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... > 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? 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 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 ... 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,...`. Thanks, Wes
