[U-Boot] Newbie SPL question for socfpga_sockit

[U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

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

SOCFPGA_CYCLONE5 # usb start
(Re)start USB...
USB0: scanning bus 0 for devices... DW_USB: Transfer completion
interrupt timeout
Timed out waiting for channel to disable
1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found


The pre-made U-Boot SPL & image that come with the board have version:
U-Boot 2013.01.01 (Aug 08 2014 - 10:46:23)

(Old!)

I need to rebuild U-Boot for this board to add md5sum and hopefully fix the
USB issues. When I've rebuilt the u-boot.img from the 2013.01.01 branch
of the (Altera maintained) source, U-boot boots, but the USB problems
get worse (100% bad):

USB0: Core Release: 2.93a
dwc_otg_core_host_init: Unable to clear halt on channel 1 (timeout
HCCHAR 0xC0000000 @ffb40520)
dwc_otg_core_host_init: Unable to clear halt on channel 2 (timeout
HCCHAR 0xC0000000 @ffb40540

(I've confirmed that CONFIG_CMD_USB and CONFIG_USB_STORAGE are
defined and have tried turning on and off 'dcache' as suggested elsewhere
to no avail).

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'm hoping the USB issues resolve themselves when I'm able to get
the later version of U-Boot running...)


Thanks for any input...

--George Broz
Moog Industrial Group

[U-Boot] Newbie SPL question for socfpga_sockit

[Phil Reid]

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):
>
> SOCFPGA_CYCLONE5 # usb start
> (Re)start USB...
> USB0: scanning bus 0 for devices... DW_USB: Transfer completion
> interrupt timeout
> Timed out waiting for channel to disable
> 1 USB Device(s) found
> scanning usb for storage devices... 0 Storage Device(s) found
>
>
> The pre-made U-Boot SPL & image that come with the board have version:
> U-Boot 2013.01.01 (Aug 08 2014 - 10:46:23)
>
> (Old!)
>
> I need to rebuild U-Boot for this board to add md5sum and hopefully fix the
> USB issues. When I've rebuilt the u-boot.img from the 2013.01.01 branch
> of the (Altera maintained) source, U-boot boots, but the USB problems
> get worse (100% bad):
>
> USB0: Core Release: 2.93a
> dwc_otg_core_host_init: Unable to clear halt on channel 1 (timeout
> HCCHAR 0xC0000000 @ffb40520)
> dwc_otg_core_host_init: Unable to clear halt on channel 2 (timeout
> HCCHAR 0xC0000000 @ffb40540
>
> (I've confirmed that CONFIG_CMD_USB and CONFIG_USB_STORAGE are
> defined and have tried turning on and off 'dcache' as suggested elsewhere
> to no avail).
>
> 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'm hoping the USB issues resolve themselves when I'm able to get
> the later version of U-Boot running...)
>

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

[U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

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

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.

Thanks for any help!

--George Broz
Moog Industrial Group

[U-Boot] Newbie SPL question for socfpga_sockit

[Phil Reid]

On 2/03/2016 10:40 AM, George Broz wrote:

> 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
>
> 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.
>
> Thanks for any help!
>

Even without the custom FPGA logic the files generated from qts-filter.sh need to match your board.
Sets up PLL and SDRAM parameters.
I'm not familiar with the Terasic dev board ( I do have the altera devkit, but haven't used it for awhile).
I'd hope the files in the git repo are correct for your board.
Without the corresponding qsys project it's hard to be sure.

The sd card write commands look correct.
I just used a dts files in the uboot source but modified a couple of things.
Update Mem size and serial port speeds to match our requirements.

I also modified a few debug statements so the spl outputs a bit more info by default.
Output is alot closer to the altera supplied uboot tree.

My spl bootup is:

U-Boot SPL 2016.01-00003-g40d1cd2 (Mar 01 2016 - 15:29:44)
CLOCK: MPU           800000 kHz
CLOCK: DDR           400000 kHz
CLOCK: EOSC1          50000 kHz
CLOCK: EOSC2          50000 kHz
CLOCK: F2S_SDR_REF        0 kHz
CLOCK: F2S_PER_REF        0 kHz
CLOCK: MMC            50000 kHz
CLOCK: QSPI          400000 kHz
CLOCK: UART          100000 kHz
CLOCK: SPI           200000 kHz
INFO: Changing address order to 2 (row, chip, bank, column)
SDRAM: Calibrating PHY
SDRAM: Preparing to start memory calibration
SDRAM: CALIBRATION PASSED
SDRAM: Calibration complete
SDRAM: 2048 MiB
Trying to boot from MMC


U-Boot 2016.01-00003-g40d1cd2 (Mar 01 2016 - 15:29:44 +0800)


Marek who committed the terasic config may be able to help.
It most likely a mismatch in the qts config vs hardware.


-- 
Regards
Phil Reid

ElectroMagnetic Imaging Technology Pty Ltd
Development of Geophysical Instrumentation & Software
www.electromag.com.au

3 The Avenue, Midland WA 6056, AUSTRALIA
Ph: +61 8 9250 8100
Fax: +61 8 9250 7100
Email: preid at electromag.com.au

[U-Boot] Newbie SPL question for socfpga_sockit

[Dinh Nguyen]

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

Dinh

[U-Boot] Newbie SPL question for socfpga_sockit

[Marek Vasut]

On 03/02/2016 11: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...

Try dcache off ... does it work ?

-- 
Best regards,
Marek Vasut

[U-Boot] Newbie SPL question for socfpga_sockit

[Dinh Nguyen]

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)

Dinh

[U-Boot] Newbie SPL question for socfpga_sockit

[Marek Vasut]

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

?

-- 
Best regards,
Marek Vasut

[U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 1 March 2016 at 19:49, Phil Reid <preid@electromag.com.au> wrote:
> On 2/03/2016 10:40 AM, George Broz wrote:
>
>> 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
>>
>> 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.
>>
>> Thanks for any help!
>>
>
> Even without the custom FPGA logic the files generated from qts-filter.sh
> need to match your board.
> Sets up PLL and SDRAM parameters.
> I'm not familiar with the Terasic dev board ( I do have the altera devkit,
> but haven't used it for awhile).
> I'd hope the files in the git repo are correct for your board.
> Without the corresponding qsys project it's hard to be sure.
>
Hi Phil,

So as my next attempt, there was a Quartus/Qsys example that came
with the Terasic board (specific to my Rev. of the board).

* I took the contents of the 'handoff folder', .sof, and .sopcinfo file.
* launched an "Embedded Command Shell" from EDS 15.0 and then the BSP editor GUI
* pointed the BSP editor to the "handoff folder", and hit "Generate"
to produce iocsr, pinmux, pll, etc. files
* applied qts-filter.sh to these files, the output of which I then
dropped into the u-boot source @ ../board/terasic/sockit/qts
* rebuilt uboot spl & image, but got a similar result:

U-Boot SPL 2016.01 (Mar 02 2016 - 22:13:31)
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 ###

Except now it repeats four times, whereas before it only printed out once.

It that essentially the correct procedure? Is it now a matter of
looking through
the include files that where generated by qts-filter.sh to find a
setting that is "off"?

(BTW - my first attempt was to use EDS 13.0, but that resulted in
several undefined macros when it
came time to compile u-boot with the qts-filter-generated code. How
does one know which tool version to use?)

Thanks,
--George

> The sd card write commands look correct.
> I just used a dts files in the uboot source but modified a couple of things.
> Update Mem size and serial port speeds to match our requirements.
>
> I also modified a few debug statements so the spl outputs a bit more info by
> default.
> Output is alot closer to the altera supplied uboot tree.
>
> My spl bootup is:
>
> U-Boot SPL 2016.01-00003-g40d1cd2 (Mar 01 2016 - 15:29:44)
> CLOCK: MPU           800000 kHz
> CLOCK: DDR           400000 kHz
> CLOCK: EOSC1          50000 kHz
> CLOCK: EOSC2          50000 kHz
> CLOCK: F2S_SDR_REF        0 kHz
> CLOCK: F2S_PER_REF        0 kHz
> CLOCK: MMC            50000 kHz
> CLOCK: QSPI          400000 kHz
> CLOCK: UART          100000 kHz
> CLOCK: SPI           200000 kHz
> INFO: Changing address order to 2 (row, chip, bank, column)
> SDRAM: Calibrating PHY
> SDRAM: Preparing to start memory calibration
> SDRAM: CALIBRATION PASSED
> SDRAM: Calibration complete
> SDRAM: 2048 MiB
> Trying to boot from MMC
>
>
> U-Boot 2016.01-00003-g40d1cd2 (Mar 01 2016 - 15:29:44 +0800)
>
>
> Marek who committed the terasic config may be able to help.
> It most likely a mismatch in the qts config vs hardware.
>
>
> --
> Regards
> Phil Reid
>
> ElectroMagnetic Imaging Technology Pty Ltd
> Development of Geophysical Instrumentation & Software
> www.electromag.com.au
>
> 3 The Avenue, Midland WA 6056, AUSTRALIA
> Ph: +61 8 9250 8100
> Fax: +61 8 9250 7100
> Email: preid at electromag.com.au

[U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 2 March 2016 at 14:54, Dinh Nguyen <dinguyen@opensource.altera.com> wrote:

>> 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.
>
Thanks, Dinh. That's a time saver.

On my version that target is: 'make u-boot-with-spl-dtb.sfp'

Thanks,
--George

[U-Boot] Newbie SPL question for socfpga_sockit

[Phil Reid]

On 3/03/2016 2:49 PM, George Broz wrote:
> On 1 March 2016 at 19:49, Phil Reid <preid@electromag.com.au> wrote:
>> On 2/03/2016 10:40 AM, George Broz wrote:
>>
>>> 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
>>>
>>> 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.
>>>
>>> Thanks for any help!
>>>
>>
>> Even without the custom FPGA logic the files generated from qts-filter.sh
>> need to match your board.
>> Sets up PLL and SDRAM parameters.
>> I'm not familiar with the Terasic dev board ( I do have the altera devkit,
>> but haven't used it for awhile).
>> I'd hope the files in the git repo are correct for your board.
>> Without the corresponding qsys project it's hard to be sure.
>>
> Hi Phil,
>
> So as my next attempt, there was a Quartus/Qsys example that came
> with the Terasic board (specific to my Rev. of the board).
>
> * I took the contents of the 'handoff folder', .sof, and .sopcinfo file.
> * launched an "Embedded Command Shell" from EDS 15.0 and then the BSP editor GUI
> * pointed the BSP editor to the "handoff folder", and hit "Generate"
> to produce iocsr, pinmux, pll, etc. files
> * applied qts-filter.sh to these files, the output of which I then
> dropped into the u-boot source @ ../board/terasic/sockit/qts
> * rebuilt uboot spl & image, but got a similar result:
>
> U-Boot SPL 2016.01 (Mar 02 2016 - 22:13:31)
> 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 ###
>
> Except now it repeats four times, whereas before it only printed out once.
>
> It that essentially the correct procedure? Is it now a matter of
> looking through
> the include files that where generated by qts-filter.sh to find a
> setting that is "off"?
>
> (BTW - my first attempt was to use EDS 13.0, but that resulted in
> several undefined macros when it
> came time to compile u-boot with the qts-filter-generated code. How
> does one know which tool version to use?)
>

What does a diff of the new files show compared to the ones in uboot.
I'm using the Quartus 15.0 tool chain at the moment.
Turning on debugging in drivers/ddr/altera/sequencer.c may help.


-- 
Regards
Phil Reid

[U-Boot] Newbie SPL question for socfpga_sockit

[Marek Vasut]

On 03/03/2016 07:55 AM, George Broz wrote:
> On 2 March 2016 at 14:54, Dinh Nguyen <dinguyen@opensource.altera.com> wrote:
> 
>>> 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.
>>
> Thanks, Dinh. That's a time saver.
> 
> On my version that target is: 'make u-boot-with-spl-dtb.sfp'

This was changed after 2016.01 was out by the following patch:

commit bd7dc3883bf4e61538e5519ca2d6798b3e8e0695
Author: Simon Glass <sjg@chromium.org>
Date:   Sun Jan 31 18:10:53 2016 -0700

    socfpga: Simplify Makefile filenames

-- 
Best regards,
Marek Vasut

[U-Boot] Newbie SPL question for socfpga_sockit

[Dinh Nguyen]

On 03/02/2016 05:24 PM, Marek Vasut wrote:
> 
> 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),
> 

I'm away from my office today and don't have access to the sockit. I can
test this tomorrow.

But what's interesting is that I have the DE0-NANO-SOCKIT board at home,
and USB seems to be working fine with dcache on.

Dinh

[U-Boot] Newbie SPL question for socfpga_sockit

[Marek Vasut]

On 03/03/2016 03:48 PM, Dinh Nguyen wrote:
> 
> 
> On 03/02/2016 05:24 PM, Marek Vasut wrote:
>>
>> 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),
>>
> 
> I'm away from my office today and don't have access to the sockit. I can
> test this tomorrow.
> 
> But what's interesting is that I have the DE0-NANO-SOCKIT board at home,
> and USB seems to be working fine with dcache on.

Yeah, the USB issue happens only with some stick :-/


-- 
Best regards,
Marek Vasut

[U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 2 March 2016 at 23:11, Phil Reid <preid@electromag.com.au> wrote:
> On 3/03/2016 2:49 PM, George Broz wrote:
>>
>> On 1 March 2016 at 19:49, Phil Reid <preid@electromag.com.au> wrote:
>>>
>>> On 2/03/2016 10:40 AM, George Broz wrote:
>>>
>>>> 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
>>>>
>>>> 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.
>>>>
>>>> Thanks for any help!
>>>>
>>>
>>> Even without the custom FPGA logic the files generated from qts-filter.sh
>>> need to match your board.
>>> Sets up PLL and SDRAM parameters.
>>> I'm not familiar with the Terasic dev board ( I do have the altera
>>> devkit,
>>> but haven't used it for awhile).
>>> I'd hope the files in the git repo are correct for your board.
>>> Without the corresponding qsys project it's hard to be sure.
>>>
>> Hi Phil,
>>
>> So as my next attempt, there was a Quartus/Qsys example that came
>> with the Terasic board (specific to my Rev. of the board).
>>
>> * I took the contents of the 'handoff folder', .sof, and .sopcinfo file.
>> * launched an "Embedded Command Shell" from EDS 15.0 and then the BSP
>> editor GUI
>> * pointed the BSP editor to the "handoff folder", and hit "Generate"
>> to produce iocsr, pinmux, pll, etc. files
>> * applied qts-filter.sh to these files, the output of which I then
>> dropped into the u-boot source @ ../board/terasic/sockit/qts
>> * rebuilt uboot spl & image, but got a similar result:
>>
>> U-Boot SPL 2016.01 (Mar 02 2016 - 22:13:31)
>> 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 ###
>>
>> Except now it repeats four times, whereas before it only printed out once.
>>
>> It that essentially the correct procedure? Is it now a matter of
>> looking through
>> the include files that where generated by qts-filter.sh to find a
>> setting that is "off"?
>>
>> (BTW - my first attempt was to use EDS 13.0, but that resulted in
>> several undefined macros when it
>> came time to compile u-boot with the qts-filter-generated code. How
>> does one know which tool version to use?)
>>
>
> What does a diff of the new files show compared to the ones in uboot.

Here's two of them...

--- /home/mcis/altera/uboot-native/u-boot-socfpga-2016.01/board/terasic/sockit/qts/sdram_config.h.orig
+++ /home/mcis/altera/uboot-native/u-boot-socfpga-2016.01/board/terasic/sockit/qts/sdram_config.h

@@ -33,10 +33,10 @@
 #define CONFIG_HPS_SDR_CTRLCFG_DRAMODT_WRITE 1
 #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_AL 0
 #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TCL 7
-#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TCWL 6
-#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TFAW 12
-#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TRFC 104
-#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TRRD 4
+#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TCWL 7
+#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TFAW 15
+#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TRFC 120
+#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TRRD 3
 #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING2_IF_TRCD 6
 #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING2_IF_TREFI 3120
 #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING2_IF_TRP 6

@@ -46,12 +46,12 @@
 #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING3_TMRD 4
 #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING3_TRAS 14
 #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING3_TRC 20
-#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING3_TRTP 4
+#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING3_TRTP 3
 #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING4_PWRDOWNEXIT 3
 #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING4_SELFRFSHEXIT 512
 #define CONFIG_HPS_SDR_CTRLCFG_FIFOCFG_INCSYNC 0
 #define CONFIG_HPS_SDR_CTRLCFG_FIFOCFG_SYNCMODE 0
-#define CONFIG_HPS_SDR_CTRLCFG_FPGAPORTRST 0x1FF
+#define CONFIG_HPS_SDR_CTRLCFG_FPGAPORTRST 0x0
 #define CONFIG_HPS_SDR_CTRLCFG_LOWPWREQ_SELFRFSHMASK 3
 #define CONFIG_HPS_SDR_CTRLCFG_LOWPWRTIMING_AUTOPDCYCLES 0
 #define CONFIG_HPS_SDR_CTRLCFG_LOWPWRTIMING_CLKDISABLECYCLES 8

@@ -147,7 +147,7 @@
 #define IO_SHIFT_DQS_EN_WHEN_SHIFT_DQS 0
 #define MAX_LATENCY_COUNT_WIDTH 5
 #define READ_VALID_FIFO_SIZE 16
-#define REG_FILE_INIT_SEQ_SIGNATURE 0x5555048d
+#define REG_FILE_INIT_SEQ_SIGNATURE 0x5555048c
 #define RW_MGR_MEM_ADDRESS_MIRRORING 0
 #define RW_MGR_MEM_DATA_MASK_WIDTH 4
 #define RW_MGR_MEM_DATA_WIDTH 32

@@ -168,19 +168,20 @@

 #define TRESET_CNTR2_VAL 10
 /* Sequencer ac_rom_init configuration */
-const u32 ac_rom_init[] = {
+const u32 ac_rom_init[] =
+{
  0x20700000,
  0x20780000,
  0x10080431,
  0x10080530,
  0x10090044,
- 0x100a0008,
+ 0x100a0010,
  0x100b0000,
  0x10380400,
  0x10080449,
  0x100804c8,
  0x100a0024,
- 0x10090010,
+ 0x10090008,
  0x100b0000,
  0x30780000,
  0x38780000,

@@ -208,7 +209,8 @@
 };


 /* Sequencer inst_rom_init configuration */
-const u32 inst_rom_init[] = {
+const u32 inst_rom_init[] =
+{
  0x80000,
  0x80680,
  0x8180,

--- /home/mcis/altera/uboot-native/u-boot-socfpga-2016.01/board/terasic/sockit/qts/pll_config.h.orig
+++ /home/mcis/altera/uboot-native/u-boot-socfpga-2016.01/board/terasic/sockit/qts/pll_config.h
@@ -16,7 +16,7 @@
 #define CONFIG_HPS_MAINPLLGRP_DBGATCLK_CNT 0
 #define CONFIG_HPS_MAINPLLGRP_MAINQSPICLK_CNT 4
 #define CONFIG_HPS_MAINPLLGRP_MAINNANDSDMMCCLK_CNT 511
-#define CONFIG_HPS_MAINPLLGRP_CFGS2FUSER0CLK_CNT 14
+#define CONFIG_HPS_MAINPLLGRP_CFGS2FUSER0CLK_CNT 18
 #define CONFIG_HPS_MAINPLLGRP_MAINDIV_L3MPCLK 1
 #define CONFIG_HPS_MAINPLLGRP_MAINDIV_L3SPCLK 1
 #define CONFIG_HPS_MAINPLLGRP_MAINDIV_L4MPCLK 1


> I'm using the Quartus 15.0 tool chain at the moment.
> Turning on debugging in drivers/ddr/altera/sequencer.c may help.
>

Setting DLEVEL = 2 yields:

U-Boot SPL 2016.01 (Mar 03 2016 - 06:28:33)
drivers/ddr/altera/sequencer.c: Preparing to start memory calibration
find_vfifo_failing_read:1519: vfifo 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
find_vfifo_failing_read:1519: vfifo 1
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1864 p: ptap=4
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1877 p/d: ptap=4 dtap=7 end=16399
rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1887 found range [14003,16399]
rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1895 calculate
dtaps_per_ptap for tracking
rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1906 backedup phase only:
p=3rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1919 find passing read
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1927 find failing read
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1948 dtaps_per_ptap=21 -
8 = 13work_bgn=14003 work_end=16399 work_mid=15201
vfifo ptap delay 2496
new work_mid 225
new p 0, tmp_delay=0
new d 9, tmp_delay=225
find_dqs_en_phase: center
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
sdr_find_window_center:1779 center: found: ptap=0 dtap=9
rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0) => 1
search_stop_check:2006 center(left): dtap=0 => 255 == 255 &&
0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
=> 1
search_stop_check:2006 center(left): dtap=1 => 255 == 255 &&
0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
=> 1
search_stop_check:2006 center(left): dtap=2 => 255 == 255 &&
0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
=> 1
search_stop_check:2006 center(left): dtap=3 => 255 == 255 &&
0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
=> 1
search_stop_check:2006 center(left): dtap=4 => 255 == 255 &&
0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
=> 1
search_stop_check:2006 center(left): dtap=5 => 255 == 255 &&
0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
=> 1
search_stop_check:2006 center(left): dtap=6 => 255 == 255 &&
0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
=> 1
search_stop_check:2006 center(left): dtap=7 => 255 == 255 &&
0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
=> 1
search_stop_check:2006 center(left): dtap=8 => 255 == 255 &&
0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
=> 1
search_stop_check:2006 center(left): dtap=9 => 255 == 255 &&
0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
=> 1
search_stop_check:2006 center(left): dtap=10 => 255 == 255 &&
0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
=> 1
search_stop_check:2006 center(left): dtap=11 => 255 == 255 &&
0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
=> 1
search_stop_check:2006 center(left): dtap=12 => 255 == 255 &&
0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
=> 1
search_stop_check:2006 center(left): dtap=13 => 255 == 255 &&
0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
=> 1
search_stop_check:2006 center(left): dtap=14 => 255 == 255 &&
0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
=> 1
search_stop_check:2006 center(left): dtap=15 => 255 == 255 &&
0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (187 != 0)
=> 1
search_stop_check:2006 center(left): dtap=16 => 255 == 255 &&
0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (179 != 0)
=> 1
search_stop_check:2006 center(left): dtap=17 => 255 == 255 &&
0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (19 != 0)
=> 1
search_stop_check:2006 center(left): dtap=18 => 255 == 255 &&
0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (17 != 0)
=> 1
search_stop_check:2006 center(left): dtap=19 => 255 == 255 &&
0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (16 != 0)
=> 1
search_stop_check:2006 center(left): dtap=20 => 255 == 255 &&
0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) =>
0
search_stop_check:2006 center(left): dtap=21 => 255 == 255 &&?

Will try to make sense of these today...

Any insights welcome!

Thanks,
--George

>
> --
> Regards
> Phil Reid
>

[U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 2 March 2016 at 23:11, Phil Reid <preid@electromag.com.au> wrote:
> On 3/03/2016 2:49 PM, George Broz wrote:
>>
>> On 1 March 2016 at 19:49, Phil Reid <preid@electromag.com.au> wrote:
>>>
>>> On 2/03/2016 10:40 AM, George Broz wrote:
>>>
>>>> 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
>>>>
>>>> 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.
>>>>
>>>> Thanks for any help!
>>>>
>>>
>>> Even without the custom FPGA logic the files generated from qts-filter.sh
>>> need to match your board.
>>> Sets up PLL and SDRAM parameters.
>>> I'm not familiar with the Terasic dev board ( I do have the altera
>>> devkit,
>>> but haven't used it for awhile).
>>> I'd hope the files in the git repo are correct for your board.
>>> Without the corresponding qsys project it's hard to be sure.
>>>
>> Hi Phil,
>>
>> So as my next attempt, there was a Quartus/Qsys example that came
>> with the Terasic board (specific to my Rev. of the board).
>>
>> * I took the contents of the 'handoff folder', .sof, and .sopcinfo file.
>> * launched an "Embedded Command Shell" from EDS 15.0 and then the BSP
>> editor GUI
>> * pointed the BSP editor to the "handoff folder", and hit "Generate"
>> to produce iocsr, pinmux, pll, etc. files
>> * applied qts-filter.sh to these files, the output of which I then
>> dropped into the u-boot source @ ../board/terasic/sockit/qts
>> * rebuilt uboot spl & image, but got a similar result:

> What does a diff of the new files show compared to the ones in uboot.
> I'm using the Quartus 15.0 tool chain at the moment.
> Turning on debugging in drivers/ddr/altera/sequencer.c may help.
>
>
> --
> Regards
> Phil Reid
>

If I build the SPL using in the embedded_command_shell environment:

~/altera/15/embedded/embedded_command_shell.sh
cd ~/<to-folder-generated-by-BSP editor>/software/spl_bsp
make

I get a working preloader-mkpimage.bin that seems to work with the
u-boot.img generated from the 2016.01 release:

U-Boot SPL 2013.01.01 (Mar 03 2016 - 08:10:01)
BOARD : Altera SOCFPGA Cyclone V Board
CLOCK: EOSC1 clock 25000 KHz
CLOCK: EOSC2 clock 25000 KHz
CLOCK: F2S_SDR_REF clock 0 KHz
CLOCK: F2S_PER_REF clock 0 KHz
CLOCK: MPU clock 925 MHz
CLOCK: DDR clock 400 MHz
CLOCK: UART clock 100000 KHz
CLOCK: MMC clock 50000 KHz
CLOCK: QSPI clock 370000 KHz
RESET: WARM
INFO : Watchdog enabled
SDRAM: Initializing MMR registers
SDRAM: Calibrating PHY
SEQ.C: Preparing to start memory calibration
SEQ.C: CALIBRATION PASSED
SDRAM: 1024 MiB
ALTERA DWMMC: 0


U-Boot 2016.01 (Mar 03 2016 - 13:02:56 -0800)

CPU:   Altera SoCFPGA Platform
FPGA:  Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0
BOOT:  SD/MMC Internal Transceiver (3.0V)
       Watchdog enabled
I2C:   ready
DRAM:  1 GiB
MMC:   dwmmc0 at ff704000: 0
In:    serial
Out:   serial
Err:   serial
Model: Terasic SoCkit
Net:
Error: ethernet at ff702000 address not set.
No ethernet found.
Hit any key to stop autoboot:  0


That would seem to indicate at least my quartus/qsys project and the files it
generates are valid and that something is amiss with the terasic board
support code?


BTW - if I set DLEVEL=1 in sequencer.c with the 2016.01-generated SPL I get:

U-Boot SPL 2016.01 (Mar 03 2016 - 11:24:11)
scc_mgr_initialize:281: Clearing SCC RFILE index 0
scc_mgr_initialize:281: Clearing SCC RFILE index 1
scc_mgr_initialize:281: Clearing SCC RFILE index 2
scc_mgr_initialize:281: Clearing SCC RFILE index 3
scc_mgr_initialize:281: Clearing SCC RFILE index 4
scc_mgr_initialize:281: Clearing SCC RFILE index 5
scc_mgr_initialize:281: Clearing SCC RFILE index 6
scc_mgr_initialize:281: Clearing SCC RFILE index 7
scc_mgr_initialize:281: Clearing SCC RFILE index 8
scc_mgr_initialize:281: Clearing SCC RFILE index 9
scc_mgr_initialize:281: Clearing SCC RFILE index 10
scc_mgr_initialize:281: Clearing SCC RFILE index 11
scc_mgr_initialize:281: Clearing SCC RFILE index 12
scc_mgr_initialize:281: Clearing SCC RFILE index 13
scc_mgr_initialize:281: Clearing SCC RFILE index 14
scc_mgr_initialize:281: Clearing SCC RFILE index 15

If that's of use to anyone...

Thanks,
--George

[U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 3 March 2016 at 06:51, Marek Vasut <marex@denx.de> wrote:
> On 03/03/2016 03:48 PM, Dinh Nguyen wrote:
>>
>>
>> On 03/02/2016 05:24 PM, Marek Vasut wrote:
>>>
>>> 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),
>>>

The 2016.01 code I'm using already includes this patch. If I try
reading a USB stick with dcache on or off
I get the same result:

=> dcache off
=> usb reset
resetting USB...
USB0:   Core Release: 2.93a
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
scanning bus 0 for devices... 1 USB Device(s) found
=> usb tree
USB device tree:
  1  Hub (480 Mb/s, 0mA)
      U-Boot Root Hub


>>
>> I'm away from my office today and don't have access to the sockit. I can
>> test this tomorrow.
>>
>> But what's interesting is that I have the DE0-NANO-SOCKIT board at home,
>> and USB seems to be working fine with dcache on.
>
> Yeah, the USB issue happens only with some stick :-/

I've tried five different sticks, same result.

--George

>
>
> --
> Best regards,
> Marek Vasut
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Newbie SPL question for socfpga_sockit

[Marek Vasut]

On 03/03/2016 11:00 PM, George Broz wrote:
> On 3 March 2016 at 06:51, Marek Vasut <marex@denx.de> wrote:
>> On 03/03/2016 03:48 PM, Dinh Nguyen wrote:
>>>
>>>
>>> On 03/02/2016 05:24 PM, Marek Vasut wrote:
>>>>
>>>> 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),
>>>>
> 
> The 2016.01 code I'm using already includes this patch. If I try
> reading a USB stick with dcache on or off
> I get the same result:
> 
> => dcache off
> => usb reset
> resetting USB...
> USB0:   Core Release: 2.93a
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout!
> scanning bus 0 for devices... 1 USB Device(s) found
> => usb tree
> USB device tree:
>   1  Hub (480 Mb/s, 0mA)
>       U-Boot Root Hub

This more likely means that either clock or reset bits are not
configured correctly OR you're using the wrong controller. Since
you're mixing old U-Boot SPL with new U-Boot, there can be some
discrepancy and I have no idea how to help you with that :(


Best regards,
Marek Vasut

[U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 3 March 2016 at 15:07, Marek Vasut <marex@denx.de> wrote:

>> On 3 March 2016 at 14:42, Marek Vasut <marex@denx.de> wrote:
>>> On 03/03/2016 11:27 PM, George Broz wrote:
>>>> Hi Marek,
>>>
>>> Hi!
>>>
>>>> Yes - would love to be using the SPL from 2016.01 for the Terasic board,
>>>> but it does not seem to be working for me with the files from the repo or
>>>> with handoff files I supply & run through qts-filter.sh. This is about two
>>>> layers below where my normal expertise is, so any help getting 2016.01
>>>> (or later) SPL working (with the end goal of having working USB) would
>>>> be much appreciated!
>>>
>>> Are you using sockit ? Which revision (it's etched in the PCB from the
>>> bottom, it's not silkscreen but really part of the copper) ? I'll test
>>> it and get back to you. If I happen to forget about it, remind me ;-)
>>>
>>>> Best regards,
>>>> --George Broz
>>>>
>>>>
>>>> On 3 March 2016 at 14:09, Marek Vasut <marex@denx.de> wrote:
>>>>> On 03/03/2016 11:00 PM, George Broz wrote:
>>>>>> On 3 March 2016 at 06:51, Marek Vasut <marex@denx.de> wrote:
>>>>>>> On 03/03/2016 03:48 PM, Dinh Nguyen wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 03/02/2016 05:24 PM, Marek Vasut wrote:
>>>>>>>>>
>>>>>>>>> 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),
>>>>>>>>>
>>>>>>
>>>>>> The 2016.01 code I'm using already includes this patch. If I try
>>>>>> reading a USB stick with dcache on or off
>>>>>> I get the same result:
>>>>>>
>>>>>> => dcache off
>>>>>> => usb reset
>>>>>> resetting USB...
>>>>>> USB0:   Core Release: 2.93a
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> scanning bus 0 for devices... 1 USB Device(s) found
>>>>>> => usb tree
>>>>>> USB device tree:
>>>>>>   1  Hub (480 Mb/s, 0mA)
>>>>>>       U-Boot Root Hub
>>>>>
>>>>> This more likely means that either clock or reset bits are not
>>>>> configured correctly OR you're using the wrong controller. Since
>>>>> you're mixing old U-Boot SPL with new U-Boot, there can be some
>>>>> discrepancy and I have no idea how to help you with that :(
>>>>>
>>>>>
>>>>> Best regards,
>>>>> Marek Vasut
>>>
>>>
>>> --
>>> Best regards,
>>> Marek Vasut

> On 03/03/2016 11:57 PM, George Broz wrote:
>> Yes - using SocKit, revision D (etching is 10-31212180-D0).
>>
>> Thanks - any help is much appreciated!
>
> Try attached patch.
>

Thanks, Marek. The patch applied cleanly, but the end result is the same

(with DLEVEL=1 in sequencer.c) I get
U-Boot SPL 2016.01 (Mar 03 2016 - 15:28:06)
scc_mgr_initialize:281: Clearing SCC RFILE index 0
scc_mgr_initialize:281: Clearing SCC RFILE index 1
scc_mgr_initialize:281: Clearing SCC RFILE index 2
scc_mgr_initialize:281: Clearing SCC RFILE index 3
scc_mgr_initialize:281: Clearing SCC RFILE index 4
scc_mgr_initialize:281: Clearing SCC RFILE index 5
scc_mgr_initialize:281: Clearing SCC RFILE index 6
scc_mgr_initialize:281: Clearing SCC RFILE index 7
scc_mgr_initialize:281: Clearing SCC RFILE index 8
scc_mgr_initialize:281: Clearing SCC RFILE index 9
scc_mgr_initialize:281: Clearing SCC RFILE index 10
scc_mgr_initialize:281: Clearing SCC RFILE index 11
scc_mgr_initialize:281: Clearing SCC RFILE index 12
scc_mgr_initialize:281: Clearing SCC RFILE index 13
scc_mgr_initialize:281: Clearing SCC RFILE index 14
scc_mgr_initialize:281: Clearing SCC RFILE index 15

4x then hang.



>
>> Best regards,
>> --George
>>


>
> --
> Best regards,
> Marek Vasut

[U-Boot] Newbie SPL question for socfpga_sockit

[Dinh Nguyen]

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.

Dinh

[U-Boot] Newbie SPL question for socfpga_sockit

[Dinh Nguyen]

On 03/03/2016 04:09 PM, Marek Vasut wrote:
> On 03/03/2016 11:00 PM, George Broz wrote:
>> On 3 March 2016 at 06:51, Marek Vasut <marex@denx.de> wrote:
>>> On 03/03/2016 03:48 PM, Dinh Nguyen wrote:
>>>>
>>>>
>>>> On 03/02/2016 05:24 PM, Marek Vasut wrote:
>>>>>
>>>>> 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),
>>>>>
>>
>> The 2016.01 code I'm using already includes this patch. If I try
>> reading a USB stick with dcache on or off
>> I get the same result:
>>
>> => dcache off
>> => usb reset
>> resetting USB...
>> USB0:   Core Release: 2.93a
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> scanning bus 0 for devices... 1 USB Device(s) found
>> => usb tree
>> USB device tree:
>>   1  Hub (480 Mb/s, 0mA)
>>       U-Boot Root Hub
> 
> This more likely means that either clock or reset bits are not
> configured correctly OR you're using the wrong controller. Since
> you're mixing old U-Boot SPL with new U-Boot, there can be some
> discrepancy and I have no idea how to help you with that :(
> 

Can you try these steps?

1)Boot up
2)"dcache off"
3)"mw.l 0xffb40440 0x00001000 1"
4)"usb start"

On the devkit, it seems that the USB port power bit is not getting
turned on, so it's failing to detect the USB device. You can probably
ignore stop 2, if you already Marek's patch.

Dinh

[U-Boot] Newbie SPL question for socfpga_sockit

[Marek Vasut]

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

[U-Boot] Newbie SPL question for socfpga_sockit

[Phil Reid]

G'day George,

On 3/03/2016 10:57 PM, George Broz wrote:
> On 2 March 2016 at 23:11, Phil Reid <preid@electromag.com.au> wrote:
>> On 3/03/2016 2:49 PM, George Broz wrote:
>>>
>>> On 1 March 2016 at 19:49, Phil Reid <preid@electromag.com.au> wrote:
>>>>
>>>> On 2/03/2016 10:40 AM, George Broz wrote:
>>>>
>>>>> 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
>>>>>
>>>>> 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.
>>>>>
>>>>> Thanks for any help!
>>>>>
>>>>
>>>> Even without the custom FPGA logic the files generated from qts-filter.sh
>>>> need to match your board.
>>>> Sets up PLL and SDRAM parameters.
>>>> I'm not familiar with the Terasic dev board ( I do have the altera
>>>> devkit,
>>>> but haven't used it for awhile).
>>>> I'd hope the files in the git repo are correct for your board.
>>>> Without the corresponding qsys project it's hard to be sure.
>>>>
>>> Hi Phil,
>>>
>>> So as my next attempt, there was a Quartus/Qsys example that came
>>> with the Terasic board (specific to my Rev. of the board).
>>>
>>> * I took the contents of the 'handoff folder', .sof, and .sopcinfo file.
>>> * launched an "Embedded Command Shell" from EDS 15.0 and then the BSP
>>> editor GUI
>>> * pointed the BSP editor to the "handoff folder", and hit "Generate"
>>> to produce iocsr, pinmux, pll, etc. files
>>> * applied qts-filter.sh to these files, the output of which I then
>>> dropped into the u-boot source @ ../board/terasic/sockit/qts
>>> * rebuilt uboot spl & image, but got a similar result:
>>>
>>> U-Boot SPL 2016.01 (Mar 02 2016 - 22:13:31)
>>> 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 ###
>>>
>>> Except now it repeats four times, whereas before it only printed out once.
>>>
>>> It that essentially the correct procedure? Is it now a matter of
>>> looking through
>>> the include files that where generated by qts-filter.sh to find a
>>> setting that is "off"?
>>>
>>> (BTW - my first attempt was to use EDS 13.0, but that resulted in
>>> several undefined macros when it
>>> came time to compile u-boot with the qts-filter-generated code. How
>>> does one know which tool version to use?)
>>>
>>
>> What does a diff of the new files show compared to the ones in uboot.
>
> Here's two of them...
>
> --- /home/mcis/altera/uboot-native/u-boot-socfpga-2016.01/board/terasic/sockit/qts/sdram_config.h.orig
> +++ /home/mcis/altera/uboot-native/u-boot-socfpga-2016.01/board/terasic/sockit/qts/sdram_config.h
>
> @@ -33,10 +33,10 @@
>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMODT_WRITE 1
>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_AL 0
>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TCL 7
> -#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TCWL 6
> -#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TFAW 12
> -#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TRFC 104
> -#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TRRD 4
> +#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TCWL 7
> +#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TFAW 15
> +#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TRFC 120
> +#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TRRD 3
>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING2_IF_TRCD 6
>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING2_IF_TREFI 3120
>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING2_IF_TRP 6
>
> @@ -46,12 +46,12 @@
>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING3_TMRD 4
>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING3_TRAS 14
>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING3_TRC 20
> -#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING3_TRTP 4
> +#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING3_TRTP 3
>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING4_PWRDOWNEXIT 3
>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING4_SELFRFSHEXIT 512
>   #define CONFIG_HPS_SDR_CTRLCFG_FIFOCFG_INCSYNC 0
>   #define CONFIG_HPS_SDR_CTRLCFG_FIFOCFG_SYNCMODE 0
> -#define CONFIG_HPS_SDR_CTRLCFG_FPGAPORTRST 0x1FF
> +#define CONFIG_HPS_SDR_CTRLCFG_FPGAPORTRST 0x0
>   #define CONFIG_HPS_SDR_CTRLCFG_LOWPWREQ_SELFRFSHMASK 3
>   #define CONFIG_HPS_SDR_CTRLCFG_LOWPWRTIMING_AUTOPDCYCLES 0
>   #define CONFIG_HPS_SDR_CTRLCFG_LOWPWRTIMING_CLKDISABLECYCLES 8
>
> @@ -147,7 +147,7 @@
>   #define IO_SHIFT_DQS_EN_WHEN_SHIFT_DQS 0
>   #define MAX_LATENCY_COUNT_WIDTH 5
>   #define READ_VALID_FIFO_SIZE 16
> -#define REG_FILE_INIT_SEQ_SIGNATURE 0x5555048d
> +#define REG_FILE_INIT_SEQ_SIGNATURE 0x5555048c
>   #define RW_MGR_MEM_ADDRESS_MIRRORING 0
>   #define RW_MGR_MEM_DATA_MASK_WIDTH 4
>   #define RW_MGR_MEM_DATA_WIDTH 32
>
> @@ -168,19 +168,20 @@
>
>   #define TRESET_CNTR2_VAL 10
>   /* Sequencer ac_rom_init configuration */
> -const u32 ac_rom_init[] = {
> +const u32 ac_rom_init[] =
> +{
>    0x20700000,
>    0x20780000,
>    0x10080431,
>    0x10080530,
>    0x10090044,
> - 0x100a0008,
> + 0x100a0010,
>    0x100b0000,
>    0x10380400,
>    0x10080449,
>    0x100804c8,
>    0x100a0024,
> - 0x10090010,
> + 0x10090008,
>    0x100b0000,
>    0x30780000,
>    0x38780000,
>
> @@ -208,7 +209,8 @@
>   };
>
>
>   /* Sequencer inst_rom_init configuration */
> -const u32 inst_rom_init[] = {
> +const u32 inst_rom_init[] =
> +{
>    0x80000,
>    0x80680,
>    0x8180,
>
> --- /home/mcis/altera/uboot-native/u-boot-socfpga-2016.01/board/terasic/sockit/qts/pll_config.h.orig
> +++ /home/mcis/altera/uboot-native/u-boot-socfpga-2016.01/board/terasic/sockit/qts/pll_config.h
> @@ -16,7 +16,7 @@
>   #define CONFIG_HPS_MAINPLLGRP_DBGATCLK_CNT 0
>   #define CONFIG_HPS_MAINPLLGRP_MAINQSPICLK_CNT 4
>   #define CONFIG_HPS_MAINPLLGRP_MAINNANDSDMMCCLK_CNT 511
> -#define CONFIG_HPS_MAINPLLGRP_CFGS2FUSER0CLK_CNT 14
> +#define CONFIG_HPS_MAINPLLGRP_CFGS2FUSER0CLK_CNT 18
>   #define CONFIG_HPS_MAINPLLGRP_MAINDIV_L3MPCLK 1
>   #define CONFIG_HPS_MAINPLLGRP_MAINDIV_L3SPCLK 1
>   #define CONFIG_HPS_MAINPLLGRP_MAINDIV_L4MPCLK 1
>
>
>> I'm using the Quartus 15.0 tool chain at the moment.
>> Turning on debugging in drivers/ddr/altera/sequencer.c may help.
>>
>
> Setting DLEVEL = 2 yields:
>
> U-Boot SPL 2016.01 (Mar 03 2016 - 06:28:33)
> drivers/ddr/altera/sequencer.c: Preparing to start memory calibration
> find_vfifo_failing_read:1519: vfifo 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> find_vfifo_failing_read:1519: vfifo 1
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1864 p: ptap=4
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1877 p/d: ptap=4 dtap=7 end=16399
> rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1887 found range [14003,16399]
> rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1895 calculate
> dtaps_per_ptap for tracking
> rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1906 backedup phase only:
> p=3rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1919 find passing read
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
> rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1927 find failing read
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
> rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1948 dtaps_per_ptap=21 -
> 8 = 13work_bgn=14003 work_end=16399 work_mid=15201
> vfifo ptap delay 2496
> new work_mid 225
> new p 0, tmp_delay=0
> new d 9, tmp_delay=225
> find_dqs_en_phase: center
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
> sdr_find_window_center:1779 center: found: ptap=0 dtap=9
> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0) => 1
> search_stop_check:2006 center(left): dtap=0 => 255 == 255 &&
> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
> => 1
> search_stop_check:2006 center(left): dtap=1 => 255 == 255 &&
> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
> => 1
> search_stop_check:2006 center(left): dtap=2 => 255 == 255 &&
> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
> => 1
> search_stop_check:2006 center(left): dtap=3 => 255 == 255 &&
> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
> => 1
> search_stop_check:2006 center(left): dtap=4 => 255 == 255 &&
> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
> => 1
> search_stop_check:2006 center(left): dtap=5 => 255 == 255 &&
> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
> => 1
> search_stop_check:2006 center(left): dtap=6 => 255 == 255 &&
> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
> => 1
> search_stop_check:2006 center(left): dtap=7 => 255 == 255 &&
> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
> => 1
> search_stop_check:2006 center(left): dtap=8 => 255 == 255 &&
> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
> => 1
> search_stop_check:2006 center(left): dtap=9 => 255 == 255 &&
> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
> => 1
> search_stop_check:2006 center(left): dtap=10 => 255 == 255 &&
> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
> => 1
> search_stop_check:2006 center(left): dtap=11 => 255 == 255 &&
> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
> => 1
> search_stop_check:2006 center(left): dtap=12 => 255 == 255 &&
> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
> => 1
> search_stop_check:2006 center(left): dtap=13 => 255 == 255 &&
> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
> => 1
> search_stop_check:2006 center(left): dtap=14 => 255 == 255 &&
> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
> => 1
> search_stop_check:2006 center(left): dtap=15 => 255 == 255 &&
> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (187 != 0)
> => 1
> search_stop_check:2006 center(left): dtap=16 => 255 == 255 &&
> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (179 != 0)
> => 1
> search_stop_check:2006 center(left): dtap=17 => 255 == 255 &&
> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (19 != 0)
> => 1
> search_stop_check:2006 center(left): dtap=18 => 255 == 255 &&
> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (17 != 0)
> => 1
> search_stop_check:2006 center(left): dtap=19 => 255 == 255 &&
> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (16 != 0)
> => 1
> search_stop_check:2006 center(left): dtap=20 => 255 == 255 &&
> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) =>
> 0
> search_stop_check:2006 center(left): dtap=21 => 255 == 255 &&?
>
> Will try to make sense of these today...
>
> Any insights welcome!
>

Any success.

You've reached the limits of my knowledge.
The diff shows that there are differences in config.
Failure of Memory Calibration has always been my biggest fear with hardware design.

Interesting that the 2013.01 build from the Quartus tools works.
But the 2016.01 using the same qts generated files does not.
Which would suggest there is something amiss in the code.

Is there similar debug statements in the 2013.01 code?

I'll try and find time to build with the 2016.01 debug statements here and send you a log for comparison.


-- 
Regards
Phil Reid

[U-Boot] Newbie SPL question for socfpga_sockit

[Marek Vasut]

On 03/09/2016 02:42 AM, Phil Reid wrote:
> G'day George,
> 
> On 3/03/2016 10:57 PM, George Broz wrote:
>> On 2 March 2016 at 23:11, Phil Reid <preid@electromag.com.au> wrote:
>>> On 3/03/2016 2:49 PM, George Broz wrote:
>>>>
>>>> On 1 March 2016 at 19:49, Phil Reid <preid@electromag.com.au> wrote:
>>>>>
>>>>> On 2/03/2016 10:40 AM, George Broz wrote:
>>>>>
>>>>>> 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
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> Thanks for any help!
>>>>>>
>>>>>
>>>>> Even without the custom FPGA logic the files generated from
>>>>> qts-filter.sh
>>>>> need to match your board.
>>>>> Sets up PLL and SDRAM parameters.
>>>>> I'm not familiar with the Terasic dev board ( I do have the altera
>>>>> devkit,
>>>>> but haven't used it for awhile).
>>>>> I'd hope the files in the git repo are correct for your board.
>>>>> Without the corresponding qsys project it's hard to be sure.
>>>>>
>>>> Hi Phil,
>>>>
>>>> So as my next attempt, there was a Quartus/Qsys example that came
>>>> with the Terasic board (specific to my Rev. of the board).
>>>>
>>>> * I took the contents of the 'handoff folder', .sof, and .sopcinfo
>>>> file.
>>>> * launched an "Embedded Command Shell" from EDS 15.0 and then the BSP
>>>> editor GUI
>>>> * pointed the BSP editor to the "handoff folder", and hit "Generate"
>>>> to produce iocsr, pinmux, pll, etc. files
>>>> * applied qts-filter.sh to these files, the output of which I then
>>>> dropped into the u-boot source @ ../board/terasic/sockit/qts
>>>> * rebuilt uboot spl & image, but got a similar result:
>>>>
>>>> U-Boot SPL 2016.01 (Mar 02 2016 - 22:13:31)
>>>> 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 ###
>>>>
>>>> Except now it repeats four times, whereas before it only printed out
>>>> once.
>>>>
>>>> It that essentially the correct procedure? Is it now a matter of
>>>> looking through
>>>> the include files that where generated by qts-filter.sh to find a
>>>> setting that is "off"?
>>>>
>>>> (BTW - my first attempt was to use EDS 13.0, but that resulted in
>>>> several undefined macros when it
>>>> came time to compile u-boot with the qts-filter-generated code. How
>>>> does one know which tool version to use?)
>>>>
>>>
>>> What does a diff of the new files show compared to the ones in uboot.
>>
>> Here's two of them...
>>
>> ---
>> /home/mcis/altera/uboot-native/u-boot-socfpga-2016.01/board/terasic/sockit/qts/sdram_config.h.orig
>>
>> +++
>> /home/mcis/altera/uboot-native/u-boot-socfpga-2016.01/board/terasic/sockit/qts/sdram_config.h
>>
>>
>> @@ -33,10 +33,10 @@
>>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMODT_WRITE 1
>>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_AL 0
>>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TCL 7
>> -#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TCWL 6
>> -#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TFAW 12
>> -#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TRFC 104
>> -#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TRRD 4
>> +#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TCWL 7
>> +#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TFAW 15
>> +#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TRFC 120
>> +#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TRRD 3
>>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING2_IF_TRCD 6
>>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING2_IF_TREFI 3120
>>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING2_IF_TRP 6
>>
>> @@ -46,12 +46,12 @@
>>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING3_TMRD 4
>>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING3_TRAS 14
>>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING3_TRC 20
>> -#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING3_TRTP 4
>> +#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING3_TRTP 3
>>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING4_PWRDOWNEXIT 3
>>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING4_SELFRFSHEXIT 512
>>   #define CONFIG_HPS_SDR_CTRLCFG_FIFOCFG_INCSYNC 0
>>   #define CONFIG_HPS_SDR_CTRLCFG_FIFOCFG_SYNCMODE 0
>> -#define CONFIG_HPS_SDR_CTRLCFG_FPGAPORTRST 0x1FF
>> +#define CONFIG_HPS_SDR_CTRLCFG_FPGAPORTRST 0x0
>>   #define CONFIG_HPS_SDR_CTRLCFG_LOWPWREQ_SELFRFSHMASK 3
>>   #define CONFIG_HPS_SDR_CTRLCFG_LOWPWRTIMING_AUTOPDCYCLES 0
>>   #define CONFIG_HPS_SDR_CTRLCFG_LOWPWRTIMING_CLKDISABLECYCLES 8
>>
>> @@ -147,7 +147,7 @@
>>   #define IO_SHIFT_DQS_EN_WHEN_SHIFT_DQS 0
>>   #define MAX_LATENCY_COUNT_WIDTH 5
>>   #define READ_VALID_FIFO_SIZE 16
>> -#define REG_FILE_INIT_SEQ_SIGNATURE 0x5555048d
>> +#define REG_FILE_INIT_SEQ_SIGNATURE 0x5555048c
>>   #define RW_MGR_MEM_ADDRESS_MIRRORING 0
>>   #define RW_MGR_MEM_DATA_MASK_WIDTH 4
>>   #define RW_MGR_MEM_DATA_WIDTH 32
>>
>> @@ -168,19 +168,20 @@
>>
>>   #define TRESET_CNTR2_VAL 10
>>   /* Sequencer ac_rom_init configuration */
>> -const u32 ac_rom_init[] = {
>> +const u32 ac_rom_init[] =
>> +{
>>    0x20700000,
>>    0x20780000,
>>    0x10080431,
>>    0x10080530,
>>    0x10090044,
>> - 0x100a0008,
>> + 0x100a0010,
>>    0x100b0000,
>>    0x10380400,
>>    0x10080449,
>>    0x100804c8,
>>    0x100a0024,
>> - 0x10090010,
>> + 0x10090008,
>>    0x100b0000,
>>    0x30780000,
>>    0x38780000,
>>
>> @@ -208,7 +209,8 @@
>>   };
>>
>>
>>   /* Sequencer inst_rom_init configuration */
>> -const u32 inst_rom_init[] = {
>> +const u32 inst_rom_init[] =
>> +{
>>    0x80000,
>>    0x80680,
>>    0x8180,
>>
>> ---
>> /home/mcis/altera/uboot-native/u-boot-socfpga-2016.01/board/terasic/sockit/qts/pll_config.h.orig
>>
>> +++
>> /home/mcis/altera/uboot-native/u-boot-socfpga-2016.01/board/terasic/sockit/qts/pll_config.h
>>
>> @@ -16,7 +16,7 @@
>>   #define CONFIG_HPS_MAINPLLGRP_DBGATCLK_CNT 0
>>   #define CONFIG_HPS_MAINPLLGRP_MAINQSPICLK_CNT 4
>>   #define CONFIG_HPS_MAINPLLGRP_MAINNANDSDMMCCLK_CNT 511
>> -#define CONFIG_HPS_MAINPLLGRP_CFGS2FUSER0CLK_CNT 14
>> +#define CONFIG_HPS_MAINPLLGRP_CFGS2FUSER0CLK_CNT 18
>>   #define CONFIG_HPS_MAINPLLGRP_MAINDIV_L3MPCLK 1
>>   #define CONFIG_HPS_MAINPLLGRP_MAINDIV_L3SPCLK 1
>>   #define CONFIG_HPS_MAINPLLGRP_MAINDIV_L4MPCLK 1
>>
>>
>>> I'm using the Quartus 15.0 tool chain at the moment.
>>> Turning on debugging in drivers/ddr/altera/sequencer.c may help.
>>>
>>
>> Setting DLEVEL = 2 yields:
>>
>> U-Boot SPL 2016.01 (Mar 03 2016 - 06:28:33)
>> drivers/ddr/altera/sequencer.c: Preparing to start memory calibration
>> find_vfifo_failing_read:1519: vfifo 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> find_vfifo_failing_read:1519: vfifo 1
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1864 p: ptap=4
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1877 p/d: ptap=4 dtap=7
>> end=16399
>> rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1887 found range
>> [14003,16399]
>> rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1895 calculate
>> dtaps_per_ptap for tracking
>> rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1906 backedup phase only:
>> p=3rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1919 find passing read
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>> rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1927 find failing read
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>> rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1948 dtaps_per_ptap=21 -
>> 8 = 13work_bgn=14003 work_end=16399 work_mid=15201
>> vfifo ptap delay 2496
>> new work_mid 225
>> new p 0, tmp_delay=0
>> new d 9, tmp_delay=225
>> find_dqs_en_phase: center
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>> sdr_find_window_center:1779 center: found: ptap=0 dtap=9
>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0) => 1
>> search_stop_check:2006 center(left): dtap=0 => 255 == 255 &&
>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>> => 1
>> search_stop_check:2006 center(left): dtap=1 => 255 == 255 &&
>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>> => 1
>> search_stop_check:2006 center(left): dtap=2 => 255 == 255 &&
>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>> => 1
>> search_stop_check:2006 center(left): dtap=3 => 255 == 255 &&
>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>> => 1
>> search_stop_check:2006 center(left): dtap=4 => 255 == 255 &&
>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>> => 1
>> search_stop_check:2006 center(left): dtap=5 => 255 == 255 &&
>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>> => 1
>> search_stop_check:2006 center(left): dtap=6 => 255 == 255 &&
>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>> => 1
>> search_stop_check:2006 center(left): dtap=7 => 255 == 255 &&
>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>> => 1
>> search_stop_check:2006 center(left): dtap=8 => 255 == 255 &&
>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>> => 1
>> search_stop_check:2006 center(left): dtap=9 => 255 == 255 &&
>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>> => 1
>> search_stop_check:2006 center(left): dtap=10 => 255 == 255 &&
>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>> => 1
>> search_stop_check:2006 center(left): dtap=11 => 255 == 255 &&
>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>> => 1
>> search_stop_check:2006 center(left): dtap=12 => 255 == 255 &&
>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>> => 1
>> search_stop_check:2006 center(left): dtap=13 => 255 == 255 &&
>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>> => 1
>> search_stop_check:2006 center(left): dtap=14 => 255 == 255 &&
>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>> => 1
>> search_stop_check:2006 center(left): dtap=15 => 255 == 255 &&
>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (187 != 0)
>> => 1
>> search_stop_check:2006 center(left): dtap=16 => 255 == 255 &&
>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (179 != 0)
>> => 1
>> search_stop_check:2006 center(left): dtap=17 => 255 == 255 &&
>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (19 != 0)
>> => 1
>> search_stop_check:2006 center(left): dtap=18 => 255 == 255 &&
>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (17 != 0)
>> => 1
>> search_stop_check:2006 center(left): dtap=19 => 255 == 255 &&
>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (16 != 0)
>> => 1
>> search_stop_check:2006 center(left): dtap=20 => 255 == 255 &&
>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) =>
>> 0
>> search_stop_check:2006 center(left): dtap=21 => 255 == 255 &&?
>>
>> Will try to make sense of these today...
>>
>> Any insights welcome!
>>
> 
> Any success.
> 
> You've reached the limits of my knowledge.
> The diff shows that there are differences in config.
> Failure of Memory Calibration has always been my biggest fear with
> hardware design.
> 
> Interesting that the 2013.01 build from the Quartus tools works.
> But the 2016.01 using the same qts generated files does not.
> Which would suggest there is something amiss in the code.
> 
> Is there similar debug statements in the 2013.01 code?

There is debug(), which you can enable by adding #define DEBUG at the
beginning of drivers/ddr/altera/*.c . The other way of tracking down
this bug would be to rig the writel()/readl() calls and check what
values they use compared to the original altera code.

> I'll try and find time to build with the 2016.01 debug statements here
> and send you a log for comparison.
> 
> 


-- 
Best regards,
Marek Vasut

[U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 9 March 2016 at 02:55, Marek Vasut <marex@denx.de> wrote:
> On 03/09/2016 02:42 AM, Phil Reid wrote:
>> G'day George,
>>
>> On 3/03/2016 10:57 PM, George Broz wrote:
>>> On 2 March 2016 at 23:11, Phil Reid <preid@electromag.com.au> wrote:
>>>> On 3/03/2016 2:49 PM, George Broz wrote:
>>>>>
>>>>> On 1 March 2016 at 19:49, Phil Reid <preid@electromag.com.au> wrote:
>>>>>>
>>>>>> On 2/03/2016 10:40 AM, George Broz wrote:
>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> Thanks for any help!
>>>>>>>
>>>>>>
>>>>>> Even without the custom FPGA logic the files generated from
>>>>>> qts-filter.sh
>>>>>> need to match your board.
>>>>>> Sets up PLL and SDRAM parameters.
>>>>>> I'm not familiar with the Terasic dev board ( I do have the altera
>>>>>> devkit,
>>>>>> but haven't used it for awhile).
>>>>>> I'd hope the files in the git repo are correct for your board.
>>>>>> Without the corresponding qsys project it's hard to be sure.
>>>>>>
>>>>> Hi Phil,
>>>>>
>>>>> So as my next attempt, there was a Quartus/Qsys example that came
>>>>> with the Terasic board (specific to my Rev. of the board).
>>>>>
>>>>> * I took the contents of the 'handoff folder', .sof, and .sopcinfo
>>>>> file.
>>>>> * launched an "Embedded Command Shell" from EDS 15.0 and then the BSP
>>>>> editor GUI
>>>>> * pointed the BSP editor to the "handoff folder", and hit "Generate"
>>>>> to produce iocsr, pinmux, pll, etc. files
>>>>> * applied qts-filter.sh to these files, the output of which I then
>>>>> dropped into the u-boot source @ ../board/terasic/sockit/qts
>>>>> * rebuilt uboot spl & image, but got a similar result:
>>>>>
>>>>> U-Boot SPL 2016.01 (Mar 02 2016 - 22:13:31)
>>>>> 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 ###
>>>>>
>>>>> Except now it repeats four times, whereas before it only printed out
>>>>> once.
>>>>>
>>>>> It that essentially the correct procedure? Is it now a matter of
>>>>> looking through
>>>>> the include files that where generated by qts-filter.sh to find a
>>>>> setting that is "off"?
>>>>>
>>>>> (BTW - my first attempt was to use EDS 13.0, but that resulted in
>>>>> several undefined macros when it
>>>>> came time to compile u-boot with the qts-filter-generated code. How
>>>>> does one know which tool version to use?)
>>>>>
>>>>
>>>> What does a diff of the new files show compared to the ones in uboot.
>>>
>>> Here's two of them...
>>>
>>> ---
>>> /home/mcis/altera/uboot-native/u-boot-socfpga-2016.01/board/terasic/sockit/qts/sdram_config.h.orig
>>>
>>> +++
>>> /home/mcis/altera/uboot-native/u-boot-socfpga-2016.01/board/terasic/sockit/qts/sdram_config.h
>>>
>>>
>>> @@ -33,10 +33,10 @@
>>>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMODT_WRITE 1
>>>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_AL 0
>>>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TCL 7
>>> -#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TCWL 6
>>> -#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TFAW 12
>>> -#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TRFC 104
>>> -#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TRRD 4
>>> +#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TCWL 7
>>> +#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TFAW 15
>>> +#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TRFC 120
>>> +#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TRRD 3
>>>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING2_IF_TRCD 6
>>>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING2_IF_TREFI 3120
>>>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING2_IF_TRP 6
>>>
>>> @@ -46,12 +46,12 @@
>>>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING3_TMRD 4
>>>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING3_TRAS 14
>>>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING3_TRC 20
>>> -#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING3_TRTP 4
>>> +#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING3_TRTP 3
>>>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING4_PWRDOWNEXIT 3
>>>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING4_SELFRFSHEXIT 512
>>>   #define CONFIG_HPS_SDR_CTRLCFG_FIFOCFG_INCSYNC 0
>>>   #define CONFIG_HPS_SDR_CTRLCFG_FIFOCFG_SYNCMODE 0
>>> -#define CONFIG_HPS_SDR_CTRLCFG_FPGAPORTRST 0x1FF
>>> +#define CONFIG_HPS_SDR_CTRLCFG_FPGAPORTRST 0x0
>>>   #define CONFIG_HPS_SDR_CTRLCFG_LOWPWREQ_SELFRFSHMASK 3
>>>   #define CONFIG_HPS_SDR_CTRLCFG_LOWPWRTIMING_AUTOPDCYCLES 0
>>>   #define CONFIG_HPS_SDR_CTRLCFG_LOWPWRTIMING_CLKDISABLECYCLES 8
>>>
>>> @@ -147,7 +147,7 @@
>>>   #define IO_SHIFT_DQS_EN_WHEN_SHIFT_DQS 0
>>>   #define MAX_LATENCY_COUNT_WIDTH 5
>>>   #define READ_VALID_FIFO_SIZE 16
>>> -#define REG_FILE_INIT_SEQ_SIGNATURE 0x5555048d
>>> +#define REG_FILE_INIT_SEQ_SIGNATURE 0x5555048c
>>>   #define RW_MGR_MEM_ADDRESS_MIRRORING 0
>>>   #define RW_MGR_MEM_DATA_MASK_WIDTH 4
>>>   #define RW_MGR_MEM_DATA_WIDTH 32
>>>
>>> @@ -168,19 +168,20 @@
>>>
>>>   #define TRESET_CNTR2_VAL 10
>>>   /* Sequencer ac_rom_init configuration */
>>> -const u32 ac_rom_init[] = {
>>> +const u32 ac_rom_init[] =
>>> +{
>>>    0x20700000,
>>>    0x20780000,
>>>    0x10080431,
>>>    0x10080530,
>>>    0x10090044,
>>> - 0x100a0008,
>>> + 0x100a0010,
>>>    0x100b0000,
>>>    0x10380400,
>>>    0x10080449,
>>>    0x100804c8,
>>>    0x100a0024,
>>> - 0x10090010,
>>> + 0x10090008,
>>>    0x100b0000,
>>>    0x30780000,
>>>    0x38780000,
>>>
>>> @@ -208,7 +209,8 @@
>>>   };
>>>
>>>
>>>   /* Sequencer inst_rom_init configuration */
>>> -const u32 inst_rom_init[] = {
>>> +const u32 inst_rom_init[] =
>>> +{
>>>    0x80000,
>>>    0x80680,
>>>    0x8180,
>>>
>>> ---
>>> /home/mcis/altera/uboot-native/u-boot-socfpga-2016.01/board/terasic/sockit/qts/pll_config.h.orig
>>>
>>> +++
>>> /home/mcis/altera/uboot-native/u-boot-socfpga-2016.01/board/terasic/sockit/qts/pll_config.h
>>>
>>> @@ -16,7 +16,7 @@
>>>   #define CONFIG_HPS_MAINPLLGRP_DBGATCLK_CNT 0
>>>   #define CONFIG_HPS_MAINPLLGRP_MAINQSPICLK_CNT 4
>>>   #define CONFIG_HPS_MAINPLLGRP_MAINNANDSDMMCCLK_CNT 511
>>> -#define CONFIG_HPS_MAINPLLGRP_CFGS2FUSER0CLK_CNT 14
>>> +#define CONFIG_HPS_MAINPLLGRP_CFGS2FUSER0CLK_CNT 18
>>>   #define CONFIG_HPS_MAINPLLGRP_MAINDIV_L3MPCLK 1
>>>   #define CONFIG_HPS_MAINPLLGRP_MAINDIV_L3SPCLK 1
>>>   #define CONFIG_HPS_MAINPLLGRP_MAINDIV_L4MPCLK 1
>>>
>>>
>>>> I'm using the Quartus 15.0 tool chain at the moment.
>>>> Turning on debugging in drivers/ddr/altera/sequencer.c may help.
>>>>
>>>
>>> Setting DLEVEL = 2 yields:
>>>
>>> U-Boot SPL 2016.01 (Mar 03 2016 - 06:28:33)
>>> drivers/ddr/altera/sequencer.c: Preparing to start memory calibration
>>> find_vfifo_failing_read:1519: vfifo 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> find_vfifo_failing_read:1519: vfifo 1
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1864 p: ptap=4
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1877 p/d: ptap=4 dtap=7
>>> end=16399
>>> rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1887 found range
>>> [14003,16399]
>>> rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1895 calculate
>>> dtaps_per_ptap for tracking
>>> rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1906 backedup phase only:
>>> p=3rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1919 find passing read
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>> rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1927 find failing read
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>> rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1948 dtaps_per_ptap=21 -
>>> 8 = 13work_bgn=14003 work_end=16399 work_mid=15201
>>> vfifo ptap delay 2496
>>> new work_mid 225
>>> new p 0, tmp_delay=0
>>> new d 9, tmp_delay=225
>>> find_dqs_en_phase: center
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>> sdr_find_window_center:1779 center: found: ptap=0 dtap=9
>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0) => 1
>>> search_stop_check:2006 center(left): dtap=0 => 255 == 255 &&
>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>>> => 1
>>> search_stop_check:2006 center(left): dtap=1 => 255 == 255 &&
>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>>> => 1
>>> search_stop_check:2006 center(left): dtap=2 => 255 == 255 &&
>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>>> => 1
>>> search_stop_check:2006 center(left): dtap=3 => 255 == 255 &&
>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>>> => 1
>>> search_stop_check:2006 center(left): dtap=4 => 255 == 255 &&
>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>>> => 1
>>> search_stop_check:2006 center(left): dtap=5 => 255 == 255 &&
>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>>> => 1
>>> search_stop_check:2006 center(left): dtap=6 => 255 == 255 &&
>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>>> => 1
>>> search_stop_check:2006 center(left): dtap=7 => 255 == 255 &&
>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>>> => 1
>>> search_stop_check:2006 center(left): dtap=8 => 255 == 255 &&
>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>>> => 1
>>> search_stop_check:2006 center(left): dtap=9 => 255 == 255 &&
>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>>> => 1
>>> search_stop_check:2006 center(left): dtap=10 => 255 == 255 &&
>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>>> => 1
>>> search_stop_check:2006 center(left): dtap=11 => 255 == 255 &&
>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>>> => 1
>>> search_stop_check:2006 center(left): dtap=12 => 255 == 255 &&
>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>>> => 1
>>> search_stop_check:2006 center(left): dtap=13 => 255 == 255 &&
>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>>> => 1
>>> search_stop_check:2006 center(left): dtap=14 => 255 == 255 &&
>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>>> => 1
>>> search_stop_check:2006 center(left): dtap=15 => 255 == 255 &&
>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (187 != 0)
>>> => 1
>>> search_stop_check:2006 center(left): dtap=16 => 255 == 255 &&
>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (179 != 0)
>>> => 1
>>> search_stop_check:2006 center(left): dtap=17 => 255 == 255 &&
>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (19 != 0)
>>> => 1
>>> search_stop_check:2006 center(left): dtap=18 => 255 == 255 &&
>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (17 != 0)
>>> => 1
>>> search_stop_check:2006 center(left): dtap=19 => 255 == 255 &&
>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (16 != 0)
>>> => 1
>>> search_stop_check:2006 center(left): dtap=20 => 255 == 255 &&
>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) =>
>>> 0
>>> search_stop_check:2006 center(left): dtap=21 => 255 == 255 &&?
>>>
>>> Will try to make sense of these today...
>>>
>>> Any insights welcome!
>>>
>>
>> Any success.
>>
>> You've reached the limits of my knowledge.
>> The diff shows that there are differences in config.
>> Failure of Memory Calibration has always been my biggest fear with
>> hardware design.
>>
>> Interesting that the 2013.01 build from the Quartus tools works.
>> But the 2016.01 using the same qts generated files does not.
>> Which would suggest there is something amiss in the code.
>>
>> Is there similar debug statements in the 2013.01 code?
>
> There is debug(), which you can enable by adding #define DEBUG at the
> beginning of drivers/ddr/altera/*.c . The other way of tracking down
> this bug would be to rig the writel()/readl() calls and check what
> values they use compared to the original altera code.

Thanks, Phil. I will see what the 2013.01 debug produces. But below is
what I see if I add DEBUG to the 2016.03-rc3 code.

Marek -
The marking on my DDR parts is 4NE77 D9PXV which translates to
Micron part# MT41K256M16HA-125:E. I was looking at the data sheet
to see if I could further manually relax some of the settings in
sdram_config.h. I was also wondering what DDR parts you have on your
boards. Given that your two Rev. D boards work fine, I'm beginning to
think mine is defective and I'd be better off to get a new one.


Best regards,
--George Broz


U-Boot SPL 2016.03-rc3 (Mar 08 2016 - 15:46:07)
scc_mgr_initialize:281: Clearing SCC RFILE index 0
scc_mgr_initialize:281: Clearing SCC RFILE index 1
scc_mgr_initialize:281: Clearing SCC RFILE index 2
scc_mgr_initialize:281: Clearing SCC RFILE index 3
scc_mgr_initialize:281: Clearing SCC RFILE index 4
scc_mgr_initialize:281: Clearing SCC RFILE index 5
scc_mgr_initialize:281: Clearing SCC RFILE index 6
scc_mgr_initialize:281: Clearing SCC RFILE index 7
scc_mgr_initialize:281: Clearing SCC RFILE index 8
scc_mgr_initialize:281: Clearing SCC RFILE index 9
scc_mgr_initialize:281: Clearing SCC RFILE index 10
scc_mgr_initialize:281: Clearing SCC RFILE index 11
scc_mgr_initialize:281: Clearing SCC RFILE index 12
scc_mgr_initialize:281: Clearing SCC RFILE index 13
scc_mgr_initialize:281: Clearing SCC RFILE index 14
scc_mgr_initialize:281: Clearing SCC RFILE index 15
drivers/ddr/altera/sequencer.c: Preparing to start memory calibration
DDR3 FULL_RATE ranks=1 cs/dimm=1 dq/dqs=8,8 vg/dqs=1,1 dqs=5,5 dq=40
dm=5 ptap_delay=312 dtap_delay=25 dtap_dqsen_delay=25, dll=8max
values: en_p=7 dqdqs_p=0 en_d=31 dqs_in_d=31 io_in_d=31 io_out1_d=31
io_out2_d=0 dqs_in_reserve=4 dqs_out_reserve=6
scc_mgr_set_hhp_extras:477 Setting HHP Extras
scc_mgr_set_hhp_extras:480 Done Setting HHP Extras
rw_mgr_mem_calibrate_guaranteed_write:2534 guaranteed write: g=0 p=0
rw_mgr_mem_calibrate_read_test_patterns:1290 test_load_patterns(0,ALL)
=> (255 == 255) => 0
rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=0 r=0 i=0 p=0 d=0
rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=0 r=0 i=1 p=1 d=4
rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=0 r=0 i=2 p=2 d=8
rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=0 r=0 i=3 p=3 d=12
rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=0 r=0 i=4 p=4 d=16
rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=0 r=0 i=5 p=5 d=20
rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=0 r=0 i=6 p=6 d=24
rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=0 r=0 i=7 p=7 d=28
rw_mgr_mem_calibrate_dqs_enable_calibration:2607: g=0 found=1;
Reseting delay chain to zero
get_window_mid_index:2288 vfifo_center: *mid_min=-5 (index=3)
vfifo_center: new mid_min=-5 new_dqs=9
vfifo_center: start_dqs=4 start_dqs_en=-1 new_dqs=9 mid_min=-5
get_window_mid_index:2288 vfifo_center: *mid_min=2 (index=6)
rw_mgr_mem_calibrate_writes_center:3005 write_center: start_dqs=6
new_dqs=6 mid_min=0
get_window_mid_index:2288 vfifo_center: *mid_min=0 (index=3)
vfifo_center: new mid_min=0 new_dqs=9
vfifo_center: start_dqs=9 start_dqs_en=-1 new_dqs=9 mid_min=0
rw_mgr_mem_calibrate_guaranteed_write:2534 guaranteed write: g=1 p=0
rw_mgr_mem_calibrate_read_test_patterns:1290 test_load_patterns(1,ALL)
=> (255 == 255) => 0
rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=1 r=0 i=0 p=0 d=0
rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=1 r=0 i=1 p=1 d=4
rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=1 r=0 i=2 p=2 d=8
rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=1 r=0 i=3 p=3 d=12
rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=1 r=0 i=4 p=4 d=16
rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=1 r=0 i=5 p=5 d=20
rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=1 r=0 i=6 p=6 d=24
rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=1 r=0 i=7 p=7 d=28
rw_mgr_mem_calibrate_dqs_enable_calibration:2607: g=1 found=1;
Reseting delay chain to zero
get_window_mid_index:2288 vfifo_center: *mid_min=-4 (index=3)
vfifo_center: new mid_min=-4 new_dqs=8
vfifo_center: start_dqs=4 start_dqs_en=-1 new_dqs=8 mid_min=-4
get_window_mid_index:2288 vfifo_center: *mid_min=2 (index=2)
rw_mgr_mem_calibrate_writes_center:3005 write_center: start_dqs=6
new_dqs=6 mid_min=0
get_window_mid_index:2288 vfifo_center: *mid_min=-1 (index=3)
vfifo_center: new mid_min=-1 new_dqs=9
vfifo_center: start_dqs=8 start_dqs_en=-1 new_dqs=9 mid_min=-1
rw_mgr_mem_calibrate_guaranteed_write:2534 guaranteed write: g=2 p=0
rw_mgr_mem_calibrate_read_test_patterns:1290 test_load_patterns(2,ALL)
=> (255 == 255) => 0
rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=2 r=0 i=0 p=0 d=0
rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=2 r=0 i=1 p=1 d=4
rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=2 r=0 i=2 p=2 d=8
rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=2 r=0 i=3 p=3 d=12
rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=2 r=0 i=4 p=4 d=16
rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=2 r=0 i=5 p=5 d=20
rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=2 r=0 i=6 p=6 d=24
rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=2 r=0 i=7 p=7 d=28
rw_mgr_mem_calibrate_dqs_enable_calibration:2607: g=2 found=1;
Reseting delay chain to zero
get_window_mid_index:2288 vfifo_center: *mid_min=-3 (index=3)
vfifo_center: new mid_min=-3 new_dqs=7
vfifo_center: start_dqs=4 start_dqs_en=-1 new_dqs=7 mid_min=-3
get_window_mid_index:2288 vfifo_center: *mid_min=2 (index=2)
rw_mgr_mem_calibrate_writes_center:3005 write_center: start_dqs=6
new_dqs=6 mid_min=0
get_window_mid_index:2288 vfifo_center: *mid_min=-1 (index=7)
vfifo_center: new mid_min=-1 new_dqs=8
vfifo_center: start_dqs=7 start_dqs_en=-1 new_dqs=8 mid_min=-1
rw_mgr_mem_calibrate_guaranteed_write:2534 guaranteed write: g=3 p=0
rw_mgr_mem_calibrate_read_test_patterns:1290 test_load_patterns(3,ALL)
=> (255 == 255) => 0
rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=3 r=0 i=0 p=0 d=0
rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=3 r=0 i=1 p=1 d=4
rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=3 r=0 i=2 p=2 d=8
rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=3 r=0 i=3 p=3 d=12
rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=3 r=0 i=4 p=4 d=16
rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=3 r=0 i=5 p=5 d=20
rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=3 r=0 i=6 p=6 d=24
rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=3 r=0 i=7 p=7 d=28
rw_mgr_mem_calibrate_dqs_enable_calibration:2607: g=3 found=1;
Reseting delay chain to zero
get_window_mid_index:2288 vfifo_center: *mid_min=-4 (index=7)
vfifo_center: new mid_min=-4 new_dqs=8
vfifo_center: start_dqs=4 start_dqs_en=-1 new_dqs=8 mid_min=-4
get_window_mid_index:2288 vfifo_center: *mid_min=1 (index=2)
rw_mgr_mem_calibrate_writes_center:3005 write_center: start_dqs=6
new_dqs=6 mid_min=0
get_window_mid_index:2288 vfifo_center: *mid_min=0 (index=3)
vfifo_center: new mid_min=0 new_dqs=8
vfifo_center: start_dqs=8 start_dqs_en=-1 new_dqs=8 mid_min=0
rw_mgr_mem_calibrate_guaranteed_write:2534 guaranteed write: g=4 p=0
rw_mgr_mem_calibrate_read_test_patterns:1290 test_load_patterns(4,ALL)
=> (170 == 255) => -5
rw_mgr_mem_calibrate_guaranteed_write:2554 Guaranteed read test failed: g=4 p=0
scc_mgr_apply_group_all_out_delay_add:691 (4, 2) DQS: 2 > 0; adding 2 to OUT1
scc_mgr_apply_group_all_out_delay_add:705 (4, 2) DQS: 2 > 0; adding 2 to OUT1
rw_mgr_mem_calibrate_guaranteed_write:2534 guaranteed write: g=4 p=0
rw_mgr_mem_calibrate_read_test_patterns:1290 test_load_patterns(4,ALL)
=> (170 == 255) => -5
rw_mgr_mem_calibrate_guaranteed_write:2554 Guaranteed read test failed: g=4 p=0
scc_mgr_apply_group_all_out_delay_add:691 (4, 4) DQS: 4 > 0; adding 4 to OUT1
scc_mgr_apply_group_all_out_delay_add:705 (4, 4) DQS: 4 > 0; adding 4 to OUT1
rw_mgr_mem_calibrate_guaranteed_write:2534 guaranteed write: g=4 p=0
rw_mgr_mem_calibrate_read_test_patterns:1290 test_load_patterns(4,ALL)
=> (170 == 255) => -5
rw_mgr_mem_calibrate_guaranteed_write:2554 Guaranteed read test failed: g=4 p=0
scc_mgr_apply_group_all_out_delay_add:691 (4, 6) DQS: 6 > 0; adding 6 to OUT1
scc_mgr_apply_group_all_out_delay_add:705 (4, 6) DQS: 6 > 0; adding 6 to OUT1
rw_mgr_mem_calibrate_guaranteed_write:2534 guaranteed write: g=4 p=0
rw_mgr_mem_calibrate_read_test_patterns:1290 test_load_patterns(4,ALL)
=> (170 == 255) => -5
rw_mgr_mem_calibrate_guaranteed_write:2554 Guaranteed read test failed: g=4 p=0
scc_mgr_apply_group_all_out_delay_add:691 (4, 8) DQS: 8 > 0; adding 8 to OUT1
scc_mgr_apply_group_all_out_delay_add:705 (4, 8) DQS: 8 > 0; adding 8 to OUT1
rw_mgr_mem_calibrate_guaranteed_write:2534 guaranteed write: g=4 p=0
rw_mgr_mem_calibrate_read_test_patterns:1290 test_load_patterns(4,ALL)
=> (170 == 255) => -5
rw_mgr_mem_calibrate_guaranteed_write:2554 Guaranteed read test failed: g=4 p=0
scc_mgr_apply_group_all_out_delay_add:691 (4, 10) DQS: 10 > 0; adding 10 to OUT1
scc_mgr_apply_group_all_out_delay_add:705 (4, 10) DQS: 10 > 0; adding 10 to OUT1
rw_mgr_mem_calibrate_guaranteed_write:2534 guaranteed write: g=4 p=0
rw_mgr_mem_calibrate_read_test_patterns:1290 test_load_patterns(4,ALL)
=> (170 == 255) => -5
rw_mgr_mem_calibrate_guaranteed_write:2554 Guaranteed read test failed: g=4 p=0
scc_mgr_apply_group_all_out_delay_add:691 (4, 12) DQS: 12 > 0; adding 12 to OUT1
scc_mgr_apply_group_all_out_delay_add:705 (4, 12) DQS: 12 > 0; adding 12 to OUT1
rw_mgr_mem_calibrate_guaranteed_write:2534 guaranteed write: g=4 p=0
rw_mgr_mem_calibrate_read_test_patterns:1290 test_load_patterns(4,ALL)
=> (170 == 255) => -5
rw_mgr_mem_calibrate_guaranteed_write:2554 Guaranteed read test failed: g=4 p=0
drivers/ddr/altera/sequencer.c: CALIBRATION FAILED
drivers/ddr/altera/sequencer.c: Calibration complete
SDRAM calibration failed.
### ERROR ### Please RESET the board ###


>
>> I'll try and find time to build with the 2016.01 debug statements here
>> and send you a log for comparison.
>>
>>
>
>
> --
> Best regards,
> Marek Vasut

[U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 9 March 2016 at 08:06, George Broz <brozgeo@gmail.com> wrote:
> On 9 March 2016 at 02:55, Marek Vasut <marex@denx.de> wrote:
>> On 03/09/2016 02:42 AM, Phil Reid wrote:
>>> G'day George,
>>>
>>> On 3/03/2016 10:57 PM, George Broz wrote:
>>>> On 2 March 2016 at 23:11, Phil Reid <preid@electromag.com.au> wrote:
>>>>> On 3/03/2016 2:49 PM, George Broz wrote:
>>>>>>
>>>>>> On 1 March 2016 at 19:49, Phil Reid <preid@electromag.com.au> wrote:
>>>>>>>
>>>>>>> On 2/03/2016 10:40 AM, George Broz wrote:
>>>>>>>
>>>>>>>> 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
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> Thanks for any help!
>>>>>>>>
>>>>>>>
>>>>>>> Even without the custom FPGA logic the files generated from
>>>>>>> qts-filter.sh
>>>>>>> need to match your board.
>>>>>>> Sets up PLL and SDRAM parameters.
>>>>>>> I'm not familiar with the Terasic dev board ( I do have the altera
>>>>>>> devkit,
>>>>>>> but haven't used it for awhile).
>>>>>>> I'd hope the files in the git repo are correct for your board.
>>>>>>> Without the corresponding qsys project it's hard to be sure.
>>>>>>>
>>>>>> Hi Phil,
>>>>>>
>>>>>> So as my next attempt, there was a Quartus/Qsys example that came
>>>>>> with the Terasic board (specific to my Rev. of the board).
>>>>>>
>>>>>> * I took the contents of the 'handoff folder', .sof, and .sopcinfo
>>>>>> file.
>>>>>> * launched an "Embedded Command Shell" from EDS 15.0 and then the BSP
>>>>>> editor GUI
>>>>>> * pointed the BSP editor to the "handoff folder", and hit "Generate"
>>>>>> to produce iocsr, pinmux, pll, etc. files
>>>>>> * applied qts-filter.sh to these files, the output of which I then
>>>>>> dropped into the u-boot source @ ../board/terasic/sockit/qts
>>>>>> * rebuilt uboot spl & image, but got a similar result:
>>>>>>
>>>>>> U-Boot SPL 2016.01 (Mar 02 2016 - 22:13:31)
>>>>>> 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 ###
>>>>>>
>>>>>> Except now it repeats four times, whereas before it only printed out
>>>>>> once.
>>>>>>
>>>>>> It that essentially the correct procedure? Is it now a matter of
>>>>>> looking through
>>>>>> the include files that where generated by qts-filter.sh to find a
>>>>>> setting that is "off"?
>>>>>>
>>>>>> (BTW - my first attempt was to use EDS 13.0, but that resulted in
>>>>>> several undefined macros when it
>>>>>> came time to compile u-boot with the qts-filter-generated code. How
>>>>>> does one know which tool version to use?)
>>>>>>
>>>>>
>>>>> What does a diff of the new files show compared to the ones in uboot.
>>>>
>>>> Here's two of them...
>>>>
>>>> ---
>>>> /home/mcis/altera/uboot-native/u-boot-socfpga-2016.01/board/terasic/sockit/qts/sdram_config.h.orig
>>>>
>>>> +++
>>>> /home/mcis/altera/uboot-native/u-boot-socfpga-2016.01/board/terasic/sockit/qts/sdram_config.h
>>>>
>>>>
>>>> @@ -33,10 +33,10 @@
>>>>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMODT_WRITE 1
>>>>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_AL 0
>>>>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TCL 7
>>>> -#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TCWL 6
>>>> -#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TFAW 12
>>>> -#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TRFC 104
>>>> -#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TRRD 4
>>>> +#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TCWL 7
>>>> +#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TFAW 15
>>>> +#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TRFC 120
>>>> +#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING1_TRRD 3
>>>>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING2_IF_TRCD 6
>>>>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING2_IF_TREFI 3120
>>>>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING2_IF_TRP 6
>>>>
>>>> @@ -46,12 +46,12 @@
>>>>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING3_TMRD 4
>>>>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING3_TRAS 14
>>>>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING3_TRC 20
>>>> -#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING3_TRTP 4
>>>> +#define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING3_TRTP 3
>>>>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING4_PWRDOWNEXIT 3
>>>>   #define CONFIG_HPS_SDR_CTRLCFG_DRAMTIMING4_SELFRFSHEXIT 512
>>>>   #define CONFIG_HPS_SDR_CTRLCFG_FIFOCFG_INCSYNC 0
>>>>   #define CONFIG_HPS_SDR_CTRLCFG_FIFOCFG_SYNCMODE 0
>>>> -#define CONFIG_HPS_SDR_CTRLCFG_FPGAPORTRST 0x1FF
>>>> +#define CONFIG_HPS_SDR_CTRLCFG_FPGAPORTRST 0x0
>>>>   #define CONFIG_HPS_SDR_CTRLCFG_LOWPWREQ_SELFRFSHMASK 3
>>>>   #define CONFIG_HPS_SDR_CTRLCFG_LOWPWRTIMING_AUTOPDCYCLES 0
>>>>   #define CONFIG_HPS_SDR_CTRLCFG_LOWPWRTIMING_CLKDISABLECYCLES 8
>>>>
>>>> @@ -147,7 +147,7 @@
>>>>   #define IO_SHIFT_DQS_EN_WHEN_SHIFT_DQS 0
>>>>   #define MAX_LATENCY_COUNT_WIDTH 5
>>>>   #define READ_VALID_FIFO_SIZE 16
>>>> -#define REG_FILE_INIT_SEQ_SIGNATURE 0x5555048d
>>>> +#define REG_FILE_INIT_SEQ_SIGNATURE 0x5555048c
>>>>   #define RW_MGR_MEM_ADDRESS_MIRRORING 0
>>>>   #define RW_MGR_MEM_DATA_MASK_WIDTH 4
>>>>   #define RW_MGR_MEM_DATA_WIDTH 32
>>>>
>>>> @@ -168,19 +168,20 @@
>>>>
>>>>   #define TRESET_CNTR2_VAL 10
>>>>   /* Sequencer ac_rom_init configuration */
>>>> -const u32 ac_rom_init[] = {
>>>> +const u32 ac_rom_init[] =
>>>> +{
>>>>    0x20700000,
>>>>    0x20780000,
>>>>    0x10080431,
>>>>    0x10080530,
>>>>    0x10090044,
>>>> - 0x100a0008,
>>>> + 0x100a0010,
>>>>    0x100b0000,
>>>>    0x10380400,
>>>>    0x10080449,
>>>>    0x100804c8,
>>>>    0x100a0024,
>>>> - 0x10090010,
>>>> + 0x10090008,
>>>>    0x100b0000,
>>>>    0x30780000,
>>>>    0x38780000,
>>>>
>>>> @@ -208,7 +209,8 @@
>>>>   };
>>>>
>>>>
>>>>   /* Sequencer inst_rom_init configuration */
>>>> -const u32 inst_rom_init[] = {
>>>> +const u32 inst_rom_init[] =
>>>> +{
>>>>    0x80000,
>>>>    0x80680,
>>>>    0x8180,
>>>>
>>>> ---
>>>> /home/mcis/altera/uboot-native/u-boot-socfpga-2016.01/board/terasic/sockit/qts/pll_config.h.orig
>>>>
>>>> +++
>>>> /home/mcis/altera/uboot-native/u-boot-socfpga-2016.01/board/terasic/sockit/qts/pll_config.h
>>>>
>>>> @@ -16,7 +16,7 @@
>>>>   #define CONFIG_HPS_MAINPLLGRP_DBGATCLK_CNT 0
>>>>   #define CONFIG_HPS_MAINPLLGRP_MAINQSPICLK_CNT 4
>>>>   #define CONFIG_HPS_MAINPLLGRP_MAINNANDSDMMCCLK_CNT 511
>>>> -#define CONFIG_HPS_MAINPLLGRP_CFGS2FUSER0CLK_CNT 14
>>>> +#define CONFIG_HPS_MAINPLLGRP_CFGS2FUSER0CLK_CNT 18
>>>>   #define CONFIG_HPS_MAINPLLGRP_MAINDIV_L3MPCLK 1
>>>>   #define CONFIG_HPS_MAINPLLGRP_MAINDIV_L3SPCLK 1
>>>>   #define CONFIG_HPS_MAINPLLGRP_MAINDIV_L4MPCLK 1
>>>>
>>>>
>>>>> I'm using the Quartus 15.0 tool chain at the moment.
>>>>> Turning on debugging in drivers/ddr/altera/sequencer.c may help.
>>>>>
>>>>
>>>> Setting DLEVEL = 2 yields:
>>>>
>>>> U-Boot SPL 2016.01 (Mar 03 2016 - 06:28:33)
>>>> drivers/ddr/altera/sequencer.c: Preparing to start memory calibration
>>>> find_vfifo_failing_read:1519: vfifo 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> find_vfifo_failing_read:1519: vfifo 1
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1864 p: ptap=4
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1877 p/d: ptap=4 dtap=7
>>>> end=16399
>>>> rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1887 found range
>>>> [14003,16399]
>>>> rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1895 calculate
>>>> dtaps_per_ptap for tracking
>>>> rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1906 backedup phase only:
>>>> p=3rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1919 find passing read
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>>> rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1927 find failing read
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) => 0
>>>> rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase:1948 dtaps_per_ptap=21 -
>>>> 8 = 13work_bgn=14003 work_end=16399 work_mid=15201
>>>> vfifo ptap delay 2496
>>>> new work_mid 225
>>>> new p 0, tmp_delay=0
>>>> new d 9, tmp_delay=225
>>>> find_dqs_en_phase: center
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (31 != 0) => 1
>>>> sdr_find_window_center:1779 center: found: ptap=0 dtap=9
>>>> rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0) => 1
>>>> search_stop_check:2006 center(left): dtap=0 => 255 == 255 &&
>>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>>>> => 1
>>>> search_stop_check:2006 center(left): dtap=1 => 255 == 255 &&
>>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>>>> => 1
>>>> search_stop_check:2006 center(left): dtap=2 => 255 == 255 &&
>>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>>>> => 1
>>>> search_stop_check:2006 center(left): dtap=3 => 255 == 255 &&
>>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>>>> => 1
>>>> search_stop_check:2006 center(left): dtap=4 => 255 == 255 &&
>>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>>>> => 1
>>>> search_stop_check:2006 center(left): dtap=5 => 255 == 255 &&
>>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>>>> => 1
>>>> search_stop_check:2006 center(left): dtap=6 => 255 == 255 &&
>>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>>>> => 1
>>>> search_stop_check:2006 center(left): dtap=7 => 255 == 255 &&
>>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>>>> => 1
>>>> search_stop_check:2006 center(left): dtap=8 => 255 == 255 &&
>>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>>>> => 1
>>>> search_stop_check:2006 center(left): dtap=9 => 255 == 255 &&
>>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>>>> => 1
>>>> search_stop_check:2006 center(left): dtap=10 => 255 == 255 &&
>>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>>>> => 1
>>>> search_stop_check:2006 center(left): dtap=11 => 255 == 255 &&
>>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>>>> => 1
>>>> search_stop_check:2006 center(left): dtap=12 => 255 == 255 &&
>>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>>>> => 1
>>>> search_stop_check:2006 center(left): dtap=13 => 255 == 255 &&
>>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>>>> => 1
>>>> search_stop_check:2006 center(left): dtap=14 => 255 == 255 &&
>>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (255 != 0)
>>>> => 1
>>>> search_stop_check:2006 center(left): dtap=15 => 255 == 255 &&
>>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (187 != 0)
>>>> => 1
>>>> search_stop_check:2006 center(left): dtap=16 => 255 == 255 &&
>>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (179 != 0)
>>>> => 1
>>>> search_stop_check:2006 center(left): dtap=17 => 255 == 255 &&
>>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (19 != 0)
>>>> => 1
>>>> search_stop_check:2006 center(left): dtap=18 => 255 == 255 &&
>>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (17 != 0)
>>>> => 1
>>>> search_stop_check:2006 center(left): dtap=19 => 255 == 255 &&
>>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (16 != 0)
>>>> => 1
>>>> search_stop_check:2006 center(left): dtap=20 => 255 == 255 &&
>>>> 0rw_mgr_mem_calibrate_read_test:1457 read_test(0,ONE,0) => (0 != 0) =>
>>>> 0
>>>> search_stop_check:2006 center(left): dtap=21 => 255 == 255 &&?
>>>>
>>>> Will try to make sense of these today...
>>>>
>>>> Any insights welcome!
>>>>
>>>
>>> Any success.
>>>
>>> You've reached the limits of my knowledge.
>>> The diff shows that there are differences in config.
>>> Failure of Memory Calibration has always been my biggest fear with
>>> hardware design.
>>>
>>> Interesting that the 2013.01 build from the Quartus tools works.
>>> But the 2016.01 using the same qts generated files does not.
>>> Which would suggest there is something amiss in the code.
>>>
>>> Is there similar debug statements in the 2013.01 code?
>>
>> There is debug(), which you can enable by adding #define DEBUG at the
>> beginning of drivers/ddr/altera/*.c . The other way of tracking down
>> this bug would be to rig the writel()/readl() calls and check what
>> values they use compared to the original altera code.
>
> Thanks, Phil. I will see what the 2013.01 debug produces. But below is
> what I see if I add DEBUG to the 2016.03-rc3 code.
>
> Marek -
> The marking on my DDR parts is 4NE77 D9PXV which translates to
> Micron part# MT41K256M16HA-125:E. I was looking at the data sheet
> to see if I could further manually relax some of the settings in
> sdram_config.h. I was also wondering what DDR parts you have on your
> boards. Given that your two Rev. D boards work fine, I'm beginning to
> think mine is defective and I'd be better off to get a new one.
>
>
> Best regards,
> --George Broz
>
>
> U-Boot SPL 2016.03-rc3 (Mar 08 2016 - 15:46:07)
> scc_mgr_initialize:281: Clearing SCC RFILE index 0
> scc_mgr_initialize:281: Clearing SCC RFILE index 1
> scc_mgr_initialize:281: Clearing SCC RFILE index 2
> scc_mgr_initialize:281: Clearing SCC RFILE index 3
> scc_mgr_initialize:281: Clearing SCC RFILE index 4
> scc_mgr_initialize:281: Clearing SCC RFILE index 5
> scc_mgr_initialize:281: Clearing SCC RFILE index 6
> scc_mgr_initialize:281: Clearing SCC RFILE index 7
> scc_mgr_initialize:281: Clearing SCC RFILE index 8
> scc_mgr_initialize:281: Clearing SCC RFILE index 9
> scc_mgr_initialize:281: Clearing SCC RFILE index 10
> scc_mgr_initialize:281: Clearing SCC RFILE index 11
> scc_mgr_initialize:281: Clearing SCC RFILE index 12
> scc_mgr_initialize:281: Clearing SCC RFILE index 13
> scc_mgr_initialize:281: Clearing SCC RFILE index 14
> scc_mgr_initialize:281: Clearing SCC RFILE index 15
> drivers/ddr/altera/sequencer.c: Preparing to start memory calibration
> DDR3 FULL_RATE ranks=1 cs/dimm=1 dq/dqs=8,8 vg/dqs=1,1 dqs=5,5 dq=40
> dm=5 ptap_delay=312 dtap_delay=25 dtap_dqsen_delay=25, dll=8max
> values: en_p=7 dqdqs_p=0 en_d=31 dqs_in_d=31 io_in_d=31 io_out1_d=31
> io_out2_d=0 dqs_in_reserve=4 dqs_out_reserve=6
> scc_mgr_set_hhp_extras:477 Setting HHP Extras
> scc_mgr_set_hhp_extras:480 Done Setting HHP Extras
> rw_mgr_mem_calibrate_guaranteed_write:2534 guaranteed write: g=0 p=0
> rw_mgr_mem_calibrate_read_test_patterns:1290 test_load_patterns(0,ALL)
> => (255 == 255) => 0
> rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=0 r=0 i=0 p=0 d=0
> rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=0 r=0 i=1 p=1 d=4
> rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=0 r=0 i=2 p=2 d=8
> rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=0 r=0 i=3 p=3 d=12
> rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=0 r=0 i=4 p=4 d=16
> rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=0 r=0 i=5 p=5 d=20
> rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=0 r=0 i=6 p=6 d=24
> rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=0 r=0 i=7 p=7 d=28
> rw_mgr_mem_calibrate_dqs_enable_calibration:2607: g=0 found=1;
> Reseting delay chain to zero
> get_window_mid_index:2288 vfifo_center: *mid_min=-5 (index=3)
> vfifo_center: new mid_min=-5 new_dqs=9
> vfifo_center: start_dqs=4 start_dqs_en=-1 new_dqs=9 mid_min=-5
> get_window_mid_index:2288 vfifo_center: *mid_min=2 (index=6)
> rw_mgr_mem_calibrate_writes_center:3005 write_center: start_dqs=6
> new_dqs=6 mid_min=0
> get_window_mid_index:2288 vfifo_center: *mid_min=0 (index=3)
> vfifo_center: new mid_min=0 new_dqs=9
> vfifo_center: start_dqs=9 start_dqs_en=-1 new_dqs=9 mid_min=0
> rw_mgr_mem_calibrate_guaranteed_write:2534 guaranteed write: g=1 p=0
> rw_mgr_mem_calibrate_read_test_patterns:1290 test_load_patterns(1,ALL)
> => (255 == 255) => 0
> rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=1 r=0 i=0 p=0 d=0
> rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=1 r=0 i=1 p=1 d=4
> rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=1 r=0 i=2 p=2 d=8
> rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=1 r=0 i=3 p=3 d=12
> rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=1 r=0 i=4 p=4 d=16
> rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=1 r=0 i=5 p=5 d=20
> rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=1 r=0 i=6 p=6 d=24
> rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=1 r=0 i=7 p=7 d=28
> rw_mgr_mem_calibrate_dqs_enable_calibration:2607: g=1 found=1;
> Reseting delay chain to zero
> get_window_mid_index:2288 vfifo_center: *mid_min=-4 (index=3)
> vfifo_center: new mid_min=-4 new_dqs=8
> vfifo_center: start_dqs=4 start_dqs_en=-1 new_dqs=8 mid_min=-4
> get_window_mid_index:2288 vfifo_center: *mid_min=2 (index=2)
> rw_mgr_mem_calibrate_writes_center:3005 write_center: start_dqs=6
> new_dqs=6 mid_min=0
> get_window_mid_index:2288 vfifo_center: *mid_min=-1 (index=3)
> vfifo_center: new mid_min=-1 new_dqs=9
> vfifo_center: start_dqs=8 start_dqs_en=-1 new_dqs=9 mid_min=-1
> rw_mgr_mem_calibrate_guaranteed_write:2534 guaranteed write: g=2 p=0
> rw_mgr_mem_calibrate_read_test_patterns:1290 test_load_patterns(2,ALL)
> => (255 == 255) => 0
> rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=2 r=0 i=0 p=0 d=0
> rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=2 r=0 i=1 p=1 d=4
> rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=2 r=0 i=2 p=2 d=8
> rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=2 r=0 i=3 p=3 d=12
> rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=2 r=0 i=4 p=4 d=16
> rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=2 r=0 i=5 p=5 d=20
> rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=2 r=0 i=6 p=6 d=24
> rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=2 r=0 i=7 p=7 d=28
> rw_mgr_mem_calibrate_dqs_enable_calibration:2607: g=2 found=1;
> Reseting delay chain to zero
> get_window_mid_index:2288 vfifo_center: *mid_min=-3 (index=3)
> vfifo_center: new mid_min=-3 new_dqs=7
> vfifo_center: start_dqs=4 start_dqs_en=-1 new_dqs=7 mid_min=-3
> get_window_mid_index:2288 vfifo_center: *mid_min=2 (index=2)
> rw_mgr_mem_calibrate_writes_center:3005 write_center: start_dqs=6
> new_dqs=6 mid_min=0
> get_window_mid_index:2288 vfifo_center: *mid_min=-1 (index=7)
> vfifo_center: new mid_min=-1 new_dqs=8
> vfifo_center: start_dqs=7 start_dqs_en=-1 new_dqs=8 mid_min=-1
> rw_mgr_mem_calibrate_guaranteed_write:2534 guaranteed write: g=3 p=0
> rw_mgr_mem_calibrate_read_test_patterns:1290 test_load_patterns(3,ALL)
> => (255 == 255) => 0
> rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=3 r=0 i=0 p=0 d=0
> rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=3 r=0 i=1 p=1 d=4
> rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=3 r=0 i=2 p=2 d=8
> rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=3 r=0 i=3 p=3 d=12
> rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=3 r=0 i=4 p=4 d=16
> rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=3 r=0 i=5 p=5 d=20
> rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=3 r=0 i=6 p=6 d=24
> rw_mgr_mem_calibrate_dqs_enable_calibration:2590: g=3 r=0 i=7 p=7 d=28
> rw_mgr_mem_calibrate_dqs_enable_calibration:2607: g=3 found=1;
> Reseting delay chain to zero
> get_window_mid_index:2288 vfifo_center: *mid_min=-4 (index=7)
> vfifo_center: new mid_min=-4 new_dqs=8
> vfifo_center: start_dqs=4 start_dqs_en=-1 new_dqs=8 mid_min=-4
> get_window_mid_index:2288 vfifo_center: *mid_min=1 (index=2)
> rw_mgr_mem_calibrate_writes_center:3005 write_center: start_dqs=6
> new_dqs=6 mid_min=0
> get_window_mid_index:2288 vfifo_center: *mid_min=0 (index=3)
> vfifo_center: new mid_min=0 new_dqs=8
> vfifo_center: start_dqs=8 start_dqs_en=-1 new_dqs=8 mid_min=0
> rw_mgr_mem_calibrate_guaranteed_write:2534 guaranteed write: g=4 p=0
> rw_mgr_mem_calibrate_read_test_patterns:1290 test_load_patterns(4,ALL)
> => (170 == 255) => -5
> rw_mgr_mem_calibrate_guaranteed_write:2554 Guaranteed read test failed: g=4 p=0
> scc_mgr_apply_group_all_out_delay_add:691 (4, 2) DQS: 2 > 0; adding 2 to OUT1
> scc_mgr_apply_group_all_out_delay_add:705 (4, 2) DQS: 2 > 0; adding 2 to OUT1
> rw_mgr_mem_calibrate_guaranteed_write:2534 guaranteed write: g=4 p=0
> rw_mgr_mem_calibrate_read_test_patterns:1290 test_load_patterns(4,ALL)
> => (170 == 255) => -5
> rw_mgr_mem_calibrate_guaranteed_write:2554 Guaranteed read test failed: g=4 p=0
> scc_mgr_apply_group_all_out_delay_add:691 (4, 4) DQS: 4 > 0; adding 4 to OUT1
> scc_mgr_apply_group_all_out_delay_add:705 (4, 4) DQS: 4 > 0; adding 4 to OUT1
> rw_mgr_mem_calibrate_guaranteed_write:2534 guaranteed write: g=4 p=0
> rw_mgr_mem_calibrate_read_test_patterns:1290 test_load_patterns(4,ALL)
> => (170 == 255) => -5
> rw_mgr_mem_calibrate_guaranteed_write:2554 Guaranteed read test failed: g=4 p=0
> scc_mgr_apply_group_all_out_delay_add:691 (4, 6) DQS: 6 > 0; adding 6 to OUT1
> scc_mgr_apply_group_all_out_delay_add:705 (4, 6) DQS: 6 > 0; adding 6 to OUT1
> rw_mgr_mem_calibrate_guaranteed_write:2534 guaranteed write: g=4 p=0
> rw_mgr_mem_calibrate_read_test_patterns:1290 test_load_patterns(4,ALL)
> => (170 == 255) => -5
> rw_mgr_mem_calibrate_guaranteed_write:2554 Guaranteed read test failed: g=4 p=0
> scc_mgr_apply_group_all_out_delay_add:691 (4, 8) DQS: 8 > 0; adding 8 to OUT1
> scc_mgr_apply_group_all_out_delay_add:705 (4, 8) DQS: 8 > 0; adding 8 to OUT1
> rw_mgr_mem_calibrate_guaranteed_write:2534 guaranteed write: g=4 p=0
> rw_mgr_mem_calibrate_read_test_patterns:1290 test_load_patterns(4,ALL)
> => (170 == 255) => -5
> rw_mgr_mem_calibrate_guaranteed_write:2554 Guaranteed read test failed: g=4 p=0
> scc_mgr_apply_group_all_out_delay_add:691 (4, 10) DQS: 10 > 0; adding 10 to OUT1
> scc_mgr_apply_group_all_out_delay_add:705 (4, 10) DQS: 10 > 0; adding 10 to OUT1
> rw_mgr_mem_calibrate_guaranteed_write:2534 guaranteed write: g=4 p=0
> rw_mgr_mem_calibrate_read_test_patterns:1290 test_load_patterns(4,ALL)
> => (170 == 255) => -5
> rw_mgr_mem_calibrate_guaranteed_write:2554 Guaranteed read test failed: g=4 p=0
> scc_mgr_apply_group_all_out_delay_add:691 (4, 12) DQS: 12 > 0; adding 12 to OUT1
> scc_mgr_apply_group_all_out_delay_add:705 (4, 12) DQS: 12 > 0; adding 12 to OUT1
> rw_mgr_mem_calibrate_guaranteed_write:2534 guaranteed write: g=4 p=0
> rw_mgr_mem_calibrate_read_test_patterns:1290 test_load_patterns(4,ALL)
> => (170 == 255) => -5
> rw_mgr_mem_calibrate_guaranteed_write:2554 Guaranteed read test failed: g=4 p=0
> drivers/ddr/altera/sequencer.c: CALIBRATION FAILED
> drivers/ddr/altera/sequencer.c: Calibration complete
> SDRAM calibration failed.
> ### ERROR ### Please RESET the board ###
>
>
>>
>>> I'll try and find time to build with the 2016.01 debug statements here
>>> and send you a log for comparison.
>>>
>>>
>>
>>
>> --
>> Best regards,
>> Marek Vasut

Hello again -

So under the assumption my SoCKit h/w was broken, I bought a new board.
They are back ordered on SoCKit boards, so I got a DE0-Nano-SoC instead.

I build the v2016.03 (release) version of u-boot-with-spl.sfp.

I power-up the (brand new) board and get:

U-Boot SPL 2016.03 (Mar 15 2016 - 14:52:42)
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 ###

U-Boot SPL 2016.03 (Mar 15 2016 - 14:52:42)
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 ###

U-Boot SPL 2016.03 (Mar 15 2016 - 14:52:42)
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 MMC

U-Boot 2016.03 (Mar 15 2016 - 14:52:42 -0700)

CPU:   Altera SoCFPGA Platform
FPGA:  Altera Cyclone V, SE/A4 or SX/C4, version 0x0
BOOT:  SD/MMC Internal Transceiver (3.0V)
       Watchdog enabled
I2C:   ready
DRAM:  1 GiB
MMC:   dwmmc0 at ff704000: 0
In:    serial
Out:   serial
Err:   serial
Model: Terasic DE0-Nano(Atlas)
Net:
Error: ethernet at ff702000 address not set.
No ethernet found.
Hit any key to stop autoboot:  0
=>

And this is a good case... usually it doesn't succeed after the fourth try
and I have to cycle power 4 or 5 times before I get lucky.

If I do get lucky and then try to see a USB storage device, then I get:

=>
=> usb start
starting USB...
USB0:   Core Release: 2.93a
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
scanning bus 0 for devices... 1 USB Device(s) found
=>

(Every time)

The version of u-boot SPL that ships with the board:
U-Boot SPL 2013.01.01 (Dec 29 2014 - 15:29:15)

boots every time and has limited USB capability as
it can see some USB sticks, but not others.


Anyway - brand new board - same old symptoms.

Is it perhaps a toolchain problem?? I'm using:

Thread model: posix
gcc version 4.9.3 20141031 (prerelease) (Linaro GCC 4.9-2014.11)

COLLECT_GCC=arm-poky-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/opt/poky/1.7.1/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.3/lto-wrapper
< snip >

Any advice greatly appreciated.


Regards,
--George Broz

[U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 15 March 2016 at 18:29, George Broz <brozgeo@gmail.com> wrote:

>
> Hello again -
>
> So under the assumption my SoCKit h/w was broken, I bought a new board.
> They are back ordered on SoCKit boards, so I got a DE0-Nano-SoC instead.
>
> I build the v2016.03 (release) version of u-boot-with-spl.sfp.
>
> I power-up the (brand new) board and get:
>
> U-Boot SPL 2016.03 (Mar 15 2016 - 14:52:42)
> 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 ###
>
> U-Boot SPL 2016.03 (Mar 15 2016 - 14:52:42)
> 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 ###
>
> U-Boot SPL 2016.03 (Mar 15 2016 - 14:52:42)
> 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 MMC
>
> U-Boot 2016.03 (Mar 15 2016 - 14:52:42 -0700)
>
> CPU:   Altera SoCFPGA Platform
> FPGA:  Altera Cyclone V, SE/A4 or SX/C4, version 0x0
> BOOT:  SD/MMC Internal Transceiver (3.0V)
>        Watchdog enabled
> I2C:   ready
> DRAM:  1 GiB
> MMC:   dwmmc0 at ff704000: 0
> In:    serial
> Out:   serial
> Err:   serial
> Model: Terasic DE0-Nano(Atlas)
> Net:
> Error: ethernet at ff702000 address not set.
> No ethernet found.
> Hit any key to stop autoboot:  0
> =>
>
> And this is a good case... usually it doesn't succeed after the fourth try
> and I have to cycle power 4 or 5 times before I get lucky.
>
> If I do get lucky and then try to see a USB storage device, then I get:
>
> =>
> => usb start
> starting USB...
> USB0:   Core Release: 2.93a
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout!
> scanning bus 0 for devices... 1 USB Device(s) found
> =>
>
> (Every time)
>
> The version of u-boot SPL that ships with the board:
> U-Boot SPL 2013.01.01 (Dec 29 2014 - 15:29:15)
>
> boots every time and has limited USB capability as
> it can see some USB sticks, but not others.
>
>
> Anyway - brand new board - same old symptoms.
>
> Is it perhaps a toolchain problem?? I'm using:
>
> Thread model: posix
> gcc version 4.9.3 20141031 (prerelease) (Linaro GCC 4.9-2014.11)
>
> COLLECT_GCC=arm-poky-linux-gnueabi-gcc
> COLLECT_LTO_WRAPPER=/opt/poky/1.7.1/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.3/lto-wrapper
> < snip >
>
> Any advice greatly appreciated.
>
>
> Regards,
> --George Broz

Rebuilt using the Altera EDS15.0 toolchain:

  arm-altera-eabi-gcc --version
  arm-altera-eabi-gcc (Sourcery CodeBench Lite 2014.11-13) 4.9.1
  Copyright (C) 2014 Free Software Foundation, Inc.
  This is free software; see the source for copying conditions.  There is NO
  warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Get same result ... mostly failing calibration, non-working USB....

U-Boot SPL 2016.03 (Mar 16 2016 - 08:27:20)
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 ###

U-Boot SPL 2016.03 (Mar 16 2016 - 08:27:20)
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 ###

U-Boot SPL 2016.03 (Mar 16 2016 - 08:27:20)
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 MMC


U-Boot 2016.03 (Mar 16 2016 - 08:27:20 -0700)

Does this work for anybody else?
Is it in anyone's experience that these (cheaper) Terasic
eval boards are generally out of spec?

Is there a way to relax the calibration parameters? the USB parameters?

Would it help if I posted debug output?


Thanks,
--George

[U-Boot] Newbie SPL question for socfpga_sockit

[Marek Vasut]

On 03/16/2016 05:17 PM, George Broz wrote:
> On 15 March 2016 at 18:29, George Broz <brozgeo@gmail.com> wrote:
> 
>>
>> Hello again -
>>
>> So under the assumption my SoCKit h/w was broken, I bought a new board.
>> They are back ordered on SoCKit boards, so I got a DE0-Nano-SoC instead.
>>
>> I build the v2016.03 (release) version of u-boot-with-spl.sfp.
>>
>> I power-up the (brand new) board and get:
>>
>> U-Boot SPL 2016.03 (Mar 15 2016 - 14:52:42)
>> 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 ###
>>
>> U-Boot SPL 2016.03 (Mar 15 2016 - 14:52:42)
>> 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 ###
>>
>> U-Boot SPL 2016.03 (Mar 15 2016 - 14:52:42)
>> 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 MMC
>>
>> U-Boot 2016.03 (Mar 15 2016 - 14:52:42 -0700)
>>
>> CPU:   Altera SoCFPGA Platform
>> FPGA:  Altera Cyclone V, SE/A4 or SX/C4, version 0x0
>> BOOT:  SD/MMC Internal Transceiver (3.0V)
>>        Watchdog enabled
>> I2C:   ready
>> DRAM:  1 GiB
>> MMC:   dwmmc0 at ff704000: 0
>> In:    serial
>> Out:   serial
>> Err:   serial
>> Model: Terasic DE0-Nano(Atlas)
>> Net:
>> Error: ethernet at ff702000 address not set.
>> No ethernet found.
>> Hit any key to stop autoboot:  0
>> =>
>>
>> And this is a good case... usually it doesn't succeed after the fourth try
>> and I have to cycle power 4 or 5 times before I get lucky.
>>
>> If I do get lucky and then try to see a USB storage device, then I get:
>>
>> =>
>> => usb start
>> starting USB...
>> USB0:   Core Release: 2.93a
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> scanning bus 0 for devices... 1 USB Device(s) found
>> =>
>>
>> (Every time)
>>
>> The version of u-boot SPL that ships with the board:
>> U-Boot SPL 2013.01.01 (Dec 29 2014 - 15:29:15)
>>
>> boots every time and has limited USB capability as
>> it can see some USB sticks, but not others.
>>
>>
>> Anyway - brand new board - same old symptoms.
>>
>> Is it perhaps a toolchain problem?? I'm using:
>>
>> Thread model: posix
>> gcc version 4.9.3 20141031 (prerelease) (Linaro GCC 4.9-2014.11)
>>
>> COLLECT_GCC=arm-poky-linux-gnueabi-gcc
>> COLLECT_LTO_WRAPPER=/opt/poky/1.7.1/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.3/lto-wrapper
>> < snip >
>>
>> Any advice greatly appreciated.
>>
>>
>> Regards,
>> --George Broz
> 
> Rebuilt using the Altera EDS15.0 toolchain:
> 
>   arm-altera-eabi-gcc --version
>   arm-altera-eabi-gcc (Sourcery CodeBench Lite 2014.11-13) 4.9.1
>   Copyright (C) 2014 Free Software Foundation, Inc.
>   This is free software; see the source for copying conditions.  There is NO
>   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> 
> Get same result ... mostly failing calibration, non-working USB....
> 
> U-Boot SPL 2016.03 (Mar 16 2016 - 08:27:20)
> 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 ###
> 
> U-Boot SPL 2016.03 (Mar 16 2016 - 08:27:20)
> 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 ###
> 
> U-Boot SPL 2016.03 (Mar 16 2016 - 08:27:20)
> 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 MMC
> 
> 
> U-Boot 2016.03 (Mar 16 2016 - 08:27:20 -0700)
> 
> Does this work for anybody else?
> Is it in anyone's experience that these (cheaper) Terasic
> eval boards are generally out of spec?
> 
> Is there a way to relax the calibration parameters? the USB parameters?
> 
> Would it help if I posted debug output?

Sorry for the late reply, I am horribly overloaded now. I asked someone
in #u-boot who has the DE0-NANO-SOC board to test latest u-boot/master
on it and it apparently worked for him. I should get some more feedback
in the morning [ see http://pastebin.com/CM1QJGnh ] .

Still, this is getting real creepy. You are the second person who is
complaining about misbehavior of terasic boards with mainline u-boot
and whatever I do, I cannot replicate this.

I am at least CCing the Altera guys. Sorry I have no better suggestion
for you :(

Best regards,
Marek Vasut

[U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 16 March 2016 at 18:35, Marek Vasut <marex@denx.de> wrote:
> On 03/16/2016 05:17 PM, George Broz wrote:
>> On 15 March 2016 at 18:29, George Broz <brozgeo@gmail.com> wrote:
>>
>>>
>>> Hello again -
>>>
>>> So under the assumption my SoCKit h/w was broken, I bought a new board.
>>> They are back ordered on SoCKit boards, so I got a DE0-Nano-SoC instead.
>>>
>>> I build the v2016.03 (release) version of u-boot-with-spl.sfp.
>>>
>>> I power-up the (brand new) board and get:
>>>
>>> U-Boot SPL 2016.03 (Mar 15 2016 - 14:52:42)
>>> 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 ###
>>>
>>> U-Boot SPL 2016.03 (Mar 15 2016 - 14:52:42)
>>> 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 ###
>>>
>>> U-Boot SPL 2016.03 (Mar 15 2016 - 14:52:42)
>>> 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 MMC
>>>
>>> U-Boot 2016.03 (Mar 15 2016 - 14:52:42 -0700)
>>>
>>> CPU:   Altera SoCFPGA Platform
>>> FPGA:  Altera Cyclone V, SE/A4 or SX/C4, version 0x0
>>> BOOT:  SD/MMC Internal Transceiver (3.0V)
>>>        Watchdog enabled
>>> I2C:   ready
>>> DRAM:  1 GiB
>>> MMC:   dwmmc0 at ff704000: 0
>>> In:    serial
>>> Out:   serial
>>> Err:   serial
>>> Model: Terasic DE0-Nano(Atlas)
>>> Net:
>>> Error: ethernet at ff702000 address not set.
>>> No ethernet found.
>>> Hit any key to stop autoboot:  0
>>> =>
>>>
>>> And this is a good case... usually it doesn't succeed after the fourth try
>>> and I have to cycle power 4 or 5 times before I get lucky.
>>>
>>> If I do get lucky and then try to see a USB storage device, then I get:
>>>
>>> =>
>>> => usb start
>>> starting USB...
>>> USB0:   Core Release: 2.93a
>>> dwc_otg_core_host_init: Timeout!
>>> dwc_otg_core_host_init: Timeout!
>>> dwc_otg_core_host_init: Timeout!
>>> dwc_otg_core_host_init: Timeout!
>>> dwc_otg_core_host_init: Timeout!
>>> dwc_otg_core_host_init: Timeout!
>>> dwc_otg_core_host_init: Timeout!
>>> dwc_otg_core_host_init: Timeout!
>>> dwc_otg_core_host_init: Timeout!
>>> dwc_otg_core_host_init: Timeout!
>>> dwc_otg_core_host_init: Timeout!
>>> dwc_otg_core_host_init: Timeout!
>>> dwc_otg_core_host_init: Timeout!
>>> dwc_otg_core_host_init: Timeout!
>>> dwc_otg_core_host_init: Timeout!
>>> scanning bus 0 for devices... 1 USB Device(s) found
>>> =>
>>>
>>> (Every time)
>>>
>>> The version of u-boot SPL that ships with the board:
>>> U-Boot SPL 2013.01.01 (Dec 29 2014 - 15:29:15)
>>>
>>> boots every time and has limited USB capability as
>>> it can see some USB sticks, but not others.
>>>
>>>
>>> Anyway - brand new board - same old symptoms.
>>>
>>> Is it perhaps a toolchain problem?? I'm using:
>>>
>>> Thread model: posix
>>> gcc version 4.9.3 20141031 (prerelease) (Linaro GCC 4.9-2014.11)
>>>
>>> COLLECT_GCC=arm-poky-linux-gnueabi-gcc
>>> COLLECT_LTO_WRAPPER=/opt/poky/1.7.1/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.3/lto-wrapper
>>> < snip >
>>>
>>> Any advice greatly appreciated.
>>>
>>>
>>> Regards,
>>> --George Broz
>>
>> Rebuilt using the Altera EDS15.0 toolchain:
>>
>>   arm-altera-eabi-gcc --version
>>   arm-altera-eabi-gcc (Sourcery CodeBench Lite 2014.11-13) 4.9.1
>>   Copyright (C) 2014 Free Software Foundation, Inc.
>>   This is free software; see the source for copying conditions.  There is NO
>>   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>>
>>
>> Get same result ... mostly failing calibration, non-working USB....
>>
>> U-Boot SPL 2016.03 (Mar 16 2016 - 08:27:20)
>> 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 ###
>>
>> U-Boot SPL 2016.03 (Mar 16 2016 - 08:27:20)
>> 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 ###
>>
>> U-Boot SPL 2016.03 (Mar 16 2016 - 08:27:20)
>> 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 MMC
>>
>>
>> U-Boot 2016.03 (Mar 16 2016 - 08:27:20 -0700)
>>
>> Does this work for anybody else?
>> Is it in anyone's experience that these (cheaper) Terasic
>> eval boards are generally out of spec?
>>
>> Is there a way to relax the calibration parameters? the USB parameters?
>>
>> Would it help if I posted debug output?
>
> Sorry for the late reply, I am horribly overloaded now. I asked someone
> in #u-boot who has the DE0-NANO-SOC board to test latest u-boot/master
> on it and it apparently worked for him. I should get some more feedback
> in the morning [ see http://pastebin.com/CM1QJGnh ] .
>
> Still, this is getting real creepy. You are the second person who is
> complaining about misbehavior of terasic boards with mainline u-boot
> and whatever I do, I cannot replicate this.
>
> I am at least CCing the Altera guys. Sorry I have no better suggestion
> for you :(
>
> Best regards,
> Marek Vasut


Hi Marek,

I've got a third board coming to me in the mail (another
DE0-NANO-SOC). I'll post
how that goes.If it fails, maybe I'll send it to you...

I've also sent Terasic an email.

One question - after you (your collegue's) SoCKit (Nano) get past memory
calibration, does USB work (i.e. does the u-boot USB subsystem recognize mass
storage devices)?

I'm beginning to look for solutions that don't involve rebuilding the
SPL or using USB.

Best regards,
--George Broz

[U-Boot] Newbie SPL question for socfpga_sockit

[Marek Vasut]

On 03/18/2016 07:59 PM, George Broz wrote:
> On 16 March 2016 at 18:35, Marek Vasut <marex@denx.de> wrote:
>> On 03/16/2016 05:17 PM, George Broz wrote:
>>> On 15 March 2016 at 18:29, George Broz <brozgeo@gmail.com> wrote:
>>>
>>>>
>>>> Hello again -
>>>>
>>>> So under the assumption my SoCKit h/w was broken, I bought a new board.
>>>> They are back ordered on SoCKit boards, so I got a DE0-Nano-SoC instead.
>>>>
>>>> I build the v2016.03 (release) version of u-boot-with-spl.sfp.
>>>>
>>>> I power-up the (brand new) board and get:
>>>>
>>>> U-Boot SPL 2016.03 (Mar 15 2016 - 14:52:42)
>>>> 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 ###
>>>>
>>>> U-Boot SPL 2016.03 (Mar 15 2016 - 14:52:42)
>>>> 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 ###
>>>>
>>>> U-Boot SPL 2016.03 (Mar 15 2016 - 14:52:42)
>>>> 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 MMC
>>>>
>>>> U-Boot 2016.03 (Mar 15 2016 - 14:52:42 -0700)
>>>>
>>>> CPU:   Altera SoCFPGA Platform
>>>> FPGA:  Altera Cyclone V, SE/A4 or SX/C4, version 0x0
>>>> BOOT:  SD/MMC Internal Transceiver (3.0V)
>>>>        Watchdog enabled
>>>> I2C:   ready
>>>> DRAM:  1 GiB
>>>> MMC:   dwmmc0 at ff704000: 0
>>>> In:    serial
>>>> Out:   serial
>>>> Err:   serial
>>>> Model: Terasic DE0-Nano(Atlas)
>>>> Net:
>>>> Error: ethernet at ff702000 address not set.
>>>> No ethernet found.
>>>> Hit any key to stop autoboot:  0
>>>> =>
>>>>
>>>> And this is a good case... usually it doesn't succeed after the fourth try
>>>> and I have to cycle power 4 or 5 times before I get lucky.
>>>>
>>>> If I do get lucky and then try to see a USB storage device, then I get:
>>>>
>>>> =>
>>>> => usb start
>>>> starting USB...
>>>> USB0:   Core Release: 2.93a
>>>> dwc_otg_core_host_init: Timeout!
>>>> dwc_otg_core_host_init: Timeout!
>>>> dwc_otg_core_host_init: Timeout!
>>>> dwc_otg_core_host_init: Timeout!
>>>> dwc_otg_core_host_init: Timeout!
>>>> dwc_otg_core_host_init: Timeout!
>>>> dwc_otg_core_host_init: Timeout!
>>>> dwc_otg_core_host_init: Timeout!
>>>> dwc_otg_core_host_init: Timeout!
>>>> dwc_otg_core_host_init: Timeout!
>>>> dwc_otg_core_host_init: Timeout!
>>>> dwc_otg_core_host_init: Timeout!
>>>> dwc_otg_core_host_init: Timeout!
>>>> dwc_otg_core_host_init: Timeout!
>>>> dwc_otg_core_host_init: Timeout!
>>>> scanning bus 0 for devices... 1 USB Device(s) found
>>>> =>
>>>>
>>>> (Every time)
>>>>
>>>> The version of u-boot SPL that ships with the board:
>>>> U-Boot SPL 2013.01.01 (Dec 29 2014 - 15:29:15)
>>>>
>>>> boots every time and has limited USB capability as
>>>> it can see some USB sticks, but not others.
>>>>
>>>>
>>>> Anyway - brand new board - same old symptoms.
>>>>
>>>> Is it perhaps a toolchain problem?? I'm using:
>>>>
>>>> Thread model: posix
>>>> gcc version 4.9.3 20141031 (prerelease) (Linaro GCC 4.9-2014.11)
>>>>
>>>> COLLECT_GCC=arm-poky-linux-gnueabi-gcc
>>>> COLLECT_LTO_WRAPPER=/opt/poky/1.7.1/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.3/lto-wrapper
>>>> < snip >
>>>>
>>>> Any advice greatly appreciated.
>>>>
>>>>
>>>> Regards,
>>>> --George Broz
>>>
>>> Rebuilt using the Altera EDS15.0 toolchain:
>>>
>>>   arm-altera-eabi-gcc --version
>>>   arm-altera-eabi-gcc (Sourcery CodeBench Lite 2014.11-13) 4.9.1
>>>   Copyright (C) 2014 Free Software Foundation, Inc.
>>>   This is free software; see the source for copying conditions.  There is NO
>>>   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>>>
>>>
>>> Get same result ... mostly failing calibration, non-working USB....
>>>
>>> U-Boot SPL 2016.03 (Mar 16 2016 - 08:27:20)
>>> 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 ###
>>>
>>> U-Boot SPL 2016.03 (Mar 16 2016 - 08:27:20)
>>> 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 ###
>>>
>>> U-Boot SPL 2016.03 (Mar 16 2016 - 08:27:20)
>>> 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 MMC
>>>
>>>
>>> U-Boot 2016.03 (Mar 16 2016 - 08:27:20 -0700)
>>>
>>> Does this work for anybody else?
>>> Is it in anyone's experience that these (cheaper) Terasic
>>> eval boards are generally out of spec?
>>>
>>> Is there a way to relax the calibration parameters? the USB parameters?
>>>
>>> Would it help if I posted debug output?
>>
>> Sorry for the late reply, I am horribly overloaded now. I asked someone
>> in #u-boot who has the DE0-NANO-SOC board to test latest u-boot/master
>> on it and it apparently worked for him. I should get some more feedback
>> in the morning [ see http://pastebin.com/CM1QJGnh ] .
>>
>> Still, this is getting real creepy. You are the second person who is
>> complaining about misbehavior of terasic boards with mainline u-boot
>> and whatever I do, I cannot replicate this.
>>
>> I am at least CCing the Altera guys. Sorry I have no better suggestion
>> for you :(
>>
>> Best regards,
>> Marek Vasut
> 
> 
> Hi Marek,
> 
> I've got a third board coming to me in the mail (another
> DE0-NANO-SOC). I'll post
> how that goes.If it fails, maybe I'll send it to you...
> 
> I've also sent Terasic an email.
> 
> One question - after you (your collegue's) SoCKit (Nano) get past memory
> calibration, does USB work (i.e. does the u-boot USB subsystem recognize mass
> storage devices)?
> 
> I'm beginning to look for solutions that don't involve rebuilding the
> SPL or using USB.

Try "dcache off" before "usb reset", I had trouble with usb in recent
versions due to cache problems. If this works, I am happy to give you
a workaround, but I would also love a real solution ... which I do not
have for 3+ months now :'-(

Best regards,
Marek Vasut

[U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 18 March 2016 at 12:32, Marek Vasut <marex@denx.de> wrote:
> On 03/18/2016 07:59 PM, George Broz wrote:
>> On 16 March 2016 at 18:35, Marek Vasut <marex@denx.de> wrote:
>>> On 03/16/2016 05:17 PM, George Broz wrote:
>>>> On 15 March 2016 at 18:29, George Broz <brozgeo@gmail.com> wrote:
>>>>
>>>>>
>>>>> Hello again -
>>>>>
>>>>> So under the assumption my SoCKit h/w was broken, I bought a new board.
>>>>> They are back ordered on SoCKit boards, so I got a DE0-Nano-SoC instead.
>>>>>
>>>>> I build the v2016.03 (release) version of u-boot-with-spl.sfp.
>>>>>
>>>>> I power-up the (brand new) board and get:
>>>>>
>>>>> U-Boot SPL 2016.03 (Mar 15 2016 - 14:52:42)
>>>>> 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 ###
>>>>>
>>>>> U-Boot SPL 2016.03 (Mar 15 2016 - 14:52:42)
>>>>> 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 ###
>>>>>
>>>>> U-Boot SPL 2016.03 (Mar 15 2016 - 14:52:42)
>>>>> 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 MMC
>>>>>
>>>>> U-Boot 2016.03 (Mar 15 2016 - 14:52:42 -0700)
>>>>>
>>>>> CPU:   Altera SoCFPGA Platform
>>>>> FPGA:  Altera Cyclone V, SE/A4 or SX/C4, version 0x0
>>>>> BOOT:  SD/MMC Internal Transceiver (3.0V)
>>>>>        Watchdog enabled
>>>>> I2C:   ready
>>>>> DRAM:  1 GiB
>>>>> MMC:   dwmmc0 at ff704000: 0
>>>>> In:    serial
>>>>> Out:   serial
>>>>> Err:   serial
>>>>> Model: Terasic DE0-Nano(Atlas)
>>>>> Net:
>>>>> Error: ethernet at ff702000 address not set.
>>>>> No ethernet found.
>>>>> Hit any key to stop autoboot:  0
>>>>> =>
>>>>>
>>>>> And this is a good case... usually it doesn't succeed after the fourth try
>>>>> and I have to cycle power 4 or 5 times before I get lucky.
>>>>>
>>>>> If I do get lucky and then try to see a USB storage device, then I get:
>>>>>
>>>>> =>
>>>>> => usb start
>>>>> starting USB...
>>>>> USB0:   Core Release: 2.93a
>>>>> dwc_otg_core_host_init: Timeout!
>>>>> dwc_otg_core_host_init: Timeout!
>>>>> dwc_otg_core_host_init: Timeout!
>>>>> dwc_otg_core_host_init: Timeout!
>>>>> dwc_otg_core_host_init: Timeout!
>>>>> dwc_otg_core_host_init: Timeout!
>>>>> dwc_otg_core_host_init: Timeout!
>>>>> dwc_otg_core_host_init: Timeout!
>>>>> dwc_otg_core_host_init: Timeout!
>>>>> dwc_otg_core_host_init: Timeout!
>>>>> dwc_otg_core_host_init: Timeout!
>>>>> dwc_otg_core_host_init: Timeout!
>>>>> dwc_otg_core_host_init: Timeout!
>>>>> dwc_otg_core_host_init: Timeout!
>>>>> dwc_otg_core_host_init: Timeout!
>>>>> scanning bus 0 for devices... 1 USB Device(s) found
>>>>> =>
>>>>>
>>>>> (Every time)
>>>>>
>>>>> The version of u-boot SPL that ships with the board:
>>>>> U-Boot SPL 2013.01.01 (Dec 29 2014 - 15:29:15)
>>>>>
>>>>> boots every time and has limited USB capability as
>>>>> it can see some USB sticks, but not others.
>>>>>
>>>>>
>>>>> Anyway - brand new board - same old symptoms.
>>>>>
>>>>> Is it perhaps a toolchain problem?? I'm using:
>>>>>
>>>>> Thread model: posix
>>>>> gcc version 4.9.3 20141031 (prerelease) (Linaro GCC 4.9-2014.11)
>>>>>
>>>>> COLLECT_GCC=arm-poky-linux-gnueabi-gcc
>>>>> COLLECT_LTO_WRAPPER=/opt/poky/1.7.1/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.3/lto-wrapper
>>>>> < snip >
>>>>>
>>>>> Any advice greatly appreciated.
>>>>>
>>>>>
>>>>> Regards,
>>>>> --George Broz
>>>>
>>>> Rebuilt using the Altera EDS15.0 toolchain:
>>>>
>>>>   arm-altera-eabi-gcc --version
>>>>   arm-altera-eabi-gcc (Sourcery CodeBench Lite 2014.11-13) 4.9.1
>>>>   Copyright (C) 2014 Free Software Foundation, Inc.
>>>>   This is free software; see the source for copying conditions.  There is NO
>>>>   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>>>>
>>>>
>>>> Get same result ... mostly failing calibration, non-working USB....
>>>>
>>>> U-Boot SPL 2016.03 (Mar 16 2016 - 08:27:20)
>>>> 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 ###
>>>>
>>>> U-Boot SPL 2016.03 (Mar 16 2016 - 08:27:20)
>>>> 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 ###
>>>>
>>>> U-Boot SPL 2016.03 (Mar 16 2016 - 08:27:20)
>>>> 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 MMC
>>>>
>>>>
>>>> U-Boot 2016.03 (Mar 16 2016 - 08:27:20 -0700)
>>>>
>>>> Does this work for anybody else?
>>>> Is it in anyone's experience that these (cheaper) Terasic
>>>> eval boards are generally out of spec?
>>>>
>>>> Is there a way to relax the calibration parameters? the USB parameters?
>>>>
>>>> Would it help if I posted debug output?
>>>
>>> Sorry for the late reply, I am horribly overloaded now. I asked someone
>>> in #u-boot who has the DE0-NANO-SOC board to test latest u-boot/master
>>> on it and it apparently worked for him. I should get some more feedback
>>> in the morning [ see http://pastebin.com/CM1QJGnh ] .
>>>
>>> Still, this is getting real creepy. You are the second person who is
>>> complaining about misbehavior of terasic boards with mainline u-boot
>>> and whatever I do, I cannot replicate this.
>>>
>>> I am at least CCing the Altera guys. Sorry I have no better suggestion
>>> for you :(
>>>
>>> Best regards,
>>> Marek Vasut
>>
>>
>> Hi Marek,
>>
>> I've got a third board coming to me in the mail (another
>> DE0-NANO-SOC). I'll post
>> how that goes.If it fails, maybe I'll send it to you...
>>
>> I've also sent Terasic an email.
>>
>> One question - after you (your collegue's) SoCKit (Nano) get past memory
>> calibration, does USB work (i.e. does the u-boot USB subsystem recognize mass
>> storage devices)?
>>
>> I'm beginning to look for solutions that don't involve rebuilding the
>> SPL or using USB.
>
> Try "dcache off" before "usb reset", I had trouble with usb in recent
> versions due to cache problems. If this works, I am happy to give you
> a workaround, but I would also love a real solution ... which I do not
> have for 3+ months now :'-(
>
> Best regards,
> Marek Vasut

Thanks, but nope - same story:
=> dcache off
=> dcache
Data (writethrough) Cache is OFF
=> usb reset
resetting USB...
USB0:   Core Release: 0.000
SNPSID invalid (not DWC2 OTG device): 00000000
Port not available.
USB1:   Core Release: 2.93a
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout! ...
:
:


Best regards,
--George Broz

[U-Boot] Newbie SPL question for socfpga_sockit

[Phil Reid]

On 19/03/2016 5:22 AM, George Broz wrote:
> On 18 March 2016 at 12:32, Marek Vasut <marex@denx.de> wrote:
>> On 03/18/2016 07:59 PM, George Broz wrote:
>>> On 16 March 2016 at 18:35, Marek Vasut <marex@denx.de> wrote:
>>>> On 03/16/2016 05:17 PM, George Broz wrote:
>>>>> On 15 March 2016 at 18:29, George Broz <brozgeo@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>> Hello again -
>>>>>>
>>>>>> So under the assumption my SoCKit h/w was broken, I bought a new board.
>>>>>> They are back ordered on SoCKit boards, so I got a DE0-Nano-SoC instead.
>>>>>>
>>>>>> I build the v2016.03 (release) version of u-boot-with-spl.sfp.
>>>>>>
>>>>>> I power-up the (brand new) board and get:
>>>>>>
>>>>>> U-Boot SPL 2016.03 (Mar 15 2016 - 14:52:42)
>>>>>> 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 ###
>>>>>>
>>>>>> U-Boot SPL 2016.03 (Mar 15 2016 - 14:52:42)
>>>>>> 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 ###
>>>>>>
>>>>>> U-Boot SPL 2016.03 (Mar 15 2016 - 14:52:42)
>>>>>> 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 MMC
>>>>>>
>>>>>> U-Boot 2016.03 (Mar 15 2016 - 14:52:42 -0700)
>>>>>>
>>>>>> CPU:   Altera SoCFPGA Platform
>>>>>> FPGA:  Altera Cyclone V, SE/A4 or SX/C4, version 0x0
>>>>>> BOOT:  SD/MMC Internal Transceiver (3.0V)
>>>>>>         Watchdog enabled
>>>>>> I2C:   ready
>>>>>> DRAM:  1 GiB
>>>>>> MMC:   dwmmc0 at ff704000: 0
>>>>>> In:    serial
>>>>>> Out:   serial
>>>>>> Err:   serial
>>>>>> Model: Terasic DE0-Nano(Atlas)
>>>>>> Net:
>>>>>> Error: ethernet at ff702000 address not set.
>>>>>> No ethernet found.
>>>>>> Hit any key to stop autoboot:  0
>>>>>> =>
>>>>>>
>>>>>> And this is a good case... usually it doesn't succeed after the fourth try
>>>>>> and I have to cycle power 4 or 5 times before I get lucky.
>>>>>>
>>>>>> If I do get lucky and then try to see a USB storage device, then I get:
>>>>>>
>>>>>> =>
>>>>>> => usb start
>>>>>> starting USB...
>>>>>> USB0:   Core Release: 2.93a
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> scanning bus 0 for devices... 1 USB Device(s) found
>>>>>> =>
>>>>>>
>>>>>> (Every time)
>>>>>>
>>>>>> The version of u-boot SPL that ships with the board:
>>>>>> U-Boot SPL 2013.01.01 (Dec 29 2014 - 15:29:15)
>>>>>>
>>>>>> boots every time and has limited USB capability as
>>>>>> it can see some USB sticks, but not others.
>>>>>>
>>>>>>
>>>>>> Anyway - brand new board - same old symptoms.
>>>>>>
>>>>>> Is it perhaps a toolchain problem?? I'm using:
>>>>>>
>>>>>> Thread model: posix
>>>>>> gcc version 4.9.3 20141031 (prerelease) (Linaro GCC 4.9-2014.11)
>>>>>>
>>>>>> COLLECT_GCC=arm-poky-linux-gnueabi-gcc
>>>>>> COLLECT_LTO_WRAPPER=/opt/poky/1.7.1/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.3/lto-wrapper
>>>>>> < snip >
>>>>>>
>>>>>> Any advice greatly appreciated.
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> --George Broz
>>>>>
>>>>> Rebuilt using the Altera EDS15.0 toolchain:
>>>>>
>>>>>    arm-altera-eabi-gcc --version
>>>>>    arm-altera-eabi-gcc (Sourcery CodeBench Lite 2014.11-13) 4.9.1
>>>>>    Copyright (C) 2014 Free Software Foundation, Inc.
>>>>>    This is free software; see the source for copying conditions.  There is NO
>>>>>    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>>>>>
>>>>>
>>>>> Get same result ... mostly failing calibration, non-working USB....
>>>>>
>>>>> U-Boot SPL 2016.03 (Mar 16 2016 - 08:27:20)
>>>>> 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 ###
>>>>>
>>>>> U-Boot SPL 2016.03 (Mar 16 2016 - 08:27:20)
>>>>> 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 ###
>>>>>
>>>>> U-Boot SPL 2016.03 (Mar 16 2016 - 08:27:20)
>>>>> 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 MMC
>>>>>
>>>>>
>>>>> U-Boot 2016.03 (Mar 16 2016 - 08:27:20 -0700)
>>>>>
>>>>> Does this work for anybody else?
>>>>> Is it in anyone's experience that these (cheaper) Terasic
>>>>> eval boards are generally out of spec?
>>>>>
>>>>> Is there a way to relax the calibration parameters? the USB parameters?
>>>>>
>>>>> Would it help if I posted debug output?
>>>>
>>>> Sorry for the late reply, I am horribly overloaded now. I asked someone
>>>> in #u-boot who has the DE0-NANO-SOC board to test latest u-boot/master
>>>> on it and it apparently worked for him. I should get some more feedback
>>>> in the morning [ see http://pastebin.com/CM1QJGnh ] .
>>>>
>>>> Still, this is getting real creepy. You are the second person who is
>>>> complaining about misbehavior of terasic boards with mainline u-boot
>>>> and whatever I do, I cannot replicate this.
>>>>
>>>> I am at least CCing the Altera guys. Sorry I have no better suggestion
>>>> for you :(
>>>>
>>>> Best regards,
>>>> Marek Vasut
>>>
>>>
>>> Hi Marek,
>>>
>>> I've got a third board coming to me in the mail (another
>>> DE0-NANO-SOC). I'll post
>>> how that goes.If it fails, maybe I'll send it to you...
>>>
>>> I've also sent Terasic an email.
>>>
>>> One question - after you (your collegue's) SoCKit (Nano) get past memory
>>> calibration, does USB work (i.e. does the u-boot USB subsystem recognize mass
>>> storage devices)?
>>>
>>> I'm beginning to look for solutions that don't involve rebuilding the
>>> SPL or using USB.
>>
>> Try "dcache off" before "usb reset", I had trouble with usb in recent
>> versions due to cache problems. If this works, I am happy to give you
>> a workaround, but I would also love a real solution ... which I do not
>> have for 3+ months now :'-(
>>
>> Best regards,
>> Marek Vasut
>
> Thanks, but nope - same story:
> => dcache off
> => dcache
> Data (writethrough) Cache is OFF
> => usb reset
> resetting USB...
> USB0:   Core Release: 0.000
> SNPSID invalid (not DWC2 OTG device): 00000000
> Port not available.
> USB1:   Core Release: 2.93a
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout! ...
> :
> :
>

USB worked on my board for 2016.1
Don't think I did anything special.
Testing was limited, could see files on the USB partition etc.



-- 
Regards
Phil Reid

[U-Boot] Newbie SPL question for socfpga_sockit

[Dinh Nguyen]

On 03/16/2016 08:35 PM, Marek Vasut wrote:
>>
>> Does this work for anybody else?
>> Is it in anyone's experience that these (cheaper) Terasic
>> eval boards are generally out of spec?
>>
>> Is there a way to relax the calibration parameters? the USB parameters?
>>
>> Would it help if I posted debug output?
> 
> Sorry for the late reply, I am horribly overloaded now. I asked someone
> in #u-boot who has the DE0-NANO-SOC board to test latest u-boot/master
> on it and it apparently worked for him. I should get some more feedback
> in the morning [ see http://pastebin.com/CM1QJGnh ] .
> 
> Still, this is getting real creepy. You are the second person who is
> complaining about misbehavior of terasic boards with mainline u-boot
> and whatever I do, I cannot replicate this.
> 
> I am at least CCing the Altera guys. Sorry I have no better suggestion
> for you :(

I don't have any problems with mainline U-Boot and SPL on my DE0-NANO-BOARD:

U-Boot SPL 2016.03-00307-ge4fb863 (Mar 20 2016 - 10:37:13)
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 MMC


U-Boot 2016.03-00307-ge4fb863 (Mar 20 2016 - 10:37:13 -0500)

CPU:   Altera SoCFPGA Platform
FPGA:  Altera Cyclone V, SE/A4 or SX/C4, version 0x0
BOOT:  SD/MMC Internal Transceiver (3.0V)
       Watchdog enabled
I2C:   ready
DRAM:  1 GiB
MMC:   dwmmc0 at ff704000: 0
In:    serial
Out:   serial
Err:   serial
Model: Terasic DE0-Nano(Atlas)
Net:   eth0: ethernet at ff702000
Hit any key to stop autoboot:  0
=>

Sorry, I know that doesn't help. So let's walk through my workflow. I am
not using any Altera tools when I build.

$make socfpga_de0_nano_soc_defconfig
$make u-boot-with-spl.sfp
$dd if=u-boot-with-spl.sfp of=/dev/sdb3

My gcc is: arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3

Has the board ever worked for you at all? Can you try this image:

https://rocketboards.org/foswiki/view/Documentation/AtlasSoCSdCardImage

Dinh

[U-Boot] Newbie SPL question for socfpga_sockit

[Marek Vasut]

On 03/20/2016 04:55 PM, Dinh Nguyen wrote:
> 
> 
> On 03/16/2016 08:35 PM, Marek Vasut wrote:
>>>
>>> Does this work for anybody else?
>>> Is it in anyone's experience that these (cheaper) Terasic
>>> eval boards are generally out of spec?
>>>
>>> Is there a way to relax the calibration parameters? the USB parameters?
>>>
>>> Would it help if I posted debug output?
>>
>> Sorry for the late reply, I am horribly overloaded now. I asked someone
>> in #u-boot who has the DE0-NANO-SOC board to test latest u-boot/master
>> on it and it apparently worked for him. I should get some more feedback
>> in the morning [ see http://pastebin.com/CM1QJGnh ] .
>>
>> Still, this is getting real creepy. You are the second person who is
>> complaining about misbehavior of terasic boards with mainline u-boot
>> and whatever I do, I cannot replicate this.
>>
>> I am at least CCing the Altera guys. Sorry I have no better suggestion
>> for you :(
> 
> I don't have any problems with mainline U-Boot and SPL on my DE0-NANO-BOARD:
> 
> U-Boot SPL 2016.03-00307-ge4fb863 (Mar 20 2016 - 10:37:13)
> 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 MMC
> 
> 
> U-Boot 2016.03-00307-ge4fb863 (Mar 20 2016 - 10:37:13 -0500)
> 
> CPU:   Altera SoCFPGA Platform
> FPGA:  Altera Cyclone V, SE/A4 or SX/C4, version 0x0
> BOOT:  SD/MMC Internal Transceiver (3.0V)
>        Watchdog enabled
> I2C:   ready
> DRAM:  1 GiB
> MMC:   dwmmc0 at ff704000: 0
> In:    serial
> Out:   serial
> Err:   serial
> Model: Terasic DE0-Nano(Atlas)
> Net:   eth0: ethernet at ff702000
> Hit any key to stop autoboot:  0
> =>
> 
> Sorry, I know that doesn't help. So let's walk through my workflow. I am
> not using any Altera tools when I build.
> 
> $make socfpga_de0_nano_soc_defconfig
> $make u-boot-with-spl.sfp
> $dd if=u-boot-with-spl.sfp of=/dev/sdb3
> 
> My gcc is: arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3
> 
> Has the board ever worked for you at all? Can you try this image:
> 
> https://rocketboards.org/foswiki/view/Documentation/AtlasSoCSdCardImage
> 
> Dinh

I just ported U-Boot to another customer board. I noticed QSPI has
problems and USB can be flaky. That's the standard cache issue we
have, disabling dcache fixed that.

I am starting to wonder whether we're hitting some corner case here.
Maybe we should eventually try and trace all the register reads and
writes generated by the DDR calibration code both in old and new SPL
and make a diff to see if something really did change.

Dinh, can you share the marking on the SoC and the DRAMs on your board?

Thanks!

-- 
Best regards,
Marek Vasut

[U-Boot] Newbie SPL question for socfpga_sockit

[Marek Vasut]

On 03/19/2016 12:10 PM, Phil Reid wrote:
> On 19/03/2016 5:22 AM, George Broz wrote:
>> On 18 March 2016 at 12:32, Marek Vasut <marex@denx.de> wrote:
>>> On 03/18/2016 07:59 PM, George Broz wrote:
>>>> On 16 March 2016 at 18:35, Marek Vasut <marex@denx.de> wrote:
>>>>> On 03/16/2016 05:17 PM, George Broz wrote:
>>>>>> On 15 March 2016 at 18:29, George Broz <brozgeo@gmail.com> wrote:
>>>>>>
>>>>>>>
>>>>>>> Hello again -
>>>>>>>
>>>>>>> So under the assumption my SoCKit h/w was broken, I bought a new
>>>>>>> board.
>>>>>>> They are back ordered on SoCKit boards, so I got a DE0-Nano-SoC
>>>>>>> instead.
>>>>>>>
>>>>>>> I build the v2016.03 (release) version of u-boot-with-spl.sfp.
>>>>>>>
>>>>>>> I power-up the (brand new) board and get:
>>>>>>>
>>>>>>> U-Boot SPL 2016.03 (Mar 15 2016 - 14:52:42)
>>>>>>> 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 ###
>>>>>>>
>>>>>>> U-Boot SPL 2016.03 (Mar 15 2016 - 14:52:42)
>>>>>>> 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 ###
>>>>>>>
>>>>>>> U-Boot SPL 2016.03 (Mar 15 2016 - 14:52:42)
>>>>>>> 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 MMC
>>>>>>>
>>>>>>> U-Boot 2016.03 (Mar 15 2016 - 14:52:42 -0700)
>>>>>>>
>>>>>>> CPU:   Altera SoCFPGA Platform
>>>>>>> FPGA:  Altera Cyclone V, SE/A4 or SX/C4, version 0x0
>>>>>>> BOOT:  SD/MMC Internal Transceiver (3.0V)
>>>>>>>         Watchdog enabled
>>>>>>> I2C:   ready
>>>>>>> DRAM:  1 GiB
>>>>>>> MMC:   dwmmc0 at ff704000: 0
>>>>>>> In:    serial
>>>>>>> Out:   serial
>>>>>>> Err:   serial
>>>>>>> Model: Terasic DE0-Nano(Atlas)
>>>>>>> Net:
>>>>>>> Error: ethernet at ff702000 address not set.
>>>>>>> No ethernet found.
>>>>>>> Hit any key to stop autoboot:  0
>>>>>>> =>
>>>>>>>
>>>>>>> And this is a good case... usually it doesn't succeed after the
>>>>>>> fourth try
>>>>>>> and I have to cycle power 4 or 5 times before I get lucky.
>>>>>>>
>>>>>>> If I do get lucky and then try to see a USB storage device, then
>>>>>>> I get:
>>>>>>>
>>>>>>> =>
>>>>>>> => usb start
>>>>>>> starting USB...
>>>>>>> USB0:   Core Release: 2.93a
>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>> scanning bus 0 for devices... 1 USB Device(s) found
>>>>>>> =>
>>>>>>>
>>>>>>> (Every time)
>>>>>>>
>>>>>>> The version of u-boot SPL that ships with the board:
>>>>>>> U-Boot SPL 2013.01.01 (Dec 29 2014 - 15:29:15)
>>>>>>>
>>>>>>> boots every time and has limited USB capability as
>>>>>>> it can see some USB sticks, but not others.
>>>>>>>
>>>>>>>
>>>>>>> Anyway - brand new board - same old symptoms.
>>>>>>>
>>>>>>> Is it perhaps a toolchain problem?? I'm using:
>>>>>>>
>>>>>>> Thread model: posix
>>>>>>> gcc version 4.9.3 20141031 (prerelease) (Linaro GCC 4.9-2014.11)
>>>>>>>
>>>>>>> COLLECT_GCC=arm-poky-linux-gnueabi-gcc
>>>>>>> COLLECT_LTO_WRAPPER=/opt/poky/1.7.1/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.3/lto-wrapper
>>>>>>>
>>>>>>> < snip >
>>>>>>>
>>>>>>> Any advice greatly appreciated.
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> --George Broz
>>>>>>
>>>>>> Rebuilt using the Altera EDS15.0 toolchain:
>>>>>>
>>>>>>    arm-altera-eabi-gcc --version
>>>>>>    arm-altera-eabi-gcc (Sourcery CodeBench Lite 2014.11-13) 4.9.1
>>>>>>    Copyright (C) 2014 Free Software Foundation, Inc.
>>>>>>    This is free software; see the source for copying conditions. 
>>>>>> There is NO
>>>>>>    warranty; not even for MERCHANTABILITY or FITNESS FOR A
>>>>>> PARTICULAR PURPOSE.
>>>>>>
>>>>>>
>>>>>> Get same result ... mostly failing calibration, non-working USB....
>>>>>>
>>>>>> U-Boot SPL 2016.03 (Mar 16 2016 - 08:27:20)
>>>>>> 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 ###
>>>>>>
>>>>>> U-Boot SPL 2016.03 (Mar 16 2016 - 08:27:20)
>>>>>> 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 ###
>>>>>>
>>>>>> U-Boot SPL 2016.03 (Mar 16 2016 - 08:27:20)
>>>>>> 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 MMC
>>>>>>
>>>>>>
>>>>>> U-Boot 2016.03 (Mar 16 2016 - 08:27:20 -0700)
>>>>>>
>>>>>> Does this work for anybody else?
>>>>>> Is it in anyone's experience that these (cheaper) Terasic
>>>>>> eval boards are generally out of spec?
>>>>>>
>>>>>> Is there a way to relax the calibration parameters? the USB
>>>>>> parameters?
>>>>>>
>>>>>> Would it help if I posted debug output?
>>>>>
>>>>> Sorry for the late reply, I am horribly overloaded now. I asked
>>>>> someone
>>>>> in #u-boot who has the DE0-NANO-SOC board to test latest u-boot/master
>>>>> on it and it apparently worked for him. I should get some more
>>>>> feedback
>>>>> in the morning [ see http://pastebin.com/CM1QJGnh ] .
>>>>>
>>>>> Still, this is getting real creepy. You are the second person who is
>>>>> complaining about misbehavior of terasic boards with mainline u-boot
>>>>> and whatever I do, I cannot replicate this.
>>>>>
>>>>> I am at least CCing the Altera guys. Sorry I have no better suggestion
>>>>> for you :(
>>>>>
>>>>> Best regards,
>>>>> Marek Vasut
>>>>
>>>>
>>>> Hi Marek,
>>>>
>>>> I've got a third board coming to me in the mail (another
>>>> DE0-NANO-SOC). I'll post
>>>> how that goes.If it fails, maybe I'll send it to you...
>>>>
>>>> I've also sent Terasic an email.
>>>>
>>>> One question - after you (your collegue's) SoCKit (Nano) get past
>>>> memory
>>>> calibration, does USB work (i.e. does the u-boot USB subsystem
>>>> recognize mass
>>>> storage devices)?
>>>>
>>>> I'm beginning to look for solutions that don't involve rebuilding the
>>>> SPL or using USB.
>>>
>>> Try "dcache off" before "usb reset", I had trouble with usb in recent
>>> versions due to cache problems. If this works, I am happy to give you
>>> a workaround, but I would also love a real solution ... which I do not
>>> have for 3+ months now :'-(
>>>
>>> Best regards,
>>> Marek Vasut
>>
>> Thanks, but nope - same story:
>> => dcache off
>> => dcache
>> Data (writethrough) Cache is OFF
>> => usb reset
>> resetting USB...
>> USB0:   Core Release: 0.000
>> SNPSID invalid (not DWC2 OTG device): 00000000
>> Port not available.
>> USB1:   Core Release: 2.93a
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout! ...
>> :
>> :
>>
> 
> USB worked on my board for 2016.1
> Don't think I did anything special.
> Testing was limited, could see files on the USB partition etc.

Ther are some sticks which trigger an USB issue, but it's more of an
issue in the cache configuration than the USB controller itself I think.

-- 
Best regards,
Marek Vasut

[U-Boot] Newbie SPL question for socfpga_sockit

[Marek Vasut]

On 03/18/2016 10:22 PM, George Broz wrote:
> On 18 March 2016 at 12:32, Marek Vasut <marex@denx.de> wrote:
>> On 03/18/2016 07:59 PM, George Broz wrote:
>>> On 16 March 2016 at 18:35, Marek Vasut <marex@denx.de> wrote:
>>>> On 03/16/2016 05:17 PM, George Broz wrote:
>>>>> On 15 March 2016 at 18:29, George Broz <brozgeo@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>> Hello again -
>>>>>>
>>>>>> So under the assumption my SoCKit h/w was broken, I bought a new board.
>>>>>> They are back ordered on SoCKit boards, so I got a DE0-Nano-SoC instead.
>>>>>>
>>>>>> I build the v2016.03 (release) version of u-boot-with-spl.sfp.
>>>>>>
>>>>>> I power-up the (brand new) board and get:
>>>>>>
>>>>>> U-Boot SPL 2016.03 (Mar 15 2016 - 14:52:42)
>>>>>> 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 ###
>>>>>>
>>>>>> U-Boot SPL 2016.03 (Mar 15 2016 - 14:52:42)
>>>>>> 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 ###
>>>>>>
>>>>>> U-Boot SPL 2016.03 (Mar 15 2016 - 14:52:42)
>>>>>> 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 MMC
>>>>>>
>>>>>> U-Boot 2016.03 (Mar 15 2016 - 14:52:42 -0700)
>>>>>>
>>>>>> CPU:   Altera SoCFPGA Platform
>>>>>> FPGA:  Altera Cyclone V, SE/A4 or SX/C4, version 0x0
>>>>>> BOOT:  SD/MMC Internal Transceiver (3.0V)
>>>>>>        Watchdog enabled
>>>>>> I2C:   ready
>>>>>> DRAM:  1 GiB
>>>>>> MMC:   dwmmc0 at ff704000: 0
>>>>>> In:    serial
>>>>>> Out:   serial
>>>>>> Err:   serial
>>>>>> Model: Terasic DE0-Nano(Atlas)
>>>>>> Net:
>>>>>> Error: ethernet at ff702000 address not set.
>>>>>> No ethernet found.
>>>>>> Hit any key to stop autoboot:  0
>>>>>> =>
>>>>>>
>>>>>> And this is a good case... usually it doesn't succeed after the fourth try
>>>>>> and I have to cycle power 4 or 5 times before I get lucky.
>>>>>>
>>>>>> If I do get lucky and then try to see a USB storage device, then I get:
>>>>>>
>>>>>> =>
>>>>>> => usb start
>>>>>> starting USB...
>>>>>> USB0:   Core Release: 2.93a
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> scanning bus 0 for devices... 1 USB Device(s) found
>>>>>> =>
>>>>>>
>>>>>> (Every time)
>>>>>>
>>>>>> The version of u-boot SPL that ships with the board:
>>>>>> U-Boot SPL 2013.01.01 (Dec 29 2014 - 15:29:15)
>>>>>>
>>>>>> boots every time and has limited USB capability as
>>>>>> it can see some USB sticks, but not others.
>>>>>>
>>>>>>
>>>>>> Anyway - brand new board - same old symptoms.
>>>>>>
>>>>>> Is it perhaps a toolchain problem?? I'm using:
>>>>>>
>>>>>> Thread model: posix
>>>>>> gcc version 4.9.3 20141031 (prerelease) (Linaro GCC 4.9-2014.11)
>>>>>>
>>>>>> COLLECT_GCC=arm-poky-linux-gnueabi-gcc
>>>>>> COLLECT_LTO_WRAPPER=/opt/poky/1.7.1/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.3/lto-wrapper
>>>>>> < snip >
>>>>>>
>>>>>> Any advice greatly appreciated.
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> --George Broz
>>>>>
>>>>> Rebuilt using the Altera EDS15.0 toolchain:
>>>>>
>>>>>   arm-altera-eabi-gcc --version
>>>>>   arm-altera-eabi-gcc (Sourcery CodeBench Lite 2014.11-13) 4.9.1
>>>>>   Copyright (C) 2014 Free Software Foundation, Inc.
>>>>>   This is free software; see the source for copying conditions.  There is NO
>>>>>   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>>>>>
>>>>>
>>>>> Get same result ... mostly failing calibration, non-working USB....
>>>>>
>>>>> U-Boot SPL 2016.03 (Mar 16 2016 - 08:27:20)
>>>>> 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 ###
>>>>>
>>>>> U-Boot SPL 2016.03 (Mar 16 2016 - 08:27:20)
>>>>> 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 ###
>>>>>
>>>>> U-Boot SPL 2016.03 (Mar 16 2016 - 08:27:20)
>>>>> 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 MMC
>>>>>
>>>>>
>>>>> U-Boot 2016.03 (Mar 16 2016 - 08:27:20 -0700)
>>>>>
>>>>> Does this work for anybody else?
>>>>> Is it in anyone's experience that these (cheaper) Terasic
>>>>> eval boards are generally out of spec?
>>>>>
>>>>> Is there a way to relax the calibration parameters? the USB parameters?
>>>>>
>>>>> Would it help if I posted debug output?
>>>>
>>>> Sorry for the late reply, I am horribly overloaded now. I asked someone
>>>> in #u-boot who has the DE0-NANO-SOC board to test latest u-boot/master
>>>> on it and it apparently worked for him. I should get some more feedback
>>>> in the morning [ see http://pastebin.com/CM1QJGnh ] .
>>>>
>>>> Still, this is getting real creepy. You are the second person who is
>>>> complaining about misbehavior of terasic boards with mainline u-boot
>>>> and whatever I do, I cannot replicate this.
>>>>
>>>> I am at least CCing the Altera guys. Sorry I have no better suggestion
>>>> for you :(
>>>>
>>>> Best regards,
>>>> Marek Vasut
>>>
>>>
>>> Hi Marek,
>>>
>>> I've got a third board coming to me in the mail (another
>>> DE0-NANO-SOC). I'll post
>>> how that goes.If it fails, maybe I'll send it to you...
>>>
>>> I've also sent Terasic an email.
>>>
>>> One question - after you (your collegue's) SoCKit (Nano) get past memory
>>> calibration, does USB work (i.e. does the u-boot USB subsystem recognize mass
>>> storage devices)?
>>>
>>> I'm beginning to look for solutions that don't involve rebuilding the
>>> SPL or using USB.
>>
>> Try "dcache off" before "usb reset", I had trouble with usb in recent
>> versions due to cache problems. If this works, I am happy to give you
>> a workaround, but I would also love a real solution ... which I do not
>> have for 3+ months now :'-(
>>
>> Best regards,
>> Marek Vasut
> 
> Thanks, but nope - same story:
> => dcache off
> => dcache
> Data (writethrough) Cache is OFF
> => usb reset
> resetting USB...
> USB0:   Core Release: 0.000
> SNPSID invalid (not DWC2 OTG device): 00000000
> Port not available.
> USB1:   Core Release: 2.93a
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout! ...
> :
> :

If we cannot get this sorted out and you'd be willing to ship me one of
those boards, I'd be super-glad to have one.

In the meantime, can you try the ELDK 5.8 toolchain ? You can fetch it
from [1], go into 5.8 / targets / armv5te and grab
eldk-glibc-i686-arm-toolchain.sh . Run the script and it will install
the toolchain into /opt/eldk/ . Then just source
/opt/eldk-5.8/arm*/environment* script
and build u-boot as usual.

[1]
https://www.amazon.com/clouddrive/share/ZDYTL7dwcLT1lkNoHzM4D7UoTJ4ulmPKFQBSW8IuG0I/folder/qoplba6uRqeeSDyEOnqIow

-- 
Best regards,
Marek Vasut

[U-Boot] Newbie SPL question for socfpga_sockit

[Chin Liang See]

On Fri, 2016-03-04 at 20:03 +0100, Marek Vasut wrote:
> 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 at 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 :-(

Sorry for away for a while as busy with some critical issues. 

Finally relooking back on this. I notice that with SanDisk Cruzer Blade
pendrive, U-Boot 2013.01.01 can detect it while latest cannot. The
dcache disablement at latest U-Boot doesn't help.

With that, I compared a bunch of registers from clocks, sysmgr, SCTLR,
ATCLR and USB1 too. I noticed they are similar except the
usb1.globgrp.gusbcfg.ulpiextvbusdrv. The latest U-Boot is indicating
external supply (address 0xffb4000c return value 0x00101710) while
working 2013.01.01 indicating internal charge pump (return value
0x00001710)

Wonder you guys are seeing the same too? Will dig more about this. FYI,
I tried to add lot of delay within dwc2.c but doesn't help at all.

Thanks
Chin Liang



> 
> Best regards,
> Marek Vasut

[U-Boot] Newbie SPL question for socfpga_sockit

[Chin Liang See]

On Mon, 2016-03-21 at 22:05 +0800, Chin Liang See wrote:
> On Fri, 2016-03-04 at 20:03 +0100, Marek Vasut wrote:
> > 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 at 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 :-(
> 
> Sorry for away for a while as busy with some critical issues. 
> 
> Finally relooking back on this. I notice that with SanDisk Cruzer
> Blade
> pendrive, U-Boot 2013.01.01 can detect it while latest cannot. The
> dcache disablement at latest U-Boot doesn't help.
> 
> With that, I compared a bunch of registers from clocks, sysmgr,
> SCTLR,
> ATCLR and USB1 too. I noticed they are similar except the
> usb1.globgrp.gusbcfg.ulpiextvbusdrv. The latest U-Boot is indicating
> external supply (address 0xffb4000c return value 0x00101710) while
> working 2013.01.01 indicating internal charge pump (return value
> 0x00001710)
> 
> Wonder you guys are seeing the same too? Will dig more about this.
> FYI,
> I tried to add lot of delay within dwc2.c but doesn't help at all.
> 

While modifying the USB power control of the code, I noticed the patch
made by Dinh is not there. Just realize the git clone through http from
main git doesn't work. I was able to clone but getting older version.

With getting the latest code, all my pendrive now can works with dcache
off. Its easier now as I can get consistent behaviour compared
previously. With that, dcache investigation for tomorrow then

Thanks
Chin Liang


> Thanks
> Chin Liang
> 
> 
> 
> > 
> > Best regards,

[U-Boot] Newbie SPL question for socfpga_sockit

[Dinh Nguyen]

On 03/20/2016 11:42 AM, Marek Vasut wrote:
>>
>> Sorry, I know that doesn't help. So let's walk through my workflow. I am
>> not using any Altera tools when I build.
>>
>> $make socfpga_de0_nano_soc_defconfig
>> $make u-boot-with-spl.sfp
>> $dd if=u-boot-with-spl.sfp of=/dev/sdb3
>>
>> My gcc is: arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3
>>
>> Has the board ever worked for you at all? Can you try this image:
>>
>> https://rocketboards.org/foswiki/view/Documentation/AtlasSoCSdCardImage
>>
>> Dinh
> 
> I just ported U-Boot to another customer board. I noticed QSPI has
> problems and USB can be flaky. That's the standard cache issue we
> have, disabling dcache fixed that.
> 
> I am starting to wonder whether we're hitting some corner case here.
> Maybe we should eventually try and trace all the register reads and
> writes generated by the DDR calibration code both in old and new SPL
> and make a diff to see if something really did change.
> 
> Dinh, can you share the marking on the SoC and the DRAMs on your board?
> 

My SoC is:

5CSEMA4U23C6N
CACAU1525A

DRAMs are:

ISSI 1510
IS43TR16256A
15HBL K080
P4482100QER2 TWN

Dinh

[U-Boot] Newbie SPL question for socfpga_sockit

[Chin Liang See]

On Mon, 2016-03-21 at 23:45 +0800, Chin Liang See wrote:
> On Mon, 2016-03-21 at 22:05 +0800, Chin Liang See wrote:
> > On Fri, 2016-03-04 at 20:03 +0100, Marek Vasut wrote:
> > > On 03/04/2016 05:06 PM, Dinh Nguyen wrote:
> > > > On 03/02/2016 05:24 PM, Marek Vasut wrote:

[..]

> > > > > 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 :-(
> > 
> > Sorry for away for a while as busy with some critical issues. 
> > 
> > Finally relooking back on this. I notice that with SanDisk Cruzer
> > Blade
> > pendrive, U-Boot 2013.01.01 can detect it while latest cannot. The
> > dcache disablement at latest U-Boot doesn't help.
> > 
> > With that, I compared a bunch of registers from clocks, sysmgr,
> > SCTLR,
> > ATCLR and USB1 too. I noticed they are similar except the
> > usb1.globgrp.gusbcfg.ulpiextvbusdrv. The latest U-Boot is
> > indicating
> > external supply (address 0xffb4000c return value 0x00101710) while
> > working 2013.01.01 indicating internal charge pump (return value
> > 0x00001710)
> > 
> > Wonder you guys are seeing the same too? Will dig more about this.
> > FYI,
> > I tried to add lot of delay within dwc2.c but doesn't help at all.
> > 
> 
> While modifying the USB power control of the code, I noticed the
> patch
> made by Dinh is not there. Just realize the git clone through http
> from
> main git doesn't work. I was able to clone but getting older version.
> 
> With getting the latest code, all my pendrive now can works with
> dcache
> off. Its easier now as I can get consistent behaviour compared
> previously. With that, dcache investigation for tomorrow then
> 
> Thanks
> Chin Liang
> 

Spent more time on the dcache + USB issue today. Narrow down to below
patch which can make all my USB pendrives work with dcache enabled. But
still need to understand further as not in depth familiar with dwc2.
Probably this might ring a bell to you guys?


diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
index b2f4bc6..b11d8d7 100644
--- a/drivers/usb/host/dwc2.c
+++ b/drivers/usb/host/dwc2.c
@@ -776,6 +776,7 @@ static int transfer_chunk(struct dwc2_hc_regs
*hc_regs, void *aligned_buffer,
               (num_packets << DWC2_HCTSIZ_PKTCNT_OFFSET) |
               (*pid << DWC2_HCTSIZ_PID_OFFSET),
               &hc_regs->hctsiz);
+       udelay(2);

        if (!in && xfer_len) {
                memcpy(aligned_buffer, buffer, xfer_len);


Thanks
Chin Liang

> 
> > Thanks
> > Chin Liang
> > 
> > 
> > 
> > > 

[U-Boot] SoCFPGA cache / S-bit problem - was Re: Newbie SPL question for socfpga_sockit

[Stefan Roese]

Hi Chin,

On 23.03.2016 16:00, Chin Liang See wrote:
> On Mon, 2016-03-21 at 23:45 +0800, Chin Liang See wrote:
>> On Mon, 2016-03-21 at 22:05 +0800, Chin Liang See wrote:
>>> On Fri, 2016-03-04 at 20:03 +0100, Marek Vasut wrote:
>>>> On 03/04/2016 05:06 PM, Dinh Nguyen wrote:
>>>>> On 03/02/2016 05:24 PM, Marek Vasut wrote:
>
> [..]
>
>>>>>> 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 :-(
>>>
>>> Sorry for away for a while as busy with some critical issues.
>>>
>>> Finally relooking back on this. I notice that with SanDisk Cruzer
>>> Blade
>>> pendrive, U-Boot 2013.01.01 can detect it while latest cannot. The
>>> dcache disablement at latest U-Boot doesn't help.
>>>
>>> With that, I compared a bunch of registers from clocks, sysmgr,
>>> SCTLR,
>>> ATCLR and USB1 too. I noticed they are similar except the
>>> usb1.globgrp.gusbcfg.ulpiextvbusdrv. The latest U-Boot is
>>> indicating
>>> external supply (address 0xffb4000c return value 0x00101710) while
>>> working 2013.01.01 indicating internal charge pump (return value
>>> 0x00001710)
>>>
>>> Wonder you guys are seeing the same too? Will dig more about this.
>>> FYI,
>>> I tried to add lot of delay within dwc2.c but doesn't help at all.
>>>
>>
>> While modifying the USB power control of the code, I noticed the
>> patch
>> made by Dinh is not there. Just realize the git clone through http
>> from
>> main git doesn't work. I was able to clone but getting older version.
>>
>> With getting the latest code, all my pendrive now can works with
>> dcache
>> off. Its easier now as I can get consistent behaviour compared
>> previously. With that, dcache investigation for tomorrow then
>>
>> Thanks
>> Chin Liang
>>
>
> Spent more time on the dcache + USB issue today. Narrow down to below
> patch which can make all my USB pendrives work with dcache enabled. But
> still need to understand further as not in depth familiar with dwc2.
> Probably this might ring a bell to you guys?
>
>
> diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
> index b2f4bc6..b11d8d7 100644
> --- a/drivers/usb/host/dwc2.c
> +++ b/drivers/usb/host/dwc2.c
> @@ -776,6 +776,7 @@ static int transfer_chunk(struct dwc2_hc_regs
> *hc_regs, void *aligned_buffer,
>                 (num_packets << DWC2_HCTSIZ_PKTCNT_OFFSET) |
>                 (*pid << DWC2_HCTSIZ_PID_OFFSET),
>                 &hc_regs->hctsiz);
> +       udelay(2);
>
>          if (!in && xfer_len) {
>                  memcpy(aligned_buffer, buffer, xfer_len);

I can't really comment on the USB problem, as I've only seen this
d-cache / S-bit problem with SPI NOR flash. This is because I've never
really used USB on this platform intensively. But I'm nearly 100%
sure, that all changes that add some delays (or debug printfs)
resulting in a "working solution", either in the USB case or the SPI
NOR case, are just papering over the real problem.

Thanks,
Stefan

[U-Boot] Newbie SPL question for socfpga_sockit

[Marek Vasut]

On 03/22/2016 06:06 PM, Dinh Nguyen wrote:
> 
> 
> On 03/20/2016 11:42 AM, Marek Vasut wrote:
>>>
>>> Sorry, I know that doesn't help. So let's walk through my workflow. I am
>>> not using any Altera tools when I build.
>>>
>>> $make socfpga_de0_nano_soc_defconfig
>>> $make u-boot-with-spl.sfp
>>> $dd if=u-boot-with-spl.sfp of=/dev/sdb3
>>>
>>> My gcc is: arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3
>>>
>>> Has the board ever worked for you at all? Can you try this image:
>>>
>>> https://rocketboards.org/foswiki/view/Documentation/AtlasSoCSdCardImage
>>>
>>> Dinh
>>
>> I just ported U-Boot to another customer board. I noticed QSPI has
>> problems and USB can be flaky. That's the standard cache issue we
>> have, disabling dcache fixed that.
>>
>> I am starting to wonder whether we're hitting some corner case here.
>> Maybe we should eventually try and trace all the register reads and
>> writes generated by the DDR calibration code both in old and new SPL
>> and make a diff to see if something really did change.
>>
>> Dinh, can you share the marking on the SoC and the DRAMs on your board?
>>
> 
> My SoC is:
> 
> 5CSEMA4U23C6N
> CACAU1525A
> 
> DRAMs are:
> 
> ISSI 1510
> IS43TR16256A
> 15HBL K080
> P4482100QER2 TWN

Thanks, that's indeed rev. C . About time I bang my head against the
desk because this is creepy.


-- 
Best regards,
Marek Vasut

[U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 20 March 2016 at 08:55, Dinh Nguyen <dinguyen@opensource.altera.com> wrote:
>
>
> On 03/16/2016 08:35 PM, Marek Vasut wrote:
>>>
>>> Does this work for anybody else?
>>> Is it in anyone's experience that these (cheaper) Terasic
>>> eval boards are generally out of spec?
>>>
>>> Is there a way to relax the calibration parameters? the USB parameters?
>>>
>>> Would it help if I posted debug output?
>>
>> Sorry for the late reply, I am horribly overloaded now. I asked someone
>> in #u-boot who has the DE0-NANO-SOC board to test latest u-boot/master
>> on it and it apparently worked for him. I should get some more feedback
>> in the morning [ see http://pastebin.com/CM1QJGnh ] .
>>
>> Still, this is getting real creepy. You are the second person who is
>> complaining about misbehavior of terasic boards with mainline u-boot
>> and whatever I do, I cannot replicate this.
>>
>> I am at least CCing the Altera guys. Sorry I have no better suggestion
>> for you :(
>
> I don't have any problems with mainline U-Boot and SPL on my DE0-NANO-BOARD:
>
> U-Boot SPL 2016.03-00307-ge4fb863 (Mar 20 2016 - 10:37:13)
> 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 MMC
>
>
> U-Boot 2016.03-00307-ge4fb863 (Mar 20 2016 - 10:37:13 -0500)
>
> CPU:   Altera SoCFPGA Platform
> FPGA:  Altera Cyclone V, SE/A4 or SX/C4, version 0x0
> BOOT:  SD/MMC Internal Transceiver (3.0V)
>        Watchdog enabled
> I2C:   ready
> DRAM:  1 GiB
> MMC:   dwmmc0 at ff704000: 0
> In:    serial
> Out:   serial
> Err:   serial
> Model: Terasic DE0-Nano(Atlas)
> Net:   eth0: ethernet at ff702000
> Hit any key to stop autoboot:  0
> =>
>
> Sorry, I know that doesn't help. So let's walk through my workflow. I am
> not using any Altera tools when I build.
>
> $make socfpga_de0_nano_soc_defconfig
> $make u-boot-with-spl.sfp
> $dd if=u-boot-with-spl.sfp of=/dev/sdb3
>
> My gcc is: arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3
>
> Has the board ever worked for you at all? Can you try this image:
>
> https://rocketboards.org/foswiki/view/Documentation/AtlasSoCSdCardImage
>
> Dinh
>
>

Hi All,

Was away...sorry... back again.

Dinh - my workflow is exactly as yours is above.

I've used several toolchains - always the same result.

The first de0_nano_soc board I bought has no problem booting from the
factory supplied image:

   SPL: U-Boot SPL 2013.01.01 (Dec 29 2014 - 15:29:15)
   Image: U-Boot 2013.01.01 (Dec 30 2014 - 12:07:34)

and it even works with some USB sticks.

But if I build a new SPL/image with workflow above using v2016.03

(git clone git://git.denx.de/u-boot.git u-boot/ or git clone
http://git.denx.de/u-boot.git u-boot/)

then I get the intermittent failing memory calibration and no USB
(dwc_otg_core_host_init: Timeout!...)

On my sockit board the memory calibration fails every time.



So I ordered and received a _second_ de0_nano_soc board.

The same SPL/image that was intermittently failing on the first board
works on the second board. I have not seen it fail after 20 reboots.

Unfortunately, USB behaves the same (dwc_otg_core_host_init: Timeout!...)

Not sure what that means... marginal boards from Terasic? Calibration
tests/parameters too stringent?

--George

[U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 20 March 2016 at 09:49, Marek Vasut <marex@denx.de> wrote:
> On 03/18/2016 10:22 PM, George Broz wrote:
>> On 18 March 2016 at 12:32, Marek Vasut <marex@denx.de> wrote:
>>> On 03/18/2016 07:59 PM, George Broz wrote:
>>>> On 16 March 2016 at 18:35, Marek Vasut <marex@denx.de> wrote:
>>>>> On 03/16/2016 05:17 PM, George Broz wrote:
>>>>>> On 15 March 2016 at 18:29, George Broz <brozgeo@gmail.com> wrote:
>>>>>>
>>>>>>>
>>>>>>> Hello again -
>>>>>>>
>>>>>>> So under the assumption my SoCKit h/w was broken, I bought a new board.
>>>>>>> They are back ordered on SoCKit boards, so I got a DE0-Nano-SoC instead.
>>>>>>>
>>>>>>> I build the v2016.03 (release) version of u-boot-with-spl.sfp.
>>>>>>>
>>>>>>> I power-up the (brand new) board and get:
>>>>>>>
>>>>>>> U-Boot SPL 2016.03 (Mar 15 2016 - 14:52:42)
>>>>>>> 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 ###
>>>>>>>
>>>>>>> U-Boot SPL 2016.03 (Mar 15 2016 - 14:52:42)
>>>>>>> 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 ###
>>>>>>>
>>>>>>> U-Boot SPL 2016.03 (Mar 15 2016 - 14:52:42)
>>>>>>> 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 MMC
>>>>>>>
>>>>>>> U-Boot 2016.03 (Mar 15 2016 - 14:52:42 -0700)
>>>>>>>
>>>>>>> CPU:   Altera SoCFPGA Platform
>>>>>>> FPGA:  Altera Cyclone V, SE/A4 or SX/C4, version 0x0
>>>>>>> BOOT:  SD/MMC Internal Transceiver (3.0V)
>>>>>>>        Watchdog enabled
>>>>>>> I2C:   ready
>>>>>>> DRAM:  1 GiB
>>>>>>> MMC:   dwmmc0 at ff704000: 0
>>>>>>> In:    serial
>>>>>>> Out:   serial
>>>>>>> Err:   serial
>>>>>>> Model: Terasic DE0-Nano(Atlas)
>>>>>>> Net:
>>>>>>> Error: ethernet at ff702000 address not set.
>>>>>>> No ethernet found.
>>>>>>> Hit any key to stop autoboot:  0
>>>>>>> =>
>>>>>>>
>>>>>>> And this is a good case... usually it doesn't succeed after the fourth try
>>>>>>> and I have to cycle power 4 or 5 times before I get lucky.
>>>>>>>
>>>>>>> If I do get lucky and then try to see a USB storage device, then I get:
>>>>>>>
>>>>>>> =>
>>>>>>> => usb start
>>>>>>> starting USB...
>>>>>>> USB0:   Core Release: 2.93a
>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>> scanning bus 0 for devices... 1 USB Device(s) found
>>>>>>> =>
>>>>>>>
>>>>>>> (Every time)
>>>>>>>
>>>>>>> The version of u-boot SPL that ships with the board:
>>>>>>> U-Boot SPL 2013.01.01 (Dec 29 2014 - 15:29:15)
>>>>>>>
>>>>>>> boots every time and has limited USB capability as
>>>>>>> it can see some USB sticks, but not others.
>>>>>>>
>>>>>>>
>>>>>>> Anyway - brand new board - same old symptoms.
>>>>>>>
>>>>>>> Is it perhaps a toolchain problem?? I'm using:
>>>>>>>
>>>>>>> Thread model: posix
>>>>>>> gcc version 4.9.3 20141031 (prerelease) (Linaro GCC 4.9-2014.11)
>>>>>>>
>>>>>>> COLLECT_GCC=arm-poky-linux-gnueabi-gcc
>>>>>>> COLLECT_LTO_WRAPPER=/opt/poky/1.7.1/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.3/lto-wrapper
>>>>>>> < snip >
>>>>>>>
>>>>>>> Any advice greatly appreciated.
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> --George Broz
>>>>>>
>>>>>> Rebuilt using the Altera EDS15.0 toolchain:
>>>>>>
>>>>>>   arm-altera-eabi-gcc --version
>>>>>>   arm-altera-eabi-gcc (Sourcery CodeBench Lite 2014.11-13) 4.9.1
>>>>>>   Copyright (C) 2014 Free Software Foundation, Inc.
>>>>>>   This is free software; see the source for copying conditions.  There is NO
>>>>>>   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>>>>>>
>>>>>>
>>>>>> Get same result ... mostly failing calibration, non-working USB....
>>>>>>
>>>>>> U-Boot SPL 2016.03 (Mar 16 2016 - 08:27:20)
>>>>>> 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 ###
>>>>>>
>>>>>> U-Boot SPL 2016.03 (Mar 16 2016 - 08:27:20)
>>>>>> 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 ###
>>>>>>
>>>>>> U-Boot SPL 2016.03 (Mar 16 2016 - 08:27:20)
>>>>>> 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 MMC
>>>>>>
>>>>>>
>>>>>> U-Boot 2016.03 (Mar 16 2016 - 08:27:20 -0700)
>>>>>>
>>>>>> Does this work for anybody else?
>>>>>> Is it in anyone's experience that these (cheaper) Terasic
>>>>>> eval boards are generally out of spec?
>>>>>>
>>>>>> Is there a way to relax the calibration parameters? the USB parameters?
>>>>>>
>>>>>> Would it help if I posted debug output?
>>>>>
>>>>> Sorry for the late reply, I am horribly overloaded now. I asked someone
>>>>> in #u-boot who has the DE0-NANO-SOC board to test latest u-boot/master
>>>>> on it and it apparently worked for him. I should get some more feedback
>>>>> in the morning [ see http://pastebin.com/CM1QJGnh ] .
>>>>>
>>>>> Still, this is getting real creepy. You are the second person who is
>>>>> complaining about misbehavior of terasic boards with mainline u-boot
>>>>> and whatever I do, I cannot replicate this.
>>>>>
>>>>> I am at least CCing the Altera guys. Sorry I have no better suggestion
>>>>> for you :(
>>>>>
>>>>> Best regards,
>>>>> Marek Vasut
>>>>
>>>>
>>>> Hi Marek,
>>>>
>>>> I've got a third board coming to me in the mail (another
>>>> DE0-NANO-SOC). I'll post
>>>> how that goes.If it fails, maybe I'll send it to you...
>>>>
>>>> I've also sent Terasic an email.
>>>>
>>>> One question - after you (your collegue's) SoCKit (Nano) get past memory
>>>> calibration, does USB work (i.e. does the u-boot USB subsystem recognize mass
>>>> storage devices)?
>>>>
>>>> I'm beginning to look for solutions that don't involve rebuilding the
>>>> SPL or using USB.
>>>
>>> Try "dcache off" before "usb reset", I had trouble with usb in recent
>>> versions due to cache problems. If this works, I am happy to give you
>>> a workaround, but I would also love a real solution ... which I do not
>>> have for 3+ months now :'-(
>>>
>>> Best regards,
>>> Marek Vasut
>>
>> Thanks, but nope - same story:
>> => dcache off
>> => dcache
>> Data (writethrough) Cache is OFF
>> => usb reset
>> resetting USB...
>> USB0:   Core Release: 0.000
>> SNPSID invalid (not DWC2 OTG device): 00000000
>> Port not available.
>> USB1:   Core Release: 2.93a
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout! ...
>> :
>> :
>
> If we cannot get this sorted out and you'd be willing to ship me one of
> those boards, I'd be super-glad to have one.
>
> In the meantime, can you try the ELDK 5.8 toolchain ? You can fetch it
> from [1], go into 5.8 / targets / armv5te and grab
> eldk-glibc-i686-arm-toolchain.sh . Run the script and it will install
> the toolchain into /opt/eldk/ . Then just source
> /opt/eldk-5.8/arm*/environment* script
> and build u-boot as usual.
>
> [1]
> https://www.amazon.com/clouddrive/share/ZDYTL7dwcLT1lkNoHzM4D7UoTJ4ulmPKFQBSW8IuG0I/folder/qoplba6uRqeeSDyEOnqIow
>
> --
> Best regards,
> Marek Vasut

Hello Marek,

I tried the ELDK 5.8 toolchain. On the de0_nano_soc board that
intermittently fails memory calibration
it makes no difference.

On the second de0_nano_soc board, the same SPL/image that failed on
the other board works every time
on this board, but USB still does not work (using the ELDK toolchain).

Let me know if we're to the point where you'd need to have the failing board.

Best regards,
--George Broz

[U-Boot] Newbie SPL question for socfpga_sockit

[Marek Vasut]

On 03/29/2016 03:44 AM, George Broz wrote:
> On 20 March 2016 at 08:55, Dinh Nguyen <dinguyen@opensource.altera.com> wrote:
>>
>>
>> On 03/16/2016 08:35 PM, Marek Vasut wrote:
>>>>
>>>> Does this work for anybody else?
>>>> Is it in anyone's experience that these (cheaper) Terasic
>>>> eval boards are generally out of spec?
>>>>
>>>> Is there a way to relax the calibration parameters? the USB parameters?
>>>>
>>>> Would it help if I posted debug output?
>>>
>>> Sorry for the late reply, I am horribly overloaded now. I asked someone
>>> in #u-boot who has the DE0-NANO-SOC board to test latest u-boot/master
>>> on it and it apparently worked for him. I should get some more feedback
>>> in the morning [ see http://pastebin.com/CM1QJGnh ] .
>>>
>>> Still, this is getting real creepy. You are the second person who is
>>> complaining about misbehavior of terasic boards with mainline u-boot
>>> and whatever I do, I cannot replicate this.
>>>
>>> I am at least CCing the Altera guys. Sorry I have no better suggestion
>>> for you :(
>>
>> I don't have any problems with mainline U-Boot and SPL on my DE0-NANO-BOARD:
>>
>> U-Boot SPL 2016.03-00307-ge4fb863 (Mar 20 2016 - 10:37:13)
>> 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 MMC
>>
>>
>> U-Boot 2016.03-00307-ge4fb863 (Mar 20 2016 - 10:37:13 -0500)
>>
>> CPU:   Altera SoCFPGA Platform
>> FPGA:  Altera Cyclone V, SE/A4 or SX/C4, version 0x0
>> BOOT:  SD/MMC Internal Transceiver (3.0V)
>>        Watchdog enabled
>> I2C:   ready
>> DRAM:  1 GiB
>> MMC:   dwmmc0 at ff704000: 0
>> In:    serial
>> Out:   serial
>> Err:   serial
>> Model: Terasic DE0-Nano(Atlas)
>> Net:   eth0: ethernet at ff702000
>> Hit any key to stop autoboot:  0
>> =>
>>
>> Sorry, I know that doesn't help. So let's walk through my workflow. I am
>> not using any Altera tools when I build.
>>
>> $make socfpga_de0_nano_soc_defconfig
>> $make u-boot-with-spl.sfp
>> $dd if=u-boot-with-spl.sfp of=/dev/sdb3
>>
>> My gcc is: arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3
>>
>> Has the board ever worked for you at all? Can you try this image:
>>
>> https://rocketboards.org/foswiki/view/Documentation/AtlasSoCSdCardImage
>>
>> Dinh
>>
>>
> 
> Hi All,
> 
> Was away...sorry... back again.
> 
> Dinh - my workflow is exactly as yours is above.
> 
> I've used several toolchains - always the same result.
> 
> The first de0_nano_soc board I bought has no problem booting from the
> factory supplied image:
> 
>    SPL: U-Boot SPL 2013.01.01 (Dec 29 2014 - 15:29:15)
>    Image: U-Boot 2013.01.01 (Dec 30 2014 - 12:07:34)
> 
> and it even works with some USB sticks.
> 
> But if I build a new SPL/image with workflow above using v2016.03
> 
> (git clone git://git.denx.de/u-boot.git u-boot/ or git clone
> http://git.denx.de/u-boot.git u-boot/)
> 
> then I get the intermittent failing memory calibration and no USB
> (dwc_otg_core_host_init: Timeout!...)
> 
> On my sockit board the memory calibration fails every time.

Are you willing to debug this stuff ? I have an idea how to do
comparative debugging if you have time to spare.

> So I ordered and received a _second_ de0_nano_soc board.
> 
> The same SPL/image that was intermittently failing on the first board
> works on the second board. I have not seen it fail after 20 reboots.
> 
> Unfortunately, USB behaves the same (dwc_otg_core_host_init: Timeout!...)
> 
> Not sure what that means... marginal boards from Terasic? Calibration
> tests/parameters too stringent?

Code being slightly different than what Altera ships ... ;-)

> --George
> 


-- 
Best regards,
Marek Vasut

[U-Boot] Newbie SPL question for socfpga_sockit

[Marek Vasut]

On 03/29/2016 03:56 AM, George Broz wrote:
> On 20 March 2016 at 09:49, Marek Vasut <marex@denx.de> wrote:
>> On 03/18/2016 10:22 PM, George Broz wrote:
>>> On 18 March 2016 at 12:32, Marek Vasut <marex@denx.de> wrote:
>>>> On 03/18/2016 07:59 PM, George Broz wrote:
>>>>> On 16 March 2016 at 18:35, Marek Vasut <marex@denx.de> wrote:
>>>>>> On 03/16/2016 05:17 PM, George Broz wrote:
>>>>>>> On 15 March 2016 at 18:29, George Broz <brozgeo@gmail.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> Hello again -
>>>>>>>>
>>>>>>>> So under the assumption my SoCKit h/w was broken, I bought a new board.
>>>>>>>> They are back ordered on SoCKit boards, so I got a DE0-Nano-SoC instead.
>>>>>>>>
>>>>>>>> I build the v2016.03 (release) version of u-boot-with-spl.sfp.
>>>>>>>>
>>>>>>>> I power-up the (brand new) board and get:
>>>>>>>>
>>>>>>>> U-Boot SPL 2016.03 (Mar 15 2016 - 14:52:42)
>>>>>>>> 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 ###
>>>>>>>>
>>>>>>>> U-Boot SPL 2016.03 (Mar 15 2016 - 14:52:42)
>>>>>>>> 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 ###
>>>>>>>>
>>>>>>>> U-Boot SPL 2016.03 (Mar 15 2016 - 14:52:42)
>>>>>>>> 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 MMC
>>>>>>>>
>>>>>>>> U-Boot 2016.03 (Mar 15 2016 - 14:52:42 -0700)
>>>>>>>>
>>>>>>>> CPU:   Altera SoCFPGA Platform
>>>>>>>> FPGA:  Altera Cyclone V, SE/A4 or SX/C4, version 0x0
>>>>>>>> BOOT:  SD/MMC Internal Transceiver (3.0V)
>>>>>>>>        Watchdog enabled
>>>>>>>> I2C:   ready
>>>>>>>> DRAM:  1 GiB
>>>>>>>> MMC:   dwmmc0 at ff704000: 0
>>>>>>>> In:    serial
>>>>>>>> Out:   serial
>>>>>>>> Err:   serial
>>>>>>>> Model: Terasic DE0-Nano(Atlas)
>>>>>>>> Net:
>>>>>>>> Error: ethernet at ff702000 address not set.
>>>>>>>> No ethernet found.
>>>>>>>> Hit any key to stop autoboot:  0
>>>>>>>> =>
>>>>>>>>
>>>>>>>> And this is a good case... usually it doesn't succeed after the fourth try
>>>>>>>> and I have to cycle power 4 or 5 times before I get lucky.
>>>>>>>>
>>>>>>>> If I do get lucky and then try to see a USB storage device, then I get:
>>>>>>>>
>>>>>>>> =>
>>>>>>>> => usb start
>>>>>>>> starting USB...
>>>>>>>> USB0:   Core Release: 2.93a
>>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>>> scanning bus 0 for devices... 1 USB Device(s) found
>>>>>>>> =>
>>>>>>>>
>>>>>>>> (Every time)
>>>>>>>>
>>>>>>>> The version of u-boot SPL that ships with the board:
>>>>>>>> U-Boot SPL 2013.01.01 (Dec 29 2014 - 15:29:15)
>>>>>>>>
>>>>>>>> boots every time and has limited USB capability as
>>>>>>>> it can see some USB sticks, but not others.
>>>>>>>>
>>>>>>>>
>>>>>>>> Anyway - brand new board - same old symptoms.
>>>>>>>>
>>>>>>>> Is it perhaps a toolchain problem?? I'm using:
>>>>>>>>
>>>>>>>> Thread model: posix
>>>>>>>> gcc version 4.9.3 20141031 (prerelease) (Linaro GCC 4.9-2014.11)
>>>>>>>>
>>>>>>>> COLLECT_GCC=arm-poky-linux-gnueabi-gcc
>>>>>>>> COLLECT_LTO_WRAPPER=/opt/poky/1.7.1/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.3/lto-wrapper
>>>>>>>> < snip >
>>>>>>>>
>>>>>>>> Any advice greatly appreciated.
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> --George Broz
>>>>>>>
>>>>>>> Rebuilt using the Altera EDS15.0 toolchain:
>>>>>>>
>>>>>>>   arm-altera-eabi-gcc --version
>>>>>>>   arm-altera-eabi-gcc (Sourcery CodeBench Lite 2014.11-13) 4.9.1
>>>>>>>   Copyright (C) 2014 Free Software Foundation, Inc.
>>>>>>>   This is free software; see the source for copying conditions.  There is NO
>>>>>>>   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>>>>>>>
>>>>>>>
>>>>>>> Get same result ... mostly failing calibration, non-working USB....
>>>>>>>
>>>>>>> U-Boot SPL 2016.03 (Mar 16 2016 - 08:27:20)
>>>>>>> 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 ###
>>>>>>>
>>>>>>> U-Boot SPL 2016.03 (Mar 16 2016 - 08:27:20)
>>>>>>> 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 ###
>>>>>>>
>>>>>>> U-Boot SPL 2016.03 (Mar 16 2016 - 08:27:20)
>>>>>>> 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 MMC
>>>>>>>
>>>>>>>
>>>>>>> U-Boot 2016.03 (Mar 16 2016 - 08:27:20 -0700)
>>>>>>>
>>>>>>> Does this work for anybody else?
>>>>>>> Is it in anyone's experience that these (cheaper) Terasic
>>>>>>> eval boards are generally out of spec?
>>>>>>>
>>>>>>> Is there a way to relax the calibration parameters? the USB parameters?
>>>>>>>
>>>>>>> Would it help if I posted debug output?
>>>>>>
>>>>>> Sorry for the late reply, I am horribly overloaded now. I asked someone
>>>>>> in #u-boot who has the DE0-NANO-SOC board to test latest u-boot/master
>>>>>> on it and it apparently worked for him. I should get some more feedback
>>>>>> in the morning [ see http://pastebin.com/CM1QJGnh ] .
>>>>>>
>>>>>> Still, this is getting real creepy. You are the second person who is
>>>>>> complaining about misbehavior of terasic boards with mainline u-boot
>>>>>> and whatever I do, I cannot replicate this.
>>>>>>
>>>>>> I am at least CCing the Altera guys. Sorry I have no better suggestion
>>>>>> for you :(
>>>>>>
>>>>>> Best regards,
>>>>>> Marek Vasut
>>>>>
>>>>>
>>>>> Hi Marek,
>>>>>
>>>>> I've got a third board coming to me in the mail (another
>>>>> DE0-NANO-SOC). I'll post
>>>>> how that goes.If it fails, maybe I'll send it to you...
>>>>>
>>>>> I've also sent Terasic an email.
>>>>>
>>>>> One question - after you (your collegue's) SoCKit (Nano) get past memory
>>>>> calibration, does USB work (i.e. does the u-boot USB subsystem recognize mass
>>>>> storage devices)?
>>>>>
>>>>> I'm beginning to look for solutions that don't involve rebuilding the
>>>>> SPL or using USB.
>>>>
>>>> Try "dcache off" before "usb reset", I had trouble with usb in recent
>>>> versions due to cache problems. If this works, I am happy to give you
>>>> a workaround, but I would also love a real solution ... which I do not
>>>> have for 3+ months now :'-(
>>>>
>>>> Best regards,
>>>> Marek Vasut
>>>
>>> Thanks, but nope - same story:
>>> => dcache off
>>> => dcache
>>> Data (writethrough) Cache is OFF
>>> => usb reset
>>> resetting USB...
>>> USB0:   Core Release: 0.000
>>> SNPSID invalid (not DWC2 OTG device): 00000000
>>> Port not available.
>>> USB1:   Core Release: 2.93a
>>> dwc_otg_core_host_init: Timeout!
>>> dwc_otg_core_host_init: Timeout!
>>> dwc_otg_core_host_init: Timeout!
>>> dwc_otg_core_host_init: Timeout! ...
>>> :
>>> :
>>
>> If we cannot get this sorted out and you'd be willing to ship me one of
>> those boards, I'd be super-glad to have one.
>>
>> In the meantime, can you try the ELDK 5.8 toolchain ? You can fetch it
>> from [1], go into 5.8 / targets / armv5te and grab
>> eldk-glibc-i686-arm-toolchain.sh . Run the script and it will install
>> the toolchain into /opt/eldk/ . Then just source
>> /opt/eldk-5.8/arm*/environment* script
>> and build u-boot as usual.
>>
>> [1]
>> https://www.amazon.com/clouddrive/share/ZDYTL7dwcLT1lkNoHzM4D7UoTJ4ulmPKFQBSW8IuG0I/folder/qoplba6uRqeeSDyEOnqIow
>>
>> --
>> Best regards,
>> Marek Vasut
> 
> Hello Marek,
> 
> I tried the ELDK 5.8 toolchain. On the de0_nano_soc board that
> intermittently fails memory calibration
> it makes no difference.
> 
> On the second de0_nano_soc board, the same SPL/image that failed on
> the other board works every time
> on this board, but USB still does not work (using the ELDK toolchain).
> 
> Let me know if we're to the point where you'd need to have the failing board.

Where are you located, australia ?


-- 
Best regards,
Marek Vasut

[U-Boot] Newbie SPL question for socfpga_sockit

[Phil Reid]

On 27/03/2016 4:52 AM, Marek Vasut wrote:
> On 03/22/2016 06:06 PM, Dinh Nguyen wrote:
>>
>>
>> On 03/20/2016 11:42 AM, Marek Vasut wrote:
>>>>
>>>> Sorry, I know that doesn't help. So let's walk through my workflow. I am
>>>> not using any Altera tools when I build.
>>>>
>>>> $make socfpga_de0_nano_soc_defconfig
>>>> $make u-boot-with-spl.sfp
>>>> $dd if=u-boot-with-spl.sfp of=/dev/sdb3
>>>>
>>>> My gcc is: arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3
>>>>
>>>> Has the board ever worked for you at all? Can you try this image:
>>>>
>>>> https://rocketboards.org/foswiki/view/Documentation/AtlasSoCSdCardImage
>>>>
>>>> Dinh
>>>
>>> I just ported U-Boot to another customer board. I noticed QSPI has
>>> problems and USB can be flaky. That's the standard cache issue we
>>> have, disabling dcache fixed that.
>>>
>>> I am starting to wonder whether we're hitting some corner case here.
>>> Maybe we should eventually try and trace all the register reads and
>>> writes generated by the DDR calibration code both in old and new SPL
>>> and make a diff to see if something really did change.
>>>
>>> Dinh, can you share the marking on the SoC and the DRAMs on your board?
>>>
>>
>> My SoC is:
>>
>> 5CSEMA4U23C6N
>> CACAU1525A
>>
>> DRAMs are:
>>
>> ISSI 1510
>> IS43TR16256A
>> 15HBL K080
>> P4482100QER2 TWN
>
> Thanks, that's indeed rev. C . About time I bang my head against the
> desk because this is creepy.
>
>
FYI

I've just spend some time trying to update the spl / uboot / kernel & rootfs image on our
Altera socdk to use for some software testing / development.
Unfortunately it fails in the mem calibration process with the latest uboot most of the time.
And when it does boot somtimes fails loading uboot fomr the mmc.

Our own design works fine.

I've built different images using the qts files in uboot git and those generated from quartus for the socdk.

Both have the same reliability.

It's an old revC board.

Been running perfectly for months using the older spl / uboot. :(





-- 
Regards
Phil Reid

[U-Boot] Newbie SPL question for socfpga_sockit

[Marek Vasut]

On 04/05/2016 10:33 AM, Phil Reid wrote:
> On 27/03/2016 4:52 AM, Marek Vasut wrote:
>> On 03/22/2016 06:06 PM, Dinh Nguyen wrote:
>>>
>>>
>>> On 03/20/2016 11:42 AM, Marek Vasut wrote:
>>>>>
>>>>> Sorry, I know that doesn't help. So let's walk through my workflow.
>>>>> I am
>>>>> not using any Altera tools when I build.
>>>>>
>>>>> $make socfpga_de0_nano_soc_defconfig
>>>>> $make u-boot-with-spl.sfp
>>>>> $dd if=u-boot-with-spl.sfp of=/dev/sdb3
>>>>>
>>>>> My gcc is: arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3
>>>>>
>>>>> Has the board ever worked for you at all? Can you try this image:
>>>>>
>>>>> https://rocketboards.org/foswiki/view/Documentation/AtlasSoCSdCardImage
>>>>>
>>>>>
>>>>> Dinh
>>>>
>>>> I just ported U-Boot to another customer board. I noticed QSPI has
>>>> problems and USB can be flaky. That's the standard cache issue we
>>>> have, disabling dcache fixed that.
>>>>
>>>> I am starting to wonder whether we're hitting some corner case here.
>>>> Maybe we should eventually try and trace all the register reads and
>>>> writes generated by the DDR calibration code both in old and new SPL
>>>> and make a diff to see if something really did change.
>>>>
>>>> Dinh, can you share the marking on the SoC and the DRAMs on your board?
>>>>
>>>
>>> My SoC is:
>>>
>>> 5CSEMA4U23C6N
>>> CACAU1525A
>>>
>>> DRAMs are:
>>>
>>> ISSI 1510
>>> IS43TR16256A
>>> 15HBL K080
>>> P4482100QER2 TWN
>>
>> Thanks, that's indeed rev. C . About time I bang my head against the
>> desk because this is creepy.
>>
>>
> FYI
> 
> I've just spend some time trying to update the spl / uboot / kernel &
> rootfs image on our
> Altera socdk to use for some software testing / development.
> Unfortunately it fails in the mem calibration process with the latest
> uboot most of the time.
> And when it does boot somtimes fails loading uboot fomr the mmc.

Try this u-boot-socfpga/ddr branch [1] , see if it works for you.

[1]
http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=shortlog;h=refs/heads/ddr

> Our own design works fine.
> 
> I've built different images using the qts files in uboot git and those
> generated from quartus for the socdk.
> 
> Both have the same reliability.
> 
> It's an old revC board.
> 
> Been running perfectly for months using the older spl / uboot. :(

Great, see above, please let me know.

-- 
Best regards,
Marek Vasut

[U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 5 April 2016 at 15:03, Marek Vasut <marex@denx.de> wrote:
> On 04/05/2016 10:33 AM, Phil Reid wrote:
>> On 27/03/2016 4:52 AM, Marek Vasut wrote:
>>> On 03/22/2016 06:06 PM, Dinh Nguyen wrote:
>>>>
>>>>
>>>> On 03/20/2016 11:42 AM, Marek Vasut wrote:
>>>>>>
>>>>>> Sorry, I know that doesn't help. So let's walk through my workflow.
>>>>>> I am
>>>>>> not using any Altera tools when I build.
>>>>>>
>>>>>> $make socfpga_de0_nano_soc_defconfig
>>>>>> $make u-boot-with-spl.sfp
>>>>>> $dd if=u-boot-with-spl.sfp of=/dev/sdb3
>>>>>>
>>>>>> My gcc is: arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3
>>>>>>
>>>>>> Has the board ever worked for you at all? Can you try this image:
>>>>>>
>>>>>> https://rocketboards.org/foswiki/view/Documentation/AtlasSoCSdCardImage
>>>>>>
>>>>>>
>>>>>> Dinh
>>>>>
>>>>> I just ported U-Boot to another customer board. I noticed QSPI has
>>>>> problems and USB can be flaky. That's the standard cache issue we
>>>>> have, disabling dcache fixed that.
>>>>>
>>>>> I am starting to wonder whether we're hitting some corner case here.
>>>>> Maybe we should eventually try and trace all the register reads and
>>>>> writes generated by the DDR calibration code both in old and new SPL
>>>>> and make a diff to see if something really did change.
>>>>>
>>>>> Dinh, can you share the marking on the SoC and the DRAMs on your board?
>>>>>
>>>>
>>>> My SoC is:
>>>>
>>>> 5CSEMA4U23C6N
>>>> CACAU1525A
>>>>
>>>> DRAMs are:
>>>>
>>>> ISSI 1510
>>>> IS43TR16256A
>>>> 15HBL K080
>>>> P4482100QER2 TWN
>>>
>>> Thanks, that's indeed rev. C . About time I bang my head against the
>>> desk because this is creepy.
>>>
>>>
>> FYI
>>
>> I've just spend some time trying to update the spl / uboot / kernel &
>> rootfs image on our
>> Altera socdk to use for some software testing / development.
>> Unfortunately it fails in the mem calibration process with the latest
>> uboot most of the time.
>> And when it does boot somtimes fails loading uboot fomr the mmc.
>
> Try this u-boot-socfpga/ddr branch [1] , see if it works for you.
>
> [1]
> http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=shortlog;h=refs/heads/ddr

I downloaded a "snapshot" from the above link producing,
u-boot-socfpga-1931be2.tar.gz

When I try to build for sockit or de0_nano_soc I get:

 CC      drivers/mmc/mmc-uclass.o
  CC      drivers/mmc/dw_mmc.o
  CC      drivers/mmc/mmc.o
  CC      drivers/mmc/socfpga_dw_mmc.o
drivers/mmc/socfpga_dw_mmc.c:9:28: fatal error: asm/arch/dwmmc.h: No
such file or directory
 #include <asm/arch/dwmmc.h>
                            ^
compilation terminated.
make[1]: *** [drivers/mmc/socfpga_dw_mmc.o] Error 1
make: *** [drivers/mmc] Error 2


Please advise.

--George


>
>> Our own design works fine.
>>
>> I've built different images using the qts files in uboot git and those
>> generated from quartus for the socdk.
>>
>> Both have the same reliability.
>>
>> It's an old revC board.
>>
>> Been running perfectly for months using the older spl / uboot. :(
>
> Great, see above, please let me know.
>
> --
> Best regards,
> Marek Vasut

[U-Boot] Newbie SPL question for socfpga_sockit

[Marek Vasut]

On 04/06/2016 02:31 AM, George Broz wrote:
> On 5 April 2016 at 15:03, Marek Vasut <marex@denx.de> wrote:
>> On 04/05/2016 10:33 AM, Phil Reid wrote:
>>> On 27/03/2016 4:52 AM, Marek Vasut wrote:
>>>> On 03/22/2016 06:06 PM, Dinh Nguyen wrote:
>>>>>
>>>>>
>>>>> On 03/20/2016 11:42 AM, Marek Vasut wrote:
>>>>>>>
>>>>>>> Sorry, I know that doesn't help. So let's walk through my workflow.
>>>>>>> I am
>>>>>>> not using any Altera tools when I build.
>>>>>>>
>>>>>>> $make socfpga_de0_nano_soc_defconfig
>>>>>>> $make u-boot-with-spl.sfp
>>>>>>> $dd if=u-boot-with-spl.sfp of=/dev/sdb3
>>>>>>>
>>>>>>> My gcc is: arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3
>>>>>>>
>>>>>>> Has the board ever worked for you at all? Can you try this image:
>>>>>>>
>>>>>>> https://rocketboards.org/foswiki/view/Documentation/AtlasSoCSdCardImage
>>>>>>>
>>>>>>>
>>>>>>> Dinh
>>>>>>
>>>>>> I just ported U-Boot to another customer board. I noticed QSPI has
>>>>>> problems and USB can be flaky. That's the standard cache issue we
>>>>>> have, disabling dcache fixed that.
>>>>>>
>>>>>> I am starting to wonder whether we're hitting some corner case here.
>>>>>> Maybe we should eventually try and trace all the register reads and
>>>>>> writes generated by the DDR calibration code both in old and new SPL
>>>>>> and make a diff to see if something really did change.
>>>>>>
>>>>>> Dinh, can you share the marking on the SoC and the DRAMs on your board?
>>>>>>
>>>>>
>>>>> My SoC is:
>>>>>
>>>>> 5CSEMA4U23C6N
>>>>> CACAU1525A
>>>>>
>>>>> DRAMs are:
>>>>>
>>>>> ISSI 1510
>>>>> IS43TR16256A
>>>>> 15HBL K080
>>>>> P4482100QER2 TWN
>>>>
>>>> Thanks, that's indeed rev. C . About time I bang my head against the
>>>> desk because this is creepy.
>>>>
>>>>
>>> FYI
>>>
>>> I've just spend some time trying to update the spl / uboot / kernel &
>>> rootfs image on our
>>> Altera socdk to use for some software testing / development.
>>> Unfortunately it fails in the mem calibration process with the latest
>>> uboot most of the time.
>>> And when it does boot somtimes fails loading uboot fomr the mmc.
>>
>> Try this u-boot-socfpga/ddr branch [1] , see if it works for you.
>>
>> [1]
>> http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=shortlog;h=refs/heads/ddr
> 
> I downloaded a "snapshot" from the above link producing,
> u-boot-socfpga-1931be2.tar.gz
> 
> When I try to build for sockit or de0_nano_soc I get:
> 
>  CC      drivers/mmc/mmc-uclass.o
>   CC      drivers/mmc/dw_mmc.o
>   CC      drivers/mmc/mmc.o
>   CC      drivers/mmc/socfpga_dw_mmc.o
> drivers/mmc/socfpga_dw_mmc.c:9:28: fatal error: asm/arch/dwmmc.h: No
> such file or directory
>  #include <asm/arch/dwmmc.h>
>                             ^
> compilation terminated.
> make[1]: *** [drivers/mmc/socfpga_dw_mmc.o] Error 1
> make: *** [drivers/mmc] Error 2

Thanks for spotting this. Did you try the most basic of basic approaches:

diff --git a/drivers/mmc/socfpga_dw_mmc.c b/drivers/mmc/socfpga_dw_mmc.c
index 43a7e7e..097db81 100644
--- a/drivers/mmc/socfpga_dw_mmc.c
+++ b/drivers/mmc/socfpga_dw_mmc.c
@@ -6,7 +6,6 @@

 #include <common.h>
 #include <asm/arch/clock_manager.h>
-#include <asm/arch/dwmmc.h>
 #include <asm/arch/system_manager.h>
 #include <dm.h>
 #include <dwmmc.h>

The git tree is updated now.

Best regards,
Marek Vasut

[U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 5 April 2016 at 17:45, Marek Vasut <marex@denx.de> wrote:
> On 04/06/2016 02:31 AM, George Broz wrote:
>> On 5 April 2016 at 15:03, Marek Vasut <marex@denx.de> wrote:
>>> On 04/05/2016 10:33 AM, Phil Reid wrote:
>>>> On 27/03/2016 4:52 AM, Marek Vasut wrote:
>>>>> On 03/22/2016 06:06 PM, Dinh Nguyen wrote:
>>>>>>
>>>>>>
>>>>>> On 03/20/2016 11:42 AM, Marek Vasut wrote:
>>>>>>>>
>>>>>>>> Sorry, I know that doesn't help. So let's walk through my workflow.
>>>>>>>> I am
>>>>>>>> not using any Altera tools when I build.
>>>>>>>>
>>>>>>>> $make socfpga_de0_nano_soc_defconfig
>>>>>>>> $make u-boot-with-spl.sfp
>>>>>>>> $dd if=u-boot-with-spl.sfp of=/dev/sdb3
>>>>>>>>
>>>>>>>> My gcc is: arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3
>>>>>>>>
>>>>>>>> Has the board ever worked for you at all? Can you try this image:
>>>>>>>>
>>>>>>>> https://rocketboards.org/foswiki/view/Documentation/AtlasSoCSdCardImage
>>>>>>>>
>>>>>>>>
>>>>>>>> Dinh
>>>>>>>
>>>>>>> I just ported U-Boot to another customer board. I noticed QSPI has
>>>>>>> problems and USB can be flaky. That's the standard cache issue we
>>>>>>> have, disabling dcache fixed that.
>>>>>>>
>>>>>>> I am starting to wonder whether we're hitting some corner case here.
>>>>>>> Maybe we should eventually try and trace all the register reads and
>>>>>>> writes generated by the DDR calibration code both in old and new SPL
>>>>>>> and make a diff to see if something really did change.
>>>>>>>
>>>>>>> Dinh, can you share the marking on the SoC and the DRAMs on your board?
>>>>>>>
>>>>>>
>>>>>> My SoC is:
>>>>>>
>>>>>> 5CSEMA4U23C6N
>>>>>> CACAU1525A
>>>>>>
>>>>>> DRAMs are:
>>>>>>
>>>>>> ISSI 1510
>>>>>> IS43TR16256A
>>>>>> 15HBL K080
>>>>>> P4482100QER2 TWN
>>>>>
>>>>> Thanks, that's indeed rev. C . About time I bang my head against the
>>>>> desk because this is creepy.
>>>>>
>>>>>
>>>> FYI
>>>>
>>>> I've just spend some time trying to update the spl / uboot / kernel &
>>>> rootfs image on our
>>>> Altera socdk to use for some software testing / development.
>>>> Unfortunately it fails in the mem calibration process with the latest
>>>> uboot most of the time.
>>>> And when it does boot somtimes fails loading uboot fomr the mmc.
>>>
>>> Try this u-boot-socfpga/ddr branch [1] , see if it works for you.
>>>
>>> [1]
>>> http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=shortlog;h=refs/heads/ddr
>>
>> I downloaded a "snapshot" from the above link producing,
>> u-boot-socfpga-1931be2.tar.gz
>>
>> When I try to build for sockit or de0_nano_soc I get:
>>
>>  CC      drivers/mmc/mmc-uclass.o
>>   CC      drivers/mmc/dw_mmc.o
>>   CC      drivers/mmc/mmc.o
>>   CC      drivers/mmc/socfpga_dw_mmc.o
>> drivers/mmc/socfpga_dw_mmc.c:9:28: fatal error: asm/arch/dwmmc.h: No
>> such file or directory
>>  #include <asm/arch/dwmmc.h>
>>                             ^
>> compilation terminated.
>> make[1]: *** [drivers/mmc/socfpga_dw_mmc.o] Error 1
>> make: *** [drivers/mmc] Error 2
>
> Thanks for spotting this. Did you try the most basic of basic approaches:
>
> diff --git a/drivers/mmc/socfpga_dw_mmc.c b/drivers/mmc/socfpga_dw_mmc.c
> index 43a7e7e..097db81 100644
> --- a/drivers/mmc/socfpga_dw_mmc.c
> +++ b/drivers/mmc/socfpga_dw_mmc.c
> @@ -6,7 +6,6 @@
>
>  #include <common.h>
>  #include <asm/arch/clock_manager.h>
> -#include <asm/arch/dwmmc.h>
>  #include <asm/arch/system_manager.h>
>  #include <dm.h>
>  #include <dwmmc.h>
>
> The git tree is updated now.

It compiles and it works!

On sockit:

U-Boot SPL 2016.03 (Apr 05 2016 - 17:57:23)
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

First time that an SPL built from a recent version has run successfully
on that board.

Will try it out on de0 tomorrow morning...

Thanks!
--George

>
> Best regards,
> Marek Vasut

[U-Boot] Newbie SPL question for socfpga_sockit

[Phil Reid]

On 6/04/2016 6:03 AM, Marek Vasut wrote:
> On 04/05/2016 10:33 AM, Phil Reid wrote:
>> On 27/03/2016 4:52 AM, Marek Vasut wrote:
>>> On 03/22/2016 06:06 PM, Dinh Nguyen wrote:
>>>>
>>>>
>>>> On 03/20/2016 11:42 AM, Marek Vasut wrote:
>>>>>>
>>>>>> Sorry, I know that doesn't help. So let's walk through my workflow.
>>>>>> I am
>>>>>> not using any Altera tools when I build.
>>>>>>
>>>>>> $make socfpga_de0_nano_soc_defconfig
>>>>>> $make u-boot-with-spl.sfp
>>>>>> $dd if=u-boot-with-spl.sfp of=/dev/sdb3
>>>>>>
>>>>>> My gcc is: arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3
>>>>>>
>>>>>> Has the board ever worked for you at all? Can you try this image:
>>>>>>
>>>>>> https://rocketboards.org/foswiki/view/Documentation/AtlasSoCSdCardImage
>>>>>>
>>>>>>
>>>>>> Dinh
>>>>>
>>>>> I just ported U-Boot to another customer board. I noticed QSPI has
>>>>> problems and USB can be flaky. That's the standard cache issue we
>>>>> have, disabling dcache fixed that.
>>>>>
>>>>> I am starting to wonder whether we're hitting some corner case here.
>>>>> Maybe we should eventually try and trace all the register reads and
>>>>> writes generated by the DDR calibration code both in old and new SPL
>>>>> and make a diff to see if something really did change.
>>>>>
>>>>> Dinh, can you share the marking on the SoC and the DRAMs on your board?
>>>>>
>>>>
>>>> My SoC is:
>>>>
>>>> 5CSEMA4U23C6N
>>>> CACAU1525A
>>>>
>>>> DRAMs are:
>>>>
>>>> ISSI 1510
>>>> IS43TR16256A
>>>> 15HBL K080
>>>> P4482100QER2 TWN
>>>
>>> Thanks, that's indeed rev. C . About time I bang my head against the
>>> desk because this is creepy.
>>>
>>>
>> FYI
>>
>> I've just spend some time trying to update the spl / uboot / kernel &
>> rootfs image on our
>> Altera socdk to use for some software testing / development.
>> Unfortunately it fails in the mem calibration process with the latest
>> uboot most of the time.
>> And when it does boot somtimes fails loading uboot fomr the mmc.
>
> Try this u-boot-socfpga/ddr branch [1] , see if it works for you.
>
> [1]
> http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=shortlog;h=refs/heads/ddr
>

Spent a bit of time on it and things are very weird. So far no luck booting with the ddr branch.
I got the memory calibration to pass but then had problems with loading uboot. Using the mmc.
Say no device found for the mmc. error -19.

When I try to add some extra debug in things fall over.
Sometimes just hangs in the Memory cal (and not changing anything there).
Then sometimes I get missing DTB.
I found the uboot-with-spl.sfp file generated by the latest uboot tree and tried burning that with
same results.

Reverted back to the image available on rocketboards and wrote that to the card.
Thinking something strange with the card (thou I tried several) and that works fine.
Sourced from
https://rocketboards.org/foswiki/view/Documentation/AlteraSoCDevelopmentBoard

I've not had any success with the ARM dstream connection to do bare metal debugging to this board.
It finds the cpu but has trouble downloading the image.
Again this all works fine with our hardware.

Not sure were to go from here. I may not have time to probe any further as our hardware appears to work.


-- 
Regards
Phil Reid

[U-Boot] Newbie SPL question for socfpga_sockit

[Marek Vasut]

On 04/06/2016 03:17 AM, George Broz wrote:
> On 5 April 2016 at 17:45, Marek Vasut <marex@denx.de> wrote:
>> On 04/06/2016 02:31 AM, George Broz wrote:
>>> On 5 April 2016 at 15:03, Marek Vasut <marex@denx.de> wrote:
>>>> On 04/05/2016 10:33 AM, Phil Reid wrote:
>>>>> On 27/03/2016 4:52 AM, Marek Vasut wrote:
>>>>>> On 03/22/2016 06:06 PM, Dinh Nguyen wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 03/20/2016 11:42 AM, Marek Vasut wrote:
>>>>>>>>>
>>>>>>>>> Sorry, I know that doesn't help. So let's walk through my workflow.
>>>>>>>>> I am
>>>>>>>>> not using any Altera tools when I build.
>>>>>>>>>
>>>>>>>>> $make socfpga_de0_nano_soc_defconfig
>>>>>>>>> $make u-boot-with-spl.sfp
>>>>>>>>> $dd if=u-boot-with-spl.sfp of=/dev/sdb3
>>>>>>>>>
>>>>>>>>> My gcc is: arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3
>>>>>>>>>
>>>>>>>>> Has the board ever worked for you at all? Can you try this image:
>>>>>>>>>
>>>>>>>>> https://rocketboards.org/foswiki/view/Documentation/AtlasSoCSdCardImage
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Dinh
>>>>>>>>
>>>>>>>> I just ported U-Boot to another customer board. I noticed QSPI has
>>>>>>>> problems and USB can be flaky. That's the standard cache issue we
>>>>>>>> have, disabling dcache fixed that.
>>>>>>>>
>>>>>>>> I am starting to wonder whether we're hitting some corner case here.
>>>>>>>> Maybe we should eventually try and trace all the register reads and
>>>>>>>> writes generated by the DDR calibration code both in old and new SPL
>>>>>>>> and make a diff to see if something really did change.
>>>>>>>>
>>>>>>>> Dinh, can you share the marking on the SoC and the DRAMs on your board?
>>>>>>>>
>>>>>>>
>>>>>>> My SoC is:
>>>>>>>
>>>>>>> 5CSEMA4U23C6N
>>>>>>> CACAU1525A
>>>>>>>
>>>>>>> DRAMs are:
>>>>>>>
>>>>>>> ISSI 1510
>>>>>>> IS43TR16256A
>>>>>>> 15HBL K080
>>>>>>> P4482100QER2 TWN
>>>>>>
>>>>>> Thanks, that's indeed rev. C . About time I bang my head against the
>>>>>> desk because this is creepy.
>>>>>>
>>>>>>
>>>>> FYI
>>>>>
>>>>> I've just spend some time trying to update the spl / uboot / kernel &
>>>>> rootfs image on our
>>>>> Altera socdk to use for some software testing / development.
>>>>> Unfortunately it fails in the mem calibration process with the latest
>>>>> uboot most of the time.
>>>>> And when it does boot somtimes fails loading uboot fomr the mmc.
>>>>
>>>> Try this u-boot-socfpga/ddr branch [1] , see if it works for you.
>>>>
>>>> [1]
>>>> http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=shortlog;h=refs/heads/ddr
>>>
>>> I downloaded a "snapshot" from the above link producing,
>>> u-boot-socfpga-1931be2.tar.gz
>>>
>>> When I try to build for sockit or de0_nano_soc I get:
>>>
>>>  CC      drivers/mmc/mmc-uclass.o
>>>   CC      drivers/mmc/dw_mmc.o
>>>   CC      drivers/mmc/mmc.o
>>>   CC      drivers/mmc/socfpga_dw_mmc.o
>>> drivers/mmc/socfpga_dw_mmc.c:9:28: fatal error: asm/arch/dwmmc.h: No
>>> such file or directory
>>>  #include <asm/arch/dwmmc.h>
>>>                             ^
>>> compilation terminated.
>>> make[1]: *** [drivers/mmc/socfpga_dw_mmc.o] Error 1
>>> make: *** [drivers/mmc] Error 2
>>
>> Thanks for spotting this. Did you try the most basic of basic approaches:
>>
>> diff --git a/drivers/mmc/socfpga_dw_mmc.c b/drivers/mmc/socfpga_dw_mmc.c
>> index 43a7e7e..097db81 100644
>> --- a/drivers/mmc/socfpga_dw_mmc.c
>> +++ b/drivers/mmc/socfpga_dw_mmc.c
>> @@ -6,7 +6,6 @@
>>
>>  #include <common.h>
>>  #include <asm/arch/clock_manager.h>
>> -#include <asm/arch/dwmmc.h>
>>  #include <asm/arch/system_manager.h>
>>  #include <dm.h>
>>  #include <dwmmc.h>
>>
>> The git tree is updated now.
> 
> It compiles and it works!
> 
> On sockit:
> 
> U-Boot SPL 2016.03 (Apr 05 2016 - 17:57:23)
> 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
> 
> First time that an SPL built from a recent version has run successfully
> on that board.
> 
> Will try it out on de0 tomorrow morning...

This is great news, thanks!

Best regards,
Marek Vasut

[U-Boot] Newbie SPL question for socfpga_sockit

[Marek Vasut]

On 04/06/2016 09:00 AM, Phil Reid wrote:
> On 6/04/2016 6:03 AM, Marek Vasut wrote:
>> On 04/05/2016 10:33 AM, Phil Reid wrote:
>>> On 27/03/2016 4:52 AM, Marek Vasut wrote:
>>>> On 03/22/2016 06:06 PM, Dinh Nguyen wrote:
>>>>>
>>>>>
>>>>> On 03/20/2016 11:42 AM, Marek Vasut wrote:
>>>>>>>
>>>>>>> Sorry, I know that doesn't help. So let's walk through my workflow.
>>>>>>> I am
>>>>>>> not using any Altera tools when I build.
>>>>>>>
>>>>>>> $make socfpga_de0_nano_soc_defconfig
>>>>>>> $make u-boot-with-spl.sfp
>>>>>>> $dd if=u-boot-with-spl.sfp of=/dev/sdb3
>>>>>>>
>>>>>>> My gcc is: arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1)
>>>>>>> 4.7.3
>>>>>>>
>>>>>>> Has the board ever worked for you at all? Can you try this image:
>>>>>>>
>>>>>>> https://rocketboards.org/foswiki/view/Documentation/AtlasSoCSdCardImage
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Dinh
>>>>>>
>>>>>> I just ported U-Boot to another customer board. I noticed QSPI has
>>>>>> problems and USB can be flaky. That's the standard cache issue we
>>>>>> have, disabling dcache fixed that.
>>>>>>
>>>>>> I am starting to wonder whether we're hitting some corner case here.
>>>>>> Maybe we should eventually try and trace all the register reads and
>>>>>> writes generated by the DDR calibration code both in old and new SPL
>>>>>> and make a diff to see if something really did change.
>>>>>>
>>>>>> Dinh, can you share the marking on the SoC and the DRAMs on your
>>>>>> board?
>>>>>>
>>>>>
>>>>> My SoC is:
>>>>>
>>>>> 5CSEMA4U23C6N
>>>>> CACAU1525A
>>>>>
>>>>> DRAMs are:
>>>>>
>>>>> ISSI 1510
>>>>> IS43TR16256A
>>>>> 15HBL K080
>>>>> P4482100QER2 TWN
>>>>
>>>> Thanks, that's indeed rev. C . About time I bang my head against the
>>>> desk because this is creepy.
>>>>
>>>>
>>> FYI
>>>
>>> I've just spend some time trying to update the spl / uboot / kernel &
>>> rootfs image on our
>>> Altera socdk to use for some software testing / development.
>>> Unfortunately it fails in the mem calibration process with the latest
>>> uboot most of the time.
>>> And when it does boot somtimes fails loading uboot fomr the mmc.
>>
>> Try this u-boot-socfpga/ddr branch [1] , see if it works for you.
>>
>> [1]
>> http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=shortlog;h=refs/heads/ddr
>>
>>
> 
> Spent a bit of time on it and things are very weird. So far no luck
> booting with the ddr branch.
> I got the memory calibration to pass but then had problems with loading
> uboot. Using the mmc.
> Say no device found for the mmc. error -19.

Which board is this ? How wide is the MMC data bus ?

> When I try to add some extra debug in things fall over.
> Sometimes just hangs in the Memory cal (and not changing anything there).
> Then sometimes I get missing DTB.
> I found the uboot-with-spl.sfp file generated by the latest uboot tree
> and tried burning that with
> same results.
> 
> Reverted back to the image available on rocketboards and wrote that to
> the card.
> Thinking something strange with the card (thou I tried several) and that
> works fine.
> Sourced from
> https://rocketboards.org/foswiki/view/Documentation/AlteraSoCDevelopmentBoard

Are you actually using the SoCDK or some custom board ?

> I've not had any success with the ARM dstream connection to do bare
> metal debugging to this board.
> It finds the cpu but has trouble downloading the image.
> Again this all works fine with our hardware.
> 
> Not sure were to go from here. I may not have time to probe any further
> as our hardware appears to work.
> 
> 


-- 
Best regards,
Marek Vasut

[U-Boot] Newbie SPL question for socfpga_sockit

[Phil Reid]

On 6/04/2016 7:51 PM, Marek Vasut wrote:
> On 04/06/2016 09:00 AM, Phil Reid wrote:
>> On 6/04/2016 6:03 AM, Marek Vasut wrote:
>>> On 04/05/2016 10:33 AM, Phil Reid wrote:
>>>> On 27/03/2016 4:52 AM, Marek Vasut wrote:
>>>>> On 03/22/2016 06:06 PM, Dinh Nguyen wrote:
>>>>>>
>>>>>>
>>>>>> On 03/20/2016 11:42 AM, Marek Vasut wrote:
>>>>>>>>
>>>>>>>> Sorry, I know that doesn't help. So let's walk through my workflow.
>>>>>>>> I am
>>>>>>>> not using any Altera tools when I build.
>>>>>>>>
>>>>>>>> $make socfpga_de0_nano_soc_defconfig
>>>>>>>> $make u-boot-with-spl.sfp
>>>>>>>> $dd if=u-boot-with-spl.sfp of=/dev/sdb3
>>>>>>>>
>>>>>>>> My gcc is: arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1)
>>>>>>>> 4.7.3
>>>>>>>>
>>>>>>>> Has the board ever worked for you at all? Can you try this image:
>>>>>>>>
>>>>>>>> https://rocketboards.org/foswiki/view/Documentation/AtlasSoCSdCardImage
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Dinh
>>>>>>>
>>>>>>> I just ported U-Boot to another customer board. I noticed QSPI has
>>>>>>> problems and USB can be flaky. That's the standard cache issue we
>>>>>>> have, disabling dcache fixed that.
>>>>>>>
>>>>>>> I am starting to wonder whether we're hitting some corner case here.
>>>>>>> Maybe we should eventually try and trace all the register reads and
>>>>>>> writes generated by the DDR calibration code both in old and new SPL
>>>>>>> and make a diff to see if something really did change.
>>>>>>>
>>>>>>> Dinh, can you share the marking on the SoC and the DRAMs on your
>>>>>>> board?
>>>>>>>
>>>>>>
>>>>>> My SoC is:
>>>>>>
>>>>>> 5CSEMA4U23C6N
>>>>>> CACAU1525A
>>>>>>
>>>>>> DRAMs are:
>>>>>>
>>>>>> ISSI 1510
>>>>>> IS43TR16256A
>>>>>> 15HBL K080
>>>>>> P4482100QER2 TWN
>>>>>
>>>>> Thanks, that's indeed rev. C . About time I bang my head against the
>>>>> desk because this is creepy.
>>>>>
>>>>>
>>>> FYI
>>>>
>>>> I've just spend some time trying to update the spl / uboot / kernel &
>>>> rootfs image on our
>>>> Altera socdk to use for some software testing / development.
>>>> Unfortunately it fails in the mem calibration process with the latest
>>>> uboot most of the time.
>>>> And when it does boot somtimes fails loading uboot fomr the mmc.
>>>
>>> Try this u-boot-socfpga/ddr branch [1] , see if it works for you.
>>>
>>> [1]
>>> http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=shortlog;h=refs/heads/ddr
>>>
>>>
>>
>> Spent a bit of time on it and things are very weird. So far no luck
>> booting with the ddr branch.
>> I got the memory calibration to pass but then had problems with loading
>> uboot. Using the mmc.
>> Say no device found for the mmc. error -19.
>
> Which board is this ? How wide is the MMC data bus ?
>
>> When I try to add some extra debug in things fall over.
>> Sometimes just hangs in the Memory cal (and not changing anything there).
>> Then sometimes I get missing DTB.
>> I found the uboot-with-spl.sfp file generated by the latest uboot tree
>> and tried burning that with
>> same results.
>>
>> Reverted back to the image available on rocketboards and wrote that to
>> the card.
>> Thinking something strange with the card (thou I tried several) and that
>> works fine.
>> Sourced from
>> https://rocketboards.org/foswiki/view/Documentation/AlteraSoCDevelopmentBoard
>
> Are you actually using the SoCDK or some custom board ?
>
I've got two boards here.
The Altera Cyclone V SoC FPGA Development Kit Board RevC
which is the SocDK right?
And our own board design.

Our design works fine with new uboot's.
Just can't get things to work with the dek kit.
It's fairly similar to the SocDK

I'm building two different version of uboot.
Using the two different qts generated files.
I've setup a separate defconfig / dts and board config for our board.

I'd really like to find the quartus project that was used to generate
the qts files committed into the uboot tree. All the ones I've used so
far have different ddr timing and pin configs!

-- 
Regards
Phil Reid

ElectroMagnetic Imaging Technology Pty Ltd
Development of Geophysical Instrumentation & Software
www.electromag.com.au

3 The Avenue, Midland WA 6056, AUSTRALIA
Ph: +61 8 9250 8100
Fax: +61 8 9250 7100
Email: preid at electromag.com.au

[U-Boot] SoCFPGA cache / S-bit problem - was Re: Newbie SPL question for socfpga_sockit

[Dinh Nguyen]

On Wed, Mar 23, 2016 at 10:37 AM, Stefan Roese <sr@denx.de> wrote:
>
> I can't really comment on the USB problem, as I've only seen this
> d-cache / S-bit problem with SPI NOR flash. This is because I've never
> really used USB on this platform intensively. But I'm nearly 100%
> sure, that all changes that add some delays (or debug printfs)
> resulting in a "working solution", either in the USB case or the SPI
> NOR case, are just papering over the real problem.
>

After a quick chat with Mark Rutland here at ELC, he alluded that there
could be a problem with the PL310 interfering with the L1 DCACHE. I won't
be able to try it until I get back, but perhaps somebody can test turning
off the PL310?

--- a/include/configs/socfpga_common.h
+++ b/include/configs/socfpga_common.h
@@ -78,7 +78,6 @@
  * Cache
  */
 #define CONFIG_SYS_CACHELINE_SIZE 32
-#define CONFIG_SYS_L2_PL310
 #define CONFIG_SYS_PL310_BASE          SOCFPGA_MPUL2_ADDRESS

 Dinh

[U-Boot] SoCFPGA cache / S-bit problem - was Re: Newbie SPL question for socfpga_sockit

[Marek Vasut]

On 04/06/2016 06:35 PM, Dinh Nguyen wrote:
> On Wed, Mar 23, 2016 at 10:37 AM, Stefan Roese <sr@denx.de> wrote:
>>
>> I can't really comment on the USB problem, as I've only seen this
>> d-cache / S-bit problem with SPI NOR flash. This is because I've never
>> really used USB on this platform intensively. But I'm nearly 100%
>> sure, that all changes that add some delays (or debug printfs)
>> resulting in a "working solution", either in the USB case or the SPI
>> NOR case, are just papering over the real problem.
>>
> 
> After a quick chat with Mark Rutland here at ELC, he alluded that there
> could be a problem with the PL310 interfering with the L1 DCACHE. I won't
> be able to try it until I get back, but perhaps somebody can test turning
> off the PL310?
> 
> --- a/include/configs/socfpga_common.h
> +++ b/include/configs/socfpga_common.h
> @@ -78,7 +78,6 @@
>   * Cache
>   */
>  #define CONFIG_SYS_CACHELINE_SIZE 32
> -#define CONFIG_SYS_L2_PL310
>  #define CONFIG_SYS_PL310_BASE          SOCFPGA_MPUL2_ADDRESS
> 
>  Dinh
> 
If this is about disabling PL310 (L2 cache controller), then I already
tried that. It did not help :(

-- 
Best regards,
Marek Vasut

[U-Boot] SoCFPGA cache / S-bit problem - was Re: Newbie SPL question for socfpga_sockit

[Dinh Nguyen]

On Wed, Apr 6, 2016 at 11:46 AM, Marek Vasut <marex@denx.de> wrote:
> If this is about disabling PL310 (L2 cache controller), then I already
> tried that. It did not help :(
>

Yes, it is...I'll continue to troll around some more.

Dinh

[U-Boot] Newbie SPL question for socfpga_sockit

[Marek Vasut]

On 04/06/2016 05:04 PM, Phil Reid wrote:
> On 6/04/2016 7:51 PM, Marek Vasut wrote:
>> On 04/06/2016 09:00 AM, Phil Reid wrote:
>>> On 6/04/2016 6:03 AM, Marek Vasut wrote:
>>>> On 04/05/2016 10:33 AM, Phil Reid wrote:
>>>>> On 27/03/2016 4:52 AM, Marek Vasut wrote:
>>>>>> On 03/22/2016 06:06 PM, Dinh Nguyen wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 03/20/2016 11:42 AM, Marek Vasut wrote:
>>>>>>>>>
>>>>>>>>> Sorry, I know that doesn't help. So let's walk through my
>>>>>>>>> workflow.
>>>>>>>>> I am
>>>>>>>>> not using any Altera tools when I build.
>>>>>>>>>
>>>>>>>>> $make socfpga_de0_nano_soc_defconfig
>>>>>>>>> $make u-boot-with-spl.sfp
>>>>>>>>> $dd if=u-boot-with-spl.sfp of=/dev/sdb3
>>>>>>>>>
>>>>>>>>> My gcc is: arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1)
>>>>>>>>> 4.7.3
>>>>>>>>>
>>>>>>>>> Has the board ever worked for you at all? Can you try this image:
>>>>>>>>>
>>>>>>>>> https://rocketboards.org/foswiki/view/Documentation/AtlasSoCSdCardImage
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Dinh
>>>>>>>>
>>>>>>>> I just ported U-Boot to another customer board. I noticed QSPI has
>>>>>>>> problems and USB can be flaky. That's the standard cache issue we
>>>>>>>> have, disabling dcache fixed that.
>>>>>>>>
>>>>>>>> I am starting to wonder whether we're hitting some corner case
>>>>>>>> here.
>>>>>>>> Maybe we should eventually try and trace all the register reads and
>>>>>>>> writes generated by the DDR calibration code both in old and new
>>>>>>>> SPL
>>>>>>>> and make a diff to see if something really did change.
>>>>>>>>
>>>>>>>> Dinh, can you share the marking on the SoC and the DRAMs on your
>>>>>>>> board?
>>>>>>>>
>>>>>>>
>>>>>>> My SoC is:
>>>>>>>
>>>>>>> 5CSEMA4U23C6N
>>>>>>> CACAU1525A
>>>>>>>
>>>>>>> DRAMs are:
>>>>>>>
>>>>>>> ISSI 1510
>>>>>>> IS43TR16256A
>>>>>>> 15HBL K080
>>>>>>> P4482100QER2 TWN
>>>>>>
>>>>>> Thanks, that's indeed rev. C . About time I bang my head against the
>>>>>> desk because this is creepy.
>>>>>>
>>>>>>
>>>>> FYI
>>>>>
>>>>> I've just spend some time trying to update the spl / uboot / kernel &
>>>>> rootfs image on our
>>>>> Altera socdk to use for some software testing / development.
>>>>> Unfortunately it fails in the mem calibration process with the latest
>>>>> uboot most of the time.
>>>>> And when it does boot somtimes fails loading uboot fomr the mmc.
>>>>
>>>> Try this u-boot-socfpga/ddr branch [1] , see if it works for you.
>>>>
>>>> [1]
>>>> http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=shortlog;h=refs/heads/ddr
>>>>
>>>>
>>>>
>>>
>>> Spent a bit of time on it and things are very weird. So far no luck
>>> booting with the ddr branch.
>>> I got the memory calibration to pass but then had problems with loading
>>> uboot. Using the mmc.
>>> Say no device found for the mmc. error -19.
>>
>> Which board is this ? How wide is the MMC data bus ?
>>
>>> When I try to add some extra debug in things fall over.
>>> Sometimes just hangs in the Memory cal (and not changing anything
>>> there).
>>> Then sometimes I get missing DTB.
>>> I found the uboot-with-spl.sfp file generated by the latest uboot tree
>>> and tried burning that with
>>> same results.
>>>
>>> Reverted back to the image available on rocketboards and wrote that to
>>> the card.
>>> Thinking something strange with the card (thou I tried several) and that
>>> works fine.
>>> Sourced from
>>> https://rocketboards.org/foswiki/view/Documentation/AlteraSoCDevelopmentBoard
>>>
>>
>> Are you actually using the SoCDK or some custom board ?
>>
> I've got two boards here.
> The Altera Cyclone V SoC FPGA Development Kit Board RevC
> which is the SocDK right?

Yes, that's the SoCDK.

Can you confirm to me whether or not the SoCDK boots reliably in the
default configuration provided with u-boot-socfpga/ddr branch, with DRAM
calibration always passing?

If the MMC fails, can you show me how do you test the MMC ?

I will try the SOCDK later, once I have some time. Boot/output log would
really help too.

> And our own board design.
>
> Our design works fine with new uboot's.
> Just can't get things to work with the dek kit.
> It's fairly similar to the SocDK
> 
> I'm building two different version of uboot.
> Using the two different qts generated files.
> I've setup a separate defconfig / dts and board config for our board.
> 
> I'd really like to find the quartus project that was used to generate
> the qts files committed into the uboot tree. All the ones I've used so
> far have different ddr timing and pin configs!

It's most likely generated from GHRD 15.0 or 15.1 , the result should be
the same either way.

-- 
Best regards,
Marek Vasut

[U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 6 April 2016 at 03:43, Marek Vasut <marex@denx.de> wrote:
> On 04/06/2016 03:17 AM, George Broz wrote:
>> On 5 April 2016 at 17:45, Marek Vasut <marex@denx.de> wrote:
>>> On 04/06/2016 02:31 AM, George Broz wrote:
>>>> On 5 April 2016 at 15:03, Marek Vasut <marex@denx.de> wrote:
>>>>> On 04/05/2016 10:33 AM, Phil Reid wrote:
>>>>>> On 27/03/2016 4:52 AM, Marek Vasut wrote:
>>>>>>> On 03/22/2016 06:06 PM, Dinh Nguyen wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 03/20/2016 11:42 AM, Marek Vasut wrote:
>>>>>>>>>>
>>>>>>>>>> Sorry, I know that doesn't help. So let's walk through my workflow.
>>>>>>>>>> I am
>>>>>>>>>> not using any Altera tools when I build.
>>>>>>>>>>
>>>>>>>>>> $make socfpga_de0_nano_soc_defconfig
>>>>>>>>>> $make u-boot-with-spl.sfp
>>>>>>>>>> $dd if=u-boot-with-spl.sfp of=/dev/sdb3
>>>>>>>>>>
>>>>>>>>>> My gcc is: arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3
>>>>>>>>>>
>>>>>>>>>> Has the board ever worked for you at all? Can you try this image:
>>>>>>>>>>
>>>>>>>>>> https://rocketboards.org/foswiki/view/Documentation/AtlasSoCSdCardImage
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Dinh
>>>>>>>>>
>>>>>>>>> I just ported U-Boot to another customer board. I noticed QSPI has
>>>>>>>>> problems and USB can be flaky. That's the standard cache issue we
>>>>>>>>> have, disabling dcache fixed that.
>>>>>>>>>
>>>>>>>>> I am starting to wonder whether we're hitting some corner case here.
>>>>>>>>> Maybe we should eventually try and trace all the register reads and
>>>>>>>>> writes generated by the DDR calibration code both in old and new SPL
>>>>>>>>> and make a diff to see if something really did change.
>>>>>>>>>
>>>>>>>>> Dinh, can you share the marking on the SoC and the DRAMs on your board?
>>>>>>>>>
>>>>>>>>
>>>>>>>> My SoC is:
>>>>>>>>
>>>>>>>> 5CSEMA4U23C6N
>>>>>>>> CACAU1525A
>>>>>>>>
>>>>>>>> DRAMs are:
>>>>>>>>
>>>>>>>> ISSI 1510
>>>>>>>> IS43TR16256A
>>>>>>>> 15HBL K080
>>>>>>>> P4482100QER2 TWN
>>>>>>>
>>>>>>> Thanks, that's indeed rev. C . About time I bang my head against the
>>>>>>> desk because this is creepy.
>>>>>>>
>>>>>>>
>>>>>> FYI
>>>>>>
>>>>>> I've just spend some time trying to update the spl / uboot / kernel &
>>>>>> rootfs image on our
>>>>>> Altera socdk to use for some software testing / development.
>>>>>> Unfortunately it fails in the mem calibration process with the latest
>>>>>> uboot most of the time.
>>>>>> And when it does boot somtimes fails loading uboot fomr the mmc.
>>>>>
>>>>> Try this u-boot-socfpga/ddr branch [1] , see if it works for you.
>>>>>
>>>>> [1]
>>>>> http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=shortlog;h=refs/heads/ddr
>>>>
>>>> I downloaded a "snapshot" from the above link producing,
>>>> u-boot-socfpga-1931be2.tar.gz
>>>>
>>>> When I try to build for sockit or de0_nano_soc I get:
>>>>
>>>>  CC      drivers/mmc/mmc-uclass.o
>>>>   CC      drivers/mmc/dw_mmc.o
>>>>   CC      drivers/mmc/mmc.o
>>>>   CC      drivers/mmc/socfpga_dw_mmc.o
>>>> drivers/mmc/socfpga_dw_mmc.c:9:28: fatal error: asm/arch/dwmmc.h: No
>>>> such file or directory
>>>>  #include <asm/arch/dwmmc.h>
>>>>                             ^
>>>> compilation terminated.
>>>> make[1]: *** [drivers/mmc/socfpga_dw_mmc.o] Error 1
>>>> make: *** [drivers/mmc] Error 2
>>>
>>> Thanks for spotting this. Did you try the most basic of basic approaches:
>>>
>>> diff --git a/drivers/mmc/socfpga_dw_mmc.c b/drivers/mmc/socfpga_dw_mmc.c
>>> index 43a7e7e..097db81 100644
>>> --- a/drivers/mmc/socfpga_dw_mmc.c
>>> +++ b/drivers/mmc/socfpga_dw_mmc.c
>>> @@ -6,7 +6,6 @@
>>>
>>>  #include <common.h>
>>>  #include <asm/arch/clock_manager.h>
>>> -#include <asm/arch/dwmmc.h>
>>>  #include <asm/arch/system_manager.h>
>>>  #include <dm.h>
>>>  #include <dwmmc.h>
>>>
>>> The git tree is updated now.
>>
>> It compiles and it works!
>>
>> On sockit:
>>
>> U-Boot SPL 2016.03 (Apr 05 2016 - 17:57:23)
>> 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
>>
>> First time that an SPL built from a recent version has run successfully
>> on that board.
>>
>> Will try it out on de0 tomorrow morning...
>
> This is great news, thanks!

This patch also fixes the intermittent SDRAM calibration failures on my
de0_nano_soc board. Thanks so much!


Now with up-to-date versions of SPL and image... I have some
USB questions/news/observations:

When using an OTG cable between USB port and mass storage
device, the de0_nano_soc board is able to detect and access some USB
sticks. The detection with these is almost immediate from when 'usb start'
is entered. If the same (working) USB stick is used with a non-OTG cable,
I get the timeout messages from before:

dwc_otg_core_host_init: Timeout!
dwc_otg_core_host_init: Timeout!

and this is true even if I add 'dr_mode = "host" ' to the dts for usb1
of the de0
(and rebuild/reload). The older SPL/image that ships from the Terasic factory
detects USB sticks with a non-OTG cable, (the cable that ships with the unit).
What is the correct "expected" behavior here?? Is an OTG cable required or
not?

Even with the OTG cable, some USB sticks "fail" in a not-so-great way.
I have a Kingston stick and the sequence goes like this:

=> usb reset
resetting USB...
USB0:   Core Release: 2.93a
scanning bus 0 for devices...

<<< 1 minute, 41 seconds pass before >>>
... Device NOT ready
   Request Sense returned 00 00 00

 <<< then another  24 seconds pass before >>>

2 USB Device(s) found

It was able to read some information about the stick:

=> usb info
:
2: Mass Storage,  USB Revision 2.0
- Kingston DataTraveler SE9 0014857749E5ECB0173000D3
- Class: (from Interface) Mass Storage
- PacketSize: 64  Configurations: 1
- Vendor: 0x0930  Product 0x6545 Version 1.0
   Configuration: 1
   - Interfaces: 1 Bus Powered 200mA
     Interface: 0
     - Alternate Setting 0, Endpoints: 2
     - Class Mass Storage, Transp. SCSI, Bulk only
     - Endpoint 1 In Bulk MaxPacket 512
     - Endpoint 2 Out Bulk MaxPacket 512

BUT, the stick cannot be accessed otherwise, for example:

=> usb part 0
## Unknown partition table type 0


Is there any feature of the USB stick that would indicate
whether or not it is "compatible" with u-boot?


Thanks again for the calibration fix! Let me
know if there is something else I can test!

Best regards,
--George Broz

>
> Best regards,
> Marek Vasut

[U-Boot] Newbie SPL question for socfpga_sockit

[Marek Vasut]

On 04/07/2016 03:42 AM, George Broz wrote:

Hi,

>>> U-Boot SPL 2016.03 (Apr 05 2016 - 17:57:23)
>>> 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
>>>
>>> First time that an SPL built from a recent version has run successfully
>>> on that board.
>>>
>>> Will try it out on de0 tomorrow morning...
>>
>> This is great news, thanks!
> 
> This patch also fixes the intermittent SDRAM calibration failures on my
> de0_nano_soc board. Thanks so much!

Great

> Now with up-to-date versions of SPL and image... I have some
> USB questions/news/observations:
> 
> When using an OTG cable between USB port and mass storage
> device, the de0_nano_soc board is able to detect and access some USB
> sticks. The detection with these is almost immediate from when 'usb start'
> is entered. If the same (working) USB stick is used with a non-OTG cable,
> I get the timeout messages from before:
> 
> dwc_otg_core_host_init: Timeout!
> dwc_otg_core_host_init: Timeout!
> 
> and this is true even if I add 'dr_mode = "host" '

I don't think the driver supports the dr_mode property yet. Patch is
welcome.

> to the dts for usb1
> of the de0
> (and rebuild/reload). The older SPL/image that ships from the Terasic factory
> detects USB sticks with a non-OTG cable, (the cable that ships with the unit).
> What is the correct "expected" behavior here?? Is an OTG cable required or
> not?

The DWC2 driver tests the value of the OTG ID pin, so if you don't use
OTG cable with correct ID pin setup, the host won't work.

> Even with the OTG cable, some USB sticks "fail" in a not-so-great way.
> I have a Kingston stick and the sequence goes like this:
> 
> => usb reset
> resetting USB...
> USB0:   Core Release: 2.93a
> scanning bus 0 for devices...
> 
> <<< 1 minute, 41 seconds pass before >>>
> ... Device NOT ready
>    Request Sense returned 00 00 00
> 
>  <<< then another  24 seconds pass before >>>
> 
> 2 USB Device(s) found
> 
> It was able to read some information about the stick:
> 
> => usb info
> :
> 2: Mass Storage,  USB Revision 2.0
> - Kingston DataTraveler SE9 0014857749E5ECB0173000D3
> - Class: (from Interface) Mass Storage
> - PacketSize: 64  Configurations: 1
> - Vendor: 0x0930  Product 0x6545 Version 1.0
>    Configuration: 1
>    - Interfaces: 1 Bus Powered 200mA
>      Interface: 0
>      - Alternate Setting 0, Endpoints: 2
>      - Class Mass Storage, Transp. SCSI, Bulk only
>      - Endpoint 1 In Bulk MaxPacket 512
>      - Endpoint 2 Out Bulk MaxPacket 512
> 
> BUT, the stick cannot be accessed otherwise, for example:
> 
> => usb part 0
> ## Unknown partition table type 0
> 
> 
> Is there any feature of the USB stick that would indicate
> whether or not it is "compatible" with u-boot?

Can you do "dcache off" before you do "usb reset" and see if that fixes
the problem ?

> Thanks again for the calibration fix! Let me
> know if there is something else I can test!

Yeah, I CCed you on the DDR patches, so you can reply with your
Tested-By for SoCkit and Nano-SoC. Thanks

Best regards,
Marek Vasut

[U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 6 April 2016 at 19:05, Marek Vasut <marex@denx.de> wrote:
> On 04/07/2016 03:42 AM, George Broz wrote:
>
> Hi,
>
>>>> U-Boot SPL 2016.03 (Apr 05 2016 - 17:57:23)
>>>> 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
>>>>
>>>> First time that an SPL built from a recent version has run successfully
>>>> on that board.
>>>>
>>>> Will try it out on de0 tomorrow morning...
>>>
>>> This is great news, thanks!
>>
>> This patch also fixes the intermittent SDRAM calibration failures on my
>> de0_nano_soc board. Thanks so much!
>
> Great
>
>> Now with up-to-date versions of SPL and image... I have some
>> USB questions/news/observations:
>>
>> When using an OTG cable between USB port and mass storage
>> device, the de0_nano_soc board is able to detect and access some USB
>> sticks. The detection with these is almost immediate from when 'usb start'
>> is entered. If the same (working) USB stick is used with a non-OTG cable,
>> I get the timeout messages from before:
>>
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>>
>> and this is true even if I add 'dr_mode = "host" '
>
> I don't think the driver supports the dr_mode property yet. Patch is
> welcome.
>
>> to the dts for usb1
>> of the de0
>> (and rebuild/reload). The older SPL/image that ships from the Terasic factory
>> detects USB sticks with a non-OTG cable, (the cable that ships with the unit).
>> What is the correct "expected" behavior here?? Is an OTG cable required or
>> not?
>
> The DWC2 driver tests the value of the OTG ID pin, so if you don't use
> OTG cable with correct ID pin setup, the host won't work.
>
>> Even with the OTG cable, some USB sticks "fail" in a not-so-great way.
>> I have a Kingston stick and the sequence goes like this:
>>
>> => usb reset
>> resetting USB...
>> USB0:   Core Release: 2.93a
>> scanning bus 0 for devices...
>>
>> <<< 1 minute, 41 seconds pass before >>>
>> ... Device NOT ready
>>    Request Sense returned 00 00 00
>>
>>  <<< then another  24 seconds pass before >>>
>>
>> 2 USB Device(s) found
>>
>> It was able to read some information about the stick:
>>
>> => usb info
>> :
>> 2: Mass Storage,  USB Revision 2.0
>> - Kingston DataTraveler SE9 0014857749E5ECB0173000D3
>> - Class: (from Interface) Mass Storage
>> - PacketSize: 64  Configurations: 1
>> - Vendor: 0x0930  Product 0x6545 Version 1.0
>>    Configuration: 1
>>    - Interfaces: 1 Bus Powered 200mA
>>      Interface: 0
>>      - Alternate Setting 0, Endpoints: 2
>>      - Class Mass Storage, Transp. SCSI, Bulk only
>>      - Endpoint 1 In Bulk MaxPacket 512
>>      - Endpoint 2 Out Bulk MaxPacket 512
>>
>> BUT, the stick cannot be accessed otherwise, for example:
>>
>> => usb part 0
>> ## Unknown partition table type 0
>>
>>
>> Is there any feature of the USB stick that would indicate
>> whether or not it is "compatible" with u-boot?
>
> Can you do "dcache off" before you do "usb reset" and see if that fixes
> the problem ?

The behavior is unchanged if "dcache off" done before "usb reset".

Best regards,
--George Broz

>
>> Thanks again for the calibration fix! Let me
>> know if there is something else I can test!
>
> Yeah, I CCed you on the DDR patches, so you can reply with your
> Tested-By for SoCkit and Nano-SoC. Thanks
>
> Best regards,
> Marek Vasut

[U-Boot] Newbie SPL question for socfpga_sockit

[Marek Vasut]

On 04/07/2016 03:14 PM, George Broz wrote:
> On 6 April 2016 at 19:05, Marek Vasut <marex@denx.de> wrote:
>> On 04/07/2016 03:42 AM, George Broz wrote:
>>
>> Hi,
>>
>>>>> U-Boot SPL 2016.03 (Apr 05 2016 - 17:57:23)
>>>>> 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
>>>>>
>>>>> First time that an SPL built from a recent version has run successfully
>>>>> on that board.
>>>>>
>>>>> Will try it out on de0 tomorrow morning...
>>>>
>>>> This is great news, thanks!
>>>
>>> This patch also fixes the intermittent SDRAM calibration failures on my
>>> de0_nano_soc board. Thanks so much!
>>
>> Great
>>
>>> Now with up-to-date versions of SPL and image... I have some
>>> USB questions/news/observations:
>>>
>>> When using an OTG cable between USB port and mass storage
>>> device, the de0_nano_soc board is able to detect and access some USB
>>> sticks. The detection with these is almost immediate from when 'usb start'
>>> is entered. If the same (working) USB stick is used with a non-OTG cable,
>>> I get the timeout messages from before:
>>>
>>> dwc_otg_core_host_init: Timeout!
>>> dwc_otg_core_host_init: Timeout!
>>>
>>> and this is true even if I add 'dr_mode = "host" '
>>
>> I don't think the driver supports the dr_mode property yet. Patch is
>> welcome.
>>
>>> to the dts for usb1
>>> of the de0
>>> (and rebuild/reload). The older SPL/image that ships from the Terasic factory
>>> detects USB sticks with a non-OTG cable, (the cable that ships with the unit).
>>> What is the correct "expected" behavior here?? Is an OTG cable required or
>>> not?
>>
>> The DWC2 driver tests the value of the OTG ID pin, so if you don't use
>> OTG cable with correct ID pin setup, the host won't work.
>>
>>> Even with the OTG cable, some USB sticks "fail" in a not-so-great way.
>>> I have a Kingston stick and the sequence goes like this:
>>>
>>> => usb reset
>>> resetting USB...
>>> USB0:   Core Release: 2.93a
>>> scanning bus 0 for devices...
>>>
>>> <<< 1 minute, 41 seconds pass before >>>
>>> ... Device NOT ready
>>>    Request Sense returned 00 00 00
>>>
>>>  <<< then another  24 seconds pass before >>>
>>>
>>> 2 USB Device(s) found
>>>
>>> It was able to read some information about the stick:
>>>
>>> => usb info
>>> :
>>> 2: Mass Storage,  USB Revision 2.0
>>> - Kingston DataTraveler SE9 0014857749E5ECB0173000D3
>>> - Class: (from Interface) Mass Storage
>>> - PacketSize: 64  Configurations: 1
>>> - Vendor: 0x0930  Product 0x6545 Version 1.0
>>>    Configuration: 1
>>>    - Interfaces: 1 Bus Powered 200mA
>>>      Interface: 0
>>>      - Alternate Setting 0, Endpoints: 2
>>>      - Class Mass Storage, Transp. SCSI, Bulk only
>>>      - Endpoint 1 In Bulk MaxPacket 512
>>>      - Endpoint 2 Out Bulk MaxPacket 512
>>>
>>> BUT, the stick cannot be accessed otherwise, for example:
>>>
>>> => usb part 0
>>> ## Unknown partition table type 0
>>>
>>>
>>> Is there any feature of the USB stick that would indicate
>>> whether or not it is "compatible" with u-boot?
>>
>> Can you do "dcache off" before you do "usb reset" and see if that fixes
>> the problem ?
> 
> The behavior is unchanged if "dcache off" done before "usb reset".

Try with the attached patch (and probably with dcache off)

Best regards,
Marek Vasut
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Revert-usb-Change-power-on-scanning-timeout-handling.patch
Type: text/x-patch
Size: 11819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160407/b9185f72/attachment.bin>

[U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 7 April 2016 at 13:39, Marek Vasut <marex@denx.de> wrote:
> On 04/07/2016 03:14 PM, George Broz wrote:
>> On 6 April 2016 at 19:05, Marek Vasut <marex@denx.de> wrote:
>>> On 04/07/2016 03:42 AM, George Broz wrote:
>>>
>>> Hi,
>>>
>>>>>> U-Boot SPL 2016.03 (Apr 05 2016 - 17:57:23)
>>>>>> 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
>>>>>>
>>>>>> First time that an SPL built from a recent version has run successfully
>>>>>> on that board.
>>>>>>
>>>>>> Will try it out on de0 tomorrow morning...
>>>>>
>>>>> This is great news, thanks!
>>>>
>>>> This patch also fixes the intermittent SDRAM calibration failures on my
>>>> de0_nano_soc board. Thanks so much!
>>>
>>> Great
>>>
>>>> Now with up-to-date versions of SPL and image... I have some
>>>> USB questions/news/observations:
>>>>
>>>> When using an OTG cable between USB port and mass storage
>>>> device, the de0_nano_soc board is able to detect and access some USB
>>>> sticks. The detection with these is almost immediate from when 'usb start'
>>>> is entered. If the same (working) USB stick is used with a non-OTG cable,
>>>> I get the timeout messages from before:
>>>>
>>>> dwc_otg_core_host_init: Timeout!
>>>> dwc_otg_core_host_init: Timeout!
>>>>
>>>> and this is true even if I add 'dr_mode = "host" '
>>>
>>> I don't think the driver supports the dr_mode property yet. Patch is
>>> welcome.
>>>
>>>> to the dts for usb1
>>>> of the de0
>>>> (and rebuild/reload). The older SPL/image that ships from the Terasic factory
>>>> detects USB sticks with a non-OTG cable, (the cable that ships with the unit).
>>>> What is the correct "expected" behavior here?? Is an OTG cable required or
>>>> not?
>>>
>>> The DWC2 driver tests the value of the OTG ID pin, so if you don't use
>>> OTG cable with correct ID pin setup, the host won't work.
>>>
>>>> Even with the OTG cable, some USB sticks "fail" in a not-so-great way.
>>>> I have a Kingston stick and the sequence goes like this:
>>>>
>>>> => usb reset
>>>> resetting USB...
>>>> USB0:   Core Release: 2.93a
>>>> scanning bus 0 for devices...
>>>>
>>>> <<< 1 minute, 41 seconds pass before >>>
>>>> ... Device NOT ready
>>>>    Request Sense returned 00 00 00
>>>>
>>>>  <<< then another  24 seconds pass before >>>
>>>>
>>>> 2 USB Device(s) found
>>>>
>>>> It was able to read some information about the stick:
>>>>
>>>> => usb info
>>>> :
>>>> 2: Mass Storage,  USB Revision 2.0
>>>> - Kingston DataTraveler SE9 0014857749E5ECB0173000D3
>>>> - Class: (from Interface) Mass Storage
>>>> - PacketSize: 64  Configurations: 1
>>>> - Vendor: 0x0930  Product 0x6545 Version 1.0
>>>>    Configuration: 1
>>>>    - Interfaces: 1 Bus Powered 200mA
>>>>      Interface: 0
>>>>      - Alternate Setting 0, Endpoints: 2
>>>>      - Class Mass Storage, Transp. SCSI, Bulk only
>>>>      - Endpoint 1 In Bulk MaxPacket 512
>>>>      - Endpoint 2 Out Bulk MaxPacket 512
>>>>
>>>> BUT, the stick cannot be accessed otherwise, for example:
>>>>
>>>> => usb part 0
>>>> ## Unknown partition table type 0
>>>>
>>>>
>>>> Is there any feature of the USB stick that would indicate
>>>> whether or not it is "compatible" with u-boot?
>>>
>>> Can you do "dcache off" before you do "usb reset" and see if that fixes
>>> the problem ?
>>
>> The behavior is unchanged if "dcache off" done before "usb reset".
>
> Try with the attached patch (and probably with dcache off)

The patch applied cleanly. The behavior is unchanged with both
dcache on and off. The "good" sticks still work, and "bad" sticks still don't.

Best regards,
--George

>
> Best regards,
> Marek Vasut

[U-Boot] Newbie SPL question for socfpga_sockit

[Marek Vasut]

On 04/08/2016 01:31 AM, George Broz wrote:
> On 7 April 2016 at 13:39, Marek Vasut <marex@denx.de> wrote:
>> On 04/07/2016 03:14 PM, George Broz wrote:
>>> On 6 April 2016 at 19:05, Marek Vasut <marex@denx.de> wrote:
>>>> On 04/07/2016 03:42 AM, George Broz wrote:
>>>>
>>>> Hi,
>>>>
>>>>>>> U-Boot SPL 2016.03 (Apr 05 2016 - 17:57:23)
>>>>>>> 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
>>>>>>>
>>>>>>> First time that an SPL built from a recent version has run successfully
>>>>>>> on that board.
>>>>>>>
>>>>>>> Will try it out on de0 tomorrow morning...
>>>>>>
>>>>>> This is great news, thanks!
>>>>>
>>>>> This patch also fixes the intermittent SDRAM calibration failures on my
>>>>> de0_nano_soc board. Thanks so much!
>>>>
>>>> Great
>>>>
>>>>> Now with up-to-date versions of SPL and image... I have some
>>>>> USB questions/news/observations:
>>>>>
>>>>> When using an OTG cable between USB port and mass storage
>>>>> device, the de0_nano_soc board is able to detect and access some USB
>>>>> sticks. The detection with these is almost immediate from when 'usb start'
>>>>> is entered. If the same (working) USB stick is used with a non-OTG cable,
>>>>> I get the timeout messages from before:
>>>>>
>>>>> dwc_otg_core_host_init: Timeout!
>>>>> dwc_otg_core_host_init: Timeout!
>>>>>
>>>>> and this is true even if I add 'dr_mode = "host" '
>>>>
>>>> I don't think the driver supports the dr_mode property yet. Patch is
>>>> welcome.
>>>>
>>>>> to the dts for usb1
>>>>> of the de0
>>>>> (and rebuild/reload). The older SPL/image that ships from the Terasic factory
>>>>> detects USB sticks with a non-OTG cable, (the cable that ships with the unit).
>>>>> What is the correct "expected" behavior here?? Is an OTG cable required or
>>>>> not?
>>>>
>>>> The DWC2 driver tests the value of the OTG ID pin, so if you don't use
>>>> OTG cable with correct ID pin setup, the host won't work.
>>>>
>>>>> Even with the OTG cable, some USB sticks "fail" in a not-so-great way.
>>>>> I have a Kingston stick and the sequence goes like this:
>>>>>
>>>>> => usb reset
>>>>> resetting USB...
>>>>> USB0:   Core Release: 2.93a
>>>>> scanning bus 0 for devices...
>>>>>
>>>>> <<< 1 minute, 41 seconds pass before >>>
>>>>> ... Device NOT ready
>>>>>    Request Sense returned 00 00 00
>>>>>
>>>>>  <<< then another  24 seconds pass before >>>
>>>>>
>>>>> 2 USB Device(s) found
>>>>>
>>>>> It was able to read some information about the stick:
>>>>>
>>>>> => usb info
>>>>> :
>>>>> 2: Mass Storage,  USB Revision 2.0
>>>>> - Kingston DataTraveler SE9 0014857749E5ECB0173000D3
>>>>> - Class: (from Interface) Mass Storage
>>>>> - PacketSize: 64  Configurations: 1
>>>>> - Vendor: 0x0930  Product 0x6545 Version 1.0
>>>>>    Configuration: 1
>>>>>    - Interfaces: 1 Bus Powered 200mA
>>>>>      Interface: 0
>>>>>      - Alternate Setting 0, Endpoints: 2
>>>>>      - Class Mass Storage, Transp. SCSI, Bulk only
>>>>>      - Endpoint 1 In Bulk MaxPacket 512
>>>>>      - Endpoint 2 Out Bulk MaxPacket 512
>>>>>
>>>>> BUT, the stick cannot be accessed otherwise, for example:
>>>>>
>>>>> => usb part 0
>>>>> ## Unknown partition table type 0
>>>>>
>>>>>
>>>>> Is there any feature of the USB stick that would indicate
>>>>> whether or not it is "compatible" with u-boot?
>>>>
>>>> Can you do "dcache off" before you do "usb reset" and see if that fixes
>>>> the problem ?
>>>
>>> The behavior is unchanged if "dcache off" done before "usb reset".
>>
>> Try with the attached patch (and probably with dcache off)
> 
> The patch applied cleanly. The behavior is unchanged with both
> dcache on and off. The "good" sticks still work, and "bad" sticks still don't.

OK. Then I should probably go hunting for Kingston DataTraveler SE9,
right ? Can you give me a link to the stick you have, so I know what
crappy device to look for ? Thanks!

Best regards,
Marek Vasut

[U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 7 April 2016 at 16:36, Marek Vasut <marex@denx.de> wrote:
> On 04/08/2016 01:31 AM, George Broz wrote:
>> On 7 April 2016 at 13:39, Marek Vasut <marex@denx.de> wrote:
>>> On 04/07/2016 03:14 PM, George Broz wrote:
>>>> On 6 April 2016 at 19:05, Marek Vasut <marex@denx.de> wrote:
>>>>> On 04/07/2016 03:42 AM, George Broz wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>>>>> U-Boot SPL 2016.03 (Apr 05 2016 - 17:57:23)
>>>>>>>> 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
>>>>>>>>
>>>>>>>> First time that an SPL built from a recent version has run successfully
>>>>>>>> on that board.
>>>>>>>>
>>>>>>>> Will try it out on de0 tomorrow morning...
>>>>>>>
>>>>>>> This is great news, thanks!
>>>>>>
>>>>>> This patch also fixes the intermittent SDRAM calibration failures on my
>>>>>> de0_nano_soc board. Thanks so much!
>>>>>
>>>>> Great
>>>>>
>>>>>> Now with up-to-date versions of SPL and image... I have some
>>>>>> USB questions/news/observations:
>>>>>>
>>>>>> When using an OTG cable between USB port and mass storage
>>>>>> device, the de0_nano_soc board is able to detect and access some USB
>>>>>> sticks. The detection with these is almost immediate from when 'usb start'
>>>>>> is entered. If the same (working) USB stick is used with a non-OTG cable,
>>>>>> I get the timeout messages from before:
>>>>>>
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>
>>>>>> and this is true even if I add 'dr_mode = "host" '
>>>>>
>>>>> I don't think the driver supports the dr_mode property yet. Patch is
>>>>> welcome.
>>>>>
>>>>>> to the dts for usb1
>>>>>> of the de0
>>>>>> (and rebuild/reload). The older SPL/image that ships from the Terasic factory
>>>>>> detects USB sticks with a non-OTG cable, (the cable that ships with the unit).
>>>>>> What is the correct "expected" behavior here?? Is an OTG cable required or
>>>>>> not?
>>>>>
>>>>> The DWC2 driver tests the value of the OTG ID pin, so if you don't use
>>>>> OTG cable with correct ID pin setup, the host won't work.
>>>>>
>>>>>> Even with the OTG cable, some USB sticks "fail" in a not-so-great way.
>>>>>> I have a Kingston stick and the sequence goes like this:
>>>>>>
>>>>>> => usb reset
>>>>>> resetting USB...
>>>>>> USB0:   Core Release: 2.93a
>>>>>> scanning bus 0 for devices...
>>>>>>
>>>>>> <<< 1 minute, 41 seconds pass before >>>
>>>>>> ... Device NOT ready
>>>>>>    Request Sense returned 00 00 00
>>>>>>
>>>>>>  <<< then another  24 seconds pass before >>>
>>>>>>
>>>>>> 2 USB Device(s) found
>>>>>>
>>>>>> It was able to read some information about the stick:
>>>>>>
>>>>>> => usb info
>>>>>> :
>>>>>> 2: Mass Storage,  USB Revision 2.0
>>>>>> - Kingston DataTraveler SE9 0014857749E5ECB0173000D3
>>>>>> - Class: (from Interface) Mass Storage
>>>>>> - PacketSize: 64  Configurations: 1
>>>>>> - Vendor: 0x0930  Product 0x6545 Version 1.0
>>>>>>    Configuration: 1
>>>>>>    - Interfaces: 1 Bus Powered 200mA
>>>>>>      Interface: 0
>>>>>>      - Alternate Setting 0, Endpoints: 2
>>>>>>      - Class Mass Storage, Transp. SCSI, Bulk only
>>>>>>      - Endpoint 1 In Bulk MaxPacket 512
>>>>>>      - Endpoint 2 Out Bulk MaxPacket 512
>>>>>>
>>>>>> BUT, the stick cannot be accessed otherwise, for example:
>>>>>>
>>>>>> => usb part 0
>>>>>> ## Unknown partition table type 0
>>>>>>
>>>>>>
>>>>>> Is there any feature of the USB stick that would indicate
>>>>>> whether or not it is "compatible" with u-boot?
>>>>>
>>>>> Can you do "dcache off" before you do "usb reset" and see if that fixes
>>>>> the problem ?
>>>>
>>>> The behavior is unchanged if "dcache off" done before "usb reset".
>>>
>>> Try with the attached patch (and probably with dcache off)
>>
>> The patch applied cleanly. The behavior is unchanged with both
>> dcache on and off. The "good" sticks still work, and "bad" sticks still don't.
>
> OK. Then I should probably go hunting for Kingston DataTraveler SE9,
> right ? Can you give me a link to the stick you have, so I know what
> crappy device to look for ? Thanks!

Here it is [1] - I have the 8GB version.

I think there will always be crappy sticks that don't work... but do you
have any advice as to what properties will/might generally cause a problem?

[1] http://www.amazon.com/Kingston-Digital-DataTraveler-DTSE9H-16GBZET/dp/B00DYQYITG


FYI - here is the verbose lsusb output for this particular device for
what it's worth:

Bus 001 Device 005: ID 0930:6545 Toshiba Corp. Kingston DataTraveler
102 Flash Drive / HEMA Flash Drive 2 GB / PNY Attache 4GB Stick
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x0930 Toshiba Corp.
  idProduct          0x6545 Kingston DataTraveler 102 Flash Drive /
HEMA Flash Drive 2 GB / PNY Attache 4GB Stick
  bcdDevice            1.00
  iManufacturer           1 Kingston
  iProduct                2 DataTraveler SE9
  iSerial                 3 0014857749E5ECB0173000D3
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              200mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0000
  (Bus Powered)

Best regards,
--George Broz

>
> Best regards,
> Marek Vasut

[U-Boot] Newbie SPL question for socfpga_sockit

[Stefan Roese]

On 08.04.2016 01:51, George Broz wrote:

<snip>

>>>> Try with the attached patch (and probably with dcache off)
>>>
>>> The patch applied cleanly. The behavior is unchanged with both
>>> dcache on and off. The "good" sticks still work, and "bad" sticks still don't.
>>
>> OK. Then I should probably go hunting for Kingston DataTraveler SE9,
>> right ? Can you give me a link to the stick you have, so I know what
>> crappy device to look for ? Thanks!
> 
> Here it is [1] - I have the 8GB version.
> 
> I think there will always be crappy sticks that don't work... but do you
> have any advice as to what properties will/might generally cause a problem?
> 
> [1] http://www.amazon.com/Kingston-Digital-DataTraveler-DTSE9H-16GBZET/dp/B00DYQYITG

I have exactly this stick here (16GiB) version. And it is detected just
fine in both, current mainline Armada XP (theadorable) and x86 boards
(conga-qeval20-qa3-e3845). Here my lsusb output:

Bus 001 Device 004: ID 0930:6545 Toshiba Corp. Kingston DataTraveler 102/2.0 / HEMA Flash Drive 2 GB / PNY Attache 4GB Stick
Couldn't open device, some information will be missing
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x0930 Toshiba Corp.
  idProduct          0x6545 Kingston DataTraveler 102/2.0 / HEMA Flash Drive 2 GB / PNY Attache 4GB Stick
  bcdDevice            1.10
  iManufacturer           1 
  iProduct                2 
  iSerial                 3 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              300mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0

HTP.

Thanks,
Stefan
 


> 
> FYI - here is the verbose lsusb output for this particular device for
> what it's worth:
> 
> Bus 001 Device 005: ID 0930:6545 Toshiba Corp. Kingston DataTraveler
> 102 Flash Drive / HEMA Flash Drive 2 GB / PNY Attache 4GB Stick
> Device Descriptor:
>    bLength                18
>    bDescriptorType         1
>    bcdUSB               2.00
>    bDeviceClass            0 (Defined at Interface level)
>    bDeviceSubClass         0
>    bDeviceProtocol         0
>    bMaxPacketSize0        64
>    idVendor           0x0930 Toshiba Corp.
>    idProduct          0x6545 Kingston DataTraveler 102 Flash Drive /
> HEMA Flash Drive 2 GB / PNY Attache 4GB Stick
>    bcdDevice            1.00
>    iManufacturer           1 Kingston
>    iProduct                2 DataTraveler SE9
>    iSerial                 3 0014857749E5ECB0173000D3
>    bNumConfigurations      1
>    Configuration Descriptor:
>      bLength                 9
>      bDescriptorType         2
>      wTotalLength           32
>      bNumInterfaces          1
>      bConfigurationValue     1
>      iConfiguration          0
>      bmAttributes         0x80
>        (Bus Powered)
>      MaxPower              200mA
>      Interface Descriptor:
>        bLength                 9
>        bDescriptorType         4
>        bInterfaceNumber        0
>        bAlternateSetting       0
>        bNumEndpoints           2
>        bInterfaceClass         8 Mass Storage
>        bInterfaceSubClass      6 SCSI
>        bInterfaceProtocol     80 Bulk-Only
>        iInterface              0
>        Endpoint Descriptor:
>          bLength                 7
>          bDescriptorType         5
>          bEndpointAddress     0x81  EP 1 IN
>          bmAttributes            2
>            Transfer Type            Bulk
>            Synch Type               None
>            Usage Type               Data
>          wMaxPacketSize     0x0200  1x 512 bytes
>          bInterval               0
>        Endpoint Descriptor:
>          bLength                 7
>          bDescriptorType         5
>          bEndpointAddress     0x02  EP 2 OUT
>          bmAttributes            2
>            Transfer Type            Bulk
>            Synch Type               None
>            Usage Type               Data
>          wMaxPacketSize     0x0200  1x 512 bytes
>          bInterval               0
> Device Qualifier (for other device speed):
>    bLength                10
>    bDescriptorType         6
>    bcdUSB               2.00
>    bDeviceClass            0 (Defined at Interface level)
>    bDeviceSubClass         0
>    bDeviceProtocol         0
>    bMaxPacketSize0        64
>    bNumConfigurations      1
> Device Status:     0x0000
>    (Bus Powered)
> 
> Best regards,
> --George Broz
> 
>>
>> Best regards,
>> Marek Vasut
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 


-- 
Viele Gr??e,
Stefan

--
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr at denx.de

[U-Boot] Newbie SPL question for socfpga_sockit

[Marek Vasut]

On 04/08/2016 07:16 AM, Stefan Roese wrote:
> On 08.04.2016 01:51, George Broz wrote:
> 
> <snip>
> 
>>>>> Try with the attached patch (and probably with dcache off)
>>>>
>>>> The patch applied cleanly. The behavior is unchanged with both
>>>> dcache on and off. The "good" sticks still work, and "bad" sticks still don't.
>>>
>>> OK. Then I should probably go hunting for Kingston DataTraveler SE9,
>>> right ? Can you give me a link to the stick you have, so I know what
>>> crappy device to look for ? Thanks!
>>
>> Here it is [1] - I have the 8GB version.
>>
>> I think there will always be crappy sticks that don't work... but do you
>> have any advice as to what properties will/might generally cause a problem?
>>
>> [1] http://www.amazon.com/Kingston-Digital-DataTraveler-DTSE9H-16GBZET/dp/B00DYQYITG
> 
> I have exactly this stick here (16GiB) version. And it is detected just
> fine in both, current mainline Armada XP (theadorable) and x86 boards
> (conga-qeval20-qa3-e3845). Here my lsusb output:

I bought the kingston stick and it's not detected on SoCFPGA SoCkit at
all. Ouch :-(

[...]
Best regards,
Marek Vasut

[U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 8 April 2016 at 05:36, Marek Vasut <marex@denx.de> wrote:
> On 04/08/2016 07:16 AM, Stefan Roese wrote:
>> On 08.04.2016 01:51, George Broz wrote:
>>
>> <snip>
>>
>>>>>> Try with the attached patch (and probably with dcache off)
>>>>>
>>>>> The patch applied cleanly. The behavior is unchanged with both
>>>>> dcache on and off. The "good" sticks still work, and "bad" sticks still don't.
>>>>
>>>> OK. Then I should probably go hunting for Kingston DataTraveler SE9,
>>>> right ? Can you give me a link to the stick you have, so I know what
>>>> crappy device to look for ? Thanks!
>>>
>>> Here it is [1] - I have the 8GB version.
>>>
>>> I think there will always be crappy sticks that don't work... but do you
>>> have any advice as to what properties will/might generally cause a problem?
>>>
>>> [1] http://www.amazon.com/Kingston-Digital-DataTraveler-DTSE9H-16GBZET/dp/B00DYQYITG
>>
>> I have exactly this stick here (16GiB) version. And it is detected just
>> fine in both, current mainline Armada XP (theadorable) and x86 boards
>> (conga-qeval20-qa3-e3845). Here my lsusb output:
>
> I bought the kingston stick and it's not detected on SoCFPGA SoCkit at
> all. Ouch :-(
>
> [...]
> Best regards,
> Marek Vasut

For what it's worth - here is the marking on the OTG chip on the de0_nano_soc:

SMSC
3300-EZK
A1515AC13
515AR3A
ASETV

Best regards,
--George

[U-Boot] Newbie SPL question for socfpga_sockit

[Marek Vasut]

On 04/09/2016 12:40 AM, George Broz wrote:
> On 8 April 2016 at 05:36, Marek Vasut <marex@denx.de> wrote:
>> On 04/08/2016 07:16 AM, Stefan Roese wrote:
>>> On 08.04.2016 01:51, George Broz wrote:
>>>
>>> <snip>
>>>
>>>>>>> Try with the attached patch (and probably with dcache off)
>>>>>>
>>>>>> The patch applied cleanly. The behavior is unchanged with both
>>>>>> dcache on and off. The "good" sticks still work, and "bad" sticks still don't.
>>>>>
>>>>> OK. Then I should probably go hunting for Kingston DataTraveler SE9,
>>>>> right ? Can you give me a link to the stick you have, so I know what
>>>>> crappy device to look for ? Thanks!
>>>>
>>>> Here it is [1] - I have the 8GB version.
>>>>
>>>> I think there will always be crappy sticks that don't work... but do you
>>>> have any advice as to what properties will/might generally cause a problem?
>>>>
>>>> [1] http://www.amazon.com/Kingston-Digital-DataTraveler-DTSE9H-16GBZET/dp/B00DYQYITG
>>>
>>> I have exactly this stick here (16GiB) version. And it is detected just
>>> fine in both, current mainline Armada XP (theadorable) and x86 boards
>>> (conga-qeval20-qa3-e3845). Here my lsusb output:
>>
>> I bought the kingston stick and it's not detected on SoCFPGA SoCkit at
>> all. Ouch :-(
>>
>> [...]
>> Best regards,
>> Marek Vasut
> 
> For what it's worth - here is the marking on the OTG chip on the de0_nano_soc:
> 
> SMSC
> 3300-EZK
> A1515AC13
> 515AR3A
> ASETV

OK, that's the standard/recommended USB3300 PHY. I will keep fiddling
with the Kingston SE9 USB stick to see what's going on, that's probably
some other issue than the cache issue though.

-- 
Best regards,
Marek Vasut

[U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 10 April 2016 at 10:47, Marek Vasut <marex@denx.de> wrote:
> On 04/09/2016 12:40 AM, George Broz wrote:
>> On 8 April 2016 at 05:36, Marek Vasut <marex@denx.de> wrote:
>>> On 04/08/2016 07:16 AM, Stefan Roese wrote:
>>>> On 08.04.2016 01:51, George Broz wrote:
>>>>
>>>> <snip>
>>>>
>>>>>>>> Try with the attached patch (and probably with dcache off)
>>>>>>>
>>>>>>> The patch applied cleanly. The behavior is unchanged with both
>>>>>>> dcache on and off. The "good" sticks still work, and "bad" sticks still don't.
>>>>>>
>>>>>> OK. Then I should probably go hunting for Kingston DataTraveler SE9,
>>>>>> right ? Can you give me a link to the stick you have, so I know what
>>>>>> crappy device to look for ? Thanks!
>>>>>
>>>>> Here it is [1] - I have the 8GB version.
>>>>>
>>>>> I think there will always be crappy sticks that don't work... but do you
>>>>> have any advice as to what properties will/might generally cause a problem?
>>>>>
>>>>> [1] http://www.amazon.com/Kingston-Digital-DataTraveler-DTSE9H-16GBZET/dp/B00DYQYITG
>>>>
>>>> I have exactly this stick here (16GiB) version. And it is detected just
>>>> fine in both, current mainline Armada XP (theadorable) and x86 boards
>>>> (conga-qeval20-qa3-e3845). Here my lsusb output:
>>>
>>> I bought the kingston stick and it's not detected on SoCFPGA SoCkit at
>>> all. Ouch :-(
>>>
>>> [...]
>>> Best regards,
>>> Marek Vasut
>>
>> For what it's worth - here is the marking on the OTG chip on the de0_nano_soc:
>>
>> SMSC
>> 3300-EZK
>> A1515AC13
>> 515AR3A
>> ASETV
>
> OK, that's the standard/recommended USB3300 PHY. I will keep fiddling
> with the Kingston SE9 USB stick to see what's going on, that's probably
> some other issue than the cache issue though.
>
On my third order for an OTG USB mini cable from Amazon, I finally got an
actual OTG cable!

On the SoCKit, using this cable the "dwc_otg_core_host_init: Timeout!"
messages no longer appear.

A few of the USB sticks I have here are immediately recognized and function
normally - a first for me with the latest version of u-boot. For
others, like the
Kingston SE9 stick, I get the same result as you - it's not detected at all.

I have yet to find one of the non-working USB sticks on the SoCKit
fail with the
same sort of long timeout followed by the zombie behavior exhibited by the
DE0/Kingston combination.

Best regards,
--George Broz

> --
> Best regards,
> Marek Vasut

[U-Boot] Newbie SPL question for socfpga_sockit

[Marek Vasut]

On 04/11/2016 04:03 AM, George Broz wrote:
> On 10 April 2016 at 10:47, Marek Vasut <marex@denx.de> wrote:
>> On 04/09/2016 12:40 AM, George Broz wrote:
>>> On 8 April 2016 at 05:36, Marek Vasut <marex@denx.de> wrote:
>>>> On 04/08/2016 07:16 AM, Stefan Roese wrote:
>>>>> On 08.04.2016 01:51, George Broz wrote:
>>>>>
>>>>> <snip>
>>>>>
>>>>>>>>> Try with the attached patch (and probably with dcache off)
>>>>>>>>
>>>>>>>> The patch applied cleanly. The behavior is unchanged with both
>>>>>>>> dcache on and off. The "good" sticks still work, and "bad" sticks still don't.
>>>>>>>
>>>>>>> OK. Then I should probably go hunting for Kingston DataTraveler SE9,
>>>>>>> right ? Can you give me a link to the stick you have, so I know what
>>>>>>> crappy device to look for ? Thanks!
>>>>>>
>>>>>> Here it is [1] - I have the 8GB version.
>>>>>>
>>>>>> I think there will always be crappy sticks that don't work... but do you
>>>>>> have any advice as to what properties will/might generally cause a problem?
>>>>>>
>>>>>> [1] http://www.amazon.com/Kingston-Digital-DataTraveler-DTSE9H-16GBZET/dp/B00DYQYITG
>>>>>
>>>>> I have exactly this stick here (16GiB) version. And it is detected just
>>>>> fine in both, current mainline Armada XP (theadorable) and x86 boards
>>>>> (conga-qeval20-qa3-e3845). Here my lsusb output:
>>>>
>>>> I bought the kingston stick and it's not detected on SoCFPGA SoCkit at
>>>> all. Ouch :-(
>>>>
>>>> [...]
>>>> Best regards,
>>>> Marek Vasut
>>>
>>> For what it's worth - here is the marking on the OTG chip on the de0_nano_soc:
>>>
>>> SMSC
>>> 3300-EZK
>>> A1515AC13
>>> 515AR3A
>>> ASETV
>>
>> OK, that's the standard/recommended USB3300 PHY. I will keep fiddling
>> with the Kingston SE9 USB stick to see what's going on, that's probably
>> some other issue than the cache issue though.
>>
> On my third order for an OTG USB mini cable from Amazon, I finally got an
> actual OTG cable!
> 
> On the SoCKit, using this cable the "dwc_otg_core_host_init: Timeout!"
> messages no longer appear.
> 
> A few of the USB sticks I have here are immediately recognized and function
> normally - a first for me with the latest version of u-boot. For
> others, like the
> Kingston SE9 stick, I get the same result as you - it's not detected at all.
> 
> I have yet to find one of the non-working USB sticks on the SoCKit
> fail with the
> same sort of long timeout followed by the zombie behavior exhibited by the
> DE0/Kingston combination.

Thanks for checking. I also have the SE9 here and it fails indeed, I
will have to look into it later.


-- 
Best regards,
Marek Vasut

[U-Boot] Newbie SPL question for socfpga_sockit

[Dinh Nguyen]

On 04/07/2016 06:31 PM, George Broz wrote:
> On 7 April 2016 at 13:39, Marek Vasut <marex@denx.de> wrote:
>> On 04/07/2016 03:14 PM, George Broz wrote:
>>> On 6 April 2016 at 19:05, Marek Vasut <marex@denx.de> wrote:
>>>> On 04/07/2016 03:42 AM, George Broz wrote:
>>>>
>>>> Hi,
>>>>
>>>>>>> U-Boot SPL 2016.03 (Apr 05 2016 - 17:57:23)
>>>>>>> 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
>>>>>>>
>>>>>>> First time that an SPL built from a recent version has run successfully
>>>>>>> on that board.
>>>>>>>
>>>>>>> Will try it out on de0 tomorrow morning...
>>>>>>
>>>>>> This is great news, thanks!
>>>>>
>>>>> This patch also fixes the intermittent SDRAM calibration failures on my
>>>>> de0_nano_soc board. Thanks so much!
>>>>
>>>> Great
>>>>
>>>>> Now with up-to-date versions of SPL and image... I have some
>>>>> USB questions/news/observations:
>>>>>
>>>>> When using an OTG cable between USB port and mass storage
>>>>> device, the de0_nano_soc board is able to detect and access some USB
>>>>> sticks. The detection with these is almost immediate from when 'usb start'
>>>>> is entered. If the same (working) USB stick is used with a non-OTG cable,
>>>>> I get the timeout messages from before:
>>>>>
>>>>> dwc_otg_core_host_init: Timeout!
>>>>> dwc_otg_core_host_init: Timeout!
>>>>>
>>>>> and this is true even if I add 'dr_mode = "host" '
>>>>
>>>> I don't think the driver supports the dr_mode property yet. Patch is
>>>> welcome.
>>>>
>>>>> to the dts for usb1
>>>>> of the de0
>>>>> (and rebuild/reload). The older SPL/image that ships from the Terasic factory
>>>>> detects USB sticks with a non-OTG cable, (the cable that ships with the unit).
>>>>> What is the correct "expected" behavior here?? Is an OTG cable required or
>>>>> not?
>>>>
>>>> The DWC2 driver tests the value of the OTG ID pin, so if you don't use
>>>> OTG cable with correct ID pin setup, the host won't work.
>>>>
>>>>> Even with the OTG cable, some USB sticks "fail" in a not-so-great way.
>>>>> I have a Kingston stick and the sequence goes like this:
>>>>>
>>>>> => usb reset
>>>>> resetting USB...
>>>>> USB0:   Core Release: 2.93a
>>>>> scanning bus 0 for devices...
>>>>>
>>>>> <<< 1 minute, 41 seconds pass before >>>
>>>>> ... Device NOT ready
>>>>>    Request Sense returned 00 00 00
>>>>>
>>>>>  <<< then another  24 seconds pass before >>>
>>>>>
>>>>> 2 USB Device(s) found
>>>>>
>>>>> It was able to read some information about the stick:
>>>>>
>>>>> => usb info
>>>>> :
>>>>> 2: Mass Storage,  USB Revision 2.0
>>>>> - Kingston DataTraveler SE9 0014857749E5ECB0173000D3
>>>>> - Class: (from Interface) Mass Storage
>>>>> - PacketSize: 64  Configurations: 1
>>>>> - Vendor: 0x0930  Product 0x6545 Version 1.0
>>>>>    Configuration: 1
>>>>>    - Interfaces: 1 Bus Powered 200mA
>>>>>      Interface: 0
>>>>>      - Alternate Setting 0, Endpoints: 2
>>>>>      - Class Mass Storage, Transp. SCSI, Bulk only
>>>>>      - Endpoint 1 In Bulk MaxPacket 512
>>>>>      - Endpoint 2 Out Bulk MaxPacket 512
>>>>>
>>>>> BUT, the stick cannot be accessed otherwise, for example:
>>>>>
>>>>> => usb part 0
>>>>> ## Unknown partition table type 0
>>>>>
>>>>>
>>>>> Is there any feature of the USB stick that would indicate
>>>>> whether or not it is "compatible" with u-boot?
>>>>
>>>> Can you do "dcache off" before you do "usb reset" and see if that fixes
>>>> the problem ?
>>>
>>> The behavior is unchanged if "dcache off" done before "usb reset".
>>
>> Try with the attached patch (and probably with dcache off)
> 
> The patch applied cleanly. The behavior is unchanged with both
> dcache on and off. The "good" sticks still work, and "bad" sticks still don't.
> 

Not sure if this helps, but with this patch and dcache off, my "bad"
stick (SanDisk Cruzer U 4C530200250418114310) is now working.

Dinh

[U-Boot] Newbie SPL question for socfpga_sockit

[Marek Vasut]

On 04/12/2016 05:53 PM, Dinh Nguyen wrote:
> 
> 
> On 04/07/2016 06:31 PM, George Broz wrote:
>> On 7 April 2016 at 13:39, Marek Vasut <marex@denx.de> wrote:
>>> On 04/07/2016 03:14 PM, George Broz wrote:
>>>> On 6 April 2016 at 19:05, Marek Vasut <marex@denx.de> wrote:
>>>>> On 04/07/2016 03:42 AM, George Broz wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>>>>> U-Boot SPL 2016.03 (Apr 05 2016 - 17:57:23)
>>>>>>>> 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
>>>>>>>>
>>>>>>>> First time that an SPL built from a recent version has run successfully
>>>>>>>> on that board.
>>>>>>>>
>>>>>>>> Will try it out on de0 tomorrow morning...
>>>>>>>
>>>>>>> This is great news, thanks!
>>>>>>
>>>>>> This patch also fixes the intermittent SDRAM calibration failures on my
>>>>>> de0_nano_soc board. Thanks so much!
>>>>>
>>>>> Great
>>>>>
>>>>>> Now with up-to-date versions of SPL and image... I have some
>>>>>> USB questions/news/observations:
>>>>>>
>>>>>> When using an OTG cable between USB port and mass storage
>>>>>> device, the de0_nano_soc board is able to detect and access some USB
>>>>>> sticks. The detection with these is almost immediate from when 'usb start'
>>>>>> is entered. If the same (working) USB stick is used with a non-OTG cable,
>>>>>> I get the timeout messages from before:
>>>>>>
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>
>>>>>> and this is true even if I add 'dr_mode = "host" '
>>>>>
>>>>> I don't think the driver supports the dr_mode property yet. Patch is
>>>>> welcome.
>>>>>
>>>>>> to the dts for usb1
>>>>>> of the de0
>>>>>> (and rebuild/reload). The older SPL/image that ships from the Terasic factory
>>>>>> detects USB sticks with a non-OTG cable, (the cable that ships with the unit).
>>>>>> What is the correct "expected" behavior here?? Is an OTG cable required or
>>>>>> not?
>>>>>
>>>>> The DWC2 driver tests the value of the OTG ID pin, so if you don't use
>>>>> OTG cable with correct ID pin setup, the host won't work.
>>>>>
>>>>>> Even with the OTG cable, some USB sticks "fail" in a not-so-great way.
>>>>>> I have a Kingston stick and the sequence goes like this:
>>>>>>
>>>>>> => usb reset
>>>>>> resetting USB...
>>>>>> USB0:   Core Release: 2.93a
>>>>>> scanning bus 0 for devices...
>>>>>>
>>>>>> <<< 1 minute, 41 seconds pass before >>>
>>>>>> ... Device NOT ready
>>>>>>    Request Sense returned 00 00 00
>>>>>>
>>>>>>  <<< then another  24 seconds pass before >>>
>>>>>>
>>>>>> 2 USB Device(s) found
>>>>>>
>>>>>> It was able to read some information about the stick:
>>>>>>
>>>>>> => usb info
>>>>>> :
>>>>>> 2: Mass Storage,  USB Revision 2.0
>>>>>> - Kingston DataTraveler SE9 0014857749E5ECB0173000D3
>>>>>> - Class: (from Interface) Mass Storage
>>>>>> - PacketSize: 64  Configurations: 1
>>>>>> - Vendor: 0x0930  Product 0x6545 Version 1.0
>>>>>>    Configuration: 1
>>>>>>    - Interfaces: 1 Bus Powered 200mA
>>>>>>      Interface: 0
>>>>>>      - Alternate Setting 0, Endpoints: 2
>>>>>>      - Class Mass Storage, Transp. SCSI, Bulk only
>>>>>>      - Endpoint 1 In Bulk MaxPacket 512
>>>>>>      - Endpoint 2 Out Bulk MaxPacket 512
>>>>>>
>>>>>> BUT, the stick cannot be accessed otherwise, for example:
>>>>>>
>>>>>> => usb part 0
>>>>>> ## Unknown partition table type 0
>>>>>>
>>>>>>
>>>>>> Is there any feature of the USB stick that would indicate
>>>>>> whether or not it is "compatible" with u-boot?
>>>>>
>>>>> Can you do "dcache off" before you do "usb reset" and see if that fixes
>>>>> the problem ?
>>>>
>>>> The behavior is unchanged if "dcache off" done before "usb reset".
>>>
>>> Try with the attached patch (and probably with dcache off)
>>
>> The patch applied cleanly. The behavior is unchanged with both
>> dcache on and off. The "good" sticks still work, and "bad" sticks still don't.
>>
> 
> Not sure if this helps, but with this patch and dcache off, my "bad"
> stick (SanDisk Cruzer U 4C530200250418114310) is now working.

You mean the revert is needed on SoCFPGA, right ? I tried bashing Stefan
about the patch a bit and I am tempted to just revert it for now, since
there seems to be no time to repair it proper :(


-- 
Best regards,
Marek Vasut

[U-Boot] Newbie SPL question for socfpga_sockit

[Dinh Nguyen]

On 04/12/2016 11:00 AM, Marek Vasut wrote:
> On 04/12/2016 05:53 PM, Dinh Nguyen wrote:
>>
>>
>> On 04/07/2016 06:31 PM, George Broz wrote:
>>> On 7 April 2016 at 13:39, Marek Vasut <marex@denx.de> wrote:
>>>> On 04/07/2016 03:14 PM, George Broz wrote:
>>>>> On 6 April 2016 at 19:05, Marek Vasut <marex@denx.de> wrote:
>>>>>> On 04/07/2016 03:42 AM, George Broz wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>>>> U-Boot SPL 2016.03 (Apr 05 2016 - 17:57:23)
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>> First time that an SPL built from a recent version has run successfully
>>>>>>>>> on that board.
>>>>>>>>>
>>>>>>>>> Will try it out on de0 tomorrow morning...
>>>>>>>>
>>>>>>>> This is great news, thanks!
>>>>>>>
>>>>>>> This patch also fixes the intermittent SDRAM calibration failures on my
>>>>>>> de0_nano_soc board. Thanks so much!
>>>>>>
>>>>>> Great
>>>>>>
>>>>>>> Now with up-to-date versions of SPL and image... I have some
>>>>>>> USB questions/news/observations:
>>>>>>>
>>>>>>> When using an OTG cable between USB port and mass storage
>>>>>>> device, the de0_nano_soc board is able to detect and access some USB
>>>>>>> sticks. The detection with these is almost immediate from when 'usb start'
>>>>>>> is entered. If the same (working) USB stick is used with a non-OTG cable,
>>>>>>> I get the timeout messages from before:
>>>>>>>
>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>>
>>>>>>> and this is true even if I add 'dr_mode = "host" '
>>>>>>
>>>>>> I don't think the driver supports the dr_mode property yet. Patch is
>>>>>> welcome.
>>>>>>
>>>>>>> to the dts for usb1
>>>>>>> of the de0
>>>>>>> (and rebuild/reload). The older SPL/image that ships from the Terasic factory
>>>>>>> detects USB sticks with a non-OTG cable, (the cable that ships with the unit).
>>>>>>> What is the correct "expected" behavior here?? Is an OTG cable required or
>>>>>>> not?
>>>>>>
>>>>>> The DWC2 driver tests the value of the OTG ID pin, so if you don't use
>>>>>> OTG cable with correct ID pin setup, the host won't work.
>>>>>>
>>>>>>> Even with the OTG cable, some USB sticks "fail" in a not-so-great way.
>>>>>>> I have a Kingston stick and the sequence goes like this:
>>>>>>>
>>>>>>> => usb reset
>>>>>>> resetting USB...
>>>>>>> USB0:   Core Release: 2.93a
>>>>>>> scanning bus 0 for devices...
>>>>>>>
>>>>>>> <<< 1 minute, 41 seconds pass before >>>
>>>>>>> ... Device NOT ready
>>>>>>>    Request Sense returned 00 00 00
>>>>>>>
>>>>>>>  <<< then another  24 seconds pass before >>>
>>>>>>>
>>>>>>> 2 USB Device(s) found
>>>>>>>
>>>>>>> It was able to read some information about the stick:
>>>>>>>
>>>>>>> => usb info
>>>>>>> :
>>>>>>> 2: Mass Storage,  USB Revision 2.0
>>>>>>> - Kingston DataTraveler SE9 0014857749E5ECB0173000D3
>>>>>>> - Class: (from Interface) Mass Storage
>>>>>>> - PacketSize: 64  Configurations: 1
>>>>>>> - Vendor: 0x0930  Product 0x6545 Version 1.0
>>>>>>>    Configuration: 1
>>>>>>>    - Interfaces: 1 Bus Powered 200mA
>>>>>>>      Interface: 0
>>>>>>>      - Alternate Setting 0, Endpoints: 2
>>>>>>>      - Class Mass Storage, Transp. SCSI, Bulk only
>>>>>>>      - Endpoint 1 In Bulk MaxPacket 512
>>>>>>>      - Endpoint 2 Out Bulk MaxPacket 512
>>>>>>>
>>>>>>> BUT, the stick cannot be accessed otherwise, for example:
>>>>>>>
>>>>>>> => usb part 0
>>>>>>> ## Unknown partition table type 0
>>>>>>>
>>>>>>>
>>>>>>> Is there any feature of the USB stick that would indicate
>>>>>>> whether or not it is "compatible" with u-boot?
>>>>>>
>>>>>> Can you do "dcache off" before you do "usb reset" and see if thusb at fixes
>>>>>> the problem ?
>>>>>
>>>>> The behavior is unchanged if "dcache off" done before "usb reset".
>>>>
>>>> Try with the attached patch (and probably with dcache off)
>>>
>>> The patch applied cleanly. The behavior is unchanged with both
>>> dcache on and off. The "good" sticks still work, and "bad" sticks still don't.
>>>
>>
>> Not sure if this helps, but with this patch and dcache off, my "bad"
>> stick (SanDisk Cruzer U 4C530200250418114310) is now working.
> 
> You mean the revert is needed on SoCFPGA, right ? I tried bashing Stefan
> about the patch a bit and I am tempted to just revert it for now, since
> there seems to be no time to repair it proper :(
> 

Yes, I applied your attached patch as is, not realizing it was a revert
of 'c998da0d "usb: Change power-on / scanning timeout handling"'.

I also tested with a revert as well.

Dinh

[U-Boot] Newbie SPL question for socfpga_sockit

[Stefan Roese]

On 12.04.2016 18:00, Marek Vasut wrote:
> On 04/12/2016 05:53 PM, Dinh Nguyen wrote:
>>
>>
>> On 04/07/2016 06:31 PM, George Broz wrote:
>>> On 7 April 2016 at 13:39, Marek Vasut <marex@denx.de> wrote:
>>>> On 04/07/2016 03:14 PM, George Broz wrote:
>>>>> On 6 April 2016 at 19:05, Marek Vasut <marex@denx.de> wrote:
>>>>>> On 04/07/2016 03:42 AM, George Broz wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>>>> U-Boot SPL 2016.03 (Apr 05 2016 - 17:57:23)
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>> First time that an SPL built from a recent version has run successfully
>>>>>>>>> on that board.
>>>>>>>>>
>>>>>>>>> Will try it out on de0 tomorrow morning...
>>>>>>>>
>>>>>>>> This is great news, thanks!
>>>>>>>
>>>>>>> This patch also fixes the intermittent SDRAM calibration failures on my
>>>>>>> de0_nano_soc board. Thanks so much!
>>>>>>
>>>>>> Great
>>>>>>
>>>>>>> Now with up-to-date versions of SPL and image... I have some
>>>>>>> USB questions/news/observations:
>>>>>>>
>>>>>>> When using an OTG cable between USB port and mass storage
>>>>>>> device, the de0_nano_soc board is able to detect and access some USB
>>>>>>> sticks. The detection with these is almost immediate from when 'usb start'
>>>>>>> is entered. If the same (working) USB stick is used with a non-OTG cable,
>>>>>>> I get the timeout messages from before:
>>>>>>>
>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>>
>>>>>>> and this is true even if I add 'dr_mode = "host" '
>>>>>>
>>>>>> I don't think the driver supports the dr_mode property yet. Patch is
>>>>>> welcome.
>>>>>>
>>>>>>> to the dts for usb1
>>>>>>> of the de0
>>>>>>> (and rebuild/reload). The older SPL/image that ships from the Terasic factory
>>>>>>> detects USB sticks with a non-OTG cable, (the cable that ships with the unit).
>>>>>>> What is the correct "expected" behavior here?? Is an OTG cable required or
>>>>>>> not?
>>>>>>
>>>>>> The DWC2 driver tests the value of the OTG ID pin, so if you don't use
>>>>>> OTG cable with correct ID pin setup, the host won't work.
>>>>>>
>>>>>>> Even with the OTG cable, some USB sticks "fail" in a not-so-great way.
>>>>>>> I have a Kingston stick and the sequence goes like this:
>>>>>>>
>>>>>>> => usb reset
>>>>>>> resetting USB...
>>>>>>> USB0:   Core Release: 2.93a
>>>>>>> scanning bus 0 for devices...
>>>>>>>
>>>>>>> <<< 1 minute, 41 seconds pass before >>>
>>>>>>> ... Device NOT ready
>>>>>>>     Request Sense returned 00 00 00
>>>>>>>
>>>>>>>   <<< then another  24 seconds pass before >>>
>>>>>>>
>>>>>>> 2 USB Device(s) found
>>>>>>>
>>>>>>> It was able to read some information about the stick:
>>>>>>>
>>>>>>> => usb info
>>>>>>> :
>>>>>>> 2: Mass Storage,  USB Revision 2.0
>>>>>>> - Kingston DataTraveler SE9 0014857749E5ECB0173000D3
>>>>>>> - Class: (from Interface) Mass Storage
>>>>>>> - PacketSize: 64  Configurations: 1
>>>>>>> - Vendor: 0x0930  Product 0x6545 Version 1.0
>>>>>>>     Configuration: 1
>>>>>>>     - Interfaces: 1 Bus Powered 200mA
>>>>>>>       Interface: 0
>>>>>>>       - Alternate Setting 0, Endpoints: 2
>>>>>>>       - Class Mass Storage, Transp. SCSI, Bulk only
>>>>>>>       - Endpoint 1 In Bulk MaxPacket 512
>>>>>>>       - Endpoint 2 Out Bulk MaxPacket 512
>>>>>>>
>>>>>>> BUT, the stick cannot be accessed otherwise, for example:
>>>>>>>
>>>>>>> => usb part 0
>>>>>>> ## Unknown partition table type 0
>>>>>>>
>>>>>>>
>>>>>>> Is there any feature of the USB stick that would indicate
>>>>>>> whether or not it is "compatible" with u-boot?
>>>>>>
>>>>>> Can you do "dcache off" before you do "usb reset" and see if that fixes
>>>>>> the problem ?
>>>>>
>>>>> The behavior is unchanged if "dcache off" done before "usb reset".
>>>>
>>>> Try with the attached patch (and probably with dcache off)
>>>
>>> The patch applied cleanly. The behavior is unchanged with both
>>> dcache on and off. The "good" sticks still work, and "bad" sticks still don't.
>>>
>>
>> Not sure if this helps, but with this patch and dcache off, my "bad"
>> stick (SanDisk Cruzer U 4C530200250418114310) is now working.
>
> You mean the revert is needed on SoCFPGA, right ? I tried bashing Stefan
> about the patch a bit and I am tempted to just revert it for now, since
> there seems to be no time to repair it proper :(

Hmmmm. My priorities seem to have shifted a bit just now. ;)

I'll definitely try to fix this issue on SoCFPGA with the USB
scanning patches in this release. As we don't want to go back
to USB scanning times in the range of more than 20 seconds!
Please give me something like 1 week for this.

Marek, how can I reproduce this issue? Can I use the SoCrates
board for this? Could you perhaps double-check this on this
board? Which USB sticks are known to fail?

Thanks,
Stefan

[U-Boot] Newbie SPL question for socfpga_sockit

[Marek Vasut]

On 04/12/2016 06:08 PM, Dinh Nguyen wrote:
> 
> 
> On 04/12/2016 11:00 AM, Marek Vasut wrote:
>> On 04/12/2016 05:53 PM, Dinh Nguyen wrote:
>>>
>>>
>>> On 04/07/2016 06:31 PM, George Broz wrote:
>>>> On 7 April 2016 at 13:39, Marek Vasut <marex@denx.de> wrote:
>>>>> On 04/07/2016 03:14 PM, George Broz wrote:
>>>>>> On 6 April 2016 at 19:05, Marek Vasut <marex@denx.de> wrote:
>>>>>>> On 04/07/2016 03:42 AM, George Broz wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>>>>> U-Boot SPL 2016.03 (Apr 05 2016 - 17:57:23)
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>> First time that an SPL built from a recent version has run successfully
>>>>>>>>>> on that board.
>>>>>>>>>>
>>>>>>>>>> Will try it out on de0 tomorrow morning...
>>>>>>>>>
>>>>>>>>> This is great news, thanks!
>>>>>>>>
>>>>>>>> This patch also fixes the intermittent SDRAM calibration failures on my
>>>>>>>> de0_nano_soc board. Thanks so much!
>>>>>>>
>>>>>>> Great
>>>>>>>
>>>>>>>> Now with up-to-date versions of SPL and image... I have some
>>>>>>>> USB questions/news/observations:
>>>>>>>>
>>>>>>>> When using an OTG cable between USB port and mass storage
>>>>>>>> device, the de0_nano_soc board is able to detect and access some USB
>>>>>>>> sticks. The detection with these is almost immediate from when 'usb start'
>>>>>>>> is entered. If the same (working) USB stick is used with a non-OTG cable,
>>>>>>>> I get the timeout messages from before:
>>>>>>>>
>>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>>>
>>>>>>>> and this is true even if I add 'dr_mode = "host" '
>>>>>>>
>>>>>>> I don't think the driver supports the dr_mode property yet. Patch is
>>>>>>> welcome.
>>>>>>>
>>>>>>>> to the dts for usb1
>>>>>>>> of the de0
>>>>>>>> (and rebuild/reload). The older SPL/image that ships from the Terasic factory
>>>>>>>> detects USB sticks with a non-OTG cable, (the cable that ships with the unit).
>>>>>>>> What is the correct "expected" behavior here?? Is an OTG cable required or
>>>>>>>> not?
>>>>>>>
>>>>>>> The DWC2 driver tests the value of the OTG ID pin, so if you don't use
>>>>>>> OTG cable with correct ID pin setup, the host won't work.
>>>>>>>
>>>>>>>> Even with the OTG cable, some USB sticks "fail" in a not-so-great way.
>>>>>>>> I have a Kingston stick and the sequence goes like this:
>>>>>>>>
>>>>>>>> => usb reset
>>>>>>>> resetting USB...
>>>>>>>> USB0:   Core Release: 2.93a
>>>>>>>> scanning bus 0 for devices...
>>>>>>>>
>>>>>>>> <<< 1 minute, 41 seconds pass before >>>
>>>>>>>> ... Device NOT ready
>>>>>>>>    Request Sense returned 00 00 00
>>>>>>>>
>>>>>>>>  <<< then another  24 seconds pass before >>>
>>>>>>>>
>>>>>>>> 2 USB Device(s) found
>>>>>>>>
>>>>>>>> It was able to read some information about the stick:
>>>>>>>>
>>>>>>>> => usb info
>>>>>>>> :
>>>>>>>> 2: Mass Storage,  USB Revision 2.0
>>>>>>>> - Kingston DataTraveler SE9 0014857749E5ECB0173000D3
>>>>>>>> - Class: (from Interface) Mass Storage
>>>>>>>> - PacketSize: 64  Configurations: 1
>>>>>>>> - Vendor: 0x0930  Product 0x6545 Version 1.0
>>>>>>>>    Configuration: 1
>>>>>>>>    - Interfaces: 1 Bus Powered 200mA
>>>>>>>>      Interface: 0
>>>>>>>>      - Alternate Setting 0, Endpoints: 2
>>>>>>>>      - Class Mass Storage, Transp. SCSI, Bulk only
>>>>>>>>      - Endpoint 1 In Bulk MaxPacket 512
>>>>>>>>      - Endpoint 2 Out Bulk MaxPacket 512
>>>>>>>>
>>>>>>>> BUT, the stick cannot be accessed otherwise, for example:
>>>>>>>>
>>>>>>>> => usb part 0
>>>>>>>> ## Unknown partition table type 0
>>>>>>>>
>>>>>>>>
>>>>>>>> Is there any feature of the USB stick that would indicate
>>>>>>>> whether or not it is "compatible" with u-boot?
>>>>>>>
>>>>>>> Can you do "dcache off" before you do "usb reset" and see if thusb at fixes
>>>>>>> the problem ?
>>>>>>
>>>>>> The behavior is unchanged if "dcache off" done before "usb reset".
>>>>>
>>>>> Try with the attached patch (and probably with dcache off)
>>>>
>>>> The patch applied cleanly. The behavior is unchanged with both
>>>> dcache on and off. The "good" sticks still work, and "bad" sticks still don't.
>>>>
>>>
>>> Not sure if this helps, but with this patch and dcache off, my "bad"
>>> stick (SanDisk Cruzer U 4C530200250418114310) is now working.
>>
>> You mean the revert is needed on SoCFPGA, right ? I tried bashing Stefan
>> about the patch a bit and I am tempted to just revert it for now, since
>> there seems to be no time to repair it proper :(
>>
> 
> Yes, I applied your attached patch as is, not realizing it was a revert
> of 'c998da0d "usb: Change power-on / scanning timeout handling"'.
> 
> I also tested with a revert as well.

Grumble ... I will either look into the patch or revert it. I am not
sure yet. Still, the dcache issue is not gone even with the DDR patches.

-- 
Best regards,
Marek Vasut

[U-Boot] Newbie SPL question for socfpga_sockit

[Chin Liang See]

On Tue, 2016-04-12 at 18:11 +0200, Marek Vasut wrote:
> On 04/12/2016 06:08 PM, Dinh Nguyen wrote:
> > 
> > 
> > On 04/12/2016 11:00 AM, Marek Vasut wrote:
> > > On 04/12/2016 05:53 PM, Dinh Nguyen wrote:
> > > > 
> > > > 
> > > > On 04/07/2016 06:31 PM, George Broz wrote:
> > > > > On 7 April 2016 at 13:39, Marek Vasut <marex@denx.de> wrote:
> > > > > > On 04/07/2016 03:14 PM, George Broz wrote:
> > > > > > > On 6 April 2016 at 19:05, Marek Vasut <marex@denx.de>
> > > > > > > wrote:
> > > > > > > > On 04/07/2016 03:42 AM, George Broz wrote:
> > > > > > > > 
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > > > > U-Boot SPL 2016.03 (Apr 05 2016 - 17:57:23)
> > > > > > > > > > > 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
> > > > > > > > > > > 
> > > > > > > > > > > First time that an SPL built from a recent
> > > > > > > > > > > version has run successfully
> > > > > > > > > > > on that board.
> > > > > > > > > > > 
> > > > > > > > > > > Will try it out on de0 tomorrow morning...
> > > > > > > > > > 
> > > > > > > > > > This is great news, thanks!
> > > > > > > > > 
> > > > > > > > > This patch also fixes the intermittent SDRAM
> > > > > > > > > calibration failures on my
> > > > > > > > > de0_nano_soc board. Thanks so much!
> > > > > > > > 
> > > > > > > > Great
> > > > > > > > 
> > > > > > > > > Now with up-to-date versions of SPL and image... I
> > > > > > > > > have some
> > > > > > > > > USB questions/news/observations:
> > > > > > > > > 
> > > > > > > > > When using an OTG cable between USB port and mass
> > > > > > > > > storage
> > > > > > > > > device, the de0_nano_soc board is able to detect and
> > > > > > > > > access some USB
> > > > > > > > > sticks. The detection with these is almost immediate
> > > > > > > > > from when 'usb start'
> > > > > > > > > is entered. If the same (working) USB stick is used
> > > > > > > > > with a non-OTG cable,
> > > > > > > > > I get the timeout messages from before:
> > > > > > > > > 
> > > > > > > > > dwc_otg_core_host_init: Timeout!
> > > > > > > > > dwc_otg_core_host_init: Timeout!
> > > > > > > > > 
> > > > > > > > > and this is true even if I add 'dr_mode = "host" '
> > > > > > > > 
> > > > > > > > I don't think the driver supports the dr_mode property
> > > > > > > > yet. Patch is
> > > > > > > > welcome.
> > > > > > > > 
> > > > > > > > > to the dts for usb1
> > > > > > > > > of the de0
> > > > > > > > > (and rebuild/reload). The older SPL/image that ships
> > > > > > > > > from the Terasic factory
> > > > > > > > > detects USB sticks with a non-OTG cable, (the cable
> > > > > > > > > that ships with the unit).
> > > > > > > > > What is the correct "expected" behavior here?? Is an
> > > > > > > > > OTG cable required or
> > > > > > > > > not?
> > > > > > > > 
> > > > > > > > The DWC2 driver tests the value of the OTG ID pin, so
> > > > > > > > if you don't use
> > > > > > > > OTG cable with correct ID pin setup, the host won't
> > > > > > > > work.
> > > > > > > > 
> > > > > > > > > Even with the OTG cable, some USB sticks "fail" in a
> > > > > > > > > not-so-great way.
> > > > > > > > > I have a Kingston stick and the sequence goes like
> > > > > > > > > this:
> > > > > > > > > 
> > > > > > > > > => usb reset
> > > > > > > > > resetting USB...
> > > > > > > > > USB0:   Core Release: 2.93a
> > > > > > > > > scanning bus 0 for devices...
> > > > > > > > > 
> > > > > > > > > <<< 1 minute, 41 seconds pass before >>>
> > > > > > > > > ... Device NOT ready
> > > > > > > > >    Request Sense returned 00 00 00
> > > > > > > > > 
> > > > > > > > >  <<< then another  24 seconds pass before >>>
> > > > > > > > > 
> > > > > > > > > 2 USB Device(s) found
> > > > > > > > > 
> > > > > > > > > It was able to read some information about the stick:
> > > > > > > > > 
> > > > > > > > > => usb info
> > > > > > > > > :
> > > > > > > > > 2: Mass Storage,  USB Revision 2.0
> > > > > > > > > - Kingston DataTraveler SE9 0014857749E5ECB0173000D3
> > > > > > > > > - Class: (from Interface) Mass Storage
> > > > > > > > > - PacketSize: 64  Configurations: 1
> > > > > > > > > - Vendor: 0x0930  Product 0x6545 Version 1.0
> > > > > > > > >    Configuration: 1
> > > > > > > > >    - Interfaces: 1 Bus Powered 200mA
> > > > > > > > >      Interface: 0
> > > > > > > > >      - Alternate Setting 0, Endpoints: 2
> > > > > > > > >      - Class Mass Storage, Transp. SCSI, Bulk only
> > > > > > > > >      - Endpoint 1 In Bulk MaxPacket 512
> > > > > > > > >      - Endpoint 2 Out Bulk MaxPacket 512
> > > > > > > > > 
> > > > > > > > > BUT, the stick cannot be accessed otherwise, for
> > > > > > > > > example:
> > > > > > > > > 
> > > > > > > > > => usb part 0
> > > > > > > > > ## Unknown partition table type 0
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Is there any feature of the USB stick that would
> > > > > > > > > indicate
> > > > > > > > > whether or not it is "compatible" with u-boot?
> > > > > > > > 
> > > > > > > > Can you do "dcache off" before you do "usb reset" and
> > > > > > > > see if thusb at fixes
> > > > > > > > the problem ?
> > > > > > > 
> > > > > > > The behavior is unchanged if "dcache off" done before
> > > > > > > "usb reset".
> > > > > > 
> > > > > > Try with the attached patch (and probably with dcache off)
> > > > > 
> > > > > The patch applied cleanly. The behavior is unchanged with
> > > > > both
> > > > > dcache on and off. The "good" sticks still work, and "bad"
> > > > > sticks still don't.
> > > > > 
> > > > 
> > > > Not sure if this helps, but with this patch and dcache off, my
> > > > "bad"
> > > > stick (SanDisk Cruzer U 4C530200250418114310) is now working.
> > > 
> > > You mean the revert is needed on SoCFPGA, right ? I tried bashing
> > > Stefan
> > > about the patch a bit and I am tempted to just revert it for now,
> > > since
> > > there seems to be no time to repair it proper :(
> > > 
> > 
> > Yes, I applied your attached patch as is, not realizing it was a
> > revert
> > of 'c998da0d "usb: Change power-on / scanning timeout handling"'.
> > 
> > I also tested with a revert as well.
> 
> Grumble ... I will either look into the patch or revert it. I am not
> sure yet. Still, the dcache issue is not gone even with the DDR
> patches.
> 

Yup, same to my case. The DDR works as can boot to Linux at CV socdk
but still same issue with USB. I am still suspecting the issue between
the cache and DDR area. 

With that, I tried to patch both L1 and L2 cache auxiliary register but
doesn't help. Attaching the change here and hope can spark some
thoughts.



diff --git a/arch/arm/include/asm/pl310.h
b/arch/arm/include/asm/pl310.h
index d588f94..8c1d217 100644
--- a/arch/arm/include/asm/pl310.h
+++ b/arch/arm/include/asm/pl310.h
@@ -17,8 +17,11 @@
#define L2X0_CTRL_EN                           1
 
#define L310_SHARED_ATT_OVERRIDE_ENABLE                (1 << 22)
+#define L310_AUX_CTRL_FULL_LINE_ZERO_MASK      (1 << 0)
+#define L310_AUX_CTRL_NS_LOCKDOWN_MASK         (1 << 26)
#define L310_AUX_CTRL_DATA_PREFETCH_MASK       (1 << 28)
#define L310_AUX_CTRL_INST_PREFETCH_MASK       (1 << 29)
+#define L310_AUX_CTRL_EARLY_BRESP_MASK         (1 << 30)
 
struct pl310_regs {
        u32 pl310_cache_id;
diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach
-socfpga/misc.c
index dd05e14..f67ab0b 100644
--- a/arch/arm/mach-socfpga/misc.c
+++ b/arch/arm/mach-socfpga/misc.c
@@ -53,6 +53,13 @@ void enable_caches(void)
 
void v7_outer_cache_enable(void)
{
+       u32 acr;
+
+       /* Read ACR */
+       asm volatile ("mrc p15, 0, %0, c1, c0, 1" : "=r" (acr));
+       acr |= (0x7 << 1);
+       v7_arch_cp15_set_acr(acr, 0, 0, 0, 0);
+
        /* Disable the L2 cache */
        clrbits_le32(&pl310->pl310_ctrl, L2X0_CTRL_EN);
 
@@ -60,6 +67,9 @@ void v7_outer_cache_enable(void)
        setbits_le32(&pl310->pl310_aux_ctrl,
                     L310_AUX_CTRL_DATA_PREFETCH_MASK |
                     L310_AUX_CTRL_INST_PREFETCH_MASK |
+                    L310_AUX_CTRL_EARLY_BRESP_MASK |
+                    L310_AUX_CTRL_NS_LOCKDOWN_MASK |
+                    L310_AUX_CTRL_FULL_LINE_ZERO_MASK |
                     L310_SHARED_ATT_OVERRIDE_ENABLE);
 
        /* Enable the L2 cache */

[U-Boot] Newbie SPL question for socfpga_sockit

[Marek Vasut]

On 04/12/2016 06:09 PM, Stefan Roese wrote:
> On 12.04.2016 18:00, Marek Vasut wrote:
>> On 04/12/2016 05:53 PM, Dinh Nguyen wrote:
>>>
>>>
>>> On 04/07/2016 06:31 PM, George Broz wrote:
>>>> On 7 April 2016 at 13:39, Marek Vasut <marex@denx.de> wrote:
>>>>> On 04/07/2016 03:14 PM, George Broz wrote:
>>>>>> On 6 April 2016 at 19:05, Marek Vasut <marex@denx.de> wrote:
>>>>>>> On 04/07/2016 03:42 AM, George Broz wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>>>>> U-Boot SPL 2016.03 (Apr 05 2016 - 17:57:23)
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>> First time that an SPL built from a recent version has run
>>>>>>>>>> successfully
>>>>>>>>>> on that board.
>>>>>>>>>>
>>>>>>>>>> Will try it out on de0 tomorrow morning...
>>>>>>>>>
>>>>>>>>> This is great news, thanks!
>>>>>>>>
>>>>>>>> This patch also fixes the intermittent SDRAM calibration
>>>>>>>> failures on my
>>>>>>>> de0_nano_soc board. Thanks so much!
>>>>>>>
>>>>>>> Great
>>>>>>>
>>>>>>>> Now with up-to-date versions of SPL and image... I have some
>>>>>>>> USB questions/news/observations:
>>>>>>>>
>>>>>>>> When using an OTG cable between USB port and mass storage
>>>>>>>> device, the de0_nano_soc board is able to detect and access some
>>>>>>>> USB
>>>>>>>> sticks. The detection with these is almost immediate from when
>>>>>>>> 'usb start'
>>>>>>>> is entered. If the same (working) USB stick is used with a
>>>>>>>> non-OTG cable,
>>>>>>>> I get the timeout messages from before:
>>>>>>>>
>>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>>> dwc_otg_core_host_init: Timeout!
>>>>>>>>
>>>>>>>> and this is true even if I add 'dr_mode = "host" '
>>>>>>>
>>>>>>> I don't think the driver supports the dr_mode property yet. Patch is
>>>>>>> welcome.
>>>>>>>
>>>>>>>> to the dts for usb1
>>>>>>>> of the de0
>>>>>>>> (and rebuild/reload). The older SPL/image that ships from the
>>>>>>>> Terasic factory
>>>>>>>> detects USB sticks with a non-OTG cable, (the cable that ships
>>>>>>>> with the unit).
>>>>>>>> What is the correct "expected" behavior here?? Is an OTG cable
>>>>>>>> required or
>>>>>>>> not?
>>>>>>>
>>>>>>> The DWC2 driver tests the value of the OTG ID pin, so if you
>>>>>>> don't use
>>>>>>> OTG cable with correct ID pin setup, the host won't work.
>>>>>>>
>>>>>>>> Even with the OTG cable, some USB sticks "fail" in a
>>>>>>>> not-so-great way.
>>>>>>>> I have a Kingston stick and the sequence goes like this:
>>>>>>>>
>>>>>>>> => usb reset
>>>>>>>> resetting USB...
>>>>>>>> USB0:   Core Release: 2.93a
>>>>>>>> scanning bus 0 for devices...
>>>>>>>>
>>>>>>>> <<< 1 minute, 41 seconds pass before >>>
>>>>>>>> ... Device NOT ready
>>>>>>>>     Request Sense returned 00 00 00
>>>>>>>>
>>>>>>>>   <<< then another  24 seconds pass before >>>
>>>>>>>>
>>>>>>>> 2 USB Device(s) found
>>>>>>>>
>>>>>>>> It was able to read some information about the stick:
>>>>>>>>
>>>>>>>> => usb info
>>>>>>>> :
>>>>>>>> 2: Mass Storage,  USB Revision 2.0
>>>>>>>> - Kingston DataTraveler SE9 0014857749E5ECB0173000D3
>>>>>>>> - Class: (from Interface) Mass Storage
>>>>>>>> - PacketSize: 64  Configurations: 1
>>>>>>>> - Vendor: 0x0930  Product 0x6545 Version 1.0
>>>>>>>>     Configuration: 1
>>>>>>>>     - Interfaces: 1 Bus Powered 200mA
>>>>>>>>       Interface: 0
>>>>>>>>       - Alternate Setting 0, Endpoints: 2
>>>>>>>>       - Class Mass Storage, Transp. SCSI, Bulk only
>>>>>>>>       - Endpoint 1 In Bulk MaxPacket 512
>>>>>>>>       - Endpoint 2 Out Bulk MaxPacket 512
>>>>>>>>
>>>>>>>> BUT, the stick cannot be accessed otherwise, for example:
>>>>>>>>
>>>>>>>> => usb part 0
>>>>>>>> ## Unknown partition table type 0
>>>>>>>>
>>>>>>>>
>>>>>>>> Is there any feature of the USB stick that would indicate
>>>>>>>> whether or not it is "compatible" with u-boot?
>>>>>>>
>>>>>>> Can you do "dcache off" before you do "usb reset" and see if that
>>>>>>> fixes
>>>>>>> the problem ?
>>>>>>
>>>>>> The behavior is unchanged if "dcache off" done before "usb reset".
>>>>>
>>>>> Try with the attached patch (and probably with dcache off)
>>>>
>>>> The patch applied cleanly. The behavior is unchanged with both
>>>> dcache on and off. The "good" sticks still work, and "bad" sticks
>>>> still don't.
>>>>
>>>
>>> Not sure if this helps, but with this patch and dcache off, my "bad"
>>> stick (SanDisk Cruzer U 4C530200250418114310) is now working.
>>
>> You mean the revert is needed on SoCFPGA, right ? I tried bashing Stefan
>> about the patch a bit and I am tempted to just revert it for now, since
>> there seems to be no time to repair it proper :(
> 
> Hmmmm. My priorities seem to have shifted a bit just now. ;)
> 
> I'll definitely try to fix this issue on SoCFPGA with the USB
> scanning patches in this release. As we don't want to go back
> to USB scanning times in the range of more than 20 seconds!
> Please give me something like 1 week for this.

OK, thanks!

> Marek, how can I reproduce this issue? Can I use the SoCrates
> board for this?

I think you can, but I just pulled out SoCrates from the drawer and it
doesn't enable port power when I start the USB. On the other hand, my
SoCrates is a bit abnormal, so it might be the board in this case.

> Could you perhaps double-check this on this
> board? Which USB sticks are known to fail?

Any stick fails for me :)

> Thanks,
> Stefan
> 


-- 
Best regards,
Marek Vasut