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 enabledDRAM: 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 enabledDRAM:
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:
Edit arch/arm/cpu/armv7/socfpga/misc.c
Locate call to get_ram_size()
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 ?
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 ?
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.
btw you don't happen to have a spare CV and AV kits you could send me, so I can do the testing rounds on them too, do you ?
I'll look around.
Thanks!