Hi folks,
I can see Linaro is Linux oriented, but most of my colleagues are much
more familiar with Windows and Source Insight, rather than Linux and
vim/emacs. We may be happier and more effective if we can build aarch64
UEFI on Windows directly.
So how can we do that? Is there any detailed guideline?
Thanks and regards,
Gary (Heyi Guo)
This cleans up some dodgy code in the SMBIOS driver, after which it is
possible to enable the shiny new memory protection controls.
Changes since v1:
- enable on Cello as well as Overdrive, I will leave it up to Alan whether
this gets enabled on the Overdrive 1000 as well
- simplify patch #1
Note that the prerequisite EDK2 changes have now been merged.
Ard Biesheuvel (4):
Platforms/AMD/Styx/PlatformSmbiosDxe: don't write to string literals
Platforms/AMD/Styx: constify/staticize all local functions and
variables
Platforms/AMD/Overdrive: enable strict memory permission policy
Platforms/AMD/Cello: enable strict memory permission policy
Platforms/AMD/Styx/CelloBoard/CelloBoard.dsc | 16 ++++
Platforms/AMD/Styx/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c | 79 +++++++++++---------
Platforms/AMD/Styx/OverdriveBoard/OverdriveBoard.dsc | 16 ++++
3 files changed, 74 insertions(+), 37 deletions(-)
--
2.7.4
The SiI isn't an AHCI compatible adapter so it implements the EFI ATA
pass-through protocol directly. This works for fixed hard drives, but
not ATAPI attached devices (CDROM, DVDROM, TAPE, etc).
This patch adds read only ATAPI support via the EFI SCSI pass-through
protocol, allowing boot from attached CD/DVD. This patch also cleans
up, and tweaks recovery paths/etc in the original driver. When
combined with the ARM/PCI dma lib changes this allows us to relax the
IO alignment requirement that caused grub failures.
Finally, the OpenPlatformPkg/Juno must be updated, with another patch
to avoid build breaks now that the SiI has a dependency on the SCSI
libraries.
V2->V3:
Send the correct patch, rather than the one I was running
the patch checker against.
V1->V2:
Formatting corrections per Ard's comments and Daniil's
updated patch checker.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeremy Linton <jeremy.linton(a)arm.com>
Jeremy Linton (7):
EmbeddedPkg: SiI3132: Note that ARM is using this Dxe
MdePkg IndustryStandard/Scsi.h: Add sense code macro
EmbeddedPkg: SiI3132: Add ScsiProtocol callbacks
EmbeddedPkg: SiI3132: Add SCSI protocol support to header
EmbeddedPkg: SiI3132: Break out FIS command submission
EmbeddedPkg: SiI3132: Cleanup device node creation
EmbeddedPkg: SiI3132: Enable SCSI pass-through protocol
EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.c | 49 ++-
EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h | 93 ++++-
.../Drivers/SataSiI3132Dxe/SataSiI3132Dxe.inf | 2 +
.../Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c | 268 ++++++++-----
.../Drivers/SataSiI3132Dxe/SiI3132ScsiPassThru.c | 431 +++++++++++++++++++++
MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf | 2 +-
MdePkg/Include/IndustryStandard/Scsi.h | 2 +
OpenPlatformPkg | 2 +-
8 files changed, 721 insertions(+), 128 deletions(-)
create mode 100644 EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132ScsiPassThru.c
--
2.9.3
From: Heyi Guo <heyi.guo(a)linaro.org>
We need to rebuild FVMAIN_SEC.fv after enlarging FVMAIN_COMPACT,
because the fv size and trustfirmware located base address changed.
Signed-off-by: Chenhui Sun <sunchenhui(a)huawei.com>
---
Platforms/Hisilicon/Binary/D02/Sec/FVMAIN_SEC.Fv | Bin 262144 -> 262144 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
diff --git a/Platforms/Hisilicon/Binary/D02/Sec/FVMAIN_SEC.Fv b/Platforms/Hisilicon/Binary/D02/Sec/FVMAIN_SEC.Fv
index bac8767..49b61aa 100644
Binary files a/Platforms/Hisilicon/Binary/D02/Sec/FVMAIN_SEC.Fv and b/Platforms/Hisilicon/Binary/D02/Sec/FVMAIN_SEC.Fv differ
--
1.9.1
Hi ,all
Lately I've been having a problem when I tried to boot kernel from EMMC.
GUID Partition Table is the basic essentials for UEFI and must be stored
on the device before power on;It has two header structures:the primary
and the backup.The primary GPT Header must be located in LBA 1 (i.e.,
the second logical block of EMMC), which is also the storage place of
Bootloader, and the backup GPT Header must be located in the last LBA of
the device. Therefore,there is a conflict between GPT and Bootloader in
the storage. The boot architecture on Poplar board can be described as
follows:
BootRom-->Bootloader-->ATF-->UEFI-->Kernel.
The Bootloader can be viewed as the BL1 stage of the ATF image;So it's a
basic essential either.
In some date manual we can get that the EMMC device is composed of five
parts:BOOT Area Partition 1,BOOT Area Partition 2,RPMB,User Data Area
and Vender private area.Hikey did not flash its fastboot into User Data
Area where Poplar flased. I have asked our BootRom engineers but got a
negative result:BootRom only can recognize the Bootloader in the start
address of User Data Area on Poplar board where GPT must be placed to.
Therefor, how to solve the conflicts between GPT and Bootloader is
really a thorny problem.
I have asked several people for help,and got two methods as follows:
#1.Use the backup GPT Header.
In the GPT chapter of the UEFI Spec2.6 I read some useful
information.Firstly,the backup GPT Partition Entry Array must be located
after the Last Usable LBA and end before the backup GPT
Header.Secondly,if the primary GPT is corrupt, software must check the
last LBA of the device to see if it has a valid GPT Header and point to
a valid GPT Partition Entry Array. If it points to a valid GPT Partition
Entry Array, then software should restore the primary GPT if allowed by
platform policy settings.If the primary GPT is invalid, the backup GPT
is used instead and it is located on the last logical
block on the disk.
On the base of the above,I only flashed the backup GPT to the
thirty-three block from the end. But the UEFI can't recognize the
backup GPT.So I don't know if the place where I store the backup GPT is
wrong?
#2.Add an offset when read or write block .
This method will reserve a 1M space for Bootloader at the start address
of EMMC. And the primary GPT will be placed in a start address of 1M.
We should add a 1M offset when we use the BlockIO functions to read or
write block devices.This method maybe need to modify the EDKII core
code;Honestly, I have not try this method.
How to solve the conflicts between GPT and Bootloader is really a thorny
problem for me.Can you give me some advises about this problem?
Best regards,
Wengang
This cleans up some dodgy code in the SMBIOS driver, after which it is
possible to enable the shiny new memory protection controls.
Note that these patches are still under review, so patch #3 cannot be
merged yet.
Ard Biesheuvel (3):
Platforms/AMD/Styx/PlatformSmbiosDxe: don't write to string literals
Platforms/AMD/Styx: constify/staticize all local functions and
variables
Platforms/AMD/Styx: enable strict memory permission policy
Platforms/AMD/Styx/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c | 87 ++++++++++++--------
Platforms/AMD/Styx/OverdriveBoard/OverdriveBoard.dsc | 15 ++++
2 files changed, 67 insertions(+), 35 deletions(-)
--
2.7.4