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

[Marek Vasut]

On Wednesday, September 17, 2014 at 01:07:29 PM, Chin Liang See wrote:
> On Wed, 2014-09-17 at 01:52 +0200, marex at 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 .