Matthijs Kooijman Posted November 9, 2022 Posted November 9, 2022 I just tried the official Jammy image on the Rock Pi S, which does not boot. Looking at serial, it halts after "Starting kernel ...". I've tried redownloading the image, burning it again and on a different SD card. I also tried the bullseye image, which *does* boot (which makes me believe this is not a hardware issue). Anyone with a Rock Pi S that could confirm my observation? This image failed to boot: Armbian_22.08.7_Rockpi-s_jammy_edge_5.19.16.img Serial output: rock-pi-s-fail.txt This image booted ok: Armbian_22.08.7_Rockpi-s_bullseye_edge_5.19.16.img Serial output: rock-pi-s-ok.txt Diff of serial output (up to Staring kernel... line): --- rock-pi-s-fail.txt 2022-11-09 12:40:03.199949846 +0100 +++ rock-pi-s-ok.txt 2022-11-09 12:58:16.937136391 +0100 @@ -52,7 +52,7 @@ BootCapSize=0 UserCapSize=29554MB FwPartOffset=2000 , 0 -StorageInit ok = 27839 +StorageInit ok = 27858 SecureMode = 0 Secure read PBA: 0x4 Secure read PBA: 0x404 @@ -70,7 +70,7 @@ No find bl32.bin Load uboot, ReadLba = 2000 Load OK, addr=0x600000, size=0x9dad0 -RunBL31 0x40000 @ 106200 us +RunBL31 0x40000 @ 106201 us ^AINFO: Preloader serial: 0 NOTICE: BL31: v1.3(release):30f1405 NOTICE: BL31: Built : 17:08:28, Sep 23 2019 @@ -108,8 +108,8 @@ 3045 bytes read in 5 ms (594.7 KiB/s) ## Executing script at 00500000 Boot script loaded from mmc 1 -176 bytes read in 5 ms (34.2 KiB/s) -23219213 bytes read in 986 ms (22.5 MiB/s) +176 bytes read in 4 ms (43 KiB/s) +19531454 bytes read in 831 ms (22.4 MiB/s) 31263232 bytes read in 1328 ms (22.5 MiB/s) 54638 bytes read in 9 ms (5.8 MiB/s) Failed to load '/boot/dtb/rockchip/overlay/rk3308-fixup.scr' @@ -117,15 +117,33 @@ ## Loading init Ramdisk from Legacy Image at 04000000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) - Data Size: 23219149 Bytes = 22.1 MiB + Data Size: 19531390 Bytes = 18.6 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 02800000 Booting using the fdt blob at 0x2800000 - Loading Ramdisk to 0c8fd000, end 0df21bcd ... OK + Loading Ramdisk to 0cc81000, end 0df2167e ... OK ERROR: reserving fdt memory region failed (addr=0 size=0 flags=0) - Loading Device Tree to 000000000c887000, end 000000000c8fcfff ... OK + Loading Device Tree to 000000000cc0b000, end 000000000cc80fff ... OK Starting kernel ... 0 Quote
Werner Posted November 9, 2022 Posted November 9, 2022 16 minutes ago, Matthijs Kooijman said: it halts after "Starting kernel ...". Increase verbosity to 7 in your /boot/armbianEnv.txt. Otherwise nobody knows what's going on inside. 0 Quote
Matthijs Kooijman Posted November 9, 2022 Author Posted November 9, 2022 Increasing verbosity to 7 did not change the output at all. AFAIU that option only increases verbosity of the kernel, not u-boot, right? Then maybe the kernel does not manage to start executing at all maybe? I doublechecked the serial settings in the boot.scr, which indeed point to ttyS0. I also tried setting `earlycon=on` in armbianEnv.txt, but that did not make a difference either... 0 Quote
Igor Posted January 5, 2023 Posted January 5, 2023 My test device is now pretty stable: ____ _ _ ____ | _ \ ___ ___| | ___ __ (_) / ___| | |_) / _ \ / __| |/ / '_ \| | \___ \ | _ < (_) | (__| <| |_) | | ___) | |_| \_\___/ \___|_|\_\ .__/|_| |____/ |_| Welcome to Armbian 23.02.0-trunk.0118 Jammy with Linux 5.15.86-rockchip64 No end-user support: untested automated build System load: 2% Up time: 48 min Memory usage: 23% of 473M IP: 10.0.30.152 CPU temp: 36°C Usage of /: 7% of 29G RX today: 100.7 KiB [ General system configuration (beta): armbian-config ] Last login: Sun Jan 1 14:03:19 2023 from 10.0.10.12 Spoiler 0 Quote
Matthijs Kooijman Posted January 10, 2023 Author Posted January 10, 2023 (edited) Prompted by your tests, I also did another test, maybe the problem has been fixed since then. IIUC you tested with images built from git master (are those autobuilt and available somewhere? I did not find them at https://www.armbian.com/rockpi-s/ or http://xogium.performanceservers.nl/archive/rockpi-s/nightly/), but I tested released versions only (but now I tested 22.11, before it was 22.08, hoping it would be fixed between those versions already). The images were downloaded two weeks ago or so, so maybe they are not the completely latest versions. Interestingly enough, I discovered that the regular cli image still does not boot (same behaviour and serial output), but the minimal version *does* boot. That's actually surprising, since I would expect both versions to share the same kernel and most of the initrd contents (maybe minimal has a bit less). This image fails to boot: Armbian_22.11.2_Rockpi-s_jammy_edge_6.0.10.img rock-pi-s-fail.txt This image boots Armbian_22.11.2_Rockpi-s_jammy_edge_6.0.10_minimal.img boot rock-pi-s-ok.txt Diff of serial output (up to Staring kernel... line): --- rock-pi-s-fail.txt 2023-01-10 11:40:36.181577309 +0100 +++ rock-pi-s-ok.txt 2023-01-10 11:41:44.916939972 +0100 @@ -9,7 +9,7 @@ Boot1 Release Time: Mar 24 2022 08:28:57, version: 1.36 ROM VER:0x56323030, 19 chip_id:330800,0 -ChipType = 0x13, 481 +ChipType = 0x13, 483 DPLL = 1300 MHz ...nandc_flash_init enter... No.1 FLASH ID:ff ff ff ff ff ff @@ -50,9 +50,9 @@ NeedKHz=40000KHz,clock=650000KHz SdmmcInit=0 0 BootCapSize=0 -UserCapSize=29554MB +UserCapSize=29844MB FwPartOffset=2000 , 0 -StorageInit ok = 27861 +StorageInit ok = 27952 SecureMode = 0 Secure read PBA: 0x4 Secure read PBA: 0x404 @@ -70,7 +70,7 @@ No find bl32.bin Load uboot, ReadLba = 2000 Load OK, addr=0x600000, size=0x994f8 -RunBL31 0x40000 @ 104386 us +RunBL31 0x40000 @ 105251 us ^AINFO: Preloader serial: 0 NOTICE: BL31: v1.3(release):30f1405 NOTICE: BL31: Built : 17:08:28, Sep 23 2019 @@ -87,7 +87,7 @@ INFO: SPSR = 0x3c9 -U-Boot 2022.04-armbian (Dec 23 2022 - 09:48:40 +0000) +U-Boot 2022.04-armbian (Dec 23 2022 - 09:41:50 +0000) Model: Radxa ROCK Pi S DRAM: 254 MiB @@ -105,27 +105,174 @@ mmc1 is current device Scanning mmc 1:1... Found U-Boot script /boot/boot.scr -3045 bytes read in 4 ms (743.2 KiB/s) +3045 bytes read in 6 ms (495.1 KiB/s) ## Executing script at 00500000 Boot script loaded from mmc 1 176 bytes read in 4 ms (43 KiB/s) -23208702 bytes read in 987 ms (22.4 MiB/s) -31273472 bytes read in 1327 ms (22.5 MiB/s) -54638 bytes read in 10 ms (5.2 MiB/s) +16449244 bytes read in 701 ms (22.4 MiB/s) +31273472 bytes read in 1329 ms (22.4 MiB/s) +54638 bytes read in 11 ms (4.7 MiB/s) Failed to load '/boot/dtb/rockchip/overlay/rk3308-fixup.scr' Moving Image from 0x680000 to 0x800000, end=2670000 ## Loading init Ramdisk from Legacy Image at 04000000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) - Data Size: 23208638 Bytes = 22.1 MiB + Data Size: 16449180 Bytes = 15.7 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 02800000 Booting using the fdt blob at 0x2800000 - Loading Ramdisk to 0c904000, end 0df262be ... OK + Loading Ramdisk to 0cf76000, end 0df25e9c ... OK ERROR: reserving fdt memory region failed (addr=0 size=0 flags=0) - Loading Device Tree to 000000000c88e000, end 000000000c903fff ... OK + Loading Device Tree to 000000000cf00000, end 000000000cf75fff ... OK Starting kernel ... Surprisingly, the diff is bigger then between the bullseye and jammy builds in my original posts. I'll see if I can build a cli an minimal image from git master myself to see if those boot normally or not. Edited January 10, 2023 by Matthijs Kooijman 0 Quote
Matthijs Kooijman Posted January 11, 2023 Author Posted January 11, 2023 Building a git master "cli" image does seem to boot. E.g. with this commandline: ./compile.sh docker BOARD=rockpi-s BRANCH=edge RELEASE=jammy BUILD_DESKTOP=no BUILD_MINIMAL=no KERNEL_ONLY=no KERNEL_CONFIGURE=no and armbian-build master 21186c0577c39699e04949366f094bda54960729, I built Armbian_23.02.0-trunk_Rockpi-s_jammy_edge_6.1.4.img which boots as expected. Building 22.11.2 locally also shows the same problem (does not boot). E.g. with this commandline: ./compile.sh docker BOARD=rockpi-s BRANCH=edge RELEASE=jammy BUILD_DESKTOP=no BUILD_MINIMAL=no KERNEL_ONLY=no KERNEL_CONFIGURE=no REPOSITORY_INSTALL=kernel,u-boot ./compile.sh docker BOARD=rockpi-s BRANCH=edge RELEASE=jammy BUILD_DESKTOP=no BUILD_MINIMAL=no KERNEL_ONLY=no KERNEL_CONFIGURE=no REPOSITORY_INSTALL=kernel,u-boot and armbian-build v22.11 e323753fe7fb26f833dbfeab94351b38fe97550d, I built Armbian_22.11.2_Rockpi-s_jammy_edge_6.0.10.img which does not boot like the official builds. Note that I used REPOSITORY_INSTALL here, since a locally-built kernel failed for some reason (net/bluetooth/hci_sync.c:3442:42: error: ‘HCI_QUIRK_BROKEN_PARK_LINK_STATUS’ undeclared.), which I have not further investigated. Building git master with prebuilt kernel and u-boot does *not* boot: ./compile.sh docker BOARD=rockpi-s BRANCH=edge RELEASE=jammy BUILD_DESKTOP=no BUILD_MINIMAL=no KERNEL_ONLY=no KERNEL_CONFIGURE=no REPOSITORY_INSTALL=kernel,u-boot and armbian-build master 21186c0577c39699e04949366f094bda54960729, I built Armbian_23.02.0-trunk_Rockpi-s_jammy_edge_6.0.10.img which fails to boot again. Note that the kernel is actually different from the self-built master version, which got 6.1.4. This suggests that the problem is in the kernel, and 6.0.10 kernel is broken and 6.1.4 fixed it, except that the problem also occurred with 5.19.16 jammy, but that same kernel worked with bullseye (so at least there is more than just the kernel involved). Doing the same built with just REPOSITORY_INSTALL=kernel (so rebuilding u-boot) also fails, removing REPOSITORY_INSTALL entirely again (so the same built as the first one in this post), things boot again, confirming that the difference is not in something that has been cached along the way. Conclusion: Likely the problem has been fixed in git master. I'll retest the official images once 23.02 is released (if I remember...). 1 Quote
Igor Posted January 11, 2023 Posted January 11, 2023 On 1/10/2023 at 11:54 AM, Matthijs Kooijman said: That's actually surprising Indeed. I would bet we have some undetected error in CI build process ... We are putting hopes to bring up armbian-next up as soon as possible as this will also give improved error detection and logging. In case you manage, welcome. Thank you for your input. 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.