etherboot-developers — Discussion of developer issues

[Etherboot-developers] Re: [Ltsp-discuss] Adventures with Etherboot, DHCP, PXE

[Rudhuwan A. B. <du...@mi...>]

On Sun, 8 Jul 2001, Marty Connor wrote:

> Managed PC Boot Agent (MBA) v4.00
> (C) Copyright 1999 Lanworks Technologies Co. a subsidiary of 3Com 
> Corporation
> All rights reserved.
> 
> Pre-boot eXecution Environment (PXE) v2.00
> (C) Copyright 1999 Intel Corporation.
> (C) Copyright 1999 Lanworks Technologies Co. a subsidiary of 3Com 
> Corporation
> All rights reserved.
> 
> DHCP MAC ADDR: 00 01 02 C1 79 C7
> DHCP....
> CLIENT IP: 192.168.4.100  MASK: 255.255.255.0  DHCP IP: 192.168.4.1
> GATEWAY IP: 192.168.4.1
> PXE loader for etherboot(with ZLOADER)
> PXENV+ unloaded
> ROM segment 0x07C0 length 0x3000 reloc 0x9400
> Etherboot 5.0.2 (GPL) Tagged ELF for [3C90X]
> Boot from (N)etwork or from (L)ocal? N
> Found 3Com905C-TXM at 0xDC00, ROM address 0xE300
> Probing...[3C90X]
> 
> 3C90X Driver 2.00 Copyright 1999 LightSys Technology Services, Inc.
> Portions Copyright 1999 Steve Smith
> Provided with ABSOLUTELY NO WARRANTY.
> ---------------------------------------------------------------------------
> -------
> MAC Address - 00:01:02:C1:79:C7
> Connectors present: 10Base-T / 100Base-TX.
> Searching for server (DHCP)...
> Me: 192.168.4.100, Server: 192.168.4.1, Gateway 192.168.4.1
> Loading 192.168.4.1:/tftpboot/bootImage-rt (NBI)... done
> 
> Linux Net Boot Image Loader Version 0.8.1 (netboot)
> Copyright (C) 1996,1997 G. Kuhlmann and M. Gutschke
> Copyright (C) 1995-1998 G. Kuhlmann
> 
> Searching for server (DHCP)...
> Me: 192.168.4.100, Server: 192.168.4.1, Gateway 192.168.4.1
> Loading 192.168.4.1:/tftpboot/lts/vmlinuz-test.nbi (NBI)... done

Firstly, Thanks to Marty it works like charm BUT...:)

I am using Redhat 6.2 with rtl8139 chipset. I configured my dhcp as Marty
had shown in his email.Got the mknbi.1.2.x. The client can boot using PXE
to load the etherboot.

The problem I got when the client boots up, it freezes at

Freeing unused kernel memory: 44K freed
Warning: unable to open an initial console
Kernel panic.No init found.Try passing init=option to kernel 

Not sure where to look for what causes the error.Hope Marty can give some
pointers.

Thanks

Re: [Etherboot-developers] Confirmation of fix!

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

>> + Load %edx with dev just before calling xstart in floppy.c:bootdisk()
>> so that %dl will have device number, just like entry from BIOS.
>
>With this change, my "rekickstart" script discussed earlier now works.

Excellent, one bug down, infinity to go. :-)

[Etherboot-developers] Confirmation of fix!

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

On Sun, 8 Jul 2001, ke...@us... wrote:

> + Load %edx with dev just before calling xstart in floppy.c:bootdisk()
> so that %dl will have device number, just like entry from BIOS.

With this change, my "rekickstart" script discussed earlier now works.

Many thanks!

Dax

Re: [Etherboot-developers] Re: Adventures with Etherboot, DHCP, PXE, and LTSP

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

>It looks even easier than PXE. The RPL config file looks like it has
>enough features to specify portions of files and their memory
>destination.  So you could take disnbi and hack it to generate a config
>file fragment for a tagged image. So there you are, you could be 5
>minutes hacking away from fame and glory. Just buy me a beer when you
>get there. :-)

Another way to do it might be simply to load an Etherboot .lzrom image
at 0x10000 and then jump to 0x10006. There should be less complications
than with PXE because AFAIK it doesn't use DHCP.

[Etherboot-developers] Re: Adventures with Etherboot, DHCP, PXE, and LTSP

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

>>2) Do you think it would be possible to do a similar thing using
>>   RPL instead of PXE ?  I haven't a clue where to start, but there
>>   sure are alot of motherboards out there with RPL embedded, and it
>>   would be cool to do the 'RPL->Etherboot->Linux' trick.
>
>Check out:
>
>   http://gimel.esc.cam.ac.uk/james/rpld/index.html
>
>It looks ugly, but apparently they got something to work.  With some 
>work, one could probably fool RPL cards into loading Etherboot.  
>
>Who wants a chance at fame and glory? :-)

It looks even easier than PXE. The RPL config file looks like it has
enough features to specify portions of files and their memory
destination.  So you could take disnbi and hack it to generate a config
file fragment for a tagged image. So there you are, you could be 5
minutes hacking away from fame and glory. Just buy me a beer when you
get there. :-)

PS: Ah, actually it doesn't seem to allow arguments to be passed to
loaded programs so you may need to forget about first32.c and devise
some other way to pass kernel arguments eventually.

[Etherboot-developers] Re: [Ltsp-discuss] Re: [Etherboot-users] Adventures with Etherboot, DHCP, PXE, and LTSP

[Georg B. <Geo...@po...>]

Am Montag,  9. Juli 2001 03:23 schrieb Marty Connor:
> depending on the card, you'd be adding a few seconds.  The PXE spec is
> available at Intel.  I think you can even read it without signing an NDA.

It is directly available at ftp://download.intel.com/ial/wfm/pxespec.pdf.

Some more info is at http://developer.intel.com/ial/wfm/tools/index.htm.


Georg

[Etherboot-developers] Re: [Etherboot-users] Adventures with Etherboot, DHCP, PXE, and LTSP

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

On 7/8/2001 6:18 PM Jim McQuillan ja...@mc... wrote:
>1) Do you have an estimate of how the 'Double' boot affects the
>   boot time?  I'm guessing only a second or two.

PXE is an umm, "interesting" (notice how I avoided saying "horribly 
broken" :-) protocol.  It seems to do three DHCP probes, and "picks" the 
one it likes best.  So it seems to take about 6 seconds to figure out 
what to do.  Etherboot takes no seconds (after the timeout).  So I guess, 
depending on the card, you'd be adding a few seconds.  The PXE spec is 
available at Intel.  I think you can even read it without signing an NDA. 
 But the developer's kit requires some sort of the agreement with Intel.  
I'm not into NDA's, in general.

>2) Do you think it would be possible to do a similar thing using
>   RPL instead of PXE ?  I haven't a clue where to start, but there
>   sure are alot of motherboards out there with RPL embedded, and it
>   would be cool to do the 'RPL->Etherboot->Linux' trick.

Check out:

   http://gimel.esc.cam.ac.uk/james/rpld/index.html

It looks ugly, but apparently they got something to work.  With some 
work, one could probably fool RPL cards into loading Etherboot.  

Who wants a chance at fame and glory? :-)

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] Re: [Etherboot-users] Adventures with Etherboot, DHCP, PXE, and LTSP

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

Marty,

Great description of how all this stuff works.  I thoroughly 
enjoyed reading through it.

I have 2 questions for you:

1) Do you have an estimate of how the 'Double' boot affects the
   boot time?  I'm guessing only a second or two.

2) Do you think it would be possible to do a similar thing using
   RPL instead of PXE ?  I haven't a clue where to start, but there
   sure are alot of motherboards out there with RPL embedded, and it
   would be cool to do the 'RPL->Etherboot->Linux' trick.

Thanks,

Jim McQuillan
ja...@Lt...

Marty Connor wrote:
> 
> Write a driver or play with the PXE stuff... Write a driver or play with
> the PXE stuff...
> 
> I was deciding what to do this weekend when in came a message about
> someone trying to use the Etherboot/PXE feature, so I decided I'd look at
> that.
> 
> What follows is a description of that process.
> 
> Executive Summary:
> 
> I got it to work.  Two PXE cards (a 3COM and an Intel) with PXE built in
> were able to boot by loading Etherboot and the letting Etherboot do the
> kernel load. Sweet.
> 
  SNIPPED

[Etherboot-developers] Adventures with Etherboot, DHCP, PXE, and LTSP

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

Write a driver or play with the PXE stuff... Write a driver or play with 
the PXE stuff...

I was deciding what to do this weekend when in came a message about 
someone trying to use the Etherboot/PXE feature, so I decided I'd look at 
that.

What follows is a description of that process.

Executive Summary:

I got it to work.  Two PXE cards (a 3COM and an Intel) with PXE built in 
were able to boot by loading Etherboot and the letting Etherboot do the 
kernel load. Sweet.

If you want to hear the tale, read on.  You're probably used to my 
messages by now ;-)

Background:

Etherboot and PXE are two pieces of software that allow one to boot a 
workstation over a network.  Some other ways exist like Netboot and RPL. 
I mostly understand Etherboot because I like to work with Free Software.  

I've got two pristine, fancy, expensive ethernet cards that I use for 
testing:

  - 3COM 3C905C-TXM
  - Intel EEPRO100+

These cards have flash memory on them, with code that will boot the 
workstation connected to them.  They both have PXE as a boot method.

Now, a while back, we in the Etherboot project had developed the 
technology to reprogram the flash memory on the cards with Etherboot.

For the 3COM card, see:

   http://www.rom-o-matic.net/5.0.2/contrib/3c90xutil/

and for the Intel EEPRO100 see:

   http://www.rom-o-matic.net/5.0.2/contrib/eepro100notes/

There are also motherboards that have PXE flashed in them, like the 
ThinkNIC computer.  Perhaps someday they will have Etherboot as well.

Reflashing cards and BIOSes is not possible sometimes, either for 
technical reasons, or because people want to be able to the original PXE 
code.  It also requires some work inside the case of the computer, and we 
don't have tools to reflash all BIOSes.  

So, to create a way to use PXE cards and BIOSes without reprogramming 
them, Peter Lister and Vasil Vasilev recently asked the question "Why 
can't PXE code load Etherboot and let Etherboot take over?".  They then 
wrote the code to make it happen, and so now you can build a ".lzpxe" 
image and when your PXE ROM or BIOS loads the file, it will actually be 
starting Etherboot, and you can use your Etherboot environment.  

Peter and Vasil rock.

The Goal:

I wanted to boot both cards (3C905C-TXM and EEPRO100) using PXE to load 
Etherboot, and have Etherboot load the kernel and start it.  From there, 
it is up to LTSP or whatever software is handling the session.  Once the 
kernel loads and starts, Etherboot has done its job.

"DHCP for people of reasonable intelligence...
               who can't read the documentation" ;-) :

When PXE and Etherboot start running, they are both looking for the same 
thing: A DHCP server.  They need some information, like their IP address, 
a name server, the server where they should load a boot file, and the 
path to that file, and various other things.

The thing is, that the DHCP server needs to be able to know if it is PXE 
asking for information, or if it is Etherboot asking.

If it is PXE calling, we should hand it a file name to a ".lzpxe" file, 
which is an Etherboot image wrapped in a form PXE can load.  If however 
it is Etherboot calling, we want to hand it a ".nbi" or network bootable 
image, a linux kernel that has been wrapped using mknbi-linux, or a DOS 
image made with mknbi-dos.  mknbi is available for download on the 
Etherboot download page at:

   http://etherboot.sourceforge.net/distribution.html

Alright, so let's look at the parts we need:

   - DHCP Server
   - TFTP Server
   - PXE Ethernet cards
   - mknbi package
   - Tagged kernel (prepared with mknbi-linux)
   - .lzpxe image (from rom-o-matic.net or made with Etherboot v5.0.2 + 
Patches)

The DHCP Server needs to be able to differentiate between PXE Clients and 
Etherboot Clients.  I want to keep things simple.  I want to be able to 
say:

  host ws137 {
      hardware ethernet     00:02:B3:25:45:56;
      fixed-address         192.168.2.137;
      if        substring (option vendor-class-identifier, 0, 9) = 
"PXEClient" {
            filename "/tftpboot/eepro100.lzpxe"; 
      } else if substring (option vendor-class-identifier, 0, 9) = 
"Etherboot" {
          filename "/tftpboot/lts/vmlinuz-test.nbi"; 
          option vendor-encapsulated-options 
3c:09:45:74:68:65:72:62:6f:6f:74:ff;
      }
  }

It turns out that ISC DHCPD version 3 
(http://www.isc.org/products/DHCP/dhcp-v3.html) can do this. Version 2, 
which is what I had on my Progeny Debian machine cannot (at least not 
this way.  If someone knows how to do something like this in v2.x, please 
let us know).

So I had to upgrade my DHCPD to v3.0.  I downloaded the package from:

   ftp://ftp.isc.org/isc/dhcp/dhcp-latest.tar.gz

I then enabled root privs and moved the file to /usr/src/local and did:

   mv dhcp-latest.tar.gz dhcp-3.0rc10.tar.gz

I then did:

   tar -zxvf dhcp-3.0rc10.tar.gz

to unpack it.  This gave me a directory called dhcp-3.0rc10 so I did:

   cd dhcp-3.0rc10
   more README
   ./configure
   make
   make install

This gave me new version of /usr/sbin/dhcpd . I then did

   touch /var/state/dhcp/dhcpd.leases

and

   /etc/init.d/dhcp restart

to start up my new DHCP daemon.  I checked 

   /var/log/daemon.log

to make sure everything was alright with the DHCP startup:

Jul  8 15:05:42 ll dhcpd: Internet Software Consortium DHCP Server 
V3.0rc10
Jul  8 15:05:42 ll dhcpd: Copyright 1995-2001 Internet Software 
Consortium.
Jul  8 15:05:42 ll dhcpd: All rights reserved.
Jul  8 15:05:42 ll dhcpd: For info, please visit 
http://www.isc.org/products/DHCP
Jul  8 15:05:42 ll dhcpd: Wrote 0 deleted host decls to leases file.
Jul  8 15:05:42 ll dhcpd: Wrote 0 new dynamic host decls to leases file.
Jul  8 15:05:42 ll dhcpd: Wrote 0 leases to leases file.
Jul  8 15:05:42 ll dhcpd: Listening on 
LPF/eth0/00:50:ba:77:1d:9f/testingnet
Jul  8 15:05:42 ll dhcpd: Sending on   
LPF/eth0/00:50:ba:77:1d:9f/testingnet
Jul  8 15:05:42 ll dhcpd: Sending on   Socket/fallback/fallback-net

Now I needed a new /etc/dhcpd.conf file.  I wanted to make the simplest 
file I could, and not use all the whizzy new features of v3.0.  If I 
could have used v2.x I would have, but I couldn't figure out how to 
cleanly do the conditional (the "if" statement) that I wanted to use.  So 
I made a very simple /etc/dhcpd.conf file.  Heck, I don't even claim to 
know very much about DHCP.  (why are you reading this? :-)

Here is what my /etc/dhcpd.conf file looks like:

# Configuration file for ISC dhcpd v3.0

not authoritative;
ddns-update-style             none;             # required for ISC v3.0

shared-network testingnet {
    subnet 192.168.2.0 netmask 255.255.255.0 {
    }
}

group   {

    default-lease-time            21600;
    max-lease-time                21600;
    use-host-decl-names           on;

    option domain-name            "thinguin.net";
    option subnet-mask            255.255.255.0;
    option broadcast-address      192.168.2.255;
    option routers                192.168.2.1;
    option domain-name-servers    192.168.2.56;
    option log-servers            192.168.2.56;
    option root-path              "/tftpboot/lts/ltsroot";

    host ws121 {
        hardware ethernet     00:80:C6:F8:AB:2A;
        fixed-address         192.168.2.121;
        filename              "/tftpboot/lts/vmlinuz.all";
    }
    host ws136 {
        hardware ethernet     00:01:02:c1:79:c7;
        fixed-address         192.168.2.136;
        if        substring (option vendor-class-identifier, 0, 9) = 
"PXEClient" {
            filename              
"/tftpboot/eb-5.0.2-mc1-3c905c-tpo.lzpxe"; 
        } else if substring (option vendor-class-identifier, 0, 9) = 
"Etherboot" {
            filename              "/tftpboot/lts/vmlinuz-test.nbi"; 
            option vendor-encapsulated-options 
3c:09:45:74:68:65:72:62:6f:6f:74:ff;
        }
    }
    host ws137 {
        hardware ethernet     00:02:B3:25:45:56;
        fixed-address         192.168.2.137;
        if        substring (option vendor-class-identifier, 0, 9) = 
"PXEClient" {
            filename "/tftpboot/eepro100.lzpxe"; 
        } else if substring (option vendor-class-identifier, 0, 9) = 
"Etherboot" {
            filename "/tftpboot/lts/vmlinuz-test.nbi"; 
            option vendor-encapsulated-options 
3c:09:45:74:68:65:72:62:6f:6f:74:ff;
        }
    }

} # group


Let's walk through this, a piece at a time.  This is all explained in the 
DHCP documentation, but I'll try to break it down even more for people 
who can't hack that.

  # Configuration file for ISC dhcpd v3.0
  not authoritative;

The "not authoritative;" line is there because I don't want my DHCP 
server to be giving out information to hosts on my network that it 
doesn't have information for.  Some DHCP clients get confused when a DHCP 
server NAKs (say NO!).  If you're setting up a server to serve Etherboot 
clients, and you don't want to interfere with another DHCP server, you 
need to say "not authoritative;"  (even with version 2.x of ISC DHCPD).  
You'll be glad you did.

  ddns-update-style             none;             # required for ISC v3.0

This is required for ISC DHCPD v3.0.  It has to do with dynamic DNS 
updates.  If you really care, you can read the documentation.  ddns lets 
you tell your DNS server what a host's address is or what host is at an 
address.  Since my hosts have fixed addresses, I don't worry about this.  
You have to say something, however.

  shared-network testingnet {
      subnet 192.168.2.0 netmask 255.255.255.0 {
      }
  }

This defines the subnet that I'm interested in serving information about.

  group   {

The "group" tag just says that I'm going to be talking about some hosts 
who are related in some way.  

    default-lease-time            21600;
    max-lease-time                21600;

These two lines set some parameters for DHCP leases.

    use-host-decl-names           on;

This says to send to the client the name defined by the "host" statement 
as the host's name.  If I didn't include it, I'd have to explicitly put a 
statement naming each host in its "host" entry.

    option domain-name            "thinguin.net";
    option subnet-mask            255.255.255.0;
    option broadcast-address      192.168.2.255;
    option routers                192.168.2.1;
    option domain-name-servers    192.168.2.56;
    option log-servers            192.168.2.56;
    option root-path              "/tftpboot/lts/ltsroot";

These are pretty self-explanatory, or you can check the DHCPD doc.

Now the good stuff:

    host ws135 {
        hardware ethernet     00:a0:cc:a0:e6:5b;
        fixed-address         192.168.2.135;
        filename              "/tftpboot/lts/vmlinuz.all";
    }

This is for a normal ethernet card.  It's a Netgear FA312.  It has no 
PXE, and Etherboot is the only thing that would be asking the DHCP server 
about it. Since everything else it needs to know has been defined above 
just under the "group" tag, we just add the three things it needs and 
away it goes.

    host ws136 {
        hardware ethernet     00:01:02:c1:79:c7;
        fixed-address         192.168.2.136;
        if        substring (option vendor-class-identifier, 0, 9) = 
"PXEClient" {
            filename              
"/tftpboot/eb-5.0.2-mc1-3c905c-tpo.lzpxe"; 
        } else if substring (option vendor-class-identifier, 0, 9) = 
"Etherboot" {
            filename              "/tftpboot/lts/vmlinuz-test.nbi"; 
            option vendor-encapsulated-options 
3c:09:45:74:68:65:72:62:6f:6f:74:ff;
        }
    }

OK, this is what you've been waiting for.  This is for the 3C905C-TXM 
card. It's like the card above, except that it starts up with PXE.  So, 
what we do is to check to see who is calling from this hardware address 
(00:01:02:c1:79:c7).  You see, when PXE starts up, it sends "PXEClient" 
in its DHCP message.  So if we see that, we send back a file name of 
"/tftpboot/eb-5.0.2-mc1-3c905c-tpo.lzpxe", which is an Etherboot image 
that PXE can load.  PXE loads it, and it promptly unloads PXE and gives 
control to Etherboot. (so much of life is bootstrapping, after all :-).

Now, Etherboot starts up, and the first thing it does is to send a DHCP 
request.  In this case, the "else if" part of the conditional gets run, 
and we hand back (among other things):

       filename              "/tftpboot/lts/vmlinuz-test.nbi"; 
       option vendor-encapsulated-options 
3c:09:45:74:68:65:72:62:6f:6f:74:ff;

The "filename" part is obvious.  That's a Linux kernel.  The next part:

      option vendor-encapsulated-options 
3c:09:45:74:68:65:72:62:6f:6f:74:ff;

is not so obvious.

Here's the problem.  What if you have two DHCP servers on the network, 
and you want to make sure that your server is the one that your Etherboot 
clients choose.  How do you guarantee that it will reject replies from 
the other DHCP server?

Well, you first set the option: REQUIRE_VCI_ETHERBOOT when you make your 
".lzpxe" image (or Configure it at rom-o-matic.net).  This tells 
Etherboot to ignore any reply that doesn't contain the VCI (vendor class 
identifier) "Etherboot".  Then you add the line:

      option vendor-encapsulated-options 
3c:09:45:74:68:65:72:62:6f:6f:74:ff;

to your "host" entry.  This says "send the VCI 'Etherboot' back to the 
requesting client".  So now you can be pretty sure your client will be 
talking to the right DHCP server.  

Put it all together and you get:

    host ws136 {
        hardware ethernet     00:01:02:c1:79:c7;
        fixed-address         192.168.2.136;
        if        substring (option vendor-class-identifier, 0, 9) = 
"PXEClient" {
            filename              
"/tftpboot/eb-5.0.2-mc1-3c905c-tpo.lzpxe"; 
        } else if substring (option vendor-class-identifier, 0, 9) = 
"Etherboot" {
            filename              "/tftpboot/lts/vmlinuz-test.nbi"; 
            option vendor-encapsulated-options 
3c:09:45:74:68:65:72:62:6f:6f:74:ff;
        }
    }

Smoke test:

I put in the 3COM card, set it to do PXE.  Did "/etc/init.d/dhcp restart" 
to restart my DHCPD.  and rebooted my workstation.

Here's what I get  [fake screen shot, yes i typed it all in by hand]:

Managed PC Boot Agent (MBA) v4.00
(C) Copyright 1999 Lanworks Technologies Co. a subsidiary of 3Com 
Corporation
All rights reserved.

Pre-boot eXecution Environment (PXE) v2.00
(C) Copyright 1999 Intel Corporation.
(C) Copyright 1999 Lanworks Technologies Co. a subsidiary of 3Com 
Corporation
All rights reserved.

DHCP MAC ADDR: 00 01 02 C1 79 C7
DHCP....
CLIENT IP: 192.168.2.136  MASK: 255.255.255.0  DHCP IP: 192.168.2.56
GATEWAY IP: 192.168.2.1
PXE loader for etherboot(with ZLOADER)
PXENV+ unloaded
ROM segment 0x07C0 length 0x3000 reloc 0x9400
Etherboot 5.0.2 (GPL) Tagged ELF for [3C90X]
Boot from (N)etwork or from (L)ocal? N
Found 3Com905C-TXM at 0xDC00, ROM address 0xE300
Probing...[3C90X]

3C90X Driver 2.00 Copyright 1999 LightSys Technology Services, Inc.
Portions Copyright 1999 Steve Smith
Provided with ABSOLUTELY NO WARRANTY.
---------------------------------------------------------------------------
-------
MAC Address - 00:01:02:C1:79:C7
Connectors present: 10Base-T / 100Base-TX.
Searching for server (DHCP)...
Me: 192.168.2.136, Server: 192.168.2.56, Gateway 192.168.2.1
Loading 192.168.2.56:/tftpboot/lts/vmlinuz-test.nbi (NBI)... done

Linux Net Boot Image Loader Version 0.8.1 (netboot)
Copyright (C) 1996,1997 G. Kuhlmann and M. Gutschke
Copyright (C) 1995-1998 G. Kuhlmann

Not enough memory
<abort>

Hmmmmmm, now what could be going on here.  We were doing so well.  PXE 
had started, loaded Etherboot.  Etherboot had taken over.  Etherboot had 
loaded the kernel.  And failed to execute.

Whoa.  It looks like we've got a tagged-image that was tagged with an old 
version of mknbi-linux.  It's a tagged-kernel I got from the LTSP site.  
Under normal circumstances Etherboot doesn't seem to care, but apparently 
after PXE has been in memory life is more complicated...

What would happen if I took a kernel and tagged it with mknbi-1.2?  This:

Searching for server (DHCP)...
Me: 192.168.2.136, Server: 192.168.2.56, Gateway 192.168.2.1
Loading 192.168.2.56:/tftpboot/lts/vmlinuz-test.nbi (NBI)... done
mknbi-1.2-2/first32.c (GPL)
129792k total memory
Uncompressing Linux... Ok, booting the kernel
Linux version 2.2.19 (jgoerzen@fritz) (gcc version 2.95.2 20000220 
(Debian GNU/Linux)) #1 Thu Apr 5 15:18:02 EST 2001
BIOS-provided physical RAM map:
 BIOS-e820: 00090000 @ 00000000 (usable)
 BIOS-e820: 07dc0000 @ 00100000 (usable)
Detected 564845 kHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1127.21 BogoMIPS
Memory: 126600k/129792k available (1124 kernel code, 472k reserved, 1524k 
data, 72k init)
........

Sweet.  The Intel EEPRO100+ card worked similarly, which means their PXE 
implementation of PXE seems compatible.  I hope some other people will 
try this and let us know how it works for them.  The DHCP server and the 
mknbi-1.2 requirement seem to be the only tricky parts.  Maybe someone 
will come up with a clever way to do this in v2 of the DHCP server.

So there's one way to use PXE to load Etherboot.  I hope this helps some 
people who want to try this.  Maybe we should put this message in the 
contrib directory for people who need some help getting started with 
this, or maybe we can work it into the documentation for Etherboot.

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] Etherboot 5.1.1 (development) released

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

I have released Etherboot 5.1.1 (development) at
http://etherboot.sourceforge.net/distribution.html

Changes from 5.0.2:

+ Added missing rules in genrules.pl for .pxe and .lzpxe images.

+ Peter Lister unified pxeloader.S into loader.S. pxeloader.S not
required now. Also fixed .lzpxe.

+ Added missing int i; declaration in try_floppy_first().

+ Load %edx with dev just before calling xstart in floppy.c:bootdisk()
so that %dl will have device number, just like entry from BIOS.

+ Merged in Eric Biederman's patches to build .ebi images that run under
LinuxBIOS. To make an image, edit Config to enable the EBI options (and
disable TAGGED_IMAGE), then make bin32/driver.ebi, where driver is the
name of a supported PCI NIC.

MD5 sums:

b545ee5ba7a3937c6d16538da95daf66  etherboot-5.1.1.tar.bz2
276664b1428a81864a8031e2505267e1  etherboot-5.1.1.tar.gz

SHA1 sums:

ef7184bf617ffe47ef5328119158224d43a42155  etherboot-5.1.1.tar.bz2
78c84236322635f54795e62af5fb19490a785db8  etherboot-5.1.1.tar.gz

[Etherboot-developers] Re: [Ltsp-discuss] rom-o-matic.net updated, 5.0.2-mc1, PXE loadable etherboot support

[<lin...@ic...>]

Careful with the Reply-All since this is cross posted...

I'm attempting to get etherboot w/ pPXE to work in my environment.  At
home I have 2 Fujitsu Scovery 211 terminals which have a eepro100 NIC
built in with PXE.  This configuration is working fine with BPBATCH,
LTSP and a RedHat 7.0 server with dhcpd v2.

Now, obviously I'd like to ditch BPBATCH...

Here are my questions:

  1) I downloaded a rom-o-matic built eb-5.02-mc1-eepro100.lzpxe
     and now I wonder if there are recommended config settings?

  2) I briefly scanned the mailing archives for dhcpd.conf recommendations
     but have been unsuccessful.  Any hints?

When my system boots, I'm currently getting:

  received 000b Kbyte; sorted 000b Kbyte; invoked primary bootstrap
  E6e: can't start from RAM disk image

Here's a snippet from my dhcpd.conf (am I even close)?

group {
  ##
  ## PXE Hosts using ETHERBOOT
  ## 
  use-host-decl-names                on;
  default-lease-time                 -1;
  next-server                        192.168.1.101;
  filename                           "/tftpboot/eb502eepro100.lzpxe";
  option dhcp-class-identifier       "PXEClient";
  #option vendor-encapsulated-options 01:04:00:00:00:00;
  #option root-path   "/tftpboot/lts/ltsroot";
  #option option-129  "nfsroot=192.168.1.101:/tftpboot/lts/ltsroot mem=64m";

  host scovery1 {
    hardware ethernet    08:00:06:25:A2:D4;
    fixed-address        192.168.1.105;
  }
 }

group {
  ##
  ## ETHERBOOT Hosts
  ##

  option dhcp-class-identifier    "Etherboot";
  use-host-decl-names             on;
  option log-servers              192.168.1.254;

  host scovery1 {
  hardware ethernet       08:00:06:25:A2:D4;
  fixed-address           192.168.1.105;
  filename                "/tftpboot/lts/vmlinuz.eepro100";
  }
}


> With major thanks to Peter Lister, Vasil Vasilev, and Ken Yap, I've 
> updated http://rom-o-matic.net with Etherboot 5.0.2-mc1.
> 
> This version allows one to use a PXE bootrom to load Etherboot, which in 
> turn can load a linux kernel or anything else that has been prepared with 
> mknbi-*.
> 
> In order for this to work, you have to prepare your DHCP server to check 
> the VCI (Vendor Class Indentifier) strings being sent by the client.  
> 
> What roughly happens is:
> 
>   - PXE ROM sends a DHCP request with VCI beginning with "PXEClient"
>   - DHCP server sends back a filename to load which is something like
>     "eepro100.lzpxe"  (this is actually an Etherboot image wrapped in
>     PXE clothing).
>   - PXE ROM loads the .lzpxe file and starts it.
>   - Etherboot starts, unloads PXE from RAM and takes over.
>   - Etherboot sends a DHCP request with VCI beginning with
>     "Etherboot".
>   - DHCP server sends back the filename of a tagged image to load.
>   - Etherboot loads the file and executes it.
> 
> There is obviously a little extra work here, but there are some good 
> reasons why you might want to do this.
> 
> There are some high-end cards (Intel EEPro100 and 3Com 3C905C-TXM cards 
> come to mind) and some motherboards (like the ThinkNIC) that have PXE 
> loaders onboard in Flash memory.  Although you can replace that code with 
> Etherboot in some cases, you might not wish to.  The above method allows 
> you to keep your PXE loader, but allows you to still use Etherboot to 
> load the kernel or other imagem and take advantage of all extensibility 
> and features of Etherboot.
> 
> Also, a lot of cards don't come with PXE and you might not want to pay 
> US$15/ROM to get a PXE ROM from Bootix or LANWorks, and then, they don't 
> support all cards, and it's closed source, and not sharable, etc.  The 
> above method lets you use an Etherboot setup for all clients, by 
> adjusting your DHCP server to differentiate clients based on VCIs.  
> 
> Etherboot is GPL, Free Software, Open Source Compliant, and supported by 
> a dedicated group of folks who want to see you succeed! ;-)
> 
> Seriously though, Major thanks to Peter Lister, Vasil Vasilev, and Ken 
> Yap for making this happen.
> 
> Someone (like me :-) needs to document this better.  The feature is very 
> new, and has been discussed on the Etherboot-Users list (archives 
> available at: 
> http://www.geocrawler.com/redir-sf.php3?list=etherboot-users)
> 
> Oh yes, the 5.0.2-mc1 version of Etherboot on http://rom-o-matic.net/ 
> should have the patches for this PXE stuff.  If you have problems, ask on 
> Etherboot-Users.  
> 
> "World Domination... and Fast!"
> 
> 
> ---
>     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/
> 
> 
> 
> _____________________________________________________________________
> Ltsp-discuss mailing list.   To un-subscribe, or change prefs, goto:
>       http://lists.sourceforge.net/lists/listinfo/ltsp-discuss
> For additional LTSP help,   try #ltsp channel on irc.openprojects.net
> 

[Etherboot-developers] Forcing rw in mknbi considered hamrful

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

I have added a flag to mknbi to specify whether the root will be mounted
ro or rw.

I need to be able to mount root ro, as this is what Red Hat 6.2 expects,
and I may very well need to specify this per-machine with Etherboot.

Look at branch prl-ro-rw of mknbi/mknbi-1.2/mknbi.pl

NB, I committed OK, but my ssh key doesn't work, and I got an error...

[prl@tomintoul mknbi-1.2]$ cvs commit mknbi.pl
pr...@cv...'s password: 
Checking in mknbi.pl;
/cvsroot/etherboot/mknbi/mknbi-1.2/mknbi.pl,v  <--  mknbi.pl
new revision: 1.3.2.1; previous revision: 1.3
done
chgrp: invalid group name `etherboot'

It also seems that my reverse lookup on my uid fails...

revision 1.3.2.1
date: 2001/07/04 15:02:13;  author: uid57129;  state: Exp;  lines: +16 
-2

Re: [Etherboot-developers] pxe patch bugfix release

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

> It wasn't any drama, it didn't break things for normal compilation and
> any breakage would have been sorted out eventually.

Well, *I* wouldn't trust me.

OK, I'm registered as prl.

In future though, this stuff should probably go out on an odd-numbered
release first.

[Etherboot-developers] rom-o-matic.net updated, 5.0.2-mc1, PXE loadable etherboot support

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

With major thanks to Peter Lister, Vasil Vasilev, and Ken Yap, I've 
updated http://rom-o-matic.net with Etherboot 5.0.2-mc1.

This version allows one to use a PXE bootrom to load Etherboot, which in 
turn can load a linux kernel or anything else that has been prepared with 
mknbi-*.

In order for this to work, you have to prepare your DHCP server to check 
the VCI (Vendor Class Indentifier) strings being sent by the client.  

What roughly happens is:

  - PXE ROM sends a DHCP request with VCI beginning with "PXEClient"
  - DHCP server sends back a filename to load which is something like
    "eepro100.lzpxe"  (this is actually an Etherboot image wrapped in
    PXE clothing).
  - PXE ROM loads the .lzpxe file and starts it.
  - Etherboot starts, unloads PXE from RAM and takes over.
  - Etherboot sends a DHCP request with VCI beginning with
    "Etherboot".
  - DHCP server sends back the filename of a tagged image to load.
  - Etherboot loads the file and executes it.

There is obviously a little extra work here, but there are some good 
reasons why you might want to do this.

There are some high-end cards (Intel EEPro100 and 3Com 3C905C-TXM cards 
come to mind) and some motherboards (like the ThinkNIC) that have PXE 
loaders onboard in Flash memory.  Although you can replace that code with 
Etherboot in some cases, you might not wish to.  The above method allows 
you to keep your PXE loader, but allows you to still use Etherboot to 
load the kernel or other imagem and take advantage of all extensibility 
and features of Etherboot.

Also, a lot of cards don't come with PXE and you might not want to pay 
US$15/ROM to get a PXE ROM from Bootix or LANWorks, and then, they don't 
support all cards, and it's closed source, and not sharable, etc.  The 
above method lets you use an Etherboot setup for all clients, by 
adjusting your DHCP server to differentiate clients based on VCIs.  

Etherboot is GPL, Free Software, Open Source Compliant, and supported by 
a dedicated group of folks who want to see you succeed! ;-)

Seriously though, Major thanks to Peter Lister, Vasil Vasilev, and Ken 
Yap for making this happen.

Someone (like me :-) needs to document this better.  The feature is very 
new, and has been discussed on the Etherboot-Users list (archives 
available at: 
http://www.geocrawler.com/redir-sf.php3?list=etherboot-users)

Oh yes, the 5.0.2-mc1 version of Etherboot on http://rom-o-matic.net/ 
should have the patches for this PXE stuff.  If you have problems, ask on 
Etherboot-Users.  

"World Domination... and Fast!"


---
    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] LinuxBIOS support.

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

ke...@us... writes:

> >I have just updated my patch so that etherboot can be loaded
> >directly from linuxBIOS, to be against 5.0.2.
> >
> >You can now do ``make bin32/driver.ebi'' to build the driver.
> >
> >This should have no effects on the normal etherboot compilation.
> >
> >When compiling for use under linuxBIOS some compilation options
> >fail to compile becase no native PC compatible BIOS is present, and
> >the support routines have all been removed.
> >
> >This patch is archived at:
> >ftp://download.linuxnetworx.com/pub/src/ethetboot/ethetboot-5.0.2.eb1.diff
> 
> Thanks Eric, I'll try that patch. Are you perhaps another candidate for
> developer privilege at Etherboot@Sourceforge?

Could be.  Though I try to think of myself as more of an extermely
interested user.  I already have an account at sourceforge.  
Username: ebiederm

Convincing me to check in stuff could be the tricky bit.  3/4 of the
time changes I make and probably could use a once over by someone else
before the commited.

Anway.  This is probably the last you will hear of me for about 2
weeks as I'm leaving on vacation shortly.

Eric

Re: [Etherboot-developers] LinuxBIOS support.

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

>I have just updated my patch so that etherboot can be loaded
>directly from linuxBIOS, to be against 5.0.2.
>
>You can now do ``make bin32/driver.ebi'' to build the driver.
>
>This should have no effects on the normal etherboot compilation.
>
>When compiling for use under linuxBIOS some compilation options
>fail to compile becase no native PC compatible BIOS is present, and
>the support routines have all been removed.
>
>This patch is archived at:
>ftp://download.linuxnetworx.com/pub/src/ethetboot/ethetboot-5.0.2.eb1.diff

Thanks Eric, I'll try that patch. Are you perhaps another candidate for
developer privilege at Etherboot@Sourceforge?

Re: [Etherboot-developers] pxe patch bugfix release

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

>> Sounds like perhaps you should register at Sourceforge so that I can
>> give you developer privileges for Etherboot.
>
>Sure you trust me, given the broken version I gave you first time round?

It wasn't any drama, it didn't break things for normal compilation and
any breakage would have been sorted out eventually.

I just brought the CVS archive up to date so developers can even check
in work in progress and increase the parallelism. Naturally things need
to be tested before release time.

Besides it's all part of my plan to give up Etherboot maintenance by
2026. :-)

[Etherboot-developers] LinuxBIOS support.

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

I have just updated my patch so that etherboot can be loaded
directly from linuxBIOS, to be against 5.0.2.

You can now do ``make bin32/driver.ebi'' to build the driver.

This should have no effects on the normal etherboot compilation.

When compiling for use under linuxBIOS some compilation options
fail to compile becase no native PC compatible BIOS is present, and
the support routines have all been removed.

This patch is archived at:
ftp://download.linuxnetworx.com/pub/src/ethetboot/ethetboot-5.0.2.eb1.diff

Eric


diff -uNr etherboot-5.0.2/src/Config etherboot-5.0.2.eb1/src/Config
--- etherboot-5.0.2/src/Config	Sat Jun 23 02:54:49 2001
+++ etherboot-5.0.2.eb1/src/Config	Sat Jun 30 17:35:07 2001
@@ -172,6 +172,11 @@
 #			Define this for PCI BIOSes that do not implement
 #			BIOS32 or not correctly. Normally not needed.
 #			Only works for BIOSes of a certain era.
+#	-DCONFIG_TSC_CURRTICKS
+#                       Uses the processor time stamp counter instead of reading
+#                       the BIOS time counter.  This allows etherboot to work
+#                       even without a BIOS.  This only works on late model
+#                       486s and above.
 #
 #	Obscure options you probably don't need to touch:
 #
@@ -226,6 +231,9 @@
 
 # Change download protocol to NFS, default is TFTP
 # CFLAGS32+=	-DDOWNLOAD_PROTO_NFS
+
+# Options to make a version of etherboot that will work under linuxBIOS.
+#CFLAGS32+= -DCONFIG_TSC_CURRTICKS  -DCONSOLE_SERIAL -DCOMCONSOLE=0x3f8 -DCONSPEED=115200 -DCONFIG_PCI_DIRECT -DELF_IMAGE -DIMAGE_MULTIBOOT
 
 # These flags affect the loader that is prepended to the Etherboot image
 LCONFIG+=	-DMOVEROM
diff -uNr etherboot-5.0.2/src/Makefile etherboot-5.0.2.eb1/src/Makefile
--- etherboot-5.0.2/src/Makefile	Thu Jun 21 09:44:39 2001
+++ etherboot-5.0.2.eb1/src/Makefile	Sat Jun 30 17:04:21 2001
@@ -87,10 +87,11 @@
 
 GCC=		gcc
 CPP=		gcc -E
+STRIP=		strip
 OBJCOPY=	objcopy
 VERSION_MAJOR=	5
 VERSION_MINOR=	0
-VERSION_PATCH=	2
+VERSION_PATCH=	2.eb1
 VERSION=	$(VERSION_MAJOR).$(VERSION_MINOR).$(VERSION_PATCH)
 CFLAGS32+=	-DVERSION_MAJOR=$(VERSION_MAJOR) \
 		-DVERSION_MINOR=$(VERSION_MINOR) \
@@ -158,6 +159,7 @@
 LILOPREFIX=	bin/liloprefix.bin
 
 START32=	bin32/start32.o
+UBE_START32 = bin32/ube_start32.o bin32/ube.o
 
 BOBJS32=	bin32/main.o bin32/osloader.o bin32/nfs.o bin32/misc.o
 BOBJS32+=	bin32/ansiesc.o bin32/bootmenu.o bin32/md5.o bin32/floppy.o
@@ -166,6 +168,7 @@
 LIBS32=		$(BLIB32) $(LIBC32)
 UTILS+=		bin/makerom bin/lzhuf
 STDDEPS32=	$(START32) $(BLIB32) $(UTILS)
+UBE_DEPS32=	$(UBE_START32) $(BLIB2)
 MAKEDEPS=	Makefile Config Roms
 
 CHECKSIZE=	{ read d1; read d1 d2 d3 size d4; [ $$size -gt $(ROMLIMIT) ] &&\
@@ -389,6 +392,7 @@
 	$(RM) bin32/*.dsk bin32/*.lzdsk
 	$(RM) bin32/*.lilo bin32/*.lzlilo
 	$(RM) bin32/*.pxe bin32/*.lzpxe
+	$(RM) bin32/*.elf bin32/*.ebi
 
 tarball:
 	(echo -n $(VERSION) ''; date -u +'%Y-%m-%d') > ../VERSION
diff -uNr etherboot-5.0.2/src/genrules.pl etherboot-5.0.2.eb1/src/genrules.pl
--- etherboot-5.0.2/src/genrules.pl	Mon Apr 23 07:51:53 2001
+++ etherboot-5.0.2.eb1/src/genrules.pl	Sat Jun 30 17:05:29 2001
@@ -141,6 +141,9 @@
 	cat \$(PRZLOADER) \$< > \$@
 	bin/makerom \$(MAKEROM_\$*) -p $ids -i\$(IDENT32) \$@
 
+bin32/$rom.ebi: bin32/$drv.elf
+	cp bin32/$drv.elf \$@
+	\$(STRIP) -R .comment -R .note \$@
 EOF
 }
 foreach $rom (sort keys %roms_isa) {
@@ -160,6 +163,10 @@
 	print <<EOF;
 bin32/$key.tmp:	bin32/$key.o bin32/config-$key.o bin32/pci.o \$(STDDEPS32)
 	\$(LD32) \$(LDFLAGS32) -o \$@ \$(START32) bin32/config-$key.o bin32/$key.o bin32/pci.o \$(LIBS32)
+	@\$(SIZE32) \$@ | \$(CHECKSIZE)
+
+bin32/$key.elf: bin32/$key.o bin32/config-$key.o bin32/pci.o \$(UBE_DEPS32)
+	\$(LD32) \$(LDFLAGS32) -o \$@ \$(UBE_START32) bin32/config-$key.o bin32/$key.o bin32/pci.o \$(LIBS32)
 	@\$(SIZE32) \$@ | \$(CHECKSIZE)
 
 bin32/$key.img:	bin32/$key.o bin32/$key.tmp bin32/config-$key.o bin32/pci.o \$(STDDEPS32)
diff -uNr etherboot-5.0.2/src/start32.S etherboot-5.0.2.eb1/src/start32.S
--- etherboot-5.0.2/src/start32.S	Thu Mar  8 04:51:42 2001
+++ etherboot-5.0.2.eb1/src/start32.S	Sat Jun 30 17:23:06 2001
@@ -112,6 +112,12 @@
 	lret
 
 	.code32
+#if defined(CONFIG_TSC_CURRTICKS)
+#undef CONFIG_BIOS_CURRTICKS
+#else
+#define CONFIG_BIOS_CURRTICKS 1
+#endif
+#if defined(CONFIG_BIOS_CURRTICKS)
 /**************************************************************************
 CURRTICKS - Get Time
 Use direct memory access to BIOS variables, longword 0040:006C (ticks
@@ -141,7 +147,7 @@
 	popl	%ebx
 	popl	%ebp
 	ret
-
+#endif /* CONFIG_BIOS_CURRTICKS */
 /**************************************************************************
 CONSOLE_PUTC - Print a character on console
 **************************************************************************/
diff -uNr etherboot-5.0.2/src/timer.c etherboot-5.0.2.eb1/src/timer.c
--- etherboot-5.0.2/src/timer.c	Sun Dec 10 00:40:48 2000
+++ etherboot-5.0.2.eb1/src/timer.c	Sat Jun 30 17:01:54 2001
@@ -18,3 +18,110 @@
 	outb(ticks & 0xFF, TIMER2_PORT);
 	outb(ticks >> 8, TIMER2_PORT);
 }
+
+#if defined(CONFIG_TSC_CURRTICKS)
+#define rdtsc(low,high) \
+     __asm__ __volatile__("rdtsc" : "=a" (low), "=d" (high))
+
+#define rdtscll(val) \
+     __asm__ __volatile__ ("rdtsc" : "=A" (val))
+
+
+#define HZ TICKS_PER_SEC
+#define CLOCK_TICK_RATE	1193180U /* Underlying HZ */
+/* LATCH is used in the interval timer and ftape setup. */
+#define LATCH  ((CLOCK_TICK_RATE + HZ/2) / HZ)	/* For divider */
+
+
+/* ------ Calibrate the TSC ------- 
+ * Return 2^32 * (1 / (TSC clocks per usec)) for do_fast_gettimeoffset().
+ * Too much 64-bit arithmetic here to do this cleanly in C, and for
+ * accuracy's sake we want to keep the overhead on the CTC speaker (channel 2)
+ * output busy loop as low as possible. We avoid reading the CTC registers
+ * directly because of the awkward 8-bit access mechanism of the 82C54
+ * device.
+ */
+
+#define CALIBRATE_LATCH	(5 * LATCH)
+
+static unsigned long long calibrate_tsc(void)
+{
+       /* Set the Gate high, disable speaker */
+	outb((inb(0x61) & ~0x02) | 0x01, 0x61);
+
+	/*
+	 * Now let's take care of CTC channel 2
+	 *
+	 * Set the Gate high, program CTC channel 2 for mode 0,
+	 * (interrupt on terminal count mode), binary count,
+	 * load 5 * LATCH count, (LSB and MSB) to begin countdown.
+	 */
+	outb(0xb0, 0x43);			/* binary, mode 0, LSB/MSB, Ch 2 */
+	outb(CALIBRATE_LATCH & 0xff, 0x42);	/* LSB of count */
+	outb(CALIBRATE_LATCH >> 8, 0x42);	/* MSB of count */
+
+	{
+		unsigned long startlow, starthigh;
+		unsigned long endlow, endhigh;
+		unsigned long count;
+
+		rdtsc(startlow,starthigh);
+		count = 0;
+		do {
+			count++;
+		} while ((inb(0x61) & 0x20) == 0);
+		rdtsc(endlow,endhigh);
+
+		/* Error: ECTCNEVERSET */
+		if (count <= 1)
+			goto bad_ctc;
+
+		/* 64-bit subtract - gcc just messes up with long longs */
+		__asm__("subl %2,%0\n\t"
+			"sbbl %3,%1"
+			:"=a" (endlow), "=d" (endhigh)
+			:"g" (startlow), "g" (starthigh),
+			 "0" (endlow), "1" (endhigh));
+
+		/* Error: ECPUTOOFAST */
+		if (endhigh)
+			goto bad_ctc;
+
+		endlow /= 5;
+		return endlow;
+	}
+
+	/*
+	 * The CTC wasn't reliable: we got a hit on the very first read,
+	 * or the CPU was so fast/slow that the quotient wouldn't fit in
+	 * 32 bits..
+	 */
+bad_ctc:
+	printf("bad_ctc\n");
+	return 0;
+}
+
+
+unsigned long currticks(void)
+{
+	static unsigned long clocks_per_tick;
+	unsigned long clocks_high, clocks_low;
+	unsigned long currticks;
+	if (!clocks_per_tick) {
+		clocks_per_tick = calibrate_tsc();
+		printf("clocks_per_tick = %d\n", clocks_per_tick);
+	}
+
+	/* Read the Time Stamp Counter */
+	rdtsc(clocks_low, clocks_high);
+
+	/* currticks = clocks / clocks_per_tick; */
+	__asm__("divl %1"
+		:"=a" (currticks)
+		:"r" (clocks_per_tick), "0" (clocks_low), "d" (clocks_high));
+
+
+	return currticks;
+}
+
+#endif /* RTC_CURRTICKS */
diff -uNr etherboot-5.0.2/src/ube.c etherboot-5.0.2.eb1/src/ube.c
--- etherboot-5.0.2/src/ube.c	Wed Dec 31 17:00:00 1969
+++ etherboot-5.0.2.eb1/src/ube.c	Sat Jun 30 17:01:54 2001
@@ -0,0 +1,159 @@
+#include "etherboot.h"
+#include "uniform_boot.h"
+
+static struct bootinfo {
+	unsigned base_mem_k;
+	unsigned high_mem_k;
+} bootinfo;
+
+
+
+static unsigned long uniform_boot_compute_header_checksum(
+	struct uniform_boot_header *header)
+{
+	unsigned short *ptr;
+	unsigned long sum;
+	unsigned long len;
+	/* compute an ip style checksum on the header */
+	sum = 0;
+	len = header->header_bytes >> 1;
+	ptr = (void *)header;
+	while (len--) {
+		sum += *(ptr++);
+		if (sum > 0xFFFF)
+			sum -= 0xFFFF;
+	}
+	return (~sum) & 0xFFFF;
+}
+
+static void set_base_mem_k(struct bootinfo *info, unsigned mem_k)
+{
+	if ((mem_k <= 640) && (info->base_mem_k <= mem_k)) {
+		info->base_mem_k = mem_k;
+	}
+}
+static void set_high_mem_k(struct bootinfo *info, unsigned mem_k)
+{
+	/* Shave off a megabyte before playing */
+	if (mem_k < 1024) {
+		return;
+	}
+	mem_k -= 1024;
+	if (info->high_mem_k <= mem_k) {
+		info->high_mem_k = mem_k;
+	}
+}
+static void read_uniform_boot_memory(
+	struct bootinfo *info, struct ube_memory *mem)
+{
+	int i;
+	int entries;
+	entries = (mem->size - sizeof(*mem))/sizeof(mem->map[0]);
+	for(i = 0; (i < entries); i++) {
+		switch(mem->map[i].type) {
+		case UBE_MEM_RAM:
+		{
+			unsigned long long high;
+			unsigned long mem_k;
+			high = mem->map[i].start + mem->map[i].size;
+#if defined(DEBUG_UBE)
+			printf("ube: ram start: %X%X size: %X%X high: %X%X\n",
+				(unsigned long)(mem->map[i].start >>32), 
+				(unsigned long)(mem->map[i].start & 0xFFFFFFFF), 
+				(unsigned long)(mem->map[i].size >> 32),
+				(unsigned long)(mem->map[i].size  & 0xFFFFFFFF),
+				(unsigned long)(high >> 32), 
+				(unsigned long)(high & 0xFFFFFFFF));
+#endif /* DEBUG_UBE */
+			high >>= 10;
+			mem_k = high;
+			if (high & 0xFFFFFFFF00000000ULL) {
+				mem_k = 0xFFFFFFFF;
+			}
+			set_base_mem_k(info, mem_k);
+			set_high_mem_k(info, mem_k);
+			break;
+		}
+		case UBE_MEM_ACPI:
+			break;
+		case UBE_MEM_NVS:
+			break;
+		case UBE_MEM_RESERVED:
+		default:
+			break;
+		}
+	}
+}
+
+
+static void read_uniform_boot_data(struct bootinfo *info,
+	struct uniform_boot_header *header)
+{
+	/* Uniform boot environment */
+	unsigned long env_bytes;
+	char *env;
+	unsigned long checksum;
+	checksum = uniform_boot_compute_header_checksum(header);
+	if (checksum != 0) {
+		printf("Bad uniform boot header checksum!\n");
+	}
+	if (header->arg_bytes) {
+		/* Ignore the command line I am passed */
+	}
+	env = (void *)(header->env);
+	env_bytes = header->env_bytes;
+	while(env_bytes) {
+		struct ube_record *record;
+		unsigned long mem_k;
+		record = (void *)env;
+		if (record->tag == UBE_TAG_MEMORY) {
+			read_uniform_boot_memory(info, (void *)record);
+		}
+		env += record->size;
+		env_bytes -= record->size;
+	}
+}
+
+static void initialize_bootinfo(void)
+{
+	extern unsigned long initeax;
+	extern unsigned long initebx;
+	static int initialized = 0;
+	unsigned long type;
+	void *ptr;
+	if (initialized) {
+		return;
+	}
+	initialized = 1;
+#if defined(DEBUG_UBE)
+	printf("\nReading bootinfo initeax = %X initebx = %X\n",
+		initeax, initebx);
+#endif /* DEBUG_UBE */
+	type = initeax;
+	ptr = (void *)initebx;
+	bootinfo.base_mem_k = 0;
+	bootinfo.high_mem_k = 0;
+	if (type == 0x0A11B007) {
+		read_uniform_boot_data(&bootinfo, ptr);
+	}
+	if (bootinfo.base_mem_k == 0) {
+		printf("No base memory found assuming 640K\n");
+		bootinfo.base_mem_k = 640;
+	}
+#if defined(DEBUG_UBE)
+	printf("base_mem_k = %d high_mem_k = %d\n", 
+		bootinfo.base_mem_k, bootinfo.high_mem_k);
+#endif /* DEBUG_UBE */
+}
+unsigned short basememsize(void)
+{
+	initialize_bootinfo();
+	return bootinfo.base_mem_k;
+}
+
+unsigned int memsize(void)
+{
+	initialize_bootinfo();
+	return bootinfo.high_mem_k;
+}
+
diff -uNr etherboot-5.0.2/src/ube_start32.S etherboot-5.0.2.eb1/src/ube_start32.S
--- etherboot-5.0.2/src/ube_start32.S	Wed Dec 31 17:00:00 1969
+++ etherboot-5.0.2.eb1/src/ube_start32.S	Sat Jun 30 17:01:54 2001
@@ -0,0 +1,165 @@
+/* #defines because ljmp wants a number, probably gas bug */
+/*	.equ	KERN_CODE_SEG,_pmcs-_gdt	*/
+#define	KERN_CODE_SEG	0x08
+	.equ	KERN_DATA_SEG,_pmds-_gdt
+/*	.equ	REAL_CODE_SEG,_rmcs-_gdt	*/
+#define	REAL_CODE_SEG	0x18
+	.equ	REAL_DATA_SEG,_rmds-_gdt
+	.equ	CR0_PE,1
+
+#ifdef	GAS291
+#define DATA32 data32;
+#define ADDR32 addr32;
+#define	LJMPI(x)	ljmp	x
+#else
+#define DATA32 data32
+#define ADDR32 addr32
+/* newer GAS295 require #define	LJMPI(x)	ljmp	*x */
+#define	LJMPI(x)	ljmp	x
+#endif
+
+/*
+ * NOTE: if you write a subroutine that is called from C code (gcc/egcs),
+ * then you only have to take care of %ebx, %esi, %edi and %ebp.  These
+ * registers must not be altered under any circumstance.  All other registers
+ * may be clobbered without any negative side effects.  If you don't follow
+ * this rule then you'll run into strange effects that only occur on some
+ * gcc versions (because the register allocator may use different registers).
+ *
+ * All the data32 prefixes for the ljmp instructions are necessary, because
+ * the assembler emits code with a relocation address of 0.  This means that
+ * all destinations are initially negative, which the assembler doesn't grok,
+ * because for some reason negative numbers don't fit into 16 bits. The addr32
+ * prefixes are there for the same reasons, because otherwise the memory
+ * references are only 16 bit wide.  Theoretically they are all superfluous.
+ * One last note about prefixes: the data32 prefixes on all call _real_to_prot
+ * instructions could be removed if the _real_to_prot function is changed to
+ * deal correctly with 16 bit return addresses.  I tried it, but failed.
+ */
+
+	
+
+/**************************************************************************
+START - Where all the fun begins....
+**************************************************************************/
+/* this must be the first thing in the file because we enter from the top */
+	.global	_start
+	.code32
+#ifdef IMAGE_MULTIBOOT
+/**************************************************************************
+XEND - Restart Etherboot from the beginning (from protected mode)
+**************************************************************************/
+	.globl xend
+xend:
+#endif
+_start:
+	cli
+
+	cs;lgdt	gdtarg	
+	ljmp	$KERN_CODE_SEG, $1f
+1:
+	/* reload other segment registers */
+	movl	$KERN_DATA_SEG, %ebp
+	movl	%ebp,%ds
+	movl	%ebp,%es
+	movl	%ebp,%ss
+	movl	%ebp,%fs
+	movl	%ebp,%gs
+
+	movl	%esp, initesp
+	movl	%eax, initeax
+	movl	%ebx, initebx
+
+	movl	$_estack, %esp
+
+	call	main
+	/* fall through */
+
+	.globl	exit
+exit:
+	movl	initesp, %esp
+	ret
+
+
+/**************************************************************************
+SETJMP - Save stack context for non-local goto
+**************************************************************************/
+	.globl	setjmp
+setjmp:
+	movl	4(%esp),%ecx
+	movl	0(%esp),%edx
+	movl	%edx,0(%ecx)
+	movl	%ebx,4(%ecx)
+	movl	%esp,8(%ecx)
+	movl	%ebp,12(%ecx)
+	movl	%esi,16(%ecx)
+	movl	%edi,20(%ecx)
+	movl	%eax,24(%ecx)
+	movl	$0,%eax
+	ret
+
+/**************************************************************************
+LONGJMP - Non-local jump to a saved stack context
+**************************************************************************/
+	.globl	longjmp
+longjmp:
+	movl	4(%esp),%edx
+	movl	8(%esp),%eax
+	movl	0(%edx),%ecx
+	movl	4(%edx),%ebx
+	movl	8(%edx),%esp
+	movl	12(%edx),%ebp
+	movl	16(%edx),%esi
+	movl	20(%edx),%edi
+	cmpl	$0,%eax
+	jne	1f
+	movl	$1,%eax
+1:	movl	%ecx,0(%esp)
+	ret
+
+/**************************************************************************
+GLOBAL DESCRIPTOR TABLE
+**************************************************************************/
+	.align	4
+_gdt:
+gdtarg:
+	.word	0x27			/* limit */
+	.long	_gdt			/* addr */
+	.word	0
+
+_pmcs:
+	/* 32 bit protected mode code segment */
+	.word	0xffff,0
+	.byte	0,0x9f,0xcf,0
+
+_pmds:
+	/* 32 bit protected mode data segment */
+	.word	0xffff,0
+	.byte	0,0x93,0xcf,0
+
+_rmcs:
+	/* 16 bit real mode code segment */
+	.word	0xffff,(RELOC&0xffff)
+	.byte	(RELOC>>16),0x9b,0x00,(RELOC>>24)
+
+_rmds:
+	/* 16 bit real mode data segment */
+	.word	0xffff,(RELOC&0xffff)
+	.byte	(RELOC>>16),0x93,0x00,(RELOC>>24)
+
+initesp: .long 0
+	.globl initeax
+initeax: .long 0
+	.globl initebx
+initebx: .long 0
+
+
+	.align	4
+
+	.section ".bss"
+	.p2align 3
+	/* allocate a 4K stack in the bss segment */
+_stack:
+	.space 4096
+_estack:
+	
diff -uNr etherboot-5.0.2/src/uniform_boot.h etherboot-5.0.2.eb1/src/uniform_boot.h
--- etherboot-5.0.2/src/uniform_boot.h	Wed Dec 31 17:00:00 1969
+++ etherboot-5.0.2.eb1/src/uniform_boot.h	Sat Jun 30 17:01:54 2001
@@ -0,0 +1,67 @@
+#ifndef __UNIFORM_BOOT_H
+#define __UNIFORM_BOOT_H
+
+/* The uniform boot environment information is restricted to 
+ * hardware information.  In particular for a simple enough machine
+ * all of the environment information should be able to reside in
+ * a rom and not need to be moved.  This information is the
+ * information a trivial boot room can pass to linux to let it
+ * run the hardware.  
+ *
+ * Also all of the information should be Position Independent Data.  
+ * That is it should be safe to relocated any of the information
+ * without it's meaning/correctnes changing. The exception is the
+ * uniform_boot_header with it's two pointers arg & env.
+ * 
+ * The addresses in the arg & env pointers must be physical
+ * addresses. A physical address is an address you put in the page
+ * table. 
+ *
+ * The Command line is for user policy.  Things like the default
+ * root device.
+ * 
+ */
+
+struct uniform_boot_header
+{
+	unsigned long header_bytes;
+	unsigned long header_checksum;
+	unsigned long arg;
+	unsigned long arg_bytes;
+	unsigned long env;
+	unsigned long env_bytes;
+};
+
+/* Every entry in the boot enviroment list will correspond to a boot
+ * info record.  Encoding both type and size.  The type is obviously
+ * so you can tell what it is.  The size allows you to skip that
+ * boot enviroment record if you don't know what it easy.  This allows
+ * forward compatibility with records not yet defined.
+ */
+struct ube_record {
+	unsigned long tag;		/* tag ID */
+	unsigned long size;		/* size of record (in bytes) */
+	unsigned long data[0];		/* data */
+};
+
+
+#define UBE_TAG_MEMORY	0x0001
+
+struct ube_memory_range {
+	unsigned long long start;
+	unsigned long long size;
+	unsigned long type;
+#define UBE_MEM_RAM      1
+#define UBE_MEM_RESERVED 2
+#define UBE_MEM_ACPI     3
+#define UBE_MEM_NVS      4
+	
+};
+
+struct ube_memory {
+	unsigned long tag;
+	unsigned long size;
+	struct ube_memory_range map[0];
+};
+
+#endif /* _UNIFORM_BOOT_H */

Re: [Etherboot-developers] pxe patch bugfix release

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

> I can upload the patch to the patch area. But I thought the .pxe stuff
> worked even if the .lzpxe didn't, Ah you need the ROM_SEGMENT patch of
> course.

And the rounding up in makerom; between them the make stuff fall over
much less. I really should have tested more before announcing it.

> Marty has incorporated that patch at rom-o-matic.net.

Great - now I don't have to build images for people. :)

BTW, I have struck up a conversation with a guy who asked on the
syslinux list about using 2000 (uh huh, 2K) linux clients with pxe nics,
at a UK insurance company (he hasn't let on which one). I'm trying to
wean him off pxelinux and on to Etherboot. If he succeeds, this would be
a great reference for Linux, Etherboot, and also useful to us. Although
the details of netbooting is incidental to our product, it's one of
those things which we have to have to do convincingly, which is why I'm
doing this on company time.

> Sounds like perhaps you should register at Sourceforge so that I can
> give you developer privileges for Etherboot.

Sure you trust me, given the broken version I gave you first time round?

-- =

Peter Lister, Sychron Inc.  -  1-866-SYCHRON
Intelligent Infrastructure  -  www.sychron.com

Re: [Etherboot-developers] pxe patch bugfix release

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

>I can upload the patch to the patch area. But I thought the .pxe stuff
>worked even if the .lzpxe didn't, Ah you need the ROM_SEGMENT patch of
>course.

Patch uploaded to patch area.

Re: [Etherboot-developers] pxe patch bugfix release

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

>Hi - I'd like to be able to tell a couple of people about the pxe stuff,
>but *with* bugfixes (otherwise it will be highly unreliable), but I see
>no 5.0.3 or 5.0.2a on sourceforge or on rom-o-matic.
>
>Will this happen soon?

I can upload the patch to the patch area. But I thought the .pxe stuff
worked even if the .lzpxe didn't, Ah you need the ROM_SEGMENT patch of
course.

Marty has incorporated that patch at rom-o-matic.net.

>Was it just coincidence that the first version made it into 5.0.2 so
>fast?

In a way yes, your patch came along shortly before I was going to do a
release. I don´t want strange version numbers like 5.0.2a so it will be
5.0.3 next and I haven't got enough new stuff to warrant 5.0.3.

Sounds like perhaps you should register at Sourceforge so that I can
give you developer privileges for Etherboot.

Re: [Etherboot-developers] ANSI/GFX vs SERIAL/DUAL consoles

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

>Users should be able to choose dual console "safely", - no ANSI gunk in
>the wrong place - without needing to tweak the compilation image or
>server configuration for one or other. So, as Etherboot interprets the
>GFX/ANSI gunk, the Right Thing is to *always* interpret the ANSI,
>generate output only for the video, and ignore it for the serial line,
>or at least use minimal formatting. Clearing the video screen might
>produce no more than a newline or page break in the serial output so

Yes, I'd say that's an excellent goal.

>that the following text is neat. While I'm about it, I also want to
>suppress the "rotating line" progress indicator. Yes, it's cute, it's
>traditional, but a row of dots does the job, and doesn't clog up log

And a row of dots is probably more useful in giving an idea of progress.

>files with non-printable gunk. For completeness, it would be great to
>get mknbi and loader.S messages down the serial as well.

A good goal, but not so important as there are very few messages from
this stage.

Go for it.

[Etherboot-developers] pxe patch bugfix release

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

Hi - I'd like to be able to tell a couple of people about the pxe stuff,
but *with* bugfixes (otherwise it will be highly unreliable), but I see
no 5.0.3 or 5.0.2a on sourceforge or on rom-o-matic.

Will this happen soon?

Was it just coincidence that the first version made it into 5.0.2 so
fast?

[Etherboot-developers] ANSI/GFX vs SERIAL/DUAL consoles

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

I'd like to sort out the problems of GFX versus serial console (I use
"console" in the OS sense as "the place where kernel messages go", not
the commonly used PC centric sense of "video+keyboard").

We are interested in booting clusters such with the console connected to
machine readable hardware (i.e. rs232, but potentially parallel or USB)
with a console manager and/or logger on the other end; for clusters this
is the Right Thing. [*] But it's nice to have the company logo on the
video screen if there is one.

Users should be able to choose dual console "safely", - no ANSI gunk in
the wrong place - without needing to tweak the compilation image or
server configuration for one or other. So, as Etherboot interprets the
GFX/ANSI gunk, the Right Thing is to *always* interpret the ANSI,
generate output only for the video, and ignore it for the serial line,
or at least use minimal formatting. Clearing the video screen might
produce no more than a newline or page break in the serial output so
that the following text is neat. While I'm about it, I also want to
suppress the "rotating line" progress indicator. Yes, it's cute, it's
traditional, but a row of dots does the job, and doesn't clog up log
files with non-printable gunk. For completeness, it would be great to
get mknbi and loader.S messages down the serial as well.

Comments?

-- 
Peter Lister, Sychron Inc.  -  1-866-SYCHRON
Intelligent Infrastructure  -  www.sychron.com

[*] Actually, that's the short term Right Thing. The longer term Right
Thing is more interesting (and really why I'm suddenly motivated to use
Etherboot), but I'll bore you all about this at a later date.

Re: [Etherboot-developers] Boot Eprom

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

27512 is a 64kB EPROM. It should work fine with a 16kB image. It
is backwards compatible with the 27256 (which is 32kB) and 27128
(which is 16kB), but if you configured your NIC for 16kB mode, it is
not clear whether it will select the first, second, third or fourth
16kB segment (or maybe randomly pick one each time you access the
ROM); thus, you might want to burn the same image into all four
segments and then configure the NIC for 16kB. Alternatively, if you
configured the NIC for 64kB mode, then you only need to burn the
image into the first part of the EPROM and you leave everthing
else blank.

Many cards require that you enable the ROM using some card-specific
utility. I am not sure, if this is the case for the two NICs that
you use.

Where did you download the images from? http://www.rom-o-matic/ ?

There used to be a bug in very old PCI BIOSs that would refuse to
recognize etherboot images. I am not sure if that is still the case
(I think, at one time, there was discussion of putting a workaround
into etherboot). Check the mailing list archive for more information.
If you have one of these old and buggy BIOS version, then the archive
might have instructions on how to modify etherboot to make things work.


Markus

BM wrote:


> Have anybody know how programme eprom's?
> 
> I have an Eprom Programmer & downloaded boot image file for my ethernet 
> cards.(3C905B-TX-NM & RTL8139).
> 
> I write image file (16Kb) to Eprom 27C128 for 8139.
> 
> But 8139 could'nt boot pc client.Also I write 29C512 for 3C905 but it 
> doesn't boot too.Is there any tricks for writing Eprom's?.
> 
> I write the image file from adres 0000.Is it true? or is there another 
> thing so I don't know?
> 
> Please help me if any one know this...

-- 
Markus Gutschke                                Resonate, Inc.
3637 Fillmore Street #106                      385 Moffett Park Drive
San Francisco, CA 94123-1600                   Sunnyvale, CA 94089
+1-415-567-8449                                +1-408-548-5528
ma...@gu...                            mgu...@re...