ARM Launches Juno Reference Platform For 64-bit Android Developers 69
MojoKid writes One of the trickiest aspects to launching a new platform update is the chicken and egg problem. Without any hardware to test on, developers are leery of committing to supporting new hardware features. Without software that takes advantage of new hardware capabilities, customers aren't willing to pay for new equipment. This is the crux of the issue with respect to the ARMv8 architecture and enabling development for 64-bit Android platforms. As such ARM is readying their Juno development platform that combines several of ARM's most advanced technologies on a single board. The product supports big.Little in an asymmetric configuration; each board ships with two Cortex-A57s, four Cortex-A53s, and a modest Mali T-624 core. All this hardware needs an OS to run on — which is why ARM is announcing a 64-bit port of Android as part of this new development board. By including AOSP support as well as additional hooks and features from Linaro, ARM wants Juno to be a sort-of one-stop shopping product for anyone who needs to test, prototype, or design a 64-bit product for the ARM ecosystem. The Android flavor that's coming over is based on Linaro Stable Kernel 3.10. At launch, Juno will support OpenGL-ES 3.0, on-chip thermal and power management, up to 8GB of RAM (12.8GB/s of bandwidth), an optional FPGA, and USB 2.0. OpenCL 1.1 will be added in a future product update. The project is positioned as a joint ARM / Linaro launch with ARM handling the hardware and Linaro taking responsibility for the software stack.
Re:What the fuck is this thing? (Score:5, Informative)
Yes, it's a reference board. What's new about it is that it contains a 64-bit ARM processor.
For what it's worth, I thought the summary was very informative.
Re: (Score:1)
What's special about a 64-bit ARM processor? Haven't they been in iPhone 5S phones for almost a year now?
Re:What the fuck is this thing? (Score:5, Funny)
Re: (Score:2)
Re:What the fuck is this thing? (Score:4, Interesting)
Well, Apple pretty much skunked everyone, because the roadmaps for 64-bit ARM processors had them sampling middle of 2014, for release end of 2014. These were roadmaps published by Qualcomm, Broadcom and everyone else.
So Apple pretty much got a year and a half head start (devices weren't to ship until mid 2015).
Oh, Android for 64-bit ARM wasn't supposed to be out until end of 2014, either.
Which meant if you really wanted, you shouldn't buy a phone in 2014 because what made the iPhone and iPad so fast WAS 64-bit. ARMv8 is much more efficient - 32 bit code gets a minor speedup, but the 64-bit stuff runs WAY faster.
Re:What the fuck is this thing? (Score:4, Insightful)
64 bit direct addressing is no more necessary to use >4 GB of RAM with ARM than it is with Intel. The magic is called PAE - physical address extension. It allows a multiple of 4 GB of RAM globally, though each process is, in practical terms, limited to 4 GB. For example, the Cortex-A12 core is a 32 bit architecture, but has 40 bits of memory addressability. 32 of those bits are directly set from address fields in instructions, and the other 8 bits are set by page tables. With 40 bits you can utilize up to 1 TB of RAM.
Those old enough to remember the 8086 will recall that it was a 16 bit architecture, but had 20 address pins, so could address 1 MB of RAM rather than just 64K. 4 of those pins were set using segment registers. The segmented memory model was actually more flexible than the flat memory model, because even individual processes could manipulate their own segment registers to address the full 1 MB range.
Re: (Score:2)
PAE is mostly for kernels and a few select apps that page out buffers (like SQL Server). It is not a general flat >4GB memory space for applications.
And yes I remember how it was with the 8086. Which is why I try to forget segmentation for general purpose programming :-)
Re: (Score:1)
+1, sir, would that I could!
I remember learning x86 assembly after knowing 6502, 68000, and 68HC11 and wondering what it was the Intel engineers were smoking when they came up with not just the addressing scheme, but little-endian (don't get me started), and destination, source! More importantly, WHY that became the most popular architecture. It's like everything was upside-down and backwards of what I learned.
Though from what I've seen, ARM is little-endian and dest,src too, probably to appease people comi
Re: (Score:1)
Hmmm... I agree with you about segmentation, but think that adding an octet or two to IP4 would be vastly preferable to the unreadable, unmemorizable, mess that is IP6 that makes us slaves to domain name servers. So make it a non-lethal shot, please!
Re: (Score:3)
The segmented memory model was actually more flexible than the flat memory model, because even individual processes could manipulate their own segment registers to address the full 1 MB range.
Should really be written
The segmented memory model was actually less flexible than the flat memory model, because individual processes had to manipulate their own segment registers to address the full 1 MB range.
There's no doubt that, from the point of view of a programmer, the flat memory model is simpler and more flexible. You only have to see the kludges that 8086 C compilers introduced to make the full 1 Megabyte available to C programmers to understand that. Also check out every operating system, de
Re: (Score:2)
The main reason to move to 64-bit isn't memory, it's address space. Some other useful things falls out of it in a co-incidental kind of way too, like more registers (which are nice for tight loops).
Re: (Score:2)
I hate replyin to ACs. But, no. What sped up the iPhone and iPad Air wasn't the low resolution. We aren't talking about gamin or graphics performance, we are talking about raw CPU performance.
The transition to 64 bit wasn't the secret sauce, the secret sauce was that a lot of legacy CPU behavior in 32 bit mode went away. So when running in pure 64 bit mode, the CPU was way more efficient.
It's like the x64 transition.
Re: (Score:2)
The nice thing about Android is that most apps will get an immediate re-compilation to 64 bit by the device and benefit from the full speed boost, without any need for the developer to act. Apps that use native code will need to be re-compiled of course.
Re: (Score:1)
I gathered from the summary that it is a dev board to bootstrap/showcase ARMv8 (64-bit ARM) arch development. Vendors will have their own dev boards with their own SoCs, I'm sure. But they will expect you to be plugged into their ecosystem and tough going if you aren't.
Seemed obvious.
Re: (Score:2)
Re: (Score:1)
ARM has sold dev boards for ages.
Re: (Score:2)
Presumably building "ARM's reference board", rather than letting the licensees of the A57 spawn theirs and leaving it at that, is p
Re: (Score:2)
Official ARM Link (Score:2)
http://arm.com/products/tools/development-boards/versatile-express/index.php
Re:Official ARM Link (Score:5, Informative)
Re: (Score:2)
Juno SoC? (Score:2)
Re: (Score:2)
ARM didn't make the ARM1/2 either, they were fabricated by VLSI (the company, not the acronym). ARM has always been fabless.
Re: (Score:2)
By that measure, isn't AMD also fabless because TSMC makes their chips? (or at least their big processors)
I guess what I mean by "making" is "designing and having someone fabricate for them". That is what would set it apart from all of the other ARM chips out there today.
Android development guidelines recommend Java (Score:2)
If developers do not want to worry about the underlying hardware, all they need to do is stick to Google's developer guidelines and use Java. Let the JRE and native recompiler abstract all the hardware-dependent stuff. Not quite as compute/power-efficient (at least in theory) but from what I have seen, there seems to be tons of developers who waste tons of cycles regardless of portable vs native anyway.
chicken and egg problem (Score:1)
"Without any hardware to test on, developers are leery of committing to supporting new hardware features. Without software that takes advantage of new hardware capabilities, customers aren't willing to pay for new equipment."
Is it not the manufacturer's interest to provide initial software / libraries? At least version 1.0?
What!!!? (Score:2)
Sixteen posts already and nobody (apart from the sidebar) even mentioned the word Linux?
(Which, kids, surprise, surprise -- is what Android basically is.)
Yes, these days, many of my smart phone addict friends stifle with quite a surprising look when
they hear Android is Linux.
My fellow nerds -- you have an obligation, don't let Google or Samsung get away with this!
Re: (Score:2)
Open Source Drivers? (Score:4, Insightful)
I'll buy one if ARM publishes the source code to the drivers in an open source license. These Android stacks with binary blobs are nightmares to work with.
Re: (Score:2)
Open Source Drivers? (Score:2)
ARM doesn't build chips, thus no drivers neither. That falls on the silicon vendors - TI, Broadcom, Samsung, etc. They are a pure-IP licensing company.
BTW, their Mali GPUs have open source drivers.
Re: (Score:2)
ARM only do the reference design for the CPU core. All the peripheral stuff that you need drivers for is designed by other companies. FWIW the core stuff that ARM do is all publicly documented and well supported on OS platforms like Linux/AOSP.
Re: (Score:2)
They do more than just CPU cores. The GPU in this thing, for example, is from ARM.
just curious, why did you choose Android on ARM? (Score:2)
I'm just curious - for a server, where you want RAID, gigabit bandwidth, etc, why did you choose Android on ARM as opposed to something like one of the inexpensive AMD offerings with any of the oother small Linux distributions that are more flexible? Those scale anywhere from very low end to 8 cores at 5Ghz and there are all kinds of options for RAID, gigabit or higher networking, etc. Was that because Android tablets made sense for the clients, so you decided to just run both client and server on the sa
Re: (Score:2)
Re: (Score:2)
Either APK is truly sexist, stupid and crazy, or this is a super clever APK troll. Only if we had some sort of way for him to possibly enter credentials verifying it's actually him... :)
Now the big question, is APK sexist, crazy/stupid AND racist? Will he make the ESR hat trick?
Re: (Score:2)
Either you're a clever troll or you're too stupid to check post history, etc.
I'll save you the trouble if you're not a troll. I am not raymorris' sock puppet.
The answer is called LLVM (Score:2)
The weird thing is Google already
Re: (Score:2)
Google supports LLVM in the NDK. Renderscript is more like OpenCL where they restrict the input to make portability easier. Google also has the portable native client definition that aims to do something more general as you are suggesting, though that's for the desktop not android, admittedly. The thing is that LLVM is not actually portable between 32-bit and 64-bit anyway because C loses too much of that information at the early stages of compilation.
If you look at the SPIR spec (https://www.khronos.org/sp