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
Gesendet: Mittwoch, 23. März 2022 um 10:03 Uhr
Von: "Ahmad Fatoum" <a.fatoum@xxxxxxxxxxxxxx>
An: "Frank Wunderlich" <frank-w@xxxxxxxxxxxxxxx>
Cc: barebox@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxx>
An: frank-w@xxxxxxxxxxxxxxx, barebox@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox
--
Regards,
Oleksij
_______________________________________________
barebox mailing list
barebox@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox
