I like to offer my help about extending the supported devices built around BCM6338 CPU-s, which is the cheaper end of the BCM963xx lineup.
These devices are mainly standalone ADSL2+ modems with 1 ethernet port, or ADSL2+ modems extended with a LAN switch to provide simple routing functionalities. There are a lots of hardware built around this cheap platform from many vendors (like D-Link or TP-Link).
These devices has 2MB flash and 8MB RAM which is kinda low, but they do not support a lot of things (Wifi, SIP, VOIP etc.) so these parts can be left out from an image for this platform.
The main probllem with the original firmwares for these devices are the following:
- There is no JFFS partition, so most of the setting cannot be saved permanently, specially the fine tuned ADSL settings
- Most of the features in this device cannot be accessed via the default configuration pages
- The web interface is not intuitive, part of the supported features are also not workng at all, or not working correctly.
I really like to help in developing a version of Bitswither that support this platform and enhance the capabilities of the otherway great hardware.
Dchard
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Downloaded an older source which has a proper target for 96332CG board, currentyl I'am working on the build environment. It seems that the bcm963xx source tree is not unified in terms of the binary drivers. Every source contains only the binary drivers for the targets intended for, and in the latest source there is no target for 96338 even the board (96332CG) is supported by the source.
It's kinda hard…
coolman: if you please tell me what OS do you use for the build and compiling environment, it would be nice.
Thanks,
Dchard
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Never mind, I have a working build environment for the latest broadcom source which has a target for board id 96332CG, and my first image is just built. Now I flashing the device so wish me luck :-)
PS: My problem was that it is not enough to have a complete toolchain, 'cause for the kernel to compile it want to use the HOSTCC not the one in the toolchain, so I had to find a working gcc-3.4 for the latest ubuntu distro. It was not easy but it is working now.
Dchard
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
CFE version 1.0.37-8.7 for BCM96338 (32bit,SP,BE)
Build Date: Tue Nov 20 17:29:44 CST 2007 (kevin@BS5)
Copyright (C) 2000-2006 Broadcom Corporation.
Boot Address 0xbfc00000
Initializing Arena.
Initializing Devices.
Serial flash device: name S25FL016A, id 0x0114, size 2048KB
100 MB Full-Duplex (auto-neg)
CPU type 0x29010: 240MHz
Total memory: 8388608 bytes (8MB)
Total memory used by CFE: 0x80401000 - 0x805279E0 (1206752)
Initialized Data: 0x8041D0E0 - 0x8041F0D0 (8176)
BSS Area: 0x8041F0D0 - 0x804259E0 (26896)
Local Heap: 0x804259E0 - 0x805259E0 (1048576)
Stack Area: 0x805259E0 - 0x805279E0 (8192)
Text (code) segment: 0x80401000 - 0x8041D0D4 (114900)
Boot area (physical): 0x00528000 - 0x00568000
Relocation Factor: I:00000000 - D:00000000
Board IP address : 192.168.1.1:ffffff00
Host IP address : 192.168.1.100
Gateway IP address :
Run from flash/host (f/h) : f
Default host run file name : vmlinux
Default host flash file name : bcm963xx_fs_kernel
Boot delay (0-9 seconds) : 3
Board Id (0-9) : 96332CG
Number of MAC Addresses (1-32) : 12
Base MAC Address : 00:1e:58:44:9b:67
PSI Size (1-64) KBytes : 24
*** Press any key to stop auto run (3 seconds) ***
Auto run second count down: 0
Code Address: 0x80010000, Entry Address: 0x801a4018
Decompression OK!
Entry at 0x801a4018
Closing network.
Starting program at 0x801a4018
Linux version 2.6.8.1 (root@image) (gcc version 3.4.2) #1 Tue Nov 9 23:13:14 CET 2010
Serial flash device: name S25FL016A, id 0x0114, size 2048KB
96332CG prom init
CPU revision is: 00029010
Determined physical RAM map:
memory: 007a0000 @ 00000000 (usable)
On node 0 totalpages: 1952
DMA zone: 1952 pages, LIFO batch:1
Normal zone: 0 pages, LIFO batch:1
HighMem zone: 0 pages, LIFO batch:1
Built 1 zonelists
Kernel command line: root=31:0 ro noinitrd console=ttyS0,115200
brcm mips: enabling icache and dcache…
Primary instruction cache 16kB, physically tagged, 2-way, linesize 16 bytes.
Primary data cache 8kB 2-way, linesize 16 bytes.
PID hash table entries: 32 (order 5: 256 bytes)
Using 120.000 MHz high precision timer.
Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
Memory: 5844k/7808k available (1408k kernel code, 1944k reserved, 203k data, 68k init, 0k highmem)
KLOB Pool 1 Initialized: 1048576 bytes <0x80600000 … 0x80700000>
Calibrating delay loop… 239.20 BogoMIPS
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Checking for 'wait' instruction… unavailable.
NET: Registered protocol family 16
Total Flash size: 2048K with 32 sectors
File system address: 0xbfc10100
Blk# BlkOff Blks MemLen Partition Name
0 1408 1 1024 NVRAM
30 40960 1 24576 Config 2
31 32768 1 8192 Scratch PAD
31 40960 1 24576 Config 1
Can't analyze prologue code at 8016eb64
Initializing Cryptographic API
PPP generic driver version 2.4.2
NET: Registered protocol family 24
Using noop io scheduler
bcm963xx_mtd driver v1.0
brcmboard: brcm_board_init entry
Serial: BCM63XX driver $Revision: 3.00 $
ttyS0 at MMIO 0xfffe0300 (irq = 10) is a BCM63XX
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 512 bind 1024)
Initializing IPsec netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
Ebtables v2.0 registered
NET: Registered protocol family 8
NET: Registered protocol family 20
VFS: Mounted root (squashfs filesystem) readonly.
Freeing unused kernel memory: 68k freed
Kernel panic: No init found. Try passing init= option to kernel.
<0>Rebooting in 1 seconds..
I don't know why I got this message…
Dchard
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It seems that you have got no init in your filesystem. Please check if you have the file <your_build_tree>/target/963…/fs/sbin/init after you have built an image. In Bitswitcher the kernel gets init=/etc/preinit option on bootup, where preinit is a script which mounts the mini_fo-filesystem and then calls /sbin/init.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I cleaned the source last night, but the compilation is on it's way now.
Till it ends I have to ask something: for a long time I believed that the source for bcm963xx which can be found all around the net is unified and it is possible to make a firmware for every model which built around this platform. So when I started this "project" first I searched for the latest source code I can find, which was bcm963xx_4.02L.03_consumer_release, but after some experimenting I was found out, that because of the binary drivers this is not true. I assume that you can only built a firmware for the part of the lineup that has a nearly identical target in the sourcecode. Forexmaple: if I want to duild a firmware for devices built around 96338 CPU, but I only have targets in the source for 96343 or 96353, than I cannot compile a working image for 6338 from this source due to the differences in the binary drivers.
Am I true?
Dchard
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1. There is only one thing in targets/96332CG/fs/sbin: a symbolic link called "ethctl" which points to ../bin/ethctl
2. There is no "perinit" in targets/96332CG/fs/etc neither.
Also I post the "init releated" parameters which I used during the comiplation:
In bosybox/brcm.config:
#
# Init Utilities
#
CONFIG_INIT=y
CONFIG_FEATURE_USE_INITTAB=y
CONFIG_FEATURE_INITRD=y
# CONFIG_FEATURE_INIT_COREDUMPS is not set
# CONFIG_FEATURE_EXTRA_QUIET is not set
# CONFIG_HALT is not set
# CONFIG_POWEROFF is not set
CONFIG_REBOOT=y
# CONFIG_MESG is not set
From kerlenl/linux/.config:
#
# Kernel hacking
#
CONFIG_CROSSCOMPILE=y
CONFIG_CMDLINE="console=ttyS0,115200"
# CONFIG_DEBUG_KERNEL is not set
CONFIG_BRCM_VMTOOLS=y
# CONFIG_BRCM_IKOS is not set
From kernel/linux/arch/mips/brcm-boards/brcm-963xx/Kconfig
config ROOT_FLASHFS
string "flash partition"
depends on ROOTFS_SQUASHFS || ROOTFS_CRAMFS || ROOTFS_JFFS2
default "root=31:0 ro noinitrd" if ROOTFS_SQUASHFS = y || ROOTFS_CRAMFS = y
default "root=31:0 ro noinitrd" if ROOTFS_JFFS2 = y
help
This is the root file system partition on flash memory
I can post you any file if you need it.
Thanks for the help, and I really hope we can merge the two projects. :-)
Dchard
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I extracted some information from the original firmware the device currently runs:
1. There is plenty of mtd devices, but there is only one cames up when I run "df" or "cat /proc/mtd" commands, and that is /dev/mtdblock0
2. After that point where my image stopped working, in the original fimrware busybox starts to load up, more specially the output is excatly the same, like if I run the "busybox linuxrc" command.
Maybe from these informations collman can sugget me something, forexample how should I modify the rootfs init entry in the kernel before the build.
Dchard
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1. I believed that if a kernel booting with "noinitrd", it means that the kernel will not going to search for initrd outside the kernel. Which is true, but I poorly missed the part, that the actual init part will going to be done anyway, and the kernel - even without an actual init= parameter - will try to search for some default locations to initiate the init process, before it actually dies with "Kernel panic: no init found".
2. And here is the actual problem: the kernel tries to search for init without a success, because the busybox is compiled, but not installed successfully to the target rootfs. I mean that the busybox binary is placed corretly to /bin/busybox in the rootfs, but the symlinks for the various programs the busybox binary contains, are not generated. Actually none of the symlinks for the busybox binary generated at all. First I thought, that these symlinks are generated at runtime and this is why I can't see them in the rootfs, but later I read at bosybox.net, that the symlinks are generated right after the compilation, so I should see them in the rootfs.
So I have to check the master makefile and busybox makefile for errors, because it is clear that I have this init errors because of the missing busybox symlinks.
Dchard
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It seems that I'am right with the init problems, so now I have a working firmware compiled from the broadcom source.
My only problem is that even if I modify the targets/96332CG/96332CG file to compile an Annex B ADSL driver, it continues to produce Annex A ADSL drivers…
coolman: can you help me with this? I see you can produce annex an and annex b firmwares too.
Dchard
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Congratulations for building your first running firmware. Look at our last changelog http://bitswitcher.sourceforge.net/info.html#change. You can see that we updated the DSL-firmware with the latest release but not the driver itself.
Do you use the BS-trunk for your development or do you work with another one? In my opinion we should merge the support for your small devices with the current BS-sources as you mentioned before.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I used the stock source for my developement, not the BS tree, and I aggreed: we should merge it.
I searched through the dlink.ru GPL site and can confirm coolman he got the latest drivers which has both annex a and annex B binaries. On the net there are newver version for annex a, but not for both.
I'am downloading the BS trunk latest development tree at the moment. and going to start to work on this.
I think we have to maijor jobs:
1. Work out a proper target for the board 96332CG
2. Cut most of the features down (even the web gui) to fit on the 2MB flash.
I wan to add some features that BS can actually do what stock firmwares not: to save the ADSL parameters permanent. A very tiny JFFS2 partition can do this.
Dchard
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Finished the DL of the latest development tree, and finished to compile my first firmware with that. It went successful with the default target ( make PROFILE=96348GWV_DT) and the image is a little bit more than a 1MB larger than the available flash on my device family.
First I'am going to work on the proper target for the board and so.
coolman: if you have any idea what to cut out and what to keep, or how to set the exact size of the JFFS2 partition, that would be nice.
Dchard
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I worked out a target for 96332CG board, repaired all the missing file errors during the build, but at the optimization of C runtime libraries, I always get the following errors:
make: Leaving directory `/opt/bitswitch_dev_tree/userapps/opensource/busybox'
make -C /opt/bitswitch_dev_tree/userapps/opensource/libcreduction install
make: Entering directory `/opt/bitswitch_dev_tree/userapps/opensource/libcreduction'
Optimizing C run-time library…
I: Using ld-uClibc.so.0 as dynamic linker.
I: library reduction pass 1
Traceback (most recent call last):
File "./mklibs.py", line 392, in <module>
for lib in regexpfilter(os.listdir(dest_path), "(.*-so-stripped)$").elems():
OSError: No such file or directory: 'uclibc'
make: *** Error 1
make: Leaving directory `/opt/bitswitch_dev_tree/userapps/opensource/libcreduction'
make: *** Error 2
root@image:/opt/bitswitch_dev_tree#
root@image:/opt/bitswitch_dev_tree# uclibc
uclibc: command not found
The toolchain and everything else is intact: i can compile successfully the original target…
Dchard
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I found out that if I comment out "BRCM_APP_PHONE=sip" from the target config, I got that error message above.
With stripping down the kernel, I was able to reduce the image size to 2.587.382 bytes and I didn't even touch the user space applications nor the web interface :-) According to the BCM image generator, I have to cut down 490.230 more bytes to fit on a 2MB flash.
coolman: which is the preferred way to switch off the build and integration of the features located in bs_extra directory? I can hack it out for testing purposes, but if we want to merge the two projects, we must keep it as simple as we can.
Dchard
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
With removing dropbear and dnsmasq, and cutting out less important function from the busybox binary as "less", "nc" "vi" "awk" and others, I was able to get an image which can fit on a 2MB flash. I written the image to the device, and got the following bootlog:
It is clear that it fails due it cannot mount the rootfs, 'cause the board not initialized properly, but the board ID and everything else is fine in the configuration file, in fact I used the exact same parameters I can successfully compile the original broadcom source before…
Dchard
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We control the features which have to built in by setting environment variables in the main Makefile. Have a look on release.sh-Skript, there you can find the actual supported environment variables. I think to support your platform another kernel-config has to be used. Please have a look at dev_tree/kernel/linux/config_ipv4. You have to modify this file and select another Broadcom Board. I think your Board is a 96338 board, so your config should look like this:
CONFIG_MIPS_BRCM=y
CONFIG_BCM96338=y
# CONFIG_BCM96345 is not set
# CONFIG_BCM96348 is not set
This should enable another mtd-layout and your image should hopefully boot up.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The main problem is that the 96332CG part is missing from boardparams.c file, and even if I copy paste it from the original broadcom source, the compiler still not use it. The interesting is that if I cut the 96332CG parts out from the original boardparams.c under the broadcom source, the target not going to compile any more (it fails), but when the 96332CG parts are missing from the boardparams.c under the bitswitch source, the compilation process is done anyway.
The original broadcom source is take the board ID as a parameter from /targets/<target name> -> BRCM_BOARD_ID="" and uses it to search in the boardparams.c to find and match the proper board parameteres. I think the bitswitch source is somehow uses the original 96348GW board ID's matching parameters even if I change the board ID in the config files…. Didn't you made some modifications in this part of the code according to the original?
Dchard
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
From the bcm source i figured out the the BCM96348 series only has CFI flash support, but my board need SPI flash support, which is completely missing from the bitswitcher source along with the support of my flash device.
I really don't know how can I add SPI support for the bitswitcher source. Coolman, if you have any idea, don't hold it back :-)
Dchard
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the mean time I backported the latest annex B adsl driver from the bitswitcher source to the original broadcom source, and it's working now. The connection is stable and jitter-free.
BCM6338 series has CFI and SPI support too, so maybe a it would be more simple to port bitswitcher to the codebase I have. My source is even newer then the source bitswitcher currently using, and as I see, my source is fully supporting BCM96348GW boards.
Coolman: here is the source what I currently using:
I was able to build a proper firmware for 96348GW board and CPU with my source, based on the target and kernel config from the bitswitcher source. Just a little modification was needed in the source.
I seriously think that it would be more simple to use that source over the current bitswitcher source. It would be more simple to add other devices in the future to the supported list.
Dchard
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hey Guys,
I like to offer my help about extending the supported devices built around BCM6338 CPU-s, which is the cheaper end of the BCM963xx lineup.
These devices are mainly standalone ADSL2+ modems with 1 ethernet port, or ADSL2+ modems extended with a LAN switch to provide simple routing functionalities. There are a lots of hardware built around this cheap platform from many vendors (like D-Link or TP-Link).
These devices has 2MB flash and 8MB RAM which is kinda low, but they do not support a lot of things (Wifi, SIP, VOIP etc.) so these parts can be left out from an image for this platform.
The main probllem with the original firmwares for these devices are the following:
- There is no JFFS partition, so most of the setting cannot be saved permanently, specially the fine tuned ADSL settings
- Most of the features in this device cannot be accessed via the default configuration pages
- The web interface is not intuitive, part of the supported features are also not workng at all, or not working correctly.
I really like to help in developing a version of Bitswither that support this platform and enhance the capabilities of the otherway great hardware.
Dchard
Downloaded an older source which has a proper target for 96332CG board, currentyl I'am working on the build environment. It seems that the bcm963xx source tree is not unified in terms of the binary drivers. Every source contains only the binary drivers for the targets intended for, and in the latest source there is no target for 96338 even the board (96332CG) is supported by the source.
It's kinda hard…
coolman: if you please tell me what OS do you use for the build and compiling environment, it would be nice.
Thanks,
Dchard
Never mind, I have a working build environment for the latest broadcom source which has a target for board id 96332CG, and my first image is just built. Now I flashing the device so wish me luck :-)
PS: My problem was that it is not enough to have a complete toolchain, 'cause for the kernel to compile it want to use the HOSTCC not the one in the toolchain, so I had to find a working gcc-3.4 for the latest ubuntu distro. It was not easy but it is working now.
Dchard
I have a half successful boot:
CFE version 1.0.37-8.7 for BCM96338 (32bit,SP,BE)
Build Date: Tue Nov 20 17:29:44 CST 2007 (kevin@BS5)
Copyright (C) 2000-2006 Broadcom Corporation.
Boot Address 0xbfc00000
Initializing Arena.
Initializing Devices.
Serial flash device: name S25FL016A, id 0x0114, size 2048KB
100 MB Full-Duplex (auto-neg)
CPU type 0x29010: 240MHz
Total memory: 8388608 bytes (8MB)
Total memory used by CFE: 0x80401000 - 0x805279E0 (1206752)
Initialized Data: 0x8041D0E0 - 0x8041F0D0 (8176)
BSS Area: 0x8041F0D0 - 0x804259E0 (26896)
Local Heap: 0x804259E0 - 0x805259E0 (1048576)
Stack Area: 0x805259E0 - 0x805279E0 (8192)
Text (code) segment: 0x80401000 - 0x8041D0D4 (114900)
Boot area (physical): 0x00528000 - 0x00568000
Relocation Factor: I:00000000 - D:00000000
Board IP address : 192.168.1.1:ffffff00
Host IP address : 192.168.1.100
Gateway IP address :
Run from flash/host (f/h) : f
Default host run file name : vmlinux
Default host flash file name : bcm963xx_fs_kernel
Boot delay (0-9 seconds) : 3
Board Id (0-9) : 96332CG
Number of MAC Addresses (1-32) : 12
Base MAC Address : 00:1e:58:44:9b:67
PSI Size (1-64) KBytes : 24
*** Press any key to stop auto run (3 seconds) ***
Auto run second count down: 0
Code Address: 0x80010000, Entry Address: 0x801a4018
Decompression OK!
Entry at 0x801a4018
Closing network.
Starting program at 0x801a4018
Linux version 2.6.8.1 (root@image) (gcc version 3.4.2) #1 Tue Nov 9 23:13:14 CET 2010
Serial flash device: name S25FL016A, id 0x0114, size 2048KB
96332CG prom init
CPU revision is: 00029010
Determined physical RAM map:
memory: 007a0000 @ 00000000 (usable)
On node 0 totalpages: 1952
DMA zone: 1952 pages, LIFO batch:1
Normal zone: 0 pages, LIFO batch:1
HighMem zone: 0 pages, LIFO batch:1
Built 1 zonelists
Kernel command line: root=31:0 ro noinitrd console=ttyS0,115200
brcm mips: enabling icache and dcache…
Primary instruction cache 16kB, physically tagged, 2-way, linesize 16 bytes.
Primary data cache 8kB 2-way, linesize 16 bytes.
PID hash table entries: 32 (order 5: 256 bytes)
Using 120.000 MHz high precision timer.
Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
Memory: 5844k/7808k available (1408k kernel code, 1944k reserved, 203k data, 68k init, 0k highmem)
KLOB Pool 1 Initialized: 1048576 bytes <0x80600000 … 0x80700000>
Calibrating delay loop… 239.20 BogoMIPS
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Checking for 'wait' instruction… unavailable.
NET: Registered protocol family 16
Total Flash size: 2048K with 32 sectors
File system address: 0xbfc10100
Blk# BlkOff Blks MemLen Partition Name
0 1408 1 1024 NVRAM
30 40960 1 24576 Config 2
31 32768 1 8192 Scratch PAD
31 40960 1 24576 Config 1
Can't analyze prologue code at 8016eb64
Initializing Cryptographic API
PPP generic driver version 2.4.2
NET: Registered protocol family 24
Using noop io scheduler
bcm963xx_mtd driver v1.0
brcmboard: brcm_board_init entry
Serial: BCM63XX driver $Revision: 3.00 $
ttyS0 at MMIO 0xfffe0300 (irq = 10) is a BCM63XX
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 512 bind 1024)
Initializing IPsec netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
Ebtables v2.0 registered
NET: Registered protocol family 8
NET: Registered protocol family 20
VFS: Mounted root (squashfs filesystem) readonly.
Freeing unused kernel memory: 68k freed
Kernel panic: No init found. Try passing init= option to kernel.
<0>Rebooting in 1 seconds..
I don't know why I got this message…
Dchard
It seems that you have got no init in your filesystem. Please check if you have the file <your_build_tree>/target/963…/fs/sbin/init after you have built an image. In Bitswitcher the kernel gets init=/etc/preinit option on bootup, where preinit is a script which mounts the mini_fo-filesystem and then calls /sbin/init.
I cleaned the source last night, but the compilation is on it's way now.
Till it ends I have to ask something: for a long time I believed that the source for bcm963xx which can be found all around the net is unified and it is possible to make a firmware for every model which built around this platform. So when I started this "project" first I searched for the latest source code I can find, which was bcm963xx_4.02L.03_consumer_release, but after some experimenting I was found out, that because of the binary drivers this is not true. I assume that you can only built a firmware for the part of the lineup that has a nearly identical target in the sourcecode. Forexmaple: if I want to duild a firmware for devices built around 96338 CPU, but I only have targets in the source for 96343 or 96353, than I cannot compile a working image for 6338 from this source due to the differences in the binary drivers.
Am I true?
Dchard
I checked what you asked for:
1. There is only one thing in targets/96332CG/fs/sbin: a symbolic link called "ethctl" which points to ../bin/ethctl
2. There is no "perinit" in targets/96332CG/fs/etc neither.
Also I post the "init releated" parameters which I used during the comiplation:
In bosybox/brcm.config:
From kerlenl/linux/.config:
From kernel/linux/arch/mips/brcm-boards/brcm-963xx/Kconfig
I can post you any file if you need it.
Thanks for the help, and I really hope we can merge the two projects. :-)
Dchard
I extracted some information from the original firmware the device currently runs:
1. There is plenty of mtd devices, but there is only one cames up when I run "df" or "cat /proc/mtd" commands, and that is /dev/mtdblock0
2. After that point where my image stopped working, in the original fimrware busybox starts to load up, more specially the output is excatly the same, like if I run the "busybox linuxrc" command.
Maybe from these informations collman can sugget me something, forexample how should I modify the rootfs init entry in the kernel before the build.
Dchard
Here is some commandline output from the original firmware:
Dchard
And a full bootlog with the original firmware:
Dchard
If I run "busybox linuxrc" the output is almost identical to the output I got when I start the original firmware:
Dchard
I think I found out what should be the problem:
1. I believed that if a kernel booting with "noinitrd", it means that the kernel will not going to search for initrd outside the kernel. Which is true, but I poorly missed the part, that the actual init part will going to be done anyway, and the kernel - even without an actual init= parameter - will try to search for some default locations to initiate the init process, before it actually dies with "Kernel panic: no init found".
2. And here is the actual problem: the kernel tries to search for init without a success, because the busybox is compiled, but not installed successfully to the target rootfs. I mean that the busybox binary is placed corretly to /bin/busybox in the rootfs, but the symlinks for the various programs the busybox binary contains, are not generated. Actually none of the symlinks for the busybox binary generated at all. First I thought, that these symlinks are generated at runtime and this is why I can't see them in the rootfs, but later I read at bosybox.net, that the symlinks are generated right after the compilation, so I should see them in the rootfs.
So I have to check the master makefile and busybox makefile for errors, because it is clear that I have this init errors because of the missing busybox symlinks.
Dchard
It seems that I'am right with the init problems, so now I have a working firmware compiled from the broadcom source.
My only problem is that even if I modify the targets/96332CG/96332CG file to compile an Annex B ADSL driver, it continues to produce Annex A ADSL drivers…
coolman: can you help me with this? I see you can produce annex an and annex b firmwares too.
Dchard
It seems I achieved my first sync with the firmware compiled myself :-)))
I used the annex b binary driver found in the 0.3.7 bitswticher source.
These drivers are very old, we have to find newer ones. I start to search tomorrow at the russian d-link page.
Dchard
Congratulations for building your first running firmware. Look at our last changelog http://bitswitcher.sourceforge.net/info.html#change. You can see that we updated the DSL-firmware with the latest release but not the driver itself.
Do you use the BS-trunk for your development or do you work with another one? In my opinion we should merge the support for your small devices with the current BS-sources as you mentioned before.
I used the stock source for my developement, not the BS tree, and I aggreed: we should merge it.
I searched through the dlink.ru GPL site and can confirm coolman he got the latest drivers which has both annex a and annex B binaries. On the net there are newver version for annex a, but not for both.
I'am downloading the BS trunk latest development tree at the moment. and going to start to work on this.
I think we have to maijor jobs:
1. Work out a proper target for the board 96332CG
2. Cut most of the features down (even the web gui) to fit on the 2MB flash.
I wan to add some features that BS can actually do what stock firmwares not: to save the ADSL parameters permanent. A very tiny JFFS2 partition can do this.
Dchard
Finished the DL of the latest development tree, and finished to compile my first firmware with that. It went successful with the default target ( make PROFILE=96348GWV_DT) and the image is a little bit more than a 1MB larger than the available flash on my device family.
First I'am going to work on the proper target for the board and so.
coolman: if you have any idea what to cut out and what to keep, or how to set the exact size of the JFFS2 partition, that would be nice.
Dchard
I worked out a target for 96332CG board, repaired all the missing file errors during the build, but at the optimization of C runtime libraries, I always get the following errors:
make: Leaving directory `/opt/bitswitch_dev_tree/userapps/opensource/busybox'
make -C /opt/bitswitch_dev_tree/userapps/opensource/libcreduction install
make: Entering directory `/opt/bitswitch_dev_tree/userapps/opensource/libcreduction'
Optimizing C run-time library…
I: Using ld-uClibc.so.0 as dynamic linker.
I: library reduction pass 1
Traceback (most recent call last):
File "./mklibs.py", line 392, in <module>
for lib in regexpfilter(os.listdir(dest_path), "(.*-so-stripped)$").elems():
OSError: No such file or directory: 'uclibc'
make: *** Error 1
make: Leaving directory `/opt/bitswitch_dev_tree/userapps/opensource/libcreduction'
make: *** Error 2
root@image:/opt/bitswitch_dev_tree#
root@image:/opt/bitswitch_dev_tree# uclibc
uclibc: command not found
The toolchain and everything else is intact: i can compile successfully the original target…
Dchard
I found out that if I comment out "BRCM_APP_PHONE=sip" from the target config, I got that error message above.
With stripping down the kernel, I was able to reduce the image size to 2.587.382 bytes and I didn't even touch the user space applications nor the web interface :-) According to the BCM image generator, I have to cut down 490.230 more bytes to fit on a 2MB flash.
coolman: which is the preferred way to switch off the build and integration of the features located in bs_extra directory? I can hack it out for testing purposes, but if we want to merge the two projects, we must keep it as simple as we can.
Dchard
With removing dropbear and dnsmasq, and cutting out less important function from the busybox binary as "less", "nc" "vi" "awk" and others, I was able to get an image which can fit on a 2MB flash. I written the image to the device, and got the following bootlog:
It is clear that it fails due it cannot mount the rootfs, 'cause the board not initialized properly, but the board ID and everything else is fine in the configuration file, in fact I used the exact same parameters I can successfully compile the original broadcom source before…
Dchard
We control the features which have to built in by setting environment variables in the main Makefile. Have a look on release.sh-Skript, there you can find the actual supported environment variables. I think to support your platform another kernel-config has to be used. Please have a look at dev_tree/kernel/linux/config_ipv4. You have to modify this file and select another Broadcom Board. I think your Board is a 96338 board, so your config should look like this:
This should enable another mtd-layout and your image should hopefully boot up.
The Board ID is 96332CG and the CPU ID is 6338.
The main problem is that the 96332CG part is missing from boardparams.c file, and even if I copy paste it from the original broadcom source, the compiler still not use it. The interesting is that if I cut the 96332CG parts out from the original boardparams.c under the broadcom source, the target not going to compile any more (it fails), but when the 96332CG parts are missing from the boardparams.c under the bitswitch source, the compilation process is done anyway.
The original broadcom source is take the board ID as a parameter from /targets/<target name> -> BRCM_BOARD_ID="" and uses it to search in the boardparams.c to find and match the proper board parameteres. I think the bitswitch source is somehow uses the original 96348GW board ID's matching parameters even if I change the board ID in the config files…. Didn't you made some modifications in this part of the code according to the original?
Dchard
Located the problem again:
From the bcm source i figured out the the BCM96348 series only has CFI flash support, but my board need SPI flash support, which is completely missing from the bitswitcher source along with the support of my flash device.
I really don't know how can I add SPI support for the bitswitcher source. Coolman, if you have any idea, don't hold it back :-)
Dchard
In the mean time I backported the latest annex B adsl driver from the bitswitcher source to the original broadcom source, and it's working now. The connection is stable and jitter-free.
BCM6338 series has CFI and SPI support too, so maybe a it would be more simple to port bitswitcher to the codebase I have. My source is even newer then the source bitswitcher currently using, and as I see, my source is fully supporting BCM96348GW boards.
Coolman: here is the source what I currently using:
ftp://ftp.dlink.ru/pub/ADSL/GPL_source_code/DSL-2500U_BRU_C/
Take a look.
Dchard
I was able to build a proper firmware for 96348GW board and CPU with my source, based on the target and kernel config from the bitswitcher source. Just a little modification was needed in the source.
I seriously think that it would be more simple to use that source over the current bitswitcher source. It would be more simple to add other devices in the future to the supported list.
Dchard