That's not quite true and your bias is showing. The company behind Loongarch is reasonably friendly to FOSS and most of their LA64 changes (to Linux, llvm, binutils, gcc, etc) are upstreamed in a timely fashion. As for the chipset, kernel drivers are all open source although not all have been accepted upstream. I have personally been maintaining the out-of-tree Linux drm driver for their onboard gpu chip and it's available on github https://github.com/cl91/linux/tree/gsgpu-devel. If you have a barebone 3A6000+7A2000 setup, as far as I know the only closed source component needed is their userspace mesa driver for the onboard gpu.
The funny thing is, the boot processes on Windows and Linux are remarkably similar, and have always been.
On Windows, firmware loads bootloader, bootloader loads ntoskrnl (NT kernel), ntoskrnl starts first user process smss.exe, smss starts security subsystem lsass.exe, lsass starts winlogon.exe, winlogon logs user on and starts the shell, explorer.exe
On Linux, bootloader loads vmlinuz (kernel), vmlinuz starts first user process (init), init starts display manager (eg gdm), gdm
logs user on and starts another copy of the X server and launches user's favorite window manager.
These have essentially stayed the same since the first NT 3.1 release and Red hat 0.9. I'm not familiar with Mac OS X or other Unices but I imagine they aren't that different. Modern desktop OS design has essentially converged to a point where there is no fundamental difference between any modern desktop OSes, because after all they are all trying to solve more or less the exact same set of problems. When a user inserts a flash drive he expects it to be mounted automatically (you can't honestly expect most end users to type in a sudo command to access his flash drive, can you), and this in fact requires careful coordinations from a ton of system components to implement securely, because mounting a filesystem is a privileged operation (you certainly don't want the end user to be able to unmount the root filesystem do you, but he should be able to unmount his flash drive). This is why things like polkit are necessary. People in Linux land love to complain about dbus --- oh it's turning Linux into the big evil M$ Windowz --- but how do you propose to solve the problem of two talking processes having to send objects between each other? With plan9's 9p? How about authentication? How do I make sure the process I'm talking to is really the process I think it is? If you try to solve all these problems, you end up with something that's essentially no different from dbus.
is UEFI.