[U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI
Christian Didriksson
christian at didritec.com
Tue Jun 21 21:22:24 CEST 2016
> On 06/21/16 17:30, Christian Didriksson wrote:
> > Some more comments inline
> >
> >>
> >>> On 06/20/2016 06:04 PM, Christian Didriksson wrote:
> >>>> Hi,
> >>>
> >>> 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.
> >>>
> >>> That stuff is not active unless you set spi-rx-bus-width = <4>; in
> >>> your flash node in DT. The Cadence QSPI driver in U-Boot does not
> >>> support switching to "parallel spi" (dual/quad) mode yet, even
> >>> though I do have a patch in progress to add that. It does speed things up.
> >>>
> >>
> >> Ok, during my first test of 2016.05 I used menuconfig to configure
> >> some options and I think there might have been some problems there in
> >> combination with the flash DT entry. I reverted back to the original
> >> spi_flash.c now and the SPL still works. Confused...
> >>
> >>>>>>> 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:
> >>>>
> >> [..]
> >>>>
> >>>> So I guess I need to figure out what's missing in the SPL setup of
> SDRAM.
> >>>
> >>> I'd rather look in the cache direction, it's not clear to me how
> >>> this would be related to SDRAM. Even though this is odd either way
> >>> you slice it, it works on Rev C board and not on Rev E , which is weird.
> >>>
> >>
> >> I think Dinh has tested Rev E for the qts updates earlier and it
> >> seems to work for him? The combo Altera 2013.01.01 SPL +
> >> u-boot.2016.05 works for me and that might point in the SPL SDRAM
> >> setup direction. Maybe Altera has replaced the SDRAM devices between
> Rev C and Rev E?
> >>
> >
> > The combo Altera 2013.01.01 + u-boot.2016.05 does not work out of the
> box. I had to add code to exit 4-byte addressing mode for QSPI flash in u-
> boot.2016.05 as Altera's SPL seems to enter 4-byte addressing mode.
> >
> > Further (maybe I should start a new thread?):
> >
> > I have created a UBI volume with a UBIFS from Linux and I can't access it
> from u-boot (no problem to mount in Linux after every reboot).
> >
> > Scenario 1 using SPL.2016.05 + u-boot.2016.05 (NO caches enabled):
> >
> > => mtdparts
> >
> > device nor0 <ff705000.spi.0>, # parts = 9
> > #: name size offset mask_flags
> > 0: spl 0x00040000 0x00000000 0
> > 1: env1 0x00010000 0x00040000 0
> > 2: dtb 0x00010000 0x00050000 0
> > 3: u-boot 0x00080000 0x00060000 0
> > 4: lba 0x00800000 0x000e0000 0
> > 5: lbafs 0x01000000 0x008e0000 0
> > 6: fpga 0x00800000 0x018e0000 0
> > 7: script 0x00020000 0x020e0000 0
> > 8: UBI 0x01f00000 0x02100000 0
> >
> > active partition: nor0,0 - (spl) 0x00040000 @ 0x00000000
> >
> > defaults:
> > mtdids : nor0=ff705000.spi.0
> > mtdparts:
> > mtdparts=ff705000.spi.0:256k(spl),64k(env1),64k(dtb),512k(u-boot),8m(l
> > ba),16m(lbafs),8m(fpga),128k(script),-(UBI)
> > => ubi part UBI
> > ubi0: attaching mtd1
> > data abort
> > pc : [<3ff8a87a>] lr : [<3ff82747>]
> > reloc pc : [<010238ba>] lr : [<0101b787>]
> > sp : 3bf51980 ip : 3ff82123 fp : 3bf57a80
> > r10: 00000040 r9 : 3bf56ef0 r8 : 3bf58280
> > r7 : 00000000 r6 : aaaaaaaa r5 : 00000000 r4 : 00000040
> > r3 : 55555555 r2 : 00000040 r1 : 02100000 r0 : 00000000
> > Flags: nzcv IRQs off FIQs off Mode SVC_32 Resetting CPU ...
> >
> > resetting ...
> >
> > U-Boot SPL 2016.05-ga0bd0e7-dirty (Jun 21 2016 - 09:01:14)
> > 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
> > initcall: 0103b8b5
> > initcall: 01040501
> >
> >
> > U-Boot 2016.05-ga0bd0e7-dirty (Jun 21 2016 - 09:46:44 +0200)
> >
> > Scenario 2 using Altera.2013.01.01 + u-boot.2016.05 (caches enabled):
> >
> > => mtdparts default
> > => mtdparts
> >
> > device nor0 <ff705000.spi.0>, # parts = 9
> > #: name size offset mask_flags
> > 0: spl 0x00040000 0x00000000 0
> > 1: env1 0x00010000 0x00040000 0
> > 2: dtb 0x00010000 0x00050000 0
> > 3: u-boot 0x00080000 0x00060000 0
> > 4: lba 0x00800000 0x000e0000 0
> > 5: lbafs 0x01000000 0x008e0000 0
> > 6: fpga 0x00800000 0x018e0000 0
> > 7: script 0x00020000 0x020e0000 0
> > 8: UBI 0x01f00000 0x02100000 0
> >
> > active partition: nor0,0 - (spl) 0x00040000 @ 0x00000000
> >
> > defaults:
> > mtdids : nor0=ff705000.spi.0
> > mtdparts:
> > mtdparts=ff705000.spi.0:256k(spl),64k(env1),64k(dtb),512k(u-boot),8m(l
> > ba),16m(lbafs),8m(fpga),128k(script),-(UBI)
> > => ubi part UBI
> > ubi0: attaching mtd1
> > dev_get_uclass_priv: null device
> > Cannot set speed (err=-22)
> > dev_get_uclass_priv: null device
> > Cannot set speed (err=-22)
> > dev_get_uclass_priv: null device
> > Cannot set speed (err=-22)
> > dev_get_uclass_priv: null device
> > Cannot set speed (err=-22)
> > UBI init error 22
> > =>
> >
> > I have searched the u-boot mail list and as I understand it this is quite
> recently tested for the QSPI flash?
>
> I've been using QSPI for over a year on QSPI NOR, so that works.
> Check if you have CONFIG_SPI_FLASH_USE_4K_SECTORS not set , UBI
> cannot deal with 4k sectors.
CONFIG_SPI_FLASH_USE_4K_SECTORS is not defined/set
More information about the U-Boot
mailing list