[PATCH 0/1] Enable ACPI support on ARM64

[PATCH 0/1] Enable ACPI support on ARM64

[Mathew McBride]

[-- Attachment #1: Type: text/plain, Size: 1959 bytes --]

Hi all,
It's been a while.

This patch enables ACPI support for ARM64 which allows IPFire to boot on ARM
"server" machines which use EFI/TianoCore to boot.

One such example is the QEMU arm64 "virt" machine with an EFI firmware -
https://releases.linaro.org/reference-platform/enterprise/latest/uefi/

The arm64 images from "standard" distros (Debian/Ubuntu/Fedora/etc.) are
designed to work with this EFI+ACPI combination.

There should be no regressions for any current arm64 hardware supported
by IPFire - Linux will only use ACPI tables if present, if
not fallback to device tree.

The use case for this is to run our hardware[1] using the muvirt[2] VM host,
which also allows some "blending" of OpenWrt functions on the host, e.g
the host can manage bridging of Ethernet ports and WiFi hostapd
so IPFire can work with simple Ethernet interfaces for the
Red/Green/Blue/Orange.

You can see the Fireinfo profile for the VM here -
https://fireinfo.ipfire.org/profile/67aa9a9cff94f3ef8f61866197a57106ccdcea4b

I have successfully speedtested ~1Gbps though
this virtualized setup so this should provide more than adequate
performance for most situations.

It is not possible to run IPFire directly on our LS1088 (Ten64) platform
at the moment as 4.14 does not have working Ethernet (DPAA2) and PCIe
controller drivers. It is possible to backport them from later kernels
(and I did have a go at this a few months ago) - but it is a very large
patch (>1M lines) and that is before considering any of the features and
fixes in more recent kernels (e.g backporting PHYLINK).

When IPFire moves to a newer kernel that would be a good time to revisit this.

[1] - https://traverse.com.au/products/ten64-networking-platform/
[2] - https://gitlab.com/traversetech/muvirt

Mathew McBride (1):
  kernel: enable ACPI support on ARM64

 config/kernel/kernel.config.aarch64-ipfire | 99 +++++++++++++++++++++-
 1 file changed, 96 insertions(+), 3 deletions(-)

-- 
2.19.1

[PATCH 1/1] kernel: enable ACPI support on ARM64

[Mathew McBride]

[-- Attachment #1: Type: text/plain, Size: 10314 bytes --]

ACPI (with EFI) is used on ARM systems conforming to the
Server Base Boot Requirements (SBBR) and is an optional
on embedded systems (EBBR).

Up to now the ARM64 boards supported by IPFire use U-Boot and
device tree so ACPI was not turned on.

The immediate use case here is to run under virtualization,
using my muvirt project[1] I can run IPFire on our Traverse Ten64
system. For reasons I'll explain separately it is not
currently possible to run stock IPFire on this system.

This change also enables the EFI RTC driver which is presented
by the qemu arm64 virt machine.

Signed-off-by: Mathew McBride <matt(a)traverse.com.au>

[1] - https://gitlab.com/traversetech/muvirt
---
 config/kernel/kernel.config.aarch64-ipfire | 99 +++++++++++++++++++++-
 1 file changed, 96 insertions(+), 3 deletions(-)

diff --git a/config/kernel/kernel.config.aarch64-ipfire b/config/kernel/kernel.config.aarch64-ipfire
index c616cbb85..da5d7d9f1 100644
--- a/config/kernel/kernel.config.aarch64-ipfire
+++ b/config/kernel/kernel.config.aarch64-ipfire
@@ -185,6 +185,7 @@ CONFIG_KALLSYMS_ALL=y
 # CONFIG_KALLSYMS_ABSOLUTE_PERCPU is not set
 CONFIG_KALLSYMS_BASE_RELATIVE=y
 CONFIG_PRINTK=y
+CONFIG_PRINTK_NMI=y
 CONFIG_BUG=y
 CONFIG_ELF_CORE=y
 CONFIG_BASE_FULL=y
@@ -232,6 +233,7 @@ CONFIG_UPROBES=y
 CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
 CONFIG_HAVE_KPROBES=y
 CONFIG_HAVE_KRETPROBES=y
+CONFIG_HAVE_NMI=y
 CONFIG_HAVE_ARCH_TRACEHOOK=y
 CONFIG_HAVE_DMA_CONTIGUOUS=y
 CONFIG_GENERIC_SMP_IDLE_THREAD=y
@@ -246,6 +248,7 @@ CONFIG_HAVE_PERF_REGS=y
 CONFIG_HAVE_PERF_USER_STACK_DUMP=y
 CONFIG_HAVE_ARCH_JUMP_LABEL=y
 CONFIG_HAVE_RCU_TABLE_FREE=y
+CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y
 CONFIG_HAVE_ALIGNED_STRUCT_PAGE=y
 CONFIG_HAVE_CMPXCHG_LOCAL=y
 CONFIG_HAVE_CMPXCHG_DOUBLE=y
@@ -613,6 +616,7 @@ CONFIG_ARM64_MODULE_CMODEL_LARGE=y
 #
 # Boot options
 #
+# CONFIG_ARM64_ACPI_PARKING_PROTOCOL is not set
 CONFIG_CMDLINE="console=ttyAM0,115200 root=/dev/sda1 rootdelay=20"
 # CONFIG_CMDLINE_FORCE is not set
 CONFIG_EFI_STUB=y
@@ -663,7 +667,14 @@ CONFIG_ARCH_SUSPEND_POSSIBLE=y
 #
 # CPU Idle
 #
-# CONFIG_CPU_IDLE is not set
+CONFIG_CPU_IDLE=y
+# CONFIG_CPU_IDLE_GOV_LADDER is not set
+CONFIG_CPU_IDLE_GOV_MENU=y
+
+#
+# ARM CPU Idle Drivers
+#
+# CONFIG_ARM_CPUIDLE is not set
 # CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set
 
 #
@@ -694,6 +705,7 @@ CONFIG_CPUFREQ_DT_PLATDEV=y
 CONFIG_ARM_BIG_LITTLE_CPUFREQ=m
 CONFIG_ARM_DT_BL_CPUFREQ=m
 # CONFIG_ARM_KIRKWOOD_CPUFREQ is not set
+CONFIG_ACPI_CPPC_CPUFREQ=m
 CONFIG_QORIQ_CPUFREQ=y
 CONFIG_NET=y
 CONFIG_COMPAT_NETLINK_MESSAGES=y
@@ -1577,6 +1589,13 @@ CONFIG_PARPORT=m
 # CONFIG_PARPORT_AX88796 is not set
 CONFIG_PARPORT_1284=y
 CONFIG_PARPORT_NOT_PC=y
+CONFIG_PNP=y
+# CONFIG_PNP_DEBUG_MESSAGES is not set
+
+#
+# Protocols
+#
+CONFIG_PNPACPI=y
 CONFIG_BLK_DEV=y
 # CONFIG_BLK_DEV_NULL_BLK is not set
 # CONFIG_BLK_DEV_PCIESSD_MTIP32XX is not set
@@ -1793,6 +1812,8 @@ CONFIG_HAVE_PATA_PLATFORM=y
 CONFIG_ATA=y
 # CONFIG_ATA_NONSTANDARD is not set
 CONFIG_ATA_VERBOSE_ERROR=y
+CONFIG_ATA_ACPI=y
+# CONFIG_SATA_ZPODD is not set
 CONFIG_SATA_PMP=y
 
 #
@@ -1884,6 +1905,7 @@ CONFIG_SATA_MV=m
 #
 # Generic fallback / legacy drivers
 #
+# CONFIG_PATA_ACPI is not set
 # CONFIG_ATA_GENERIC is not set
 # CONFIG_PATA_LEGACY is not set
 CONFIG_MD=y
@@ -2272,6 +2294,7 @@ CONFIG_DWC_XLGMAC=m
 CONFIG_DWC_XLGMAC_PCI=m
 # CONFIG_FDDI is not set
 # CONFIG_HIPPI is not set
+# CONFIG_NET_SB1000 is not set
 CONFIG_MDIO_DEVICE=y
 CONFIG_MDIO_BUS=y
 CONFIG_MDIO_BCM_UNIMAC=m
@@ -2617,6 +2640,7 @@ CONFIG_USB_NET_RNDIS_WLAN=m
 #
 # CONFIG_WAN is not set
 CONFIG_VMXNET3=m
+# CONFIG_FUJITSU_ES is not set
 # CONFIG_ISDN is not set
 CONFIG_NVM=y
 # CONFIG_NVM_DEBUG is not set
@@ -2794,6 +2818,7 @@ CONFIG_DEVMEM=y
 CONFIG_SERIAL_EARLYCON=y
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_DEPRECATED_OPTIONS=y
+CONFIG_SERIAL_8250_PNP=y
 # CONFIG_SERIAL_8250_FINTEK is not set
 CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_SERIAL_8250_DMA=y
@@ -2872,6 +2897,7 @@ CONFIG_HW_RANDOM_CAVIUM=y
 #
 CONFIG_RAW_DRIVER=y
 CONFIG_MAX_RAW_DEVS=8192
+# CONFIG_HPET is not set
 # CONFIG_TCG_TPM is not set
 CONFIG_DEVPORT=y
 # CONFIG_XILLYBUS is not set
@@ -2880,6 +2906,7 @@ CONFIG_DEVPORT=y
 # I2C support
 #
 CONFIG_I2C=y
+CONFIG_ACPI_I2C_OPREGION=y
 CONFIG_I2C_BOARDINFO=y
 CONFIG_I2C_COMPAT=y
 CONFIG_I2C_CHARDEV=m
@@ -2925,6 +2952,11 @@ CONFIG_I2C_ALGOPCA=m
 # CONFIG_I2C_VIA is not set
 # CONFIG_I2C_VIAPRO is not set
 
+#
+# ACPI drivers
+#
+# CONFIG_I2C_SCMI is not set
+
 #
 # I2C system bus drivers (mostly embedded / system-on-chip)
 #
@@ -3050,6 +3082,7 @@ CONFIG_PINCTRL_SUN50I_A64_R=y
 CONFIG_PINCTRL_SUN50I_H5=y
 CONFIG_GPIOLIB=y
 CONFIG_OF_GPIO=y
+CONFIG_GPIO_ACPI=y
 CONFIG_GPIOLIB_IRQCHIP=y
 # CONFIG_DEBUG_GPIO is not set
 CONFIG_GPIO_SYSFS=y
@@ -3060,6 +3093,7 @@ CONFIG_GPIO_GENERIC=y
 #
 # CONFIG_GPIO_74XX_MMIO is not set
 # CONFIG_GPIO_ALTERA is not set
+# CONFIG_GPIO_AMDPT is not set
 CONFIG_GPIO_AXP209=y
 # CONFIG_GPIO_DWAPB is not set
 # CONFIG_GPIO_EXAR is not set
@@ -3336,6 +3370,12 @@ CONFIG_SENSORS_W83L785TS=m
 CONFIG_SENSORS_W83L786NG=m
 # CONFIG_SENSORS_W83627HF is not set
 # CONFIG_SENSORS_W83627EHF is not set
+# CONFIG_SENSORS_XGENE is not set
+
+#
+# ACPI drivers
+#
+# CONFIG_SENSORS_ACPI_POWER is not set
 CONFIG_THERMAL=y
 CONFIG_THERMAL_EMERGENCY_POWEROFF_DELAY_MS=0
 CONFIG_THERMAL_HWMON=y
@@ -3378,6 +3418,7 @@ CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED=y
 #
 CONFIG_SOFT_WATCHDOG=m
 CONFIG_GPIO_WATCHDOG=m
+# CONFIG_WDAT_WDT is not set
 # CONFIG_XILINX_WATCHDOG is not set
 # CONFIG_ZIIRAVE_WATCHDOG is not set
 CONFIG_ARM_SP805_WATCHDOG=m
@@ -3521,6 +3562,7 @@ CONFIG_MFD_SYSCON=y
 # CONFIG_MFD_TPS65086 is not set
 # CONFIG_MFD_TPS65090 is not set
 # CONFIG_MFD_TPS65217 is not set
+# CONFIG_MFD_TPS68470 is not set
 # CONFIG_MFD_TI_LP873X is not set
 # CONFIG_MFD_TI_LP87565 is not set
 # CONFIG_MFD_TPS65218 is not set
@@ -3603,10 +3645,14 @@ CONFIG_IR_MCE_KBD_DECODER=m
 CONFIG_IR_XMP_DECODER=m
 CONFIG_RC_DEVICES=y
 # CONFIG_RC_ATI_REMOTE is not set
+# CONFIG_IR_ENE is not set
 # CONFIG_IR_HIX5HD2 is not set
 CONFIG_IR_IMON=m
 CONFIG_IR_MCEUSB=m
+# CONFIG_IR_ITE_CIR is not set
+# CONFIG_IR_FINTEK is not set
 # CONFIG_IR_MESON is not set
+# CONFIG_IR_NUVOTON is not set
 CONFIG_IR_REDRAT3=m
 CONFIG_IR_STREAMZAP=m
 # CONFIG_IR_IGORPLUGUSB is not set
@@ -4918,6 +4964,7 @@ CONFIG_USB_DWC3_DUAL_ROLE=y
 #
 # Platform Glue Driver Support
 #
+# CONFIG_USB_DWC3_PCI is not set
 CONFIG_USB_DWC3_OF_SIMPLE=m
 CONFIG_USB_DWC2=y
 # CONFIG_USB_DWC2_HOST is not set
@@ -5118,6 +5165,7 @@ CONFIG_MMC_ARMMMCI=m
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_IO_ACCESSORS=y
 # CONFIG_MMC_SDHCI_PCI is not set
+# CONFIG_MMC_SDHCI_ACPI is not set
 CONFIG_MMC_SDHCI_PLTFM=y
 CONFIG_MMC_SDHCI_OF_ARASAN=m
 # CONFIG_MMC_SDHCI_OF_AT91 is not set
@@ -5291,7 +5339,7 @@ CONFIG_RTC_DRV_DS1553=m
 # CONFIG_RTC_DRV_DS1685_FAMILY is not set
 CONFIG_RTC_DRV_DS1742=m
 CONFIG_RTC_DRV_DS2404=m
-# CONFIG_RTC_DRV_EFI is not set
+CONFIG_RTC_DRV_EFI=m
 CONFIG_RTC_DRV_STK17TA8=m
 # CONFIG_RTC_DRV_M48T86 is not set
 CONFIG_RTC_DRV_M48T35=m
@@ -5327,6 +5375,7 @@ CONFIG_DMADEVICES=y
 CONFIG_ASYNC_TX_ENABLE_CHANNEL_SWITCH=y
 CONFIG_DMA_ENGINE=y
 CONFIG_DMA_VIRTUAL_CHANNELS=y
+CONFIG_DMA_ACPI=y
 CONFIG_DMA_OF=y
 # CONFIG_ALTERA_MSGDMA is not set
 CONFIG_AMBA_PL08X=y
@@ -5535,6 +5584,7 @@ CONFIG_HWSPINLOCK=y
 # Clock Source drivers
 #
 CONFIG_TIMER_OF=y
+CONFIG_TIMER_ACPI=y
 CONFIG_TIMER_PROBE=y
 CONFIG_CLKSRC_MMIO=y
 CONFIG_ROCKCHIP_TIMER=y
@@ -5556,6 +5606,7 @@ CONFIG_MAILBOX=y
 # CONFIG_PLATFORM_MHU is not set
 CONFIG_PL320_MBOX=y
 CONFIG_ROCKCHIP_MBOX=y
+CONFIG_PCC=y
 # CONFIG_ALTERA_MBOX is not set
 CONFIG_BCM2835_MBOX=y
 # CONFIG_MAILBOX_TEST is not set
@@ -5805,6 +5856,7 @@ CONFIG_HID_SENSOR_IIO_TRIGGER=m
 #
 # Light sensors
 #
+# CONFIG_ACPI_ALS is not set
 # CONFIG_ADJD_S311 is not set
 # CONFIG_AL3320A is not set
 # CONFIG_APDS9300 is not set
@@ -5993,6 +6045,7 @@ CONFIG_PHY_MESON_GXL_USB2=y
 # Performance monitor support
 #
 CONFIG_ARM_PMU=y
+CONFIG_ARM_PMU_ACPI=y
 CONFIG_RAS=y
 
 #
@@ -6032,6 +6085,7 @@ CONFIG_ARM_PSCI_FW=y
 # CONFIG_FIRMWARE_MEMMAP is not set
 CONFIG_DMIID=y
 # CONFIG_DMI_SYSFS is not set
+# CONFIG_ISCSI_IBFT is not set
 CONFIG_RASPBERRYPI_FIRMWARE=y
 # CONFIG_FW_CFG_SYSFS is not set
 CONFIG_HAVE_ARM_SMCCC=y
@@ -6051,12 +6105,50 @@ CONFIG_EFI_BOOTLOADER_CONTROL=m
 # CONFIG_EFI_CAPSULE_LOADER is not set
 # CONFIG_EFI_TEST is not set
 # CONFIG_RESET_ATTACK_MITIGATION is not set
+CONFIG_UEFI_CPER=y
+# CONFIG_EFI_DEV_PATH_PARSER is not set
 CONFIG_MESON_SM=y
 
 #
 # Tegra firmware driver
 #
-# CONFIG_ACPI is not set
+CONFIG_ACPI=y
+CONFIG_ACPI_GENERIC_GSI=y
+CONFIG_ACPI_CCA_REQUIRED=y
+# CONFIG_ACPI_DEBUGGER is not set
+CONFIG_ACPI_SPCR_TABLE=y
+# CONFIG_ACPI_EC_DEBUGFS is not set
+CONFIG_ACPI_BUTTON=m
+CONFIG_ACPI_FAN=m
+# CONFIG_ACPI_DOCK is not set
+CONFIG_ACPI_PROCESSOR_IDLE=y
+CONFIG_ACPI_MCFG=y
+CONFIG_ACPI_CPPC_LIB=y
+CONFIG_ACPI_PROCESSOR=m
+# CONFIG_ACPI_IPMI is not set
+CONFIG_ACPI_HOTPLUG_CPU=y
+CONFIG_ACPI_THERMAL=m
+# CONFIG_ACPI_CUSTOM_DSDT is not set
+CONFIG_ARCH_HAS_ACPI_TABLE_UPGRADE=y
+CONFIG_ACPI_TABLE_UPGRADE=y
+# CONFIG_ACPI_DEBUG is not set
+# CONFIG_ACPI_PCI_SLOT is not set
+CONFIG_ACPI_CONTAINER=y
+CONFIG_ACPI_HED=y
+# CONFIG_ACPI_CUSTOM_METHOD is not set
+# CONFIG_ACPI_BGRT is not set
+CONFIG_ACPI_REDUCED_HARDWARE_ONLY=y
+CONFIG_HAVE_ACPI_APEI=y
+CONFIG_ACPI_APEI=y
+CONFIG_ACPI_APEI_GHES=y
+CONFIG_ACPI_APEI_PCIEAER=y
+CONFIG_ACPI_APEI_SEA=y
+# CONFIG_ACPI_APEI_EINJ is not set
+# CONFIG_ACPI_APEI_ERST_DEBUG is not set
+# CONFIG_PMIC_OPREGION is not set
+CONFIG_ACPI_CONFIGFS=m
+CONFIG_ACPI_IORT=y
+CONFIG_ACPI_GTDT=y
 
 #
 # File systems
@@ -6467,6 +6559,7 @@ CONFIG_DYNAMIC_FTRACE=y
 CONFIG_FUNCTION_PROFILER=y
 CONFIG_FTRACE_MCOUNT_RECORD=y
 # CONFIG_FTRACE_STARTUP_TEST is not set
+# CONFIG_HIST_TRIGGERS is not set
 # CONFIG_TRACEPOINT_BENCHMARK is not set
 CONFIG_RING_BUFFER_BENCHMARK=m
 # CONFIG_RING_BUFFER_STARTUP_TEST is not set
-- 
2.19.1

Re: [PATCH 0/1] Enable ACPI support on ARM64

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 2367 bytes --]

Hello Matthew,

Great to hear from you again.

Do you think this could also resolve this problem?

  https://bugzilla.ipfire.org/show_bug.cgi?id=11940

Best,
-Michael

> On 14 Sep 2020, at 02:32, Mathew McBride <matt(a)traverse.com.au> wrote:
> 
> Hi all,
> It's been a while.
> 
> This patch enables ACPI support for ARM64 which allows IPFire to boot on ARM
> "server" machines which use EFI/TianoCore to boot.
> 
> One such example is the QEMU arm64 "virt" machine with an EFI firmware -
> https://releases.linaro.org/reference-platform/enterprise/latest/uefi/
> 
> The arm64 images from "standard" distros (Debian/Ubuntu/Fedora/etc.) are
> designed to work with this EFI+ACPI combination.
> 
> There should be no regressions for any current arm64 hardware supported
> by IPFire - Linux will only use ACPI tables if present, if
> not fallback to device tree.
> 
> The use case for this is to run our hardware[1] using the muvirt[2] VM host,
> which also allows some "blending" of OpenWrt functions on the host, e.g
> the host can manage bridging of Ethernet ports and WiFi hostapd
> so IPFire can work with simple Ethernet interfaces for the
> Red/Green/Blue/Orange.
> 
> You can see the Fireinfo profile for the VM here -
> https://fireinfo.ipfire.org/profile/67aa9a9cff94f3ef8f61866197a57106ccdcea4b
> 
> I have successfully speedtested ~1Gbps though
> this virtualized setup so this should provide more than adequate
> performance for most situations.
> 
> It is not possible to run IPFire directly on our LS1088 (Ten64) platform
> at the moment as 4.14 does not have working Ethernet (DPAA2) and PCIe
> controller drivers. It is possible to backport them from later kernels
> (and I did have a go at this a few months ago) - but it is a very large
> patch (>1M lines) and that is before considering any of the features and
> fixes in more recent kernels (e.g backporting PHYLINK).
> 
> When IPFire moves to a newer kernel that would be a good time to revisit this.
> 
> [1] - https://traverse.com.au/products/ten64-networking-platform/
> [2] - https://gitlab.com/traversetech/muvirt
> 
> Mathew McBride (1):
>  kernel: enable ACPI support on ARM64
> 
> config/kernel/kernel.config.aarch64-ipfire | 99 +++++++++++++++++++++-
> 1 file changed, 96 insertions(+), 3 deletions(-)
> 
> -- 
> 2.19.1
> 

RE: [PATCH 0/1] Enable ACPI support on ARM64

[Mathew McBride]

[-- Attachment #1: Type: text/plain, Size: 2861 bytes --]

Hello Michael,
Yes - this is the exact same symptom (no serial output after GRUB handoff) I
see if I boot the current core148 image.

As there is no DTB being presented by the firmware (only ACPI tables), the
kernel won't be able to find the serial UART to use.

Regards,
Matt

-----Original Message-----
From: Michael Tremer <michael.tremer(a)ipfire.org> 
Sent: Wednesday, 16 September 2020 10:47 PM
To: Mathew McBride <matt(a)traverse.com.au>
Cc: development(a)lists.ipfire.org
Subject: Re: [PATCH 0/1] Enable ACPI support on ARM64

Hello Matthew,

Great to hear from you again.

Do you think this could also resolve this problem?

  https://bugzilla.ipfire.org/show_bug.cgi?id=11940

Best,
-Michael

> On 14 Sep 2020, at 02:32, Mathew McBride <matt(a)traverse.com.au> wrote:
> 
> Hi all,
> It's been a while.
> 
> This patch enables ACPI support for ARM64 which allows IPFire to boot 
> on ARM "server" machines which use EFI/TianoCore to boot.
> 
> One such example is the QEMU arm64 "virt" machine with an EFI firmware 
> - 
> https://releases.linaro.org/reference-platform/enterprise/latest/uefi/
> 
> The arm64 images from "standard" distros (Debian/Ubuntu/Fedora/etc.) 
> are designed to work with this EFI+ACPI combination.
> 
> There should be no regressions for any current arm64 hardware 
> supported by IPFire - Linux will only use ACPI tables if present, if 
> not fallback to device tree.
> 
> The use case for this is to run our hardware[1] using the muvirt[2] VM 
> host, which also allows some "blending" of OpenWrt functions on the 
> host, e.g the host can manage bridging of Ethernet ports and WiFi 
> hostapd so IPFire can work with simple Ethernet interfaces for the 
> Red/Green/Blue/Orange.
> 
> You can see the Fireinfo profile for the VM here - 
> https://fireinfo.ipfire.org/profile/67aa9a9cff94f3ef8f61866197a57106cc
> dcea4b
> 
> I have successfully speedtested ~1Gbps though this virtualized setup 
> so this should provide more than adequate performance for most 
> situations.
> 
> It is not possible to run IPFire directly on our LS1088 (Ten64) 
> platform at the moment as 4.14 does not have working Ethernet (DPAA2) 
> and PCIe controller drivers. It is possible to backport them from 
> later kernels (and I did have a go at this a few months ago) - but it 
> is a very large patch (>1M lines) and that is before considering any 
> of the features and fixes in more recent kernels (e.g backporting
PHYLINK).
> 
> When IPFire moves to a newer kernel that would be a good time to revisit
this.
> 
> [1] - https://traverse.com.au/products/ten64-networking-platform/
> [2] - https://gitlab.com/traversetech/muvirt
> 
> Mathew McBride (1):
>  kernel: enable ACPI support on ARM64
> 
> config/kernel/kernel.config.aarch64-ipfire | 99 +++++++++++++++++++++-
> 1 file changed, 96 insertions(+), 3 deletions(-)
> 
> --
> 2.19.1
> 

Re: [PATCH 0/1] Enable ACPI support on ARM64

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 3352 bytes --]

Hi,

Ah that is good to hear.

I didn’t have time to investigate, and so far I have personally only worked with IPFire aarch64 in KVM virtual machines where it simply boots fine.

Best,
-Michael

> On 17 Sep 2020, at 02:47, Mathew McBride <matt(a)traverse.com.au> wrote:
> 
> Hello Michael,
> Yes - this is the exact same symptom (no serial output after GRUB handoff) I
> see if I boot the current core148 image.
> 
> As there is no DTB being presented by the firmware (only ACPI tables), the
> kernel won't be able to find the serial UART to use.
> 
> Regards,
> Matt
> 
> -----Original Message-----
> From: Michael Tremer <michael.tremer(a)ipfire.org> 
> Sent: Wednesday, 16 September 2020 10:47 PM
> To: Mathew McBride <matt(a)traverse.com.au>
> Cc: development(a)lists.ipfire.org
> Subject: Re: [PATCH 0/1] Enable ACPI support on ARM64
> 
> Hello Matthew,
> 
> Great to hear from you again.
> 
> Do you think this could also resolve this problem?
> 
>  https://bugzilla.ipfire.org/show_bug.cgi?id=11940
> 
> Best,
> -Michael
> 
>> On 14 Sep 2020, at 02:32, Mathew McBride <matt(a)traverse.com.au> wrote:
>> 
>> Hi all,
>> It's been a while.
>> 
>> This patch enables ACPI support for ARM64 which allows IPFire to boot 
>> on ARM "server" machines which use EFI/TianoCore to boot.
>> 
>> One such example is the QEMU arm64 "virt" machine with an EFI firmware 
>> - 
>> https://releases.linaro.org/reference-platform/enterprise/latest/uefi/
>> 
>> The arm64 images from "standard" distros (Debian/Ubuntu/Fedora/etc.) 
>> are designed to work with this EFI+ACPI combination.
>> 
>> There should be no regressions for any current arm64 hardware 
>> supported by IPFire - Linux will only use ACPI tables if present, if 
>> not fallback to device tree.
>> 
>> The use case for this is to run our hardware[1] using the muvirt[2] VM 
>> host, which also allows some "blending" of OpenWrt functions on the 
>> host, e.g the host can manage bridging of Ethernet ports and WiFi 
>> hostapd so IPFire can work with simple Ethernet interfaces for the 
>> Red/Green/Blue/Orange.
>> 
>> You can see the Fireinfo profile for the VM here - 
>> https://fireinfo.ipfire.org/profile/67aa9a9cff94f3ef8f61866197a57106cc
>> dcea4b
>> 
>> I have successfully speedtested ~1Gbps though this virtualized setup 
>> so this should provide more than adequate performance for most 
>> situations.
>> 
>> It is not possible to run IPFire directly on our LS1088 (Ten64) 
>> platform at the moment as 4.14 does not have working Ethernet (DPAA2) 
>> and PCIe controller drivers. It is possible to backport them from 
>> later kernels (and I did have a go at this a few months ago) - but it 
>> is a very large patch (>1M lines) and that is before considering any 
>> of the features and fixes in more recent kernels (e.g backporting
> PHYLINK).
>> 
>> When IPFire moves to a newer kernel that would be a good time to revisit
> this.
>> 
>> [1] - https://traverse.com.au/products/ten64-networking-platform/
>> [2] - https://gitlab.com/traversetech/muvirt
>> 
>> Mathew McBride (1):
>> kernel: enable ACPI support on ARM64
>> 
>> config/kernel/kernel.config.aarch64-ipfire | 99 +++++++++++++++++++++-
>> 1 file changed, 96 insertions(+), 3 deletions(-)
>> 
>> --
>> 2.19.1
>> 
> 
> 

Re: [PATCH 0/1] Enable ACPI support on ARM64

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 3661 bytes --]

It does not want to work:

https://bugzilla.ipfire.org/show_bug.cgi?id=11940

Any ideas anyone?

-Michael

> On 17 Sep 2020, at 08:14, Michael Tremer <michael.tremer(a)ipfire.org> wrote:
> 
> Hi,
> 
> Ah that is good to hear.
> 
> I didn’t have time to investigate, and so far I have personally only worked with IPFire aarch64 in KVM virtual machines where it simply boots fine.
> 
> Best,
> -Michael
> 
>> On 17 Sep 2020, at 02:47, Mathew McBride <matt(a)traverse.com.au> wrote:
>> 
>> Hello Michael,
>> Yes - this is the exact same symptom (no serial output after GRUB handoff) I
>> see if I boot the current core148 image.
>> 
>> As there is no DTB being presented by the firmware (only ACPI tables), the
>> kernel won't be able to find the serial UART to use.
>> 
>> Regards,
>> Matt
>> 
>> -----Original Message-----
>> From: Michael Tremer <michael.tremer(a)ipfire.org> 
>> Sent: Wednesday, 16 September 2020 10:47 PM
>> To: Mathew McBride <matt(a)traverse.com.au>
>> Cc: development(a)lists.ipfire.org
>> Subject: Re: [PATCH 0/1] Enable ACPI support on ARM64
>> 
>> Hello Matthew,
>> 
>> Great to hear from you again.
>> 
>> Do you think this could also resolve this problem?
>> 
>> https://bugzilla.ipfire.org/show_bug.cgi?id=11940
>> 
>> Best,
>> -Michael
>> 
>>> On 14 Sep 2020, at 02:32, Mathew McBride <matt(a)traverse.com.au> wrote:
>>> 
>>> Hi all,
>>> It's been a while.
>>> 
>>> This patch enables ACPI support for ARM64 which allows IPFire to boot 
>>> on ARM "server" machines which use EFI/TianoCore to boot.
>>> 
>>> One such example is the QEMU arm64 "virt" machine with an EFI firmware 
>>> - 
>>> https://releases.linaro.org/reference-platform/enterprise/latest/uefi/
>>> 
>>> The arm64 images from "standard" distros (Debian/Ubuntu/Fedora/etc.) 
>>> are designed to work with this EFI+ACPI combination.
>>> 
>>> There should be no regressions for any current arm64 hardware 
>>> supported by IPFire - Linux will only use ACPI tables if present, if 
>>> not fallback to device tree.
>>> 
>>> The use case for this is to run our hardware[1] using the muvirt[2] VM 
>>> host, which also allows some "blending" of OpenWrt functions on the 
>>> host, e.g the host can manage bridging of Ethernet ports and WiFi 
>>> hostapd so IPFire can work with simple Ethernet interfaces for the 
>>> Red/Green/Blue/Orange.
>>> 
>>> You can see the Fireinfo profile for the VM here - 
>>> https://fireinfo.ipfire.org/profile/67aa9a9cff94f3ef8f61866197a57106cc
>>> dcea4b
>>> 
>>> I have successfully speedtested ~1Gbps though this virtualized setup 
>>> so this should provide more than adequate performance for most 
>>> situations.
>>> 
>>> It is not possible to run IPFire directly on our LS1088 (Ten64) 
>>> platform at the moment as 4.14 does not have working Ethernet (DPAA2) 
>>> and PCIe controller drivers. It is possible to backport them from 
>>> later kernels (and I did have a go at this a few months ago) - but it 
>>> is a very large patch (>1M lines) and that is before considering any 
>>> of the features and fixes in more recent kernels (e.g backporting
>> PHYLINK).
>>> 
>>> When IPFire moves to a newer kernel that would be a good time to revisit
>> this.
>>> 
>>> [1] - https://traverse.com.au/products/ten64-networking-platform/
>>> [2] - https://gitlab.com/traversetech/muvirt
>>> 
>>> Mathew McBride (1):
>>> kernel: enable ACPI support on ARM64
>>> 
>>> config/kernel/kernel.config.aarch64-ipfire | 99 +++++++++++++++++++++-
>>> 1 file changed, 96 insertions(+), 3 deletions(-)
>>> 
>>> --
>>> 2.19.1
>>> 
>> 
>> 
>