On Wednesday, September 17, 2014 at 01:07:29 PM, Chin Liang See wrote: > On Wed, 2014-09-17 at 01:52 +0200, ma...@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 . _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot