[U-Boot] [PATCH 3/3] vexpress64: store env in flash

[Ryan Harkin]

Hi Linus,

On 27 October 2015 at 11:49, Linus Walleij <linus.walleij at linaro.org> wrote:
> On Wed, Oct 21, 2015 at 11:54 AM, Ryan Harkin <ryan.harkin at linaro.org> wrote:
>
>> Juno has 1 flash part with 259 sectors.  The first 255 sectors are
>> 0x40000 (256kb) and are followed by 4 sectors of 0x10000 (64KB).
>>
>> FVP models simulate a 64MB NOR flash part at base address 0x0FFC0000.
>> This part has 256 x 256kb sectors.  We use the last sector to store the
>> environment.
>
> Does this mean it appears in a AFS partition so that we see it
> sitting around there in the flash with afs (no arguments)?

Yes and no.  But mostly no.


>
> I'm asking because that seems to be how it work on the
> RealView PB11MPCore which was based on some out-of-tree
> U-Boot that Peter Pearse was maintaining at the time.
>

That seems like a nice feature.


> If there is not a AFS partition for the U-Boot environment,
> we should take measures to create one, since the flash
> is handled in AFS partitions on these machines.
>

On FVP, afs does nothing because the simulated NOR flash will come up
empty each time.

On Juno, I have created an entry in the motherboard firmware's
images.txt for a file called blank.img that lives in the same region
as the config.  The config current consumes 1 x 64kb sector, but can
consume all 4 x 64kb sectors; blank.img spans 4 x 64kb sectors.

The main idea for blank.img is two-fold:

1) let other people who edit images.txt know that we are using that region
2) allow users to erase the config by mounting the motherboard's mass
storage device and touching blank.img.  On reboot, the firmware will
see the timestamp update and re-write the blank.img file, this erasing
the config.  This is mostly useful because both EDK2 and U-Boot use
the same area of flash to store their config and EDK2 gets quite upset
if the config isn't what it expected it to be.

A potential problem:  If the config expands to consume all 4 x 64kb
partitions, then the CFI code's sector erase will wipe the footer that
afs uses to signal the blank.img file.

Of course, the afs command showing the area as "blank.img" is not
representative of what u-boot has done with it.

Either way, AFAIK, the existing CFI code does not handle AFS support.
I think the CFI code would need extending to write the footer if we
wanted the afs command to show the config in another way.  Could that
be what Peter Pearse did?

Thanks,
Ryan.