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
Hi,
I have been working on support for AHCI controller for my ARMv8 platform.
For that I have integrated my PciEmulation code and SataControllerDxe driver code with MdeModulePkg/Bus/Ata.
But facing one issue, this is same issue reported by Jan Dabros(in To list) sometime back.
Setting PxCMD.FRE bit of command register doesn't cause PxCMD.FR to be set to '1' even after "500msec" timeout.
(As per AHCI spec 1.3 : When PxCMD.FRE is set, it causes PxCMD.FR to be set to '1' )
Is it correct to just comment out following code part from "MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c" file, "AhciModeInitialization" function:
As Initialization timeouts is occurring in below part of code:
//
// Enable FIS Receive DMA engine for the first D2H FIS.
//
Offset = EFI_AHCI_PORT_START + Port * EFI_AHCI_PORT_REG_WIDTH + EFI_AHCI_PORT_CMD;
AhciOrReg (PciIo, Offset, EFI_AHCI_PORT_CMD_FRE);
Status = AhciWaitMmioSet (
PciIo,
Offset,
EFI_AHCI_PORT_CMD_FR,
EFI_AHCI_PORT_CMD_FR,
EFI_AHCI_PORT_CMD_FR_CLEAR_TIMEOUT
);
if (EFI_ERROR (Status)) {
continue;
}
And if above code is commented out, then SATA stack works completely fine.
What can be the problem?
Thank you in advance for your time!
Best regards,
Shaveta
Hi folks,
We can see that in a single timer interrupt, there will be two writes to
EOIR, one in timer interrupt handler, the other in GIC IRQ handler.
The question is: does two writes to EOIR have any side effect? From GIC
specification (ARM IHI 0069B (ID121715)), we can see below text about
writing EOIR (page 205):
A write to this register must correspond to the most recent valid read
from an Interrupt
Acknowledge Register for which there has not been a priority drop and
that this identifier was read
from ICC_IAR1_EL1 while operating in the same Security state as that in
which the write occurs,
otherwise the system behavior is UNPREDICTABLE. A valid read is a read
that returns a valid interrupt
ID, that is not a special INTID.
For GICv2, we can also see below text about EOIR:
For nested interrupts, the order of writes to this register must be the
reverse of the order of interrupt
acknowledgement. Behavior is UNPREDICTABLE if:
• This ordering constraint is not maintained.
*• The value written to this register does not match an active
interrupt, or the ID of a spurious interrupt. *
• The value written to this register does not match the last valid
interrupt value read from GICC_IAR.
When we issue the 1st EOIR, the interrupt will be deactivated, so it is
not in active state anymore for the 2nd write of EOIR.
Could anyone help to confirm whether it is OK to keep the 2nd write of
EOIR? And how to explain the above paragraphs from GIC specification?
Thanks and regards.
Heyi