Re: [osol-code] Programming funny PCI device

[Dan Mick]

Cyril Plisko wrote:
On 11/15/06, Dan Mick <[EMAIL PROTECTED]> wrote:
Cyril:  Which device is this, and is its spec freely available?

I am not sure the spec is free - I'll check it.

And it appears to me now (after some additional research I did
on that) that it is BIOS fault/feature. It is BIOS that were to program
the vensor specific bit during initialization. Does it makes sense ?

That makes a lot more sense, yes.  Then, by the time the OS enumerates it, 
it's either one type of device or the other, and normal OS init procedures 
work as expected.



Dan Mick wrote:
> Cyril Plisko wrote:
>> On 11/14/06, Dan Mick <[EMAIL PROTECTED]> wrote:
>>
>>> >> Cyril, what happens when you enabled this BAR - presumably it 
needs
>>> >> resources allocated to it?
>>> >
>>> > Yes, I need to map this BAR. If that is what you mean by allocating
>>> > resources
>>>
>>> well, "map this BAR" is ambiguous.  Physical memory space needs to be
>>
>> Hm, by "map this BAR" I mean that I want ddi_regs_map_setup() call to
>> succeed.
>> Is it less ambiguous now ?
>
> Yes, but the problem is that's a multi-step process.  First, the BAR 
has
> to be programmed with the base address of the physical region allocated
> for it; then, ddi_regs_map_setup() assigns a virtual address to that
> physical address.  The latter is what most people mean by "mapping", 
but
> it's not going to happen without the first stage happening, which
> involves global resource allocation.
>
> (and, apparently, on this device, before all *that*, some
> device-specific register must be written to even make the BAR appear.)
>
>>> or other OSes, I bet.
>>
>> I lack a relevant experience to say that for other OSes.
>> Would, say, Linux have similar problems with such a device ?
>
> If I knew for certain, I wouldn't say "I bet", but, "I bet".
>
>>> The only thought that comes to mind is a device-specific hack in the
>>> generic allocation routines.
>>
>> I am willing to invest some time into hacking this, what would be the
>> place to start looking at (from your experience) ? pci_autoconfig ?
>
> yes; that's the global PCI enumerator and resource allocator.
>
>> when my laptop boots it spits the following message to 
/var/adm/messages.
>> Nov 14 08:54:54 zulu pci_autoconfig: [ID 771164 kern.info] NOTICE:
>> reprogram pci device [0/2/1] (pci1014,582)
>>
>> Does it mean that similar hacks are already exist in pci_autoconfig ?
>
> No, that's just assigning address space to BARs that are present but 
not
> written to non-zero (physical) base addresses.  This is one step
> further, in that the BAR doesn't even appear to be present until
> device-specific code runs.
>
> _______________________________________________
> opensolaris-code mailing list
> opensolaris-code@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/opensolaris-code





_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code