Probably The Hardest Task I've Been Assigned At Seneca's CDoT (or at least the one that's taken me the longest...) rasp pi v6hl status

[Jon Chiappetta]

So I *think* I've got a basic start on a general armv6hl hard float root fs for Fedora. I just posted probably one of my more complicated blog posts this far about bringing up a new arch for Fedora ARM Linux -> http://fossjon.wordpress.com/2012/09/18/bootstrapping-fedora-arm-for-a-new-a...

Thanks to the help and support from the people on this list and in channel, I've been able to get this far. My next step is to patch yum && rpm somehow and turn this basic root fs into a koji builder so we can start building for v6hl off to the side for the rasp pi possibly. I haven't done any speed tests at all yet and probably wont be able to for a while until we get a complete image with all the packages cleanly rebuilt -- but were really hoping this thing proves to be much faster and a better user experience overall. The text login (multi-user) boot up seems pretty good so far though. Anyway, I posted a screenshot up above for proof, which is basically me just compiling a v6 binary on the pi and running it. It's pretty cool I guess.

Thanks for your times,

Jon Chiappetta

[Niels de Vos]

On Wed, Sep 19, 2012 at 4:55 AM, Jon Chiappetta
 wrote:
> So I *think* I've got a basic start on a general armv6hl hard float root fs
> for Fedora. I just posted probably one of my more complicated blog posts
> this far about bringing up a new arch for Fedora ARM Linux ->
> http://fossjon.wordpress.com/2012/09/18/bootstrapping-fedora-arm-for-a-new-a...

Congrats and such a write-up will really be helpful a next
architecture needs to get added :)

Cheers,
Niels

[Gordan Bobic]

On 09/19/2012 03:55 AM, Jon Chiappetta wrote:
> So I *think* I've got a basic start on a general armv6hl hard float root
> fs for Fedora. I just posted probably one of my more complicated blog
> posts this far about bringing up a new arch for Fedora ARM Linux ->
> http://fossjon.wordpress.com/2012/09/18/bootstrapping-fedora-arm-for-a-new-a...
>
> Thanks to the help and support from the people on this list and in
> channel, I've been able to get this far. My next step is to patch yum &&
> rpm somehow and turn this basic root fs into a koji builder so we can
> start building for v6hl off to the side for the rasp pi possibly. I
> haven't done any speed tests at all yet and probably wont be able to for
> a while until we get a complete image with all the packages cleanly
> rebuilt -- but were really hoping this thing proves to be much faster
> and a better user experience overall. The text login (multi-user) boot
> up seems pretty good so far though. Anyway, I posted a screenshot up
> above for proof, which is basically me just compiling a v6 binary on the
> pi and running it. It's pretty cool I guess.

Well done.

It raises a couple of questions, though.

1) How much performance difference does this _actually_ make over 
armv5tel targeted binaries? The benchmark results I have seen from a 
similar Debian effort is that with the exception of A/V transcoding, the 
performnce difference is in the low single figure % points which is 
unlikely to be perceivable over and above the placebo effect to the 
average user.

2) Why base the mainline distribution on armv7hl instead of armv6hl if 
armv6hl code will run on both? (Note: I don't consider the argument of 
"That's what all the other distros are doing." to stand up on it's own 
at face value.)

Gordan

[Peter Robinson]

> It raises a couple of questions, though.
> How much performance difference does this _actually_ make over armv5tel
>
> targeted binaries? The benchmark results I have seen from a similar Debian
> effort is that with the exception of A/V transcoding, the performnce
> difference is in the low single figure % points which is unlikely to be
> perceivable over and above the placebo effect to the average user.
> From my understanding of the Raspian graphs you see around the place

it's a comparison of Debian 6 vanilla to a custom compiled Wheezy.
Debian 6 for ARM was compiled for ARMv4t chips as opposed to a ARMv6hl
build. I think you'd cover off a chunk of the performance differences
in the move from v4t to v5tel. Add to that the massive amounts of work
that has been done of late on a lot of libraries to optimise them for
arm (linpng, libjepg, pixman, cairo etc etc) between the versions
shipped for the different releases and I think you would almost be
there without v6hl optimisations.
> Why base the mainline distribution on armv7hl instead of armv6hl if
>
> armv6hl code will run on both? (Note: I don't consider the argument of
> "That's what all the other distros are doing." to stand up on it's own at
> face value.)

There's a number of reasons for going with v7hl over v6hl.

1) There was no v6 boards around when we made the decision. Most of
the v6 chips are used in cheap low end phones of which we're not
targeting what so ever as a Fedora device. Since that decision there
is now 2. The Pi and a VIA board.

2) There's quite a bit of architectural difference and optimisations
between v6 and v7 that make it worthwhile optimising v7 on it's own.
This includes a completely different completely rearchitected VFP It's
also where all chips are going even on the very low end.

3) Most of the features in v6 were optional in v5 and hence were run
time detectable anyway

4) Prior to gcc 4.7 there were apparently issues with the VFP2
implementation and it hadn't been widely used as far as we could tell,
the optimisation that had gone into hardfp in gcc 4.[5-7] were mostly
aimed at the VFPv3 in the ARMv7+ processors. VFPv2 in the armv6 still
isn't compulsory.

5) That's the direction where the industry was going (and hence all
the distros) and so we also went where the industry was going to
ensure as much compatibility moving forward for binaries between the
various distros as possible. Compiling for VFPv2+ wasn't going to give
us that.

Basically it was a whole lot of pain for at the time of the decision
zero gain. Even now I don't think it's worth the effort and we still
don't have solid numbers to prove it either way.

Peter