It's a device based on BCM5365P (0x5365 package 0x00). This SoC has
USB 1.1 controller but device has two USB 2.0 parts. They are handled by
PCI-based controllers: 1106:3038 UHCI and 1106:3104 EHCI.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
The target name does not need to included a revision
if all revisions are supported.
This target supports all revisions (v1, v2, v2.1).
Signed-off-by: Moritz Warning <moritzwarning@web.de>
[Keep the version numbers in the device title, it doesn't harm]
Signed-off-by: Mathias Kresin <dev@kresin.me>
By default we are reusing the stack provided by CFE, like it is intended
by CFE. On my WRT54GS it is located at 0x8043BF30, so a big kernel image
could overwrite it. Relocate it to a different memory region which is
still under the 8MB RAM, but in the higher area. We only need this
memory region for the stack of the loader, Linux will set up this
for its own.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The boot process on a WRT54GL works the following way:
1. CFE gets loaded by the boot rom from flash
2. CFE loads the loader from the flash and gzip uncompresses it
3. CFE starts the loader
4. The loader stores the FW arguments and relocates itself to
BZ_TEXT_START (now 0x80600000)
5. The loader reads the Linux image from flash
6. The loader lzma decompresses the Linux image to LOADADDR (0x80001000)
7. The loader executes the uncompress Linux image at LOADADDR
The BZ_TEXT_START was set to 0x80400000 before. When the kernel gets
uncompressed and is bigger than BZ_TEXT_START - LOADADDR it overwrote
the loader which was currently uncompressing it and made the board
crash. Increase the BZ_TEXT_START my 2 MB to have more space for the
kernel. Even on 16MB RAM devices the memory goes till 0x80FFFFFF so this
should not be a problem.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
BCM4704 SoC has only USB 1.1 core:
ssb: Core 3 found: USB 1.1 Hostdev (cc 0x808, rev 0x03, vendor 0x4243)
but this device actually comes with two USB 2.0 ports.
It appears embedded controller isn't used but instead there are two PCI
attached controllers (next to the BCM4321 wireless card):
1106:3038 VT82xx/62xx UHCI USB 1.1 Controller
1106:3104 USB 2.0
Choose a set of USB drivers which actually support this hardware.
Signed-off-by: Mirko Parthey <mirko.parthey@web.de>
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
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>
The current code only partially invalidates both caches
because the cache size and cache-line size values are
incorrectly passed to the C code.
Fix the assembly code to pass the arguments in the correct
order.
Compile tested only.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
SVN-Revision: 49060
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
Jo-Philipp Wich