Re: [Etherboot-developers] changes checked into CVS

[<ebi...@ln...>]

ke...@us... (Ken Yap) writes:

> >In any event these are the macro the linux kernel uses to deal with
> >these numbers internal.  The isa-pnp spec has more information.
> >
> >#define ISAPNP_VENDOR(a,b,c)	(((((a)-'A'+1)&0x1f)<<2)|\
> >				((((b)-'A'+1)&0x18)>>3)|((((b)-'A'+1)&7)<<13)|
> >\
> >				((((c)-'A'+1)&0x1f)<<8))
> >#define ISAPNP_DEVICE(x)	((((x)&0xf000)>>8)|\
> >				 (((x)&0x0f00)>>8)|\
> >				 (((x)&0x00f0)<<8)|\
> >				 (((x)&0x000f)<<8))
> >
> >The endian issues with the EISA part number drive me crazy.  I think
> >the data is normally stored big endian.  But I am confused.  For
> >purposes of synching with modules.isapnpmap from the linux kernel=20
> >these values produced by the macros are the values we need.=20=20
> >
> >Using these in etherboot we should be able to have readable ISA part
> >numbers as well as fitting everything snuggly into 32 bits.
> >
> >The linux kernel 3c509.c driver is a good one to work against as it
> >actually implements the discovery via the isapnp id's.
> >
> >If we are going to fix the interface to the id's in 5.0.7 we need to
> >be certain we get this correct.
> 
> Ok, an interesting issue, the Linux 3c509 driver actually declares
> several vendor IDs, depending on the model, including the generic PNP
> for compatibles. Conceivably we could distinguish between the models in
> Etherboot as we know the configuration registers, though that's not very
> useful information to the sysadmin as one Linux driver will handle them
> all. A similar situation applies to the ne.c driver. So shall we just go
> for the generic ISAPNP_VENDOR('P','N','P'), with the exception of the
> 3c515 which uses TCM? In which case the vendor_id field is effectively a
> constant except for the 515. A pity but there is no ambiguity with the
> device id anyway.

As long as we are basically correct the system works.  If someone
finds it useful and they care about distinguishing between the fine
variants they can work out the details themselves.  I just want to
make certain that the id's we are passing are valid, and actually map
to the cards that we have.

The PNP vendor comes from retro fitting cards that were produced
before the isapnp spec was written.  Newer cards should have something
of their own.
 
> Also only a few Linux drivers actually declare this information but the
> table you supplied in a previous mail has most of the ones we care
> about.

Again this is one of those areas where if enough people care the
drivers will be updated.  Especially as the isapnp detection is much
more reliable than random port probes.

At this point I believe we have enough information to do a reasonable
job for all of our isa cards.  Getting isa working at all was going
the extra mile for me.  Now that the foundation is laid if enough
people on old low end machines care we can do some nice improvements
to the drivers.  But until then...

O.k. now back to dealing with the BIOS issues I get when I have 4GB of
ram plugged into a PC, and figuring out how to auto-detect pci-x or
pci and at which bus speed 33, 66, 100 or 133Mhz I should run the card
at :)  Except superio chips ISA isn't even a real case for me. 

Eric