<sigmaepsilon92@...> wrote: No, the kernel is entered with the MMU and caches off. The LinuxLoader is a poorly maintained hack, and it is badly broken on AARCH64. On ARM, however, it should

If I understand this correctly this is just some MMU feature, right? I'm talking about a pure ARM(with atag's) linux kernel which is not UEFI aware. Also the LinuxLoader disables almost

You most likely don't have execution rights for those pages. Refer to 4.6 EFI Configuration Table & Properties Table EFI_MEMORY_ATTRIBUTES_TABLE in the UEFI 2.6 spec. See also git commit range

Thanks everyone! Laszlo

I compared each v3 patch against its v2 counterpart, including the commit messages. The changes look right. Also, I tested the series, with special regard to the USB 2 keyboard in the firmware, and

Allright - now pushed. Mike, Andrew, apologies for the noise, and thank you for very quick feedback. / Leif

Yes, please. On Monday, I will look into adding Arm support to the optdxe flavor, and once that is in, we can move all platforms over and deprecate/remove the stm version.

Mainly because we don't _know_ that it will be resolved next week and I'm currently having some trust issues regarding these libraries. If that's what it takes to get consensus, sure, I'll go along

This code is now no longer used, so remove it. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@...> Reviewed-by: Laszlo Ersek

If the pci-host-ecam-generic DT node describes a 64-bit MMIO region, account for it in the PCI_ROOT_BRIDGE description that we return to the generic PciHostBridgeDxe implementation, which will be able

Wire up the FdtPciHostBridgeLib introduced in the previous patch to the generic PciHostBridgeDxe implementation, and drop the special ArmVirtPkg version. The former's dependency on

Implement PciHostBridgeLib for DT platforms that expose a PCI root bridge via a pci-host-ecam-generic DT node. The DT parsing logic is copied from the PciHostBridgeDxe implementation in ArmVirtPkg,

Add handling of the PcdPciIoTranslation PCD, so that modules that include this library via NULL resolution are guaranteed that it will be set before they reference it. Contributed-under: TianoCore

Setting the linux,pci-probe-only was intended to align OSes booting via DT with OSes booting via ACPI in the way they honor the PCI configuration performed by the firmware. However, ACPI on arm64 does

Now that Laszlo's virtio-gpu-pci series has removed the last remaining obstacle, we can get rid of the special PciHostBridgeDxe implementation in ArmVirtPkg, and move to the generic one. On AArch64,

I agree that fixing the branch now would be nice. I just don't understand why fixing BaseMemoryLibStm in place is not a better solution, especially if we are nuking it anyway next week. That way, we

Hi Feng, Some Nvme devices returns EFI_DEVICE_ERROR for the SCT test code ( when the buffer passed with 10 bytes) and that creates failure in the SCT report. Some Nvme devices returns EFI_SUCCESS

OK, but that's still yet another change. I don't share that concern. I am entirely serious about nuking it next week if we come to an agreement on a better solution. And I'm happy to take on the

Before trying it, I'll say that I don't like it, for two reasons :) (1) This will affect AllocateBuffer(), yes, but it doesn't affect Map() and Unmap(). In fact I don't understand how the spec allows

Thanks. You seem to have a good handle on things already, though :-) Actually, I suspect this is a bug in PciHostBridgeDxe. It ignores the absence of the EFI_PCI_ATTRIBUTE_DUAL_ADDRESS_CYCLE