[U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI

Marek Vasut marex at denx.de
Thu Jun 23 20:42:28 CEST 2016


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


More information about the U-Boot mailing list