- Oct 28, 2021
-
-
Enable RD-N2-Cfg1 platform to choose linuxboot fdf file to replace the shell application with the stage-1 linuxboot kernel based on the build flag $LINUXBOOT_BUILD_ENABLED. This is an initial implementation of linuxboot for RD-N2-Cfg1 platform and not the final version. Signed-off-by:
Shriram K <shriram.k@arm.com>
Change-Id: I607c2d6631a42115d50a801778933e4dc4e2c939 -
Enable RD-N2 platform to choose linuxboot fdf file to replace the shell application with the stage-1 linuxboot kernel based on the build flag $LINUXBOOT_BUILD_ENABLED. This is an initial implementation of linuxboot for RD-N2 platform and not the final verison. Signed-off-by:Shriram K <shriram.k@arm.com>
Change-Id: Ic56c0a9e1135c7a8ea19a210006772d7b23aa62a -
Enable RD-V1 platform to choose linuxboot fdf file to replace the shell application with the stage-1 linuxboot kernel based on the build flag $LINUXBOOT_BUILD_ENABLED. This is an initial implementation of linuxboot for RD-V1 platform and not the final version. Signed-off-by:Shriram K <shriram.k@arm.com>
Change-Id: I4091053ee4d3a216619556bf28fe20f2e070029f -
LinuxBoot is a firmware that replaces specific firmware functionality like the UEFI DXE phase with a Linux kernel and runtime. This patch adds LinuxBootPkg and SgiPlatformLinuxBoot.fdf which replaces the shell application with stage-1 linuxboot kernel and will be built when build flag $LINUXBOOT_BUILD_ENABLED is set. The stage-1 linuxboot kernel uses the same GUID as the shell application, enabling the user to boot the stage-1 linxuboot kernel when launching the Shell from the Boot Manager. This is an initial implementation of linuxboot for RD platforms and not the final version. Signed-off-by:Shriram K <shriram.k@arm.com>
Change-Id: I952bd76487c9a643e39cd82ddcb222417a883847
-
- Oct 25, 2021
-
-
Vijayenthiran Subramaniam authored
Platforms which uses SgiMemoryMap.dsc.inc has been updated to use 0x5_0000_0000 as base for the 64-bit Pci MMIO region and the size has been limited to 4GiB. Update SgiMemoryMap.dsc.inc so that the OS would use correct 64-bit Pci MMIO region. Signed-off-by:Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com> Change-Id: I0a473eccef3d4c2e67dae87206331bcf6cca582d
-
Extend the SMBIOS support for RD-N2-Cfg2 Platform. Change-Id: Ia2364214835eb23894b83d46533b65e2a3607acd Signed-off-by:
Pranav Madhu <pranav.madhu@arm.com> -
Add initial support for RD-N2-Cfg2 Platform. Signed-off-by:Aditya Angadi <aditya.angadi@arm.com> Change-Id: I09bb028c7ab839aa90732c336e1b22b7872679c8
-
Add Madt, Dsdt, Iort, Mcfg, Srat and Ssdt ACPI tables that are specific for RD-N2-Cfg2 platform. Reuse the rest of the shared ACPI tables in SgiPkg. Signed-off-by: -
As a preparatory step towards adding support for RD-N2-Cfg2 Platfrom, add the Product ID lookup values for GetProductID API. Signed-off-by: -
Vijayenthiran Subramaniam authored
OpenSSL requires floating point support. So remove nofp compiler flag from SgiPlatformMm dsc file. Signed-off-by: -
The RD-N2-Cfg1 platform uses one instance of the IO Virtualization block to connect PL011 UART controllers and PL330 DMA controllers. Describe these devices by including the SsdtIoVirtBlk.asl ACPI table. In addition to this, add named-component IORT nodes for DMA PL330 DMA controllers that is interfaced with the SMMUv3 present in the IO virtualization block that is used to connect non-discoverable devices. This node maps to the DMA PL330 device node present in Ssdt table for the platform. Signed-off-by:
Vivek Gautam <vivek.gautam@arm.com> Signed-off-by:
-
The RD-N2 platform uses one instance of the IO Virtualization block to connect PL011 UART controllers and PL330 DMA controllers. Describe these devices by including the SsdtIoVirtBlk.asl ACPI table. In addition to this, add named-component IORT nodes for DMA PL330 DMA controllers that is interfaced with the SMMUv3 present in the IO virtualization block that is used to connect non-discoverable devices. This node maps to the DMA PL330 device node present in Ssdt table for the platform. Signed-off-by:
-
For platform that connect non-discoverable devices to IO virtualization block, add a SSDT table to describe those devices. PL011 UART controller and PL330 DMA controller are connected to the non-discoverable IO virtualization block. Signed-off-by:
-
The IO virtualization block on reference design platforms allow connecting non-discoverable devices such as PL011 UART. On platforms that support this, initialize the UART controller connected to the IO virtualization block. Signed-off-by:Shriram K <shriram.k@arm.com>
Change-Id: I70bd3f790f51fa86707b0d300b3a70168731a4ff -
The IO topology on the RD-N2-Cfg1 platform is built using the IO Virtualization block. There are two instances of the IO Virtualization block on the RD-N2 platform and one of these instances is used to connect to a PCIe root bridge. Add RD-N2-Cfg1 platform specific IORT, MCFG and SSDT ACPI tables to represent this IO topology. Signed-off-by:
-
The IO topology on the RD-N2 platform is built using the IO Virtualization block. There are five instances of the IO Virtualization block on the RD-N2 platform and four of these instances are used to connect to PCIe root bridge. Add RD-N2 platform specific IORT, MCFG and SSDT ACPI tables to represent this IO topology. Signed-off-by:
-
Add helper macros for generation of the MCFG, SSDT and IORT ACPI table. The macro EFI_ACPI_SMMUv3_ID_TABLE_INIT simplifies the addition of the SMMUv3 ID remapping table in the IORT table. The macro EFI_ACPI_PCI_RC_ECAM_INIT describes the location of the PCI Express configuration space in the MCFG ACPI table. The macro EFI_ACPI_PCI_RC_INIT simplifies the addition of the root complex entry in the SSDT ACPI table. Signed-off-by:
-
Vijayenthiran Subramaniam authored
In preparation of adding multiple SMMU, IORT and PCIe root complex nodes into the IORT ACPI table, parameterize the existing IORT table. The SMMU interrupt numbers, device ID and base addresses are all parameterized using helper macros. PCDs for these parameters are defined and the platforms can define the value of these PCDs. Signed-off-by:
-
Vijayenthiran Subramaniam authored
For reference design platforms that support more than one PCIe host bridge, update the PCIe host bridge library implementation to allow support for upto four PCIe host bridges. PCDs are introduced to allow platforms to specify the values for bus count and the various MMIO base address and sizes. The available PCIe resources are split equally between the various host bridge instances in the system and macros have been introduced that makes it easier to implment this split. Signed-off-by:
-
GicBase, GicVBase and GicHBase addresses are not used from GICv3 onwards in Madt table. Since RD-N2's GIC version is v4.1, make these base addresses as zero in Madt table. Signed-off-by: -
EINJ table is statically installed. If RAS is disabled EINJ table is not required. This change checks if RAS is enabled, if not then uninstalls the EINJ table from the platform. Signed-off-by:Omkar Anand Kulkarni <omkar.kulkarni@arm.com> Change-Id: Ib4babfcf06072522436674280bd1a6618d4c3b0c
-
The error injection intructions that is pointed to by the EINJ table are placed in a region of memory reserved for it. Clear this memory region before it is used. Change-Id: I1aac512045372ac93cf1a5e2a8d670c5df7a523c Signed-off-by: -
DMC only supports SRAM error injection via integ_cfg registers. So these hacks added will catch the SRAM error injection events and convert them to DRAM errors, by programming appropriate DRAM error record registers. Signed-off-by: -
Current support for error injection is for DMC620 1-bit errors. Signed-off-by: -
Current support for error injection is for DMC620 1-bit errors. Signed-off-by: -
Enables firmware first error handling on the given platform. Installs and publishes the SDEI and HEST ACPI tables required for firmware first error handling. Signed-off-by: -
For ACPI tables that are generated dynamically, define the ACPI table header values that have to be used to build the table header. Co-authored-by:
Thomas Abraham <thomas.abraham@arm.com> Signed-off-by:
-
Allow platforms to define the base address and size of the memory region that is reserved for MM drivers to populate the GHES generic error status block with information about the platform error. Co-authored-by:
-
Enable the use of HEST table generation protocol, GHES error source descriptor protocol and DMC-620 MM driver on ARM Neoverse Reference Design platforms. This allows firmware-first error handling and reporting of DMC-620 memory controller's 1-bit DRAM ECC errors. Co-authored-by:
-
DMC-620 memory controller improves system reliability by generating interrupts on detecting ECC errors on the data. Add a initial DMC-620 MM driver that implements a MMI handler for handling single-bit ECC error events originating from the DRAM. The driver implements the HEST error source descriptor protocol in order to publish the GHES error source descriptor for single-bit DRAM errors. The GHES error source descriptor that is published is of type 'memory error'. A GHES error source descriptor is published for each instances if the DMC-620 controller in the system. The driver registers a MMI handler for handling 1-bit DRAM ECC error events. The MMI handler, when invoked, reads the DMC-620 error record registers and populates the EFI_PLATFORM_MEMORY_ERROR_DATA type error section information structure with the corresponding information read from the error record registers. Co-authored-by:
-
Allow the use of ACPI system description table (SDT) protocol on Arm reference design platforms. This protocol will be used for dynamic addition of ACPI table such as the SDEI ACPI table. Signed-off-by:
-
- Oct 22, 2021
-
-
Isaac Oram authored
Use the open source version of MultiPchPei PEIM. Cc: Nate DeSimone <nathaniel.l.desimone@intel.com> Cc: Chasel Chiu <chasel.chiu@intel.com> Signed-off-by:
Isaac Oram <isaac.w.oram@intel.com> Reviewed-by:
Nate DeSimone <nathaniel.l.desimone@intel.com>
-
Isaac Oram authored
Eliminate the need for the binary PEIM currenty in use by Whitley. Cc: Nate DeSimone <nathaniel.l.desimone@intel.com> Cc: Chasel Chiu <chasel.chiu@intel.com> Signed-off-by:
-
- Oct 19, 2021
-
-
Jeremy Linton authored
In theory we should be properly cleaning up all the device drivers before hitting the big reset. The partition manager will issue flush commands to attached disks as it goes down. This assures that devices running in WB mode, which correctly handle flush/sync/etc commands, are persisted to physical media before reset. Without this, there are definitely cases where the relevant specifications don't guarantee persistence of data in their buffers in the face of reset conditions. We can't really do anything about the many devices that don't honor persistence requests, but we can start here. Signed-off-by:
Jeremy Linton <jeremy.linton@arm.com> Reviewed-by:
Ard Biesheuvel <ardb@kernel.org>
-
Jeremy Linton authored
The EFI spec seems to indicate that the EFI uncacheable attribute should be mapped to device memory rather than normal-nc. This means that the UEFI mem attribute for the >3G ram doesn't match the remainder of the RAM in the machine. So, lets remove the uncacheable attribute to make it more consistent. Signed-off-by:
-
Jeremy Linton authored
It appears that the locking for many of the mailbox commands is incorrect. All UEFI firmware calls to the RPi mailbox share a single mDmaBuffer. That buffer is used to fill out the command passed to the vc firmware, and record its response. The buffer is protected by mMailboxLock, yet in many cases the mailbox response is copied from the buffer after the lock has been released. This doesn't currently appear to be causing any problems, but should be fixed anyway. There are a couple other minor tweaks in this patch that are hard to justify on their own, one is a bit of whitespace cleanup, and the other is the addition of a debug message to print the returned clock rate for the requested clock. This latter print would have immediatly shown that the vc firmware was returning 0 as the emmc clock rate rather than something reasonable. Signed-off-by:
Andrei Warkentin <awarkentin@vmware.com>
-
Jeremy Linton authored
The build has been tossing a warning about having two defaults for a while now, lets fix it. Signed-off-by:
-
Jeremy Linton authored
One of the many issues with the PCIe on this platform is its inbound DMA is either constrained to the lower 3G, or on later SOC's a translation may be used. That translation is problematic with some of the OS's expected to boot on this platform. So, across the board a 3G DMA limit is enforced during boot when in ACPI mode. This itself causes problems because the later boards removed the SPI EEPROM used by the onboard XHCI controller, instead favoring using a block of RAM to load its firmware. Hence it is the lower level firmware's responsibility via a mailbox call, to read the bridge translation/configuration before telling the XHCI controller where it can find its firmware. Everything is great in ACPI land. Now it appears that Linux after reprogramming the bridge to match the DT (when using a translation) can't actually get the XHCI/quirk/reset to function. Apparently, because the firmware only reads the bridge configuration the first time its called(?), or the kernel reset sequence isn't correct. Worse, with just the DMA ranges corrected, the XHCI/QUIRK itself then causes the controller to start having what appear to be DMA issues. Lets simplify the situation and make all DT's provided by this firmware have a 3G DMA limit on the PCIe bus. Then remove the ability for Linux/etc to trigger the quirk by remove the DT node attaching the reset controller to the XHCI. The latter seems somewhat questionable, since the DT/PCIe host bridge driver is doing what appears to be a PERST which might then require a firmware reload, but at the moment seems to work without. The first part of this patch also appears to fix a problem with OpenBSD which interprets the DT as describing how the firmware has configured the device, and makes no attempt to reconfigure it. Hence the newer SOC's implementing a translation fail to boot since the DT being passed to the OS doesn't match the translation the firmware has setup. Signed-off-by:
-
Daniel Schaefer authored
It's a generic platform file. Only the device tree decides what happens. Cc: Daniel Schaefer <daniel.schaefer@hpe.com> Cc: Abner Chang <abner.chang@hpe.com> Cc: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by:
Abner Chang <abner.chang@hpe.com> Signed-off-by:
Daniel Schaefer <daniel.schaefer@hpe.com>
-
Daniel Schaefer authored
Cc: Daniel Schaefer <daniel.schaefer@hpe.com> Cc: Abner Chang <abner.chang@hpe.com> Cc: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by:
-
