Re: [U-Boot] RAM burst mode problem

2009-09-18 Thread Frank Svendsbøe
On Thu, Sep 17, 2009 at 5:42 PM, Mikhail Zaturenskiy 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 > wrote: >> Hi Mikhail, >> Burst mode UPM setup is not trivial, and it is quite amount of work to

Re: [U-Boot] RAM burst mode problem

2009-09-17 Thread Mikhail Zaturenskiy
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 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 k

Re: [U-Boot] RAM burst mode problem

2009-09-03 Thread Frank Svendsbøe
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 Wi

Re: [U-Boot] RAM burst mode problem

2009-09-02 Thread Mikhail Zaturenskiy
> 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

Re: [U-Boot] RAM burst mode problem

2009-08-25 Thread Wolfgang Denk
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 re