etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] booting non linux images

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

>Actually the bootsect.S and setup.S _are_ sligntly changed versions of
>corresponding Linux files. They even carry the copyright message of Linus
>Torvalds.
>
>mknbi-linux reports that it is not a Linux kernel image. Actually I tried
>to _blindly_ build it with the build program of a newer linux kernel, but
>this didn't work. I am now trying the problem in a more methodical way.

That's probably because it didn't find various magic numbers in the
bootblock or the setup segment. See which one it's complaining about,
and temporarily disable the check in mknbi.pl.

>First I wrote a small C program (well, to be honest, I am not at all good
>in Perl, althogh I use C, shell scripting and PHP extensively) to compare
>two binary files and find equal regions. Using this and hexdump I am
>comparing a real linux kernel and a tagged one with mknbi-linux. This
>shows that a tagged immage is a header plus the original image. If I am to
>write a program mknbi.memtest86 (in C), will I have to first write the
>header and "append" the "kernel" to it?

Sure, but as I said, you'd have better luck modifying mknbi.pl.

>BTW, please let me know if the documentation regarding a tagged images
>_with_ a first magic number is correct and whether etherboot handles them
>(unlike the ones with a second magic number)?

Yes, it is correct.

[Etherboot-developers] some rom-o-matic.net stats

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

I thought it might be interesting to take a week of ROM-o-matic.net data 
and do a simple count of what ROMs were requested. Below is a simple 
count of each ROM image type requested sorted in reverse order by 
frequency.

This will give you a rough idea of what kinds of Etherboot images people 
are generating.  With a little more work (and using the table in the NIC 
file in the Etherboot distribution) one could reduce the data further by 
the actual driver that is being used.  For example, the tulip driver 
handles lots of different ROM images, as does the 3C90x driver.  I can 
hear some enterprising perl hackers in the background already getting 
their associative arrays going right now... :-)

Anyway, this was just for curiosity's sake.  The rom-o-matic has been 
doing about 1000 ROM images a week for the last month:

access_log.20010422: 951
access_log.20010429: 1160
access_log.20010506: 1080
access_log.20010513: 1132

So here's the data.  It's nice to see that people are making use of the 
service.

Enjoy :-)

Marty

http://rom-o-matic.net/ 
ROM images generated for the period 
Sunday, May 6, 2001 04:00 to Sunday, May 13, 2001 04:00

Total                    1132

rtl8139                   176
ne                        157
3c509                     105
eepro100                   86
rtl8029                    60
3c503                      49
sis900                     43
3c905c-tpo                 41
tulip                      35
3c905b-tpo100              25
davicom9102                21
wd                         19
lancepci                   17
ne2100                     15
3c905b-fx                  14
3c590                      12
3c905b-tpo                 12
eepro                      12
intel21145                 12
dlink-530tx                11
82559er                    10
via-rhine                  10
otulip                      9
sis7016                     8
3c900b-combo                7
dc21041                     7
mx98715                     7
amdhomepna                  6
kne110tx                    6
smc1211                     6
3c905b-combo                5
compexrl100atx              5
dlink-530tx-old             5
lc82c115                    5
rl100tx                     5
smc9000                     5
3c905-tpo                   4
3c905-tpo100                4
3c905b-t4                   4
cs89x0                      4
dfe530tx%2B                 4
mx98713                     4
pcnetfastiii                4
3c595                       3
3c905-t4                    3
davicom9009                 3
ds21140                     3
ds21142                     3
ds21143                     3
epic100                     3
ktiet32p2                   3
mx98725                     3
mxic-98715                  3
3c900b-tpo                  2
3c905-combo                 2
depca                       2
nepci                       2
winbond840                  2
winbond940                  2
3c507                       1
3c529                       1
3c595-1                     1
3c595-2                     1
3c900-t4                    1
3c900-tpo                   1
3c900b-fl                   1
3c900b-tpb2                 1
3c905b-fl                   1
3c905b-tpb2                 1
82562em                     1
82c168                      1
an981                       1
ax88140                     1
ax88141                     1
centaur-c                   1
centaur-p                   1
compexrl2000                1
dc21040                     1
dm9100                      1
dm9102                      1
ds21140a                    1
exos205                     1
id1029                      1
id1030                      1
ni5010                      1
ni5210                      1
ni6510                      1
nv5000sc                    1
sk_g16                      1
tiara                       1
tulip21142                  1
via-rhine-old               1
xircomtulip                 1


---
    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] booting non linux images

[Anuradha R. <anu...@gn...>]

On Mon, 14 May 2001, Ken Yap wrote:

> Etherboot users taken off recipients as they are probably not
> interested.
> 
> >1. memtest86.bin contains 512 bytes of boot sector, 2048 bytes of
> >   of setup and the "real" code.
> 
> So the layout looks like a Linux kernel. What happens if you run
> mknbi-linux on it as if it were a Linux kernel? After all LILO likes
> it too.

Actually the bootsect.S and setup.S _are_ sligntly changed versions of
corresponding Linux files. They even carry the copyright message of Linus
Torvalds.

mknbi-linux reports that it is not a Linux kernel image. Actually I tried
to _blindly_ build it with the build program of a newer linux kernel, but
this didn't work. I am now trying the problem in a more methodical way.

> >2. The os loads bootsector to the standard location (0x7c00) and
> >   transfers control to it.
> >
> >3. The code in the boot sector duplicates itself at 0x90000 and jumps
> >   to the new location. It loads setup at 0x90200 (does it load the
> >   rest of the code at 0x10000?) and transfers control to the setup.
> 
> Looking more and more like a Linux kernel setup.

Yep.

> >4. Setup does necessary initilizations, detects memory etc. (does it
> >   handle the loading of the rest) and transfers control to
> >   0x10000.
> >
> >5. The code at 0x10000 moves the code in relo.out to memory above 0x100000
> >   etc. but we don't have to worry about this.
>
> Looks very familiar.

I am not very sure about these last few steps. Also there can be missing
points or wrong assumptions and addresses in my list. If anybody has gone
through memtest86 code please let me know if I am wrong...
 
> >Now about tagged image...
> >
> >1. First I write four bytes containing the magic number.
> >
> >2. Then I write the header of the tagged image so that the tagged image
> >   contains two sections (setup and the rest of the code) and the starting
> >   and loading address of setup is given as 0x902000?
> 
> Don't deal with raw bits like this, there are methods defined to
> handle the file format transparently. But first try running
> mknbi-linux on it as if it were a Linux kernel.

Since mknbi-linux didn't work, I started approaching the problem like
this.

First I wrote a small C program (well, to be honest, I am not at all good
in Perl, althogh I use C, shell scripting and PHP extensively) to compare
two binary files and find equal regions. Using this and hexdump I am
comparing a real linux kernel and a tagged one with mknbi-linux. This
shows that a tagged immage is a header plus the original image. If I am to
write a program mknbi.memtest86 (in C), will I have to first write the
header and "append" the "kernel" to it?

I am halfway going through the process. I want to add a new tag to
memtest86 Makefile to convert memtest86.bin to a tagged image _without_
changing the existing programs.

BTW, please let me know if the documentation regarding a tagged images
_with_ a first magic number is correct and whether etherboot handles them
(unlike the ones with a second magic number)?

Thanks for your time and attention.

Regards,

Anuradha

Re: [Etherboot-developers] booting non linux images

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

Etherboot users taken off recipients as they are probably not
interested.

>1. memtest86.bin contains 512 bytes of boot sector, 2048 bytes of
>   of setup and the "real" code.

So the layout looks like a Linux kernel. What happens if you run
mknbi-linux on it as if it were a Linux kernel? After all LILO likes it
too.

>2. The os loads bootsector to the standard location (0x7c00) and
>   transfers control to it.
>
>3. The code in the boot sector duplicates itself at 0x90000 and jumps
>   to the new location. It loads setup at 0x90200 (does it load the
>   rest of the code at 0x10000?) and transfers control to the setup.

Looking more and more like a Linux kernel setup.

>4. Setup does necessary initilizations, detects memory etc. (does it
>   handle the loading of the rest) and transfers control to
>   0x10000.
>
>5. The code at 0x10000 moves the code in relo.out to memory above 0x100000
>   etc. but we don't have to worry about this.

Looks very familiar.

>Now about tagged image...
>
>1. First I write four bytes containing the magic number.
>
>2. Then I write the header of the tagged image so that the tagged image
>   contains two sections (setup and the rest of the code) and the starting
>   and loading address of setup is given as 0x902000?

Don't deal with raw bits like this, there are methods defined to handle
the file format transparently. But first try running mknbi-linux on it
as if it were a Linux kernel.

Re: [Etherboot-developers] booting non linux images

[Anuradha R. <anu...@be...>]

Dear Eric and Ken,

On Mon, 14 May 2001, Ken Yap wrote:

> If you know the load map of memtest86, it's fairly easy to write a
> routine for mknbi.pl to generate a tagged/ELF image. Look at sub
> mknbi_rom for the simplest example.

This is what I understand about memtest86 booting procedure. Please
correct me if I am wrong. I am trying to write a mknbi.memtest86 for that.

1. memtest86.bin contains 512 bytes of boot sector, 2048 bytes of
   of setup and the "real" code.

2. The os loads bootsector to the standard location (0x7c00) and
   transfers control to it.

3. The code in the boot sector duplicates itself at 0x90000 and jumps
   to the new location. It loads setup at 0x90200 (does it load the
   rest of the code at 0x10000?) and transfers control to the setup.

4. Setup does necessary initilizations, detects memory etc. (does it
   handle the loading of the rest) and transfers control to
   0x10000.

5. The code at 0x10000 moves the code in relo.out to memory above 0x100000
   etc. but we don't have to worry about this.

Now about tagged image...

1. First I write four bytes containing the magic number.

2. Then I write the header of the tagged image so that the tagged image
   contains two sections (setup and the rest of the code) and the starting
   and loading address of setup is given as 0x902000?

Will let you know the progress. Please let me know if I am making any
fundamental mistake.

Thanks again for your time.

Regards

Anuradha

Re: [Etherboot-developers] booting non linux images

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

>The patch applies neatly and memtest86.bin builds fine. But making
>memtest86.ebi stops with a link error.
>
>ld -T memtest86.lds head.obj relo.obj -o memtest86.ebi
>ld: bfd assertion fail ../../bfd/elf.c:1405
>ld: bfd assertion fail ../../bfd/elf.c:1405
>relo.obj: file not recognized: File format not recognized
>make: *** [memtest86.ebi] Error 1

If you know the load map of memtest86, it's fairly easy to write a
routine for mknbi.pl to generate a tagged/ELF image. Look at sub
mknbi_rom for the simplest example.

Re: [Etherboot-developers] Re: [Etherboot-users] atftp-0.2 tarball and RPMs available

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

>http://freshmeat.net/projects/atftp/

Updated.

Re: [Etherboot-developers] Re: [Etherboot-users] atftp-0.2 tarball and RPMs available

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

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

> >O.k.  The reason I ask is that it seems to be maintained as a debian project,
> >and version 0.3 has been out since sometime in march.
> 
> I didn't know that. I'll update the RPMs. URL please?

http://freshmeat.net/projects/atftp/

Is a good pointer.

Eric

Re: [Etherboot-developers] Re: [Etherboot-users] atftp-0.2 tarball and RPMs available

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

>O.k.  The reason I ask is that it seems to be maintained as a debian project,
>and version 0.3 has been out since sometime in march.

I didn't know that. I'll update the RPMs. URL please?

Re: [Etherboot-developers] Re: [Etherboot-users] atftp-0.2 tarball and RPMs available

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

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

> >What is the maintenance status of atftp?
> 
> It's contributed software and works well for me. As with all Etherboot
> software, I'll fix bugs if people provide patches or sufficient
> information to diagnose the problem.

O.k.  The reason I ask is that it seems to be maintained as a debian project,
and version 0.3 has been out since sometime in march.
 
> It is started from (x)inetd, but once started it uses threads to handle
> further clients, so (x)inetd won't think the service is overloaded.

True.   With atftp I haven't seen problems with inetd.  I have
see weird problems with it locking up though, it failing worse than if inetd
had simply refused to answer requests.  For me to really trust a
solution I'm going to have to both test it very hard and read the
code.  I'm not convinced there are currently any stable tftp servers....

Eric

Re: [Etherboot-developers] Re: [Etherboot-users] atftp-0.2 tarball and RPMs available

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

>What is the maintenance status of atftp?

It's contributed software and works well for me. As with all Etherboot
software, I'll fix bugs if people provide patches or sufficient
information to diagnose the problem.

It is started from (x)inetd, but once started it uses threads to handle
further clients, so (x)inetd won't think the service is overloaded.

[Etherboot-developers] Re: [Etherboot-users] atftp-0.2 tarball and RPMs available

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

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

> For your convenience, I have made a tarball and RPMs of the atftp-0.2
> package from the contrib/ directory available at
> http://etherboot.sourceforge.net/distribution.html
> Also in the FTP area.

What is the maintenance status of atftp?

I haven't shopped around very widely but to date I have found 
not found a stable tftp configuration.  In particular I have tested
atftp 0.1, inetd/tftp from redhat 6.1, inetd/tftp from redhat 6.2.
Under load, and long life none of the tested tftp servers stayed up.
Usually it comes down to a bug in inetd where it won't even start the
tftp process.  I usually resort to restarting inetd to get things
going again.

If someone could point me to a stable combination I'd really
appreciate it.

Eric

Re: [Etherboot-developers] booting non linux images

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

Anuradha Ratnaweera <anu...@gn...> writes:

> On 12 May 2001, Eric W. Biederman wrote:
> 
> > The attached patch to memtest86-2.5 builds it as an ELF image.
> > Etherboot cannot load an unpatched image memtest86 loads to low in
> > memory.
> > 
> > I have used this succesfully with the 4.6.10 with Multiboot support
> > compiled it.
> 
> The patch applies neatly and memtest86.bin builds fine. But making
> memtest86.ebi stops with a link error.
> 
> ld -T memtest86.lds head.obj relo.obj -o memtest86.ebi
> ld: bfd assertion fail ../../bfd/elf.c:1405
> ld: bfd assertion fail ../../bfd/elf.c:1405
> relo.obj: file not recognized: File format not recognized
> make: *** [memtest86.ebi] Error 1
> 
> Any clue?

Grr yes.  Your version of ld is buggy.
I have seen this once before.  If I could figure out how
to make it work with your version of ld I would.

I think I have a bad choice of names in relo.obj.  Because
except for names relo.obj and head.obj are exactly identical.

What I am currently running is:
GNU ld 2.10.90
Copyright 2000 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.
  Supported emulations:
   elf_i386
   i386linux


Eric

Re: [Etherboot-developers] booting non linux images

[Anuradha R. <anu...@gn...>]

On 12 May 2001, Eric W. Biederman wrote:

> The attached patch to memtest86-2.5 builds it as an ELF image.
> Etherboot cannot load an unpatched image memtest86 loads to low in
> memory.
> 
> I have used this succesfully with the 4.6.10 with Multiboot support
> compiled it.

The patch applies neatly and memtest86.bin builds fine. But making
memtest86.ebi stops with a link error.

ld -T memtest86.lds head.obj relo.obj -o memtest86.ebi
ld: bfd assertion fail ../../bfd/elf.c:1405
ld: bfd assertion fail ../../bfd/elf.c:1405
relo.obj: file not recognized: File format not recognized
make: *** [memtest86.ebi] Error 1

Any clue?

Sorry for going stightly off topic.

Thanks in advance.

Anuradha

[Etherboot-developers] atftp-0.2 tarball and RPMs available

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

For your convenience, I have made a tarball and RPMs of the atftp-0.2
package from the contrib/ directory available at
http://etherboot.sourceforge.net/distribution.html
Also in the FTP area.

If there are any Debian dpkg experts out there I'd appreciate some help
making the DEBs. You'll find the tarball already contains the debian/
subdirectory, but dpkg-buildpackage is having problems computing the
dependencies on my system. I suspect it's because I'm running dpkg
hosted on an RPM system (SuSE).

[Etherboot-developers] hmmm, what is that damn clicking noise? :-)

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

I had a head crash on my main development machine (a laptop), but 
fortunately I back up the important stuff (my home directory,  mainly :-) 
to another machine.

So, I had the perfect opportunity to try out the shiny new Progeny Debian 
that I just got (http://www.progeny.com/).

It is good.  

The installer was fast, lean, and efficient.  The messages during 
installation were helpful, and it used intelligent defaults for stuff.  
It installed Sawfish as the default window manager, and it runs nicely on 
my 333MHZ PII based machine.

I'm used to Red Hat, so I was a little hesitant to switch on my 
development machine, since for most of what I do (writing drivers, using 
CMU Common Lisp) it doesn't matter much what dist is on the machine.  But 
after Red Hat announced the 7.1 release to come out 1 day after Progeny 
Linux (April 24th), I figured that even Red Hat thought it might be good, 
and so that was a good cue to get Debian on my machine now :-)

I guess the thing I like most about Debian so far (besides apt-get) is 
that it is just very clean and tight.  That's not really very precise.  
It's more like driving a well-made car.  It's not one thing, but a lot of 
little things that let you know that it is made well.  I've been hacking 
or using computers most of my life now, and what it "feels" like is there 
are a lot of people like me who sweat details working on Debian, so a lot 
of little things that often don't usually work quite right simply *work* 
in Debian.

Anyway, I know this is kind of off-topic :-)  But I thought there might 
be other people like me who have thought about trying Debian, but found 
the installation process and documentation to be awful (especially for 
laptops) in the past, before the Progeny distribution, so might not be 
ready to try it again. I just wanted to say, "I tried it, I liked it".

Alright, back to hacking!!

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] booting non linux images

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

>I read in the tagged image spec that any image with bytes at offsets 510
>and 511 set to 55 and aa (may be the other way) is also valid, and this
>image _does_ contain those values. But etherboot doesn't detect it. I am
>extensively going through source code to get things fixed. I found that
>the file main.c does not check for these values. However the files in
>contrib/baremetal/main.c (line 461) _does_ this with wrong pointer
>manipulation.
>
>Also I understand a tagged image with a second magic number should be
>loaded at 0x10000 (not the boot sector which comes to 0x7c00) and not to
>0x100000. Does etherboot handle this?

Etherboot no longer supports that part of the spec. It takes up code
space, and gives misleading messages when people try to load bare
kernels, when binaries that can easily be tagged or ELFed. So strictly
speaking, it's non-conformant to the original spec. Tough. Use Eric
Biederman's ELF method.

Re: [Etherboot-developers] booting non linux images

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

Anuradha Ratnaweera <anu...@gn...> writes:

> Hello,
> 
> We have setup dhcp/tftp on debian 2.2 and things are working fine with a
> linux kernel tagged with mknbi-linux.
> 
> We need to run a progarm called memtest86 which runs stand alone, i.e., it
> is completely contained in a bootable image. Its booting procedure is
> based on _very_ old linux kernels. And many signatures and magic numbers
> seem to be minix compliant. Therefore mknbi-linux doesn't work.

The attached patch to memtest86-2.5 builds it as an ELF image.
Etherboot cannot load an unpatched image memtest86 loads to low in
memory.

I have used this succesfully with the 4.6.10 with Multiboot support
compiled it.


Eric

diff -uNr memtest86-2.5/Makefile memtest86-2.5.eb3/Makefile
--- memtest86-2.5/Makefile	Thu Sep 21 17:39:19 2000
+++ memtest86-2.5.eb3/Makefile	Wed Mar 21 21:44:37 2001
@@ -43,6 +43,9 @@
 memtest.bin: setup bootsect head.out relo.out build
 	./build bootsect setup head.out relo.out >memtest.bin
 
+memtest86.ebi: head.obj relo.obj memtest86.lds
+	ld -T memtest86.lds head.obj relo.obj -o $@
+
 test.o: test.c test.h defs.h config.h
 	$(CC) -c $(CCFLAGS) test.c
 
@@ -69,12 +72,16 @@
 	    $(OBJCOPY) relo relo.out; \
 	fi
 
+relo.obj: relo.out
+	ld -r -o $@ -T relo.lds -b binary $^
+
 head.o: head.s
 	as -o $@ $<
 
 head: $(OBJS)
 	ld -m elf_i386 -o $@ -e do_test -Ttext $(TXT_ADR) -Tdata $(DAT_ADR) \
 		-Map mapfile $(OBJS)
+
 head.out: head
 	if hash encaps 2> /dev/null; then \
 	    $(OBJDUMP) -o $(TXT_ADR) head >head.out; \
@@ -82,6 +89,9 @@
 	    $(OBJCOPY) head head.out; \
 	fi
 
+head.obj: head.out
+	ld -r -o $@ -T head.lds -b binary $^
+
 head.s: head.S test.h
 	$(CC) -E -traditional $< -o $@
 
@@ -108,7 +118,7 @@
 
 clean:
 	rm -f *.o *.s build memtest.bin bootsect setup head head.out mapfile relo \
-	      relo.out mapfile.relo
+	      relo.out mapfile.relo memtest86.ebi *.obj
 
 install: all
 	dd <memtest.bin >$(FDISK) bs=8192
Binary files memtest86-2.5/core and memtest86-2.5.eb3/core differ
diff -uNr memtest86-2.5/defs.h memtest86-2.5.eb3/defs.h
--- memtest86-2.5/defs.h	Thu Sep 21 17:39:16 2000
+++ memtest86-2.5.eb3/defs.h	Wed Mar 21 21:42:05 2001
@@ -8,7 +8,7 @@
 
 /*
  * Caution!! Do not change TESTADR, MAINSZ, TESTSZ or RELOBASE without also
- * editing the Makefile.
+ * editing the Makefile & memtest86.lds.
  */
 #define TESTADR		0x1000		/* Final adrs for the test code */
 #define MAINSZ		0x8800		/* Size of primary test code */
diff -uNr memtest86-2.5/head.S memtest86-2.5.eb3/head.S
--- memtest86-2.5/head.S	Thu Sep 21 16:48:25 2000
+++ memtest86-2.5.eb3/head.S	Wed Mar 21 21:56:03 2001
@@ -59,12 +59,6 @@
 
 	cld
 	cli
-	movl $(KERNEL_DS),%eax
-	mov %ax,%ds
-	mov %ax,%es
-	mov %ax,%fs
-	mov %ax,%gs
-	mov %ax,%ss
 	mov $(TESTADR),%esp
 /*
  * start system 32-bit setup. We need to re-do some of the things done
diff -uNr memtest86-2.5/head.lds memtest86-2.5.eb3/head.lds
--- memtest86-2.5/head.lds	Wed Dec 31 17:00:00 1969
+++ memtest86-2.5.eb3/head.lds	Wed Mar 21 21:30:04 2001
@@ -0,0 +1,5 @@
+OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386")
+OUTPUT_ARCH(i386)
+SECTIONS {
+	.head : { *(*) }
+}
diff -uNr memtest86-2.5/lib.c memtest86-2.5.eb3/lib.c
--- memtest86-2.5/lib.c	Wed Oct 18 12:57:40 2000
+++ memtest86-2.5.eb3/lib.c	Fri Mar 30 10:42:37 2001
@@ -839,8 +839,13 @@
 	/* now do hardwired init */
 	serial_echo_outb(0x03, UART_LCR); /* No parity, 8 data bits, 1 stop */
 	serial_echo_outb(0x83, UART_LCR); /* Access divisor latch */
+#if 1
 	serial_echo_outb(0x00, UART_DLM); /* 9600 baud */
 	serial_echo_outb(0x0c, UART_DLL);
+#else
+	serial_echo_outb(0x00, UART_DLM); /* 115200 baud */
+	serial_echo_outb(0x01, UART_DLL);
+#endif
 	serial_echo_outb(0x03, UART_LCR); /* Done with divisor */
 
 	/* Prior to disabling interrupts, read the LSR and RBR
diff -uNr memtest86-2.5/main.c memtest86-2.5.eb3/main.c
--- memtest86-2.5/main.c	Fri Oct 20 16:51:49 2000
+++ memtest86-2.5.eb3/main.c	Fri Mar 30 10:38:44 2001
@@ -66,6 +66,12 @@
 
 	/* Set pointer to common variable area */
 	v = (struct vars *)(TESTADR+TSTSIZE-0x400);
+	if (&segs > (int *)RELOBASE) {
+		v = (struct vars *)(RELOBASE+TESTADR+TSTSIZE-0x400);
+		if (v->firsttime == 0) {
+			restart();
+		}
+	}
 
 	/* If first time, initialize test */
 	if (v->firsttime == 0) {
@@ -392,7 +398,8 @@
         for(i=0, pp=(char *)(SCREEN_ADR+0); i<80*24; i++, pp+=2) {
                 *pp = ' ';
         }
-	do_test();
+	p = (unsigned long *)TESTADR;
+	goto *p;
 }
 
 /* Compute the total number of ticks per pass */
diff -uNr memtest86-2.5/memtest86.lds memtest86-2.5.eb3/memtest86.lds
--- memtest86-2.5/memtest86.lds	Wed Dec 31 17:00:00 1969
+++ memtest86-2.5.eb3/memtest86.lds	Fri Mar 30 10:37:40 2001
@@ -0,0 +1,26 @@
+__testadr = 0x1000;
+__reloadr = 0x9800;
+__zeroadr = 0x12000;
+__zerosz  = 0x400;
+__relobase = 0x100000;
+__start = __relobase + __reloadr;
+/*
+__relobase = 0;
+__start = __testadr;
+*/
+
+
+OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386")
+OUTPUT_ARCH(i386)
+PHDRS { 
+	head PT_LOAD ;
+	relo PT_LOAD ;
+	zero PT_LOAD ;
+}
+ENTRY(__start);
+
+SECTIONS {
+	.head (__testadr + __relobase): { *(.head) } : head
+	.relo (__reloadr + __relobase): { *(.relo) } : relo
+	.zero (__zeroadr + __relobase): { . = . + __zerosz; nothing = . ; } : zero
+}
diff -uNr memtest86-2.5/relo.lds memtest86-2.5.eb3/relo.lds
--- memtest86-2.5/relo.lds	Wed Dec 31 17:00:00 1969
+++ memtest86-2.5.eb3/relo.lds	Wed Mar 21 21:29:50 2001
@@ -0,0 +1,5 @@
+OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386")
+OUTPUT_ARCH(i386)
+SECTIONS {
+	.relo : { *(*) }
+}
diff -uNr memtest86-2.5/setup.S memtest86-2.5.eb3/setup.S
--- memtest86-2.5/setup.S	Wed Sep 20 12:08:11 2000
+++ memtest86-2.5.eb3/setup.S	Wed Mar 21 21:10:16 2001
@@ -128,7 +128,12 @@
 flush_instr:
 	mov	ax,#KERNEL_DS
 	mov	ds,ax
+	mov	es,ax
 	mov	ss,ax
+	mov	fs,ax
+	mov	gs,ax
+
+! Clear the video display
 	mov	ax,#0x0720
 	mov	ebx,#0xb8000
 	mov	ecx,#0xc0000

[Etherboot-developers] booting non linux images

[Anuradha R. <anu...@gn...>]

Hello,

We have setup dhcp/tftp on debian 2.2 and things are working fine with a
linux kernel tagged with mknbi-linux.

We need to run a progarm called memtest86 which runs stand alone, i.e., it
is completely contained in a bootable image. Its booting procedure is
based on _very_ old linux kernels. And many signatures and magic numbers
seem to be minix compliant. Therefore mknbi-linux doesn't work.

I read in the tagged image spec that any image with bytes at offsets 510
and 511 set to 55 and aa (may be the other way) is also valid, and this
image _does_ contain those values. But etherboot doesn't detect it. I am
extensively going through source code to get things fixed. I found that
the file main.c does not check for these values. However the files in
contrib/baremetal/main.c (line 461) _does_ this with wrong pointer
manipulation.

Also I understand a tagged image with a second magic number should be
loaded at 0x10000 (not the boot sector which comes to 0x7c00) and not to
0x100000. Does etherboot handle this?

Anuradha

Re: [Etherboot-developers] Access CMOS

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

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

> >Is it a good idea on saving some information to the CMOS? Does anyone
> >ever written any code to access the CMOS using etherboot? Such as the
> >Admin password and other BIOS settings?
> 
> Once you have booted your OS, a user program should be able to do what
> you want with the CMOS memory, so it's not something Etherboot needs to
> do. In Linux you can include the nvram driver. Where it is specified how
> the password etc are stored in the NVRAM, I have no idea.

It isn't specified.  And given the size of CMOS that is not suprise.
Besides the date and time I believe there is just one semi standard option,
and you have to look in a table to see where it goes.

Beyond this some BIOS actually store some of their parameters in their
flash chips.  

Eric

Re: [Etherboot-developers] Access CMOS

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

>Is it a good idea on saving some information to the CMOS? Does anyone
>ever written any code to access the CMOS using etherboot? Such as the
>Admin password and other BIOS settings?

Once you have booted your OS, a user program should be able to do what
you want with the CMOS memory, so it's not something Etherboot needs to
do. In Linux you can include the nvram driver. Where it is specified how
the password etc are stored in the NVRAM, I have no idea.

[Etherboot-developers] Access CMOS

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

Is it a good idea on saving some information to the CMOS? Does anyone
ever written any code to access the CMOS using etherboot? Such as the
Admin password and other BIOS settings?

Thanks.

Re: [Etherboot-developers] -oformat vs --oformat

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

> Old ld from binutils supports both: -oformat and --oformat while new
> version
> supports only --oformat option. Patch to fix etherboot/mknbi included
> (similar
> change was done in kernel's makefiles)...
> 
> Please apply.

Thanks, will apply.

------------------------------------------------------
This mail sent via NLC WebMail: http://www.nlc.net.au/

[Etherboot-developers] -oformat vs --oformat

[Arkadiusz M. <mi...@pl...>]

Old ld from binutils supports both: -oformat and --oformat while new version
supports only --oformat option. Patch to fix etherboot/mknbi included (similar
change was done in kernel's makefiles)...

Please apply.

diff -urN etherboot-5.0.0.org/src/Config etherboot-5.0.0/src/Config
--- etherboot-5.0.0.org/src/Config	Wed May  2 11:12:05 2001
+++ etherboot-5.0.0/src/Config	Wed May  2 11:13:36 2001
@@ -245,5 +245,5 @@
 CFLAGS32+=	-Wall -W -Wno-format -Wno-unused
 ASFLAGS32=
 LDFLAGS32+=	-N -Ttext $(RELOCADDR) -e _start
-LDBINARY32=	-oformat binary		# flag for headerless binary
+LDBINARY32=	--oformat binary		# flag for headerless binary
 LIBC32=					# not needed


diff -urN mknbi-1.2.org/Makefile mknbi-1.2/Makefile
--- mknbi-1.2.org/Makefile	Wed May  2 11:41:04 2001
+++ mknbi-1.2/Makefile	Wed May  2 11:41:33 2001
@@ -76,17 +76,17 @@
 
 # New 32-bit first stage setup program
 first32.linux:	start32.o first32.o printf.o
-	$(LD) -N -Ttext $(FIRSRELOC) -e _start -oformat binary -o $@ start32.o first32.o printf.o
+	$(LD) -N -Ttext $(FIRSRELOC) -e _start --oformat binary -o $@ start32.o first32.o printf.o
 	@if [ `wc -c < $@` -gt 4096 ]; then echo Binary too large; fi
 
 # New 32-bit first stage protected mode call setup program
 first32pm.linux:	start32pm.o first32pm.o printf.o
-	$(LD) -N -Ttext $(FIRSRELOC) -e _start -oformat binary -o $@ start32pm.o first32pm.o printf.o
+	$(LD) -N -Ttext $(FIRSRELOC) -e _start --oformat binary -o $@ start32pm.o first32pm.o printf.o
 	@if [ `wc -c < $@` -gt 4096 ]; then echo Binary too large; fi
 
 # New 32-bit first stage ELF setup program
 first32elf.linux:	start32pm.o first32elf.o printf.o
-	$(LD) -N -Ttext $(FIRSRELOC) -e _start -oformat binary -o $@ start32pm.o first32elf.o printf.o
+	$(LD) -N -Ttext $(FIRSRELOC) -e _start --oformat binary -o $@ start32pm.o first32elf.o printf.o
 	@if [ `wc -c < $@` -gt 4096 ]; then echo Binary too large; fi
 
 start32.o:	start32.S
@@ -135,11 +135,11 @@
 
 # Menu first stage program
 menu:	startmenu.o menu.o string.o printf.o ansiesc.o
-	$(LD) -N -Ttext $(MENURELOC) -e _start -oformat binary -o $@ startmenu.o menu.o string.o printf.o ansiesc.o
+	$(LD) -N -Ttext $(MENURELOC) -e _start --oformat binary -o $@ startmenu.o menu.o string.o printf.o ansiesc.o
 
 # Another menu program, this one simpler
 menu-simple:	startmenu.o menu-simple.o string.o printf.o ansiesc.o
-	$(LD) -N -Ttext $(MENURELOC) -e _start -oformat binary -o $@ startmenu.o menu-simple.o string.o printf.o ansiesc.o
+	$(LD) -N -Ttext $(MENURELOC) -e _start --oformat binary -o $@ startmenu.o menu-simple.o string.o printf.o ansiesc.o
 
 startmenu.o:	startmenu.S
 	gcc -E -DRELOC=$(MENURELOC) $(OLDGAS) startmenu.S | $(AS) -o startmenu.o

-- 
Arkadiusz Miśkiewicz, AM2-6BONE    [ PLD GNU/Linux IPv6 ]
http://www.t17.ds.pwr.wroc.pl/~misiek/ipv6/   [ enabled ]

[Etherboot-developers] Mknbi 1.2-1 (production) released

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

I have released Mknbi 1.2-1 at http://etherboot.sourceforge.net

Changes in 1.2-1 are:

+ A debugging statement left behind in disnbi.pl, tsk.

+ Support setup.S header version 0x0202 where parameter string pointer
is 32-bit pointer.

+ Put mknbi version into vendor string so that it will be in image.

+ Derive version number of mknbi.pl and first32.c from VERSION in Makefile.

+ Replace 0x9000 by $relocseg, and add support for placement of Linux
segments at 0x90000 and 0x80000 upwards.

+ Makefile now makes 2 more versions of first32{,pm,elf}.linux for
placement at 0x92200 and 0x82200.

The two main changes are support for header version 0x0202 (2.4 kernels)
and support for Etherboot relocation to 0x84000.