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.
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: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.