mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: Wes Chow <wes.chow@gmail.com>
Cc: barebox@lists.infradead.org
Subject: Re: barebox state w/ qemu
Date: Tue, 9 Jul 2024 11:16:31 +0200	[thread overview]
Message-ID: <c1ac0b3f-5a9d-4aab-9f26-d8e0970e959b@pengutronix.de> (raw)
In-Reply-To: <CAGWymk23wmB14DSzHcyjc0eHCVaNgxeG6ykL7WyE_fCCiTsdsw@mail.gmail.com>

Hello Wes,

On 09.07.24 04:13, Wes Chow wrote:
> Ahmad,
> 
>> Normally, the barebox device tree already describes the state and
>> environment, but Qemu is a special case, because the device tree is
>> not compiled into barebox, but supplied by the virtual machine.
>>
>> Thus this overlay to add some barebox specific information. As this
>> should happen very early, so that the environment can take effect early
>> on, the overlays aren't applied dynamically in this case, but compiled-in.
> 
> Thanks, that's very helpful. I'm starting to understand but I'm not
> quite there yet...

No problem. Once we have figured this out, maybe we should reword the parts
of the docs that were confusing.

>> Because that flash is a fixed part of the virt machine, you should
>> already have functional state:
>>
>>   barebox@ARM QEMU virt64:/ state
>>   registered state instances:
>>   state                (backend: raw, path: /dev/nor0.barebox-state)
>>
>> Is this not the case and if not, what errors did you get?
> 
> I do have the same thing. If I'm reading the docs correctly though I
> should be able to modify state with the nv command, right?

Not quite. As you see in the overlay, there are two partitions created
for barebox use: The environment partition and state.

The environment partition can contain anything: scripts, default values
for variables (nv), boot splashes, binaries ...etc.

The state partition however only contains the variables that you explicitly
define in your device tree state description. Unlike the environment,
these variables are laid out redundantly, so they are accessible in a
power-fail safe manner.

Systems with verified boot can thus elect to disable the mutable
environment completely and only keep the barebox built-in environment
while still being able to do A/B boot and such as that uses the
barebox state as backend, which is separate.

> This doesn't seem to persist the foo variable:
> 
>  barebox@ARM QEMU virt64:/ state
>  registered state instances:
>  state                (backend: raw, path: /dev/nor0.barebox-state)
>  barebox@ARM QEMU virt64:/ nv foo=bar
>  nv variable modified, will save nv variables on shutdown
>  barebox@ARM QEMU virt64:/ nv
>    allow_color: true
>    autoboot_timeout: 3
>    foo: bar
>    user: none
>  barebox@ARM QEMU virt64:/ poweroff

state variables can be set via device parameters, devinfo state
will tell you what variables you have and then you can set them like
this:

  state.bootstate.system0.priority=30

The variables have tab completion, so you can just state.<Tab> to list
them.

State is automatically saved when barebox exits, so you don't
need to call state -s manually to write your changes back.

> When I restart Qemu the "foo" variable goes away. And actually, every
> time I start Qemu I get this message:
> 
>  state state.of: Fresh state detected, continuing with defaults
> 
> Do I need to specify a flash device when starting Qemu? I'm running
> this (taken from the docs):
> 
>  qemu-system-aarch64 -m 2048M -cpu cortex-a57 -machine virt -display
> none -serial stdio -kernel ./images/barebox-dt-2nd.img

The assumption (that's probably not written down anywhere) is that the
user would use reset, not poweroff if they want state to persist.

Of course, on real boards, both are expected to work, but it's IMO an acceptable
tradeoff for emulation.

> ... but I'm guessing I'm missing a pflash argument. I've been trying
> various incantations but haven't been able to get Qemu to boot
> successfully if I supply a `-drive if=pflash,...`.

I think the problem is that QEMU expects you to place a "BIOS" (first stage
bootloader) into the pflash if you specify it. Unlike e.g. vexpress, barebox
for Qemu Virt64 only generates an image for use with -kernel.

You can use the second flash though (-drive if=pflash,unit=1) and change
the device tree overlay to point at.

There's surely neater ways to go about it. What are you trying to do?

Cheers,
Ahmad

> 
> Thanks,
> Wes
> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |




  reply	other threads:[~2024-07-09  9:17 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-08  2:22 Wes Chow
2024-07-08  6:49 ` Ahmad Fatoum
2024-07-09  2:13   ` Wes Chow
2024-07-09  9:16     ` Ahmad Fatoum [this message]
2024-07-11 11:47       ` Wes Chow
2024-07-12 22:35         ` Wes Chow

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=c1ac0b3f-5a9d-4aab-9f26-d8e0970e959b@pengutronix.de \
    --to=a.fatoum@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    --cc=wes.chow@gmail.com \
    /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