[PATCH 0/2] net: tegra: Misc network fixes
From: Tom Warren twarren@nvidia.com
These two patches are from downstream Tegra L4T U-Boot.
Tom Warren (2): net: rt8169: WAR for DHCP not getting IP after kernel boot/reboot tegra: Enable CONFIG_BOOTP_PREFER_SERVERIP for all Jetson boards
configs/e2220-1170_defconfig | 1 + configs/p2371-0000_defconfig | 1 + configs/p2371-2180_defconfig | 1 + configs/p2571_defconfig | 1 + configs/p2771-0000-000_defconfig | 1 + configs/p2771-0000-500_defconfig | 1 + drivers/net/rtl8169.c | 16 ++++++++++++++++ 7 files changed, 22 insertions(+)
From: Tom Warren twarren@nvidia.com
This is a WAR for DHCP failure after rebooting from the L4T kernel. The r8169.c kernel driver is setting bit 19 of the rt816x HW register 0xF0, which goes by FuncEvent and MISC in various driver source/datasheets. That bit is called RxDv_Gated_En in the r8169.c kernel driver. Clear it here at the end of probe to ensure that U-Boot can get an IP assigned via DHCP.
Signed-off-by: Tom Warren twarren@nvidia.com --- drivers/net/rtl8169.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)
diff --git a/drivers/net/rtl8169.c b/drivers/net/rtl8169.c index 5ccdfdd..ff89e28 100644 --- a/drivers/net/rtl8169.c +++ b/drivers/net/rtl8169.c @@ -237,6 +237,9 @@ enum RTL8169_register_content {
/*_TBICSRBit*/ TBILinkOK = 0x02000000, + + /* FuncEvent/Misc */ + RxDv_Gated_En = 0x80000, };
static struct { @@ -1207,6 +1210,19 @@ static int rtl8169_eth_probe(struct udevice *dev) return ret; }
+ /* + * WAR for DHCP failure after rebooting from kernel. + * Clear RxDv_Gated_En bit which was set by kernel driver. + * Without this, U-Boot can't get an IP via DHCP. + * Register (FuncEvent, aka MISC) and RXDV_GATED_EN bit are from + * the r8169.c kernel driver. + */ + + u32 val = RTL_R32(FuncEvent); + debug("%s: FuncEvent/Misc (0xF0) = 0x%08X\n", __func__, val); + val &= ~RxDv_Gated_En; + RTL_W32(FuncEvent, val); + return 0; }
On 3/17/20 2:07 PM, twarren@nvidia.com wrote:
From: Tom Warren twarren@nvidia.com
This is a WAR for DHCP failure after rebooting from the L4T kernel. The r8169.c kernel driver is setting bit 19 of the rt816x HW register 0xF0, which goes by FuncEvent and MISC in various driver source/datasheets. That bit is called RxDv_Gated_En in the r8169.c kernel driver. Clear it here at the end of probe to ensure that U-Boot can get an IP assigned via DHCP.
Is there a way to reset the entire chip back to power-on state instead, just to make sure there aren't any other register bits that might cause issues in the future?
Does this bit exist in all the different chips that the driver supports? IIRC at least the Linux r8169 driver supports many different similar chips; I'm not sure if the U-Boot driver does too. Since this driver is shared between many boards in U-Boot, we need to make sure this change doesn't break anyone using a different Realtek chip to the exact one we use on Jetson.
We need to send this patch to the network maintainers so they're aware of it, and they'll probably want to apply it.
@@ -1207,6 +1210,19 @@ static int rtl8169_eth_probe(struct udevice *dev)
- u32 val = RTL_R32(FuncEvent);
- debug("%s: FuncEvent/Misc (0xF0) = 0x%08X\n", __func__, val);
- val &= ~RxDv_Gated_En;
- RTL_W32(FuncEvent, val);
I vagueley recall that U-Boot coding style wants variables declared at the start of the block, but perhaps that's no longer true. What does scripts/checkpatch.pl say?
-----Original Message----- From: Stephen Warren swarren@wwwdotorg.org Sent: Wednesday, March 18, 2020 4:30 PM To: Tom Warren TWarren@nvidia.com Cc: u-boot@lists.denx.de; Stephen Warren swarren@nvidia.com; Thierry Reding treding@nvidia.com; Jonathan Hunter jonathanh@nvidia.com; tomcwarren3959@gmail.com Subject: Re: [PATCH 1/2] net: rt8169: WAR for DHCP not getting IP after kernel boot/reboot
External email: Use caution opening links or attachments
On 3/17/20 2:07 PM, twarren@nvidia.com wrote:
From: Tom Warren twarren@nvidia.com
This is a WAR for DHCP failure after rebooting from the L4T kernel. The r8169.c kernel driver is setting bit 19 of the rt816x HW register 0xF0, which goes by FuncEvent and MISC in various driver source/datasheets. That bit is called RxDv_Gated_En in the r8169.c kernel driver. Clear it here at the end of probe to ensure that U-Boot can get an IP assigned via DHCP.
Is there a way to reset the entire chip back to power-on state instead, just to make sure there aren't any other register bits that might cause issues in the future? [Tom] Maybe, I'll have to look at the RTL spec, it's been awhile since I came up with this WAR.
Does this bit exist in all the different chips that the driver supports? IIRC at least the Linux r8169 driver supports many different similar chips; I'm not sure if the U-Boot driver does too. Since this driver is shared between many boards in U-Boot, we need to make sure this change doesn't break anyone using a different Realtek chip to the exact one we use on Jetson. [Tom] I'll look into it after I get Nano patches all in place upstream. If anyone runs into the problem described here w/no IP on net boot, they can use this as a WAR until I try for a more robust fix.
We need to send this patch to the network maintainers so they're aware of it, and they'll probably want to apply it. [Tom] Will do.
@@ -1207,6 +1210,19 @@ static int rtl8169_eth_probe(struct udevice *dev)
u32 val = RTL_R32(FuncEvent);debug("%s: FuncEvent/Misc (0xF0) = 0x%08X\n", __func__, val);val &= ~RxDv_Gated_En;RTL_W32(FuncEvent, val);
I vagueley recall that U-Boot coding style wants variables declared at the start of the block, but perhaps that's no longer true. What does scripts/checkpatch.pl say? [Tom] I don't recall, I'll run it again and see.
----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------
On Tue, Mar 17, 2020 at 01:07:15PM -0700, twarren@nvidia.com wrote:
From: Tom Warren twarren@nvidia.com
This is a WAR for DHCP failure after rebooting from the L4T kernel. The r8169.c kernel driver is setting bit 19 of the rt816x HW register 0xF0, which goes by FuncEvent and MISC in various driver source/datasheets. That bit is called RxDv_Gated_En in the r8169.c kernel driver. Clear it here at the end of probe to ensure that U-Boot can get an IP assigned via DHCP.
Signed-off-by: Tom Warren twarren@nvidia.com
drivers/net/rtl8169.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)
Is this still needed? In my old p3450 branch that I worked on to get Porg up and running I don't have this patch. It's also not in my local development tree that I typically use to boot Tegra186 and earlier boards. That branch works fine on the Jetson Nano, so I don't think this is needed anymore. I vaguely recall that I determined that this was fixed some other way, but unfortunately I don't remember the exact details.
Thierry
-----Original Message----- From: Thierry Reding treding@nvidia.com Sent: Thursday, March 19, 2020 1:04 AM To: Tom Warren TWarren@nvidia.com Cc: u-boot@lists.denx.de; Stephen Warren swarren@nvidia.com; Jonathan Hunter jonathanh@nvidia.com; tomcwarren3959@gmail.com Subject: Re: [PATCH 1/2] net: rt8169: WAR for DHCP not getting IP after kernel boot/reboot
On Tue, Mar 17, 2020 at 01:07:15PM -0700, twarren@nvidia.com wrote:
From: Tom Warren twarren@nvidia.com
This is a WAR for DHCP failure after rebooting from the L4T kernel. The r8169.c kernel driver is setting bit 19 of the rt816x HW register 0xF0, which goes by FuncEvent and MISC in various driver source/datasheets. That bit is called RxDv_Gated_En in the r8169.c kernel driver. Clear it here at the end of probe to ensure that U-Boot can get an IP assigned via DHCP.
Signed-off-by: Tom Warren twarren@nvidia.com
drivers/net/rtl8169.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)
Is this still needed? In my old p3450 branch that I worked on to get Porg up and running I don't have this patch. It's also not in my local development tree that I typically use to boot Tegra186 and earlier boards. That branch works fine on the Jetson Nano, so I don't think this is needed anymore. I vaguely recall that I determined that this was fixed some other way, but unfortunately I don't remember the exact details.
Thierry [Tom] I'll retest as part of my Nano rework of your original patch, Thierry. So you've done network boot, then rebooted from the kernel (sudo reboot), and attempted net boot again and seen it work OK, w/an IP assigned by DHCP, etc.? (not static IP). It's also possible that something in the kernel RT8169 driver has changed, and it's not setting the bit anymore.
----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------
From: Tom Warren twarren@nvidia.com
This allows the user to set $serverip in the environment before executing a DHCP request. If they do, U-Boot will use that IP rather than using the IP in the DHCP response.
Signed-off-by: Tom Warren twarren@nvidia.com --- configs/e2220-1170_defconfig | 1 + configs/p2371-0000_defconfig | 1 + configs/p2371-2180_defconfig | 1 + configs/p2571_defconfig | 1 + configs/p2771-0000-000_defconfig | 1 + configs/p2771-0000-500_defconfig | 1 + 6 files changed, 6 insertions(+)
diff --git a/configs/e2220-1170_defconfig b/configs/e2220-1170_defconfig index 1639040..951ed1d 100644 --- a/configs/e2220-1170_defconfig +++ b/configs/e2220-1170_defconfig @@ -43,3 +43,4 @@ CONFIG_CI_UDC=y CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y +CONFIG_BOOTP_PREFER_SERVERIP=y diff --git a/configs/p2371-0000_defconfig b/configs/p2371-0000_defconfig index 2070199..7081719 100644 --- a/configs/p2371-0000_defconfig +++ b/configs/p2371-0000_defconfig @@ -44,3 +44,4 @@ CONFIG_CI_UDC=y CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y +CONFIG_BOOTP_PREFER_SERVERIP=y diff --git a/configs/p2371-2180_defconfig b/configs/p2371-2180_defconfig index 8c808ae..c70217c 100644 --- a/configs/p2371-2180_defconfig +++ b/configs/p2371-2180_defconfig @@ -52,3 +52,4 @@ CONFIG_CI_UDC=y CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y +CONFIG_BOOTP_PREFER_SERVERIP=y diff --git a/configs/p2571_defconfig b/configs/p2571_defconfig index 721c5c5..43c24b8 100644 --- a/configs/p2571_defconfig +++ b/configs/p2571_defconfig @@ -44,3 +44,4 @@ CONFIG_CI_UDC=y CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y +CONFIG_BOOTP_PREFER_SERVERIP=y diff --git a/configs/p2771-0000-000_defconfig b/configs/p2771-0000-000_defconfig index e347a77..8bf8419 100644 --- a/configs/p2771-0000-000_defconfig +++ b/configs/p2771-0000-000_defconfig @@ -37,3 +37,4 @@ CONFIG_SYS_NS16550=y CONFIG_USB=y CONFIG_DM_USB=y CONFIG_POSITION_INDEPENDENT=y +CONFIG_BOOTP_PREFER_SERVERIP=y diff --git a/configs/p2771-0000-500_defconfig b/configs/p2771-0000-500_defconfig index 0803b26..1f40333 100644 --- a/configs/p2771-0000-500_defconfig +++ b/configs/p2771-0000-500_defconfig @@ -37,3 +37,4 @@ CONFIG_SYS_NS16550=y CONFIG_USB=y CONFIG_DM_USB=y CONFIG_POSITION_INDEPENDENT=y +CONFIG_BOOTP_PREFER_SERVERIP=y
On 3/17/20 2:07 PM, twarren@nvidia.com wrote:
From: Tom Warren twarren@nvidia.com
This allows the user to set $serverip in the environment before executing a DHCP request. If they do, U-Boot will use that IP rather than using the IP in the DHCP response.
Acked-by: Stephen Warren swarren@nvidia.com
I wonder if this should be applied to more Tegra boards, so they all work consistently? E.g. T20/30/114/124 boards.
-----Original Message----- From: Stephen Warren swarren@wwwdotorg.org Sent: Wednesday, March 18, 2020 4:31 PM To: Tom Warren TWarren@nvidia.com Cc: u-boot@lists.denx.de; Stephen Warren swarren@nvidia.com; Thierry Reding treding@nvidia.com; Jonathan Hunter jonathanh@nvidia.com; tomcwarren3959@gmail.com Subject: Re: [PATCH 2/2] tegra: Enable CONFIG_BOOTP_PREFER_SERVERIP for all boards
External email: Use caution opening links or attachments
On 3/17/20 2:07 PM, twarren@nvidia.com wrote:
From: Tom Warren twarren@nvidia.com
This allows the user to set $serverip in the environment before executing a DHCP request. If they do, U-Boot will use that IP rather than using the IP in the DHCP response.
Acked-by: Stephen Warren swarren@nvidia.com
I wonder if this should be applied to more Tegra boards, so they all work consistently? E.g. T20/30/114/124 boards. [Tom] I can certainly do that, but I don't really test on anything <T210 anymore, especially not net boot. Do you test for that in your Jenkins test harness?
----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------
On 3/18/20 5:52 PM, Tom Warren wrote:
-----Original Message----- From: Stephen Warren swarren@wwwdotorg.org Sent: Wednesday, March 18, 2020 4:31 PM To: Tom Warren TWarren@nvidia.com Cc: u-boot@lists.denx.de; Stephen Warren swarren@nvidia.com; Thierry Reding treding@nvidia.com; Jonathan Hunter jonathanh@nvidia.com; tomcwarren3959@gmail.com Subject: Re: [PATCH 2/2] tegra: Enable CONFIG_BOOTP_PREFER_SERVERIP for all boards
External email: Use caution opening links or attachments
On 3/17/20 2:07 PM, twarren@nvidia.com wrote:
From: Tom Warren twarren@nvidia.com
This allows the user to set $serverip in the environment before executing a DHCP request. If they do, U-Boot will use that IP rather than using the IP in the DHCP response.
Acked-by: Stephen Warren swarren@nvidia.com
I wonder if this should be applied to more Tegra boards, so they all work consistently? E.g. T20/30/114/124 boards. [Tom] I can certainly do that, but I don't really test on anything <T210 anymore, especially not net boot. Do you test for that in your Jenkins test harness?
The oldest hardware that's tested in Jenkins is Jetson TK1. In total I have TK1, TX1, TX2 automated.
participants (4)
-
Stephen Warren -
Thierry Reding -
Tom Warren -
twarren＠nvidia.com