RISC OS on hypervisor

yup Jeffrey is correct.

So when you isolate the core from Linux Kernel it shouldn’t use the core (IIRC it won’t use it at all), so the core coprocessor registers won’t be set hence you get your “different MMU per core”.

Cache coherency should also be ok, MMUs on ARMv7a/v8a are before cache, RPi doesn’t use Cache Coherent Interconnect (obviously) and again excluded CPUs won’t be considered by Linux and RISC OS only uses one.

The other potential issue that needs to be understood is the GIC module, partially because it’s separated from the cores, so in this case it’s a shared resource. Each core can handle IRQs, but the GIC module deals with them and then (via distributor) send them to each core.

Now one hypothesis is but assigning the physical NIC and WiFi to Linux, and not to RISC OS, it should be safe ‘cause it’s not shared. Then assigning everything else to RISC OS (in linux we could blacklist all drivers for what we do not want it to use for example) and in RISC OS just avoid loading the NIC drivers should be enough.

Now 100% this will work thought, need to test it, so I am guessing.

@ Michael

You can pm me on twitter.

Ermmm cool… now I need to create a Twitter account loooool :D

Will do later, sorry busy day for me between work and today is first ARM DevSummit day!!! :)

Oh and before anyone asks something like:

Wait if Linux gets’ the physical NIC and WiFi then RISC OS will have no network access

The virtual NIC between RISC OS and Linux can also be used for traffic forwarding (a bit has it happens in RPCEmu), so RISC OS will have network access.

Firefox, OpenOffice etc. executed on Linux will use more cores and real threading which means it’ll be faster than running it on RISC OS, however it will appear in RISC OS and will look a bit like the GCCSDK ported applications.

Also it should be possible to configure tools like vpnc on the linux side to allow RISC OS to finally have VPN access, so you could finally use it to work connected to your company VPN.

I am almost thinking to try this on my ARMBook and finally have pure Apple lifestyle on RISC OS :)))…. oh wait covid is out there so no working from the coffee shop ala San Francisco Apple style…

I handle gic .. simply not initiate it in the other system ( just add it as a device) and set affinity from risc os. BTW, the reason why I selected netbsd over Linux is two things. The kernel is much easier to limit and the license,

and the license

:)

Why oh why isn’t there a pm function on this forum?!

Because this forum was intended as an example of a (barely) functional forum written in a trendy new language in the minimum of code.

As you noticed – changing your email address spawned a new account. It seems you now have two Michael Grunditz accounts. I suppose we ought to be glad that it didn’t just orphan all your old posts. ;-)

if you look at the requirements for starting Linux, irq and mmu off.

Isn’t that pretty much how U-Boot hands over to the OS kernel? It’s the kernel’s responsibility to set up handlers and how the logical memory is arranged, so anything else doing that beforehand will lead to things going wrong.

Is it really possible to have different mmu maps for each core?

Why not? If they are capable of each having a different view of the available memory, it stands to reason that the MMU setup would be different for each core.

Most of the other coprocessor registers are core-local too.

By that, you mean things like VFP and NEON?

oh wait covid is out there so no working from the coffee shop ala San Francisco Apple style…

Overpriced stuff with fake Italian sounding words.

Better just to make your own coffee ¹ the way you like it, and sit somewhere peacefully. You’ll be so much more productive than those avocado-juice-and-shia-butter-mocha-latte-with-a-hint-of-aloe swilling hipsters ever could be.

¹ Tea, in my case. Just a teabag, in a mug, hot water, some sugar, and a little milk. Absolutely no bull.

So to sum it up a bit..

• RISC OS needs to binary patch linux/bsd dtb with ram start size etc
• In case of BSD , the dtb is passed in X1 assuming aarch64 is used, So some clever play with the image and a small start program is necessary.
• In case of Linux , the dtb can be at the end of kernel imgage ( is this still supported?) and we probably need atag support (dead simple to do)
• For both systems RAM needs to be allocated , PCIRam_alloc is a hot candidate.
• GIC has to be configured to set aside affinity to bsd/linux cpu. The bsd/linux gic code has to be limited.

The old linux boot apps and tools like softload is of little use. I did a attempt of starting linux on the ARMX6, something like on Titanium . It worked got console , but USB didn’t get power,, so gave up.

Online in ChatCube!

Will RISC OS move to use to the ARM Server Base Boot Requirement Specification(SBBR) when moving to 64-bit? And will it make porting to hardware, once done far easier?

I’m not a low level guy so don’t fully understand, but it seems that many ARM Workstation vendors say they will support any OS that meets the SBBR specification.

Tea, in my case. Just a teabag, in a mug, hot water, some sugar, and a little milk. Absolutely no bull.

Some sugar? I’ve seen that headless chai making video!
That’s like “some” property damage in Hiroshima

That was barely anything.

When I get headaches and feel grumpy, a couple ¹ of sugar cubes fixes that.
Well, the headaches at least…

¹ Conservative estimate – it’s a surprise that my blood sugar isn’t off the chart. Apparently it’s “within range” the last time it was checked. Go figure.

it’s a surprise that my blood sugar isn’t off the chart.

In my student days the local sit-in pizza place had bowls of sugar cubes. There were always three empty bowls (adjacent tables) when we (well I) left.
I never had sugar in tea or coffee, or in anything to speak of.

@ Michael

Online in ChatCube!

If more people are interested we can also create a chatroom to work together in ChatCube.

RISC OS needs to binary patch linux/bsd dtb with ram start size etc

correct, but we could also have a look at dtc tool and maybe use GCCSDK (on linux to either rebuild it for RISC OS or use it to generate pre configured dtb), if I understand you correctly.

dtc -i dtb -o dts blah blah

should give us back the source, so I am not sure if we need the binary patch…

In case of BSD , the dtb is passed in X1 assuming aarch64 is used, So some clever play with the image and a small start program is necessary.

so in AArch64 we should use X0 as the physical address of the dtb, but need to verify this.

Other things required are (obviously):
- “rest” state for all DMA capable devices
- MMU off (using a non RISC OS used core this should be the case anyway)
- all types of interrupts (IRQ, FIQ, debug, serror) should be masked
- CPU should be in EL2 state or EL1 (so depending on how we start code execution on the target core we may need to ERET or increase the EL depending on the “start up” code)

…and there are a bunch other requirements that I do not remember right now, but I am 100% sure they are publicly documented somewhere

In case of Linux , the dtb can be at the end of kernel imgage ( is this still supported?) and we probably need atag support (dead simple to do)

AFAIR $fdt_addr (or $ftdaddr) is always higher than $loadaddr, so yes still supported I think. AFAIK tdb and atag are mutually exclusive, so I don’t think we need atag if we use dtb.

GIC has to be configured to set aside affinity to bsd/linux cpu. The bsd/linux gic code has to be limited.

Agreed.

Quick note: here it’s 3:50am now and I am dead tired, so apologies for any crazy answers I may have given above…

I find this forum to be made for misunderstandings. So not going to reply more in this thread.

That’s a pity – I for one was finding this very interesting.

One of the things that was discussed was an X Server for RISC OS – I know there was a commercial offering around in 90s, but was unaware of anything since. Is there anything?

@ David Thorn

One of the things that was discussed was an X Server for RISC OS – I know there was a commercial offering around in 90s, but was unaware of anything since. Is there anything?

I am not aware of the latest and greatest, however I do have an X11 Server for RISC OS (26bit) that works on Archimedes and should work too on RiscPC. Beyond that I am not aware of any new or 32bit versions.

I wouldn’t want to use a RISC OS X11 server to access other virtualized OS’s, as they all use hardware video acceleration, and that’s not going to work on RISC OS. It makes far more sense of the other OS’s to display RISC OS’s simple framebuffer.

One of the things that was discussed was an X Server for RISC OS – I know there was a commercial offering around in 90s, but was unaware of anything since. Is there anything?

The thing you probably remember was the Gnome X Server, imaginatively called “!X”. Commercial offering, very expensive at first, later a bit cheaper around 200 UKP. See here for the archived Gnome site: https://web.archive.org/web/20050205211842fw_/http://gnome.co.uk/flyx.html

Then, there was Vincent Sanders’ experimental X Server. Probably around 2000. Ah yes, found it via Google: http://www.kyllikki.org/software/x/

The most mature free X Server effort was Leo White’s RiscX, but I think that was also 26bit only. Accompanied by RiscXLib, which basically allowed compiling native XWindow-based applications for RISC OS which then used RiscX as a display server. http://www.mybigideas.co.uk/html/software.php

Other than that…no idea. I think there was an effort by Peter Naulls to accompany ChoX11, but I don’t remember the details.

I did a basic port of an X11 server called ‘RiscX’ back in 2000. Worked well enough to run Firefox etc.but I don’t seem to have kept any screen shots!

Binary is available at http://mybigideas.co.uk/html/software.php and might still run on a 26bit platform….

For a while I did consider turning it into a commercial project, but just didn’t think there was enough of a market to justify it, even if the Bank Manager seemed positive!

Less time got spent on it once I got a full time job, then there was an update to GCC and it stopped cross compiling for some confusing reason and development kinda halted.

In theory I still have the sources, but I’d need to remember how to use SVN to get at them…

@Leo

In theory I still have the sources, but I’d need to remember how to use SVN to get at them…

maybe I am misunderstanding this but what about `svn checkout` ? And SVN is still available and up-to-date for RISC OS 5 in RiscPkg, you should find it in Packman.

@Paolo

That would probably work! Its just I’ve not used SVN since then, so a bit rusty on the commands.

Its on a Linux machine, as that’s what I was using to cross compile on, but no longer have SVN installed!

Hmm, having installed that the SVN repo contains my other software, but not the RiscX sources… Will have to have a hunt around and see if I can find a copy anywhere.

@Leo

cool! And good luck seeking for the sources

If I can be of any help (with my very restricted time availability) to bring !RiscX to RISC OS 5 please let me know, I would definitely want to use it on RISC OS 5!

@Paolo

I’ve found a copy of the source on another machine, complete with CVS history.
Starting to think I wasn’t cross compiling as much as I thought, as its mostly made up of modules…

Will try and have a look this weekend at getting the sources building again. Might also go check the Iyonix to see if it has a copy as well.

@Leo

I’ve found a copy of the source on another machine, complete with CVS history.

fantastic! :)

Will try and have a look this weekend at getting the sources building again. Might also go check the Iyonix to see if it has a copy as well.

you are amazing! Thanks a lot.