[OpenWrt-Devel] [PATCH v2] fstools: Add support to read-only MTD partitions (eg. recovery images)

[Bruno Pena]

Hi Mathias,

Actually the current default for the ath79 architecture is to pad the
partitions as seen on target/linux/ath79/image/Makefile:

    define Device/Default
      [...]
      IMAGE/sysupgrade.bin = append-kernel | pad-to $$$$(BLOCKSIZE) | \
            append-rootfs | pad-rootfs | append-metadata | check-size
$$$$(IMAGE_SIZE)

This means that all devices that do not customize the sysupgrade.bin will
have their partitions padded to the blocksize (which are still quite a few).

Having said that, I do understand and agree that for very small flash sizes
it may seem unwise to spend up to 64k (32k on average) just to round the
partition to the blocksize.
However, due to how mtd is implemented the padding is actually a
requirement for this kernel patch to work properly.

Best regards,
Bruno Pena

On Tue, Jan 21, 2020 at 11:51 PM Mathias Kresin <dev at kresin.me> wrote:

> 21/01/2020 22:10, Bruno Pena:
> > Hi everyone,
> >
> > I was finally able to replicate the issue you are observing.
> >
> > The problem comes from the fact that the kernel partition on the TP-Link
> > images is not padded to the write blocksize - which can be observed on
> > the dmesg from Steve:
> >
> > [    0.450987] 0x000000000000-0x0000001a39ea : "kernel"
> > [    0.456772] 0x0000001a39ea-0x000000ec0000 : "rootfs"
>
> [...]
>
>  > Would any of you be willing to spend some time testing this change on
>  > your TP-Link?
>
> Hey Bruno,
>
> what you see here, is pretty much OpenWrt standard. It's done this way
> to not waste any flash space.
>
> If we would pad the kernel to the erase block boundary, we would lose
> flash space, which can't be used for the rootfs. Considering the 0x10000
> bytes EB size for the TP-Link device, we would loose 64 KByte in worst
> case.
>
> Mathias
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20200122/769b7ba7/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel