Our start with ARM64: The Applied Micro Mustang

by Michael Tremer, May 31, 2015, Updated November 19, 2019

Do you like what you are reading? Subscribe to our newsletter and don't miss out on the latest...   Join Now

It is now a couple of years since there is a “stable” version of IPFire for the ARM platform. I put the word stable in quotes because everyone who has tried to use it knows what that means: IPFire runs well, but not on all the hardware. I blogged about this here in full length and stated that I was getting a bit tired about supporting legacy hardware.

As of today, I feel that ARM has not really been a success for us. We expected that there would eventually be professional hardware around with multiple Gigabit Ethernet adapters. Instead we got one single-board computer after an other. As soon as software got usable on them, they were replaced by the next one. Many distributions dropped support for the older ones as nobody really wanted to play with the old stuff. All the work that needs to be done to get a distribution running was practically worthless. Obviously this circle could not go on for forever…

ARMv8 and a unified boot

There is a solution on the horizon. It is called ARMv8 or ARM64. That is basically the codename of the next generation of the ARM platform. Its main feature is the huge step towards 64-bit and hence becoming more relevant for the server market. An other one is that (in theory at least) it is no longer required to have an extra kernel or a unified kernel for one or more boards. It uses UEFI instead.

When Arne, Hannes and I went to the Embedded World exhibition, we visited Applied Micro Systems (APM).

One of their staff who was by the way very much interested in our project was so kind to present us their product. It is really refreshing to have someone at the booth who is not just there for marketing, but who knows really what he is talking about? After a quick chat and a couple of emails, we were received a development kit from APM in March. Since then we have been working on porting IPFire 3 to the ARMv8 architecture.

Without going too much into detail, here is a quick summary about the progress: We decided to port IPFire 3 to ARMv8 because it is much newer and because we have a wonderful build system that helps us doing that. For now we do not have any plans to port IPFire 2 to ARMv8. As this new architecture is so new that we are running into lots of bugs. The most difficult part is the so called bootstrap. We need to create a working distribution without having anything to start with. To compile a compiler, you will need a compiler… Get it?

So the plan is that we are going to play around with all of this for a bit. We have run in so many bugs and we solved so many of them already. This will however take much more time and of course this project is not the one with the highest priority here. As soon as we are done with the basic bootstrap and everything builds properly we will add build machines to the ARM build cluster and see where all of this is going.

The hardware

I am not allowed to post any benchmarks. But I can tell you that it is fast. Forget about the single-board computer with SoCs designed for mobile applications. This is a completely different world. The processor has eight cores with 2.4 GHz; there is 16G of RAM and all the connectors that a server needs. This one is designed as a MiniITX board with ATX power connectors and so on. It is indistinguishable from a normal x86 MiniITX board at a first sight.

The board came is a big case with a harddrive and power supply.


What really interests me is the 10G Ethernet port on it. These may already suggest what the board is capable of. But before we get to use these, we will have to do our homework.

Join us

This is just the start of IPFire and ARM64. After the huge disappointment of the ARM 32-bit boards this is now a good start where everything old has been thrown over board and a new designed architecture is making its first steps. This is looking really well because the code looks tidy and is easy to understand. No more hacks for hardware that has died decades ago.

What we need is many man hours that we can put into bootstrapping IPFire and then getting the distribution to work. If you want to help us with that please get in touch. If you find it awesome what we are doing here and if you want to help us funding our research activities, then please donate.

As an example what kind of work needs to be done here, there is the grsecurity patchset that is used by IPFire:

grsecurity

The grsecurity patchset is something that we use in all versions of IPFire. It has support for 32-bit ARM, but not for ARM64. I emailed some very basic patches to the project which made the Linux kernel compile, but those do not implement any of the really interesting features of grsecurity that are desperately needed for making IPFire as bulletproof as we possibly can. I am not an expert who can write ARM64 assembly. Neither am I involved into kernel development at that level. It is just ridiculous what these guys can do. Their work is highly important for us and many other distributions. Security starts at the bottom of the operating system.

So this is an other project which is just at the beginning of supporting ARM64. If you can, please contribute to that by sending in patches or donating. It is highly important that these building blocks of systems like IPFire are ported to the new architecture as well.

AMD

We also spoke to AMD who are also working on ARMv8 at the same exhibition. Unfortunately, they are not as far as APM. They neither had a working demo to show at the exhibition nor did they have any idea whether there development kit was available for buying for anyone. They did not know when or even if products based on their ARMv8 SoC will ever hit the market. A rather longish but very disappointing email conversation where they tried to figure out this information left us with a very bad impression of AMD. We were directed to one marketing representative after the other and were not able to get a final response to any of our questions. We would have been fine with a clear no. But doing this sort of thing just keeps yourself and us busy with nonsense. Sorry AMD. At some point we wrote to AMD and told them that we are working with the Applied Micro system for now.