etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] [RFC] Loading Arbitrary images.

[Christopher Li <ch...@gn...>]

On 15 Jan 2002, Eric W. Biederman wrote:

> ke...@us... (Ken Yap) writes:
> 
> > >Recently I attacked and solved the problem in linuxBIOS where we
> > >were having problems loading ELF executables that wanted to
> > >live on top of our linuxBIOS code.
> > >
> > >Etherboot by default conflicts much less, but it still has this
> > >problem to some degree. 
> > >
> > >Would there be interest in implementing this for etherboot?
> > 
> > Go for it, would be interesting to see how it works out.
> 
> Ken does etherboot use anything besides statics variables and a stack?
As far as I know, No.

Chris

Re: [Etherboot-developers] [RFC] Loading Arbitrary images.

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

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

> >Recently I attacked and solved the problem in linuxBIOS where we
> >were having problems loading ELF executables that wanted to
> >live on top of our linuxBIOS code.
> >
> >Etherboot by default conflicts much less, but it still has this
> >problem to some degree. 
> >
> >Would there be interest in implementing this for etherboot?
> 
> Go for it, would be interesting to see how it works out.

Ken does etherboot use anything besides statics variables and a stack?

Eric

Re: [Etherboot-developers] [RFC] Loading Arbitrary images.

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

>Recently I attacked and solved the problem in linuxBIOS where we
>were having problems loading ELF executables that wanted to
>live on top of our linuxBIOS code.
>
>Etherboot by default conflicts much less, but it still has this
>problem to some degree. 
>
>Would there be interest in implementing this for etherboot?

Go for it, would be interesting to see how it works out.

[Etherboot-developers] [RFC] Loading Arbitrary images.

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

Recently I attacked and solved the problem in linuxBIOS where we
were having problems loading ELF executables that wanted to
live on top of our linuxBIOS code.

Etherboot by default conflicts much less, but it still has this
problem to some degree. 

Would there be interest in implementing this for etherboot?

The idea is to move the bootloader to the top of memory at the last
possible moment.  This would allow things like booting etherboot from
etherboot.

I could implement this but it would take me a while to ascertain what
memory areas etherboot really uses and how they all of that interact.

Anyway a description of my algorithm in linuxBIOS is below.

Eric


/* The problem:  
 * Static executables all want to share the same addresses
 * in memory because only a few addresses are reliably present on
 * a machine, and implementing general relocation is hard.
 *
 * The solution:
 * - Allocate a buffer twice the size of the linuxBIOS image.
 * - Anything that would overwrite linuxBIOS copy into the lower half of
 *   the buffer. 
 * - After loading an ELF image copy linuxBIOS to the upper half of the
 *   buffer.
 * - Then jump to the loaded image.
 * 
 * Benefits:
 * - Nearly arbitrary standalone executables can be loaded.
 * - LinuxBIOS is preserved, so it can be returned to.
 * - The implementation is still relatively simple,
 *   and much simpler then the general case implemented in kexec.
 * 
 */

Re: [Etherboot-developers] Some idea about etherboot

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

>1) how about add a gdb remote debug stub?
>...
>2) how about the configure script like linux kernel?
>etherboot itself is pretty much like a tiny kernel. Then make the
>configure option will be easier.

Sure, produce a plausible implementation, try it out, let others try it
out, and if it's an improvement, I'll accept it. Code speaks loudest.

[Etherboot-developers] Some idea about etherboot

[Christopher Li <ch...@gn...>]

Hi Ken,

While I am playing with the etherboot, I am thinking about 2 things:

1) how about add a gdb remote debug stub?

If we really want debug stub, there are two things need to take care.
That will need to enable hardware interrupt for serial port (Which
etherboot do not provide right now.) Assume we can have hardware
interrupt, the handler must in the protect mode. BTW etherboot
jump back and forth between real mode and protect mode. So I guess
we can check the serial port every time we return to protect mode.

The nice things if we have the remote debug stub, we can download the
program from serial port. Right now I have to reboot and switch
floopys.

Just an idea.

2) how about the configure script like linux kernel?
etherboot itself is pretty much like a tiny kernel. Then make the
configure option will be easier.

Chris


 

Re: [Etherboot-developers] [PATCH] linuxbios reorg...

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

>I have just done a major reorganization of linuxBIOS that for booting
>it was passing all of the BIOS information instead of putting it in a
>table.  Now LinuxBIOS just creates a table and you can scan for it.
>This is now much more robust.
>
>Now I don't need to use etherboot's multi-boot elf loader, and I can
>use the default one.

Great thanks, this looks much simpler and will go into the next release.
I should also put a link in the doco to your mkelfimage package.

[Etherboot-developers] [PATCH] linuxbios reorg...

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

I have just done a major reorganization of linuxBIOS that for booting
it was passing all of the BIOS information instead of putting it in a
table.  Now LinuxBIOS just creates a table and you can scan for it.
This is now much more robust.

Now I don't need to use etherboot's multi-boot elf loader, and I can
use the default one.

My new version of mkelfImage (that works with this) is at 
ftp://download.lnxi.com/pub/src/mkelfImage/mkelfImage-1.9.tar.gz

The big difference between mkelfImage and mknbi in this application
is that mkelfImage strips out and replaces all of the linux kernels
hardware probe code.  This is great for prototyping but probably
wrong for long term maintenance.  For that I need to update the linux
kernel.

Eric

diff -uNr --exclude=Config --exclude=Roms etherboot-5.0.5/src/Makefile etherboot-5.0.5.eb1/src/Makefile
--- etherboot-5.0.5/src/Makefile	Thu Dec 20 20:54:24 2001
+++ etherboot-5.0.5.eb1/src/Makefile	Fri Jan  4 12:19:37 2002
@@ -92,7 +92,7 @@
 VERSION_MAJOR=	5
 VERSION_MINOR=	0
 VERSION_PATCH=	5
-EXTRAVERSION=
+EXTRAVERSION=   eb1
 VERSION=	$(VERSION_MAJOR).$(VERSION_MINOR).$(VERSION_PATCH)$(EXTRAVERSION)
 CFLAGS32+=	-DVERSION_MAJOR=$(VERSION_MAJOR) \
 		-DVERSION_MINOR=$(VERSION_MINOR) \
@@ -160,7 +160,7 @@
 LILOPREFIX=	bin/liloprefix.bin
 
 START32=	bin32/start32.o bin32/memsizes.o
-UBE_START32=	bin32/ube_start32.o bin32/ube.o
+ELF_START32=	bin32/elf_start32.o bin32/linuxbios.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
@@ -169,7 +169,7 @@
 LIBS32=		$(BLIB32) $(LIBC32)
 UTILS+=		bin/makerom bin/lzhuf
 STDDEPS32=	$(START32) $(BLIB32) $(UTILS)
-UBE_DEPS32=	$(UBE_START32) $(BLIB32)
+ELF_DEPS32=	$(ELF_START32) $(BLIB32)
 # MAKEDEPS is the one target that is depended by all ROMs, so we check gcc here
 # If you are confident that gcc 2.96 works for you, you can delete gcccheck
 # from the next line
diff -uNr --exclude=Config --exclude=Roms etherboot-5.0.5/src/elf_start32.S etherboot-5.0.5.eb1/src/elf_start32.S
--- etherboot-5.0.5/src/elf_start32.S	Wed Dec 31 17:00:00 1969
+++ etherboot-5.0.5.eb1/src/elf_start32.S	Fri Jan  4 11:23:28 2002
@@ -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=Config --exclude=Roms etherboot-5.0.5/src/genrules.pl etherboot-5.0.5.eb1/src/genrules.pl
--- etherboot-5.0.5/src/genrules.pl	Fri Aug  3 07:33:45 2001
+++ etherboot-5.0.5.eb1/src/genrules.pl	Fri Jan  4 11:25:11 2002
@@ -178,8 +178,8 @@
 	\$(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)
+bin32/$key.elf:	bin32/$key.o bin32/config-$key.o bin32/pci.o \$(ELF_DEPS32)
+	\$(LD32) \$(LDFLAGS32) -o \$@ \$(ELF_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=Config --exclude=Roms etherboot-5.0.5/src/linuxbios.c etherboot-5.0.5.eb1/src/linuxbios.c
--- etherboot-5.0.5/src/linuxbios.c	Wed Dec 31 17:00:00 1969
+++ etherboot-5.0.5.eb1/src/linuxbios.c	Mon Jan  7 21:25:35 2002
@@ -0,0 +1,198 @@
+#include "etherboot.h"
+#include "linuxbios_tables.h"
+
+struct meminfo meminfo;
+
+#undef DEBUG_LINUXBIOS
+
+/* FIXME should I use ipchksum here instead? 
+ * It is the same algorithm, and reuse would save a few bytes... 
+ */
+static unsigned long compute_checksum(void *addr, unsigned long length)
+{
+	/* Assumes the start is 2 byte aligned.
+	 * This isn't exactly a problem on x86 but...
+	 */
+	unsigned short *ptr = addr;
+	unsigned long len;
+	unsigned long remainder;
+	unsigned long partial;
+	partial = 0;
+	len = length >> 1;
+	remainder = len & 1;
+	while(len--) {
+		partial += *(ptr++);
+		if (partial > 0xFFFF) 
+			partial -= 0xFFFF;
+	}
+	if (remainder) {
+		unsigned char *ptr2 = (void *)ptr;
+		partial += *ptr2;
+		if (partial > 0xFFFF)
+			partial -= 0xFFFF;
+	}
+	return (~partial) & 0xFFFF;
+}
+
+static void set_base_mem_k(struct meminfo *info, unsigned mem_k)
+{
+	if ((mem_k <= 640) && (info->basememsize <= mem_k)) {
+		info->basememsize = mem_k;
+	}
+}
+static void set_high_mem_k(struct meminfo *info, unsigned mem_k)
+{
+	/* Shave off a megabyte before playing */
+	if (mem_k < 1024) {
+		return;
+	}
+	mem_k -= 1024;
+	if (info->memsize <= mem_k) {
+		info->memsize = mem_k;
+	}
+}
+
+static void read_lb_memory(
+	struct meminfo *info, struct lb_memory *mem)
+{
+	int i;
+	int entries;
+	entries = (mem->size - sizeof(*mem))/sizeof(mem->map[0]);
+	for(i = 0; (i < entries); i++) {
+		if (info->map_count < E820MAX) {
+			info->map[info->map_count].addr = mem->map[i].start;
+			info->map[info->map_count].size = mem->map[i].size;
+			info->map[info->map_count].type = mem->map[i].type;
+			info->map_count++;
+		}
+		switch(mem->map[i].type) {
+		case LB_MEM_RAM:
+		{
+			unsigned long long high;
+			unsigned long mem_k;
+			high = mem->map[i].start + mem->map[i].size;
+#if defined(DEBUG_LINUXBIOS)
+			printf("lb: 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_LINUXBIOS */
+			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 LB_MEM_RESERVED:
+		default:
+			break;
+		}
+	}
+}
+
+
+static void read_linuxbios_values(struct meminfo *info,
+	struct lb_header *head)
+{
+	/* Read linuxbios tables... */
+	struct lb_record *rec;
+	void *start, *end;
+
+	start = ((unsigned char *)head) + sizeof(*head);
+	end = ((char *)start) + head->table_bytes;
+	for(rec = start; ((void *)rec < end) &&
+		((long)rec->size <= (end - (void *)rec)); 
+		rec = (void *)(((char *)rec) + rec->size)) {
+		switch(rec->tag) {
+		case LB_TAG_MEMORY:
+		{
+			struct lb_memory *mem;
+			mem = (struct lb_memory *) rec;
+			read_lb_memory(info, mem); 
+			break;
+		}
+		default: 
+			break;
+		};
+	}
+}
+
+
+
+static unsigned long count_lb_records(void *start, unsigned long length)
+{
+	struct lb_record *rec;
+	void *end;
+	unsigned long count;
+	count = 0;
+	end = ((char *)start) + length;
+	for(rec = start; ((void *)rec < end) &&
+		((signed long)rec->size <= (end - (void *)rec)); 
+		rec = (void *)(((char *)rec) + rec->size)) {
+		count++;
+	}
+	return count;
+}
+
+static int find_lb_table(void *start, void *end, struct lb_header **result)
+{
+	unsigned char *ptr;
+	/* For now be stupid.... */
+	for(ptr = start; (void *)ptr < end; ptr += 16) {
+		struct lb_header *head = (void *)ptr;
+		if (	(head->signature[0] == 'L') && 
+			(head->signature[1] == 'B') &&
+			(head->signature[2] == 'I') &&
+			(head->signature[3] == 'O') &&
+			(head->header_bytes == sizeof(*head)) &&
+			(compute_checksum(head, sizeof(*head)) == 0) &&
+			(compute_checksum(ptr + sizeof(*head), head->table_bytes) ==
+				head->table_checksum) &&
+			(count_lb_records(ptr + sizeof(*head), head->table_bytes) ==
+				head->table_entries)
+			) {
+			*result = head;
+			return 1;
+		}
+	};
+	return 0;
+}
+
+void get_memsizes(void)
+{
+	struct lb_header *lb_table;
+	int found;
+#if defined(DEBUG_LINUXBIOS)
+	printf("\nSearching for linuxbios tables...\n");
+#endif /* DEBUG_LINUXBIOS */
+	found = 0;
+	meminfo.basememsize = 0;
+	meminfo.memsize = 0;
+	meminfo.map_count = 0;
+	/* This code is specific to linuxBIOS but could
+	 * concievably be extended to work under a normal bios.
+	 * but size is important...
+	 */
+	if (!found) {
+		found = find_lb_table((void*)0x00000, (void*)0x01000, &lb_table);
+	}
+	if (!found) {
+		found = find_lb_table((void*)0xf0000, (void*)0x100000, &lb_table);
+	}
+	if (found) {
+		read_linuxbios_values(&meminfo, lb_table);
+	}
+
+#if defined(DEBUG_LINUXBIOS)
+	printf("base_mem_k = %d high_mem_k = %d\n", 
+		meminfo.basememsize, meminfo.memsize);
+#endif /* DEBUG_LINUXBIOS */
+	
+}
+
diff -uNr --exclude=Config --exclude=Roms etherboot-5.0.5/src/linuxbios_tables.h etherboot-5.0.5.eb1/src/linuxbios_tables.h
--- etherboot-5.0.5/src/linuxbios_tables.h	Wed Dec 31 17:00:00 1969
+++ etherboot-5.0.5.eb1/src/linuxbios_tables.h	Fri Jan  4 11:27:57 2002
@@ -0,0 +1,82 @@
+#ifndef LINUXBIOS_TABLES_H
+#define LINUXBIOS_TABLES_H
+
+#include <stdint.h>
+
+/* The linuxbios table information is for conveying information
+ * from the firmware to the loaded OS image.  Primarily this
+ * is expected to be information that cannot be discovered by
+ * other means, such as quering the hardware directly.
+ *
+ * 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.   For table that
+ * can reasonably be used on multiple architectures the data
+ * size should be fixed.  This should ease the transition between
+ * 32 bit and 64 bit architectures etc.
+ *
+ * The completeness test for the information in this table is:
+ * - Can all of the hardware be detected?
+ * - Are the per motherboard constants available?
+ * - Is there enough to allow a kernel to run that was written before
+ *   a particular motherboard is constructed? (Assuming the kernel
+ *   has drivers for all of the hardware but it does not have
+ *   assumptions on how the hardware is connected together).
+ *
+ * With this test it should be straight forward to determine if a
+ * table entry is required or not.  This should remove much of the
+ * long term compatibility burden as table entries which are
+ * irrelevant or have been replaced by better alternatives may be
+ * dropped.  Of course it is polite and expidite to include extra
+ * table entries and be backwards compatible, but it is not required.
+ */
+
+
+struct lb_header
+{
+	uint8_t  signature[4]; /* LBIO */
+	uint32_t header_bytes;
+	uint32_t header_checksum;
+	uint32_t table_bytes;
+	uint32_t table_checksum;
+	uint32_t table_entries;
+};
+
+/* 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 lb_record {
+	uint32_t tag;		/* tag ID */
+	uint32_t size;		/* size of record (in bytes) */
+};
+
+#define LB_TAG_UNUSED	0x0000
+
+#define LB_TAG_MEMORY	0x0001
+
+struct lb_memory_range {
+	uint64_t start;
+	uint64_t size;
+	uint32_t type;
+#define LB_MEM_RAM      1
+#define LB_MEM_RESERVED 2
+	
+};
+
+struct lb_memory {
+	uint32_t tag;
+	uint32_t size;
+	struct lb_memory_range map[0];
+};
+
+#define LB_TAG_HWRPB	0x0002
+struct lb_hwrpb {
+	uint32_t tag;
+	uint32_t size;
+	uint64_t hwrpb;
+};
+
+#endif /* LINUXBIOS_TABLES_H */
diff -uNr --exclude=Config --exclude=Roms etherboot-5.0.5/src/ube.c etherboot-5.0.5.eb1/src/ube.c
--- etherboot-5.0.5/src/ube.c	Thu Dec 20 16:16:35 2001
+++ etherboot-5.0.5.eb1/src/ube.c	Wed Dec 31 17:00:00 1969
@@ -1,153 +0,0 @@
-#include "etherboot.h"
-#include "uniform_boot.h"
-
-struct meminfo meminfo;
-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 meminfo *info, unsigned mem_k)
-{
-	if ((mem_k <= 640) && (info->basememsize <= mem_k)) {
-		info->basememsize = mem_k;
-	}
-}
-static void set_high_mem_k(struct meminfo *info, unsigned mem_k)
-{
-	/* Shave off a megabyte before playing */
-	if (mem_k < 1024) {
-		return;
-	}
-	mem_k -= 1024;
-	if (info->memsize <= mem_k) {
-		info->memsize = mem_k;
-	}
-}
-
-static void read_uniform_boot_memory(
-	struct meminfo *info, struct ube_memory *mem)
-{
-	int i;
-	int entries;
-	entries = (mem->size - sizeof(*mem))/sizeof(mem->map[0]);
-	for(i = 0; (i < entries); i++) {
-		if (info->map_count < E820MAX) {
-			info->map[info->map_count].addr = mem->map[i].start;
-			info->map[info->map_count].size = mem->map[i].size;
-			info->map[info->map_count].type = mem->map[i].type;
-			info->map_count++;
-		}
-		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 meminfo *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;
-	}
-}
-
-void get_memsizes(void)
-{
-	extern unsigned long initeax;
-	extern unsigned long initebx;
-	unsigned long type;
-	void *ptr;
-#if defined(DEBUG_UBE)
-	printf("\nReading bootinfo initeax = %X initebx = %X\n",
-		initeax, initebx);
-#endif /* DEBUG_UBE */
-	type = initeax;
-	ptr = (void *)initebx;
-	meminfo.basememsize = 0;
-	meminfo.memsize = 0;
-	meminfo.map_count = 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 */
-	
-}
-
diff -uNr --exclude=Config --exclude=Roms etherboot-5.0.5/src/ube_start32.S etherboot-5.0.5.eb1/src/ube_start32.S
--- etherboot-5.0.5/src/ube_start32.S	Sat Jul  7 19:24:28 2001
+++ etherboot-5.0.5.eb1/src/ube_start32.S	Wed Dec 31 17:00:00 1969
@@ -1,165 +0,0 @@
-/* #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:
-	

[Etherboot-developers] Etherboot Project going to LinuxWorld Expo NYC

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

Greetings Fans of Network Booting :)

It's getting to be LinuxWorld Expo time, 
(http://www.linuxworldexpo.com/), and we'll be exhibiting in a booth in 
New York City.  This will be our third consecutive show, and they've been 
a great opportunity to showcase Etherboot and network booting technology, 
as well as meet a lot of the folks who use Etherboot in all kinds of 
applications.

Here's a link to our report from last year's show:

   http://www.thinguin.org/linuxworldny2001/

The Show is Tuesday, January 29 to Friday February 2, 2002, at the Jacob 
Javitts Convention Center in New York City.  The exhibit hall is open 
Wednesday thru Friday from 10am to 6pm (4pm on Friday).

Markus Gutschke and I will be there, and we would love to see you there, 
and we could also use some volunteers to help in our booth.  Email me to 
let me know if you're interested in helping and what days you'll be 
available.

We also have a bunch of free "exhibits only" passes we'd be happy to send 
to anyone who wants one (whether you can help out or not).

Jim McQuillan and the good folks of http://LTSP.org will have a booth as 
well, and there will be lots of neat people and hardware around to mingle 
with.  These expos are always a great time.

So we look forward to LinuxWorld Expo, to seeing folks there, and to 
spreading the word about network booting, thin clients and how to save a 
whole lot of money :)

See you there!!

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] Merging linuxbios support....

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

Having reviewed everything I have concluded that what I have been doing
with passing ``extra'' parameters from the bootloader to the OS image
for linuxBIOS is not the best way to go.  To this end I in the process
of implementing tables that can just be scanned for in memory
to get the linuxBIOS information.

With that it becomes much easier to build a single set of tools that can
handle all of the interesting cases.

I still believe there is some information (bootloader, bootloader
version, etc) that should be passed from the etherboot to the loaded
image.   In general the information is unneeded but it allows for bug
work arounds and other special case behavior.

I posted my ideas on how to accomplish this a little while ago before
I went on vacation. 

Anyway I am working on implementing those ideas and will probably have
a patch for etherboot along presently.  The first patch will just
modify how etherboot gets the memory size from linuxBIOS.  Then
I will be interested to see what we can clean up on the loader side.

Eric

[Etherboot-developers] Patch to support SIS 630ET NIC

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

Hmm, doesn't look like my first mail message made it to the lists, so I'll
try again.

This patch applies against etherboot-5.0.5 and adds support for the
SIS 630ET NIC embedded in the SIS 630ET chipset.  I got the changes
from the the Linux sis900 driver.

Thanks,

Doug A.

*** sis900.h.orig	Mon Apr  2 02:00:04 2001
--- sis900.h	Wed Jan  2 12:47:31 2002
***************
*** 39,44 ****
--- 39,46 ----
  
  /* Symbolic names for bits in various registers */
  enum sis900_command_register_bits {
+     RELOAD  = 0x00000400,
+     ACCESSMODE = 0x00000200,/* ET */
      RESET   = 0x00000100, 
      SWI     = 0x00000080, 
      RxRESET = 0x00000020,
***************
*** 320,326 ****
  
  enum sis900_revision_id {
  	SIS630A_900_REV = 0x80,		SIS630E_900_REV = 0x81,
! 	SIS630S_900_REV = 0x82,		SIS630EA1_900_REV = 0x83
  };
  
  enum sis630_revision_id {
--- 322,329 ----
  
  enum sis900_revision_id {
  	SIS630A_900_REV = 0x80,		SIS630E_900_REV = 0x81,
! 	SIS630S_900_REV = 0x82,		SIS630EA1_900_REV = 0x83,
! 	SIS630ET_900_REV = 0x84
  };
  
  enum sis630_revision_id {
*** sis900.c.orig	Sat Oct 27 02:13:26 2001
--- sis900.c	Wed Jan  2 12:47:01 2002
***************
*** 201,206 ****
--- 201,242 ----
  
  	return 1;
  }
+ 
+ /**
+  *	sis630e_get_mac_addr: - Get MAC address for SiS630E model
+  *	@pci_dev: the sis900 pci device
+  *	@net_dev: the net device to get address for
+  *
+  *	SiS630E model, use APC CMOS RAM to store MAC address.
+  *	APC CMOS RAM is accessed through ISA bridge.
+  *	MAC address is read into @net_dev->dev_addr.
+  */
+ 
+ static int sis635_get_mac_addr(struct pci_device * pci_dev, struct nic *nic, 
+ 	long ioaddr)
+ {
+ 	u32 rfcrSave;
+ 	u32 i;
+ 
+ 	rfcrSave = inl(rfcr + ioaddr);
+ 
+ 	outl(rfcrSave | RELOAD, ioaddr + cr);
+ 	outl(0, ioaddr + cr);
+ 
+ 	/* disable packet filtering before setting filter */
+ 	outl(rfcrSave & ~RFEN, rfcr + ioaddr);
+ 
+ 	/* load MAC addr to filter data register */
+ 	for (i = 0 ; i < 3 ; i++) {
+ 		outl((i << RFADDR_shift), ioaddr + rfcr);
+ 		*( ((u16 *)nic->node_addr) + i) = inw(ioaddr + rfdr);
+ 	}
+ 
+ 	/* enable packet filitering */
+ 	outl(rfcrSave | RFEN, rfcr + ioaddr);
+ 
+ 	return 1;
+ }
  
  /* 
   * Function: sis900_probe
***************
*** 240,249 ****
      /* get MAC address */
      ret = 0;
      pcibios_read_config_byte(pci->bus,pci->devfn, PCI_REVISION, &revision);
!     if (revision == SIS630E_900_REV || revision == SIS630EA1_900_REV)
         ret = sis630e_get_mac_addr(pci, nic);
!     else if (revision == SIS630S_900_REV)
!         ret = sis630e_get_mac_addr(pci, nic);
      else
          ret = sis900_get_mac_addr(pci, nic);
  
--- 276,286 ----
      /* get MAC address */
      ret = 0;
      pcibios_read_config_byte(pci->bus,pci->devfn, PCI_REVISION, &revision);
!     if (revision == SIS630E_900_REV || revision == SIS630EA1_900_REV 
! 	|| revision == SIS630S_900_REV)
         ret = sis630e_get_mac_addr(pci, nic);
!     else if ((revision > 0x81) && (revision <= 0x90))
!         ret = sis635_get_mac_addr(pci, nic, ioaddr);
      else
          ret = sis900_get_mac_addr(pci, nic);
  
***************
*** 252,257 ****
--- 289,299 ----
          printf ("sis900_probe: Error MAC address not found\n");
          return NULL;
      }
+ 
+     /* 630ET : set the mii access mode as software-mode */
+     if (revision == SIS630ET_900_REV)
+ 	outl(ACCESSMODE | inl(ioaddr + cr), ioaddr + cr);
+ 
  
      printf("\nsis900_probe: MAC addr %! at ioaddr %#hX\n",
             nic->node_addr, ioaddr);

Re: [Etherboot-developers] Re: Etherboot 5.0.5 released

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

>> + Mark G of Inprimis Technologies contributed another FA311 (National
>> Semiconductor DP83815) driver, also based on the Donald Becker Linux
>> driver.
>
>Cool. How many drivers are there in Etherboot for the FA311? I seem to rememb
>er there being two tulip drivers, does this mean there are now three of them?
> Any advice for choosing which to use?

The FA311 doesn't have a Tulip family chip. As noted above, it has a
Natsemi DP83815. So there are two Natsemi drivers. The old Tulip driver
is not much good, I don't know anybody who uses it, so effectively
Marty's driver is it.

[Etherboot-developers] Re: Etherboot 5.0.5 released

[ken r. <ke...@24...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Mon, Dec 31, 2001 at 12:05:01PM -0800, eth...@li... wrote:
>    1. Etherboot 5.0.5 released (ke...@us...)
> 
> + Mark G of Inprimis Technologies contributed another FA311 (National
> Semiconductor DP83815) driver, also based on the Donald Becker Linux
> driver.

Cool. How many drivers are there in Etherboot for the FA311? I seem to remember there being two tulip drivers, does this mean there are now three of them? Any advice for choosing which to use?

> 
> 
> This release is dedicated to the memory of my mother (July 1917 -
> November 2001) [Ken Yap].
> 

My condolences.

- -ken

- -- 
- ------------------
One world. Many gods. Plenty for everyone.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD4DBQE8MMose8HF+6xeOIcRAgncAJY7Ayzk3yw1MDL0nhhn77SuUmtYAKCSZDHu
4GhBEirOS9sZM1dacju8UQ==
=efa5
-----END PGP SIGNATURE-----

[Etherboot-developers] Etherboot 5.0.5 released

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

I have released Etherboot 5.0.5 at http://etherboot.sourceforge.net/
and also at http://etherboot.berlios.de/

Changes from 5.0.4:

+ Fixed a struct alignment (8-byte constraint) problem in lance.c caused
by the introduction of the rx_idx field by moving rx_idx to the end of
the struct. Found by Rizsanyi Zsolt. Klaus Espenlaub also suggested
increasing all the Rx buffers by 4 bytes because of the checksum stored
at the end.

+ Fred Gray contributed changes in tulip.c to check for a duplex
connection and to modify the controller register if so. Marty fixed an
unassigned to "negotiated" variable.

+ Mark G of Inprimis Technologies contributed another FA311 (National
Semiconductor DP83815) driver, also based on the Donald Becker Linux
driver.

+ Armin Schindler contributed a patch to allow booting LynxOS KDI
images.

+ Moved code to set PCI busmastering and reasonable latency to a routine
in pci.c and added calls to this routine from all PCI drivers.

+ New files for contrib/mkffwnb for version 1.9.11 and 1.9.16.

+ Removed BOOTP_DATA_AT_0x93Cxx option.

+ Convert epic100 driver to use hardware timer for transmit timeout and
remove polling loop from receive routine.

+ Steve Tilden pointed out that BOOT_INT18H is a LCONFIG option, not a
CFLAGS32 option. Put note under option documentation and also added a
commented-out example in Config. Steve also contributed a patch¸ in
contrib/auto-default, which autoboots from the next device if a disk is
detected.

+ PNP_BUT_NOT_BBS_COMPLIANT option renamed to BBS_BUT_NOT_PNP_COMPLIANT.

+ Merged in Vasil Vasilev's changes to loader.S to release memory taken
by PXE properly.

+ E820 memory detection routines added by Eric Biederman. May increase
size of bss segment and push large drivers, e.g. Tulip, nearer to limit,
please report.

+ Default to -DCONGESTED in Config, may help on busy networks.

+ Add Holtek HT80232 to list of NE2000 PCI clones.

+ Remove prohibition on loading < 0x10000 in ELF images since by default
drivers don't use memory < 0x10000 any more, with 48kB to run in.

+ Put define of ETH_MAX_MTU in etherboot.h inside #ifndef so that it can
be overriden from Makefile.

+ Gustavo Junior Alves added .cvsignore files for src/bin and src/bin32.

+ Short note on how to make tomsrtbt netbootable in contrib/tomsrtbt.

This release is dedicated to the memory of my mother (July 1917 -
November 2001) [Ken Yap].

Released as Etherboot 5.0.5 (production)

MD5 sums:

1b7bcf5544ef8729bd6ea571ef8fc365  etherboot-5.0.5.tar.bz2
4ac4ae1bedfbea21acace604229c4ff2  etherboot-5.0.5.tar.gz
64579f1e248c4e7e8c632a57dcee2013  patch-5.0.5.gz

SHA1 sums:

bb33a933f8515e70a937c0033c28d5f8a4fb9214  etherboot-5.0.5.tar.bz2
fbf50f9f6169b9b53b5ed416fb0394472261d06f  etherboot-5.0.5.tar.gz
00a3f4197f5245e3d86462e4e363927088c5cf2b  patch-5.0.5.gz

Re: [Etherboot-developers] Inconsistence on CVS tree

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

>Will be nice! :-)
>
>Ken Yap wrote:
>
>>>Those are the patches for .cvsignore.
>>
>>Ok, thanks, will add. Would you like to be a registered developer?

Ok, register yourself at sourceforge.net and then mail me your Unix
login ID.

Re: [Etherboot-developers] Inconsistence on CVS tree

[Gustavo J. A. <al...@co...>]

Will be nice! :-)

Ken Yap wrote:

>>Those are the patches for .cvsignore.
>>
>
>Ok, thanks, will add. Would you like to be a registered developer?
>
>_______________________________________________
>Etherboot-developers mailing list
>Eth...@li...
>https://lists.sourceforge.net/lists/listinfo/etherboot-developers
>

Re: [Etherboot-developers] Inconsistence on CVS tree

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

>Those are the patches for .cvsignore.

Ok, thanks, will add. Would you like to be a registered developer?

Re: [Etherboot-developers] Inconsistence on CVS tree

[Gustavo J. A. <al...@co...>]

--- src/bin/.cvsignore	Tue May  5 17:32:27 1998
+++ src/bin/.cvsignore	Fri Dec 21 14:38:18 2001
@@ -0,0 +1,4 @@
+*.bin
+*.s
+lzhuf
+makerom
--- src/bin32/.cvsignore	Tue May  5 17:32:27 1998
+++ src/bin32/.cvsignore	Fri Dec 21 14:35:35 2001
@@ -0,0 +1,16 @@
+*.com
+*.rom
+*.pxe
+*.lilo
+*.dsk
+*.lzrom
+*.lzpxe
+*.lzlilo
+*.lzdsk
+*.img
+*.huf
+*.a
+*.o
+*.tmp
+*.elf
+*.ebi

[Etherboot-developers] stats page for rom-o-matic.net

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

For the curious or otherwise statistically inclined, I've put up a stats 
page for rom-o-matic.net that gets updated once a day.

The URL is:

   http://www.rom-o-matic.net/stats/

Marty

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

   Name: Marty Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827; Cambridge, MA 02139; USA
  Voice: (617) 491-6935, Fax: (617) 491-7046 
  Email: md...@th...
    Web: http://www.thinguin.org/

[Etherboot-developers] Re: Etherboot in Linux Journal publications

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

On 12/21/2001 9:39 AM Richard C Ferri rc...@us... wrote:
>Marty, everyone,
>      I wrote the article in LinuxJournal regarding booting linux remotely.
>I didn't mean to mis-represent etherboot in any way -- in fact I am an avid
>etherboot user.  Since I work on commodity clusters, I don't use the
>ability to write etherboot to BIOS -- in our clusters we use either
>etherboot from diskette or PXE.

Richard,

Thanks very much for your message!  It is gratifying to know that 
Etherboot is being used extensively in your work, and thanks also for the 
pointers to other projects that use Etherboot.

We've exhibited at the last two LinuxWorld Expo conferences and we plan 
to do so again in New York at the end of January 2002.  I hope you'll be 
able to attend and visit us in our booth.  I and Markus Gutschke (one of 
the original Etherboot authors) will be there.  Ken was at the last show 
in San Francisco, but can't make the New York show this time.

One funny thing that happens when we go to shows is that business people  
always come up and ask us "What's your business plan?".  We smile, and 
usually say something like "nobody beats us on price!".  The funny thing 
is that we actually have no real budget, business plan, or venture 
capital.  We do what we do because we find in rewarding and useful in 
some way.  That folks like yourself use it in your work is warms my 
heart. Knowing that drivers that I have written are running somewhere 
also makes me smile.

Rom-o-matic.net generated over 50,000 Etherboot images in its first year, 
and is on track to do even more this year. I expect at least 75,000, or 
1500 a week.  Clearly Ken's "hobby project" is doing quite nicely :)

Anyway, thanks again for your kind message, and thanks for spreading the 
word about our efforts, and those of our friends at LTSP.org.

Regards,

Marty

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

   Name: Marty Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827; Cambridge, MA 02139; USA
  Voice: (617) 491-6935, Fax: (617) 491-7046 
  Email: md...@th...
    Web: http://www.thinguin.org/

[Etherboot-developers] Re: Etherboot in Linux Journal publications

[Richard C F. <rc...@us...>]

Marty, everyone,
      I wrote the article in LinuxJournal regarding booting linux remotely.
I didn't mean to mis-represent etherboot in any way -- in fact I am an avid
etherboot user.  Since I work on commodity clusters, I don't use the
ability to write etherboot to BIOS -- in our clusters we use either
etherboot from diskette or PXE.

       I don't know if you're aware of some of the ways we've used
etherboot... When I first wrote LUI, the Linux Utility for cluster Install,
2 years ago (oss.software.ibm.com/lui) it supported both etherboot and pxe
style booting.  LUI was picked up as the cluster installation method for
OSCAR (www.sourceforge.net/projects/oscar).  OSCAR is an open source
cluster solution for High Performance Computing -- it's been downloaded
over 16,000 times.  The top 500 clusters web site recently did a survey (
http://clusters.top500.org/pollbooth.php?qid=clustersys and OSCAR came in
third among open source clustering solutions. However, MSC.Linux picked up
OSCAR as their High Performance Computing solution, and as such MSC and
OSCAR combined scored 29 percent and would be in first place.  Judging from
the mailing lists for oscar, I'd say about half our users use straight PXE,
and the other half use etherboot.  So, maybe you didn't realize it, but
etherboot has had a significant impact on high performance computing
clusters.  In fact, OSCAR was picked up by NCSA as the basis for their
grid-in-a-box, cluster-in-a-box and display-wall-in-a-box initiatives.

      Well, I just wanted to give credit where due... thanks for all your
hard work and running a great project (LTSP too!)...

happy holidays, Rich

Richard Ferri
IBM Linux Technology Center
rc...@us...
845.433.7920


Marty Connor <md...@th...> on 12/21/2001 07:59:02 AM

To:    "Etherboot Developers" <eth...@li...>,
       "Etherboot Users" <eth...@li...>
cc:
Subject:    Etherboot in Linux Journal publications



There is an article in the January 2002 Linux Journal on "The Basics of
Booting Linux Remotely" which mentions Etherboot.  They didn't quite seem
to realize that Etherboot creates code that can be burned into ROM or
flashed into BIOS, but seemed to think that it can only be run from a
floppy and if you want a ROM you have to buy a PXE-enabled card.  Oh
well, at least we're positively mentioned, and more people will visit the
web page and find us and LTSP and realize all the capabilities that we
are offering.

There was also a nice article in the September/October 2001 (issue 5)
Embedded Linux Journal called "Booting from the Ether" by Jay Sissom.  He
talks about booting the ThinkNIC by burning your own CDROM and using
Etherboot as well as other methods.

I'm pretty sure people are reading these articles because when they are
released I get a pretty good spike on rom-o-matic.net :)

Anyway, it's nice to be mentioned, and hopefully people will use and
enjoy (and help improve) our free software and free services.

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 in Linux Journal publications

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

There is an article in the January 2002 Linux Journal on "The Basics of 
Booting Linux Remotely" which mentions Etherboot.  They didn't quite seem 
to realize that Etherboot creates code that can be burned into ROM or 
flashed into BIOS, but seemed to think that it can only be run from a 
floppy and if you want a ROM you have to buy a PXE-enabled card.  Oh 
well, at least we're positively mentioned, and more people will visit the 
web page and find us and LTSP and realize all the capabilities that we 
are offering.

There was also a nice article in the September/October 2001 (issue 5) 
Embedded Linux Journal called "Booting from the Ether" by Jay Sissom.  He 
talks about booting the ThinkNIC by burning your own CDROM and using 
Etherboot as well as other methods.  

I'm pretty sure people are reading these articles because when they are 
released I get a pretty good spike on rom-o-matic.net :)

Anyway, it's nice to be mentioned, and hopefully people will use and 
enjoy (and help improve) our free software and free services.

Marty

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

   Name: Marty Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827; Cambridge, MA 02139; USA
  Voice: (617) 491-6935, Fax: (617) 491-7046 
  Email: md...@th...
    Web: http://www.thinguin.org/

Re: [Etherboot-developers] Intel 82559ER question

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

>ummm...TICKS_PER_SEC in etherboot.h is defined to be 18.  How do u get
>this to be 18?

That's the well-known* rate of the BIOS clock, 18.2something is closer,
but it's only used for macro delays so it's not critical. As I said, if
you're using LinuxBIOS, you probably don't have a BIOS clock. And that's
not the timer used for udelay anyway.

* Well-known to people who have looked at the IBM PC architecture specs.  :-)

Re: [Etherboot-developers] Intel 82559ER question

[BHARATHWAJ M. <mb...@co...>]

ummm...TICKS_PER_SEC in etherboot.h is defined to be 18.  How do u get
this to be 18?

Bharath

On Fri, 21 Dec 2001, Ken Yap wrote:

> >Unfortunately, I am getting timing issues.  For instance, if I keep adding
> >printfs in the do loop in the function do_eeprom_cmd in eepro100.c, the
> >loop advances, if not it doesn't.  Here is my do_eeprom_cmd in eepro100.c:
>
> It could be that the timing requirements of recent chips require a
> larger delay now. You could try increasing the value in udelay (but only
> up to max of about 50, due to the way udelay works). Also have a look at
> what values they're using in Linux drivers these days.
>
> Also udelay relies on the hardware timer. Do you have this timer on your
> motherboard?
>
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers
>

Re: [Etherboot-developers] Intel 82559ER question

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

>> Also udelay relies on the hardware timer. Do you have this timer on your
>> motherboard?
>
>I will have to verify this.  Right now I am thinking no, because I noticed
>that although -DASK_BOOT=3, there
>is no waiting at all, just flies right through using the default value.  I
>tried setting it to 10, didnt work, no waiting at all!

Actually there are two timers. The one that does macro delays is the
18.2 Hz BIOS timer, which you probably don't have with LinuxBIOS, you
may have to enable the replacement routines in timer.c which use the
time stamp counter (CONFIG_TSC_CURRTICKS, Eric wrote this code). The one
for microdelays uses the timer chip and is incremented at about 1.2 MHz
so with a 16 bit counter gives a max of about 55 ms of delay. You'd hope
that this timer chip is implemented in all compatibles, but who knows.