[U-Boot] [PATCH 1/1] driver: net: fsl-mc: fsl_mc_ldpaa_exit exit earlier if dpl applied

[Santan Kumar]

In fsl_mc_ldpaa_exit(), in case of mc is booted and
dpl is applied, it should return earlier without executing
dpbp_exit()

Signed-off-by: Santan Kumar 
---
This piece of code is mistakenly removed in below patch.
 https://patchwork.ozlabs.org/patch/756038/

 drivers/net/fsl-mc/mc.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c
index 8bf25c7..3a30c03 100644
--- a/drivers/net/fsl-mc/mc.c
+++ b/drivers/net/fsl-mc/mc.c
@@ -1336,14 +1336,18 @@ int fsl_mc_ldpaa_exit(bd_t *bd)
 {
int err = 0;
bool is_dpl_apply_status = false;
+   bool mc_boot_status = false;
 
if (bd && mc_lazy_dpl_addr && !fsl_mc_ldpaa_exit(NULL)) {
mc_apply_dpl(mc_lazy_dpl_addr);
mc_lazy_dpl_addr = 0;
}
 
+   if (!get_mc_boot_status())
+   mc_boot_status = true;
+
/* MC is not loaded intentionally, So return success. */
-   if (bd && get_mc_boot_status() != 0)
+   if (bd && !mc_boot_status)
return 0;
 
/* If DPL is deployed, set is_dpl_apply_status as TRUE. */
@@ -1354,11 +1358,14 @@ int fsl_mc_ldpaa_exit(bd_t *bd)
 * For case MC is loaded but DPL is not deployed, return success and
 * print message on console. Else FDT fix-up code execution hanged.
 */
-   if (bd && !get_mc_boot_status() && !is_dpl_apply_status) {
+   if (bd && mc_boot_status && !is_dpl_apply_status) {
printf("fsl-mc: DPL not deployed, DPAA2 ethernet not work\n");
return 0;
}
 
+   if (bd && mc_boot_status && is_dpl_apply_status)
+   return 0;
+
err = dpbp_exit();
if (err < 0) {
printf("dpbp_exit() failed: %d\n", err);
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 10/16] usb: xhci: Program 'route string' in the input slot context

[Stefan Roese]

Hi Bin,

On 29.06.2017 07:42, Bin Meng wrote:

Hi Stefan,

On Thu, Jun 29, 2017 at 1:29 PM, Stefan Roese  wrote:

Hi Bin,


On 29.06.2017 01:00, Bin Meng wrote:


Hi Stefan,

On Wed, Jun 28, 2017 at 8:27 PM, Bin Meng  wrote:


Hi Stefan,

On Wed, Jun 28, 2017 at 7:28 PM, Stefan Roese  wrote:


Hi Bin,


On 27.06.2017 10:27, Bin Meng wrote:



Hi Stefan,

On Tue, Jun 27, 2017 at 1:23 PM, Stefan Roese  wrote:



Hi Bin,


On 27.06.2017 02:01, Bin Meng wrote:




On Tue, Jun 27, 2017 at 2:07 AM, Marek Vasut  wrote:




On 06/24/2017 03:57 AM, Bin Meng wrote:




Hi Marek,

On Sat, Jun 24, 2017 at 2:02 AM, Marek Vasut  wrote:




On 06/23/2017 11:54 AM, Bin Meng wrote:




xHCI spec says: the values of the 'route string' field shall be
initialized by the first 'Address Device' command issued to a
device slot, and shall not be modified by any other command.

So far U-Boot does not program this field, and it does not
prevent
SS device directly attached to root port, or HS device behind an
HS
hub, from working, due to the fact that 'route string' is used by
the xHC to target SS packets. But in order to enumerate devices
behind an SS hub, this field must be programmed.

With this commit and along with previous commits, now SS & HS
devices
attached to a USB 3.0 hub can be enumerated by U-Boot.

As usual, this new feature is only available when DM is on.





Great, but I really dislike the ifdef pollution, so this needs to
be
sorted out.





The ifdef was needed due to it calls DM APIs or access DM udevice.
I
have no intention to add a new feature to the non-DM driver.





But then this creates a massive disparity, it's like we're growing
two
USB stacks.



Yep, unfortunately. But if we continue adding new features/fixes to
the old non-DM stuff, I am not sure how this can encourage people to
switch to DM.





Correct. We definitely don't want to add new features to non-DM
drivers / IF, if this is non-trivial.


Maybe I can check all boards that use xHCI to see if
they are switched to DM?





xHCI is still quite new in U-Boot, so I would expect that all
platforms using it, are using DM or at least not far away from using
it. Yes, please check all xHCI "users", if they use DM. Then we
know if and which users need some "persuasion" to switch over to
DM soon. ;)




I checked all boards that have CONFIG_USB_XHCI_HCD defined but without
CONFIG_DM_USB. Here is the list.

configs/uniphier_v8_defconfig:36:CONFIG_USB_XHCI_HCD=y

configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig:62:CONFIG_USB_XHCI_HCD=y
configs/am57xx_evm_nodt_defconfig:53:CONFIG_USB_XHCI_HCD=y
configs/evb-rk3328_defconfig:34:CONFIG_USB_XHCI_HCD=y
configs/ls1021atwr_nor_lpuart_defconfig:43:CONFIG_USB_XHCI_HCD=y
configs/uniphier_pxs2_ld6b_defconfig:44:CONFIG_USB_XHCI_HCD=y
configs/ls1012ardb_qspi_SECURE_BOOT_defconfig:43:CONFIG_USB_XHCI_HCD=y


configs/ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig:57:CONFIG_USB_XHCI_HCD=y
configs/k2e_hs_evm_defconfig:34:CONFIG_USB_XHCI_HCD=y
configs/ls1021aqds_sdcard_qspi_defconfig:61:CONFIG_USB_XHCI_HCD=y
configs/am43xx_evm_ethboot_defconfig:48:CONFIG_USB_XHCI_HCD=y
configs/xilinx_zynqmp_ep_defconfig:70:CONFIG_USB_XHCI_HCD=y
configs/ls1021aqds_nand_defconfig:57:CONFIG_USB_XHCI_HCD=y
configs/ls1021atwr_qspi_defconfig:50:CONFIG_USB_XHCI_HCD=y
configs/k2g_evm_defconfig:45:CONFIG_USB_XHCI_HCD=y
configs/am57xx_evm_defconfig:63:CONFIG_USB_XHCI_HCD=y
configs/am43xx_hs_evm_defconfig:49:CONFIG_USB_XHCI_HCD=y
configs/am43xx_evm_defconfig:39:CONFIG_USB_XHCI_HCD=y
configs/ls1021atwr_nor_defconfig:42:CONFIG_USB_XHCI_HCD=y
configs/firefly-rk3399_defconfig:59:CONFIG_USB_XHCI_HCD=y
configs/puma-rk3399_defconfig:78:CONFIG_USB_XHCI_HCD=y
configs/cl-som-am57x_defconfig:55:CONFIG_USB_XHCI_HCD=y
configs/ls1021aqds_nor_SECURE_BOOT_defconfig:43:CONFIG_USB_XHCI_HCD=y
configs/uniphier_pro4_defconfig:43:CONFIG_USB_XHCI_HCD=y

configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig:61:CONFIG_USB_XHCI_HCD=y
configs/xilinx_zynqmp_zcu102_defconfig:63:CONFIG_USB_XHCI_HCD=y
configs/ls1021atwr_nor_SECURE_BOOT_defconfig:42:CONFIG_USB_XHCI_HCD=y
configs/cm_t43_defconfig:67:CONFIG_USB_XHCI_HCD=y
configs/k2g_hs_evm_defconfig:36:CONFIG_USB_XHCI_HCD=y
configs/am43xx_evm_qspiboot_defconfig:45:CONFIG_USB_XHCI_HCD=y
configs/ls1021aqds_qspi_defconfig:50:CONFIG_USB_XHCI_HCD=y
configs/am57xx_hs_evm_defconfig:67:CONFIG_USB_XHCI_HCD=y
configs/xilinx_zynqmp_zcu102_revB_defconfig:63:CONFIG_USB_XHCI_HCD=y
configs/ls1021aqds_sdcard_ifc_defconfig:55:CONFIG_USB_XHCI_HCD=y
configs/uniphier_ld20_defconfig:39:CONFIG_USB_XHCI_HCD=y
configs/am43xx_evm_usbhost_boot_defconfig:61:CONFIG_USB_XHCI_HCD=y
configs/ls1021atwr_sdcard_qspi_defconfig:61:CONFIG_USB_XHCI_HCD=y
configs/evb-rk3399_defconfig:60:CONFIG_USB_XHCI_HCD=y
configs/k2hk_evm_defconfig:43:CONFIG_USB_XHCI_HCD=y
configs/k2hk_hs_evm_defconfig:34:CONFIG_USB_XHCI_HCD=y
configs/k2e_evm_defconfig:43:CONFIG_USB_XHCI_HCD=y

[U-Boot] Targets with xHCI but without DM_USB

[Stefan Roese]

Hi,

as you might have noticed, Bin Meng is currently greatly improving
the U-Boot xHCI support. While doing this, he noticed that some
additions are more complex and especially ugly to add, since some
users of the xHCI support have not enabled CONFIG_DM_USB. This
adds ugly #ifdef's, which we really would like to avoid. Because
of this we checked, which boards exactly are using xHCI without
DM_USB enabled. Here a complete list of all the boards:

ls1012ardb_qspi_SECURE_BOOT
ls1021atwr_nor_SECURE_BOOT
am43xx_hs_evm
am57xx_hs_evm
ls1021aqds_nand
ls1021atwr_nor
ls1021atwr_qspi
cm_t43
ls1021atwr_nor_lpuart
ls1021aqds_sdcard_qspi
k2hk_hs_evm
am43xx_evm
ls1021aqds_qspi
am57xx_evm_nodt
k2g_hs_evm
ls1021atwr_sdcard_qspi
am43xx_evm_ethboot
ls1021aqds_sdcard_ifc
k2l_evm
am43xx_evm_usbhost_boot
am43xx_evm_qspiboot
k2g_evm
am57xx_evm
ls1021atwr_sdcard_ifc
cl-som-am57x
k2hk_evm
k2e_evm
ls1021atwr_sdcard_ifc_SECURE_BOOT
ls1021aqds_nor_SECURE_BOOT
k2e_hs_evm

So I'm sending this mail to you, the maintainers of the boards above
and would like you to check, if you can enable DM_USB for these
boards. This would be great, as it would bring the xHCI support into
a much better state, with only DM_USB enabled.

Thanks for your feedback in advance.

Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 10/16] usb: xhci: Program 'route string' in the input slot context

[Bin Meng]

Hi Stefan,

On Thu, Jun 29, 2017 at 1:29 PM, Stefan Roese  wrote:
> Hi Bin,
>
>
> On 29.06.2017 01:00, Bin Meng wrote:
>>
>> Hi Stefan,
>>
>> On Wed, Jun 28, 2017 at 8:27 PM, Bin Meng  wrote:
>>>
>>> Hi Stefan,
>>>
>>> On Wed, Jun 28, 2017 at 7:28 PM, Stefan Roese  wrote:

 Hi Bin,


 On 27.06.2017 10:27, Bin Meng wrote:
>
>
> Hi Stefan,
>
> On Tue, Jun 27, 2017 at 1:23 PM, Stefan Roese  wrote:
>>
>>
>> Hi Bin,
>>
>>
>> On 27.06.2017 02:01, Bin Meng wrote:
>>>
>>>
>>>
>>> On Tue, Jun 27, 2017 at 2:07 AM, Marek Vasut  wrote:



 On 06/24/2017 03:57 AM, Bin Meng wrote:
>
>
>
> Hi Marek,
>
> On Sat, Jun 24, 2017 at 2:02 AM, Marek Vasut  wrote:
>>
>>
>>
>> On 06/23/2017 11:54 AM, Bin Meng wrote:
>>>
>>>
>>>
>>> xHCI spec says: the values of the 'route string' field shall be
>>> initialized by the first 'Address Device' command issued to a
>>> device slot, and shall not be modified by any other command.
>>>
>>> So far U-Boot does not program this field, and it does not
>>> prevent
>>> SS device directly attached to root port, or HS device behind an
>>> HS
>>> hub, from working, due to the fact that 'route string' is used by
>>> the xHC to target SS packets. But in order to enumerate devices
>>> behind an SS hub, this field must be programmed.
>>>
>>> With this commit and along with previous commits, now SS & HS
>>> devices
>>> attached to a USB 3.0 hub can be enumerated by U-Boot.
>>>
>>> As usual, this new feature is only available when DM is on.
>>
>>
>>
>>
>> Great, but I really dislike the ifdef pollution, so this needs to
>> be
>> sorted out.
>
>
>
>
> The ifdef was needed due to it calls DM APIs or access DM udevice.
> I
> have no intention to add a new feature to the non-DM driver.




 But then this creates a massive disparity, it's like we're growing
 two
 USB stacks.

>>>
>>> Yep, unfortunately. But if we continue adding new features/fixes to
>>> the old non-DM stuff, I am not sure how this can encourage people to
>>> switch to DM.
>>
>>
>>
>>
>> Correct. We definitely don't want to add new features to non-DM
>> drivers / IF, if this is non-trivial.
>>
>>> Maybe I can check all boards that use xHCI to see if
>>> they are switched to DM?
>>
>>
>>
>>
>> xHCI is still quite new in U-Boot, so I would expect that all
>> platforms using it, are using DM or at least not far away from using
>> it. Yes, please check all xHCI "users", if they use DM. Then we
>> know if and which users need some "persuasion" to switch over to
>> DM soon. ;)
>
>
>
> I checked all boards that have CONFIG_USB_XHCI_HCD defined but without
> CONFIG_DM_USB. Here is the list.
>
> configs/uniphier_v8_defconfig:36:CONFIG_USB_XHCI_HCD=y
>
> configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig:62:CONFIG_USB_XHCI_HCD=y
> configs/am57xx_evm_nodt_defconfig:53:CONFIG_USB_XHCI_HCD=y
> configs/evb-rk3328_defconfig:34:CONFIG_USB_XHCI_HCD=y
> configs/ls1021atwr_nor_lpuart_defconfig:43:CONFIG_USB_XHCI_HCD=y
> configs/uniphier_pxs2_ld6b_defconfig:44:CONFIG_USB_XHCI_HCD=y
> configs/ls1012ardb_qspi_SECURE_BOOT_defconfig:43:CONFIG_USB_XHCI_HCD=y
>
>
> configs/ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig:57:CONFIG_USB_XHCI_HCD=y
> configs/k2e_hs_evm_defconfig:34:CONFIG_USB_XHCI_HCD=y
> configs/ls1021aqds_sdcard_qspi_defconfig:61:CONFIG_USB_XHCI_HCD=y
> configs/am43xx_evm_ethboot_defconfig:48:CONFIG_USB_XHCI_HCD=y
> configs/xilinx_zynqmp_ep_defconfig:70:CONFIG_USB_XHCI_HCD=y
> configs/ls1021aqds_nand_defconfig:57:CONFIG_USB_XHCI_HCD=y
> configs/ls1021atwr_qspi_defconfig:50:CONFIG_USB_XHCI_HCD=y
> configs/k2g_evm_defconfig:45:CONFIG_USB_XHCI_HCD=y
> configs/am57xx_evm_defconfig:63:CONFIG_USB_XHCI_HCD=y
> configs/am43xx_hs_evm_defconfig:49:CONFIG_USB_XHCI_HCD=y
> configs/am43xx_evm_defconfig:39:CONFIG_USB_XHCI_HCD=y
> configs/ls1021atwr_nor_defconfig:42:CONFIG_USB_XHCI_HCD=y
> configs/firefly-rk3399_defconfig:59:CONFIG_USB_XHCI_HCD=y
> configs/puma-rk3399_defconfig:78:CONFIG_USB_XHCI_HCD=y
> configs/cl-som-am57x_defconfig:55:CONFIG_USB_XHCI_HCD=y
> configs/ls1021aqds_nor_SECURE_BOOT_defconfig:43:CONFIG_USB_XHCI_HCD=y
> configs/uniphier_pro4_defconfig:43:CONFIG_USB_XHCI_HCD=y
>
> 

Re: [U-Boot] [PATCH 0/3] usb: xhci: Add interrupt transfer support

[Bin Meng]

Hi Stefan,

On Wed, Jun 28, 2017 at 8:47 PM, Stefan Roese  wrote:
> Hi Bin,
>
> On 28.06.2017 14:11, Bin Meng wrote:
>> On Wed, Jun 28, 2017 at 7:00 PM, Stefan Roese  wrote:
>>> Hi Bin,
>>>
>>> On 26.06.2017 13:05, Bin Meng wrote:
 This series is the final series of the xHCI driver update.

 This adds the missing interrupt transfer support to xHCI driver, so
 that devices like USB keyboard that uses interrupt transfer when
 CONFIG_SYS_USB_EVENT_POLL is defined can work.

 Previous two series:
 [1]: usb: xhci: Fix USB xHCI support on Intel platform
 https://lists.denx.de/pipermail/u-boot/2017-June/296166.html
 [2]: usb: hub: Support USB 3.0 hubs
 https://lists.denx.de/pipermail/u-boot/2017-June/296284.html

 This series is available at u-boot-x86/xhci-working3 for testing.
>>>
>>> I'm using this git branch to test all your xHCI related patches
>>> now. On my BayTrail platform I get these messages upon "usb reset"
>>> scanning:
>>>
>>> => usb reset
>>> resetting USB...
>>> USB0:   Register 7000820 NbrPorts 7
>>> Starting the controller
>>> USB XHCI 1.00
>>> scanning bus 0 for devices... cannot reset port 1!?
>>> USB device descriptor short read (expected 18, got 8)
>>> 5 USB Device(s) found
>>> scanning usb for storage devices... 1 Storage Device(s) found
>>>
>>> On the 2nd scan, the "cannot reset port 1" line is gone:
>>>
>>> => usb reset
>>> resetting USB...
>>> USB0:   Register 7000820 NbrPorts 7
>>> Starting the controller
>>> USB XHCI 1.00
>>> scanning bus 0 for devices... USB device descriptor short read (expected 
>>> 18, got 8)
>>> 5 USB Device(s) found
>>> scanning usb for storage devices... 1 Storage Device(s) found
>>>
>>> All USB devices seem to be detected correctly though. Here the
>>> logs:
>>>
>>> => usb tree
>>> USB device tree:
>>>1  Hub (5 Gb/s, 0mA)
>>>|  U-Boot XHCI Host Controller
>>>|
>>>+-2  Hub (480 Mb/s, 100mA)
>>>|
>>>+-3  Hub (480 Mb/s, 2mA)
>>>| |
>>>| +-5  Mass Storage (480 Mb/s, 200mA)
>>>|  JetFlash Mass Storage Device 3281440601
>>>|
>>>+-4  Vendor specific (5 Gb/s, 64mA)
>>> Realtek USB 10/100/1000 LAN 0200
>>>
>>> => usb info
>>> 1: Hub,  USB Revision 3.0
>>>   - U-Boot XHCI Host Controller
>>>   - Class: Hub
>>>   - PacketSize: 512  Configurations: 1
>>>   - Vendor: 0x  Product 0x Version 1.0
>>> Configuration: 1
>>> - Interfaces: 1 Self Powered 0mA
>>>   Interface: 0
>>>   - Alternate Setting 0, Endpoints: 1
>>>   - Class Hub
>>>   - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms
>>>
>>> 2: Hub,  USB Revision 2.0
>>>   - Class: Hub
>>>   - PacketSize: 64  Configurations: 1
>>>   - Vendor: 0x0409  Product 0x005a Version 1.0
>>> Configuration: 1
>>> - Interfaces: 1 Self Powered Remote Wakeup 100mA
>>>   Interface: 0
>>>   - Alternate Setting 0, Endpoints: 1
>>>   - Class Hub
>>>   - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms
>>>
>>> 3: Hub,  USB Revision 2.1
>>>   - Class: Hub
>>>   - PacketSize: 64  Configurations: 1
>>>   - Vendor: 0x0424  Product 0x4604 Version 1.131
>>> Configuration: 1
>>> - Interfaces: 1 Self Powered Remote Wakeup 2mA
>>>   Interface: 0
>>>   - Alternate Setting 0, Endpoints: 1
>>>   - Class Hub
>>>   - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms
>>>   - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms
>>>
>>> 5: Mass Storage,  USB Revision 2.10
>>>   - JetFlash Mass Storage Device 3281440601
>>>   - Class: (from Interface) Mass Storage
>>>   - PacketSize: 64  Configurations: 1
>>>   - Vendor: 0x8564  Product 0x1000 Version 16.117
>>> Configuration: 1
>>> - Interfaces: 1 Bus Powered 200mA
>>>   Interface: 0
>>>   - Alternate Setting 0, Endpoints: 2
>>>   - Class Mass Storage, Transp. SCSI, Bulk only
>>>   - Endpoint 2 Out Bulk MaxPacket 512
>>>   - Endpoint 1 In Bulk MaxPacket 512
>>>
>>> 4: Vendor specific,  USB Revision 3.0
>>>   - Realtek USB 10/100/1000 LAN 0200
>>>   - Class: (from Interface) Vendor specific
>>>   - PacketSize: 512  Configurations: 2
>>>   - Vendor: 0x0bda  Product 0x8153 Version 48.0
>>> Configuration: 1
>>> - Interfaces: 1 Bus Powered Remote Wakeup 64mA
>>>   Interface: 0
>>>   - Alternate Setting 0, Endpoints: 3
>>>   - Class Vendor specific
>>>   - Endpoint 1 In Bulk MaxPacket 1024
>>>   - Endpoint 2 Out Bulk MaxPacket 1024
>>>   - Endpoint 3 In Interrupt MaxPacket 2 Interval 8ms
>>>
>>> Do you have any ideas about the scanning logs that I've noticed
>>> above? Would it help if I provided some debug logs (-DDEBUG)
>>> for this?
>>
>> "cannot reset port 1" message is annoying, but that may happen
>> sometimes due to unstable power supply. I will see if we can mute it
>> if it's not the final round of reset try.
>
> That would be good, thanks.
>
>> I am more concerned about
>> the "USB device descriptor 

Re: [U-Boot] [PATCH 10/16] usb: xhci: Program 'route string' in the input slot context

[Stefan Roese]

Hi Bin,

On 29.06.2017 01:00, Bin Meng wrote:

Hi Stefan,

On Wed, Jun 28, 2017 at 8:27 PM, Bin Meng  wrote:

Hi Stefan,

On Wed, Jun 28, 2017 at 7:28 PM, Stefan Roese  wrote:

Hi Bin,


On 27.06.2017 10:27, Bin Meng wrote:


Hi Stefan,

On Tue, Jun 27, 2017 at 1:23 PM, Stefan Roese  wrote:


Hi Bin,


On 27.06.2017 02:01, Bin Meng wrote:



On Tue, Jun 27, 2017 at 2:07 AM, Marek Vasut  wrote:



On 06/24/2017 03:57 AM, Bin Meng wrote:



Hi Marek,

On Sat, Jun 24, 2017 at 2:02 AM, Marek Vasut  wrote:



On 06/23/2017 11:54 AM, Bin Meng wrote:



xHCI spec says: the values of the 'route string' field shall be
initialized by the first 'Address Device' command issued to a
device slot, and shall not be modified by any other command.

So far U-Boot does not program this field, and it does not prevent
SS device directly attached to root port, or HS device behind an HS
hub, from working, due to the fact that 'route string' is used by
the xHC to target SS packets. But in order to enumerate devices
behind an SS hub, this field must be programmed.

With this commit and along with previous commits, now SS & HS
devices
attached to a USB 3.0 hub can be enumerated by U-Boot.

As usual, this new feature is only available when DM is on.




Great, but I really dislike the ifdef pollution, so this needs to be
sorted out.




The ifdef was needed due to it calls DM APIs or access DM udevice. I
have no intention to add a new feature to the non-DM driver.




But then this creates a massive disparity, it's like we're growing two
USB stacks.



Yep, unfortunately. But if we continue adding new features/fixes to
the old non-DM stuff, I am not sure how this can encourage people to
switch to DM.




Correct. We definitely don't want to add new features to non-DM
drivers / IF, if this is non-trivial.


Maybe I can check all boards that use xHCI to see if
they are switched to DM?




xHCI is still quite new in U-Boot, so I would expect that all
platforms using it, are using DM or at least not far away from using
it. Yes, please check all xHCI "users", if they use DM. Then we
know if and which users need some "persuasion" to switch over to
DM soon. ;)



I checked all boards that have CONFIG_USB_XHCI_HCD defined but without
CONFIG_DM_USB. Here is the list.

configs/uniphier_v8_defconfig:36:CONFIG_USB_XHCI_HCD=y
configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig:62:CONFIG_USB_XHCI_HCD=y
configs/am57xx_evm_nodt_defconfig:53:CONFIG_USB_XHCI_HCD=y
configs/evb-rk3328_defconfig:34:CONFIG_USB_XHCI_HCD=y
configs/ls1021atwr_nor_lpuart_defconfig:43:CONFIG_USB_XHCI_HCD=y
configs/uniphier_pxs2_ld6b_defconfig:44:CONFIG_USB_XHCI_HCD=y
configs/ls1012ardb_qspi_SECURE_BOOT_defconfig:43:CONFIG_USB_XHCI_HCD=y

configs/ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig:57:CONFIG_USB_XHCI_HCD=y
configs/k2e_hs_evm_defconfig:34:CONFIG_USB_XHCI_HCD=y
configs/ls1021aqds_sdcard_qspi_defconfig:61:CONFIG_USB_XHCI_HCD=y
configs/am43xx_evm_ethboot_defconfig:48:CONFIG_USB_XHCI_HCD=y
configs/xilinx_zynqmp_ep_defconfig:70:CONFIG_USB_XHCI_HCD=y
configs/ls1021aqds_nand_defconfig:57:CONFIG_USB_XHCI_HCD=y
configs/ls1021atwr_qspi_defconfig:50:CONFIG_USB_XHCI_HCD=y
configs/k2g_evm_defconfig:45:CONFIG_USB_XHCI_HCD=y
configs/am57xx_evm_defconfig:63:CONFIG_USB_XHCI_HCD=y
configs/am43xx_hs_evm_defconfig:49:CONFIG_USB_XHCI_HCD=y
configs/am43xx_evm_defconfig:39:CONFIG_USB_XHCI_HCD=y
configs/ls1021atwr_nor_defconfig:42:CONFIG_USB_XHCI_HCD=y
configs/firefly-rk3399_defconfig:59:CONFIG_USB_XHCI_HCD=y
configs/puma-rk3399_defconfig:78:CONFIG_USB_XHCI_HCD=y
configs/cl-som-am57x_defconfig:55:CONFIG_USB_XHCI_HCD=y
configs/ls1021aqds_nor_SECURE_BOOT_defconfig:43:CONFIG_USB_XHCI_HCD=y
configs/uniphier_pro4_defconfig:43:CONFIG_USB_XHCI_HCD=y
configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig:61:CONFIG_USB_XHCI_HCD=y
configs/xilinx_zynqmp_zcu102_defconfig:63:CONFIG_USB_XHCI_HCD=y
configs/ls1021atwr_nor_SECURE_BOOT_defconfig:42:CONFIG_USB_XHCI_HCD=y
configs/cm_t43_defconfig:67:CONFIG_USB_XHCI_HCD=y
configs/k2g_hs_evm_defconfig:36:CONFIG_USB_XHCI_HCD=y
configs/am43xx_evm_qspiboot_defconfig:45:CONFIG_USB_XHCI_HCD=y
configs/ls1021aqds_qspi_defconfig:50:CONFIG_USB_XHCI_HCD=y
configs/am57xx_hs_evm_defconfig:67:CONFIG_USB_XHCI_HCD=y
configs/xilinx_zynqmp_zcu102_revB_defconfig:63:CONFIG_USB_XHCI_HCD=y
configs/ls1021aqds_sdcard_ifc_defconfig:55:CONFIG_USB_XHCI_HCD=y
configs/uniphier_ld20_defconfig:39:CONFIG_USB_XHCI_HCD=y
configs/am43xx_evm_usbhost_boot_defconfig:61:CONFIG_USB_XHCI_HCD=y
configs/ls1021atwr_sdcard_qspi_defconfig:61:CONFIG_USB_XHCI_HCD=y
configs/evb-rk3399_defconfig:60:CONFIG_USB_XHCI_HCD=y
configs/k2hk_evm_defconfig:43:CONFIG_USB_XHCI_HCD=y
configs/k2hk_hs_evm_defconfig:34:CONFIG_USB_XHCI_HCD=y
configs/k2e_evm_defconfig:43:CONFIG_USB_XHCI_HCD=y
configs/ls1021atwr_sdcard_ifc_defconfig:54:CONFIG_USB_XHCI_HCD=y
configs/k2l_evm_defconfig:43:CONFIG_USB_XHCI_HCD=y

So it looks we have lots of conversion work to be done 

[U-Boot] [PATCH] scripts: config_whitelist: Handle lines with leading spaces/tabs

[Bin Meng]

Some Kconfig options are defined in a line with leading spaces/tabs.
Update build-whitelist/check-config scripts to handle such cases.
Generate a new config_whitelist.txt with new scripts.

Signed-off-by: Bin Meng 
---

 scripts/build-whitelist.sh   |   4 +-
 scripts/check-config.sh  |   5 +-
 scripts/config_whitelist.txt | 115 ---
 3 files changed, 5 insertions(+), 119 deletions(-)

diff --git a/scripts/build-whitelist.sh b/scripts/build-whitelist.sh
index f169eaa..7d8160d 100755
--- a/scripts/build-whitelist.sh
+++ b/scripts/build-whitelist.sh
@@ -39,8 +39,8 @@ git grep CONFIG_ | \
 # Finally, we need a list of the valid Kconfig options to exclude these from
 # the whitelist.
 cat `find . -name "Kconfig*"` |sed -n \
-   -e 's/^config *\([A-Za-z0-9_]*\).*$/CONFIG_\1/p' \
-   -e 's/^menuconfig *\([A-Za-z0-9_]*\).*$/CONFIG_\1/p' \
+   -e 's/^\s*config *\([A-Za-z0-9_]*\).*$/CONFIG_\1/p' \
+   -e 's/^\s*menuconfig *\([A-Za-z0-9_]*\).*$/CONFIG_\1/p' \
|sort |uniq >scripts/config_whitelist.txt.tmp2
 
 # Use only the options that are present in the first file but not the second.
diff --git a/scripts/check-config.sh b/scripts/check-config.sh
index 97e52dc..2677584 100755
--- a/scripts/check-config.sh
+++ b/scripts/check-config.sh
@@ -33,8 +33,9 @@ cat ${path} |sed -n 's/^#define 
\(CONFIG_[A-Za-z0-9_]*\).*/\1/p' |sort |uniq \
 comm -23 ${configs} ${whitelist} > ${suspects}
 
 cat `find ${srctree} -name "Kconfig*"` |sed -n \
-   -e 's/^config *\([A-Za-z0-9_]*\).*$/CONFIG_\1/p' \
-   -e 's/^menuconfig \([A-Za-z0-9_]*\).*$/CONFIG_\1/p' |sort |uniq > ${ok}
+   -e 's/^\s*config *\([A-Za-z0-9_]*\).*$/CONFIG_\1/p' \
+   -e 's/^\s*menuconfig \([A-Za-z0-9_]*\).*$/CONFIG_\1/p' \
+   |sort |uniq > ${ok}
 comm -23 ${suspects} ${ok} >${new_adhoc}
 if [ -s ${new_adhoc} ]; then
echo >&2 "Error: You must add new CONFIG options using Kconfig"
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index 31cbb86..ada2762 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -116,7 +116,6 @@ CONFIG_ARMV7_SECURE_MAX_SIZE
 CONFIG_ARMV7_SECURE_RESERVE_SIZE
 CONFIG_ARMV8_SWITCH_TO_EL1
 CONFIG_ARM_ARCH_CP15_ERRATA
-CONFIG_ARM_ASM_UNIFIED
 CONFIG_ARM_DCC
 CONFIG_ARM_FREQ
 CONFIG_ARM_GIC_BASE_ADDRESS
@@ -219,7 +218,6 @@ CONFIG_BMP_16BPP
 CONFIG_BMP_24BPP
 CONFIG_BMP_32BPP
 CONFIG_BOARDDIR
-CONFIG_BOARDINFO
 CONFIG_BOARDNAME
 CONFIG_BOARDNAME_LOCAL
 CONFIG_BOARD_AXM
@@ -297,7 +295,6 @@ CONFIG_BOOT_RETRY_MIN
 CONFIG_BOOT_RETRY_TIME
 CONFIG_BOUNCE_BUFFER
 CONFIG_BPTR_VIRT_ADDR
-CONFIG_BSEIP
 CONFIG_BS_ADDR_DEVICE
 CONFIG_BS_ADDR_RAM
 CONFIG_BS_COPY_CMD
@@ -325,7 +322,6 @@ CONFIG_CDP_POWER_CONSUMPTION
 CONFIG_CDP_TRIGGER
 CONFIG_CDP_VERSION
 CONFIG_CFG_DATA_SECTOR
-CONFIG_CFG_USB
 CONFIG_CFI_FLASH_USE_WEAK_ACCESSORS
 CONFIG_CF_DSPI
 CONFIG_CF_SBF
@@ -829,7 +825,6 @@ CONFIG_FEATURE_SH_APPLETS_ALWAYS_WIN
 CONFIG_FEATURE_SH_EXTRA_QUIET
 CONFIG_FEATURE_SH_FANCY_PROMPT
 CONFIG_FEATURE_SH_STANDALONE_SHELL
-CONFIG_FEC_ENET
 CONFIG_FEC_ENET_DEV
 CONFIG_FEC_FIXED_SPEED
 CONFIG_FEC_MXC_25M_REF_CLK
@@ -952,7 +947,6 @@ CONFIG_FTIDE020S_BASE
 CONFIG_FTIIC010_BASE
 CONFIG_FTINTC010_BASE
 CONFIG_FTLCDC100_BASE
-CONFIG_FTMAC100
 CONFIG_FTMAC100_BASE
 CONFIG_FTMAC110_BASE
 CONFIG_FTPCI100_BASE
@@ -1032,7 +1026,6 @@ CONFIG_HAS_FSL_DR_USB
 CONFIG_HAS_FSL_MPH_USB
 CONFIG_HAS_FSL_XHCI_USB
 CONFIG_HAS_POST
-CONFIG_HAVE_ACPI_RESUME
 CONFIG_HCLK_FREQ
 CONFIG_HDBOOT
 CONFIG_HDMI_ENCODER_I2C_ADDR
@@ -1041,9 +1034,7 @@ CONFIG_HIDE_LOGO_VERSION
 CONFIG_HIGH_BATS
 CONFIG_HIKEY_GPIO
 CONFIG_HIS_DRIVER
-CONFIG_HITACHI_SP19X001_Z1A
 CONFIG_HITACHI_SX14
-CONFIG_HLD1045
 CONFIG_HOSTNAME
 CONFIG_HOST_MAX_DEVICES
 CONFIG_HOTPLUG
@@ -1198,7 +1189,6 @@ CONFIG_HUSH_INIT_VAR
 CONFIG_HVBOOT
 CONFIG_HWCONFIG
 CONFIG_HW_ENV_SETTINGS
-CONFIG_HW_WATCHDOG
 CONFIG_HW_WATCHDOG_TIMEOUT_MS
 CONFIG_I2C
 CONFIG_I2C_CHIPADDRESS
@@ -1284,7 +1274,6 @@ CONFIG_IRAM_SIZE
 CONFIG_IRAM_STACK
 CONFIG_IRAM_TOP
 CONFIG_IRDA_BASE
-CONFIG_ISP1362_USB
 CONFIG_IS_BUILTIN
 CONFIG_IS_ENABLED
 CONFIG_IS_INVALID
@@ -1352,7 +1341,6 @@ CONFIG_KM_ECC_MODE
 CONFIG_KM_ENV_IS_IN_SPI_NOR
 CONFIG_KM_FDT_ADDR
 CONFIG_KM_FPGA_CONFIG
-CONFIG_KM_I2C_ABORT
 CONFIG_KM_IVM_BUS
 CONFIG_KM_KERNEL_ADDR
 CONFIG_KM_KIRKWOOD
@@ -1422,7 +1410,6 @@ CONFIG_KVM_GUEST
 CONFIG_KW88F6192
 CONFIG_KW88F6281
 CONFIG_KW88F6702
-CONFIG_KYOCERA_KCS057QV1AJ
 CONFIG_KZM_A9_GT
 CONFIG_L1_INIT_RAM
 CONFIG_L2_CACHE
@@ -1460,7 +1447,6 @@ CONFIG_LOADADDR
 CONFIG_LOADCMD
 CONFIG_LOADS_ECHO
 CONFIG_LOGBUFFER
-CONFIG_LOWBOOT
 CONFIG_LOWPOWER_ADDR
 CONFIG_LOWPOWER_FLAG
 CONFIG_LOW_MCFCLK
@@ -1535,7 +1521,6 @@ CONFIG_MACH_TYPE_COMPAT_REV
 CONFIG_MACRESET_TIMEOUT
 CONFIG_MAC_ADDR_IN_EEPROM
 CONFIG_MAC_ADDR_IN_SPIFLASH
-CONFIG_MAC_OFFSET
 CONFIG_MAKALU
 CONFIG_MALLOC_F_ADDR
 CONFIG_MALTA
@@ -1570,8 +1555,6 @@ CONFIG_MENUKEY
 CONFIG_MENUPROMPT
 CONFIG_MENU_SHOW
 CONFIG_MFG_ENV_SETTINGS
-CONFIG_MGCOGE

Re: [U-Boot] [PATCH 0/3] usb: xhci: Add interrupt transfer support

[Bin Meng]

On Thu, Jun 29, 2017 at 6:52 AM, Bin Meng  wrote:
> +Simon
>
> On Wed, Jun 28, 2017 at 7:00 PM, Stefan Roese  wrote:
>> Hi Bin,
>>
>> On 26.06.2017 13:05, Bin Meng wrote:
>>> This series is the final series of the xHCI driver update.
>>>
>>> This adds the missing interrupt transfer support to xHCI driver, so
>>> that devices like USB keyboard that uses interrupt transfer when
>>> CONFIG_SYS_USB_EVENT_POLL is defined can work.
>>>
>>> Previous two series:
>>> [1]: usb: xhci: Fix USB xHCI support on Intel platform
>>> https://lists.denx.de/pipermail/u-boot/2017-June/296166.html
>>> [2]: usb: hub: Support USB 3.0 hubs
>>> https://lists.denx.de/pipermail/u-boot/2017-June/296284.html
>>>
>>> This series is available at u-boot-x86/xhci-working3 for testing.
>>
>> I'm using this git branch to test all your xHCI related patches
>> now. On my BayTrail platform I get these messages upon "usb reset"
>> scanning:
>>
>> => usb reset
>> resetting USB...
>> USB0:   Register 7000820 NbrPorts 7
>> Starting the controller
>> USB XHCI 1.00
>> scanning bus 0 for devices... cannot reset port 1!?
>> USB device descriptor short read (expected 18, got 8)
>> 5 USB Device(s) found
>>scanning usb for storage devices... 1 Storage Device(s) found
>>
>> On the 2nd scan, the "cannot reset port 1" line is gone:
>>
>> => usb reset
>> resetting USB...
>> USB0:   Register 7000820 NbrPorts 7
>> Starting the controller
>> USB XHCI 1.00
>> scanning bus 0 for devices... USB device descriptor short read (expected 18, 
>> got 8)
>> 5 USB Device(s) found
>>scanning usb for storage devices... 1 Storage Device(s) found
>>
>> All USB devices seem to be detected correctly though. Here the
>> logs:
>>
>> => usb tree
>> USB device tree:
>>   1  Hub (5 Gb/s, 0mA)
>>   |  U-Boot XHCI Host Controller
>>   |
>>   +-2  Hub (480 Mb/s, 100mA)
>>   |
>>   +-3  Hub (480 Mb/s, 2mA)
>>   | |
>>   | +-5  Mass Storage (480 Mb/s, 200mA)
>>   |  JetFlash Mass Storage Device 3281440601
>>   |
>>   +-4  Vendor specific (5 Gb/s, 64mA)
>>Realtek USB 10/100/1000 LAN 0200
>>
>> => usb info
>> 1: Hub,  USB Revision 3.0
>>  - U-Boot XHCI Host Controller
>>  - Class: Hub
>>  - PacketSize: 512  Configurations: 1
>>  - Vendor: 0x  Product 0x Version 1.0
>>Configuration: 1
>>- Interfaces: 1 Self Powered 0mA
>>  Interface: 0
>>  - Alternate Setting 0, Endpoints: 1
>>  - Class Hub
>>  - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms
>>
>> 2: Hub,  USB Revision 2.0
>>  - Class: Hub
>>  - PacketSize: 64  Configurations: 1
>>  - Vendor: 0x0409  Product 0x005a Version 1.0
>>Configuration: 1
>>- Interfaces: 1 Self Powered Remote Wakeup 100mA
>>  Interface: 0
>>  - Alternate Setting 0, Endpoints: 1
>>  - Class Hub
>>  - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms
>>
>> 3: Hub,  USB Revision 2.1
>>  - Class: Hub
>>  - PacketSize: 64  Configurations: 1
>>  - Vendor: 0x0424  Product 0x4604 Version 1.131
>>Configuration: 1
>>- Interfaces: 1 Self Powered Remote Wakeup 2mA
>>  Interface: 0
>>  - Alternate Setting 0, Endpoints: 1
>>  - Class Hub
>>  - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms
>>  - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms
>>
>> 5: Mass Storage,  USB Revision 2.10
>>  - JetFlash Mass Storage Device 3281440601
>>  - Class: (from Interface) Mass Storage
>>  - PacketSize: 64  Configurations: 1
>>  - Vendor: 0x8564  Product 0x1000 Version 16.117
>>Configuration: 1
>>- Interfaces: 1 Bus Powered 200mA
>>  Interface: 0
>>  - Alternate Setting 0, Endpoints: 2
>>  - Class Mass Storage, Transp. SCSI, Bulk only
>>  - Endpoint 2 Out Bulk MaxPacket 512
>>  - Endpoint 1 In Bulk MaxPacket 512
>>
>> 4: Vendor specific,  USB Revision 3.0
>>  - Realtek USB 10/100/1000 LAN 0200
>>  - Class: (from Interface) Vendor specific
>>  - PacketSize: 512  Configurations: 2
>>  - Vendor: 0x0bda  Product 0x8153 Version 48.0
>>Configuration: 1
>>- Interfaces: 1 Bus Powered Remote Wakeup 64mA
>>  Interface: 0
>>  - Alternate Setting 0, Endpoints: 3
>>  - Class Vendor specific
>>  - Endpoint 1 In Bulk MaxPacket 1024
>>  - Endpoint 2 Out Bulk MaxPacket 1024
>>  - Endpoint 3 In Interrupt MaxPacket 2 Interval 8ms
>>
>> Do you have any ideas about the scanning logs that I've noticed
>> above? Would it help if I provided some debug logs (-DDEBUG)
>> for this?
>>
>>
>> BTW: I need to re-add the SYS_USB_EVENT_POLL* options back to
>> the whilelist file. Otherwise compiling fails with this
>> message:
>>
>> $ make minnowmax_defconfig
>> $ make -s -j10
>> Error: You must add new CONFIG options using Kconfig
>> The following new ad-hoc CONFIG options were detected:
>> CONFIG_SYS_USB_EVENT_POLL
>>
>> Please add these via Kconfig instead. Find a suitable Kconfig
>> file and add a 'config' or 'menuconfig' option.
>> Makefile:862: recipe for target 'all' failed
>>
>> Don't you see 

Re: [U-Boot] [PATCH V7 4/4] rockchip: rk3288: enable rockusb support on rk3288 based device

[Eddie Cai]

2017-06-28 15:55 GMT+08:00 Lukasz Majewski :
> Hi Eddie,
>
>> Hi Lukasz
>>
>> 2017-06-21 15:44 GMT+08:00 Lukasz Majewski :
>> > Hi Eddie,
>> >
>> >> Hi Eddie,
>> >>
>> >> > 2017-05-31 15:12 GMT+08:00 Lukasz Majewski :
>> >> > > On Wed, 31 May 2017 10:27:23 +0800
>> >> > > Eddie Cai  wrote:
>> >> > >
>> >> > >> Hi Lukasz
>> >> > >>
>> >> > >> 2017-05-29 15:51 GMT+08:00 Lukasz Majewski :
>> >> > >> > Good morning Eddie,
>> >> > >> >
>> >> > >> >> this patch enable rockusb support on rk3288 based device.
>> >> > >> >>
>> >> > >> >> Signed-off-by: Eddie Cai 
>> >> > >> >> Reviewed-by: Simon Glass 
>> >> > >> >>
>> >> > >> >
>> >> > >> > I've give this patch set a try on travisCI:
>> >> > >> >
>> >> > >> > https://travis-ci.org/lmajewski/u-boot-dfu/jobs/237068149
>> >> > >> >
>> >> > >> > Unfortunately, there are some problem with following boards:
>> >> > >> >
>> >> > >> > chromebook_jerry, chromebook_minnie ...
>> >> > >> I did it by myself last week. i got the same error. then i fix
>> >> > >> those chromebook error
>> >> > >> and test again. I still got some 3036 board error. But it
>> >> > >> build successfully when i
>> >> > >> build it on my computer. here is the travis-ci.org error log
>> >> > >> https://travis-ci.org/eddiecailinux/u-boot/jobs/236232837
>> >> > >> I have no idea what can i do to fix it.
>> >> > >
>> >> > > Can you share the SHA1 of commit on top of which you applied
>> >> > > your patches?
>> >> > >
>> >> > > I take u-boot-usb (the USB u-boot tree from Marek Vasut) as a
>> >> > > base and then apply commits on top of it.
>> >> > here is my branch
>> >> > https://github.com/eddiecailinux/u-boot/tree/rockusb-v8 I apply
>> >> > my patch on top of below commit commit
>> >> > a63d800196ebee59b0f8ff924f67843cd597a8c1 Author: Tom Rini
>> >> >  Date:   Mon May 1 19:54:41 2017 -0400
>> >> >
>> >> > Prepare v2017.05-rc3
>> >> >
>> >> > Signed-off-by: Tom Rini 
>> >>
>> >> I've looked thoroughly at your patches:
>> >>
>> >> Your patches has been applied on top of the above commit:
>> >> SHA1: a63d800196ebee59b0f8ff924f67843cd597a8c1
>> >>
>> >> Before applying your patches:
>> >> https://travis-ci.org/lmajewski/u-boot-dfu/builds/239069544
>> >>
>> >> After applying them:
>> >> https://travis-ci.org/lmajewski/u-boot-dfu/builds/239074799
>> >>
>> >> To be more precise:
>> >> https://travis-ci.org/lmajewski/u-boot-dfu/jobs/239074800
>> >>
>> >>
>> >> For example:
>> >>
>> >>   arm:  +   rock2
>> >> +cmd/built-in.o: In function `do_fastboot':
>> >> +cmd/fastboot.c:28: undefined reference to `board_usb_init'
>> >> +cmd/fastboot.c:34: undefined reference to `g_dnl_clear_detach'
>> >> +cmd/fastboot.c:35: undefined reference to `g_dnl_register'
>> >> +cmd/fastboot.c:39: undefined reference to
>> >>   `g_dnl_board_usb_cable_connected' +cmd/fastboot.c:57:
>> >> undefined reference to `g_dnl_unregister' +cmd/fastboot.c:58:
>> >> undefined reference to `g_dnl_clear_detach' +cmd/fastboot.c:59:
>> >> undefined reference to `board_usb_cleanup' +cmd/fastboot.c:47:
>> >> undefined reference to `g_dnl_detach' +cmd/fastboot.c:51: undefined
>> >>   reference to `usb_gadget_handle_interrupts' +cmd/built-in.o:
>> >> In function `do_usb_mass_storage':
>> >>
>> >>
>> >>
>> >> For me it seems like you have enabled fastboot support on too many
>> >> rochchip's boards.
>> >>
>> >> Can you look on it?
>> >
>> > If I might ask - have you managed to investigate this issue?
>> I can fix the chromebook error.
>
> Ok.
>
>> But i didn't enable rockusb support on
>> rk3036 based board. I built these board on my desktop. It work fine.
>
> The issue is not with this one particular board.
>
> I'm concerned, since your patch set causes build errors for other
> boards.
>
> Can you build test (with travis-CI) your patches and check if you can
> reproduce those errors?
I can reproduce this error with travis-CI. but i can't not reproduce
this rk3036 board error on my desktop.
can you try to local build rk3036 board and see if can reproduce this error?
>
> Best regards,
> Łukasz
>
>> >
>> >>
>> >> I've also updated my .travis.ml file to be in sync with mainline,
>> >> so we will use recommended arm toolchain.
>> >>
>> >> Please find this file attached.
>> >>
>> >> If there are any other patches required before applying this patch
>> >> series, please let me know (or better post them to ML).
>> >>
>> >>
>> >> Best regards,
>> >> Łukasz Majewski
>> >>
>> >> > >
>> >> > >> >
>> >> > >> > caused by "undefined references to "
>> >> > >> >
>> >> > >> > I've tried your patches on top of:
>> >> > >> > u-boot-usb/HEAD
>> >> > >> > SHA1: 3426b2038cfb831d74ac0407fc7a04e990b44540
>> >> > >> >
>> >> > >> > Maybe you have built tested it on other branch/commit?
>> >> > >> >
>> >> > >> > Best regards,
>> >> > >> > Łukasz Majewski
>> >> > >> >
>> >> > >> > p.s. 

Re: [U-Boot] [PATCH 10/16] usb: xhci: Program 'route string' in the input slot context

[Bin Meng]

Hi Stefan,

On Wed, Jun 28, 2017 at 8:27 PM, Bin Meng  wrote:
> Hi Stefan,
>
> On Wed, Jun 28, 2017 at 7:28 PM, Stefan Roese  wrote:
>> Hi Bin,
>>
>>
>> On 27.06.2017 10:27, Bin Meng wrote:
>>>
>>> Hi Stefan,
>>>
>>> On Tue, Jun 27, 2017 at 1:23 PM, Stefan Roese  wrote:

 Hi Bin,


 On 27.06.2017 02:01, Bin Meng wrote:
>
>
> On Tue, Jun 27, 2017 at 2:07 AM, Marek Vasut  wrote:
>>
>>
>> On 06/24/2017 03:57 AM, Bin Meng wrote:
>>>
>>>
>>> Hi Marek,
>>>
>>> On Sat, Jun 24, 2017 at 2:02 AM, Marek Vasut  wrote:


 On 06/23/2017 11:54 AM, Bin Meng wrote:
>
>
> xHCI spec says: the values of the 'route string' field shall be
> initialized by the first 'Address Device' command issued to a
> device slot, and shall not be modified by any other command.
>
> So far U-Boot does not program this field, and it does not prevent
> SS device directly attached to root port, or HS device behind an HS
> hub, from working, due to the fact that 'route string' is used by
> the xHC to target SS packets. But in order to enumerate devices
> behind an SS hub, this field must be programmed.
>
> With this commit and along with previous commits, now SS & HS
> devices
> attached to a USB 3.0 hub can be enumerated by U-Boot.
>
> As usual, this new feature is only available when DM is on.



 Great, but I really dislike the ifdef pollution, so this needs to be
 sorted out.
>>>
>>>
>>>
>>> The ifdef was needed due to it calls DM APIs or access DM udevice. I
>>> have no intention to add a new feature to the non-DM driver.
>>
>>
>>
>> But then this creates a massive disparity, it's like we're growing two
>> USB stacks.
>>
>
> Yep, unfortunately. But if we continue adding new features/fixes to
> the old non-DM stuff, I am not sure how this can encourage people to
> switch to DM.



 Correct. We definitely don't want to add new features to non-DM
 drivers / IF, if this is non-trivial.

> Maybe I can check all boards that use xHCI to see if
> they are switched to DM?



 xHCI is still quite new in U-Boot, so I would expect that all
 platforms using it, are using DM or at least not far away from using
 it. Yes, please check all xHCI "users", if they use DM. Then we
 know if and which users need some "persuasion" to switch over to
 DM soon. ;)
>>>
>>>
>>> I checked all boards that have CONFIG_USB_XHCI_HCD defined but without
>>> CONFIG_DM_USB. Here is the list.
>>>
>>> configs/uniphier_v8_defconfig:36:CONFIG_USB_XHCI_HCD=y
>>> configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig:62:CONFIG_USB_XHCI_HCD=y
>>> configs/am57xx_evm_nodt_defconfig:53:CONFIG_USB_XHCI_HCD=y
>>> configs/evb-rk3328_defconfig:34:CONFIG_USB_XHCI_HCD=y
>>> configs/ls1021atwr_nor_lpuart_defconfig:43:CONFIG_USB_XHCI_HCD=y
>>> configs/uniphier_pxs2_ld6b_defconfig:44:CONFIG_USB_XHCI_HCD=y
>>> configs/ls1012ardb_qspi_SECURE_BOOT_defconfig:43:CONFIG_USB_XHCI_HCD=y
>>>
>>> configs/ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig:57:CONFIG_USB_XHCI_HCD=y
>>> configs/k2e_hs_evm_defconfig:34:CONFIG_USB_XHCI_HCD=y
>>> configs/ls1021aqds_sdcard_qspi_defconfig:61:CONFIG_USB_XHCI_HCD=y
>>> configs/am43xx_evm_ethboot_defconfig:48:CONFIG_USB_XHCI_HCD=y
>>> configs/xilinx_zynqmp_ep_defconfig:70:CONFIG_USB_XHCI_HCD=y
>>> configs/ls1021aqds_nand_defconfig:57:CONFIG_USB_XHCI_HCD=y
>>> configs/ls1021atwr_qspi_defconfig:50:CONFIG_USB_XHCI_HCD=y
>>> configs/k2g_evm_defconfig:45:CONFIG_USB_XHCI_HCD=y
>>> configs/am57xx_evm_defconfig:63:CONFIG_USB_XHCI_HCD=y
>>> configs/am43xx_hs_evm_defconfig:49:CONFIG_USB_XHCI_HCD=y
>>> configs/am43xx_evm_defconfig:39:CONFIG_USB_XHCI_HCD=y
>>> configs/ls1021atwr_nor_defconfig:42:CONFIG_USB_XHCI_HCD=y
>>> configs/firefly-rk3399_defconfig:59:CONFIG_USB_XHCI_HCD=y
>>> configs/puma-rk3399_defconfig:78:CONFIG_USB_XHCI_HCD=y
>>> configs/cl-som-am57x_defconfig:55:CONFIG_USB_XHCI_HCD=y
>>> configs/ls1021aqds_nor_SECURE_BOOT_defconfig:43:CONFIG_USB_XHCI_HCD=y
>>> configs/uniphier_pro4_defconfig:43:CONFIG_USB_XHCI_HCD=y
>>> configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig:61:CONFIG_USB_XHCI_HCD=y
>>> configs/xilinx_zynqmp_zcu102_defconfig:63:CONFIG_USB_XHCI_HCD=y
>>> configs/ls1021atwr_nor_SECURE_BOOT_defconfig:42:CONFIG_USB_XHCI_HCD=y
>>> configs/cm_t43_defconfig:67:CONFIG_USB_XHCI_HCD=y
>>> configs/k2g_hs_evm_defconfig:36:CONFIG_USB_XHCI_HCD=y
>>> configs/am43xx_evm_qspiboot_defconfig:45:CONFIG_USB_XHCI_HCD=y
>>> configs/ls1021aqds_qspi_defconfig:50:CONFIG_USB_XHCI_HCD=y
>>> configs/am57xx_hs_evm_defconfig:67:CONFIG_USB_XHCI_HCD=y
>>> configs/xilinx_zynqmp_zcu102_revB_defconfig:63:CONFIG_USB_XHCI_HCD=y
>>> 

Re: [U-Boot] [PATCH 0/3] usb: xhci: Add interrupt transfer support

[Bin Meng]

+Simon

On Wed, Jun 28, 2017 at 7:00 PM, Stefan Roese  wrote:
> Hi Bin,
>
> On 26.06.2017 13:05, Bin Meng wrote:
>> This series is the final series of the xHCI driver update.
>>
>> This adds the missing interrupt transfer support to xHCI driver, so
>> that devices like USB keyboard that uses interrupt transfer when
>> CONFIG_SYS_USB_EVENT_POLL is defined can work.
>>
>> Previous two series:
>> [1]: usb: xhci: Fix USB xHCI support on Intel platform
>> https://lists.denx.de/pipermail/u-boot/2017-June/296166.html
>> [2]: usb: hub: Support USB 3.0 hubs
>> https://lists.denx.de/pipermail/u-boot/2017-June/296284.html
>>
>> This series is available at u-boot-x86/xhci-working3 for testing.
>
> I'm using this git branch to test all your xHCI related patches
> now. On my BayTrail platform I get these messages upon "usb reset"
> scanning:
>
> => usb reset
> resetting USB...
> USB0:   Register 7000820 NbrPorts 7
> Starting the controller
> USB XHCI 1.00
> scanning bus 0 for devices... cannot reset port 1!?
> USB device descriptor short read (expected 18, got 8)
> 5 USB Device(s) found
>scanning usb for storage devices... 1 Storage Device(s) found
>
> On the 2nd scan, the "cannot reset port 1" line is gone:
>
> => usb reset
> resetting USB...
> USB0:   Register 7000820 NbrPorts 7
> Starting the controller
> USB XHCI 1.00
> scanning bus 0 for devices... USB device descriptor short read (expected 18, 
> got 8)
> 5 USB Device(s) found
>scanning usb for storage devices... 1 Storage Device(s) found
>
> All USB devices seem to be detected correctly though. Here the
> logs:
>
> => usb tree
> USB device tree:
>   1  Hub (5 Gb/s, 0mA)
>   |  U-Boot XHCI Host Controller
>   |
>   +-2  Hub (480 Mb/s, 100mA)
>   |
>   +-3  Hub (480 Mb/s, 2mA)
>   | |
>   | +-5  Mass Storage (480 Mb/s, 200mA)
>   |  JetFlash Mass Storage Device 3281440601
>   |
>   +-4  Vendor specific (5 Gb/s, 64mA)
>Realtek USB 10/100/1000 LAN 0200
>
> => usb info
> 1: Hub,  USB Revision 3.0
>  - U-Boot XHCI Host Controller
>  - Class: Hub
>  - PacketSize: 512  Configurations: 1
>  - Vendor: 0x  Product 0x Version 1.0
>Configuration: 1
>- Interfaces: 1 Self Powered 0mA
>  Interface: 0
>  - Alternate Setting 0, Endpoints: 1
>  - Class Hub
>  - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms
>
> 2: Hub,  USB Revision 2.0
>  - Class: Hub
>  - PacketSize: 64  Configurations: 1
>  - Vendor: 0x0409  Product 0x005a Version 1.0
>Configuration: 1
>- Interfaces: 1 Self Powered Remote Wakeup 100mA
>  Interface: 0
>  - Alternate Setting 0, Endpoints: 1
>  - Class Hub
>  - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms
>
> 3: Hub,  USB Revision 2.1
>  - Class: Hub
>  - PacketSize: 64  Configurations: 1
>  - Vendor: 0x0424  Product 0x4604 Version 1.131
>Configuration: 1
>- Interfaces: 1 Self Powered Remote Wakeup 2mA
>  Interface: 0
>  - Alternate Setting 0, Endpoints: 1
>  - Class Hub
>  - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms
>  - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms
>
> 5: Mass Storage,  USB Revision 2.10
>  - JetFlash Mass Storage Device 3281440601
>  - Class: (from Interface) Mass Storage
>  - PacketSize: 64  Configurations: 1
>  - Vendor: 0x8564  Product 0x1000 Version 16.117
>Configuration: 1
>- Interfaces: 1 Bus Powered 200mA
>  Interface: 0
>  - Alternate Setting 0, Endpoints: 2
>  - Class Mass Storage, Transp. SCSI, Bulk only
>  - Endpoint 2 Out Bulk MaxPacket 512
>  - Endpoint 1 In Bulk MaxPacket 512
>
> 4: Vendor specific,  USB Revision 3.0
>  - Realtek USB 10/100/1000 LAN 0200
>  - Class: (from Interface) Vendor specific
>  - PacketSize: 512  Configurations: 2
>  - Vendor: 0x0bda  Product 0x8153 Version 48.0
>Configuration: 1
>- Interfaces: 1 Bus Powered Remote Wakeup 64mA
>  Interface: 0
>  - Alternate Setting 0, Endpoints: 3
>  - Class Vendor specific
>  - Endpoint 1 In Bulk MaxPacket 1024
>  - Endpoint 2 Out Bulk MaxPacket 1024
>  - Endpoint 3 In Interrupt MaxPacket 2 Interval 8ms
>
> Do you have any ideas about the scanning logs that I've noticed
> above? Would it help if I provided some debug logs (-DDEBUG)
> for this?
>
>
> BTW: I need to re-add the SYS_USB_EVENT_POLL* options back to
> the whilelist file. Otherwise compiling fails with this
> message:
>
> $ make minnowmax_defconfig
> $ make -s -j10
> Error: You must add new CONFIG options using Kconfig
> The following new ad-hoc CONFIG options were detected:
> CONFIG_SYS_USB_EVENT_POLL
>
> Please add these via Kconfig instead. Find a suitable Kconfig
> file and add a 'config' or 'menuconfig' option.
> Makefile:862: recipe for target 'all' failed
>
> Don't you see this error? Any idea whats going wrong here?

Simon,

Do you know why this error was generated? CONFIG_SYS_USB_EVENT_POLL
was already a Kconfig option.

Regards,
Bin
___

[U-Boot] [PATCH] net: tftp: silence a subscript above array bounds compile time warning

[Vladimir Zapolskiy]

For strncpy() select a minimal string length of destination and source
strings, here DEFAULT_NAME_LEN is preferable to MAX_LEN.

Due to the NUL-terminated contents of default_string the change is
a noop, however it removes a compilation warning if SH2/3/4 platform
specific strncpy() function is used:

  In file included from include/linux/string.h:21:0,
   from include/common.h:28,
   from net/tftp.c:9:

  net/tftp.c: In function 'tftp_start':
  arch/sh/include/asm/string.h:52:42: warning: array subscript is above array 
bounds [-Warray-bounds]
 : "0" (__dest), "1" (__src), "r" (__src+__n)

Signed-off-by: Vladimir Zapolskiy 
---
 net/tftp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/tftp.c b/net/tftp.c
index ced45ec..61e1671 100644
--- a/net/tftp.c
+++ b/net/tftp.c
@@ -742,8 +742,8 @@ void tftp_start(enum proto_t protocol)
(net_ip.s_addr >> 16) & 0xFF,
(net_ip.s_addr >> 24) & 0xFF);
 
-   strncpy(tftp_filename, default_filename, MAX_LEN);
-   tftp_filename[MAX_LEN - 1] = 0;
+   strncpy(tftp_filename, default_filename, DEFAULT_NAME_LEN);
+   tftp_filename[DEFAULT_NAME_LEN - 1] = 0;
 
printf("*** Warning: no boot file name; using '%s'\n",
   tftp_filename);
-- 
2.10.2

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] mkimage: fix display of image types list

[Baruch Siach]

Since commit 5b9d44df2307f (mkimage: Display a better list of available image
types) mkimage usage text suggest to "use -T to see a list of available image
types". Unfortunately, commit 02221f29deb8 (mkimage: Convert to use getopt())
broke that feature, because getopt() fails when -T has no option argument.

Make the -T option argument optional to restore the original behaviour.

Cc: Simon Glass 
Signed-off-by: Baruch Siach 
---
 tools/mkimage.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/tools/mkimage.c b/tools/mkimage.c
index d982bc5665f1..2c7801e8f836 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -144,7 +144,7 @@ static void process_args(int argc, char **argv)
int opt;
 
while ((opt = getopt(argc, argv,
-"a:A:b:c:C:d:D:e:Ef:Fk:i:K:ln:N:p:O:rR:qsT:vVx")) 
!= -1) {
+"a:A:b:c:C:d:D:e:Ef:Fk:i:K:ln:N:p:O:rR:qsT::vVx")) 
!= -1) {
switch (opt) {
case 'a':
params.addr = strtoull(optarg, , 16);
@@ -260,8 +260,9 @@ static void process_args(int argc, char **argv)
params.skipcpy = 1;
break;
case 'T':
-   type = genimg_get_type_id(optarg);
-   if (type < 0) {
+   if (optarg)
+   type = genimg_get_type_id(optarg);
+   if (optarg == NULL || type < 0) {
show_valid_options(IH_TYPE);
usage("Invalid image type");
}
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] ARM: Running U-boot on Raspberry Pi Zero W

[Grigory Emelyanov]

Hi

We are trying to run U-Boot on the Raspberry Pi Zero W. But all our
attempts have
finished at rainbow screen. During our experiments we have been following
an
instructions from (with a different config file, configs/rpi_defconfig).

http://ltekieli.com/buildroot-with-raspberry-pi-u-boot/

Also we have tried a method from

http://www.embeddedforu.com/embedded-linux/raspberry-pi/how-to-compile-mainline-u-boot-for-raspberry-pi/

However we have got the same result in both cases. At the same time we
don't
have any problem with Raspbery Pi 3 (with a different config file
configs/rpi_3_32b_defconfig).

We are using buildroot 2017.05 which contains U-boot 2017.03.

Thanks in advance,

*Grigory E**melyanov*
Hardware Engineer
[image: Logo]

OMBEA AB | Torbjörn Klockares g. 14 | 113 30 Stockholm | Sweden
OMBEA Ltd. | 71-75 Shelton Street | London WC2H 9JQ | United Kingdom
OMBEA USA, Inc. | PO Box 232 Warren | Ohio 44482-0590 | United States
More offices 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 07/16] usb: hub: Translate USB 3.0 hub port status into old version

[Marek Vasut]

On 06/28/2017 10:28 AM, Bin Meng wrote:
> Hi Marek,
> 
> On Tue, Jun 27, 2017 at 7:57 AM, Bin Meng  wrote:
>> Hi Marek,
>>
>> On Tue, Jun 27, 2017 at 2:06 AM, Marek Vasut  wrote:
>>> On 06/24/2017 03:53 AM, Bin Meng wrote:
 Hi Marek,

 On Sat, Jun 24, 2017 at 1:59 AM, Marek Vasut  wrote:
> On 06/23/2017 11:54 AM, Bin Meng wrote:
>> USB 3.0 hub port status field has different bit positions from 2.0
>> hubs. Since U-Boot only understands the old version, translate the
>> new one into the old one.
>
> This is quite hairy. I'd rather see some protocol version agnostic flag
> field rather than patching the wPortStatus and co.
>

 I am not sure how do do that in a clean way. If we return the raw 3.0
 hub port status data, that means we need change lot of hub codes here
 and there to do different parsing.
>>>
>>> How does Linux handle this?
>>
>> Looks Linux is doing different parsing depending on hub is 3.0 or 2.0,
>> at least for the power bit that I was just looking at. Do you want to
>> do that?
> 
> OK, I will do something similar like Linux in v2.

Thanks

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

[U-Boot] [PATCH] ti816x: Enable ethernet support

[Tom Rini]

The ti816x SoC revision of the ethernet IP block is handled by the
"davinci_emac" driver, rather than the "cpsw" driver as done by later
members of the family.  Enable the relevant plumbing.

Signed-off-by: Sriramakrishnan 
Signed-off-by: Vitaly Wool 
Signed-off-by: Tom Rini 
---
 arch/arm/include/asm/arch-am33xx/emac_defs.h   | 38 ++
 arch/arm/include/asm/arch-am33xx/hardware_ti816x.h |  1 +
 board/ti/ti816x/evm.c  | 28 ++
 configs/ti816x_evm_defconfig   |  5 ++
 drivers/net/davinci_emac.c | 60 ++
 drivers/net/davinci_emac.h |  2 +
 include/configs/ti816x_evm.h   |  9 
 7 files changed, 122 insertions(+), 21 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-am33xx/emac_defs.h

diff --git a/arch/arm/include/asm/arch-am33xx/emac_defs.h 
b/arch/arm/include/asm/arch-am33xx/emac_defs.h
new file mode 100644
index ..b5703f710f42
--- /dev/null
+++ b/arch/arm/include/asm/arch-am33xx/emac_defs.h
@@ -0,0 +1,38 @@
+/*
+ * Copyright (C) 2010 Texas Instruments
+ *
+ * Based on:
+ *
+ * 
+ *
+ * dm644x_emac.h
+ *
+ * TI DaVinci (DM644X) EMAC peripheral driver header for DV-EVM
+ *
+ * Copyright (C) 2005 Texas Instruments.
+ *
+ * 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ *
+ */
+
+#ifndef _EMAC_DEFS_H_
+#define _EMAC_DEFS_H_
+
+#ifdef CONFIG_TI816X
+#define EMAC_BASE_ADDR (0x4A10)
+#define EMAC_WRAPPER_BASE_ADDR (0x4A100900)
+#define EMAC_WRAPPER_RAM_ADDR  (0x4A102000)
+#define EMAC_MDIO_BASE_ADDR(0x4A100800)
+#define EMAC_MDIO_BUS_FREQ (25000UL)
+#define EMAC_MDIO_CLOCK_FREQ   (200UL)
+
+typedef volatile unsigned int  dv_reg;
+typedef volatile unsigned int  *dv_reg_p;
+
+#define DAVINCI_EMAC_VERSION2
+#define DAVINCI_EMAC_GIG_ENABLE
+#endif
+
+#endif  /* _EMAC_DEFS_H_ */
diff --git a/arch/arm/include/asm/arch-am33xx/hardware_ti816x.h 
b/arch/arm/include/asm/arch-am33xx/hardware_ti816x.h
index 3c680649abfa..78b79486ed47 100644
--- a/arch/arm/include/asm/arch-am33xx/hardware_ti816x.h
+++ b/arch/arm/include/asm/arch-am33xx/hardware_ti816x.h
@@ -31,6 +31,7 @@
 
 /* Control Module Base Address */
 #define CTRL_BASE  0x4814
+#define CTRL_DEVICE_BASE   0x48140600
 
 /* PRCM Base Address */
 #define PRCM_BASE  0x4818
diff --git a/board/ti/ti816x/evm.c b/board/ti/ti816x/evm.c
index 577e60f875f4..9d6c3d6b5dc9 100644
--- a/board/ti/ti816x/evm.c
+++ b/board/ti/ti816x/evm.c
@@ -9,6 +9,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -31,6 +32,33 @@ int board_init(void)
return 0;
 }
 
+int board_eth_init(bd_t *bis)
+{
+   uint8_t mac_addr[6];
+   uint32_t mac_hi, mac_lo;
+   struct ctrl_dev *cdev = (struct ctrl_dev *)CTRL_DEVICE_BASE;
+
+   if (!eth_getenv_enetaddr("ethaddr", mac_addr)) {
+   printf(" not set. Reading from E-fuse\n");
+   /* try reading mac address from efuse */
+   mac_lo = readl(>macid0l);
+   mac_hi = readl(>macid0h);
+   mac_addr[0] = mac_hi & 0xFF;
+   mac_addr[1] = (mac_hi & 0xFF00) >> 8;
+   mac_addr[2] = (mac_hi & 0xFF) >> 16;
+   mac_addr[3] = (mac_hi & 0xFF00) >> 24;
+   mac_addr[4] = mac_lo & 0xFF;
+   mac_addr[5] = (mac_lo & 0xFF00) >> 8;
+
+   if (is_valid_ethaddr(mac_addr))
+   eth_setenv_enetaddr("ethaddr", mac_addr);
+   else
+   printf("Unable to read MAC address. Set \n");
+   }
+
+   return davinci_emac_initialize();
+}
+
 #ifdef CONFIG_SPL_BUILD
 static struct module_pin_mux mmc_pin_mux[] = {
{ OFFSET(pincntl157), PULLDOWN_EN | PULLUDDIS | MODE(0x0) },
diff --git a/configs/ti816x_evm_defconfig b/configs/ti816x_evm_defconfig
index 1c6608218b00..7f43ecb7ebc2 100644
--- a/configs/ti816x_evm_defconfig
+++ b/configs/ti816x_evm_defconfig
@@ -35,6 +35,11 @@ CONFIG_OF_CONTROL=y
 CONFIG_DM=y
 CONFIG_DM_GPIO=y
 CONFIG_DM_I2C=y
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_FAT=y
 CONFIG_MMC_OMAP_HS=y
 CONFIG_SYS_NS16550=y
 # CONFIG_USE_PRIVATE_LIBGCC is not set
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 5e7ebc8a99f3..d1024879a0ef 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -341,6 +341,14 @@ static int gen_auto_negotiate(int phy_addr)
if (!davinci_eth_phy_read(phy_addr, MII_BMCR, ))
return(0);
 
+#ifdef DAVINCI_EMAC_GIG_ENABLE
+   davinci_eth_phy_read(phy_addr, MII_CTRL1000, );
+   val |= PHY_1000BTCR_1000FD;
+ 

Re: [U-Boot] [PATCH 1/1] Set VLD04 output to 2.8V in PMIC initialization.

[Fabio Estevam]

Hi Gautam,

On Tue, Jun 27, 2017 at 11:32 PM, mind entropy  wrote:

> Hi Fabio,
>
> The patch for the kernel was supposed to be next. Should I send the kernel
> patch to mainline or some place else?

Do you have MIPI DSI working in mainline kernel? If you do, please
share the patches.

You can use ./scripts/get_maintainer.pl to get the people and lists to
put on Cc.

> Coming to u-boot, the fact that even if there is no MIPI DSI/MIPI CSI
> support the voltage would still be 3.3V in those rails. In my case I do not
> attach the display after u-boot boots up. I keep the display attached and
> sometimes I leave it in u-boot command line without going over to the
> kernel. Since this is a development board this is often the case for many
> developers and there may be chances of the display getting damaged.

It makes sense now. Please send a v2 with the following changes:

1.  Add mx7dsabresd to the Subject, so that it becomes: mx7dsabresd:
Set VLD04 output to 2.8V

2. Explain in the commit message why you are doing such change, just
like you did above, where you explain that the default LDO4 output is
3.3V and that is beyond the MIPI DSI spec.

3. Remove the extra parentesis (0xF): regval &= ~0xF; is enough.

Thanks
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] usb: xhci: Add interrupt transfer support

[Stefan Roese]

Hi Bin,

On 28.06.2017 14:11, Bin Meng wrote:
> On Wed, Jun 28, 2017 at 7:00 PM, Stefan Roese  wrote:
>> Hi Bin,
>>
>> On 26.06.2017 13:05, Bin Meng wrote:
>>> This series is the final series of the xHCI driver update.
>>>
>>> This adds the missing interrupt transfer support to xHCI driver, so
>>> that devices like USB keyboard that uses interrupt transfer when
>>> CONFIG_SYS_USB_EVENT_POLL is defined can work.
>>>
>>> Previous two series:
>>> [1]: usb: xhci: Fix USB xHCI support on Intel platform
>>> https://lists.denx.de/pipermail/u-boot/2017-June/296166.html
>>> [2]: usb: hub: Support USB 3.0 hubs
>>> https://lists.denx.de/pipermail/u-boot/2017-June/296284.html
>>>
>>> This series is available at u-boot-x86/xhci-working3 for testing.
>>
>> I'm using this git branch to test all your xHCI related patches
>> now. On my BayTrail platform I get these messages upon "usb reset"
>> scanning:
>>
>> => usb reset
>> resetting USB...
>> USB0:   Register 7000820 NbrPorts 7
>> Starting the controller
>> USB XHCI 1.00
>> scanning bus 0 for devices... cannot reset port 1!?
>> USB device descriptor short read (expected 18, got 8)
>> 5 USB Device(s) found
>> scanning usb for storage devices... 1 Storage Device(s) found
>>
>> On the 2nd scan, the "cannot reset port 1" line is gone:
>>
>> => usb reset
>> resetting USB...
>> USB0:   Register 7000820 NbrPorts 7
>> Starting the controller
>> USB XHCI 1.00
>> scanning bus 0 for devices... USB device descriptor short read (expected 18, 
>> got 8)
>> 5 USB Device(s) found
>> scanning usb for storage devices... 1 Storage Device(s) found
>>
>> All USB devices seem to be detected correctly though. Here the
>> logs:
>>
>> => usb tree
>> USB device tree:
>>1  Hub (5 Gb/s, 0mA)
>>|  U-Boot XHCI Host Controller
>>|
>>+-2  Hub (480 Mb/s, 100mA)
>>|
>>+-3  Hub (480 Mb/s, 2mA)
>>| |
>>| +-5  Mass Storage (480 Mb/s, 200mA)
>>|  JetFlash Mass Storage Device 3281440601
>>|
>>+-4  Vendor specific (5 Gb/s, 64mA)
>> Realtek USB 10/100/1000 LAN 0200
>>
>> => usb info
>> 1: Hub,  USB Revision 3.0
>>   - U-Boot XHCI Host Controller
>>   - Class: Hub
>>   - PacketSize: 512  Configurations: 1
>>   - Vendor: 0x  Product 0x Version 1.0
>> Configuration: 1
>> - Interfaces: 1 Self Powered 0mA
>>   Interface: 0
>>   - Alternate Setting 0, Endpoints: 1
>>   - Class Hub
>>   - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms
>>
>> 2: Hub,  USB Revision 2.0
>>   - Class: Hub
>>   - PacketSize: 64  Configurations: 1
>>   - Vendor: 0x0409  Product 0x005a Version 1.0
>> Configuration: 1
>> - Interfaces: 1 Self Powered Remote Wakeup 100mA
>>   Interface: 0
>>   - Alternate Setting 0, Endpoints: 1
>>   - Class Hub
>>   - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms
>>
>> 3: Hub,  USB Revision 2.1
>>   - Class: Hub
>>   - PacketSize: 64  Configurations: 1
>>   - Vendor: 0x0424  Product 0x4604 Version 1.131
>> Configuration: 1
>> - Interfaces: 1 Self Powered Remote Wakeup 2mA
>>   Interface: 0
>>   - Alternate Setting 0, Endpoints: 1
>>   - Class Hub
>>   - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms
>>   - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms
>>
>> 5: Mass Storage,  USB Revision 2.10
>>   - JetFlash Mass Storage Device 3281440601
>>   - Class: (from Interface) Mass Storage
>>   - PacketSize: 64  Configurations: 1
>>   - Vendor: 0x8564  Product 0x1000 Version 16.117
>> Configuration: 1
>> - Interfaces: 1 Bus Powered 200mA
>>   Interface: 0
>>   - Alternate Setting 0, Endpoints: 2
>>   - Class Mass Storage, Transp. SCSI, Bulk only
>>   - Endpoint 2 Out Bulk MaxPacket 512
>>   - Endpoint 1 In Bulk MaxPacket 512
>>
>> 4: Vendor specific,  USB Revision 3.0
>>   - Realtek USB 10/100/1000 LAN 0200
>>   - Class: (from Interface) Vendor specific
>>   - PacketSize: 512  Configurations: 2
>>   - Vendor: 0x0bda  Product 0x8153 Version 48.0
>> Configuration: 1
>> - Interfaces: 1 Bus Powered Remote Wakeup 64mA
>>   Interface: 0
>>   - Alternate Setting 0, Endpoints: 3
>>   - Class Vendor specific
>>   - Endpoint 1 In Bulk MaxPacket 1024
>>   - Endpoint 2 Out Bulk MaxPacket 1024
>>   - Endpoint 3 In Interrupt MaxPacket 2 Interval 8ms
>>
>> Do you have any ideas about the scanning logs that I've noticed
>> above? Would it help if I provided some debug logs (-DDEBUG)
>> for this?
> 
> "cannot reset port 1" message is annoying, but that may happen
> sometimes due to unstable power supply. I will see if we can mute it
> if it's not the final round of reset try.

That would be good, thanks.

> I am more concerned about
> the "USB device descriptor short read (expected 18, got 8)". This
> message indicates U-Boot cannot get the device descriptor during set
> configuration process. So did you manage to get all USB devices that
> are connected on your board 

Re: [U-Boot] [PATCH 10/16] usb: xhci: Program 'route string' in the input slot context

[Bin Meng]

Hi Stefan,

On Wed, Jun 28, 2017 at 7:28 PM, Stefan Roese  wrote:
> Hi Bin,
>
>
> On 27.06.2017 10:27, Bin Meng wrote:
>>
>> Hi Stefan,
>>
>> On Tue, Jun 27, 2017 at 1:23 PM, Stefan Roese  wrote:
>>>
>>> Hi Bin,
>>>
>>>
>>> On 27.06.2017 02:01, Bin Meng wrote:


 On Tue, Jun 27, 2017 at 2:07 AM, Marek Vasut  wrote:
>
>
> On 06/24/2017 03:57 AM, Bin Meng wrote:
>>
>>
>> Hi Marek,
>>
>> On Sat, Jun 24, 2017 at 2:02 AM, Marek Vasut  wrote:
>>>
>>>
>>> On 06/23/2017 11:54 AM, Bin Meng wrote:


 xHCI spec says: the values of the 'route string' field shall be
 initialized by the first 'Address Device' command issued to a
 device slot, and shall not be modified by any other command.

 So far U-Boot does not program this field, and it does not prevent
 SS device directly attached to root port, or HS device behind an HS
 hub, from working, due to the fact that 'route string' is used by
 the xHC to target SS packets. But in order to enumerate devices
 behind an SS hub, this field must be programmed.

 With this commit and along with previous commits, now SS & HS
 devices
 attached to a USB 3.0 hub can be enumerated by U-Boot.

 As usual, this new feature is only available when DM is on.
>>>
>>>
>>>
>>> Great, but I really dislike the ifdef pollution, so this needs to be
>>> sorted out.
>>
>>
>>
>> The ifdef was needed due to it calls DM APIs or access DM udevice. I
>> have no intention to add a new feature to the non-DM driver.
>
>
>
> But then this creates a massive disparity, it's like we're growing two
> USB stacks.
>

 Yep, unfortunately. But if we continue adding new features/fixes to
 the old non-DM stuff, I am not sure how this can encourage people to
 switch to DM.
>>>
>>>
>>>
>>> Correct. We definitely don't want to add new features to non-DM
>>> drivers / IF, if this is non-trivial.
>>>
 Maybe I can check all boards that use xHCI to see if
 they are switched to DM?
>>>
>>>
>>>
>>> xHCI is still quite new in U-Boot, so I would expect that all
>>> platforms using it, are using DM or at least not far away from using
>>> it. Yes, please check all xHCI "users", if they use DM. Then we
>>> know if and which users need some "persuasion" to switch over to
>>> DM soon. ;)
>>
>>
>> I checked all boards that have CONFIG_USB_XHCI_HCD defined but without
>> CONFIG_DM_USB. Here is the list.
>>
>> configs/uniphier_v8_defconfig:36:CONFIG_USB_XHCI_HCD=y
>> configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig:62:CONFIG_USB_XHCI_HCD=y
>> configs/am57xx_evm_nodt_defconfig:53:CONFIG_USB_XHCI_HCD=y
>> configs/evb-rk3328_defconfig:34:CONFIG_USB_XHCI_HCD=y
>> configs/ls1021atwr_nor_lpuart_defconfig:43:CONFIG_USB_XHCI_HCD=y
>> configs/uniphier_pxs2_ld6b_defconfig:44:CONFIG_USB_XHCI_HCD=y
>> configs/ls1012ardb_qspi_SECURE_BOOT_defconfig:43:CONFIG_USB_XHCI_HCD=y
>>
>> configs/ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig:57:CONFIG_USB_XHCI_HCD=y
>> configs/k2e_hs_evm_defconfig:34:CONFIG_USB_XHCI_HCD=y
>> configs/ls1021aqds_sdcard_qspi_defconfig:61:CONFIG_USB_XHCI_HCD=y
>> configs/am43xx_evm_ethboot_defconfig:48:CONFIG_USB_XHCI_HCD=y
>> configs/xilinx_zynqmp_ep_defconfig:70:CONFIG_USB_XHCI_HCD=y
>> configs/ls1021aqds_nand_defconfig:57:CONFIG_USB_XHCI_HCD=y
>> configs/ls1021atwr_qspi_defconfig:50:CONFIG_USB_XHCI_HCD=y
>> configs/k2g_evm_defconfig:45:CONFIG_USB_XHCI_HCD=y
>> configs/am57xx_evm_defconfig:63:CONFIG_USB_XHCI_HCD=y
>> configs/am43xx_hs_evm_defconfig:49:CONFIG_USB_XHCI_HCD=y
>> configs/am43xx_evm_defconfig:39:CONFIG_USB_XHCI_HCD=y
>> configs/ls1021atwr_nor_defconfig:42:CONFIG_USB_XHCI_HCD=y
>> configs/firefly-rk3399_defconfig:59:CONFIG_USB_XHCI_HCD=y
>> configs/puma-rk3399_defconfig:78:CONFIG_USB_XHCI_HCD=y
>> configs/cl-som-am57x_defconfig:55:CONFIG_USB_XHCI_HCD=y
>> configs/ls1021aqds_nor_SECURE_BOOT_defconfig:43:CONFIG_USB_XHCI_HCD=y
>> configs/uniphier_pro4_defconfig:43:CONFIG_USB_XHCI_HCD=y
>> configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig:61:CONFIG_USB_XHCI_HCD=y
>> configs/xilinx_zynqmp_zcu102_defconfig:63:CONFIG_USB_XHCI_HCD=y
>> configs/ls1021atwr_nor_SECURE_BOOT_defconfig:42:CONFIG_USB_XHCI_HCD=y
>> configs/cm_t43_defconfig:67:CONFIG_USB_XHCI_HCD=y
>> configs/k2g_hs_evm_defconfig:36:CONFIG_USB_XHCI_HCD=y
>> configs/am43xx_evm_qspiboot_defconfig:45:CONFIG_USB_XHCI_HCD=y
>> configs/ls1021aqds_qspi_defconfig:50:CONFIG_USB_XHCI_HCD=y
>> configs/am57xx_hs_evm_defconfig:67:CONFIG_USB_XHCI_HCD=y
>> configs/xilinx_zynqmp_zcu102_revB_defconfig:63:CONFIG_USB_XHCI_HCD=y
>> configs/ls1021aqds_sdcard_ifc_defconfig:55:CONFIG_USB_XHCI_HCD=y
>> configs/uniphier_ld20_defconfig:39:CONFIG_USB_XHCI_HCD=y
>> configs/am43xx_evm_usbhost_boot_defconfig:61:CONFIG_USB_XHCI_HCD=y
>> 

Re: [U-Boot] [PATCH 0/3] usb: xhci: Add interrupt transfer support

[Bin Meng]

Hi Stefan,

On Wed, Jun 28, 2017 at 7:00 PM, Stefan Roese  wrote:
> Hi Bin,
>
> On 26.06.2017 13:05, Bin Meng wrote:
>> This series is the final series of the xHCI driver update.
>>
>> This adds the missing interrupt transfer support to xHCI driver, so
>> that devices like USB keyboard that uses interrupt transfer when
>> CONFIG_SYS_USB_EVENT_POLL is defined can work.
>>
>> Previous two series:
>> [1]: usb: xhci: Fix USB xHCI support on Intel platform
>> https://lists.denx.de/pipermail/u-boot/2017-June/296166.html
>> [2]: usb: hub: Support USB 3.0 hubs
>> https://lists.denx.de/pipermail/u-boot/2017-June/296284.html
>>
>> This series is available at u-boot-x86/xhci-working3 for testing.
>
> I'm using this git branch to test all your xHCI related patches
> now. On my BayTrail platform I get these messages upon "usb reset"
> scanning:
>
> => usb reset
> resetting USB...
> USB0:   Register 7000820 NbrPorts 7
> Starting the controller
> USB XHCI 1.00
> scanning bus 0 for devices... cannot reset port 1!?
> USB device descriptor short read (expected 18, got 8)
> 5 USB Device(s) found
>scanning usb for storage devices... 1 Storage Device(s) found
>
> On the 2nd scan, the "cannot reset port 1" line is gone:
>
> => usb reset
> resetting USB...
> USB0:   Register 7000820 NbrPorts 7
> Starting the controller
> USB XHCI 1.00
> scanning bus 0 for devices... USB device descriptor short read (expected 18, 
> got 8)
> 5 USB Device(s) found
>scanning usb for storage devices... 1 Storage Device(s) found
>
> All USB devices seem to be detected correctly though. Here the
> logs:
>
> => usb tree
> USB device tree:
>   1  Hub (5 Gb/s, 0mA)
>   |  U-Boot XHCI Host Controller
>   |
>   +-2  Hub (480 Mb/s, 100mA)
>   |
>   +-3  Hub (480 Mb/s, 2mA)
>   | |
>   | +-5  Mass Storage (480 Mb/s, 200mA)
>   |  JetFlash Mass Storage Device 3281440601
>   |
>   +-4  Vendor specific (5 Gb/s, 64mA)
>Realtek USB 10/100/1000 LAN 0200
>
> => usb info
> 1: Hub,  USB Revision 3.0
>  - U-Boot XHCI Host Controller
>  - Class: Hub
>  - PacketSize: 512  Configurations: 1
>  - Vendor: 0x  Product 0x Version 1.0
>Configuration: 1
>- Interfaces: 1 Self Powered 0mA
>  Interface: 0
>  - Alternate Setting 0, Endpoints: 1
>  - Class Hub
>  - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms
>
> 2: Hub,  USB Revision 2.0
>  - Class: Hub
>  - PacketSize: 64  Configurations: 1
>  - Vendor: 0x0409  Product 0x005a Version 1.0
>Configuration: 1
>- Interfaces: 1 Self Powered Remote Wakeup 100mA
>  Interface: 0
>  - Alternate Setting 0, Endpoints: 1
>  - Class Hub
>  - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms
>
> 3: Hub,  USB Revision 2.1
>  - Class: Hub
>  - PacketSize: 64  Configurations: 1
>  - Vendor: 0x0424  Product 0x4604 Version 1.131
>Configuration: 1
>- Interfaces: 1 Self Powered Remote Wakeup 2mA
>  Interface: 0
>  - Alternate Setting 0, Endpoints: 1
>  - Class Hub
>  - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms
>  - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms
>
> 5: Mass Storage,  USB Revision 2.10
>  - JetFlash Mass Storage Device 3281440601
>  - Class: (from Interface) Mass Storage
>  - PacketSize: 64  Configurations: 1
>  - Vendor: 0x8564  Product 0x1000 Version 16.117
>Configuration: 1
>- Interfaces: 1 Bus Powered 200mA
>  Interface: 0
>  - Alternate Setting 0, Endpoints: 2
>  - Class Mass Storage, Transp. SCSI, Bulk only
>  - Endpoint 2 Out Bulk MaxPacket 512
>  - Endpoint 1 In Bulk MaxPacket 512
>
> 4: Vendor specific,  USB Revision 3.0
>  - Realtek USB 10/100/1000 LAN 0200
>  - Class: (from Interface) Vendor specific
>  - PacketSize: 512  Configurations: 2
>  - Vendor: 0x0bda  Product 0x8153 Version 48.0
>Configuration: 1
>- Interfaces: 1 Bus Powered Remote Wakeup 64mA
>  Interface: 0
>  - Alternate Setting 0, Endpoints: 3
>  - Class Vendor specific
>  - Endpoint 1 In Bulk MaxPacket 1024
>  - Endpoint 2 Out Bulk MaxPacket 1024
>  - Endpoint 3 In Interrupt MaxPacket 2 Interval 8ms
>
> Do you have any ideas about the scanning logs that I've noticed
> above? Would it help if I provided some debug logs (-DDEBUG)
> for this?

"cannot reset port 1" message is annoying, but that may happen
sometimes due to unstable power supply. I will see if we can mute it
if it's not the final round of reset try. I am more concerned about
the "USB device descriptor short read (expected 18, got 8)". This
message indicates U-Boot cannot get the device descriptor during set
configuration process. So did you manage to get all USB devices that
are connected on your board enumerated?

>
> BTW: I need to re-add the SYS_USB_EVENT_POLL* options back to
> the whilelist file. Otherwise compiling fails with this
> message:
>
> $ make minnowmax_defconfig
> $ make -s -j10
> Error: You must add new CONFIG options using Kconfig
> The following new ad-hoc CONFIG 

Re: [U-Boot] [PATCH v8 4/8] rockchip: configs: rk3328: enable dwc2 driver and config fastboot

[rock-chips(daniel.meng)]

On 2017/6/28 19:55, Dr. Philipp Tomsich wrote:

On 28 Jun 2017, at 13:22, Meng Dongyang  wrote:

Config dwc2 driver support host and gadget function. Add support
of fastboot function.

Signed-off-by: Meng Dongyang 
Acked-by: Philipp Tomsich 

Reviewed-by: Philipp Tomsich 

I’ll migrate the remaining uses of CONFIG_USB_DWC2, when I apply.


OK, thanks



Regards,
Philipp.







___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v8 4/8] rockchip: configs: rk3328: enable dwc2 driver and config fastboot

[Dr. Philipp Tomsich]

> On 28 Jun 2017, at 13:22, Meng Dongyang  wrote:
> 
> Config dwc2 driver support host and gadget function. Add support
> of fastboot function.
> 
> Signed-off-by: Meng Dongyang 
> Acked-by: Philipp Tomsich 

Reviewed-by: Philipp Tomsich 

I’ll migrate the remaining uses of CONFIG_USB_DWC2, when I apply.

Regards,
Philipp.

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 10/16] usb: xhci: Program 'route string' in the input slot context

[Stefan Roese]

Hi Bin,

On 27.06.2017 10:27, Bin Meng wrote:

Hi Stefan,

On Tue, Jun 27, 2017 at 1:23 PM, Stefan Roese  wrote:

Hi Bin,


On 27.06.2017 02:01, Bin Meng wrote:


On Tue, Jun 27, 2017 at 2:07 AM, Marek Vasut  wrote:


On 06/24/2017 03:57 AM, Bin Meng wrote:


Hi Marek,

On Sat, Jun 24, 2017 at 2:02 AM, Marek Vasut  wrote:


On 06/23/2017 11:54 AM, Bin Meng wrote:


xHCI spec says: the values of the 'route string' field shall be
initialized by the first 'Address Device' command issued to a
device slot, and shall not be modified by any other command.

So far U-Boot does not program this field, and it does not prevent
SS device directly attached to root port, or HS device behind an HS
hub, from working, due to the fact that 'route string' is used by
the xHC to target SS packets. But in order to enumerate devices
behind an SS hub, this field must be programmed.

With this commit and along with previous commits, now SS & HS devices
attached to a USB 3.0 hub can be enumerated by U-Boot.

As usual, this new feature is only available when DM is on.



Great, but I really dislike the ifdef pollution, so this needs to be
sorted out.



The ifdef was needed due to it calls DM APIs or access DM udevice. I
have no intention to add a new feature to the non-DM driver.



But then this creates a massive disparity, it's like we're growing two
USB stacks.



Yep, unfortunately. But if we continue adding new features/fixes to
the old non-DM stuff, I am not sure how this can encourage people to
switch to DM.



Correct. We definitely don't want to add new features to non-DM
drivers / IF, if this is non-trivial.


Maybe I can check all boards that use xHCI to see if
they are switched to DM?



xHCI is still quite new in U-Boot, so I would expect that all
platforms using it, are using DM or at least not far away from using
it. Yes, please check all xHCI "users", if they use DM. Then we
know if and which users need some "persuasion" to switch over to
DM soon. ;)


I checked all boards that have CONFIG_USB_XHCI_HCD defined but without
CONFIG_DM_USB. Here is the list.

configs/uniphier_v8_defconfig:36:CONFIG_USB_XHCI_HCD=y
configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig:62:CONFIG_USB_XHCI_HCD=y
configs/am57xx_evm_nodt_defconfig:53:CONFIG_USB_XHCI_HCD=y
configs/evb-rk3328_defconfig:34:CONFIG_USB_XHCI_HCD=y
configs/ls1021atwr_nor_lpuart_defconfig:43:CONFIG_USB_XHCI_HCD=y
configs/uniphier_pxs2_ld6b_defconfig:44:CONFIG_USB_XHCI_HCD=y
configs/ls1012ardb_qspi_SECURE_BOOT_defconfig:43:CONFIG_USB_XHCI_HCD=y
configs/ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig:57:CONFIG_USB_XHCI_HCD=y
configs/k2e_hs_evm_defconfig:34:CONFIG_USB_XHCI_HCD=y
configs/ls1021aqds_sdcard_qspi_defconfig:61:CONFIG_USB_XHCI_HCD=y
configs/am43xx_evm_ethboot_defconfig:48:CONFIG_USB_XHCI_HCD=y
configs/xilinx_zynqmp_ep_defconfig:70:CONFIG_USB_XHCI_HCD=y
configs/ls1021aqds_nand_defconfig:57:CONFIG_USB_XHCI_HCD=y
configs/ls1021atwr_qspi_defconfig:50:CONFIG_USB_XHCI_HCD=y
configs/k2g_evm_defconfig:45:CONFIG_USB_XHCI_HCD=y
configs/am57xx_evm_defconfig:63:CONFIG_USB_XHCI_HCD=y
configs/am43xx_hs_evm_defconfig:49:CONFIG_USB_XHCI_HCD=y
configs/am43xx_evm_defconfig:39:CONFIG_USB_XHCI_HCD=y
configs/ls1021atwr_nor_defconfig:42:CONFIG_USB_XHCI_HCD=y
configs/firefly-rk3399_defconfig:59:CONFIG_USB_XHCI_HCD=y
configs/puma-rk3399_defconfig:78:CONFIG_USB_XHCI_HCD=y
configs/cl-som-am57x_defconfig:55:CONFIG_USB_XHCI_HCD=y
configs/ls1021aqds_nor_SECURE_BOOT_defconfig:43:CONFIG_USB_XHCI_HCD=y
configs/uniphier_pro4_defconfig:43:CONFIG_USB_XHCI_HCD=y
configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig:61:CONFIG_USB_XHCI_HCD=y
configs/xilinx_zynqmp_zcu102_defconfig:63:CONFIG_USB_XHCI_HCD=y
configs/ls1021atwr_nor_SECURE_BOOT_defconfig:42:CONFIG_USB_XHCI_HCD=y
configs/cm_t43_defconfig:67:CONFIG_USB_XHCI_HCD=y
configs/k2g_hs_evm_defconfig:36:CONFIG_USB_XHCI_HCD=y
configs/am43xx_evm_qspiboot_defconfig:45:CONFIG_USB_XHCI_HCD=y
configs/ls1021aqds_qspi_defconfig:50:CONFIG_USB_XHCI_HCD=y
configs/am57xx_hs_evm_defconfig:67:CONFIG_USB_XHCI_HCD=y
configs/xilinx_zynqmp_zcu102_revB_defconfig:63:CONFIG_USB_XHCI_HCD=y
configs/ls1021aqds_sdcard_ifc_defconfig:55:CONFIG_USB_XHCI_HCD=y
configs/uniphier_ld20_defconfig:39:CONFIG_USB_XHCI_HCD=y
configs/am43xx_evm_usbhost_boot_defconfig:61:CONFIG_USB_XHCI_HCD=y
configs/ls1021atwr_sdcard_qspi_defconfig:61:CONFIG_USB_XHCI_HCD=y
configs/evb-rk3399_defconfig:60:CONFIG_USB_XHCI_HCD=y
configs/k2hk_evm_defconfig:43:CONFIG_USB_XHCI_HCD=y
configs/k2hk_hs_evm_defconfig:34:CONFIG_USB_XHCI_HCD=y
configs/k2e_evm_defconfig:43:CONFIG_USB_XHCI_HCD=y
configs/ls1021atwr_sdcard_ifc_defconfig:54:CONFIG_USB_XHCI_HCD=y
configs/k2l_evm_defconfig:43:CONFIG_USB_XHCI_HCD=y

So it looks we have lots of conversion work to be done by many board
maintainers. I am not sure how to proceed on this.


Marek reminded me, that he thinks that most of these platforms
above will most likely select DM_USB implicitly via Kconfig.

I did a quick check and it seems 

[U-Boot] [PATCH v8 8/8] rockchip: dts: rk3399: control vbus of typec by fixed regulator

[Meng Dongyang]

Add fixed regulator for the port of typec0 and typec1 to control vbus
instead of gpio.

Signed-off-by: Meng Dongyang 
Reviewed-by: Simon Glass 
Reviewed-by: Philipp Tomsich 
Acked-by: Philipp Tomsich 
---

Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None

 arch/arm/dts/rk3399-evb.dts | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/rk3399-evb.dts b/arch/arm/dts/rk3399-evb.dts
index f5af75b..bff00c3 100644
--- a/arch/arm/dts/rk3399-evb.dts
+++ b/arch/arm/dts/rk3399-evb.dts
@@ -60,6 +60,18 @@
gpio = < 25 GPIO_ACTIVE_HIGH>;
};
 
+   vcc5v0_typec0: vcc5v0-typec0-en {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc5v0_typec0";
+   gpio = < 3 GPIO_ACTIVE_HIGH>;
+   };
+
+   vcc5v0_typec1: vcc5v0-typec1-en {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc5v0_typec1";
+   gpio = < 4 GPIO_ACTIVE_HIGH>;
+   };
+
clkin_gmac: external-gmac-clock {
compatible = "fixed-clock";
clock-frequency = <12500>;
@@ -163,7 +175,7 @@
 };
 
 _typec0 {
-   rockchip,vbus-gpio = < 3 GPIO_ACTIVE_HIGH>;
+   vbus-supply = <_typec0>;
status = "okay";
 };
 
@@ -176,7 +188,7 @@
 };
 
 _typec1 {
-   rockchip,vbus-gpio = < 4 GPIO_ACTIVE_HIGH>;
+   vbus-supply = <_typec1>;
status = "okay";
 };
 
-- 
1.9.1


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v8 1/8] usb: Kconfig: config USB_XHCI_ROCKCHIP depends on DM_REGULATOR and DM_USB

[Meng Dongyang]

The xhci-rockchip driver depends on DM_REGULATOR and DM_USB.
So add dependent features for xhci-rockchip driver in Kconfig.

Signed-off-by: Meng Dongyang 
Reviewed-by: Philipp Tomsich 
Acked-by: Philipp Tomsich 
---

Changes in v8: None
Changes in v7: None
Changes in v6:
- New patch, add depends on features for xhci-rockchip in Kconfig

 drivers/usb/host/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index b824eec..5e07a10 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -34,6 +34,8 @@ config USB_XHCI_MVEBU
 config USB_XHCI_ROCKCHIP
bool "Support for Rockchip on-chip xHCI USB controller"
depends on ARCH_ROCKCHIP
+   depends on DM_REGULATOR
+   depends on DM_USB
default y
help
  Enables support for the on-chip xHCI controller on Rockchip SoCs.
-- 
1.9.1


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v8 6/8] rockchip: rk3328: board: add support of dwc2 gadget

[Meng Dongyang]

Probe dwc2 udc in the function of board_usb_start to enable
usb gadget function.

Signed-off-by: Meng Dongyang 
Reviewed-by: Simon Glass 
Reviewed-by: Philipp Tomsich 
Acked-by: Philipp Tomsich 
---

Changes in v8: None
Changes in v7: None
Changes in v6: None
Chagnes in v5: None
Changes in v4: None
Changes in v3: None

 board/rockchip/evb_rk3328/evb-rk3328.c | 42 ++
 1 file changed, 42 insertions(+)

diff --git a/board/rockchip/evb_rk3328/evb-rk3328.c 
b/board/rockchip/evb_rk3328/evb-rk3328.c
index 0a26ed5..7fc25bb 100644
--- a/board/rockchip/evb_rk3328/evb-rk3328.c
+++ b/board/rockchip/evb_rk3328/evb-rk3328.c
@@ -31,7 +31,49 @@ int dram_init_banksize(void)
return 0;
 }
 
+#if defined(CONFIG_USB_GADGET) && defined(CONFIG_USB_GADGET_DWC2_OTG)
+#include 
+#include 
+
+static struct dwc2_plat_otg_data rk3328_otg_data = {
+   .rx_fifo_sz = 512,
+   .np_tx_fifo_sz  = 16,
+   .tx_fifo_sz = 128,
+};
+
 int board_usb_init(int index, enum usb_init_type init)
 {
+   int node;
+   const char *mode;
+   bool matched = false;
+   const void *blob = gd->fdt_blob;
+
+   /* find the usb_otg node */
+   node = fdt_node_offset_by_compatible(blob, -1,
+   "rockchip,rk3328-usb");
+
+   while (node > 0) {
+   mode = fdt_getprop(blob, node, "dr_mode", NULL);
+   if (mode && strcmp(mode, "otg") == 0) {
+   matched = true;
+   break;
+   }
+
+   node = fdt_node_offset_by_compatible(blob, node,
+   "rockchip,rk3328-usb");
+   }
+   if (!matched) {
+   debug("Not found usb_otg device\n");
+   return -ENODEV;
+   }
+
+   rk3328_otg_data.regs_otg = fdtdec_get_addr(blob, node, "reg");
+
+   return dwc2_udc_probe(_otg_data);
+}
+
+int board_usb_cleanup(int index, enum usb_init_type init)
+{
return 0;
 }
+#endif
-- 
1.9.1


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v8 5/8] usb: dwc2: use dev_read_bool() instead of fdt_getprop()

[Meng Dongyang]

Use dev_read_bool() instead of fdt_getprop() to get the property
from DTS. And add a comment for "hnp-srp-disable" property to
fully describe its effect.

Signed-off-by: Meng Dongyang 
Reviewed-by: Philipp Tomsich 
Acked-by: Philipp Tomsich 
---

Changes in v8: None
Changes in v7:
- Romove unused variable ‘prop’ in dwc2 driver
 
Changes in v6:
- New patch
- Use dev_read_bool() instead of fdt_getprop()
- Add a comment for "hnp-srp-disable" feature

 drivers/usb/host/dwc2.c | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
index 841e596..64c42ac 100644
--- a/drivers/usb/host/dwc2.c
+++ b/drivers/usb/host/dwc2.c
@@ -43,6 +43,10 @@ struct dwc2_priv {
struct dwc2_core_regs *regs;
int root_hub_devnum;
bool ext_vbus;
+   /*
+* The hnp/srp capability must be disabled if the platform
+* does't support hnp/srp. Otherwise the force mode can't work.
+*/
bool hnp_srp_disable;
bool oc_disable;
 };
@@ -1239,7 +1243,6 @@ static int dwc2_submit_int_msg(struct udevice *dev, 
struct usb_device *udev,
 static int dwc2_usb_ofdata_to_platdata(struct udevice *dev)
 {
struct dwc2_priv *priv = dev_get_priv(dev);
-   const void *prop;
fdt_addr_t addr;
 
addr = devfdt_get_addr(dev);
@@ -1247,15 +1250,8 @@ static int dwc2_usb_ofdata_to_platdata(struct udevice 
*dev)
return -EINVAL;
priv->regs = (struct dwc2_core_regs *)addr;
 
-   prop = fdt_getprop(gd->fdt_blob, dev_of_offset(dev),
-  "disable-over-current", NULL);
-   if (prop)
-   priv->oc_disable = true;
-
-   prop = fdt_getprop(gd->fdt_blob, dev_of_offset(dev),
-  "hnp-srp-disable", NULL);
-   if (prop)
-   priv->hnp_srp_disable = true;
+   priv->oc_disable = dev_read_bool(dev, "disable-over-current");
+   priv->hnp_srp_disable = dev_read_bool(dev, "hnp-srp-disable");
 
return 0;
 }
-- 
1.9.1


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v8 3/8] rockchip: dts: rk3328: add fixed regulator node for xhci

[Meng Dongyang]

The driver changes gpio to fixed regulator to control vbus, so add
fixed regulator node in DTS for xhci driver.

Signed-off-by: Meng Dongyang 
Reviewed-by: Philipp Tomsich 
Acked-by: Philipp Tomsich 
---

Changes in v8: None
Changes in v7: None
Changes in v6:
- New patch, splited from [PATCH,v5,06/11]

 arch/arm/dts/rk3328-evb.dts | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/rk3328-evb.dts b/arch/arm/dts/rk3328-evb.dts
index b807bc5..4cf6d2e 100644
--- a/arch/arm/dts/rk3328-evb.dts
+++ b/arch/arm/dts/rk3328-evb.dts
@@ -14,6 +14,15 @@
chosen {
stdout-path = 
};
+
+   vcc5v0_host_xhci: vcc5v0-host-xhci-drv {
+   compatible = "regulator-fixed";
+   enable-active-high;
+   regulator-name = "vcc5v0_host_xhci";
+   gpio = < 0 GPIO_ACTIVE_HIGH>;
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   };
 };
 
  {
@@ -53,6 +62,6 @@
 };
 
 _host0_xhci {
-   rockchip,vbus-gpio = < 0 GPIO_ACTIVE_HIGH>;
+   vbus-supply = <_host_xhci>;
status = "okay";
 };
-- 
1.9.1


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v8 7/8] rockchip: dts: rk3328: support and enable dwc2

[Meng Dongyang]

Enable dwc2 controller and add fixed regulator for dwc2 controller to
control vbus.

Signed-off-by: Meng Dongyang 
Reviewed-by: Simon Glass 
Reviewed-by: Philipp Tomsich 
Acked-by: Philipp Tomsich 
---

Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
- add hnp-srp-disable property

 arch/arm/dts/rk3328-evb.dts | 14 ++
 arch/arm/dts/rk3328.dtsi| 10 ++
 2 files changed, 24 insertions(+)

diff --git a/arch/arm/dts/rk3328-evb.dts b/arch/arm/dts/rk3328-evb.dts
index 4cf6d2e..220d0ab 100644
--- a/arch/arm/dts/rk3328-evb.dts
+++ b/arch/arm/dts/rk3328-evb.dts
@@ -15,6 +15,15 @@
stdout-path = 
};
 
+   vcc5v0_otg: vcc5v0-otg-drv {
+   compatible = "regulator-fixed";
+   enable-active-high;
+   regulator-name = "vcc5v0_otg";
+   gpio = < 27 GPIO_ACTIVE_HIGH>;
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   };
+
vcc5v0_host_xhci: vcc5v0-host-xhci-drv {
compatible = "regulator-fixed";
enable-active-high;
@@ -61,6 +70,11 @@
status = "okay";
 };
 
+_otg {
+   vbus-supply = <_otg>;
+   status = "okay";
+};
+
 _host0_xhci {
vbus-supply = <_host_xhci>;
status = "okay";
diff --git a/arch/arm/dts/rk3328.dtsi b/arch/arm/dts/rk3328.dtsi
index f18cfc2..1290982 100644
--- a/arch/arm/dts/rk3328.dtsi
+++ b/arch/arm/dts/rk3328.dtsi
@@ -460,6 +460,16 @@
status = "disabled";
};
 
+   usb20_otg: usb@ff58 {
+   compatible = "rockchip,rk3328-usb", "rockchip,rk3066-usb",
+"snps,dwc2";
+   reg = <0x0 0xff58 0x0 0x4>;
+   interrupts = ;
+   hnp-srp-disable;
+   dr_mode = "otg";
+   status = "disabled";
+   };
+
sdmmc_ext: rksdmmc@ff5f {
compatible = "rockchip,rk3328-dw-mshc", 
"rockchip,rk3288-dw-mshc";
reg = <0x0 0xff5f 0x0 0x4000>;
-- 
1.9.1


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v8 0/8] rk3328: add support of usb host and gadget

[Meng Dongyang]

Add support of usb host and gadget function for rk3328.

Changed in v8:
- Convert CONFIG_USB_DWC2 to a Kconfig entry
 
Changed in v7:
- Romove unused variable ‘prop’ in dwc2 driver
 
Changed in v6:
- Rebase on the newest code of master branch
- Make xhci-rockchip driver depend on DM_REGULATOR and DM_USB
- Remove #ifdef DM_RERULATOR and DM_USB in xhci-rockchip driver
- Use dev_read_boot() instead of fdt_getprop() in dwc2 driver
 
Changes in v5:
- Propagate return value and print error message when failed
 
Changes in v4:
- Splite patch [U-boot,v3,04/10] into two patches
- Define set vbus as empty function if the macros aren't set
- Prepare a mask and set capabilities in GUSBCFG register once
 
Changes in v3:
- Revert change of macro definition in dwc2 driver
- Support host mode without HNP/SRP capability through DTS
 
Changes in v2:
- Add commit messages
- Split patch [U-boot,7/8] into two patches
- Use fixed regulator to control vbus instead of gpio

Meng Dongyang (8):
  usb: Kconfig: config USB_XHCI_ROCKCHIP depends on DM_REGULATOR and
DM_USB
  usb: host: xhci-rockchip: use fixed regulator to control vbus
  rockchip: dts: rk3328: add fixed regulator node for xhci
  rockchip: configs: rk3328: enable dwc2 driver and config fastboot
  usb: dwc2: use dev_read_bool() instead of fdt_getprop()
  rockchip: rk3328: board: add support of dwc2 gadget
  rockchip: dts: rk3328: support and enable dwc2
  rockchip: dts: rk3399: control vbus of typec by fixed regulator

 arch/arm/dts/rk3328-evb.dts| 25 +++-
 arch/arm/dts/rk3328.dtsi   | 10 
 arch/arm/dts/rk3399-evb.dts| 16 +++--
 board/rockchip/evb_rk3328/evb-rk3328.c | 42 ++
 configs/evb-rk3328_defconfig   | 20 ++--
 drivers/usb/host/Kconfig   | 12 ++
 drivers/usb/host/dwc2.c| 16 +
 drivers/usb/host/xhci-rockchip.c   | 36 ++---
 8 files changed, 144 insertions(+), 33 deletions(-)

-- 
1.9.1


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v8 4/8] rockchip: configs: rk3328: enable dwc2 driver and config fastboot

[Meng Dongyang]

Config dwc2 driver support host and gadget function. Add support
of fastboot function.

Signed-off-by: Meng Dongyang 
Acked-by: Philipp Tomsich 
---

Changes in v8:
- Convert CONFIG_USB_DWC2 to a Kconfig entry

Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 configs/evb-rk3328_defconfig | 20 ++--
 drivers/usb/host/Kconfig | 10 ++
 2 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/configs/evb-rk3328_defconfig b/configs/evb-rk3328_defconfig
index 1384e87..aabc8a4 100644
--- a/configs/evb-rk3328_defconfig
+++ b/configs/evb-rk3328_defconfig
@@ -31,12 +31,28 @@ CONFIG_DEBUG_UART_SHIFT=2
 CONFIG_SYS_NS16550=y
 CONFIG_SYSRESET=y
 CONFIG_USB=y
-CONFIG_USB_XHCI_HCD=y
-CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_GENERIC=y
 CONFIG_USB_OHCI_HCD=y
 CONFIG_USB_OHCI_GENERIC=y
+CONFIG_USB_DWC2=y
 CONFIG_USB_STORAGE=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_RK=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_USB_GADGET_DUALSPEED=y
+CONFIG_USB_GADGET_DWC2_OTG=y
+CONFIG_USB_FUNCTION_FASTBOOT=y
+CONFIG_G_DNL_MANUFACTURER="Rockchip"
+CONFIG_G_DNL_VENDOR_NUM=0x2207
+CONFIG_G_DNL_PRODUCT_NUM=0x330a
+CONFIG_FASTBOOT=y
+CONFIG_CMD_FASTBOOT=y
+CONFIG_FASTBOOT_FLASH=y
+CONFIG_FASTBOOT_FLASH_MMC_DEV=1
+CONFIG_FASTBOOT_BUF_ADDR=0x00800800
+CONFIG_FASTBOOT_BUF_SIZE=0x0800
 CONFIG_USE_TINY_PRINTF=y
 CONFIG_ERRNO_STR=y
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 5e07a10..bc2c1f1 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -201,3 +201,13 @@ config USB_UHCI_HCD
 if USB_UHCI_HCD
 
 endif # USB_UHCI_HCD
+
+config USB_DWC2
+   bool "DesignWare USB2 Core support"
+   select USB_HOST
+   ---help---
+ The DesignWare USB 2.0 controller is compliant with the
+ USB-Implementers Forum (USB-IF) USB 2.0 specifications.
+ Hi-Speed (480 Mbps), Full-Speed (12 Mbps), and Low-Speed (1.5 Mbps)
+ operation is compliant to the controller Supplement. If you want to
+ enable this controller in host mode, say Y.
-- 
1.9.1


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v8 2/8] usb: host: xhci-rockchip: use fixed regulator to control vbus

[Meng Dongyang]

Use fixed regulator to control the voltage of vbus. Enable vbus
supply when usb start and disable vbus supply when usb stop.

Signed-off-by: Meng Dongyang 
Reviewed-by: Philipp Tomsich 
Acked-by: Philipp Tomsich 
---

Changes in v8: None
Changes in v7: None
Changes in v6:
- Remove #ifdef DM_REGULATOR and DM_USB due to the addition in Kconfig
 
Changes in v5:
- Propagate the return value of setting VBus and print error when failed
 
Changes in v4:
- Splited from patch [Uboot,v3,04/10]
- Define set vbus as empty function if the macros aren't set
 
Changes in v3: None
Changes in v2:
- Use fixed regulator to control vbus instead of gpio

 drivers/usb/host/xhci-rockchip.c | 36 ++--
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/usb/host/xhci-rockchip.c b/drivers/usb/host/xhci-rockchip.c
index c4ae55f..6b4caf9 100644
--- a/drivers/usb/host/xhci-rockchip.c
+++ b/drivers/usb/host/xhci-rockchip.c
@@ -48,7 +48,7 @@ static int xhci_usb_ofdata_to_platdata(struct udevice *dev)
 */
plat->hcd_base = devfdt_get_addr(dev);
if (plat->hcd_base == FDT_ADDR_T_NONE) {
-   debug("Can't get the XHCI register base address\n");
+   error("Can't get the XHCI register base address\n");
return -ENXIO;
}
 
@@ -62,17 +62,15 @@ static int xhci_usb_ofdata_to_platdata(struct udevice *dev)
}
 
if (plat->phy_base == FDT_ADDR_T_NONE) {
-   debug("Can't get the usbphy register address\n");
+   error("Can't get the usbphy register address\n");
return -ENXIO;
}
 
-#if defined(CONFIG_DM_USB) && defined(CONFIG_DM_REGULATOR)
/* Vbus regulator */
ret = device_get_supply_regulator(dev, "vbus-supply",
  >vbus_supply);
if (ret)
-   debug("Can't get vbus supply\n");
-#endif
+   debug("Can't get VBus regulator!\n");
 
return 0;
 }
@@ -126,7 +124,7 @@ static int rockchip_xhci_core_init(struct rockchip_xhci 
*rkxhci,
 
ret = dwc3_core_init(rkxhci->dwc3_reg);
if (ret) {
-   debug("failed to initialize core\n");
+   error("failed to initialize core\n");
return ret;
}
 
@@ -155,15 +153,17 @@ static int xhci_usb_probe(struct udevice *dev)
hcor = (struct xhci_hcor *)((uint64_t)ctx->hcd +
HC_LENGTH(xhci_readl(>hcd->cr_capbase)));
 
-#if defined(CONFIG_DM_USB) && defined(CONFIG_DM_REGULATOR)
-   ret = regulator_set_enable(plat->vbus_supply, true);
-   if (ret)
-   debug("XHCI: Failed to enable vbus supply\n");
-#endif
+   if (plat->vbus_supply) {
+   ret = regulator_set_enable(plat->vbus_supply, true);
+   if (ret) {
+   error("XHCI: failed to set VBus supply\n");
+   return ret;
+   }
+   }
 
ret = rockchip_xhci_core_init(ctx, dev);
if (ret) {
-   debug("XHCI: failed to initialize controller\n");
+   error("XHCI: failed to initialize controller\n");
return ret;
}
 
@@ -183,13 +183,13 @@ static int xhci_usb_remove(struct udevice *dev)
if (ret)
return ret;
 
-#if defined(CONFIG_DM_USB) && defined(CONFIG_DM_REGULATOR)
-   ret = regulator_set_enable(plat->vbus_supply, false);
-   if (ret)
-   debug("XHCI: Failed to disable vbus supply\n");
-#endif
+   if (plat->vbus_supply) {
+   ret = regulator_set_enable(plat->vbus_supply, false);
+   if (ret)
+   error("XHCI: failed to set VBus supply\n");
+   }
 
-   return 0;
+   return ret;
 }
 
 static const struct udevice_id xhci_usb_ids[] = {
-- 
1.9.1


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] usb: xhci: Add interrupt transfer support

[Stefan Roese]

Hi Bin,

On 26.06.2017 13:05, Bin Meng wrote:
> This series is the final series of the xHCI driver update.
> 
> This adds the missing interrupt transfer support to xHCI driver, so
> that devices like USB keyboard that uses interrupt transfer when
> CONFIG_SYS_USB_EVENT_POLL is defined can work.
> 
> Previous two series:
> [1]: usb: xhci: Fix USB xHCI support on Intel platform
> https://lists.denx.de/pipermail/u-boot/2017-June/296166.html
> [2]: usb: hub: Support USB 3.0 hubs
> https://lists.denx.de/pipermail/u-boot/2017-June/296284.html
> 
> This series is available at u-boot-x86/xhci-working3 for testing.

I'm using this git branch to test all your xHCI related patches
now. On my BayTrail platform I get these messages upon "usb reset"
scanning:

=> usb reset
resetting USB...
USB0:   Register 7000820 NbrPorts 7
Starting the controller
USB XHCI 1.00
scanning bus 0 for devices... cannot reset port 1!?
USB device descriptor short read (expected 18, got 8)
5 USB Device(s) found
   scanning usb for storage devices... 1 Storage Device(s) found

On the 2nd scan, the "cannot reset port 1" line is gone:

=> usb reset
resetting USB...
USB0:   Register 7000820 NbrPorts 7
Starting the controller
USB XHCI 1.00
scanning bus 0 for devices... USB device descriptor short read (expected 18, 
got 8)
5 USB Device(s) found
   scanning usb for storage devices... 1 Storage Device(s) found

All USB devices seem to be detected correctly though. Here the
logs:

=> usb tree
USB device tree:
  1  Hub (5 Gb/s, 0mA)
  |  U-Boot XHCI Host Controller 
  |
  +-2  Hub (480 Mb/s, 100mA)
  |  
  +-3  Hub (480 Mb/s, 2mA)
  | |
  | +-5  Mass Storage (480 Mb/s, 200mA)
  |  JetFlash Mass Storage Device 3281440601
  |
  +-4  Vendor specific (5 Gb/s, 64mA)
   Realtek USB 10/100/1000 LAN 0200
 
=> usb info
1: Hub,  USB Revision 3.0
 - U-Boot XHCI Host Controller 
 - Class: Hub
 - PacketSize: 512  Configurations: 1
 - Vendor: 0x  Product 0x Version 1.0
   Configuration: 1
   - Interfaces: 1 Self Powered 0mA
 Interface: 0
 - Alternate Setting 0, Endpoints: 1
 - Class Hub
 - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms

2: Hub,  USB Revision 2.0
 - Class: Hub
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x0409  Product 0x005a Version 1.0
   Configuration: 1
   - Interfaces: 1 Self Powered Remote Wakeup 100mA
 Interface: 0
 - Alternate Setting 0, Endpoints: 1
 - Class Hub
 - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms

3: Hub,  USB Revision 2.1
 - Class: Hub
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x0424  Product 0x4604 Version 1.131
   Configuration: 1
   - Interfaces: 1 Self Powered Remote Wakeup 2mA
 Interface: 0
 - Alternate Setting 0, Endpoints: 1
 - Class Hub
 - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms
 - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms

5: Mass Storage,  USB Revision 2.10
 - JetFlash Mass Storage Device 3281440601
 - Class: (from Interface) Mass Storage
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x8564  Product 0x1000 Version 16.117
   Configuration: 1
   - Interfaces: 1 Bus Powered 200mA
 Interface: 0
 - Alternate Setting 0, Endpoints: 2
 - Class Mass Storage, Transp. SCSI, Bulk only
 - Endpoint 2 Out Bulk MaxPacket 512
 - Endpoint 1 In Bulk MaxPacket 512

4: Vendor specific,  USB Revision 3.0
 - Realtek USB 10/100/1000 LAN 0200
 - Class: (from Interface) Vendor specific
 - PacketSize: 512  Configurations: 2
 - Vendor: 0x0bda  Product 0x8153 Version 48.0
   Configuration: 1
   - Interfaces: 1 Bus Powered Remote Wakeup 64mA
 Interface: 0
 - Alternate Setting 0, Endpoints: 3
 - Class Vendor specific
 - Endpoint 1 In Bulk MaxPacket 1024
 - Endpoint 2 Out Bulk MaxPacket 1024
 - Endpoint 3 In Interrupt MaxPacket 2 Interval 8ms

Do you have any ideas about the scanning logs that I've noticed
above? Would it help if I provided some debug logs (-DDEBUG)
for this?


BTW: I need to re-add the SYS_USB_EVENT_POLL* options back to
the whilelist file. Otherwise compiling fails with this
message:

$ make minnowmax_defconfig
$ make -s -j10
Error: You must add new CONFIG options using Kconfig
The following new ad-hoc CONFIG options were detected:
CONFIG_SYS_USB_EVENT_POLL

Please add these via Kconfig instead. Find a suitable Kconfig
file and add a 'config' or 'menuconfig' option.
Makefile:862: recipe for target 'all' failed

Don't you see this error? Any idea whats going wrong here?

Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] atmel, at91: fix taurus board

[Yang, Wenyou]

On 2017/6/28 17:24, Heiko Schocher wrote:

since commit: f8b7fff1d5c5 "serial: atmel_usart: Add clk support"

taurus board comes not up anymore. Fix it.

Signed-off-by: Heiko Schocher 

Thank you.

Acked-by: Wenyou Yang 


---

  arch/arm/dts/at91sam9g20-taurus.dts | 2 ++
  board/siemens/taurus/taurus.c   | 9 -
  configs/taurus_defconfig| 3 +++
  3 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/arch/arm/dts/at91sam9g20-taurus.dts 
b/arch/arm/dts/at91sam9g20-taurus.dts
index f27d772..7931c0a 100644
--- a/arch/arm/dts/at91sam9g20-taurus.dts
+++ b/arch/arm/dts/at91sam9g20-taurus.dts
@@ -18,6 +18,7 @@
compatible = "atmel,at91sam9g20ek", "atmel,at91sam9g20", 
"atmel,at91sam9";
  
  	chosen {

+   u-boot,dm-pre-reloc;
stdout-path = 
};
  
@@ -48,6 +49,7 @@

};
  
  			dbgu: serial@f200 {

+   u-boot,dm-pre-reloc;
status = "okay";
};
  
diff --git a/board/siemens/taurus/taurus.c b/board/siemens/taurus/taurus.c

index 8da24be..4aa8d64 100644
--- a/board/siemens/taurus/taurus.c
+++ b/board/siemens/taurus/taurus.c
@@ -448,12 +448,3 @@ U_BOOT_CMD(
  );
  #endif
  #endif
-
-static struct atmel_serial_platdata at91sam9260_serial_plat = {
-   .base_addr = ATMEL_BASE_DBGU,
-};
-
-U_BOOT_DEVICE(at91sam9260_serial) = {
-   .name   = "serial_atmel",
-   .platdata = _serial_plat,
-};
diff --git a/configs/taurus_defconfig b/configs/taurus_defconfig
index 2de9cad..70d44a7 100644
--- a/configs/taurus_defconfig
+++ b/configs/taurus_defconfig
@@ -7,6 +7,7 @@ CONFIG_TARGET_TAURUS=y
  CONFIG_SPL_GPIO_SUPPORT=y
  CONFIG_SPL_LIBCOMMON_SUPPORT=y
  CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x1000
  CONFIG_SPL_SERIAL_SUPPORT=y
  CONFIG_SPL_NAND_SUPPORT=y
  CONFIG_SPL_SPI_FLASH_SUPPORT=y
@@ -36,6 +37,8 @@ CONFIG_CMD_PING=y
  # CONFIG_DOS_PARTITION is not set
  CONFIG_OF_CONTROL=y
  CONFIG_OF_EMBED=y
+CONFIG_CLK=y
+CONFIG_CLK_AT91=y
  CONFIG_DFU_NAND=y
  # CONFIG_MMC is not set
  CONFIG_SPI_FLASH=y

Best Regards,
Wenyou Yang
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCHv6 3/3] ARM64: poplar: hi3798cv200: u-boot support for Poplar 96Boards

[Jorge Ramirez]

On 06/26/2017 03:52 PM, Jorge Ramirez-Ortiz wrote:

This port adds support for:
 1) Serial
 2) eMMC
 3) USB

It has been tested with ARM TRUSTED FIRMWARE running u-boot as the
BL33 executable [see board's README]



FYI, I just submitted the Pull Request to the arm trusted firmware project:
https://github.com/ARM-software/arm-trusted-firmware/pull/1005/commits/420eabe76eb0a23314b21044f4387464df79d38f




eMMC has been tested for reading and booting the loader and linux
kernels as well as saving the u-boot environment.

USB has been tested with ASIX networking adapter and SanDisk 7.4GB
drive.

PSCI has been tested via the reset call (PSCI executes from DDR)

The firwmare upgrade process has been tested via TFTP and USB FAT
filesystem containing the fastboot.bin image in one of the partitions.

Signed-off-by: Jorge Ramirez-Ortiz 
---
  arch/arm/Kconfig   |  14 +
  arch/arm/dts/hi3798cv200-u-boot.dtsi   |  29 +++
  arch/arm/include/asm/arch-hi3798cv200/dwmmc.h  |  13 +
  .../arm/include/asm/arch-hi3798cv200/hi3798cv200.h |  50 
  board/hisilicon/poplar/Kconfig |  15 ++
  board/hisilicon/poplar/MAINTAINERS |   6 +
  board/hisilicon/poplar/Makefile|   7 +
  board/hisilicon/poplar/README  | 288 +
  board/hisilicon/poplar/poplar.c| 174 +
  configs/poplar_defconfig   |  26 ++
  include/configs/poplar.h   |  86 ++
  11 files changed, 708 insertions(+)
  create mode 100644 arch/arm/dts/hi3798cv200-u-boot.dtsi
  create mode 100644 arch/arm/include/asm/arch-hi3798cv200/dwmmc.h
  create mode 100644 arch/arm/include/asm/arch-hi3798cv200/hi3798cv200.h
  create mode 100644 board/hisilicon/poplar/Kconfig
  create mode 100644 board/hisilicon/poplar/MAINTAINERS
  create mode 100644 board/hisilicon/poplar/Makefile
  create mode 100644 board/hisilicon/poplar/README
  create mode 100644 board/hisilicon/poplar/poplar.c
  create mode 100644 configs/poplar_defconfig
  create mode 100644 include/configs/poplar.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 46183ae..4b4f51c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -837,6 +837,19 @@ config TARGET_HIKEY
  Support for HiKey 96boards platform. It features a HI6220
  SoC, with 8xA53 CPU, mali450 gpu, and 1GB RAM.
  
+config TARGET_POPLAR

+   bool "Support Poplar 96boards Enterprise Edition Platform"
+   select ARM64
+   select DM
+   select OF_CONTROL
+   select DM_SERIAL
+   select DM_USB
+ help
+ Support for Poplar 96boards EE platform. It features a HI3798cv200
+ SoC, with 4xA53 CPU, 1GB RAM and the high performance Mali T720 GPU
+ making it capable of running any commercial set-top solution based on
+ Linux or Android.
+
  config TARGET_LS1012AQDS
bool "Support ls1012aqds"
select ARCH_LS1012A
@@ -1165,6 +1178,7 @@ source "board/grinn/chiliboard/Kconfig"
  source "board/gumstix/pepper/Kconfig"
  source "board/h2200/Kconfig"
  source "board/hisilicon/hikey/Kconfig"
+source "board/hisilicon/poplar/Kconfig"
  source "board/imx31_phycore/Kconfig"
  source "board/isee/igep003x/Kconfig"
  source "board/olimex/mx23_olinuxino/Kconfig"
diff --git a/arch/arm/dts/hi3798cv200-u-boot.dtsi 
b/arch/arm/dts/hi3798cv200-u-boot.dtsi
new file mode 100644
index 000..2b3713b
--- /dev/null
+++ b/arch/arm/dts/hi3798cv200-u-boot.dtsi
@@ -0,0 +1,29 @@
+/*
+ * U-Boot addition to:
+ *  1) use platform data for the console
+ *  2) provide support for the generic-ehci USB driver currently not available
+ * in the linux kernel (8/May/2017).
+ *
+ * (C) Copyright 2017 Jorge Ramirez-Ortiz 
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+ {
+   usb2: ehci@989 {
+   compatible = "generic-ehci";
+   reg = <0x989 0x100>;
+   status = "okay";
+   };
+};
+
+ {
+   status = "disabled";
+};
+
+/{
+   chosen {
+   stdout-path = "";
+   };
+};
+
diff --git a/arch/arm/include/asm/arch-hi3798cv200/dwmmc.h 
b/arch/arm/include/asm/arch-hi3798cv200/dwmmc.h
new file mode 100644
index 000..1060d94
--- /dev/null
+++ b/arch/arm/include/asm/arch-hi3798cv200/dwmmc.h
@@ -0,0 +1,13 @@
+/*
+ * (C) Copyright 2017 Linaro
+ * Jorge Ramirez-Ortiz 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _HI3798cv200_DWMMC_H_
+#define _HI3798cv200_DWMMC_H_
+
+int hi6220_dwmci_add_port(int index, u32 regbase, int bus_width);
+
+#endif /* _HI3798cv200_DWMMC_H_ */
diff --git a/arch/arm/include/asm/arch-hi3798cv200/hi3798cv200.h 
b/arch/arm/include/asm/arch-hi3798cv200/hi3798cv200.h
new file mode 100644
index 000..d30e0b4
--- /dev/null
+++ 

[U-Boot] [PATCH] atmel, at91: fix taurus board

[Heiko Schocher]

since commit: f8b7fff1d5c5 "serial: atmel_usart: Add clk support"

taurus board comes not up anymore. Fix it.

Signed-off-by: Heiko Schocher 
---

 arch/arm/dts/at91sam9g20-taurus.dts | 2 ++
 board/siemens/taurus/taurus.c   | 9 -
 configs/taurus_defconfig| 3 +++
 3 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/arch/arm/dts/at91sam9g20-taurus.dts 
b/arch/arm/dts/at91sam9g20-taurus.dts
index f27d772..7931c0a 100644
--- a/arch/arm/dts/at91sam9g20-taurus.dts
+++ b/arch/arm/dts/at91sam9g20-taurus.dts
@@ -18,6 +18,7 @@
compatible = "atmel,at91sam9g20ek", "atmel,at91sam9g20", 
"atmel,at91sam9";
 
chosen {
+   u-boot,dm-pre-reloc;
stdout-path = 
};
 
@@ -48,6 +49,7 @@
};
 
dbgu: serial@f200 {
+   u-boot,dm-pre-reloc;
status = "okay";
};
 
diff --git a/board/siemens/taurus/taurus.c b/board/siemens/taurus/taurus.c
index 8da24be..4aa8d64 100644
--- a/board/siemens/taurus/taurus.c
+++ b/board/siemens/taurus/taurus.c
@@ -448,12 +448,3 @@ U_BOOT_CMD(
 );
 #endif
 #endif
-
-static struct atmel_serial_platdata at91sam9260_serial_plat = {
-   .base_addr = ATMEL_BASE_DBGU,
-};
-
-U_BOOT_DEVICE(at91sam9260_serial) = {
-   .name   = "serial_atmel",
-   .platdata = _serial_plat,
-};
diff --git a/configs/taurus_defconfig b/configs/taurus_defconfig
index 2de9cad..70d44a7 100644
--- a/configs/taurus_defconfig
+++ b/configs/taurus_defconfig
@@ -7,6 +7,7 @@ CONFIG_TARGET_TAURUS=y
 CONFIG_SPL_GPIO_SUPPORT=y
 CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x1000
 CONFIG_SPL_SERIAL_SUPPORT=y
 CONFIG_SPL_NAND_SUPPORT=y
 CONFIG_SPL_SPI_FLASH_SUPPORT=y
@@ -36,6 +37,8 @@ CONFIG_CMD_PING=y
 # CONFIG_DOS_PARTITION is not set
 CONFIG_OF_CONTROL=y
 CONFIG_OF_EMBED=y
+CONFIG_CLK=y
+CONFIG_CLK_AT91=y
 CONFIG_DFU_NAND=y
 # CONFIG_MMC is not set
 CONFIG_SPI_FLASH=y
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] question regarding the odroidc2 board support

[Lukasz Majewski]

On Wed, 28 Jun 2017 10:44:17 +0200
daggs  wrote:

> Greetings Lukasz,
> 
> > Sent: Tuesday, June 27, 2017 at 4:12 PM
> > From: "Lukasz Majewski" 
> > To: daggs 
> > Cc: u-boot@lists.denx.de
> > Subject: Re: [U-Boot] question regarding the odroidc2 board support
> >
> > On Tue, 27 Jun 2017 13:58:46 +0200
> > daggs  wrote:
> > 
> > > Greetings Lukasz 
> > > 
> > > > Sent: Tuesday, June 27, 2017 at 10:57 AM
> > > > From: "Lukasz Majewski" 
> > > > To: daggs 
> > > > Cc: u-boot@lists.denx.de
> > > > Subject: Re: [U-Boot] question regarding the odroidc2 board
> > > > support
> > > >
> > > > On Thu, 22 Jun 2017 19:55:21 +0200
> > > > daggs  wrote:
> > > > 
> > > > > Greetings,
> > > > > 
> > > > > I'm using buildroot to generate images for the odroid c2
> > > > > boards and from what I see, it uses u-boot.bin to burn into
> > > > > the image. I'm not seeing any other uboot product that is
> > > > > used for booting (unless I'm mistaken). I'm reading the
> > > > > odroid c2 readme file and I see it instructs the use to burn
> > > > > a alternative u-boot.bin from the one that was created by the
> > > > > env. I wonder how it is possible to actually use newer uboot
> > > > > when in the end uboot recommends to replace u-boot.bin with
> > > > > pre existing one?
> > > > 
> > > > From the spec I do see that C2 has SD card and eMMC.
> > > > 
> > > > I can only share my experience with Odroid XU3/U3.
> > > > 
> > > > The boot process would (probably) require some signed blobs from
> > > > hardkernel (those binaries are corresponding to u-boot-spl.bin).
> > > > 
> > > > I can recommend looking to Hardkernel forum (they should have
> > > > some topics dedicated for this SoM), or look for tizen.org wiki:
> > > > 
> > > > https://wiki.tizen.org/Quick_guide_for_odroidxu3
> > > > 
> > > > I hope, that the boot flow is similar for XU3 and C2.
> > > > 
> > > > > 
> > > > > Thanks,
> > > > > 
> > > > > Dagg.
> > > > > ___
> > > > > U-Boot mailing list
> > > > > U-Boot@lists.denx.de
> > > > > https://lists.denx.de/listinfo/u-boot
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Best regards,
> > > > 
> > > > Lukasz Majewski
> > > > 
> > > > --
> > > > 
> > > > DENX Software Engineering GmbH,  Managing Director: Wolfgang
> > > > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194
> > > > Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax:
> > > > (+49)-8142-66989-80 Email: w...@denx.de
> > > > 
> > > 
> > > indeed that is correct, the c2 has a singed binary.
> > > as said in my mail, I'm using buildroot to create my images, at
> > > the end buildroot takes the file u-boot.bin and burn it into the
> > > image at a specific location. the c2 readme explains how to
> > > extract the signed blob but I'd expect that it will overwrite
> > > part of the u-boot.bin file and no replace it. so I assume I'm
> > > missing a part. e.g. u-boot.bin isn't the only file needed from
> > > u-boot. am I correct?
> > 
> > I can only speak by having some experience with Odroid XU3.
> > 
> > XU3 had bl1.bin.hardkernel, which was signed (and this corresponds
> > to u-boot's SPL binary).
> > 
> > This bl1 called "normal" u-boot (u-boot.bin).
> > 
> > And afterwards u-boot was calling uImage + DTB.
> > 
> > There was also problem with the eMMC layout - you had to jump
> > somewhere else since the default "partition" for u-boot (512 KiB)
> > was too small.
> > 
> > Also please pay a note if you need any TZW (trust zone) firmware for
> > your platform.
> > 
> > Have you found any info on hardkerne's wiki/forum?
> > 
> > > 
> > > Thanks.
> > > 
> > > Dagg.
> > 
> > 
> > 
> > 
> > Best regards,
> > 
> > Lukasz Majewski
> 
> yes, I did asked a question regarding this but didn't got any answer.
> I've decided to ask the uboot devs as from what I understand, the
> hardkernel guys must comply with uboot's guidelines.
> 
> so my question is, does u-boot.bin is the only product from u-boot
> which is added into the image?

From my Exynos development experience - yes it is the only one.

> 
> Thanks,
> 
> Dagg.
> 
> Dagg.




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] question regarding the odroidc2 board support

[daggs]

Greetings Lukasz,

> Sent: Tuesday, June 27, 2017 at 4:12 PM
> From: "Lukasz Majewski" 
> To: daggs 
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] question regarding the odroidc2 board support
>
> On Tue, 27 Jun 2017 13:58:46 +0200
> daggs  wrote:
> 
> > Greetings Lukasz 
> > 
> > > Sent: Tuesday, June 27, 2017 at 10:57 AM
> > > From: "Lukasz Majewski" 
> > > To: daggs 
> > > Cc: u-boot@lists.denx.de
> > > Subject: Re: [U-Boot] question regarding the odroidc2 board support
> > >
> > > On Thu, 22 Jun 2017 19:55:21 +0200
> > > daggs  wrote:
> > > 
> > > > Greetings,
> > > > 
> > > > I'm using buildroot to generate images for the odroid c2 boards
> > > > and from what I see, it uses u-boot.bin to burn into the image.
> > > > I'm not seeing any other uboot product that is used for booting
> > > > (unless I'm mistaken). I'm reading the odroid c2 readme file and
> > > > I see it instructs the use to burn a alternative u-boot.bin from
> > > > the one that was created by the env. I wonder how it is possible
> > > > to actually use newer uboot when in the end uboot recommends to
> > > > replace u-boot.bin with pre existing one?
> > > 
> > > From the spec I do see that C2 has SD card and eMMC.
> > > 
> > > I can only share my experience with Odroid XU3/U3.
> > > 
> > > The boot process would (probably) require some signed blobs from
> > > hardkernel (those binaries are corresponding to u-boot-spl.bin).
> > > 
> > > I can recommend looking to Hardkernel forum (they should have some
> > > topics dedicated for this SoM), or look for tizen.org wiki:
> > > 
> > > https://wiki.tizen.org/Quick_guide_for_odroidxu3
> > > 
> > > I hope, that the boot flow is similar for XU3 and C2.
> > > 
> > > > 
> > > > Thanks,
> > > > 
> > > > Dagg.
> > > > ___
> > > > U-Boot mailing list
> > > > U-Boot@lists.denx.de
> > > > https://lists.denx.de/listinfo/u-boot
> > > 
> > > 
> > > 
> > > 
> > > Best regards,
> > > 
> > > Lukasz Majewski
> > > 
> > > --
> > > 
> > > DENX Software Engineering GmbH,  Managing Director: Wolfgang
> > > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> > > Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:
> > > w...@denx.de
> > > 
> > 
> > indeed that is correct, the c2 has a singed binary.
> > as said in my mail, I'm using buildroot to create my images, at the
> > end buildroot takes the file u-boot.bin and burn it into the image at
> > a specific location. the c2 readme explains how to extract the signed
> > blob but I'd expect that it will overwrite part of the u-boot.bin
> > file and no replace it. so I assume I'm missing a part. e.g.
> > u-boot.bin isn't the only file needed from u-boot. am I correct?
> 
> I can only speak by having some experience with Odroid XU3.
> 
> XU3 had bl1.bin.hardkernel, which was signed (and this corresponds to
> u-boot's SPL binary).
> 
> This bl1 called "normal" u-boot (u-boot.bin).
> 
> And afterwards u-boot was calling uImage + DTB.
> 
> There was also problem with the eMMC layout - you had to jump somewhere
> else since the default "partition" for u-boot (512 KiB) was too small.
> 
> Also please pay a note if you need any TZW (trust zone) firmware for
> your platform.
> 
> Have you found any info on hardkerne's wiki/forum?
> 
> > 
> > Thanks.
> > 
> > Dagg.
> 
> 
> 
> 
> Best regards,
> 
> Lukasz Majewski

yes, I did asked a question regarding this but didn't got any answer.
I've decided to ask the uboot devs as from what I understand, the hardkernel 
guys must comply with uboot's guidelines.

so my question is, does u-boot.bin is the only product from u-boot which is 
added into the image?

Thanks,

Dagg.

Dagg.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 07/16] usb: hub: Translate USB 3.0 hub port status into old version

[Bin Meng]

Hi Marek,

On Tue, Jun 27, 2017 at 7:57 AM, Bin Meng  wrote:
> Hi Marek,
>
> On Tue, Jun 27, 2017 at 2:06 AM, Marek Vasut  wrote:
>> On 06/24/2017 03:53 AM, Bin Meng wrote:
>>> Hi Marek,
>>>
>>> On Sat, Jun 24, 2017 at 1:59 AM, Marek Vasut  wrote:
 On 06/23/2017 11:54 AM, Bin Meng wrote:
> USB 3.0 hub port status field has different bit positions from 2.0
> hubs. Since U-Boot only understands the old version, translate the
> new one into the old one.

 This is quite hairy. I'd rather see some protocol version agnostic flag
 field rather than patching the wPortStatus and co.

>>>
>>> I am not sure how do do that in a clean way. If we return the raw 3.0
>>> hub port status data, that means we need change lot of hub codes here
>>> and there to do different parsing.
>>
>> How does Linux handle this?
>
> Looks Linux is doing different parsing depending on hub is 3.0 or 2.0,
> at least for the power bit that I was just looking at. Do you want to
> do that?

OK, I will do something similar like Linux in v2.

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] ARM: make memset and memcpy prompt message more clearly

[Andy Yan]

The origin SPL_USE_ARCH_MEMSET/MEMCPY use same prompt message
as USE_ARCH_MEMSET/MEMCPY, which makes it's hard to distinguish
them in menuconfig interface. This patch gives them different
prompt messages for spl and none-spl config.

Signed-off-by: Andy Yan 
---

 arch/arm/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 46183ae..59206b8 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -253,7 +253,7 @@ config USE_ARCH_MEMCPY
  but may increase the binary size.
 
 config SPL_USE_ARCH_MEMCPY
-   bool "Use an assembly optimized implementation of memcpy"
+   bool "Use an assembly optimized implementation of memcpy for spl"
default y if USE_ARCH_MEMCPY
depends on !ARM64
help
@@ -271,7 +271,7 @@ config USE_ARCH_MEMSET
  but may increase the binary size.
 
 config SPL_USE_ARCH_MEMSET
-   bool "Use an assembly optimized implementation of memset"
+   bool "Use an assembly optimized implementation of memset for spl"
default y if USE_ARCH_MEMSET
depends on !ARM64
help
-- 
2.7.4


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 05/16] usb: hub: Add a new API to test if a hub device is root hub

[Bin Meng]

Hi Marek,

On Sat, Jun 24, 2017 at 1:55 AM, Marek Vasut  wrote:
> On 06/23/2017 11:54 AM, Bin Meng wrote:
>> Sometimes we need know if a given hub device is root hub or not.
>> Add a new API to test this.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>  common/usb_hub.c | 10 ++
>>  include/usb.h|  8 
>>  2 files changed, 18 insertions(+)
>>
>> diff --git a/common/usb_hub.c b/common/usb_hub.c
>> index 18bd827..d780251 100644
>> --- a/common/usb_hub.c
>> +++ b/common/usb_hub.c
>> @@ -74,6 +74,16 @@ static inline bool usb_hub_is_superspeed(struct 
>> usb_device *hdev)
>>   return hdev->descriptor.bDeviceProtocol == 3;
>>  }
>>
>> +#ifdef CONFIG_DM_USB
>> +bool usb_hub_is_root_hub(struct udevice *hub)
>> +{
>> + if (device_get_uclass_id(hub->parent) != UCLASS_USB_HUB)
>
> Can this call fail ?

No,

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v10 3/6] arm: socfpga: Convert FPGA and FPGA_ALTERA configuration to Kconfig

[Chee, Tien Fong]

On Sel, 2017-06-27 at 09:45 -0500, Dinh Nguyen wrote:
> 
> On 06/07/2017 11:33 PM, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > This converts the following to Kconfig:
> >    CONFIG_FPGA
> >    CONFIG_FPGA_ALTERA
> > 
> > Signed-off-by: Tien Fong Chee 
> > ---
> >  configs/astro_mcf5373l_defconfig| 1 +
> >  configs/theadorable_debug_defconfig | 1 +
> >  configs/theadorable_defconfig   | 1 +
> >  include/configs/astro_mcf5373l.h| 2 --
> >  include/configs/theadorable.h   | 2 --
> >  5 files changed, 3 insertions(+), 4 deletions(-)
> > 
> The commit header of this patch is wrong. This patch has nothing to
> do
> with "arm: socfpga"
> 
Okay, i will change that.

> Dinh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v10 5/6] drivers: Enable FPGA driver build on SPL

[Chee, Tien Fong]

On Sel, 2017-06-27 at 00:56 -0500, Dinh Nguyen wrote:
> 
> On 06/07/2017 11:33 PM, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > Enable FPGA driver build for SPL because FPGA driver is needed for
> > SPL
> > to configure and getting DDR up before loading U-boot into DDR and
> > booting from there.
> > 
> > FPGA driver build on SPL must be enabled 1st before applying patch
> > 8 to
> This message referring to "patch 8" is useless when this patch is
> applied. Please refer to a patch title.
> 
That is old message from v9 patchset, i will clean up in next version.
> 
> > 
> > avoid build failed, because fpga_manager which would be moved to
> > drivers/fpga and those functions are expected to be available in
> > SPL.
> > 
> > Signed-off-by: Tien Fong Chee 
> > ---
> >  drivers/Makefile | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/Makefile b/drivers/Makefile
> > index 64c39d3..4478212 100644
> > --- a/drivers/Makefile
> > +++ b/drivers/Makefile
> > @@ -48,6 +48,7 @@ obj-$(CONFIG_OMAP_USB_PHY) += usb/phy/
> >  obj-$(CONFIG_SPL_SATA_SUPPORT) += block/
> >  obj-$(CONFIG_SPL_USB_HOST_SUPPORT) += block/
> >  obj-$(CONFIG_SPL_MMC_SUPPORT) += block/
> > +obj-$(CONFIG_SPL_FPGA_SUPPORT) += fpga/
> >  endif
> >  
> >  ifdef CONFIG_TPL_BUILD
> > 
> Dinh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v10 0/6] Add Intel Arria 10 SoC FPGA driver

[Chee, Tien Fong]

On Sel, 2017-06-27 at 09:56 -0500, Dinh Nguyen wrote:
> 
> On 06/07/2017 11:33 PM, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > This is the 10th version of patchset to adds support for Intel
> > Arria 10 SoC FPGA
> > driver. This version mainly resolved comments from Marek in [v9].
> > This series is working on top of u-boot-socfpga.git - http://git.de
> > nx.de/u-boot-socfpga.git
> > 
> > [v9]: https://www.mail-archive.com/u-boot@lists.denx.de/msg252422.h
> > tml
> > 
> > v9 -> v10 changes:
> > -
> > - Moved astro_mcf5373_defocnfig into patch 3(v10).
> > - Keep fpga_manager intact by removing patch 6(v9) and patch 7(v9).
> > 
> > Patchset history
> > 
> > [v1]: https://www.mail-archive.com/u-boot@lists.denx.de/msg247788.h
> > tml
> > [v2]: https://www.mail-archive.com/u-boot@lists.denx.de/msg248541.h
> > tml
> > [v3]: https://www.mail-archive.com/u-boot@lists.denx.de/msg249160.h
> > tml
> > [v4]: https://www.mail-archive.com/u-boot@lists.denx.de/msg250149.h
> > tml
> > [v5]: https://www.mail-archive.com/u-boot@lists.denx.de/msg250517.h
> > tml
> > [v6]: https://www.mail-archive.com/u-boot@lists.denx.de/msg250687.h
> > tml
> > [v7]: https://www.mail-archive.com/u-boot@lists.denx.de/msg251213.h
> > tml
> > [v8]: https://www.mail-archive.com/u-boot@lists.denx.de/msg252196.h
> > tml
> > 
> For the whole series, besides the few minor-nits, please add
> 
> Reviewed-by: Dinh Nguyen 
> 
> FYI: please add endorsement signatures that you have received on any
> subsequent versions of the patch series. This lets people know that
> at
> least somebody has reviewed you patch so that we don't have to hunt
> down
> previous responses.
> 
Okay.

> Dinh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH V7 4/4] rockchip: rk3288: enable rockusb support on rk3288 based device

[Lukasz Majewski]

Hi Eddie,

> Hi Lukasz
> 
> 2017-06-21 15:44 GMT+08:00 Lukasz Majewski :
> > Hi Eddie,
> >
> >> Hi Eddie,
> >>
> >> > 2017-05-31 15:12 GMT+08:00 Lukasz Majewski :
> >> > > On Wed, 31 May 2017 10:27:23 +0800
> >> > > Eddie Cai  wrote:
> >> > >
> >> > >> Hi Lukasz
> >> > >>
> >> > >> 2017-05-29 15:51 GMT+08:00 Lukasz Majewski :
> >> > >> > Good morning Eddie,
> >> > >> >
> >> > >> >> this patch enable rockusb support on rk3288 based device.
> >> > >> >>
> >> > >> >> Signed-off-by: Eddie Cai 
> >> > >> >> Reviewed-by: Simon Glass 
> >> > >> >>
> >> > >> >
> >> > >> > I've give this patch set a try on travisCI:
> >> > >> >
> >> > >> > https://travis-ci.org/lmajewski/u-boot-dfu/jobs/237068149
> >> > >> >
> >> > >> > Unfortunately, there are some problem with following boards:
> >> > >> >
> >> > >> > chromebook_jerry, chromebook_minnie ...
> >> > >> I did it by myself last week. i got the same error. then i fix
> >> > >> those chromebook error
> >> > >> and test again. I still got some 3036 board error. But it
> >> > >> build successfully when i
> >> > >> build it on my computer. here is the travis-ci.org error log
> >> > >> https://travis-ci.org/eddiecailinux/u-boot/jobs/236232837
> >> > >> I have no idea what can i do to fix it.
> >> > >
> >> > > Can you share the SHA1 of commit on top of which you applied
> >> > > your patches?
> >> > >
> >> > > I take u-boot-usb (the USB u-boot tree from Marek Vasut) as a
> >> > > base and then apply commits on top of it.
> >> > here is my branch
> >> > https://github.com/eddiecailinux/u-boot/tree/rockusb-v8 I apply
> >> > my patch on top of below commit commit
> >> > a63d800196ebee59b0f8ff924f67843cd597a8c1 Author: Tom Rini
> >> >  Date:   Mon May 1 19:54:41 2017 -0400
> >> >
> >> > Prepare v2017.05-rc3
> >> >
> >> > Signed-off-by: Tom Rini 
> >>
> >> I've looked thoroughly at your patches:
> >>
> >> Your patches has been applied on top of the above commit:
> >> SHA1: a63d800196ebee59b0f8ff924f67843cd597a8c1
> >>
> >> Before applying your patches:
> >> https://travis-ci.org/lmajewski/u-boot-dfu/builds/239069544
> >>
> >> After applying them:
> >> https://travis-ci.org/lmajewski/u-boot-dfu/builds/239074799
> >>
> >> To be more precise:
> >> https://travis-ci.org/lmajewski/u-boot-dfu/jobs/239074800
> >>
> >>
> >> For example:
> >>
> >>   arm:  +   rock2
> >> +cmd/built-in.o: In function `do_fastboot':
> >> +cmd/fastboot.c:28: undefined reference to `board_usb_init'
> >> +cmd/fastboot.c:34: undefined reference to `g_dnl_clear_detach'
> >> +cmd/fastboot.c:35: undefined reference to `g_dnl_register'
> >> +cmd/fastboot.c:39: undefined reference to
> >>   `g_dnl_board_usb_cable_connected' +cmd/fastboot.c:57:
> >> undefined reference to `g_dnl_unregister' +cmd/fastboot.c:58:
> >> undefined reference to `g_dnl_clear_detach' +cmd/fastboot.c:59:
> >> undefined reference to `board_usb_cleanup' +cmd/fastboot.c:47:
> >> undefined reference to `g_dnl_detach' +cmd/fastboot.c:51: undefined
> >>   reference to `usb_gadget_handle_interrupts' +cmd/built-in.o:
> >> In function `do_usb_mass_storage':
> >>
> >>
> >>
> >> For me it seems like you have enabled fastboot support on too many
> >> rochchip's boards.
> >>
> >> Can you look on it?
> >
> > If I might ask - have you managed to investigate this issue?
> I can fix the chromebook error.

Ok.

> But i didn't enable rockusb support on
> rk3036 based board. I built these board on my desktop. It work fine.

The issue is not with this one particular board.

I'm concerned, since your patch set causes build errors for other
boards.

Can you build test (with travis-CI) your patches and check if you can
reproduce those errors?

Best regards,
Łukasz

> >
> >>
> >> I've also updated my .travis.ml file to be in sync with mainline,
> >> so we will use recommended arm toolchain.
> >>
> >> Please find this file attached.
> >>
> >> If there are any other patches required before applying this patch
> >> series, please let me know (or better post them to ML).
> >>
> >>
> >> Best regards,
> >> Łukasz Majewski
> >>
> >> > >
> >> > >> >
> >> > >> > caused by "undefined references to "
> >> > >> >
> >> > >> > I've tried your patches on top of:
> >> > >> > u-boot-usb/HEAD
> >> > >> > SHA1: 3426b2038cfb831d74ac0407fc7a04e990b44540
> >> > >> >
> >> > >> > Maybe you have built tested it on other branch/commit?
> >> > >> >
> >> > >> > Best regards,
> >> > >> > Łukasz Majewski
> >> > >> >
> >> > >> > p.s. My travis CI .travis.yml attached.
> >> > >> >
> >> > >> >> Changes in v7:
> >> > >> >> -use imply in the Kconfig to enable rockusb
> >> > >> >>
> >> > >> >> Changes in v6:
> >> > >> >> -enable rockusb in defconfig
> >> > >> >>
> >> > >> >> Changes in v5:
> >> > >> >> -none
> >> > >> >>
> >> > >> >> Changes in v4:
> >> > >> >> -move to rk3288_common.h
> >> > >> >>
> >> > >> >> Changes in 

Re: [U-Boot] [PATCH V7 4/4] rockchip: rk3288: enable rockusb support on rk3288 based device

[Eddie Cai]

Hi Lukasz

2017-06-21 15:44 GMT+08:00 Lukasz Majewski :
> Hi Eddie,
>
>> Hi Eddie,
>>
>> > 2017-05-31 15:12 GMT+08:00 Lukasz Majewski :
>> > > On Wed, 31 May 2017 10:27:23 +0800
>> > > Eddie Cai  wrote:
>> > >
>> > >> Hi Lukasz
>> > >>
>> > >> 2017-05-29 15:51 GMT+08:00 Lukasz Majewski :
>> > >> > Good morning Eddie,
>> > >> >
>> > >> >> this patch enable rockusb support on rk3288 based device.
>> > >> >>
>> > >> >> Signed-off-by: Eddie Cai 
>> > >> >> Reviewed-by: Simon Glass 
>> > >> >>
>> > >> >
>> > >> > I've give this patch set a try on travisCI:
>> > >> >
>> > >> > https://travis-ci.org/lmajewski/u-boot-dfu/jobs/237068149
>> > >> >
>> > >> > Unfortunately, there are some problem with following boards:
>> > >> >
>> > >> > chromebook_jerry, chromebook_minnie ...
>> > >> I did it by myself last week. i got the same error. then i fix
>> > >> those chromebook error
>> > >> and test again. I still got some 3036 board error. But it build
>> > >> successfully when i
>> > >> build it on my computer. here is the travis-ci.org error log
>> > >> https://travis-ci.org/eddiecailinux/u-boot/jobs/236232837
>> > >> I have no idea what can i do to fix it.
>> > >
>> > > Can you share the SHA1 of commit on top of which you applied your
>> > > patches?
>> > >
>> > > I take u-boot-usb (the USB u-boot tree from Marek Vasut) as a base
>> > > and then apply commits on top of it.
>> > here is my branch
>> > https://github.com/eddiecailinux/u-boot/tree/rockusb-v8 I apply my
>> > patch on top of below commit commit
>> > a63d800196ebee59b0f8ff924f67843cd597a8c1 Author: Tom Rini
>> >  Date:   Mon May 1 19:54:41 2017 -0400
>> >
>> > Prepare v2017.05-rc3
>> >
>> > Signed-off-by: Tom Rini 
>>
>> I've looked thoroughly at your patches:
>>
>> Your patches has been applied on top of the above commit:
>> SHA1: a63d800196ebee59b0f8ff924f67843cd597a8c1
>>
>> Before applying your patches:
>> https://travis-ci.org/lmajewski/u-boot-dfu/builds/239069544
>>
>> After applying them:
>> https://travis-ci.org/lmajewski/u-boot-dfu/builds/239074799
>>
>> To be more precise:
>> https://travis-ci.org/lmajewski/u-boot-dfu/jobs/239074800
>>
>>
>> For example:
>>
>>   arm:  +   rock2
>> +cmd/built-in.o: In function `do_fastboot':
>> +cmd/fastboot.c:28: undefined reference to `board_usb_init'
>> +cmd/fastboot.c:34: undefined reference to `g_dnl_clear_detach'
>> +cmd/fastboot.c:35: undefined reference to `g_dnl_register'
>> +cmd/fastboot.c:39: undefined reference to
>>   `g_dnl_board_usb_cable_connected' +cmd/fastboot.c:57: undefined
>>   reference to `g_dnl_unregister' +cmd/fastboot.c:58: undefined
>>   reference to `g_dnl_clear_detach' +cmd/fastboot.c:59: undefined
>>   reference to `board_usb_cleanup' +cmd/fastboot.c:47: undefined
>>   reference to `g_dnl_detach' +cmd/fastboot.c:51: undefined
>>   reference to `usb_gadget_handle_interrupts' +cmd/built-in.o: In
>>   function `do_usb_mass_storage':
>>
>>
>>
>> For me it seems like you have enabled fastboot support on too many
>> rochchip's boards.
>>
>> Can you look on it?
>
> If I might ask - have you managed to investigate this issue?
I can fix the chromebook error. But i didn't enable rockusb support on
rk3036 based board. I built these board on my desktop. It work fine.
>
>>
>> I've also updated my .travis.ml file to be in sync with mainline, so
>> we will use recommended arm toolchain.
>>
>> Please find this file attached.
>>
>> If there are any other patches required before applying this patch
>> series, please let me know (or better post them to ML).
>>
>>
>> Best regards,
>> Łukasz Majewski
>>
>> > >
>> > >> >
>> > >> > caused by "undefined references to "
>> > >> >
>> > >> > I've tried your patches on top of:
>> > >> > u-boot-usb/HEAD
>> > >> > SHA1: 3426b2038cfb831d74ac0407fc7a04e990b44540
>> > >> >
>> > >> > Maybe you have built tested it on other branch/commit?
>> > >> >
>> > >> > Best regards,
>> > >> > Łukasz Majewski
>> > >> >
>> > >> > p.s. My travis CI .travis.yml attached.
>> > >> >
>> > >> >> Changes in v7:
>> > >> >> -use imply in the Kconfig to enable rockusb
>> > >> >>
>> > >> >> Changes in v6:
>> > >> >> -enable rockusb in defconfig
>> > >> >>
>> > >> >> Changes in v5:
>> > >> >> -none
>> > >> >>
>> > >> >> Changes in v4:
>> > >> >> -move to rk3288_common.h
>> > >> >>
>> > >> >> Changes in v3:
>> > >> >> -move to defconfig
>> > >> >>
>> > >> >> ---
>> > >> >>  arch/arm/mach-rockchip/Kconfig| 2 ++
>> > >> >>  configs/evb-rk3288_defconfig  | 9 +
>> > >> >>  configs/fennec-rk3288_defconfig   | 6 ++
>> > >> >>  configs/firefly-rk3288_defconfig  | 6 ++
>> > >> >>  configs/miqi-rk3288_defconfig | 6 ++
>> > >> >>  configs/popmetal-rk3288_defconfig | 6 ++
>> > >> >>  configs/tinker-rk3288_defconfig   | 6 ++
>> > >> >>  include/configs/rk3288_common.h