[OpenWrt-Devel] [PATCH v2 2/4] ramips: fix RBM33G partitioning

[Thibaut]

> Le 30 juil. 2018 à 08:40, John Crispin <john at 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 at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel