Posted on by Jean-Luc Aufranc (CNXSoft) - 33 Comments on Fedora 26 Supports Single “Unified” OS Images for Multiple ARM Platforms

Fedora 26 Supports Single “Unified” OS Images for Multiple ARM Platforms

The decision to use device tree in Linux occurred several years ago, after Linus Torvalds complained that Linux on ARM was a mess, with the ultimate goal of providing a unified ARM kernel for all hardware. Most machine specific board files in arch/arm/mach-xxx/ are now gone from the Linux kernel, being replaced by device tree files, and in many case you simply need to replace the DTB (Device Tree Binary) file from an operating system to run on different hardware platforms. However, this is not always that easy as U-boot still often differ between boards / devices, so it’s quite frequent to distribute different firmware / OS images per board. Fedora has taken another approach, as the developers are instead distributing a single Fedora 26 OS ARMv7 image, together with an installation script.

Images for 64-bit ARM (Aarch64) are a little different since they are designed for SBSA compliant servers, so a single image will work on any server leveraging UEFI / ACPI implementation on the hardware. So what follows is specific to ARMv7 hard-float images as explained in the Wiki.

You’ll need to install Fedora Arm installer after downloading one of the Fedora 26 images. This requires an Fedora machine, and since I’m running Ubuntu 16.04, and don’t want to setup a Fedora virtual machine in Virtualbox, I used docker instead right inside Ubuntu as it’s much faster to do:


The last line requires some explanation. /media/hdd is the mount point of the storage device on the host where I download the Fedora image and that will be accessible through /mnt in docker, /dev/sdd is my micro SD card device, while /dev/sdd3 will be the rootfs partition.Note that it took me a while to get that right, and I’m not sure it works for all targets (other other /dev/sddx are also needed), so using an actual Fedora 26 installation would be easier. The rest of the instructions below are not specific to docker.

I could then install the Fedora ARM Installer and the required xz & file packages…


…and check the usage:


Let’s see how many boards are supported in /usr/share/doc/fedora-arm-installer/SUPPORTED-BOARDS file:

AllWinner Devices:
A10-OLinuXino-Lime A10s-OLinuXino-M A13-OLinuXino A13-OLinuXinoM
A20-OLinuXino-Lime A20-OLinuXino-Lime2 A20-OLinuXino_MICRO
A20-Olimex-SOM-EVB Ampe_A76 Auxtek-T003 Auxtek-T004 Bananapi Bananapro CHIP
CSQ_CS908 Chuwi_V7_CW0825 Colombus Cubieboard Cubieboard2 Cubietruck
Cubietruck_plus Hummingbird_A31 Hyundai_A7HD Itead_Ibox_A20 Lamobo_R1
Linksprite_pcDuino Linksprite_pcDuino3 Linksprite_pcDuino3_Nano MK808C
MSI_Primo73 MSI_Primo81 Marsboard_A10 Mele_A1000 Mele_A1000G_quad Mele_I7
Mele_M3 Mele_M5 Mele_M9 Mini-X Orangepi Orangepi_mini Sinlinx_SinA31s
UTOO_P66 Wexler_TAB7200 Wits_Pro_A20_DKT Yones_Toptech_BS1078_V2 ba10_tv_box
colorfly_e708_q1 difrnce_dit4350 dserve_dsrv9703c i12-tvbox iNet_86VS
icnova-a20-swac inet86dz jesurun_q5 mk802 mk802_a10s mk802ii orangepi_2
orangepi_lite orangepi_pc orangepi_plus polaroid_mid2809pxe04
pov_protab2_ips9 q8_a13_tablet q8_a23_tablet_800x480 q8_a33_tablet_1024x600
q8_a33_tablet_800x480 r7-tv-dongle sunxi_Gemei_G9

MX6 Devices:
cm_fx6 mx6cuboxi novena riotboard wandboard

OMAP Devices:
am335x_boneblack am57xx_evm kc1 omap3_beagle omap4_panda omap5_uevm

MVEBU Devices:
clearfog

ST Devices:
stih410-b2260

Other Devices:
jetson-tk1 rpi2 rpi3 trimslice

So we’ve got a list of device to choose from. For example, if you wanted to install Fedora 26 server in a micro SD card for Raspberry Pi 3, you’d run something like:


You’ll then be ask to confirm:


The full process will take several minutes, and at the end you’ll get “_/” rootfs partition, “_/boot ” partition, and a “30 MB volume” with u-boot, config,etc…


I did not try the micro SD card in Raspberry Pi 3 board myself, because Geek Till It Hertz has already done it successfully on both RPi 3 and Banana Pi boards as shown in the video below.

He also showed the boards run Linux 4.11.8 version, but that can be upgraded with dnf update to Linux 4.11.11, just as on his Fedora 26 installation on a x86-64  computer.

Share this:
FacebookTwitterHacker NewsSlashdotRedditLinkedInPinterestFlipboardMeWeLineEmailShare

Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress

ROCK Pi 4C Plus

33 Replies to “Fedora 26 Supports Single “Unified” OS Images for Multiple ARM Platforms”

  1. Heh, loads of allwinner devices being listed, but does anyone even know, for instance, how to identify the r7-tv-dongle? There’s support for it in both u-boot and the kernel, but what is it, and how do i know whether my a10s device is an r7-tv-dongle or not? Google gives me no relevant information on what it is or what it looks like.

    So well done on supporting a huge array of devices, now if we only knew what some of those devices were.

    — the guy who wrote most of the linux-sunxi wiki and who warned about this several years ago.

    Reply

  2. There’s also a u-boot updater, so you don’t need to completely rewrite the image between different boards:
    update-uboot
    ————
    Update to a new u-boot on a disk image from a local host install. Optionally download a specified
    newer u-boot from koji by specifying a koji tag.

    Reply

  5. They say history is told by the victor. So, the opening statement probably deserves a little attention:
    “Device tree was born several years ago, when Linus Torvalds complained that ARM was a mess”

    If you consult the wikipedia entry for device tree it states:
    “The device tree is a data structure for describing hardware, which originated from Open Firmware. ”

    If you consult the wikipedia entery for Open Firmware, it states:
    “It originated at Sun, and has been used by Sun, Apple, IBM, ARM[1] and most other non-x86 PCI chipset vendors.”

    Device tree existed before ARM. ARM has simply popularized its use because there are far more ARM devices than Sparc or PowerPC.

    (Note: Link purposely left out of the comment to avoid “moderation”. )

    Reply

  6. And the board list above in not complete. It’s possible to add your own by adding files to /usr/share/arm-image-installer/boards.d. Current content:

    Content of udoo file as example:

    Reply

  8. CSQ_CS908: this is the only sensible link (http://www.lightinthebox.com/csq-cs908-quad-core-1g-8g-android-4-2-2-smart-tv-box_p2903324.html) and who knows how long that will live.
    Chuwi V7 CW0825 is explained away with ‘It is clearly marked “CHUWI”, “V7” and “Model: CW0825” on the back of the tablet. ‘
    Colombus is actually Wits ColUmbus A31
    UTOO_P66 is mostly just found from alibaba or aliexpress, for as long as that lasts.
    ba10_tv_box is a mystery as well
    difrnce dit4350 was very popular in europe, so that is almost excusable.
    dserve dsrv-9703c is the same story

    What’s the point of these then?

    Reply

  10. @Luc Verhaegen
    Well Hans was busy with several A10 devices I suggest

    “.] (4.3 kB) by Hans de Goede Hans de Goede , pushed by Maxime Ripard Maxime Ripard

    ARM: dts: sun5i: Add new Auxtek-t004 board

    The auxtek-t004:
    http://www.fasttech.com/products/1110/10004200/1318603-auxtek-t004-allwinner-a10s-single-core-android-ics

    Is an Allwinner A10s based hdmi tv stick with with 512M RAM, 4G nand flash,
    toc9002 (bcm43362) sdio wifi, 1 USB host ports using an USB-A receptacle and
    a 2 micro-usb receptacles, one for power and one for USB OTG.

    The sdio wifi appears to not have an oob irq hooked up, so we rely on sdio-irq
    support for it.

    Signed-off-by: Hans de Goede
    Signed-off-by: Maxime Ripard ”

    ”

    Source, Sourceforge.net

    Reply

  12. Running U-boot on Rpi seems silly. It’s much much slower than the proprietary GPU driven bootloader. I wouldn’t use it personally unless having a need for netboot.

    Reply

  13. Maybe I misunderstand, but do you get a “normal” Fedora on those boards, e.g. Orange Pi PC in my case? What components are supported? Is HDMI and a Desktop Environment supported? Seems it is a recent mainline/vanilla kernel. Until now I assume(d) Armbian supports those boards best. Suddenly Fedora supports all these boards. Someone in the Fedora team worked on that in “stealth mode”? … seems to be too good to be true …

    Reply

    1. Fedora ARM developer team worked on this for a number of years before this article was released. There have been previous releases of Fedora on ARM and there continue to be Fedora on ARM releases. By the way the name of the installer has changed to ‘arm-image-installer’

      Reply

  14. Hat off to Fedora! Re u-boot, I’ve been considering going UEFI on at least one of my aarch64 boards, but u-boot is so much more versatile than UEFI, that the convenience of booting a stock arm64 image ‘right off the bat’ is voided by the convenience of doing low-level maintenance and dt tinkering right from the fw. My firsts OpenFirmware board was the Efika 5200B, and that was an eye-opener.

    Reply

  16. @crashoverride
    haha, right. I guess these device tree “inventors” in the near future will be in the need of “inventing” ACPI. device trees are blatantly pulled off of ePAPR, a tiny OF subset, and they even didn’t make reversion to the Little endianness, OF is BE, and these arm borads are LE. it would be so easy to do that. but nope.

    Reply

    1. @cortex-a72 Device tree predates ACPI by a number of years. It was used in Sun’s OpenBoot which evolved into OpenFirmare. It was invented by Mitch Bradley and he had a hand in advising people in its use.

      Reply

      1. you misunderstood me completely. the talk was not about what is older – OF or ACPI. it was about that DT were NOT invented by linaro, they just pulled them off of OF and brought into ARM. initially the article beginning was this: “Device tree was born several years ago, when Linus Torvalds complained that ARM was a mess”.

        Reply

  17. blu :
    Hat off to Fedora! Re u-boot, I’ve been considering going UEFI on at least one of my aarch64 boards, but u-boot is so much more versatile than UEFI, that the convenience of booting a stock arm64 image ‘right off the bat’ is voided by the convenience of doing low-level maintenance and dt tinkering right from the fw. My firsts OpenFirmware board was the Efika 5200B, and that was an eye-opener.

    even if this is true, it’s only a matter of the UEFI implementations on arm being a rarity and non mature. nothing inherent, rather opposite uboot is a horrible mess looking at whose source code lifts your own self esteem up to the clouds. xD uefi doesn’t prevent one of any imagined low-level “tinkering” of a board configuartion. it’s a matter of an implementation choice.

    Reply

  18. @Christian
    If I understood correctly this new approach does simply combine one of a few generic Fedora 26 userlands with a generic ARMv7 kernel image that enabled all supported platform features (don’t know about Fedora’s patch policy, eg. Armbian’s dev/next kernel branches for all boards contain ~230 patches adding functionality eg. stuff that not yet landed upstream in mainline kernel). Combined with an installation routine that picks up the necessary bootloader stuff (u-boot/SPL) and assembled all of this to bootable OS images that can be burned to an installation media.

    If Fedora doesn’t collect/rebase missing hardware support patches for the various supported boards then you get kernel functionality based on what’s already upstreamed (eg. with a 4.11 kernel and an Orange Pi PC no Ethernet, no THS/throttling and a lot of other missing stuff) and since Fedora is solely providing a recent kernel all the stuff that only works with smelly vendor/legacy kernels (eg. HW accelerated video decoding on most if not all above listed boards) will be missing.

    So if my assumptions are correct (no idea if that’s the case) then this is just the combination of appropriate mainline u-boot + official device tree + an ARMv7 kernel supporting all those boards + a modern userland. In other words: there might be a lot of stuff missing even if a specific device is listed and ‘supported by mainline Linux’.

    Based on the work Armbian did for example a lot of upstream DRAM configs (u-boot) can be considered questionable (overclocking DRAM for no reason being the root cause of instabilities on many boards). No idea whether this is adressed by the Fedora installer using patched bootloaders or not. Then based on specific device support landed already upstream or not many features might simply not work (Allwinner A10/A13/A20 and i.MX6 devices have a clear advantage here since they’re old and boring and therefore software support is mature now). And I also have no idea whether the Fedora userland contains individual performance tweaks for various boards (eg. IRQ affinitiy or optimized cpufreq/dvfs/throttling settings — ‘mainline’ stuff performs often poorly).

    When thinking about this Armbian also provides device tree overlays for sunxi boards in the meantime (as known from Raspberries and BeagleBones) that might be missing with Fedora. And maybe a few more tweaks to make all hardware on the various boards really useable (eg. firmware mess with the common AP6212 vs. AP6212A Wi-Fi/BT chips on many boards). Really don’t know yet since all my personal Fedora tests get postponed again and again 🙁

    BTW: Comparing pure mainline stuff (my assumption about the Fedora approach here that might be totally wrong) with Armbian’s u-boot and kernel patches to ‘fix’ issues and adding special tweaks as part of individual OS images the latter are pretty much distro agnostic. What Armbian does here at this layer is simply the result of looking at these boards from a user perspective trying to squeeze out the max. But I’ll shut up for now and try out the Fedora installer asapissimo on 2 boards 🙂

    Reply

  19. cortex-a72 :
    even if this is true, it’s only a matter of the UEFI implementations on arm being a rarity and non mature. nothing inherent, rather opposite uboot is a horrible mess looking at whose source code lifts your own self esteem up to the clouds. xD uefi doesn’t prevent one of any imagined low-level “tinkering” of a board configuartion. it’s a matter of an implementation choice.

    I have only cursory idea of u-boot’s code, but would you mind sharing your findings in u-boot’s code that have bothered you? Perhaps we can raise awareness of some issues there?

    Reply

  20. it’s that case, where I am better off to not raise anything. xD i am sure uboot is poorly designed, that’s my imho, but i don’t want to go farther with that, since it’s not my interest to improve it. below is my recent notice made when I was trying to figure out where and when it f&cking does the MMC initilization. It’s a chain of function calls I’ve tracked just by looking at the code. mostly those are plain dumb stubs doing nothing. It reflects lack of any structure inside, it’s a clueless mess, which is made into a “just works” state after some time of torturizing yourself.

    start
    ->board_init_f
    ->board_init_r
    ->initr_mmc
    ->mmc_initialize
    ->board_mmc_init
    ->jz_mmc_init
    ->jz_mmc_init_one
    ->do_preinit
    ->mmc_start_init
    ->init

    but hey, they are ingenious with names. xD
    UEFI on the other hand has its structure specified. not that it’s brilliant. but with this on the hands, it’s easier to bring a board support. it’s just yet not very well matured. for me hearing about uboot’s “versatilty” is refreshing, if by “versatility” to understand a good design, extensibilty, flexibilty etc.

    Reply

  21. CNXSOFT can you dig it more or make like video, i dont have the skill but i do have the Mele A1000G around

    Reply

  22. @cortex-a72
    I just checked your example in u-boot 2017.03 and as far as I can see from a quick browse, what you quote is the entire call chain from powering up of a board (i.e. before any mmc activity), through u-boot mmc core API, through board-specific mmc code (i.e. past any u-boot core API). From the POV of u-boot core, the actual mmc initialization occurs from initr_mmc() -> mmc_initialize() -> board_mmc_init() (and a subsequent optional mmc_do_preinit(), for those boards that need it). From board_mmc_init() onwards, a board-specific implementation may decide to include Google TensorFlow to do the mmc initalization – that’s entirely up to the board maintainers. So what am I missing?

    Reply

  23. tkaiser :
    So if my assumptions are correct (no idea if that’s the case) then this is just the combination of appropriate mainline u-boot + official device tree + an ARMv7 kernel supporting all those boards + a modern userland. In other words: there might be a lot of stuff missing even if a specific device is listed and ‘supported by mainline Linux’.

    You are mostly right. Fedora only accept mainline kernel/uboot/dtb.

    Reply

  26. @Rafael Duarte
    Based on @pmos69 link (Hardware Status), you don’t really need to consider it for MeLE A1000G: no network, no USB, and it boots to a black screen without serial console.

    Other boards appear to fare better. The Hardware Status status is not complete though, since not all boards listed above have been tested with F26.

    Reply

  27. Zamir :
    You are mostly right. Fedora only accept mainline kernel/uboot/dtb.

    Well, if it’s pure mainline then not a lot will work on most boards anyway (and both performance and stability is affected since for reasons I don’t understand both mainline submitters and maintainers seems to not care about such stuff)

    Reply

  28. Is it possible to let nanoPC T3 boot from emmc without sdcard?T3 needs sdcard inserted even boot from emmc now. T3 shows color bars when booting without sdcard inserted

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

Khadas VIM4 SBC
Khadas VIM4 SBC