mbox series

[0/1] Enable ACPI support on ARM64

Message ID 20200914013249.30733-1-matt@traverse.com.au
Headers
Series Enable ACPI support on ARM64 |

Message

Mathew McBride Sept. 14, 2020, 1:32 a.m. UTC 
  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(-)

Comments

Michael Tremer Sept. 16, 2020, 12:46 p.m. UTC | #1 
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@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
>
Mathew McBride Sept. 17, 2020, 1:47 a.m. UTC | #2 
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@ipfire.org> 
Sent: Wednesday, 16 September 2020 10:47 PM
To: Mathew McBride <matt@traverse.com.au>
Cc: development@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@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
>
Michael Tremer Sept. 17, 2020, 7:14 a.m. UTC | #3 
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@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@ipfire.org> 
> Sent: Wednesday, 16 September 2020 10:47 PM
> To: Mathew McBride <matt@traverse.com.au>
> Cc: development@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@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
>> 
> 
>
Michael Tremer Sept. 18, 2020, 8:46 a.m. UTC | #4 
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@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@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@ipfire.org> 
>> Sent: Wednesday, 16 September 2020 10:47 PM
>> To: Mathew McBride <matt@traverse.com.au>
>> Cc: development@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@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
>>> 
>> 
>> 
>