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. > > > > > > 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 :) > > > > 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 0x40000000 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 00000000: 00000000 aaaaaaaa aaaaaaaa aaaaaaaa ................ 00000010: aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa ................ 00000020: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU 00000030: 55555555 55555555 55555555 55555555 UUUUUUUUUUUUUUUU 00000040: 7f7b958a a30289de 6bfe35cb 2d3f494f ..{......5.kOI?- 00000050: d5777778 6f010bb3 ec671fe4 27131f7b xww....o..g.{..' 00000060: 2f6ff6e4 bb97cecd 7fff9dda 6ffa1fcd ..o/...........o 00000070: b7375b84 7159d3ae f07ac971 e99bbff6 .[7...Yqq.z..... 00000080: d325d7fd d3b663b8 f377cfea f3675f72 ..%..c....w.r_g. 00000090: 3d1d4cd9 11a59b18 b795fffd 33ba95b8 .L.=...........3 000000a0: 575bbfef 73eb794f 33536eee 104389cf ..[WOy.s.nS3..C. 000000b0: 7763a778 35ff5fd8 f33e57c1 f777fbce x.cw._.5.W>...w. 000000c0: f35b6f9b 5bf70fdb bb730de3 7d7b5f88 .o[....[..s.._{} 000000d0: 5547a7f9 f33f07eb a395364c b35377e8 ..GU..?.L6...wS. 000000e0: 77bf6597 27737ea2 af3577f5 5b34f7d9 .e.w.~s'.w5...4[ 000000f0: 33eadbba fed7df87 3efbfaa8 83b9ef9c ...3.......>.... SOCFPGA_CYCLONE5 # mw 0 12345678 100 SOCFPGA_CYCLONE5 # md 0 00000000: 12345678 12345678 12345678 12345678 xV4.xV4.xV4.xV4. 00000010: 12345678 12345678 12345678 12345678 xV4.xV4.xV4.xV4. 00000020: 12345678 12345678 12345678 12345678 xV4.xV4.xV4.xV4. 00000030: 12345678 12345678 12345678 12345678 xV4.xV4.xV4.xV4. 00000040: 12345678 12345678 12345678 12345678 xV4.xV4.xV4.xV4. 00000050: 12345678 12345678 12345678 12345678 xV4.xV4.xV4.xV4. 00000060: 12345678 12345678 12345678 12345678 xV4.xV4.xV4.xV4. 00000070: 12345678 12345678 12345678 12345678 xV4.xV4.xV4.xV4. 00000080: 12345678 12345678 12345678 12345678 xV4.xV4.xV4.xV4. 00000090: 12345678 12345678 12345678 12345678 xV4.xV4.xV4.xV4. 000000a0: 12345678 12345678 12345678 12345678 xV4.xV4.xV4.xV4. 000000b0: 12345678 12345678 12345678 12345678 xV4.xV4.xV4.xV4. 000000c0: 12345678 12345678 12345678 12345678 xV4.xV4.xV4.xV4. 000000d0: 12345678 12345678 12345678 12345678 xV4.xV4.xV4.xV4. 000000e0: 12345678 12345678 12345678 12345678 xV4.xV4.xV4.xV4. 000000f0: 12345678 12345678 12345678 12345678 xV4.xV4.xV4.xV4. SOCFPGA_CYCLONE5 # md 100000 00100000: eafffffd fbff4b3f fffffffe fdff33be ....?K.......3.. 00100010: ffb2aacf f7779ac4 f73bbf7f f7fbfbfc ......w...;..... 00100020: ffe3bb6d ef9f3fff fdb63bbd f6f76f5d m....?...;..]o.. 00100030: efafbdf1 bbefbdbd efbffcfd fffffffd ................ 00100040: fffbb58f e7baabfc ebfa37cd ed3ff96e .........7..n.?. 00100050: ff7ff7f4 ef1b3ff3 eff71fb6 ffbb0d73 .....?......s... 00100060: efeff6e7 ffb7afeb f7bfbdfb efffffff ................ 00100070: f7fff7ff f7df73ee f1fafff5 ebbbb1e7 .....s.......... 00100080: f3e3dff5 f7eff3ff fb77fd64 fbffdff2 ........d.w..... 00100090: ffbc5cfd f5fbbff8 effffffd f7f8a1fc .\.............. 001000a0: 5b7b3fff f7bb734f fbffffee f3fb8bcf .?{[Os.......... 001000b0: f3b3b75f ffffffda f3bf5fc5 fbffffdb _........_...... 001000c0: f3df6fde dbffffdd fbf1ede7 bd7b7fdc .o............{. 001000d0: f7d7b77f f39f2fef f7933bdc f35337af ...../...;...7S. 001000e0: f7f71ddf e7f77e38 ef7777fd ffb4f2fc ....8~...ww..... 001000f0: f3eafb5e fffffee7 fffbdaec f3f0e5f7 ^............... SOCFPGA_CYCLONE5 # mw 100000 23456789 100 SOCFPGA_CYCLONE5 # md 100000 00100000: 23456789 23456789 23456789 23456789 .gE#.gE#.gE#.gE# 00100010: 23456789 23456789 23456789 23456789 .gE#.gE#.gE#.gE# 00100020: 23456789 23456789 23456789 23456789 .gE#.gE#.gE#.gE# 00100030: 23456789 23456789 23456789 23456789 .gE#.gE#.gE#.gE# 00100040: 23456789 23456789 23456789 23456789 .gE#.gE#.gE#.gE# 00100050: 23456789 23456789 23456789 23456789 .gE#.gE#.gE#.gE# 00100060: 23456789 23456789 23456789 23456789 .gE#.gE#.gE#.gE# 00100070: 23456789 23456789 23456789 23456789 .gE#.gE#.gE#.gE# 00100080: 23456789 23456789 23456789 23456789 .gE#.gE#.gE#.gE# 00100090: 23456789 23456789 23456789 23456789 .gE#.gE#.gE#.gE# 001000a0: 23456789 23456789 23456789 23456789 .gE#.gE#.gE#.gE# 001000b0: 23456789 23456789 23456789 23456789 .gE#.gE#.gE#.gE# 001000c0: 23456789 23456789 23456789 23456789 .gE#.gE#.gE#.gE# 001000d0: 23456789 23456789 23456789 23456789 .gE#.gE#.gE#.gE# 001000e0: 23456789 23456789 23456789 23456789 .gE#.gE#.gE#.gE# 001000f0: 23456789 23456789 23456789 23456789 .gE#.gE#.gE#.gE# 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