Harald Gutmann wrote:
* hda: UDMA/33 compared to UDMA/66 with prop. BIOSMy 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.
(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. :\
//Peter
On Tuesday 07 July 2009 19:30:03 Peter Stuge wrote:
Harald Gutmann wrote:
* hda: UDMA/33 compared to UDMA/66 with prop. BIOSMy suggestion would be to open up a new ML-thread according to this problem.
Good idea.
Thanks for doing so!
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.
(but I don't know if it's for real a bit which needs to be set).
Usually there is.
Okay, fine. But then I'd really be interested how the proprietary bios does know if it needs to set it or not. Or, how do we find out if there is an 88 wire IDE cable used instead of a 44(?) wired cable?
Ideas? Assumptions?
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. :\
I think that we'll find it. :)
//Peter
On Tuesday 07 July 2009 19:30:03 Peter Stuge wrote:
Harald Gutmann wrote:
* hda: UDMA/33 compared to UDMA/66 with prop. BIOSMy 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
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.
Oh, I wanted to attach some files here so it's easy to verify. amd_cable_detect.c is some cp&paste from amd_74xx.c under drivers/ide from the linux sources.
//Peter
Regards, Harald
Harald Gutmann wrote:
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".
Fair enough, but this is the "output" of coreboot. The tricky part is to find the "input" for the coreboot code. How to find out which cable type is really attached, on this chipset?
//Peter
On Tuesday 07 July 2009 21:47:57 Peter Stuge wrote:
Harald Gutmann wrote:
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".
Fair enough, but this is the "output" of coreboot. The tricky part is to find the "input" for the coreboot code. How to find out which cable type is really attached, on this chipset?
I know that, and that's the question about "when" to write the output. For a quick and dirty, compile-time option fix, this information is enough, but not for a runtime-solution.
//Peter
On 07.07.2009 21:47, Peter Stuge wrote:
Harald Gutmann wrote:
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".
Fair enough, but this is the "output" of coreboot. The tricky part is to find the "input" for the coreboot code. How to find out which cable type is really attached, on this chipset?
I think there is a chipset GPIO you can read to find this out. Dumping the factory BIOS GPIOs for 40-pin and 80-pin cables would probably help find the correct setting.
Regards, Carl-Daniel
On Tuesday 07 July 2009 23:11:18 Carl-Daniel Hailfinger wrote:
On 07.07.2009 21:47, Peter Stuge wrote:
Harald Gutmann wrote:
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".
Fair enough, but this is the "output" of coreboot. The tricky part is to find the "input" for the coreboot code. How to find out which cable type is really attached, on this chipset?
I think there is a chipset GPIO you can read to find this out. Dumping the factory BIOS GPIOs for 40-pin and 80-pin cables would probably help find the correct setting.
Good starting point, but makes no difference in using proprietary bios and switching the cable to 40 wired once. All GPIOs stay at the same value as with the 80 wire cable.
I think that the pci-registers of the ide device are more interesting in that case. My assumption is, that it is value 0x72 in the ide device (00:4.0) pci- register, is what I'm searching for.
Why and how I figured that out? 1. dump pci-registers of proprietary & coreboot of the ide-device. 2. replace the 80wire cable with a 40 wire cable and dump the registers again. 3. start to compare all the dumps, and search for a value which is equal on coreboot and proprietary with 80 wire cable and changes to the same value in coreboot & proprietary bios when using the 40 wire cable.
4. assume you did everything right and claim that it is value 0x72 (hopefully you got it right with the pci-register-endianness and the address number). ;)
I attach all my logs which are relevant on that topic and hopefully someone of you can check this again.
This should be the input we're looking for. :)
Regards, Harald Gutmann
Regards, Carl-Daniel
PS: I've also managed to get a floppy device and I'll test if this works fine.
On Monday 13 July 2009 20:32:46 Harald Gutmann wrote:
- assume you did everything right and claim that it is value 0x72
(hopefully you got it right with the pci-register-endianness and the address number). ;)
Okay, this was for sure wrong, as I read the line number instead the pci- register number. It has to be 0x52 instead 0x72.
Attached is a little patch, which is not working on different hardware than mine, as some values are hard-coded. Also the place I patched that stuff is totally "wrong".
This patch works for me on my hardware: [ 2.256143] hda: UDMA/133 mode selected [ 2.256333] hdb: UDMA/66 mode selected
There are a few things which I need to figure out to get this stuff working like it should: [*] Where shall I add the patch? src/southbridge/nvidia/mcp55/mcp55.c in mcp55_enable case device = IDE? some better/different suggestions?
[*] How to figure out the UDMA modes supported by the attached devices in coreboot? As this is according to IDE devices which can be changed at any time, it would be necessary to check for supported UDMA modes on run-time.
Any suggestions/ideas/further reading documents/... is welcome.
Kind regards, Harald Gutmann
On Mon, Jul 13, 2009 at 4:14 PM, Harald Gutmannharald.gutmann@gmx.net wrote:
[*] How to figure out the UDMA modes supported by the attached devices in coreboot? As this is according to IDE devices which can be changed at any time, it would be necessary to check for supported UDMA modes on run-time.
I am still confused by the more basic question of how you are detecting the presence of an 80 conductor cable. You need a GPIO or one of the mechanisms described in the PATA spec from T13. You need that in addition to knowing what the drives support. To know what the drives support you look in their identify device information (also specified by T13, but you can find examples in the kernel or Hale Landis' code)
On Tuesday 14 July 2009 00:34:12 Tom Sylla wrote:
On Mon, Jul 13, 2009 at 4:14 PM, Harald Gutmannharald.gutmann@gmx.net
wrote:
[*] How to figure out the UDMA modes supported by the attached devices in coreboot? As this is according to IDE devices which can be changed at any time, it would be necessary to check for supported UDMA modes on run-time.
I am still confused by the more basic question of how you are detecting the presence of an 80 conductor cable.
The AMD74xx ide controller has the advantage that the presence of the 80 conductor cable is reflected in it's pci-registers. I determined that through the kernel driver source for this controller and verified it with replacing the 80 wire cable with a 40 wire cable. The bit 0x52 of the pci-registers from the AMD74xx controller changes to 04 when using a 40 wire cable.
You need a GPIO or one of the mechanisms described in the PATA spec from T13.
This shouldn't be necessary for the 80 wire cable, as this is reflected in the pci-register.
You need that in addition to knowing what the drives support. To know what the drives support you look in their identify device information (also specified by T13, but you can find examples in the kernel or Hale Landis' code)
This is ATM the interesting part which needs to be done. Figuring out which UDMA mode is supported by the attached drives, as the kernel driver sets the mode to a value which is also in the pci-registers of that controller. The value is at offset 0x62-0x63 for primary master & slave. My little previous attached patch does check if the 80 wire cable is used, and if it's used sets the 0x62-0x63 values to those which are needed by my connected devices. This part is right now hardcoded, and should be done via looking up the device information and set the value dynamically to work with every ide-device.
Regards, Harald
-
Carl-Daniel Hailfinger -
Harald Gutmann -
Peter Stuge -
Tom Sylla