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
Oh dear...
Adding linaro-toolchain(a)lists.linaro.org to see what they have to say
(and linaro-uefi, because it's useful information for subscribers of that).
Regards,
Leif
On Tue, Feb 21, 2017 at 08:09:53PM +0000, Evan Lloyd wrote:
> To add to Alexei's comments:
> It seems there is a bug in the newer GCC Pre-processor that messes with the file case.
> (He is currently checking what file system flags might be affecting that, but older versions work fine).
>
> The questions I'd add are:
> Is there someone in Linaro who we might discuss the problem with (on the GCC side)? I think there are Linaro guys involved with it, and they may be able to tell us it is confusion on our part.
> Should we be trying to upstream the fix, or just wait for a new GCC?
>
> Regards,
> Evan
>
>
>
> From: Alexei Fedorov
> Sent: 21 February 2017 16:37
> To: ard.biesheuvel(a)linaro.org; ryan.harkin(a)linaro.org; leif.lindholm(a)linaro.org; Evan Lloyd; Sami Mujawar; Girish Pathak
> Cc: Mitch Ishihara; Alexei Fedorov
> Subject: Problem with building AML file from Dsdt.asl for Juno
>
>
> Hello,
>
>
>
> We are facing a problem when compiling Juno's Dsdt.asl file with the following GCC builds:
>
>
>
> gcc-linaro-5.3.1-2016.05-i686-mingw32_aarch64-elf
>
> gcc-linaro-6.1.1-2016.08-i686-mingw32_aarch64-elf
>
> gcc-linaro-6.2.1-2016.11-i686-mingw32_aarch64-elf
>
> gcc-linaro-6.3.1-2017.02-i686-mingw32_aarch64-elf
>
>
>
> which all show a similar error:
>
>
>
> ...
> Trim --source-code -l -o k:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT\.\Dsdt.iiii k:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT\.\Dsdt.iii
> "C:\ASL\iasl" -pk:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT\.\Dsdt.aml k:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT\.\Dsdt.iiii
> Error 6126 - Input file does not appear to be an ASL or data table source file
> Intel ACPI Component Architecture
> make: *** [Makefile:325: k:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT\Dsdt.aml] Error -1
>
>
>
> It looks like the problem is with GCC pre-processor running on Dsdt.i file (created after
>
> Trim --asl-file -o k:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT\.\Dsdt.i -i k:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT\inc.lst k:\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\Dsdt.asl
>
> )
>
>
>
> See:
>
>
> "C:\gcc-linaro-6.3.1-2017.02-i686-mingw32_aarch64-elf\bin\aarch64-elf-gcc" -x c -E -include AutoGen.h -Ik:\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables -Ik:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\DEBUG -Ik:\ArmPkg -Ik:\ArmPkg\Include -Ik:\ArmPlatformPkg -Ik:\ArmPlatformPkg\Include -Ik:\ArmPlatformPkg\ArmVExpressPkg -Ik:\ArmPlatformPkg\ArmVExpressPkg\Include -Ik:\ArmPlatformPkg\ArmJunoPkg -Ik:\ArmPlatformPkg\ArmJunoPkg\Include -Ik:\EmbeddedPkg -Ik:\EmbeddedPkg\Include -Ik:\MdePkg -Ik:\MdePkg\Include -Ik:\MdePkg\Include\AArch64 -Ik:\MdeModulePkg -Ik:\MdeModulePkg\Include -Ik:\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTablesk:\Build\ArmJuno\DEBUG_GCC5AARCH64OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT\.\Dsdt.i > k:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT\.\Dsdt.iii
>
>
>
> For all GCC versions above, the 1st line of Dsdt.iii lists its name & full path in lowercase:
>
> # 1 "k:\\build\\armjuno\\debug_gcc5\\aarch64\\openplatformpkg\\platforms\\arm\\juno\\acpitables\\acpitables\\output\\dsdt.i"
>
>
>
> Compare it with Dsdt.iii after pre-processing by GCC from gcc-linaro-4.9.4-2017.01-i686-mingw32_aarch64-elf release:
>
> # 1 "k:\\Build\\ArmJuno\\DEBUG_GCC49\\AARCH64\\OpenPlatformPkg\\Platforms\\ARM\\Juno\\AcpiTables\\AcpiTables\\OUTPUT\\.\\Dsdt.i"
>
>
>
> For GCC 5.3.1 & above Dsdt.iiii created by
>
> Trim --source-code -l -o k:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT\.\Dsdt.iiii k:\Build\ArmJuno\DEBUG_GCC5\AARCH64\OpenPlatformPkg\Platforms\ARM\Juno\AcpiTables\AcpiTables\OUTPUT\.\Dsdt.iii
>
>
>
> has 0 length, which causes iASL compiler to fail with:
>
> Error 6126 - Input file does not appear to be an ASL or data table source file
>
>
>
> We've got a workaround solution for that problem which involves modification of \BaseTools\Conf\build_rule.template:
>
>
>
> In ASL section:
> [Acpi-Source-Language-File]
> <InputFile>
> ?.asl, ?.Asl, ?.ASL
>
>
>
> by replacing 3 lines as below:
>
>
> <Command.GCC, Command.GCCLD>
> # Trim --asl-file -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.i -i $(INC_LIST) ${src}
> # "$(ASLPP)" $(ASLPP_FLAGS) $(INC) -I${s_path} $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.i > $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iii
> # Trim --source-code -l -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iiii $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iii
> "$(ASLPP)" $(ASLPP_FLAGS) $(INC) -I${s_path} ${src} > $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.i
> Trim --source-code -l -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iiii $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.I
>
>
>
> Please share your opinion on that matter.
>
>
>
> Alexei.
>
>
>
>
>
>
>
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
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.
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
Hi folks,
It seems there is no code to enable stack alignment check in EDK2, while
it is required to be enabled according to UEFI spec v2.6, section 2.3.6,
page 38.
Shall we find somewhere to enable SA?
Thanks and regards,
Gary (Heyi Guo)
