On 12 August 2016 at 01:58, Daniil Egranov daniil.egranov@arm.com wrote:
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?
This code should be using gBS->Stall(). In general, the code should be using the various protocols for delay, cache maintenance etc rather than linking to them directly.