Hello Rasmus,
Am 24.09.2020 um 08:55 schrieb Rasmus Villemoes:
On 23/09/2020 07.02, Heiko Schocher wrote:
Hi Rasmus,
Am 22.09.2020 um 16:34 schrieb Rasmus Villemoes:
The board already used OF_CONTROL, so I've tried extending the device-tree based partly on you changes for the km boards, partly from our linux device tree - the two mostly agree:
+ qe: qe@e0100000 { + #address-cells = <1>; + #size-cells = <1>; + device_type = "qe"; + compatible = "fsl,qe"; + ranges = <0x0 0xe0100000 0x00100000>; + reg = <0xe0100000 0x480>;
Does this work with linux? If so, it should be OK....
I miss something like:
https://gitlab.denx.de/u-boot/u-boot/-/commit/7bdfe8592956439743cad3c2d3ff5f...
Important here:
&qe { compatible = "fsl,qe", "simple-bus"; };
That helped, thanks. In our linux device tree we just have "fsl,qe", which works because linux has an actual driver for that. Is there a reason you didn't just include the "simple-bus" string in the .dtsi files, instead of fixing it in each .dts that includes the .dtsi?
No, seems there is more room for optimizations :-)
The defconfig is updated with
CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT=1 CONFIG_PHYLIB=y CONFIG_PHY_MARVELL=y +CONFIG_DM_ETH=y +CONFIG_DM_MDIO=y +CONFIG_DM_ETH_PHY=y CONFIG_MII=y +CONFIG_QE_UEC=y
Looks good...
So, I also added CONFIG_PHY_FIXED, and changed from the deprecated old-style
fixed-link = <1 1 100 0 0>;
(which I can't find any U-Boot code that would parse) to the new-style
fixed-link { speed = <100>; full-duplex; };
Ok!
Perhaps I need to explain a little more about the board: It has a marvell 88e6250 switch, the above fixed-link is from one of the cpu's ethernet devices to the switch's cpu port. In order to get traffic flowing, we used to manually do a few mii commands to instruct the switch to open the cpu port and one specific outwards port, i.e. we have something like
phy1_up=mii write 17 19 3100; mii write 17 18 9620; mii write 19 04 007F cpu_up=mii write 1D 01 0033; mii write 1D 04 007F > prep_switch=mii device UEC2; run phy1_up cpu_up ...
Why not adding this into a phy driver?
So I used to be able to do
=> run prep_switch => ping $serverip UEC: PHY is Fixed PHY (ffffffff) UEC0: Full Duplex UEC0: Speed 100BT UEC0: Link is up Using UEC0 device host 192.168.174.2 is alive
Now, I've updated the prep_switch etc. commands to use "mdio write mdio@2120 ...", and that part I think works - when I run the phy1_up, the link LED does get lit, and using mdio read I can read back both the registers I wrote as well as the switch's identification registers, so I'm pretty sure I'm talking to the right thing. But when I then try the ping command, nothing:
=> ping $serverip ping failed; host 192.168.174.2 is not alive
Any hints?
So, you see that your ethernet and so also mdio driver is probed?
Can you post a "dm tree" output?
Without looking onto hardware it is hard to say ... you need to debug into ethernet driver, may compare register setup with old driver....
May a problem with pinsetup? Or clock setup?
bye, Heiko