[edk2-devel] Intel NUC platform firmware -- no serial I/O support?

Laszlo Ersek lersek at redhat.com
Wed Apr 13 06:06:23 UTC 2022


Hi Manic,

thanks a lot for spending time on this!

Laszlo

On 04/12/22 20:40, Manickavasakam Karpagavinayagam wrote:
> Laszlo :
> 
> Checked internally and came to know that Aptio BIOS for this platform doesn't support the serial redirection support during POST.
> 
> Thank you
> 
> -Manic
> 
>  -----Original Message-----
> From: Laszlo Ersek <lersek at redhat.com>
> Sent: Friday, April 8, 2022 5:20 AM
> To: Manickavasakam Karpagavinayagam <manickavasakamk at ami.com>; Gerd Hoffmann <kraxel at redhat.com>; Srini Narayana <SriniN at ami.com>; KarenLee [李致瑤] <KarenLee at ami.com>; Harikrishna Doppalapudi <Harikrishnad at ami.com>
> Cc: devel at edk2.groups.io; Ramesh R. <rameshr at ami.com>; Sivaraman Nainar <sivaramann at ami.com>
> Subject: Re: [EXTERNAL] Re: [edk2-devel] Intel NUC platform firmware -- no serial I/O support?
> 
> Hi Manic,
> 
> On 04/07/22 19:04, Manickavasakam Karpagavinayagam wrote:
>> Laszlo/Gred :
>>
>> Can you please let us know the GITHUB project location from where you have downloaded the source ?
> 
> I didn't download any new source code. I've just had my local edk2 clone as always, and the small patch at the bottom (adding "NucSerialPkg", just for the sake of buildig SerialDxe and TerminalDxe in separation) applies on top of current master.
> 
> Thanks
> Laszlo
> 
>>
>> Thank you
>>
>> -Manic
>>
>> -----Original Message-----
>> From: Laszlo Ersek <lersek at redhat.com>
>> Sent: Thursday, April 7, 2022 10:12 AM
>> To: Gerd Hoffmann <kraxel at redhat.com>
>> Cc: devel at edk2.groups.io; Ramesh R. <rameshr at ami.com>; Sivaraman
>> Nainar <sivaramann at ami.com>; Manickavasakam Karpagavinayagam
>> <manickavasakamk at ami.com>
>> Subject: [EXTERNAL] Re: [edk2-devel] Intel NUC platform firmware -- no serial I/O support?
>>
>>
>> **CAUTION: The e-mail below is from an external source. Please
>> exercise caution before opening attachments, clicking links, or
>> following guidance.**
>>
>> On 04/07/22 14:50, Gerd Hoffmann wrote:
>>
>>> Well, it at least looks like 16550 / ide hardware.  Not sure how this
>>> is actually implemented, I suspect it is virtual, maybe port access
>>> traps into SMM and it's emulated there.  Or the management engine can
>>> intercept those port accesses somehow.
>>
>>> If today's hardware still works the same way I'd expect you have a
>>> little driver taking the role of SioBusDxe, but binding to
>>> PCI_CLASS_COMMUNICATION_SERIAL devices instead of a LPC bridge with
>>> isa serial ports behind it.  Possibly the AMI drivers you've seen are
>>> just that.
>>>
>>> Does the NUC accept unsigned firmware updates?  If so we can maybe
>>> just add a SioBusDxe driver variant customized for the NUC hardware
>>
>> You are spot on, but reality is even simpler than this. :)
>>
>> Here's what I've done:
>>
>> (1) I cross-referenced three lists of PCI IDs:
>>
>> (1.1) The supported IDs in the windows UART driver INF file, downloaded from Intel, for this NUC.
>>
>> (1.2) The "lspci" output on the NUC.
>>
>> (1.3) The "drivers/mfd/intel-lpss-pci.c" file in the Linux tree.
>>
>> Result: there is no separate PCI device on this NUC that stands for a
>> serial controller. Furthermore, "intel-lpss-pci.c" suggests all the
>> "LPSS" serial ports (UARTs) are 16550 compatible -- see the reference
>> chain
>>
>> <all UART IDs> -> spt_uart_info -> uart_node -> uart_properties -> "snps,uart-16550-compatible".
>>
>> (2) While navigating the (graphical) Setup UI, I noticed that HII debug messages *were* sent to the serial port, by this nice, graphical, Setup Browser.
>>
>> (3) The particular (non-Linux) kernel that I booted on this NUC could flawlessly drive the serial port for input and output just by my specification of the bog standard params baud-rate=115200, 8 data bits, no parity, 1 stop bit.
>>
>> That gave me the following idea:
>>
>>> commit 0e794fe273b77830532ffb003b0d5539d7ae9823 (HEAD ->
>>> nuc_serial_pkg)
>>> Author: Laszlo Ersek <lersek at redhat.com>
>>> Date:   Thu Apr 7 14:37:13 2022 +0200
>>>
>>>     add NucSerialPkg: build SerialDxe and TerminalDxe for the
>>> NUC8i3PNH
>>>
>>>     Signed-off-by: Laszlo Ersek <lersek at redhat.com>
>>>
>>> diff --git a/NucSerialPkg/NucSerialPkg.dec
>>> b/NucSerialPkg/NucSerialPkg.dec new file mode 100644 index
>>> 000000000000..b077cde229c0
>>> --- /dev/null
>>> +++ b/NucSerialPkg/NucSerialPkg.dec
>>> @@ -0,0 +1,13 @@
>>> +## @file
>>> +#  UART 16650 serial port driver build for the NUC8i3PNH.
>>> +#
>>> +#  Copyright (c) 2022, Red Hat, Inc.
>>> +#
>>> +#  SPDX-License-Identifier: BSD-2-Clause-Patent ##
>>> +
>>> +[Defines]
>>> +  DEC_SPECIFICATION              = 1.29
>>> +  PACKAGE_NAME                   = NucSerialPkg
>>> +  PACKAGE_GUID                   = afdaaf17-4a06-4d97-a456-1ede0db46bc0
>>> +  PACKAGE_VERSION                = 0.1
>>> diff --git a/NucSerialPkg/NucSerialPkg.dsc
>>> b/NucSerialPkg/NucSerialPkg.dsc new file mode 100644 index
>>> 000000000000..971fb2f96a43
>>> --- /dev/null
>>> +++ b/NucSerialPkg/NucSerialPkg.dsc
>>> @@ -0,0 +1,46 @@
>>> +## @file
>>> +#  UART 16650 serial port driver build for the NUC8i3PNH.
>>> +#
>>> +#  Copyright (c) 2022, Red Hat, Inc.
>>> +#
>>> +#  SPDX-License-Identifier: BSD-2-Clause-Patent ##
>>> +
>>> +[Defines]
>>> +  PLATFORM_NAME                  = NucSerial
>>> +  PLATFORM_GUID                  = 30c397cf-a446-4f41-858f-9ae677547094
>>> +  PLATFORM_VERSION               = 0.1
>>> +  DSC_SPECIFICATION              = 1.30
>>> +  OUTPUT_DIRECTORY               = Build/NucSerial
>>> +  SUPPORTED_ARCHITECTURES        = X64
>>> +  BUILD_TARGETS                  = NOOPT|DEBUG|RELEASE
>>> +  SKUID_IDENTIFIER               = DEFAULT
>>> +
>>> +[BuildOptions]
>>> +  GCC:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG
>>> +  RELEASE_*_*_GENFW_FLAGS  = --zero
>>> +  GCC:*_*_*_CC_FLAGS       = -D DISABLE_NEW_DEPRECATED_INTERFACES
>>> +
>>> +[LibraryClasses]
>>> +  BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
>>> +  BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
>>> +  DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
>>> +
>>> +DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
>>> +  IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
>>> +
>>> +MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemor
>>> +MemoryAllocationLib|y
>>> +AllocationLib.inf
>>> +  PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
>>> +  PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
>>> +
>>> +RegisterFilterLib|MdePkg/Library/RegisterFilterLibNull/RegisterFilte
>>> +RegisterFilterLib|r
>>> +LibNull.inf
>>> +
>>> +ReportStatusCodeLib|MdePkg/Library/BaseReportStatusCodeLibNull/BaseR
>>> +ReportStatusCodeLib|e
>>> +portStatusCodeLibNull.inf
>>> +  SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
>>> +
>>> +UefiBootServicesTableLib|MdePkg/Library/UefiBootServicesTableLib/Uef
>>> +UefiBootServicesTableLib|i
>>> +BootServicesTableLib.inf
>>> +
>>> +UefiDriverEntryPoint|MdePkg/Library/UefiDriverEntryPoint/UefiDriverE
>>> +UefiDriverEntryPoint|n
>>> +tryPoint.inf
>>> +  UefiLib|MdePkg/Library/UefiLib/UefiLib.inf
>>> +
>>> +UefiRuntimeServicesTableLib|MdePkg/Library/UefiRuntimeServicesTableL
>>> +UefiRuntimeServicesTableLib|i
>>> +b/UefiRuntimeServicesTableLib.inf
>>> +
>>> +[PcdsFeatureFlag]
>>> +  gEfiMdePkgTokenSpaceGuid.PcdUgaConsumeSupport|FALSE
>>> +
>>> +[Components]
>>> +  MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
>>> +  MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
>>
>> The key line is the following lib class resolution:
>>
>>   SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
>>
>> It's the simplest possible (= most compatible) approach on X64.
>>
>> And It Just Works (TM), with the following two commands in the UEFI shell (after I copied the binaries to the USB stick, alongside the UEFI Shell binary I built earlier):
>>
>>> Shell> fs0:
>>> FS0:\> cd efi\boot
>>> FS0:\efi\boot\> load SerialDxe.efi
>>> Image 'FS0:\EFI\BOOT\SerialDxe.efi' loaded at 2C801000 - Success
>>> FS0:\efi\boot\> load TerminalDxe.efi Image
>>> 'FS0:\EFI\BOOT\TerminalDxe.efi' loaded at 2C7FB000 - Success
>>> FS0:\efi\boot\>
>>
>> At this point, the UEFI console is properly multiplexed to both serial and HDMI+USB.
>>
>> (Side comment: SerialDxe is not even a UEFI_DRIVER just a DXE_DRIVER,
>> so it produces SerialIo immediately.)
>>
>> With the serial console up, I can provide a "drivers" output too:
>>
>>> FS0:\efi\boot\> drivers
>>>             T   D
>>> D           Y C I
>>> R           P F A
>>> V  VERSION  E G G #D #C DRIVER NAME                         IMAGE NAME
>>> == ======== = = = == == =================================== ==========
>>> 49 00000017 D - -  1  - AMI USB Driver                      Uhcd
>>> 4B 00000017 B - -  1  3 AMI USB Bus Driver                  Uhcd
>>> 4C 00000002 D - -  2  - AMI USB Hid Driver                  Uhcd
>>> 4D 00000001 D - -  1  - AMI USB Mass Storage Driver         Uhcd
>>> 78 00010000 ? - -  -  - AMI NTFS Driver                     NTFS
>>> 7A 00000001 D - -  2  - <null string>                       MouseDriver
>>> 7D 00000001 D - -  1  - AMI AHCI BUS Driver                 Ahci
>>> 7F 00000010 ? - -  -  - AMI Serial I/O Driver               SerialIo
>>> 83 00000001 B - -  1  1 AMI NVMe BUS Driver                 Nvme
>>> 124 00000010 D - -  1  - Serial ATA Controller Initializatio
>>> SataController
>>> 132 00000010 B - -  2  2 AMI Console Splitter Text Out Drive
>>> ConSplitter
>>> 133 00000010 B - -  2  2 AMI Console Splitter Text In Driver
>>> ConSplitter
>>> 134 00000010 B - -  1  1 AMI Console Splitter Pointer Driver ConSplitter
>>> 137 00000010 D - -  1  - AMI Graphic Console Driver          GraphicsConsole
>>> 138 0000000A D - -  8  - Generic Disk I/O Driver             DiskIoDxe
>>> 139 0000000B B - -  2  6 Partition Driver(MBR/GPT/El Torito) PartitionDxe
>>> 13D 00000000 ? - -  -  - Integrated Touch Driver             IntegratedTouch
>>> 13E 0000000A ? - -  -  - Bluetooth Bus Driver                BluetoothBusDxe
>>> 13F 0000000A ? - -  -  - <null string>                       BluetoothBusDxe
>>> 140 0000000A ? - -  -  - Bluetooth Connection Manager        BluetoothConfigDxe
>>> 141 0000000A ? - -  -  - Bluetooth HID Driver                BluetoothHidDxe
>>> 142 0000000A ? - -  -  - Hid Keyboard Driver                 HidKbDxe
>>> 143 0000000A ? - -  -  - Hid Mouse Driver                    HidMouseDxe
>>> 147 00000010 D - -  1  - AMI Generic LPC Super I/O Driver    GenericSio
>>> 149 00A50111 B - -  1 17 AMI PCI Bus Driver                  PciBus
>>> 14B 00000010 ? - -  -  - AMI PS/2 Driver                     Ps2Main
>>> 14D 00000010 ? - -  -  - AMI Terminal Driver                 TerminalSrc
>>> 14E 0000000A ? - -  -  - IpSec Driver                        IpSecDxe
>>> 150 0000000A ? - -  -  - IpSec Driver                        IpSecDxe
>>> 151 0000000A ? - -  -  - VLAN Configuration Driver           VlanConfigDxe
>>> 152 0000000A ? - -  -  - HttpDxe                             HttpDxe
>>> 153 0000000A ? - -  -  - HttpDxe                             HttpDxe
>>> 154 00000000 ? - -  -  - DNS Network Service Driver          DnsDxe
>>> 155 00000000 ? - -  -  - DNS Network Service Driver          DnsDxe
>>> 158 0000000A D - -  4  - FAT File System Driver              Fat
>>> 159 0000000A ? - -  -  - iSCSI Driver                        IScsiDxe
>>> 15A 0000000A ? - -  -  - iSCSI Driver                        IScsiDxe
>>> 15C 0000000A ? - -  -  - SCSI Bus Driver                     ScsiBus
>>> 15D 0000000A ? - -  -  - Scsi Disk Driver                    ScsiDisk
>>> 16A 0900044A B - -  1  1 Intel(R) GOP Driver [9.0.1098]      MemoryMapped(0x3,0x29A33018,0x29A44A98)
>>> 19B 0000000A B - -  1  1 Serial Terminal Driver              \EFI\BOOT\TerminalDxe.efi
>>
>> SerialDxe is not in the list, as it is not a UEFI driver (it does not install an instance of the Driver Binding protocol).
>>
>> The curious parts are:
>>
>> - what the "TerminalSrc" driver ("AMI Terminal Driver") stands for (it
>>   does not bind the SerialIo instance installed by SerialDxe, not even
>>   after "connect -r" -- that's why I need TerminalDxe from edk2),
>>
>> - why the platform firmware packager thought it would be a good idea to
>>   *exclude* the SerialDxe and TerminalDxe drivers -- these binaries
>>   weigh in at 23 KB together, in a DEBUG build! And the hardware is
>>   there...
>>
>> Thanks,
>> Laszlo
>>
>> -The information contained in this message may be confidential and proprietary to American Megatrends (AMI). This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission.
>>
> 
> -The information contained in this message may be confidential and proprietary to American Megatrends (AMI). This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission.
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#88843): https://edk2.groups.io/g/devel/message/88843
Mute This Topic: https://groups.io/mt/90308335/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-




More information about the edk2-devel-archive mailing list