Re: [U-Boot] RAM burst mode problem
On Thu, Sep 17, 2009 at 5:42 PM, Mikhail Zaturenskiy mzaturenskiy...@gmail.com wrote: We finally solved our DRAM timing problem so I wanted to follow up on my question. On Fri, Sep 4, 2009 at 1:41 AM, Frank Svendsbøe frank.svends...@gmail.com wrote: Hi Mikhail, Burst mode UPM setup is not trivial, and it is quite amount of work to go through your table, so I'm not surprised nobody has replied. I know, I'm not too surprised either :) I assume you've verified the generated waveforms using a logic analyzer/scope, and compared them to the DRAMs datasheet (?). Unfortunately we do not have access to a decent scope nor a logic analyzer, that would certainly have been helpful. If you have access to a Windows machine, you could try an ancient Motorola tool called UPM860. It might be helpful when verifying your UPM program. Did take a look at that, though it did not appear to be as helpful as I hoped. Good luck! - Frank Thanks for your suggestions Frank, They did provide me with some food for thought. What the issue ended up being was us incorrectly setting the amx0/amx1 bits of the Exception RAM word. After we fixed that we also found a nice document from Micron on DRAM timings which had slightly more efficient read/write section values than what we came up with, for those interested here is the link http://download.micron.com/pdf/technotes/TN4812.pdf . Now RAM burst reads/writes are finally working properly :) Mikhail Zaturenskiy I'm impressed! You've solved your burst problem working in blind ;-) Next time, consider buying/renting an analyzer/MSO. It's strange you mentioned this certain Micron datasheet. It was the same document that finally made me understand how address multiplexing works on the 8xx. Far easier to understand than the Freescale ref. manual. Now, consider supporting the community by commiting a patch containing the working UPM table for this SDRAM ;-) - Frank ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RAM burst mode problem
We finally solved our DRAM timing problem so I wanted to follow up on my question. On Fri, Sep 4, 2009 at 1:41 AM, Frank Svendsbøe frank.svends...@gmail.com wrote: Hi Mikhail, Burst mode UPM setup is not trivial, and it is quite amount of work to go through your table, so I'm not surprised nobody has replied. I know, I'm not too surprised either :) I assume you've verified the generated waveforms using a logic analyzer/scope, and compared them to the DRAMs datasheet (?). Unfortunately we do not have access to a decent scope nor a logic analyzer, that would certainly have been helpful. If you have access to a Windows machine, you could try an ancient Motorola tool called UPM860. It might be helpful when verifying your UPM program. Did take a look at that, though it did not appear to be as helpful as I hoped. Good luck! - Frank Thanks for your suggestions Frank, They did provide me with some food for thought. What the issue ended up being was us incorrectly setting the amx0/amx1 bits of the Exception RAM word. After we fixed that we also found a nice document from Micron on DRAM timings which had slightly more efficient read/write section values than what we came up with, for those interested here is the link http://download.micron.com/pdf/technotes/TN4812.pdf . Now RAM burst reads/writes are finally working properly :) Mikhail Zaturenskiy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RAM burst mode problem
Hi Mikhail,
Burst mode UPM setup is not trivial, and it is quite amount of work to
go through your table, so
I'm not surprised nobody has replied.
I assume you've verified the generated waveforms using a logic
analyzer/scope, and compared
them to the DRAMs datasheet (?). If you have access to a Windows
machine, you could try an
ancient Motorola tool called UPM860. It might be helpful when
verifying your UPM program.
Unless someone has experience with this certain DRAM I guess you're on
your own. Or.. you
could try to hire one of the engineers at Denx to do the job for you.
Good luck!
- Frank
On Wed, Sep 2, 2009 at 11:58 PM, Mikhail
Zaturenskiymzaturenskiy...@gmail.com wrote:
Hello, I am working on a board similar to the EP88xC and am having
trouble getting the sdram_table[] setup with the correct values (at
least I think that's the problem).
The board words fine if i burst-inhibit memc_or1 so I know single
read/write works, but if I remove burst-inhibit, it results in a crash
when U-Boot transfers itself from flash to RAM and jumps to the
relocated code.
My board uses the MPC875 processor and MT48LC16M16A2 for the RAM. The
following is my current SDRAM table:
static uint sdram_table[] = {
/* Single read (offset 0x00 in UPM RAM) */
0x0F03C004, 0x0FFFC004, 0x00FCC004, 0x0FFFC000,
0x0FF30004, 0x0FFFC004, 0xC005, 0xC005,
/* Burst read (offset 0x08 in UPM RAM) */
0x0F03C004, 0x0FFFC004, 0x00FCC004, 0x00FFC000,
0x00FFC000, 0x00FFC000, 0x00FFC000, 0x00FFC000,
0x00FFC000, 0x00FFC000, 0x0FF3, 0x0FFFC004,
0xC005, 0xC005, 0xC005, 0xC005,
/* Single write (offset 0x18 in UPM RAM) */
0x0F03C004, 0x0FFFC004, 0x00FC0004, 0x0FFFC002,
0x0FF30004, 0X0FFFC004, 0xC005, 0xC005,
/* Burst write (offset 0x20 in UPM RAM) */
0x0F03C004, 0x0FFFC004, 0x00FC0004, 0X00FFC000,
0x00FFC000, 0x00FFC000, 0x00FFC000, 0X00FFC000,
0x00FFC000, 0x00FFC000, 0x0FF30002, 0x0FFFC004,
0xC005, 0xC005, 0xC005, 0xC005,
/* Refresh (offset 0x30 in UPM RAM) */
0x0FF0C004, 0x0FFFC004, 0x0FFFC004, 0x0FFFC004,
0xC005, 0x0FA30004, 0x0FFFC004, 0x0FF0C084,
0x0FFFC004, 0x0FFFC004, 0x0FFFC004, 0x0FFFC084,
/* Exception (offset 0x3C in UPM RAM) */
0x0FFFC004, 0x0FF4, 0x0FFFC004, 0xC005
};
And the following is my ram init function:
phys_size_t initdram (int board_type)
{
long int msize;
volatile immap_t *immap = (volatile immap_t *)CONFIG_SYS_IMMR;
volatile memctl8xx_t *memctl = immap-im_memctl;
upmconfig(UPMA, sdram_table, sizeof(sdram_table) / sizeof(uint));
/* Configure SDRAM refresh */
memctl-memc_mptpr = MPTPR_PTP_DIV2; /* BRGCLK/2 */
memctl-memc_mamr = (65 24) | CONFIG_SYS_MAMR; /* No refresh */
udelay(100);
/* Run MRS pattern from location 0x35 */ // MZ - was 0x36
memctl-memc_mar = 0x46; // MZ - was 0x88
memctl-memc_mcr = 0x80002235; // MZ - was 0x80002236
udelay(100);
memctl-memc_mamr |= MAMR_PTAE; /* Enable refresh */
memctl-memc_or1 = ~(CONFIG_SYS_SDRAM_MAX_SIZE - 1) | OR_CSNT_SAM;
// memctl-memc_or1 = ~(CONFIG_SYS_SDRAM_MAX_SIZE - 1) | OR_CSNT_SAM
| OR_BI; // MZ - temp, burst inhibit
memctl-memc_br1 = CONFIG_SYS_SDRAM_BASE | BR_PS_16 | BR_MS_UPMA |
BR_V;
msize = get_ram_size(CONFIG_SYS_SDRAM_BASE,
CONFIG_SYS_SDRAM_MAX_SIZE);
memctl-memc_or1 |= ~(msize - 1);
return msize;
}
Also attached is a spreadsheet which illustrates the RAM timing.
Is there something wrong with my RAM table? Am I missing any flags?
Something else wrong?
Any ideas/suggestions are appreciated. Again, sorry for the first
poorly-formatted post.
Thank you,
Mikhail Zaturenskiy
Anyone?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RAM burst mode problem
Dear Mikhail Zaturenskiy,
In message 97dd5fd20908251235ic0e64eela7c75fb138143...@mail.gmail.com you
wrote:
static uint sdram_table[] = { /* Single read (offset 0x00 in UPM RAM) */
0x0F03C004, 0x0FFFC004, 0x00FCC004, 0x0FFFC000, 0x0FF30004, 0x0FFFC004,
0xC005, 0xC005, /* Burst read (offset 0x08 in UPM RAM) */
0x0F03C004, 0x0FFFC004, 0x00FCC004, 0x00FFC000, 0x00FFC000, 0x00FFC000,
0x00FFC000, 0x00FFC000, 0x00FFC000, 0x00FFC000, 0x0FF3, 0x0FFFC004,
0xC005, 0xC005, 0xC005, 0xC005, /* Single write (offset 0x18
in UPM RAM) */ 0x0F03C004, 0x0FFFC004, 0x00FC0004, 0x0FFFC002, 0x0FF30004,
0X0FFFC004, 0xC005, 0xC005, /* Burst write (offset 0x20 in UPM RAM)
*/ 0x0F03C004, 0x0FFFC004, 0x00FC0004, 0X00FFC000, 0x00FFC000, 0x00FFC000,
0x00FFC000, 0X00FFC000, 0x00FFC000, 0x00FFC000, 0x0FF30002, 0x0FFFC004,
0xC005, 0xC005, 0xC005, 0xC005, /* Refresh (offset 0x30 in
UPM RAM) */ 0x0FF0C004, 0x0FFFC004, 0x0FFFC004, 0x0FFFC004, 0xC005,
0x0FA30004, 0x0FFFC004, 0x0FF0C084, 0x0FFFC004, 0x0FFFC004, 0x0FFFC004,
0x0FFFC084, /* Exception (offset 0x3C in UPM RAM) */ 0x0FFFC004, 0x0FF4,
0x0FFFC004, 0xC005 };
Nice formatting.
And the following is my ram init function:
phys_size_t initdram (int board_type) { long int msize; volatile immap_t
*immap = (volatile immap_t *)CONFIG_SYS_IMMR; volatile memctl8xx_t *memctl =
immap-im_memctl; upmconfig(UPMA, sdram_table, sizeof(sdram_table) /
sizeof(uint)); /* Configure SDRAM refresh */ memctl-memc_mptpr =
MPTPR_PTP_DIV2; /* BRGCLK/2 */ memctl-memc_mamr = (65 24) |
CONFIG_SYS_MAMR; /* No refresh */ udelay(100); /* Run MRS pattern from
location 0x35 */ // MZ - was 0x36 memctl-memc_mar = 0x46; // MZ - was 0x88
memctl-memc_mcr = 0x80002235; // MZ - was 0x80002236 udelay(100);
memctl-memc_mamr |= MAMR_PTAE; /* Enable refresh */ memctl-memc_or1 =
~(CONFIG_SYS_SDRAM_MAX_SIZE - 1) | OR_CSNT_SAM; // memctl-memc_or1 =
~(CONFIG_SYS_SDRAM_MAX_SIZE - 1) | OR_CSNT_SAM | OR_BI; // MZ - temp, burst
inhibit memctl-memc_br1 = CONFIG_SYS_SDRAM_BASE | BR_PS_16 | BR_MS_UPMA |
BR_V; msize = get_ram_size(CONFIG_SYS_SDRAM_BASE,
CONFIG_SYS_SDRAM_MAX_SIZE); memctl-memc_or1 |= ~(msize - 1); return msize;
}
That's even better. Do you suppose anybody will bother to read any
code after you formatted it like this?
Note that this is the U-Boot mailing list, not the submission of
entries for the IOCCC.
Also attached is a spreadsheet which illustrates the RAM timing.
Is there something wrong with my RAM table? Am I missing any flags?
Something else wrong?
For one, your style of formatting and posting is terribly wrong.
Please see http://www.catb.org/~esr/faqs/smart-questions.html
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
Like winter snow on summer lawn, time past is time gone.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
