[okl4-developer] newbie guide (was: no subject)

[Carl van Schaik]

Hi Jorge,

Thanks for the great work you have done on this, it will certainly 
become a useful document!
Some minor comments are inline below.

regards,
Carl

Jorge Torres wrote:
> Hi okl4.org <http://okl4.org>,
>
> I'm writing this OKL4 newbie guide, and I thought interesting 
> describing from switch on to wombat init process, here is what I have, 
> but I might be wrong or incomplete, so please if any of you have the 
> time to correct me if I'm wrong, I'll be very happy to receive some 
> feedback:
>
>
> Boot-Loader
> ---------------
> As almost allways for operating systems, there must be an specific 
> boot sequence, un-
> derstood as the set of operations performed to load an operating 
> system after computer's
> switch on, since most computers can only execute code stored on 
> system's ROM
> or RAM, and computer's hardware alone cannot load a program from a 
> disk or other
> removable media, therefore a sort of operating system itself might be 
> needed to load
> another much more complex operating system, such process was called 
> bootstrapping,
> out of the legend of a man flying by pulling himself up from his own 
> bootstraps. As so,
> a very small program or set of programs called bootstrap-loader or 
> bootloader is used
> to load into memory the necessary software for an operative system to 
> start, OKL4 is
> no exemption; it all starts with a bootloader, which is on user hands 
> to chose, in this
> specific case the GRUB bootloader. Whatever the chosen may be, must 
> boot the L4
> kernel image image.elf built by the SCons Build system. More 
> information about this
> can be found at the tools/doc directory.
>
> L4 u-kernel
> ---------------
> Inside code; kernel's entry point is architecture dependent. 
> Generally, one may think at
> first; main() function to be the first function to receive control, 
> just as in applications,
> but the real entry function is called _start(), which commonly sets up 
> the environment,
> opens descriptors, and then invokes that main() we all know. So kernel 
> has to define its
> _start function, since Boot loader expects from first loaded file a 
> declaration of it.
The entry point is typically located in the "start address" field of the 
ELF file kernel image, or a hardcoded address when not using an 
ELF/equivalent compatible bootloader.
>
> • L4's u-kernel _start is defined at assembly code file (for ia32 pc99):
> pistachio/platform/pc99/src/startup.spp
> where paging is set up, and then a jump to what the top-level main in 
> this case
> will be: the startup_system function.
>
> • Architecture dependent startup_system() function located at:
> pistachio/arch/ia32/src/init.cc:
> Where spaceids, kernel space, KIP, IRQ Hardware, global_timing, Global 
> De-
> scriptor table, processor(s), timer, and scheduler are initialized.
you are missing exception/irq handling support is initialised?
>
> • Timer initialization is done by first calling 
> get_timer()->init_global() method,
> which assigns IRQ time tick interrupt to the timer_interrupt function, 
> both found
> on file pistachio/arch/ia32/src/timer.cc, therefore if a time tick 
> interrupt occurs, timer_interrupt ACKs and then triggers
> the scheduler's handle_timer_interrupt method.
> pistachio/src/schedule.cc.
>
> • (startup_scheduler) function located at:
> pistachio/src/init.cc
> Allocates Kernel's stacks, initializes the scheduler, which 
> initializes the priorities
> queue, then idle_thread is created, after that scheduler is started 
> where idle_thread
> is scheduled and switched to, finally an infinite loop starts to 
> prevent termination
> of kernel execution.
The idle thread has had some startup code "notified" and its 
continuation points to the further init code
>
> • (root_task); at startup_scheduler init_all_threads is called, where 
> interrupt threads,
> kernel threads and root server thread are initialized. Root server or 
> root task runs
> in the root address space, giving it special access rights. It is 
> initialized with the
> init_root_servers() found at:
> pistachio/src/thread.cc
> There is a root_server structure on the kernel interface page class, 
> holding in-
> formation about root_task instruction pointer, stack pointer and 
> memory region
> occupied by the server, this addresses are set by elfweaver. Last on 
> initializa-
> tion; kernel jumps to the idle_thread that will also be executed 
> whenever no other
> threads are active, and whose job is to search for some thread ready 
> to run, so
> root_task is the first found by idle and a context switch is performed 
> to it.
The roottask thread is created, and its initial address space is mapped  
from the info in the KIP memory-descriptors, which are provided by the 
build system.

The idle thread runs the scheduler, which picks the first user thread 
(roottask) to run.
>
>
> Iguana
> ---------
> If iguana is specified as the project to the build system, then iguana 
> server is set to be
> µ-kernel's root task.
>
> • (main), located at iguana/server/src/main.c Initializes iguana by 
> initializing  UTCB areas and sizes (utcb_init()), then spaces are 
> initialized, and it creates a protection domain with itself as a 
> parent (init_pd()), threads parameters
> are initialized, and finally before entering into its loop state; 
> based on boot infor-
> mation server threads are created as well as iguana tasks 
> (bi_execute()), servers
> and applications are specified at the iguana's SConstruct file on
> projects/iguana/SConstruct essentially servers are: naming which 
> provides a sim-
> ple shared namespace, timer which as its name suggests is a timer 
> server for
> Iguana, and serial server. This three are not optionally loaded by the 
> build system,
> once project is set to Iguana they are automaticly added to the 
> Applications.
>
> • (examples) Optionally there are two examples which can be specified 
> as argu-
> ments to the build system, they are located at 
> iguana/examples/<example>. they
> will help allot on iguana basic service understanding.
>
> • (wombat) If wombat build system argument is set to true, then Wombat 
> Linux and
> bussybox are added as Iguana applications, note that examples and 
> wombat cant
(busybox)
> go at the same time, since its restricted by the build.py
>
> Wombat
> -------------
> Deciding if wombat will be part of the system image, it's on user
> hands, by simply sending the wombat=True argument to the build system, 
> if such thing
> happens, then Linux task is set for iguana.
>
> • (main) Linux entry point can be found at
> linux/kernel/arch/l4/kernel/main.c, where basicly a new thread is 
> created called
> the main_thread and labeled L_Syscall, which is in charge of starting 
> the Linux
> kernel almost just as its original _start entry point. The linux 
> initial thread labels
> it self as L_timer, who will be responsably of acting as Linux's ISR.
>
> • (L_timer) code can be found in interrupt_loop() function, located at
> linux/kernel/arch/l4/kernel/sys_iguana.c which initially is waked up 
> by the main_thread,
> then timer is initialized and enters to an infinite loop which handle 
> interrupts, for-
> ward them to the main_thread if necessary and signal linux scheduler 
> when timer
> interrupts occur.
ISRs run in the context of L_timer most of the time, unless they are 
defered (IRQ can when L_syscall has interrupts disabled, in which case, 
L_syscall will run the ISR when re-enabling interrupts).
>
> • (main_thread) code begins with the start_kernel function at
> linux/kernel/init/main.c, there from scheduler to signals, page 
> writebacks, and
> many others are initialized, and also, L_timer thread waked up, and 
> finally init
> thread with rest_init function where /sbin/init, /etc/init, bin/init, 
> /bin/sh init pro-
> cesses are runned with run_init_process() function. And as many say: 
> the rest is
> history!.
>
L_syscall eventually gets to syscall_loop(), which switches to 
Linux-user threads, and receives events back from then (pagefaults, 
exceptions, syscalls etc). Also L_timer calls L_syscall - which it 
detected in the syscall_loop to enable pre-emption of user-threads.
>
>
> Thank you,
>
> Jorge
> ------------------------------------------------------------------------
>
> _______________________________________________
> Developer mailing list
> Developer at okl4.org
> https://lists.okl4.org/mailman/listinfo/developer
>