etherboot-developers — Discussion of developer issues

[Etherboot-developers] Boot Eprom

[BM <ss_...@ya...>]

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

[Etherboot-developers] Re: [Etherboot-users] mknbi memtest?

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

>I would like to have an option on my etherboot menu to load memtest.

[Followups set to developer list.]

Somebody with a gnu mail address was trying to build memtest so that it
could be turned into a tagged image for netloading, see the developer
mailing list archives of about a few weeks ago, but we haven't heard
from him for a while. memtest is segmented like a Linux kernel image, so
one would think at first that mknbi-linux could be used on it but no,
the boot and setup segments are slightly different and need some
hacking. If you love reading x86 assembler, there's your new project.  :-)

Re: [Etherboot-developers] Bugfixed PXE (and patched patch)

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

Hi,

Thanks for unifying loader.S and pxeloader.S.  I've made the constants
in loader.S and etherboot.h all in hex and added comments. I also put
the space reservation for the two words inside #ifdef PXELOADER as it's
not needed by other loaders and will increase their size.  Here is the
latest patch, wrt 5.0.2.

diff -urP --exclude=Roms ../../etherboot-5.0.2/src/Makefile ./Makefile
--- ../../etherboot-5.0.2/src/Makefile	Fri Jun 22 01:44:39 2001
+++ ./Makefile	Thu Jun 28 13:35:39 2001
@@ -89,8 +89,8 @@
 CPP=		gcc -E
 OBJCOPY=	objcopy
 VERSION_MAJOR=	5
 VERSION_MINOR=	0
 VERSION_PATCH=	2
 VERSION=	$(VERSION_MAJOR).$(VERSION_MINOR).$(VERSION_PATCH)
 CFLAGS32+=	-DVERSION_MAJOR=$(VERSION_MAJOR) \
 		-DVERSION_MINOR=$(VERSION_MINOR) \
@@ -142,7 +142,7 @@
 WDFLAGS=	-DINCLUDE_WD -DWD_DEFAULT_MEM=0xCC000
 W89C840FLAGS=	-DINCLUDE_W89C840
 
-SRCS=	boot1a.s comprefix.S liloprefix.S loader.S pxeloader.S start32.S serial.S
+SRCS=	boot1a.s comprefix.S liloprefix.S loader.S start32.S serial.S
 SRCS+=	main.c pci.c osloader.c nfs.c misc.c ansiesc.c bootmenu.c config.c
 SRCS+=	md5.c floppy.c
 
@@ -254,11 +254,11 @@
 bin/rzloader.s:	loader.S $(MAKEDEPS)
 	$(CPP) $(LCONFIG) -DZLOADER -o $@ $<
 
-bin/pxeloader.s:	pxeloader.S $(MAKEDEPS)
-	$(CPP) $(LCONFIG) -o $@ $<
+bin/pxeloader.s:	loader.S $(MAKEDEPS)
+	$(CPP) $(LCONFIG) -DPXELOADER -o $@ $<
 
-bin/pxezloader.s:	pxeloader.S $(MAKEDEPS)
-	$(CPP) $(LCONFIG) -DZLOADER -o $@ $<
+bin/pxezloader.s:	loader.S $(MAKEDEPS)
+	$(CPP) $(LCONFIG) -DPXELOADER -DZLOADER -o $@ $<
 
 bin/prloader.s:	loader.S $(MAKEDEPS)
 	$(CPP) $(LCONFIG) -DPCI_PNP_HEADER -o $@ $<
diff -urP --exclude=Roms ../../etherboot-5.0.2/src/etherboot.h ./etherboot.h
--- ../../etherboot-5.0.2/src/etherboot.h	Tue Jun 19 21:54:05 2001
+++ ./etherboot.h	Thu Jun 28 09:06:36 2001
@@ -440,8 +440,11 @@
 #define NFS_READ_SIZE	1024
 
 #define	FLOPPY_BOOT_LOCATION	0x7c00
+/* Must match offsets in loader.S */
+#define ROM_SEGMENT		0x1fa
+#define ROM_LENGTH		0x1fc
 
-#define	ROM_INFO_LOCATION	0x7dfa
+#define	ROM_INFO_LOCATION	(FLOPPY_BOOT_LOCATION+ROM_SEGMENT)
 /* at end of floppy boot block */
 
 struct rom_info {
diff -urP --exclude=Roms ../../etherboot-5.0.2/src/genrules.pl ./genrules.pl
--- ../../etherboot-5.0.2/src/genrules.pl	Mon Apr 23 23:51:53 2001
+++ ./genrules.pl	Mon Jun 25 00:16:36 2001
@@ -141,6 +141,14 @@
 	cat \$(PRZLOADER) \$< > \$@
 	bin/makerom \$(MAKEROM_\$*) -p $ids -i\$(IDENT32) \$@
 
+bin32/$rom.pxe:	bin32/$drv.img \$(PXELOADER)
+	cat \$(PXELOADER) \$< > \$@
+	bin/makerom -x \$(MAKEROM_\$*) -p $ids -i\$(IDENT32) \$@
+
+bin32/$rom.lzpxe:	bin32/$drv.huf \$(PXEZLOADER)
+	cat \$(PXEZLOADER) \$< > \$@
+	bin/makerom -x \$(MAKEROM_\$*) -p $ids -i\$(IDENT32) \$@
+
 EOF
 }
 foreach $rom (sort keys %roms_isa) {
@@ -149,6 +157,10 @@
 bin32/$rom.rom:	bin32/$rom.img \$(RLOADER)
 
 bin32/$rom.lzrom:	bin32/$rom.huf \$(RZLOADER)
+
+bin32/$rom.pxe:	bin32/$rom.img \$(PXELOADER)
+
+bin32/$rom.lzpxe:	bin32/$rom.huf \$(PXEZLOADER)
 
 EOF
 }
diff -urP --exclude=Roms ../../etherboot-5.0.2/src/loader.S ./loader.S
--- ../../etherboot-5.0.2/src/loader.S	Sat Jun 16 15:36:25 2001
+++ ./loader.S	Thu Jun 28 13:57:01 2001
@@ -16,10 +16,22 @@
  */
 #endif
 
+#ifdef	PXELOADER
+#ifdef	PCI_PNP_HEADER
+#error Cannot have PXELOADER and PCI_PNP_HEADER
+#endif
+#endif
+
 /* This provides for execution at 0x88000 to avoid disk-on-chip drivers */
 #undef	NOT_AT_0x9xxxx
 #if	(RELOC & 0xF0000) != 0x90000
 #define NOT_AT_0x9xxxx
+#else
+#ifdef	PXELOADER
+/* also don't depend on the amount of memory int 12 reports as it has been 
+   decreased by PXE and not increased again even after releasing it */
+#define NOT_AT_0x9xxxx
+#endif / * PXELOADER */
 #define	MAX_SP	((RELOC & 0xF0000) + 0x10000 - RELOC)
 /* e.g. RELOC = 0x84000, MAX_SP = 0x90000 - 0x84000 = 0xC000 */
 #endif
@@ -63,11 +75,12 @@
 #define SCRATCHVEC	0x300
 
 /* Offsets of words containing ROM's CS and size (in 512 byte blocks)
- * from start of floppy boot block at 0x7C00
+ * from start of floppy boot block at 0x7c00
+ * Offsets must match those in etherboot.h
  */
-#define FLOPPY_SEGMENT	0x7C0
-#define ROM_SEGMENT	506
-#define ROM_LENGTH	508
+#define FLOPPY_SEGMENT	0x7c0
+#define ROM_SEGMENT	0x1fa
+#define ROM_LENGTH	0x1fc
 
 /* Do not change these values unless you really know what you are doing
  * the pre-computed lookup tables rely on the buffer size being 4kB or
@@ -87,6 +100,7 @@
 	.org 0
 
 _start: 
+#ifndef	PXELOADER
 	.word 0xAA55			/* BIOS extension signature */
 size:	.byte 0				/* number of 512 byte blocks */
 					/* = number of 256 word blocks */
@@ -187,6 +201,126 @@
 	jmp	blockmove
 pnpentry:
 	movw	$0,%ax
+#else /* PXELOADER */
+#define PXENV_UNDI_SHUTDOWN	0x05
+#define PXENV_UNLOAD_STACK	0x70
+	jmp	startpxe
+size:	.byte 64			/* number of 512 byte blocks */
+					/* PXE will not load more than 32K */
+					/* so this should be <= 64 */
+					/* filled in by makerom program */
+startpxe:
+	jmp	$FLOPPY_SEGMENT, $n-_start
+n:
+	movw	%sp, %bp
+
+	push	%cs
+	pop	%ds
+	
+	movw	$hellomsgend-hellomsg, %cx
+	movw	$hellomsg-_start, %si
+	movw	$0x0007, %bx			/* page 0, attribute 7 (normal) */
+	movb	$0x0e, %ah			/* write char, tty mode */
+prloop_hellomsg: 
+	lodsb
+	int	$0x10
+	loop	prloop_hellomsg
+	
+	movw	$MAGIC,%ax
+	jmp	pxefind
+hellomsg:
+	.ascii	"PXE loader for etherboot"
+#if	defined(ZLOADER) 
+	.ascii	"(with ZLOADER)"
+#endif
+	.ascii	"\r\n"
+hellomsgend: 
+pxe_undi_shutdown_pkt:
+	.word	0
+pxe_unload_stack_pkt:
+	.word	0
+	.word	0,0,0,0,0
+PXEEntry:
+	.word	0,0
+pxefind:
+	les	4(%bp), %di		/* !PXE structure */
+	cmpl	$0x45585021, %es:(%di)	/* '!PXE' signature */
+	je	have_pxe
+	movl	$0x202b564e, pxemsg2-_start /* 'NV+ ' */
+	mov	$0x5650, %ax
+	int	$0x1a
+	jc	no_pxe
+	cmp	$0x564e, %ax
+	jne	no_pxe
+
+	cmpl	$0x4e455850, %es:(%bx)	/* 'PXEN' signature */
+	jne	no_pxe
+	cmpw	$0x2b56, %es:4(%bx)	/* 'V+' signature */
+	jne	no_pxe
+	mov	%bx, %cs:PXEEntry  -_start /* save them in case we use PXENV+ */
+	mov	%es, %cs:PXEEntry+2-_start
+	cmpw	$0x201, %es:6(%bx)	/* API version 2.1 or higher */
+	jae	get_pxe			/* otherwise use PXENV+ */
+use_pxenv:
+	les	%es:0x0a(%bx), %di
+	mov	%di, %cs:PXEEntry  -_start
+	mov	%es, %cs:PXEEntry+2-_start
+	push	%ds
+	pop	%es
+	mov	$pxe_undi_shutdown_pkt, %di
+	mov	$PXENV_UNDI_SHUTDOWN, %bx
+	lcall	%cs:(PXEEntry-_start)
+	mov	$pxe_unload_stack_pkt, %di
+	mov	$PXENV_UNLOAD_STACK, %bx
+	lcall	%cs:(PXEEntry-_start)
+	jmp	pxe
+get_pxe:
+	les	%es:0x28(%bx), %di
+	cmpl	$0x45585021, %es:(%di)	/* '!PXE' signature */
+	jne	no_pxe
+	jmp	have_pxe
+/*	mov	%cs:PXEEntry+2-_start, %bx /* restore PXENV+ */
+/*	mov	%bx, %es
+	mov	%cs:PXEEntry  -_start, %bx
+	jmp	use_pxenv */
+have_pxe:
+	les	%es:0x10(%di), %di
+	mov	%di, %cs:PXEEntry  -_start
+	mov	%es, %cs:PXEEntry+2-_start
+
+	pushw	%cs
+	pushw	$pxe_undi_shutdown_pkt
+	pushw	$PXENV_UNDI_SHUTDOWN
+	lcall	%cs:(PXEEntry-_start)
+	add	$6, %sp
+	pushw	%cs
+	pushw	$pxe_unload_stack_pkt
+	pushw	$PXENV_UNLOAD_STACK
+	lcall	%cs:(PXEEntry-_start)
+	add	$6, %sp
+
+pxe:	movw	$pxemsg-_start+3, %si
+	movw	$pxemsgend-pxemsg-3, %cx
+	jmp	pxe_print
+no_pxe:
+	movw	$pxemsg-_start, %si
+	movw	$pxemsgend-pxemsg, %cx
+pxe_print:
+	movw	$0x0007, %bx			/* page 0, attribute 7 (normal) */
+	movb	$0x0e, %ah			/* write char, tty mode */
+prloop_pxemsg: 
+	lodsb
+	int	$0x10
+	loop	prloop_pxemsg
+	
+	movw	$MAGIC,%ax
+	jmp	blockmove
+pxemsg:
+	.ascii	"No PXE"
+pxemsg2:
+	.ascii	"    unloaded\r\n"
+pxemsgend:
+#endif /* PXELOADER*/
 blockmove: 
 	pushw	%ax			/* indicates whether PnP or legacy */
 /* The following copy is a bit convoluted to save source code, so here a few
@@ -208,6 +342,16 @@
 	movw	%ax, ROM_SEGMENT
 	movw	%cx, ROM_LENGTH
 	popw	%ds			/* restore DS */
+
+/* PXE loads this code in FLOPPY_SEGMENT so we have to leave some room
+   or it will clobber code */
+#ifdef	PXELOADER
+	jmp	endrominfo
+	.org	ROM_SEGMENT
+	.word	0
+	.word	0
+endrominfo:
+#endif	/* PXELOADER */
 
 #if	!defined(ZLOADER) || defined(MOVEROM)
 	cld
diff -urP --exclude=Roms ../../etherboot-5.0.2/src/main.c ./main.c
--- ../../etherboot-5.0.2/src/main.c	Sat Jun 23 13:25:42 2001
+++ ./main.c	Tue Jun 26 23:07:53 2001
@@ -179,6 +179,7 @@
 static inline void try_floppy_first(void)
 {
 #if (TRY_FLOPPY_FIRST > 0) && defined (FLOPPY)
+	int i;
 	printf("Trying floppy");
 	disk_init();
 	for (i = TRY_FLOPPY_FIRST; i-- > 0; ) {
diff -urP --exclude=Roms ../../etherboot-5.0.2/src/makerom.c ./makerom.c
--- ../../etherboot-5.0.2/src/makerom.c	Sat Jun 23 21:10:15 2001
+++ ./makerom.c	Thu Jun 28 13:25:50 2001
@@ -183,7 +183,7 @@
 		printf("%ld bytes read\n", fs);
 	if (ispxe) {
 		romsize=fs;
-		rom[2] = romsize / 512L;
+		rom[2] = ( romsize / 512L ) + 1 ;
 		goto writerom ;
 	}
 

Re: [Etherboot-developers] Bugfixed PXE

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

>>Well, turns out that main.c uses the rom_info structure, BUT there are
>>no obvious cues that rom_info in main.c and ROM_SEGMENT in loader.S are
>>the same place. Just some absolute values - one in hex and the other in
>>decimal - and different names (c.f. _start, used in both - but which
>>really *is* different).

Sorry, guys you can blame me. I really should document this. But just
ask in this list if there's something you don't understand and I'll
realise there's something to fix/document.

rom_info is a structure located near the end of where the boot sector
would normally be read in (0x7c00-0x7dff). rom_info's got nothing to do
with floppies, it's just a place to pass information.  The startup code
needs some place to stash two shorts, the ROM segment address (value of
CS on entering Etherboot) and the length of the ROM in words (the third
byte of the ROM, after the AA55). main retrieves it later by using a
pointer to a structure with two shorts. The idea is that knowing the
address where the ROM is located can be used to discriminate between
NICs and know which one it was booted from.

The assembler code to store the ROM address and size is a bit tricky
because one has to save DS, change DS to enable access to the addresses
0x7c00+506 and 508 (510 contains the boot sector signature, AA55), then
restore DS.

For the purposes of PXE loading, ROM segment doesn't really have any
meaning so it doesn't matter what values are put there. It's more likely
you upset the assembler code just mentioned.

Re: [Etherboot-developers] Bugfixed PXE

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

On 6/27/2001 4:25 PM Peter Lister P.L...@sy... wrote:
>OK, I found the magic numbers. :)

Give that man a prize!  Congrats!!
(I knew you'd figure it out :-)

>Had this just been affecting the ZLOADER, I would probably have left it,
>but I was getting weird hangs and crashes on our Supermicro boxes with
>Intel chips, even without ZLOADER, and I really have to get those going.

Necessity is a mother :-)

>Well, turns out that main.c uses the rom_info structure, BUT there are
>no obvious cues that rom_info in main.c and ROM_SEGMENT in loader.S are
>the same place. Just some absolute values - one in hex and the other in
>decimal - and different names (c.f. _start, used in both - but which
>really *is* different).

This is good information.  I am attempting to document parts of 
Etherboot, and I really appreciate your time on this.

>Vasil's original patch did actually allocate some space at the end of
>pxeloader.S for ROM_SEGMENT, but this broke when using ZLOADER, so I
>ifdef'd out the ROM_SEGMENT / ROM_LENGTH code, as it seemed to have no
>useful function, and we're not using a floppy, right? I was also worried
>by the fact that something was obviously being poked into somewhere I
>didn't understand.

Seems like a reasonable thing to do.

>So my fault for removing code without understanding the implications.
>BUT Etherboot didn't make it easy for me; this needs to be cleaned up
>and documented by someone who genuinely understands which way is up. It
>took me a *long* time to work out what was happening. Where *should*
>ROM_SEGMENT really be? Has Etherboot been poking into some random space
>and just been lucky until now?

I don't know if anyone at this moment understands this better, though I'm 
attempting to.  I suspect right now, each of us does what you just did.  
We spend a few long days and nights, figure things out, and post them.  
That's one reason Ken and I insist that people (as a general rule) 
respond to the lists rather than only sending us personal mail, so that 
stuff gets into the archives where we can search it, and so that others 
can contribute wisdom to the conversation.  (obviously sometimes private 
mail is required, but as the exception).

>I have reinstated the ROM_SEGMENT code, and the 2 data words just
>afterwards, conveniently before the ZLOADER code. I *believe* that I'm
>doing the right thing in properly allocating space, and so have NOT put
>the words in #ifdef PXELOADER/#endif. The assembler is happy, though it
>inflates the raw binary size a bit. Since we can now compress, I am not
>bothered.
>And - happy happy joy joy - I now get sensible numbers like
>(eepro100) ROM segment 0x07C0 length 0x3000 reloc 0x9400
>(3c90x)    ROM segment 0x07C0 length 0x5000 reloc 0x9400
>and ZLOADER is OK, once I fixed makerom to round UP the sizes.

Yes!  And this might also explain a problem I was having with LOADLIN.  
Each bit of knowledge added helps.

>The *correct* thing to do here, is - I believe - to stop using the 506
>offset unless we really and truly ARE providing floppyness to the
>outside world, and shove the data words just after the 3rd byte. This
>entails tweaking other code, however, and I do not claim to understand
>what is going on.

I will look at this.  As you've noticed there are so many interconnected 
parts and constraints with Etherboot that one must be careful in changing 
one part (especially low-level parts) without considering the 
ramifications to other parts.  The win is that since we all have the 
code, we can help each other and enlist the help of others when we get 
stuck.

>So - here's the new improved pxeloader, Makefile which now builds it
>with -DPXELOADER, and makerom which rounds up the size properly. The
>number of patch sections in pxeloader.S is now down to 4 PXE related and
>one for the ROM_SEGMENT; it should now be easy to retire pxeloader.S and
>merge back into loader.S. Patch relative to 5.0.2.
>Enjoy.

Excellent!  And I owe you and Vasil a beverage when we meet :-)

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] Bugfixed PXE

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

OK, I found the magic numbers. :)

Had this just been affecting the ZLOADER, I would probably have left it,
but I was getting weird hangs and crashes on our Supermicro boxes with
Intel chips, even without ZLOADER, and I really have to get those going.

Well, turns out that main.c uses the rom_info structure, BUT there are
no obvious cues that rom_info in main.c and ROM_SEGMENT in loader.S are
the same place. Just some absolute values - one in hex and the other in
decimal - and different names (c.f. _start, used in both - but which
really *is* different).

Vasil's original patch did actually allocate some space at the end of
pxeloader.S for ROM_SEGMENT, but this broke when using ZLOADER, so I
ifdef'd out the ROM_SEGMENT / ROM_LENGTH code, as it seemed to have no
useful function, and we're not using a floppy, right? I was also worried
by the fact that something was obviously being poked into somewhere I
didn't understand.

So my fault for removing code without understanding the implications.
BUT Etherboot didn't make it easy for me; this needs to be cleaned up
and documented by someone who genuinely understands which way is up. It
took me a *long* time to work out what was happening. Where *should*
ROM_SEGMENT really be? Has Etherboot been poking into some random space
and just been lucky until now?

I have reinstated the ROM_SEGMENT code, and the 2 data words just
afterwards, conveniently before the ZLOADER code. I *believe* that I'm
doing the right thing in properly allocating space, and so have NOT put
the words in #ifdef PXELOADER/#endif. The assembler is happy, though it
inflates the raw binary size a bit. Since we can now compress, I am not
bothered.

And - happy happy joy joy - I now get sensible numbers like

(eepro100) ROM segment 0x07C0 length 0x3000 reloc 0x9400
(3c90x)    ROM segment 0x07C0 length 0x5000 reloc 0x9400

and ZLOADER is OK, once I fixed makerom to round UP the sizes.

The *correct* thing to do here, is - I believe - to stop using the 506
offset unless we really and truly ARE providing floppyness to the
outside world, and shove the data words just after the 3rd byte. This
entails tweaking other code, however, and I do not claim to understand
what is going on.

So - here's the new improved pxeloader, Makefile which now builds it
with -DPXELOADER, and makerom which rounds up the size properly. The
number of patch sections in pxeloader.S is now down to 4 PXE related and
one for the ROM_SEGMENT; it should now be easy to retire pxeloader.S and
merge back into loader.S. Patch relative to 5.0.2.
Enjoy.

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

Re: [Etherboot-developers] Does anyone have code to pass arguments via .com version?

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

>It doesn't look like the code supports passing parameters via a com file.
>I'd like to override a DHCP parameter via a command option to the DHCP
>server or change the identifier.  Worst case is that I could build a 
>special version of Etherboot but I was hoping someone new more about
>dos stuff then I do and maybe already done this.

Com files are the neglected children in the Etherboot family because DOS
sometimes hinders com files from working.

If you don't really need to boot DOS first, you just want to launch
Etherboot from a DOS partition and be able to dual boot DOS/Windows...

I was chatting with Marty the other night and we thought that there
should be a good chance LILO can be made to work on a DOS partition.
LILO doesn't really care what filesystem your boot files are stored on.
it just stores the block numbers of the boot files. Here's how one would
proceed:

Make a .lilo Etherboot image.

Extract the LILO support files in a DOS partition, i.e. the stuff in
/boot and /etc/lilo.conf. Put the Etherboot .lilo image in /boot. Edit
/etc/lilo.conf with entries for DOS and Etherboot.

Boot a Linux rescue disk with LILO, e.g. tomsbtrt (www.toms.net).

Mount the DOS partition. Say it's mounted on /mnt/dos

Run lilo -r /mnt/dos

LILO should find /etc/lilo.con and install boot entries for DOS and
Etherboot.

[Etherboot-developers] Does anyone have code to pass arguments via .com version?

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

It doesn't look like the code supports passing parameters via a com file.
I'd like to override a DHCP parameter via a command option to the DHCP
server or change the identifier.  Worst case is that I could build a 
special version of Etherboot but I was hoping someone new more about
dos stuff then I do and maybe already done this.

Thanks,

Doug A.

[Etherboot-developers] 3c905c-tx-m weirdness

[David C. <da...@co...>]

So, I've been working on getting a functioning Etherboot ROM for the 3Com
3c905C-TX-M that would allow me to load a menu & then choose an image to
boot from there.  My last issue had been that I had a working ghost
multicast image that would work from floppy, however, after using
mknbi-dos on the floppy image & having Etherboot download the image,
netbind would fail to find the network card.  After posting to the list,
Marty Connor (who has been a great help through my endeavors, along with
the rest of the Etherboot community) suggested that I add a call to
a3c90x_reset(NULL) within the call to a3c90x_disable().  Unfortunately
this did not help my problem.  However, the interesting thing that I
wanted to share with the community is that commenting out everything
within the a3c90x_disable() function call allowed the ghost image to
detect the card & boot properly (I also set the compile flag
-DCFG_3C90X_PRESERVE_XCVR). I really have no idea why this worked,
and the solution still needs to undergo further testing (particularly with
other images than the ghost multicast, such as a linux rescue disk image).
But I wanted to share these results, in case anyone out there was facing a
similar issue & so that some of the developers of Etherboot with more
experience with the code than I could possibly look into this issue & see
what the truly appropriate (& working) thing to have the disable function
do would be.  Again, I would just like to thank the Etherboot community
for all of their help & I'm sure that I will have many more questions as I
continue to develop a production environment which will receive the same
courteous help from the Etherboot community.


Thanks again,

David Coulthart
da...@co...

[Etherboot-developers] Postcard from Texas

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

My wife and I had a nice long weekend in Arlington Texas, and are now 
heading back to Cambridge, Massachusetts.

It was actually very relaxing to be away, and the quiet early mornings 
proved ideal for some hacking and cleanup work on Etherboot and updating 
rom-o-matic.net. I'm refreshed and excited to get back, and look forward 
to some of the projects we have in the queue.

Etherboot is growing like a tree, with interesting new leaves and 
branches.  It's quite delightful to see all the new ways people are 
utilizing the technology.  I think the PXE stuff is great because it 
allows people who might now have been able to try Etherboot easily to 
load it using built-in BIOS or (in the case of eepro100/3C905c-TXM or 
eepro100 cards) built-in flash ROM.  I hope we can soon figure out how to 
also make .lzpxe images work for more options.

I'm already thinking of ways to improve on the January LinuxWorld Expo 
(report at http://www.thinguin.org/linuxworldny2001/).  Any ideas, 
suggestions, or offers of assistance are welcome.  It will be nice to 
finally meet Ken and Markus :-)

Anyway, it's nice to be associated with a project that people seem to 
find useful, and it's fun to work with motivated, creative and talented 
people.

"Tanned, rested, and ready, Etherboot 2001!!"

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] Errors detected while attempting to build eb501, and eb502 script files attached

[Gregg C L. <dr...@at...>]

Hello from Gregg C Levine normally with Jedi knight Computers
I just tried to build two versions of etherboot. The versions were
5.0.1, and 5.0.2 . Both failed with multiple errors. Rather then
reproduce them here, I have attached two script files, with the
activties reproduced within. My system is running Slackware 7.2, with
binutils 2.11 and gcc 2.9.5.2 . Prior to these versions, I have had no
problems with building version 5.0.0 of etherboot, or even a 4.6.x
version of it. The output from 5.0.2 reccomended reporting the error.
The output from 5.0.1 did not, but I am doing so, anyway. Please take
the time to review, and then get back to me. List based, rather then
direct is accepted.
Gregg C Levine dr...@at...
"You came in that thing?"

[Etherboot-developers] patch to 5.0.2

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

This one only affects people who want to generate .pxe images. .pxe
Etherboot images can be netbooted from a PXE bootrom, allowing you to
chain from PXE to Etherboot. This can be useful if don't want to replace
the PXE ROM with an Etherboot ROM and you don't want to set up PXE boot
infrastructure or want just one set of LTSP images.

Marty Connor drew my attention to the fact that the Makefile rules don't
quite work for .pxe images. It's a deficiency in genrules.pl. Applying
the patch below will fix it. But Marty also tells me that
rom-o-matic.net now has the patched 5.0.2 distribution so you can get
your images from there instead of compiling Etherboot.

--- ../../etherboot-5.0.2/src/genrules.pl	Mon Apr 23 23:51:53 2001
+++ ./genrules.pl	Mon Jun 25 00:16:36 2001
@@ -141,6 +141,14 @@
 	cat \$(PRZLOADER) \$< > \$@
 	bin/makerom \$(MAKEROM_\$*) -p $ids -i\$(IDENT32) \$@
 
+bin32/$rom.pxe:	bin32/$drv.img \$(PXELOADER)
+	cat \$(PXELOADER) \$< > \$@
+	bin/makerom -x \$(MAKEROM_\$*) -p $ids -i\$(IDENT32) \$@
+
+bin32/$rom.lzpxe:	bin32/$drv.huf \$(PXEZLOADER)
+	cat \$(PXEZLOADER) \$< > \$@
+	bin/makerom -x \$(MAKEROM_\$*) -p $ids -i\$(IDENT32) \$@
+
 EOF
 }
 foreach $rom (sort keys %roms_isa) {
@@ -149,6 +157,10 @@
 bin32/$rom.rom:	bin32/$rom.img \$(RLOADER)
 
 bin32/$rom.lzrom:	bin32/$rom.huf \$(RZLOADER)
+
+bin32/$rom.pxe:	bin32/$rom.img \$(PXELOADER)
+
+bin32/$rom.lzpxe:	bin32/$rom.huf \$(PXEZLOADER)
 
 EOF
 }

[Etherboot-developers] Etherboot 5.0.2 (production) released

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

I have released Etherboot 5.0.2 (sources and documentation) at
http://etherboot.sourceforge.net/distribution.html

Changes from 5.1.0 (development) are:

+ All the changes from 5.1.0 carried over except calling eth_reset()
from cleanup().

+ Marty Connor, funded by Sicom System (http://www.sicompos.com/), wrote
a driver for NICs based on the National Semiconductor DP83815, e.g.
Netgear FA311/FA312. Also independently created by Jason McMullan just
at the time Marty released his driver. Thanks for the effort Jason;
great minds think alike. Both are based on Donald Becker's Linux driver,
of course.

+ Doug Ambrisko contributed a patch to take environment bindings for
FreeBSD kernels from a BOOTP/DHCP option or config variable.

+ Dax Kelson contributed an example of an ISC DHCP config file that uses
Vendor Class Identifier to tailor the response to Etherboot clients.
Also discovered that the Etherboot VCI should also be sent in the
DHCPREQUEST message, in addition to the DHCPDISCOVER message.  Note that
the DHCP server must be set to non authorititative if you have an
authoritative server running already or it will interfere with that
one's operation.

+ Peter Lister and Vasil Vasilev contributed changes to generate .pxe
images bootable via PXE.

+ Eric Biederman added code to 3c90x.c to enable the NIC: set up
busmastering and set the latency timer in case the NIC is not already
set correctly, and fixed a couple of related bugs in eepro100.c.
Verified that the 3c90x driver works for the 3c980.

+ Moved strncmp from osdep.h to linux-asm-string.h. Use the general
version using string ops, not the deprecated 486 version (what was I
thinking).  Also added strlen, needed for FreeBSD patch above.

+ Thanks to gcc 3.0, found and corrected a couple of C constructs of
undefined semantics in rtl8139.c and lance.c of the form: i = ++i &
MASK;

+ In Config/CFLAGS32: changed -m386 to prefered form, -mcpu=i386,
changed -O2 to -Os, and added -ffreestanding. These changes allow
warning-free compilation under gcc 3.0. Only mimimal testing has been
done with gcc 3.0 compiled binaries, we hope there are no problems but
don't throw away your gcc 2.9.5 yet.

+ Added an .org 0 to loader.S just before _start. May or may not fix
alleged assembly problem with gas 2.11.

+ Cosmetic change: in boot1a.s replaced "loaded" with "done\r\n" so that
Etherboot messages start at beginning of line.

+ More improvements to contrib/mkffwnb.

MD5 sums:

4bf2fb8c1c48bbae18f1fa2300ac626b  etherboot-5.0.2.tar.bz2
5b8fa4fc91544f39a5e13ac8b50377db  etherboot-5.0.2.tar.gz
c1dd7936297c7400d657388bbe95f769  patch-5.0.2.gz
7ce7401291da0863e179deefc9dc5a35  etherboot-doc-5.0.2.tar.bz2
74a551283723be7de1c1ab4e9660a6a4  etherboot-doc-5.0.2.tar.gz

Re: [Etherboot-developers] main.c:cleanup()

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

On 6/22/2001 11:43 PM ke...@us... 
ke...@us... wrote:
>I've found that it's not safe to call eth_reset after eth_disable in
>cleanup(). On my 3c509 it hangs the program. So I have removed it from
>5.0.2. This probably means 5.1.0 wasn't much tested.

I agree with this.  Depending on the card, this may work or not.

>Part of the problem is that the semantics of eth_probe, eth_reset and
>eth_disable have never been rigorously defined. Informally I took it to
>be:
>eth_probe:	Finds the card

In eth_probe, most cards assume the card has been found by the core 
Etherboot routines, and do some initializations and checking, including:

- Putting the MAC address in *nic_node_addr [I think this should be in 
reset()]
- setting the addresses of the other driver routines
- calling eth_reset to prepare the card to send and receive packets

I'm not really sure if the etherboot core calls eth_reset before actually 
trying to send and receive packets;  If it does, we could probably not 
call it in eth_reset since it is probably being called redundantly in 
some cases.

>eth_reset:	Resets the card to a known state

Most drivers in this routine:

- do a hard/soft reset of the card
- setup TX and RX rings
- tell the card where the TX and RX rings are
- select proper media interface
- check duplex

Here's the sis900 eth-reset routine:

sis900_init(struct nic *nic)
{
    /* Soft reset the chip. */
    sis900_reset(nic);

    sis900_init_rxfilter(nic);

    sis900_init_txd(nic);
    sis900_init_rxd(nic);

    sis900_set_rx_mode(nic);

    sis900_check_mode(nic);

    outl(RxENA, ioaddr + cr);
}

in eepro100.c the eth_reset routine is:

static void eepro100_reset(struct nic *nic)
{
  outl(0, ioaddr + SCBPort);
}

This is probably inadequate for a lot of cases where one would call 
eth_reset, and a lot of what is in the eepro100 eth_probe() routine 
should be moved to the reset routine.  We are depending on a lot of 
things not changing by using such a simple reset routine.

I've taken to creating a routine called eth_init() in drivers because the 
word "reset" is a little overloaded.  Most cards have specific semantics 
about simply being reset, whereas Etherboot expects a lot of stateful 
initializations to be done.

One of those rainy-day projects I have is to go through all the drivers 
and make them more semantically consistent in this area.  Of course, 
great care must be taken in such endeavors, and I normally don't alter 
drivers unless there is a problem.

>		can be called in last part of eth_probe

I'd like to make this "must be called".

This would make it the driver's responsibility to get the card in the 
proper state.
I tend to think "probe" routines should do as little as possible, since 
they will likely only get called once by the core.

>Normal operation:
>		eth_reset can be called as often as wished

This seems fine.  Putting the card in a state where it can send and 
receive packets may require resetting some global driver state (RX 
pointers, counters, etc.) as well as some card state (resetting registers 
to point to driver globals).

>eth_disable:	Disables the card
>		Only eth_probe can be called thereafter

Hmmm, I think some drivers assume that disable just disables TX and RX.  
I think of the sematics as being "put the card in such a state that 
another driver can safely start and manipulate the card".  I tend to stop 
RX and TX, disable interrupts and DMA, and issue a hard reset to the 
card.  Since DMA could have been happening, it's important to make sure 
the card engine is not writing to memory after Etherboot stops because it 
could corrupt memory in unexpected and hard to debug ways.

>I feel that if eth_disable is felt to be inadequate for cleanup, then it
>should be enhanced, rather than calling eth_reset from cleanup.

I agree.

>Another possibility is for cleanup() to call eth_reset first, then
>eth_disable. I would be willing to introduce this in 5.1.1 but I feel
>5.0.2 should not risk breaking things for the majority of users.
>Comments?

This would probably work in the majority of cases.  This will motivate me 
to go through all the drivers and attempt to have consistent semantics 
for the five basic routines (probe, reset, transmit, poll, disable).

Partially this depends on what the Etherboot core expects.  Is reset() 
always called after probe() ?   If disable() is called, are both probe() 
and reset() called before any other driver routines?  If only probe() is 
called, then I'd say we have to insist that people call reset() at the 
end of probe().  

So I guess I'm in favor of very simple probe() routines, since reset() is 
more likely to get called to reinitialize the card and driver state.  
probe() seems like it should only do PCI bus related stuff, set some 
globals (including the addresses of the other routines), and call 
reset().  Anything that the card or driver could change during normal 
operation should be done in reset(). 

Anyway, that's my initial thinking on this.  I welcome other opinions.

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.0.2 out Real Soon Now

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

The tarballs have been written and I'm waiting for the servers at
Sourceforge to come up. This is to let you busy developers know that any
submitted patches from now on (and some that have been held over) will
go into the next version, either 5.1.1 or 5.0.3.

[Etherboot-developers] main.c:cleanup()

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

Hi,

I've found that it's not safe to call eth_reset after eth_disable in
cleanup(). On my 3c509 it hangs the program. So I have removed it from
5.0.2. This probably means 5.1.0 wasn't much tested.

Part of the problem is that the semantics of eth_probe, eth_reset and
eth_disable have never been rigorously defined. Informally I took it to
be:

eth_probe:	Finds the card
eth_reset:	Resets the card to a known state
		can be called in last part of eth_probe
Normal operation:
		eth_reset can be called as often as wished
eth_disable:	Disables the card
		Only eth_probe can be called thereafter

I feel that if eth_disable is felt to be inadequate for cleanup, then it
should be enhanced, rather than calling eth_reset from cleanup.

Another possibility is for cleanup() to call eth_reset first, then
eth_disable. I would be willing to introduce this in 5.1.1 but I feel
5.0.2 should not risk breaking things for the majority of users.

Comments?

Re: [Etherboot-developers] Re: Success with reusing etherboot whole in linuxBIOS.

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

Ollie Lho <ol...@si...> writes:

> "Eric W. Biederman" wrote:
> > 
> > Marty Connor <md...@th...> writes:
> > 
> > > On 6/21/2001 4:10 AM Eric W. Biederman ebi...@ln... wrote:
> > >
> > > >ebi...@ln... (Eric W. Biederman) writes:
> > > >> Anyway I'll see if I can get a good patch out in the next couple of
> > > >> days.
> > >
> > > >Make that hours.
> > > >Here is my preliminar patch.
> > >
> > > This is great news!  I can't keep up with all the good news lately in
> > > fact.  I hope you can make it to LinuxWorld Expo in San Francisco.  There
> > > will be an Etherboot booth again, and we will be able to show off some of
> > > the new technology. Ken is going to be there, and Markus and who knows
> > > who else.  I hope lots of people stop by to say hello and have fun.
> > 
> > I haven't a clue.  I haven't made any plans yet.  If you want a motherboard
> > for playing with linuxBIOS I'd recommend one based on either the SiS630 or
> > the SiS730 chipset.  The chipsets are well supported in linuxBIOS
> > currently, and motherboard based on them should be relatively
> > inexpensive.
> > 
> 
> Eric,
> 	Does your code works on SiS630/730 with the internal SiS900
> LAN ?? Can you give me a little description how can I reproduce
> it here. I am still reading those Diskless/Netboot/Etherboot HOWTOs.
> Sorry, the last time I played with remote boot was on Sun SPARC and 
> IBM RS6000 workstations 6 years ago back in the university.

O.k. 
The code I added simply allows etherboot to work under linuxbios.
It compiles into an ELF image, that I can boot with the elfboot.c
So etherboot should be as simple to use as a linux kernel.

There is SiS900 code in etherboot.  I haven't tested it, I don't have
the hardware, but it should work.

If you compile in multiboot support into  etherboot right now,
you can use my mkelfImage code in the linuxBIOS cvs tree to create
a bootable kernel image.  mknbi might work but I haven't tested it,
and I think it still keeps some bios calls around, which is a show
stopper.

Basically the setup is a dhcp server that gives a node an ip address,
and a file name to download and boot.  Plus a tftp server that serves
a file over the network.  It takes a little work to setup but it
isn't to hard.  The only tricky piece is at the moment it really helps
to have the network booting machine on a seperate subnet from the
company network, otherwise you get clash of the dual dhcp servers.

Eric

Re: [Etherboot-developers] Re: Success with reusing etherboot whole in linuxBIOS.

[Ollie L. <ol...@si...>]

"Eric W. Biederman" wrote:
> 
> Marty Connor <md...@th...> writes:
> 
> > On 6/21/2001 4:10 AM Eric W. Biederman ebi...@ln... wrote:
> >
> > >ebi...@ln... (Eric W. Biederman) writes:
> > >> Anyway I'll see if I can get a good patch out in the next couple of
> > >> days.
> >
> > >Make that hours.
> > >Here is my preliminar patch.
> >
> > This is great news!  I can't keep up with all the good news lately in
> > fact.  I hope you can make it to LinuxWorld Expo in San Francisco.  There
> > will be an Etherboot booth again, and we will be able to show off some of
> > the new technology. Ken is going to be there, and Markus and who knows
> > who else.  I hope lots of people stop by to say hello and have fun.
> 
> I haven't a clue.  I haven't made any plans yet.  If you want a motherboard
> for playing with linuxBIOS I'd recommend one based on either the SiS630 or
> the SiS730 chipset.  The chipsets are well supported in linuxBIOS
> currently, and motherboard based on them should be relatively
> inexpensive.
> 

Eric,
	Does your code works on SiS630/730 with the internal SiS900
LAN ?? Can you give me a little description how can I reproduce
it here. I am still reading those Diskless/Netboot/Etherboot HOWTOs.
Sorry, the last time I played with remote boot was on Sun SPARC and 
IBM RS6000 workstations 6 years ago back in the university.

Ollie

Re: [Etherboot-developers] Re: Success with reusing etherboot whole in linuxBIOS.

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

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

> On 6/21/2001 4:10 AM Eric W. Biederman ebi...@ln... wrote:
> 
> >ebi...@ln... (Eric W. Biederman) writes:
> >> Anyway I'll see if I can get a good patch out in the next couple of
> >> days.
> 
> >Make that hours.
> >Here is my preliminar patch.
> 
> This is great news!  I can't keep up with all the good news lately in 
> fact.  I hope you can make it to LinuxWorld Expo in San Francisco.  There 
> will be an Etherboot booth again, and we will be able to show off some of 
> the new technology. Ken is going to be there, and Markus and who knows 
> who else.  I hope lots of people stop by to say hello and have fun.

I haven't a clue.  I haven't made any plans yet.  If you want a motherboard
for playing with linuxBIOS I'd recommend one based on either the SiS630 or
the SiS730 chipset.  The chipsets are well supported in linuxBIOS
currently, and motherboard based on them should be relatively
inexpensive. 

I'm currently working with the AMD760MP chipset but it will be a
little while until the linuxBIOS support is solid. 
 
> I'll be interested to know what sort of machine and motherboard I should 
> get to do an effective demo.  I don't know if you already got the 3Com 
> Etherboot driver you needed, but let me know and I'll see what I can do.  
> If I can find a card, I can probably do something useful.

I haven't yet.  My concern was getting something clean and running.
I have an eepro100 plug into the mainboard, and am using that instead
of the onboard 3COM nic at the moment.
 
> So now Etherboot can run from floppy, ROM, LILO, SYSLINUX, PXE ROMs, DOS, 
> and some BIOSes. Yow! I guess it's about time to update rom-o-matic.net 
> again :-)

Tell me how it goes, putting my code into the normal build tree.
There were some minor rough edges left out.

Eric

Re: [Etherboot-developers] Re: Success with reusing etherboot whole in linuxBIOS.

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

On 6/21/2001 4:10 AM Eric W. Biederman ebi...@ln... wrote:

>ebi...@ln... (Eric W. Biederman) writes:
>> Anyway I'll see if I can get a good patch out in the next couple of
>> days.

>Make that hours.
>Here is my preliminar patch.

This is great news!  I can't keep up with all the good news lately in 
fact.  I hope you can make it to LinuxWorld Expo in San Francisco.  There 
will be an Etherboot booth again, and we will be able to show off some of 
the new technology. Ken is going to be there, and Markus and who knows 
who else.  I hope lots of people stop by to say hello and have fun.

I'll be interested to know what sort of machine and motherboard I should 
get to do an effective demo.  I don't know if you already got the 3Com 
Etherboot driver you needed, but let me know and I'll see what I can do.  
If I can find a card, I can probably do something useful.

So now Etherboot can run from floppy, ROM, LILO, SYSLINUX, PXE ROMs, DOS, 
and some BIOSes. Yow! I guess it's about time to update rom-o-matic.net 
again :-)

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: Success with reusing etherboot whole in linuxBIOS.

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

"Hamish Guthrie \(Mail Lists\)" <ha...@dp...> writes:

> Eric and Developers,
> 
> I am very pleased to hear about this joint effort - I think it is great.
> 
> I have been looking at doing an implementation but I have a problem - the
> CPU core of my target device is a 486, and I do not have the TSC, and other
> than a nasty loop hack, I guess the only way of catering for timeouts is
> using the PIT.

Sound right.  If that is the only timer you have.
 
> I have looked at the Etherboot code and the tick implementation is done by
> flipping back into real mode to allow the PIC to service PIT interrupts
> utilsing BIOS routines, and then flipping back to PMODE.Obviously in
> LinuxBIOS we get into PMODE as soon as possible and it makes a lot of sense
> for us to stay there. The issue now is to set up a good IDT and create a
> PMODE interrupt routine for the timer.
> 
> I have broken 3 walls with my head bashing in trying to do this!
> 
> Any suggestions?

Check out memtest86.  I don't know if it does an especially good job
but does setup an interrupt descriptor table, and the code is pretty
straight forward. 

The code to program the PIT from i8259.c is:
	/*
	 * Set the clock to HZ Hz, we already have a valid
	 * vector now:
	 */
	outb_p(0x34,0x43);		/* binary, mode 2, LSB/MSB, ch 0 */
	outb_p(LATCH & 0xff , 0x40);	/* LSB */
	outb(LATCH >> 8 , 0x40);	/* MSB */

Though I think this is short an enable.

Eric

[Etherboot-developers] RE: Success with reusing etherboot whole in linuxBIOS.

[Hamish G. \(M. Lists\) <ha...@dp...>]

Eric and Developers,

I am very pleased to hear about this joint effort - I think it is great.

I have been looking at doing an implementation but I have a problem - the
CPU core of my target device is a 486, and I do not have the TSC, and other
than a nasty loop hack, I guess the only way of catering for timeouts is
using the PIT.

I have looked at the Etherboot code and the tick implementation is done by
flipping back into real mode to allow the PIC to service PIT interrupts
utilsing BIOS routines, and then flipping back to PMODE.Obviously in
LinuxBIOS we get into PMODE as soon as possible and it makes a lot of sense
for us to stay there. The issue now is to set up a good IDT and create a
PMODE interrupt routine for the timer.

I have broken 3 walls with my head bashing in trying to do this!

Any suggestions?

TIA

Regards

Hamish

[Etherboot-developers] Re: Success with reusing etherboot whole in linuxBIOS.

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

ebi...@ln... (Eric W. Biederman) writes:

> Anyway I'll see if I can get a good patch out in the next couple of
> days.
Make that hours.

Here is my preliminar patch.
The code present in it is good, but it still doesn't integrate into
Etherboot quite right.  In particular it refuses to build if you give
it options it doesn't support when running under linuxBIOS.  It
probably just needs a different make target or the like.

The code is archived at:
ftp://download.linuxnetworx.com/pub/src/etherboot

The patch is against etherboot-5.1.0

Eric

diff -uNr --exclude=Roms etherboot-5.1.0/src/Config etherboot-5.1.0.eb1/src/Config
--- etherboot-5.1.0/src/Config	Sun May  6 23:55:54 2001
+++ etherboot-5.1.0.eb1/src/Config	Thu Jun 21 00:54:57 2001
@@ -170,6 +170,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:
 #
@@ -219,11 +224,14 @@
 
 # Enable tagged image, generic ELF, Multiboot ELF
 # or FreeBSD ELF/a.out boot image support
-CFLAGS32+=	-DTAGGED_IMAGE -DELF_IMAGE
+#CFLAGS32+=	-DTAGGED_IMAGE -DELF_IMAGE
 # CFLAGS32+=	-DAOUT_IMAGE -DIMAGE_MULTIBOOT -DIMAGE_FREEBSD
 
 # 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 --exclude=Roms etherboot-5.1.0/src/Makefile etherboot-5.1.0.eb1/src/Makefile
--- etherboot-5.1.0/src/Makefile	Sat May 26 17:45:39 2001
+++ etherboot-5.1.0.eb1/src/Makefile	Thu Jun 21 01:53:22 2001
@@ -84,11 +84,12 @@
 
 GCC=		gcc
 CPP=		gcc -E
+STRIP=		strip
 OBJCOPY=	objcopy
 VERSION_MAJOR=	5
 VERSION_MINOR=	1
 VERSION_PATCH=	0
-VERSION=	$(VERSION_MAJOR).$(VERSION_MINOR).$(VERSION_PATCH)
+VERSION=	$(VERSION_MAJOR).$(VERSION_MINOR).$(VERSION_PATCH).eb1
 CFLAGS32+=	-DVERSION_MAJOR=$(VERSION_MAJOR) \
 		-DVERSION_MINOR=$(VERSION_MINOR) \
 		-DVERSION=\"$(VERSION)\" -DRELOC=$(RELOCADDR) $(OLDGAS)
@@ -152,6 +153,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
@@ -160,6 +162,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) ] &&\
@@ -366,6 +369,7 @@
 	$(RM) bin32/*.com
 	$(RM) bin32/*.dsk bin32/*.lzdsk
 	$(RM) bin32/*.lilo bin32/*.lzlilo
+	$(RM) bin32/*.elf bin32/*.ebi
 
 tarball:
 	(echo -n $(VERSION) ''; date -u +'%Y-%m-%d') > ../VERSION
diff -uNr --exclude=Roms etherboot-5.1.0/src/etherboot.h etherboot-5.1.0.eb1/src/etherboot.h
--- etherboot-5.1.0/src/etherboot.h	Sat May 26 17:47:14 2001
+++ etherboot-5.1.0.eb1/src/etherboot.h	Thu Jun 21 00:45:53 2001
@@ -531,6 +531,10 @@
 extern void xend P((void));
 #endif
 extern unsigned long currticks P((void));
+#if !defined(CONFIG_TSC_CURRTICKS)
+extern unsigned long __currticks P((void));
+#define currticks __currticks
+#endif /* RTC_CURRTICKS */
 extern int setjmp P((jmpbuf env));
 extern void longjmp P((jmpbuf env, int val));
 extern void exit P((int status));
diff -uNr --exclude=Roms etherboot-5.1.0/src/genrules.pl etherboot-5.1.0.eb1/src/genrules.pl
--- etherboot-5.1.0/src/genrules.pl	Mon Apr 23 07:51:53 2001
+++ etherboot-5.1.0.eb1/src/genrules.pl	Thu Jun 21 00:00:08 2001
@@ -89,7 +89,7 @@
 	}
 }
 foreach $key (sort keys %roms_pci) {
-	print "BINS32\t+= bin32/$key.rom bin32/$key.lzrom\n";
+	print "BINS32\t+= bin32/$key.rom bin32/$key.lzrom bin32/$key.ebi\n";
 }
 foreach $key (sort keys %roms_isa) {
 	print "BINS32\t+= bin32/$key.rom bin32/$key.lzrom\n";
@@ -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 --exclude=Roms etherboot-5.1.0/src/start32.S etherboot-5.1.0.eb1/src/start32.S
--- etherboot-5.1.0/src/start32.S	Thu Mar  8 04:51:42 2001
+++ etherboot-5.1.0.eb1/src/start32.S	Thu Jun 21 00:05:09 2001
@@ -118,8 +118,8 @@
 today) and byte 0040:0070 (midnight crossover flag) instead of calling
 timeofday BIOS interrupt.
 **************************************************************************/
-	.globl	currticks
-currticks:
+	.globl	__currticks
+__currticks:
 	pushl	%ebp
 	pushl	%ebx
 	pushl	%esi
diff -uNr --exclude=Roms etherboot-5.1.0/src/timer.c etherboot-5.1.0.eb1/src/timer.c
--- etherboot-5.1.0/src/timer.c	Sun Dec 10 00:40:48 2000
+++ etherboot-5.1.0.eb1/src/timer.c	Thu Jun 21 00:43:58 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 --exclude=Roms etherboot-5.1.0/src/ube.c etherboot-5.1.0.eb1/src/ube.c
--- etherboot-5.1.0/src/ube.c	Wed Dec 31 17:00:00 1969
+++ etherboot-5.1.0.eb1/src/ube.c	Thu Jun 21 01:49:44 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 --exclude=Roms etherboot-5.1.0/src/ube_start32.S etherboot-5.1.0.eb1/src/ube_start32.S
--- etherboot-5.1.0/src/ube_start32.S	Wed Dec 31 17:00:00 1969
+++ etherboot-5.1.0.eb1/src/ube_start32.S	Thu Jun 21 01:18:17 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 --exclude=Roms etherboot-5.1.0/src/uniform_boot.h etherboot-5.1.0.eb1/src/uniform_boot.h
--- etherboot-5.1.0/src/uniform_boot.h	Wed Dec 31 17:00:00 1969
+++ etherboot-5.1.0.eb1/src/uniform_boot.h	Thu Jun 21 00:08:06 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 */

[Etherboot-developers] Success with reusing etherboot whole in linuxBIOS.

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

Just a quick status report.  After looking at the code that
preliminary patch to put ehterboot into linuxBIOS, I decided to check
to see how hard it would be to simply reuse therboot whole.

Making a valid ELF image from etherboot is simple.  One already
exists but it has a 16bit entry point.  So all I had to do was
write another version of start32.S

Quite a few of the routines in start32.S I simply removed because
I don't have any 16bit BIOS calls.  Of the rest only currticks was
a challenge.  I hacked up an implementation based on rdtsc, and the
linux fast_gettimeoffset code, which should work on everything better
than a 486.  The patch to linuxBIOS had an implementation which was
very specific to the SiS 630 chipsets, using an ACPI timer.

Sizewise linuxBIOS for the AMD762 chipset and etherboot for the
eepro100 fit into about 48k.  I'm not packing them into the rom that
tight currently because it is tricky to pack them.  But that is a
detail that should be easy to overcome.

Does anyone know what it would take to get etherboot up on the:
3Com PCI 3c980 Cyclone?
In linux I can just use the 3c59x driver?


Anyway I'll see if I can get a good patch out in the next couple of
days.  I did a number of silly things including starting with a very
hacked up version already (my patches to 5.01 ) and I hardcoded the
ram size.  Plus I tried to figure out what if getting the 3COM driver
up was as simple as adding it PCI id somewhere.  


Eric

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

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

Christoph Plattner <chr...@al...> writes:

> Hello !
> 
> AFAIK Linux-Bios is a small Linux kernel which is booted directly from
> the
> boot vector. Only a smart chipset setup is done, all other things are
> coming
> from this small linux kernel, as it can handle and drive all i/o
> components,
> as we know :-)
> 
> So this linux kernel also can handle network and bootp/dhcp requests,
> transporting files fia ftp/tftp and mounting NFS roots.
> 
> So I don't know, but possible there is not much up to nothing to do,
> to support netboot here.
> 
> But again, I don't know it very well, as up to now, I have no machine,
> which Linux Bios supports. If I would have one, I only would use Linux
> Bios !!!!

The problem is size of ROM.   As a small linux kernel weighs in at 360KB
getting it on your stock rom of 256KB is next to impossible.  With etherboot
or another minimal bootloader we can get around the small ROM size restriction
and support many more motherboards.

Eric