Fix the uboot for rock-3a

[catalinii]

Description

This PR improves the kernel configuration for radxa rock pi 3A by adding more modules.
Additionally, it consolidates the packaging patch into 1 locations to ensure it accounts for the custom patches added to the radxa 4.19 kernel.

I am currently experiencing what seems to be u-boot issues
Found U-Boot script /boot/boot.scr
fs_devread read outside partition 2640856

Executing script at 00c00000

Wrong image format for "source" command
SCRIPT FAILED: continuing...
MMC error: The cmd index is 0, ret is -110
mmc_init: -110, time 4
starting USB...

**** This issue has been fixed by preventing EFI partitions from being read in U-boot ******

How Has This Been Tested?

Focal and Hirsute images

• Test A
• Test B

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• Any dependent changes have been merged and published in downstream modules

[piter75]

This was fixed with the patch for source command but now the patch is removed from Armbian because Radxa incorporated it in their sources.

Seeing this error now is odd as it seems your local u-boot sources were not updated.
Please verify that your cmd/source.c file is indeed updated in your local cache according to the patch changes.

[catalinii]

Thanks for the tip, let me look into it

[catalinii]

@piter75 I confirmed and the correct line is there. I even tried this: catalinii@dd7e6ad#diff-b5be43512e74a30c65e79d6af8395b6febb45bf93f593637372c7d4de03afa87

but without much luck. What I can see is:
Starting the controller
USB XHCI 1.10
scanning bus dwc3@fcc00000 for devices... 1 USB Device(s) found
scanning bus dwc3@fd000000 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found

Device 0: unknown device
No ethernet found.
missing environment variable: pxeuuid
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm-rockchip
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default
No ethernet found.
Config file not found
No ethernet found.
No ethernet found.

Booting FIT Image FIT: No fit blob

FIT: No FIT image
MMC error: The cmd index is 0, ret is -110
mmc_init: -110, time 5
Could not get mmc 0

Is this expected?
scanning usb for storage devices... 0 Storage Device(s) found

[catalinii]

Trying to see what is going on, so it seems that the actual image in the memory is not the right format.
With this patch
catalinii@83d036b#diff-b5be43512e74a30c65e79d6af8395b6febb45bf93f593637372c7d4de03afa87R41

I get the following:
Scanning mmc 1:1...
Found U-Boot script /boot/boot.scr
fs_devread read outside partition 2645944

Executing script at 00c00000

--> start
x = 0
--> fe ff ef ff
Wrong image format for "source" command

xxd boot/boot.scr | head -1

00000000: 2705 1956 ecf4 5dd6 61b5 6741 0000 0c31 '..V..].a.gA...1

So I am assuming at that location is not the correct content.

[catalinii]

@piter75 @igorpecovnik it seems that the issue is that the partition (mmc 1:1) has for some reason the size set as 1048576 blocks as here:
https://github.com/radxa/u-boot/blob/stable-4.19-rock3/fs/fs_internal.c#L29

By disabling that check the boot works as expected, but still not sure where that size comes from. The partition name is set to "boot" if that helps.

[catalinii]

@piter75 @igorpecovnik I have fixed the issue by preventing the EFI partition from being read before the DOS ones.
For some reason the EFI layout is different and has 2 partitions (boot - 512M and rootfs - remaining).

The PR has been tested and works good on both focal and hirsute.

[lanefu]

Nice work @catalinii

I have received a confirmation that this image works from your PR

https://armbian.lane-fu.com/Armbian_21.11.0-trunk_Rock-3a_bullseye_legacy_4.19.193.img.xz

[catalinii]

@piter75 @igorpecovnik gentle ping for review

[lanefu]

Fine to merge

[amazingfate]

@catalinii hello, I'm working on spi nor flash + NVME boot on rock-3a these days, I find that EFI is necessary for NVME and rockchip_set_ethaddr. I still can't boot from spi and I'm trying to make it work.

[catalinii]

@amazingfate please see this patch: https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-rk35xx/board_rock-3a/0001-Lower-the-priority-of-EFI-to-be-after-DOS-partition.patch .

This patch was added because of EFI vs DOS first partition size mismatch and the first EFI partition was too small for the uboot to load the kernel/dtb.

[amazingfate]

@amazingfate please see this patch: https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-rk35xx/board_rock-3a/0001-Lower-the-priority-of-EFI-to-be-after-DOS-partition.patch .

This patch was added because of EFI vs DOS first partition size mismatch and the first EFI partition was too small for the uboot to load the kernel/dtb.

Root cause of this issue is rockchip legacy u-boot has bad support for ext4 filesystem. Neither EFI nor DOS would make u-boot load kernel successfully. Your patch disabling the EFI mode will make rockchip_set_ethaddr not work, which is responsible for generating ethernet mac address in the uboot vnvm partition. If it doesn't work, every boot will have a random ethernet mac address.
I also tried to update the ext4 driver from the mainline, but still can't get my NVME SSD boot.
Finnaly I made a vfat boot partition on my NVME SSD and now everything works fine(without the EFI disabling patch).

[catalinii]

If you can think of a another workaround for sd card u-boot I think we can remove the patch.

[amazingfate]

If you can think of a another workaround for sd card u-boot I think we can remove the patch.

I build a image with mainline kernel and burn it to my SD card, but I can't reproduce your issue. Here is log:

U-Boot 2017.09-armbian (May 24 2022 - 17:55:21 +0000)

Model: Radxa ROCK 3 Model A
PreSerial: 2, raw, 0xfe660000
DRAM:  7.7 GiB
Sysmem: init
Relocation Offset: ed34a000
Relocation fdt: eb9f7740 - eb9fecd0
CR: M/C/I
Using default environment

PCIe-0 Link Fail
no mmc device at slot 1
dwmmc@fe2b0000: 1 (SD), dwmmc@fe2c0000: 2, sdhci@fe310000: 0
Bootdev(atags): mmc 1
MMC1: Legacy, 52Mhz
PartType: DOS
No misc partition
boot mode: None
FIT: No boot partition
No resource partition
No resource partition
Failed to load DTB, ret=-19
Failed to get kernel dtb, ret=-19
I2c0 speed: 100000Hz
vsel-gpios- not found! Error: -2
vdd_cpu 900000 uV
PMIC:  RK8090 (on=0x02, off=0x08)
vdd_logic init 900000 uV
vdd_gpu init 900000 uV
vdd_npu init 900000 uV
io-domain: OK
Model: Radxa ROCK 3 Model A
rockchip_set_serialno: could not find efuse/otp device
CLK: (sync kernel. arm: enter 816000 KHz, init 816000 KHz, kernel 0N/A)
  apll 816000 KHz
  dpll 780000 KHz
  gpll 1188000 KHz
  cpll 1000000 KHz
  npll 24000 KHz
  vpll 24000 KHz
  hpll 24000 KHz
  ppll 200000 KHz
  armclk 816000 KHz
  aclk_bus 150000 KHz
  pclk_bus 50000 KHz
  aclk_top_high 300000 KHz
  aclk_top_low 200000 KHz
  hclk_top 150000 KHz
  pclk_top 50000 KHz
  aclk_perimid 300000 KHz
  hclk_perimid 150000 KHz
  pclk_pmu 100000 KHz
No misc partition
Net:   No ethernet found.
Hit key to stop autoboot('CTRL+C'):  0
failed to find reset-gpios property

Device 0: unknown device
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:1...
Found U-Boot script /boot/boot.scr
3185 bytes read in 16 ms (194.3 KiB/s)
## Executing script at 00c00000
Boot script loaded from mmc 1
199 bytes read in 14 ms (13.7 KiB/s)
18449298 bytes read in 1568 ms (11.2 MiB/s)
30769664 bytes read in 2588 ms (11.3 MiB/s)
112076 bytes read in 98 ms (1.1 MiB/s)
** File not found /boot/dtb/rockchip/overlay/rk35xx-fixup.scr **
Fdt Ramdisk skip relocation
No misc partition
## Loading init Ramdisk from Legacy Image at 0a200000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    18449234 Bytes = 17.6 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 0x0a100000
   Booting using the fdt blob at 0x0a100000
   reserving fdt memory region: addr=a100000 size=81000
   Using Device Tree in place at 000000000a100000, end 000000000a183fff
can't found rockchip,drm-logo, use rockchip,fb-logo
WARNING: could not set reg FDT_ERR_BADOFFSET.
failed to reserve fb-loader-logo memory
Adding bank: 0x00200000 - 0xf0000000 (size: 0xefe00000)
Adding bank: 0x100000000 - 0x200000000 (size: 0x100000000)
Total: 5644.470 ms

Starting kernel ...


Armbian 22.05.0-trunk Jammy ttyS2

rock-3a login:

[catalinii]

We can remove it then..

[amazingfate]

@catalinii here is the root cause: https://forum.armbian.com/topic/12352-orange-pi-4/page/3/#comment-94322
There is a known behaviour of newer Rockchip blobs that recovers GPT partitions from a GPT recovery partition table if it finds one and then it cannot boot because there is nothing the blob expects in the recovered partitions.
I remember this happening when one used a vendor prepared image on the sdcard (usually GPT) and then afterwards written the Armbian one (MBR) to the same card.
Because the image is only written to the beginning of the media the recovery GPT partition table stays intact and then it is recovered by a blob which renders the image unusable.
Erasing the recovery partiton table (or the whole card) fixes the issue.

[catalinii]

Thanks I noticed that something is off trying to switch between android and armbian for rock 3a, but this explains it.

Last time I used wipefs which did the trick but I think this post explains it.
Thanks for pointing it out.
Do you know if there is a way of documenting this at least @piter75 ?

I am assuming more people will trip over this.

[igorpecovnik]

Do you know if there is a way of documenting

IMO for start at least adding some warning / known issue / link to this conversation at the download pages.

[catalinii]

Do you know where the source of the download page is?

I could add so the message to u-boot...

[igorpecovnik]

Do you know where the source of the download page is?

WP, have sent you to email.

[catalinii]

@piter75 is the code restoring the gpt part of u-boot? If yes can you point out where?

[piter75]

@catalinii for rk3399 the GPT restoration was part of the Rockchip's proprietary loader blob IIRC.
For rk3568 we use u-boot's spl as loader so I guess it must be somewhere in Rockchip's u-boot tree.
I did not look for it yet though.

[catalinii]

Thx for the pointer