search

inindev / rockpi-4c-plus

debian arm64 linux for the rockpi 4c+
GNU General Public License v3.0
10 stars 0 forks source link

Latest Rock 4C+ not booting #2

Open gustav-heinrich opened 7 months ago

gustav-heinrich commented 7 months ago

Hi John,

first of all I'd like to thank you for sharing this repository with the public. You did an amazing job! Your scripts worked perfectly for my Rock 4 C+ boards so far.

However, apparently, with the most recent batch of boards I received, the images generated by your scripts do not boot anymore. The "official" Debian image available from Radxa [1], however, still works. Although, the new boards have the same revision as the old ones (v1.41), on can see some "minor differences".

Since I do not even receive output via the serial console, I assume that u-boot isn't really alive. To summarize what I've tested so far:

Do you have any idea, what I could try next? Is there anything I can provide that would help you help me?

Cheers and thanks G.

[1] https://github.com/radxa-build/rock-4c-plus/releases/download/20230312-1521/rock-4c-plus_debian_bullseye_kde_b55.img.xz

gustav-heinrich commented 6 months ago

Hi,

I've now built u-boot from the official Radxa repo [1]. Combining the three resulting binaries with the image generated by your build script make_debian_img.sh, results in an image that starts up successfully on the "new" Rock 4C+. However, I have the impression that startup time is a lot longer now...

Cheers G.

[1] https://github.com/radxa/rockchip-bsp

inindev commented 6 months ago

Do you suspect a bad u-boot with the latest image? You could apply the previous u-boot to the latest image after flashing:

https://github.com/inindev/rockpi-4c-plus/releases/tag/v12.0

sudo dd bs=4K seek=8 if=idbloader.img of=/dev/sdX conv=notrunc
sudo dd bs=4K seek=2048 if=u-boot.itb of=/dev/sdX conv=notrunc
gustav-heinrich commented 6 months ago

Hi John,

thanks a lot for your response!

Unfortunately, the previous u-boot does not boot either. Also the images yielded when building u-boot on the next branch do not work.

Having a look at the images with xxd, I noticed that the u-boot built from Radxa's repo [1] is U-Boot 2017.09 while yours is U-Boot 2023.04 (or U-Boot 2023.10-rc3 if one checks out the next branch). Kind of strange that a much older version of u-boot works on newer boards, while a newer one doesn't.

Based on this, I'm wondering, whether u-boot itself or some difference in the configuration causes the boot issue on my newer batch of boards...

[1] https://github.com/radxa/rockchip-bsp

zixzix commented 6 months ago

Hi John,

first of all I'd like to thank you for sharing this repository with the public. You did an amazing job! Your scripts worked perfectly for my Rock 4 C+ boards so far.

However, apparently, with the most recent batch of boards I received, the images generated by your scripts do not boot anymore. The "official" Debian image available from Radxa [1], however, still works. Although, the new boards have the same revision as the old ones (v1.41), on can see some "minor differences".

Since I do not even receive output via the serial console, I assume that u-boot isn't really alive. To summarize what I've tested so far:

  • Cloned the latest version of this repo and made a fresh debian image (sligt modifications to some of the URLs in make_debian_img.sh were necessary [v12.0 -> v12.0.1]). No success.
  • Built DTB and uboot from scratch using sh make_dtb.sh cp and sh make_uboot.sh cp and built a new image. No success.
  • Found commit radxa/u-boot@31b8524 and changed +CONFIG_SPL_FIT_SIGNATURE=y to +CONFIG_SPL_FIT_SIGNATURE=n in https://github.com/inindev/rockpi-4c-plus/blob/main/uboot/patches/0003-u-boot-config-for-the-rock-4c-plus.patch . No success.
  • Installed "official" Debian image [1]. Success, board boots. Serial console only outputs tons of @ instead of anything useful.
  • Took 50 4-k-blocks starting from offset 8 (4-k-blocks) out of the "official" Debian image and replaced idbloader.img with that. A small succes: The serial console receives the @s again. Board does not boot.
  • Tried to build u-boot from Radxa repository. Stuck here, because repo cotains some pre-compiled binaries. For x86 and I'm on an RPi at the moment.
  • Mounted the two root file systems and compared the contents of /boot. The are major differences...

Do you have any idea, what I could try next? Is there anything I can provide that would help you help me?

Cheers and thanks G.

[1] https://github.com/radxa-build/rock-4c-plus/releases/download/20230312-1521/rock-4c-plus_debian_bullseye_kde_b55.img.xz

Hello, I have exactly the same problem even with Armbian images. Is there any news or progress on this?

Thank you

gustav-heinrich commented 5 months ago

Hi,

I have some updates on this issue.

Meanwhile, I've managed to build u-boot from the Radxa repo [1]. I've then copied the three resulting files idbloader.img, uboot.img and trust.img to the existing image yielded by your script make_debian_img.sh (I used the offsets suggested in the Radxa wiki [2]). Using the resulting image, both the "old" as well as the "new" Rock 4C+ boot. However, now it takes a lot longer until my customized Plymouth splash screen shows and I have the impression that the startup time is longer.

While the serial console works for u-boot on the "old" board, it still shows @s on the new one.

Cheers G.

[1] https://github.com/radxa/rockchip-bsp [2] https://wiki.radxa.com/Rockpi4/dev/u-boot

gustav-heinrich commented 4 months ago

Hi,

I did some more research. I think that my "new" board has slightly different DDR chips...

Since I do not receive any output on the serial console on the "new" board, I assume that the boot process fails at a very early stage. Taking a look at [1] and comparing the flow chart with the source code of make_uboot.sh, I assume that you use what is called "Boot Flow 2" there (while the "official" images seem to be using "Boot Flow 1", i.e. a miniloader). "Boot Flow 2" uses a combination of SPL and TPL in idbloader.img and takes care of "ddr init". What do you think? Might there be a link between the slightly different RAM chips and u-boot failing to boot?

I saw that make_debian_img.sh uses ATF v2.8. Hoping that it might fix the issue, I've built v2.9 from the official sources and rebuilt u-boot using make_uboot.sh. However, the result is the same.

Cheers G.

[1] https://opensource.rock-chips.com/wiki_Boot_option#Boot_flow

gustav-heinrich commented 4 months ago

Hi,

in the meantime I've experimented with various different configurations and combinations of u-boot and Linux. None of them resulted in a working serial console for u-boot on the "new" board. One thing became clear, though. Apparently, only miniloader bootloader setups work on the "new" board. According to [1], "Rockchip miniloader may have better memory compatibility". Given that the two boards use different RAM chips, this seems plausible.

I've also opened a thread in Radxa's forum [1] asking which of the boards is the "newer" and which the "older" one.

Cheers G.

[1] https://github.com/radxa-repo/bsp/blob/main/u-boot/latest/fork.conf#L40 [2] https://forum.radxa.com/t/rock-4c-v1-41-different-hardware-revisions/20777