etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] Re: failed

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

On 11/3/2000 1:23 AM Ken Yap ke...@nl... wrote:
>Or I could do this fix, which would forestall this error in future:
>Change all #ifdef MOTD to #if defined(MOTD) && defined(IMAGE_MENU).

Sounds like a plan.  There are probably other dependencies that should be 
checked as well, and I can probably do a bit more sanity checking in 
rom-o-matic's parameter selection code.  Right now, I allow the user to 
combine options any way they choose, and pass them right to make and let 
it decide, which may in fact be more right than wrong.

Re: [Etherboot-developers] Re: Disk on chip work-arounds

[Garth A. <ga...@cc...>]

Ken Yap wrote:
> 
> >Thanks Ken
> >
> >Please email the list of instructions. The kernel
> >version in use is based on 2.2.12 with patches
> >applied for M-Systems disk on chip and ext2
> >filesystem compression.
> 
> I'll mail them to you late Saturday or Sunday. You realise they are not
> precise instructions but more like general leads to follow with no
> guarantee of success?

Sure do! I appreciate any help I can get with this.

Re: [Etherboot-developers] Re: Disk on chip work-arounds

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

>Thanks Ken
>
>Please email the list of instructions. The kernel
>version in use is based on 2.2.12 with patches
>applied for M-Systems disk on chip and ext2
>filesystem compression.

I'll mail them to you late Saturday or Sunday. You realise they are not
precise instructions but more like general leads to follow with no
guarantee of success?

Re: [Etherboot-developers] Re: failed

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

>>#ifdef  IMAGE_MENU
>>extern char *motd[RFC1533_VENDOR_NUMOFMOTD];
>>...
>>
>>Is it possible to do MOTD without IMAGE_MENU?  If so, it might make sense 
>>to put the *motd buffer under another conditional, or possibly define 
>>IMAGEMENU "with extreme prejudice" :-)  
>
>Or I could do this fix, which would forestall this error in future:
>
>Change all #ifdef MOTD to #if defined(MOTD) && defined(IMAGE_MENU).

Well it looks like that extern declaration is bracketed by the wrong
ifdef. I've put it inside a #ifdef MOTD now. One more bug fixed for
4.6.11.

Re: [Etherboot-developers] Re: failed

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

>For Etherboot Developers, in etherboot.h is the following conditional:
>
>#ifdef  IMAGE_MENU
>extern char *motd[RFC1533_VENDOR_NUMOFMOTD];
>...
>
>Is it possible to do MOTD without IMAGE_MENU?  If so, it might make sense 
>to put the *motd buffer under another conditional, or possibly define 
>IMAGEMENU "with extreme prejudice" :-)  

Or I could do this fix, which would forestall this error in future:

Change all #ifdef MOTD to #if defined(MOTD) && defined(IMAGE_MENU).

Re: [Etherboot-developers] Etherboot as a PnP ROM

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

>It's an 82558 that the vendor is integrating into a Phoenix bios.
>Sure, it worked fine with the floppy and it works fine if we integrate
>it into an Award bios as an ISA rom but not as a PnP rom.  We don't
>have the tools to integrate it into Phoenix in-house.  The part I
>really don't understand is the vendor complaint that the checksum is
>invalid.  

Quite a few people have been using Etherboot PnP ROMs. AFAIK any ROM
plugged into a PCI NIC would have to be a PnP ROM since these ROMs don't
occupy any memory area until they are enabled. I don't know what is
required of motherboard ROMs.  Can you get them to be more specific
about what part of the PCI PnP spec the ROM does not satisfy? Phoenix
co-developed the spec so they should know about this.

Re: [Etherboot-developers] Etherboot as a PnP ROM

[Matt H. <mbh...@ie...>]

> >Is anyone successfully using Etherboot as a PnP bootrom?  Up to this
> >point, we were using Etherboot only as an "ISA rom" and it works fine.
> >However, we sent a rom image to a vendor to integrate into the BIOS
> >as a PnP rom and they complained that the checksum was invalid.  We
> >then tried to integrate it into Award BIOS ourselves as a PnP rom  and
> >we were also unsuccessful.  Has anyone done this?
> 
> Yes, it works fine with quite a few drivers, I'm booting from a Tulip
> clone. Another example, a friend of mine has integrated the rtl8139
> driver into an Award BIOS. Which one were you trying to make a PnP ROM,
> was this the 82559ER? I assume it works ok from floppy, so you sent it
> off to the vendor? Remember the ID must also be set correctly in the
> call to makerom, hence the NIC file.

It's an 82558 that the vendor is integrating into a Phoenix bios.
Sure, it worked fine with the floppy and it works fine if we integrate
it into an Award bios as an ISA rom but not as a PnP rom.  We don't
have the tools to integrate it into Phoenix in-house.  The part I
really don't understand is the vendor complaint that the checksum is
invalid.  

I am using an old version of Etherboot (4.4.0) but I compared the
checksum generation code with the current version and saw no
differences (in makerom.c and loader.asm).

> BTW, nothing to do with your PnP ROM problem, if you could please try
> this fix to eepro100.c and let me know if 1. it causes any problems you
> didn't have before, 2. if fixes any problems with kernel crashing that
> some people have reported. If I get a no for 1. I will put the fix in
> anyway.
> 
> Replace the empty eepro100_disable with this:
> 
> static void eepro100_disable(struct nic *nic)
> {
>     /* See if this PartialReset solves the problem with interfering with
>        kernel operation after Etherboot hands over. - Ken 20001102 */
>     outl(2, ioaddr + SCBPort);
> }

I haven't seen the problem with the kernel crashing but I will try
this tomorrow and let you know if it causes any side effects.

thanks,

-Matt

[Etherboot-developers] Re: failed

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

On 11/1/2000 10:42 AM John Huggins hu...@tl... wrote:
>Build failed. Status = 2.
>Following is the output from make:

John,
Thanks for your report.  The error you got when you tried to make your 
ROM image was because the MOTD option also requires the IMAGEMENU option 
be selected, which is on by default default.  If you leave it checked, 
and then choose MOTD, all should be well.

For Etherboot Developers, in etherboot.h is the following conditional:

#ifdef  IMAGE_MENU
extern char *motd[RFC1533_VENDOR_NUMOFMOTD];
...

Is it possible to do MOTD without IMAGE_MENU?  If so, it might make sense 
to put the *motd buffer under another conditional, or possibly define 
IMAGEMENU "with extreme prejudice" :-)  

Food for thought.

Regards,

Marty

>make: Entering directory `/tmp/ROMyLsnPp'
>gcc -DNO_DHCP_SUPPORT -DMOTD -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOVERO
>M -DBACKOFF_LIMIT=7 -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03 -DTRY_
>FLOPPY_FIRST=0 -O2 -g -fstrength-reduce -fomit-frame-pointer -m386 -malign-j
>umps=1 -malign-loops=1 -malign-functions=1 -Wall -W -Wno-format -Wno-unused 
>-DVERSION=\"4.6.10\" -DRELOC=0x98000  -DINCLUDE_3C90X -o bin32/3c90x.o -c
>3c90x.c
>gcc -DNO_DHCP_SUPPORT -DMOTD -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOVERO
>M -DBACKOFF_LIMIT=7 -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03 -DTRY_
>FLOPPY_FIRST=0 -O2 -g -fstrength-reduce -fomit-frame-pointer -m386 -malign-j
>umps=1 -malign-loops=1 -malign-functions=1 -Wall -W -Wno-format -Wno-unused 
>-DVERSION=\"4.6.10\" -DRELOC=0x98000  -DINCLUDE_3C90X -o
>bin32/config-3c90x.o -c config.c
>gcc -DNO_DHCP_SUPPORT -DMOTD -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOVERO
>M -DBACKOFF_LIMIT=7 -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03 -DTRY_
>FLOPPY_FIRST=0 -O2 -g -fstrength-reduce -fomit-frame-pointer -m386 -malign-j
>umps=1 -malign-loops=1 -malign-functions=1 -Wall -W -Wno-format -Wno-unused 
>-DVERSION=\"4.6.10\" -DRELOC=0x98000  -o bin32/pci.o -c pci.c
>gcc -E -DNO_DHCP_SUPPORT -DMOTD -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOV
>EROM -DBACKOFF_LIMIT=7 -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03 -DT
>RY_FLOPPY_FIRST=0 -O2 -g -fstrength-reduce -fomit-frame-pointer -m386 -malig
>n-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W -Wno-format -Wno-unus
>ed -DVERSION=\"4.6.10\" -DRELOC=0x98000  start32.S | as  -o bin32/start32.o
>gcc -DNO_DHCP_SUPPORT -DMOTD -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOVERO
>M -DBACKOFF_LIMIT=7 -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03 -DTRY_
>FLOPPY_FIRST=0 -O2 -g -fstrength-reduce -fomit-frame-pointer -m386 -malign-j
>umps=1 -malign-loops=1 -malign-functions=1 -Wall -W -Wno-format -Wno-unused 
>-DVERSION=\"4.6.10\" -DRELOC=0x98000  -o bin32/main.o -c main.c
>gcc -DNO_DHCP_SUPPORT -DMOTD -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOVERO
>M -DBACKOFF_LIMIT=7 -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03 -DTRY_
>FLOPPY_FIRST=0 -O2 -g -fstrength-reduce -fomit-frame-pointer -m386 -malign-j
>umps=1 -malign-loops=1 -malign-functions=1 -Wall -W -Wno-format -Wno-unused 
>-DVERSION=\"4.6.10\" -DRELOC=0x98000  -o bin32/osloader.o -c osloader.c
>gcc -DNO_DHCP_SUPPORT -DMOTD -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOVERO
>M -DBACKOFF_LIMIT=7 -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03 -DTRY_
>FLOPPY_FIRST=0 -O2 -g -fstrength-reduce -fomit-frame-pointer -m386 -malign-j
>umps=1 -malign-loops=1 -malign-functions=1 -Wall -W -Wno-format -Wno-unused 
>-DVERSION=\"4.6.10\" -DRELOC=0x98000  -o bin32/nfs.o -c nfs.c
>gcc -DNO_DHCP_SUPPORT -DMOTD -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOVERO
>M -DBACKOFF_LIMIT=7 -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03 -DTRY_
>FLOPPY_FIRST=0 -O2 -g -fstrength-reduce -fomit-frame-pointer -m386 -malign-j
>umps=1 -malign-loops=1 -malign-functions=1 -Wall -W -Wno-format -Wno-unused 
>-DVERSION=\"4.6.10\" -DRELOC=0x98000  -o bin32/misc.o -c misc.c
>gcc -DNO_DHCP_SUPPORT -DMOTD -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOVERO
>M -DBACKOFF_LIMIT=7 -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03 -DTRY_
>FLOPPY_FIRST=0 -O2 -g -fstrength-reduce -fomit-frame-pointer -m386 -malign-j
>umps=1 -malign-loops=1 -malign-functions=1 -Wall -W -Wno-format -Wno-unused 
>-DVERSION=\"4.6.10\" -DRELOC=0x98000  -o bin32/ansiesc.o -c ansiesc.c
>gcc -DNO_DHCP_SUPPORT -DMOTD -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOVERO
>M -DBACKOFF_LIMIT=7 -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03 -DTRY_
>FLOPPY_FIRST=0 -O2 -g -fstrength-reduce -fomit-frame-pointer -m386 -malign-j
>umps=1 -malign-loops=1 -malign-functions=1 -Wall -W -Wno-format -Wno-unused 
>-DVERSION=\"4.6.10\" -DRELOC=0x98000  -o bin32/bootmenu.o -c bootmenu.c
>bootmenu.c: In function `show_motd':
>bootmenu.c:35: `motd' undeclared (first use in this function)
>bootmenu.c:35: (Each undeclared identifier is reported only once
>bootmenu.c:35: for each function it appears in.)
>bootmenu.c:38: warning: left-hand operand of comma expression has no effect
>bootmenu.c:32: warning: `ptr' might be used uninitialized in this function
>bootmenu.c:33: warning: `j' might be used uninitialized in this function
>make: *** [bin32/bootmenu.o] Error 1
>make: Leaving directory `/tmp/ROMyLsnPp'
>Please let us know that this happened.
>
>*******************************************
>John Huggins
>
>Transmitter Location Systems, LLC
>14120 Parke Long Court, 103
>Chantilly, Virginia 20151
>703-227-8435
>703-968-8808 fax
>hu...@tl...
>http://www.tls2000.com/


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

[Etherboot-developers] Re: Disk on chip work-arounds

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

[Further discussion directed to eth...@li...,
please subscribe if you are not already on the list.]

>Hi Ken
>
>I saw this posting which sums up my problem exactly. I am
>using etherboot 4.6.10 and wonder if any of the work-arounds
>that you (might of) provided to mar...@hp... worked?
>
>		"By: ken_yap ( Ken Yap ) 
>                           RE: DiskOnChip [ reply ]   
>                         2000-Jul-05 07:14 
>                         This is a hard one and gets asked
>often. 
>                         The problem appears to be that DOC
>uses some 
>                         memory just under 0xA0000 and this
>clashes 
>                         with Etherboot use. 
>                         You can't just redefine RELOCADDR,
>this has 
>                         only the effect of shifting the
>base address 
>                         of the code down to 0x96000 or
>0x94000 to 
>                         allow for more features, but the
>clash still 
>                         exists. 
>                         The solution may be to move
>Etherboot to 
>                         0x88000 and not load kernels larger
>than 
>                         544kB or to load bzImage kernels
>(above 1MB). 
>                         To do this, the formulas in the
>assembler 
>                         files need to be edited. 
>                         Another wrinkle is that the
>decompressor will 
>                         need to be moved down to 0x70000
>but at least 
>                         this doesn't affect the kernel
>size. 
>                         If you are willing to experiment,
>contact me 
>                         by email and I will give you some
>things to 
>                         try"

A couple of versions ago, I put in some small changes to support running
from the 0x80000 segment, but it still uses some memory areas above
0x90000.  I don't have DOC, but the changes didn't break any existing
usage.  Subsequently Stuart Lynne (sorry if my memory's got your name or
affiliation wrong) of Lineo communicated to me privately that DOC uses
areas above 0x90000 and that to have any chance of success, everything
would have to be moved out of 0x90000, probably down to 0x80000.  This
would also include areas above 0x90000 used by kernel startup segment.
Apparently there are patches floating around the Linux kernel world for
this. The details are my email at home, which I can post later.

If you are serious about this and are willing to invest some time in
hacking the code, I'm willing to talk you through this. But you would
have to do the experimentation, as I don't have DOC.

Re: [Etherboot-developers] Etherboot as a PnP ROM

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

>Is anyone successfully using Etherboot as a PnP bootrom?  Up to this
>point, we were using Etherboot only as an "ISA rom" and it works fine.
>However, we sent a rom image to a vendor to integrate into the BIOS
>as a PnP rom and they complained that the checksum was invalid.  We
>then tried to integrate it into Award BIOS ourselves as a PnP rom  and
>we were also unsuccessful.  Has anyone done this?

Yes, it works fine with quite a few drivers, I'm booting from a Tulip
clone. Another example, a friend of mine has integrated the rtl8139
driver into an Award BIOS. Which one were you trying to make a PnP ROM,
was this the 82559ER? I assume it works ok from floppy, so you sent it
off to the vendor? Remember the ID must also be set correctly in the
call to makerom, hence the NIC file.

Add this line to NIC after the eepro100 one:

82559er         eepro100        0x8086,0x1209

Then make bin32/82559er.lzrom or .rom as you wish.

BTW, nothing to do with your PnP ROM problem, if you could please try
this fix to eepro100.c and let me know if 1. it causes any problems you
didn't have before, 2. if fixes any problems with kernel crashing that
some people have reported. If I get a no for 1. I will put the fix in
anyway.

Replace the empty eepro100_disable with this:

static void eepro100_disable(struct nic *nic)
{
    /* See if this PartialReset solves the problem with interfering with
       kernel operation after Etherboot hands over. - Ken 20001102 */
    outl(2, ioaddr + SCBPort);
}

Re: [Etherboot-developers] Intel 82559ER

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

>I ran across a new (to me) intel chip today.  It's labeled 82559ER but
>the Etherboot driver wouldn't recognized it.  Etherboot works fine on
>the 82559 and I happened to notice that the 82559 has a PCI Device ID
>of 0x1229 (same as the 82558) but the 82559ER had an ID of 0x1209.  I
>took a shot in the dark and added the new device ID to the EEPRO100
>section of config.c.  Etherboot then worked just fine with the
>82559ER.
>
>Just thought you'd like to know.

Thanks very much. I will add that ID into the source.

[Etherboot-developers] Etherboot as a PnP ROM

[Matt H. <mbh...@ie...>]

Is anyone successfully using Etherboot as a PnP bootrom?  Up to this
point, we were using Etherboot only as an "ISA rom" and it works fine.
However, we sent a rom image to a vendor to integrate into the BIOS
as a PnP rom and they complained that the checksum was invalid.  We
then tried to integrate it into Award BIOS ourselves as a PnP rom  and
we were also unsuccessful.  Has anyone done this?

thanks,

-Matt

[Etherboot-developers] Intel 82559ER

[Matt H. <mbh...@ie...>]

I ran across a new (to me) intel chip today.  It's labeled 82559ER but
the Etherboot driver wouldn't recognized it.  Etherboot works fine on
the 82559 and I happened to notice that the 82559 has a PCI Device ID
of 0x1229 (same as the 82558) but the 82559ER had an ID of 0x1209.  I
took a shot in the dark and added the new device ID to the EEPRO100
section of config.c.  Etherboot then worked just fine with the
82559ER.

Just thought you'd like to know.

-Matt

Re: [Etherboot-developers] Re: Intel 82559 chip - work ?

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

>We should have a wish-list or something where ideas like this go.  I try 
>to remember things like this, but it would be easier to consult a list.  
>One of these weekends I may get to the SiS900 driver, for example :-)

I've entered it into the Support Manager. It may not sound like a
support problem but I think the definition of support is broad enough,
it's just a problem ticket system that we need in the final analysis.

Re: [Etherboot-developers] Re: Intel 82559 chip - work ?

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

>We should have a wish-list or something where ideas like this go.  I try 
>to remember things like this, but it would be easier to consult a list.  
>One of these weekends I may get to the SiS900 driver, for example :-)

I'll see what I can do with the Task Manager in Sourceforge, it may be
for this sort of thing.

Re: [Etherboot-developers] Re: Intel 82559 chip - work ?

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

On 10/31/2000 9:21 PM Ken Yap ke...@nl... wrote:
>The EEPRO100 NIC uses this chip, and there's an Etherboot driver, and
>AFAIK it generally works although there have been sporadic reports of
>problems, unclear whether due to chip revisions or BIOS versions or
>what. One thing I'm not happy about is the use of a counting loop to
>implement the timeout in the transmit routine, it's processor speed
>dependent and should be changed to use the new hardware timer routines.

We should have a wish-list or something where ideas like this go.  I try 
to remember things like this, but it would be easier to consult a list.  
One of these weekends I may get to the SiS900 driver, for example :-)

Marty

[Etherboot-developers] Re: Intel 82559 chip - work ?

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

>Now a question to the etherboot hackers:
>
>Is this chip working propably with etherboot (current version) ?
>Are there any problems ?

The EEPRO100 NIC uses this chip, and there's an Etherboot driver, and
AFAIK it generally works although there have been sporadic reports of
problems, unclear whether due to chip revisions or BIOS versions or
what. One thing I'm not happy about is the use of a counting loop to
implement the timeout in the transmit routine, it's processor speed
dependent and should be changed to use the new hardware timer routines.

Re: [Etherboot-developers] Porting Etherboot to MIPS

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

> Only that you have enough hair on your head to start with. :-)
> 
> The architecture of Etherboot is shot through with x86isms, including:
> the execution mechanism, the use of various memory areas, the hook into
> the PCI subsystem, and others I've probably forgot.

My gut feeling is, that once all of the assembly code has been
ported, the C code is not too bad. Some features will probably
have to be turned off for the initial port, but the general
concept should work. I'd very much like to know though, which
problems do come up if anybody attempts this. I would certainly
allocate a good chunk of time to tackle this problem. The devil
(as always) is in the details.


Markus

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

Re: [Etherboot-developers] Porting Etherboot to MIPS

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

> I am in the position where I need to use bootp to load a Linux kernel onto a diskless embedded system with a MIPS processor.  There seems to only be 2 main tools to do this: Etherboot and Netboot.  However, both only support the x86 architecture.  Since use of this type of tool is imperative to my project, I have decided to port Etherboot over to the MIPS architecture.  I have my own MIPS specific boot loader.  I am hoping that the boot loader is the only part of Etherboot that is x86 specific.  Is there any reason that I should not attempt to port this over to MIPS?

If you feel comfortable writing MIPS assembly code, and if you have
a good understanding of how the bootstrapping code has to look like,
then I don't see why you couldn't port etherboot. You will probably
have to rewrite both the assembly glue code, that is neccessary to
use C from within a BIOS ROM, and you will have to rewrite
mknbi-linux for the second-stage loader. Hopefully, the C code is
sufficiently portable to not require any major changes.


Markus

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

Re: [Etherboot-developers] Porting Etherboot to MIPS

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

>I am in the position where I need to use bootp to load a Linux kernel
>onto a diskless embedded system with a MIPS processor.  There seems to
>only be 2 main tools to do this: Etherboot and Netboot.  However, both
>only support the x86 architecture.  Since use of this type of tool is
>imperative to my project, I have decided to port Etherboot over to the
>MIPS architecture.  I have my own MIPS specific boot loader.  I am hoping
>that the boot loader is the only part of Etherboot that is x86 specific. 
>Is there any reason that I should not attempt to port this over to MIPS?

Only that you have enough hair on your head to start with. :-)

The architecture of Etherboot is shot through with x86isms, including:
the execution mechanism, the use of various memory areas, the hook into
the PCI subsystem, and others I've probably forgot. Portability for
Etherboot could not be achived in the past because there were no other
targets available to port to. Or desire to port. (Read: This is a hobby
project and x86 machines were all I could afford.) While I encourage you
to try, do not expect that it will be straightforward. Please feel free
to yell for clarification or help. It should be interesting at least to
know where the architecture dependencies are.

[Etherboot-developers] Porting Etherboot to MIPS

[Bob V. G. <rva...@na...>]

Greetings...

I am in the position where I need to use bootp to load a Linux kernel =
onto a diskless embedded system with a MIPS processor.  There seems to =
only be 2 main tools to do this: Etherboot and Netboot.  However, both =
only support the x86 architecture.  Since use of this type of tool is =
imperative to my project, I have decided to port Etherboot over to the =
MIPS architecture.  I have my own MIPS specific boot loader.  I am =
hoping that the boot loader is the only part of Etherboot that is x86 =
specific.  Is there any reason that I should not attempt to port this =
over to MIPS?

Thanks,
Bob

[Etherboot-developers] Problem with gas 2.9.5 in etherboot 4.6.8

[Christoph P. <chr...@do...>]

While compiling etherboot32 in version 4.6.8 I got following error
on Linux RedHat 6.2 (egcs-2.91.66, as 2.9.5)


gcc -E -DMOTD -DIMAGE_MENU -DBACKOFF_LIMIT=7 -DASK_BOOT=3
-DANS_DEFAULT=ANS_NETWORK -O2 -g -fstrength-reduce -fomit-frame-pointer
-m386 -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W
-Wno-format -Wno-unused -DVERSION=\"4.6.8\" -DRELOC=0x98000  start32.S |
as  -o bin32/start32.o
{standard input}: Assembler messages:
{standard input}:323: Error: suffix or operands invalid for `ljmp'
make: *** [bin32/start32.o] Error 1

The problem seem to be the `*' in the LJMPI() macro.
The problem is in the xstart routine. As I saw in the other
parts of the code and the the code 4.6.2, I think, the `*' has
to be removed. In 4.6.2 there was no distinguish between GAS291 and
GAS295 on this line in xstart:



	ADDR32 ljmp	_execaddr-_start


In 4.6.8 this line:

	ADDR32	LJMPI(_execaddr-_start)

with the difference:

#ifdef	GAS291
#define DATA32 data32;
#define ADDR32 addr32;
#define	LJMPI(x)	ljmp	x
#else
#define DATA32 data32
#define ADDR32 addr32
#define	LJMPI(x)	ljmp	*x
#endif

Whatfor the `*' here ?

With friendly regards

	Christoph P.

PS: Without `*' the code builds, but I have not tested it !



-------------------------------------------------------------------------
private:	chr...@do...
company:	chr...@al...

[Etherboot-developers] Stack problem in start32.S

[Paul R. <pau...@lo...>]

Hi,

I just spent some time investigating a reboot problem with a customised
BIOS+Etherboot ROM. The fix really belongs in the BIOS itself (General
Software Embedded BIOS 4.3), but I think it will help add a line of code to
Etherboot.

The scenario is that on selecting "Shutdown & Restart" from Windows 9x the
machine crashes very early in the Etherboot int 19h handler.
The problem turned out to be some spurious value in the upper bits of ESP.
The fix is the instruction:
andl    $0xffff,%esp
just before the first switch from real to protected mode. At least that
fixes it for us.

Anyone else reported a restart problem like this?
--
Paul Robertson
LocSoft Limited
"The key to your embedded solutions"
www.locsoft.com
Phone +44 (0) 1793 784784
Fax     +44 (0) 1793 784789

Re: [Etherboot-developers] for gurus ;-) remote boot with tftp'd ramdisk =?iso-8859-1?q?=3F?=

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

> Is it possible to boot a linux kernel over the network __without using NFS___, say using a ramdisk downloaded by tftp ? I don't mind how difficult it could be (kernel hacking,...), either a linux kernel or another *nix btw...
> I have to set up a diskless node for an embedded motherboard which does not need to save any data to disk. If I can get rid of NFS I will be able to set up the boot server on any OS, including windows 9x.

That should work just fine. You can use etherboot's initrd feature
to load a ramdisk. Then just specify this ramdisk as your root device
rather than switching to NFS. You should check the initrd
documentation that comes with the Linux kernel source code.


Markus

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

Re: [Etherboot-developers] for gurus ;-) remote boot with tftp'd ramdisk ?

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

> Is it possible to boot a linux kernel over the network __without using >
NFS___, say using a ramdisk downloaded by tftp ? I don't mind how > difficult it
could be (kernel hacking,...), either a linux kernel or > another *nix btw...
> I have to set up a diskless node for an embedded motherboard which does > not
need to save any data to disk. If I can get rid of NFS I will be > able to set
up the boot server on any OS, including windows 9x.
>
> Any ideas would be greatly appreciated.

Sure, just use an initrd, it's been supported in mknbi for a long time. All the
boot disks for Linux distros use this method. You'd have to read
/usr/src/Documentation/{ramdisk,initrd}.txt to see what magic incantations are
needed to tell the kernel to mount the initrd as the rootFS.

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