From: Yan Zhang <zhangyan81(a)huawei.com>
Assign valid value to AddressTranslationOffset to support
address translation between domains of CPU and PCIe, which
is need by GOP to enable frame buffer.
This patch fix the bug:
Kernel (4.12, without the vga driver) boot hang with kernel panic
while kernel accesses UEFI GOP frame buffer.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yan Zhang <zhangyan81(a)huawei.com>
Signed-off-by: Ming Huang <huangming23(a)huawei.com>
Signed-off-by: Heyi Guo <heyi.guo(a)linaro.org>
---
Silicon/Hisilicon/Drivers/PciHostBridgeDxe/PciRootBridgeIo.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/Silicon/Hisilicon/Drivers/PciHostBridgeDxe/PciRootBridgeIo.c b/Silicon/Hisilicon/Drivers/PciHostBridgeDxe/PciRootBridgeIo.c
index b57bd51..55b80aa 100644
--- a/Silicon/Hisilicon/Drivers/PciHostBridgeDxe/PciRootBridgeIo.c
+++ b/Silicon/Hisilicon/Drivers/PciHostBridgeDxe/PciRootBridgeIo.c
@@ -2316,6 +2316,7 @@ RootBridgeIoConfiguration (
}
Configuration.SpaceDesp[Index].AddrRangeMax = Configuration.SpaceDesp[Index].AddrRangeMin + PrivateData->ResAllocNode[Index].Length - 1;
Configuration.SpaceDesp[Index].AddrLen = PrivateData->ResAllocNode[Index].Length;
+ Configuration.SpaceDesp[Index].AddrTranslationOffset = PrivateData->MemBase - PrivateData->PciRegionBase;
}
}
--
1.9.1
hikey is now supported in upstream atf, i.e.
https://github.com/ARM-software/arm-trusted-firmware
but the way the OP-TEE binary is loaded differs from
https://github.com/96boards-hikey/arm-trusted-firmware
so add a note to inform users about setting a different TOS_BIN when
using upstream atf, otherwise firmware boot will hang.
Signed-off-by: Victor Chong <victor.chong(a)linaro.org>
---
platforms.config | 3 +++
1 file changed, 3 insertions(+)
diff --git a/platforms.config b/platforms.config
index 6d3abff..deb02f4 100644
--- a/platforms.config
+++ b/platforms.config
@@ -194,6 +194,9 @@ PACKAGES_PATH=OpenPlatformPkg/Platforms/AMD/Styx/Binary
UEFI_BIN=STYX_ROM.fd
UEFI_IMAGE_DIR=Cello
+# NOTE: If using upstream ATF, i.e.
+# https://github.com/ARM-software/arm-trusted-firmware
+# please set TOS_BIN=tee-pager.bin
[hikey]
LONGNAME=CircuitCo HiKey
DSC=OpenPlatformPkg/Platforms/Hisilicon/HiKey/HiKey.dsc
--
2.13.0
Hi
After power-on the system, from default UEFI shell prompt, then moving to
FS0:>, I execute a uefi application (bootx64.efi) which starts image by
calling 'Shell.efi' image. But shell.efi doesn't calls FS0:\startup.nsh.
I understood 'EFI/BOOT/startup.nsh' is called on booting the system if it
boots through UEFI shell.
But my scenario to write the UEFI C code (bootx64.c) which supports gnu-efi
(3.0.6) libraries from USB mass storage (i.e. first boot) which calls
Shell.efi with FS0:\startup.nsh.
Shell.efi is from EDK2
Please let me know to achieve this using gnu-efi other than EDK2. Since
EDK2 development environment is tough to understand quickly.
Thank & Regards
Manjunatha Srinivasan N
Without the PCD for the second SATA Controller being specified, the boot
will hang. These patches fix it.
Alan Ott (3):
Silicon/AMD/Styx: Make PcdSataPortMode 32 bits
Silicon/AMD/Styx: Use PcdSataPortMode properly for two controllers
Platform/AMD/OverdriveBoard: Re-enable the second SATA Controller
Platform/AMD/OverdriveBoard/OverdriveBoard.dsc | 10 +++-------
Silicon/AMD/Styx/AmdStyx.dec | 2 +-
.../AMD/Styx/Drivers/StyxSataPlatformDxe/InitController.c | 13 +++++++++----
3 files changed, 13 insertions(+), 12 deletions(-)
--
2.9.3
Without the PCD for the second SATA Controller being specified, the boot
will hang. These patches fix it.
Alan Ott (2):
Silicon/AMD/Styx: Make PcdSataPortMode 32 bits
Platform/AMD/OverdriveBoard: Re-enable the second SATA Controller
Platform/AMD/OverdriveBoard/OverdriveBoard.dsc | 10 +++-------
Silicon/AMD/Styx/AmdStyx.dec | 2 +-
Silicon/AMD/Styx/Drivers/StyxSataPlatformDxe/InitController.c | 4 ++--
3 files changed, 6 insertions(+), 10 deletions(-)
--
2.9.3