[U-Boot-Users] tftp problem -> Solved

[Sonia Martinez <anexwarrior@hotmail.com>]

TFTP works. I applied the changes suggested by James Jiao.
I've modified the udelay routine in /cpu/pxa/interrupts.c the way he
explained and it works.
Thank you all for your help
Sonia
----- Original Message -----
From: "George G. Davis" <davis_g@comcast.net>
To: "Wolfgang Denk" <wd@denx.de>
Cc: "Martinez Sonia" <SMartinez@ikerlan.es>; "Sonia Martinez"
<anexwarrior@hotmail.com>; <u-boot-users@lists.sourceforge.net>
Sent: Monday, May 10, 2004 5:28 PM
Subject: Re: [U-Boot-Users] tftp problem


> On Mon, May 10, 2004 at 11:08:07AM +0200, Wolfgang Denk wrote:
> > In message <A5F3D6A490BAD1118AAE00A0C94C2664034025EA@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
>