rk3328 broken between v2022.04 and v2022.07 - still not working with v2023.01
Hello,
After a few years, I tried updating my u-boot 2021 to a more recent version, as the linux kernel complained "ATF needs update". The device I'm using is a nanopi neo3 2GB (more or less the same compared to NanoPi R2S, both RK3328 platform).
Starting from 2023.04-rc1, I couldn't get it running: in TPL, it complained "out of memory". A hint on IRC made me pull back to v2022.04, which works with a few mods, but there's one (minor) thing not working: board_misc_init() causes a function call failed. Probably because efuse isn't working properly? I also had to modify the device tree a bit:
--- a/arch/arm/dts/rk3328-nanopi-r2s.dts +++ b/arch/arm/dts/rk3328-nanopi-r2s.dts @@ -166,6 +166,35 @@ }; };
+&saradc { + status = "okay"; +}; + +&efuse { + status = "okay"; +}; + + +&spi0 { + status = "okay"; + + spiflash@0 { + compatible = "jedec,spi-nor"; + reg = <0>; + +// maximum speed for Rockchip SPI + spi-max-frequency = <50000000>; + }; +}; + +&rng { + status = "okay"; +}; + +&pdm { + status = "okay"; +}; + --- a/arch/arm/dts/rk3328.dtsi +++ b/arch/arm/dts/rk3328.dtsi @@ -279,6 +279,17 @@ status = "disabled"; };
+ rng: rng@ff060000 { + compatible = "rockchip,cryptov1-rng"; + reg = <0x0 0xff060000 0x0 0x4000>; + + clocks = <&cru SCLK_CRYPTO>, <&cru HCLK_CRYPTO_SLV>; + clock-names = "clk_crypto", "hclk_crypto"; + assigned-clocks = <&cru SCLK_CRYPTO>, <&cru HCLK_CRYPTO_SLV>; + assigned-clock-rates = <150000000>, <100000000>; + status = "disabled"; + }; +
The sdram controller needs to be patched as well to compile:
--- a/drivers/ram/rockchip/sdram_rk3328.c +++ b/drivers/ram/rockchip/sdram_rk3328.c @@ -561,7 +561,7 @@ static int rk3328_dmc_of_to_plat(struct udevice *dev) __func__, ret); return ret; } - ret = regmap_init_mem(dev, &plat->map); + ret = regmap_init_mem(dev->node_, &plat->map); if (ret) printf("%s: regmap failed %d\n", __func__, ret); #endif
And ultimately, rockchip SFC also needs an update:
--- a/drivers/spi/rockchip_sfc.c +++ b/drivers/spi/rockchip_sfc.c @@ -17,6 +17,7 @@ #include <linux/iopoll.h> #include <spi.h> #include <spi-mem.h> +#include <dm/device_compat.h>
But starting from 2022.07, the system simply prints (in TPL) "data training error" and gives up (using default values in "make oldconfig". I have the config files of both 2022.04 and 2022.07 attached, any clue why it's no longer working?
Kind regards,
Janpieter Sollie
On Fri, Feb 10, 2023 at 6:01 PM Janpieter Sollie janpieter.sollie@kabelmail.de wrote:
Hello,
After a few years, I tried updating my u-boot 2021 to a more recent version, as the linux kernel complained "ATF needs update". The device I'm using is a nanopi neo3 2GB (more or less the same compared to NanoPi R2S, both RK3328 platform).
Starting from 2023.04-rc1, I couldn't get it running: in TPL, it complained "out of memory". A hint on IRC made me pull back to v2022.04, which works with a few mods, but there's one (minor) thing not working: board_misc_init() causes a function call failed. Probably because efuse isn't working properly? I also had to modify the device tree a bit:
--- a/arch/arm/dts/rk3328-nanopi-r2s.dts +++ b/arch/arm/dts/rk3328-nanopi-r2s.dts @@ -166,6 +166,35 @@ }; };
Fyi: v2023.01 is working for me (roc-rk3328-cc) but the master is broken.
Jagan.
On Fri, Feb 10, 2023 at 12:31 PM Janpieter Sollie janpieter.sollie@kabelmail.de wrote:
Hello,
After a few years, I tried updating my u-boot 2021 to a more recent version, as the linux kernel complained "ATF needs update". The device I'm using is a nanopi neo3 2GB (more or less the same compared to NanoPi R2S, both RK3328 platform).
Starting from 2023.04-rc1, I couldn't get it running: in TPL, it complained "out of memory". A hint on IRC made me pull back to v2022.04, which works with a few mods, but there's one (minor) thing not working: board_misc_init() causes a function call failed. Probably because efuse isn't working properly? I also had to modify the device tree a bit:
I have the Rock64 running 2022.10 without issues.
--- a/arch/arm/dts/rk3328-nanopi-r2s.dts +++ b/arch/arm/dts/rk3328-nanopi-r2s.dts @@ -166,6 +166,35 @@ }; };
+&saradc {
status = "okay";+};
+&efuse {
status = "okay";+};
+&spi0 {
status = "okay";spiflash@0 {compatible = "jedec,spi-nor";reg = <0>;+// maximum speed for Rockchip SPI
spi-max-frequency = <50000000>;};+};
+&rng {
status = "okay";+};
+&pdm {
status = "okay";+};
--- a/arch/arm/dts/rk3328.dtsi +++ b/arch/arm/dts/rk3328.dtsi @@ -279,6 +279,17 @@ status = "disabled"; };
rng: rng@ff060000 {compatible = "rockchip,cryptov1-rng";reg = <0x0 0xff060000 0x0 0x4000>;clocks = <&cru SCLK_CRYPTO>, <&cru HCLK_CRYPTO_SLV>;clock-names = "clk_crypto", "hclk_crypto";assigned-clocks = <&cru SCLK_CRYPTO>, <&cru HCLK_CRYPTO_SLV>;assigned-clock-rates = <150000000>, <100000000>;status = "disabled";};The sdram controller needs to be patched as well to compile:
--- a/drivers/ram/rockchip/sdram_rk3328.c +++ b/drivers/ram/rockchip/sdram_rk3328.c @@ -561,7 +561,7 @@ static int rk3328_dmc_of_to_plat(struct udevice *dev) __func__, ret); return ret; }
ret = regmap_init_mem(dev, &plat->map);
ret = regmap_init_mem(dev->node_, &plat->map); if (ret) printf("%s: regmap failed %d\n", __func__, ret);And ultimately, rockchip SFC also needs an update:
--- a/drivers/spi/rockchip_sfc.c +++ b/drivers/spi/rockchip_sfc.c @@ -17,6 +17,7 @@ #include <linux/iopoll.h> #include <spi.h> #include <spi-mem.h> +#include <dm/device_compat.h>
But starting from 2022.07, the system simply prints (in TPL) "data training error" and gives up (using default values in "make oldconfig". I have the config files of both 2022.04 and 2022.07 attached, any clue why it's no longer working?
Kind regards,
Janpieter Sollie
Op 10/02/2023 om 13:41 schreef Peter Robinson:
On Fri, Feb 10, 2023 at 12:31 PM Janpieter Sollie janpieter.sollie@kabelmail.de wrote:
Hello,
After a few years, I tried updating my u-boot 2021 to a more recent version, as the linux kernel complained "ATF needs update". The device I'm using is a nanopi neo3 2GB (more or less the same compared to NanoPi R2S, both RK3328 platform).
Starting from 2023.04-rc1, I couldn't get it running: in TPL, it complained "out of memory". A hint on IRC made me pull back to v2022.04, which works with a few mods, but there's one (minor) thing not working: board_misc_init() causes a function call failed. Probably because efuse isn't working properly? I also had to modify the device tree a bit:
I have the Rock64 running 2022.10 without issues.
On your advice, I tested these as well 2022.10 and 2023.1. seems to work when the patches are applied. However, still no misc_init():
initcall sequence 000000007ffcf0b0 failed at call 0000000000202ff8 (err=-1) ### ERROR ### Please RESET the board ###
in the map file I see this points to misc_init() but I guess your advice already obsoletes my statement, it's only "2023.04-rc1" now. make oldconfig seems to be a bad idea, simply defconfig and make modifications again seems to be a much safer choice.
Any way I could help fixing the misc_init_f()?
kind regards,
Janpieter Sollie
Hi, On 2023-02-10 16:32, Janpieter Sollie wrote:
Op 10/02/2023 om 13:41 schreef Peter Robinson:
On Fri, Feb 10, 2023 at 12:31 PM Janpieter Sollie janpieter.sollie@kabelmail.de wrote:
Hello,
After a few years, I tried updating my u-boot 2021 to a more recent version, as the linux kernel complained "ATF needs update". The device I'm using is a nanopi neo3 2GB (more or less the same compared to NanoPi R2S, both RK3328 platform).
Starting from 2023.04-rc1, I couldn't get it running: in TPL, it complained "out of memory". A hint on IRC made me pull back to v2022.04, which works with a few mods, but there's one (minor) thing not working: board_misc_init() causes a function call failed. Probably because efuse isn't working properly? I also had to modify the device tree a bit:
I have the Rock64 running 2022.10 without issues.
On your advice, I tested these as well 2022.10 and 2023.1. seems to work when the patches are applied. However, still no misc_init():
initcall sequence 000000007ffcf0b0 failed at call 0000000000202ff8 (err=-1) ### ERROR ### Please RESET the board ###
in the map file I see this points to misc_init() but I guess your advice already obsoletes my statement, it's only "2023.04-rc1" now. make oldconfig seems to be a bad idea, simply defconfig and make modifications again seems to be a much safer choice.
Any way I could help fixing the misc_init_f()?
Try with CONFIG_ROCKCHIP_EFUSE disabled. misc_init_f will try to read cpuid from efuse/otp and use that to have a persistent ethaddr, should probably not hard fail when there is no efuse/otp to read cpuid from.
Regards, Jonas
kind regards,
Janpieter Sollie
Op 10/02/2023 om 17:02 schreef Jonas Karlman:
Hi, On 2023-02-10 16:32, Janpieter Sollie wrote:
Op 10/02/2023 om 13:41 schreef Peter Robinson:
On Fri, Feb 10, 2023 at 12:31 PM Janpieter Sollie janpieter.sollie@kabelmail.de wrote:
Hello,
After a few years, I tried updating my u-boot 2021 to a more recent version, as the linux kernel complained "ATF needs update". The device I'm using is a nanopi neo3 2GB (more or less the same compared to NanoPi R2S, both RK3328 platform).
Starting from 2023.04-rc1, I couldn't get it running: in TPL, it complained "out of memory". A hint on IRC made me pull back to v2022.04, which works with a few mods, but there's one (minor) thing not working: board_misc_init() causes a function call failed. Probably because efuse isn't working properly? I also had to modify the device tree a bit:
I have the Rock64 running 2022.10 without issues.
On your advice, I tested these as well 2022.10 and 2023.1. seems to work when the patches are applied. However, still no misc_init():
initcall sequence 000000007ffcf0b0 failed at call 0000000000202ff8 (err=-1) ### ERROR ### Please RESET the board ###
in the map file I see this points to misc_init() but I guess your advice already obsoletes my statement, it's only "2023.04-rc1" now. make oldconfig seems to be a bad idea, simply defconfig and make modifications again seems to be a much safer choice.
Any way I could help fixing the misc_init_f()?
Try with CONFIG_ROCKCHIP_EFUSE disabled. misc_init_f will try to read cpuid from efuse/otp and use that to have a persistent ethaddr, should probably not hard fail when there is no efuse/otp to read cpuid from.
Regards, Jonas
kind regards,
Janpieter Sollie
I made a typo here, sorry: the function we're talking about is misc_init_r(). Without efuse, it won't do a thing:
__weak intmisc_init_r(void) { constu32 cpuid_offset = 0x7; constu32 cpuid_length = 0x10; u8 cpuid[cpuid_length]; intret;
ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, cpuid); if(ret) returnret;
ret = rockchip_cpuid_set(cpuid, cpuid_length); if(ret) returnret;
ret = rockchip_setup_macaddr();
returnret; }
I may as well simply dump the mac in a uboot.env and skip misc_init completely ... which is what I did right now :)
Kind regards,
Janpieter Sollie
Op 10/02/2023 om 17:02 schreef Jonas Karlman:
Hi, On 2023-02-10 16:32, Janpieter Sollie wrote:
Op 10/02/2023 om 13:41 schreef Peter Robinson:
On Fri, Feb 10, 2023 at 12:31 PM Janpieter Sollie janpieter.sollie@kabelmail.de wrote:
Hello,
After a few years, I tried updating my u-boot 2021 to a more recent version, as the linux kernel complained "ATF needs update". The device I'm using is a nanopi neo3 2GB (more or less the same compared to NanoPi R2S, both RK3328 platform).
Starting from 2023.04-rc1, I couldn't get it running: in TPL, it complained "out of memory". A hint on IRC made me pull back to v2022.04, which works with a few mods, but there's one (minor) thing not working: board_misc_init() causes a function call failed. Probably because efuse isn't working properly? I also had to modify the device tree a bit:
I have the Rock64 running 2022.10 without issues.
On your advice, I tested these as well 2022.10 and 2023.1. seems to work when the patches are applied. However, still no misc_init():
initcall sequence 000000007ffcf0b0 failed at call 0000000000202ff8 (err=-1) ### ERROR ### Please RESET the board ###
in the map file I see this points to misc_init() but I guess your advice already obsoletes my statement, it's only "2023.04-rc1" now. make oldconfig seems to be a bad idea, simply defconfig and make modifications again seems to be a much safer choice.
Any way I could help fixing the misc_init_f()?
Try with CONFIG_ROCKCHIP_EFUSE disabled. misc_init_f will try to read cpuid from efuse/otp and use that to have a persistent ethaddr, should probably not hard fail when there is no efuse/otp to read cpuid from.
Regards, Jonas
kind regards,
Janpieter Sollie
I think we'd better close the discussion here. Whether keeping misc_init_r() is useful for the rockchip boards is up to the devs, not to me. If anyone would like to take a look at my modifications to make u-boot 2023.1 run on my nanopi neo3, that would maybe be helpful for other ones.
Kind regards,
Janpieter Sollie
diff --git a/arch/arm/dts/rk3328-nanopi-r2s.dts b/arch/arm/dts/rk3328-nanopi-r2s.dts index 3857d487ab..914b085e64 100644 --- a/arch/arm/dts/rk3328-nanopi-r2s.dts +++ b/arch/arm/dts/rk3328-nanopi-r2s.dts @@ -166,6 +166,35 @@ }; };
+&saradc { + status = "okay"; +}; + +&efuse { + status = "okay"; +}; + + +&spi0 { + status = "okay"; + + spiflash@0 { + compatible = "jedec,spi-nor"; + reg = <0>; + +// maximum speed for Rockchip SPI + spi-max-frequency = <50000000>; + }; +}; + +&rng { + status = "okay"; +}; + +&pdm { + status = "okay"; +}; + &i2c1 { status = "okay";
@@ -400,6 +429,7 @@ }; };
+ &usb_host0_ehci { status = "okay"; };
diff --git a/arch/arm/dts/rk3328.dtsi b/arch/arm/dts/rk3328.dtsi index 27e45d5886..5e7f0f7db9 100644 --- a/arch/arm/dts/rk3328.dtsi +++ b/arch/arm/dts/rk3328.dtsi @@ -279,6 +279,17 @@ status = "disabled"; };
+ rng: rng@ff060000 { + compatible = "rockchip,cryptov1-rng"; + reg = <0x0 0xff060000 0x0 0x4000>; + + clocks = <&cru SCLK_CRYPTO>, <&cru HCLK_CRYPTO_SLV>; + clock-names = "clk_crypto", "hclk_crypto"; + assigned-clocks = <&cru SCLK_CRYPTO>, <&cru HCLK_CRYPTO_SLV>; + assigned-clock-rates = <150000000>, <100000000>; + status = "disabled"; + }; + grf: syscon@ff100000 { compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd"; reg = <0x0 0xff100000 0x0 0x1000>;
diff --git a/drivers/ram/rockchip/sdram_rk3328.c b/drivers/ram/rockchip/sdram_rk3328.c index 9c6798f816..5324ba8ed8 100644 --- a/drivers/ram/rockchip/sdram_rk3328.c +++ b/drivers/ram/rockchip/sdram_rk3328.c @@ -561,7 +561,7 @@ static int rk3328_dmc_of_to_plat(struct udevice *dev) __func__, ret); return ret; } - ret = regmap_init_mem(dev, &plat->map); + ret = regmap_init_mem(dev->node_, &plat->map); if (ret) printf("%s: regmap failed %d\n", __func__, ret); #endif diff --git a/drivers/spi/rk_spi.c b/drivers/spi/rk_spi.c index cb80be77ae..38e55a6dd5 100644 --- a/drivers/spi/rk_spi.c +++ b/drivers/spi/rk_spi.c @@ -566,3 +566,4 @@ U_BOOT_DRIVER(rockchip_rk3288_spi) = { };
DM_DRIVER_ALIAS(rockchip_rk3288_spi, rockchip_rk3368_spi) +DM_DRIVER_ALIAS(rockchip_rk3288_spi, rockchip_rk3328_spi)
diff --git a/drivers/spi/rockchip_sfc.c b/drivers/spi/rockchip_sfc.c index 851a648298..1037460f78 100644 --- a/drivers/spi/rockchip_sfc.c +++ b/drivers/spi/rockchip_sfc.c @@ -18,6 +18,7 @@ #include <linux/iopoll.h> #include <spi.h> #include <spi-mem.h> +#include <dm/device_compat.h>
/* System control */ #define SFC_CTRL 0x0
participants (4)
-
Jagan Teki -
Janpieter Sollie -
Jonas Karlman -
Peter Robinson