[U-Boot-Users] [PATCH] lan91c96 driver MAC address detection

[U-Boot-Users] [PATCH] lan91c96 driver MAC address detection

[Dave Peverley]

Hi all,

  This is a small patch for the lan91c96 ethernet driver that adds the
capability to automatically detect the MAC address stored in EPROM in the
absence of a valid MAC address in the environment. It is modelled on the
system used by the smc91111 driver as suggested by Marius Groeger 
(thanks!)

The patch itself was created against the CVS repository tag 
"U-Boot-1_1_0" using the command :
  diff -purN u-boot u-boot-omap730p2 > u-boot-1.1.0-omap730p2.patch

All comments and feedback welcome.

Best Wishes,

Dave Peverley


---------------------------------------------------------------------------
             Dave Peverley, Software Engineer, MPC Data Limited.
Phone : [+44] (0) 1225 868 228              Web : http://www.mpc-data.co.uk
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: u-boot-1.1.0-lan91c96-mac-detect.patch
Url: http://lists.denx.de/pipermail/u-boot/attachments/20040429/02301e27/attachment.txt 

[U-Boot-Users] [PATCH] lan91c96 driver MAC address detection

[George G. Davis]

On Thu, Apr 29, 2004 at 06:02:01PM +0100, Dave Peverley wrote:
> Hi all,
> 
>  This is a small patch for the lan91c96 ethernet driver that adds the
> capability to automatically detect the MAC address stored in EPROM in the
> absence of a valid MAC address in the environment. It is modelled on the
> system used by the smc91111 driver as suggested by Marius Groeger 
> (thanks!)
> 
> The patch itself was created against the CVS repository tag 
> "U-Boot-1_1_0" using the command :
>  diff -purN u-boot u-boot-omap730p2 > u-boot-1.1.0-omap730p2.patch
> 
> All comments and feedback welcome.

Cool! Thanks for that! I have a minor suggestion though. Can we squelch
the warning for the "setenv ethaddr" case? Like so:

--- drivers/lan91c96.c.orig	2004-04-29 13:15:14.000000000 -0400
+++ drivers/lan91c96.c	2004-04-30 15:47:45.000000000 -0400
@@ -886,9 +886,7 @@
 	uchar v_rom_mac[6];
 
 	env_size = getenv_r ("ethaddr", s_env_mac, sizeof (s_env_mac));
-	if (env_size != sizeof(es)) {	/* Ignore if env is bad or not set */
-		printf ("\n*** Warning: ethaddr is not set properly, ignoring!!\n");
-	} else {
+	if (env_size == sizeof(es)) {
 		env_present = 1;
 		s = s_env_mac;
 
@@ -897,7 +895,8 @@
 			if (s)
 				s = (*e) ? e + 1 : e;
 		}
-	}
+	} else if (env_size >= 0)	/* Ignore if env is bad */
+		printf ("\n*** Warning: ethaddr is not set properly, ignoring!!\n");
 
 	rom_valid = get_rom_mac (v_rom_mac);	/* get ROM mac value if any */
 

I've tested your patch with the above change and it works for me:

OMAP1510 Innovator # bootp
Using MAC Address 08:00:28:32:0F:FF
BOOTP broadcast 1
DHCP client bound to address 192.168.1.91
OMAP1510 Innovator # setenv ethaddr 00:11:22:33:44
OMAP1510 Innovator # bootp

*** Warning: ethaddr is not set properly, ignoring!!
Using MAC Address 08:00:28:32:0F:FF
BOOTP broadcast 1
DHCP client bound to address 192.168.1.91
OMAP1510 Innovator # setenv ethaddr
OMAP1510 Innovator # bootp
Using MAC Address 08:00:28:32:0F:FF
BOOTP broadcast 1
DHCP client bound to address 192.168.1.91


Thanks again!

--
Regards,
George
> 
> Best Wishes,
> 
> Dave Peverley

<snip>

[U-Boot-Users] [PATCH] lan91c96 driver MAC address detection

[Dave Peverley]

George G. Davis wrote:
> Cool! Thanks for that! 
No porbs :-)

> I have a minor suggestion though. Can we squelch
> the warning for the "setenv ethaddr" case? Like so:
Sure, I have no preference either way. I think I originally put in the 
warning as I have the impression that Wolfgang's preference is to
have the user use the environment to set the MAC address rather than
have it detected. 

Of course the easiest way to suppress the message is to do a 'bootp' 
to read teh detected address, and then 'saveenv' to set it permenently.
This is perhaps something I should have added to the README?

Best Wishes,

~Pev

---------------------------------------------------------------------------
             Dave Peverley, Software Engineer, MPC Data Limited.
Phone : [+44] (0) 1225 868 228              Web : http://www.mpc-data.co.uk

[U-Boot-Users] [PATCH] lan91c96 driver MAC address detection

[Wolfgang Denk]

In message <409766D3.2030409@mpc-data.co.uk> you wrote:
> 
> > I have a minor suggestion though. Can we squelch
> > the warning for the "setenv ethaddr" case? Like so:
> Sure, I have no preference either way. I think I originally put in the 
> warning as I have the impression that Wolfgang's preference is to
> have the user use the environment to set the MAC address rather than
> have it detected. 

The rules are simple and documented:

o If the SROM has a valid MAC address, and there is no address in the
  environment, the SROM's address is used.

o If there is no valid address in the SROM, and a definition in the
  environment exists, then the value from the environment variable is
  used.

o If both the SROM and the environment contain a MAC address, and
  both addresses are the same, this MAC address is used.

o If both the SROM and the environment contain a MAC address, and the
  addresses differ, the value from the environment is used and a
  warning is printed.

o If neither SROM nor the environment contain a MAC address, an error
  is raised.


> Of course the easiest way to suppress the message is to do a 'bootp' 
> to read teh detected address, and then 'saveenv' to set it permenently.

You cannot use BOOTP (nor ony  other  network  related  protocol)  to
detect a MAC address!!!


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
It is easier to write an incorrect program than understand a  correct
one.

[U-Boot-Users] [PATCH] lan91c96 driver MAC address detection

[Dave Peverley]

Wolfgang Denk wrote:
> The rules are simple and documented:
Sure, I've read these...

> You cannot use BOOTP (nor ony  other  network  related  protocol)  to
> detect a MAC address!!!
I think that either we operate on utterly different brainwave-lengths 
or theres some kind of language barrier issue here!

If you issue a 'bootp' command to u-boot via its interface as I stated, 
the following call sequence happens if you're using the lan91c96 (with 
patch) or smc91111 ethernet devices :
  
   do_bootp()                     [cmd_net.c]
    netboot_common()              [cmd_net.c]
     NetLoop()                    [net.c]
      eth_init()                  [lan91c96.c]
       smc_open()                 [lan91c96.c]
        smc_get_ethaddr()         [lan91c96.c]
         get_rom_mac()            [lan91c96.c]
 
So in practical use, issuing a bootp detects the mac address of the 
adapter. 

> (nor ony  other  network  related  protocol) 
Well, the following network related protocol calls :
  do_tftpb()
  do_rarpb()
  do_dhcp()
  do_nfs()
all call netboot_common() so will in effect detect the MAC address as 
well ;-)

Best Wishes,

Dave Peverley

---------------------------------------------------------------------------
             Dave Peverley, Software Engineer, MPC Data Limited.
Phone : [+44] (0) 1225 868 228              Web : http://www.mpc-data.co.uk

[U-Boot-Users] [PATCH] lan91c96 driver MAC address detection

[Wolfgang Denk]

In message <40978D65.7030805@mpc-data.co.uk> you wrote:
>
> > You cannot use BOOTP (nor ony  other  network  related  protocol)  to
> > detect a MAC address!!!
> I think that either we operate on utterly different brainwave-lengths 
> or theres some kind of language barrier issue here!

BOOTP is a well-defined protocol which is  based  on  the  assumption
that  you  have  a  network  interface  that  can be used to send and
receive packets. To do so, the interface must be  initialized.  BOOTP
does  in  NO  WAY  work if your interface does not have a MAC address
set. Especially, it does NOT retrieve the MAC address from anywhere.

> If you issue a 'bootp' command to u-boot via its interface as I stated, 
> the following call sequence happens if you're using the lan91c96 (with 
> patch) or smc91111 ethernet devices :
>   
>    do_bootp()                     [cmd_net.c]
>     netboot_common()              [cmd_net.c]
>      NetLoop()                    [net.c]
>       eth_init()                  [lan91c96.c]

Stop here. eth_init() performs the  initialization  of  the  ethernet
interface,  if  this  did  not  happen before, because an initialized
ethernet interface is a precondition to use BOOTP.

> So in practical use, issuing a bootp detects the mac address of the 
> adapter. 

No, no, no. This is plainly wrong.

> Well, the following network related protocol calls :
>   do_tftpb()
>   do_rarpb()
>   do_dhcp()
>   do_nfs()
> all call netboot_common() so will in effect detect the MAC address as 
> well ;-)

None of these protocols has ato do  anything  with  setting  the  MAC
address. Please don't mix things up.

You could as well claim that bootp sets the baudrate  of  the  serial
console,  because  to  run  bootp  you must execute an initialization
sequence which includes the serial port, thus setting the baudrate.

IT AIN'T SO!


Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Oh, that sound of male ego.  You travel halfway across the galaxy and
it's still the same song.
	-- Eve McHuron, "Mudd's Women", stardate 1330.1

Communication (Was Re: [U-Boot-Users] [PATCH] lan91c96 driver MAC address detection)

[Dave Peverley]

Wolfgang Denk wrote:
>>If you issue a 'bootp' command to u-boot via its interface as I stated, 
>>the following call sequence happens
...
>>So in practical use, issuing a bootp detects the mac address of the 
>>adapter. 
> No, no, no. This is plainly wrong.

I've tried my best to explain this concisely and with no room for 
mis-interpretation but I have seemed to fail and I can't see why. I don't
think anyone else managed to mis-read me as radically as this, so I've 
taken this off list to try and clear up with Wolfgang whatever the 
mixup seems to be.  Apologies to all.... 

Best Wishes,

~Pev

---------------------------------------------------------------------------
             Dave Peverley, Software Engineer, MPC Data Limited.
Phone : [+44] (0) 1225 868 228              Web : http://www.mpc-data.co.uk

[U-Boot-Users] [PATCH] lan91c96 driver MAC address detection

[Wolfgang Denk]

Dear Dave,

in message <40913509.1090309@mpc-data.co.uk> you wrote:
> 
>   This is a small patch for the lan91c96 ethernet driver that adds the
> capability to automatically detect the MAC address stored in EPROM in the
> absence of a valid MAC address in the environment. It is modelled on the
> system used by the smc91111 driver as suggested by Marius Groeger 

Added, thanks.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
There are very few personal problems that cannot be solved through  a
suitable application of high explosives.

[U-Boot-Users] [PATCH] lan91c96 driver MAC address detection

[Woodruff, Richard]

Actually, I added the following 2 functions to remove related
problems... 

Aside from the warning you will find that if you 'directly' boot your
system and have NOT set the mac address via the indirect bootp probe, a
kernel built for a nfsroot won't make it, as the kernel driver assumes a
valid mac is set (or available).  So, in my board's misc_init_r() I make
sure to probe for a chip, if its there go ahead and set the mac address
up.  (several boards I've used didn't have a serial eeprom).  Seems like
some chips do something similar (reset anyway) in lib_arm/board.c, but I
think its better to done at the board level.

This probably also kills the mac warning.

Regards,

Richard W.



=============== Added to smc91111.c =======================
static int smc_probe(void)
{
	int bank;
	
	bank =  SMC_inw (BANK_SELECT);
	if ((bank & 0xFF00) != 0x3300)
		return -1;
	return 0;
}

/* 
 * Set MAC address even if smc_open is not called by u-boot. Its a good
idea
 * for the mac to be set in the chip when the kernel starts (no eeprom
case).
 */
int eth_mac_config(bd_t *bd)
{
	int err, i;

	err = smc_probe();
        if(err >= 0){
		SMC_SELECT_BANK (1);
		smc_get_ethaddr (bd);
		for (i = 0; i < 6; i++)
			SMC_outb (smc_mac_addr[i], ADDR0_REG + i);
	}
	return err;
}



========== in myboard.c file ================
int misc_init_r (void)
{   
#ifdef CONFIG_DRIVER_SMC91111
    DECLARE_GLOBAL_DATA_PTR;
    extern int eth_mac_config(bd_t *);

    /* for development board enable ethernet */
    /* take chip out of reset (need shadow reg) */
    toto_bcr_write( toto_bcr_read() | TOTO_BCR_COM_RESET);
    udelay(300);    
    eth_mac_config(gd->bd); /* set mac addr in chip */
#endif

    return(0);
}


> -----Original Message-----
> From: u-boot-users-admin at lists.sourceforge.net [mailto:u-boot-users-
> admin at lists.sourceforge.net] On Behalf Of Dave Peverley
> Sent: Tuesday, May 04, 2004 7:33 AM
> To: Wolfgang Denk
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] [PATCH] lan91c96 driver MAC address
detection
> 
> Wolfgang Denk wrote:
> > The rules are simple and documented:
> Sure, I've read these...
> 
> > You cannot use BOOTP (nor ony  other  network  related  protocol)
to
> > detect a MAC address!!!
> I think that either we operate on utterly different brainwave-lengths
> or theres some kind of language barrier issue here!
> 
> If you issue a 'bootp' command to u-boot via its interface as I
stated,
> the following call sequence happens if you're using the lan91c96 (with
> patch) or smc91111 ethernet devices :
> 
>    do_bootp()                     [cmd_net.c]
>     netboot_common()              [cmd_net.c]
>      NetLoop()                    [net.c]
>       eth_init()                  [lan91c96.c]
>        smc_open()                 [lan91c96.c]
>         smc_get_ethaddr()         [lan91c96.c]
>          get_rom_mac()            [lan91c96.c]
> 
> So in practical use, issuing a bootp detects the mac address of the
> adapter.
> 
> > (nor ony  other  network  related  protocol)
> Well, the following network related protocol calls :
>   do_tftpb()
>   do_rarpb()
>   do_dhcp()
>   do_nfs()
> all call netboot_common() so will in effect detect the MAC address as
> well ;-)
> 
> Best Wishes,
> 
> Dave Peverley
> 
>
------------------------------------------------------------------------
--
> -
>              Dave Peverley, Software Engineer, MPC Data Limited.
> Phone : [+44] (0) 1225 868 228              Web : http://www.mpc-
> data.co.uk
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle
10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] [PATCH] lan91c96 driver MAC address detection

[Wolfgang Denk]

In message <71555548814716479478431542AA5F8ADF8B08@dlee2k04.ent.ti.com> you wrote:
> Actually, I added the following 2 functions to remove related
> problems... 

can you please submit a proper patch?

Your message as is is useless. I will not go and try to find  out  if
and where to add this.

> Aside from the warning you will find that if you 'directly' boot your
> system and have NOT set the mac address via the indirect bootp probe, a

Please STOP spreading this misinformation.

bootp has NOTHING to do with  setting  the  MAC  address.  I  repeat:
NOTHING.  It  has  alo  nothing  to  do  with  setting  the CPU clock
frequencies, the console baudrate, or the phase of moon.

> kernel built for a nfsroot won't make it, as the kernel driver assumes a
> valid mac is set (or available).  So, in my board's misc_init_r() I make

In this case the kernel driver is misdesigned. The old rule is that a
driver should make no assumptions about the  state  of  the  hardware
when  it  starts,  except  when  certain preconditions are well docu-
mented. But this is a  Linux  issue,  and  off  topic  here.  Go  and
complain on the Linux list if you like.

> sure to probe for a chip, if its there go ahead and set the mac address
> up.  (several boards I've used didn't have a serial eeprom).  Seems like

This is against the design principles of U-Boot.  Normally,  you  are
expected  to  initialize a device or interface if and only if you are
going to use it in U-Boot.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Every program has at least one bug and can be shortened by  at  least
one  instruction  --  from  which,  by induction, one can deduce that
every program can be reduced to one instruction which doesn't work.

[U-Boot-Users] [PATCH] lan91c96 driver MAC address detection

[Woodruff, Richard]

:)

You might say that the u-boot 'bootp command implementation', which
utilizes the bootp protocol, will initialize the ether driver which in
turn causes mac address initialization.  All u-boot network 'commands'
do this as their protocols require that the mac is setup as a
precondition to their use.

I have to admit the first time I read the post I was confused to the
intent.

Regards,

Richard W.

> -----Original Message-----
> From: u-boot-users-admin at lists.sourceforge.net [mailto:u-boot-users-
> admin at lists.sourceforge.net] On Behalf Of Wolfgang Denk
> Sent: Tuesday, May 04, 2004 12:02 PM
> To: Dave Peverley
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] [PATCH] lan91c96 driver MAC address
detection
> 
> In message <40978D65.7030805@mpc-data.co.uk> you wrote:
> >
> > > You cannot use BOOTP (nor ony  other  network  related  protocol)
to
> > > detect a MAC address!!!
> > I think that either we operate on utterly different
brainwave-lengths
> > or theres some kind of language barrier issue here!
> 
> BOOTP is a well-defined protocol which is  based  on  the  assumption
> that  you  have  a  network  interface  that  can be used to send and
> receive packets. To do so, the interface must be  initialized.  BOOTP
> does  in  NO  WAY  work if your interface does not have a MAC address
> set. Especially, it does NOT retrieve the MAC address from anywhere.
> 
> > If you issue a 'bootp' command to u-boot via its interface as I
stated,
> > the following call sequence happens if you're using the lan91c96
(with
> > patch) or smc91111 ethernet devices :
> >
> >    do_bootp()                     [cmd_net.c]
> >     netboot_common()              [cmd_net.c]
> >      NetLoop()                    [net.c]
> >       eth_init()                  [lan91c96.c]
> 
> Stop here. eth_init() performs the  initialization  of  the  ethernet
> interface,  if  this  did  not  happen before, because an initialized
> ethernet interface is a precondition to use BOOTP.
> 
> > So in practical use, issuing a bootp detects the mac address of the
> > adapter.
> 
> No, no, no. This is plainly wrong.
> 
> > Well, the following network related protocol calls :
> >   do_tftpb()
> >   do_rarpb()
> >   do_dhcp()
> >   do_nfs()
> > all call netboot_common() so will in effect detect the MAC address
as
> > well ;-)
> 
> None of these protocols has ato do  anything  with  setting  the  MAC
> address. Please don't mix things up.
> 
> You could as well claim that bootp sets the baudrate  of  the  serial
> console,  because  to  run  bootp  you must execute an initialization
> sequence which includes the serial port, thus setting the baudrate.
> 
> IT AIN'T SO!
> 
> 
> Wolfgang Denk
> 
> --
> Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
> Oh, that sound of male ego.  You travel halfway across the galaxy and
> it's still the same song.
> 	-- Eve McHuron, "Mudd's Women", stardate 1330.1
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle
10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users