On 5/4/20 1:15 PM, Pete Batard wrote:
From: Andrei Warkentin <andrey.warken...@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.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#58605): https://edk2.groups.io/g/devel/message/58605
Mute This Topic: https://groups.io/mt/73972541/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-