On Mon, 2008-10-13 at 13:37 +0100, Martin Guy wrote: > On 7/31/08, Ahmed Ammar <[EMAIL PROTECTED]> 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 > code. 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. Best Regards, Ahmed Ammar
