Caanoo / WIZ Howto: Wiz Usb-Ethernet With Stock Usb Cable


hi

when i run NetworkUp.gpe from the launcher i dont see anything appearing in dmesg of my host (debian)linux

serial line works though... so i connected via kermit an tried to load the NetworkUp.gpe there ;)

this is what happens:

Code:
root@wiz:/mnt/sd/game/00-usb/USBNetwork# ./NetworkUp.gpe 
Using /lib/modules/2.6.24/kernel/drivers/usb/gadget/lf1000_udc.ko
insmod: cannot insert `/lib/modules/2.6.24/kernel/drivers/usb/gadget/lf1000_udc.ko': File exists (-1): File exists
SIOCSIFADDR: No such device
SIOCSIFNETMASK: No such device
view created...
GP2X wiz Mode...
FB_OpenMouse()
Using tslib touchscreen
Check joystick...
Killed
root@wiz:/mnt/sd/game/00-usb/USBNetwork#

ok lf1000 is in use for the serial line i guess, but how would i find out what happens when i start it through the launcher, with no usbserial loaded?
screen just flickers then i see the main menu again... it should display some debug info

any ideas?
 
Hi zort,

Thanks for helping. I think the dmesg info hcf needs is the the one on the WIZ, not the host.

If you want to know what is going on, you can try it via termula: http://dl.openhandhelds.org/cgi-bin/wiz.cgi?0,0,0,0,8,163

@all:

On the German board if have seen that there are different revisions of firmware 1.1.0. It came up as subject to the touchscreen bug.
With revision 244 or 255 the touchscreen seems to be more accurate than with the "official" revision 222. This is a test with 255:
http://www.imgbox.de/users/public/images/h43151n168.jpg
Obviously GPH have done some significant modifications with the revisions that have not officially been release for updates :unsure: .
Maybe we should check our firmware revisions?
I have 222 and the USB Network works fine.
What about yours?

Kasi
 
zort said:
serial line works though... so i connected via kermit an tried to load the NetworkUp.gpe there ;)

Ah, that definitely won't work. It is a combination of hardware and software (Linux "USB Gadget Interface") limitations, although a USB hardware component might be capable of presenting plural "endpoints", and it could send configuration blocks that mix and match the meaning of those endpoints, the lf1000 hardware supports only 2 endpoints (one in, one out), and even if that weren't true the Linux USB Gadget API allows at most one "gadget driver" to take control of a hardware device at a time...there is no API that dynamically assigns endpoint descriptors, the gadget drivers assign their own (usually statically in the sources).

Could you perhaps add 'dmesg > dmesg.out' to the end of your NetworkUp.gpe and try to run it after a fresh shutdown/power-on of your Wiz (this ensures the Serial gadget, or any other stray gadget is unloaded)? Then use NetworkDown.gpe (or restart your wiz), and copy the file off the SD card separately.

ok lf1000 is in use for the serial line i guess, but how would i find out what happens when i start it through the launcher, with no usbserial loaded?
screen just flickers then i see the main menu again... it should display some debug info

As there is no VTY, displaying debug info is slightly more difficult than it sounds. Not impossible, just hard enough I haven't tried...


kasi said:
On the German board if have seen that there are different revisions of firmware 1.1.0. It came up as subject to the touchscreen bug.
With revision 244 or 255 the touchscreen seems to be more accurate than with the "official" revision 222. This is a test with 255:
http://www.imgbox.de/users/public/images/h43151n168.jpg
Obviously GPH have done some significant modifications with the revisions that have not officially been release for updates :unsure: .
Maybe we should check our firmware revisions?
I have 222 and the USB Network works fine.
What about yours?

Kasi

Ah, I am using the 1.1.0 firmware that is on the openhandhelds archive;

http://dl.openhandhelds.org/cgi-bin/wiz.cgi?0,0,0,0,42,112

And the kernel sources (with only config modifications for serial gadget, and some minor source modifications (beginning of thread) for network gadget) also from openhandhelds archive;

http://dl.openhandhelds.org/cgi-bin/wiz.cgi?0,0,0,0,46,151


I am not sure why the USBSerial would work, but the USBNetwork wouldn't. That is a little more mystifying.
 
Last edited by a moderator:
hcf said:
Ah, I am using the 1.1.0 firmware that is on the openhandhelds archive;

AFAIK that is 222 - the same as I have.

Now it would be interesting to hear if anybody got 244 or higher with (not) working USBNetwork.

BTW, I never tried the USBSerial - didn't need it. ;)

Kasi
 
Last edited by a moderator:
kasi said:
hcf said:
Ah, I am using the 1.1.0 firmware that is on the openhandhelds archive;

AFAIK that is 222 - the same as I have.

Now it would be interesting to hear if anybody got 244 or higher with (not) working USBNetwork.

BTW, I never tried the USBSerial - didn't need it. ;)

Kasi
thx hcf for the explanation!
i found out that NetworkUP.gpe is just a shell script ;)

Code:
#!/bin/sh

# Load the g_ether module.
insmod lf1000_udc.ko
insmod ./g_ether.ko > test.log 2>&1

# Wait a few moments for things to settle.
sleep 2

# Configure the 10.0.0.2 address locally.
/sbin/ifconfig usb0 inet 10.0.0.2 netmask 255.255.255.0

# Return to GP2X default menu.
cd /usr/gp2x
exec ./gp2xmenu

so i checked test.log, its just one line there "Segmentation Fault"

and kasi: i'm using 255 firmware that was on board...

btw this is a nice and helpful tool that i found:
termula

so if the g_ether.ko module works on 222 that means someone has to compile it for the new 255 i guess...
i would try it if i had the source code ;)
 
Last edited by a moderator:
Hi Zort,


zort said:
btw this is a nice and helpful tool that i found:
termula

Do I have a déja vu or did I just forget to post the link? :blink: Thanks, anyway.

However, I don't know if there really is a significant difference, e.g. in the kernel. I'm not sure if you CAN compile it just for another revision.

Kasi
 
Last edited by a moderator:
hmmm i found out that there is a g_ether in /lib/modules/2.6.24/kernel/drivers/usb/gadget/g_ether.ko
so in termula i tried this:
(after successfully loading lf1000_ubc.ko)

Code:
$ insmod g_ether
Using /lib/modules/2.6.24/kernel/drivers/usb/gadget/g_ether.ko
Segmentation fault

$ insmod g_ether
Using /lib/modules/2.6.24/kernel/drivers/usb/gadget/g_ether.ko
insmod: cannot insert `/lib/modules/2.6.24/kernel/drivers/usb/gadget/g_ether.ko': File exists (-1): File exists

i guess something is really b0rken in the firmware 255
 
zort said:
hmmm i found out that there is a g_ether in /lib/modules/2.6.24/kernel/drivers/usb/gadget/g_ether.ko
so in termula i tried this:
(after successfully loading lf1000_ubc.ko)

Code:
$ insmod g_ether
Using /lib/modules/2.6.24/kernel/drivers/usb/gadget/g_ether.ko
Segmentation fault

$ insmod g_ether
Using /lib/modules/2.6.24/kernel/drivers/usb/gadget/g_ether.ko
insmod: cannot insert `/lib/modules/2.6.24/kernel/drivers/usb/gadget/g_ether.ko': File exists (-1): File exists

i guess something is really b0rken in the firmware 255

seems they compiled it by themselves and messed it up? i wouldn't be surprised 'bout that ...
 
Last edited by a moderator:
Having insmod segfault for any reason is worrisome...

So the reason the serial module works is because for some reason insmod doesn't segfault on it? I wonder what the difference is. They both attach to the same lf1000 driver.
 
hcf said:
Having insmod segfault for any reason is worrisome...

So the reason the serial module works is because for some reason insmod doesn't segfault on it? I wonder what the difference is. They both attach to the same lf1000 driver.

I experience exactly the same problem here (vev 255) and I did some debugging on the g_ether module.

The problem seems to be that GPH modified the kernel used in revision 255. The alloc_etherdev function does initialize the device but does not allocate the private data structure. This results in a null pointer causing the segfault. After studying the kernel sources I know that this cannot happen: the memory is always allocated. I suspect that GPH modified something (there is a news entry on the official site for some network messaging test) and broke this part of the kernel.

When I allocate the memory 'by hand' the module can be inserted and the device is there. But something is still wrong. ifconfig shows no mac address so 'ifconfig up' does not work. You can assign a mac address and then you can bring up the device but still there is no communication (but at least the pc recognizes the usb interface).

This is very wierd - I hope GPH will release their changes (they actually have to, because that part of the system is GPL) but ... well... you know... :(

I'll keep on trying to get this working but I guess they damaged the networking stuff to bad...

If anyone wants me to try things with the module on rev 255 I'll be happy to help... :)

p.s.
First post on this site - just got myself a Wiz. Hello everyone! :)
 
Last edited by a moderator:
I just tried the following:
I compiled pppd for the Wiz and also the needed ppp modules for the kernel.
Then I tried to setup a ppp connection over the usb serial device (g_serial) (USBSerial works really nice btw).

I get a ppp0 device on the wiz but again, no communication is done. Also, the pointtopoint address does not show up in ifconfig. When I tried to set it, the Wiz crashed (not sure, if it was the cause, but interesting).

These strange things make me believe, that GPH definitely messed around with the Kernels networking code at a very low level... (Something that should be punishable by law if you ask me... ;) )

I hope by using pppd I will be able to find out whats going on... maybe I can setup a connection between two pipes on the device and see, if this also fails...

Maybe I'm just missing something very obvious and things will just work... but I have a bad feeling.

*edit*
Just tested pppd over pipes on the Wiz. Does also not work... really broken... :(
Does any local IP traffic work on the Wiz ?
 
Newb here, how useful would this be at this point in it's development for game development?

thanks
 
Jonsul said:
Newb here, how useful would this be at this point in it's development for game development?

thanks

Currently, I think this is not useful, as networking with the Wiz is not very common. I personally plan to add Bluetooth and/or Wifi to my Wiz and then there might be opportunities to develop multiplayer games.
For me, I just want to have a network connection for easier debugging and for abusing the Wiz as a remote control for my PC. But rev 255 seems to crush all my dreams... :-|
 
Last edited by a moderator:
I did some more testing with the g_ether module and found something curious:

I setup the network on the Wiz using termula by assigning a MAC address and then the IP address. When I setup the network on the PC I see that 4 packets where transferred on the Wiz (interesting... something IS happening).
But when I then try to ping the Wiz, it crashes / hangs.

I'm not sure what to make of this but I'll post further findings here...

*edit*
At least I can now confirm that local IP traffic is still working on the device (two local netcats talking via TCP possible). So the problem must be somewhere at the point where the driver sets up the hooks to get data from the kernel...
 
Hi hiben,

I just can't help asking:
Did you try the new FW 1.2.1 ??

rds

kasi
 
kasi said:
I just can't help asking:
Did you try the new FW 1.2.1 ??

i just did it, but it still segfaults ;(
tried both commands:
insmod ./g_ether.ko
insmod g_ether (for the original module)

btw for a storagemount-copyingnewbinary-runit loop i hacked this little tool together -> USBFoo
it just needs some buttons pressed, no reboots ;)
 
Last edited by a moderator:
I also have this problem with FW 1.2.1:

Code:
lf1000_udc: version 03 Jul 2007
lf1000_udc_probe: base addr = f0018000
Unable to handle kernel NULL pointer dereference at virtual address 0000009c
pgd = c1164000
[0000009c] *pgd=01fde031, *pte=00000000, *ppte=00000000
Internal error: Oops: 817 [#1]
Modules linked in: g_ether lf1000_udc rtc_pollux_m41t80 rtc_core
CPU: 0    Not tainted  (2.6.24 #665)
PC is at eth_bind+0x278/0x6b4 [g_ether]
LR is at alloc_netdev_mq+0xb4/0xd4
pc : [<bf00db30>]    lr : [<c019fb5c>]    psr: a0000013
sp : c1ca1e7c  ip : c1ca1e40  fp : c1ca1ec0
r10: bf00bab4  r9 : bf00ba84  r8 : c1cdf800
r7 : 00000000  r6 : 00000001  r5 : bf012ab6  r4 : 00000002
r3 : 00000000  r2 : 000000a0  r1 : c02739c2  r0 : c1cdf800
Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 0005317f  Table: 01164000  DAC: 00000015
Process insmod (pid: 1074, stack limit = 0xc1ca0258)
Stack: (0xc1ca1e7c to 0xc1ca2000)
1e60:                                                                c028bbaa 
1e80: bf009fc4 c0150ed4 c014fc4c bf00bb58 bf00ba44 00000000 bf0129a0 bf00b9ec 
1ea0: 00000000 bf00bad0 c33a6200 c3374000 00000000 c1ca1ee0 c1ca1ec4 bf008a84 
1ec0: bf00d8c8 c1c2f9c4 c1c2f800 bf012c80 c33a67c8 c1ca1ef0 c1ca1ee4 bf014014 
1ee0: bf0089f8 c1ca1fa4 c1ca1ef4 c00641cc bf014010 00000000 c33a67a0 c33a6430 
1f00: c33a6778 c1ee95a0 c33b7f70 00000023 00000009 00000000 00000000 00000000 
1f20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
1f40: 00000000 00000008 00000149 00000149 00000000 c0113fac 00000025 c33a60c6 
1f60: 00000025 bf011d60 c33a6228 bf012c8c 00000025 00000000 00000000 0000000d 
1f80: 00000000 00000000 00000080 c002f044 c1ca0000 00000002 00000000 c1ca1fa8 
1fa0: c002eea0 c0062e58 00000000 00000000 00900080 4021d000 00044b9c 0009d0d0 
1fc0: 0000000d 00000000 00000000 0009d090 00000000 00000000 00000002 00000000 
1fe0: bec6bb54 bec6bb48 00031b78 401b9ec0 60000010 00900080 00000000 00000000 
Backtrace: 
[<bf00d8b8>] (eth_bind+0x0/0x6b4 [g_ether]) from [<bf008a84>] (usb_gadget_register_driver+0x9c/0x1ac [lf1000_udc])
[<bf0089e8>] (usb_gadget_register_driver+0x0/0x1ac [lf1000_udc]) from [<bf014014>] (init+0x14/0x1c [g_ether])
 r7:c33a67c8 r6:bf012c80 r5:c1c2f800 r4:c1c2f9c4
[<bf014000>] (init+0x0/0x1c [g_ether]) from [<c00641cc>] (sys_init_module+0x1384/0x142c)
[<c0062e48>] (sys_init_module+0x0/0x142c) from [<c002eea0>] (ret_fast_syscall+0x0/0x2c)
Code: e598718c e50b202c e51b302c e28720a0 (e587309c) 
---[ end trace 007a4d754b0fcbe1 ]---
 
I just started playing with my Wiz again after some months of other projects.

Still with the 1.2.1 firmware g_ether does not work for me.
What does work for me is installing a custom kernel with the 1.2.1 firmware and using custom modules for lf1000_udc and g_ether.
In other words: I now have a _working_ usb network connection (just got it to work a few minutes ago but I'm too excited to do a real test (netcat connection works) ;-) ) but it definitely seems to require building a kernel yourself (and then replacing uImage from fw 1.2.1 with your own uImage). (I built my kernel from the wiz branch in the pandora.git).
I'm not yet sure if this brakes something - I'm not going to buy any commercial games for the wiz so I don't care if this part is broken...

If anyone is interested in getting this to work I'll write up the process. So far I was not able to just replace the kernel without updating the whole filesystem from the sd card - this kind of sucks. I guess I'll create a custom bootloader soon that can do this for me...

Now the Wiz got a lot more interesting again for me :)
 
hiben said:
built my kernel from the wiz branch in the pandora.git

just to note, this is an early version of the firmware - i think it is (almost?) equal to 1.1.0. that's the reason why it's working, because in this kernel GPH didn't ruin it yet ;)
 
Last edited by a moderator:
hmn said:
I also have this problem with FW 1.2.1:

Code:
Unable to handle kernel NULL pointer dereference at virtual address 0000009c

This looks like the kernel module is trying to dereference a structure member off a NULL pointer.

Code:
CPU: 0    Not tainted  (2.6.24 #665)

Edited:

The sources I used to compile the 1.1.0 version of the USBNetwork module is 'linux-2.6.24-pollux'. So it seems they have made further modifications to the kernel beyond what appears in the 'pollux' archive version.
 
Last edited by a moderator:
Back
Top