On Wednesday, September 17, 2014 at 01:07:29 PM, Chin Liang See wrote:
On Wed, 2014-09-17 at 01:52 +0200, marex@denx.de wrote:
On Wednesday, September 17, 2014 at 12:29:54 AM, Dinh Nguyen wrote:
[...]
Yes, tracked it down to get_ram_size(). I forced gd->ram_size to 1GB and it works fine for me now. I'll try to spend some cycles to debug the problem.
Hmmmmm, how much DRAM can the SoCFPGA chip drive in total ?
All of our devkits have at least 1 GiB and I have heard there is a variant with 2GiB in the wild. Spec says up to 4 GiB.
OK, I see. You cannot realistically map all those 4GiB into the 32-bit address space of an CortexA9, but on the other hand, all those bugs related to an CA9 with 4GiB of DRAM should be fixed due to my work on Novena ;-)
Yup, 4GB would not be possible. Within SocFPGA, by using HPS-FPGA bridges, we can workaround by swapping memory chunk so ARM processor can access entire 4GB. Interested to find out how you did it for Novena :)
Awwwwww, you know this kind of stuff is really so cool about these SoC+FPGA combo designs :)
As for the Novena, MX6 can only address 3.8 GiB, there is a bit of the DRAM which is not available .
Well, consider a theoretical SoCFPGA board with 128MiB of DRAM attached to it, what happens if I try to write at address of the 129th MiB (which is past the DRAM) ? Will this generate an DABT for the ARM core or will some kind of DRAM "mirroring" or "wraparound" happen such that I would write to the content of 1st MiB of the DRAM ?
We've encountered this issue downstream on a system with 1 GiB.
OK, so a wraparound happens ?
It should be a wrap around. It is not working previously as incorrect configuration for one of SDRAM parameters. The fix is under internal review now. :)
All right :)
If I would get DABT, then there is a rather easy fix for that, see arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c and mxs_mem_get_size() function. The function places an assembly return instruction into the DABT handler entry position (offset 0x14 in ARM vector table IIRC) and then runs the get_dram_size() . The assembly instruction only returns from the DABT handler right past the code where the DABT happened. For the get_ram_size(), the read from the unpopulated DRAM space contains zeroes and the function doesn't even realize the DABT happened. But it considers the DRAM invalid and thus this works correctly. That's how it detects the amount of DRAM.
You might want to consider something similar if that's how it behaves on SoCFPGA.
This could be the issue. I think Chin Liang would know about this more than me at this point. So I hope he can solve this quickly.
Sure, patch is welcome!
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.
Aw, fixed locally, thanks!
[...]
Pavel had some strange issue here, but these patches should address that. This one 'arm: socfpga: pl310: Map SDRAM to 0x0' is extremely important .