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

[Sylvain Lesne <lesne@alse-fr.com>]

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
>>
>
>