os_stack/readme at main · nikonov1101/os_stack · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
memory map so far:

0x100000: kernel32 (not yet)
0x0a0000: lomem end @ 640k
0x09fc00: extended bios data area @ 1k
0x09c000: early stack
.........
0x008000: early32
0x007e00: boot1
0x007c00: boot0 @ 31k
0x007000: early32 scratch ram end
0x006000: early32 scratch ram start
.........
0x000c00: e820 maps @ up to boot0
0x000600: handover tables @ 1.5k
0x000000: bios reserved @ 1.5k


---------------------------------------


from https://www.kernel.org/doc/Documentation/x86/boot.rst

At entry, the CPU must be in 32-bit protected mode with paging
disabled; a GDT must be loaded with the descriptors for selectors
__BOOT_CS(0x10) and __BOOT_DS(0x18); both descriptors must be 4G flat
segment; __BOOT_CS must have execute/read permission, and __BOOT_DS
must have read/write permission; CS must be __BOOT_CS and DS, ES, SS
must be __BOOT_DS; interrupt must be disabled; %esi must hold the base
address of the struct boot_params; %ebp, %edi and %ebx must be zero.

looks like a good start conditions for your own kernel.

UPD: what i does not understant at this point
how to load (relocate??) the kernel at the __BOOT_CS?

if the desired environemt is as described above, what we have to do is:

1. load kernel into the lowmem:
    let assume the bootloader knowns how to find a kernel
    OR as it is done for in linux, let's allocate a "data exchange" page
    at the beginning of the kernel.

2. ok at this point we know the physical address of the kernel,
   and probably the entrypoint offset (via the data-exchange page as described above)

3. how we can set-up the GDT having that info?
   we need 4 segments:
     1. kernel code
     2. kernel data + stack
     3. userspace code
     4. userspave data + stack

how about loading a kernel right into the highmem?

since 386, we can access 32 bit address from real mode.
what if we load the kernel right there?
just waiste of the whole LOWMEM, but who cares, since it's fun enough.


---------------------------------------------------------


next steps:

* understand the protected mode memory model
  * segments vs pages?
  * we can't turn it off, so implement bare minimum:
    4 pages: 2 for kernel's code and data,
    and 2 more for userspace.
  * the above config effectively enforces flat memory model;

  * s2b: set 32 or even 64 bit mode?
  * s2b: must set up GDT and paging
  * s2b: load kernel into kernel code segment from above?
  * jump to kernel's main
  * kernel: set 32 or even 64 bit mode?


* find out where the kernel image is located;
* load the kernel image into memory (requires basic disk I/O);
* enable protected mode;
* preparing the runtime environment for the kernel (e.g. setting up stack space);
    - store memory maps on a pre-defined location
* jump to the kernel entrypoint (e.g. kmain() );

---

reading

https://stanislavs.org/helppc/int_table.html

https://www.cs.uaf.edu/2017/fall/cs301/reference/x86_64.html