Samsung Exynos 5250 - production starting in Q2 2012

[Lodix]

I don't understand why so low information about the SOC of the phone.

 

[codedivine]

I think these might be the Geekbench results for the Exynos Note 4: http://browser.primatelabs.com/geekbench3/745794

Those results are for Aarch32. Aarch32 is for ARMv8 processors, so if those results are for the Exynos 5433, then it is a ARMv8 chip.

 

[Exophase]

I think these might be the Geekbench results for the Exynos Note 4: http://browser.primatelabs.com/geekbench3/745794

Those results are for Aarch32. Aarch32 is for ARMv8 processors, so if those results are for the Exynos 5433, then it is a ARMv8 chip.

I doubt that's what it means. Geekbench is probably just using "AArch32" to mean that it's targeting a 32-bit ARM ISA, probably ARMv7. Note that it says "Geekbench for AArch32", that suggests a property of the binary, not the system. ARMv8 AArch32 modes don't really add that much over ARMv7 anyway. There's precious little reason why a Geekbench build would target the former in a way that didn't work in the latter. I'd go so far as to say I'd be surprised if Android even supports it as a separate NDK target.

This will be clear if the same version of Geekbench is ran on some other device and shows the same message.

 

[codedivine]

I doubt that's what it means. Geekbench is probably just using "AArch32" to mean that it's targeting a 32-bit ARM ISA, probably ARMv7. Note that it says "Geekbench for AArch32", that suggests a property of the binary, not the system. ARMv8 AArch32 modes don't really add that much over ARMv7 anyway. There's precious little reason why a Geekbench build would target the former in a way that didn't work in the latter. I'd go so far as to say I'd be surprised if Android even supports it as a separate NDK target.

This will be clear if the same version of Geekbench is ran on some other device and shows the same message.

I had confirmed from John Poole of Primatelabs that they do in fact distinguish between Aarch32 and ARMv7. Aarch32 makes a difference in Geekbench scores because it adds (amongst other things) new instructions for AES and SHA-1 and he did confirm that they use them.

See this comparison with the Exynos version of Galaxy Note 3 using Cortex A15 and notice the difference in SHA-1 and AES scores in particular:

http://browser.primatelabs.com/geekbench3/compare/769515?baseline=745794

 

[codedivine]

I doubt that's what it means. Geekbench is probably just using "AArch32" to mean that it's targeting a 32-bit ARM ISA, probably ARMv7. Note that it says "Geekbench for AArch32", that suggests a property of the binary, not the system. ARMv8 AArch32 modes don't really add that much over ARMv7 anyway. There's precious little reason why a Geekbench build would target the former in a way that didn't work in the latter. I'd go so far as to say I'd be surprised if Android even supports it as a separate NDK target.

This will be clear if the same version of Geekbench is ran on some other device and shows the same message.

Also, there are actually only 3-4 results where Geekbench reports Aarch32, the other ones being a few Snapdragon 615 results. In other cases, it reports Android on ARMv7 accurately.

 

[Exophase]

I had confirmed from John Poole of Primatelabs that they do in fact distinguish between Aarch32 and ARMv7. Aarch32 makes a difference in Geekbench scores because it adds (amongst other things) new instructions for AES and SHA-1 and he did confirm that they use them.

See this comparison with the Exynos version of Galaxy Note 3 using Cortex A15 and notice the difference in SHA-1 and AES scores in particular:

http://browser.primatelabs.com/geekbench3/compare/769515?baseline=745794

I see. Well that's certainly interesting. You're right, I totally forgot about the encryption instructions (which also make Geekbench total scores kind of a farce)

But it'd be a ton clearer if it said ARMv8 A32 or something there. I'm sure ARMv9 will still keep the AArch32/64 designators, so it really says too little about architecture.

 

[Laurent06]

Part 3335 seems to confirm it's a Cortex-A57.

 

[codedivine]

Part 3335 seems to confirm it's a Cortex-A57.

Thanks! That's a much more direct way to confirm the processor ID than the long-winded routes I was taking. :smile:

 

[Nebuchadnezzar]

If this is really an A5X chip, then I wonder what's going on with them trying to keep quiet about it. The mobile division is probably putting pressure on them to avoid outcry on the S805 versions of the Note 4.

And if it is a A5X chip, they have a 6 month lead on everybody else if they already *ship* it in October.

 

[Alexko]

I think these might be the Geekbench results for the Exynos Note 4: http://browser.primatelabs.com/geekbench3/745794

Those results are for Aarch32. Aarch32 is for ARMv8 processors, so if those results are for the Exynos 5433, then it is a ARMv8 chip.

Compared to the fastest Shield Tablet entry I could find (which I think is the fastest ARM SoC currently available): http://browser.primatelabs.com/geekbench3/compare/755577?baseline=745794

 

[Nebuchadnezzar]

N910C scores seem to be even a bit higher and has more samples in the score browser: http://browser.primatelabs.com/geekbench3/compare/750158?baseline=775311

I think we can conclude that it is indeed an A57/A53 chip. Wonder what SLSI will officially name it and wether they're going with Exynos 7 or will just try to ignore it.

 

[Nebuchadnezzar]

The 5433 is a A57/A53 running on an abstraction layer being faked to most of the kernel as a A15/A7. We'll probably never see 64bit mode on this chip.

The Exynos7420 is their first real 64bit platform.

 

[Deleted member 13524]

The 5433 is a A57/A53 running on an abstraction layer being faked to most of the kernel as a A15/A7. We'll probably never see 64bit mode on this chip.

Why not? The Note 4 will surely get upgraded to Android L.

 

[Nebuchadnezzar]

Why not? The Note 4 will surely get upgraded to Android L.

The kernel is running in 32bit mode, and they will definitely not upgrade all drivers to ARMv8 once a product is launched and out.

http://www.anandtech.com/show/8537?previewkey=B2LO17I47DWMHL1Q

 

[Laurent06]

The kernel is running in 32bit mode, and they will definitely not upgrade all drivers to ARMv8 once a product is launched and out.

What a definitive answer. What makes you think so?

BTW all drivers are ARMv8, just not ARM64/AArch64.

 

[Nebuchadnezzar]

What a definitive answer. What makes you think so?

BTW all drivers are ARMv8, just not ARM64/AArch64.

The software stack has been done for months and they won't update it beyond security fixes once a device is out.

 

[Laurent06]

The software stack has been done for months and they won't update it beyond security fixes once a device is out.

That'd be bad and it makes the choice of the SoC all the more strange...

 

[Exophase]

The 5433 is a A57/A53 running on an abstraction layer being faked to most of the kernel as a A15/A7. We'll probably never see 64bit mode on this chip.

What does faked to the kernel as a A15/A7 mean? This is the same chip that reports a Cortex-A57 version string in Geekbench right? That's presumably taken from /proc/cpuinfo. Do you mean that the kernel is configured as A15?

 

[Nebuchadnezzar]

What does faked to the kernel as a A15/A7 mean? This is the same chip that reports a Cortex-A57 version string in Geekbench right? That's presumably taken from /proc/cpuinfo. Do you mean that the kernel is configured as A15?

I'm talking about driver implementation and interoperability. They did the absolute minimum in terms of drivers to make it work; the whole CPUFreq layer is identical and even treats it as a CA15/CA7 part. All the auxilliary IP block drivers are 32-bit, the device tree is exposed as ARMv7. The platform that is being pushed to mainline right now / Exynos 7 is a pure ARM64 implementation. I'll try to investigate more once I have the device, but I really doubt you'll ever see this thing running in AArch64.

 

[Deleted member 13524]

Perhaps they did the bare minimum for the launch window because the Note 4's lifetime with KitKat will be very short?