Unslung/WL500g packages available for Oleg's firmware

Link: http://sourceforge.net/projects/fuse
There is Optware make file for 2.6 kernel: http://trac.nslu2-linux.org/optware/...odules-fuse.mk

I've tried to do this for 2.4 and provided kernel dir with http://trac.nslu2-linux.org/optware/...rmware-oleg.mk

But fuse configure did not understand it. So I've figured out that this could be a problem of 2.4.20 kernel that will need a patch to include fuse at all.

From Fuse FAQ:

Quote:

What version of FUSE do I need to use FUSE with Linux 2.4?

FUSE 2.5.3 (supports 2.4.21 or later); later versions include a kernel module compatible with Linux 2.6 only (Linux 2.6.9 or later, as of FUSE 2.6.1).

The latest version of the FUSE libraries retains compatibility with the module for 2.4.x .

I think, I've tried latest but it seems that I should 2.5.3 but this seems to be suported by 2.4.21 and not 2.4.20.
So some kernel patch will still be needed. Or maybe some previous fuse release.

Will report this ASAP.

http://pastebin.ca/421577 describes make/fuse.mk that fails to build kernel module.

oleo, please post error messages too.

At the moment I've no host to build optware stuff.

Build log for make fuse:
http://pastebin.ca/424607 with default toolchain

with 4.1.1 is almost the same.

Look:

gcc -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -pipe -msoft-float -I/home/leon/optware/wl500g/builds/firmware-oleg/src/linux/linux/include -I. -D__KERNEL__ -DMODULE -D_LOOSE_KERNEL_NAMES -DFUSE_VERSION=\"2.5.3\" -c dev.c -o dev.o

Why does it call gcc, not the mipsel-linux-gcc? Also, some kernel defines seems to be missing too...

UH. This is really true. I will take a look why mipsel is not used.

Standard module like USB gets compiled with:

Code:

# mipsel-linux-gcc -D__KERNEL__ -I/home/leon/optware/wl500g/builds/firmware-oleg/src/linux/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -I/home/leon/optware/wl500g/builds/firmware-oleg/src/linux/linux/../../include -DBCMDRIVER -I /home/leon/optware/wl500g/builds/firmware-oleg/src/linux/linux/include/asm/gcc -G 0 -mno-abicalls -fno-pic -pipe -mcpu=r4600 -mips2 -Wa,--trap -m4710a0kern -DMODULE -mlong-calls -fno-common -nostdinc -iwithprefix include -DKBUILD_BASENAME=usb -DEXPORT_SYMTAB -c usb.c

Following this sample I've changed fuse/kernel/Makefile to

Code:

CC = /opt/brcm/hndtools-mipsel-linux/bin/mipsel-linux-gcc LD = /opt/brcm/hndtools-mipsel-linux/bin/mipsel-linux-ld CFLAGS = -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -pipe -fno-common -fomit-frame-pointer -mcpu=r4600 -mips2 -Wa,--trap -m4710a0kern CPPFLAGS = -I/home/leon/optware/wl500g/builds/firmware-oleg/src/linux/linux/include -I. -D__KERNEL__ -DMODULE -D_LOOSE_KERNEL_NAMES -DFUSE_VERSION=\"$(VERSION)\"

After that change I've got:

Code:

leon@duo:~/optware/wl500g/builds/fuse/kernel$ make /opt/brcm/hndtools-mipsel-linux/bin/mipsel-linux-gcc -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -pipe -fno-common -fomit-frame-pointer -mcpu=r4600 -mips2 -Wa,--trap -m4710a0kern -I/home/leon/optware/wl500g/builds/firmware-oleg/src/linux/linux/include -I. -D__KERNEL__ -DMODULE -D_LOOSE_KERNEL_NAMES -DFUSE_VERSION=\"2.5.3\" -c dev.c -o dev.o /opt/brcm/hndtools-mipsel-linux/bin/mipsel-linux-gcc -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -pipe -fno-common -fomit-frame-pointer -mcpu=r4600 -mips2 -Wa,--trap -m4710a0kern -I/home/leon/optware/wl500g/builds/firmware-oleg/src/linux/linux/include -I. -D__KERNEL__ -DMODULE -D_LOOSE_KERNEL_NAMES -DFUSE_VERSION=\"2.5.3\" -c dir.c -o dir.o /opt/brcm/hndtools-mipsel-linux/bin/mipsel-linux-gcc -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -pipe -fno-common -fomit-frame-pointer -mcpu=r4600 -mips2 -Wa,--trap -m4710a0kern -I/home/leon/optware/wl500g/builds/firmware-oleg/src/linux/linux/include -I. -D__KERNEL__ -DMODULE -D_LOOSE_KERNEL_NAMES -DFUSE_VERSION=\"2.5.3\" -c file.c -o file.o /opt/brcm/hndtools-mipsel-linux/bin/mipsel-linux-gcc -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -pipe -fno-common -fomit-frame-pointer -mcpu=r4600 -mips2 -Wa,--trap -m4710a0kern -I/home/leon/optware/wl500g/builds/firmware-oleg/src/linux/linux/include -I. -D__KERNEL__ -DMODULE -D_LOOSE_KERNEL_NAMES -DFUSE_VERSION=\"2.5.3\" -c inode.c -o inode.o inode.c:598: unknown field `alloc_inode' specified in initializer inode.c:598: warning: initialization from incompatible pointer type inode.c:599: unknown field `destroy_inode' specified in initializer inode.c:599: warning: initialization from incompatible pointer type inode.c: In function `fuse_inode_init_once': inode.c:702: warning: implicit declaration of function `inode_init_once' make: *** [inode.o] Error 1

Where offending lines are:

Code:

static struct super_operations fuse_super_operations = { .alloc_inode = fuse_alloc_inode, .destroy_inode = fuse_destroy_inode, .read_inode = fuse_read_inode, .clear_inode = fuse_clear_inode, .put_super = fuse_put_super, .statfs = fuse_statfs, .show_options = fuse_show_options, };

And if I comment out

Code:

// .alloc_inode = fuse_alloc_inode, // .destroy_inode = fuse_destroy_inode,

Module gets compiled :)

The problematic 2.4.20 header that lacks alloc_inode and destroy_inode is include/linux/fs.h that looks like:

PHP Code:

struct super_operations { void (*read_inode) (struct inode *); /* reiserfs kludge. reiserfs needs 64 bits of information to ** find an inode. We are using the read_inode2 call to get ** that information. We don't like this, and are waiting on some ** VFS changes for the real solution. ** iget4 calls read_inode2, iff it is defined */ void (*read_inode2) (struct inode *, void *) ; void (*dirty_inode) (struct inode *); void (*write_inode) (struct inode *, int); void (*put_inode) (struct inode *); void (*delete_inode) (struct inode *); void (*put_super) (struct super_block *); void (*write_super) (struct super_block *); void (*write_super_lockfs) (struct super_block *); void (*unlockfs) (struct super_block *); int (*statfs) (struct super_block *, struct statfs *); int (*remount_fs) (struct super_block *, int *, char *); void (*clear_inode) (struct inode *); void (*umount_begin) (struct super_block *); /* Following are for knfsd to interact with "interesting" filesystems * Currently just reiserfs, but possibly FAT and others later * * fh_to_dentry is given a filehandle fragement with length, and a type flag * and must return a dentry for the referenced object or, if "parent" is * set, a dentry for the parent of the object. * If a dentry cannot be found, a "root" dentry should be created and * flaged as DCACHE_NFSD_DISCONNECTED. nfsd_iget is an example implementation. * * dentry_to_fh is given a dentry and must generate the filesys specific * part of the file handle. Available length is passed in *lenp and used * length should be returned therein. * If need_parent is set, then dentry_to_fh should encode sufficient information * to find the (current) parent. * dentry_to_fh should return a 1byte "type" which will be passed back in * the fhtype arguement to fh_to_dentry. Type of 0 is reserved. * If filesystem was exportable before the introduction of fh_to_dentry, * types 1 and 2 should be used is that same way as the generic code. * Type 255 means error. * * Lengths are in units of 4bytes, not bytes. */ struct dentry * (*fh_to_dentry)(struct super_block *sb, __u32 *fh, int len, int fhtype, int parent); int (*dentry_to_fh)(struct dentry *, __u32 *fh, int *lenp, int need_parent); int (*show_options)(struct seq_file *, struct vfsmount *); };

Should missing functions be ommited or reconnected to some other func?

I suggest to backport fs.o from 2.4.21 or higher. And I really miss ext2 in Oleg firmware. So much that I've created
package that builds firmware-oleg with mine enables. See http://trac.nslu2-linux.org/optware/...rmware-oleg.mk for details.

hi there,

transmission is missing in http://ipkg.nslu2-linux.org/feeds/op...table/Packages.
Is this a mistake? The ipkg files are still there. I did not check if any other packages are missing in the list.

wengi

Quote:

Originally Posted by wengi

hi there,

transmission is missing in http://ipkg.nslu2-linux.org/feeds/op...table/Packages.
Is this a mistake? The ipkg files are still there. I did not check if any other packages are missing in the list.

wengi

This means that the transmission package failed to build on the autobuilder machine.

Just manually download the latest ipkg and ipkg install it from the local directory.

-- Rod

Openswan

I am interested in getting Openswan or some other ipsec software running on my wl500pg.(Have asterkisk running on it fine now just need a tunnel back to the office and I can wear pajamas for the rest of my life.)

Can someone point me in the direction of where to start?

1. get some linux box (virtualbox and such)
2. Read http://trac.nslu2-linux.org/optware/wiki
3. make oleg-target
4. cd oleg
5. make directories toolchain
6. make make/openswan.mk
7. edit openswan.mk to get buildable package with make openswan-check
8. post me openswan.mk or contact rwhitby for svn access

ipkg package oww for the WL-500GP

Hi,

i have a problem with an ipkg package for the WL-500GP.
I would like to install the new Version oww_0.82.1-1_mipsel.ipk (One Wire Weather) on my Asus WL-500GP. Until now i have installed it from http://ipkg.nslu2-linux.org/feeds/unslung/wl500g . Now, there is no new Version available, only the oww_0.82.0-1_mipsel.ipk. I will use the oww_0.82.1-1_mipsel.ipk from the http://ipkg.nslu2-linux.org/feeds/op...cross/unstable directory. But after install (when i will start owwnogui) i get an "Segmentation fault".
Is this a problem with the transmission package on the autobuilder machine? Who can build the new version for the http://ipkg.nslu2-linux.org/feeds/unslung/wl500g directory ? Or is it normally the same as the http://ipkg.nslu2-linux.org/feeds/op...cross/unstable ?
But if it is so, whats the "Segmentation fault" problem? I have now reinstalled oww_0.82.0-1_mipsel.ipk from http://ipkg.nslu2-linux.org/feeds/unslung/wl500g, all is o.k. (with the old version).
At http://www2.buoy.com/pipermail/weath...ay/008787.html i have talked with the developer of the oww package, but he can´t help me with the package for the WL-500GP.
On http://ipkgfind.nslu2-linux.org/ i cant find oww_0.82.1-1_mipsel.ipk for /unslung/wl500g.

Holger

wl500g is deprecated! Use oleg feed. openwrt-brcm2 4feed is for OpenWRT kamikaze 7.09.

RTFM Links:
http://trac.nslu2-linux.org/optware
http://www.nslu2-linux.org/wiki/FAQ/Optware-uClibcBuild
http://www.nslu2-linux.org/wiki/FAQ/OptwareWl500gBuild
http://www.nslu2-linux.org/wiki/Optware/Transmission
http://www.nslu2-linux.org/wiki/Optw...RT-brcm24Build

Donations needed to continue Optware packages service

Hello all Optware users,

If you use Optware packages from nslu2-linux.org, please help us keep them coming as we are running out of disk space.

Over the years, the nslu2-linux.org group has been developing Optware packages for well over 20 NAS/router devices. As we enable more and more Optware packages and feeds, the disk and bandwidth usage for hosting, autobuilder, and testing server keeps climbing. Right now, >80% of nslu2-linux.org access are for Optware feeds. And the disk on autobuilder is approaching 90% capacity.

We ask your help with your generous donation to nslu2-linux.org http://nslu2-linux.org/wiki/Main/Donate. We are targeting US$1000 total in this donation drive. This is to cover the immediate purchase of 5 1.5 TB hard disks to be used in a RAID5 plus hotspare configuration, and also for other expenses such as domain fees, hosting costs. So far all nslu2-linux.org infrastructure has been paid for by previous donations from the nslu2 and nas-central community. Previous donation and spending can be seen at http://nslu2-linux.org/wiki/Info/DonationList .

Thank you very much,

Brian Zhou (Optware feed manager)
On behalf of the nslu2-linux.org team

mini Ruby

Not sure whether or not this is the correct place to post, nevertheless -

I'm interested in running Ruby on my WL-500W / Oleg router.

I desire to create PABX functionality with a Ruby script that I've developed. My understanding is that there is a mini-Ruby available.

Any feedback on the potential viability of running a Ruby script on Oleg appreciated. A seach has yielded very limited results, mostly in Russian.