etherboot-developers — Discussion of developer issues

[Etherboot-developers] Re: Dynamic relocation....

[<ebi...@ln...>]

"Jeremy Jackson" <je...@co...> writes:

> I'd like to learn how you are doing this... perhaps I can have a
> peek at your program?
Look at ftp://download.lnxi.com:/pub/src/mkelfImage/reloc_test.tgz
 
> It's just a test case, a Linux usermode program, to be using brk()?

It is just a test case and brk is the guts of malloc.
 
> Have you also considered using segment registers on Intel?
I have.  While that is less code is 
(a) less portable. 
(b) Much more intrusive, when you consider device drivers, and
    other code that knows the physical layout of memory.

The downside of not using segment registers is that you loose the use 
of a register.  But generally that is much less intrusive.

So having a relocatable problem looks like a much less intrusive
change for some things, and the overhead is not too bad.

Eric

[Etherboot-developers] Re: Dynamic relocation....

[Jeremy J. <je...@co...>]

I'd like to learn how you are doing this... perhaps I can have a
peek at your program?

It's just a test case, a Linux usermode program, to be using brk()?

Have you also considered using segment registers on Intel?

Jeremy

----- Original Message -----
From: "Eric W. Biederman" <ebi...@ln...>
To: "LinuxBIOS" <lin...@la...>; "Etherboot Developers"
<eth...@li...>
Sent: Saturday, April 13, 2002 1:41 AM
Subject: Dynamic relocation....


>
> In removing address conflicts in the process of booting, I keep
> wanting to copy the bootloader around, or relocate it in other ways.
>
> So today I sat down and played with the techniques ld.so uses
> to make itself position indpendent.  I took the necessary bits
> out of ld.so stripped them down and came up with a binary with a 2308
> byte footprint (bss included).
>
> All the 2308 byte binary does is call brk to get some more memory
> and then copy itself there, and then it restarts itself.
>
> And the code isn't to painful to write or maintain.  For another 300
> bytes I can add in printf so I can see what I'm doing.
>
> Holler if you want my test program, but generating a shared object
> that can relocate it self definitely works.
>
> I will probably figure out how to deploy this first in memtest86
> as it will cut the program size in half (because it won't have to
> double compile it's code), and make it more flexible.
>
> Oh yeah, and the active code size is for the relocate is just under
> 300 lines of code.  So this is small stuff that is fairly easy to deal
> with.
>
> A linker that does symbol lookup is still spooky but for relocation
> I'm pretty much convinced this is the way to go.
>
> Eric
>

[Etherboot-developers] Dynamic relocation....

[<ebi...@ln...>]

In removing address conflicts in the process of booting, I keep
wanting to copy the bootloader around, or relocate it in other ways. 

So today I sat down and played with the techniques ld.so uses
to make itself position indpendent.  I took the necessary bits
out of ld.so stripped them down and came up with a binary with a 2308  
byte footprint (bss included).

All the 2308 byte binary does is call brk to get some more memory
and then copy itself there, and then it restarts itself.  

And the code isn't to painful to write or maintain.  For another 300
bytes I can add in printf so I can see what I'm doing.

Holler if you want my test program, but generating a shared object
that can relocate it self definitely works.

I will probably figure out how to deploy this first in memtest86
as it will cut the program size in half (because it won't have to
double compile it's code), and make it more flexible.

Oh yeah, and the active code size is for the relocate is just under
300 lines of code.  So this is small stuff that is fairly easy to deal
with.

A linker that does symbol lookup is still spooky but for relocation
I'm pretty much convinced this is the way to go. 

Eric

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

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

>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

Tis done, there's a Perl version of makerom in CVS. Tested it on a make
all, half the lines of code, no noticeable slowdown.

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

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

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

#!/usr/bin/perl
$/ = 0777;
$sum = unpack("%8C*",<>);
print "$sum\n";

And here's a run on a 1 MB file picked at random:

$ ls -l /boot/vmlinuz_2418
-rw-r--r--    1 root     root      1008337 Mar  7 14:02
/boot/vmlinuz_2418
$ time /tmp/c.pl < /boot/vmlinuz_2418
95

real    0m0.027s
user    0m0.020s
sys     0m0.010s

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

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

[<ebi...@ln...>]

ke...@us... writes:

> >Eric, I'm not sure what you mean.  According to
> >
> >    http://www.phoenix.com/PlatSS/PDFs/specs-bbs101.pdf
> >
> >Page 33, The PCI data structure seems only to occur once, and that is 
> >where the vendor and device IDs are.  The PNP expansion header is a 
> >chained structure, but does not have vendor or device information.  Maybe 
> >I don't understand what you mean.
> 
> Apropos of that, I guess it's time to revamp the ROM building
> procedures. The old NIC format is inadequate. I'm thinking of section
> that lists the base images, then a section that lists the derived
> images. The derived images can be made from a base image or another
> derived image by modifying the PCI IDs and checksums in situ.  Another
> program, say modrom, would do this. Makerom and modrom would be
> rewritten in Perl.

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.

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

Eric

Re: [Etherboot-developers] [Fwd: Kingston kne100tx problems]

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

>Anyway the PCI header is defined by the PCI spec not by the BIOS
>vendors, and is used on non-x86 as well.  
>
>It's been a long time since I've read the specs, and I will see if I
>can dig up the information.  One of the things I remember is that it
>is legal to have a ROM that had both x86 code and openbios forth
>byte codes.  I think you can have multiple PCI ID's as well.  Anyway
>more information after I dig.

Semantics matter. It could be that multiple PCI IDs mean the adaptor
board has multiple devices. If that were the case, then the BIOS would
think there were multiple NICs plugged in.

[Etherboot-developers] Re: [Etherboot-users] [Fwd: Kingston kne100tx problems]

[<ebi...@ln...>]

Marty Connor <md...@th...> writes:

> On 4/11/2002 1:56 PM Eric W. Biederman ebi...@ln... wrote:
> >Marty, given that it is legal to have multiple PCI headers do we want
> >to implement that as an option.  It would increase our romsize by a
> >little but it would create romimages that are much easier to work
> >with. 
> 
> Eric, I'm not sure what you mean.  According to
> 
>     http://www.phoenix.com/PlatSS/PDFs/specs-bbs101.pdf
> 
> Page 33, The PCI data structure seems only to occur once, and that is 
> where the vendor and device IDs are.  The PNP expansion header is a 
> chained structure, but does not have vendor or device information.  Maybe 
> I don't understand what you mean.
> 
> We should probably take this to the etherboot-developers list before 
> people think we're geeks or nerds :)

You mean if my conversation on how to do reliable IDE drive initialization
also showed up people would think I was really strange?

Anyway the PCI header is defined by the PCI spec not by the BIOS
vendors, and is used on non-x86 as well.  

It's been a long time since I've read the specs, and I will see if I
can dig up the information.  One of the things I remember is that it
is legal to have a ROM that had both x86 code and openbios forth
byte codes.  I think you can have multiple PCI ID's as well.  Anyway
more information after I dig.

Eric

[Etherboot-developers] NIC file and ROM images

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

>Eric, I'm not sure what you mean.  According to
>
>    http://www.phoenix.com/PlatSS/PDFs/specs-bbs101.pdf
>
>Page 33, The PCI data structure seems only to occur once, and that is 
>where the vendor and device IDs are.  The PNP expansion header is a 
>chained structure, but does not have vendor or device information.  Maybe 
>I don't understand what you mean.

Apropos of that, I guess it's time to revamp the ROM building
procedures. The old NIC format is inadequate. I'm thinking of section
that lists the base images, then a section that lists the derived
images. The derived images can be made from a base image or another
derived image by modifying the PCI IDs and checksums in situ.  Another
program, say modrom, would do this. Makerom and modrom would be
rewritten in Perl.

The NIC file could also generate an include for config.c, so only one
place needs to be changed to support another derived image.

Re: [Etherboot-developers] Prism II (wireless) drivers

[<ebi...@ln...>]

ke...@us... writes:

> >All now in CVS, including the multi-driver ROM stuff.  All builds fine on
> >my system, if anyone hits compile errors with my code please let me know.
> >
> >I tagged the three imported linux-wlan-ng header files with
> >Imported_linux_wlan_ng_0_1_13.  They are verbatim imports containing lots
> >and lots of constants.
> 
> Lovely thanks.
> 
> >I have discovered one minor bug: when I attempt to built a multi-driver
> >ROM containing three drivers (rtl8139, prism2_plx and prism2_pci) it has a
> >tendency to crash and reset the machine at random times.  My best guess
> >is that I am running out of memory and this is causing the resets when the
> >code tries to tread on non-existent RAM.  Any suggestions?
> 
> That's probably the stack colliding with the code. There's not much you
> can do without a major rework of Etherboot to claim more than one 64kB
> segment.

Cleaning up etherboot so it can get out of the way of the booted
image has been on my list for a while anyway.  Plus we have have the DOC
problem, which means in general we should keep etherboot lower in memory
possibly as low in memory as we can.

When I get a chance I will see about cleaning up/testing my work to get etherboot
out of the way of a loaded image.  Once we get that runtime size should not
be a problem, and we should be able to statically claim any address
we want.

I keep thinking of giving the 32bit segments different base addresses
but then etherboot would need to implement virt_to_bus (or
pci_alloc_consistent), and the drivers would all need to be changed.

Any solution for going beyond one 64K segment has the issue that
anything interacting with 16bit code needs to be isolated and looked
at.  Plus I guess there are some small loader issues.  Moving the
decompressor into 32bit code might make things easier. 

On the kernel side I have most of the hard work done, but I'm taking
a breather before I resubmit my patches.

Eric

Re: [Etherboot-developers] Prism II (wireless) drivers

[<ebi...@ln...>]

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

> On 9 Apr 2002, Eric W. Biederman wrote:
> > There is some work in progress to place an MD5 signature on bootable
> > images.  With the spoofabilty of network links somehow that sounds
> > like a desire feature.
> > Thoughts?
> 
> How would the workstation learn what the correct MD5 signature should be?
> Could be sent by the DHCP server but that wouldn't help if the attacker
> had his own DHCP server.

O.k. The base idea is like a checksum.  You have the bytes
to compute it over and the checksum so you can verify the two.

Beyond that I believe the MD5 hash was encrypted, in which case the node
would have an encryption key it would use to decrypt the hash before
verification.  Possibly doing the whole public/private key pair thing.
I am only roughly familiar with the idea.

The people doing this are part of a small university project on trusted,
booting.  If this looks interesting/useful I'll try to drag them into
the discussion.

Eric

Re: [Etherboot-developers] Prism II (wireless) drivers

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

>All now in CVS, including the multi-driver ROM stuff.  All builds fine on
>my system, if anyone hits compile errors with my code please let me know.
>
>I tagged the three imported linux-wlan-ng header files with
>Imported_linux_wlan_ng_0_1_13.  They are verbatim imports containing lots
>and lots of constants.

Lovely thanks.

>I have discovered one minor bug: when I attempt to built a multi-driver
>ROM containing three drivers (rtl8139, prism2_plx and prism2_pci) it has a
>tendency to crash and reset the machine at random times.  My best guess
>is that I am running out of memory and this is causing the resets when the
>code tries to tread on non-existent RAM.  Any suggestions?

That's probably the stack colliding with the code. There's not much you
can do without a major rework of Etherboot to claim more than one 64kB
segment.

Re: [Etherboot-developers] patch for 3c90x.c

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

>Apparently some 905s have their MAC address starting at offset 0x10 only
>in the EEPROM, while some have them at both 0 and 0x10. So Etherboot
>will not work on the former. The Linux driver always uses the one at
>0x10, so we do the same. Michael Rendell sent in this fix. It's in CVS
>now.

Sorry, that should be 10, not 0x10, but the patch is correct. It's a
worry when you start counting in everyday life in hex. :-)

[Etherboot-developers] patch for 3c90x.c

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

Apparently some 905s have their MAC address starting at offset 0x10 only
in the EEPROM, while some have them at both 0 and 0x10. So Etherboot
will not work on the former. The Linux driver always uses the one at
0x10, so we do the same. Michael Rendell sent in this fix. It's in CVS
now.

Re: [Etherboot-developers] Prism II (wireless) drivers

[Marty C. <md...@th...>]

On 4/9/2002 8:53 PM Michael Brown mb...@fe... wrote:
>I am new to this list.  I have written Etherboot drivers for the
>Prism2/2.5 wireless (IEEE802.11b) chipsets.  These work with the three
>cards I have available:
>  Netgear MA301/MA401 (PCMCIA wireless card with PLX-based PCI adaptor)
>  ActionTec HWP01170 (PCI wireless card, Prism2.5)
>  DLink DWL-520 (PCI wireless card, Prism2.5)

Great work!  This is something that people at LinuxWorld Expos have been 
asking about for for some time.  Thanks ever so much for your time and 
effort.

This may also make it easier to support some laptop wireless PCMCIA 
adapters.  The problem of initializing the PCI bridge chips in laptops 
(much variation) still remains, but maybe we can do some of the common 
cases.  Once the bridge has been initialized and one can talk to the 
adapter, driver writing becomes much easier.

Hmmmm, wireless Etherbooting....
You know of course that this means we'll have to cart *even more* demo 
hardware to LinuxWorld Expo San Francisco in August.  
Drat!! :) :) :)

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: md...@th...
    Web: http://www.thinguin.org/

Re: [Etherboot-developers] Prism II (wireless) drivers

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

>> For now the 5.1 branch is dead. 5.0.6 is the correct version
>> to be working against.
>
>What's the story behind this?  I assumed 5.1 was meant to be the
>development branch.

Because of the relatively small number of developers at the moment,
Etherboot can't really support two full development streams. So unlike
the Linux kernel effort, the minor number means something slightly
different; the odd numbered branch is used for testing occasional
controversial or high-impact changes. I realise this causes some
confusion when people try to fetch that branch. What I will do in future
is remove the development release from the release area, when the
production release supercedes it.  The alternative is to have yet
another convention for naming: e.g. 5.0.7pre2, which I'm not happy with.

>BTW, I have an EPROM programmer and am willing to burn EPROMs for anyone
>in the UK (for a small fee to cover costs).

Marty and and I are discussing setting up a web page listing a
grass-roots list of people who will burn EPROMs for cost plus. Stay
tuned.

Re: [Etherboot-developers] Prism II (wireless) drivers

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

On 9 Apr 2002, Eric W. Biederman wrote:
> > I've been using 5.0.6 - haven't tried
> > with 5.1 yet (5.1 crashed the first time I tried it, 5.0.6 worked so I
> > started developing with the one that worked).
> For now the 5.1 branch is dead. 5.0.6 is the correct version
> to be working against.

What's the story behind this?  I assumed 5.1 was meant to be the
development branch.

> > As you might be able to guess, my aim is to have a BootROM in an RTL8139
> > card that is capable of booting the machine via either a cable plugged in
> > to the RTL8139 or, if that fails, via a wireless link using a Prism2 card.
> Cool.
> > It works! :-)
> Congratulations!
> There is some work in progress to place an MD5 signature on bootable
> images.  With the spoofabilty of network links somehow that sounds
> like a desire feature.
> Thoughts?

How would the workstation learn what the correct MD5 signature should be?
Could be sent by the DHCP server but that wouldn't help if the attacker
had his own DHCP server.


BTW, I have an EPROM programmer and am willing to burn EPROMs for anyone
in the UK (for a small fee to cover costs).

Michael

Re: [Etherboot-developers] Prism II (wireless) drivers

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

On Wed, 10 Apr 2002, Ken Yap wrote:
> >I am new to this list.  I have written Etherboot drivers for the
> >Prism2/2.5 wireless (IEEE802.11b) chipsets.  These work with the three
> >cards I have available:
> >  Netgear MA301/MA401 (PCMCIA wireless card with PLX-based PCI adaptor)
> >  ActionTec HWP01170 (PCI wireless card, Prism2.5)
> >  DLink DWL-520 (PCI wireless card, Prism2.5)
> >To whom should I send the code?  I've been using 5.0.6 - haven't tried
> >with 5.1 yet (5.1 crashed the first time I tried it, 5.0.6 worked so I
> >started developing with the one that worked).
> Drool...
> Post them on this list if not large, or a URL if large. I can also make
> you a project developer at Sourceforge, register as a user then tell me
> your ID.

My Sourceforge ID is mcb30.  There's about 4,600 lines of code (3,700 of
which is header files borrowed from the linux-wlan-ng project), so I'll
check them in via CVS rather than posting to the list.

Thanks,

Michael

Re: [Etherboot-developers] Prism II (wireless) drivers

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

>I am new to this list.  I have written Etherboot drivers for the
>Prism2/2.5 wireless (IEEE802.11b) chipsets.  These work with the three
>cards I have available:
>
>  Netgear MA301/MA401 (PCMCIA wireless card with PLX-based PCI adaptor)
>  ActionTec HWP01170 (PCI wireless card, Prism2.5)
>  DLink DWL-520 (PCI wireless card, Prism2.5)
>
>To whom should I send the code?  I've been using 5.0.6 - haven't tried
>with 5.1 yet (5.1 crashed the first time I tried it, 5.0.6 worked so I
>started developing with the one that worked).

Drool...

Post them on this list if not large, or a URL if large. I can also make
you a project developer at Sourceforge, register as a user then tell me
your ID.

Thanks!

Re: [Etherboot-developers] Prism II (wireless) drivers

[<ebi...@ln...>]

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

> Greetings,
> 
> I am new to this list.  I have written Etherboot drivers for the
> Prism2/2.5 wireless (IEEE802.11b) chipsets.  These work with the three
> cards I have available:
> 
>   Netgear MA301/MA401 (PCMCIA wireless card with PLX-based PCI adaptor)
>   ActionTec HWP01170 (PCI wireless card, Prism2.5)
>   DLink DWL-520 (PCI wireless card, Prism2.5)
>
> To whom should I send the code?  

This list, or at least a pointer to it.  It is also possible
to get setup on sourceforge.

> I've been using 5.0.6 - haven't tried
> with 5.1 yet (5.1 crashed the first time I tried it, 5.0.6 worked so I
> started developing with the one that worked).

For now the 5.1 branch is dead. 5.0.6 is the correct version
to be working against.

> I'm also working on a small patch to genrules.pl to make it easier to
> build BootROMs that support multiple drivers.  As a related item, I've
> added a few lines to rtl8139_probe that detect when the network cable is
> unplugged, print a warning message and then abort (thereby allowing
> Etherboot to continue on to trying other cards).

Nice.
 
> As you might be able to guess, my aim is to have a BootROM in an RTL8139
> card that is capable of booting the machine via either a cable plugged in
> to the RTL8139 or, if that fails, via a wireless link using a Prism2 card.

Cool.

> It works! :-)

Congratulations!

There is some work in progress to place an MD5 signature on bootable
images.  With the spoofabilty of network links somehow that sounds
like a desire feature.

Thoughts?

Eric

[Etherboot-developers] Prism II (wireless) drivers

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

Greetings,

I am new to this list.  I have written Etherboot drivers for the
Prism2/2.5 wireless (IEEE802.11b) chipsets.  These work with the three
cards I have available:

  Netgear MA301/MA401 (PCMCIA wireless card with PLX-based PCI adaptor)
  ActionTec HWP01170 (PCI wireless card, Prism2.5)
  DLink DWL-520 (PCI wireless card, Prism2.5)

To whom should I send the code?  I've been using 5.0.6 - haven't tried
with 5.1 yet (5.1 crashed the first time I tried it, 5.0.6 worked so I
started developing with the one that worked).

I'm also working on a small patch to genrules.pl to make it easier to
build BootROMs that support multiple drivers.  As a related item, I've
added a few lines to rtl8139_probe that detect when the network cable is
unplugged, print a warning message and then abort (thereby allowing
Etherboot to continue on to trying other cards).

As you might be able to guess, my aim is to have a BootROM in an RTL8139
card that is capable of booting the machine via either a cable plugged in
to the RTL8139 or, if that fails, via a wireless link using a Prism2 card.
It works! :-)

Michael

Re: [Etherboot-developers] ADMTek Comet 683 (fwd)

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

Checked into CVS.

------- Forwarded Message

Date: Sat, 6 Apr 2002 13:38:42 +0200
From: RISKO Gergely <ri...@at...>
To: ke...@us...
Subject: Re: [Etherboot-developers] ADMTek Comet 683 (fwd)

Hello!

Sorry for the late response, I only now had got time to probe this out
(amd comet 983 with your code). In the released 5.0.6 I found it doesn't
work, but only because two simple and silly typos:

diff -ur etherboot-5.0.6/src/config.c etherboot-5.0.6.good/src/config.c
- --- etherboot-5.0.6/src/config.c	Fri Mar 15 15:25:55 2002
+++ etherboot-5.0.6.good/src/config.c	Sat Apr  6 13:29:27 2002
@@ -193,7 +193,7 @@
 		"ADMtek Centaur-P" },
 	{ PCI_VENDOR_ID_ADMTEK, 0x0981,
 		"ADMtek AN981 Comet" },
-	{ PCI_VENDOR_ID_MACRONIX, 0x1216,
+	{ PCI_VENDOR_ID_SMC_1211, 0x1216,
 		"ADMTek AN983 Comet" },
         { 0x125B, 0x1400,
 		"ASIX AX88140"},
diff -ur etherboot-5.0.6/src/tulip.c etherboot-5.0.6.good/src/tulip.c
--- etherboot-5.0.6/src/tulip.c	Tue Feb 19 06:48:26 2002
+++ etherboot-5.0.6.good/src/tulip.c	Sat Apr  6 13:31:04 2002
@@ -213,7 +213,7 @@
     { "ADMtek AN981 Comet", { 0x09811317, 0xffffffff, 0, 0, 0, 0 },
       TULIP_IOTYPE, 256, COMET },
     { "ADMTek AN983 Comet", { 0x12161113, 0xffffffff, 0, 0, 0, 0 },
-      TULIP_IOTYPE, 256, MX98715 },
+      TULIP_IOTYPE, 256, COMET },
     { "ADMtek Centaur-P", { 0x09851317, 0xffffffff, 0, 0, 0, 0 },
       TULIP_IOTYPE, 256, COMET },
     { "ADMtek Centaur-C", { 0x19851317, 0xffffffff, 0, 0, 0, 0 },

The first change is needed, because it is 1113 -> smc_1211. The second
is also seems to need, because if it leaved with MX98715, it can't found
the dhcp server.

Please change this in CVS, so the next release will be good for this
card also.

Thanks,
Gergely

------- End of Forwarded Message

Re: [Etherboot-developers] [CFT][RFC] Linux kernel boot cleanup.

[<ebi...@ln...>]

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

> >There are a couple of approaches to this problem.
> >1) mknbi still works.  All of my changes are backwards compatible.
> >   mknbi can now (potentially) do a better job as higher quality
> >   information is available, but from that perspective it is the only
> >   significant change. 
> >
> >   In particular my current ELF images will not work on a system
> >   with a DOC millenium.  
> 
> A interim solution might be to teach mkelf-linux about the new kernel
> Elf format. It should be transparent, the Perl code would detect the new
> format and do the right thing. 

Since all you have to do is strip a ~= 333 byte header off to get a 
bzImage that should be simple.  

> It would accept a kernel Elf and spit out
> a netbootable Elf, the only difference being that a third stage stub
> gets control first to parse the DHCP options and inject the relevant
> ones into the command line. And so long as the kernel cannot handle
> appended initrds, the stub would copy the initrd to the top of memory.
> 
> When the code goes into 2.5 I might hack mkelf-linux.

Right there is no point doing anything before then.
 
> Users who don't need to extract options from DHCP or append initrds
> could just use the kernel Elfs directly.

Correct.
 
> >2) We can teach the kernel about etherboot specifically and let it
> >   pick the command line out the dhcp options etherboots passes.
> 
> Maybe at some later stage when the stub code stabilises it could become
> part of the kernel build. But this is not a step to take lightly, one
> would have to convince the kernel team to accept it and then changes are
> more hassle to make as it's tied to the kernel release cycle.

Agreed.  
 
> >3) We can teach the kernel another bootloader && kernel independent
> >   protocol for passing command line information.  And have etherboot
> >   use that.
> 
> Etherboot could parse the DHCP reply itself and modify the command line,
> but I not keen on the idea of a significant amount of code in Etherboot
> that knows about the OS image format. 

I wasn't even thinking that.  I have some fairly generic code in
LinuxBIOS that says here is a command line.  Image make of it what you
will.  This is something that could be done in the generic ELF
support.   I preserve all registers at kernel entry so finding
something like this would be straight forward.

A command line is a generally useful concept so treating it specially
has some merit.
 
> It would put more pressure on the
> footprint, and would be wasted space when Etherboot is used to load
> other images.  Saving the space with conditional compilation might give
> rise to problem reports from users who had not configured it in. At
> least with the current config, both tagged and Elf are supported by
> default.  And it would be hard to make changes, once the Etherboot code
> has gone into ROMs. At least with mkelf-linux you can still tweak things
> later.

I totally agree that there is a use for a mkelf-linux that tweaks
things and implements policy.  With my changes this just becomes
easier.  Especially with the 32bit kernel enttry point, and the work
to find the lowest possible ramdisk address.  So the ramdisk will
not need to be relocated at runtime.

If you can take BIOS calls out of the picture things should get a
little easier :)

Eric

Re: [Etherboot-developers] [CFT][RFC] Linux kernel boot cleanup.

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

>There are a couple of approaches to this problem.
>1) mknbi still works.  All of my changes are backwards compatible.
>   mknbi can now (potentially) do a better job as higher quality
>   information is available, but from that perspective it is the only
>   significant change. 
>
>   In particular my current ELF images will not work on a system
>   with a DOC millenium.  

A interim solution might be to teach mkelf-linux about the new kernel
Elf format. It should be transparent, the Perl code would detect the new
format and do the right thing. It would accept a kernel Elf and spit out
a netbootable Elf, the only difference being that a third stage stub
gets control first to parse the DHCP options and inject the relevant
ones into the command line. And so long as the kernel cannot handle
appended initrds, the stub would copy the initrd to the top of memory.

When the code goes into 2.5 I might hack mkelf-linux.

Users who don't need to extract options from DHCP or append initrds
could just use the kernel Elfs directly.

>2) We can teach the kernel about etherboot specifically and let it
>   pick the command line out the dhcp options etherboots passes.

Maybe at some later stage when the stub code stabilises it could become
part of the kernel build. But this is not a step to take lightly, one
would have to convince the kernel team to accept it and then changes are
more hassle to make as it's tied to the kernel release cycle.

>3) We can teach the kernel another bootloader && kernel independent
>   protocol for passing command line information.  And have etherboot
>   use that.

Etherboot could parse the DHCP reply itself and modify the command line,
but I not keen on the idea of a significant amount of code in Etherboot
that knows about the OS image format. It would put more pressure on the
footprint, and would be wasted space when Etherboot is used to load
other images.  Saving the space with conditional compilation might give
rise to problem reports from users who had not configured it in. At
least with the current config, both tagged and Elf are supported by
default.  And it would be hard to make changes, once the Etherboot code
has gone into ROMs. At least with mkelf-linux you can still tweak things
later.

>I don't know which is the best route to go.  All I know for certain
>is that.
>A)  I am doing the heavy lifting to so the kernel supports things
>    like this.   A few more tweaks and I can place a ramdisk at a fixed
>    address in ram.
>
>B)  It really makes sense to generate an ELF image that works
>    in 90% of the circumstances.  Even if it isn't optimal.
>
>My hunch is that the optimal method is to build a smart dhcp/tftp
>server that builds whatever file your kernel needs on the fly.

This could be yet another technique in the armory and could be used in
quite innovative ways not limited to booting OSes. Anybody want to hack
an existing tftpd? E.g.  tftp-hpa or atftp. My idea is a tftpd that can
accept a filename which is actually a spec file for putting an image
together. Sort of like dynamic web pages.

Re: [Etherboot-developers] [CFT][RFC] Linux kernel boot cleanup.

[<ebi...@ln...>]

<ja...@Mc...> writes:

> Eric,
> 
> I see you've added the ability to add kernel command line
> args at compile time, and it looks like there will be a
> tool to update those command line args, but I can't really tell
> from your description if you've kept the ability to pass
> kernel command line args via dhcp options.
> 
> Over at LTSP, we really like the ability to set those
> args in dhcpd.conf.  That way, we can use the same kernel
> for all of the workstations, and the differences are all
> maintained in the dhcpd.conf file.

Which is a sensible thing to do.  In this case the kernel never has
directly understood etherboot, or a command line passed as dhcp
options I haven't added that capability.  I have not used the
capability to pass a command line via dhcp as the couple of times I
tried it a long time ago it didn't work.  And then I built up the
infrastructure to make assmebling a kernel, a command line, and a
ramdisk into a network bootable image easy.  

It should be just a couple of hours to code.  My goal has been to
lower the barrier to doing a lot of this. 

There are a couple of approaches to this problem.
1) mknbi still works.  All of my changes are backwards compatible.
   mknbi can now (potentially) do a better job as higher quality
   information is available, but from that perspective it is the only
   significant change. 

   In particular my current ELF images will not work on a system
   with a DOC millenium.  

2) We can teach the kernel about etherboot specifically and let it
   pick the command line out the dhcp options etherboots passes.

3) We can teach the kernel another bootloader && kernel independent
   protocol for passing command line information.  And have etherboot
   use that.

I don't know which is the best route to go.  All I know for certain
is that.
A)  I am doing the heavy lifting to so the kernel supports things
    like this.   A few more tweaks and I can place a ramdisk at a fixed
    address in ram.

B)  It really makes sense to generate an ELF image that works
    in 90% of the circumstances.  Even if it isn't optimal.

My hunch is that the optimal method is to build a smart dhcp/tftp
server that builds whatever file your kernel needs on the fly.

Eric