etherboot-developers

[Etherboot-developers] changes checked into CVS

[<ke...@us...>]

I have checked into CVS:

For 5.0.7 and 5.1.2 candidates:

Changes to NIC identification scheme from variable length string to
fixed binary structure. Added ISA IDs to drivers.

For 5.0.7 candidate:

Some portability and code cleanups backported from 5.1.2 candidate.

Please sync your working copy with cvs update.

Re: [Etherboot-developers] changes checked into CVS

[Michael B. <mb...@fe...>]

On Tue, 2 Jul 2002 ke...@us... wrote:
> I have checked into CVS:
> For 5.0.7 and 5.1.2 candidates:
> Changes to NIC identification scheme from variable length string to
> fixed binary structure. Added ISA IDs to drivers.
> Please sync your working copy with cvs update.

A couple of issues:

1. the "nic_id" struct now contains the length of the
   etherboot-encapsulated-options packet, which does not belong in this
   struct since it is unrelated to the NIC id.

2. These changes break backwards compatibility for the sake of 8 bytes
   saved in the DHCP request packet (which is not really size-critical).
   I know that the Mandrake distribution has already included related code
   that depends the old-format NIC ID scheme present in RC1.

I really think that we should revert to the old plain-text method, where
the IDs were strings such as "PCI:1186:1300" rather than a binary sequence
0x01,0x86,0x11,0x00,0x13.  Aside from anything else, it makes a real mess
of dhcpd.conf files to start manipulating binary structures like this. :-(

Michael Brown
http://www.fensystems.co.uk
--
Fen Systems: Linux made easy for schools

Re: [Etherboot-developers] changes checked into CVS

[Michael B. <mb...@fe...>]

On Tue, 2 Jul 2002, Michael Brown wrote:
> > I have checked into CVS:
> > For 5.0.7 and 5.1.2 candidates:
> > Changes to NIC identification scheme from variable length string to
> > fixed binary structure. Added ISA IDs to drivers.
> > Please sync your working copy with cvs update.
> A couple of issues:
> 1. the "nic_id" struct now contains the length of the
>    etherboot-encapsulated-options packet, which does not belong in this
>    struct since it is unrelated to the NIC id.
> 2. These changes break backwards compatibility for the sake of 8 bytes
>    saved in the DHCP request packet (which is not really size-critical).
>    I know that the Mandrake distribution has already included related code
>    that depends the old-format NIC ID scheme present in RC1.
> I really think that we should revert to the old plain-text method, where
> the IDs were strings such as "PCI:1186:1300" rather than a binary sequence
> 0x01,0x86,0x11,0x00,0x13.  Aside from anything else, it makes a real mess
> of dhcpd.conf files to start manipulating binary structures like this. :-(

Forgot to mention: I've also burned about 200 copies of the RC1 code into
silicon for various customers, since I was happy that RC1 worked
sufficiently well for my needs.  It's going to cause me and them a lot of
hassle if I have to replace 200 EPROMs because of a change that broke
backwards compatibility between RC1 and final release.

Michael Brown
http://www.fensystems.co.uk
--
Fen Systems: Linux made easy for schools

Re: [Etherboot-developers] changes checked into CVS

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

ke...@us... writes:

> I have checked into CVS:
>=20
> For 5.0.7 and 5.1.2 candidates:
>=20
> Changes to NIC identification scheme from variable length string to
> fixed binary structure. Added ISA IDs to drivers.

O.k. Looking at this there is a bug in how the ISAPNP id's are
encoded.  You have been using the pci vendor id's instead of the=20
EISA/PNP vendor id's.


The 32-bit Vendor ID is an EISA Product Identifier (ID).  This ID consists =
of:
=B7	bits[15:0] -  three character compressed ASCII EISA ID.
	Compressed ASCII is defined as 5 bits per character, "00001" =3D "A" ... "=
11010" =3D "Z". This field is assigned to each manufacturer by the EISA adm=
inistrative agent.
=B7	bits[31:16] -  manufacturer specific product number and
        revision.  It is the responsibility of each vendor to select
        unique values for this field.=20


For the crystal lan the partnumber is CSC0007 (For the CSC8900 rev B)
Cyrus Logic has a good set of data sheets online for it.

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.

Eric