[U-Boot] [PATCH] qemu-arm: Add persistent environment support

[Takahiro Akashi]

On Thu, Dec 13, 2018 at 02:43:58AM +0200, Tuomas Tynkkynen wrote:
> Hi Sumit, Takahiro,
> 
> On Wed, 12 Dec 2018 10:42:56 +0900
> Takahiro Akashi <takahiro.akashi at linaro.org> wrote:
> 
> > On Tue, Dec 11, 2018 at 06:04:05PM +0530, Sumit Garg wrote:
> > > On Mon, 26 Nov 2018 at 16:51, Sumit Garg <sumit.garg at linaro.org>
> > > wrote:  
> > > >
> > > > Currently on qemu-arm platforms environment is kept in RAM.
> > > > Instead use pflash device 1 to provide persistent environment
> > > > support across device reset.
> > > >
> > > > Also (optionally) provide support for persistent environment
> > > > across qemu machine OFF/ON using following instructions:
> > > >
> > > > - Create envstore.img using qemu-img:
> > > >     qemu-img create -f raw envstore.img 64M
> > > > - Add a pflash drive parameter to the command line:
> > > >     -drive if=pflash,format=raw,index=1,file=envstore.img
> > > >
> > > > Signed-off-by: Sumit Garg <sumit.garg at linaro.org>
> > > > ---
> > > >  configs/qemu_arm64_defconfig | 7 +++++++
> > > >  configs/qemu_arm_defconfig   | 7 +++++++
> > > >  doc/README.qemu-arm          | 6 ++++++
> > > >  include/configs/qemu-arm.h   | 8 +++++++-
> > > >  4 files changed, 27 insertions(+), 1 deletion(-)
> > > >  
> > > 
> > > Gentle reminder. Please let me know if you have any further
> > > comments.  
> 
> I'm not too familiar with the UEFI/ATF related aspects here, but I
> think that the read-only parts (aka u-boot.bin) and read-write parts
> (the U-Boot environment) should belong to different files (which is
> what this patch series does). Basically, IMO as a normal user I should
> be able to run QEMU on a distro-provided U-Boot binary with something
> like:

So probably I'm not a normal user.
Tom has already applied this patch, and I would change qemu-arm.h
in my local repo if necessary. That's fine.

>     qemu-system-arm -bios /usr/share/u-boot/qemu_arm.bin

# As u-boot is quite board-specific, I don't think distro's default
u-boot, if any, won't work on qemu.

> and not have it fail due to not having write permission to /usr/.
> 
> > Another use case is atf + u-boot (although I don't know people are
> > interested in it). Put bl1.bin in flash0(0x0-0x4000000) and put
> > fip.bin in flash1(0x4000000-0x8000000). Please note that, with
> > secure=on, flash0 is in secure and flash1 is in non-secure.
> > While I admit that your patch is workable, my point is that there are
> > different use cases and it may not be a good idea to put one
> > configuration in qemu-arm.h.

> Can EDK2 in QEMU boot with ATF and if so, how does it lay out things?

Do you mean UEFI? EDK2 is an implementation, UEFI is the specification/
interface.
Just FYI, as I said, I experimentally succeeded to run atf + u-boot
as BL33, only modifying CONFIG_SYS_TEXT_BASE and CONFIG_SYS_FLASH_BASE
(and CONFIG_ENV_* if needed).

> Would it be possible to build U-Boot in such a way that u-boot.bin
> could be substituted in existing build scripts or instructions in place
> of the EDK2 binary so that things still work the same?
> 
> Or in other words, if EDK2 has already has a working
> implementation of something (such as the flash layout), IMO we should
> prefer to use that instead of reimplementing it in a different
> way.

It is up to the implementation how efi variables are stored
in storage while efi variables on u-boot are mapped to corresponding
u-boot environment variables. So there's no compatibility in flash layout
between EDK2 and u-boot/UEFI.

Thanks,
-Takahiro Akashi


> - Tuomas