Menu
▾
▴
blob-cvs-commit
|
From: Abraham vd M. <ab...@2d...> - 2002-10-14 08:33:01
|
Hi! Sorry for the cross post, but I'm not sure if all the BLOB developers are on the linux-arm-kernel mailinglists and this question involves them as well. I've got a StrongARM board with a DIMM on it and I can't figure out how to configure the DRI (see MDREFR register in SA-1110 dev manual) bitfield in the MDREFR. The StrongARM manual talks about ((Tref - Tburst) / rows) / Fmem) / 32 where Tref =3D refresh time of SDRAM Tburst =3D longest burst access in _any_ memory region Fmem =3D memory clock speed. rows =3D row address bits However they don't mention any units. Is Tref in ms? Tburst surely can't be in ms right in which case that equation doesn't make sens Is Fmem in Hz? Does the row address bits include the extra bank select bits or not? In arch/arm/mach-sa1110/cpu-sa1110.c I see that Russel seems to do (Tref >> rows) / 32 where Tref is in clocks which makes sense apart from the bug (it should be / rows, not >> rows) and the fact that it doesn't take burst access into account. The refresh time found in SDRAM SPD's - is that per row or for the whole module? Must be per row, since the longest possible refresh time is 125us. I'd really appreciate it if somebody could shed some light on this. --=20 Regards Abraham Teamwork is essential -- it allows you to blame someone else. __________________________________________________________ Abraham vd Merwe - 2d3D, Inc. Device Driver Development, Outsourcing, Embedded Systems Cell: +27 82 565 4451 Snailmail: Tel: +27 21 761 7549 Block C, Aintree Park Fax: +27 21 761 7648 Doncaster Road Email: ab...@2d... Kenilworth, 7700 Http: http://www.2d3d.com South Africa |
|
From: Russell K. - A. L. <li...@ar...> - 2002-10-14 09:10:33
|
On Mon, Oct 14, 2002 at 10:17:40AM +0200, Abraham vd Merwe wrote:
> In arch/arm/mach-sa1110/cpu-sa1110.c I see that Russel seems to do
>
> (Tref >> rows) / 32
>
> where Tref is in clocks which makes sense apart from the bug (it should be /
> rows, not >> rows) and the fact that it doesn't take burst access into
> account.
That's not a bug. "rows" here is the number of address bits for a row
address. In the intel documentation, they're talking about the number
of rows - in other words 2^row_bits. So shifting right is the correct
thing to do in our case.
> The refresh time found in SDRAM SPD's - is that per row or for the whole
> module? Must be per row, since the longest possible refresh time is 125us.
Tref is the time between refreshes on a single row of dynamic RAM. As
an example, take a Tref of 64ms and 12-bits of row address (ie, 4096
rows.)
This means that row 0 must be refreshed every 64ms. Or to put it another
way, you need to refresh all rows in the chip within 64ms:
0ms 64ms
v v
time: ------------------------------------>
rownr: 0 1 2 3 ... 4095 0 1 2
|
|
From: Abraham vd M. <ab...@2d...> - 2002-10-14 09:35:49
|
Hi Russell! > > The refresh time found in SDRAM SPD's - is that per row or for the whole > > module? Must be per row, since the longest possible refresh time is 125= us. >=20 > Tref is the time between refreshes on a single row of dynamic RAM. As > an example, take a Tref of 64ms and 12-bits of row address (ie, 4096 > rows.) >=20 > This means that row 0 must be refreshed every 64ms. Or to put it another > way, you need to refresh all rows in the chip within 64ms: >=20 > 0ms 64ms > v v > time: ------------------------------------> > rownr: 0 1 2 3 ... 4095 0 1 2 That's what I gathered. However in the SDRAM SPD (Serial Presence Detect - the little EEPROM which contains the info about the DIMM) module, the refresh time goes from 3.9us up to 125us which is orders of magnitude shorter than all the other refresh times I've seen. So I've thought that the XXms refresh times was for all the rows and that the SPD specs has it per row, but the explanation above throws that theory out the door. Do you think it is possible that the SDRAM dimms can have such short refresh times? See http://developer.intel.com/technology/memory/pc133sdram/spec/Spdsd12b.pdf byte 12 for the SPD refresh times. Also, do those row address bits in above calculation include bits for the bank selects or is it just the row address bits on the dimm (I guess it's the latter right?) --=20 Regards Abraham None love the bearer of bad news. -- Sophocles __________________________________________________________ Abraham vd Merwe - 2d3D, Inc. Device Driver Development, Outsourcing, Embedded Systems Cell: +27 82 565 4451 Snailmail: Tel: +27 21 761 7549 Block C, Aintree Park Fax: +27 21 761 7648 Doncaster Road Email: ab...@2d... Kenilworth, 7700 Http: http://www.2d3d.com South Africa |
|
From: Russell K. - A. L. <li...@ar...> - 2002-10-14 09:57:06
|
On Mon, Oct 14, 2002 at 11:26:58AM +0200, Abraham vd Merwe wrote: > That's what I gathered. However in the SDRAM SPD (Serial Presence Detect - > the little EEPROM which contains the info about the DIMM) module, the > refresh time goes from 3.9us up to 125us which is orders of magnitude > shorter than all the other refresh times I've seen. 64ms / 4096 = ~15us > So I've thought that the XXms refresh times was for all the rows Correct - you'll find this confirmed by data sheets on the actual SDRAM devices. > and that the SPD specs has it per row, but the explanation above throws > that theory out the door. Do you think > it is possible that the SDRAM dimms can have such short refresh times? No. Or if they do, the refresh starts severely impacting on the performance of the device. > Also, do those row address bits in above calculation include bits for the > bank selects or is it just the row address bits on the dimm (I guess it's > the latter right?) tbh I don't remember off hand. I seem to remember that it doesn't include the bank selects, but please check the data on the SDRAM chips you're using there. |
|
From: Abraham vd M. <ab...@2d...> - 2002-10-14 10:17:03
|
Hi Russell! > > That's what I gathered. However in the SDRAM SPD (Serial Presence Detec= t - > > the little EEPROM which contains the info about the DIMM) module, the > > refresh time goes from 3.9us up to 125us which is orders of magnitude > > shorter than all the other refresh times I've seen. >=20 > 64ms / 4096 =3D ~15us Thanks. That clears it up. One more question. You're currently ignoring the burst access times when configuring MDREFR. Isn't that dangerous? (if you have any bursts, its going to take too long to refresh and then the DRAM contents will corrupt) or am I missing something? Also, the SPD datasheet refers to SDRAM burst lengths of 1, 2, 4, 8 and full page. Is that 1,2,4,8 clocks? What is a full page? Is that across all the rows? Does it need multiple clock cycles to refresh a row (i.e. cas latency * rows =3D=3D longs burst access?) --=20 Regards Abraham * netgod opens his mailbox and immediately wishes he hadnt __________________________________________________________ Abraham vd Merwe - 2d3D, Inc. Device Driver Development, Outsourcing, Embedded Systems Cell: +27 82 565 4451 Snailmail: Tel: +27 21 761 7549 Block C, Aintree Park Fax: +27 21 761 7648 Doncaster Road Email: ab...@2d... Kenilworth, 7700 Http: http://www.2d3d.com South Africa |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X