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 :)
In case you do not know yet: there is no virtualisation support
in Fedora 21 on APM Mustang. Looks like one of 3.18-rc commits
went into 3.17/stable tree and disabled it for us.
Added into to https://bugzilla.redhat.com/show_bug.cgi?id=1165290
[root@pinkiepie virt]# LC_ALL=C virsh create hrw-f21.xml
error: Failed to create domain from hrw-f21.xml
error: unsupported configuration: Domain requires KVM, but it is not available. Check that virtualisation is enabled in the host BIOS, and host configuration is setup to load the kvm modules.
[root@pinkiepie virt]# dmesg|grep -i kvm
[ 0.303959] kvm : GICV size 0x2000 not a multiple of page size 0x10000
[ 0.303965] kvm : error: no compatible GIC info found
[ 0.304070] kvm : error initializing Hyp mode: -6
[root@pinkiepie virt]# uname -a
Linux pinkiepie 3.17.4-301.fc21.aarch64 #1 SMP Sun Nov 30 20:41:43 UTC 2014 aarch64 aarch64 aarch64 GNU/Linux
In the past couple of days, I have been trying to make Fedora 21 boot in
a BeagleBoard-xM Rev C. Unfortunately, this doesn't work out of the box
as I expected, and I had to do many tweaks to the documented procedure:
FWIW, I am using the Minimal Fedora image for this.
Well, the first thing I tried was following the exact instructions for a
But, as I said, this did not work. I found that BeagleBoard-xM expects
the first partition to be a FAT one, and the image provided by Fedora
has an ext* partition. OK, so I manually created an SDCard with a FAT
partition as the first one (where the u-boot files + the Linux kernel
stay), and then the rest of the partitions are the ones that you find in
the original image. It worked, in the sense that I could turn on the
board and see something in the serial. However, more problems ahead...
The second problem was about "catX" not being defined. It is actually
defined in boot.cmd, but due to some bugs in the u-boot version that is
being used, it is not recongnized. I found this message about the
[It feels strange that nobody noticed/experienced this problem before; I
hope I'm not doing anything wrong...]
Anyway, after struggling a lot with this, I decided to give up the
original boot.cmd and write very simple boot.cmd + uEnv.txt files, just
for the board that I have. The contents are:
Those were obviously made using the definitions found in the original
boot.cmd file. With them, the board can finally (and apparently) load
the Linux kernel + the initrd + the dtb files from the SDCard, but I
still can't make it to boot; it freezes after the "Starting kernel ..."
message, all the lights turn on, and nothing else happens.. Here is
what I see now:
It seems to me that I have made some mistake somewhere (offsets? files
to load? u-boot commands?), but I can't find it. I was at least
expecting to see the "decompressing kernel" message, but nothing... And
adding earlyprintk in the bootargs doesn't tell anything either.
So, I'm kind of running out of ideas on how to solve this, and I want to
get everything working until Monday. Does anyone know what can be
wrong, or point me to some documentation that I can use to boot Fedora
21 on this BeagleBoard-xM?
Thanks a lot,
GPG key ID: 0x65FC5E36
Please send encrypted e-mail if possible
Fedora 22 Alpha Release Announcement
The Fedora 22 Alpha release for the AARCH64 and POWER 64 secondary architectures
has arrived, with a preview of the latest free and open source technology under
development. Take a peek inside!
• Get Fedora 22 Alpha Server
What is the Alpha release?
The Alpha 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, helps us target and identify bugs. When these bugs
are fixed, we make a Beta release available. A Beta release is
code-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 Alpha and make sure the
things that are important to you are working well. If you find a bug,
please report it – every bug you uncover is a chance to improve the
experience for millions of Fedora users worldwide.
Together, we can make Fedora 22 another rock-solid release. 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.
Fedora 22 Server
The 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.
Issues and Details
This is an Alpha 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 test mailing list or in #fedora-qa
As testing progresses, common issues are tracked on the Common F22 Bugs
For tips on reporting a bug effectively, read "how to file a bug
The full release schedule is available on the Fedora wiki:
The current schedule calls for a beta release in the middle of April,
and a final release in the second half of May.
These dates are subject to change, pending any major bugs or issues
found during the development process.
Today I have installed a Fedora 21 on an sdcard for my Wandboard Quad.
But I had problem with u-boot.
I have follow the doc on fedora wiki :
But after setting up the sdcard, the board don't want to start.
I didn't have output on serial output with the u-boot.imx from the fedora
After build u-boot from the head of u-boot-imx repository (and apply this
patch :https://firstname.lastname@example.org/msg167764.html), I
was able to boot a fedora 21 minimal system.
It's a know problem ? Someone else have the problem ?
I don't have tested with upstream uboot v2015.1, peraps it's can be a good
thing to update the version of uboot.