[PATCH] ARM: dts: sun7i: Add dts file for the lamobo-r1 board

[Hans de Goede]

From: Jelle de Jong <jelle...@powercraft.nl>

The lamobo-r1 board, sometimes called the BPI-R1 but not labelled as such
on the PCB, is meant as a A20 based router board. As such the board comes
with a built-in switch chip giving it 5 gigabit ethernet boards, and it
has a large empty area on the pcb with mounting holes which will fit a
2.5 inch harddisk. To complete its networking features it has a
Realtek RTL8192CU for WiFi 802.11 b/g/n.

Signed-off-by: Jelle de Jong <jelle...@powercraft.nl>
Signed-off-by: Hans de Goede <hdeg...@redhat.com>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts | 297 ++++++++++++++++++++++++++++++
2 files changed, 298 insertions(+)
create mode 100644 arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 28b0403..7572c29 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -639,6 +639,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
sun7i-a20-hummingbird.dtb \
sun7i-a20-i12-tvbox.dtb \
sun7i-a20-icnova-swac.dtb \
+ sun7i-a20-lamobo-r1.dtb \
sun7i-a20-m3.dtb \
sun7i-a20-mk808c.dtb \
sun7i-a20-olimex-som-evb.dtb \
diff --git a/arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts b/arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts
new file mode 100644
index 0000000..975b0b2
--- /dev/null
+++ b/arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts
@@ -0,0 +1,297 @@
+/*
+ * Copyright 2015 Jelle de Jong <jelle...@powercraft.nl>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun7i-a20.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/pinctrl/sun4i-a10.h>
+
+/ {
+ model = "Lamobo R1";
+ compatible = "lamobo,lamobo-r1", "allwinner,sun7i-a20";
+
+ aliases {
+ serial0 = &uart0;
+ serial1 = &uart3;
+ serial2 = &uart7;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&led_pins_lamobo_r1>;
+
+ green {
+ label = "lamobo_r1:green:usr";
+ gpios = <&pio 7 24 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ reg_gmac_3v3: gmac-3v3 {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&gmac_power_pin_lamobo_r1>;
+ regulator-name = "gmac-3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ startup-delay-us = <100000>;
+ enable-active-high;
+ gpio = <&pio 7 23 GPIO_ACTIVE_HIGH>; /* PH23 */
+ };
+};
+
+&ahci_pwr_pin_a {
+ allwinner,pins = "PB3";
+};
+
+&ahci {
+ target-supply = <&reg_ahci_5v>;
+ status = "okay";
+};
+
+&cpu0 {
+ cpu-supply = <&reg_dcdc2>;
+ operating-points = <
+ /* kHz uV */
+ 960000 1400000
+ 912000 1400000
+ 864000 1350000
+ 720000 1250000
+ 528000 1150000
+ 312000 1100000
+ 144000 1050000
+ >;
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&gmac {
+ pinctrl-names = "default";
+ pinctrl-0 = <&gmac_pins_rgmii_a>;
+ phy = <&phy1>;
+ phy-mode = "rgmii";
+ phy-supply = <&reg_gmac_3v3>;
+ status = "okay";
+
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+};
+
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins_a>;
+ status = "okay";
+
+ axp209: pmic@34 {
+ reg = <0x34>;
+ interrupt-parent = <&nmi_intc>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ };
+};
+
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins_a>;
+ status = "okay";
+};
+
+&ir0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ir0_rx_pins_a>;
+ status = "okay";
+};
+
+&mmc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_lamobo_r1>;
+ vmmc-supply = <&reg_vcc3v3>;
+ bus-width = <4>;
+ cd-gpios = <&pio 7 10 GPIO_ACTIVE_HIGH>; /* PH10 */
+ cd-inverted;
+ status = "okay";
+};
+
+&ohci0 {
+ status = "okay";
+};
+
+&ohci1 {
+ status = "okay";
+};
+
+&otg_sram {
+ status = "okay";
+};
+
+&pio {
+ usb0_id_detect_pin: usb0_id_detect_pin@0 {
+ allwinner,pins = "PH4";
+ allwinner,function = "gpio_in";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
+ };
+
+ mmc0_cd_pin_lamobo_r1: mmc0_cd_pin@0 {
+ allwinner,pins = "PH10";
+ allwinner,function = "gpio_in";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
+ };
+
+ gmac_power_pin_lamobo_r1: gmac_power_pin@0 {
+ allwinner,pins = "PH23";
+ allwinner,function = "gpio_out";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
+
+ led_pins_lamobo_r1: led_pins@0 {
+ allwinner,pins = "PH24";
+ allwinner,function = "gpio_out";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
+};
+
+#include "axp209.dtsi"
+
+&reg_ahci_5v {
+ gpio = <&pio 1 3 0>; /* PB3 */
+ status = "okay";
+};
+
+&reg_dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-name = "vdd-cpu";
+};
+
+&reg_dcdc3 {
+ regulator-always-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-name = "vdd-int-dll";
+};
+
+&reg_ldo1 {
+ regulator-name = "vdd-rtc";
+};
+
+&reg_ldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-name = "avcc";
+};
+
+&reg_usb0_vbus {
+ status = "okay";
+};
+
+&reg_usb1_vbus {
+ status = "okay";
+};
+
+&reg_usb2_vbus {
+ status = "okay";
+};
+
+&spi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi0_pins_a>,
+ <&spi0_cs0_pins_a>,
+ <&spi0_cs1_pins_a>;
+ status = "okay";
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins_a>;
+ status = "okay";
+};
+
+&uart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart3_pins_b>;
+ status = "okay";
+};
+
+&uart7 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart7_pins_a>;
+ status = "okay";
+};
+
+&usb_otg {
+ dr_mode = "otg";
+ status = "okay";
+};
+
+&usb_power_supply {
+ status = "okay";
+};
+
+&usbphy {
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb0_id_detect_pin>;
+ usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
+ usb0_vbus_power-supply = <&usb_power_supply>;
+ usb0_vbus-supply = <&reg_usb0_vbus>;
+ usb1_vbus-supply = <&reg_usb1_vbus>;
+ usb2_vbus-supply = <&reg_usb2_vbus>;
+ status = "okay";
+};
--
2.5.0

[Stefan Monnier]

> The lamobo-r1 board, sometimes called the BPI-R1 but not labelled as such
> on the PCB, is meant as a A20 based router board. As such the board comes
> with a built-in switch chip giving it 5 gigabit ethernet boards, and it
> has a large empty area on the pcb with mounting holes which will fit a
> 2.5 inch harddisk. To complete its networking features it has a
> Realtek RTL8192CU for WiFi 802.11 b/g/n.

When I looked for a DTS file for this board, I was told that the
bananapi DTS works just fine, the only difference being the ethernet
switch chip, which is not supported by mainline anyway (because the
only driver for it is in OpenWRT, using a framework that was never
accepted into mainline).

So is there some way to share the bulk of this file with that of
the bananapi?


Stefan

[Maxime Ripard]

Hi,

Why are you using a custom set of OPPs here, the default ones were
unstable?

What is connected on i2c2? Is i2c1 used at all? Would it make sense to
add aliases for the i2c buses as well?

I guess the same question about i2c also applies for SPI :)

Looks good otherwise, thanks!
Maxime

--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Thomas Kaiser]

Stefan Monnier wrote:

When I looked for a DTS file for this board, I was told that the
bananapi DTS works just fine

Nope, there are some differences already outlined in the wiki (eg. powering of a connected SATA disk is AXP209's job -- unless you pull pin PB3 the PMU won't supply the disk with power).

The device tree people use in the wild for over half a year with working SATA disk and switch can also be found in the wiki: http://linux-sunxi.org/Lamobo_R1#Mainline_kernel

Unless the patches there for the switch won't also be applied networking is pretty useless. And the R1 still suffers from lousy GMAC throughput compared to other A20 devices (maybe a driver issue).

Regards,

Thomas

[Hans de Goede]

Hi,

The fex file uses non standard OPPs, just like
the bananapi, so I've done in the same in the dts,
thinking "better safe then sorry" we can try without
the custom OPPs if you want and see how that works.

The Lamobo-R1 has a gpio header idententical to the one found
on the Banana Pi, i2c2 is routed to pins there.

> Is i2c1 used at all?

Not to my knowledge.

> Would it make sense to
> add aliases for the i2c buses as well?

I do not think anything would use those aliases, if we do
this we should probably do it for all boards which have in i2c
bus routed to some header pins.

Answers are the same too :)

Regards,

Hans

[Thomas Kaiser]

Hi,

Hans de Goede wrote:

On 22-11-15 20:59, Maxime Ripard wrote:
>> +&cpu0 {
>> +        cpu-supply = <&reg_dcdc2>;
>> +        operating-points = <
>> +                /* kHz          uV */
>> +                960000        1400000
>> +                912000        1400000
>> +                864000        1350000
>> +                720000        1250000
>> +                528000        1150000
>> +                312000        1100000
>> +                144000        1050000
>> +                >;
>
> Why are you using a custom set of OPPs here, the default ones were
> unstable?

The fex file uses non standard OPPs

Which fex file? In case you're referring to an 'official' one please  

keep in mind how SinoVoip 'develops' stuff. By doing copy&paste 

(remember the .dts for the Banana Pi M2?). Anyway, the fex files used 

by R1 users since a year contain comparable OPPs:

https://github.com/igorpecovnik/lib/blob/next/config/lamobo-r1.fex

https://github.com/Bananian/fex/blob/master/BPI-R1/script.fex

Stuff contained in official SinoVoip OS images can not be regarded 

safe or even tested since noone uses these OS images due to being 

broken more or less. And Lamobo R1 users that were relying on mainline 

kernel the last months already used a .dts sharing the default OPPs: 

https://github.com/igorpecovnik/lib/blob/next/patch/sun7i-a20-lamobo-r1.dts

[Maxime Ripard]

Hi,

On Mon, Nov 23, 2015 at 09:28:00AM +0100, Hans de Goede wrote:
> >>+&cpu0 {
> >>+ cpu-supply = <&reg_dcdc2>;
> >>+ operating-points = <
> >>+ /* kHz uV */
> >>+ 960000 1400000
> >>+ 912000 1400000
> >>+ 864000 1350000
> >>+ 720000 1250000
> >>+ 528000 1150000
> >>+ 312000 1100000
> >>+ 144000 1050000
> >>+ >;
> >
> >Why are you using a custom set of OPPs here, the default ones were
> >unstable?
>
> The fex file uses non standard OPPs, just like the bananapi, so I've
> done in the same in the dts, thinking "better safe then sorry" we
> can try without the custom OPPs if you want and see how that works.

Most of the time, when it comes to FEX, there's no standard OPP
actually. We've consolidated a set from most of the FEX files, and
it's the one that we have right now. Most of the time it works just
fine (the lime2 being the only exception), so I'd rather have you use
the generic ones, and if that proves to be unstable switch to some
custom ones.

> >>+&i2c0 {
> >>+ pinctrl-names = "default";
> >>+ pinctrl-0 = <&i2c0_pins_a>;
> >>+ status = "okay";
> >>+
> >>+ axp209: pmic@34 {
> >>+ reg = <0x34>;
> >>+ interrupt-parent = <&nmi_intc>;
> >>+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> >>+ };
> >>+};
> >>+
> >>+&i2c2 {
> >>+ pinctrl-names = "default";
> >>+ pinctrl-0 = <&i2c2_pins_a>;
> >>+ status = "okay";
> >>+};
> >
> >What is connected on i2c2?
>
> The Lamobo-R1 has a gpio header idententical to the one found
> on the Banana Pi, i2c2 is routed to pins there.

So it's just a generic header with the pins left as is, and it's up to
the user to plug something on it?

The policy we had so far for this was to not enforce anything for
these pins, and leave to the user the choice to to do whatever he
wanted.

> >Is i2c1 used at all?
>
> Not to my knowledge.

Ack

> > Would it make sense to add aliases for the i2c buses as well?
>
> I do not think anything would use those aliases, if we do
> this we should probably do it for all boards which have in i2c
> bus routed to some header pins.

What I wanted to avoid was to have the bus number changed if i2c1 was
going to be used at some point, but I doesn't seem to be the case
here, so everything's fine.

Yep :)

Thanks!

[Hans de Goede]

Hi,

Ok, I'll do a v2 with the custom OPPs dropped, but before I do that
lets get agreement on what to do with the i2c / spi pins on the
gpio header.

I'm not aware of such a policy and I actually believe that the policy
sofar has been to go with the function as which the pins are marked
in vendor documentation.

Looking at just SBC-s we're enabling at least 1 extra (unused other
then for a header) i2c controller on:

arch/arm/boot/dts/sun4i-a10-cubieboard.dts
arch/arm/boot/dts/sun4i-a10-itead-iteaduino-plus.dts
arch/arm/boot/dts/sun4i-a10-marsboard.dts
arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
arch/arm/boot/dts/sun5i-a13-olinuxino-micro.dts
arch/arm/boot/dts/sun5i-a13-olinuxino.dts
arch/arm/boot/dts/sun7i-a20-bananapi.dts
arch/arm/boot/dts/sun7i-a20-bananapro.dts
arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
arch/arm/boot/dts/sun7i-a20-cubietruck.dts
arch/arm/boot/dts/sun7i-a20-olinuxino-lime.dts
arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts

And spi on:

arch/arm/boot/dts/sun4i-a10-cubieboard.dts
arch/arm/boot/dts/sun4i-a10-itead-iteaduino-plus.dts
arch/arm/boot/dts/sun4i-a10-marsboard.dts
arch/arm/boot/dts/sun7i-a20-bananapi.dts
arch/arm/boot/dts/sun7i-a20-bananapro.dts
arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts

And note how the official documentation labels
the pins as sda / scl resp. miso/mosi:

http://www.bananapi.com/index.php/component/content/article?id=24

(you need to scroll down a bit)

As said this board is using the same header as found
on the banana pi and for the pi we are configuring
these pins as i2c / spi and looking at how I see
people use the raspberry pi at my local hackerspace
this is also what people want most of the time.

Regards,

Hans

[Thomas Kaiser]

Hi,

Hans de Goede wrote:

The Lamobo-R1 has a gpio header idententical to the one found

on the Banana Pi, i2c2 is routed to pins there.

That's the reason this header exists in this form and that's the reason customers buy these boards that expose an 'RPi compatible' 26/40 pin GPIO header. That applies also to the various Orange Pi's and other $insert-your-favourite-fruit-here Pi  with different SoCs, eg. Roseapple/Lemon Pi with Actions Semi's S500. Even boards that do not share the RPi's naming scheme feature this GPIO header, eg. LeMaker's Guitar or ODROID C1/C1+

Users expect this GPIO header being 'RPi compatible' regarding hardware-Addons (RPi HATs), software support (each of the above boards has a ported WiringPi lib) and tutorials they find on the net. Breaking this compatibility with mainline kernel is not a good idea IMO.

Best regards,

Thomas

[Thomas Kaiser]

Hi,

Hans de Goede:

The Lamobo-R1 has a gpio header idententical to the one found

on the Banana Pi, i2c2 is routed to pins there.

One thing I forgot to mention before. Please have a look into our Wiki at the second right picture:

    http://linux-sunxi.org/Lamobo_R1#GPIO_header

The Add-On is an I2C extender produced by the board's manufacturer. And the Add-On also works on RPi and nearly all other ARM boards featuring the 26/40 GPIO header since it's meant to work this way. Even boards with SoCs that can't provide this compatibility (due to different GPIO voltage levels) will be supplied with Add-Ons that make them compatible to this 'pseudo GPIO standard':

    http://www.mikronauts.com/hardkernel/hardkernel-odroid-xu4-shifter-shield-review/

BTW: In the R1's case it won't make any difference whether you configure I2C/SPI away or not since the 'distros' that are used with this specific board (containing also kernel patches to make use of the BroadCom switch IC that will never be accepted upstream) already ship with a dts making GPIO RPi compatible. And they will patch I2C and SPI back in if they're missing. My words above apply more to all the other sunxi SBC that feature the same 26/40 GPIO header.

Thx, 

Thomas

[Maxime Ripard]

Hmmm, I've been pretty bad at this, haven't I ? :)

> As said this board is using the same header as found
> on the banana pi and for the pi we are configuring
> these pins as i2c / spi and looking at how I see
> people use the raspberry pi at my local hackerspace
> this is also what people want most of the time.

What I'm more concerned about is people that will not want that. By
putting this into our DT, they will never be able to use their pin
without any way out of this apart from patching the DT itself.

But yeah, ok.

[Maxime Ripard]

On Tue, Nov 24, 2015 at 10:45:27AM +0100, Thomas Kaiser wrote:
> Hi,
>
> Hans de Goede wrote:
>
> > The Lamobo-R1 has a gpio header idententical to the one found
> > on the Banana Pi, i2c2 is routed to pins there.
>
> That's the reason this header exists in this form and that's the reason
> customers buy these boards that expose an 'RPi compatible' 26/40 pin GPIO
> header. That applies also to the various Orange Pi's and other
> $insert-your-favourite-fruit-here Pi with different SoCs, eg.
> Roseapple/Lemon Pi with Actions Semi's S500. Even boards that do not share
> the RPi's naming scheme feature this GPIO header, eg. LeMaker's Guitar or
> ODROID C1/C1+
>
> Users expect this GPIO header being 'RPi compatible' regarding
> hardware-Addons (RPi HATs), software support (each of the above boards has a
> ported WiringPi lib) and tutorials they find on the net.

The point is that it's *not* a GPIO header, and it's even worse that
that, if you actually want to use a GPIO on that header, you just
can't.

> Breaking this compatibility with mainline kernel is not a good idea
> IMO.

This compatibility is a fallacy in the first place. It might be an
electrical one, but it's certainly not a software one. How do you deal
with alternative pin configuration? How do you deal with the GPIOs
toggling? Which i2c bus is routed on this header?

And that wouldn't break anything. Quite the opposite actually, it
would allow people that want to deviate from the standard to do so
while allowing people that want to follow that standard to do so as
well.

[Thomas Kaiser]

Hi,

Maxime Ripard wrote:

>Quite the opposite actually, it would allow people that want to
>deviate from the standard to do so while allowing people that
>want to follow that standard to do so as well.

Well, the majority of people that buy boards because of this specific
26/40 pin header can't do that. They expect that everything works as with
the Raspberry Pi (a few GPIOs here, I2C there and so on) and will simply
have to give up if they (or let's better say the distro they use) switched
to mainline kernel and nothing works any longer _as expected_.

These people don't know where device trees grow and also don't care. They
expect compatibility to a 'de facto' standard and the hardware vendors
producing boards with this specific 26/40 pin header try to be compliant
to that by modifying pin definitions in the OS images they provide or
recommend. So maybe it simply doesn't matter how this stuff is defined
since it gets patched back in in every 'distro' ready for the average user.

At least that's the case for the Lamobo R1 we're talking about. As said
before: No one will use that board without also applying the OpenWRT
patchset to be able to use the internal switch IC. So I doubt anybody will
use the .dts we're talking here about since the OS images people will use
already include their own:

http://linux-sunxi.org/Lamobo_R1#Images

Best regards,

Thomas