Hi all!
Comments inline.
Am Sonntag, 24. Oktober 2010, 20:44:37 schrieb Carsten Munk:
> Liberally forking this thread so we can start a discussion - could
> someone involve the ARM toolchain guys too as we should kickstart this
> work asap?
>
[...]
> >> So, in this case I propose that we do that in MeeGo 1.1.1 (or whatever is
> >> the right number for MeeGo 1.1 update).
> >>
> >> Imho, that will be the least painfull way for everybody, especially if we
> >> decide and communicate this now. Now the amount of code/applications
> >> that needs to be recompiled is still manageable. As well as the number of
> >> affected parties.
> >
> > I don't think this can be done at all.
> > this will break all 3rd party apps and components, including codecs, plugins
> > etc etc
> >
> > that's not something that's just ok to do easily or.. well really, ever.
> >
>
> I agree that it is problematic, but even Linaro is moving in that
> direction which means a lot of reference plugins/codecs on ARM side
> will actually be hardfp in the future instead of softfp. The elephant
> in the room is the fact that Nokia's Harmattan is moving/has moved to
> hardfp too and that apps made for 1.1 ARMv7 softfp won't work on 1.2
> ARMv7 hardfp.
We can build side-by side for a grace period.
> How exactly we would bootstrap this work and how/when it would/could
> be included is something that should be discussed, so here's my
> kickoff in this area to start a conversation:
>
> * The idea is to include support for a new architecture in MeeGo, like
> we would do in case of a MIPS port of MeeGo, ie, bootstrap port is
> done (Trunk compiled..), people are assigned to take care of bug
> fixes, build capacity donated, approved by TSG at some point. This
> would be ARMv7 hardfp, let's call it armv7hfp.
Basically ack. This needs to be done in rpm first. So we need to talk to rpm
folks
and propose a patch. As they're using armv7l we could name it armv7hl ("h"
for hardfloat).
Or is there some upstream consent on armv7hfp ? We shouldn't reinvent the wheel
and use
this too for the toolchain tuple.
But then we need to teach rpm how to differ softfloat from hardfloat -
obviously we don't want users to mix it.
> * Organisationally, do we deprecate ARMv7 (softfp) and state it has
> been replaced with armv7hfp for 1.2?
Well, as we've no way to migrate softfp -> hard , what else can we do ?
We can build for softfp during a grace period to make transition possible.
> * To do this, technically, we'd have to bootstrap the port like we did
> with MeeGo ARMv5. Due to the softfp/hard conflict, we cannot reuse any
> of the ARMv7 binaries. Back then we started with MeeGo ARMv5, we used
> Fedora ARM to bootstrap a base system.
>
> Since there's no hardfp port of Fedora ARM, I propose that we
> bootstrap using debian hardfp port, debian-armhf, or using Linaro's
> work in this area with Ubuntu. Having Linaro involved could be a good
> thing.
>
> The reason for this is that rpmbuild and other tools exist for this
> platform as well and hence we can do a set of binary armv7hardfp RPMs
> we can use for starting proper OBS compiles of the MeeGo Trunk.
The actual initial bootstrap (on whatever base we do it) is not that big issue
-
I can provide a walkthrough and do the initial set.
> Support for OBS+RPM tools for armv7hardfp 'architecture' would be
> needed and potentially qemu-arm support..
IMHO this is the main things to get this up and running:
-------------------------------------------------------------------------------
* rpm support to handle/differ armv7 hardfloat
* proper qemu-arm support for armv7 hardfloat
* obs needs own scheduler name for armv7 hardfloat
* bootstrap basics on armv7 hardfloat and build distro with hardfloat.
> Of course this means our 1.1 developer story sucks from a binary
> compat point of view, but the risk is that we'll be tied forever to
> softfp instead..
Yes, exactly. Bet we've the tools to do it !
> And throwing this in the discussion too: -mfpu=neon or not in MeeGo
> ARMv7 hardfp?
Should we really hardcode this ? I'd opt for <foo>-neon optimized packages as
glibc can figure that out and fetch the right libraries at runtime (vfp or
vfp/neon subfolders) !
This will ensure broad board support.
Best,
Jan-Simon Möller
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
