How I Got Fedora Linux to Boot From eMMC (or microSD, for that matter)

[Rocklobster]

Looking for an operating system suited to the RockPro64 has led me into trying several Linux distributions. But many, I found, were unable boot from the eMMC module. One distro that did was Fedora 35. I had mentioned this in passing and during the course of another thread but after some more experience, I realized those steps needed revision. So here I'll describe the procedure which got Fedora 35 booting from my eMMC. Note the same procedure can also be employed for installation onto a μSD card: Simply make sure you are selecting the correct storage medium from Fedora installer's disk setup menu before partitioning; so, if you'd rather dump Fedora onto a μSD card you can perform the same steps, just make sure to select the appropriate device wherever eMMC is mentioned. Everything herein simply assumes eMMC is the preferred device.

A few things to quickly get out of the way.:
i ) I was unable to achieve success after flashing SPI with Fedora's U-Boot package. Acting on research, I found Sigmaris U-Boot and flashed that to the SPI, after which things fell into place. My advice is to ignore the U-Boot image distributed by Fedora since it appears not to support eMMC booting (even though it may be fine if all you want is μSD installations). Experiences may vary: I'm passing along what worked on my kit, so another might just as well (or not).
ii) Looking at these forums reveals that some eMMC storage (even those ordered directly from the Pine Store) may not be bootable, no matter what. You'll have to see if your eMMC operates in a way you need it to. A SanDisk branded 128GB eMMC, sent from Pine64, is what I'm using.

Assuming SPI has been flashed with a U-Boot capable of booting from eMMC (such as Sigmaris U-Boot), and the machine is outfitted with a booting eMMC device:

-  Download the Fedora 35 Workstation aarch64 ISO and flash it a USB memory stick. Then use that USB memory stick as your primary boot device during the installation process (see U-Boot documentation for setting boot_targets). Another, easier (albeit data-destructive) way, is just erase the boot sectors of any eMMC or μSD drives in the RockPro64, since these are by default set to boot before USB.

-  Get to the Fedora live session, and select the 'Install to Disk' option.

-  Important: Be sure the eMMC drive is the selected target device.

-   After all partitions are set, begin the installation. It will run for some time before spewing an error message about not being able to install GRUB. It will ask if you want to continue installation without GRUB. DO NOTHING YET. Leave the error message on screen for now, and open a Terminal window in the concurrent live session.

-   In said terminal window, enter the following shell commands:

     sudo bash
     mv /mnt/sysimage/boot/efi/EFI/BOOT/BOOTAA64.EFI /mnt/sysimage/boot/efi/EFI/BOOT/BOOTAA64.BAK
     cp /mnt/sysimage/boot/efi/EFI/fedora/grubaa64.efi /mnt/sysimage/boot/efi/EFI/BOOT/BOOTAA64.EFI
     sync
     exit
     exit

-   Now accept the offer to continue without GRUB by clicking an affirmative reply on that error dialogue. The operation should now move to a successful conclusion.

By following these steps, Fedora 35 can be made to boot off eMMC.

Using the stock Fedora 35 kernel (5.14), everything is fine. I can also confirm that upgrading to Linux kernel 5.15 (available in Fedora Updates) works, but you will no longer see a wonky boot menu.

In my several months using Fedora on aarch64, I've discovered a clean, efficient OS to use with my RockPro64. The only thing is Fedora's rapid upgrade cycles: But I find it's still better than the concept of rolling distribution (i.e. CentOS 9, or Manjaro), which doesn't appeal to me.

Maybe someone looking to get Fedora up-and-running from eMMC finds these points useful.

Nice work and well documented too.

I've noticed a number of users were having problems booting various distros from eMMC and it turned out it was in fact a faulty eMMC supplied at time of purchase and not a faulty board. An alternative supplier for an eMMC was found which resolved their issue. Something that others users might bear in mind too.