>> Ping? Doesn't someone have some idea of where that might come from?
> I'm not familiar with .trx in particular, but at least for AR7 squashfs
> images there is a 4-byte jffs marker at the very end that is
> deliberately aligned to the start of the next erase block after the end
> of the real firmware. The "wasted" 65532 bytes of space in that erase
> block then actually turns into part of the jffs root, which has to be
> erase-block-aligned.
> i.e. you have a firmware image of the form:
> <kernel> <squashfs> <padding to 64k boundary> <jffs marker>
> which (after the first boot) then looks like this:
> <kernel> <squashfs> <padding to 64k boundary> <jffs data ...>
> (well, actually, it puts markers at both 64k- and 128k-aligned
> boundaries so it works with either erase block size, but the idea is the
> same)
> I guess the .trx format then pads the firmware to a 4k boundary, so you
> get a firmware size of n*64k+4k.
Interesting. So that would mean that as long as I don't actually use
a jffs partition, I can just strip off the last 4kB excess?
Actually, now that I look at it, I see that indeed
build_dir/linux-*/fs_mark is appended to the image, and it's not just
4B, but 64kB+4B, which explains why my rootfs_data is still 128kB.
So there are indeed a whole 128kB to recover. Great, thanks.
Stefan
_______________________________________________
openwrt-devel mailing list
[email protected]
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
