Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 07:48
    L3tum commented #449
  • Oct 20 22:07
    jos-b commented #591
  • Oct 20 22:07
    jos-b commented #591
  • Oct 19 10:13
    AntoineSebert commented #676
  • Oct 19 09:56
    AntoineSebert opened #680
  • Oct 18 13:02

    phil-opp on master

    Also deploy site on schedule ev… (compare)

  • Oct 18 12:58

    phil-opp on sponsor-link

    (compare)

  • Oct 18 12:58

    phil-opp on master

    Add a sponsor link to github bo… (compare)

  • Oct 18 12:56

    phil-opp on master

    Update to new Github Sponsors U… (compare)

  • Oct 11 17:24
    faraazahmad commented #449
  • Oct 11 17:24
    faraazahmad commented #449
  • Oct 11 14:47
    faraazahmad commented #449
  • Oct 09 06:19
    AntoineSebert commented #405
  • Oct 09 06:00
    artizzq commented #405
  • Oct 08 19:44
    phil-opp commented #405
  • Oct 08 17:44

    phil-opp on post-06

    Use latest nightly with rustfmt… Merge branch 'post-01' into pos… Merge branch 'post-02' into pos… and 3 more (compare)

  • Oct 08 17:44

    phil-opp on post-08

    Use latest nightly with rustfmt… Merge branch 'post-01' into pos… Merge branch 'post-02' into pos… and 5 more (compare)

  • Oct 08 17:44

    phil-opp on post-03

    Use latest nightly with rustfmt… Merge branch 'post-01' into pos… Merge branch 'post-02' into pos… (compare)

  • Oct 08 17:44

    phil-opp on post-05

    Use latest nightly with rustfmt… Merge branch 'post-01' into pos… Merge branch 'post-02' into pos… and 2 more (compare)

  • Oct 08 17:44

    phil-opp on post-04

    Use latest nightly with rustfmt… Merge branch 'post-01' into pos… Merge branch 'post-02' into pos… and 1 more (compare)

Lachlan Sneff
@lachlansneff
Sometimes the kernel needs to know the physical address of some virtual memory, so it translates it with whatever method it uses.
Aleksey Halahan
@skyne98
So, basically, the whole software implementation is made only to cover some cases, where we will need to manually translate the address?
@lachlansneff, thanks for the answer, btw!
Also, isn't there any kind of interrupt we can make to call the MMU directly for it to make a conversion for us?
Aleksey Halahan
@skyne98
Also, @lachlansneff, can I maybe ask you a couple of OS related questions in the private chat?
Lachlan Sneff
@lachlansneff
Sure, go ahead.
Yeah, there's no instruction to ask the mmu to translate an address.
Ben Gubler
@nebrelbug
Anyone have resources for drawing graphics on the screen and/or using UEFI?
Philipp Oppermann
@phil-opp
I don't have much experience with it, but it seems like this is easiest with VESA. The osdev wiki has some tutorials and the Redox kernel has implementations for both BIOS boot and UEFI boot. I think this has to be done in the bootloader (at least with BIOS booting)
Scott McWhirter
@konobi
iirc, includeos has some pretty basic VGA and console functionality that might be handy for reference
Philipp Oppermann
@phil-opp
I just implemented rust-osdev/bootloader#35 to support a basic 320x200 vga buffer
Scott McWhirter
@konobi
@phil-opp it's a shame font8x8 doesn't have something for U+FFFD... seems like that could be handy to have to avoid panic-ing on unknown characters
Philipp Oppermann
@phil-opp
Yeah.. Maybe there is some other symbol we can use? Or maybe it's possible to add it to font8x8..
Scott McWhirter
@konobi
added an issue for font8x8
Scott McWhirter
@konobi
@phil-opp not sure if you've seen it before, but this project might be a tool that's useful/instructive for this work: https://aws.amazon.com/blogs/aws/firecracker-lightweight-virtualization-for-serverless-computing/
Philipp Oppermann
@phil-opp
Looks really interesting! It seems like it runs on top of Linux, at least I can't find any kernel level code. But it contains various system libaries that seem useful
Scott McWhirter
@konobi
may also provide a place to run rust based kernels though, iirc
(since it's a kvm based microvisor)
Philipp Oppermann
@phil-opp
Oh right, this would be very nice
Scott McWhirter
@konobi
i think it's a lower surface area
Philipp Oppermann
@phil-opp
You mean that it would be easier to implement that a bare metal kernel?
Scott McWhirter
@konobi
i believe it provides a really stripped down hardware device group, with the ability to add more as you see fit
so perhaps might provide a base that is more basic than what qemu provides by default
Scott McWhirter
@konobi
(i suppose I'm thinking more for integration/systems testing)
Philipp Oppermann
@phil-opp
Interesting idea
James Carl
@crazycarl
A wonderful blog you've written and I look forward to future updates.
I've been working with your code and better understanding it. I've added some features and even just overhauled some parts to fit my preferences.
I'm coming from doing a lot of embedded development for micro-controllers in C++, so this isn't too out of the norm for me, but I must say. I have quickly fallen in love Rust.
Philipp Oppermann
@phil-opp
@crazycarl Thanks a lot! Great to hear that the blog is useful to you!
Aaron Deadman
@adeadman
I've modified the bootloader to initialise a VESA framebuffer, and added a vesa_buffer module to the kernel which can print to the screen using the font8x8 bitmaps. Now I'm trying to draw to the screen. Plotting a pixel was trivial, so I've gone on to implement Bresenham's line drawing algorithm - except that any form of floating point division causes a double fault. My understanding of the soft-float option was that this should be working and implemented using integer arithmetic functions - any ideas?
Aaron Deadman
@adeadman
Example code to reproduce in main.rs:
println!("Gradient of y = x / 2 = {}", get_gradient(0, 0, 100, 50));

fn get_gradient(x1: usize, y1: usize, x2: usize, y2: usize) -> f64 {
    let dx: isize = x2 as isize - x1 as isize;
    let dy: isize = y2 as isize - y1 as isize;
    dy as f64 / dx as f64
}
Aaron Deadman
@adeadman
Doing some more digging, it seems to be related to the casting from isize to f64 as part of the division. If dx and dy are already f64 the operation does not crash the kernel.
As a result I have now got my line drawing working, but I'm still stumped as to why the example code above would be causing a double fault
Philipp Oppermann
@phil-opp

Oh wow, this is really strange. The double fault occurs because of a stack overflow. Looking at the disassembly, it becomes clear why:

000000000022a260 <__floatdidf>:
  22a260:    50                       push   rax
  22a261:    e8 fa ff ff ff           call   22a260 <__floatdidf>

This is an endless recursion. I have no idea why LLVM generates such code.

Scott McWhirter
@konobi
godbolt++
Philipp Oppermann
@phil-opp
I tried to reproduce it on godbolt, but failed
Philipp Oppermann
@phil-opp
Is there a way to pass a target config file on godbolt?
Scott McWhirter
@konobi
mmm... good question, I haven't had to test out those edges... though I know some folks will run it locally for more fine grain debugging
Philipp Oppermann
@phil-opp
I created https://github.com/phil-opp/__floatdidf-issue for reproducing the issue. I think I'll open an issue in the rust repo, maybe someone knows what's going on
Philipp Oppermann
@phil-opp
I opened an issue at rust-lang/rust#62852
Aaron Deadman
@adeadman
:+1: I'd forgotten about disassembling the code from the stack trace, I think the v2 tutorial hasn't covered it yet. Thanks Philipp
Philipp Oppermann
@phil-opp
Yeah, the second edition provides no information about debugging at the moment. I'm still thinking about the best way to add it. My current plan is to add a "Debugging" post after the "Testing" post, which explains how to use gdb/lldb, QEMUs debug options, and objdump
Scott McWhirter
@konobi
I'm never sure how visible things like qemu monitor are to folks... all the no ui, but ridiculously helpful low-level helpers
Aaron Deadman
@adeadman
I'm now trying to draw antialiased lines using Xiaolin Wu's line drawing algorithm, which requires getting the fractional part of a number.
However, calling 1.75_f64.fract() leads to a linker error:
note: rust-lld: error: undefined symbol: fmod
          >>> referenced by arith.rs:560 (/Users/aaron/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/src/libcore/ops/arith.rs:560)
          >>>               /Users/aaron/Development/x86/curi_os/target/x86_64-curi_os/debug/deps/curi_os-317ecf0cf7f99e86.5fqxd6e0jeohqd9.rcgu.o:(_$LT$f64$u20$as$u20$core..ops..arith..Rem$GT$::rem::h09842b402db57bb3)
I thought it might be something the num_traits crate isn't providing, but the linker error is against arith.rs in the core
Seems to be true for any of the functions on f64 that return a modified float - floor, round, trunc, etc.
Aaron Deadman
@adeadman
re-reading num_traits code, I think it's because only a subset of FloatCore is implemented, and these functions are not
Scott McWhirter
@konobi
looks like there's a PR stream to make some of those functions available in num_traits via libm: rust-num/num-traits#99
Ben Gubler
@nebrelbug
@adeadman could I see your code with the VESA framebuffer? I'd love to implement something like that.
Also, has anybody been able to get a graphics library working?
Aaron Deadman
@adeadman
Hi @nebrelbug sure. The bootloader code is on my public Github, and the vesa drawing code is in curi_os in the vesa branch.
I can't claim credit for the vesa mode init and framebuffer printer code though - Philipp and jabedude wrote most of that and you can see that here: https://github.com/jabedude/bootloader/tree/vesa
One thing that limits the effectiveness of a lot of this is the lack of float math in the kernel, as discussed above. I have written my own versions of functions to truncate floats and return the fractional part (actually most of those functions can be written as variations on fmod, which can be solved in a stupid way by moving closer to 0 by 1.0 in a while loop until you have a number smaller than 1.0)
Aaron Deadman
@adeadman
I was finally able to figure out how to create a double buffer by creating a lazy_static Vec<u16> using the allocator code (had to bump the heap size). This should mean I can add some mouse support or a proper scrolling vesa writer implementation that shifts the characters up as the screen fills