UEFI RGMII

Robotics & Edge Computing Jetson & Embedded Systems Jetson AGX Orin
,
1

Hi,
Is there any way to make the RGMII via ETH Phy 88E1512 work in UEFI?
It works perfectly in Tegra at kernel runtime, but the UEFI debug says that it cannot be reset.

I/TC: WARNING: UEFI variable protection is not fully enabled !
I/TC: WARNING: Test UEFI variable auth key is being used !
I/TC: WARNING: UEFI variable protection is not fully enabled !
  Failed to get BMC Boot Options Parameter 4 (IPMI CompCode = 0x0)
Waiting for driver 2 of 2 to complete
.SNP:PHY: PhyDxeInitialization () Failed to reset Phy
EqosDeviceDxe:DeviceThreadMain, driver returned Device Error to start notification

Thanks

5

Hi velorin0,

Are you using the devkit or custom board for AGX Orin?
What’s the Jetpack version in use?

I don’t get those errors on AGX Orin devkit.
Are you trying to port custom PHY on AGX Orin?
If so, I would suggest you asking the help from your vendor for those porting works in UEFI.

6

Hi Kevin,

It is a custom board that we produce (no eeprom - not sure if this is relevant). The PHY we use is ETH Phy 88E1512. Jetpack 6.1.
So you suggest there is a hardware issue? Because I doubt there is since it works perfectly afterwards (after the kernel boots).

The UEFI I build following edk2 instructions, but only for logo change, did not removed any components.

7

Device tree in use should be same for UEFI and kernel. Are you sure you did the fill flash but not only flashing kernel?

8

The flashing command I used is this:

 sudo ./flash.sh <board> internal

The configuration inside <board>.conf, TBCDTB_FILE is the same as DTB_FILE (TBCDTB_FILE="${DTB_FILE}").

flash_log.log (564.6 KB)

9

Did you ever validate this on rel-35 before?

10

No, should I?

11

Could you share the device tree setting you did for RGMII?

12 
ethernet@2310000 {
			status = "okay";
			phy-mode = "rgmii-id";
			phy-handle = <&phy>;
			
			nvidia,phy-reset-gpio = <&gpio TEGRA234_MAIN_GPIO(G, 5) 0>;

			nvidia,mac-addr-idx = <0>;
			nvidia,skip_mac_reset = <0>;
			nvidia,mdio_addr = <0>;
			nvidia,pause_frames = <0>;
			nvidia,max-platform-mtu = <0x2328>;

			mdio0: mdio {
				compatible = "nvidia,eqos-mdio";
				#address-cells = <1>;
				#size-cells = <0>;

				// Notes:
				// Changed PHY address to 0 Check schematic for CONFIG pin (initially was 1)
				phy: phy@0 {
					reg = <0>;
					nvidia,phy-rst-pdelay-msec = <224>; /* msec */
					nvidia,phy-rst-duration-usec = <10000>; /* usec */
					interrupt-parent = <&gpio>;
					interrupts = <TEGRA234_MAIN_GPIO(G, 4) IRQ_TYPE_LEVEL_LOW>;
					
					// marvell,copper-mode;
					marvell,reg-init =	<0x3 0x10 0x0 0x16>;
										// <0x3 0x12 0x7fff 0x880>;

				};
			};
  
		};
14

It seems we don’t have RGMII on AGX Orin by default, but we have it on AGX Xavier so that Wayne asked if you’ve also verified it with R35.

Your current device tree settings for phy looks good to us.
UEFI is dtb driven.
Please provide the full device tree and also the full boot log with debug UEFI logs enabled.

15

Please see below:
DT.dts.txt (317.0 KB)
boot_debug.log (160.4 KB)

Not sure if relevant but, one thing that I noticed. I tried to use another DT for the UEFI where the only difference compared to the kernel DT was that the RGMII node was disabled. I included an FDT entry in extlinux to use the kernel DT (with the node enabled). But for unknown reason, the nvethernet could not probe the PHY anymore (-2 error). Although the running device tree stated that the node is enabled. So the FDT entry is not ignored, but for some reasone the device was not working. Very weird behavior that I do not know if is supposed to happen.

The only way that the device works is with both DT being the same. But in that case, it works only in the kernel and in UEFI not. PhyDxeInitialisation throws that reset error.

16 
.SNP:PHY: PhyDxeInitialization () Failed to reset Phy

About above error, could you add more debug messages to PhyReset() in PhyDxeUtil.c to check why it fails.

From your original post, it seems you want it working in UEFI. Why you try to disable it in the DTB used for UEFI?
Please help to clarify your use case. If it can work after boot up, why you need to enable it in UEFI?

1 Like
17

OK, It seems to be caused by PhySoftReset timeout.

Waiting for driver 2 of 2 to complete
.SNP:PHY: ERROR! PhySoftReset timeout
-----velorin0: PhySoftReset failed: Time out
SNP:PHY: PhyDxeInitialization () Failed to reset Phy
EqosDeviceDxe:DeviceThreadMain, driver returned Device Error to start notification

It seems that the waiting is caused by the fact that the do-while loop inside PhySoftReset() is never broken by the PHYCTRL_RESET to become zero (as per comment):

    // Wait until PHYCTRL_RESET become zero
    if ((Data32 & REG_PHY_CONTROL_RESET) == 0) {
      break;
    }

therefore the loop is broken only when timeout is reached.

At the beginning I wanted the interface working only in the kernel. Doing so, the boot time is really long due to this error in UEFI. So I tried disabling it in UEFI dtb, but as you see, by doing so, it is somehow disabled also in the kernel, although I used different dtbs and fdt entry.
Nevertheless, this does not matter anymore, because later it has been decided that we need it in UEFI also. So right now the need is to be working in both UEFI and kernel.

18

What’s the PHY_TIMEOUT in your case? 200ms?
If so, could you try modify it to other value in PhyDxeUtil.h?

What’s the reason that you need it in UEFI?
Have you tried to disable them through the configuration file in UEFI source?

19

I have not change the code in this regard. This is the original definition form edk2 repo. Assuming it is define din microseconds, then yes, it is 200ms.

#define PHY_TIMEOUT  200000

But this value is way too low to cause any major delays. To what value should I set it?

There is another function called after the if, namely DeviceDiscoveryThreadMicroSecondDelay (1);. The description states that is switches to main thread for at least the given number of microseconds.

From my point of view, it is more likely that this will induce the extra delay (In addition to the REG_PHY_CONTROL_RESET not becoming 0).

Network Booting

Could you guide me what configuration file?

20

Sorry that we don’t have your setup so that we cannot guide you to port them.

Do you have this requirement in your use case?

You can find some fdf/inc/dsc files under edk2-nvidia/Platform/NVIDIA/ and you can disable networking stack there.

21

Of course you do not have it because I have not specified anything in this regard. Please specify what info you need and I will provide it to you, if possible.

Yes, I do. But if this is not possible please confirm it here, so we will stop lookin in this direction.

I will do this as soon as you confirm that there are issues in UEFI from your side and at the moment the network is unusable.

22

The network boot is available on the dekvit, which is also called nfs.
You can find more details in Flashing Support — NVIDIA Jetson Linux Developer Guide 1 documentation.

Sorry that custom usage like RGMII for phy is not owned by us so that I can’t give you the answer for this.

1 Like
24

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.