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!
Good day all,
Many lucky Fedora users have already received their shiny new Chromebooks and have begun
tinkering, with some reports of Fedora 18 up and running.
We'd like to discuss supporting this exciting device and adding another kernel variant for
the Exynos 5 SoC. Has anyone looked into upstream support and its status? Is anyone
attempting to build their own kernel?
What's working so far? What's not?
It's time to announce a little project I've been working on for the last
few weeks: the ARMv8 bootstrap project for Fedora.
There has been a lot of interest in ARMv8 (also known as aarch64) in the
last few months since it was introduced by ARM. A 64-bit processor that
uses as little power as possible could provide an enormous cost savings
to the vast and growing data centers throughout the world.
So, even though hardware is not yet available, we have started the work
needed to bring Fedora to ARMv8. Using the ARM provided Foundation
model (a platform simulator for ARMv8), we have been building up the
packages needed to eventually get to a full native build of Fedora.
Details and current status are here:
Of the six stages needed in the bootstrap of a new architecture, we
are in the middle of stage 2; these are therefore pretty early bits.
In the interest of full transparency in what we do, and in the spirit
of release early and release often, grab a copy and have fun!
On the Fedora wiki, you will find instructions on where to find all
the bits and pieces used to construct the root file system image
that's been created so far, and how to use the ARM Foundation model
to do further work. And there is plenty to do :).
If you'd like to help, read through the wiki pages above and get
yourself to the point where you can run the ARM Foundation model
using the Fedora root file system. Then find a package needing
some love and do what needs to be done for ARMv8 (the wiki explains
And if you have questions, you can find me (ahs3) on #fedora-arm on
IRC (Freenode), or ask on this mailing list; the more, the merrier.
Red Hat, Inc.
I'm assuming since you've all been so quiet that the 3.7 kernel works
perfectly for the intended platforms (versatile/highbank to date) and
that we don't need to do anything what so ever moving forward (ROTFLOL
here!) or else no one other than Paul has bothered to test it (Calxeda
I am glaring at you). I would like to get this bolted down sooner
rather than later as I really don't want another repeat of 3.6.
Looking at post 3.7 I'm already starting to poke around and prep
things. Similar to x86-32 I'm aiming to basically have an armv7 and an
armv7-PAE kernel. The PAE kernel will support LPAE and the various
virt things that are starting to land in the kernel now so it will be
solely for A15 chipsets. I presume the Exynos5 supports those
So with that I'd like some feedback from the mainline kernels guys or
anyone else that is a kernelly dev sort of person with for/against
suggestions and thoughts.
Fair enough. My thought was you still wanted to turn on all the express drivers. Versatile is specially handled in the kernel config logic so I thought you were doing the same. All is good.
Sent from my phone. Please excuse formatting and brevity.
Peter Robinson <pbrobinson(a)gmail.com> wrote:
On Thu, Nov 29, 2012 at 5:09 PM, Jon Masters <jcm(a)redhat.com> wrote:
> On 11/29/2012 04:32 AM, Peter Robinson wrote:
>> On Thu, Nov 29, 2012 at 8:09 AM, Jon Masters <jcm(a)redhat.com> wrote:
>>> Hi Peter,
>>> Please take a look at the attached. Note that the default kernel variant
>>> is actually a versatile, and you weren't inheriting that. Also, we need
>>> to set the V6_V7 multiplatform option because the current Kconfig logic
>>> will otherwise enable AUTO CPU support, which will force us to have a V5
>>> kernel. So take a look. I'll be online later.
>>> Tested with a cross compiler only, but it built.
>> A couple of things:
>> This is incorrect as we've uncoupled the unified from the rest of the
>> kernel to simplify and clean up the build.
>> -temp-armv7l-versatile: config-arm-versatile temp-arm-generic
>> +temp-armv7l-versatile: config-armv7 config-arm-versatile temp-arm-generic
> But, the unified kernel is the default kernel, right? As in kernel- is
> the unified kernel? That one is currently a versatile kernel. It is, if
> you look in Makefile.config pulling its config from the versatile config
> files per the above, which without explicitly pulling in config-armv7
> means that you get whatever versatile turns on for you, and certainly
> none of the intended config-armv7 bits.
> Unless I am missing something, there's a bug in the existing config
> merging that is actually the root cause here. Please explain what you
> are trying to do with joining these if I am wrong.
The fix is actually this. With unified kernel the versatile config
file (highbank too) don't actually get used at all and are due to be
removed. I didn't want to do that until I knew we were good to go.
-kernel-$(VERSION)-armv7l.config: /dev/null temp-armv7l-versatile
+kernel-$(VERSION)-armv7l.config: /dev/null temp-armv7
I managed to miss this in the move. Good catch to give me the general
direction to look :)
Foe those of you experimenting with the ARMv8 models (whether
the ARM FAST or Foundation model), you may have noticed that
the kernel parameters are hard-coded.
I've put together a quick'n'dirty tool that will allow you to
customize the kernel parameters in whatever way you need (as
long as it's less than 400 characters :).
To use the tool:
$ git clone git://fedorapeople.org/~ahs3/patch-axf.git
and then follow the instructions in the README.
So, for example, if you need to change the IP addresses for your
NFS root mount, or the name of the mount point, you can now do
so pretty easily.
Hope this helps....
Red Hat, Inc.
Just an FYI: git over http on the repos being used for ARMv8 is not
working quite as it should. I'm working with infrastructure admin
folks to fix it.
In the meantime, the bootstrap scripts should be available from:
$ git clone git://fedorapeople.org/~ahs3/bootstrap.git
And the rootfs should be available from:
$ git clone git://fedorapeople.org/~ahs3/rootfs.git
Sorry to jumble things like this, but we should have it fixed soon,
so this should only be for a couple of days.
Red Hat, Inc.
Please take a look at the attached. Note that the default kernel variant
is actually a versatile, and you weren't inheriting that. Also, we need
to set the V6_V7 multiplatform option because the current Kconfig logic
will otherwise enable AUTO CPU support, which will force us to have a V5
kernel. So take a look. I'll be online later.
Tested with a cross compiler only, but it built.