Hi Marek, > On 06/17/2016 04:39 PM, Christian Didriksson wrote: > > Hi Marek, > > Hi > > > I applied the two patches you suggested, but got no change in behavior: > > > > U-Boot SPL 2016.05-ga0bd0e7-dirty (Jun 17 2016 - 16:32:35) > > drivers/ddr/altera/sequencer.c: Preparing to start memory calibration > > drivers/ddr/altera/sequencer.c: CALIBRATION PASSED > > drivers/ddr/altera/sequencer.c: Calibration complete Trying to boot > > from SPI > > > > > > U-Boot 2016.05-ga0bd0e7-dirty (Jun 17 2016 - 16:32:35 +0200) > > > > CPU: Altera SoCFPGA Platform > > FPGA: Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0 > > BOOT: QSPI Flash (1.8V) > > Watchdog enabled > > I2C: ready > > DRAM: 1 GiB > > But this looks like U-Boot started for you. So maybe I misunderstood > something right from the getgo . The U-Boot starts, but doesn't get past this > point after the DRAM report, right ? >
Correct, initially I had an SPL issue that was solved by not entering quad mode. > In which case, edit lib/initcall.c and add "#define DEBUG" on the first line > of > the file, rebuild u-boot and boot. U-Boot will not produce far more > debugging output and you should be able to figure out which of the initcalls > was the last one that passed (and thus which one got stuck). > > Edit common/board_f.c and locate init_sequence_f[] for the list of initcalls. > Check u-boot.map to get the symbol addresses in the compiled u-boot. Then > compare the output on the console and locate the corresponding initcall > which failed. > > Or share the u-boot (Elf binary) and console output. > > (and please avoid top-posting) > 1 GiB initcall: 0100ca47 initcall: 0100c93d initcall: 0100c9e3 initcall: 0100c9bb initcall: 3ff62c1b initcall: 3ff62add initcall: 0100cc4d (relocated to 3ff62c0d) .text.initr_caches 0x000000000100cc4c 0xa common/built-in.o board_init_r ==> init_sequence_r ==> #ifdef CONFIG_ARM initr_caches, /* Note: For Freescale LS2 SoCs, new MMU table is created in DDR. * A temporary mapping of IFC high region is since removed, * so environmental variables in NOR flash is not availble * until board_init() is called below to remap IFC to high * region. */ #endif So it seems we have the classic SDRAM memory not 100% correct configured causing problems when enabling the caches. But I don't understand why this happens. Dinh can you boot your CV socdk Rev E1 board with 2016.05 SPL? > > Best regards, > > > > Christian > > > >> On 06/16/2016 12:13 PM, Christian Didriksson wrote: > >>> Hi! > >> > >> Hi, > >> > >>>> On 06/15/2016 12:06 PM, Christian Didriksson wrote: > >>>>> Trying again. > >>>> > >>>> Hi! > >>>> > >>>>> I have reverted back to a vanilla u-boot-2016.05, added the > >>>>> not-enter-quad-mode patch > >>>> > >>>> What's this patch ? Can you share it ? > >> > >> [...] > >> > >> Thanks > >> > >>> Some comments: > >>> > >>> We want to run ECC, but I don't think the SPL supports scrubbing > >>> etc. yet so > >> I undefined those qts-parameters. Am I right regarding ECC for SDRAM? > >> > >> I'll delegate this one to Dinh, I never poked into the SRAM ECC stuff. > >> > >>> I couldn't get the SPL to work from the beginning and after much > >> debugging I found that entering quad-mode for the flash is > >> problematic in the SPL. At the same time I also found this, > >> http://lists.denx.de/pipermail/u- boot/2016-June/256671.html, > confirming my findings. > >>> > >>> I have prepared the u-boot MTD-configuration for our setup. > >>> > >>> I have added SPL SPI support and configured ENV-parameters and > >>> u-boot offset > >>> > >>> I have also added the boot command we are going to use. > >> > >> OK > >> > >>>>> and changed the SPI address where the SPL should load the u-boot > >>>>> from > >>>> > >>>> Can you share this change ? > >>>> > >>> > >>> See above > >>> > >>>>> and it does not work. My question: > >>>>> > >>>>> Has anyone else tested SPL/u-boot on an Altera CV socdk Rev E1 > >>>>> board > >>>> recently (like 2016.05)? U-boot hangs after printing memory size. > >>>> Same result using different compilers. > >>>> > >>>> The rev E1 is the latest SoCDK, I only have rev. C1 . I remember > >>>> Dinh > >>>> (CCed) did send a patch for the rev. E board , so I assume he did > >>>> test it, but those were only pinmux changes and it should be part > >>>> of the > >>>> v2016.05: > >>>> > >>>> commit 4baca92001bff3c32a05001a7dc58996623e3ef8 > >>>> Author: Dinh Nguyen <dingu...@kernel.org> > >>>> Date: Tue May 10 15:13:59 2016 -0500 > >>>> > >>>> arm: socfpga: Update iomux and pll for c5 socdk RevE > >>>> > >>>> Another thing which comes to mind is the change in size of SPL, > >>>> that might be worth looking at. Can you check the size of the SPL, > >>>> u-boot-spl- > >> dtb.bin ? > >>>> > >>> > >>> 54534 bytes > >> > >> Try these two patches: > >> https://patchwork.ozlabs.org/patch/627868/ > >> https://patchwork.ozlabs.org/patch/627869/ > >> > >>>> I just tested the rev C socdk with 2016.05 and it boots for me. I > >>>> will send you the binary I used off-list. > >>>> > >>> > >>> Does this SPL (loaded from QSPI by bootrom?) load u-boot from QSPI? > >> > >> I only tested it booting from SD card, but it should just as well > >> load from QSPI if the board is configured that way. > >> > >>>>> Best regards, > >>>>> > >>>>> Christian > >>>>> > >>>>> -----Ursprungligt meddelande----- > >>>>> Från: U-Boot [mailto:u-boot-boun...@lists.denx.de] För Christian > >>>>> Didriksson > >>>>> Skickat: den 9 juni 2016 20:15 > >>>>> Till: u-boot@lists.denx.de > >>>>> Ämne: [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot > >>>>> fail when booting from QSPI > >>>>> > >>>>> Hi All, > >>>>> > >>>>> I have been struggling for quite some time now to get SPL and > >>>>> u-boot to > >>>> run from QSPI-flash. Yesterday I was able to identify a workaround > >>>> to get the SPL going by disabling quad mode for the flash (seems > >>>> identified by > >>>> http://lists.denx.de/pipermail/u-boot/2016-June/256671.html). > >>>> However > >>>> u- boot always hangs after printing memory size. I have tried to > >>>> search the archive and have seen posts about hanging here, but > >>>> nothing I can relate to my setup. I have tested to use Altera's SPL > >> (2013.01.01) and u-boot-2016.5 and this combo seems to work. > >>>>> > >>>>> I also notice that the frequency (max-spi-frequency) in the > >>>>> dts-file is not > >>>> picked up for some reason? > >>>>> > >>>>> Any help to fix the u-boot hang problem would be highly appreciated. > >>>>> > >>>>> Current printout (with added debug output): > >>>>> > >>>>> U-Boot SPL 2016.05 NGA QSPI -g133f59a-dirty (Jun 09 2016 - > >>>>> 17:06:20) > >>>>> drivers/ddr/altera/sequencer.c: Preparing to start memory > >>>>> calibration > >>>>> drivers/ddr/altera/sequencer.c: CALIBRATION PASSED > >>>>> drivers/ddr/altera/sequencer.c: Calibration complete Trying to > >>>>> boot from SPI > >>>>> spl_spi_load_image: bus=0, cs=0, speed=50000000, mode=3 > >>>>> cadence_spi_ofdata_to_platdata: regbase=ff705000 > ahbbase=ffa00000 > >>>>> max-frequency=500000 page-size=256 > >>>>> spi_flash_std_probe: slave=01100368, cs=0 > >>>>> SF: Read data capture delay calibrated to 7 (0 - 15) > >>>>> cadence_spi_set_speed: speed=100000 > >>>>> cadence_spi_xfer: len=1 [bytes] > >>>>> cadence_spi_xfer: len=5 [bytes] > >>>>> SF: Got idcodes > >>>>> 00000000: 20 ba 20 10 00 . .. > >>>>> SF: Detected N25Q512 > >>>>> cadence_spi_xfer: len=1 [bytes] > >>>>> cadence_spi_xfer: len=1 [bytes] > >>>>> spi_flash_decode_fdt: Cannot decode address > >>>>> cadence_spi_xfer: len=0 [bytes] > >>>>> cadence_spi_xfer: len=0 [bytes] > >>>>> SF: Detected N25Q512 with page size 256 Bytes, erase size 64 KiB, > >>>>> total 64 MiB > >>>>> SF: Read data capture delay calibrated to 7 (0 - 15) > >>>>> cadence_spi_set_speed: speed=500000 > >>>>> cadence_spi_xfer: len=5 [bytes] > >>>>> cadence_spi_xfer: len=64 [bytes] > >>>>> cadence_spi_xfer: len=5 [bytes] > >>>>> cadence_spi_xfer: len=443714 [bytes] > >>>>> > >>>>> > >>>>> U-Boot 2016.05 NGA QSPI -g133f59a-dirty (Jun 09 2016 - 17:06:20 > >>>>> +0200) > >>>>> > >>>>> CPU: Altera SoCFPGA Platform > >>>>> FPGA: Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0 > >>>>> BOOT: QSPI Flash (1.8V) > >>>>> Watchdog enabled > >>>>> I2C: ready > >>>>> DRAM: 1 GiB > >>>>> > >>>>> > >>>>> Best regards, > >>>>> > >>>>> Christian > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> U-Boot mailing list > >>>>> U-Boot@lists.denx.de > >>>>> http://lists.denx.de/mailman/listinfo/u-boot > >>>>> _______________________________________________ > >>>>> U-Boot mailing list > >>>>> U-Boot@lists.denx.de > >>>>> http://lists.denx.de/mailman/listinfo/u-boot > >>>>> > >>>> > >>>> > >>>> -- > >>>> Best regards, > >>>> Marek Vasut > >>> > >>> Best regards, > >>> > >>> Christian > >>> > >> > >> > >> -- > >> Best regards, > >> Marek Vasut > > > -- > Best regards, > Marek Vasut Best regards, Christian _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot