[LEDE-DEV] ramips: add support for Loewe WMDR-143N

The WMDR-143N is a small module originally used as a Wifi client
in some Loewe smart TV sets. It is sold cheaply at german surplus
shops. The module contains a RT3662 SOC.

Specifications:

- 500 MHz CPU Clock
- 1x 10/100Mbps Ethernet (pin header)
- 32 MB of RAM
- 8 MB of FLASH
- 2T3R 2.4/5 GHz (SOC internal)
- 3 Antennas on PCB
- UART pads on PCB (J3: 1 = +5V, 2 = RX, 3 = TX, 4 = GND), TX and
  RX are 3,3V only! The square hole is pin 1
- Power supply pads on PCB (J6: 1 and 2 = +5V, 3 and 4 = GND)
  The square hole is pin 1

The original firmware has two identical kernel/rootfs images and
two "Factory" calibration data blocks in flash. The LEDE image
leaves only the first "Factory" block in place and uses both
"Kernel" blocks and the redundant "Factory" block together to gain
enough space for the jffs2 partition.

Flash instructions:

You need UART and Ethernet connections to flash the board. Use
the LEDE "factory" image with tftp.

Apply power to the board and in the first 5 seconds, hit 2 to
select TFTP upload. The bootloader asks for board- and server IP
addresses and filename.

Alternate method: With the vendor firmware running, assign an IP
address to the ethernet port, tftp the firmware image to
/tmp and write to mtd4 ("KernelA").

Signed-off-by: Oliver Fleischmann <ogf@bnv-bamberg.de>
---
 .../linux/ramips/base-files/etc/board.d/02_network |  4 +-
 target/linux/ramips/base-files/lib/ramips.sh       |  3 +
 .../ramips/base-files/lib/upgrade/platform.sh      |  1 +
 target/linux/ramips/dts/WMDR-143N.dts              | 82 ++++++++++++++++++++++
 target/linux/ramips/image/rt3883.mk                | 14 ++++
 5 files changed, 103 insertions(+), 1 deletion(-)
 create mode 100644 target/linux/ramips/dts/WMDR-143N.dts

Hey Oliver,

thanks a lot for your patch. Find my comments inline.

2017-07-17 20:20 GMT+02:00 Oliver Fleischmann <ogf@bnv-bamberg.de>:
> The WMDR-143N is a small module originally used as a Wifi client
> in some Loewe smart TV sets. It is sold cheaply at german surplus
> shops. The module contains a RT3662 SOC.
>
> Specifications:
>
> - 500 MHz CPU Clock
> - 1x 10/100Mbps Ethernet (pin header)
> - 32 MB of RAM
> - 8 MB of FLASH
> - 2T3R 2.4/5 GHz (SOC internal)
> - 3 Antennas on PCB
> - UART pads on PCB (J3: 1 = +5V, 2 = RX, 3 = TX, 4 = GND), TX and
>   RX are 3,3V only! The square hole is pin 1
> - Power supply pads on PCB (J6: 1 and 2 = +5V, 3 and 4 = GND)
>   The square hole is pin 1
>
> The original firmware has two identical kernel/rootfs images and
> two "Factory" calibration data blocks in flash. The LEDE image
> leaves only the first "Factory" block in place and uses both
> "Kernel" blocks and the redundant "Factory" block together to gain
> enough space for the jffs2 partition.
>
> Flash instructions:
>
> You need UART and Ethernet connections to flash the board. Use
> the LEDE "factory" image with tftp.
>
> Apply power to the board and in the first 5 seconds, hit 2 to
> select TFTP upload. The bootloader asks for board- and server IP
> addresses and filename.
>
> Alternate method: With the vendor firmware running, assign an IP
> address to the ethernet port, tftp the firmware image to
> /tmp and write to mtd4 ("KernelA").
>
> Signed-off-by: Oliver Fleischmann <ogf@bnv-bamberg.de>
> ---
>  .../linux/ramips/base-files/etc/board.d/02_network |  4 +-
>  target/linux/ramips/base-files/lib/ramips.sh       |  3 +
>  .../ramips/base-files/lib/upgrade/platform.sh      |  1 +
>  target/linux/ramips/dts/WMDR-143N.dts              | 82 ++++++++++++++++++++++
>  target/linux/ramips/image/rt3883.mk                | 14 ++++
>  5 files changed, 103 insertions(+), 1 deletion(-)
>  create mode 100644 target/linux/ramips/dts/WMDR-143N.dts

[snip]

> diff --git a/target/linux/ramips/dts/WMDR-143N.dts b/target/linux/ramips/dts/WMDR-143N.dts
> new file mode 100644
> index 0000000000..66db0c8ea8
> --- /dev/null
> +++ b/target/linux/ramips/dts/WMDR-143N.dts
> @@ -0,0 +1,82 @@
> +/dts-v1/;
> +
> +#include "rt3883.dtsi"
> +
> +#include <dt-bindings/input/input.h>

You can drop this include. You don't have any input devices (buttons)
in your dts.

> +
> +/ {
> +       compatible = "WMDR-143N", "ralink,rt3883-soc";

should be: compatible = "loewe,wmdr-143n", "ralink,rt3883-soc";

> +       model = "Loewe WMDR-143N";
> +};
> +
> +&spi0 {
> +        status = "okay";
> +
> +        m25p80@0 {
> +                #address-cells = <1>;
> +                #size-cells = <1>;
> +                compatible = "jedec,spi-nor";
> +                reg = <0>;
> +                spi-max-frequency = <25000000>;
> +
> +                partition@0 {
> +                        label = "u-boot";
> +                        reg = <0x0 0x30000>;
> +                        read-only;
> +                };
> +
> +                partition@30000 {
> +                        label = "u-boot-env";
> +                        reg = <0x30000 0x00010000>;
> +                        read-only;
> +                };
> +
> +                factory: partition@40000 {
> +                        label = "factory";
> +                        reg = <0x40000 0x10000>;
> +                        read-only;
> +                };
> +
> +                partition@50000 {
> +                        label = "firmware";
> +                        reg = <0x50000 0x7b0000>;
> +                };
> +        };
> +};
> +
> +&gpio1 {
> +       status = "okay";
> +};

The gpio1 node can be dropped. None of the SoC pins are used as GPIOs
for this board.

> +
> +&pinctrl {
> +       state_default: pinctrl0 {
> +               gpio {
> +                       ralink,group = "i2c", "jtag", "uartf";
> +                       ralink,function = "gpio";
> +               };
> +       };
> +};

Same as above. None if the pins in these groups are used as GPIO.

> +
> +&ethernet {
> +       mtd-mac-address = <&factory 0x4>;
> +
> +       port@0 {
> +               phy-handle = <&phy0>;
> +               phy-mode = "mii";
> +       };
> +       mdio-bus {
> +               status = "okay";
> +
> +               phy0: ethernet-phy@0 {
> +                       reg = <0>;
> +                       phy-mode = "mii";
> +               };
> +       };
> +};
> +
> +&wmac {
> +       status = "okay";
> +       ralink,mtd-eeprom = <&factory 0>;
> +       mtd-mac-address = <&factory 0x4>;
> +       mtd-mac-address-increment = <1>;

Have you validated against the original firmware that wireless and
ethernet have different mac addresses? Is it the wireless mac address
that is incremented? I'm somehow in doubt here, since there is no
ethernet by default for this board.

> +};
> diff --git a/target/linux/ramips/image/rt3883.mk b/target/linux/ramips/image/rt3883.mk
> index 2cd60f3858..c21a2cad1b 100644
> --- a/target/linux/ramips/image/rt3883.mk
> +++ b/target/linux/ramips/image/rt3883.mk
> @@ -114,3 +114,17 @@ define Device/wlr-6000
>    DEVICE_PACKAGES := kmod-usb-core kmod-usb-ohci kmod-usb2 swconfig
>  endef
>  TARGET_DEVICES += wlr-6000
> +
> +
> +define Device/wmdr-143n
> +  DTS := WMDR-143N
> +  BLOCKSIZE := 64k
> +  IMAGES += factory.bin

It seams to me a factory image isn't required for this board. The
sysupgrade.bin should work fine for the initial installation.

> +  IMAGE/sysupgrade.bin := \
> +       append-kernel | append-rootfs | pad-rootfs | append-metadata | check-size $$$$(IMAGE_SIZE)

Drop this line, it is identical to the defaults defined in
target/linux/ramips/image/Makefile.

> +  IMAGE/factory.bin := \
> +       append-kernel | append-rootfs | pad-rootfs | check-size $$$$(IMAGE_SIZE)

See my factory.bin remarks above.

> +  DEVICE_TITLE := Loewe WMDR-143N
> +  DEVICE_PACKAGES :=

Drop this line, it is the default to not include any device packages.

Mathias

Hello Mathias,

many thanks for your review!

>> +#include "rt3883.dtsi"
>> +
>> +#include <dt-bindings/input/input.h>
>
> You can drop this include. You don't have any input devices (buttons)
> in your dts.

OK, I will change that for my next attempt.

>> +
>> +/ {
>> +       compatible = "WMDR-143N", "ralink,rt3883-soc";
>
> should be: compatible = "loewe,wmdr-143n", "ralink,rt3883-soc";

OK.

>> +&gpio1 {
>> +       status = "okay";
>> +};
>
> The gpio1 node can be dropped. None of the SoC pins are used as GPIOs
> for this board.

OK.

>> +&pinctrl {
>> +       state_default: pinctrl0 {
>> +               gpio {
>> +                       ralink,group = "i2c", "jtag", "uartf";
>> +                       ralink,function = "gpio";
>> +               };
>> +       };
>> +};
>
> Same as above. None if the pins in these groups are used as GPIO.

But if I remove this part, the kernel hangs during boot reproducibly:

(...)
[    0.134508] clocksource: jiffies: mask: 0xffffffff max_cycles: 
0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.154048] futex hash table entries: 256 (order: -1, 3072 bytes)
[    0.166222] pinctrl core: initialized pinctrl subsystem
[    0.177541] NET: Registered protocol family 16

and gone. It doesn't matter if I leave all three groups or only one of 
them, but as soon as I remove them all, it hangs. So I'd prefer to keep 
this...

>> +&ethernet {
>> +       mtd-mac-address = <&factory 0x4>;
>> +
>> +       port@0 {
>> +               phy-handle = <&phy0>;
>> +               phy-mode = "mii";
>> +       };
>> +       mdio-bus {
>> +               status = "okay";
>> +
>> +               phy0: ethernet-phy@0 {
>> +                       reg = <0>;
>> +                       phy-mode = "mii";
>> +               };
>> +       };
>> +};
>> +
>> +&wmac {
>> +       status = "okay";
>> +       ralink,mtd-eeprom = <&factory 0>;
>> +       mtd-mac-address = <&factory 0x4>;
>> +       mtd-mac-address-increment = <1>;
>
> Have you validated against the original firmware that wireless and
> ethernet have different mac addresses? Is it the wireless mac address
> that is incremented? I'm somehow in doubt here, since there is no
> ethernet by default for this board.

With the original firmware, both interfaces do indeed have different mac
addresses. The wireless interface uses the one from the "Factory"
partition (e.g. F8:35:DD:C9:1B:19), not incremented (sorry).

The ethernet interface has a completely different address (e.g. 
00:0C:43:28:80:0F). I have no idea where it comes from, I can't find it in 
any of the configuration partitions wether in binary or in ASCII. It gets 
set by a kernel module (raeth.ko). In the hexdump of this binary module, I 
can find a part of this address (00 0c 43 28 80 00) hardcoded.

So I thought, just incrementing the given address for the second interface 
would do for the beginning. Do you have a suggestion for a better 
solution?

>> +define Device/wmdr-143n
>> +  DTS := WMDR-143N
>> +  BLOCKSIZE := 64k
>> +  IMAGES += factory.bin
>
> It seams to me a factory image isn't required for this board. The
> sysupgrade.bin should work fine for the initial installation.

I had some trouble during testing because of the metadata at the end of
the sysupgrade.bin image, but I will try again. Probably you are right :-)


Oliver

2017-07-18 21:15 GMT+02:00 Oliver Fleischmann <ogf@bnv-bamberg.de>:
>>> +&pinctrl {
>>> +       state_default: pinctrl0 {
>>> +               gpio {
>>> +                       ralink,group = "i2c", "jtag", "uartf";
>>> +                       ralink,function = "gpio";
>>> +               };
>>> +       };
>>> +};
>>
>> Same as above. None if the pins in these groups are used as GPIO.
>
> But if I remove this part, the kernel hangs during boot reproducibly:
>
> (...)
> [    0.134508] clocksource: jiffies: mask: 0xffffffff max_cycles:
> 0xffffffff, max_idle_ns: 19112604462750000 ns
> [    0.154048] futex hash table entries: 256 (order: -1, 3072 bytes)
> [    0.166222] pinctrl core: initialized pinctrl subsystem
> [    0.177541] NET: Registered protocol family 16
>
> and gone. It doesn't matter if I leave all three groups or only one of them,
> but as soon as I remove them all, it hangs. So I'd prefer to keep this...

I'm not entirely sure, but It rather looks like a (driver) bug to me.
If it is a bug, I prefer to see this bug fixed instead of adding not
required pinmuxes to workaround a possible bug.

>>> +&ethernet {
>>> +       mtd-mac-address = <&factory 0x4>;
>>> +
>>> +       port@0 {
>>> +               phy-handle = <&phy0>;
>>> +               phy-mode = "mii";
>>> +       };
>>> +       mdio-bus {
>>> +               status = "okay";
>>> +
>>> +               phy0: ethernet-phy@0 {
>>> +                       reg = <0>;
>>> +                       phy-mode = "mii";
>>> +               };
>>> +       };
>>> +};
>>> +
>>> +&wmac {
>>> +       status = "okay";
>>> +       ralink,mtd-eeprom = <&factory 0>;
>>> +       mtd-mac-address = <&factory 0x4>;
>>> +       mtd-mac-address-increment = <1>;
>>
>>
>> Have you validated against the original firmware that wireless and
>> ethernet have different mac addresses? Is it the wireless mac address
>> that is incremented? I'm somehow in doubt here, since there is no
>> ethernet by default for this board.
>
>
> With the original firmware, both interfaces do indeed have different mac
> addresses. The wireless interface uses the one from the "Factory"
> partition (e.g. F8:35:DD:C9:1B:19), not incremented (sorry).
>
> The ethernet interface has a completely different address (e.g.
> 00:0C:43:28:80:0F). I have no idea where it comes from, I can't find it in
> any of the configuration partitions wether in binary or in ASCII. It gets
> set by a kernel module (raeth.ko). In the hexdump of this binary module, I
> can find a part of this address (00 0c 43 28 80 00) hardcoded.
>
> So I thought, just incrementing the given address for the second interface
> would do for the beginning. Do you have a suggestion for a better solution?

00:0C:43 is the RaLink mac prefix and 00:0C:43:28:80:0F is set as
default mac address by the proprietary driver. Most likely it is the
same for all WMDR-143N boards.

Long story short, there is no designated mac address for the ethernet
interface and we should not use the incremented wireless mac address
for the ethernet interface. The resulting mac address might be used by
other boards. Just drop  mtd-mac-address* from the dts. This way a
random one is used. Not a perfect solution, but IMHO better than what
you have at the moment.

Alternatively, it would be possible to set 00:0C:43:28:80:0F for the
ethernet of all WMDR-143N boards by using

  mac-address = [ 00 0C 43 28 80 0F ];

in the dts. Use whatever you prefer.

Mathias