etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] Q: LinuxBIOS support?

[Christoph P. <chr...@al...>]

Hello !

AFAIK Linux-Bios is a small Linux kernel which is booted directly from
the
boot vector. Only a smart chipset setup is done, all other things are
coming
from this small linux kernel, as it can handle and drive all i/o
components,
as we know :-)

So this linux kernel also can handle network and bootp/dhcp requests,
transporting files fia ftp/tftp and mounting NFS roots.

So I don't know, but possible there is not much up to nothing to do,
to support netboot here.

But again, I don't know it very well, as up to now, I have no machine,
which Linux Bios supports. If I would have one, I only would use Linux
Bios !!!!

With friendly regards
	Christoph P.

Marty Connor wrote:
> 
> On 6/16/2001 7:34 AM Eric W. Biederman ebi...@ln... wrote:
> >Assuming that a clean approach can be found to use etherboot in
> >linuxBIOS.  Would you be willing for etherboot to go in that direction?
> >The expectation here is that the linuxBIOS developers would contribute
> >the code to work with linuxBIOS.
> 
> This sounds like an interesting idea in principle.  During the time I
> have contributed to the Etherboot Project we seem to be constantly moving
> in the direction of supporting more ways for people to utilize network
> booting.  Sometimes by adding support for more cards, and sometimes by
> creating new ways to make Etherboot bootable by other loaders and
> utilities.
> 
> I think it would be fun to work with more developers, and see what we can
> accomplish together.
> 
> As they say in poker, "Deal me in". :-)
> 
> 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/
> 
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> http://lists.sourceforge.net/lists/listinfo/etherboot-developers

------------------------------------------------------------------
private:  chr...@gm...
company:  chr...@al...

[Etherboot-developers] Re: Etherboot-developers digest, Vol 1 #153 - 3 msgs

[David C. <hos...@rc...>]

> > >Assuming that a clean approach can be found to use etherboot in
> > >linuxBIOS.  Would you be willing for etherboot to go in that direction?
> > >The expectation here is that the linuxBIOS developers would contribute
> > >the code to work with linuxBIOS.
> >
> > Speaking for myself, I'm all for it. I think that accepting fresh
> > challenges will bring a wider audience to both linuxBIOS and Etherboot.
> > I know that various experimenters have deployed Etherboot on bare metal
> > so I'm sure a clean solution can be found. When do we start?
>
> Some preliminary implementations have already been done.
> If you are really interested you can follow the discussion on
> the linuxbios mailing list (now CC'd).
>
> Look at www.linuxbios.org
> Somewhere there should be a link to the linuxbios mailing list archive.
>
> Tiara is the farthest along of the work that has been done.
>
> The challenge that keeps us from accepting just about anything
> is that interesting firmware seems to keep evolving into it's own OS
> and we really don't want to do that, with linuxBIOS.
>
> Conceptually linuxBIOS is made up of 3 parts.
> stage1 -- ram initialization.
>          (Everything cannot be done in normal C code).
> stage2 -- Basic system initialization.
> stage3/1 -- Failsafe bootloader.
> stage3/2 -- Bootloader.
>
> The model is still being refined because we have some widely varing
> targets.
>
> Primarily for the bootloader in stage3 we intend to use linux.
> Reusing an entire OS for where you need one somehow makes so
> much sense.
>
> We are still working on a backup booting strategy, and how
> to deal with kernels that don't have drivers to all of the hardware.
>
> So we are looking at using etherboot as our failsafe bootloader, and a
> bootloader for when we don't have enough flash, to include the linux
> kernel.
>
> My hunch right now is that the cleanest way to work together is to
> have etherboot compile into a network bootable ELF executable, and we
> could just reuse it whole.  I have already written an ELF bootloader
> for linuxBIOS, so that end is covered.
>
> There seem to be a few other ideas out there as well.
>
> I suspect it will take a couple of months of playing with ideas
> to come up with a good design and see it implemented and accepted.
>
> On the linuxBIOS side the difficult part is to figure out where
> to place code that is needed for system iniitialization where the
> drivers have not been written for linux yet.   Will they go into
> a kernel patch?  Will they go in a bootloader?  Somewhere else?
> They must be cleanly seperated from the rest of the linuxBIOS code
> because the intention is to remove them long term.  But we are stuck
> with them shortterm.  Because the BIOS developers tend to get access
> to a board before the kernel developers do.  For obvious reasons :)
>
> Eric
>
> --__--__--
>

Thanks for Eric's suggestions. I have already deploy etherboot and integrated with our firmware in our
prototypes. We are developing a single board computing device experimentaly.  LinuxBIOS still lack of some
important features over traditional BIOS like Phoenix, Award. We have being working hard on studying hardware
specifications and writing drivers for Linux, but the point is lack of support from chips manufacturers. Using
etherboot can be easy in deploying code from model to model.  On some of our models we will use LinuxBIOS since
they are designed to be embedded with Linux and running Linux as their only OS. For other usage, we have to
stick with Award and Phoenix since we need some features from them which LinuxBIOS doesn't have.  And yes, we
are planning to add more and more stuff to the firmware which is originaly based on etherboot which makes
etherboot a good start on firmware development and OS loader. It is also good to hear from LinuxBIOS that they
can contribute in the development of new features and new designs. We would like to contribute.. Thanks.

regards,

David

[Etherboot-developers] Re: [Etherboot-users] More on pxe nic -> Etherboot

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

On 6/18/2001 12:07 PM Peter Lister P.L...@sy... wrote:
>OK, more news from the front... I'm still trying to run Etherboot from a
>PXE based nic boot rom.

I like this idea, and am glad you're doing it.  Thanks for your 
persistence.

>So, given that one can't install etherboot on the machine somewhere, the
>obvious solution is to use the nic rom (e.g. 3Com "Managed PC Boot
>Agent") to pull Etherboot. However, when I first tried that I just
>seemed to get a silent frozen system. As I have no way of knowing what
>the proprietary nic rom was doing, I tried pxelinux, finding (a) that it
>worked out of the box and (b) a hint to the effect that Etherboot is an
>example of a COMBOOTable application.

I'm going to venture some guesses here, and hope that people who 
understand these things better will possibly chime in.

Not being quite sure what precisely a combootable application is, I did a 
search and found this link: 

      
http://www.cs.helsinki.fi/u/mjrauhal/linux/cola.archive/1996-04/cola.1996-0
4-27.001

Which seems to answer the question.  Etherboot can generate .COM files 
using a command like "make bin32/rtl8139.com".  This probably isn't 
helpful to your current situation, but I thought I'd mention it for 
others.

>Anyway, I have just tried *again* to load etherboot directly with MBA, I
>now see a message...
>This image cannot be loaded from a floppy disk

So you must be trying to load a ".lzlilo" image.

>...on the vga console; I must have missed it before, and it wasn't
>immediately obvious that this is an Etherboot message (Note - please
>could you prefix ALL messages with 'Etherboot:' so that it is clear what
>is generating the message).

I agree that we should probably consider being more uniform in output 
from Etherboot.  Your concern is noted.

>So this confirms that the Etherboot image IS being executed (I also
>added some messages in pxelinux which confirm that pxelinux is NOT
>rejecting the lilo image, it's doing the right thing, just like booting
>a genuine kernel). This message is in the liloprefix code, and should
>never be run.

>What do I need to do here? It would seem to a naive observer that that
>the fix should simply be to redirect to the "right" place. I have tried
>replacing the 'freeze: jmp freeze' loop with 'jmp setup_code' but other
>than a line of garbage on the vga console, I get nothing.

Here's what I think is happening.  I hope this makes sense.

An ".lzlilo" image is a "fake" kernel.  It is good enough to fool lilo, 
syslinux, and hopefully someday LOADLIN.  We created it by reading the 
source code to various loaders and utilities, and seeing what they needed 
in order to believe that something was a kernel.  Some do sanity checking 
on size, while others do various kinds of peeking at header fields.

I'm not sure what the LANWORKS MBA is doing, and without source code, 
help, or disassembly, it would be hard to figure out.  But I have an idea.

Here is a link on the Linux Terminal Server Project Site

  http://www.ltsp.org/documentation/LTSP-MBA.htm

Which describes how to use a mknbi "tagged image file" with the LANWORKS 
MBA.

Here is an excerpt:

"... Support for 3Com Managed PC Boot Agent (MBA).
3Com MBAs will not support the LTSP boot image files by default. This is 
because the 3Com boot ROMs do not support the format of boot image files 
created using the mknbi=A0 Etherboot utility.=A0 To
address this problem, Lanworks Technologies has developed a Linux boot 
image creation utility called imggen.=A0 Imggen patches any Etherboot Linux=
 
kernel image so that it can be booted using
any Lanworks MBA or BootWare Tri-ROM.=A0 This document details the steps 
required to use Lanworks TCP/IP boot ROMs with the Linux Terminal Server. 
... "
 
LTSP distributes kernel images which have been reformatted ("tagged") 
with a utility called "mknbi-linux".  This allows Etherboot to load them, 
because (someone correct me if i'm wrong) it is more complicated (thus 
using more code space) to load raw kernel images that have not been 
tagged.  Tagging allows the loading mechanism in Etherboot to be more 
efficient (and fit better in the limited space of the ROM).

Here is a link to the "imggen" utility.

   http://prdownloads.sourceforge.net/ltsp/imggen

It takes a tagged kernel image and makes it into an image that the 3COM 
MBA can load. Some Doc is at the link above.

I do not know exactly what imggen does, but a binary compare of the 
before and after kernel images would probably tell us.  I also note that 
imggen is only 21K, so it probably wouldn't be hard to disassemble and 
figure out what it is doing.  It is probably dressing up the tagged image 
enough to fool the MBA into loading and executing it.  Does anyone have 
the source code for imggen?

>I wondered if trying just a rom or lzrom would work, or even the
>3c905x.img (since the code should just enter at the top of _start), but
>nothing seems to work. I'm sure that, to someone who knows the code,
>this is now a trivial problem. Help, please?

With the disclaimer that others probably know a lot more about this than 
I do, I'll suggest the following.

1.  Make a .lzlilo image.  It's a fake kernel, but let's pretend it's 
real.

2.  Try running mknbi-linux on it.  This will give you a "tagged" kernel 
(.lzlilo) image.

3.  Take the tagged "kernel" (.lzlilo) image from step 2 and run the 
"imggen" utility on it.

This might work.  I haven't tried it, but I think that even if it doesn't 
work, we may have a shot at fixing it to work.  

Actually, I just did some experiments, and it seems there are more subtle 
problems here.  mknbi-linux does a sanity check on the ".lzlilo" image 
and fails.  The sanity check can be commented out, and it will generate a 
tagged image.

The imggen utility is is willing to run on the tagged image, and produces 
an output file.

Unfortunately, on my 3C905C board, setting the boot method to TCP/IP and 
DHCP, I get:

   NODE: 000102C179C7
   DHCP..
   TFTP....................

And nothing more.  It seems the MBA is not happy with our 
fake-tagged-imggen'ed file.  I'm not sure why.

The daemon.log file shows:

Jun 18 14:48:58 ll dhcpd-2.2.x: DHCPDISCOVER from 00:01:02:c1:79:c7 via 
eth0
Jun 18 14:48:58 ll dhcpd-2.2.x: DHCPOFFER on 192.168.2.136 to 
00:01:02:c1:79:c7 via eth0
Jun 18 14:48:59 ll dhcpd-2.2.x: DHCPREQUEST for 192.168.2.136 from 
00:01:02:c1:79:c7 via eth0
Jun 18 14:48:59 ll dhcpd-2.2.x: DHCPACK on 192.168.2.136 to 
00:01:02:c1:79:c7 via eth0
Jun 18 14:49:00 ll in.tftpd[1322]: connect from 192.168.2.136
Jun 18 14:49:00 ll tftpd[1323]: tftpd: trying to get file: 
/tftpboot/lts/3c905c-tpo.imggen 

I also tried running imggen on a .lzrom file tagged with mknbi-rom with 
identical results.

>If we can get EB to run straight away, without pxelinux, this would be
>great. Maybe better yet if EB could snarf enough pxe code from pxelinux
>to be a good pxe citizen (i.e. return control back to pxe if things go
>wrong, rather than looping), and have a "PXEable" image build option.
>And maybe, once successfully demo'd, we can persuade customers to just
>flash Etherboot.

These are interesting ideas.  I'm not sure if anyone is interested in 
doing this, since Etherboot supports a large number of cards, but I've 
occasionally thought this would be an interesting idea, in principle for 
people who have PXE cards but want to execute Etherboot before booting 
their ultimate OS.

Maybe someone else has some ideas or suggestions.  I'm out of ideas and 
time for the moment.   Let us know if you get any farther.  Perhaps some 
3Com folks would be willing to help debug this?

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] Q: LinuxBIOS support?

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

On 6/16/2001 7:34 AM Eric W. Biederman ebi...@ln... wrote:
>Assuming that a clean approach can be found to use etherboot in
>linuxBIOS.  Would you be willing for etherboot to go in that direction?
>The expectation here is that the linuxBIOS developers would contribute
>the code to work with linuxBIOS.

This sounds like an interesting idea in principle.  During the time I 
have contributed to the Etherboot Project we seem to be constantly moving 
in the direction of supporting more ways for people to utilize network 
booting.  Sometimes by adding support for more cards, and sometimes by 
creating new ways to make Etherboot bootable by other loaders and 
utilities.

I think it would be fun to work with more developers, and see what we can 
accomplish together.  

As they say in poker, "Deal me in". :-)

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] Re: mknbi fails with 2.4.5, initrd, and machines with a load of RAM

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

>For 2.4.x however, the kernel has the appropriate logic to not stomp
>on an initial ramdisk, before it starts allocating ram, so the fix
>might simply be to place the ramdisk immediately after the kernel.

Looks like it's time for me to reimplement the ramaddr= option that was
in the original Netboot mknbi.

Re: [Etherboot-developers] Re: mknbi fails with 2.4.5, initrd, and machines with a load of RAM

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

Tim Small <ti...@di...> writes:

> ke...@us... <mailto:ke...@us...> wrote:
> 
> >>We have some machines here which we are using Etherboot/ mknbi to boot 
> >>remotely.  The machines have 1G of RAM, and are failing to boot from an 
> >>initrd image because mknbi appears to be shoving it too high up in 
> >>memory.  I'm going to have a go at fixing it, but my x86 assembly skills 
> >>are pretty much non-existant ;-).  Here's what the bootup log says:
> >>
> >>Linux version 2.4.5 (ro...@vi... <mailto:ro...@vi...>) (gcc
> version 2.95.4 20010319
> 
> >>(Debian prerelease)) #1941 SMP Tue Jun 12 13:07:35 BST 2001
> >>BIOS-provided physical RAM map:
> >>BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
> >>BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
> >>BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
> >>BIOS-e820: 0000000000100000 - 000000003fff0000 (usable)
> >>BIOS-e820: 000000003fff0000 - 000000003fff8000 (ACPI data)
> >>BIOS-e820: 000000003fff8000 - 0000000040000000 (ACPI NVS)
> >>BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
> >>BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
> >>BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
> >>127MB HIGHMEM available.
> >>
> >>....
> >>
> >>initrd extends beyond end of memory (0x3fff0000 > 0x38000000)
> >>disabling initrd
> >>
> >>...
> >>
> >>Memory: 1028240k/1048512k available (1368k kernel code, 19884k reserved, 
> >>479k data, 240k init, 131008k highmem)
> >>
> >
> >What's probably happening is that first32.linux's algorithm for working
> >out the memory size is not sufficiently comprehensive. The Linux kernel
> >tries a few BIOS calls, first32.linux only uses two (of which e820 is
> >not one) and probably doesn't take into account the holes.
> >start32.S:memsize is probably what needs to be enhanced, using the code
> >in the kernel's setup.S as a guide.
> >
> I'm pretty sure the later is beyond me.  I'm also not sure it would fix 
> the problem, as the kernel then makes a decision about where it 
> considers highmem to start, and won't like the initrd being above this. 
>  I could probably manage a dirty hack to make sure it doesn't get moved 
> to beyond 512M (or 768M - or some other semi-arbitary number - with 512M 
> of RAM, this box boots fine) - but I would imagine this is not of much 
> interest to anyone but myself ;-).

Actually I have run into similiar problems.   On a machine with 2GB of
RAM with linux-2.2.x.  If I place the ramdisk at I think it was 16MB
it gets overwritten, because of all of the struct page entries.  I
have different implementation of mknbi though, and I have just
hardwired my ramdisks at the top of 64MB.  The 1GB/3GB split in the
kernel is the wose case linux should see.  So I would limit a ramdisk
to either 768M or 256M.  If you are moving it up in memory.  

For 2.4.x however, the kernel has the appropriate logic to not stomp
on an initial ramdisk, before it starts allocating ram, so the fix
might simply be to place the ramdisk immediately after the kernel.

Eric

Re: [Etherboot-developers] Q: LinuxBIOS support?

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

ke...@us... writes:

> >Assuming that a clean approach can be found to use etherboot in
> >linuxBIOS.  Would you be willing for etherboot to go in that direction?
> >The expectation here is that the linuxBIOS developers would contribute
> >the code to work with linuxBIOS.
> 
> Speaking for myself, I'm all for it. I think that accepting fresh
> challenges will bring a wider audience to both linuxBIOS and Etherboot.
> I know that various experimenters have deployed Etherboot on bare metal
> so I'm sure a clean solution can be found. When do we start?

Some preliminary implementations have already been done.
If you are really interested you can follow the discussion on
the linuxbios mailing list (now CC'd).

Look at www.linuxbios.org
Somewhere there should be a link to the linuxbios mailing list archive.

Tiara is the farthest along of the work that has been done.

The challenge that keeps us from accepting just about anything
is that interesting firmware seems to keep evolving into it's own OS
and we really don't want to do that, with linuxBIOS.

Conceptually linuxBIOS is made up of 3 parts.
stage1 -- ram initialization.  
         (Everything cannot be done in normal C code).
stage2 -- Basic system initialization.
stage3/1 -- Failsafe bootloader.
stage3/2 -- Bootloader.

The model is still being refined because we have some widely varing
targets.  

Primarily for the bootloader in stage3 we intend to use linux.
Reusing an entire OS for where you need one somehow makes so
much sense.

We are still working on a backup booting strategy, and how
to deal with kernels that don't have drivers to all of the hardware. 

So we are looking at using etherboot as our failsafe bootloader, and a
bootloader for when we don't have enough flash, to include the linux
kernel.

My hunch right now is that the cleanest way to work together is to
have etherboot compile into a network bootable ELF executable, and we
could just reuse it whole.  I have already written an ELF bootloader
for linuxBIOS, so that end is covered.

There seem to be a few other ideas out there as well.

I suspect it will take a couple of months of playing with ideas
to come up with a good design and see it implemented and accepted.

On the linuxBIOS side the difficult part is to figure out where
to place code that is needed for system iniitialization where the
drivers have not been written for linux yet.   Will they go into
a kernel patch?  Will they go in a bootloader?  Somewhere else?
They must be cleanly seperated from the rest of the linuxBIOS code
because the intention is to remove them long term.  But we are stuck
with them shortterm.  Because the BIOS developers tend to get access
to a board before the kernel developers do.  For obvious reasons :)

Eric

Re: [Etherboot-developers] Q: LinuxBIOS support?

[Jim M. <ja...@mc...>]

I agree completely with Ken about this.

I've met Ron Minnich and Ollie Lho of the LinuxBIOS project,
and I believe they are working on one of the coolest projects
out there.  If there is a way that Etherboot can be utilized as
part of that solution, then I would certainly like to try to
help that effort.

When I listened to Ron talk about LinuxBios, there was several
times that he mentioned Biederman, and how helpful he was to the
LinuxBios project.  I just now realized that he was
talking about Eric Biederman.

Having a pool of talent containing people like Ken Yap, Marty Connor,
Eric Biederman, Ron Minnich, Ollie Lho, and all the other people
involved in both the Etherboot project and the LinuxBios project
is really almost unbelievable.

I'm looking forward to seeing what comes out of this, and I hope
there is a way that I can contribute.

Thanks,

Jim McQuillan
ja...@lt...

ke...@us... wrote:
> 
> >Assuming that a clean approach can be found to use etherboot in
> >linuxBIOS.  Would you be willing for etherboot to go in that direction?
> >The expectation here is that the linuxBIOS developers would contribute
> >the code to work with linuxBIOS.
> 
> Speaking for myself, I'm all for it. I think that accepting fresh
> challenges will bring a wider audience to both linuxBIOS and Etherboot.
> I know that various experimenters have deployed Etherboot on bare metal
> so I'm sure a clean solution can be found. When do we start?
> 
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> http://lists.sourceforge.net/lists/listinfo/etherboot-developers

Re: [Etherboot-developers] Q: LinuxBIOS support?

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

>Assuming that a clean approach can be found to use etherboot in
>linuxBIOS.  Would you be willing for etherboot to go in that direction?
>The expectation here is that the linuxBIOS developers would contribute
>the code to work with linuxBIOS.

Speaking for myself, I'm all for it. I think that accepting fresh
challenges will bring a wider audience to both linuxBIOS and Etherboot.
I know that various experimenters have deployed Etherboot on bare metal
so I'm sure a clean solution can be found. When do we start?

[Etherboot-developers] Q: LinuxBIOS support?

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

Right now with linuxBIOS we are actively working out what is
a good bootloader solutions.  With at least 512KB of ROM
we can use the linux kernel and that works well.

On systems with smaller ROMS we are looking at building a small
bootloader that can run without BIOS support.  Etherboot keeps showing
up in the prototypes.

Assuming that a clean approach can be found to use etherboot in
linuxBIOS.  Would you be willing for etherboot to go in that direction?
The expectation here is that the linuxBIOS developers would contribute
the code to work with linuxBIOS.

On the etherboot side, for the boards supported by linuxBIOS
this neatly solves the problem of how to add etherboot to the boards
BIOS..

Ken, Marty, and company, if you have major objections to going
this route I'm going to kill this idea.  Reusing someone elses drivers
is not a solution maintainable long term.

Eric

Re: [Etherboot-developers] Feature Request

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

>It would be really cool if you could use variables in your menu or motd
>reference items like your:
>
>MAC address
>Hostname (supplied from DHCP server)
>IP address
>etc
>etc

All somebody has to do is write an extended menu program on the lines of
the sample one in mknbi. Since it has access to the DHCP reply, it can
extract all these values.

[Etherboot-developers] Feature Request

[Dax K. <dk...@gu...>]

It would be really cool if you could use variables in your menu or motd
reference items like your:

MAC address
Hostname (supplied from DHCP server)
IP address
etc
etc


Somethink like


.motd:\
        :T184="ESC[31m":\
        :T185="+------------------------------------------------------+":\
        :T186="|                Welcome to %HOSTNAME                  |":\
        :T187="|              Your IP address: %IP                    |":\
        :T188="|                                                      |":\
        :T189="+------------------------------------------------------+":\
        :T190="ESC[37m":


Would show

        +------------------------------------------------------+
        |                Welcome to station7                   |
        |              Your IP address: 10.100.0.7             |
        |                                                      |
        +------------------------------------------------------+


Thanks for the great software!

Dax

Re: [Etherboot-developers] None fallback to hard disk, when BOOTP is ok, but TFTP fails

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

Andreas Roscher <aro...@ar...> writes:

> I have add three simple lines to main.c to support this automatic
> fallback.
> By this way, I have now the same behavior like the netboot boot code or
> commercial boot code (e.g. from the company incom).

I'm assuming you mean the the #ifdef EMERGENCYDISKBOOT lines.
A more comprehensive version of this is in 5.1.0 Check it out.

Eric

[Etherboot-developers] None fallback to hard disk, when BOOTP is ok, but TFTP fails

[Andreas R. <aro...@ar...>]

I have add three simple lines to main.c to support this automatic
fallback.
By this way, I have now the same behavior like the netboot boot code or
commercial boot code (e.g. from the company incom).


        for (;;) {
                const char      *kernel;

                kernel = KERNEL_BUF[0] != '\0' ? KERNEL_BUF :
DEFAULT_BOOTFILE;
                printf("Loading %I:%s ", arptable[ARP_SERVER].ipaddr,
kernel);
                while (!loadkernel(kernel)) {
                        printf("Unable to load file.\n");
                        sleep(2);       /* lay off server for a while */

#ifdef  EMERGENCYDISKBOOT
                        exit(0);
#endif
                      }
       }


--
Andreas Roscher --- President AROSOFT network GmbH
OMA install computers in 5 minutes (PC, Sun Systems, SGI, HP ....)
No more hand made management. Save your money for other things.
http://www.arosoft.de

[Etherboot-developers] Re: mknbi fails with 2.4.5, initrd, and machines with a load of RAM

[Tim S. <ti...@di...>]

ke...@us... <mailto:ke...@us...> wrote:

>>We have some machines here which we are using Etherboot/ mknbi to boot 
>>remotely.  The machines have 1G of RAM, and are failing to boot from an 
>>initrd image because mknbi appears to be shoving it too high up in 
>>memory.  I'm going to have a go at fixing it, but my x86 assembly skills 
>>are pretty much non-existant ;-).  Here's what the bootup log says:
>>
>>Linux version 2.4.5 (ro...@vi... <mailto:ro...@vi...>) (gcc version 2.95.4 20010319 
>>(Debian prerelease)) #1941 SMP Tue Jun 12 13:07:35 BST 2001
>>BIOS-provided physical RAM map:
>>BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
>>BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
>>BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
>>BIOS-e820: 0000000000100000 - 000000003fff0000 (usable)
>>BIOS-e820: 000000003fff0000 - 000000003fff8000 (ACPI data)
>>BIOS-e820: 000000003fff8000 - 0000000040000000 (ACPI NVS)
>>BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
>>BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
>>BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
>>127MB HIGHMEM available.
>>
>>....
>>
>>initrd extends beyond end of memory (0x3fff0000 > 0x38000000)
>>disabling initrd
>>
>>...
>>
>>Memory: 1028240k/1048512k available (1368k kernel code, 19884k reserved, 
>>479k data, 240k init, 131008k highmem)
>>
>
>What's probably happening is that first32.linux's algorithm for working
>out the memory size is not sufficiently comprehensive. The Linux kernel
>tries a few BIOS calls, first32.linux only uses two (of which e820 is
>not one) and probably doesn't take into account the holes.
>start32.S:memsize is probably what needs to be enhanced, using the code
>in the kernel's setup.S as a guide.
>
I'm pretty sure the later is beyond me.  I'm also not sure it would fix 
the problem, as the kernel then makes a decision about where it 
considers highmem to start, and won't like the initrd being above this. 
 I could probably manage a dirty hack to make sure it doesn't get moved 
to beyond 512M (or 768M - or some other semi-arbitary number - with 512M 
of RAM, this box boots fine) - but I would imagine this is not of much 
interest to anyone but myself ;-).

Cheers,

Tim.

Re: [Etherboot-developers] Patch to add passing FreeBSD kernel environment

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

>| Although I'm happy to accept the patch as is but with the buffer reduced
>| from 1024 to 256 bytes. An overhead of 256 bytes of data + tens of bytes
>| of code I can live with, especially as it falls on the FreeBSD booters,
>| not the Linux booters. :-) But in the long term, a third stage for
>| FreeBSD would allow functionality to be moved there.
>
>Sounds fair.  Would you like me to resubmit it with that change?

It's ok, I can do s/1024/256/ manually.

Re: [Etherboot-developers] Patch to add passing FreeBSD kernel environment

[Doug A. <amb...@am...>]

ke...@us... writes:
| >> So you are saying that the third stage loader can access the network to
| >> send and receive packets?  Before when I looked at it I don't recall
| >> it doing that.
| >
| >The third stage has access to the DHCP results so it shouldn't need
| >to do any send/receive.  Just parse out the DHCP options.
| 
| Although I'm happy to accept the patch as is but with the buffer reduced
| from 1024 to 256 bytes. An overhead of 256 bytes of data + tens of bytes
| of code I can live with, especially as it falls on the FreeBSD booters,
| not the Linux booters. :-) But in the long term, a third stage for
| FreeBSD would allow functionality to be moved there.

Sounds fair.  Would you like me to resubmit it with that change?

Thanks,

Doug A.

[Etherboot-developers] Re: mknbi fails with 2.4.5, initrd, and machines with a load of RAM

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

[Problem reports should always to go the mailing lists so that more
brains can ponder the problem. I'm moving the discussion there.]

>We have some machines here which we are using Etherboot/ mknbi to boot 
>remotely.  The machines have 1G of RAM, and are failing to boot from an 
>initrd image because mknbi appears to be shoving it too high up in 
>memory.  I'm going to have a go at fixing it, but my x86 assembly skills 
>are pretty much non-existant ;-).  Here's what the bootup log says:
>
>Linux version 2.4.5 (ro...@vi...) (gcc version 2.95.4 20010319 
>(Debian prerelease)) #1941 SMP Tue Jun 12 13:07:35 BST 2001
>BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
> BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
> BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 000000003fff0000 (usable)
> BIOS-e820: 000000003fff0000 - 000000003fff8000 (ACPI data)
> BIOS-e820: 000000003fff8000 - 0000000040000000 (ACPI NVS)
> BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
> BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
> BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
>127MB HIGHMEM available.
>
>....
>
>initrd extends beyond end of memory (0x3fff0000 > 0x38000000)
>disabling initrd
>
>...
>
>Memory: 1028240k/1048512k available (1368k kernel code, 19884k reserved, 
>479k data, 240k init, 131008k highmem)

What's probably happening is that first32.linux's algorithm for working
out the memory size is not sufficiently comprehensive. The Linux kernel
tries a few BIOS calls, first32.linux only uses two (of which e820 is
not one) and probably doesn't take into account the holes.
start32.S:memsize is probably what needs to be enhanced, using the code
in the kernel's setup.S as a guide.

Re: [Etherboot-developers] Patch to add passing FreeBSD kernel environment

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

>That doesn't really buy anything.  Might just as well pass that string
>into the kernel and let the kernel parse them out.  I don't see a point
>for a 3rd stage loader that doesn't do anything.  It's easy enough to 
>load things into memory and then jump into the image.  Then you don't
>have to do a mk{nbi,elf}-linux which seems kind of strange to me but then

The reason a mk{nbi,elf}-linux is needed is because the Linux kernel
image has a strange layout which would require code to understand. Also
the kernel image has no provision for storing any parameters. This
parsing code doesn't belong in Etherboot, which should be just a loader.
A similar argument applies to DOS images. So either the extra work is
done by an image builder and a third stage, or as in PXE you load a
target specific second stage which does the rest.

>it seems strange to me to have to run lilo whenever you build a kernel or 
>want to load a different kernel vs. just loading a kernel I want.  I just
>point /tftpboo/kernel<foo> into my kernel tree and it gets auto updated.
>It's an easy way with the menu stuff to manage several different kernels.

Fair enough, but Etherboot is not PXE. If somebody wants to hack PXE
functionality in, feel free to contribute.

>Then there is the issue the kernel might want a different set of parameters 
>then EtherBoot.  To keep things to a minimum EtherBoot should only request 
>the things it deals with.  The 3rd stage should only request the things it 
>needs.  The kernel should only request the things it needs.  Then at the 
>OS level it should only request the things it needs.

Well it almost works like that actually, Etherboot does a request, and
the kernel can also do a request, and user space programs can do a
request too. In fact, if you want to get things like NIS server or the
other options which Etherboot doesn't use, you have to make an extra
request. Only the third stage doesn't do any requests at the moment.
Etherboot's third stage isn't an independent executable, more like a
chained segment.

>Obviously this is going to the extreme but DHCP options are starting to
>get very long so now I break them out on vendor identifiers so my DHCP
>packets are shorter.

To actually get significantly more space you would have to use the
overload option to tell the DHCP server not to send the filename and
hostname in the reserved fields, but as options, so that the reserved
fields can be collapsed. Overall you are limited by the 1500 bytes of
the Ethernet packet anyway. And the 1 byte length field.

Re: [Etherboot-developers] Patch to add passing FreeBSD kernel environment

[Doug A. <amb...@am...>]

Eric W. Biederman writes:
| Doug Ambrisko <amb...@am...> writes:
| 
| > Donald J Christensen writes:
| > | There is a third stage bootloader program that is included in a
| > | tagged image by mk{nbi,elf}-linux.  That is where the option processing
| > | currently happens, I believe.  The size restrictions are more relaxed
| > | on this than on Etherboot (with a little effort, you can easily get
| > | 64KB to run it in.)
| > | 
| > | I would suggest modifying first32.c or adding a new implementation that
| > | does what you need.
| > 
| > So you are saying that the third stage loader can access the network to
| > send and receive packets?  Before when I looked at it I don't recall
| > it doing that.
| 
| The third stage has access to the DHCP results so it shouldn't need
| to do any send/receive.  Just parse out the DHCP options.

That doesn't really buy anything.  Might just as well pass that string
into the kernel and let the kernel parse them out.  I don't see a point
for a 3rd stage loader that doesn't do anything.  It's easy enough to 
load things into memory and then jump into the image.  Then you don't
have to do a mk{nbi,elf}-linux which seems kind of strange to me but then
it seems strange to me to have to run lilo whenever you build a kernel or 
want to load a different kernel vs. just loading a kernel I want.  I just
point /tftpboo/kernel<foo> into my kernel tree and it gets auto updated.
It's an easy way with the menu stuff to manage several different kernels.

Then there is the issue the kernel might want a different set of parameters 
then EtherBoot.  To keep things to a minimum EtherBoot should only request 
the things it deals with.  The 3rd stage should only request the things it 
needs.  The kernel should only request the things it needs.  Then at the 
OS level it should only request the things it needs.

Obviously this is going to the extreme but DHCP options are starting to
get very long so now I break them out on vendor identifiers so my DHCP
packets are shorter.

PXE UNDI is kind-of nice since it loads a loader and then an image.
So for DOS you put a raw disk image in the tftpboot area and you 
can mount and modify that on the fly.

Doug A.

Re: [Etherboot-developers] Patch to add passing FreeBSD kernel environment

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

>> So you are saying that the third stage loader can access the network to
>> send and receive packets?  Before when I looked at it I don't recall
>> it doing that.
>
>The third stage has access to the DHCP results so it shouldn't need
>to do any send/receive.  Just parse out the DHCP options.

Although I'm happy to accept the patch as is but with the buffer reduced
from 1024 to 256 bytes. An overhead of 256 bytes of data + tens of bytes
of code I can live with, especially as it falls on the FreeBSD booters,
not the Linux booters. :-) But in the long term, a third stage for
FreeBSD would allow functionality to be moved there.

Re: [Etherboot-developers] Patch to add passing FreeBSD kernel environment

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

Doug Ambrisko <amb...@am...> writes:

> Donald J Christensen writes:
> | Doug Ambrisko wrote:
> | > 
> | > Eric W. Biederman writes:
> | > | least would put the complexity in mknbi.  I hate to see etherboot
> | > | clutered up with OS specific code, when it has size constraints.
> | > |
> | > | If we could download that code etherboot get to stay smaller.
> | > 
> | > Note that it is all hidden under #define for FreeBSD so if you don't have
> | > FreeBSD defined then there is no impact.  The size if the same.
> | > 
> | > Well we sort-of have that type of thing.  It's called the third stage loader
> 
> | > and is PXE compliant.  If EtherBoot or Nilo or whatever exposed a PXE
> | > compliant environment then this would be done.  I don't see how mknbi
> | > is going to help since it at best passes static info to whatever it loads
> | > and they is no network API exposed to it to send and receive packets.
> | 
> | There is a third stage bootloader program that is included in a
> | tagged image by mk{nbi,elf}-linux.  That is where the option processing
> | currently happens, I believe.  The size restrictions are more relaxed
> | on this than on Etherboot (with a little effort, you can easily get
> | 64KB to run it in.)
> | 
> | I would suggest modifying first32.c or adding a new implementation that
> | does what you need.
> 
> So you are saying that the third stage loader can access the network to
> send and receive packets?  Before when I looked at it I don't recall
> it doing that.

The third stage has access to the DHCP results so it shouldn't need
to do any send/receive.  Just parse out the DHCP options.

Eric

Re: [Etherboot-developers] Patch to add passing FreeBSD kernel environment

[Doug A. <amb...@am...>]

Donald J Christensen writes:
| Doug Ambrisko wrote:
| > 
| > Eric W. Biederman writes:
| > | least would put the complexity in mknbi.  I hate to see etherboot
| > | clutered up with OS specific code, when it has size constraints.
| > |
| > | If we could download that code etherboot get to stay smaller.
| > 
| > Note that it is all hidden under #define for FreeBSD so if you don't have
| > FreeBSD defined then there is no impact.  The size if the same.
| > 
| > Well we sort-of have that type of thing.  It's called the third stage loader
| > and is PXE compliant.  If EtherBoot or Nilo or whatever exposed a PXE
| > compliant environment then this would be done.  I don't see how mknbi
| > is going to help since it at best passes static info to whatever it loads
| > and they is no network API exposed to it to send and receive packets.
| 
| There is a third stage bootloader program that is included in a
| tagged image by mk{nbi,elf}-linux.  That is where the option processing
| currently happens, I believe.  The size restrictions are more relaxed
| on this than on Etherboot (with a little effort, you can easily get
| 64KB to run it in.)
| 
| I would suggest modifying first32.c or adding a new implementation that
| does what you need.

So you are saying that the third stage loader can access the network to
send and receive packets?  Before when I looked at it I don't recall
it doing that.

Doug A.

Re: [Etherboot-developers] Patch to add passing FreeBSD kernel environment

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

Doug Ambrisko wrote:
> 
> Eric W. Biederman writes:
> | least would put the complexity in mknbi.  I hate to see etherboot
> | clutered up with OS specific code, when it has size constraints.
> |
> | If we could download that code etherboot get to stay smaller.
> 
> Note that it is all hidden under #define for FreeBSD so if you don't have
> FreeBSD defined then there is no impact.  The size if the same.
> 
> Well we sort-of have that type of thing.  It's called the third stage loader
> and is PXE compliant.  If EtherBoot or Nilo or whatever exposed a PXE
> compliant environment then this would be done.  I don't see how mknbi
> is going to help since it at best passes static info to whatever it loads
> and they is no network API exposed to it to send and receive packets.

There is a third stage bootloader program that is included in a
tagged image by mk{nbi,elf}-linux.  That is where the option processing
currently happens, I believe.  The size restrictions are more relaxed
on this than on Etherboot (with a little effort, you can easily get
64KB to run it in.)

I would suggest modifying first32.c or adding a new implementation that
does what you need.

-Don

--
Don Christensen    Senior Software Development Engineer
  dj...@ci...    MMABU - Mid-Market Access Business Unit
  Cisco Systems    ComLOB - Commercial Line of Business
   San Jose, CA    "So much relies on the course that you take
                   The fool and the wise man both burn at the stake"

Re: [Etherboot-developers] Patch to add passing FreeBSD kernel environment

[Doug A. <amb...@am...>]

ke...@us... writes:
| >that the reply fits in the buffer. This way you can replace the 1024
| >byte global buffer with a pointer and an int.
| 
| Oh and I don't think you can pass more than 255 bytes of environment
| since the DHCP option length is one byte.

Good point but I should save of 256 for the trailing null.

Doug A.