etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] Adminstrivia: list archives

[Tania O. <ta...@ce...>]

I for one would like to say thanks to Ken and Marty for their time and
energy.  I haven't been on the list long but I have been impressed by how
responsive they have been to the problems posted here.

I think the person with all the complaints should remember that he didn't
pay any money and that no-one is under any obligation to help him.  Frankly
I hope no-one does since in my opinion such rudeness doesn't deserve to be
rewarded.

[Etherboot-developers] Re: RTL8139 ROM

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

|So you understand the problem clearly:  I have ami, 256 ram that can be
|written to.  I have an rt8139 ethernet card.  I want to make bootp or rarp
|work (linux).  I want an eprom for that card OR reprogram the bios.  The
|module for realtek card is 16K.  HOW do I integrate it????

BTW if you just want to evaluate the technology in 2 hours (I doubt it),
you could buy a ready to go NIC with an Etherboot ROM from the companies
listed under commercial links from the home page.

Re: [Etherboot-developers] RE: [Etherboot-users] Adminstrivia: list archives

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

On 2/13/2001 9:01 PM Bob Andrews bo...@in... wrote:
>The rom-o-matic did not work on win98/IE, all you obtain are small useless
>html files.  It did work under Linux.  I wonder if the links were absolute
>not relative, since I have Apache server w/php on my other machine.

Sigh.  What people (Micro~1 Internet Exploder victims) think they are 
getting is "small useless html files" but in fact if either MIE followed 
specifications and passed the supplied name through (some versions do, 
some do not) or you supplied a name like rtl8139.lzrom yourself, you 
would get a working rom image (or whatever flavor of image you asked 
for).  People get confused and believe that they are actually getting 
html.  I may just tell people to use Netscape for "best results".

>I pulled down the distro from sourceforge, and to be honest the
>documentation was so crappy I did not even bother.  

oh really?

>Why clutter my disk

why indeed.

>when
>I don't know it works (or even what it does), and yes I did read the doc
>files.  You mention that new stuff is on a mailing list, just say how to get
>it easily, or why anyone would care.  

....

>Getting you to complete a sentence is
>like pulling hen's teeth.  Try to finish a thought for once so we don't have
>to make 10 questions out of each phrase you spit out.  If I actually cared,
>I'd have to ask you what you meant (ie., English) or just guess where it was
>and plod along.  My expectations are that you would reply with an irrelevant
>or totally usely cryptic remark that solves nothing.

Well, this is an interesting strategy... you need help, so you brazenly 
insult the volunteer developers.  Better yet, you insult the primary 
maintainer! I have to say, Sir, that it is a "novel" approach;  Perhaps 
it just doesn't translate well cross-culturally.  I have my doubts about 
the effectiveness of this particular strategy...

>What we are trying to do here should be simple (under 2 hours) - but you
>make it into a full-time effort for a week.  If one have to read every line
>of someone's code to use it, it's trash - don't bother.

Does this mean you're giving up and going away? :-)

>So you understand the problem clearly:  I have ami, 256 ram that can be
>written to.  I have an rt8139 ethernet card.  I want to make bootp or rarp
>work (linux).  I want an eprom for that card OR reprogram the bios.  The
>module for realtek card is 16K.  HOW do I integrate it????

Just so *you* understand the problem clearly, this is a volunteer effort. 
 We spend our spare time (and money) supporting this project.  Your 
comments would make me angry if they didn't make me laugh first.

And may I say, that your command of language is not that great either. 
The last paragraph makes little sense to me.  I think you are saying that 
you have an AMI BIOS, you have either 256MB or 256KB of RAM/FLASH.  You 
seem to be wanting to burn a ROM for your card, or you want to add code 
to your AMI BIOS.

Look, I'd try to help you, but I don't like the way you talk to Ken.  So 
apologize publicly (and in good English), and maybe I'll change my mind. 
:-)

Marty

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

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

Re: [Etherboot-developers] how to get RTL8139 ROM

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

Bob,

Now that I have counted to 100 after your accusations, let me say that
you misunderstand the nature of the location of the knowledge in this
project. I DO NOT HAVE ALL OF IT, and I say so in the documentation.  I
DO NOT have all the possible variations of hardware that people have
tried Etherboot on. I have not personally flashed a RTL8139 ROM image
Etherboot into an Award BIOS, a friend did it for me, following the
instructions contributed by Dirk and other users. rom-o-matic.net is a
site was set up by Marty Connor, another kind contributor.

This is why I ask people to subscribe to the mailing list and ask their
questions there. I hope that you can get some useful answers from the
list, but if this method of getting information does not suit you, I'm
sorry, but this the nature of the territory.

Re: [Etherboot-developers] RE: [Etherboot-users] Adminstrivia: list archives

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

|The rom-o-matic did not work on win98/IE, all you obtain are small useless
|html files.  It did work under Linux.  I wonder if the links were absolute
|not relative, since I have Apache server w/php on my other machine.

Apparently IE assumes unknown file types are HTML. I'm told that they
do contain the right content, you just have to rename them but I don't
run IE so I can't confirm.

As for the other "deficiencies", we try our best with the spare time
that we have. It's a volunteer project so feel free to contribute
improvements.

[Etherboot-developers] RE: [Etherboot-users] Adminstrivia: list archives

[Bob A. <bo...@in...>]

Ken,

The rom-o-matic did not work on win98/IE, all you obtain are small useless
html files.  It did work under Linux.  I wonder if the links were absolute
not relative, since I have Apache server w/php on my other machine.

I pulled down the distro from sourceforge, and to be honest the
documentation was so crappy I did not even bother.  Why clutter my disk when
I don't know it works (or even what it does), and yes I did read the doc
files.  You mention that new stuff is on a mailing list, just say how to get
it easily, or why anyone would care.  Getting you to complete a sentence is
like pulling hen's teeth.  Try to finish a thought for once so we don't have
to make 10 questions out of each phrase you spit out.  If I actually cared,
I'd have to ask you what you meant (ie., English) or just guess where it was
and plod along.  My expectations are that you would reply with an irrelevant
or totally usely cryptic remark that solves nothing.

What we are trying to do here should be simple (under 2 hours) - but you
make it into a full-time effort for a week.  If one have to read every line
of someone's code to use it, it's trash - don't bother.

So you understand the problem clearly:  I have ami, 256 ram that can be
written to.  I have an rt8139 ethernet card.  I want to make bootp or rarp
work (linux).  I want an eprom for that card OR reprogram the bios.  The
module for realtek card is 16K.  HOW do I integrate it????


-----Original Message-----
From: eth...@li...
[mailto:eth...@li...]On Behalf Of Ken Yap
Sent: Tuesday, February 13, 2001 4:56 PM
To: eth...@li...;
eth...@li...
Subject: [Etherboot-users] Adminstrivia: list archives

A couple of subscribers have pointed out to me that the archive link
from the page Project Info -> Mailing Lists is most up to date and
different from the one you get when you go to the Mailman web interface,
which goes no further than end Dec 2000. I'm asking Sourceforge for
clarification, it seems to be a side effect of their recent relocation.
In the meantime, bear in mind that the most up to date archives are
accessed from the Mailing List web page.

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

[Etherboot-developers] Adminstrivia: list archives

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

A couple of subscribers have pointed out to me that the archive link
from the page Project Info -> Mailing Lists is most up to date and
different from the one you get when you go to the Mailman web interface,
which goes no further than end Dec 2000. I'm asking Sourceforge for
clarification, it seems to be a side effect of their recent relocation.
In the meantime, bear in mind that the most up to date archives are
accessed from the Mailing List web page.

Re: [Etherboot-developers] Is it possible to hardwire paths to kernel&root?

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

|I don't want to hardwire any client IP addresses. Just the address of
|then TFTP-server.
|I can recompile the etherboot, if you point out where should I put the
|tftp-servername and path to kernel.

You'd have to hack the code yourself to make it use a hardwired tftp IP
address, it's not as simple as changing one line.  It's not a change I'm
interested in, so you're on your own.  The fallback kernel path is
controlled by a #define.

|> A better idea would be to use the Vendor Class Identifier mechanism to
|> partition bootp/dhcp domains so that you can run a Linux server
|> alongside the NT server.
|Yes it would be, but I can't use it :(

Why not?

[Etherboot-developers] Fwd: compilation error in 4.7.17

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

Here's a bug report from rom-o-matic.net.  It may have been fixed, but I 
thought I'd pass it along.  It seems to be in 4.7.17.  Any ideas?

---------------- Begin Forwarded Message ----------------
Date:        2/13/2001 5:06 PM
Received:    2/13/2001 5:33 PM
From:        Christian Kissner, ch...@to...
To:          web...@en...

I've been playing with options, I think this was caused by MULTIBOOT.

Forgive me if I'm pestering you and should have sent this to
ke...@et... or so.


http://rom-o-matic.net/4.7.17/build.php3?F=05060130711ANS_NETWORK0810160171
7
181924050x3F82504960026040x033201033&nic=lancepci&ofmt=Floppy+Bootable+ROM+
I
mage&A=Get+ROM



Following is the output from make:


make: Entering directory `/tmp/ROMXzxnuf'
gcc -DMOTD -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DEMERGENCYDISKBOOT 
-DBACK
OFF_LIMIT=7 -DAOUT_IMAGE -DELF_IMAGE -DIMAGE_MULTIBOOT -DCOMCONSOLE=0x3F8 
-D
CONSPEED=9600 -DCOMPARM=0x03 -DTRY_FLOPPY_FIRST=0 -DCONFIG_PCI_DIRECT -O2 
-g
 -fstrength-reduce -fomit-frame-pointer -m386 -malign-jumps=1 
-malign-loops=
1 -malign-functions=1 -Wall -W -Wno-format -Wno-unused -DVERSION_MAJOR=4 
-DV
ERSION_MINOR=7 -DVERSION=\"4.7.17\" -DRELOC=0x98000  -DINCLUDE_LANCE		 -o
bin32/lance.o -c lance.c
gcc -DMOTD -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DEMERGENCYDISKBOOT 
-DBACK
OFF_LIMIT=7 -DAOUT_IMAGE -DELF_IMAGE -DIMAGE_MULTIBOOT -DCOMCONSOLE=0x3F8 
-D
CONSPEED=9600 -DCOMPARM=0x03 -DTRY_FLOPPY_FIRST=0 -DCONFIG_PCI_DIRECT -O2 
-g
 -fstrength-reduce -fomit-frame-pointer -m386 -malign-jumps=1 
-malign-loops=
1 -malign-functions=1 -Wall -W -Wno-format -Wno-unused -DVERSION_MAJOR=4 
-DV
ERSION_MINOR=7 -DVERSION=\"4.7.17\" -DRELOC=0x98000  -DINCLUDE_LANCE -o
bin32/config-lance.o -c config.c
gcc -DMOTD -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DEMERGENCYDISKBOOT 
-DBACK
OFF_LIMIT=7 -DAOUT_IMAGE -DELF_IMAGE -DIMAGE_MULTIBOOT -DCOMCONSOLE=0x3F8 
-D
CONSPEED=9600 -DCOMPARM=0x03 -DTRY_FLOPPY_FIRST=0 -DCONFIG_PCI_DIRECT -O2 
-g
 -fstrength-reduce -fomit-frame-pointer -m386 -malign-jumps=1 
-malign-loops=
1 -malign-functions=1 -Wall -W -Wno-format -Wno-unused -DVERSION_MAJOR=4 
-DV
ERSION_MINOR=7 -DVERSION=\"4.7.17\" -DRELOC=0x98000  -o bin32/pci.o -c 
pci.c
gcc -E -DMOTD -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DEMERGENCYDISKBOOT 
-DB
ACKOFF_LIMIT=7 -DAOUT_IMAGE -DELF_IMAGE -DIMAGE_MULTIBOOT 
-DCOMCONSOLE=0x3F8
 -DCONSPEED=9600 -DCOMPARM=0x03 -DTRY_FLOPPY_FIRST=0 -DCONFIG_PCI_DIRECT 
-O2
 -g -fstrength-reduce -fomit-frame-pointer -m386 -malign-jumps=1 
-malign-loo
ps=1 -malign-functions=1 -Wall -W -Wno-format -Wno-unused 
-DVERSION_MAJOR=4 
-DVERSION_MINOR=7 -DVERSION=\"4.7.17\" -DRELOC=0x98000  start32.S | as  -o
bin32/start32.o
{standard input}: Assembler messages:
{standard input}:327: Warning: indirect ljmp without `*'
gcc -DMOTD -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DEMERGENCYDISKBOOT 
-DBACK
OFF_LIMIT=7 -DAOUT_IMAGE -DELF_IMAGE -DIMAGE_MULTIBOOT -DCOMCONSOLE=0x3F8 
-D
CONSPEED=9600 -DCOMPARM=0x03 -DTRY_FLOPPY_FIRST=0 -DCONFIG_PCI_DIRECT -O2 
-g
 -fstrength-reduce -fomit-frame-pointer -m386 -malign-jumps=1 
-malign-loops=
1 -malign-functions=1 -Wall -W -Wno-format -Wno-unused -DVERSION_MAJOR=4 
-DV
ERSION_MINOR=7 -DVERSION=\"4.7.17\" -DRELOC=0x98000  -o bin32/main.o -c
main.c
gcc -DMOTD -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DEMERGENCYDISKBOOT 
-DBACK
OFF_LIMIT=7 -DAOUT_IMAGE -DELF_IMAGE -DIMAGE_MULTIBOOT -DCOMCONSOLE=0x3F8 
-D
CONSPEED=9600 -DCOMPARM=0x03 -DTRY_FLOPPY_FIRST=0 -DCONFIG_PCI_DIRECT -O2 
-g
 -fstrength-reduce -fomit-frame-pointer -m386 -malign-jumps=1 
-malign-loops=
1 -malign-functions=1 -Wall -W -Wno-format -Wno-unused -DVERSION_MAJOR=4 
-DV
ERSION_MINOR=7 -DVERSION=\"4.7.17\" -DRELOC=0x98000  -o bin32/osloader.o 
-c
osloader.c
osloader.c: In function `elf_download':
osloader.c:447: `kernel' undeclared (first use in this function)
osloader.c:447: (Each undeclared identifier is reported only once
osloader.c:447: for each function it appears in.)
osloader.c:452: warning: unreachable code at beginning of switch statement
osloader.c: In function `os_download':
osloader.c:616: union has no member named `s'
make: *** [bin32/osloader.o] Error 1
make: Leaving directory `/tmp/ROMXzxnuf'



----------------- End Forwarded Message -----------------

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

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

[Etherboot-developers] Flashing EB into BIOS ROM

[Wolf, P. <Wo...@Ul...>]

I am looking for a utility that I can append Etherboot in the BIOS ROM.
Does anybody have information on this.  I found one for AWARD for $3000.  I
am would like one for Award and AMI BIOS.

Thanks 

Paul

Re: [Etherboot-developers] Is it possible to hardwire paths to kernel&root?

[Hannu M. <mar...@pe...>]

On Tue, 13 Feb 2001, ext Ken Yap wrote:

> |What I need is to be able to hardwire
> |	tftp-server
> |	kernel-path
> |into etherboot images. They could be overridden if dhcp-server provide=
s
> |something else.
> |
> |I would especially like if services like "rom-o-matic" would add this
> |their image-generators.
> |Just couple of more lines asking "tftp-server" and "path to kernel".
> |
> |It also would be nice to be able to "hardwire" NFS-server and path to
> |root-image at the same time (I know this info can be put into kernel
> |images).
> |
> |I'd really like to see these features in standard etherboot package, b=
ut
> |if anyone knows how to "hack" these values in, I'd be happy enough...
>
> Firstly the code does not accomodate hardwiring the tftp server address=
,
> you have to get it from bootp or dhcp. I am not in favour of altering
> the code to allow hardwiring IP addresses in ROMs. The fallback bootfil=
e
> path can be changed by a #define but perhaps you should ask if you
> should be compiling this yourself.

I don't want to hardwire any client IP addresses. Just the address of
then TFTP-server.
I can recompile the etherboot, if you point out where should I put the
tftp-servername and path to kernel.
I wouldn't think that adding few #defines and later on overriding them
whatever DHCP/BOOTP-server returns would really break anything...
Especially since you already have the kernel-path "fallback" #define.

> What are you going to boot? You will need a Unix/Linux host if you are
> going to mount NFS filesystems.

I'm going to boot LTSP, but I simply cannot have Linux on every subnet
serving TFTP/dhcp/NFS for LTSP. And I cannot touch network configuration
(helpers, etc). Anyway I already have the LTSP test-environment
up&running, now I just need get some real testers to connect it and
they're not anywhere near my network segment...

I'd like to setup few default boot-images (ie floppies) that people could
use to connect limited number of LTSP servers. Since I cannot touch DHCP
nor network(routers, etc) the only option is to hardwire the names&paths.

> NFS-server and path to root image are not in the ROM, they can be
> changed in the tagged kernel image. rom-o-matic is for making ROM
> images, not tagged kernel images. Again it's best that you build you ow=
n
> development environment in this case.
Kernel is not a problem. I can build necessary kernels&bootimages...

> A better idea would be to use the Vendor Class Identifier mechanism to
> partition bootp/dhcp domains so that you can run a Linux server
> alongside the NT server.
Yes it would be, but I can't use it :(

- Goodi
"The linuX Files -- The Source is Out There."
=F8,=B8=B8,=F8=A4=BA=B0`=B0=BA=A4=F8,=B8=B8,=F8=A4=BA=B0`=B0=BA=A4=F8,=B8=
=B8,=F8=A4=BA=B0`=B0=BA=A4=F8,=B8=B8,=F8=A4=BA=B0`=B0=BA=A4=F8=A4=BA=B0`=B0=
=BA=A4=F8,=B8=B8,=F8=A4=BA=B0

Re: [Etherboot-developers] Is it possible to hardwire paths to kernel&root?

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

|What I need is to be able to hardwire
|	tftp-server
|	kernel-path
|into etherboot images. They could be overridden if dhcp-server provides
|something else.
|
|I would especially like if services like "rom-o-matic" would add this
|their image-generators.
|Just couple of more lines asking "tftp-server" and "path to kernel".
|
|It also would be nice to be able to "hardwire" NFS-server and path to
|root-image at the same time (I know this info can be put into kernel
|images).
|
|I'd really like to see these features in standard etherboot package, but
|if anyone knows how to "hack" these values in, I'd be happy enough...

Firstly the code does not accomodate hardwiring the tftp server address,
you have to get it from bootp or dhcp. I am not in favour of altering
the code to allow hardwiring IP addresses in ROMs. The fallback bootfile
path can be changed by a #define but perhaps you should ask if you
should be compiling this yourself. What are you going to boot? You will
need a Unix/Linux host if you are going to mount NFS filesystems.

NFS-server and path to root image are not in the ROM, they can be
changed in the tagged kernel image. rom-o-matic is for making ROM
images, not tagged kernel images. Again it's best that you build you own
development environment in this case.

A better idea would be to use the Vendor Class Identifier mechanism to
partition bootp/dhcp domains so that you can run a Linux server
alongside the NT server.

Re: [Etherboot-developers] Etherboot/GRUB driver for eepro100 - problem in understanding !

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

|I have the problem downloading the OS kernel image to 1MB
|(0x00100000), via GRUB / tftpboot (*** not etherboot here ! ***)
|Booting the same kernel from the disk works !

Before you go off chasing bugs in eepro100.c, make sure that the source
in GRUB is recent. There was a bug fixed in recent Etherboot
distributions where the NIC was not turned off after loading and
deposited stray packets in memory. (eepro100_disable was not
implemented.) As I understand it the source in GRUB is a bit behind.

[Etherboot-developers] Is it possible to hardwire paths to kernel&root?

[Hannu M. <mar...@pe...>]

Hei,

We have DHCP-servers (Win NT) and I cannot use Unix dhcp-servers (Well,
or course I could, but this must work also on other subnets...).
And it would be mission impossible to have the NT-servers provide
necessary information/files for LTSP systems.

What I need is to be able to hardwire
	tftp-server
	kernel-path
into etherboot images. They could be overridden if dhcp-server provides
something else.

I would especially like if services like "rom-o-matic" would add this
their image-generators.
Just couple of more lines asking "tftp-server" and "path to kernel".

It also would be nice to be able to "hardwire" NFS-server and path to
root-image at the same time (I know this info can be put into kernel
images).

I'd really like to see these features in standard etherboot package, but
if anyone knows how to "hack" these values in, I'd be happy enough...

- Goodi
"The linuX Files -- The Source is Out There."
=F8,=B8=B8,=F8=A4=BA=B0`=B0=BA=A4=F8,=B8=B8,=F8=A4=BA=B0`=B0=BA=A4=F8,=B8=
=B8,=F8=A4=BA=B0`=B0=BA=A4=F8,=B8=B8,=F8=A4=BA=B0`=B0=BA=A4=F8=A4=BA=B0`=B0=
=BA=A4=F8,=B8=B8,=F8=A4=BA=B0

RE: [Etherboot-developers] Why doesn't gas assemble start32.S

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

My results are the same as yours with the exception I didn't get the
assembler messages but that is ok. 

I don't quite understand the implications here - too early on Monday morning
I guess. When I have digested this business, I'll post again.

Over the weekend, I did have an opportunity to look into assemblers. I am
startled to discover nasm, a product that clearly outperforms tasm and masm.

Thank you once again. I think you and Ken are doing the community a great
service.

Eno


 -----Original Message-----
From: 	Marty Connor [mailto:md...@th...] 
Sent:	Friday, February 09, 2001 7:11 PM
To:	Eno Compton
Cc:	Etherboot Developers
Subject:	RE: [Etherboot-developers] Why doesn't gas assemble
start32.S

On 2/9/2001 5:37 PM Eno Compton Eno...@Mi... wrote:
>Have done a little digging here.
>In the 4.7.17 Makefile, the precompile target copies stuff from src/bin to
>src but the rules don't say anything about compiling anything and the bin
>src/bin directory is empty. The complaint that make issues to the effect
>there is no target for bin/rloader.bin is a little specious.

Did you uncomment the AS86 define in Makefile (the first one)?  If you 
didn't you wouldn't recompile anything. Here is the relevant part of the 
Makefile:

# If you have not made any changes to the *.S files, AS86 need not be set.
# (most people)
# If you have made changes to the *.S files and you want to rebuild 
*loader.bin
# and {floppy,com}load.bin and you have as86 from the ELKS Dev86 package 
(not
# the one that normally comes with Linux) (not most people)
AS86=          as86
# If you have made changes to the *.S files and you want to rebuild 
*loader.bin
# and {floppy,com}load.bin and you have nasm (not most people)
#AS86=          nasm

if I do:

$ make clean

then

$ make bin32/start32.o

I get:

gcc -E -DMOTD -DIMAGE_MENU -DBACKOFF_LIMIT=7 -DASK_BOOT=3 
-DANS_DEFAULT=ANS_NETWORK -DTAGGED_IMAGE -DELF_IMAGE -O2 -g 
-fstrength-reduce -fomit-frame-pointer -m386 -malign-jumps=1 
-malign-loops=1 -malign-functions=1 -Wall -W -Wno-format -Wno-unused 
-DVERSION_MAJOR=4 -DVERSION_MINOR=7 -DVERSION=\"4.7.17\" -DRELOC=0x98000  
start32.S | as  -o bin32/start32.o
{standard input}: Assembler messages:
{standard input}:327: Warning: indirect ljmp without `*'

How about you?  

$ gcc --version
egcs-2.91.66

What version of gcc are you running?

I hope this helps,

Regards,

Marty

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

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

[Etherboot-developers] Etherboot/GRUB driver for eepro100 - problem in understanding !

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

Hi Etherboot hackers.

I have the problem downloading the OS kernel image to 1MB
(0x00100000), via GRUB / tftpboot (*** not etherboot here ! ***)
Booting the same kernel from the disk works !

So I tried to analyse the etherboot eepro100 stuff to
analyse, if the kernel is overwritten per packets per
accident, as a transfer buffer or similar is on that address.

While code reading of eepro100.c I got a problem in understanding
one detail:

In the probe section of the driver, the RxFD structure is
initialized. Here the field
	  ACCESS(rxfd)rx_buf_addr = (int) &nic->packet;
is setup with the address of the packet frame POINTER inside
the nic structure.

What does the field rx_buf_addr expect ?
The address to a buffer, or the address to a pointer, indicating
the the buffer ?

The point I cannot understand here is the following.
The setup in the probe functions sets the `rx_buf_addr' to the
packet buffer, defined in `config.c'. This means, that an received
packet is transfered there by the i8255[789] chip. On the
other hand, in the `poll' routine, I found following code:

    nic->packetlen =  ACCESS(rxfd)count & 0x3fff;
    memcpy (nic->packet, ACCESS(rxfd)packet, nic->packetlen);

Here the contents from the packet field of the `rxfd' is copied into
the nic->packet frame. But how does the frame come in `rxfd'-packet
field ?? The hardware has to send the data directly to nic->packet.

Why does this code work on booting Linux, etc.... ?

Please help me to understand that point !

With friendly regards
	Christoph Plattner

Ask if my explanations as questions are unclear ...


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

RE: [Etherboot-developers] Why doesn't gas assemble start32.S

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

On 2/9/2001 5:37 PM Eno Compton Eno...@Mi... wrote:
>Have done a little digging here.
>In the 4.7.17 Makefile, the precompile target copies stuff from src/bin to
>src but the rules don't say anything about compiling anything and the bin
>src/bin directory is empty. The complaint that make issues to the effect
>there is no target for bin/rloader.bin is a little specious.

Did you uncomment the AS86 define in Makefile (the first one)?  If you 
didn't you wouldn't recompile anything. Here is the relevant part of the 
Makefile:

# If you have not made any changes to the *.S files, AS86 need not be set.
# (most people)
# If you have made changes to the *.S files and you want to rebuild 
*loader.bin
# and {floppy,com}load.bin and you have as86 from the ELKS Dev86 package 
(not
# the one that normally comes with Linux) (not most people)
AS86=          as86
# If you have made changes to the *.S files and you want to rebuild 
*loader.bin
# and {floppy,com}load.bin and you have nasm (not most people)
#AS86=          nasm

if I do:

$ make clean

then

$ make bin32/start32.o

I get:

gcc -E -DMOTD -DIMAGE_MENU -DBACKOFF_LIMIT=7 -DASK_BOOT=3 
-DANS_DEFAULT=ANS_NETWORK -DTAGGED_IMAGE -DELF_IMAGE -O2 -g 
-fstrength-reduce -fomit-frame-pointer -m386 -malign-jumps=1 
-malign-loops=1 -malign-functions=1 -Wall -W -Wno-format -Wno-unused 
-DVERSION_MAJOR=4 -DVERSION_MINOR=7 -DVERSION=\"4.7.17\" -DRELOC=0x98000  
start32.S | as  -o bin32/start32.o
{standard input}: Assembler messages:
{standard input}:327: Warning: indirect ljmp without `*'

How about you?  

$ gcc --version
egcs-2.91.66

What version of gcc are you running?

I hope this helps,

Regards,

Marty

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

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

Re: [Etherboot-developers] Why doesn't gas assemble start32.S

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

On 2/9/2001 12:36 PM Eno Compton Eno...@Mi... wrote:
>Tried to assemble start32.S. Was amazed to discover errors occur even on
>comment lines. Obviously, some assembler, other than gas, has been used to
>assemble the code.
>Discovered as well, gas includes only one pass, which, among other things,
>makes an assembly listing of questionable value.
>These things suggest to me, real programmers are using an assembler other
>than gas.
>Would somebody please fill me in on these questions?
>How does one assemble start32.S?

Good question.  Let's see how the Makefile does it:

$ grep start32 Makefile
SRCS=   floppyload.S comload.S liloprefix.S loader.S start16.S start32.S 
serial.S
START32=        start32.o.pre
START32=        bin32/start32.o
# To make sure that this actually builds a start32.o.pre with all options 
set,
precompiled:    bin/rloader.bin bin/rzloader.bin bin/prloader.bin 
bin/przloader.bin bin/floppyload.bin bin/comload.bin bin16/start16.o 
bin32/start32.o bin/liloprefix.bin
        cp -p bin32/start32.o start32.o.pre

Well, it seems to be part of the "precompiled" family.  Let's see what 
happens if we do that:

[mdc@rom src]$ make precompiled
gcc -E -DUSE_AS86 -DMOVEROM -DRELOC=0x98000 -o bin/rloader.s loader.S
as86  -0 -b bin/rloader.bin bin/rloader.s
gcc -E -DUSE_AS86 -DMOVEROM -DRELOC=0x98000 -DZLOADER -o bin/rzloader.s 
loader.S
as86  -0 -b bin/rzloader.bin bin/rzloader.s
gcc -E -DUSE_AS86 -DMOVEROM -DRELOC=0x98000 -DPCI_PNP_HEADER -o 
bin/prloader.s loader.S
as86  -0 -b bin/prloader.bin bin/prloader.s
gcc -E -DUSE_AS86 -DMOVEROM -DRELOC=0x98000 -DPCI_PNP_HEADER -DZLOADER -o 
bin/przloader.s loader.S
as86  -0 -b bin/przloader.bin bin/przloader.s
gcc -E -DUSE_AS86 -o bin/floppyload.s floppyload.S
as86  -0 -b bin/floppyload.bin bin/floppyload.s
gcc -E -DUSE_AS86 -o bin/comload.s comload.S
as86  -0 -b bin/comload.bin bin/comload.s
bcc -DMOTD -DIMAGE_MENU -DBACKOFF_LIMIT=7 -DASK_BOOT=3 
-DANS_DEFAULT=ANS_NETWORK -O -ansi  -DVERSION=\"4.6.12\" -DRELOC=0x98000  
-c -o bin16/start16.o start16.S

[here's where start32.S gets assembled]

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.12\" -DRELOC=0x98000  start32.S | 
as  -o bin32/start32.o
{standard input}: Assembler messages:
{standard input}:339: Warning: indirect ljmp without `*'

[the warnings can be safely ignored, I'm told]

gcc -E -DUSE_AS86 -o bin/liloprefix.s liloprefix.S
as86  -0 -b bin/liloprefix.bin bin/liloprefix.s
cp -p bin/rloader.bin rloader.bin.pre
cp -p bin/rzloader.bin rzloader.bin.pre
cp -p bin/prloader.bin prloader.bin.pre
cp -p bin/przloader.bin przloader.bin.pre
cp -p bin/floppyload.bin floppyload.bin.pre
cp -p bin/comload.bin comload.bin.pre
cp -p bin16/start16.o start16.o.pre
cp -p bin32/start32.o start32.o.pre
cp -p bin/liloprefix.bin liloprefix.bin.pre

OK, so it puts it in bin32/start32.o

Let's try making that:

[mdc@rom src]$ make bin32/start32.o
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.12\" -DRELOC=0x98000  start32.S | 
as  -o bin32/start32.o
{standard input}: Assembler messages:
{standard input}:339: Warning: indirect ljmp without `*'

That looks like it.  I guess it needs lots of options to assemble 
properly.

Hope this helps,

Marty


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

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

[Etherboot-developers] Why doesn't gas assemble start32.S

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

Tried to assemble start32.S. Was amazed to discover errors occur even on
comment lines. Obviously, some assembler, other than gas, has been used to
assemble the code.

Discovered as well, gas includes only one pass, which, among other things,
makes an assembly listing of questionable value.

These things suggest to me, real programmers are using an assembler other
than gas.

Would somebody please fill me in on these questions?

How does one assemble start32.S?

Thanks

Eno Compton

[Etherboot-developers] mknbi-1.1-0 (development) released

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

I have released mknbi-1.1-0 at http://etherboot.sourceforge.net .tar.gz
and RPMs are available, DEBs soon.

This is a development release, but it has been in use for some time.  It
contains a 32-bit version of the startup segment which should get rid of
the "BOOTP record too large" mystery bug, and also has support for
protected mode startup code, and ELF format containers (mkelf). It
should handle RAM > 64M without any problem.  There is preliminary
support for an external chooser menu program. Some of the features
require Etherboot 4.7.x and higher.

Re: [Etherboot-developers] secrets behind symbol, INCLUDE_LANCE ?

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

|Don't know, but I hope there is some ethernet signal, analogous to rs232
|data-set-ready or clear-to-send,  that says something is plugged into the
|port thus implying logical clear-to-send. I was thinking of checking that
|signal and doing as you suggest with the absence of dhcp responses.

With some 10/100-Base-T controllers it might be possible to detect
missing carrier. In other cases it's indistinguishable from loss of
packets.

RE: [Etherboot-developers] secrets behind symbol, INCLUDE_LANCE ?

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

Hmmm, very helpful, Ken. Thanks.

I'll post once in a while as the development goes along - keep everybody
amused with my travails.

>You'd have to decide what fails to boot means...

Don't know, but I hope there is some ethernet signal, analogous to rs232
data-set-ready or clear-to-send,  that says something is plugged into the
port thus implying logical clear-to-send. I was thinking of checking that
signal and doing as you suggest with the absence of dhcp responses.

Had a quick peek at csr0 in the AM79C960 spec. The descriptions of the bits
is a little vague and I don't see a signal that offers but then I haven't
invested time enough to truly understand the bits. 

Eno

 -----Original Message-----
From: 	Ken Yap [mailto:ke...@nl...] 
Sent:	Wednesday, February 07, 2001 7:43 AM
To:	eth...@li...
Subject:	Re: [Etherboot-developers] secrets behind symbol,
INCLUDE_LANCE ?

>Being unfamiliar with Etherboot Architecture, I am unsure how to
>approach this development. My first thought was to confine my
>modifications to the lance driver itself. Considering over night
>though, I think there must be higher level logic, that calls the lance
>driver, where simple modifications might fit easier. My thought here is
>to modify the lance driver such that the probe routine knows to ignore
>a device. With this ability, the higher routine could call lance
>normally (use any device you can find). Failing the first device, the
>higher routine could call lance again with a parameter that says, in
>effect, use any device you can find except this one.

You probably don't need to modify the lance driver. The way the PCI
subsystem works is that the pci_probe routine returns (or is supposed to
return) a list of addresses at which an adaptor has been detected.
Currently it just hands the first one to the lance driver and assumes
that one will work. What you could do is use a static variable to index
into the list, and if the first one fails to boot, then advance the
index to the next device and call the probe routine again on the next
adaptor.  You'd have to decide what fails to boot means, probably no
DHCP reply within so many retries. Oh and probably you should disable
the current device before moving on to the next one.

If you get this to work, it might be a useful addition to the code.

>Your statement about non-reentrancies worries me, but that can't be a
killer
>unless space restrictions are insurmountable. We intend to keep the code in
>about 16k of available space in bios rom. If this is insufficient, we will
>just have to make other arrangements, something we need to avoid if
>possible.

It's not a space problem per se, just that the driver keeps in static
variables info about the current device. It could be remedied by
rewriting the driver to have no static variables, except perhaps
read-only lookup tables and strings, and to hang device specific data
off the NIC structure, there is a pointer field for private data.
However if you are dealing with only one interface at any given time
then you shouldn't need to modify the driver.

Non-reentrant is probably the wrong term, single threaded is probably
closer to what I meant.

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

Re: [Etherboot-developers] secrets behind symbol, INCLUDE_LANCE ?

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

>Being unfamiliar with Etherboot Architecture, I am unsure how to
>approach this development. My first thought was to confine my
>modifications to the lance driver itself. Considering over night
>though, I think there must be higher level logic, that calls the lance
>driver, where simple modifications might fit easier. My thought here is
>to modify the lance driver such that the probe routine knows to ignore
>a device. With this ability, the higher routine could call lance
>normally (use any device you can find). Failing the first device, the
>higher routine could call lance again with a parameter that says, in
>effect, use any device you can find except this one.

You probably don't need to modify the lance driver. The way the PCI
subsystem works is that the pci_probe routine returns (or is supposed to
return) a list of addresses at which an adaptor has been detected.
Currently it just hands the first one to the lance driver and assumes
that one will work. What you could do is use a static variable to index
into the list, and if the first one fails to boot, then advance the
index to the next device and call the probe routine again on the next
adaptor.  You'd have to decide what fails to boot means, probably no
DHCP reply within so many retries. Oh and probably you should disable
the current device before moving on to the next one.

If you get this to work, it might be a useful addition to the code.

>Your statement about non-reentrancies worries me, but that can't be a killer
>unless space restrictions are insurmountable. We intend to keep the code in
>about 16k of available space in bios rom. If this is insufficient, we will
>just have to make other arrangements, something we need to avoid if
>possible.

It's not a space problem per se, just that the driver keeps in static
variables info about the current device. It could be remedied by
rewriting the driver to have no static variables, except perhaps
read-only lookup tables and strings, and to hang device specific data
off the NIC structure, there is a pointer field for private data.
However if you are dealing with only one interface at any given time
then you shouldn't need to modify the driver.

Non-reentrant is probably the wrong term, single threaded is probably
closer to what I meant.

RE: [Etherboot-developers] secrets behind symbol, INCLUDE_LANCE ?

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

Thanks, Ken for that explanation.

Since you speculate about the second nic, I'll add some detail about our
project and solicit you suggestions.

The machine, a custom built box intended for avionics applications, is
equipped with two ethernet interfaces. One uses the AMD AM79C972 chip; the
other uses the AMD AM79C973 chip. Both these chips are, for etherboot
purposes, compatible with the AMD Lance. The unmodified etherboot is working
against the 972 chip.

The project requires the boot process to attempt the boot first against the
972 device. Failing that, the process must continue by attempting the boot
against the 973 device. Failing that, the process continues normally against
local rotating storage.

Being unfamiliar with Etherboot Architecture, I am unsure how to approach
this development. My first thought was to confine my modifications to the
lance driver itself. Considering over night though, I think there must be
higher level logic, that calls the lance driver, where simple modifications
might fit easier. My thought here is to modify the lance driver such that
the probe routine knows to ignore a device. With this ability, the higher
routine could call lance normally (use any device you can find). Failing the
first device, the higher routine could call lance again with a parameter
that says, in effect, use any device you can find except this one.

Your statement about non-reentrancies worries me, but that can't be a killer
unless space restrictions are insurmountable. We intend to keep the code in
about 16k of available space in bios rom. If this is insufficient, we will
just have to make other arrangements, something we need to avoid if
possible.

Does this make any sense?

Eno

 -----Original Message-----
From: 	Ken Yap [mailto:ke...@nl...] 
Sent:	Tuesday, February 06, 2001 4:45 PM
To:	eth...@li...
Subject:	Re: [Etherboot-developers] secrets behind symbol,
INCLUDE_LANCE ? 

|Have been studying the lance driver for some time. Of course confusion
|reigns. The confusion stems from the conditional compilation symbol,
|INCLUDE_LANCE. Here is why. 

The confusion is because INCLUDE_LANCE is a bit of a misnomer. It really
means "this is a PCI lance card".

|Where the probe routine definition occurs, the entry point to
lancepci_probe
|is defined within an ifdef INCLUDE_LANCE. But there is no alternative
|definition to serve in the case the symbol is undefined.

If the symbol is undefined, one of the others will be, INCLUDE_NE2100 or
INCLUDE_NI6510. I'm guessing since you probably have a PCI lance card,
you should continue to use INCLUDE_LANCE. To add an entry to the PCI
entries for lance, edit config.c and NIC. Also add an entry to
chip_table[] in lance.c.

|I don't mean to be picky here but I have to modify the driver to
accommodate
|a second nic. Further to this end it is necessary for me to understand
|driver subtleties that seem to be eluding me.

If by second NIC you mean detecting two cards on the same machine rather
than adding a new type of card to the table, you are entering
unchartered territory. I don't think the current code will work for more
than one card without large modifications, there are too many
non-reentrancies in the code.

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

Re: [Etherboot-developers] secrets behind symbol, INCLUDE_LANCE ?

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

|Have been studying the lance driver for some time. Of course confusion
|reigns. The confusion stems from the conditional compilation symbol,
|INCLUDE_LANCE. Here is why. 

The confusion is because INCLUDE_LANCE is a bit of a misnomer. It really
means "this is a PCI lance card".

|Where the probe routine definition occurs, the entry point to lancepci_probe
|is defined within an ifdef INCLUDE_LANCE. But there is no alternative
|definition to serve in the case the symbol is undefined.

If the symbol is undefined, one of the others will be, INCLUDE_NE2100 or
INCLUDE_NI6510. I'm guessing since you probably have a PCI lance card,
you should continue to use INCLUDE_LANCE. To add an entry to the PCI
entries for lance, edit config.c and NIC. Also add an entry to
chip_table[] in lance.c.

|I don't mean to be picky here but I have to modify the driver to accommodate
|a second nic. Further to this end it is necessary for me to understand
|driver subtleties that seem to be eluding me.

If by second NIC you mean detecting two cards on the same machine rather
than adding a new type of card to the table, you are entering
unchartered territory. I don't think the current code will work for more
than one card without large modifications, there are too many
non-reentrancies in the code.