Is this any simpler on ARM?
Writing a BIOS bootloader for 64-bit mode from scratch
11–20 of 82 posts
Re: Writing a BIOS bootloader for 64-bit mode from scratch
#12Earlier quoted context omitted.
BIOS is deprecated. All of its functionality on new motherboards is basically emulated via the UEFI; and it's certainly not being extended upon. Deprecated doesn't mean deleted, it just means "no longer updated/developed with a goal towards removal".
This killed FreeDOS (and presumably all the other *DOS as well) on modern hardware unfortunately. It was fun as long as it lasted. I do not know what the next-best single-user, single-process, non-bloated OS would be to run on modern hardware that still has some reasonably modern software and can be used for distraction-free (hobby) development the way FreeDOS could.
Linux in single user mode
Re: Writing a BIOS bootloader for 64-bit mode from scratch
#13Does this boot procedure work with EFI/UEFI ? If so, does UEFI supervisor emulate swithing real/protected/long modes or does it go in real hardware ?
No. UEFI firmware creates a completely different environment for a UEFI bootloader than the legacy BIOS environment (real-address mode). The UEFI firmware enters 64-bit long mode directly on modern systems, and sets up a flat memory model GDT, as well as identity-mapped paging.
I've written about creating a UEFI bootloader (for my hobby OS) here: https://0xc0ffee.netlify.app/osdev/05-bootloader-p1.html
Re: Writing a BIOS bootloader for 64-bit mode from scratch
#14All to me entirely unnecessary steps required to get the CPU into the correct
mode is astounding.
They all seem to be steps needed for backwards compatibility.
Could Intel just provide a flag, command, to start in the right mode from the beginning.
Or just remove all the backwards compatibility.
I think I remember doing some research and ARM64 has some of the same issues.
Are there any CPUs that are designed from scratch as 64 bit it will not have any need for backwards compatibility and would enter the required state by default?
I guess sthat was the goal / design of Itanium?
are made to start in the desired 64 bit state from th
Re: Writing a BIOS bootloader for 64-bit mode from scratch
#15All to me entirely unnecessary steps required to get the CPU into the correct mode is astounding. They all seem to be steps needed for backwards compatibility. Could Intel just provide a flag, command, to start in the right mode from the beginning. Or just remove all the backwards compatibility. I think I remember doing some research and ARM64 has some of the same issues. Are there any CPUs that are designed from scr…
UEFI exists. You just put a Windows-like binary in a folder on a partition and it runs in a hosted environment in 64-bit mode. And of course there's countless bootloaders that can take care of all this for you too.
Re: Writing a BIOS bootloader for 64-bit mode from scratch
#16All to me entirely unnecessary steps required to get the CPU into the correct mode is astounding. They all seem to be steps needed for backwards compatibility. Could Intel just provide a flag, command, to start in the right mode from the beginning. Or just remove all the backwards compatibility. I think I remember doing some research and ARM64 has some of the same issues. Are there any CPUs that are designed from scr…
This is what Intel's proposed X86S [0] is designed for.
> X86S is a legacy-reduced-OS ISA that removes outdated execution modes and operating system ISA.
> The presence of the X86S ISA is enumerated by a single, main CPUID feature LEGACY_REDUCED_ISA in CPUID 7.1.ECX[2] which implies all the ISA removals described in this document. A new, 64-bit “start-up” interprocessor interrupt (SIPI) has a separate CPUID feature flag.
[0] https://cdrdv2.intel.com/v1/dl/getContent/776648 [pdf warning]
Re: Writing a BIOS bootloader for 64-bit mode from scratch
#17Earlier quoted context omitted.
This killed FreeDOS (and presumably all the other *DOS as well) on modern hardware unfortunately. It was fun as long as it lasted. I do not know what the next-best single-user, single-process, non-bloated OS would be to run on modern hardware that still has some reasonably modern software and can be used for distraction-free (hobby) development the way FreeDOS could.
Linux in single user mode
That's still multi-process though, there's an awful lot of background tasks running in pretty much every non-fossil kernel version, not to mention userspace daemons (udev, dbus, dhcp) without which most normal userspace stuff doesn't even work.
Re: Writing a BIOS bootloader for 64-bit mode from scratch
#18The 80286 has the Machine Status Word (MSW), a 16 bit register. The 80386 expands this to CR0, a 32 bits register. Then 64 bit long mode adds the EFER MSR and expands CR0 to 64 bits. But even today only 11 bits of CR0 are in use and EFER has 8 active bits. I wonder why intel/AMD did not simply use the free bits of the existing register, and made that decision twice?
Re: Writing a BIOS bootloader for 64-bit mode from scratch
#19Earlier quoted context omitted.
Linux in single user mode
That's still multi-process though, there's an awful lot of background tasks running in pretty much every non-fossil kernel version, not to mention userspace daemons (udev, dbus, dhcp) without which most normal userspace stuff doesn't even work.
None of that exists in single user. When you say init=/bin/foo, then that's it, the only process is /bin/foo.
Re: Writing a BIOS bootloader for 64-bit mode from scratch
#20Earlier quoted context omitted.
That's still multi-process though, there's an awful lot of background tasks running in pretty much every non-fossil kernel version, not to mention userspace daemons (udev, dbus, dhcp) without which most normal userspace stuff doesn't even work.
None of that exists in single user. When you say init=/bin/foo, then that's it, the only process is /bin/foo.
/bin/foo is the initial process. It can fork and/or exec other processes, right?