Re: change r2pro dts to public hw version (was "Board code with 2 dts" )

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 08.04.22 um 19:19 schrieb Frank Wunderlich:
Am 8. April 2022 19:00:03 MESZ schrieb Oleksij Rempel <linux@xxxxxxxxxxxxxxxx>:
Hi Frank

Am 08.04.22 um 13:03 schrieb Frank Wunderlich:
Hi,

have now the new board, but cannot get the gmac working in barebox.
In linux i have it working


https://github.com/frank-w/BPI-R2-4.14/blob/5.17-main/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts#L235

changed the dts in barebox to same values, but cannot get it working


https://github.com/frank-w/barebox-r2pro/blob/r2pro/arch/arm/dts/rk3568-bpi-r2-pro.dts#L123

i see both interfaces, but it looks like the phy (rtl8211F) is not
working in barebox

The rgmii configuration is may be wrong.

phy-mode = "rgmii" looks not realistic. The "rgmii" is only possible if
rgmii clock line on this
board is about 20cm longer compared to rgmii data lines. I doubt it is
the case :)

So, it looks like the delay was added as separate property for the MAC.
Without reading manual for
this chip I can't interprete this values looks somehow strange:
	tx_delay = <0x4f>;
	rx_delay = <0x0f>;

Normally delays are equal for both directions.
Best practice is: MAC  do not adds delays, PHY will do it (PHY driver
should be enabled)

barebox@BPI R2PRO:/ dhcp eth1
eth1: 1000Mbps full duplex link detected
eth1: 1000Mbps full duplex link detected
WARNING: eth1: No MAC address set. Using random address
e2:3c:a9:08:b8:c8
T T T T T T T T T T T eth1: link down
T dhcp: Network is down
barebox@BPI R2PRO:/ eth1: 1000Mbps full duplex link detected

barebox@BPI R2PRO:/
barebox@BPI R2PRO:/
barebox@BPI R2PRO:/
barebox@BPI R2PRO:/ devinfo eth1
Parent: fe010000.ethernet@xxxxxxxxxxx
Parameters:
ethaddr: e2:3c:a9:08:b8:c8 (type: MAC)
gateway: 0.0.0.0 (type: ipv4)
ipaddr: 0.0.0.0 (type: ipv4)
linux.bootargs: (type: string)
linux.devname: (type: string)
mode: dhcp (type: enum) (values: "dhcp", "static", "disabled")
netmask: 0.0.0.0 (type: ipv4)
serverip: (type: string)
barebox@BPI R2PRO:/ eth1.mode=static
barebox@BPI R2PRO:/ eth1.netmask=255.255.255.0
barebox@BPI R2PRO:/ eth1.ipaddr=192.168.0.18
barebox@BPI R2PRO:/ devinfo eth1
Parent: fe010000.ethernet@xxxxxxxxxxx
Parameters:
ethaddr: e2:3c:a9:08:b8:c8 (type: MAC)
gateway: 0.0.0.0 (type: ipv4)
ipaddr: 192.168.0.18 (type: ipv4)
linux.bootargs: (type: string)
linux.devname: (type: string)
mode: static (type: enum) (values: "dhcp", "static", "disabled")
netmask: 255.255.255.0 (type: ipv4)
serverip: (type: string)
barebox@BPI R2PRO:/ global.net.nameserver=192.168.0.10
barebox@BPI R2PRO:/ ifup eth1
barebox@BPI R2PRO:/ ping 192.168.0.10
T T T T T ping failed: Connection timed out
barebox@BPI R2PRO:/

devinfo without device shows me this:

`-- fe010000.ethernet@xxxxxxxxxxx
    `-- miibus0
      `-- mdio0-phy00
        `-- 0x00000000-0x0000003f ( 64 Bytes): /dev/mdio0-phy00
    `-- eth1
`-- fe2a0000.ethernet@xxxxxxxxxxx
    `-- miibus1
    `-- eth0

any idea how to trace the problem down?

regards Frank

--
Regards,
Oleksij

Thanks for first lookup.

Imho delays are read here,so source supports these properties:

https://git.pengutronix.de/cgit/barebox/tree/drivers/net/designware_rockchip.c#n272

ack

And default values are different too. Have not compared source with linux,but there it works with this values....
If understand you right,the rgmii should be possible with the delays.

rgmii can't work properly without correctly configured delays.
IMO, the best way is to disable delays on the MAC side and let configure proper delays by PHY, by
setting phy-mode = "rgmii-id"


Is there any way to debug this (or try different values)? Just to get which value is wrong.

By this way of testing, you will get range of values which would work good enough with some random
packet drops. It is better to measure it.

The only way i'm thinking about is creating different dtbs and loading then for testing from uboot. But which values to try...i don't know which direction is broken and can try only some "random" values.

I would suggest to take an oscilloscope and measure rgmii clk and data lines. Make sure it is using
correct frequency and the clock skew (delay between clk and data)

I hope this is not the problem that i load barebox from uboot.
regards Frank

u-boot can affect inital configuration. Most drivers are developed with clean HW in mind, not
preconfigured by other system. In the best case, the driver will do some kind of soft reset.

--
Regards,
Oleksij

_______________________________________________
barebox mailing list
barebox@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox



[Index of Archives]     [Linux Embedded]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux