Slashdot Mirror


Linux Hacked Onto Fry's Cheap Wireless G Router

nerdyH points to this smile-inducing story at LinuxDevices which begins "An inexpensive house-brand 802.11b/g wireless router from Fry's (Outpost.com) has been adopted by a group of Linux hackers that aims to make Fry's 'AirLink' devices 'as capable as name-brand gadgets.' The AirLink101 AR315W is based on a Marvell board that can run Linux or eCos, and has a six-port 10/100 Ethernet switch built in. It's listed for $45 online, but is reportedly on sale for $20 in some Fry's stores."

1 of 153 comments (clear)

  1. Good for them! by Saint+Aardvark · · Score: 5, Interesting
    Congratulations to these guys -- this is very cool. As TFA sez, a $20 embedded Linux box is Just A Good Thing; the flexibility that'll come with getting Linux (or NetBSD or whatever) working on these things will be amazing. I'm also glad to see that these guys are active -- the HRI people, who have a very similar project, seem to have fallen off the face of the earth. (Where are you guys?)

    I've been working on something similar: last Christmas, I picked up 3 Network Everywhere NWR04B wireless routers on sale -- $18 each! -- and have been trying ever since to duplicate this guy's success in getting uClinux (a version of Linux for CPUs with no MMU) running on the thing.

    The guy who got it running originally hasn't responded to my emails, so it's a good thing he made his kernel tree available. Alsoplus, I think he used a JTAG adapter to load the image; since I wanted to make a firmware image that anyone could upload with the web interface, I had to reverse engineer the firmware checksum too. (Luckily it was a pretty simple checksum, or else I don't think I would've been able to do it...I'm really learning all this as I go along.)

    In July I finally managed to get a kernel panic, am now trying to get BusyBox working on the thing. I keep getting these errors:

    Unhandled fault: external abort on linefetch (D4) at 0x00000001
    fault-common.c(97): start_code=0x740040, start_stack=0x71ffbc)

    which, from what I have been able to Google, may be because of differing opinions (libc/uClibc vs. the kernel vs. the chip) about whether or not this thing has an FPU. If anyone's got any suggestions, please leave a note -- I need all the help I can get.

    It's been an incredible learning experience -- I know more now about how the kernel interacts with CPUs, the filesystems, compilers and the bootloader than I ever had. (Still got tons to learn, mind you.) I'm looking forward to the day I can get a Beowulf cluster of these things going. :-)