darkness

I did this with GPL-4-00-03.tgz. This are just the steps I took. You should read the whole thing to see if I was successful or if I destroyed my router. I do not recommend you use these steps! Proceed at your own risk! I am not liable for any damages to your router, your PC, your mind, the space-time fabric surrounding your residence or place of work, or anything else you can think of!

Unpacked the Belkin firmware tarball. cd GPL-4/src/linux; tar -jcf belkin-kernel-headers.tar.bz2 linux/include. This is your kernel header tarball, used in making the toolchain.

Also, before we get too far, let me plug ccache again. I’ve screwed this up a few times and had to rebuild everything. ccache has saved a lot of time. The uClibc toolchain building stuff will automatically build ccache and set up the default compiler(s) in bin to use it.

Checked out http://www.uclibc.org/cgi-bin/cvsweb/toolchain/gcc-3.3.x/. Edited the make/uclibc.mk file to use the snapshot instead of the latest release (0.9.26, which the same file warns against using). Edited make/kernel-headers.mk, changed VERSION, PATCHLEVEL, and SUBLEVEL to match what’s in the Belkin firmware’s kernel sources; also changed LINUX_SOURCE to the tarball of kernel headers we created above from the Belkin kernel sources. Edited make/gcc-uclibc-3.3.mk and changed references to things like $(STAGING_DIR)/usr/lib/gcc-lib/$(REAL_GNU_TARGET_NAME)/$(GCC_VERSION)/specs to elide the /usr portion of that path; I think there are four of these changes. (Sorry if that’s vague; you can try building and you’ll get the staging dir specs file is missing, then poke around a bit and find out where the staging files really are.) mkdir -p sources/dl and copy the belkin-kernel-headers.tar.bz2 file into sources/dl. One more note: I think I disabled C++ somewhere. Generally poke through the top level Makefile for settings you might want to change. Build the toolchain with make. It ended up in /home/darkness/tmp/toolchain/gcc-3.3.x/toolchain_mipsel_nofpu.

cd GPL-4/src and edited the definition for PATH in Makefile to include the toolchain (as above). ln -s router router_belkin. Edited router/Makefile to change export CROSS_COMPILE := mipsel-uclibc- to mipsel-linux-uclibc- since that’s what the uClibc toolchain scripts built. Back in the src directory, I cp linux/linux/{default_belkin,.config} in hopes of using the default_belkin kernel configuration. Copy libc.a from the mipsel cross toolchain you built into router/lib/mipsel/. Now, make belkin. I got an error like:

mipsel-linux-uclibc-gcc -D_linux_=1 -DHAVE_PATHS_H -DHAVE_MMAP 
-I. -I../pppd -O2 -pipe -Wall -I/home/darkness/tmp/GPL-4/src/include 
-DCHAP_SUPPORT=1 -DCHAPMS=1 -DUSE_CRYPT=1 -DHAVE_CRYPT_H=1 
-c -o pppoe.o pppoe.c
pppoe.c:136:28: missing terminating " character
pppoe.c:137:52: missing terminating " character

I find a string broken across two lines in router/ppp/pppoecd/pppoe.c. Join the two lines and restart make belkin. Then I get another error in router/vlan/vconfig.c of the same nature. Find something like http://lists.gnu.org/archive/html/lilypond-user/2003-07/msg00189.html and decide that multi-line literals are gone. Also see http://gcc.gnu.org/ml/gcc/2002-04/msg00546.html which tells us to stick n at the end of the lines inside the string. So I do this and restart make belkin again.

When it gets to the kernel compile you’ll probably get something like cc1: error: invalid option `cpu=r4600'. Reading http://sources.redhat.com/ml/crossgcc/2004-01/msg00210.html we get the impression that -mcpu is no longer valid. So we need to find the section for CONFIG_CPU_MIPS32 in arch/mips/Makefile and remove -mcpu=r4600 from GCCFLAGS. Time for make belkin again. Later you’ll have this same problem with pmon, so make roughly the same change in pmon/GNUmakefile.

You might get an error like /home/darkness/tmp/GPL-4/src/include/bcmnvram.h:21:1: "INLINE" redefined. I chose to comment out the INLINE definition in this file. I also got a few errors like /home/darkness/tmp/GPL-4/src/cfe/cfe/arch/mips/common/src/disasm.c:1791: warning: integer constant is too large for "long" type. For this I went and found the offending constant and jammed ULL (unsigned long long… I hope) on the end. This shut up gcc with -Werror.

Got a few more errors on lines that look like (uint32)sbr &= ~(1 which I changed to sbr = (uint32*) (((uint32)sbr) & ~(1 , these both in shared/sbutils.c. In shared/bcmutils.c I got a bitch about line 635, *tptr = *((ulong *)pdata)++, as warning: use of cast expressions as lvalues is deprecated. I changed this to:

ulong *pdata_ulong = (ulong*)pdata;
*tptr = *pdata_ulong++;

At this point, I am wondering if I really want to use the firmware that will result from this process.

In cfe/cfe/lib/lib_qsort.c I hit the same error. I changed the whole offending section to look like:

    for (i = sizeof(int); i 

I think this makes it more readable, anyway.


In cfe/cfe/include/cfe_bootblock.h look for the constants around
BOOT_MAGIC_NUMBER and slap ULL at the end again.  Lather,
rinse, repeat with warnings in cfe/cfe/ui/ui_examcmds.c.  At this
point I am once again tempted to remove -Werror from compile
flags.


For fun, here's a patch between the original Belkin sources and my
modified
tree.


... Dear god, there are now what I believe to be firmware images built
in GPL-4/image/belkin.  I've tried to flash it to my router,
though, and the web interface won't accept it.  Nor will it accept the
two firmwares linked on the seattlewireless.net F5D7230-4 page.  This
is the v1444 hardware, which may suck.  I also wonder if newer
firmwares keep you from flashing homegrown firmware.


What I'll be doing now is making a toolchain from the Linksys WRT54G
firmware, then trying to build the Belkin firmware with that.  I'm
currently rebuilding the toolchain in the WRT54G firmware with the
Belkin kernel headers.  This is apparently important, since PPPoE is
included by default in the Belkin firmware.  I'm also installing the
tools where they default to, in /opt/brcm.

IBM was scary fast with repairing the broken ATI video in my T40. I called it in on Saturday or Sunday, they shipped an empty box to me on Tuesday, I shipped it back to them on Wednesday. They then received it, fixed it, and shipped it back out all on Thursday, and I had my laptop by Friday (today). They replaced my mainboard, in the process upgrading my video card from a Radeon 7500 to (I think) a Radeon 9000. Very nice. The only thing they didn’t fix is the 3mm scratch on my display, which I don’t really care about most of the time (LCD not under warranty).

So now I’m reinstalling FC2 from scratch. Install went fine, and now that I have a fixed video card graphical boot works fine. First thing I do is disable UTF-8 in /etc/sysconfig/i18n as usual. I also turn off sub-pixel hinting which doesn’t look right on my LCD. To do this, edit /etc/fonts/local.conf to look like mine. You may need to service xfs restart; I did it preemptively, and then I restarted X.

Now copy in my yum.conf pointing to my favorite mirror, as well as my /etc/yum.conf.install which has a whole bunch of repositories, and which I only use (with yum -c /etc/yum.conf.install) for installing/updating packages. yum -y update and all the rest of the usual stuff. No Sawfish by default, so I installed that.

Installed my slmodem package (see an entry or two ago on it) and ipw2100 from ATrpms. Installed tpb from fedora.us (I think).

I was going to use ACPI, which seemed to kind of work (echo 3 > /proc/acpi/sleep tried to do something, but you have to remove the USB modules before it’ll go to sleep; I think acpid can be made to do this). I had heard that, though in S3 (which I think is suspend to ram) it used more battery than suspend under APM, the C3 processor mode greatly increased running time on the battery. ACPI on my T40, however, doesn’t seem to support what’s called “S4bios” by the kernel. This is a variant on the S4 (a.k.a. hibernate, suspend to disk) mode where the BIOS handles suspending to disk. There are two software suspend implementations in the 2.6 kernel called “pmdisk” and “swsusp.” (There’s a third “swsusp2″ which isn’t included in the kernel yet AFAIK). However, both of these are disabled in the FC2 kernel. See the RFE bug for ACPI software suspend in RH Bugzilla, I guess. Due to the lack of these, I boot with acpi=off. APM works fine for my needs. I note that I have done a hibernate/resume several times now and it has worked every time. I should try lid close, which never worked before.

An explanation of my Bluetooth setup. My T40 doesn’t have Bluetooth built in. I just got a Motorola v710 which does have Bluetooth. My provider is Verizon. I went out to CompUSA and bought a store brand USB Bluetooth dongle which turned out to have a CSR chipset that was supported in FC2. My suggestion is to install every package beginning with bluez pretty much, since I don’t know exactly what does what and what’s really needed yet. I suspect bluez-utils, bluez-hcidump, and bluez-pin are particularly important. I also installed the gnome-bluetooth package which doesn’t do all that much, but is still useful. After installing all this stuff, you should be able to service bluetooth start before you connect your Bluetooth USB dongle. (I recommend chkconfig bluetooth on too, since everything seems to work fine with connect/disconnect of the USB dongle, and the service starts fine with the dongle disconnected; i.e., safe to boot with.)

Next I ran gnome-bluetooth-config (I think) as root. I then opened my v710 and hit the “Find Me” under Bluetooth Link->Setup (IIRC). It told me it was discoverable for 60 seconds. I hit the “Scan” (or was it “Search”) button in gnome-bluetooth-config, waited a bit, and it popped up a window asking me for a PIN for my phone. At the same time, my v710 popped up a message asking if I wanted to bond with my laptop. I said yes and the phone then asked for a PIN. I made up a PIN and hit “OK.” Then I typed that same PIN into gnome-bluetooth-config and hit “OK.” Now my phone showed up in gnome-bluetooth-config and my phone said it had successfully paired.

Next I edited /etc/bluetooth/rfcomm.conf and put in something like this at the bottom:

rfcomm0 {
	bind yes;
	device 00:11:22:33:44:55;
	channel 8;
	comment "v710";
}

Note that the channel 8 bit was determined by some command which basically asked for a verbose display of the features of the profiles (?) of the phone and the channels associated with them. Unfortunately, I’ve forgotten this command. I suspect channel 8 is correct for at least Verizon’s v710, but with other phones I think it might well be different. I suspect you can find the command to discover this information from your phone/other device by digging with Google or maybe in Bluez (and specifically rfcomm) documentation.

I think next I did a service bluetooth start but I think a rfcomm bind 0 would work too. Then I was able to fire up Minicom, point it at /dev/ttyUB0, and issue AT commands and the like.

Now, I have this weird unlimited access plan with Verizon that was carried over from Bell Atlantic Mobile when they merged. Verizon hasn’t decided to kick me off this plan yet and I haven’t really been eager to leave it. This plan has the side-effect that sometimes people don’t let me do things other customers can. For example, apparently their systems won’t let me add picture messaging into my account. Also, I apparently can’t get Mobile Web 2.0. One important feature I want for data access is called National Access (maybe there’s not a space in there) by the tech that added it for me at the Verizon corporate store. This feature is sometimes also called NA MOU, 1xRTT, or 1XPP1 (the feature code it is/was supposedly given in Verizon computers). This is the 130kbps service or something like that. You generally need this feature for picture messaging, probably Mobile Web 2.0, and possibly Get It Now (or at least it helps since it makes things faster). Over the phone they said they couldn’t add this feature for me; it isn’t usually something people request, except when they want Internet access at which point Verizon wants you to buy a National Access plan where you pay them more money. I went to the store and complained that my picture messaging wasn’t working (it wasn’t) and the really, really awesome tech added NA to my account for me.

Once I had that on my account, I ran system-network-config to configure a dial-up connection. I set up a modem with the max baud rate on /dev/ttyUB0. Then I set up a new connection. This part is Verizon specific! More specifically, it’s for National Access, the 1xRTT (faster) data service. If you want the old, slower data service, read the next paragraph. I set the phone number to just #777. This is the magic Verizon Internet service number. Set your user name to NNNNNNNNNN@vzw3g.com where NNNNNNNNNN is your mobile phone’s area code and phone number. Set your password to vzw. Previously I had set my modem init string to AT$QCMDR=3, but I have also left this out and everything continued to work. You can accept the defaults on everything else, and voila: you’re done. Just bring the connection up. It should automatically find your phone (assuming it’s in range and Bluetooth is on, all that good stuff), dial out, and get an IP from Verizon. I was seeing anywhere from 600ms to 2000ms latency, which still isn’t super usable. I may have seen as low as 400ms before, which is getting there.

The older, 14.4kbps data access which I called CDPD and Verizon calls Quick Net Connect (QNC, but maybe Quick 2 Net — Q2N — as well; memory… fuzzy…) is still available. I had to use it before I got NA on my account. Instructions are the same as above with the following exceptions: set the baud rate to 19200, user name to qnc, password to qnc, and if you used an init string for NA try changing it to AT$QCMDR=2 for QNC.

Keywords: fedora core 2, bluetooth, v710, fc2, t40, install

Using the directions described on this IBM on the T40 page I was able to get my modem working, and I indeed have an untainted kernel on my T40 still. I’ve made a package for slmodemd in FC2 using ALSA that should make it as easy as service slmodemd start and such. SRPM also in that directory.

Keywords: IBM Thinkpad T40 Fedora Core 2 Winmodem modem slmodem