Re: [OpenWrt-Devel] [PATCH 1/1] ramips: remove RB750GR3 support

2018-07-19 Thread Thibaut 

> On 19 Jul 2018, at 19:52, Mathias Kresin  wrote:
> 
> 2018-07-19 19:26 GMT+02:00 Thibaut VARÈNE :
>> faf94d926e2810f895f2a98d4a49ee2fe8f673e8 added "support" for a hacked
>> device where the original boot loader (routerboot) has been replaced
>> by u-boot.
>> 
>> Support for this device with stock bootloader is possible (as evidenced
>> by support for the RBM33G), and conflicts with this code.
>> 
>> Remove code before release.
>> 
>> Signed-off-by: Thibaut VARÈNE 
> 
> FYI, I already NAK'ed the very same patch on github.
> 
> I do agree that it can be done better by not requiring the replacement
> of the bootloader. Nevertheless, support for this board is already
> shipped since LEDE-17.01 and I don't agree to drop support for a board
> without providing an alternative/fixed/better image.

Just to clarify: this is not “support”. This is a user created custom hack that 
applies only to their modified board.

T.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

2018-07-19 Thread Mathias Kresin 
2018-07-19 19:12 GMT+02:00 Thibaut VARÈNE :
> 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] 0x-0x0004 : "RouterBoot"
> [2.488948] 0x-0xf000 : "routerboot"
> [2.495289] 0xf000-0x0001 : "hard_config"
> [2.501596] 0x0001-0x0001f000 : "routerboot2"
> [2.507966] 0x0002-0x00021000 : "soft_config"
> [2.514307] 0x0003-0x00031000 : "bios"
> [2.520108] 0x0004-0x0100 : "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.
> 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 
> Signed-off-by: Thibaut VARÈNE 

FYI, I already NAK'ed the very same patch on github after a way to
short conversation on IRC follow by some more words on github.

I neither see the need to add notes for not yet working nodes
[personal preference] to the device tree source file, nor the need to
to create the overlapping partitions "RouterBoot" +
routerboot/hard_config/routerboot2/... [personal preference].

To get the dt compiler accepting the overlapping partitions without a
warning, a style was chosen completely different from all other dts
files in the target [maintenance reason]. Furthermore, nodes sharing
the same reg are usually (always?) expressed as child nodes in the
devicetree similar to [technical reason]:

partitions {
compatible = "fixed-partitions";

partition@0 {
reg = <0 0x3000>;

subpartition@0 {
reg = <0 0x1000>;
};

subpartition@1000 {
reg = <0x1000 0x2000>;
};
};

partition@3000 {
reg = <0x3000 0x1>;
};
};

To my knowledge, the above isn't possible with fixed-partitions. Which
either means fixed-partitions misses a feature or someone tries to use
it in a way not intended.

This time I'll leave it up to someone else to make a call. I tried my
best to turn it into something that I'm fine to accept and failed.

Mathias

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/2] ramips: fix RBM33G name and partitioning

2018-07-19 Thread Thibaut 

> On 19 Jul 2018, at 19:46, Mathias Kresin  wrote:
> 
> 
> To get the dt compiler accepting the overlapping partitions without a
> warning, a style was chosen completely different from all other dts
> files in the target [maintenance reason]. Furthermore, nodes sharing
> the same reg are usually (always?) expressed as child nodes in the
> devicetree similar to [technical reason]:
> 
> partitions {
>   compatible = "fixed-partitions";
> 
>   partition@0 {
>   reg = <0 0x3000>;
> 
>   subpartition@0 {
>   reg = <0 0x1000>;
>   };
> 
>   subpartition@1000 {
>   reg = <0x1000 0x2000>;
>   };
>   };
> 
>   partition@3000 {
>   reg = <0x3000 0x1>;
>   };
> };
> 
> To my knowledge, the above isn't possible with fixed-partitions.

I don’t see why. AIUI DTS syntax is respected, all nodes have a unique name and 
all nodes refer to their top boundary as the unit address.

> Which
> either means fixed-partitions misses a feature or someone tries to use
> it in a way not intended.

The above is in line with the canonical way to define partitions in DTS, as 
documented in Documentation/devicetree/bindings/mtd/partition.txt

This method is apparently used in all bcm targets, as well as ath79, ipq and 
lantiq. I’d suggest that _not_ using this method is a bug, and not the correct 
way to go, as evidenced by the aforementioned documentation. Quoting:

For backwards compatibility partitions as direct subnodes of the flash 
device are
supported. This use is discouraged.

If this gets accepted it should be cherry-picked for 18.06.

T.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/2] ramips: fix RBM33G name and partitioning

2018-07-19 Thread Mathias Kresin 
2018-07-19 19:12 GMT+02:00 Thibaut VARÈNE :
> This patch improves 5684d087418d176cfdef4e045e1950ca7ba3b09f 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 OEM source code also define a "fake" partition at the beginning of
> the secondary flash chip: to avoid trouble if OEM ever make use of that
> space, we define it here.
>
> The resulting partition scheme looks like this:
> [2.355095] Creating 6 MTD partitions on "spi0.0":
> [2.359872] 0x-0x0004 : "RouterBoot"
> [2.366197] 0x-0xf000 : "routerboot"
> [2.372437] 0xf000-0x0001 : "hard_config"
> [2.378818] 0x0001-0x0001f000 : "routerboot2"
> [2.385200] 0x0002-0x00021000 : "soft_config"
> [2.391503] 0x0003-0x00031000 : "bios"
> [2.419283] Creating 2 MTD partitions on "spi0.1":
> [2.424062] 0x-0x0004 : "RouterBootFake"
> [2.430717] 0x0004-0x0100 : "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.
> 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 
> Signed-off-by: Thibaut VARÈNE 

FYI, I already NAK'ed the very same patch on github after a way to
short conversation on IRC follow by some more words on github.

I neither see the need to add notes for not yet working nodes
[personal preference] to the device tree source file, nor the need to
to create the overlapping partitions "RouterBoot" +
routerboot/hard_config/routerboot2/... [personal preference].

To get the dt compiler accepting the overlapping partitions without a
warning, a style was chosen completely different from all other dts
files in the target [maintenance reason]. Furthermore, nodes sharing
the same reg are usually (always?) expressed as child nodes in the
devicetree similar to [technical reason]:

partitions {
compatible = "fixed-partitions";

partition@0 {
reg = <0 0x3000>;

subpartition@0 {
reg = <0 0x1000>;
};

subpartition@1000 {
reg = <0x1000 0x2000>;
};
};

partition@3000 {
reg = <0x3000 0x1>;
};
};

To my knowledge, the above isn't possible with fixed-partitions. Which
either means fixed-partitions misses a feature or someone tries to use
it in a way not intended.

This time I'll leave it up to someone else to make a call. I tried my
best to turn it into something that I'm fine to accept and failed.

Mathias

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

2018-07-19 Thread Thibaut 

> On 19 Jul 2018, at 19:46, Mathias Kresin  wrote:
> 
> 
> To get the dt compiler accepting the overlapping partitions without a
> warning, a style was chosen completely different from all other dts
> files in the target [maintenance reason]. Furthermore, nodes sharing
> the same reg are usually (always?) expressed as child nodes in the
> devicetree similar to [technical reason]:
> 
> partitions {
>compatible = "fixed-partitions";
> 
>partition@0 {
>reg = <0 0x3000>;
> 
>subpartition@0 {
>reg = <0 0x1000>;
>};
> 
>subpartition@1000 {
>reg = <0x1000 0x2000>;
>};
>};
> 
>partition@3000 {
>reg = <0x3000 0x1>;
>};
> };
> 
> To my knowledge, the above isn't possible with fixed-partitions.

I don’t see why. AIUI DTS syntax is respected, all nodes have a unique name and 
all nodes refer to their top boundary as the unit address.

> Which
> either means fixed-partitions misses a feature or someone tries to use
> it in a way not intended.

The above is in line with the canonical way to define partitions in DTS, as 
documented in Documentation/devicetree/bindings/mtd/partition.txt

This method is apparently used in all bcm targets, as well as ath79, ipq and 
lantiq. I’d suggest that _not_ using this method is a bug, and not the correct 
way to go, as evidenced by the aforementioned documentation. Quoting:

For backwards compatibility partitions as direct subnodes of the flash 
device are
supported. This use is discouraged.

T.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/1] ramips: remove RB750GR3 support

2018-07-19 Thread Mathias Kresin 
2018-07-19 19:26 GMT+02:00 Thibaut VARÈNE :
> faf94d926e2810f895f2a98d4a49ee2fe8f673e8 added "support" for a hacked
> device where the original boot loader (routerboot) has been replaced
> by u-boot.
>
> Support for this device with stock bootloader is possible (as evidenced
> by support for the RBM33G), and conflicts with this code.
>
> Remove code before release.
>
> Signed-off-by: Thibaut VARÈNE 

FYI, I already NAK'ed the very same patch on github.

I do agree that it can be done better by not requiring the replacement
of the bootloader. Nevertheless, support for this board is already
shipped since LEDE-17.01 and I don't agree to drop support for a board
without providing an alternative/fixed/better image.

Same as with Thibauts other patches, this time I'll leave it up to
someone else to make a call.

Mathias

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 0/1] [18.06] ramips: remove RB750GR3 support

2018-07-19 Thread Thibaut VARÈNE 
[resending properly formatted]

Detailed rationale:
• This code should never have been accepted: it should certainly not be part of
  a release and if it accidentally was part of one that should not be reason to
  continue what is IMO a mistake.
• This code does not support the stock hardware.
• This code is a maintenance burden (it's a custom hack, in essence).
• This code will induce confusion with end user when the correct code is
  introduced
• There will be no upgrade path between this code and the correct support.

Assuming there’s more than a single user for this code (which I doubt
considering the wiki suggests using an SPI flash programmer to install), the
supplementary rationale from my point of view is thus precisely to break the
support chain and make it perfectly clear that current “support" stops in 18.06
without what could be taken as a sign of a transition ("oh, image has changed
name but it should still be the right one"): old code in 17, nothing in 18,
support in 19: clean break.

No replacement is proposed since no such a thing can exist: stock hw uses a
different bootloader (routerboot) which expects a different image format, and
uses an incompatible mtd flash partitioning. "New" support code will be exactly
that: new.

Thibaut VARÈNE (1):
  ramips: remove RB750GR3 support

 .../linux/ramips/base-files/etc/board.d/02_network |   1 -
 target/linux/ramips/base-files/lib/ramips.sh   |   3 -
 .../ramips/base-files/lib/upgrade/platform.sh  |   1 -
 target/linux/ramips/dts/RB750Gr3.dts   | 125 -
 target/linux/ramips/image/mt7621.mk|   8 --
 5 files changed, 138 deletions(-)
 delete mode 100644 target/linux/ramips/dts/RB750Gr3.dts

-- 
2.14.3 (Apple Git-98)


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/1] ramips: remove RB750GR3 support

2018-07-19 Thread Thibaut VARÈNE 
faf94d926e2810f895f2a98d4a49ee2fe8f673e8 added "support" for a hacked
device where the original boot loader (routerboot) has been replaced
by u-boot.

Support for this device with stock bootloader is possible (as evidenced
by support for the RBM33G), and conflicts with this code.

Remove code before release.

Signed-off-by: Thibaut VARÈNE 
---
 .../linux/ramips/base-files/etc/board.d/02_network |   1 -
 target/linux/ramips/base-files/lib/ramips.sh   |   3 -
 .../ramips/base-files/lib/upgrade/platform.sh  |   1 -
 target/linux/ramips/dts/RB750Gr3.dts   | 125 -
 target/linux/ramips/image/mt7621.mk|   8 --
 5 files changed, 138 deletions(-)
 delete mode 100644 target/linux/ramips/dts/RB750Gr3.dts

diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index 76b6fe9f50..981e001f64 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -200,7 +200,6 @@ ramips_setup_interfaces()
jhr-n926r|\
mikrotik,rbm33g|\
mzk-wdpr|\
-   rb750gr3|\
rt-n14u|\
tplink,c20-v4|\
tplink,c50-v3|\
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index 5741cbd2ee..2dd0388426 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -418,9 +418,6 @@ ramips_board_detect() {
*"R6220")
name="r6220"
;;
-   *"RB750Gr3")
-   name="rb750gr3"
-   ;;
*"RE350 v1")
name="re350-v1"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index ffdc5e73e0..59aca60ad0 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -129,7 +129,6 @@ platform_check_image() {
psr-680w|\
px-4885-4M|\
px-4885-8M|\
-   rb750gr3|\
re6500|\
rp-n53|\
rt5350f-olinuxino|\
diff --git a/target/linux/ramips/dts/RB750Gr3.dts 
b/target/linux/ramips/dts/RB750Gr3.dts
deleted file mode 100644
index dc359b10bb..00
--- a/target/linux/ramips/dts/RB750Gr3.dts
+++ /dev/null
@@ -1,125 +0,0 @@
-/dts-v1/;
-
-#include "mt7621.dtsi"
-
-#include 
-#include 
-
-/ {
-   compatible = "mikrotik,rb750gr3", "mediatek,mt7621-soc";
-   model = "MikroTik RB750Gr3";
-
-   memory@0 {
-   device_type = "memory";
-   reg = <0x0 0x1000>;
-   };
-
-   chosen {
-   bootargs = "console=ttyS0,57600";
-   };
-
-   gpio-leds {
-   compatible = "gpio-leds";
-
-   pwr {
-   label = "rb750gr3:blue:pwr";
-   gpios = < 16 GPIO_ACTIVE_HIGH>;
-   };
-
-   usr {
-   label = "rb750gr3:green:usr";
-   gpios = < 0 GPIO_ACTIVE_HIGH>;
-   };
-   };
-
-   gpio-keys-polled {
-   compatible = "gpio-keys-polled";
-   #address-cells = <1>;
-   #size-cells = <0>;
-   poll-interval = <20>;
-
-   mode {
-   label = "mode";
-   gpios = < 13 GPIO_ACTIVE_LOW>;
-   linux,code = ;
-   };
-
-   res {
-   label = "res";
-   gpios = < 18 GPIO_ACTIVE_LOW>;
-   linux,code = ;
-   };
-   };
-
-   gpio_export {
-   compatible = "gpio-export";
-   #size-cells = <0>;
-
-   buzzer {
-   gpio-export,name = "buzzer";
-   gpio-export,output = <0>;
-   gpios = < 15 GPIO_ACTIVE_HIGH>;
-   };
-
-   usb {
-   gpio-export,name = "usb";
-   gpio-export,output = <1>;
-   gpios = < 12 GPIO_ACTIVE_HIGH>;
-   };
-   };
-};
-
- {
-   status = "okay";
-
-   m25p80@0 {
-   #address-cells = <1>;
-   #size-cells = <1>;
-   compatible = "jedec,spi-nor";
-   reg = <0>;
-   spi-max-frequency = <1000>;
-   m25p,chunked-io = <32>;
-
-   partition@0 {
-   label = "u-boot";
-   reg = <0x0 0x3>;
-   read-only;
-   };
-
-   partition@3 {
-   label = "u-boot-env";
-   reg = <0x3 0x1>;
-   read-only;
-   };
-
-   factory: partition@4 {
-   label = "factory";
-

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

2018-07-19 Thread Thibaut VARÈNE 
This patch improves 5684d087418d176cfdef4e045e1950ca7ba3b09f 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 OEM source code also define a "fake" partition at the beginning of
the secondary flash chip: to avoid trouble if OEM ever make use of that
space, we define it here.

The resulting partition scheme looks like this:
[2.355095] Creating 6 MTD partitions on "spi0.0":
[2.359872] 0x-0x0004 : "RouterBoot"
[2.366197] 0x-0xf000 : "routerboot"
[2.372437] 0xf000-0x0001 : "hard_config"
[2.378818] 0x0001-0x0001f000 : "routerboot2"
[2.385200] 0x0002-0x00021000 : "soft_config"
[2.391503] 0x0003-0x00031000 : "bios"
[2.419283] Creating 2 MTD partitions on "spi0.1":
[2.424062] 0x-0x0004 : "RouterBootFake"
[2.430717] 0x0004-0x0100 : "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.
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 
Signed-off-by: Thibaut VARÈNE 
---
 target/linux/ramips/dts/RBM33G.dts | 64 +-
 1 file changed, 50 insertions(+), 14 deletions(-)

diff --git a/target/linux/ramips/dts/RBM33G.dts 
b/target/linux/ramips/dts/RBM33G.dts
index cc6da267a2..e1de3c8c11 100644
--- a/target/linux/ramips/dts/RBM33G.dts
+++ b/target/linux/ramips/dts/RBM33G.dts
@@ -7,7 +7,7 @@
 
 / {
compatible = "mikrotik,rbm33g", "mediatek,mt7621-soc";
-   model = "MikroTik RBM33G";
+   model = "MikroTik RouterBOARD M33G";
 
aliases {
led-status = _usr;
@@ -39,7 +39,7 @@
poll-interval = <20>;
 
res {
-   label = "res";
+   label = "reset";
gpios = < 18 GPIO_ACTIVE_LOW>;
linux,code = ;
};
@@ -69,6 +69,7 @@
regulator-always-on;
};
 
+   // not defined in OEM source, this controls the M.2 slot
pcie2_vcc_reg {
compatible = "regulator-fixed";
regulator-name = "pcie2_vcc";
@@ -104,18 +105,42 @@
reg = <0>;
spi-max-frequency = <3125000>;
 
-   partition@0 {
-   label = "routerboot";
-   reg = <0x0 0xf000>;
-   read-only;
-   };
-
-   factory: partition@f000 {
-   label = "factory";
-   reg = <0xf000 0x71000>;
-   read-only;
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   partition@0 {
+   label = "RouterBoot";
+   reg = <0x0 0x4>;
+   read-only;
+   };
+
+   routerboot@0 {
+   reg = <0x0 0xf000>;
+   read-only;
+   };
+
+   hard_config: hard_config@f000 {
+   reg = <0xf000 0x1000>;
+   read-only;
+   };
+
+   routerboot2@1 {
+   reg = <0x1 0xf000>;
+   read-only;
+   };
+
+   soft_config@2 {
+   reg = <0x2 0x1000>;
+   };
+
+   // valid data only extends up to 0x4f but make it 
0x1000 to match ar71xx
+   bios@3 {
+   reg = <0x3 0x1000>;
+   read-only;
+   };
};
-
};
 
w25q128@0 {
@@ -123,8 +148,16 @@
#size-cells = <1>;
compatible = "jedec,spi-nor";
reg = <1>;
+   // XXX empiric value to obtain actual 10MHz SCK at the chip 
spi-max-frequency = <3125000>;
 
+   // this contains no data but is defined in OEM source
+   partition@0 {
+   label = "RouterBootFake";
+   reg = <0x0 0x4>;
+   read-only;
+   };
+

[OpenWrt-Devel] [PATCH 0/2] ramips: fix RBMxxG name and partitionning

2018-07-19 Thread Thibaut VARÈNE 
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 0x4 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@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

2018-07-19 Thread Thibaut VARÈNE 
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] 0x-0x0004 : "RouterBoot"
[2.488948] 0x-0xf000 : "routerboot"
[2.495289] 0xf000-0x0001 : "hard_config"
[2.501596] 0x0001-0x0001f000 : "routerboot2"
[2.507966] 0x0002-0x00021000 : "soft_config"
[2.514307] 0x0003-0x00031000 : "bios"
[2.520108] 0x0004-0x0100 : "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.
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 
Signed-off-by: Thibaut VARÈNE 
---
 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";
 
aliases {
led-status = _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@0 {
-   label = "routerboot";
-   reg = <0x00 0x00F000>;
-   read-only;
-   };
-
-   factory: partition@f000 {
-   label = "factory";
-   reg = <0x00F000 0x031000>;
-   read-only;
-   };
-
-   partition@4 {
-   label = "firmware";
-   reg = <0x04 0xFC>;
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   partition@0 {
+   label = "RouterBoot";
+   reg = <0x0 0x4>;
+   read-only;
+   };
+
+   routerboot@0 {
+   reg = <0x0 0xf000>;
+   read-only;
+   };
+
+   hard_config: hard_config@f000 {
+   reg = <0xf000 0x1000>;
+   read-only;
+   };
+
+   routerboot2@1 {
+   reg = <0x1 0xf000>;
+   read-only;
+   };
+
+   soft_config@2 {
+   reg = <0x2 0x1000>;
+   };
+
+   // valid data only extends up to 0x4f but make it 
0x1000 to match ar71xx
+   bios@3 {
+   reg = <0x3 0x1000>;
+   read-only;
+   };
+
+   firmware@4 {
+   reg = <0x04 0xFC>;
+   };
};
};
 };
 
  {
-   mtd-mac-address = < 0x0010>;
+   mtd-mac-address = <_config 0x0010>;
mtd-mac-address-increment = <1>;
 };
 
@@ -133,3 +158,6 @@
  {
status = "okay";
 };
+
+// XXX this device has hardware crypto
+// {};
-- 
2.14.3 (Apple Git-98)


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/3] kernel: handle bad blocks in ubi auto attach code

2018-07-19 Thread Mathias Kresin 
The first block(s) of the ubi mtd device might be bad. We need to take
care on our own to skip the bad block(s) and read the next one(s).

Don't treat recoverable read errors as fatal and check for the UBI magic
if the data of a block could be recovered using ECC or similar.

Signed-off-by: Mathias Kresin 
---
 ...tach-mtd-device-named-ubi-or-data-on-boot.patch | 22 ++
 ...tach-mtd-device-named-ubi-or-data-on-boot.patch | 22 ++
 2 files changed, 36 insertions(+), 8 deletions(-)

diff --git 
a/target/linux/generic/pending-4.14/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
 
b/target/linux/generic/pending-4.14/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
index 83b0c72..b6890e3 100644
--- 
a/target/linux/generic/pending-4.14/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
+++ 
b/target/linux/generic/pending-4.14/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
@@ -8,7 +8,7 @@ Signed-off-by: Daniel Golle 
 
 --- a/drivers/mtd/ubi/build.c
 +++ b/drivers/mtd/ubi/build.c
-@@ -1171,6 +1171,53 @@ static struct mtd_info * __init open_mtd
+@@ -1171,6 +1171,67 @@ static struct mtd_info * __init open_mtd
return mtd;
  }
  
@@ -20,6 +20,7 @@ Signed-off-by: Daniel Golle 
 +{
 +  int err;
 +  struct mtd_info *mtd;
++  loff_t offset = 0;
 +  size_t len;
 +  char magic[4];
 +
@@ -31,9 +32,22 @@ Signed-off-by: Daniel Golle 
 +  if (IS_ERR(mtd))
 +  return;
 +
++  /* get the first not bad block */
++  if (mtd_can_have_bb(mtd))
++  while (mtd_block_isbad(mtd, offset)) {
++  offset += mtd->erasesize;
++
++  if (offset > mtd->size) {
++  pr_err("UBI error: Failed to find a non-bad "
++ "block on mtd%d\n", mtd->index);
++  goto cleanup;
++  }
++  }
++
 +  /* check for a valid ubi magic if read from flash was successful */
-+  err = mtd_read(mtd, 0, 4, , (void *) magic);
-+  if (!err && len == 4 && strncmp(magic, "UBI#", 4)) {
++  err = mtd_read(mtd, offset, 4, , (void *) magic);
++  if ((!err || mtd_is_bitflip(err)) &&
++  len == 4 && strncmp(magic, "UBI#", 4)) {
 +  pr_err("UBI error: no valid UBI magic found inside mtd%d\n", 
mtd->index);
 +  goto cleanup;
 +  }
@@ -62,7 +76,7 @@ Signed-off-by: Daniel Golle 
  static int __init ubi_init(void)
  {
int err, i, k;
-@@ -1254,6 +1301,12 @@ static int __init ubi_init(void)
+@@ -1254,6 +1315,12 @@ static int __init ubi_init(void)
}
}
  
diff --git 
a/target/linux/generic/pending-4.9/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
 
b/target/linux/generic/pending-4.9/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
index d6585b1..4051a01 100644
--- 
a/target/linux/generic/pending-4.9/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
+++ 
b/target/linux/generic/pending-4.9/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
@@ -8,7 +8,7 @@ Signed-off-by: Daniel Golle 
 
 --- a/drivers/mtd/ubi/build.c
 +++ b/drivers/mtd/ubi/build.c
-@@ -1226,6 +1226,53 @@ static struct mtd_info * __init open_mtd
+@@ -1226,6 +1226,67 @@ static struct mtd_info * __init open_mtd
return mtd;
  }
  
@@ -20,6 +20,7 @@ Signed-off-by: Daniel Golle 
 +{
 +  int err;
 +  struct mtd_info *mtd;
++  loff_t offset = 0;
 +  size_t len;
 +  char magic[4];
 +
@@ -31,9 +32,22 @@ Signed-off-by: Daniel Golle 
 +  if (IS_ERR(mtd))
 +  return;
 +
++  /* get the first not bad block */
++  if (mtd_can_have_bb(mtd))
++  while (mtd_block_isbad(mtd, offset)) {
++  offset += mtd->erasesize;
++
++  if (offset > mtd->size) {
++  pr_err("UBI error: Failed to find a non-bad "
++ "block on mtd%d\n", mtd->index);
++  goto cleanup;
++  }
++  }
++
 +  /* check for a valid ubi magic if read from flash was successful */
-+  err = mtd_read(mtd, 0, 4, , (void *) magic);
-+  if (!err && len == 4 && strncmp(magic, "UBI#", 4)) {
++  err = mtd_read(mtd, offset, 4, , (void *) magic);
++  if ((!err || mtd_is_bitflip(err)) &&
++  len == 4 && strncmp(magic, "UBI#", 4)) {
 +  pr_err("UBI error: no valid UBI magic found inside mtd%d\n", 
mtd->index);
 +  goto cleanup;
 +  }
@@ -62,7 +76,7 @@ Signed-off-by: Daniel Golle 
  static int __init ubi_init(void)
  {
int err, i, k;
-@@ -1309,6 +1356,12 @@ static int __init ubi_init(void)
+@@ -1309,6 +1370,12 @@ static int __init ubi_init(void)
}
}
  
-- 
2.7.4


___
openwrt-devel mailing list

[OpenWrt-Devel] [PATCH 1/3] kernel: improve ubi auto attach code readability

2018-07-19 Thread Mathias Kresin 
The early return on failed open of the mtd device allows to get rid of
one level of indentation.

Move the put_mtd_device() called on multiple error conditions to a goto
label to use it later for more error conditions.

While at it, make clear that we only check for the UBI magic if the read
from flash was successful.

Signed-off-by: Mathias Kresin 
---
 ...tach-mtd-device-named-ubi-or-data-on-boot.patch | 54 --
 ...tach-mtd-device-named-ubi-or-data-on-boot.patch | 54 --
 2 files changed, 58 insertions(+), 50 deletions(-)

diff --git 
a/target/linux/generic/pending-4.14/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
 
b/target/linux/generic/pending-4.14/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
index 63afabb..83b0c72 100644
--- 
a/target/linux/generic/pending-4.14/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
+++ 
b/target/linux/generic/pending-4.14/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
@@ -8,7 +8,7 @@ Signed-off-by: Daniel Golle 
 
 --- a/drivers/mtd/ubi/build.c
 +++ b/drivers/mtd/ubi/build.c
-@@ -1171,6 +1171,49 @@ static struct mtd_info * __init open_mtd
+@@ -1171,6 +1171,53 @@ static struct mtd_info * __init open_mtd
return mtd;
  }
  
@@ -20,45 +20,49 @@ Signed-off-by: Daniel Golle 
 +{
 +  int err;
 +  struct mtd_info *mtd;
++  size_t len;
++  char magic[4];
 +
 +  /* try attaching mtd device named "ubi" or "data" */
 +  mtd = open_mtd_device("ubi");
 +  if (IS_ERR(mtd))
 +  mtd = open_mtd_device("data");
 +
-+  if (!IS_ERR(mtd)) {
-+  size_t len;
-+  char magic[4];
++  if (IS_ERR(mtd))
++  return;
 +
-+  /* check for a valid ubi magic */
-+  err = mtd_read(mtd, 0, 4, , (void *) magic);
-+  if (!err && len == 4 && strncmp(magic, "UBI#", 4)) {
-+  pr_err("UBI error: no valid UBI magic found inside 
mtd%d\n", mtd->index);
-+  put_mtd_device(mtd);
-+  return;
-+  }
++  /* check for a valid ubi magic if read from flash was successful */
++  err = mtd_read(mtd, 0, 4, , (void *) magic);
++  if (!err && len == 4 && strncmp(magic, "UBI#", 4)) {
++  pr_err("UBI error: no valid UBI magic found inside mtd%d\n", 
mtd->index);
++  goto cleanup;
++  }
 +
-+  /* auto-add only media types where UBI makes sense */
-+  if (mtd->type == MTD_NANDFLASH ||
-+  mtd->type == MTD_NORFLASH ||
-+  mtd->type == MTD_DATAFLASH ||
-+  mtd->type == MTD_MLCNANDFLASH) {
-+  mutex_lock(_devices_mutex);
-+  pr_notice("UBI: auto-attach mtd%d\n", mtd->index);
-+  err = ubi_attach_mtd_dev(mtd, UBI_DEV_NUM_AUTO, 0, 0);
-+  mutex_unlock(_devices_mutex);
-+  if (err < 0) {
-+  pr_err("UBI error: cannot attach mtd%d\n", 
mtd->index);
-+  put_mtd_device(mtd);
-+  }
++  /* auto-add only media types where UBI makes sense */
++  if (mtd->type == MTD_NANDFLASH ||
++  mtd->type == MTD_NORFLASH ||
++  mtd->type == MTD_DATAFLASH ||
++  mtd->type == MTD_MLCNANDFLASH) {
++  mutex_lock(_devices_mutex);
++  pr_notice("UBI: auto-attach mtd%d\n", mtd->index);
++  err = ubi_attach_mtd_dev(mtd, UBI_DEV_NUM_AUTO, 0, 0);
++  mutex_unlock(_devices_mutex);
++  if (err < 0) {
++  pr_err("UBI error: cannot attach mtd%d\n", mtd->index);
++  goto cleanup;
 +  }
 +  }
++
++  return;
++
++cleanup:
++  put_mtd_device(mtd);
 +}
 +
  static int __init ubi_init(void)
  {
int err, i, k;
-@@ -1254,6 +1297,12 @@ static int __init ubi_init(void)
+@@ -1254,6 +1301,12 @@ static int __init ubi_init(void)
}
}
  
diff --git 
a/target/linux/generic/pending-4.9/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
 
b/target/linux/generic/pending-4.9/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
index 8b37dba..d6585b1 100644
--- 
a/target/linux/generic/pending-4.9/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
+++ 
b/target/linux/generic/pending-4.9/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
@@ -8,7 +8,7 @@ Signed-off-by: Daniel Golle 
 
 --- a/drivers/mtd/ubi/build.c
 +++ b/drivers/mtd/ubi/build.c
-@@ -1226,6 +1226,49 @@ static struct mtd_info * __init open_mtd
+@@ -1226,6 +1226,53 @@ static struct mtd_info * __init open_mtd
return mtd;
  }
  
@@ -20,45 +20,49 @@ Signed-off-by: Daniel Golle 
 +{
 +  int err;
 +  struct mtd_info *mtd;
++  size_t len;
++  char magic[4];
 +
 +  /* try attaching mtd device named

[OpenWrt-Devel] [PATCH 3/3] kernel: don't auto attach ubi on read error

2018-07-19 Thread Mathias Kresin 
With a10a204aab26cc ("kernel: make ubi auto-attach check for a tar file
magic") the check for the magic was added without considering a failing
mtd_read(). If the read fails, no check is done and the mount code is
called straight away.

Failing with an error message for such cases seems to me the cleaner way,
as it would allow to spot hidden/workaround issues.

Signed-off-by: Mathias Kresin 
---
 ...auto-attach-mtd-device-named-ubi-or-data-on-boot.patch | 15 ++-
 ...auto-attach-mtd-device-named-ubi-or-data-on-boot.patch | 15 ++-
 2 files changed, 20 insertions(+), 10 deletions(-)

diff --git 
a/target/linux/generic/pending-4.14/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
 
b/target/linux/generic/pending-4.14/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
index b6890e3..ae93d12 100644
--- 
a/target/linux/generic/pending-4.14/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
+++ 
b/target/linux/generic/pending-4.14/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
@@ -8,7 +8,7 @@ Signed-off-by: Daniel Golle 
 
 --- a/drivers/mtd/ubi/build.c
 +++ b/drivers/mtd/ubi/build.c
-@@ -1171,6 +1171,67 @@ static struct mtd_info * __init open_mtd
+@@ -1171,6 +1171,72 @@ static struct mtd_info * __init open_mtd
return mtd;
  }
  
@@ -44,10 +44,15 @@ Signed-off-by: Daniel Golle 
 +  }
 +  }
 +
-+  /* check for a valid ubi magic if read from flash was successful */
++  /* check if the read from flash was successful */
 +  err = mtd_read(mtd, offset, 4, , (void *) magic);
-+  if ((!err || mtd_is_bitflip(err)) &&
-+  len == 4 && strncmp(magic, "UBI#", 4)) {
++  if ((err && !mtd_is_bitflip(err)) || len != 4) {
++  pr_err("UBI error: unable to read from mtd%d\n", mtd->index);
++  goto cleanup;
++  }
++
++  /* check for a valid ubi magic */
++  if (strncmp(magic, "UBI#", 4)) {
 +  pr_err("UBI error: no valid UBI magic found inside mtd%d\n", 
mtd->index);
 +  goto cleanup;
 +  }
@@ -76,7 +81,7 @@ Signed-off-by: Daniel Golle 
  static int __init ubi_init(void)
  {
int err, i, k;
-@@ -1254,6 +1315,12 @@ static int __init ubi_init(void)
+@@ -1254,6 +1320,12 @@ static int __init ubi_init(void)
}
}
  
diff --git 
a/target/linux/generic/pending-4.9/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
 
b/target/linux/generic/pending-4.9/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
index 4051a01..8ce508e 100644
--- 
a/target/linux/generic/pending-4.9/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
+++ 
b/target/linux/generic/pending-4.9/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch
@@ -8,7 +8,7 @@ Signed-off-by: Daniel Golle 
 
 --- a/drivers/mtd/ubi/build.c
 +++ b/drivers/mtd/ubi/build.c
-@@ -1226,6 +1226,67 @@ static struct mtd_info * __init open_mtd
+@@ -1226,6 +1226,72 @@ static struct mtd_info * __init open_mtd
return mtd;
  }
  
@@ -44,10 +44,15 @@ Signed-off-by: Daniel Golle 
 +  }
 +  }
 +
-+  /* check for a valid ubi magic if read from flash was successful */
++  /* check if the read from flash was successful */
 +  err = mtd_read(mtd, offset, 4, , (void *) magic);
-+  if ((!err || mtd_is_bitflip(err)) &&
-+  len == 4 && strncmp(magic, "UBI#", 4)) {
++  if ((err && !mtd_is_bitflip(err)) || len != 4) {
++  pr_err("UBI error: unable to read from mtd%d\n", mtd->index);
++  goto cleanup;
++  }
++
++  /* check for a valid ubi magic */
++  if (strncmp(magic, "UBI#", 4)) {
 +  pr_err("UBI error: no valid UBI magic found inside mtd%d\n", 
mtd->index);
 +  goto cleanup;
 +  }
@@ -76,7 +81,7 @@ Signed-off-by: Daniel Golle 
  static int __init ubi_init(void)
  {
int err, i, k;
-@@ -1309,6 +1370,12 @@ static int __init ubi_init(void)
+@@ -1309,6 +1375,12 @@ static int __init ubi_init(void)
}
}
  
-- 
2.7.4


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ramips: define common MikroTik RouterBOARD image recipe

2018-07-19 Thread Thibaut VARÈNE 
All these devices share the exact same image format.

Signed-off-by: Thibaut VARÈNE 
---
 target/linux/ramips/image/mt7621.mk | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/target/linux/ramips/image/mt7621.mk 
b/target/linux/ramips/image/mt7621.mk
index fa87e40520..8ac78ad7de 100644
--- a/target/linux/ramips/image/mt7621.mk
+++ b/target/linux/ramips/image/mt7621.mk
@@ -260,11 +260,9 @@ define Device/rb750gr3
 endef
 TARGET_DEVICES += rb750gr3
 
-define Device/mikrotik_rbm33g
-  DTS := RBM33G
+define Device/MikroTik
   BLOCKSIZE := 64k
   IMAGE_SIZE := 16128k
-  DEVICE_TITLE := MikroTik RBM33G
   DEVICE_PACKAGES := kmod-usb3
   LOADER_TYPE := elf
   PLATFORM := mt7621
@@ -272,18 +270,18 @@ define Device/mikrotik_rbm33g
   IMAGE/sysupgrade.bin := append-kernel | kernel2minor -s 1024 | pad-to 
(BLOCKSIZE) | \
append-rootfs | pad-rootfs | append-metadata | check-size 
(IMAGE_SIZE)
 endef
+
+define Device/mikrotik_rbm33g
+  $(Device/MikroTik)
+  DTS := RBM33G
+  DEVICE_TITLE := MikroTik RouterBOARD M33G
+endef
 TARGET_DEVICES += mikrotik_rbm33g
 
 define Device/mikrotik_rbm11g
+  $(Device/MikroTik)
   DTS := RBM11G
-  BLOCKSIZE := 64k
-  IMAGE_SIZE := 16128k
-  DEVICE_TITLE := MikroTik RBM11G
-  LOADER_TYPE := elf
-  PLATFORM := mt7621
-  KERNEL := kernel-bin | patch-dtb | lzma | loader-kernel
-  IMAGE/sysupgrade.bin := append-kernel | kernel2minor -s 1024 | pad-to 
(BLOCKSIZE) | \
-   append-rootfs | pad-rootfs | append-metadata | check-size 
(IMAGE_SIZE)
+  DEVICE_TITLE := MikroTik RouterBOARD M11G
 endef
 TARGET_DEVICES += mikrotik_rbm11g
 
-- 
2.14.3 (Apple Git-98)


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [18.06] ramips: remove RB750GR3 support

2018-07-19 Thread Thibaut 
Detailed rationale:
• This code should never have been accepted: it should certainly not be part of 
a release and if it accidentally was part of one that should absolutely not be 
reason to continue what is IMO a mistake.
• This code does not support the stock hardware
• This code is a maintenance burden (it's a custom hack, in essence)
• This code will induce confusion with end user when the new code is introduced
• There will be no upgrade path between this code and the new support

Assuming there’s more than a single user for this code (which I doubt 
considering the wiki suggests using an SPI flash programmer to install), the 
supplementary rationale from my point of view is thus precisely to break the 
support chain and make it perfectly clear that current “support" stops in 18.06 
without what could be taken as a sign of a transition ("oh, image has changed 
name but it should still be the right one"): old support in 17, nothing in 18, 
new support in 19: clean break.

No replacement is proposed since no such a thing can exist: stock hw uses a 
different bootloader (routerboot) which expects a different image format, and 
uses an incompatible mtd flash partitioning.



0001-ramips-remove-RB750GR3-support.patch
Description: Binary data
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] lede-imagebuilder-17.01.5-ar71xx-generic.Linux-x86_64 fails to build image

2018-07-19 Thread Mikael Bak 

Hi,

On 2018-07-19 08:49, Jo-Philipp Wich wrote:

Hi again,

As a workaround, run the following command once within the IB/SDK directory:

sed -i -e 's,/\(usr\|lib\|etc\)/,/###/,g' ./staging_dir/host/lib/libc.so.6



Executing the above command solves the problem on my system (Manjaro - 
similar to Arch).




This will prevent the bundled glibc from trying to dlopen() libraries on
the host system which is the root cause of the assertion.



Thank you very much for the quick workaround!

Is it generally recommended to use Debian or Ubuntu for building images? 
I do not have to use Manjaro for that if it's difficult for the project 
to support it.


Cheers,
Mikael

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] lede-imagebuilder-17.01.5-ar71xx-generic.Linux-x86_64 fails to build image

2018-07-19 Thread Jo-Philipp Wich 
Hi again,

As a workaround, run the following command once within the IB/SDK directory:

sed -i -e 's,/\(usr\|lib\|etc\)/,/###/,g' ./staging_dir/host/lib/libc.so.6


This will prevent the bundled glibc from trying to dlopen() libraries on
the host system which is the root cause of the assertion.

~ Jo




signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] lede-imagebuilder-17.01.5-ar71xx-generic.Linux-x86_64 fails to build image

2018-07-19 Thread Jo-Philipp Wich 
Hi,

works for me on Debian 9 und Ubuntu 18. I've got reports that it is
broken on Arch which I am currently trying to install but it seems to be
a pain

~ Jo



signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel