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
signature.asc
Description: This is a digitally signed message part.
-- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
