Re: CorebootPayloadPkg: redirect UEFI Shell to serial

["Piotr Król" <piotr.krol@3mdeb.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



On 07/14/2017 03:06 AM, Laszlo Ersek wrote:

Hi Laszlo,

>> 
>> Any further steps appreciated. I believe I need no stuff related
>> to GOP, maybe it cause some problems ?
> 
> There are two paths to the serial port:
> 
> (1) Via SerialPortLib APIs directly (or a bit more indirectly, via
> a DebugLib instance that relies on SerialPortLib). This is working
> for you already.
> 
> (2) Using EfiSimpleTextOutProtocol. ConSplitterDxe installs a
> "fake" one of this, and then splits the output to all "actual"
> ones. This isn't working for you.
> 
> From the log, the problem seems to me that ConPlatformDxe does not 
> install a NULL EfiConsoleOutDevice protocol instance on the 
> EfiSimpleTextOutProtocol instance that comes from TerminalDxe.
> 
> Therefore, ConSplitterDxe does not consider the terminal as a
> device that it should split console output to. So when any
> application writes to ConSplitterDxe's own "fake"
> EfiSimpleTextOutProtocol, ConSplitterDxe does not forward the data
> to TerminalDxe's EfiSimpleTextOutProtocol, and the output is lost.
> 
> The reason for ConPlatformDxe's behavior could be that your 
> PlatformBootManagerLib instance does not add, in the 
> PlatformBootManagerBeforeConsole() function, a device path to the 
> L"ConOut" global variable that would match the device path of 
> TerminalDxe's EfiSimpleTextOutProtocol instance.
> 
> For example, see 
> "ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c", function 
> PlatformBootManagerBeforeConsole():
> 
> // // Add the hardcoded serial console device path to ConIn,
> ConOut, ErrOut. // CopyGuid (&mSerialConsole.TermType.Guid, 
> PcdGetPtr (PcdTerminalTypeGuidBuffer)); 
> EfiBootManagerUpdateConsoleVariable (ConIn, 
> (EFI_DEVICE_PATH_PROTOCOL *)&mSerialConsole, NULL); 
> EfiBootManagerUpdateConsoleVariable (ConOut, 
> (EFI_DEVICE_PATH_PROTOCOL *)&mSerialConsole, NULL); 
> EfiBootManagerUpdateConsoleVariable (ErrOut, 
> (EFI_DEVICE_PATH_PROTOCOL *)&mSerialConsole, NULL);
> 
> See the initialization of "mSerialConsole" near the top of that
> file.
> 
> In short, in PlatformBootManagerBeforeConsole(), you need to add
> the device paths of all the EfiSimpleTextOutProtocol instances to
> L"ConOut" that you want to use as output consoles. Similarly for
> input and error.

Many thanks for this detailed explanation. I was able to follow your
advice and already have UEFI Shell booting on PC Engines APU2
platform. As always great support.

Changes that I had applied can be found here:
https://github.com/3mdeb/edk2/pull/1/files

I have couple following questions:
1. Right now I removed calls to CbReserveResourceInGcd from
CbSupportDxe since those result in ASSERT. This code seems to be very
hardware specific. I'm not sure how AMD architecture match
expectations in this section. Any pointers appreciated.
2. There are 2 minor typos like gUEfi instead of gUefi and entrhy
instead of entry, does it make sense to send patches for that ? In
various places I saw more typos like that.
3. Does upstreaming improved consoler splitting makes sense for
CorebootPayloadPkg ?
4. I had to move some PCDs to PcdsFixedAtBuild section. This seems to
makes difference for PcdSet64S. After that I'm getting error from that
function. Where I can read about difference between normal PCD and
FixedAtBuild
5. VRT (Valid RAM and Time) bit in RTC Register D seems to be r/w
instead of r/o, this bit is 1 after reset, but initialization clears
it, what cause further problems during booting. What is approach to
implement this kind of workarounds ? Should I keep separate version of
PcatRealTimeClockRuntimeDxe ?
6. Initial values for ie. Register A in PcRtc.h writes to reserved
registers (at least on AMD platform). Is there any way to make this
code compatible across platforms ?

Maybe it would be easier if I will push some patches, but probably
first I would like to know, if anyone is interested in above changes ?

As next step I would like to boot UEFI aware OS on top of that code. I
assume there will be more problems with that. I will let you know
about progress.

Best Regards,
- -- 
Piotr Król
Embedded Systems Consultant
https://3mdeb.com | @3mdeb_com
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE4DCbLYWmfoRjKeNLsu5x6WeqnkwFAllqEfQACgkQsu5x6Weq
nkzZbRAAijEdPVuVO9F07iw9RtaG0vMS+7P7luSG9aO9s8yjTW++BOGtJmw0Qgym
cCodVa5gFEsalncFyJlAKjahVuzbKezKhHx6sb6Br2tEj88ycl8meCktf0eILNwn
4+9kIb7qJ4TevSUtF62bxiM4Eqx18Lnm3MOtu5F0YO7n4fuO1yTFbQ72AbMNQu5h
PW8GjwdFiW+0oaeJ+V7pS7ctrsa5ezs9iuS5H6VeJZc247rpteCHLpLIwzfRd/jb
X20ZLdxqswhuIV9vSLk1yTHXTNQa36Qg/H2xwCulUFYbaXso3zDW834RutRUvL+f
OFxOvMs7sNr7n74UIIQx3auVwetZhX4AqlSt79FWI21i2rWOjCtaqh7IjrwJfwS6
c82Qw+UbPXEqxp4FOlL7PuoEIrBSr75u34SQxikQK8uuIj6tUghltt1zUvh/h38g
yDPJo6lm+ZX7dgrnpDOgc6+YHNLm9mzJujc1vbTV1mZlwmxoXuvgv/Nf39leZZMx
WNXCEPWoq4jtXykZdvUvgG7G3aFeNjk7QQvZ5gBU+4/ueTHhVt34FCj46fM6h7ZK
PWIqtgTRj1D7OlfhJl/e7hg6C2gygtSKB2FrfroB17s71R74YGyIlJ6OtX7MZF4G
Mu3uQmnhapLyz/xS2OYcBQlXqWSeZeJerSQDJiEx4zvPeTvdZE8=
=L5as
-----END PGP SIGNATURE-----