barebox state w/ qemu

[Ahmad Fatoum]

Hello Wes,

On 08.07.24 04:22, Wes Chow wrote:
> I am trying to better understand barebox and playing with it via
> Buildroot with Qemu. One thing I don't understand is how the state
> backend is configured. I see this:
> 
> https://github.com/barebox/barebox/blob/d74c84582591ac1f93b203d733831fcf18e6b033/common/boards/qemu-virt/qemu-virt-flash.dtso#L4
> 
> ..however I don't know how to read dts overlay files.

The device trees and device tree overlays you see in the barebox source
tree are normally compiled _into_ barebox. Board code then references
them. For Qemu's state overlay, this is being done here:

  https://github.com/barebox/barebox/blob/d74c84582591ac1f93b203d733831fcf18e6b033/common/boards/qemu-virt/board.c#L76

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.

> Do I need to set
> up a disk with a partition scheme that matches lines 17-30? Or is it
> sufficient to just have a partition with the "barebox-state" label?

"fixed-partitions" are partitions that have a fixed offset that isn't
of any on-disk (MBR, GPT, ...etc.) partitioning. So you don't need
to do anything special with your disk, just ensure you don't place
any data you don't want clobbered into the environment/state partition.

> Also possibly of relevance, I'm starting qemu like so:
> 
> qemu-system-aarch64 -m 2048M -cpu cortex-a57 -machine virt -display
> none -serial mon:stdio -kernel output/images/barebox-dt-2nd.img
> -device virtio-blk-pci,drive=hd0,disable-legacy=on -drive
> file=output/images/rootfs.ext2,if=none,format=raw,id=hd0
> 
> The rootfs.ext2 disk becomes available to barebox as /dev/virtioblk0.
> How does barebox know which disk to search for the backend?

This is described in the state device tree node. In the case of the Qemu
overlay, it's /state/backend-type = <&backend_state_flash>, which is
partition at 3e00000 on the cfi-flash.

Because that flash is a fixed part of the virt machine, you should
already have functional state:

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

If you got no errors at all, which defconfig did you use?
multi_v8_defconfig should have everything needed for this to just
work out of the box.

Placing the state on the Virt I/O disk is possible too in theory, but more
complicated, because there is no device tree nodes you can easily reference
in the DT. I'd suggest that you use the flash for state, even if your
rootfs is on a Virt I/O block device.

> In the target image, I installed dt-utils and so have access to the
> barebox-state command. How does the barebox-state executable know
> where to look for the state backend? Is this passed down through the
> device tree?

Yes. When the barebox state driver successfully probes, it takes care to
fix up into the kernel device tree the state description node, so dt-utils
can find it. If you are interested to see what fixups barebox is going to
apply, you can list them with (+ means take the previous arguments, but
fix it up):

  of_diff /mnt/virtioblk0/boot/my-devicetree.dtb +

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 |