Dear Ben,
in message <4a9069e9.2030...@gmail.com> you wrote:
>
> > Tested on mx31ads: works like a charm.
> >
> Great news! Thanks!
Wait... we've not reached the goal yet, I'm afraid...
> > Will try to debug the trab issues later tonight (if I manage to find a
> > matching JTAG connector for this board ).
This turns out to be a nasty one.
The good news is: the hang on trab is not caused by your patch.
Fact is that it is instead caused by using a somewhat recent
(gcc-4.2.2 based) tool chain. This compiler does some ugly things
when attempting to access 32 bit wide registers which cause one of
the trab-specific drivers to hang in the initialization. If I use an
older tool chain (say, gcc-4.0.0 based), your patch works like a
charm, too.
The bad news ist: I don't know how to fix this.
In the first attempt I noticed that the (old) trab code does not use
any I/O accessors at all. My guesses that a "volatile" might be
missing didn't help.
So I changed the code in question to use readl() / writel() - and
this did not help either.
Then I noticed that readl() / writel() on ARM are mapped to
__arch_getl() / __arch_putl() which in turn are just plain stupid
volatile pointer accesses.
So I replaced these #defines by the following code:
static inline uint32_t __arch_getl (uint32_t V_ATTRIB * const addr)
{
uint32_t val;
val = *addr;
return val;
}
static inline void __arch_putl (uint32_t val, uint32_t V_ATTRIB * const addr)
{
*addr = val;
}
With this code, I see the following behaviour:
1) If I use "#define V_ATTRIB volatile" which I think is needed and
technically correct, the trab-specific driver code starts working
again; however, the CS8900 Ethernet driver does not work. It
gives:
TRAB # run load
Using CS8900-0 device
TFTP from server 192.168.1.1; our IP address is 192.168.20.2
Filename '/tftpboot/trab/u-boot.bin'.
Load address: 0xc100000
Loading: T T T T T T T T T T
Retry count exceeded; starting again
Using CS8900-0 device
TFTP from server 192.168.1.1; our IP address is 192.168.20.2
Filename '/tftpboot/trab/u-boot.bin'.
Load address: 0xc100000
Loading: T T T T T T T T T T
Retry count exceeded; starting again
Using CS8900-0 device
TFTP from server 192.168.1.1; our IP address is 192.168.20.2
Filename '/tftpboot/trab/u-boot.bin'.
Load address: 0xc100000
Loading: T T T T T T T T T T
Retry count exceeded; starting again
...
All this in quick sequence, without the usual longish delays /
timeouts.
2) If I use "#define V_ATTRIB" instead (i. e. if I do _not_ use
"volatile"), then the trab driver code hangs again, but the CS8900
Ethernet driver works fine.
It seems the "volatile" causes the compiler to generate different
code - with the volatile it seems that 4 x 8 bit reads are performed
instead of 1 x 32 bit read. Unfortunaltely I wasn't able to reduce
this to a trival test case yet.
Is there anybody out there with good C compiler / assembler knowhow
on ARM - and with an idea how to fix this issue?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The thing is, as you progress in the Craft, you'll learn there is
another rule... When you break rules, break 'em good and hard.
- Terry Pratchett, _Wyrd Sisters_
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
