On 16/05/16 13:03, Kishon Vijay Abraham I wrote: > Hi Roger, > > On Monday 16 May 2016 03:19 PM, Roger Quadros wrote: >> On 16/05/16 12:26, Roger Quadros wrote: >>> On 16/05/16 12:06, Roger Quadros wrote: >>>> On 13/05/16 15:45, Marek Vasut wrote: >>>>> On 05/13/2016 02:36 PM, Roger Quadros wrote: >>>>>> Currently CONFIG_USB_DWC3 is not selected so doing a usb start >>>>>> command results in a serious error [1]. >>>>> >>>>> Why does this error happen ? That is what should be fixed. Selecting >>>>> some random options seems like papering over a bug. >>>> >>>> Agreed. I was lazy :P. >>> >>> OK. The issue is like this. >>> >>> CONFIG_CMD_USB and CONFIG_USB_XHCI is defined, so usb_init() calls >>> usb_lowlevel_init() in xhci.c which calls xhci_hcd_init in xhci-omap.c >>> which calls >>> board_usb_init(). > > IIRC, board_usb_init for xhci (omap) is mostly a NOP.
Then who will call board_usb_init() for host case? >>> >>> But board_usb_init() in am57xx/board.c is defined only if CONFIG_USB_DWC3 >>> is defined >>> and that is missing in am57xx_evm.h leading to the serious error. We're >>> trying to >>> access the IP without turning on the necessary clocks. > > clocks are not turned on in board_usb_init() right? The board_usb_init() in > am57xx/board.c is used only for gadget mode. >>> >>> So it looks like we need to define it based on CONFIG_USB_XHCI_OMAP or >>> something else. > > right, but before that we might have to cleanup xhci-omap. >>> >>> But then again looking into the future, what if we want only gadget >>> operation? >>> That would not define XHCI, but we still need board_usb_init(). So >>> board_usb_init() >>> should be defined based on CONFIG_CMD_USB=y? >>> >>> What do you suggest? >> >> But board_usb_init() calls >> >> ti_usb_phy_uboot_init(&usb_phy1_device); >> dwc3_omap_uboot_init(&usb_otg_ss1_glue); >> dwc3_uboot_init(&usb_otg_ss1); >> >> which depend on CONFIG_USB_DWC3_PHY_OMAP, CONFIG_USB_DWC3_OMAP and >> CONFIG_USB_DWC3 >> respectively. > > IMO we should cleanup xhci-omap so that all the initializations are done using > ti_usb_phy_uboot_init, dwc3_omap_uboot_init and dwc3_uboot_init. Then modify > dwc3_uboot_init to initialize host or device based on CONFIG_*. > I'm still trying to get a grip of how USB works in u-boot. Is CONFIG_CMD_USB only meant for host mode or gadget mode as well? Is dual-role even required in u-boot? probably it is not a good idea and we just ignore it for simplicity. What determines whether a USB port is meant for Host or device operation? Is it the CONFIG_ or caller of board_usb_init()? I see board_usb_init() being used by gadget drivers, host drivers, dfu.c, etc. cheers, -roger _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
