On 16/05/16 14:10, Kishon Vijay Abraham I wrote: > Hi Roger, > > On Monday 16 May 2016 04:01 PM, Roger Quadros wrote: >> 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? > > IIRC it is only for host. Commands like usb start, usb stop are used to start > and stop host. >> Is dual-role even required in u-boot? probably it is not a good idea and we >> just >> ignore it for simplicity. > > yeah. >> >> What determines whether a USB port is meant for Host or device operation? Is >> it >> the CONFIG_ or caller of board_usb_init()? > It should be the caller of board_usb_init(). The same port can be used as > device or host based on command used (the command determines the caller of > board_usb_init).
Then it is upto board_usb_init() to complain if it is called for some mode and the respective drivers are not enabled. board_usb_init() must be defined in the board if CONFIG_CMD_USB || USB_GADGET But there is no single config option for USB_GADGET. people seem to be calling board_usb_init() from all over the place without any dependency on USB_GADGET. e.g. dfu.c, ether.c, fastboot.c, thordown.c, usb_mass_storage.c, ether.c So things will break with various configurations. So probably for now board_usb_init() has to be always defined. cheers, -roger _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot