From Fedora Project Wiki
Line 7: Line 7:
<fixme>
<fixme>


Fedora 20 for ARM includes two image types - one for use with platforms requiring a VFAT partition (such as Texas Instruments's OMAP4-based PandaBoard), the other for use with devices that boot from an EXT3/4 partition (such as CompuLab's Tegra2-based TrimSlice). For each of these image types, there are a number of images providing for a variety of desktop choices (including MATE, KDE, XFCE, LXDE, SOAS), as well as a minimal image that does not include the desktop. Any of these images can be used with QEMU on an x86_64 desktop to emulate a fully functional ARM environment.
Fedora 20 Alpha for ARM includes two image types - one for use with platforms requiring a VFAT partition (such as Texas Instruments's OMAP4-based PandaBoard), the other for use with devices that boot from an EXT3/4 partition (such as CompuLab's Tegra2-based TrimSlice). For each of these image types, there are a number of images providing for a variety of desktop choices (including MATE, KDE, XFCE, LXDE, SOAS), as well as a minimal image that does not include the desktop. Any of these images can be used with QEMU on an x86_64 desktop to emulate a fully functional ARM environment.


The image-based installation process involves downloading an image file (depending upon the target type and desktop/non-desktop option desired), inserting removable media into a "host" system (e.g. an ARM or x86_64 PC class desktop, laptop, etc.) and performing a few simple commands to write this image onto the media. This media is then used by the ARM "target" system to boot the Fedora 20 environment.
The image-based installation process involves downloading an image file (depending upon the target type and desktop/non-desktop option desired), inserting removable media into a "host" system (e.g. an ARM or x86_64 PC class desktop, laptop, etc.) and performing a few simple commands to write this image onto the media. This media is then used by the ARM "target" system to boot the Fedora 20 environment.

Revision as of 18:04, 23 September 2013

Fedora 20 Alpha for ARM

The Fedora ARM team is pleased to announce that the Fedora 20 Alpha for the ARM Architecture is now available for download from:

<fixme>

Fedora 20 Alpha for ARM includes two image types - one for use with platforms requiring a VFAT partition (such as Texas Instruments's OMAP4-based PandaBoard), the other for use with devices that boot from an EXT3/4 partition (such as CompuLab's Tegra2-based TrimSlice). For each of these image types, there are a number of images providing for a variety of desktop choices (including MATE, KDE, XFCE, LXDE, SOAS), as well as a minimal image that does not include the desktop. Any of these images can be used with QEMU on an x86_64 desktop to emulate a fully functional ARM environment.

The image-based installation process involves downloading an image file (depending upon the target type and desktop/non-desktop option desired), inserting removable media into a "host" system (e.g. an ARM or x86_64 PC class desktop, laptop, etc.) and performing a few simple commands to write this image onto the media. This media is then used by the ARM "target" system to boot the Fedora 20 environment.

Determining the location of installation media

NOTE The following instructions will provide a means to determine the correct device to use in the examples below for "location-of-your-media". It is extremely important to verify the location chosen as a target of this installation, since an incorrect location could result in destructive damage to one or more unrelated host filesystems containing unrelated data. If in doubt following these instructions, consult an expert or ask for assistance on the mailing list, or #fedora-arm IRC.

Determine the location of your chosen installation media, such as an SD Card. This can be done conveniently using the "lshw" package, which may not be installed on your host system:

sudo yum install lshw
sudo lshw

The output will contain information about removable media, such as (the device name will quite possibly differ on your system from this example):

     *-scsi:1
          physical id: 3
          bus info: usb@2:1.8.3
          logical name: scsi6
          capabilities: emulated scsi-host
          configuration: driver=usb-storage
        *-disk
             description: SCSI Disk
             product: SD Card Reader
             vendor: APPLE
             physical id: 0.0.0
             bus info: scsi@6:0.0.0
             logical name: /dev/sdb
             version: 2.00
             capabilities: removable
             configuration: sectorsize=512
           *-medium
                physical id: 0
                logical name: /dev/sdb

In the example, the device location is /dev/sdb, which will quite likely differ on your system.

For the CompuLab TrimSlice

IMPORTANT
You must use the latest Device Tree enabled U-Boot to boot the Fedora 20 Trimslice image, which you can find here. Failure to do so will result in a non-booting system.

Download the image of your choice for use with the TrimSlice:

TYPE= # options include KDE, LXDE, XFCE, SoaS, Mate and Minimal
wget http://download.fedoraproject.org/pub/fedora-secondary/releases/20/Images/armhfp/Fedora-$TYPE-armhfp-20-1-sda.raw.xz

Copy the image to the intended media:

xzcat Fedora-$TYPE-armhfp-20-1-sda.raw.xz > /dev/<location-of-your-media> 

Insert into the TrimSlice and boot. Fedora will boot to an initial setup screen allowing you to create your user, set the root password and timezone.

For Versatile Express Emulation with QEMU

No ARM hardware? No problem! Even without hardware, it is possible to run the Fedora 20 for ARM images using the QEMU emulator program. Any image can be used, and you can choose a script method or manual depending on your preference.

Manual Preparation

TYPE= # options include KDE, LXDE, XFCE, SoaS, Mate and Minimal
wget http://download.fedoraproject.org/pub/fedora-secondary/releases/20/Images/armhfp/Fedora-$TYPE-armhfp-20-1-sda.raw.xz

Extract the image:

unxz Fedora-$TYPE-armhfp-20-1-sda.raw.xz

Mount the image and extract the kernel and initramfs for use with booting.

sudo kpartx -av Fedora-$TYPE-armhfp-20-1-sda.raw

Make a temporary mount point

mkdir /tmp/boot
sudo mount /dev/mapper/loop0p1 /tmp/boot
sudo cp /tmp/boot/initramfs-3.9.5-301.fc20.armv7hl.img .
sudo cp /tmp/boot/vmlinuz-3.9.5-301.fc20.armv7hl .
sudo umount /tmp/boot
sudo kpartx -dv Fedora-$TYPE-armhfp-20-1-sda.raw

To boot:

sudo qemu-system-arm -machine vexpress-a9 -m 1024 -nographic -net nic -net user \
 -append "console=ttyAMA0,115200n8 rw root=/dev/mmcblk0p3 rootwait physmap.enabled=0" \
 -kernel vmlinuz-3.9.5-301.fc20.armv7hl \
 -initrd initramfs-3.9.5-301.fc20.armv7hl.img \
 -sd Fedora-$TYPE-armhfp-20-1-sda.raw \

For convenience you can also download a script for booting the system here. To run the script:

chmod 755 boot-vexpress
./boot-vexpress -h
Usage: ./boot-vexpress [--gui] --kernel=vmlinuz... --ramfs=initramfs --image=fsimage [--dtb=vexpress.dtb]

To boot the image:

sudo ./boot-vexpress --kernel=vmlinuz-3.9.5-301.fc20.armv7hl --ramfs=initramfs-3.9.5-301.fc20.armv7hl.img --image=Fedora-$TYPE-armhfp-20-1-sda.raw

Booting with device tree is possible, although passing --gui for graphics will not work at this time (this is due to ongoing platform reword occurring within the Versatile Express kernel code). Booting without device tree is recommended for F-20, as it will work in both serial and graphics mode, whereas passing a DTB will only work with serial.

livemedia-modifier

The livemedia-modifier tool written by Jon Chiappetta can be used to perform the above steps and is available here. After installing you can run the script using the following example:

# Extract the image
unxz Fedora-$TYPE-armhfp-20-1-sda.raw.xz
# Run livemedia-modifier
livemedia-modifier --image=Fedora-$TYPE-armhfp-20-1-sda.raw --platform=vexpress --nocompress

The modifier will create a copy of the original image, all changes will be made on the copy preserving the original image integrity.

Additional usage instructions can be found here.

Calxeda EnergyCore (HighBank)

Fedora 20 for ARM includes support for systems that are able to perform a network installation using a kickstart, including enterprise hardware such as the Highbank. A working kickstart can be found here.

For more detailed instructions on setting this up, please visit this page.

Resize the Root Filesystem

By default the images in Fedora are 8GB and can be resized to fit your media.

yum install dracut-modules-growroot cloud-utils-growpart

Rebuild the initramfs or install a new kernel to use the module.

#Rebuild your existing initramfs

KERVER= #use your kernel version eg - '3.9.5-301.fc20.armv7hl.tegra' for the Trimslice

dracut -f --kver=$KERVER
mkimage -A arm -O linux -T ramdisk -C none -a 0 -e 0 \
 -n initramfs-$KERVER \
 -d /boot/initramfs-$KERVER.img /boot/uInitrd-$KERVER

# When the system is rebooted, the root partition will be resized to fill the remaining space on the media. Lastly you will need to increase the filesystem size:

ROOT_PART= # location of your root partition, usually '/dev/sda3' or '/dev/mmcblk0p3'

resize2fs $ROOT_PART

Booting for the First Time

Initial-setup

  • During the first boot the system will launch the 'initial-setup' utility. For graphical images this will occur on the display, for minimal images this will occur on the serial console. Failure to complete the initial-setup will prevent logging into the root account. To log in to the root account without completing the initial-setup you will need to minimally edit '/etc/passwd' file and remove the 'x' from the line beginning with 'root' (this will allow you to log into the root account without entering a password).


Known Issues

  • A known issue exists wherein OMAP3-based devices, such as the Texas Instruments BeagleBoard and BeagleBone, are are unable to boot the standard installation images (this is due to a Cortex-A15 errata option that was enabled in the kernel and has been disabled). We hope to issue updated installation images once Fedora 20 transitions to Linux kernel 3.10. At this time, technical users may choose to manually replace the kernel in order to enable support for these devices. Others are encouraged to wait for updated images.