RE: [U-Boot-Users] [PATCH] lan91c96 driver MAC address detection
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@lists.sourceforge.net [mailto:u-boot-users- admin@lists.sourceforge.net] On Behalf Of Dave Peverley Sent: Tuesday, May 04, 2004 7:33 AM To: Wolfgang Denk Cc: u-boot-users@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
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
participants (2)
-
Wolfgang Denk -
Woodruff, Richard