This allows more feature complete images. Of course it affect the size,
e.g. enabling b43 bumped rootfs from 1569618 to 2029122 for me.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Thanks to leaving .pattern file we can easily insert extra step between
linksys-pattern-partition and trx-v2-with-loader, e.g. rootfs one.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Linksys WRT300N V1 has pretty bugged CFE bootloader (it crashes in a lot
of situations) that doesn't accept .bin image.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Apart from using our new building system there are 2 more changes:
1) Limit amount of images
So far we were generating all standard images (optimized one and two
with no loader) for every SUBTARGET. This is not needed, as e.g. the
only device requiring gzipped kernel is legacy Huawei E970.
2) Change output names
The new image building system requires specifying device name. This
forced picking some and resulted in:
openwrt-brcm47xx-$(SUBTARGET)-squashfs.trx
openwrt-brcm47xx-$(SUBTARGET)-squashfs-gz.trx
openwrt-brcm47xx-$(SUBTARGET)-squashfs-noloader-nodictionary.trx
becoming:
openwrt-brcm47xx-$(SUBTARGET)-standard-squashfs.trx
openwrt-brcm47xx-$(SUBTARGET)-standard-noloader-gz-squashfs.trx
openwrt-brcm47xx-$(SUBTARGET)-standard-noloader-nodictionarylzma-squashfs.trx
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
SVN-Revision: 49006
This only drops WGR614 V9 which has 2 MiB flash and it's unlikely to get
any interest.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
SVN-Revision: 48975
the trx utile uses a maximum image size of 7.2MB. There are brcm47xx
devices even with serial flash with bigger flash chips, but OpenWrt was
not able to create images for these devices. This patch provides an
additional parameter which increases this limit to 32 MB. There is a
warning in the trx utile code which suggests that bigger images could
overwrite the nvram partition on some devices, but normally the program
writing the image should make sure that it is safe to write it to the
flash.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
SVN-Revision: 46872
This patch changes nothing on the behaviour, it just breaks long lines
with bin/trx to make it easier to add additional parameters.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
SVN-Revision: 46871
Instead of letting each target define it themselves, create on in
include/image.mk and let the targets use it.
Signed-off-by: Jonas Gorski <jogo@openwrt.org>
SVN-Revision: 46596
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>
SVN-Revision: 45178
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>
SVN-Revision: 42205
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>
SVN-Revision: 41546
This allows creating more subtargets and optimize builds per family.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
SVN-Revision: 41024
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>
SVN-Revision: 40762
