[PATCH 0/2] net: tegra: Misc network fixes

[PATCH 0/2] net: tegra: Misc network fixes

[twarren at nvidia.com]

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(+)

-- 
1.8.2.1.610.g562af5b


-----------------------------------------------------------------------------------
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.
-----------------------------------------------------------------------------------

[PATCH 1/2] net: rt8169: WAR for DHCP not getting IP after kernel boot/reboot

[twarren at nvidia.com]

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;
 }
 
-- 
1.8.2.1.610.g562af5b


-----------------------------------------------------------------------------------
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.
-----------------------------------------------------------------------------------

[PATCH 1/2] net: rt8169: WAR for DHCP not getting IP after kernel boot/reboot

[Stephen Warren]

On 3/17/20 2:07 PM, twarren at 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?

[PATCH 1/2] net: rt8169: WAR for DHCP not getting IP after kernel boot/reboot

[Tom Warren]

-----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 at lists.denx.de; Stephen Warren <swarren@nvidia.com>; Thierry Reding <treding@nvidia.com>; Jonathan Hunter <jonathanh@nvidia.com>; tomcwarren3959 at 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 at 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.
-----------------------------------------------------------------------------------

[PATCH 1/2] net: rt8169: WAR for DHCP not getting IP after kernel boot/reboot

[Thierry Reding]

On Tue, Mar 17, 2020 at 01:07:15PM -0700, twarren at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200319/f36936dc/attachment.sig>

[PATCH 1/2] net: rt8169: WAR for DHCP not getting IP after kernel boot/reboot

[Tom Warren]

-----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 at lists.denx.de; Stephen Warren <swarren@nvidia.com>; Jonathan Hunter <jonathanh@nvidia.com>; tomcwarren3959 at 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 at 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.
-----------------------------------------------------------------------------------

[PATCH 2/2] tegra: Enable CONFIG_BOOTP_PREFER_SERVERIP for all boards

[twarren at nvidia.com]

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
-- 
1.8.2.1.610.g562af5b


-----------------------------------------------------------------------------------
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.
-----------------------------------------------------------------------------------

[PATCH 2/2] tegra: Enable CONFIG_BOOTP_PREFER_SERVERIP for all boards

[Stephen Warren]

On 3/17/20 2:07 PM, twarren at 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.

[PATCH 2/2] tegra: Enable CONFIG_BOOTP_PREFER_SERVERIP for all boards

[Tom Warren]

-----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 at lists.denx.de; Stephen Warren <swarren@nvidia.com>; Thierry Reding <treding@nvidia.com>; Jonathan Hunter <jonathanh@nvidia.com>; tomcwarren3959 at 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 at 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.
-----------------------------------------------------------------------------------

[PATCH 2/2] tegra: Enable CONFIG_BOOTP_PREFER_SERVERIP for all boards

[Stephen Warren]

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 at lists.denx.de; Stephen Warren <swarren@nvidia.com>; Thierry Reding <treding@nvidia.com>; Jonathan Hunter <jonathanh@nvidia.com>; tomcwarren3959 at 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 at 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.

[PATCH 0/2] net: tegra: Misc network fixes

[tomcwarren3959 at gmail.com]

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(+)

-- 
1.8.2.1.610.g562af5b


-----------------------------------------------------------------------------------
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.
-----------------------------------------------------------------------------------

[PATCH 1/2] net: rt8169: WAR for DHCP not getting IP after kernel boot/reboot

[tomcwarren3959 at gmail.com]

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;
 }
 
-- 
1.8.2.1.610.g562af5b


-----------------------------------------------------------------------------------
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.
-----------------------------------------------------------------------------------

[PATCH 1/2] net: rt8169: WAR for DHCP not getting IP after kernel boot/reboot

[Tom Rini]

On Thu, Mar 26, 2020 at 03:59:13PM -0700, tomcwarren3959 at gmail.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>

Applied to u-boot/next, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200612/9a96f6fb/attachment.sig>