From: heyi.guo <guoheyi(a)huawei.com>
This patch resolves the issue 2393: https://bugs.linaro.org.
The cdb16 command should be used if the hard disk size larger than 4TB.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chenhui Sun <sunchenhui(a)huawei.com>
Signed-off-by: Jason Zhang <zhangjinsong2(a)huawei.com>
---
.../Binary/D03/Drivers/Sas/SasDriverDxe.efi | Bin 210752 -> 208288 bytes
.../Binary/D05/Drivers/Sas/SasDriverDxe.efi | Bin 210400 -> 230912 bytes
2 files changed, 0 insertions(+), 0 deletions(-)
diff --git a/Platforms/Hisilicon/Binary/D03/Drivers/Sas/SasDriverDxe.efi b/Platforms/Hisilicon/Binary/D03/Drivers/Sas/SasDriverDxe.efi
index b956b19..19cd038 100644
Binary files a/Platforms/Hisilicon/Binary/D03/Drivers/Sas/SasDriverDxe.efi and b/Platforms/Hisilicon/Binary/D03/Drivers/Sas/SasDriverDxe.efi differ
diff --git a/Platforms/Hisilicon/Binary/D05/Drivers/Sas/SasDriverDxe.efi b/Platforms/Hisilicon/Binary/D05/Drivers/Sas/SasDriverDxe.efi
index 6021d12..8d9ecd2 100644
Binary files a/Platforms/Hisilicon/Binary/D05/Drivers/Sas/SasDriverDxe.efi and b/Platforms/Hisilicon/Binary/D05/Drivers/Sas/SasDriverDxe.efi differ
--
1.9.1
From: Achin Gupta <achin.gupta(a)arm.com>
This patchset adds support for creating a MM Standalone image suitable for
running on a Base FVP in the AArch64 execution state.
The core support for instantiating MM Standalone mode is being developed in the
following edk2-staging branch:
https://github.com/tianocore/edk2-staging/tree/AArch64StandaloneMm
This branch and the patchset should be combined to build a MM Standalone
image. The instructions for this will be updated in edk2-staging later.
The changes in this series are aimed at:
1. partitioning DRAM to set aside memory for the MM Standalone image
2. including the necessary modules to instantiate the Standalone MM on the Base
FVP
This patchset should be staged in a separate branch until it is clearer how the
MM Standalone image should be supported on common ARM platforms. The name of the
branch should be the same as the edk2-staging branch i.e. AArch64StandaloneMm.
Changelog since v1:
- Introduced ARM_STANDALONE_MM_ENABLE define to encapsulate changes introduced
in this series
Achin Gupta (4):
Platforms/ARM/VExpress: Size DRAM to accommodate Standalone MM image
Platforms/ARM/VExpress: Define extents of MM communication buffer
Platforms/ARM/VExpress: Include MM communication protocol driver
Platforms/ARM/VExpress: Include UEFI Info application in FVP build
Platforms/ARM/VExpress/ArmVExpress-FVP-AArch64.dsc | 19 +++++++++++++++++++
Platforms/ARM/VExpress/ArmVExpress-FVP-AArch64.fdf | 6 ++++++
2 files changed, 25 insertions(+)
--
1.9.1
Hi everyone,
I'd like to know if there's a way to hide SimpleFileSystem instance from
boot entries?
Currently we have some entries that are known to be sure not bootable (used
only for configuration purposes) and we don't want to expose them to user.
Thanks in advance.
Best regards,
Konrad Adamczyk
Hi ,all
In the progress of UEFI porting, I had a big problem. The function GicV2DxeInitialize in ArmGicDxe.inf module produced a Synchronous Exception, when it executed MmioRead32 (mGicDistributorBase + ARM_GIC_ICDICTR). And I am also using GIC400. The GICD&GICC register base have been set correctly. Strangely enough, the MmioRead32 (mGicDistributorBase + ARM_GIC_ICDICTR) code can be executed successfully in Arm trusted firmware which is the previous stage of UEFI. And also, I tried to use a evaluation to analysis the exception and got the following error message.
[cid:image001.png@01D25C42.2B95A4F0]
I don't know whether the ArmGicDxe.inf module must be executed in a particular environment which have not been set correctly in the previous module of UEFI? By the way, I'm using dependency expression way to dispatch the DXE drivers on Poplar board. I don't know the main cause of this problem and how to solve it. Can you give me some advises?
Best Regards,
Wengang