speaker beeper

[Ronald G. Minnich]

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