RTL8196 vs OpenWRT

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.

necromant@ilwyn:/media/NC-OS/pocket_router/linux-2.6.30-veteran/arch/mips/rtl8196b$ ls -la
итого 64
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


Extract from their GPIO driver:


This soon made it to the top of the russian site called govnokod.ru ( a collection of MOST shitty code from the known universe) =))