by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Philipp Oppermann
    @phil-opp
    Sounds like a .bss section issue. You might need to manually zero this section at startup
    rybot666
    @rybot666
    I wonder if that would be an issue for our bootloader
    The GDT seems to be zero'd
    Or at least the pointer to it is
    On the plus side, both architectures compile, link and run fine when I manually load a GDT
    Cristian Kubis
    @tsurai
    wait, but how does using const functions as an initializer to statics work? The .bss section contains uninitialized data so rust cannot initialize them at compile time but there is nothing that could call the initializer at runtime either
    Cristian Kubis
    @tsurai
    shouldn't it rather be initialized at compile time and be put into the .data section?
    Philipp Oppermann
    @phil-opp

    I wonder if that would be an issue for our bootloader

    We handle .bss sections here: https://github.com/rust-osdev/bootloader/blob/e136cbe898a42d9787bb94367d7d8091dc2cddbc/src/page_table.rs#L103-L184

    Philipp Oppermann
    @phil-opp

    wait, but how does using const functions as an initializer to statics work? The .bss section contains uninitialized data so rust cannot initialize them at compile time but there is nothing that could call the initializer at runtime either

    It's not uninitialized data, but zeroed data. The idea is that you don't need to actually store static variables that are initialized with zero in the executable. Instead, you tell the loader which memory range it should set to zero when loading.

    This has nothing to do with const functions, all that matters is the bit-value of the result. If it is zero, the compiler does not store it in the .rodata/.data sections but only increases the size of the .bss section without actually writing it to the executable. However, this only works when your loader zeroes the memory range specified by the .bss section. If you write a custom loader and forget to do this, the memory will be unitialized and might contain random values.

    Cristian Kubis
    @tsurai
    the bootloader is a flat binary for MBR and does not have any loader that could zero out bss
    at least mine is
    Cristian Kubis
    @tsurai
    So because my initalization function sets the struct values to zero Rust is optimizing the whole call out assuming the ELF loader will zero the .bss section anyway
    Philipp Oppermann
    @phil-opp
    I think you might have to manually zero the .bss section at startup. One way to do that is to use a linker script to create _bss_start/_bss_end symbols so that you know the memory range that needs to be zeroed. Your startup code can then loop over this range and set everything to zero
    Cristian Kubis
    @tsurai
    That's what I just did and it seems to work as expected now :)
    Philipp Oppermann
    @phil-opp
    Great to hear that
    See also the r0 crate: https://docs.rs/r0/1.0.0/r0/
    Cristian Kubis
    @tsurai
    its the little things you learn along the way. Like not assuming too much about the environment
    Philipp Oppermann
    @phil-opp
    Absolutely!
    Cristian Kubis
    @tsurai
    while I do appreciate there being proper crates for handling this I want to code everything myself for this project. Just to force myself to read into every aspect and deal with it myself
    which isnt good for the end result but I might end up learning more
    Philipp Oppermann
    @phil-opp
    Sure, that's fair
    Oh, and just let me know if you want an invite to the organization
    Cristian Kubis
    @tsurai
    sure, would love to be a part of it
    Philipp Oppermann
    @phil-opp
    Invite sent
    Cristian Kubis
    @tsurai
    I'm having a hard time trying to figure out the smallest setup possible to reliable work across most systems
    given that the bootloader is only a transitional system there is not really a need to setup a sophisticated system
    I don't need multi threading, don't even need paging, maybe I can even get away with the PIC
    rybot666
    @rybot666
    You don't really need the PIC in a bootloader, unless you're advanced enough that you want to handle keyboard input
    Cristian Kubis
    @tsurai
    it will be needed eventually but the PIC should be just fine for it. Configuring APIC seems over the top unless multiboot kernels require apic to be setup
    rybot666
    @rybot666
    I don't believe that's a requirement
    Is your bootloader multiboot compatible?
    Also you need to enable paging to use long mode
    Cristian Kubis
    @tsurai
    but I don't really need long mode either
    Ilja Kartašov
    @Lowentwickler
    Hey guys! Is there some tool that can generate rust code from dtb files?
    defunct
    @defunctio
    @phil-opp thanks for publishing your work on the os dev series. It has been a incredible resource and reference for my own work. I’d like to join the GitHub osdev org and in time contribute back :)
    Philipp Oppermann
    @phil-opp
    Great to hear that, invite sent!
    @Lowentwickler I'm not aware of any. There are some crates for parsing dtb files on crates.io, but I found nothing that automatically generates Rust code. For embedded, there is svd2rust which does code generation for SVD files, maybe this is useful as a reference.
    Ilja Kartašov
    @Lowentwickler
    @phil-opp It would be nice to have something that can generate board abstraction from DTB file. Mostly files with constants of irqs, ranges and base addresses. What do you think?
    rybot666
    @rybot666
    Would this be used in a build.rs script?
    Ilja Kartašov
    @Lowentwickler
    My idea is to use it as a standalone tool for OS kernel development. It is up to developer to use it just once or for every build
    rybot666
    @rybot666
    Ah right
    Sounds like a great idea!
    Cristian Kubis
    @tsurai
    should be rather difficult to achieve tho
    Philipp Oppermann
    @phil-opp
    Sounds definitively useful!
    Ilja Kartašov
    @Lowentwickler
    I’ve been porting my kernel to PineBook Pro and RPi4 and found that both devices provide dtb to linux kernel. But I don’t like that concept. I want my Kernel compiled for RPi to already know the hardware. It is more embedded concept and should save from some overhead. I know that Zephyr uses something similar but for C. They pregenerate header files with preprocessor macroses. So maybe it is something I can contribute to the rust-osdev
    1 reply
    Ilja Kartašov
    @Lowentwickler

    Yes, it is. https://github.com/lowenware/leos-kernel

    I’ve started with real hardware recently. Haven’t commit anything yet, but hopefully will do until the end of the week.

    Shane Utt
    @shaneutt
    Cool, I'll take a look thank you.
    rybot666
    @rybot666
    @phil-opp I just registered i386 as a crate and invited you as an owner. I was thinking it would be better than cpu for 32-bit bare-metal stuff (akin to our current x86_64 crate)
    Currently it's just a blank crate
    Philipp Oppermann
    @phil-opp
    Good idea! There is also the x86 crate, which provides abstractions for both 32-bit and 64-bit, maybe that's useful for us too.