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 install.
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 yet too.
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.