I cut the trace, enabled flash and flashed it. I'm now the proud owner of a doorstop. :-)
At the end of this email is a paste from the serial log. It boots, says it jumps to RAM, my HDD light flickers (I'm using the BOOT_IDE flag) and then it starts over again.
A couple of questions: Is it saying it's happy with the system RAM? I do not have a kernel image at the location I said it would be at in the config file, which is why I _think_ that it is rebooting, but I thought there'd be some kind of log message stating something to that effect.
My other question is one I probably already know the answer to: is there a serial-port flash util in LinuxBIOS? It's not a big big deal, I knew the risks going in to this but I'd like to try and get around desoldering a TQFP part and buying the adaptor (and socket) if I can help it. These motherboards were only $10, it seems silly to spend hundreds to reflash it. :-)
(and yeah, the date is right... it's been over a month since I've been really working on it. :-)
Regards, Andrew
LinuxBIOS-1.0.0 Mon Nov 25 21:39:06 EST 2002 starting... Ram1 After 0x0000000 nop... Before 0x4000000 nop... After 0x4000000 nop... After 0x54... After 0x00... Before 0x4000000 nop... After 0x4000000 nop... After 0x4000000 nop... Before 0x4000000 nop... After 0x4000000 nop... First DRAM setup done Ram2 Ram3 Ram Enable 1 Ram Enable 2 Ram Enable 3 Ram Enable 4 Ram Enable 5 Ram4 Ram5 Ram6 Copying LinuxBIOS to ram. Jumping to LinuxBIOS.
LinuxBIOS-1.0.0 Mon Nov 25 21:39:06 EST 2002 starting... Ram1 After 0x0000000 nop... Before 0x4000000 nop... After 0x4000000 nop... After 0x54... After 0x00...
... forever.
just checking, but I have forgotten some things.
I assume that you used a different flash part? or that you use the dumpdevmem command to save your flash image? or have some way to get back?
ron
jumps to RAM, my HDD light flickers (I'm using the BOOT_IDE flag) and then it starts over again.
A couple of questions: Is it saying it's happy with the system RAM?
All of my results like this were that RAM was not really there. It is copying the C code to ram, which isn't there, and then jumping to garbage, which on many mobos results in a reboot eventually.
Could be the ram is in the wrong slot. Did you try all RAM sockets? Some bridge implementations in LinuxBios expect a particular socket (#1 if it is numbered).
-Steve
I assume that you used a different flash part? or that you use the dumpdevmem command to save your flash image? or have some way to get back?
Same flash part (soldered TQFP part, which is why I was doing so many checks in Bochs first). I do have an copy of the old bios though.
Regards, Andrew
All of my results like this were that RAM was not really there. It is copying the C code to ram, which isn't there, and then jumping to garbage, which on many mobos results in a reboot eventually.
Crap. :-(
Could be the ram is in the wrong slot. Did you try all RAM sockets? Some bridge implementations in LinuxBios expect a particular socket (#1 if it is numbered).
There is only the one slot. This particular system would only accept EDO before, but it's a 430TX chipset which should work with either. I tried both EDO and SDRAM SODIMMs without success.
Time to unsolder the part. I think I'm going to install a DIP socket and officially declare this particular motherboard my sacrificial system. :-)
Regards, Andrew
Time to unsolder the part. I think I'm going to install a DIP socket and officially declare this particular motherboard my sacrificial system. :-)
Well the system is sacrificed and I got quite far with a 28F001 DIP part in a ZIF zocket. Unfortunately I connected +15 to the wrong pin (off by one errors in hardware are often more damaging than in software) last night and fried something. I had RAM initialized properly now (I think) and ramtest was executing the load part. Unfortunately the SuperIO (SMC FDC37N958FR) seems to have a watchdog in the internal 8051 core and the 8051 firmware does not follow SMSC's recommended mailbox protocols so I can't shut it off directly. <grrrrr>
Does anyone have a P5-class ICE I can borrow? :-) Bochs doesn't get far enough running the original BIOS to see how the mailbox registers are accessed. I had hacked it to spit out any I/O accesses but I have to do a lot of work in getting the tx chipset more fully emuated before the original BIOS will get to the part where it talks to the 8051 core. :-(
Regards, Anderw
-
Andrew Kohlsmith -
Ronald G. Minnich -
Steve M. Gehlbach