Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add USB Ethernet Gadget toggle #933

Open
wants to merge 12 commits into
base: qml
Choose a base branch
from

Conversation

paulober
Copy link

No description provided.

Copy link
Collaborator

@tdewey-rpi tdewey-rpi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great - a handful of cleanup tasks, but otherwise a great addition

src/OptionsPopup.qml Outdated Show resolved Hide resolved
src/OptionsPopup.qml Outdated Show resolved Hide resolved
src/cli.cpp Outdated Show resolved Hide resolved
src/downloadthread.cpp Show resolved Hide resolved
src/extraFiles/configure-usb-ether-gadget-once.sh Outdated Show resolved Hide resolved
src/imagewriter.h Outdated Show resolved Hide resolved
src/imagewriter.h Outdated Show resolved Hide resolved
src/CMakeLists.txt Outdated Show resolved Hide resolved
@lurch
Copy link
Contributor

lurch commented Sep 19, 2024

IIRC this USB Ethernet Gadget mode only works for those Pis where there's not a USB Hub chip in between the SoC and the USB port (e.g. it will work on Pi Zero or Pi 3A+, but won't work on Pi 2B or Pi 3B+). And given that RPi Imager now asks the user which Pi they're going to be running on, I guess we could make this option conditional on that? 🤔 (or at least make it not-selectable on those Pis where we know it definitely won't work?)

@tdewey-rpi
Copy link
Collaborator

IIRC this USB Ethernet Gadget mode only works for those Pis where there's not a USB Hub chip in between the SoC and the USB port (e.g. it will work on Pi Zero or Pi 3A+, but won't work on Pi 2B or Pi 3B+). And given that RPi Imager now asks the user which Pi they're going to be running on, I guess we could make this option conditional on that? 🤔 (or at least make it not-selectable on those Pis where we know it definitely won't work?)

Yes, the sensible gate is probably to exclude the Pi 3 series entirely rather than introduce the distinction between 3A+ and 3B+. So, make it work on Pi Zero, 4, 5

@paulober
Copy link
Author

paulober commented Sep 19, 2024

Ok, I will implement that.
But concerning 3b+ (@lurch):

  • So does it have no OTG support on none of its USB ports?
  • Is there really no option to get the USB port into peripheral mode?

src/OptionsPopup.qml Outdated Show resolved Hide resolved
src/imagewriter.h Outdated Show resolved Hide resolved
src/downloadthread.cpp Outdated Show resolved Hide resolved
src/main.qml Outdated Show resolved Hide resolved
@XECDesign
Copy link

Shouldn't features like this come after cloud-init support? Why is it enabling a different network configuration service when NM is used for all other interfaces? rpi-imager implementing things that should happen on the OS side instead has only caused headaches in the past.

@tdewey-rpi
Copy link
Collaborator

Shouldn't features like this come after cloud-init support? Why is it enabling a different network configuration service when NM is used for all other interfaces? rpi-imager implementing things that should happen on the OS side instead has only caused headaches in the past.

This is a pretty straightforward win that can tide people over until the cloud-init work is completed on the OS (something else @paulober might want to look at).

An earlier version did use a NetworkManager configuration file - @paulober, is there any reason that hasn't made it into this PR?

@paulober
Copy link
Author

An earlier version did use a NetworkManager configuration file - @paulober, is there any reason that hasn't made it into this PR?

I have tried creating a NM config file but didn't work so I defaulted back to my systemd-networkd config since it's still on all Rbpi OSs and I haven't found any good resource to get the NM config up and running without wasting to much time. (my approach can be found in the DEB package repo)
But I can look into it again, if this is a problem?

@paulober
Copy link
Author

The current setup has one drawback: On the RPi zero if this config is applied the USB port can only be used of this ether gadget and not for HID devices like keyboard and mouse. This would require the manual config approach with libcomposite as the current gadgets in the kernel only support either ethernet or HID or ethernet + serial (there are also more but out of the topic)

@lurch
Copy link
Contributor

lurch commented Sep 20, 2024

If people are making custom HID devices, perhaps they're more likely to be doing that with Raspberry Pi Pico (microcontroller) rather than Raspberry Pi Zero (computer)? 🤷‍♂️

@paulober
Copy link
Author

If people are making custom HID devices, perhaps they're more likely to be doing that with Raspberry Pi Pico (microcontroller) rather than Raspberry Pi Zero (computer)? 🤷‍♂️

I'm not sure what you mean by this?

The HID functionality is also need so that normal keyboards and mice work with that port so after enabling this feature they won't be able to connect any of those devices any more until they uninstall the package.

@lurch
Copy link
Contributor

lurch commented Sep 20, 2024

Ahhh, I misunderstood what you were saying - I thought you meant that you wanted to simultaneously enable both USB Ethernet and HID gadget modes, so that the you could SSH from your laptop to your Pi Zero, whilst also allowing the Pi Zero to act as a virtual keyboard input-device to your laptop.

But you're actually saying that if you enable this Ethernet gadget mode (which puts the USB OTG port into device mode), then you can't then later connect a real USB keyboard (which would require the USB OTG port to be in host mode). Isn't that expected behaviour? 🤔

@paulober
Copy link
Author

@XECDesign
May I ask how

rpi-imager implementing things that should happen on the OS side instead has only caused headaches in the past.

is ment?

Would you suggest writing a new kernel USB gadget, adding an option to raspi-config and make rpi-imager then just calling raspi-config on first boot to enable this feature?

@paulober
Copy link
Author

But you're actually saying that if you enable this Ethernet gadget mode (which puts the USB OTG port into device mode), then you can't then later connect a real USB keyboard (which would require the USB OTG port to be in host mode). Isn't that expected behaviour? 🤔

I guess you're right. That sure be the reason why the g_multi gadget supports only ethernet, serial and stuff like that. Because they all require the port beeing in the same mode and g_hid would require the port to be in a different mode....

Sorry for the confusion. I guess this is something that needs to be noted somewhere like in the UI and the DEB pkg description + README?

@paulober paulober force-pushed the add-usb-ether-gadget-toggle branch from da8ed5f to 2c0da0d Compare September 20, 2024 18:20
@lurch
Copy link
Contributor

lurch commented Sep 21, 2024

g_hid would require the port to be in a different mode

I assume the g in g_hid still stands for "gadget", i.e. g_hid does still run in device-mode rather than host-mode, but it's used for making the Pi Zero appear to your laptop as a virtual keyboard or mouse (etc.) input-device. (Ah yes: https://docs.kernel.org/usb/gadget_hid.html )

@XECDesign
Copy link

@XECDesign May I ask how

rpi-imager implementing things that should happen on the OS side instead has only caused headaches in the past.

is ment?

When image customisation was added, it was just the firstrun.sh script doing all the work. This caused problems because it made a ton of assumptions about the OS. When we moved away from dhcpcd, for example, the wifi config option broke.

So I added /usr/lib/raspberrypi-sys-mods/imager_custom as something rpi-imager can call instead. Then it doesn't matter how the images changes, as long as imager_custom does the right thing.

I have previously proposed that the json file could have a field matching imager_custom version to determine what customisations the image supports. However, since firstrun.sh was just temporary and we should be using cloud-init to do all of this anyway, it was deemed necessary.

But since this isn't a feature I'm comfortable adding to Raspberry Pi OS as-is, it's probably better for rpi-imager to handle it itself in this case.

@lurch
Copy link
Contributor

lurch commented Sep 24, 2024

@paulober Something that occurred to me this morning (following on from the earlier HID discussion) - maybe there should also be some shell scripts on the Pi that you can use to easily "enable / disable" this USB Ethernet functionality, so that if you're using USB Ethernet gadget on a Zero and you later want to use a real USB keyboard with the same Zero, you could connect to the Zero over SSH over the USB-ethernet, run the "disable usb ethernet" script, and then the next time you boot up the Zero it'll be running in "normal" mode (so you could directly-connect keyboard/mouse/monitor). And if you then later wanted to switch it back into USB Ethernet gadget mode, you could run the "enable usb ethernet" script?

@paulober
Copy link
Author

paulober commented Sep 24, 2024

@lurch Sounds like a good addition. I'll add a script to toggle and get the status.

@paulober
Copy link
Author

The script i just added is not completely ready yet.

src/imagewriter.cpp Outdated Show resolved Hide resolved
@paulober paulober marked this pull request as ready for review September 25, 2024 09:53
@paulober paulober requested a review from tdewey-rpi September 26, 2024 17:11
@macmpi
Copy link

macmpi commented Oct 17, 2024

How about replacing g_ether driver by g_cdc in rpi-usb-ether-gadget.sh & usb-ether-gadget.conf: this would give both ethernet and serial console options, each having own merits to setup PiZero & al devices?
(note; dwc2 in usb-ether-gadget.conf is probably not required as this driver is loaded by setting dtoverlay)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants