Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

PCI9080 and EEPROM trouble

0 views
Skip to first unread message

Christoph Minkwitz

unread,
Apr 20, 1998, 3:00:00 AM4/20/98
to

Hi there,
I know that the subject of my writing is only near to the subject of
this group, but I have found no better place (if someone knows one,
please give me a hint).
The problem in short:
We have a PCI card with the PCI9080 on it, a clock and a blank, serial
EEPROM, running under NT4.0 SP3. The system boots properly and we can
read the runtime registers of the card. The CNTRL register says that
there is no EEPROM (bit [24] = '0' but if we read from the EEPROM the
result is 0xFFFF as expected (blank EEPROM). Writing is not possible,
may be, that we even did not read anything propper. What are we missing?

I do not want to fill the group with this not related subject, so please
e-mail me any answer to "Christoph...@himh1.hi.bosch.de".

Thanks

Christoph


Adam Zderski

unread,
Apr 21, 1998, 3:00:00 AM4/21/98
to

Christoph Minkwitz wrote in message <353B6315...@himh1.hi.bosch.de>...


>Hi there,
>I know that the subject of my writing is only near to the subject of
>this group, but I have found no better place (if someone knows one,
>please give me a hint).
>The problem in short:
>We have a PCI card with the PCI9080 on it, a clock and a blank, serial
>EEPROM, running under NT4.0 SP3. The system boots properly and we can
>read the runtime registers of the card. The CNTRL register says that
>there is no EEPROM (bit [24] = '0' but if we read from the EEPROM the
>result is 0xFFFF as expected (blank EEPROM). Writing is not possible,
>may be, that we even did not read anything propper. What are we missing?


Serial EEPROM present is in reg PCI6Ch bit 28, is it not?

If this bit is not active and you have read 0xFFFF then perhaps it is empty
as you have suggested. If you have mis-read the EEPROM the BAR values may
address some memory.

To help you any further I need some more info.
What are the BAR values?
Is the h/w designed in house, and can it be modified?
If the EEPROM requires programming you could do this by connecting
Program Enable (PE) to the General Purpose line, or simple mod the board so
PE is high.

Any questions I can further help with just e-mail me.

Christoph Minkwitz

unread,
Apr 21, 1998, 3:00:00 AM4/21/98
to

Hi Adam,
thanks for your respond, the problem is the not compatible EEPROM. We try to get

a right one.

Adam Zderski wrote:

> Serial EEPROM present is in reg PCI6Ch bit 28, is it not?

Sure, it's a funny thing, how mistyping or selecting the wrong EEPROM happens
:-).

> If this bit is not active and you have read 0xFFFF then perhaps it is empty
> as you have suggested. If you have mis-read the EEPROM the BAR values may
> address some memory.

I think the BAR values are used correctly, if not I would expect a crash.

> To help you any further I need some more info.
> What are the BAR values?
> Is the h/w designed in house, and can it be modified?
> If the EEPROM requires programming you could do this by connecting
> Program Enable (PE) to the General Purpose line, or simple mod the board so
> PE is high.

It's our card, we can change it, but I hope these problems are gone by choosing
the right EEPROM.

The answers leads me to another point: I seem to have not the right
understanding of the thing called PCI master DMA till now.
- In the system structure CM_PARTIAL_RESOURCE_DESCRIPTOR there is a member
'struct Dma', I think now that this is never filled in by the call to
HalAssignSlotResources even if the device will use DMA, right?
- If I set for the call to HalGetAdapter in the device description 'Master' to
TRUE and 'InterfaceType' to PCIBus, the part 'DmaChannel' is not needed (set to
0?), right?
- What about the members DmaWidth, DmaSpeed and MaximumLength?

Thanks

Christoph


0 new messages