[U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI
Christian Didriksson
christian at didritec.com
Mon Jun 20 18:04:02 CEST 2016
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 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.
>
> 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 at 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 at 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 at 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 at lists.denx.de] För Christian
> >>>>>>> Didriksson
> >>>>>>> Skickat: den 9 juni 2016 20:15
> >>>>>>> Till: u-boot at 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 at lists.denx.de
> >>>>>>> http://lists.denx.de/mailman/listinfo/u-boot
> >>>>>>> _______________________________________________
> >>>>>>> U-Boot mailing list
> >>>>>>> U-Boot at 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
More information about the U-Boot
mailing list