Re: [Etherboot-developers] EEPRO100.C PCI activiation
Brought to you by:
marty_connor,
stefanhajnoczi
|
From: Marty C. <md...@th...> - 2001-10-08 17:45:33
|
On 10/8/2001 11:34 AM Christoph Plattner chr...@al...
wrote:
>An interesting thing: We are working on a prototype version
>of a new built hardware using the i82559ER. On prototype A
>the NIC works, on protoype B, the problem occurs. So there
>is a depenceny on BIOS and hardware mapping of addresses, etc...
I think the PCI detection code should not be driver specific, except in
truly bizarre cases. I need to go through all the PCI drivers and see
which ones are doing:
/* from tulip driver */
if (io_addrs == 0 || *io_addrs == 0)
return 0;
------------
and which ones are doing stuff like this:
/* rtl8139 driver */
if (probeaddrs == 0 || probeaddrs[0] == 0) {
printf("\nERROR: no probeaddrs given, using
pci_device\n");
for (p = pci; p->vendor; p++) {
if ( ( (p->vendor == PCI_VENDOR_ID_REALTEK)
&& (p->dev_id == PCI_DEVICE_ID_REALTEK_8139) )
|| ( (p->vendor == PCI_VENDOR_ID_SMC_1211)
&& (p->dev_id == PCI_DEVICE_ID_SMC_1211) ) ) {
probeaddrs[0] = p->ioaddr;
printf("rtl8139: probing %hX (membase
%hX)\n",
p->ioaddr, p->membase);
}
}
return 0;
}
In the RTL case, I think we should do this in the core. If the correct
vendor IDs aren't in config.c, then we should add them there so the
driver won't have to know do stuff like this.
---------------
Or how about this in the eepro100 driver:
Below, the problem isn't that the card isn't found, it's that the card
isn't set to be bus mastering, and then the PCI latency is sanity
checked. I think Eric suggested adding a core routine that can be called
that does this consistently for any cards that need it. I suspect that
it was a hack for someone's broken BIOS, and they would have the same
trouble if they had other PCI cards as well.
/* eepro100 */
if (probeaddrs == 0 || probeaddrs[0] == 0)
return 0;
ioaddr = probeaddrs[0] & ~3; /* Mask the bit that says "this is
an io addr\
" */
/* From Matt Hortman <mbh...@ac...> */
if (p->dev_id == PCI_DEVICE_ID_INTEL_82557 ) {
/*
* check to make sure the bios properly set the
* 82557 (or 82558) to be bus master
*
* from eepro100.c in 2.2.9 kernel source
*/
pcibios_read_config_word(p->bus, p->devfn, PCI_COMMAND,
&pci_comma\
nd);
new_command = pci_command |
PCI_COMMAND_MASTER|PCI_COMMAND_IO;
if (pci_command != new_command) {
printf("\nThe PCI BIOS has not enabled this
device!\nUpdat\
ing PCI command %hX->%hX. pci_bus %hhX pci_device_fn %hhX\n",
pci_command, new_command, p->bus,
p->devfn);
pcibios_write_config_word(p->bus, p->devfn,
PCI_COMMAND, n\
ew_command);
}
pcibios_read_config_byte(p->bus, p->devfn,
PCI_LATENCY_TIMER, &pci\
_latency);
if (pci_latency < 32) {
printf("\nPCI latency timer (CFLT) is
unreasonably low at \
%d. Setting to 32 clocks.\n", pci_latency);
pcibios_write_config_byte(p->bus, p->devfn,
PCI_LATENCY_TI\
MER, 32);
}
}
------------
and how about this one from via-rhine.c:
Here it first checks for bus master (like in the eepro100 driver), and
then for and unreasonably small PCI latency value. Sounds like a good
candidate for a couple of core PCI routines.
if (!pci->ioaddr)
return NULL;
nic = rhine_probe1 (nic, pci->ioaddr, 0, -1);
if (nic)
{
/* Get and check the bus-master and latency values. */
pcibios_read_config_word (pci->bus, pci->devfn, PCI_COMMAND,
&pci_command)\
;
if (!(pci_command & PCI_COMMAND_MASTER))
{
printf (" PCI Master Bit has not been set! Setting...\n");
pci_command |= PCI_COMMAND_MASTER;
pcibios_write_config_word (pci->bus, pci->devfn, PCI_COMMAND,
pci_command);
}
pcibios_read_config_byte (pci->bus, pci->devfn, PCI_LATENCY_TIMER,
&pci_latency);
if (pci_latency < 10)
{
printf (" PCI latency timer (CFLT) is unreasonably low "
"at %d. Setting to 64 clocks.\n", pci_latency);
pcibios_write_config_byte (pci->bus, pci->devfn,
PCI_LATENCY_TIMER, 64\
);
}
else if (rhine_debug > 1)
printf (" PCI latency timer (CFLT) is %#hX.\n", pci_latency);
}
--------------
So what do other think? Should we consider creating some core routines
to give a little more consistency and simplicity to the driver probe
code? Or since it's a small amount of code, and drivers are
comparmentalized, just let it go. If you have an opinion, please let us
hear it.
Marty
---
Try: http://rom-o-matic.net/ to make Etherboot images instantly.
Name: Marty Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827; Cambridge, MA 02139; USA
Voice: (617) 491-6935, Fax: (617) 491-7046
Email: md...@th...
Web: http://www.thinguin.org/
|