* [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI
@ 2016-06-21 15:30 Christian Didriksson
2016-06-21 17:07 ` Marek Vasut
0 siblings, 1 reply; 26+ messages in thread
From: Christian Didriksson @ 2016-06-21 15:30 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI
2016-06-21 15:30 [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI Christian Didriksson
@ 2016-06-21 17:07 ` Marek Vasut
2016-06-21 19:22 ` Christian Didriksson
0 siblings, 1 reply; 26+ messages in thread
From: Marek Vasut @ 2016-06-21 17:07 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI
2016-06-21 17:07 ` Marek Vasut
@ 2016-06-21 19:22 ` Christian Didriksson
2016-06-22 16:37 ` Christian Didriksson
0 siblings, 1 reply; 26+ messages in thread
From: Christian Didriksson @ 2016-06-21 19:22 UTC (permalink / raw)
To: u-boot
> 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
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI
2016-06-21 19:22 ` Christian Didriksson
@ 2016-06-22 16:37 ` Christian Didriksson
2016-06-23 13:07 ` Marek Vasut
0 siblings, 1 reply; 26+ messages in thread
From: Christian Didriksson @ 2016-06-22 16:37 UTC (permalink / raw)
To: u-boot
Hi Marek,
[..]
I skipped booting from QSPI and started all over with a vanilla 2016.05 and built the u-boot-with-spl.sfp. Put it on an SD-card and booted:
U-Boot SPL 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53: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 MMC1
This printout is repeated forever.
I then connected DS5 via the USB-Blaster cable and single stepped through the SPL and after a while, down in mmc_init, I loose connection to the target and when I interrupt it the PC is here:
#ifdef CONFIG_SPL_BUILD
.align 5
undefined_instruction:
software_interrupt:
prefetch_abort:
data_abort:
not_used:
irq:
fiq:
1:
bl 1b /* hang and never return */
#else /* !CONFIG_SPL_BUILD */
I will send you my binary for test on your Rev c board if you can find the time.
I also tested the binary you sent me last week and it behaves identically regarding the printouts and reboot.
Best regards,
Christian
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI
2016-06-22 16:37 ` Christian Didriksson
@ 2016-06-23 13:07 ` Marek Vasut
2016-06-23 15:58 ` Sylvain Lesne
0 siblings, 1 reply; 26+ messages in thread
From: Marek Vasut @ 2016-06-23 13:07 UTC (permalink / raw)
To: u-boot
On 06/22/2016 06:37 PM, Christian Didriksson wrote:
> Hi Marek,
Hi!
> [..]
>
> I skipped booting from QSPI and started all over with a vanilla 2016.05 and built the u-boot-with-spl.sfp. Put it on an SD-card and booted:
>
> U-Boot SPL 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53: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 MMC1
>
> This printout is repeated forever.
>
> I then connected DS5 via the USB-Blaster cable and single stepped through the SPL and after a while, down in mmc_init, I loose connection to the target and when I interrupt it the PC is here:
mmc_init causes data abort ? That is _weird_ .
> #ifdef CONFIG_SPL_BUILD
>
> .align 5
> undefined_instruction:
> software_interrupt:
> prefetch_abort:
> data_abort:
> not_used:
> irq:
> fiq:
>
> 1:
> bl 1b /* hang and never return */
>
> #else /* !CONFIG_SPL_BUILD */
>
> I will send you my binary for test on your Rev c board if you can find the time.
>
> I also tested the binary you sent me last week and it behaves identically regarding the printouts and reboot.
Works on my rev C1:
U-Boot SPL 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53: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 MMC1
U-Boot 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53:14 +0200)
CPU: Altera SoCFPGA Platform
FPGA: Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0
BOOT: SD/MMC External Transceiver (1.8V)
Watchdog enabled
I2C: ready
DRAM: 1 GiB
MMC: dwmmc0 at ff704000: 0
In: serial
Out: serial
Err: serial
Model: Altera SOCFPGA Cyclone V SoC Development Kit
Net: eth0: ethernet at ff702000
Hit any key to stop autoboot: 0
=>
=>
=>
=> ver
U-Boot 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53:14 +0200)
arm-cortexa9_neon-linux-uclibcgnueabihf-gcc (crosstool-NG
crosstool-ng-1.22.0-129-ga41b269) 5.3.0
GNU ld (crosstool-NG crosstool-ng-1.22.0-129-ga41b269) 2.26.20160125
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI
2016-06-23 13:07 ` Marek Vasut
@ 2016-06-23 15:58 ` Sylvain Lesne
2016-06-23 16:14 ` Marek Vasut
0 siblings, 1 reply; 26+ messages in thread
From: Sylvain Lesne @ 2016-06-23 15:58 UTC (permalink / raw)
To: u-boot
Hi Marek, Christian,
On 06/23/2016 03:07 PM, Marek Vasut wrote:
> On 06/22/2016 06:37 PM, Christian Didriksson wrote:
>> Hi Marek,
>
> Hi!
>
>> [..]
>>
>> I skipped booting from QSPI and started all over with a vanilla
2016.05 and built the u-boot-with-spl.sfp. Put it on an SD-card and booted:
>>
>> U-Boot SPL 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53: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 MMC1
>>
>> This printout is repeated forever.
>>
>> I then connected DS5 via the USB-Blaster cable and single stepped
through the SPL and after a while, down in mmc_init, I loose connection
to the target and when I interrupt it the PC is here:
>
> mmc_init causes data abort ? That is _weird_ .
>
>> #ifdef CONFIG_SPL_BUILD
>>
>> .align 5
>> undefined_instruction:
>> software_interrupt:
>> prefetch_abort:
>> data_abort:
>> not_used:
>> irq:
>> fiq:
>>
>> 1:
>> bl 1b /* hang and never return */
>>
>> #else /* !CONFIG_SPL_BUILD */
>>
>> I will send you my binary for test on your Rev c board if you can
find the time.
>>
>> I also tested the binary you sent me last week and it behaves
identically regarding the printouts and reboot.
>
> Works on my rev C1:
>
> U-Boot SPL 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53: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 MMC1
>
>
> U-Boot 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53:14 +0200)
>
> CPU: Altera SoCFPGA Platform
> FPGA: Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0
> BOOT: SD/MMC External Transceiver (1.8V)
> Watchdog enabled
> I2C: ready
> DRAM: 1 GiB
> MMC: dwmmc0 at ff704000: 0
> In: serial
> Out: serial
> Err: serial
> Model: Altera SOCFPGA Cyclone V SoC Development Kit
> Net: eth0: ethernet at ff702000
> Hit any key to stop autoboot: 0
> =>
> =>
> =>
> => ver
>
> U-Boot 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53:14 +0200)
> arm-cortexa9_neon-linux-uclibcgnueabihf-gcc (crosstool-NG
> crosstool-ng-1.22.0-129-ga41b269) 5.3.0
> GNU ld (crosstool-NG crosstool-ng-1.22.0-129-ga41b269) 2.26.20160125
>
>
I think this might be related to something we discussed last month
(starting from [1])!
Am I right to assume that:
- Marek, you have the A2 partition starting at the sector 2048 of the
SD card? (I think that this is the partitioning of the reference
designs)
- Christian, your SD card partitioning is different?
The 2016.05 socfpga SPL loads U-Boot from a fixed offset on the SD
card, and this could explain why you both have a different behavior
if you have different offsets for your partitions!
So, Christian, you could try to move your A2 partition (which
contains u-boot-with-spl.sfp ) to the offset that the SPL expects, ie:
----------8<-------------------8<---------------
$ sudo fdisk -l /dev/sdc
Disk /dev/sdc: 7969 MB, 7969177600 bytes
246 heads, 62 sectors/track, 1020 cylinders, total 15564800 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/sdc1 2000000 3000000 500000+ b W95 FAT32
/dev/sdc2 14000 1999999 993000 83 Linux
/dev/sdc3 2048 4096 1024+ a2 Unknown
Partition table entries are not in disk order
----------8<-------------------8<---------------
Or else, if you'd rather keep your SD layout, Marek accepted a patch
that will be in v2016.07 (I think) to enable loading U-Boot from an
offset starting@the beginning of a partition (the third one by
default): [2]
However, if you want to apply this patch in v2016.05, you should
enable CONFIG_SPL_SYS_MALLOC_SIMPLE, and also apply [3] due to size
constraints.
[1]: http://lists.denx.de/pipermail/u-boot/2016-May/256580.html
[2]:
http://git.denx.de/?p=u-boot.git;a=commit;h=d31e9c575f24f4b7f5f382ccae70d7a86bbc379d
[3]:
http://git.denx.de/?p=u-boot.git;a=commit;h=1254667689a5a4accc149fef6ff69da760001b2b
Hope this helps,
Sylvain
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI
2016-06-23 15:58 ` Sylvain Lesne
@ 2016-06-23 16:14 ` Marek Vasut
2016-06-23 16:31 ` Sylvain Lesne
0 siblings, 1 reply; 26+ messages in thread
From: Marek Vasut @ 2016-06-23 16:14 UTC (permalink / raw)
To: u-boot
On 06/23/2016 05:58 PM, Sylvain Lesne wrote:
> Hi Marek, Christian,
Hi,
> On 06/23/2016 03:07 PM, Marek Vasut wrote:
>> On 06/22/2016 06:37 PM, Christian Didriksson wrote:
>>> Hi Marek,
>>
>> Hi!
>>
>>> [..]
>>>
>>> I skipped booting from QSPI and started all over with a vanilla
> 2016.05 and built the u-boot-with-spl.sfp. Put it on an SD-card and booted:
>>>
>>> U-Boot SPL 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53: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 MMC1
>>>
>>> This printout is repeated forever.
>>>
>>> I then connected DS5 via the USB-Blaster cable and single stepped
> through the SPL and after a while, down in mmc_init, I loose connection
> to the target and when I interrupt it the PC is here:
>>
>> mmc_init causes data abort ? That is _weird_ .
>>
>>> #ifdef CONFIG_SPL_BUILD
>>>
>>> .align 5
>>> undefined_instruction:
>>> software_interrupt:
>>> prefetch_abort:
>>> data_abort:
>>> not_used:
>>> irq:
>>> fiq:
>>>
>>> 1:
>>> bl 1b /* hang and never return */
>>>
>>> #else /* !CONFIG_SPL_BUILD */
>>>
>>> I will send you my binary for test on your Rev c board if you can
> find the time.
>>>
>>> I also tested the binary you sent me last week and it behaves
> identically regarding the printouts and reboot.
>>
>> Works on my rev C1:
>>
>> U-Boot SPL 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53: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 MMC1
>>
>>
>> U-Boot 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53:14 +0200)
>>
>> CPU: Altera SoCFPGA Platform
>> FPGA: Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0
>> BOOT: SD/MMC External Transceiver (1.8V)
>> Watchdog enabled
>> I2C: ready
>> DRAM: 1 GiB
>> MMC: dwmmc0 at ff704000: 0
>> In: serial
>> Out: serial
>> Err: serial
>> Model: Altera SOCFPGA Cyclone V SoC Development Kit
>> Net: eth0: ethernet at ff702000
>> Hit any key to stop autoboot: 0
>> =>
>> =>
>> =>
>> => ver
>>
>> U-Boot 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53:14 +0200)
>> arm-cortexa9_neon-linux-uclibcgnueabihf-gcc (crosstool-NG
>> crosstool-ng-1.22.0-129-ga41b269) 5.3.0
>> GNU ld (crosstool-NG crosstool-ng-1.22.0-129-ga41b269) 2.26.20160125
>>
>>
>
> I think this might be related to something we discussed last month
> (starting from [1])!
>
> Am I right to assume that:
> - Marek, you have the A2 partition starting at the sector 2048 of the
> SD card? (I think that this is the partitioning of the reference
> designs)
> - Christian, your SD card partitioning is different?
>
> The 2016.05 socfpga SPL loads U-Boot from a fixed offset on the SD
> card, and this could explain why you both have a different behavior
> if you have different offsets for your partitions!
Oh right, thanks for reminding me that your patch broke booting of all
SoCFPGA boards which boot from SD card and I had to locally revert it.
I will send a patch which fixes that now. Would you be able to send a
fixed patch ?
> So, Christian, you could try to move your A2 partition (which
> contains u-boot-with-spl.sfp ) to the offset that the SPL expects, ie:
>
> ----------8<-------------------8<---------------
> $ sudo fdisk -l /dev/sdc
>
> Disk /dev/sdc: 7969 MB, 7969177600 bytes
> 246 heads, 62 sectors/track, 1020 cylinders, total 15564800 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0x00000000
>
> Device Boot Start End Blocks Id System
> /dev/sdc1 2000000 3000000 500000+ b W95 FAT32
> /dev/sdc2 14000 1999999 993000 83 Linux
> /dev/sdc3 2048 4096 1024+ a2 Unknown
The A2 partition should be partition 1, please do not use this crippled
layout by placing the bootloader partition at the end of boot media. I
don't know who invented that, but that's a design disaster.
> Partition table entries are not in disk order
> ----------8<-------------------8<---------------
>
> Or else, if you'd rather keep your SD layout, Marek accepted a patch
> that will be in v2016.07 (I think) to enable loading U-Boot from an
> offset starting at the beginning of a partition (the third one by
> default): [2]
I will be reverting that one, sorry.
> However, if you want to apply this patch in v2016.05, you should
> enable CONFIG_SPL_SYS_MALLOC_SIMPLE, and also apply [3] due to size
> constraints.
>
> [1]: http://lists.denx.de/pipermail/u-boot/2016-May/256580.html
> [2]:
> http://git.denx.de/?p=u-boot.git;a=commit;h=d31e9c575f24f4b7f5f382ccae70d7a86bbc379d
> [3]:
> http://git.denx.de/?p=u-boot.git;a=commit;h=1254667689a5a4accc149fef6ff69da760001b2b
>
> Hope this helps,
> Sylvain
>
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI
2016-06-23 16:14 ` Marek Vasut
@ 2016-06-23 16:31 ` Sylvain Lesne
2016-06-23 18:42 ` Marek Vasut
0 siblings, 1 reply; 26+ messages in thread
From: Sylvain Lesne @ 2016-06-23 16:31 UTC (permalink / raw)
To: u-boot
On 06/23/2016 06:14 PM, Marek Vasut wrote:
> On 06/23/2016 05:58 PM, Sylvain Lesne wrote:
>> Hi Marek, Christian,
>
> Hi,
>
>> On 06/23/2016 03:07 PM, Marek Vasut wrote:
>>> On 06/22/2016 06:37 PM, Christian Didriksson wrote:
>>>> Hi Marek,
>>>
>>> Hi!
>>>
>>>> [..]
>>>>
>>>> I skipped booting from QSPI and started all over with a vanilla
>> 2016.05 and built the u-boot-with-spl.sfp. Put it on an SD-card and
booted:
>>>>
>>>> U-Boot SPL 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53: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 MMC1
>>>>
>>>> This printout is repeated forever.
>>>>
>>>> I then connected DS5 via the USB-Blaster cable and single stepped
>> through the SPL and after a while, down in mmc_init, I loose connection
>> to the target and when I interrupt it the PC is here:
>>>
>>> mmc_init causes data abort ? That is _weird_ .
>>>
>>>> #ifdef CONFIG_SPL_BUILD
>>>>
>>>> .align 5
>>>> undefined_instruction:
>>>> software_interrupt:
>>>> prefetch_abort:
>>>> data_abort:
>>>> not_used:
>>>> irq:
>>>> fiq:
>>>>
>>>> 1:
>>>> bl 1b /* hang and never return */
>>>>
>>>> #else /* !CONFIG_SPL_BUILD */
>>>>
>>>> I will send you my binary for test on your Rev c board if you can
>> find the time.
>>>>
>>>> I also tested the binary you sent me last week and it behaves
>> identically regarding the printouts and reboot.
>>>
>>> Works on my rev C1:
>>>
>>> U-Boot SPL 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53: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 MMC1
>>>
>>>
>>> U-Boot 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53:14 +0200)
>>>
>>> CPU: Altera SoCFPGA Platform
>>> FPGA: Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0
>>> BOOT: SD/MMC External Transceiver (1.8V)
>>> Watchdog enabled
>>> I2C: ready
>>> DRAM: 1 GiB
>>> MMC: dwmmc0 at ff704000: 0
>>> In: serial
>>> Out: serial
>>> Err: serial
>>> Model: Altera SOCFPGA Cyclone V SoC Development Kit
>>> Net: eth0: ethernet at ff702000
>>> Hit any key to stop autoboot: 0
>>> =>
>>> =>
>>> =>
>>> => ver
>>>
>>> U-Boot 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53:14 +0200)
>>> arm-cortexa9_neon-linux-uclibcgnueabihf-gcc (crosstool-NG
>>> crosstool-ng-1.22.0-129-ga41b269) 5.3.0
>>> GNU ld (crosstool-NG crosstool-ng-1.22.0-129-ga41b269) 2.26.20160125
>>>
>>>
>>
>> I think this might be related to something we discussed last month
>> (starting from [1])!
>>
>> Am I right to assume that:
>> - Marek, you have the A2 partition starting at the sector 2048 of the
>> SD card? (I think that this is the partitioning of the reference
>> designs)
>> - Christian, your SD card partitioning is different?
>>
>> The 2016.05 socfpga SPL loads U-Boot from a fixed offset on the SD
>> card, and this could explain why you both have a different behavior
>> if you have different offsets for your partitions!
>
> Oh right, thanks for reminding me that your patch broke booting of all
> SoCFPGA boards which boot from SD card and I had to locally revert it.
> I will send a patch which fixes that now. Would you be able to send a
> fixed patch ?
Ack, I'm sorry about that! That was obviously not my goal.
(I see that you just sent a patch to change the partition from 3 to
1, and I agree that this is reasonable)
>
>> So, Christian, you could try to move your A2 partition (which
>> contains u-boot-with-spl.sfp ) to the offset that the SPL expects, ie:
>>
>> ----------8<-------------------8<---------------
>> $ sudo fdisk -l /dev/sdc
>>
>> Disk /dev/sdc: 7969 MB, 7969177600 bytes
>> 246 heads, 62 sectors/track, 1020 cylinders, total 15564800 sectors
>> Units = sectors of 1 * 512 = 512 bytes
>> Sector size (logical/physical): 512 bytes / 512 bytes
>> I/O size (minimum/optimal): 512 bytes / 512 bytes
>> Disk identifier: 0x00000000
>>
>> Device Boot Start End Blocks Id System
>> /dev/sdc1 2000000 3000000 500000+ b W95 FAT32
>> /dev/sdc2 14000 1999999 993000 83 Linux
>> /dev/sdc3 2048 4096 1024+ a2 Unknown
>
> The A2 partition should be partition 1, please do not use this crippled
> layout by placing the bootloader partition at the end of boot media. I
> don't know who invented that, but that's a design disaster.
I don't know either, but the official reference designs from Altera
still use this layout by default! (I agree that this is kind of
backwards)
>
>> Partition table entries are not in disk order
>> ----------8<-------------------8<---------------
>>
>> Or else, if you'd rather keep your SD layout, Marek accepted a patch
>> that will be in v2016.07 (I think) to enable loading U-Boot from an
>> offset starting at the beginning of a partition (the third one by
>> default): [2]
>
> I will be reverting that one, sorry.
Again, I'm sorry for the trouble.
>
>> However, if you want to apply this patch in v2016.05, you should
>> enable CONFIG_SPL_SYS_MALLOC_SIMPLE, and also apply [3] due to size
>> constraints.
>>
>> [1]: http://lists.denx.de/pipermail/u-boot/2016-May/256580.html
>> [2]:
>>
http://git.denx.de/?p=u-boot.git;a=commit;h=d31e9c575f24f4b7f5f382ccae70d7a86bbc379d
>> [3]:
>>
http://git.denx.de/?p=u-boot.git;a=commit;h=1254667689a5a4accc149fef6ff69da760001b2b
>>
>> Hope this helps,
>> Sylvain
>>
>
>
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI
2016-06-23 16:31 ` Sylvain Lesne
@ 2016-06-23 18:42 ` Marek Vasut
2016-06-27 9:10 ` Christian Didriksson
0 siblings, 1 reply; 26+ messages in thread
From: Marek Vasut @ 2016-06-23 18:42 UTC (permalink / raw)
To: u-boot
On 06/23/2016 06:31 PM, Sylvain Lesne wrote:
> On 06/23/2016 06:14 PM, Marek Vasut wrote:
>> On 06/23/2016 05:58 PM, Sylvain Lesne wrote:
>>> Hi Marek, Christian,
>>
>> Hi,
>>
>>> On 06/23/2016 03:07 PM, Marek Vasut wrote:
>>>> On 06/22/2016 06:37 PM, Christian Didriksson wrote:
>>>>> Hi Marek,
>>>>
>>>> Hi!
>>>>
>>>>> [..]
>>>>>
>>>>> I skipped booting from QSPI and started all over with a vanilla
>>> 2016.05 and built the u-boot-with-spl.sfp. Put it on an SD-card and
> booted:
>>>>>
>>>>> U-Boot SPL 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53: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 MMC1
>>>>>
>>>>> This printout is repeated forever.
>>>>>
>>>>> I then connected DS5 via the USB-Blaster cable and single stepped
>>> through the SPL and after a while, down in mmc_init, I loose connection
>>> to the target and when I interrupt it the PC is here:
>>>>
>>>> mmc_init causes data abort ? That is _weird_ .
>>>>
>>>>> #ifdef CONFIG_SPL_BUILD
>>>>>
>>>>> .align 5
>>>>> undefined_instruction:
>>>>> software_interrupt:
>>>>> prefetch_abort:
>>>>> data_abort:
>>>>> not_used:
>>>>> irq:
>>>>> fiq:
>>>>>
>>>>> 1:
>>>>> bl 1b /* hang and never return */
>>>>>
>>>>> #else /* !CONFIG_SPL_BUILD */
>>>>>
>>>>> I will send you my binary for test on your Rev c board if you can
>>> find the time.
>>>>>
>>>>> I also tested the binary you sent me last week and it behaves
>>> identically regarding the printouts and reboot.
>>>>
>>>> Works on my rev C1:
>>>>
>>>> U-Boot SPL 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53: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 MMC1
>>>>
>>>>
>>>> U-Boot 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53:14 +0200)
>>>>
>>>> CPU: Altera SoCFPGA Platform
>>>> FPGA: Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0
>>>> BOOT: SD/MMC External Transceiver (1.8V)
>>>> Watchdog enabled
>>>> I2C: ready
>>>> DRAM: 1 GiB
>>>> MMC: dwmmc0 at ff704000: 0
>>>> In: serial
>>>> Out: serial
>>>> Err: serial
>>>> Model: Altera SOCFPGA Cyclone V SoC Development Kit
>>>> Net: eth0: ethernet at ff702000
>>>> Hit any key to stop autoboot: 0
>>>> =>
>>>> =>
>>>> =>
>>>> => ver
>>>>
>>>> U-Boot 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53:14 +0200)
>>>> arm-cortexa9_neon-linux-uclibcgnueabihf-gcc (crosstool-NG
>>>> crosstool-ng-1.22.0-129-ga41b269) 5.3.0
>>>> GNU ld (crosstool-NG crosstool-ng-1.22.0-129-ga41b269) 2.26.20160125
>>>>
>>>>
>>>
>>> I think this might be related to something we discussed last month
>>> (starting from [1])!
>>>
>>> Am I right to assume that:
>>> - Marek, you have the A2 partition starting at the sector 2048 of the
>>> SD card? (I think that this is the partitioning of the reference
>>> designs)
>>> - Christian, your SD card partitioning is different?
>>>
>>> The 2016.05 socfpga SPL loads U-Boot from a fixed offset on the SD
>>> card, and this could explain why you both have a different behavior
>>> if you have different offsets for your partitions!
>>
>> Oh right, thanks for reminding me that your patch broke booting of all
>> SoCFPGA boards which boot from SD card and I had to locally revert it.
>> I will send a patch which fixes that now. Would you be able to send a
>> fixed patch ?
>
> Ack, I'm sorry about that! That was obviously not my goal.
> (I see that you just sent a patch to change the partition from 3 to
> 1, and I agree that this is reasonable)
>
>>
>>> So, Christian, you could try to move your A2 partition (which
>>> contains u-boot-with-spl.sfp ) to the offset that the SPL expects, ie:
>>>
>>> ----------8<-------------------8<---------------
>>> $ sudo fdisk -l /dev/sdc
>>>
>>> Disk /dev/sdc: 7969 MB, 7969177600 bytes
>>> 246 heads, 62 sectors/track, 1020 cylinders, total 15564800 sectors
>>> Units = sectors of 1 * 512 = 512 bytes
>>> Sector size (logical/physical): 512 bytes / 512 bytes
>>> I/O size (minimum/optimal): 512 bytes / 512 bytes
>>> Disk identifier: 0x00000000
>>>
>>> Device Boot Start End Blocks Id System
>>> /dev/sdc1 2000000 3000000 500000+ b W95 FAT32
>>> /dev/sdc2 14000 1999999 993000 83 Linux
>>> /dev/sdc3 2048 4096 1024+ a2 Unknown
>>
>> The A2 partition should be partition 1, please do not use this crippled
>> layout by placing the bootloader partition at the end of boot media. I
>> don't know who invented that, but that's a design disaster.
>
> I don't know either, but the official reference designs from Altera
> still use this layout by default! (I agree that this is kind of
> backwards)
>
>>
>>> Partition table entries are not in disk order
>>> ----------8<-------------------8<---------------
>>>
>>> Or else, if you'd rather keep your SD layout, Marek accepted a patch
>>> that will be in v2016.07 (I think) to enable loading U-Boot from an
>>> offset starting at the beginning of a partition (the third one by
>>> default): [2]
>>
>> I will be reverting that one, sorry.
>
> Again, I'm sorry for the trouble.
No problem, it's fixed and I hope I managed to nip the problem in the bud.
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI
2016-06-23 18:42 ` Marek Vasut
@ 2016-06-27 9:10 ` Christian Didriksson
2016-06-27 9:38 ` Sylvain Lesne
0 siblings, 1 reply; 26+ messages in thread
From: Christian Didriksson @ 2016-06-27 9:10 UTC (permalink / raw)
To: u-boot
Hi,
> On 06/23/2016 06:31 PM, Sylvain Lesne wrote:
> > On 06/23/2016 06:14 PM, Marek Vasut wrote:
> >> On 06/23/2016 05:58 PM, Sylvain Lesne wrote:
> >>> Hi Marek, Christian,
> >>
> >> Hi,
> >>
> >>> On 06/23/2016 03:07 PM, Marek Vasut wrote:
> >>>> On 06/22/2016 06:37 PM, Christian Didriksson wrote:
> >>>>> Hi Marek,
> >>>>
> >>>> Hi!
> >>>>
> >>>>> [..]
> >>>>>
> >>>>> I skipped booting from QSPI and started all over with a vanilla
> >>> 2016.05 and built the u-boot-with-spl.sfp. Put it on an SD-card and
> > booted:
> >>>>>
> >>>>> U-Boot SPL 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53: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 MMC1
> >>>>>
> >>>>> This printout is repeated forever.
> >>>>>
> >>>>> I then connected DS5 via the USB-Blaster cable and single stepped
> >>> through the SPL and after a while, down in mmc_init, I loose
> >>> connection to the target and when I interrupt it the PC is here:
> >>>>
> >>>> mmc_init causes data abort ? That is _weird_ .
> >>>>
> >>>>> #ifdef CONFIG_SPL_BUILD
> >>>>>
> >>>>> .align 5
> >>>>> undefined_instruction:
> >>>>> software_interrupt:
> >>>>> prefetch_abort:
> >>>>> data_abort:
> >>>>> not_used:
> >>>>> irq:
> >>>>> fiq:
> >>>>>
> >>>>> 1:
> >>>>> bl 1b /*
> hang and never return */
> >>>>>
> >>>>> #else /* !CONFIG_SPL_BUILD */
> >>>>>
> >>>>> I will send you my binary for test on your Rev c board if you can
> >>> find the time.
> >>>>>
> >>>>> I also tested the binary you sent me last week and it behaves
> >>> identically regarding the printouts and reboot.
> >>>>
> >>>> Works on my rev C1:
> >>>>
> >>>> U-Boot SPL 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53: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 MMC1
> >>>>
> >>>>
> >>>> U-Boot 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53:14 +0200)
> >>>>
> >>>> CPU: Altera SoCFPGA Platform
> >>>> FPGA: Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0
> >>>> BOOT: SD/MMC External Transceiver (1.8V)
> >>>> Watchdog enabled
> >>>> I2C: ready
> >>>> DRAM: 1 GiB
> >>>> MMC: dwmmc0 at ff704000: 0
> >>>> In: serial
> >>>> Out: serial
> >>>> Err: serial
> >>>> Model: Altera SOCFPGA Cyclone V SoC Development Kit
> >>>> Net: eth0: ethernet at ff702000
> >>>> Hit any key to stop autoboot: 0
> >>>> =>
> >>>> =>
> >>>> =>
> >>>> => ver
> >>>>
> >>>> U-Boot 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53:14 +0200)
> >>>> arm-cortexa9_neon-linux-uclibcgnueabihf-gcc (crosstool-NG
> >>>> crosstool-ng-1.22.0-129-ga41b269) 5.3.0 GNU ld (crosstool-NG
> >>>> crosstool-ng-1.22.0-129-ga41b269) 2.26.20160125
> >>>>
> >>>>
> >>>
> >>> I think this might be related to something we discussed last month
> >>> (starting from [1])!
> >>>
> >>> Am I right to assume that:
> >>> - Marek, you have the A2 partition starting at the sector 2048 of
> >>> the SD card? (I think that this is the partitioning of the reference
> >>> designs)
> >>> - Christian, your SD card partitioning is different?
> >>>
> >>> The 2016.05 socfpga SPL loads U-Boot from a fixed offset on the SD
> >>> card, and this could explain why you both have a different behavior
> >>> if you have different offsets for your partitions!
> >>
> >> Oh right, thanks for reminding me that your patch broke booting of
> >> all SoCFPGA boards which boot from SD card and I had to locally revert it.
> >> I will send a patch which fixes that now. Would you be able to send a
> >> fixed patch ?
> >
> > Ack, I'm sorry about that! That was obviously not my goal.
> > (I see that you just sent a patch to change the partition from 3 to 1,
> > and I agree that this is reasonable)
> >
> >>
> >>> So, Christian, you could try to move your A2 partition (which
> >>> contains u-boot-with-spl.sfp ) to the offset that the SPL expects, ie:
> >>>
> >>> ----------8<-------------------8<---------------
> >>> $ sudo fdisk -l /dev/sdc
> >>>
> >>> Disk /dev/sdc: 7969 MB, 7969177600 bytes
> >>> 246 heads, 62 sectors/track, 1020 cylinders, total 15564800 sectors
> >>> Units = sectors of 1 * 512 = 512 bytes Sector size
> >>> (logical/physical): 512 bytes / 512 bytes I/O size
> >>> (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
> >>>
> >>> Device Boot Start End Blocks Id System
> >>> /dev/sdc1 2000000 3000000 500000+ b W95 FAT32
> >>> /dev/sdc2 14000 1999999 993000 83 Linux
> >>> /dev/sdc3 2048 4096 1024+ a2 Unknown
> >>
> >> The A2 partition should be partition 1, please do not use this
> >> crippled layout by placing the bootloader partition at the end of
> >> boot media. I don't know who invented that, but that's a design disaster.
> >
> > I don't know either, but the official reference designs from Altera
> > still use this layout by default! (I agree that this is kind of
> > backwards)
> >
> >>
> >>> Partition table entries are not in disk order
> >>> ----------8<-------------------8<---------------
> >>>
> >>> Or else, if you'd rather keep your SD layout, Marek accepted a patch
> >>> that will be in v2016.07 (I think) to enable loading U-Boot from an
> >>> offset starting at the beginning of a partition (the third one by
> >>> default): [2]
> >>
> >> I will be reverting that one, sorry.
> >
> > Again, I'm sorry for the trouble.
>
> No problem, it's fixed and I hope I managed to nip the problem in the bud.
>
I have tried to apply the changes you have suggested, but I end up with the
"undefined reference to 'sprintf' error" when I try to build 2016.05.
>
> --
> Best regards,
> Marek Vasut
Best regards,
Christian
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI
2016-06-27 9:10 ` Christian Didriksson
@ 2016-06-27 9:38 ` Sylvain Lesne
2016-06-27 10:43 ` Christian Didriksson
0 siblings, 1 reply; 26+ messages in thread
From: Sylvain Lesne @ 2016-06-27 9:38 UTC (permalink / raw)
To: u-boot
Hi!
On 06/27/2016 11:10 AM, Christian Didriksson wrote:
> Hi,
>
>> On 06/23/2016 06:31 PM, Sylvain Lesne wrote:
>>> On 06/23/2016 06:14 PM, Marek Vasut wrote:
>>>> On 06/23/2016 05:58 PM, Sylvain Lesne wrote:
>>>>> Hi Marek, Christian,
>>>>
>>>> Hi,
>>>>
>>>>> On 06/23/2016 03:07 PM, Marek Vasut wrote:
>>>>>> On 06/22/2016 06:37 PM, Christian Didriksson wrote:
>>>>>>> Hi Marek,
>>>>>>
>>>>>> Hi!
>>>>>>
>>>>>>> [..]
>>>>>>>
>>>>>>> I skipped booting from QSPI and started all over with a vanilla
>>>>> 2016.05 and built the u-boot-with-spl.sfp. Put it on an SD-card and
>>> booted:
>>>>>>>
>>>>>>> U-Boot SPL 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53: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 MMC1
>>>>>>>
>>>>>>> This printout is repeated forever.
>>>>>>>
>>>>>>> I then connected DS5 via the USB-Blaster cable and single stepped
>>>>> through the SPL and after a while, down in mmc_init, I loose
>>>>> connection to the target and when I interrupt it the PC is here:
>>>>>>
>>>>>> mmc_init causes data abort ? That is _weird_ .
>>>>>>
>>>>>>> #ifdef CONFIG_SPL_BUILD
>>>>>>>
>>>>>>> .align 5
>>>>>>> undefined_instruction:
>>>>>>> software_interrupt:
>>>>>>> prefetch_abort:
>>>>>>> data_abort:
>>>>>>> not_used:
>>>>>>> irq:
>>>>>>> fiq:
>>>>>>>
>>>>>>> 1:
>>>>>>> bl 1b /*
>> hang and never return */
>>>>>>>
>>>>>>> #else /* !CONFIG_SPL_BUILD */
>>>>>>>
>>>>>>> I will send you my binary for test on your Rev c board if you can
>>>>> find the time.
>>>>>>>
>>>>>>> I also tested the binary you sent me last week and it behaves
>>>>> identically regarding the printouts and reboot.
>>>>>>
>>>>>> Works on my rev C1:
>>>>>>
>>>>>> U-Boot SPL 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53: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 MMC1
>>>>>>
>>>>>>
>>>>>> U-Boot 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53:14 +0200)
>>>>>>
>>>>>> CPU: Altera SoCFPGA Platform
>>>>>> FPGA: Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0
>>>>>> BOOT: SD/MMC External Transceiver (1.8V)
>>>>>> Watchdog enabled
>>>>>> I2C: ready
>>>>>> DRAM: 1 GiB
>>>>>> MMC: dwmmc0 at ff704000: 0
>>>>>> In: serial
>>>>>> Out: serial
>>>>>> Err: serial
>>>>>> Model: Altera SOCFPGA Cyclone V SoC Development Kit
>>>>>> Net: eth0: ethernet at ff702000
>>>>>> Hit any key to stop autoboot: 0
>>>>>> =>
>>>>>> =>
>>>>>> =>
>>>>>> => ver
>>>>>>
>>>>>> U-Boot 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53:14 +0200)
>>>>>> arm-cortexa9_neon-linux-uclibcgnueabihf-gcc (crosstool-NG
>>>>>> crosstool-ng-1.22.0-129-ga41b269) 5.3.0 GNU ld (crosstool-NG
>>>>>> crosstool-ng-1.22.0-129-ga41b269) 2.26.20160125
>>>>>>
>>>>>>
>>>>>
>>>>> I think this might be related to something we discussed last month
>>>>> (starting from [1])!
>>>>>
>>>>> Am I right to assume that:
>>>>> - Marek, you have the A2 partition starting at the sector 2048 of
>>>>> the SD card? (I think that this is the partitioning of the reference
>>>>> designs)
>>>>> - Christian, your SD card partitioning is different?
>>>>>
>>>>> The 2016.05 socfpga SPL loads U-Boot from a fixed offset on the SD
>>>>> card, and this could explain why you both have a different behavior
>>>>> if you have different offsets for your partitions!
>>>>
>>>> Oh right, thanks for reminding me that your patch broke booting of
>>>> all SoCFPGA boards which boot from SD card and I had to locally revert it.
>>>> I will send a patch which fixes that now. Would you be able to send a
>>>> fixed patch ?
>>>
>>> Ack, I'm sorry about that! That was obviously not my goal.
>>> (I see that you just sent a patch to change the partition from 3 to 1,
>>> and I agree that this is reasonable)
>>>
>>>>
>>>>> So, Christian, you could try to move your A2 partition (which
>>>>> contains u-boot-with-spl.sfp ) to the offset that the SPL expects, ie:
>>>>>
>>>>> ----------8<-------------------8<---------------
>>>>> $ sudo fdisk -l /dev/sdc
>>>>>
>>>>> Disk /dev/sdc: 7969 MB, 7969177600 bytes
>>>>> 246 heads, 62 sectors/track, 1020 cylinders, total 15564800 sectors
>>>>> Units = sectors of 1 * 512 = 512 bytes Sector size
>>>>> (logical/physical): 512 bytes / 512 bytes I/O size
>>>>> (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
>>>>>
>>>>> Device Boot Start End Blocks Id System
>>>>> /dev/sdc1 2000000 3000000 500000+ b W95 FAT32
>>>>> /dev/sdc2 14000 1999999 993000 83 Linux
>>>>> /dev/sdc3 2048 4096 1024+ a2 Unknown
>>>>
>>>> The A2 partition should be partition 1, please do not use this
>>>> crippled layout by placing the bootloader partition at the end of
>>>> boot media. I don't know who invented that, but that's a design disaster.
>>>
>>> I don't know either, but the official reference designs from Altera
>>> still use this layout by default! (I agree that this is kind of
>>> backwards)
>>>
>>>>
>>>>> Partition table entries are not in disk order
>>>>> ----------8<-------------------8<---------------
>>>>>
>>>>> Or else, if you'd rather keep your SD layout, Marek accepted a patch
>>>>> that will be in v2016.07 (I think) to enable loading U-Boot from an
>>>>> offset starting at the beginning of a partition (the third one by
>>>>> default): [2]
>>>>
>>>> I will be reverting that one, sorry.
>>>
>>> Again, I'm sorry for the trouble.
>>
>> No problem, it's fixed and I hope I managed to nip the problem in the bud.
>>
> I have tried to apply the changes you have suggested, but I end up with the
> "undefined reference to 'sprintf' error" when I try to build 2016.05.
Did you also enable CONFIG_USE_TINY_PRINTF? If yes, please try to apply
the following commits as well:
http://git.denx.de/?p=u-boot.git;a=commit;h=5c411d88be8df5f6a8a1ea0c961f7c35ba82c064
http://git.denx.de/?p=u-boot.git;a=commit;h=abeb272d22217481c214495818c3ceabad57b9c0
http://git.denx.de/?p=u-boot.git;a=commit;h=3191d8408053674c1b9bb79a82e3973add48830c
Best regards,
Sylvain
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI
2016-06-27 9:38 ` Sylvain Lesne
@ 2016-06-27 10:43 ` Christian Didriksson
0 siblings, 0 replies; 26+ messages in thread
From: Christian Didriksson @ 2016-06-27 10:43 UTC (permalink / raw)
To: u-boot
Hi!
>
> Hi!
>
> On 06/27/2016 11:10 AM, Christian Didriksson wrote:
> > Hi,
> >
> >> On 06/23/2016 06:31 PM, Sylvain Lesne wrote:
> >>> On 06/23/2016 06:14 PM, Marek Vasut wrote:
> >>>> On 06/23/2016 05:58 PM, Sylvain Lesne wrote:
> >>>>> Hi Marek, Christian,
> >>>>
> >>>> Hi,
> >>>>
> >>>>> On 06/23/2016 03:07 PM, Marek Vasut wrote:
> >>>>>> On 06/22/2016 06:37 PM, Christian Didriksson wrote:
> >>>>>>> Hi Marek,
> >>>>>>
> >>>>>> Hi!
> >>>>>>
> >>>>>>> [..]
> >>>>>>>
> >>>>>>> I skipped booting from QSPI and started all over with a vanilla
> >>>>> 2016.05 and built the u-boot-with-spl.sfp. Put it on an SD-card
> >>>>> and
> >>> booted:
> >>>>>>>
> >>>>>>> U-Boot SPL 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53: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 MMC1
> >>>>>>>
> >>>>>>> This printout is repeated forever.
> >>>>>>>
> >>>>>>> I then connected DS5 via the USB-Blaster cable and single
> >>>>>>> stepped
> >>>>> through the SPL and after a while, down in mmc_init, I loose
> >>>>> connection to the target and when I interrupt it the PC is here:
> >>>>>>
> >>>>>> mmc_init causes data abort ? That is _weird_ .
> >>>>>>
> >>>>>>> #ifdef CONFIG_SPL_BUILD
> >>>>>>>
> >>>>>>> .align 5
> >>>>>>> undefined_instruction:
> >>>>>>> software_interrupt:
> >>>>>>> prefetch_abort:
> >>>>>>> data_abort:
> >>>>>>> not_used:
> >>>>>>> irq:
> >>>>>>> fiq:
> >>>>>>>
> >>>>>>> 1:
> >>>>>>> bl 1b /*
> >> hang and never return */
> >>>>>>>
> >>>>>>> #else /* !CONFIG_SPL_BUILD */
> >>>>>>>
> >>>>>>> I will send you my binary for test on your Rev c board if you
> >>>>>>> can
> >>>>> find the time.
> >>>>>>>
> >>>>>>> I also tested the binary you sent me last week and it behaves
> >>>>> identically regarding the printouts and reboot.
> >>>>>>
> >>>>>> Works on my rev C1:
> >>>>>>
> >>>>>> U-Boot SPL 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53: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 MMC1
> >>>>>>
> >>>>>>
> >>>>>> U-Boot 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53:14 +0200)
> >>>>>>
> >>>>>> CPU: Altera SoCFPGA Platform
> >>>>>> FPGA: Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0
> >>>>>> BOOT: SD/MMC External Transceiver (1.8V)
> >>>>>> Watchdog enabled
> >>>>>> I2C: ready
> >>>>>> DRAM: 1 GiB
> >>>>>> MMC: dwmmc0 at ff704000: 0
> >>>>>> In: serial
> >>>>>> Out: serial
> >>>>>> Err: serial
> >>>>>> Model: Altera SOCFPGA Cyclone V SoC Development Kit
> >>>>>> Net: eth0: ethernet at ff702000
> >>>>>> Hit any key to stop autoboot: 0
> >>>>>> =>
> >>>>>> =>
> >>>>>> =>
> >>>>>> => ver
> >>>>>>
> >>>>>> U-Boot 2016.05-gbb88b7b-dirty (Jun 22 2016 - 14:53:14 +0200)
> >>>>>> arm-cortexa9_neon-linux-uclibcgnueabihf-gcc (crosstool-NG
> >>>>>> crosstool-ng-1.22.0-129-ga41b269) 5.3.0 GNU ld (crosstool-NG
> >>>>>> crosstool-ng-1.22.0-129-ga41b269) 2.26.20160125
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> I think this might be related to something we discussed last month
> >>>>> (starting from [1])!
> >>>>>
> >>>>> Am I right to assume that:
> >>>>> - Marek, you have the A2 partition starting at the sector 2048 of
> >>>>> the SD card? (I think that this is the partitioning of the
> >>>>> reference
> >>>>> designs)
> >>>>> - Christian, your SD card partitioning is different?
> >>>>>
> >>>>> The 2016.05 socfpga SPL loads U-Boot from a fixed offset on the SD
> >>>>> card, and this could explain why you both have a different
> >>>>> behavior if you have different offsets for your partitions!
> >>>>
> >>>> Oh right, thanks for reminding me that your patch broke booting of
> >>>> all SoCFPGA boards which boot from SD card and I had to locally revert
> it.
> >>>> I will send a patch which fixes that now. Would you be able to send
> >>>> a fixed patch ?
> >>>
> >>> Ack, I'm sorry about that! That was obviously not my goal.
> >>> (I see that you just sent a patch to change the partition from 3 to
> >>> 1, and I agree that this is reasonable)
> >>>
> >>>>
> >>>>> So, Christian, you could try to move your A2 partition (which
> >>>>> contains u-boot-with-spl.sfp ) to the offset that the SPL expects, ie:
> >>>>>
> >>>>> ----------8<-------------------8<---------------
> >>>>> $ sudo fdisk -l /dev/sdc
> >>>>>
> >>>>> Disk /dev/sdc: 7969 MB, 7969177600 bytes
> >>>>> 246 heads, 62 sectors/track, 1020 cylinders, total 15564800
> >>>>> sectors Units = sectors of 1 * 512 = 512 bytes Sector size
> >>>>> (logical/physical): 512 bytes / 512 bytes I/O size
> >>>>> (minimum/optimal): 512 bytes / 512 bytes Disk identifier:
> >>>>> 0x00000000
> >>>>>
> >>>>> Device Boot Start End Blocks Id System
> >>>>> /dev/sdc1 2000000 3000000 500000+ b W95 FAT32
> >>>>> /dev/sdc2 14000 1999999 993000 83 Linux
> >>>>> /dev/sdc3 2048 4096 1024+ a2 Unknown
> >>>>
> >>>> The A2 partition should be partition 1, please do not use this
> >>>> crippled layout by placing the bootloader partition at the end of
> >>>> boot media. I don't know who invented that, but that's a design
> disaster.
> >>>
I changed the sdcard:
-----------------8<-----------------8<----------------
Disk /dev/sda: 3966 MB, 3966763008 bytes
123 heads, 62 sectors/track, 1015 cylinders, total 7747584 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xb93adff2
Device Boot Start End Blocks Id System
/dev/sda1 2048 22528 10240+ a2 Unknown
/dev/sda2 22529 124929 51200+ 83 Linux
/dev/sda3 124930 227330 51200+ b W95 FAT32
-----------------8<-----------------8<----------------
> >>> I don't know either, but the official reference designs from Altera
> >>> still use this layout by default! (I agree that this is kind of
> >>> backwards)
> >>>
> >>>>
> >>>>> Partition table entries are not in disk order
> >>>>> ----------8<-------------------8<---------------
> >>>>>
> >>>>> Or else, if you'd rather keep your SD layout, Marek accepted a
> >>>>> patch that will be in v2016.07 (I think) to enable loading U-Boot
> >>>>> from an offset starting at the beginning of a partition (the third
> >>>>> one by
> >>>>> default): [2]
> >>>>
> >>>> I will be reverting that one, sorry.
> >>>
> >>> Again, I'm sorry for the trouble.
> >>
> >> No problem, it's fixed and I hope I managed to nip the problem in the
> bud.
> >>
> > I have tried to apply the changes you have suggested, but I end up
> > with the "undefined reference to 'sprintf' error" when I try to build
> 2016.05.
>
> Did you also enable CONFIG_USE_TINY_PRINTF? If yes, please try to apply
> the following commits as well:
>
> http://git.denx.de/?p=u-
> boot.git;a=commit;h=5c411d88be8df5f6a8a1ea0c961f7c35ba82c064
> http://git.denx.de/?p=u-
> boot.git;a=commit;h=abeb272d22217481c214495818c3ceabad57b9c0
> http://git.denx.de/?p=u-
> boot.git;a=commit;h=3191d8408053674c1b9bb79a82e3973add48830c
>
I used tiny-printf.c from the latest snapshot, which solved the link-problem.
Now I have a working SPL that loads the u-boot image, but there are still
some Rev E problems with the u-boot I guess. Coming out of a power-on-reset
(> 20s power off) u-boot gets stuck after 1GB printout. This is most likely
due to enabling the caches (investigation of last week). However, I found
a new behavior today. If I left it hanging at the 1GB printout the board re-
booted after a while (watchdog?) and now it managed to start u-boot:
-----------------8<-----------------8<----------------
U-Boot SPL 2016.05-gbb88b7b-dirty (Jun 27 2016 - 11:49:30)
drivers/ddr/altera/sequencer.c: Preparing to start memory calibration
drivers/ddr/altera/sequencer.c: CALIBRATION PASSED
drivers/ddr/altera/sequencer.c: Calibration complete
>>spl:board_init_r()
spl_init()
Trying to boot from MMC1
spl: payload image: *s load addr: 0x4 size: 16777248
Jumping to U-Boot
SPL malloc() used lx bytes (d KB)
loaded - jumping to U-Boot...image entry point: 0x
U-Boot 2016.05-gbb88b7b-dirty (Jun 27 2016 - 11:49:30 +0200)
CPU: Altera SoCFPGA Platform
FPGA: Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0
BOOT: SD/MMC External Transceiver (1.8V)
Watchdog enabled
I2C: ready
DRAM: 1 GiB
U-Boot SPL 2016.05-gbb88b7b-dirty (Jun 27 2016 - 11:49:30)
drivers/ddr/altera/sequencer.c: Preparing to start memory calibration
drivers/ddr/altera/sequencer.c: CALIBRATION PASSED
drivers/ddr/altera/sequencer.c: Calibration complete
>>spl:board_init_r()
spl_init()
Trying to boot from MMC1
spl: payload image: *s load addr: 0x4 size: 16777248
Jumping to U-Boot
SPL malloc() used lx bytes (d KB)
loaded - jumping to U-Boot...image entry point: 0x
U-Boot 2016.05-gbb88b7b-dirty (Jun 27 2016 - 11:49:30 +0200)
CPU: Altera SoCFPGA Platform
FPGA: Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0
BOOT: SD/MMC External Transceiver (1.8V)
Watchdog enabled
I2C: ready
DRAM: 1 GiB
MMC: dwmmc0 at ff704000: 0
SF: Detected N25Q512 with page size 256 Bytes, erase size 64 KiB, total 64 MiB
In: serial
Out: serial
Err: serial
Model: Altera SOCFPGA Cyclone V SoC Development Kit
Net: eth0: ethernet at ff702000
Hit any key to stop autoboot: 0
=>
-----------------8<-----------------8<----------------
> Best regards,
> Sylvain
Best regards,
Christian
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI
2016-06-20 16:04 ` Christian Didriksson
2016-06-20 20:22 ` Marek Vasut
@ 2016-06-29 7:03 ` Pavel Machek
1 sibling, 0 replies; 26+ messages in thread
From: Pavel Machek @ 2016-06-29 7:03 UTC (permalink / raw)
To: u-boot
Hi!
> > 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.
Just for the record, I seen similar problems on is1 board, and they
also somehow magically went away.
One possibility was that SPL was too big, and the quad spi probing
pushed it over the limits.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI
2016-06-20 20:22 ` Marek Vasut
@ 2016-06-21 7:32 ` Christian Didriksson
0 siblings, 0 replies; 26+ messages in thread
From: Christian Didriksson @ 2016-06-21 7:32 UTC (permalink / raw)
To: u-boot
> 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
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI
2016-06-20 16:04 ` Christian Didriksson
@ 2016-06-20 20:22 ` Marek Vasut
2016-06-21 7:32 ` Christian Didriksson
2016-06-29 7:03 ` Pavel Machek
1 sibling, 1 reply; 26+ messages in thread
From: Marek Vasut @ 2016-06-20 20:22 UTC (permalink / raw)
To: u-boot
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.
>>>> 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:
>
> 1 GiB
> initcall: 0100c70f
> initcall: 0100c607
> initcall: 0100c6ab
> initcall: 0100c683
> initcall: 3ff738e3
> initcall: 3ff737a5
> initcall: 0100c915 (relocated to 3ff738d5)
> initcall: 0100c8ed (relocated to 3ff738ad)
> initcall: 0100c927 (relocated to 3ff738e7)
> initcall: 0100c8d1 (relocated to 3ff73891)
> initcall: 0100c91f (relocated to 3ff738df)
> initcall: 0100c7e1 (relocated to 3ff737a1)
> initcall: 0100c8bf (relocated to 3ff7387f)
> initcall: 0100c8b3 (relocated to 3ff73873)
> initcall: 010011ef (relocated to 3ff681af)
> initcall: 01001179 (relocated to 3ff68139)
> initcall: 010387d1 (relocated to 3ff9f791)
> initcall: 01013521 (relocated to 3ff7a4e1)
> initcall: 0100c8a9 (relocated to 3ff73869)
> initcall: 0100c7fd (relocated to 3ff737bd)
> initcall: 0100c607 (relocated to 3ff735c7)
> initcall: 0100c607 (relocated to 3ff735c7)
> initcall: 0100c607 (relocated to 3ff735c7)
> initcall: 01000d8d (relocated to 3ff67d4d)
> initcall: 0100c7f9 (relocated to 3ff737b9)
> initcall: 0100c607 (relocated to 3ff735c7)
> initcall: 0100c891 (relocated to 3ff73851)
> MMC: dwmmc0 at ff704000: 0
> initcall: 0100c849 (relocated to 3ff73809)
> SF: Detected N25Q512 with page size 256 Bytes, erase size 64 KiB, total 64 MiB
> initcall: 0100c607 (relocated to 3ff735c7)
> initcall: 0100c92d (relocated to 3ff738ed)
> initcall: 0100c607 (relocated to 3ff735c7)
> initcall: 01013535 (relocated to 3ff7a4f5)
> initcall: 0100c83f (relocated to 3ff737ff)
> initcall: 01010b9d (relocated to 3ff77b5d)
> In: serial
> Out: serial
> Err: serial
> initcall: 0100c94d (relocated to 3ff7390d)
> Model: Altera SOCFPGA Cyclone V SoC Development Kit
> initcall: 01000c19 (relocated to 3ff67bd9)
> initcall: 0100c607 (relocated to 3ff735c7)
> initcall: 01000851 (relocated to 3ff67811)
> initcall: 0100c835 (relocated to 3ff737f5)
> initcall: 0100c81d (relocated to 3ff737dd)
> initcall: 0100c607 (relocated to 3ff735c7)
> initcall: 0100c809 (relocated to 3ff737c9)
> Net: eth0: ethernet at ff702000
> initcall: 0100c801 (relocated to 3ff737c1)
> Hit any key to stop autoboot: 0
> =>
>
> 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.
[...]
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI
2016-06-20 13:43 ` Marek Vasut
@ 2016-06-20 16:04 ` Christian Didriksson
2016-06-20 20:22 ` Marek Vasut
2016-06-29 7:03 ` Pavel Machek
0 siblings, 2 replies; 26+ messages in thread
From: Christian Didriksson @ 2016-06-20 16:04 UTC (permalink / raw)
To: u-boot
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.
> >> 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:
1 GiB
initcall: 0100c70f
initcall: 0100c607
initcall: 0100c6ab
initcall: 0100c683
initcall: 3ff738e3
initcall: 3ff737a5
initcall: 0100c915 (relocated to 3ff738d5)
initcall: 0100c8ed (relocated to 3ff738ad)
initcall: 0100c927 (relocated to 3ff738e7)
initcall: 0100c8d1 (relocated to 3ff73891)
initcall: 0100c91f (relocated to 3ff738df)
initcall: 0100c7e1 (relocated to 3ff737a1)
initcall: 0100c8bf (relocated to 3ff7387f)
initcall: 0100c8b3 (relocated to 3ff73873)
initcall: 010011ef (relocated to 3ff681af)
initcall: 01001179 (relocated to 3ff68139)
initcall: 010387d1 (relocated to 3ff9f791)
initcall: 01013521 (relocated to 3ff7a4e1)
initcall: 0100c8a9 (relocated to 3ff73869)
initcall: 0100c7fd (relocated to 3ff737bd)
initcall: 0100c607 (relocated to 3ff735c7)
initcall: 0100c607 (relocated to 3ff735c7)
initcall: 0100c607 (relocated to 3ff735c7)
initcall: 01000d8d (relocated to 3ff67d4d)
initcall: 0100c7f9 (relocated to 3ff737b9)
initcall: 0100c607 (relocated to 3ff735c7)
initcall: 0100c891 (relocated to 3ff73851)
MMC: dwmmc0 at ff704000: 0
initcall: 0100c849 (relocated to 3ff73809)
SF: Detected N25Q512 with page size 256 Bytes, erase size 64 KiB, total 64 MiB
initcall: 0100c607 (relocated to 3ff735c7)
initcall: 0100c92d (relocated to 3ff738ed)
initcall: 0100c607 (relocated to 3ff735c7)
initcall: 01013535 (relocated to 3ff7a4f5)
initcall: 0100c83f (relocated to 3ff737ff)
initcall: 01010b9d (relocated to 3ff77b5d)
In: serial
Out: serial
Err: serial
initcall: 0100c94d (relocated to 3ff7390d)
Model: Altera SOCFPGA Cyclone V SoC Development Kit
initcall: 01000c19 (relocated to 3ff67bd9)
initcall: 0100c607 (relocated to 3ff735c7)
initcall: 01000851 (relocated to 3ff67811)
initcall: 0100c835 (relocated to 3ff737f5)
initcall: 0100c81d (relocated to 3ff737dd)
initcall: 0100c607 (relocated to 3ff735c7)
initcall: 0100c809 (relocated to 3ff737c9)
Net: eth0: ethernet at ff702000
initcall: 0100c801 (relocated to 3ff737c1)
Hit any key to stop autoboot: 0
=>
So I guess I need to figure out what's missing in the SPL setup of SDRAM.
> > But I don't understand why this happens. Dinh can you boot your CV socdk
> Rev E1 board with 2016.05 SPL?
> >
> >>> Best regards,
> >>>
> >>> Christian
> >>>
> >>>> On 06/16/2016 12:13 PM, Christian Didriksson wrote:
> >>>>> Hi!
> >>>>
> >>>> Hi,
> >>>>
> >>>>>> On 06/15/2016 12:06 PM, Christian Didriksson wrote:
> >>>>>>> Trying again.
> >>>>>>
> >>>>>> Hi!
> >>>>>>
> >>>>>>> I have reverted back to a vanilla u-boot-2016.05, added the
> >>>>>>> not-enter-quad-mode patch
> >>>>>>
> >>>>>> What's this patch ? Can you share it ?
> >>>>
> >>>> [...]
> >>>>
> >>>> Thanks
> >>>>
> >>>>> Some comments:
> >>>>>
> >>>>> We want to run ECC, but I don't think the SPL supports scrubbing
> >>>>> etc. yet so
> >>>> I undefined those qts-parameters. Am I right regarding ECC for
> SDRAM?
> >>>>
> >>>> I'll delegate this one to Dinh, I never poked into the SRAM ECC stuff.
> >>>>
> >>>>> I couldn't get the SPL to work from the beginning and after much
> >>>> debugging I found that entering quad-mode for the flash is
> >>>> problematic in the SPL. At the same time I also found this,
> >>>> http://lists.denx.de/pipermail/u- boot/2016-June/256671.html,
> >> confirming my findings.
> >>>>>
> >>>>> I have prepared the u-boot MTD-configuration for our setup.
> >>>>>
> >>>>> I have added SPL SPI support and configured ENV-parameters and
> >>>>> u-boot offset
> >>>>>
> >>>>> I have also added the boot command we are going to use.
> >>>>
> >>>> OK
> >>>>
> >>>>>>> and changed the SPI address where the SPL should load the u-boot
> >>>>>>> from
> >>>>>>
> >>>>>> Can you share this change ?
> >>>>>>
> >>>>>
> >>>>> See above
> >>>>>
> >>>>>>> and it does not work. My question:
> >>>>>>>
> >>>>>>> Has anyone else tested SPL/u-boot on an Altera CV socdk Rev E1
> >>>>>>> board
> >>>>>> recently (like 2016.05)? U-boot hangs after printing memory size.
> >>>>>> Same result using different compilers.
> >>>>>>
> >>>>>> The rev E1 is the latest SoCDK, I only have rev. C1 . I remember
> >>>>>> Dinh
> >>>>>> (CCed) did send a patch for the rev. E board , so I assume he did
> >>>>>> test it, but those were only pinmux changes and it should be part
> >>>>>> of the
> >>>>>> v2016.05:
> >>>>>>
> >>>>>> commit 4baca92001bff3c32a05001a7dc58996623e3ef8
> >>>>>> Author: Dinh Nguyen <dinguyen@kernel.org>
> >>>>>> Date: Tue May 10 15:13:59 2016 -0500
> >>>>>>
> >>>>>> arm: socfpga: Update iomux and pll for c5 socdk RevE
> >>>>>>
> >>>>>> Another thing which comes to mind is the change in size of SPL,
> >>>>>> that might be worth looking at. Can you check the size of the
> >>>>>> SPL,
> >>>>>> u-boot-spl-
> >>>> dtb.bin ?
> >>>>>>
> >>>>>
> >>>>> 54534 bytes
> >>>>
> >>>> Try these two patches:
> >>>> https://patchwork.ozlabs.org/patch/627868/
> >>>> https://patchwork.ozlabs.org/patch/627869/
> >>>>
> >>>>>> I just tested the rev C socdk with 2016.05 and it boots for me. I
> >>>>>> will send you the binary I used off-list.
> >>>>>>
> >>>>>
> >>>>> Does this SPL (loaded from QSPI by bootrom?) load u-boot from
> QSPI?
> >>>>
> >>>> I only tested it booting from SD card, but it should just as well
> >>>> load from QSPI if the board is configured that way.
> >>>>
> >>>>>>> Best regards,
> >>>>>>>
> >>>>>>> Christian
> >>>>>>>
> >>>>>>> -----Ursprungligt meddelande-----
> >>>>>>> Fr?n: U-Boot [mailto:u-boot-bounces at lists.denx.de] F?r Christian
> >>>>>>> Didriksson
> >>>>>>> Skickat: den 9 juni 2016 20:15
> >>>>>>> Till: u-boot at lists.denx.de
> >>>>>>> ?mne: [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot
> >>>>>>> fail when booting from QSPI
> >>>>>>>
> >>>>>>> Hi All,
> >>>>>>>
> >>>>>>> I have been struggling for quite some time now to get SPL and
> >>>>>>> u-boot to
> >>>>>> run from QSPI-flash. Yesterday I was able to identify a
> >>>>>> workaround to get the SPL going by disabling quad mode for the
> >>>>>> flash (seems identified by
> >>>>>> http://lists.denx.de/pipermail/u-boot/2016-June/256671.html).
> >>>>>> However
> >>>>>> u- boot always hangs after printing memory size. I have tried to
> >>>>>> search the archive and have seen posts about hanging here, but
> >>>>>> nothing I can relate to my setup. I have tested to use Altera's
> >>>>>> SPL
> >>>> (2013.01.01) and u-boot-2016.5 and this combo seems to work.
> >>>>>>>
> >>>>>>> I also notice that the frequency (max-spi-frequency) in the
> >>>>>>> dts-file is not
> >>>>>> picked up for some reason?
> >>>>>>>
> >>>>>>> Any help to fix the u-boot hang problem would be highly
> appreciated.
> >>>>>>>
> >>>>>>> Current printout (with added debug output):
> >>>>>>>
> >>>>>>> U-Boot SPL 2016.05 NGA QSPI -g133f59a-dirty (Jun 09 2016 -
> >>>>>>> 17:06:20)
> >>>>>>> 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
> >>>>>>> spl_spi_load_image: bus=0, cs=0, speed=50000000, mode=3
> >>>>>>> cadence_spi_ofdata_to_platdata: regbase=ff705000
> >> ahbbase=ffa00000
> >>>>>>> max-frequency=500000 page-size=256
> >>>>>>> spi_flash_std_probe: slave=01100368, cs=0
> >>>>>>> SF: Read data capture delay calibrated to 7 (0 - 15)
> >>>>>>> cadence_spi_set_speed: speed=100000
> >>>>>>> cadence_spi_xfer: len=1 [bytes]
> >>>>>>> cadence_spi_xfer: len=5 [bytes]
> >>>>>>> SF: Got idcodes
> >>>>>>> 00000000: 20 ba 20 10 00 . ..
> >>>>>>> SF: Detected N25Q512
> >>>>>>> cadence_spi_xfer: len=1 [bytes]
> >>>>>>> cadence_spi_xfer: len=1 [bytes]
> >>>>>>> spi_flash_decode_fdt: Cannot decode address
> >>>>>>> cadence_spi_xfer: len=0 [bytes]
> >>>>>>> cadence_spi_xfer: len=0 [bytes]
> >>>>>>> SF: Detected N25Q512 with page size 256 Bytes, erase size 64
> >>>>>>> KiB, total 64 MiB
> >>>>>>> SF: Read data capture delay calibrated to 7 (0 - 15)
> >>>>>>> cadence_spi_set_speed: speed=500000
> >>>>>>> cadence_spi_xfer: len=5 [bytes]
> >>>>>>> cadence_spi_xfer: len=64 [bytes]
> >>>>>>> cadence_spi_xfer: len=5 [bytes]
> >>>>>>> cadence_spi_xfer: len=443714 [bytes]
> >>>>>>>
> >>>>>>>
> >>>>>>> U-Boot 2016.05 NGA QSPI -g133f59a-dirty (Jun 09 2016 - 17:06:20
> >>>>>>> +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
> >>>>>>>
> >>>>>>>
> >>>>>>> Best regards,
> >>>>>>>
> >>>>>>> Christian
> >>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> U-Boot mailing list
> >>>>>>> U-Boot at lists.denx.de
> >>>>>>> http://lists.denx.de/mailman/listinfo/u-boot
> >>>>>>> _______________________________________________
> >>>>>>> U-Boot mailing list
> >>>>>>> U-Boot at lists.denx.de
> >>>>>>> http://lists.denx.de/mailman/listinfo/u-boot
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Best regards,
> >>>>>> Marek Vasut
> >>>>>
> >>>>> Best regards,
> >>>>>
> >>>>> Christian
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Best regards,
> >>>> Marek Vasut
> >>
> >>
> >> --
> >> Best regards,
> >> Marek Vasut
> >
> > Best regards,
> > Christian
> >
>
>
> --
> Best regards,
> Marek Vasut
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI
2016-06-20 13:22 ` Christian Didriksson
@ 2016-06-20 13:43 ` Marek Vasut
2016-06-20 16:04 ` Christian Didriksson
0 siblings, 1 reply; 26+ messages in thread
From: Marek Vasut @ 2016-06-20 13:43 UTC (permalink / raw)
To: u-boot
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 ?
>> 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/
You can also try defining CONFIG_SYS_ICACHE_OFF and
CONFIG_SYS_DCACHE_OFF to disable caches and see where that gets you.
> But I don't understand why this happens. Dinh can you boot your CV socdk Rev E1 board with 2016.05 SPL?
>
>>> Best regards,
>>>
>>> Christian
>>>
>>>> On 06/16/2016 12:13 PM, Christian Didriksson wrote:
>>>>> Hi!
>>>>
>>>> Hi,
>>>>
>>>>>> On 06/15/2016 12:06 PM, Christian Didriksson wrote:
>>>>>>> Trying again.
>>>>>>
>>>>>> Hi!
>>>>>>
>>>>>>> I have reverted back to a vanilla u-boot-2016.05, added the
>>>>>>> not-enter-quad-mode patch
>>>>>>
>>>>>> What's this patch ? Can you share it ?
>>>>
>>>> [...]
>>>>
>>>> Thanks
>>>>
>>>>> Some comments:
>>>>>
>>>>> We want to run ECC, but I don't think the SPL supports scrubbing
>>>>> etc. yet so
>>>> I undefined those qts-parameters. Am I right regarding ECC for SDRAM?
>>>>
>>>> I'll delegate this one to Dinh, I never poked into the SRAM ECC stuff.
>>>>
>>>>> I couldn't get the SPL to work from the beginning and after much
>>>> debugging I found that entering quad-mode for the flash is
>>>> problematic in the SPL. At the same time I also found this,
>>>> http://lists.denx.de/pipermail/u- boot/2016-June/256671.html,
>> confirming my findings.
>>>>>
>>>>> I have prepared the u-boot MTD-configuration for our setup.
>>>>>
>>>>> I have added SPL SPI support and configured ENV-parameters and
>>>>> u-boot offset
>>>>>
>>>>> I have also added the boot command we are going to use.
>>>>
>>>> OK
>>>>
>>>>>>> and changed the SPI address where the SPL should load the u-boot
>>>>>>> from
>>>>>>
>>>>>> Can you share this change ?
>>>>>>
>>>>>
>>>>> See above
>>>>>
>>>>>>> and it does not work. My question:
>>>>>>>
>>>>>>> Has anyone else tested SPL/u-boot on an Altera CV socdk Rev E1
>>>>>>> board
>>>>>> recently (like 2016.05)? U-boot hangs after printing memory size.
>>>>>> Same result using different compilers.
>>>>>>
>>>>>> The rev E1 is the latest SoCDK, I only have rev. C1 . I remember
>>>>>> Dinh
>>>>>> (CCed) did send a patch for the rev. E board , so I assume he did
>>>>>> test it, but those were only pinmux changes and it should be part
>>>>>> of the
>>>>>> v2016.05:
>>>>>>
>>>>>> commit 4baca92001bff3c32a05001a7dc58996623e3ef8
>>>>>> Author: Dinh Nguyen <dinguyen@kernel.org>
>>>>>> Date: Tue May 10 15:13:59 2016 -0500
>>>>>>
>>>>>> arm: socfpga: Update iomux and pll for c5 socdk RevE
>>>>>>
>>>>>> Another thing which comes to mind is the change in size of SPL,
>>>>>> that might be worth looking at. Can you check the size of the SPL,
>>>>>> u-boot-spl-
>>>> dtb.bin ?
>>>>>>
>>>>>
>>>>> 54534 bytes
>>>>
>>>> Try these two patches:
>>>> https://patchwork.ozlabs.org/patch/627868/
>>>> https://patchwork.ozlabs.org/patch/627869/
>>>>
>>>>>> I just tested the rev C socdk with 2016.05 and it boots for me. I
>>>>>> will send you the binary I used off-list.
>>>>>>
>>>>>
>>>>> Does this SPL (loaded from QSPI by bootrom?) load u-boot from QSPI?
>>>>
>>>> I only tested it booting from SD card, but it should just as well
>>>> load from QSPI if the board is configured that way.
>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>> Christian
>>>>>>>
>>>>>>> -----Ursprungligt meddelande-----
>>>>>>> Fr?n: U-Boot [mailto:u-boot-bounces at lists.denx.de] F?r Christian
>>>>>>> Didriksson
>>>>>>> Skickat: den 9 juni 2016 20:15
>>>>>>> Till: u-boot at lists.denx.de
>>>>>>> ?mne: [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot
>>>>>>> fail when booting from QSPI
>>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> I have been struggling for quite some time now to get SPL and
>>>>>>> u-boot to
>>>>>> run from QSPI-flash. Yesterday I was able to identify a workaround
>>>>>> to get the SPL going by disabling quad mode for the flash (seems
>>>>>> identified by
>>>>>> http://lists.denx.de/pipermail/u-boot/2016-June/256671.html).
>>>>>> However
>>>>>> u- boot always hangs after printing memory size. I have tried to
>>>>>> search the archive and have seen posts about hanging here, but
>>>>>> nothing I can relate to my setup. I have tested to use Altera's SPL
>>>> (2013.01.01) and u-boot-2016.5 and this combo seems to work.
>>>>>>>
>>>>>>> I also notice that the frequency (max-spi-frequency) in the
>>>>>>> dts-file is not
>>>>>> picked up for some reason?
>>>>>>>
>>>>>>> Any help to fix the u-boot hang problem would be highly appreciated.
>>>>>>>
>>>>>>> Current printout (with added debug output):
>>>>>>>
>>>>>>> U-Boot SPL 2016.05 NGA QSPI -g133f59a-dirty (Jun 09 2016 -
>>>>>>> 17:06:20)
>>>>>>> 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
>>>>>>> spl_spi_load_image: bus=0, cs=0, speed=50000000, mode=3
>>>>>>> cadence_spi_ofdata_to_platdata: regbase=ff705000
>> ahbbase=ffa00000
>>>>>>> max-frequency=500000 page-size=256
>>>>>>> spi_flash_std_probe: slave=01100368, cs=0
>>>>>>> SF: Read data capture delay calibrated to 7 (0 - 15)
>>>>>>> cadence_spi_set_speed: speed=100000
>>>>>>> cadence_spi_xfer: len=1 [bytes]
>>>>>>> cadence_spi_xfer: len=5 [bytes]
>>>>>>> SF: Got idcodes
>>>>>>> 00000000: 20 ba 20 10 00 . ..
>>>>>>> SF: Detected N25Q512
>>>>>>> cadence_spi_xfer: len=1 [bytes]
>>>>>>> cadence_spi_xfer: len=1 [bytes]
>>>>>>> spi_flash_decode_fdt: Cannot decode address
>>>>>>> cadence_spi_xfer: len=0 [bytes]
>>>>>>> cadence_spi_xfer: len=0 [bytes]
>>>>>>> SF: Detected N25Q512 with page size 256 Bytes, erase size 64 KiB,
>>>>>>> total 64 MiB
>>>>>>> SF: Read data capture delay calibrated to 7 (0 - 15)
>>>>>>> cadence_spi_set_speed: speed=500000
>>>>>>> cadence_spi_xfer: len=5 [bytes]
>>>>>>> cadence_spi_xfer: len=64 [bytes]
>>>>>>> cadence_spi_xfer: len=5 [bytes]
>>>>>>> cadence_spi_xfer: len=443714 [bytes]
>>>>>>>
>>>>>>>
>>>>>>> U-Boot 2016.05 NGA QSPI -g133f59a-dirty (Jun 09 2016 - 17:06:20
>>>>>>> +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
>>>>>>>
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>> Christian
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> U-Boot mailing list
>>>>>>> U-Boot at lists.denx.de
>>>>>>> http://lists.denx.de/mailman/listinfo/u-boot
>>>>>>> _______________________________________________
>>>>>>> U-Boot mailing list
>>>>>>> U-Boot at lists.denx.de
>>>>>>> http://lists.denx.de/mailman/listinfo/u-boot
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Best regards,
>>>>>> Marek Vasut
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Christian
>>>>>
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>> Marek Vasut
>>
>>
>> --
>> Best regards,
>> Marek Vasut
>
> Best regards,
> Christian
>
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI
2016-06-17 14:48 ` Marek Vasut
@ 2016-06-20 13:22 ` Christian Didriksson
2016-06-20 13:43 ` Marek Vasut
0 siblings, 1 reply; 26+ messages in thread
From: Christian Didriksson @ 2016-06-20 13:22 UTC (permalink / raw)
To: u-boot
Hi Marek,
> 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.
> 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. But I don't understand why this happens. Dinh can you boot your CV socdk Rev E1 board with 2016.05 SPL?
> > Best regards,
> >
> > Christian
> >
> >> On 06/16/2016 12:13 PM, Christian Didriksson wrote:
> >>> Hi!
> >>
> >> Hi,
> >>
> >>>> On 06/15/2016 12:06 PM, Christian Didriksson wrote:
> >>>>> Trying again.
> >>>>
> >>>> Hi!
> >>>>
> >>>>> I have reverted back to a vanilla u-boot-2016.05, added the
> >>>>> not-enter-quad-mode patch
> >>>>
> >>>> What's this patch ? Can you share it ?
> >>
> >> [...]
> >>
> >> Thanks
> >>
> >>> Some comments:
> >>>
> >>> We want to run ECC, but I don't think the SPL supports scrubbing
> >>> etc. yet so
> >> I undefined those qts-parameters. Am I right regarding ECC for SDRAM?
> >>
> >> I'll delegate this one to Dinh, I never poked into the SRAM ECC stuff.
> >>
> >>> I couldn't get the SPL to work from the beginning and after much
> >> debugging I found that entering quad-mode for the flash is
> >> problematic in the SPL. At the same time I also found this,
> >> http://lists.denx.de/pipermail/u- boot/2016-June/256671.html,
> confirming my findings.
> >>>
> >>> I have prepared the u-boot MTD-configuration for our setup.
> >>>
> >>> I have added SPL SPI support and configured ENV-parameters and
> >>> u-boot offset
> >>>
> >>> I have also added the boot command we are going to use.
> >>
> >> OK
> >>
> >>>>> and changed the SPI address where the SPL should load the u-boot
> >>>>> from
> >>>>
> >>>> Can you share this change ?
> >>>>
> >>>
> >>> See above
> >>>
> >>>>> and it does not work. My question:
> >>>>>
> >>>>> Has anyone else tested SPL/u-boot on an Altera CV socdk Rev E1
> >>>>> board
> >>>> recently (like 2016.05)? U-boot hangs after printing memory size.
> >>>> Same result using different compilers.
> >>>>
> >>>> The rev E1 is the latest SoCDK, I only have rev. C1 . I remember
> >>>> Dinh
> >>>> (CCed) did send a patch for the rev. E board , so I assume he did
> >>>> test it, but those were only pinmux changes and it should be part
> >>>> of the
> >>>> v2016.05:
> >>>>
> >>>> commit 4baca92001bff3c32a05001a7dc58996623e3ef8
> >>>> Author: Dinh Nguyen <dinguyen@kernel.org>
> >>>> Date: Tue May 10 15:13:59 2016 -0500
> >>>>
> >>>> arm: socfpga: Update iomux and pll for c5 socdk RevE
> >>>>
> >>>> Another thing which comes to mind is the change in size of SPL,
> >>>> that might be worth looking at. Can you check the size of the SPL,
> >>>> u-boot-spl-
> >> dtb.bin ?
> >>>>
> >>>
> >>> 54534 bytes
> >>
> >> Try these two patches:
> >> https://patchwork.ozlabs.org/patch/627868/
> >> https://patchwork.ozlabs.org/patch/627869/
> >>
> >>>> I just tested the rev C socdk with 2016.05 and it boots for me. I
> >>>> will send you the binary I used off-list.
> >>>>
> >>>
> >>> Does this SPL (loaded from QSPI by bootrom?) load u-boot from QSPI?
> >>
> >> I only tested it booting from SD card, but it should just as well
> >> load from QSPI if the board is configured that way.
> >>
> >>>>> Best regards,
> >>>>>
> >>>>> Christian
> >>>>>
> >>>>> -----Ursprungligt meddelande-----
> >>>>> Fr?n: U-Boot [mailto:u-boot-bounces at lists.denx.de] F?r Christian
> >>>>> Didriksson
> >>>>> Skickat: den 9 juni 2016 20:15
> >>>>> Till: u-boot at lists.denx.de
> >>>>> ?mne: [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot
> >>>>> fail when booting from QSPI
> >>>>>
> >>>>> Hi All,
> >>>>>
> >>>>> I have been struggling for quite some time now to get SPL and
> >>>>> u-boot to
> >>>> run from QSPI-flash. Yesterday I was able to identify a workaround
> >>>> to get the SPL going by disabling quad mode for the flash (seems
> >>>> identified by
> >>>> http://lists.denx.de/pipermail/u-boot/2016-June/256671.html).
> >>>> However
> >>>> u- boot always hangs after printing memory size. I have tried to
> >>>> search the archive and have seen posts about hanging here, but
> >>>> nothing I can relate to my setup. I have tested to use Altera's SPL
> >> (2013.01.01) and u-boot-2016.5 and this combo seems to work.
> >>>>>
> >>>>> I also notice that the frequency (max-spi-frequency) in the
> >>>>> dts-file is not
> >>>> picked up for some reason?
> >>>>>
> >>>>> Any help to fix the u-boot hang problem would be highly appreciated.
> >>>>>
> >>>>> Current printout (with added debug output):
> >>>>>
> >>>>> U-Boot SPL 2016.05 NGA QSPI -g133f59a-dirty (Jun 09 2016 -
> >>>>> 17:06:20)
> >>>>> 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
> >>>>> spl_spi_load_image: bus=0, cs=0, speed=50000000, mode=3
> >>>>> cadence_spi_ofdata_to_platdata: regbase=ff705000
> ahbbase=ffa00000
> >>>>> max-frequency=500000 page-size=256
> >>>>> spi_flash_std_probe: slave=01100368, cs=0
> >>>>> SF: Read data capture delay calibrated to 7 (0 - 15)
> >>>>> cadence_spi_set_speed: speed=100000
> >>>>> cadence_spi_xfer: len=1 [bytes]
> >>>>> cadence_spi_xfer: len=5 [bytes]
> >>>>> SF: Got idcodes
> >>>>> 00000000: 20 ba 20 10 00 . ..
> >>>>> SF: Detected N25Q512
> >>>>> cadence_spi_xfer: len=1 [bytes]
> >>>>> cadence_spi_xfer: len=1 [bytes]
> >>>>> spi_flash_decode_fdt: Cannot decode address
> >>>>> cadence_spi_xfer: len=0 [bytes]
> >>>>> cadence_spi_xfer: len=0 [bytes]
> >>>>> SF: Detected N25Q512 with page size 256 Bytes, erase size 64 KiB,
> >>>>> total 64 MiB
> >>>>> SF: Read data capture delay calibrated to 7 (0 - 15)
> >>>>> cadence_spi_set_speed: speed=500000
> >>>>> cadence_spi_xfer: len=5 [bytes]
> >>>>> cadence_spi_xfer: len=64 [bytes]
> >>>>> cadence_spi_xfer: len=5 [bytes]
> >>>>> cadence_spi_xfer: len=443714 [bytes]
> >>>>>
> >>>>>
> >>>>> U-Boot 2016.05 NGA QSPI -g133f59a-dirty (Jun 09 2016 - 17:06:20
> >>>>> +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
> >>>>>
> >>>>>
> >>>>> Best regards,
> >>>>>
> >>>>> Christian
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> U-Boot mailing list
> >>>>> U-Boot at lists.denx.de
> >>>>> http://lists.denx.de/mailman/listinfo/u-boot
> >>>>> _______________________________________________
> >>>>> U-Boot mailing list
> >>>>> U-Boot at lists.denx.de
> >>>>> http://lists.denx.de/mailman/listinfo/u-boot
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Best regards,
> >>>> Marek Vasut
> >>>
> >>> Best regards,
> >>>
> >>> Christian
> >>>
> >>
> >>
> >> --
> >> Best regards,
> >> Marek Vasut
>
>
> --
> Best regards,
> Marek Vasut
Best regards,
Christian
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI
2016-06-17 14:39 ` Christian Didriksson
2016-06-17 14:48 ` Marek Vasut
@ 2016-06-17 16:45 ` Dinh Nguyen
1 sibling, 0 replies; 26+ messages in thread
From: Dinh Nguyen @ 2016-06-17 16:45 UTC (permalink / raw)
To: u-boot
Trying to respond inline:
On 06/17/2016 09:39 AM, Christian Didriksson wrote:
> Hi Marek,
>
> 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
>
>
I haven't tested on QSPI. I tested my patch on a board with SD/MMC. I'll
check it on a QSPI board shortly.
> 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
>
> Best regards,
>
> Christian
>
>> On 06/16/2016 12:13 PM, Christian Didriksson wrote:
>>> Hi!
>>
>> Hi,
>>
>>>> On 06/15/2016 12:06 PM, Christian Didriksson wrote:
>>>>> Trying again.
>>>>
>>>> Hi!
>>>>
>>>>> I have reverted back to a vanilla u-boot-2016.05, added the
>>>>> not-enter-quad-mode patch
>>>>
>>>> What's this patch ? Can you share it ?
>>
>> [...]
>>
>> Thanks
>>
>>> Some comments:
>>>
>>> We want to run ECC, but I don't think the SPL supports scrubbing etc. yet so
>> I undefined those qts-parameters. Am I right regarding ECC for SDRAM?
>>
Yes, in order for ECC, you need to scrub the SDRAM. I'll look to see
what is needed.
Dinh
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI
2016-06-17 14:39 ` Christian Didriksson
@ 2016-06-17 14:48 ` Marek Vasut
2016-06-20 13:22 ` Christian Didriksson
2016-06-17 16:45 ` Dinh Nguyen
1 sibling, 1 reply; 26+ messages in thread
From: Marek Vasut @ 2016-06-17 14:48 UTC (permalink / raw)
To: u-boot
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 ?
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)
> Best regards,
>
> Christian
>
>> On 06/16/2016 12:13 PM, Christian Didriksson wrote:
>>> Hi!
>>
>> Hi,
>>
>>>> On 06/15/2016 12:06 PM, Christian Didriksson wrote:
>>>>> Trying again.
>>>>
>>>> Hi!
>>>>
>>>>> I have reverted back to a vanilla u-boot-2016.05, added the
>>>>> not-enter-quad-mode patch
>>>>
>>>> What's this patch ? Can you share it ?
>>
>> [...]
>>
>> Thanks
>>
>>> Some comments:
>>>
>>> We want to run ECC, but I don't think the SPL supports scrubbing etc. yet so
>> I undefined those qts-parameters. Am I right regarding ECC for SDRAM?
>>
>> I'll delegate this one to Dinh, I never poked into the SRAM ECC stuff.
>>
>>> I couldn't get the SPL to work from the beginning and after much
>> debugging I found that entering quad-mode for the flash is problematic in
>> the SPL. At the same time I also found this, http://lists.denx.de/pipermail/u-
>> boot/2016-June/256671.html, confirming my findings.
>>>
>>> I have prepared the u-boot MTD-configuration for our setup.
>>>
>>> I have added SPL SPI support and configured ENV-parameters and u-boot
>>> offset
>>>
>>> I have also added the boot command we are going to use.
>>
>> OK
>>
>>>>> and changed the SPI address where the SPL should load the u-boot
>>>>> from
>>>>
>>>> Can you share this change ?
>>>>
>>>
>>> See above
>>>
>>>>> and it does not work. My question:
>>>>>
>>>>> Has anyone else tested SPL/u-boot on an Altera CV socdk Rev E1 board
>>>> recently (like 2016.05)? U-boot hangs after printing memory size.
>>>> Same result using different compilers.
>>>>
>>>> The rev E1 is the latest SoCDK, I only have rev. C1 . I remember Dinh
>>>> (CCed) did send a patch for the rev. E board , so I assume he did
>>>> test it, but those were only pinmux changes and it should be part of
>>>> the
>>>> v2016.05:
>>>>
>>>> commit 4baca92001bff3c32a05001a7dc58996623e3ef8
>>>> Author: Dinh Nguyen <dinguyen@kernel.org>
>>>> Date: Tue May 10 15:13:59 2016 -0500
>>>>
>>>> arm: socfpga: Update iomux and pll for c5 socdk RevE
>>>>
>>>> Another thing which comes to mind is the change in size of SPL, that
>>>> might be worth looking at. Can you check the size of the SPL, u-boot-spl-
>> dtb.bin ?
>>>>
>>>
>>> 54534 bytes
>>
>> Try these two patches:
>> https://patchwork.ozlabs.org/patch/627868/
>> https://patchwork.ozlabs.org/patch/627869/
>>
>>>> I just tested the rev C socdk with 2016.05 and it boots for me. I
>>>> will send you the binary I used off-list.
>>>>
>>>
>>> Does this SPL (loaded from QSPI by bootrom?) load u-boot from QSPI?
>>
>> I only tested it booting from SD card, but it should just as well load from QSPI
>> if the board is configured that way.
>>
>>>>> Best regards,
>>>>>
>>>>> Christian
>>>>>
>>>>> -----Ursprungligt meddelande-----
>>>>> Fr?n: U-Boot [mailto:u-boot-bounces at lists.denx.de] F?r Christian
>>>>> Didriksson
>>>>> Skickat: den 9 juni 2016 20:15
>>>>> Till: u-boot at lists.denx.de
>>>>> ?mne: [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail
>>>>> when booting from QSPI
>>>>>
>>>>> Hi All,
>>>>>
>>>>> I have been struggling for quite some time now to get SPL and u-boot
>>>>> to
>>>> run from QSPI-flash. Yesterday I was able to identify a workaround to
>>>> get the SPL going by disabling quad mode for the flash (seems
>>>> identified by
>>>> http://lists.denx.de/pipermail/u-boot/2016-June/256671.html). However
>>>> u- boot always hangs after printing memory size. I have tried to
>>>> search the archive and have seen posts about hanging here, but
>>>> nothing I can relate to my setup. I have tested to use Altera's SPL
>> (2013.01.01) and u-boot-2016.5 and this combo seems to work.
>>>>>
>>>>> I also notice that the frequency (max-spi-frequency) in the dts-file
>>>>> is not
>>>> picked up for some reason?
>>>>>
>>>>> Any help to fix the u-boot hang problem would be highly appreciated.
>>>>>
>>>>> Current printout (with added debug output):
>>>>>
>>>>> U-Boot SPL 2016.05 NGA QSPI -g133f59a-dirty (Jun 09 2016 - 17:06:20)
>>>>> 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
>>>>> spl_spi_load_image: bus=0, cs=0, speed=50000000, mode=3
>>>>> cadence_spi_ofdata_to_platdata: regbase=ff705000 ahbbase=ffa00000
>>>>> max-frequency=500000 page-size=256
>>>>> spi_flash_std_probe: slave=01100368, cs=0
>>>>> SF: Read data capture delay calibrated to 7 (0 - 15)
>>>>> cadence_spi_set_speed: speed=100000
>>>>> cadence_spi_xfer: len=1 [bytes]
>>>>> cadence_spi_xfer: len=5 [bytes]
>>>>> SF: Got idcodes
>>>>> 00000000: 20 ba 20 10 00 . ..
>>>>> SF: Detected N25Q512
>>>>> cadence_spi_xfer: len=1 [bytes]
>>>>> cadence_spi_xfer: len=1 [bytes]
>>>>> spi_flash_decode_fdt: Cannot decode address
>>>>> cadence_spi_xfer: len=0 [bytes]
>>>>> cadence_spi_xfer: len=0 [bytes]
>>>>> SF: Detected N25Q512 with page size 256 Bytes, erase size 64 KiB,
>>>>> total 64 MiB
>>>>> SF: Read data capture delay calibrated to 7 (0 - 15)
>>>>> cadence_spi_set_speed: speed=500000
>>>>> cadence_spi_xfer: len=5 [bytes]
>>>>> cadence_spi_xfer: len=64 [bytes]
>>>>> cadence_spi_xfer: len=5 [bytes]
>>>>> cadence_spi_xfer: len=443714 [bytes]
>>>>>
>>>>>
>>>>> U-Boot 2016.05 NGA QSPI -g133f59a-dirty (Jun 09 2016 - 17:06:20
>>>>> +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
>>>>>
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Christian
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> U-Boot mailing list
>>>>> U-Boot at lists.denx.de
>>>>> http://lists.denx.de/mailman/listinfo/u-boot
>>>>> _______________________________________________
>>>>> U-Boot mailing list
>>>>> U-Boot at lists.denx.de
>>>>> http://lists.denx.de/mailman/listinfo/u-boot
>>>>>
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>> Marek Vasut
>>>
>>> Best regards,
>>>
>>> Christian
>>>
>>
>>
>> --
>> Best regards,
>> Marek Vasut
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI
2016-06-16 13:32 ` Marek Vasut
@ 2016-06-17 14:39 ` Christian Didriksson
2016-06-17 14:48 ` Marek Vasut
2016-06-17 16:45 ` Dinh Nguyen
0 siblings, 2 replies; 26+ messages in thread
From: Christian Didriksson @ 2016-06-17 14:39 UTC (permalink / raw)
To: u-boot
Hi Marek,
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
Best regards,
Christian
> On 06/16/2016 12:13 PM, Christian Didriksson wrote:
> > Hi!
>
> Hi,
>
> >> On 06/15/2016 12:06 PM, Christian Didriksson wrote:
> >>> Trying again.
> >>
> >> Hi!
> >>
> >>> I have reverted back to a vanilla u-boot-2016.05, added the
> >>> not-enter-quad-mode patch
> >>
> >> What's this patch ? Can you share it ?
>
> [...]
>
> Thanks
>
> > Some comments:
> >
> > We want to run ECC, but I don't think the SPL supports scrubbing etc. yet so
> I undefined those qts-parameters. Am I right regarding ECC for SDRAM?
>
> I'll delegate this one to Dinh, I never poked into the SRAM ECC stuff.
>
> > I couldn't get the SPL to work from the beginning and after much
> debugging I found that entering quad-mode for the flash is problematic in
> the SPL. At the same time I also found this, http://lists.denx.de/pipermail/u-
> boot/2016-June/256671.html, confirming my findings.
> >
> > I have prepared the u-boot MTD-configuration for our setup.
> >
> > I have added SPL SPI support and configured ENV-parameters and u-boot
> > offset
> >
> > I have also added the boot command we are going to use.
>
> OK
>
> >>> and changed the SPI address where the SPL should load the u-boot
> >>> from
> >>
> >> Can you share this change ?
> >>
> >
> > See above
> >
> >>> and it does not work. My question:
> >>>
> >>> Has anyone else tested SPL/u-boot on an Altera CV socdk Rev E1 board
> >> recently (like 2016.05)? U-boot hangs after printing memory size.
> >> Same result using different compilers.
> >>
> >> The rev E1 is the latest SoCDK, I only have rev. C1 . I remember Dinh
> >> (CCed) did send a patch for the rev. E board , so I assume he did
> >> test it, but those were only pinmux changes and it should be part of
> >> the
> >> v2016.05:
> >>
> >> commit 4baca92001bff3c32a05001a7dc58996623e3ef8
> >> Author: Dinh Nguyen <dinguyen@kernel.org>
> >> Date: Tue May 10 15:13:59 2016 -0500
> >>
> >> arm: socfpga: Update iomux and pll for c5 socdk RevE
> >>
> >> Another thing which comes to mind is the change in size of SPL, that
> >> might be worth looking at. Can you check the size of the SPL, u-boot-spl-
> dtb.bin ?
> >>
> >
> > 54534 bytes
>
> Try these two patches:
> https://patchwork.ozlabs.org/patch/627868/
> https://patchwork.ozlabs.org/patch/627869/
>
> >> I just tested the rev C socdk with 2016.05 and it boots for me. I
> >> will send you the binary I used off-list.
> >>
> >
> > Does this SPL (loaded from QSPI by bootrom?) load u-boot from QSPI?
>
> I only tested it booting from SD card, but it should just as well load from QSPI
> if the board is configured that way.
>
> >>> Best regards,
> >>>
> >>> Christian
> >>>
> >>> -----Ursprungligt meddelande-----
> >>> Fr?n: U-Boot [mailto:u-boot-bounces at lists.denx.de] F?r Christian
> >>> Didriksson
> >>> Skickat: den 9 juni 2016 20:15
> >>> Till: u-boot at lists.denx.de
> >>> ?mne: [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail
> >>> when booting from QSPI
> >>>
> >>> Hi All,
> >>>
> >>> I have been struggling for quite some time now to get SPL and u-boot
> >>> to
> >> run from QSPI-flash. Yesterday I was able to identify a workaround to
> >> get the SPL going by disabling quad mode for the flash (seems
> >> identified by
> >> http://lists.denx.de/pipermail/u-boot/2016-June/256671.html). However
> >> u- boot always hangs after printing memory size. I have tried to
> >> search the archive and have seen posts about hanging here, but
> >> nothing I can relate to my setup. I have tested to use Altera's SPL
> (2013.01.01) and u-boot-2016.5 and this combo seems to work.
> >>>
> >>> I also notice that the frequency (max-spi-frequency) in the dts-file
> >>> is not
> >> picked up for some reason?
> >>>
> >>> Any help to fix the u-boot hang problem would be highly appreciated.
> >>>
> >>> Current printout (with added debug output):
> >>>
> >>> U-Boot SPL 2016.05 NGA QSPI -g133f59a-dirty (Jun 09 2016 - 17:06:20)
> >>> 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
> >>> spl_spi_load_image: bus=0, cs=0, speed=50000000, mode=3
> >>> cadence_spi_ofdata_to_platdata: regbase=ff705000 ahbbase=ffa00000
> >>> max-frequency=500000 page-size=256
> >>> spi_flash_std_probe: slave=01100368, cs=0
> >>> SF: Read data capture delay calibrated to 7 (0 - 15)
> >>> cadence_spi_set_speed: speed=100000
> >>> cadence_spi_xfer: len=1 [bytes]
> >>> cadence_spi_xfer: len=5 [bytes]
> >>> SF: Got idcodes
> >>> 00000000: 20 ba 20 10 00 . ..
> >>> SF: Detected N25Q512
> >>> cadence_spi_xfer: len=1 [bytes]
> >>> cadence_spi_xfer: len=1 [bytes]
> >>> spi_flash_decode_fdt: Cannot decode address
> >>> cadence_spi_xfer: len=0 [bytes]
> >>> cadence_spi_xfer: len=0 [bytes]
> >>> SF: Detected N25Q512 with page size 256 Bytes, erase size 64 KiB,
> >>> total 64 MiB
> >>> SF: Read data capture delay calibrated to 7 (0 - 15)
> >>> cadence_spi_set_speed: speed=500000
> >>> cadence_spi_xfer: len=5 [bytes]
> >>> cadence_spi_xfer: len=64 [bytes]
> >>> cadence_spi_xfer: len=5 [bytes]
> >>> cadence_spi_xfer: len=443714 [bytes]
> >>>
> >>>
> >>> U-Boot 2016.05 NGA QSPI -g133f59a-dirty (Jun 09 2016 - 17:06:20
> >>> +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
> >>>
> >>>
> >>> Best regards,
> >>>
> >>> Christian
> >>>
> >>>
> >>> _______________________________________________
> >>> U-Boot mailing list
> >>> U-Boot at lists.denx.de
> >>> http://lists.denx.de/mailman/listinfo/u-boot
> >>> _______________________________________________
> >>> U-Boot mailing list
> >>> U-Boot at lists.denx.de
> >>> http://lists.denx.de/mailman/listinfo/u-boot
> >>>
> >>
> >>
> >> --
> >> Best regards,
> >> Marek Vasut
> >
> > Best regards,
> >
> > Christian
> >
>
>
> --
> Best regards,
> Marek Vasut
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI
2016-06-16 10:13 ` Christian Didriksson
@ 2016-06-16 13:32 ` Marek Vasut
2016-06-17 14:39 ` Christian Didriksson
0 siblings, 1 reply; 26+ messages in thread
From: Marek Vasut @ 2016-06-16 13:32 UTC (permalink / raw)
To: u-boot
On 06/16/2016 12:13 PM, Christian Didriksson wrote:
> Hi!
Hi,
>> On 06/15/2016 12:06 PM, Christian Didriksson wrote:
>>> Trying again.
>>
>> Hi!
>>
>>> I have reverted back to a vanilla u-boot-2016.05, added the
>>> not-enter-quad-mode patch
>>
>> What's this patch ? Can you share it ?
[...]
Thanks
> Some comments:
>
> We want to run ECC, but I don't think the SPL supports scrubbing etc. yet so I undefined those qts-parameters. Am I right regarding ECC for SDRAM?
I'll delegate this one to Dinh, I never poked into the SRAM ECC stuff.
> I couldn't get the SPL to work from the beginning and after much debugging I found that entering quad-mode for the flash is problematic in the SPL. At the same time I also found this, http://lists.denx.de/pipermail/u-boot/2016-June/256671.html, confirming my findings.
>
> I have prepared the u-boot MTD-configuration for our setup.
>
> I have added SPL SPI support and configured ENV-parameters and u-boot offset
>
> I have also added the boot command we are going to use.
OK
>>> and changed the SPI address where the SPL should load the u-boot from
>>
>> Can you share this change ?
>>
>
> See above
>
>>> and it does not work. My question:
>>>
>>> Has anyone else tested SPL/u-boot on an Altera CV socdk Rev E1 board
>> recently (like 2016.05)? U-boot hangs after printing memory size. Same
>> result using different compilers.
>>
>> The rev E1 is the latest SoCDK, I only have rev. C1 . I remember Dinh
>> (CCed) did send a patch for the rev. E board , so I assume he did test it, but
>> those were only pinmux changes and it should be part of the
>> v2016.05:
>>
>> commit 4baca92001bff3c32a05001a7dc58996623e3ef8
>> Author: Dinh Nguyen <dinguyen@kernel.org>
>> Date: Tue May 10 15:13:59 2016 -0500
>>
>> arm: socfpga: Update iomux and pll for c5 socdk RevE
>>
>> Another thing which comes to mind is the change in size of SPL, that might be
>> worth looking at. Can you check the size of the SPL, u-boot-spl-dtb.bin ?
>>
>
> 54534 bytes
Try these two patches:
https://patchwork.ozlabs.org/patch/627868/
https://patchwork.ozlabs.org/patch/627869/
>> I just tested the rev C socdk with 2016.05 and it boots for me. I will send you
>> the binary I used off-list.
>>
>
> Does this SPL (loaded from QSPI by bootrom?) load u-boot from QSPI?
I only tested it booting from SD card, but it should just as well load
from QSPI if the board is configured that way.
>>> Best regards,
>>>
>>> Christian
>>>
>>> -----Ursprungligt meddelande-----
>>> Fr?n: U-Boot [mailto:u-boot-bounces at lists.denx.de] F?r Christian
>>> Didriksson
>>> Skickat: den 9 juni 2016 20:15
>>> Till: u-boot at lists.denx.de
>>> ?mne: [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail
>>> when booting from QSPI
>>>
>>> Hi All,
>>>
>>> I have been struggling for quite some time now to get SPL and u-boot to
>> run from QSPI-flash. Yesterday I was able to identify a workaround to get the
>> SPL going by disabling quad mode for the flash (seems identified by
>> http://lists.denx.de/pipermail/u-boot/2016-June/256671.html). However u-
>> boot always hangs after printing memory size. I have tried to search the
>> archive and have seen posts about hanging here, but nothing I can relate to
>> my setup. I have tested to use Altera's SPL (2013.01.01) and u-boot-2016.5
>> and this combo seems to work.
>>>
>>> I also notice that the frequency (max-spi-frequency) in the dts-file is not
>> picked up for some reason?
>>>
>>> Any help to fix the u-boot hang problem would be highly appreciated.
>>>
>>> Current printout (with added debug output):
>>>
>>> U-Boot SPL 2016.05 NGA QSPI -g133f59a-dirty (Jun 09 2016 - 17:06:20)
>>> 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
>>> spl_spi_load_image: bus=0, cs=0, speed=50000000, mode=3
>>> cadence_spi_ofdata_to_platdata: regbase=ff705000 ahbbase=ffa00000
>>> max-frequency=500000 page-size=256
>>> spi_flash_std_probe: slave=01100368, cs=0
>>> SF: Read data capture delay calibrated to 7 (0 - 15)
>>> cadence_spi_set_speed: speed=100000
>>> cadence_spi_xfer: len=1 [bytes]
>>> cadence_spi_xfer: len=5 [bytes]
>>> SF: Got idcodes
>>> 00000000: 20 ba 20 10 00 . ..
>>> SF: Detected N25Q512
>>> cadence_spi_xfer: len=1 [bytes]
>>> cadence_spi_xfer: len=1 [bytes]
>>> spi_flash_decode_fdt: Cannot decode address
>>> cadence_spi_xfer: len=0 [bytes]
>>> cadence_spi_xfer: len=0 [bytes]
>>> SF: Detected N25Q512 with page size 256 Bytes, erase size 64 KiB,
>>> total 64 MiB
>>> SF: Read data capture delay calibrated to 7 (0 - 15)
>>> cadence_spi_set_speed: speed=500000
>>> cadence_spi_xfer: len=5 [bytes]
>>> cadence_spi_xfer: len=64 [bytes]
>>> cadence_spi_xfer: len=5 [bytes]
>>> cadence_spi_xfer: len=443714 [bytes]
>>>
>>>
>>> U-Boot 2016.05 NGA QSPI -g133f59a-dirty (Jun 09 2016 - 17:06:20 +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
>>>
>>>
>>> Best regards,
>>>
>>> Christian
>>>
>>>
>>> _______________________________________________
>>> U-Boot mailing list
>>> U-Boot at lists.denx.de
>>> http://lists.denx.de/mailman/listinfo/u-boot
>>> _______________________________________________
>>> U-Boot mailing list
>>> U-Boot at lists.denx.de
>>> http://lists.denx.de/mailman/listinfo/u-boot
>>>
>>
>>
>> --
>> Best regards,
>> Marek Vasut
>
> Best regards,
>
> Christian
>
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI
2016-06-15 22:36 ` Marek Vasut
@ 2016-06-16 10:13 ` Christian Didriksson
2016-06-16 13:32 ` Marek Vasut
0 siblings, 1 reply; 26+ messages in thread
From: Christian Didriksson @ 2016-06-16 10:13 UTC (permalink / raw)
To: u-boot
Hi!
> On 06/15/2016 12:06 PM, Christian Didriksson wrote:
> > Trying again.
>
> Hi!
>
> > I have reverted back to a vanilla u-boot-2016.05, added the
> > not-enter-quad-mode patch
>
> What's this patch ? Can you share it ?
>
These are the changes I have made to 2016.05:
diff --git a/board/altera/cyclone5-socdk/qts/sdram_config.h b/board/altera/cyclone5-socdk/qts/sdram_config.h
index 37c1476..bd61a7a 100644
--- a/board/altera/cyclone5-socdk/qts/sdram_config.h
+++ b/board/altera/cyclone5-socdk/qts/sdram_config.h
@@ -14,8 +14,8 @@
#define CONFIG_HPS_SDR_CTRLCFG_CPORTWMAP_CPORTWMAP 0x2C011000
#define CONFIG_HPS_SDR_CTRLCFG_CTRLCFG_ADDRORDER 0
#define CONFIG_HPS_SDR_CTRLCFG_CTRLCFG_DQSTRKEN 0
-#define CONFIG_HPS_SDR_CTRLCFG_CTRLCFG_ECCCORREN 1
-#define CONFIG_HPS_SDR_CTRLCFG_CTRLCFG_ECCEN 1
+#define CONFIG_HPS_SDR_CTRLCFG_CTRLCFG_ECCCORREN 0
+#define CONFIG_HPS_SDR_CTRLCFG_CTRLCFG_ECCEN 0
#define CONFIG_HPS_SDR_CTRLCFG_CTRLCFG_MEMBL 8
#define CONFIG_HPS_SDR_CTRLCFG_CTRLCFG_MEMTYPE 2
#define CONFIG_HPS_SDR_CTRLCFG_CTRLCFG_NODMPINS 0
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 5451725..de3abca 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -1104,20 +1104,24 @@ int spi_flash_scan(struct spi_flash *flash)
/* Now erase size becomes valid sector size */
flash->sector_size = flash->erase_size;
+#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;
diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h
index 4fdc09a..ac83ee4 100644
--- a/include/configs/socfpga_common.h
+++ b/include/configs/socfpga_common.h
@@ -284,22 +284,28 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
*
* device nor0 <ff705000.spi.0>, # parts = 6
* #: name size offset mask_flags
- * 0: u-boot 0x00100000 0x00000000 0
- * 1: env1 0x00040000 0x00100000 0
- * 2: env2 0x00040000 0x00140000 0
- * 3: UBI 0x03e80000 0x00180000 0
- * 4: boot 0x00e80000 0x00180000 0
- * 5: rootfs 0x01000000 0x01000000 0
+ * 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
*
*/
#if defined(CONFIG_CMD_SF) && !defined(MTDPARTS_DEFAULT)
#define MTDPARTS_DEFAULT "mtdparts=ff705000.spi.0:"\
- "1m(u-boot)," \
- "256k(env1)," \
- "256k(env2)," \
- "14848k(boot)," \
- "16m(rootfs)," \
- "- at 1536k(UBI)\0"
+ "256k(spl)," \
+ "64k(env1)," \
+ "64k(dtb)," \
+ "512k(u-boot)," \
+ "8m(lba)," \
+ "16m(lbafs)," \
+ "8m(fpga)," \
+ "128k(script)," \
+ "-(UBI)\0"
#endif
/* UBI and UBIFS support */
@@ -360,7 +366,7 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
#ifdef CONFIG_SPL_SPI_SUPPORT
#define CONFIG_SPL_SPI_FLASH_SUPPORT
#define CONFIG_SPL_SPI_LOAD
-#define CONFIG_SYS_SPI_U_BOOT_OFFS 0x40000
+#define CONFIG_SYS_SPI_U_BOOT_OFFS 0x60000
#endif
/* SPL NAND boot support */
diff --git a/include/configs/socfpga_cyclone5_socdk.h b/include/configs/socfpga_cyclone5_socdk.h
index a2da7d4..399f42c 100644
--- a/include/configs/socfpga_cyclone5_socdk.h
+++ b/include/configs/socfpga_cyclone5_socdk.h
@@ -24,7 +24,7 @@
#ifdef CONFIG_SOCFPGA_VIRTUAL_TARGET
#define CONFIG_BOOTCOMMAND "run ramboot"
#else
-#define CONFIG_BOOTCOMMAND "run mmcload; run mmcboot"
+#define CONFIG_BOOTCOMMAND "run qspi-boot-nga"
#endif
#define CONFIG_LOADADDR 0x01000000
#define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR
@@ -35,7 +35,18 @@
#define CONFIG_PHY_MICREL_KSZ9021
#endif
-#define CONFIG_ENV_IS_IN_MMC
+#define CONFIG_SPL_SPI_SUPPORT
+
+#define CONFIG_ENV_IS_IN_SPI_FLASH
+#define CONFIG_ENV_OFFSET 0x00040000
+#define CONFIG_ENV_SECT_SIZE (64 * 1024)
+#define CONFIG_ENV_SIZE (64 * 1024)
+
+#define CONFIG_SF_DEFAULT_SPEED 50000000
+#define CONFIG_SF_DEFAULT_MODE SPI_MODE_3
+#define CONFIG_SF_DEFAULT_BUS 0
+#define CONFIG_SF_DEFAULT_CS 0
+
/* Extra Environment */
#define CONFIG_EXTRA_ENV_SETTINGS \
@@ -58,6 +69,11 @@
"qspiboot=setenv bootargs " CONFIG_BOOTARGS \
" ubi.mtd=1,64 root=ubi0:rootfs rw rootfstype=ubifs;"\
"bootz ${loadaddr} - ${fdt_addr}\0" \
+ "qspiloadcs=0\0" \
+ "qspiscraddr=0x020e0000\0" \
+ "qspi-boot-nga=sf probe ${qspiloadcs};" \
+ "sf read 0x100000 ${qspiscraddr} 0x10000;" \
+ "source 0x100000\0" \
"ubiload=ubi part UBI && ubifsmount ubi0 && " \
"ubifsload ${loadaddr} /boot/${bootimage} && " \
"ubifsload ${fdt_addr} /boot/${fdtimage}\0"
Some comments:
We want to run ECC, but I don't think the SPL supports scrubbing etc. yet so I undefined those qts-parameters. Am I right regarding ECC for SDRAM?
I couldn't get the SPL to work from the beginning and after much debugging I found that entering quad-mode for the flash is problematic in the SPL. At the same time I also found this, http://lists.denx.de/pipermail/u-boot/2016-June/256671.html, confirming my findings.
I have prepared the u-boot MTD-configuration for our setup.
I have added SPL SPI support and configured ENV-parameters and u-boot offset
I have also added the boot command we are going to use.
> > and changed the SPI address where the SPL should load the u-boot from
>
> Can you share this change ?
>
See above
> > and it does not work. My question:
> >
> > Has anyone else tested SPL/u-boot on an Altera CV socdk Rev E1 board
> recently (like 2016.05)? U-boot hangs after printing memory size. Same
> result using different compilers.
>
> The rev E1 is the latest SoCDK, I only have rev. C1 . I remember Dinh
> (CCed) did send a patch for the rev. E board , so I assume he did test it, but
> those were only pinmux changes and it should be part of the
> v2016.05:
>
> commit 4baca92001bff3c32a05001a7dc58996623e3ef8
> Author: Dinh Nguyen <dinguyen@kernel.org>
> Date: Tue May 10 15:13:59 2016 -0500
>
> arm: socfpga: Update iomux and pll for c5 socdk RevE
>
> Another thing which comes to mind is the change in size of SPL, that might be
> worth looking at. Can you check the size of the SPL, u-boot-spl-dtb.bin ?
>
54534 bytes
> I just tested the rev C socdk with 2016.05 and it boots for me. I will send you
> the binary I used off-list.
>
Does this SPL (loaded from QSPI by bootrom?) load u-boot from QSPI?
> > Best regards,
> >
> > Christian
> >
> > -----Ursprungligt meddelande-----
> > Fr?n: U-Boot [mailto:u-boot-bounces at lists.denx.de] F?r Christian
> > Didriksson
> > Skickat: den 9 juni 2016 20:15
> > Till: u-boot at lists.denx.de
> > ?mne: [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail
> > when booting from QSPI
> >
> > Hi All,
> >
> > I have been struggling for quite some time now to get SPL and u-boot to
> run from QSPI-flash. Yesterday I was able to identify a workaround to get the
> SPL going by disabling quad mode for the flash (seems identified by
> http://lists.denx.de/pipermail/u-boot/2016-June/256671.html). However u-
> boot always hangs after printing memory size. I have tried to search the
> archive and have seen posts about hanging here, but nothing I can relate to
> my setup. I have tested to use Altera's SPL (2013.01.01) and u-boot-2016.5
> and this combo seems to work.
> >
> > I also notice that the frequency (max-spi-frequency) in the dts-file is not
> picked up for some reason?
> >
> > Any help to fix the u-boot hang problem would be highly appreciated.
> >
> > Current printout (with added debug output):
> >
> > U-Boot SPL 2016.05 NGA QSPI -g133f59a-dirty (Jun 09 2016 - 17:06:20)
> > 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
> > spl_spi_load_image: bus=0, cs=0, speed=50000000, mode=3
> > cadence_spi_ofdata_to_platdata: regbase=ff705000 ahbbase=ffa00000
> > max-frequency=500000 page-size=256
> > spi_flash_std_probe: slave=01100368, cs=0
> > SF: Read data capture delay calibrated to 7 (0 - 15)
> > cadence_spi_set_speed: speed=100000
> > cadence_spi_xfer: len=1 [bytes]
> > cadence_spi_xfer: len=5 [bytes]
> > SF: Got idcodes
> > 00000000: 20 ba 20 10 00 . ..
> > SF: Detected N25Q512
> > cadence_spi_xfer: len=1 [bytes]
> > cadence_spi_xfer: len=1 [bytes]
> > spi_flash_decode_fdt: Cannot decode address
> > cadence_spi_xfer: len=0 [bytes]
> > cadence_spi_xfer: len=0 [bytes]
> > SF: Detected N25Q512 with page size 256 Bytes, erase size 64 KiB,
> > total 64 MiB
> > SF: Read data capture delay calibrated to 7 (0 - 15)
> > cadence_spi_set_speed: speed=500000
> > cadence_spi_xfer: len=5 [bytes]
> > cadence_spi_xfer: len=64 [bytes]
> > cadence_spi_xfer: len=5 [bytes]
> > cadence_spi_xfer: len=443714 [bytes]
> >
> >
> > U-Boot 2016.05 NGA QSPI -g133f59a-dirty (Jun 09 2016 - 17:06:20 +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
> >
> >
> > Best regards,
> >
> > Christian
> >
> >
> > _______________________________________________
> > U-Boot mailing list
> > U-Boot at lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot
> > _______________________________________________
> > U-Boot mailing list
> > U-Boot at lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot
> >
>
>
> --
> Best regards,
> Marek Vasut
Best regards,
Christian
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI
2016-06-15 10:06 ` Christian Didriksson
@ 2016-06-15 22:36 ` Marek Vasut
2016-06-16 10:13 ` Christian Didriksson
0 siblings, 1 reply; 26+ messages in thread
From: Marek Vasut @ 2016-06-15 22:36 UTC (permalink / raw)
To: u-boot
On 06/15/2016 12:06 PM, Christian Didriksson wrote:
> Trying again.
Hi!
> I have reverted back to a vanilla u-boot-2016.05, added the not-enter-quad-mode patch
What's this patch ? Can you share it ?
> and changed the SPI address where the SPL should load the u-boot from
Can you share this change ?
> and it does not work. My question:
>
> Has anyone else tested SPL/u-boot on an Altera CV socdk Rev E1 board recently (like 2016.05)? U-boot hangs after printing memory size. Same result using different compilers.
The rev E1 is the latest SoCDK, I only have rev. C1 . I remember Dinh
(CCed) did send a patch for the rev. E board , so I assume he did test
it, but those were only pinmux changes and it should be part of the
v2016.05:
commit 4baca92001bff3c32a05001a7dc58996623e3ef8
Author: Dinh Nguyen <dinguyen@kernel.org>
Date: Tue May 10 15:13:59 2016 -0500
arm: socfpga: Update iomux and pll for c5 socdk RevE
Another thing which comes to mind is the change in size of SPL, that
might be worth looking at. Can you check the size of the SPL,
u-boot-spl-dtb.bin ?
I just tested the rev C socdk with 2016.05 and it boots for me. I will
send you the binary I used off-list.
> Best regards,
>
> Christian
>
> -----Ursprungligt meddelande-----
> Fr?n: U-Boot [mailto:u-boot-bounces at lists.denx.de] F?r Christian Didriksson
> Skickat: den 9 juni 2016 20:15
> Till: u-boot at lists.denx.de
> ?mne: [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI
>
> Hi All,
>
> I have been struggling for quite some time now to get SPL and u-boot to run from QSPI-flash. Yesterday I was able to identify a workaround to get the SPL going by disabling quad mode for the flash (seems identified by http://lists.denx.de/pipermail/u-boot/2016-June/256671.html). However u-boot always hangs after printing memory size. I have tried to search the archive and have seen posts about hanging here, but nothing I can relate to my setup. I have tested to use Altera's SPL (2013.01.01) and u-boot-2016.5 and this combo seems to work.
>
> I also notice that the frequency (max-spi-frequency) in the dts-file is not picked up for some reason?
>
> Any help to fix the u-boot hang problem would be highly appreciated.
>
> Current printout (with added debug output):
>
> U-Boot SPL 2016.05 NGA QSPI -g133f59a-dirty (Jun 09 2016 - 17:06:20)
> 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
> spl_spi_load_image: bus=0, cs=0, speed=50000000, mode=3
> cadence_spi_ofdata_to_platdata: regbase=ff705000 ahbbase=ffa00000 max-frequency=500000 page-size=256
> spi_flash_std_probe: slave=01100368, cs=0
> SF: Read data capture delay calibrated to 7 (0 - 15)
> cadence_spi_set_speed: speed=100000
> cadence_spi_xfer: len=1 [bytes]
> cadence_spi_xfer: len=5 [bytes]
> SF: Got idcodes
> 00000000: 20 ba 20 10 00 . ..
> SF: Detected N25Q512
> cadence_spi_xfer: len=1 [bytes]
> cadence_spi_xfer: len=1 [bytes]
> spi_flash_decode_fdt: Cannot decode address
> cadence_spi_xfer: len=0 [bytes]
> cadence_spi_xfer: len=0 [bytes]
> SF: Detected N25Q512 with page size 256 Bytes, erase size 64 KiB, total 64 MiB
> SF: Read data capture delay calibrated to 7 (0 - 15)
> cadence_spi_set_speed: speed=500000
> cadence_spi_xfer: len=5 [bytes]
> cadence_spi_xfer: len=64 [bytes]
> cadence_spi_xfer: len=5 [bytes]
> cadence_spi_xfer: len=443714 [bytes]
>
>
> U-Boot 2016.05 NGA QSPI -g133f59a-dirty (Jun 09 2016 - 17:06:20 +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
>
>
> Best regards,
>
> Christian
>
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI
2016-06-09 18:15 Christian Didriksson
@ 2016-06-15 10:06 ` Christian Didriksson
2016-06-15 22:36 ` Marek Vasut
0 siblings, 1 reply; 26+ messages in thread
From: Christian Didriksson @ 2016-06-15 10:06 UTC (permalink / raw)
To: u-boot
Trying again.
I have reverted back to a vanilla u-boot-2016.05, added the not-enter-quad-mode patch and changed the SPI address where the SPL should load the u-boot from and it does not work. My question:
Has anyone else tested SPL/u-boot on an Altera CV socdk Rev E1 board recently (like 2016.05)? U-boot hangs after printing memory size. Same result using different compilers.
Best regards,
Christian
-----Ursprungligt meddelande-----
Fr?n: U-Boot [mailto:u-boot-bounces at lists.denx.de] F?r Christian Didriksson
Skickat: den 9 juni 2016 20:15
Till: u-boot at lists.denx.de
?mne: [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI
Hi All,
I have been struggling for quite some time now to get SPL and u-boot to run from QSPI-flash. Yesterday I was able to identify a workaround to get the SPL going by disabling quad mode for the flash (seems identified by http://lists.denx.de/pipermail/u-boot/2016-June/256671.html). However u-boot always hangs after printing memory size. I have tried to search the archive and have seen posts about hanging here, but nothing I can relate to my setup. I have tested to use Altera's SPL (2013.01.01) and u-boot-2016.5 and this combo seems to work.
I also notice that the frequency (max-spi-frequency) in the dts-file is not picked up for some reason?
Any help to fix the u-boot hang problem would be highly appreciated.
Current printout (with added debug output):
U-Boot SPL 2016.05 NGA QSPI -g133f59a-dirty (Jun 09 2016 - 17:06:20)
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
spl_spi_load_image: bus=0, cs=0, speed=50000000, mode=3
cadence_spi_ofdata_to_platdata: regbase=ff705000 ahbbase=ffa00000 max-frequency=500000 page-size=256
spi_flash_std_probe: slave=01100368, cs=0
SF: Read data capture delay calibrated to 7 (0 - 15)
cadence_spi_set_speed: speed=100000
cadence_spi_xfer: len=1 [bytes]
cadence_spi_xfer: len=5 [bytes]
SF: Got idcodes
00000000: 20 ba 20 10 00 . ..
SF: Detected N25Q512
cadence_spi_xfer: len=1 [bytes]
cadence_spi_xfer: len=1 [bytes]
spi_flash_decode_fdt: Cannot decode address
cadence_spi_xfer: len=0 [bytes]
cadence_spi_xfer: len=0 [bytes]
SF: Detected N25Q512 with page size 256 Bytes, erase size 64 KiB, total 64 MiB
SF: Read data capture delay calibrated to 7 (0 - 15)
cadence_spi_set_speed: speed=500000
cadence_spi_xfer: len=5 [bytes]
cadence_spi_xfer: len=64 [bytes]
cadence_spi_xfer: len=5 [bytes]
cadence_spi_xfer: len=443714 [bytes]
U-Boot 2016.05 NGA QSPI -g133f59a-dirty (Jun 09 2016 - 17:06:20 +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
Best regards,
Christian
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
^ permalink raw reply [flat|nested] 26+ messages in thread
* [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI
@ 2016-06-09 18:15 Christian Didriksson
2016-06-15 10:06 ` Christian Didriksson
0 siblings, 1 reply; 26+ messages in thread
From: Christian Didriksson @ 2016-06-09 18:15 UTC (permalink / raw)
To: u-boot
Hi All,
I have been struggling for quite some time now to get SPL and u-boot to run from QSPI-flash. Yesterday I was able to identify a workaround to get the SPL going by disabling quad mode for the flash (seems identified by http://lists.denx.de/pipermail/u-boot/2016-June/256671.html). However u-boot always hangs after printing memory size. I have tried to search the archive and have seen posts about hanging here, but nothing I can relate to my setup. I have tested to use Altera's SPL (2013.01.01) and u-boot-2016.5 and this combo seems to work.
I also notice that the frequency (max-spi-frequency) in the dts-file is not picked up for some reason?
Any help to fix the u-boot hang problem would be highly appreciated.
Current printout (with added debug output):
U-Boot SPL 2016.05 NGA QSPI -g133f59a-dirty (Jun 09 2016 - 17:06:20)
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
spl_spi_load_image: bus=0, cs=0, speed=50000000, mode=3
cadence_spi_ofdata_to_platdata: regbase=ff705000 ahbbase=ffa00000 max-frequency=500000 page-size=256
spi_flash_std_probe: slave=01100368, cs=0
SF: Read data capture delay calibrated to 7 (0 - 15)
cadence_spi_set_speed: speed=100000
cadence_spi_xfer: len=1 [bytes]
cadence_spi_xfer: len=5 [bytes]
SF: Got idcodes
00000000: 20 ba 20 10 00 . ..
SF: Detected N25Q512
cadence_spi_xfer: len=1 [bytes]
cadence_spi_xfer: len=1 [bytes]
spi_flash_decode_fdt: Cannot decode address
cadence_spi_xfer: len=0 [bytes]
cadence_spi_xfer: len=0 [bytes]
SF: Detected N25Q512 with page size 256 Bytes, erase size 64 KiB, total 64 MiB
SF: Read data capture delay calibrated to 7 (0 - 15)
cadence_spi_set_speed: speed=500000
cadence_spi_xfer: len=5 [bytes]
cadence_spi_xfer: len=64 [bytes]
cadence_spi_xfer: len=5 [bytes]
cadence_spi_xfer: len=443714 [bytes]
U-Boot 2016.05 NGA QSPI -g133f59a-dirty (Jun 09 2016 - 17:06:20 +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
Best regards,
Christian
^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2016-06-29 7:03 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-06-21 15:30 [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI Christian Didriksson
2016-06-21 17:07 ` Marek Vasut
2016-06-21 19:22 ` Christian Didriksson
2016-06-22 16:37 ` Christian Didriksson
2016-06-23 13:07 ` Marek Vasut
2016-06-23 15:58 ` Sylvain Lesne
2016-06-23 16:14 ` Marek Vasut
2016-06-23 16:31 ` Sylvain Lesne
2016-06-23 18:42 ` Marek Vasut
2016-06-27 9:10 ` Christian Didriksson
2016-06-27 9:38 ` Sylvain Lesne
2016-06-27 10:43 ` Christian Didriksson
-- strict thread matches above, loose matches on Subject: below --
2016-06-09 18:15 Christian Didriksson
2016-06-15 10:06 ` Christian Didriksson
2016-06-15 22:36 ` Marek Vasut
2016-06-16 10:13 ` Christian Didriksson
2016-06-16 13:32 ` Marek Vasut
2016-06-17 14:39 ` Christian Didriksson
2016-06-17 14:48 ` Marek Vasut
2016-06-20 13:22 ` Christian Didriksson
2016-06-20 13:43 ` Marek Vasut
2016-06-20 16:04 ` Christian Didriksson
2016-06-20 20:22 ` Marek Vasut
2016-06-21 7:32 ` Christian Didriksson
2016-06-29 7:03 ` Pavel Machek
2016-06-17 16:45 ` Dinh Nguyen
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.