[U-Boot] [usb] dwc3 -- phy -- hub: a hint/help/an idea needed.
Hi,
Any ideas/hints needed with regard to dwc3 -- phy -- hub support on a custom
board.
I've been struggling with u-boot implementation of usb support on a mips32-based
development board (a SoC with DWC3 integrated).
SoC has the ULPI interface, and by means of it, it's connected to USB 2.0 phy
(Microchip USB3315),
and down the stream, the phy is connected to USB hub chip (smsc usb2422) using
of usb 2.0 interface.
I've been able to verify, that USB hub chip has proper power and, when dwc3
generates proper USB commands,
the hub is kinda activated and on the pad XTALIN/CLKIN (pad #22) I can see a
proper-shaped 24 mhz clock
(an oscilloscope was hooked up). But the hub is not configured properly, since
the LED indicator
(connected to the pad #17 of the hub) never blinks (it's the indication that
the hub has been configured properly).
USB protocol hangs up after xhci_queue_command (TRB_ENABLE_SLOT): the host
never receives indication from the hub
(event->event_cmd.flags never changes from 0) => xhci stack issues BUG() ==>
Reset CPU by CPC.
I presume, that hardware is ok, since after linux kernel has been loaded, the
hub works just properly.
We don't have any gpios involved, any ULPI viewport windows, indeed nothing
which would allow me to
configure the phy or the hub itselves. In fact, as far as I understand, the phy
and the hub
shouldn't be configured by software and (in our setup at least) intended to be
software-transparent.
The code in linux which activates the usb, in essence just updates the clocks
infrastructure:
dwc->clk = devm_clk_get(dwc->dev, "usb");
if (IS_ERR(dwc->clk)) {
dev_err(dev, "no interface clk specified\n");
return -EINVAL;
}
ret = clk_prepare_enable(dwc->clk);
and I verified, that the necessary clocks are all enabled in u-boot (the
necessary bits are on in proper addresses).
# usb start
(Re)start USB...
USB0: baikal-xhci: init hccr bf10 and hcor bf100020 hc_length 32
// Halt the HC: bf100020
// Reset the HC
Register 1000140 NbrPorts 1
Starting the controller
USB XHCI 1.00
scanning bus 0 for devices... New Device 0
common/usb.c:938 TMPBUF: a7e30a00
--- usb_set_address(dev) ---
set address 1
usb_control_msg: request: 0x5, requesttype: 0x0, value 0x1 index 0x0 length 0x0
USB_REQ_SET_ADDRESS
scrlen = 0
req->length = 0
Len is 0
--- usb_get_descriptor(USB_DT_DEVICE) ---
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length
0x12
USB_DT_DEVICE request
scrlen = 18
req->length = 18
-- returned from usb_get_descriptor.
bcdUSB:0x300
idVendor: 0x0
idProduct: 0x0
bcdDevice: 0x100
--- usb_get_configuration_no(dev, tmpbuf, 0) ---
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length
0x9
USB_DT_CONFIG config
scrlen = 25
req->length = 9
: 09 02 1f 00 01 01 00 40 00 ...@.
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length
0x1F
USB_DT_CONFIG config
scrlen = 25
req->length = 31
: 09 02 1f 00 01 01 00 40 00 09 04 00 00 01 09 00...@
0010: 00 00 07 05 81 03 08 00 ff 77 6d 61 63 2e 62 .wmac.b
get_conf_no 0 Result 25, wLength 31
--- usb_parse_config(dev, tmpbuf, 0) ---
if 0, ep 0
unknown Description Type : 6d
77 6D 61 63 2E 62 66 30 36 30 30 30 30 00 A7 0C 00 00 00 28 4F F6 A7 58 0A E3
A7 58 0A E3 A7 C8 B9 FA A7 28 4F
--- usb_set_maxpacket(dev) ---
##EP epmaxpacketin[1] = 8
new device strings: Mfr=1, Product=2, SerialNumber=0
--- usb_string iProduct ---
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x300 index 0x0 length
0xFF
USB_DT_STRING config
scrlen = 4
req->length = 255
USB device number 1 default language ID 0x409
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x302 index 0x409
length 0xFF
USB_DT_STRING config
scrlen = 42
req->length = 255
--- usb_string iManufacturer ---
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index 0x409
length 0xFF
USB_DT_STRING config
scrlen = 14
req->length = 255
--- usb_string iSerialNumber ---
Manufacturer U-Boot
Product XHCI Host Controller
SerialNumber
--- usb_set_configuration ---
set configuration 1
usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length 0x0
scrlen = 0
req->length = 0
Len is 0
USB hub found
HUB IS SUPERSPEED, dtype 0x2a, dtype << 8 0x2a00
USB_DT_HUB: 0x29, USB_DT_SS_HUB: 0x2a
usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2A00 index 0x0 length
0x4
USB_DT_HUB config
scrlen = 8
req->length = 4
: 0c 2a 01 08 ff ff ff ff ff ff ff ff.*..
HUB IS SUPERSPEED, dtype 0x2a, dtype << 8 0x2a00
USB_DT_HUB: 0x29, USB_DT_SS_HUB: 0x2a
usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2A00 index 0x0 length
0xC
USB_DT_HUB config
scrlen = 8
req->length = 12
: 0c 2a 01 08 00 0a 00 00 ff ff ff ff.*..
1 ports detected
hubCharacteristics: 0x8
ganged power switching
standalone hub
individual port over-current
[U-Boot] [usb] dwc3 -- phy -- hub: a hint/help/an idea needed.
Hi,
Any ideas/hints needed with regard to dwc3 -- phy -- hub support on a custom
board.
I've been struggling with u-boot implementation of usb support on a mips32-based
development board (a SoC with DWC3 integrated).
SoC has the ULPI interface, and by means of it, it's connected to USB 2.0 phy
(Microchip USB3315),
and down the stream, the phy is connected to USB hub chip (smsc usb2422) using
of usb 2.0 interface.
I've been able to verify, that USB hub chip has proper power and, when dwc3
generates proper USB commands,
the hub is kinda activated and on the pad XTALIN/CLKIN (pad #22) I can see a
proper-shaped 24 mhz clock
(an oscilloscope was hooked up). But the hub is not configured properly, since
the LED indicator
(connected to the pad #17 of the hub) never blinks (it's the indication that
the hub has been configured properly).
USB protocol hangs up after xhci_queue_command (TRB_ENABLE_SLOT): the host
never receives indication from the hub
(event->event_cmd.flags never changes from 0) => xhci stack issues BUG() ==>
Reset CPU by CPC.
I presume, that hardware is ok, since after linux kernel has been loaded, the
hub works just properly.
We don't have any gpios involved, any ULPI viewport windows, indeed nothing
which would allow me to
configure the phy or the hub itselves. In fact, as far as I understand, the phy
and the hub
shouldn't be configured by software and (in our setup at least) intended to be
software-transparent.
The code in linux which activates the usb, in essence just updates the clocks
infrastructure:
dwc->clk = devm_clk_get(dwc->dev, "usb");
if (IS_ERR(dwc->clk)) {
dev_err(dev, "no interface clk specified\n");
return -EINVAL;
}
ret = clk_prepare_enable(dwc->clk);
and I verified, that the necessary clocks are all enabled in u-boot (the
necessary bits are on in proper addresses).
# usb start
(Re)start USB...
USB0: baikal-xhci: init hccr bf10 and hcor bf100020 hc_length 32
// Halt the HC: bf100020
// Reset the HC
Register 1000140 NbrPorts 1
Starting the controller
USB XHCI 1.00
scanning bus 0 for devices... New Device 0
common/usb.c:938 TMPBUF: a7e30a00
--- usb_set_address(dev) ---
set address 1
usb_control_msg: request: 0x5, requesttype: 0x0, value 0x1 index 0x0 length 0x0
USB_REQ_SET_ADDRESS
scrlen = 0
req->length = 0
Len is 0
--- usb_get_descriptor(USB_DT_DEVICE) ---
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length
0x12
USB_DT_DEVICE request
scrlen = 18
req->length = 18
-- returned from usb_get_descriptor.
bcdUSB:0x300
idVendor: 0x0
idProduct: 0x0
bcdDevice: 0x100
--- usb_get_configuration_no(dev, tmpbuf, 0) ---
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length
0x9
USB_DT_CONFIG config
scrlen = 25
req->length = 9
: 09 02 1f 00 01 01 00 40 00 ...@.
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length
0x1F
USB_DT_CONFIG config
scrlen = 25
req->length = 31
: 09 02 1f 00 01 01 00 40 00 09 04 00 00 01 09 00...@
0010: 00 00 07 05 81 03 08 00 ff 77 6d 61 63 2e 62 .wmac.b
get_conf_no 0 Result 25, wLength 31
--- usb_parse_config(dev, tmpbuf, 0) ---
if 0, ep 0
unknown Description Type : 6d
77 6D 61 63 2E 62 66 30 36 30 30 30 30 00 A7 0C 00 00 00 28 4F F6 A7 58 0A E3
A7 58 0A E3 A7 C8 B9 FA A7 28 4F
--- usb_set_maxpacket(dev) ---
##EP epmaxpacketin[1] = 8
new device strings: Mfr=1, Product=2, SerialNumber=0
--- usb_string iProduct ---
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x300 index 0x0 length
0xFF
USB_DT_STRING config
scrlen = 4
req->length = 255
USB device number 1 default language ID 0x409
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x302 index 0x409
length 0xFF
USB_DT_STRING config
scrlen = 42
req->length = 255
--- usb_string iManufacturer ---
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index 0x409
length 0xFF
USB_DT_STRING config
scrlen = 14
req->length = 255
--- usb_string iSerialNumber ---
Manufacturer U-Boot
Product XHCI Host Controller
SerialNumber
--- usb_set_configuration ---
set configuration 1
usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length 0x0
scrlen = 0
req->length = 0
Len is 0
USB hub found
HUB IS SUPERSPEED, dtype 0x2a, dtype << 8 0x2a00
USB_DT_HUB: 0x29, USB_DT_SS_HUB: 0x2a
usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2A00 index 0x0 length
0x4
USB_DT_HUB config
scrlen = 8
req->length = 4
: 0c 2a 01 08 ff ff ff ff ff ff ff ff.*..
HUB IS SUPERSPEED, dtype 0x2a, dtype << 8 0x2a00
USB_DT_HUB: 0x29, USB_DT_SS_HUB: 0x2a
usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2A00 index 0x0 length
0xC
USB_DT_HUB config
scrlen = 8
req->length = 12
: 0c 2a 01 08 00 0a 00 00 ff ff ff ff.*..
1 ports detected
hubCharacteristics: 0x8
ganged power switching
standalone hub
individual port over-current protection
TT
[U-Boot] [mips, usb xhci] Question / advice needed: cacheable adresses as a device output buffers?
Is it possible to use *cached* addresses as device's output buffer? E.g, is it a correct thing, to read an uImage from USB pen to cacheable addresses in order to boot from these cached area? U-Boot 2014.10-00051-g8cb056b-dirty / SDK (May 15 2018 - 17:11:35) CPU: MIPS32 P5600 @ 1200 MHz (Rev 1.0) FPU: Present Cores: 2 (running on CPU0) Timer: 600 MHz ECC: L1 L2 (80800ff0) PLLs: CPU: 1200MHz SATA: 600MHz ETH:1250MHz PCIE:1200MHz DDR3: 400MHz AXI: 600MHz Board: Baikal-T1 BFK3 Watchdog enabled I2C: ready DRAM: Rank = 1 highmem = 1792 MiB lowmem = 128 MiB NVRAM: ready Rev: 3.1 MIPS: SIMD ready MIPS: Write Merge enable MIPS: MAAR[0]: 0x0001-0x07ff speculate MIPS: secondary cache 1024kB, 8-way, linesize 32 bytes. In:serial Out: serial Err: serial RomID: 20ba18102360907301001500102604164781 Net: dwmac.bf05e000, dwmac.bf06 First, read a file to cacheable adresses: # usb start; fatload usb 0:1 8100 uimage.nfs (Re)start USB... USB0: Register 1000140 NbrPorts 1 Starting the controller USB XHCI 1.00 scanning bus 0 for devices... 2 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found reading uimage.nfs 4630013 bytes read in 2532 ms (1.7 MiB/s) BAIKAL # md 8100 8100: 8110: 8120: 8130: 8140: 8150: 8160: 8170: 8180: 8190: 81a0: 81b0: 81c0: 81d0: 81e0: 81f0: Then, to the uncacheable area: # usb start; fatload usb 0:1 a100 uimage.nfs (Re)start USB... USB0: Register 1000140 NbrPorts 1 Starting the controller USB XHCI 1.00 scanning bus 0 for devices... 2 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found reading uimage.nfs 4630013 bytes read in 2531 ms (1.7 MiB/s) BAIKAL # md a100 a100: 56190527 1697a1a2 0107d65a bda54600'..VZF.. a110: 1080 d0618780 1644ad13 01020505..a...D. a120: 756e694c 2e342d78 31312e34 66622d38Linux-4.4.118-bf a130: 302d336b 3335 6361672d 66623237k3-05333-gac72bf a140: 00088b1f 7dec0302 655c7c7d...}}|\e a150: ce6fef9d eda6499c 69da4f40 3300be99..o..I..@O.i...3 a160: 691a49ed 880701c0 9261ca32 495d80be.I.i2.a...]I a170: dd04505f 9794931d d5dbdc5d 72c4a2b2_P..]..r a180: 7418a648 5a2c44cc d243745d a6430294H..t.D,Z]tC...C. a190: 0af17960 74540b12 dd5652f5 12baeecb`yTt.RV. a1a0: 7c50575d 0a5655e9 fbf739b4 9273ce7d]WP|.UV..9..}.s. a1b0: 7ad69a69 ee3fdef7 e4f9f247 f39e7333i..z..?.G...3s.. a1c0: f7e7bf3c cf7fdefc f1bc88db 1bdfc6f7<... a1d0: 7faa7f7f 454b9f9b f45f9fab c9665b1e..KE.._..[f. a1e0: ae9dcaee e3cb8d95 3395f895 653f2f62...3b/?e a1f0: d6e9dc8e f2f4b9f0 bc069153 d4f75d2fS.../].. and, exactly after loading/reading from uncached addresses: # md 8100 8100: 8110: 8120: 8130: 8140: 8150: 8160: 8170: 8180: 8190: 81a0: 7c50575d 0a5655e9 fbf739b4 9273ce7d]WP|.UV..9..}.s. 81b0: 7ad69a69 ee3fdef7 e4f9f247 f39e7333i..z..?.G...3s.. 81c0: 81d0: 81e0: 81f0: From the config for the board: #define CONFIG_SYS_SDRAM_BASE 0x8000 /* Only one
[U-Boot] [usb dwc3] xHCI driver -- a hint needed.
Hi,
I've been trying to bring up a dwc3 usb controller included in 32-bit MIPS chip.
Usb is the one port usb2.0 host module, compliant with xHCI Revision 1.0, UTMI+
Low Pin interface (ULPI) Revision 1.1 and AMBA AXI Protocol specification.
g_snpsid register reports 0x5533290a revision.
It's verified, that linux kernel support is ok, usb is fully functional.
axi {
<...>
usb@1F04D050 {
compatible = "be,baikal-dwc3";
reg = <0x1f04d050 0x4>;
interrupts = <0x0 0x45 0x4>;
#address-cells = <0x1>;
#size-cells = <0x1>;
clocks = <0xf 0x0>;
clock-names = "usb";
ranges;
status = "okay";
dwc3@1F10 {
compatible = "snps,dwc3", "synopsys,dwc3",
"generic-xhci";
reg = <0x1f10 0x1>;
interrupts = <0x0 0x44 0x4>;
dr_mode = "host";
tx-fifo-resize;
maximum-speed = "high-speed";
};
};
};
whereas in u-boot 'usb start' fails on hub initialization (as I can see):
Any ideas why this could happen?.. Any direction where to look at?
Any suggestions will be greatly appreciated.
# usb start
(Re)start USB...
USB0: dwc3_reg->g_snpsid: 0x5533290a
Register 1000140 NbrPorts 1
Starting the controller
USB XHCI 1.00
scanning bus 0 for devices... New Device 0
set address 1
usb_control_msg: request: 0x5, requesttype: 0x0, value 0x1 index 0x0 length 0x0
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length
0x12
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length
0x9
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length
0x1F
get_conf_no 0 Result 25, wLength 31
if 0, ep 0
##EP epmaxpacketin[1] = 8
set configuration 1
usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length 0x0
new device strings: Mfr=1, Product=2, SerialNumber=0
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x300 index 0x0 length
0xFF
USB device number 1 default language ID 0x409
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index 0x409
length 0xFF
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x302 index 0x409
length 0xFF
Manufacturer U-Boot
Product XHCI Host Controller
SerialNumber
USB hub found
usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2A00 index 0x0 length
0x4
usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2A00 index 0x0 length
0xC
1 ports detected
ganged power switching
standalone hub
individual port over-current protection
TT requires at most 8 FS bit times (666 ns)
power on to power good time: 20ms
hub controller current requirement: 0mA
port 1 is removable
usb_control_msg: request: 0x0, requesttype: 0xA0, value 0x0 index 0x0 length 0x4
get_hub_status returned status 1, change 801
local power source is lost (inactive)
no over-current condition exists
enabling power on all ports
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1 length 0x0
port 1 returns 0
devnum=1 poweron: query_delay=100 connect_timeout=1100
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4
Port 1 Status 101 Change 1
devnum=1 port=1: USB dev found
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4
portstatus 101, change 1, 12 Mb/s
usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x1 length
0x0
usb_hub_port_reset: resetting port 1...
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1 length 0x0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4
portstatus 111, change 0, 12 Mb/s
STAT_C_CONNECTION = 0 STAT_CONNECTION = 1 USB_PORT_STAT_ENABLE 0
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1 length 0x0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4
portstatus 503, change 10, 480 Mb/s
STAT_C_CONNECTION = 0 STAT_CONNECTION = 1 USB_PORT_STAT_ENABLE 1
usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x1 length
0x0
New Device 1
XHCI timeout on event type 33... cannot recover.
BUG: failure at drivers/usb/host/xhci-ring.c:474/xhci_wait_for_event()!
BUG!
Reset CPU by CPC
Here is the drivers/usb/host/xhci-baikal.c:
#include
#include
#include
#include
#include
#include
#include "xhci.h"
/* Declare global data pointer */
DECLARE_GLOBAL_DATA_PTR;
struct baikal_xhci {
struct xhci_hccr *hcd;
struct dwc3 *dwc3_reg;
};
static struct baikal_xhci baikal;
int __attribute__((weak)) board_usb_init(int index, enum usb_init_type init);
static int baikal_xhci_core_init(struct
[U-Boot] [powerpc NOR flash start address]
Hello, probably an obvious question, but nevertheless... More than a year ago, u-boot binary size was incfreased for powerpc boards (commit e222b1f36fedb0363dbc21e0add7dc3848bae553 powerpc/mpc85xx:Increase binary size for P, B T series boards.), so CONFIG_SYS_TEXT_BASE changed from 0xeff8 to 0xeff4. I've been using Freescale P2041RDB-PA, rev. A board with U-Boot 2011.09-0-g2c02d1d flashed to NOR at 0xeff8 and running properly. I'd like to update u-boot (rcw, fmac microcode, etc) hence, I need to flash u-boot binary at 0xeff4. The question is: which way does hardware know from which NOR flash address to begin to start? After reset, powerpc cpus start to execute code from the 0xfffc address, which is usually (or, to say better - almost always) the last word of NOR flash); there is 0x4bfff004 at that address, which means jump to 0xf000, if I understand it correctly. What code resides here and what does it do? And, more practical question, where (and how) the hardware is given to understand, that it should look for u-boot image at particular NOR address? What (and where) should I fix to change hardware's understanding of u-boot image location from 0xeff8 to 0xeff4? TIA, Yuri ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
