Hi Nick,
Thanx for the reply . I have read last month's mail regarding this.
> Have you checked bit 18 (K0DB2) of the MDREFR register (SA1110
> developer's manual pg. 10-15, section 10.2.2)??
Bit 18 says SMROM clock pin 0 (SDCLK 0) divide by 2 control /status.
Why should I check it ? Am I missing any thing here?
>
> In order for your RAM to work at 60MHz, it should have a "Tac" of
> about 6ns or better (and *not* use delayed latching). Otherwise forget
> it. In general if you are not using delayed latching you must make
> sure that:
>
> SDRAM's(Tac) <= Tmem - 9.3ns
I am having a Winbond W986416DH-7. The Tac is given as 5.5ns at CS=3 and
it is 6 ns at CS=2. Since I am running at 103.2 Mhz then Tmem=19.379ns
Tmem-7.2(for 133 Mhz processor) = ~12ns and hence I must be able to run at
half the clock speed but I am not able to.
>
> This means that for speeds *above* about 60Mhz you *should* use
> delayed latching. And it's funny that it is still not sure that it
> will work (strange as it may sound)! As a rule of thumb, when using
> *delayed latching*, at say ~69MHz, the critical thing is to make sure
> that you RAM has a Toh >= ~4.7ns.
This factor depends whether you use a 133 Mhz or a 206 Mhz SA1110.
If you see the specification update April 2001 page 69 section 13.6
The data input set up time to SDCLK <2:0> rise (Tsdis) 28-66 Nondelayed- 7.2
ns
and when you use a 206 Mhz processor it differs .
28-62 -Nondelayed- 9.3ns
62-103- Delayed. - 2.7ns
Coming to the hold time(tsdis) here also it differs whether it is a 133 or a
206 one according to the specification update
28-66 - 2.7 ns -133 Mhz -Nondelayed latching
If you use a 206 Mhz processor
28-62 - 2.7ns- Nondelayed
62-69- 5.5ns- Delayed
So here my SDRAM's Toh=3ns hence it should run at half the clock speed
without trouble but it is not running.
-
My problem is that I am getting problem only during SDRAM reads.
The following code runs at 1/4 clock speed properly and not at half the
clock speed. During memory verify( *only * when running at 50% clock
frequency ) it gives wrong values at some locations and hence a memory
failure occurs.
mov r7, #0xC0000000
add r6, r7, #0x1000000 /* 16 MB SDRAM */
mov r4, r7
memoryload:
str r4, [r4]
add r4, r4, #0x400 /* Each row is only 1K */
adr r0, del10 /* backspace */
bl print_str /* Priting via UART1*/
mov r0, r4
bl print_hex
cmp r4, r6
blt memoryload
mov r4, r7
adr r0, memoryverify
bl print_str
memorytest:
ldr r5, [r4]
mov r0, r4
bl print_hex
adr r0, del10
bl print_str
cmp r5, r4
bne memoryfail
add r4, r4, #0x400
cmp r4, r6
blt memorytest
b alias_done
memoryfail:
adr r0, memoryfailure
bl print_str
mov r0, r5
bl print_hex
done:
b done
Also I would like to know about the Errata mentioned in April 2001
specification update.
Problem 13 page 23 says
Corruption of internal register reads/writes following SDRAM/SMROM reads
PRoblem:
"Reads and writes from and to internal registers other than memory
controller registers can be conrrupted if they immediately follow reads
from SDRAM or SMROM
REgister reads following reads from SDRAM or SMROM on 32 bit data
buses with SDCLK running at full memory clock frequency and using
nondelayed data latching. "
It does not mention whether it is for a 133 Mhz one or a 206 Mhz one.
They have mentioned a work around which says
" For SDRAM at 32 bit data buses
a higher core clock frequency and delayed data latching
set the SDCLK to run at half memory clock frequency (MDREFR:KnDB2 =1)"
and it says the status is fixed. Does this mean that the workaround is the
fix mentioned ? BEcause it doesn't say fixed on B2 . Whereas for some errata
they have carefully mentioned that Fixed on a particular stepping.
what am I missing ?
Harishankkar
_______________________________________________
http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
Please visit the above address for information on this list.
