etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] Verifying loaded ELF images, with the IP checksum...

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

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

> >Ken has all of the utilities in perl, and I have a one as well that
> >prepare network bootable images.  And for the longest time I could
> >not figure out how to perl to do a reasonably fast job of computing
> >the ip checksum.  Reasonable as in under a minute.  The attached
> >code accomplishes that. 
> 
> Your code runs in 0.1s on a 1MB vmlinuz file on my system (350MHz K6-2).
> Congratulations.

Nice.  Then I won't worry about the code to much.
 
> >Does anyone have any objects to included this checksum ability
> >into mknbi?
> 
> Go for it.

O.k. it is on my Todo/wishlist.  So I will implement it the first
decent opportunity I get.
 
> >Or ideas on how to speed of the ckecksum computation,
> >even more?
> 
> You can get 20% improvement by using pass by reference. Call
> compute_ip_checksum(\$string). In the routine, replace all but the first
> $str with $$str.

Nice.  Do you know if the substr hurts?  I guess at 0.1s it isn't too
bad.  Last time I was messing with the code and I complained checksums
in perl were terribly slow, you speculated that the problem was that I
was using substr.  And it has taken me a long time to think of a
substitute.

Eric

[Etherboot-developers] mknbi-dos images cause problem whereas the image works when booted from floppy.

[<sa...@um...>]

I'm having problems with a nbi-dos modified image.

I've created a network boot floppy using win98 startup disk with windows 
network client 3.0

The original image (copied from the floppy) works fine.

When netbooted (using a etherboot 5.0.5 network bios)
The loaded dos OS has issues with memory, namely net.exe complains about a 
"Error 8: There is not enough memory available"
when doing a net start.

I can send both the nbi-dos image & the dos image upon request, and I am 
using the most recent mknbi-dos program.

Disk images are created fromteh floppy with dd.

The etherboot 5.0.5 is in a modified ECS k75sa BIOS.

Any help would be appreciated.

satadru

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

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

Scott Tillman wrote:

> Am I misunderstanding what you want here?  If so, then have at the 
> discussion.  If not, then stop worrying about using nvidia's .o files in 
> the linux kernel...it's allowed.

The issue that started this is, can we make an etherboot instance that 
relies on the nvnet.o.  My take on the general response is, go for it, 
but don't expect anyone to take your bullet from RMS's assault rifle.

-Andy

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

[Scott T. <spe...@ho...>]

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

First, I should say that it is, by default, illegal to link (runtime linking 
counts) non-GPL binaries into GPL binaries...by default.

The copyright holder of the GPL'd code has the right to allow this through 
explicit exemption.  In the case of the kernel code (copyright Linus 
Torvalds) this right has been granted.  So, binary only kernel modules are 
allowed, though everyone and their brother will whine incessantly about you 
not releasing the sources.

Am I misunderstanding what you want here?  If so, then have at the 
discussion.  If not, then stop worrying about using nvidia's .o files in the 
linux kernel...it's allowed.

-SpeedBump

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

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

[Robert C. <lif...@bi...>]

On Sat, 2002-08-24 at 00:41, Donald J Christensen wrote:
> Richard Antony Burton wrote:

 
> > This also means that you can not link dynamically
> > both to a GPLed library and a proprietary library because the licenses of
> > the two libraries conflict."
> 
> This, on the other hand, does not make any sense at all, and I bet that
> it would not stand up to a legal test (but IANAL).  The GPLed library is
> not required to make the proprietary library function.

AFAIK you are correct. The GPL can not, and does not prevent the use of
proprietary libraries by the author of a GPL program. In fact, the GPL
itself does not mention libraries at all.
(http://www.gnu.org/licences/gpl.html).
 
> The license of the proprietary library makes no restrictions on other
> libraries that might also be linked to the executable.  

Actually, a licence can do just about anything that the licensor can get
the licencee to agree to. See for example MS's exluding the use of GPL'd
*tools* with it's winCE SDK. No grepping in this source!. However, for
the case *in discussion* I haven't read the NVidia licence, but assume
that it is friendly enough to permit use with linux :}, and therefor
this project.

> I can't see how
> the GPL can extend from a library up into an executable and then down into
> another library.  In a sense, the two libraries are not being linked
> together, they just happen to both be linked to a common executable.

The GPL doesn't try to extend intoo the other library. (assuming use of
a GPL library, not a new author deciding what to do): The GPL only has
power over code *you* create. It can't influence something a third party
has created. What it can do is prevent you from violating the
only-use-this-code-if-you-release-your-own rule that applies to the GPL
library. Specifically, see section 3 of the GPL. (I won't quote here for
brevity.) If you are unable to provide the full source for the
executable excluding *normally distributed components of the OS*, then
you can not use the GPL'd library XOR you cannot 'distribute' the
product (because it is a derived work from the library - yuck). This
means that if that proprietary library that you want to use, is not part
of the OS... it's  going to prevent you complying with section 3 UNLESS
you get an excemption - see below. Note: under no circumstances does the
GPL ask that the licence on the proprietart library be changed, only
that the code author make a choice.
 
> As someone else said, if the GPL does try to do this, then it is broken.
> I suspect there are no end of examples of GPLed code that links to the
> proprietary C libraries of various systems.  

These are covered by 'normally distributed components'.

> IIRC, gcc linked with the
> system C library for a long time before the Gnu C library was an
> adequate replacement.

There is an important thing to add here: The author of any given work
can create an excemption in the GPL to allow linking with specific (or
generic) proprietary libraries. There was some relicencing fuss with GPL
projects that use libssl for just this reason recently IIRC.
cygwin1.dll, which is a GPL C-and-a-bit library for win32, creates a
specific excemption to the GPL for and 'open source compliant' licence
(ie the X licence). 

For the code that will use the Nvidia blob, the author can create such
an exclusion. If no one here will be that author, or it will be a
derived work, or need pure GPL, non OS standard libraries available,
then you need to write to the original author(s) and get an excemption.

http://www.gnu.org/licenses/gpl-faq.html may be of interest to you folk.

Or you could email RMS and get a specific answer for what you want to
accomplish.

Rob

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

[Donald J C. <dj...@ci...>]

Richard Antony Burton wrote:
> 
> ----- Original Message -----
> From: "Andy Green" <an...@wa...>
> To: <eth...@li...>
> Cc: <Xbo...@li...>
> Sent: Wednesday, August 21, 2002 4:47 PM
> Subject: [Xbox-linux] Question on supporting nVidia .o driver
...
> So, when you compile an executable and you link it
> dynamically to a GPLed library, the executable must be distributed as free
> software with the library.

This makes perfect sense, since the executable would not function without
the GPLed library.

> This also means that you can not link dynamically
> both to a GPLed library and a proprietary library because the licenses of
> the two libraries conflict."

This, on the other hand, does not make any sense at all, and I bet that
it would not stand up to a legal test (but IANAL).  The GPLed library is
not required to make the proprietary library function.

The license of the proprietary library makes no restrictions on other
libraries that might also be linked to the executable.  I can't see how
the GPL can extend from a library up into an executable and then down into
another library.  In a sense, the two libraries are not being linked
together, they just happen to both be linked to a common executable.

As someone else said, if the GPL does try to do this, then it is broken.
I suspect there are no end of examples of GPLed code that links to the
proprietary C libraries of various systems.  IIRC, gcc linked with the
system C library for a long time before the Gnu C library was an
adequate replacement.

-Don

-- 
Don Christensen       Senior Software Development Engineer
dj...@ci...         Cisco Systems, Santa Cruz, CA
  "It was a new day yesterday, but it's an old day now."

Re: [Etherboot-developers] Verifying loaded ELF images, with the IP checksum...

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

> Does anyone have any objects to included this checksum ability
> into mknbi?  Or ideas on how to speed of the ckecksum computation,
> even more?

0. Look in CPAN, there may be something already.  Always the first
step when you need neat stuff in Perl. I can't see anything obvious
for IP checksum, there are "Math" modules.

1. Write a C function and create a Perl hook. Not too hard, use Swig
(or put the C here and I'll do it). Contribute to CPAN when done.

2. Write a C standalone utility and use system() or backticks to get
the answer.

Re: [Etherboot-developers] Verifying loaded ELF images, with the IP checksum...

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

>Ken has all of the utilities in perl, and I have a one as well that
>prepare network bootable images.  And for the longest time I could
>not figure out how to perl to do a reasonably fast job of computing
>the ip checksum.  Reasonable as in under a minute.  The attached
>code accomplishes that. 

Your code runs in 0.1s on a 1MB vmlinuz file on my system (350MHz K6-2).
Congratulations.

>Does anyone have any objects to included this checksum ability
>into mknbi?

Go for it.

>Or ideas on how to speed of the ckecksum computation,
>even more?

You can get 20% improvement by using pass by reference. Call
compute_ip_checksum(\$string). In the routine, replace all but the first
$str with $$str.

[Etherboot-developers] Verifying loaded ELF images, with the IP checksum...

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

One of the pieces I have implemented in 5.1.x is the ability to read
the ELF note section, and read various interesting pieces of
information, most of which are not yet defined. 

The most useful piece I have built so far is the ability to verify
a checksum on the entire loaded image.  At the moment I am using
the IP checksum because that is a moderately strong checksum, and
every bootrom need to implement it for other reasons as well.

Ken has all of the utilities in perl, and I have a one as well that
prepare network bootable images.  And for the longest time I could
not figure out how to perl to do a reasonably fast job of computing
the ip checksum.  Reasonable as in under a minute.  The attached
code accomplishes that. 

Does anyone have any objects to included this checksum ability
into mknbi?  Or ideas on how to speed of the ckecksum computation,
even more?

Eric


sub compute_ip_checksum
{
	my ($str) = @_;
	my ($checksum, $i, $size, $shorts);
	$checksum = 0;
	$size = length($str);
	$shorts = $size >> 1;
	# Perl has a fairly large loop overhead so a straight forward
	# implementation of the ip checksum is intolerably slow.
	# Instead we use the unpack checksum computation function,
	# and sum 16bit little endian words into a 32bit number, on at
	# most 64K of data at a time.  This ensures we do not overflow
	# the 32bit sum allowing carry wrap around to be implemented by
	# hand.
	for($i = 0; $i < $shorts; $i += 32768) {
		$checksum += unpack("%32v32768", substr($str, $i <<1, 65536));
		while($checksum > 0xffff) {
			$checksum = ($checksum & 0xffff) + ($checksum >> 16);
		}
	}
	if ($size & 1) {
		$checksum += unpack('C', substr($str, -1, 1));
		while($checksum > 0xffff) {
			$checksum = ($checksum & 0xffff) + ($checksum >> 16);
		}
	}
	$checksum = (~$checksum) & 0xFFFF;
	return $checksum;
}

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

[Richard A. B. <ric...@ho...>]

----- Original Message -----
From: "Stefan Reinauer" <st...@su...>
To: "Richard Antony Burton" <ric...@ho...>
Cc: "Andy Green" <an...@wa...>;
<eth...@li...>;
<Xbo...@li...>
Sent: Friday, August 23, 2002 11:27 AM
Subject: Re: [Xbox-linux] Question on supporting nVidia .o driver


> * Richard Antony Burton <ric...@ho...> [020823 11:35]:
> > "Some people feel that linking to the library dynamically avoids making
the
> > executable derived work of the library. A dynamically linked executable
does
> > not embed a copy of the library. Instead, it contains code for loading
the
> > library from the disk during run-time. However, the executable is still
> > derived work.
>
> This would mean that
> a) You're not allowed to boot Windows using Lilo
> b) You're not allowed booting Windows CE using LinuxBIOS.

Surely here the boot loader isn't making use of the code that it links too.
I think it would be stretch of the imagination to say a bootloader is a
derived work of the operating system (which ever it happens to be booting).
Also what the user chooses to boot, is up to the user, and not then
distributed in some form based on it. I think I'm right in saying you can do
what you like with GPL software on your own PC, so long as you aren't
intending distributing it.

I guess the quote given doesn't actually exclude your example, but perhaps
it is slightly out of context.


> The border is pretty philosophical I guess. But still. As long as
> the closed source blob would not call symbols from it's "loader", but
> just gets parsed and executed, this is not a library.

But we make use of it's functions. We load it so we can use networking, so
isn't it acting as a library for us?

> The missing
> memcpy could be linked against the nv module (Thus creating a non-GPLed
> memcpy function before to avoid license problems)
> When the loader functionality is generic enough to only interact as
> a intermediate boot API layer, "using" the nv object as data.

Doesn't your additional loader layer then become governed (forcefully) by
the GPL, leaving you back at the same point again. You can't just create a
layer for all the GPL software, make that layer non-GPL and then do what you
like through the layer. If you try, the layer has become GPL too, gaining
you nothing.

> It would be enough though to show the functionality of the link layer
> by having one example where an open source driver uses this as well.
> Whether this example actually works should not even matter as long as
> it is there and shows the principles. There is no law telling that the
> software I give out for free is forced to be fully operational

You mean make your own GPL verison of vmnet.o (for distribution with xbox
linux) that has the same interface, but doesn't do anything. Then if users
choose to replace that with the real version it's out of your hands? I guess
that might work, but it's deceptive and not in the spirit of the GPL. (Which
I might add I'm not a fan of, so yeah, I like your plan!)

Richard.

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

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

Stefan Reinauer wrote:

>>If there is a licence conflict, hasn't it already been broken by the
>>distribution of nvnet.o with the current version of xbox linux?
> 
>  
> Probably, yes. SuSE does not deliver this with it's distribution, but
> rather contains a bunch of scripts downloading it for you. Same applies
> for some Truetype Fonts (here you even have to acknowledge the licenses
> to these)

:-(  This discussion doesn't seem to be helping.  nVidia put their 
object code driver out for use by the free software community, we're 
using it.  They didn't want to share (for their own stupid reasons) 
information about the register-level detail of the chip.  We are 
respecting that.  And frankly if the GPL is trying to tell me that I 
CAN'T make a GPL project that interoperates with a .o file, yet does not 
include as part of the project, then something is busted with the GPL 
and we should release under a GPL.xboxlinux license which is exactly the 
same but allows this.  Andy's brain says: ignore all this pointless 
nonproductive amateur lawyer crud and if someone feels we're doing them 
down they can say and we will react.  In the meanwhile, do the needful.

I can see why the GPL might want to encourage totally clean licenses and 
no funny dependences.  But in our situation, with an externally mandated 
box and the one architechture to get going, its just burdensome.

>>And are we just looking at getting a replacement driver from the etherboot
>>project? Or are we looking at remote booting the xbox? I'd be happier with a
>>standalone box, not dependant on being served it's boot image. I hope that
>>will still be an option.
> 
> remote booting is the way to go as long as you develop the basic system
> functionality. As soon as it's possible to install Linux natively you
> will very likely not need it.

Etherboot will be another way to bring up the box under user control, 
that's all.  Its not removing choices but adding them.  It seems from 
the people using what it out there so far the CD boot route is currently 
preferred.  In the future we will be installing a distro to HDD too. 
Personally I am an embedded trog and I am booting it from the flash 
(although I will probably move to Etherboot thus removing space 
problems).  So whatever you like it will still be there.

-Andy

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

[Stefan R. <st...@su...>]

* Richard Antony Burton <ric...@ho...> [020823 11:35]:
> >From http://www.codelearn.com/cpp/gnutools/node56.html
> 
> "Some people feel that linking to the library dynamically avoids making the
> executable derived work of the library. A dynamically linked executable does
> not embed a copy of the library. Instead, it contains code for loading the
> library from the disk during run-time. However, the executable is still
> derived work.

This would mean that
a) You're not allowed to boot Windows using Lilo
b) You're not allowed booting Windows CE using LinuxBIOS.

The border is pretty philosophical I guess. But still. As long as 
the closed source blob would not call symbols from it's "loader", but
just gets parsed and executed, this is not a library. The missing 
memcpy could be linked against the nv module (Thus creating a non-GPLed
memcpy function before to avoid license problems)
When the loader functionality is generic enough to only interact as
a intermediate boot API layer, "using" the nv object as data. 
Otherwise I would not be allowed to write closed source commercial 
software when using vim. 
Or am I completely wrong?

> "Note that there is no conflict when a GPLed utility is invoked by a
> proprietary program or vice versa via a system () call." Can we
> modprobe/insmod from a system call to load the module? That would bring us
> to this: "However, a free program that depends on a proprietary program for
> its operation can not be included in a free operating system, because the
> proprietary program would also have to be distributed with the system."
> Hence the not distributing the .o file idea.

It would be enough though to show the functionality of the link layer
by having one example where an open source driver uses this as well.
Whether this example actually works should not even matter as long as
it is there and shows the principles. There is no law telling that the
software I give out for free is forced to be fully operational

> If there is a licence conflict, hasn't it already been broken by the
> distribution of nvnet.o with the current version of xbox linux?
 
Probably, yes. SuSE does not deliver this with it's distribution, but
rather contains a bunch of scripts downloading it for you. Same applies
for some Truetype Fonts (here you even have to acknowledge the licenses
to these)

> And are we just looking at getting a replacement driver from the etherboot
> project? Or are we looking at remote booting the xbox? I'd be happier with a
> standalone box, not dependant on being served it's boot image. I hope that
> will still be an option.

remote booting is the way to go as long as you develop the basic system
functionality. As soon as it's possible to install Linux natively you
will very likely not need it.
 
  Stefan

-- 
The x86 isn't all that complex - it just doesn't make a lot of
sense.          -- Mike Johnson, Leader of 80x86 Design at AMD
	                          Microprocessor Report (1994)

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

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

>"Note that there is no conflict when a GPLed utility is invoked by a
>proprietary program or vice versa via a system () call." Can we
>modprobe/insmod from a system call to load the module? That would bring us
>to this: "However, a free program that depends on a proprietary program for
>its operation can not be included in a free operating system, because the
>proprietary program would also have to be distributed with the system."
>Hence the not distributing the .o file idea.

How about using software interrupts to interface to nvidia.o, does that
count?

>And are we just looking at getting a replacement driver from the etherboot

Etherboot has no nvidia driver to speak of.  And an Etherboot driver is
not a replacement for a Linux driver.  This whole thread was started by
somebody who thought nvidia.o could be called from Etherboot for
netbooting. Whether you implement disk booting in addition is not
Etherboot's concern, at least.

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

[Richard A. B. <ric...@ho...>]

----- Original Message -----
From: "Andy Green" <an...@wa...>
To: <eth...@li...>
Cc: <Xbo...@li...>
Sent: Wednesday, August 21, 2002 4:47 PM
Subject: [Xbox-linux] Question on supporting nVidia .o 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).

From http://www.codelearn.com/cpp/gnutools/node56.html

"Some people feel that linking to the library dynamically avoids making the
executable derived work of the library. A dynamically linked executable does
not embed a copy of the library. Instead, it contains code for loading the
library from the disk during run-time. However, the executable is still
derived work. The law makes no distinction between static linking and
dynamic linking. So, when you compile an executable and you link it
dynamically to a GPLed library, the executable must be distributed as free
software with the library. This also means that you can not link dynamically
both to a GPLed library and a proprietary library because the licenses of
the two libraries conflict."

If that is the case, it doesn't appear to matter if you distribute the
library or not, the fact that you intend to link with it makes it a derived
work. The suggested work around is to use something else, or get the maker
of the library to release it under the GPL - great work arounds, why didn't
we think of these! :-).

"Note that there is no conflict when a GPLed utility is invoked by a
proprietary program or vice versa via a system () call." Can we
modprobe/insmod from a system call to load the module? That would bring us
to this: "However, a free program that depends on a proprietary program for
its operation can not be included in a free operating system, because the
proprietary program would also have to be distributed with the system."
Hence the not distributing the .o file idea.

Has anyone actually spoken to a Legal expert on this? Or someone from
GNU/FSF? They may be able to clear it up once and for all.

If there is a licence conflict, hasn't it already been broken by the
distribution of nvnet.o with the current version of xbox linux?

And are we just looking at getting a replacement driver from the etherboot
project? Or are we looking at remote booting the xbox? I'd be happier with a
standalone box, not dependant on being served it's boot image. I hope that
will still be an option.

Richard.

Re: [Etherboot-developers] On filesystems and booting from disk.

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

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

> >Basically the same code we have today except with 
> >how configuration is loaded from disk is different from
> >how the configuration is loaded from DHCP.
> >
> >The big change is the outer loop walking through each
> >of the different classes of devices and trying them one by one.  The
> >minor change is having a different probe, load_configuration, and load
> >functions for the different classes of devices. 
> 
> Yes, that all makes sense.
> 
> You'd also need somewhere to store the priority list, or hardwire it, or
> allow an escape key to choose the booting device interactively, like
> some BIOSes do.

Yes definitely, and with LinuxBIOS I can also put it in a CMOS option.
But putting that into an appropriate call is not to bad once the rest
is abstracted. 

The interesting part is also having the boot from disk code integrate
with the external menu code :)

On the escape key side there are a couple of semi important things.
1) It should be fairly easy for a user to cope with (menu).
2) It should be expect friendly so if necessary it can be scripted
   over the serial line.
3) For power users it would be nice if we could just type in an
   etherboot specific url.  Something roughly like lilo in command
   line mode.

I am going to start with a compiled in priority and then get
the rest.

Eric

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

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

Stefan Reinauer <st...@su...> writes:

> * Eric W Biederman <ebi...@ln...> [020821 20:12]:
> > > 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).
> > 
> > This assumes the appropriate virt_to_bus, bus_to_virt and ioremap calls
> > are being made.  Otherwise it try reading and writing to the wrong
> > registers.
> 
> Would a driver working in Linux not always require the virt_to_bus
> address shifting? 

There is a fairly big difference between virt_to_bus, and
pci_alloc_consistent.  A modern Linux driver will use
pci_alloc_consistent.  Plus if the abstraction is poor nvidia could 
be making assumptions about how Linux implements virt_to_bus
which is totally different from the etherboot implementation.

The reason etherboot can get away with virt_to_bus is that when
it is ported I can essentially do pci_alloc_consistent on the entire
etherboot image.   At least that is the plan.

Eric

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

[Stefan R. <st...@su...>]

* Eric W Biederman <ebi...@ln...> [020821 20:12]:
> > 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).
> 
> This assumes the appropriate virt_to_bus, bus_to_virt and ioremap calls
> are being made.  Otherwise it try reading and writing to the wrong
> registers.

Would a driver working in Linux not always require the virt_to_bus
address shifting? 

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

Not faking the kernel api, but faking the api that nvidia uses 
in it's wrapper and on the other side, implementing a suitable etherboot
api grip.

Best regards,
  Stefan 
  
-- 
The x86 isn't all that complex - it just doesn't make a lot of
sense.          -- Mike Johnson, Leader of 80x86 Design at AMD
	                          Microprocessor Report (1994)

Re: [Etherboot-developers] On filesystems and booting from disk.

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

>Basically the same code we have today except with 
>how configuration is loaded from disk is different from
>how the configuration is loaded from DHCP.
>
>The big change is the outer loop walking through each
>of the different classes of devices and trying them one by one.  The
>minor change is having a different probe, load_configuration, and load
>functions for the different classes of devices. 

Yes, that all makes sense.

You'd also need somewhere to store the priority list, or hardwire it, or
allow an escape key to choose the booting device interactively, like
some BIOSes do.

[Etherboot-developers] On filesystems and booting from disk.

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

The basic structure needed to extend etherboot to boot from disk, is
the same with or without a filesystem.

My first stab at the needed outer loop is:
static void main2(void)
{
	struct class_operations *ops;
	int i, class;
	for(i = 0; i < sizeof(classes)/sizeof(classes[0]); i++) {
		int adapter;
		ops = &classes[i];
		while((adapter = ops->probe(adapter)) > 0) {
			ops->load_configuration();
			ops->load();
		}
	}
}

Basically the same code we have today except with 
how configuration is loaded from disk is different from
how the configuration is loaded from DHCP.

The big change is the outer loop walking through each
of the different classes of devices and trying them one by one.  The
minor change is having a different probe, load_configuration, and load
functions for the different classes of devices. 

With the above setup having filesystem support can be implemented
with different load_configuration, and load functions from the
stupid ELF loader.  So it shouldn't limit anyone.

I still need to look at the disk loading code in detail to convince
myself it really is worth it, but I fully intend to allow it
to happen.

Eric

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

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

On Wed, 21 Aug 2002, Peter Lister wrote:
> > 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.

For the sake of the sanity of anyone who tries to develop this driver:
>=20kB of driver code is almost certainly enough to make Etherboot 5.0.x
simply die without warning at seemingly random points.  I say this on the
basis that 17kB of driver code (prism2_pci, prism2_plx and rtl8139 in the
same build) produces these effects.  This is due to the memory model in
Etherboot 5.0.x.

I would strongly recommend that anyone attempting to write this driver
ignores the 5.0.x tree and works only on 5.1.x with the new memory
architecture.

*** DO NOT TRY TO GET THIS DRIVER TO WORK WITH ETHERBOOT 5.0.x ***

Hopefully that might save someone a few days of pointless head-banging.
:-)

Michael Brown

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

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

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

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

Yes, and no.

Ultimately a filesystem driver is useful.

There are two cases.

Have a simple consistent interface that everything supports that is
enough to boot from disk.  For a PCBIOS this is reading the first
sector from the drive and jumping to it.  With LinuxBIOS and Etherboot
I am aiming at being just slightly more sophisticated.

Once you can get something off of the drive, and you aren't limited by
what you can put into the ROM chip you can be a lot more flexible.

I am definitely convinced that filesystem drivers can be small and
useful.  I know Ollie Lho, and Ada Agnew have had pretty good luck
with them.  It certainly makes sense to have them someplace in the
bootloader path.  I'm just not certain if etherboot is the tool to
have them.  

So for the url case having a way to specify filesytems and partitions is
definitely good. 

I suspect just:
file:///<device>/<partition>/<path/to/file>
is good enough.  Because partition types and filesystem types can
be autodetected.

If etherboot were to have a filesystem drivers I suspect the way
to go is to configure it to have 2 modes of operation.  Full on
filesystem, and configuration file support, and simple stupid read an
ELF image from the ram disk device support.  With the simple version
going in ROM chips and the complicated coming off the filesystem, network,
and only occasionally being flashed into the ROM when there is room.

But space wise we are doing pretty good currently etherboot will every
driver is only 65K.

Eric

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

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

Markus Gutschke <ma...@gu...> writes:

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

The simplied version is now checked in to etherboot cvs.

Conceptually it is based on copying bytes.  But instead of using
a hufman tree to encode the bits, it uses an encoding based upon stop
bits.

Check out the decompressor in nrv2b.c it is only about a screenful so
it isn't to hard to comprehend.  Watch out for the GETBIT code though
how it uses stop bits instead of a count to remember how far to go is
interesting.

Then look at the unnrv2b.S the optimized assembly version, and notice
how a lot of the awkward cases in C, become straight easy to
implement in the assembly.

Eric

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

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

> It seems I did misunderstand you here, however, I was imagining that 
> nvnetlib.o is full of APIs that take kernel-defined structs as 
> parameters, etc, and at least to this extent it will need to be kept 
> satisfied.

I didn't make it too clear, but my cursory inspection did establish that
the only linux related stuff seems to be the "driver" part, (nvnet.c
nvnet.h os.h), and NOT the "NIC API" parts (basetype.h phy.h adapter.h).
I'm basing my guesses to a significant degree on the "looks like they
did the right thing, so they probably did" principle.

We want to use the Linux driver as guide and then write an EB driver to
the NIC's API.

> Yes, this work should be equally applicable to the nForce motherboards, 
> in case the xbox is a bit contentious for them.

Sure. I think Etherboot and LTSP are "respectable" enough.

Also, if anyone out there has a non-Xbox mobo, it might make EB
development a bit easier.

> The .o can be kept at arms length from whatever shim is needed to 
> interface it to the etherboot stuff, I can imagine it can be distributed 
> in a way that nobody will be unhappy.

And again, we can at least ask. They probably just don't know about EB.

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

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

Peter Lister wrote:

> 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

It seems I did misunderstand you here, however, I was imagining that 
nvnetlib.o is full of APIs that take kernel-defined structs as 
parameters, etc, and at least to this extent it will need to be kept 
satisfied.

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

Yes, this work should be equally applicable to the nForce motherboards, 
in case the xbox is a bit contentious for them.

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

The .o can be kept at arms length from whatever shim is needed to 
interface it to the etherboot stuff, I can imagine it can be distributed 
in a way that nobody will be unhappy.

-Andy

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

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

Michael Brown <mb...@fe...> writes:

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

This assumes the appropriate virt_to_bus, bus_to_virt and ioremap calls
are being made.  Otherwise it try reading and writing to the wrong
registers.

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

Plus having code you can change is much more maintainable.

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

Eric