[U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes

[Marek Vasut <marex@denx.de>]

On Friday, September 19, 2014 at 01:12:23 PM, Marek Vasut wrote:
> On Friday, September 19, 2014 at 11:44:48 AM, Chin Liang See wrote:
> > Dear Wolfgang,
> > 
> > On Wed, 2014-09-17 at 16:11 +0200, ZY - wd wrote:
> > > Dear Chin Liang See,
> > > 
> > > In message <1410952049.7769.11.camel@clsee-VirtualBox.altera.com> you 
wrote:
> > > > Hmmm... actually I can get it works well for my Altera dev kit. The
> > > > get_dram_size would take in the argument PHYS_SDRAM_1_SIZE. From
> > > > here, the function will ensure the memory specified can read and
> > > > writable. If its failing here, probably the SDRAM access might have
> > > > issue. FYI, PHYS_SDRAM_1_SIZE is 0x40000000 for 1GB.
> > > 
> > > Normally, get_dram_size() would be called with a size argument that is
> > > _larger_ (twice as big) as the biggest possible memory configuration
> > > on the respective device.  Otherwise it can only detect smaller memory
> > > sizes, but would fail to detect if a bigger memory device is
> > > installed by accident.
> > 
> > Yup, you are right. But currently, the memory space after the SDRAM is a
> > bridge to FPGA. We will get data abort when trying to read that area
> > (for a blank FPGA).
> 
> This is good, no ? If you reliably get DABT if the H2F bridge is disabled,
> you can place the trampoline into the DABT vector and detect DRAM size.
> I'll have to test this.

Aw snap, on my hardware, when I access past SDRAM, I am getting a wrap around. 
What's worse is that I can reliably read and write from that location. This
renders get_ram_size() unusable. All right, guys, ideas ?

Best regards,
Marek Vasut