5
12bitfloat
138d

I've just wasted 3 hours on this shit

Apparently when you use -device loader in qemu to load raw code into your vm and start executing it, qemu thinks that - actually - you didn't really want to execute from 0x00007c00. What you *really* wanted is to execute random fucking gibberish at 0xffff07c00

Yes qemu, that's *exactly* what I wanted!
*grumble* fckingpieceofshitsoftware *grumble*

Comments
  • 1
    Not surprising? It's physical vs virtual addresses
  • 0
    @devRancid It's in real mode. There is no virtual memory and CS is 0
  • 1
    Theres gotta be a setting for that though right?

    What are you trying to test for?
  • 1
    @Wisecrack I was trying to load a bootloader into a specific memory region. It should set the PC to the same location after loading so it executes but something was super weird

    Now that I think about it, it probably automatically relocated the range because 0x7c00 is reserved for the actual bios bootloader

    But anyhow, I've figured it out by just using a raw disk image instead of the device loader :D
  • 1
    @12bitfloat other than math, os development is one of my favorite things to see threads and comments about.

    Looking forward to more of this. Hope your project is coming along nicely.
  • 1
    @retoor I have a little real mode bootloader in the 512 byte boot sector which sets up unreal mode, calls the bios to read sectors of my kernel and jumps to it in high mem. The kernel then enables long mode, but that isn't working quite right yet :P

    I think I need to fully configure my interrupts first
  • 1
    @Wisecrack Slowly but surely :D

    This is more of a fun project so I don't think I will produce anything amazing, but my goal is a little unix-ish inspired 64-bit os with processes and virtual memory
  • 0
    @retoor Maybe in my next lifetime? :P
  • 0
    @retoor Surely I have enough karma.......
Add Comment