Rock PI 4 A not starting

[raidboy]

The following image boots fine from microSD card on my RockPI4a (2GByte):

 

https://dl.radxa.com/rockpi/images/third-party/Armbian_5.67_Rockpi4b_Debian_stretch_default_4.4.154_desktop_20181210-gpt.img.gz

 

Unfortunately, that images' kernel does not seem to include an AHCI driver, so it does not find the 5 SATA port miniPCIe controller. i am using. That controller is working (mostly) fine with the Radxa provided 4.4.100 debian kernel though.

 

So, i tried to install the following current images:

 

https://dl.armbian.com/rockpi-4a/Buster_current

https://dl.armbian.com/rockpi-4a/archive/Armbian_19.11.5_Rockpi-4a_buster_current_5.4.6.7z

 

On both of them, the board will not boot. Console output stops after "no trust IMG", and HDMI never has signal.

 

I do not understand the uboot process, so i can not figure out how to analyze what should happen during bootstrap and whats wrong with the images. Pointers to documentation welcome. Maybe there is something wrong with the image building first stage bootloader or the like.

[Igor]

2 hours ago, raidboy said:

and HDMI never has signal.

There is a long boot delay ATM with kernels 5.4.y ... how long do you wait?

 

2 hours ago, raidboy said:

I do not understand the uboot proces

http://opensource.rock-chips.com/wiki_Boot_option

[martinayotte]

2 hours ago, raidboy said:

On both of them, the board will not boot. Console output stops after "no trust IMG", and HDMI never has signal.

Is your RockPi4B equipped with eMMC ?

Because on any RK3399 boards, the boot priority is eMMC over SDCard, maybe the "no trust IMG" is coming from eMMC U-Boot that doesn't like Armbian SDCard.

Unplug the eMMC modules and try Armbian SDCard alone to see if it is booting properly ...

[raidboy]

19 minutes ago, Igor said:

There is a long boot delay ATM with kernels 5.4.y ... how long do you wait?

Maybe 10 minutes.

 

Do you know if the console output is supposed to work in the armbian 5.x kernels ? Because if it is supposed to work, then its clear that its broken early in bootstrap: No console output. If console output is not working, then yes, the wait would be necessary, but see above..

[raidboy]

13 minutes ago, martinayotte said:

Is your RockPi4B equipped with eMMC ?

Because on any RK3399 boards, the boot priority is eMMC over SDCard, maybe the "no trust IMG" is coming from eMMC U-Boot that doesn't like Armbian SDCard.

Unplug the eMMC modules and try Armbian SDCard alone to see if it is booting properly ...

Yes, the rockpi4a (!) is equipped with eMMC, but my experience was that uSD takes precendence over eMMC - at least on my board.

The eMMC has the working 4.4 debian kernel from radxa, everything working with the disks except for see above (idling disks crashes system).

 

When i ALSO insert a uSD an power cycle, the rockpi4a will  boot from the uSD first, for example with the working armbian 4.4 image from radxa server (my first URL). 

 

Of course, there may be more complications in the bootstrap process that i don't understand, but removing eMMC is really not an option anymore on this board, its inside the raid case with heatsink and M.2 adapter. It's already terrible difficult to squeeze the uSD into its slot because thats now hidden behind the PCI extension cable. Waiting for an uSD extension cable/board *sigh*.

 

Would be lovely to have a way to boot the board remotely, e.g.: without plugging/rewriting modules. Any netboot option ?

[Igor]

7 minutes ago, raidboy said:

but my experience was that uSD takes precendence over eMMC - at least on my board.

Study manual.

 

8 minutes ago, raidboy said:

When i ALSO insert a uSD an power cycle, the rockpi4a will  boot from the uSD first

Boot still starts on eMMC where they implement a hack that it loads kernel from elsewhere first if exists. We did the same with MiQi back in the days.

 

10 minutes ago, raidboy said:

Would be lovely to have a way to boot the board remotely, e.g.: without plugging/rewriting modules. Any netboot option ?

 

Yes if there is support for network card in the u-boot that resist on SPI. Start R&D to find out if that is true and implement that to build script that others will benefit from your work. I hope you don't expect we will do that for you?

 

Moving to DEV zone.

[Igor]

Added notification "Kernel 5.4.y is currently broken" with a link to this thread at the download pages of https://www.armbian.com/rock-pi-4/ 

[martinayotte]

5 minutes ago, raidboy said:

Yes, the rockpi4a (!) is equipped with eMMC, but my experience was that uSD takes precendence over eMMC - at least on my board.

No ! Not true ! Trust me, or as Igor said, read the Rockchip datasheets !

All RK3399, as well as any other Rockchip SoC, are loading U-Boot from eMMC first.

The fact that some boards is looking at SDCard is simply that this U-Boot loaded from eMMC is checking for SDCard with specific format, partitions, or uEnv.ini, and then continue boot process from SDCard.

[raidboy]

9 minutes ago, Igor said:

Study manual.

 

Boot still starts on eMMC where they implement a hack that it loads kernel from elsewhere first if exists. We did the same with MiQi back in the days.

 

 

Yes if there is support for network card in the u-boot that resist on SPI. Start R&D to find out if that is true and implement that to build script that others will benefit from your work. I hope you don't expect we will do that for you?

 

Moving to DEV zone.

 

Thanks!

 

Wrt. "study manuals" - yes, thats what i am trying to do, but there is no good description of the boot process, especially priority of diffeent media over each other on the radxa wiki, or if there is, i have not found it. But once i understand it, i am happy to improve the text.

 

The rockchip URL provides a lot of detail, but i would not even know without additional documentation from another place or RTFS on my behalf whether the rock pi 4 uses the red or the blue path.

 

But the explanation you provided about some form of hack might be an explanation of the problem i am seeing: If my 4.4 debian eMMC system actually boots some initial boot stage(s) from eMMC, and one of those stages then looks at the uSD and continues to boot from there, then this could explain why  this might work with a 4.4 armbian in the uSD slot, but not a 5.x in the uSD slot.

 

Which stage has this hack that looks first at uSD ? And do you have any idea if it could be that that hack could only continue to boot then from uSD a 4.4 system, but maybe not a 5.x one ?

 

Btw: The note you said you added to the rock pi 4 page may not be correct. Even if the problem is not only because of me also having an eMMC card, its probably more an IMG issue and not a kernel issue (unless the kenel is booting but i can not see it on the console because its not correctly supporting the console).

 

 

[Igor]

36 minutes ago, raidboy said:

The rockchip URL provides a lot of detail, but i would not even know without additional documentation from another place or RTFS on my behalf whether the rock pi 4 uses the red or the blue path.

 

Don't expect quick understanding. We needed weeks of studying (with lots of experiences) before we were able to more or less understand and implement that to our build engine. Even today not everything is straight forward. There are different ways of booting, different memory require different settings. Some have troubles here, some there. On our forum you will find a lot of the information. Focus on the chip - board differences are safe to ignore.

 

36 minutes ago, raidboy said:

But the explanation you provided about some form of hack might be an explanation of the problem i am seeing: If my 4.4 debian eMMC system actually boots some initial boot stage(s) from eMMC, and one of those stages then looks at the uSD and continues to boot from there, then this could explain why  this might work with a 4.4 armbian in the uSD slot, but not a 5.x in the uSD slot.

 

36 minutes ago, raidboy said:

Which stage has this hack that looks first at uSD

Modern kernel might have completely different way of booting, but it can also be just different u-boot initial scripting. Which is considered as a minor, distro specific settings. Distro in this case is not Debian, but "Radxa (Debian) image". I gave you just an approximation since I don't recall/know what is the exact case without research. But yes, this explains why.

 

37 minutes ago, raidboy said:

The note you said you added to the rock pi 4 page may not be correct. Even if the problem is not only because of me also having an eMMC card, its probably more an IMG issue and not a kernel issue

Yes, not entirely because it probably works without eMMC (tests were only run on B model). It's good enough information for now  - it saves support expense until this is not somehow fixed. If you care about, this way we do it: 

 

[chwe]

blind-shot to try to debug doesn't make sense. Without the (full) console log it doesn't make sense to step into this. So first, make sure you connect to the right UART to get the debug output.

For the bootorder:

https://lists.denx.de/pipermail/u-boot/2017-April/285493.html

http://rockchip.wikidot.com/boot-sequence

(even when I'm not sure the second one is fully complete, I guess it's mostly achieved over the choosen node)

 

if you look at the sources of radxas bootloader, and we assume that's the one which is on your eMMC:

https://github.com/radxa/u-boot/blob/6d910b7f12318e5a5bb8d1b2093fe5a9ba17dfce/arch/arm/dts/rockpi-4b-linux.dts#L26

	chosen {
		stdout-path = &uart2;
		u-boot,spl-boot-order = &sdhci, &sdmmc;
	};

 

in their u-boot eMMC should have priority over SD card. If you now look on our bootloader:

	chosen {
		stdout-path = &uart2;
	};

it's not as clear anymore.. according to rockchip it should look in SD-Card first. But I could be that they achieve this over the choosen node, no idea what happens then if it's not defined there. Also their docs rely on their u-boot. We used a patched one based on theirs.. So another option where things can change. A bunch of variables and things go messy.

 

1 hour ago, raidboy said:

but removing eMMC is really not an option anymore on this board, its inside the raid case with heatsink and M.2 adapter. It's already terrible difficult to squeeze the uSD into its slot because thats now hidden behind the PCI extension cable. Waiting for an uSD extension cable/board *sigh*.

 

debugging your issue without a bootlog isn't a option for us. So either you can provide a full bootlog (and that starts a way earlier than when the kernel takes over) or you've to follow @martinayotte recommendation and remove the eMMC.

 

BTW for the rockchip maintainers here (adding @TonyMac32 @piter75) It might make sense to add a proper choosen node to all our DTS files to get a predictable bootorder for all RK3399 boards.

[raidboy]

Haha, nice pitch for maintainer positions. Alas, not enough time, and no spare new hardware to play around with.

 

I can contribute the predecessor HW to my rock pi 4 + miniPCI card, which is a banana pi M1 and a SATA port multiplier, but that is such old hardware, and i think almost not sold anymore (and Rock PI 4 + miniPCIE would be so much better if i'd get the one problem fixed).

And i guess one of your maintainers will already have a banana pi m1 given how you list it as supported.

[raidboy]

Thanks chwe for all the info. 

 

Alas, my Rock PI 4 setup isn't even at home, so i have to first figure out how i can continue troubleshooting given how it doesn't seem to be possible to do without physcial access. Aka: will probably want to see if i can get netboot to work, because then i could safely overwrite uSD/eMMC from remote.

[Igor]

1 hour ago, raidboy said:

not enough time

 

It doesn't convince me  We just save you a big chunk of it. You would waste weeks without guidance and hints.

[piter75]

28 minutes ago, chwe said:

blind-shot to try to debug doesn't make sense. Without the (full) console log it doesn't make sense to step into this.

Totally agree. This is the only way to get help in this case.

 

29 minutes ago, chwe said:

BTW for the rockchip maintainers here (adding @TonyMac32 @piter75) It might make sense to add a proper choosen node to all our DTS files to get a predictable bootorder for all RK3399 boards.

This crossed my mind before and I think it is a good idea.

We already have it in place for Rock Pi 4b (it was implemented before we had Rock Pi 4a as a separate board) and it works well when used with the same u-boot version on eMMC and SD.

 

@raidboy you can try to use Rock Pi 4b image which has priority set to SD and see if it works better in this scenario. Nothing is guaranteed as you are mixing stages of u-boots compiled with different configurations and even different code bases so... YMMV.

[raidboy]

15 hours ago, Igor said:

It doesn't convince me  We just save you a big chunk of it. You would waste weeks without guidance and hints.

 

Most likely, yes, but me trying to tinker with my toys is something i can do in the random spare time i have. Being maintainer requires small but more predictable longer term cycle allocation which is the issue.

 

I still have a banana to offer to the community   

[raidboy]

Here is a log when i attempted to boot an armbian 5.4.8 kernel off an installed radxa debian 4.4. May not be useful to anyone, but all i can do without physcial access to box right now.

 

really curious to me how it seems as if early printk seems to work, but no output beside a very late one.

bootlog.armbian5.4.test2.txt

[piter75]

6 hours ago, raidboy said:

early printk seems to work, but no output beside a very late one

Add loglevel=7 to kernel cmdline and you should see more output on the console

[martinayotte]

Yes ! It is defaulted to 1 i /boot/armbianEnv.txt ...

[raidboy]

1 hour ago, martinayotte said:

Yes ! It is defaulted to 1 i /boot/armbianEnv.txt ...

Indeed. Thanks. See below.

 

Seems to hang in a similar place as my self compiled debian kernel, after (in?) system clock setting.

 

But at least it seems as if i i can forget to understand the bootstrap process because it seems i should be able to just boot different kernels, debian/armbian. If the 5.x armbian kernel would not like the 4.4 filesystem, i could create another partition as a second root partition. 

 

On my running 4.4 debian, this is what follows after clock setting:

 

[    2.928947] I : [File] : drivers/gpu/arm/mali400/mali/linux/mali_kernel_linux.c; [Line] : 417; [Func] : mali_module_enit(); svn_rev_string_from_arm of this mali_ko is '', rk_ko_ver is '5', built at '11:59:48', on 'Dec 14 2019'.

[    2.931490] Mali: Mali device driver loaded

 

GPU initialization does of course look like a potentially difficult piece. Any kernel option to disable GPU ?

 

 

bootlog.armbian5.4.test3.txt

[raidboy]

Ok, got a second rockpi4a v1.4 1MB RAM, 32 MByte eMMC to play around with, and

 

 Armbian_20.02.0-rc1_Rockpi-4a_bionic_current_5.4.14_minimal.img

 

is booting fine

 

http://ix.io/2bgq

 

after fixing up the UEFI partition table. See:

 

I can not yet correlate this experience with the prior experience on my other production rockpi4 from the postings above, back on that system i also have 5 SATA HDD connected via a 5 port PCI adapter, whereas i have no optional components connected yet to this rockpi.