On 12/06/2014 12:40 AM, Jacco Ligthart wrote:
Hi List,
With one of my spare raspberries busy building newer redsleeve6
packages, I thought that with the other I could make an effort to start
redsleeve7 :)
I don't think the poor device can build all packages, so my first goal
is to build an equivalent to the minimal install. I want to start out
with pidora19 and build (at least) everything needed for a mock chroot.
Once I have that I hope to use that chroot to build (possibly again) all
needed for the minimal install.
AFAICT there is no Pidora 19. Looking through the archives they went
from F18 straight to F20.
The main question I have is which architecture to build for. I see the
following possibilities:
* armv5tel same as for redsleeve6:
- best compatibility with all arm platforms
- possible not the best performance
- possible build issues as the raspberry has another arch, and some
srpms could test for that
- possible compatibility issues, some srpms may not support armv5tel
without patching
armv5tel would be nice, but since there is no armv5tel F19, it would
mean manually bootstrapping the first stage packages (i.e. everything in
the buildsys-build group plus dependencies thereof).
It might be easiest to start with F18, and rebuild the basic
buildsys-build package set based on F18, and manually fix or work around
any issues that come up. This is not going to be a trivial amount of work.
Once that is complete, rebuild all the packages again using themselves,
while dropping as many of the earlier fixes/bodges/workarounds as
possible. Now you should have a basic starting point for further building.
Then build everything else, with any other required boostrapping options
(many packages take the --with bootstrap parameter to build with fewer
dependencies).
Once that is complete, rebuild everything again without any
bootstrapping options.
* armv7 not an option, raspberry does not understand that, but the
general idea is that rebuilding upstream for v7 is easier than for other
archs
armv7hl would indeed be easiest because you can use F19 directly for a
stage 1 build. That simplifies things massively.
* armv6hl/armhf/armel (these are all different names I've seen for use
on the raspberry):
armel is ARMv4, and is IIRC what soft-float Debian used to use. I am not
sure what the performance difference is in any realistic load between
armv6hl and armv7hl. Do you have any data on that?
- I probably end-up with a better performing system (especially with hf)
That is highly questionable. Difference between armv5tel and armv6hl is
only obvious in a handful of FP-heavy applications such as A/V
transcoding and gaming but:
1) A/V transcoding on ARM will be painfully slow anyway. I am currently
transcoding my DVD collection to MP4/H264/AAC and with
-crf 18 -preset veryslow
I am seeing about 60 fps transcoding speed on a 12-core/24-thread Xeon
machine running at 4GHz, with ffmpeg leveraging all of SIMD FPU
features. This quite simply wouldn't be even remotely workable on a
single core 600MHz ARMv6, regardless of whether it is using hard-float
or not.
2) The Pi SoC only supports OpenGL ES, which means very limited support
in games, and even then only in open source games, so this is probably
not even worth considering.
- not sure if anybody can reuse the binaries, or that I make a
special redsleeve for raspberry :)
I am not convinced here is a performance based case for hard-float in
RedSleeve for most typical server tasks. On the desktop there may be a
little more of a case for it (e.g. HTML5 A/V).
But - F19 is hard-float only, and most other distributions are also
dropping soft-float support (except maybe Debian IIRC, since there are
still Debian releases for things like ARMv5 based NAS boxes, but that is
becoming very niche). Which means that the only possible option is to do
what I suggested above, start with F18, and do a 3-stage build bootstrap:
1) EL7s1 --with bootstrap on F18
2) EL7s2 --with bootstrap on EL7s1
3) EL7s3 on EL7s2
4) EL7-final on EL7s3
In terms of universal usefulness, armv5tel EL7 would be better than armv6hl.
For armv6hf bootstrap, however, we could potentially cheap, and
bootstrap using F19 armv7hl. Since both armv7hl and armv6hl are
hard-float, armv6hl binaries will run on armv7hl. So if we were to
decide that our EL7 build will be armv6hl rather than armv7hl, the
boostrapping process would be the same as for armv7hl.
So what we need to decide, then, is:
1) Do we want to support armv5tel soft-float devices? How many of our
users have hardware that isn't at least armv6hl? Examples of such
hardware include:
- SheevaPlug
- GuruPlug
- DreamPlug
- QNAP ARM based NAS boxes
- VIA APC 8750 (the original ARMv6 model, newer ones are ARMv7)
2) If we are only going to support hard-float devices, I guess there are
enough users on this list that have Pis to perhaps warrant having an
armv6hl based build rather than an armv7hl one.
Any thoughts and opinions from fellow listers would be most welcome at
this point. Once we set off in a certain direction it is unlikely we
will be able to backtrack without having to re-do everything from
scratch, and we are unlikely to have resources to do so.
Gordan
_______________________________________________
users mailing list
[email protected]
http://lists.redsleeve.org/mailman/listinfo/users
