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

[Daniel Thompson]

On Fri, Dec 14, 2018 at 08:00:11PM +0900, Takahiro Akashi wrote:
> 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.

To be honest I think we should seriously consider changing TF-A so that
is doesn't look for the FIP in the non-secure flash. When TF-A and the
secure world payload are part of the FIP then loading them from
non-secure flash is a very odd thing to do (in addition to the
practical problems related to read-only binaries in /usr when firmware
and varstore live in the same pflash).


Daniel.

> 
> >     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