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.ca...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot