> What I would recommend you do is that you test this code in user-mode on
> Linux, booting from the standard BIOS.
>
> That's how I got the new pci code working, and how we tested our early SPD
> code. You can then verify all your SMBUS operations in a sane world, get
> them figured out, and then try them out again in linuxbios.
Yes ... sounds like a good idea.
> Are you using an Arium? I have some of those mainboards lying around (I
> think); we can try to replicate your problem here.
No such luck! I wish I had one of those around it would be extremely helpful!
If you do have a bit of time and a similar board It would be much appreciated ...
despite
all the debugging the code I am using is the same as your vt8601 (spd) code except for
the change in the PCI configuration address for the SMBus controller which is Bus
number
0, device number 4 and function number 3 but the same offset of the registers. I am
getting this bit right as it is putting its register set in the requested offset into
the processor
IO space.
I have had a few things that I can't explain happen while debugging and was
wondering if you had any ideas what might be going on. When I was trying to debug the
what was being written to the SMBus io registers I setup a series of delays after
writing the
information to the POST card so I could see multiple values on one debug pass. The
first
thing was that with multiple loops they became a shorter delay for each loop (is this
the
Level 1 cache at work ... except it only needs to go once round the loop to cache it
and it
was a macro so the loops were different code in different positions) and I was getting
different values back from the registers on multiple runs of the code. Now this might
make
you think that it isn't being set properly ... but I also did this the long way and
added a
write to the POST card and a halt after every write to a port to read back what had
been
written and this gave me rock solid consistent results! I can't understand what was
going on
the other time.
Marcus
