I would like to introduce myself to the group. I have recently
received an IGEPv2 board , which is based on the Beagle Board, but
with wifi, bluetooth, ethernet, and more RAM. I'm still at the "wow,
it's tiny and it runs Linux" stage. I should get a bit more time over
the next month and Christmas to play around properly with it.
I'm new to embedded development, but neither new to Linux nor ARM
(writing my first ARM assembly some 15 years ago). However, for the
past 6 years I've not even built a Linux kernel, preferring to use the
default kernel in Fedora for simplicity :)
Firstly, a thank you to those involved in Fedora ARM for getting it to
this stage. If I get the time, I'd really like to contribute some
(probably small) effort to help get Fedora ARM working well on the
IGEPv2 and Beagle Board. As I progress, I'd like to know what I can
do to help.
In the meantime, I have some questions. Apologies in advance if these
1) There are various different kernels from different sources. I'm
used to there being a small set of "right" kernels (that is, Fedora's
idea of "right") for x86. I fully appreciate that different ARM-based
boards are quite different in capabilities (like different instruction
a) Is there likely to be some standardised vanilla Fedora ARM kernel
source? (Or is that simply the source RPM available for Fedora?)
Then patches /could/ be offered for the more common systems (e.g.
Beagle Board & clones, SheevaPlug).
b) Would it then make sense to offer these as pre-built RPMs for common systems?
c) Is there any guidance on which version is good to use as a base?
I've seen quite different kernel versions being used (from 2.6.27 to
2) I understand a little bit about the different calling conventions,
FP differences (e.g. soft FPU versus VFP), and instruction set
differences (v5 versus v7).
a) Can the kernel can be safely built with a different instruction set
targeted? (I know there are different optimisation options passed to
GCC. Apologies if this seems a bit newbie-ish.)
b) For FP-heavy programs (e.g. ogg encoding), is it possible to build
the packages with VFP/NEON but still get them to work in a soft FPU
system? I'd imagine any call to an external library would have to
somehow be defined to use a different calling standard.
3) There seem to be some missing dependencies in the packages in the
current Fedora ARM repository. For example, emacs is requiring
libotf, which doesn't seem to be there in the repository. And
likewise with the xorg-x11-font* packages needing ttmkdir. I'm
confused as to how the RPM could have been successfully built without
it. What am I missing?
4) I see there has been some discussion over unaligned data access.
(Oh, I remember that from the ARM2 days.) It seems as if the
Cortex-A8 cores allow unaligned data access when set up to do so .
Does this, in any way, help with the compatibility of packages
5) I've managed to get various source packages missing from the Fedora
ARM repositories to compile successfully (natively). I guess there is
a reason why there are not in the repos right now -- is that reason
down to time and priorities, or is there some blocking bugs with many
of these packages?
I look forward to being able to contribute something back into Fedora!
today I posted first enablement patches for Cavium Thunder.
See here for the thread:
The patches are publicly hosted on kernel.org:
We will add more patches for Thunder soon.
Please take a look at the patches and consider them for integration
into the arm64 Fedora kernel. Let me know if you have questions or how
I could help adding Thunder support to Fedora.
I will also be at Flock in Prague next week. Maybe we can meet there
and start a discussion on this.
----- Forwarded message from Robert Richter <rric(a)kernel.org> -----
Subject: [PATCH 0/5] arm64, thunder: Enable Cavium Thunder SoC Family
Date: Wed, 30 Jul 2014 17:06:29 +0200
From: Robert Richter <rric(a)kernel.org>
To: Catalin Marinas <catalin.marinas(a)arm.com>, Will Deacon <will.deacon(a)arm.com>, Rob Herring <robh+dt(a)kernel.org>, Arnd Bergmann <arnd(a)arndb.de>
Cc: linux-kernel(a)vger.kernel.org, linux-arm-kernel(a)lists.infradead.org, Robert Richter <rrichter(a)cavium.com>
X-Mailer: git-send-email 2.0.1
From: Robert Richter <rrichter(a)cavium.com>
This initial patches enable Cavium Thunder SoC Family. The patches add
Kconfig and devicetree support and then add Thunder to the defconfig.
The last patch is unrelated to Thunder and enables the tmpfs mount
option for a more convinient use of defconfig with distros.
The Thunder system needs more enablement patches for subsystems and
devices, this includes network, ahci, gicv3/gicv3-its, pci, smmu, kvm.
We will send separate patch sets for these. All of them base on this
Patches are available here:
Radha Mohan Chintakuntla (3):
arm64, thunder: Add Kconfig option for Cavium Thunder SoC Family
arm64, thunder: Add initial dts for Cavium Thunder SoC
arm64, thunder: document devicetree bindings for Cavium Thunder SoC
Robert Richter (2):
arm64, defconfig: Enable Cavium Thunder SoC in defconfig
arm64, defconfig: Enable tmpfs mount option
.../devicetree/bindings/arm/cavium-thunder.txt | 10 +
Documentation/devicetree/bindings/arm/cpus.txt | 1 +
arch/arm64/Kconfig | 6 +
arch/arm64/boot/dts/Makefile | 1 +
arch/arm64/boot/dts/thunder-88xx.dts | 387 +++++++++++++++++++++
arch/arm64/configs/defconfig | 2 +
6 files changed, 407 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/cavium-thunder.txt
create mode 100644 arch/arm64/boot/dts/thunder-88xx.dts
----- End forwarded message -----
-----BEGIN PGP SIGNED MESSAGE-----
I have been working with Ian McLeod on getting oz and imagefactory
running on arm. I used the resulting work to build a docker base image
for arm. docker is installable on arm in f22 and rawhide though the
registry does not work correctly since it only supports x86_64.
I figured I would put the base image up at I have tested that it
loads with "docker load -i
Fedora-Docker-Base-22_Alpha_TC8-20150302.armv7hl.tar.xz" and that it
runs bash okay with "docker run -t -i
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
-----END PGP SIGNATURE-----
I assume that we will be rebasing u-boot to the just released v2015.01
for F-22? But I was wondering if there is any chance we can jump to
v2015.04 ? The reason I'm asking is that things are progressing
quite rapidly on the u-boot side, at least with Allwinner SoC support,
I've just send a pull-req for v2015.04 with the following highlights:
1) Improved sun6i (A31) support, including support for the A31s variant and
automatic assignment of a SoC serial based MAC address for ethernet
2) Full sun8i (A23) support including DRAM controller init and SPL, so now
people can boot these boards using a full FOSS solution
3) Many improvement to the graphical console support, automatic selection
of the native mode for HDMI/DVI monitors via DDC + EDID, LCD panel support,
VGA output support
4) Preparation work for OTG controller support, together with 3) this allows using
u-boot on tablets effortlessly. The rest of the OTG support is going upstream
through the usb tree
And if possible I would like to see this end up in Fedora 22 :)
Fedora 22 Beta Release Announcement
The Fedora 22 Beta release for aarch64 and POWER secondary architecutres
has arrived, with a preview of the latest free and open source technology
under development. Take a peek inside!
What is the Beta release?
The Beta release contains all the exciting features of Fedora 22's
editions in a form that anyone can help test. This testing, guided by
the [Fedora QA team](https://fedoraproject.org/wiki/QA), helps us
target and identify bugs. When these bugs are fixed, we make a Beta
release available. A Beta release is meant to be feature complete and
bears a very strong resemblance to the third and final release.
The final release of Fedora 22 is expected in May.
We need your help to make Fedora 22 the best release yet, so please take
some time to download and try out the Beta and make sure the things that
are important to you are working. If you find a bug, please report
it – every bug you uncover (and/or help fix!) is a chance to improve
the experience for millions of Fedora users worldwide.
Together, we can make Fedora rock-solid. We have a culture of
coordinating new features and pushing fixes upstream as much as
feasible, and your feedback will help improve not only Fedora but Linux
and free software on the whole.
### Base platform
- Faster and better dependency management: yum has been replaced with
dnf as the default package manager. dnf has very similar command
line options and configuration files compared to yum but also has
several major internal changes including using libsolv in
coordination with friends from the openSUSE project for faster and
better dependency management. dnf-yum provides automatic redirection
from yum to dnf in the command line for compatibility. The classic
yum command line tool renamed to yum-deprecated as a transitional
step for tools still using it.
### Fedora 22 Server
Fedora 22 Server Edition brings several changes that will improve Fedora
for use as a server in your environment.
- Database Server Role: Fedora 21 introduced rolekit, a daemon for
Linux systems that provides a stable D-Bus interface to manage
deployment of server roles. The Fedora 22 release adds onto that
work with a database server role based on PostgreSQL.
- Cockpit Updates: The Cockpit Web-based management application has
been updated to the latest upstream release which adds many new
features as well as a modular design for adding new functionality.
- XFS as default filesystem. XFS scales better for servers and can
handle higher storage capacity and we have made it the default
filesystem for Fedora 22 server users. Other filesystems including
ext4 will continue to be supported and the ability to choose them
have been retained.
Issues and Details
This is an Beta release. As such, we expect that you may encounter bugs
or missing features. To report issues encountered during testing,
contact the Fedora QA team via the mailing list or in \#fedora-qa on
As testing progresses, common issues are tracked on the Common F22
The full release schedule is available on the Fedora wiki. The current
schedule calls for a final release in the end of May.
These dates are subject to change, pending any major bugs or issues
found during the testing process.