Is there any change phy driver in rel 36.x?

[kcs0421]

hello, experts

In rel 35.5.0, it was confirmed that ethernet status LED is controlled by adding a code to the phy driver.
When I read the LED register, I confirmed that the value was written correctly.

but in rel 36.4, I added the code to the same location of the same phy driver, but ethernet status LED is not controlled.
When I read the LED register after adding the code, the value was still set to 0x0000.

I checked that .ko module was created after compiling the phy driver.
Are there any changes or differences between the 35.x and 36.x versions in phy driver?

I use custom carrier board for AGX ORIN.

** The phy driver I modified is aquantia_main.c.

Thanks.

[carolyuu]

Hi,
Here are some suggestions for the common issues:

1. Performance

Please run the below command before benchmarking deep learning use case:

$ sudo nvpmodel -m 0
$ sudo jetson_clocks

2. Installation

Installation guide of deep learning frameworks on Jetson:

• TensorFlow: Installing TensorFlow for Jetson Platform - NVIDIA Docs
• PyTorch: Installing PyTorch for Jetson Platform - NVIDIA Docs
  We also have containers that have frameworks preinstalled:
  Data Science, Machine Learning, AI, HPC Containers | NVIDIA NGC

3. Tutorial

Startup deep learning tutorial:

• Jetson-inference: Hello AI World guide to deploying deep-learning inference networks and deep vision primitives with TensorRT and NVIDIA Jetson
• TensorRT sample: Jetson/L4T/TRT Customized Example - eLinux.org

4. Report issue

If these suggestions don’t help and you want to report an issue to us, please attach the model, command/step, and the customized app (if any) with us to reproduce locally.

Thanks!

[kcs0421]

Hi carolyuu!
I think there’s a misunderstanding.
I’m not referring to deep learning and machine learning, but phy driver.

[WayneWWW]

One basic question first.

Are you sure the driver code you modify really takes effect in the driver code?

For example, if you add print in the driver code, did you see those print appeared in your log?

[kcs0421]

Hi Wayne,

Yes, I think It takes effect in the aquantia_main.c.
I added a pr_info in theaquantia_main.c, and confirmed that it is displayed in the dmesg log.

[WayneWWW]

Then have you used MDIO tool to read back the value you wrote and see if it took effect in PHY?

[kcs0421]

Hi, Wayne

I used the “phytool” mdio tool to read the registers related to the LED.
sudo phytool read eno1/0:0x1e/0xc430
sudo phytool read eno1/0:0x1e/0xc431
sudo phytool read eno1/0:0x1e/0xc432

but the values were still “0x0000”.

Using “phytool,” if I directly write a value to the register with the command
sudo phytool write eno1/0:0x1e/0xc430 0xc0ef
sudo phytool write eno1/0:0x1e/0xc430 0x0080
sudo phytool write eno1/0:0x1e/0xc430 0xc040, the LED functions properly.

Thanks.

[WayneWWW]

Then have you read the register in the phy driver directly to make sure if it really has successful read/write there?

[kcs0421]

Hi Wayne,

I used “phy_read_mmd” in the phy driver to directly read the register.

In the dmesg log, I think the values in the register are successfully written and read.

Here are the dmesg logs and the modified phy driver.
dmesg.txt (64.6 KB)
aquantia_main.zip (7.9 KB)

[WayneWWW]

Then that sounds something else overwrite or reset the phy reg later. You may need to find it out