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 |
