[edk2] [staging/PRMCaseStudy]: Creating a new feature branch "PRMCaseStudy"
Hi, A new feature branch "PRMCaseStudy" is being created in edk2-staging. Platform Runtime Mechanism (PRM) is an architecture for ACPI codes to call into UEFI BIOS's Runtime Services at OS runtime. Traditionally, ACPI codes call into BIOS through the invocation of Software SMIs. When applicable, PRM provides an alternative for ACPI codes to invoke UEFI Runtime Services, which runs in OS kernel space, without invoking SMM. This package contains proof-of-concept codes that implement the ideas of PRM. Resources: - PRM introduction: https://www.opencompute.org/events/past-summits (Please search for "UEFI Implementation Intel(r) Xeon Based OCP Platform" in the webpage, which lists pointers to video and presentation that introduce the concept of PRM) - TianoCore: http://www.tianocore.org - UEFI Forum: https://uefi.org/ Thanks, -ben ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] CorebootModulePkg: Fix various typos
Reviewed-by: Benjamin You > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Antoine Coeur > Sent: Thursday, February 7, 2019 12:47 AM > To: edk2-devel@lists.01.org > Subject: [edk2] [PATCH] CorebootModulePkg: Fix various typos > > Fix various typos in CorebootModulePkg. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Coeur > --- > .../Include/Library/CbParseLib.h | 36 +-- > .../BaseSerialPortLib16550.c | 12 +++ > .../Library/CbParseLib/CbParseLib.c | 6 ++-- > .../SataControllerDxe/SataController.h| 2 +- > CorebootModulePkg/SecCore/FindPeiCore.c | 2 +- > CorebootModulePkg/SecCore/Ia32/Stack.S| 18 +- > CorebootModulePkg/SecCore/Ia32/Stack.asm | 18 +- > CorebootModulePkg/SecCore/Ia32/Stack.nasm | 2 +- > CorebootModulePkg/SecCore/SecMain.c | 14 > CorebootModulePkg/SecCore/SecMain.h | 4 +-- > 10 files changed, 57 insertions(+), 57 deletions(-) > > diff --git a/CorebootModulePkg/Include/Library/CbParseLib.h > b/CorebootModulePkg/Include/Library/CbParseLib.h > index 12dd4fa979..be39bd0923 100644 > --- a/CorebootModulePkg/Include/Library/CbParseLib.h > +++ b/CorebootModulePkg/Include/Library/CbParseLib.h > @@ -25,7 +25,7 @@ typedef RETURN_STATUS \ >@param TagThe tag id to be found > >@retval NULL The Tag is not found. > - @retval OthersThe poiter to the record found. > + @retval OthersThe pointer to the record found. > > **/ > VOID * > @@ -51,7 +51,7 @@ CbParseMemoryInfo ( >IN CB_MEM_INFO_CALLBACK MemInfoCallback, >IN VOID *pParam >); > - > + > /** >Acquire the coreboot memory table with the given table id > > @@ -67,11 +67,11 @@ CbParseMemoryInfo ( > RETURN_STATUS > EFIAPI > CbParseCbMemTable ( > - IN UINT32 TableId, > + IN UINT32 TableId, >IN VOID** pMemTable, >IN UINT32*pMemTableSize >); > - > + > /** >Acquire the acpi table from coreboot > > @@ -89,7 +89,7 @@ CbParseAcpiTable ( >IN VOID** pMemTable, >IN UINT32*pMemTableSize >); > - > + > /** >Acquire the smbios table from coreboot > > @@ -107,14 +107,14 @@ CbParseSmbiosTable ( >IN VOID** pMemTable, >IN UINT32*pMemTableSize >); > - > + > /** >Find the required fadt information > >@param pPmCtrlReg Pointer to the address of power management > control register >@param pPmTimerRegPointer to the address of power management > timer register >@param pResetReg Pointer to the address of system reset register > - @param pResetValuePointer to the value to be writen to the system > reset register > + @param pResetValuePointer to the value to be written to the system > reset register >@param pPmEvtReg Pointer to the address of power management event > register >@param pPmGpeEnRegPointer to the address of power management GPE > enable register > > @@ -132,16 +132,16 @@ CbParseFadtInfo ( >IN UINTN* pPmEvtReg, >IN UINTN* pPmGpeEnReg >); > - > + > /** >Find the serial port information > >@param pRegBase Pointer to the base address of serial port > registers >@param pRegAccessType Pointer to the access type of serial port > registers > - @param pRegWidth Pointer to the register width in bytes > + @param pRegWidth Pointer to the register width in bytes >@param pBaudrate Pointer to the serial port baudrate > - @param pInputHertzPointer to the input clock frequency > - @param pUartPciAddr Pointer to the UART PCI bus, dev and func > address > + @param pInputHertzPointer to the input clock frequency > + @param pUartPciAddr Pointer to the UART PCI bus, dev and func > address > >@retval RETURN_SUCCESS Successfully find the serial port information. >@retval RETURN_NOT_FOUND Failed to find the serial port information . > @@ -150,12 +150,12 @@ CbParseFadtInfo ( > RETURN_STATUS > EFIAPI > CbParseSerialInfo ( > - OUT UINT32 *pRegBase, > - OUT UINT32 *pRegAccessType, > - OUT UINT32 *pRegWidth, > - OUT UINT32 *pBaudrate, > - OUT UINT32 *pInputHertz, > - OUT UINT32 *pUartPciAddr > + OUT UINT32 *pRegBase, > + OUT UINT32 *pRegAccessType, > + OUT UINT32 *pRegWidth, > + OUT UINT32 *pBaudrate, > + OUT UINT32 *pInputHertz, > + OUT UINT32 *pUartPciAddr >); > > /** > @@ -174,7 +174,7 @@ CbParseGetCbHeader ( >IN UINTN Level, >IN VOID** HeaderPtr >); > - > + > /** >Find the video frame buffer information > > diff --git > a/CorebootModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550. > c > b/CorebootModulePkg/Library/BaseSerialPortLib16550/BaseSerial
Re: [edk2] [PATCH] CorebootPayloadPkg: Fix various typos
Reviewed-by: Benjamin You
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Antoine Coeur
> Sent: Thursday, February 7, 2019 12:49 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [PATCH] CorebootPayloadPkg: Fix various typos
>
> Fix various typos in CorebootPayloadPkg.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Coeur
> ---
> CorebootPayloadPkg/FbGop/FbGop.c | 8 +-
> CorebootPayloadPkg/FbGop/FbGop.h | 8 +-
> .../Library/PciHostBridgeLib/PciHostBridge.h | 2 +-
> .../PciHostBridgeLib/PciHostBridgeLib.c | 2 +-
> .../PciHostBridgeLib/PciHostBridgeSupport.c | 6 +-
> .../PlatformBootManager.c | 2 +-
> .../Library/PlatformHookLib/PlatformHookLib.c | 106 +-
> 7 files changed, 67 insertions(+), 67 deletions(-)
>
> diff --git a/CorebootPayloadPkg/FbGop/FbGop.c
> b/CorebootPayloadPkg/FbGop/FbGop.c
> index ecafc95ae3..9a66943cbf 100644
> --- a/CorebootPayloadPkg/FbGop/FbGop.c
> +++ b/CorebootPayloadPkg/FbGop/FbGop.c
> @@ -262,7 +262,7 @@ FbGopDriverBindingStart (
> if (IsDevicePathEnd (RemainingDevicePath)) {
>//
>// If RemainingDevicePath is the End of Device Path Node,
> - // don't create any child device and return EFI_SUCESS
> + // don't create any child device and return EFI_SUCCESS
>Status = EFI_SUCCESS;
>goto Done;
> }
> @@ -688,7 +688,7 @@ FbGopChildHandleUninstall (
>
>
> /**
> - Release resource for biso video instance.
> + Release resource for bios video instance.
>
>@param FbGopPrivate Video child device private data structure
>
> @@ -703,7 +703,7 @@ FbGopDeviceReleaseResource (
>}
>
>//
> - // Release all the resourses occupied by the FB_VIDEO_DEV
> + // Release all the resources occupied by the FB_VIDEO_DEV
>//
>
>//
> @@ -1222,7 +1222,7 @@ FbGopVbeBltWorker (
>}
>//
>// We need to fill the Virtual Screen buffer with the blt data.
> - // The virtual screen is upside down, as the first row is the bootom row of
> + // The virtual screen is upside down, as the first row is the bottom row of
>// the image.
>//
>if (BltOperation == EfiBltVideoToBltBuffer) {
> diff --git a/CorebootPayloadPkg/FbGop/FbGop.h
> b/CorebootPayloadPkg/FbGop/FbGop.h
> index 4445f5c730..112d5c5cb5 100644
> --- a/CorebootPayloadPkg/FbGop/FbGop.h
> +++ b/CorebootPayloadPkg/FbGop/FbGop.h
> @@ -205,7 +205,7 @@ FbGopCheckForVbe (
>
>
> /**
> - Release resource for biso video instance.
> + Release resource for bios video instance.
>
>@param FbGopPrivate Video child device private data structure
>
> @@ -311,9 +311,9 @@ FbGopGraphicsOutputVbeBlt (
>
>
> /**
> - Grahpics Output protocol instance to block transfer for VGA device.
> + Graphics Output protocol instance to block transfer for VGA device.
>
> - @param This Pointer to Grahpics Output protocol instance
> + @param This Pointer to Graphics Output protocol instance
>@param BltBuffer The data to transfer to screen
>@param BltOperation The operation to perform
>@param SourceXThe X coordinate of the source for
> BltOperation
> @@ -394,7 +394,7 @@ FbGopChildHandleUninstall (
>);
>
> /**
> - Release resource for biso video instance.
> + Release resource for bios video instance.
>
>@param FbGopPrivate Video child device private data structure
>
> diff --git a/CorebootPayloadPkg/Library/PciHostBridgeLib/PciHostBridge.h
> b/CorebootPayloadPkg/Library/PciHostBridgeLib/PciHostBridge.h
> index 4852ed0d8d..c777cdbac1 100644
> --- a/CorebootPayloadPkg/Library/PciHostBridgeLib/PciHostBridge.h
> +++ b/CorebootPayloadPkg/Library/PciHostBridgeLib/PciHostBridge.h
> @@ -42,7 +42,7 @@ ScanForRootBridges (
> assigned to any subordinate bus found behind
> any
> PCI bridge hanging off this root bus.
>
> - The caller is repsonsible for ensuring that
> + The caller is responsible for ensuring that
> RootBusNumber <= MaxSubBusNumber. If
> RootBusNumber equals MaxSubBusNumber, then the
> root bus has no room for subordinate buses.
> diff --git a/CorebootPayloadPkg/Library/PciHostBridgeLib/PciHostBridgeLib.c
> b/CorebootPayloadPkg/Library/PciHostBridgeLib/PciHostBridgeLib.c
> index b0a6361557..f7e1369a08 100644
> --- a/CorebootPayloadPkg/Library/PciHostBridgeLib/PciHostBridgeLib.c
> +++ b/CorebootPayloadPkg/Library/PciHostBridgeLib/PciHostBridgeLib.c
> @@ -70,7 +70,7 @@ CB_PCI_ROOT_BRIDGE_DEVICE_PATH
> mRootBridgeDevicePathTemplate = {
> assigned to any subordinate bus found behind
> any
> PCI bridge
Re: [edk2] [PATCH V3 16/17] CorebootPayloadPkg: Use merged variable driver for emulated NV mode
Reviewed-by: Benjamin You
> -Original Message-
> From: Zeng, Star
> Sent: Tuesday, January 15, 2019 6:30 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Ma, Maurice ;
> Agyeman, Prince ; You, Benjamin
>
> Subject: [PATCH V3 16/17] CorebootPayloadPkg: Use merged variable driver for
> emulated NV mode
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1323
> Merge EmuVariable and Real variable driver.
>
> The real variable driver has been updated to support emulated
> variable NV mode and the EmuVariableRuntimeDxe will be removed
> later, so use merged variable driver for emulated NV mode.
>
> Cc: Maurice Ma
> Cc: Prince Agyeman
> Cc: Benjamin You
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng
> ---
> CorebootPayloadPkg/CorebootPayloadPkg.fdf| 4 ++--
> CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc| 11 +--
> CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc | 11 +--
> 3 files changed, 20 insertions(+), 6 deletions(-)
>
> diff --git a/CorebootPayloadPkg/CorebootPayloadPkg.fdf
> b/CorebootPayloadPkg/CorebootPayloadPkg.fdf
> index 741a5c232ed8..0c24f96a1561 100644
> --- a/CorebootPayloadPkg/CorebootPayloadPkg.fdf
> +++ b/CorebootPayloadPkg/CorebootPayloadPkg.fdf
> @@ -3,7 +3,7 @@
> #
> # Provides drivers and definitions to create uefi payload for coreboot.
> #
> -# Copyright (c) 2014 - 2017, Intel Corporation. All rights reserved.
> +# Copyright (c) 2014 - 2019, Intel Corporation. All rights reserved.
> # This program and the accompanying materials are licensed and made
> available under
> # the terms and conditions of the BSD License that accompanies this
> distribution.
> # The full text of the license may be found at
> @@ -109,7 +109,7 @@ [FV.DXEFV]
> INF
> MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterR
> untimeDxe.inf
> INF
> MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.in
> f
> INF
> PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe
> .inf
> -INF
> MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariableRuntimeDxe.i
> nf
> +INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
>
> INF UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
> INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
> diff --git a/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
> b/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
> index 467d4fcdb422..98d6073866f0 100644
> --- a/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
> +++ b/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
> @@ -3,7 +3,7 @@
> #
> # Provides drivers and definitions to create uefi payload for coreboot.
> #
> -# Copyright (c) 2014 - 2017, Intel Corporation. All rights reserved.
> +# Copyright (c) 2014 - 2019, Intel Corporation. All rights reserved.
> # This program and the accompanying materials are licensed and made
> available under
> # the terms and conditions of the BSD License that accompanies this
> distribution.
> # The full text of the license may be found at
> @@ -203,6 +203,9 @@ [LibraryClasses]
>
> DebugLib|MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDe
> bugLibReportStatusCode.inf
>LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf
>FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
> +
> AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibN
> ull.inf
> +
> TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmM
> easurementLibNull.inf
> + VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
>
> [LibraryClasses.IA32.SEC]
>DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
> @@ -277,6 +280,10 @@ [PcdsFixedAtBuild]
>gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x1
>
> gEfiMdeModulePkgTokenSpaceGuid.PcdMaxHardwareErrorVariableSize|0x8000
>gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0x1
> + #
> + # Make VariableRuntimeDxe work at emulated non-volatile variable mode.
> + #
> + gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvModeEnable|TRUE
>
>gEfiMdeModulePkgTokenSpaceGuid.PcdVpdBaseAddress|0x0
>gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa,
> 0x2c, 0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23,
> 0x31 }
> @@ -417,7 +424,7 @@ [Components.IA32]
>
> MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterR
> untimeDxe.inf
>
> MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.in
> f
>
> PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe
> .inf
> -
> MdeModulePkg/Universa
Re: [edk2] [PATCH v3 5/5] CorebootPayloadPkg: Remove EdkShellBinPkg in FDF
Reviewed-by: Benjamin You
> -Original Message-
> From: Zhang, Shenglei
> Sent: Monday, November 5, 2018 11:08 AM
> To: edk2-devel@lists.01.org
> Cc: Zhang, Shenglei ; Ma, Maurice
> ; Agyeman, Prince ; You,
> Benjamin
> Subject: [PATCH v3 5/5] CorebootPayloadPkg: Remove EdkShellBinPkg in FDF
>
> From: shenglei
>
> Remove EdkShellBinPkg in CorebootPayloadPkg.fdf.
> https://bugzilla.tianocore.org/show_bug.cgi?id=1108
>
> v3:Remove FULL_BIN and change SHELL_TYPE from FULL_BIN
> to UEFI_BIN.
>
> Cc: Maurice Ma
> Cc: Prince Agyeman
> Cc: Benjamin You
> Change-Id: I4db7068a3a1f68a1f6303079b73dc548c9feb2e3
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Shenglei Zhang
> ---
> CorebootPayloadPkg/CorebootPayloadPkg.fdf| 8
> CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc| 9 ++---
> CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc | 9 ++---
> 3 files changed, 4 insertions(+), 22 deletions(-)
>
> diff --git a/CorebootPayloadPkg/CorebootPayloadPkg.fdf
> b/CorebootPayloadPkg/CorebootPayloadPkg.fdf
> index 7994f0c949..741a5c232e 100644
> --- a/CorebootPayloadPkg/CorebootPayloadPkg.fdf
> +++ b/CorebootPayloadPkg/CorebootPayloadPkg.fdf
> @@ -185,14 +185,6 @@ INF
> ShellPkg/DynamicCommand/DpDynamicCommand/DpDynamicCommand.inf
> INF ShellPkg/Application/Shell/Shell.inf
> !endif
>
> -!if $(SHELL_TYPE) == FULL_BIN
> -!if $(ARCH) == IA32
> -INF RuleOverride = BINARY USE = IA32 EdkShellBinPkg/FullShell/FullShell.inf
> -!else
> -INF RuleOverride = BINARY USE = X64 EdkShellBinPkg/FullShell/FullShell.inf
> -!endif
> -!endif
> -
> !if $(SHELL_TYPE) == MIN_BIN
> !if $(ARCH) == IA32
> INF RuleOverride = BINARY USE = IA32
> ShellBinPkg/MinUefiShell/MinUefiShell.inf
> diff --git a/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
> b/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
> index 7d5052be93..467d4fcdb4 100644
> --- a/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
> +++ b/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
> @@ -83,9 +83,9 @@
>DEFINE USE_HPET_TIMER = FALSE
>
>#
> - # Shell options: [BUILD_SHELL, FULL_BIN, MIN_BIN, NONE, UEFI]
> + # Shell options: [BUILD_SHELL, MIN_BIN, NONE, UEFI]
>#
> - DEFINE SHELL_TYPE = FULL_BIN
> + DEFINE SHELL_TYPE = UEFI_BIN
>
> [BuildOptions]
>*_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
> @@ -327,13 +327,8 @@
>#
># Set the proper Shell file GUID
>#
> - !if $(SHELL_TYPE) == FULL_BIN
> - # c57ad6b7-0515-40a8-9d21-551652854e37
> - gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0xB7, 0xD6,
> 0x7A, 0xC5, 0x15, 0x05, 0xA8, 0x40, 0x9D, 0x21, 0x55, 0x16, 0x52, 0x85, 0x4E,
> 0x37 }
> - !else
># 7C04A583-9E3E-4f1c-AD65-E05268D0B4D1
>gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5,
> 0x04, 0x7C, 0x3E, 0x9E, 0x1c, 0x4f, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4,
> 0xD1 }
> - !endif
>
>
> #
> ###
> #
> diff --git a/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
> b/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
> index 0484e941cc..673bd26c79 100644
> --- a/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
> +++ b/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc
> @@ -83,9 +83,9 @@
>DEFINE USE_HPET_TIMER = FALSE
>
>#
> - # Shell options: [BUILD_SHELL, FULL_BIN, MIN_BIN, NONE, UEFI]
> + # Shell options: [BUILD_SHELL, MIN_BIN, NONE, UEFI]
>#
> - DEFINE SHELL_TYPE = FULL_BIN
> + DEFINE SHELL_TYPE = UEFI_BIN
>
> [BuildOptions]
>*_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
> @@ -328,13 +328,8 @@
>#
># Set the proper Shell file GUID
>#
> - !if $(SHELL_TYPE) == FULL_BIN
> - # c57ad6b7-0515-40a8-9d21-551652854e37
> - gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0xB7, 0xD6,
> 0x7A, 0xC5, 0x15, 0x05, 0xA8, 0x40, 0x9D, 0x21, 0x55, 0x16, 0x52, 0x85, 0x4E,
> 0x37 }
> - !else
># 7C04A583-9E3E-4f1c-AD65-E05268D0B4D1
>gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5,
> 0x04, 0x7C, 0x3E, 0x9E, 0x1c, 0x4f, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4,
> 0xD1 }
> - !endif
>
>
> #
> ###
> #
> --
> 2.18.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] CorebootPayloadPkg: don't use serial output for Release build
Hi, Reviewed-by: Benjamin You Thanks, - ben > -Original Message- > From: Wonkyu Kim [mailto:norwayfores...@gmail.com] > Sent: Tuesday, October 16, 2018 6:45 AM > To: edk2-devel@lists.01.org > Cc: You, Benjamin ; Agyeman, Prince > ; gauml...@gmail.com; > stefan.reina...@coreboot.org; Williams, Hannah ; > Kim, Wonkyu ; Zhao, Lijian > Subject: [PATCH] CorebootPayloadPkg: don't use serial output for Release build > > From: Wonkyu Kim > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Wonkyu Kim > --- > CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc| 4 > CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc | 4 > 2 files changed, 8 insertions(+) > > diff --git a/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc > b/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc > index b6cdb697a5b0..7d5052be9301 100644 > --- a/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc > +++ b/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc > @@ -263,7 +263,11 @@ > # > > # > ### > [PcdsFeatureFlag] > +!if $(TARGET) == DEBUG >gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseSerial|TRUE > +!else > + gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseSerial|FALSE > +!endif >gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseMemory|FALSE >gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode|FALSE >gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE > diff --git a/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc > b/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc > index c3fe099e5fec..0484e941cce7 100644 > --- a/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc > +++ b/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc > @@ -263,7 +263,11 @@ > # > > # > ### > [PcdsFeatureFlag] > +!if $(TARGET) == DEBUG >gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseSerial|TRUE > +!else > + gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseSerial|FALSE > +!endif >gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseMemory|FALSE >gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode|TRUE >gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE > -- > 2.17.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [staging/UEFIPayload]: Creating a new feature branch UEFIPayload in edk2-staging
Hi Mike, Yes, this work aims at being the successor of Coreboot*Pkgs after it matures. I've followed your recommendations in the UEFIPayload branch created at https://github.com/tianocore/edk2-staging/tree/UEFIPayload Thanks, - ben > -Original Message- > From: Kinney, Michael D > Sent: Saturday, September 15, 2018 1:38 AM > To: You, Benjamin ; edk2-devel@lists.01.org; Kinney, > Michael D > Subject: RE: [edk2] [staging/UEFIPayload]: Creating a new feature branch > UEFIPayload in edk2-staging > > Hi Benjamin, > > Once this work is complete would the CoreBoot*Pkgs > be removed from edk2/master and the UefiPayloadPkg > added? > > In order to remove the Readme.md conflict, I recommend > cloning edk2 and edk2-statging into different directories > and use PACKAGES_PATH for the build to see packages from > both repos. > > You also need to clone the edk2 repo recursively so it > pulls in the OpenSLL submodule. > > Thanks, > > Mike > > > -Original Message----- > > From: edk2-devel [mailto:edk2-devel- > > boun...@lists.01.org] On Behalf Of You, Benjamin > > Sent: Friday, September 14, 2018 6:47 AM > > To: edk2-devel@lists.01.org > > Subject: [edk2] [staging/UEFIPayload]: Creating a new > > feature branch UEFIPayload in edk2-staging > > > > Hi, > > > > A new feature branch "UEFIPayload" is being created in > > edk2-staging. > > > > UEFI Payload (UefiPayloadPkg) aims to be an upgrade to > > CorebootModulePkg and CorebootPayloadPkg > > > > UEFI Payload has some new features: > > * Supporting Slim Bootloader in addition to Coreboot > > * Source level configuration using .ini format > > * User Extension using simple "C" codes > > * Platform support library for adding platform specific > > codes > > > > A draft version can be found at > > https://github.com/BenjaminYou/UEFIPayload > > > > Thanks, > > > > - ben > > ___ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [staging/UEFIPayload]: Creating a new feature branch UEFIPayload in edk2-staging
Hi, The UEFIPayload feature branch has been created at: https://github.com/tianocore/edk2-staging/tree/UEFIPayload Thanks, - ben > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of You, > Benjamin > Sent: Friday, September 14, 2018 9:47 PM > To: edk2-devel@lists.01.org > Subject: [edk2] [staging/UEFIPayload]: Creating a new feature branch > UEFIPayload in edk2-staging > > Hi, > > A new feature branch "UEFIPayload" is being created in edk2-staging. > > UEFI Payload (UefiPayloadPkg) aims to be an upgrade to CorebootModulePkg > and CorebootPayloadPkg > > UEFI Payload has some new features: > * Supporting Slim Bootloader in addition to Coreboot > * Source level configuration using .ini format > * User Extension using simple "C" codes > * Platform support library for adding platform specific codes > > A draft version can be found at https://github.com/BenjaminYou/UEFIPayload > > Thanks, > > - ben > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [staging/UEFIPayload]: Creating a new feature branch UEFIPayload in edk2-staging
Hi, A new feature branch "UEFIPayload" is being created in edk2-staging. UEFI Payload (UefiPayloadPkg) aims to be an upgrade to CorebootModulePkg and CorebootPayloadPkg UEFI Payload has some new features: * Supporting Slim Bootloader in addition to Coreboot * Source level configuration using .ini format * User Extension using simple "C" codes * Platform support library for adding platform specific codes A draft version can be found at https://github.com/BenjaminYou/UEFIPayload Thanks, - ben ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Reg: Intel Rangley Support in EDK
Hi Dhanasekar, You can check out Maintainers.txt in the root directory of the EDK2 tree for a list of maintainers for each package. For FSP related packages, you can consult following folks: Jiewen Yao Chasel Chiu Thanks, - ben > From: Dhanasekar Jaganathan [mailto:jdhanasekar...@gmail.com] > Sent: Friday, July 27, 2018 12:46 PM > To: You, Benjamin > Cc: Desimone, Nathaniel L ; > edk2-devel@lists.01.org > Subject: Re: [edk2] Reg: Intel Rangley Support in EDK > > Hi Ben, > > Thanks for sharing. > I am unable to find owners of FSP. > Where Can I get those details ?. > > Thanks, > Dhanasekar > > On Fri, Jul 27, 2018 at 6:15 AM, You, Benjamin wrote: > Hi Dhanasekar, > > Here is a link: > https://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Using_the_Intel_Firmware_Support_Package_Version_1_1_with_the_EFI_Developer_Kit_II.pdf > > You may also consult the owners of the FSP related packages in the EDK2 repo > for any questions. > > Thanks, > > - ben > > > > From: Dhanasekar Jaganathan [mailto:jdhanasekar...@gmail.com] > > Sent: Thursday, July 26, 2018 8:45 PM > > To: You, Benjamin > > Cc: Desimone, Nathaniel L ; > > edk2-devel@lists.01.org > > Subject: Re: [edk2] Reg: Intel Rangley Support in EDK > > > > Hi Nate, Ben, > > > > > > Can you please provide me the steps to integrate FSP with latest EDK2 > > source ?. I didnt get clear steps from net (seems steps are compatible with > > latest source). > > Which are the changes I have to do in latest EDK2 source and in which > > location I have to copy FSP binary ?. > > My FSP version is 1.1. > > Please share me links or example projects. > > > > Thanks, > > dhanasekar > > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Reg: Intel Rangley Support in EDK
Hi Dhanasekar,
Here is a link:
https://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Using_the_Intel_Firmware_Support_Package_Version_1_1_with_the_EFI_Developer_Kit_II.pdf
You may also consult the owners of the FSP related packages in the EDK2 repo
for any questions.
Thanks,
- ben
> From: Dhanasekar Jaganathan [mailto:jdhanasekar...@gmail.com]
> Sent: Thursday, July 26, 2018 8:45 PM
> To: You, Benjamin
> Cc: Desimone, Nathaniel L ;
> edk2-devel@lists.01.org
> Subject: Re: [edk2] Reg: Intel Rangley Support in EDK
>
> Hi Nate, Ben,
>
>
> Can you please provide me the steps to integrate FSP with latest EDK2 source
> ?. I didnt get clear steps from net (seems steps are compatible with latest
> source).
> Which are the changes I have to do in latest EDK2 source and in which
> location I have to copy FSP binary ?.
> My FSP version is 1.1.
> Please share me links or example projects.
>
> Thanks,
> dhanasekar
>
> On Wed, Jul 18, 2018 at 1:12 PM, You, Benjamin wrote:
> Hi, Dhanasekar,
>
> I see "console=tty0 console=ttyUSB0,115200n8" in your configuration.
>
> You might want to check if "ttyUSB0" matches what Linux kernel denotes
> your serial port.
>
> I am not expert in Linux kernel so not exactly sure how to debug this. A
> possible way may be trying to enable Linux serial output on a known good
> BIOS with your board (if there is such a BIOS) first.
>
> Thanks,
>
> - ben
>
> > From: Dhanasekar Jaganathan [mailto:jdhanasekar...@gmail.com]
> > Sent: Wednesday, July 18, 2018 3:06 PM
> > To: You, Benjamin
> > Cc: Desimone, Nathaniel L ;
> > edk2-devel@lists.01.org
> > Subject: Re: [edk2] Reg: Intel Rangley Support in EDK
> >
> > Hi Ben,
> >
> > I have shared my grub.cfg below,
> >
> > if loadfont /boot/grub/font.pf2 ; then
> > set gfxmode=auto
> > insmod efi_gop
> > insmod efi_uga
> > insmod gfxterm
> > terminal_output gfxterm
> > fi
> >
> > set menu_color_normal=white/black
> > set menu_color_highlight=black/light-gray
> >
> > set timeout=5
> > menuentry "Install Ubuntu Server" {
> > set gfxpayload=keep
> > #DJ linux /casper/vmlinuz boot=casper quiet ---
> > linux /casper/vmlinuz file=/cdrom/preseed/ubuntu-server.seed
> > vga=normal console=tty0 console=ttyUSB0,115200n8 ---
> > initrd /casper/initrd.gz
> > }
> > menuentry "OEM install (for manufacturers)" {
> > set gfxpayload=keep
> > linux /casper/vmlinuz boot=casper only-ubiquity quiet splash
> > oem-config/enable=true ---
> > initrd /casper/initrd.gz
> > }
> > menuentry "Check disc for defects" {
> > set gfxpayload=keep
> > linux /casper/vmlinuz boot=casper integrity-check quiet splash ---
> > initrd /casper/initrd.gz
> > }
> >
> > Thanks,
> > Dhanasekar
> >
> > On Wed, Jul 18, 2018 at 11:28 AM, You, Benjamin
> > wrote:
> > Hi, Dhanasekar,
> >
> > Linux boot parameters allow specifying serial baudrate. An example would
> > be:
> > earlycon=uart8250,mmio32,0x,115200n81 console=ttyS2,115200
> >
> > Please make sure the serial device info (including MMIO or I/O address and
> > the device name) matches your platform in above settings.
> >
> > I guess character set is not an issue here since Linux only outputs basic
> > ASCII codes.
> >
> > Thanks,
> >
> > - ben
> >
> > > From: Dhanasekar Jaganathan [mailto:jdhanasekar...@gmail.com]
> > > Sent: Tuesday, July 17, 2018 9:32 PM
> > > To: You, Benjamin
> > > Cc: Desimone, Nathaniel L ;
> > > edk2-devel@lists.01.org
> > > Subject: Re: [edk2] Reg: Intel Rangley Support in EDK
> > >
> > > Hi Nate, Ben,
> > >
> > > After changing Windows -> Translation = CP437 in Putty, I can able to
> > > see proper Shell and BIOS setup.
> > > After Grub, I am not seeing OS installation Process. I have changed
> > > Kernal Parameters too.
> > >
> > > May Linux Server Installation(via serial) use different character setting
> > > or baud rate?.
> > >
> > > Thanks,
> > > Dhanasekar
> > >
> > > On Mon, Jul 16, 2018 at 10:58 AM, Dhanasekar Jaganathan
> > > wrote:
> > > Hi Nate/ Ben,
> > >
> > > Thanks for the info.
> > >
> > > My host is Ubuntu system an
Re: [edk2] Reg: Intel Rangley Support in EDK
Hi, Dhanasekar,
I see "console=tty0 console=ttyUSB0,115200n8" in your configuration.
You might want to check if "ttyUSB0" matches what Linux kernel denotes
your serial port.
I am not expert in Linux kernel so not exactly sure how to debug this. A
possible way may be trying to enable Linux serial output on a known good
BIOS with your board (if there is such a BIOS) first.
Thanks,
- ben
> From: Dhanasekar Jaganathan [mailto:jdhanasekar...@gmail.com]
> Sent: Wednesday, July 18, 2018 3:06 PM
> To: You, Benjamin
> Cc: Desimone, Nathaniel L ;
> edk2-devel@lists.01.org
> Subject: Re: [edk2] Reg: Intel Rangley Support in EDK
>
> Hi Ben,
>
> I have shared my grub.cfg below,
>
> if loadfont /boot/grub/font.pf2 ; then
> set gfxmode=auto
> insmod efi_gop
> insmod efi_uga
> insmod gfxterm
> terminal_output gfxterm
> fi
>
> set menu_color_normal=white/black
> set menu_color_highlight=black/light-gray
>
> set timeout=5
> menuentry "Install Ubuntu Server" {
> set gfxpayload=keep
> #DJ linux /casper/vmlinuz boot=casper quiet ---
> linux /casper/vmlinuz file=/cdrom/preseed/ubuntu-server.seed
> vga=normal console=tty0 console=ttyUSB0,115200n8 ---
> initrd /casper/initrd.gz
> }
> menuentry "OEM install (for manufacturers)" {
> set gfxpayload=keep
> linux /casper/vmlinuz boot=casper only-ubiquity quiet splash
> oem-config/enable=true ---
> initrd /casper/initrd.gz
> }
> menuentry "Check disc for defects" {
> set gfxpayload=keep
> linux /casper/vmlinuz boot=casper integrity-check quiet splash ---
> initrd /casper/initrd.gz
> }
>
> Thanks,
> Dhanasekar
>
> On Wed, Jul 18, 2018 at 11:28 AM, You, Benjamin
> wrote:
> Hi, Dhanasekar,
>
> Linux boot parameters allow specifying serial baudrate. An example would be:
> earlycon=uart8250,mmio32,0x,115200n81 console=ttyS2,115200
>
> Please make sure the serial device info (including MMIO or I/O address and
> the device name) matches your platform in above settings.
>
> I guess character set is not an issue here since Linux only outputs basic
> ASCII codes.
>
> Thanks,
>
> - ben
>
> > From: Dhanasekar Jaganathan [mailto:jdhanasekar...@gmail.com]
> > Sent: Tuesday, July 17, 2018 9:32 PM
> > To: You, Benjamin
> > Cc: Desimone, Nathaniel L ;
> > edk2-devel@lists.01.org
> > Subject: Re: [edk2] Reg: Intel Rangley Support in EDK
> >
> > Hi Nate, Ben,
> >
> > After changing Windows -> Translation = CP437 in Putty, I can able to see
> > proper Shell and BIOS setup.
> > After Grub, I am not seeing OS installation Process. I have changed Kernal
> > Parameters too.
> >
> > May Linux Server Installation(via serial) use different character setting
> > or baud rate?.
> >
> > Thanks,
> > Dhanasekar
> >
> > On Mon, Jul 16, 2018 at 10:58 AM, Dhanasekar Jaganathan
> > wrote:
> > Hi Nate/ Ben,
> >
> > Thanks for the info.
> >
> > My host is Ubuntu system and I am using "minicom" for serial messages.
> > I will use putty with the values you mentioned.
> > I have been trying with different Kernel parameters (in grub.cfg) while
> > installing Ubuntu Server OS.
> >
> > I will update the result.
> >
> > Thanks,
> > Dhanasekar
> >
> > On Sat, Jul 14, 2018 at 10:48 AM, You, Benjamin
> > wrote:
> > Hi Dhanasekar,
> >
> > The Coreboot UEFI Payload does support serial and terminal. As Nate said
> > below, there may be some configuration issue causing the display not
> > correctly
> > formatted through serial terminal.
> >
> > I also agree with Nate that since your board does not have a VGA
> > connection,
> > you might have to configure Ubuntu to use serial console to monitor the
> > boot
> > process.
> >
> > Thanks,
> >
> > - ben
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > > Desimone, Nathaniel L
> > > Sent: Saturday, July 14, 2018 8:51 AM
> > > To: Dhanasekar Jaganathan
> > > Cc: edk2-devel@lists.01.org
> > > Subject: Re: [edk2] Reg: Intel Rangley Support in EDK
> > >
> > > Hi Dhanasekar,
> > >
> > > I don't know very much about coreboot or the coreboot UEFI payload, so I
> > > won't be able to help you much with that. From what you mention in your
> > > m
Re: [edk2] Reg: Intel Rangley Support in EDK
Hi, Dhanasekar, Linux boot parameters allow specifying serial baudrate. An example would be: earlycon=uart8250,mmio32,0x,115200n81 console=ttyS2,115200 Please make sure the serial device info (including MMIO or I/O address and the device name) matches your platform in above settings. I guess character set is not an issue here since Linux only outputs basic ASCII codes. Thanks, - ben > From: Dhanasekar Jaganathan [mailto:jdhanasekar...@gmail.com] > Sent: Tuesday, July 17, 2018 9:32 PM > To: You, Benjamin > Cc: Desimone, Nathaniel L ; > edk2-devel@lists.01.org > Subject: Re: [edk2] Reg: Intel Rangley Support in EDK > > Hi Nate, Ben, > > After changing Windows -> Translation = CP437 in Putty, I can able to see > proper Shell and BIOS setup. > After Grub, I am not seeing OS installation Process. I have changed Kernal > Parameters too. > > May Linux Server Installation(via serial) use different character setting or > baud rate?. > > Thanks, > Dhanasekar > > On Mon, Jul 16, 2018 at 10:58 AM, Dhanasekar Jaganathan > wrote: > Hi Nate/ Ben, > > Thanks for the info. > > My host is Ubuntu system and I am using "minicom" for serial messages. > I will use putty with the values you mentioned. > I have been trying with different Kernel parameters (in grub.cfg) while > installing Ubuntu Server OS. > > I will update the result. > > Thanks, > Dhanasekar > > On Sat, Jul 14, 2018 at 10:48 AM, You, Benjamin > wrote: > Hi Dhanasekar, > > The Coreboot UEFI Payload does support serial and terminal. As Nate said > below, there may be some configuration issue causing the display not correctly > formatted through serial terminal. > > I also agree with Nate that since your board does not have a VGA connection, > you might have to configure Ubuntu to use serial console to monitor the boot > process. > > Thanks, > > - ben > > > -Original Message- > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > > Desimone, Nathaniel L > > Sent: Saturday, July 14, 2018 8:51 AM > > To: Dhanasekar Jaganathan > > Cc: edk2-devel@lists.01.org > > Subject: Re: [edk2] Reg: Intel Rangley Support in EDK > > > > Hi Dhanasekar, > > > > I don't know very much about coreboot or the coreboot UEFI payload, so I > > won't be able to help you much with that. From what you mention in your > > message it sounds like either the coreboot UEFI payload does not include the > > TerminalDxe driver, there is a configuration issue with it. MinPlatformPkg > > is a > > pure EDK2 only implementation that does not have any coreboot dependencies, > > but it does not support Rangley at the moment. > > > > With regard to the setup menu graphical corruption, the setup menu uses the > > CP437 character set, since the setup menu is often displayed using VGA text > > mode, whereas most current terminal emulators assume UTF-8 encoding. To > > make it render properly, use PuTTY and in the connection configuration under > > Windows -> Translation change the remote character set to CP437. > > > > I suspect there are kernel parameters you will need to pass to make Ubuntu > > use > > the serial port as the terminal, I suggest looking at Ubuntu documentation > > or > > message boards. > > > > Thanks, > > > > Nate > > > > On 7/12/18, 10:21 PM, "edk2-devel on behalf of Dhanasekar Jaganathan" > > > > wrote: > > > > Hi Nate, > > > > Thanks for the info. I will try this. > > > > My Rangley platform has no onboard or offboard vga support. Com Port / > > Serial > > console is used for display and communication. > > I am booting the platform by coreboot with UEFI payload. I am trying to > > install > > Ubuntu server OS. > > > > When I boot into Shell, I am not seeing actually shell (graphics are not > > good) and > > keystroke are working properly. > > When I boot into EDK Setup, I am not getting proper setup page (graphics are > > not good) and keystroke are not working. > > > > When I try to boot Ubuntu Server, I am getting below error, > > > > "error: no suitable video mode found. > > Booting in blind mode" > > > > It seems I am missing some video/graphics settings in UEFI payload. If you > > know > > the fix, Please provide me. > > > > Thanks, > > Dhanasekar > > > > > > > > On Fri, Jul 13, 2018 at 7:14 AM, Desimone, Nathaniel L > > wrote: > > Hi Dhan
Re: [edk2] Reg: Intel Rangley Support in EDK
Hi Dhanasekar, The Coreboot UEFI Payload does support serial and terminal. As Nate said below, there may be some configuration issue causing the display not correctly formatted through serial terminal. I also agree with Nate that since your board does not have a VGA connection, you might have to configure Ubuntu to use serial console to monitor the boot process. Thanks, - ben > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Desimone, Nathaniel L > Sent: Saturday, July 14, 2018 8:51 AM > To: Dhanasekar Jaganathan > Cc: edk2-devel@lists.01.org > Subject: Re: [edk2] Reg: Intel Rangley Support in EDK > > Hi Dhanasekar, > > I don't know very much about coreboot or the coreboot UEFI payload, so I > won't be able to help you much with that. From what you mention in your > message it sounds like either the coreboot UEFI payload does not include the > TerminalDxe driver, there is a configuration issue with it. MinPlatformPkg is > a > pure EDK2 only implementation that does not have any coreboot dependencies, > but it does not support Rangley at the moment. > > With regard to the setup menu graphical corruption, the setup menu uses the > CP437 character set, since the setup menu is often displayed using VGA text > mode, whereas most current terminal emulators assume UTF-8 encoding. To > make it render properly, use PuTTY and in the connection configuration under > Windows -> Translation change the remote character set to CP437. > > I suspect there are kernel parameters you will need to pass to make Ubuntu use > the serial port as the terminal, I suggest looking at Ubuntu documentation or > message boards. > > Thanks, > > Nate > > On 7/12/18, 10:21 PM, "edk2-devel on behalf of Dhanasekar Jaganathan" > > wrote: > > Hi Nate, > > Thanks for the info. I will try this. > > My Rangley platform has no onboard or offboard vga support. Com Port / Serial > console is used for display and communication. > I am booting the platform by coreboot with UEFI payload. I am trying to > install > Ubuntu server OS. > > When I boot into Shell, I am not seeing actually shell (graphics are not > good) and > keystroke are working properly. > When I boot into EDK Setup, I am not getting proper setup page (graphics are > not good) and keystroke are not working. > > When I try to boot Ubuntu Server, I am getting below error, > > "error: no suitable video mode found. > Booting in blind mode" > > It seems I am missing some video/graphics settings in UEFI payload. If you > know > the fix, Please provide me. > > Thanks, > Dhanasekar > > > > On Fri, Jul 13, 2018 at 7:14 AM, Desimone, Nathaniel L > wrote: > Hi Dhanasekar, > > There is nothing pre-built and off-the-shelf ready today. But we do have a > generalized infrastructure for open source Intel UEFI platforms called > MinPlatformPkg. Please see the following: > > https://github.com/tianocore/edk2-platforms/tree/devel- > MinPlatform/Platform/Intel > > Notice that MinPlatformPkg requires a *OpenBoardPkg that supports the > desired platform. To my knowledge no one at Intel has looked at implementing > a RangleyOpenBoardPkg thus far. The focus has been on recently released > platforms, Rangley is 4 years old at this point. If you are so inclined, you > are > welcome to try implementing a RangleyOpenBoardPkg. I would recommend > using KabylakeOpenBoardPkg as a starting point. > > Thanks, > Nate > > On 7/11/18, 8:52 PM, "edk2-devel on behalf of Dhanasekar Jaganathan" devel-boun...@lists.01.org on behalf of jdhanasekar...@gmail.com> wrote: > > Hi, > > I have booted Intel Rangley / MohonPeak platform in coreboot with Intel > FSP. > I am unable to install UEFI OS in coreboot (sometime). > > EDK bios will install both UEFI and Legacy OS. > Does Open EDK supports Intel Rangley platform?. > Is code base available for Intel Rangely platform? > > > > Thanks, > Dhanasekar > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel > > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 07/37] CorebootPayloadPkg: Removing ipf from edk2.
Reviewed-by: Benjamin You > -Original Message- > From: Chen, Chen A > Sent: Wednesday, June 13, 2018 11:44 AM > To: edk2-devel@lists.01.org > Cc: Chen, Chen A ; Ma, Maurice > ; Agyeman, Prince ; You, > Benjamin ; Kinney, Michael D > > Subject: [PATCH 07/37] CorebootPayloadPkg: Removing ipf from edk2. > > Removing rules for Ipf sources file: > * Remove the source file which path with "ipf" and also listed in > [Sources.IPF] section of INF file. > * Remove the source file which listed in [Components.IPF] section > of DSC file and not listed in any other [Components] section. > * Remove the embedded Ipf code for MDE_CPU_IPF. > > Removing rules for Inf file: > * Remove IPF from VALID_ARCHITECTURES comments. > * Remove DXE_SAL_DRIVER from LIBRARY_CLASS in [Defines] section. > * Remove the INF which only listed in [Components.IPF] section in DSC. > * Remove statements from [BuildOptions] that provide IPF specific flags. > * Remove any IPF sepcific sections. > > Removing rules for Dec file: > * Remove [Includes.IPF] section from Dec. > > Removing rules for Dsc file: > * Remove IPF from SUPPORTED_ARCHITECTURES in [Defines] section of DSC. > * Remove any IPF specific sections. > * Remove statements from [BuildOptions] that provide IPF specific flags. > > Cc: Maurice Ma > Cc: Prince Agyeman > Cc: Benjamin You > Cc: Michael D Kinney > Signed-off-by: chenc2 > Contributed-under: TianoCore Contribution Agreement 1.1 > --- > CorebootPayloadPkg/FbGop/FbGop.inf | 2 +- > CorebootPayloadPkg/Library/AcpiTimerLib/AcpiTimerLib.inf | 4 ++-- > CorebootPayloadPkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf | 2 +- > CorebootPayloadPkg/Library/ResetSystemLib/ResetSystemLib.inf | 2 +- > 4 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/CorebootPayloadPkg/FbGop/FbGop.inf > b/CorebootPayloadPkg/FbGop/FbGop.inf > index 0d97387679..b95add240b 100644 > --- a/CorebootPayloadPkg/FbGop/FbGop.inf > +++ b/CorebootPayloadPkg/FbGop/FbGop.inf > @@ -29,7 +29,7 @@ > # > # The following information is for reference only and not required by the > build > tools. > # > -# VALID_ARCHITECTURES = IA32 X64 IPF EBC > +# VALID_ARCHITECTURES = IA32 X64 EBC > # > # DRIVER_BINDING= gBiosVideoDriverBinding > # COMPONENT_NAME= gBiosVideoComponentName > diff --git a/CorebootPayloadPkg/Library/AcpiTimerLib/AcpiTimerLib.inf > b/CorebootPayloadPkg/Library/AcpiTimerLib/AcpiTimerLib.inf > index 2bff61094a..4c5684cb09 100644 > --- a/CorebootPayloadPkg/Library/AcpiTimerLib/AcpiTimerLib.inf > +++ b/CorebootPayloadPkg/Library/AcpiTimerLib/AcpiTimerLib.inf > @@ -25,7 +25,7 @@ > # > # The following information is for reference only and not required by the > build > tools. > # > -# VALID_ARCHITECTURES = IA32 X64 IPF EBC > +# VALID_ARCHITECTURES = IA32 X64 EBC > # > > [Sources] > @@ -43,4 +43,4 @@ >DebugLib > > [Guids] > - gUefiAcpiBoardInfoGuid > \ No newline at end of file > + gUefiAcpiBoardInfoGuid > diff --git a/CorebootPayloadPkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf > b/CorebootPayloadPkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf > index 15ffb45f84..7fc1326a70 100644 > --- a/CorebootPayloadPkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf > +++ b/CorebootPayloadPkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf > @@ -27,7 +27,7 @@ > # The following information is for reference only and not required by the > build > # tools. > # > -# VALID_ARCHITECTURES = IA32 X64 IPF EBC > +# VALID_ARCHITECTURES = IA32 X64 EBC > # > > [Sources] > diff --git a/CorebootPayloadPkg/Library/ResetSystemLib/ResetSystemLib.inf > b/CorebootPayloadPkg/Library/ResetSystemLib/ResetSystemLib.inf > index 1af96c6e23..9e025ecee2 100644 > --- a/CorebootPayloadPkg/Library/ResetSystemLib/ResetSystemLib.inf > +++ b/CorebootPayloadPkg/Library/ResetSystemLib/ResetSystemLib.inf > @@ -23,7 +23,7 @@ > # > # The following information is for reference only and not required by the > build > tools. > # > -# VALID_ARCHITECTURES = IA32 X64 IPF > +# VALID_ARCHITECTURES = IA32 X64 > # > > [Sources] > -- > 2.16.2.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 06/37] CorebootModulePkg: Removing ipf from edk2.
Reviewed-by: Benjamin You > -Original Message- > From: Chen, Chen A > Sent: Wednesday, June 13, 2018 11:43 AM > To: edk2-devel@lists.01.org > Cc: Chen, Chen A ; Ma, Maurice > ; Agyeman, Prince ; You, > Benjamin ; Kinney, Michael D > > Subject: [PATCH 06/37] CorebootModulePkg: Removing ipf from edk2. > > Removing rules for Ipf sources file: > * Remove the source file which path with "ipf" and also listed in > [Sources.IPF] section of INF file. > * Remove the source file which listed in [Components.IPF] section > of DSC file and not listed in any other [Components] section. > * Remove the embedded Ipf code for MDE_CPU_IPF. > > Removing rules for Inf file: > * Remove IPF from VALID_ARCHITECTURES comments. > * Remove DXE_SAL_DRIVER from LIBRARY_CLASS in [Defines] section. > * Remove the INF which only listed in [Components.IPF] section in DSC. > * Remove statements from [BuildOptions] that provide IPF specific flags. > * Remove any IPF sepcific sections. > > Removing rules for Dec file: > * Remove [Includes.IPF] section from Dec. > > Removing rules for Dsc file: > * Remove IPF from SUPPORTED_ARCHITECTURES in [Defines] section of DSC. > * Remove any IPF specific sections. > * Remove statements from [BuildOptions] that provide IPF specific flags. > > Cc: Maurice Ma > Cc: Prince Agyeman > Cc: Benjamin You > Cc: Michael D Kinney > Signed-off-by: chenc2 > Contributed-under: TianoCore Contribution Agreement 1.1 > --- > CorebootModulePkg/CbSupportDxe/CbSupportDxe.inf | 2 +- > CorebootModulePkg/SataControllerDxe/SataControllerDxe.inf | 2 +- > CorebootModulePkg/SecCore/SecCore.inf | 2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/CorebootModulePkg/CbSupportDxe/CbSupportDxe.inf > b/CorebootModulePkg/CbSupportDxe/CbSupportDxe.inf > index 15b0dac774..63f6ab35db 100644 > --- a/CorebootModulePkg/CbSupportDxe/CbSupportDxe.inf > +++ b/CorebootModulePkg/CbSupportDxe/CbSupportDxe.inf > @@ -25,7 +25,7 @@ > # > # The following information is for reference only and not required by the > build > tools. > # > -# VALID_ARCHITECTURES = IA32 X64 IPF EBC > +# VALID_ARCHITECTURES = IA32 X64 EBC > # > > [Sources] > diff --git a/CorebootModulePkg/SataControllerDxe/SataControllerDxe.inf > b/CorebootModulePkg/SataControllerDxe/SataControllerDxe.inf > index b0ed2f4db5..b40f0d2668 100644 > --- a/CorebootModulePkg/SataControllerDxe/SataControllerDxe.inf > +++ b/CorebootModulePkg/SataControllerDxe/SataControllerDxe.inf > @@ -24,7 +24,7 @@ > # > # The following information is for reference only and not required by the > build > tools. > # > -# VALID_ARCHITECTURES = IA32 X64 IPF EBC > +# VALID_ARCHITECTURES = IA32 X64 EBC > # > > [Sources] > diff --git a/CorebootModulePkg/SecCore/SecCore.inf > b/CorebootModulePkg/SecCore/SecCore.inf > index 3eb8aa029b..431f235665 100644 > --- a/CorebootModulePkg/SecCore/SecCore.inf > +++ b/CorebootModulePkg/SecCore/SecCore.inf > @@ -24,7 +24,7 @@ > # > # The following information is for reference only and not required by the > build > tools. > # > -# VALID_ARCHITECTURES = IA32 X64 IPF EBC > +# VALID_ARCHITECTURES = IA32 X64 EBC > # > > [Sources] > -- > 2.16.2.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 2/7] CorebootPayload/PlatformBDS: Impl PlatformBootManagerUnableToBoot
Reviewed-by: Benjamin You
> -Original Message-
> From: Ni, Ruiyu
> Sent: Tuesday, July 3, 2018 2:38 PM
> To: edk2-devel@lists.01.org
> Cc: Ma, Maurice ; Agyeman, Prince
> ; You, Benjamin
> Subject: [PATCH v3 2/7] CorebootPayload/PlatformBDS: Impl
> PlatformBootManagerUnableToBoot
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni
> Cc: Maurice Ma
> Cc: Prince Agyeman
> Cc: Benjamin You
> ---
> .../PlatformBootManagerLib/PlatformBootManager.c | 19
> ++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
>
> diff --git
> a/CorebootPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManage
> r.c
> b/CorebootPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManage
> r.c
> index 7e92441da1..368e89d586 100644
> ---
> a/CorebootPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManage
> r.c
> +++
> b/CorebootPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManage
> r.c
> @@ -2,7 +2,7 @@
>This file include all platform action which can be customized
>by IBV/OEM.
>
> -Copyright (c) 2015 - 2017, Intel Corporation. All rights reserved.
> +Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD
> License
> which accompanies this distribution. The full text of the license may be
> found
> at
> @@ -252,3 +252,20 @@ PlatformBootManagerWaitCallback (
> {
>return;
> }
> +
> +/**
> + The function is called when no boot option could be launched,
> + including platform recovery options and options pointing to applications
> + built into firmware volumes.
> +
> + If this function returns, BDS attempts to enter an infinite loop.
> +**/
> +VOID
> +EFIAPI
> +PlatformBootManagerUnableToBoot (
> + VOID
> + )
> +{
> + return;
> +}
> +
> --
> 2.16.1.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] CorebootModulePkg/CbSupportDxe: Remove SCI_EN setting
Hi Matt,
Thanks. I've submitted patch v2 based on your feedbacks.
- ben
> From: Matt Delco [mailto:de...@google.com]
> Sent: Friday, June 8, 2018 1:07 AM
> To: Ma, Maurice
> Cc: You, Benjamin ; Agyeman, Prince
> ; edk2-devel@lists.01.org
> Subject: Re: [PATCH] CorebootModulePkg/CbSupportDxe: Remove SCI_EN setting
>
> Thanks for working on this. I did a quick test to confirm that things still
> work okay. The code change looks fine though there's some optional
> optimizations to consider:
>
> The new code added to CbParseFadtInfo() is mostly to add debug checks but I
> think it'll still result in a IO port access in a release build so it might
> be worthwhile to make the entire code block specific to a debug build
> (possibly by sticking the code within a "#if !defined(MDEPKG_NDEBUG)" block,
> though I don't see any other such cases in edk2 so I suspect this isn't an
> ideal suggestion). Regarding "Pm1CntLen" It looks like the "if (==2) {} else
> if (==4) {} else {}" could be simplified to "if (==4) {} else {}".
>
> In CbDxeEntryPoint() the "Find the acpi board information guid hob" code
> block can probably be deleted. Its only remaining use is the debug log
> regarding the value of PmCtrlReg, which I suspect isn't that valuable given
> the other deletions. This would also allow the removal of the "mPmCtrlReg"
> variable at file scope.
>
> On Thu, Jun 7, 2018 at 8:40 AM, Ma, Maurice wrote:
> It looks good to me.
> Reviewed-by: Maurice Ma
>
>
> > -Original Message-
> > From: You, Benjamin
> > Sent: Thursday, June 7, 2018 1:19
> > To: edk2-devel@lists.01.org
> > Cc: Ma, Maurice ; Agyeman, Prince
> > ; de...@google.com
> > Subject: [PATCH] CorebootModulePkg/CbSupportDxe: Remove SCI_EN setting
> >
> > Current implemenation sets PM1_CNT.SCI_EN bit at ReadyToBoot event.
> > However, this should not be done because this causes OS to skip triggering
> > FADT.SMI_CMD, which leads to the functions implemented in the SMI handler
> > being omitted.
> >
> > This issue was identified by Matt Delco .
> >
> > The fix does the following:
> > - The SCI_EN bit setting is removed from CbSupportDxe driver.
> > - Some additional checks are added in CbParseFadtInfo() in CbParseLib.c to
> > output some error message and ASSERT (FALSE) if ALL of the following
> > conditions are met:
> > 1) HARDWARE_REDUCED_ACPI is not set;
> > 2) SMI_CMD field is zero;
> > 3) SCI_EN bit is zero;
> > which indicates the ACPI enabling status is inconsistent: SCI is not
> > enabled but the ACPI table does not provide a means to enable it through
> > FADT->SMI_CMD. This may cause issues in OS.
> >
> > Cc: Maurice Ma
> > Cc: Prince Agyeman
> > Cc: Matt Delco
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Benjamin You
> > ---
> > CorebootModulePkg/CbSupportDxe/CbSupportDxe.c | 39
> > --
> > CorebootModulePkg/CbSupportDxe/CbSupportDxe.inf| 1 -
> > CorebootModulePkg/Library/CbParseLib/CbParseLib.c | 28
> > .../Library/CbParseLib/CbParseLib.inf | 3 +-
> > 4 files changed, 30 insertions(+), 41 deletions(-)
> >
> > diff --git a/CorebootModulePkg/CbSupportDxe/CbSupportDxe.c
> > b/CorebootModulePkg/CbSupportDxe/CbSupportDxe.c
> > index c526c9e871..b41c0885f7 100755
> > --- a/CorebootModulePkg/CbSupportDxe/CbSupportDxe.c
> > +++ b/CorebootModulePkg/CbSupportDxe/CbSupportDxe.c
> > @@ -86,31 +86,6 @@ CbReserveResourceInGcd (
> >return Status;
> > }
> >
> > -/**
> > - Notification function of EVT_GROUP_READY_TO_BOOT event group.
> > -
> > - This is a notification function registered on EVT_GROUP_READY_TO_BOOT
> > event group.
> > - When the Boot Manager is about to load and execute a boot option, it
> > reclaims variable
> > - storage if free size is below the threshold.
> > -
> > - @param EventEvent whose notification function is being invoked.
> > - @param Context Pointer to the notification function's context.
> > -
> > -**/
> > -VOID
> > -EFIAPI
> > -OnReadyToBoot (
> > - IN EFI_EVENT Event,
> > - IN VOID *Context
> > - )
> > -{
> > - //
> > - // Enable SCI
> > - //
> > - IoOr16 (mPmCtrlReg, BIT0);
> > -
> > - DEBUG ((EFI_D_ERROR, "Enable SCI bit at 0x%lx before boot\n",
> >
Re: [edk2] [PATCH] CorebootModulePkg/CbSupportDxe: Enable ACPI via cmd register
Hi Matt, Sure. I will prepare a patch for this. Thanks, - ben > From: Matt Delco [mailto:de...@google.com] > Sent: Friday, June 1, 2018 10:13 AM > To: You, Benjamin > Cc: edk2-devel@lists.01.org; Ma, Maurice ; Agyeman, > Prince > Subject: Re: [PATCH] CorebootModulePkg/CbSupportDxe: Enable ACPI via cmd > register > > Normally I would provide a patch, but I'm not sure I'd add correctly add the > checks that were proposed for CbParseFadtInfo(). I'd also have to go through > an company-internal review process regarding edk2's contributor license > agreement (I incorrectly assumed this had already been done when I provided > the initial patch). This review might require that I place an apache2 > license and company copyright on patch contributions, and I'd feel really odd > about providing a patch that added a license but otherwise merely deleted the > lines that modify the register. So, for this particular issue it might be > cleaner, faster, and more straightforward if I didn't provide a patch. > > > On Thu, May 31, 2018 at 5:44 PM, You, Benjamin > > wrote: > > Hi, Matt, > > > > Thanks. Would you like to provide an updated patch? > > > > Thanks, > > > > - ben > > > > > From: Matt Delco [mailto:de...@google.com] > > > Sent: Friday, June 1, 2018 5:55 AM > > > To: You, Benjamin > > > Cc: edk2-devel@lists.01.org; Ma, Maurice ; Agyeman, > > > Prince > > > Subject: Re: [PATCH] CorebootModulePkg/CbSupportDxe: Enable ACPI via cmd > > > register > > > > > > Hi, > > > > > > I commented out the body of OnReadyToBoot() and the result is as expected > > > (i.e., ACPI events are still received, presumably because the OS enabled > > > ACPI for itself). > > > > > > > On Wed, May 30, 2018 at 7:52 PM, You, Benjamin > > > > wrote: > > > > Hi, Matt, > > > > > > > > The original SCI_EN setting code was added to cover some early buggy > > > > firmware implementation that fails to enable SMM, and/or fails to fill > > > > FADT > > > > properly, and still needs an SCI_EN to transition to ACPI mode. > > > > > > > > However, as you pointed out, setting it in Payload is not the correct > > > > way > > > > to address the issue, which also has some side effects as in your > > > > case. > > > > Instead, Payload should output some reminding message to developer to > > > > fix > > > > the firmware that runs before Payload. > > > > > > > > Thanks, > > > > > > > > - ben > > > > > > > > > From: Matt Delco [mailto:de...@google.com] > > > > > Sent: Wednesday, May 30, 2018 4:40 PM > > > > > To: You, Benjamin > > > > > Cc: edk2-devel@lists.01.org; Ma, Maurice ; > > > > > Agyeman, Prince > > > > > Subject: Re: [PATCH] CorebootModulePkg/CbSupportDxe: Enable ACPI via > > > > > cmd register > > > > > > > > > > Hi, thanks for taking a look. I agree that this seems like the OS's > > > > > responsibility to enable ACPI and I was tempted to just remove the > > > > > setting of SCI_EN. However, I figured that there was likely a reason > > > > > that someone bothered to add the function in the first place so I > > > > > went with what seemed like the more conservative fix. I can try > > > > > testing the removal of SCI_EN though I'll likely be at a remote > > > > > office for the next 2 days so it may be 3 or more days before I can > > > > > update the flash on the platform to perform the experiment. > > > > > > > > > > On Wed, May 30, 2018 at 1:27 AM, You, Benjamin > > > > > wrote: > > > > > Hi Matt, > > > > > > > > > > This is indeed a bug. The Payload should not set the SCI_EN bit. > > > > > > > > > > However, the Payload should not trigger an SMI either. It is OS's > > > > > responsibility to enable ACPI by following FADT's instruction to > > > > > write > > > > > some value to some port. > > > > > > > > > > We think a better fix might be: > > > > > 1) Remove the SCI_EN setting code in ReadyToBoot event handler, > > > > > 2) Add some checking in CbParseFadtInfo() in CbParseLib.c to o
Re: [edk2] [PATCH] CorebootModulePkg/CbSupportDxe: Enable ACPI via cmd register
Hi, Matt,
Thanks. Would you like to provide an updated patch?
Thanks,
- ben
> From: Matt Delco [mailto:de...@google.com]
> Sent: Friday, June 1, 2018 5:55 AM
> To: You, Benjamin
> Cc: edk2-devel@lists.01.org; Ma, Maurice ; Agyeman,
> Prince
> Subject: Re: [PATCH] CorebootModulePkg/CbSupportDxe: Enable ACPI via cmd
> register
>
> Hi,
>
> I commented out the body of OnReadyToBoot() and the result is as expected
> (i.e., ACPI events are still received, presumably because the OS enabled ACPI
> for itself).
>
> > On Wed, May 30, 2018 at 7:52 PM, You, Benjamin
> > wrote:
> > Hi, Matt,
> >
> > The original SCI_EN setting code was added to cover some early buggy
> > firmware implementation that fails to enable SMM, and/or fails to fill FADT
> > properly, and still needs an SCI_EN to transition to ACPI mode.
> >
> > However, as you pointed out, setting it in Payload is not the correct way
> > to address the issue, which also has some side effects as in your case.
> > Instead, Payload should output some reminding message to developer to fix
> > the firmware that runs before Payload.
> >
> > Thanks,
> >
> > - ben
> >
> > > From: Matt Delco [mailto:de...@google.com]
> > > Sent: Wednesday, May 30, 2018 4:40 PM
> > > To: You, Benjamin
> > > Cc: edk2-devel@lists.01.org; Ma, Maurice ; Agyeman,
> > > Prince
> > > Subject: Re: [PATCH] CorebootModulePkg/CbSupportDxe: Enable ACPI via cmd
> > > register
> > >
> > > Hi, thanks for taking a look. I agree that this seems like the OS's
> > > responsibility to enable ACPI and I was tempted to just remove the
> > > setting of SCI_EN. However, I figured that there was likely a reason
> > > that someone bothered to add the function in the first place so I went
> > > with what seemed like the more conservative fix. I can try testing the
> > > removal of SCI_EN though I'll likely be at a remote office for the next 2
> > > days so it may be 3 or more days before I can update the flash on the
> > > platform to perform the experiment.
> > >
> > > On Wed, May 30, 2018 at 1:27 AM, You, Benjamin
> > > wrote:
> > > Hi Matt,
> > >
> > > This is indeed a bug. The Payload should not set the SCI_EN bit.
> > >
> > > However, the Payload should not trigger an SMI either. It is OS's
> > > responsibility to enable ACPI by following FADT's instruction to write
> > > some value to some port.
> > >
> > > We think a better fix might be:
> > > 1) Remove the SCI_EN setting code in ReadyToBoot event handler,
> > > 2) Add some checking in CbParseFadtInfo() in CbParseLib.c to output some
> > >warning message and ASSERT (FALSE) if ALL of the following conditions
> > >are met:
> > >- HARDWARE_REDUCED_ACPI is not set
> > >- SMI_CMD field is zero (indicating no need to switch mode, hence
> > > the platform being in ACPI mode)
> > >- SCI_EN bit is zero (indicating not in ACPI mode)
> > >
> > > Item 2) above is to remind the developer that in this case, there may be
> > > a
> > > bug in the firmware that runs before the Payload.
> > >
> > > Could you please try on your platform to completely remove the SCI_EN
> > > setting code in ReadToBoot event handler, and see if it works properly
> > > (e.g., ACPI events delivered correctly)?
> > >
> > > Thanks,
> > >
> > > - ben
> > >
> > > > -Original Message-
> > > > From: Matt Delco [mailto:de...@google.com]
> > > > Sent: Monday, May 28, 2018 5:57 AM
> > > > To: edk2-devel@lists.01.org
> > > > Cc: Ma, Maurice ; Agyeman, Prince
> > > > ; You, Benjamin
> > > > Subject: [PATCH] CorebootModulePkg/CbSupportDxe: Enable ACPI via cmd
> > > > register
> > > >
> > > > The existing code sets the SCI_EN bit directly, which is a violation
> > > > of the ACPI spec ("It is the responsibility of the hardware to set or
> > > > reset this bit. OSPM always preserves this bit position"). The proper
> > > > way to cause this bit to bit set is to reference the FADT table and
> > > > write the value of ACPI_ENABLE to SMI_CMD. The SMI will in turn set
> > > > the SCI_EN bit.
> > > >
> > > > Prior to this change ACPI events were not being delivered because
> > > > ACPI was not pro
Re: [edk2] [PATCH] CorebootModulePkg/CbSupportDxe: Enable ACPI via cmd register
Hi, Matt,
The original SCI_EN setting code was added to cover some early buggy
firmware implementation that fails to enable SMM, and/or fails to fill FADT
properly, and still needs an SCI_EN to transition to ACPI mode.
However, as you pointed out, setting it in Payload is not the correct way
to address the issue, which also has some side effects as in your case.
Instead, Payload should output some reminding message to developer to fix
the firmware that runs before Payload.
Thanks,
- ben
> From: Matt Delco [mailto:de...@google.com]
> Sent: Wednesday, May 30, 2018 4:40 PM
> To: You, Benjamin
> Cc: edk2-devel@lists.01.org; Ma, Maurice ; Agyeman,
> Prince
> Subject: Re: [PATCH] CorebootModulePkg/CbSupportDxe: Enable ACPI via cmd
> register
>
> Hi, thanks for taking a look. I agree that this seems like the OS's
> responsibility to enable ACPI and I was tempted to just remove the setting of
> SCI_EN. However, I figured that there was likely a reason that someone
> bothered to add the function in the first place so I went with what seemed
> like the more conservative fix. I can try testing the removal of SCI_EN
> though I'll likely be at a remote office for the next 2 days so it may be 3
> or more days before I can update the flash on the platform to perform the
> experiment.
>
> On Wed, May 30, 2018 at 1:27 AM, You, Benjamin wrote:
> Hi Matt,
>
> This is indeed a bug. The Payload should not set the SCI_EN bit.
>
> However, the Payload should not trigger an SMI either. It is OS's
> responsibility to enable ACPI by following FADT's instruction to write
> some value to some port.
>
> We think a better fix might be:
> 1) Remove the SCI_EN setting code in ReadyToBoot event handler,
> 2) Add some checking in CbParseFadtInfo() in CbParseLib.c to output some
>warning message and ASSERT (FALSE) if ALL of the following conditions
>are met:
>- HARDWARE_REDUCED_ACPI is not set
>- SMI_CMD field is zero (indicating no need to switch mode, hence
> the platform being in ACPI mode)
>- SCI_EN bit is zero (indicating not in ACPI mode)
>
> Item 2) above is to remind the developer that in this case, there may be a
> bug in the firmware that runs before the Payload.
>
> Could you please try on your platform to completely remove the SCI_EN
> setting code in ReadToBoot event handler, and see if it works properly
> (e.g., ACPI events delivered correctly)?
>
> Thanks,
>
> - ben
>
> > -Original Message-----
> > From: Matt Delco [mailto:de...@google.com]
> > Sent: Monday, May 28, 2018 5:57 AM
> > To: edk2-devel@lists.01.org
> > Cc: Ma, Maurice ; Agyeman, Prince
> > ; You, Benjamin
> > Subject: [PATCH] CorebootModulePkg/CbSupportDxe: Enable ACPI via cmd
> > register
> >
> > The existing code sets the SCI_EN bit directly, which is a violation
> > of the ACPI spec ("It is the responsibility of the hardware to set or
> > reset this bit. OSPM always preserves this bit position"). The proper
> > way to cause this bit to bit set is to reference the FADT table and
> > write the value of ACPI_ENABLE to SMI_CMD. The SMI will in turn set
> > the SCI_EN bit.
> >
> > Prior to this change ACPI events were not being delivered because
> > ACPI was not properly enabled and the OS also did not attempt
> > to enable ACPI since it sees that SCI_EN is already set. After this
> > change I observed that ACPI events were now being delivered properly.
> >
> > Cc: Maurice Ma
> > Cc: Prince Agyeman
> > Cc: Benjamin You
> >
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Matt Delco
> > ---
> > CorebootModulePkg/CbSupportDxe/CbSupportDxe.c | 79 ---
> > .../CbSupportDxe/CbSupportDxe.inf | 1 +
> > 2 files changed, 68 insertions(+), 12 deletions(-)
> >
> > diff --git a/CorebootModulePkg/CbSupportDxe/CbSupportDxe.c
> > b/CorebootModulePkg/CbSupportDxe/CbSupportDxe.c
> > index c526c9e871..4c7917ff2a 100755
> > --- a/CorebootModulePkg/CbSupportDxe/CbSupportDxe.c
> > +++ b/CorebootModulePkg/CbSupportDxe/CbSupportDxe.c
> > @@ -14,7 +14,10 @@
> > **/
> > #include "CbSupportDxe.h"
> >
> > -UINTN mPmCtrlReg = 0;
> > +BOOLEAN mSmiPortFound = FALSE;
> > +UINTN mSmiCommandPort = 0;
> > +UINT8 mAcpiEnable = 0;
> > +
> > /**
> >Reserve MMIO/IO resource in GCD
> >
> > @@ -107,9 +110,63 @@ OnReadyToBoot (
> >//
> >// Enable SCI
> >//
> > - IoOr16 (mPmCtrlReg, BIT0);
> > + if (!mSmiPortFound) {
> > +
Re: [edk2] [PATCH] CorebootModulePkg/CbSupportDxe: Enable ACPI via cmd register
Hi Matt,
This is indeed a bug. The Payload should not set the SCI_EN bit.
However, the Payload should not trigger an SMI either. It is OS's
responsibility to enable ACPI by following FADT's instruction to write
some value to some port.
We think a better fix might be:
1) Remove the SCI_EN setting code in ReadyToBoot event handler,
2) Add some checking in CbParseFadtInfo() in CbParseLib.c to output some
warning message and ASSERT (FALSE) if ALL of the following conditions
are met:
- HARDWARE_REDUCED_ACPI is not set
- SMI_CMD field is zero (indicating no need to switch mode, hence
the platform being in ACPI mode)
- SCI_EN bit is zero (indicating not in ACPI mode)
Item 2) above is to remind the developer that in this case, there may be a
bug in the firmware that runs before the Payload.
Could you please try on your platform to completely remove the SCI_EN
setting code in ReadToBoot event handler, and see if it works properly
(e.g., ACPI events delivered correctly)?
Thanks,
- ben
> -Original Message-
> From: Matt Delco [mailto:de...@google.com]
> Sent: Monday, May 28, 2018 5:57 AM
> To: edk2-devel@lists.01.org
> Cc: Ma, Maurice ; Agyeman, Prince
> ; You, Benjamin
> Subject: [PATCH] CorebootModulePkg/CbSupportDxe: Enable ACPI via cmd register
>
> The existing code sets the SCI_EN bit directly, which is a violation
> of the ACPI spec ("It is the responsibility of the hardware to set or
> reset this bit. OSPM always preserves this bit position"). The proper
> way to cause this bit to bit set is to reference the FADT table and
> write the value of ACPI_ENABLE to SMI_CMD. The SMI will in turn set
> the SCI_EN bit.
>
> Prior to this change ACPI events were not being delivered because
> ACPI was not properly enabled and the OS also did not attempt
> to enable ACPI since it sees that SCI_EN is already set. After this
> change I observed that ACPI events were now being delivered properly.
>
> Cc: Maurice Ma
> Cc: Prince Agyeman
> Cc: Benjamin You
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Matt Delco
> ---
> CorebootModulePkg/CbSupportDxe/CbSupportDxe.c | 79 ---
> .../CbSupportDxe/CbSupportDxe.inf | 1 +
> 2 files changed, 68 insertions(+), 12 deletions(-)
>
> diff --git a/CorebootModulePkg/CbSupportDxe/CbSupportDxe.c
> b/CorebootModulePkg/CbSupportDxe/CbSupportDxe.c
> index c526c9e871..4c7917ff2a 100755
> --- a/CorebootModulePkg/CbSupportDxe/CbSupportDxe.c
> +++ b/CorebootModulePkg/CbSupportDxe/CbSupportDxe.c
> @@ -14,7 +14,10 @@
> **/
> #include "CbSupportDxe.h"
>
> -UINTN mPmCtrlReg = 0;
> +BOOLEAN mSmiPortFound = FALSE;
> +UINTN mSmiCommandPort = 0;
> +UINT8 mAcpiEnable = 0;
> +
> /**
>Reserve MMIO/IO resource in GCD
>
> @@ -107,9 +110,63 @@ OnReadyToBoot (
>//
>// Enable SCI
>//
> - IoOr16 (mPmCtrlReg, BIT0);
> + if (!mSmiPortFound) {
> +DEBUG ((DEBUG_ERROR, "SMI port not known so can not enable SCI\n"));
> + } else {
> +IoWrite8 (mSmiCommandPort, mAcpiEnable);
> +DEBUG ((DEBUG_ERROR, "Enable ACPI at 0x%lx with 0x%x before boot\n",
> (UINT64)mSmiCommandPort, (UINT32)mAcpiEnable));
> + }
> +}
> +
> +/**
> + Lookup port and value for enabling ACPI
> +
> + @param[in] SystemTableA pointer to the EFI System Table.
>
> - DEBUG ((EFI_D_ERROR, "Enable SCI bit at 0x%lx before boot\n",
> (UINT64)mPmCtrlReg));
> +**/
> +VOID
> +FindAcpiFadtTableInfo (
> + IN EFI_SYSTEM_TABLE *SystemTable
> + )
> +{
> + EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER *Rsdp;
> + EFI_ACPI_DESCRIPTION_HEADER *Rsdt;
> + EFI_ACPI_2_0_FIXED_ACPI_DESCRIPTION_TABLE *Fadt;
> + UINTN Index;
> + Rsdp = NULL;
> + Rsdt = NULL;
> + Fadt = NULL;
> +
> + for (Index = 0; Index < SystemTable->NumberOfTableEntries; Index++) {
> +if (CompareGuid (&(SystemTable->ConfigurationTable[Index].VendorGuid),
> &gEfiAcpi20TableGuid)) {
> + Rsdp = SystemTable->ConfigurationTable[Index].VendorTable;
> + break;
> +}
> + }
> + if (Rsdp == NULL) {
> +return;
> + }
> +
> + Rsdt = (EFI_ACPI_DESCRIPTION_HEADER *)(UINTN) Rsdp->RsdtAddress;
> + if (Rsdt == NULL || Rsdt->Signature !=
> EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_TABLE_SIGNATURE) {
> +return;
> + }
> + for (Index = sizeof (EFI_ACPI_DESCRIPTION_HEADER); Index < Rsdt->Length;
> Index = Index + sizeof (UINT32)) {
> +UINT32 Data32 = *(UINT32 *) ((UINT8 *) Rsdt + Index);
> +Fadt= (EFI_ACPI_2_0_FIXED_ACPI_DESCRIPTION_TABLE *) (UINT32
Re: [edk2] [PATCH v1] CorebootPayloadPkg: Conditionally add DebugAgentLib for DXE drivers
Reviewed-by: Benjamin You > -Original Message- > From: Alex James [mailto:theracermas...@gmail.com] > Sent: Tuesday, March 27, 2018 12:15 AM > To: edk2-devel@lists.01.org > Cc: Ma, Maurice ; Agyeman, Prince > ; You, Benjamin > Subject: [PATCH v1] CorebootPayloadPkg: Conditionally add DebugAgentLib for > DXE drivers > > To fix building with SOURCE_DEBUG_ENABLE, add DebugAgentLib for > LibraryClasses.common.DXE_DRIVER, as is done with Vlv2TbltDevicePkg. > > Cc: Maurice Ma > Cc: Prince Agyeman > Cc: Benjamin You > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Alex James > --- > CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc| 3 +++ > CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc | 3 +++ > 2 files changed, 6 insertions(+) > > diff --git a/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc > b/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc > index ace1bc0a37..b6cdb697a5 100644 > --- a/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc > +++ b/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc > @@ -239,6 +239,9 @@ > > MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryA > llocationLib.inf > > ExtractGuidedSectionLib|MdePkg/Library/DxeExtractGuidedSectionLib/DxeExtra > ctGuidedSectionLib.inf > > ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeRep > ortStatusCodeLib.inf > +!if $(SOURCE_DEBUG_ENABLE) > + > DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib. > inf > +!endif > > CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuE > xceptionHandlerLib.inf >MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf > > diff --git a/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc > b/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc > index 2492142b97..c3fe099e5f 100644 > --- a/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc > +++ b/CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc > @@ -239,6 +239,9 @@ > > MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryA > llocationLib.inf > > ExtractGuidedSectionLib|MdePkg/Library/DxeExtractGuidedSectionLib/DxeExtra > ctGuidedSectionLib.inf > > ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeRep > ortStatusCodeLib.inf > +!if $(SOURCE_DEBUG_ENABLE) > + > DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib. > inf > +!endif > > CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuE > xceptionHandlerLib.inf >MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf > > -- > 2.16.3 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v7 1/6] CorebootPayloadPkg/PciHostBridgeLib: clear aperture vars for (re)init
Reviewed-by: Benjamin You
> -Original Message-
> From: Heyi Guo [mailto:heyi@linaro.org]
> Sent: Thursday, March 15, 2018 2:04 PM
> To: edk2-devel@lists.01.org
> Cc: Heyi Guo ; Yi Li ; Ma,
> Maurice ; Agyeman, Prince
> ; You, Benjamin ; Ni,
> Ruiyu ; Laszlo Ersek ; Ard Biesheuvel
>
> Subject: [PATCH v7 1/6] CorebootPayloadPkg/PciHostBridgeLib: clear aperture
> vars for (re)init
>
> Use ZeroMem() to initialize (or re-initialize) all fields in temporary
> PCI_ROOT_BRIDGE_APERTURE variables to zero. This is not mandatory but
> helpful for future extension: when we add new fields to
> PCI_ROOT_BRIDGE_APERTURE and the default value of these fields can
> safely be zero, this code will not suffer from an additional change.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Heyi Guo
> Signed-off-by: Yi Li
> Reviewed-by: Ni Ruiyu
> Cc: Maurice Ma
> Cc: Prince Agyeman
> Cc: Benjamin You
> Cc: Ruiyu Ni
> Cc: Laszlo Ersek
> Cc: Ard Biesheuvel
> ---
>
> Notes:
> v6:
> - Move ZeroMem() into the loop just as Laszlo commented on OvmfPkg
> [Laszlo]
> - Minor changes in commit message
>
> CorebootPayloadPkg/Library/PciHostBridgeLib/PciHostBridgeSupport.c | 7
> ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git
> a/CorebootPayloadPkg/Library/PciHostBridgeLib/PciHostBridgeSupport.c
> b/CorebootPayloadPkg/Library/PciHostBridgeLib/PciHostBridgeSupport.c
> index 6d94ff72c956..18dcbafdf0c6 100644
> --- a/CorebootPayloadPkg/Library/PciHostBridgeLib/PciHostBridgeSupport.c
> +++ b/CorebootPayloadPkg/Library/PciHostBridgeLib/PciHostBridgeSupport.c
> @@ -328,8 +328,13 @@ ScanForRootBridges (
>for (PrimaryBus = 0; PrimaryBus <= PCI_MAX_BUS; PrimaryBus = SubBus + 1) {
> SubBus = PrimaryBus;
> Attributes = 0;
> +
> +ZeroMem (&Io, sizeof (Io));
> +ZeroMem (&Mem, sizeof (Mem));
> +ZeroMem (&MemAbove4G, sizeof (MemAbove4G));
> +ZeroMem (&PMem, sizeof (PMem));
> +ZeroMem (&PMemAbove4G, sizeof (PMemAbove4G));
> Io.Base = Mem.Base = MemAbove4G.Base = PMem.Base =
> PMemAbove4G.Base = MAX_UINT64;
> -Io.Limit = Mem.Limit = MemAbove4G.Limit = PMem.Limit =
> PMemAbove4G.Limit = 0;
> //
> // Scan all the PCI devices on the primary bus of the PCI root bridge
> //
> --
> 2.7.4
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v7 0/6] Add translation support to generic PciHostBridge
Hi, I consulted Ray. I have no objection to the patch for CorebootPayloadPkg. Thanks, - ben > -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Thursday, March 15, 2018 4:05 PM > To: Heyi Guo ; Ni, Ruiyu ; Ma, > Maurice ; You, Benjamin ; > Agyeman, Prince > Cc: edk2-devel@lists.01.org; Zeng, Star ; Dong, Eric > ; Laszlo Ersek ; Kinney, Michael D > ; Justen, Jordan L ; > Anthony Perard ; Julien Grall > > Subject: Re: [PATCH v7 0/6] Add translation support to generic PciHostBridge > > On 15 March 2018 at 06:03, Heyi Guo wrote: > > Code can also be found here: > > https://github.com/iwishguo/edk2/tree/patch-pci-host-bridge-v7 > > > > v7: > > - Patch 4: implement 1 comments from Ray. > > > > > Thanks Heyi. > > I will merge this v7 by the end of today unless anyone objects. > > Maurice, Prince, Benjamin: you have had ample time to respond to the > Coreboot changes. I am going to assume that you have no objections > unless you raise them today. > > Thanks all, > Ard. > > > > > v6: > > - Patch 1, 2: implement 3 comments from Laszlo. > > - Patch 4: implement 3 comments from Ray. > > > > Patch v5 inherits the code from RFC v4; we don't restart the version number > for > > RFC to PATCH change. > > > > v5: > > - Patch 4/6: Modify the code according to the comments from Ray. > > - Patch 1/6 and 2/6 are totally new. They add initialization for all fields > > of > > PCI_ROOT_BRIDGE_APERTURE temporary variables in PciHostBridgeLib > instances, so > > that they will not suffer from extension of PCI_ROOT_BRIDGE_APERTURE > > structure. > > - Generate a separate patch (3/6) for PciHostBridgeLib.h change. Though it > > is a > > prerequisite for patch 4/6, it does not change the code in PciHostBridge > > driver and won't cause any build failure or functional issue. > > > > > > v4: > > - Modify the code according to the comments from Ray, Laszlo and Ard > (Please see > > the notes of Patch 1/3) > > - Ignore translation of bus in CreateRootBridge. > > > > > > v3: > > - Keep definition of Translation consistent in EDKII code: Translation = > > device > > address - host address. > > - Patch 2/2 is split into 2 patches (2/3 and 3/3). > > - Refine comments and commit messages to make the code easier to > understand. > > > > > > v2: > > Changs are made according to the discussion on the mailing list, including: > > > > - PciRootBridgeIo->Configuration should return CPU view address, as well as > > PciIo->GetBarAttributes, and Translation Offset should be equal to PCI > > view > > address - CPU view address. > > - Add translation offset to PCI_ROOT_BRIDGE_APERTURE structure definition. > > - PciHostBridge driver internally used Base Address is still based on PCI > > view > > address, and translation offset = CPU view - PCI view, which follows the > > definition in ACPI, and not the same as that in UEFI spec. > > > > Cc: Ruiyu Ni > > Cc: Ard Biesheuvel > > Cc: Star Zeng > > Cc: Eric Dong > > Cc: Laszlo Ersek > > Cc: Michael D Kinney > > Cc: Maurice Ma > > Cc: Prince Agyeman > > Cc: Benjamin You > > Cc: Jordan Justen > > Cc: Anthony Perard > > Cc: Julien Grall > > > > > > Heyi Guo (6): > > CorebootPayloadPkg/PciHostBridgeLib: clear aperture vars for (re)init > > OvmfPkg/PciHostBridgeLib: clear PCI aperture vars for (re)init > > MdeModulePkg/PciHostBridgeLib.h: add address Translation > > MdeModulePkg/PciHostBridgeDxe: Add support for address translation > > MdeModulePkg/PciBus: convert host address to device address > > MdeModulePkg/PciBus: return CPU address for GetBarAttributes > > > > MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.h | 21 > > +++ > > MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostResource.h| 3 + > > MdeModulePkg/Include/Library/PciHostBridgeLib.h| 19 > > +++ > > CorebootPayloadPkg/Library/PciHostBridgeLib/PciHostBridgeSupport.c | 7 > +- > > MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c | 12 +- > > MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c | 129 > --- > > MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c| 135 > ++-- > > OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.c| 4 + > > OvmfPkg/Library/PciHostBridgeLib/XenSupport.c | 7 +- > > 9 files changed, 306 insertions(+), 31 deletions(-) > > > > -- > > 2.7.4 > > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] CorebootPayloadPkg: Use correct BytesPerScanLine
Reviewed-by: Benjamin You > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > art...@aheymans.xyz > Sent: Wednesday, January 24, 2018 6:58 PM > To: edk2-devel@lists.01.org > Cc: Arthur Heymans > Subject: [edk2] [PATCH] CorebootPayloadPkg: Use correct BytesPerScanLine > > From: Arthur Heymans > > Fetch BytesPerScanLine from coreboot table to reflect how the actual > framebuffer is set up instead of guessing it from the horizontal > resolution. > > This fixes a garbled display when HorizontalResolution * (BitsPerPixel > / 8) and pFbInfo->BytesPerScanLine don't match. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Arthur Heymans > > diff --git a/CorebootPayloadPkg/FbGop/FbGop.c > b/CorebootPayloadPkg/FbGop/FbGop.c > index 37d6def7f7..6790617033 100644 > --- a/CorebootPayloadPkg/FbGop/FbGop.c > +++ b/CorebootPayloadPkg/FbGop/FbGop.c > @@ -822,7 +822,7 @@ FbGopCheckForVbe ( >BitsPerPixel = pFbInfo->BitsPerPixel; >HorizontalResolution = pFbInfo->HorizontalResolution; >VerticalResolution = pFbInfo->VerticalResolution; > - BytesPerScanLine = HorizontalResolution * (BitsPerPixel / 8); > + BytesPerScanLine = pFbInfo->BytesPerScanLine; > >ModeBuffer = (FB_VIDEO_MODE_DATA *) AllocatePool ( > > > ModeNumber * sizeof > (FB_VIDEO_MODE_DATA) > -- > 2.16.1 > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] CorebootPayloadPkg: Use correct BytesPerScanLine
Hi Arthur, There is a related fix in the same file (FbGop.c): Line 896: FbGopPrivate->GraphicsOutput.Mode->Info->PixelsPerScanLine = HorizontalResolution; must be changed to: FbGopPrivate->GraphicsOutput.Mode->Info->PixelsPerScanLine = BytesPerScanLine / (BitsPerPixel / 8); I will submit a separate patch for this. Thanks, - ben > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > art...@aheymans.xyz > Sent: Wednesday, January 24, 2018 6:58 PM > To: edk2-devel@lists.01.org > Cc: Arthur Heymans > Subject: [edk2] [PATCH] CorebootPayloadPkg: Use correct BytesPerScanLine > > From: Arthur Heymans > > Fetch BytesPerScanLine from coreboot table to reflect how the actual > framebuffer is set up instead of guessing it from the horizontal > resolution. > > This fixes a garbled display when HorizontalResolution * (BitsPerPixel > / 8) and pFbInfo->BytesPerScanLine don't match. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Arthur Heymans > > diff --git a/CorebootPayloadPkg/FbGop/FbGop.c > b/CorebootPayloadPkg/FbGop/FbGop.c > index 37d6def7f7..6790617033 100644 > --- a/CorebootPayloadPkg/FbGop/FbGop.c > +++ b/CorebootPayloadPkg/FbGop/FbGop.c > @@ -822,7 +822,7 @@ FbGopCheckForVbe ( >BitsPerPixel = pFbInfo->BitsPerPixel; >HorizontalResolution = pFbInfo->HorizontalResolution; >VerticalResolution = pFbInfo->VerticalResolution; > - BytesPerScanLine = HorizontalResolution * (BitsPerPixel / 8); > + BytesPerScanLine = pFbInfo->BytesPerScanLine; > >ModeBuffer = (FB_VIDEO_MODE_DATA *) AllocatePool ( > > > ModeNumber * sizeof > (FB_VIDEO_MODE_DATA) > -- > 2.16.1 > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] CorebootPayloadPkg: Use correct BytesPerScanLine
Hi Nico, Thanks for the documentation that is very clear. Thanks, - ben > -Original Message- > From: Nico Huber [mailto:nic...@gmx.de] > Sent: Sunday, January 28, 2018 10:34 PM > To: You, Benjamin ; edk2-devel@lists.01.org > Cc: Arthur Heymans > Subject: Re: [edk2] [PATCH] CorebootPayloadPkg: Use correct BytesPerScanLine > > Hi Ben, > > On 28.01.2018 09:49, You, Benjamin wrote: > > Hi Nico, > > > > Thanks for the detailed information. It makes sense. I do like the idea of > > documenting the lb_framebuffer. > > > >> The only guarantee for `bytes_per_pixel` (typo? 'bytes_per_scanline') > > yes, typo. > > >> and `x_resolution` you get as a consumer, is that the former is big > >> enough to hold `x_resolution` pixels. > > > > I think it would be good to also document that the consumer is assured that > > in framebuffer, all the 'x_resolution' pixels are aligned at the beginning > > of each scanline, and the extra bytes are always padded after the > > 'x_resolution' pixels in the scanline. Would this be true with existing > > graphics devices? (I am not expert in this area so I'd like to confirm.) > > Yes, that's true. I've started to document the whole thing now: > > https://review.coreboot.org/#/c/coreboot/+/23466/4/src/commonlib/include/ > commonlib/coreboot_tables.h@214 > > The same applies in principle to EFI_GRAPHICS_OUTPUT_MODE_INFORMATION. > This framebuffer layout is very common. > > Nico ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] CorebootPayloadPkg: Use correct BytesPerScanLine
Hi Nico, Thanks for the detailed information. It makes sense. I do like the idea of documenting the lb_framebuffer. > The only guarantee for `bytes_per_pixel` (typo? 'bytes_per_scanline') > and `x_resolution` you get as a consumer, is that the former is big > enough to hold `x_resolution` pixels. I think it would be good to also document that the consumer is assured that in framebuffer, all the 'x_resolution' pixels are aligned at the beginning of each scanline, and the extra bytes are always padded after the 'x_resolution' pixels in the scanline. Would this be true with existing graphics devices? (I am not expert in this area so I'd like to confirm.) > -Original Message- > From: Nico Huber [mailto:nic...@gmx.de] > Sent: Saturday, January 27, 2018 10:14 PM > To: You, Benjamin > Cc: Arthur Heymans ; edk2-devel@lists.01.org > Subject: Re: [edk2] [PATCH] CorebootPayloadPkg: Use correct BytesPerScanLine > > Hello Ben, > > On 27.01.2018 05:11, benjamin.you at intel.com (You, Benjamin) wrote: > > The functioning will depend on Coreboot interpreting properly too. However > > fixing the Payload will not cause any regression anyway. > > I'm not sure what you mean by "interpreting properly". The > `bytes_per_line` field has to match the hardware configuration ofc. > But it is never interpreted by coreboot, coreboot is the producer > of that value, never the consumer. > > Please don't make this more complicated than it is. The consumer of the > framebuffer configuration (in this case TianoCore) simply has to honor > the `bytes_per_line` field and shouldn't make any assumptions about it > (there is no generic rule how to get from an `x_resolution` to a > `bytes_per_line` value, there are only constraints. otherwise, there > would be no reason to pass `bytes_per_line` at all). > > If you'd like, I can add some documentation to `struct lb_framebuffer` > (that's how it's called in coreboot, don't know the name in TianoCore). > The consumer should be only written with that struct (and it's documen- > tation) in mind (i.e. not by looking at coreboot internal code that may > change at any time). > > > I am still not very clear about some cases in Coreboot as below: > > > >> This is how x_resolution initially gets set after the EDID is read, but > >> it is further modified to satisfy the display controllers needs, > >> e.g. src/northbridge/intel/gm45/gma.c: > >> > >> edid->bytes_per_line = (edid->bytes_per_line + 63) & ~63; > > > > This line does not change the value of edid->bytes_per_line since it is > > already rounded up to 64 by previous calculation in edid.c: > > > > edid->bytes_per_line = ALIGN_UP(edid->mode.ha * > > div_round_up(fb_bpp, 8), row_byte_alignment); > > The piece of code in gm45/gma.c uses `struct edid` as an interface. > There is no guarantee that this struct run through the code in edid.c, > it could also have been generated somewhere else. But the hardware > covered by gm45/gma.c has this requirement, so it has to be done there. > > Moreover the code in edid.c is broken anyway: it aligns x_resolution > up as well, which is wrong (generally. it might be correct for some > hardware but that should be handled in the respective driver). > > Please ignore any code surrounding `struct edid` in coreboot, it's > very badly designed and implemented worse. > > >> There are also other code paths that don't use src/lib/edid.c to set up > >> the framebuffer. > >> > >> In src/drivers/intel/gma/hires_fb/gma.adb we have: > >> x_resolution => word32 (fb.Width), > >> y_resolution => word32 (fb.Height), > >> bytes_per_line => 4 * word32 (fb.Stride), > >> > >>From the same file, I found: > > Stride => ((Width_Type (min_h) + 63) / 64) * 64 > > > > This line seems to expand Stride to 64 alignment in the unit of Pixel, not > > Byte. I thought line padding is on 64 byte alignment, not on 64 pixel > > alignment. > > Yes, you are right. This "over-alignment" was introduced by accident, by > me. I'd like to keep it, though. It's not wrong by any means, and only > wastes a little memory. OTOH, as it's using unusual values while still > being compliant with hardware and the coreboot framebuffer interface, > it's a great measure to discover bugs in consumers of our framebuffer > interface. > > Btw. there is much more gfx init code in coreboot for non-Intel hard- > ware. Which may have it's own constraints regarding `bytes_per_pixel`. > The only guarantee for `bytes_per_pixel` and `x_resolution` you get as > a consumer, is that the former is big enough to hold `x_resolution` > pixels. > > Nico Thanks, - ben ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] CorebootPayloadPkg: Use correct BytesPerScanLine
Hi Arthur, I agree with your suggestion that Payload interpret BytesPerScanLine and Horizontal Resolution properly such that a 1366 display can be handled well. The functioning will depend on Coreboot interpreting properly too. However fixing the Payload will not cause any regression anyway. I am still not very clear about some cases in Coreboot as below: > -Original Message- > From: Arthur Heymans [mailto:art...@aheymans.xyz] > Sent: Friday, January 26, 2018 5:09 PM > To: You, Benjamin > Cc: edk2-devel@lists.01.org > Subject: Re: [edk2] [PATCH] CorebootPayloadPkg: Use correct BytesPerScanLine > > "You, Benjamin" writes: > > > > > I noticed in coreboot-4.7\src\include\edid.h, there are following comments: > > > > /* 3 variables needed for coreboot framebuffer. > > * In most cases, they are the same as the ha > > * and va variables, but not always, as in the > > * case of a 1366 wide display. > > */ > > u32 x_resolution; > > u32 y_resolution; > > u32 bytes_per_line; > > > > And in coreboot-4.7\src\lib\edid.c: > > > > edid->bytes_per_line = ALIGN_UP(edid->mode.ha * > > div_round_up(fb_bpp, 8), row_byte_alignment); > > edid->x_resolution = edid->bytes_per_line / (fb_bpp / 8); > > > > This is how x_resolution initially gets set after the EDID is read, but > it is further modified to satisfy the display controllers needs, > e.g. src/northbridge/intel/gm45/gma.c: > > edid->bytes_per_line = (edid->bytes_per_line + 63) & ~63; This line does not change the value of edid->bytes_per_line since it is already rounded up to 64 by previous calculation in edid.c: edid->bytes_per_line = ALIGN_UP(edid->mode.ha * div_round_up(fb_bpp, 8), row_byte_alignment); > > before it gets send to code that sets up the coreboot tables from which > payloads extract this information: > > set_vbe_mode_info_valid(edid, lfb); > > There are also other code paths that don't use src/lib/edid.c to set up > the framebuffer. > > In src/drivers/intel/gma/hires_fb/gma.adb we have: > x_resolution => word32 (fb.Width), > y_resolution => word32 (fb.Height), > bytes_per_line => 4 * word32 (fb.Stride), > >From the same file, I found: Stride => ((Width_Type (min_h) + 63) / 64) * 64 This line seems to expand Stride to 64 alignment in the unit of Pixel, not Byte. I thought line padding is on 64 byte alignment, not on 64 pixel alignment. > > > Above calculations derive x_resolution from the roundup value of > > bytes_per_line. In case of 1366 display, it would produce a x_resolution of > > 1376, which is larger than 1366 but satisfies the equation of > > bytes_per_line == (HorizontalResolution * (BitsPerPixel / 8) > > > > It is only initialized to that when the EDID is read. The code that > actually sets up the hardware further modifies it or passes on the value > it needs to bytes_per_line. > > > It appears this is what Coreboot produces right now. Not sure if there are > > other cases leading to Coreboot producing framebuffer parameters NOT > > satisfying the above equation. > > > > well given that other code touches edid_bytes_per_lines, there are many > examples where this is not satisfied. > > > BTW, do you think the above calculation of x_resolution hides the > > information of display and should be fixed? > > > >> So tianocore should use the value coreboot provides it instead of trying > >> to compute/guess it. > >> > >> > Thanks, > >> > > >> > - ben > >> > > >> > >> I hope this clarifies it. > >> > >> Arthur > >> > >> >> -Original Message- > >> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > >> >> art...@aheymans.xyz > >> >> Sent: Wednesday, January 24, 2018 6:58 PM > >> >> To: edk2-devel@lists.01.org > >> >> Cc: Arthur Heymans > >> >> Subject: [edk2] [PATCH] CorebootPayloadPkg: Use correct > BytesPerScanLine > >> >> > >> >> From: Arthur Heymans > >> >> > >> >> Fetch BytesPerScanLine from coreboot table to reflect how the actual > >> >> framebuffer is set up instead of guessing it from the horizontal > >> >> resolution. > >> >> > >> >> This fixes a garbled display when HorizontalResolution * (BitsPerPixel > >> >> / 8) and pFbInfo-
Re: [edk2] [PATCH] CorebootPayloadPkg: Use correct BytesPerScanLine
Hi Arthur, > -Original Message- > From: Arthur Heymans [mailto:art...@aheymans.xyz] > Sent: Thursday, January 25, 2018 5:03 PM > To: You, Benjamin > Cc: edk2-devel@lists.01.org > Subject: Re: [edk2] [PATCH] CorebootPayloadPkg: Use correct BytesPerScanLine > > "You, Benjamin" writes: > > > Hi Arthur, > > > > Could you please give more details about your case that > > HorizontalResolution * (BitsPerPixel / 8) and pFbInfo->BytesPerScanLine > > don't match? > > > > On many devices, notably Intel hardware, the STRIDE needs to be 64 byte > aligned when used in linear memory mode, which coreboot does. STRIDE is > value that used to determine the line to line increment for the > display. So what coreboot does when initializing the hardware to align > (HorizontalResolution * (BitsPerPixel / 8)), 64 bytes up. > > > I did a brief search in Coreboot source and found following comments in > > coreboot-4.6\src\lib\edid.c: > > > > /* In the case of (e.g.) 24 framebuffer bits per pixel, the convention > >* nowadays seems to be to round it up to the nearest reasonable > >* boundary, because otherwise the byte-packing is hideous. > > > > So it appears framebuffer BitsPerPixel will likely be 16 or 32, and the > > following statement in the same file calculates: > > > > edid->x_resolution = edid->bytes_per_line / (fb_bpp / 8); > > > > which results in bytes_per_line (already rounded up to be 32 or 64 byte > > aligned) matching x_resolution * (fb_bpp / 8). > > > > There are cases that even if panel bits_per_pixel is 24, the framebuffer > > bits_per_pixel is still 32, as shown in > > coreboot-4.6\src\drivers\emulation\qemu\bochs.c: > > > > edid.panel_bits_per_pixel = 24; > > edid_set_framebuffer_bits_per_pixel(&edid, 32, 0); > > > > It would be good if you could help with more details on how the mismatch > > happened in your case as I may have missed something. > > > > So long story short 'bytes_per_line' reflects how the actual hardware is > set up, while using '(HorizontalResolution * (BitsPerPixel / 8)' is a > guess which is only sometimes correct. > > To give an example (on which this was actually a problem): > let's say we have a display 1366 pixel horizontal resolution with 32 > bits per pixel. > > HorizontalResolution * BitsPerPixel / 8 = 5464 > > But this value is not 64 byte aligned which the hardware expects so. > > aligned value = ((HorizontalResolution * (BitsPerPixel / 8) + 63) & ~63 > = 5504 > I noticed in coreboot-4.7\src\include\edid.h, there are following comments: /* 3 variables needed for coreboot framebuffer. * In most cases, they are the same as the ha * and va variables, but not always, as in the * case of a 1366 wide display. */ u32 x_resolution; u32 y_resolution; u32 bytes_per_line; And in coreboot-4.7\src\lib\edid.c: edid->bytes_per_line = ALIGN_UP(edid->mode.ha * div_round_up(fb_bpp, 8), row_byte_alignment); edid->x_resolution = edid->bytes_per_line / (fb_bpp / 8); Above calculations derive x_resolution from the roundup value of bytes_per_line. In case of 1366 display, it would produce a x_resolution of 1376, which is larger than 1366 but satisfies the equation of bytes_per_line == (HorizontalResolution * (BitsPerPixel / 8) It appears this is what Coreboot produces right now. Not sure if there are other cases leading to Coreboot producing framebuffer parameters NOT satisfying the above equation. BTW, do you think the above calculation of x_resolution hides the information of display and should be fixed? > So tianocore should use the value coreboot provides it instead of trying > to compute/guess it. > > > Thanks, > > > > - ben > > > > I hope this clarifies it. > > Arthur > > >> -Original Message- > >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > >> art...@aheymans.xyz > >> Sent: Wednesday, January 24, 2018 6:58 PM > >> To: edk2-devel@lists.01.org > >> Cc: Arthur Heymans > >> Subject: [edk2] [PATCH] CorebootPayloadPkg: Use correct BytesPerScanLine > >> > >> From: Arthur Heymans > >> > >> Fetch BytesPerScanLine from coreboot table to reflect how the actual > >> framebuffer is set up instead of guessing it from the horizontal > >> resolution. > >> > >> This fixes a garbled display when HorizontalResolution * (BitsPerPixel > >> / 8) and pFbInfo->BytesPerScanLine don't m
Re: [edk2] [PATCH] CorebootPayloadPkg: Use correct BytesPerScanLine
Hi Arthur, Could you please give more details about your case that HorizontalResolution * (BitsPerPixel / 8) and pFbInfo->BytesPerScanLine don't match? I did a brief search in Coreboot source and found following comments in coreboot-4.6\src\lib\edid.c: /* In the case of (e.g.) 24 framebuffer bits per pixel, the convention * nowadays seems to be to round it up to the nearest reasonable * boundary, because otherwise the byte-packing is hideous. So it appears framebuffer BitsPerPixel will likely be 16 or 32, and the following statement in the same file calculates: edid->x_resolution = edid->bytes_per_line / (fb_bpp / 8); which results in bytes_per_line (already rounded up to be 32 or 64 byte aligned) matching x_resolution * (fb_bpp / 8). There are cases that even if panel bits_per_pixel is 24, the framebuffer bits_per_pixel is still 32, as shown in coreboot-4.6\src\drivers\emulation\qemu\bochs.c: edid.panel_bits_per_pixel = 24; edid_set_framebuffer_bits_per_pixel(&edid, 32, 0); It would be good if you could help with more details on how the mismatch happened in your case as I may have missed something. Thanks, - ben > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > art...@aheymans.xyz > Sent: Wednesday, January 24, 2018 6:58 PM > To: edk2-devel@lists.01.org > Cc: Arthur Heymans > Subject: [edk2] [PATCH] CorebootPayloadPkg: Use correct BytesPerScanLine > > From: Arthur Heymans > > Fetch BytesPerScanLine from coreboot table to reflect how the actual > framebuffer is set up instead of guessing it from the horizontal > resolution. > > This fixes a garbled display when HorizontalResolution * (BitsPerPixel > / 8) and pFbInfo->BytesPerScanLine don't match. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Arthur Heymans > > diff --git a/CorebootPayloadPkg/FbGop/FbGop.c > b/CorebootPayloadPkg/FbGop/FbGop.c > index 37d6def7f7..6790617033 100644 > --- a/CorebootPayloadPkg/FbGop/FbGop.c > +++ b/CorebootPayloadPkg/FbGop/FbGop.c > @@ -822,7 +822,7 @@ FbGopCheckForVbe ( >BitsPerPixel = pFbInfo->BitsPerPixel; >HorizontalResolution = pFbInfo->HorizontalResolution; >VerticalResolution = pFbInfo->VerticalResolution; > - BytesPerScanLine = HorizontalResolution * (BitsPerPixel / 8); > + BytesPerScanLine = pFbInfo->BytesPerScanLine; > >ModeBuffer = (FB_VIDEO_MODE_DATA *) AllocatePool ( > > > ModeNumber * sizeof > (FB_VIDEO_MODE_DATA) > -- > 2.16.1 > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Enabling boot menu via serial & PXE boot in CorebootPayloadPkg
Hi Cameron, > >I get serial output from edk2 with the release build and the debug build. > >However this serial output does not include the boot menu, I just get > >progress > >and error codes (and debug messages in debug mode). > >I have attached a runtime log of a recent debug build. >From your log, I cannot see the below prompt message: "F2 or Down to enter Boot Manager Menu. ENTER to boot directly." With my system, there is above message shown in serial. When I press F2 upon the message, the boot manager is shown. The message is printed in PlatformBootManagerAfterConsole() in CorebootPayloadPkg\Library\PlatformBootManagerLib\PlatformBootManager.c. Not sure what went wrong, but you might add some debug message to trace the execution flow. Or, have you been able to boot to UEFI Shell? If yes, you may type "exit" from the Shell prompt, and boot manager should show up. Thanks, - ben ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Enabling boot menu via serial & PXE boot in CorebootPayloadPkg
Hi, Cameron, > Interestingly, my debug build was complaining that it ran out of room when > attempting to fit everything in the UEFIPAYLOAD. > When I strip out the network additions and keep DEBUG on, Tianocore builds but > errors at runtime: > ``` > Failed to add memory space :0xFEE0 0x10 > ``` > I'm guessing I can increase the size of a region somewhere to avoid this > issue? There has been a recent fix for this issue by commit e2ef8b9a68. Could you please have a try? > I get serial output from coreboot and edk2, just not the boot menu. I will double check whether there is an issue with enabling serial with release build. Thanks, - ben ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 5/6] CorebootPayloadPkg: Fix build failure due to Tftp/Dp library removal
Reviewed-by: Benjamin You
> -Original Message-
> From: Ni, Ruiyu
> Sent: Wednesday, November 29, 2017 9:00 AM
> To: edk2-devel@lists.01.org
> Cc: Ma, Maurice ; Agyeman, Prince
> ; You, Benjamin
> Subject: [PATCH v3 5/6] CorebootPayloadPkg: Fix build failure due to Tftp/Dp
> library removal
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni
> Cc: Maurice Ma
> Cc: Prince Agyeman
> Cc: Benjamin You
> ---
> CorebootPayloadPkg/CorebootPayloadPkg.fdf| 4 ++-
> CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc| 36 +--
> -
> CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc | 36 +
> ---
> 3 files changed, 41 insertions(+), 35 deletions(-)
>
> diff --git a/CorebootPayloadPkg/CorebootPayloadPkg.fdf
> b/CorebootPayloadPkg/CorebootPayloadPkg.fdf
> index 303e626842..7994f0c949 100644
> --- a/CorebootPayloadPkg/CorebootPayloadPkg.fdf
> +++ b/CorebootPayloadPkg/CorebootPayloadPkg.fdf
> @@ -3,7 +3,7 @@
> #
> # Provides drivers and definitions to create uefi payload for coreboot.
> #
> -# Copyright (c) 2014 - 2016, Intel Corporation. All rights reserved.
> +# Copyright (c) 2014 - 2017, Intel Corporation. All rights reserved.
> # This program and the accompanying materials are licensed and made
> available under
> # the terms and conditions of the BSD License that accompanies this
> distribution.
> # The full text of the license may be found at
> @@ -180,6 +180,8 @@ [FV.DXEFV]
> # Shell
> #
> !if $(SHELL_TYPE) == BUILD_SHELL
> +INF
> ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
> +INF
> ShellPkg/DynamicCommand/DpDynamicCommand/DpDynamicCommand.inf
> INF ShellPkg/Application/Shell/Shell.inf
> !endif
>
> diff --git a/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
> b/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
> index cdfcb75b59..ace1bc0a37 100644
> --- a/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
> +++ b/CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc
> @@ -3,7 +3,7 @@
> #
> # Provides drivers and definitions to create uefi payload for coreboot.
> #
> -# Copyright (c) 2014 - 2016, Intel Corporation. All rights reserved.
> +# Copyright (c) 2014 - 2017, Intel Corporation. All rights reserved.
> # This program and the accompanying materials are licensed and made
> available under
> # the terms and conditions of the BSD License that accompanies this
> distribution.
> # The full text of the license may be found at
> @@ -515,11 +515,6 @@ [Components.IA32]
>
> !if $(SHELL_TYPE) == BUILD_SHELL
>
> -[PcdsFixedAtBuild]
> - ## This flag is used to control initialization of the shell library
> - # This should be FALSE for compiling the shell application itself only.
> - gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> -
>#
># Shell Lib
>#
> @@ -527,9 +522,27 @@ [LibraryClasses]
>
> BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCo
> mmandLib.inf
>DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
>FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
> + ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
> + NetLib|MdeModulePkg/Library/DxeNetLib/DxeNetLib.inf
>
> [Components.IA32]
> +
> ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
> {
> +
> + ## This flag is used to control initialization of the shell library
> + # This should be FALSE for compiling the dynamic command.
> + gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> + }
> + ShellPkg/DynamicCommand/DpDynamicCommand/DpDynamicCommand.inf {
> +
> + ## This flag is used to control initialization of the shell library
> + # This should be FALSE for compiling the dynamic command.
> + gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> + }
>ShellPkg/Application/Shell/Shell.inf {
> +
> + ## This flag is used to control initialization of the shell library
> + # This should be FALSE for compiling the shell application itself
> only.
> + gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
>
> #--
> # Basic commands
> @@ -549,14 +562,6 @@ [Components.IA32]
>
>
>
> NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1Co
> mmandsLib.inf
> -
> NULL|ShellPkg/Library/UefiShellTftpCommandLib/UefiShellTftpCommandLib.inf
> -
> -#--
> -# Performance command
> -#--
> -
> -
> - NULL|ShellPkg/Library/UefiDpLib/UefiDpLib.inf
>
>
Re: [edk2] Enabling boot menu via serial & PXE boot in CorebootPayloadPkg
Hi Cameron, BTW, please use debug build for Coreboot Payload, such that debug information can be shown in serial console from the very early stage in the Payload's execution. This would help validating the functioning of serial. Thanks, - ben > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of You, > Benjamin > Sent: Saturday, November 25, 2017 11:25 PM > To: Cameron Craig ; 'edk2-devel@lists.01.org' > > Subject: Re: [edk2] Enabling boot menu via serial & PXE boot in > CorebootPayloadPkg > > Hi Cameron, > > CorebootPayloadPkg does support serial output as user interface. To enable > serial, the CorebootPayloadPkg retrieves serial information from Coreboot > through CorebootModulePkg\Library\CbParseLib\CbParseLib.c => > CbParseSerialInfo(), which is called by CorebootPayloadPkg\Library\ > PlatformHookLib\PlatformHookLib.c => PlatformHookSerialPortInitialize(), > which is in turn called by CorebootModulePkg\Library\BaseSerialPortLib16550 > \BaseSerialPortLib16550.c ==> SerialPortInitialize(). > > Have you seen serial output info during Coreboot? If the answer is no, then > Coreboot should be tweaked. If the answer is yes, but you cannot see serial > output in Coreboot Payload, then probably the above call sequence needs to > be checked. If you do not have a debugger, one way to trace code flow is to > insert raw serial outputs in the code flow. This should be doable since > Coreboot already does serial output. Once the serial output functions > correctly in the Coreboot Payload, Boot Menu / UI through serial should be > automatically supported. > > On networking, you might refer to the Minnow Board v3 source tree, at > https://github.com/tianocore/edk2-platforms/tree/devel-MinnowBoard3- > UDK2017 > > Minnow Board v3 uses the same SOC as Leaf Hill. You might look at > Platform/BroxtonPlatformPkg/PlatformPkg.fdf file for a reference on which > components are used for network / PXE. > > Thanks, > > - ben > > > -Original Message- > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > > Cameron Craig > > Sent: Friday, November 24, 2017 5:16 PM > > To: 'edk2-devel@lists.01.org' > > Subject: [edk2] Enabling boot menu via serial & PXE boot in > CorebootPayloadPkg > > > > Hi all, > > > > I'm new to this list and new to edk2 integration. > > Currently I'm working on an Intel Leaf Hill CRB, attempting to produce a > > coreboot payload consisting of a Tianocore EDKII UDK 2017 UEFI boot > manager. > > > > I have basic functionality, but a few useful features are currently missing > > from > > my build: > > > > 1. User interface via serial. > > We will not have the luxury of a video output so need to be able to navigate > the > > boot menu etc. via serial. > > In an ideal world I would be looking for a Boolean value to toggle :) But I > > imagine there might be a little more to it. > > > > 2. PXE Boot. > > So far I have sources and built an UNDI driver and pinged a local network > device. > > I have also attempted to enable the necessary features for PXE boot [1]. > > But I get an error message: > > ``` > > $ ipconfig > > MAC Address: > > Broadcast MAC: FF FF FF FF FF FF > > ipconfig: Locate protocol error: 'PXE base code protocol' > > ``` > > So I'm thinking some drivers are not being loaded? > > > > Any suggestions for enabling these features would be greatly appreciated. > > > > [1] https://github.com/tianocore/tianocore.github.io/wiki/NetworkPkg- > > Getting-Started-Guide -> FEATURES ENABLING > > > > Cheers, > > Cameron > > > > > > Cameron Craig | Graduate Software Engineer | Exterity Limited > > tel: +44 1383 828 250 | fax: | mobile: > > e: cameron.cr...@exterity.com | w: www.exterity.com > > > > Exterity is a leading provider of IP Video and Digital Signage solutions > > that > helps > > organizations to harness the power of video to communicate, educate and > > entertain. Our end-to-end solutions enable you to take TV and video content > > directly from any source and manage its delivery, live or on demand, to any > > connected device via your existing network. For more information or to > > schedule a product demonstration, contact Exterity on +44(0)1383 828 250 or > > visit www.exterity.com > > > > Legal Notice > > Unless expressly stated otherwise, this message is confidenti
Re: [edk2] Enabling boot menu via serial & PXE boot in CorebootPayloadPkg
Hi Cameron, CorebootPayloadPkg does support serial output as user interface. To enable serial, the CorebootPayloadPkg retrieves serial information from Coreboot through CorebootModulePkg\Library\CbParseLib\CbParseLib.c => CbParseSerialInfo(), which is called by CorebootPayloadPkg\Library\ PlatformHookLib\PlatformHookLib.c => PlatformHookSerialPortInitialize(), which is in turn called by CorebootModulePkg\Library\BaseSerialPortLib16550 \BaseSerialPortLib16550.c ==> SerialPortInitialize(). Have you seen serial output info during Coreboot? If the answer is no, then Coreboot should be tweaked. If the answer is yes, but you cannot see serial output in Coreboot Payload, then probably the above call sequence needs to be checked. If you do not have a debugger, one way to trace code flow is to insert raw serial outputs in the code flow. This should be doable since Coreboot already does serial output. Once the serial output functions correctly in the Coreboot Payload, Boot Menu / UI through serial should be automatically supported. On networking, you might refer to the Minnow Board v3 source tree, at https://github.com/tianocore/edk2-platforms/tree/devel-MinnowBoard3-UDK2017 Minnow Board v3 uses the same SOC as Leaf Hill. You might look at Platform/BroxtonPlatformPkg/PlatformPkg.fdf file for a reference on which components are used for network / PXE. Thanks, - ben > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Cameron Craig > Sent: Friday, November 24, 2017 5:16 PM > To: 'edk2-devel@lists.01.org' > Subject: [edk2] Enabling boot menu via serial & PXE boot in CorebootPayloadPkg > > Hi all, > > I'm new to this list and new to edk2 integration. > Currently I'm working on an Intel Leaf Hill CRB, attempting to produce a > coreboot payload consisting of a Tianocore EDKII UDK 2017 UEFI boot manager. > > I have basic functionality, but a few useful features are currently missing > from > my build: > > 1. User interface via serial. > We will not have the luxury of a video output so need to be able to navigate > the > boot menu etc. via serial. > In an ideal world I would be looking for a Boolean value to toggle :) But I > imagine there might be a little more to it. > > 2. PXE Boot. > So far I have sources and built an UNDI driver and pinged a local network > device. > I have also attempted to enable the necessary features for PXE boot [1]. > But I get an error message: > ``` > $ ipconfig > MAC Address: > Broadcast MAC: FF FF FF FF FF FF > ipconfig: Locate protocol error: 'PXE base code protocol' > ``` > So I'm thinking some drivers are not being loaded? > > Any suggestions for enabling these features would be greatly appreciated. > > [1] https://github.com/tianocore/tianocore.github.io/wiki/NetworkPkg- > Getting-Started-Guide -> FEATURES ENABLING > > Cheers, > Cameron > > > Cameron Craig | Graduate Software Engineer | Exterity Limited > tel: +44 1383 828 250 | fax: | mobile: > e: cameron.cr...@exterity.com | w: www.exterity.com > > Exterity is a leading provider of IP Video and Digital Signage solutions that > helps > organizations to harness the power of video to communicate, educate and > entertain. Our end-to-end solutions enable you to take TV and video content > directly from any source and manage its delivery, live or on demand, to any > connected device via your existing network. For more information or to > schedule a product demonstration, contact Exterity on +44(0)1383 828 250 or > visit www.exterity.com > > Legal Notice > Unless expressly stated otherwise, this message is confidential and may be > privileged. It is intended for the addressee(s) only. Access to this e-mail by > anyone else is unauthorized. If you are not an addressee, any disclosure or > copying of the contents of this e-mail or any action taken (or not taken) in > reliance on it is unauthorized and may be unlawful. If you are not an > addressee, > please inform the sender immediately. > > Exterity Limited is registered in Scotland under No. 225313 with its > registered > office at Ridge Way, Hillend Industrial Park, Dalgety Bay, KY11 9JD. > > > _ > _ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > _ > _ > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
