etherboot-discuss — General Etherboot Discussion

Re: [Etherboot-discuss] ROM programming ( was Of possible interest to those trying to find 27cxxx EPROM's)

[Michael L. <mil...@ya...>]

Thanks for the link, Marty. I wish i had read it
before spending hours trying to find what type of chip
went in my rtl8139 boards before finding out the
Etherboot docs
cover it really well :P

I was lucky to find a Willem universal programmer
(http://www.willem.org/) from ebay, with a few
adapters
(PLCC32, MCS-51,etc) for around $90. It programs quite
a diverse selection of chips, includeing flash chips
found on a number of motherboards. 

I'll definetly second you, Marty when it comes to
using flash instead of EPROMS for createing
Etherboot-capable network cards. Much cheaper and
easier. Espically once you realize that the 12 EPROMS
you "Burned" need to be erased (with a special UV
lamp,no less) and re-programmed. :P

An old pentium-1 motherboard with flash chips (from
old pentium MB's :P) works quite nicely as a subsitite
with
Univflash (http://www.uniflash.org/) While trying not
to make a walking bilboard out of my posts,Id suggest
anyone looking into this route for more then a few
chips, get a 32-pin ZIF (Zero Insertion Force) socket
that can be mounted where the bios flash chip goes.
There avalible from digi-key, as well as other
suppliers. Makes a nice, secure connection for the
chip, and makes swapping the chips in and out easy. A
cheap adapter can also be found for PLCC-type flash
chips (Used on a number of newer NIC's). 

I'd say, all in all, if i had to do it over again, I
would have stuck with the hot-flash idea. :P
--- Marty Connor <md...@et...> wrote:

> On Mar 23, 2006, at 8:53 PM, Michael Lamontagne
> wrote:
> > Hi, just figured I'd alert anyone trying to find
> the
> > above chips, they are available from NTE at
> > www.nteinc.com, an electronics supplier. I
> purchased
> > 12 of the
> > 27c256-70D UV chips for about $4.50 apiece from a
> > local supplier. They are marked as originally from
> ST,
> > and appear to be NOS (New Old Stock) Not exactally
> > cheap or
> > fast, but reputed to be dependable.
> 
> Michael,
> 
> Thanks a lot for the pointer.
> 
> Typing 27C256 into Google brings up additional
> suppliers as well.   
> I've bought successfully from digikey.com and
> several other companies  
> over the years.  I've even used some of the newer
> flash memore parts  
> such as the 27SF256.
> 
> I should also mention, for those who would like to
> make a boot ROM,  
> this link:
> 
>     
> http://ltsp.sourceforge.net/documentation/eproms.txt
> 
> There, Jim McQuillan, of LTSP fame shares some tips
> on choosing  
> EPROMs for various cards.
> 
> ROM burning is a curious skill.  It's really not
> that hard to do, but  
> easy to mess up.  Every Electrical Engineer or
> Technician knows how  
> to do it, but few programmers do.
> 
> Basically, you're just writing a small amount of
> code into a chip.
> 
> The ROM burner itself can be somewhat expensive
> (starting at around  
> $200US), but we even figured out a way to write
> certain kinds of  
> FLASH EEPROMs on 3COM 3C905B Ethernet cards under
> Linux, so if you  
> use those cards (which are 5 for $10US on eBay), you
> can flash your  
> own chips right on them, using a utility we have in
> the contrib  
> directory of Etherboot distributions!)
> 
> At that price, the EEPROMs will cost more than the
> 10/100 cards ;)
> 
> So, if any Etherboot-ers want to start a
> conversation about ROM  
> burning, feel free.  It's a lot of fun to take the
> step from floppy  
> or CD to EPROM.  Give it a try!
> 
> Marty
> 
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Etherboot-discuss] Last call for additions to Etherboot 5.4.2

[Georg B. <gb...@us...>]

Am Freitag, 24. M=E4rz 2006 00:05 schrieb Marty Connor:

> So we might as well add a few more while we're at it.

Note that some of these require code changes as well. I have a half=
=20
finished update of the e1000 driver on my disk for a year now, but I=
=20
never got the time to test and submit it. If anyone is interested to=
=20
finish it I' gladly dig it out.


Georg

Re: [Etherboot-discuss] Of possible interest to those trying to find 27cxxx EPROM's

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

On Mar 23, 2006, at 8:53 PM, Michael Lamontagne wrote:
> Hi, just figured I'd alert anyone trying to find the
> above chips, they are available from NTE at
> www.nteinc.com, an electronics supplier. I purchased
> 12 of the
> 27c256-70D UV chips for about $4.50 apiece from a
> local supplier. They are marked as originally from ST,
> and appear to be NOS (New Old Stock) Not exactally
> cheap or
> fast, but reputed to be dependable.

Michael,

Thanks a lot for the pointer.

Typing 27C256 into Google brings up additional suppliers as well.   
I've bought successfully from digikey.com and several other companies  
over the years.  I've even used some of the newer flash memore parts  
such as the 27SF256.

I should also mention, for those who would like to make a boot ROM,  
this link:

     http://ltsp.sourceforge.net/documentation/eproms.txt

There, Jim McQuillan, of LTSP fame shares some tips on choosing  
EPROMs for various cards.

ROM burning is a curious skill.  It's really not that hard to do, but  
easy to mess up.  Every Electrical Engineer or Technician knows how  
to do it, but few programmers do.

Basically, you're just writing a small amount of code into a chip.

The ROM burner itself can be somewhat expensive (starting at around  
$200US), but we even figured out a way to write certain kinds of  
FLASH EEPROMs on 3COM 3C905B Ethernet cards under Linux, so if you  
use those cards (which are 5 for $10US on eBay), you can flash your  
own chips right on them, using a utility we have in the contrib  
directory of Etherboot distributions!)

At that price, the EEPROMs will cost more than the 10/100 cards ;)

So, if any Etherboot-ers want to start a conversation about ROM  
burning, feel free.  It's a lot of fun to take the step from floppy  
or CD to EPROM.  Give it a try!

Marty

Re: [Etherboot-discuss] Getting etherboot to relinquish control to bios

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

On Mar 23, 2006, at 8:41 PM, Michael Lamontagne wrote:
>> This is the place.  Welcome.
> Thanks for the welcome!

=06You're most welcome for the Welcome!

We are surely trying to maximize welcomeness here --  while dealing =20
with the multi-variate and unforgiving nature of bare-metal =20
computing ;-)

> I tried your modification as below, created the image,
> and then used mknbi-rom to create an etherboot nbi
> to be used by the current boot rom on the card.
> Etherboot froze.  That was the bad news.

Yes, there may be some mknbi issues.  Klaus has made a patch for =20
mknbi, and I probably should make a new release of mknbi as well as =20
Etherboot.  Unfortunately, we really don't have a regular mknbi =20
maintainer right now ( Any Volunteers!? ), but we'll do what we can.

It's possible you just ran out of low memory when loading the second =20
ROM image.
What version of mknbi-rom were you using, out of curiosity?

> The good
> news is upon takeing the rom image and burning it
> directly onto the 27c256 chip that goes on the NIC,
> it worked perfectly! My profuse thanks!

You're very welcome.  What BIOS are you using, BTW?  How did you set =20
your boot priorities, or did you just let them default?

> I should point out, however, that i have zlich
> programming experiance, and that I had to ask a friend
> of mine how to add it as a compile option.

Well done!  Way to be resourceful!

> He returned
> my question with the below modifaction to
> /src/core/nic.c:
>
> if ( kernel ) {
>                  loadkernel(kernel); /* We don't
> return except on error */
>                  printf("Unable to load file.\n");
> #ifdef EXIT_ON_TFTP_ERROR
>                  longjmp(restart_etherboot, 255);
>  #endif
>
> ... And the appropiate modifaction to /src/Config:
> (Ive added the remark as to what it actually does)
>
> # If TFTP file dosen't exist, exit and allow bios to
> #resume boot order
> CFLAGS+=3D -DEXIT_ON_TFTP_ERROR

Yes, this would certainly do the job.  On reflection, we should =20
probably rename it to something like:

     EXIT_ON_FILE_LOAD_ERROR

because we could be using a different protocol (nfs or http) to load =20
the boot file.

> A re-compile and dump to EPROM later, and all's well!
> Once again, thanks!

Sweet.  It's fun to see it boot from a ROM on an Ethernet card, isn't =20=

it?

Thanks for the patch.  Does anyone want to clean it up and submit =20
it?  It'll probably make it into 5.4.2 (if I don't forget :).  That's =20=

why we're encouraging people to put patches on SourceForge here:

     https://sourceforge.net/tracker/?func=3Dadd&group_id=3D4233&atid=3D30=
4233

So that they're easy to find.  Don't get me wrong, any patch is =20
welcome on the list!
Putting them on SourceForge just makes them easier to keep track of :)

If anyone wants to help keep track of stuff like this, just do what I =20=

did when I started, read the list, and volunteer to do something, and =20=

we'll help you get started.

Thanks again for your work, Michael.

Marty

RE: [Etherboot-discuss] Last call for additions to Etherboot 5.4.2

[Eli C. <el...@me...>]

Hi Marty,
Attached is a patch to the Mellanox Technologies HCA drivers. This patch
fixes a wrong interpretation of the client identifier role in DHCP over
IPOIB. I made the client accept DHCPOFFERs and DHCPACKs only if they
carry the client's clinet identifier. This patch removes this
requirement.

Thanks
Eli

[Etherboot-discuss] Re: Cleanup via-velocity and enable multicast

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

On Mar 23, 2006, at 7:34 PM, Timothy Legge wrote:
> Hi
> Here is a patch to cleanup the via-velocity driver and enable  
> multicast.    It is also attached at:
> http://sourceforge.net/tracker/index.php? 
> func=detail&aid=1457432&group_id=4233&atid=304233
> Tim

Thanks for the code cleanup and additions.  Would you care to commit it?

Marty

> Index: drivers/net/via-velocity.c
> ===================================================================
> RCS file: /cvsroot/etherboot/etherboot/etherboot-5.4/src/drivers/ 
> net/via-velocity.c,v
> retrieving revision 1.1
> diff -u -r1.1 via-velocity.c
> --- drivers/net/via-velocity.c	8 Mar 2006 03:07:58 -0000	1.1
> +++ drivers/net/via-velocity.c	24 Mar 2006 00:28:24 -0000
> @@ -35,6 +35,7 @@
>  *    ================
>  *
>  *    v1.0	03-06-2006	timlegge	Initial port of Linux driver
> +*    v1.1	03-19-2006	timlegge	Cleanup and enabled multicast
>  *
>  *    Indent Options: indent -kr -i8
>   
> ********************************************************************** 
> ***/
> @@ -49,6 +50,13 @@
>
>  #include "via-velocity.h"
>
> +//#define EDEBUG
> +#ifdef EDEBUG
> +#define dprintf(x) printf x
> +#else
> +#define dprintf(x)
> +#endif
> +
>  typedef int pci_power_t;
>
>  #define PCI_D0  ((int) 0)
> @@ -213,6 +221,9 @@
>     All descriptors point to a part of this buffer */
>  static u8 rxb[(RX_DESC_DEF * PKT_BUF_SZ) + 64];
>
> +static void velocity_init_cam_filter(struct velocity_info *vptr);
> +static inline void velocity_give_many_rx_descs(struct  
> velocity_info *vptr);
> +static int velocity_rx_refill(struct velocity_info *vptr);
>  static void velocity_init_info(struct pci_device *pdev,
>  			       struct velocity_info *vptr,
>  			       struct velocity_info_tbl *info);
> @@ -221,7 +232,6 @@
>  static int velocity_open(struct nic *nic, struct pci_device *pci);
>
>  static int velocity_soft_reset(struct velocity_info *vptr);
> -static void velocity_init_cam_filter(struct velocity_info *vptr);
>  static void mii_init(struct velocity_info *vptr, u32 mii_status);
>  static u32 velocity_get_opt_media_mode(struct velocity_info *vptr);
>  static void velocity_print_link_status(struct velocity_info *vptr);
> @@ -266,8 +276,8 @@
>  				 int def, char *name, char *devname)
>  {
>  	if (val == -1) {
> -		printf("%s: set value of parameter %s to %d\n",
> -		       devname, name, def);
> +		dprintf(("%s: set value of parameter %s to %d\n",
> +		       devname, name, def));
>  		*opt = def;
>  	} else if (val < min || val > max) {
>  		printf
> @@ -275,8 +285,8 @@
>  		     devname, name, min, max);
>  		*opt = def;
>  	} else {
> -		printf("%s: set value of parameter %s to %d\n",
> -		       devname, name, val);
> +		dprintf(("%s: set value of parameter %s to %d\n",
> +		       devname, name, val));
>  		*opt = val;
>  	}
>  }
> @@ -300,8 +310,8 @@
>  {
>  	(*opt) &= (~flag);
>  	if (val == -1) {
> -		printf("%s: set parameter %s to %s\n",
> -		       devname, name, def ? "TRUE" : "FALSE");
> +		dprintf(("%s: set parameter %s to %s\n",
> +		       devname, name, def ? "TRUE" : "FALSE"));
>  		*opt |= (def ? flag : 0);
>  	} else if (val < 0 || val > 1) {
>  		printf
> @@ -309,8 +319,8 @@
>  		     devname, name);
>  		*opt |= (def ? flag : 0);
>  	} else {
> -		printf("%s: set parameter %s to %s\n",
> -		       devname, name, val ? "TRUE" : "FALSE");
> +		dprintf(("%s: set parameter %s to %s\n",
> +		       devname, name, val ? "TRUE" : "FALSE"));
>  		*opt |= (val ? flag : 0);
>  	}
>  }
> @@ -330,7 +340,7 @@
>  {
>
>  	/* FIXME Do the options need to be configurable */
> -	velocity_set_int_opt(&opts->rx_thresh, -1, RX_THRESH_MIN,
> +	velocity_set_int_opt(&opts->rx_thresh, rx_thresh[index],  
> RX_THRESH_MIN,
>  			     RX_THRESH_MAX, RX_THRESH_DEF, "rx_thresh",
>  			     devname);
>  	velocity_set_int_opt(&opts->DMA_length, DMA_length[index],
> @@ -433,7 +443,7 @@
>  	dirty = vptr->rd_dirty - unusable;
>  	for (avail = vptr->rd_filled & 0xfffc; avail; avail--) {
>  		dirty = (dirty > 0) ? dirty - 1 : vptr->options.numrx - 1;
> -//              printf("return dirty: %d\n", dirty);
> +//              dprintf(("return dirty: %d\n", dirty));
>  		vptr->rd_ring[dirty].rdesc0.owner = OWNED_BY_NIC;
>  	}
>
> @@ -445,14 +455,14 @@
>  {
>  	int dirty = vptr->rd_dirty, done = 0, ret = 0;
>
> -//      printf("rx_refill - rd_curr = %d, dirty = %d\n", vptr- 
> >rd_curr, dirty);
> +//      dprintf(("rx_refill - rd_curr = %d, dirty = %d\n", vptr- 
> >rd_curr, dirty));
>  	do {
>  		struct rx_desc *rd = vptr->rd_ring + dirty;
>
>  		/* Fine for an all zero Rx desc at init time as well */
>  		if (rd->rdesc0.owner == OWNED_BY_NIC)
>  			break;
> -//              printf("rx_refill - after owner %d\n", dirty);
> +//              dprintf(("rx_refill - after owner %d\n", dirty));
>
>  		rd->inten = 1;
>  		rd->pa_high = 0;
> @@ -463,7 +473,7 @@
>  	} while (dirty != vptr->rd_curr);
>
>  	if (done) {
> -//              printf("\nGive Back Desc\n");
> +//              dprintf(("\nGive Back Desc\n"));
>  		vptr->rd_dirty = dirty;
>  		vptr->rd_filled += done;
>  		velocity_give_many_rx_descs(vptr);
> @@ -472,12 +482,10 @@
>  	return ret;
>  }
>
> -extern void hex_dump(const char *data, const unsigned int len);
>  / 
> ********************************************************************** 
> ****
>  POLL - Wait for a frame
>   
> ********************************************************************** 
> *****/
> -//EB53 static int velocity_poll(struct nic *nic, int retrieve)
> -static int velocity_poll(struct nic *nic __unused)
> +static int velocity_poll(struct nic *nic __unused, int retrieve)
>  {
>  	/* Work out whether or not there's an ethernet packet ready to
>  	 * read.  Return 0 if not.
> @@ -490,6 +498,9 @@
>  		return 0;
>  	rmb();
>
> +	if ( ! retrieve )
> +		return 1;
> +
>  	/*
>  	 *      Don't drop CE or RL error frame although RXOK is off
>  	 */
> @@ -545,9 +556,8 @@
>  		ptxb[size++] = '\0';
>
>  	if (size < ETH_ZLEN) {
> -//              printf("Padd that packet\n");
> +//              dprintf(("Pad that packet\n"));
>  		pktlen = ETH_ZLEN;
> -//                memcpy(ptxb, skb->data, skb->len);
>  		memset(ptxb + size, 0, ETH_ZLEN - size);
>
>  		vptr->td_rings[entry].tdesc0.pktsize = pktlen;
> @@ -558,7 +568,7 @@
>  		    vptr->td_rings[entry].tdesc0.pktsize;
>  		vptr->td_rings[entry].tdesc1.CMDZ = 2;
>  	} else {
> -//              printf("Correct size packet\n");
> +//              dprintf(("Correct size packet\n"));
>  		td_ptr->tdesc0.pktsize = size;
>  		td_ptr->td_buf[0].pa_low = virt_to_bus(ptxb);
>  		td_ptr->td_buf[0].pa_high = 0;
> @@ -595,7 +605,6 @@
>  	if (currticks() >= to) {
>  		printf("TX Time Out");
>  	}
> -
>  }
>
>  / 
> ********************************************************************** 
> ****
> @@ -673,7 +682,7 @@
>  	int ret, i;
>  	struct mac_regs *regs;
>
> -	printf("via-velocity.c: Found %s Vendor=0x%hX Device=0x%hX\n",
> +	printf("Found %s Vendor=0x%hX Device=0x%hX",
>  	       pci->name, pci->vendor, pci->dev_id);
>
>  	/* point to private storage */
> @@ -701,15 +710,15 @@
>
>  	BASE = vptr->ioaddr;
>
> -	printf("Chip ID: %hX\n", vptr->chip_id);
> +//	dprintf(("Chip ID: %hX\n", vptr->chip_id));
>
>  	for (i = 0; i < 6; i++)
>  		nic->node_addr[i] = readb(&regs->PAR[i]);
>
>  	/* Print out some hardware info */
> -	printf("%s: %! at ioaddr %hX, ", pci->name, nic->node_addr, BASE);
> +	printf(" %! at ioaddr %hX, ", nic->node_addr, BASE);
>
> -	velocity_get_options(&vptr->options, 0, pci->name);
> +	velocity_get_options(&vptr->options, 0, (char *) pci->name);
>
>  	/*
>  	 *      Mask out the options cannot be set to the chip
> @@ -729,10 +738,6 @@
>
>  	vptr->phy_id = MII_GET_PHY_ID(vptr->mac_regs);
>
> -	if (vptr->flags & VELOCITY_FLAGS_TX_CSUM) {
> -		printf("features missing\n");
> -	}
> -
>  	/* and leave the chip powered down */
>  // FIXME:       pci_set_power_state(pci, PCI_D3hot);
>
> @@ -751,8 +756,6 @@
>  	return 1;
>  }
>
> -//#define IORESOURCE_IO              0x00000100      /* Resource  
> type */
> -
>  /**
>   *	velocity_init_info	-	init private data
>   *	@pdev: PCI device
> @@ -775,41 +778,27 @@
>  	vptr->num_txq = info->txqueue;
>  	vptr->multicast_limit = MCAM_SIZE;
>
> -	printf
> -	    ("chip_id: 0x%hX, io_size: %d, num_txq %d, multicast_limit: %d 
> \n",
> +	dprintf
> +	    (("chip_id: 0x%hX, io_size: %d, num_txq %d, multicast_limit: % 
> d\n",
>  	     vptr->chip_id, vptr->io_size, vptr->num_txq,
> -	     vptr->multicast_limit);
> -	printf("Name: %s\n", info->name);
> +	     vptr->multicast_limit));
> +	dprintf(("Name: %s\n", info->name));
>
> -//      spin_lock_init(&vptr->lock);
> -//      INIT_LIST_HEAD(&vptr->list);
> -}
> -
> -/**
> - *	velocity_get_pci_info	-	retrieve PCI info for device
> - *	@vptr: velocity device
> - *	@pdev: PCI device it matches
> - *
> - *	Retrieve the PCI configuration space data that interests us from
> - *	the kernel PCI layer
> - */
>
> -#define IORESOURCE_IO   0x00000100	/* Resource type */
> -#define IORESOURCE_PREFETCH        0x00001000	/* No side effects */
> +}
>
> -#define IORESOURCE_MEM             0x00000200
> -#define BAR_0           0
> -#define BAR_1           1
> -#define BAR_5           5
> -#define  PCI_BASE_ADDRESS_SPACE 0x01	/* 0 = memory, 1 = I/O */
> -#define  PCI_BASE_ADDRESS_SPACE_IO 0x01
> -#define  PCI_BASE_ADDRESS_SPACE_MEMORY 0x00
> -#define  PCI_BASE_ADDRESS_MEM_TYPE_MASK 0x06
> -#define  PCI_BASE_ADDRESS_MEM_TYPE_32   0x00	/* 32 bit address */
> -#define  PCI_BASE_ADDRESS_MEM_TYPE_1M   0x02	/* Below 1M  
> [obsolete] */
> -#define  PCI_BASE_ADDRESS_MEM_TYPE_64   0x04	/* 64 bit address */
> -#define  PCI_BASE_ADDRESS_MEM_PREFETCH  0x08	/* prefetchable? */
> -//#define  PCI_BASE_ADDRESS_MEM_MASK      (~0x0fUL)
> +#define IORESOURCE_IO			0x00000100	/* Resource type */
> +#define IORESOURCE_MEM			0x00000200
> +#define IORESOURCE_PREFETCH		0x00001000	/* No side effects */
> +#define  PCI_BASE_ADDRESS_SPACE		0x01	/* 0 = memory, 1 = I/O */
> +#define  PCI_BASE_ADDRESS_SPACE_MEMORY	0x00
> +// #define  PCI_BASE_ADDRESS_SPACE_IO 0x01
> +// #define  PCI_BASE_ADDRESS_MEM_TYPE_MASK 0x06
> +// #define  PCI_BASE_ADDRESS_MEM_TYPE_32   0x00	/* 32 bit address */
> +// #define  PCI_BASE_ADDRESS_MEM_TYPE_1M   0x02	/* Below 1M  
> [obsolete] */
> +// #define  PCI_BASE_ADDRESS_MEM_TYPE_64   0x04	/* 64 bit address */
> +#define  PCI_BASE_ADDRESS_MEM_PREFETCH	0x08	/* prefetchable? */
> +// #define  PCI_BASE_ADDRESS_MEM_MASK      (~0x0fUL)
>  // #define  PCI_BASE_ADDRESS_IO_MASK       (~0x03UL)
>
>  unsigned long pci_resource_flags(struct pci_device *pdev, unsigned  
> int bar)
> @@ -832,20 +821,18 @@
>  		   continue;
>  		   res->start = l & PCI_BASE_ADDRESS_MEM_MASK;
>  		 */ flags |= l & ~PCI_BASE_ADDRESS_MEM_MASK;
> -		printf("Memory Resource\n");
> +//		dprintf(("Memory Resource\n"));
>  	} else {
>  		//            sz = pci_size(l, sz, PCI_BASE_ADDRESS_IO_MASK &  
> 0xffff);
>  		///         if (!sz)
>  		///              continue;
>  //              res->start = l & PCI_BASE_ADDRESS_IO_MASK;
>  		flags |= l & ~PCI_BASE_ADDRESS_IO_MASK;
> -		printf("I/O Resource\n");
> +//		dprintf(("I/O Resource\n"));
>  	}
>  	if (flags & PCI_BASE_ADDRESS_SPACE_IO) {
> -		printf("Why is it here\n");
>  		flags |= IORESOURCE_IO;
>  	} else {
> -		printf("here\n");
>  //flags &= ~IORESOURCE_IO;
>  	}
>
> @@ -853,9 +840,17 @@
>  	if (flags & PCI_BASE_ADDRESS_MEM_PREFETCH)
>  		flags |= IORESOURCE_MEM | IORESOURCE_PREFETCH;
>
> -
>  	return flags;
>  }
> +
> +/**
> + *	velocity_get_pci_info	-	retrieve PCI info for device
> + *	@vptr: velocity device
> + *	@pdev: PCI device it matches
> + *
> + *	Retrieve the PCI configuration space data that interests us from
> + *	the kernel PCI layer
> + */
>  static int velocity_get_pci_info(struct velocity_info *vptr,
>  				 struct pci_device *pdev)
>  {
> @@ -869,7 +864,7 @@
>  	vptr->ioaddr = pci_bar_start(pdev, PCI_BASE_ADDRESS_0);
>  	vptr->memaddr = pci_bar_start(pdev, PCI_BASE_ADDRESS_1);
>
> -	printf("Looking for I/O Resource - Found:");
> +	dprintf(("Looking for I/O Resource - Found:"));
>  	if (!
>  	    (pci_resource_flags(pdev, PCI_BASE_ADDRESS_0) & IORESOURCE_IO))
>  	{
> @@ -878,7 +873,7 @@
>  		return -1;
>  	}
>
> -	printf("Looking for Memory Resource - Found:");
> +	dprintf(("Looking for Memory Resource - Found:"));
>  	if ((pci_resource_flags(pdev, PCI_BASE_ADDRESS_1) &  
> IORESOURCE_IO)) {
>  		printf("DEBUG: region #1 is an I/O resource, aborting.\n");
>  		return -1;
> @@ -956,8 +951,6 @@
>  	struct mac_regs *regs = vptr->mac_regs;
>  	int i;
>
> -//ptr->rd_dirty = vptr->rd_filled = vptr->rd_curr = 0;
> -
>  	/*
>  	 *      Init state, all RD entries belong to the NIC
>  	 */
> @@ -985,6 +978,7 @@
>  {
>  	struct mac_regs *regs = vptr->mac_regs;
>  	int i, mii_status;
> +	u8 rx_mode;
>
>  	mac_wol_reset(regs);
>
> @@ -992,8 +986,6 @@
>  	case VELOCITY_INIT_RESET:
>  	case VELOCITY_INIT_WOL:
>
> -//netif_stop_queue(vptr->dev);
> -
>  		/*
>  		 *      Reset RX to prevent RX pointer not on the 4X location
>  		 */
> @@ -1008,14 +1000,12 @@
>  			velocity_print_link_status(vptr);
>  			if (!(vptr->mii_status & VELOCITY_LINK_FAIL))
>  				printf("Link Failed\n");
> -//                              netif_wake_queue(vptr->dev);
>  		}
>
>  		enable_flow_control_ability(vptr);
>
>  		mac_clear_isr(regs);
>  		writel(CR0_STOP, &regs->CR0Clr);
> -		//writel((CR0_DPOLL | CR0_TXON | CR0_RXON | CR0_STRT),
>  		writel((CR0_DPOLL | CR0_TXON | CR0_RXON | CR0_STRT),
>  		       &regs->CR0Set);
>  		break;
> @@ -1055,7 +1045,19 @@
>  		/*
>  		 *      Set packet filter: Receive directed and broadcast address
>  		 */
> -//FIXME Multicast               velocity_set_multi(nic);
> +		
> +		/*
> +		 * Enable Multicast by default
> +		 * from velocity_set_multi(nic)
> +		 */
> +		writel(0xffffffff, &regs->MARCAM[0]);
> +		writel(0xffffffff, &regs->MARCAM[4]);
> +		rx_mode = (RCR_AM | RCR_AB | RCR_PROM);
> +		/* Not necessary (no where to set mtu)
> +		if (dev->mtu > 1500)
> +                	rx_mode |= RCR_AL;
> +		*/
> +		BYTE_REG_BITS_ON(rx_mode, &regs->RCR);
>
>  		/*
>  		 *      Enable MII auto-polling
> @@ -1084,7 +1086,6 @@
>  		       &regs->CR0Set);
>
>  		mii_status = velocity_get_opt_media_mode(vptr);
> -//              netif_stop_queue(vptr->dev);
>
>  		mii_init(vptr, mii_status);
>
> @@ -1092,8 +1093,7 @@
>  		    VELOCITY_LINK_CHANGE) {
>  			velocity_print_link_status(vptr);
>  			if (!(vptr->mii_status & VELOCITY_LINK_FAIL))
> -				printf("Link Faaailll\n");
> -//                              netif_wake_queue(vptr->dev);
> +				printf("Link Failed\n");
>  		}
>
>  		enable_flow_control_ability(vptr);
> @@ -1240,12 +1240,12 @@
>
>  	/* Tx Descriptor needs 64 bytes alignment; */
>  	TxPhyAddr = virt_to_bus(vptr->TxDescArrays);
> -	printf("Unaligned Address : %lX\n", TxPhyAddr);
> +	dprintf(("Unaligned Address : %lX\n", TxPhyAddr));
>  	diff = 64 - (TxPhyAddr - ((TxPhyAddr >> 6) << 6));
>  	TxPhyAddr += diff;
>  	vptr->td_rings = (struct tx_desc *) (vptr->TxDescArrays + diff);
>
> -	printf("Aligned Address: %lX\n", virt_to_bus(vptr->td_rings));
> +	dprintf(("Aligned Address: %lX\n", virt_to_bus(vptr->td_rings)));
>  	vptr->tx_buffs = txb;
>  	/* Rx Buffer needs 64 bytes alignment; */
>  	TxBufPhyAddr = virt_to_bus(vptr->tx_buffs);
> Index: drivers/net/via-velocity.h
> ===================================================================
> RCS file: /cvsroot/etherboot/etherboot/etherboot-5.4/src/drivers/ 
> net/via-velocity.h,v
> retrieving revision 1.1
> diff -u -r1.1 via-velocity.h
> --- drivers/net/via-velocity.h	8 Mar 2006 03:07:58 -0000	1.1
> +++ drivers/net/via-velocity.h	24 Mar 2006 00:28:25 -0000
> @@ -46,7 +46,7 @@
>
>  #define PKT_BUF_SZ          1564
>
> -#define MAX_UNITS           8
> +#define MAX_UNITS           1
>  #define OPTION_DEFAULT      { [0 ... MAX_UNITS-1] = -1}
>
>  #define REV_ID_VT6110       (0)
> @@ -1775,23 +1775,12 @@
>  #define TX_DESC_DEF     4
>
>  struct velocity_info {
> -//      struct list_head list;
> -
>  	struct pci_device *pdev;
> -//      struct net_device *dev;
> -//      struct net_device_stats stats;
>
>  #ifdef CONFIG_PM
>  	u32 pci_state[16];
>  #endif
>
> -//      dma_addr_t rd_pool_dma;
> -//      dma_addr_t td_pool_dma[TX_QUEUE_NO];
> -
> -//      dma_addr_t tx_bufs_dma;
> -	u8 *tx_bufs;
> -
> -	u8 ip_addr[4];
>  	enum chip_type chip_id;
>
>  	struct mac_regs *mac_regs;
> @@ -1805,9 +1794,7 @@
>
>  	int num_txq;
>
> -	volatile int td_used[TX_QUEUE_NO];
>  	int td_curr;
> -	int td_tail[TX_QUEUE_NO];
>  	unsigned char *TxDescArrays;	/* Index of Tx Descriptor buffer */
>  	unsigned char *RxDescArrays;	/* Index of Rx Descriptor buffer */
>  	unsigned char *tx_buffs;
> @@ -1816,16 +1803,13 @@
>  	unsigned char *txb;
>  	unsigned char *rxb;
>  	struct tx_desc *td_rings;
> -	struct velocity_td_info *td_infos[TX_QUEUE_NO];
>
>  	int rd_curr;
>  	int rd_dirty;
>  	u32 rd_filled;
>  	struct rx_desc *rd_ring;
> -	struct velocity_rd_info *rd_info;	/* It's an array */
>
>  #define GET_RD_BY_IDX(vptr, idx)   (vptr->rd_ring[idx])
> -	u32 mib_counter[MAX_HW_MIB_COUNTER];
>  	struct velocity_opt options;
>
>  	u32 int_mask;
> @@ -1840,15 +1824,7 @@
>  	u8 vCAMmask[(VCAM_SIZE / 8)];
>  	u8 mCAMmask[(MCAM_SIZE / 8)];
>
> -//      spinlock_t lock;
> -
>  	int wol_opts;
> -	u8 wol_passwd[6];
> -
> -	struct velocity_context context;
> -
> -	u32 ticks;
> -	u32 rx_bytes;
>
>  } vptx;
>

[Etherboot-discuss] Of possible interest to those trying to find 27cxxx EPROM's

[Michael L. <mil...@ya...>]

Hi, just figured I'd alert anyone trying to find the
above chips, they are available from NTE at
www.nteinc.com, an electronics supplier. I purchased
12 of the
27c256-70D UV chips for about $4.50 apiece from a
local supplier. They are marked as originally from ST,
and appear to be NOS (New Old Stock) Not exactally
cheap or
fast, but reputed to be dependable. 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Etherboot-discuss] Getting etherboot to relinquish control to bios

[Michael L. <mil...@ya...>]

--- Marty Connor <md...@et...> wrote:


> This is the place.  Welcome.
Thanks for the welcome!

I tried your modification as below, created the image,
and then used mknbi-rom to create an etherboot nbi
to be used by the current boot rom on the card. 
Etherboot froze. That was the bad news. The good
news is upon takeing the rom image and burning it
directly onto the 27c256 chip that goes on the NIC,
it worked perfectly! My profuse thanks!

I should point out, however, that i have zlich
programming experiance, and that I had to ask a friend
of mine how to add it as a compile option. He returned
my question with the below modifaction to
/src/core/nic.c:

if ( kernel ) {
                 loadkernel(kernel); /* We don't
return except on error */
                 printf("Unable to load file.\n");
#ifdef EXIT_ON_TFTP_ERROR
                 longjmp(restart_etherboot, 255);
 #endif



... And the appropiate modifaction to /src/Config:
(Ive added the remark as to what it actually does)

# If TFTP file dosen't exist, exit and allow bios to
#resume boot order
CFLAGS+= -DEXIT_ON_TFTP_ERROR

A re-compile and dump to EPROM later, and all's well!

Once again, thanks!


> Hmmm, well, looking at src/core/nic.c, around line
> 421, we see:
> 
>          if ( kernel ) {
>                  loadkernel(kernel); /* We don't
> return except on  
> error */
>                  printf("Unable to load file.\n");
>          } else {
>                  printf("No filename\n");
>          }
>          interruptible_sleep(2);         /* lay off
> the server for a  
> while */
>          longjmp(restart_etherboot, -1);
> 
> So, let's say that function loadkernel(kernel) has
> just tried to load  
> a kernel, and failed.
> 
> Normally, it would print "Unable to load file." and
> sleep 2 seconds  
> and try again.
> 
> The "longjmp(restart_etherboot, -1);" line is
> telling Etherboot what  
> to do next.
> 
> So, what does "-1" mean?
> 
> Well, for that, we have to go to src/core/main.c,
> where, around line  
> 240 we see:
> 
>          /* -1:  timeout or ESC
>             -2:  error return from loader
>             -3:  finish the current run.
>             0:   retry booting bootp and tftp
>             1:   retry tftp with possibly modified
> bootp reply
>             2:   retry bootp and tftp
>             3:   retry probe bootp and tftp
>             4:   start with the next device and
> retry from there...
>             255: exit Etherboot
>             256: retry after relocation
>          */
> 
> So, if after:
> 
>                  loadkernel(kernel); /* We don't
> return except on  
> error */
>                  printf("Unable to load file.\n");
> 
> we were to add:
> 
> 	        longjmp(restart_etherboot, 255);
> 
> Etherboot would exit if it was unable to load the
> kernel.  This might  
> just do what you want.
> Of course, your BIOS would have to be setup to go to
> the next  
> device.  I often see people have boot priority set
> up as:
> 
>      CDROM
>      FLOPPY
>      HARD DISK
> 
> In your case, it would depend on if you're booting
> from ROM or  
> FLOPPY, but hopefully this will help you get
> started.
> 
> Are you able to build Etherboot (download 5.4.1,
> edit the files,  
> etc.)?  If not, please ask on the list, and we'll
> get you an image to  
> test.
> 
> If this works, it might make an interesting option. 
> Something like  
> "EXIT_ON_TFTP_ERROR".
> 
> Anyway, please let us know how it goes, and ask
> questions questions  
> if you get stuck.
> I hope this helps you.
> 
> 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/
> 
> > The reason im trying todo this is because the pc's
> > booting etherboot need to be able to boot locally
> from
> > the hard drive. The pcs are a part of an
> old-school
> > gameing network that will eventually be used as a
> > beowulf/POPS (pile of pc's) cluster. Currently,
> the
> > mechanic im trying is to have etherboot boot an
> mknbi
> > file on the server that has the same name as the
> pc's
> > workgroup name. I'm using a symbolic link to
> > differentiate what the pc will do, ie, to reload
> the
> > system, ive created an mknbi-dos image of the
> > universal tcp-ip bootdisk found at
> > www.netbootdisk.com. For linux booting in the
> future,
> > I'l create a mkelf-linux image, and so on.
> >
> > However,getting them to boot locally is a prolbem.
> > Currently, im trying to set it up so that if the
> tftp
> > image specified in dhcpd.conf does not exist,
> > etherboot will exit and the bios will try the next
> > boot device.
> >
> > Ive tried using etherboot as a second stage
> bootloader
> > under PXE, which works on one machine using an
> intel
> > pro/100 NIC. If the PXE file dosent exist,
> etherboot
> > dosent get loaded, and the PXE loader aborts,
> allowing
> > the system to be booted locally.
> >
> > However, on the gameing cluster, the PXE loader
> > (Realtek 8139 generic rom image found at realtek's
> > site) freezes no matter what i do. Preferably, i'd
> > like to use etherboot as the first stage
> bootloader.
> >
> > Another idea that ive tried and semi-works is to
> use
> > mknbi-dos to make a boot image of a floppy disk
> from
> > win98 (the os that im running the gameing systems
> on)
> > specifically designed to boot from the hard disk)
> >
> > However, the prolbem i run into is occasionally
> win98
> > needs to re-read command.com, which is in the net
> boot
> > image, which, if the network is unavailable,
> causes a
> > serious crash. Ive been unable to re-direct
> win98's
> > calls to command.com to the local copy.
> >
> > Im using kingston KNE120 network cards with an
> > etherboot image from rom-o-matic
> (rtl8139:rtl8139),
> > witch works nicely.
> >
> > Any ideas?
> >
> > Thnkas.
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam
> protection around
> > http://mail.yahoo.com
> >
> >
> >
>
-------------------------------------------------------
> > This SF.Net email is sponsored by xPML, a
> groundbreaking scripting  
> > language
> > that extends applications into web and mobile
> media. 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[Etherboot-discuss] Cleanup via-velocity and enable multicast

[Timothy L. <tl...@ro...>]

Hi

Here is a patch to cleanup the via-velocity driver and enable multicast.
     It is also attached at:

http://sourceforge.net/tracker/index.php?func=detail&aid=1457432&group_id=4233&atid=304233

Tim

Re: [Etherboot-discuss] Last call for additions to Etherboot 5.4.2

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

On Mar 23, 2006, at 4:25 PM, Glenn Brown wrote:
> I just backed out relocate.patch.  I won't be relying on it, so  
> there is no reason for the change.
> --Glenn

Thanks.

Marty

Re: [Etherboot-discuss] Last call for additions to Etherboot 5.4.2

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

On Mar 23, 2006, at 4:17 PM, Geert Stappers wrote:
> | From: Arno Wagner <wagner@ti...>
> | New Intel e1000 variant
> | 2005-10-05 12:07
> | it seems Intel has a new e1000 variant. The chip is the
> | 82541PI, the PCI-ID is 0200:8086:107c. Etherboot does not
> | detect it.
...
> | The Card is an Intel Pro/1000 GT desktop adapter (PWLA8391GT).
> | The main difference seems to be that it is a lead-free
> | product.
...
> | 0000:00:13.0 0200: 8086:107c (rev 05)

Good catch.  Do you want to make a patch and submit it?

I note that in:

     /usr/src/linux-2.4/drivers/net/e1000/e1000_main.c

/* e1000_pci_tbl - PCI Device ID Table
*
* Last entry must be all 0s
*
* Macro expands to...
*   {PCI_DEVICE(PCI_VENDOR_ID_INTEL, device_id)}
*/
static struct pci_device_id e1000_pci_tbl[] = {
         INTEL_E1000_ETHERNET_DEVICE(0x1000),
         INTEL_E1000_ETHERNET_DEVICE(0x1001),
         INTEL_E1000_ETHERNET_DEVICE(0x1004),
         INTEL_E1000_ETHERNET_DEVICE(0x1008),
         INTEL_E1000_ETHERNET_DEVICE(0x1009),
         INTEL_E1000_ETHERNET_DEVICE(0x100C),
         INTEL_E1000_ETHERNET_DEVICE(0x100D),
         INTEL_E1000_ETHERNET_DEVICE(0x100E),
         INTEL_E1000_ETHERNET_DEVICE(0x100F),
         INTEL_E1000_ETHERNET_DEVICE(0x1010),
         INTEL_E1000_ETHERNET_DEVICE(0x1011),
         INTEL_E1000_ETHERNET_DEVICE(0x1012),
         INTEL_E1000_ETHERNET_DEVICE(0x1013),
         INTEL_E1000_ETHERNET_DEVICE(0x1014),
         INTEL_E1000_ETHERNET_DEVICE(0x1015),
         INTEL_E1000_ETHERNET_DEVICE(0x1016),
         INTEL_E1000_ETHERNET_DEVICE(0x1017),
         INTEL_E1000_ETHERNET_DEVICE(0x1018),
         INTEL_E1000_ETHERNET_DEVICE(0x1019),
         INTEL_E1000_ETHERNET_DEVICE(0x101A),
         INTEL_E1000_ETHERNET_DEVICE(0x101D),
         INTEL_E1000_ETHERNET_DEVICE(0x101E),
         INTEL_E1000_ETHERNET_DEVICE(0x1026),
         INTEL_E1000_ETHERNET_DEVICE(0x1027),
         INTEL_E1000_ETHERNET_DEVICE(0x1028),
         INTEL_E1000_ETHERNET_DEVICE(0x1075),
         INTEL_E1000_ETHERNET_DEVICE(0x1076),
         INTEL_E1000_ETHERNET_DEVICE(0x1077),
         INTEL_E1000_ETHERNET_DEVICE(0x1078),
         INTEL_E1000_ETHERNET_DEVICE(0x1079),
         INTEL_E1000_ETHERNET_DEVICE(0x107A),
         INTEL_E1000_ETHERNET_DEVICE(0x107B),
         INTEL_E1000_ETHERNET_DEVICE(0x107C),
         INTEL_E1000_ETHERNET_DEVICE(0x108A),
         INTEL_E1000_ETHERNET_DEVICE(0x108B),
         INTEL_E1000_ETHERNET_DEVICE(0x108C),
         INTEL_E1000_ETHERNET_DEVICE(0x1099),
         /* required last entry */
         {0,}
};

So we might as well add a few more while we're at it.

In etherboot-5.4/src/drivers/net/ our list stops at:

static struct pci_id e1000_nics[] = {
PCI_ROM(0x8086, 0x1000, "e1000-82542",               "Intel  
EtherExpressPro1000"),
PCI_ROM(0x8086, 0x1001, "e1000-82543gc-fiber",       "Intel  
EtherExpressPro1000 82543GC Fiber"),
PCI_ROM(0x8086, 0x1004, "e1000-82543gc-copper",      "Intel  
EtherExpressPro1000 82543GC Copper"),
PCI_ROM(0x8086, 0x1008, "e1000-82544ei-copper",      "Intel  
EtherExpressPro1000 82544EI Copper"),
PCI_ROM(0x8086, 0x1009, "e1000-82544ei-fiber",       "Intel  
EtherExpressPro1000 82544EI Fiber"),
PCI_ROM(0x8086, 0x100C, "e1000-82544gc-copper",      "Intel  
EtherExpressPro1000 82544GC Copper"),
PCI_ROM(0x8086, 0x100D, "e1000-82544gc-lom",         "Intel  
EtherExpressPro1000 82544GC LOM"),
PCI_ROM(0x8086, 0x100E, "e1000-82540em",             "Intel  
EtherExpressPro1000 82540EM"),
PCI_ROM(0x8086, 0x100F, "e1000-82545em-copper",      "Intel  
EtherExpressPro1000 82545EM Copper"),
PCI_ROM(0x8086, 0x1010, "e1000-82546eb-copper",      "Intel  
EtherExpressPro1000 82546EB Copper"),
PCI_ROM(0x8086, 0x1011, "e1000-82545em-fiber",       "Intel  
EtherExpressPro1000 82545EM Fiber"),
PCI_ROM(0x8086, 0x1012, "e1000-82546eb-fiber",       "Intel  
EtherExpressPro1000 82546EB Copper"),
PCI_ROM(0x8086, 0x1013, "e1000-82541ei",             "Intel  
EtherExpressPro1000 82541EI"),
PCI_ROM(0x8086, 0x1015, "e1000-82540em-lom",         "Intel  
EtherExpressPro1000 82540EM LOM"),
PCI_ROM(0x8086, 0x1016, "e1000-82540ep-lom",         "Intel  
EtherExpressPro1000 82540EP LOM"),
PCI_ROM(0x8086, 0x1017, "e1000-82540ep",             "Intel  
EtherExpressPro1000 82540EP"),
PCI_ROM(0x8086, 0x1018, "e1000-82541ep",             "Intel  
EtherExpressPro1000 82541EP"),
PCI_ROM(0x8086, 0x1019, "e1000-82547ei",             "Intel  
EtherExpressPro1000 82547EI"),
PCI_ROM(0x8086, 0x101d, "e1000-82546eb-quad-copper", "Intel  
EtherExpressPro1000 82546EB Quad Copper"),
PCI_ROM(0x8086, 0x101e, "e1000-82540ep-lp",          "Intel  
EtherExpressPro1000 82540EP LP"),
PCI_ROM(0x8086, 0x1026, "e1000-82545gm-copper",      "Intel  
EtherExpressPro1000 82545GM Copper"),
PCI_ROM(0x8086, 0x1027, "e1000-82545gm-fiber",       "Intel  
EtherExpressPro1000 82545GM Fiber"),
PCI_ROM(0x8086, 0x1028, "e1000-82545gm-serdes",      "Intel  
EtherExpressPro1000 82545GM SERDES"),
PCI_ROM(0x8086, 0x1075, "e1000-82547gi",             "Intel  
EtherExpressPro1000 82547GI"),
PCI_ROM(0x8086, 0x1076, "e1000-82541gi",             "Intel  
EtherExpressPro1000 82541GI"),
PCI_ROM(0x8086, 0x1077, "e1000-82541gi-mobile",      "Intel  
EtherExpressPro1000 82541GI Mobile"),
PCI_ROM(0x8086, 0x1078, "e1000-82541er",             "Intel  
EtherExpressPro1000 82541ER"),
PCI_ROM(0x8086, 0x1079, "e1000-82546gb-copper",      "Intel  
EtherExpressPro1000 82546GB Copper"),
PCI_ROM(0x8086, 0x107a, "e1000-82546gb-fiber",       "Intel  
EtherExpressPro1000 82546GB Fiber"),
PCI_ROM(0x8086, 0x107b, "e1000-82546gb-serdes",      "Intel  
EtherExpressPro1000 82546GB SERDES"),
};

Marty

[Etherboot-discuss] Re: GPXE questions

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

On Mar 16, 2006, at 10:13 AM, Eli Cohen wrote:
> Hi all,
> I have seen lately some emails on this new project and have some
> questions:

Hi Eli,

You raise some really good questions.  For now, the GPXE-Discuss is  
inactive, since everyone on GPXE-Discuss is also on Etherboot- 
Discuss.  I think it's better we stick with one list for now.

I'll do my best to answer your questions.  I'm sure Michael may have  
comments as well.  We're still working out some of the details on GPXE.

So, here's my take on things, right now:

> 1. The name of the project is GPXE. Will it be a pure PXE
> implementation? I mean is it going to work in real mode?

We're going to try to follow the PXE specification as best we can.   
It is generally agreed that the specification has problems, and there  
are things we may have to work around, but in general, I believe the  
answer to this question is affirmative.

> 2. Which BIOSs will this support? UEFI? Regular BIOSs

We'll support "normal" PNP BIOSes, of course (or perhaps better said,  
they'll support GPXE :)

We'd like to work with UEFI, and having looked over the UEFI spec, I  
think we should be able to be interoperable, and hopefully more so,  
if it makes sense for us to be.

> 3. I hope there will be a standard way to allocate memory.

I'll mostly leave this to Michael to explain.  As I understand it, in  
the bare-metal environment we must exist in, static memory allocation  
is preferred.  We have constraints on memory that don't exist after  
an OS is in charge of the machine.  One significant problem is that  
there can be other legitimate (and illegitimate) users of memory, and  
we have to be very careful how and when we allocate memory, and when  
we free it. Simplicity counts for a lot.

Can you be more specific about what you're hoping for here?  I know  
how nice it would be to not have to have a different driver for GPXE,  
but there are reason why it may make sense. Kernel drivers are made  
for a different realm.

Let's have a discussion about what you'd like to see, and what make  
sense given the architecture and environment we're in.  Maybe we can  
come up with something, or at least make things easier.

> 4. I would like to see support for other network media than Ethernet -
> Infiniband for example. This would require supporting Infiniband
> hardware type, 20 byte MAC addresses and also some changes to the DHCP
> client (setting the broadcast flag, client identifier).
> Eli

I believe we're looking at this for GPXE.  The new network stack  
(based on uIP) is a lot more flexible, and should give us the ability  
to much better support TCP as well as UDP protocols, as well as other  
network architectures.

I've been so focused on getting 5.4.2 out that I haven't said much  
about GPXE-0.5 lately.

So I'll say this:

GPXE is a minimum-compromises rewrite of Etherboot.  GPXE has a new  
network stack, build system, and modular structure to the code.  It  
is intended to better support the PXE specification, with extensions  
to allow things that were not thought of when the PXE spec was  
created. We're considering UEFI compatibility, for example, as well  
as network protocol extensions.

For now, GPXE is focussed on x86 machines, though support for other  
architectures may be included if someone wishes to implement and  
maintain the code.

Code quality, stability, maintainability, efficiency, and robustness  
are important goals for GPXE.

We will decide functionality past what is provided for in the PXE  
spec as we go. If an extension makes sense, be it an architecture  
addition, protocol addition, or functionality addition, we'll decide  
if it is something that makes sense for GPXE. Figuring out what to do  
is part of what makes programming an interesting activity.

I hope this makes things clearer.  We'll be talking a lot more about  
GPXE after LinuxWorld.

Your help, comments, questions, and suggestions are most welcome as  
we create GPXE.

Marty

Re: [Etherboot-discuss] Last call for additions to Etherboot 5.4.2

[<sta...@st...>]

On Thu, Mar 23, 2006 at 03:54:32PM -0500, Marty Connor wrote:
> Hello,
     <snip/> 
> Does anyone have anything to add to 5.4.2 that I missed?

From http://sourceforge.net/mailarchive/forum.php?forum_id=6402&max_rows=25&style=flat&viewmonth=200510&viewday=5
( Message-ID: <200...@ti...> )

| From: Arno Wagner <wagner@ti...>
| New Intel e1000 variant  
| 2005-10-05 12:07
| 
| Dear developers,
| 
| it seems Intel has a new e1000 variant. The chip is the
| 82541PI, the PCI-ID is 0200:8086:107c. Etherboot does not 
| detect it.
| 
| I patched a current etherboot 5.4.1 by replacing the 0x1076 
| for an earlier e1000 with 0x107c and it seems to work. I 
| am sorry, but I don't have the time to find out how to properly
| add the new ID, so I don't have a patch.
| 
| The Card is an Intel Pro/1000 GT desktop adapter (PWLA8391GT).
| The main difference seems to be that it is a lead-free
| product.
| 
| lspci -v and lspci -v -n output below.
| 
| Arno
| 
| ----
| 
| 0000:00:13.0 Ethernet controller: Intel Corporation 82541PI Gigabit
| Ethernet
| Controller (rev 05)
|         Subsystem: Intel Corporation: Unknown device 1376
|         Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 18
|         Memory at feb00000 (32-bit, non-prefetchable) [size=128K]
|         Memory at fea00000 (32-bit, non-prefetchable) [size=128K]
|         I/O ports at ef00 [size=64]
|         Expansion ROM at fe900000 [disabled] [size=128K]
|         Capabilities: [dc] Power Management version 2
|         Capabilities: [e4] PCI-X non-bridge device.
| 
| ----
| 
| 0000:00:13.0 0200: 8086:107c (rev 05)
|         Subsystem: 8086:1376
|         Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 18
|         Memory at feb00000 (32-bit, non-prefetchable) [size=128K]
|         Memory at fea00000 (32-bit, non-prefetchable) [size=128K]
|         I/O ports at ef00 [size=64]
|         Expansion ROM at fe900000 [disabled] [size=128K]
|         Capabilities: [dc] Power Management version 2
|         Capabilities: [e4] PCI-X non-bridge device.
| 
| --
| Arno Wagner, Dipl. Inform., CISSP --- CSG, ETH Zurich,
| wa...@ti...
| GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
| ----
| Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
| Windows is the "under-3" toy of the OS world. -- Matthew D. Fuller
			
> Suggestions and comments are welcome.
> 
> Many thanks,
> 
> Marty


GSt

Re: [Etherboot-discuss] Last call for additions to Etherboot 5.4.2

[Glenn B. <gl...@my...>]

I just backed out relocate.patch.  I won't be relying on it, so there is 
no reason for the change.

--Glenn

[Etherboot-discuss] Last call for additions to Etherboot 5.4.2

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

Hello,

I would like to release 5.4.2 in time for LinuxWorld Expo (Monday,  
April 3), so let's review what's new:

     + Timothy Legge updated the r8169 driver with changes to  
RTL8169_VERSION 2.2
       <2004/08/09>

     + Committed patch from Eli Cohen of Mellanox Technologies Ltd  
for Infiniband
       support for their cards.  Thanks to Mellanox for their support  
of the
       Etherboot project

     + Eli Cohen sent a patch for Infiniband to add a readme file,  
sample files to
       help configuring a DHCP server for use with Infiniband and add  
an option for
       the user to print information that is helpful in configuring a  
DHCP server

     + Klaus Espenlaub contributed a patch that fixed Multiboot image  
probing,
       parameter passing to kernels with external boot menu, parsing  
of DHCP tags
       and other miscellaneous cleanups. Changed DHCP offer  
processing slightly to
       avoid always dropping the first offer. Because of a fixed  
pcnet32 driver and
       various small changes Etherboot now works again with VMware  
(tested up to
       version 5.0.0). Also the floppy image no longer loads a fixed  
128KByte
       portion but only what is necessary.

     + Timothy Legge contributed the via-velocity driver for the VIA  
Velocity
       6120/6122 based Gigabit cards based on the Linux 2.6.15.4 driver

     + Michael Brown contributed the etherfabric driver for the  
Etherfabric
       series of cards produced by Level 5 Networks Inc.

These are very exciting additions, and we thank everyone who has  
contributed!

There are two other efforts underway (that I am aware of) that may  
make it into 5.4.2:

     1. Glenn Brown is very near completion on a myricom driver, and if
        hardware is finalized soon, it may be included in 5.4.2.

     2. Ricardo Carrillo Cruz submitted a patch which enables static  
values
        to be supplied for network information.  I am cleaning up the  
patch
        slightly, and hope to include it in 5.4.2.

I would like to temporarily freeze Etherboot-5.4 for release testing  
and bug fixing in a few days.

Does anyone have anything to add to 5.4.2 that I missed?

Suggestions and comments are welcome.

Many thanks,

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/

Re: [Etherboot-discuss] Getting etherboot to relinquish control to bios

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

On Mar 23, 2006, at 7:09 AM, Michael Lamontagne wrote:
> Hi. Please forgive me if this is not the correct forum
> for this, or it has been answered previously.

This is the place.  Welcome.

> I'm trying to configure Etherboot to hand control back
> to the bios in event of TFTP failure,ie file not
> found.

Hmmm, well, looking at src/core/nic.c, around line 421, we see:

         if ( kernel ) {
                 loadkernel(kernel); /* We don't return except on  
error */
                 printf("Unable to load file.\n");
         } else {
                 printf("No filename\n");
         }
         interruptible_sleep(2);         /* lay off the server for a  
while */
         longjmp(restart_etherboot, -1);

So, let's say that function loadkernel(kernel) has just tried to load  
a kernel, and failed.

Normally, it would print "Unable to load file." and sleep 2 seconds  
and try again.

The "longjmp(restart_etherboot, -1);" line is telling Etherboot what  
to do next.

So, what does "-1" mean?

Well, for that, we have to go to src/core/main.c, where, around line  
240 we see:

         /* -1:  timeout or ESC
            -2:  error return from loader
            -3:  finish the current run.
            0:   retry booting bootp and tftp
            1:   retry tftp with possibly modified bootp reply
            2:   retry bootp and tftp
            3:   retry probe bootp and tftp
            4:   start with the next device and retry from there...
            255: exit Etherboot
            256: retry after relocation
         */

So, if after:

                 loadkernel(kernel); /* We don't return except on  
error */
                 printf("Unable to load file.\n");

we were to add:

	        longjmp(restart_etherboot, 255);

Etherboot would exit if it was unable to load the kernel.  This might  
just do what you want.
Of course, your BIOS would have to be setup to go to the next  
device.  I often see people have boot priority set up as:

     CDROM
     FLOPPY
     HARD DISK

In your case, it would depend on if you're booting from ROM or  
FLOPPY, but hopefully this will help you get started.

Are you able to build Etherboot (download 5.4.1, edit the files,  
etc.)?  If not, please ask on the list, and we'll get you an image to  
test.

If this works, it might make an interesting option.  Something like  
"EXIT_ON_TFTP_ERROR".

Anyway, please let us know how it goes, and ask questions questions  
if you get stuck.
I hope this helps you.

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/

> The reason im trying todo this is because the pc's
> booting etherboot need to be able to boot locally from
> the hard drive. The pcs are a part of an old-school
> gameing network that will eventually be used as a
> beowulf/POPS (pile of pc's) cluster. Currently, the
> mechanic im trying is to have etherboot boot an mknbi
> file on the server that has the same name as the pc's
> workgroup name. I'm using a symbolic link to
> differentiate what the pc will do, ie, to reload the
> system, ive created an mknbi-dos image of the
> universal tcp-ip bootdisk found at
> www.netbootdisk.com. For linux booting in the future,
> I'l create a mkelf-linux image, and so on.
>
> However,getting them to boot locally is a prolbem.
> Currently, im trying to set it up so that if the tftp
> image specified in dhcpd.conf does not exist,
> etherboot will exit and the bios will try the next
> boot device.
>
> Ive tried using etherboot as a second stage bootloader
> under PXE, which works on one machine using an intel
> pro/100 NIC. If the PXE file dosent exist, etherboot
> dosent get loaded, and the PXE loader aborts, allowing
> the system to be booted locally.
>
> However, on the gameing cluster, the PXE loader
> (Realtek 8139 generic rom image found at realtek's
> site) freezes no matter what i do. Preferably, i'd
> like to use etherboot as the first stage bootloader.
>
> Another idea that ive tried and semi-works is to use
> mknbi-dos to make a boot image of a floppy disk from
> win98 (the os that im running the gameing systems on)
> specifically designed to boot from the hard disk)
>
> However, the prolbem i run into is occasionally win98
> needs to re-read command.com, which is in the net boot
> image, which, if the network is unavailable, causes a
> serious crash. Ive been unable to re-direct win98's
> calls to command.com to the local copy.
>
> Im using kingston KNE120 network cards with an
> etherboot image from rom-o-matic (rtl8139:rtl8139),
> witch works nicely.
>
> Any ideas?
>
> Thnkas.
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
> language
> that extends applications into web and mobile media. Attend the  
> live webcast
> and join the prime developer group breaking into this new coding  
> territory!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Etherboot-discuss mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-discuss

[Etherboot-discuss] Getting etherboot to relinquish control to bios

[Michael L. <mil...@ya...>]

Hi. Please forgive me if this is not the correct forum
for this, or it has been answered previously.

I'm trying to configure Etherboot to hand control back
to the bios in event of TFTP failure,ie file not
found.

The reason im trying todo this is because the pc's
booting etherboot need to be able to boot locally from
the hard drive. The pcs are a part of an old-school
gameing network that will eventually be used as a
beowulf/POPS (pile of pc's) cluster. Currently, the
mechanic im trying is to have etherboot boot an mknbi
file on the server that has the same name as the pc's
workgroup name. I'm using a symbolic link to
differentiate what the pc will do, ie, to reload the
system, ive created an mknbi-dos image of the
universal tcp-ip bootdisk found at
www.netbootdisk.com. For linux booting in the future,
I'l create a mkelf-linux image, and so on.

However,getting them to boot locally is a prolbem.
Currently, im trying to set it up so that if the tftp
image specified in dhcpd.conf does not exist,
etherboot will exit and the bios will try the next
boot device.

Ive tried using etherboot as a second stage bootloader
under PXE, which works on one machine using an intel
pro/100 NIC. If the PXE file dosent exist, etherboot
dosent get loaded, and the PXE loader aborts, allowing
the system to be booted locally. 

However, on the gameing cluster, the PXE loader
(Realtek 8139 generic rom image found at realtek's
site) freezes no matter what i do. Preferably, i'd
like to use etherboot as the first stage bootloader.

Another idea that ive tried and semi-works is to use
mknbi-dos to make a boot image of a floppy disk from
win98 (the os that im running the gameing systems on)
specifically designed to boot from the hard disk)

However, the prolbem i run into is occasionally win98
needs to re-read command.com, which is in the net boot
image, which, if the network is unavailable, causes a
serious crash. Ive been unable to re-direct win98's
calls to command.com to the local copy.

Im using kingston KNE120 network cards with an
etherboot image from rom-o-matic (rtl8139:rtl8139),
witch works nicely.

Any ideas?

Thnkas. 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Etherboot-discuss] How to test irq() entry point?

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

On Wed, 22 Mar 2006, Glenn Brown wrote:
> What are some good ways to test a driver's irq() entry point?
> I guess this is the same as asking "How do I exercise Etherboot's UNDI 
> interface?"

The only known way is to use the Etherboot UNDI driver, since we don't 
know of anything else that uses the UNDI interface.  You can do this by 
building bin/undi.zpxe.  Fire up your myri10ge driver first, and let that 
download undi.zpxe as the PXE NBP.  undi.zpxe will then control the 
myri10ge via the underlying driver's UNDI interface, which requires a 
working irq() in the underlying driver.

If the myri10ge driver is loaded from ROM then an unmodified undi.zpxe 
should work.  If you want to load the myri10ge from any other media (e.g. 
zdsk) then you'll need to build bin/undi.zpxe with -DPXELOADER_KEEP_ALL, 
so that it won't try to unload and reload the stack.

Michael

Re: [Etherboot-discuss] KEEP_IT_REAL memory constraints?

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

On Wed, 22 Mar 2006, Glenn Brown wrote:
> I bit the bullet and converted the myri10ge driver to allocate buffers 
> according to Etherboot convention (statically allocated in one big 
> structure).

:)  Excellent.

> Can you summarize the memory constraints imposed by GPXE's KEEP_IT_REAL 
> on the text, data, bss, and __shared sections?  I need to know how far I 
> need to push memory savings...

We get up to 64kB for code, plus up to 64kB for everything else. 
Technically, PXE allows us separate 64kB data and stack segments, but 
since gcc knows nothing about segmented addressing, we have to use the 
same segment for both, otherwise code like

   void test_fn ( void ) {
      int x;

      do_something ( &x );
   }

fails, because do_something() can't tell the difference between pointers 
to data and stack segments.  We get away with having a separate code 
segment, because code pointers (i.e. function addresses) are only ever 
used for code jumps (call or jmp instructions), so the CPU implicitly 
assumes that they are relative to %cs anyway.

> Currently, for my bin/myri10ge.o, it looks like my __shared usage will 
> be just under 60KB, .data and .bss will be under 128 bytes each, and 
> code is under 8KB.  Do I need to push further?

Code is fine.  If you can reduce the number of buffers used, it would make 
it less likely to spontaneously fail when the stack crashes into the data 
segment.

Michael

[Etherboot-discuss] How to test irq() entry point?

[Glenn B. <gl...@my...>]

What are some good ways to test a driver's irq() entry point?
I guess this is the same as asking "How do I exercise Etherboot's UNDI 
interface?"

Thanks,
--Glenn

[Etherboot-discuss] KEEP_IT_REAL memory constraints?

[Glenn B. <gl...@my...>]

Michael,

I bit the bullet and converted the myri10ge driver to allocate buffers 
according to Etherboot convention (statically allocated in one big 
structure).

Can you summarize the memory constraints imposed by GPXE's KEEP_IT_REAL 
on the text, data, bss, and __shared sections?  I need to know how far I 
need to push memory savings...

Currently, for my bin/myri10ge.o, it looks like my __shared usage will 
be just under 60KB, .data and .bss will be under 128 bytes each, and 
code is under 8KB.  Do I need to push further?

Thanks,
--Glenn

[Etherboot-discuss] LinuxWorld Expo Boston Reminder -- Monday, April 3 - Thursday, April 6, 2006

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

This list is too quiet, so let me start a few threads to get things  
going.

Come one, come all...

Well, this is a pretty exciting time for us.  LinuxWorld Boston  
starts just 2 weeks from now, and it looks to be a very nice one.   
Here is a list of people who are in the .ORG Pavilion (where we  
exhibit) this time:

     Eclipse
     Etherboot Project
     Fedora Project
     Free Software Foundation
     Free Standards Group
     FreeBSD Project
     Gentoo Foundation
     GNOME
     Joomla!
     KDE
     Linux Link Tech Show
     Linux Questions.org
     Linux Test Project
     LTSP.org
     Mono Project
     OpenOffice.org
     OSSI
     PostgreSQL
     Project
     SugarForge.org
     SUSE Linux
     Ubuntu
     X Foundation

That's pretty nice company to be with.  It's great that the  
LinuxWorld Expo people to have a .ORG Pavilion.  It's one of the most  
interesting places in the show, and even though it's a lot work to  
exhibit, it's worth it to demo Etherboot, and to meet people, and to  
hang with all the great folks of the FOSS community.

The Slashdot Lounge is right in the middle of the Pavilion this time,  
so it should be _very_ interesting.  ( Real hackers love Etherboot  
ROM images, btw ;-p )

Now, you can learn more about the show at:

     http://www.linuxworldexpo.com/

or more specifically at:

     http://www.linuxworldexpo.com/live/12/events/12BOS06A

There's quite a bit of work left to do before the show, but working  
towards a deadline and a pleasant goal makes the work exciting and  
pleasurable.

     So, who's going to be in Boston?

     Does anyone want to help out in the Booth for a few hours?

     ( If you do, you'll definitely have a good time!  Just ask  
Markus! ;)

If you do attend the show, don't forget to drop by and say hello!

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-discuss] Welcome to Etherboot-Discuss

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

Hello,

The subscribers of Etherboot-Users and Etherboot-Developers have been  
merged into a new list called:

     eth...@li...

In cases people were on both lists, the Digest preference was set if  
it was set on either of the old lists.  I hand-applied other list  
preferences, since they could not all be imported.  I apologize in  
advance if I missed anything.

If you would like to change your list settings on these lists, here  
are some handy URLs:

======================================================================== 
==================

For Etherboot-Discuss:

     http://lists.sourceforge.net/lists/listinfo/etherboot-discuss

For Etherboot-Users:

     http://lists.sourceforge.net/lists/listinfo/etherboot-users

For Etherboot-Developers:

     http://lists.sourceforge.net/lists/listinfo/etherboot-developers

======================================================================== 
==================

Automatic posting to the old lists has been suspended, but for a  
while messages will be individually approved, to ease the transition,  
until threads get re-established.

If you have problems with your subscriptions, please send mail to:

     eth...@li...

(or me), and we'll do our best to fix it.

Thanks for participating in the Etherboot Project!

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/