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@3e00000 on the cfi-flash. 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? 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 |
