Re: ARM 64?

Re: ARM 64?

[Mathew McBride]

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

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.
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.)
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. 

The board Guy linked (LS1043-S) is our OEM/volume product, and he can brief you on the pricing off-list. 
We also have a 'hacker' oriented product in the pipeline (Five64 - https://traverse.com.au/products/five64-arm64-platform/ ) - which is currently in the PCB layout phase. This one has a wider feature set (NVMe SSD, ATX PSU on/off, ability to 'debrick' the flash and control via a separate BMC board). 
This is one we intend to be available to everyone (through CrowdSupply - via the campaign and beyond), which addresses the channel 'accessibility' issue (in terms of individuals and small operators being able to buy them). It's pricing will be similar to the other boards (Omnia, Novena, Atom C2000/C3000).

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.
> 
> 

Re: ARM 64?

[Michael Tremer]

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

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.

> 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?

> The board Guy linked (LS1043-S) is our OEM/volume product, and he can brief
> you on the pricing off-list. 

Thanks for that.

> We also have a 'hacker' oriented product in the pipeline (Five64 -
> https://traverse.com.au/products/five64-arm64-platform/ ) - which is currently
> in the PCB layout phase. This one has a wider feature set (NVMe SSD, ATX PSU
> on/off, ability to 'debrick' the flash and control via a separate BMC board). 
> This is one we intend to be available to everyone (through CrowdSupply - via
> the campaign and beyond), which addresses the channel 'accessibility' issue
> (in terms of individuals and small operators being able to buy them). It's
> pricing will be similar to the other boards (Omnia, Novena, Atom C2000/C3000).
> 
> Regards,
> Matt

-Michael

> 
> -------- 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.
> > 
> > 
> 
> 
> 

Re: ARM 64?

[Mathew McBride]

[-- 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.
    > > 
    > > 
    > 
    > 
    > 
    

Re: ARM 64?

[Michael Tremer]

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

Hey,

On Thu, 2018-05-24 at 21:02 +1000, Mathew McBride wrote:
> 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

Okay, that would be a better start for us to have all architectures on the same
kernel.

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.

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.

>     > 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-mu
> stang
>   
>     > 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.

In this hardware or in a future one?

> '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?

Best,
-Michael

> 
> 
>     > 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.
>     > > 
>     > > 
>     > 
>     > 
>     > 
>     
> 
> 

Re: ARM 64?

[Mathew McBride]

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

Hello,

On 25/5/18, 12:44 am, "Michael Tremer" <michael.tremer(a)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(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.
    >     > > 
    >     > > 
    >     > 
    >     > 
    >     > 
    >     
    > 
    > 
    

Re: ARM 64?

[Michael Tremer]

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

Hello,

On Fri, 2018-05-25 at 12:45 +1000, Mathew McBride wrote:
> Hello,
> 
> On 25/5/18, 12:44 am, "Michael Tremer" <michael.tremer(a)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?

Yes, IPFire 3 builds on ARM64. If it is running outside of a VM is completely
unknown. I was really passionate about this, but since we had no hardware that
was good enough to develop IPFire towards, this is more of a proof-of-concept
than anything else.

IPFire 3 is really hard to port because everything is a package and there is no
easy way how to bootstrap the distribution starting with no package.

IPFire 2 can only be built in one go. Nothing is a package. Every change
requires us to recompile the *entire* distribution. That takes a long time (~9
hours without ccache and about 4-5 with ccache).

>     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.

Oh yeah, they are awesome. So fast and power consumption is quite okay. I got
the first generation XGene and read that any newer generations are more
efficient.

> 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.

With IPFire 3 we can distribute the build process really well. So it wouldn't
matter to have a few build instances more as long as that is financially
feasible.

> I do kernel and other builds (Funtoo/Gentoo) all the time on our hardware; but
> this is more for 'dogfooding'/load testing purposes! 

I think you hardware is good enough for a builder. But I still am not sure what
to expect from the CPU. It will be faster than a Raspberry Pi, but not a
Mustang.

> 
>     >     > 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. 

That would be fine with me. We have no use for the NAND for the OS.

> (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 :)

*thumbs up*

So we would have a huge advantage in the security of the hardware. It looks like
the system isn't even vulnerable for (most of?) Spectre.

> 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).

What does the firmware do?

> 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.

-Michael

> 
>     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(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.
>     >     > > 
>     >     > > 
>     >     > 
>     >     > 
>     >     > 
>     >     
>     > 
>     > 
>     
> 
> 

Re: ARM 64?

[Mathew McBride]

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

Hi Michael,

Just in response to your questions:
On 25/5/18, 11:10 pm, "Michael Tremer" <michael.tremer(a)ipfire.org> wrote:
    
    
    I think you hardware is good enough for a builder. But I still am not sure what
    to expect from the CPU. It will be faster than a Raspberry Pi, but not a
    Mustang.
    
We did some benchmarks with the Phoronix test suite a while ago, this will give you an idea:
http://openbenchmarking.org/result/1708303-TR-1703199RI93&obr_hgv=Traverse+LS1043+Prototype

To give an idea of the Cortex (ARM designed)-based core performance:

The LS1043 has the same A53 cores as the RPi3, but performs better due to having more cache, DDR4 etc (and higher clock).
A72 is about double A53 in performance (and power consumption!) per MHz, as A72 is a modern out-of-order speculative core (it did get hit with the Meltdown/Spectre issue).

The latest gen of ARM64 server cores would all be well above A72, your Mustang is probably around the A72 level.

In general, ARM network SoCs try to work 'smarter' instead of 'harder', so the high network performance comes from having very good network silicon, taking advantage of crypto accelerators etc.

    
    > 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).
    
    What does the firmware do?
It implements some vendor-specific power-management extensions (PSCI), as well as some TPM-like functions.
NXP provides a good overview: https://github.com/qoriq-open-source/ppa-generic/blob/integration/ReleaseNotes.txt
I am not a security expert, but it could be a good test environment for secure boot, private key storage and other things.

    
Cheers,
Matt
 

Re: ARM 64?

[Michael Tremer]

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

Hey Matt,

On Mon, 2018-05-28 at 20:32 +1000, Mathew McBride wrote:
> Hi Michael,
> 
> Just in response to your questions:
> On 25/5/18, 11:10 pm, "Michael Tremer" <michael.tremer(a)ipfire.org> wrote:
>     
>     
>     I think you hardware is good enough for a builder. But I still am not sure
> what
>     to expect from the CPU. It will be faster than a Raspberry Pi, but not a
>     Mustang.
>     
> We did some benchmarks with the Phoronix test suite a while ago, this will
> give you an idea:
> http://openbenchmarking.org/result/1708303-TR-
> 1703199RI93&obr_hgv=Traverse+LS1043+Prototype

I had a look at that. And yes indeed, it is a bit hard to figure out the
performance by the CPU name alone for most ARM SoCs. There is no branding in
order of performance (or similar) like Intel has.

That might actually turn out to be a bigger marketing problem, but we will see
that in the future.

> To give an idea of the Cortex (ARM designed)-based core performance:
> 
> The LS1043 has the same A53 cores as the RPi3, but performs better due to
> having more cache, DDR4 etc (and higher clock).

Performance is also coming from the rest of the periphery. The RPi has a slow
and not very stable USB bus to talk to the network to and SD card storage. Even
with a faster CPU it might very often just wait for data.

We have been trying to tell people that they should look out for some specific
features like cache and good single-core performance.

> A72 is about double A53 in performance (and power consumption!) per MHz, as
> A72 is a modern out-of-order speculative core (it did get hit with the
> Meltdown/Spectre issue).

Yes, wouldn't mind to have some systems based on that one since the A53 will be
too slow for really large enterprise deployments.

> The latest gen of ARM64 server cores would all be well above A72, your Mustang
> is probably around the A72 level.
> 
> In general, ARM network SoCs try to work 'smarter' instead of 'harder', so the
> high network performance comes from having very good network silicon, taking
> advantage of crypto accelerators etc.

I prefer the NICs in the SoC which gives great performance. The disadvantage
only is that they sometimes to odd configurations like 5x 1G and 1x 10G in this
case which I don't really understand. The only use-case that makes sense to me
is a server but for that the CPU is too slow and people would probably go for a
A72-class CPU.

>     > 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).
>     
>     What does the firmware do?
> It implements some vendor-specific power-management extensions (PSCI), as well
> as some TPM-like functions.
> NXP provides a good overview: https://github.com/qoriq-open-source/ppa-generic
> /blob/integration/ReleaseNotes.txt
> I am not a security expert, but it could be a good test environment for secure
> boot, private key storage and other things.

Great that this is entirely open.

-Michael

> 
>     
> Cheers,
> Matt
>  
> 
> 

Re: ARM 64?

[Peter Müller]

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

Hello,

this board sounds very interesting indeed (trustworthy hardware - yay!).
However, after reading the datasheet it did not became clear to me if it
has some built-in random number generator and/or cryptography acceleration.

Apart from some low-level backdoors (baked into USB, ... firmware chips)
it seems like this is suitable for security relevant devices. Looking
forward to hear some experiences with IPFire on it. :-)

Best regards,
Peter Müller

> Hey Matt,
> 
> On Mon, 2018-05-28 at 20:32 +1000, Mathew McBride wrote:
>> Hi Michael,
>>
>> Just in response to your questions:
>> On 25/5/18, 11:10 pm, "Michael Tremer" <michael.tremer(a)ipfire.org> wrote:
>>     
>>     
>>     I think you hardware is good enough for a builder. But I still am not sure
>> what
>>     to expect from the CPU. It will be faster than a Raspberry Pi, but not a
>>     Mustang.
>>     
>> We did some benchmarks with the Phoronix test suite a while ago, this will
>> give you an idea:
>> http://openbenchmarking.org/result/1708303-TR-
>> 1703199RI93&obr_hgv=Traverse+LS1043+Prototype
> 
> I had a look at that. And yes indeed, it is a bit hard to figure out the
> performance by the CPU name alone for most ARM SoCs. There is no branding in
> order of performance (or similar) like Intel has.
> 
> That might actually turn out to be a bigger marketing problem, but we will see
> that in the future.
> 
>> To give an idea of the Cortex (ARM designed)-based core performance:
>>
>> The LS1043 has the same A53 cores as the RPi3, but performs better due to
>> having more cache, DDR4 etc (and higher clock).
> 
> Performance is also coming from the rest of the periphery. The RPi has a slow
> and not very stable USB bus to talk to the network to and SD card storage. Even
> with a faster CPU it might very often just wait for data.
> 
> We have been trying to tell people that they should look out for some specific
> features like cache and good single-core performance.
> 
>> A72 is about double A53 in performance (and power consumption!) per MHz, as
>> A72 is a modern out-of-order speculative core (it did get hit with the
>> Meltdown/Spectre issue).
> 
> Yes, wouldn't mind to have some systems based on that one since the A53 will be
> too slow for really large enterprise deployments.
> 
>> The latest gen of ARM64 server cores would all be well above A72, your Mustang
>> is probably around the A72 level.
>>
>> In general, ARM network SoCs try to work 'smarter' instead of 'harder', so the
>> high network performance comes from having very good network silicon, taking
>> advantage of crypto accelerators etc.
> 
> I prefer the NICs in the SoC which gives great performance. The disadvantage
> only is that they sometimes to odd configurations like 5x 1G and 1x 10G in this
> case which I don't really understand. The only use-case that makes sense to me
> is a server but for that the CPU is too slow and people would probably go for a
> A72-class CPU.
> 
>>     > 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).
>>     
>>     What does the firmware do?
>> It implements some vendor-specific power-management extensions (PSCI), as well
>> as some TPM-like functions.
>> NXP provides a good overview: https://github.com/qoriq-open-source/ppa-generic
>> /blob/integration/ReleaseNotes.txt
>> I am not a security expert, but it could be a good test environment for secure
>> boot, private key storage and other things.
> 
> Great that this is entirely open.
> 
> -Michael
> 
>>
>>     
>> Cheers,
>> Matt
>>  
>>
>>

-- 
"We don't care.  We don't have to.  We're the Phone Company."


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: ARM 64?

[Mathew McBride]

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

Hi Peter,
There are two crypto options on our board:
- ARMv8 Cryptography instructions (similar to AES-NI on x86)
- Freescale SEC/CAAM engine (a 'hardware accelerator' that can do many TLS,IPSec etc. operations)
I am certain that an RNG is part of the SEC engine, but I need to check the driver status on Linux.

/proc/crypto output for those interested: https://gist.github.com/mcbridematt/11f14c78ed4e35e97adf2f027010e374

Regards,
Mathew 

On 15/6/18, 3:09 am, "Peter Müller" <peter.mueller(a)link38.eu> wrote:

    Hello,
    
    this board sounds very interesting indeed (trustworthy hardware - yay!).
    However, after reading the datasheet it did not became clear to me if it
    has some built-in random number generator and/or cryptography acceleration.
    
    Apart from some low-level backdoors (baked into USB, ... firmware chips)
    it seems like this is suitable for security relevant devices. Looking
    forward to hear some experiences with IPFire on it. :-)
    
    Best regards,
    Peter Müller
    
    > Hey Matt,
    > 
    > On Mon, 2018-05-28 at 20:32 +1000, Mathew McBride wrote:
    >> Hi Michael,
    >>
    >> Just in response to your questions:
    >> On 25/5/18, 11:10 pm, "Michael Tremer" <michael.tremer(a)ipfire.org> wrote:
    >>     
    >>     
    >>     I think you hardware is good enough for a builder. But I still am not sure
    >> what
    >>     to expect from the CPU. It will be faster than a Raspberry Pi, but not a
    >>     Mustang.
    >>     
    >> We did some benchmarks with the Phoronix test suite a while ago, this will
    >> give you an idea:
    >> http://openbenchmarking.org/result/1708303-TR-
    >> 1703199RI93&obr_hgv=Traverse+LS1043+Prototype
    > 
    > I had a look at that. And yes indeed, it is a bit hard to figure out the
    > performance by the CPU name alone for most ARM SoCs. There is no branding in
    > order of performance (or similar) like Intel has.
    > 
    > That might actually turn out to be a bigger marketing problem, but we will see
    > that in the future.
    > 
    >> To give an idea of the Cortex (ARM designed)-based core performance:
    >>
    >> The LS1043 has the same A53 cores as the RPi3, but performs better due to
    >> having more cache, DDR4 etc (and higher clock).
    > 
    > Performance is also coming from the rest of the periphery. The RPi has a slow
    > and not very stable USB bus to talk to the network to and SD card storage. Even
    > with a faster CPU it might very often just wait for data.
    > 
    > We have been trying to tell people that they should look out for some specific
    > features like cache and good single-core performance.
    > 
    >> A72 is about double A53 in performance (and power consumption!) per MHz, as
    >> A72 is a modern out-of-order speculative core (it did get hit with the
    >> Meltdown/Spectre issue).
    > 
    > Yes, wouldn't mind to have some systems based on that one since the A53 will be
    > too slow for really large enterprise deployments.
    > 
    >> The latest gen of ARM64 server cores would all be well above A72, your Mustang
    >> is probably around the A72 level.
    >>
    >> In general, ARM network SoCs try to work 'smarter' instead of 'harder', so the
    >> high network performance comes from having very good network silicon, taking
    >> advantage of crypto accelerators etc.
    > 
    > I prefer the NICs in the SoC which gives great performance. The disadvantage
    > only is that they sometimes to odd configurations like 5x 1G and 1x 10G in this
    > case which I don't really understand. The only use-case that makes sense to me
    > is a server but for that the CPU is too slow and people would probably go for a
    > A72-class CPU.
    > 
    >>     > 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).
    >>     
    >>     What does the firmware do?
    >> It implements some vendor-specific power-management extensions (PSCI), as well
    >> as some TPM-like functions.
    >> NXP provides a good overview: https://github.com/qoriq-open-source/ppa-generic
    >> /blob/integration/ReleaseNotes.txt
    >> I am not a security expert, but it could be a good test environment for secure
    >> boot, private key storage and other things.
    > 
    > Great that this is entirely open.
    > 
    > -Michael
    > 
    >>
    >>     
    >> Cheers,
    >> Matt
    >>  
    >>
    >>
    
    -- 
    "We don't care.  We don't have to.  We're the Phone Company."
    
    

Re: ARM 64?

[Michael Tremer]

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

On Mon, 2018-06-18 at 09:40 +1000, Mathew McBride wrote:
> Hi Peter,
> There are two crypto options on our board:
> - ARMv8 Cryptography instructions (similar to AES-NI on x86)
> - Freescale SEC/CAAM engine (a 'hardware accelerator' that can do many
> TLS,IPSec etc. operations)
> I am certain that an RNG is part of the SEC engine, but I need to check the
> driver status on Linux.
> 
> /proc/crypto output for those interested:
> https://gist.github.com/mcbridematt/11f14c78ed4e35e97adf2f027010e374

Wow, that is a very extensive list of supported ciphers and hashes as well as
the combination of HMAC + cipher mode.

IPsec in the kernel will basically be not consuming any CPU cycles for crypto.

Best,
-Michael

> 
> Regards,
> Mathew 
> 
> On 15/6/18, 3:09 am, "Peter Müller" <peter.mueller(a)link38.eu> wrote:
> 
>     Hello,
>     
>     this board sounds very interesting indeed (trustworthy hardware - yay!).
>     However, after reading the datasheet it did not became clear to me if it
>     has some built-in random number generator and/or cryptography
> acceleration.
>     
>     Apart from some low-level backdoors (baked into USB, ... firmware chips)
>     it seems like this is suitable for security relevant devices. Looking
>     forward to hear some experiences with IPFire on it. :-)
>     
>     Best regards,
>     Peter Müller
>     
>     > Hey Matt,
>     > 
>     > On Mon, 2018-05-28 at 20:32 +1000, Mathew McBride wrote:
>     >> Hi Michael,
>     >>
>     >> Just in response to your questions:
>     >> On 25/5/18, 11:10 pm, "Michael Tremer" <michael.tremer(a)ipfire.org>
> wrote:
>     >>     
>     >>     
>     >>     I think you hardware is good enough for a builder. But I still am
> not sure
>     >> what
>     >>     to expect from the CPU. It will be faster than a Raspberry Pi, but
> not a
>     >>     Mustang.
>     >>     
>     >> We did some benchmarks with the Phoronix test suite a while ago, this
> will
>     >> give you an idea:
>     >> http://openbenchmarking.org/result/1708303-TR-
>     >> 1703199RI93&obr_hgv=Traverse+LS1043+Prototype
>     > 
>     > I had a look at that. And yes indeed, it is a bit hard to figure out the
>     > performance by the CPU name alone for most ARM SoCs. There is no
> branding in
>     > order of performance (or similar) like Intel has.
>     > 
>     > That might actually turn out to be a bigger marketing problem, but we
> will see
>     > that in the future.
>     > 
>     >> To give an idea of the Cortex (ARM designed)-based core performance:
>     >>
>     >> The LS1043 has the same A53 cores as the RPi3, but performs better due
> to
>     >> having more cache, DDR4 etc (and higher clock).
>     > 
>     > Performance is also coming from the rest of the periphery. The RPi has a
> slow
>     > and not very stable USB bus to talk to the network to and SD card
> storage. Even
>     > with a faster CPU it might very often just wait for data.
>     > 
>     > We have been trying to tell people that they should look out for some
> specific
>     > features like cache and good single-core performance.
>     > 
>     >> A72 is about double A53 in performance (and power consumption!) per
> MHz, as
>     >> A72 is a modern out-of-order speculative core (it did get hit with the
>     >> Meltdown/Spectre issue).
>     > 
>     > Yes, wouldn't mind to have some systems based on that one since the A53
> will be
>     > too slow for really large enterprise deployments.
>     > 
>     >> The latest gen of ARM64 server cores would all be well above A72, your
> Mustang
>     >> is probably around the A72 level.
>     >>
>     >> In general, ARM network SoCs try to work 'smarter' instead of 'harder',
> so the
>     >> high network performance comes from having very good network silicon,
> taking
>     >> advantage of crypto accelerators etc.
>     > 
>     > I prefer the NICs in the SoC which gives great performance. The
> disadvantage
>     > only is that they sometimes to odd configurations like 5x 1G and 1x 10G
> in this
>     > case which I don't really understand. The only use-case that makes sense
> to me
>     > is a server but for that the CPU is too slow and people would probably
> go for a
>     > A72-class CPU.
>     > 
>     >>     > 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).
>     >>     
>     >>     What does the firmware do?
>     >> It implements some vendor-specific power-management extensions (PSCI),
> as well
>     >> as some TPM-like functions.
>     >> NXP provides a good overview: https://github.com/qoriq-open-source/ppa-
> generic
>     >> /blob/integration/ReleaseNotes.txt
>     >> I am not a security expert, but it could be a good test environment for
> secure
>     >> boot, private key storage and other things.
>     > 
>     > Great that this is entirely open.
>     > 
>     > -Michael
>     > 
>     >>
>     >>     
>     >> Cheers,
>     >> Matt
>     >>  
>     >>
>     >>
>     
>     -- 
>     "We don't care.  We don't have to.  We're the Phone Company."
>     
>     
> 
> 

Re: ARM 64?

[Peter Müller]

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

Hello,

this looks quite good - I am strongly interested. :-)

Best regards,
Peter Müller

> On Mon, 2018-06-18 at 09:40 +1000, Mathew McBride wrote:
>> Hi Peter,
>> There are two crypto options on our board:
>> - ARMv8 Cryptography instructions (similar to AES-NI on x86)
>> - Freescale SEC/CAAM engine (a 'hardware accelerator' that can do many
>> TLS,IPSec etc. operations)
>> I am certain that an RNG is part of the SEC engine, but I need to check the
>> driver status on Linux.
>>
>> /proc/crypto output for those interested:
>> https://gist.github.com/mcbridematt/11f14c78ed4e35e97adf2f027010e374
> 
> Wow, that is a very extensive list of supported ciphers and hashes as well as
> the combination of HMAC + cipher mode.
> 
> IPsec in the kernel will basically be not consuming any CPU cycles for crypto.
> 
> Best,
> -Michael
> 
>>
>> Regards,
>> Mathew 
>>
>> On 15/6/18, 3:09 am, "Peter Müller" <peter.mueller(a)link38.eu> wrote:
>>
>>     Hello,
>>     
>>     this board sounds very interesting indeed (trustworthy hardware - yay!).
>>     However, after reading the datasheet it did not became clear to me if it
>>     has some built-in random number generator and/or cryptography
>> acceleration.
>>     
>>     Apart from some low-level backdoors (baked into USB, ... firmware chips)
>>     it seems like this is suitable for security relevant devices. Looking
>>     forward to hear some experiences with IPFire on it. :-)
>>     
>>     Best regards,
>>     Peter Müller
>>     
>>     > Hey Matt,
>>     > 
>>     > On Mon, 2018-05-28 at 20:32 +1000, Mathew McBride wrote:
>>     >> Hi Michael,
>>     >>
>>     >> Just in response to your questions:
>>     >> On 25/5/18, 11:10 pm, "Michael Tremer" <michael.tremer(a)ipfire.org>
>> wrote:
>>     >>     
>>     >>     
>>     >>     I think you hardware is good enough for a builder. But I still am
>> not sure
>>     >> what
>>     >>     to expect from the CPU. It will be faster than a Raspberry Pi, but
>> not a
>>     >>     Mustang.
>>     >>     
>>     >> We did some benchmarks with the Phoronix test suite a while ago, this
>> will
>>     >> give you an idea:
>>     >> http://openbenchmarking.org/result/1708303-TR-
>>     >> 1703199RI93&obr_hgv=Traverse+LS1043+Prototype
>>     > 
>>     > I had a look at that. And yes indeed, it is a bit hard to figure out the
>>     > performance by the CPU name alone for most ARM SoCs. There is no
>> branding in
>>     > order of performance (or similar) like Intel has.
>>     > 
>>     > That might actually turn out to be a bigger marketing problem, but we
>> will see
>>     > that in the future.
>>     > 
>>     >> To give an idea of the Cortex (ARM designed)-based core performance:
>>     >>
>>     >> The LS1043 has the same A53 cores as the RPi3, but performs better due
>> to
>>     >> having more cache, DDR4 etc (and higher clock).
>>     > 
>>     > Performance is also coming from the rest of the periphery. The RPi has a
>> slow
>>     > and not very stable USB bus to talk to the network to and SD card
>> storage. Even
>>     > with a faster CPU it might very often just wait for data.
>>     > 
>>     > We have been trying to tell people that they should look out for some
>> specific
>>     > features like cache and good single-core performance.
>>     > 
>>     >> A72 is about double A53 in performance (and power consumption!) per
>> MHz, as
>>     >> A72 is a modern out-of-order speculative core (it did get hit with the
>>     >> Meltdown/Spectre issue).
>>     > 
>>     > Yes, wouldn't mind to have some systems based on that one since the A53
>> will be
>>     > too slow for really large enterprise deployments.
>>     > 
>>     >> The latest gen of ARM64 server cores would all be well above A72, your
>> Mustang
>>     >> is probably around the A72 level.
>>     >>
>>     >> In general, ARM network SoCs try to work 'smarter' instead of 'harder',
>> so the
>>     >> high network performance comes from having very good network silicon,
>> taking
>>     >> advantage of crypto accelerators etc.
>>     > 
>>     > I prefer the NICs in the SoC which gives great performance. The
>> disadvantage
>>     > only is that they sometimes to odd configurations like 5x 1G and 1x 10G
>> in this
>>     > case which I don't really understand. The only use-case that makes sense
>> to me
>>     > is a server but for that the CPU is too slow and people would probably
>> go for a
>>     > A72-class CPU.
>>     > 
>>     >>     > 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).
>>     >>     
>>     >>     What does the firmware do?
>>     >> It implements some vendor-specific power-management extensions (PSCI),
>> as well
>>     >> as some TPM-like functions.
>>     >> NXP provides a good overview: https://github.com/qoriq-open-source/ppa-
>> generic
>>     >> /blob/integration/ReleaseNotes.txt
>>     >> I am not a security expert, but it could be a good test environment for
>> secure
>>     >> boot, private key storage and other things.
>>     > 
>>     > Great that this is entirely open.
>>     > 
>>     > -Michael
>>     > 
>>     >>
>>     >>     
>>     >> Cheers,
>>     >> Matt
>>     >>  
>>     >>
>>     >>
>>     
>>     -- 
>>     "We don't care.  We don't have to.  We're the Phone Company."
>>     
>>     
>>
>>

-- 
"We don't care.  We don't have to.  We're the Phone Company."


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: ARM 64?

[Michael Tremer]

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello guys,

so here is a quick status update on aarch64 & EFI:

* EFI: We have a separate branch with a bootloader that runs in EFI
mode for x86_64 and aarch64. We won't support 32 bit x86 and EFI.

It seems to be running quite okay on most hardware, although we haven't
really tested enough yet to say if is ready for production. All in all
we might merge it for Core 124, but since there was no feedback
whatsoever it is hard to make that decision, yet.

* aarch64: We got a booting kernel and userland. It runs on the RPi 3
with a little bit of manual configuration of the bootloader. Generally
I do not want to support any SBCs, but Arne used this one for testing
at least.

Since we don't have any other hardware and especially nothing that
supports EFI, we haven't brought the two things together, but are
looking forward to do this soon.

I have launched a virtual machine with both, aarch64 and EFI on the APM
Mustang that I have available and it is running well. It is fast, it is
stable and we don't expect a big backlog of bugs that we need to solve
before this is ready to be shipped.

So, that is the July update from my side. Please feel free to ask any
questions if there are any.

Best,
- -Michael

On Mon, 2018-06-18 at 18:11 +0200, Peter Müller wrote:
> Hello,
> 
> this looks quite good - I am strongly interested. :-)
> 
> Best regards,
> Peter Müller
> 
> > On Mon, 2018-06-18 at 09:40 +1000, Mathew McBride wrote:
> > > Hi Peter,
> > > There are two crypto options on our board:
> > > - ARMv8 Cryptography instructions (similar to AES-NI on x86)
> > > - Freescale SEC/CAAM engine (a 'hardware accelerator' that can do many
> > > TLS,IPSec etc. operations)
> > > I am certain that an RNG is part of the SEC engine, but I need to check the
> > > driver status on Linux.
> > > 
> > > /proc/crypto output for those interested:
> > > https://gist.github.com/mcbridematt/11f14c78ed4e35e97adf2f027010e374
> > 
> > Wow, that is a very extensive list of supported ciphers and hashes as well as
> > the combination of HMAC + cipher mode.
> > 
> > IPsec in the kernel will basically be not consuming any CPU cycles for crypto.
> > 
> > Best,
> > -Michael
> > 
> > > 
> > > Regards,
> > > Mathew 
> > > 
> > > On 15/6/18, 3:09 am, "Peter Müller" <peter.mueller(a)link38.eu> wrote:
> > > 
> > >     Hello,
> > >     
> > >     this board sounds very interesting indeed (trustworthy hardware - yay!).
> > >     However, after reading the datasheet it did not became clear to me if it
> > >     has some built-in random number generator and/or cryptography
> > > acceleration.
> > >     
> > >     Apart from some low-level backdoors (baked into USB, ... firmware chips)
> > >     it seems like this is suitable for security relevant devices. Looking
> > >     forward to hear some experiences with IPFire on it. :-)
> > >     
> > >     Best regards,
> > >     Peter Müller
> > >     
> > >     > Hey Matt,
> > >     > 
> > >     > On Mon, 2018-05-28 at 20:32 +1000, Mathew McBride wrote:
> > >     >> Hi Michael,
> > >     >>
> > >     >> Just in response to your questions:
> > >     >> On 25/5/18, 11:10 pm, "Michael Tremer" <michael.tremer(a)ipfire.org>
> > > wrote:
> > >     >>     
> > >     >>     
> > >     >>     I think you hardware is good enough for a builder. But I still am
> > > not sure
> > >     >> what
> > >     >>     to expect from the CPU. It will be faster than a Raspberry Pi, but
> > > not a
> > >     >>     Mustang.
> > >     >>     
> > >     >> We did some benchmarks with the Phoronix test suite a while ago, this
> > > will
> > >     >> give you an idea:
> > >     >> http://openbenchmarking.org/result/1708303-TR-
> > >     >> 1703199RI93&obr_hgv=Traverse+LS1043+Prototype
> > >     > 
> > >     > I had a look at that. And yes indeed, it is a bit hard to figure out the
> > >     > performance by the CPU name alone for most ARM SoCs. There is no
> > > branding in
> > >     > order of performance (or similar) like Intel has.
> > >     > 
> > >     > That might actually turn out to be a bigger marketing problem, but we
> > > will see
> > >     > that in the future.
> > >     > 
> > >     >> To give an idea of the Cortex (ARM designed)-based core performance:
> > >     >>
> > >     >> The LS1043 has the same A53 cores as the RPi3, but performs better due
> > > to
> > >     >> having more cache, DDR4 etc (and higher clock).
> > >     > 
> > >     > Performance is also coming from the rest of the periphery. The RPi has a
> > > slow
> > >     > and not very stable USB bus to talk to the network to and SD card
> > > storage. Even
> > >     > with a faster CPU it might very often just wait for data.
> > >     > 
> > >     > We have been trying to tell people that they should look out for some
> > > specific
> > >     > features like cache and good single-core performance.
> > >     > 
> > >     >> A72 is about double A53 in performance (and power consumption!) per
> > > MHz, as
> > >     >> A72 is a modern out-of-order speculative core (it did get hit with the
> > >     >> Meltdown/Spectre issue).
> > >     > 
> > >     > Yes, wouldn't mind to have some systems based on that one since the A53
> > > will be
> > >     > too slow for really large enterprise deployments.
> > >     > 
> > >     >> The latest gen of ARM64 server cores would all be well above A72, your
> > > Mustang
> > >     >> is probably around the A72 level.
> > >     >>
> > >     >> In general, ARM network SoCs try to work 'smarter' instead of 'harder',
> > > so the
> > >     >> high network performance comes from having very good network silicon,
> > > taking
> > >     >> advantage of crypto accelerators etc.
> > >     > 
> > >     > I prefer the NICs in the SoC which gives great performance. The
> > > disadvantage
> > >     > only is that they sometimes to odd configurations like 5x 1G and 1x 10G
> > > in this
> > >     > case which I don't really understand. The only use-case that makes sense
> > > to me
> > >     > is a server but for that the CPU is too slow and people would probably
> > > go for a
> > >     > A72-class CPU.
> > >     > 
> > >     >>     > 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).
> > >     >>     
> > >     >>     What does the firmware do?
> > >     >> It implements some vendor-specific power-management extensions (PSCI),
> > > as well
> > >     >> as some TPM-like functions.
> > >     >> NXP provides a good overview: https://github.com/qoriq-open-source/ppa-
> > > generic
> > >     >> /blob/integration/ReleaseNotes.txt
> > >     >> I am not a security expert, but it could be a good test environment for
> > > secure
> > >     >> boot, private key storage and other things.
> > >     > 
> > >     > Great that this is entirely open.
> > >     > 
> > >     > -Michael
> > >     > 
> > >     >>
> > >     >>     
> > >     >> Cheers,
> > >     >> Matt
> > >     >>  
> > >     >>
> > >     >>
> > >     
> > >     -- 
> > >     "We don't care.  We don't have to.  We're the Phone Company."
> > >     
> > >     
> > > 
> > > 
> 
> 
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE5/rW5l3GGe2ypktxgHnw/2+QCQcFAltZmUsACgkQgHnw/2+Q
CQcNfw//VkhXWguNNy/rsjeNLxNlzkJaeb9VXVar6vaTwvq6CcjgNtoRHJcsYU5t
Pk550WufwCeWk1b8VjmGrO1AAfMow/aXVfYJ+wlR0vpi/pwiX596wt1PLcGYMlCB
Ye8Zz4N1FjR1wh8Mqv1aH9AAYhzAKp80GM3bAxU4IRaENutMpdLnOpL9/tiMeoNs
hK9P9skFobvMVQxi+BoF8aWVJrpuVlNP56a/JE/8CVB85El7YnqxLixoDuL1GHjN
6E4CSqtLM8OY9morx32yxd9XvvanxiivAlCnzu8vII8OMuf050fGDV/WHTMlXNEc
S/C5Uua3tcGRInsf2LwPuZ3nMHL4nVIvLUMioMVeCEjoLftQOGgOUK/gV7AOYoy8
WicItyGRduY3IxB79LkRRKy7nZyRTeUm9zxEqsNmT6MquQDhrNa9hQB5LB2N3ZQv
L7CHgeXxtHt5F7n7PQJaICCf0Zl0BM4yP8NK5bpK8YVYP30s8dQxWBbhEuYDO241
ryYIaZ6Xv3cOEH7Md97+2aMsuyXepI/ZW/wpFI//MlkOXoWHNKLDyigmy5rPbQNW
gHIyp7xGOTYOoZPh/jii9dYDwQWNvNMESzC+AsYkBWLmyTYtsexIYts3FIXxunp8
9sqknx/jvhYNsR+9F8htZ9lAhI9fgqqGe9wBPp+blDRE/VNa+Jc=
=khkX
-----END PGP SIGNATURE-----

Re: ARM 64?

[Peter Müller]

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

Hello Michael,

thanks for the update. Sorry for high reply latencies here... :-|

Especially after recent Spectre NG security vulnerabilities I am
certainly interested in having some trustworthy hardware around. As
mentioned already, ARM64 sounds good so far - there is no need to
add another rant about the current situation on the CPU market.

@Mathew: Any updates from the hardware side? :-)

Best regards,
Peter Müller


> Hello guys,
> 
> so here is a quick status update on aarch64 & EFI:
> 
> * EFI: We have a separate branch with a bootloader that runs in EFI
> mode for x86_64 and aarch64. We won't support 32 bit x86 and EFI.
> 
> It seems to be running quite okay on most hardware, although we haven't
> really tested enough yet to say if is ready for production. All in all
> we might merge it for Core 124, but since there was no feedback
> whatsoever it is hard to make that decision, yet.
> 
> * aarch64: We got a booting kernel and userland. It runs on the RPi 3
> with a little bit of manual configuration of the bootloader. Generally
> I do not want to support any SBCs, but Arne used this one for testing
> at least.
> 
> Since we don't have any other hardware and especially nothing that
> supports EFI, we haven't brought the two things together, but are
> looking forward to do this soon.
> 
> I have launched a virtual machine with both, aarch64 and EFI on the APM
> Mustang that I have available and it is running well. It is fast, it is
> stable and we don't expect a big backlog of bugs that we need to solve
> before this is ready to be shipped.
> 
> So, that is the July update from my side. Please feel free to ask any
> questions if there are any.
> 
> Best,
> -Michael
> 
> On Mon, 2018-06-18 at 18:11 +0200, Peter Müller wrote:
>> Hello,
> 
>> this looks quite good - I am strongly interested. :-)
> 
>> Best regards,
>> Peter Müller
> 
>>> On Mon, 2018-06-18 at 09:40 +1000, Mathew McBride wrote:
>>>> Hi Peter,
>>>> There are two crypto options on our board:
>>>> - ARMv8 Cryptography instructions (similar to AES-NI on x86)
>>>> - Freescale SEC/CAAM engine (a 'hardware accelerator' that can do many
>>>> TLS,IPSec etc. operations)
>>>> I am certain that an RNG is part of the SEC engine, but I need to check the
>>>> driver status on Linux.
>>>>
>>>> /proc/crypto output for those interested:
>>>> https://gist.github.com/mcbridematt/11f14c78ed4e35e97adf2f027010e374
>>>
>>> Wow, that is a very extensive list of supported ciphers and hashes as well as
>>> the combination of HMAC + cipher mode.
>>>
>>> IPsec in the kernel will basically be not consuming any CPU cycles for crypto.
>>>
>>> Best,
>>> -Michael
>>>
>>>>
>>>> Regards,
>>>> Mathew 
>>>>
>>>> On 15/6/18, 3:09 am, "Peter Müller" <peter.mueller(a)link38.eu> wrote:
>>>>
>>>>     Hello,
>>>>     
>>>>     this board sounds very interesting indeed (trustworthy hardware - yay!).
>>>>     However, after reading the datasheet it did not became clear to me if it
>>>>     has some built-in random number generator and/or cryptography
>>>> acceleration.
>>>>     
>>>>     Apart from some low-level backdoors (baked into USB, ... firmware chips)
>>>>     it seems like this is suitable for security relevant devices. Looking
>>>>     forward to hear some experiences with IPFire on it. :-)
>>>>     
>>>>     Best regards,
>>>>     Peter Müller
>>>>     
>>>>     > Hey Matt,
>>>>     > 
>>>>     > On Mon, 2018-05-28 at 20:32 +1000, Mathew McBride wrote:
>>>>     >> Hi Michael,
>>>>     >>
>>>>     >> Just in response to your questions:
>>>>     >> On 25/5/18, 11:10 pm, "Michael Tremer" <michael.tremer(a)ipfire.org>
>>>> wrote:
>>>>     >>     
>>>>     >>     
>>>>     >>     I think you hardware is good enough for a builder. But I still am
>>>> not sure
>>>>     >> what
>>>>     >>     to expect from the CPU. It will be faster than a Raspberry Pi, but
>>>> not a
>>>>     >>     Mustang.
>>>>     >>     
>>>>     >> We did some benchmarks with the Phoronix test suite a while ago, this
>>>> will
>>>>     >> give you an idea:
>>>>     >> http://openbenchmarking.org/result/1708303-TR-
>>>>     >> 1703199RI93&obr_hgv=Traverse+LS1043+Prototype
>>>>     > 
>>>>     > I had a look at that. And yes indeed, it is a bit hard to figure out the
>>>>     > performance by the CPU name alone for most ARM SoCs. There is no
>>>> branding in
>>>>     > order of performance (or similar) like Intel has.
>>>>     > 
>>>>     > That might actually turn out to be a bigger marketing problem, but we
>>>> will see
>>>>     > that in the future.
>>>>     > 
>>>>     >> To give an idea of the Cortex (ARM designed)-based core performance:
>>>>     >>
>>>>     >> The LS1043 has the same A53 cores as the RPi3, but performs better due
>>>> to
>>>>     >> having more cache, DDR4 etc (and higher clock).
>>>>     > 
>>>>     > Performance is also coming from the rest of the periphery. The RPi has a
>>>> slow
>>>>     > and not very stable USB bus to talk to the network to and SD card
>>>> storage. Even
>>>>     > with a faster CPU it might very often just wait for data.
>>>>     > 
>>>>     > We have been trying to tell people that they should look out for some
>>>> specific
>>>>     > features like cache and good single-core performance.
>>>>     > 
>>>>     >> A72 is about double A53 in performance (and power consumption!) per
>>>> MHz, as
>>>>     >> A72 is a modern out-of-order speculative core (it did get hit with the
>>>>     >> Meltdown/Spectre issue).
>>>>     > 
>>>>     > Yes, wouldn't mind to have some systems based on that one since the A53
>>>> will be
>>>>     > too slow for really large enterprise deployments.
>>>>     > 
>>>>     >> The latest gen of ARM64 server cores would all be well above A72, your
>>>> Mustang
>>>>     >> is probably around the A72 level.
>>>>     >>
>>>>     >> In general, ARM network SoCs try to work 'smarter' instead of 'harder',
>>>> so the
>>>>     >> high network performance comes from having very good network silicon,
>>>> taking
>>>>     >> advantage of crypto accelerators etc.
>>>>     > 
>>>>     > I prefer the NICs in the SoC which gives great performance. The
>>>> disadvantage
>>>>     > only is that they sometimes to odd configurations like 5x 1G and 1x 10G
>>>> in this
>>>>     > case which I don't really understand. The only use-case that makes sense
>>>> to me
>>>>     > is a server but for that the CPU is too slow and people would probably
>>>> go for a
>>>>     > A72-class CPU.
>>>>     > 
>>>>     >>     > 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).
>>>>     >>     
>>>>     >>     What does the firmware do?
>>>>     >> It implements some vendor-specific power-management extensions (PSCI),
>>>> as well
>>>>     >> as some TPM-like functions.
>>>>     >> NXP provides a good overview: https://github.com/qoriq-open-source/ppa-
>>>> generic
>>>>     >> /blob/integration/ReleaseNotes.txt
>>>>     >> I am not a security expert, but it could be a good test environment for
>>>> secure
>>>>     >> boot, private key storage and other things.
>>>>     > 
>>>>     > Great that this is entirely open.
>>>>     > 
>>>>     > -Michael
>>>>     > 
>>>>     >>
>>>>     >>     
>>>>     >> Cheers,
>>>>     >> Matt
>>>>     >>  
>>>>     >>
>>>>     >>
>>>>     
>>>>     -- 
>>>>     "We don't care.  We don't have to.  We're the Phone Company."
>>>>     
>>>>     
>>>>
>>>>
> 
> 
> 

-- 
"We don't care.  We don't have to.  We're the Phone Company."


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: ARM 64?

[Mathew McBride]

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

Hi Michael,
I gave the arm64 snapshot a go under virtualization on our boards. 
The kernel dies very quickly, I had to use earlycon to get some output.

It looks like ACPI isn't enabled? (CONFIG_ACPI=n in config/kernel/kernel.config.aarch64-ipfire)

Our board does not use ACPI, but under virtualization, the Linaro UEFI/EDK2 blobs for QEMU use ACPI exclusively, as do recent "ARM Server"/SBSA boards I believe. Your APM Mustang certainly pre-dates the 'mainstream' ARM64 switch to ACPI.
CONFIG_ACPI=y will not prevent the kernel working on boards that use the FDT/Device tree method, just that an ACPI device table will be used instead of FDT if it exists.

Here is the set of options I use (I think these are the arm64 defaults) that work with EDK2:
https://gitlab.com/traversetech/traverse-kernel-patches/blob/kernel-4-14/kernel-config#L4102

efi: Getting EFI parameters from FDT:
efi: EFI v2.60 by EDK II
efi:  SMBIOS 3.0=0x5bdb0000  ACPI 2.0=0x585b0000  MEMATTR=0x58e27018
cma: Reserved 8 MiB at 0x000000005f800000
Failed to find device node for boot cpu
missing boot CPU MPIDR, not enabling secondaries
..
Kernel panic - not syncing: No interrupt controller found.
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.50-ipfire #1
Call trace:
[<ffffff800808b078>] dump_backtrace+0x0/0x288
[<ffffff800808b324>] show_stack+0x24/0x30
[<ffffff80088dc108>] dump_stack+0x9c/0xbc
[<ffffff80080a7b14>] panic+0x140/0x29c
[<ffffff8008e07c30>] init_IRQ+0x1c8/0x208
[<ffffff8008e016c4>] start_kernel+0x33c/0x5a0
Rebooting in 10 seconds..
Reboot failed -- System halted

Full boot log attached.

Cheers,
Matt


On 26/7/18, 7:50 pm, "Michael Tremer" <michael.tremer(a)ipfire.org> wrote:

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA512
    
    Hello guys,
    
    so here is a quick status update on aarch64 & EFI:
    
    * EFI: We have a separate branch with a bootloader that runs in EFI
    mode for x86_64 and aarch64. We won't support 32 bit x86 and EFI.
    
    It seems to be running quite okay on most hardware, although we haven't
    really tested enough yet to say if is ready for production. All in all
    we might merge it for Core 124, but since there was no feedback
    whatsoever it is hard to make that decision, yet.
    
    * aarch64: We got a booting kernel and userland. It runs on the RPi 3
    with a little bit of manual configuration of the bootloader. Generally
    I do not want to support any SBCs, but Arne used this one for testing
    at least.
    
    Since we don't have any other hardware and especially nothing that
    supports EFI, we haven't brought the two things together, but are
    looking forward to do this soon.
    
    I have launched a virtual machine with both, aarch64 and EFI on the APM
    Mustang that I have available and it is running well. It is fast, it is
    stable and we don't expect a big backlog of bugs that we need to solve
    before this is ready to be shipped.
    
    So, that is the July update from my side. Please feel free to ask any
    questions if there are any.
    
    Best,
    - -Michael
    
    On Mon, 2018-06-18 at 18:11 +0200, Peter Müller wrote:
    > Hello,
    > 
    > this looks quite good - I am strongly interested. :-)
    > 
    > Best regards,
    > Peter Müller
    > 
    > > On Mon, 2018-06-18 at 09:40 +1000, Mathew McBride wrote:
    > > > Hi Peter,
    > > > There are two crypto options on our board:
    > > > - ARMv8 Cryptography instructions (similar to AES-NI on x86)
    > > > - Freescale SEC/CAAM engine (a 'hardware accelerator' that can do many
    > > > TLS,IPSec etc. operations)
    > > > I am certain that an RNG is part of the SEC engine, but I need to check the
    > > > driver status on Linux.
    > > > 
    > > > /proc/crypto output for those interested:
    > > > https://gist.github.com/mcbridematt/11f14c78ed4e35e97adf2f027010e374
    > > 
    > > Wow, that is a very extensive list of supported ciphers and hashes as well as
    > > the combination of HMAC + cipher mode.
    > > 
    > > IPsec in the kernel will basically be not consuming any CPU cycles for crypto.
    > > 
    > > Best,
    > > -Michael
    > > 
    > > > 
    > > > Regards,
    > > > Mathew 
    > > > 
    > > > On 15/6/18, 3:09 am, "Peter Müller" <peter.mueller(a)link38.eu> wrote:
    > > > 
    > > >     Hello,
    > > >     
    > > >     this board sounds very interesting indeed (trustworthy hardware - yay!).
    > > >     However, after reading the datasheet it did not became clear to me if it
    > > >     has some built-in random number generator and/or cryptography
    > > > acceleration.
    > > >     
    > > >     Apart from some low-level backdoors (baked into USB, ... firmware chips)
    > > >     it seems like this is suitable for security relevant devices. Looking
    > > >     forward to hear some experiences with IPFire on it. :-)
    > > >     
    > > >     Best regards,
    > > >     Peter Müller
    > > >     
    > > >     > Hey Matt,
    > > >     > 
    > > >     > On Mon, 2018-05-28 at 20:32 +1000, Mathew McBride wrote:
    > > >     >> Hi Michael,
    > > >     >>
    > > >     >> Just in response to your questions:
    > > >     >> On 25/5/18, 11:10 pm, "Michael Tremer" <michael.tremer(a)ipfire.org>
    > > > wrote:
    > > >     >>     
    > > >     >>     
    > > >     >>     I think you hardware is good enough for a builder. But I still am
    > > > not sure
    > > >     >> what
    > > >     >>     to expect from the CPU. It will be faster than a Raspberry Pi, but
    > > > not a
    > > >     >>     Mustang.
    > > >     >>     
    > > >     >> We did some benchmarks with the Phoronix test suite a while ago, this
    > > > will
    > > >     >> give you an idea:
    > > >     >> http://openbenchmarking.org/result/1708303-TR-
    > > >     >> 1703199RI93&obr_hgv=Traverse+LS1043+Prototype
    > > >     > 
    > > >     > I had a look at that. And yes indeed, it is a bit hard to figure out the
    > > >     > performance by the CPU name alone for most ARM SoCs. There is no
    > > > branding in
    > > >     > order of performance (or similar) like Intel has.
    > > >     > 
    > > >     > That might actually turn out to be a bigger marketing problem, but we
    > > > will see
    > > >     > that in the future.
    > > >     > 
    > > >     >> To give an idea of the Cortex (ARM designed)-based core performance:
    > > >     >>
    > > >     >> The LS1043 has the same A53 cores as the RPi3, but performs better due
    > > > to
    > > >     >> having more cache, DDR4 etc (and higher clock).
    > > >     > 
    > > >     > Performance is also coming from the rest of the periphery. The RPi has a
    > > > slow
    > > >     > and not very stable USB bus to talk to the network to and SD card
    > > > storage. Even
    > > >     > with a faster CPU it might very often just wait for data.
    > > >     > 
    > > >     > We have been trying to tell people that they should look out for some
    > > > specific
    > > >     > features like cache and good single-core performance.
    > > >     > 
    > > >     >> A72 is about double A53 in performance (and power consumption!) per
    > > > MHz, as
    > > >     >> A72 is a modern out-of-order speculative core (it did get hit with the
    > > >     >> Meltdown/Spectre issue).
    > > >     > 
    > > >     > Yes, wouldn't mind to have some systems based on that one since the A53
    > > > will be
    > > >     > too slow for really large enterprise deployments.
    > > >     > 
    > > >     >> The latest gen of ARM64 server cores would all be well above A72, your
    > > > Mustang
    > > >     >> is probably around the A72 level.
    > > >     >>
    > > >     >> In general, ARM network SoCs try to work 'smarter' instead of 'harder',
    > > > so the
    > > >     >> high network performance comes from having very good network silicon,
    > > > taking
    > > >     >> advantage of crypto accelerators etc.
    > > >     > 
    > > >     > I prefer the NICs in the SoC which gives great performance. The
    > > > disadvantage
    > > >     > only is that they sometimes to odd configurations like 5x 1G and 1x 10G
    > > > in this
    > > >     > case which I don't really understand. The only use-case that makes sense
    > > > to me
    > > >     > is a server but for that the CPU is too slow and people would probably
    > > > go for a
    > > >     > A72-class CPU.
    > > >     > 
    > > >     >>     > 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).
    > > >     >>     
    > > >     >>     What does the firmware do?
    > > >     >> It implements some vendor-specific power-management extensions (PSCI),
    > > > as well
    > > >     >> as some TPM-like functions.
    > > >     >> NXP provides a good overview: https://github.com/qoriq-open-source/ppa-
    > > > generic
    > > >     >> /blob/integration/ReleaseNotes.txt
    > > >     >> I am not a security expert, but it could be a good test environment for
    > > > secure
    > > >     >> boot, private key storage and other things.
    > > >     > 
    > > >     > Great that this is entirely open.
    > > >     > 
    > > >     > -Michael
    > > >     > 
    > > >     >>
    > > >     >>     
    > > >     >> Cheers,
    > > >     >> Matt
    > > >     >>  
    > > >     >>
    > > >     >>
    > > >     
    > > >     -- 
    > > >     "We don't care.  We don't have to.  We're the Phone Company."
    > > >     
    > > >     
    > > > 
    > > > 
    > 
    > 
    -----BEGIN PGP SIGNATURE-----
    
    iQIzBAEBCgAdFiEE5/rW5l3GGe2ypktxgHnw/2+QCQcFAltZmUsACgkQgHnw/2+Q
    CQcNfw//VkhXWguNNy/rsjeNLxNlzkJaeb9VXVar6vaTwvq6CcjgNtoRHJcsYU5t
    Pk550WufwCeWk1b8VjmGrO1AAfMow/aXVfYJ+wlR0vpi/pwiX596wt1PLcGYMlCB
    Ye8Zz4N1FjR1wh8Mqv1aH9AAYhzAKp80GM3bAxU4IRaENutMpdLnOpL9/tiMeoNs
    hK9P9skFobvMVQxi+BoF8aWVJrpuVlNP56a/JE/8CVB85El7YnqxLixoDuL1GHjN
    6E4CSqtLM8OY9morx32yxd9XvvanxiivAlCnzu8vII8OMuf050fGDV/WHTMlXNEc
    S/C5Uua3tcGRInsf2LwPuZ3nMHL4nVIvLUMioMVeCEjoLftQOGgOUK/gV7AOYoy8
    WicItyGRduY3IxB79LkRRKy7nZyRTeUm9zxEqsNmT6MquQDhrNa9hQB5LB2N3ZQv
    L7CHgeXxtHt5F7n7PQJaICCf0Zl0BM4yP8NK5bpK8YVYP30s8dQxWBbhEuYDO241
    ryYIaZ6Xv3cOEH7Md97+2aMsuyXepI/ZW/wpFI//MlkOXoWHNKLDyigmy5rPbQNW
    gHIyp7xGOTYOoZPh/jii9dYDwQWNvNMESzC+AsYkBWLmyTYtsexIYts3FIXxunp8
    9sqknx/jvhYNsR+9F8htZ9lAhI9fgqqGe9wBPp+blDRE/VNa+Jc=
    =khkX
    -----END PGP SIGNATURE-----
    
    




[-- Attachment #2: ipfire-edk2-failure.txt --]
[-- Type: text/plain, Size: 3130 bytes --]

Loading Linux 4.14.50-ipfire ...
Loading initial ramdisk ...
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
Booting Linux on physical CPU 0x0
Linux version 4.14.50-ipfire (root@arm64-01.builders.ipfire.org) (gcc version 7.3.0 (GCC)) #1 SMP Tue Jul 31 18:37:31 GMT 2018
Boot CPU: AArch64 Processor [410fd034]
earlycon: pl11 at MMIO 0x0000000009000000 (options '')
bootconsole [pl11] enabled
efi: Getting EFI parameters from FDT:
efi: EFI v2.60 by EDK II
efi:  SMBIOS 3.0=0x5bdb0000  ACPI 2.0=0x585b0000  MEMATTR=0x58e27018
cma: Reserved 8 MiB at 0x000000005f800000
Failed to find device node for boot cpu
missing boot CPU MPIDR, not enabling secondaries
random: get_random_bytes called from start_kernel+0xe4/0x5a0 with crng_init=0
percpu: Embedded 22 pages/cpu @ffffffc01f7db000 s49176 r8192 d32744 u90112
Detected VIPT I-cache on CPU0
CPU features: enabling workaround for ARM erratum 845719
Built 1 zonelists, mobility grouping on.  Total pages: 129024
Kernel command line: BOOT_IMAGE=/vmlinuz-4.14.50-ipfire root=UUID=75fb2f6c-ed03-4f5c-820a-0b7d764d89fe earlycon=pl011,0x9000000 ro panic=10
PID hash table entries: 2048 (order: 2, 16384 bytes)
Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)
Inode-cache hash table entries: 32768 (order: 6, 262144 bytes)
Memory: 467604K/524288K available (9724K kernel code, 1308K rwdata, 3348K rodata, 2048K init, 527K bss, 48492K reserved, 8192K cma-reserved)
Virtual kernel memory layout:
    modules : 0xffffff8000000000 - 0xffffff8008000000   (   128 MB)
    vmalloc : 0xffffff8008000000 - 0xffffffbebfff0000   (   250 GB)
      .text : 0xffffff8008080000 - 0xffffff8008a00000   (  9728 KB)
    .rodata : 0xffffff8008a00000 - 0xffffff8008e00000   (  4096 KB)
      .init : 0xffffff8008e00000 - 0xffffff8009000000   (  2048 KB)
      .data : 0xffffff8009000000 - 0xffffff8009147200   (  1309 KB)
       .bss : 0xffffff8009147200 - 0xffffff80091cb058   (   528 KB)
    fixed   : 0xffffffbefe7fb000 - 0xffffffbefec00000   (  4116 KB)
    PCI I/O : 0xffffffbefee00000 - 0xffffffbeffe00000   (    16 MB)
    vmemmap : 0xffffffbf00000000 - 0xffffffc000000000   (     4 GB maximum)
              0xffffffbf00000000 - 0xffffffbf00800000   (     8 MB actual)
    memory  : 0xffffffc000000000 - 0xffffffc020000000   (   512 MB)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
ftrace: allocating 30266 entries in 119 pages
Hierarchical RCU implementation.
        RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=1.
RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
Kernel panic - not syncing: No interrupt controller found.
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.50-ipfire #1
Call trace:
[<ffffff800808b078>] dump_backtrace+0x0/0x288
[<ffffff800808b324>] show_stack+0x24/0x30
[<ffffff80088dc108>] dump_stack+0x9c/0xbc
[<ffffff80080a7b14>] panic+0x140/0x29c
[<ffffff8008e07c30>] init_IRQ+0x1c8/0x208
[<ffffff8008e016c4>] start_kernel+0x33c/0x5a0
Rebooting in 10 seconds..
Reboot failed -- System halted

Re: ARM 64?

[Michael Tremer]

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

Hello,

On Sun, 2018-08-19 at 18:54 +1000, Mathew McBride wrote:
> Hi Michael,
> I gave the arm64 snapshot a go under virtualization on our boards. 
> The kernel dies very quickly, I had to use earlycon to get some output.
> 
> It looks like ACPI isn't enabled? (CONFIG_ACPI=n in
> config/kernel/kernel.config.aarch64-ipfire)

Yes, that might be possible.

The ARM64 configuration came from the 32 bit ARM build and that was terribly
stripped down, because it doesn't have support for things like PCI, EFI and no
ACPI either - and if it does in theory, nobody is using that in the real world.

> Our board does not use ACPI, but under virtualization, the Linaro UEFI/EDK2
> blobs for QEMU use ACPI exclusively, as do recent "ARM Server"/SBSA boards I
> believe. Your APM Mustang certainly pre-dates the 'mainstream' ARM64 switch to
> ACPI.

I have only been running it as a virtual machine on the Mustang and not
natively. So potentially it won't run there either because I upgraded my machine
to EFI and I guess that needs ACPI on bare-metal. But I am not sure. Didn't test
it.

> CONFIG_ACPI=y will not prevent the kernel working on boards that use the
> FDT/Device tree method, just that an ACPI device table will be used instead of
> FDT if it exists.
> 
> Here is the set of options I use (I think these are the arm64 defaults) that
> work with EDK2:
> 
https://gitlab.com/traversetech/traverse-kernel-patches/blob/kernel-4-14/kernel-config#L4102

You can edit the kernel configuration if you want and then rebuild the whole
distribution. Eventually this will give you an image that runs.

I am not sure what we can test without hardware here. Maybe Arne can say
something about that.

But thanks for looking into things so far!

Best,
-Michael

> 
> efi: Getting EFI parameters from FDT:
> efi: EFI v2.60 by EDK II
> efi:  SMBIOS 3.0=0x5bdb0000  ACPI 2.0=0x585b0000  MEMATTR=0x58e27018
> cma: Reserved 8 MiB at 0x000000005f800000
> Failed to find device node for boot cpu
> missing boot CPU MPIDR, not enabling secondaries
> ..
> Kernel panic - not syncing: No interrupt controller found.
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.50-ipfire #1
> Call trace:
> [<ffffff800808b078>] dump_backtrace+0x0/0x288
> [<ffffff800808b324>] show_stack+0x24/0x30
> [<ffffff80088dc108>] dump_stack+0x9c/0xbc
> [<ffffff80080a7b14>] panic+0x140/0x29c
> [<ffffff8008e07c30>] init_IRQ+0x1c8/0x208
> [<ffffff8008e016c4>] start_kernel+0x33c/0x5a0
> Rebooting in 10 seconds..
> Reboot failed -- System halted
> 
> Full boot log attached.
> 
> Cheers,
> Matt
> 
> 
> On 26/7/18, 7:50 pm, "Michael Tremer" <michael.tremer(a)ipfire.org> wrote:
> 
>     -----BEGIN PGP SIGNED MESSAGE-----
>     Hash: SHA512
>     
>     Hello guys,
>     
>     so here is a quick status update on aarch64 & EFI:
>     
>     * EFI: We have a separate branch with a bootloader that runs in EFI
>     mode for x86_64 and aarch64. We won't support 32 bit x86 and EFI.
>     
>     It seems to be running quite okay on most hardware, although we haven't
>     really tested enough yet to say if is ready for production. All in all
>     we might merge it for Core 124, but since there was no feedback
>     whatsoever it is hard to make that decision, yet.
>     
>     * aarch64: We got a booting kernel and userland. It runs on the RPi 3
>     with a little bit of manual configuration of the bootloader. Generally
>     I do not want to support any SBCs, but Arne used this one for testing
>     at least.
>     
>     Since we don't have any other hardware and especially nothing that
>     supports EFI, we haven't brought the two things together, but are
>     looking forward to do this soon.
>     
>     I have launched a virtual machine with both, aarch64 and EFI on the APM
>     Mustang that I have available and it is running well. It is fast, it is
>     stable and we don't expect a big backlog of bugs that we need to solve
>     before this is ready to be shipped.
>     
>     So, that is the July update from my side. Please feel free to ask any
>     questions if there are any.
>     
>     Best,
>     - -Michael
>     
>     On Mon, 2018-06-18 at 18:11 +0200, Peter Müller wrote:
>     > Hello,
>     > 
>     > this looks quite good - I am strongly interested. :-)
>     > 
>     > Best regards,
>     > Peter Müller
>     > 
>     > > On Mon, 2018-06-18 at 09:40 +1000, Mathew McBride wrote:
>     > > > Hi Peter,
>     > > > There are two crypto options on our board:
>     > > > - ARMv8 Cryptography instructions (similar to AES-NI on x86)
>     > > > - Freescale SEC/CAAM engine (a 'hardware accelerator' that can do
> many
>     > > > TLS,IPSec etc. operations)
>     > > > I am certain that an RNG is part of the SEC engine, but I need to
> check the
>     > > > driver status on Linux.
>     > > > 
>     > > > /proc/crypto output for those interested:
>     > > > https://gist.github.com/mcbridematt/11f14c78ed4e35e97adf2f027010e374
>     > > 
>     > > Wow, that is a very extensive list of supported ciphers and hashes as
> well as
>     > > the combination of HMAC + cipher mode.
>     > > 
>     > > IPsec in the kernel will basically be not consuming any CPU cycles for
> crypto.
>     > > 
>     > > Best,
>     > > -Michael
>     > > 
>     > > > 
>     > > > Regards,
>     > > > Mathew 
>     > > > 
>     > > > On 15/6/18, 3:09 am, "Peter Müller" <peter.mueller(a)link38.eu>
> wrote:
>     > > > 
>     > > >     Hello,
>     > > >     
>     > > >     this board sounds very interesting indeed (trustworthy hardware
> - yay!).
>     > > >     However, after reading the datasheet it did not became clear to
> me if it
>     > > >     has some built-in random number generator and/or cryptography
>     > > > acceleration.
>     > > >     
>     > > >     Apart from some low-level backdoors (baked into USB, ...
> firmware chips)
>     > > >     it seems like this is suitable for security relevant devices.
> Looking
>     > > >     forward to hear some experiences with IPFire on it. :-)
>     > > >     
>     > > >     Best regards,
>     > > >     Peter Müller
>     > > >     
>     > > >     > Hey Matt,
>     > > >     > 
>     > > >     > On Mon, 2018-05-28 at 20:32 +1000, Mathew McBride wrote:
>     > > >     >> Hi Michael,
>     > > >     >>
>     > > >     >> Just in response to your questions:
>     > > >     >> On 25/5/18, 11:10 pm, "Michael Tremer" <
> michael.tremer(a)ipfire.org>
>     > > > wrote:
>     > > >     >>     
>     > > >     >>     
>     > > >     >>     I think you hardware is good enough for a builder. But I
> still am
>     > > > not sure
>     > > >     >> what
>     > > >     >>     to expect from the CPU. It will be faster than a
> Raspberry Pi, but
>     > > > not a
>     > > >     >>     Mustang.
>     > > >     >>     
>     > > >     >> We did some benchmarks with the Phoronix test suite a while
> ago, this
>     > > > will
>     > > >     >> give you an idea:
>     > > >     >> http://openbenchmarking.org/result/1708303-TR-
>     > > >     >> 1703199RI93&obr_hgv=Traverse+LS1043+Prototype
>     > > >     > 
>     > > >     > I had a look at that. And yes indeed, it is a bit hard to
> figure out the
>     > > >     > performance by the CPU name alone for most ARM SoCs. There is
> no
>     > > > branding in
>     > > >     > order of performance (or similar) like Intel has.
>     > > >     > 
>     > > >     > That might actually turn out to be a bigger marketing problem,
> but we
>     > > > will see
>     > > >     > that in the future.
>     > > >     > 
>     > > >     >> To give an idea of the Cortex (ARM designed)-based core
> performance:
>     > > >     >>
>     > > >     >> The LS1043 has the same A53 cores as the RPi3, but performs
> better due
>     > > > to
>     > > >     >> having more cache, DDR4 etc (and higher clock).
>     > > >     > 
>     > > >     > Performance is also coming from the rest of the periphery. The
> RPi has a
>     > > > slow
>     > > >     > and not very stable USB bus to talk to the network to and SD
> card
>     > > > storage. Even
>     > > >     > with a faster CPU it might very often just wait for data.
>     > > >     > 
>     > > >     > We have been trying to tell people that they should look out
> for some
>     > > > specific
>     > > >     > features like cache and good single-core performance.
>     > > >     > 
>     > > >     >> A72 is about double A53 in performance (and power
> consumption!) per
>     > > > MHz, as
>     > > >     >> A72 is a modern out-of-order speculative core (it did get hit
> with the
>     > > >     >> Meltdown/Spectre issue).
>     > > >     > 
>     > > >     > Yes, wouldn't mind to have some systems based on that one
> since the A53
>     > > > will be
>     > > >     > too slow for really large enterprise deployments.
>     > > >     > 
>     > > >     >> The latest gen of ARM64 server cores would all be well above
> A72, your
>     > > > Mustang
>     > > >     >> is probably around the A72 level.
>     > > >     >>
>     > > >     >> In general, ARM network SoCs try to work 'smarter' instead of
> 'harder',
>     > > > so the
>     > > >     >> high network performance comes from having very good network
> silicon,
>     > > > taking
>     > > >     >> advantage of crypto accelerators etc.
>     > > >     > 
>     > > >     > I prefer the NICs in the SoC which gives great performance.
> The
>     > > > disadvantage
>     > > >     > only is that they sometimes to odd configurations like 5x 1G
> and 1x 10G
>     > > > in this
>     > > >     > case which I don't really understand. The only use-case that
> makes sense
>     > > > to me
>     > > >     > is a server but for that the CPU is too slow and people would
> probably
>     > > > go for a
>     > > >     > A72-class CPU.
>     > > >     > 
>     > > >     >>     > 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).
>     > > >     >>     
>     > > >     >>     What does the firmware do?
>     > > >     >> It implements some vendor-specific power-management
> extensions (PSCI),
>     > > > as well
>     > > >     >> as some TPM-like functions.
>     > > >     >> NXP provides a good overview: 
> https://github.com/qoriq-open-source/ppa-
>     > > > generic
>     > > >     >> /blob/integration/ReleaseNotes.txt
>     > > >     >> I am not a security expert, but it could be a good test
> environment for
>     > > > secure
>     > > >     >> boot, private key storage and other things.
>     > > >     > 
>     > > >     > Great that this is entirely open.
>     > > >     > 
>     > > >     > -Michael
>     > > >     > 
>     > > >     >>
>     > > >     >>     
>     > > >     >> Cheers,
>     > > >     >> Matt
>     > > >     >>  
>     > > >     >>
>     > > >     >>
>     > > >     
>     > > >     -- 
>     > > >     "We don't care.  We don't have to.  We're the Phone Company."
>     > > >     
>     > > >     
>     > > > 
>     > > > 
>     > 
>     > 
>     -----BEGIN PGP SIGNATURE-----
>     
>     iQIzBAEBCgAdFiEE5/rW5l3GGe2ypktxgHnw/2+QCQcFAltZmUsACgkQgHnw/2+Q
>     CQcNfw//VkhXWguNNy/rsjeNLxNlzkJaeb9VXVar6vaTwvq6CcjgNtoRHJcsYU5t
>     Pk550WufwCeWk1b8VjmGrO1AAfMow/aXVfYJ+wlR0vpi/pwiX596wt1PLcGYMlCB
>     Ye8Zz4N1FjR1wh8Mqv1aH9AAYhzAKp80GM3bAxU4IRaENutMpdLnOpL9/tiMeoNs
>     hK9P9skFobvMVQxi+BoF8aWVJrpuVlNP56a/JE/8CVB85El7YnqxLixoDuL1GHjN
>     6E4CSqtLM8OY9morx32yxd9XvvanxiivAlCnzu8vII8OMuf050fGDV/WHTMlXNEc
>     S/C5Uua3tcGRInsf2LwPuZ3nMHL4nVIvLUMioMVeCEjoLftQOGgOUK/gV7AOYoy8
>     WicItyGRduY3IxB79LkRRKy7nZyRTeUm9zxEqsNmT6MquQDhrNa9hQB5LB2N3ZQv
>     L7CHgeXxtHt5F7n7PQJaICCf0Zl0BM4yP8NK5bpK8YVYP30s8dQxWBbhEuYDO241
>     ryYIaZ6Xv3cOEH7Md97+2aMsuyXepI/ZW/wpFI//MlkOXoWHNKLDyigmy5rPbQNW
>     gHIyp7xGOTYOoZPh/jii9dYDwQWNvNMESzC+AsYkBWLmyTYtsexIYts3FIXxunp8
>     9sqknx/jvhYNsR+9F8htZ9lAhI9fgqqGe9wBPp+blDRE/VNa+Jc=
>     =khkX
>     -----END PGP SIGNATURE-----
>     
>     
> 

ARM 64?

[Guy Ellis]

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

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.


-- 
Guy Ellis
+61 419 398 234
www.traverse.com.au

Re: ARM 64?

[Michael Tremer]

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

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.
> 
>