RockPro64 eMMC boot

[euu]

First tries with my new RockPro64.

Flashed Manjaro ARM 20.06 on an SD card and ayufan's latest stable release bionic-minimal-rockpro64-0.9.14-1159-armhf on another SD card.
Both of them work just fine.

While in Manjaro, I flashed the same Manjaro image to eMMC, which Linux sees as /dev/mmcblk1.
Shutdown, removed SD card and reboot.
The board does not boot from eMMC.
It boots fine from Manjaro SD card when eMMC module is present.

Tried the same thing in Bionic, flashing the same Bionic image to eMMC.
Again the board does not boot from eMMC, but boots all right from Bionic SD card with the eMMC module present.

Then I flashed the SPI using the instructions from https://github.com/ayufan-rock64/linux-b...ash-spi.md with the latest release of flash_spi.img.
The eMMC module was removed during the SPI flashing process.
Same result, the board still does not boot from eMMC.

Last thing I flashed the SPI again using the instructions from https://github.com/sigmaris/u-boot/wiki/...oot-to-SPI.
This did not help either: boot from eMMC is not happening, while boot works like a charm from any SD with the eMMC present.

SW4 is open (no jumper).

What am I doing wrong?
How do I get the board to boot from eMMC?

[diskers]

First tries with my new RockPro64.

Flashed Manjaro ARM 20.06 on an SD card and ayufan's latest stable release bionic-minimal-rockpro64-0.9.14-1159-armhf on another SD card.
Both of them work just fine.

While in Manjaro, I flashed the same Manjaro image to eMMC, which Linux sees as /dev/mmcblk1.
Shutdown, removed SD card and reboot.
The board does not boot from eMMC.
It boots fine from Manjaro SD card when eMMC module is present.

Tried the same thing in Bionic, flashing the same Bionic image to eMMC.
Again the board does not boot from eMMC, but boots all right from Bionic SD card with the eMMC module present.

Then I flashed the SPI using the instructions from https://github.com/ayufan-rock64/linux-b...ash-spi.md with the latest release of flash_spi.img.
The eMMC module was removed during the SPI flashing process.
Same result, the board still does not boot from eMMC.

Last thing I flashed the SPI again using the instructions from https://github.com/sigmaris/u-boot/wiki/...oot-to-SPI.
This did not help either: boot from eMMC is not happening, while boot works like a charm from any SD with the eMMC present.

SW4 is open (no jumper).

What am I doing wrong?
How do I get the board to boot from eMMC?

[euu]

And it seems that nobody is interested about booting from emmc.
Probably everybody is booting now from NVME SSD, so nobody cares!

[euu]

Temporary success by combining sigmaris' instructions with ayufan's bionic-mate-rockpro64-0.9.14-1159-armhf, which is the latest stable release.
Initial boot from emmc, but fails again after updating the system, even after dd u-boot with seek=64 and seek=16384.

Gave up trying to boot from emmc.
PCIe NVMe boots fine and is impressively fast, although no other release works after that mentioned above, nor any other kernel.

Next step: installing gentoo 64-bit kernel and userland.

[t4_4t]

What complicates the eMMC issue is the mix of lucky and unlucky eMMC.
I'm not sure how much it is, but at least in my own eMMC, both exist.

For example, if you look at the thread of pinbookpro, there are many writing that seems to have similar symptoms.
For those who only own the lucky eMMC,
What doesn't work is advice from the perspective of "there's a problem with that person's operation". That's unavoidable.
(In fact, there is no objection that there will be many such cases...)
Therefore, the problem is not easily solved.

Since the problem is in the kernel's eMMC driver, my conclusion is that it must be corrected.
If you can kernel-build, try changing "CQE" to "Disable" completely.

In my case, I improved it so that it can be started even with an unlucky eMMC that did not work at all.
The eMMC I own is
  A) Unlucky eMMC:
      Booting from all devices is impossible just by installing the eMMC
  B) Lucky eMMC:
      It can be booted correctly without any additional work.

I can't tell if everything is the same as my case, but this trend existed even with old kernel-4.xx.

Of course, the bad thing is the kernel-driver that cannot absorb individual differences of eMMC, and I do not think that eMMC itself is bad.