The problem
It seems that the sources supplied by US Robotics are incomplete. For instance, the file
boardparms.h is missing, and it seems to be an important header to compile the 96345-specific drivers (see below). The .c files below also mention some functions, like
BpSetBoardId, which are found nowhere else (so, some
.c file must be missing as well).
In version 1 :
./arch/mips/brcm-boards/bcm96345/prom.c:38:#include "boardparms.h"
./drivers/char/bcm96345/board/bcm6345_flash.c:34:#include "boardparms.h"
./drivers/char/bcm96345/board/board.c:43:#include "boardparms.h"
In version 2 :
./arch/mips/brcm-boards/generic/prom.c:42:#include "boardparms.h"
./drivers/char/bcmboard/impl1/bcm63xx_flash.c:39:#include "boardparms.h"
./drivers/char/bcmboard/impl1/board.c:48:#include "boardparms.h"
Another strange thing (in the version 1 sources) is that some Makefiles include stuff from outside de kernel tree :
In version 1 :
./arch/mips/brcm-boards/bcm96345/Makefile:EXTRA_CFLAGS += -I$(TOPDIR)/../../targets
./drivers/char/bcm96345/board/Makefile:EXTRA_CFLAGS += -I. -I$(HPATH)/asm/bcm96345 -I$(TOPDIR)/../../targets -fno-exceptions
./Makefile:SUBDIRS +=modulesrc/drivers ../../targets
./Makefile:DRIVERS-y += modulesrc/drivers/kermods.o ../../targets/bp.o
Also note that the
modulesrc directory does not exist ... Which indeed causes problems when compiling.
I'm trying to contact Broadcom and US Robotics about that ; because without those files, it might be impossible to compile a working kernel.
The workaround
Meanwhile, I tried to disable the drivers which lacked important functions to see what could be done. I removed most of the flash driver and some other stuff ; and the kernel can now compile,
BUT I can't be sure that it will boot at all and recognize the hardware correctly. For instance, I had to hard-code the SDRAM size to 16 MB, and some other hacks like that. Now, the problem is the following : my kernel is a "regular" ELF or ECOFF executable, but the CFE loader seems to expect something different :
result of the "file" command
vmlinux: ELF 32-bit MSB MIPS-II executable, MIPS, version 1 (SYSV), statically linked, not stripped
arch/mips/boot/vmlinux.ecoff: MIPSEB ECOFF executable (impure) stripped - version 0.200
any_kernel_extracted_from_firmware_files: 8086 relocatable (Microsoft)
Of course, I suppose that the kernels loaded by CFE aren't actually 8086 relocatable ;-)
I compared the files with
hexdump but found no rssemblance so far.
The new problem
It seems that CFE is expecting something different from "regular" kernel images produced by the regular compilation toolchain. And the kernels loaded by CFE have no visible symbol nor string ; maybe they are compressed and CFE decompresses them. I'll browse CFE documentations to learn more ... (It might by the "SREC" format ; I read something about that earlier when quickly checking CFE, but I don't know at all what it is - yet).
Possible solution?
Netgear ship all the standard broadcom modules precompiled in their firmware for the DG834GS. They have a script which makes a working boot image for that router, making changes to the kernel very easy. This has a 6348 not a 6345 but I believe them to be compatible - [ftp://downloads.netgear.com/files/GPL/DG834GT.V1.01.25_src.tar.bz2]
This includes a broadcom application for building new firmware which looks generic, plus CFE and bootloader and the abovementioned modulesrc directory.
Note that some of these modules are *statically* linked into the linux kernel - something that is still a GPL violation (Modules are OK, static linking is not).