facebook rss twitter

ARM releases Juno dev platform for 64-bit computing

by Tarinder Sandhu on 2 July 2014, 17:00

Tags: ARM

Quick Link: HEXUS.net/qacgbn

Add to My Vault: x

Inexorable march towards 64-bit

In a move designed to accelerate the time to market for applications running the 64-bit-capable ARMv8-A Architecture, present on the latest generation of Cortex processors from the British company, ARM is today releasing Juno, a development board platform, to hardware partners and software developers.

A bit of background first. 64-bit is supported on the ARMv8-A Architecture via a processing state known as AArch64, but unfettered compatibility is still retained with mainstream 32-bit software through a separate mode called AArch32. The processor decides which mode to use in each case. Speaking of which, the ARM Cortex-A57 and Cortex-A53 processors are the first to be equipped with the ARM v8-A Architecture that, the company says, is primed to handle the needs of servers today and superphones and premium tablets of tomorrow. ARM has a well-established roadmap detailing upcoming 64-bit-compatible processors.

64-bit is useful because it expands the virtual and physical memory address space to 48 bits, enabling complex programs to store far more data in memory than was previously possible. Going hand in hand with the extended memory support is the presence of wider registers. These act as a fast storage area available to the CPU cores and, as such, the ability to hold more data is crucial in increasing performance. The ARM 64-bit topology includes 31 general-purpose registers able to hold 64 bits each and 32 floating-point registers holding 128 bits.

A combination of greater memory support and wider register files enables compatible processors to process more work, more quickly, which is an important attribute when running high-performance applications on mobile devices. Tuned optimally and run on compatible software, a 64-bit processor is able to do more work at the same power level as a 32-bit one.

Catching the industry off guard, Apple has already debuted a 64-bit-capable ARM-based system-on-chip (SoC) in the form of the A7 powering the iPhone 5S, iPad Air and second-generation iPad Mini. Qualcomm, too, has ARMv8-A Architecture SoCs in development - the Snapdragon 808 and 810 are due for release early next year.

So with 64-bit processing already out in the wild and major hardware players in the final stages of development, why is ARM releasing a development board? Good question.

Juno to facilitate 64-bit software

A company with the appropriate ARM license can develop hardware compatible with the v8-A Architecture - Apple, Qualcomm, X-Gene and Cavium are key examples - but it's equally important to have applications ready to take advantage of the increased performance and efficiency. Drawing a tenuous analogy, there's little point in having a supercar without access to lots of petrol.

This is where Juno comes in. The development board, pictured right, houses a powerful dual-core Cortex-A57 processor alongside an energy-efficient quad-core Cortex-A53 on the SoC. The two are tied together via ARM big.LITTLE technology that, via cognisant software, enables any number of cores to be used, for performance or efficiency. There's also ARM Mali-T624 graphics, and the trio of core technologies are chosen because they represent, in ARM eyes, the likely configuration of many next-generation smartphone and tablet SoCs.

By having proven, consistent hardware conforming to a minimum standard outlined by adherence to the ARM Server Base System Architecture (SBSA), ARM is making it easier for software developers to test and iterate 64-bit drivers, software, tools and engage in performance tuning. The approach is akin to AMD or Nvidia sending out hundreds of reference next-generation graphics boards to game studios and smaller developers, with the aim of providing a base from which software can tease out the advantages inherent in a new architecture.

Linaro steps up to the 64-bit plate

Yet a development board platform still requires a compatible operating system upon which developers can, well, develop. Linaro, a provider of open-source software for ARM SoCs, is today also releasing a 64-bit port of the Android Open Source Project (AOSP) fully compatible with the Juno platform.

Based on the stable 3.10 kernel and featuring the latest global task scheduling software - enabling optimum use of the big and LITTLE ARM CPU cores - it provides developers a full hardware and software platform on day one of launch. We already know that Google is keen to support 64-bit ARM SoCs via its upcoming Android L OS, due for official release this year, so Linaro's effort can be viewed as a precursor to the full-blown Android update.

64-bit support here and now

Apple made considerable waves when it announced the A7 SoC last year and promptly rolled it into a number of devices. The benefits of mobile 64-bit computing, which is a cornerstone of the ARM v8-A Architecture, are, on paper, tangible enough that many premium smartphones and tablets will be packing the technology in early 2015.

ARM is helping developers get to grips with the architecture by providing these development Juno boards, in their '100s', to a wide range of software developers. The approach makes implicit sense, particularly when dealing with a new architecture, and, considered from an Android point of view, is much-needed when Apple is presently firmly ahead in the 64-bit hardware and software stakes.



HEXUS Forums :: 6 Comments

Login with Forum Account

Don't have an account? Register today!
and with AMD shipping the Opteron A1100 dev kits - looking rather good :D
Hmm, a number of unanswered questions, like a link to order from, the cost, and when the board will be shipped. The whole thing smells a bit like a press release launch, and nothing will actually be available for another few months.

However a bigger red flag is the linux kernel version. The press release said 3.10 that was released around a year ago. (3.15 is the most recent stable version and was released about a week ago). Releasing with such an old kernel suggests that ARM have not learnt the lesson of getting their kernel changes accepted into the mainline because if they had it would have been trivial to support the latest kernel version on this board.

Instead, I predict another rant from Linus Torvolds, and putting up with poor and out of date support for this hardware as is sadly all too common with ARM dev boards.
chrestomanci
Hmm, a number of unanswered questions, like a link to order from, the cost, and when the board will be shipped. The whole thing smells a bit like a press release launch, and nothing will actually be available for another few months.

However a bigger red flag is the linux kernel version. The press release said 3.10 that was released around a year ago. (3.15 is the most recent stable version and was released about a week ago). Releasing with such an old kernel suggests that ARM have not learnt the lesson of getting their kernel changes accepted into the mainline because if they had it would have been trivial to support the latest kernel version on this board.

Instead, I predict another rant from Linus Torvolds, and putting up with poor and out of date support for this hardware as is sadly all too common with ARM dev boards.

It is just a dev board, so cost will be high and only available to companies who bulk buy ARM chips. If you buy enough chips, you can probably blag one for free. These things are designed to speed engineers getting a design to market, and hence speed silicon getting sold, they aren't intended to be usable as a product.

The PCIe options on the board look interesting, but in the configuration shown that looks like an Android dev kit.

My phone seems to be on 3.1.10 for Android 4.2, embedded devices aren't normally so worried about keeping up with the latest as a well understood version is often seen as better.

Edit to add: Something cheaper than the Zotac board would be nice: http://www.maplin.co.uk/p/zotac-jetson-tk1-developer-kit-a30ny
http://community.arm.com/groups/smart-and-connected/blog/2014/02/24/64-bit-arm-server-development-kit-from-amd


^^

the AMD kit allrady out ;)

btw I can see why they are using the STABLE 3.10 kernel - 3.15 is buggy and needing a few fixes :(
DanceswithUnix
It is just a dev board, so cost will be high and only available to companies who bulk buy ARM chips. If you buy enough chips, you can probably blag one for free. These things are designed to speed engineers getting a design to market, and hence speed silicon getting sold, they aren't intended to be usable as a product.

I am not expecting to buy one from PC world for Ā£30, but in my experience if an SOC company is serous about getting their platform out their, they do make sure that the dev kit is available to buy at reasonable cost by anyone who wants one. This usually means less than $500 either direct or from someone like Farnell components.

DanceswithUnix
My phone seems to be on 3.1.10 for Android 4.2, embedded devices aren't normally so worried about keeping up with the latest as a well understood version is often seen as better.
I think you miss my point. The issue is not if the board comes with the latest (possibly unstable) kenel version, but if it is possible to buld a recent kernel for it. Older kernels are well understood, but they also have bugs that are fixed in newer kernels, as they lack features that the newer kernels have, so sooner or later it will be necessary to update. Doing so will be very easy if the kernel patches necessary to support this board have been accepted upstream, or very hard if not.

To explain the situation a bit more: In the x86 world, our PCs have a BIOS, which insulates the OS from needing to know hardware specific details like memory voltages & timings, and provides an easy way to discover an enumerate what hardware is present such as how much memory, how many CPUs, and what PCI cards are available. The outcome is that a Linux kernel built for x86 will boot on anything from a 30 year old 386, to the latest desktop from PC world. (And but for minimum system requirements, so will a windows kernel).

In the embedded ARM world, devices usually don't have a firmware to insulate the kernel from hardware details, so lots of stuff like memory timings has to be complied into the kernel, so you need a different kernel binary for every different ARM device, and a different set of patches and board configuration files in the kernel source tree as well. A few years ago, the situation got insane with the number of different devices that had config files in the main Linux kernel source (most of which where unmaintained) that the kernel maintainers called a halt and stopped accepting those patches.

The new system is know as device tree. The idea is that for each different ARM device, a device tree file listing all the hardware details is prepared. The kernel reads it early in the bootup process, and uses it to setup the hardware and find all the devices. Using device tree, the same kernel will work on most devices, and as the kernel is updated with bug fixes and new features the new kernel will still work because everything is independent.

The problem is that ARM SOC vendors have been slow to support device tree. Without it they can ship an ARM kernel, but that kernel will be abandonware from day one, as it is very unlikely to get bug fixes and new features that the rest of the Linux world gets. That is why I am concerned that the linux kernel that comes with this new 64 bit ARM board is old, and disappointed that ARM are not working with the Linux kernel community.