You know explain the reason? I think that this anomaly is truly paradoxical.







"breadcom BCM2709" it is actually Broadcom !emilio86 wrote: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.![]()
![]()
![]()
![]()
![]()
![]()
Code: Select all
cat /proc/cpuinfo
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.jamesh wrote:That is being reported incorrectly - its definitely Armv8 (Four a53 cores)
However, all the current OS' are 32bit, 64 versions are under development.
They are definitely a53 cores on the Pi3. No doubt whatsoever.emilio86 wrote: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.jamesh wrote:That is being reported incorrectly - its definitely Armv8 (Four a53 cores)
However, all the current OS' are 32bit, 64 versions are under development.
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.DavidS wrote: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.
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".davidcoton wrote: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....![]()
)
ARM documentation:ejolson wrote: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].DavidS wrote: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.
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.
In 64-bit mode lscpu reports "Architecture: aarch64"RaTTuS wrote:because it is running in 32bit mode it is begin reported as such
when it runs in 64bit mode it will have different output
I use: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?
Code: Select all
-mcpu=cortex-a53 -mfpu=neon-fp-armv8 -mneon-for-64bits
Code: Select all
-mcpu=cortex-a53
Thanks, I'll go with that. It didn't solve my particular problem with compiling handbrake's newest version, but an older one worked.jahboater wrote:I use:Code: Select all
-mcpu=cortex-a53 -mfpu=neon-fp-armv8 -mneon-for-64bits
Do NOT do that. It caused the boot sequence to hang.