Hello,
On 25/5/18, 12:44 am, "Michael Tremer" michael.tremer@ipfire.org wrote:
Hey,
IPFire is not based on any other distribution like Ubuntu is (was?) based on Debian. So we have to port the entire userspace as well as the kernel. Our kernel is also highly customised because the needs of a firewall and secure and hardened systems vary a lot from other server systems. Understood. I've had a look through the repositories - I take it only 3.x is planned to have armv8/arm64 support. Does the userspace build on arm64 at the moment?
We also put a huge emphasis on performance. Networks need to be fast.
There isn't too much great build hardware out there for us right now. We have some smaller system that I can use to play around a bit for a start in a data center. The Mustang system I have doesn't run too well because there is a huge hardware bug in the SATA controller.
There are a couple of options out there, NXP has a Cortex-A72 based SoC's (and devboards) that would be better suited to build tasks. I'm not sure how it stacks up with X-Gene/Mustang but the marketing claims are that A72 (when given a good amount of L2/L3 cache) can hold up against Xeon D's in single thread. I'm hoping ThunderX2 (Cavium) hosts start appearing on cloud providers soon as well. There are ThunderX (v1) instances available, but that core had very poor single thread performance for a server. I do kernel and other builds (Funtoo/Gentoo) all the time on our hardware; but this is more for 'dogfooding'/load testing purposes!
> > 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.) > > 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.
In this hardware or in a future one?
On this hardware. For example, to implement the EFI variable service, we will probably have to make the NAND inaccessible to Linux in EFI-mode. (If you package your images to work on 'removable media', as required for ARM standard VM's, you probably don't need efivars anyway). With the real time clock - we have a discrete RTC chip on our board, whereas the major distributions expect a 'platform' RTC (like x86). Not an issue for embedded distributions but having the EFI RTC will solve system clock issues on the major distros.
> '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.
Not to userspace but to our kernel.
We don't support EFI yet on x86 because there was never any demand for it. Servers are still happy with the legacy mode and people don't seem to trust the bigger EFI blobs that are running on modern systems.
I suppose this hardware comes without a management engine and all of that stuff?
Definitely. No hidden blobs here :) There is a TrustZone firmware running in the ring/EL above the OS, for the NXP Layerscape/QorIQ SoC's this firmware is open source, and not strictly required to run the system (it gets loaded by u-boot after power on). It is, however, required to do certain functions that the ARM server standard expects (such as moving between ring/ELs) - EFI boot does not work without it.
Best, -Michael
Cheers, Matt > Matt > > > > -------- Forwarded Message -------- > > Subject: > > Re: ARM 64? > > Date: > > Wed, 23 May 2018 10:58:00 +0100 > > From: > > Michael Tremer mailto:michael.tremer@ipfire.org > > To: > > mailto:guy@traverse.com.au, mailto:development@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. > > > > > > > > > > > > > > >