Linaro-uefi

linaro-uefi@lists.linaro.org

811 discussions

[PATCH edk2-non-osi v2] Update D03/D05 MemoryInit.efi binary for bug 3419

by Ming Huang

https://bugs.linaro.org/show_bug.cgi?id=3061 For fix this bug,the function PciIoPciRead of NonDiscoverablePciDeviceDxe should be modified also. Code can also be found in github: https://github.com/hisilicon/OpenPlatformPkg.git branch: rp-osi-bug-v2 Ming Huang (1): Hisilicon D0x: Remove uncacheable attribute from memory resource HOB Platform/Hisilicon/D03/MemoryInitPei/MemoryInit.efi | Bin 90272 -> 90336 bytes Platform/Hisilicon/D05/MemoryInitPei/MemoryInit.efi | Bin 152576 -> 152480 bytes 2 files changed, 0 insertions(+), 0 deletions(-) -- 1.9.1

7 years, 5 months

[PATCH edk2-non-osi v1] Update D03/D05 MemoryInit.efi binary for bug 3419

by Ming Huang

https://bugs.linaro.org/show_bug.cgi?id=3061 For fix this bug,the function PciIoPciRead of NonDiscoverablePciDeviceDxe should be modifyed also. Code can also be found in github: https://github.com/hisilicon/OpenPlatformPkg.git branch: rp-osi-bug-v1 Ming Huang (1): Hisilicon D0x: Remove uncacheable attribute from memory resource HOB Platform/Hisilicon/D03/MemoryInitPei/MemoryInit.efi | Bin 90272 -> 90336 bytes Platform/Hisilicon/D05/MemoryInitPei/MemoryInit.efi | Bin 152576 -> 152480 bytes 2 files changed, 0 insertions(+), 0 deletions(-) -- 1.9.1

7 years, 5 months

[edk2][PATCH] MdeModulePkg/NonDiscoverable: fix memory override bug

by Heyi Guo

For PciIoPciRead interface, memory prior to Buffer would be written with zeros if Offset was larger than sizeof (Dev->ConfigSpace), which would cause serious system exception. So we add a pre-check branch to avoid memory override. Cc: Star Zeng <star.zeng(a)intel.com> Cc: Eric Dong <eric.dong(a)intel.com> Cc: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Cc: Ruiyu Ni <ruiyu.ni(a)intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Heyi Guo <heyi.guo(a)linaro.org> --- .../Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceIo.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceIo.c b/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceIo.c index c836ad6..0e42ae4 100644 --- a/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceIo.c +++ b/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceIo.c @@ -465,6 +465,11 @@ PciIoPciRead ( Address = (UINT8 *)&Dev->ConfigSpace + Offset; Length = Count << ((UINTN)Width & 0x3); + if (Offset >= sizeof (Dev->ConfigSpace)) { + ZeroMem (Buffer, Length); + return EFI_SUCCESS; + } + if (Offset + Length > sizeof (Dev->ConfigSpace)) { // // Read all zeroes for config space accesses beyond the first -- 1.9.1

7 years, 5 months

[PATCH] ArmPkg/ArmMmuLib: Add new attribute

by Heyi Guo

V1 changes upon RFC version: 1. Rename NONSHARE to NONSHAREABLE per review comments. 2. Place these two uncommon attributes after normal WRITE_BACK attributes to imply they should not be used by default. 3. Add warnning comments. Peicong Li (1): ArmPkg/ArmMmuLib: Add new attribute WRITE_BACK_NONSHAREABLE ArmPkg/Include/Library/ArmLib.h | 7 +++++++ ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c | 4 ++++ 2 files changed, 11 insertions(+) -- 2.7.2.windows.1

7 years, 5 months

[RFC] ArmPkg/ArmMmuLib: Add new attribute WRITE_BACK_NONSHARE

by Heyi Guo

From: Peicong Li <lipeicong(a)huawei.com> Flash region needs to be set as cacheable (write back) to increase performance, if PEI is still XIP on flash or DXE FV is decompressed from flash FV. However some ARM platforms do not support to set flash as inner shareable since flash is not normal DDR memory and it will not respond to cache snoop request, which will causes system hang after MMU is enabled. So we need a new ARM memory region attribute WRITE_BACK_NONSHARE for flash region on these platforms specifically. This attribute will set the region as write back but not inner shared. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Peicong Li <lipeicong(a)huawei.com> Signed-off-by: Heyi Guo <heyi.guo(a)linaro.org> Cc: Leif Lindholm <leif.lindholm(a)linaro.org> Cc: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> --- ArmPkg/Include/Library/ArmLib.h | 2 ++ ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c | 4 ++++ 2 files changed, 6 insertions(+) diff --git a/ArmPkg/Include/Library/ArmLib.h b/ArmPkg/Include/Library/ArmLib.h index 24ffe9f..e43e375 100644 --- a/ArmPkg/Include/Library/ArmLib.h +++ b/ArmPkg/Include/Library/ArmLib.h @@ -39,6 +39,8 @@ typedef enum { ARM_MEMORY_REGION_ATTRIBUTE_UNCACHED_UNBUFFERED = 0, ARM_MEMORY_REGION_ATTRIBUTE_NONSECURE_UNCACHED_UNBUFFERED, + ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK_NONSHARE, + ARM_MEMORY_REGION_ATTRIBUTE_NONSECURE_WRITE_BACK_NONSHARE, ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK, ARM_MEMORY_REGION_ATTRIBUTE_NONSECURE_WRITE_BACK, ARM_MEMORY_REGION_ATTRIBUTE_WRITE_THROUGH, diff --git a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c index 8bd1c6f..cc10143 100644 --- a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c +++ b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c @@ -35,6 +35,10 @@ ArmMemoryAttributeToPageAttribute ( ) { switch (Attributes) { + case ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK_NONSHARE: + case ARM_MEMORY_REGION_ATTRIBUTE_NONSECURE_WRITE_BACK_NONSHARE: + return TT_ATTR_INDX_MEMORY_WRITE_BACK; + case ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK: case ARM_MEMORY_REGION_ATTRIBUTE_NONSECURE_WRITE_BACK: return TT_ATTR_INDX_MEMORY_WRITE_BACK | TT_SH_INNER_SHAREABLE; -- 2.7.2.windows.1

7 years, 5 months

[RFC][edk2] MdeModulePkg/NonDiscoverablePciDeviceDxe: NonCoherentPciIoAllocateBuffer issue with AArch64

by Heyi Guo

Hi folks, In NonDiscoverablePciDeviceDxe driver, NonCoherentPciIoAllocateBuffer may allocate EFI_MEMORY_UC buffer depending on input Attributes and GCD capabilities. If it does, it actually allocates memory of "device" type in AArch64, but not "normal uncacheable" memory. For "device" memory type, it requires restrict access alignment and it may trigger alignment fault exception with BaseMemoryLibOptDxe in which read/write alignment is not guaranteed. Is EFI_MOMORY_WC enough for AArch64 platforms? How about other platforms, like X86? Thanks and regards, Heyi Guo

7 years, 5 months

Re: [Linaro-uefi] [PATCH] firmware: bluefield: add boot control driver

by Chris Metcalf

On 10/10/2017 7:58 AM, Leif Lindholm wrote: > On Tue, Oct 10, 2017 at 11:23:32AM +0100, Mark Rutland wrote: >> On Tue, Oct 10, 2017 at 11:15:39AM +0100, Sudeep Holla wrote: >>> (+Mark, Grant) >>> >>> On 09/10/17 18:16, Chris Metcalf wrote: >>>> The Mellanox BlueField SoC firmware supports a safe upgrade mode as >>>> part of the flow where users put new firmware on the secondary eMMC >>>> boot partition (the one not currently in use), tell the eMMC to make >>>> the secondary boot partition primary, and reset. >> When you say "firmware", are you referreind to actual firmware, or a >> platform-specific OS image? >> >> For the former, the preferred update mechanism would be UpdateCapsule(). > This sounds to me very much like something we'd want to keep out of > the kernel. Assuming ACPI means UEFI, there should be less invasive > solutions to this problem. > > I've added linaro-uefi to cc. Chris - if you'd be willing to have a > side discussion on the overall aproach, please drop the kernel lists > from cc and let's have a chat there. I've taken linux-kernel off the Cc and added linaro-uefi. For the linaro-uefi folks, here is the original patch and commit message: https://patchwork.kernel.org/patch/9993965/ The proposed solution is intended to be a way to update ATF + UEFI. It's possible that in practice this would also include a UEFI boot image path change (passed as a parameter contained in the firmware image on the eMMC boot partition) that would cause us to boot a different OS image and/or use a different root filesystem as well. The intent is to be able to deploy arbitrary updates to a device in the field, and then if needed, safely roll it back. But the issue here really isn't about how we install the new firmware itself. We have a simple model now that works: we use Linux to copy the new firmware to the eMMC alternate boot partition, then we issue an ioctl to the mmc driver to tell it to switch boot partitions. Now when we reboot we will get the desired new firmware. What this driver is intended to support is access via SMC to code in ATF that lets us be clever about how we can roll back bad firmware. Specifically, we notify ATF that, after the next reset, we want to turn on the ARM watchdog, and at the same time arrange that after the NEXT reset, it should switch the eMMC boot partition and reset. This means that we reset, boot the new firmware, and then if it doesn't work well, eventually the ARM watchdog causes a reset, at which point ATF switches us back to the original boot partition and the device comes up fully functional running the old firmware. If things go well once the new image is booted up, we tell ATF to relax and not do anything special at reset time, and we disarm the ARM watchdog. So the UpdateCapsule mechanism seems orthogonal to this. It's true that using UpdateCapsule would be a nice improvement on our current "write to eMMC from Linux" model. But our concern is that UEFI and Linux don't have mutual exclusion when accessing the eMMC device registers, so in our multicore system it's not safe to have UEFI write the new firmware to eMMC at the time of the UpdateCapsule call; either Linux or UEFI might end up with eMMC corruption. And we don't have substantial persistent memory across reset; the DDR memory is reset along with the chip, and beyond that we just have the UEFI variable EEPROM plus a few on-chip persistent registers, so we can't pass a megabyte or so of firmware data across reset and do the installation after reset. So we didn't really pursue this approach when we were looking at how to actually do the firmware update. Maybe there is some way to request the kinds of reset behavior that we want within the existing EFI framework that we are not aware of. Or maybe there is some way to think about incorporating some of this into the EFI reset semantics. It seems reasonable to incorporate something into UpdateCapsule to provide these semantics, although then we'd also have to fix the issues that made us not adopt the UpdateCapsule approach in the first place. What other approaches do folks think would work to achieve this fail-safe firmware upgrade model? -- Chris Metcalf, Mellanox Technologies http://www.mellanox.com

7 years, 6 months

[PATCH edk2-platforms v5 00/11] Improve D0x platforms and bug fix

by Heyi Guo

Code can also be found in github: https://github.com/hisilicon/OpenPlatformPkg.git branch: rp-1710-platforms-v5 Note: 1. There may be some minor issue (or even in SoC IP) that causes D05/3 into exception, which was just found when we updated edk2 and edk2-platforms. We will continue to investigate the issue. It boot successfully by switch the VirtualEhciPciIo with old one. 2. The separate patch (Add AddressTranslationOffset support) is a prerequisite for this series and it's source can also be found in above branch(rp-1710-platforms-v5). Chenhui Sun (1): Hisilicon/D03: Disable the function of PerfTuning Heyi Guo (4): Hisilicon/D05: Modify dsc and fdf file Hisilicon/D03: Modify dsc and fdf file Hisilicon: Fix the drivers use the same GUID issue Hisilicon/PciHostBridgeDxe: Assign BAR resource from PciRegionBase Jason zhang (1): Hisilicon D03/D05: Enlarge iATU for RP with ARI capable device. Ming Huang (5): Hisilicon D03/D05: get firmware version from FIRMWARE_VER Hisilicon/D05/Pcie: fix bug of size definition D05/PCIe: Modify PcieRegionBase of secondary chip D05/ACPI: Disable D05 SAS0 and SAS2 D05/ACPI: Modify I2C device Platform/Hisilicon/D02/EarlyConfigPeim/EarlyConfigPeim.inf | 2 +- Platform/Hisilicon/D02/FdtUpdateLibD02/FdtUpdateLib.inf | 2 +- Platform/Hisilicon/D02/Library/PlatformPciLib/PlatformPciLib.inf | 2 +- Platform/Hisilicon/D02/OemNicConfigD02/OemNicConfigD02.inf | 2 +- Platform/Hisilicon/D03/D03.dsc | 12 ++- Platform/Hisilicon/D03/D03.fdf | 4 +- Platform/Hisilicon/D03/Library/FdtUpdateLib/FdtUpdateLib.inf | 2 +- Platform/Hisilicon/D05/D05.dsc | 83 +++++++++-------- Platform/Hisilicon/D05/D05.fdf | 4 +- Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.inf | 2 +- Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.inf | 2 +- Platform/Hisilicon/D05/Library/PlatformPciLib/PlatformPciLib.inf | 2 +- Silicon/Hisilicon/Drivers/PciHostBridgeDxe/PciHostBridge.c | 38 ++++---- Silicon/Hisilicon/Drivers/PciHostBridgeDxe/PciHostBridge.h | 7 ++ Silicon/Hisilicon/Drivers/PciHostBridgeDxe/PciRootBridgeIo.c | 94 +++++++++++++++++++- Silicon/Hisilicon/Hi1610/Drivers/IoInitDxe/IoInitDxe.inf | 2 +- Silicon/Hisilicon/Hi1610/Drivers/PcieInit1610/PcieInitDxe.inf | 3 +- Silicon/Hisilicon/Hi1610/Drivers/PcieInit1610/PcieInitLib.c | 50 ----------- Silicon/Hisilicon/Hi1616/D05AcpiTables/Dsdt/D05I2c.asl | 20 +---- Silicon/Hisilicon/Hi1616/D05AcpiTables/Dsdt/D05Pci.asl | 8 +- Silicon/Hisilicon/Hi1616/D05AcpiTables/Dsdt/D05Sas.asl | 10 +++ Silicon/Hisilicon/HisiPkg.dec | 1 - Silicon/Hisilicon/Library/DS3231RealTimeClockLib/DS3231RealTimeClockLib.inf | 2 +- Silicon/Hisilicon/Library/Dw8250SerialPortLib/Dw8250SerialPortLib.inf | 2 +- Silicon/Hisilicon/Library/I2CLib/I2CLib.inf | 2 +- Silicon/Hisilicon/Library/I2CLib/I2CLibRuntime.inf | 2 +- 26 files changed, 203 insertions(+), 157 deletions(-) -- 1.9.1

7 years, 6 months

[PATCH edk2-non-osi v5 00/10] Update D03/D05 binary for edk2 update and bug fix

by Heyi Guo

Code can also be found in github: https://github.com/hisilicon/OpenPlatformPkg.git branch: rp-1710-osi-v5 Heyi Guo (5): Hisilicon/D03/Net: Update Snp driver Hisilicon/D03/Sas: Add SasPlatform Hisilicon/D05/Net: Update Snp driver Hisilicon/D05/Sas: Add SasPlatform Hisilicon: Fix the drivers use the same GUID issue Ming Huang (5): Hisilicon/D03: Update binary file Hisilicon/D03: Update Trusted Firmware binary Hisilicon/D05: Update binary file Hisilicon/D05: Update Trusted Firmware binary Hisilicon/D05: Fix occasional system hang bug Platform/Hisilicon/D02/Drivers/Net/SnpPV600Dxe/SnpPV600Dxe.inf | 2 +- Platform/Hisilicon/D02/Drivers/SFC/SfcDxeDriver.inf | 2 +- Platform/Hisilicon/D02/MemoryInitPei/MemoryInitPeim.inf | 2 +- Platform/Hisilicon/D03/Drivers/GetInfoFromBmc/GetInfoFromBmc.efi | Bin 21696 -> 4768 bytes Platform/Hisilicon/D03/Drivers/Ipmi/IpmiInterfacePei/IpmiInterfacePei.efi | Bin 22208 -> 4672 bytes Platform/Hisilicon/D03/Drivers/Ipmi/ipmiInterfaceDxe/IpmiInterfaceDxe.efi | Bin 25440 -> 6784 bytes Platform/Hisilicon/D03/Drivers/IpmiMiscOpDxe/IpmiMiscOp.efi | Bin 23712 -> 4896 bytes Platform/Hisilicon/D03/Drivers/IpmiWatchdogDxe/IpmiWatchdogDxe.efi | Bin 18080 -> 2304 bytes Platform/Hisilicon/D03/Drivers/Net/SnpPV600Dxe/SnpPV600Dxe.efi | Bin 0 -> 26688 bytes Platform/Hisilicon/D03/Drivers/Net/SnpPV600Dxe/SnpPV600Dxe.inf | 24 +++++++++++++++++ Platform/Hisilicon/D03/Drivers/Net/SnpPV660Dxe/SnpPV600Dxe.efi | Bin 56832 -> 0 bytes Platform/Hisilicon/D03/Drivers/Net/SnpPV660Dxe/SnpPV600Dxe.inf | 27 -------------------- Platform/Hisilicon/D03/Drivers/Net/SnpPlatform/SnpPlatform.efi | Bin 0 -> 3040 bytes Platform/Hisilicon/D03/Drivers/Net/SnpPlatform/SnpPlatform.inf | 24 +++++++++++++++++ Platform/Hisilicon/D03/Drivers/OhciDxe/NativeOhci.efi | Bin 48352 -> 21664 bytes Platform/Hisilicon/D03/Drivers/ReportPciePlugDidVidToBmc/ReportPciePlugDidVidToBmc.efi | Bin 22112 -> 3712 bytes Platform/Hisilicon/D03/Drivers/SFC/SFCDriver.efi | Bin 262144 -> 262144 bytes Platform/Hisilicon/D03/Drivers/Sas/SasDriverDxe.efi | Bin 208288 -> 98144 bytes Platform/Hisilicon/D03/Drivers/SasPlatform/SasPlatform.efi | Bin 0 -> 3040 bytes Platform/Hisilicon/D03/Drivers/SasPlatform/SasPlatform.inf | 24 +++++++++++++++++ Platform/Hisilicon/D03/Drivers/Sm750Dxe/SmiGraphicsOutput.efi | Bin 36480 -> 17728 bytes Platform/Hisilicon/D03/Drivers/TransferSmbiosInfo/TransSmbiosInfo.efi | Bin 21408 -> 4000 bytes Platform/Hisilicon/D03/Library/OemAddressMap2P/OemAddressMap2P.lib | Bin 19486 -> 20550 bytes Platform/Hisilicon/D03/MemoryInitPei/MemoryInit.efi | Bin 161280 -> 90272 bytes Platform/Hisilicon/D03/Sec/FVMAIN_SEC.Fv | Bin 262144 -> 262144 bytes Platform/Hisilicon/D03/bl1.bin | Bin 14336 -> 14336 bytes Platform/Hisilicon/D03/fip.bin | Bin 45601 -> 62513 bytes Platform/Hisilicon/D05/Drivers/GetInfoFromBmc/GetInfoFromBmc.efi | Bin 19552 -> 5024 bytes Platform/Hisilicon/D05/Drivers/GetInfoFromBmc/GetInfoFromBmc.inf | 2 +- Platform/Hisilicon/D05/Drivers/Ipmi/IpmiInterfaceDxe/IpmiInterfaceDxe.efi | Bin 25696 -> 7680 bytes Platform/Hisilicon/D05/Drivers/Ipmi/IpmiInterfaceDxe/IpmiInterfaceDxe.inf | 2 +- Platform/Hisilicon/D05/Drivers/Ipmi/IpmiInterfacePei/IpmiInterfacePei.efi | Bin 22528 -> 5344 bytes Platform/Hisilicon/D05/Drivers/Ipmi/IpmiInterfacePei/IpmiInterfacePei.inf | 2 +- Platform/Hisilicon/D05/Drivers/IpmiMiscOpDxe/IpmiMiscOp.efi | Bin 23136 -> 5280 bytes Platform/Hisilicon/D05/Drivers/IpmiMiscOpDxe/IpmiMiscOpDxe.inf | 2 +- Platform/Hisilicon/D05/Drivers/IpmiWatchdogDxe/IpmiWatchdogDxe.efi | Bin 15968 -> 2592 bytes Platform/Hisilicon/D05/Drivers/IpmiWatchdogDxe/IpmiWatchdogDxe.inf | 2 +- Platform/Hisilicon/D05/Drivers/Net/SnpPV600Dxe/SnpPV600Dxe.efi | Bin 0 -> 28544 bytes Platform/Hisilicon/D05/Drivers/Net/SnpPV600Dxe/SnpPV600Dxe.inf | 24 +++++++++++++++++ Platform/Hisilicon/D05/Drivers/Net/SnpPV660Dxe/SnpPV600Dxe.efi | Bin 56512 -> 0 bytes Platform/Hisilicon/D05/Drivers/Net/SnpPV660Dxe/SnpPV600Dxe.inf | 27 -------------------- Platform/Hisilicon/D05/Drivers/Net/SnpPlatform/SnpPlatform.efi | Bin 0 -> 3392 bytes Platform/Hisilicon/D05/Drivers/Net/SnpPlatform/SnpPlatform.inf | 24 +++++++++++++++++ Platform/Hisilicon/D05/Drivers/OhciDxe/NativeOhci.efi | Bin 48000 -> 23328 bytes Platform/Hisilicon/D05/Drivers/OhciDxe/OhciDxe.inf | 2 +- Platform/Hisilicon/D05/Drivers/ReportPciePlugDidVidToBmc/ReportPciePlugDidVidToBmc.efi | Bin 21536 -> 4032 bytes Platform/Hisilicon/D05/Drivers/ReportPciePlugDidVidToBmc/ReportPciePlugDidVidToBmc.inf | 2 +- Platform/Hisilicon/D05/Drivers/SFC/SFCDriver.efi | Bin 262144 -> 262144 bytes Platform/Hisilicon/D05/Drivers/SFC/SfcDxeDriver.inf | 2 +- Platform/Hisilicon/D05/Drivers/Sas/SasDriverDxe.efi | Bin 230912 -> 116288 bytes Platform/Hisilicon/D05/Drivers/Sas/SasDxeDriver.inf | 2 +- Platform/Hisilicon/D05/Drivers/SasPlatform/SasPlatform.efi | Bin 0 -> 3424 bytes Platform/Hisilicon/D05/Drivers/SasPlatform/SasPlatform.inf | 24 +++++++++++++++++ Platform/Hisilicon/D05/Drivers/Sm750Dxe/SmiGraphicsOutput.efi | Bin 35904 -> 18592 bytes Platform/Hisilicon/D05/Drivers/Sm750Dxe/UefiSmi.inf | 2 +- Platform/Hisilicon/D05/Drivers/TransferSmbiosInfo/TransSmbiosInfo.efi | Bin 16576 -> 4288 bytes Platform/Hisilicon/D05/Drivers/TransferSmbiosInfo/TransSmbiosInfo.inf | 2 +- Platform/Hisilicon/D05/Library/OemAddressMapD05/OemAddressMapD05.inf | 2 +- Platform/Hisilicon/D05/Library/OemAddressMapD05/OemAddressMapD05.lib | Bin 42136 -> 52968 bytes Platform/Hisilicon/D05/MemoryInitPei/MemoryInit.efi | Bin 273312 -> 152576 bytes Platform/Hisilicon/D05/MemoryInitPei/MemoryInitPeim.inf | 2 +- Platform/Hisilicon/D05/Sec/FVMAIN_SEC.Fv | Bin 262144 -> 262144 bytes Platform/Hisilicon/D05/bl1.bin | Bin 12296 -> 14344 bytes Platform/Hisilicon/D05/fip.bin | Bin 41493 -> 41493 bytes Silicon/Hisilicon/Hi1610/Library/Hi1610Serdes/Hi1610SerdesLib.inf | 2 +- Silicon/Hisilicon/Hi1610/Library/Hi1610Serdes/Hi1610SerdesLib.lib | Bin 603524 -> 587188 bytes Silicon/Hisilicon/Hi1610/Library/IpmiCmdLib/IpmiCmdLib.lib | Bin 247176 -> 210280 bytes Silicon/Hisilicon/Hi1610/Library/LpcLib/LpcLib.inf | 2 +- Silicon/Hisilicon/Hi1610/Library/LpcLib/LpcLib.lib | Bin 13998 -> 13958 bytes Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.inf | 2 +- Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib | Bin 305230 -> 297590 bytes Silicon/Hisilicon/Hi1610/Library/Uart/LpcSerialPortLib/LpcSerialPortLib.lib | Bin 17022 -> 16942 bytes Silicon/Hisilicon/Hi1616/Library/Hi1616Serdes/Hi1616SerdesLib.inf | 2 +- Silicon/Hisilicon/Hi1616/Library/Hi1616Serdes/Hi1616SerdesLib.lib | Bin 707246 -> 726884 bytes Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib | Bin 358602 -> 344310 bytes Silicon/Hisilicon/Pv660/Library/PlatformSysCtrlLibPv660/PlatformSysCtrlLibPv660.inf | 2 +- Silicon/Hisilicon/Pv660/Library/Pv660Serdes/Pv660SerdesLib.inf | 2 +- 77 files changed, 166 insertions(+), 76 deletions(-) create mode 100644 Platform/Hisilicon/D03/Drivers/Net/SnpPV600Dxe/SnpPV600Dxe.efi create mode 100644 Platform/Hisilicon/D03/Drivers/Net/SnpPV600Dxe/SnpPV600Dxe.inf delete mode 100644 Platform/Hisilicon/D03/Drivers/Net/SnpPV660Dxe/SnpPV600Dxe.efi delete mode 100644 Platform/Hisilicon/D03/Drivers/Net/SnpPV660Dxe/SnpPV600Dxe.inf create mode 100644 Platform/Hisilicon/D03/Drivers/Net/SnpPlatform/SnpPlatform.efi create mode 100644 Platform/Hisilicon/D03/Drivers/Net/SnpPlatform/SnpPlatform.inf create mode 100644 Platform/Hisilicon/D03/Drivers/SasPlatform/SasPlatform.efi create mode 100644 Platform/Hisilicon/D03/Drivers/SasPlatform/SasPlatform.inf create mode 100644 Platform/Hisilicon/D05/Drivers/Net/SnpPV600Dxe/SnpPV600Dxe.efi create mode 100644 Platform/Hisilicon/D05/Drivers/Net/SnpPV600Dxe/SnpPV600Dxe.inf delete mode 100644 Platform/Hisilicon/D05/Drivers/Net/SnpPV660Dxe/SnpPV600Dxe.efi delete mode 100644 Platform/Hisilicon/D05/Drivers/Net/SnpPV660Dxe/SnpPV600Dxe.inf create mode 100644 Platform/Hisilicon/D05/Drivers/Net/SnpPlatform/SnpPlatform.efi create mode 100644 Platform/Hisilicon/D05/Drivers/Net/SnpPlatform/SnpPlatform.inf create mode 100644 Platform/Hisilicon/D05/Drivers/SasPlatform/SasPlatform.efi create mode 100644 Platform/Hisilicon/D05/Drivers/SasPlatform/SasPlatform.inf -- 1.9.1

7 years, 6 months

Re: [Linaro-uefi] Issue for BEAGLE BONE BLACK - bootup with UEFI

by Leif Lindholm

Adding linaro-uefi(a)lists.linaro.org, which is the more appropriate mailing list for this topic. On Mon, May 22, 2017 at 04:44:00PM +0530, Mohan Rao .vanimina wrote: > When trying to boot-up BeagleBoneBlack Platform using UEFI with below > procedure (instead of U-boot), ran into following issue. > > Followed Web link : > https://github.com/tianocore/tianocore.github.io/wiki/BeagleBoardPkg#Beagle… > > > I had a doubt on the provided git repository in this procedure. Does this > repo supports BeagelBoneBlack Platform? I am afraid this documentation is very outdated. > *Error when Tried in Qemu: * > EhcCreateUsb2Hc: capability length 0 > EhcDriverBindingStart: failed to create USB2_HC > ERROR: Did not find Linux kernel. > [1] Linux from SD > - > VenHw(B615F1F5-5088-43CD-809C-A16E52487D00)/HD(1,MBR,0x00000000,0x3F,0x19FC0)/zImage > - Arguments: console=tty0 console=ttyS2,115200n8 > root=UUID=a4af765b-c2b5-48f4-9564-7a4e9104c4f6 rootwait ro earlyprintk > - LoaderType: Linux kernel with ATAG support > [2] Shell > [3] Boot Manager And the above messages have not been possible to reproduce with an upstream edk2 build for a long time. So what repository are you using? I also do not see beaglebone black supported by upstream qemu? > Start: qemu: terminating on signal 2 > > *Error ; sd Card : **DATA abort Error coming when tried booting thru > sd-card* > > Could you please help in debug this issue? Short answer is that BeagleBoardPkg in edk2 contains the platform support for the original BeagleBoard. There was a port to BeagleBone Black done as part of Google Summer of Code 2014 by Varad Gautam, but that has not been upstreamed. I am planning to do that once BeagleBoardPkg and Omap35xxPkg have been migrated to edk2-platforms. / Leif

7 years, 6 months

← Newer
1
...
9
10
11
12
13
14
15
...
82
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Linaro-uefi