From: Mathew McBride <matt@traverse.com.au>
To: development@lists.ipfire.org
Subject: Re: ARM 64?
Date: Thu, 24 May 2018 21:02:18 +1000 [thread overview]
Message-ID: <FAB716AC-1B2D-480B-B75B-E7852AA85E98@traverse.com.au> (raw)
In-Reply-To: <c14850013b085e91a5b7d3e9f283e53b57f68346.camel@ipfire.org>
[-- Attachment #1: Type: text/plain, Size: 4738 bytes --]
Hi Michael,
See answers below
On 24/5/18, 8:31 pm, "Michael Tremer" <michael.tremer(a)ipfire.org> wrote:
Hello,
On Thu, 2018-05-24 at 11:32 +1000, Mathew McBride wrote:
> Hi Michael,
> From the software side, the support in the kernel is fairly good, mainline
> 4.15 and later works. We (Traverse) only maintain a patchset for some small
> drivers (such as hwmon sensors not yet in the kernel - not required to boot)
> and other minor fixes not yet applied upstream.
Any idea if 4.14 works? We are going to use this kernel as the next one because
it is a long-term supported one.
4.14 does work, but the network drivers for the LS1043 narrowly missed the 4.14 merge window.
They just need to be cherry-picked from a later kernel, i.e https://gitlab.com/traversetech/traverse-kernel-patches/blob/kernel-4-14/patches/0001_soc-fsl-qbman-Enable-QBMan-on-ARM-Platforms.patch
> If you build an image that uses UEFI boot it will work on both our hardware
> (bare metal), as a VM and on the ARM64 server platforms (Ampere/XGene,
> Centriq, ThunderX), or even our competitors (MacchiatoBin etc.)
I got an XGene. Not really a fan of that EFI thing it came with, but u-boot was
in a horrible state a few years ago, too.
https://planet.ipfire.org/post/our-start-with-arm64-the-applied-micro-mustang
> The big difference is that we use u-boot and it's EFI implementation - and
> that is improving at a rate that we don't feel it necessary to port TianoCore
> to our board.
Haven't tried u-boot in EFI mode, yet. But it is a good to have everything open
and freely distributable for us. I suppose u-boot is living in the NAND flash
and the OS is on SSD or SD card?
Yes, u-boot is on the NAND. It will boot EFI distributions on any supported block device (SD, USB, SSD).
There are some limitations - no EFI persistent variables etc. (yet) or RTC service, but I think that will eventually be solved.
'Real' ARM servers (these days) also use ACPI instead of passing a device tree, but this doesn't really make much of a difference in user space.
> The board Guy linked (LS1043-S) is our OEM/volume product, and he can brief
> you on the pricing off-list.
Thanks for that.
[snip]
Regards,
Matt
>
> -------- Forwarded Message --------
> Subject:
> Re: ARM 64?
> Date:
> Wed, 23 May 2018 10:58:00 +0100
> From:
> Michael Tremer mailto:michael.tremer(a)ipfire.org
> To:
> mailto:guy(a)traverse.com.au, mailto:development(a)lists.ipfire.org
>
> Hello Guy,
>
> thank you very much for getting in touch.
>
> Yes, we are working on an ARM 64 port, but so far we have not seen any
> hardware
> that was worth doing the port for. All those small and cheap single-board
> computers lack power, the bigger systems are basically unavailable and way too
> expensive.
>
> This board is way different though. CPU, Memory and especially the NICs are
> something that are way better sized and make a nice small appliance for bigger
> SOHOs or small to medium-sized offices.
>
> Not entirely sure why there is only one 10G port. Usually where 10G goes in,
> it
> has to go out somewhere else again...
>
> The big question is what software support is like in the Linux kernel for
> this.
> I have seen the patches linked on the product page and can only defer to Arne
> to
> have a look at it.
>
> My question would now be: What is the desired RRP for this or wholesale? I am
> just curious to find out if it is competitive or if people would find it too
> expensive and buy Intel again. Then we shouldn't really bother with putting
> the
> time into a port. If you are not comfortable sharing prices on the list,
> please
> feel free to email me in private about this.
>
> About the sponsorship. Thank you very much for considering us. I would be
> happy
> to have a closer look. Would you be able to ship this into the UK or Germany?
>
> Best,
> -Michael
>
> On Wed, 2018-05-23 at 12:46 +1000, Guy Ellis wrote:
> > Dear list,
> >
> > Just wondering if there is any interest in supporting ARM 64 hardware
> > moving forward?
> >
> > We can assist with donated hardware and support if there is interest.
> > https://traverse.com.au/products/ls1043s-router-board/
> >
> > Regards,
> > - Guy.
> >
> >
>
>
>
next prev parent reply other threads:[~2018-05-24 11:02 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <c51182f4-9958-4b76-83e0-9a8affa81038@traverse.com.au>
2018-05-24 1:32 ` Mathew McBride
2018-05-24 10:31 ` Michael Tremer
2018-05-24 11:02 ` Mathew McBride [this message]
2018-05-24 14:44 ` Michael Tremer
2018-05-25 2:45 ` Mathew McBride
2018-05-25 13:10 ` Michael Tremer
2018-05-28 10:32 ` Mathew McBride
2018-05-28 11:15 ` Michael Tremer
2018-06-14 17:08 ` Peter Müller
2018-06-17 23:40 ` Mathew McBride
2018-06-18 11:23 ` Michael Tremer
2018-06-18 16:11 ` Peter Müller
2018-07-26 9:50 ` Michael Tremer
2018-08-04 18:31 ` Peter Müller
2018-08-19 8:54 ` Mathew McBride
2018-08-20 15:11 ` Michael Tremer
2018-05-23 2:46 Guy Ellis
2018-05-23 9:58 ` 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=FAB716AC-1B2D-480B-B75B-E7852AA85E98@traverse.com.au \
--to=matt@traverse.com.au \
--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