RPi5 out

Hi there,

Specs of RPi5 are out…and you can buy it already in October! => Link here

As expected it’s a Crotex 76 based SOC. As I got a similar device already running at home from a different vendor under Linux, I can say it’s roughly double the speed of RPi4. As far as I remember we might not have a chance to see Risc OS easily or even running at all on this one, or ?

I’d be more interested in a Raspi 500, let’s see if they update this one, too.

to see Risc OS easily or even running at all on this one, or ?

32Bit mode on the Cortex-a76 is EL0 (User mode) only so no RISC OS.

Finally has native SSD support… but no RISC OS :(

So, the practical question, in the absence of any likelihood of a 64-bit RISC OS any time soon (or ever): is there any form of emulation on ARM that might offer superior performance to a Pi4 running natively? Timothy Baldwin’s RISC OS on Linux?

It will be at least another Pi generation or two before emulation is anywhere near Pi 4 native speeds. But I’m sure before then someone will have come up with some sort of hack to run much of the privileged code in user mode.

But there is no great rush to get something going on the Pi 5, the Pi 4 will be in production for quite a few more years, and making some use of it’s 3 cores which are sitting around idle would be more of a benefit. Particularly as native RISC OS software is plenty quick, and it’s only trying to run ported multi core browsers on a single core that really shows up the issues.

But the Pi 5 will be a massive befit to those running Linux, I’m just planning which of my Pi 4’s I’ll be upgrading first, and how then to move the Pi 4 down the chain of older machines. I’ve still got one Pi 2 in operation, the Pi 1s having been phased out a few years ago, but are still in working condition.

Pi5 previews.

ExplainingComputers

Jeff Geerling

It will be interesting to see how long models last, with the 4B and 3A and B all still listed, just not necessarily available, those provide supported hardware.

Whilst I run 2 4Bs for things, currently a PiHole and Windows on ARM test, a 5 might be nice, but my RISC OS setup is quite happy on its 3A.

Does make me a bit nervous it may be troublesome to bring new people in if Pi 5 becomes more common and hardware that can run RISC OS becomes more rare, but no point losing sleep over it at the minute. I may need to start hoarding some machines.

It’s even more likely that someone will put RISC OS on an pervious Pi model left over after they have upgraded, rather than rushing out to buy one specifically for RISC OS.

Well, I agree most people won’t be rushing out to buy a new Pi just for RISC OS, but it still would shut out first-time Pi buyers who start with the latest model.

Yes I think the problem going forwards is that there will be a lot of people for whom a pi5 will be their first pi and so we over time be loosing access to the huge audience we have had over the last 10 years.

Good grief, it wants a five amp power supply…

Still, it seems quite considerably faster.

My pre-order is in. Only one so far as I don’t want to get caught out by them releasing a 16GB model just after I’ve upgraded all the Pi 4s.

But that was how I’m now running RISC OS on a 4GB 4B, as I’d just bought the 4GB for Linux and literally the day after the 8GB came out.

Good grief, it wants a five amp power supply…

Next step to compete with a standard PeeCee

Unless by some miracle someone can successfully port RISCOS to a Pi5, I’ll stick with my Pi4s.

“Good grief, it wants a five amp power supply…” it doesn’t just if you want lots of peripherals connected at the same time. It will work fine with a Pi4 3A PSU.

But I’m sure before then someone will have come up with some sort of hack to run much of the privileged code in user mode.

99% of modules should never have run in svc mode in the first place.

⬆️ This.

But I’m sure before then someone will have come up with some sort of hack to run much of the privileged code in user mode.

Good luck!

What happens to swis if you only have user mode?

@ Colin

What happens to swis if you only have user mode?

If you’re refering to the ARM SWI instruction (beside it’s now SVC), you do have “SWI” on AArch64.

If you’re refering to what people call the “RISC OS API” (which is based on the traditional ARM SWI), then it doesn’t work on PI 5, simply because as soon as the CPU traps a request to enter privileged mode, it will switch to AArch64 which is not binary compatible with RISC OS. Given that a boot starts from that, RISC OS is not even capable of booting on a Pi 5 (without being rewritten for AArch64 obviously).

So, for now, the Pi 5 is no go, as simple as that.

As Michael pointed out, it’s not even a question of “someone coming up with some sort of hack”, the OS must be either rewritten OR there has to be a layer of emulation added. This regardless of 99% of modules should never run in SVC (which is true), but won’t help here, because to provision HW resources and interfacing with the HW the OS must be converted to AArch64 OR an emulation layer has to be introduced.

Now, I let this sink in, surely overtime people will come around. Right now it’s the usual emotional reactions to the big change, where a lot of things will be said and a lot of theories (unfortunately without actually sitting and coding to prove such theories to be right or wrong, because let’s face it the problem is the lack of developers) until people will have to accept the reality, like it has happened with the idea of adding an Hypervisor layer (which I did) and next I need to add DT support in the HAL to make the whole circus work (and this is just for AArch32), for AArch64 it’s even more pain along the way…

What happens to swis if you only have user mode?

The kernel could, and should have from the very beginning of Arthur, switched back to usr mode before calling a module’s SWI handling code. I bet a large chunk of modules would be oblivious and happily work with negligible modifications (Draw, BASIC, toolbox… probably even most of the Wimp). Others might need memory map tweaks, I suppose.

Plus, imagine all that memory safety we’d have had. Far fewer reboots.

ROFL

@ paolo

Ok – just trying to get a simple understanding of the problem – so it’s elevated to a 64 bit supervisor mode. Can’t modules which don’t need device access move to user mode (swi calls being redirected), modules’s that do need supervisor mode access be recompiled 64bit or have a parallel 64 bit module which gives device register access. Is this too simplistic.

I’m thinking of usb it has a interrupt entry point and needs access to the registers. The usb driver can stay in usermode. The ehci driver can be in usermode needs an interrupt redirecting to user mode and access to the ehci registers via a sys command. So you just need to change how ehci reads/writes registers which is probably a macro change.

Correct me if I am wrong here, but as Paolo wrote. The swi instruction that is the way riscos runs, puts the cpu into exception. That sets the cpu to 64bit. Every time.