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