On Fri, Jul 20, 2012 at 4:12 PM, Jordan Justen <jljus...@gmail.com> wrote:
> On Wed, Jul 18, 2012 at 1:56 PM, Laszlo Ersek <ler...@redhat.com> wrote:
>> BDAT is allocated as EfiReservedMemoryType, with AllocateReservedPool().
>> <MdePkg/Include/Library/MemoryAllocationLib.h> doesn't seem to provide
>> direct access to EfiACPIReclaimMemory, but at this point the former seems
>> sufficient.
>>
>> Based on SeaBIOS commit 2062f2ba by Gerd Hoffmann <kra...@redhat.com>.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>>
>> Signed-off-by: Laszlo Ersek <ler...@redhat.com>
>> ---
>> OvmfPkg/AcpiPlatformDxe/Qemu.c | 102
>> ++++++++++++++++++++++++++++++++++++-
>> OvmfPkg/AcpiTables/AcpiTables.inf | 1 +
>> OvmfPkg/AcpiTables/Ssdt.asl | 15 +++++
>> 3 files changed, 117 insertions(+), 1 deletions(-)
>> create mode 100644 OvmfPkg/AcpiTables/Ssdt.asl
>>
>> diff --git a/OvmfPkg/AcpiPlatformDxe/Qemu.c b/OvmfPkg/AcpiPlatformDxe/Qemu.c
>> index f7736c2..2d3fa0e 100644
>> --- a/OvmfPkg/AcpiPlatformDxe/Qemu.c
>> +++ b/OvmfPkg/AcpiPlatformDxe/Qemu.c
>> @@ -10,7 +10,7 @@
>> THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
>> WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
>> IMPLIED.
>>
>> -**/
>> +**/
>>
>> #include "AcpiPlatform.h"
>> #include <Library/BaseMemoryLib.h>
>> @@ -98,6 +98,103 @@ QemuInstallAcpiMadtTable (
>> }
>>
>>
>> +struct BFLD {
>
> What is BFLD? Can you make this struct name longer?
>
>> + UINT64 P0S; // PCI window 0 (below 4g) - start
>> + UINT64 P0E; // PCI window 0 (below 4g) - end
>> + UINT64 P0L; // PCI window 0 (below 4g) - length
>> + UINT64 P1S; // PCI window 1 (above 4g) - start
>> + UINT64 P1E; // PCI window 1 (above 4g) - end
>> + UINT64 P1L; // PCI window 1 (above 4g) - length
>
> Same for these fields.
Answering my own comment... I see that these same fields need to named
in ASL, thus they must be short.
Can you add the same per field comments in the ASL in 5/5?
I still think the structure name can be improved.
-Jordan
>> +} __packed;
>
> We need to use #pragma pack(1) and then #pragma pack(). See other .h
> files in edk2...
>
>> +
>> +typedef struct BFLD BFLD;
>
> You could do typedef struct { } A_GOOD_NAME;
>
>> +
>> +
>> +STATIC
>> +EFI_STATUS
>> +EFIAPI
>> +PopulateBfld(
>> + OUT BFLD *Bfld
>> + )
>> +{
>> + return EFI_SUCCESS;
>> +}
>> +
>> +
>> +STATIC
>> +EFI_STATUS
>> +EFIAPI
>> +QemuInstallAcpiSsdtTable (
>> + IN EFI_ACPI_TABLE_PROTOCOL *AcpiProtocol,
>> + IN VOID *AcpiTableBuffer,
>> + IN UINTN AcpiTableBufferSize,
>> + OUT UINTN *TableKey
>> + )
>> +{
>> + EFI_STATUS Status;
>> + BFLD *Bfld;
>> +
>> + Status = EFI_OUT_OF_RESOURCES;
>> +
>> + Bfld = AllocateReservedPool (sizeof (*Bfld));
>> + if (Bfld != NULL) {
>> + UINTN SsdtSize;
>> + UINT8 *Ssdt;
>> +
>> + SsdtSize = AcpiTableBufferSize + 17;
>> + Ssdt = AllocatePool (SsdtSize);
>> +
>> + if (Ssdt != NULL) {
>> + Status = PopulateBfld (Bfld);
>> +
>> + if (Status == EFI_SUCCESS) {
>> + UINT8 *SsdtPtr;
>> +
>> + SsdtPtr = Ssdt;
>> +
>> + CopyMem (SsdtPtr, AcpiTableBuffer, AcpiTableBufferSize);
>> + SsdtPtr += AcpiTableBufferSize;
>> +
>> + //
>> + // build "OperationRegion(BDAT, SystemMemory, 0x12345678,
>> 0x87654321)"
>> + //
>> + *(SsdtPtr++) = 0x5B; // ExtOpPrefix
>> + *(SsdtPtr++) = 0x80; // OpRegionOp
>> + *(SsdtPtr++) = 'B';
>> + *(SsdtPtr++) = 'D';
>> + *(SsdtPtr++) = 'A';
>> + *(SsdtPtr++) = 'T';
>
> BDAT? Is that for BIOS Data? I understand the 4 char limit for ACPI,
> but what about using 'F' or 'FW' instead of B?
>
>> + *(SsdtPtr++) = 0x00; // SystemMemory
>> + *(SsdtPtr++) = 0x0C; // DWordPrefix
>> +
>> + //
>> + // no virtual addressing yet, take the four least significant bytes
>> + //
>> + CopyMem(SsdtPtr, &Bfld, 4);
>> + SsdtPtr += 4;
>> +
>> + *(SsdtPtr++) = 0x0C; // DWordPrefix
>> +
>> + *(UINT32*) SsdtPtr = sizeof (*Bfld);
>> + SsdtPtr += 4;
>> +
>> + ASSERT(SsdtPtr - Ssdt == SsdtSize);
>> + ((EFI_ACPI_DESCRIPTION_HEADER *) Ssdt)->Length = SsdtSize;
>> + Status = InstallAcpiTable (AcpiProtocol, Ssdt, SsdtSize, TableKey);
>> + }
>> +
>> + FreePool(Ssdt);
>> + }
>> +
>> + if (Status != EFI_SUCCESS) {
>> + FreePool(Bfld);
>> + }
>> + }
>> +
>> + return Status;
>> +}
>> +
>> +
>> EFI_STATUS
>> EFIAPI
>> QemuInstallAcpiTable (
>> @@ -115,6 +212,9 @@ QemuInstallAcpiTable (
>> case EFI_ACPI_1_0_APIC_SIGNATURE:
>> TableInstallFunction = QemuInstallAcpiMadtTable;
>> break;
>> + case EFI_ACPI_1_0_SECONDARY_SYSTEM_DESCRIPTION_TABLE_SIGNATURE:
>> + TableInstallFunction = QemuInstallAcpiSsdtTable;
>> + break;
>> default:
>> TableInstallFunction = InstallAcpiTable;
>> }
>> diff --git a/OvmfPkg/AcpiTables/AcpiTables.inf
>> b/OvmfPkg/AcpiTables/AcpiTables.inf
>> index 0f61df4..1187a14 100644
>> --- a/OvmfPkg/AcpiTables/AcpiTables.inf
>> +++ b/OvmfPkg/AcpiTables/AcpiTables.inf
>> @@ -33,6 +33,7 @@
>> Facp.aslc
>> Facs.aslc
>> Dsdt.asl
>> + Ssdt.asl
>>
>> [Packages]
>> MdePkg/MdePkg.dec
>> diff --git a/OvmfPkg/AcpiTables/Ssdt.asl b/OvmfPkg/AcpiTables/Ssdt.asl
>> new file mode 100644
>> index 0000000..4845ca8
>> --- /dev/null
>> +++ b/OvmfPkg/AcpiTables/Ssdt.asl
>> @@ -0,0 +1,15 @@
>> +/** @file
>> + Placeholder for runtime-generated objects.
>> +
>> + This empty table provides only a header for dynamic copying and extension,
>> + and a trigger for QemuInstallAcpiSsdtTable().
>> +
>> + Copyright Red Hat, Inc. 2012
>> +
>> + Author: Laszlo Ersek <ler...@redhat.com>
>> +
>> + This work is licensed under the terms of the GNU LGPL, version 2.1 or
>> later.
>
> As mentioned in the 0/5 thread, this will not work. Maybe look at the
> Dsdt.asl header?
>
>> +**/
>> +
>> +DefinitionBlock ("Ssdt.aml", "SSDT", 1, "REDHAT", "OVMF ", 1) {
>> +}
>> --
>> 1.7.1
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> edk2-devel mailing list
>> edk2-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
