If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

I might not remember correctly, but wasn't it just the ARM implementations with out-of-order execution which were impacted by Spectre?

Cortex-A8 is in-order while Cortex-A9 and above is out-of-order and with that in mind RPi 3 should need to have Spectre mitigations while RPi 1 and 2 shouldn't?
Someone who knows more than me about this, please correct me because this doesn't make up so I'm obviously misunderstanding something.

Comment

Honestly what i find strange is that there is still no complete 64 bit support, that would give it quite a boost in performance.

You can run Ubuntu 18.04 LTS arm64 on the RPi3 with the Ubuntu arm64 kernel using U-boot. You can also do the same with the 3B+ so long as you use the Ubuntu 18.04.2 image, which (should) include kernel 4.18. I have a 3B+ running Ubuntu 18.04 arm64 and it works fine, though sometimes I wonder if it's actually slower than Raspbian despite being command line only (no XOrg running).

Comment

Honestly what i find strange is that there is still no complete 64 bit support, that would give it quite a boost in performance.

There's a few reasons that I've heard. For one, they only have 1GB of memory. Since I've run 64bit versions of Linux on other ARMv8 chips with only 1GB, I never considered that much of an excuse. Also, they have 512MB boards running 32bit Linux, so those boards should be under even more memory pressure. If they can run a 32bit OS in 512MB, they can run a 64bit on in 1GB.

The other big reason is that the processor that runs the Rpi--the VideoCore IV--can only address 1GB of memory. That means there will be no 'compatable' RPI board with >1GB of memory ever. There are other Broadcom chips with newer video cores that can support >1GB, but they won't be 100% compatable with existing RPI software. From their messaging, the Foundation seems very reluctant to make that leap.

I agree that going 64 bit on the A53 can provide huge improvements i performance, but they're only in very specific areas, so maybe they don't see the benefit? After all, they're not even optimizing their distro for the newer cores. That alone would pay off huge benefits. When it comes down to it, you don't use an RPI (or Raspbian) if you're looking for performance.

Comment

I might not remember correctly, but wasn't it just the ARM implementations with out-of-order execution which were impacted by Spectre?

Cortex-A8 is in-order while Cortex-A9 and above is out-of-order and with that in mind RPi 3 should need to have Spectre mitigations while RPi 1 and 2 shouldn't?
Someone who knows more than me about this, please correct me because this doesn't make up so I'm obviously misunderstanding something.

Comment

Honestly what i find strange is that there is still no complete 64 bit support, that would give it quite a boost in performance.

I am glad its is still 32-bit since the PI does not have more than 2G RAM.

Going 64bit will effectively 1/2 your D-cache size and do more or less the same for main memory, depending on use case, since 64bit word takes 2x the space of 32bit word.

Are there any CPU instructions/registers added in 64bit mode on ARM?

Basically you always want 32bit mode.
The only reason to have 64bit is if you want to address more memory directly.
32bit PAE can also address more memory, but slightly slower and with a 2G per process restriction.

The other reason you might want 64bit any way is if they added lots of CPU instructions/registers in 64bit mode (like on AMD64).
That is why x32 arch exits. It is 32bit on x64 with new instructions/registers available in 32bit mode. (All specInt etc benchmarks are x32 these days, because for the same instruction/register set, 32bit is almost always faster than 64bit)

So if you jump on the 64bit band-wagon just for the hell of it, you will in general be on a slower wagon

Michael This might be something you would be interested in testing on the RPI

Comment

Orange pi boards are cheaper and beyond rasperry pi boards. Used laptops cost the same as orange/rasperry pi systems. Android tv boxes can run Debian and they include cases and power units. For embedded development arduino and mbed boards suit better.

No one sane would even think of designing a used laptop into an embedded design. No hot spares, no direct replacements, unmountable, lunking-big KB display that generally have no use in embedded (embedded generally means no HMI) , and whopping big PSU - no reliable specs. You must be trolling!

If you need to add drivers to the kernel (most often true for embedded) then you should anticipate massive headaches with Allwinner. The MALI vid is a pre-eminent nightmare (thanks to ARM Ltd IMO). Allwinner regularly violates GPL including proprietary code in the kernel in direct violation of GPL; NVRAM, Vid, HDMI setup . My general experience (30+ years in embedded) is that Chinese vendors have absolutely no compunction about openly violating GPL and delivering functional kernels that cannot be re-built. Neither Rpi3*, nor OrangePi* have full schematics, power specs nor thermal specs- ALL are required for any competent embedded design.

Yeah save $5 and lose 100 consulting hours. You must be ignorant.
Post on some topic you understand.

Comment

I am glad its is still 32-bit since the PI does not have more than 2G RAM.

Going 64bit will effectively 1/2 your D-cache size and do more or less the same for main memory, depending on use case, since 64bit word takes 2x the space of 32bit word.

Are there any CPU instructions/registers added in 64bit mode on ARM?

Basically you always want 32bit mode.
The only reason to have 64bit is if you want to address more memory directly.
32bit PAE can also address more memory, but slightly slower and with a 2G per process restriction.

The other reason you might want 64bit any way is if they added lots of CPU instructions/registers in 64bit mode (like on AMD64).
That is why x32 arch exits. It is 32bit on x64 with new instructions/registers available in 32bit mode. (All specInt etc benchmarks are x32 these days, because for the same instruction/register set, 32bit is almost always faster than 64bit)

So if you jump on the 64bit band-wagon just for the hell of it, you will in general be on a slower wagon

Michael This might be something you would be interested in testing on the RPI

Raka555 - first, I must say I agree broadly with your reasoning and suggest everyone read and SERIOUSLY CONSIDER your very intelligent post before my comments.
Despite MY misgivings abt 64bit, memory/binary size in small systems - the early x86_64 binaries were indeed almost 2x the size, but as compilers/linkers improved the foot-print factor shrunk to about ~1.35x. The instruction space is marginally worse, and the data/address space is indeed almost 2x (but depends on some constant extension instructions for x86..). I've never performed the equivalent tests on ARM, but any serious embedded implementor should before they decide. MY impression is that Raka555 is right; the ARM instruction set isn't very memory space efficient at 64bit, and that limited memory in small system dictate 32bit.

Comment

I might not remember correctly, but wasn't it just the ARM implementations with out-of-order execution which were impacted by Spectre?

Cortex-A8 is in-order while Cortex-A9 and above is out-of-order and with that in mind RPi 3 should need to have Spectre mitigations while RPi 1 and 2 shouldn't?
Someone who knows more than me about this, please correct me because this doesn't make up so I'm obviously misunderstanding something.

Brand and model? Did the hardware (GPU, Wifi, LAN, etc) works well? And did it include RTC battery? Still searching tv box that have rtc with workable wifi and lan, and with close to or have mainline kernel.