Alright, I've finally got a follow up with the raminit logs and bx
configuration dumps. Hopefully you'll find something interesting or
useful in there. As expected, I had to use serial capture for the
raminit logs, since the default cbmem size isn't large enough.
I didn't get any logs from it completely failing though, kept
forgetting to have the serial capture running when rebooting from
memtest with the ram unstable. Sometimes it reboots from memtest fine
(by pressing escape), but others it hangs or boots with the ram even
more unstable then the first time. This unstablility is still only
initially triggered after rebooting from the gentoo uclibc hardened
As for the pentium ii, it seems that coreboot does fail to init the L2
cache. I hadn't even looked at the cbmem previously to see what was
going on. It's a 400MHz Deschutes SL3D5. I have no idea what was all
involved in figuring out the values for the latency table (intel
documented or not?) - assuming that's what the problem is. It's not
likely I'm going to actually use this processor normally anyway.
For the multiplier jumpers, I had thought that the processors where
multiplier locked/auto, but didn't understand why the board had
jumpers for it then. Figured it was either for early pii's or special
unlocked processors. They don't do anything, I must have just been
having issues with the processor, ram, agp/pci cards, or bios chip not
being seated right. I've had it fail to do anything a few times after
messing with stuff.
As for the bus frequency, I did end up playing around for a bit with
that a bit. For being a lower end nb, the 440zx didn't seem to have
any problems. I ran a piii 866MHz no problem, ram was stable even with
140 bus speed. Neither of the pair of agp video cards liked the agp
bus being overclocked though. Probably not a good idea to be
overclocking an almost 20 year old system, especially with it being
the only p2b/p2-99 still being tested with coreboot and being the only
board with coreboot running on it that I have.
As for the floppy and devicetree.cb, it seems to be enabled. I'll have
to try it again and see if anything shows up in the cbmem or for
seabios. Maybe check the bios vs coreboot /proc/ioports a bit closer
The seabios ps/2 keyboard init still seems to fail sometimes as well.
It usually works fine after a reset though. I think when I tried to
set a ps/2 init timeout for seabios I was using the master version and
it didn't seem to do anything. I'll have to try it again with the
serial console output and possibly some level of debug output from
seabios, maybe even just use coreboot's ps/2 keyboard init.
Thanks for the work you've done with these older systems, without
support for them, I probably wouldn't have been willing to try
coreboot. Most of the newer systems I have it wouldn't be practical to
have them sitting on the workbench trying get coreboot to work on
them, they're already in use.