[U-Boot] Newbie SPL question for socfpga_sockit

Marek Vasut
2016-03-04T19:03:21Z

On 03/04/2016 05:06 PM, Dinh Nguyen wrote:
> On 03/02/2016 05:24 PM, Marek Vasut wrote:
>> On 03/03/2016 12:08 AM, Dinh Nguyen wrote:
>>> On 03/02/2016 04:54 PM, Dinh Nguyen wrote:
>>>> CC: Marek Vasut
>>>>
>>>> On 03/01/2016 08:40 PM, George Broz wrote:
>>>>> On 17 February 2016 at 18:45, Phil Reid <preid@electromag.com.au> wrote:
>>>>>> G'day George
>>>>>>
>>>>>>
>>>>>> On 18/02/2016 5:54 AM, George Broz wrote:
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> Sorry for the newbie question...
>>>>>>>
>>>>>>> I have an Altera/Terasic board (socfpga_sockit) that has issues
>>>>>>> recognizing
>>>>>>> USB storage devices (roughly 60% good / 40% bad):
>>>>>>>
>>>>>
>>>>>>> If I try a later release (e.g. v2016.01 which seems to support the Terasic
>>>>>>> board explicitly) the boot process stops just after loading the SPL.
>>>>>>>
>>>>>>> At this point I have only been changing the u-boot.img component, not the
>>>>>>> SPL (in the a2 partition of the MMC).
>>>>>>>
>>>>>>> The documentation from Altera about generating the SPL seems to require
>>>>>>> using Qsys/Quartus tools which I'd really like to avoid.
>>>>>>>
>>>>>>> I can produce u-boot-spl.bin / u-boot.img from
>>>>>>> make socfpga_sockit_defconfig; make all.
>>>>>>>
>>>>>>> My newbie question ... should be I able to use directly the u-boot-spl.bin
>>>>>>> generated by the build to replace the SPL on the board?
>>>>>>>
>>>>>>
>>>>>> I've just gone thru the process (this week) of getting uboot 2016.01 to boot
>>>>>> on our custom socfpga board.
>>>>>> There where a few issues in getting things going.
>>>>>> If your using the sd card to boot then the current memory layout is not per
>>>>>> the altera documentation.
>>>>>> I had to make the changes below to config to match the altera docs.
>>>>>> Otherwise it hangs just after the SPL.
>>>>>> You also need to use the -dtb image versions with 2016.01 for things to
>>>>>> work.
>>>>>> Again you may need to make sure the uboot device trees match your hardware.
>>>>>> Not all uboot drivers appear to be using the DT as yet.
>>>>>>
>>>>>> Note the SPL is tightly coupled to the board design and potentially the FPGA
>>>>>> image.
>>>>>> If you using bridges or routing HPS resources (eg i2c etc) to the fpga the
>>>>>> SPL configures the muxes.
>>>>>>
>>>>>> There's a script in uboot src at arch\arm\mach-socfpga\qts-filter.sh
>>>>>> That will generate the qts files for you arch.
>>>>>>
>>>>>> I haven't tried the USB stuff as yet.
>>>>>> There are some issues witht eh altera USB port trigger an Over Current event
>>>>>> on device insertation.
>>>>>> They've modified the linux kenerl driver to use external OV current
>>>>>> detection to get around the problem.
>>>>>> My intial workaround was to insert USB device prior to power on.
>>>>>> I haven't looked at the uboot USB driver yet to see what's in there.
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Regards
>>>>>> Phil Reid
>>>>>>
>>>>>>
>>>>>> diff --git a/include/configs/socfpga_common.h
>>>>>> b/include/configs/socfpga_common.h
>>>>>> index a09e906..3a1b59b 100644 (file)
>>>>>> --- a/include/configs/socfpga_common.h
>>>>>> +++ b/include/configs/socfpga_common.h
>>>>>> @@ -357,13 +357,13 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
>>>>>>
>>>>>> /* SPL SDMMC boot support */
>>>>>> #ifdef CONFIG_SPL_MMC_SUPPORT
>>>>>> +#define CONFIG_SPL_LIBDISK_SUPPORT
>>>>>> #if defined(CONFIG_SPL_FAT_SUPPORT) || defined(CONFIG_SPL_EXT_SUPPORT)
>>>>>> #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 2
>>>>>> #define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME "u-boot-dtb.img"
>>>>>> -#define CONFIG_SPL_LIBDISK_SUPPORT
>>>>>> #else
>>>>>> -#define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 3
>>>>>> -#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR 0xa00 /* offset 2560 sect
>>>>>> (1M+256k) */
>>>>>> +#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION 3
>>>>>> +#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR 0x200
>>>>>> #define CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS 800 /* 400 KB */
>>>>>> #endif
>>>>>> #endif
>>>>>>
>>>>>>
>>>>>
>>>>> Thanks, Phil!
>>>>>
>>>>> Sorry for the delayed response - got called away, but am back to this
>>>>> now. I patched
>>>>> socfpga_common.h and re-built the project. I picked up
>>>>> spl/u-boot-spl-dtb.sfp and
>>>>> u-boot-dtb.img and transferred them to the SD card with:
>>>>>
>>>>> dd if=u-boot-spl-dtb.sfp of=/dev/sdf3 bs=64k seek=0
>>>>> dd if=u-boot-dtb.img of=/dev/sdf3 bs=64k seek=4
>>>>>
>>>>
>>>> You can just do a 'make u-boot-with-spl.sfp' and burn the
>>>> u-boot-with-spl.sfp file straight to the a2 partition, or sdf3.
>>>>
>>>>> Tried this with both the original DT set (socfpga.dtsi, socfpga_cyclone.dtsi,
>>>>> socfpga_cyclone5_sockit.dts) that came with the u-boot v2016.01 download and
>>>>> also an Altera-patched DT set that I've used to boot into Linux numerous times.
>>>>>
>>>>> When I start up the board I get:
>>>>>
>>>>> U-Boot SPL 2016.01 (Mar 01 2016 - 17:28:14)
>>>>> drivers/ddr/altera/sequencer.c: Preparing to start memory calibration
>>>>> drivers/ddr/altera/sequencer.c: CALIBRATION FAILED
>>>>> drivers/ddr/altera/sequencer.c: Calibration complete
>>>>> SDRAM calibration failed.
>>>>> ### ERROR ### Please RESET the board ###
>>>>>
>>>>> I'm not a Quartus user, so I haven't done anything with the
>>>>> qts-filter.sh script you
>>>>> mentioned. Do I need to? I don't have any custom FPGA logic - it's
>>>>> just the Terasic
>>>>> board out of the box.
>>>>>
>>>>
>>>> I just tested U-Boot(v2016.03-rc3) and USB is not working on the devkit
>>>> or sockit. It's failing to detect my mass storage device.
>>>>
>>>> Debugging...
>>>>
>>>
>>> Sorry, I mis-spoke for the sockit. I have to turn dcache off for USB to
>>> work reliably.
>>>
>>> => dcache off
>>> => usb start
>>> starting USB...
>>> USB0: Core Release: 2.93a
>>> scanning bus 0 for devices... 2 USB Device(s) found
>>> => usb tree
>>> USB device tree:
>>> 1 Hub (480 Mb/s, 0mA)
>>> | U-Boot Root Hub
>>> |
>>> +-2 Mass Storage (480 Mb/s, 200mA)
>>> SanDisk Firebird USB Flash Drive 4C532000040115111005
>>>
>>> => version
>>>
>>> U-Boot 2016.03-rc3 (Mar 02 2016 - 17:00:25 -0600)
>>
>> Well, that's our usual USB/QSPI cache issue that's tormenting your soul.
>> CCing Chin ;-)
>>
>> Does the issue by any chance magically disappear if you apply this patch:
>>
>> diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
>> index 026e7ef..06802c6 100644
>> --- a/arch/arm/include/asm/system.h
>> +++ b/arch/arm/include/asm/system.h
>> @@ -274,7 +274,7 @@ static inline void set_dacr(unsigned int val)
>>
>> /* options available for data cache on each page */
>> enum dcache_option {
>> - DCACHE_OFF = TTB_SECT_DOMAIN(0) | TTB_SECT_XN_MASK | TTB_SECT,
>> + DCACHE_OFF = TTB_SECT_S_MASK | TTB_SECT_DOMAIN(0) |
>> TTB_SECT_XN_MASK | TTB_SECT,
>> DCACHE_WRITETHROUGH = DCACHE_OFF | TTB_SECT_C_MASK,
>> DCACHE_WRITEBACK = DCACHE_WRITETHROUGH | TTB_SECT_B_MASK,
>> DCACHE_WRITEALLOC = DCACHE_WRITEBACK | TTB_SECT_TEX(1),
>>
>
> Yes, this patch fixes USB with dcache left on.

Except that it doesn't fix anything, it just makes the system slower by
setting the S bit :-/ So this is not a fix :-(

Best regards,
Marek Vasut