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

[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