>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.

>My sourceforge id is timlegge. It is activated.
Ok, I'll sign you in.
>As for the all rights reserved, I must have copied that from another driver
>;-). I can submit a patch to fix things.
Maybe cleaning up the code with indent wouldn't hurt, there is quite a
bit of old stuff lying around.

Hi Ken
My sourceforge id is timlegge. It is activated.
I contacted Donald today and he is fine with adding:
This driver includes code that is copyright 1997-2000 by Donald Becker.
And then the usual GPL notice and possibly a mention of how to contact him.
As for the all rights reserved, I must have copied that from another driver
;-). I can submit a patch to fix things.
Tim
> -----Original Message-----
> From: etherboot-developers-admin@...
> [mailto:etherboot-developers-admin@...]On Behalf Of
> Ken Yap
> Sent: Wednesday, April 17, 2002 1:12 PM
> To: Etherboot developers list
> Subject: Re: [Etherboot-developers] ISA 3C515 Driver
>
>
> >This driver is a hack. It seems to work, but I am not entirely sure how
> >I managed that. However, I believe I would be correct in stating that
> >it is the best available 3c515 etherboot driver. (Unless someone has
> >working driver for the 3c515 that I don't know of) ;-)
>
> And it probably is too. Thanks, added to source tree.
>
> BTW, you're asserted All Rights Reserved¸ is that compatible with the
> sources you've used, e.g. Donald Becker's driver, which is GPL?
>
> >Ken, I have registered with SourceForge, is there anything else I need
> >to do.
>
> Yes, tell me your id when it's activated. I can't find you in the people
> list so either you're registered under another name or the db is not up
> to date.
>
> _______________________________________________
> Etherboot-developers mailing list
> Etherboot-developers@...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers
>

ken_yap@... (Ken Yap) writes:
> >I'd be careful about using Perl for this kind of work. I'm rather
> >turned off on Perl since I added code to compute a checksum and
> >Perl 5 seconds to checksum a 1Meg binary data. That combined with the
> >challenge of dealing with binary data in Perl causes me to suggest
> >that is is proabably a more appropriate language for this task.
>
> Relax, I know Perl like an old friend. I bet you tried to sum each byte
> with a loop containing a substr. Perl has a built-in for doing
> checksums, see unpack in perlfunc(1). Here's a quickie to verify that
> the a ROM image checksums to 0.
I did use substrings and that might have been the issue.
>
> #!/usr/bin/perl
> $/ = 0777;
> $sum = unpack("%8C*",<>);
> print "$sum\n";
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.
> >> The NIC file could also generate an include for config.c, so only one
> >> place needs to be changed to support another derived image.
> >
> >That might be a good idea. But it falls down on the multiple drives
> >in one NIC side. I would be in favor of all of the PCI ID moving into
> >the drivers so drivers can be independent.
>
> But you haven't found out yet if an image can actually contain multiple
> PCI headers and do the right thing.
I have now.
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.
Eric

On 4/17/2002 11:39 AM Timothy Legge tlegge@... wrote:
>I have attached the driver for the 3c515 card.
>...
>This driver is a hack. It seems to work, but I am not entirely sure how
>I managed that. However, I believe I would be correct in stating that
>it is the best available 3c515 etherboot driver. (Unless someone has
>working driver for the 3c515 that I don't know of) ;-)
You did a fine job. Many people who you will never meet will appreciate
your work.
Driver writing is a learning experience, like so many things in life.
What you figured out from writing this driver will help you on your next
one.
Many thanks for your good work.
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: mdc@...
Web: http://www.thinguin.org/

>This driver is a hack. It seems to work, but I am not entirely sure how
>I managed that. However, I believe I would be correct in stating that
>it is the best available 3c515 etherboot driver. (Unless someone has
>working driver for the 3c515 that I don't know of) ;-)
And it probably is too. Thanks, added to source tree.
BTW, you're asserted All Rights Reserved¸ is that compatible with the
sources you've used, e.g. Donald Becker's driver, which is GPL?
>Ken, I have registered with SourceForge, is there anything else I need
>to do.
Yes, tell me your id when it's activated. I can't find you in the people
list so either you're registered under another name or the db is not up
to date.

Hi
I have attached the driver for the 3c515 card.
As far as I know, the driver only works with a PC with BIOS support for
PNP. I will test that on a 486 in the near future. If it does not work
on non PNP enabled BIOSes, I would welcome input on how to add the
required features from the ISAPNP software.
There are a whole lot of defines that are probably unneeded. I left
them in in the initial release just in case the need to be used later to
support other boards. (OK, I was too lazy and excited to bother taking
them out).
This driver is a hack. It seems to work, but I am not entirely sure how
I managed that. However, I believe I would be correct in stating that
it is the best available 3c515 etherboot driver. (Unless someone has
working driver for the 3c515 that I don't know of) ;-)
Ken, I have registered with SourceForge, is there anything else I need
to do.
Regarrds
Tim Legge
Moncton, NB
Canada

>Well with a lot of reading, (including a tutorial on Bitwise operations)
>and with the help of a whole lot of etherboot drivers, I have finally
>created a working driver for the 3c515.
Well done! Good on ya mate.
>Actually, it came as quite a surprise. I left the room while waiting
>for yet another reboot and when I returned, the ltsp kernel was booting
>on screen.
I wish my software could write itself like that. :-)
>Also, since I draw heavily on Donald Becker's linux driver as well as
>some of the other 3Com etherboot drivers I assume that I should detail
>that at the beginning of the driver. Is that correct?
Probably a good idea to give credit where it's due.
If it's small (<40kB) you could mail it to the Etherboot developers
list, or put it on your web/ftp server and post the URL, or if you wish
to be an Etherboot developer, register at Sourceforge, then tell me and
I'll add you to the developer list, then you can check it into CVS or
post in the patch area.
Again, nice job.