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.
This is a remarkably shitty summary, even by Slashdot's shitty, shitty standards.
Is it just yet another reference board like CPU vendors have been released for decades now?
Is there actually anything special about it? It all sounds rather typical to me.
For crying out loud, this summary is pretty much the entire article. What a piece of shit summary! The article isn't very good, either. The picture of the board is a lot more interesting than any of the utter crap commentary surrounding it. And why the fuck is a big part of the text nothing but an image of a presentation slide or something like that? There's a hyperlink shown in it, but you can't actually click on it, because the text is part of a goddamn image! I mean, seriously! What the fuck! Why is this total crap even on Slashdot's front page?
http://arm.com/products/tools/development-boards/versatile-express/index.php
Matt
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.
deliver. Some of will recall that it move any eq%uipment Counterpart,
"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.
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?
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?
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
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.
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.
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.