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. * * Scenario 3: fdt blob is not available. [..] david > > Regards, > Anup > > > -----Original Message----- > > From: Atish Patra > > Sent: Sunday, September 8, 2019 5:40 PM > > To: david.abdurachma...@sifive.com; Alistair Francis > > <alistair.fran...@wdc.com>; Anup Patel <anup.pa...@wdc.com> > > Cc: u-boot@lists.denx.de; open...@lists.infradead.org > > Subject: FDT placement in OpenSBI + U-Boot + Linux kernel issue for RISC-V > > > > Hi All, > > > > I noticed following issues around U-Boot fdt location in Unleashed and Qemu > > virt machine. > > > > OpenSBI copies the FDT to following addresses for respective platforms > > > > Qemu: 0x82200000 > > Unleashed: 0x88000000 > > > > > > As CONFIG_PRIOR_STAGE is set for both platforms, fdt is first copied to > > gd->fdt_blob and then gets relocated to a different address(gd- > > >new_fdt) in function reloc_fdt. > > > > As a result, FDT is present at two locations. > > > > 1. 0x88000000(Unleashed)/0x82200000(Qemu) : OpenSBI copied FDT to this > > address. > > 2. gd->new_fdt: U-Boot relocated the fdt to this address. > > fdtcontroladdr will also point to this address. > > > > However, commit ac12c6190927 (riscv: set CONFIG_SYS_BOOTM_LEN to > > SZ_64M) in U-boot changed Qemu config so that fdt_addr_r points to > > 0x88000000 which is wrong as nobody copies fdt to above address in Qemu. > > Also, 5.3-rc+ kernels overwrite the address pointed by fdtcontroladdr. > > > > As a result, fdtcontroladdr won't work on any platform and fdt_addr_r will > > work only for Unleashed but not for Qemu. > > > > I am not sure what should be the ideal solution to avoid these kind of fdt > > placement issues in future. Here are the few possible ones. > > > > 1. Change the FDT_JUMP_ADDR in OpenSBI to 0x88000000(RAM+128MB) for > > Qemu as well. This won't work as Qemu copies initrd to that address. I guess > > best next option is to copy to 0x84000000(RAM+64MB) and U-boot config for > > Qemu accordingly. > > > > 2. Change fdt_addr_r to 0x82200000 in Qemu. Update documentation to use > > fdt only from fdt_addr_r not fdtcontroladdr. > > > > @david: What was the reason behind changing it for Qemu ? > > > > 3. Fix gd->new_fdt computation. This may affect every board which is not a > > very good idea either. > > > > 4. Mandate loading fdt only from tftp or sdcard which is the safest option > > and > > will avoid these kind of complications. However, I think a default booting > > method without tftp server should at least work. Let me know if that is not > > a > > sane request. In that case, we should update documentation to clearly say > > that only tftpboot or sdcard loading method works. > > > > > > -- > > Regards, > > Atish > _______________________________________________ > opensbi mailing list > open...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/opensbi _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot