Raspberry Pi 4 Thermal Performance Is Improving With New Firmware

[AsuMagic]

It really isn't convincing enough. For one reason, you're not running into ram limits on RPis yet. They may have other reasons dealing with performance and feature support. Just because Canonical wants to jump off a cliff is no reason for everyone else to do so. I'm speculating here. I only have a Pi B+ from years back, so I have nothing to compare software distributions on to see if there are any compelling reasons beyond supporting the whole line with a single release.

I don't think it is a good idea to compare 32-bit ARM vs 64-bit ARM in the same way as x86 vs x86-64. The concerns aren't the same.

[discordian]

Last I heard, they were saying that there was no convincing need for it (as if 64>32 is not convincing enough). Probably they just want to keep making one release that works across all of their devices.

Ubuntu's release uses the 64-bit kernel, and Manjaro also has a pretty good 64-bit release.

Some convincing needs would be mapping large files (need the addresspace, not the physical RAM), docker only support 64bit Arm and several developer tools like valgrind or sanitizers not or barely working without 64bit.
And some less technical debt like not having a mandatory integer division on ARMv7, hence the kernel has to be compiled as if the instruction was missing (and later patches itself, bit the code is still suboptimal as the compiler expects function calls instead of instructions is can schuffle around).
Funny enough, any Cortex-M (small micro controllers) has a mandatory idiv.

If anything they could use a 32bit userspace with a 64bit kernel. I'd guess alot software is just ASM optimized for x86 and 32bit ARM (64bit Arm is like a complete different architecture).

[ernstp]

Next time, read the article before posting nonsense.

Doh, I got the bars in the graph mixed up :-)

[milkylainen]

Is this as usual with Raspberry foundation boards?
No real SoC or board documentation? Just superficial?
New u-boot and firmware? Can someone point me to the code?

[betam4x]

They should segment the Pi into 3 separate product lines: High Performance, Standard (current raspberry pi), and Ultra Low Power (pi zero). The high performance model could include a significantly faster SOC that requires active cooling, a new (standardized) form factor large enough for an NVME m.2 drive, yet still small and compact (they could do away with the headphone jack, since HDMI already includes audio) and replace the micro-usb jack with USB type C for charging). I would pay up to $100 personally for that type of device. The standard model would be the current Pi. The ultra low power would be the Pi Zero.

[dwagner]

Anyone know why RPI 4 on raspbian still use armv7 kernel and not AARCH64?
Also why not series 5.X?

Mostly because the Raspberry makers care much more about compatibility with lots of existing add-on hardware and their often closed-source drivers than about using the CPU cores to their full extent.

That said, you can always install a different distribution and/or run your own kernel. For example, see these instructions for Arch Linux with 64bit kernels on Pi 4b: https://esotericnonsense.com/blog/rpi-chroot.html

(I run my Pi4 with Arch Linux, as I really do not like "Raspbian" that much.)

[kozman]

xpris In some cases AARCH64 feels much slower. Haven’t investigated why.

Follow this thread for 64-bit kernel news. https://www.raspberrypi.org/forums/v...?f=29&t=250730

Moving to 5.4 is happening next year. Should help a lot on Pi4. Pi3 and earlier, remains to be seen. Maybe for VC4?

[Caffarius]

Follow this thread for 64-bit kernel news. https://www.raspberrypi.org/forums/v...?f=29&t=250730

Moving to 5.4 is happening next year. Should help a lot on Pi4. Pi3 and earlier, remains to be seen. Maybe for VC4?

Just upgraded packages on my Pi 3's Arch Linux Arm install. Their aarch64 kernel is at 5.4.1 today. I can't say it feels any snappier but I'm bottlenecked by the SD card.

A little ironic considering Arch Linux (x64) still has 5.4.1 in testing.

[archsway]

Some convincing needs would be mapping large files (need the addresspace, not the physical RAM), docker only support 64bit Arm and several developer tools like valgrind or sanitizers not or barely working without 64bit.

What made you get that idea?

$ pacman -Si docker | grep ^Arch
Architecture    : armv7h

Also, on Docker Hub many official images (ex. gcc) show with support for both "ARM" and "ARM 64", so it's not just community supported.

Why do you say valgrind is "barely working"? I used it a couple of weeks ago to find some bugs and it was working perfectly fine for me. Maybe for programs using a lot of RAM there will be issues, but physical RAM limits will be hit first.

Which sanitizers don't support 32-bit ARM? The memory tagging stuff was only added in Armv8.5-A, of which no consumer (i.e. not server) devices I'm aware of currently support, so that's not an advantage for current 64-bit ARM.

[uid313]

I would want ARMv8, it is modern and clean. I would not want the old legacy ARMv7.

Can you run ARMv8 on Raspberry Pi 4? Else it is not a much appealing SoC.
Do most people run their Raspberry Pi 4 as ARMv7?

Hey everyone, are you happy with your Raspberry Pi 4?
What are you happy about?
Anything that you miss from it? or could be better?