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!
Is it advisable to build my own kernel for the Chromebook? I glanced
through the IRC chat from last week and saw a note about kernels.
Darryl L. Pierce <mcpierce(a)gmail.com>
"What do you care what people think, Mr. Feynman?"
I'm trying to get F18 running on the globalscale mirabox.
It comes preloaded with Debian Squeeze. As a first step I've tried
downloading the generic
rootfs from the
https://fedoraproject.org/wiki/Architectures/ARM/F18/Remixes page; I've
tried both the arm and armhfp versions, and even tried an armv5 kirkwood
All of them behave the same. I unpack the rootfs into /mnt/f18, and then
try to chroot into
it. The first two or three times I try it, it comes back with either
"Illegal instruction" or
"Segmentation fault", but after a few times I successfully get into the
chroot. Then for pretty
much every command inside it's the same thing. First few times it runs
it fails with one of
the two errors above, then it starts working and appears to keep working
for an indeterminate
amount of time.
I've tried to start rebuilding rpms from source in the chroot but things
never work long enough
to get anything built.
I've also (and this part is probably off-topic) tried building rpms from
the debian environment,
and that's failing because gcc gives an error when explicitly compiling
$ gcc -c ui.c -march=armv7
ui.c:1: error: target CPU does not support ARM mode
Additionally, I've tried building gcc 4.8.0 from source, and that errors
../.././gcc/config/arm/neon.md: In function 'const char*
../.././gcc/config/arm/neon.md:3953:1: internal compiler error: Illegal
[(set_attr "neon_type" "neon_shift_2")]
../.././gcc/config/arm/neon.md:3953:1: internal compiler error:
# cat /proc/cpuinfo
Processor : Marvell PJ4Bv7 Processor?? rev 1 (v7l)
BogoMIPS : 1199.30
Features : swp half thumb fastmult vfp edsp vfpv3 vfpv3d16
CPU implementer : 0x56
CPU architecture: 7
CPU variant : 0x1
CPU part : 0x581
CPU revision : 1
Hardware : Marvell Armada-370
Revision : 0000
Serial : 0000000000000000
Looking for any help on how to debug or how to proceed.
** Resending with the right lists **
after talking at devconf with David Cantrell about the best way to
support setting up uboot on arm devices in anaconda, the best approach
going forward is pretty clear, ill get to it in a bit first i want to
describe things as I see them.
Unified kernel while solving many issues introduces some. platform
detection was kinda simple with separate kernels. unified kernel means
that while we dont need to worry about having the right kernel, we do
need to worry about loading the right dtb.
platform detection is also needed to know where in ram we should load
the kernel and offsets for initramfs and dtb to be loaded. anaconda can
tell us the filesystem and device that we are installing to, but
depending on the exact way support is done in uboot we may need to put
in different values, SCSI vs SATA vs USB etc we also need to ensure we
use the right dtb file. for instance a pandaboard ES can use a
pandaboard dtb but will be 1ghz vs the 1.2ghz its capable of. some
systems like the highbank ones have the dtb in their uboot. while
others need to load an external file.
so as i see it we need a library that anaconda can import and use to
work out the right values for the system we are installing to. probably
the library should write out the uboot template and run mkconfig on
it. we could then reuse the library in a tool to say setup a boot
sdcard to run the installer on a system. we have an issue where it is
really not possible to make the equivilent of a boot.iso that will be
I think we should take this up to the cross distro list at linaro and
ideally have the distros work on a database at the least of platforms
and the values and types needed. if not the whole library that can be
used in different places to set things up.
this is only needed for 32 bit arm, 64 bit will have UEFI, ACPI and
grub2. potentially we also want to consider if we can implement
http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec since we
need to implement something anyway.