use the device tree to find the payload and variables.

[rminnich]

we need to start using the device tree.

A good first step:
src/mainboard/emulation/qemu-armv7
in src/main.rs,
call print_fdt
as found in
lib/device_tree/src/lib.rs

This only sounds simple as stated here :-)

[rminnich]

oh guess what. It already prints it!

use device_tree::print_fdt;

let mut w = print::WriteTo::new(console);
let spi = SliceReader::new(DTB);

if let Err(err) = print_fdt(&spi, &mut w) {
    write!(w, "error: {}\n", err).expect(err);
}

So, now, the next step: how do we find the payload nodes? Why aren't they printed?

[derpsteb]

So I just decompiled the armv7 dtb to compare it to a decompiled qemu-q35 dtb. It can be found in this gist.

Looking at the q35 fixed-dtfs.dts, the location of the DTFS is specified. This is also the case when decompiling the q35's .dtb. I guess the value of the compatible property is relevant here, since it's set to ore-rampayload. Thus oreboot can look for the correct driver to handle this device, which would then load the payload and execute it (or something like this?).

Comparing that to the armv7 dt I can not immediately see something similar. So now I will have to verifiy if my above assumption is correct or how else oreboot usually identifies the payload device from the dt (or any other source..).

[derpsteb]

So I think I am hitting a minor blocker here. The way we currently build up the flash, based on the dts, is not stable imo. Meaning that it may be layed out differently every time.

My current understanding of the layoutflash tool:
We build up a vec of Areas based on the dts. These objects are essentially the same thing as the area nodes in the dts. With the difference of having an offset property [1].
This property is calculated for each invocation of layoutflash, based on the order of the objects in the areas variable in the layout_flash() function [2]. Meaning that we keep track of the current offset while iterating through the vec and based on the size we see for the current node we advance the offset.
However, in layout_flash() the areas variable is sorted right in the beginning, using sort_unstable_by_key [3]. Problem: offset is None for all nodes, every time. Thus there is no sorting among the nodes.
This works for creating the flash, since no one currently relies on the layout.

My suggestion is to add the reg = offset+length property to the dts and rely on that for layout information in the future as it seems to be the way the spec suggests to describe memory mappings for devices. But this seem like a bigger change. Maybe its good to talk about this in the weekly today?

[1] https://github.com/oreboot/oreboot/blob/main/src/lib/device_tree/src/area.rs#L13
[2] https://github.com/oreboot/oreboot/blob/main/tools/layoutflash/src/main.rs#L31
[3] https://github.com/oreboot/oreboot/blob/main/tools/layoutflash/src/main.rs#L32

[derpsteb]

Ignoring above problem I created a draft that finds the correct Area object and it's offset and prints a message about the load operation it could now perform here.