This makes legacy subtarget follow two other.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@45319 3c298f89-4303-0410-b956-a3cf2f4a3e73
KERNEL_IMAGE is used as target rule so reusing the same name causes:
Makefile:326: warning: overriding recipe for target `bin/brcm47xx/vmlinux.lzma'
Makefile:326: warning: ignoring old recipe for target `bin/brcm47xx/vmlinux.lzma'
Makefile:326: warning: overriding recipe for target `build_dir/target-mipsel_74kc+dsp2_uClibc-0.9.33.2/linux-brcm47xx_mips74k/vmlinux.lzma'
Makefile:326: warning: ignoring old recipe for target `build_dir/target-mipsel_74kc+dsp2_uClibc-0.9.33.2/linux-brcm47xx_mips74k/vmlinux.lzma'
Unfortunately this will cause copying vmlinux.lzma over and over like:
cp vmlinux.lzma FOO-kernel.bin
which is redundant on brcm47xx where we never modify kernel image.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@45178 3c298f89-4303-0410-b956-a3cf2f4a3e73
There is a group of devices that lzma-loader doesn't work with. They
simply hang at "Starting program at 0x80001000" which is really hard to
debug and we didn't find any solution for this for years.
Broadcom doesn't use lzma-loader on these devices anyway. They decided
to drop lzma-loader and use less optimal LZMA compression that can be
handled by CFE itself (it doesn't use dictionary).
So support these devices we will need kernel compressed with different
parameters and trx without a loader.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@42205 3c298f89-4303-0410-b956-a3cf2f4a3e73
broadcom-wl now builds in the mips74k profile, so remove these chips
from the generic profile.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@41546 3c298f89-4303-0410-b956-a3cf2f4a3e73
We should be more careful and don't generate 128K JFFS2 images for
devices with flashes using 64K blocks (nor the other way).
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@40762 3c298f89-4303-0410-b956-a3cf2f4a3e73
This patch adds support for Huawei E970 wireless gateway devices.
It has been tested on an E970 labelled as T-Mobile web'n'walk Box IV.
E960/B970 should work too, from what I know it's basically the same hardware.
The device has a Broadcom BCM5354 SoC and a built-in 3G USB modem.
It uses a hardware watchdog which needs GPIO-7 to be toggled at least
every 1-2 seconds. This patch uses gpio_wdt module (see my previous
patch today) to take care of this.
Tested and works: 3G wan, wlan+LED, VLAN config, failsafe using reset
button, image to be used for upgrade from OEM firmware's web interface
Link to the wiki page I've created: <http://wiki.openwrt.org/toh/huawei/e970>
Issue:
* lzma-loader crashes, so gzipped kernel is used. Presumably due to watchdog
reset during kernel decompress.
Signed-off-by: Mathias Adam <m.adam--openwrt@adamis.de>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@38011 3c298f89-4303-0410-b956-a3cf2f4a3e73
In order to support both normal images and initramfs, ensure that each
target sets KERNELNAME properly so that the generic kernel building code
can copy the corresponding files over $(KDIR) with the appropriate
extension. Update the various paths to the kernel and wrapper images
from $(LINUX_DIR)/arch/$(ARCH)/boot/$(foo) to $(KDIR)/$(foo).
Signed-off-by: Florian Fainelli <florian@openwrt.org>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@37049 3c298f89-4303-0410-b956-a3cf2f4a3e73
I recently picked up a WNDR3700 to put OpenWRT on, and only after tearing into the box did I find it
was one of the v3 boards, with poor OpenWRT support. This patch should add the board detection and
LED/button control to the broadcom-diag module, and should generate a netgear .chk image that the
bootloader and stock firmware will accept.
The changes to the broadcom-diag module are more than a few lines because the WNDR3700v3 is driving
its LEDs through an HC164 8-bit shift register.
Signed-off-by: Owen Kirby <osk@exegin.com>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@36482 3c298f89-4303-0410-b956-a3cf2f4a3e73
WNDR3400v2 is based on BCM53xx . Image that is created breaks the router somehow therefore "#".
CFE and NVRAM contain different vars - example:
CFE line original: Device eth0: hwaddr 74-44-01-37-C6-69, ipaddr 192.168.1.1, mask 255.255.255.0
CFE after openwrt: Device eth0: hwaddr 00-FF-FF-FF-FF-FF, ipaddr 192.168.1.1, mask 255.255.255.0
Logs were posted earlier on this mailing list: https://lists.openwrt.org/pipermail/openwrt-devel/2012-July/016174.html
Different logs with factory firmware are in the wiki: http://wiki.openwrt.org/toh/netgear/wndr3400#wndr3400v2
(and on wikidevi for example)
Signed off by: Dirk Neukirchen <dirkneukirchen@web.de>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@35790 3c298f89-4303-0410-b956-a3cf2f4a3e73
This is commented out until we get report of working devices.
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@30639 3c298f89-4303-0410-b956-a3cf2f4a3e73
The image will not boot because serial flash support is missing this is only for experts.
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@27302 3c298f89-4303-0410-b956-a3cf2f4a3e73
2.4 isn't present anymore, so it will always be 2.6 (or newer). Since the
2.6 check will break with 3.0, remove it alltogether.
Signed-off-by: Jonas Gorski <jonas.gorski+openwrt@gmail.com>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@27185 3c298f89-4303-0410-b956-a3cf2f4a3e73
Thank you realopty for the patch.
tools/firmware-utils/src/mkchkimg.c is from http://www.myopenrouter.com/download/10611/mkchkimg/
This closes#7702.
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@22516 3c298f89-4303-0410-b956-a3cf2f4a3e73
CFE does not boot images generated with these checksums because of
wrong checksum.
After flashing then with tftp to my Asus wl500-GPv1 the following messages
are show:
Null Rescue Flag.
Boot program checksum is invalid
Hello!! Enter Rescue Mode: (Check error)
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@22418 3c298f89-4303-0410-b956-a3cf2f4a3e73
* reduce image size for CRC calculation by fs_mark size
sysupgrade sometimes failed for me and I noticed that it was due
to incorrect CRC values in trx-header after performing it.
It seems that the fs_mark was completely included in the calculation
and that it was nevertheless modified by sysupgrade while appending
the jffs data.
This only occurs for the first boot after sysupgrade as the flashmap
driver recalculates the CRC to an even smaller area when it boots.
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@22396 3c298f89-4303-0410-b956-a3cf2f4a3e73
'factory' and 'sysupgrade' did not make much sense. A discussion
with jow convinced me that .trx results in a helpdesk disaster.
So I decided to use '.bin' for normal bin-headers and '.noheader.bin'
for the trx-v2 image.
I fixed the wiki accordingly.
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@22013 3c298f89-4303-0410-b956-a3cf2f4a3e73
Rafał Miłecki
Hauke Mehrtens
Florian Fainelli
Imre Kaloz
Felix Fietkau
Markus Wigge