Slashdot Mirror
ARM Launches Juno Reference Platform For 64-bit Android Developers
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.
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.
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.
http://arm.com/products/tools/development-boards/versatile-express/index.php
Matt
What's special about a 64-bit ARM processor? Haven't they been in iPhone 5S phones for almost a year now?
Yes, but now there's a chance to get them in actually useful devices.
Ezekiel 23:20
Wait... is ARM making its own chip? I don't think they've done that since like the ARM1/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.
Its-a-me, Mario! Wahuu!
"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?
227-3517
What!!!?
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!
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.
ARM has sold dev boards for ages.
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 same platform?
Whatever useful appliances with embedded ARMs the engineers are going to design, of course.
Ezekiel 23:20
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.
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.
well considering the target is android, you'll get v8 under the chrome browser.. beyond that, you can probably get node.js running in it.
Michael J. Ryan - tracker1.info
The problem is that a quad-core ARM isn't 40% as fast as a 6-core Intel, let alone a dual/quad 8-core AMD... Now, you can do some really cool things with ARM, if there were a decent I/O backplane for a cluster it would be awesome, but most can't even get 40mbps of throughput to a network adapter... When there are systems handling hundreds of thousands of requests per second, ARM won't handle that in its' current state, and those that have tried have been so much more expensive than x86 off the shelf, it won't save enough in power over its' lifetime. Doesn't mean it will always be that way... and yeah, I've looked, and it's cool.. but not worth it (yet).
Michael J. Ryan - tracker1.info
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.
The only major difference is that (in an effort that started before this board came out, and which they've pushed hardest for their 64-bit design, though the assorted ARM licencees seem to be tiring a bit of pointless differentiation on their own) ARM has recently been trying to stamp out some of the vendor-specific weirdness that has historically surrounded the architecture.
Presumably building "ARM's reference board", rather than letting the licensees of the A57 spawn theirs and leaving it at that, is part of their effort to ensure that crazy stuff like 'actually being able to boot without a blood-oath and a BSP' works across ARM based systems.
That's one thing that, while stultifying in many respects, the 'wintel' duopoly did for x86. Nothing stops an x86 CPU from being extremely weird (and there are a few oddities available) but the 'if it can't boot Windows it might as well not be an x86...' demands of the market, along with the fact that (unlike even MS' embedded OSes, never mind the embedded industry at large) 3rd parties pretty much don't get to touch Windows' internals until it has booted up far enough to load device drivers, has driven (ugly, hacky, largely de-facto) 'standardization'. ARM? Not. So. Much, something that they are trying to change at least for their more powerful parts.
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).
Yeah, I had a sig once; I got bored of it.
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 :-)
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.
Non impediti ratione cogitationus.
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.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
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, designed for the 386 and up which immediately set all the segment registers to point to segments that were 4Gb in size and that started at address 0.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
The weird thing is Google already support this for Renderscript, but not the NDK where it would be most useful. Encourage people to compile to LLVM and new architectures becomes much less of an issue.
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?
Non impediti ratione cogitationus.
+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 coming over from Intel.
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!
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.
Non impediti ratione cogitationus.