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

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

Ah, so I misunderstood the relationship between environment and state.
I had thought that state was the storage mechanism for persisting
things in the environment.


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

Got it, yes I can see it working now.

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

Ah that explains it -- no, I didn't see this in documentation
anywhere, but I'm a noob. I may write up a blog post or something on
what I've been learning.

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

Got it.. that should work for my purposes. I was able to see that the
nv variables persisted after a reboot so that's great.

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

Thanks, that's good to know.. I don't think I need to go down this
route though. My high level goal is that I would like to have a
hands-on understanding of setting up an A/B boot strategy, and I
figured I'd learn via Qemu emulation before attempting on real
hardware. In a past defunct project we used Qemu emulation for a lot
of development and testing and then deployed onto Raspberry Pi CM3s,
so I just naturally reached for Qemu again for this personal project.
Ultimately I want to do this with real hardware, likely Raspberry Pis
or something similar.

After I set state:

 barebox@ARM QEMU virt64:/ state.bootstate.system0.priority=30

How do I see that that's been reflected in the state? Is there a way
for me to dump out all state values?

In the target, I'm getting an error with barebox-state:

 # barebox-state -d
 state: state failed to parse path to backend: No such device
 unable to initialize state: No such device

Do I need to configure barebox-state somehow? Perhaps the Linux kernel
can't see the flash?

Thanks,
Wes



  reply	other threads:[~2024-07-11 11:48 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
2024-07-11 11:47       ` Wes Chow [this message]
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=CAGWymk38NhebcvNAbDUeXJ+1BRU3V+npCTYjeykca4EoHkiyYQ@mail.gmail.com \
    --to=wes.chow@gmail.com \
    --cc=a.fatoum@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    /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