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