fbos/kernel/head.S, branch main

Pass the hart ID on start_kernel instead

2024-12-04T16:23:57Z

Instead of storing the hard ID as given by the bootloader into a C variable, pass it directly into the 'start_kernel' function since we don't need to tamper the value as originally laid out on the 'a0' register. Signed-off-by: Miquel Sabaté Solà

Re-use the halting loop also for the main hart

2024-12-04T13:35:50Z

The halting in secondary harts should not be treated too differently as with the (unlikely) scenario that the main function quits. Hence, merge the code in both cases. Moreover, we do not really need to to initialize the values of most registers, as they will be explicitely set when needed anyways. Signed-off-by: Miquel Sabaté Solà

Run a hart lottery on SMP

2024-12-03T13:34:43Z

On systems with SMP multiple harts will try to run the kernel, and they will appear at random. But in this kernel, in order to keep things simple, we want to make sure that *only one* hart is running the show, as it greatly simplifies things on these kinds of systems. The solution is similar to what Linux does, which is to allow the first hart to initialize things, but then (and different to what Linux does), it will infinitely stall all the other harts that arrive at a random later point in time. In order to make this more apparent, I have also added a print message showing which hart is being used to run the whole thing. Signed-off-by: Miquel Sabaté Solà

Simplify how we fetch the load address

2024-12-03T06:47:56Z

Similarly to 58fcecc381be ("Simplify the constant on the size of the stack"), the base and offset load addresses where taken from the Linux kernel, which has to account for way more stuff than this poor kernel. Hence, let's be more explicit about the base address and the offset where the kernel will be located, so it's actually more clear both on the linker, and on the kernel's header. Signed-off-by: Miquel Sabaté Solà

Simplify the constant on the size of the stack

2024-12-03T06:41:45Z

At the beginning I carried over things from the Linux kernel just in case I would need them in the future. As this project is very much at a stage where I'm already happy with it, let's remove unneeded complexity. Signed-off-by: Miquel Sabaté Solà

Share the same stack everywhere

2024-12-02T20:02:35Z

As documented in the code, we are not implementing any kind of memory protection, so in theory any process (regardless if running in user or kernel space) would be able to tamper with other processes' stack. Hence, don't even pretend that we are separating stacks and share the same global stack everywhere. This simplifies things a bit. Signed-off-by: Miquel Sabaté Solà

Prepend the name of the task on debug

2024-12-02T19:47:19Z

On 'printk' and 'sys_write' calls, prepend the name of the task that is being executed for each message. This is an easy way to show off that we are doing the right thing with the 'tp' register, even if we don't do much with it. Signed-off-by: Miquel Sabaté Solà

Document what we mean by scheduling on this kernel

2024-11-30T22:42:08Z

The notion of 'scheduling' a process on this kernel is effectively the same as starting the process anew. This is pretty bananas for any general purpose kernel, but this is not our case. Signed-off-by: Miquel Sabaté Solà

Allow the kernel to run as a Linux image

2024-11-29T21:17:13Z

In order to run on real hardware, it's actually easier to re-use workflows from existing bootloaders than loading things in memory manually. In order to achieve this two things had to be settled: 1. The image has to have a Linux header as defined in the RISC-V port. This header will be taken into consideration by bootloaders in order to know where to jump, the image offset, the endianness of the image, etc. 2. The image cannot just be an ELF executable. Rather, we must translate it into binary form via `objcopy`. With all of this at hand, I was able to make the kernel run on a Starfive VisionFive 2 board, and I have recorded an example so it's available as documentation. Signed-off-by: Miquel Sabaté Solà

Enable the timer from the SBI interface

2024-11-22T14:46:59Z

A basic interrupt handler has been implemented which tracks the seconds that have been elapsing along the way. Depending on the value of these seconds, then a task has to be called. Signed-off-by: Miquel Sabaté Solà