On Tuesday 07 July 2009 19:30:03 Peter Stuge wrote:
Harald Gutmann wrote:
* hda: UDMA/33 compared to UDMA/66 with prop. BIOS
My suggestion would be to open up a new ML-thread according to this problem.
Good idea.
It should be "easy" to fix, and I think that it has nothing to do with the DMA modes itself, but with the "88pin-wire-cable-bit"
Yep.
How does the bios check if an 80wire cable is used or not? That means, on which event/basis/.../.../ we need to set those "magic bits"?
(but I don't know if it's for real a bit which needs to be set).
Usually there is.
I also tried to investigate that problem, but ran out of time the evening I started. (check kernel ide-drivers amd7xxx.c (or similar) to find out what's going on there).
I hope the bit we want isn't hidden in a chipset doc which we can't find. :\
Found!
According to some kernel sources and the differences in the pci-registers between proprietary bios and coreboot there are two values which are needed:
AMD_CABLE_DETECT = 0x42 AMD_UDMA_TIMING = 0x50
But, for PCI_VENDOR_ID_NVIDIA an offset of 0x10 has to be added, which means: AMD_CABLE_DETECT = 0x52 AMD_UDMA_TIMING = 0x60
PCI registers on coreboot address 0x52 (from the IDE device) has value FF while proprietary has value 99. This is the so called "CABLE_BIT".
And as the second stuff needed, the AMD_UDMA_TIMING registers is as follows: The kernel reads the whole address range from 0x60-0x92 and does some magic stuff to verify if everything is correct.
On the proprietary bios we have in this range in the pci-registers: 60: 00 00 c5 c7 00 00 00 00 00 00 00 00 00 00 00 00 On coreboot we have: 60: 00 00 c0 c0 00 00 00 00 00 00 00 00 00 00 00 00
Thats what to do, but when? - Maybe tomorrow.
//Peter
Regards, Harald