On Mon, 2008-10-13 at 13:37 +0100, Martin Guy wrote:
> On 7/31/08, Ahmed Ammar <firstname.lastname@example.org> wrote:
> > I am currently working on some QEMU patches to add support for the
> > EP93xx (and the ts-7200 board) I have had some general success but this
> > is far from complete. My main issue is the Maverick-Crunch FPU and some
> > question to see if anyone has had the same experience.
> > Which patch-set are people generally using, there seem to be two sets:
> > 1) futaris ones which seem to be the openembedded.org ones
> Where do you find "the openembedded ones"? I have looked for them but not found.
> Do you know how to find them without setting up a whole OE build environment?
They used to have their repository available for online viewing but as
far as i can see it's been removed. Maybe too many people grabbing what
they wanted via http.
> I know there is the tarball under files.futaris.org/gcc for 4.1.2 and 4.2.0
> > 2) the cirrus linux ones which are up to version 1.4.3.
> I dunno about "people"
but the only set ever to pass the gcc
> testsuite are the ones under files.futaris.org/gcc for 4.1.2 and
> 4.2.0. To achieve this they get round one of the problems by disabling
> all conditional instruction execution. In theory this disables some
> optimisation but in practice, if you are doing FP and can enable the
> FPU, the loss is negligable.
> Of the two, 4.1.2 requires less memory to build it and to compile
> things, compiles things faster and seems to produce smaller faster
I have moved back to 4.1.2 now as that seems to provide the best working
tool-chain, although there are the known issues that you have also
posted about (Hasjim's April ideas).
> > I have been using the
> > openembedded ones with gcc-4.2.4 but compiling the arm kernel (which by
> > default compiles with -msoft-float) will cause a kernel panic on boot.
> The kernel does not use any floating point by design, so you should
> not be worrying about this. I would guess that the breakage you are
> seeing by adding -mhard-float or whatever changes the function call
> ABI and breaks something in the kernel that knows about that, like the
> assembly routines. Compiling with floating point instructions is only
> an issue in userland.
The 4.2.4 patches that i was using as i said probably produced a broken
tool-chain so i moved back to 4.1.2 as you recommended.
I am pleased to hear that you are now being financed to continue where
others have left off as getting around certain bugs is very annoying
(broken unwind support)
I can help with any testing you may require as I am currently using this
arch in a product we are developing.