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

[Bruno Pena]

Hi Steve,

You're fast!!
I highly appreciate your help on this issue and thank you one again for
testing this change.
The only thing left to test is the build of a full read-only firmware,
which I'll try today after work.
Assuming everything works fine I'll then submit a new patch on GitHub.

Best regards,
Bruno Pena

On Wed, Jan 22, 2020, 13:03 Steve Brown <sbrown at ewol.com> wrote:

> Hi Bruno,
>
> Your suggested fix works on my TPLink A7-V5.
>
> diff --git a/target/linux/ath79/image/common-tp-link.mk
> b/target/linux/ath79/image/common-tp-link.mk
> index 9048e8340c..8aa6a5a2be 100644
> --- a/target/linux/ath79/image/common-tp-link.mk
> +++ b/target/linux/ath79/image/common-tp-link.mk
> @@ -71,7 +71,7 @@ endef
>
>  define Device/tplink-safeloader-uimage
>    $(Device/tplink-safeloader)
> -  KERNEL := kernel-bin | append-dtb | lzma | uImageArcher lzma | pad-to
> 64k
> +  KERNEL := kernel-bin | append-dtb | lzma | uImageArcher lzma
>  endef
>
>  define Device/tplink-loader-okli
> diff --git
> a/target/linux/generic/hack-4.19/401-inherit-parent-partition-access-mode.patch
> b/target/linux/generic/hack-4.19/401-inherit-parent-partition-access-mode.patch
> index 61dd0369a6..85e958acff 100644
> ---
> a/target/linux/generic/hack-4.19/401-inherit-parent-partition-access-mode.patch
> +++
> b/target/linux/generic/hack-4.19/401-inherit-parent-partition-access-mode.patch
> @@ -36,7 +36,7 @@
>                 parts[i].offset += slave->offset;
>
>  +              /* adjust partition mask */
> -+              parts[i].mask_flags = !(slave->mtd.flags & MTD_WRITEABLE)
> ? MTD_WRITEABLE : 0;
> ++              parts[i].mask_flags = !(slave->mtd.orig_flags &
> MTD_WRITEABLE) ? MTD_WRITEABLE : 0;
>  +
>                 mtd_add_partition(slave->parent,
>                                   parts[i].name,
>
> Thanks,
> Steve
>
> On Wed, 2020-01-22 at 12:18 +0100, Bruno Pena wrote:
> > Hi Steve,
> >
> > Don't waste your time with the previous test request.
> > I'll try to test either today/tomorrow the "mtd.orig_flags" approach
> > on my device and - if successful - I'll then ask if you can try it on
> > your TP-Link.
> >
> > Thank you and best regards,
> > Bruno Pena
> >
> > On Wed, Jan 22, 2020, 11:34 Bruno Pena <brunompena at gmail.com> wrote:
> > > Just a small correction on the previous email, there's actually no
> > > padding requirement since everything will be read-only!
> > >
> > > On Wed, Jan 22, 2020, 11:25 Bruno Pena <brunompena at gmail.com>
> > > wrote:
> > > > Hi Daniel,
> > > >
> > > > I was looking at the code and I think it's possible to relax the
> > > > enforcement of the parent access mode.
> > > > We can switch from a strict enforcement of the resulting mtd
> > > > access mode, to only enforcing the configured access mode (from
> > > > the DTS file).
> > > >
> > > > This can be achieved by changing from using mtd.flags to
> > > > mtd.orig_flags:
> > > >     parts[i].mask_flags = !(slave->mtd.orig_flags &
> > > > MTD_WRITEABLE) ? MTD_WRITEABLE : 0;
> > > >
> > > > With this change we no longer impact builds that do not have a
> > > > read-only firmware partition, but we can still enforce it for
> > > > those that need it.
> > > > One thing to keep in mind is that the padding is still a
> > > > requirement for those devices which are building a read-only
> > > > firmware partition!
> > > >
> > > > Also please note this is not tested, these conclusions are only
> > > > based on the analysis of the kernel source code.
> > > >
> > > > Best regards,
> > > > Bruno Pena
> > > >
> > > >
> > > > On Wed, Jan 22, 2020, 10:40 Daniel Golle <daniel at makrotopia.org>
> > > > wrote:
> > > > > Hi Bruno,
> > > > >
> > > > > On Wed, Jan 22, 2020 at 10:22:01AM +0100, Bruno Pena wrote:
> > > > > > I would also like to take the opportunity to ask if it's
> > > > > worth pursuing
> > > > > > this patch if it means that all devices (using mtd) will
> > > > > require their
> > > > > > partitions to be padded to the blocksize?
> > > > >
> > > > > Please try not to introduce that padding, it's quite a big
> > > > > impact on
> > > > > all devices while only very few (wifi-only device) really need
> > > > > that
> > > > > change. Instead of wasting flash space by additional padding
> > > > > I'd rather
> > > > > want to see an OpenWrt-specific kernel-patch to allow a rw
> > > > > subpartition
> > > > > sitting inside an ro partition or just flatten the mtd
> > > > > partitioning.
> > > > > What I mean by flatteing is this:
> > > > >
> > > > > yout current approach:
> > > > > +-----------------------------+
> > > > > |          firmware           |
> > > > > +--------+--------------------+
> > > > > |        $       rootfs       |
> > > > > | kernel +------+-------------+
> > > > > |        $ rom  | rootfs_data |
> > > > > +--------+------+-------------+
> > > > >
> > > > > here rootfs_data inherigs the read-only from rootfs not being
> > > > > block-
> > > > > aligned. a better/flat approach would be:
> > > > > +-----------------------------+
> > > > > |          firmware           |
> > > > > +--------+------+-------------+
> > > > > | kernel $ rom  | rootfs_data |
> > > > > +--------+------+-------------+
> > > > >
> > > > > Now this would require major changes to our mtd-splitting
> > > > > subsystem
> > > > > which is quite a big amount of work...
> > > > >
> > > > >
> > > > > Cheers
> > > > >
> > > > >
> > > > > Daniel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20200122/a7979b18/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel