On Tue, Sep 10, 2019 at 09:59:38AM +0000, Atish Patra wrote:
On Mon, 2019-09-09 at 13:22 +0300, David Abdurachmanov wrote:
On Mon, Sep 9, 2019 at 8:05 AM Anup Patel Anup.Patel@wdc.com wrote:
Hi,
I think keeping FDT placement in-sync between U-Boot and OpenSBI across platforms is going to be painful.
I suggest that for all platforms U-Boot explicitly load FDT from somewhere so:
- U-Boot ${fdt_addr_r} default value will be recommended location
of FDT 2. U-Boot ${fdtcontroladdr} will always point to copy of FDT passed by OpenSBI 3. To forward FDT passed by OpenSBI to Linux, U-Boot users can always explicitly copy FDT from ${fdtcontroladdr} to ${fdt_addr_r} using U-Boot copy command
I also suspect that in-future for certain platforms FDT passed to U-Boot and FDT passed to Linux might be little different due to U-Boot specific changes in DTS.
Thoughts ??
Do not forget PXE and EXTLINUX boot options. These options must always be able to override DTB from previous stages. See below what PXE/EXT use. For Fedora/RISCV we end up in scenario #2 and thus fdt_addr needs to be set if DTB is coming from somewhere in the firmware. This is why we had CONFIG_PREBOOT to set it.
[..]
- Scenario 1: If fdt_addr_r specified and "fdt" label is defined in
- pxe file, retrieve fdt blob from server. Pass fdt_addr_r to bootm,
- and adjust argc appropriately.
- Scenario 2: If there is an fdt_addr specified, pass it along to
- bootm, and adjust argc appropriately.
How about if we do this in PREBOOT ?
- copy fdt from fdtcontroladdr to fdt_addr_r
- setenv fdt_addr $fdt_addr_r
In this way, U-Boot will not have any direct dependancies on OpenSBI. As long as U-Boot is configured with a fdt_addr_r, it should work. It will be still valid for loading fdt from tftp server to fdt_addr_r as well.
Since, arg, it looks like we're already seeing some of the original mistakes from ARM land (fdt address in a bad place and getting stomped by ...), lets take a look at how this is being handled today there and mirror it? We should for example pick the fdt-in-memory location such that we have enough room between it and the maximum kernel + bss, round up and place it there. Then round up again for an overly large fdt to say that's where ramdisk should go. Thanks!