> 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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot