public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Takahiro Akashi <takahiro.akashi@linaro.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] qemu-arm: Add persistent environment support
Date: Fri, 14 Dec 2018 20:00:11 +0900	[thread overview]
Message-ID: <20181214110008.GA14562@linaro.org> (raw)
In-Reply-To: <20181213024358.754d360c@thinkpad>

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

  parent reply	other threads:[~2018-12-14 11:00 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-26 11:20 [U-Boot] [PATCH] qemu-arm: Add persistent environment support Sumit Garg
2018-11-27  6:47 ` AKASHI Takahiro
2018-11-27  7:41   ` Sumit Garg
2018-11-27  8:17     ` Takahiro Akashi
2018-11-27  9:51       ` Sumit Garg
2018-12-11 12:34 ` Sumit Garg
2018-12-12  1:42   ` Takahiro Akashi
2018-12-12  6:44     ` Sumit Garg
2018-12-12  7:40       ` Takahiro Akashi
2018-12-12 11:27         ` Sumit Garg
2018-12-13  0:43     ` Tuomas Tynkkynen
2018-12-13  9:30       ` Daniel Thompson
2018-12-14 11:00       ` Takahiro Akashi [this message]
2018-12-14 11:11         ` Daniel Thompson
2018-12-13  0:47 ` [U-Boot] " Tom Rini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181214110008.GA14562@linaro.org \
    --to=takahiro.akashi@linaro.org \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox