etherboot-developers — Discussion of developer issues

[Etherboot-developers] Etherboot 5.0.1 (production) released

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

I have released Etherboot 5.0.1 at http://etherboot.sourceforge.net

Note that starting from this release, the documentation is in a separate
package.

The changes in 5.0.1 are:

+ Donald Christensen found a small bug in osloader.c. Not all context
was cleared on tftp restart which caused restarted tftp loads to fail.

+ Correct a small error in setting %sp when not running at 0x9xxxx.
Now relocation to 0x84000 works.

+ Marty Connor added a generic Tulip entry and renamed the Macronix
entries because PHP doesn't like strings starting with digits (for
rom-o-matic.net).

+ In loader.S, move code to save ROM segment and length to before jump
to new segment, otherwise if MOVEROM is defined, then the ROM segment is
always 0x8000. In etherboot.h, define an inline function to say if a ROM
address is ok to boot from. Allow if < 0xC0000 or matches assigned ROM
address of NIC.

+ Thomas Kessler found a bug in vendortags.sgml re option-NNN tags in
dhcpd.conf, the wrong syntax was presented. However on trying the
option-NNN syntax documented in the dhcp-options man page, it was
discovered that option option-NNN is no longer supported in the old way
in recent versions of ISC dhcpd v3; a new syntax should be used. Added
note to vendortags.sgml to warn users.

+ Incorporated changes suggested by Hannu Martikka to #define
DEFAULT_KERNELPATH in etherboot.h for rarp(), and display the TFTP
server address before filename in Loading: message.

+ Split off documentation into separate package in anticipation of
production/development series split. Moved previous LOG to top level.
Moved distribution section of index.html into separate web page so that
index.html will be less ephemeral.

MD5 sums:

58d82a969fc15db4e570095728fb5b13  etherboot-5.0.1.tar.bz2
a08916065c8a37d92cf1bcc1bb687d96  etherboot-5.0.1.tar.gz
56ff97923416acf1985e45c102ab24d7  etherboot-doc-5.0.1.tar.bz2
0f1c92dc9e4cdce16f7a2528c064b310  etherboot-doc-5.0.1.tar.gz

[Etherboot-developers] Re: [Etherboot-users] National 83815

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

On 5/4/01 9:36 AM Bob Doan bd...@si... wrote:
>Simple question I hope :)
>First of all, I'm a bit new to etherbooting/ netbooting.  But I have a 
>question about the national 83815.  I'm currently trying to find the 
>correct etherboot driver name for it...   In the DB there does not seem to 
>be a name... but it looks like it was added in etherboot version 4.7.17 
>.... any ideas?

[followups should probably go to etherboot-developers]

Hi Bob.  You must be related to Terry Doan who visited the Etherboot 
booth at LinuxWorld Expo 2001 in NYC.

I don't believe there is currently support in Etherboot for the DP83815.  
Terry asked about it, and I said I'd look into doing it.  It's about the 
same level of difficulty as the SiS900 driver I did a a couple months 
back, and much easier than the Tulip driver I most recently did.  I 
downloaded the datasheet and got a copy of Don Becker's Linux driver for 
the DP83815.

If I get a spare weekend I might look into it again.  Terry said you were 
wanting to use it in an embedded system.  It also happens to be the chip 
on the NetGear FA311/312 board, which is popular, though doesn't have a 
ROM socket on it.  We don't seem to have much call for it, so it hasn't 
been a priority.

Anyway, it's about a week's work if one knows what one is doing, and a 
good learning project for anyone who might want to learn how to write 
Etherboot drivers.  See the file sis900.txt in the Etherboot 5.0.x 
distribution for a quickstart on adding a driver to Etherboot.

Perhaps someone on the list would be interested in working on the driver. 
 I'll probably get around to it, but we want to encourage new Etherboot 
developers, and this is a nice little driver project for someone who 
wants to get into driver writing.

If you're in a hurry and are willing to fund development (the driver 
would have to be released under the GPL), you can contact me privately 
and maybe we can figure something out.

Best Regards,

Marty

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

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

Re: [Etherboot-developers] HELP for RPL

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

>The link below is an email from Ken (way back in Apr, 1997) to the netboot
>list, providing a link to the Microsoft FTP site for RPL code - the same
>code he now claims no knowledge of....
>http://www.han.de/~gero/netboot/archive/msg00000.html
>
>Ken must have studied both "The Oliver North Trials", and Watergate...

Ah yes, one of those throwaway one-liners. Find em, post em, forget
em... :-)

"Developing the art of forgetting as career advancement" :-)

Re: [Etherboot-developers] HELP for RPL

[Robb M. <ma...@ac...>]

> >I am developing a program for RPL ( Remote Program Load ) Boot rom
> >Where is the source code for RPL boot rom ?
> >ON the novell web, Novell boot rom develop 's kit maybe exist.
> >But i cannot find it. Maybe it is too old.
>
> No idea. RPL is a IPX protocol. I have enough on my hands with IP. :-)

Not being one to waste an opportunity dripping irony....
... and knowing Ken must have an impressive sense of humour himself, given
the amount of abuse I have seen him take...

The link below is an email from Ken (way back in Apr, 1997) to the netboot
list, providing a link to the Microsoft FTP site for RPL code - the same
code he now claims no knowledge of....
http://www.han.de/~gero/netboot/archive/msg00000.html

Ken must have studied both "The Oliver North Trials", and Watergate...

...or is it:

<Critical ERROR>
stack overflow....
purge any recollection of old mail...complete.
Respawning task "brush teeth"...
;-)

Cheers,
Robb.

Re: [Etherboot-developers] HELP for RPL

[Robb M. <ma...@ac...>]

See:

 ftp://ftp.microsoft.com/developr/drg/RPL/

Robb.

----- Original Message -----
From: "XXXXXX" <st...@26...>
To: <eth...@li...>
Sent: Thursday, April 26, 2001 9:31 PM
Subject: [Etherboot-developers] HELP for RPL


> After reading something about Etherboot, it is based on PXE.
>
> I am developing a program for RPL ( Remote Program Load ) Boot rom
> Where is the source code for RPL boot rom ?
> ON the novell web, Novell boot rom develop 's kit maybe exist.
> But i cannot find it. Maybe it is too old.
>
> thanks all.
>
> _____________________________________________
> »¯×±Æ·ÈÈÂô£¬ÊçŮҲ·è¿ñ  http://shopping.263.net/category04.htm
> ¾«Æ·MP3¡¢ËæÉíÌý£¬¼Û¸ñÕ𺳠 http://shopping.263.net/fs/81shop/
>
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> http://lists.sourceforge.net/lists/listinfo/etherboot-developers

Re: [Etherboot-developers] HELP for RPL

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

>After reading something about Etherboot, it is based on PXE.

It's not.

>I am developing a program for RPL ( Remote Program Load ) Boot rom
>Where is the source code for RPL boot rom ?
>ON the novell web, Novell boot rom develop 's kit maybe exist.
>But i cannot find it. Maybe it is too old.

No idea. RPL is a IPX protocol. I have enough on my hands with IP. :-)

[Etherboot-developers] HELP for RPL

[»ÆµÂÖÇ <st...@26...>]

After reading something about Etherboot, it is based on PXE.

I am developing a program for RPL ( Remote Program Load ) Boot rom
Where is the source code for RPL boot rom ?
ON the novell web, Novell boot rom develop 's kit maybe exist.
But i cannot find it. Maybe it is too old.

thanks all.

_____________________________________________
»¯×±Æ·ÈÈÂô£¬ÊçŮҲ·è¿ñ  http://shopping.263.net/category04.htm
¾«Æ·MP3¡¢ËæÉíÌý£¬¼Û¸ñÕ𺳠 http://shopping.263.net/fs/81shop/

Re: [Etherboot-developers] Re: [Etherboot-users] TFTP timeout problem

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

>Okay, I dug into it and found the problem.  The tctx structure does
>not get properly re-initialized if the TFTP transfer fails (times
>out) and gets restarted.  Below is the one-line change to fix the
>problem.  The crux of the problem is the use of tctx.seglen in
>tagged_download().

Thanks, that'll be in 5.0.1.

[Etherboot-developers] Re: [Etherboot-users] TFTP timeout problem

[Donald J C. <dj...@ci...>]

(Switched from Etherboot-users to Etherboot-developers.)

Donald J Christensen wrote:
> 
> With Etherboot 4.7.23, I have a problem if the tftp download times
> out.  Best I can tell from the code, the transfer
> should restart from the beginning, but it doesn't.
...

Okay, I dug into it and found the problem.  The tctx structure does
not get properly re-initialized if the TFTP transfer fails (times
out) and gets restarted.  Below is the one-line change to fix the
problem.  The crux of the problem is the use of tctx.seglen in
tagged_download().

The diff is against the 5.0.0 sources and fixes Tagged image downloads.
I don't use Elf or a.out, so the same problem may exist with those
formats.

-Don


--- osloader.c.orig	Wed Apr 25 14:54:30 2001
+++ osloader.c	Wed Apr 25 14:54:54 2001
@@ -1020,7 +1020,7 @@
 			printf("(NBI)... ");
 			image_type = Tagged;
 			/* Zero all context info */
-			memset(&tctx.img, 0, sizeof(tctx.img));
+			memset(&tctx, 0, sizeof(tctx));
 			/* Copy first 4 longwords */
 			memcpy(&tctx.img, data, sizeof(tctx.img));
 			/* Memory location where we are supposed to save it */


--
Don Christensen    Senior Software Development Engineer
  dj...@ci...    MMABU - Mid-Market Access Business Unit
  Cisco Systems    ComLOB - Commercial Line of Business
   San Jose, CA    "So much relies on the course that you take
                   The fool and the wise man both burn at the stake"

[Etherboot-developers] Re: [Etherboot-users] Re: Etherboot 5.0.0 (production) released

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

Dirk von Suchodoletz <di...@go...> writes:

> > > I mailed the guy some weeks ago, but he is working on porting SuSE-linux
> > > to axp (?) platform. Maybe if some more people asking him for this tool he
> > > gives some more efforts to this project :-)
> > 
> > Actually this work just needs to get folded into the current mtd drivers
> > in the 2.4 kernel.  The infrastructure is nicer and they are being actively
> > developed and maintained.
> 
> Dont know much of kernel programming and these MTD :-( 
Quite a bit.

And once you have the docs to the motherboards, and chipsets, and
flash memories everything is straightforward and simple.

Getting the docs for motherboards tends to be the tricky part.  But I
haven't really looked into the general case.  Just one or two specific
cases.

> As I heard the BIOS must be accessed via the mainboard chipset. 

You need to map the BIOS into your address space, and about
half the time you need to enable writes to the BIOS.

> Do this type of flash match into the concepts of the MTD?
Yes.  You just need a per-chipsest or per-motherboard mapping driver
to enable the writes, and allow access to it.

> It would be great to have a more general driver for steady development,
> than a single kernel module patch...

The basic mtd stuff works well.  

Eric

[Etherboot-developers] Re: [Etherboot-users] Re: Etherboot 5.0.0 (production) released

[Dirk v. S. <di...@go...>]

> > I mailed the guy some weeks ago, but he is working on porting SuSE-linux
> > to axp (?) platform. Maybe if some more people asking him for this tool he
> > gives some more efforts to this project :-)
> 
> Actually this work just needs to get folded into the current mtd drivers
> in the 2.4 kernel.  The infrastructure is nicer and they are being actively
> developed and maintained.

Dont know much of kernel programming and these MTD :-( As I heard the BIOS
must be accessed via the mainboard chipset. Do this type of flash match
into the concepts of the MTD?
It would be great to have a more general driver for steady development,
than a single kernel module patch...

Ciao,
	Dirk

[Etherboot-developers] Re: [Etherboot-users] Re: Etherboot 5.0.0 (production) released

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

Dirk von Suchodoletz <di...@go...> writes:

> > And just so you know there's no rest for the wicked, here's a todo list.
> > 
> > 	http://etherboot.sourceforge.net/todo.html
> > 
> > If you think something ought to be on the list, discuss it on the
> > developer list and I'll add it if it's technically worthy. That doesn't
> > mean that I or anyone else for that matter will promise to do it. In
> > fact, I'm hoping, against hope as always, that people other than the
> > usual suspects (you know who you are) will take up the challenge. :-)
> 
> Moin,
> 	under the "BIOS" part was mentioned a tool for flashing biosses.
> There is such a thing in development: The /dev/bios project ->
> 	http://www.freiburg.linux.de/~stepan/bios/
> for the linux kernel. With an older version I was able to flash the bios
> of some older socket7 intel vx mainboards. Unfortunately it does not
> compile for the 2.4.X kernel series at the moment. It does not work with
> relatively new chipsets and biosses greater than 256kByte. It would
> improve the efficiency of my work, if I had such a tool for linux, because
> I have no diskdrives installed on about 300 X terminals :-)
> 
> I mailed the guy some weeks ago, but he is working on porting SuSE-linux
> to axp (?) platform. Maybe if some more people asking him for this tool he
> gives some more efforts to this project :-)

Actually this work just needs to get folded into the current mtd drivers
in the 2.4 kernel.  The infrastructure is nicer and they are being actively
developed and maintained.

Eric

[Etherboot-developers] Re: [Etherboot-users] Re: Etherboot 5.0.0 (production) released

[Dirk v. S. <di...@go...>]

> And just so you know there's no rest for the wicked, here's a todo list.
> 
> 	http://etherboot.sourceforge.net/todo.html
> 
> If you think something ought to be on the list, discuss it on the
> developer list and I'll add it if it's technically worthy. That doesn't
> mean that I or anyone else for that matter will promise to do it. In
> fact, I'm hoping, against hope as always, that people other than the
> usual suspects (you know who you are) will take up the challenge. :-)

Moin,
	under the "BIOS" part was mentioned a tool for flashing biosses.
There is such a thing in development: The /dev/bios project ->
	http://www.freiburg.linux.de/~stepan/bios/
for the linux kernel. With an older version I was able to flash the bios
of some older socket7 intel vx mainboards. Unfortunately it does not
compile for the 2.4.X kernel series at the moment. It does not work with
relatively new chipsets and biosses greater than 256kByte. It would
improve the efficiency of my work, if I had such a tool for linux, because
I have no diskdrives installed on about 300 X terminals :-)

I mailed the guy some weeks ago, but he is working on porting SuSE-linux
to axp (?) platform. Maybe if some more people asking him for this tool he
gives some more efforts to this project :-)

So long,
	  Dirk

[Etherboot-developers] Re: Etherboot 5.0.0 (production) released

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

On 4/25/01 11:01 AM Ken Yap ke...@nl... wrote:
>The Etherboot Project is pleased to announce the release of Etherboot 5.0.0,
>the latest production version, available immediately from
>http://sourceforge.net/projects/etherboot/.

First, I'd like to thank Ken for all his good work on this release.  He's 
good at thanking us other developers, so now it's our turn.  

   Thanks, Ken! Great job!!

Next, as is customary, I have updated http://rom-o-matic.net/ with the 
latest production release of Etherboot, version 5.0.0.

http://rom-o-matic.net/ is generating about 1000 ROMs a week now, and if 
you visit the site, please click on the link to Etherboot so that the 
Sourceforge stats reflect the Etherboot activity as well.  If rom-o-matic 
was hosted by Sourceforge, I think the project would be much higher in 
the stats. (even so, it is amazingly popular for a system utility).

Anyway, it's great to get out a new release, and I hope we get to see 
lots of you at LinuxWorld Expo SF 2001 (http://www.linuxworldexpo.com/) 
where we will once again have an Etherboot booth.

Now let's burn some ROMs and embed some code! :-)

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

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

Re: [Etherboot-developers] GAS 2.95 for compiling etherboot 4.7.24

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

> I do understand how you feel, though.  I've been waiting for the Progeny 
> Linux  (http://www.progeny.com/) distribution to come out to install some 
> packages that I'm interested in.  Now of course RH 7.1 has been 
> announced, and will be coming out (coincidentally, I'm sure) 1 day later, 
> so I'll probably be testing both distros on parallel machines.  I'm 
> hoping to switch my primary development environment to Debian in the 
> coming months.

Debian is a great distributions. Why do you need to wait for
Progeny? I run Debian (unstable) on all my machines (including my
work machine), and I am more than happy; this is a developer's dream
distribution. Running "unstable" is sometimes a little scary, but
breakage tends to not happen to often and I can usually fix it
within two minutes.


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...

[Etherboot-developers] Re: Etherboot 5.0.0 (production) released

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

And just so you know there's no rest for the wicked, here's a todo list.

	http://etherboot.sourceforge.net/todo.html

If you think something ought to be on the list, discuss it on the
developer list and I'll add it if it's technically worthy. That doesn't
mean that I or anyone else for that matter will promise to do it. In
fact, I'm hoping, against hope as always, that people other than the
usual suspects (you know who you are) will take up the challenge. :-)

Anyway, enough of this, I'm off to the beach tomorrow.

[Etherboot-developers] Etherboot 5.0.0 (production) released

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

[http://etherboot.sourceforge.net/v5ann.html]

The Etherboot Project is pleased to announce the release of Etherboot 5.0.0,
the latest production version, available immediately from
http://sourceforge.net/projects/etherboot/.

Firstly heaps of thanks to all those who have contributed code, sent in bug
reports and in one way or another improved the quality of the software. In
particular much is owed to Marty Connor, who runs the
http://rom-o-matic.net/ site, which serves ROM images on the fly. A full
list of acknowledgements can be found in the Etherboot documentation, in the
User Manual or in the LOG file. If you have contributed and I have not
included you, please contact me and I'll fix it.

The major improvements since the last production release (4.6.12) are:

   * Improved drivers for more Tulip, EEPRO100, Via-Rhine, and Lance
     variants, and a new driver for the SiS900 family.
   * Compliance (as far as we can tell) with the BIOS Boot Specification for
     PCI NIC PnP ROMs. The code will try to accommodate non-PnP BIOSes too.
     Legacy ROMs for ISA NICs are still supported.
   * User and developer documentation have been revised, rearranged and
     rewritten. Compile options are now better classified and documented.
   * Major code cleanup: Many drivers have been audited and code added to
     properly handle timeouts and disabling. The code base has been made
     ANSI-C compliant as far as possible. 16-bit support (for the
     088/086/186/286) has been discontinued in the interest of code clarity.
     Code changes to conserve memory space were made. Identifiers,
     particularly macros, have been renamed to match Linux nomenclature and
     signatures as far as possible to reduce programmer confusion.
   * New feature: Etherboot loads ELF format boot images made by
     mkelf-linux.
   * New feature: Etherboot supports the Vendor Class Identifier mechanism
     which allows Etherboot enabled clients to respond selectively to DHCP
     servers.
   * New feature: Etherboot supports auxiliary programs that return to
     Etherboot and direct further loading operations. See the Etherboot
     Developer Manual for more information on this capability.
   * Etherboot drivers can now have up to a 45kB memory footprint.
   * nasm/as86 are no longer needed, the 16-bit assembler routines have been
     converted to gas syntax.
   * New floppy boot block that also works with hard disk partitions.
   * Support for loading debugging symbols in FreeBSD loads.
   * mknbi has been split into a separate package for ease of maintenance.
   * Many new contributed utilities and documents in the contrib/ directory.
   * Many contributed links to external documentation.

and many other small improvements.

Of course, it being a .0 release, I'm sure that there are bugs, hopefully
none serious. Expect a .1 :-). This release is to mark a milestone and give
users a production release to use and developers a base for the next
development series.

Now to disappear to a Pacific island for 6 months. Hmm, I am on a very large
Pacific island already. Drat.

MD5 sums:

52ca8618fa13471ff5cab9857f5ffbb5  etherboot-5.0.0.tar.bz2
1049be887474457981b45d806201791e  etherboot-5.0.0.tar.gz

Re: [Etherboot-developers] GAS 2.95 for compiling etherboot 4.7.24

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

On 4/24/01 7:50 PM Robb Main ma...@ac... wrote:
>My intention was simply to avoid downloading a 6-7MB package (GNU gzip'd
>tars) when all I needed was a 200KB binary. No, not because I'm lazy - my
>Linux box is currently running 89% full.  

lol, clearly it's time to delete some of your old Etherboot mailing list 
archives.  That should give you more than ample room :-) :-)

I do understand how you feel, though.  I've been waiting for the Progeny 
Linux  (http://www.progeny.com/) distribution to come out to install some 
packages that I'm interested in.  Now of course RH 7.1 has been 
announced, and will be coming out (coincidentally, I'm sure) 1 day later, 
so I'll probably be testing both distros on parallel machines.  I'm 
hoping to switch my primary development environment to Debian in the 
coming months.

Regards,

Marty

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

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

Re: [Etherboot-developers] GAS 2.95 for compiling etherboot 4.7.24

[Robb M. <ma...@ac...>]

Ken,

Thanks for the guidance.

> But why not upgrade the whole package while you are at it?

My intention was simply to avoid downloading a 6-7MB package (GNU gzip'd
tars) when all I needed was a 200KB binary. No, not because I'm lazy - my
Linux box is currently running 89% full.  Time for a hard drive upgrade, but
I was hoping to put _that_ off until my favourite distro (slackware) rolls a
2.4.x kernel.

> ...I believe, but
> I'm not sure, that binutils 2.x.y contains gas 2.x.y. BTW, the binutils
> numbering scheme is confusing. It only make sense when you realise it
> should really be 2.9.5 and that 2.10.0 is more recent.

Agreed whole-heartedly!

> If I point users to the GNU archive, it may not be the best place to
> obtain updates if they are using a packaged Linux or FreeBSD distro. In
> short, I'd rather users exercise a bit of judgement.

Understood.  I will see if I can scrounge up a bit of judgement while I'm at
it ;-)

Robb.

Re: [Etherboot-developers] GAS 2.95 for compiling etherboot 4.7.24

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

Ken Yap writes:
| >Where can I download an upgrade for gas 2.95 alone?  I would assume you
| >should also update ld, but do you have to upgrade the entire binutils?
| >The GNU site (& mirrors) only distribute the full-blown binutils packages,
| >and it is not clear which binutils version contains gas 2.95 (binutils-2.9.1
| >?).
| 
| If you are using Linux, then rpm -qlp binutils-blah should show you the
| files inside a RPM package, rpm -qip will show you the build notes. dpkg
| should have a similar option. And FreeBSD will have their own scheme for
| sure. Here's a tip. If you don't want to install the whole RPM, you

Yes, FreeBSD is different.  Gas and friends are all part of the base OS.  
We have "ports" which goes and fetching things like EtherBoot applies any 
patches, checks dependancies and then builds it.  Currently the binutils 
that is part of FreeBSD supports everything that EtherBoot needs.  However, 
in the past this was not true so in the "port" it fetched a version of
the binutils and built it.  Then used that to build.  It was a bit
messy but worked.  Now we don't have to do that.  Now the "port"
just fetches the tar-ball and then builds it since all the patches 
are now part of EtherBoot.

Doug A.

Re: [Etherboot-developers] GAS 2.95 for compiling etherboot 4.7.24

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

>Where can I download an upgrade for gas 2.95 alone?  I would assume you
>should also update ld, but do you have to upgrade the entire binutils?
>The GNU site (& mirrors) only distribute the full-blown binutils packages,
>and it is not clear which binutils version contains gas 2.95 (binutils-2.9.1
>?).

If you are using Linux, then rpm -qlp binutils-blah should show you the
files inside a RPM package, rpm -qip will show you the build notes. dpkg
should have a similar option. And FreeBSD will have their own scheme for
sure. Here's a tip. If you don't want to install the whole RPM, you
usually only have to extract the gas binary from such a package, with
something like:

	rpm2cpio binutils-blah | cpio -idmv /path/to/as/binary

But why not upgrade the whole package while you are at it?

>Also, a suggestion - if such a requirement exists, it would be helpful to
>mention it on the etherboot development site (maybe even provide a link to a
>site to obtain gas 2.95, or indicate "binutils vX.X.X or greater").  The
>only mention I found was buried in the change log, and that was seemed
>limited to 'recomended upgrade'.

It is or will be in the user manual, a statement that gas 2.95 is
required. It's also in the file INSTALL. I'm not sure of the
relationship between gas versions and binutil versions. I believe, but
I'm not sure, that binutils 2.x.y contains gas 2.x.y. BTW, the binutils
numbering scheme is confusing. It only make sense when you realise it
should really be 2.9.5 and that 2.10.0 is more recent.

If I point users to the GNU archive, it may not be the best place to
obtain updates if they are using a packaged Linux or FreeBSD distro. In
short, I'd rather users exercise a bit of judgement.

[Etherboot-developers] GAS 2.95 for compiling etherboot 4.7.24

[Robb M. <ma...@ac...>]

> This was mentioned in the mailing lists a while back. If people want to
> add conditionals in the assembly sources to assemble with gas 2.91, I'm
> happy to take patches, but my personal view on this is that people
> should upgrade to gas 2.95. gcc doesn't have to be upgraded.

Where can I download an upgrade for gas 2.95 alone?  I would assume you
should also update ld, but do you have to upgrade the entire binutils?
The GNU site (& mirrors) only distribute the full-blown binutils packages,
and it is not clear which binutils version contains gas 2.95 (binutils-2.9.1
?).

Also, a suggestion - if such a requirement exists, it would be helpful to
mention it on the etherboot development site (maybe even provide a link to a
site to obtain gas 2.95, or indicate "binutils vX.X.X or greater").  The
only mention I found was buried in the change log, and that was seemed
limited to 'recomended upgrade'.

Thanks Ken,
Keep up the good work.

Robb.

Re: [Etherboot-developers] Compile problems with 4.7.24, and cs89x0_disable()

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

|I think it is likely that other assembly source files may have similar
|issues with GAS291 - I didn't try all options in the makefile.

This was mentioned in the mailing lists a while back. If people want to
add conditionals in the assembly sources to assemble with gas 2.91, I'm
happy to take patches, but my personal view on this is that people
should upgrade to gas 2.95. gcc doesn't have to be upgraded.

|I have found that adding a call to the "_reset()" function inside the
|"_disable()" function corrects problems detecting the cs89x0 in the
|compiled-in kernel driver.
|
|static void cs89x0_disable(struct nic *nic)
|{
|    cs89x0_reset(nic);
|}
|
|Without the call to "_reset()", the kernel will always fail to locate the
|cs89x0, unless
|bootparams are used to force a "more aggressive probe(i.e., io=0x301).

Thanks for that patch, will put that in now.

[Etherboot-developers] Compile problems with 4.7.24, and cs89x0_disable()

[Robb M. <ma...@ac...>]

I cannot compile the 4.7.24 etherboot distribution.
I am using old gcc v2.91.66 (and as v2.9.1) tools, and have verified that
the Makefile does properly detect this, and sets the GAS291 flag.

Because this flag is set, "start32.S" is properly compiled, however
"prloader.s" fails, with the following message:
----------------
#as -o bin/prloader.tmp bin/prloader.s
bin/prloader.s: Assembler messages:
bin/prloader.s:163: Error: Ignoring junk ':' after expression
bin/prloader.s:163: Error: operands given don't match any known 386
instruction
bin/prloader.s:219: Error: operands given don't match any known 386
instruction
bin/prloader.s:234: Error: Can't open q for reading.
bin/prloader.s:234: q: No such file or directory
----------------
I did some forensics, and have found issues with "Makefile", and "loader.s",
corrected by the patch below:
----------------
diff -r src/Makefile src_org/Makefile
104c104
< LCONFIG+= -DRELOC=$(RELOCADDR) $(OLDGAS)
---
> LCONFIG+= -DRELOC=$(RELOCADDR)

diff -r src/loader.S src_org/loader.S
205,213c205
< #ifdef GAS291
< # SEG_CS
< # seg cs
<  cs
<  rep
<  movsw
< #else
<         rep movsw %cs:(%si),%es:(%di)
< #endif
---
>         rep movsw %cs:(%si),%es:(%di)
217,220d208
<
<   #ifdef GAS291
<         ljmp     $MOVEROM>>4, $moved-_start     /* reload cs:ip to execute
from RAM */
<   #else
222,230d209
<   #endif
< /*
<   #ifdef GAS291
<  ljmp $MOVEROM>>4,$1f-RELOC
<   #else
<  ljmp $MOVEROM>>4,$1f-_start
<   #endif
< 1:
< */
419,428d397
<   #ifdef GAS291
< /*
<         call    RELOC>>4, 0
<  lcall $RELOC>>4, 0
<  DAMN - can't get the above to work, so use brute force below
< */
<  .byte 0x9A
<  .word 0
<  .word RELOC>>4
<   #else
430d398
<   #endif
----------------
All files are now built, but when I try to create a test floppy with "make
bin32/cs89x0.lzdsk" (or ".dsk"), the process failed again.  Apparently
GAS291 cannot compile the code in "boot1a.s" as compactly as necessary.

Commenting out the ".org PRT_OFF" close to the end of the file allowed me to
generate the attached listing ("boot1a.lst"). Hopefully someone will be able
to see where or how GAS291 is differing from newer GAS, and tweak the code
to allow continued support of "old" installations. I am now committed to
updating my own tools, so this I may even be able to do so myself.

I think it is likely that other assembly source files may have similar
issues with GAS291 - I didn't try all options in the makefile.

Finally, since I can't compile the latest, I have been testing with 4.6.2
I have found that adding a call to the "_reset()" function inside the
"_disable()" function corrects problems detecting the cs89x0 in the
compiled-in kernel driver.

static void cs89x0_disable(struct nic *nic)
{
    cs89x0_reset(nic);
}

Without the call to "_reset()", the kernel will always fail to locate the
cs89x0, unless
bootparams are used to force a "more aggressive probe(i.e., io=0x301).

Regards,
Robb Main.

[Etherboot-developers] Re: Feature request

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

>A special value in 192-207 dhcp entries in the command section that passes
>the etherboot NIC type as a kernel/linux boot parameter.
>
>e.g.
>
>option option-194 "stage3:::/tftpboot/xcat/stage.nbi:::console=ttyS1,9600
>stage3 %v";
>
>%v would be replaced with eepro100 if my etherboot image was for eepro100
>NICs.

The long term plan is to remove menus from the Etherboot core and handle
it using auxiliary programs instead. As explained in the developers
manual, this approach allows the bloat to be taken out of the core while
allowing the menu system to be as fancy as the implementor likes. The
idea of substitutions is a good one, I'll think about how various pieces
of information can be passed down to the auxiliary program.

But don't hold your breath, there are lots of other things on the list
to do. The best way to make it happen is to volunteer to do the work.