etherboot-developers — Discussion of developer issues

[Etherboot-developers] Etherboot 4.6.12 released

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

Hmm, the patch file is > 200kB now, so I'd better kick this one out the
door. Besides what better way to find bugs than to make a release. For
sure somebody will find a few bugs within the next day now that I have
released it; Murphy's law guarantees it. :-)

At the usual place: http://etherboot.sourceforge.net/ Will appear also
at download.sourceforge.net within a day or so.

Changes from 4.6.11:

+ Stefan Lesicnik sent in a report from Intel which explains what is
probably wrong with the PnP header. BEV should point to the mainline
vector, not to the part that installs the INT19H vector.

+ Hopefully finally fixed DHCP option limit problem. It was requesting
large packets but not parsing them fully due to the length limit passed
into decode_rfc1533(). Thanks to shredda for testing this.

+ Added the # modifier to printf, it prefixes 0x to %x and %X making
printf formats shorter throughout. 0x%[xX] changed to %#[xX] in lots of
files.  Now if only I could make b,x,X the standard hhx,hx,x and get rid
of I.

+ Andreas Neuhaus provided patches for multiple rx buffers for lance.c
which made it work again with VMware.

+ Perl script to convert floppyfw floppies to netbootable images.

+ Marty Connor made some small changes to liloprefix and Makefile to
make the LILO images SYSLINUX bootable also.

+ Make the default return value for _poll in skel.c 0 so that when
driver writers implement _transmit first, it will not hang on garbage
return values from _poll when it's called to flush the input queue
before the first transmit.

+ EEPRO/10 driver now works. µs timer routines came in useful.

+ Anders Larsen sent in a patch to 3c90x.txt which makes it clearer.

+ Added more stuff to the documentation.

+ Fixed bug in mknbi that always did the equivalent of --ipaddrs=rom
no matter what. Also removed undef from my variable list in TruncFD.pm
so that it won't have problems with Perl interpreters.

MD5 sums:

ea6272686b6eba676724c06880d941ec  etherboot-4.6.12.tar.bz2
4a58d84fc3b5d05e68643d4d35bf1608  etherboot-4.6.12.tar.gz
4e9b15cea5f89039837985a6655f463d  patch-4.6.12.gz

Re: [Etherboot-developers] Conditionalizing RELOCADDR in Makefile

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

We should have a code review (code inspection) for
this patch  :-)

Cheers
	Christoph

Ken Yap wrote:
> 
> >Can we bracket RELOCADDR in Makefile as follows:
> >
> >#ifndef RELOCADDR
> >RELOCADDR=0x98000
> >#endif
> 
> Ok, this is in the latest megapatch under Patch Manager. This is a big
> patch, I've been revising the docs and should be able to release in a
> day or two.
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> http://lists.sourceforge.net/mailman/listinfo/etherboot-developers

-- 
  +--------V--------+	Chr...@al...
  |  A L C A T E L  |	-----------------------------
  +-----------------+	Phone: +43 1 27722 3706	
         T A S		Fax:   +43 1 27722 3955

Re: [Etherboot-developers] Conditionalizing RELOCADDR in Makefile

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

On 11/28/2000 2:41 AM Ken Yap ke...@nl... wrote:
>>#ifndef RELOCADDR
>>RELOCADDR=0x98000
>>#endif
>Ok, this is in the latest megapatch under Patch Manager. This is a big
>patch, I've been revising the docs and should be able to release in a
>day or two.

Great, thanks.

Re: [Etherboot-developers] Conditionalizing RELOCADDR in Makefile

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

>Can we bracket RELOCADDR in Makefile as follows:
>
>#ifndef RELOCADDR
>RELOCADDR=0x98000
>#endif

Ok, this is in the latest megapatch under Patch Manager. This is a big
patch, I've been revising the docs and should be able to release in a
day or two.

[Etherboot-developers] Re: Conditionalizing RELOCADDR in Makefile

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

>#ifndef RELOCADDR
>RELOCADDR=0x98000
>#endif
>
>This will allow it to be set in Config.  For most people this change 
>should be transparent, it does allow me to add an option easily to 
>rom-o-matic for those people who need to relocate the ROM.  I know I also 
>have to define AS86 for this to work.

Yes, sure can, thanks for reminding me.

[Etherboot-developers] Conditionalizing RELOCADDR in Makefile

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

Can we bracket RELOCADDR in Makefile as follows:

#ifndef RELOCADDR
RELOCADDR=0x98000
#endif

This will allow it to be set in Config.  For most people this change 
should be transparent, it does allow me to add an option easily to 
rom-o-matic for those people who need to relocate the ROM.  I know I also 
have to define AS86 for this to work.

Thanks,

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] booting linux from Flash ROM

[Raghunandan N. <rag...@wi...>]

Hello,

To introduce myself I am Raghunandan from Bangalore India. You can address
me as Raghu.

I have downloaded linux kernel 2.2.14, I have a flash board which
has a 4 flash roms each of 512KB size each, This flash board has been
plugged into ISA slot of the PC.
The linux kernel image is of size 0.6MB.
Now I want to embed this in the flash roms on the flash board and boot the
computer with linux embedded in the Flash ROMs.

I have the following questions.
1.  Please let me know what are the changes i need to do in the kernel
source code so that it boots from Flash ROM. And also any other steps i need
to undertake.

2.  At what locations should the boot loader start, the OS should be
located.

3. Is it possible to boot with bare minimum kernel?

A tutorial kind of thing would help.

I hope I have clearly explained the problem statement,

Thank you very much for your help
________________________________________________________________________

Thanks n Best Regards,
RAGHUNANDAN.N             Tel: 91-80-5722293/96
Sr.Engineer-Software      Fax: 91-80-5722696/685 xtn 5319
WIPRO TECHNOLOGIES        Email: rag...@wi...
Global R&D.               http://www.wipro.com
26, Hosur Main Road,
Bommanahalli,
Bangalore-560 068, India
The World's First SEI CMM Level 5 Software Services Company.
________________________________________________________________________

Re: [Etherboot-developers] "__asm__" blocks in pci.c and pci.h

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

>I'm trying to compile it with the M$ C++ compiler, and am running into 
>problems compiling 'pci.c' due to the use of '__asm__'.  Can someone help 
>give me a kick-start by showing me how to convert these to either plain 
>assembly, straight C (preferrably this since I don't know much assembly), or 
>something else...?

I don't think you're likely to get very far using M$ C++, the software
depends heavily on the GNU toolchain. Even if you get past the
compilation problem, there's still the linking.

If you just want ROM images, go to rom-o-matic.net. If you really want
to compile it on a Windoze platform, you *might* be able to do it using
the DJGPP tools on Windoze, you could even be a pioneer. :-)

[Etherboot-developers] "__asm__" blocks in pci.c and pci.h

[Ryan J. <ri_...@ho...>]

Hello,

Etherboot is awesome!  I've been looking all over for an app like this, and 
was very excited to find it.

I'm trying to compile it with the M$ C++ compiler, and am running into 
problems compiling 'pci.c' due to the use of '__asm__'.  Can someone help 
give me a kick-start by showing me how to convert these to either plain 
assembly, straight C (preferrably this since I don't know much assembly), or 
something else...?

Thanks in advance,
Ryan
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

[Etherboot-developers] lance.c patch for multiple rx buffers

[Andreas N. <an...@fa...>]

dear everybody,

i finally managed to modify lance.c to support multiple rx buffers. now it
works with VMware again. i attached the small patch to this mail. i only
tried INCLUDE_LANCE and not INCLUDE_NE2100 and INCLUDE_NI6510. it should
work, but perhaps somebody should check that :-).
feel free to include this patch into etherboot if you think this is
useful...

regards,
andreas neuhaus

[Etherboot-developers] Re: [Etherboot-users] etherboot ignores vendor tags

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

>I changed the sources accordingly.
>
>Result:
>Runs fine, i.e. long motd and a lot of images are possible.
>But my setup (dhcpd.conf and etherboot config) is quite plain,
>so we have to test it in environments which are more
>sophisticated to prove the stability of the change.

Thanks.

>How should I change my configuration to get more expressive
>results? 

The only result of the change should be that you can get larger DHCP
packets. It shouldn't affect other aspects of your systems. So just test
it in the normal way.

[Etherboot-developers] Re: [Etherboot-users] etherboot ignores vendor tags

[Christian S. <sh...@un...>]

On Wed, 8 Nov 2000, Ken Yap wrote:
> 
> If you (shredda) could try fix 1 and confirm this works, we have at
> least confirmation of my theory.
> 

I changed the sources accordingly.

Result:
Runs fine, i.e. long motd and a lot of images are possible.
But my setup (dhcpd.conf and etherboot config) is quite plain,
so we have to test it in environments which are more
sophisticated to prove the stability of the change.

How should I change my configuration to get more expressive
results? 
~
CU,
Shredda

-- 
Christian Schroeder        sh...@up...

FW: Pro100 & OPSD Network boot issue (fwd)

[Stefan L. <st...@uc...>]

Hi,

Being GPL and all, ive decided to mail you with a recent problem we had
using EEPRO 100's and Intel boards with a phoenix bios.  This problem
existed on the 810 & 815.  Intel wont change it, so we got them 2 fix the
bootcode.  There is also a solution to why it works. I dont understand it
much. hehe.

Hope you and lots of others around the world can make some use of it.

Thanks

Stefan




> It looks like we have a simple solution here for the custom Pro100+ option
> ROM.
> 
> Here is a simplistic overview of the steps that our BBS compliant CORE
> BIOS performs when scanning for the option ROM.
> 
> 1. During ROM scan, we find the option ROM at CC00:0000, checksum it etc,
> the jump to it's entry point at CC00:0003, this code then jumps to
> CC00:0054 to execute the option ROM init code.
> 2. Option ROM init code installs an INT19 vector of CC00:0082
> 3. Our system BIOS now looks for the PCI & PNP tables in the option ROM by
> looking at WORD offsets at 18h and 1Ah.
> 4. A valid PNP Expansion Header is found at address CC00:0034
> 5. We read the Boot Strap Entry Vector (BEV) entry at table offset 1Ah
> (CC00:004E). BEV vector is read as 0054.
> 6. Because we found a valid BEV we then assume this is the boot vector.
> BEV has priority over INT19.
> 7. We now store the INT19 vector along with the BEV and set the boot
> method for this option ROM to BEV.
> 8. During INT19 boot, we attempt to boot from the BEV address, so we jump
> to CC00:0054 where the option ROM init code is run again (obviously a
> mistake), as the BEV should really point to offset 0082 (actual INT19
> vector).
> 9. Option ROM fails to boot (obviously), so we attempt to boot from the
> next device in the list.
> 
> Now, the important addresses here are:-
> 
> CC00:004E - BEV vector. Should point to a vaild BEV.
> CC00:0054 - Option ROM init code, all it does is install the INT19 vector
> of CC00:0082
> CC00:0082 - Actual INT19 boot vector. The BEV should point to this address
> rather than 0054.
> 
> I've modified the option ROM image the customer sent in by hacking the BEV
> entry to 0082, and recalculating the checksum to 00 by changing byte
> CC00:3FFF from FF to D1.
> 
> ROM attached.
> 
> For reference, take a look at the BBS spec (1.01), page 33 for details of
> the PnP & PCI tables in the option ROM.
> http://www.phoenix.com/products/specs-bbs101.pdf
> 
>  <<FIXUP.ZIP>> 
> Thanks to OPSD's BBS expert Jordan Justen.
> 
> Stephen Baldwin.
> Server/Workstation Technical Marketing Engineer.
> Intel Corp UK, Pipers Way, 
> Swindon, Wilts, SN3 1RJ, UK.
> Tel: +44 1793 403251
> Fax: +44 1793 511527
> email: Ste...@in...
> 

[Etherboot-developers] possible solution to Intel BIOS booting problem

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

This message just came in, I haven't had time to evaluate it fully yet,
but this probably explains the problems some people have been having
with Intel BIOSes. To make the change in the code, change the line in
loader.S that says:

	dw	over			; bootstrap entry vector

to

	dw	start19h		; bootstrap entry vector

and let me know if it works.

[Etherboot-developers] Re: [Etherboot-users] etherboot ignores vendor tags

[Christian S. <sh...@un...>]

On Wed, 8 Nov 2000, Ken Yap wrote:

> [...]
> 1. Change the call near line 880 to pass DHCP_OPT_LEN + MAX_BOOTP_EXTLEN
> just like the line above, since the options extend into the extension
> area anyway. The EXTENSION_PATH option should be taken out of the DHCP
> options requested, so that Etherboot does not request it and have the
> contents of the file overwrite the extension area.  Technically
> extension path (option 18) is still legal in DHCPDISCOVER requests.  In
> practice it doesn't seem to be useful to DHCP because the buffer can be
> larger now. ISC dhcpd does not support this option directly, you would
> have to request for option-18. The one small problem with this is that
> you could not enable DHCP support and then use extension path with an
> bootp server. It could be argued that people who use bootp+extension
> path should be encouraged to migrate to DHCP.
> 
> [...]
> 
> If you (shredda) could try fix 1 and confirm this works, we have at
> least confirmation of my theory.

Ok. I will try it ASAP and inform you whether it works or not.

Cu,
Shredda

-- 
Christian Schroeder        sh...@up...

Re: [Etherboot-developers] Re: [Etherboot-users] etherboot ignores vendor tags

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

>3. Put the extension path handling code inside #ifdef NO_DHCP_SUPPORT,
>so that not only does enabling DHCP not request the extension path but
>it definitely cannot handle it. This would save a little bit of code
>space.

That should be #ifndef NO_DHCP_SUPPORT. Double negatives are confusing.

Re: [Etherboot-developers] Re: [Etherboot-users] etherboot ignores vendor tags

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

>1. Change the call near line 880 to pass DHCP_OPT_LEN + MAX_BOOTP_EXTLEN
>just like the line above, since the options extend into the extension
>area anyway. The EXTENSION_PATH option should be taken out of the DHCP
>options requested, so that Etherboot does not request it and have the
>contents of the file overwrite the extension area.  Technically
>extension path (option 18) is still legal in DHCPDISCOVER requests.  In
>practice it doesn't seem to be useful to DHCP because the buffer can be
>larger now. ISC dhcpd does not support this option directly, you would
>have to request for option-18. The one small problem with this is that
>you could not enable DHCP support and then use extension path with an
>bootp server. It could be argued that people who use bootp+extension
>path should be encouraged to migrate to DHCP.

Actually on further thought I think it should still be backward
compatible as a bootp server will ignore the parameters (and lack of
some options) in a DHCPDISCOVER message and send the extension file path
anyway.

[Etherboot-developers] Re: [Etherboot-users] etherboot ignores vendor tags

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

>Finally I found the problem:
>"/src/etherboot.h" sets the constant DHCP_OPT_LEN to 312 (=0x138).
>This seems to be the maximal length for _all_ DHCP options together.
>I set it to 512 and encountered no problems with my dhcpd.conf:
>The bootmenu appeared with all entries. For larger dhcpd.confs
>the value has to be increased further. 
>
>But the contstant hasn´t been defined just for fun,
>so  what purpose does the constant have ? And where
>can I find information about it (e.g. RFC)?

Ok, I took a look at the RFCs and the source. You are right that
DHCP_OPT_LEN is the cause of the problem, but not in the obvious way.

In the DHCPDISCOVER message, Etherboot already requests for the maximum
packet size that can be accomodated in the buffer (1024 if the buffer is
located at 0x93C00, otherwise sizeof(struct bootp_t) + 1024). The
problem is the call to decode_rfc1533, where the decoding of the buffer
is restricted by DHCP_OPT_LEN. There are several possible steps that can
be taken, each with greater consequences:

1. Change the call near line 880 to pass DHCP_OPT_LEN + MAX_BOOTP_EXTLEN
just like the line above, since the options extend into the extension
area anyway. The EXTENSION_PATH option should be taken out of the DHCP
options requested, so that Etherboot does not request it and have the
contents of the file overwrite the extension area.  Technically
extension path (option 18) is still legal in DHCPDISCOVER requests.  In
practice it doesn't seem to be useful to DHCP because the buffer can be
larger now. ISC dhcpd does not support this option directly, you would
have to request for option-18. The one small problem with this is that
you could not enable DHCP support and then use extension path with an
bootp server. It could be argued that people who use bootp+extension
path should be encouraged to migrate to DHCP.

2. More radically, rework the definitions of bootp_t and bootpd_t. The
former is a definition of the minimal BOOTP/DHCP packet and is used for
defining a DHCPDISCOVER packet in bootp() and so should not be bloated
so we should probably leave bootp_t alone.  The latter includes the
extension area or additional options area. But it's not clear to me if
anything needs changing in bootpd_t except that the member
"bootp_extension" wrongly describes what is really the continuation of
the DHCP options area.

3. Put the extension path handling code inside #ifdef NO_DHCP_SUPPORT,
so that not only does enabling DHCP not request the extension path but
it definitely cannot handle it. This would save a little bit of code
space.

If you (shredda) could try fix 1 and confirm this works, we have at
least confirmation of my theory.

[Etherboot-developers] Re: [Etherboot-users] etherboot ignores vendor tags

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

>Finally I found the problem:
>"/src/etherboot.h" sets the constant DHCP_OPT_LEN to 312 (=0x138).
>This seems to be the maximal length for _all_ DHCP options together.
>I set it to 512 and encountered no problems with my dhcpd.conf:
>The bootmenu appeared with all entries. For larger dhcpd.confs
>the value has to be increased further. 
>
>But the contstant hasn´t been defined just for fun,
>so  what purpose does the constant have ? And where
>can I find information about it (e.g. RFC)?

Probably in the DHCP RFCs mentioned at the top of main.c.  I think it's
a relic of the bootp packet format.  The problem is I'm not sure how it
interacts with the field bootp_extension (see types bootp_t and
bootpd_t) as there is a max limit for the whole packet
(min(1500,sizeof(bootpd_t))). I suspect that for DHCP, the space used by
bootp_extension should be allocated to DHCP_OPT instead, since AFAIK
there is no mechanism analogous to bootp's extension file in DHCP.

Re: [Etherboot-developers] woohoo, Etherboot reaches top 100 Sourceforge projects

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

I shouldn't forget that rom-o-matic probably contributed to this too.

[Etherboot-developers] woohoo, Etherboot reaches top 100 Sourceforge projects

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

http://sourceforge.net/project/stats/?group_id=4233

Reached 80th in fact. Usual disclaimer about lies, dammed lies and
statistics. I don't know how the stats are calculated, possibly by page
views (no I haven't been ballot box stuffing :-)

It may have something to do with the fact that SuSE 7.0 and Connectiva
Linux now distribute Etherboot as a RPM package, although it's a pity
SuSE apparently had a recent release, but had the wrong version number
and contact details. Spec file cut and paste error?

[Etherboot-developers] tips re disk on chip, part 3

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

Ok, here's what I *think* you have to do:

Get those kernel and LILO patches working so that it leaves alone
0x90000 and above. Test by booting a kernel with the modified LILO and
kernel.

Look at first-linux.S in mknbi-1.0. There is a memory map somewhere in
the comments. Note the areas used by Etherboot for loading, notably the
kernel parameter area, the bootp area and the block used for the control
tags from the first block of the netboot image.  A couple of these
constants are defined in the Etherboot source, the RELOCADDR in Makefile
and the BOOTP buffer address in etherboot.h I think.  Shift them down
64k.

The rest are in mknbi.pl, the segment constants used by mknbi-linux.
Also the segment constant for the control tags. Shift these down to
0x8NNN.

Don't use .lzrom images, because the decompressor uses the 0x80000
segment.  Get it working with .rom images then hack the decompressor to
work from the 0x70000 segment.

Naturally you can't load kernels into low memory that are larger than
0x80000. Try bzImages instead then you can have as large a kernel as you
want. Maybe this is mandatory for the kernel and LILO patches anyway.

Good luck. Let us know how you go.

Re: [Etherboot-developers] eepro100.c patch testing

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

>> 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 applied it to the latest version of Etherboot (4.6.10), built using
>the default Makefile options, put it on a floppy, and tried it out.  I
>set up a reboot test where the machine constantly reboots while a
>monitoring program watches.  So far, it has successfully rebooted 197
>times with no crashes/problems/etc.
>
>What are the circumstances under which ppl are seeing kernel crashes?
>I can try to reproduce the situation in the lab using the reboot test.
>
>I had problems a few months ago with kernel panics on bootup when I
>was using 2.2.5.  I upgraded to 2.2.15 (the latest at the time) and it
>fixed all my problems.

Somebody reported that the Ethernet controller was still alive after
handing over control to Linux and received stray packets (in busy
network) which corrupted the memory area reserved for packets but now
occupied by kernel. It's entirely plausible, and the *_disable routine
is to turn off the Ethernet controller just before Etherboot hands over
control to the booted image, that's why I added this routine to the
original BSD netboot framework. Unfortunately it hasn't been implemented
in all drivers.

Thanks for the testing, this will be in 4.6.11, since it doesn't hurt
anything and will probably help.

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

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

>ST Micro. ethernet vend , devid
>( 0x1317, 0x0981 )

Thanks, I'll add that to the list in NIC.

>I also have tried the eepro100 for the 82559ER 
>but am currently stuck with problems with the 
>eepro100 driver complaining of an invalid rom 
>checksum. any pointers?

Somebody on the list seemed to have success, I think it was Matt
Hortman.

[Etherboot-developers] eepro100.c patch testing

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

Ken Yap wrote:

> 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 applied it to the latest version of Etherboot (4.6.10), built using
the default Makefile options, put it on a floppy, and tried it out.  I
set up a reboot test where the machine constantly reboots while a
monitoring program watches.  So far, it has successfully rebooted 197
times with no crashes/problems/etc.

What are the circumstances under which ppl are seeing kernel crashes?
I can try to reproduce the situation in the lab using the reboot test.

I had problems a few months ago with kernel panics on bootup when I
was using 2.2.5.  I upgraded to 2.2.15 (the latest at the time) and it
fixed all my problems.

-Matt