[Etherboot-developers] Cleaned up 3c515 driver

[Timothy Legge <tlegge@ro...>]

Hi Ken

Here is the cleaned up 3c515.  I will have to spend a little time with 
cvs patch etc. before I do much more.

Tim

Re: [Etherboot-developers] Indent Style

[<ken_yap@us...>]

>Hi
>
>Is there an indent style used by most of the etherboot code?
>
>Tim

There is no official style but since a lot of the drivers are derived
from Linux, that style tends to be common. Personally I prefer this
block style:

	if ( ) {
		...
	} else {
		...
	}

as it uses up fewer lines so you get more context on the screen. But as
long as your style is not idiosyncratic and you are consistent, speaking
for myself, I don't care. A confusing indentation can be fixed with
indent, but a confusing algorithm is harder to fix.

[Etherboot-developers] Indent Style

[Timothy Legge <tlegge@ro...>]

Hi

Is there an indent style used by most of the etherboot code?

Tim

Re: [Etherboot-developers] NIC file and ROM images

[<ebiederman@ln...>]

ken_yap@... (Ken Yap) writes:

> >A.2  PnP Option ROM Header
> Offset    Size     Value    Description
> >-----------------------------------------------------
> >00h       BYTE     55h       Signature byte 1.
> >01h       BYTE     AAh       Signature byte 2.
> >02h       BYTE     Varies    Option ROM length in 512-byte blocks.
> >03h       4 BYTES  Varies    Initialization entry point.
> >07h       17 BYTES Varies    Reserved.
> >18h       WORD     Varies    Offset to PCI data structure.
> >1Ah       WORD     Varies    Offset to expansion header structure.
> >
> >So my question is, can we have something like:
> >
> >PnP option ROM Header size 64K
> >512 bytes later, PnP option ROM Header size 64K - 512 bytes
> >512 bytes later, PnP option ROM header size 64K - 1024 bytes.
> >etc.
> 
> Interesting. How about this variation:
> 
> PnP option ROM Header size 512 bytes, jump to start
> PnP option ROM Header size 512 bytes, jump to start
> ...
> PnP option ROM Header size 512+x bytes, jump to start
> start of code (x bytes)
> 
> Problem is the BIOS might be entitled to map in only as much of the ROM
> as the header declares.

I believe it is, the PCI spec says specifically that the ROM must first
be copied into RAM.  And it is legal for us to shorten our ROM image size
after the initialization vector is called.

We read from the ROM ourselves which solves that the too little
information problem.  Another little tidbit is that the PCI data
structure has at offset 15 an indicator byte.  Bit 7 of that byte is
set to 1 if this is the last image, and it is set to 0 if there are
more images.

Eric

Re: [Etherboot-developers] NIC file and ROM images

[<ebiederman@ln...>]

"Robb Main [Genedyne]" <genedyne@...> writes:

>  <ebiederman@...> writes:
> 
> > What is clear is that you can have multiple rom images, with their
> > own rom header on a 512 byte boundary.  What I don't know yet is
> > if the rom scan algorithm supports those images overlapping.
> >
> > If they can overlap it is probably worth doing, without the ability
> > to overlap we can just make certain etherboot rom images are in
> > multiples of 512 bytes and concat rom images together if there are
> > big enough roms.
> 
> Since the early days of the XT, standard BIOSes scan on 2K boundaries.  This
> is somewhat odd, considering the blocksize given at offset 0x2 is the number
> of 512 byte blocks.  The scan increment has persisted even in modern AT
> BIOSes - one more bit of cruft from the dark ages.  For this reason, I don't
> think you can expect "overlapping" ROMs or concatenated ROMs on a 512-byte
> boundary to operate as expected. At least not if your target is a "portable"
> solution.

Possibly.  

The target is something that works with Phoenix, AMI, and Award for PCI
roms.  So that we can do better for the common case, we can fallback
to what we have today for the other cases.
 
> I believe the "standard" algorithm for performing the scan is something like
> this:
> 
> pThisLocn = 0xC000
> do {
>     if ( *(pThisLocn) == 0xAA55) {
>         // 0x55, 0xAA signature (byte-swapped) matches
>         if (checksumROMat(pThisLocn)) {
>             invokeROMat(pThisLocn)
>             pThisLocn += (*(pThisLocn+2) * 512)
>             if (pThisLocn & 0x07FF) {
>                 // ROM does not end at 2K boundary, so round it up...
>                 pThisLocn += 0x07FF
>                 pThisLocn &= 0xF800
>             }
>         } else {
>             // ROM failed checksum, so assume it only _looks_ like a ROM)
>             pThisLocn += 0x0800    // 2K increment
>         }
>     } else {
>        pThisLocn += 0x0800    // 2K increment
>     }
> } while (pThisLocn >= 0xC000) // relies on 16-bit rollover in pointer for
> termination

But none of this factors in the changes made when they added the PCI
speec.

> 
> Now one thing you _could_ do is make a "super-ROM", that contains multiple
> ROM images, but only one "standard" ROM header (0x55, 0xAA, etc).  The init
> code of the super-ROM, would scan internally for "super-ROM" headers (which
> could be anything - I like "BOB'S YER UNCLE!", although it is a bit
> excessive and wasteful).  This would be consistently portable (x86 only, of
> course), except....

That it doesn't have the PCI ID of all of the PCI chips.

> Another bit of IBM BIOS cruft was that ROMs greater than 32KB may be
> ignored.
> This issue is even less consistent. Some modern BIOSes still adhere to this
> "standard", but others will accept ROMs up to 64KB.
> Even if the BIOS ignores the ROM, it may
> - scan the next 2K boundary (i.e, within the ROM); or
> - scan the next boundary (i.e., next byte after the ROM)
> Anyway - the super-ROM concept could still work, as long as only the first
> 32KB was considered part of the standard ROM.  The code could still be
> larger, but the init code would have to implement it's own checksum for the
> entire "super-ROM" contents (or checksum each individual "super-ROM" module
> prior to invocation.
> 
> I hope there is something helpful in all the blather above, and keep up the
> great work.

Thanks there is some, I hadn't picked up on the 2K increment before.  Basically
we need to do some expirmentation and see what BIOS's actually accept.

Eric

Re: [Etherboot-developers] NIC file and ROM images

[<ken_yap@us...>]

>A.2  PnP Option ROM Header
Offset    Size     Value    Description
>-----------------------------------------------------
>00h       BYTE     55h       Signature byte 1.
>01h       BYTE     AAh       Signature byte 2.
>02h       BYTE     Varies    Option ROM length in 512-byte blocks.
>03h       4 BYTES  Varies    Initialization entry point.
>07h       17 BYTES Varies    Reserved.
>18h       WORD     Varies    Offset to PCI data structure.
>1Ah       WORD     Varies    Offset to expansion header structure.
>
>So my question is, can we have something like:
>
>PnP option ROM Header size 64K
>512 bytes later, PnP option ROM Header size 64K - 512 bytes
>512 bytes later, PnP option ROM header size 64K - 1024 bytes.
>etc.

Interesting. How about this variation:

PnP option ROM Header size 512 bytes, jump to start
PnP option ROM Header size 512 bytes, jump to start
...
PnP option ROM Header size 512+x bytes, jump to start
start of code (x bytes)

Problem is the BIOS might be entitled to map in only as much of the ROM
as the header declares.

Re: [Etherboot-developers] NIC file and ROM images

[<ebiederman@ln...>]

ken_yap@... (Ken Yap) writes:

> >What if you (we) could build a bootrom that knows about ALL
> >pci network chipsets.
> 
> You already can, in theory, just do what Michael Brown did with multi
> driver binaries.
> 
> >It would start with a whole bunch of 512 byte PCI headers.
> >Followed by the main() and other common code,  Then, the 
> >unique routines that each card needs. I don't know how big
> >that is, but it seems pretty small, per chipset.
> 
> Unfortunately it isn't, if you'd written a driver before you'd know
> different.  Each driver can have pretty complicated code and use large
> buffers. See tulip.c for an extreme example. To share the buffers would
> require some kind of dynamic memory allocation. And even then there's
> the memory squeeze, see below.

Although all of the buffers should be in the BSS and not matter,
binary size wise.
 
> >I use 29ee512 chips for the Linksys and 3Com cards, 
> >I'll bet we could fit support for a lot of chipsets into 64k.
> 
> The problem is not the ROM size, but the limited execution area with
> which Etherboot has to work (48kB from 0x94000). Hence the interest in a
> relocatable Etherboot binary which could copy itself to the top of
> memory, which should leave enough room at the bottom for the loaded code
> in all except very memory deficient machines. But that's a promising
> direction to work towards.

And the challenge with a relocateable binary is that we would need
to split etherboot into 2 sections.  The 16bit code section, which
must be under 1M, and the rest.  And we can probably place the
code that must be under 1M between 0xC0000 - 0xE0000, basically
just leave it there as our initialization finishes.

I have the self relocation working just fine with memtest86, reducing
it's memory footprint from 128KB to 56KB because it no longer has to
have 2 copies of itself.  I have a few more hurdles to over come
before I release patches against memtest86 but I have the self
relocating working solidly.

Eric

Re: [Etherboot-developers] NIC file and ROM images

[<ken_yap@us...>]

>What if you (we) could build a bootrom that knows about ALL
>pci network chipsets.

You already can, in theory, just do what Michael Brown did with multi
driver binaries.

>It would start with a whole bunch of 512 byte PCI headers.
>Followed by the main() and other common code,  Then, the 
>unique routines that each card needs. I don't know how big
>that is, but it seems pretty small, per chipset.

Unfortunately it isn't, if you'd written a driver before you'd know
different.  Each driver can have pretty complicated code and use large
buffers. See tulip.c for an extreme example. To share the buffers would
require some kind of dynamic memory allocation. And even then there's
the memory squeeze, see below.

>I use 29ee512 chips for the Linksys and 3Com cards, 
>I'll bet we could fit support for a lot of chipsets into 64k.

The problem is not the ROM size, but the limited execution area with
which Etherboot has to work (48kB from 0x94000). Hence the interest in a
relocatable Etherboot binary which could copy itself to the top of
memory, which should leave enough room at the bottom for the loaded code
in all except very memory deficient machines. But that's a promising
direction to work towards.

Re: [Etherboot-developers] NIC file and ROM images

[<ebiederman@ln...>]

<jam@...> writes:

> Interesting thread about the multiple PCI headers in a
> bootrom.
> 
> I realize this would take alot of reworking how an
> Etherboot bootrom image is put together, but I'm thinking
> that much of the code in bootrom is common code that
> is used in all bootroms.  That is, the tftp, dhcp/bootp,
> main, and probably more.
> 
> Concatenating the bootrom images would just duplicate the
> same code over and over again.
> 
> I don't know what the ratio of unique code to common code
> is, but it seems like it is far more common code than unique.
> 
> What if you (we) could build a bootrom that knows about ALL
> pci network chipsets.
> 
> It would start with a whole bunch of 512 byte PCI headers.
> Followed by the main() and other common code,  Then, the 
> unique routines that each card needs. I don't know how big
> that is, but it seems pretty small, per chipset.
> 
> I use 29ee512 chips for the Linksys and 3Com cards, 
> I'll bet we could fit support for a lot of chipsets into 64k.
> 
> Well, it's just a random thought.

You caught the basic idea.  Especially when you notice Etherboot
only has 2 3com drivers, so all of the code is common.  The
open question is if it is technically feasible to have multiple
ROM images.

While writing this it occors to me that for a PCI expansion ROM
there is one other possibility.  If it isn't technically feasible
to have overlapping ROM images, it should be feasible to have multiple
images, with just enough code to remap the PCI rom and read out the
real ROM image.  Getting the BIOS to do all of the mapping and
selecting for us is probably a better way to go, but if a small enough
mini loader can be written I am certain we can make it work.

I'm hoping I can get someone else to volunteer for some of this.  But
if not I might be able to find a little bit of time to check this out.

Eric

Re: [Etherboot-developers] NIC file and ROM images

[Robb Main [Genedyne] <genedyne@ac...>]

 <ebiederman@...> writes:

> What is clear is that you can have multiple rom images, with their
> own rom header on a 512 byte boundary.  What I don't know yet is
> if the rom scan algorithm supports those images overlapping.
>
> If they can overlap it is probably worth doing, without the ability
> to overlap we can just make certain etherboot rom images are in
> multiples of 512 bytes and concat rom images together if there are
> big enough roms.

Since the early days of the XT, standard BIOSes scan on 2K boundaries.  This
is somewhat odd, considering the blocksize given at offset 0x2 is the number
of 512 byte blocks.  The scan increment has persisted even in modern AT
BIOSes - one more bit of cruft from the dark ages.  For this reason, I don't
think you can expect "overlapping" ROMs or concatenated ROMs on a 512-byte
boundary to operate as expected. At least not if your target is a "portable"
solution.

I believe the "standard" algorithm for performing the scan is something like
this:

pThisLocn = 0xC000
do {
    if ( *(pThisLocn) == 0xAA55) {
        // 0x55, 0xAA signature (byte-swapped) matches
        if (checksumROMat(pThisLocn)) {
            invokeROMat(pThisLocn)
            pThisLocn += (*(pThisLocn+2) * 512)
            if (pThisLocn & 0x07FF) {
                // ROM does not end at 2K boundary, so round it up...
                pThisLocn += 0x07FF
                pThisLocn &= 0xF800
            }
        } else {
            // ROM failed checksum, so assume it only _looks_ like a ROM)
            pThisLocn += 0x0800    // 2K increment
        }
    } else {
       pThisLocn += 0x0800    // 2K increment
    }
} while (pThisLocn >= 0xC000) // relies on 16-bit rollover in pointer for
termination

Now one thing you _could_ do is make a "super-ROM", that contains multiple
ROM images, but only one "standard" ROM header (0x55, 0xAA, etc).  The init
code of the super-ROM, would scan internally for "super-ROM" headers (which
could be anything - I like "BOB'S YER UNCLE!", although it is a bit
excessive and wasteful).  This would be consistently portable (x86 only, of
course), except....
Another bit of IBM BIOS cruft was that ROMs greater than 32KB may be
ignored.
This issue is even less consistent. Some modern BIOSes still adhere to this
"standard", but others will accept ROMs up to 64KB.
Even if the BIOS ignores the ROM, it may
- scan the next 2K boundary (i.e, within the ROM); or
- scan the next boundary (i.e., next byte after the ROM)
Anyway - the super-ROM concept could still work, as long as only the first
32KB was considered part of the standard ROM.  The code could still be
larger, but the init code would have to implement it's own checksum for the
entire "super-ROM" contents (or checksum each individual "super-ROM" module
prior to invocation.

I hope there is something helpful in all the blather above, and keep up the
great work.

Cheers,
Robb Main.

Re: [Etherboot-developers] NIC file and ROM images

[<ebiederman@ln...>]

ken_yap@... (Ken Yap) writes:

> Perl doesn't cover all applications, but it's perfectly adequate in many
> places where you't think only C will do the job, e.g. mknbi which does
> binary manipulations and a streaming video server. It may be a long time
> before we see an Etherboot in Perl though.

I guess my point is mknbi is just at the edge.  And I crossed that
edge with my version and wasn't at all happy about it.  Which is why
I advised caution.
 
> >What is clear is that you can have multiple rom images, with their
> >own rom header on a 512 byte boundary.  What I don't know yet is
> >if the rom scan algorithm supports those images overlapping.
> 
> I don't think the header has any "data offset" fields, the body just
> follows the header.

The structure is:

A.2  PnP Option ROM Header
Offset    Size     Value    Description
-----------------------------------------------------
00h       BYTE     55h       Signature byte 1.
01h       BYTE     AAh       Signature byte 2.
02h       BYTE     Varies    Option ROM length in 512-byte blocks.
03h       4 BYTES  Varies    Initialization entry point.
07h       17 BYTES Varies    Reserved.
18h       WORD     Varies    Offset to PCI data structure.
1Ah       WORD     Varies    Offset to expansion header structure.

So my question is, can we have something like:

PnP option ROM Header size 64K
512 bytes later, PnP option ROM Header size 64K - 512 bytes
512 bytes later, PnP option ROM header size 64K - 1024 bytes.
etc.

And just adjust the pointers to the code approrpiately.

> >If they can overlap it is probably worth doing, without the ability
> >to overlap we can just make certain etherboot rom images are in
> >multiples of 512 bytes and concat rom images together if there are
> >big enough roms.
> 
> That's easy, just concatenate the ROM images. At the moment they aren't
> as small as they could be because they are padded out to the next power
> of 2, but an additional option could allow them to be padded to the next
> block only.

Right concatenation will work, but you probably can't fit very
many of them into the same rom.  Which generally defeats the purpose.

If I have a chance I will see if I can get overlapping ROMs to work,
that way we can list all of the the supported PCI for one ROM image.

Eric

Re: [Etherboot-developers] NIC file and ROM images

[<jam@McQuil.Com>]

Interesting thread about the multiple PCI headers in a
bootrom.

I realize this would take alot of reworking how an
Etherboot bootrom image is put together, but I'm thinking
that much of the code in bootrom is common code that
is used in all bootroms.  That is, the tftp, dhcp/bootp,
main, and probably more.

Concatenating the bootrom images would just duplicate the
same code over and over again.

I don't know what the ratio of unique code to common code
is, but it seems like it is far more common code than unique.

What if you (we) could build a bootrom that knows about ALL
pci network chipsets.

It would start with a whole bunch of 512 byte PCI headers.
Followed by the main() and other common code,  Then, the 
unique routines that each card needs. I don't know how big
that is, but it seems pretty small, per chipset.

I use 29ee512 chips for the Linksys and 3Com cards, 
I'll bet we could fit support for a lot of chipsets into 64k.

Well, it's just a random thought.

Thanks,

Jim McQuillan
jam@...


On Thu, 18 Apr 2002, Ken Yap wrote:

> >That wouldn't have worked because I wasn't using that checksum
> >algorightm.  Ever since playing with BASIC I'm alergic to using
> >programming languages where you must use the builtins to get
> >performance.
> 
> Well then the answer would have been one of the following:
> 
> Find a CPAN module that does what you want. E.g. there's a MD5 module.
> Write an extension in C.
> Don't use Perl
> 
> Perl doesn't cover all applications, but it's perfectly adequate in many
> places where you't think only C will do the job, e.g. mknbi which does
> binary manipulations and a streaming video server. It may be a long time
> before we see an Etherboot in Perl though.
> 
> >What is clear is that you can have multiple rom images, with their
> >own rom header on a 512 byte boundary.  What I don't know yet is
> >if the rom scan algorithm supports those images overlapping.
> 
> I don't think the header has any "data offset" fields, the body just
> follows the header.
> 
> >If they can overlap it is probably worth doing, without the ability
> >to overlap we can just make certain etherboot rom images are in
> >multiples of 512 bytes and concat rom images together if there are
> >big enough roms.
> 
> That's easy, just concatenate the ROM images. At the moment they aren't
> as small as they could be because they are padded out to the next power
> of 2, but an additional option could allow them to be padded to the next
> block only.
> 
> _______________________________________________
> Etherboot-developers mailing list
> Etherboot-developers@...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers
> 

--