[OpenWrt-Devel] [PATCH 2/2] ramips: fix RBM11G name and partitioning

[Thibaut]

> Le 20 juil. 2018 à 19:56, Martin Blumenstingl <martin.blumenstingl at googlemail.com> a écrit :
> 
>> On Thu, Jul 19, 2018 at 7:12 PM Thibaut VARÈNE <hacks at slashdirt.org> wrote:
>> 
>> This patch improves faf64056ddd46992a75b1e277d94541c7251035c by setting
>> the correct 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, with an overlapping "RouterBoot" top level
>> partition added for clarity due to the many holes.
>> 
>> The resulting partition scheme looks like this:
>> [    2.477826] Creating 7 MTD partitions on "spi0.0":
>> [    2.482604] 0x000000000000-0x000000040000 : "RouterBoot"
>> [    2.488948] 0x000000000000-0x00000000f000 : "routerboot"
>> [    2.495289] 0x00000000f000-0x000000010000 : "hard_config"
>> [    2.501596] 0x000000010000-0x00000001f000 : "routerboot2"
>> [    2.507966] 0x000000020000-0x000000021000 : "soft_config"
>> [    2.514307] 0x000000030000-0x000000031000 : "bios"
>> [    2.520108] 0x000000040000-0x000001000000 : "firmware"
>> 
>> The device name is corrected to match the hardware-stored (in hard_config)
>> device name.
>> 
>> Leave a note in DTS to mention this device supports hardware crypto.
> I find this bit of information strange since it has nothing to do with
> the other changes. also: what kind of hardware crypto does it support?

Documentation note as there’s ongoing work to support these devices: easier to grep than to check individual devices specs. If all mt7621s have this onboard device then indeed the note is unnecessary.

>> Leave a note in DTS to explain how the original author selected the SPI speed.
>> 
>> Note: more work is required to get rbcfg working on this device due to
>> endianness.
>> 
>> Tested-by: Tobias Schramm <tobleminer at gmail.com>
>> Signed-off-by: Thibaut VARÈNE <hacks at slashdirt.org>
>> ---
>> target/linux/ramips/dts/RBM11G.dts | 62 +++++++++++++++++++++++++++-----------
>> 1 file changed, 45 insertions(+), 17 deletions(-)
>> 
>> diff --git a/target/linux/ramips/dts/RBM11G.dts b/target/linux/ramips/dts/RBM11G.dts
>> index f312093a22..079b4fc146 100644
>> --- a/target/linux/ramips/dts/RBM11G.dts
>> +++ b/target/linux/ramips/dts/RBM11G.dts
>> @@ -7,7 +7,7 @@
>> 
>> / {
>>        compatible = "mikrotik,rbm11g", "mediatek,mt7621-soc";
>> -       model = "MikroTik RBM11G";
>> +       model = "MikroTik RouterBOARD M11G";
> why do you need to change the model when updating the partitions? the
> commit message doesn't explain this

This started as a cleanup patch which I didn’t expect to be this controversial so I didn’t split out this one liner.

>>        aliases {
>>                led-status = &led_usr;
>> @@ -90,29 +90,54 @@
>>                #size-cells = <1>;
>>                compatible = "jedec,spi-nor";
>>                reg = <0>;
>> +               // XXX empiric value to obtain actual 10MHz SCK at the chip
>>                spi-max-frequency = <3125000>;
>> 
>> -               partition at 0 {
>> -                       label = "routerboot";
>> -                       reg = <0x000000 0x00F000>;
>> -                       read-only;
>> -               };
>> -
>> -               factory: partition at f000 {
>> -                       label = "factory";
>> -                       reg = <0x00F000 0x031000>;
>> -                       read-only;
>> -               };
>> -
>> -               partition at 40000 {
>> -                       label = "firmware";
>> -                       reg = <0x040000 0xFC0000>;
>> +               partitions {
>> +                       compatible = "fixed-partitions";
>> +                       #address-cells = <1>;
>> +                       #size-cells = <1>;
>> +
>> +                       partition at 0 {
>> +                               label = "RouterBoot";
>> +                               reg = <0x0 0x40000>;
>> +                               read-only;
>> +                       };
>> +
>> +                       routerboot at 0 {
>> +                               reg = <0x0 0xf000>;
>> +                               read-only;
>> +                       };
> isn't the recommended node name "partition" nowadays?

Not according to kernel documentation.

> both partitions above would then become "partition at 0" -> whether the
> second node overwrites the first one (since both node names and
> addresses/offsets are identical) or both are added to the resulting
> .dtb depends on the dtc (device tree compiler) version, so I highly
> recommend *NOT* doing this
> 
>> +                       hard_config: hard_config at f000 {
>> +                               reg = <0xf000 0x1000>;
>> +                               read-only;
>> +                       };
>> +
>> +                       routerboot2 at 10000 {
>> +                               reg = <0x10000 0xf000>;
>> +                               read-only;
>> +                       };
>> +
>> +                       soft_config at 20000 {
>> +                               reg = <0x20000 0x1000>;
>> +                       };
>> +
>> +                       // valid data only extends up to 0x4f but make it 0x1000 to match ar71xx
>> +                       bios at 30000 {
>> +                               reg = <0x30000 0x1000>;
>> +                               read-only;
>> +                       };
>> +
>> +                       firmware at 40000 {
>> +                               reg = <0x040000 0xFC0000>;
>> +                       };
>>                };
>>        };
>> };
>> 
>> &ethernet {
>> -       mtd-mac-address = <&factory 0x0010>;
>> +       mtd-mac-address = <&hard_config 0x0010>;
> if you keep only the big RouterBoot partition you can simply use that
> here (you just have to add 0xf000 to the offset)

I explained in the cover letter why both the top level and the subpartitions are useful. Please refer to that.

Best,
T.



_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel