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 <[email protected]> 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 _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
