Fedora ARM 12 on IGEPv2 (Beagle Board clone)
by Matthew Wilson
Hi all,
I would like to introduce myself to the group. I have recently
received an IGEPv2 board [1], 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
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).
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.6.31).
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 [2].
Does this, in any way, help with the compatibility of packages
targetting Cortex-A8?
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!
Kind regards,
Matthew
[1] http://www.igep-platform.com/index.php?option=com_content&view=article&id...
[2] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344j/Beih...
7 years, 9 months
Fedora 14 on armv5tel status update
by Peter Robinson
Hi All,
I've been working on getting Fedora 14 moving forward with the
assistance of Dennis.
I've almost got the build root done except for a few notable
exceptions (glibc, python, perl, sqlite, nss I'm looking at you....)
and the things that depend on them.
A lot of the of the failures (python/sqlite/nss) are in the test
suites so they should be relatively easy to fix. I want to try and get
upstream to either fix or disable the offending issue where possible.
The glibc issue is interesting... it seems its a regression from F-13,
we had to apply a patch for F-13 but even with all that in place I
still get some failures. So it seems to be a regression (and we're
seeing it on the F-15 glibc one as well. I'll do some more testing and
follow up with the logs etc so that someone more smart than I am might
be able to comment and assist :-)
All help and feedback welcome :-D
I've setup a tracker bug for various issues here:
https://bugzilla.redhat.com/show_bug.cgi?id=706236
Once I have the last of the buildroot issue cleaned up we'll release
one of the automatic tools onto the dist-f14 packages and see how
quickly we can get F-14 Gold out of the way and move onto the more
interesting things :-D
Cheers,
Peter
12 years, 3 months
smsc95xx performance bug: eth vs usb
by DJ Delorie
This is a weird bug, has anyone else seen or fixed it?
If you connect storage up to a pandaboard USB port (flash or sata),
you get about 5 MB/sec throughput. Now, if you "ping -i 0.001" the
pandaboard from another host, you can increase the *storage*
performance to 22 MB/sec (for my disk, max 32 MB/sec on an x86
desktop). Note that the ethernet device is itself also on the same
USB hub (on chip) as the device storage.
This tells me that something in the smsc95xx driver is either missing
an interrupt, or not polling fast enough, but I couldn't find
anything.
USB protocol analyzer shows that most of the time, the transfers are
happening at the full speed, so it's just stopping every once in a
while, killing performance.
Kernel is 2.6.38.5-23.fc13.armv7l.omap from the Fedora 15 development
SRPMs.
12 years, 3 months
Any thoughts on running Fedora+XFCE on an Efika Smartbook?
by Niels de Vos
Hi list,
I know that some of you have an Efika Smartbook
(http://www.genesi-usa.com/products/smartbook) and am interested in
your opinions on it. I'm looking to getting one myself, but only if
there are positive experiences with it.
My normal usage of such a netbook would be some browsing, emailing and
some development (mainly with vim) while traveling. I assume that the
10" display is just big enough for it (a 7" EeePC is a little too
small).
Things I'd like some information on:
- Will XFCE run without major issues?
- How is the keyboard, are the keys (much) smaller than a standard
laptop keyboard?
- Is the display good readable when sitting outside, possibly in the sun?
- Any other pros/cons you can think of.
Many thanks,
Niels
12 years, 3 months
Hardware Crypto Offload on Kirkwood (SheevaPlug)
by Gordan Bobic
Hi,
In case anyone is interested, I got this working on F13. It required
building the cryptodev kernel module and rebuilding the standard F13
OpenSSL package with three additional parameters (the cryptodev support
is already in the standard OpenSSL package sources, it just isn't
enabled in the default build).
More details available here:
http://www.altechnative.net/?p=174
Any chance we can have cryptodev enabled in the standard package build?
I cannot see any drawbacks to having it available - when cryptodev
device isn't there, it will simply fall back to the software
implementation. (Note: required cryptodev header file provided by the
external kernel driver).
Gordan
12 years, 4 months
FWD: ANNOUNCE: Linaro Plan Reviews (May 31st to June 8th)
by Jon Masters
Sending on behalf of Christian Reis (kiko):
Hello there,
Starting next Tuesday, May 31st, Linaro tech leads will be running a
set of public phone calls to present official plans for our engineering
units. Calls are daily at 15:00 UTC, and there are local dial-in numbers
for most countries around the world. Schedule and details are listed
here:
https://wiki.linaro.org/Cycles/1111/PublicPlanReview
For each call we will provide a set of slides discussing features
planned and the blueprints that specify and track them. The calls are
open to the general public; anybody is welcome to dial in and listen.
Questions can be asked via IRC using #linaro-meeting on Freenode;
details on how to access IRC itself are also linked to from that page.
Calls will also be recorded and available for later perusal. If you'd
like a daily reminder of the call topic let me know and I'll put you on
the reminder list.
The first call, on Tuesday itself, will cover Power Management, and be
hosted by Amit Kucheria. See you there,
--
Christian Robottom Reis | [+55] 16 9112 6430 |
http://launchpad.net/~kiko
Linaro Engineering VP | [ +1] 612 216 4935 |
http://async.com.br/~kiko
12 years, 4 months
Hardware Crypto Offload on i.MX515 (Efika)
by Gordan Bobic
Just looking at the specsheet of the Freescale i.MX515, and this jumped
out at me:
Symmetric/Asymmetric Hashing and Random Accelerator (SAHARA) Lite is a
cryptographic acceleration engine security co-processor
Implements:
* Block encryption algorithms (AES, DES, and 3DES)
* Hashing algorithms (MD5, SHA-1, SHA-224, and SHA-256)
* Stream cipher algorithm (ARC4)
* True hardware random number generator (TRNG)
Does anybody know at what kernel version the support for this was added
(if it has already been added)?
And since I know the Genesi guys read this list, does the Kernel+OpenSSL
combo that comes with Efika have this enabled as standard? (I lent my
smartbook to somebody for a few days hence why I'm asking rather than
just checking - I thought I'd get a head start on trying to get this
working in the same way as it does on the Kirkwood (SheevaPlug).
I also notice there is this in the i.MX515:
Security Controller (SCC) type 2
* AES engine
* Secure/Non-Secure RAM
* Support for multiple keys and TZ/non-TZ separation
Does this mean there are two independent AES crypto co-processors in
there? What about kernel support?
Gordan
12 years, 4 months
Re: [fedora-arm] Hardware Crypto Offload on Kirkwood (SheevaPlug)
by Gordan Bobic
Jason Burrell wrote:
> > NSS supports PKCS#11 which most hardware crypto accelerators
> (including
> > things like smartcards and offloading coprocessors) use. As far as I
> > know, the only OpenSSL PKCS#11 library is external to it, from the
> > OpenSC people.
>
> Hmm... Are the relevant kernel drivers and interfaces in place for
> PKCS#11 for any of the crypto offload engines discussed (Kirkwood,
> Tegra, Freescale)? Can somebody point me at the relevant interface docs?
>
>
> Generally, the CPU-based "crypto" hardware is actually just a few
> acceleration functions, so you don't usually access it through PKCS#11.
> I know NSS supports the Intel AES instructions directly (not via
> PKCS#11), so it should be possible to add others as well.
Accelerating instructions are something for the compilers and assemblers
to deal with. I was specifically talking about asynchronous offload
engines that ARM SoCs often to have.
> So are you saying that the number of organizations that _don't_ use
> OpenSSH, OpenLDAP, mod_ssl, etc. is greater than those that do (limiting
> the field here to those that use some unix-like OS)? That would surprise
> me if it really is the case.
>
>
> I don't have figures as to the number of deployments of any of those
> tools, but only OpenSSH is listed as not yet supporting NSS anyway.
>
> I do think there are many deployments of OpenSSL that aren't following
> its license's advertising requirements. As you stated, OpenSSH is used
> pretty much everywhere, but I don't even remember the last time I saw a
> statement saying a product included software from OpenSSL, except in
> hidden about boxes, which isn't what a clear reading for the Four-clause
> BSD license states.
Just out of interest, have OpenSSL maintainers complained at having just
about every distribution on the planet break their licencing terms?
Gordan
12 years, 4 months
