Multiboot_kFreeBSD
差别
这里会显示出您选择的修订版和当前版本之间的差别。
| 两侧同时换到之前的修订记录 前一修订版 | |||
|
Multiboot_kFreeBSD [2024/10/23 06:39] whr Sync |
Multiboot_kFreeBSD [2024/10/23 09:34] (当前版本) whr Correct grammar issues |
||
|---|---|---|---|
| 行 209: | 行 209: | ||
| #4 0x00000000 in ?? () | #4 0x00000000 in ?? () | ||
| </file> | </file> | ||
| - | Although this backtrace didn't provide many useful information of where the issue occurred, by the fact that **panic(9)** has been called, indicating paging was activated, IDT and GDT has been setup; just before console finishes its initialization, the problem should sit in function ''init386'', between those code: | + | Although this backtrace didn't provide many useful information of where the issue occurred, by the fact that **panic(9)** has been called, indicating paging was activated, IDT and GDT has been setup; just before console finishes its initialization. The problem should be sitting in function ''init386'', between those code: |
| https://svnweb.freebsd.org/base/releng/10.3/sys/i386/i386/machdep.c?revision=296373&view=markup#l3367 | https://svnweb.freebsd.org/base/releng/10.3/sys/i386/i386/machdep.c?revision=296373&view=markup#l3367 | ||
| <file c i386/i386/machdep.c> | <file c i386/i386/machdep.c> | ||
| 行 324: | 行 324: | ||
| </file> | </file> | ||
| - | The kernel is now functional with Multiboot, achieve goal 2. | + | The kernel is now functional with Multiboot, achieving goal 2. |
| Following screenshots showing it booted up with QEMU direct kernel loading, but asking for root device due to kernel environment isn't available. | Following screenshots showing it booted up with QEMU direct kernel loading, but asking for root device due to kernel environment isn't available. | ||
| 行 338: | 行 338: | ||
| Those options that originally been interpreted by BTX loader should be turned into the kernel itself to parse; the result should be store to ''boothowto'' variable as well. This means filling ''boothowto'' from command line options should happens as early as possible; it is best to do that before any uses of ''boothowto''. | Those options that originally been interpreted by BTX loader should be turned into the kernel itself to parse; the result should be store to ''boothowto'' variable as well. This means filling ''boothowto'' from command line options should happens as early as possible; it is best to do that before any uses of ''boothowto''. | ||
| - | Another scheme the BTX loader passing information to kernel is **kernel environment**. Just like the environment for user-space programs, the kernel environment is built up by individual environment variables; while an environment variable is a C string with format ''<key>=<value>''. | + | Another scheme the BTX loader passing information to kernel is **kernel environment**. Just like the environment for user-space programs, the kernel environment is built up by individual environment variables; where an environment variable is a C string with format ''<key>=<value>''. |
| - | The kernel environment in kFreeBSD in an important scheme to adjust kernel configuration on boot time, many environment variables are used to set initial value of corresponding **sysctl** variables. Some variables are read-only to user-space as they can only be set from kernel environment, which are turn from the bootloader; they are called **kernel tunables**. | + | The kernel environment in kFreeBSD in an important scheme to adjust kernel configuration on boot time; many environment variables are used to set initial value of corresponding **sysctl** variables. Some variables are read-only to user-space as they can only be set from kernel environment, which are turn from the bootloader; they are called **kernel tunables**. |
| Most important variables for automatically booting the system are ''vfs.root.monutfrom*''; otherwise the kernel will asking for which device to mount as root, like if ''RB_ASKNAME'' is set in ''boothowto''. | Most important variables for automatically booting the system are ''vfs.root.monutfrom*''; otherwise the kernel will asking for which device to mount as root, like if ''RB_ASKNAME'' is set in ''boothowto''. | ||
| 行 385: | 行 385: | ||
| Parsing the command line should use no more than a page of memory, because the maximum length of a command line is limited by Multiboot Specification, which is 4 KiB, exactly same as the common page size on i386. | Parsing the command line should use no more than a page of memory, because the maximum length of a command line is limited by Multiboot Specification, which is 4 KiB, exactly same as the common page size on i386. | ||
| - | The added code will allocate one page and pass its virtual address to a new function ''parse_kernel_command_line''; this function will parsing the command line and initializing kernel environment, so a later call to ''init_static_kenv'' will be skipped in case of Multiboot. | + | The added code will allocate one page and pass its virtual address to a new function ''parse_kernel_command_line''; this function will parse the command line and initialize kernel environment, so a later call to ''init_static_kenv'' will be skipped in case of Multiboot. |
| This allocated page will holding initial static kernel environment, after the command line is fully parsed, in ''parse_kernel_command_line''. | This allocated page will holding initial static kernel environment, after the command line is fully parsed, in ''parse_kernel_command_line''. | ||
| <file diff> | <file diff> | ||
| 行 438: | 行 438: | ||
| ===== Handle Multiboot modules ===== | ===== Handle Multiboot modules ===== | ||
| - | A part from Multiboot kernel image itself, Multiboot bootloaders may also load one or more files into memory for kernel, those preloaded files usually called modules in Multiboot. | + | A part from Multiboot kernel image itself, Multiboot bootloaders may also load one or more files into memory for kernel, these preloaded files usually called modules in Multiboot. |
| - | There are 2 typical usages of the preloaded files in kFreeBSD; memory disk for root file system (initrd), and KLD modules. | + | There are 2 typical uses of the preloaded files in kFreeBSD, memory disk for root file system (initrd), and KLD modules. |
| FreeBSD BTX loader load addition files as KLD modules by default; an explicit specification of file type is required of any other types. To load an initrd, the type must be set as ''md_image'' or ''mfs_root''. | FreeBSD BTX loader load addition files as KLD modules by default; an explicit specification of file type is required of any other types. To load an initrd, the type must be set as ''md_image'' or ''mfs_root''. | ||
| 行 540: | 行 540: | ||
| Field ''pad'' is a reserved in current specification, and should always be set to 0 by bootloaders. | Field ''pad'' is a reserved in current specification, and should always be set to 0 by bootloaders. | ||
| - | Converting this Multiboot specific information to kFreeBSD preloaded file metadata is done as follows. | + | Converting this Multiboot specific information to kFreeBSD preloaded file metadata is done as followings. |
| * ''MODINFO_NAME'' will set from module command line, because many Multiboot bootloaders set the file name as the first part of the command line. | * ''MODINFO_NAME'' will set from module command line, because many Multiboot bootloaders set the file name as the first part of the command line. | ||
| 行 546: | 行 546: | ||
| * ''MODINFO_ARGS'' will also be set if there are any additional command line after the module name. | * ''MODINFO_ARGS'' will also be set if there are any additional command line after the module name. | ||
| * ''MODINFO_ADDR'' and ''MODINFO_SIZE'' is set from ''mod_start'' and ''mod_end'', the address is keeping in physical address for further converts. | * ''MODINFO_ADDR'' and ''MODINFO_SIZE'' is set from ''mod_start'' and ''mod_end'', the address is keeping in physical address for further converts. | ||
| - | * Some extra examines and adjustments will be taken if this module is a KLD module (have a valid ELF header), to make this KLD functional later. | + | * Some extra examines and adjustments will be taken if this module is a KLD module (having a valid ELF header), in order to make this KLD functional later. |
| ==== Testing with initrd ==== | ==== Testing with initrd ==== | ||
| 行 729: | 行 729: | ||
| ''Offset'' means offset to the ELF file. ''VirtAddr'' is the targeting address; it is relative because this file is a shared object. ''PhysAddr'' is ignored since KLD only care about virtual addresses. ''FileSiz'' indicates size of this segment store in the ELF file. ''MemSiz'' is the size that must be preserved after loading this segment into memory. | ''Offset'' means offset to the ELF file. ''VirtAddr'' is the targeting address; it is relative because this file is a shared object. ''PhysAddr'' is ignored since KLD only care about virtual addresses. ''FileSiz'' indicates size of this segment store in the ELF file. ''MemSiz'' is the size that must be preserved after loading this segment into memory. | ||
| - | Only segments have the ''LOAD'' type (''PT_LOAD'') are need to be loaded. | + | Only segments with the ''LOAD'' type (''PT_LOAD'') are needed to be loaded. |
| As above example, not all loadable segments have its offset equals to its relative virtual address; this will causing problems when the entire ELF file have been loaded by a Multiboot bootloader; don't expect this KLD module will work without fixing the loading location. | As above example, not all loadable segments have its offset equals to its relative virtual address; this will causing problems when the entire ELF file have been loaded by a Multiboot bootloader; don't expect this KLD module will work without fixing the loading location. | ||
| 行 742: | 行 742: | ||
| In order to link a KLD module, the KLD subsystem need to known its ''.dynamic'' section, that been mapped with ''DYNAMIC'' segment. The ''DYNAMIC'' segment is assumed to be included in another ''LOAD'' segment, usually the data segment; the relative start address of ''DYNAMIC'' segment is stored in a new metadata node with type ''MODINFO_METADATA | MODINFOMD_DYNAMIC''. | In order to link a KLD module, the KLD subsystem need to known its ''.dynamic'' section, that been mapped with ''DYNAMIC'' segment. The ''DYNAMIC'' segment is assumed to be included in another ''LOAD'' segment, usually the data segment; the relative start address of ''DYNAMIC'' segment is stored in a new metadata node with type ''MODINFO_METADATA | MODINFOMD_DYNAMIC''. | ||
| - | BTX loader will also examining the section headers of KLD modules if any, to get more information of its symbol table; it is optional because section headers are not used to make a KLD module functional, but providing useful information of symbols, that could be used in the in-kernel debugger DDB. | + | BTX loader will also examine the section headers of KLD modules if any, to get more information of its symbol table; it is optional because section headers are not used to make a KLD module functional, but providing useful information of symbols, that could be used in the in-kernel debugger DDB. |
| A KLD module could have its symbol table stripped to reduce file size; this step will be skipped if symbol table is not there. | A KLD module could have its symbol table stripped to reduce file size; this step will be skipped if symbol table is not there. | ||
Multiboot_kFreeBSD.txt · 最后更改: 2024/10/23 09:34 由 whr
除额外注明的地方外，本维基上的内容按下列许可协议发布： CC Attribution-Share Alike 4.0 International
