From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Thompson Date: Fri, 14 Dec 2018 11:11:34 +0000 Subject: [U-Boot] [PATCH] qemu-arm: Add persistent environment support In-Reply-To: <20181214110008.GA14562@linaro.org> References: <1543231217-18799-1-git-send-email-sumit.garg@linaro.org> <20181212014255.GK21466@linaro.org> <20181213024358.754d360c@thinkpad> <20181214110008.GA14562@linaro.org> Message-ID: <20181214111134.5aheae7fu6afc3zm@holly.lan> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 wrote: > > > > > On Tue, Dec 11, 2018 at 06:04:05PM +0530, Sumit Garg wrote: > > > > On Mon, 26 Nov 2018 at 16:51, Sumit Garg > > > > 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 > > > > > --- > > > > > 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