RPi5 out

Yes but then you are supervisor mode? If you have a ‘kernel’ operating in 64bit supervisor mode it can do all the redirecting can’t it? Doesn’t it become a question of how small you can make the 64bit kernel?

It would be theoretically possible to have RISC OS install a 64 bit SWI handler to drop to 32 bit user mode (after all, didn’t the RiscPC have 32 bit handlers massaging things down to 26 bit?).

Problem is twofold. Firstly anything that wants to access hardware or regions of memory locked off for system level code will either need to be made 64 bit, or turn the entire memory map to user mode writeable (as there’s no longer any SVC32).
Secondly, I’m willing to bet a lot of things do icky stuff with the PSR mode bits.
Thirdly (yeah, I suck at maths), what’s OS_EnterOS supposed to do?

To be honest, it seems like trying to bodge 64 bit support into a 32 bit OS is like trying to nail a peg leg onto an octopus.
At this point, the only sensible answer is emulation.

Piers – I’ll take your Arthur user mode switch and I’ll raise you *RMTidy ;)

Obviously there are problem areas – as there will be with any route – but a minimal system would just need usb and video hardware working that would give a desktop with network, storage, keyboard, mouse . Read and write device registers with swi OS_Read/writeDeviceRegister handled by the 64 bit kernel.

I have read it too. Not my thing. What shall I do with those item? For Risc OS a little bit oversized.

Micky

If there is only usr32, perhaps the mode bits are ignored and the hypervisor can set them to any value so that the code thinks it’s running in svc32? Failing that, there might be a bit to trap accesses to the mode bits in the PSR to a higher exception level.

The translation tables will be managed by 64-bit code, so it can change the ASID between one that allows access only to “usr” memory or to all memory available to legacy RISC OS in privileged modes.

Edit: Colin, the 64 bit code can be as large as it likes, it lives in a different memory map to 32-bit code.

You would need something of the sophistication of Aemulor to enable code which is expecting to be running in 32 bit SVC mode to run natively in 32 bit USR mode. It would need fix up the differences in behaviour and the things that can’t actually be done in USR mode by exception back up to the hypervisor. I don’t know if the tricks Aemulor used will still work on that core though.

All,

I am not sure I understand all the comments, what I do understand well however is coding. Mixing up 32 bit and 64 bit code on ARM it’s a complete pain, they are a) not binary compatible, b) can we please remember the good old concept of STATE?

Aemulor, the 32 bit code for the RiscPC, they all had a set of assumptions that are not happening here. <—- (read this careful, take your time)

On top of that there are the usuals:

First, 64 bit kernel code will need a way to share state with the 32 bit kernel code for whatever is needed to be shared, that is work on it’s own (and tests), because the existing OS has nothing of that designed/implemented.

2nd: pointers, are we talking of using compressed pointers? Another translation layer? work within PAE or 32 address space?

3rd having part of RO working in USR32 and part in privileged mode still means the part in privileged mode has to be 64 bit AArch64 and has to be written (last time I checked there is exactly 0 lines of AArch64 code in RO repos).

I understand everyone wants to sound knoledgable and all of that, but I’d suggest people go to model some code before attempting to throw theories, considering that everything has to work, the system needs to be stable and there are, well, 30 years of stuff made in all sorts of ways.

Has Rick mentioned, right now, focusing on having a good emulation solution, QEMU, RPCEmu or whatever is probably the most sensible thing to do. The Pi 5 is between 2 to 3 times faster than the Pi 4, so emulation won’t be terrible on it.

Yes QEMU/KVM may require quite a bit of memory, but there are 8GB models and that is more than enough to run RPCEmu totally fine and on Linux, so no extra costs for the users that can’t afford anything more expensive than 80 GBP. If 80 GBP is too much they can buy a Pi 4, 3, 2 or even 1 (for few quids).

While for a long term plan there are things that can be done. Obviously all of them require a community that is committed and ready to rewrite a good portion of the OS, we have people capable of doing this: Sprow, Jeffrey and few others (sorry if I am not naming everyone, not a name game).

If I can make a request, please please stop trying to make hypotesis on short cuts and ways around the problem, unless you’ve managed to write some working model that can prove concepts (for which I am sure everyone would be all hears). Just to write a barely working Hypervisor took me 3 years of spare time work and I still need to face the monumental work of adding Device Tree support in RO HAL (for which I am sure I’ll need Sprow, Jeffrey and orders help as well), it was a monumental amount of work, and that is not even close to the needs for AArch64. So, I don’t see shortcuts and “creative approaches” here that would warrantee a reliable OS.

Sorry, not trying to be negative, just trying to avoid having people with less knowledge to think it’s going to be “a walk in the woods”, which won’t happens and then (as a result) the usual shower of accusations on ROOL and others for not being doing “A” or “B”. An healthy community starts from the people with knowledge that can also take the time to determine it’s not going to be few lines of changes here and there.

Thanks, and again sorry if I have sounded negative, not my intention.

Has Rick mentioned, right now, focusing on having a good emulation solution, QEMU, RPCEmu or whatever is probably the most sensible thing to do.

Fixed that for you

I won’t disagree that I know nothing about the Hal and kernel but I’m just looking at it from the outside.

First, 64 bit kernel code will need a way to share state with the 32 bit kernel code for whatever is needed to be shared, that is work on it’s own (and tests), because the existing OS has nothing of that designed/implemented.

Why?

I don’t see it sharing anything I’m not envisioning the 64bit ’kernel doing much. think if it more like a hal just doing enough. It would be in the same thread as riscos – single tasking.

2nd: pointers, are we talking of using compressed pointers? Another translation layer? work within PAE or 32 address space?

would there be any pointers between 32 and 64 bit address space?

3rd having part of RO working in USR32 and part in privileged mode still means the part in privileged mode has to be 64 bit AArch64 and has to be written (last time I checked there is exactly 0 lines of AArch64 code in RO repos).

Yes surely the 64bit part is less than writing a hal. It just sets up the environment (memory, interrupt handler) and then everything is done in 32 bit user mode.

The 64 bit code probably has to handle OS_Memory calls, OS_ModifyRegister calls, bounce all other swis and pass on interrupts.

To those who deal with hals and kernel code and linux solutions this probably illustrates I don’t know what I’m talking about but it’s fun thinking about it.

I was about to tell the tale of current emulation effort , but changed my mind.
Maybe some other time!

I was about to tell the tale of current emulation effort , but changed my mind.
Maybe some other time!

I, and probably others, haven’t forgotten Michael.
Just didn’t want to start pressuring a willing volunteer.

I did, specifically, think about the Genode work while people were talking about QEMU on Linux and Windows.
It struck me though that the work is two streams that can work largely independently, in that the RO for QEMU can be done on a Linux or Windows platform with a specific set of features exposed to RO (masquerading as something else for the sake of RO)

I understand everyone wants to sound knoledgable and all of that, but I’d suggest people go to model some code before attempting to throw theories, considering that everything has to work, the system needs to be stable and there are, well, 30 years of stuff made in all sorts of ways.

That’s frankly insulting, please remember there are people with hell of a lot more ARM and RISC OS experience on this forum, and they are entitled to their views as much as you are.

Plus you missed my point completely which was to run the vast majority of SVC code in USR mode, using look-a-head interception similar to Aemulor without needing a 64 bit kernel. I do think a QEMU emulation of 32bit privileged code would be an easier and quicker option though.

That’s frankly insulting

What is offensive? Asking for people to slow down and test things before attempting rush judgments on a complex technical problem? Interesting definition of offensive, especially from Druk who known for being direct…

please remember there are people with hell of a lot more ARM and RISC OS experience on this forum, and they are entitled to their views as much as you are.

Of course you’re entitled to your own opinion, all I have asked is wait and figure out if it is practical or impractical. Why? Because of what you just said in the first part of the above comment, aka if Druck says something the less knowlegable people may just think it’s right because Druck said it, that will lead to people starting to post stuff without knowing if it’s actually feasible or not. BTW I still am not sure who you meant that should do the work you’ve mentioned ’cause I know you do not have time for it.

On top of that there is the usual “Oh just put a pinch of salt, a sprinkle of onions and a couple of slices of bacon” and it will take great, kind of approach which has never worked, after 30 years we still do not have the basics a decent OS should have.

But let’s explore this a little furter, all the changes required, may also involve a new builder or a set of changes in the builder, now that combined with we still are unable to release 5.30, should already give some ideas of the reasources vs actual achievable goals.

I am not criticising you Druck, so please stop taking it somewhat personal, I had no intention to be offensive (if I want to be you’ll get it straight away, believe me).

My point is simple and clear (and possibly the most achievable one here): Focus on emulation as stage one, QEMU, Genode, RPCEmu, whatever you like, forget about hybrid approaches or things that will introduce more complexity in the OS and it’s building. KISS, Keep It Simple and Stupid at the beginning, then start facing bigger challenges.

The Pi 5 is between 2 to 3 times faster than a Pi 4 and even more compared to a Pi 3 or 2, which a twice as fast SD and a ton more I/O bandwidth, so no one will feel the overhead of emulation (unless done drammatically bad of course). Obviously Genode and QEMU are probably favorite candidates if they can bring a modern ARM platform compared to RPCEmu, but in all honesty everything will just be fine for the average use people do with RISC OS (I still need to see an App that uses more than 32 MB of RAM, maybe I just don’t use that special one)

Plus you missed my point completely which was to run the vast majority of SVC code in USR mode, using look-a-head interception similar to Aemulor without needing a 64 bit kernel. I do think a QEMU emulation of 32bit privileged code would be an easier and quicker option though.

If I missed your point I am sorry, I did mention I wasn’t sure I was understanding all the comments thought, so your remark “on it’s offensive” is really misplaced, sorry.

Dear Colin

Why?

Because technically RISC OS is Acorn MOS where a lot of state is shared among multiple part of the OS and when you separate you may get bizzarre side effects if you do not at least synchronize it?

I don’t see it sharing anything I’m not envisioning the 64bit ’kernel doing much. think if it more like a hal just doing enough. It would be in the same thread as riscos – single tasking.

If you are talking of implementing some kind of micro-kernel as 64 bit kernel, you’d still need to figure out how the two would communicate, what would be the communication overhead and if it’s feasible. How IRQs would be treated and how an IRQ would be then treated from AArch64 to AArch32.

The 64 bit portion can’t be a HAL, a HAL is accessible from the rest of the OS (that’s why it’s an HAL) and AFAIR, IRQs would switch the CPU back to 64 bit, so IRQs handling has to be done in AArch64.

Before you also mentioned drivers, so that means all the driver infrastructure and the drivers code itself needs to be in the 64 bit portion of the kernel, unless you have changed your mind or are geeting confused with all the pieces.

Again emulation will make things a lot easier, nothing is preventing ROOL having the time, in the future, to implement a 64 bit version of the OS. I personally don’t see it happening, but I may be wrong.

would there be any pointers between 32 and 64 bit address space?

And how are you planning to pass data between the two? implementing a messaging system that doesn’t yet exists? Ok let’s add this to the above list then, I think your 64 bit kernel is growing in size a lot already (and the 32 bit portion already needs quite a bit of changes)

Oh and as mentioned on my response to Druck, there are probably changes also to the builder and the build process, and also producing AArch64 code in DDE, or maybe adapt the builder to build with GCC?

Yes surely the 64bit part is less than writing a hal.

According to your own architecture, this doesn’t seems to be the case to me. But if you meant to use an Emulator, then just say it ;) – Yes with an Emulator none of the above is required and the builder can stay as it is now.

It just sets up the environment (memory, interrupt handler) and then everything is done in 32 bit user mode.

That doesn’t sounds like it’s going to work IMHO, so how IRQs are going to be handled? And by what exactly? How the SWis are going to be handled? What about old code and old modules?

The 64 bit code probably has to handle OS_Memory calls, OS_ModifyRegister calls, bounce all other swis and pass on interrupts.

And how will it return pointers to memory allocated? You seems to have implied no pointers previously.

How are you envisioning to pass on IRQs? And which changes do you envision have to be made on the 32 bit kernel to deal with the “pass on” abstract concept?

To those who deal with hals and kernel code and linux solutions this probably illustrates I don’t know what I’m talking about but it’s fun thinking about it.

Linux runs as a full 64 bit OS, not splitted 64/32 kernels. So, not sure what you mean here. Yes I understand it may be fun, and that is all well and good, but makeing it happen won’t be fun, I can assure you this ;)

Of course you’re entitled to your own opinion, all I have asked is wait and figure out if it is practical or impractical.

Why do you think that anything else but an open discussion would be better to judge whether ideas are practical or impractical?

I can see a lot of ideas here and elsewhere that might basically work more-or-less, some better for specific cases, some better suited for the future (e.g. cores that can no longer execute any 32bit code). I think it is eminently sensible to throw around a few ideas before sitting down and starting to code.

I am really glad that Adrian Lees did not discuss his plans for Aemulor with someone like you, you might have convinced him that what he wanted to do is virtually impossible.

On top of that there is the usual “Oh just put a pinch of salt, a sprinkle of onions and a couple of slices of bacon” and it will take great, kind of approach which has never worked, after 30 years we still do not have the basics a decent OS should have.

We have an OS that is built exactly on that: pinches of salt and sprinkles of onions. Hacking the MOS into a 32bit OS that even pretends to multitask. I really have no idea why “we” (as in “the users and coders of RISC OS”) should suddenly start insisting on the idea to write the one OS to rule them all, the one OS that is secure and fast and reliable and all that (and providing full backwards compatibility of course!), when for the last 35 years we didn’t even start to have such a thing.

Actually, I feel the same as Druck: that section

I understand everyone wants to sound knoledgable and all of that, but I’d suggest people go to model some code before attempting to throw theories, considering that everything has to work, the system needs to be stable and there are, well, 30 years of stuff made in all sorts of ways.

is really incredibly insulting (“want to sound knowledgeable” – this is usually what I think when I read your posts on some subjects) to all people taking part in this discussion. Especially because you try to ascribe motives like “the new system must be stable and still 100% compatible” – we have not even agreed on a common set of objectives. Because why would anyone like to do that – most people just like to do a bit of tinkering and having fun, as you yourself keep pointing out.

might have convinced him that what he wanted to do is virtually impossible.

Some people might take that as a challenge.
Impossible? Hold my beer.

Agreed on all the other points. :/

I think you are over complicating my idea. All the cpu vector entry points are into a 64bit environment. Riscos has 32bit vector entry points. So the cpu starts up in 64 bit mode sets up memory and calls the 32 bit hal. Exceptions go to the 64 bit environment and are passed through to 32 bit entry points. So the 64bit environment is calling 32bit entrypoints in the riscos rom – surely it is possible for the supervisor level do this.

When a swi is called in 32 bit the swi vector is in 64bit svc and that calls the riscos swi vector.

The only need to access 64 bit svc is to modify device registers which could be done by swis. I suggested that memory would be created in 64bit mode because any 64 bit code had to exist in some basic environment whether it needs to be done there or whether it could be done from 32 bit mode with register access I don’t know.

is really incredibly insulting (“want to sound knowledgeable” – this is usually what I think when I read your posts on some subjects) to all people taking part in this discussion.

Well in which case I leave you, not my goal to sound insulting.

I’m afraid I don’t see much point in expending a huge amount of effort in finding some way for RISC OS to run on a Pi5. More than likely, before it is finished there will be a PiX (X > 5) which is 64-bit only. Better to concentrate the limited developer time available in developing something that will run on a Pi5 and future 64-bit only successors.

I noticed some objections to the notion that a “new” RISC OS needs to be stable and 100% compatible. The problem with RISC OS is that there is little development going on with existing applications — for instance the only “office” type program still in active development appears to be TextEase. This makes compatibility much more important than for other OSs. And surely any operating system needs to be stable?

I think there are many assumptions and mucking with PSR that might cause problems.

If we ask really nicely, somebody might throw a quick patch into the sources to switch the SWI vector down to USR mode ¹ and make a ROM of it, just to see how far it gets before imploding.

¹ I originally thought SYS mode, but that’s privileged, so mucking with the mode bits would still work. Not so in user mode.

And lose the privileges to memory mapped registers and any other memory that is svc mode only.

There was progress on the RPCEmu front, see https://www.riscosopen.org/forum/forums/10/topics/17579 for something that does actually work right now on existing AArch64 (and other) platforms. Not the fastest, but working. And probably a lot better when some JIT magic is applied.

So basically the Pi 5 is the perfect platform to validate 64 bit RISC OS – ain’t that great…

Colin wrote:

I think you are over complicating my idea. All the cpu vector entry points are into a 64bit environment. Riscos has 32bit vector entry points. So the cpu starts up in 64 bit mode sets up memory and calls the 32 bit hal. Exceptions go to the 64 bit environment and are passed through to 32 bit entry points. So the 64bit environment is calling 32bit entrypoints in the riscos rom – surely it is possible for the supervisor level do this.

If Acorn were releasing an A-76 based machine today, that’s exactly how RISC OS 5.5 would work, (just as RISC OS 3.5 did for ARMs which started in 32 rather than 26 bit mode). The big question is what they would do a couple of years later for an A-78 machine with no 32 bit mode whatsoever. Cashing in their ARM shares and running for the hills isn’t and acceptable answer, even though it is now possible again!

Good grief, it wants a five amp power supply…

“Power management receives an upgrade with the Renesas DA9091 power management IC, capable of supplying up to 20A to the BCM2712 for high-performance processing.”

“Does Raspberry Pi 5 need active cooling?
Raspberry Pi 5 is faster and more powerful than prior-generation Raspberry Pis, and like most general-purpose computers, it will perform best with active cooling.”

It is a long way from a low power processor running a light weight operating system.