Re: [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  wrote:
> On 04/07/2016 03:14 PM, George Broz wrote:
>> On 6 April 2016 at 19:05, Marek Vasut  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 :(
> 
> H. 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 

Re: [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  wrote:
> > > > > > On 04/07/2016 03:14 PM, George Broz wrote:
> > > > > > > On 6 April 2016 at 19:05, Marek Vasut 
> > > > > > > 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 

Re: [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  wrote:
> On 04/07/2016 03:14 PM, George Broz wrote:
>> On 6 April 2016 at 19:05, Marek Vasut  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. 

Re: [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  wrote:

On 04/07/2016 03:14 PM, George Broz wrote:

On 6 April 2016 at 19:05, Marek Vasut  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 :(


H. 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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [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  wrote:
 On 04/07/2016 03:14 PM, George Broz wrote:
> On 6 April 2016 at 19:05, Marek Vasut  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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [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  wrote:
>>> On 04/07/2016 03:14 PM, George Broz wrote:
 On 6 April 2016 at 19:05, Marek Vasut  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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [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  wrote:
>> On 04/07/2016 03:14 PM, George Broz wrote:
>>> On 6 April 2016 at 19:05, Marek Vasut  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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [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  wrote:
>> On 04/09/2016 12:40 AM, George Broz wrote:
>>> On 8 April 2016 at 05:36, Marek Vasut  wrote:
 On 04/08/2016 07:16 AM, Stefan Roese wrote:
> On 08.04.2016 01:51, George Broz wrote:
>
> 
>
> 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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 10 April 2016 at 10:47, Marek Vasut  wrote:
> On 04/09/2016 12:40 AM, George Broz wrote:
>> On 8 April 2016 at 05:36, Marek Vasut  wrote:
>>> On 04/08/2016 07:16 AM, Stefan Roese wrote:
 On 08.04.2016 01:51, George Broz wrote:

 

 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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [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  wrote:
>> On 04/08/2016 07:16 AM, Stefan Roese wrote:
>>> On 08.04.2016 01:51, George Broz wrote:
>>>
>>> 
>>>
>>> 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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 8 April 2016 at 05:36, Marek Vasut  wrote:
> On 04/08/2016 07:16 AM, Stefan Roese wrote:
>> On 08.04.2016 01:51, George Broz wrote:
>>
>> 
>>
>> 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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

Re: [U-Boot] Newbie SPL question for socfpga_sockit

[Stefan Roese]

On 08.04.2016 01:51, George Broz wrote:



 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:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x0930 Toshiba Corp.
  idProduct  0x6545 Kingston DataTraveler 102/2.0 / HEMA Flash Drive 2 
GB / PNY Attache 4GB Stick
  bcdDevice1.10
  iManufacturer   1 
  iProduct2 
  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
  bInterfaceNumber0
  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
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  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:
>bLength18
>bDescriptorType 1
>bcdUSB   2.00
>bDeviceClass0 (Defined at Interface level)
>bDeviceSubClass 0
>bDeviceProtocol 0
>bMaxPacketSize064
>idVendor   0x0930 Toshiba Corp.
>idProduct  0x6545 Kingston DataTraveler 102 Flash Drive /
> HEMA Flash Drive 2 GB / PNY Attache 4GB Stick
>bcdDevice1.00
>iManufacturer   1 Kingston
>iProduct2 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
>bInterfaceNumber0
>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
>  bmAttributes2
>Transfer TypeBulk
>Synch Type   None
>Usage Type   Data
>  wMaxPacketSize 0x0200  1x 512 bytes

Re: [U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 7 April 2016 at 16:36, Marek Vasut  wrote:
> On 04/08/2016 01:31 AM, George Broz wrote:
>> On 7 April 2016 at 13:39, Marek Vasut  wrote:
>>> On 04/07/2016 03:14 PM, George Broz wrote:
 On 6 April 2016 at 19:05, Marek Vasut  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:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize064
  idVendor   0x0930 Toshiba 

Re: [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  wrote:
>> On 04/07/2016 03:14 PM, George Broz wrote:
>>> On 6 April 2016 at 19:05, Marek Vasut  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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 7 April 2016 at 13:39, Marek Vasut  wrote:
> On 04/07/2016 03:14 PM, George Broz wrote:
>> On 6 April 2016 at 19:05, Marek Vasut  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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [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  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
>From 1d9326d5db29f2dca8639e8929eac780e1bd29a3 Mon Sep 17 00:00:00 2001
From: Marek Vasut 
Date: Sat, 2 Apr 2016 00:20:37 +0200
Subject: [PATCH] Revert "usb: Change power-on / scanning timeout handling"

This reverts commit c998da0d67091f800933e59b8693913764a9e8f4.
---
 common/usb_hub.c | 317 +--
 include/usb.h|   4 -
 2 files changed, 94 insertions(+), 227 deletions(-)

diff --git a/common/usb_hub.c b/common/usb_hub.c
index e6a2cdb..d621f50 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -30,7 +30,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #ifdef CONFIG_SANDBOX
 #include 
@@ -50,19 +49,9 @@ DECLARE_GLOBAL_DATA_PTR;
 #define HUB_SHORT_RESET_TIME	20
 #define HUB_LONG_RESET_TIME	200
 
-#define PORT_OVERCURRENT_MAX_SCAN_COUNT		3
-
-struct usb_device_scan {
-	struct usb_device *dev;		/* USB hub device to scan */
-	struct usb_hub_device *hub;	/* USB hub struct */
-	int port;			/* USB port to scan */
-	struct list_head list;
-};
-
 /* TODO(s...@chromium.org): Remove this when CONFIG_DM_USB is defined */
 static struct usb_hub_device hub_dev[USB_MAX_HUB];
 static int usb_hub_index;
-static LIST_HEAD(usb_scan_list);
 
 __weak void usb_hub_reset_devices(int port)
 {
@@ -120,15 +109,6 @@ static void usb_hub_power_on(struct usb_hub_device *hub)
 		debug("port %d returns %lX\n", i + 1, dev->status);
 	}
 
-#ifdef CONFIG_SANDBOX
-	/*
-	 * Don't set timeout / delay values here. This results
-	 * in these values still being reset to 0.
-	 */
-	if (state_get_skip_delays())
-		

Re: [U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 6 April 2016 at 19:05, Marek Vasut  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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

Re: [U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 6 April 2016 at 03:43, Marek Vasut  wrote:
> On 04/06/2016 03:17 AM, George Broz wrote:
>> On 5 April 2016 at 17:45, Marek Vasut  wrote:
>>> On 04/06/2016 02:31 AM, George Broz wrote:
 On 5 April 2016 at 15:03, 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

 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 
 ^
 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 
>>>  #include 
>>> -#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>>
>>> 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 

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

Re: [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: pr...@electromag.com.au
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

Re: [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  wrote:
>> On 04/06/2016 02:31 AM, George Broz wrote:
>>> On 5 April 2016 at 15:03, 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
>>>
>>> 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 
>>> ^
>>> 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 
>>  #include 
>> -#include 
>>  #include 
>>  #include 
>>  #include 
>>
>> 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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

Re: [U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 5 April 2016 at 17:45, Marek Vasut  wrote:
> On 04/06/2016 02:31 AM, George Broz wrote:
>> On 5 April 2016 at 15:03, 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
>>
>> 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 
>> ^
>> 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 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
>
> 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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [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  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 
> ^
> 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 
 #include 
-#include 
 #include 
 #include 
 #include 

The git tree is updated now.

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

Re: [U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 5 April 2016 at 15:03, 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

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 
^
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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

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

Re: [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  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@ff704000: 0
>> In:serial
>> Out:   serial
>> Err:   serial
>> Model: Terasic DE0-Nano(Atlas)
>> Net:   eth0: ethernet@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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [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  wrote:
>> On 03/18/2016 10:22 PM, George Broz wrote:
>>> On 18 March 2016 at 12:32, Marek Vasut  wrote:
 On 03/18/2016 07:59 PM, George Broz wrote:
> On 16 March 2016 at 18:35, Marek Vasut  wrote:
>> On 03/16/2016 05:17 PM, George Broz wrote:
>>> On 15 March 2016 at 18:29, George Broz  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@ff704000: 0
 In:serial
 Out:   serial
 Err:   serial
 Model: Terasic DE0-Nano(Atlas)
 Net:
 Error: ethernet@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 

Re: [U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 20 March 2016 at 09:49, Marek Vasut  wrote:
> On 03/18/2016 10:22 PM, George Broz wrote:
>> On 18 March 2016 at 12:32, Marek Vasut  wrote:
>>> On 03/18/2016 07:59 PM, George Broz wrote:
 On 16 March 2016 at 18:35, Marek Vasut  wrote:
> On 03/16/2016 05:17 PM, George Broz wrote:
>> On 15 March 2016 at 18:29, George Broz  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@ff704000: 0
>>> In:serial
>>> Out:   serial
>>> Err:   serial
>>> Model: Terasic DE0-Nano(Atlas)
>>> Net:
>>> Error: ethernet@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 ### 

Re: [U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 20 March 2016 at 08:55, 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@ff704000: 0
> In:serial
> Out:   serial
> Err:   serial
> Model: Terasic DE0-Nano(Atlas)
> Net:   eth0: ethernet@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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

Re: [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
> > 0x1710)
> > 
> > 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),
   _regs->hctsiz);
+   udelay(2);

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


Thanks
Chin Liang

> 
> > Thanks
> > Chin Liang
> > 
> > 
> > 
> > > 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

Re: [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 <
> > > > > > > pr...@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 

Re: [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 <
> > > > > > pr...@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
> > > > 

Re: [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  wrote:
>>> On 03/18/2016 07:59 PM, George Broz wrote:
 On 16 March 2016 at 18:35, Marek Vasut  wrote:
> On 03/16/2016 05:17 PM, George Broz wrote:
>> On 15 March 2016 at 18:29, George Broz  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@ff704000: 0
>>> In:serial
>>> Out:   serial
>>> Err:   serial
>>> Model: Terasic DE0-Nano(Atlas)
>>> Net:
>>> Error: ethernet@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 

Re: [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@ff704000: 0
> In:serial
> Out:   serial
> Err:   serial
> Model: Terasic DE0-Nano(Atlas)
> Net:   eth0: ethernet@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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [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  wrote:
>> On 03/18/2016 07:59 PM, George Broz wrote:
>>> On 16 March 2016 at 18:35, Marek Vasut  wrote:
 On 03/16/2016 05:17 PM, George Broz wrote:
> On 15 March 2016 at 18:29, George Broz  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@ff704000: 0
>> In:serial
>> Out:   serial
>> Err:   serial
>> Model: Terasic DE0-Nano(Atlas)
>> Net:
>> Error: ethernet@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
> 

Re: [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@ff704000: 0
In:serial
Out:   serial
Err:   serial
Model: Terasic DE0-Nano(Atlas)
Net:   eth0: ethernet@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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 16 March 2016 at 18:35, Marek Vasut  wrote:
> On 03/16/2016 05:17 PM, George Broz wrote:
>> On 15 March 2016 at 18:29, George Broz  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@ff704000: 0
>>> In:serial
>>> Out:   serial
>>> Err:   serial
>>> Model: Terasic DE0-Nano(Atlas)
>>> Net:
>>> Error: ethernet@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 

Re: [U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 18 March 2016 at 12:32, Marek Vasut  wrote:
> On 03/18/2016 07:59 PM, George Broz wrote:
>> On 16 March 2016 at 18:35, Marek Vasut  wrote:
>>> On 03/16/2016 05:17 PM, George Broz wrote:
 On 15 March 2016 at 18:29, George Broz  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@ff704000: 0
> In:serial
> Out:   serial
> Err:   serial
> Model: Terasic DE0-Nano(Atlas)
> Net:
> Error: ethernet@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 

Re: [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  wrote:
>> On 03/16/2016 05:17 PM, George Broz wrote:
>>> On 15 March 2016 at 18:29, George Broz  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@ff704000: 0
 In:serial
 Out:   serial
 Err:   serial
 Model: Terasic DE0-Nano(Atlas)
 Net:
 Error: ethernet@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: 

Re: [U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 15 March 2016 at 18:29, George Broz  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@ff704000: 0
> In:serial
> Out:   serial
> Err:   serial
> Model: Terasic DE0-Nano(Atlas)
> Net:
> Error: ethernet@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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [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  wrote:

On 03/18/2016 07:59 PM, George Broz wrote:

On 16 March 2016 at 18:35, Marek Vasut  wrote:

On 03/16/2016 05:17 PM, George Broz wrote:

On 15 March 2016 at 18:29, George Broz  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@ff704000: 0
In:serial
Out:   serial
Err:   serial
Model: Terasic DE0-Nano(Atlas)
Net:
Error: ethernet@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 

Re: [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  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@ff704000: 0
>> In:serial
>> Out:   serial
>> Err:   serial
>> Model: Terasic DE0-Nano(Atlas)
>> Net:
>> Error: ethernet@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 

Re: [U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 9 March 2016 at 08:06, George Broz  wrote:
> On 9 March 2016 at 02:55, Marek Vasut  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  wrote:
> On 3/03/2016 2:49 PM, George Broz wrote:
>>
>> On 1 March 2016 at 19:49, Phil Reid  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
  

Re: [U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 9 March 2016 at 02:55, Marek Vasut  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  wrote:
 On 3/03/2016 2:49 PM, George Broz wrote:
>
> On 1 March 2016 at 19:49, Phil Reid  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 

Re: [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  wrote:
>>> On 3/03/2016 2:49 PM, George Broz wrote:

 On 1 March 2016 at 19:49, Phil Reid  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
>> 

Re: [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  wrote:

On 3/03/2016 2:49 PM, George Broz wrote:


On 1 March 2016 at 19:49, Phil Reid  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 

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

Re: [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  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 0x1000 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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [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  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 

Re: [U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 3 March 2016 at 15:07, Marek Vasut  wrote:

>> On 3 March 2016 at 14:42, Marek Vasut  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  wrote:
> On 03/03/2016 11:00 PM, George Broz wrote:
>> On 3 March 2016 at 06:51, Marek Vasut  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 mailing 

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

Re: [U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 3 March 2016 at 06:51, Marek Vasut  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@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 2 March 2016 at 23:11, Phil Reid  wrote:
> On 3/03/2016 2:49 PM, George Broz wrote:
>>
>> On 1 March 2016 at 19:49, Phil Reid  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 ~//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 10 KHz
CLOCK: MMC clock 5 KHz
CLOCK: QSPI clock 37 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@ff704000: 0
In:serial
Out:   serial
Err:   serial
Model: Terasic SoCkit
Net:
Error: ethernet@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

Re: [U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 2 March 2016 at 23:11, Phil Reid  wrote:
> On 3/03/2016 2:49 PM, George Broz wrote:
>>
>> On 1 March 2016 at 19:49, Phil Reid  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 

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

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

Re: [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  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 
Date:   Sun Jan 31 18:10:53 2016 -0700

socfpga: Simplify Makefile filenames

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

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

Re: [U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 2 March 2016 at 14:54, Dinh Nguyen  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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 1 March 2016 at 19:49, Phil Reid  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-3-g40d1cd2 (Mar 01 2016 - 15:29:44)
> CLOCK: MPU   80 kHz
> CLOCK: DDR   40 kHz
> CLOCK: EOSC1  5 kHz
> CLOCK: EOSC2  5 kHz
> CLOCK: F2S_SDR_REF0 kHz
> CLOCK: F2S_PER_REF0 kHz
> CLOCK: MMC5 kHz
> CLOCK: QSPI  40 kHz
> CLOCK: UART  10 kHz
> CLOCK: SPI   20 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-3-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: pr...@electromag.com.au
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [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  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 

Re: [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  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 

Re: [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  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 

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

Re: [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-3-g40d1cd2 (Mar 01 2016 - 15:29:44)
CLOCK: MPU   80 kHz
CLOCK: DDR   40 kHz
CLOCK: EOSC1  5 kHz
CLOCK: EOSC2  5 kHz
CLOCK: F2S_SDR_REF0 kHz
CLOCK: F2S_PER_REF0 kHz
CLOCK: MMC5 kHz
CLOCK: QSPI  40 kHz
CLOCK: UART  10 kHz
CLOCK: SPI   20 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-3-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: pr...@electromag.com.au
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

On 17 February 2016 at 18:45, Phil Reid  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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [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 0xC000 @ffb40520)
dwc_otg_core_host_init: Unable to clear halt on channel 2 (timeout
HCCHAR 0xC000 @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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[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 0xC000 @ffb40520)
dwc_otg_core_host_init: Unable to clear halt on channel 2 (timeout
HCCHAR 0xC000 @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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot