Add a PCD to allow the platform to mask in/out specific features of
the LAN9118 device advertised during auto-negotiation.
For example, the Juno ARM Development Platform doesn't support full
duplex mode. This PCD will allow the platform developer to prevent the
full duplex modes from being advertised.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
[ardb: change default feature mask so that full duplex is disabled]
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Leif Lindholm <leif.lindholm@linaro.org>
Now that the LAN9118-specific MMIO accessors provide the required
delays, remove the redundant stalls.
Stalls in delay loops are kept, as these give time for work to happen
beyond synchronisation of the device register file.
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Ryan Harkin <ryan.harkin@linaro.org>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Migrate the existing code to use the new LAN9118 MMIO wrappers, ensuring
that timing requirements are respected.
The newly redundant stalls will be removed in a subsequent patch.
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Ryan Harkin <ryan.harkin@linaro.org>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
As described in the LAN9118 datasheet, delays are necessary after some
reads and writes in order to ensure subsequent reads do not see stale
data.
This patch adds helpers to provide these delays automatically, by
performing dummy reads of the BYTE_TEST register (as recommended in the
LAN9118 datasheet). This approach allows the device register file itself
to provide the required delay, avoiding issues with early write
acknowledgement, or re-ordering of MMIO accesses aganist other
instructions (e.g. the delay loop).
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Ryan Harkin <ryan.harkin@linaro.org>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Commit a4626006bb ("EmbeddedPkg/Lan9118Dxe: use MemoryFence")
replaced some stalls with memory fences, on the presumption that these
were erroneously being used to order memory accesses. However, this was
not the case.
LAN9118 devices require a timing delay between state-changing
reads/writes and subsequent reads, as updates to the register file are
asynchronous and the effects of state-changes are not immediately
visible to subsequent reads.
This delay cannot be ensured through the use of memory barriers, which
only enforce observable ordering, and not timing. Thus, converting these
stalls to memory fences was erroneous, and may result in stale values
being read.
This reverts commit a4626006bb.
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Ryan Harkin <ryan.harkin@linaro.org>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
The variable TimeOut is actually a retry, not a timeout, so I renamed
the variable accordingly.
This patch makes no functional change.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Add a PCD for the link negotiation timeout so the platform can over-ride
the default value.
The code previously did 2000 iterations of the loop with a 2us stall, so
the code has been changed subtly to set the number of iterations equal
to the PCD value divided by the stall time.
Since the stall time has not changed, the default PCD value is set at
4000 so the original behaviour is not changed.
The problems were discovered when the ARM Juno Development Platform used
the "EFI Network" option with then LAN9118 driver. It fails to boot the
first time and so the board drops back to Shell again:
Warning: LAN9118 Driver in stopped state
Link timeout in auto-negotiation.
Lan9118: Auto Negociation not supported.
EhcExecTransfer: transfer failed with 2
EhcControlTransfer: error - Device Error, transfer - 2
Buffer: EFI Hard Drive
Booting EFI Misc Device
Booting EFI Misc Device 1
Booting EFI Hard Drive
Booting EFI Network
Warning: LAN9118 Driver not initialized
Link timeout in auto-negotiation.
Lan9118: Auto Negociation not supported.
Booting EFI Internal Shell
Exiting Shell drops the user back to the Intel BDS UI. Selecting
"Continue" then succeeds in booting from the EFI Network:
Booting EFI Misc Device
Booting EFI Misc Device 1
Booting EFI Hard Drive
Booting EFI Network
..MnpFreeTxBuf: Duplicated recycle report from SNP.
MnpFreeTxBuf: Duplicated recycle report from SNP.
[snip repeated errors]
Discussion on the edk2-devel mailing list [1] prompted Laszlo Ersek to
suggest the time taken for the NIC to negotiate was causing a problem.
He suggested the solution contained in this patch to provide a PCD
configurable by the platform.
The default PCD value does not work for Juno. Setting the PCD to a
larger value works for Juno R0, R1 and R2.
[1] http://article.gmane.org/gmane.comp.bios.edk2.devel/7341
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
When reviewing my LAN9118 driver PCD patch [1], Ard Biesheuvel noted
that most calls to gBS->Stall() in this driver seem to be used to
prevent timing issues between the device updating data and the host
reading the values. And that replacing most of these calls with a
MemoryFence() would be more robust.
The only exceptions are the stalls that are enclosed inside retry loops:
- in the AutoNegotiate() function.
This stall is waiting for the link to negotiate, which may require
stalling until it is ready.
- in the Lan9118Initialize() function.
These two stalls are waiting for devices and time out after a number
of retries.
- in the SoftReset() function.
This stall is inside a loop where the comment states:
"If time taken exceeds 100us, then there was an error condition"
In these instances, I kept the stall, but also added a MemoryFence().
[1] http://article.gmane.org/gmane.comp.bios.edk2.devel/7389
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
The UEFI specification does not require the initialisation and reset
interface to check if an Ethernet cable is connected or not, and provides
the GetStatus() interface to do this. Furthermore, the 'Managed Network
Protocol' take care of the cable connection check in edk2 network stack.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Reviewed-by: Olivier Martin <olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16326 6f19259b-4bc3-4df7-8a09-765794883524
Correct the setting of the hardware filters according to what it asked
to the driver through the ReceiveFilters() interface function.
Keep track of the hardware settings in the "ReceiveFilterSetting" field of
the EFI_SIMPLE_NETWORK_MODE structure.
From now, after initialization, all filters are disabled and thus no packet
received.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Reviewed-By: Olivier Martin <olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16243 6f19259b-4bc3-4df7-8a09-765794883524
- Make the function PhySoftReset() return EFI_STATUS
- EFI_STATUS was treated as a signed integer by the caller which is not correct.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin <olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15630 6f19259b-4bc3-4df7-8a09-765794883524