Mity CPU Platforms » MitySOM-5CSX Altera Cyclone V

What PHY are you using?

This sounds a lot like the PHY is maybe getting held in reset. Do you have a GPIO connected to the PHY reset pin? Can you scope that pin?

When linux boots, if you connect a network connection to the port, do the PHY leds (or the leds on the other end) indicate a link is established? If the LEDs do not, then that is likely it.

-Mike

Hi Mike
I believe the PHY is the same as the dev board, but I'll need to confirm that.

The activity LED for the PHY flashes during U-Boot start-up and then once for every ping out from U-Boot.
During Linux start-up I think I see the activity LED flash once maybe, and after start-up it flashes when I disconnect and reconnect the Ethernet cable to my PC.

Something else I tried was perform a PHY reset within Linux, by clearing and setting GPIO28 (gpio130 provided by gpiochip102).
When I did this both PHY LEDs go off and soon come back with the activity LED flashing a few times like it does for U-Boot start-up.

I think this tells me that the PHY is OK and not being held in reset?

We had Thomas Catalino visit us today and during the conversation he mentioned pin multiplexing - could that be related?
But in that respect I don't think our hardware design differs much from the dev kit.

Any other ideas?

Sounds like reset is working properly.

Are the MDIO pins connected the same way as for the Dev Kit?

Have you updated the preloader for your FPGA build?

The device is the Microchip/Micrel KSZ9031RNX, which I believe is the same as the Dev Kit.
The MDIO pins are connected like the Dev Kit except that as recommended by Microchip there is a 1K MDIO pullup instead of 10K as on the Dev Kit.

The SD Card builds I tested today on our board were:
(1) Unchanged Preloader & FPGA image based on 4YA_release_2011_11_05_17_28 then the Kernel rebuilt from socfpga-3.16 (but with CAN and USB removed)
(2) As (1) but with our FPGA image and preloader built from our handoff files.

Again, stopping in U-Boot allows ethernet activity, but in Linux both builds resulted in
constantly reporting the same errors, which cannot be stopped (say with /etc/init.d/networking stop):
stmmac_init_phy: of_phy_connect_failed
stmmac_open: Cannot attach to PHY (error: -19)

In U-Boot I also set the kernel loglevel=7 (max) and saw one more error:
SIOCSIFFLAGS: No such device

I've just seen this post [[https://support.criticallink.com/redmine/boards/45/topics/3796]], but I don't know how relevant it is.

Seeing as u-boot works correctly and linux doesn't I believe this has to do with the PHY ID. u-boot will just probe all possible IDs on the MDIO interface until it finds one but unluckily linux requires you to specify it in the device tree and if it doesn't find one at the ID you set it will give you the stmmac_open: Cannot attach to PHY (error: -19) error.

I would recommend the following to find out what the board believes is your PHY ID:

1. boot to u-boot
2. make sure you have ethernet activity
3. use the mii dump [id] command to find your PHY ID valid ids are 0 to 31

Example of a dump that isn't a phy:

MitySOM-5CSx # mii dump 1 0
0.     (ffff)                 -- PHY control register --
  (8000:8000) 0.15    =     1    reset
  (4000:4000) 0.14    =     1    loopback
  (2040:2040) 0. 6,13 =   b11    speed selection = 10 Mbps
  (1000:1000) 0.12    =     1    A/N enable
  (0800:0800) 0.11    =     1    power-down
  (0400:0400) 0.10    =     1    isolate
  (0200:0200) 0. 9    =     1    restart A/N
  (0100:0100) 0. 8    =     1    duplex = full
  (0080:0080) 0. 7    =     1    collision test enable
  (003f:003f) 0. 5- 0 =    63    (reserved)

Example of a dump that is a phy:

MitySOM-5CSx # mii dump 7 0
0.     (1140)                 -- PHY control register --
  (8000:0000) 0.15    =     0    reset
  (4000:0000) 0.14    =     0    loopback
  (2040:0040) 0. 6,13 =   b10    speed selection = 1000 Mbps
  (1000:1000) 0.12    =     1    A/N enable
  (0800:0000) 0.11    =     0    power-down
  (0400:0000) 0.10    =     0    isolate
  (0200:0000) 0. 9    =     0    restart A/N
  (0100:0100) 0. 8    =     1    duplex = full
  (0080:0000) 0. 7    =     0    collision test enable
  (003f:0000) 0. 5- 0 =     0    (reserved)

Once you determine what your phy id is then you will need to change it in the device tree in the following node:

        mdio1: mdio@ff702000 {
            status = "okay";
            #address-cells = <1>;
            #size-cells = <0>;
            phy0: ethernet-phy@0 {
                reg = <0x3>;
                device_type = "ethernet-phy";
                compatible = "ethernet-phy-ieee802.3-c22";
            };
        };

The phy ID is set in the reg of the phy0 node.

Hi
Thanks for that information - that was it!
U-Boot 'mii dump' command reports that the Dev Kit has a PHY ID of 3 but our board has a PHY ID of 2.

BUT ... it looks like the Dev Kit was designed for the PHY ID to be 2 but turned out to be 3 and so the Device Tree file reflects this.
We found that the Dev Kit has an LED in the magnetics with a low value resistor (130R?), which causes the PHYAD0 NOT to be pulled down at reset but just drop a little in voltage. This causes the PHY to read this pin as a high, not low as suggested by the schematic.
Our hardware design regarding the KSZ9031RNX PHY is the same as the Dev Kit except that the LED resistor is 3K, which allows the pull-down to work thus allowing PHYAD0 to go low.

I updated socfpga_mitysom5csx-h6-4ya_devkit.dts so that for phy0 entry, reg = <0x2> instead of reg = <0x3>. I then rebuilt the DTB and deployed it on the SD Card that we're booting from. The mitysom then successfully booted into Linux with no errors and having eth0 available.

Thanks
Mat