memset() was called with a size argument against a pointer size, not the
structure size itself.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
SVN-Revision: 43913
The new TP-LINK Pharos series uses a new bootloader, the "TP-LINK Safeloader".
It uses an advanced firmware image format, containing an image partition table
and a flash partition table (and image partitions are mapped to the
corresponding flash partitions). The exact image format is documented in the
source code.
Furthermore, the bootloader expects the kernel image as an ELF executable.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
SVN-Revision: 43384
(Reposted due to an issue with the patchwork server during original submission)
Unbranded. Silkscreen on PCB is “A5-V11”, believed to be made by Bococom (or at least uses Bococom image encryption - as used on poray devices - but different key)
Signed-off-by: Gareth Bryan <gareth@mx9.org>
SVN-Revision: 43102
Compiling the host tools on the new x32 architecture (which is
an ILP32 ELF32 system on an amd64 CPU) fails for various reasons.
gmp: pull same fix I applied to OpenADK, which was inspired
by the fix in the Debian source package
mtd-utils: write a workaround myself; only affects x32, but
the use of llseek is dangerous according to the manpage, so
the guard ifdef should probably go away
findutils: pull fix straight from the Debian source packae
Signed-off-by: Thorsten Glaser <tg@mirbsd.org>
SVN-Revision: 43060
I defined a new download method @SAVANNAH in include/download.mk and scripts/download.pl,
and converted quilt and qemu to use that method.
Signed-off-by: Hannu Nyman <hannu.nyman@iki.fi>
SVN-Revision: 42840
I have never seen a LP-PHY with core rev 16 or higher, but the ucode
will be included, because we need LP-PHY 13 and 15 and N-PHY core rev
16. Comment out the code for now.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
SVN-Revision: 41595
This adds support for new firmware files from b43 and selects the ucode
based on the PHY type now.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
SVN-Revision: 41592
This patch adds factory image building for the DGN3500, all variants,
and fixes sysupgrade images to make them play nice with the sercomm
secondary boot loader.
The factory images can be used directly in the update dialog in the
interface of the stock firmware and via the special Sercomm bootmode
and a special windows flashing utility (allegedly present in the CD
that came with the device -- but it's also compatible with the NSLU2
Upgrade_207_XP utility.) The special bootmode can be activated by
turning the device on while holding the reset button pressed, then
releasing it when the power led starts blinking red and green. Please
notice that if using the 207 utility, it will always report that the
flashing failed even though it completed successfully. Just power
cycle the router manually after the utility reports the failure and
OpenWRT will boot. This same utility (despite reporting failure in
this case too) can revert a DGN3500 (any variant) to the appropriate
stock Netgear firmware.
This patch is a heavily modified version of a package I found on the
OpenWRT forum with a couple fixes and features added -- mainly the
generation of all the different image variants to support all known
models directly, atm known variants are AnnexA-WW, AnnexA-NA and
AnnexB-DE/GR.
I tested the patch successfully on my device.
Signed-off-by: Marco Antonio Mauro <marcus90@gmail.com>
SVN-Revision: 41236
This patch series is extracted from
http://ftp.de.debian.org/debian/pool/main/g/genext2fs/genext2fs_1.4.1-4.debian.tar.gz
The patches are used in Debian for quite a long time, so I assume that
this is solid material. At least, my Ubuntu host fsck.ext4 does not bark :-)
The goal is to allow building filesystems with larger blocksizes instead of the
current default of 1k. This should improve performance and lifetime when the
filesystem is stored e.g. on a SD card (on Raspberry Pi/I2SE Duckbill for example)
which uses internal flash memory. Writing to flash memory is slow because writing
the data of one block results in erasing a whole erase block of the flash memory.
Thus it is preferable to align the filesystem block size on a flash device with
the erase blocksize, or at least bring it closer to the later one, to avoid
unnecessary write amplification.
Signed-off-by: Michael Heimpold <mhei@heimpold.de>
SVN-Revision: 40921
Jo-Philipp Wich