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

[Dinh Nguyen <dinguyen@opensource.altera.com>]

On 09/16/2014 04:55 PM, Marek Vasut wrote:
> On Tuesday, September 16, 2014 at 11:29:45 PM, dinguyen wrote:
>> On Tue, 16 Sep 2014, Marek Vasut wrote:
>>> On Tuesday, September 16, 2014 at 06:28:52 PM, Dinh Nguyen wrote:
>>>> On 09/16/2014 08:18 AM, Pavel Machek wrote:
>>>>> Hi!
>>>>>
>>>>> On Mon 2014-09-15 13:05:53, Marek Vasut wrote:
>>>>>> This entire RFC series is the first stab at making SoCFPGA usable
>>>>>> with mainline U-Boot again. There are still some bits missing, but
>>>>>> in general, this allows me to use mainline U-Boot on my SoCFPGA
>>>>>> systems. The big missing part is the SPL generation, which still
>>>>>> needs a lot of additional work.
>>>>>>
>>>>>> This set contains patches for a few subsystems, bu the most part is
>>>>>> the SoCFPGA chip support.
>>>>>>
>>>>>> Most of the patches should be in good shape already, so I wonder if
>>>>>> the RFC tag is really necessary.
>>>>>
>>>>> Just... I earlier today I tested Marek's git tree based on this
>>>>> series, and it works well for me on board similar to sockit.
>>>>>
>>>>> So
>>>>>
>>>>> Tested-by: Pavel Machek <pavel@denx.de>
>>>>>
>>>>> Thanks and best regards,
>>>>>
>>>>> 									
> Pavel
>>>>
>>>> I applied all the patches to v2014.10-rc2, and I see that the watchdog
>>>> has been enabled and it's getting reset:
>>>>
>>>> U-Boot 2014.10-rc2-00139-g70e9e3e (Sep 16 2014 - 11:21:38)
>>>>
>>>> CPU:   Altera SoCFPGA Platform
>>>> BOARD: Altera SoCFPGA Cyclone5 Board
>>>>
>>>>        Watchdog enabled
>>>>
>>>> DRAM:
>>>> U-Boot SPL 2013.01.01-00019-g9cce15f (Jul 18 2013 - 13:05:43)
>>>> SDRAM : Initializing MMR registers
>>>> SDRAM : Calibrating PHY
>>>> SEQ.C: Preparing to start memory calibration
>>>> SEQ.C: CALIBRATION PASSED
>>>> ALTERA DWMMC: 0
>>>> reading u-boot.img
>>>> reading u-boot.img
>>>>
>>>>
>>>> U-Boot 2014.10-rc2-00139-g70e9e3e (Sep 16 2014 - 11:21:38)
>>>>
>>>> CPU:   Altera SoCFPGA Platform
>>>> BOARD: Altera SoCFPGA Cyclone5 Board
>>>>
>>>>        Watchdog enabled
>>>>
>>>> DRAM:
>>> This doesn't seem like a WDT problem. How much DRAM is there on that kit
>>> ? In
>>
>> The devkit has 1GB.
> 
> Ah, thanks for this info!
> 
>>> any case, try this:
>>>
>>> 1) Edit arch/arm/cpu/armv7/socfpga/misc.c
>>> 2) Locate call to get_ram_size()
>>> 3) Replace this function call with the size of your DRAM in bytes.
>>>
>>>    (that is, make it "gd->ram_size = 128 * 1024 * 1024;" if you have
>>>    128MiB)
>>>
>>> I suspect get_ram_size() on socfpga is still broken in mainline and
>>> causes this crash you observe.
>>
>> 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.

> 
> 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.

> 
> 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.

Seems odd that the get_ram_size is working on your DENX board and not
the devkit.

Dinh