On Fri, 14 Jan 2005, Adam Talbot wrote:
-Ron OK, so what would you advise is the next step. Where should I start looking/debugging.
Well, this is where it gets hard. I think the northbridge is wedging because something is wrong in the setup. Basically, if you program the northbridge kind-of-right and you get data errors, then you screwed up the dram config, so the timing is wrong, but the northbridge is kind of working. But if the northbridge locks up the machine like this, then you've screwed up the northbridge config and you need to find out what's wrong before you go another step. Our northbridge config code is wrong.
I think there is some clock we have not enabled that sequences a state machine in the northbridge. Just guessing, not sure. On the 430TX chipset there was a bug such that you had to do a write, not a read on a Mode Register Set command. Was this documented publicly in any way? Hell No. Did the existing documentation directly contradict this way of doing the Mode Register Set? Hell Yes. Did any other northbridge we've ever seen work this way? Hell No. We just guessed our way into fixing that one. And, no, this is not the bug in this i855gme chipset -- I've tried that fix.
But it is locking up on the Mode Register Set command, I believe. Intel has no interest in helping us with this, as they are concerned that helping us with LinuxBIOS will expose "core IP". They have made it very clear to us that they feel the future of BIOS efforts, even Open Source ones, will have to involve the use of proprietary, closed-source code. Without commenting on our opinion of Intel's position in this matter, for now we have decided to place our faith in Open Source as much as we can and work with cooperative vendors for our embedded efforts.
Nevertheless I hope you figure this out.
Here is an interesting way to attack this problem. It's a bit of work. 1. Define a new register set for romcc to use, called 'low 64k of flash'. This register set is written/read with normal flash commands. It will be slow as molasses, but who cares? This Is A Test. 2. Compile the x86 emulator with romcc. You now have an emulator that does not need RAM to operate. 3. have the emulator run the fuctory bios as the code for the x86 emulator. Watch all the register reads/writes that the bios does to the northbridge. You now know how to program the chipset.
You've now got a general purpose BIOS reverse engineering tool. This is our Nuclear Option, which we have not gone to yet, but: in the long term, it will be possible, using romcc and techniques such as this, to find out what magic the bios is doing to make the chipsets work. I've not done this as I prefer just to find a friendly vendor and work them -- we've got AMD to name one friendly vendor, so why not work with a company that wants to work with you?
But, in the long term, people who want to figure the chipsets out can do so, using emulation technology. If you want to see heroic reverse engineering, find the article by the guys who reverse engineered the early Xbox bios. That was really amazing.
ron