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
ARMv8 (64-bit ARM)
So it's time for Google to step up to the plate. How long will it be until we get v8 for the v8?
All I see mentioned is Android. Where's the announcement of these useful devices you mention?
The real story:
By including AOSP support as well as additional hooks and features from Linaro
They never offereed a dev platform before. Now they do. And its their first 64 bit reference targeting the mass android market.
The end.
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.
I could use an Android/ARM low end server box today. What are the options? 64 bit its fine and all, but I don't need either the processing power or the wider Integer width and don't want to use first generation technology. So I don't see the point in waiting for the A57s/53s boxes, 32 bit A15s are fine.
The App is currently running on Exynos 5 8 core Android tablet with client and server on same tablet. It needs to support multiple clients, the tablet isn't suitable obviously. So I'm looking for something with 8 cores, doesn't have to be the Samsung chip. Android 4.4 would be nice, I'd like a RAID for storage, Gigabit wired network, 2-3GB ram would be fine. Android support is essential, I don't want to mix the development environments, and the apps already written, the client-server split is already in and working.
What's the options?
ARM has sold dev boards for ages.
Then watch Samsung fuck it up. Nexus or nothing.
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 today arm on servers don't make a particularly large amount of sense. But common x86 servers have a two sockets, a 12-32 cores, 64GB ram, consume a max of 300-400 watts, have a "free" gigE, take up 0.5 to 1 RU in a rack, and cost approximately $3k.
Sure you can add 10G ethernet, 40G ethernet, or Infiniband, but it's not cheap. Now imagine that a future 64-bit arm chip allows for a system/blade at say 20 watts, quad core 64-bit arm, 40% as fast as a 6 core intel, and cost $600 each in a chassis that holds 16 and takes 2U and uses a 40G uplink.
You end up with better performance per watt, performance per rack unit, and more balanced CPU/Network bandwidth. Lower rack space bills, lower power bills, lower cooling bills, you need less ports on a switch, less cabling, etc.
Sure some will hate it because the cores individually are slower than intel, but others care more about throughput and don't care about microsoft windows compatibility.
Not sure if arm (and partners) will pull it off, but it seems possible.
It simply developed from being a client side app, with rich tablet interactions, to a larger app shared by people in the office. So it's already Arm and Android, and I don't want to port it or run two different development environments and maintain two different parts on two different OS's. I want to simply move one part over to another box.
I like Android, the scheduling and restarting of my code when it crashes, the separation between GUI components and 'services', intents, easy threads via AsyncTasks, remote installs, and so on. It runs now quietly as a service in the background on a dedicated tablet, with the GUI occasionally interacting with it.
I'm not close-minded to x86 hardware running Android, I see you can get Android ports for PCs and hence for servers, but I have a raid at home (Synology), and it's ARM based, and low powered, it sits quietly on my network reliable, cool, stable, reliable, does masses of stuff, etc. so I have very good experience with Arm boxes already and want to continue that experience.
Ideally, if someone had a port of Android to a Synology raid, I'd go with that. It doesn't have to be a full port, no need for the gui, so no need for all that hardware rendering and OpenGL and so on, but just the Java + Android framework-only would do.
"so you decided to just run both client and server on the same platform"
No, I decided to write a tool for myself on what was then a small 5 inch android tablet, and over the years it grew bigger and did more and others in the office want to use it. It needed upgrades along the way, and Android provided that with bigger screens, more cores, hardwired Ethernet, more ram and so on, as it needed them. Now I want to put a client-server split it in, and run it on multiple clients to a server. My expectation is (based on all the previous upgrades), that this will be possible, or perhaps already is.
I did a test last year using a TV Box (Android Quad core, 2GB ram, Gigabit ethernet, USB drive) and the principle is there, but a crappy Quad core A9 wasn't ideal, and a USB drive is obviously unsuitable. As a test of the principle it was fine, as a production system, obviously not.
So I assume such a system is available, but Google searches for server android and variants give me servers running on Android, the flip of what I want, so is such a box available.
Read this raymorris (don't evade it a dozen times and downmod it like you did before) http://it.slashdot.org/comment...
http://it.slashdot.org/comment...
APK
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 :-)
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.
That is a bit like saying that it is better to be stuck in a well since you then can climb out of it.
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
What?!
According to the Fandroids around here, I thought 64-bit was useless unless you needed more than 4GB of RAM! Why do I have a feeling the exact same people are going to be extolling the virtues of 64-bit ARM as being revolutionary and absolutely necessary when it shows up in a Samsung / HTC / LG / Motorola device?
(Yes, it was stupid a year ago, and it's still stupid today. Just the same as it was stupid to say that in 1996 when DEC had the 64-bit Alpha that only the highest end configurations got close to 4GB of RAM)
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
Also afaik Arm64 added a lot of features, made vector math obligatory and dumped Thumb-mode.
Sorry to reply as anonymous; I just stopped giving a shit about /. a couple of years back. If my login is still around it has excellent karma.
Why doesn't it just adopt openGL 4 like tegra k1 did.
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.
There's also a new 64-bit Objective C runtime. It has better performance than the 32-bit version but isn't a drop-in replacement. Since everything needs to be re-compiled and re-tested for 64-bit support, they can make add the new runtime without breaking existing 32-bit applications.
Copyright (c) 1990 - 2014 Dice. All rights reserved. Use of this comment is subject to certain Terms and Conditions.
but most can't even get 40mbps of throughput to a network adapter...
Not entirely true.
Samsung Arm Chromebook (Exynos 5250) + 1Gbps USB3.0 adapter, iperf TCP -> 800mbps.
I have a QNAP ARM-based NAS device. It came with linux+busybox+http server for configuring but it was soon running debian.
I haven't paid attention for a few years, but there were also things like the sheeva plug and gumstix (which can run android).
Copyright (c) 1990 - 2014 Dice. All rights reserved. Use of this comment is subject to certain Terms and Conditions.
+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.
There is the reasonable justification that having the destination operand first has greater consistency since the number of source operands is variable. Despite being something you have to be prepared for little-endian versus big-endian doesn't really effect code too much anywhere.
Meanwhile, anyone who suggests segmentation as a reasonable approach to anything needs to be shot well before sight. If you see them you're already dead. Just say NO to segmentation! This is kind of like the people who "merely" suggest adding an octect onto IPv4 addresses, you instantly know they know nothing about the actual protocols.
CAPTCHA: baffler
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!