<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi,<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">Le 15 mars 2020 à 14:20, Roger Pueyo Centelles | <a href="http://Guifi.net" class="">Guifi.net</a> <<a href="mailto:roger.pueyo@guifi.net" class="">roger.pueyo@guifi.net</a>> a écrit :</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div class=""><p class="">Hi,</p>
<blockquote type="cite" cite="mid:C161EAD9-7C28-484D-A0B6-DA7A9366F514@slashdirt.org" class="">
<div class="">I believe this is a waste of resources and a very suboptimal
approach. I’m not sure I’m interested in spending time on this
:P</div>
</blockquote>
Probably it is. How would you approach it? Some devices that are the
same hardware with just a different name are already supported like
this:
<a href="https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=ac36cca012dd1bbeea0fc4c2dc7a00941de34b52" class="">https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=ac36cca012dd1bbeea0fc4c2dc7a00941de34b52</a><br class=""></div></div></blockquote><div><br class=""></div>Yes, except in this case the resulting image name isn’t changed and the difference in naming is very subtle. In the case I quote below, one device is called RB 911L, the other RB SXT 2nD r3. The average user is never going to know they’re one and the same :P</div><div><br class=""></div><div>That’s why I’d prefer maintaining the one-image for all devices approach, which has benefits both for the openwrt infrastructure (it scales and consumes less ressources) and for the users (« you have a mikrotik SPI NOR device? You can’t get it wrong, the image works on all of those we support »).</div><div><br class=""></div><div>Considering routerboot’s lack of support for DTS, I suspect the only way to tackle this is via an intermediary loader, unless there is a specific mechanism in the kernel we could use (I’m not aware of any, but I know very little about the implementation details of DTS).</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div class="">
<blockquote type="cite" cite="mid:C161EAD9-7C28-484D-A0B6-DA7A9366F514@slashdirt.org" class="">
<div class="">Some devices share the exact same hardware and differ only in
(marketing) name, as evidenced by:</div>
<div class=""><a href="https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=5ac974f2145c770431a6eb7e006dd086b70224b1" class="" moz-do-not-send="true">https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=5ac974f2145c770431a6eb7e006dd086b70224b1</a></div>
<div class=""><br class="">
</div>
<div class="">(this device uses the 911L platform)</div>
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class="">
<div class="">
<div class="">Just have a look at how the few ath79 devices
are implemented, but note that they will be moved to a
mikrotik subtarget soon as indicated by Roger already.<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
<div class="">I’ve offered in this thread a couple patches to
align the ath79 implementation on the existing ramips one wrt
mtd partitioning and naming.</div>
</blockquote><p class="">To me they're OK, I have no preference for having the partitions
nested or not. What are the benefits and drawbacks?</p><div class=""><br class=""></div></div></div></blockquote>As was once discussed and eventually accepted (when renaming RBMxxG partitions), this is in line with the canonical way to define partitions in DTS, as documented in Documentation/devicetree/bindings/mtd/partition.txt</div><div><br class=""><div class="">This method is apparently used in all bcm targets, including ath79, ipq and lantiq. The aforementioned documentation says:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>For backwards compatibility partitions as direct subnodes of the flash device are</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>supported. This use is discouraged.</div><br class="Apple-interchange-newline"><br class=""></div><div>Cheers,</div><div>Thibaut</div></body></html>