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