R: [RFC] rockchip: rk3308: fix "same-as-spl" bug in boot devices order

[Tom Rini]

On Tue, Jul 11, 2023 at 04:04:57PM +0000, Pegorer Massimo wrote:
> > Da: Peter Robinson <pbrobinson at gmail.com>
> > Inviato: lunedì 3 luglio 2023 20:29
> > 
> > On Mon, Jul 3, 2023 at 6:59 PM Pegorer Massimo
> > <Massimo.Pegorer at vimar.com> wrote:
> > >
> > > Value "same-as-spl" in uboot,spl-boot-order attribute is not working
> > > for boards based on rk3308 due to mismatch between definitions in
> > > rk3308.c and those in rk3308.dtsi: in the first file boot devices are
> > > defined as "/mcc at ff4....", while in the DTSI they are "dwmmc at ff4...".
> > >
> > > Of course it could be fixed updating rk3308.c to match DTSI definitions.
> > > Anyway, I've noticed that almost all rockchip DTS/DTSI files, in the
> > > past, have been moved from using "dwmmc" to "mmc". And rk3308.dtsi in
> > > Linux kernel sources too, it has been already updated to "mmc".
> > >
> > > Therefore, other two alternative ways to fix the problem are: replace
> > > "dwmmc" with "mmc" in rk3308.dtsi; align rk3308.dtsi with Linux kernel
> > > one. Which do you suggest? I would prefer the last, but there are
> > > several other differences between u-boot and linux DTSI files.
> > 
> > Sync the linux rk3308* dt files and update the drivers appropriately if needed
> > to match.
> > 
> > > A second point is: I need to add bootph-all to sdmmc because some
> > > models of Rock Pi S are missing of SDNAND/eMMC and the only bootable
> > > device is the uSD. Is it preferrable to add it in the common
> > > rk3308-u-boot.dsi or in the board specific rk3308-rock-pi-s-u-boot.dtsi?
> > 
> > A common rk3308-u-boot.dtsi is probably the most straight forward.
> > 
> > Peter
> 
> Simon, Tom, Kever, any opinion or preference?
> 
> Peter, thanks for your feedback.
> 
> I had a look at, and changes needed by sync'ing DTS seems limited.
> Of course I will be able to test just on Rock Pi S board. Other affected
> boards will be Rockchip RK3308 EVB and Firefly roc-rk3308-cc.
> 
> If you agree, I can try to provide a patch with sync'd DTS.

One thing I would say is that the bootph changes can go to the upstream
kernel dts files, so that they aren't lost in the future, and we can
reduce the -u-boot.dtsi files.  A common -u-boot.dtsi file for now is
fine, and ideally one that the logic we have to automatically find and
include one (see u_boot_dtsi_options in scripts/Makefile.lib) will use
rather than one each board must #include.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20230711/eabf4c2a/attachment.sig>