More j820 breakage.

[Francois-Rene Rideau]

KERNEL BOOT PROBLEM
After recompiling the kernel with the 2.95.3 toolchain from handhelds.org
I could successfully boot. Retrying with the 3.3.2 toolchain,
hpcboot refuses once again to start my kernel.
I tried to compile everything with 3.3.2 except for the last step
(make j820), but that didn't work. I haven't yet tried to track down
more precisely which step breaks with the 3.3.2 toolchain.
What does hpcboot look for before it prints the kernel entry address?
Oleg: can you publish your hpcboot tree together with the toolchain you use?

BUSYBOX
I can't compile busybox with the 2.95.3 toolchain from handhelds.org. Sigh.

PCMCIA
The pcmcia package seems to compile with either 2.95.3 or 3.3.2
however, it only accepts to configure if I had a PCI-enabled i386
kernel in /usr/src/linux, and the configuration was useless.
In an attempt to clean up the CVS tree, I changed our Makefile
to short-circuit the pcmcia-cs configuration process and compile directly,
explicitly specifying static linking.
But the resulting cardmgr (compiled with 3.3.2) doesn't look like it works,
or maybe it's the kernel PCMCIA not working. I get the following error:
  cs: socket c0035800 timed out during reset.  Try increasing setup_delay.
when I insert my PCMCIA pcnet_cs, and when I use my CF memory I get
  cs: socket d00da000 timed out during reset.  Try increasing setup_delay.

RAM EXPANSION BOARD
In other news, the 16MB of F1267A RAM extension seems to be
in bank 2 @ D0000000, but I'm not sure.
First, I tried to peek at the RAM with busybox, using such commands
	dd if=/dev/mem of=foo bs=$(( 0x1000 )) count=1 skip=$(( 0xc0000 ))
but get an error with return code 1 and the following error:
	dd: /dev/mem: Success
Failing that, I wrote some memory autodetection routines to be run from
fixup_jornada820(), but they were crashing the system early on, even
when just trying to detect and printk() without setting things. Sigh.
I suppose it isn't legit to peek and poke at addresses where there is no RAM.
Yet, this is how blob does it, isn't it?
(Plus blob will clobber the RAM cells it tries word,
which will prevent the kernel from working properly.)
That said, it's a long time since I haven't tried blob.
Maybe I'm just doing something incredibly stupid.
I will have to put a console on serial to debug the autodetect code.
In the meantime, I'm just compiling a special-cased kernel.
So, for the record, trying to use 32MB in bank 0 fails miserably
before the framebuffer is even set, trying to use bank 1 crashes quickly
after framebuffer init.
Oleg: can you post the code you used to find out about RAM banks 0, 1, 2, 3?

MICRODRIVE
In yet other news, my replacement microdrive is dead.
Maybe my heavy usage pattern quickly overheats this cheap model?
I *disrecommend* these 2.0GB CF+Type II "tinydrive" Model: TD-1020C.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[  TUNES project for a Free Reflective Computing System  | http://tunes.org  ]
He who refuses to do arithmetic is doomed to talk nonsense.
	-- John McCarthy, in his webpage on Progress and Sustainability