On Tuesday 14 July 2009 00:34:12 Tom Sylla wrote:
> On Mon, Jul 13, 2009 at 4:14 PM, Harald Gutmann
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
On Mon, Jul 13, 2009 at 4:14 PM, Harald Gutmann 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 con
On Monday 13 July 2009 20:32:46 Harald Gutmann wrote:
> 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). ;)
Okay, this was for sure wrong, as I read the line number instead the pci-
register
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
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
>
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
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
> 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
>
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
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.
Thanks for doing so!
> > It should be "easy" to fix, and
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-wir
11 matches
Mail list logo
