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?"
Has anyone been able to get fedora on a rock chip RK3066 device?
Red Hat, Inc
"It's not whether you get knocked down, it's whether you get up." - Vince Lombardi
Even though F19 ARM Beta bits are making their way to the mirrors now
there is still quite a bit yet to be done before GA. In addition to
beta release notes still needing to be written there are still bugs and
regressions to track down. Let's squash as many of these as possible in
the next couple weeks, and preferably spin test images early&often to
confirm the fixes.
General image issues:
o LVM console spam on first boot
o The initial-setup does not appear to run
o Restorecon runs on first boot- can we avoid this?
o No u-boot - would be nice to have for virt integration
o No boot-vexpress script or pre-extracted kernels - was in F18.
o No graphics support - regression since F18 (Kernel 3.6)
TI Boards in general:
o Images, as distributed, need manual steps to be made bootable.
o An easy script to handle the manual steps is not yet available.
o Supplied vfat partition possibly badly formed.
o No graphics - regression since F18 (Kernel 3.6)
OMAP3 (Beagle boards):
o The supplied uboot does not load boot.scr.
o The supplied kernel fails to boot.
AM335x (Beagle bone boards):
o Missing kernel support - this is probably an F19 remix or F20 feature.
Tegra2 (Trimslice, specifically)
o SSD support is unreliable due to evident hardware bug.
o X, though functional, is not stable.
o a-b-c needs to be run manually in %post
Notwithstanding the above, OMAP4 (Panda), Trimslice, Highbank and
Versatile Express are in decent shape, which is why the Beta is going
out now. Plus it gives a readily available set of bits for advancing
these defects. If you are aware of additional issues please followup
here- let's get them all identified then work out solutions. Thanks!
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com