First A15 Device

I saw a thread on another forum that implied some network devices do most of the work themselves, I assume this also applies to security wifi cards, since some don’t work on all OSes with all security protocols.

If this isn’t the case, even just support for open wifi networks would be very useful.

I’m guessing that the problem with some OSes not supporting all security protocols on all cards is that it doesn’t pass the keys to the card, for whatever reason. My understanding is that all of that is done on the card.

I was guessing that the card didn’t have the protocols built in, but the manufacturer provided drivers that did the other protocols in the OS (Windows obviously).

So it looks like the Arndale Board is using a rebadged Atheros AR6003, which has hardware WEP, WPA/WPA2 (both AES and TKIP), and WAPI.

Looks like the ath6kl project (for Linux drivers) is dual-licensed BSD and GPL.

To go back to original suject, some guys here seem to have noproblem hacking the ChromeBook to install some Linux distributions on it.

To go back to original suject, some guys here seem to have noproblem hacking the ChromeBook to install some Linux distributions on it.

I was looking at a short tutorial on the subject at the weekend and since it seems to represent a means of switching between the default software install and your alternate it could be fun to get a Samsung Chromebook (recent ARM version that is) and see what doesn’t break, so to speak.

The Arndale board may represent an equivalent board for developer purposes.

The hacked Chromebook would indeed be an alternate to the Pi + lapdock (which pre-supposes someone could get RO to work on the Exynos systems.)

Also, regarding the retina display RISC OS discussion over in the RPCEmu forum, there’s always the Nexus 10, which is also an Exynos 5, and has a 2560×1600 display. You’d really want an external keyboard and mouse of some sort, and it’d be a subpar laptop, though. X2560 Y1600 C16M EX0 EY0 would look excellent on that.

(I do wonder how the NewsPad handled RISC OS, though, with a touchscreen. Or, maybe they just kept a mouse plugged in on the demonstrators, given that the project never went anywhere, and never bothered with the UI. But, the RISC OS UI isn’t suited to touch anyway.)

http://www.samsung.com/global/business/semiconductor/file/product/Exynos_5_Dual_User_Manaul_Public_REV1.00-0.pdf

Looks like that was posted on Samsung’s site 2 days ago.

Looks like that was posted on Samsung’s site 2 days ago.

I noted that the other day, but the route I went through was via the forum they have referenced on the Arndale board site and they appear to be now locking down those forum access to only allow registered users access to the files via that route.

Needless to say, although I don’t have a current use for the info there is a copy on my work laptop and the desktop here in front of me. I’m now happy the data will be available for use. :)

I just found some interesting benchmarks comparing Exynos 5, Tegra 3, Intel Atom, Intel Core i3 here

I just found some interesting benchmarks comparing Exynos 5, Tegra 3, Intel Atom, Intel Core i3 here

I was particularly tickled by the remark on the last page:
“The Samsung Exynos 5 Dual can easily handle MP3 encoding with LAME.”

Um.
Yeah.

My PVR (200MHz ARM926 + ~100MHz TI DSP) can handle encoding at 128kbit as either MP3 or AAC in realtime.
I have had the old 1GHz XP box rip CDs to MP3 in around a third of the real length of the audio.
So I’d jolly well hope that a 1.7GHz dual-core anything would be capable of making MP3s – even with lame, which seems to me to be one of the slower encoders around.
Perhaps in this day and age, a better rule-of-thumb benchmark might be to take HD H.264+AAC MP4s like are recorded with mobile phones and transcode them to HD XviD+MP3 AVI? Something that requires a little more grunt?

There was a hint in the article of a quad core A15. Can I be the first to say “yummy”? (^_^) Plus, I’d laugh hysterically like a crazy person (wouldn’t take much effort to pull that off) if ARM came along and made a strong showing on the desktop having never really cut it in the past, and been stomped on (a lot) by x86. But why not? ARM is kicking ass in the embedded market, doing pretty fine in handheld devices, and getting some netbook/laptop things out there will potentially start for the desktop market – for what is a laptop if not a very portable “computer”? The eeePC 901 I’m writing this on is restricted by technical reasons of size (no optical media, can’t bung in another harddisc, etc) but that aside it runs XP and can do everything a comparable spec XP box can do… and it’s about the same size as a school textbook and runs for hours on its own steam. We’re all used to laptop style devices. Well rather than attempt to compete with the billion-core hideously over-specified cutting edge x86 hardware, you have to appreciate the cunning of putting out an ARM netbook device. It’ll run Ubuntu, it’ll allow you to fiddle with documents, make moronic slide presentations so beloved of middle-management, blah blah; but wait, it isn’t yet another fancy looking x86 thingy. It’s something quite different inside. It can connect to the company WAP and… “I laugh in the face of Confiker, you snot-nosed weavils!” <cough> Where was I? Oh yes, observing the brilliance of sneaking in the back door. I have high hopes, not because of any ill feeling towards Intel or any dislike of Microsoft, but simply because we were introduced to x86 at college (when the 386 was hot stuff) and I, personally, feel that as an instruction set it is the most god-awful disgusting thing I’ve seen. Even Eldritch Abominations would cower when faced with a disassembly of anything more complicated than “Hello World”. It really is extremely displeasing to look at. By comparison, I lament the loss (the understandable loss, mind you) of the ARM’s ability to restore the necessary registers from the stack, restore the callee’s flags, and exit a function in one instruction which could be conditionally executed. If it was possible to fall in love with an instruction, LDMFD R13!, {....}^ would surely be the one. From a code point of view, well-crafted ARM code just looks nice. Its simplicity on the eyes belies its inner strengths. I am such a fanboy, it’s really rather pathetic, isn’t it? <sigh>

:-)

if ARM came along and made a strong showing on the desktop … stomped on (a lot) by x86

Doesn’t Ivy Bridge (although relatively light-footed) actually wear bovver boots?

Seems like Linux is working OK on this (even ARM Blogs noting so), and there are also efforts to get Android running. Shame the Chromebox isn’t ARM-based.

For info, efforts to port Android to the Samsung Chromebook series 3 have started. Will be interesting to follow this and see how much transferable stuff is uncovered.

I don’t see what Android would add to the porting process when Linux (Ubuntu, Debian..) already run and full kernel sources are readily available..
Android runs in a VM on top of Linux.

If there is anything to be tested on the chromebook then let me know. I have been using mine with Ubuntu for months now :-) Also am quite accustomed to building kernels etc.

Just thought there might be commonalities in terms of getting another OS on it. But if Linux is running, then I guess that the process for running Android is unlikely to add new info.

f there is anything to be tested on the chromebook then let me know. I have been using mine with Ubuntu for months now :-) Also am quite accustomed to building kernels etc.

Is that power up, u-boot and u-boot launches linux or the version where you can hit alt key combos to flip between chromos and ubuntu?
What is really needed for these things is a u-boot startup where you can choose which of two OS images you run. That then means it becomes easy for testers to switch from a RO development that falls over readily and their normal linux (or chromos) startup.

From my very brief search recently, isn’t this port to linux complete?
If anyone is interested in a port, I am more than willing to discuss funding/adding to funds and paying for the required hardware to make this a sweeter target.
It would be nicer on the barebones, rather than a chrome book (I couldn’t see ethernet as an interface on the chromebook)

I run kernel 3.8.11 + Linaro Ubuntu 13.09.
This boots into Ubuntu so no Chroot env besides chromeOS.
RPCemu runs at about 30 MIPS, OpenGL-ES 3.0 works, HW accelerated video and WebGL in chrome browser works.
I have not yet tried my ARM optimized version of RPCemu yet but I think it won’t yield much extra a.t.m.
There was no ‘port’ to Linux necessary due to all the work done by google for the chromeos. ChromeOS uses a standard linux kernel (with fixes for Exynos 5 that found their way upstream) and added a few ChromeOS security drivers.
So with those sources it was rather trivial to get Ubuntu up and running. Kernel 3.4 was ‘default’ with a 3.8 coming soon to ChromeOS. (I am actually typing this on the Chromebook..) If/when the quad core A15 Chromebooks will arrive, no one knows. For quad core the Odroid-XU does great and more boards are coming. Apparently Exynos 5420 has fixed some hw bugs of the 5410 (Odroid XU) which allows all 8 cores to work at the same time.
If the 5410 also suffers from the instruction loop buffer bug is unknown to me. The chromebook (Exy.5250) definitely suffers from that bug. (implemented workaround is to disable the loop buffer. reducing the performance of tight loops significantly.) I have yet to test the Odroid XU more for these bugs and see if this hw revision has a fix.
Cortex A15 is a real game changer, the quad core performs as well as my old PC.