More hacking the j820

[Faré]

OK, so I completely rehauled the build infrastructure. You might want to
   make dist-clean
before you use it, if you update your CVS.

I made everything much more deterministic by only picking
well-numbered version. No more dependency on moving CVS targets.
(Well, OK, the toolchain still moves, but that's a one liner away in
the Makefile.) Note that on x86_64, gcc 4.0 or 3.4 won't compile the
toolchain so you'll need gcc 3.3 for that.

I hacked a bit the USB with the "improvement" that the j820 crashes
immediately when you modprobe usb-ohci-sa1101 instead of doing a
corrupting fandango on core first.

I cleaned up the 2.6 source so that at least it would compile, though
it has no chance in hell of running in its current state... that's
just to make the compile not bork before the file that YOU will be
hacking. For you're gonna hack, won't you? (Who am I kidding)

I got schemix to compile as a module under both kernel 2.4 and 2.6, so
that we may do some live runtime development/debugging on the kernel
with it -- if it actually runs (not tested yet, and it might miss some
FPU functions, oops). To enable it, just have the SCHEME environment
variable pointing to some valid scheme interpreter, such as
   export SCHEME=mzscheme
If we actually get it to work, I'll try to figure out what happens
when the keyboard is locked up. (Do you have an idea?)

The j720 developer have a sa1111 working ok except for cpufreq, so
we'll soon have an upstream strongarm kernel to get working code and
inspiration from.

As you see, I'm an infrastructure guy. I can get the infrastructure
right, but there's a limit to what I can do regarding drivers & co.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
The meta-Turing test counts a thing as intelligent if it seeks to apply
Turing tests to objects of its own creation.
                -- Lew Mammel, Jr.