Mainline U-Boot with SPI, NVMe and SATA boot support

[LMM]

I really don't know what happens ! the last Armbian / Focal works for me
I've just tested that
- download the new Armbian / Focal release
- unxy the image
- flash the emmc with a USB to emmc adapter : dd if=Armbian_21.05.4_Rockpro64_focal_current_5.10.43.img of=/dev/sda bs=1M
- unbox a new rockpro64
- plug emmc and hdmi
- plug power
and it boots without any problem.
Could it be a problem with the power supply ? As I am building a cluster I use a very stable ATX power supply. Or you may have malfunctions on your SBC ?

[sigmaris]

Yeah, I did all that: checked the filesystem, could mount it on another linux box. Flashed several images (debian, armbian focal with or without desktop) several times. There is one constant: as soon as it's 5.x kernel => no boot from usb/eMMC/NVMe

See also the post I referenced, exactly the same issue as I'm experiencing.
https://forum.armbian.com/topic/14724-ro...-v44-does/

I'll repost my previous reply from page 8 for this:

FWIW, if you're seeing log messages about /scripts/local-premount and so on like in the photo, that's booted up the Linux kernel and got as far as running the scripts on initramfs. So U-Boot may not be the issue here. I would suspect the scripts on initramfs are having trouble finding the root filesystem to mount it and continue booting. Look at your root= argument in the kernel command line, check it's specifying the filesystem you want

I see in Armbian, by default, they pass an argument to the kernel telling it to use /dev/mmcblk0p1 as the root device, on recent 5.x kernels I don't think that corresponds to any storage device. There was a change added to the device tree recently to make the numbering of mmc devices on RK3399 static rather than depending on probe order. On a 5.10 DT it looks like the SD card is /dev/mmcblk1 and the eMMC is /dev/mmcblk2.  So if that default variable isn't overridden in /boot/armbianEnv.txt then that could cause the inability to find the root filesystem in the screenshot. If you know the UUID of the filesystem on your eMMC (you can find this by using the blkid command from Linux with the eMMC attached), try setting rootdev=UUID=<replace with the real UUID here> in /boot/armbianEnv.txt - specifying the root by UUID should let the initramfs scripts find it no matter what the device name/number is.

[MisterA]

Hi,

thank you again for your reply!

I think the UUID is set correct. I booted the RP64 from Sdcard and attached the eMMC using an USB Adapter.
I then issued the command blkid.

jean@rockpro64:~/Desktop$ blkid
/dev/mmcblk1p1: UUID="7def08b4-fb4d-43ec-8e86-79ae058d10d8" TYPE="ext4" PARTUUID="26413df4-01"
/dev/zram0: UUID="74dadee5-30e9-4614-8f4c-4b9573af4bb7" TYPE="swap"
/dev/zram1: LABEL="log2ram" UUID="9f430707-9213-4188-ac14-7f39b43cc0c0" TYPE="ext4"
/dev/sda1: UUID="fbc89545-e72e-44f3-bbbc-44a3ff945d2a" TYPE="ext4" PARTUUID="1ab4d7e8-01"

I mounted the sda1 partition on /mnt and checked /mnt/boot/armbianEnv.txt:

verbosity=1
bootlogo=false
overlay_prefix=rockchip
rootdev=UUID=fbc89545-e72e-44f3-bbbc-44a3ff945d2a
rootfstype=ext4

(bootlogo=false - would this mean I shouldn't see the armbian logo at startup? Because I do (when the boot fails))

So I believe everything is set correct?

I did some further tests:

I wrote Armbian buster (4.x kernel) to eMMC => eMMC boot succesful
I wrote Armbian focal (5.x kernel) to eMMC => eMMC boot failed (with the output referenced in the other post)
I wrote Armbian focal (5.x. kernel) to SDCard => SDCard boot succesful
I also attached the eMMC (with Armbian focal on it) with a usb adapter and could read it's contents and mount the eMMC partition.


I thought perhaps I could use the board booting from SDcard but storing my docker data on the eMMC.
I unmounted the /dev/sda1 partition, then using fdisk I removed the /dev/sda1 partition.
I then tried booting Armbian focal from SDcard with the eMMC connected (on the RP64 itself, not over usb) => boot failed, the output on screen was:
Loading, please wait...
Starting version 245.4-4ubuntu3.6

I rebooted from SDCard and attached eMMC over usb and cleared the MBR (dd if=/dev/zero of=/dev/sda bs=512 count=1).
I tried booting again from SDCard with an empty eMMC attached but it failed with the same output on screen.

I know eMMC has preference over SDCard to boot, but I would assume when eMMC boot fails it would try the next boot option being SDCard.
Is there any way I can interupt the uboot proces , and force an SDcard boot through some uboot command? I'm not so familiar with that to be honest.

[MisterA]

Ok, I got a bit further: I attempted again to boot from SDCard with an empty eMMC module connected to the board. In my last post I explained that the board tried to boot from eMMC anyway (as it has preference over SDCard) but then halted. Seems like after a while there is some timeout and the board eventually boots from Sdcard.

So, I then logged in and saw two mmc devices listed under /dev/:
/dev/mmcblk1  => this is the sdcard as it has a number of partitions listed as well.
/dev/mmcblk2  => this is the eMMC card.

I then attemped an fdisk /dev/mmcblk2, but the command hang.
In /var/log/kern.log I could see these messages pop up from time to time, so I really believe eMMC is not supported on kernel 5.X somehow, see below. I reflashed the eMMC to Armbian buster (4.X kernel), booting succeeded and I couldn't see any of these error messages in kern.log.

Jun 30 17:18:36 rockpro64 kernel: [ 2343.905451] mmc2: cqhci: timeout for tag 0
Jun 30 17:18:36 rockpro64 kernel: [ 2343.905830] mmc2: cqhci: ============ CQHCI REGISTER DUMP ===========
Jun 30 17:18:36 rockpro64 kernel: [ 2343.906397] mmc2: cqhci: Caps:      0x00000000 | Version:  0x00000510
Jun 30 17:18:36 rockpro64 kernel: [ 2343.906962] mmc2: cqhci: Config:    0x00000001 | Control:  0x00000000
Jun 30 17:18:36 rockpro64 kernel: [ 2343.907526] mmc2: cqhci: Int stat:  0x00000000 | Int enab: 0x00000006
Jun 30 17:18:36 rockpro64 kernel: [ 2343.908091] mmc2: cqhci: Int sig:  0x00000006 | Int Coal: 0x00000000
Jun 30 17:18:36 rockpro64 kernel: [ 2343.908655] mmc2: cqhci: TDL base:  0x00000000 | TDL up32: 0x00000000
Jun 30 17:18:36 rockpro64 kernel: [ 2343.909220] mmc2: cqhci: Doorbell:  0x00000000 | TCN:      0x00000000
Jun 30 17:18:36 rockpro64 kernel: [ 2343.909820] mmc2: cqhci: Dev queue: 0x00000000 | Dev Pend: 0x00000000
Jun 30 17:18:36 rockpro64 kernel: [ 2343.910388] mmc2: cqhci: Task clr:  0x00000000 | SSC1:    0x00011000
Jun 30 17:18:36 rockpro64 kernel: [ 2343.910953] mmc2: cqhci: SSC2:      0x00000000 | DCMD rsp: 0x00000000
Jun 30 17:18:36 rockpro64 kernel: [ 2343.911518] mmc2: cqhci: RED mask:  0xfdf9a080 | TERRI:    0x00000000
Jun 30 17:18:36 rockpro64 kernel: [ 2343.912082] mmc2: cqhci: Resp idx:  0x00000000 | Resp arg: 0x00000000
Jun 30 17:18:36 rockpro64 kernel: [ 2343.912646] mmc2: sdhci: ============ SDHCI REGISTER DUMP ===========
Jun 30 17:18:36 rockpro64 kernel: [ 2343.913211] mmc2: sdhci: Sys addr:  0x00000000 | Version:  0x00001002
Jun 30 17:18:36 rockpro64 kernel: [ 2343.913804] mmc2: sdhci: Blk size:  0x00007200 | Blk cnt:  0x00000000
Jun 30 17:18:36 rockpro64 kernel: [ 2343.914371] mmc2: sdhci: Argument:  0x00000001 | Trn mode: 0x00000010
Jun 30 17:18:36 rockpro64 kernel: [ 2343.914936] mmc2: sdhci: Present:  0x1fff0000 | Host ctl: 0x00000034
Jun 30 17:18:36 rockpro64 kernel: [ 2343.915500] mmc2: sdhci: Power:    0x0000000b | Blk gap:  0x00000080
Jun 30 17:18:36 rockpro64 kernel: [ 2343.916065] mmc2: sdhci: Wake-up:  0x00000000 | Clock:    0x00000007
Jun 30 17:18:36 rockpro64 kernel: [ 2343.916629] mmc2: sdhci: Timeout:  0x0000000e | Int stat: 0x00000000
Jun 30 17:18:36 rockpro64 kernel: [ 2343.917194] mmc2: sdhci: Int enab:  0x02ff4000 | Sig enab: 0x02ff4000
Jun 30 17:18:36 rockpro64 kernel: [ 2343.917778] mmc2: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000
Jun 30 17:18:36 rockpro64 kernel: [ 2343.918346] mmc2: sdhci: Caps:      0x44edc880 | Caps_1:  0x800020f7
Jun 30 17:18:36 rockpro64 kernel: [ 2343.918911] mmc2: sdhci: Cmd:      0x00003013 | Max curr: 0x00000000
Jun 30 17:18:36 rockpro64 kernel: [ 2343.919476] mmc2: sdhci: Resp[0]:  0x00400800 | Resp[1]:  0x64201832
Jun 30 17:18:36 rockpro64 kernel: [ 2343.920040] mmc2: sdhci: Resp[2]:  0x4e436172 | Resp[3]:  0x00880103
Jun 30 17:18:36 rockpro64 kernel: [ 2343.920605] mmc2: sdhci: Host ctl2: 0x00000083
Jun 30 17:18:36 rockpro64 kernel: [ 2343.920997] mmc2: sdhci: ADMA Err:  0x00000000 | ADMA Ptr: 0x01191208
Jun 30 17:18:36 rockpro64 kernel: [ 2343.921580] mmc2: sdhci: ============================================
Jun 30 17:18:36 rockpro64 kernel: [ 2343.922179] mmc2: running CQE recovery
Jun 30 17:18:36 rockpro64 kernel: [ 2343.923435] blk_update_request: I/O error, dev mmcblk2, sector 0 op 0x0READ) flags 0x80700 phys_seg 1 prio class 0

[sigmaris]

This looks like the issue with some eMMC cards misbehaving: https://www.spinics.net/lists/linux-mmc/msg61354.html
It's mentioned in that thread that adding sdhci.debug_quirks=0x2020000 to the kernel arguments could disable command queuing and get the card to work, you could try that.

[MisterA]

This looks like the issue with some eMMC cards misbehaving: https://www.spinics.net/lists/linux-mmc/msg61354.html
It's mentioned in that thread that adding sdhci.debug_quirks=0x0x2020000 to the kernel arguments could disable command queuing and get the card to work, you could try that.

Ok, I will look into that. 

I also tried flashing a SDCard with Armbian buster 4.X and boot from it while eMMC is attached.
After a short eMMC boot timeout the boot continues from sdcard. Once booted:

ls /dev/mmc*

/dev/mmcblk0     => SDCard
/dev/mmcblk0p1
/dev/mmcblk1    => eMMC
/dev/mmcblk1boot0   => ?
/dev/mmcblk1boot1   => ?
/dev/mmcblk1rpmb    => ?

I did an fdisk /dev/mmcblk1 and created a 16M ntfs partition:

fdisk /dev/mmcblk1 -l

Disk /dev/mmcblk1: 57.6 GiB, 61865984000 bytes, 120832000 sectors

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disklabel type: dos

Disk identifier: 0x1ab4d7e8



Device        Boot Start  End Sectors Size Id Type
/dev/mmcblk1p1      2048 34815  32768  16M 83 Linux

I mounted the partition I created, copied some text files over, shut down the system and using an eMMC usb adapter I could read the testfiles on my windows box. So eMMC is working under 4.x kernel.

---

This looks like the issue with some eMMC cards misbehaving: https://www.spinics.net/lists/linux-mmc/msg61354.html
It's mentioned in that thread that adding sdhci.debug_quirks=0x2020000 to the kernel arguments could disable command queuing and get the card to work, you could try that.

Tried it, but doesn't seem to work. If command queuing would not work on the eMMC, it would not work on 4.x kernels either?

---

What about this (found in the post I referenced to earlier):

This is a known issue with rk3399 boards using mainline kernel and it was mitigated for all other boards using mainline u-boot some time ago.
RockPro64 is the last one that is uses u-boot v2017.09 but I am planning to switch it to mainline for the next Armbian release (v20.11).
For now you need to either be patient or stay with 4.4.y.

They referenced the following snippet as well:
https://github.com/armbian/build/blob/ma...kclk.patch

[LMM]

have you tried to erase spi flash and boot with emmc with a blank spi ?

[MisterA]

have you tried to erase spi flash and boot with emmc with a blank spi ?

Don't think so. When I get home I will try to boot from emmc with the spi disabled by jumpering the two pins (25-23 I believe).
The should have the same effect no?

[LMM]

Not sure that it is equivalent : if u-boot is not present in spi, the boot program in the first block of the emmc is executed.
to be confirmed by sigmaris who is more knowledgeable than me on this topic

[MisterA]

Not sure that it is equivalent : if u-boot is not present in spi, the boot program in the first block of the emmc  is executed.
to be confirmed by sigmaris who is more knowledgeable than me on this topic

I tried with disabling SPI (jumpered pins 23-25) but booting fails with emmc.
USB Boot fails as well now, so SPI definitely disabled with the 2 pins shorted.

I took the jumper of the pins, emmc keeps failing to boot.
I put the emmc on a usb adapter, booting works.