[U-Boot] USB Ethernet with device model
Hi,
I've been working with USB-Ethernet gadget for quite some time on the Allwinner SoCs, especially because most Allwinner boards lack an ethernet controller.
The thing is, it wasn't really upstreamable all this time since we've had also some boards that had a controller with DM_ETH. And usb_ether didn't have DM_ETH support until recently.
So I gave it a shot, and encountered a few weird things that prevented it from working (and still do):
1) I converted our musb glue to support the DM even in the peripheral mode. Here is the code: http://code.bulix.org/m846ni-194479
It almost works, except that usb_scan_bus in usb-uclass.c for some reason unknown to me tries to scan the peripheral device, and fails. Skipping that scan makes fastboot works, so I guess the peripheral is working. Is there any particular reason that the DM_USB code tries to scan even peripheral devices ?
2) I can't manage to get usb_ether to probe after that, using the DM. It seems that we need to call usb_ether_init, and that it looks for UCLASS_USB_DEV_GENERIC devices and binds the usb_ether gadget to it.
However, every board or arch hooks I tried seems to be much earlier than the USB controller, leading to the binding failing since we don't have a controller to bind to yet.
Adding that code right after the USB controller initialisation in the musb probe solves that issue, but for some other reason, it looks for a device of the USB_DEV_GENERIC uclass, while the uclass for the USB controllers seems to be USB. Actually, I don't seem to find any user of the USB_DEV_GENERIC uclass but the usb_ether driver, so I'm not really sure how it's supposed to work either...
Is there some user of this in U-Boot right now? the only call there is to usb_ether_init seems to be for the am33xx SoCs, whose usb glue don't register a peripheral controller (yet), so I don't really know how that can work either.
Thanks! Maxime
+Bin
Hi Maxiime,
On 5 September 2017 at 14:32, Maxime Ripard maxime.ripard@free-electrons.com wrote:
Hi,
I've been working with USB-Ethernet gadget for quite some time on the Allwinner SoCs, especially because most Allwinner boards lack an ethernet controller.
The thing is, it wasn't really upstreamable all this time since we've had also some boards that had a controller with DM_ETH. And usb_ether didn't have DM_ETH support until recently.
So I gave it a shot, and encountered a few weird things that prevented it from working (and still do):
I converted our musb glue to support the DM even in the peripheral mode. Here is the code: http://code.bulix.org/m846ni-194479
It almost works, except that usb_scan_bus in usb-uclass.c for some reason unknown to me tries to scan the peripheral device, and fails. Skipping that scan makes fastboot works, so I guess the peripheral is working. Is there any particular reason that the DM_USB code tries to scan even peripheral devices ?
Perhaps because it might be a hub? This is for companion support which Bin may know more about.
I can't manage to get usb_ether to probe after that, using the DM. It seems that we need to call usb_ether_init, and that it looks for UCLASS_USB_DEV_GENERIC devices and binds the usb_ether gadget to it.
However, every board or arch hooks I tried seems to be much earlier than the USB controller, leading to the binding failing since we don't have a controller to bind to yet.
Adding that code right after the USB controller initialisation in the musb probe solves that issue, but for some other reason, it looks for a device of the USB_DEV_GENERIC uclass, while the uclass for the USB controllers seems to be USB. Actually, I don't seem to find any user of the USB_DEV_GENERIC uclass but the usb_ether driver, so I'm not really sure how it's supposed to work either...
USB_DEV_GENERIC is a USB device (i.e. something ON the bus) which is not identified (i.e. not UCLASS_ETH for example). Anything that has a driver will be picked up by usb_find_and_bind_driver(). Note that the generic device is a fallback when the search fails.
Is there some user of this in U-Boot right now? the only call there is to usb_ether_init seems to be for the am33xx SoCs, whose usb glue don't register a peripheral controller (yet), so I don't really know how that can work either.
Well once the UCLASS_ETH device is found on USB, it will appear as a normal Ethernet device and operate as any other such device.
Thanks for looking at this. It will require some refactoring since the code is made for host mode at present.
Regards, Simon
Hi Simon,
On Fri, Sep 08, 2017 at 10:55:24PM -0600, Simon Glass wrote:
On 5 September 2017 at 14:32, Maxime Ripard maxime.ripard@free-electrons.com wrote:
Hi,
I've been working with USB-Ethernet gadget for quite some time on the Allwinner SoCs, especially because most Allwinner boards lack an ethernet controller.
The thing is, it wasn't really upstreamable all this time since we've had also some boards that had a controller with DM_ETH. And usb_ether didn't have DM_ETH support until recently.
So I gave it a shot, and encountered a few weird things that prevented it from working (and still do):
I converted our musb glue to support the DM even in the peripheral mode. Here is the code: http://code.bulix.org/m846ni-194479
It almost works, except that usb_scan_bus in usb-uclass.c for some reason unknown to me tries to scan the peripheral device, and fails. Skipping that scan makes fastboot works, so I guess the peripheral is working. Is there any particular reason that the DM_USB code tries to scan even peripheral devices ?
Perhaps because it might be a hub? This is for companion support which Bin may know more about.
I think it was because I was registering the peripheral-mode driver as a member of UCLASS_USB, which seems to be only for host devices.
The code would then start to scan the device (as it should for host devices) and things were falling apart because, well, it was not a host device.
I can't manage to get usb_ether to probe after that, using the DM. It seems that we need to call usb_ether_init, and that it looks for UCLASS_USB_DEV_GENERIC devices and binds the usb_ether gadget to it.
However, every board or arch hooks I tried seems to be much earlier than the USB controller, leading to the binding failing since we don't have a controller to bind to yet.
Adding that code right after the USB controller initialisation in the musb probe solves that issue, but for some other reason, it looks for a device of the USB_DEV_GENERIC uclass, while the uclass for the USB controllers seems to be USB. Actually, I don't seem to find any user of the USB_DEV_GENERIC uclass but the usb_ether driver, so I'm not really sure how it's supposed to work either...
USB_DEV_GENERIC is a USB device (i.e. something ON the bus) which is not identified (i.e. not UCLASS_ETH for example). Anything that has a driver will be picked up by usb_find_and_bind_driver(). Note that the generic device is a fallback when the search fails.
Ok, so I guess the reason to choose USB_DEV_GENERIC is because we're acting as that device on the bus when probing a gadget?
Is there some user of this in U-Boot right now? the only call there is to usb_ether_init seems to be for the am33xx SoCs, whose usb glue don't register a peripheral controller (yet), so I don't really know how that can work either.
Well once the UCLASS_ETH device is found on USB, it will appear as a normal Ethernet device and operate as any other such device.
Thanks for looking at this. It will require some refactoring since the code is made for host mode at present.
It works quite well already once a few quirks figured out. I've sent a serie of patch that works already, it should be in your INBOX. I guess most of the quirks are not trivial to get because there's no-one using that setup for now.
Hopefully, it should be easier to get once they're merged.
Maxime
Hi Maxime,
On 11 September 2017 at 02:33, Maxime Ripard maxime.ripard@free-electrons.com wrote:
Hi Simon,
On Fri, Sep 08, 2017 at 10:55:24PM -0600, Simon Glass wrote:
On 5 September 2017 at 14:32, Maxime Ripard maxime.ripard@free-electrons.com wrote:
Hi,
I've been working with USB-Ethernet gadget for quite some time on the Allwinner SoCs, especially because most Allwinner boards lack an ethernet controller.
The thing is, it wasn't really upstreamable all this time since we've had also some boards that had a controller with DM_ETH. And usb_ether didn't have DM_ETH support until recently.
So I gave it a shot, and encountered a few weird things that prevented it from working (and still do):
I converted our musb glue to support the DM even in the peripheral mode. Here is the code: http://code.bulix.org/m846ni-194479
It almost works, except that usb_scan_bus in usb-uclass.c for some reason unknown to me tries to scan the peripheral device, and fails. Skipping that scan makes fastboot works, so I guess the peripheral is working. Is there any particular reason that the DM_USB code tries to scan even peripheral devices ?
Perhaps because it might be a hub? This is for companion support which Bin may know more about.
I think it was because I was registering the peripheral-mode driver as a member of UCLASS_USB, which seems to be only for host devices.
Yes that's right.
The code would then start to scan the device (as it should for host devices) and things were falling apart because, well, it was not a host device.
I can't manage to get usb_ether to probe after that, using the DM. It seems that we need to call usb_ether_init, and that it looks for UCLASS_USB_DEV_GENERIC devices and binds the usb_ether gadget to it.
However, every board or arch hooks I tried seems to be much earlier than the USB controller, leading to the binding failing since we don't have a controller to bind to yet.
Adding that code right after the USB controller initialisation in the musb probe solves that issue, but for some other reason, it looks for a device of the USB_DEV_GENERIC uclass, while the uclass for the USB controllers seems to be USB. Actually, I don't seem to find any user of the USB_DEV_GENERIC uclass but the usb_ether driver, so I'm not really sure how it's supposed to work either...
USB_DEV_GENERIC is a USB device (i.e. something ON the bus) which is not identified (i.e. not UCLASS_ETH for example). Anything that has a driver will be picked up by usb_find_and_bind_driver(). Note that the generic device is a fallback when the search fails.
Ok, so I guess the reason to choose USB_DEV_GENERIC is because we're acting as that device on the bus when probing a gadget?
I don't understand' probing a gadget'. Do you mean 'probing a USB device'?
It's really just a placeholder. We have to have some sort of DM device in order to even report the existence of a USB device so this is our way of doing so when we have no real driver.
In practice I don't think that devices of type 'USB_DEV_GENERIC' are accessed, but it would be possible to send them commands.
So for USB gadget I don't think this will be needed, since U-Boot will always have a driver for the gadget (e.g. for Ethernet gadget it cannot work unless the gadget is UCLASS_ETHERNET).
BTW we do the same thing with PCI, I2C and SPI. Anything where a driver cannot be found, we have to use some sort of placeholder uclass.
Is there some user of this in U-Boot right now? the only call there is to usb_ether_init seems to be for the am33xx SoCs, whose usb glue don't register a peripheral controller (yet), so I don't really know how that can work either.
Well once the UCLASS_ETH device is found on USB, it will appear as a normal Ethernet device and operate as any other such device.
Thanks for looking at this. It will require some refactoring since the code is made for host mode at present.
It works quite well already once a few quirks figured out. I've sent a serie of patch that works already, it should be in your INBOX. I guess most of the quirks are not trivial to get because there's no-one using that setup for now.
Hopefully, it should be easier to get once they're merged.
OK sounds good.
Maxime
-- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Regards, Simon
Hi,
Removing mugunthanvnm@ti.com, who is no longer working for TI.
On Wednesday 06 September 2017 02:02 AM, Maxime Ripard wrote:
Hi,
I've been working with USB-Ethernet gadget for quite some time on the Allwinner SoCs, especially because most Allwinner boards lack an ethernet controller.
The thing is, it wasn't really upstreamable all this time since we've had also some boards that had a controller with DM_ETH. And usb_ether didn't have DM_ETH support until recently.
So I gave it a shot, and encountered a few weird things that prevented it from working (and still do):
I converted our musb glue to support the DM even in the peripheral mode. Here is the code: http://code.bulix.org/m846ni-194479
It almost works, except that usb_scan_bus in usb-uclass.c for some reason unknown to me tries to scan the peripheral device, and fails. Skipping that scan makes fastboot works, so I guess the peripheral is working. Is there any particular reason that the DM_USB code tries to scan even peripheral devices ?
I can't manage to get usb_ether to probe after that, using the DM. It seems that we need to call usb_ether_init, and that it looks for UCLASS_USB_DEV_GENERIC devices and binds the usb_ether gadget to it.
However, every board or arch hooks I tried seems to be much earlier than the USB controller, leading to the binding failing since we don't have a controller to bind to yet.
am33xx probes MISC devices in arch_misc_init() (arch/arm/mach-omap2/am33xx/board.c)
Adding that code right after the USB controller initialisation in the musb probe solves that issue, but for some other reason, it looks for a device of the USB_DEV_GENERIC uclass, while the uclass for the USB controllers seems to be USB. Actually, I don't seem to find any user of the USB_DEV_GENERIC uclass but the usb_ether driver, so I'm not really sure how it's supposed to work either...
Sorry, DM based eth gadget support is still missing for am33xx. This patch in particular was asked to be reworked: https://patchwork.ozlabs.org/patch/696033/
Is there some user of this in U-Boot right now? the only call there is to usb_ether_init seems to be for the am33xx SoCs, whose usb glue don't register a peripheral controller (yet), so I don't really know how that can work either.
Last time I tried to upstream dwc3 usb ethernet gaget and rndis boot support, Lukasz Majewski had ideas to move towards adding DM infrastructure for USB gadget: https://patchwork.ozlabs.org/patch/775110/
participants (3)
-
Maxime Ripard -
Simon Glass -
Vignesh R