Hi,
On 06/20/2016 03:22 PM, Christian Didriksson wrote:
Hi Marek,
Hi,
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.
We don't support quad mode in U-Boot . You mean not entering Quad mode in Linux ?
Nope, there seems to be quad support in u-boot, from spi_flash.c (my patched version):
#ifndef CONFIG_SPL_BUILD /* Look for the fastest read cmd */ cmd = fls(params->e_rd_cmd & spi->mode_rx); if (cmd) { cmd = spi_read_cmds_array[cmd - 1]; flash->read_cmd = cmd; } else { #endif /* Go for default supported read cmd */ flash->read_cmd = CMD_READ_ARRAY_FAST; #ifndef CONFIG_SPL_BUILD }
/* Not require to look for fastest only two write cmds yet */ if (params->flags & WR_QPP && spi->mode & SPI_TX_QUAD) flash->write_cmd = CMD_QUAD_PAGE_PROGRAM; else #endif /* Go for default supported write cmd */ flash->write_cmd = CMD_PAGE_PROGRAM;
/* Set the quad enable bit - only for quad commands */ if ((flash->read_cmd == CMD_READ_QUAD_OUTPUT_FAST) || (flash->read_cmd == CMD_READ_QUAD_IO_FAST) || (flash->write_cmd == CMD_QUAD_PAGE_PROGRAM)) { ret = set_quad_mode(flash, idcode[0]); if (ret) { debug("SF: Fail to set QEB for %02x\n", idcode[0]); return -EINVAL; } }
So there is a call to set_quad_mode that prevented the SPL to work in vanilla 2016.05.
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 sinceremoved,
* so environmental variables in NOR flash is notavailble
* until board_init() is called below to remap IFC tohigh
* region. */#endif
So it seems we have the classic SDRAM memory not 100% correct
configured causing problems when enabling the caches.
I have my doubts about this, but you can try regenerating the preloader headers from latest CV SoCDK GHRD. You'd have to compile the GHRD with Quartus, then generate the preloader files with bsp-editor and then use ./arch/arm/mach-socfpga/qts-filter.sh to process these generated files into headers that go into board/altera/cyclone5-socdk/qts/
I retested with the same result as before. It hangs at the same place.
You can also try defining CONFIG_SYS_ICACHE_OFF and CONFIG_SYS_DCACHE_OFF to disable caches and see where that gets you.
Cache problems confirmed! I disabled the caches:
1 GiB initcall: 0100c70f initcall: 0100c607 initcall: 0100c6ab initcall: 0100c683 initcall: 3ff738e3 initcall: 3ff737a5 initcall: 0100c915 (relocated to 3ff738d5) initcall: 0100c8ed (relocated to 3ff738ad) initcall: 0100c927 (relocated to 3ff738e7) initcall: 0100c8d1 (relocated to 3ff73891) initcall: 0100c91f (relocated to 3ff738df) initcall: 0100c7e1 (relocated to 3ff737a1) initcall: 0100c8bf (relocated to 3ff7387f) initcall: 0100c8b3 (relocated to 3ff73873) initcall: 010011ef (relocated to 3ff681af) initcall: 01001179 (relocated to 3ff68139) initcall: 010387d1 (relocated to 3ff9f791) initcall: 01013521 (relocated to 3ff7a4e1) initcall: 0100c8a9 (relocated to 3ff73869) initcall: 0100c7fd (relocated to 3ff737bd) initcall: 0100c607 (relocated to 3ff735c7) initcall: 0100c607 (relocated to 3ff735c7) initcall: 0100c607 (relocated to 3ff735c7) initcall: 01000d8d (relocated to 3ff67d4d) initcall: 0100c7f9 (relocated to 3ff737b9) initcall: 0100c607 (relocated to 3ff735c7) initcall: 0100c891 (relocated to 3ff73851) MMC: dwmmc0@ff704000: 0 initcall: 0100c849 (relocated to 3ff73809) SF: Detected N25Q512 with page size 256 Bytes, erase size 64 KiB, total 64 MiB initcall: 0100c607 (relocated to 3ff735c7) initcall: 0100c92d (relocated to 3ff738ed) initcall: 0100c607 (relocated to 3ff735c7) initcall: 01013535 (relocated to 3ff7a4f5) initcall: 0100c83f (relocated to 3ff737ff) initcall: 01010b9d (relocated to 3ff77b5d) In: serial Out: serial Err: serial initcall: 0100c94d (relocated to 3ff7390d) Model: Altera SOCFPGA Cyclone V SoC Development Kit initcall: 01000c19 (relocated to 3ff67bd9) initcall: 0100c607 (relocated to 3ff735c7) initcall: 01000851 (relocated to 3ff67811) initcall: 0100c835 (relocated to 3ff737f5) initcall: 0100c81d (relocated to 3ff737dd) initcall: 0100c607 (relocated to 3ff735c7) initcall: 0100c809 (relocated to 3ff737c9) Net: eth0: ethernet@ff702000 initcall: 0100c801 (relocated to 3ff737c1) Hit any key to stop autoboot: 0 =>
So I guess I need to figure out what's missing in the SPL setup of SDRAM.
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 dinguyen@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-bounces@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
-- Best regards, Marek Vasut