5 ms·

Can anyone give me an idea how much different this would be for 64bit? Do I just change the nasm directive to `bits 64`?

by aaren 12y ago

breadbox 12y ago
... and the gcc flag would need to be -m64. But I don't think it's this easy. If grub is in 32-bit mode when it hands you control, I would think you would need to switch to Long Mode before you could execute 64-bit code. So your entry point would still have to be a 32-bit program, which would set up everything necessary for Long Mode, make the switch, and then load and execute the 64-bit part of your program.
akiselev 12y ago
According to [1] in the section on initializing from reset, Intel CPUs boot to one of three modes: * Read mode has 1MB of memory and is 16 bit. * Flat protected mode which is 32 bit and takes interrupts * Segmented Protected mode which is 64 bit (w/ 32 bit emulation) and is used by operating systems to protect memory In this tutorial, your boot mode depends on what GRUB boots you in. [1] http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/minimal-intel-architecture-boot-loader-paper.pdf http://www.intel.com/content/dam/www/public/us/en/documents/...
exDM69 12y ago
> Can anyone give me an idea how much different this would be for 64bit? Do I just change the nasm directive to `bits 64`? A lot different. You can see the boot code of my x86_64 hobby kernel project [1]. The reason is that GRUB/Multiboot protocol is actually doing most of the machine initialization, but it can only set up 32 bit mode. 64 bit mode is missing partly because standardizing the Multiboot protocol is dragging behind, partly because there's no one correct way to do this as you can't have identity mapped memory in 64 bit mode (unlike 32 bit mode). If you read the OSDev wiki, you can find examples of doing machine initialization "from scratch", ie. after the PC BIOS (or UEFI). This involves arcane details about the x86 machine like setting up something called the A20 line (which was a hack that allows to have 1 megabyte of memory - utilizing a spare pin from the keyboard controller!), etc. Dealing with this shit is not time well spent. (UEFI is a lot easier in some ways, harder in others) This means that the boot code of your kernel must set up long mode, create an initial page table for virtual memory, etc. Here's my limited 64 bit boot code that sets up one 2 megabyte page [2]. Going to 64 bit mode is not that much more code, but it will make kernel development more painful. In particular, switching CPU modes messes up the GDB debugger which must be patched to work at all. And there's a bit more work involved in all the little things that come with it. So for educational purposes it would make more sense to stick to 32 bit mode than deal with the nitty gritty details of 64 bit long mode. [1] https://github.com/rikusalminen/danjeros https://github.com/rikusalminen/danjeros [2] https://github.com/rikusalminen/danjeros/blob/master/src/arch/x86_64/boot/start.s#L57 https://github.com/rikusalminen/danjeros/blob/master/src/arc...
- e12e 12y ago
  This makes me really sad. 32bit mode x86 assembly is such a mess compared to amd64 -- I guess it's a good excuse to work with qemu and arm, if nothing else ;-)
  - TallGuyShort 12y ago
    On the topic of ARM, does anybody know of a similar example like this for ARM? One that just shows you how to pass control to C and do some basic I/O?
    - TallGuyShort 12y ago
      Too late to edit my post, but I eventually found this: http://wiki.osdev.org/ARM_Integrator-CP_Bare_Bones http://wiki.osdev.org/ARM_Integrator-CP_Bare_Bones. I haven't tried it out yet as I'm still getting the cross-compiler toolchain together (doesn't seem to be part of OpenSUSE 12, at least not an obvious part), and it's not as well explained, but still the best I've found.
    - exDM69 12y ago
      It would be difficult to write an article similar to this on ARM, because there's no equivalent of what the PC "standard" is to x86 for ARM. Every ARM board and SoC have different boot protocols and peripheral devices. There are some bootloaders that are commonly used in ARM, such as U-Boot. Perhaps that could be used to get started.

Can anyone give me an idea how much different this would be for 64bit? Do I just change the nasm directive to `bits 64`?

by aaren 12y ago

Can anyone give me an idea how much different this would be for 64bit? Do I just change the nasm directive to `bits 64`?

breadbox 12y ago

... and the gcc flag would need to be -m64. But I don't think it's this easy. If grub is in 32-bit mode when it hands you control, I would think you would need to switch to Long Mode before you could execute 64-bit code. So your entry point would still have to be a 32-bit program, which would set up everything necessary for Long Mode, make the switch, and then load and execute the 64-bit part of your program.

akiselev 12y ago

According to [1] in the section on initializing from reset, Intel CPUs boot to one of three modes: * Read mode has 1MB of memory and is 16 bit. * Flat protected mode which is 32 bit and takes interrupts * Segmented Protected mode which is 64 bit (w/ 32 bit emulation) and is used by operating systems to protect memory In this tutorial, your boot mode depends on what GRUB boots you in. [1] http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/minimal-intel-architecture-boot-loader-paper.pdf http://www.intel.com/content/dam/www/public/us/en/documents/...

exDM69 12y ago

> Can anyone give me an idea how much different this would be for 64bit? Do I just change the nasm directive to `bits 64`? A lot different. You can see the boot code of my x86_64 hobby kernel project [1]. The reason is that GRUB/Multiboot protocol is actually doing most of the machine initialization, but it can only set up 32 bit mode. 64 bit mode is missing partly because standardizing the Multiboot protocol is dragging behind, partly because there's no one correct way to do this as you can't have identity mapped memory in 64 bit mode (unlike 32 bit mode). If you read the OSDev wiki, you can find examples of doing machine initialization "from scratch", ie. after the PC BIOS (or UEFI). This involves arcane details about the x86 machine like setting up something called the A20 line (which was a hack that allows to have 1 megabyte of memory - utilizing a spare pin from the keyboard controller!), etc. Dealing with this shit is not time well spent. (UEFI is a lot easier in some ways, harder in others) This means that the boot code of your kernel must set up long mode, create an initial page table for virtual memory, etc. Here's my limited 64 bit boot code that sets up one 2 megabyte page [2]. Going to 64 bit mode is not that much more code, but it will make kernel development more painful. In particular, switching CPU modes messes up the GDB debugger which must be patched to work at all. And there's a bit more work involved in all the little things that come with it. So for educational purposes it would make more sense to stick to 32 bit mode than deal with the nitty gritty details of 64 bit long mode. [1] https://github.com/rikusalminen/danjeros https://github.com/rikusalminen/danjeros [2] https://github.com/rikusalminen/danjeros/blob/master/src/arch/x86_64/boot/start.s#L57 https://github.com/rikusalminen/danjeros/blob/master/src/arc...

e12e 12y ago
This makes me really sad. 32bit mode x86 assembly is such a mess compared to amd64 -- I guess it's a good excuse to work with qemu and arm, if nothing else ;-)
- TallGuyShort 12y ago
  On the topic of ARM, does anybody know of a similar example like this for ARM? One that just shows you how to pass control to C and do some basic I/O?
  - TallGuyShort 12y ago
    Too late to edit my post, but I eventually found this: http://wiki.osdev.org/ARM_Integrator-CP_Bare_Bones http://wiki.osdev.org/ARM_Integrator-CP_Bare_Bones. I haven't tried it out yet as I'm still getting the cross-compiler toolchain together (doesn't seem to be part of OpenSUSE 12, at least not an obvious part), and it's not as well explained, but still the best I've found.
  - exDM69 12y ago
    It would be difficult to write an article similar to this on ARM, because there's no equivalent of what the PC "standard" is to x86 for ARM. Every ARM board and SoC have different boot protocols and peripheral devices. There are some bootloaders that are commonly used in ARM, such as U-Boot. Perhaps that could be used to get started.