05.02.2017 10:15, John Crispin:
On 05/02/2017 09:59, Claudio Leite wrote:
mtdsplit_lzma requires that the rootfs be aligned to a block boundary.
Pad the kernel partition to make this so.
Signed-off-by: Claudio Leite <lei...@gmail.com>
---
target/linux/ramips/image/rt288x.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/ramips/image/rt288x.mk
b/target/linux/ramips/image/rt288x.mk
index 4a0d6d4..86a5063 100644
--- a/target/linux/ramips/image/rt288x.mk
+++ b/target/linux/ramips/image/rt288x.mk
@@ -14,7 +14,7 @@ define Device/ar670w
BLOCKSIZE := 64k
DEVICE_TITLE := Airlink AR670W
IMAGE_SIZE := $(ralink_default_fw_size_4M)
- KERNEL := $(KERNEL_DTB)
+ KERNEL := $(KERNEL_DTB) | pad-to $$(BLOCKSIZE)
IMAGES += factory.bin
IMAGE/factory.bin := $$(sysupgrade_bin) | check-size $$$$(IMAGE_SIZE) | \
wrg-header wrgn16a_airlink_ar670w
Hi
although technically correct, the lzma splitter needs to be fixed to not
have this requirement, instead of adding these patches for all boards.
there is no need for any padding beyond 4byte padding.
I'm in doubt that the lzma splitter can be fixed.
The dependency to align the rootfs isn't specific to the lzma splitter.
mtd_find_rootfs_from() in mtdsplit.c uses the erase block size as step size.
For the other splitter an not erase block size aligned rootfs works only
because the headers provide informations about the kernel size and we
can pass the kernel size as offset to mtd_find_rootfs_from() to prevent
stepping over the mtd.
But the lzma header doesn't provide any informations about
kernel/compressed size. Only the uncompressed size is stored in the
header. According to the LZMA SDK, the LZMA decoder simply stops
decompressing as soon as the amount of decompressed data matches the
value stored in the header.
The only fix I can think of, would be to change the step size in
mtd_find_rootfs_from() to 1 byte. But that would introduce a huge
performance penalty.
Hopefully I missed the obvious solution for the problem.
Mathias
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
