Raspberry Pi 3B+

Bq. Is it considered a microkernel or a monolithic?

Such terms cannot be easly applied to RISC OS as there is no user/kernel security boundary in RISC OS. By standard terminology all the modules are part of the kernel, and arguably all the applications as well. This, combined the filesystems and device drivers run in the same thread as the caller, means RISC OS is a modular monolithic kernel design.

The RISC OS Kernel source is in apache/RiscOS/Sources/kernel and includes some graphics rendering, the command line interpreter and memory management. It does not include task switching and scheduling (which is considered a kernel task in microkernels) nor filesystems.

and arguably all the applications as well.

Applications normally run with a lower level of privilege than kernel/modules; although this may not mean much when just about anybody can scribble into OS workspace and if not, the OS is quite happy to bump any old user mode code up to supervisor level with One Simple Trick…
[though don’t try this within BASIC, as BASIC doesn’t like it]

As for the kernel type, I’d say monolithic is the closest match, but as you’ll see, it’s a kind of an interesting hybrid that doesn’t neatly fit into a specific category.

It does not include task switching and scheduling

RISC OS is a single user single process system (you’ll easily spot the single global graphics context…) with a multitasking desktop environment bolted on. The entire desktop world is magical smoke and mirrors to convince an application that it is the only application running, mapped at address &8000, and to manage to do this for dozens of applications. It’s quite clever how it was made to work, but as has been said above, the kernel only knows of a single process. The task switching magic happens elsewhere.
[though to confound things, the task memory mapping is handled by the kernel – AMB means Application Memory Block (or something like that)]

One image I saw represented the kernel as a large center circle, with the modules as smaller circles surrounding it, connected by lines (spokes?). Thus, if that representation were accurate, what does JUST that central kernel actually do, assuming no other modules were connected/activated/enabled?

The RISC OS 5 kernel has the following responsibilities:

• Managing the CPU’s cache and MMU page tables (it has builtin drivers for all the supported CPUs)
• Managing memory mapping & memory allocation, on both a coarse-grain basis (pages & dynamic areas) and fine-grain basis (OS_Heap)
• Managing the module list (starting, stopping, etc.)
• Managing the processor vectors (SWI, interrupt, abort/exception, etc.) – routing the events to the right software, or handling it itself in some cases (e.g. default abort handlers which will kill the running program). However it doesn’t contain any drivers for interrupt controllers – that’s located in the HAL
• Facilitating communication between modules and programs via a few different mechanisms (vectors, service calls, SWI instructions, system()/terminal commands, etc.).
• Managing the environment variables (“system variables” in RISC OS terminology)
• Managing the system timers (100Hz monotonic timer & real time clock; however communication with the RTC hardware is delegated to the RTC module)
• Managing transfers on the IIC buses (using hardware drivers in the HAL)
• Managing the system configuration that’s stored in NVRAM/CMOS RAM (relying on a kernel-external hardware driver to do the talking to the hardware)
• Managing the framebuffer/VDU
  • Talking to the hardware driver to e.g. program video modes
  • Managing the mouse cursor (cursor image and position, receiving position updates from the mouse driver module)
  • Simple bitmap font rendering (only bitmap framebuffers are supported). “Proper” fonts are handled by a separate module (the font manager)
  • Graphics drawing primitives – lines, triangles, rectangles, circles, etc.
  • Basic support for sprite plotting (essentially bit-blit support – not translation between pixel formats / colour depths. The more complex cases are handled by the SpriteExtend module)
• Lots of other ancillary things
  • Most of the OS_Byte & OS_Word APIs (scatter-brained APIs inherited from the BBC Micro)
  • Managing the keyboard buffer & key press state (receiving key up/down events from the keyboard driver module)
  • SWIs for calculating CRCs, converting numbers to strings, etc. (basically, almost all of the OS SWIs)

In my opinion the first four and a half are what the kernel should be doing, while the rest is starting to stray into monolithic kernel bloat territory.

If you were to boot a ROM containing just the HAL + kernel, it would in theory drop you at a terminal prompt (assuming you have some way of seeing it – e..g. video driver in the HAL, or a build with the serial debug enabled). But since the kernel is reliant on external modules for a lot of things, it’s hard to say how much will work.

I looked at the FreeBSD Raspberry Pi port and it appears to be both 64-bit as well as SMP. If making the RISC OS kernel the same (64-bit/SMP) is such an arduous/impossible/expensive task, why not just use the FreeBSD one and modify it to function with the rest of RISC OS? Or are the two kernels so radically different, you might as well ask a monkey to install a 747 jet engine into a VW bug? :-D

Or are the two kernels so radically different, you might as well ask a monkey to install a 747 jet engine into a VW bug? :-D

Among other things.

Have a look at the source code. When you get over the mixture of C, assembler and other and realise that the order that I gave isn’t representing the relative quantities you might see the nature of one aspect of the task you describe. Then start digging in to how things inter-relate you will see what Jeffrey was talking about.

Most of all – RISC OS is not a flavour of Linux. It isn’t even a distant relative.
That’s probably the aspect most people round here like – what it isn’t.

But, would it be possible to take what is known (the 64-bit/SMP aspects of FreeBSD) and convert them to the code format (Assembly language) of RISC OS, replacing the non-64-bit/SMP part(s) of the kernel? License-wise, it shouldn’t be an issue, but does anybody know how to “translate” from one into the other? I’m only thinking of how to simplify the “upgrade process” by taking what others have already done and simply adapt it to RISC OS. I did not intent to sound like I was wanting RISC OS to be “mangled” such as I might have made it sound. :-(

But, would it be possible to take what is known

No, not really. Converting the older 26 bit code to 32 bit was a pain but it was possible because the two were essentially similar. Instead of PC+PSR, they were separate so code needed to be modified not to touch PC (in other words, don’t push bit 28 to set V flag, etc).

ARM 32 to ARM 64 is nothing like that. The two are quite different, and I liken doing a conversion to porting RISC OS to MIPS, not out of hyperbole but in order to demonstrate exactly how different the two are.

With our limited developer resources, the best way to run RISC OS on 64 bit is probably going to be emulation. Anything else is…….

Rick – Limited Developer Resources (LDR)… is that in actual manpower (people who know how to do it or number of said individuals) or financial? If we have the people but not the finances, that’s a problem. But if you simply don’t HAVE the people, that’s a worse problem.

At the recent show, Andrew from ROD was saying something to the effect of “we have funding to build a new browser but we can’t find anyone to do the work”. I’d imagine that finding kernel developers would also be tricky, if not more so.

AIUI There are people who have RISC OS experience and the necessary skills to do big project development of the OS and apps but finding someone who ‘currently’ has the time is a problem. Someone who hasn’t RISC OS experience but does have the necessary skills could be found but finding them is no easy quick task and they would cost more due the extra time required to learn how RISC OS works.

n.b. One active RISC OS developer told me a while back that he was keeping an eye on a particular bounty and when the amount got to a particular figure he would claim it, if other work permitted.

Hi Chris, Which bounty was that and what was the figure? Knowing the first fact at least might give that bounty a boost – especially during this period where ROOL are matching any contributions made. ..

Echo-ing what mikko just posted, if people are thinking about a bounty, they should drop us a line at RISC OS Developments. We have plans for development of the OS, and want to work with people to further it. Availability of willing/able programmers is our number one problem, so if anyone would like to do application or lower level development work, please talk to us.

“Hi Chris, Which bounty was that and what was the figure?”
That would be up to the developer to say. Telling ROOL/ROD would be the best way I’d have thought. Maybe they did?

If someone who ROOL/ROD took seriously made such an offer then they could publicise it and as you say I’m sure it would get a boost.

IIRC it was a bounty that has since been claimed, I don’t know if it was by the developer I was talking to over a year ago.

A little over 1 yr. later…

If someone were to be crazy enough to even attempt what I have mentioned, where would you start, in the source code tree? I’ve downloaded the Source Code tree for Raspberry Pi. And I definitely want to get as “fast and tight” as possible, so I’d like to keep everything written in Assembly Language, if possible. So (I assume) I’d start in the path: BCM2835 > RiscOS > Sources > Kernel > s

If you wanted to start at the lowest level. The very beginning of the boot sequence and the most basic aspects of the kernel itself… is that where you would start? Does that specific directory have the files necessary for that?

Does any of this help?

https://www.riscosopen.org/wiki/documentation/show/Developer%20documentation

If you wanted to start at the lowest level. The very beginning of the boot sequence and the most basic aspects of the kernel itself… is that where you would start? Does that specific directory have the files necessary for that?

Yes, that’s the right place for the kernel sources. Kernel startup starts with the RISCOS_Start routine in s.HAL.

However note that RISCOS_Start is called from the HAL (RiscOS.Sources.HAL.BCM2835, execution starts in s.Top). So if you’re going for 64bit support you’ll also need to modify/replace the HAL.

The way I’d start with this is to strip the kernel down to the bare minimum (i.e. the first four/five things from my earlier post), moving all of the other functionality into one or more modules. Then you can replace the stripped-down kernel with a 64bit, SMP-capable version with minimal effort. Then once that’s working correctly (with the rest of the OS running in 32bit mode on a single core) you can start updating the rest of the OS, one module at a time.

Wow.. I need to ask which compiler that could work with 64bit.. I mean when binary is supposed to cooperate with the rest of riscos?

Wow.. I need to ask which compiler that could work with 64bit.. I mean when binary is supposed to cooperate with the rest of riscos?But I guess you can have a -BIN binary that loads rest of OS after switching to 32bit. There are problems , like how to deal with SWI’s.