[fedora-arm] Fedora ARM 12 on IGEPv2 (Beagle Board clone)

[Kedar Sovani]

> -----Original Message-----
> From: fedora-arm-bounces at redhat.com [mailto:fedora-arm-
> bounces at redhat.com] On Behalf Of Matthew Wilson

...snip...

> In the meantime, I have some questions.  Apologies in advance
> if these
> seem simple.
> 
> 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
> set variants).
> 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).

Yes, you can pick up the kernel source rpm for Fedora and use
that.
Alternatively, you could just try the latest stable vanilla 
kernel. 

> b) Would it then make sense to offer these as pre-built RPMs
> for common systems?

I guess someone was looking into making this available. In the 
meanwhile, kernel images for commonly required boards are 
accessible from the Fedora-ARM wiki. 

> 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.6.31).
> 

Treat the latest to be the greatest? :-)

> 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.
> 

I am not entirely sure on this... Anyone?

> 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?
> 

These rpms are now available on koji:
http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=21323
http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=21322

This usually happens because we check for the repoclosure of a 
set of package groups. Packages beyond these may have dangling 
dependencies. These usually get addressed, during the mass build 
run (which will start in this week) or on-demand, like in this 
case.

> 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 [2].
> Does this, in any way, help with the compatibility of packages
> targetting Cortex-A8?
> 

You can fix alignment errors in the current versions as well by:
# echo 2 > /proc/cpu/alignment

With hardware support it will be faster. 


> 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?

As you point out, it is about time and priorities. These will get 
addressed in the mass build run that will start this week. If you 
provide me with a list of packages I'll move them to the top of 
the list.

> 
> I look forward to being able to contribute something back into
> Fedora!
> 

Great! You are welcome...

> Kind regards,
> Matthew
> 

Kedar.

> 
> [1] http://www.igep-
> platform.com/index.php?option=com_content&view=article&id=46&It
> emid=55
> 
> [2]
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi
> 0344j/Beihgifg.html
>