From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Thu, 23 Jun 2016 20:42:28 +0200 Subject: [U-Boot] socfpga 2016.05, CV socdk Rev E1, SPL and u-boot fail when booting from QSPI In-Reply-To: <576C0EE6.6030709@alse-fr.com> References: <576BDEFD.6050204@denx.de> <576C0733.3080603@alse-fr.com> <576C0AE3.6050702@denx.de> <576C0EE6.6030709@alse-fr.com> Message-ID: <576C2D94.1000400@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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