etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] [COMMIT]architecture option... [RFC] option handling...

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

Michael Brown <mb...@fe...> writes:


> There is a sample DHCPD config file in
> contrib/initrd/dhcpd.conf.etherboot.include.  If you can achieve what is
> in there using vendor-encapsulated-options then one of my two objections
> to using VEO will disappear.


O.k. I just did the research and testing.  In addition to saying:
option etherboot-encapsulated-options code 43 = encapsulate etherboot;

It is also necessary to say:
vendor-option-space etherboot;


The vendor-option-space specifies which option space to use when
reading vendor-encapsulated options.

Eric

Re: [Etherboot-developers] Fwd: Bug-report for rom-o-matic.net: etherboot 5.1.3 + NFS issues

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

On Friday, December 13, 2002, at 08:44  AM, Ken Yap wrote:
>> Could this be a Makefile problem?
>>
>>> 	In file included from ns8390.c:29:
>>> 	etherboot.h:88: #error No download protocol defined!
>>> 	make: *** [bin32/ns8390.o] Error 1
>>> 	make: Leaving directory /tmp/ROMrzFVEe'
>
> No, typo. Look at etherboot.h:88 and it will be obvious.

Thanks for finding it. Patched on rom-o-matic.net 5.1.3.

-- 
     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...@et...
     Web: http://www.etherboot.org/

Re: [Etherboot-developers] Fwd: Bug-report for rom-o-matic.net: etherboot 5.1.3 + NFS issues

[<ke...@us...>]

>Could this be a Makefile problem?
>
>> 	In file included from ns8390.c:29:
>> 	etherboot.h:88: #error No download protocol defined!
>> 	make: *** [bin32/ns8390.o] Error 1
>> 	make: Leaving directory /tmp/ROMrzFVEe'

No, typo. Look at etherboot.h:88 and it will be obvious.

[Etherboot-developers] Fwd: Bug-report for rom-o-matic.net: etherboot 5.1.3 + NFS issues

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

Could this be a Makefile problem?

Begin forwarded message:
> From: Alexander Koch <ak...@ne...>
> Date: Fri Dec 13, 2002  5:26:14  AM US/Eastern
> To: web...@en...
> Subject: Bug-report for rom-o-matic.net: etherboot 5.1.3 + NFS issues
>
> Hi there,
>
> First off, i'd like to thank you for providing rom-o-matic.net -- very 
> nice
> idea! it saved me time and hassle.
>
> Now, for my bug-report:
>
> It seems that your etherboot 5.1.3 dev-release on 
> http://rom-o-matic.net
> does not properly support booting from NFS -- while trying to download 
> a
> customized rom-image, i encountered the following build error:
>
> 	rtl8029 Build Failed
> 	------------------------------------------
> 	Build failed. Status = 2.
>
> 	Following is the output from make:
>
> 	make: Entering directory /tmp/ROMrzFVEe'
> 	kgcc -DCONGESTED -DBACKOFF_LIMIT=7 -DTRY_FLOPPY_FIRST=0 
> -DTAGGED_IMAGE -DELF_IMAGE -DDOWNLOAD_PROTO_NFS -DCOMCONSOLE=0x3F8 
> -DCONSPEED=9600 -DCOMPARM=0x03 -DPOWERSAVE -DPCBIOS 
> -DALLOW_ONLY_ENCAPSULATED -DBOOT_FIRST=BOOT_NIC 
> -DBOOT_SECOND=BOOT_NOTHING -DBOOT_THIRD=BOOT_NOTHING -DCONFIG_PCI -Os 
> -ffreestanding -fstrength-reduce -fomit-frame-pointer -mcpu=i386 
> -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W 
> -Wno-format -DVERSION_MAJOR=5 -DVERSION_MINOR=1 -DVERSION=\"5.1.3\" 
> -DRELOC=0x20000  -DINCLUDE_NS8390	 -o bin32/ns8390.o -c ns8390.c
> 	In file included from ns8390.c:29:
> 	etherboot.h:88: #error No download protocol defined!
> 	make: *** [bin32/ns8390.o] Error 1
> 	make: Leaving directory /tmp/ROMrzFVEe'
> 	------------------------------------------
>
> On the config page, all options were unset except for the following:
>
> 	( rtl8029 ROM-o-matic configuration for Etherboot version 5.1.3 )
>
> 	  ASK_BOOT: -1
> 	CONGESTED
> 	  BACKOFF_LIMIT: 7
> 	TAGGED_IMAGE
> 	ELF_IMAGE
> 	DOWNLOAD_PROTO_NFS
> 	MOVEROM
> 	POWERSAVE
> 	PCBIOS
> 	ALLOW_ONLY_ENCAPSULATED
> 	  BOOT_FIRST: BOOT_NIC
> 	  BOOT_SECOND: BOOT_NOTHING
> 	  BOOT_THIRD: BOOT_NOTHING
> 	  DEFAULT_BOOTFILE:
> 	CONFIG_PCI
>
>
> When i tried the same with the 5.0.8 stable-release, everything worked 
> fine.
>
> Regards,
>
> --Alexander Koch

[Etherboot-developers] [COMMIT] osloader.c splitup....

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

O.k. I have split osloader.c into a host of small files one per loader
type.  osloader.c #includes them since there seemed to be some
noticeable size benefits to inlining the probe routines last time I
measured.

Most of the loaders have now been moved to arch/i386/core, with
the exception of the elf loader which works on multiple platforms.

For the tree this should be the last of the major changes...

I still need to generalize the elf parameter massing and update mkelf
so it can auto-detect the format.  I have the code for ia64, but until
I get it for i386, I want to leave a working etherboot in the CVS
repository.

I have also added the directories that will hold the itanium port, but
I have not yet put in any of the code.   I have made a few small
corrections as I merged the i386 code, which I need to make into
the Itanium code before I can expect it to work.  But that should come
soon.

Eric

Re: [Etherboot-developers] [COMMIT]architecture option... [RFC] option handling...

[Michael B. <mb...@fe...>]

On 12 Dec 2002, Eric W. Biederman wrote:
> > Not quite sure what you mean here.  Etherboot will accept any of the old
> > Etherboot-specific options inside an etherboot-encapsulated-options field
> > (i.e. a dhcp option 150).
> But all such options have been removed from the core of etherboot,
> with I believe the removal of the image menu.

True enough; I was looking at the 5.0 code which still has plenty.

> Options always interpreted:
> RFC1533_PAD
> RFC1533_END
> RFC1533_EXTENSIONPATH /* STD tftp file name of more options */
> Options that are never used in encapsulated options:
> RFC1533_NETMASK       /* Standard */
> RFC1533_GATEWAY       /* Standard */
> RFC1533_VENDOR        /* Vendor encapsulated options */
> RFC2132_MSG_TYPE      /* Standard */
> RFC2132_SRV_ID        /* Standard */
> RFC1533_HOSTNAME      /* Standard */
> RFC1533_VENDOR_ETHERBOOT_ENCAP  /* Only truly etherboot specific option */
> Options only interpreted in encapsulated options:
> RFC1533_VENDOR_MAGIC   /* Only option really used.. */
> RFC1533_VENDOR_HOWTO /* FreeBSD only */
> RFC1533_VENDOR_KERNEL_ENV /* FreeBSD only */
> The only place etherboot specific options show up is in the code of mknbi....

Etherboot-specific options 175 (and now also 177) are used as well, to
pass information to the DHCP server inside an etherboot-encapsulated-
options field.

Michael

Re: [Etherboot-developers] Intel 82540em Gigabit cards seen on Optiplex Sx260 not DHCPing

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

ebi...@ln... (Eric W. Biederman) writes:

> Zameer Ahmed <za...@sy...> writes:
> 
> 
> > Searching for server (DHCP)...
> > _
> > 
> 
> How very odd I just reproduced this.  Then I turned the machine off and back
> on and the problem went away...

And I think I see what is going on.
There is this loop in the transmit function:

	while (!(txp->upper.data & E1000_TXD_STAT_DD)) {
		udelay (10);	/* give the nic a chance to write to the register */
		poll_interruptions();
	}

And if you never see any dots on the line after 
"Searching for server (DHCP)..."
Then the transmit function never returns.
With that being the only loop that must be where it is hanging.

As to what causes it to hang I do not yet know.

Given that we call functions that may modify memory in arbitrary
ways I do not see the compiler over optimizing this, but
on some random compiles I have seen it hang there...

Eric

Re: [Etherboot-developers] Intel 82540em Gigabit cards seen on Optiplex Sx260 not DHCPing

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

Zameer Ahmed <za...@sy...> writes:


> Searching for server (DHCP)...
> _
> 

How very odd I just reproduced this.  Then I turned the machine off and back
on and the problem went away...
Eric

Re: [Etherboot-developers] [COMMIT]architecture option... [RFC] option handling...

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

Michael Brown <mb...@fe...> writes:

> On 12 Dec 2002, Eric W. Biederman wrote:
> > Currently etherboot does not interpret any encapsulated options
> > (except in the case of FreeBSD).
> 
> Not quite sure what you mean here.  Etherboot will accept any of the old
> Etherboot-specific options inside an etherboot-encapsulated-options field
> (i.e. a dhcp option 150).  

But all such options have been removed from the core of etherboot,
with I believe the removal of the image menu.

Options always interpreted:
RFC1533_PAD
RFC1533_END
RFC1533_EXTENSIONPATH /* STD tftp file name of more options */
Options that are never used in encapsulated options:
RFC1533_NETMASK       /* Standard */
RFC1533_GATEWAY       /* Standard */
RFC1533_VENDOR        /* Vendor encapsulated options */
RFC2132_MSG_TYPE      /* Standard */
RFC2132_SRV_ID        /* Standard */
RFC1533_HOSTNAME      /* Standard */
RFC1533_VENDOR_ETHERBOOT_ENCAP  /* Only truly etherboot specific option */
Options only interpreted in encapsulated options:
RFC1533_VENDOR_MAGIC   /* Only option really used.. */
RFC1533_VENDOR_HOWTO /* FreeBSD only */
RFC1533_VENDOR_KERNEL_ENV /* FreeBSD only */

The only place etherboot specific options show up is in the code of mknbi....
 
> Option 128 is marked as ENCAP_OPT hence if ALLOW_ONLY_ENCAPSULATED is
> defined then it is valid only within etherboot-encapsulated-options and
> hence acts as a magic signature for the etherboot-encapsulated-options
> field.

I missed that one, so yes we have something that works there.

> > With respect to transmitting options I am less certain on how that
> > should be handled.  But my gut impression says vendor encapsulated
> > options is the way to go.  But it has been suggested that dhcpv3
> > cannot parse those options.  I will at least want to verify that
> > before I go any further.
> 
> There is a sample DHCPD config file in
> contrib/initrd/dhcpd.conf.etherboot.include.  If you can achieve what is
> in there using vendor-encapsulated-options then one of my two objections
> to using VEO will disappear.

Thanks, I will take a look.

Eric

Re: [Etherboot-developers] [COMMIT]architecture option... [RFC] option handling...

[Michael B. <mb...@fe...>]

On 12 Dec 2002, Eric W. Biederman wrote:
> Currently etherboot does not interpret any encapsulated options
> (except in the case of FreeBSD).

Not quite sure what you mean here.  Etherboot will accept any of the old
Etherboot-specific options inside an etherboot-encapsulated-options field
(i.e. a dhcp option 150).  There is an option #define
ALLOW_ONLY_ENCAPSULATED which will cause it to ignore Etherboot-specific
options that are *not* in an etherboot-encapsulated-options field.  This
option is undefined by default in order to preserve backwards
compatibility.

> When using encapsulated options we are not checking for a magic signature.

We still check for the magic signature in option 128.  If
ALLOW_ONLY_ENCAPSULATED is defined then this option will be accepted only
if it is found within etherboot-encapsulated-options.

There are two macros defined that are used in main.c to mark whether or
not an option should be treated as in the Etherboot encapsulated
namespace.  If an option is marked is NON_ENCAP_OPT then it will be
ignored if found within an etherboot-encapsulated-options field.  If an
option is marked as ENCAP_OPT then it will be ignored if found outside an
etherboot-encapsulated-options field (but only if ALLOW_ONLY_ENCAPSULATED
is defined).  If an option is not marked as either then it will be
accepted anywhere.

Option 128 is marked as ENCAP_OPT hence if ALLOW_ONLY_ENCAPSULATED is
defined then it is valid only within etherboot-encapsulated-options and
hence acts as a magic signature for the etherboot-encapsulated-options
field.

> With respect to transmitting options I am less certain on how that
> should be handled.  But my gut impression says vendor encapsulated
> options is the way to go.  But it has been suggested that dhcpv3
> cannot parse those options.  I will at least want to verify that
> before I go any further.

There is a sample DHCPD config file in
contrib/initrd/dhcpd.conf.etherboot.include.  If you can achieve what is
in there using vendor-encapsulated-options then one of my two objections
to using VEO will disappear.

Michael Brown
http://www.fensystems.co.uk

Re: [Etherboot-developers] .ebi and .elf formats

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

On Thursday, December 12, 2002, at 09:02  PM, Ken Yap wrote:
> Maybe you could assume that anybody using LinuxBIOS knows what they 
> are doing and knows that only PCI NICs are supported?

I could, but if I can easily check for the condition when they press 
"Configure" or "Get ROM", I could put up a clear error message so as to 
avoid the delightful emails asking why build failed for 3C509B cards ;)

-- 
     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...@et...
     Web: http://www.etherboot.org/

Re: [Etherboot-developers] .ebi and .elf formats

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

Marty Connor <md...@et...> writes:

> I'm working on fixing defaults for LinuxBIOS Etherboot formats on
> rom-o-matic.net, and need some clarification on what .ebi and .elf formats
> are. As far as I can tell, the .ebi format is not used anymore and can be
> removed in 5.0.7, 5.0.8, and 5.1.3. The only reference to .ebi is in the "make
> clean" section in 5.0.7 and .8, so I'm pretty sure .ebi is gone.
> 
> Am I correct in thinking .elf is now the interesting format for LinuxBIOS
> support?

Yes.  They were aliases, and .elf was clearer, than .ebi for Elf Boot Image....
In 5.1.x .elf should not be restricted to just LinuxBIOS.  Allowing etherboot
to boot itself without running mknbi-rom.
 
> Next question, is it the case that LinuxBIOS support works only with PCI NICs?

Only because I have never fixed the makefile rules.  There is no inherent reason
only PCI NICs should be supported.

Point out bugs like that and we can get them fixed.

> I seem to recall this, and so far I only seem to be able to build a .elf with
> eepro100 selected.  Is this correct?  How could I determine which NICs I could
> make .elf images with?

The all should work, in principle.  Though with the .elf prefix you may
be restricted to the family and not the exact model.  With no pci id in the
header there is no reason to do anything differently.

The restrictions are all due to strange makefile rules, and not due to any inherent
limitations of LinuxBIOS or etherboot.

> Thanks for the help,

Welcome,
Eric

Re: [Etherboot-developers] .ebi and .elf formats

[<ke...@us...>]

>Next question, is it the case that LinuxBIOS support works only with 
>PCI NICs? I seem to recall this, and so far I only seem to be able to 
>build a .elf with eepro100 selected.  Is this correct?  How could I 
>determine which NICs I could make .elf images with?

Maybe you could assume that anybody using LinuxBIOS knows what they are
doing and knows that only PCI NICs are supported?

[Etherboot-developers] .ebi and .elf formats

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

I'm working on fixing defaults for LinuxBIOS Etherboot formats on 
rom-o-matic.net, and need some clarification on what .ebi and .elf 
formats are. As far as I can tell, the .ebi format is not used anymore 
and can be removed in 5.0.7, 5.0.8, and 5.1.3. The only reference to 
.ebi is in the "make clean" section in 5.0.7 and .8, so I'm pretty sure 
.ebi is gone.

Am I correct in thinking .elf is now the interesting format for 
LinuxBIOS support?

Next question, is it the case that LinuxBIOS support works only with 
PCI NICs? I seem to recall this, and so far I only seem to be able to 
build a .elf with eepro100 selected.  Is this correct?  How could I 
determine which NICs I could make .elf images with?

Thanks for the help,

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...@et...
     Web: http://www.etherboot.org/

[Etherboot-developers] [COMMIT]architecture option... [RFC] option handling...

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

O.k. Etherboot is now passing it's current architecture, in dhcp options.
I am currently using encapsulated option #177.

What we are doing and what we wish to accomplish with the DHCP options
needs to documented clearly, and scrubbed a little bit.  For the moment
I don't want to break the code so I have not done anything radical.

Currently etherboot does not interpret any encapsulated options
(except in the case of FreeBSD).

When using encapsulated options we are not checking for a magic signature.

The code that uses the non-standard DHCP options is now in mknbi,
and it doesn't use encapsulated options.

For a reference case PXE uses vendor encapsulated options, which
makes it likely we won't run into problems if we use it as well.  Especially
if we require a signature option immediate inside of the vendor encapsulated 
options.

In addition we do expect a vendor encapsulated option with REQUIRE_VCI_ETHERBOOT.
So placing more options in the vendor encapsulated options field sounds
quite reasonable to me.

With respect to transmitting options I am less certain on how that
should be handled.  But my gut impression says vendor encapsulated
options is the way to go.  But it has been suggested that dhcpv3
cannot parse those options.  I will at least want to verify that
before I go any further.

Cleaning all of this up should also reduce our code size as well,
which is probably the good etherboot reason for doing it.

With respect to conflicts in the vendor encapsulated options field,
if we require VCI etherboot to be present before looking at any
of the other tags we should be safe in assuming the tags are etherboot
safe.  And the tag can be sent a second time for strange clients
that also want to use VCI etherboot.

Eric

Re: [Etherboot-developers] I've fixed the problem with net booting dos with PXE to EB to DOS

[Matthew S. <sta...@ho...>]

> >How should I submit the changes to the code or has this problem >That's 
>wonderful, you've finally fixed a long standing bug. If the fixes
>aren't too large, say > 10kB, just post them to this developer list

Here is the code to fixed the problem with net booting dos with PXE to EB to 
DOS.  The line numbers lists are from the original code.

Changes to src/loader.S:

lines 209 - 212

pnpentry:
	movw	$0,%ax
#else /* PXELOADER */
#define PXENV_STOP_UNDI		0x15
#define PXENV_UNDI_SHUTDOWN	0x05

lines 244 - 247

hellomsgend:
pxe_stop_undi_pkt:
	.word	0
pxe_undi_shutdown_pkt:
	.word	0
pxe_unload_stack_pkt:

lines 318 - 327

	pushw	%cs
	pushw	$pxe_undi_shutdown_pkt
	pushw	$PXENV_UNDI_SHUTDOWN
	lcall	*%cs:(PXEEntry-_start)
	add	$6, %sp
	pushw	%cs
	pushw	$pxe_stop_undi_pkt
	pushw	$PXENV_STOP_UNDI
	lcall	*%cs:(PXEEntry-_start)
	add	$6, %sp
	pushw	%cs
	pushw	$pxe_unload_stack_pkt
	pushw	$PXENV_UNLOAD_STACK
	lcall	*%cs:(PXEEntry-_start)
	add	$6, %sp

lines 367 - 380 (Turn memory count into ASCII hexadecimal characters)

	mov	%bl, %al
	shr	$4, %al
/*	daa
	cmp	$9, %al
	sbb	$0xcf, %al */
	cmp	$10, %al	/* These three lines written by Norbert Juffa 
<nor...@am...> */
	sbb	$0x69, %al
	das
	mov	%al, pxeKmsg-_start+3
	mov	%bl, %al
	and	$0x0f, %al
/*	daa */              /* no carry here */
/*	cmp	$9, %al
	sbb	$0xcf, %al */
	cmp	$10, %al
	sbb	$0x69, %al
	das
	mov	%al, pxeKmsg-_start+4
	movw	$0x0a0d, pxemsg-_start   /* "\r\n" */

The three new lines to convert hex into ASCII characters were found at the 
following web site: http://www.df.lth.se/~john_e/gems/gem003a.html.

NOTE: Since this was a quick fix, there is no error checking.  If anyone has 
any older versions of the PXE Specifications they might want to check if 
PXENV_STOP_UNDI has always been implemented or if it's definitions are any 
different to the definition in version 2.1 and whether that will effect this 
new code.

>Great. If you like reading the PXE spec, maybe you can do Etherboot on top 
>of
>PXE's UNDI without using an Etherboot's native network driver :). This, of
>course, is an option in addition to using the native driver.

Is anyone else already working on an Etherboot UNDI driver?  I am interested 
in working on one, but probably won't be able to start for a while.

Matthew Stapleton
Email: sta...@ho...


_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE* 
http://join.msn.com/?page=features/virus

[Etherboot-developers] 3c900 not working ...

[Paul M. <pa...@as...>]

Hi,

I've been trying to get an old 3c900(B?) combo card working with
etherboot-5.0.8, initially via a floppy boot.

Etherboot detected the card correctly, chose to use the UTP media option
and got as far as attempting to send its first ethernet frame (DHCP
discovery) before hanging.

Being of an inquisitive nature, I tracked the problem down to line 206 of
3c595.c If I understand this correctly, this is a tight loop that waits
for the FIFO buffer to become sufficiently free that it has space for the
first packet.  The problem is FREE_TX is always returning 0 :^/

I was using the Linux driver as a comparison (to try and figure out how
things worked) and I noticed something odd.  In 2.4.19 (what I had to
hand), there's a discrepancy between what Linux uses for the offset and
what etherboot does.  In Linux (3c59x.c line 626)

> /* Register window 1 offsets, the window used in normal operation.
>    On the Vortex this window is always mapped at offsets 0x10-0x1f. */
> enum Window1 {
>         TX_FIFO = 0x10,  RX_FIFO = 0x10,  RxErrors = 0x14,
>         RxStatus = 0x18,  Timer=0x1A, TxStatus = 0x1B,
>         TxFree = 0x1C, /* Remaining free bytes in Tx buffer. */
> };

Also, the Linux driver never sets the Window to 1.  So Window 1 could be
repeated, at the slightly higher offsets for (my) Boomerang card, not just
the Vortex.

Whereas, in etherboot, there's (3c595.h line 137 onwards)
> /*
>  * Window 1 registers. Operating Set.
>  */
[...]
> #define VX_W1_FREE_TX           0x0c

The etherboot driver *does* change the Window to 1. This could explain the 
discrepancy in offsets. 

I tried changing VX_W1_FREE_TX to 0x1c, but the card still returned 0x0
for each query of FREE_TX.

Any suggestions?

Cheers,

Paul.

PS
The card works perfectly under Linux, btw.

PPS
Please CC emails to me as I'm not subscribed to the list


-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
Particle Physics (Theory & Experimental) Groups                   Paul Millar 
Department of Physics and Astronomy                     pa...@as...
University of Glasgow                                 pa...@ph...
Glasgow, G12 8QQ, Scotland             http://www.astro.gla.ac.uk/users/paulm 
+44 (0)141 330 4717        A54C A9FC 6A77 1664 2E4E  90E3 FFD2 704B BF0F 03E9
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

Re: [Etherboot-developers] Intel 82540em Gigabit cards seen on Optiplex Sx260 not DHCPing

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

Zameer Ahmed <za...@sy...> writes:
> 
> >There is a
> >#define DEBUG 0
> >at the top of file.  Could you change that to 
> >#define DEBUG 3
> >
> > And then send the output?
> I downloaded the source, made above changes and generated the floppy in the
> following manner.
> 
> 
> $sudo cat boot1a.s bin32/e1000.lzimg > sudo /dev/fd0
> 
> Results in the same behaviour.. Etherboot waits in the new line after
>
> Searching for server (DHCP)...

Does etherboot print out more information?  All I would expect is a long
stream of extra print statements before it gets to this point.  I would
at least have a clue what the driver is thinking at this point.

I don't know what good it will do me but it is certainly a possibility.

> 
> Any ideas?
> 
> Do I need to specify any PCI specific lines to etherboot?
> Is the way I generated floppy correct?

It looks correct except the bit about redirecting it into sudo.
You can modify EXTRAVERSION in the makefile if you want to be certain you
are running your newly compiled version.

Eric

Re: [Etherboot-developers] Intel 82540em Gigabit cards seen on Optiplex Sx260 not DHCPing

[Zameer A. <za...@sy...>]

Hi eric,

Here are my findings

>lspci -n gives the information I was looking for.
>I expect it is 8086:100e, but I am not certain.
Yes, it is what you said.

[root@lion root]# lspci | grep Ethernet
01:0c.0 Ethernet controller: Intel Corp. 82540EM Gigabit Ethernet Controller
(rev 02)
[root@lion root]# lspci -n | grep 01:0c.0
01:0c.0 Class 0200: 8086:100e (rev 02)

>Is this a 10Mbit hub
>or a 100Mbit hub?
Its a 100Mbit hub.

>There is a
>#define DEBUG 0
>at the top of file.  Could you change that to 
>#define DEBUG 3
>
> And then send the output?
I downloaded the source, made above changes  and generated the floppy in the following manner.

$sudo cat boot1a.s bin32/e1000.lzimg > sudo /dev/fd0

Results in the same behaviour.. Etherboot waits in the new line after

Searching for server (DHCP)...
_


Any ideas?

Do I need to specify any PCI specific lines to etherboot?
Is the way I generated floppy correct?

Thanks,
Zameer A.

Re: [Etherboot-developers] unsubscribe

[Aaron G. <aar...@be...>]

Yer, Well, I am using M$ Inlook Depress (Microsoft Outlook Express e-mail
client)

Shame, the SourceForge web pages do not have that information on them as
well !!!

Oh, well there you go, some humour came out of it anyway :)

Cheers,

Aaron

----- Original Message -----
From: "Michael Brown" <mb...@fe...>
To: "Etherboot" <Eth...@li...>
Sent: Thursday, December 12, 2002 6:58 PM
Subject: Re: [Etherboot-developers] unsubscribe


You have to laugh when you see how this message appears in Pine:

> Hello,
>
> How do I remove my self from this list ?
>
> There are no instructions at all.
>
> Aaron
>
>   [ Note: This message contains email list management information ]

:-)

From the headers:

List-Help:
<mailto:eth...@li...?subject=help>
List-Post: <mailto:eth...@li...>
List-Subscribe:
<https://lists.sourceforge.net/lists/listinfo/etherboot-developers>,

<mailto:eth...@li...?subject=subscribe
>
List-Id: Discussion list for Etherboot developers
<etherboot-developers.lists.sourceforge.net>
List-Unsubscribe:
<https://lists.sourceforge.net/lists/listinfo/etherboot-developers>,

<mailto:eth...@li...?subject=unsubscri
be>
List-Archive:
<http://sourceforge.net/mailarchive/forum.php?forum=etherboot-developers>

HTH,

Michael



-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
Etherboot-developers mailing list
Eth...@li...
https://lists.sourceforge.net/lists/listinfo/etherboot-developers

Re: [Etherboot-developers] unsubscribe

[Michael B. <mb...@fe...>]

You have to laugh when you see how this message appears in Pine:

> Hello,
> =A0
> How do I remove my self from this list ?
> =A0
> There are no instructions at all.
> =A0
> Aaron
>
>   [ Note: This message contains email list management information ]

:-)

From=20the headers:

List-Help: <mailto:eth...@li...?subje=
ct=3Dhelp>
List-Post: <mailto:eth...@li...>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/etherboot-dev=
elopers>,
        <mailto:eth...@li...?subject=
=3Dsubscribe>
List-Id: Discussion list for Etherboot developers <etherboot-developers.lis=
ts.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/etherboot-d=
evelopers>,
        <mailto:eth...@li...?subject=
=3Dunsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=3Detherbo=
ot-developers>

HTH,

Michael

Re: [Etherboot-developers] [Q] How do we pass options to the DHCP server, are we failing?

[Michael B. <mb...@fe...>]

On 12 Dec 2002, Eric W. Biederman wrote:
> > The original code was cleaner but apparently took up more space.  It's
> > fairly straightforward: the DHCP request packet includes an option 175
> > which is a binary option with the structure:
> >   Bus type (1 byte) : 1=PCI, 2=ISA
> >   Vendor id (2 bytes)
> >   Device id (2 bytes)
> > This is enclosed within an Etherboot encapsulated options field (i.e. an
> > option 150) in order to avoid pollution of the DHCP option namespace.
> > This data must be present in the DHCP request.  It could be included in
> > the DHCP discover as well with no ill effects.
> Thinking:
> <-DISCOVER
> ->OFFER
> <-REQUEST
> ->ACK
> > It must be in the DHCP
> > request because the contents of the DHCP acknowledge will be derived from
> > the DHCP request (since DHCP is a stateless protocol).  Since the DHCP
> > acknowledge includes the TFTP filename, which is the part most likely to
> > depend upon the PCI IDs, it is mandatory for the PCI IDs to be included in
> > the DHCP request.
> If the logic for in the DHCP server is:
> if (client_I_can_handle) {
>         filename "x";
> }
> else {
>         ...
> }
> Then etherboot  must also send the information during the DISCOVER.

Any filename information sent in the OFFER will, AFAICR, be ignored by
Etherboot.  It would perhaps be cleaner if the DISCOVER packet included
all the information; when I added PCI ID sending I followed the
pre-existing pattern of doing all the DHCP option stuff in the
REQUEST->ACK phase.

> > Feel free to tidy up the code but please don't change the data structures;
> > there are by now plenty of production systems that rely on it.  You can
> > add other Etherboot-specific DHCP options within the encapsulated options
> > field, but if you change the structure of option 150 then you will be
> > breaking things.
> Here is my fundamental puzzlement.  Why are we not using option 43 to
> transmit our data as well as receive it?  It looks like that is
> exactly what Vendor Encapsulated Options is for, and using that field
> I do not see how we would conflict with anyone.

I've gone back and read over the discussion on the list when all this was
first added.  Here's what I wrote at the time:

  RFC1533_VENDOR_ETHERBOOT_ENCAP could be set equal to 43 (to use
  vendor-encapsulated-options) or, alternatively, we could request a DHCP
  option number from IANA.  The latter may be preferable for two reasons:

  1. It's quite conceivable that a vendor might wish to use Etherboot and
     some of their own (unrelated to Etherboot) DHCP options.  If the
     Etherboot options go in vendor-encapsulated-options then we have yet
     another option-space conflict, just in the vendor-encapsulated-options
     space instead of the "raw" option space.

  2. ISC DHCPD seems to have problems with extracting client-sent options
     from vendor-encapsulated-options, although it will happily extract
     options from any other encapsulated option field.

No-one disagreed; it got implemented.  At the moment we are safe from
clashes unless someone else uses option 150, since option 150 can
encapsulate all other Etherboot options.  This is the safest we can
possibly be without actually having an officially allocated number.  If we
move to use vendor-encapsulated-options then we *increase* the risk of
clashes (and, as a side-effect, make it impossible to use some versions of
ISC DHCPD with Etherboot).

In addition to being safer, option 150 is in a significant amount of
production code (Mandrake 9.0, for example).  Even if we changed it, we'd
probably have to still accept options returned via option 150.

Michael Brown
http://www.fensystems.co.uk

[Etherboot-developers] unsubscribe

[Aaron G. <aar...@be...>]

Hello,

How do I remove my self from this list ?

There are no instructions at all.

Aaron

Re: [Etherboot-developers] [Q] How do we pass options to the DHCP server, are we failing?

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

Michael Brown <mb...@fe...> writes:

> > I am currently trying to get a grip on how we are passing options
> > to the DHCP server, and I think there are some problems, but I don't
> > quite get how we are encoding the options.
> > 1) We do not pass the NIC vendor and device id in the DHCP discover,
> >    only in the DHCP request.  If anything it should be the other way
> >    around.
> > 2) I need pass the architecture etherboot is running on so I can
> >    magically serve up an image that will boot.  The plan is to extend
> >    how we are passing the NIC id's, add another tag type, and pass
> >    the ELF architecture type, we need it anyway for other reasons.
> >    But the code is a little convoluted, and a first glance I don't get
> >    how we are passing the NIC vendor and device ids.
> >    Could someone give me a quick synopsis, of how we intend to be passing
> >    the NIC vendor and device ids?
> 
> The original code was cleaner but apparently took up more space.  It's
> fairly straightforward: the DHCP request packet includes an option 175
> which is a binary option with the structure:
> 
>   Bus type (1 byte) : 1=PCI, 2=ISA
>   Vendor id (2 bytes)
>   Device id (2 bytes)
> 
> This is enclosed within an Etherboot encapsulated options field (i.e. an
> option 150) in order to avoid pollution of the DHCP option namespace.
> 
> This data must be present in the DHCP request.  It could be included in
> the DHCP discover as well with no ill effects.  

Thinking:
<-DISCOVER
->OFFER
<-REQUEST
->ACK


> It must be in the DHCP
> request because the contents of the DHCP acknowledge will be derived from
> the DHCP request (since DHCP is a stateless protocol).  Since the DHCP
> acknowledge includes the TFTP filename, which is the part most likely to
> depend upon the PCI IDs, it is mandatory for the PCI IDs to be included in
> the DHCP request.

If the logic for in the DHCP server is:
if (client_I_can_handle) {
        filename "x";
}
else {
        ...
}

Then etherboot  must also send the information during the DISCOVER.

Following the principle of be conservative in what you send, and be
liberal in what you accept, we should not plan of having the information
change during the REQUEST/ACK part of the configuration cycle, and instead
simply rely on that for confirmation.

> Feel free to tidy up the code but please don't change the data structures;
> there are by now plenty of production systems that rely on it.  You can
> add other Etherboot-specific DHCP options within the encapsulated options
> field, but if you change the structure of option 150 then you will be
> breaking things.

Here is my fundamental puzzlement.  Why are we not using option 43 to
transmit our data as well as receive it?  It looks like that is
exactly what Vendor Encapsulated Options is for, and using that field
I do not see how we would conflict with anyone.

Eric

Re: [Etherboot-developers] I've fixed the problem with net booting dos with PXE to EB to DOS

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

Peter Lister <P.L...@sy...> writes:

> Congratulations Matthew.
> 
> > Great. If you like reading the PXE spec, maybe you can do Etherboot on top of
> > PXE's UNDI without using an Etherboot's native network driver :).
> 
> The Etherboot driver would in fact be written for PXE's *UDP* interface,
> not UNDI. Eric B pointed out my loose terminology: no-one needs UNDI per
> se unless genuinely implementing a new network protocol (not UDP/IP). We
> want the PXE driver abstraction, but we don't have to use it directly.

To be clear.  I believe etherboot should use the PXE UNDI layer explicity,
when writing an etherboot driver.  Any other layer would cause us
problems, (we could not send arp, or igmp packets for example).  Plus
using UNDI directly we have the most direct access to the underlying
UNDI bugs.  I actually have an ia64 UNDI driver at the moment.  But
ia64 UNDI != i386 UNDI, so the code cannot be simply reused.

The case I was talking about earlier was for etherboot reexporting
PXE services to bootloaders like syslinux.  In which case all we
need to do is export the PXE UDP layer.  

> > This, of course, is an option in addition to using the native driver.
> 
> A generic image with multiple drivers could use PXE as a default: it is
> fine for simple cases and new hardware;

No.  The reliable thing to do would be to use PXE as the fallback if
there is not a native driver.  That way in most cases you steer
clear of PXE/UNDI bugs and only have to worry about etherboot bugs
which are fixable.

>  anyone who finds it restrictive
> (e.g. by having multiple NICs or wanting better multicast) can load the
> native driver for the nic(s) via tftp. That way everyone is happy. :)

I suggest you go have a long talk with Marvin if you think you can
make everyone happy.

Eric