• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 275 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM6442: PRUETH on mainline

Andy Green
Prodigy 70 points
Part Number: AM6442


Tool/software:

Hi -

We are successfully using mainline (6.11-rc2 at the moment) with am6442, on a Phytec EVB.

We are able to use the onboard eth0 / PHY that is on the SOM okay.

We have forward-ported from the 6.1 BSP kernel the pieces related to PRU / PRUETH, the DP83867 PHY support, the related MDIO, and the dts pieces to glue it together, and the firmware from the 6.1 BSP uSD that came with the EVM in order to enable the other two RJ45s on the EVM.  Both channels of the PRUETH are enabled same as the 6.1 version (although it needed ti,iep rather than iep on mainline).

This is close to working but we are not quite getting the cigar at the moment.

eth1 and eth2 netdevs appear, we can set addresses etc, and they are bound to the phy, but there is no linkup.  We found that we can use ethtool to turn off autoneg, and the switch it is connected to will light up; but any idea of a link is bogus, there is no continuous traffic on the ethernet side and it states the link is 10Mbps (it's a 1Gbps switch).

PRU firmware is being loaded, I also forward-ported the missing M4F support from 6.1 BSP kernel and that firmware is also loaded, in phytec case this does a "heartbeat" on a SOM LED, but didn't solve the PHY situation.

Booting from the 6.1 BSP build, it all works with same switch, cables, EVM, so it seems something missing on the software side.

Any ideas?

Thanks

  • 0
    Prodigy 70 points

    These problems seem to boil down to REFCLK1 from the SoC is 50MHz on our build; it's driven with 25MHz on the Phytec BSP.

    It seems this ball on the SoC is driven from the SoC in both cases.

    I cannot find any information on how to control what rate appears on REFCLK1 when it is used as an output, in the rev H reference manual.  There's a lot of information about selecting it as in input clock to various IPs.

    Comparing /sys/kernel/debug/clk_summary on both builds, there are no clocks that change from 25MHz -> 50MHz.

    Is the rate for this perhaps changed in U-Boot?  The clock is only driven after the linux driver for PRUETH starts, but it looks like the rate was set before?  How should I set the rate for it?

  • 0 in reply to Andy Green
    Prodigy 70 points

    For future humans puzzled by similar mysteries, the reference manual calls this signal by "CLKOUT" meaning you're not going to find it using "REFCLK1".  In the rev H reference manual, the solution is on page 2220

    The drivers leave it alone because on ethernet boot path, this is set by the ROM according to BOOTMODE pins.  So the problem was solved hacking in a mw.l 43008010 1  into U-Boot.