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