Armbian images do not boot on RockPi4a (with workaround)

[Molnár Gábor]

WIthout SD card, it boots normally, but if SD card is inserted, it won’t boot. On serial port, it is visible that there’s a crash right after the message that says something like “booting from eMMC”. The message includes the values of the registers IIRC. Then, something like “resetting CPU”, and it starts over: tries to boot from eMMC, crashes, etc. Sorry, I didn’t record the exact message, but there’s a chance I’ll re-flash the board in the next couple weeks and then I can provide the exact messages.

 

I’ve tested it with Bionic minimal with 5.4 kernel and buster server with 5.4 kernel. If I insert the SD card later, it’s fine. Also, the official ubuntu bionic server image from radxa works fine.

[raidboy]

https://dl.armbian.com/rockpi-4b/Bionic_legacy_desktop

https://dl.radxa.com/rockpi/images/debian/rockpi4-debian-stretch-desktop-arm64-20190730_2022-gpt.img.gz

(probably other images too, those are just the two i tried).

 

Both boot fine when installing/booting on RockPi4a via uSD.

Both fail to book when installing/booting on RockPI4a vie eMMC (32GByte).

 

Problem seems to be that bootloader on the rockpi4a seemingly does not want to boot from MBR partition table, but only from GUID partition table. When check the partition table on both of the above images, fdisk/gdisk report proper mbr partition table, gdisk also reports broken gpt header, backup header problems, etc. pp.

 

When i tried to fix up the disk images with zeroe'd space and ONLY mbr, it won't boot either, so IMHO no confusion.

When i fixed up the images to ONLY have GUID partition table, the images boot fine.

 

Note that radxa's own images do come with GUID partition table.

 

My rockpi4a is v1.4, and i am not 100% sure that it didn't work from the start, but maybe there was some upgrade of bootloader/sppi, or whatever, when i was playing around with the radxa debian images, so one time when i tried to start using armian, the images didn't boot anymore.

 

No idea how to further troubleshoot, e.g.: bootloader version or the like. Not sure the armbianmonitor output is of any help.

 

http://ix.io/2bgj

 

Btw: Why does armbian partition start at sector 32768 instead of usual sector 2048 ? I zeroed out the first 32768 sectors, and that didn't hurt the ability to boot, so doesn't seem as if there is any hidden bootstrap code. Instead, i was positively surprised i didn't need any magic boot code (like on x86), but just a clean GUID with the ext4 armbian partition to boot.

[Igor]

7 hours ago, raidboy said:

like on x86

 

7 hours ago, raidboy said:

When i tried to fix

This is not x86. Forget what you know from that world and start reading this forum and other related resources on the internet. We are somewhere between embedded and what you are used to.

 

7 hours ago, raidboy said:

Why does armbian partition start at sector 32768

 

https://www.google.com/search?q=rockchip+rk3399+boot+process

https://www.armbian.com/search

 

7 hours ago, raidboy said:

Problem seems to be that bootloader on the rockpi4a

Radxa SPI boot loader is their work - we don't provide it - but AFAIK it can boot (unchanged) Armbian and other images without issues.

 

I don't have Rockpi with SPI to be able to verify.

[piter75]

@raidboy are you using SPI to boot?

Can you provide the failed boot log from serial console?

[raidboy]

Boot from unchanged armbian image:

 

http://ix.io/2bjY
 

(trying to boot from ethernet at the end).

 

Working boot after replacing MBR with EUFI:

 

http://ix.io/2bk3
 

I have no clue about SPI. I just think to remember that booting from MBR on eMMC did work initially, but then i was experimenting with radxas debian installation, and when i installed something with "apt install ..." there was some dependency that took a long time, seemingly flashing something. Thats why i am thinking that i may now have some newer radxa firmware flashed than what the device was shipped with. But i couldn't find any webpage from where i could diagnose the situation ... I'll certainly ask on the radxa forum too.

 

Took me already the better part of sunday to figure out how to get armbian booting again. *sigh*.

 

[raidboy]

@igor: 

 

Are you telling me that the armbian images have stage 2 and stage 3 in the sectors before 32768 without showing them in the MBR partition table ? 

 

Looks to me as if what i am seeing on my rockpi4a looks more like what the documentation describes as boot from "u-disk" with armbian really being stage 4/5 from the single partition it has, and no stage 2/3 taken from the disk before.

 

I don't even know what a u-disk is.

 

[chwe]

10 hours ago, piter75 said:

@raidboy are you using SPI to boot?

Can you provide the failed boot log from serial console?

there's not much of a choice here..   SPI has priority over SD-Card/eMMC as long as there is a valid bootloader on it. From

2 hours ago, raidboy said:

http://ix.io/2bjY

U-Boot 2017.09-02676-g4490220395 (Jul 01 2019 - 07:49:56 +0000)

and

DDR Version 1.20 20190314

doesn't look like armbian bootloader being used.

 

I don't own a RockPi with SPI populated.. (additionally my SD-Card slot got damaged so that I can only use eMMC - don't let the SD-card inside when moving your board in your backpack in a box.. it will wipe off the card holder and there's so much plastic that you don't want to solder it after its.. )

 

I guess radxa has some debian packages to update SPI on their boards or send them with a preflashed version of their bootloader.

[piter75]

42 minutes ago, chwe said:

there's not much of a choice here

Wanted to be sure of that. It was not that long ago that we were chasing issues with OrangePi 4 not booting from Armbian with SD that had Xunlong's BSP image on that card before (because of secondary GPT) ;-)

 

Now it looks more clear and a bit unfortunate... ;-)

U-Boot 2017.09-02676-g4490220395 (Jul 01 2019 - 07:49:56 +0000)

The u-boot image is pretty ancient:

g4490220395 => https://github.com/radxa/u-boot/commit/44902203959cef9d92dff2f36896c7ec27fb3d88

in next commit Radxa added DOS partition support to it => https://github.com/radxa/u-boot/commit/59412e4610af669538a057995ed2d418703723a2

I have a later g674eaa57f0 in SPI and it boots Armbian fine  => https://github.com/radxa/u-boot/commit/674eaa57f03d48aa1803650a901f0244563eea60

Full history here: https://github.com/radxa/u-boot/commits/rk3399-pie-gms-express-baseline

 

Now the positive stuff...

@raidboy to boot Armbian images without creating GPT on them you can simply connect pin 23 with 25 (or any other GND/black) pin on GPIO header. This disables onboard SPI.

To erase the SPI you could use this guide: https://wiki.radxa.com/Rockpi4/dev/spi-install#Erase_images_on_SPI_device.

Writing zeroes with dd to /dev/mtdblock0 while being booted with Radxa's image should also do the trick ;-)

[raidboy]

Thanks, piter75. You are pointing me to good workarounds, but i think in the first place, radxa needs to explain what the forward going image format is that third party distributions like armbian should use and that will correctly bootstrap across all rockpi4 versions. Seems right now there is no such format and that would be a big pain for distros like armbian or others: you seem to require a standard rockchip setup for rockpi4a without SPI, and another one (UEFI, stage 2,3 on SPI) on v1.4 with som random new radxa code on the SPI. 

 

Just curious: Is there actually any benefit of having the u-boot stage 3 on the SD/eMMC card, e.g.: does it do any special cool things that the radxa u-boot wouldn't do ? Or is it just there because on rockpi4a without SPI its just mandatory to have _some_ u-boot version on the uSD/eMMC, but theres beside bug-fixes no real feature differences between those u-boot's.

 

Thanks!

[Igor]

15 minutes ago, raidboy said:

radxa needs to explain what the forward going image format is that third party distributions like armbian should use

 

Most likely the only solution is that we provide SPI boot loader with a simple method - which @piter75 is mentioning - how to update it and remove their software creations and troubles they are making. But AFAIK they fixed those problems - just shipped SPI boot loader is old and needs updating.

[raidboy]

But why shuold the current file format with MBR and phase 2/3 not continue to work whether SPI is or is not present ? Radxa would just have to fix up their SPI boot loader to recognize MBR and continue to boot from the phase 2/3 on the eMMC. Or for that matter, if there is really no benefit to execute the on-eMMC phase 2/3 (hence my question before) to boot directly into phase 4 on the eMMC as they seem to do now when they discover UEFI. I probably would prefer the latter, if the SPI boot code from radxa could try to find /boot on multiple partition and offer a menu on serial console or even graphics ;-) Then the OSs on those partitions wouldn't have to bother implementing that. Thats a typical platform firmware problem when they want to support multiple different OS simultaneously. Which at least for one partition linux, one partition android might be interesting to users.

 

Expecting third parties like armbian to do additional install magic like explaining to users what SPI is, how they need to feed and fix is, doesn't sound like a viable way to make users happy. 

[chwe]

All RockPi images were developed and tested for RockPi4b v1.3 boards which didn't had SPI populated back then (also one of the LEDs couldn't be toggled back then, but that's a different story). Having multiple images for RockPis alone is something which won't happen as long as it isn't absolutely needed. People can hardly distinguish between the boards they have.. If we have to explain them now that they have to choose a image depending on which preloaded u-boot they have.... We'll have more trouble to answer all those questions than benefits.

Also having "special images" for all RockPi compared to all other rk3399 boards is something which should not be needed (from a maintenance standpoint rk3399 is already "boated" enough, we do not need another 'special one' here).

 

@Igor maybe we should just link to this thread on the DL page for the RockPi (or to a short tutorial how to wipe SPI) so that users have the chance to see it when they download their images?

 

5 hours ago, raidboy said:

Radxa would just have to fix up their SPI boot loader to recognize MBR and continue to boot from the phase 2/3 on the eMMC.

 

5 hours ago, raidboy said:

Expecting third parties like armbian to do additional install magic like explaining to users what SPI is, how they need to feed and fix is, doesn't sound like a viable way to make users happy. 

that's better asked to them on their support channels..

[Igor]

7 minutes ago, chwe said:

maybe we should just link to this thread on the DL page for the RockPi

Done. Ideally would be to pack SPI boot loader inside our u-boot-rockpi deb package and perhaps provide update from armbian-config. And save users all the troubles. Just time is again the issue

[raidboy]

I have added SPI workaround to the radxa eMMC install wiki page:

https://wiki.radxa.com/Rockpi4/install/eMMC

 

Btw: I am wondering why Armbian isn't using GUID partition table. Was GUID partition table not working on older Radxa ?

[Igor]

1 hour ago, raidboy said:

I am wondering why Armbian isn't using GUID partition table. Was GUID partition table not working on older Radxa ?

Armbian is here for 7 years. Only last / this year this is becoming relevant. Only SPI boot is problematic, while our standard way of installing a system - boot from eMMC/SD and root on SSD / HDD ... doesn't care about partition type. It can be anything.

 

Providing as unique experiences across different hardware as possible is very important. For us and for you.

 

We should start thinking about this, agree ...

[raidboy]

Whatever is the image format that works on all rockpi variations with/without SPI and with least amount of work involved. Not changing what armbian does right now seems to depend on hoping that radxa fixes broken SPI code. Which i agree they should do, but not sure if they will.

[hipboi]

I think there is some misunderstanding here. Last time we checked, radxa u-boot in SPI with Armbian in NVMe can boot, with MBR. Maybe some boot order change in u-boot caused this? We will look into it.

[raidboy]

Thanks

This was booting from eMMC, not NVMe.

Some commands to verify the version of the software on SPI would be helpfull before i erase it, so that i can try the workaround but reproduce (save/restore SPI).

[raidboy]

Finally managed to verify the SPI assumption, and it is correct:

 

Boot radxa debian, e.g.: from SSD

% cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00400000 00001000 "loader"

This shows that there is a partition? on SPI.  When trying to do the same on Armbian, it will not show the partition.

 

Erase:

dd if=/dev/zero ob=/dev/mtdblock0 bs=512

Use first command to verify its erased.

 

Afterwards, normal armbian image with only MBR partition table will boot fine from eMMC.

The modified gpt partition image will still boot too.

[Molnár Gábor]

My topic (my February 9 post) was merged into this one but it turns it incorrectly. Now that I've debugged it, and can see my original problem more clearly, it was basically this: the problem I had in was that the idbloader.img (loaded from the eMMC) tries to boot the next stage (u-boot.itb) from the SD card, because of the patch in patch/u-boot/u-boot-rockchip64-dev/board_rockpi-4b/001-boot-order-prioritize-sd.patch and instead I wanted to boot all stages from the eMMC and use the SD card as storage. But if the SD card is present, armbian's idbloader tries to load later stages from there and then crashes. I'll attach what I've seen on the serial console, just for reference if someone has the same probem.

 

The solution was to simply delete the 001-boot-order-prioritize-sd.patch file and build the image like that. In that case, the whole boot sequence is loaded from the eMMC and I can use the SD card as storage.

armbian_boot_with_sd.txt

[piter75]

2 hours ago, Molnár Gábor said:

because of the patch in (...)/001-boot-order-prioritize-sd.patch (...) if the SD card is present, armbian's idbloader tries to load later stages from there and then crashes

The reason for this patch to exist is that it is difficult to remove / insert the eMMC module of RockPi 4 while installed with large heatsink and in general I think that SD should take precedence over eMMC in our tinkerers' world ;-)

Nonetheless I think your use case is valid and it would be great to have a solution that switches to SD only if it is actually bootable. It would then satisfy both cases.

[martinayotte]

4 hours ago, Molnár Gábor said:

the whole boot sequence is loaded from the eMMC and I can use the SD card as storage.

Normally, even if 001-boot-order-prioritize-sd.patch is still present, if you erase the first 1MB of the SD (filling it with zeros), it won't try to boot from SD since it doesn't find the u-boot magic numbers.

[Gregory]

I need the rockpi login

[soerenderfor]

6 hours ago, Gregory said:

I need the rockpi login

On all Armbian image, it is like follows:

root

1234