How I Got Fedora Linux to Boot From eMMC (or microSD, for that matter)
#1
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.
  Reply
#2
(12-30-2021, 08:05 AM)whitecat23 Wrote: 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.
  Reply
#3
(12-30-2021, 07:40 PM)Rocklobster Wrote: 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.

Thank you. It's encouraging to see support in mainline Linux. I was getting worried about the selection of operating systems, when I found that Fedora provides me with a good personal computing experience. I would've likely considered Armbian if not for the fact they've dropped support for the RockPro64. I look forward to seeing more distros running vanilla on this board.

It's good to hear they've resolved their eMMC issues. It seemed like an attractive option at the time, given how they fit a small case. But if I opt for another Pine64 board, it'll probably be with the NAS case, to house an NVMe drive.
  Reply
#4
(01-01-2022, 06:10 PM)whitecat23 Wrote:
(12-30-2021, 07:40 PM)Rocklobster Wrote: 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.

Thank you. It's encouraging to see support in mainline Linux. I was getting worried about the selection of operating systems, when I found that Fedora provides me with a good personal computing experience. I would've likely considered Armbian if not for the fact they've dropped support for the RockPro64. I look forward to seeing more distros running vanilla on this board.

It's good to hear they've resolved their eMMC issues. It seemed like an attractive option at the time, given how they fit a small case. But if I opt for another Pine64 board, it'll probably be with the NAS case, to house an NVMe drive.

I actually settled on LibreElec for my RockPro64 in the end. I like the JeOS concept it provides. Boot times are lightening fast and all my media needs are covered. Overall performance is very acceptable and graphics performance is excellent. The only downside is community input but like yourself I finally found something I liked on the OS front that covered all bases and got it working. I might even have a go at Fedora now that you've done such thorough work documenting it. Well done again.
  Reply
#5
(01-01-2022, 07:33 PM)Rocklobster Wrote: I actually settled on LibreElec for my RockPro64 in the end. I like the JeOS concept it provides. Boot times are lightening fast and all my media needs are covered. Overall performance is very acceptable and graphics performance is excellent. The only downside is community input but like yourself I finally found something I liked on the OS front that covered all bases and got it working. I might even have a go at Fedora now that you've done such thorough work documenting it. Well done again.

Your mention of LibreElec got me curious about graphics performance with Fedora, specifically on the RockPro64. Given that my day-to-day comprises mostly internet, LibreOffice, and some light programming with gcc, I really haven't tested the video playback capabilities (I use Windows for that, out of habit). So I logged into a Gnome session and first executed glxgears several times: A table of 10 or more entries was produced by each run, showing that frames-per-second (FPS) hovering around the 59.9xx mark, very rarely matching exactly 60 FPS (but never dropping too far below, either). Then several official trailers were played in VLC, each exhibiting a slight but perceptible stutter about every 5 or 7 seconds; the size of the playback window didn't seem to matter (i.e. virtually the same was observed in windowed and full screen modes).
Now, I'm very limited in my knowledge of both video and of Linux. So I guess the next thing is for me to check the RPMFusion repos for better codecs.

Edit: I added that info about glxgears because I'm not sure if it's an indicator of movie playback quality or not.
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  irradium (based on crux linux) RockPro64 riscv64, aarch64 mara 6 1,663 10-12-2024, 04:53 AM
Last Post: mara
  Boot/Shutdown on timer captainmorgan 8 7,377 11-01-2023, 12:08 PM
Last Post: Nikolay_Po
Exclamation Ethernet regression on Linux Kernel 6.5.4? Deathcrow 3 1,400 09-22-2023, 04:27 AM
Last Post: diederik
  Installing CH431SER on Ayufan 0.9.14: gitlab-ci-linux-build-159 Thisone 4 2,118 07-14-2023, 04:22 AM
Last Post: hunderteins
Question How do I compile an arbitrary kernel for U-Boot? Valenoern 3 1,733 06-16-2023, 10:54 AM
Last Post: CounterPillow
  Linux laptop does not detect the board when plugged in via USB soupy 1 4,427 04-13-2023, 03:01 AM
Last Post: Reynold Grady
  RockPro64 boot questions misterc 3 2,213 01-13-2023, 06:21 PM
Last Post: misterc
  Is some u-boot required on the SPI for installing debian with the official installer? callegar 1 1,688 10-25-2022, 10:07 AM
Last Post: ratzzupaltuff
  RockPro64 linux console video mode callegar 0 1,092 09-06-2022, 02:32 PM
Last Post: callegar
Brick Maintained Linux booting from eMMC ootoovak 10 9,668 04-30-2022, 03:57 PM
Last Post: TRS-80

Forum Jump:


Users browsing this thread: 1 Guest(s)