[U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI
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 sinceremoved,
* so environmental variables in NOR flash is notavailble
* until board_init() is called below to remap IFC tohigh
* 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
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 sinceremoved,
* so environmental variables in NOR flash is notavailble
* until board_init() is called below to remap IFC tohigh
* 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.
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
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
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@ff704000: 0 In: serial Out: serial Err: serial Model: Altera SOCFPGA Cyclone V SoC Development Kit Net: eth0: ethernet@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
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@ff704000: 0 In: serial Out: serial Err: serial Model: Altera SOCFPGA Cyclone V SoC Development Kit Net: eth0: ethernet@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 at 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=d31e9c575f24f4b7f5f382ccae70d7a8... [3]: http://git.denx.de/?p=u-boot.git;a=commit;h=1254667689a5a4accc149fef6ff69da7...
Hope this helps, Sylvain
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@ff704000: 0 In: serial Out: serial Err: serial Model: Altera SOCFPGA Cyclone V SoC Development Kit Net: eth0: ethernet@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.
Hope this helps, Sylvain
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@ff704000: 0 In: serial Out: serial Err: serial Model: Altera SOCFPGA Cyclone V SoC Development Kit Net: eth0: ethernet@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.
[2]:
http://git.denx.de/?p=u-boot.git;a=commit;h=d31e9c575f24f4b7f5f382ccae70d7a8...
[3]:
http://git.denx.de/?p=u-boot.git;a=commit;h=1254667689a5a4accc149fef6ff69da7...
Hope this helps, Sylvain
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@ff704000: 0 In: serial Out: serial Err: serial Model: Altera SOCFPGA Cyclone V SoC Development Kit Net: eth0: ethernet@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.
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@ff704000: 0 In: serial Out: serial Err: serial Model: Altera SOCFPGA Cyclone V SoC Development Kit Net: eth0: ethernet@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
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@ff704000: 0 In: serial Out: serial Err: serial Model: Altera SOCFPGA Cyclone V SoC Development Kit Net: eth0: ethernet@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=5c411d88be8df5f6a8a1ea0c961f7c35... http://git.denx.de/?p=u-boot.git;a=commit;h=abeb272d22217481c214495818c3ceab... http://git.denx.de/?p=u-boot.git;a=commit;h=3191d8408053674c1b9bb79a82e3973a...
Best regards, Sylvain
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@ff704000: 0 > In: serial > Out: serial > Err: serial > Model: Altera SOCFPGA Cyclone V SoC Development Kit > Net: eth0: ethernet@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@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@ff702000 Hit any key to stop autoboot: 0 => -----------------8<-----------------8<----------------
Best regards, Sylvain
Best regards, Christian
participants (3)
-
Christian Didriksson -
Marek Vasut -
Sylvain Lesne