66 replies to this topic

[hcf]

After tooling around with USBSerial for awhile, I got really tired of still having to restart my Wiz to transfer files. Something had to be done. I was surprised to see what was wrong...after reading all the stories about the g_ether module having problems, I thought it would be a much more significant issue!

Anyway.

As usual, step 1 involves fetching some software (the g_ether.ko on the Wiz will not help you, you will need the one I compiled with source changes);

http://www.mercenary...k-1.1.0.tar.bz2

Step 2, untar it onto the SD card.

cd /media/disk # or wherever
tar xzf ~/Desktop/USBNetwork-1.1.0.tar.gz # or wherever

Unmount the SD flash safely and return the Wiz to the menu.

Step 3, run the "NetworkUp.gpe" script from the Launcher.

The NetworkUp.gpe script will configure the usb0 interface with '10.0.0.2/24'. I guess I didn't have to use a /24 but it is easier to type on the host side slightly.

Step 4, now on the host side, check 'dmesg', and then configure the host side of the interface so the two can speak (automating this step depends largely on host OS and is up to you):

usb 5-2: new full speed USB device using ohci_hcd and address 18
usb 5-2: not running at top speed; connect to a high speed hub
usb 5-2: new device found, idVendor=049f, idProduct=505a
usb 5-2: new device strings: Mfr=1, Product=2, SerialNumber=0
usb 5-2: Product: OpenWiz Ethernet
usb 5-2: Manufacturer: Linux 2.6.24/lf1000_udc
usb 5-2: configuration #1 chosen from 1 choice
usb 5-2: unsupported MDLM descriptors
usb0: register 'cdc_subset' at usb-0000:00:13.4-2, Linux Device, 76:63:3c:8b:35:72

# ifconfig usb0 inet 10.0.0.1 netmask 255.255.255.0
# ping 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=4.69 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.986 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.959 ms

At this stage, the Wiz is attached to the host by networking. What network applications to build, install, or configure, and how to use them, is a howto for another day.

Note that again while the LF1000 device is in use, the Wiz cannot be used as a block device to mount the SD or NAND devices. To remove the g_ether module and restore these functions while the Wiz is running, simply run the NetworkDown.gpe script included in the same directory. This will take the Wiz off network. You may also safely simply restart the Wiz.

RELEASE NOTES

There is a known problem with using this kernel module on GPH firmware 1.1.0-255 which has been circulating separately from the 1.1.0-222 available from GPH's website and the openhandhelds.org archive. The problem is that 'insmod' segfaults before it can load the network gadget module into the kernel. There is no known workaround. Hopefully this flaw in the 1.1.0-255 firmware will be corrected before final release.


Here is the patch showing changes I made to the gadget ethernet sources, for those who are wondering what it took. It was surprisingly trivial, as I think you may agree:

*** drivers/usb/gadget/ether.c.old      2009-04-30 05:35:10.000000000 -0700
--- drivers/usb/gadget/ether.c  2009-11-18 16:57:31.000000000 -0800
***************
*** 67,74 ****
   * needlessly complex.
   */
  
! #define DRIVER_DESC           "Ethernet Gadget"
! #define DRIVER_VERSION                "May Day 2005"
  
  static const char shortname [] = "ether";
  static const char driver_desc [] = DRIVER_DESC;
--- 67,74 ----
   * needlessly complex.
   */
  
! #define DRIVER_DESC           "OpenWiz Ethernet"
! #define DRIVER_VERSION                "HCF 0"
  
  static const char shortname [] = "ether";
  static const char driver_desc [] = DRIVER_DESC;
***************
*** 287,292 ****
--- 287,295 ----
  #define       DEV_CONFIG_CDC
  #endif
  
+ #ifdef CONFIG_USB_GADGET_LF1000
+ #define DEV_CONFIG_SUBSET
+ #endif
  
  /*-------------------------------------------------------------------------*/
  

Edit: I forgot to mention one other minor change. When configuring linux-2.6.24-pollux to build the g_ether kernel module, the default is to build the module with the NDIS additional module (intended for some kind of Windows compatibility). I had no intention of using this service, I'm not even familiar with it, and so selected 'no' to simplify the driver. I do not know if this affects the g_ether module's success above (if it is required), but it will mean the driver presents one configuration (for the subset/bulk driver) instead of two (bulk/cdc and NDIS).

Edit 2: Decided my tasteless joke at the expense of others was a tasteless joke at the expense of others, and not nearly as funny as I thought.

Edit 4: Documenting edit 3: s/ether.c/ether.ko/ (describing module installed on Wiz), s/SDRAM/SD card/ (correcting finger macro)

Edit 5: Added RELEASE NOTES to document known problem(s).

Edited by hcf, 30 December 2009 - 06:57 PM.

[crow_riot]

am i safe to try this without reflashing firmware?

[torpor]

This is great, but is telnetd or dropbear onboard too?

[crow_riot]

This is great, but is telnetd or dropbear onboard too?

as nothing has to be changed for the modded serial cable, wouldn't it work, too?

[torpor]

With serial I believe (correct me if I'm wrong) that login is handled by getty, but over ethernet we're going to need either telnetd or dropbear ..

[crow_riot]

With serial I believe (correct me if I'm wrong) that login is handled by getty, but over ethernet we're going to need either telnetd or dropbear ..

i don't know either

but from the file listing http://www.distant-e.../rootfslist.txt - telnetd seems to be there. so if it is not running, a starter script would just be sufficient?

Edited by crow_riot, 19 November 2009 - 10:03 AM.

[derdritte]

Really excited about the networking finally taking off, thank you for pushing it forward

[torpor]

Yeah I'd like to say thanks too, this is definitely helpful ..

[crow_riot]

Of course, like to thank u too for making this happen! I'm really excited about this and cant wait to get home and try it

[hcf]

am i safe to try this without reflashing firmware?

I think so! =D So far mine has been okay. The problem with my first USBSerial package was I was mucking with /etc/inittab to save memory and the shutdown script ruined it (init is used to start the initial gp2xmenu, auto-logging-in as root). Like my second USBSerial package, this one doesn't touch root at all. I'd be really surprised if there was a problem.

This is great, but is telnetd or dropbear onboard too?

I left application preference pretty much open. I'm not familiar with dropbear so I haven't looked for it on the Wiz system root. There is a 'telnetd' link to busybox on the Wiz already, but when you actually use it, it turns out the telnetd applet can't be found inside the busybox binary. sshd+openssl are a little difficult to cross-compile, but it's not hard to compile e.g. rshd or telnetd and run that out of inetd. It's easy to just '/usr/sbin/inetd' on the Up event and 'killall inetd' on the Down event, that part works, the only hiccup is getting a daemon and listing it in /etc/inetd.conf. There are also links for ftpget and ftpput but I don't know if they're "applet not found" too. There doesn't seem to be an ftpd.

Note that the 'loginpass.sh' hack I used on USBSerial or something like that will still be necessary on whatever daemon you choose. The default login will auto-spawn the gp2x menu when you login, and it doesn't provide a usable interactive shell (it's just menu debug output). Another option might be adding a second root user to /etc/passwd ("toor" is commonly used) that doesn't have the auto-login affliction.

I haven't checked if it has udhcpc or if it works, but with a DHCP client (or changing the manual config for your network), you could have the host computer provide a virtual bridge for the usb0 interface, and the Wiz could be On The Internet ™.

[hcf]

Actually, I take that back, I must have been tired yesterday. telnetd must be included in the busybox binary, the problem instead appears to be that the "-l" flag to change the /bin/login selection tries to find the selected application inside busybox, rather than on the filesystem.

[torpor]

hcf, check into dropbear .. it should be *very* easy to build for the Wiz and it would mean we can just ssh into the Wiz, or scp files across the gadget ethernet link, etc. I'll try to spend some time looking at this tonight, maybe we can meet in #wiz or something ..

[notaz]

Great work, can't believe it was just missing a single define!

Off topic: I wonder why do you call SD cards SDRAM?

[hcf]

Great work, can't believe it was just missing a single define!

I initially started my post with an off-color complaint that no one seems to read module comments anymore. The instructions to define a CONFIG_DEV_ for specific lower layer hardware are written halfway through the module...of course I also didn't notice it until my third attempt at understanding the USB config block definitions. :/

Off topic: I wonder why do you call SD cards SDRAM?

Finger macro.

[Exophase]

I totally need to get back to trying to unbrick my Wiz so I can try this. D: