[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 15:22:48 CEST 2016
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 <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
More information about the U-Boot
mailing list