Success and some ideas

Hi!

I'm glad to report that I've managed to overcome the problems I had when I first tried VDR-NG-EM 0.6. It was similar to what was discussed here. For testing some plugins, 'vdr_pluginopts = " -P* "' seemed like a good option, but in combination with "AbortWhenPluginFails = 0", some plugins didn't load. When I started calling all plugins individually, the problems disappeared. Even my 2,5"-USB-powered hard disk works now. One thing that confused me a bit was the comparatively late mounting process, but having understood it now, I especially like that I can start watching TV even when the filesystem needs to be checked.
I've also started translating and editing the various *.conf files under /etc/vdr into German. Doing that, I found what I believe to be some inconsistencies in /etc/vdr/plugins/filebrowser/commands.conf: At least when using busybox, the symlink command shouldn't contain the option 'v' - it doesn't exist in busybox's ln. Similarly, the unzip command may not be available, so I think the respective lines ought to be removed.

Apart from that, I've being pondering on this idea:
As the network interface has been a bottleneck in all firmware versions (even though NFS is improved in VDR-NG-EM 0.6) - why not bypass it by using USB-networking? I don't really know how feasible that is, however, there seem to be some indications that it's not pointless:
*other embedded devices like an NSLU2 or a Beagleboard can do it. For example, all I need to set up a usb network between my NSLU2 (SlugOS 5.3) and an old Fritzbox SL is a simple usb cable and (on the NSLU2) cdc_ether and usbnet modules.
*at least for lemmi-firmware, some additional usb modules have been compiled before:

LCD
Keyboard
CD/DVD related stuff

I must admit I was curious and so I already found out that simply changing the respective parameters ("CONFIG_USB_CDCETHER = m" and "CONFIG_USB_USBNET = m") in the kernel configuration is not enough - usbnet fails to build with this error:

Código:

mips-linux-egcs -D__KERNEL__ -I/home/spain/VDR-NG-EM/VDR-NG-FW/build/slin_m740/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -I /home/spain/VDR-NG-EM/VDR-NG-FW/build/slin_m740/include/asm/gcc -G 0 -mno-abicalls -fno-pic -pipe -mcpu=vr4100 -mips2 -Wa,--trap,-mfix-vr4120 -DMODULE -mlong-calls  -nostdinc -iwithprefix include -DKBUILD_BASENAME=usbnet  -c -o usbnet.o usbnet.c
usbnet.c: In function `usbnet_probe':
usbnet.c:2518: structure has no member named `ethtool_ops'
usbnet.c: At top level:
usbnet.c:2755: variable `usbnet_ethtool_ops' has initializer but incomplete type
usbnet.c:2756: unknown field `get_drvinfo' specified in initializer
usbnet.c:2756: warning: excess elements in struct initializer after `usbnet_ethtool_ops'
usbnet.c:2757: unknown field `get_link' specified in initializer
usbnet.c:2757: warning: excess elements in struct initializer after `usbnet_ethtool_ops'
usbnet.c:2758: unknown field `get_msglevel' specified in initializer
usbnet.c:2758: warning: excess elements in struct initializer after `usbnet_ethtool_ops'
usbnet.c:2759: unknown field `set_msglevel' specified in initializer
usbnet.c:2759: warning: excess elements in struct initializer after `usbnet_ethtool_ops'
make[3]: *** [usbnet.o] Fehler 1
make[3]: Verlasse Verzeichnis '/home/spain/VDR-NG-EM/VDR-NG-FW/build/slin_m740/drivers/usb'
make[2]: *** [_modsubdir_usb] Fehler 2
make[2]: Verlasse Verzeichnis '/home/spain/VDR-NG-EM/VDR-NG-FW/build/slin_m740/drivers'
make[1]: *** [_mod_drivers] Fehler 2
make[1]: Verlasse Verzeichnis '/home/spain/VDR-NG-EM/VDR-NG-FW/build/slin_m740'
make: *** [/home/spain/VDR-NG-EM/VDR-NG-FW/m7x0_xtc_uclibc_Linux-i686/stagefiles/.siemens-linux-kernel_m740_compiled] Fehler 2


("Fehler" means error, "Verlasse Verzeichnis" = "Leaving directory")

If just "CONFIG_USB_CDCETHER = m" ist set, a module is build that can at least be inserted without causing apparent errors (though no functionality tests have been made).
Any ideas on this issue are welcome (e.g. how to solve the above error or simply why the whole thing is a bad idea anyway...).

Regards,

Thomas

Hi Thomas,

Nobody escribió:[...]all I need to set up a usb network between my NSLU2 (SlugOS 5.3) and an old Fritzbox SL is a simple usb cable and (on the NSLU2) cdc_ether and usbnet modules.

The cdc_ether module requires a unpowered USB client port (with a male MiniUSB, MicroUSB or USB Type B connector) and not a USB host port with USB Type A female connector like the two that the M740AV has. I don't know exactly how are wired the USB ports, but I don't think that USB client and USB host ports are wired together. Also, you can't load simultaneously host and client kernel modules for the same port, so in the case that you manage to enable the USB client mode, you will not be able to use a Hard Disk.

I'm aware of that. Just like the M740AV, the NSLU2 can only act as a USB host - that's what I've successfully tested. It's the Fritzbox I mentioned that acts as a USB device (cf. http://www.zebradem.com/wiki/images/8/81/FRITZBox_SL-1.png ). Newer Fritzboxes don't seem to have this feature. I guess it was meant for people who basically wanted to use it as an ADSL modem. So with regard to USB, the M740AV would stay a host all the time and even though the Fritzbox is a device in the USB sense, it would act as a network host (cf. http://www.linux-usb.org/usbnet/ , especially the paragraph starting with "Linux PDAs" is relevant in this case.) People without such a USB device might be able to use a host-to-host cable.
Apart from that, I don't deny that there might well be side effects on USB storage. I vaguely remember reading something about a rather incomplete implementation of USB on the M740AV on the German forum. However, that doesn't explain why building the module fails - isn't that standard kernel code?

Thanks nevertheless,

Thomas

OK, reading Spanish takes a while for me, but now I've come across this thread:
https://vdr-m7x0.foroactivo.com.es/t1020-usar-puerto-usb-2-para-adaptador-de-red-es-posible
Let's see where it takes me.

Cheers,

Thomas

No, Siemens modified the kernel and at least this part does not match with 2.4.21 original kernel and therefore fail to compile.

Here (only in spanish) we talk about compiling usbnet module and checking changes with original kernels (usbnet in our kernel was more similar to 2.4.22) I did a patch to compile and load it in firmware (now it is lost ), although finally this module did not recognize the hardware tested.

If you are interested I can redo the patch, but you just have to remove "ethtool_ops" in usbnet.c because this is not included in 2.4.21 or 2.4.22 kernels and it will compile.

Hi Bittor!

I followed your instructions from the other thread (well, as good as I could without the patch) and removed ethtool_ops from usbnet.c. The module compiles now, however, on insmod I get the same error that was discussed in the other thread and probably solved by your lost patch :

Código:

insmod: unresolved symbol generic_mii_ioctl

Although I've found the relevant line in usbnet.c, I'd be much happier if you could redo the patch - messing with the source code of kernel modules is not my no. 1 competence and I gladly leave that to people who know what they're doing. In return, I'll do the testing and I'll report back.

Thanks in advance,

Thomas

OK, I thought that only was needed to remove "ethtool_ops" to work.

I'll upload the patch soon.

I attached patches to compile usbnet modules in our kernel.

Really are patches to get the original source code of 2.4.21 or 2.4.22 kernels and you need only one of them.

You have to unzip the attached file and copy a file .patch (2.4.22 has fewer changes to ours) in:
patches/siemens-linux-kernel/common
and run "make clean-siemens-linux-kernel distclean-siemens-linux-kernel && make" to rebuild kernel with new patch.

It works!
I followed your instructions, then copied the modules (usbnet.o and CDCEther.o) to the box and inserted them with insmod. Next I connected the Fritzbox via USB. A first lsmod told me that both modules were unused and I was about to get disappointed when I thought I could just as well pull the "I'll be lucky" card, so I simply entered:

Código:

 ifconfig eth1 192.168.3.45 netmask 255.255.255.0 up

Afterwards, I was able to connect via ftp and ssh while the "real" network cable wasn't plugged in. I haven't been able to make any real speed test yet because my LAN is a routing hell and this new option raises a few other questions for me but anyway, having it as an option is definitely a plus.

Thanks for the help and especially for the patches.

Thomas

Do you have used the patch which the code is adapted from 2.4.21 or 2.4.22 kernel?

We can add a parameter to .config file for compile usbnet modules more easily and add files .o directly to firmware.

I used the 2.4.22 patch.
Maybe some more people should experiment with it before it's added to the firmware. It still might turn out to perform poorly or have side effects on usb storage. On the other hand, it's obviously a good idea to have code that won't break when compiling.

Regards,

Thomas