Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 00:57
    andyhhp commented #570
  • Nov 20 14:29
    phil-opp commented #676
  • Nov 20 02:49
    andyhhp commented #449
  • Nov 16 19:25

    phil-opp on master

    Clarified writing beyond the bu… (compare)

  • Nov 16 19:25
    phil-opp closed #685
  • Nov 16 19:24
    phil-opp commented #685
  • Nov 16 19:14
    djhworld opened #685
  • Nov 16 18:09
    phil-opp commented #403
  • Nov 16 18:03
    phil-opp commented #403
  • Nov 16 08:27
    shakram02 commented #627
  • Nov 16 08:26
    shakram02 commented #627
  • Nov 16 08:26
    shakram02 commented #627
  • Nov 15 20:07
    djhworld commented #403
  • Nov 12 09:30
    arnoldcui commented #403
  • Nov 11 16:12
    arnoldcui commented #403
  • Nov 11 10:49
    phil-opp commented #403
  • Nov 11 10:09
    arnoldcui commented #403
  • Nov 11 08:44
    Dentosal commented #283
  • Nov 11 03:39
    64 commented #283
  • Nov 11 03:39
    64 commented #283
Philipp Oppermann
@phil-opp
Why are you still using the alpha version?
I'm currently not near a computer, so I'm not sure what's the problem
Lachlan Sneff
@lachlansneff
I'm using a fork of it that supports packaging. The current upstream has the same problem I believe.
Lachlan Sneff
@lachlansneff
Oh, btw @phil-opp, can you update the published version of os_bootinfo when you get the chance?
Philipp Oppermann
@phil-opp

can you update the published version of os_bootinfo when you get the chance?

Done (as version 0.3.0)

Lachlan Sneff
@lachlansneff
Thanks :)
Lachlan Sneff
@lachlansneff
Also, looks like the x86_64 crate needs to be updated to use the new os_bootinfo version.
Philipp Oppermann
@phil-opp
Hmm, this dependency does not really make sense in my opinion. It was just a hack because the old bootloader loading mechanism couldn't ensure that the same bootinfo versions were used in the bootloader and kernel, so the workaround was to just eliminate almost all dependencies from os_bootinfo so that its types stay the same. With the new mechanism kernels should not depend on os_bootinfo directly.
I'm going to yank os_bootinfo version 0.3.0, because it is a backwards compatibitily hazard for kernels that still dependend on it directly.
I think the best way forward is to deprecate os_bootinfo completely and create a new crate with a different name that is used internally by the bootloader but never reported to the outside (only re-exported). This allows us to remove the VERSION constant and use dependencies more freely.
Lachlan Sneff
@lachlansneff
You could just have os_bootinfo be a module of the bootloader.
The main issue here is how ranges from the bootloader should be converted into ranges for the x86_64 crate.
Lachlan Sneff
@lachlansneff
Sorry, other way around
Philipp Oppermann
@phil-opp
Yeah, just making it a submodule is a good idea. We can always factor it out in a separate crate if needed
Lachlan Sneff
@lachlansneff
Btw, nebulet is waiting on this to work, do you mind if work on it so it can get done sooner?
Philipp Oppermann
@phil-opp
@lachlansneff Could you try rust-osdev/bootloader#23
Lachlan Sneff
@lachlansneff
Damn, I did exactly the same thing
Philipp Oppermann
@phil-opp
Oh sorry
Lachlan Sneff
@lachlansneff
No worries
Philipp Oppermann
@phil-opp
I wanted to see whether it works out before I say anything
Lachlan Sneff
@lachlansneff
Let's take a closer work at the differences between them, but yeah
Philipp Oppermann
@phil-opp
Seems like you just used the PhysFrameRange types directly. I think this is the correct way forward, but I think it's better to do it in a seperate patch because it requires fairly large changes
So how about merging rust-osdev/bootloader#23 first and then doing the additional steps (removing repr(C), directly using PhysFrameRange, adding packaging support, etc) separately?
Lachlan Sneff
@lachlansneff
That's probably the right way to do it, but I need packaging support for nebulet, so I'm going to use my fork for now.
Philipp Oppermann
@phil-opp
Sure
It was one of the goals of the new bootloader dependency mechanism that it's easily possible to use a different bootloader
Lachlan Sneff
@lachlansneff
That's true.
It's probably safe to say that the new interface is stable.
Philipp Oppermann
@phil-opp
And it's good that the infrastructure no longer depends solely on me^^
Lachlan Sneff
@lachlansneff
Indeed
Scott McWhirter
@konobi
howdy all
I've been trying to get blog_os up and running on OSX, I've gotten it all to build without error, but the kernel just hangs and never outputs anything
is this specific to binutils on OSX? if so, is there some documentation on what/how to change the linker used somewhere?
@phil-opp great blog series btw... definitely one of the best approaches I've seen to explaining os dev in a consumable way in a long time
Scott McWhirter
@konobi
oh... was able to coax qemu on osx to show it up (using -curses as a qemu option)... looks like qemu on OSX has some pain points that make things tough to debug
Scott McWhirter
@konobi
@phil-opp I noted there's some interest in supporting ARM perhaps... has there been any movement along those lines at all?
Lachlan Sneff
@lachlansneff
Has anyone put thought into making an uefi version of the bootloader?
It doesn't look like it'd be much work.
Scott McWhirter
@konobi
it's been a few years, but the uefi tooling at the time was really quite poor... hopefully that's improved since
I have prior experience working with the u-boot source and the freebsd loader on ARM (armv7) and am currently interested in experiments with low cost, high performance ARM64 SBCs, so am hoping to avoid redundant work if an ARM bootloader is on the cards
Lachlan Sneff
@lachlansneff
No one is currently working on one unfortunately. You could though!
Scott McWhirter
@konobi
Cool... I'll likely be working with something like this... https://www.pine64.org/?page_id=61454
(either this, or another high spec "open" board)
which should hopefully make it more accessible to hobbyists
Lachlan Sneff
@lachlansneff
Awesome
Scott McWhirter
@konobi
yeah... $80 isn't too far out of reach
Philipp Oppermann
@phil-opp

@konobi Hi! Sorry for the late reply, I've been on vacation.

great blog series btw... definitely one of the best approaches I've seen to explaining os dev in a consumable way in a long time

Thanks so much!

oh... was able to coax qemu on osx to show it up (using -curses as a qemu option)... looks like qemu on OSX has some pain points that make things tough to debug

Never heard of this issue. So the QEMU window didn't open without the -curses option?

I noted there's some interest in supporting ARM perhaps... has there been any movement along those lines at all?

Not much. The biggest problem is that ARM is so heterogeneous, i.e. there are all kinds of boards with very different features (some of them don't even have a MMU). So writing a general ARM tutorial that works with multiple boards is difficult. I imagine that we could provide some "Porting to X" posts as soon as there is enough functionality in the kernel (where X are various boards, e.g. raspberry pi or the ROCKPro64 you mentioned).

@lachlansneff

Has anyone put thought into making an uefi version of the bootloader?

UEFI support would be great! We had some discussion about this in https://github.com/phil-opp/blog_os/issues/349#issuecomment-381163174.

Scott McWhirter
@konobi
@phil-opp yeah... I took a look through the field again and reminded myself of just how hit and miss it was. It has thankfully had a flurry of new and better tooling for those platforms, but yeah... it's a minefield. There's 2 aspects that are promising though... quite a bit can be taken care of by use of FDT to take care of some of those issues at build time, but also that the ARM hardware is now cheap enough that restricting a kernel's functionality to a known set of features is less of a barrier to entry than the difference between Intel and AMD