[U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI

[Christian Didriksson <christian@didritec.com>]

> 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?

> [...]
> 
> --
> Best regards,
> Marek Vasut