> Le 30 juil. 2018 à 08:40, John Crispin <j...@phrozen.org> a écrit : > > > > On 29/07/18 11:07, Thibaut VARÈNE wrote: >> This patch improves 5684d087418d176cfdef4e045e1950ca7ba3b09f by correcting >> the partition scheme for the "RouterBoot" section of the flash. >> >> This section is subdivided in several segments, as they are on ar71xx >> RB devices, albeit with different offsets and sizes. The naming convention >> from ar71xx has been preserved. The preferred 'fixed-partitions' DTS >> node syntax is used, with nesting support as introduced in 2a598bbaa3. >> >> The OEM source code also define a "RouterBootFake" partition at the >> beginning of the secondary flash chip: to avoid trouble if OEM ever makes >> use of that space, it is also defined here. > > as discussed on IRC we concluded, that this should be done with a mtd > splitter. > John
I’m sorry, we didn’t conclude anything, I believe you demanded it be done so. Unfortunately, after a more careful investigation, I am now convinced this is not the right course of action. Here’s why, in my very humble opinion and limited understanding: - this splitter will be quite intrusive in generic code (currently « mtdsplit » only works with « firmware » and « rootfs » named partitions) - the bootloaders (routerboot and routerboot2) cannot be programmatically splitted: they are raw machine code without a signature - all ramips routerboard machines share the exact same partition scheme which is different from all the ar71xx routerboard machines (which also all share the same scheme) - if I read the OEM source code correctly, it’s likely their ARM-based boards have yet another partition scheme Consequently, a purported splitter will be invasive and full of hardcoded numbers, making its upstream acceptance very unlikely (I anticipate the argument « this should all be done in DTS, especially now that DTS supports nested partitions »). Now, I would like to hope that a correct partition scheme that uses all the OpenWRT-accepted features and follows guidelines would be more likely to be accepted in the source than the currently broken, incorrect and incomplete existing one. Best regards, T. _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
