Rockpro64 will not boot

[CeeGO]

I've tried the latest CLI and GUI images. I tried different microSD cards but the result is the same.

 

Both images get to

Booting using the fdt blob

and never progress.

 

Is there anything I can try to get this working?

 

[AxelFoley]

No you are not the only person. The Image is screwed and wont boot when flashed to eMMC.  It boots from SD.

I'm looking into the problem now.  

[AxelFoley]

Happens on both the CLI and GUI Desktop Images tried flashing in Rufus and Etcher 

It simply dose not work on eMMC .... so I don't know how this could get released without the basics being checked. 

I'm not going to buy SD Cards for my 20 node clusters !

 

[AxelFoley]

https://wiki.pine64.org/wiki/ROCKPro64_Software_Release

"If you are booting from a Micro SD card, then both Linux kernel versions will work. If you are trying to boot from an eMMC module then the 4.4.y will work, but the newer 5.10.y will not."

 

Doh !  So you will need to flash to 4.4.y or boot from SD Card if you want Armbian 

[schwar3kat]

22 hours ago, AxelFoley said:

Doh !  So you will need to flash to 4.4.y or boot from SD Card if you want Armbian 

Hi Axel,

I don't own one, and I don't have a board that uses eMMC, so I'm neither familiar with it nor can I can't test, but Googling the issue, Rockpro64 seems well known for a eMMC bug with random cards that report command queue (CMDQ) support but don't work correctly when CMDQ is enabled and if you searched these forums, you possibly came across this. https://forum.armbian.com/topic/19917-rockpro64-emmc-armbian-2108-kernel-51060-buster/    The post indicates that it only affects some boards, so it's likely a hardware tolerance issue that is triggered by something in the newer kernels.

According to some Googled solutions it apparently requires a Kernel boot argument work around to get such cards to work with Kernels > 5. 
Kernel boot arguments can be added into the Armbian boot armbianEnv.txt file.
It's certainly worth a try.

You can try this:

Add a line into into /boot/armbianEnv.txt
extraargs="mmc_cmdqueue=off"

Let us know if it works  

[AxelFoley]

Tried setting extraargs="mmc_cmdqueue=off"   Still same error.

 

When I googled around a bit, one suggestion was that it was caused by the 1st  n byte's of the eMMC chip getting nulled out deleting the normal boot partition location and that the solution was to move the boot sector to a new address range outside that first n bytes... but I'm no boot expert ... I'll do some digging;

 

 

[Igor]

Build image from sources. It has different boot loader.

[AxelFoley]

Well after a bit of tracing the serial output of the boot load process and looking at a working ayufan image against a Armbian Image (5 kernel) it looks like they have a different way of implementing U-Boot for the RockPro64 RK3399.

Note my test boards come with PCIe NVMe Drives and the board provides 128Mb SPI boot Flash and 64GbE eMMC Storage from which I am trying to boot the kernel.  

 

Not booting eMMC:    Armbian TPL -> SPL-> U-Boot -> Kernel

Booting eMMC:          Ayufan    SPL -> U-Boot -> kernel 

 

>> What I notice is that Ayufan image has a serial boot output prefixed by what looks like a LDDR Memory test/probe.

The boot sequence should be consistent at first then deviate, not deviate right from the start ! 

 

 RTFM Here https://wiki.pine64.org/wiki/RK3399_boot_sequence

 

"It employs 5 strategies, in order, to load a bootloader from off-chip:

loading from NOR flash on SPI1

loading from NAND flash on SPI1

loading from eMMC

loading from SD on the SDMMC controller

bringing up the OTG0 USB controller in device mode and accepting control transfers to load programs

Loading a bootloader from storage is done in 4 steps:

Probing the boot device

Finding the ID block

Loading the first stage of the bootloader to main SRAM and running it

(if the first stage returned to BROM) Loading the second stage to low DRAM and running it"

 

>> I have a suspicion that Ayufan's images have loaded a U-Boot Boot loader into SPI Flash and, perhaps that may be the issue as to why his images work but others do not.

His kernel may be located at address below in eMMC but other boot images are not.

 

"Booting using the fdt blob at 0x1f00000" 

 

I'll see if I can wipe the SPI Flash and see if Armbian starts to boot.

 

FailedBoot.log SuccessfulBootlog.log

[AxelFoley]

Nah I think the above hypothesis is wrong, in some respects. 

 

My (poor) understanding of the boot process is;

1). First/Primary Boot Stage loader is BROM in the SOC's Chip initiated to enable enough HW to find the main boot loader (e.g. U-boot's SPL Secondary Boot Loader which is loaded on SPIFlash/eMMC/SDMMC Card),

2). The U-Boots SPL then initiates more HW (such as DDR Memory) to enable the full U-Boot to be loaded into larger memory space.

      >> I suspect that this is a legacy constraint ... legacy systems had limited memory so any boot loader needs to fit into those smaller memory environments for backwards compatibility.

      >>  however if it can probe and detect more memory (NAND,NOR Flash Chips, eMMC, SDMMC & DDR Memory). This is Where the TPL Comes in

3). Tertiary Program Loader  (to look for larger memory HW in which the SPI can load a bigger version of U-Boot out side of legacy constrained HW).

 

>> So I think that both eMMC's U-Boot SPL Part of the boot image is being initialised on the eMMC (nee MMC lines in the serial output as eMMC is treated as SDMMC). It immediately loads the TPL to initialise the DDR memory   and this explains why you see the TPL before the SPL in the output. The reason why the working Auyfan's has more verbose DDR output is because he is using a debug version of U-Boot;

 

Auyfan working u-boot  ( v1.3(debug):370ab80)          SPL finds kernel image on eMMC   Found /boot/extlinux/extlinux.conf    ...Retrieving file: /boot/vmlinuz-4.4.190-1233-rockchip-ayufan-gd3f1be0ed310

Armbian non working u-boot v1.3(release):845ee93   SPL finds kernel image on eMMC   Found U-Boot script /boot/boot.scr

 

so TPL hands back to SPL again after initialising the DDR Memory so SPL can load the big U-Boot image into DDR Memory .... but this is where I think the problem is .... 

 

Both images seem to try to load a Ram Disk to load the kernel into

 

Aufan;  ## Flattened Device Tree blob at 01f00000
   Booting using the fdt blob at 0x1f00000
   Loading Ramdisk to f5902000, end f5f00ca8 ... OK
   Loading Device Tree to 00000000f58e7000, end 00000000f5901810 ... OK

 

Armbian;  Applying kernel provided DT fixup script (rockchip-fixup.scr)
## Executing script at 09000000
Moving Image from 0x2080000 to 0x2200000, end=3f90000
## Loading init Ramdisk from Legacy Image at 06000000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    14238821 Bytes = 13.6 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 01f00000
   Booting using the fdt blob at 0x1f00000

 

So I need to look at what this "rockchip-fixup.scr" is actually doing that Auyan's image is not. because it looks to me like the Armbian image is failing to load the kernel into DDR memory.

Now this may be down to this line in the Armbian Boot process;

 

Device 0: unknown device
Card did not respond to voltage select! : -110
switch to partitions #0, OK

 

>> I wonder if its the NVMe storage that's confusing the Armbian image boot process and preventing it from loading the kernel into DDR.

Time for bed but tomorrow I'll disconnect the PCIe NVMe device and see if Armbian boots !

[AxelFoley]

Update:   well its was not the NVMe drive or the USB Peripherals. I disconnected them both and the Armbian image still refuses to boot the kernel

 

There is still and unknown device

 

Device 0: unknown device
Card did not respond to voltage select! : -110
switch to partitions #0, OK
 

and the image still fails to boot

 

 Applying kernel provided DT fixup script (rockchip-fixup.scr)
## Executing script at 09000000
Moving Image from 0x2080000 to 0x2200000, end=3f90000
## Loading init Ramdisk from Legacy Image at 06000000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    14238821 Bytes = 13.6 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 01f00000
   Booting using the fdt blob at 0x1f00000

 

[schwar3kat]

Have you tried the new images 23-Jun?

There is a description of the boot processes on the pine site
https://wiki.pine64.org/wiki/RK3399_boot_sequence
I noted this statement: "The BROM does not support using the standard option for eMMC boot partitions"
 

I also note that rockchip64 has 128Mb SPI boot Flash.

So perhaps it is possible to place your bootloader in spi, and the rest in eMMC

[Igor]

On 6/22/2022 at 9:55 PM, AxelFoley said:

RTFM Here https://wiki.pine64.org/wiki/RK3399_boot_sequence

 

Worth comparing if not already:
https://github.com/armbian/build/blob/master/config/sources/families/include/rockchip64_common.inc