Re: [Etherboot-developers] NIC file and ROM images
Brought to you by:
marty_connor,
stefanhajnoczi
|
From: <ebi...@ln...> - 2002-04-17 19:50:09
|
ke...@us... (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
|