Re: if_dwxe driver for h3 - additional testing

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: if_dwxe driver for h3 - additional testing

Stephen Graf
I added some debug lines to try to see what is happening.  I could not see
the dwxe clocks being turned on until I changed:

        /* Enable clock. */
//      clock_enable(faa->fa_node, "stmmaceth");
//      reset_deassert(faa->fa_node, "stmmaceth");
clock_enable_all(faa->fa_node);
reset_deassert_all(faa->fa_node);

I could not find any reference to stmmaceth.  I can now see one clock being
turned on:
#define H3_CLK_BUS_EMAC         27
        [H3_CLK_BUS_EMAC] = { 0x0060, 17, H3_CLK_AHB2 },

But not the physical clock:
#define H3_CLK_BUS_EPHY         67
        [H3_CLK_BUS_EPHY]  = { 0x0070, 0 },

From the boot log:

dwxe0 at simplebus0
if_dwxe  phy-handle node: 0x588.
if_dwxe sc_phyloc: 0x1.
sxiccmu clock enable on: 1, reg: 0x60, bit: 17
sxiccmu clock reset assert: 0, reg: 0x2c0, bit: 17
: address 02:81:b1:07:76:5e
dwxe0: reset timeout
ukphy0 at dwxe0 phy 1: Generic IEEE 802.3u media interface, rev. 4: OUI
0x1e7240, model 0x0004
ifmedia_set: no match for 0x100/0xffffffffffffffff

I have cobbled together a dtb from an armbian distribution where the
ethernet works and the clocks match the entries in sxiccmu_clocks.h:
                ethernet@1c30000 {
                        compatible = "allwinner,sun8i-h3-emac";
                        syscon = <0x49>;
                        reg = <0x1c30000 0x104>;
                        interrupts = <0x0 0x52 0x4>;
                        resets = <0x2 0xc 0x2 0x27>;
                        reset-names = "ahb";
                        clocks = <0x2 0x1b 0x2 0x43>;
                        clock-names = "ahb";
                        pinctrl-names = "default";
                        pinctrl-0 = <0x48>;
                        #address-cells = <0x1>;
                        #size-cells = <0x0>;
                        status = "okay";
                        phy-handle = <0x47>;
                        phy-mode = "mii";
                        allwinner,leds-active-low;
                        linux,phandle = <0x31>;
                        phandle = <0x31>;

                        mdio {
                                #address-cells = <0x1>;
                                #size-cells = <0x0>;
                                linux,phandle = <0x32>;
                                phandle = <0x32>;

                                ethernet-phy@1 {
                                        reg = <0x1>;
                                        clocks = <0x2 0x43>;
                                        resets = <0x2 0x27>;
                                        linux,phandle = <0x47>;
                                        phandle = <0x47>;
                                };
                        };
                };



From: Stephen Graf [mailto:[hidden email]]
Sent: Thursday, October 12, 2017 8:35 PM
To: 'Mark Kettenis' <[hidden email]>; 'Patrick Wildt'
<[hidden email]>; '[hidden email]' <[hidden email]>
Subject: if_dwxe driver for h3

I don’t think that the driver is starting the clocks and/or clearing the
reset.  This is about the only thig that could cause the following on boot:
dwxe0: reset timeout

Testing on an orange pi one (H3).

Reply | Threaded
Open this post in threaded view
|

Re: if_dwxe driver for h3 - additional testing

Artturi Alm
On Thu, Oct 12, 2017 at 10:14:34PM -0700, Stephen Graf wrote:

> I added some debug lines to try to see what is happening.  I could not see
> the dwxe clocks being turned on until I changed:
>
>         /* Enable clock. */
> //      clock_enable(faa->fa_node, "stmmaceth");
> //      reset_deassert(faa->fa_node, "stmmaceth");
> clock_enable_all(faa->fa_node);
> reset_deassert_all(faa->fa_node);
>
> I could not find any reference to stmmaceth.  I can now see one clock being
> turned on:
> #define H3_CLK_BUS_EMAC         27
>         [H3_CLK_BUS_EMAC] = { 0x0060, 17, H3_CLK_AHB2 },
>
> But not the physical clock:
> #define H3_CLK_BUS_EPHY         67
>         [H3_CLK_BUS_EPHY]  = { 0x0070, 0 },
>

Hi,

when you reboot the oPIone next time, try something like this:

U-Boot 2017.09 (Sep 13 2017 - 04:48:58 -0600) Allwinner Technology

CPU:   Allwinner A64 (SUN50I)
Model: Pine64+
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   phy interface7
eth0: ethernet@01c30000
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
scanning bus 0 for devices... 2 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
Hit any key to stop autoboot:  0
=> dhcp
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
DHCP client bound to address 192.168.2.44 (1005 ms)
*** Warning: no boot file name; using 'C0A8022C.img'
Using ethernet@01c30000 device
TFTP from server 192.168.2.2; our IP address is 192.168.2.44
Filename 'C0A8022C.img'.
Load address: 0x42000000
Loading: *
Abort
=> env delete fdtfile
=> run distro_bootcmd
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found EFI removable media binary efi/boot/bootaa64.efi
reading efi/boot/bootaa64.efi
78335 bytes read in 39 ms (1.9 MiB/s)
## Starting EFI application at 40080000 ...
Scanning disks on usb...
Scanning disks on mmc...
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 5 disks
>> OpenBSD/arm64 BOOTAA64 0.8
boot>
booting sd0a:/bsd: 3865904+572704+508760+807488 [284196+96+451776+239879]=0x82fd28
[....you_know....]
[ using 976784 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
        The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2017 OpenBSD. All rights reserved.  https://www.OpenBSD.org

OpenBSD 6.2-current (GENERIC) #41: Fri Oct 13 15:29:43 MDT 2017
    [hidden email]:/usr/src/sys/arch/arm64/compile/GENERIC
real mem  = 948121600 (904MB)
avail mem = 892653568 (851MB)
mainbus0 at root: Pine64+
cpu0 at mainbus0: ARM Cortex-A53 r0p4
psci0 at mainbus0
agtimer0 at mainbus0: tick rate 24000 KHz
simplebus0 at mainbus0: "soc"
sxiccmu0 at simplebus0
sxipio0 at simplebus0: 103 pins
sximmc0 at simplebus0
sdmmc0 at sximmc0: 4-bit, sd high-speed, mmc high-speed, dma
ehci0 at simplebus0
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Generic EHCI root hub" rev 2.00/1.00 addr 1
com0 at simplebus0: ns16550, no working fifo
com0: console
ampintc0 at simplebus0 nirq 224, ncpu 4: "interrupt-controller"
sxirtc0 at simplebus0
dwxe0 at simplebus0: address 02:ba:40:e5:f7:9b
rgephy0 at dwxe0 phy 0: RTL8169S/8110S/8211 PHY, rev. 5
rgephy1 at dwxe0 phy 1: RTL8169S/8110S/8211 PHY, rev. 5
gpio0 at sxipio0: 32 pins
gpio1 at sxipio0: 32 pins
gpio2 at sxipio0: 32 pins
gpio3 at sxipio0: 32 pins
gpio4 at sxipio0: 32 pins
gpio5 at sxipio0: 32 pins
gpio6 at sxipio0: 32 pins
gpio7 at sxipio0: 32 pins
scsibus0 at sdmmc0: 2 targets, initiator 0
sd0 at scsibus0 targ 1 lun 0: <SD/MMC, SD16G, 0030> SCSI2 0/direct removable
sd0: 14804MB, 512 bytes/sector, 30318592 sectors
umass0 at uhub0 port 1 configuration 1 interface 0 "SanDisk Ultra" rev 2.10/1.00 addr 2
umass0: using SCSI over Bulk-Only
scsibus1 at umass0: 2 targets, initiator 0
sd1 at scsibus1 targ 1 lun 0: <SanDisk, Ultra, 1.00> SCSI4 0/direct removable serial.07815581301126103035
sd1: 29327MB, 512 bytes/sector, 60062500 sectors
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
bootfile: sd0a:/bsd
boot device: sd0
root on sd0a (45b906b25b16be69.a) swap on sd0b dump on sd0b
Automatic boot in progress: starting file system checks.
/dev/sd0a (45b906b25b16be69.a): file system is clean; not checking
/dev/sd0l (45b906b25b16be69.l): file system is clean; not checking
/dev/sd0d (45b906b25b16be69.d): file system is clean; not checking
/dev/sd0f (45b906b25b16be69.f): file system is clean; not checking
/dev/sd0g (45b906b25b16be69.g): file system is clean; not checking
/dev/sd0h (45b906b25b16be69.h): file system is clean; not checking
/dev/sd0k (45b906b25b16be69.k): file system is clean; not checking
/dev/sd0e (45b906b25b16be69.e): file system is clean; not checking
setting tty flags
pf enabled
starting network
reordering libraries: done.
starting early daemons: syslogd pflogd ntpd.
starting RPC daemons:.
savecore: no core dump
checking quotas: done.
clearing /tmp
kern.securelevel: 0 -> 1
creating runtime link editor directory cache.
preserving editor files.
starting network daemons: sshd smtpd sndiod.
starting local daemons: cron.
Sat Oct 14 03:28:36 EEST 2017

OpenBSD/arm64 (a64pine.my.domain) (console)

login: root
Password:
Last login: Sat Oct 14 03:14:20 on console
OpenBSD 6.2-current (GENERIC) #41: Fri Oct 13 15:29:43 MDT 2017

Welcome to OpenBSD: The proactively secure Unix-like operating system.

Please use the sendbug(1) utility to report bugs in the system.
Before reporting a bug, please try to reproduce it with the latest
version of the code.  With bug reports, please try to ensure that
enough information to reproduce the problem is enclosed, and if a
known fix for it exists, include that as well.

You have mail.
# dhclient dwxe0
dwxe0: DHCPREQUEST to 255.255.255.255
dwxe0: DHCPACK from 192.168.2.2 (00:22:68:10:3d:f0)
dwxe0: bound to 192.168.2.44 -- renewal in 21600 seconds


i did the "=> dhcp... ^C" on purpose too, the "env delete fdtfile" is what
jsg@ already told you about, to use the u-boot's copy of fdt, alternatively
you can just remove .dtb from the fat partition, i guess.
It does work here w/a64 like that, no ethernet without, but it doesn't help
w/the panic that's waiting for H3 internal phy setup like patrick@ told you,
H3 is different from A64&H5, and iirc. it can't be 'fixed' from the device tree.

-Artturi


> From the boot log:
>
> dwxe0 at simplebus0
> if_dwxe  phy-handle node: 0x588.
> if_dwxe sc_phyloc: 0x1.
> sxiccmu clock enable on: 1, reg: 0x60, bit: 17
> sxiccmu clock reset assert: 0, reg: 0x2c0, bit: 17
> : address 02:81:b1:07:76:5e
> dwxe0: reset timeout
> ukphy0 at dwxe0 phy 1: Generic IEEE 802.3u media interface, rev. 4: OUI
> 0x1e7240, model 0x0004
> ifmedia_set: no match for 0x100/0xffffffffffffffff
>
> I have cobbled together a dtb from an armbian distribution where the
> ethernet works and the clocks match the entries in sxiccmu_clocks.h:
>                 ethernet@1c30000 {
>                         compatible = "allwinner,sun8i-h3-emac";
>                         syscon = <0x49>;
>                         reg = <0x1c30000 0x104>;
>                         interrupts = <0x0 0x52 0x4>;
>                         resets = <0x2 0xc 0x2 0x27>;
>                         reset-names = "ahb";
>                         clocks = <0x2 0x1b 0x2 0x43>;
>                         clock-names = "ahb";
>                         pinctrl-names = "default";
>                         pinctrl-0 = <0x48>;
>                         #address-cells = <0x1>;
>                         #size-cells = <0x0>;
>                         status = "okay";
>                         phy-handle = <0x47>;
>                         phy-mode = "mii";
>                         allwinner,leds-active-low;
>                         linux,phandle = <0x31>;
>                         phandle = <0x31>;
>
>                         mdio {
>                                 #address-cells = <0x1>;
>                                 #size-cells = <0x0>;
>                                 linux,phandle = <0x32>;
>                                 phandle = <0x32>;
>
>                                 ethernet-phy@1 {
>                                         reg = <0x1>;
>                                         clocks = <0x2 0x43>;
>                                         resets = <0x2 0x27>;
>                                         linux,phandle = <0x47>;
>                                         phandle = <0x47>;
>                                 };
>                         };
>                 };
>
>
>
> From: Stephen Graf [mailto:[hidden email]]
> Sent: Thursday, October 12, 2017 8:35 PM
> To: 'Mark Kettenis' <[hidden email]>; 'Patrick Wildt'
> <[hidden email]>; '[hidden email]' <[hidden email]>
> Subject: if_dwxe driver for h3
>
> I don’t think that the driver is starting the clocks and/or clearing the
> reset.  This is about the only thig that could cause the following on boot:
> dwxe0: reset timeout
>
> Testing on an orange pi one (H3).
>