< Architectures | ARM
Introduction
The [1] ODroid XU4 series are a family of credit card-sized ARM based single board computer (SBC). Fedora 27 supports the the XU4, and closely related variant HC1 in Fedora 27 without any requirement of third party kernels or scripts to adjust official images. This documentation describes how to get started, and (will) include a Frequently Asked Questions (FAQ) about what is supported and what is not.
Caveat
Some of the Fedora community have barely restrained [2] hostility to Exynos devices
- From my point of view the devices are "best effort", I personally don't have any devices to test, the Odroid manufacturers generally don't give a shit about anything upstream and no one in the community has stepped up to be the maintainer of the (Exynos) devices
This of course also represents an opportunity for developers to step up, and to dispel that attitude with documentation and stabilization work, such that this Caveat might be removed
Targeted Hardware
We initially (2017 11) seek only to document support for the ODroid XU4 and HC1
Prerequisites
- An ODroid XU4 or HC1; Amazon also stocks a partial line of current production ODroid kit including these units and some accessories
- A hefty power supply. You'll want at least 2A and 2.5A is preferred to avoid mysterious and hard to diagnose power 'current droop' failure modes
- One or more 'better' quality SD Card (eLinux hosts a compatibility list). ODroid also sells such pre-flashed, but shipping costs are non-trivial from Korea
- A USB keyboard
- A HDMI input Monitor, or TV with an HDMI input (optional as to the HC1, which is 'headless')
- A USB mouse (optional in non-GUI environments)
For preparation of the SD card:
- Computer running any modern operating system; SD card writing software
- SD card reader / writer device (usually an USB device, but an 'in-chassis' adapter has been shown to also work fine)
- Under any reasonable Linux or OS/X operating system, the "dd" CLI tool will work to transfer a proposed image to SD media; For those preferring a GUI tool, Etcher [3], also available with a support issue environment pre-release [4] of their next periodic release cadence. That said, ** please ** read their support [5] documentation, ** before ** opening an issue [6] at GitHub
Success report
On an Odroid HC1 with kernel 4.15.0-0.rc0.git6.1.fc28.armv7hl [7] with on-board network (USB-3 bus based) and the ssd (USB-2 bus based SATA ... the HC1 has multiple USB buses) is working . This includes booting and enumerating devices properly
Background on the fix
From the Fedora mailing list:
- http://www.spinics.net/lists/arm-kernel/msg606525.html [8]
- So today must be your lucky day, while waiting for images to download I was browsing the ARM kernel list and noticed the exynos pull request for 4.15 [9] and low and behold there's a fix headed upstream for the usb3 issues and it applied cleanly to 4.13/4.14 so that should be fixed in 4.13.7 which might make F-27 GA because I'm such a nice individual. Only took them 7 kernel releases to fix it!
Earlier:
- The system still requires the 'cpuidle.off=1' argument on the "append" line of the 'extlinux.conf' file to boot
Long form description of the fix
A follow up post [10] was then made with a long form description of the steps taken:
Summary of Fedora on Odroid XU4 1.
1. with Kernel 4.6.5-300.fc24 system boots without failure, but update to newer kernel fails due dracut didn't build suitable intramfs see RHBug # 1482825 [11]
2. newer kernel works only with "cpuidle.off=1" inserted into the "append" kernel line in the /boot/extlinux/extlinux.conf file, but all USB3 Hosts failed, no onboard ethernet
3. To boot the system from the eMMC card:
- A. The initramfs image file must be rebuilt. The simplest way is to:
-- a. Boot up using the MicroSD card;
-- b. Partition the eMMC card such that partition 1 begins on sector 3072 (Default starting sector from fdisk is 2048). There should be 4 partitions created;
-- c. Mount the Fedora image desired to be installed on the eMMC card;
-- d. Copy all partition data from the mounted fedora image partitions (there are 4 for Fedora 26 ARM images) to the appropriate eMMC partitions;
-- e. Update the UUID values on what will be the /boot/extlinux/extlinux.conf file and /etc/fstab files of the eMMC card; QUERY: should not this be done by 'grubby' or 'dracut' on a hands off basis for updates, and by anaconda during the initial install (again probably by calling 'dracut' to do the configuration at a Single Point of Truth
-- f. Assuming the eMMC partitions are mounted as such --
- mount /dev/mmcblk1p4 /mnt
- mount /dev/mmcblk1p2 /mnt/boot
then perform the following (customary Linux kernel virtual filesystem) mounts --
- mount -o bind /proc /mnt/proc
- mount -o bind /dev /mnt/dev
- mount -o bind /sys /mnt/sys
- B. Rebuild the eMMC card's initramfs by executing the following command:
- chroot /mnt dracut --add-drivers='pwrseq_emmc mmc_block' /boot/initramfs-4.11.8-300.fc26.armv7hl.img 4.11.8-300.fc26.armv7hl
- C. Flash the boot information in the header of the eMMC card;
- D. Shutdown the system, then remove the MicroSD card; (now 'umounted' cleanly from a stopped sytem)
- E. Boot up using the eMMC card.
4. If the system is to be updated using "dnf update", a new initramfs image must again be (presently manually) generated. This can be done using steps 1f - B. above using the new initramfs and kernel images provided by the "dnf update".
Note to the developers/maintainers of dracut: The kernel modules "pwrseq_emmc" and "mmc_block" should be included in 'dracut' for the Odroid-XU3 and Odroid-XU4 such that the user need not have to execute this procedure each time and update to the system is performed.
Open Issues
Please note any: FIXME or other testing reminders here
Track Dracut RFE for ODroid modules required RHBug # 1482825