Hi Mark, On Wed, Sep 29, 2021 at 02:59:10PM +0200, Mark Kettenis wrote: > > > > > >
[...] > > > > > > I was wondering if we need to check CONFIG_OF_BOARD here? I'm not > > > > > > sure > > > > > > whether we should distinguish the value of a1 register which is > > > > > > Yes, it seems to me that we could use a config to separate the case > > > between the prior stage and the _end. > > > > Untangling OF_SEPARATE and OF_BOARD is part of a bigger revamp I wanted to > > do on the handover of a device tree from previous bootloaders, since we do > > have similar 'problems' in Arm and TF-A. But in principle OF_SEPARATE > > shouldn't have per board code to overwrite it. OF_BOARD should be used for > > that. OF_SEPARATE should merely mean "The dtb is concatenated to my U-Boot > > binary. > > > > Right now RISC-V uses OF_SEPARATE reads the DTB on SPL and then goes back > > to using the a1 register for U-Boot proper. We could instead read the > > U-Boot concatenated DTB always in that case. OF_BOARD would then be used in > > case OpenSBI is compiled with a *different* DTB and you'd want to use that. > > Any idea if OpenSBI performs fixups before handing over the dtb in a1? > > It does. One of the things it does is add a reserved memory entry for > itself. > Ah lovely :(, then untangling that is not an option atm :(. We still have to keep board_fdt_blob_setup() a __weak symbol for those boards, even if OF_SEPARATE is selected. > > Unfortunately I don't have a board to test apart from QEMU. Let me respin > > this, with a potential fix I have in mind and we can discuss further. > > > > > Just note that, there is a patch > > > on the fly, it modifies the same snippet of code, you might need to > > > update your code based on top of it. > > > https://lists.denx.de/pipermail/u-boot/2021-September/460378.html > > > > I'll reply to that and see if the _end is indeed a problem. > > > > Thanks > > /Ilias > > Thanks /Ilias