Hi,
Since serdes, mdio and phy support of Armada 7040 has been
integrated to the tree, here is another part of the platform.
This short patchset comprise only adding and enabling driver
for a single network controller with multi-port.
It consumes Simple Network Protocol and registers as many of its
instances as defined in PCD's. Please refer to porting guide
and the commit logs for more details. The driver itself is not
huge and it makes use of the OS-independent library obtained
from Marvell, comprising pure HW configuration.
Drivers/Net/Pp2Dxe/Pp2Dxe.h is therefore a glue between the
library and UEFI environment.
The patches are also available in the public github tree:
https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/opp…
Any comments or remarks would be welcome.
Best regards,
Marcin
Bartosz Szczepanek (3):
Drivers/Net: Import mvpp2_lib
Drivers/Net: Create Pp2Dxe driver
Platforms/Marvell: Enable Pp2Dxe driver on Armada70x0 platform
Documentation/Marvell/PortingGuide/Pp2.txt | 59 +
Drivers/Net/Pp2Dxe/Pp2Dxe.c | 1190 ++++++++
Drivers/Net/Pp2Dxe/Pp2Dxe.h | 530 ++++
Drivers/Net/Pp2Dxe/Pp2Dxe.inf | 91 +
Drivers/Net/Pp2Dxe/mvpp2_lib.c | 4299 ++++++++++++++++++++++++++++
Drivers/Net/Pp2Dxe/mvpp2_lib.h | 2362 +++++++++++++++
Platforms/Marvell/Armada/Armada.dsc.inc | 1 +
Platforms/Marvell/Armada/Armada70x0.dsc | 18 +-
Platforms/Marvell/Armada/Armada70x0.fdf | 1 +
Platforms/Marvell/Marvell.dec | 16 +
10 files changed, 8566 insertions(+), 1 deletion(-)
create mode 100644 Documentation/Marvell/PortingGuide/Pp2.txt
create mode 100644 Drivers/Net/Pp2Dxe/Pp2Dxe.c
create mode 100644 Drivers/Net/Pp2Dxe/Pp2Dxe.h
create mode 100644 Drivers/Net/Pp2Dxe/Pp2Dxe.inf
create mode 100644 Drivers/Net/Pp2Dxe/mvpp2_lib.c
create mode 100644 Drivers/Net/Pp2Dxe/mvpp2_lib.h
--
1.8.3.1
Hi,
I am looking at proper implementation for a driver which does not depend
on a platform but can be built for any supported architecture like EBC,
AARCH64, etc. That means the driver can be built separately from the
platform specific dsc but still be able to use proper platform
implemented interface functions once it's loaded (ex. from UEFI Shell).
As an example of a platform specific call:
for (i = 0; i < MSK_TIMEOUT; i++) {
MicroSecondDelay (1);
val = GMAC_READ_2 (mSoftc, port, GM_SMI_CTRL);
if ((val & GM_SMI_CT_RD_VAL) != 0) {
val = GMAC_READ_2 (mSoftc, port, GM_SMI_DATA);
break;
}
}
If the driver is using MicroSecondDelay() (code above) and is built as
part of the Juno platform dsc, the MicroSecondDelay() will be linked to
its implementation in ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.c.
If the driver has not been built as part of any platform,
MicroSecondDelay() will be linked to
MdePkg/Library/BaseTimerLibNullTemplate/TimerLibNull.c implementation.
So if the driver is built as platform independent (or architecture
independent in case of EBC) and included in the controller's option ROM
(or shipped as a file), it will fail as it will not be able to call
correct platform interface function.
This means the driver should do runtime (load time) bindings to the
platform interface functions to be a "platform independent". Does the
EDK2 provide a way to do such dynamic bindings?
Thanks,
Daniil