From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: [PATCH 0/1] Enable ACPI support on ARM64
Date: Wed, 16 Sep 2020 13:46:49 +0100 [thread overview]
Message-ID: <D60D3E6F-4282-45BB-AE48-A478A9DBAA12@ipfire.org> (raw)
In-Reply-To: <20200914013249.30733-1-matt@traverse.com.au>
[-- 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
>
next prev parent reply other threads:[~2020-09-16 12:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-14 1:32 Mathew McBride
2020-09-14 1:32 ` [PATCH 1/1] kernel: enable " Mathew McBride
2020-09-16 12:46 ` Michael Tremer [this message]
2020-09-17 1:47 ` [PATCH 0/1] Enable " Mathew McBride
2020-09-17 7:14 ` Michael Tremer
2020-09-18 8:46 ` Michael Tremer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D60D3E6F-4282-45BB-AE48-A478A9DBAA12@ipfire.org \
--to=michael.tremer@ipfire.org \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox