Arm-dev

arm-dev@lists.centos.org

684 discussions

Latest rhel7 nss and nss-softokn won't build on arm
by Troy Dawson 11 Mar '15

11 Mar '15

Hi, Just giving you a heads up about this bug. https://bugzilla.redhat.com/show_bug.cgi?id=1200856 Since it's only for the latest errata release on RHEL7, you might not hit it for a while, depending on how you are doing your build. Troy p.s. Solution is in the bugzilla, as well as the problem.

1 0

Status for aarch64 builds
by Jim Perrin 10 Mar '15

10 Mar '15

Here's where things are for aarch64/ARMv8 currently. http://seven.centos.org/2015/03/building-centos-linux-7-for-armv8/ -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77

2 1

Current F22 uboot/kernel supports sata boot
by Robert Moskowitz 03 Mar '15

03 Mar '15

Kind of; for those devices with sata. You still have to have uboot on the SD card; at some point in the future you will be able to copy it to NAND. So I have modified the installer script to support this; having the small SD card and the sata drive mounted together on your host system for the build step. I have sent my mods in. Just one more step down the road of making this 'easy' for use. Will always need the SD card for firstboot, then some step to copy it to NAND for future boots. I was having some problems at first and saw some intersesting messages on the serial console. Thus I would not be supprised if USB boot would work just as well. I will try that next week with an IDE drive on a USB adapter.

1 1

Re: [Arm-dev] Work in progress ARM v7 port
by Jacco Ligthart 22 Feb '15

22 Feb '15

Hi Howard, As Gordan noted before, I did more ore less the same but then for armv5. As of today the result of that can be found here: http://www.mirrorservice.org/sites/ftp.redsleeve.org/pub/el7/ It might be interesting for you to have a look at the things that required patching or other "special" treatment for mock building. I tried to summarize that all here: http://www.mirrorservice.org/sites/ftp.redsleeve.org/pub/el7/alpha/RS7_issu… (the patches are all here: http://www.mirrorservice.org/sites/ftp.redsleeve.org/pub/el7/alpha/patches/ ) What I wanted is to have RHEL7/CentOS7 to run on the Raspberry Pi model 1 (there was no model 2 when I started) After discussion with Gordan I went for armv5 in stead of armv6, so it would work for more arm devices. > 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 [1]. 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. My build was bootstrapped from the armv5 build of F18 And exactly as you explained, all rpms have been build (at least) twice. Once against F18 (or a combination of F18 and RSEL7) and after that once against the result of that. > 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 [2], a Pi-like small ARM board. The C1 has a couple > of advantages over even the Pi 2: it has a somewhat faster CPU [3], but, > more importantly, it has on-SoC gigabit ethernet [4]. The ODROID is > designed and manufactured by Hardkernel in South Korea. The ODROID is a > bit more expensive (£33 from a UK supplier [5] 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 also took refuge to Odroid after discovering that buildtimes on a Pi1 would seriously hamper this undertaking. I bought an Odroid U3, because this was the cheapest quadcore ARM with 2GB of mem. And my guess is that lots of memory will speedup the build quite a lot. > 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 [6], I ended up grabbing an F21 image made by one > of the ODROID forum members [7]. 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 [8] > 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. I took the easy way. I bought an external USB drive. The SD is now only used for '/boot'. '/' is on the USB disk. > 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 [9]. 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 > [10]. 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 also first build everything in the "build-sys" group (against F18). I thought (wrongly) that having this would mean I could build the rest without further help from F18. It does not work that way, there are numerous circular references in the build dependencies. There are even a lot of packages that depend on themselves :( If I would do it again I would first build *everything* against F18 (or better yet F19) and after that do it all again against itself. Your choice for GA has pro's and con's: - some packages won't build because they have a time-constraint. java comes to mind, which will complain about the change of the turkish currency is more than 10 years ago, but I've seen similar things for outdated certificates in the srpm, etc - other packages FTBFS when build against newer packages than GA. I think I had 5 packages that don't build with the latest java. > 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 [11], or > because they're listed as either "exclusivearch", which means they > should only be built on a specific list of architectures [12]. 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 > [13]. Very much on the positive side, after a 36 hour build, the third > build attempt of libreoffice completed successfully [14]. I found that I often do want to build the exclusivearch packages. They are sometimes needed for dependencies, or are just perfectly good packages for arm. I also sometimes disable the testsuites, but elfutils is not one of them. > 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 [15]. I made the kernel build (even the latest version, which was more of a challenge), but till now I've only used the headers for building other packages. I think my kernel srpm patch can be used to build a perfectly working arm kernel *if you have the right .config* I noticed that both the raspberrypi and the odroid have quite some patches against the standard kernel and I don't think it is worth it to try and merge that to RH's kernel. I think I should put this a bit stronger: I don't trust RH to make a good basis for an ARM kernel. A good example is that one of the patches they did against the kernel "missed" the arm part of the patch (resulting in FTBFS). The original patch I saw *did* have the ARM part, so RH must have removed that somewhere. Point is that if you're not a kernel hacker it will be damn difficult to assess if the fixes they did to the kernel are present in your ARM build, etc. In the end I just package the pre-compiled stuff from raspberry/odroid Good luck on your endeavor and feel free to ask if you need any help. Jacco

2 2

Booting from sata
by Robert Moskowitz 19 Feb '15

19 Feb '15

I noticed in a recent post to the u-boot list that Hans said that booting from sata now works with the latest upstream uboot and 3.19 kernel. So I asked him to clearify and he said that you still need the SD card, but just for the uboot. ALL partitions can go on your sata drive. I further suspect that even I can figure out how to get the uboot to NAND, so that no SD card is needed. This might even be able to be implemented in an install script that a lot of users can deal with. And that is where we get past crawling to walking. When you run a script, only providing the location of the .xz file and your board, and the install goes. Well at least to the part where you have a bootable drive to install into your system.

1 1

Work in progress ARM v7 port
by Howard Johnson 18 Feb '15

18 Feb '15

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 [1]. 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 [2], a Pi-like small ARM board. The C1 has a couple of advantages over even the Pi 2: it has a somewhat faster CPU [3], but, more importantly, it has on-SoC gigabit ethernet [4]. The ODROID is designed and manufactured by Hardkernel in South Korea. The ODROID is a bit more expensive (£33 from a UK supplier [5] 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 [6], I ended up grabbing an F21 image made by one of the ODROID forum members [7]. 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 [8] 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 [9]. 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 [10]. 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 [11], or because they're listed as either "exclusivearch", which means they should only be built on a specific list of architectures [12]. 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 [13]. Very much on the positive side, after a 36 hour build, the third build attempt of libreoffice completed successfully [14]. 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 [15]. 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. Cheers! [1] 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 fixes. [2] http://www.hardkernel.com/main/products/prdt_info.php?g_code=G141578608433 [3] Four 1.5GHz cores versus the Pi 2's four 900MHz cores. [4] Contrasting with the Pi's fast ethernet adapter wired to the onboard USB hub. [5] http://www.lilliputdirect.com/odroid-c1-quad-core-computer [6] Not helped by me not having bought a serial cable, so I couldn't watch the bootloader messages. [7] http://forum.odroid.com/viewtopic.php?f=114&t=8872 [8] SSD backed, using a Samsung EVO 850 SATA SSD. [9] To the point where it might save an entire OS rebuild cycle, which will be a not inconsiderate amount of effort. [10] For example, one night I queued up all SRPMs with names starting with "lib"; unfortunately I forgot that that would include libreoffice... [11] So we can use the C7 builds unmodified. [12] Packages in this group are generally platform-specific packages like efibootmgr or dmidecode which make no sense on ARMv7 platforms. [13] Due to a single failing test that wasn't run in the Fedora 19 elfutils build. [14] 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. [15] Apologies for all the footnotes, I like them. -- HJ

7 21

Project status
by Marcin Trendota 03 Dec '14

03 Dec '14

Hello. I'd like to know what is the status if arm-dev project? I recently bought A20- OlinuXino-MICRO board (https://www.olimex.com/wiki/A20-OLinuXino-MICRO) and successfully run it with their official Linux image. But it's Debian... I don't have any experience in porting Linux to other architectures and configuring for particularly board but i'm eager to learn it (i plan to use some kind of embedded computer to develop home automation system). Could you point me into right direction - how to begin and what should i know (i've been compiling kernels some time ago but i can't say i'm a kernel hacker). I would like to use CentOS for my purposes (i have some more ideas for small appliances and they are mainly ARM-based i think). Thanks for any help and information. -- Over And Out MoonWolf

3 9

Kernel questions
by Robert Moskowitz 02 Dec '14

02 Dec '14

Both my Fedora 19 & 20 remixes have 'static' kernels. What I mean by that, is when I do a yum update, I have to --exclude=kern* or I have an ubootable system. And that is not enough as you really have to work at it with some packages referencing the newer kernel rpms. In Fedora 21 they have a current kernel that works on a lot of boards. So the question for you people that understand kernels (which I do not): Is it possible to take the Fedora 19 kernel and get it working for all boards? or Is it better to take the Fedora 21 kernel and backport it to F19/Centos7? or A kernel is really a kernel and the Fedora 21 kernel will work just fine with Centos7-arm. After uboot and kernel, it is 'just' a matter of recompiling stuff for arm. Noarch rpms can just be moved over; or else they are really not noarch... Note that for my epel6 needs for RSEL6, I took a number of noarch rpms from the epel6-i386 repo and locally installed them to meet some messed up versioning challenges I had for my mailserver.

1 0

Boards supported by F21 uboot
by Robert Moskowitz 02 Dec '14

02 Dec '14

Here is the list of boards supported in the F21 beta: ls /usr/share/uboot/ A10-OLinuXino-Lime arndale Cubieboard Mele_A1000 panda snowball wandboard_quad A10s-OLinuXino-M Bananapi Cubieboard2 Mele_A1000G paz00 trimslice wandboard_solo A13-OLinuXino beagle Cubietruck Mini-X riotboard udoo_quad A13-OLinuXinoM beaglebone highbank Mini-X-1Gb smdkv310 uevm A20-OLinuXino_MICRO cm_fx6 jetson-tk1 origen snow wandboard_dl

1 0

Lessons learned on state of uboot while working on F21
by Robert Moskowitz 08 Sep '14

08 Sep '14

I have been kind of active on F21 testing on my Cubieboards, and have learned a number of unsettling facts. Basically, for the Allwinner SOC, uboot is missing a lot and it probably will not be until spring that key components will work. Most noteably video! Now I am running Redsleeve successfully on my Cubieboards, and to do that I used the uboot from the Fedora 19 remix which uses the old Allwinner 'special' SunXi 3.4 kernel which has video support, but lacks things like support for the Cubietruck WiFi. See http://linux-sunxi.org/Linux_mainlining_effort for uboot status. There is a flurry of updates on the uboot list, the target for a major code freeze for upstream is in October, but I don't recognize many Allwinner updates (lots of Freescale posts). But on the Fedora-arm list it was made clear that F21 will be lacking a lot of functionality for Allwinner boards; good enough for servers, but not workstations. And it will be F22 to target what was not included. I am seriously considering alternative boards like the Wandboard, but it costs more, and my CFO (wife) was really complaining about how much money I recently spent on hardware (even with a 15 month ROI). So for now I am staying with the Cubies. So on to any possible testing. Karanbir stated in an earlier post to use a F19 build as the basis for a Centos7 build. That would mean the older Sunxi 3.4; which works. But no updates. Not the newer 3.16. To see what I did for RSEL see: http://cdn.opensxce.org/redsleeve/el6/cubieboard2/ I have to update the README with some caveats I have learned while working with RSEL (like selinux not working, and you have to install cronie as it is not part of the minimal image). I am interested in contributing, but... Travel and Holidays over the next month. And most of my Cubies are now in production.

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Arm-dev