[U-Boot] FDT placement in OpenSBI + U-Boot + Linux kernel issue for RISC-V

[Tom Rini]

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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190910/5bb22a12/attachment.sig>