Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 20:57
    ethindp commented #696
  • 11:36

    phil-opp on master

    Use <h1> instead of <h2> for 'R… (compare)

  • 11:23
    Rustin-Liu synchronize #700
  • 11:21
    Rustin-Liu commented #700
  • 11:17
    Rustin-Liu synchronize #700
  • 11:12
    phil-opp commented #696
  • 10:54
    phil-opp commented #700
  • 10:41
    phil-opp commented #699
  • 07:33
    wusyong commented #699
  • Dec 12 19:51
    zheli commented #700
  • Dec 12 19:19
    ethindp commented #696
  • Dec 12 11:57
    phil-opp commented #696
  • Dec 12 11:40
    phil-opp commented #700
  • Dec 12 10:12
    phil-opp edited #692
  • Dec 12 10:04
    phil-opp commented #692
  • Dec 12 09:51

    phil-opp on master

    Code examples are _additionally… (compare)

  • Dec 12 09:51

    phil-opp on master

    Improve rendering of "```" (compare)

  • Dec 12 09:48

    phil-opp on license

    (compare)

  • Dec 12 09:48

    phil-opp on master

    Update copyright year in MIT li… License blog content under CC B… Clarify licensing in root README and 3 more (compare)

  • Dec 12 09:48
    phil-opp closed #705
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
qemu on osx didn't want to open at all... possibly due to xquartz being hit and miss
(the gui window that is)
Philipp Oppermann
@phil-opp

qemu on osx didn't want to open at all... possibly due to xquartz being hit and miss

Hmm, never heard of that issue (and I believe there are some people who implemented the blog on macOS). How did you install QEMU?

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

What do you mean? That ARM is cheap enough so that everybody can just buy a specific board?