barebox state w/ qemu

[Wes Chow]

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