Board code with 2 dts

Board code with 2 dts

[Frank Wunderlich]

Hi,

I get information that new hardware revision of bpi-r2 pro has some differences to the version i upstreamed. Is it possible to add a new dts and use same board code?

How can i choose between the 2 dts on build (kconfig option)?

Afaik the name of dtb is hardcoded in lowlevel.c [1]

Differences are iodomains (not defined in barebox,but linux) and gmac-config (gmacs swapped and different settings).

Currently i have not yet the new board for testing,but then i want to send patches for linux and barebox.

[1] https://git.pengutronix.de/cgit/barebox/tree/arch/arm/boards/rockchip-rk3568-bpi-r2pro/lowlevel.c#n24
regards Frank

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

Re: Board code with 2 dts

[Ahmad Fatoum]

Hello Frank,

On 22.03.22 18:23, Frank Wunderlich wrote:
> Hi,
> 
> I get information that new hardware revision of bpi-r2 pro has some differences to the version i upstreamed. Is it possible to add a new dts and use same board code?
> 
> How can i choose between the 2 dts on build (kconfig option)?

In any case, don't add a new Kconfig option. The existing one suffices.

> Afaik the name of dtb is hardcoded in lowlevel.c [1]
> 
> Differences are iodomains (not defined in barebox,but linux) and gmac-config (gmacs swapped and different settings).
> 
> Currently i have not yet the new board for testing,but then i want to send patches for linux and barebox.
> 
> [1] https://git.pengutronix.de/cgit/barebox/tree/arch/arm/boards/rockchip-rk3568-bpi-r2pro/lowlevel.c#n24

Is it possible to detect which board is being used?
If so, best practice is to have barebox the same image for both
and detect board type at runtime.
Here's an example doing it in lowlevel.c:
arch/arm/boards/stm32mp15xx-dkx/lowlevel.c

If you need more barebox infrastructure than what's available in the bootloader
to detect board type, you could e.g. rewrite gmac-config in barebox board code
after detection.

If there is no way to dynamically detect which board variant barebox is running
on, just duplicate the entry point in the same file and change just the device
tree. Then extend images/Makefile.rockchip to reference the new entry point
and barebox build will generate an image for each board. See for example:

arch/arm/boards/kontron-samx6i/lowlevel.c


Cheers,
Ahmad

> regards Frank
> 
> _______________________________________________
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox
> 


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

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

Aw: Re: Board code with 2 dts

[Frank Wunderlich]

Hi

thanks for your fast and detailed answer.
afaik vendor have not changed the saradc-detection (because v00 was not public), so v00 has same value as v1.0 and i cannot detect difference there. Maybe there is another way to detect (maybe based on gmac or any hardware-change), but for now i used last option you've mentioned (second entry function).

Have it implemented like kontron-samx6i (both dts currently same), it compiles, can you take a quick look if i did it right?

https://github.com/frank-w/barebox-r2pro/commit/deaf7a8eed7575e35c17807aa0a432363122b033

this is not intended to be upstreamed, but for me to fix upstream with v1 config (when i get the board) and still using v00 board.

regards Frank


> Gesendet: Dienstag, 22. März 2022 um 18:34 Uhr
> Von: "Ahmad Fatoum" <a.fatoum@pengutronix.de>
> An: frank-w@public-files.de, barebox@lists.infradead.org
> Betreff: Re: Board code with 2 dts
>
> Hello Frank,
> 
> On 22.03.22 18:23, Frank Wunderlich wrote:
> > Hi,
> > 
> > I get information that new hardware revision of bpi-r2 pro has some differences to the version i upstreamed. Is it possible to add a new dts and use same board code?
> > 
> > How can i choose between the 2 dts on build (kconfig option)?
> 
> In any case, don't add a new Kconfig option. The existing one suffices.
> 
> > Afaik the name of dtb is hardcoded in lowlevel.c [1]
> > 
> > Differences are iodomains (not defined in barebox,but linux) and gmac-config (gmacs swapped and different settings).
> > 
> > Currently i have not yet the new board for testing,but then i want to send patches for linux and barebox.
> > 
> > [1] https://git.pengutronix.de/cgit/barebox/tree/arch/arm/boards/rockchip-rk3568-bpi-r2pro/lowlevel.c#n24
> 
> Is it possible to detect which board is being used?
> If so, best practice is to have barebox the same image for both
> and detect board type at runtime.
> Here's an example doing it in lowlevel.c:
> arch/arm/boards/stm32mp15xx-dkx/lowlevel.c
> 
> If you need more barebox infrastructure than what's available in the bootloader
> to detect board type, you could e.g. rewrite gmac-config in barebox board code
> after detection.
> 
> If there is no way to dynamically detect which board variant barebox is running
> on, just duplicate the entry point in the same file and change just the device
> tree. Then extend images/Makefile.rockchip to reference the new entry point
> and barebox build will generate an image for each board. See for example:
> 
> arch/arm/boards/kontron-samx6i/lowlevel.c
> 
> 
> Cheers,
> Ahmad


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

Re: Aw: Re: Board code with 2 dts

[Ahmad Fatoum]

Hi Frank,

On 23.03.22 08:47, Frank Wunderlich wrote:
> Hi
> 
> thanks for your fast and detailed answer.
> afaik vendor have not changed the saradc-detection (because v00 was not public), so v00 has same value as v1.0 and i cannot detect difference there. Maybe there is another way to detect (maybe based on gmac or any hardware-change), but for now i used last option you've mentioned (second entry function).

If it's just pre-production HW, it's not worth it to dynamically detect, I agree.

> Have it implemented like kontron-samx6i (both dts currently same), it compiles, can you take a quick look if i did it right?
> 
> https://github.com/frank-w/barebox-r2pro/commit/deaf7a8eed7575e35c17807aa0a432363122b033

Looks ok to me. Nitpick: Using __dtb_z_ instead of __dtb_ and selecting ARM_USE_COMPRESSED_DTB
will decrease barebox size a bit.

> this is not intended to be upstreamed, but for me to fix upstream with v1 config (when i get the board) and still using v00 board.

If v00 is not publicly available, it would be nice if you could replace the existing
v00 support with v01 once you can test it.

Cheers,
Ahmad

> 
> regards Frank
> 
> 
>> Gesendet: Dienstag, 22. März 2022 um 18:34 Uhr
>> Von: "Ahmad Fatoum" <a.fatoum@pengutronix.de>
>> An: frank-w@public-files.de, barebox@lists.infradead.org
>> Betreff: Re: Board code with 2 dts
>>
>> Hello Frank,
>>
>> On 22.03.22 18:23, Frank Wunderlich wrote:
>>> Hi,
>>>
>>> I get information that new hardware revision of bpi-r2 pro has some differences to the version i upstreamed. Is it possible to add a new dts and use same board code?
>>>
>>> How can i choose between the 2 dts on build (kconfig option)?
>>
>> In any case, don't add a new Kconfig option. The existing one suffices.
>>
>>> Afaik the name of dtb is hardcoded in lowlevel.c [1]
>>>
>>> Differences are iodomains (not defined in barebox,but linux) and gmac-config (gmacs swapped and different settings).
>>>
>>> Currently i have not yet the new board for testing,but then i want to send patches for linux and barebox.
>>>
>>> [1] https://git.pengutronix.de/cgit/barebox/tree/arch/arm/boards/rockchip-rk3568-bpi-r2pro/lowlevel.c#n24
>>
>> Is it possible to detect which board is being used?
>> If so, best practice is to have barebox the same image for both
>> and detect board type at runtime.
>> Here's an example doing it in lowlevel.c:
>> arch/arm/boards/stm32mp15xx-dkx/lowlevel.c
>>
>> If you need more barebox infrastructure than what's available in the bootloader
>> to detect board type, you could e.g. rewrite gmac-config in barebox board code
>> after detection.
>>
>> If there is no way to dynamically detect which board variant barebox is running
>> on, just duplicate the entry point in the same file and change just the device
>> tree. Then extend images/Makefile.rockchip to reference the new entry point
>> and barebox build will generate an image for each board. See for example:
>>
>> arch/arm/boards/kontron-samx6i/lowlevel.c
>>
>>
>> Cheers,
>> Ahmad
> 
> 


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

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

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

[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

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@fe010000.of
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@fe010000.of
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@fe010000.of
  `-- miibus0
    `-- mdio0-phy00
      `-- 0x00000000-0x0000003f ( 64 Bytes): /dev/mdio0-phy00
  `-- eth1
`-- fe2a0000.ethernet@fe2a0000.of
  `-- miibus1
  `-- eth0

any idea how to trace the problem down?

regards Frank


> Gesendet: Mittwoch, 23. März 2022 um 10:03 Uhr
> Von: "Ahmad Fatoum" <a.fatoum@pengutronix.de>
> An: "Frank Wunderlich" <frank-w@public-files.de>
> Cc: barebox@lists.infradead.org
> Betreff: Re: Aw: Re: Board code with 2 dts
>
> Hi Frank,
> 
> On 23.03.22 08:47, Frank Wunderlich wrote:
> > Hi
> > 
> > thanks for your fast and detailed answer.
> > afaik vendor have not changed the saradc-detection (because v00 was not public), so v00 has same value as v1.0 and i cannot detect difference there. Maybe there is another way to detect (maybe based on gmac or any hardware-change), but for now i used last option you've mentioned (second entry function).
> 
> If it's just pre-production HW, it's not worth it to dynamically detect, I agree.
> 
> > Have it implemented like kontron-samx6i (both dts currently same), it compiles, can you take a quick look if i did it right?
> > 
> > https://github.com/frank-w/barebox-r2pro/commit/deaf7a8eed7575e35c17807aa0a432363122b033
> 
> Looks ok to me. Nitpick: Using __dtb_z_ instead of __dtb_ and selecting ARM_USE_COMPRESSED_DTB
> will decrease barebox size a bit.
> 
> > this is not intended to be upstreamed, but for me to fix upstream with v1 config (when i get the board) and still using v00 board.
> 
> If v00 is not publicly available, it would be nice if you could replace the existing
> v00 support with v01 once you can test it.
> 
> Cheers,
> Ahmad
> 
> > 
> > regards Frank
> > 
> > 
> >> Gesendet: Dienstag, 22. März 2022 um 18:34 Uhr
> >> Von: "Ahmad Fatoum" <a.fatoum@pengutronix.de>
> >> An: frank-w@public-files.de, barebox@lists.infradead.org
> >> Betreff: Re: Board code with 2 dts
> >>
> >> Hello Frank,
> >>
> >> On 22.03.22 18:23, Frank Wunderlich wrote:
> >>> Hi,
> >>>
> >>> I get information that new hardware revision of bpi-r2 pro has some differences to the version i upstreamed. Is it possible to add a new dts and use same board code?
> >>>
> >>> How can i choose between the 2 dts on build (kconfig option)?
> >>
> >> In any case, don't add a new Kconfig option. The existing one suffices.
> >>
> >>> Afaik the name of dtb is hardcoded in lowlevel.c [1]
> >>>
> >>> Differences are iodomains (not defined in barebox,but linux) and gmac-config (gmacs swapped and different settings).
> >>>
> >>> Currently i have not yet the new board for testing,but then i want to send patches for linux and barebox.
> >>>
> >>> [1] https://git.pengutronix.de/cgit/barebox/tree/arch/arm/boards/rockchip-rk3568-bpi-r2pro/lowlevel.c#n24
> >>
> >> Is it possible to detect which board is being used?
> >> If so, best practice is to have barebox the same image for both
> >> and detect board type at runtime.
> >> Here's an example doing it in lowlevel.c:
> >> arch/arm/boards/stm32mp15xx-dkx/lowlevel.c
> >>
> >> If you need more barebox infrastructure than what's available in the bootloader
> >> to detect board type, you could e.g. rewrite gmac-config in barebox board code
> >> after detection.
> >>
> >> If there is no way to dynamically detect which board variant barebox is running
> >> on, just duplicate the entry point in the same file and change just the device
> >> tree. Then extend images/Makefile.rockchip to reference the new entry point
> >> and barebox build will generate an image for each board. See for example:
> >>
> >> arch/arm/boards/kontron-samx6i/lowlevel.c
> >>
> >>
> >> Cheers,
> >> Ahmad
> > 
> > 
> 
> 
> -- 
> Pengutronix e.K.                           |                             |
> Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
>

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

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

[Oleksij Rempel]

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@fe010000.of
> 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@fe010000.of
> 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@fe010000.of
>    `-- miibus0
>      `-- mdio0-phy00
>        `-- 0x00000000-0x0000003f ( 64 Bytes): /dev/mdio0-phy00
>    `-- eth1
> `-- fe2a0000.ethernet@fe2a0000.of
>    `-- miibus1
>    `-- eth0
>
> any idea how to trace the problem down?
>
> regards Frank
>
>
>> Gesendet: Mittwoch, 23. März 2022 um 10:03 Uhr
>> Von: "Ahmad Fatoum" <a.fatoum@pengutronix.de>
>> An: "Frank Wunderlich" <frank-w@public-files.de>
>> Cc: barebox@lists.infradead.org
>> Betreff: Re: Aw: Re: Board code with 2 dts
>>
>> Hi Frank,
>>
>> On 23.03.22 08:47, Frank Wunderlich wrote:
>>> Hi
>>>
>>> thanks for your fast and detailed answer.
>>> afaik vendor have not changed the saradc-detection (because v00 was not public), so v00 has same value as v1.0 and i cannot detect difference there. Maybe there is another way to detect (maybe based on gmac or any hardware-change), but for now i used last option you've mentioned (second entry function).
>>
>> If it's just pre-production HW, it's not worth it to dynamically detect, I agree.
>>
>>> Have it implemented like kontron-samx6i (both dts currently same), it compiles, can you take a quick look if i did it right?
>>>
>>> https://github.com/frank-w/barebox-r2pro/commit/deaf7a8eed7575e35c17807aa0a432363122b033
>>
>> Looks ok to me. Nitpick: Using __dtb_z_ instead of __dtb_ and selecting ARM_USE_COMPRESSED_DTB
>> will decrease barebox size a bit.
>>
>>> this is not intended to be upstreamed, but for me to fix upstream with v1 config (when i get the board) and still using v00 board.
>>
>> If v00 is not publicly available, it would be nice if you could replace the existing
>> v00 support with v01 once you can test it.
>>
>> Cheers,
>> Ahmad
>>
>>>
>>> regards Frank
>>>
>>>
>>>> Gesendet: Dienstag, 22. März 2022 um 18:34 Uhr
>>>> Von: "Ahmad Fatoum" <a.fatoum@pengutronix.de>
>>>> An: frank-w@public-files.de, barebox@lists.infradead.org
>>>> Betreff: Re: Board code with 2 dts
>>>>
>>>> Hello Frank,
>>>>
>>>> On 22.03.22 18:23, Frank Wunderlich wrote:
>>>>> Hi,
>>>>>
>>>>> I get information that new hardware revision of bpi-r2 pro has some differences to the version i upstreamed. Is it possible to add a new dts and use same board code?
>>>>>
>>>>> How can i choose between the 2 dts on build (kconfig option)?
>>>>
>>>> In any case, don't add a new Kconfig option. The existing one suffices.
>>>>
>>>>> Afaik the name of dtb is hardcoded in lowlevel.c [1]
>>>>>
>>>>> Differences are iodomains (not defined in barebox,but linux) and gmac-config (gmacs swapped and different settings).
>>>>>
>>>>> Currently i have not yet the new board for testing,but then i want to send patches for linux and barebox.
>>>>>
>>>>> [1] https://git.pengutronix.de/cgit/barebox/tree/arch/arm/boards/rockchip-rk3568-bpi-r2pro/lowlevel.c#n24
>>>>
>>>> Is it possible to detect which board is being used?
>>>> If so, best practice is to have barebox the same image for both
>>>> and detect board type at runtime.
>>>> Here's an example doing it in lowlevel.c:
>>>> arch/arm/boards/stm32mp15xx-dkx/lowlevel.c
>>>>
>>>> If you need more barebox infrastructure than what's available in the bootloader
>>>> to detect board type, you could e.g. rewrite gmac-config in barebox board code
>>>> after detection.
>>>>
>>>> If there is no way to dynamically detect which board variant barebox is running
>>>> on, just duplicate the entry point in the same file and change just the device
>>>> tree. Then extend images/Makefile.rockchip to reference the new entry point
>>>> and barebox build will generate an image for each board. See for example:
>>>>
>>>> arch/arm/boards/kontron-samx6i/lowlevel.c
>>>>
>>>>
>>>> Cheers,
>>>> Ahmad
>>>
>>>
>>
>>
>> --
>> Pengutronix e.K.                           |                             |
>> Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
>> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
>> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
>>
>
> _______________________________________________
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox


--
Regards,
Oleksij

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

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

[Frank Wunderlich]

Am 8. April 2022 19:00:03 MESZ schrieb Oleksij Rempel <linux@rempel-privat.de>:
>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@fe010000.of
>> 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@fe010000.of
>> 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@fe010000.of
>>    `-- miibus0
>>      `-- mdio0-phy00
>>        `-- 0x00000000-0x0000003f ( 64 Bytes): /dev/mdio0-phy00
>>    `-- eth1
>> `-- fe2a0000.ethernet@fe2a0000.of
>>    `-- 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

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.

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

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 hope this is not the problem that i load barebox from uboot.
regards Frank

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

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

[Oleksij Rempel]

Am 08.04.22 um 19:19 schrieb Frank Wunderlich:
> Am 8. April 2022 19:00:03 MESZ schrieb Oleksij Rempel <linux@rempel-privat.de>:
>> 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@fe010000.of
>>> 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@fe010000.of
>>> 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@fe010000.of
>>>     `-- miibus0
>>>       `-- mdio0-phy00
>>>         `-- 0x00000000-0x0000003f ( 64 Bytes): /dev/mdio0-phy00
>>>     `-- eth1
>>> `-- fe2a0000.ethernet@fe2a0000.of
>>>     `-- 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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

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

[Frank Wunderlich]

> Gesendet: Samstag, 09. April 2022 um 10:04 Uhr
> Von: "Oleksij Rempel" <linux@rempel-privat.de>
> An: frank-w@public-files.de, "Ahmad Fatoum" <a.fatoum@pengutronix.de>
> Cc: barebox@lists.infradead.org
> Betreff: Re: change r2pro dts to public hw version (was "Board code with 2 dts" )
>
> Am 08.04.22 um 19:19 schrieb Frank Wunderlich:
> > Am 8. April 2022 19:00:03 MESZ schrieb Oleksij Rempel <linux@rempel-privat.de>:
> >> 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@fe010000.of
> >>> 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@fe010000.of
> >>> 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@fe010000.of
> >>>     `-- miibus0
> >>>       `-- mdio0-phy00
> >>>         `-- 0x00000000-0x0000003f ( 64 Bytes): /dev/mdio0-phy00
> >>>     `-- eth1
> >>> `-- fe2a0000.ethernet@fe2a0000.of
> >>>     `-- 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"

tried this but same result

+++ b/arch/arm/dts/rk3568-bpi-r2-pro.dts
@@ -165,8 +165,8 @@
        /* Reset time is 20ms, 100ms for rtl8211f */
        snps,reset-delays-us = <0 20000 100000>;

-       tx_delay = <0x3c>;
-       rx_delay = <0x2f>;
+       //tx_delay = <0x3c>;
+       //rx_delay = <0x2f>;

        status = "okay";
 };
@@ -400,6 +400,7 @@
        rgmii_phy1: ethernet-phy@0 {
                compatible = "ethernet-phy-ieee802.3-c22";
                reg = <0x0>;
+               phy-mode = "rgmii-id";
        };
 };


barebox@BPI R2PRO:/ dhcp eth1
eth1: 1000Mbps full duplex link detected
WARNING: eth1: No MAC address set. Using random address 72:a4:02:4a:e9:38
T T T T T T T T T T eth1: link down
eth1: 1000Mbps full duplex link detected
T T T T T T T T T T dhcp: Connection timed out

also tried to set the phy-mode on gmac instead of phy

        phy-handle = <&rgmii_phy1>;
-       phy-mode = "rgmii";
+       phy-mode = "rgmii-id";
        pinctrl-names = "default";

same result ;(

> >
> > 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.

if i get it working this way, how to read out the delays?

> > 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)

have no oscilloscope here as i'm a private person and do this as hobby

> > 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.

currently uboot does not support rk3568 ethernet, so i guess it should not affect.

> --
> Regards,
> Oleksij
>

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

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

[Oleksij Rempel]

Am 09.04.22 um 10:35 schrieb Frank Wunderlich:
>
>> Gesendet: Samstag, 09. April 2022 um 10:04 Uhr
>> Von: "Oleksij Rempel" <linux@rempel-privat.de>
>> An: frank-w@public-files.de, "Ahmad Fatoum" <a.fatoum@pengutronix.de>
>> Cc: barebox@lists.infradead.org
>> Betreff: Re: change r2pro dts to public hw version (was "Board code with 2 dts" )
>>
>> Am 08.04.22 um 19:19 schrieb Frank Wunderlich:
>>> Am 8. April 2022 19:00:03 MESZ schrieb Oleksij Rempel <linux@rempel-privat.de>:
>>>> Hi Frank
>>>>
>>>> Am 08.04.22 um 13:03 schrieb Frank Wunderlich:
...
>>> 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"
>
> tried this but same result
>
> +++ b/arch/arm/dts/rk3568-bpi-r2-pro.dts
> @@ -165,8 +165,8 @@
>          /* Reset time is 20ms, 100ms for rtl8211f */
>          snps,reset-delays-us = <0 20000 100000>;
>
> -       tx_delay = <0x3c>;
> -       rx_delay = <0x2f>;
> +       //tx_delay = <0x3c>;
> +       //rx_delay = <0x2f>;

In this case driver will set some default values:
priv->tx_delay = 0x30;
priv->rx_delay = 0x10;

No idea what this values mean.

>          status = "okay";
>   };
> @@ -400,6 +400,7 @@
>          rgmii_phy1: ethernet-phy@0 {
>                  compatible = "ethernet-phy-ieee802.3-c22";
>                  reg = <0x0>;
> +               phy-mode = "rgmii-id";
>          };
>   };
>
> barebox@BPI R2PRO:/ dhcp eth1
> eth1: 1000Mbps full duplex link detected
> WARNING: eth1: No MAC address set. Using random address 72:a4:02:4a:e9:38
> T T T T T T T T T T eth1: link down
> eth1: 1000Mbps full duplex link detected
> T T T T T T T T T T dhcp: Connection timed out
>
> also tried to set the phy-mode on gmac instead of phy
>
>          phy-handle = <&rgmii_phy1>;
> -       phy-mode = "rgmii";
> +       phy-mode = "rgmii-id";
>          pinctrl-names = "default";
>
> same result ;(

Except of clk delay, there can be wrong clk direction and/or frequency. Or pinctrl, or clk driver issue.

>>>
>>> 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.
>
> if i get it working this way, how to read out the delays?

in this case I would try to do a register dump

>>> 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)
>
> have no oscilloscope here as i'm a private person and do this as hobby

i have private oscilloscope, no idea what to answer :)

>>> 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.
>
> currently uboot does not support rk3568 ethernet, so i guess it should not affect.

--
Regards,
Oleksij

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

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

[Trent Piepho]

On Sat, Apr 9, 2022 at 9:02 AM Oleksij Rempel <linux@rempel-privat.de> wrote:>
>
> In this case driver will set some default values:
> priv->tx_delay = 0x30;
> priv->rx_delay = 0x10;
>
> No idea what this values mean.

They are supposed to be delays in picoseconds, but sometimes driver
authors are lazy and just use whatever goes into their device's
registers.  That creates a dts binding that only works for one
specific device.

> >> 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)
> >
> > have no oscilloscope here as i'm a private person and do this as hobby
>
> i have private oscilloscope, no idea what to answer :)

I also have a scope, but mine does not do picoseconds!  Those are expensive.

What you can do, is just write a test program that goes through every
delay value and measures how many packets it was able to send or
receive.  The success rate will probably look something like this:

0% 0% 5% 99% 100% 100% 100% 100% 99% 0% 0%

If the first value is for delay = 0 and they go up by 1 , then
probably delay = 5 or 6 is the best value to use.

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

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

[Oleksij Rempel]

Am 09.04.22 um 19:08 schrieb Trent Piepho:
> On Sat, Apr 9, 2022 at 9:02 AM Oleksij Rempel <linux@rempel-privat.de> wrote:>
>>
>> In this case driver will set some default values:
>> priv->tx_delay = used cd;
>> priv->rx_delay = 0x10;
>>
>> No idea what this values mean.
>
> They are supposed to be delays in picoseconds, but sometimes driver
> authors are lazy and just use whatever goes into their device's
> registers.  That creates a dts binding that only works for one
> specific device.

According to RGMII 2.0 specification, delay should be 2.8 nanosecond or 2800 picoseconds. None of
used raw values fits to the specified range.
>
>>>> 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)
>>>
>>> have no oscilloscope here as i'm a private person and do this as hobby
>>
>> i have private oscilloscope, no idea what to answer :)
>
> I also have a scope, but mine does not do picoseconds!  Those are expensive.
>
> What you can do, is just write a test program that goes through every
> delay value and measures how many packets it was able to send or
> receive.  The success rate will probably look something like this:
>
> 0% 0% 5% 99% 100% 100% 100% 100% 99% 0% 0%
>
> If the first value is for delay = 0 and they go up by 1 , then
> probably delay = 5 or 6 is the best value to use.

Normally we use phy-mode with predefined values:
- rgmii == tx/rx delay is 0
- rgmii-id == PHY configures tx and rx delays to closest possible values to 2.8ns
- rgmii-txid == PHY configures only tx delay to 2.8ns, rx is 0
- rgmii-rxid == same as rgmii-txid but for rx.

Using raw values or fine tuning this delays makes no sense in 99% cases.

Since the PHY and the driver, used on this boards, supports internal delay configuration, it makes
no sense to spend any time on this kind of investigation for this or any other board. All embedded
boards would work with "rgmii-id" and no delay on the MAC side. Which should be default MAC
configuration without additional device tree properties, except of buggy driver or MACs with
integrated not configurable delays, or boards with insanely long traces for rgmii clk.

As I already said, except of delays there can be other issue. For example:
- incorrect pinmux configuration
- incorrect RGMII clock source configuration
- incorrect MAC or PHY mode configuration (xMII instead of RGMII)
- incorrect reset or power up sequence affecting proper bootstrap configuration.
- incorrect MDIO configuration, for example CLK rate outside of range supported by the PHY.
- not properly configured SoCs internal clock dependencies.
- some missing "enable" bit on the PHY or the MAC side

Even if you don't like the fact, that for most of this cases, scope will reduce dramatically
investigation time. I'll need to repeat it, it will help to use the scope.

--
Regards,
Oleksij

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

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

[Frank Wunderlich]

Am 10. April 2022 09:41:06 MESZ schrieb Oleksij Rempel <linux@rempel-privat.de>:

>Normally we use phy-mode with predefined values:
>- rgmii == tx/rx delay is 0
>- rgmii-id == PHY configures tx and rx delays to closest possible
>values to 2.8ns
>- rgmii-txid == PHY configures only tx delay to 2.8ns, rx is 0
>- rgmii-rxid == same as rgmii-txid but for rx.
>
>Using raw values or fine tuning this delays makes no sense in 99%
>cases.

So i need to disable the delay-configuration and set rgmii-id. Do i need to set only on mac or on the phy too?

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

Set flags to RK3568_GMAC_{R,T}XCLK_DLY_DISABLE and disable second regmap write. Board has a realtek phy which is defined in dts only with this:

&mdio1 {	
rgmii_phy1: ethernet-phy@0 {	
	compatible = "ethernet-phy-ieee802.3-c22";	
  reg = <0x0>;
	};
};

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

Can i check if the phy is recognized on mdio-bus and initialized? I see it in the devlist,but not sure if this means that it is completely initialized.

>Since the PHY and the driver, used on this boards, supports internal
>delay configuration, it makes
>no sense to spend any time on this kind of investigation for this or
>any other board. All embedded
>boards would work with "rgmii-id" and no delay on the MAC side. Which
>should be default MAC
>configuration without additional device tree properties, except of
>buggy driver or MACs with
>integrated not configurable delays, or boards with insanely long traces
>for rgmii clk.
>
>As I already said, except of delays there can be other issue. For
>example:
>- incorrect pinmux configuration
>- incorrect RGMII clock source configuration
>- incorrect MAC or PHY mode configuration (xMII instead of RGMII)
>- incorrect reset or power up sequence affecting proper bootstrap
>configuration.
>- incorrect MDIO configuration, for example CLK rate outside of range
>supported by the PHY.
>- not properly configured SoCs internal clock dependencies.
>- some missing "enable" bit on the PHY or the MAC side

I more guess something like the last 2 is the problem as the delay-settings work in linux. But have not completely understood all parts. Imho pinmux is done on usage. So if i use

pinctrl-0 = <&gmac1m1_miim 		 &gmac1m1_tx_bus2 		 &gmac1m1_rx_bus2 		 &gmac1m1_rgmii_clk 		 &gmac1m1_rgmii_bus>;

The pinmux should be set,or am i wrong?

https://github.com/frank-w/barebox-r2pro/blob/b13021268148954a59682620ab284054b25448e4/arch/arm/dts/rk3568-pinctrl.dtsi#L705

Afaik gmac1 uses fixed 125MHz clock (it came from cru like gmac0) as clock_in_out is set to output.

assigned-clocks = <&cru SCLK_GMAC1_RX_TX>, <&cru SCLK_GMAC1>;
assigned-clock-parents = <&cru SCLK_GMAC1_RGMII_SPEED>, <&cru CLK_MAC1_2TOP>;

I basicly use the config from linux,which i had mostly taken from vendors repo.

As the first version (used the other gmac for wan-port) worked,i guess the phy and mac driver is right. Same for clock driver and constant values.

>Even if you don't like the fact, that for most of this cases, scope
>will reduce dramatically
>investigation time. I'll need to repeat it, it will help to use the
>scope.

I have none and if i'm not sure if i can trace it right because it's decades ago i made something with one.

So i search ways to check it in software as far as possible. Maybe there are ways to read out registers to check if phy is available and compare values with linux.

regards Frank

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

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

[Trent Piepho]

On Sun, Apr 10, 2022 at 12:41 AM Oleksij Rempel <linux@rempel-privat.de> wrote:
>
> Am 09.04.22 um 19:08 schrieb Trent Piepho:
> > On Sat, Apr 9, 2022 at 9:02 AM Oleksij Rempel <linux@rempel-privat.de> wrote:>
> >>
> >> In this case driver will set some default values:
> >> priv->tx_delay = used cd;
> >> priv->rx_delay = 0x10;
> >>
> >> No idea what this values mean.
> >
> > They are supposed to be delays in picoseconds, but sometimes driver
> > authors are lazy and just use whatever goes into their device's
> > registers.  That creates a dts binding that only works for one
> > specific device.
>
> According to RGMII 2.0 specification, delay should be 2.8 nanosecond or 2800 picoseconds. None of
> used raw values fits to the specified range.

As I understand it, there are also delays due to PCB signal routing
that might be significant enough that they need to be taken into
account too.  Thus we have standard properties like:

  rx-internal-delay-ps:
   description: |
     RGMII Receive Clock Delay defined in pico seconds.
     This is used for controllers that have configurable RX internal delays.
     If this property is present then the MAC applies the RX delay.

This is for the MAC delay, not the PHY delay, but you will notice that
it is in fact in picoseconds.  If the value was always 2.8 ns, then it
could just be boolean property to enable the delay.  But it's not,
because the delay is not always the same value for every board.

Some drivers will not use this property and will make up their own.
It will probably be whatever is written into the device registers.
Others might use vendor specific properties in picoseconds for some
reason known only to the author, e.g.:

mediatek,tx-delay-ps = <1530>;

You will notice in picroseconds and also not 2800.

When delay is controlled by the PHY, then there are properties like:

    - rxc-skew-ps : Skew control of RXC pad
    - txc-skew-ps : Skew control of TXC pad

Also in picoseconds.  A search of existing device trees will show it
is not always 2800 either.

> Normally we use phy-mode with predefined values:
> - rgmii == tx/rx delay is 0
> - rgmii-id == PHY configures tx and rx delays to closest possible values to 2.8ns
> - rgmii-txid == PHY configures only tx delay to 2.8ns, rx is 0
> - rgmii-rxid == same as rgmii-txid but for rx.
>
> Using raw values or fine tuning this delays makes no sense in 99% cases.

I agree today, rgmii-id is the normal configuration and usually works
with no further modification.

For a new board design, I think running though the delay test is a
valuable part of validating the RGMII design of the board.  Just
because the 20 prototype boards all work at room temperature does not
mean the million you make afterward will have a 0% failure rate over
the full spec temp range.

> As I already said, except of delays there can be other issue. For example:
> - incorrect pinmux configuration
> - incorrect RGMII clock source configuration
> - incorrect MAC or PHY mode configuration (xMII instead of RGMII)
> - incorrect reset or power up sequence affecting proper bootstrap configuration.
> - incorrect MDIO configuration, for example CLK rate outside of range supported by the PHY.
> - not properly configured SoCs internal clock dependencies.
> - some missing "enable" bit on the PHY or the MAC side

If all one knows is ethernet doesn't work, then I think all of those
problems above are more likely the problem than a need to fine tune
the RGMII delays.

> Even if you don't like the fact, that for most of this cases, scope will reduce dramatically
> investigation time. I'll need to repeat it, it will help to use the scope.

Where do get this idea that I do not like an oscilloscope?  I use one
constantly.  I do not own one that can measure the clk vs data delay
on RGMII to 100 ps precision.  Do have one at work that can.  But
rarely does a board have test points to do this anyway.  Determining
if the various 25/50/125 MHz clocks are there is far more feasible.

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

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

[Oleksij Rempel]

Am 10.04.22 um 11:28 schrieb Trent Piepho:
> On Sun, Apr 10, 2022 at 12:41 AM Oleksij Rempel <linux@rempel-privat.de> wrote:
>>
>> Am 09.04.22 um 19:08 schrieb Trent Piepho:
>>> On Sat, Apr 9, 2022 at 9:02 AM Oleksij Rempel <linux@rempel-privat.de> wrote:>
>>>>
>>>> In this case driver will set some default values:
>>>> priv->tx_delay = used cd;
>>>> priv->rx_delay = 0x10;
>>>>
>>>> No idea what this values mean.
>>>
>>> They are supposed to be delays in picoseconds, but sometimes driver
>>> authors are lazy and just use whatever goes into their device's
>>> registers.  That creates a dts binding that only works for one
>>> specific device.
>>
>> According to RGMII 2.0 specification, delay should be 2.8 nanosecond or 2800 picoseconds. None of
>> used raw values fits to the specified range.
>
> As I understand it, there are also delays due to PCB signal routing
> that might be significant enough that they need to be taken into
> account too.  Thus we have standard properties like:
>
>    rx-internal-delay-ps:
>     description: |
>       RGMII Receive Clock Delay defined in pico seconds.
>       This is used for controllers that have configurable RX internal delays.
>       If this property is present then the MAC applies the RX delay.
>
> This is for the MAC delay, not the PHY delay, but you will notice that
> it is in fact in picoseconds.  If the value was always 2.8 ns, then it
> could just be boolean property to enable the delay.  But it's not,
> because the delay is not always the same value for every board.
>
> Some drivers will not use this property and will make up their own.
> It will probably be whatever is written into the device registers.
> Others might use vendor specific properties in picoseconds for some
> reason known only to the author, e.g.:
>
> mediatek,tx-delay-ps = <1530>;

Just to make sure, we do not don't talk past each other. My point is: most of rgmii specific
information in many devicetree makes no sense. And here is my explanation...

I assume you used this example:
arch/arm64/boot/dts/mediatek/mt2712-evb.dts

Why not use more of it?

         phy-mode ="rgmii-rxid";
         mediatek,tx-delay-ps = <1530>;

         mdio {
                 ethernet_phy0: ethernet-phy@5 {
                         compatible = "ethernet-phy-id0243.0d90";

First what we see is:
- rgmii-rxid is used, so PHY will configure RX delay to some value.
- tx delay is configured by the MAC.

So, we have two options:
1. board design is very special and all RGMII traces except of rxclk have same length and the length
is ~10cm longer then all other RGMII traces. This sounds as very special design and it sounds not so
realistic.
2. there is something special about PHY and/or MAC. this one is more realistic.

The PHY id is hard coded, so we can find the datasheet:
http://pdf.eepw.com.cn/i20090903/8d594ec98b62289dd0d3cd17fc8ffdd1.pdf
Page 46:
Ts3,
- if TXPHASE_SEL=0, then clock is shifted by -0.65 ns
- if TXPHASE_SEL=1, then clock is shifted by  1.35 ns

Td3
- if RXPHASE_SEL=0, then clock is shifted by  0,4 ns
- if RXPHASE_SEL=1, then clock is shifted by  2.4 ns

It means, if driver supports rgmii-id, the PHY configuration will be out of spec. 1.35 ns delay is
not enough. Ok, so designer has two options:
- combine two delays: rgmii-id + mediatek,tx-delay-ps. In this case by review I personally would
ask: why?!
- or rgmii-rxid + mediatek,tx-delay-ps
In any case, both options are OK.

So, why mediatek,tx-delay-ps = <1530>? 1.5 is not enough for RGMII.
In case of rgmii-rxid internal PHY clk skew will be -0.65 ns. Hard to say, if it is typo, but 1530 +
650ps will be 2180, which is enough for RGMII.

This make sense so far and confirms my claim: most of embedded boards have nearly equal RGMII traces
and there is no need for fine tuning. I doubt that that provided delay information is a good place
for the board specific device tree. The delay calculation could be solved between MAC and PHY
driver, in case both of them would provide needed information.

I can take apart many more dts files, but the result will be in most cases very similar. There is no
good reason to set this information in the devicetree and many developers are making mistakes by
copypasting it to other boards.

> You will notice in picroseconds and also not 2800.
>
> When delay is controlled by the PHY, then there are properties like:
>
>      - rxc-skew-ps : Skew control of RXC pad
>      - txc-skew-ps : Skew control of TXC pad
>
> Also in picoseconds.  A search of existing device trees will show it
> is not always 2800 either.
 >>
>> Normally we use phy-mode with predefined values:
>> - rgmii == tx/rx delay is 0
>> - rgmii-id == PHY configures tx and rx delays to closest possible values to 2.8ns
>> - rgmii-txid == PHY configures only tx delay to 2.8ns, rx is 0
>> - rgmii-rxid == same as rgmii-txid but for rx.
>>
>> Using raw values or fine tuning this delays makes no sense in 99% cases.
 >
> I agree today, rgmii-id is the normal configuration and usually works
> with no further modification.
>
> For a new board design, I think running though the delay test is a
> valuable part of validating the RGMII design of the board.  Just
> because the 20 prototype boards all work at room temperature does not
> mean the million you make afterward will have a 0% failure rate over
> the full spec temp range.

Good point and it confirms my claim: this information should not be set in the devicetree, at least
not as delay. Instead we probably should use trace properties. It should be automatically calculated
by drivers and in your example, automatically compensated by the temperature. Especially if we are
talking about temperature range of -50 to 100C

>> As I already said, except of delays there can be other issue. For example:
>> - incorrect pinmux configuration
>> - incorrect RGMII clock source configuration
>> - incorrect MAC or PHY mode configuration (xMII instead of RGMII)
>> - incorrect reset or power up sequence affecting proper bootstrap configuration.
>> - incorrect MDIO configuration, for example CLK rate outside of range supported by the PHY.
>> - not properly configured SoCs internal clock dependencies.
>> - some missing "enable" bit on the PHY or the MAC side
>
> If all one knows is ethernet doesn't work, then I think all of those
> problems above are more likely the problem than a need to fine tune
> the RGMII delays.

ack.

--
Regards,
Oleksij

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

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

[Trent Piepho]

On Sun, Apr 10, 2022 at 8:00 AM Oleksij Rempel <linux@rempel-privat.de> wrote:
>
> The PHY id is hard coded, so we can find the datasheet:
> http://pdf.eepw.com.cn/i20090903/8d594ec98b62289dd0d3cd17fc8ffdd1.pdf
> Page 46:
> Ts3,
> - if TXPHASE_SEL=0, then clock is shifted by -0.65 ns
> - if TXPHASE_SEL=1, then clock is shifted by  1.35 ns

I do not think that is what they are saying.  Page 38,

TXPHASE_SEL  1: An intentional delay is added on GTX_CLK/ TXC (about
2ns delay in 1000BASE-T, and about 4ns delay in 100BASE-TX and
10BASE-T)

So they add 0 or 2 ns, which makes sense for internal delay added or not.

The table on page 46 is not clock shift, but the required setup time.
The sign is backward from how I would have expected it.  But if the
sign is inverted, then setup time + hold time is constant for both
values of clock delay, which is how it should be.  So when they say
-0.65 ns, what that means is TXD must be stable 0.65 ns before TXC
edge.  RGMII spec is that min setup time at receiver is 1.0 ns, but a
PHY can be better than the spec.  ~0.5 ns is typical.  If TXC is
delayed by 2 ns, then TXD can be stable 1.35 ns _after_ TCX edge and
this still meets the setup time of 0.65 ns.

> So, why mediatek,tx-delay-ps = <1530>? 1.5 is not enough for RGMII.
> In case of rgmii-rxid internal PHY clk skew will be -0.65 ns. Hard to say, if it is typo, but 1530 +
> 650ps will be 2180, which is enough for RGMII.

It doesn't make sense to me to add setup time to delay like that.  It
does produce a value that is the right range, but I think this is just
a coincidence.

>From PHY spec, we have 0.65 ns setup time and 0.2 ns hold time with 4
ns clock period (DDR), with 5% allowed variation (per RGMII).  So the
valid delay range is 0.65 ns to 3.6 ns.  But there are other factors
that reduce this range.  See calculation in section 3 here,
https://www.ti.com/lit/pdf/snla243

So maybe they did this and determined 1.53 ns delay will maximise
setup and hold margin.  Or maybe they copied that value from somewhere
and there is no good reason.

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

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

[Frank Wunderlich]

Hi,

it turned out that my problem is not wrong setting...it was the load method.

i loaded barebox by uboot like it's documented here:

https://www.barebox.org/doc/latest/user/barebox.html#starting-barebox

except i have loaded files via fatload and not tftp.

if i flash barebox and boot directly into it, network works (also with first version of dts with rx-delay/tx-delay and rgmii phy_mode).

barebox@BPI R2PRO:/ dhcp eth1
eth1: 1000Mbps full duplex link detected
WARNING: eth1: No MAC address set. Using random address 92:26:6a:9c:ec:d5
T T T eth1: DHCP client bound to address 192.168.0.104
barebox@BPI R2PRO:/ ping 192.168.0.10
PING 192.168.0.10 (192.168.0.10)
host 192.168.0.10 is alive

so imho there are 2 possible rootcauses

- uboot has initialized anything (clocks/pinctrl/...) which barebox cannot change afterwards (due to missing reset)
- barebox skips any initialization step if it is chainloaded

i have now tested both configurations (rgmii+delays and rgmii-id without delay-properties, but delays set in driver). linux is already updated in next to the rgmii+delays part, so i would send this as update to barebox.

regards Frank

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