CorebootPayloadPkg: redirect UEFI Shell to serial

CorebootPayloadPkg: redirect UEFI Shell to serial

[Piotr Król]

[-- Attachment #1.1: Type: text/plain, Size: 1466 bytes --]

Hi all,
I'm trying to enable CorebootPayloadPkg on PC Engines APU2 (AMD Embedded
G series GX-412TC). I passed some asserts related to RTC and memory
reservation for LAPIC/APIC/HPET. Now it looks like I'm starting UEFI Shell:

[Bds]Booting UEFI Shell
[Bds] Expand
MemoryMapped(0xB,0x830000,0xC0FFFF)/FvFile(7C04A583-9E3E-4F1C-AD65-E05268D0B4D1)
->
MemoryMapped(0xB,0x830000,0xC0FFFF)/FvFile(7C04A583-9E3E-4F1C-AD65-E05268D0B4D1)
PROGRESS CODE: V03058000 I0
InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B CF8FBD40
Loading driver at 0x000CF54D000 EntryPoint=0x000CF556CCF Shell.efi
InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF CF927818
ProtectUefiImageCommon - 0xCF8FBD40
  - 0x00000000CF54D000 - 0x00000000000F4380
PROGRESS CODE: V03058001 I0
InstallProtocolInterface: 387477C2-69C7-11D2-8E39-00A0C969723B CF8DEBA0
InstallProtocolInterface: 752F3136-4E16-4FDC-A22A-E5F46812F4CA CF8DDF98

What's missing is UEFI Shell output on serial console. APU2 do not have
wired video output. That's why I would like to enable UEFI Shell output
to serial.

I tried to replace DebugLib with
MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf, but
this lead to reboot after loading protocols.

I believe this is well known problem, but cannot find information about
that. Any pointers would be appreciated.

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: CorebootPayloadPkg: redirect UEFI Shell to serial

[Laszlo Ersek]

On 07/10/17 23:31, Piotr Król wrote:
> Hi all,
> I'm trying to enable CorebootPayloadPkg on PC Engines APU2 (AMD Embedded
> G series GX-412TC). I passed some asserts related to RTC and memory
> reservation for LAPIC/APIC/HPET. Now it looks like I'm starting UEFI Shell:
> 
> [Bds]Booting UEFI Shell
> [Bds] Expand
> MemoryMapped(0xB,0x830000,0xC0FFFF)/FvFile(7C04A583-9E3E-4F1C-AD65-E05268D0B4D1)
> ->
> MemoryMapped(0xB,0x830000,0xC0FFFF)/FvFile(7C04A583-9E3E-4F1C-AD65-E05268D0B4D1)
> PROGRESS CODE: V03058000 I0
> InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B CF8FBD40
> Loading driver at 0x000CF54D000 EntryPoint=0x000CF556CCF Shell.efi
> InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF CF927818
> ProtectUefiImageCommon - 0xCF8FBD40
>   - 0x00000000CF54D000 - 0x00000000000F4380
> PROGRESS CODE: V03058001 I0
> InstallProtocolInterface: 387477C2-69C7-11D2-8E39-00A0C969723B CF8DEBA0
> InstallProtocolInterface: 752F3136-4E16-4FDC-A22A-E5F46812F4CA CF8DDF98
> 
> What's missing is UEFI Shell output on serial console. APU2 do not have
> wired video output. That's why I would like to enable UEFI Shell output
> to serial.
> 
> I tried to replace DebugLib with
> MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf, but
> this lead to reboot after loading protocols.
> 
> I believe this is well known problem, but cannot find information about
> that. Any pointers would be appreciated.

CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc seems to correctly
include the general SerialDxe driver:

  #
  # ISA Support
  #
  MdeModulePkg/Universal/SerialDxe/SerialDxe.inf

and on top of that, the terminal and console drivers:

  #
  # Console Support
  #
  MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
  MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
  MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
  MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf

I imagine SerialDxe is not configured correctly for the platform. Can
you look into the PCDs that SerialDxe consumes (see the INF file),
and/or whether
"CorebootModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.inf",
which SerialDxe depends on in the CorebootPayloadPkg build, is
appropriate for your hardware? (This lib instance also consumes a large
set of PCDs.)

Laszlo

Re: CorebootPayloadPkg: redirect UEFI Shell to serial

[Piotr Król]

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



On 07/11/2017 08:01 PM, Laszlo Ersek wrote:

Hi Laszlo,
thanks for taking time to reply.

> 
> CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc seems to correctly
> include the general SerialDxe driver:
> 
> # # ISA Support # MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
> 
> and on top of that, the terminal and console drivers:
> 
> # # Console Support # 
> MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf 
> MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf 
> MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
>
>
> 
MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
> 
> I imagine SerialDxe is not configured correctly for the platform. 
> Can you look into the PCDs that SerialDxe consumes (see the INF 
> file),

Logs appear correctly in DXE and BDS, so at least at some point it
works. Boot logs for SHELL_TYPE=UEFI_BIN adn SHELL_TYPE=BUILD_UEFI:
http://81.95.197.197:7777/aciqabilaw
http://81.95.197.197:7777/ijopesosuy

It would be great to have the same for Shell application.

Board schematics is open and available here:
http://www.pcengines.ch/schema/apu2c.pdf
You can see that serial is exposed through LPC.

I tried to modify PcdSerialUseMmio to TRUE, but it doesn't seem to
affect anything. Linux say "ttyS0 at I/O 0x3f8", so using IO seems to
be fine.

> and/or whether 
> "CorebootModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.inf",
>
>
> 
which SerialDxe depends on in the CorebootPayloadPkg build, is
> appropriate for your hardware? (This lib instance also consumes a 
> large set of PCDs.)

I was able to get some results after removing:
DebugLib|MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf
from Shell.inf section in DSC. Boot log:
http://81.95.197.197:7777/isenazutac

As you can see I'm getting some logs from Shell entry point and it
looks like DoShellPrompt start, but it doesn't appear on serial. In
DoShellPrompt thing wait on ShellInfoObject.NewEfiShellProtocol->ReadFile
so it seems no input from serial is accepted.

Any further steps appreciated. I believe I need no stuff related to
GOP, maybe it cause some problems ?

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

iQIzBAEBCAAdFiEE4DCbLYWmfoRjKeNLsu5x6WeqnkwFAlloB+kACgkQsu5x6Weq
nkxUJRAAn8vB7qYm7vvFiAU8n7YM3AkkJyWs0KoQOO/4vDqJU8/O3dgDsnOhMfa8
T4xD0w/DBRdn7l06IrEnGHrYq6qH7zXmY7H3+QU4J55off/LHqNYm1SwJ+8LCDU0
/3+8VKaG3j3SR+nw/+iYAK+jPRFC0CtRIT2eNseqRHyZyvVaBEs/gcmv0znHqAjS
rxkXc9VpkRbMq/dpoPpSbLtCf2D0d9G7QeyML4K+Kqhx66dnaKckUz7jS9amWE5b
diFH8rI9IzxugO4Yg/SQsGKnGdR2c4oOxiZbV+p8fbe/AyE5qB76V+YpM9bChB/0
5/kaiWrD4S4ucZH9mRb63Km4rFZV3Km2P0EWZvtaGNacIjvLoYH6kXlqDVemdDRQ
FxGhswPxDFYkhoXKN2TVUOVihKde37pkU2txDheQ60HdzcRl4uu3kSoX1g3j9gxe
+cDOv/K8GePbp6QRhVtOqz6qIsPbpffjucqnJ5fjKkHOqSFcj8d9hKhREoL5SbBW
YQXY9at0yLQWsvyOePcn5PFLxOpv6xr26KzLcAd6uKFMnxn64gXKZzrktJlY3VtQ
b2R57kADlluTLgpcprs2QSB/v1WSSQ9KLwV8FuoMAO4XyQ1S2mDQLQhbs70zJP+h
hcGK98Yqn0ItFinrOWT72sHUz35WUtUF8p9MdOd7eVxvcGLwwl4=
=qNsJ
-----END PGP SIGNATURE-----

Re: CorebootPayloadPkg: redirect UEFI Shell to serial

[Laszlo Ersek]

On 07/14/17 01:53, Piotr Król wrote:

> I was able to get some results after removing:
> DebugLib|MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf
> from Shell.inf section in DSC. Boot log:
> http://81.95.197.197:7777/isenazutac
>
> As you can see I'm getting some logs from Shell entry point and it
> looks like DoShellPrompt start, but it doesn't appear on serial. In
> DoShellPrompt thing wait on
> ShellInfoObject.NewEfiShellProtocol->ReadFile so it seems no input
> from serial is accepted.
>
> 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.

Thanks
Laszlo

Re: CorebootPayloadPkg: redirect UEFI Shell to serial

[Piotr Król]

-----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-----

Re: CorebootPayloadPkg: redirect UEFI Shell to serial

[Laszlo Ersek]

On 07/15/17 15:00, Piotr Król wrote:

> 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.

Typo corrections are welcome.

> 4. I had to move some PCDs to PcdsFixedAtBuild section.

Why?

> 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

As their name says, fixed-at-build PCDs can't be set at runtime.
- The .dec file declares the possible storage types for a given PCD that
any platform can assign to the PCD. The .dec file also sets a default value.
- in the platform .dsc file, the platform can omit the PCD completely.
In this case modules built into the platform will get the default value
from the .dec, and they won't be able to set the PCD.
- the platform .dsc can also spell out the PCD. This determines the
actual storage the platform assigns to the PCD (such as dynamic,
dynamic-ex, dynamic-hii, fixed-at-build) and also lets the platform set
its own default for the PCD. Modules built into the platform will see
the following values for the PCD:
  - if the PCD is fixed-at-build, then they'll get the value set in the
    DSC. The PCD cannot be set by modules.
  - if the PCD is dynamic or dynamic-ex, then the initial value is the
    one set in the DSC. Modules can overwrite the PCD, and later "get"s
    will return that value.
  - if the PCD is dynamic-hii, then it is backed by a non-volatile UEFI
    variable.

... This is quite a bit of hand-waving, but should be good enough for
now. The way fixed-at-build PCDs seem to work for you is by design; I'd
rather try to understand why you had to change a dynamic PCD into a
fixed one.

The rest of your questions should be directly addressed to the
maintainers of those packages / modules (see Maintainers.txt).

Thanks
Laszlo

Re: CorebootPayloadPkg: redirect UEFI Shell to serial

[Piotr Król]

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

On 07/25/2017 11:16 AM, Laszlo Ersek wrote:
> On 07/15/17 15:00, Piotr Król wrote:

Hi Laszlo,

> 
>> 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.
> 
> Typo corrections are welcome.

Patch sent.

> 
>> 4. I had to move some PCDs to PcdsFixedAtBuild section.
> 
> Why?

After reading your post I know I made mistake by taking your reference
to PlatformBootManagerLib in ArmVirtPkg without rewriting it
correctly. They use FixedAtBuild, but CorebootPayloadPkg provide the
same parameters as dynamic PCDs - this is some inconsistency that I
wanted to address.

I resolve my issue by using const value when mSerialConsole is
created, the  druing runtime I use PcdGet calls family to get correct
values.

> 
>> 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
> 
> As their name says, fixed-at-build PCDs can't be set at runtime. -
> The .dec file declares the possible storage types for a given PCD
> that any platform can assign to the PCD. The .dec file also sets a
> default value. - in the platform .dsc file, the platform can omit
> the PCD completely. In this case modules built into the platform
> will get the default value from the .dec, and they won't be able to
> set the PCD. - the platform .dsc can also spell out the PCD. This
> determines the actual storage the platform assigns to the PCD (such
> as dynamic, dynamic-ex, dynamic-hii, fixed-at-build) and also lets
> the platform set its own default for the PCD. Modules built into
> the platform will see the following values for the PCD: - if the
> PCD is fixed-at-build, then they'll get the value set in the DSC.
> The PCD cannot be set by modules. - if the PCD is dynamic or
> dynamic-ex, then the initial value is the one set in the DSC.
> Modules can overwrite the PCD, and later "get"s will return that
> value. - if the PCD is dynamic-hii, then it is backed by a
> non-volatile UEFI variable.
> 
> ... This is quite a bit of hand-waving, but should be good enough
> for now. The way fixed-at-build PCDs seem to work for you is by
> design; I'd rather try to understand why you had to change a
> dynamic PCD into a fixed one.

Thanks for this explanation.

> 
> The rest of your questions should be directly addressed to the 
> maintainers of those packages / modules (see Maintainers.txt).

I will send that in coming days.

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

iQIzBAEBCAAdFiEE4DCbLYWmfoRjKeNLsu5x6WeqnkwFAlmFDb8ACgkQsu5x6Weq
nkxJ6w/7BWXNDvE/svknuasRds4m8mtask1dkEeq/2VFlivHMffb+s9Cz6um5fOj
xjtOdZxtQBfjUHG6dW34v1wThq9qnpr1550WJaXv4gum2zMc2G40ffkq5Hluko8s
0qEGyVknZMu5+Z5rEbxirV38UudjO8+onZb4FQE26RiaLPr0TjmrgZUhWtTdXlq9
TbuGFSVe0u3RcASehreRB11dpCuDEknlBIyLqISlw065uchGMnBBVtkrxv4yf/fk
vh+INY7ja/Ap2sKHp4/+7lQ5e+bk0WcdfjCGwbnszqB307sncHIm2Xx33aBktolS
NcHuIh3SVbfsHZ2SiwOEDClLd4UFuW5qvwnkXXVytBFHOIHpdAhLwpNM8+rvFw3t
6T/cajO0MyWaBzOcT5wK4N1PxKtgRWHc2iTbjENTdSUFK0CiX0wjVRoPtJdBjxGS
WdP7NnXoDP0GLkdvMf+1FvamJHLwgP/3p5rwZ/WXGR8ySWrkOfE8h7O00VlRHdf4
OcXcf3ZmLCSZFpxstv3b/V5pK4EDISAu5VeoUbamwsnZQhaaDALvqNcf80Kp/7Yi
eyVYLP+mQWnptzvPc1tqbF/Pb4tDPTGPHZXSDKYbfd0LXwyUaHkwwGr/0VKTD1r/
B2O1H1tVSIWSMW3atEUUCitidGSscxOGDmRJP6g2H6wuuoP9C2k=
=kE52
-----END PGP SIGNATURE-----