HiKey: An 8-Core 64-bit ARM Cortex-A53 Board For $129 USD, But With One Sad Flaw

[SystemCrasher]

It's cool to have 8 64-bit cores ... but,

1) ahem, where is all I/O? No Ethernet? No SATA? Not even USB3? Just some few USB 2.0 ports? For $129? Huh?

2) What users are supposed to do with all these 8 64-bit cores, granted I/O with external world completely suxx?

3) Also, having 8 64-bit cores and 1GiB RAM sounds like waste of RAM on 64 bit address space when ... it not even anyhow close to using 32 bit address space.

So overall it looks like some system designers gone mad and created this strange thing. Powerful number cruncher ... with sucking IO and little memory. Okay, this one counts as most strange and unbalanced hardware system I ever seen.

[Ardje]

Big.LITTLE is highly overrated. I'd much rather have all cores equal in capability.

I don't think it is highly overrated. It is just not supported that well in the linux kernel. Worse: not at all.
For a website you can actually run those few visitors at night, and turn the BIG of.
I have a big.LITTLE setup, and there is a big difference between idling and full throttle...
You can get like 4W on an XU3 in idle mode, turning off the A15's will give you 0.5W per core.
But running only on the A7 is slow. And after turning the A15's on again, you have to reshuffle the IRQ's.
The kernel still sticks processes to A7, which currently makes turning of an A15 not a fun day.
If power+process scheduling was up to par, my XU3 could probably do less than 1W.

So if you have a big cloud, you could have your servers idling with a very low accesstime.
Turning on an ARM usually takes up from 5s and up before you can log in again.

[SystemCrasher]

I don't think it is highly overrated. It is just not supported that well in the linux kernel.

Whatever, it seems to be marketing crap. You have "8" cores, but as far as I can understand, in most implementations you can only use 4 cores at once. Hence, 8 is a misnomer. It would be much better to have 8 proper cores with proper scalability (e.g. ability to downclock, power gate unneeded cores, etc). big.LITTLE sounds like dirty hack, mostly targeted on fooling users about 8 cores in marketing materials. While in most cases "8" cores chip would be just quad-core at its peak power. That's what I call marketing bullshit...

Worse: not at all.

The only problem is: Linux is the ONLY OS around which can support all these SoCs at all . Everything else? It suxx even more, usually being unable to suport most of these SoCs at all . Microsoft? It supports very few SoCs. Apple? Only cares about their own hardware and use cases. BSDs? Its dead, Jim, its dead. Other *nix like? Please do not wake up zombies, they're useless here anyway.

And after grepping on commits it in fact looks like if big.LITTLE _is_ supported in Linux. Wikipedia also claims this.

For a website you can actually run those few visitors at night, and turn the BIG of.

This sounds like very synthetic use case. I guess for web site it can be good to power up full A15 core, let it chew web site internals at full speed and then go sleep, downclock and maybe even power gate some cores. I see little reason for A7 core at all: it would make users waiting longer for page processing while A7 core will be busy and overall amount of power spent to serve user wouldnt be anyhow small. Sounds like weird technical solution.

I have a big.LITTLE setup, and there is a big difference between idling and full throttle...

And what OS you're usnig if "Linux does not supports this"? Huh?

If power+process scheduling was up to par, my XU3 could probably do less than 1W.

If it eats some WATTS of power, it is probably CPU frequency scaling issues, etc? Usually mobile SoCs can go as low as several MHz and reduce voltage, causing orders of magnitude drop in power consumption. However it requires to have proper in-kernel support for power manager regulators to adjust voltages on the fly and of course proper frequency scaling. While frequency caling is quite ofen sorted out in Linux kernel, dealing with custom power manager IC or subsystem could be tricky and in this case voltages could be left at maximum values, which warrants chip stability even at highest clock but very suboptimal in sense of power consumption since if you run at several MHz, IC would remain stable at much lower voltages than maximum. But you'll have to set full voltage before increasing CPU frequency and wait for voltage increase to happen, or you can get some nasty stability problems. Needless to say it takes some time. And to make it even less fun, standard Linux schedulers tend to behave quite poorly if you have to go from 20MHz to 1500MHz. So overall it can kill interactivity to the hell unless you manage to sort it out. Waiting for system to upclock for whole second can be PITA for, say, desktop.

Turning on an ARM usually takes up from 5s and up before you can log in again.

Ideally, there should be some power gating with ability to leave only one core on low frequency to give Linux chance to ramp up as needed, when extra load arrives. Though it's quite tricky to ramp up from deep powersave modes at good speed, so there are some latencies attached.

[schmidtbag]

I've heard about the AMD ARM boards and I personally think AMD will revolutionize ARM, since they're really trying to make it act like an x86 PC. AMD is also working on merging x86 and ARM architectures, in a similar way that big.LITTLE works. AMD probably realizes that if their new CPU architecture doesn't compete with Intel, they're going to be left behind. But with ARM gaining so much popularity (and MS's support), AMD has a chance to be the leader of ARM. Kind of funny, though, how everywhere they go, nvidia will be there to get in the way.

However, for that server board AMD has available right now, I don't see that being very useful for people at home. The most appealing aspect about it is the fact that it's so power efficient, and in turn uses passive cooling. Otherwise you're better off getting an FX-8350 build and underclock it, due to software compatibility and price.

[droidhacker]

Well, that makes even more sense. But still, it would have to be big.VeryLITTLE. Todays architectures are getting very good at shutting down unused parts of the die.

SOME are, which typically do not include ARM reference core designs, which are still pretty hogish. This is one of the reasons why Qualcomm custom core designs (Scorpion, Krait) have been so successful for smartphones, because they scale down to the power efficiency of the "little", while being able to jump up to the performance of the "big". Combine that with the fact that you don't need to jump up to double the core count just to save power, and you can keep costs relatively low. But like some people here have mentioned, why 64bit at all right now? And they are right. At THIS point, it is a marketing gimmick kicked off by the fruit company, but now everybody else is being forced to scramble to be able to say "we can 64bitz too!!". So in the rush to bring 64bit chips to market, you end up with monsters like the Snapdragon 810, which is a bunch of ARM reference cores in big.little with an Adreno strapped onto their side. Well, at least they implement heterogenous multi-processing... The next run around though, with the SD820, you will be seeing a pack of 8 BIG's with proper scaling. They're calling the new core "Taipan".

[Prosthetic Head]

Not enough RAM.... as usual.

I love these cheap ARM linux devices.. there are an absolute stack of them available as I'm sure you know...
But almost all of them have the same flaw which makes them much less attractive, at least for me. Virtually all of them have insufficient RAM. 8 cores and only 1GB?! That's only 128MB / core. I'd give up 4 of the cores to have 2 or better 4GB of RAM any day.
I have a Pi and an MK802IV android TV stick flashed with linux. (quad A9, 2GB, 8GB flash.. for only ?40!) and in both cases the main things I find myself crying out for are more RAM and better open hardware drivers... A standardised boot management system would be good too so we could have linux distros support them without huge effort for each individual model...

[Prosthetic Head]

SOME are, which typically do not include ARM reference core designs, which are still pretty hogish. This is one of the reasons why Qualcomm custom core designs (Scorpion, Krait) have been so successful for smartphones, because they scale down to the power efficiency of the "little", while being able to jump up to the performance of the "big". Combine that with the fact that you don't need to jump up to double the core count just to save power, and you can keep costs relatively low. But like some people here have mentioned, why 64bit at all right now? And they are right. At THIS point, it is a marketing gimmick kicked off by the fruit company, but now everybody else is being forced to scramble to be able to say "we can 64bitz too!!". So in the rush to bring 64bit chips to market, you end up with monsters like the Snapdragon 810, which is a bunch of ARM reference cores in big.little with an Adreno strapped onto their side. Well, at least they implement heterogenous multi-processing... The next run around though, with the SD820, you will be seeing a pack of 8 BIG's with proper scaling. They're calling the new core "Taipan".

I know it's not exactly what you and most people mean, but almost every recent SoC already does big.VeryLittle in a way.. they have dedicated hardware, including surprisingly flexible DSPs and firmware based interfaces, etc for handling cameres, sensors, I/O, displays, networks, etc, etc... The really big SoCs are in a way something like big.Little.VERYlittle.TINY.. with turing complete but increasigly simple and / or specialised units all the way down...

[scottishduck]

SOME are, which typically do not include ARM reference core designs, which are still pretty hogish. This is one of the reasons why Qualcomm custom core designs (Scorpion, Krait) have been so successful for smartphones, because they scale down to the power efficiency of the "little", while being able to jump up to the performance of the "big". Combine that with the fact that you don't need to jump up to double the core count just to save power, and you can keep costs relatively low. But like some people here have mentioned, why 64bit at all right now? And they are right. At THIS point, it is a marketing gimmick kicked off by the fruit company, but now everybody else is being forced to scramble to be able to say "we can 64bitz too!!". So in the rush to bring 64bit chips to market, you end up with monsters like the Snapdragon 810, which is a bunch of ARM reference cores in big.little with an Adreno strapped onto their side. Well, at least they implement heterogenous multi-processing... The next run around though, with the SD820, you will be seeing a pack of 8 BIG's with proper scaling. They're calling the new core "Taipan".

The 64-bit is hardly a marketing gimmick. That newer arch has significant performance gains.

[uid313]

The 64-bit is hardly a marketing gimmick. That newer arch has significant performance gains.

Not only better performance gains.
But it is much cleaner and more standardized and more sane and improved.

[Ardje]

Whatever, it seems to be marketing crap. You have "8" cores, but as far as I can understand, in most implementations you can only use 4 cores at once.

About all platforms can run all 8 continuosly, with the exception of the exynos 5410. The exynos 5410 has some issues regarding cache and power control to really run all 8.

Hence, 8 is a misnomer. It would be much better to have 8 proper cores with proper scalability (e.g. ability to downclock, power gate unneeded cores, etc). big.LITTLE sounds like dirty hack, mostly targeted on fooling users about 8 cores in marketing materials. While in most cases "8" cores chip would be just quad-core at its peak power. That's what I call marketing bullshit...

An exynos 5420 can downclock all A7's and A15's. Downclocking an A15 to low reaches a 0.5W usage, which is comparable to a not downclocked A7.
The essence of a big.LITTLE is that you can poweroff A15's and just only work on the A7 as the instruction set and caching architecture are meant to co-operate. I do acknowledge that quad A15+ might be a better name... It's still faster than quad A9.

The only problem is: Linux is the ONLY OS around which can support all these SoCs at all . Everything else? It suxx even more, usually being unable to suport most of these SoCs at all . Microsoft? It supports very few SoCs. Apple? Only cares about their own hardware and use cases. BSDs? Its dead, Jim, its dead. Other *nix like? Please do not wake up zombies, they're useless here anyway.
And after grepping on commits it in fact looks like if big.LITTLE _is_ supported in Linux. Wikipedia also claims this.

Out of the box linux supports big.LITTLE as architecture, but schedulers are meant for SMP. That means that tasks get scheduled to a CPU, be it A7 or A15...
There are patches from Samsung that do good job actually utilizing big.LITTLE, but it is still not ok. (Which makes it not Linux, because linux is that what you get from kernel.org).

This sounds like very synthetic use case. I guess for web site it can be good to power up full A15 core, let it chew web site internals at full speed and then go sleep, downclock and maybe even power gate some cores. I see little reason for A7 core at all: it would make users waiting longer for page processing while A7 core will be busy and overall amount of power spent to serve user wouldnt be anyhow small. Sounds like weird technical solution.

The problem with computers is that a lot of people have a very limited view of the world. If a solution is not fitting in that world, it is a stupid solution according to those people. Powering on an A15 takes time.

And what OS you're usnig if "Linux does not supports this"? Huh?

Linux does not support big.LITTLE scheduling and power management. Kernel forks do support them.

If it eats some WATTS of power, it is probably CPU frequency scaling issues, etc? Usually mobile SoCs can go as low as several MHz and reduce voltage, causing orders of magnitude drop in power consumption. However it requires to have proper in-kernel support for power manager regulators to adjust voltages on the fly and of course proper frequency scaling. While frequency caling is quite ofen sorted out in Linux kernel, dealing with custom power manager IC or subsystem could be tricky and in this case voltages could be left at maximum values, which warrants chip stability even at highest clock but very suboptimal in sense of power consumption since if you run at several MHz, IC would remain stable at much lower voltages than maximum. But you'll have to set full voltage before increasing CPU frequency and wait for voltage increase to happen, or you can get some nasty stability problems. Needless to say it takes some time. And to make it even less fun, standard Linux schedulers tend to behave quite poorly if you have to go from 20MHz to 1500MHz. So overall it can kill interactivity to the hell unless you manage to sort it out. Waiting for system to upclock for whole second can be PITA for, say, desktop.
Ideally, there should be some power gating with ability to leave only one core on low frequency to give Linux chance to ramp up as needed, when extra load arrives. Though it's quite tricky to ramp up from deep powersave modes at good speed, so there are some latencies attached.

I'm not really sure you really understand the architectures. The A15 is very big, hence the name big, which is all powered, the A7 is small. There are a lot of problems with frequency scaling and at this moment is such crap that you have to pre-warm the CPU by doing things like busy waiting so that it is completely scaled up and can run your stuff.
But from all the crap that exists, linux is still the best in the world.