Raspberry Pi 3 have CPU armv7l instead Armv8 [obsolete]

[emilio86]

Hello. I purchased a raspberry pi 3 by http://it.rs-online.com website. Once installed ubuntu Mate, I did a check of the technical specifications of the raspberry, and it is found that the processor is a ARMv7l "breadcom BCM2709" instead of a ARMv8.
You know explain the reason? I think that this anomaly is truly paradoxical.

[jamesh]

That is being reported incorrectly - its definitely Armv8 (Four a53 cores)

However, all the current OS' are 32bit, 64 versions are under development.

[fruitoftheloom]

Hello. I purchased a raspberry pi 3 by http://it.rs-online.com website. Once installed ubuntu Mate, I did a check of the technical specifications of the raspberry, and it is found that the processor is a ARMv7l "breadcom BCM2709" instead of a ARMv8.
You know explain the reason? I think that this anomaly is truly paradoxical.

"breadcom BCM2709" it is actually Broadcom !

Code: Select all

cat /proc/cpuinfo

http://elinux.org/RPi_HardwareHistory

[emilio86]

That is being reported incorrectly - its definitely Armv8 (Four a53 cores)

However, all the current OS' are 32bit, 64 versions are under development.

Thank you for answering. However I do not agree with his answer because the Linux operating system, includes commands that allow you to read information from hardware devices. The illustrate the two commands that I used on raspberry pi 3 to read the cpu informations.
Command one:
desktop:~$ lscpu
Architecture: armv7l
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
Model name: ARMv7 Processor rev 4 (v7l)
CPU max MHz: 1200,0000
CPU min MHz: 600,0000

Command two:
desktop:~$ cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 4 (v7l)
BogoMIPS : 76.80
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4

processor : 1
model name : ARMv7 Processor rev 4 (v7l)
BogoMIPS : 76.80
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4

processor : 2
model name : ARMv7 Processor rev 4 (v7l)
BogoMIPS : 76.80
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4

processor : 3
model name : ARMv7 Processor rev 4 (v7l)
BogoMIPS : 76.80
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4

Hardware : BCM2709
Revision : a02082
Serial : 00000000e3972860

[RaTTuS]

because it is running in 32bit mode it is begin reported as such
when it runs in 64bit mode it will have different output

[jamesh]

That is being reported incorrectly - its definitely Armv8 (Four a53 cores)

However, all the current OS' are 32bit, 64 versions are under development.

Thank you for answering. However I do not agree with his answer because the Linux operating system, includes commands that allow you to read information from hardware devices. The illustrate the two commands that I used on raspberry pi 3 to read the cpu informations.

They are definitely a53 cores on the Pi3. No doubt whatsoever.

[emilio86]

Thank you all for the information.
Yesterday I studied on the basis of your information, and I found this link that describes All the amenities of the raspberry pi 3 than the raspberry pi 2:

https://www.element14.com/community/com ... hmark-ever

[E3V3A]

This should really be fixed, regardless of whether kernel is running in 32 or 64 bit mode. Why hasn't it been fixed? (Beginners are getting confused all over the place.)

[DavidS]

Well when running in Aarch32 mode it acts like an ARMv7 with some missing instructions, so it makes perfect since that it is reported as an ARMv7 (though that should be modified to highlight the missing instructions, and depricated forms of other instructions that work on a real ARMv7 and not an ARMv8 in Aarch32 mode).

[ejolson]

Well when running in Aarch32 mode it acts like an ARMv7 with some missing instructions, so it makes perfect since that it is reported as an ARMv7 (though that should be modified to highlight the missing instructions.

Do you have an experimentally verified list of deprecated instructions that operate differently on a Pi 3 versus a Pi 2. I'm thinking in particular of SMP memory barrier and fence instructions. Also, if there are differences, then it should be possible in software to detect a Cortex-A53 running in ARMv7 mode and report this properly in /proc/cpuinfo. Maybe if less time were spent discussing splash screens.

[davidcoton]

Splash screens may not be important to you, but if a consequence of enabling the splash screen by default is that some previously working systems will no longer boot, that is a high impact problem. On the face of it much more urgent than an error in a report, that can't be rated as more than unfortunate.

I've managed bug lists for commercial products, and believe me prioritisation is a no-win situation. One person's "critical situation" against a stupid inconvenience for most users. Anyone? (Answer: it depends how many licences the one person will buy.... )

[DougieLawson]

I've managed bug lists for commercial products, and believe me prioritisation is a no-win situation. One person's "critical situation" against a stupid inconvenience for most users. Anyone? (Answer: it depends how many licences the one person will buy.... )

That's not unlike how it was when I worked for IBM. There was one notable customer who called "severity 1" for every problem record to the point where they were calling in their ticket before they'd even determined the vaguest details of why their mainframe and customer facing application was broken (let alone providing even the basic diagnostic materials). It was impossible to work with folks like that. Their absurd tickets basically said, "get your crystal ball running you've got to use that to divine what we're telling you and guess the solution".

[jahboater]

Well when running in Aarch32 mode it acts like an ARMv7 with some missing instructions, so it makes perfect since that it is reported as an ARMv7 (though that should be modified to highlight the missing instructions.

Do you have an experimentally verified list of deprecated instructions that operate differently on a Pi 3 versus a Pi 2. I'm thinking in particular of SMP memory barrier and fence instructions.[/url].

ARM documentation:

Code: Select all

The following are obsoleted in ARMv8:
• A32 SWP and SWPB instructions.
• Jazelle (only trivial implementations are supported).
• VFP short vectors and asynchronous bounces.
• Fast Context Switch Extension (FCSE).
The following are deprecated in ARMv8 and may be disabled by privileged software:
• A32 and T32 CP15 barriers CP15DSB, CP15ISB and CP15DMB.
• A32 and T32 SETEND instruction.
• A subset of T32 IT instruction functionality, as described in §6.1 below.
• T32EE instructions and coprocessor registers are both deprecated and optional.

[jahboater]

because it is running in 32bit mode it is begin reported as such
when it runs in 64bit mode it will have different output

In 64-bit mode lscpu reports "Architecture: aarch64"

No ARMv7 CPU can run aarch64. It is most definitely armv8.

[filker0]

To make it clear why /proc/cpuinfo does not report the cores as ARM Cortex-A53 when running in 32 bit mode:

• The kernel is a V6 kernel; it is unaware of the V8 architecture so the CPU cores must present themselves in a way compatible with the V6 (Raspberry Pi 1)
• Many drivers, libraries, services, utilities, and the kernel itself, use the information in /proc/cpuinfo to determine how to behave

The "CPU Part" value "d03" from the MIDR register identifies the core as A53. http://infocenter.arm.com/help/index.js ... FEABI.html has the information about the A53 (the link is to the AArch32 MIDR page, but you can navigate around it for the rest of the info.)
I hope this helps put this issue to rest.

[bensimmo]

You could add
arm_control=0x200
To config.txt if I remember correctly, to tell it to show v8?

[jytou]

Hi all,
I'm new here and I'm having trouble compiling handbrake and searching for the best options to use while compiling.
My understanding is that the RPI3 has 64 bit armv8 cores but as the kernel doesn't recognize them because it lacks support, any cpuinfo gathered from the system is unreliable. And the system is in the meantime running 32 bits with a strange "v7" set of instructions for lack of support of the 64 bit cores.

Okay. Good. But now, what options should I use for GCC on such a system? If I use armv8, am I not going to get into trouble since the proc is not recognized to run in 64 bit mode in the system anyway? If I use armv7, am I not going to have instructions that are actually not supported by the armv8 since it is not a v7? What would be the preferred set of mcpu/march and also fpu while we're at it?

Typically, compiling handbrake with armv7 is not going very far. But even if compiling with armv8 gets further, it is giving the "double free or corruption" error message and I can't go further. I've tried different flavors of arch/cpu settings, to no avail so far. So I'm just wondering what the recommended settings would be, since it seems we're in a hybrid position here...

Thanks!

[jahboater]

ARM v8 can run in 32-bit mode or 64-bit (aarch64) mode.
Currently Raspbian runs in 32-bit mode. There is nothing wrong with that, it is not a kludge.

Okay. Good. But now, what options should I use for GCC on such a system? If I use armv8, am I not going to get into trouble since the proc is not recognized to run in 64 bit mode in the system anyway? If I use armv7, am I not going to have instructions that are actually not supported by the armv8 since it is not a v7? What would be the preferred set of mcpu/march and also fpu while we're at it?

I use:

Code: Select all

-mcpu=cortex-a53  -mfpu=neon-fp-armv8  -mneon-for-64bits

If you find a 64-bit OS to run on the Pi then

Code: Select all

-mcpu=cortex-a53

is sufficient.

NEON/floating point is fixed and always available in aarch64 so there are no options for it.

[jytou]

I use:

Code: Select all

-mcpu=cortex-a53  -mfpu=neon-fp-armv8  -mneon-for-64bits

Thanks, I'll go with that. It didn't solve my particular problem with compiling handbrake's newest version, but an older one worked.

[eskc]

You could add
arm_control=0x200
To config.txt if I remember correctly, to tell it to show v8?

Do NOT do that. It caused the boot sequence to hang.

If you have done this, you will have to move the SD card to a reader connected to a PC; and remove using a plain text editor using notepad or notepad++ . Thus, it will revive as normal.

[JJBza]

Hi There,

Completely new to this as well. So I understand that the Raspbian version only support 32bit at the moment and hence using Raspbian on the Pi3 causes the Pi3 /proc/cpuinfo to report ARMv7, but if ARMv8 supports 32bit, is there some change to make such that the Pi reports ARMv8 but in 32bit mode?

Thanks for the information so far.