Re: [U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes
Hi Marek, On Wed, 2014-09-17 at 14:39 +0200, ma...@denx.de wrote: On Wednesday, September 17, 2014 at 02:00:42 PM, Chin Liang See wrote: On Wed, 2014-09-17 at 13:52 +0200, ma...@denx.de wrote: On Wednesday, September 17, 2014 at 01:29:15 PM, Chin Liang See wrote: 3. MMC is not enabled in SocFPGA. I recall there is a patch from Pavel. I believe its pending for v2 due to some comments. This should be in the tree in fact. Is CONFIG_CMD_MMC defined ? I didn't see any MMC configuration at include/configs/socfpga_cyclone5 at mainline nor the new patch series. Wonder I might miss out any ACKed patch? Oh I see. I have this enabled in the repository here, but I didn't submit that change since it needs more work. The code is there , added in the patch arm: socfpga: misc: Add SD controller init The change for the SoCFPGA config file is missing though. Yup, I just submit the patch to add that socfpga: Enable DWMMC for SOCFPGA. With this added, the SDMMC is working well at U-Boot. This including all the 35 patches from you. Something to cheer during the weekend :) Here is the printout: SOCFPGA_CYCLONE5 # fatls mmc 0:1 194168 u-boot.img 16289 socfpga.dtb 3202824 zimage 3 file(s), 0 dir(s) SOCFPGA_CYCLONE5 # mmc read 8000 0 1 MMC read: dev # 0, block # 0, count 1 ... 1 blocks read: OK SOCFPGA_CYCLONE5 # md 8000 8000: 8010: 8020: 8030: 8040: 8050: 8060: 8070: 8080: 8090: 80a0: 80b0: 80c0: 80d0: 80e0: 80f0: SOCFPGA_CYCLONE5 # 8100: 8110: 8120: 8130: 8140: 8150: 8160: 8170: 8180: 8190: 81a0: 81b0: 479bf7be 0100...G 81c0: 3c0b0001 003e093e 937e ...~. 81d0: 3c830a01 93bc133e 93bc .. 81e0: 3ca21401 27781d3e 93bc0001 x' 81f0: aa55..U. SOCFPGA_CYCLONE5 # Thanks Chin Liang Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes
Dear Wolfgang, On Wed, 2014-09-17 at 16:11 +0200, ZY - wd wrote: Dear Chin Liang See, In message 1410952049.7769.11.ca...@clsee-virtualbox.altera.com you wrote: 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 0x4000 for 1GB. Normally, get_dram_size() would be called with a size argument that is _larger_ (twice as big) as the biggest possible memory configuration on the respective device. Otherwise it can only detect smaller memory sizes, but would fail to detect if a bigger memory device is installed by accident. Yup, you are right. But currently, the memory space after the SDRAM is a bridge to FPGA. We will get data abort when trying to read that area (for a blank FPGA). I believe Marek's suggestion to work around the DABT and memory detection would work around SOCFPGA memory detection. Its something we would work closely with Marek to enable this auto detection. Thanks Chin Liang Best regards, Wolfgang Denk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes
Hi guys, On Fri, 2014-09-19 at 04:32 -0500, Chin Liang See wrote: Hi Marek, On Wed, 2014-09-17 at 14:39 +0200, ma...@denx.de wrote: On Wednesday, September 17, 2014 at 02:00:42 PM, Chin Liang See wrote: On Wed, 2014-09-17 at 13:52 +0200, ma...@denx.de wrote: On Wednesday, September 17, 2014 at 01:29:15 PM, Chin Liang See wrote: 3. MMC is not enabled in SocFPGA. I recall there is a patch from Pavel. I believe its pending for v2 due to some comments. This should be in the tree in fact. Is CONFIG_CMD_MMC defined ? I didn't see any MMC configuration at include/configs/socfpga_cyclone5 at mainline nor the new patch series. Wonder I might miss out any ACKed patch? Oh I see. I have this enabled in the repository here, but I didn't submit that change since it needs more work. The code is there , added in the patch arm: socfpga: misc: Add SD controller init The change for the SoCFPGA config file is missing though. Yup, I just submit the patch to add that socfpga: Enable DWMMC for SOCFPGA. With this added, the SDMMC is working well at U-Boot. This including all the 35 patches from you. Something to cheer during the weekend :) I just submitted a patch socfpga: Enable SDMMC boot for SOCFPGA U-Boot. This will enable the SDMMC boot as default boot for Altera dev kit. With that, I am able to success boot till Linux 3.10 LTSi successfully :) Thanks Chin Liang U-Boot 2014.10-rc2-00126-g77676b6 (Sep 19 2014 - 05:28:06) CPU: Altera SoCFPGA Platform BOARD: Altera SoCFPGA Cyclone5 Board DRAM: 1 GiB WARNING: Caches not enabled MMC: SOCFPGA DWMMC: 0 Using default environment In:serial Out: serial Err: serial Net: dwmac.ff702000 Error: dwmac.ff702000 address not set. Warning: Your board does not use generic board. Please read doc/README.generic-board and take action. Boards not upgraded by the late 2014 may break or be removed. Hit any key to stop autoboot: 0 reading zImage 3525736 bytes read in 196 ms (17.2 MiB/s) reading socfpga.dtb 19247 bytes read in 8 ms (2.3 MiB/s) Kernel image @ 0x007fc0 [ 0x00 - 0x35cc68 ] ## Flattened Device Tree blob at 0100 Booting using the fdt blob at 0x000100 Loading Device Tree to 0fff7000, end 0fffeb2e ... OK Starting kernel ... Booting Linux on physical CPU 0x0 Initializing cgroup subsys cpuset Linux version 3.10.31-ltsi (jdasilva@sj-interactive3) (gcc version 4.8.3 20140401 (prerelease) (crosstool-NG linaro-1.13.1-4.8-2014.04 - Linaro GCC 4.8-2014.04) ) #1 SMP Wed Sep 17 00:24:24 PDT 2014 CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache Machine: Altera SOCFPGA, model: Altera SOCFPGA Cyclone V Memory policy: ECC disabled, Data cache writealloc PERCPU: Embedded 8 pages/cpu @80f7 s11200 r8192 d13376 u32768 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260096 Kernel command line: console=ttyS0,115200 root=/dev/mmcblk0p2 rw rootwait PID hash table entries: 4096 (order: 2, 16384 bytes) Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1024MB = 1024MB total Memory: 1031884k/1031884k available, 16692k reserved, 0K highmem Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) vmalloc : 0xc080 - 0xff00 (1000 MB) lowmem : 0x8000 - 0xc000 (1024 MB) modules : 0x7f00 - 0x8000 ( 16 MB) .text : 0x80008000 - 0x8068cab0 (6675 kB) .init : 0x8068d000 - 0x806e3bc0 ( 347 kB) .data : 0x806e4000 - 0x807204d0 ( 242 kB) .bss : 0x807204d0 - 0x80761cb4 ( 262 kB) SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 Hierarchical RCU implementation. NR_IRQS:16 nr_irqs:16 16 sched_clock: 32 bits at 100MHz, resolution 10ns, wraps every 42949ms Console: colour dummy device 80x30 Calibrating delay loop... 1836.64 BogoMIPS (lpj=9183232) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok ftrace: allocating 17914 entries in 53 pages CPU0: thread -1, cpu 0, socket 0, mpidr 8000 Setting up static identity map for 0x804d39c8 - 0x804d3a20 CPU1: Booted secondary processor CPU1: thread -1, cpu 1, socket 0, mpidr 8001 Brought up 2 CPUs SMP: Total of 2 processors activated (3679.84 BogoMIPS). CPU: All CPU(s) started in SVC mode. devtmpfs: initialized NET: Registered protocol family 16 fpga bridge driver DMA: preallocated 256 KiB pool for atomic coherent allocations L310 cache controller enabled l2x0: 8 ways, CACHE_ID 0x410030c9, AUX_CTRL 0x3246, Cache size: 524288 B syscon fffef000.l2-cache: regmap [mem 0xfffef000-0xfffe] registered syscon ffd05000.rstmgr: regmap [mem 0xffd05000-0xffd05fff] registered syscon ffc25000.sdrctl: regmap [mem 0xffc25000-0xffc25fff] registered syscon ff80.l3regs:
Re: [U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes
On Friday, September 19, 2014 at 12:36:41 PM, Chin Liang See wrote: Hi guys, On Fri, 2014-09-19 at 04:32 -0500, Chin Liang See wrote: Hi Marek, On Wed, 2014-09-17 at 14:39 +0200, ma...@denx.de wrote: On Wednesday, September 17, 2014 at 02:00:42 PM, Chin Liang See wrote: On Wed, 2014-09-17 at 13:52 +0200, ma...@denx.de wrote: On Wednesday, September 17, 2014 at 01:29:15 PM, Chin Liang See wrote: 3. MMC is not enabled in SocFPGA. I recall there is a patch from Pavel. I believe its pending for v2 due to some comments. This should be in the tree in fact. Is CONFIG_CMD_MMC defined ? I didn't see any MMC configuration at include/configs/socfpga_cyclone5 at mainline nor the new patch series. Wonder I might miss out any ACKed patch? Oh I see. I have this enabled in the repository here, but I didn't submit that change since it needs more work. The code is there , added in the patch arm: socfpga: misc: Add SD controller init The change for the SoCFPGA config file is missing though. Yup, I just submit the patch to add that socfpga: Enable DWMMC for SOCFPGA. With this added, the SDMMC is working well at U-Boot. This including all the 35 patches from you. Something to cheer during the weekend :) I just submitted a patch socfpga: Enable SDMMC boot for SOCFPGA U-Boot. This will enable the SDMMC boot as default boot for Altera dev kit. With that, I am able to success boot till Linux 3.10 LTSi successfully :) We still have a few bugs in the DWMMC driver when using eMMC card, but that's a problem with a particular eMMC card I think. I'll have to look into it. I will pick your patch and re-post the entire bulk today or tomorrow with the suggested changes. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes
On Friday, September 19, 2014 at 11:44:48 AM, Chin Liang See wrote: Dear Wolfgang, On Wed, 2014-09-17 at 16:11 +0200, ZY - wd wrote: Dear Chin Liang See, In message 1410952049.7769.11.ca...@clsee-virtualbox.altera.com you wrote: 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 0x4000 for 1GB. Normally, get_dram_size() would be called with a size argument that is _larger_ (twice as big) as the biggest possible memory configuration on the respective device. Otherwise it can only detect smaller memory sizes, but would fail to detect if a bigger memory device is installed by accident. Yup, you are right. But currently, the memory space after the SDRAM is a bridge to FPGA. We will get data abort when trying to read that area (for a blank FPGA). This is good, no ? If you reliably get DABT if the H2F bridge is disabled, you can place the trampoline into the DABT vector and detect DRAM size. I'll have to test this. I believe Marek's suggestion to work around the DABT and memory detection would work around SOCFPGA memory detection. Its something we would work closely with Marek to enable this auto detection. OK ;-) Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes
On Friday, September 19, 2014 at 01:12:23 PM, Marek Vasut wrote: On Friday, September 19, 2014 at 11:44:48 AM, Chin Liang See wrote: Dear Wolfgang, On Wed, 2014-09-17 at 16:11 +0200, ZY - wd wrote: Dear Chin Liang See, In message 1410952049.7769.11.ca...@clsee-virtualbox.altera.com you wrote: 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 0x4000 for 1GB. Normally, get_dram_size() would be called with a size argument that is _larger_ (twice as big) as the biggest possible memory configuration on the respective device. Otherwise it can only detect smaller memory sizes, but would fail to detect if a bigger memory device is installed by accident. Yup, you are right. But currently, the memory space after the SDRAM is a bridge to FPGA. We will get data abort when trying to read that area (for a blank FPGA). This is good, no ? If you reliably get DABT if the H2F bridge is disabled, you can place the trampoline into the DABT vector and detect DRAM size. I'll have to test this. Aw snap, on my hardware, when I access past SDRAM, I am getting a wrap around. What's worse is that I can reliably read and write from that location. This renders get_ram_size() unusable. All right, guys, ideas ? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes
Hi! What board are doing your testing on? The Arrow Sockit? I have board similar to SocKit, yes. I also see this error print: U-Boot 2014.10-rc2-00139-g70e9e3e-dirty (Sep 16 2014 - 16:26:56) CPU: Altera SoCFPGA Platform BOARD: Altera SoCFPGA Cyclone5 Board Watchdog enabled DRAM: 1 GiB WARNING: Caches not enabled Using default environment In:serial Out: serial Err: serial Net: dwmac.ff702000 Error: dwmac.ff702000 address not set. ^ Do you see this on your side? I can track it down... i2c code that reads address from ROM was not part of the merge, so you need to either set address manually or port it from rocketboards version. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes
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.
Hm, 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 :)
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. :)
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 0x4000 for 1GB.
Seems odd that the get_ram_size is working on your DENX board and not
the devkit.
I _think_ I might have hacked this part up and it's still in the cleanup
pipeline.
It works for me without hacks. I can read and write to the SDRAM memory
well (include 1MB region).
U-Boot 2014.10-rc2-00123-g461be2f-dirty (Sep 17 2014 - 04:28:52)
CPU: Altera SoCFPGA Platform
BOARD: Altera SoCFPGA Cyclone5 Board
DRAM: 1 GiB
WARNING: Caches not enabled
Using default environment
In:serial
Out: serial
Err: serial
Net: dwmac.ff702000
Error: dwmac.ff702000 address not set.
Warning: Your board does not use generic board. Please read
doc/README.generic-board and take action. Boards not
upgraded by the late 2014 may break or be removed.
Hit any key to stop autoboot: 0
Wrong Image Format for bootm command
ERROR: can't get kernel image!
SOCFPGA_CYCLONE5 # md 0
:
0010:
0020:
0030:
0040: 7f7b958a a30289de 6bfe35cb 2d3f494f..{..5.kOI?-
0050: d578 6f010bb3 ec671fe4 27131f7bxwwo..g.{..'
0060: 2f6ff6e4 bb97cecd 7fff9dda 6ffa1fcd..o/...o
0070: b7375b84 7159d3ae f07ac971 e99bbff6.[7...Yqq.z.
0080: d325d7fd d3b663b8 f377cfea f3675f72..%..cw.r_g.
0090: 3d1d4cd9 11a59b18 b795fffd 33ba95b8.L.=...3
00a0: 575bbfef 73eb794f 33536eee 104389cf..[WOy.s.nS3..C.
00b0: 7763a778 35ff5fd8 f33e57c1 f777fbcex.cw._.5.W...w.
00c0: f35b6f9b 5bf70fdb bb730de3 7d7b5f88.o[[..s.._{}
00d0: 5547a7f9 f33f07eb a395364c b35377e8..GU..?.L6...wS.
00e0: 77bf6597 27737ea2 af3577f5 5b34f7d9.e.w.~s'.w5...4[
00f0: 33eadbba fed7df87 3efbfaa8 83b9ef9c...3...
SOCFPGA_CYCLONE5 # mw 0 12345678 100
SOCFPGA_CYCLONE5 # md 0
: 12345678 12345678 12345678 12345678xV4.xV4.xV4.xV4.
0010: 12345678 12345678 12345678 12345678xV4.xV4.xV4.xV4.
0020: 12345678 12345678 12345678 12345678xV4.xV4.xV4.xV4.
Re: [U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes
On Mon, 2014-09-15 at 13:05 +0200, ma...@denx.de 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. Charles Manning (1): tools: socfpga: Add socfpga preloader signing to mkimage Marek Vasut (21): net: dwc: Fix cache alignment issues net: dwc: Make the cache handling less cryptic mmc: dw_mmc: Fix cache alignment issue arm: socfpga: Clean up base address file arm: socfpga: sysmgr: Clean up system manager arm: socfpga: clock: Implant order into bit definitions arm: socfpga: clock: Drop nonsense inlining from clock manager code arm: socfpga: clock: Add missing stubs into board file arm: socfpga: clock: Trim down code duplication arm: socfpga: timer: Pull the timer reload value from config file arm: socfpga: reset: Add EMAC reset functions arm: socfpga: board: Align checkboard() output arm: socfpga: reset: Add function to reset FPGA bridges arm: socfpga: sysmgr: Add FPGA bits into system manager arm: cache: Add support for write-allocate D-Cache arm: socfpga: cache: Define cacheline size arm: socfpga: cache: Enable D-Cache arm: socfpga: cache: Enable PL310 L2 cache arm: socfpga: scu: Add SCU register file arm: socfpga: nic301: Add NIC-301 GPV register file arm: socfpga: pl310: Map SDRAM to 0x0 Pavel Machek (13): net: Remove unused CONFIG_DW_SEARCH_PHY from configs net: phy: Cleanup drivers/net/phy/micrel.c mmc: dw_mmc: cleanups arm: socfpga: Complete the list of base addresses arm: socfpga: Add watchdog disable for socfpga arm: socfpga: clock: Add code to read clock configuration arm: socfpga: mmc: Pick the clock from clock manager arm: socfpga: misc: Add proper ethernet initialization arm: socfpga: misc: Add SD controller init arm: socfpga: misc: Align print_cpuinfo() output arm: socfpga: board: Correctly set ATAG position arm: socfpga: fpga: Add SoCFPGA FPGA programming interface arm: socfpga: nic301: Add NIC-301 configuration code arch/arm/cpu/armv7/socfpga/Makefile| 3 +- arch/arm/cpu/armv7/socfpga/clock_manager.c | 218 - arch/arm/cpu/armv7/socfpga/fpga_manager.c | 354 + arch/arm/cpu/armv7/socfpga/misc.c | 144 - arch/arm/cpu/armv7/socfpga/reset_manager.c | 72 + arch/arm/cpu/armv7/socfpga/system_manager.c| 57 +++- arch/arm/cpu/armv7/socfpga/timer.c | 2 + arch/arm/include/asm/arch-socfpga/clock_manager.h | 209 arch/arm/include/asm/arch-socfpga/fpga_manager.h | 77 + arch/arm/include/asm/arch-socfpga/nic301.h | 195 arch/arm/include/asm/arch-socfpga/reset_manager.h | 6 + arch/arm/include/asm/arch-socfpga/scu.h| 23 ++ .../include/asm/arch-socfpga/socfpga_base_addrs.h | 62 +++- arch/arm/include/asm/arch-socfpga/system_manager.h | 111 +-- arch/arm/include/asm/system.h | 1 + arch/arm/lib/cache-cp15.c | 2 + board/altera/socfpga/pll_config.h | 3 + board/altera/socfpga/socfpga_cyclone5.c| 7 +- common/image.c | 1 + drivers/fpga/altera.c | 21 ++ drivers/mmc/dw_mmc.c | 26 +- drivers/mmc/socfpga_dw_mmc.c | 15 +- drivers/net/designware.c | 46 +-- drivers/net/phy/micrel.c | 7 +- include/altera.h | 1 + include/configs/axs101.h | 1 - include/configs/socfpga_cyclone5.h | 9 +- include/dwmmc.h| 2 +- include/image.h| 1 + tools/Makefile | 1 + tools/imagetool.c | 2 + tools/imagetool.h | 1 + tools/socfpgaimage.c | 255 +++ 33 files changed, 1753 insertions(+), 182 deletions(-) create mode 100644 arch/arm/cpu/armv7/socfpga/fpga_manager.c create mode 100644 arch/arm/include/asm/arch-socfpga/fpga_manager.h create mode 100644 arch/arm/include/asm/arch-socfpga/nic301.h create mode 100644 arch/arm/include/asm/arch-socfpga/scu.h create mode 100644 tools/socfpgaimage.c Cc: Chin Liang See cl...@altera.com Cc: Dinh Nguyen dingu...@altera.com Cc:
Re: [U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes
On Wednesday, September 17, 2014 at 01:29:15 PM, Chin Liang See wrote: [...] A quick test from my side and result as below: 1. SDRAM access is working where I can read and write to few spots. :) SOCFPGA_CYCLONE5 # md 0 : SOCFPGA_CYCLONE5 # mw 0 12345678 100 SOCFPGA_CYCLONE5 # md 0 : 12345678 12345678 12345678 12345678xV4.xV4.xV4.xV4. SOCFPGA_CYCLONE5 # md 10 0010: eafd fbff4b3f fffe fdff33be?K...3.. SOCFPGA_CYCLONE5 # mw 10 23456789 100 SOCFPGA_CYCLONE5 # md 10 0010: 23456789 23456789 23456789 23456789.gE#.gE#.gE#.gE# SOCFPGA_CYCLONE5 # What does that mean? 2. Ethernet seems not working for me. But I will look into this to find out any missing pieces. SOCFPGA_CYCLONE5 # setenv ethaddr 02:11:22:33:44:55 SOCFPGA_CYCLONE5 # dhcp Speed: 1000, full duplex BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 BOOTP broadcast 4 BOOTP broadcast 5 BOOTP broadcast 6 BOOTP broadcast 7 BOOTP broadcast 8 BOOTP broadcast 9 BOOTP broadcast 10 BOOTP broadcast 11 BOOTP broadcast 12 BOOTP broadcast 13 BOOTP broadcast 14 BOOTP broadcast 15 BOOTP broadcast 16 BOOTP broadcast 17 Retry time exceeded; starting again This is on the SoCDK, right ? 3. MMC is not enabled in SocFPGA. I recall there is a patch from Pavel. I believe its pending for v2 due to some comments. This should be in the tree in fact. Is CONFIG_CMD_MMC defined ? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes
On Wed, 2014-09-17 at 13:52 +0200, ma...@denx.de wrote: On Wednesday, September 17, 2014 at 01:29:15 PM, Chin Liang See wrote: [...] A quick test from my side and result as below: 1. SDRAM access is working where I can read and write to few spots. :) SOCFPGA_CYCLONE5 # md 0 : SOCFPGA_CYCLONE5 # mw 0 12345678 100 SOCFPGA_CYCLONE5 # md 0 : 12345678 12345678 12345678 12345678xV4.xV4.xV4.xV4. SOCFPGA_CYCLONE5 # md 10 0010: eafd fbff4b3f fffe fdff33be?K...3.. SOCFPGA_CYCLONE5 # mw 10 23456789 100 SOCFPGA_CYCLONE5 # md 10 0010: 23456789 23456789 23456789 23456789.gE#.gE#.gE#.gE# SOCFPGA_CYCLONE5 # What does that mean? I recall Pavel was having issue when he is accessing 1MB of memory at 0. I believe this is gone as this new patch works well for me. 2. Ethernet seems not working for me. But I will look into this to find out any missing pieces. SOCFPGA_CYCLONE5 # setenv ethaddr 02:11:22:33:44:55 SOCFPGA_CYCLONE5 # dhcp Speed: 1000, full duplex BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 BOOTP broadcast 4 BOOTP broadcast 5 BOOTP broadcast 6 BOOTP broadcast 7 BOOTP broadcast 8 BOOTP broadcast 9 BOOTP broadcast 10 BOOTP broadcast 11 BOOTP broadcast 12 BOOTP broadcast 13 BOOTP broadcast 14 BOOTP broadcast 15 BOOTP broadcast 16 BOOTP broadcast 17 Retry time exceeded; starting again This is on the SoCDK, right ? Yup, Altera SoCDK. 3. MMC is not enabled in SocFPGA. I recall there is a patch from Pavel. I believe its pending for v2 due to some comments. This should be in the tree in fact. Is CONFIG_CMD_MMC defined ? I didn't see any MMC configuration at include/configs/socfpga_cyclone5 at mainline nor the new patch series. Wonder I might miss out any ACKed patch? Thanks Chin Liang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes
On Wednesday, September 17, 2014 at 02:00:42 PM, Chin Liang See wrote: On Wed, 2014-09-17 at 13:52 +0200, ma...@denx.de wrote: On Wednesday, September 17, 2014 at 01:29:15 PM, Chin Liang See wrote: [...] A quick test from my side and result as below: 1. SDRAM access is working where I can read and write to few spots. :) SOCFPGA_CYCLONE5 # md 0 : SOCFPGA_CYCLONE5 # mw 0 12345678 100 SOCFPGA_CYCLONE5 # md 0 : 12345678 12345678 12345678 12345678xV4.xV4.xV4.xV4. SOCFPGA_CYCLONE5 # md 10 0010: eafd fbff4b3f fffe fdff33be?K...3.. SOCFPGA_CYCLONE5 # mw 10 23456789 100 SOCFPGA_CYCLONE5 # md 10 0010: 23456789 23456789 23456789 23456789.gE#.gE#.gE#.gE# SOCFPGA_CYCLONE5 # What does that mean? I recall Pavel was having issue when he is accessing 1MB of memory at 0. I believe this is gone as this new patch works well for me. Yes, the NIC301 patches solve this. Pavel confirmed this yesterday. 2. Ethernet seems not working for me. But I will look into this to find out any missing pieces. SOCFPGA_CYCLONE5 # setenv ethaddr 02:11:22:33:44:55 SOCFPGA_CYCLONE5 # dhcp Speed: 1000, full duplex BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 BOOTP broadcast 4 BOOTP broadcast 5 BOOTP broadcast 6 BOOTP broadcast 7 BOOTP broadcast 8 BOOTP broadcast 9 BOOTP broadcast 10 BOOTP broadcast 11 BOOTP broadcast 12 BOOTP broadcast 13 BOOTP broadcast 14 BOOTP broadcast 15 BOOTP broadcast 16 BOOTP broadcast 17 Retry time exceeded; starting again This is on the SoCDK, right ? Yup, Altera SoCDK. OK 3. MMC is not enabled in SocFPGA. I recall there is a patch from Pavel. I believe its pending for v2 due to some comments. This should be in the tree in fact. Is CONFIG_CMD_MMC defined ? I didn't see any MMC configuration at include/configs/socfpga_cyclone5 at mainline nor the new patch series. Wonder I might miss out any ACKed patch? Oh I see. I have this enabled in the repository here, but I didn't submit that change since it needs more work. The code is there , added in the patch arm: socfpga: misc: Add SD controller init The change for the SoCFPGA config file is missing though. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes
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. Hm, 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 :) Aww, 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 0x4000 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
Re: [U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes
Dear Chin Liang See, In message 1410952049.7769.11.ca...@clsee-virtualbox.altera.com you wrote: 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 0x4000 for 1GB. Normally, get_dram_size() would be called with a size argument that is _larger_ (twice as big) as the biggest possible memory configuration on the respective device. Otherwise it can only detect smaller memory sizes, but would fail to detect if a bigger memory device is installed by accident. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Have you lived in this village all your life?No, not yet. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes
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 -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes
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 was tested a Cyclone5 devkit. Dinh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes
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 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. 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 ? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes
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. 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. 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. Dinh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes
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 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. 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 ? What board are doing your testing on? The Arrow Sockit? I also see this error print: U-Boot 2014.10-rc2-00139-g70e9e3e-dirty (Sep 16 2014 - 16:26:56) CPU: Altera SoCFPGA Platform BOARD: Altera SoCFPGA Cyclone5 Board Watchdog enabled DRAM: 1 GiB WARNING: Caches not enabled Using default environment In:serial Out: serial Err: serial Net: dwmac.ff702000 Error: dwmac.ff702000 address not set. ^ Do you see this on your side? I can track it down... Thanks, Dinh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes
On Tuesday, September 16, 2014 at 11:35:38 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 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. 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 ? What board are doing your testing on? The Arrow Sockit? DENX MCVEVK and I also have the SoCKIT here. Pavel has something funny at home, which I prefer to not know ;-) I also see this error print: U-Boot 2014.10-rc2-00139-g70e9e3e-dirty (Sep 16 2014 - 16:26:56) CPU: Altera SoCFPGA Platform BOARD: Altera SoCFPGA Cyclone5 Board Watchdog enabled DRAM: 1 GiB WARNING: Caches not enabled This needs resolving. The I/D caches are enabled too late so we get this splat. I'll cook a patch for that. Using default environment In:serial Out: serial Err: serial Net: dwmac.ff702000 Error: dwmac.ff702000 address not set. ^ Do you see this on your side? I can track it down... Use = setenv ethaddr 00:ma:ca:dd:re:ss = saveenv It's possibly because the code to read out the MAC from some storage where it usually is is likely defunct. So just set the MAC manually and your ethernet will work. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes
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. Hm, 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! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes
On 09/16/2014 04:46 PM, Marek Vasut wrote: On Tuesday, September 16, 2014 at 11:35:38 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 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. 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 ? What board are doing your testing on? The Arrow Sockit? DENX MCVEVK and I also have the SoCKIT here. Pavel has something funny at home, which I prefer to not know ;-) I also see this error print: U-Boot 2014.10-rc2-00139-g70e9e3e-dirty (Sep 16 2014 - 16:26:56) CPU: Altera SoCFPGA Platform BOARD: Altera SoCFPGA Cyclone5 Board Watchdog enabled DRAM: 1 GiB WARNING: Caches not enabled This needs resolving. The I/D caches are enabled too late so we get this splat. I'll cook a patch for that. Using default environment In:serial Out: serial Err: serial Net: dwmac.ff702000 Error: dwmac.ff702000 address not set. ^ Do you see this on your side? I can track it down... Use = setenv ethaddr 00:ma:ca:dd:re:ss = saveenv ah yes...I added a CONFIG_ETHADDR since saveenv is not enabled yet. Sorry for the noise, I was expecting Warning: failed to set MAC address Dinh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes
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. Hm, 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
Re: [U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes
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. Hm, 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 ;-) 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 ? 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! Seems odd that the get_ram_size is working on your DENX board and not the devkit. I _think_ I might have hacked this part up and it's still in the cleanup pipeline. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes
Dear Marek, In message 201409162355.1.ma...@denx.de you wrote: ... For the get_ram_size(), the read from the unpopulated DRAM space contains zeroes ... nitpick Reading from non-existent memory is not guaranteed to return zeroes, nor any other specific value; in general, the value you read back is undefined. /nitpick Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It is practically impossible to teach good programming style to stu- dents that have had prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration. - Dijkstra ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes
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. Charles Manning (1): tools: socfpga: Add socfpga preloader signing to mkimage Marek Vasut (21): net: dwc: Fix cache alignment issues net: dwc: Make the cache handling less cryptic mmc: dw_mmc: Fix cache alignment issue arm: socfpga: Clean up base address file arm: socfpga: sysmgr: Clean up system manager arm: socfpga: clock: Implant order into bit definitions arm: socfpga: clock: Drop nonsense inlining from clock manager code arm: socfpga: clock: Add missing stubs into board file arm: socfpga: clock: Trim down code duplication arm: socfpga: timer: Pull the timer reload value from config file arm: socfpga: reset: Add EMAC reset functions arm: socfpga: board: Align checkboard() output arm: socfpga: reset: Add function to reset FPGA bridges arm: socfpga: sysmgr: Add FPGA bits into system manager arm: cache: Add support for write-allocate D-Cache arm: socfpga: cache: Define cacheline size arm: socfpga: cache: Enable D-Cache arm: socfpga: cache: Enable PL310 L2 cache arm: socfpga: scu: Add SCU register file arm: socfpga: nic301: Add NIC-301 GPV register file arm: socfpga: pl310: Map SDRAM to 0x0 Pavel Machek (13): net: Remove unused CONFIG_DW_SEARCH_PHY from configs net: phy: Cleanup drivers/net/phy/micrel.c mmc: dw_mmc: cleanups arm: socfpga: Complete the list of base addresses arm: socfpga: Add watchdog disable for socfpga arm: socfpga: clock: Add code to read clock configuration arm: socfpga: mmc: Pick the clock from clock manager arm: socfpga: misc: Add proper ethernet initialization arm: socfpga: misc: Add SD controller init arm: socfpga: misc: Align print_cpuinfo() output arm: socfpga: board: Correctly set ATAG position arm: socfpga: fpga: Add SoCFPGA FPGA programming interface arm: socfpga: nic301: Add NIC-301 configuration code arch/arm/cpu/armv7/socfpga/Makefile| 3 +- arch/arm/cpu/armv7/socfpga/clock_manager.c | 218 - arch/arm/cpu/armv7/socfpga/fpga_manager.c | 354 + arch/arm/cpu/armv7/socfpga/misc.c | 144 - arch/arm/cpu/armv7/socfpga/reset_manager.c | 72 + arch/arm/cpu/armv7/socfpga/system_manager.c| 57 +++- arch/arm/cpu/armv7/socfpga/timer.c | 2 + arch/arm/include/asm/arch-socfpga/clock_manager.h | 209 arch/arm/include/asm/arch-socfpga/fpga_manager.h | 77 + arch/arm/include/asm/arch-socfpga/nic301.h | 195 arch/arm/include/asm/arch-socfpga/reset_manager.h | 6 + arch/arm/include/asm/arch-socfpga/scu.h| 23 ++ .../include/asm/arch-socfpga/socfpga_base_addrs.h | 62 +++- arch/arm/include/asm/arch-socfpga/system_manager.h | 111 +-- arch/arm/include/asm/system.h | 1 + arch/arm/lib/cache-cp15.c | 2 + board/altera/socfpga/pll_config.h | 3 + board/altera/socfpga/socfpga_cyclone5.c| 7 +- common/image.c | 1 + drivers/fpga/altera.c | 21 ++ drivers/mmc/dw_mmc.c | 26 +- drivers/mmc/socfpga_dw_mmc.c | 15 +- drivers/net/designware.c | 46 +-- drivers/net/phy/micrel.c | 7 +- include/altera.h | 1 + include/configs/axs101.h | 1 - include/configs/socfpga_cyclone5.h | 9 +- include/dwmmc.h| 2 +- include/image.h| 1 + tools/Makefile | 1 + tools/imagetool.c | 2 + tools/imagetool.h | 1 + tools/socfpgaimage.c | 255 +++ 33 files changed, 1753 insertions(+), 182 deletions(-) create mode 100644 arch/arm/cpu/armv7/socfpga/fpga_manager.c create mode 100644 arch/arm/include/asm/arch-socfpga/fpga_manager.h create mode 100644 arch/arm/include/asm/arch-socfpga/nic301.h create mode 100644 arch/arm/include/asm/arch-socfpga/scu.h create mode 100644 tools/socfpgaimage.c Cc: Chin Liang See cl...@altera.com Cc: Dinh Nguyen dingu...@altera.com Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Tom Rini tr...@ti.com Cc: Wolfgang Denk w...@denx.de Cc: Pavel Machek pa...@denx.de Cc: Joe Hershberger
