build error with branch Multithreading

[janrinze]

./build
Building with RiscOS build RiscOS/Images/rURZ00-00,fe5
./build: line 130: cd: RiscOS/CKernel/: No such file or directory
arm-linux-gnueabi-gcc-8: error: Modules/*.o: No such file or directory

clearly the directory RiscOS/CKernel/ does not exist.

[Simon-Willcocks]

There's a new file Legacy/RO.patch which you should be able to use to make them.

cd to RiscOS/ and run

patch -fNp1 < ../Legacy/RO.patch

If there isn't a whole RiscOS tree, it should still create some files in CKernel. The -f flag skips all the missing files etc. (It's also a bit dangerous.) You can also run the same command in any clean directory and copy the CKernel directory across.

The output files are not typed:

mv CKernel/Balls2022{,\,ffb}
mv CKernel/\!Boot{,\,feb}
mv CKernel/Hello{,\,ffb}
mv CKernel/RAMFS{,\,ffa}

(RAMFS is the C version of RAMFS, built on RISC OS, but it needs more Dynamic Area functionality than I've implemented.)

Hope this helps.

The plan is that the HAL will be a simple module which will register !Boot in Resources:$, which the kernel will run. It can be any type of program, but it will usually load modules appropriate to the hardware, possibly passing in the addresses that device drivers should be expecting their hardware to be.

[janrinze]

I managed to get it to run.
When running on qemu it appears that depending on which cpu finishes last (should be cpu0) it continues with rendering the balls and the desktop.
Apparently this is more of a random luck game at the moment.
What do you do to synchronize the cpu's?

[Simon-Willcocks]

At the moment, I'm compiling with

./build -DSINGLE_CORE -DDEBUG__VERY_SLOW_TICKS -DDEBUG_SLOW_TICKS

To avoid thinking about that sort of thing! (The TICKS defines are so qemu doesn't get overwhelmed by millisecond ticks when tracing or simply running on an old PC.)

I treat the cores as equals, first come, first served. What I'm after is having tasks communicate using (a new) OS_PipeOp which blocks tasks until the pipe has enough space or data in it for the task to write to or read from. Wimp programs will either be traditional, or have tasks/threads that continue to run while the main task is in a Wimp_Poll.

Maybe I should declare a read-only code variable that returns the current core, or something like that, so the boot sequence can pick a core to start the Desktop, or we could modify the Wimp to ensure it's only started once...

[janrinze]

It clearly only runs if cpu0 finishes last.
Thus it might be useful to have some notification from the other cpus telling cpu0 that they have finished.
A simple way could be that they set a flag. Assuming that cpu0 can read that flag, once it has done its initialization. I don't know how cache coherency is maintained but the main idea is that writes should become visible to other cpus.

[Simon-Willcocks]

That sort of thing is in hand, honest! But in the meantime, I spent the last week or two understanding how RO expects applications to exit.

There are multiple synchronisation events during the pre-RO boot process.

The first code entered is _start, from ./boot/generic/boot.c.
At this point, the "ROM" is still writable, and the structure boot_data is pre-initialised to zero.
_start just allocates a little stack (per core), and calls locate_rom_and_enter_kernel.
Core 0 is special only for as short a time as possible. It initialises some flags, performs the relocation of the "ROM" code (if necessary) and releases the other cores to continue.
Until the MMU is enabled (at which point STREX instructions will work), the synchronisation mechanism is at_checkpoint/release_from_checkpoint/wait_for_cores_to_reach, which rely on non-MMU atomic writes to memory.
All cores jump to the new location of the "ROM", then core 0 reserves memory for shared and core-specific workspace, before letting the other cores continue.
Each core initialises its workspace, sets up the stack pointer to within it, and calls pre_mmu_with_stacks.

pre_mmu_with_stacks has core 0 being special for the last time (I think), as it releases each other core to call MMU_enter (which will call BOOT_finished_allocating when it's done using the non-thread safe code).

MMU_enter is in MMU/ARMv6/mmu.c, and it allocates memory for translation tables, calls BOOT_finished_allocating to release the next core, sets up the MMU (with the "ROM" mapped both at its physical address and starting at 0xfc000000), with some core-specific virtual memory areas and some shared between all cores. go_kernel starts running in high virtual memory, wipes the physical memory mapping from the translation tables and calls Kernel_start, in kernel.c.

In core 0's final special act in Kernel_start, tells the kernel about unused RAM from the minimum expected RAM. All cores set up the kernel's hardware vectors in high memory (0xffff8000, iirc), initialise a few more things, including the initial Dynamic Areas, and calls Boot (in modules.c).

Then we start trying to run RISC OS code!

Initialise_system_DAs has already allocated some core-specific memory pages expected by legacy code. (That should be made redundant, or moved.) Boot initialises legacy "Zero Page" memory for each core, and initialises most ROM modules in order, separately for each core. That may well be a mistake. It's needed for modules that have zero page allocations, but not for, say, device drivers which expect to be unique in a system (but will need protection from multiple cores or tasks making requests of them, when they're ignorant of multi-tasking/processing).

Boot starts by creating a TaskSlot for modules, with no (? maybe the memory manager should have some) application memory (0x8000-...). It initialises the HAL module, then the ROM modules, finally running Resources:!Boot.

TaskSlots are associated with physical memory located at 0x8000-, each one will have one or more Tasks associated with it. When a Task is scheduled, its TaskSlot is mapped into memory. (It's basically a process.)

The Currently Active Object (CAO) value associated with a RISC OS thread was 0x8000 for all applications. Now, it is the address/handle of the TaskSlot. This, I hope, will convince the Wimp to not try to do any memory management. Non-Wimp Tasks will be able to trigger the Wimp Task by setting the pollword.

[Simon-Willcocks]

memory_manager needs to be made less Dynamic Area specific, and more an arbiter of virtual memory areas, particularly the shared ones. Maybe.