The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.
--- Begin Message ---
On Thu, Jul 19, 2018 at 7:13 PM Thibaut VARÈNE <ha...@slashdirt.org> wrote:
>
> 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.
these seem good reasons to add a "big" partition ranging from 0x0 to 0x40000
> 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.
based on my understanding a splitter is used to dynamically
"configure" partitions based on some kind of metadata (header, footer,
...)
can you please add a bit more description which describes this
metadata in RouterBoot?
> 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.
to me this only seems relevant if the "hard_config" partition (or
"segment") doesn't have a fixed offset. if it is always at a fixed
offset then you can calculate the "final offset" to the data within
"hard_config" from the start of the flash (assuming the whole 0x0 to
0x40000 area is described as a big partition)
> 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.
this is a very important bit of information - MAC address, serial,
etc. is all static data where a big partition marked as read-only
doesn't hurt
Regards
Martin
--- End Message ---
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
