[OpenWrt-Devel] [PATCH 0/2] ramips: fix RBMxxG name and partitionning
Thibaut VARÈNE
hacks at slashdirt.org
Thu Jul 19 13:12:31 EDT 2018
This series fix the DTS files of the MikroTik RouterBOARD M11G and M33G. The
changes are similar in both patches:
- The model name string is updated to match the hardware-stored (in flash)
string that we cannot (yet?) extract at runtime.
- The partition scheme is updated to reflect areas reserved by OEM (as defined
in their GPL source code) and the reverse-engineered sections contained
herein.
The proposed partition scheme defines a "top-level" overlapping "RouterBoot"
partition that matches the identically named, OEM-defined segment (in their GPL
code), and then defines extrapolated sub-segments.
The rationale for this is as follows:
- OEM only defines the 0x0 0x40000 segment in their source: the whole segment
should thus be considered "reserved by OEM", despite having empty holes.
- The subsegments are reverse-engineered (initially by Gabor Juhos in
target/linux/ar71xx/files/arch/mips/ath79/routerboot.c) and may vary from
hardware to hardware (they are already different in size and offsets between
ar71xx and ramips).
- We have no certitude that the empty holes will remain empty: it is desirable
to make it perfectly clear that they should never be reclaimed as user
storage space (preferably without having to define a clutter of empty
partitions).
- OEM tools might be usable with this top level partition present and named
identically with OEM.
- The top level partition is a convenient way to ask for a user dump ("please
send the content of the RouterBoot partition") and build a database of such
dumps whose use will become apparent below.
- I expect it might eventually be possible to split that top level partition
at runtime with a splitter.
This last point is of particular significance: currently the proposed partition
scheme "emulates" what the purported splitter would produce at runtime. In an
ideal world the DTS would only define the top-level RouterBoot area and the
splitter would produce the exact same partition as is currently defined, in a
fashion very similar to what is done with e.g. the 'firmware' partition.
Regardless, in this situation the partition scheme for these devices would thus
not change.
I cannot immediately provide such a runtime splitter, notably because I would
need to collect several dumps to extract a statistically meaningful working set
to test the splitter code against; and also because of DTS-specific challenges
associated with this proposal (the MAC address and ART data are contained in a
specific sub-partition currently directly referred in DTS).
These subpartitions are nevertheless necessary in their own right: besides the
primary and secondary bootloader (apparently common to all RB devices, across
all platforms) defined as 'routerboot' and 'routerboot2', the 'hard_config'
segment contains the device MAC address, its model name string, its serial
number or its WLAN calibration data for instance.
The 'soft_config' partition contains user-modifiable settings such as boot
delay, boot order, selected bootloader, cpu frequency scaling or uart speed.
These settings can be accessed and modified in OpenWRT via the 'rbcfg' utility,
which relies on the presence of the 'soft_config' partition to operate. This
explains the naming choice for these subpartitions: it's been carried over from
ar71xx for consistency.
Thibaut VARÈNE (2):
ramips: fix RBM33G name and partitioning
ramips: fix RBM11G name and partitioning
target/linux/ramips/dts/RBM11G.dts | 62 ++++++++++++++++++++++++++----------
target/linux/ramips/dts/RBM33G.dts | 64 +++++++++++++++++++++++++++++---------
2 files changed, 95 insertions(+), 31 deletions(-)
--
2.14.3 (Apple Git-98)
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
More information about the openwrt-devel
mailing list