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>
SVN-Revision: 27185
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)
SVN-Revision: 22418
* 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.
SVN-Revision: 22396
'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.
SVN-Revision: 22013
- hacked addpattern due to changes in header format
- added "-5" to addpattern, some 0xFF are needed for trx2 header
"-4" broke CRC checking in CFE
- hacked trx.c due to new header format version
- added target to create trx-V2 images
the flashmap driver possibly needs to be customized.
SVN-Revision: 20433
We switched over to appending the jffs2 eof mark to the squashfs images,
but since the squashfs is not always aligned to eraseblocksize, the eof
mark landed in the wrong place. This commit adds an extra flag to the
trx utility that can append extra data to a partition with alignment.
This is used to place the jffs2 eof mark at the right offset.
SVN-Revision: 7253
Felix Fietkau