etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] i82559er

[Ken Y. <ke...@nl...>]

>I have used Etherboot since 4.6.2 and in most cases it worked fine. 
>Yesterday I have downloaded 4.6.12 and I have recognized that you 
>added the i82559er controller. I made changes to earlier releases 
>(4.6.9-4.6.10) to get this controller work. In 4.6.12 the controller 
>stuff works well, but there are no outgoing packets. To me there is 
>a problem with changes to mknbi.....

I have a feeling that the 82559er and other new models didn't really
work until 4.7.13 or so when the changes for EEPROs with 256 byte config
EEPROMs were finally correctly introduced.  Could you please have a look
at the latest 4.7.17 and see if the changes are the same as what you
have done?  If not please send me some changes that work for you. I have
no way of testing them myself.

What sort of problem are you having with mknbi?

RE: [Etherboot-developers] testing from pcmcia flash card in plac e of floppy

[Eno C. <Eno...@Mi...>]

Hmmm... sorry to be so stupid. I had expected the boot sector to be
universal across all bootable devices. 

Thanks for your reply.



 -----Original Message-----
From: 	Ken Yap [mailto:ke...@nl...] 
Sent:	Tuesday, January 16, 2001 3:51 PM
To:	eth...@li...
Subject:	Re: [Etherboot-developers] testing from pcmcia flash card in
place of floppy 

|The flash has a problem. The first sector from the flash gets read in and
|executed ok. But the code that comes from the flash attempts to read the
|rest of the loader from floppy. Looking at the source, it seems clear, the
|boot sector code just assumes it comes from diskette on drive a and that it
|should get the rest of the code from the same place.

Sure. That's why the boot sector code is called floppyload.bin.

|Can anyone suggest how I can get past this problem? 

You could try to make a LILO compatible image .lilo and boot it from
syslinux or LILO. There are targets in the Makefile for making .lilo
images.

_______________________________________________
Etherboot-developers mailing list
Eth...@li...
http://lists.sourceforge.net/lists/listinfo/etherboot-developers

[Etherboot-developers] i82559er

[Helmut A. <Hel...@ju...>]

Hi there...

I have used Etherboot since 4.6.2 and in most cases it worked fine. 
Yesterday I have downloaded 4.6.12 and I have recognized that you 
added the i82559er controller. I made changes to earlier releases 
(4.6.9-4.6.10) to get this controller work. In 4.6.12 the controller 
stuff works well, but there are no outgoing packets. To me there is 
a problem with changes to mknbi.....

Please respond for more detailed information....
Thanks
Helmut

[Etherboot-developers] Re: FIXED: Intel CA810E mobo doesn't see Etherboot Option ROM

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

Summary:

There is a problem with the PCI and PNP headers in Etherboot ROMs which 
causes them not to be recognized by certain modern PNP and "Legacy Free" 
BIOSes.  In my case the motherboard was a current offering by Intel, 
model CA810EA.  It is likely that this issue may affect other 
motherboards as well, depending on their BIOS revision.  This motherboard 
has 4 PCI slots, onboard video and sound, and is a Micro-ATX form factor.

The behavior observed was that the ROM would be recognized by the Setup 
screen of the BIOS as a potential BOOT device, but the ROM code would not 
execute when selected as a boot device.

I have created a patch for the "loader.S" file in Etherboot which fixes 
this problem.  I have tested this patch by burning ROMs and Etherbooting 
with an MX98715-based board on 4 different motherboards, some with legacy 
slots, some without, and with various BIOSes.  The patch is available at:

  http://www.thinguin.org/

With the patch installed, it is possible to use the BIOS setup screen to 
select, prioritize, or disable numerous boot (IPL) devices, and have them 
checked in any order.  In my case, I first check for a floppy, then for 
"Etherboot ROM".  It is also possible to install two Ethernet cards and 
select which one to Etherboot from, if they are both capable.

Please note that the bug also exists in Netboot version 0.9.0e, and 
should probably be fixed there as well.

Regards,

Marty

P.S. For those who would like to know how I figured this out, below is a 
description of the debugging process.  I mainly do this for the curious 
and with the hope that others who have to debug such things can benefit 
from time I spent gathering information and analyzing the problem.

The Tale:

Like so many interesting adventures, it started off innocently enough...

In preparation for LinuxWorld Expo in New York, I purchased an Intel 
CA810EA, which is a modern Micro-ATX form factor motherboard.  I liked it 
because it had integrated AGP video, sound, and used PC100 RAM.  It would 
display well because the only PCI device would be an Ethernet card.  it 
also will fit in my suitcase along with a flat screen, so transportation 
would be easier.

I built a machine with the CA810EA motherboard, using a Celeron 566Mhz 
CPU with a large heat-sink so no CPU fan is needed.  The power supply for 
the case is virtually silent, because as we all know "Thin clients should 
be seen and not heard".

I Etherbooted various PCI cards via floppy, and all looked very good.  I 
was just about to attach plexiglass sides to the case so people at the 
show could see there was nothing inside except a NIC card with an 
Etherboot ROM on it.

I then burned a ROM for an MX98715-based tulip clone card, and tried to 
Etherboot with it.  It didn't work.  It was recognized by the BIOS setup 
screen, but failed to execute.  I tried various BIOS settings, but to no 
avail.

To determine if this was a problem with the boot ROM, I tested the 
motherboard with an Intel PRO/100+ card and a 3Com 3C905C-TX-M card, both 
of which have integrated flash memory containing PXE network booting 
code. Both commercial cards were recognized by the BIOS, and attempted to 
network boot.  

Because the MX98715 board's ROM was at least selectable by the BIOS, I 
suspected that it was at seeing a ROM on the card, but for some reason 
didn't think it was correct for network booting.

Time to take a look inside

Using the contrib/3c90xutil/cromutil utility program from the Etherboot 
package I dumped the Flash memory contents of the working 3Com 
3C905C-TX-M board to a file.  Using the techniques described in the 
Etherboot contrib/3c90xutil/eepro100notes file, I dumped the flash memory 
contents of the pro/100+ adapter as well.  I already had the 
mx98715.lzrom code for Etherboot, of course.

Here is a hex dump of the first part of each of those ROM images:

-:---F1  mx987x5.lzrom      (Hexl)--L3--Top---------------------------
00000000: 55aa 20eb 4f31 e98c 0045 7468 6572 626f  U. .O1...Etherbo
00000010: 6f74 0000 0000 0000 1c00 3400 5043 4952  ot........4.PCIR
00000020: d910 3105 0000 1800 0000 0002 2000 0100  ..1......... ...
00000030: 0080 0000 2450 6e50 0102 0000 0061 0000  ....$PnP.....a..
00000040: 0000 0000 0000 0000 0214 0000 0000 5400  ..............T.
00000050: 0000 0000 501e 31c0 8ed8 a104 033d 4ce4  ....P.1......=L.

-:---F1  3c905c.img         (Hexl)--L7--Top-----------------------------
00000000: 55aa 08e9 af07 554c 4452 0000 0003 0000  U.....ULDR......
00000010: 0000 d006 4005 7000 5800 3800 6d00 0004  ....@.p.X.8.m...
00000020: cc00 0010 0427 10d4 3005 0000 0000 0000  .....'..0.......
00000030: 0000 0000 0000 0000 2450 6e50 0102 0000  ........$PnP....
00000040: 00e2 0000 0000 c300 c800 0200 0014 0000  ................
00000050: 0000 4503 0000 0000 5043 4952 b710 0092  ..E.....PCIR....
00000060: 0000 1800 0002 0000 6d00 0000 0080 0000  ........m.......

-:---F1  pro100+.img       (Hexl)--L7--Top-----------------------------
00000000: 55aa 14e8 3f23 cbc4 d502 0000 0000 0000  U...?#..........
00000010: 0000 0000 0000 2000 4000 6000 5503 2001  ...... .@.`.U. .
00000020: 554e 4449 1605 0000 0102 130e 0008 604b  UNDI..........`K
00000030: 9020 5043 4952 2e8b c02e 8bc0 2e8b c090  . PCIR..........
00000040: 5043 4952 8680 2912 0000 1800 0002 0000  PCIR..).........
00000050: 1400 0102 0080 0000 2e8b c02e 8bc0 8bc0  ................
00000060: 2450 6e50 0102 0000 0020 0000 0000 9b00  $PnP..... ......
00000070: bc00 0200 00e4 0000 0000 610d 0000 0000  ..........a.....

Decoding the ROMs

Using the specifications for Option ROM Headers described in the document:

   http://www.phoenix.com/products/specs-bbs101.pdf

I decoded three headers from each ROM, and created a table to compare the 
Etherboot ROM to the 3Com and Intel ROMs.  I then studied the 
specifications to see whether the ROM contents made sense for each field.

Here is a table showing the decoded headers:

A.2  PnP Option ROM Header                                                
  
             Etherboot  3Com       Intel      
Offset Size  before fix 3C905C     PRO/100+  Description
00h    B     55h        55h        55h       Signature byte 1.
01h    B     AAh        AAh        AAh       Signature byte 2.
02h    B     20h        08h        14h       Option ROM len 512byte blks.
03h    B*4   eb4f31e9h  e9af0755h  e83f23cbh Initialization entry point.
07h    B*17                                  Reserved.
18h    W     1c00h      5800h      4000h     Offset to PCI data struct.
1Ah    W     3400h      3800h      6000h     Offset to expansion hdr.
                                                       
A.3  PnP Expansion Header                                                 
   
             Etherboot  3Com       Intel      
Offset Size  before fix 3C905C     PRO/100+  Description
00h    B     '$'        '$'        '$'       Signature byte 1.
01h    B     'P'        'P'        'P'       Signature byte 2.
02h    B     'n'        'n'        'n'       Signature byte 3.
03h    B     'P'        'P'        'P'       Signature byte 4.
04h    B     01h        01h        01h       Structure revision.
05h    B     02h        02h        02h       Length (16 byte increments).
06h    W     0000h      0000h      0000h     Offset of next hdr
08h    B     00h        00h        00h       Reserved.
09h    B     61h        e2h        20h       Checksum.
0Ah    DW    00000000h  00000000h  00000000h Device identifier.
0Eh    W     0000h      c300h      9b00h     Ptr to mfgr str. (opt)
10h    W     0000h      c800h      bc00h     Ptr to prod name str (Opt)
12h    B*3   000002h    020000h    020000h   Device type code.
15h    B     14h        14h        e4h       Device indicators.
16h    W     0000h      0000h      0000h     Boot Connection Vector (BCV)
18h    W     0000h      0000h      0000h     Disconnect Vector (DV)
1Ah    W     5400h      4503h      610dh     Bootstrap Entry Vector (BEV)
1Ch    W     0000h      0000h      0000h     Reserved.
1Eh    W     0000h      0000h      0000h     Static res info vector   
                                                    
A.4  PCI Data Structure                                                   
   
             Etherboot  3Com       Intel      
Offset Size  before fix 3C905C     PRO/100+  Description
00h    B     'P'        'P'        'P'       Signature byte 1.
01h    B     'C'        'C'        'C'       Signature byte 2.
02h    B     'I'        'I'        'I'       Signature byte 3.
03h    B     'R'        'R'        'R'       Signature byte 4.
04h    W     d910h      b710h      8680h     Vendor Identification.
06h    W     3105h      0092h      2912h     Device Identification.
08h    W     0000h      0000h      0000h     Ptr to Vital Product Data.
0Ah    W     1800h      1800h      1800h     PCI Data Structure Length.
0Ch    B     00h        00h        00h       PCI Data Structure Revision.
0Dh    B*3   000002h    020000h    020000h   Class Code.
10h    W     2000h      6d00h      1400h     Image Length.
12h    W     0100h      0000h      0102h     Revision Level of Code/Data.
14h    B     00h        00h        00h       Code Type.
15h    B     80h        80h        80h       Indicator.
16h    W     0000h      0000h      0000h     Reserved.

Eureka!

Note specifically the values at offet 12h of the PnP Expansion Header and 
offset 0Dh of the PCI Data Structure.  It appears that they are in 
reverse order in the Etherboot ROM.  Referring the the Device ID 
specification available at:

   http://www.microsoft.com/hwdev/download/respec/devids.txt

we note that the 3 bytes of the Device code should be:

   Base Type = 2: Network Interface Controller
     Sub-Type = 0: Ethernet
       Interface Type = 0: General Ethernet

which they are, in the Intel and 3Com ROM images.  It seems they are 
simply reversed in the Etherboot ROM.

referring to the relevant portion of src/loader.S in Etherboot, we see:

PCI:
        STRDECL('PCIR')                 ; signature
        dw      0x8086                  ; vendor ID, filled in by makerom
        dw      0x1229                  ; device ID, filled in by makerom
        dw      0x0000                  ; pointer to vital product data
        dw      0x0018                  ; PCI data structure length
        db      0                       ; PCI data structure revision
        db      0                       ; Class code byte 1
        db      0                       ; Class code byte 2
        db      0x02                    ; Class code byte 3 (from 
hexdumping
                                        ; Intel bootrom image)
        dw      0x0000                  ; Image length same as offset 02h
        dw      0x0001                  ; revision level of code /data
        db      0                       ; code type
        db      0x80                    ; indicator (from hexdumping
                                        ; Intel bootrom image)
        dw      0x0000                  ; reserved

and

PnP:
        STRDECL('$PnP')                 ; signature
        db      0x01                    ; structure revision
        db      0x02                    ; length (in 16 byte increments)
        dw      0x0000                  ; offset of next header
        db      0                       ; Reserved
        db      0                       ; checksum filled by makerom
        dd      0x00000000              ; Device identifier
        dw      0x0000                  ; pointer to manufacturer str
        dw      0x0000                  ; pointer to product name
        db      0                       ; device type code byte 1
        db      0                       ; device type code byte 2
        db      2                       ; device type code byte 3 (from
                                        ; hexdumping Intel bootrom image)
        db      0x14                    ; device indictors (from
                                        ; hexdumping Intel bootrom image)
        dw      0x0000                  ; boot connection vector
        dw      0x0000                  ; disconnect vector
        dw      start19h                ; bootstrap entry vector
        dw      0x0000                  ; reserved
        dw      0x0000                  ; static resource information 
vector

note the order of the "class code" and "device type code" bytes.  It is 
reversed from the order specified in the PnP specification.

From the file netboot-0.9.0e/bootrom/loader/rom.S file we see:

! Define the PCI data structure to make the netboot bootrom compatible
! with the PCI local bus specification 2.1. This header is actually only
! needed when the bootrom is physically located on the PCI network card.
! Note that the order of the class codes has to be reversed compared to
! what the spec says.

pcihdr: .ascii  "PCIR"                  ! signature for PCI data structure
        .word   0                       ! vendor ID (filled in later)
        .word   0                       ! device ID (filled in later)
        .word   0                       ! ptr to vital product data 
(unused)
        .word   $0018                   ! length of PCI data structure
        .byte   $00                     ! structure revision 0.0
        .byte   PCI_IFTYPE              ! device programming interface
        .byte   PCI_SUBTYPE             ! device subtype code
        .byte   PCI_BASETYPE            ! base device type code
        .word   0                       ! rom image length (filled in 
later)
        .word   PCI_REVISION            ! version number of code/data
        .byte   0                       ! code type
        .byte   PCI_DEVIND              ! device indicator
        .word   0                       ! reserved

! Define the expansion header to make the netboot bootrom Plug and Play
! compatible according to the Plug and Play BIOS Specification 1.0A. This
! will allow the system BIOS to select wether to boot from the network or
! not, and we dont have to redirect interrupt 18h or 19h by ourselves.
! Note that the order of the class codes has to be reversed compared to
! what the spec says.

pnphdr: .ascii  "$PnP"                  ! signature for PnP expansion 
header
        .byte   $01                     ! structure revision 0.1
        .byte   2                       ! length of header in 
16-byte-blocks
        .word   0                       ! pointer to next header (0 = 
none)
        .byte   0                       ! reserved
        .byte   0                       ! checksum (filled in later)
        .word   PNP_VENDID              ! compressed manufacturer code
        .word   PNP_DEVID               ! product number and revision, 
device ID
        .word   0                       ! ptr to manufacturer string 
(unused)
        .word   prdnam                  ! ptr to product name
        .byte   PNP_IFTYPE              ! device programming interface
        .byte   PNP_SUBTYPE             ! device subtype code
        .byte   PNP_BASETYPE            ! base device type code
        .byte   PNP_DEVIND              ! device indicators
        .word   0                       ! boot connection vector (unused)
        .word   0                       ! disconnect vector (unused)
        .word   dorom                   ! bootstrap entry vector
        .word   0                       ! reserved
        .word   0                       ! static resource info vector 
(unused)

Note that the author specifically reversed the order of the PCI and PNP 
class codes.  I suspect there must have been a BIOS implementation bug 
that caused cards following the specification not to work at the time, 
because the 1.0A specification states:

   "Device Type Code - This field contains general device type 
   information that will assist the System BIOS in prioritizing the boot
   devices. The Device Type code is broken down into three byte fields.
   The byte fields consist of a Base-Type code that indicates the general
   device type.  The second byte is the device Sub-Type and its definition
   is dependent upon the Base-Type code.  The third byte defines the 
   specific device programming interface, IF.-Type, based on the Base-Type
   and Sub-Type."

We have liftoff

WIth this information and analysis I reversed the codes in the Etherboot 
ROM code, burned a ROM, and it was properly recognized by the BIOS.  

I also added preliminary manufacturer and product strings to the header 
to allow the string "Etherboot ROM" to appear in the BIOS setup menu for 
boot device.  Without this, it says "Option ROM" which is less 
descriptive.  With a little more work, we could embed the actual ROM type 
as well at compile time so it would say "Etherboot 4.6.12 MX987x5.lzrom" 
or something more descriptive.  According to the spec, the first 32 bytes 
are significant, though no length limit for the string is specified.

I burned a second ROM (an LC82C115.lzrom) to test a second card type, and 
it also functioned.

The third ROM was an RTL8139.lzrom.  This one was not recognized 
initially by the BIOS.  I booted to DOS and ran a utility to enable the 
ROM socket and specify the size of the ROM.  Still no joy.

I noted that in this 3rd case, the ROM was not even being seen by the 
BIOS setup screen.  This suggested that there might be something 
physically wrong with the ROM.  Though it was the same speed as the other 
ROMs it appears that the RTL8139 card was not inserting enough wait 
states to mediate between the bus speed (66MHZ) and the ROM speed.  I 
burned a faster ROM (150ns vs. 250ns) and the ROM was recognized and 
booted properly.

I then took the three cards and Etherbooted them on four different CPUs 
with various BIOS and legacy configurations.  They seemed to function 
properly.

Cut to the present

So, that's where we are now.  I can now continue to prepare for 
LinuxWorld Expo, and show a modern motherboard with various modern PCI 
cards Etherbooting from a Linux box and running X.

Hopefully my experience will help others who are debugging such problems. 
 Network booting is a very useful technology, and I am pleased to be able 
to contribute to making it more widespread and accessible.

Marty

---
    Try: http://rom-o-matic.net/ to make Etherboot images instantly.

   Name: Martin D. 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] testing from pcmcia flash card in place of floppy

[Robb M. <ma...@ac...>]

> >We have a custom pc with a pcmcia flash card...

I interpret the "We" above to imply a company, and from that, a commercial
end product.
Given this, you should bear in mind that the first solution Marty presents
may have licensing issues.
Has anyone tried the etherboot ".COM" with FREEDOS?

> What you want to do first is to make your Flash bootable.  You can do
> that in a number of ways, depending on what operating system you plan to
> use.
>
> Try this:
>
>    - Run FDISK and make a DOS partition on D:
>
>    - FORMAT /S D:

Re: [Etherboot-developers] testing from pcmcia flash card in place of floppy

[Robb M. [Genedyne] <gen...@ac...>]

> We have a custom pc with a pcmcia flash card and no floppy. The flash card
> appears to the computer as hard drive d:

> The flash has a problem. The first sector from the flash gets read in and
> executed ok. But the code that comes from the flash attempts to read the
> rest of the loader from floppy. Looking at the source, it seems clear, the
> boot sector code just assumes it comes from diskette on drive a and that
it
> should get the rest of the code from the same place.

I am going to assume that since you state above that "The first sector from
the flash gets read in and executed ok.", that your custom PC supports the
PCMCIA card through the BIOS (i.e., INT 0x13) as drive 0x81 (which would
then be mapped as drive "D:" by an OS such as (MS)DOS, and that your "custom
pc" allows you to boot from BIOS drive 0x81 (curious..."A:" and "C:" are the
common options)

You should be able to modify "floppyload.S" to ensure the DL register
contains 0x81 on all INT 0x13 calls. Note that this might require a bit of
creativity, since the existing code is getting close to the 512 byte limit
for one sector.

If this was of much use, you could provide a patchable byte just prior to
the 0xAA55 at the end of the sector, which would default to 0x00 (first
floppy drive), but could be easily patched.

Good Luck,
Robb Main.

Re: [Etherboot-developers] testing from pcmcia flash card in place of floppy

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

On 1/16/2001 2:41 PM Eno Compton Eno...@Mi... wrote:
>We have a custom pc with a pcmcia flash card and no floppy. The flash card
>appears to the computer as hard drive d: To test the etherboot, I wrote the
>driver and the boot to a floppy on another computer, copied the first 64k
>from the floppy to the flash card and started testing.
>The floppy boots fine ... on floppy equipped machines which made me think
>this would be easy. But ...

This won't work because a floppy image is designed to load from the 
floppy drive.

>The flash has a problem. The first sector from the flash gets read in and
>executed ok. But the code that comes from the flash attempts to read the
>rest of the loader from floppy. Looking at the source, it seems clear, the
>boot sector code just assumes it comes from diskette on drive a and that it
>should get the rest of the code from the same place.
>Can anyone suggest how I can get past this problem? 

Sure.  Etherboot is quite flexible about what it will boot from.  So far 
we have: Floppy, ROM, lilo, and DOS (.COM file) working.

What you want to do first is to make your Flash bootable.  You can do 
that in a number of ways, depending on what operating system you plan to 
use.

Try this:

   - Run FDISK and make a DOS partition on D:

   - FORMAT /S D:
   
   - Make a DOS .COM Executable file by telling Etherboot something like:

     cd src
     make bin32/rtl8139.com

     (substitute your rom type for "rtl8139")

     or you can download one from http://rom-o-matic.net/ by choosing
     "DOS .COM Executable" from the ROM type menu.

   - copy your .com file to drive D:

   - add a line to your AUTOEXEC.BAT or CONFIG.SYS file to run your .COM
     file on startup.

If drive D: is bootable, and your BIOS will let you boot from it, it 
should start DOS, and run Etherboot, which should execute and do what you 
want.

Another way to use this is to use the SYSLINUX package, which sort of 
does the same thing, except it makes the partition on the flash bootable. 
 Using SYSLINUX you would still create a FAT (dos) filesystem on the 
flash, and wouldn't need DOS.  You would hand SYSLINUX an Etherboot image 
(which is make with:

    cd src
    make bin32/rtl8129.lzlilo

or you can get one from http://rom-o-matic.net/

Hopefully that will get you going.  Let us know how it goes...

Regards,

Marty

---
    Try: http://rom-o-matic.net/ to make Etherboot images instantly.

   Name: Martin D. 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] testing from pcmcia flash card in place of floppy

[Ken Y. <ke...@nl...>]

|The flash has a problem. The first sector from the flash gets read in and
|executed ok. But the code that comes from the flash attempts to read the
|rest of the loader from floppy. Looking at the source, it seems clear, the
|boot sector code just assumes it comes from diskette on drive a and that it
|should get the rest of the code from the same place.

Sure. That's why the boot sector code is called floppyload.bin.

|Can anyone suggest how I can get past this problem? 

You could try to make a LILO compatible image .lilo and boot it from
syslinux or LILO. There are targets in the Makefile for making .lilo
images.

[Etherboot-developers] testing from pcmcia flash card in place of floppy

[Eno C. <Eno...@Mi...>]

We have a custom pc with a pcmcia flash card and no floppy. The flash card
appears to the computer as hard drive d: To test the etherboot, I wrote the
driver and the boot to a floppy on another computer, copied the first 64k
from the floppy to the flash card and started testing.

The floppy boots fine ... on floppy equipped machines which made me think
this would be easy. But ...

The flash has a problem. The first sector from the flash gets read in and
executed ok. But the code that comes from the flash attempts to read the
rest of the loader from floppy. Looking at the source, it seems clear, the
boot sector code just assumes it comes from diskette on drive a and that it
should get the rest of the code from the same place.

Can anyone suggest how I can get past this problem? 

Eno Compton

Re: [Etherboot-developers] Re: Intel CA810E mobo doesn't see Etherboot Option ROM

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

On 1/14/2001 5:57 PM Ken Yap ke...@nl... wrote:
>|It appears Etherboot 4.6.12 does not produce ROM code that is detected 
>|with this Intel motherboard.  As I mentioned previously, Etherboot does 
>|work with an older Intel motherboard (the SE440BX2).

>Two thing you could try:
>Configure the ROM as a legacy ROM rather than a PnP ROM.

This new "legacy free" motherboard seems to have removed all code to deal 
with this kind of ROM layout.

>Try to get hold of the latest PnP specs for option ROMs. The headers in
>the Etherboot ROM probably don't conform in some way. As I haven't had
>PnP BIOSes till recently, all the PnP stuff was contributed and untested
>by me personally.

Great minds think alike :-)

By the time I got your message I had already downloaded specs, extracted 
ROM contents of the Intel and 3Com cards for comparison, debugged and 
developed a patch for the bug.  I wanted to write up a description of the 
fix and how I found it before replying.

>Also send me a dump of the first 512 bytes of the commercial ROMs that
>work so that I can have a look at the headers.

I'll include this in the message I send about this.  I have a client 
emergency to take care of this morning, but the bug/problem is that there 
is what appears to be a typo in loader.S which causes one of the header 
fields to be in the wrong place.

I'll send in a small patch for loader.S, which fixes this.  The bug 
exists in Netboot's code as well, so this is probably also of interest to 
that list.

Regards,

Marty

---
    Try: http://rom-o-matic.net/ to make Etherboot images instantly.

   Name: Martin D. 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: Intel CA810E mobo doesn't see Etherboot Option ROM

[Ken Y. <ke...@nl...>]

|It appears Etherboot 4.6.12 does not produce ROM code that is detected 
|with this Intel motherboard.  As I mentioned previously, Etherboot does 
|work with an older Intel motherboard (the SE440BX2).

Two thing you could try:

Configure the ROM as a legacy ROM rather than a PnP ROM.

Try to get hold of the latest PnP specs for option ROMs. The headers in
the Etherboot ROM probably don't conform in some way. As I haven't had
PnP BIOSes till recently, all the PnP stuff was contributed and untested
by me personally.

Also send me a dump of the first 512 bytes of the commercial ROMs that
work so that I can have a look at the headers.

[Etherboot-developers] Re: Intel CA810E mobo doesn't see Etherboot Option ROM

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

On 1/12/2001 11:48 PM Ste...@3c... Ste...@3c... wrote:
>Marty...let me know how the 905C & ROM work out on the CA810e....any problems
>and we will be right on it. I will double check with our test staff and 
>see of we have that board in our collection.

Thanks Steve,

I just tested the Intel CA810E motherboard with a new 3Com 3C905C-TX-M 
and its option ROM is detected and executes.  I also tested with an Intel 
PRO/100+ card and it also works.  (both cards attempted PXE booting).

It appears Etherboot 4.6.12 does not produce ROM code that is detected 
with this Intel motherboard.  As I mentioned previously, Etherboot does 
work with an older Intel motherboard (the SE440BX2).

Does anyone have an idea how Etherboot code might differ from 
3Com/LanWorks or Intel code?  I'm guessing that it is scanning for some 
markers in the ROM that it does not find.  I am not sure what those might 
be.

Thanks for any and all assistance and suggestions.

Regards,

Marty

---
    Try: http://rom-o-matic.net/ to make Etherboot images instantly.

   Name: Martin D. 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: Diskless Notebook

[Ken Y. <ke...@nl...>]

>Note, to have a really diskless setup you'd need to find a network boot loade
>r
>that can handle those cards.  I don't know if such a thing exists.  It might
>be possible with the Netboot package if you can get a packet driver that does
>n't
>need any other TSR programs to run the PCMCIA controller.  Etherboot definite
>ly
>doesn't support PCMCIA network adapters.

It's probably just a matter of someone writing a PCMCIA subsystem
handler in a similar fashion to the PCI subsystem handler to enable
access to the cardbus.

[Etherboot-developers] intel CA810E mobo doesn't see Etherboot Option ROM

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

Has anyone successfully gotten an Intel CA810E (micro-ATX) motherboard to 
boot from a ROM on a PCI card?

I took a PCI ethernet card with an Etherboot ROM on it which works fine 
on an Intel SE440BX2 motherboard, and put it in the CA810E motherboard.  
It failed to find the ROM.  

Now the CA810E is a pretty new motherboard, so it is quite conceivable 
that there is a bug in the latest BIOS (I upgraded it to the latest (Nov 
8) version).

I tried making OPTION ROM the first boot device, but no luck. Note that 
the machine Etherboots just fine from a floppy, so I'm pretty sure this 
new Intel BIOS wants or needs something that it is not finding.  Since it 
works on an older motherboard, I am wondering if the bus speed is too 
great or something.

My next move is to get a 3Com 3c905C-TXM card with their Flash Option ROM 
on it, and see if that is recognized.  At least I'll know it is possible.

Anybody know what might be going on?

Thanks,

Marty

---
    Try: http://rom-o-matic.net/ to make Etherboot images instantly.

   Name: Martin D. 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: [Etherboot-users] Etherboot 4.7.17 (development) released

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

Ken Yap <ke...@nl...> writes:

> |> Mm, believe me. I ran gdb on objdump to find out what was going on.
> |> Fortunately I resisted the temptation to call the objdump authors idiots
> |> until I had double checked the spec.
> |
> |Well I have double checked the specs (i.e in the gabi documents), and
> |it says that section table is optional, in several place.  If you
> |actually have a section table then yes the first entry needs to be a
> |dummy.
> 
> All the same, even though I specified 0 for the number of section table
> entries and null for the offset, the tools went looking for a section
> table. Feel free to take this up with the BFD maintainers yourself, I'm
> not going to lose sleep over 32 bytes extra in the file.

No I won't either but if I get the chance I'll complain to them...
 
> |1. convert_param.c  
> |2. kernel
> |3. Ramdisk (optional)
> |
> |convert_param.c converts multiboot headers, and my redesigned headers, 
> |holds the hard coded kernel parmeters.  I use a little perl program
> |call mkelfImage to generate this.  
> |
> |I don't currently have any 16 bit code, I start the linux
> |kernel in it's 32bit entry point.
> 
> Etherboot doesn't have any 16 bit code either (except for the BIOS
> calls) when it's calling the extension in protected mode. The only 16
> bit mode code is in boot.S and setup.S from the kernel.
> 
> So it looks like you have all that you need already.

Hmm.  I'll have to look and see what etherboot is doing now.
More feedback after I have read your code :)

> 
> I might even change the code to detect the multiboot magic number
> automatically and eliminate one more configure option.

Actually that's an interesting kettle of fish.  Maybe I misread
the multiboot stuff but as I read it you only need the magic number
for a.out executables....

Eric

Re: [Etherboot-developers] Re: [Etherboot-users] Etherboot 4.7.17 (development) released

[Ken Y. <ke...@nl...>]

|> Mm, believe me. I ran gdb on objdump to find out what was going on.
|> Fortunately I resisted the temptation to call the objdump authors idiots
|> until I had double checked the spec.
|
|Well I have double checked the specs (i.e in the gabi documents), and
|it says that section table is optional, in several place.  If you
|actually have a section table then yes the first entry needs to be a
|dummy.

All the same, even though I specified 0 for the number of section table
entries and null for the offset, the tools went looking for a section
table. Feel free to take this up with the BFD maintainers yourself, I'm
not going to lose sleep over 32 bytes extra in the file.

|1. convert_param.c  
|2. kernel
|3. Ramdisk (optional)
|
|convert_param.c converts multiboot headers, and my redesigned headers, 
|holds the hard coded kernel parmeters.  I use a little perl program
|call mkelfImage to generate this.  
|
|I don't currently have any 16 bit code, I start the linux
|kernel in it's 32bit entry point.

Etherboot doesn't have any 16 bit code either (except for the BIOS
calls) when it's calling the extension in protected mode. The only 16
bit mode code is in boot.S and setup.S from the kernel.

So it looks like you have all that you need already.

I might even change the code to detect the multiboot magic number
automatically and eliminate one more configure option.

Re: [Etherboot-developers] Re: [Etherboot-users] Etherboot 4.7.17 (development) released

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

Ken Yap <ke...@nl...> writes:

> |> At least one is needed otherwise objdump complains. And reading the spec
> |> carefully you will see that the 0th entry is needed, it's a NULL entry.
> |
> |Hmm.  I'll look but a section table should be unnecessary.
> |I haven't tried striping it out though.
> 
> Mm, believe me. I ran gdb on objdump to find out what was going on.
> Fortunately I resisted the temptation to call the objdump authors idiots
> until I had double checked the spec.

Well I have double checked the specs (i.e in the gabi documents), and
it says that section table is optional, in several place.  If you
actually have a section table then yes the first entry needs to be a
dummy.

> |But it should be able to boot an Etherboot ELF image just as
> |etherboot does.   
> 
> Here's what a tagged Etherboot image contains, also an ELF Etherboot
> image:
> 
> 	1. Small stub program (first32.c)
> 	2. Kernel parameters
> 	3. Kernel boot sector (boot.S)
> 	4. Kernel setup sector (setup.S)
> 	5. Kernel
> 	6. Ramdisk (optional)
> 
> The stub program is there to handle append tag 129 to the parameters,
> handle kernel parameters of the special form xxx=rom, vga=xxx, and move
> the ramdisk to the top of memory. The stub program is passed 3
> parameters, a pointer to a structure describing Etherboot, a pointer to
> the header structure (tagged or ELF) so that the stub can find the
> segments, and a pointer to the bootp record so that it can extract
> necessary information out of that.
> 
> It then goes into real mode and calls the setup sector. The boot sector
> is there because the setup code references bits of it. Eventually
> protected mode is entered and the kernel is called.
> 
> >From what you describe it sounds like you are processing the Linux
> kernel in different way to generate an ELF image, perhaps even throwing
> out everything except the kernel segment? If that is so, how do you
> handle kernel parameters and ramdisks?
> 
> Nonetheless, your ELF image should load fine with or without
> IMAGE_MULTIBOOT, as I said, it's just a container. 

It's close.  Once you are dumped out of the container you
need to be in a well defined state.

If you are going to be in 32bit mode with paging disabled the
following things also should apply.
1) All of your segment registers are loaded with an unlimted segment.
   This means that every segment is valid to use until you reload it.
   And you don't need any kind of segment table.

2) You should know what kind of environment you are coming into.  And
some easy to find, parse, and ignore unknown parameters can be a big
help.

But as for changing of the config option I have no problem.


> The only difficulty
> might be with obtaining the BIOS information. I would argue that
> Etherboot should not do this but a stub should, just like above. Perhaps
> you already have a stub segment to do this?

Sort of.
And I do agree that there is definentily some value in stubs.
But I think there should be at least enough passed to the stub
so that knows if there is a BIOS present for it to call down to.
In the linuxBIOS case I don't have a BIOS is the normall accepted
sense of the word.

For things like hard coding command lines, and locations of ramdisks
stubs are definentily the right solution.

> 
> What does your image look like?

What I have is:

1. convert_param.c  
2. kernel
3. Ramdisk (optional)

convert_param.c converts multiboot headers, and my redesigned headers, 
holds the hard coded kernel parmeters.  I use a little perl program
call mkelfImage to generate this.  

I don't currently have any 16 bit code, I start the linux
kernel in it's 32bit entry point.

Eric

Re: [Etherboot-developers] Re: [Discuss] BOOTP record too large - fixed - but rom-o-matic image for realtek8139 is misbehaving

[Richard J. <rj...@im...>]

Marty Connor wrote:
[snip]

>> Well I downloaded it to my RH7 machine and the same thing happened, but when 
>> I telneted into the server which is RH6.2, and compiled the realtek rom from 
>> etherboot and ftp'd it here to my office it worked perfectly, problem solved.
>> 
>> Looks like RH7 has a problem with compiling it.  
>> 
>> This isn't the first time I've had trouble compiling things on RH7, I can't 
>> even compile a custom kernel without getting errors, and have to get all 
>> software in rpm format. I installed the updates but it's only gotten a bit 
>> better. 
>> 
>> It's gotten so bad that hopefully the debian cd's I ordered will arrive 
>> tomorrow. 
> 
Just out of curiosity, have you used kgcc for etherboot? I would be 
willing to bet that it would work pretty well not only for etherboot, 
but also fix most of the other "problems" you've been having.  move 
/usr/bin/gcc to /usr/bin/gcc.orig and symlink /usr/bin/kgcc to 
/usr/bin/gcc bet your custom kernel(I assume you mean a non RH provided 
kernel) and etherboot compilation troubles go away.
[snip]

[Etherboot-developers] Re: [Discuss] BOOTP record too large - fixed - but rom-o-matic image for realtek8139 is misbehaving

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

On 1/10/2001 7:21 PM Robert Stanford ro...@ro... wrote:
>> I'd be curious if you could download Etherboot from
>> etherboot.sourceforge.net and do:
>>
>>     $ tar -zxvf etherboot-4.6.12.tar.gz .
>>     $ cd etherboot-4.6.12/src
>>     $ make bin32/rtl8139.lzfd0
>>
>> (you'll need to have blank formatted floppy in the drive to do the last
>> command)
>>
>Well I downloaded it to my RH7 machine and the same thing happened, but when 
>I telneted into the server which is RH6.2, and compiled the realtek rom from 
>etherboot and ftp'd it here to my office it worked perfectly, problem solved.
>
>Looks like RH7 has a problem with compiling it.  
>
>This isn't the first time I've had trouble compiling things on RH7, I can't 
>even compile a custom kernel without getting errors, and have to get all 
>software in rpm format. I installed the updates but it's only gotten a bit 
>better. 
>
>It's gotten so bad that hopefully the debian cd's I ordered will arrive 
>tomorrow. 

Rob, Thanks a lot for your debugging help with this.  It appears the C 
compiler in RH7 breaks compilation of Etherboot.  I think it is really 
that there is a new version of the GNU Assembler (2.10.90).

Here's what I just discovered when compiling a rom by hand:

gcc -DMOTD -DIMAGE_MENU -DBACKOFF_LIMIT=7 -DASK_BOOT=3 
-DANS_DEFAULT=ANS_NETWORK -O2 -g -fstrength-reduce -fomit-frame-pointer 
-m386 -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W 
-Wno-format -Wno-unused -DVERSION_MAJOR=4 -DVERSION_MINOR=7 
-DVERSION=\"4.7.16\" -DRELOC=0x98000  -o bin32/pci.o -c pci.c
/tmp/ccPmCLtp.s: Assembler messages:
/tmp/ccPmCLtp.s:105: Warning: indirect lcall without `*'
/tmp/ccPmCLtp.s:214: Warning: indirect lcall without `*'
/tmp/ccPmCLtp.s:286: Warning: indirect lcall without `*'
/tmp/ccPmCLtp.s:359: Warning: indirect lcall without `*'
/tmp/ccPmCLtp.s:441: Warning: indirect lcall without `*'
/tmp/ccPmCLtp.s:512: Warning: indirect lcall without `*'
/tmp/ccPmCLtp.s:583: Warning: indirect lcall without `*'
/tmp/ccPmCLtp.s:654: Warning: indirect lcall without `*'
gcc -E -DMOTD -DIMAGE_MENU -DBACKOFF_LIMIT=7 -DASK_BOOT=3 
-DANS_DEFAULT=ANS_NETWORK -O2 -g -fstrength-reduce -fomit-frame-pointer 
-m386 -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W 
-Wno-format -Wno-unused -DVERSION_MAJOR=4 -DVERSION_MINOR=7 
-DVERSION=\"4.7.16\" -DRELOC=0x98000  start32.S | as  -o bin32/start32.o
{standard input}: Assembler messages:
{standard input}:278: Warning: indirect ljmp without `*'

Well doesn't this just suck.  I begin to see why people were upset with 
Red Hat's decision to include a questionnable C compiler in RH7.  I hope 
this is not too hard to fix.  It looks like another assembler syntax 
problem.  Can anyone suggest how to fix it?  I am looking at either 
fixing this bug in RH7 or having to reinstall RH6.2 on the rom-o-matic. 
The warning in Start32.S is particularly interesting.

Oh yes, before you ask, here's the output of "as --version"

[mdc@rom src]$ as --version
GNU assembler 2.10.90
Copyright 2000 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.
This assembler was configured for a target of `i386-redhat-linux'.

If this can't be resolved quickly the only responsible thing to do is to 
disable the rom-o-matic until I can re-install another version of Linux.  
I hope this can be made to work in RH7, however since a lot of Etherboot 
users will be using that version.

News as it happens.

Marty

---
    Try: http://rom-o-matic.net/ to make Etherboot images instantly.

   Name: Martin D. 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: [Etherboot-users] Etherboot 4.7.17 (development) released

[Ken Y. <ke...@nl...>]

|> At least one is needed otherwise objdump complains. And reading the spec
|> carefully you will see that the 0th entry is needed, it's a NULL entry.
|
|Hmm.  I'll look but a section table should be unnecessary.
|I haven't tried striping it out though.

Mm, believe me. I ran gdb on objdump to find out what was going on.
Fortunately I resisted the temptation to call the objdump authors idiots
until I had double checked the spec.

|But it should be able to boot an Etherboot ELF image just as
|etherboot does.   

Here's what a tagged Etherboot image contains, also an ELF Etherboot
image:

	1. Small stub program (first32.c)
	2. Kernel parameters
	3. Kernel boot sector (boot.S)
	4. Kernel setup sector (setup.S)
	5. Kernel
	6. Ramdisk (optional)

The stub program is there to handle append tag 129 to the parameters,
handle kernel parameters of the special form xxx=rom, vga=xxx, and move
the ramdisk to the top of memory. The stub program is passed 3
parameters, a pointer to a structure describing Etherboot, a pointer to
the header structure (tagged or ELF) so that the stub can find the
segments, and a pointer to the bootp record so that it can extract
necessary information out of that.

It then goes into real mode and calls the setup sector. The boot sector
is there because the setup code references bits of it. Eventually
protected mode is entered and the kernel is called.

From what you describe it sounds like you are processing the Linux
kernel in different way to generate an ELF image, perhaps even throwing
out everything except the kernel segment? If that is so, how do you
handle kernel parameters and ramdisks?

Nonetheless, your ELF image should load fine with or without
IMAGE_MULTIBOOT, as I said, it's just a container. The only difficulty
might be with obtaining the BIOS information. I would argue that
Etherboot should not do this but a stub should, just like above. Perhaps
you already have a stub segment to do this?

What does your image look like?

[Etherboot-developers] Re: [Etherboot-users] Etherboot 4.7.17 (development) released

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

Ken Yap <ke...@nl...> writes:

> |What do you need a section header for?  Sections aren't really applicable
> |to programs, just relocatable content. 
> |You should only need to care about Program Headers.
> 
> At least one is needed otherwise objdump complains. And reading the spec
> carefully you will see that the 0th entry is needed, it's a NULL entry.

Hmm.  I'll look but a section table should be unnecessary.
I haven't tried striping it out though.

> |> + Added code to support non-MULTIBOOT ELF when IMAGE_ELF is selected but
> |> IMAGE_MULTIBOOT is not.  Booting from images created by mkelf-linux
> |> now works!
> |
> |I definentily need to review this and get a little discussion going.
> |I have patches for linux to add a syscall to boot ELF images,
> |on both x86 & alpha.  
> |
> |It would be nice if etherboot had a compatible format.  I intend to 
> |start writing just what beyond the elf format will be needed to be
> |compatible.
> 
> I'm just using ELF format as a container. You can continue to use
> IMAGE_MULTIBOOT. My changes affect only what happens when
> IMAGE_MULTIBOOT is not selected, which was undefined prior to my
> changes. Seeing as the Linux kernel image file is actually a 3 section
> image, and the sections are not the traditional code, data, bss at all;
> the addresses in the image are tied to real physical addresses (no
> relocation data) and real devices, what can your Linux patch sensibily
> do when given an Etherboot ELF image?

I need to read the code, to see what you have.

But it should be able to boot an Etherboot ELF image just as
etherboot does.   

Currently I have small linux program (I'll put it up for down load
this week) that can do dhcp & tftp and the start the downloaded
kernel, on top of a linux kernel.

Currently I can create images that will booth with either etherboot
or my program&kernel put on a linux floppy.  This handles nicely
the cards that linux supports that etherboot doesn't yet support.
Or architectures (alpha) that etherboot doesn't support yet.

The environment my kernel patch exports: 
images tied to real physical addresses.  (You can have a virtual !=
physical address but the virtual is ignored).

The processor comes up in native mode (32 bit protected mode on x86),
with essentially virutal addressing disabled. (On some architectures
you can't disable the mmu and have to create a page table to simulate
this).

A register is loaded with a pointer to a data block with information
that you can't find out by probing the hardware, but you need.  Like
how much memory is in the system.  BIOS tables in a know range of
physical are considered probable.  This that require BIOS calls are 
not considered probable.

Not needing to do BIOS calls is important for me because I'm doing
this as part of the work to get linuxBIOS going&useful.  linuxBIOS
being just a big enough stub to boot a kernel on a machine with
none of the traditional legacy BIOS calls.

Does this clarify where I'm coming from?

Eric

[Etherboot-developers] Re: [Etherboot-users] Etherboot 4.7.17 (development) released

[Ken Y. <ke...@nl...>]

|What do you need a section header for?  Sections aren't really applicable
|to programs, just relocatable content. 
|You should only need to care about Program Headers.

At least one is needed otherwise objdump complains. And reading the spec
carefully you will see that the 0th entry is needed, it's a NULL entry.

|> + Added code to support non-MULTIBOOT ELF when IMAGE_ELF is selected but
|> IMAGE_MULTIBOOT is not.  Booting from images created by mkelf-linux
|> now works!
|
|I definentily need to review this and get a little discussion going.
|I have patches for linux to add a syscall to boot ELF images,
|on both x86 & alpha.  
|
|It would be nice if etherboot had a compatible format.  I intend to 
|start writing just what beyond the elf format will be needed to be
|compatible.

I'm just using ELF format as a container. You can continue to use
IMAGE_MULTIBOOT. My changes affect only what happens when
IMAGE_MULTIBOOT is not selected, which was undefined prior to my
changes. Seeing as the Linux kernel image file is actually a 3 section
image, and the sections are not the traditional code, data, bss at all;
the addresses in the image are tied to real physical addresses (no
relocation data) and real devices, what can your Linux patch sensibily
do when given an Etherboot ELF image?

[Etherboot-developers] Re: [Etherboot-users] Etherboot 4.7.17 (development) released

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

Ken Yap <ke...@nl...> writes:

> I have released Etherboot 4.7.17 at http://etherboot.sourceforge.net
> 
> Changes in this release:
> 
> + Added atftp 0.2 (ftp://ftp.mamalinux.com/pub/atftp/) to contrib/.
> Supposedly contains a tftpd that runs multithreaded, which may help
> people having problems with *inetd shutting down tftpds that spawn too
> fast.

Cool.  I hadn't noticed there was a second rev of atftp out.
 
> + Got ELF format creation in mkelf-linux working now. At least one empty
> section header is required to make a valid ELF file.

What do you need a section header for?  Sections aren't really applicable
to programs, just relocatable content. 
You should only need to care about Program Headers.
> 
> + Added code to support non-MULTIBOOT ELF when IMAGE_ELF is selected but
> IMAGE_MULTIBOOT is not.  Booting from images created by mkelf-linux
> now works!

I definentily need to review this and get a little discussion going.
I have patches for linux to add a syscall to boot ELF images,
on both x86 & alpha.  

It would be nice if etherboot had a compatible format.  I intend to 
start writing just what beyond the elf format will be needed to be
compatible.

Eric

[Etherboot-developers] Etherboot 4.7.17 (development) released

[Ken Y. <ke...@nl...>]

I have released Etherboot 4.7.17 at http://etherboot.sourceforge.net

Changes in this release:

+ Added atftp 0.2 (ftp://ftp.mamalinux.com/pub/atftp/) to contrib/.
Supposedly contains a tftpd that runs multithreaded, which may help
people having problems with *inetd shutting down tftpds that spawn too
fast.

+ Added a few more Tulip entries to config.c and NIC, not all of them
have been confirmed working.

+ Got ELF format creation in mkelf-linux working now. At least one empty
section header is required to make a valid ELF file.

+ Added code to support non-MULTIBOOT ELF when IMAGE_ELF is selected but
IMAGE_MULTIBOOT is not.  Booting from images created by mkelf-linux
now works!

+ TAGGED_IMAGE is now not always selected. It's just the fallback if
none of TAGGED_IMAGE, AOUT_IMAGE or ELF_IMAGE is selected. Therefore you
must explicitly select TAGGED_IMAGE if you want it, and you have
selected AOUT_IMAGE or ELF_IMAGE.  Startup banner line displays all
image formats accepted.

+ exit() in mknbi/start32.S should copy argument to %eax first.

+ Images with 0xAA55 in bytes 510-511 are no longer accepted, which
should reject invalid formats now, e.g. Linux kernel images, which have
a boot sector in the first block. Strictly this does not conform to the
original netboot spec by Jamie Honan, which specifies that non-tagged,
linear images starting from 0x10000 are allowed, but that format is
pretty useless now. Any decent loading scheme needs a roadmap to the
blocks in the downloaded file, which is what tagged, a.out, or ELF
images provide in the header. Q: What is config_buffer in main.c for?
Nothing else seems to use it. Is it a relic of non-tagged images?

+ Clean up lots of obsolete prototypes in etherboot.h. Ansify lots of
function headers in main.c. Make lots of functions and variables in
main.c static.  Make bootmenu.c:getoptvalue() static.

+ Simple external menu program works!

+ More documentation cleanup, notably editing the compile options to
match what has been done.

MD5 sums:

6bde3ea28b6d320640284586520c7454  etherboot-4.7.17.tar.bz2
b75f136890b98aa62fb7f5546f47b0ce  etherboot-4.7.17.tar.gz

Re: [Etherboot-developers] Etherboot 4.7.16 (development) released

[Ken Y. <ke...@nl...>]

|> + Started on Elf support in mknbi.
|
|I'm just wondering where you are going here.  I have done
|some parellel work (documentation is still pending), and would like

Just to create ELF images with mkelf-linux and boot that. The advantages
are to have a widely-known standard to work to, and be able to use
standard tools like objdump to work on elfed images. There is no change
to the existing ELF boot code in Etherboot, just mknbi (mkelf). So it's
quite possible your changes are complementary.

|to see how it compares.  In particular I created a variation on 
|the multiboot stuff that allows an arbitrary number of parameters
|to be defined instead of just that limited structure.

Is there documentation on multiboot somewhere?