Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 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
  • Nov 11 03:38
    64 commented #283
  • Nov 08 12:53
    samgiles commented #283
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?

Scott McWhirter
@konobi
@phil-opp homebrew... my xquartz is royally messed though... not sure if that's how they tried to implement the "cocoa" display option
not so much a specific board as a board with a specific base featureset
Philipp Oppermann
@phil-opp
Ah, so maybe it's just an issue with your setup, and not "normal" macOS machines.
Makes sense
I'm open for adding ARM support, but I don't have the time to look into it myself at the moment
Scott McWhirter
@konobi
yeah... no worries... trying to gather the info for ARM booting seems to be the bottleneck for me... it's just not as available as x86 in forms such as the osdev wiki
Lachlan Sneff
@lachlansneff
qemu works just fine on my macbook
Scott McWhirter
@konobi
is the window you get via xquartz?
Lachlan Sneff
@lachlansneff
Dunno, I just installed qemu through homebrew