[Arm-dev] Work in progress ARM v7 port
rgm at htt-consult.com
Tue Feb 17 19:17:08 UTC 2015
Great to see this.
You could be using the Fedora 21 arm builds and source for your starting
point. It has direct installation on a number of cards. You have to dig
a bit on the Fedora download site to find them, but they are there.
Or go with F22 beta that is just starting. This has the advantage of a
newer uboot and 3.19 kernel; both give better support for a number of
boards, including work on the Banana Pi R1 (makes a great router).
F22 can be gotten from
Now I use the Cubieboards. These have sata, so you can have even better
performance and safety than working with an SD card. I have a number
running both Redsleeve 6 and Fedora 21. Anything with the Allwinner
SoC, you want F22 uboot and kernel to get video support (I am having
problems with the usb disconnecting and waiting for a fix on that).
Raspberry Pi 2 work is also being done with F22 (well Rawhide until
today when F22 build got approved for beta).
Check out the Fedora-arm list for what has been going on there.
But great to see this post.
On 02/17/2015 01:48 PM, Howard Johnson wrote:
> Hello all. Recently I've been having a bit of fun trying to port
> CentOS 7 to ARMv7, and I thought I'd share info on what I've been
> doing with the list.
> As a long-time Red Hat family distribution user, I've been interested
> in a CentOS build for ARM since the release of the originally
> Raspberry Pi. However, it's only with the release of RHEL 7 that a
> source code base that largely works on ARM has been available to
> CentOS . The announcement and release of the new, faster,
> quad-core ARMv7-based Raspberry Pi 2 sounded like an ideal reason to
> have a go at making a CentOS-like RHEL rebuild for ARM, so I ordered a
> couple of Pi 2s, and started having a think about how I'd go about
> building EL7.
> Having been on the periphery of the CentOS project for quite a while,
> I knew how CentOS 7 was built: the RHEL 7 sources were rebuilt
> multiple times; first against the public RHEL 7 beta, then against the
> results of this build, then against then those results, and so on.
> Ideally, a similar process could be used to built EL7 for ARM, but of
> course there has never been a RHEL 7 release for ARM of any sort.
> Fortunately, Fedora 19, which RHEL 7 was forked from, does have a
> public (and functional) ARM release. So an EL7 ARM port can be
> bootstrapped from the Fedora binary RPMs.
> Of course, before I could start rebuilding CentOS sources, I'd need an
> OS image to rebuild on. Fortunately, the Raspberry Pi's bootloader
> system is pretty simple: the Pi's firmware looks for specifically
> named files in the VFAT-formatted first partition of the SD card. The
> Fedora 19 Minimal image has an ext4 /boot partition which is easily
> reformatted, and populated with the contents of /boot from the Pi 2
> Rasbian image, and the kernel modules to go with the Rasbian-shipped
> kernel copied to the ext4 / filesystem. A quick (not really) dd of
> the image to an SD card, and I had a booting Pi 2. The next step was
> to test out running mock to build Fedora 19 chroots ready to build
> packages in. Testing showed that it took the Pi roughly 8m30s to
> create a basic F19 mock chroot on the SD card.
> At the same time as starting out working with the Pi 2, a friend
> pointed me at the ODROID C1 , a Pi-like small ARM board. The C1
> has a couple of advantages over even the Pi 2: it has a somewhat
> faster CPU , but, more importantly, it has on-SoC gigabit ethernet
> . The ODROID is designed and manufactured by Hardkernel in South
> Korea. The ODROID is a bit more expensive (£33 from a UK supplier 
> versus the £25 Pi 2), but still quite affordable. Realising that
> building RPMs on a Pi on the SD card or over the network would be very
> slow, I ordered a C1 to try.
> I was really rather pleased with the C1 when it arrived. After trying
> and failing to modify the Fedora 19 ARM Minimal image with an
> ODROID-specific kernel , I ended up grabbing an F21 image made by
> one of the ODROID forum members . The (one of the) nice thing(s)
> about building RPMs in mock is that as long as the host OS can run
> mock, it doesn't really matter what the host OS is, so a Fedora 21 OS
> for the C1s is fine.
> Of course, even the ODROID wouldn't be able to make mock chroots very
> quickly on their SD card, but the built-in gigabit ethernet makes
> another option quite sensible: iSCSI. By mounting a block device 
> from a server over iSCSI, the C1 can create an F19 chroot in about
> 2m40s. Having decided the C1 was better for the builder job than the
> Pi 2, I borrowed another C1 from my friend, and put an order in for
> two more.
> In the meantime, I made a start on building packages using the C1. The
> sensible starting point was building the C7 versions of the packages
> that go into the basic mock build chroot. The basic idea here is that
> the sooner that the set of packages used to build all packages is
> replaced with the C7 versions, the closer the OS will be to a "true"
> C7 OS . Once this base set was built, the order of the remaining
> 1000+ SRPMs is a bit less critical, and more at the mercy of my random
> whims . I should also note that I'm concentrating on building the
> CentOS 7 GA package set, not any of the updates. Once I have a C7 GA
> package set I'm happy with, then I'll look at all the package updates
> from GA to current.
> I was originally planning to knock up a script or two to wrap mock and
> do createrepo runs. Instead I decided to dust off Plague, the old
> build system Seth Vidal and co wrote for Fedora Extras. Plague takes
> care of managing a queue of SRPMs to distribute to multiple builders,
> running builds, collecting resulting logs and RPMs, and making yum
> repos. Plague is a tad old, and needed a few code changes to support
> ARM architectures. It's also a bit... tempremental at times, as the
> central manager process has issues spotting when builders come and go,
> but overall it's done quite well.
> So what's the current status of the rebuild effort? Of the 2481 SRPMs
> in CentOS 7.0.1406 (the GA C7 release), 1125 don't need to be rebuilt
> for ARM, either because they're entirely noarch packages , or
> because they're listed as either "exclusivearch", which means they
> should only be built on a specific list of architectures . Of the
> remaining 1356 packages, 943 have been successfully rebuilt, 62 have
> failed to build, and 351 haven't been attempted yet. Thus far only
> two RPMs have needed to be modified: centos-release had to be altered
> to not conflict with the Fedora 19 systemd (both packages contain
> /usr/lib/systemd/system-preset/90-default.preset), but is now replaced
> with the stock C7 version, and elfutils has had its test suite
> disabled . Very much on the positive side, after a 36 hour build,
> the third build attempt of libreoffice completed successfully .
> The other thing that's worth saying is that I've not yet looked at any
> ARM-specific "special" stuff, like an ARM kernel build, or any
> bootloader support. That's potentially hard stuff, and will take some
> thinking about .
> I'm planning to put the various hacky scripts I'm using into a github
> repo or similar, and I'll be posting status updates in the future with
> how I get on.
>  RHEL6's Fedora 12/13-derived codebase largely predates the Fedora
> ARM effort, whereas the Fedora 19 base of RHEL 7 had an actively
> maintained ARM secondary architecture; fixes to Fedora packages for
> ARM were incorporated into Fedora proper, and RHEL 7 inherited these
>  Four 1.5GHz cores versus the Pi 2's four 900MHz cores.
>  Contrasting with the Pi's fast ethernet adapter wired to the
> onboard USB hub.
>  http://www.lilliputdirect.com/odroid-c1-quad-core-computer
>  Not helped by me not having bought a serial cable, so I couldn't
> watch the bootloader messages.
>  http://forum.odroid.com/viewtopic.php?f=114&t=8872
>  SSD backed, using a Samsung EVO 850 SATA SSD.
>  To the point where it might save an entire OS rebuild cycle, which
> will be a not inconsiderate amount of effort.
>  For example, one night I queued up all SRPMs with names starting
> with "lib"; unfortunately I forgot that that would include libreoffice...
>  So we can use the C7 builds unmodified.
>  Packages in this group are generally platform-specific packages
> like efibootmgr or dmidecode which make no sense on ARMv7 platforms.
>  Due to a single failing test that wasn't run in the Fedora 19
> elfutils build.
>  The first died when the C1 ran out of RAM, which made me add
> iSCSI-backed swap to all the builders, while the second ended when I
> found that the libreoffice build requires more than 16GB of space; on
> the bright side I found out that the iSCSI LUNs can be resized
> entirely online.
>  Apologies for all the footnotes, I like them.
More information about the Arm-dev