Re: It boots!
Jim Pick wrote:
>Unfortunately, our bash also has the floating point code in it, so it
>won't work (you need bash to call the script to insert the emulator
>module). I had to install Corel's bash, /lib/ld.so, and
>/lib/libc.so.4* into the Debian partition. We'll have to figure out
>how to get around this...
Philip Blundell wrote:
>Here are a few thoughts about ways in which this could be done. Maybe it will
>give someone a good idea. :-)
>1. Fiddle the kernel so that it can load the fpem.o module itself.
>2. Give up on the floating point emulator and use -msoft-float/--without-fp
>3. [Pass] the default floating point control word to the libc startup code
>4. [Remove floating point from init-first.c and link init and bash with that]
>5. Write an open-source floating point emulator and [compile into the kernel]
>My recommendation would be #3 or #4 in the short term and #5 as the eventual
6. Write a small C program, init-boot, which does only three things:
read in fpem.o, insmod it, exec init proper. Set up the boot loader
to pass "init=/sbin/init-boot" to the kernel. You can probably nick
most of the necessary code from insmod itself.
I suppose you'd have to link init-boot as per (4) above, but you wouldn't
have the worry that you'd cripple something as vital as bash if it didn't
work, or of redoing your changes every time bash was upgraded.
In the long term, I'd expect that using soft-float (2) would be better
than using a floating point trap emulator, for reasons of efficiency,
but having both would allow you to also support binaries which expect
an FPU, too. (I can't imagine a trap being quicker than in-line code.
OTOH, on the ARM, there might not be much difference.)
In fact, if GCC can open-code FP (or has a library for it), an FPU
emulator should be easy to write... No FP work to be done there at all!
(Note: I have no knowledge of the ARM/StrongArm except what I've
read here, and that I've looked at a few data sheets. I don't have a
Incidentally, does anyone know of a set of free "reference"-style
IEEE-754 FP routines? Knuth's TAOCP isn't up-to-date enough to cover
gradual underflow in anything other than a footnote.
White pages entry, with PGP key: <URL:http://alethea.ukc.ac.uk/wp?95cpb4>
PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2