etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] Question on supporting nVidia .o driver

[Peter L. <P.L...@sy...>]

Sorry, everyone, I sort of started this. :)

> > The issue is that nVidia supply a .o file containing all the goodies; it
> >   is believed to be quite possible to fake up something using the kernel
> > network API to use this and make it believe it was a kernel driver.

Misunderstanding on Mr Green's part. My suggestion was that the
nvnetlib.o contains enough NIC API on to which we could glue an EB
driver API (as suggested already). It seems to me that the *driver* is
essentially open source, but that the minutiae of tweaking the NIC is
enclosed in nvnetlib.o - I've never done an Etherboot polling driver
before, but I've looked at enough NIC specs to guess that this is true,
and my original post to suggest to the xbox-linux guys that, if
possible, a

This would seem reasonable, as well - after all hardware vendors tend to
be obsessed only be hiding their hw interfaces; making life hard for the
world is usually just a side-effect.

And if we *do* hit any problems, we could just ask nVidia, no? At least
lets give them opportunity to be helpful before assuming that they
aren't. The LinuxBIOS experience is somethimes that asking hw vendors
for specs means that the *spec* may be NDA'd even though the resulting
source can be open.

> > The main question is, what's the prevailing opinion about using a .o in
> > this way GPL-wise.  It has been suggested that we'll be okay if we do
> > not distribute the .o but make our GPL project consist of everything
> > but.  (Because we are running on the xbox only, portability is not a
> > concern).

The GPL is only "enforced" at the point of *distribution* (from reading
http://emoglen.law.columbia.edu/publications/lu-12.html), but we are not
claiming nvnetlib.o is GPL'd. It's nVidia's copyright, which they
license as being OK for distribution in Linux related circumstances. The
question is more does *Etherboot* tolerate being linked with such code?

Actually, since EB can boot FreeDOS and maybe other things, I suppose
it's not exclusively Linux related. :)

> > In addition, has anyone made such a fake kernel API shell before?  Has
> > anyone looked at supporting nForce motherboards?

I repeat that this was NOT my suggestion, but I believe OSkit does this.

> 1. The nVidia .o file is 20kB in size - around 4-5 times the size of most
>    of the Etherboot drivers.  This might be enough to prevent it working
>    in 5.0.x (AFAICT, the memory-map changes in the 5.1.x branch will fix
>    this anyway).

I can image that much of the nvnet.o might be bloat from Etherboot's
POV, but as you say EB can hopefully cope.

> 2. Is it possible to use the .o file to create a polling driver?
>    Etherboot doesn't use interrupts.

Based on fairly cursory inspection, I'd guess yes. It may not be
elegant, though, and I suspect the only authoritative answer is likely
to be suck it and see.

Several dozen people will now prove me wrong...

> 3. As others have said, don't bother faking a kernel network API - just
>    take the skeleton Etherboot driver in skel.c and fill out the gaps
>    between that and the nVidia .o file.

:)

Re: Re[2]: [Etherboot-developers] Q: device naming....

[Ronald G M. <rmi...@la...>]

On Wednesday 21 August 2002 11:50, Eric W Biederman wrote:

> I didn't see the file system type in the naming systax (fat was required).
> I saw etherX but I didn't see anything beyond that.


I'll try to find a better example(s)

Although catching up on this thread it sounds like a file system driver is 
not of interest? Just checking.

ron

Re: Re[2]: [Etherboot-developers] Q: device naming....

[Eric W B. <ebi...@ln...>]

Ronald G Minnich <rmi...@la...> writes:

> On Wednesday 21 August 2002 10:14, Anselm Martin Hoffmeister wrote:
> >
> > A pity there's some thousand matches (about 104000 on google) for
> > "Plan 9". Give us a clue, please.
> 
> Sorry. This is a reasonable starting point. 
> 
> http://plan9.escet.urjc.es/magic/man2html/8/9load
> 
> Why I like the syntax:
> - good support for many device names/types
> - naming syntax that includes the file system type
> - network path names
> 
> pretty much anything I've found I want in a name string is in there. 

I didn't see the file system type in the naming systax (fat was required).
I saw etherX but I didn't see anything beyond that.

Eric

Re: [Etherboot-developers] Q: device naming....

[Eric W B. <ebi...@ln...>]

Anselm Martin Hoffmeister <an...@ho...> writes:

> > Tenatively I have made the url:
> > file:///floppy0
> > file:///disk0
> 
> > With a +- offset to find the start of the boot file.
> > Which is fine.
> 
> But that doesn't help in every case (e.g. Ms-doze formatted disc, some
> kind of fragmentation taking place). OK, that's exaggeration, nowadays
> you have to format floppies before using them anyway (storing them in
> a box beside my screen. Good idea I hope).

A little more information.  From the offset I do a scan 8K forwards
and 8K bacwards to find the start of the image.  So I don't have
to stomp partition tables and the like.  Plus ELF images can be sparse
so I can do the full lilo thing of memoryizing the disk layout if
necessary.

What I have been after so far is the simplest mechanism needed to boot
the system.  So I have been avoiding filesystem, and partition table
parsing code.  The current driver infrastructure could certainly
support a filesystem parser.

So far I have managed to handle every corner case I can think of
uniformly with just an ELF parser and not a filesystem parser.  Except
for making editing a little easier I have yet to see adding gain from
a filesystem parser, but I have seen a lot more complexity.  A
filesystem parser is certainly needed when you are offering selections
between different kernels, but that is about it.

My requirement is that any setup work on a disk with BSD disk labels,
EFI partition tables, DOS partition tables, no parition tables, or
a partition table scheme written after I flashed the rom chip.

My expectation in the long term is to load Linux or possibly Grub
from the disk to to handle all of the strange issues.

I'm willing to work with any system that works, but I will only code
what makes sense to me.

> Digging inside my 10-year-old "PC-intern 3.0" documentation I found
> out that every dos floppy has a fixed format (well, I knew that,
> but...) with a BIOS parameter block that allows the FAT to be shifted.
> It usually starts at block 1 (offset 0x200), but one can shift that
> while still keeping DOS compatibility. Imagine a disk layout like
> this:
> 
> 0x0000 (512 bytes) Bios Parameter Block*, Loader Code
>        *with FAT-shift for 15,5 kB set
> 0x0200 (15,5 kB) Rest of etherboot
> 0x4000 Begin of FAT, length as needed
> 0x.... Directory
> 
> which should be DOS/Win-compatible. You better not format it (killing the
> etherboot loader), but else it should work as usual floppy, allowing
> you to copy the kernel to this disk from any operating system. Or (if
> you cannot burn a ROM) lock a write-protected disc inside drive A
> which can contain some stuff - better than provoking some Windumb
> choke (if dual-OS or so, as in my "test lab") about that unformatted
> disk in drive A.

Interesting.  I so rarely load etherboot from a floppy I hadn't
thought of that as a normal case at all.

> In case someone writes FAT12 support, this disk could bear a kernel or
> a menu image or so, but mountable and *easily* configurable from
> linux.
> 
> > I am wondering if that naming convention is find of if I should
> > switch to something like:
> 
> > file:///fd0
> > file:///hd0
> 
> You could think about three factors
> - What happens with the second/third disc? -> file:///disk1 ...
> - How to access partitions (hard disk only)? -> file:///disk0/1 ...
> - How to access files there? -> file:///floppy0/vmlinuz,
> file:///disk0/1/vmlinuz -> that's not intuitive.
> I'd prefer
> file:///fd <number> [/<filename>]
> file:///hd <letter> [<number>[/filename[+offset]]] (no number->mbr)
> file:///hd <letter> [<number>][{+|-}offset]

That might be good. But I have a hard time with a 26 drive limit.
Plus I'm not terribly found of fat filesystems.  Having a filesystem
with important information that isn't journaled looks like a problem
waiting to happen.

> Meanwhile, the + offset is ok, but what is - for?

Backwards from the end of the disk.  The most useful feature is
that disk0-0 will scan backwards first.  Logically I have the disk
wrap around so you can have an ELF header at the end of the disk,
and the rest of the image wherever you want on the disk.

> > And on the same subject I am wondering if the old disk code
> > that reads from the pcbios has enough merits to even be kept.
> 
> Could be... If there is some SCSI hardware snapping into the BIOS, it
> could allow SCSI disk access as disk 0x81 or so. Your ide code
> probably doesn't handle that up to now, does it?

Not yet so it is probably worth preserving in some form.  But it will
probably take a complete rewrite, because the current code is not
at all general purpose.

> file:///bd<number> [<number>] while <number> accesses the Bios
> device 0x80+<number> could do (for BiosDisk-access). Floppy support
> through the Bios can become obsolete. If sometime filesystem support
> be added, an uniform interface to disk access could be reasonable. Not
> neccessary for floppy/disk as few people will have
> fat12-disk-partitions, but who knows if for scsi(via Bios)/ide?

Eric

Re: [Etherboot-developers] upx compressor/decompressor...

[Markus G. <ma...@gu...>]

Eric W Biederman wrote:
> In it's final form the overhead for the nrv2b decompressor is just
> 180 bytes and should handle any size of file.  The 32bit infrastructure
> is now an advantage instead of a liability size wise.

Sweet! That's very impressive. Now, if only there was some documentation on 
these algorithms. I've been browsing the project pages for UPX, but they are 
extremely sparse on documentation.


Markus

-- 
Markus Gutschke
3637 Fillmore Street #106
San Francisco, CA 94123-1600
+1-415-567-8449
ma...@gu...

[Etherboot-developers] upx compressor/decompressor...

[Eric W B. <ebi...@ln...>]

Yeah!  I have just incoporated the nrv2b algorthim from
upx into etherboot.  And I have built an image with
all of the etherboot drivers.

-rwxrwxr-x    1 eric     eric       136080 Aug 21 02:52 bin32/etherboot.img*
-rwxrwxr-x    1 eric     eric        64912 Aug 21 02:52 bin32/etherboot.nrv2bimg
$ size bin32/unnrv2b.o      
   text    data     bss     dec     hex filename
    180       0       0     180      b4 bin32/unnrv2b.o

In it's final form the overhead for the nrv2b decompressor is just
180 bytes and should handle any size of file.  The 32bit infrastructure
is now an advantage instead of a liability size wise.

I will be adding targets etherboot, etherboot-pci, and etherboot-isa
shortly and then checking this code in.

Eric

Re: Re[2]: [Etherboot-developers] Q: device naming....

[Ronald G M. <rmi...@la...>]

On Wednesday 21 August 2002 10:14, Anselm Martin Hoffmeister wrote:
>
> A pity there's some thousand matches (about 104000 on google) for
> "Plan 9". Give us a clue, please.

Sorry. This is a reasonable starting point. 

http://plan9.escet.urjc.es/magic/man2html/8/9load

Why I like the syntax:
- good support for many device names/types
- naming syntax that includes the file system type
- network path names

pretty much anything I've found I want in a name string is in there. 

ron

Re[2]: [Etherboot-developers] Q: device naming....

[Anselm M. H. <an...@ho...>]

Hello Ronald,

> One thing I would like to mention re device naming is that Plan 9 has a
> reasonable device naming syntax that is uniform across their boot loader
> and OS. Worth taking a look.

> ron

A pity there's some thousand matches (about 104000 on google) for
"Plan 9". Give us a clue, please.

Thx
Anselm

Re: [Etherboot-developers] Question on supporting nVidia .o driver

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

On Wed, 21 Aug 2002, Andy Green wrote:
> Over at the xbox linux project there is some discussion today about
> supporting the nVidia inside the xbox (and used on nForce motherboards)
> Ethernet controller with an etherboot driver.
> The issue is that nVidia supply a .o file containing all the goodies; it
>   is believed to be quite possible to fake up something using the kernel
> network API to use this and make it believe it was a kernel driver.
> The main question is, what's the prevailing opinion about using a .o in
> this way GPL-wise.  It has been suggested that we'll be okay if we do
> not distribute the .o but make our GPL project consist of everything
> but.  (Because we are running on the xbox only, portability is not a
> concern).
> In addition, has anyone made such a fake kernel API shell before?  Has
> anyone looked at supporting nForce motherboards?

Aside from the legal / copyright issues, a few technical points spring
to mind:

1. The nVidia .o file is 20kB in size - around 4-5 times the size of most
   of the Etherboot drivers.  This might be enough to prevent it working
   in 5.0.x (AFAICT, the memory-map changes in the 5.1.x branch will fix
   this anyway).

2. Is it possible to use the .o file to create a polling driver?
   Etherboot doesn't use interrupts.

3. As others have said, don't bother faking a kernel network API - just
   take the skeleton Etherboot driver in skel.c and fill out the gaps
   between that and the nVidia .o file.

Michael Brown
http://www.fensystems.co.uk

[Etherboot-developers] Re: [Xbox-linux] Question on supporting nVidia .o driver

[Andy G. <an...@wa...>]

Milosch Meriac wrote:
> Am Mittwoch, 21. August 2002 17:47 schrieb Andy Green:
> 
>>In addition, has anyone made such a fake kernel API shell before?  Has
>>anyone looked at supporting nForce motherboards?
> 
> 
> You don't need a kernel API - you can directly link to nvnetlib.o - nvnet.c is 
> a excellent reference document for this.

Milosch, that's a great point, nvnet.c is a perfect example of how to 
use the .o, we don't need to worry too much about faking up an 
environment that nvnetlib.o will find acceptable.

-Andy

Re: [Etherboot-developers] Question on supporting nVidia .o driver

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

>Over at the xbox linux project there is some discussion today about 
>supporting the nVidia inside the xbox (and used on nForce motherboards) 
>Ethernet controller with an etherboot driver.
>
>The issue is that nVidia supply a .o file containing all the goodies; it 
>  is believed to be quite possible to fake up something using the kernel 
>network API to use this and make it believe it was a kernel driver.

You realise that Linux NIC drivers and Etherboot NIC drivers are
different kinds of animals? Read the Etherboot developers manual if you
want to understand what the difference is. A shim for Linux would be
different from a shim for Etherboot. If you can code up an Etherboot
shim and GPL that, I don't see any problem. Another problem you might
face is that the Etherboot execution environment is much more
parsimonious than the kernel environment. If the nVidia .o is
self-contained, that might not be a problem.

Re: [Etherboot-developers] Q: device naming....

[Anselm M. H. <an...@ho...>]

> Tenatively I have made the url:
> file:///floppy0
> file:///disk0

> With a +- offset to find the start of the boot file.
> Which is fine.

But that doesn't help in every case (e.g. Ms-doze formatted disc, some
kind of fragmentation taking place). OK, that's exaggeration, nowadays
you have to format floppies before using them anyway (storing them in
a box beside my screen. Good idea I hope).

Digging inside my 10-year-old "PC-intern 3.0" documentation I found
out that every dos floppy has a fixed format (well, I knew that,
but...) with a BIOS parameter block that allows the FAT to be shifted.
It usually starts at block 1 (offset 0x200), but one can shift that
while still keeping DOS compatibility. Imagine a disk layout like
this:

0x0000 (512 bytes) Bios Parameter Block*, Loader Code
       *with FAT-shift for 15,5 kB set
0x0200 (15,5 kB) Rest of etherboot
0x4000 Begin of FAT, length as needed
0x.... Directory

which should be DOS/Win-compatible. You better not format it (killing the
etherboot loader), but else it should work as usual floppy, allowing
you to copy the kernel to this disk from any operating system. Or (if
you cannot burn a ROM) lock a write-protected disc inside drive A
which can contain some stuff - better than provoking some Windumb
choke (if dual-OS or so, as in my "test lab") about that unformatted
disk in drive A.

In case someone writes FAT12 support, this disk could bear a kernel or
a menu image or so, but mountable and *easily* configurable from
linux.

> I am wondering if that naming convention is find of if I should
> switch to something like:

> file:///fd0
> file:///hd0

You could think about three factors
- What happens with the second/third disc? -> file:///disk1 ...
- How to access partitions (hard disk only)? -> file:///disk0/1 ...
- How to access files there? -> file:///floppy0/vmlinuz,
file:///disk0/1/vmlinuz -> that's not intuitive.
I'd prefer
file:///fd <number> [/<filename>]
file:///hd <letter> [<number>[/filename[+offset]]] (no number->mbr)
file:///hd <letter> [<number>][{+|-}offset]

Meanwhile, the + offset is ok, but what is - for?

> And on the same subject I am wondering if the old disk code
> that reads from the pcbios has enough merits to even be kept.

Could be... If there is some SCSI hardware snapping into the BIOS, it
could allow SCSI disk access as disk 0x81 or so. Your ide code
probably doesn't handle that up to now, does it?

file:///bd<number> [<number>] while <number> accesses the Bios
device 0x80+<number> could do (for BiosDisk-access). Floppy support
through the Bios can become obsolete. If sometime filesystem support
be added, an uniform interface to disk access could be reasonable. Not
neccessary for floppy/disk as few people will have
fat12-disk-partitions, but who knows if for scsi(via Bios)/ide?

Watching a game, having a Bud,

Anselm

[Etherboot-developers] Re: [Xbox-linux] Question on supporting nVidia .o driver

[Milosch M. <xbo...@me...>]

Am Mittwoch, 21. August 2002 17:47 schrieb Andy Green:
> In addition, has anyone made such a fake kernel API shell before?  Has
> anyone looked at supporting nForce motherboards?

You don't need a kernel API - you can directly link to nvnetlib.o - nvnet=
=2Ec is=20
a excellent reference document for this.

--
Milosch

[Etherboot-developers] Question on supporting nVidia .o driver

[Andy G. <an...@wa...>]

Over at the xbox linux project there is some discussion today about 
supporting the nVidia inside the xbox (and used on nForce motherboards) 
Ethernet controller with an etherboot driver.

The issue is that nVidia supply a .o file containing all the goodies; it 
  is believed to be quite possible to fake up something using the kernel 
network API to use this and make it believe it was a kernel driver.

The main question is, what's the prevailing opinion about using a .o in 
this way GPL-wise.  It has been suggested that we'll be okay if we do 
not distribute the .o but make our GPL project consist of everything 
but.  (Because we are running on the xbox only, portability is not a 
concern).

In addition, has anyone made such a fake kernel API shell before?  Has 
anyone looked at supporting nForce motherboards?

-Andy

Re: [Etherboot-developers] Q: device naming....

[Ronald G M. <rmi...@la...>]

One thing I would like to mention re device naming is that Plan 9 has a
reasonable device naming syntax that is uniform across their boot loader
and OS. Worth taking a look.

ron

Re: [Etherboot-developers] Q: device naming....

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

>What I am trying to do with the names is have a name for a class
>of devices.  nics, hard drive, floppy drives, cds, tapes, dislpay.  An
>average machine will normally have only one device of each class.  So
>for a simple machine the names will be unambiguous, and predictable.
>``file:///disk0'' will mean your first disk if it scsi, ide, or even
>if it is plugged into the second channel of your ide controller
>instead of the first.
>
>On top of this infrastructure I also intend to have a setup of
>bootorder where it selects which devices to boot from.

Ok, got it.

>Two pieces.
>- try_floppy_first(), read from the floppy disk, and returns to
>  the BIOS if it doesn't get an error.
>- The second case bootdisk() transfers control to the MBR.

Both cases sound like they can be replaced by the functionality of your
code.

Re: [Etherboot-developers] Q: device naming....

[Eric W B. <ebi...@ln...>]

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

> >Tenatively I have made the url:
> >
> >file:///floppy0
> >file:///disk0
> >
> >With a +- offset to find the start of the boot file.
> >
> >Which is fine.
> >
> >I am wondering if that naming convention is find of if I should
> >switch to something like:
> >
> >file:///fd0
> >file:///hd0
> 
> Any chance of booting from SCSI in future?

Definitely.

> Flash disks?
 
Compact flash already works with the IDE driver.  And I don't see a
problem with writing a driver for something like the DOC millenium.
The current infrastructure works on anything that has a random read
operation.

The really interesting piece will be getting the console code flexible
enough so it can have a flexible set of drivers as well.  Under
LinuxBIOS we need something like a framebuffer so we can enable the
video.

> Using an
> existing naming convention like Linux's has the advantage you have
> a ready made stock of names.

Matching up 100% is impossible on physical devices.  Linux can't
even do it from kernel to kernel.  And if the names don't match 100%
I'm not certain they should match at all.

What I am trying to do with the names is have a name for a class
of devices.  nics, hard drive, floppy drives, cds, tapes, dislpay.  An
average machine will normally have only one device of each class.  So
for a simple machine the names will be unambiguous, and predictable.
``file:///disk0'' will mean your first disk if it scsi, ide, or even
if it is plugged into the second channel of your ide controller
instead of the first.

On top of this infrastructure I also intend to have a setup of
bootorder where it selects which devices to boot from.

Having a seperate device class does not imply having a seperate
driver merely the probe() (descended from eth_probe) will look
for that device seperately from others.

> >And on the same subject I am wondering if the old disk code
> >that reads from the pcbios has enough merits to even be kept.
> 
> What does it do again? Only transfers control to the MBR IIRC?

Two pieces.
- try_floppy_first(), read from the floppy disk, and returns to
  the BIOS if it doesn't get an error.
- The second case bootdisk() transfers control to the MBR.

Eric

Re: [Etherboot-developers] Q: device naming....

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

>Tenatively I have made the url:
>
>file:///floppy0
>file:///disk0
>
>With a +- offset to find the start of the boot file.
>
>Which is fine.
>
>I am wondering if that naming convention is find of if I should
>switch to something like:
>
>file:///fd0
>file:///hd0

Any chance of booting from SCSI in future? Flash disks? Using an
existing naming convention like Linux's has the advantage you have
a ready made stock of names.

>And on the same subject I am wondering if the old disk code
>that reads from the pcbios has enough merits to even be kept.

What does it do again? Only transfers control to the MBR IIRC?

[Etherboot-developers] Q: device naming....

[Eric W B. <ebi...@ln...>]

I have checked in the IDE and floppy support.

Tenatively I have made the url:

file:///floppy0
file:///disk0

With a +- offset to find the start of the boot file.

Which is fine.

I am wondering if that naming convention is find of if I should
switch to something like:

file:///fd0
file:///hd0

And on the same subject I am wondering if the old disk code
that reads from the pcbios has enough merits to even be kept.

Eric

[Etherboot-developers] 5.1.2+ status

[Eric W B. <ebi...@ln...>]

O.k. I have been making headway.

I have what looks like a solid read only disk api.  That should handle
just about everything, CDs being the major question mark.

The floppy driver and the ide driver both seem to work, and have
been converted, to normal drivers, and are now listed in NIC.

The floppy driver still has several corner cases that need polish,
(It doesn't detect when you don't have a disk in the drive or when the 
  floppy drive isn't plugged in.), and it doesn't autodetect the geometry
of your disk, but the core works fine.

I have dug out the compressor/decompressor code from upx, and
am just about ready to incoporate it into etherboot.  The decompressor
is 144 bytes, with no buffers.  It uses the stack but only as a space
optimization (push/pop is smaller that mov).

I will check all of this code in shortly.  Now I need to go to bed.

Eric

[Etherboot-developers] RFP - Patch for tftp address

[Bill C. <bi...@ca...>]

Request for Proposal - Patch for tftp ip address

Please send your quote for this project to Bill Cavalieri
(bi...@ca...), include either a hourly rate with estimated hours
to complete project, or a set fee.  This patch would be offered back to
the etherboot maintainers, and available for download from my site.  The
programmer and my company would be listed in the credits.  

Please submit a phone number, and an appropriate time that you can be
reached to discuss project (communication from then on would be by
email).

You would receive a small upfront payment as a gesture of good will, and
the rest of payment on delivery of final patch.


Desc:
I would like to be able to use etherboot in networks where I have no
control over the dhcp server, for the purpose of booting off a LTSP
server.

Project:
To be able to create an etherboot image, that receives the client ip
address from any dhcp server, and has the tftp server ip address hard
coded in the image.  The tftp and LTSP would be on the same server.
Floppy drives would be the predominant method of booting.

Deliverables:
source code patch for etherboot
instructions on creating floppy image with patch



-Bill


  

Re: [Etherboot-developers] All pci drivers in 1 rom image.

[Eric W B. <ebi...@ln...>]

Michael Brown <mb...@fe...> writes:
> 
> Ummm... it already did that.

It certainly didn't look like it would sucessfully recurse forever,
but I could have missed something.  Thinking it looked like it might
have succesfully parsed the filename, and used the approriate .o files,
but I still don't think it had the dependencies correct.

In any event the current version is quite a bit simpler, which makes
comprehension and maintenance better.  I'm just short of 200 lines,
in genrules.pl  And the Roms file is quite a bit shorter as well.

Eric

Re: [Etherboot-developers] All pci drivers in 1 rom image.

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

On 16 Aug 2002, Eric W Biederman wrote:
> > > size limit already.  So I will probably add a target for all pci
> > > drivers, to avoid this problem.
> > > size
> > bin32/3c595--3c90x--eepro100--e1000--lance--tulip--davicom--rtl8139--via-rhine--w89c840--sis900--natsemi--fa311--prism2_plx--prism2_pci--ns8390--epic100.tmp
> >
> > >    text	   data	    bss	    dec	    hex	filename
> > > 83156 2856 106076 192088 2ee58
> > bin32/3c595--3c90x--eepro100--e1000--lance--tulip--davicom--rtl8139--via-rhine--w89c840--sis900--natsemi--fa311--prism2_plx--prism2_pci--ns8390--epic100.tmp
> > I assume you'll be keeping the current scheme as well - the most usual
> > number of drivers in a ROM will probably be 1, 2 or all of them.
> Right.  I still haven't written the all of them case.  But I have
> extended the current scheme to be fully recursive as above, so you
> can include all of the drivers you want.

Ummm... it already did that.

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

[Etherboot-developers] 32bit bios calls broken in 5.1.2+

[Eric W B. <ebi...@ln...>]

I just noticed that pci.c uses inline assembly to perform 32bit bios
calls when CONFIG_PCI_DIRECT is not selected.  Ouch!

It will be a little while before this is fixed, but if relocation is
used this won't work.  I need to think just a little bit on the
correct fix for this.  It may just be enough to change the segment
register, but it might require a little more work.

Eric

Re: [Etherboot-developers] SMC 1211 vendor id correction

[Eric W B. <ebi...@ln...>]

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

> >Some versions of the smc1211tx card use 0x1112 and others use 0x1113.
> >And, they didn't change the version number on the card !
> 
> Ok, put both entries in. I hate these manafacturer shenanigans.

Careful with the 5.1.x branch, as the places the id's go just changed.

Eric