[RFC] rockchip: rk3308: fix "same-as-spl" bug in boot devices order
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@ff4....", while in the DTSI they are "dwmmc@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.
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?
Thanks. Regards, Massimo
On Mon, Jul 3, 2023 at 6:59 PM Pegorer Massimo Massimo.Pegorer@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@ff4....", while in the DTSI they are "dwmmc@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
Da: Peter Robinson pbrobinson@gmail.com Inviato: lunedì 3 luglio 2023 20:29
On Mon, Jul 3, 2023 at 6:59 PM Pegorer Massimo Massimo.Pegorer@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@ff4....", while in the DTSI they are "dwmmc@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.
Thanks. Regards,
Massimo
On Tue, Jul 11, 2023 at 04:04:57PM +0000, Pegorer Massimo wrote:
Da: Peter Robinson pbrobinson@gmail.com Inviato: lunedì 3 luglio 2023 20:29
On Mon, Jul 3, 2023 at 6:59 PM Pegorer Massimo Massimo.Pegorer@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@ff4....", while in the DTSI they are "dwmmc@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.
On Tue, Jul 11, 2023 at 2:14 PM Tom Rini trini@konsulko.com wrote:
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
Are you sure? I don't see bootph devicetree properties being supported in 6.5-rc1.
On Tue, Jul 11, 2023 at 03:01:28PM -0300, Fabio Estevam wrote:
On Tue, Jul 11, 2023 at 2:14 PM Tom Rini trini@konsulko.com wrote:
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
Are you sure? I don't see bootph devicetree properties being supported in 6.5-rc1.
$ git grep -l bootph arch/arm64/ arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi arch/arm64/boot/dts/xilinx/zynqmp-sm-k26-revA.dts arch/arm64/boot/dts/xilinx/zynqmp.dtsi $ git describe HEAD v6.5-rc1-6-g3f01e9fed845
On Tue, Jul 11, 2023 at 5:04 PM Tom Rini trini@konsulko.com wrote:
$ git grep -l bootph arch/arm64/ arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi arch/arm64/boot/dts/xilinx/zynqmp-sm-k26-revA.dts arch/arm64/boot/dts/xilinx/zynqmp.dtsi $ git describe HEAD v6.5-rc1-6-g3f01e9fed845
but where is bootph documented?
On Tue, Jul 11, 2023 at 05:11:15PM -0300, Fabio Estevam wrote:
On Tue, Jul 11, 2023 at 5:04 PM Tom Rini trini@konsulko.com wrote:
$ git grep -l bootph arch/arm64/ arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi arch/arm64/boot/dts/xilinx/zynqmp-sm-k26-revA.dts arch/arm64/boot/dts/xilinx/zynqmp.dtsi $ git describe HEAD v6.5-rc1-6-g3f01e9fed845
but where is bootph documented?
I don't know where Rob is with how the schema stuff is being handled itself, but it's: https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/bootp...
And I also believe some of the TI parts have the bootph properties merged, but not in time for v6.5-rc1.
participants (4)
-
Fabio Estevam -
Pegorer Massimo -
Peter Robinson -
Tom Rini