etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] SiS900 Etherboot driver available

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

|I have written and released an SiS900 driver for Etherboot.  

Nice going Marty. It will be included in .21 (5.0 RC1) out within a few
days. Thanks.

Re: [Etherboot-developers] Re: Etherboot and FreeBSD

[Michael S. <ms...@wg...>]

I saw on the web site that Eric Biederman sent a short (long but only a few
lines) reply.

I do know that the patch depends on the symbols being after any PT_LOAD
section.  It also depends on there being only one symbol section that is
to be loaded.  Currently this is required by the kernel itself (well, the
order is not) as the boot loader assumes only one symbol section.  (In
fact, it can only take one in the module information stored in the metadata.
At least, only one per metadata as the structure is not set up for that.

-- 
Michael Sinz ---- Worldgate Communications ---- ms...@wg...
A master's secrets are only as good as
	the master's ability to explain them to others.

[Etherboot-developers] SiS900 Etherboot driver available

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

I have written and released an SiS900 driver for Etherboot.  

It is available as a patch to Etherboot version 4.7.20 on

   http://www.thinguin.org/ 

and (for those who require more instant gratification :-) on demand at

   http://rom-o-matic.net/

I have tested this driver with an SiS900 based Asante 10/100 card, and 
have also booted a ThinkNIC (http://www.thinknic.com) computer with it.

"One... Two... You know what to do..." ;-)

Enjoy,

Marty

P.S.

The Etherboot Project is always looking for new developers and users and 
technical writers and fans and... (you get the idea :-)

So, here's a little something to help get you going if you want to become 
involved. I wrote this driver also to help people to get started writing 
Etherboot drivers. Writing drivers is a little like poetry.  

You have to be economical with your code, much like a poet is with words; 
It has been said that poetry is more work per word than other kinds of 
writing;  I think drivers are somewhat like that, but when you get it 
right, you are having an intimate conversation with the hardware, and the 
satisfaction of knowing that somewhere someone is using your code, 
possibly burned into a ROM, and loading an OS, and you helped them.

The rom-o-matic is doing over 800 roms a week now. I haven't looked too 
closely at exactly what people are generating, but I'm only counting 
ROMs, not hits to the site. It's nice to know that people are using this 
resource.  When I get a moment I'd like to release the PHP code for the 
rom-o-matic so others can make sites that provide free services via the 
web.  "It's nice to share".

And so another hack goes in the books.  I'm still more than a little high 
from doing the Etherboot booth at LinuxWorld Expo (there's stuff on 
http://thinguin.org/ about it if you're interested), and we're hoping to 
do a couple more shows before the end of the year.  It should be fun.

That's about it.  Just wanted to let you know that there are real people 
behind this project, and we do it because we believe in the technology, 
and because it's neat, and of course because we enjoy the community.

Come hack with us.

Here's a file I included with this latest driver:

-----------

How I added the SIS900 card to Etherboot

Author: Marty Connor (md...@th...)

Date:   25 February 2001

Description:

This file is intended to help people who want to write an Etherboot
driver or port another driver to Etherboot.  It is a starting point.
Perhaps someday I may write a more detailed description of writing an
Etherboot driver. This text should help get people started, and
studying sis900.[ch] should help show the basic structure and
techniques involved in writing and Etherboot driver.

***********************************************************************

0. Back up all the files I need to modify:

cd etherboot-4.7.20/src
cp Makefile Makefile.orig
cp config.c config.c.orig
cp pci.h pci.h.orig
cp NIC NIC.orig
cp cards.h cards.h.orig

1. Edit src/Makefile to add SIS900FLAGS to defines

SIS900FLAGS=            -DINCLUDE_SIS900

2. edit src/pci.h to add PCI signatures for card

#define PCI_VENDOR_ID_SIS               0x1039
#define PCI_DEVICE_ID_SIS900            0x0900   
#define PCI_DEVICE_ID_SIS7016           0x7016  

3. Edit src/config.c to add the card to the card probe list

#if defined(INCLUDE_NS8390)  || defined(INCLUDE_EEPRO100)  || 
    defined(INCLUDE_LANCE)   || defined(INCLUDE_EPIC100)   || 
    defined(INCLUDE_TULIP)   || defined(INCLUDE_OTULIP)    ||
    defined(INCLUDE_3C90X)   || defined(INCLUDE_3C595)     ||
    defined(INCLUDE_RTL8139) || defined(INCLUDE_VIA_RHINE) || 
    defined(INCLUDE_SIS900)  || defined(INCLUDE_W89C840)

... and ...

#ifdef INCLUDE_SIS900
       { PCI_VENDOR_ID_SIS,             PCI_DEVICE_ID_SIS900,
         "SIS900", 0, 0, 0, 0},
       { PCI_VENDOR_ID_SIS,             PCI_DEVICE_ID_SIS7016,
         "SIS7016", 0, 0, 0, 0},
#endif

... and ...

#ifdef INCLUDE_SIS900
        { "SIS900", sis900_probe, pci_ioaddrs },        
#endif

4. Edit NIC to add sis900 and sis7016 to NIC list

# SIS 900 and SIS 7016
sis900          sis900          0x1039,0x0900
sis7016         sis900          0x1039,0x7016

5. Edit cards.h to add sis900 probe routine declaration

#ifdef  INCLUDE_SIS900
extern struct nic       *sis900_probe(struct nic *, unsigned short *
                        PCI_ARG(struct pci_device *));
#endif

***********************************************************************

At this point, you can begin creating your driver source file.  See
the "Writing an Etherboot Driver" section of the Etherboot
documentation for some hints.  See the skel.c file for a starting
point.  If there is a Linux driver for the card, you may be able to
use that.  Copy and learn from existing Etherboot drivers (this is GPL
/ Open Source software!).

Join the etherboot-developers and etherboot-users mailing lists
(information is on etherboot.sourceforge.net) for information and
assistance. We invite more developers to help improve Etherboot.

Visit the http://etherboot.sourceforge.net, http://thinguin.org, 
http://rom-o-matic.net, and http://ltsp.org sites for information and
assistance.

Enjoy.


---
    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] Re: Etherboot and FreeBSD

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

Michael Sinz <ms...@wg...> writes:

> Ken Yap wrote:
> > 
> > |FreeBSD has a rather nasty design flaw that made me dig into
> > |Etherboot.  I tried to disturb as little as possible in the
> > |patch I submitted (here on this site)
> > |
> > |BTW - This is the first time I have submitted a patch to a
> > |sourceforge run project.  I hope this was the correct way to
> > |do so.
> > 
> > Yes, that's fine, except there are special circumstances for FreeBSD.
> > 
> > |If you have any questions, please feel free to contact me at
> > |the above address and/or mic...@si...
> > 
> > Could you please resubmit to eth...@li....
> > Reason is the main FreeBSD maintainer is on that list. I don't have
> > FreeBSD myself and can't verify your patch. He can tell you if your
> > concerns are valid and if you have fixed it the right way.
> 
> I have tried to submit it on the site and even though I include it
> in the HTTP post, it does not show up on the web site.  Something may
> be wrong (or maybe it does not like what I sent?)
> 
> Anyway, the patch is attached here (and this is going to the
> etherboot-developers list.
> 
> The problem (or not so much problem but design quirk) with FreeBSD
> is that it needs the debugging symbols (if you strip the kernel it
> will not work) to be loaded when the kernel is loaded.  Plus, these
> symbols must be set up in a special way and pointed to via a metadata
> structure that is pointed to by the bootinfo structure that is passed
> as part of the boot process.
> 
> I have made changes to the osloader.c code to support this behavior.
> This lets FreeBSD be loaded via Etherboot for a diskless system
> (such as via DHCPD/BOOTP setups) and work.  This affects only the Elf
> (FreeBSD 3.x/4.x) versions due to the way symbols are handled.
> 
> All of the changes are within the #ifdef IMAGE_FREEBSD sections
> and have been verified in our lab to not interfere with other booting
> processes (and other builds that are not FREEBSD based)

Have you considered something like mkelf-freebsd.  That will take
a free BSD kernel and build an appropriate PT_LOAD section for the
debugging information?

Just skimming your patch I could imagine half a dozen ways it could
fail if something in the freebsd build process  changed in the future.

Eric

Re: [Etherboot-developers] Re: Etherboot and FreeBSD

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

|If I stepped on any toes with the patch posting, I am sorry.  I saw the
|sourceforge project and figured that was the way to do things.  (The main
|other projects I have been involved with were, I would say, handled very
|differently and not via sourceforge so I did not know what the right
|protocol is for a sourceforge handled project.  My bad.)

Nah, no hurt toes at least where I'm concerned. I'm not aware of a
Sourceforge standard for patch submissions. Because Etherboot is a
rather small project, at the moment I'm coordinating contributions. If
it gets larger (hope, hope) then I'll move to a more CVS approach.
Sourceforge is flexible, it has the tools to support a variety of
approaches.

Re: [Etherboot-developers] Re: Etherboot and FreeBSD

[Michael S. <Mic...@si...>]

On Wed, 28 Feb 2001 14:33:56 -0800 (PST), Doug Ambrisko wrote:

>Michael Sinz writes:
>| Ken Yap wrote:
>| > |FreeBSD has a rather nasty design flaw that made me dig into
>| > |Etherboot.  I tried to disturb as little as possible in the
>| > |patch I submitted (here on this site)
>|
>| > Could you please resubmit to eth...@li....
>| > Reason is the main FreeBSD maintainer is on that list. I don't have
>| > FreeBSD myself and can't verify your patch. He can tell you if your
>| > concerns are valid and if you have fixed it the right way.
>
>I've been lurking and listening to his comments on the FreeBSD lists.  What 
>he is doing is valid.  It is my understanding that he is loading the symbol
>tables used for debugging and some other useful things.  I haven't
>run into the problem since for debuging I do remote gdb and I have a
>kernel in the NFS root so it can find things for top and such.

Ahh, so you load via NFS and have the kernel load its own symbols after the
fact?  How well does that actually work?

>| Anyway, the patch is attached here (and this is going to the
>| etherboot-developers list.
>| 
>| The problem (or not so much problem but design quirk) with FreeBSD
>| is that it needs the debugging symbols (if you strip the kernel it
>| will not work) to be loaded when the kernel is loaded.  Plus, these
>
>This is a little strong and mis-leading since several people are apparantly
>using something that doesn't work.  Not to mention some products in the 
>thousands have been using this code for manufacturing so something works.

The base boot works - and FreeBSD 2.x (a.out) worked due to different load
formats.  We were running early test builds without the symbols but this
prevented the kvm tools from working, which included swapon, something
that our servers actually need (yes, I am working on getting the software
to be less of a memory pig, but the situation is rather complex...)

I guess I was most surprised when symbol lookups worked for any static
symbol in the kernel.  There was no "define this as externally accessable"
such as sysctl would do.  That, combined with the lack of documentation of
some of the boot loading process made me an unhappy engineer...  I may need
to reduce my flame thrower a bit otherwise I may get blasted :-)

>| symbols must be set up in a special way and pointed to via a metadata
>| structure that is pointed to by the bootinfo structure that is passed
>| as part of the boot process.
>| 
>| I have made changes to the osloader.c code to support this behavior.
>| This lets FreeBSD be loaded via Etherboot for a diskless system
>| (such as via DHCPD/BOOTP setups) and work.  This affects only the Elf
>| (FreeBSD 3.x/4.x) versions due to the way symbols are handled.
>
>I haven't tried the patches since I've been busy with some other stuff
>but I think the concept is good and the feature is good so I don't see
>any problem with this at a high level.  I'm actually happy to see this
>work being done however wonder why he didn't send email to me directly
>since I'm listed as the maintainer in FreeBSD ports collection.  Maybe
>I missed something.

Sorry about that - we had to get something working ASAP and after running
into what the real problem was and not finding a good solution without a
BIOS change we went with the BIOS change.  (The good part is that we built
the hardware for these clusters and thus were already in a position to
build the BIOS for them...)

If I stepped on any toes with the patch posting, I am sorry.  I saw the
sourceforge project and figured that was the way to do things.  (The main
other projects I have been involved with were, I would say, handled very
differently and not via sourceforge so I did not know what the right
protocol is for a sourceforge handled project.  My bad.)

-- 
Michael Sinz ---- Technology and Engineering Director/Consultant
"Starting Startups"                 mailto:mic...@si...
My place on the web  ------->>  http://www.sinz.org/Michael.Sinz

Re: [Etherboot-developers] Re: Etherboot and FreeBSD

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

Michael Sinz writes:
| Ken Yap wrote:
| > |FreeBSD has a rather nasty design flaw that made me dig into
| > |Etherboot.  I tried to disturb as little as possible in the
| > |patch I submitted (here on this site)
|
| > Could you please resubmit to eth...@li....
| > Reason is the main FreeBSD maintainer is on that list. I don't have
| > FreeBSD myself and can't verify your patch. He can tell you if your
| > concerns are valid and if you have fixed it the right way.

I've been lurking and listening to his comments on the FreeBSD lists.  What 
he is doing is valid.  It is my understanding that he is loading the symbol
tables used for debugging and some other useful things.  I haven't
run into the problem since for debuging I do remote gdb and I have a
kernel in the NFS root so it can find things for top and such.
 
| Anyway, the patch is attached here (and this is going to the
| etherboot-developers list.
| 
| The problem (or not so much problem but design quirk) with FreeBSD
| is that it needs the debugging symbols (if you strip the kernel it
| will not work) to be loaded when the kernel is loaded.  Plus, these

This is a little strong and mis-leading since several people are apparantly
using something that doesn't work.  Not to mention some products in the 
thousands have been using this code for manufacturing so something works.

| symbols must be set up in a special way and pointed to via a metadata
| structure that is pointed to by the bootinfo structure that is passed
| as part of the boot process.
| 
| I have made changes to the osloader.c code to support this behavior.
| This lets FreeBSD be loaded via Etherboot for a diskless system
| (such as via DHCPD/BOOTP setups) and work.  This affects only the Elf
| (FreeBSD 3.x/4.x) versions due to the way symbols are handled.

I haven't tried the patches since I've been busy with some other stuff
but I think the concept is good and the feature is good so I don't see
any problem with this at a high level.  I'm actually happy to see this
work being done however wonder why he didn't send email to me directly
since I'm listed as the maintainer in FreeBSD ports collection.  Maybe
I missed something.

Doug A.

[Etherboot-developers] Re: Etherboot and FreeBSD

[Michael S. <ms...@wg...>]

Ken Yap wrote:
> 
> |FreeBSD has a rather nasty design flaw that made me dig into
> |Etherboot.  I tried to disturb as little as possible in the
> |patch I submitted (here on this site)
> |
> |BTW - This is the first time I have submitted a patch to a
> |sourceforge run project.  I hope this was the correct way to
> |do so.
> 
> Yes, that's fine, except there are special circumstances for FreeBSD.
> 
> |If you have any questions, please feel free to contact me at
> |the above address and/or mic...@si...
> 
> Could you please resubmit to eth...@li....
> Reason is the main FreeBSD maintainer is on that list. I don't have
> FreeBSD myself and can't verify your patch. He can tell you if your
> concerns are valid and if you have fixed it the right way.

I have tried to submit it on the site and even though I include it
in the HTTP post, it does not show up on the web site.  Something may
be wrong (or maybe it does not like what I sent?)

Anyway, the patch is attached here (and this is going to the
etherboot-developers list.

The problem (or not so much problem but design quirk) with FreeBSD
is that it needs the debugging symbols (if you strip the kernel it
will not work) to be loaded when the kernel is loaded.  Plus, these
symbols must be set up in a special way and pointed to via a metadata
structure that is pointed to by the bootinfo structure that is passed
as part of the boot process.

I have made changes to the osloader.c code to support this behavior.
This lets FreeBSD be loaded via Etherboot for a diskless system
(such as via DHCPD/BOOTP setups) and work.  This affects only the Elf
(FreeBSD 3.x/4.x) versions due to the way symbols are handled.

All of the changes are within the #ifdef IMAGE_FREEBSD sections
and have been verified in our lab to not interfere with other booting
processes (and other builds that are not FREEBSD based)

-- 
Michael Sinz ---- Worldgate Communications ---- ms...@wg...
A master's secrets are only as good as
	the master's ability to explain them to others.

Re: [Etherboot-developers] Fix for "kernel" undefined in a FreeBSD mode

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

|Okay, here are a couple of more changes for FreeBSD based on Etherboot 
|version 4.7.20.  The first is a change to the Makefile in the src 

Ok, thanks, they will go into .21.

Re: [Etherboot-developers] Fix for "kernel" undefined in a FreeBSD mode

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

Ken Yap writes:
| Ah thanks. I missed this one. Please mention the version number when
| reporting bugs in future so that I don't wrongly accuse you of being out
| of date.

Okay, here are a couple of more changes for FreeBSD based on Etherboot 
version 4.7.20.  The first is a change to the Makefile in the src 
directory so that if built on FreeBSD enable FreeBSD support options in
Etherboot.  This way if someone builds it on a FreeBSD machine they
shouldn't have to change the Config file to boot a FreeBSD kernel.
The only thing a FreeBSD user needs to build this is gmake.

The second change is to make life easier.  Unfortunately FreeBSD uses
the vendor option tag for swap definition.  The existing hack for 
FreeBSD is okay assuming you have swap defined then you can get into
the more advanced Etherboot options.  However, if you don't want any swap
and don't define it then you can't get into those options.  So if FreeBSD
is defined just set vendorext_isvalid to true.  This doesn't seem to have
caused any trouble for people that I've heard of.  BTW I suggested the prior
hack.

Thanks,

Doug A.

*** Makefile.orig	Thu Feb 22 14:07:37 2001
--- Makefile	Thu Feb 22 14:24:37 2001
***************
*** 93,98 ****
--- 93,101 ----
  CFLAGS32+=	-DVERSION_MAJOR=$(VERSION_MAJOR) \
  		-DVERSION_MINOR=$(VERSION_MINOR) \
  		-DVERSION=\"$(VERSION)\" -DRELOC=$(RELOCADDR) $(OLDGAS)
+ ifeq "$(shell uname -s)" "FreeBSD"
+ CFLAGS32+=	-DIMAGE_FREEBSD -DELF_IMAGE -DAOUT_IMAGE
+ endif
  LCONFIG+=	-DRELOC=$(RELOCADDR)
  
  IDENT32=	'$(VERSION) $(@F) Etherboot (GPL)'


*** main.c.orig	Thu Feb 22 14:24:48 2001
--- main.c	Thu Feb 22 14:30:16 2001
***************
*** 984,990 ****
--- 984,1000 ----
  		memset(motd, 0, sizeof(motd));
  #endif
  		end_of_rfc1533 = NULL;
+ #ifdef	IMAGE_FREEBSD
+ 		/* yes this is a pain FreeBSD uses this for swap, however,
+ 		   there are cases when you don't want swap and then
+ 		   you want this set to get the extra features so lets
+ 		   just set if dealing with FreeBSD.  I haven't run into
+ 		   any troubles with this but I have without it
+ 		*/
+ 		vendorext_isvalid = 1;
+ #else
  		vendorext_isvalid = 0;
+ #endif
  		if (memcmp(p, rfc1533_cookie, 4))
  			return(0); /* no RFC 1533 header found */
  		p += 4;
***************
*** 1047,1057 ****
  			hostnamelen = *(p + 1);
  		}
  		else if (c == RFC1533_VENDOR_MAGIC
- #ifndef	IMAGE_FREEBSD	/* since FreeBSD uses tag 128 for swap definition */
  			 && TAG_LEN(p) >= 6 &&
  			  !memcmp(p+2,vendorext_magic,4) &&
  			  p[6] == RFC1533_VENDOR_MAJOR
- #endif
  			)
  			vendorext_isvalid++;
  #ifdef	IMAGE_FREEBSD
--- 1057,1065 ----

Re: [Etherboot-developers] Fix for "kernel" undefined in a FreeBSD mode

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

>Hmm ... I downloaded 4.7.20 and it wasn't aware there are two 4.7.20's :-)
>
>  770z% pwd
>  /usr/home/ambrisko/etherboot-4.7.20/src
>  770z% grep bi_kernelname *.c
>  osloader.c:        const unsigned char     *bi_kernelname;
>  osloader.c:                     info.bsdinfo.bi_kernelname = kernel;
>  osloader.c:                     info.bsdinfo.bi_kernelname = KERNEL_BUF;
>  770z% 

Ah thanks. I missed this one. Please mention the version number when
reporting bugs in future so that I don't wrongly accuse you of being out
of date.

[Etherboot-developers] Re: AGAIN More analysis to the old problem with etherboot+GRUB (diskless/disk)

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

Hello again,

	I collected all the hints and did a serie of new
experiments. I checked the USE_INTERNA_BUFFER in the
etherboot (not GRUB) as my theory is, that GRUB is slightly
destroyed, not the loaded kernel (primary...)

It was not set, which could produce a problem, if the ethernet
board stays active, after GRUB has done it's relocation.
But there a points speaking against: The NE2000/PCI does not
use this "hack" using memory below 64K, and the problem was
aslo existing. Also tests with a new etherboot image (with usage
of `USE_INTERNAL_BUFFER' does not solve the problem.

Further I want to use the `cmp' command. To be able to get a 
information making sens, I try the following:
- Booting GRUB via EtherBoot
- loading the kernel + modules from floppy disk
--> the result: this kernel also crashes.

So I think, GRUB has internal a problem, if it is booted via 
etherboot. Perhaps I will try to calculate a checksum over the
unpacked image.

With friendly regards

	Christoph Plattner




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

Re: [Etherboot-developers] hacking pxelinux compatibility into etherboot

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

Hello,
	I don't know exactly, if this is interesting for you,
but have a look at GRUB boot loader ....

	http://www.gnu.org/software/grub/

I don't know, was pxe-linux is ...

Cheers
	Christoph P.

"David L. Parsley" wrote:
> 
> Hi Ken,
> 
> To help with my work, I'm going to look into hacking etherboot to behave
> similarly to pxelinux.  Not having looked at the code yet, my current
> plan is this: hack etherboot to check for a boot filename of
> something/pxelinux.bin.  If it finds that name, it will instead tftp the
> config-file something/pxelinux.cfg/(pxelinuxcfgfile*) and parse and use
> it in a similar manner to pxelinux.
> 
> This would make etherboot behave more like a traditional linux
> bootloader, and would simplify things for me greatly.  I reallize it's
> linux-specific, but then, my work is linux-specific. ;-)
> 
> It'll take a while for me to read through the code and figure out how
> best to do this, so I thought I'd check with you and the etherboot-devel
> list to see if anyone had suggestions for the best strategy to
> accomplish this.
> 
> regards,
>         David
> 
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> http://lists.sourceforge.net/lists/listinfo/etherboot-developers


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

[Etherboot-developers] test

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

This is a test. No posts were seen recently. Are anti-spam filters at
Sourceforge working too well?

Re: [Etherboot-developers] More analysis to the old problem with etherboot+GRUB (diskless/disk)

[OKUJI Y. <ok...@ku...>]

From: Marty Connor <md...@th...>
Subject: Re: [Etherboot-developers] More analysis to the old problem with  etherboot+GRUB (diskless/disk)
Date: Thu, 22 Feb 2001 10:08:00 -0500

> What I am wondering is if txb at 0x10000 is incompatible with something 
> that grub is doing.  I think the only drivers that do this are tulip and 
> realtek.  I would try defining USE_INTERNAL_BUFFER and see if that might 
> change your result.  Just a thought.

The macro is always defined in GRUB.

Okuji

Re: [Etherboot-developers] More analysis to the old problem with etherboot+GRUB (diskless/disk)

[OKUJI Y. <ok...@ku...>]

From: Christoph Plattner <chr...@al...>
Subject: Re: [Etherboot-developers] More analysis to the old problem with  etherboot+GRUB (diskless/disk)
Date: Thu, 22 Feb 2001 12:00:10 +0100

> Is there something done or initialized in `stage1' or `start.S'
> which is missed anywhere in `stage2' or `diskless'. I have not
> found anything.

No, I don't think so. But I think it may be possible that nbloader has
a bug in the relocation code.

Okuji

[Etherboot-developers] Re: More analysis to the old problem with etherboot+GRUB (diskless/disk)

[OKUJI Y. <ok...@ku...>]

From: Christoph Plattner <chr...@al...>
Subject: More analysis to the old problem with etherboot+GRUB (diskless/disk)
Date: Thu, 22 Feb 2001 09:45:55 +0100

> So the problem seems not to be direct a problem concerning
> ethernet chip handling. So I have again to analyse the
> differences in those two GRUB versions. Which point can
> influence the loading of this kernel. I really have no
> idea, yet. There are only some lines of C code different.

I think you should investigate if the problem is really because GRUB
loads your kernel incorrectly. To examine that, you can put your
kernel on a local disk and a remote disk and use the command "cmp". If
this command doesn't show any difference between the two files, the
problem is not due to GRUB (or Etherboot), and perhaps due to your
kernel itself.

Okuji

[Etherboot-developers] Re: hacking pxelinux compatibility into etherboot

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

|To help with my work, I'm going to look into hacking etherboot to behave
|similarly to pxelinux.  Not having looked at the code yet, my current
|plan is this: hack etherboot to check for a boot filename of
|something/pxelinux.bin.  If it finds that name, it will instead tftp the
|config-file something/pxelinux.cfg/(pxelinuxcfgfile*) and parse and use
|it in a similar manner to pxelinux.

From what I understand of PXE, this is only the tip of the iceberg. You
need callbacks to implement the whole of PXE. But if you just want to
parse a config file, that should be doable. Just make sure to #ifdef
your enhancements so that they are optional.

Re: [Etherboot-developers] Fix for "kernel" undefined in a FreeBSD mode

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

Ken Yap writes:
| |FYI, when the "kernel" variable was changed this occurance was missed which
| |causes it to fail to compile.
| 
| Thanks. Already fixed in 4.7.20.

Hmm ... I downloaded 4.7.20 and it wasn't aware there are two 4.7.20's :-)

  770z% pwd
  /usr/home/ambrisko/etherboot-4.7.20/src
  770z% grep bi_kernelname *.c
  osloader.c:        const unsigned char     *bi_kernelname;
  osloader.c:                     info.bsdinfo.bi_kernelname = kernel;
  osloader.c:                     info.bsdinfo.bi_kernelname = KERNEL_BUF;
  770z% 
 
| BTW Luigi Rizzo is doing a FreeBSD port of 4.7.20. Perhaps you should
| arrange to avoid duplicating work.

Well he is working on improving it ... it is already ported to FreeBSD.
And yes we are working together.  He has some ideas to make things better
as do I (ie. if compiling on FreeBSD then turn on FreeBSD kernel support).
I will probably put it together early next week and post them.  It won't
help rom-a-matic but it is easy enough to just enable the FreeBSD options
in that.

Doug A.

[Etherboot-developers] hacking pxelinux compatibility into etherboot

[David L. P. <pa...@li...>]

Hi Ken,

To help with my work, I'm going to look into hacking etherboot to behave
similarly to pxelinux.  Not having looked at the code yet, my current
plan is this: hack etherboot to check for a boot filename of
something/pxelinux.bin.  If it finds that name, it will instead tftp the
config-file something/pxelinux.cfg/(pxelinuxcfgfile*) and parse and use
it in a similar manner to pxelinux.

This would make etherboot behave more like a traditional linux
bootloader, and would simplify things for me greatly.  I reallize it's
linux-specific, but then, my work is linux-specific. ;-)

It'll take a while for me to read through the code and figure out how
best to do this, so I thought I'd check with you and the etherboot-devel
list to see if anyone had suggestions for the best strategy to
accomplish this.

regards,
	David

Re: [Etherboot-developers] More analysis to the old problem with etherboot+GRUB (diskless/disk)

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

On 2/22/2001 6:00 AM Christoph Plattner chr...@al... 
wrote:
>Is there something done or initialized in `stage1' or `start.S'
>which is missed anywhere in `stage2' or `diskless'. I have not
>found anything.
>My first idea was the STACK, but it is defined in `asm.S'. The 
>only thing `start.S' passes to `asm.S' is the boot driver, which
>is ignored in `asm.S' in diskless binary.

Which Etherboot driver are you using?  There was a mod made some time ago 
to a couple of the larger Etherboot drivers:

   /* transmit descriptor and buffer */
   static struct txdesc txd __attribute__ ((aligned(4)));
   #ifndef USE_INTERNAL_BUFFER
   #define txb ((char *)0x10000 - BUFLEN)
   #else
   static unsigned char txb[BUFLEN] __attribute__ ((aligned(4)));
   #endif

What I am wondering is if txb at 0x10000 is incompatible with something 
that grub is doing.  I think the only drivers that do this are tulip and 
realtek.  I would try defining USE_INTERNAL_BUFFER and see if that might 
change your result.  Just a thought.

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] More analysis to the old problem with etherboot+GRUB (diskless/disk)

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

So Mr. OKUJI,

	here a question to you in that stuff. Lets see the 
structure of the parts of GRUB:

	stage1
	stage2   or   diskless
	start    or   nbloader
	
My two scenarios:

	booting   stage1 > start > diskless 	--> works
	booting   nbloader > diskless		--> fails !

Is there something done or initialized in `stage1' or `start.S'
which is missed anywhere in `stage2' or `diskless'. I have not
found anything.

My first idea was the STACK, but it is defined in `asm.S'. The 
only thing `start.S' passes to `asm.S' is the boot driver, which
is ignored in `asm.S' in diskless binary.
	
Cheers

	Christoph P.



Christoph Plattner wrote:
> 
> Further experiment: It has nothing to do with the DISKLESS GRUB
> version. I booted the "diskless GRUB" from floppy, prepared in
> the following way:
> 
>         in stage2/ :
>         cat start diskless > stage2-diskless
> 
>         then stage1 and stage2 on a floppy with `dd'
> 
> ... and booted. This GRUB works correct, does a bootp, loads the
> menu definedwith `T150="...."' and boots CORECCTLY !!! (no crash !)
> 
> So really diskless booed GRUB has a problem (independent of GRUB
> itself) !
> 
> Etherboot problem ?
> Is GRUB not completely loaded in RAM ?
> 
> Cheers
>         Christoph
> 
> Christoph Plattner wrote:
> >
> > Hello GRUB and Etherboot people,
> >
> >         finally I had some time to further analysing the
> > problem, I describer a week ago.
> >
> > The problem was: I can boot our (company's) OS (multiboot,
> > loaded at 1MB) with a GRUB booted by floppy, kernel and
> > modules loaded via tftp (plus bootp before...)
> >
> > The OS crashes, if I do the same on a diskless booted GRUB.
> >
> > Discussions with KEN YAP leads me to the fact, that the
> > problem is the ethernet board used twice and is perhaps
> > not resetted in the correct way. So I did an experiement
> > unsing to different types of ethernet boards. A working
> > combination was a NE2000/PCI for etherboot and the i82559
> > or 559er base board for the GRUB to download.
> >
> > The result: THE SAME. The kernel crashes.
> > (By the way, I also tried to embedd the eepro100.c file
> > of 4.7.18 into GRUB to have the newest driver... there !).
> >
> > So the problem seems not to be direct a problem concerning
> > ethernet chip handling. So I have again to analyse the
> > differences in those two GRUB versions. Which point can
> > influence the loading of this kernel. I really have no
> > idea, yet. There are only some lines of C code different.
> >
> > And I often use diskless GRUB + Etherboot for Linux, and
> > I never had problems... on really many different machines
> > and embedded industrial PCs.
> >
> > With friendly regards
> >
> >         Christoph P.
> >
> > -----------------------------------------------------------------
> > private:        chr...@do...
> > company:        chr...@al...
> >
> > _______________________________________________
> > Etherboot-developers mailing list
> > Eth...@li...
> > http://lists.sourceforge.net/lists/listinfo/etherboot-developers
> 
> -----------------------------------------------------------------
> private:        chr...@do...
> company:        chr...@al...
> 
> _______________________________________________
> Bug-grub mailing list
> Bug...@gn...
> http://mail.gnu.org/mailman/listinfo/bug-grub


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

Re: [Etherboot-developers] More analysis to the old problem with etherboot+GRUB (diskless/disk)

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

Further experiment: It has nothing to do with the DISKLESS GRUB
version. I booted the "diskless GRUB" from floppy, prepared in
the following way:

	in stage2/ :
	cat start diskless > stage2-diskless

	then stage1 and stage2 on a floppy with `dd'

... and booted. This GRUB works correct, does a bootp, loads the
menu definedwith `T150="...."' and boots CORECCTLY !!! (no crash !)

So really diskless booed GRUB has a problem (independent of GRUB
itself) !

Etherboot problem ?
Is GRUB not completely loaded in RAM ?

Cheers
	Christoph

Christoph Plattner wrote:
> 
> Hello GRUB and Etherboot people,
> 
>         finally I had some time to further analysing the
> problem, I describer a week ago.
> 
> The problem was: I can boot our (company's) OS (multiboot,
> loaded at 1MB) with a GRUB booted by floppy, kernel and
> modules loaded via tftp (plus bootp before...)
> 
> The OS crashes, if I do the same on a diskless booted GRUB.
> 
> Discussions with KEN YAP leads me to the fact, that the
> problem is the ethernet board used twice and is perhaps
> not resetted in the correct way. So I did an experiement
> unsing to different types of ethernet boards. A working
> combination was a NE2000/PCI for etherboot and the i82559
> or 559er base board for the GRUB to download.
> 
> The result: THE SAME. The kernel crashes.
> (By the way, I also tried to embedd the eepro100.c file
> of 4.7.18 into GRUB to have the newest driver... there !).
> 
> So the problem seems not to be direct a problem concerning
> ethernet chip handling. So I have again to analyse the
> differences in those two GRUB versions. Which point can
> influence the loading of this kernel. I really have no
> idea, yet. There are only some lines of C code different.
> 
> And I often use diskless GRUB + Etherboot for Linux, and
> I never had problems... on really many different machines
> and embedded industrial PCs.
> 
> With friendly regards
> 
>         Christoph P.
> 
> -----------------------------------------------------------------
> private:        chr...@do...
> company:        chr...@al...
> 
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> http://lists.sourceforge.net/lists/listinfo/etherboot-developers

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

[Etherboot-developers] More analysis to the old problem with etherboot+GRUB (diskless/disk)

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

Hello GRUB and Etherboot people,

	finally I had some time to further analysing the
problem, I describer a week ago. 

The problem was: I can boot our (company's) OS (multiboot,
loaded at 1MB) with a GRUB booted by floppy, kernel and
modules loaded via tftp (plus bootp before...)

The OS crashes, if I do the same on a diskless booted GRUB.

Discussions with KEN YAP leads me to the fact, that the 
problem is the ethernet board used twice and is perhaps
not resetted in the correct way. So I did an experiement
unsing to different types of ethernet boards. A working
combination was a NE2000/PCI for etherboot and the i82559
or 559er base board for the GRUB to download.

The result: THE SAME. The kernel crashes.
(By the way, I also tried to embedd the eepro100.c file
of 4.7.18 into GRUB to have the newest driver... there !).

So the problem seems not to be direct a problem concerning
ethernet chip handling. So I have again to analyse the
differences in those two GRUB versions. Which point can
influence the loading of this kernel. I really have no
idea, yet. There are only some lines of C code different.

And I often use diskless GRUB + Etherboot for Linux, and
I never had problems... on really many different machines
and embedded industrial PCs.

With friendly regards

	Christoph P.


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

Re: [Etherboot-developers] Fix for "kernel" undefined in a FreeBSD mode

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

|FYI, when the "kernel" variable was changed this occurance was missed which
|causes it to fail to compile.

Thanks. Already fixed in 4.7.20.

BTW Luigi Rizzo is doing a FreeBSD port of 4.7.20. Perhaps you should
arrange to avoid duplicating work.