[PATCH v2 0/5] powerpc, mpc83xx: add DM_ETH support

[Heiko Schocher]

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 at 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 at 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: hs at denx.de