etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] ISCSI Boot Support or ISCSI boot floppy image?

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

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

> >methods are setting up a RIS server (ugly) or somehow try to get the RIS
> >boot disk tagged for etherboot (ugly, especially considering the likely
> >lack of support for my NIC, the sis900). =20
> 
> Have you looked? There is a sis900 driver.
> 
> >Is this too far outside to purview of the etherboot project to be done?=20
> >Etherboot would then have to maintain some process in memory to be able
> >to communicate with the iscsi server while the machine was running.
> 
> Etherboot gets displaced by whatever it's loading so it cannot "maintain
> some process in memory".
> 
> I don't know how feasible it is to boot off iscsi. It may require a more
> complex network stack, i.e. TCP, than Etherboot has.

We now have the proof of concept tcp stack now and at first glance it
does not look two hideous.

We do have an infrastructure for disk drivers now so running iscsi over
that would probably work.

But in the case of Etherboot I would really recommend something
that takes the Windows preinstallation environment and wraps the whole
thing up into an ELF executable and give that to etherboot.  Unless it
has really nasty dependencies that should work fairly cleanly.

Eric

Re: [Etherboot-developers] Re: 3c900-tpo hang after DHCPOFFER

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

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

> >Is anyone else getting the feeling we might want to output a message 
> >saying:
> >
> >    DHCP response received from xx.xx.xx.xx but no filename specified, 
> >ignored.
> 
> I'm in two minds about this. On one hand it might help show the problem,
> but on the other hand it might take Etherboot's attention away from an
> offer which is usable, plus it might get annoying in networks where it's
> expected that there will be bogus offers. There are a whole bunch of
> difficulties that must be overcome in setting up a diskless boot, such
> as getting DHCP right, TFTP right, etc and this is only one problem. I'm
> inclined to think a better newbie document would do more good. Perhaps
> we should collaborate with LTSP in writing such a document which can be
> published by both projects.

One thing we can do is instead of printing a dot we can print
another character like 'D'.  Not enough text to cause us problems
but enough to indicate that etherboot has received a certain
type of packet.

Eric

Re: [Etherboot-developers] ANNOUNCE: limited tagged image support for grub (0.93)

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

Hans-Peter Jansen <hp...@ur...> writes:

> Dear Ken,
> 
> On Friday 01 August 2003 11:35, Ken Yap wrote:
> 
> > In 5.1 and above menus are devolved to a loadable image which uses
> > the redirection capability of Etherboot to specify which image to
> > load. I didn't feel that menus should be part of the core
> > functionality of Etherboot, mainly because of the issue of updating
> > ROMs, which is slower than updating disk images. Have a look at
> 
> I'm 100% fine with this decision.
> 
> > mkelf-nfl, which doesn't take the entries from the DHCP packet and
> > has no limitations on menu entries due to packet size.
> 
> Yep, I've looked at it. In general, if I need to load some secondary 
> menuing system, it does't matter, if this is 10L or 166K. But when I'm
> forced to use a pxe loader, etherboot >= 5.1 isn't an option anymore, 
> since despite of the pxe target, it doesn't provide any surplus value 
> anymore, no, better than that, it creates a nice useless boot loop.
> Options: use 5.0 with menus enabled, or go the grub way.

I have no problem at all using 5.1 with pxe.  All it takes is a single
if statement in the dhcpv3 configuration file to distinguish between
etherboot and pxe.
 
> The nice thing in grub from developers pov is the approach to provide 
> some limited posix like f* functions to operate on files (one at a 
> time), which seems to work fine with tftp, too. 

I am amazed you are looking at the grub code and not going blind...
I guess if you are not digging into it too deeply the code looks o.k.

> > While I have no philosophical objections to Etherboot code being used
> > in GRUB, and certainly no objections on licence grounds---it's GPL
> > after all---I do not want Etherboot to evolve towards becoming a disk
> > bootloader and certainly not splash screens and all that.  We have
> > enough work as it is trying to keep up with ideas in network booting.
> > If however these capabilities can be provided by a general mechanism,
> > or Etherboot can be invoked as a subsystem to do network booting,
> > then I'll listen to the proposal. In short, like the kernel
> > developers, I like to push bells and whistles into user space; and I
> > prefer interoperability to feature bloat.
> 
> That's definitely a good thing. Put the essential diskless boot stuff 
> into the flashes, and daisy chain/delegate everything more complex
> to something else. BTW: Did you noticed the huge amount of (old) 
> etherboot code in grub? 

The old etherboot drivers in grub are known about.
 
> This is one thing, I didn't like in this scenario: the repetition of 
> device drivers in the different loaders. Much cooler would be to 
> install and use an interrupt vector for basic nic device operations, 
> such that chained boot loaders are able to use one set of device 
> drivers. That would spare me the now necessary port of the current 
> etherboot drivers to grub to not loose the track. I hope, you don't 
> have any objections.

Chained drivers are so wrong.   The reason they are wrong is very
simple, software on a ROM is never updated.  As long as the software
on the ROM is good enough to do it's one thing that is all that is
required of it.  

As for porting please notice that the 5.2 drivers are much easier to
host.

Now if you want something really fun that saves all of the work
of replicating drivers.  I can hook you up with a kernel with kexec
support and you can use all of it's drivers and boot anything you
want. 

Eric

Re: [Etherboot-developers] Re: TCP and HTTP support

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

Markus Gutschke wrote:
> latter is the problem. I know that none of my packets are large, so I 
> guess I could just shrink this buffer (576 would make a lot of sense), 
> and impose a maximum segment size for outgoing TCP packets.

I just tested, and the code works correctly, even if I shrink the buffer 
size to something as ridiculous as just 50 bytes. Of course, now, the 
"HTTP GET" request is split across three or four TCP packets ;-) 
Realistic sizes should probably be in the ballpark region of at least 
128 bytes.


Markus

Re: TCP and HTTP support (Was: [Etherboot-developers] 3c900-tpo hang after DHCPOFFER)

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

Eric W. Biederman wrote:
> A couple of interesting things to find out are:
> 1) How much does it increase the size of a rom?

A quick inspection of the object files suggests that selecting 
DOWNLOAD_PROTO_HTTP increases the image size by about 2kB.

> 2) How well does it the tcp stack work in a congested environment.
>    - Does it play badly with other simultaneous tcp connections?
>    - Does the implemented window scaling work well.

I don't have much in the form of test environments. Hopefully, somebody 
else can take a stab at testing the code in more real-life situations.

> 3) Are alignment considerations that need to be taken care of.

??? Can you elaborate what you were thinking of?


Markus

Re: [Etherboot-developers] List of NICs by popularity

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

Alastair McKinstry <mck...@co...> writes:

> Hi,
> 
> I'm a debian developer working on the next-generation Debian Installer. 
> For people still using floppies + net to install from, we need to make 
> all the NIC driver modules for Linux available on floppies - this will
> take several floppies, and wish to prioritise them according to how
> popular each of the NICs are.
> 
> It appears that downloads from the rom-o-matic.org site would be a good
> source of nic popularity data in linux. Is such a list available?

Last I checked it was possible to compile all of the pci nic drivers 
into one kernel and still fit it onto a floppy.

Eric

Re: [Etherboot-developers] editing release announcement for 5.2

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

ke...@et... writes:

> Ok, so far no showstoppers in sight. I'll need to make up a release
> announcement. It'll just be the major improvements in 5.2 in point form.
> However so much has gone in that I fear I may have forgotten something.
> So here's what I have and if I missed something, let me know and I'll
> put it in.
> 
> Major improvements in 5.2:
> 
> + Now multiplatform, ported to Itanium and Hammer.
> 
> + Restruture of code: separation of platform independent and
> dependent parts. Decompressor now in C and platform independent.

Hmm...  Last I looked there was a decompressor in C that you could
use, for testing etc.  But the one used was still in assembly so it
could be insanely small.

> + Relocation to top of memory, removes the 45 kB limit on footprint.

My boxes with > 4GB don't seem to agree but close enough.
 
> + Support for multicasting (in selected drivers)
> 
> + Simple disk and floppy drivers (for loading ELF images)

   a.out and nbi images should work as well. In fact everything except
   legacy boot sectors should work.  Only ELF images support
   being scattered all over the disk, but that is because ELF images
   support having holes in them.

+ Simple disk and floppy drivers (for loading normal Etherboot images)
 
> + Generalised URLs for load files.
> 
> + New drivers: Broadcom TG3, Sundance, TLAN, Prism wireless NICs.
> 
> + Encapsulated PCI IDs.
> 
> + UNDI support

--  We need to say that we are using UNDI as a driver not that
    we export the UNDI interface.
> 
> + Better method for compilation of PCI ID table.
> 
> + Lots of bug fixes for drivers, symlink support for NFS, experimental
> support for signed boot files.
> 
> + Rewrite of documentation and web pages.
> 
> + ???

  + Image suffixes changed.

Eric

Re: TCP and HTTP support (Was: [Etherboot-developers] 3c900-tpo hang after DHCPOFFER)

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

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

> Ken Yap wrote:
> >>Dig all you want, but I still like my HTTP idea :)
> > So do I but I think it should be done by writing a server side TFTP to
> > HTTP proxy. I might knock up a Perl version sometime. That might scare
> > some of you into doing it first with a more readable language. :-)
> 
> I always thought that HTTP couldn't be that difficult to do, if it was strictly
> limited to the small subset that Etherboot needs. 15 hours later, I have the
> proof ;-)
> 
> The attached patch is against 5.0.11, as that was easiest to test with; I might
> try to port it next week at LinuxExpo, if I can find a more up-to-date test
> environment.
> 
> Now, whether this is really a good idea, and whether it should go into
> Etherboot, is a a completely different question. I leave that up to Ken.

A couple of interesting things to find out are:
1) How much does it increase the size of a rom?
2) How well does it the tcp stack work in a congested environment.
   - Does it play badly with other simultaneous tcp connections?
   - Does the implemented window scaling work well.
3) Are alignment considerations that need to be taken care of.

Eric

Re: [Etherboot-developers] Re: TCP and HTTP support

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

Ken Yap wrote:
> I won't accept it for 5.0, it's too large a change.

Agreed. I hadn't really expected it to go in that version of the tree; 
it was just easier to test with for me.

> I'll accept for 5.3

Sweet ;-)

> if you patch against 5.3.0 (5.1.10 is close enough) and remove all the
> large buffers from the stack

I had been wondering how to do that best. I don't really need much 
space. The only large structures are the ones that hold the current HTTP 
header/state (about 100 bytes), any URL found in redirects (80 bytes), 
and the buffer used for assembling outgoing packets (1500 bytes). The 
latter is the problem. I know that none of my packets are large, so I 
guess I could just shrink this buffer (576 would make a lot of sense), 
and impose a maximum segment size for outgoing TCP packets. Would that 
be acceptable?

Alternatively, I could allocate the buffer in the BSS.

What is the prefered solution?


> and of course it's #ifdefed so that there's
> no cost for anybody not choosing to use TCP. There's only a 4kB stack
> available.

I'll try to do these changes once we have set up some machines at LinuxExpo.


Markus

Re: [Etherboot-developers] List of NICs by popularity

[<ke...@et...>]

>It appears that downloads from the rom-o-matic.org site would be a good
>source of nic popularity data in linux. Is such a list available?

It may or may not be representative. The Etherboot drivers are a subset
of the Linux ones. Also it tends to be skewed by the kind of NICs that
used with LTSP (probably the most frequent use).

Anyway there is a stats page whose URL you can ask Marty for which lists
the raw URLs requested. He may be busy with LWE and not answer
immediately.

[Etherboot-developers] List of NICs by popularity

[Alastair M. <mck...@co...>]

Hi,

I'm a debian developer working on the next-generation Debian Installer. 
For people still using floppies + net to install from, we need to make 
all the NIC driver modules for Linux available on floppies - this will
take several floppies, and wish to prioritise them according to how
popular each of the NICs are.

It appears that downloads from the rom-o-matic.org site would be a good
source of nic popularity data in linux. Is such a list available?

Regards,
Alastair

-- 
Alastair McKinstry <mck...@de...>
GPG Key fingerprint = 9E64 E714 8E08 81F9 F3DC  1020 FA8E 3790 9051 38F4

He that would make his own liberty secure must guard even his enemy from
oppression; for if he violates this duty he establishes a precedent that
will reach to himself.

- --Thomas Paine

[Etherboot-developers] Re: TCP and HTTP support

[<ke...@et...>]

>I always thought that HTTP couldn't be that difficult to do, if it was 
>strictly limited to the small subset that Etherboot needs. 15 hours 
>later, I have the proof ;-)
>
>The attached patch is against 5.0.11, as that was easiest to test with; 
>I might try to port it next week at LinuxExpo, if I can find a more 
>up-to-date test environment.
>
>Now, whether this is really a good idea, and whether it should go into 
>Etherboot, is a a completely different question. I leave that up to Ken.

I won't accept it for 5.0, it's too large a change.  I'll accept for 5.3
if you patch against 5.3.0 (5.1.10 is close enough) and remove all the
large buffers from the stack and of course it's #ifdefed so that there's
no cost for anybody not choosing to use TCP. There's only a 4kB stack
available.

Re: TCP and HTTP support (Was: [Etherboot-developers] 3c900-tpo hang after DHCPOFFER)

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

Markus Gutschke wrote:
> I always thought that HTTP couldn't be that difficult to do, if it was 
> strictly limited to the small subset that Etherboot needs. 15 hours 
> later, I have the proof ;-)

Oh, and if you want to play with it, make sure that you use your 
server's IP address rather than its DNS name in the URL. I haven't felt 
sufficiently crazy, yet, to attempt implementing a resolver library in 
Etherboot.

The client does understand passing port numbers in the URL, and it has 
very limited support for HTTP redirects -- as long as you redirect to 
the same machine, you are OK.


Markus

TCP and HTTP support (Was: [Etherboot-developers] 3c900-tpo hang after DHCPOFFER)

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

Ken Yap wrote:
>>Dig all you want, but I still like my HTTP idea :)
> 
> So do I but I think it should be done by writing a server side TFTP to
> HTTP proxy. I might knock up a Perl version sometime. That might scare
> some of you into doing it first with a more readable language. :-)

I always thought that HTTP couldn't be that difficult to do, if it was 
strictly limited to the small subset that Etherboot needs. 15 hours 
later, I have the proof ;-)

The attached patch is against 5.0.11, as that was easiest to test with; 
I might try to port it next week at LinuxExpo, if I can find a more 
up-to-date test environment.

Now, whether this is really a good idea, and whether it should go into 
Etherboot, is a a completely different question. I leave that up to Ken.



Markus

[Etherboot-developers] editing release announcement for 5.2

[<ke...@et...>]

Ok, so far no showstoppers in sight. I'll need to make up a release
announcement. It'll just be the major improvements in 5.2 in point form.
However so much has gone in that I fear I may have forgotten something.
So here's what I have and if I missed something, let me know and I'll
put it in.

Major improvements in 5.2:

+ Now multiplatform, ported to Itanium and Hammer.

+ Restruture of code: separation of platform independent and
dependent parts. Decompressor now in C and platform independent.

+ Relocation to top of memory, removes the 45 kB limit on footprint.

+ Support for multicasting (in selected drivers)

+ Simple disk and floppy drivers (for loading ELF images)

+ Generalised URLs for load files.

+ New drivers: Broadcom TG3, Sundance, TLAN, Prism wireless NICs.

+ Encapsulated PCI IDs.

+ UNDI support

+ Better method for compilation of PCI ID table.

+ Lots of bug fixes for drivers, symlink support for NFS, experimental
support for signed boot files.

+ Rewrite of documentation and web pages.

+ ???

Re: [Etherboot-developers] ANNOUNCE: limited tagged image support for grub (0.93)

[Hans-Peter J. <hp...@ur...>]

Dear Ken,

On Friday 01 August 2003 11:35, Ken Yap wrote:

> In 5.1 and above menus are devolved to a loadable image which uses
> the redirection capability of Etherboot to specify which image to
> load. I didn't feel that menus should be part of the core
> functionality of Etherboot, mainly because of the issue of updating
> ROMs, which is slower than updating disk images. Have a look at

I'm 100% fine with this decision.

> mkelf-nfl, which doesn't take the entries from the DHCP packet and
> has no limitations on menu entries due to packet size.

Yep, I've looked at it. In general, if I need to load some secondary 
menuing system, it does't matter, if this is 10L or 166K. But when I'm
forced to use a pxe loader, etherboot >= 5.1 isn't an option anymore, 
since despite of the pxe target, it doesn't provide any surplus value 
anymore, no, better than that, it creates a nice useless boot loop.
Options: use 5.0 with menus enabled, or go the grub way.

The nice thing in grub from developers pov is the approach to provide 
some limited posix like f* functions to operate on files (one at a 
time), which seems to work fine with tftp, too. 

> While I have no philosophical objections to Etherboot code being used
> in GRUB, and certainly no objections on licence grounds---it's GPL
> after all---I do not want Etherboot to evolve towards becoming a disk
> bootloader and certainly not splash screens and all that.  We have
> enough work as it is trying to keep up with ideas in network booting.
> If however these capabilities can be provided by a general mechanism,
> or Etherboot can be invoked as a subsystem to do network booting,
> then I'll listen to the proposal. In short, like the kernel
> developers, I like to push bells and whistles into user space; and I
> prefer interoperability to feature bloat.

That's definitely a good thing. Put the essential diskless boot stuff 
into the flashes, and daisy chain/delegate everything more complex
to something else. BTW: Did you noticed the huge amount of (old) 
etherboot code in grub? 

This is one thing, I didn't like in this scenario: the repetition of 
device drivers in the different loaders. Much cooler would be to 
install and use an interrupt vector for basic nic device operations, 
such that chained boot loaders are able to use one set of device 
drivers. That would spare me the now necessary port of the current 
etherboot drivers to grub to not loose the track. I hope, you don't 
have any objections.

Kind regards,
Pete

RE: [Etherboot-developers] eb 5.0.10 console_putc clobbers %cl

[Timothy L. <tl...@ro...>]

> hexdump(char *msg, char *mem, unsigned int len): what the name implies
> regdump(): show the content of i386 cpu registers

Correct me if I am wrong, but I believe that hexdump is currently in
5.1.  
 
> They where very helpful for me, and I bet, other developers would
profit
> from them, too. What do you think?

hexdump has been useful to me when I have used it.  I really hope that
regdump never becomes useful to me! ;-)

Tim

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.502 / Virus Database: 300 - Release Date: 7/18/2003
 

Re: [Etherboot-developers] eb 5.0.10 console_putc clobbers %cl

[<ke...@et...>]

>since 5.0.11 is in preparation, I thought, it would be good to at least 
>mention a very minor catch.

5.0.11 was released a couple of days ago and the 5.0 branch is closed.

>While examining etherboots tagged image loader, I discovered, that 
>console_putc clobbers %cl. Is this intended?

IIRC it doesn't cause any problem in 5.0 because all the calls are from
C and C does not expect %ecx to be preserved across calls.  In 5.1
console_putc is done totally differently and the PM to RM switch saves
%ecx.

>If I'm going to prepare some low level debugging stuff for etherboot 
>similar as in the patch to grub, is there any chance to get this into 
>5.1? (Of course, covered by a #define like LOW_LEVEL_DEBUG)

No, you'll have to wait for 5.3. 5.1 is virtually closed except for some
last minute cleanups by me and will become 5.2 within a few days.

This is what I was trying to hint to you: 5.0 is no longer being
developed and 5.1 does things underneath rather differently.

[Etherboot-developers] eb 5.0.10 console_putc clobbers %cl

[Hans-Peter J. <hp...@ur...>]

Hi Ken,

since 5.0.11 is in preparation, I thought, it would be good to at least 
mention a very minor catch.

While examining etherboots tagged image loader, I discovered, that 
console_putc clobbers %cl. Is this intended?

--- ../etherboot-5.0.10/src/pcbios.S	2002-04-20 16:15:31.000000000 +0200
+++ src/pcbios.S	2003-07-30 23:19:46.000000000 +0200
@@ -70,6 +70,7 @@
 	pushl	%ebp
 	movl	%esp,%ebp
 	pushl	%ebx
+	pushl	%ecx
 	pushl	%esi
 	pushl	%edi
 	movb	8(%ebp),%cl
@@ -86,6 +87,7 @@
 #endif
 	popl	%edi
 	popl	%esi
+	popl	%ecx
 	popl	%ebx
 	popl	%ebp
 	ret

If I'm going to prepare some low level debugging stuff for etherboot 
similar as in the patch to grub, is there any chance to get this into 
5.1? (Of course, covered by a #define like LOW_LEVEL_DEBUG)

hexdump(char *msg, char *mem, unsigned int len): what the name implies
regdump(): show the content of i386 cpu registers

They where designed for minimum food print and dependancies, while being 
convenient in usage.

They where very helpful for me, and I bet, other developers would profit 
from them, too. What do you think?

BTW: does anybody has an idea, how to get the %eip register in ix86?

Cheers,
Pete

Re: [Etherboot-developers] ANNOUNCE: limited tagged image support for grub (0.93)

[<ke...@et...>]

>Well, since grub is a full replacement for etherboot menus for me now, 
>which disappeared from 5.1, I thought, it would be interesting for 

In 5.1 and above menus are devolved to a loadable image which uses the
redirection capability of Etherboot to specify which image to load. I
didn't feel that menus should be part of the core functionality of
Etherboot, mainly because of the issue of updating ROMs, which is slower
than updating disk images. Have a look at mkelf-nfl, which doesn't take
the entries from the DHCP packet and has no limitations on menu entries
due to packet size.

While I have no philosophical objections to Etherboot code being used in
GRUB, and certainly no objections on licence grounds---it's GPL after
all---I do not want Etherboot to evolve towards becoming a disk
bootloader and certainly not splash screens and all that.  We have
enough work as it is trying to keep up with ideas in network booting. If
however these capabilities can be provided by a general mechanism, or
Etherboot can be invoked as a subsystem to do network booting, then I'll
listen to the proposal. In short, like the kernel developers, I like to
push bells and whistles into user space; and I prefer interoperability
to feature bloat.

>For the record: when I started experimenting with diskless linux setups 
>back in 1997 [fiddling with netboot and packet drivers], I couldn't 
>imagine, how far this could go. The progress made since then is 
>absolutely impressive (especially from the etherboot point of view).
>
>I looks to me, that the future of netbooting gets brighter and brighter.
>
>Thanks to all contributors,

And thanks for your kind words.

Re: [Etherboot-developers] ANNOUNCE: limited tagged image support for grub (0.93)

[Hans-Peter J. <hp...@ur...>]

Dear Ken,

On Friday 01 August 2003 04:12, Ken Yap wrote:
> >BTW: is there somebody out there really interested in this stuff?
>
> Probably not on the Etherboot-dev list though. 5.0 has just been put
> into maintenance mode and 5.2 prefers ELF images. Starting with
> mknbi-1.4.2 I intend to discourage tagged images by nagging and phase
> them out by 1.6, except for DOS and ROM tagged images. So I would
> encourage you to work on ELF image support instead.

Well, since grub is a full replacement for etherboot menus for me now, 
which disappeared from 5.1, I thought, it would be interesting for 
etherboot developers, too. I mainly put this together in order to get 
my dos images loaded, since grub is already able to load native linux 
kernel images with separate initrds via tftp. Thus, the necessity to 
load elf images seems pretty low to me. Correct me, if I'm wrong.

The main advantages of using {nb,pxe}grub are:
 - no need to mknbi linux kernels
 - separate config files per client (if needed)
 - thus no restart of dhcpd because of minor config changes
 - nr of menu items isn't limited

As an additional plus, together with gfxboot from SuSE 8.2, I 
succcessfully set up a customized graphical boot menu and a nice 
progress bar while netbooting linux ;-).

Although eyecandy only, it's especially nice on exhibitions to prove
netbooting doesn't limit the possibilites, it greatly enhances them.

For the record: when I started experimenting with diskless linux setups 
back in 1997 [fiddling with netboot and packet drivers], I couldn't 
imagine, how far this could go. The progress made since then is 
absolutely impressive (especially from the etherboot point of view).

I looks to me, that the future of netbooting gets brighter and brighter.

Thanks to all contributors,
Pete

Re: [Etherboot-developers] ANNOUNCE: limited tagged image support for grub (0.93)

[<ke...@et...>]

>BTW: is there somebody out there really interested in this stuff?

Probably not on the Etherboot-dev list though. 5.0 has just been put
into maintenance mode and 5.2 prefers ELF images. Starting with
mknbi-1.4.2 I intend to discourage tagged images by nagging and phase
them out by 1.6, except for DOS and ROM tagged images. So I would
encourage you to work on ELF image support instead.

[Etherboot-developers] 5.1.10 and 5.0.11 up on rom-o-matic.net, please test

[Marty C. <ma...@et...>]

For your network booting pleasure,

     Etherboot versions 5.1.10 and 5.0.11 are up on rom-o-matic.net.

Please test them, and send reports to the lists.

We're getting close to the next production version (5.2.0) and we'd 
like to avoid as many "brown paper bag" bugs as possible. (a "brown 
paper bag" bug is one that is so embarrassing that one is compelled to 
wear a brown paper bag over one's head to avoid being recognized :)

5.1.10 is a release candidate for 5.2, so try testing cards, burning 
ROMs, .zpxe'ing and .com'ing. QC, doc, and sanity checking are very 
much appreciated. And if I haven't said it lately, MAJOR THANKS to 
everyone for pitching in to make this next production release a great 
one!

Anyway, I hope to see some of you at LinuxWorld in SF.  It's always an 
adventure :)

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...@et...
     Web: http://www.etherboot.org/

[Etherboot-developers] ANNOUNCE: limited tagged image support for grub (0.93)

[Hans-Peter J. <hp...@ur...>]

Hi *,

here's a reworked and debugged implementation of the tagged image format
for grub. It currently lacks one exotic relocation scheme, and the ability 
to execute returning images (mainly because of grubs memory layout)...

The patch below also includes some useful low level debugging stuff in 
asm.S, currently covered by a local #define, but could be useful in other 
areas as well. I've kept it for discussion purposes, since my i386 assembler
knowledge is a bit rusty at best.

I've tried to follow grub's coding style most of the time.

BTW: is there somebody out there really interested in this stuff?

Pleace, love & happiness,
Pete

--- ../grub-0.93/netboot/main.c	2002-06-12 10:58:18.000000000 +0200
+++ netboot/main.c	2003-07-29 01:18:36.000000000 +0200
@@ -49,14 +49,14 @@
 int ip_abort = 0;
 /* Set if an ethernet card is probed and IP addresses are set.  */
 int network_ready = 0;
 
 struct rom_info rom;
+struct bootpd_t bootp_data;
 
 static int vendorext_isvalid;
 static unsigned long netmask;
-static struct bootpd_t bootp_data;
 static unsigned long xid;
 static unsigned char *end_of_rfc1533 = NULL;
 
 #ifndef	NO_DHCP_SUPPORT
 #endif /* NO_DHCP_SUPPORT */
--- stage2/asm.S.orig	2003-07-31 22:06:02.000000000 +0200
+++ stage2/asm.S	2003-07-31 22:08:31.000000000 +0200
@@ -1720,11 +1720,422 @@
 	DATA32	jmp	pc_stop
 ENTRY(patch_code_end)
 
 	.code32
 
+#if TAGGED_IMAGE_DEBUG
+/*
+ * hex dump
+ *
+ * void hexdump(const char *msg, void *p, unsigned int len);
+ */
+ENTRY(hexdump)
+	pushl	%eax			/* save used */
+	pushl	%ebx
+	pushl	%ecx
+	pushl	%edx
+	pushl	%edi
+	movl	24(%esp), %eax		/* msg */
+	testl	%eax, %eax		/* any? */
+	je	hd_nomsg
+	pushl	%eax			/* print message */
+	call	EXT_C(console_print)
+	pushl	$r_nl			/* newline */
+	call	EXT_C(console_print)
+	addl	$8, %esp
+hd_nomsg:
+	movl	$EXT_C(h_buf), %edi	/* ascii buffer */
+	movl	28(%esp), %ecx		/* p */
+	movl	32(%esp), %ebx		/* len */
+	jmp	hd_nextline		/* enter loop */
+
+hd_outerloop:
+	pushl	%ecx			/* address label */
+	call	EXT_C(console_print_int)
+
+	pushl	$0x3a			/* colon */
+	call	EXT_C(console_putchar)
+
+	pushl	$r_sep			/* separator */
+	call	EXT_C(console_print)
+	addl	$12, %esp
+
+	xorl	%edx, %edx		/* line index */
+hd_innerloop:
+	testl	%ebx, %ebx		/* finished? */
+	je	hd_lastline
+	movb	(%ecx, %edx), %al	/* grab value */
+	pushl	%eax			/* keep value on stack */
+	call	EXT_C(console_print_byte)
+	pushl	%edx			/* clobbered by console_putchar */
+	pushl	$0x20			/* extra blank */
+	call	EXT_C(console_putchar)
+	addl	$4, %esp
+	popl	%edx
+	popl	%eax			/* restore value */
+	cmpb	$0x20, %al		/* printable ascii */
+	jl	hd_subdot
+	cmpb	$0x7f, %al		/* < DEL */
+	jl	hd_asciiok
+hd_subdot:
+	movb	$0x2e, %al		/* subst. with '.' */
+hd_asciiok:
+	movb	%al, (%edi, %edx)	/* -> ascii value */
+	decl	%ebx			/* len -= 1 */
+	incl	%edx			/* index += 1 */
+
+	cmp	$8, %edx		/* half time? */
+	jne	hd_noegap
+	pushl	%edx			/* clobbered by console_putchar */
+	pushl	$0x20			/* extra blank */
+	call	EXT_C(console_putchar)
+	addl	$4, %esp
+	popl	%edx
+hd_noegap:
+	movl	$16, %eax		/* bytes per line */
+	cmp	%eax, %edx		/* line done? */
+	jl	hd_innerloop
+	addl	%eax, %ecx		/* advance p */
+	jmp	hd_putascii
+
+hd_lastline:				/* last line */
+	movb	$0, (%edi, %edx)	/* end of ascii */
+
+	movl	$16, %eax		/* calc. gab */
+	subl	%edx, %eax		/* # of bytes */
+	movl	%eax, %ecx		/* not used anymore */
+	addl	%eax, %eax
+	addl	%ecx, %eax		/* # of bytes * 3 */
+
+	cmpl	$8, %edx		/* extra gab? */
+	jae	hd_noegab2
+	incl	%eax
+hd_noegab2:
+	movl	%eax, %ecx		/* fill with blanks */
+	pushl	%edx			/* clobbered by console_putchar */
+hd_fillgab:
+	pushl	$0x20
+	call	EXT_C(console_putchar)
+	addl	$4, %esp
+	loop	hd_fillgab
+	popl	%edx
+hd_putascii:
+	pushl	$r_sep			/* separator */
+	call	EXT_C(console_print)
+
+	pushl	%edi			/* ascii part */
+	call	EXT_C(console_print)
+
+	pushl	$r_nl			/* newline */
+	call	EXT_C(console_print)
+	addl	$12, %esp
+hd_nextline:
+	testl	%ebx, %ebx		/* anything left? */
+	jne	hd_outerloop
+
+	popl	%edi			/* restore used */
+	popl	%edx
+	popl	%ecx
+	popl	%ebx
+	popl	%eax
+	ret
+
+VARIABLE(h_buf)
+	.string "1234567890123456"
+/*
+ * register dump
+ *
+ * void regdump(void);
+ */
+
+VARIABLE(r_msg)
+	.string "cs: "
+	.string "ds: "
+	.string "es: "
+	.string "ss: "
+
+VARIABLE(er_msg)
+	.string	"eax: "
+	.string	"ebx: "
+	.string	"ecx: "
+	.string	"edx: "
+	.string	"edi: "
+	.string	"esi: "
+	.string	"ebp: "
+	.string	"esp: "
+
+VARIABLE(r_sep)
+	.string "  "
+
+VARIABLE(r_nl)
+	.string "\r\n"
+
+ENTRY	(regdump)
+	pushl	%eax	/* save used */
+	pushl	%ebx
+	pushl	%ecx
+	pushl	%edx
+
+	push	%ss	/* push regs in reverse order */
+	push	%es
+	push	%ds
+	push	%cs
+	pushl	%esp
+	pushl	%ebp
+	pushl	%esi
+	pushl	%edi
+	pushl	%edx
+	pushl	%ecx
+	pushl	%ebx
+	pushl	%eax
+
+	movl	$EXT_C(r_nl), %edx	    /* line break */
+	movl	$EXT_C(er_msg), %ebx
+	movw	$8, %cx
+	pushl	%edx
+	call	EXT_C(console_print)
+	add	$4, %esp
+1:	push	%ebx
+	call	EXT_C(console_print)
+	add	$4, %esp
+	call	EXT_C(console_print_int)
+	add	$4, %esp		    /* consume pushed regs */
+	addl	$6, %ebx		    /* advance reg label */
+	dec	%cx
+	testw	%cx, %cx		    /* finished? */
+	je	3f
+
+	cmp	$4, %cx			    /* half time? */
+	jne	2f
+	push	%edx			    /* line break */
+	call	EXT_C(console_print)
+	add	$4, %esp
+	jmp	1b			    /* loop */
+
+2:	pushl	$EXT_C(r_sep)		    /* separator */
+	call	EXT_C(console_print)
+	add	$4, %esp
+	jmp	1b			    /* loop */
+
+3:	push	%edx			    /* line break */
+	call	EXT_C(console_print)
+	add	$4, %esp
+
+	movl	$EXT_C(r_msg), %ebx
+	movw	$4, %cx
+
+4:	pushl	%ebx
+	call	EXT_C(console_print)
+	add	$4, %esp
+	call	EXT_C(console_print_short)  /* consume pushed regs */
+	add	$4, %esp
+	add	$5, %ebx		    /* advance reg label */
+	dec	%cx
+	testw	%cx, %cx		    /* finished? */
+	je	5f
+	pushl	$EXT_C(r_sep)		    /* separator */
+	call	EXT_C(console_print)
+	add	$4, %esp
+	jmp	4b			    /* loop */
+
+5:	pushl	%edx			    /* line break */
+	call	EXT_C(console_print)
+	add	$4, %esp
+
+	popl	%edx
+	popl	%ecx
+	popl	%ebx
+	popl	%eax
+	ret
+
+ENTRY	(byte2hex)
+	movb	%al, %ah
+	andb	$0xf, %al
+	addb	$0x30, %al
+	cmpb	$0x39, %al
+	jle	1f
+	addb	$0x27, %al
+1:	xchgb	%al, %ah
+	shrb	$4, %al
+	andb	$0xf, %al
+	addb	$0x30, %al
+	cmpb	$0x39, %al
+	jle	2f
+	addb	$0x27, %al
+2:	ret
+
+ENTRY	(console_print_byte)
+	pushl	%eax
+	pushl	%edx	/* clobbered by console_putchar */
+	mov	12(%esp), %eax
+	call	EXT_C(byte2hex)
+	pushw	%ax
+	andl	$0xff, %eax
+	pushl	%eax
+	call	EXT_C(console_putchar)
+	add	$4, %esp
+	popw	%ax
+	movb	%ah, %al
+	andl	$0xff, %eax
+	push	%eax
+	call	EXT_C(console_putchar)
+	add	$4, %esp
+	popl	%edx
+	popl	%eax
+	ret
+
+ENTRY	(console_print_short)
+	pushl	%eax
+	movl	8(%esp), %eax
+	movb	%ah, %al
+	pushl	%eax
+	call	EXT_C(console_print_byte)
+	add	$4, %esp
+	movl	8(%esp), %eax
+	pushl	%eax
+	call	EXT_C(console_print_byte)
+	addl	$4, %esp
+	popl	%eax
+	ret
+
+ENTRY	(console_print_int)
+	pushl	%eax
+	movw	10(%esp), %ax
+	pushl	%eax
+	call	EXT_C(console_print_short)
+	add	$4, %esp
+	movw	8(%esp), %ax
+	pushl	%eax
+	call	EXT_C(console_print_short)
+	add	$4, %esp
+	popl	%eax
+	ret
+
+ENTRY	(console_print)
+	pushl	%eax
+	pushl	%ebx
+	pushl	%edx	/* clobbered by console_putchar */
+	movl	16(%esp), %ebx
+	jmp	2f
+1:	pushl	%eax
+	call	EXT_C(console_putchar)
+	add	$4, %esp
+	inc	%ebx
+2:	xorl	%eax, %eax
+	movb	(%ebx), %al
+	testb	%al, %al
+	jne	1b
+	popl	%edx
+	popl	%ebx
+	popl	%eax
+	ret
+
+ENTRY	(console_hitkey)
+	pushl	%eax
+	pushl	%edx
+	pushl	$EXT_C(hitkey)
+	call	EXT_C(console_print)
+	call	EXT_C(console_getkey)
+	pushl	$EXT_C(hitkey_rub)
+	call	EXT_C(console_print)
+	addl	$8, %esp
+	popl	%edx
+	popl	%eax
+	ret
+
+VARIABLE(hitkey)
+	.string	"<key>"
+VARIABLE(hitkey_rub)
+	.string	"\b\b\b\b\b     \b\b\b\b\b"
+
+#endif /* TAGGED_IMAGE_DEBUG */
+
+#ifdef SUPPORT_NETBOOT
+/*
+ * taggedimg_boot()
+ *
+ * Does some funky things and then jumps to the entry point
+ */
+VARIABLE(taggedimg_setup)
+	.long	0
+
+VARIABLE(taggedimg_setup_length)
+	.long	0
+
+VARIABLE(taggedimg_entry)
+	.long	0
+
+VARIABLE(taggedimg_bootp)
+	.long	0
+
+ENTRY(taggedimg_boot)
+	/* don't worry about saving anything, we're committed at this point */
+	cld	/* forward copying */
+
+	/* copy setup segment, if necessary */
+	movl	EXT_C(taggedimg_setup_length), %ecx
+	testl	%ecx, %ecx
+	je	no_rm_copy
+	addl	$3, %ecx
+	shrl	$2, %ecx
+	movl	$TAGGED_IMAGE_HIGHMEM, %esi
+	movl	$TAGGED_IMAGE_BASEMEM, %edi
+	rep
+	movsl
+
+no_rm_copy:
+	/* prepare ljmp */
+	movl	EXT_C(taggedimg_entry), %eax
+	movl	%eax, taggedimg_jmp
+
+	/* XXX new stack pointer in safe area for calling functions */
+	movl	$TAGGED_IMAGE_STACK, %esp
+	pushl	$0
+	call	EXT_C(gateA20)
+	addl	$4, %esp
+	call	EXT_C(stop_floppy)
+
+	/* final setup for tagged image boot */
+
+	movl	EXT_C(taggedimg_setup), %ebx
+	/* convert *BOOTP_DATA_ADDR to seg:off */
+	movl	EXT_C(taggedimg_bootp), %ecx
+	shll	$12, %ecx
+	shrw	$12, %cx
+
+#if TAGGED_IMAGE_DEBUG
+	call	EXT_C(regdump)
+	call	EXT_C(console_hitkey)
+#endif
+
+	call	EXT_C(prot_to_real)
+	.code16
+
+	/* final setup for tagged image boot */
+	cli
+	movw	%bx, %ss
+	movl	$TAGGED_IMAGE_STACK, %esp
+	
+	movw	%bx, %ds
+	movw	%bx, %es
+	movw	%bx, %fs
+	movw	%bx, %gs
+
+	pushl	%ecx		/* taggedimg_bootp */
+	pushl	%ebx		/* taggedimg_setup */
+	pushl	EXT_C(stop)	/* in case of return */
+
+	/* jump to start */
+3:
+	/* ljmp */
+	.byte	0xea
+taggedimg_jmp:	
+	.long	0
+	.code32
 
+#endif /* SUPPORT_NETBOOT */
+ 
 /*
  * linux_boot()
  *
  * Does some funky things (including on the stack!), then jumps to the
  * entry point of the Linux setup code.
--- ../grub-0.93/stage2/boot.c	2002-11-30 18:29:16.000000000 +0100
+++ stage2/boot.c	2003-07-31 21:51:59.000000000 +0200
@@ -23,10 +23,27 @@
 
 #include "freebsd.h"
 #include "imgact_aout.h"
 #include "i386-elf.h"
 
+#ifdef SUPPORT_NETBOOT
+# define GRUB 1
+# include <etherboot.h>
+
+/* Keep all context about loaded image in one place */
+static struct tagged_context    tctx;
+
+#define TAGGED_PROGRAM_RETURNS  (tctx.img.length & 0x00000100)  /* bit 8 */
+#define LINEAR_EXEC_ADDR        (tctx.img.length & 0x80000000)  /* bit 31 */
+
+static struct ebinfo            loaderinfo = {
+        5,0, /* VERSION_MAJOR, VERSION_MINOR, */
+        0
+};
+
+#endif /* SUPPORT_NETBOOT */
+
 static int cur_addr;
 entry_func entry_addr;
 static struct mod_list mll[99];
 static int linux_mem_size;
 
@@ -89,10 +106,126 @@
 	  str2 = "Multiboot";
 	  break;
 	}
     }
 
+#ifdef SUPPORT_NETBOOT
+
+  /* check for tagged image */
+  if ((type == KERNEL_TYPE_NONE) && (*((unsigned long *)buffer) == TAGGED_MAGIC))
+    {
+      type = KERNEL_TYPE_TAGGEDIMAGE;
+      str2 = "Tagged Image";
+      taggedimg_setup = NULL;
+      taggedimg_setup_length = 0;
+      taggedimg_entry = NULL;
+      taggedimg_bootp = NULL;
+      printf("Netboot Tagged Image Format detected\n");
+
+      /* Zero all context info */
+      grub_memset(&tctx, 0, sizeof(tctx));
+      /* Copy first 4 longwords */
+      grub_memmove(&tctx.img, buffer, sizeof(tctx.img));
+      /* Memory location where we are supposed to save it */
+      tctx.segaddr = tctx.linlocation = ((tctx.img.u.segoff.ds) << 4)
+					 + tctx.img.u.segoff.bx;
+
+      /* Grab a copy */
+      if (tctx.segaddr < TAGGED_IMAGE_BASEMEM_LIMIT) {
+	  /* We won't overwrite grub, move stuff to a temporary location */
+	  tctx.segaddr += TAGGED_IMAGE_HIGHMEM_OFFSET;
+	  taggedimg_setup_length = 512;
+      }
+      grub_memmove((void *)tctx.segaddr, buffer, 512);
+      tctx.segaddr += ((tctx.img.length & 0x0F) << 2) +
+		      ((tctx.img.length & 0xF0) >> 2);
+
+      grub_seek(512);
+      len = 512;
+
+      while (1) 
+	{
+	  if (tctx.seglen == 0) {
+	    struct segheader sh;
+	    if (tctx.segflags & 0x04) {
+	      if (TAGGED_PROGRAM_RETURNS) {
+		printf("Warning: returning images not supported\n");
+		type = KERNEL_TYPE_NONE;
+		break;
+	      }
+	      if (LINEAR_EXEC_ADDR) {
+		type = KERNEL_TYPE_TAGGEDPMIMAGE;
+#if TAGGED_IMAGE_DEBUG
+		printf("PM image: %x(%x, %x, %x)\n", tctx.img.execaddr,
+		     &loaderinfo, tctx.linlocation, (char *) BOOTP_DATA_ADDR);
+#else
+		printf("%d K, start in protected mode\n", len >> 10);
+#endif
+	      } else {
+		taggedimg_entry = (char *) tctx.img.execaddr;
+		taggedimg_setup = (char *) tctx.img.u.location;
+		taggedimg_bootp = (char *) BOOTP_DATA_ADDR;
+#if TAGGED_IMAGE_DEBUG
+		printf("RM image: entry: %x, setup: %x, bootp: %x\n",
+			taggedimg_entry, taggedimg_setup, taggedimg_bootp);
+#else
+		printf("%d K, start in real mode\n", len >> 10);
+#endif
+	      }
+	      break;
+	    }
+	    sh = *((struct segheader *)tctx.segaddr);
+	    tctx.seglen = sh.imglength;
+	    if ((tctx.segflags = sh.flags & 0x03) == 0)
+		    cur_addr = sh.loadaddr;
+	    else if (tctx.segflags == 0x01)
+		    cur_addr = tctx.last1 + sh.loadaddr;
+	    else if (tctx.segflags == 0x02) {
+#if 0
+	      cur_addr = (Address)(meminfo.memsize * 1024L + 0x100000L)
+			 - sh.loadaddr;
+#endif
+	      printf("Addressing mode not supported\n");
+	      type = KERNEL_TYPE_NONE;
+	      break;
+	    }
+	    else
+	      cur_addr = tctx.last0 - sh.loadaddr;
+	    /* calc. segm. parameter */
+	    tctx.last1 = (tctx.last0 = cur_addr) + sh.memlength;
+	    tctx.segflags = sh.flags;
+	    tctx.segaddr += ((sh.length & 0x0F) << 2)
+		    + ((sh.length & 0xF0) >> 2);
+	  }
+#if TAGGED_IMAGE_DEBUG
+	  printf("segaddr: %x, dest: %x, seglen: %d, segflags: %x\n",
+	     tctx.segaddr, cur_addr, tctx.seglen, tctx.segflags);
+#endif
+	  if (tctx.seglen) {
+	      /* another segment */
+	      if (cur_addr < TAGGED_IMAGE_BASEMEM_LIMIT) {
+		  cur_addr += TAGGED_IMAGE_HIGHMEM_OFFSET;
+		  taggedimg_setup_length = (cur_addr - TAGGED_IMAGE_HIGHMEM)
+					   + tctx.seglen;
+	      }
+	      len += tctx.seglen;
+#if TAGGED_IMAGE_DEBUG
+	      printf("read: %x, len: %d\n", cur_addr, tctx.seglen);
+#else
+	      printf("%d K\r", len >> 10);
+#endif
+	      grub_read((char *) RAW_ADDR(cur_addr), tctx.seglen);
+	      tctx.seglen = 0;
+	  } 
+	  else break;
+	}
+      grub_close ();
+      return type;
+    }
+
+#endif /* SUPPORT_NETBOOT */
+
   /* Use BUFFER as a linux kernel header, if the image is Linux zImage
      or bzImage.  */
   lh = (struct linux_kernel_header *) buffer;
   
   /* ELF loading supported if multiboot, FreeBSD and NetBSD.  */
@@ -999,5 +1132,15 @@
       
       (*entry_addr) (clval, bootdev, 0, end_mark,
 		     extended_memory, mbi.mem_lower);
     }
 }
+
+#ifdef SUPPORT_NETBOOT
+void taggedimg_pmboot(void)
+{
+  void (*entry)(struct ebinfo *, long, struct bootpd_t *);
+  entry = (void (*)())tctx.img.execaddr;
+  /* jump to it */
+  (*entry)(&loaderinfo, tctx.linlocation, BOOTP_DATA_ADDR);
+}
+#endif /* SUPPORT_NETBOOT */
--- stage2/builtins.c.orig	2003-07-31 22:06:11.000000000 +0200
+++ stage2/builtins.c	2003-07-31 22:10:42.000000000 +0200
@@ -295,10 +295,22 @@
     case KERNEL_TYPE_MULTIBOOT:
       /* Multiboot */
       multi_boot ((int) entry_addr, (int) &mbi);
       break;
 
+#ifdef SUPPORT_NETBOOT
+    case KERNEL_TYPE_TAGGEDIMAGE:
+      /* Tagged Image */
+      taggedimg_boot ();
+      break;
+
+    case KERNEL_TYPE_TAGGEDPMIMAGE:
+      /* Tagged PM Image */
+      taggedimg_pmboot ();
+      break;
+#endif
+
     default:
       errnum = ERR_BOOT_COMMAND;
       return 1;
     }
 
--- stage2/shared.h.orig	2003-07-31 22:45:53.000000000 +0200
+++ stage2/shared.h	2003-07-31 23:00:51.000000000 +0200
@@ -157,10 +157,19 @@
 #define LINUX_CL_OFFSET			0x9000
 #define LINUX_CL_END_OFFSET		0x90FF
 #define LINUX_SETUP_MOVE_SIZE		0x9100
 #define LINUX_CL_MAGIC			0xA33F
 
+#ifdef SUPPORT_NETBOOT
+#define TAGGED_IMAGE_DEBUG		0
+#define TAGGED_IMAGE_STACK		0x9000
+#define TAGGED_IMAGE_BASEMEM		0x10000
+#define TAGGED_IMAGE_BASEMEM_LIMIT	0x90000
+#define TAGGED_IMAGE_HIGHMEM_OFFSET	0xf0000
+#define TAGGED_IMAGE_HIGHMEM		0x100000
+#define TAGGED_MAGIC			0x1b031336
+#endif /* SUPPORT_NETBOOT */
 /*
  *  General disk stuff
  */
 
 #define SECTOR_SIZE		0x200
@@ -488,10 +497,66 @@
   unsigned long max_pixel_clock;
 
   unsigned char reserved3[189];
 } __attribute__ ((packed));
 
+#ifdef SUPPORT_NETBOOT
+
+struct imgheader 
+{
+  unsigned long magic;
+  unsigned long length;                   /* and flags */
+  union
+  {
+    struct { unsigned short bx, ds; } segoff;
+    unsigned long location;
+  } u;
+  unsigned long execaddr;
+};
+
+struct segheader
+{
+  unsigned char length;
+  unsigned char vendortag;
+  unsigned char reserved; 
+  unsigned char flags;
+  unsigned long loadaddr;
+  unsigned long imglength;
+  unsigned long memlength;
+};
+
+struct tagged_context
+{
+  struct imgheader        img;                    /* copy of header */
+  unsigned long           linlocation;            /* addr of header */
+  unsigned long           last0, last1;           /* of prev segment */
+  unsigned long           segaddr, seglen;        /* of current segment */
+  unsigned char           segflags;
+};
+
+/* globals for real mode stub */
+
+extern char *taggedimg_setup;
+extern unsigned long taggedimg_setup_length;
+extern char *taggedimg_entry;
+extern char *taggedimg_bootp;
+
+#if TAGGED_IMAGE_DEBUG
+void console_print(char *);
+void console_print_byte(char);
+void console_print_short(short);
+void console_print_int(int);
+void console_hitkey(void);
+void regdump(void);
+void hexdump(const char *msg, void *p, unsigned int len);
+#endif /* TAGGED_IMAGE_DEBUG */
+
+/* do some funky stuff, then boot a tagged image */
+void taggedimg_boot (void) __attribute__ ((noreturn));
+void taggedimg_pmboot (void) __attribute__ ((noreturn));
+
+#endif /* SUPPORT_NETBOOT */
 
 #undef NULL
 #define NULL         ((void *) 0)
 
 /* Error codes (descriptions are in common.c) */
@@ -829,11 +894,15 @@
   KERNEL_TYPE_MULTIBOOT,	/* Multiboot.  */
   KERNEL_TYPE_LINUX,		/* Linux.  */
   KERNEL_TYPE_BIG_LINUX,	/* Big Linux.  */
   KERNEL_TYPE_FREEBSD,		/* FreeBSD.  */
   KERNEL_TYPE_NETBSD,		/* NetBSD.  */
-  KERNEL_TYPE_CHAINLOADER	/* Chainloader.  */
+  KERNEL_TYPE_CHAINLOADER,	/* Chainloader.  */
+#ifdef SUPPORT_NETBOOT
+  KERNEL_TYPE_TAGGEDIMAGE,	/* Netboot Tagged Image.  */
+  KERNEL_TYPE_TAGGEDPMIMAGE,	/* Netboot Tagged PM Image.  */
+#endif /* SUPPORT_NETBOOT */
 }
 kernel_t;
 
 extern kernel_t kernel_type;
 extern int show_menu;

RE: [Etherboot-developers] 3c900-tpo hang after DHCPOFFER

[Timothy L. <tl...@ro...>]

> Are Eric and I the only people who understand that Etherboot doesn't
> have deep latency or memory resources? All these things such as
> suggestions of HTTP, use of recursive routines, etc. Sorry can't
resist
> a dig. :-)

I certainly don't know much about Etherboot beyond the driver level.
One day I must read the 5.2 developer's manual to see what everything
does...

Tim

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.502 / Virus Database: 300 - Release Date: 7/18/2003