[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 17:30:26 CEST 2016
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(lba),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(lba),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?
> > [...]
> >
> > --
> > Best regards,
> > Marek Vasut
More information about the U-Boot
mailing list