RPi 4 / STM32 / ESP32 / Teensy 4 / RISC-V GAZPACHO

[brucehoult]

I wonder if they will finally transition the supported/approved OS to 64-bit?

Still 32 bits. Raspbian Buster needs to be backwards compatible with older pi versions. Raspbian (32 bits) can address up to 4Gb. There is no need to change to 64 bits

One of my own benchmarks I use to compare CPUs shows the same C code running on an Odroid C2 being 22.7% faster when compiled for 64 bit than when compiled for 32 bit. This is a benchmark btw that uses less than 16 KB RAM, so 4 GB is not the issue.

19.500 sec Odroid C2 A53 @ 1536 MHz A64  276 bytes
23.940 sec Odroid C2 A53 @ 1536 MHz T32  204 bytes

[HoracioDos]

I wonder if they will finally transition the supported/approved OS to 64-bit?

Still 32 bits. Raspbian Buster needs to be backwards compatible with older pi versions. Raspbian (32 bits) can address up to 4Gb. There is no need to change to 64 bits

One of my own benchmarks I use to compare CPUs shows the same C code running on an Odroid C2 being 22.7% faster when compiled for 64 bit than when compiled for 32 bit. This is a benchmark btw that uses less than 16 KB RAM, so 4 GB is not the issue.

19.500 sec Odroid C2 A53 @ 1536 MHz A64  276 bytes
23.940 sec Odroid C2 A53 @ 1536 MHz T32  204 bytes

Simon Long from Raspberrypi blog
We cannot avoid focussing on backwards compatibility; it may not matter to you, but it is massively important to us. There are 27 million Pis in the wild; I don’t have exact numbers to hand for how many of those are Pis 1, 2 and Zero, but it’s well over 10 million of them. As soon as we move to a 64-bit OS, those devices are orphaned, because we do not have the resource to maintain two separate forks of Raspbian. (Not to mention to handle the support requests we will get from the thousands of users who download the wrong version and find it doesn’t boot.)

No-one has yet managed to provide us with a convincing use-case for where a 64-bit OS actually provides a real, quantifiable benefit to end-users. 32-bit accesses the entire RAM of the 4GB Pi 4. 64-bit code is invariably larger than 32-bit code – compare the sizes of the 32-bit and 64-bit versions of Windows 7; the 64-bit version is 30-40% larger. That’s a lot of extra download bandwidth for us, and for our users. A lot of 64-bit code actually runs slower than the 32-bit equivalent – because it’s larger, it takes longer to pull in from backing store. There are numerous costs attached to 64-bit – and we have yet to find a proven use-case where it actually offers any benefit whatsoever to the vast majority of our user base.

So no, this is not the ideal platform for the transition, or the time to make it. When (and if) we have a board that has more than 4GB of RAM – and that is likely to be a good few years off from today’s launch – we will look at 64-bit. But until then, the advantages of 32-bit – backwards compatibility, size, speed; of which backwards compatibility is easily the largest – vastly outweigh the putative advantages of a move to 64-bit at this point in time.

[brucehoult]

64-bit code is invariably larger than 32-bit code – compare the sizes of the 32-bit and 64-bit versions of Windows 7; the 64-bit version is 30-40% larger. That’s a lot of extra download bandwidth for us, and for our users. A lot of 64-bit code actually runs slower than the 32-bit equivalent – because it’s larger, it takes longer to pull in from backing store.

This is undeniably true for ARM 64 bit code.

There are a lot of ways that Aarch64 is well designed, but it's been my opinion ever since it was announced that ARM has been foolish to forget that it was the 16/32 bit opcode Thumb2 that really gave them dominance. ARM was doing well in mobile in 2003 with the ARM7TDMI but it was Thumb2 that launched them into hyperspace.

With 64 bit they seem to have had an attitude of "Well, if we're close to x86_64 and beating MIPS and PowerPC on code size then we'll be fine".

This is going to be, personal opinion, the one purely technical thing that will help drive RISC-V through the ARM world in the coming years. RISC-V has Thumb2-like instruction encoding and code size for 64 bit code (and 128 bit) as well as for 32 bit code. RV64 programs are essentially the same size as RV32 programs.

[NiHaoMike]

So the infamous "3.5GB" issue does not apply to ARM? And that some 64 bit advantages on x86 (e.g. more registers, guaranteed SSE2 compatibility) do not apply to ARM?

[brucehoult]

So the infamous "3.5GB" issue does not apply to ARM? And that some 64 bit advantages on x86 (e.g. more registers, guaranteed SSE2 compatibility) do not apply to ARM?

I think 3.5 GB was always a PC architecture memory map thing, nothing to do with x86 as such.

ARM 64 bit certainly does have some advantages similar to those you give. You get 32 registers instead of 16 (whereas 64 bit x86 is 16 registers instead of , a better function call ABI, and I believe with the -A profile you are also guaranteed to have both FPU and NEON, so there is no need to check for them.

[Berni]

It is possible to have more than 4GB of RAM on a 32bit x86 CPU, but windows generally doesn't implement it (Some server version do have it tho).

Its called PAE (Physical Address Extension) and works much like memory paging that was used on oldschool 8bit CPUs. And ARM does have its own implementation of it on the bigger chips, so they are indeed able to address more than 4GB of memory. As for the ~3.5GB instead of 4GB limit, that's mostly because the ~0.5GB is used as hardware registers for peripherals, video memory and other specialized tasks.

That being said just because the CPU can address more than 4GB doesn't mean that the applications running on it can easily make use of it all since the 32bit instruction set is not made for addressing so much memory. But the MMU can be used to map user application in different parts of the >4GB memory, so while a single one can't use it, you can still run multiple apps, each using its own chunk of memory to fill out all of the RAM.

Since Linux is capable of using PAE id expect there to be no big problems making a 8GB raspberry pi in the future on a 32bit OS. Just don't expect to be able to successfully malloc a 5GB chunk of memory in your program.

[GeorgeOfTheJungle]

For example my Mac has 16GB and it's running OSX 10.6 in 32 bits mode and everything is fine and dandy.

[GromBeestje]

It is possible to have more than 4GB of RAM on a 32bit x86 CPU, but windows generally doesn't implement it (Some server version do have it tho).

All Windows kernels implement it, it's just not normally enabled on non-server SKUs. By cracking Windows kernel (magic byte replacement using a hex editor), PAE can be enabled.

http://wj32.org/wp/2013/10/25/pae-patch-updated-for-windows-8-1/

This is enforced since, if memory serves correct, Windows XP Service Pack 2. Windows XP gold and Windows 2000 give you all the memory. Back in the days this was a reason not to install the Service Pack.

[eugenenine]

PAE was just a windows issue, mostly for backwards compatibility.

I've always ran Slackware ARM so I have been running 64bit on my 3's already.

[brucehoult]

PAE was just a windows issue, mostly for backwards compatibility.

The PAE *name* is an x86-specific thing (not Windows), but the concept is common across I'd think all modern CPUs.

For example in RISC-V land we have the following virtual memory modes:

sv32: supports a 4 GB virtual address space in a 16 GB (34 bit) physical address space, using a two-level page table. This is similar to PAE, except PAE used a 3-level page table to support a 36 bit (64 GB) physical address space.

sv39: supports a 39 bit (512 GB) virtual address space in a 56 bit physical address space, using a three-level page table.

sv48: supports a 48 bit (256 TB) virtual address space in a 56 bit physical address space, using a four-level page table.

As a comparison, early x86_64 supported 48 bit virtual and 40 bit physical address space, with the current page table format supporting a future limit of 64 bit virtual addresses in a 52 bit physical address space.

ARM also has a similar Large Physical Address Extension (LPAE) supporting up to a 44 bit physical address space from a 48 bit virtual address space (on ARMv8 obviously).

[HoracioDos]

Pi4 not working with some chargers (or why you need two cc resistors)
https://www.scorpia.co.uk/2019/06/28/pi4-not-working-with-some-chargers-or-why-you-need-two-cc-resistors/

[SiliconWizard]

Pi4 not working with some chargers (or why you need two cc resistors)
https://www.scorpia.co.uk/2019/06/28/pi4-not-working-with-some-chargers-or-why-you-need-two-cc-resistors/

Ouch. That's a nice design fuck-up.

[Monkeh]

Pi4 not working with some chargers (or why you need two cc resistors)
https://www.scorpia.co.uk/2019/06/28/pi4-not-working-with-some-chargers-or-why-you-need-two-cc-resistors/

Ouch. That's a nice design fuck-up.

Ah, but their testing was very extensive so it's quite surprising. Just like the PoE fail.

[SiliconWizard]

Probably extensive with just the power adapter they are suggesting (which is likely just a dumb adapter routing the +5V to the VBUS pins)...

Now USB-C is a bit of a bitch, so if you're going to use it, at least use it right! Otherwise they should just have added a basic power connector, much simpler and less expensive...

[Kjelt]

I always hated the USB connector for power.
Why not a simple small Phoenix Contact connector with screws, at least you can connect a decent power supply instead of a ccc.

[CJay]

I always hated the USB connector for power.
Why not a simple small Phoenix Contact connector with screws, at least you can connect a decent power supply instead of a ccc.

Because "everyone" has a microUSB PSU (I know, not everyone has one suitable now the current draw is higher but I ran my Pi 1 from a HTC phone charger for years), they all have the same polarity and are all 5V, fit a connector that gives the user scope to reverse polarity it or apply 240VAC and users will do that.

[james_s]

I've also always hated the USB connector for power. The vast majority of my micro USB power supplies are inadequate and result in unreliable performance. Most of the cables are also insufficient and have too much resistance. I've resorted to soldering on a barrel jack on a pigtail and that has always been rock solid. I have loads of 5V wall warts with standard 2.1mm barrel jacks and I've never had one not work. Wish they'd at least provide pads for something more sensible.

[eugenenine]

The option to power from pins on the GPIO has always been available.

[NiHaoMike]

I've also always hated the USB connector for power. The vast majority of my micro USB power supplies are inadequate and result in unreliable performance. Most of the cables are also insufficient and have too much resistance. I've resorted to soldering on a barrel jack on a pigtail and that has always been rock solid. I have loads of 5V wall warts with standard 2.1mm barrel jacks and I've never had one not work. Wish they'd at least provide pads for something more sensible.

My experience is that any cable and adapter that works well for charging a modern smartphone will work well for powering a Pi.

[coppice]

I've also always hated the USB connector for power. The vast majority of my micro USB power supplies are inadequate and result in unreliable performance. Most of the cables are also insufficient and have too much resistance. I've resorted to soldering on a barrel jack on a pigtail and that has always been rock solid. I have loads of 5V wall warts with standard 2.1mm barrel jacks and I've never had one not work. Wish they'd at least provide pads for something more sensible.

My experience is that any cable and adapter that works well for charging a modern smartphone will work well for powering a Pi.

I agree. I've had troubles with USB cables powering a RasPi, but those were cables that wouldn't charge a phone properly. I haven't had any problems when using a USB cable that worked well with a phone. However, if the OP has lots of 5V wall warts around, there no reason not to use them.

[Berni]

Yeah i have seen WAY too many shitty USB cables that barely have any copper inside of them.

In fact at my day job i had a software guy come over about the product i designed, saying that no matter what he does it just won't charge the battery or it charges it with next to no current. So i hook it up at desk and it charges just fine, so i go over to see his setup and find a suspiciously flexible USB cable, turns out that cable was dropping a whole volt across it as soon as you tried to draw any proper current, so the charging IC inside my device was backing off the current thinking its overloading the charger due to the sagging input voltage.

These are the sort of cables that don't work on a Raspberry Pi and should be burned with there remains burred deep under so that nobody else would have to suffer there shitty performance anymore.

[coppice]

Yeah i have seen WAY too many shitty USB cables that barely have any copper inside of them.

A lot of good quality USB cables have serious problems supplying high current because of dirt build up on the contacts. A good spray with switch cleaner frequently improves things greatly.

[Kjelt]

It is just NOT a connector I feel comfortable running 2Amps continuously through.

[james_s]

I've never had a smartphone that charges with a regular USB cable and I keep my phones for ~5 years so I don't exactly have a pile of quality micro USB cables laying around. You never really know what you're getting when buying them either until you actually try them.

Whatever the case the USB cable has been my biggest source of aggravation by far with these things. I've always had to either specifically hunt down something reported to work well and buy it, or hack the thing and solder in a standard barrel jack which has worked perfectly every time. It should just have a buck regulator onboard for the 5V as well as 3.3V so it could use any standard 9-12V wall wart which are common as muck and generally quite robust with reasonably heavy cable.

Starting with 5V and expecting to have 5V at the other end of a thin cable with a teeny tiny connector is just asking for trouble.

[Mr. Scram]

A lot of chargers don't start with 5V though. They take the drop into account and actually start higher.