A while ago I was asked in comments about my OpenWRT IPv6 setup. So I decided to write a small note about it here in my blog. Sorry for missing some of the theory and the details – it’s meant for those who are in a hurry.
It’s been a while since I’ve done something really… EPIC. Like, REALLY EPIC. And that doesn’t sound nice, so I decided to pick another router and make it EPIC.
This time I picked a nice Mercury MW4530R, which is known to be supported by OpenWRT trunk (No bloody Openwrt patching/hacking this time, so no pain in rebasing a patchset on every update), and for 60$ is a deal. So, I got the hardware, and set down to work. Since a few people asked this time I even took the time to record a small video of the whole build. My thanks fly out to Dmitry Zganyaiko for his awesome music.
Okay, that was fun. You see, it happened, that I got for nearly free a Mercury MW150R router. Since it was pretty sucky, I didn’t hope to find anything useful in it, nor I thought it could be the target for OpenWRT. Nevertheless, once I had a spare moment I cracked it open and…
Well, AR9331 describes it all. The same chip you’ll find on WR703N, so it WAS a target for OpenWRT after all. Next I hooked up the UART, and saw the very unpleasant picture. It had only 2 MiBs of spi flash, and 8 MiBs of RAM, barely enough to run VxWorks with a crippled web interface. So it was a nice time for an upgrade:
Okay, I admit it. I screwed up. Bought some ‘edup’ shit to find out the chip was totally unsupported. Well, it caught my attension and I decided to make it supported. Not just because I can’t buy a supported one… It’s just the fun
Inside is… RTL8196C. Some time ago I already completed an awesome quest called “collect all the pacthes and get a somewhat working outdated toolchain” ( in russian, sorry I’m lazy to translate). A look at the BSP is quite enough for my ‘shit-o-meter’ to say “value out of range”. This code causes depression, headache, stomachache and an unconventional desire to kill… make sure you have good nerves, before you open it.
Well, all the trash and fun I found in realtek’s BSP follows. THIS shit is running in production use!
Should anybody from realtek be reading this… Guys… Do a favor… Kill yourself, save the planet!
Okay, lets start with the fun stuff.
[email protected]:/media/NC-OS/pocket_router/linux-2.6.30-veteran/arch/mips/rtl8196b$ ls -la
drwxr-xr-x 2 necromant necromant 4096 2010-12-17 11:48 .
drwxr-xr-x 19 necromant necromant 4096 2010-12-17 11:48 ..
-rw-r--r-- 1 necromant necromant 6268 2010-02-22 05:35 int.c
-rw-r--r-- 1 necromant necromant 236 2010-02-22 05:35 Makefile
-rw-r--r-- 1 necromant necromant 2615 2010-02-22 05:35 mem.c
lrwxrwxrwx 1 necromant necromant 84 2011-08-21 14:14 pci.c -> /home/bo_zhao/8196/linux-2.6.19/linux-2.6.x/arch/mips/realtek/rtl8196b/pci-rtl8196.c
-rw-r--r-- 1 necromant necromant 1996 2010-02-22 05:35 pci.h
-rw-r--r-- 1 necromant necromant 14802 2010-02-22 05:35 pci-rtl8196.c
-rw-r--r-- 1 necromant necromant 1111 2010-02-22 05:35 printf.c
-rw-r--r-- 1 necromant necromant 4383 2010-02-22 05:35 setup.c
-rw-r--r-- 1 necromant necromant 2240 2010-02-22 05:35 timer.c
pci.c symlinks to /home/%codemonkeyname%/…, and since %codemonkeyname% != necromant it wouldn’t get compiled. Luckily that was some old redundant stuff. Just a miracle it worked after all. There’s a plenty of this shit in kernel source.
From the kernel tree, lots of symlinks go outside. Without passing some vars to the hacked kernel Makefiles it wouldn’t compile at all. Only from BSP.
Board-specific init is not in mach-boardname.c, no way, a whole folder called bsp that is sylinked somewhere outside. And there’s little to no board-specific code in there.
MTD layout is hardwired in driver, not board specific and set via kconfig.
leds’n’buttons, just like the whole gpio subsystem is implemented as a char dev, incompatible with just about anything. Web apps are supposed to read and write to that char device. Forget those /sys/class/leds/, led triggers and such shit! Btw, board-specific led defines are in the led driver, not board-specific stuff.
For LexraCore (A veteran MIPS-like CPU, that got damaged by patent trolls and doesn’t have some instructions) there’s a new kernel arch called rlx, mostly copypaste from mips, with lottsa hacks.
Makefiles of the kernel are hacked to get compiled via an archeological gcc 3.4x.
Guys from realtek write in camelCase at kernel level.Crap!
Comments in dmesg are sucky like “IN WIFI INIT!111”. Why caps?
Kernel images are packed using rtkload, some hacked opensource project. It is put in kernel tree, and the Makefile calls ‘cvimg’ util by realtek, that gets compiled along in some ‘goahead’ (the webserver, yeah!?) Rootfs is attached to the image with ‘mgbin’ from the same ass.
Paths longer than about 20 chars cause mgbin & cvimg to crash. Who the heck is gonna do boundary checks, you ****?!?
Baudrate for earlyprintk is defined somewhere in a header totally unrelated to board init somewhere in в arch/rlx/include. It’s just not funny anymore!111
A COOL BONUS.
Extract from their GPIO driver:
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,27) kill_proc(1,SIGTERM,1); #else ...
This soon made it to the top of the russian site called govnokod.ru ( a collection of MOST shitty code from the known universe) =))
Okay. As promissed, usb support arrived. Thanks to Layne Edwards for his dwc_otg patches – everything now works.
Since I have this hardware and I use it, I will be updating a page with firmware builds.
So, meet the first version of it and grab on the ….
- comgt for 3g modems is built-in
- USB host and dwc_otg are compiled in kernel, therefore additional usb kmod packages have to be installed with –force-depends
- Adjusted mtd partition sizes