[U-Boot-Users] tftp problem

[George G. Davis]

On Mon, May 10, 2004 at 11:08:07AM +0200, Wolfgang Denk wrote:
> In message <A5F3D6A490BAD1118AAE00A0C94C2664034025EA at CORREO> you wrote:
> >
> > We're using u-boot 1.0.0 to boot Linux on a Lubbock based platform. We've
> 
> Why are you posting the very same message twice  from  two  different
> mail addresses?
> 
> Please NEVER do this again!!!!
> 
> > We know that the tftp server works because we've tested it with other
> > clients. But with tftp in u-boot we're only able to transfer little files
> > (1, 2 Kb).. 
> 
> What happens then? Is there an error mesaage or what? Did you try  to
> debug the problem?
> 
> > Which can be the problem?? Newer versions work fine??
> 
> Ummm... did you try it out? If yes, what was the result? If not, why not???

FWIW, I've noticed that the Lubbock SMC_inb macro in drivers/lan9196.h is
broken. Take a look at that Lubbock SMC_inb macro definition:

#define SMC_inb(p)	({ \
	unsigned int __p = (unsigned int)(SMC_BASE_ADDRESS + (p * 4)); \
	unsigned int __v = *(volatile unsigned short *)((__p) & ~1); \
	if (__p & 1) __v >>= 8; \
	else __v &= 0xff; \
	__v; })


I believe that definition should be rewritten as follows (ignoring issues
of coding style or personal preferences : ):

#define SMC_inb(p)	({ \
	unsigned int __p = (unsigned int)(SMC_BASE_ADDRESS + ((p) * 4)); \
	unsigned int __v = *(volatile unsigned short *)(__p & ~4); \
	if (__p & 4) __v >>= 8; \
	else __v &= 0xff; \
	__v; })


I don't have a Lubbock target so I can't vouch for the accuracy of my
assertion. But it clearly seems broken as currently written. Also have a
look at the Lubbock kernel lan91c96 support to review those macros there
and draw your own conclusions.

I have no idea if this will help with this problem. But it probably won't
hurt. : )

HTH!

--
Regards,
George