4 ms·

When technical debt strangles your entire business. "We'll fix this next release"

mnd999 4y ago
It’s not technical debt, it’s a feature. Being able to boot and run software from decades ago has served them well in the past.
- mjg59 4y ago
  That's an argument for including support for real mode, rather than for coming up in it. Modern systems booting legacy software are already transitioning into protected mode to run the UEFI stack, and then switching back to real mode before passing control to the Compatibility Services Module.
  - LoganDark 4y ago
    > That's an argument for including support for real mode, rather than for coming up in it. Not really. You have to come up in it to boot software that expects to already be in it.
    - mjg59 4y ago
      No, firmware needs to hand off in the state the software you're booting needs. That says nothing about the mode the CPU needs to be in when it starts running firmware.
      - LoganDark 4y ago
        > No, firmware needs to hand off in the state the software you're booting needs. That says nothing about the mode the CPU needs to be in when it starts running firmware. This assumes that "firmware" doesn't count against backwards compatibility, which isn't necessarily the case. Maybe Intel (or AMD) doesn't have a 100% monopoly on firmware to be confident enough that the CPU mode is an implementation detail. Or maybe some customers do indeed run their own "firmware" (maybe embedded?). No way to be sure.
        mjg59 4y ago
        Firmware needs to know CPU-specific details (it needs to be able to program the memory controller, for instance), so skipping (or inverting) the real mode to protected mode code in the firmware is just another step in porting to a new platform.
        LoganDark 4y ago
        Are we talking about the same "firmware" here? If you're talking about firmware loaded directly onto the CPU (like microcode updates are), that runs even before the motherboard gets to do anything, then the mode the CPU starts in can only be observed after that point anyway, so for all we know it probably could already be implementing your idea without anyone noticing. I have objections to changing the way the CPU observably starts (i.e. mode in which the BIOS or bootloader starts in).
        mjg59 4y ago
        I'm talking about the firmware on the motherboard. Your BIOS is CPU-specific - if a future CPU changes the default CPU mode, you simply update your BIOS code to match while you're doing the rest of the work you need to do for that BIOS to run on the new CPU. If the BIOS expects to run in real mode (I'm not aware of any modern firmware that does, but) then you just add some code to switch back to real mode. Otherwise, you probably just delete the code that currently transitions from real mode to protected mode. That doesn't preclude you switching back to real mode if the bootloader expects that.
        LoganDark 4y ago
        > I'm talking about the firmware on the motherboard. Then that's what I thought, yeah. I don't see why you're explaining how your idea would be implemented; I'm rather saying that implementing it in that way might be prohibitive if Intel or AMD still have customers that expect the CPU to act a certain way. And these customers aren't necessarily standard desktop/laptop motherboards. In other words, changing "what mode the CPU starts in" would be a big and observable breaking change and not necessarily just an implementation detail that can be magically worked around by firmware updates like you describe.
jeroenhd 4y ago
I believe one of the Playstations or Xboxes run an AMD64 chip that does away with most of the legacy stuff. I read about it in an article about getting Linux to run on a homebrewed console. If I remember correctly, this required hacking around a lot of assumptions in the Linux kernel. I imagine the Windows kernel won't be that different. If Intel or AMD bring out a CPU that doesn't support any operating system in use today (or any UEFI firmware/BIOS implementation for that matter) they wouldn't be selling many chips. Many vendors outsource their driver update tools to third parties, which in turn use tiny operating systems like FreeDOS to flash firmware onto devices; it'd suck for them to end up needing to rebuild their operating systems. Likewise, a dedicated GPU also plays a role in the boot process, and taking away the legacy assumptions of the GPU boot ROM will probably also require flashing any consumer graphics card with new firmware as well. Then there's PXE network boot, which often still relies on separate firmware, which also brings its own expectations about the state of the CPU. Bringing up a modern CPU is going to be a terrible hack whatever you do. I don't see why Intel would need to re-engineer their entire boot process. The current system is hacky as hell but it works and it doesn't require much more work than putting the firmware and microcode images in the right place. I seriously doubt that redoing their entire boot process and guiding everyone from motherboard manufacturers to driver programmers on how to use the new system (and to iron out the bugs in the new process) will be more cost effective than letting all the old code work like it does today. Very rarely do complete rewrites make any business sense.
- mjg59 4y ago
  GPU option ROMs no longer make assumptions about legacy setup - UEFI option ROMs are executed in either 32-bit or 64-bit mode, and there's no need to implement any of the legacy VGA compatibility. Same for PXE, which just hooks into the UEFI network stack rather than having to deal with anything legacy. No OS assumes real-mode for the boot processor at this point. If you boot Linux on a UEFI system you'll jump straight into the kernel in 64-bit protected mode. The only time real mode comes into play is in the bringup of other CPUs (which is something that can be ignored now that ACPI specifies an alternative) and ACPI resume (which isn't relevant on systems that use S0ix rather than S3), so you could absolutely ship an x86 CPU that didn't support real mode and all you'd have to do is modify the firmware entry code. Modern operating systems would Just Work, as would hardware option ROMs. (And enough systems no longer ship with CSMs that people aren't using FreeDOS for firmware updates any more - it's either Linux or a UEFI executable)

It’s not technical debt, it’s a feature. Being able to boot and run software from decades ago has served them well in the past.

mjg59 4y ago
That's an argument for including support for real mode, rather than for coming up in it. Modern systems booting legacy software are already transitioning into protected mode to run the UEFI stack, and then switching back to real mode before passing control to the Compatibility Services Module.
- LoganDark 4y ago
  > That's an argument for including support for real mode, rather than for coming up in it. Not really. You have to come up in it to boot software that expects to already be in it.
  - mjg59 4y ago
    No, firmware needs to hand off in the state the software you're booting needs. That says nothing about the mode the CPU needs to be in when it starts running firmware.
    - LoganDark 4y ago
      > No, firmware needs to hand off in the state the software you're booting needs. That says nothing about the mode the CPU needs to be in when it starts running firmware. This assumes that "firmware" doesn't count against backwards compatibility, which isn't necessarily the case. Maybe Intel (or AMD) doesn't have a 100% monopoly on firmware to be confident enough that the CPU mode is an implementation detail. Or maybe some customers do indeed run their own "firmware" (maybe embedded?). No way to be sure.
      - mjg59 4y ago
        Firmware needs to know CPU-specific details (it needs to be able to program the memory controller, for instance), so skipping (or inverting) the real mode to protected mode code in the firmware is just another step in porting to a new platform.
        LoganDark 4y ago
        Are we talking about the same "firmware" here? If you're talking about firmware loaded directly onto the CPU (like microcode updates are), that runs even before the motherboard gets to do anything, then the mode the CPU starts in can only be observed after that point anyway, so for all we know it probably could already be implementing your idea without anyone noticing. I have objections to changing the way the CPU observably starts (i.e. mode in which the BIOS or bootloader starts in).
        mjg59 4y ago
        I'm talking about the firmware on the motherboard. Your BIOS is CPU-specific - if a future CPU changes the default CPU mode, you simply update your BIOS code to match while you're doing the rest of the work you need to do for that BIOS to run on the new CPU. If the BIOS expects to run in real mode (I'm not aware of any modern firmware that does, but) then you just add some code to switch back to real mode. Otherwise, you probably just delete the code that currently transitions from real mode to protected mode. That doesn't preclude you switching back to real mode if the bootloader expects that.
        LoganDark 4y ago
        > I'm talking about the firmware on the motherboard. Then that's what I thought, yeah. I don't see why you're explaining how your idea would be implemented; I'm rather saying that implementing it in that way might be prohibitive if Intel or AMD still have customers that expect the CPU to act a certain way. And these customers aren't necessarily standard desktop/laptop motherboards. In other words, changing "what mode the CPU starts in" would be a big and observable breaking change and not necessarily just an implementation detail that can be magically worked around by firmware updates like you describe.

jeroenhd 4y ago

I believe one of the Playstations or Xboxes run an AMD64 chip that does away with most of the legacy stuff. I read about it in an article about getting Linux to run on a homebrewed console. If I remember correctly, this required hacking around a lot of assumptions in the Linux kernel. I imagine the Windows kernel won't be that different. If Intel or AMD bring out a CPU that doesn't support any operating system in use today (or any UEFI firmware/BIOS implementation for that matter) they wouldn't be selling many chips. Many vendors outsource their driver update tools to third parties, which in turn use tiny operating systems like FreeDOS to flash firmware onto devices; it'd suck for them to end up needing to rebuild their operating systems. Likewise, a dedicated GPU also plays a role in the boot process, and taking away the legacy assumptions of the GPU boot ROM will probably also require flashing any consumer graphics card with new firmware as well. Then there's PXE network boot, which often still relies on separate firmware, which also brings its own expectations about the state of the CPU. Bringing up a modern CPU is going to be a terrible hack whatever you do. I don't see why Intel would need to re-engineer their entire boot process. The current system is hacky as hell but it works and it doesn't require much more work than putting the firmware and microcode images in the right place. I seriously doubt that redoing their entire boot process and guiding everyone from motherboard manufacturers to driver programmers on how to use the new system (and to iron out the bugs in the new process) will be more cost effective than letting all the old code work like it does today. Very rarely do complete rewrites make any business sense.

mjg59 4y ago
GPU option ROMs no longer make assumptions about legacy setup - UEFI option ROMs are executed in either 32-bit or 64-bit mode, and there's no need to implement any of the legacy VGA compatibility. Same for PXE, which just hooks into the UEFI network stack rather than having to deal with anything legacy. No OS assumes real-mode for the boot processor at this point. If you boot Linux on a UEFI system you'll jump straight into the kernel in 64-bit protected mode. The only time real mode comes into play is in the bringup of other CPUs (which is something that can be ignored now that ACPI specifies an alternative) and ACPI resume (which isn't relevant on systems that use S0ix rather than S3), so you could absolutely ship an x86 CPU that didn't support real mode and all you'd have to do is modify the firmware entry code. Modern operating systems would Just Work, as would hardware option ROMs. (And enough systems no longer ship with CSMs that people aren't using FreeDOS for firmware updates any more - it's either Linux or a UEFI executable)