RE: [U-Boot-Users] [PATCH-1/2] LAN91C111

Hi Stephen,
Yes I suppose. When I snoop packets I have gotten what I expected. Could be luck I suppose, I'll check the address block we use. The reset of the changes looked reasonable....switching the one word access to a byte access might need looking at...I seem to recall reading threads where some boards weren't wired up to do 8 byte accesses correctly. I'd cross check with the kernel level driver 91c1111 or 91c9x.c, before making that change. Might be ok.
Regards,
Richard W.
-----Original Message----- From: Stephan Linz [mailto:linz@mazet.de] Sent: Monday, November 03, 2003 7:02 AM To: Woodruff, Richard; u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] [PATCH-1/2] LAN91C111
Am Montag, 3. November 2003 13:13 schrieb Woodruff, Richard:
I've been using the 91111 for a while now. I've not had any real problems with it. As the environment I'm in has some 30 odd boards, I've never
used
the hard coded mac address.
Hi Richard
It is not a problem of hard coded mac addresses because smc_mac_addr[] will be used as buffer storage too. Furthermore it's a problem of type casting from signed char to unsigned short (type of word) when writing the mac address into LAN91C111 (near line smc91111.c:smc_open():700 the USE_32_BIT branch).
Note: it could be _only_ a NIOS related problem, but I think the type unsigned char for smc_mac_addr[] is more exact in common case, or not?
Regards, Stephan
Regards,
Richard W.
-----Original Message----- From: u-boot-users-admin@lists.sourceforge.net [mailto:u-boot-users-admin@lists.sourceforge.net] On Behalf Of Stephan
Linz
Sent: Monday, November 03, 2003 5:02 AM To: u-boot-users@lists.sourceforge.net Subject: [U-Boot-Users] [PATCH-1/2] LAN91C111
Hi all,
in context of one of my emails last week:
http://sourceforge.net/mailarchive/forum.php?thread_id=3364771&forum_id=...
9 8
I'm wondering about how many people are using the LAN91C111 driver without significant problems. There is (just was :-) a fat signed/unsigned bug in drivers/smc91111.c which is significant at NIOS plattforms when you are using MAC addresses with address elements above 0x7f. Example: 00:07:ed:0a:a4:7b goes over to 00:07:ed:ff:a4:ff inside the chip. Simple solution:
static char smc_mac_addr[] = { . . . };
have to be:
static char unsigned smc_mac_addr[6] = { . . . };
In attatchment you will find my smc91111_fix patch. It includes some other minor fixes I've made. This patch has been working successful at NIOS Stratix and Cyclone boards.
Please try out and patch CVS tree.
Best Regards,

Am Montag, 3. November 2003 14:06 schrieb Woodruff, Richard:
Hi Stephen,
Yes I suppose. When I snoop packets I have gotten what I expected. Could be luck I suppose, I'll check the address block we use. The reset of the changes looked reasonable....switching the one word access to a byte access might need looking at...I seem to recall reading threads where some boards weren't wired up to do 8 byte accesses correctly. I'd cross check with the kernel level driver 91c1111 or 91c9x.c, before making that change.
I'm curious about it. When your test phase / cross check has success what is the next step to put in this patch into U-Boot CVS repository? I need a time line to plan my further jobs.
Regards, Stephan
Richard W.
-----Original Message----- From: Stephan Linz [mailto:linz@mazet.de] Sent: Monday, November 03, 2003 7:02 AM To: Woodruff, Richard; u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] [PATCH-1/2] LAN91C111
Am Montag, 3. November 2003 13:13 schrieb Woodruff, Richard:
I've been using the 91111 for a while now. I've not had any real problems with it. As the environment I'm in has some 30 odd boards, I've never
used
the hard coded mac address.
Hi Richard
It is not a problem of hard coded mac addresses because smc_mac_addr[] will be used as buffer storage too. Furthermore it's a problem of type casting from signed char to unsigned short (type of word) when writing the mac address into LAN91C111 (near line smc91111.c:smc_open():700 the USE_32_BIT branch).
Note: it could be _only_ a NIOS related problem, but I think the type unsigned char for smc_mac_addr[] is more exact in common case, or not?
Regards, Stephan
Regards,
Richard W.
-----Original Message----- From: u-boot-users-admin@lists.sourceforge.net [mailto:u-boot-users-admin@lists.sourceforge.net] On Behalf Of Stephan
Linz
Sent: Monday, November 03, 2003 5:02 AM To: u-boot-users@lists.sourceforge.net Subject: [U-Boot-Users] [PATCH-1/2] LAN91C111
Hi all,
in context of one of my emails last week:
http://sourceforge.net/mailarchive/forum.php?thread_id=3364771&forum_id=...
9 8
I'm wondering about how many people are using the LAN91C111 driver without significant problems. There is (just was :-) a fat signed/unsigned bug in drivers/smc91111.c which is significant at NIOS plattforms when you are using MAC addresses with address elements above 0x7f. Example: 00:07:ed:0a:a4:7b goes over to 00:07:ed:ff:a4:ff inside the chip. Simple solution:
static char smc_mac_addr[] = { . . . };
have to be:
static char unsigned smc_mac_addr[6] = { . . . };
In attatchment you will find my smc91111_fix patch. It includes some other minor fixes I've made. This patch has been working successful at NIOS Stratix and Cyclone boards.
Please try out and patch CVS tree.
Best Regards,
This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

Dear Stephan,
in message 0311031553480Q.02205@pcj86 you wrote:
I'm curious about it. When your test phase / cross check has success what is the next step to put in this patch into U-Boot CVS repository? I need a time line to plan my further jobs.
Please allow for a couple of days - Richard needs some time for testing, and I won;t find time to check anything in before Thursday anyway. If by then nobody complained I will check in your patches - thanks for it.
Best regards,
Wolfgang Denk
participants (3)
-
Stephan Linz
-
Wolfgang Denk
-
Woodruff, Richard