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.pa...@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: > > > 1. 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 ? > > 1. copy fdt from fdtcontroladdr to fdt_addr_r > 2. 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! -- Tom
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot