ACPI on ARMv8 Servers

这篇具有很好参考价值的文章主要介绍了ACPI on ARMv8 Servers。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

前言

Linux内核在2015年6月21日发布的Linux 4.1版本中,Linux为arm64架构添加了初步的ACPI 5.1支持:ACPI support for the ARM64 architecture。

ACPI主要是x86体系结构的特性。尽管存在争议,但ARM领域的一些部分一直在推动ACPI的支持。在Linux_4.1这个版本中,Linux为arm64架构添加了初步的ACPI 5.1支持。

ACPI(高级配置与电源接口)是一种开放标准,用于管理计算机硬件和软件之间的交互,以实现高级电源管理、设备发现和配置等功能。在x86架构上,ACPI已经成为了标准配置和电源管理机制,并且在Linux内核中得到了广泛支持。然而,在ARM架构中,ACPI的支持相对较少,因为ARM架构通常使用其他的设备树(Device Tree)机制来描述硬件配置。

尽管存在争议,一些ARM领域的人士认为引入ACPI支持可以带来一些优势,例如更好的硬件兼容性和可移植性。因此,在这个版本中,Linux内核向arm64架构添加了初步的ACPI 5.1支持。这意味着arm64架构的设备可以开始使用ACPI来管理电源和配置,以及与其他ACPI兼容系统进行交互。

ARM64处理器除了可以用设备树(DT)描述系统中设备的硬件,提供硬件抽象表述,还可以用ACPI(Advanced Configuration and Power Interface),比如:

# ls -l /sys/firmware/
acpi/       devicetree/ dmi/        efi/        fdt
# ls -l /sys/firmware/acpi/tables/
APIC     BGRT     data/    DSDT     dynamic/ FACP     GTDT     IORT     MCFG     PPTT     SPCR     SSDT

ARM64处理器兼容设备树和ACPI两者模式,但在内核启动时ACPI和DT只能选择一种启动方式。
ARM在移动端、嵌入式领域通常都是uboot+DT,ARM在服务器和桌面领域时,可以选择UEFI+ACPI,ACPI相比于DT,ACPI不但实现了硬件设备的静态抽象,还实现了硬件行为的动态抽象,同时ACPI基本占据了服务器生态。

比如我手中的飞腾处理器+麒麟桌面操作系统,就是采用和UEFI+ACPI:

[    0.000000] efi: Getting EFI parameters from FDT:
[    0.000000] efi: EFI v2.70 by EDK II
[    0.000000] efi:  SMBIOS=0xeb790000  SMBIOS 3.0=0xeb770000  ACPI 2.0=0xec000000  MEMATTR=0xdeaefa98  MEMRESERVE=0xd5909e98
[    0.000000] secureboot: Secure boot disabled
[    0.000000] cma: Reserved 32 MiB at 0x00000000fa000000
[    0.000000] ACPI: Early table checksum verification disabled
[    0.000000] ACPI: RSDP 0x00000000EC000000 000024 (v02 PHYLTD)
[    0.000000] ACPI: XSDT 0x00000000EBFF0000 00006C (v01 PHYLTD PHYTIUM. 00000001 GGCL 00010000)
[    0.000000] ACPI: FACP 0x00000000EBFE0000 000114 (v06 PHYLTD PHYTIUM. 00000001 PHYT 00000001)
[    0.000000] ACPI: DSDT 0x00000000EBF70000 0014AC (v02 PHYLTD PHYTIUM. 00000001 INTL 20190509)
[    0.000000] ACPI: GTDT 0x00000000EBFD0000 000098 (v02 PHYLTD PHYTIUM. 00000001 PHYT 00000001)
[    0.000000] ACPI: IORT 0x00000000EBFC0000 000080 (v00 PHYLTD PHYTIUM. 00000001 PHYT 00000001)
[    0.000000] ACPI: APIC 0x00000000EBFB0000 0002D8 (v04 PHYLTD PHYTIUM. 00000001 PHYT 00000001)
[    0.000000] ACPI: MCFG 0x00000000EBFA0000 00003C (v01 PHYLTD PHYTIUM. 00000001 PHYT 00000001)
[    0.000000] ACPI: SPCR 0x00000000EBF90000 000050 (v02 PHYLTD PHYTIUM. 00000001 PHYT 00000001)
[    0.000000] ACPI: SSDT 0x00000000EBF80000 000515 (v02 PHYLTD PHYTIUM. 00000001 INTL 20190509)
[    0.000000] ACPI: PPTT 0x00000000EBF60000 000396 (v01 PHYLTD PHYTIUM. 00000001 PHYT 00000001)
[    0.000000] ACPI: BGRT 0x00000000EBF50000 000038 (v01 GWTLTD GWTLBGRT 00010000 GGCL 00010000)

ACPI可用于ARMv8通用服务器,其设计符合ARM SBSA(服务器基础系统架构)和SBBR(服务器基础引导要求)规范。

ARMv8内核实现了ACPI 5.1版或更高版本的精简硬件模式。在该模式中,没有使用硬件实现 ACPI 固定硬件接口,而是使用对应的软件替代方案。并且设置HW_REDUCED_ACPI 标志位
规范及其引用的所有外部文档的链接由UEFI论坛管理。请参考:https://uefi.org/specifications

根据 Linux 文档说明,对于 ARM64 上的 ACPI,表格分为如下类型:

Required: DSDT, FADT, GTDT, MADT, MCFG, RSDP, SPCR, XSDT

Recommended: BERT, EINJ, ERST, HEST, PCCT, SSDT

Optional: BGRT, CPEP, CSRT, DBG2, DRTM, ECDT, FACS, FPDT, IBFT, IORT, MCHI, MPST, MSCT, NFIT, PMTT, RASF, SBST, SLIT, SPMI, SRAT, STAO, TCPA, TPM2, UEFI, XENV

Not supported: BOOT, DBGP, DMAR, ETDT, HPET, IVRS, LPIT, MSDM, OEMx, PSDT, RSDT, SLIC, WAET, WDAT, WDRT, WPBT

ARM64服务器处理器通常要求实现上述 Required 表格这一项内容,其它表格项可由固件和OS根据需要实现。

如果ARMv8系统不符合SBSA和SBBR的要求,或者不能使用所需的ACPI规范中定义的机制进行描述,则ACPI可能不太适合该硬件。

接下来描述ARMv8系统上ACPI与Linux之间的交互。

一、Why ACPI on ARM?

在检查ACPI和Linux之间的接口细节之前,了解ACPI被使用的原因是很有用的。毕竟,Linux中已经存在一些描述不可枚举硬件的技术(比如设备树)。
这篇博文:https://www.secretlab.ca/archives/151,概述了ARMv8服务器上ACPI背后的原因。总结如下所示:
(1)ACPI的字节码(AML)允许平台对硬件行为进行编码,而DT明确不支持这一点。对于硬件供应商来说,能够编码行为是支持新硬件上的操作系统版本的关键工具。
(2)ACPI的OSPM定义了一个电源管理模型,该模型将平台允许做的事情限制在一个特定的模型中,同时还提供了硬件设计的灵活性。
(3)在企业服务器环境中,ACPI已经建立了当前在生产系统中使用的绑定(例如RAS)。DT没有。这样的绑定可以在DT中定义,但这样做意味着ARM和x86最终将在固件和内核中使用完全不同的代码路径。
(4)选择单一接口来描述平台和操作系统之间的抽象非常重要。如果硬件供应商想要支持多个操作系统,则不需要同时实现DT和ACPI。而且,在单个接口上达成一致,而不是将其分散到每个操作系统的接口中,有助于实现更好的整体互操作性。
(5)新的ACPI管理过程运行良好,Linux现在与硬件供应商和其他操作系统供应商处于同一位置。事实上,再也没有任何理由认为ACPI只属于Windows,或者在这一领域Linux在任何方面都是微软的次要产品。ACPI管理向UEFI论坛的转移极大地开放了规范开发过程,目前,ACPI的大部分更改都是由Linux驱动的。

ACPI使用的关键是 the support model 。对于一般的服务器,硬件行为的责任不能仅仅是内核的领域,而是必须在平台和内核之间划分,以允许随着时间的推移进行有序的更改。ACPI使操作系统无需了解硬件的所有细节,从而无需将操作系统单独移植到每个设备。它允许硬件供应商对电源管理行为负责,而不依赖于不受其控制的OS发布周期。

ACPI重要的一个原因是硬件和操作系统供应商已经制定出支持通用计算生态系统的机制(The infrastructure、 the bindings 、 the processes等都是现成的)。当使用垂直定制集成设备开发时,虽然完全符合Linux的要求,但没有很好的流程来支持服务器供应商的需要。Linux有可能通过DT实现这一目标,但这样做实际上只是复制了一些已经有效的东西。ACPI已经满足了硬件供应商的需求,微软不会在DT上合作,硬件供应商最终仍然会提供两个完全独立的固件接口:一个用于Linux,一个用于Windows。

嵌入式领域往往是高度定制化的平台,各个硬件模块都是不可分割的,因此用uboot+DT较为合适,移植也比较简单,这合适专用系统,而不是通用系统。
而服务器领域和桌面领域往往都是通用系统,ARM服务器生态系统更适合于所有操作系统使用相同接口的协议。硬件和操作系统供应商已经使用ACPI来支持通用生态系统,ACPI更适合通用硬件支持模型。

因此对于ARM64,ACPI相比于DT来说跟适合用于服务器领域。

二、Kernel Compatibility

ACPI的主要动机之一是标准化,并利用它为Linux内核提供向后兼容性。在服务器市场上,软件和硬件经常被长期使用。ACPI允许内核和固件在一个一致的抽象层上达成一致,即使在硬件或软件发生变化时,该抽象层也可以随时间保持。只要支持抽象层,就可以更新系统,而不必更换内核。
ACPI充当操作系统和系统固件之间的接口层:
acpi_match_table,ARM 64,linux,服务器
当Linux驱动程序或子系统第一次使用ACPI实现时,根据定义,它最终需要特定版本的ACPI规范–它是基准。ACPI固件必须继续工作,即使它可能不是最优的,因为最早的内核版本首先提供对ACPI基准版本的支持。可能需要额外的驱动程序,但添加新功能(例如,CPU电源管理)不应破坏较旧的内核版本。此外,ACPI固件还必须与最新版本的内核一起工作。

三、Relationship with Device Tree

ARMv8驱动程序和子系统中的ACPI支持在编译时不应与DT互斥,即两者编译兼容,两者可同时存在,在启动阶段选择一种。

在引导时,内核将仅使用一种描述方法,这取决于从引导加载器传递的参数(包括内核引导参数)。

无论使用DT还是ACPI,内核必须始终能够使用任一方案启动(在编译时启用两种方案的内核中)。

因此驱动可以 DT 和 ACPI 两种启动方式,如下所示:

static const struct of_device_id static_replicator_match[] = {
	{.compatible = "arm,coresight-replicator"},
	{.compatible = "arm,coresight-static-replicator"},
	{}
};

MODULE_DEVICE_TABLE(of, static_replicator_match);

#ifdef CONFIG_ACPI
static const struct acpi_device_id static_replicator_acpi_ids[] = {
	{"ARMHC985", 0}, /* ARM CoreSight Static Replicator */
	{}
};

MODULE_DEVICE_TABLE(acpi, static_replicator_acpi_ids);
#endif

static struct platform_driver static_replicator_driver = {
	.probe          = static_replicator_probe,
	.remove         = static_replicator_remove,
	.driver         = {
		.name   = "coresight-static-replicator",
		/* THIS_MODULE is taken care of by platform_driver_register() */
		.of_match_table = of_match_ptr(static_replicator_match),
		.acpi_match_table = ACPI_PTR(static_replicator_acpi_ids),
		.pm	= &replicator_dev_pm_ops,
		.suppress_bind_attrs = true,
	},
};

of_match_table 用于从DT启动匹配硬件设备。
acpi_match_table 用于从ACPI启动匹配硬件设备。

驱动设备有两套方案,一套用于解析DT,一套用于解析ACPI,从解析的数据中获取相应的硬件属性。

ARM在移动端和嵌入式领域通常都是uboot+DT。
ARM在服务器和桌面领域时,可以选择UEFI+ACPI。

四、Booting using ACPI tables

在ARMv8上将ACPI表传递给内核的唯一定义方法是通过UEFI系统配置表。正因为如此,这意味着ACPI仅在通过UEFI引导的平台上受支持。

当ARMv8系统启动时,它可以有DT信息、ACPI表,或者在一些非常不寻常的情况下,两者都有。如果没有使用命令行参数,内核将尝试使用DT进行设备枚举;如果不存在DT,内核将尝试使用ACPI表,但前提是它们存在。如果两者都不可用,内核将无法启动。如果在命令行上使用acpi=force,内核将尝试首先使用acpi表,但如果没有acpi表则返回DT。

通过在内核命令行上传递ACPI=off,可以 disable ACPI表的处理;这是默认行为。

五、ACPI Detection

驱动程序应该通过检查ACPI_HANDLE的空值、检查.of_node或设备结构中的其他信息来确定其probe()类型。

在非驱动程序代码中,如果需要在运行时检测ACPI的存在,请检查acpi_disabled的值。如果未设置CONFIG_ACPI,acpi_disabled将始终为1。

六、Device Enumeration

ACPI中的设备描述应使用标准认可的ACPI接口。这些可能包含比通常通过设备树描述为同一设备提供的信息更少的信息,这也是ACPI有用的原因之一:驱动程序考虑到它可能没有关于设备的详细信息,而是使用合理的默认值。如果在驱动程序中做得适当,硬件可以随着时间的推移而改变和改进,而不必改变驱动程序。

时钟就是一个很好的例子。在DT中,需要指定时钟,驱动程序需要将其考虑在内。在ACPI中,假设UEFI将使设备处于合理的默认状态,包括任何时钟设置。如果出于某种原因,驱动程序需要更改时钟值,这可以通过ACPI方法完成;驱动程序需要做的只是调用方法,而不关心方法需要做什么来改变时钟。随着时间的推移,可以通过改变ACPI方法而不是驱动程序来改变硬件。

在DT中,驱动程序设置时钟所需的参数称为“bindings”;在ACPI中,这些参数称为“Device Properties”,并通过_DSD对象提供给驱动程序。

七、Driver Recommendations

为驱动程序添加ACPI支持时,请勿删除任何DT处理。同一设备可用于许多不同的系统。请尝试构造驱动程序,使其成为数据驱动的。也就是说,根据默认值设置一个包含每个设备内部状态的结构。驱动程序 probe 函数必须发现任何其他内容。然后,让驱动程序的其余部分对该结构的内容进行操作。这样做应该允许ACPI和DT功能之间的大部分差异保持在 probe 函数的本地,而不是分散在整个驱动器中。例如:

static int device_probe_dt(struct platform_device *pdev)
{
       /* DT specific functionality */
       ...
}

static int device_probe_acpi(struct platform_device *pdev)
{
       /* ACPI specific functionality */
       ...
}

static int device_probe(struct platform_device *pdev)
{
       ...
       struct device_node node = pdev->dev.of_node;
       ...

       if (node)
               ret = device_probe_dt(pdev);
       else if (ACPI_HANDLE(&pdev->dev))
               ret = device_probe_acpi(pdev);
       else
               /* other initialization */
               ...
       /* Continue with any generic probe operations */
       ...
}

一定要在驱动程序中将MODULE_DEVICE_TABLE条目放在一起,以明确从DT和ACPI探测驱动程序的不同名称:

static struct of_device_id virtio_mmio_match[] = {
        { .compatible = "virtio,mmio", },
        { }
};
MODULE_DEVICE_TABLE(of, virtio_mmio_match);

static const struct acpi_device_id virtio_mmio_acpi_match[] = {
        { "LNRO0005", },
        { }
};
MODULE_DEVICE_TABLE(acpi, virtio_mmio_acpi_match);

参考资料

https://static.lwn.net/kerneldoc/arm64/acpi_object_usage.html
https://static.lwn.net/kerneldoc/arm64/arm-acpi.html
https://www.linaro.org/blog/when-will-uefi-and-acpi-be-ready-on-arm/文章来源地址https://www.toymoban.com/news/detail-792815.html

到了这里,关于ACPI on ARMv8 Servers的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • ARMv8架构简介

    ARMv8‑A 架构是针对应用程序配置文件的最新一代 ARM 架构。 ARMv8 这个名称用于描述整体架构,现在包括 32 位执行状态和 64 位执行状态。它引入了使用 64 位宽寄存器执行的能力,同时保持与现有 ARMv7 软件的向后兼容性。 ARMv8‑A 架构引入了许多更改,可以设计出性能显着提高

    2024年02月04日
    浏览(43)
  • Armv8/Armv9从入门到精通-课程介绍

    通知,Arm二期,咱们也有大合集PDF了,共计1587页,还未完成,后续持续更新和优化中。为了方便大家阅读、探讨、做笔记,特意整了此合集PPT,为了增加标签目录,还特意开了福兮阅读器会员。 以下是此课程的介绍: 1、全体系的掌握ARMv8/ARMv9的核心知识点(ARM基础、异常中断

    2024年02月03日
    浏览(50)
  • [笔记]ARMv7/ARMv8 交叉编译器下载

    开发 Cortex-A7、Cortex-A72 或其他 ARM 架构 profile 芯片时,经常需要下载对应架构的交叉编译器,所以写这篇笔记,用于记录一下交叉编译器下载流程,免得搞忘。 编译环境:ubuntu 虚拟机 下载地址 我们可以从 ARM 官网的 Arm Developer下载交叉编译器,这个网站也包含几乎所有的 A

    2024年02月02日
    浏览(47)
  • ARMv8 - 安全机制 - 异常等级

    ARMv8架构处理器有一套异常等级(Exception level)机制,分成4个等级(EL0 ~ EL3)。 处理器运行时会处于其中的某个等级并且可以进行等级切换。 每个异常等级都拥有一些自己版本的特殊寄存器,例如:system ctrl 寄存器(sctlr_el1,sctlr_el2 …),程序状态寄存器(SPSR_EL1,SPSR_EL

    2024年02月13日
    浏览(46)
  • Armv8/Armv9 Cache知识大纲分享--思维导图

    :cache学习、mmu学习、cache资料、mmu资料、arm资料、armv8资料、armv9资料、 trustzone视频、tee视频、ATF视频、secureboot视频、安全启动视频、selinux视频,cache视频、mmu视频,armv8视频、armv9视频、FF-A视频、密码学视频、RME/CCA视频、学习资料下载、免费学习资料、免费 周贺贺

    2024年02月08日
    浏览(42)
  • ARMv8 TTBRx寄存器

    Selection between TTBR0_ELx and TTBR1_ELx when two VA ranges are supported. 支持两个 VA 范围时,在 TTBR0_ELx 和 TTBR1_ELx 之间进行选择。 Every translation table walk starts by accessing the translation table addressed by the TTBR_ELx for the stage 1 translation for the required translation regime. 每个转换表遍历都从访问由 TTBR_EL

    2024年02月10日
    浏览(54)
  • Armv8-A virtualization

    快速链接: . 👉👉👉 个人博客笔记导读目录(全部) 👈👈👈 付费专栏-付费课程 【购买须知】: 【精选】ARMv8/ARMv9架构入门到精通-[目录] 👈👈👈 — 适合小白入门 【目录】ARMv8/ARMv9架构高级进阶-[目录]👈👈👈 — 高级进阶、小白勿买 【加群】ARM/TEE/ATF/SOC/芯片/安全-学习交

    2024年01月23日
    浏览(45)
  • ARMv8 - 安全机制(TrustZone) - 异常等级

    ARMv8架构处理器有一套异常等级(Exception level)机制,分成4个等级(EL0 ~ EL3)。 处理器运行时会处于其中的某个等级并且可以进行等级切换。 每个异常等级都拥有一些自己版本的特殊寄存器,例如:system ctrl 寄存器(sctlr_el1,sctlr_el2 …),程序状态寄存器(SPSR_EL1,SPSR_EL

    2024年01月16日
    浏览(42)
  • Armv8-M架构学习笔记

    Armv8-M架构概述: 关于Armv8架构和architecture profiles Arm定义了三个architecture profiles: A 应用程序profile: 支持基于内存管理单元(MMU)的虚拟内存系统架构(VMSA)。 支持A64、A32和T32指令集。 R 实时profile: 支持AArchi64或AArchi32执行状态。 支持A64或A32和T32指令集。 支持基于内存保

    2024年02月09日
    浏览(49)
  • 浅析ARMv8体系结构:异常处理机制

    异常处理指的是处理器在运行过程中发生了外部事件,导致处理器需要中断当前执行流程转而去处理异常事件的一种机制。在Intel处理器的术语中,中断与异常被分开来描述,但在ARMv8体系结构中,异常和中断统一被称为异常处理。 在ARMv8体系结构中,广义上的异常可以分成同

    2024年02月09日
    浏览(49)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包