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 <sbr...@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 <brunomp...@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 <brunomp...@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 <dan...@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 > >
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
