[LEDE-DEV] [PATCH] ramips: fix AR670W partition alignment

[Claudio Leite]

Hello,

* 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.

-Claudio