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