Architectures/ARM/exynos

In other languages: English (en) [edit]

Introduction

The EXYNOS SoCs from Samsung are an ARMv7 series of SoCs based on the ARM Cortex series. Fedora supports these devices in a best effort fashion due to the inability to ship all binaries required to run them.

The 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.

Other Exynos devices that are known to work with Fedora include some models of Chromebooks, the Arndale device, and some other SBC boards.

BootLoader support

Unfortunately (as of XU3/4), the FBL (equivalent of u-boot's SPL) must be signed to run on Exynos5 SoCs. As a result EXYNOS5 devices must explicitly reuse the pre-built binary FPL code from HardKernel and can only use u-boot only as a second stage bootloader. Without the ability for Fedora to build and sign the FBL(SPL) we can't build/test/distribute that as part of the project, instead we can only document the steps and these devices as a result are best effort support.

Caveat

Some of the Fedora community have barely restrained [1] 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 [2], also available with a support issue environment pre-release [3] of their next periodic release cadence. That said, ** please ** read their support [4] documentation, ** before ** opening an issue [5] at GitHub

Success Report

On an Odroid HC1 with kernel 4.15.0-0.rc0.git6.1.fc28.armv7hl [6] 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 [7]

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 [8] 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

In the thread [9] I (RPH) summarize and annotate the 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 initramfs See RHBug # 1482825 [10] (but see: Gilmore configuration file suggestion, which permits local workaround this issue, pending code additions to add as a 'special-case' the capabilities and module requirements of particular hardware)

2. A 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 (part of this was later solved with some patches upstreamed at '4.15.0-0.rc0.git6.1.fc28.armv7hl' .. the need for the "cpuidle.off=1" remains as of 2017 12 QUERY by RPH: can this be 'whitelisted' and automatically done based on hardware probing?)

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; QUERY by RPH: how to copy: 'rsync' with '--exclude' arguments, cd to a mountpoint and 'cp -a'?

-- e. Update (manually) the UUID values on what will be the '/boot/extlinux/extlinux.conf' file and '/etc/fstab' files of the eMMC card; QUERY by RPH: in a non-manual install, 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

... as to 'dracut' modules inclusion, Dennis Gilmore noted on the mailing list:

'mmc_block' is not needed to be added. You should drop a config snippet in a file such as '/etc/dracut.conf.d/pwrseq_emmc.conf' with contents being: add_drivers+=" pwrseq_emmc

With that dracut will always include the modules when making initramfs's

- 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 system)

- E. Boot up using the eMMC card.

4. If the system is hereafter 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. FIXME: this needs to be 'upstreamed' further

Open Issues

Please note any: FIXME or other testing reminders here

Track Dracut RFE for ODroid modules required RHBug # 1482825 This may also need to be further 'upstreamed' to ... RPH: Dracut documentation [11], and upstream VCS [12], and mention of the initramfs mailing list

> To note a bug in RHBZ is a Fedora bug not an upstream bug