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