[U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI
Marek Vasut
marex at denx.de
Tue Jun 21 19:07:00 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(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?
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.
More information about the U-Boot
mailing list