Re: gemini: sl3516: Mainlining of NS 2502

2021-04-07 Thread Linus Walleij
On Tue, Apr 6, 2021 at 2:05 PM Corentin Labbe  wrote:

> You could find photos at http://kernel.montjoie.ovh/gemini/
> There are also photos of another SL3516 SoC based device (a SSI 1328 NAS), 
> but I fail to setup a serial on it, so I keep it for later.

Yeah it is clearly an RTL82111 at least, so this should be possible
to get going.

> > > syscon: syscon@4000 {
> > > pinctrl {
> > > /*
> > >  * gpio0agrp cover line 0-4
> > >  * gpio0bgrp cover line 5
> > >  */
> > > gpio0_default_pins: pinctrl-gpio0 {
> > > mux {
> > > function = "gpio0";
> > > groups = "gpio0agrp",
> > > "gpio0bgrp";
> > > };
> > > };
> >
> > Change groups to
> >
> > groups = "gpio0agrp", "gpio0bgrp", "gpio0hgrp";
> >
> > So you mux in group h which is where the GPIO 21, 22 go out
> > to the MDIO on 3516 IIUC. The right mux out is pretty important,
> > if you have vendor source code, please share so I can check how
> > they set it up.
>
> No change, probably due to all pinctrl-gemini 4000.syscon:pinctrl: could 
> not map pin config for "R8 GMAC0 RXDV"
> Please see http://kernel.montjoie.ovh/gemini/bootlog6.txt , I have added some 
> pr_info in gmac.
> I have put in the directory, the final dtb which I use.

All this is wrong too:
pinctrl-gemini 4000.syscon:pinctrl: could not map pin config for
"R8 GMAC0 RXDV"
pinctrl-gemini 4000.syscon:pinctrl: could not map pin config for
"U11 GMAC1 RXDV"
(...)

This is because we copied the DT config from a 3512 device rather than
3516 ... totally different pins. :/ R8 is the pin on 3512 so they all need
to change to e.g. from "R8 GMAC0 RXDV" to "V8 GMAC0 RXDV".

We need to come up with something unique for this device.

The code for mux is in drivers/pinctrl/pinctrl-gemini.c but can be a bit
terse. This file contains both 3512 and 3516 drivers so check closely
that you are looking at the right variant. The right pin names are in
the array gemini_3516_pins[].

The tricky thing is that I have never seen a SL3516 connected directly to
a simple phy like 82111. They all connect to some kind of switch chip...
So we need to figure out the muxing and pin config for this set-up.

This is what the DIR-685 is using for GMAC0:

pinctrl-gmii {
mux {
function = "gmii";
groups = "gmii_gmac0_grp";
};
conf0 {
pins = "V8 GMAC0
RXDV", "T10 GMAC1 RXDV",
 "Y7 GMAC0 RXC",
"Y11 GMAC1 RXC",
 "T8 GMAC0 TXEN",
"W11 GMAC1 TXEN",
 "U8 GMAC0 TXC",
"V11 GMAC1 TXC",
 "W8 GMAC0 RXD0",
"V9 GMAC0 RXD1",
 "Y8 GMAC0 RXD2",
"U9 GMAC0 RXD3",
 "T7 GMAC0 TXD0",
"U6 GMAC0 TXD1",
 "V7 GMAC0 TXD2",
"U7 GMAC0 TXD3",
 "Y12 GMAC1 RXD0",
"V12 GMAC1 RXD1",
 "T11 GMAC1 RXD2",
"W12 GMAC1 RXD3",
 "U10 GMAC1 TXD0",
"Y10 GMAC1 TXD1",
 "W10 GMAC1 TXD2",
"T9 GMAC1 TXD3";
skew-delay = <7>;
};
/* Set up drive strength on
GMAC0 to 16 mA */
conf1 {
groups = "gmii_gmac0_grp";
drive-strength = <16>;
};
};

But maybe your device is using GMAC1? I would try GMAC0 first anyway.

> The vendor source could be found at 
> https://www.edimax.com/edimax/mw/cufiles/files/download/OpenSourceCode/transfer/Wireless/NAS/NAS-GPL-source.zip

Normally the kernel should be setting up device resources and
config under arch/arm/mach-sl2312 (never mind the ASIC number...)
but Storlink have hacked the kernel all over the place so the
relevant parts can be hard to find.

The interesting stuff relating to pin control appears when
you 

Re: gemini: sl3516: Mainlining of NS 2502

2021-04-06 Thread Corentin Labbe
Le Tue, Apr 06, 2021 at 10:15:51AM +0200, Linus Walleij a écrit :
> On Mon, Apr 5, 2021 at 8:39 PM Corentin Labbe  
> wrote:
> 
> > I own an Edimax NS 2502, which is a NAS based on StormLinix 3516.
> > I successfully upgraded it with a recent Linux.
> 
> Pretty cool!
> 
> > mdio0: ethernet-phy {
> > compatible = "virtual,mdio-gpio";
> > gpios = < 22 GPIO_ACTIVE_HIGH>, /* MDC */
> > < 21 GPIO_ACTIVE_HIGH>; /* MDIO */
> > #address-cells = <1>;
> > #size-cells = <0>;
> > phy0: ethernet-phy@1 {
> > reg = <1>;
> > device_type = "ethernet-phy";
> > };
> > };
> 
> This looks like the most typical way to attach an MDIO phy.
> 
> I always try to identify the exact component used on the board. Do you have
>  a high res board photo?
> 

Hello

You could find photos at http://kernel.montjoie.ovh/gemini/
There are also photos of another SL3516 SoC based device (a SSI 1328 NAS), but 
I fail to setup a serial on it, so I keep it for later. 

> Realtek RTL82111 is the most common configuration.
> 
> Compare to the D-Linux DNS-313 DTS:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/gemini-dlink-dns-313.dts
> 
> Try just copying the whole pinctrl-gmii section!
> 
> 
> > syscon: syscon@4000 {
> > pinctrl {
> > /*
> >  * gpio0agrp cover line 0-4
> >  * gpio0bgrp cover line 5
> >  */
> > gpio0_default_pins: pinctrl-gpio0 {
> > mux {
> > function = "gpio0";
> > groups = "gpio0agrp",
> > "gpio0bgrp";
> > };
> > };
> 
> Change groups to
> 
> groups = "gpio0agrp", "gpio0bgrp", "gpio0hgrp";
> 
> So you mux in group h which is where the GPIO 21, 22 go out
> to the MDIO on 3516 IIUC. The right mux out is pretty important,
> if you have vendor source code, please share so I can check how
> they set it up.
> 

No change, probably due to all pinctrl-gemini 4000.syscon:pinctrl: could 
not map pin config for "R8 GMAC0 RXDV"
Please see http://kernel.montjoie.ovh/gemini/bootlog6.txt , I have added some 
pr_info in gmac.
I have put in the directory, the final dtb which I use.

The vendor source could be found at 
https://www.edimax.com/edimax/mw/cufiles/files/download/OpenSourceCode/transfer/Wireless/NAS/NAS-GPL-source.zip

> > BUT neither ethernet nor USB works.
> 
> For USB try this patch:
> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git/commit/?h=gemini-usb=cbaf6cdf770b90de5f10bfa5112c679f1dffe948
> 

One of the USB port is now working.

> Pls report progress! I hope we can mainline this device.
> 

I hope too.
Note that I have also started to work on the gemini crypto driver.

Thanks for your help


Re: gemini: sl3516: Mainlining of NS 2502

2021-04-06 Thread Corentin Labbe
Le Mon, Apr 05, 2021 at 10:36:32PM +0200, Andrew Lunn a écrit :
> On Mon, Apr 05, 2021 at 08:39:54PM +0200, Corentin Labbe wrote:
[ ... ]
> > libphy: Fixed MDIO Bus: probed
> > mdio-gpio ethernet-phy: failed to get alias id
> 
> That does not look too good. But it is just a warning.
> 
> if (pdev->dev.of_node) {
> bus_id = of_alias_get_id(pdev->dev.of_node, "mdio-gpio");
> if (bus_id < 0) {
> dev_warn(>dev, "failed to get alias id\n");
> bus_id = 0;
> }
> 
> If you look at the example in the documentation, it has
> 
> aliases {
> mdio-gpio0 = 
> };
> 
> If you add that, i guess this will go away.
>   

Hello

Yes it go away with this

> > gemini-ethernet-port 6000c000.ethernet-port: probe 6000c000.ethernet-port 
> > ID 1
> > gemini-ethernet-port 6000c000.ethernet-port: using a random ethernet address
> > gemini-ethernet-port 6000c000.ethernet-port (unnamed net_device) 
> > (uninitialized): PHY init failed
> 
> And now it seems to of all gone horribly wrong :-(
> 
> This is the second Ethernet interface, the one you have commented as 
> 
> /* Not used in this platform */
> 
> I _think_ you just need to delete the entry, otherwise it tried to
> probe it. And then that probe fails, it looks like it also fails the
> working interface :-(

Deleting the entry did no change. It still try to probe it.
I will try to delete second interface in gemini.dtsi just in case...


> > # udhcpc -i eth0
> > udhcpc: started, v1.33.0
> > udhcpc: socket: Address family not supported by protocol
> 
> That suggests the kernel you have build does not have PF_PACKET.
> Enable CONFIG_PACKET_DIAG.

Yes adding it fixed this error message.

Thanks


Re: gemini: sl3516: Mainlining of NS 2502

2021-04-06 Thread Linus Walleij
On Mon, Apr 5, 2021 at 8:39 PM Corentin Labbe  wrote:

> I own an Edimax NS 2502, which is a NAS based on StormLinix 3516.
> I successfully upgraded it with a recent Linux.

Pretty cool!

> mdio0: ethernet-phy {
> compatible = "virtual,mdio-gpio";
> gpios = < 22 GPIO_ACTIVE_HIGH>, /* MDC */
> < 21 GPIO_ACTIVE_HIGH>; /* MDIO */
> #address-cells = <1>;
> #size-cells = <0>;
> phy0: ethernet-phy@1 {
> reg = <1>;
> device_type = "ethernet-phy";
> };
> };

This looks like the most typical way to attach an MDIO phy.

I always try to identify the exact component used on the board. Do you have
 a high res board photo?

Realtek RTL82111 is the most common configuration.

Compare to the D-Linux DNS-313 DTS:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/gemini-dlink-dns-313.dts

Try just copying the whole pinctrl-gmii section!


> syscon: syscon@4000 {
> pinctrl {
> /*
>  * gpio0agrp cover line 0-4
>  * gpio0bgrp cover line 5
>  */
> gpio0_default_pins: pinctrl-gpio0 {
> mux {
> function = "gpio0";
> groups = "gpio0agrp",
> "gpio0bgrp";
> };
> };

Change groups to

groups = "gpio0agrp", "gpio0bgrp", "gpio0hgrp";

So you mux in group h which is where the GPIO 21, 22 go out
to the MDIO on 3516 IIUC. The right mux out is pretty important,
if you have vendor source code, please share so I can check how
they set it up.

> BUT neither ethernet nor USB works.

For USB try this patch:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git/commit/?h=gemini-usb=cbaf6cdf770b90de5f10bfa5112c679f1dffe948

Pls report progress! I hope we can mainline this device.

Yours,
Linus Walleij


Re: gemini: sl3516: Mainlining of NS 2502

2021-04-05 Thread Andrew Lunn
On Mon, Apr 05, 2021 at 08:39:54PM +0200, Corentin Labbe wrote:

>   mdio0: ethernet-phy {

Not relevant to the brokennes, but this should not be called
ethernet-phy. The example given in
Documentation/devicetree/bindings/net/mdio-gpio.txt is

mdio0: mdio

>   compatible = "virtual,mdio-gpio";
>   gpios = < 22 GPIO_ACTIVE_HIGH>, /* MDC */
>   < 21 GPIO_ACTIVE_HIGH>; /* MDIO */
>   #address-cells = <1>;
>   #size-cells = <0>;
>   phy0: ethernet-phy@1 {
>   reg = <1>;
>   device_type = "ethernet-phy";
>   };
>   };

So you are using a bit-banging MDIO bus.

>   gpio0: gpio@4d00 {
>   pinctrl-names = "default";
>   pinctrl-0 = <_default_pins>;
>   };

and here is the gpio controller.

>   ethernet@6000 {
>   status = "okay";
>   ethernet-port@0 {
>   phy-mode = "rgmii";
>   phy-handle = <>;
>   };
>   ethernet-port@1 {
>   /* Not used in this platform */
>   };
>   };

and this look O.K.

> libphy: Fixed MDIO Bus: probed
> mdio-gpio ethernet-phy: failed to get alias id

That does not look too good. But it is just a warning.

if (pdev->dev.of_node) {
bus_id = of_alias_get_id(pdev->dev.of_node, "mdio-gpio");
if (bus_id < 0) {
dev_warn(>dev, "failed to get alias id\n");
bus_id = 0;
}

If you look at the example in the documentation, it has

aliases {
mdio-gpio0 = 
};

If you add that, i guess this will go away.
  

> libphy: GPIO Bitbanged MDIO: probed
> tun: Universal TUN/TAP device driver, 1.6
> gmac-gemini 6000.ethernet: Ethernet device ID: 0x000, revision 0x1
> gemini-ethernet-port 60008000.ethernet-port: probe 60008000.ethernet-port ID 0
> gemini-ethernet-port 60008000.ethernet-port: using a random ethernet address
> RTL8211B Gigabit Ethernet gpio-0:01: attached PHY driver 
> (mii_bus:phy_addr=gpio-0:01, irq=POLL)

So a realtek PHY has been found on the MDIO bus. Good.

> gemini-ethernet-port 60008000.ethernet-port eth0: irq 30, DMA @ 0x0x60008000, 
> GMAC @ 0x0x6000a000

and everything looks good.

> gemini-ethernet-port 6000c000.ethernet-port: probe 6000c000.ethernet-port ID 1
> gemini-ethernet-port 6000c000.ethernet-port: using a random ethernet address
> gemini-ethernet-port 6000c000.ethernet-port (unnamed net_device) 
> (uninitialized): PHY init failed

And now it seems to of all gone horribly wrong :-(

This is the second Ethernet interface, the one you have commented as 

/* Not used in this platform */

I _think_ you just need to delete the entry, otherwise it tried to
probe it. And then that probe fails, it looks like it also fails the
working interface :-(
> 1: lo:  mtu 65536 qdisc noqueue qlen 1000
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
>valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
>valid_lft forever preferred_lft forever
> 2: eth0:  mtu 1500 qdisc noop qlen 1000
> link/ether b6:95:3c:18:98:62 brd ff:ff:ff:ff:ff:ff
> 3: sit0@NONE:  mtu 1480 qdisc noop qlen 1000
> link/sit 0.0.0.0 brd 0.0.0.0
> # udhcpc -i eth0
> udhcpc: started, v1.33.0
> gmac-gemini 6000.ethernet: allocate 512 pages for queue
> gemini-ethernet-port 60008000.ethernet-port eth0: Unsupported PHY speed (-1) 
> on gpio-0:01
> gemini-ethernet-port 60008000.ethernet-port eth0: Link is Down
> gemini-ethernet-port 60008000.ethernet-port eth0: link flow control: none
> udhcpc: socket: Address family not supported by protocol
> # gemini-ethernet-port 60008000.ethernet-port eth0: Link is Up - 1Gbps/Full - 
> flow control rx/tx
> gemini-ethernet-port 60008000.ethernet-port eth0: link flow control: tx
> IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> 
> # udhcpc -i eth0
> udhcpc: started, v1.33.0
> udhcpc: socket: Address family not supported by protocol

That suggests the kernel you have build does not have PF_PACKET.
Enable CONFIG_PACKET_DIAG.

   Andrew


gemini: sl3516: Mainlining of NS 2502

2021-04-05 Thread Corentin Labbe
Hello

I own an Edimax NS 2502, which is a NAS based on StormLinix 3516.

I successfully upgraded it with a recent Linux.
The DTB I use is the following:
/dts-v1/;
#include "gemini.dtsi"
#include 
/ {
model = "Edimax NS-2502";
compatible = "edimax,ns-2502", "cortina,gemini";
#address-cells = <1>;
#size-cells = <1>;
memory@0 {
/* 128 MB */
device_type = "memory";
reg = <0x 0x800>;
};
chosen {
bootargs = "console=ttyS0,19200n8";
stdout-path = 
};
mdio0: ethernet-phy {
compatible = "virtual,mdio-gpio";
gpios = < 22 GPIO_ACTIVE_HIGH>, /* MDC */
< 21 GPIO_ACTIVE_HIGH>; /* MDIO */
#address-cells = <1>;
#size-cells = <0>;
phy0: ethernet-phy@1 {
reg = <1>;
device_type = "ethernet-phy";
};
};
soc {
flash@3000 {
status = "okay";
/* 8MB of flash */
reg = <0x3000 0x0080>;
partition@0 {
label = "RedBoot";
reg = <0x 0x0002>;
read-only;
};
partition@2 {
label = "kernel";
reg = <0x0002 0x0070>;
};
partition@72 {
label = "VCTL";
reg = <0x0072 0x0002>;
read-only;
};
partition@74 {
label = "CurConf";
reg = <0x0074 0x000a>;
read-only;
};
partition@7e {
label = "FIS";
reg = <0x007e 0x0001>;
read-only;
};
};
syscon: syscon@4000 {
pinctrl {
/*
 * gpio0agrp cover line 0-4
 * gpio0bgrp cover line 5
 */
gpio0_default_pins: pinctrl-gpio0 {
mux {
function = "gpio0";
groups = "gpio0agrp",
"gpio0bgrp";
};
};
};
};
gpio0: gpio@4d00 {
pinctrl-names = "default";
pinctrl-0 = <_default_pins>;
};
ethernet@6000 {
status = "okay";
ethernet-port@0 {
phy-mode = "rgmii";
phy-handle = <>;
};
ethernet-port@1 {
/* Not used in this platform */
};
};
usb@6800 {
status = "okay";
};
usb@6900 {
status = "okay";
};
};
};

This is a bit of copy paste of other DTB.
With it I boot successfully to a shell.

BUT neither ethernet nor USB works.
This is the bootlog:
Flash Block Size = 65536

Storlink SL351x Boot Loader [Linux], version 1.0.9
Built by linux, 10:50:46, Aug  6 2008

Processor: SL3516c2
CPU Rate: 3
AHB Bus Clock:150MHzRatio:2/1
MAC 1 Address: 00:00:25:02:00:00
MAC 2 Address: 00:01:25:02:00:00
inet addr: 192.168.1.237/255.255.255.0
==> enter ^C to abort booting within 2 seconds ..
Load Kern image from 0x3002 to 0x80 size 7340032
Booting Linux on physical CPU 0x0
Linux version 5.12.0-rc5-next-20210401+ (compile@Red) 
(armv7a-unknown-linux-gnueabihf-gcc (Gentoo 9.3.0-r2 p4) 9.3.0, GNU ld (Gentoo 
2.34 p6) 2.34.0) #47 PREEMPT Mon Apr 5 20:20:27 CEST 2021
CPU: FA526 [66015261] revision 1 (ARMv4), cr=397f
CPU: VIVT data cache, VIVT instruction cache
OF: fdt: Machine model: Edimax NS-2502
Memory policy: Data cache writeback
Zone ranges:
  Normal   [mem 0x-0x07ff]
  HighMem  empty
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x-0x07ff]
Initmem setup node 0 [mem 0x-0x07ff]
Built 1