(replying on the webui... sorry!)

The problem is actually embedded in MdePkg and MdeModulePkg.

- In DxeMain() (and in functions called by DxeMain()), we call DebugLib APIs *before* reaching ProcessLibraryConstructorList().

- In ArmVirtQemu, we resolve the DXE Core's DebugLib dependency to BaseDebugLibSerialPort (from MdePkg).

- BaseDebugLibSerialPort has a constructor function (BaseDebugLibSerialPortConstructor()).

These already suffice for broken DebugLib behavior. APIs of a library class should not be called because the library instance has a chance to initialize.

The rest is circumstantial. Like, BaseDebugLibSerialPortConstructor calls SerialPortInitialize, but our SerialPortInitialize (in FdtPL011SerialPortLib) does nothing. Well, the latter doesn't need to do anything, because FdtPL011SerialPortLib has its own constructor (FdtPL011SerialPortLibInitialize), thus, if constructors were called properly, then BaseDebugLibSerialPort + FdtPL011SerialPortLib would work properly together, regardless of SerialPortInitialize being empty in the latter.

Basically the DXE Core has a hidden requirement -- it can only use such DebugLib instances that need no explicit initialization.

The proposed patch works around the problem by satisfying that hidden requirement one level lower down: in the SerialPortLib instance. The initialization of BaseDebugLibSerialPort is still busted (its constructor is not called, so it cannot call SerialPortInitialize either), but now it is masked, because EarlyFdtPL011SerialPortLib works withouth *both* SerialPortInitialize and construction.

The real fix would be to make the DXE Core requirement explicit, by introducing separate (dedicated) DebugLib and SerialPortLib *classes* (whose APIs are guaranteed to work without initialization).

Laszlo

_._,_._,_

Groups.io Links:

You receive all messages sent to this group.

_._,_._,_