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 -----
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
Try the kernel build in the SC testing repo....
Run "sc-cleanUpdate-testing-pi" from your Pi2B and reboot.
* Sat Feb 21 2015 - 3.18.7-507.20150221git37ce36a.sc20
- Update to latest git.
- Modify bcm2709 config
Clive Messer <clive.m.messer(a)gmail.com>
On Fri, 2015-02-20 at 23:29 -0800, ryan jarvinen wrote:
> Hi Clive,
> Thanks for your work on the RPi2 images for Fedora!
> I'm trying to see if I can get Docker and newer versions of OpenShift
> to run on this hardware, and I wanted to send over a few notes on the
> initial testing I've done:
> It looks like your current kernel does not include support for
> DM_THIN_PROVISIONING, which Docker requires.
> I've seen some other projects
> (http://blog.hypriot.com/kick-ass-raspberry-pi-2-having-a-forbidden-love-a...) that have had some success with Docker on RPi2. It sounds like they are making use of CONFIG_OVERLAY_FS as well.
> Let me know if you end up enabling these features in future versions
> of your minimal image. It could help us build some really impressive
> micro-scale Linux clustering demos. :)
> Thanks again for your work on this effort!
> On Feb 20, 2015 5:46 AM, "Clive Messer" <clive.m.messer(a)gmail.com>
> On Fri, 2015-02-20 at 08:24 +0000, Paul Knox-Kennedy wrote:
> > Also installed the LXQT desktop without any problems, and
> ran a full dnf
> > upgrade, which updated the kernel correctly.
> > Great job Clive, very much appreciated.
> Thanks for testing. (You and everyone else who downloaded an
> image and
> booted it.)
> I posted an "announcement" to the RPi Forum.
> Clive Messer <clive.m.messer(a)gmail.com>
> arm mailing list
Running Fedora release 22 (Rawhide) 3.19.0-0.rc7.git3.1.fc22.armv7hl I
find I have a problem with wlan0 becoming de-activated.
Running headless, attempt to ssh to device. No response. Turn on monitor
ifconfig shows an ip address ok.
cannot ping router
try |sudo systemctl restart network.service|
decide to ifdown/ifup wlan0
system returns to normal, can then ping router and ssh to device from my
journalctl for wlan0 gives results as per attached.
Can anyone explain what is happening to the wlan0 device and why I have
to re-activate it?
Compose started at Sat Feb 28 07:15:03 UTC 2015
Added Packages: 0
Removed Packages: 0
Modified Packages: 0
Size of added packages: 0 (0 )
Size change of modified packages: 0 (0 )
Size of removed packages: 0 (0 )
Size change: 0 (0 )
Compose finished at Sat Feb 28 08:16:12 UTC 2015
The change here on my part is using a new installer script I sent to
Paul Whalen, I installed the partitions to a sata hdd and the uboot to a
4Gb mSD card.
I then successfully boot with then and my system is running from the
My script changes may not be the neatest, but they have no impact for
the installer for devices without a sata and no change for any of the
board specific uboot dd scripts.
I meant to do something like this in the Fedora 21 cycle but it was
long and winding and for me in a new role as we ran into the end of
the cycle it managed to slip through the cracks.
With Fedora 22 coming into Alpha and in all likely hood we'll have the
4.0 kernel for GA it gives us a decent runway to focus on polish for
both ARMv7 and aarch64 on the runway to F-22 GA.
The idea is for people to pick small items to improve and polish,
these don't have to be large time consuming complicated tasks.
I've got a bunch of ideas that I'm working on and there's 100s of
improvements that can be made whether it be to various components of
devices, testing and improvements to packages or documentation there's
lots that can be done.
So a couple of the idea I'm working on to give you some ideas:
* Wifi/Bluetooth support on the PandaBoard (yes, I've got a fix for
the kernel issues too I'll be pushing RSN once I've cleaned it up).
There's a package if someone would like to review it 
* Testing and improving accelerated X as much as possible across as
many platforms as possible. EG fbturbo will help XFCE/Sugar etc on a
number of devices. Package review  is a beginning here. LOTs to
So what other ideas are there? Here's some random ideas:
* Create an alsa UCM profile  for your device. See the alsa-ucm
package in F-22+ for some examples
* Fix packages for OpenCL to build on ARM*, package the shamrock
OpenCL implementation 
* Test and document use of sensors on devices like the BeagleBone
* Test and document the use of Capes/Hats with the new DT Overlays
(awaiting confirmation the configfs bits land in 4.0)
* Testing of media offload engines, packaging of associated tools/libraries.
* Help implement device pages in the wiki 
* Lots of small kernels bits if you're interested in that :)
NOTE what this _IS_NOT_ is a place for people to dump this wish lists
unless they are actually going to pick up them up and implement :-)
Any queries or if you're looking for some ideas head to #fedora-arm
and ask there. I'm pbrobinson on IRC. Please don't just rock up, ask a
question and leave. We're not all online 24/7 even if we monitor it