[From nobody Thu Jun 25 05:54:45 2020 Received: from mail-oi0-x242.google.com ([2607:f8b0:4003:c06::242]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1fgbIP-000214-EY for openwrt-devel@lists.openwrt.org; Fri, 20 Jul 2018 19:42:35 +0000 Received: by mail-oi0-x242.google.com with SMTP id n84-v6so23251268oib.9 for <openwrt-devel@lists.openwrt.org>; Fri, 20 Jul 2018 12:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ERn3qpBTxVUfRaLca30tHcyQnkucn17j8A6yceqvmZY=; b=RXan2S/hYLZP9IoE7yX0DGM+LYyapdEtrqXnginF5BjdrJFRdOuMZxB0ZRNQUE+lTg JpHcqDgCv5q4kGYQULWR2jGXGCaKB+qP/p5+n8tdNQ2Gj0R6Ig0Ke/QqRwbRwF9hmDqd xnGE7PmGs22SrQKjPyhhA3+dLZ0VDKshERlaGeRfZRTjNqqdyfm6wyK2KZtIRmIwwGOy MgAL8wET+YAeuONrUSJ3JJ9l333NHLZXMn+/WgBarMeQXjwfsnZE1GqOTJ5c1fuJdxAq 8F0nZVgPcHLs2KAJIjUTWmi6aRPOLnsqwPfX0rLeJDb8fVrsiLn6xyli4XJuhFQ1hvM6 sE8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ERn3qpBTxVUfRaLca30tHcyQnkucn17j8A6yceqvmZY=; b=lpF0HM2SiPphaKJglySM5HLF+D6Y8MmibRzfFvmxG+sk8qPTkwdiahzY7yuQ9O+i3e ZlicFLKye2LiBN1uu5oufZNT7RwLvCQKTF98QrEcKNIGS0nkZ9NK4f08Pgc/Ic0IGMk0 s2QXMcOhRS+hNF3wdN87C6VXuiQJqWe4hBYfpGgm0OCE1+MzBsef5lBHOxyRz8oyPxy5 EuDBzA1eQ8aqcnfFnoowPYZ0WYX4ptyds0kw6WBrnlHmnRz7+Zy8pURH3hrHpnihIo8o Ry3Rwb4+q0T8nVVLGC6mVwFgZuJj/1bdOV+hwTTBHQQJkmm9fxVzlGVRApm2HFCeN64V 3lrQ== X-Gm-Message-State: AOUpUlEPF9eiU+yvd6G41BmOcYMqukCUQOWtr/k+yTfN3QCorb5cW7Gg UVK/1jtEWdbnupXxj66bGgPieFOuasdWdleSUzBf236u X-Google-Smtp-Source: AAOMgpdJKUZpz+QOSmHmNbEWY1TTU0PdQdDNJF7GPJs9SFT8jEUTdBXSjwm9UNWwC2IAhzfNyMXX+lij4xSizORj0EE= X-Received: by 2002:aca:4d87:: with SMTP id a129-v6mr53693oib.256.1532115741958; Fri, 20 Jul 2018 12:42:21 -0700 (PDT) MIME-Version: 1.0 References: <20180719171233.43763-1-hacks@slashdirt.org> In-Reply-To: <20180719171233.43763-1-hacks@slashdirt.org> From: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Date: Fri, 20 Jul 2018 21:42:10 +0200 Message-ID: <CAFBinCDHr7mqucX1MfRH4yLJ5fZLi_c2y5LBtMzbpnmOUEvkHw@mail.gmail.com> Subject: Re: [OpenWrt-Devel] [PATCH 0/2] ramips: fix RBMxxG name and partitionning To: hacks@slashdirt.org Cc: openwrt-devel@lists.openwrt.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20180720_124233_512324_B4F2C6E8 X-CRM114-Status: GOOD ( 19.60 ) X-Spam-Score: -0.1 (/) X-Spam-Report: SpamAssassin version 3.4.1 on bombadil.infradead.org summary: Content analysis details: (-0.1 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [2607:f8b0:4003:c06:0:0:0:242 listed in] [list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (martin.blumenstingl[at]googlemail.com) 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain On Thu, Jul 19, 2018 at 7:13 PM Thibaut VAR=C3=88NE <hacks@slashdirt.org> w= rote: > > 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 flas= h) > string that we cannot (yet?) extract at runtime. > - The partition scheme is updated to reflect areas reserved by OEM (as d= efined > in their GPL source code) and the reverse-engineered sections containe= d > herein. > > The proposed partition scheme defines a "top-level" overlapping "RouterBo= ot" > partition that matches the identically named, OEM-defined segment (in the= ir 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 se= gment > should thus be considered "reserved by OEM", despite having empty hole= s. > - The subsegments are reverse-engineered (initially by Gabor Juhos in > target/linux/ar71xx/files/arch/mips/ath79/routerboot.c) and may vary f= rom > hardware to hardware (they are already different in size and offsets b= etween > ar71xx and ramips). > - We have no certitude that the empty holes will remain empty: it is des= irable > 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 na= med > identically with OEM. > - The top level partition is a convenient way to ask for a user dump ("p= lease > 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 parti= tion > at runtime with a splitter. these seem good reasons to add a "big" partition ranging from 0x0 to 0x4000= 0 > This last point is of particular significance: currently the proposed par= tition > scheme "emulates" what the purported splitter would produce at runtime. I= n an > ideal world the DTS would only define the top-level RouterBoot area and t= he > 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 woul= d 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 w= ould > need to collect several dumps to extract a statistically meaningful worki= ng set > to test the splitter code against; and also because of DTS-specific chall= enges > 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: beside= s the > primary and secondary bootloader (apparently common to all RB devices, ac= ross > all platforms) defined as 'routerboot' and 'routerboot2', the 'hard_confi= g' > segment contains the device MAC address, its model name string, its seria= l > 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 boo= t > delay, boot order, selected bootloader, cpu frequency scaling or uart spe= ed. > These settings can be accessed and modified in OpenWRT via the 'rbcfg' ut= ility, > which relies on the presence of the 'soft_config' partition to operate. T= his > explains the naming choice for these subpartitions: it's been carried ove= r 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 ]