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/7bdfe8592956439743cad3c2d3ff5f24c4dd5aa9#8fd63f1c0ee54bb5ed6e0446595997296ab56205
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
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: [email protected]
