rust-osdev / bootloader Goto Github PK
View Code? Open in Web Editor NEWAn experimental pure-Rust x86 bootloader
License: Apache License 2.0
An experimental pure-Rust x86 bootloader
License: Apache License 2.0
I've finally had some spare time to start working on my OS again and was hoping I might have a chance to give back after all the great work you've done so far. I know there's currently an open issue for VESA video modes #37, but I didn't want to hijack that thread.
Since you have plans for VESA video modes in the future, would you also be interested in adding support for VGA modes? I've just finished a minimal example that has support for switching to 80x25 text
mode from the kernel using VGA registers. The current code can be found here https://gist.github.com/RKennedy9064/374ed861f743079e43b1c5da87af63f8.
I was able to successfully boot my OS using the vga_320x200
mode from bootloader
, then switch to 80x25 text
mode and use the println!
macro to display messages again.
I'm not sure if this is on the road map, or even something you're interested in, but if you are I'd love to possible collaborate to include something like this. My plan is to clean up the existing code, add more comments and tests and then try to add more support for additional modes. I figured it would be nice to have the ability to switch video modes from the kernel at run time.
Let me know what you think when you have the time and thanks for all the great work so far on the tutorials!
The current entry point is hardcoded to _start
(or the entry_point!
macro). This provides a single entry point to the code.
When bootstrapping SMP, the new processor starts up at a given physical address in the IPI (Inter-Processor Interrupt) in 16 bit mode. This requires us to start at 16 bit code and enable 64 bit mode again. Please provide a way to define multiple "entry points" which defaults to the current _start
but can also be used to bootstrap SMP.
The booloader fails to load the second stage when run in qemu. In func load_second_stage_from_disk in file boot.s the code jumps to label second_stage_load_failed as the carry flag has been set.
Hey there! I have a question and, maybe, a suggestion: should bootinfo be passed as a mutable static reference? Or maybe there is no need at all for it to be a static reference? Maybe the struct itself should just contain the address (which can be easily copied) and all the other copies of bootinfo can operate on it during the function calls?
Right now, there seems to be a slight problem / inconvenience, where you cannot allocate any physical frames, because you have a static immutable reference to the bootinfo struct, which contains the required structs / functions.
Cheers, Alex!
I want to run my kernel under HAXM but whenever I do that Qemu immediately gives me two VCPU shutdown requests (that's using -accel hax
). Is there a way we can add HAXM support or is this a bug in Qemu itself?
From your first volume, you would do something like
start:
mov %esp, stack_top
mov %edi, %ebx
and then add multiboot_information_address: usize
to the "kmain" (or in the case of volume 2, _start).
However, when I add
global_asm!(r#"
start:
mov %esp, stack_top
mov %edi, %ebx
"#);
to the top of my main.rs, and do
pub extern "C" fn _start(multiboot_information_address: usize) -> ! {
let boot_info = unsafe{ multiboot2::load(multiboot_information_address)};
let memory_map_tag = boot_info.memory_map_tag()
.expect("Memory map tag required");
println!("memory areas:");
for area in memory_map_tag.memory_areas() {
println!(" start: 0x{:x}, length: 0x{:x}",
area.base_addr, area.length);
}
...
The kernel panics with
(I added a function to handle panics)
Thank you in advance
Will bootloader support windows/macOS ? I went to x86_64-bootlader.json, but there's only "x86_64-unknown-none-gnu" target for llvm
The bootloader currently sets up huge stack for the kernel by default (512 pages = 2MB). Now that the stack size is configurable, we should probably reduce the default.
cc @64
Right now the kernel stack is always fixed in memory. If I want to make my kernel higher-half the kernel will need to move. This can be done by providing a custom linker script to the kernel target. This works fine. The stack that is setup by the bootloader however is always fixed in memory and will not move with the kernel.
I suggest making the stack location configurable like the physical memory offset already is. A more elegant solution would be to switch to an offset and automatically calculate the stack location.
The references are currently only valid in the kernel address space, and not in the current bootloader address space. We could fix this by either:
I love the idea of a pure Rust bootloader, but I'd love to know how it works, and perhaps write my own. Are there some good resources for this? I'd love to see a Phil-Opp tutorial about writing your own bootloader...
Done some testing. Seems to happen after entering protected mode. CPU at 100% and frozen
When building the bootloader as a dependency (i.e. to enjoy the extra features) the build fails:
thread 'main' panicked at 'The bootloader must be compiled for the `x86_64-bootloader.json` target.', C:\Users\ethin\.cargo\registry\src\github.com-1ecc6299db9ec823\bootloader-0.8.0\build.rs:108:9
I am attempting to take advantage of the dynamic stack selection, dynamic kernel placement, etc., that I would not otherwise enjoy had I not specified the "binary" feature. Is this doable?
i get stuck with this screen on Oracle Virtual box, and 2 hardware devices, if i use a USB stick with the image.
it works fine if i use qemu-system-x86_64 to load the binary.
it works fine if i use qemu-system-x86_64 to boot from a USB stick with the image.
i am using this source code to build the binary (pinned to the commit i was using) https://github.com/CaptainOachkatzl/RustOS/tree/de6aaee00cc11f8274ca9b003730c7a10dd11210
in the zip are the binary and the virtualbox USB drive image i was using
bootloader_stuck.zip
this was the information part. i also want to say what you are doing is amazing and it helped me out a lot so thank you for that!
Currently we only provide some minimal build instructions in the Readme. We should also document advanced patterns such as:
I think the best approach for now is to just create a doc
folder with markdown files in it and link it from the Readme.
Would you consider adding the builder executable to a [[bin]]
section of the cargo manifest a good idea? That should simplify things for people who don't want to clone the repo and manually cd
into the builder directory to make use of it.
If so, I'm happy to whip up the short PR
When making a higher half kernel it would be useful to move the boot_info into the higher half. It would also have to remap all the child structures, like memory_map
I imagine it would go into the [package.metadata.bootloader]
like physical-memory-offset
and kernel-stack-address
.
It seems to be a regression between 0.2.0 and 0.2.1: 0.2.0 works fine but 0.2.1 and 0.3.0 both hang.
Tested on qemu-3.0.0 on linux 4.14.18 x86_64, built with rustc 1.30.0-nightly (4141a4079 2018-09-25)
Should be a pretty simple problem to fix, but as of 24 April 2020, use of the asm!
macro is triggering multiple deprecation warnings:
warning: use of deprecated item 'asm': the syntax of asm! will change soon, use llvm_asm! to avoid breakage
--> src/main.rs:46:5
|
46 | asm!("call $1; ${:private}.spin.${:uid}: jmp ${:private}.spin.${:uid}" ::
| ^^^ help: replace the use of the deprecated item: `llvm_asm`
|
= note: `#[warn(deprecated)]` on by default
warning: use of deprecated item 'asm': the syntax of asm! will change soon, use llvm_asm! to avoid breakage
--> src/main.rs:92:5
|
92 | asm!("mov bx, 0x0
| ^^^ help: replace the use of the deprecated item: `llvm_asm`
Should be an easy fix if you ask me โ since there's probably a lot more instances than those two, is this being worked on already?
The boot loader provides the kernel with a miss aligned stack.
This cause issues when SSE is enabled, as some of those instructions expect 16-aligned stacks and the alignment is off by eight.
Reproduction steps:
Take blog-os post-03, enable SSE in the boot loader and target, call panic! in main, if running under bochs you will get a fault.
(QEMU appears to ignore the issue)
The fault occurs on movaps instruction form xmm0 to the (mis-aligned stack).
The stack alignment is mess-ed up because when the _start function is called the compiler assumes a return address has been pushed on the stack, making it 16x +8 aligned, while it is apparently 16 aligned when called by the bootloader.
From reading OS dev wiki, the kernel entry point should be reached using a call instruction so that it matches the compiler assumptions, (Even in C) whereas the boot loader appears to use a jmp.
This is the tracking issue for the bootloader rewrite. We're tracking our progress under the "Rewrite" milsestone. Our progress is as follows
Our eventual roadmap is to include UEFI support (@phil-opp is working on that) and multiboot client support, so we can load our kernel from GRUB (and other complaint loaders)
Currently the bootloader masks all hardware interrupts:
Lines 68 to 71 in bda13d8
They shouldn't be masked when control is passed to the kernel.
At the moment, the bootloader only handles normal loadable ELF sections. It should also zero .bss and similar sections.
I am slightly new to rust. Apologize for any mistakes.
I am trying to add [package.metadata.bootloader]
but it does not take effect.
Steps for repro:
post-10
from blog_osprintln!("{:X}", boot_info.physical_memory_offset);
to kernel_main
[package.metadata.bootloader]
kernel-stack-address = "0xFFFFFF8000000000"
kernel-stack-size = 128
physical-memory-offset = "0xFFFF800000000000"
Expected output: 0xFFFF800000000000
Current output: not 0xFFFF800000000000
Am I missing something? Should I have to build bootloader myself to use the configuration?
It appears that the name rustboot is already taken. https://github.com/charliesome/rustboot
Might I suggest boot.rs?
I'm wondering if its possible to explicitly map memory regions in the bootloader? For example, could we detect to see if the APIC is available, then map its entire memory region into the page table before loading the kernel, and then let the kernel configure the IDT? We can even pass the address of the APIC region (its default is FE0000, if I'm not mistaken, but this can change) in the boot information structure. Is this feasible, and if so how would it be accomplished?
Building the bootloader fails during the linking stage. It appears some funcs are not implemented in rlibc.
error: linking with `cc` failed: exit code: 1
|
= note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/home/cylon2p0/.xargo/HOST/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.114xigf1yyw2gcw0.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.16u6js6g0l3k1ic6.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.170lmw1sqqfe80qo.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.1dk5kk1ooqmqppyo.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.1dqvxks6k2bzkxe.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.1dtnwzxvq606tnr.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.1gwav539dtqo5mpz.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.1jlhl2cwhfjqk73.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.1rumt9cqnarag56v.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.1y0f1d2ywo4h8fck.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.1y16o1qfye96o7m0.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.236iz806sghm3wx.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.27e9glo77wiztta4.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.2jqywn86b2gsqohu.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.2lyh15q6cjwzy18c.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.2qnu5lz8itx5t8lt.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.2uoyeb1ud6wb16nh.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.340hcms0rqmw1pjh.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.39fsqmmlmfbk11x5.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.3ab2w6r2t45b4bca.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.3ik0x0hz6l66cx38.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.3ldk0i2zxftngav8.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.3mf543h185mr1r9y.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.436dotimmrgzkwfa.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.43v6g0y2xsxoggnt.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.45pc7c65foh9i35f.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.48721dc4k5qxei0u.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.49a7n47po4ttqjl7.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.4h0kvux6xasoqj9f.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.4hqczukarqnsxim3.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.4re5h8xun1god8vx.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.4svjkysiwylw53vz.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.4tz198z0woys4rj8.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.4xq48u46a1pwiqn7.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.4yh8x2b62dcih00t.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.4ypvbwho0bu5tnww.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.51s1w397y42gpez1.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.56dhlykxk36fnj7k.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.57k06xfugllsc526.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.594xacf7fal17zd5.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.5csepo1d58sdgir4.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.7p53qlves2rwxx0.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.8xzrsc1ux72v29j.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.98g0d9x8aw3akpe.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.9elsx31vb4it187.rcgu.o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.ehly403ieh2api9.rcgu.o" "-o" "/home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-nodefaultlibs" "-L" "/home/cylon2p0/bootloader/target/debug/deps" "-L" "/home/cylon2p0/.xargo/HOST/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/home/cylon2p0/bootloader/target/debug/deps/libspin-c51b2e86c2de1538.rlib" "/home/cylon2p0/bootloader/target/debug/deps/libos_bootinfo-dba7815e5fe96d50.rlib" "/home/cylon2p0/bootloader/target/debug/deps/libarrayvec-53c961d979185dfa.rlib" "/home/cylon2p0/bootloader/target/debug/deps/libnodrop-5ac98ef241ef76ef.rlib" "/home/cylon2p0/bootloader/target/debug/deps/libx86_64-8aa0ca550f385699.rlib" "/home/cylon2p0/bootloader/target/debug/deps/libux-1c933097b4b69b23.rlib" "/home/cylon2p0/bootloader/target/debug/deps/libusize_conversions-5b96477c65312c01.rlib" "/home/cylon2p0/bootloader/target/debug/deps/libbit_field-f6dd7c703522e559.rlib" "/home/cylon2p0/bootloader/target/debug/deps/libbitflags-a50202da937bfed0.rlib" "/home/cylon2p0/bootloader/target/debug/deps/libxmas_elf-28f6da88f7f9c0cf.rlib" "/home/cylon2p0/bootloader/target/debug/deps/libzero-359b6889bcf3f9b5.rlib" "/home/cylon2p0/bootloader/target/debug/deps/librlibc-a70e38fe72970e76.rlib" "/home/cylon2p0/.xargo/HOST/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-6b8006ed673e894b.rlib" "-Tlinker.ld" "-Wl,-Bdynamic"
= note: /home/cylon2p0/bootloader/target/debug/deps/bootloader-135935f7d9f3d13c.170lmw1sqqfe80qo.rcgu.o: In function `_start':
170lmw1sqqfe80qo-d74921964f837aa8fb1308e78eea466c.rs:(.boot+0x0): multiple definition of `_start'
/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../lib/Scrt1.o:(.text+0x0): first defined here
/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../lib/Scrt1.o: In function `_start':
(.text+0x12): undefined reference to `__libc_csu_fini'
(.text+0x19): undefined reference to `__libc_csu_init'
(.text+0x20): undefined reference to `main'
(.text+0x26): undefined reference to `__libc_start_main'
collect2: error: ld returned 1 exit status
Hello there! I need to start by saying that this project is awesome and I strongly believe it will spark the creation of some very creative pieces of software!
Nevertheless, I think it would have being awesome to add support for choosing one of the available VESA modes. Right now, you have to do it in real-time mode, while bootloader switches the processor to go to 64-bits and therefore, if you need to work with it, then you need to somehow go back to 16-bits in the kernel (or 32-bits with emulation?) and do the setup. Making bootloader do it might be the best idea (as well as give it an option to automatically choose the highest option).
As far as I understand, it can be quite a challenge, considering you have to fit it into 16-bit processor mode memory (512 first bytes?), but as far as I know, it is rather doable.
I think that this implementation from Redox OS can serve as a good example.
Cheers, Alex!
Reported in phil-opp/blog_os#403 (comment).
Is there any documentation about the state of the system when _start
function is invoked by the bootloader? For example, what features are enabled, what is the layout of memory, what state are the processors in?
The current bootloader generates a ".bin" file at the end which is a hard disk image. Is it possible to provide some instructions to generate a simple FAT disk with that bin file of ELF file?
Because the bootloader is completely customized, i am struggling to understand how to put the bin file or some part of the kernel in an actual file system.
For example, using GRUB one can follow these to generate disks
Or alternatively, can we make GRUB boot this bootloader (not chainloading because it works on different disks)
Hi all,
A building error occurs when renaming the kernel binary and building
cp example-kernel/target/x86_64-example-kernel/debug/example-kernel example-kernel/target/x86_64-example-kernel/debug/example-kernel.elf
KERNEL=example-kernel/target/x86_64-example-kernel/debug/example-kernel.elf KERNEL_MANIFEST=example-kernel/Cargo.toml cargo xbuild --release --features binary
Error: rust-lld: error: undefined symbol: _kernel_start_addr
.
It seems that build.rs
does not redefine the symbols correctly, i.e., _binary_objfile_*
set by objcopy
, when objfile name contains the special character .
.
After updating bootloader
to 0.8.3 I started getting error: This crate currently does not support 32-bit protected mode
error but I am pretty sure that I cross-compile x86_64 arch binary.
This issue is not reproducible with bootloader version 0.7.1 or lower. Here is the content of my target x86_64-unknown-none.json:
{
"llvm-target": "x86_64-unknown-none",
"data-layout": "e-m:e-i64:64-f80:128-n8:16:32:64-S128",
"arch": "x86_64",
"target-endian": "little",
"target-pointer-width": "64",
"target-c-int-width": "32",
"os": "none",
"executables": true,
"linker-flavor": "ld.lld",
"linker": "rust-lld",
"panic-strategy": "abort",
"disable-redzone": true,
"features": "-mmx,-sse,+soft-float"
}
I am compiling with this command:
cargo bootimage --target x86_64-unknown-none.json
Best regards!
Things we have to do in order to improve this crate:
cargo-xbuild
instead of xargo
(since the latter is no longer maintained)build
sub-crate that builds the bootloader and links it with a kernel to create a bootable disk image. The tool needs to do the following:
cargo xbuild --target x86_64-bootloader.json --release
llvm-objcopy
and cargo-binutilscc phil-opp/blog_os#403 (comment).
@Mendess2526 let's continue the discussion here.
This will need src/stage_3.s to be adapted to stay in protected mode and to setup non-PAE page tables. It will then need at least changes to the rust part to handle non-PAE page tables.
Hello! When I test an handwritten OS following the toturial Writing an OS in Rust, the test is successful, but there is a warning on configuration when building the bootloader. Here's my console output:
PS D:\RustProjects\spicy_os> cargo xtest
Compiling spicy_os v0.1.0 (D:\RustProjects\spicy_os)
Finished dev [unoptimized + debuginfo] target(s) in 0.38s
Running target\x86_64-spicy_os\debug\deps\spicy_os-990499773c553c1e
Building bootloader
warning: The `publish-lockfile` feature is deprecated and currently has no effect. It may be removed in a future version.
Compiling bootloader v0.6.0 (C:\Users\luojia65\.cargo\registry\src\mirrors.ustc.edu.cn-61ef6e0cd06fb9b8\bootloader-0.6.0)
Finished release [optimized + debuginfo] target(s) in 1.88s
Running: `qemu-system-x86_64 -drive format=raw,file=D:\RustProjects\spicy_os\target\x86_64-spicy_os\debug\deps\bootimage-spicy_os-990499773c553c1e.bin -device isa-debug-exit,iobase=0xf4,iosize=0x04 -serial stdio -display none
According to this warning, cargo feature publish-lockfile
has currently no effect. It looks like this is related to the piece of code here. Would it be possible to remove this cargo feature configuration, or do another way to fix this warning?
Here's my Rustup and Rustc version:
C:\Users\luojia65>rustup -V
rustup 1.18.3 (435397f48 2019-05-22)
C:\Users\luojia65>rustc -V
rustc 1.35.0 (3c235d560 2019-05-20)
https://github.com/rust-osdev/bootloader/blob/master/src/main.rs#L368
does the panic handler really need to be extern "C"?
it causes a warning due to PanicInfo not being ffi-safe:
Compiling bootloader v0.8.2 (/Users/user/.cargo/registry/src/github.com-1ecc6299db9ec823/bootloader-0.8.2)
warning: `extern` fn uses type `core::panic::PanicInfo`, which is not FFI-safe
--> src/main.rs:368:31
|
368 | pub extern "C" fn panic(info: &PanicInfo) -> ! {
| ^^^^^^^^^^ not FFI-safe
|
= note: `#[warn(improper_ctypes)]` on by default
= help: consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute to this struct
= note: this struct has unspecified layout
Finished release [optimized + debuginfo] target(s) in 3.16s
When I build the bootloader under WSL (Windows subsystem Linux), it finishes while reporting errors:
Compiling bootloader v0.8.0 (/mnt/d/devs/Rust/bootloader)
error: failed to remove /mnt/d/devs/Rust/bootloader/target/x86_64-bootloader/release/deps/bootloader-589b595378e59014.bootloader.3pdwijpa-cgu.0.rcgu.o: Input/output error (os error 5)error: failed to remove /mnt/d/devs/Rust/bootloader/target/x86_64-bootloader/release/deps/bootloader-589b595378e59014.bootloader.3pdwijpa-cgu.1.rcgu.o: Input/output error (os error 5)
error: failed to remove /mnt/d/devs/Rust/bootloader/target/x86_64-bootloader/release/deps/bootloader-589b595378e59014.bootloader.3pdwijpa-cgu.12.rcgu.o: Input/output error (os error 5)
error: aborting due to 3 previous errors
Finished release [optimized + debuginfo] target(s) in 3.83s
Would it be possible to have support to boot using PXE or iPXE (with iPXE downloading the bootimage.bin using TFTP for instance).
This would require changing the logic to load the files in memory (which iPXE probably takes care of).
This could be poretty helpful for development on real hardware, as it wuld allow to network boot instead of going through the write to USB manipulations.
Currently the build process is a bit strange:
We could change it in the following way:
BOOTLOADER_KERNEL_PATH
environment variable, converts it to a binary blob and then back to an object file (e.g. cargo objcopy -- -I binary -O elf64-x86-64 target/x86_64-blog_os/debug/blog_os blog_os_bin.o --binary-architecture=i386:x86-64
)The new build process would be:
The big disadvantage of this is that we need to rebuild the bootloader for each kernel change, so maybe it is better to keep the current build system.
Is it always index 0
? Should this be passed in the BootInfo
struct?
We currently only test the bootloader without the SSE feature. We should add an additional test kernel that makes use of it.
Im following the OS dev tutorial series and decided to try to run the kernel on a real machine, but it hangs indefinitely before the second stage of the bootloader.
It prints Booting... (first stage)
and then hangs. No other output unfortunately.
I've tried building it in release mode (as suggested in a similar issue) but it doesn't make a difference. Everything works fine when I run it in QEMU, release or debug.
Any ideas? Would be cool to see it running on real hardware :)
Edit: I'm on macOS, booting from a USB stick. Writing the image with dd if=target/x86_64-blog_os/release/bootimage-blog_os.bin of=/dev/disk3 && sync
tdata
and tbss
section stores thread local storage for the system. In kernel, we will need to initialize this section per-cpu or per-thread depending on usages. Rust provides a #[thread_local]
attribute which puts the data in the above sections.
Please enable that section in bootloader and pass its location to the kernel so that it can map the TLS data as needed.
Causing a page fault upon attempted access, of course.
Yeah, stuff gets mapped multiple times. Here is my log output [from an isa-debugcon]:
; STUFF HERE
MAP @ PhysFrame[4KiB](0x5f8000) to Page[4KiB](0xf001f7000)
Now mapping Seg
MAP @ PhysFrame[4KiB](0x5f8000) to Page[4KiB](0xf001f7000)
panicked at 'kernel mapping failed: Mapping(PageAlreadyMapped(PhysFrame[4KiB](0x5f8000)))', src/main.rs:268:6
And it just hangs. So... It seems that sections do NOT have to be 4k-aligned in ELFs. The culprit in my case was .got
. Forcing it to stay aligned fixed my problem. But, this should just work and not require custom linker scripts.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.