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