OpenWrt Forum Archive

Topic: New unofficial whiterussian firmware

The content of this topic has been archived between 31 Mar 2018 and 23 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hi!

I build a new whiterussian firmware to fix a problem as discussed here but some of you could find it useful for other situations, so I post it here for review and comment.

Kamikaze have all this resolved plus is a lot better, this is just a bandage to whiterussian (which is obsolete), please if you can, use Kamikaze instead.

Latest source patch (Version 5).

Version 5 - May/20/2007 - Changes:
Decouple netfilter (specially ip_conntrack) from the kernel to external loadable modules in kmod_iptables package.
Fix selects and depends for kmod_iptables.
Fix iptables list of builtin extensions.

Version 4 - May/20/2007 - Changes:
Resync with svn.
Revert back gcc, kernel, wlcompat, switch, iptables and squashfs versions in order to keep binary/source compatibility and minimum differences with upstream Whiterussian.
Port Kamikaze's bcm47xx arch to kernel 2.4.30 so latest wl driver works with this kernel.

Version 3 - May/4/2007 - Changes:
wl driver from 4.80.9.2 to 4.80.53.0
wificonf patched to recognize wl?_spect nvram variable, if not present disable spectrum management (802.11h & 802.11d) at wifi setup.
netconsole dropped (instability with wl driver).

Version 2 - May/2/2007 - Changes:
Build fixes.
netconsole added.

Version 1 - April/25/2007 - Original changes to whiterussian (svn):
gcc from 3.4.4 to 3.4.6
kernel from 2.4.30 to 2.4.34.4
wl driver from 3.90.37.0 to packaged 4.80.9.2
wlcompat driver from kamikaze
diag driver from kamikaze
switch driver from kamikaze
iptables from 1.3.3 to 1.3.5
squashfs from 2.1r2 to 3.0

(Last edited by solca on 20 May 2007, 20:34)

Great work.  Thank you.

I am baffled by why 802.11h is even present? From what I have read on Wikipedia it's an interference-avoidance addition to 802.11a, which makes no sense on an 802.11g radio.  Anyhow, will try the firmware out on an in-house AP.

Hi!

Good news: Seems the "wl spect 0" setting works! Great Job,  Solca!!!!! smile

This sounds good to me, thanks to everyone involved in this topic by hunting down the problem, building custom firmwares and testing them!

@devs:
Is it likely to get a new official White Russian release based on Solca's changes if further testing during the next days and weeks is successful?

solca wrote:

wl driver from 3.90.37.0 to 4.80.9.2

Why not the 4.80.53.0?

vincentfox wrote:

I am baffled by why 802.11h is even present? From what I have read on Wikipedia it's an interference-avoidance addition to 802.11a, which makes no sense on an 802.11g radio.  Anyhow, will try the firmware out on an in-house AP.

Good question, just a guess: wl driver works for 802.11a and 802.11bg, just that the broadcom developers forgot to disable 802.11h (or 802.11d) when operating in 802.11bg environment, pretty sure it is a bug.

The question is: why just Intel cards seems affected?

booBot wrote:
solca wrote:

wl driver from 3.90.37.0 to 4.80.9.2

Why not the 4.80.53.0?

Because was a typo, initially I was targetting 4.80.53.0 and just change the version description, not the actual code to fetch it, as I was trying which ones were working versions the code remains in 4.80.9.2.

I'm working in a new version which correctly will use 4.80.53.0 and will patch the wificonf source to disable 802.11h and 802.11d in startup so no special steps needs to be made to have a working WRT.

I'm not sure whether this is related to solca's patch, or an issue related to the current Whiterussian SVN. I applied solca's patch to the latest SVN image and selected to build image maker. Everthing built fine, whiterussian images produced and image builder bzipped tar archive.

I installed the "openwrt-brcm-2.4-squashfs.trx" image (i.e. the one built during the SVN Whiterussian build process) onto a Buffalo WHR-G54S and it worked perfectly (Excellent work solca :-) ).

I then tested image builder and built the default firmware and a slightly customised image. When either of these images were installed on the Buffalo, the router would boot successfully the first time, but when I tried to reboot, it failed to boot and sat there with the red light flashing. When I reinstalled the original firmware image (i.e. the one built during the SVN Whiterussian build process), the router booted up fine and reboots fine.

I tried to reinstall the image builder firmware images (default firmware and a slightly customised image) and the reboot issue came back.

I tried the same images on a Belkin F5D7231-4P and the same problem occurred.

Could image builder have been broken, does anyone have any suggestions ?

Thanks.

* Just tried again with a new Buffalo WHR-G54S out of the box, same problem although I managed to reboot it 5 or 6 times before it died :-(

-----------

I've just tried to apply the patch to Whiterussian-0.9 (i.e. not SVN) and get the follow error, it looks like the build process is looking for iptables-1.3.3 rather than the updated version 1.3.5. Can anyone suggest a fix ?

:191:1: warning: this is the location of the previous definition
extensions/libipt_connbytes.c: In function `parse':
extensions/libipt_connbytes.c:87: error: `IPT_CONNBYTES_WHAT_PKTS' undeclared (first use in this function)
extensions/libipt_connbytes.c:87: error: (Each undeclared identifier is reported only once
extensions/libipt_connbytes.c:87: error: for each function it appears in.)
extensions/libipt_connbytes.c:89: error: `IPT_CONNBYTES_WHAT_BYTES' undeclared (first use in this function)
extensions/libipt_connbytes.c:91: error: `IPT_CONNBYTES_WHAT_AVGPKT' undeclared (first use in this function)
extensions/libipt_connbytes.c: In function `print_mode':
extensions/libipt_connbytes.c:114: error: `IPT_CONNBYTES_WHAT_PKTS' undeclared (first use in this function)
extensions/libipt_connbytes.c:117: error: `IPT_CONNBYTES_WHAT_BYTES' undeclared (first use in this function)
extensions/libipt_connbytes.c:120: error: `IPT_CONNBYTES_WHAT_AVGPKT' undeclared (first use in this function)
make[3]: *** [extensions/libipt_connbytes_sh.o] Error 1
make[3]: Leaving directory `/home/kenw/newbuildwhiterussian/whiterussian-0.9/build_mipsel/iptables-1.3.3'
make[2]: *** [/home/kenw/newbuildwhiterussian/whiterussian-0.9/build_mipsel/iptables-1.3.3/.built] Error 2
make[2]: Leaving directory `/home/kenw/newbuildwhiterussian/whiterussian-0.9/package/iptables'
make[1]: *** [iptables-compile] Error 2
make[1]: Leaving directory `/home/kenw/newbuildwhiterussian/whiterussian-0.9/package'
make: *** [package/compile] Error 2

(Last edited by kebab on 4 May 2007, 20:08)

kebab wrote:

I'm not sure whether this is related to solca's patch, or an issue related to the current Whiterussian SVN. I applied solca's patch to the latest SVN image and selected to build image maker. Everthing built fine, whiterussian images produced and image builder bzipped tar archive.

I installed the "openwrt-brcm-2.4-squashfs.trx" image (i.e. the one built during the SVN Whiterussian build process) onto a Buffalo WHR-G54S and it worked perfectly (Excellent work solca :-) ).

I then tested image builder and built the default firmware and a slightly customised image. When either of these images were installed on the Buffalo, the router would boot successfully the first time, but when I tried to reboot, it failed to boot and sat there with the red light flashing. When I reinstalled the original firmware image (i.e. the one built during the SVN Whiterussian build process), the router booted up fine and reboots fine.

I tried to reinstall the image builder firmware images (default firmware and a slightly customised image) and the reboot issue came back.

I tried the same images on a Belkin F5D7231-4P and the same problem occurred.

Could image builder have been broken, does anyone have any suggestions ?

Thanks.

* Just tried again with a new Buffalo WHR-G54S out of the box, same problem although I managed to reboot it 5 or 6 times before it died :-(

-----------

I've just tried to apply the patch to Whiterussian-0.9 (i.e. not SVN) and get the follow error, it looks like the build process is looking for iptables-1.3.3 rather than the updated version 1.3.5. Can anyone suggest a fix ?

:191:1: warning: this is the location of the previous definition
extensions/libipt_connbytes.c: In function `parse':
extensions/libipt_connbytes.c:87: error: `IPT_CONNBYTES_WHAT_PKTS' undeclared (first use in this function)
extensions/libipt_connbytes.c:87: error: (Each undeclared identifier is reported only once
extensions/libipt_connbytes.c:87: error: for each function it appears in.)
extensions/libipt_connbytes.c:89: error: `IPT_CONNBYTES_WHAT_BYTES' undeclared (first use in this function)
extensions/libipt_connbytes.c:91: error: `IPT_CONNBYTES_WHAT_AVGPKT' undeclared (first use in this function)
extensions/libipt_connbytes.c: In function `print_mode':
extensions/libipt_connbytes.c:114: error: `IPT_CONNBYTES_WHAT_PKTS' undeclared (first use in this function)
extensions/libipt_connbytes.c:117: error: `IPT_CONNBYTES_WHAT_BYTES' undeclared (first use in this function)
extensions/libipt_connbytes.c:120: error: `IPT_CONNBYTES_WHAT_AVGPKT' undeclared (first use in this function)
make[3]: *** [extensions/libipt_connbytes_sh.o] Error 1
make[3]: Leaving directory `/home/kenw/newbuildwhiterussian/whiterussian-0.9/build_mipsel/iptables-1.3.3'
make[2]: *** [/home/kenw/newbuildwhiterussian/whiterussian-0.9/build_mipsel/iptables-1.3.3/.built] Error 2
make[2]: Leaving directory `/home/kenw/newbuildwhiterussian/whiterussian-0.9/package/iptables'
make[1]: *** [iptables-compile] Error 2
make[1]: Leaving directory `/home/kenw/newbuildwhiterussian/whiterussian-0.9/package'
make: *** [package/compile] Error 2

do a make distclean and start over... that should resolve your issue (assuming your patch applied cleanly).

liquid wrote:

do a make distclean and start over... that should resolve your issue (assuming your patch applied cleanly).

liquid: do you still have a copy of my _first_original_ patch? I delete it and now have problems with the next iterations as I modified a lot of code for debugging the association issues wink

Edit: Found the problem, was netconsole module, I remove it (it help me a lot in the beginning).

(Last edited by solca on 4 May 2007, 23:22)

Thanks Liquid.

The patch applied cleanly, but unfortunately make distclean didn't help.

kebab wrote:

Thanks Liquid.

The patch applied cleanly, but unfortunately make distclean didn't help.

kebab could you please check if you still have problems with my latest patch?  Thank you.

Solca, I still have the same problem with the new patch.

/home/kenw/newbuildwhiterussian/whiterussian-0.9/staging_dir_mipsel/lib/gcc/mipsel-linux-uclibc/3.4.6/../../../../mipsel-linux-uclibc/sys-include/sys/cdefs.h:191:1: warning: this is the location of the previous definition
extensions/libipt_connbytes.c: In function `parse':
extensions/libipt_connbytes.c:87: error: `IPT_CONNBYTES_WHAT_PKTS' undeclared (first use in this function)
extensions/libipt_connbytes.c:87: error: (Each undeclared identifier is reported only once
extensions/libipt_connbytes.c:87: error: for each function it appears in.)
extensions/libipt_connbytes.c:89: error: `IPT_CONNBYTES_WHAT_BYTES' undeclared (first use in this function)
extensions/libipt_connbytes.c:91: error: `IPT_CONNBYTES_WHAT_AVGPKT' undeclared (first use in this function)
extensions/libipt_connbytes.c: In function `print_mode':
extensions/libipt_connbytes.c:114: error: `IPT_CONNBYTES_WHAT_PKTS' undeclared (first use in this function)
extensions/libipt_connbytes.c:117: error: `IPT_CONNBYTES_WHAT_BYTES' undeclared (first use in this function)
extensions/libipt_connbytes.c:120: error: `IPT_CONNBYTES_WHAT_AVGPKT' undeclared (first use in this function)
make[3]: *** [extensions/libipt_connbytes_sh.o] Error 1
make[3]: Leaving directory `/home/kenw/newbuildwhiterussian/whiterussian-0.9/build_mipsel/iptables-1.3.3'
make[2]: *** [/home/kenw/newbuildwhiterussian/whiterussian-0.9/build_mipsel/iptables-1.3.3/.built] Error 2
make[2]: Leaving directory `/home/kenw/newbuildwhiterussian/whiterussian-0.9/package/iptables'
make[1]: *** [iptables-compile] Error 2
make[1]: Leaving directory `/home/kenw/newbuildwhiterussian/whiterussian-0.9/package'
make: *** [package/compile] Error 2


Contents of the build directory /home/kenw/newbuildwhiterussian/whiterussian-0.9/build_mipsel

drwxr-xr-x   4 root root   4096 May  5 11:30 base-files
drwxr-xr-x   7 2997 users  4096 May  5 11:30 bridge-utils-1.0.6
drwxr-xr-x  29 1000  1000  4096 May  5 11:35 busybox-1.00
drwxr-xr-x   9 kenw users  4096 May  5 11:36 dnsmasq-2.35
drwx------   7 1001  1001  4096 May  5 11:39 dropbear-0.48.1
drwxrwxrwx   7 1000  1000  4096 May  5 11:39 haserl-0.8.0
drwxrwxrwx   9  106 users 12288 May  5 11:42 ipkg-0.99.149
drwxr-sr-x   3 1000  1000  4096 May  5 10:47 ipkg-utils-1.7
drwxr-xr-x   9 1000  1000  4096 May  5 11:42 iptables-1.3.3
lrwxrwxrwx   1 root root     91 May  5 11:03 linux -> /home/kenw/newbuildwhiterussian/whiterussian-0.9/build_mipsel/linux-2.4-brcm/linux-2.4.34.4
drwxr-xr-x  11 root root   4096 May  5 11:29 linux-2.4-brcm
drwxr-xr-x   3 root root   4096 May  5 11:02 lzma
drwxr-xr-x   3 root root   4096 May  5 11:30 nvram
drwxr-xr-x  19 root   502  4096 May  5 11:04 squashfs3.0
drwxr-xr-x   2 root root   4096 May  5 11:42 stamp
drwxr-xr-x   2 root root   4096 May  5 11:01 target-utils

iptables-1.3.3 directory exists, shouldn't this be iptables-1.3.5 ?

Thanks

(Last edited by kebab on 5 May 2007, 11:50)

kebab wrote:

Solca, I still have the same problem with the new patch.

...

iptables-1.3.3 directory exists, shouldn't this be iptables-1.3.5 ?

Thanks

You are trying to apply this patch to whiterussian-0.9 and it doesn't apply cleanly, patch is for whiterussian svn.
On the other side is trivial to fix, just check whiterussian-0.9/package/iptables/Makefile.rej and fix the Makefile.

Thanks solca...

The reason I am trying to apply your patch to Whiterussian-0.9, is because of boot up issues I had with images generated with image builder (see my posting Yesterday 19:00:59).

I've just build a non-patched Whiterussian version from SVN, to see whether the boot issues are related to the current SVN or your patch.

Thanks again...

Now that wireless runs rock-stable I bumped into another issue. In my previous posts I wrote that even though the reboots have disappeared, a few devices seemed to have crashed. I did more research and actually the devices did not crash - only the network became non-functional.

This occurs at locations with real heavy usage - therefore very seldom. I managed to save a log - here are the essential lines:

May  6 12:31:06 wrt kern.err chillispot[703]: radius.c: 1269: 132 (No buffer space available) sendto() failed!
May  6 12:31:06 wrt kern.warn kernel: NET: 494 messages suppressed.
May  6 12:31:06 wrt kern.warn kernel: dst cache overflow

Results of free:

              total         used         free       shared      buffers
  Mem:        14284        13512          772            0          412
 Swap:            0            0            0
Total:        14284        13512          772

The dst cache very well explained here: http://www.mail-archive.com/netdev@vger … 02107.html - it is a routing cache.  When it overflows the device can't communicate anymore after a while.

According to /proc/sys/net/ipv4/route/max_size is 8192

I am not sure whether this is a problem or if the little WRT devices just reach their limits under extreme conditions. Also it might not be related to solca's version at all. In the past the devices simply rebooted before this cache could overflow.

EDIT: The number of entries given by "ip route ls cache" is normal when the cache overflows.

What is your opinion about it (should it be moved to a new thread?)?

lc

(Last edited by lc on 6 May 2007, 16:50)

lc wrote:
May  6 12:31:06 wrt kern.err chillispot[703]: radius.c: 1269: 132 (No buffer space available) sendto() failed!
May  6 12:31:06 wrt kern.warn kernel: NET: 494 messages suppressed.
May  6 12:31:06 wrt kern.warn kernel: dst cache overflow

Hi!

For me the 'dst cache overflow' is a consequence of the 'No buffer space available' when chillispot try to send data to your radius server.  Something is eating your memory (and that can be normal just high usage/traffic relative to WRT potential).  Maybe is time to put a big (more RAM) WRT in those locations or move chillispot to another box.  The 'No buffer space available' can be triggered by other factors, check'em too, I bet your problem is low mem condition.

lc wrote:

What is your opinion about it (should it be moved to a new thread?)?

Sure, is OT here.

Hey Solca, I built the firmware using your patch (v3) without problems.  Its running fine.  I'm looking at the binarys provided by linksys (nas, wl, etc), but I'm not sure what to do with wl_apsta and/or wl_apsta_mimo.

http://downloads.openwrt.org/sources/br … .2.tar.bz2

Do I need to replace wl.o or wlcompat.o with one of these?  Or perhaps I should not use the new binaries at all?

By the way, great work!

netprince wrote:

Hey Solca, I built the firmware using your patch (v3) without problems.  Its running fine.  I'm looking at the binarys provided by linksys (nas, wl, etc), but I'm not sure what to do with wl_apsta and/or wl_apsta_mimo.

http://downloads.openwrt.org/sources/br … .2.tar.bz2

Do I need to replace wl.o or wlcompat.o with one of these?  Or perhaps I should not use the new binaries at all?

By the way, great work!

You should use http://downloads.openwrt.org/sources/br … .0.tar.bz2 instead.

wl_apsta.o and wl_apsta_mimo.o are object files needed to construct the propietary wl.o driver (MIMO is for the pre 802.11n devices) so you don't need to mess with them, my patch downloads the above file, extracts the object files and build the wl.o driver.  You just need to copy the wl and nas binaries if you plan to use them.

Building from whiterussian SVN + solca patch (3rd revision) kmod-fuse build fails:

make[9]: Entering directory `/home/davide/openwrt/0.9-patched/whiterussian/openwrt/build_mipsel/linux-2.4-brcm/fuse-2.2.1/kernel'
/home/davide/openwrt/0.9-patched/whiterussian/openwrt/staging_dir_mipsel/bin/mipsel-linux-uclibc-gcc -D__KERNEL__ -I/home/davide/openwrt/0.9-patched/whiterussian/openwrt/build_mipsel/linux-2.4-brcm/linux-2.4.34.4/include -Wall -Wstrict-prototypes -Wno-trigraphs -Os -fno-strict-aliasing -fno-common -fno-builtin-sprintf -fomit-frame-pointer   -funit-at-a-time -pipe  -fno-unit-at-a-time -DMODULE -DFUSE_VERSION=\"2.2.1\" -nostdinc -iwithprefix include -DKBUILD_BASENAME=dev  -c -o dev.o dev.c
{standard input}: Assembler messages:
{standard input}:242: Error: opcode not supported on this processor: mips1 (mips1) `ll $3,8($4)'
{standard input}:244: Error: opcode not supported on this processor: mips1 (mips1) `sc $3,8($4)'
{standard input}:268: Error: opcode not supported on this processor: mips1 (mips1) `ll $2,8($4)'
{standard input}:270: Error: opcode not supported on this processor: mips1 (mips1) `sc $2,8($4)'
{standard input}:354: Error: opcode not supported on this processor: mips1 (mips1) `ll $3,52($16)'
{standard input}:356: Error: opcode not supported on this processor: mips1 (mips1) `sc $2,52($16)'
{standard input}:359: Error: opcode not supported on this processor: mips1 (mips1) `sync '
{standard input}:454: Error: opcode not supported on this processor: mips1 (mips1) `ll $3,52($16)'
{standard input}:456: Error: opcode not supported on this processor: mips1 (mips1) `sc $2,52($16)'
{standard input}:459: Error: opcode not supported on this processor: mips1 (mips1) `sync '
{standard input}:631: Error: opcode not supported on this processor: mips1 (mips1) `ll $6,8($5)'
{standard input}:633: Error: opcode not supported on this processor: mips1 (mips1) `sc $3,8($5)'
{standard input}:636: Error: opcode not supported on this processor: mips1 (mips1) `sync '
{standard input}:678: Error: opcode not supported on this processor: mips1 (mips1) `ll $2,8($5)'
{standard input}:680: Error: opcode not supported on this processor: mips1 (mips1) `sc $3,8($5)'
{standard input}:683: Error: opcode not supported on this processor: mips1 (mips1) `sync '
{standard input}:822: Error: opcode not supported on this processor: mips1 (mips1) `ll $2,20($4)'
{standard input}:824: Error: opcode not supported on this processor: mips1 (mips1) `sc $2,20($4)'
make[9]: *** [dev.o] Error 1
make[9]: Leaving directory `/home/davide/openwrt/0.9-patched/whiterussian/openwrt/build_mipsel/linux-2.4-brcm/fuse-2.2.1/kernel'
make[8]: *** [_mod_/home/davide/openwrt/0.9-patched/whiterussian/openwrt/build_mipsel/linux-2.4-brcm/fuse-2.2.1/kernel] Error 2
make[8]: Leaving directory `/home/davide/openwrt/0.9-patched/whiterussian/openwrt/build_mipsel/linux-2.4-brcm/linux-2.4.34.4'
make[7]: *** [all-spec] Error 2
make[7]: Leaving directory `/home/davide/openwrt/0.9-patched/whiterussian/openwrt/build_mipsel/linux-2.4-brcm/fuse-2.2.1/kernel'
make[6]: *** [all-recursive] Error 1
make[6]: Leaving directory `/home/davide/openwrt/0.9-patched/whiterussian/openwrt/build_mipsel/linux-2.4-brcm/fuse-2.2.1'
make[5]: *** [/home/davide/openwrt/0.9-patched/whiterussian/openwrt/build_mipsel/linux-2.4-brcm/fuse-2.2.1/.built] Error 2
make[5]: Leaving directory `/home/davide/openwrt/0.9-patched/whiterussian/openwrt/target/linux/package/fuse'
make[4]: *** [fuse-compile] Error 2
make[4]: Leaving directory `/home/davide/openwrt/0.9-patched/whiterussian/openwrt/target/linux/package'
make[3]: *** [/home/davide/openwrt/0.9-patched/whiterussian/openwrt/build_mipsel/stamp/.linux-compile] Error 2
make[3]: Leaving directory `/home/davide/openwrt/0.9-patched/whiterussian/openwrt/target/linux/linux-2.4'
make[2]: *** [2.4/brcm-compile] Error 2
make[2]: Leaving directory `/home/davide/openwrt/0.9-patched/whiterussian/openwrt/target/linux'
make[1]: *** [linux-compile] Error 2
make[1]: Leaving directory `/home/davide/openwrt/0.9-patched/whiterussian/openwrt/target'
make: *** [target/compile] Error 2

There is a similar problem with shfs

make[9]: Entering directory `/home/davide/openwrt/0.9-patched/whiterussian/openwrt/build_mipsel/linux-2.4-brcm/linux-2.4.34.4'
make -C  /home/davide/openwrt/0.9-patched/whiterussian/openwrt/build_mipsel/linux-2.4-brcm/shfs-0.35/shfs/Linux-2.4 CFLAGS="-D__KERNEL__ -I/home/davide/openwrt/0.9-patched/whiterussian/openwrt/build_mipsel/linux-2.4-brcm/linux-2.4.34.4/include -Wall -Wstrict-prototypes -Wno-trigraphs -Os -fno-strict-aliasing -fno-common -fno-builtin-sprintf -fomit-frame-pointer   -funit-at-a-time -pipe  -fno-unit-at-a-time -DMODULE" MAKING_MODULES=1 modules
make[10]: Entering directory `/home/davide/openwrt/0.9-patched/whiterussian/openwrt/build_mipsel/linux-2.4-brcm/shfs-0.35/shfs/Linux-2.4'
Makefile:52: warning: overriding commands for target `shfs.o'
/home/davide/openwrt/0.9-patched/whiterussian/openwrt/build_mipsel/linux-2.4-brcm/linux-2.4.34.4/Rules.make:97: warning: ignoring old commands for target `shfs.o'
/home/davide/openwrt/0.9-patched/whiterussian/openwrt/staging_dir_mipsel/bin/mipsel-linux-uclibc-gcc -D__KERNEL__ -I/home/davide/openwrt/0.9-patched/whiterussian/openwrt/build_mipsel/linux-2.4-brcm/linux-2.4.34.4/include -Wall -Wstrict-prototypes -Wno-trigraphs -Os -fno-strict-aliasing -fno-common -fno-builtin-sprintf -fomit-frame-pointer   -funit-at-a-time -pipe  -fno-unit-at-a-time -DMODULE  -nostdinc -iwithprefix include -DKBUILD_BASENAME=dcache  -c -o dcache.o dcache.c
{standard input}: Assembler messages:
{standard input}:165: Error: opcode not supported on this processor: mips1 (mips1) `ll $2,24($16)'
{standard input}:167: Error: opcode not supported on this processor: mips1 (mips1) `sc $2,24($16)'
{standard input}:554: Error: opcode not supported on this processor: mips1 (mips1) `ll $2,24($3)'
{standard input}:556: Error: opcode not supported on this processor: mips1 (mips1) `sc $2,24($3)'
make[10]: *** [dcache.o] Error 1
make[10]: Leaving directory `/home/davide/openwrt/0.9-patched/whiterussian/openwrt/build_mipsel/linux-2.4-brcm/shfs-0.35/shfs/Linux-2.4'
make[9]: *** [_mod_/home/davide/openwrt/0.9-patched/whiterussian/openwrt/build_mipsel/linux-2.4-brcm/shfs-0.35/shfs/Linux-2.4] Error 2
make[9]: Leaving directory `/home/davide/openwrt/0.9-patched/whiterussian/openwrt/build_mipsel/linux-2.4-brcm/linux-2.4.34.4'
make[8]: *** [all-y] Error 2
make[8]: Leaving directory `/home/davide/openwrt/0.9-patched/whiterussian/openwrt/build_mipsel/linux-2.4-brcm/shfs-0.35/shfs/Linux-2.4'
make[7]: *** [all] Error 2
make[7]: Leaving directory `/home/davide/openwrt/0.9-patched/whiterussian/openwrt/build_mipsel/linux-2.4-brcm/shfs-0.35/shfs'
make[6]: *** [module] Error 2
make[6]: Leaving directory `/home/davide/openwrt/0.9-patched/whiterussian/openwrt/build_mipsel/linux-2.4-brcm/shfs-0.35'
make[5]: *** [/home/davide/openwrt/0.9-patched/whiterussian/openwrt/build_mipsel/linux-2.4-brcm/shfs-0.35/.built] Error 2
make[5]: Leaving directory `/home/davide/openwrt/0.9-patched/whiterussian/openwrt/target/linux/package/shfs'
make[4]: *** [shfs-compile] Error 2
make[4]: Leaving directory `/home/davide/openwrt/0.9-patched/whiterussian/openwrt/target/linux/package'
make[3]: *** [/home/davide/openwrt/0.9-patched/whiterussian/openwrt/build_mipsel/stamp/.linux-compile] Error 2
make[3]: Leaving directory `/home/davide/openwrt/0.9-patched/whiterussian/openwrt/target/linux/linux-2.4'
make[2]: *** [2.4/brcm-compile] Error 2
make[2]: Leaving directory `/home/davide/openwrt/0.9-patched/whiterussian/openwrt/target/linux'
make[1]: *** [linux-compile] Error 2
make[1]: Leaving directory `/home/davide/openwrt/0.9-patched/whiterussian/openwrt/target'
make: *** [target/compile] Error 2

Any ideas?

Davide

(Last edited by davide125 on 7 May 2007, 10:09)

When I try to start nas, i get:

/usr/sbin/nas: can't resolve symbol 'wl_iovar_set'

I also tried with and without the libbcmcrypto.so from the broadcom-wl-4.80.53.0

EDIT: looks like some functions may be missing from wl.c, here is the kamikaze version:

https://dev.openwrt.org/browser/trunk/p … m/src/wl.c

(Last edited by netprince on 7 May 2007, 14:39)

davide125 wrote:

Building from whiterussian SVN + solca patch (3rd revision) kmod-fuse build fails:

...

Any ideas?

Davide

I never test compiling fuse and shfs, will take a look and update the patch.  Thanks.