Re: [edk2-platforms][PATCH 2/3] Platform/RPi/DualSerialPortLib: Fix miniUART serial divisor computation

["Ard Biesheuvel" <ard.biesheuvel@arm.com>]

On 5/4/20 1:15 PM, Pete Batard wrote:
> From: Andrei Warkentin <andrey.warkentin@gmail.com>
> 
> Fix for https://github.com/raspberrypi/firmware/issues/1376.
> 
> For the Pi 3, to properly configure miniUART, we need the core clock,
> which can be vary between VideoCore firmare release or config.txt options.
> 
> Unfortunately, it's painful to get - it's only available via the mailbox
> interface. Additionally, SerialLib is a very limited environment, even
> when linked in a DXE-mode component, because as part of a DebugLib
> implementation it ends being the base prerequisite of everything.
> That means a "normal" mailbox implementation like the one from
> RpiFirmwareDxe (with dependencies on DmaLib) is out of the question.
> Using a basic implementation such as the one in PlatformLib doesn't work
> either because it operates in both environments with MMU on (DXE phase)
> and MMU off (SEC/PrePi).
> 
> Ideally, we read the value via mbox exactly once at boot (PlatformLib),
> and then somehow stash it. A GUID Hob sounds appropriate, yet when
> SerialPortLib operates in DXE components, we can't use the HobLib to
> *locate* the Hob list itself (remember, SerialPortLib initializes
> before any of HobLib's dependencies, like UeflLib...).
> 

Yeah, the gift that keeps on giving :-) NXP are struggling with a 
similar issue.

So the problem is that SerialPortInitialize() is called before we know 
what value to program, and we cannot rely on other libraries to discover 
this value because they may not work before their constructor has been 
called.

So can we break the contents of SerialPortInitialize() into things that 
need to happen once (program the divisors etc) and things that need to 
happen each and every time (figure out which UART we are using in the 
first place)? If the second set does not suffer from the same issue, can 
we just move the entire logic that programs the UART block into PrePi, 
so that all subsequent users don't have to touch those registers at all?

This means we may need two versions of DualSerialPortLib, where the one 
that PrePi uses may need to be attached to SerialDxe as well, so that it 
can reprogram the baud rate as needed. But for all the remaining 
DebugLib related uses, we don't really need to reprogram the UART at all 
afaics.