Rock Pi 4SE does not boot

MrDadoo commented 1 year ago

Describe the issue you are experiencing

I flashed (BalenaEtcher) haos_rockpi-4b-plus-9.5.dev20230129.img.xz on two different SD cards. With neither of them my ROCK Pi 4 SE started the boot process.... (Blue led didnt light up and nothing on console).

What operating system image do you use?

generic-x86-64 (Generic UEFI capable x86-64 systems)

What version of Home Assistant Operating System is installed?

-

Did you upgrade the Operating System.

Yes

Steps to reproduce the issue

Flashed (BalenaEtcher) haos_rockpi-4b-plus-9.5.dev20230129.img.xz to SD card
Insert card in ROCK Pi 4 SE
Power up ... Nothing happens.

Anything in the Supervisor logs that might be useful for us?

Anything in the Host logs that might be useful for us?

System information

No response

Additional information

-

citruz commented 1 year ago

The image is compressed with xz, did you uncompress it before flashing?

MrDadoo commented 1 year ago

Well, BalenaEtcher performs the decompression for me.

citruz commented 1 year ago

Ah ok. I assume by “nothing on console” you mean HDMI? Do you have a USB to serial adapter?

citruz commented 1 year ago

There was someone on the HAOS discord with an 4SE and for them it booted up correctly 🤔 Please also try the 9.4 image.

MrDadoo commented 1 year ago

Yes, I ment hdmi didn’t know I could have an usb-serial adapter. But, should the blue led be lit when boot process starts?

MrDadoo commented 1 year ago

I connected to the serial port on the ROCK Pi. Output during boot is as follows:

U-Boot TPL 2022.01 (Jan 29 2023 - 16:21:38) Channel 0: col error Cap error! Channel 1: col error Cap error! 256B stride lpddr4_set_rate: change freq to 400000000 mhz 0, 1 lpddr4_set_rate: change freq to 800000000 mhz 1, 0 Trying to boot from BOOTROM Returning to boot ROM...

When starting up a ROCK provided Ubuntu image, the console looks as follows

U-Boot TPL 2022.01 (Jan 29 2023 - 16:21:38) Channel 0: LPDDR4, 50MHz BW=32 Col=9 Bk=4 CS0 Row=13/15 CS=1 Die BW=16 Size=48MB Channel 1: col error Cap error! no stride lpddr4_set_rate: change freq to 400000000 mhz 0, 1 lpddr4_set_rate: change freq to 800000000 mhz 1, 0 ÿÿÿÿÿÿÿDDR Version 1.20 20190314 In channel 0 CS = 0 MR0=0xB8 MR4=0x1 MR5=0x13 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0xFF channel 1

Hopefully this can give a clue about whats happening (or not).

To me, the output "Channel 0: LPDDR4, 50MHz" for the Ubuntu SD card it looks like Channel 0 referrs to RAM circuits and that the memory cannot be found when using hhe haos SD card...

MrDadoo commented 1 year ago

Please also try the 9.4 image.

Tested, but it behaves the same

citruz commented 1 year ago

But, should the blue led be lit when boot process starts?

Also to my surprise, that is something that Armbian/Ubuntu seem to have added and not a feature of the board. For HAOS, the blue led will not flash.

Indeed the boot logs are very interesting.

To me, the output "Channel 0: LPDDR4, 50MHz" for the Ubuntu SD card it looks like Channel 0 referrs to RAM circuits and that the memory cannot be found when using hhe haos SD card...

Agree that this is about the RAM. Although, 50MHz is wayyy to low. This should be 400MHz. Also, even in the second log the channel 1 has as error which should not be the case.

Another thing is throwing me off. Both logs have the exact same timestamp U-Boot TPL 2022.01 (Jan 29 2023 - 16:21:38) which seems to suggest that in the second log still the bootloader of the HAOS image was used? Do you have any other bootable media connected at the same time? emmc for example

MrDadoo commented 1 year ago

First I'd like to applogize for flooding this comment thread. Its the first time I dig into the boot process of embedded computers.

I posted wrong output from the running "Ubutntu" image above. I cut-n-patsted to many rows. The output from the boot process up till the point where U-Boot starts looks like this. (Long one)

Here we see that the first output line is " DDR Version 1.20 20190314"

To me it seems that when the haos image boots, it goes directly into U-Boot and skipping the hardware initialization part.

I've looked at the sd card partion structures on both the haos and ubuntu images and they looks verry differnt, Where would I expect to find the entrypoint that the bootrom code starts using the SD card image?

Do you have any other bootable media connected at the same time? emmc for example

No. The 4SE comes without both SPI Flash and eMMC. No additoinal eMMC is mounted.

Now, the log from Ubuntu image boot up until U-Boot ...

DDR Version 1.20 20190314 In channel 0 CS = 0 MR0=0xB8 MR4=0x1 MR5=0x13 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0xFF channel 1 CS = 0 MR0=0xB8 MR4=0x1 MR5=0x13 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0xFF channel 0 training pass! channel 1 training pass! change freq to 400MHz 0,1 channel 0 CS = 0 MR0=0xB8 MR4=0x1 MR5=0x13 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0xFF channel 1 CS = 0 MR0=0xB8 MR4=0x1 MR5=0x13 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0xFF channel 0 training pass! channel 1 training pass! change freq to 800MHz 1,0 Channel 0: LPDDR4,800MHz Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB Channel 1: LPDDR4,800MHz Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB 256B stride ch 0 ddrconfig = 0x101, ddrsize = 0x40 ch 1 ddrconfig = 0x101, ddrsize = 0x40 pmugrf_os_reg[2] = 0x32C1F2C1, stride = 0xD OUT Boot1: 2019-03-14, version: 1.19 CPUId = 0x0 ChipType = 0x10, 250 mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000 mmc: ERROR: Card did not respond to voltage select! emmc reinit mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000 mmc: ERROR: Card did not respond to voltage select! emmc reinit mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000 mmc: ERROR: Card did not respond to voltage select! SdmmcInit=2 1 mmc0:cmd5,20 SdmmcInit=0 0 BootCapSize=0 UserCapSize=30436MB FwPartOffset=2000 , 0 StorageInit ok = 54635 SecureMode = 0 SecureInit read PBA: 0x4 SecureInit read PBA: 0x404 SecureInit read PBA: 0x804 SecureInit read PBA: 0xc04 SecureInit read PBA: 0x1004 SecureInit read PBA: 0x1404 SecureInit read PBA: 0x1804 SecureInit read PBA: 0x1c04 SecureInit ret = 0, SecureMode = 0 atags_set_bootdev: ret:(0) GPT part: 0, name: loader1, start:0x40, size:0x1f40 GPT part: 1, name: loader2, start:0x4000, size:0x2000 GPT part: 2, name: trust, start:0x6000, size:0x2000 GPT part: 3, name: boot, start:0x8000, size:0x100000 GPT part: 4, name: rootfs, start:0x108000, size:0x3a69c60 no find partition:uboot. LoadTrust Addr:0x4000 No find bl30.bin No find bl32.bin Load uboot, ReadLba = 2000 hdr 0000000003380880 + 0x0:0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,

Load OK, addr=0x200000, size=0xf1b44 RunBL31 0x10000 NOTICE: BL31: v1.3(debug):0e7a845 NOTICE: BL31: Built : 16:13:46, Apr 17 2019 NOTICE: BL31: Rockchip release version: v1.1 INFO: GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3 INFO: Using opteed sec cpu_context! INFO: boot cpu mask: 0 INFO: plat_rockchip_pmu_init(1181): pd status 3e INFO: BL31: Initializing runtime services WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK ERROR: Error initializing runtime service opteed_fast INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x200000 INFO: SPSR = 0x3c9

U-Boot 2017.09-00026-g2431fa34678 (Feb 14 2022 - 21:41:40 +0800)

citruz commented 1 year ago

First I'd like to applogize for flooding this comment thread. Its the first time I dig into the boot process of embedded computers.

No worries at all. I am pretty new to this as well. What helped me tremendously in understanding the boot flow was this page: https://opensource.rock-chips.com/wiki_Boot_option#Boot_flow

It also explains why the boot log looks completely different between the Rock provided Ubuntu image and HAOS. There are using a very different boot flow, see the graphic comparing "Flow 1" and "Flow 2". The first one is essentially the "vendor boot chain" which uses proprietary firmware blobs by rockchip to initialize the low-level hardware and then jumps into U-Boot which "only" takes are of locating and loading the linux kernel.

Flow 2 is the "opensource boot chain" which this project uses. It does not rely on proprietary firmware blobs but uses the ARM trusted firmware instead (usually abbreviated as ATF). In this case, U-Boot is used as a first- and second-stage boot loader (TPL, SPL) which embeds the ATF for low-level initialization (see https://u-boot.readthedocs.io/en/latest/develop/spl.html). It finally jumps into U-Boot "proper" to do the actual kernel loading.

For reference, this is what a successful boot should look like (with annotations by me):

U-Boot TPL 2022.10 (Feb 04 2023 - 13:53:58)     <- first-stage bootloader
lpddr4_set_rate: change freq to 400MHz 0, 1       <- RAM initialization (see the 400MHz and two channels)
Channel 0: LPDDR4, 400MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
Channel 1: LPDDR4, 400MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
256B stride
lpddr4_set_rate: change freq to 800MHz 1, 0
Trying to boot from BOOTROM    <- TPL hands off to SPL
Returning to boot ROM...

U-Boot SPL 2022.10 (Feb 04 2023 - 13:53:58 +0000)   <- second-stage bootloader
Trying to boot from MMC2
NOTICE:  BL31: v2.8(release):76a7e48                <- BL31 is part of ATF, also low-level init
NOTICE:  BL31: Built : 13:53:34, Feb  4 2023

U-Boot 2022.10 (Feb 04 2023 - 13:53:58 +0000)    <- U-Boot proper

Model: Radxa ROCK Pi 4B
DRAM:  2 GiB
PMIC:  RK808 
Core:  282 devices, 29 uclasses, devicetree: separate
MMC:   mmc@fe310000: 2, mmc@fe320000: 1, mmc@fe330000: 0
Loading Environment from MMC...
In:    serial
Out:   vidconsole
Err:   vidconsole
Model: Radxa ROCK Pi 4B
Net:   eth0: ethernet@fe300000
Hit any key to stop autoboot:  2 ... 1 ... 0 
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:1...
Found U-Boot script /boot.scr
3181 bytes read in 5 ms (621.1 KiB/s)
## Executing script at 00500000
switch to partitions #0, OK
mmc1 is current device
loading env...

MMC read: dev # 1, block # 1214464, count 64 ... 64 blocks read: OK
loading environment from haos-config.txt
91 bytes read in 2 ms (43.9 KiB/s)
60 bytes read in 3 ms (19.5 KiB/s)
Loading standard device tree rk3399-rock-pi-4b-plus.dtb
56358 bytes read in 7 ms (7.7 MiB/s)
Trying to boot slot A, 2 attempts remaining. Loading kernel ...
36338176 bytes read in 1403 ms (24.7 MiB/s)
storing env...

MMC write: dev # 1, block # 1214464, count 64 ... 64 blocks written: OK
Starting kernel with args zram.enabled=1 zram.num_devices=3 apparmor=1 security=apparmor systemd.machine_id=cdc0c77d5ca54dc1ab377f0ab3ab52e9 fsck.repair=yes root=PARTUUID=8d3d53e3-6d49-4c38-8349-aff6859e82fd rootfstype=squashfs ro rootwait rauc.slot=A earlycon=uart8250,mmio32,0xff1a0000 console=ttyS2,1500000n8
Moving Image from 0x2080000 to 0x2200000, end=4540000
 ## Flattened Device Tree blob at 01f00000
   Booting using the fdt blob at 0x1f00000
   Loading Device Tree to 0000000079ea4000, end 0000000079f1afff ... OK

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]

citruz commented 1 year ago

Unfortunately, that doesn't bring us closer to solving your boot issue. I am just trying to explain why I think it should boot (as it did for others with a 4SE) even if the boot logs look very different from a Rock-provided image.

Somehow the memory initialization seems to fail and then the transition from TPL to SPL does not work.

I just released a new version with updated U-Boot. You can try that and upload the logs here.

citruz commented 1 year ago

Just out of curiosity, you can try to boot Armbian and see what the boot log looks like: https://www.armbian.com/rockpi4/ They recommend to use the 4B build if you have a 4SE.

MrDadoo commented 1 year ago

Thanx allot for your explanation above.

I'm glad to tell you that the latest haos_rockpi-4b-plus-9.5.dev20230204.img.xz my 4 SE board booted all the way into ha.

Thanks for your effort and I can't wait to try the miniloader and start using my nvme drive. Though, I have to get a SPI Flash first and solder to the board. eMMC modules seems to be imposible to find at the moment.

haos_rock boot sequence below

U-Boot TPL 2022.10 (Feb 04 2023 - 13:53:58)
lpddr4_set_rate: change freq to 400MHz 0, 1
Channel 0: LPDDR4, 400MHz
BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
Channel 1: LPDDR4, 400MHz
BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
256B stride
lpddr4_set_rate: change freq to 800MHz 1, 0
Trying to boot from BOOTROM
Returning to boot ROM...

U-Boot SPL 2022.10 (Feb 04 2023 - 13:53:58 +0000)
Trying to boot from MMC1

U-Boot 2022.10 (Feb 04 2023 - 13:53:58 +0000)

Model: Radxa ROCK Pi 4B
DRAM:  3.9 GiB
PMIC:  RK808
Core:  282 devices, 29 uclasses, devicetree: separate
MMC:   mmc@fe310000: 2, mmc@fe320000: 1, mmc@fe330000: 0
Loading Environment from MMC... Card did not respond to voltage select! : -110
*** Warning - No block device, using default environment

In:    serial
Out:   serial
Err:   serial
Model: Radxa ROCK Pi 4B
Net:   eth0: ethernet@fe300000
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:1...
Found U-Boot script /boot.scr
3264 bytes read in 4 ms (796.9 KiB/s)
## Executing script at 00500000
switch to partitions #0, OK
mmc1 is current device
loading env...

MMC read: dev # 1, block # 1214464, count 64 ... 64 blocks read: OK
loading environment from haos-config.txt
91 bytes read in 3 ms (29.3 KiB/s)
60 bytes read in 3 ms (19.5 KiB/s)
Loading standard device tree rk3399-rock-pi-4b-plus.dtb
56358 bytes read in 6 ms (9 MiB/s)
Trying to boot slot A, 2 attempts remaining. Loading kernel ...
36551168 bytes read in 1373 ms (25.4 MiB/s)
storing env...

MMC write: dev # 1, block # 1214464, count 64 ... 64 blocks written: OK
Starting kernel with args zram.enabled=1 zram.num_devices=3 apparmor=1 security=                                      apparmor systemd.machine_id=28fdfae325b844669cd65a84b721b4c0 fsck.repair=yes roo                                      t=PARTUUID=8d3d53e3-6d49-4c38-8349-aff6859e82fd rootfstype=squashfs ro rootwait                                       rauc.slot=A earlycon=uart8250,mmio32,0xff1a0000 console=ttyS2,1500000n8
Moving Image from 0x2080000 to 0x2200000, end=4570000
## Flattened Device Tree blob at 01f00000
   Booting using the fdt blob at 0x1f00000
   Loading Device Tree to 00000000f1ea4000, end 00000000f1f1afff ... OK

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[    0.000000] Linux version 5.15.90 (builder@efbdc569a02a) (aarch64-buildroot-l                                      inux-gnu-gcc.br_real (Buildroot -g14dcc6f7) 9.4.0, GNU ld (GNU Binutils) 2.36.1)                                       #1 SMP PREEMPT Sat Feb 4 13:56:33 UTC 2023
[    0.000000] Machine model: Radxa ROCK Pi 4B+

citruz commented 1 year ago

Well... I did not expect that, but glad that it works now! The next improvement I want to do is to create specific builds for the different Rock Pi boards with the correct devicetree so that the model and CPU frequencies are reported correctly. Would be nice if you could test the 4SE build then.

KrickGregory commented 1 year ago

I have the 4se too and works for me with build 9.5. Thank you.

citruz commented 1 year ago

I just published a beta release which includes an upgrade to a much more recent kernel version and specific images for the 4SE and other boards. Please give this release a try and let me know if it works. https://github.com/citruz/haos-rockpi/releases/tag/9.5%2B20230212beta

citruz / haos-rockpi