* [U-Boot] Intel e1000 PHY HW reset timeout reasons?
@ 2016-12-14 16:51 Kostya Porotchkin
2017-02-02 18:46 ` Joe Hershberger
0 siblings, 1 reply; 3+ messages in thread
From: Kostya Porotchkin @ 2016-12-14 16:51 UTC (permalink / raw)
To: u-boot
Hello,
I am currently working on u-boot mainline code supporting Marvell
Armada armv8 platforms (80x0, 70x0, 37x0).
During this coding and testing cycles I found a very strange issue
related to u-boot e1000 network driver.
The PCIe e1000 NIC is tested on 2 platforms based on the same SoC (8040).
On one of these platforms the e1000 card is properly detected on PCIe
bus, but fails to activate the HW due to HW PHY reset timeout.
If I bypass the timeout error, the e1000 card continues to work without
any problem and I am able to run a full Linux system with root on NFS
using this network card.
Below is the (ugly) change that solves me the PHY reset timeout problem:
diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index 3332ad9..a40b009 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -4361,7 +4361,7 @@ e1000_get_phy_cfg_done(struct e1000_hw *hw)
if (!timeout) {
DEBUGOUT("MNG configuration cycle has not "
"completed.\n");
- return -E1000_ERR_RESET;
+// return -E1000_ERR_RESET;
}
break;
I have found that the similar issue has already been discussed in this
email list, but the driver code was not changed and the timeout seems
to happen in some test cases.
http://lists.denx.de/pipermail/u-boot/2014-September/188544.html
I would be glad to get an idea about such timeout reasons and ways to
solve this issue on my development platform.
Both my platforms are based on Marvell Armada 8040 SoC.
1. Platform-1: PCIe x1, card reset connected to system reset wire
No driver WA required.
2. Platform-2: PCIe x4, card reset connected to GPIO,
reset released upon PCIe bus probe.
e1000 driver WA required for a normal operation.
==============================================
E1000 debug log on Platform-2:
==============================================
=> pci enum
PCIE-0: Link up (Gen1-x1, Bus0)
=> pci 1
Scanning PCI devices on bus 1
BusDevFun VendorId DeviceId Device Class Sub-Class
_____________________________________________________________
01.00.00 0x8086 0x107d Network controller 0x00
=> ping 192.168.100.200
e1000: e1000#0: DEBUG: iobase 0xf6000000
e1000_set_mac_type
e1000_set_media_type
copper interface
e1000_reset_hw
Masking off all interrupts
Issuing a global reset to MAC
Masking off all interrupts
e1000_init_eeprom_params
e1000_read_mac_addr
e1000_read_eeprom
e1000_is_onboard_nvm_eeprom
e1000_acquire_eeprom
e1000_swfw_sync_acquire
e1000_get_hw_eeprom_semaphore
e1000_put_hw_eeprom_semaphore
e1000_spi_eeprom_ready
e1000_release_eeprom
e1000_swfw_sync_release
e1000_get_hw_eeprom_semaphore
e1000_put_hw_eeprom_semaphore
e1000_read_eeprom
e1000_is_onboard_nvm_eeprom
e1000_acquire_eeprom
e1000_swfw_sync_acquire
e1000_get_hw_eeprom_semaphore
e1000_put_hw_eeprom_semaphore
e1000_spi_eeprom_ready
e1000_release_eeprom
e1000_swfw_sync_release
e1000_get_hw_eeprom_semaphore
e1000_put_hw_eeprom_semaphore
e1000_read_eeprom
e1000_is_onboard_nvm_eeprom
e1000_acquire_eeprom
e1000_swfw_sync_acquire
e1000_get_hw_eeprom_semaphore
e1000_put_hw_eeprom_semaphore
e1000_spi_eeprom_ready
e1000_release_eeprom
e1000_swfw_sync_release
e1000_get_hw_eeprom_semaphore
e1000_put_hw_eeprom_semaphore
e1000: 68:05:ca:12:4d:dc
Warning: e1000#0 MAC addresses don't match:
Address in SROM is 68:05:ca:12:4d:dc
Address in environment is 00:00:00:00:51:81
e1000_reset_hw
Masking off all interrupts
Issuing a global reset to MAC
Masking off all interrupts
e1000_init_hw
e1000_set_media_type
Initializing the IEEE VLAN
e1000_init_rx_addrs
Programming MAC Address into RAR[0]
Clearing RAR[1-15]
Zeroing the MTA
e1000_setup_link
e1000_read_eeprom
e1000_is_onboard_nvm_eeprom
e1000_acquire_eeprom
e1000_swfw_sync_acquire
e1000_get_hw_eeprom_semaphore
e1000_put_hw_eeprom_semaphore
e1000_spi_eeprom_ready
e1000_release_eeprom
e1000_swfw_sync_release
e1000_get_hw_eeprom_semaphore
e1000_put_hw_eeprom_semaphore
e1000_read_eeprom
e1000_is_onboard_nvm_eeprom
e1000_acquire_eeprom
e1000_swfw_sync_acquire
e1000_get_hw_eeprom_semaphore
e1000_put_hw_eeprom_semaphore
e1000_spi_eeprom_ready
e1000_release_eeprom
e1000_swfw_sync_release
e1000_get_hw_eeprom_semaphore
e1000_put_hw_eeprom_semaphore
After fix-ups FlowControl is now = 3
e1000_setup_copper_link
e1000_copper_link_preconfig
e1000_detect_gig_phy
Phy ID = 2a80380
e1000_set_phy_mode
e1000_copper_link_igp_setup
e1000_phy_reset
e1000_phy_hw_reset
Resetting Phy...
e1000_swfw_sync_acquire
e1000_get_hw_eeprom_semaphore
e1000_put_hw_eeprom_semaphore
e1000_swfw_sync_release
e1000_get_hw_eeprom_semaphore
e1000_put_hw_eeprom_semaphore
e1000_get_phy_cfg_done
MNG configuration cycle has not completed.
Error Resetting the PHY
e1000: e1000#0: ERROR: Hardware Initialization Failed
ping failed; host 192.168.100.200 is not alive
==============================================
Thank you beforehand for your help.
Best Regards
Konstantin Porotchkin
^ permalink raw reply related [flat|nested] 3+ messages in thread
* [U-Boot] Intel e1000 PHY HW reset timeout reasons?
2016-12-14 16:51 [U-Boot] Intel e1000 PHY HW reset timeout reasons? Kostya Porotchkin
@ 2017-02-02 18:46 ` Joe Hershberger
2017-02-02 21:12 ` Kostya Porotchkin
0 siblings, 1 reply; 3+ messages in thread
From: Joe Hershberger @ 2017-02-02 18:46 UTC (permalink / raw)
To: u-boot
Hi Kostya,
On Wed, Dec 14, 2016 at 10:51 AM, Kostya Porotchkin <kostap@marvell.com> wrote:
> Hello,
>
> I am currently working on u-boot mainline code supporting Marvell
> Armada armv8 platforms (80x0, 70x0, 37x0).
> During this coding and testing cycles I found a very strange issue
> related to u-boot e1000 network driver.
> The PCIe e1000 NIC is tested on 2 platforms based on the same SoC (8040).
> On one of these platforms the e1000 card is properly detected on PCIe
> bus, but fails to activate the HW due to HW PHY reset timeout.
> If I bypass the timeout error, the e1000 card continues to work without
> any problem and I am able to run a full Linux system with root on NFS
> using this network card.
> Below is the (ugly) change that solves me the PHY reset timeout problem:
>
> diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
> index 3332ad9..a40b009 100644
> --- a/drivers/net/e1000.c
> +++ b/drivers/net/e1000.c
> @@ -4361,7 +4361,7 @@ e1000_get_phy_cfg_done(struct e1000_hw *hw)
> if (!timeout) {
> DEBUGOUT("MNG configuration cycle has not "
> "completed.\n");
> - return -E1000_ERR_RESET;
> +// return -E1000_ERR_RESET;
> }
> break;
So basically if you have the driver lie about the reset succeeding,
then it's OK. Maybe the reset timeout needs to be longer? Maybe the
hardware isn't reporting the reset completion properly?
> I have found that the similar issue has already been discussed in this
> email list, but the driver code was not changed and the timeout seems
> to happen in some test cases.
> http://lists.denx.de/pipermail/u-boot/2014-September/188544.html
>
> I would be glad to get an idea about such timeout reasons and ways to
> solve this issue on my development platform.
>
> Both my platforms are based on Marvell Armada 8040 SoC.
Maybe Prafulla has some ideas?
> 1. Platform-1: PCIe x1, card reset connected to system reset wire
> No driver WA required.
>
> 2. Platform-2: PCIe x4, card reset connected to GPIO,
> reset released upon PCIe bus probe.
> e1000 driver WA required for a normal operation.
>
> ==============================================
> E1000 debug log on Platform-2:
> ==============================================
>
> => pci enum
> PCIE-0: Link up (Gen1-x1, Bus0)
> => pci 1
> Scanning PCI devices on bus 1
> BusDevFun VendorId DeviceId Device Class Sub-Class
> _____________________________________________________________
> 01.00.00 0x8086 0x107d Network controller 0x00
>
> => ping 192.168.100.200
> e1000: e1000#0: DEBUG: iobase 0xf6000000
> e1000_set_mac_type
> e1000_set_media_type
> copper interface
> e1000_reset_hw
> Masking off all interrupts
> Issuing a global reset to MAC
> Masking off all interrupts
> e1000_init_eeprom_params
> e1000_read_mac_addr
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_acquire_eeprom
> e1000_swfw_sync_acquire
> e1000_get_hw_eeprom_semaphore
> e1000_put_hw_eeprom_semaphore
> e1000_spi_eeprom_ready
> e1000_release_eeprom
> e1000_swfw_sync_release
> e1000_get_hw_eeprom_semaphore
> e1000_put_hw_eeprom_semaphore
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_acquire_eeprom
> e1000_swfw_sync_acquire
> e1000_get_hw_eeprom_semaphore
> e1000_put_hw_eeprom_semaphore
> e1000_spi_eeprom_ready
> e1000_release_eeprom
> e1000_swfw_sync_release
> e1000_get_hw_eeprom_semaphore
> e1000_put_hw_eeprom_semaphore
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_acquire_eeprom
> e1000_swfw_sync_acquire
> e1000_get_hw_eeprom_semaphore
> e1000_put_hw_eeprom_semaphore
> e1000_spi_eeprom_ready
> e1000_release_eeprom
> e1000_swfw_sync_release
> e1000_get_hw_eeprom_semaphore
> e1000_put_hw_eeprom_semaphore
> e1000: 68:05:ca:12:4d:dc
>
> Warning: e1000#0 MAC addresses don't match:
> Address in SROM is 68:05:ca:12:4d:dc
> Address in environment is 00:00:00:00:51:81
> e1000_reset_hw
> Masking off all interrupts
> Issuing a global reset to MAC
> Masking off all interrupts
> e1000_init_hw
> e1000_set_media_type
> Initializing the IEEE VLAN
> e1000_init_rx_addrs
> Programming MAC Address into RAR[0]
> Clearing RAR[1-15]
> Zeroing the MTA
> e1000_setup_link
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_acquire_eeprom
> e1000_swfw_sync_acquire
> e1000_get_hw_eeprom_semaphore
> e1000_put_hw_eeprom_semaphore
> e1000_spi_eeprom_ready
> e1000_release_eeprom
> e1000_swfw_sync_release
> e1000_get_hw_eeprom_semaphore
> e1000_put_hw_eeprom_semaphore
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_acquire_eeprom
> e1000_swfw_sync_acquire
> e1000_get_hw_eeprom_semaphore
> e1000_put_hw_eeprom_semaphore
> e1000_spi_eeprom_ready
> e1000_release_eeprom
> e1000_swfw_sync_release
> e1000_get_hw_eeprom_semaphore
> e1000_put_hw_eeprom_semaphore
> After fix-ups FlowControl is now = 3
> e1000_setup_copper_link
> e1000_copper_link_preconfig
> e1000_detect_gig_phy
> Phy ID = 2a80380
> e1000_set_phy_mode
> e1000_copper_link_igp_setup
> e1000_phy_reset
> e1000_phy_hw_reset
> Resetting Phy...
> e1000_swfw_sync_acquire
> e1000_get_hw_eeprom_semaphore
> e1000_put_hw_eeprom_semaphore
> e1000_swfw_sync_release
> e1000_get_hw_eeprom_semaphore
> e1000_put_hw_eeprom_semaphore
> e1000_get_phy_cfg_done
> MNG configuration cycle has not completed.
> Error Resetting the PHY
> e1000: e1000#0: ERROR: Hardware Initialization Failed
> ping failed; host 192.168.100.200 is not alive
> ==============================================
>
> Thank you beforehand for your help.
>
> Best Regards
> Konstantin Porotchkin
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
^ permalink raw reply [flat|nested] 3+ messages in thread
* [U-Boot] Intel e1000 PHY HW reset timeout reasons?
2017-02-02 18:46 ` Joe Hershberger
@ 2017-02-02 21:12 ` Kostya Porotchkin
0 siblings, 0 replies; 3+ messages in thread
From: Kostya Porotchkin @ 2017-02-02 21:12 UTC (permalink / raw)
To: u-boot
Hi, Joe,
Thank you for your response!
Actually I tried to increase the after-reset delay up to 500mS and even to 1000mS, but got the same result.
It looks like I hit a corner case when the u-boot e1000 driver expects semaphore release from the e1000 FW and it does not happen for some reason.
I guess when e1000 reset signal released in the same time as the board reset, the u-boot driver is not started yet and the e1000 FW gets ready before the driver starts to talk to the NIC HW.
Interesting if Intel has a FW update for this card type. Such update might be fixing this driver-FW lock issue.
Regards
Kosta
________________________________________
From: Joe Hershberger <joe.hershberger@gmail.com>
Sent: Thursday, February 2, 2017 20:46
To: Kostya Porotchkin
Cc: u-boot at lists.denx.de; joe.hershberger at ni.com; rabeeh at solid-run.com; Prafulla Wadaskar
Subject: [EXT] Re: [U-Boot] Intel e1000 PHY HW reset timeout reasons?
External Email
----------------------------------------------------------------------
Hi Kostya,
On Wed, Dec 14, 2016 at 10:51 AM, Kostya Porotchkin <kostap@marvell.com> wrote:
> Hello,
>
> I am currently working on u-boot mainline code supporting Marvell
> Armada armv8 platforms (80x0, 70x0, 37x0).
> During this coding and testing cycles I found a very strange issue
> related to u-boot e1000 network driver.
> The PCIe e1000 NIC is tested on 2 platforms based on the same SoC (8040).
> On one of these platforms the e1000 card is properly detected on PCIe
> bus, but fails to activate the HW due to HW PHY reset timeout.
> If I bypass the timeout error, the e1000 card continues to work without
> any problem and I am able to run a full Linux system with root on NFS
> using this network card.
> Below is the (ugly) change that solves me the PHY reset timeout problem:
>
> diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
> index 3332ad9..a40b009 100644
> --- a/drivers/net/e1000.c
> +++ b/drivers/net/e1000.c
> @@ -4361,7 +4361,7 @@ e1000_get_phy_cfg_done(struct e1000_hw *hw)
> if (!timeout) {
> DEBUGOUT("MNG configuration cycle has not "
> "completed.\n");
> - return -E1000_ERR_RESET;
> +// return -E1000_ERR_RESET;
> }
> break;
So basically if you have the driver lie about the reset succeeding,
then it's OK. Maybe the reset timeout needs to be longer? Maybe the
hardware isn't reporting the reset completion properly?
> I have found that the similar issue has already been discussed in this
> email list, but the driver code was not changed and the timeout seems
> to happen in some test cases.
> http://lists.denx.de/pipermail/u-boot/2014-September/188544.html
>
> I would be glad to get an idea about such timeout reasons and ways to
> solve this issue on my development platform.
>
> Both my platforms are based on Marvell Armada 8040 SoC.
Maybe Prafulla has some ideas?
> 1. Platform-1: PCIe x1, card reset connected to system reset wire
> No driver WA required.
>
> 2. Platform-2: PCIe x4, card reset connected to GPIO,
> reset released upon PCIe bus probe.
> e1000 driver WA required for a normal operation.
>
> ==============================================
> E1000 debug log on Platform-2:
> ==============================================
>
> => pci enum
> PCIE-0: Link up (Gen1-x1, Bus0)
> => pci 1
> Scanning PCI devices on bus 1
> BusDevFun VendorId DeviceId Device Class Sub-Class
> _____________________________________________________________
> 01.00.00 0x8086 0x107d Network controller 0x00
>
> => ping 192.168.100.200
> e1000: e1000#0: DEBUG: iobase 0xf6000000
> e1000_set_mac_type
> e1000_set_media_type
> copper interface
> e1000_reset_hw
> Masking off all interrupts
> Issuing a global reset to MAC
> Masking off all interrupts
> e1000_init_eeprom_params
> e1000_read_mac_addr
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_acquire_eeprom
> e1000_swfw_sync_acquire
> e1000_get_hw_eeprom_semaphore
> e1000_put_hw_eeprom_semaphore
> e1000_spi_eeprom_ready
> e1000_release_eeprom
> e1000_swfw_sync_release
> e1000_get_hw_eeprom_semaphore
> e1000_put_hw_eeprom_semaphore
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_acquire_eeprom
> e1000_swfw_sync_acquire
> e1000_get_hw_eeprom_semaphore
> e1000_put_hw_eeprom_semaphore
> e1000_spi_eeprom_ready
> e1000_release_eeprom
> e1000_swfw_sync_release
> e1000_get_hw_eeprom_semaphore
> e1000_put_hw_eeprom_semaphore
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_acquire_eeprom
> e1000_swfw_sync_acquire
> e1000_get_hw_eeprom_semaphore
> e1000_put_hw_eeprom_semaphore
> e1000_spi_eeprom_ready
> e1000_release_eeprom
> e1000_swfw_sync_release
> e1000_get_hw_eeprom_semaphore
> e1000_put_hw_eeprom_semaphore
> e1000: 68:05:ca:12:4d:dc
>
> Warning: e1000#0 MAC addresses don't match:
> Address in SROM is 68:05:ca:12:4d:dc
> Address in environment is 00:00:00:00:51:81
> e1000_reset_hw
> Masking off all interrupts
> Issuing a global reset to MAC
> Masking off all interrupts
> e1000_init_hw
> e1000_set_media_type
> Initializing the IEEE VLAN
> e1000_init_rx_addrs
> Programming MAC Address into RAR[0]
> Clearing RAR[1-15]
> Zeroing the MTA
> e1000_setup_link
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_acquire_eeprom
> e1000_swfw_sync_acquire
> e1000_get_hw_eeprom_semaphore
> e1000_put_hw_eeprom_semaphore
> e1000_spi_eeprom_ready
> e1000_release_eeprom
> e1000_swfw_sync_release
> e1000_get_hw_eeprom_semaphore
> e1000_put_hw_eeprom_semaphore
> e1000_read_eeprom
> e1000_is_onboard_nvm_eeprom
> e1000_acquire_eeprom
> e1000_swfw_sync_acquire
> e1000_get_hw_eeprom_semaphore
> e1000_put_hw_eeprom_semaphore
> e1000_spi_eeprom_ready
> e1000_release_eeprom
> e1000_swfw_sync_release
> e1000_get_hw_eeprom_semaphore
> e1000_put_hw_eeprom_semaphore
> After fix-ups FlowControl is now = 3
> e1000_setup_copper_link
> e1000_copper_link_preconfig
> e1000_detect_gig_phy
> Phy ID = 2a80380
> e1000_set_phy_mode
> e1000_copper_link_igp_setup
> e1000_phy_reset
> e1000_phy_hw_reset
> Resetting Phy...
> e1000_swfw_sync_acquire
> e1000_get_hw_eeprom_semaphore
> e1000_put_hw_eeprom_semaphore
> e1000_swfw_sync_release
> e1000_get_hw_eeprom_semaphore
> e1000_put_hw_eeprom_semaphore
> e1000_get_phy_cfg_done
> MNG configuration cycle has not completed.
> Error Resetting the PHY
> e1000: e1000#0: ERROR: Hardware Initialization Failed
> ping failed; host 192.168.100.200 is not alive
> ==============================================
>
> Thank you beforehand for your help.
>
> Best Regards
> Konstantin Porotchkin
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-02-02 21:12 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-12-14 16:51 [U-Boot] Intel e1000 PHY HW reset timeout reasons? Kostya Porotchkin
2017-02-02 18:46 ` Joe Hershberger
2017-02-02 21:12 ` Kostya Porotchkin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox