[LEDE-DEV] [PATCH] ramips: fix AR670W partition alignment
leitec at gmail.com
Mon Feb 6 15:03:19 PST 2017
* Mathias Kresin (dev at kresin.me) wrote:
> 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.
I tried the naive approach, except stepping every 4 bytes given John's
remarks. It does incur some performance penalty, slowing boot down
about 0.6 seconds.
before; aligned to eraseblock
[ 0.667565] 0x000000040000-0x000000400000 : "firmware"
[ 0.684885] 2 lzma-fw partitions found on MTD device firmware
[ 0.696634] 0x000000040000-0x000000180000 : "kernel"
[ 0.711025] 0x000000180000-0x000000400000 : "rootfs"
after; aligned to 4 bytes only
[ 0.667375] 0x000000040000-0x000000400000 : "firmware"
[ 1.293574] 2 lzma-fw partitions found on MTD device firmware
[ 1.305285] 0x000000040000-0x000000170ad4 : "kernel"
[ 1.319547] 0x000000170ad4-0x000000400000 : "rootfs"
At least in the case of this board it's not a huge delay. But given
that the search happens in mtd_find_rootfs_from() and affects other
models, the impact is likely to be more severe elsewhere.
Either approach fixes the oddball AR670W, which currently does not
boot LEDE. It uses u-boot, but the developers hardcoded an "uImage"
so that there's no length parameter to search from. I suppose it's
nice to have the extra 64k in rootfs_data with the second approach.
More information about the Lede-dev