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

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

[Woodruff, Richard]

As to the 8bit to 16 access change, at both the boot and kernel I use 16 bit
accesses.  I'm ok using 8bit access on my board, but based on comments in
code and the ifdef's in the shipping kernel code, switching that access size
will break a few boards.  As word access works, I wouldn't switch that bit.

As far as testing goes, if it works on my board I'm usually happy.  My
opinion would be if you are submitting new code, it doesn't really matter if
it works for anyone else as long as it doesn't break the compile.  If its
existing code, then some more care is obviously necessary.

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

[Stephan Linz]

Hi,

I'm just back to NIOS.

Am Montag,  3. November 2003 19:04 schrieb Woodruff, Richard:
> As to the 8bit to 16 access change, at both the boot and kernel I use 16
> bit accesses.  I'm ok using 8bit access on my board, but based on comments
> in code and the ifdef's in the shipping kernel code, switching that access
> size will break a few boards.  As word access works, I wouldn't switch that
> bit.

Oops, very interesting informations, because the SMSC's manuals for LAN91C110 
and LAN91C1111 sayes about SMC91111_INT_REG: "... This register can be read 
and write as a word or two individual bytes ...". So I'm wondering about a 
few boards will be broken.

Nevertheless, let's leave it at 16bit access. The NIOS board is running in 
both cases, so there is no really important reason to change this bit.

>
> As far as testing goes, if it works on my board I'm usually happy.  My
> opinion would be if you are submitting new code, it doesn't really matter
> if it works for anyone else as long as it doesn't break the compile.  If
> its existing code, then some more care is obviously necessary.

Yes of course, the 16bit to 8 change isn't really important. I've thought it 
could be a good minor code generalization. It wasn't my intention to make 
broken code.

So, here my second try. In attachment yo will find the patch again without 
this critical change.

>
> From a group submission aspect, Wolfgang does a good job of filtering and
> moderating, and likely applies similar logic for submission.  He is
> probably is a bit more stringent in certain areas as the code would become
> more difficult to maintain with out some control.

Oh yes, he does a good job for us.


Regards,
Stephan


> > From: wd at denx.de [mailto:wd at denx.de]
> > Sent: Monday, November 03, 2003 9:40 AM
> > To: Stephan Linz
> > Cc: Woodruff, Richard; u-boot-users at lists.sourceforge.net
> > Subject: Re: [U-Boot-Users] [PATCH-1/2] LAN91C111
> >
> >
> > Dear Stephan,
> >
> > in message <0311031553480Q.02205@pcj86> you wrote:
> > > I'm curious about it. When your test phase / cross check
> > --8<--snipp-->8--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: u-boot-20031103cvs-smc91111_fix.patch-0
Type: text/x-c
Size: 2320 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20031104/d96e77c7/attachment.bin 

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

[Woodruff, Richard]

The comments about broken boards due with the hardware not wiring up byte
enables.  The problem in that case is a board limitation, not a 91c1111.

After you pointed out the mac needs to be unsigned, I went though and
changed "all" mac references.  Seems like there were a couple more than your
patch had.  The kernel drivers I have for this already have your fix, and
treat mac's correctly through out.

Regards,

Richard W.

> -----Original Message-----
> From: Stephan Linz [mailto:linz at mazet.de] 
> Sent: Tuesday, November 04, 2003 12:45 PM
> To: Woodruff, Richard; 'wd at denx.de'
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] [PATCH-1/2] LAN91C111
> 
> 
> 
> Hi,
> 
> I'm just back to NIOS.
> 
> Am Montag,  3. November 2003 19:04 schrieb Woodruff, Richard:
> > As to the 8bit to 16 access change, at both the boot and 
> kernel I use 
> > 16 bit accesses.  I'm ok using 8bit access on my board, but 
> based on 
> > comments in code and the ifdef's in the shipping kernel code, 
> > switching that access size will break a few boards.  As word access 
> > works, I wouldn't switch that bit.
> 
> Oops, very interesting informations, because the SMSC's 
> manuals for LAN91C110 
> and LAN91C1111 sayes about SMC91111_INT_REG: "... This 
> register can be read 
> and write as a word or two individual bytes ...". So I'm 
> wondering about a 
> few boards will be broken.
> 
> Nevertheless, let's leave it at 16bit access. The NIOS board 
> is running in 
> both cases, so there is no really important reason to change this bit.
> 
> >
> > As far as testing goes, if it works on my board I'm usually 
> happy.  My 
> > opinion would be if you are submitting new code, it doesn't really 
> > matter if it works for anyone else as long as it doesn't break the 
> > compile.  If its existing code, then some more care is obviously 
> > necessary.
> 
> Yes of course, the 16bit to 8 change isn't really important. 
> I've thought it 
> could be a good minor code generalization. It wasn't my 
> intention to make 
> broken code.
> 
> So, here my second try. In attachment yo will find the patch 
> again without 
> this critical change.
> 
> >
> > From a group submission aspect, Wolfgang does a good job of 
> filtering 
> > and moderating, and likely applies similar logic for 
> submission.  He 
> > is probably is a bit more stringent in certain areas as the 
> code would 
> > become more difficult to maintain with out some control.
> 
> Oh yes, he does a good job for us.
> 
> 
> Regards,
> Stephan
> 
> 
> > > From: wd at denx.de [mailto:wd at denx.de]
> > > Sent: Monday, November 03, 2003 9:40 AM
> > > To: Stephan Linz
> > > Cc: Woodruff, Richard; u-boot-users at lists.sourceforge.net
> > > Subject: Re: [U-Boot-Users] [PATCH-1/2] LAN91C111
> > >
> > >
> > > Dear Stephan,
> > >
> > > in message <0311031553480Q.02205@pcj86> you wrote:
> > > > I'm curious about it. When your test phase / cross check
> > > --8<--snipp-->8--
> 

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

[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.  Might be
ok.

Regards,

Richard W.

-----Original Message-----
From: Stephan Linz [mailto:linz at mazet.de] 
Sent: Monday, November 03, 2003 7:02 AM
To: Woodruff, Richard; u-boot-users at 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 at lists.sourceforge.net
> [mailto:u-boot-users-admin at lists.sourceforge.net] On Behalf Of Stephan
Linz
> Sent: Monday, November 03, 2003 5:02 AM
> To: u-boot-users at 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=128
>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,

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

[Stephan Linz]

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 at mazet.de]
> Sent: Monday, November 03, 2003 7:02 AM
> To: Woodruff, Richard; u-boot-users at 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 at lists.sourceforge.net
> > [mailto:u-boot-users-admin at lists.sourceforge.net] On Behalf Of Stephan
>
> Linz
>
> > Sent: Monday, November 03, 2003 5:02 AM
> > To: u-boot-users at 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=128
>
> >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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users

-- 
Mit freundlichen Gruessen
Stephan Linz



======================================================================
Stephan Linz
Softwareentwicklung

MAZeT GmbH                   Email: mailto:linz at mazet.de
G?schwitzer Str. 32          Tel. : (3641) 2809-55
D-07745 Jena                 Fax  : (3641) 2809-12

Besuchen Sie bitte unsere Web-Seiten: http://www.MAZeT.de
======================================================================

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

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Remember, there's a big difference between kneeling down and  bending
over.                                                   - Frank Zappa

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

[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.  

Regards,

Richard W.

-----Original Message-----
From: u-boot-users-admin@lists.sourceforge.net
[mailto:u-boot-users-admin at lists.sourceforge.net] On Behalf Of Stephan Linz
Sent: Monday, November 03, 2003 5:02 AM
To: u-boot-users at 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=1289
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,
-- 
Mit freundlichen Gruessen
Stephan Linz



======================================================================
Stephan Linz
Softwareentwicklung

MAZeT GmbH                   Email: mailto:linz at mazet.de
G?schwitzer Str. 32          Tel. : (3641) 2809-55
D-07745 Jena                 Fax  : (3641) 2809-12

Besuchen Sie bitte unsere Web-Seiten: http://www.MAZeT.de
======================================================================

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

[Stephan Linz]

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 at lists.sourceforge.net
> [mailto:u-boot-users-admin at lists.sourceforge.net] On Behalf Of Stephan Linz
> Sent: Monday, November 03, 2003 5:02 AM
> To: u-boot-users at 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=128
>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,

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

[Stephan Linz]

Hi all,

in context of one of my emails last week:
http://sourceforge.net/mailarchive/forum.php?thread_id=3364771&forum_id=12898


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,
-- 
Mit freundlichen Gruessen
Stephan Linz



======================================================================
Stephan Linz
Softwareentwicklung

MAZeT GmbH                   Email: mailto:linz at mazet.de
G?schwitzer Str. 32          Tel. : (3641) 2809-55
D-07745 Jena                 Fax  : (3641) 2809-12

Besuchen Sie bitte unsere Web-Seiten: http://www.MAZeT.de
======================================================================
-------------- next part --------------
A non-text attachment was scrubbed...
Name: u-boot-20031103cvs-smc91111_fix.patch-0
Type: text/x-c
Size: 2545 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20031103/ce1ac026/attachment.bin 

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

[Wolfgang Denk]

In message <0311031202290K.02205@pcj86> you wrote:
> 
> 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.

Checked in. 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
"Whoever undertakes to set himself up as a judge of Truth  and  Know-
ledge is shipwrecked by the laughter of the gods."  - Albert Einstein