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:
sudo apt install docker
sudo docker pull fedora
sudo umount /dev/sdd*
sudo docker run -i -t -v /media/hdd:/mnt --device==/dev/sdd --device=/dev/sdd3 fedora:latest /bin/bash
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…
dnf install fedora-arm-installer xz file
…and check the usage:
[root@f2a5f32ac868 /]# fedora-arm-image-installer
--image=IMAGE - xz compressed image file name
--target=TARGET - target board
--media=DEVICE - media device file (/dev/[sdX|mmcblkX])
--norootpass - Remove the root password
-y - Assumes yes, will not wait for confirmation
--version - Display version and exit
--resizefs - Resize root filesystem to fill media device
--addconsole - Add system console to extlinux.conf
--addkey= - /path/to/ssh-public-key
Example: fedora-arm-image-installer --image=Fedora-Rawhide.xz --target=Bananapi --media=/dev/mmcblk0
For list of supported boards please check SUPPORTED-BOARDS file.
Let’s see how many boards are supported in /usr/share/doc/fedora-arm-installer/SUPPORTED-BOARDS file:
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
cm_fx6 mx6cuboxi novena riotboard wandboard
am335x_boneblack am57xx_evm kc1 omap3_beagle omap4_panda omap5_uevm
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:
fedora-arm-image-installer --image=/mnt/Downloads/Fedora-Server-armhfp-26-1.5-sda.raw.xz --target=rpi3 --media=/dev/sdd --resizefs
You’ll then be ask to confirm:
= Selected Image:
= Selected Media : /dev/sdd
= U-Boot Target : rpi3
= Root partition will be resized
******** WARNING! ALL DATA WILL BE DESTROYED ********
Type 'YES' to proceed, anything else to exit now
= Proceed? YES
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.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
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… Read more »
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. Usage: update-uboot <options> --target=TARGET - target board [Bananapi|beaglebone|Cubieboard|Cubieboard2|Cubietruck|Mele_A1000|Mele_A1000G|panda|trimslice|wandboard_dual|wandboard_quad|wandboard_solo] --media=DEVICE - media device file (/dev/[sdX|mmcblkX]) --tag=KOJI TAG - koji tag (Default is f22. f21, f21-updates etc..) Example: update-uboot --target=panda --media=/dev/mmcblk0 12345678 Usage: update-uboot <options> --target=TARGET - target board [Bananapi|beaglebone|Cubieboard|Cubieboard2|Cubietruck|Mele_A1000|Mele_A1000G|panda|trimslice|wandboard_dual|wandboard_quad|wandboard_solo] --media=DEVICE - media device file (/dev/[sdX|mmcblkX]) --tag=KOJI TAG - koji tag (Default is f22. f21, f21-updates etc..) Example: update-uboot… Read more »
Heh, seems like i complained about the exact same device 3 years ago: https://patchwork.kernel.org/patch/4158771/ Who besides Hans knows what this device is, does he still own it today, or know where it is, or which one it is exactly?
But it is by no means the only one in there.
Yeah, finding any kind of information about that R7 dongle is really a challenge.
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 and most other non-x86 PCI chipset vendors.” Device tree existed before ARM. ARM has simply popularized… Read more »
Actually Device Tree was originally designed and implemented by Mitch Bradley when he worked for Sun
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: A10-OLinuXino-Lime Lamobo_R1 ba10_tv_box orangepi_pc A10s-OLinuXino-M Linksprite_pcDuino cl-som-am57x orangepi_plus A13-OLinuXino Linksprite_pcDuino3 clearfog orangepi_plus2e A13-OLinuXinoM Linksprite_pcDuino3_Nano cm_fx6 orangepi_zero A20-OLinuXino-Lime MK808C colorfly_e708_q1 pine64_plus A20-OLinuXino-Lime2 MSI_Primo73 difrnce_dit4350 polaroid_mid2809pxe04 A20-OLinuXino_MICRO MSI_Primo81 dserve_dsrv9703c pov_protab2_ips9 A20-Olimex-SOM-EVB Marsboard_A10 i12-tvbox q8_a13_tablet Ampe_A76 Mele_A1000 iNet_86VS q8_a23_tablet_800x480 Auxtek-T003 Mele_A1000G_quad icnova-a20-swac q8_a33_tablet_1024x600 Auxtek-T004 Mele_I7 inet86dz q8_a33_tablet_800x480 Bananapi Mele_M3 jesurun_q5 r7-tv-dongle Bananapi_M2_Ultra Mele_M5 jetson-tk1 riotboard Bananapro Mele_M9 kc1 rpi2 CHIP Mini-X mk802 rpi3 CSQ_CS908 Orangepi mk802_a10s stih410-b2260 Chuwi_V7_CW0825 Orangepi_mini mk802ii sunxi_Gemei_G9 Colombus Sinlinx_SinA31s mx6cuboxi trimslice Cubieboard UTOO_P66 none udoo Cubieboard2 Wexler_TAB7200 novena… Read more »
R7 tv-dongle is an A10s based hdmi tv dongle, with 1G RAM, 4G nand flash, and rtl8189es sdio wifi. It has a standard male hdmi connector, an USB host port using an USB-A receptacle and a micro-usb receptacle for both power and USB OTG.
Why the mistry, it was probable a branded item similar to this
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?
How certain are you that this is not some other, more ore less incompatible, A10s tv stick?
@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:… Read more »
And from way back on CNX-software , Smallart U-Host AllWinner A10 article in the comments a A10s dongle on Aliexpress
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.
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 …
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’
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.
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.
@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.
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”.
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… Read more »
@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… Read more »
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?
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… Read more »
CNXSOFT can you dig it more or make like video, i dont have the skill but i do have the Mele A1000G around
@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 –… Read more »
You are mostly right. Fedora only accept mainline kernel/uboot/dtb.
@Jean-Luc Aufranc (CNXSoft) Fedora do ship “Unified” image since Fedora 20 or so. It’s really not something new.
That method is not actually new for Fedora they’ve done it for a long time -> https://twitter.com/nullr0ute/status/897085896176041984
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.
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)
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
Recent video about Fedora and 96Boards