Coming from somebody who has done only a fraction of the maverick hacking that Martin Guy has done (martinwguy.co.uk/martin/tech/Maverick/) I can safely say that as of right now, maverick is definitely NOT stable, and I would NOT include this patch in any release.
Martin has been doing an incredible amount of work, and the maverick co-processor patches are actually coming close to the point of being ready. Right now it works 'correctly' aside from disabling the 64-bit code generation. He's tested it with Paranoia, the GCC testsuite, the OpenSSL testsuite and now FFTW. It's very close, but because of some long-standing issues (I would say poor hardware design was one of them), the speedup is not as dramatic as one would hope, due to the necessity for multi-process data integrity. C On Tue, Dec 23, 2008 at 11:51 PM, Jakub Ladman <[email protected]> wrote: > I do not uderstand it too. > What this patch is intended for? > What motivation? > I understand only, that it should correspond with my need for maverick enabled > crosscompiler, but i don't know in which way. > > Jakub Ladman > > Dne Friday 26 of September 2008 10:12:56 [email protected] napsal(a): >> Hi!!! >> This patch add one stage(-s1, --stage1 Also build kernel and libc >> headers) betwen 0 and 1 stage, for available this trick: >> >> crossdev -S --ex-gdb --g 4.2.4 -v -t armv4tl-maverick-linux-gnueabi -s1 >> EXTRA_ECONF="--with-cpu=arm920t --with-tune=arm920t --with-fpu=maverick >> --with-float-abi=softfp" crossdev -S --ex-gdb --g 4.2.4 -v -t >> armv4tl-maverick-linux-gnueabi -s2 >> crossdev -S --ex-gdb --g 4.2.4 -v -t armv4tl-maverick-linux-gnueabi -s4 >> EXTRA_ECONF="--with-cpu=arm920t --with-tune=arm920t --with-fpu=maverick >> --with-float-abi=softfp" crossdev -S --ex-gdb --g 4.2.4 -v -t >> armv4tl-maverick-linux-gnueabi -s5 > > > >
