Unfortunately it isn't that simple. One of the comments on the youtube video gets to the heart of the matter:
> I don't see how this might be changed. Most of those little red circles are not just "tiny computers" but also different implementers in different companies, all trying to protect their little fiefdom against their customers
There are of course initiatives like libreboot/freeboot/whatever, and efforts to reverse-engineer the firmware of microcontrollers in peripherals, and there exists fully documented hardware such as the Raspberry Pi 4 (I think?), but even with full documentation, it's incredibly hard to write custom firmware, and the benefit is very slim (better security perhaps?)
That actually goes to the heart of the problem, modern SOCs are basically proprietary components gobbled together on a chip with some internal networking/wiring that each come with their own software that does a lot of stuff before even getting around to booting Linux.
The problem is the proprietary nature of this stuff and the fact that a lot of it is outside of the scope of scrutiny that goes into Linux. It's held together with what basically amounts to glorified duct tape. It's complicated. It has weird failure modes and occasionally this stuff has expensive issues. Like for example security issues.
Very relevant if you want to build an open source phone platform or laptop. Not impossible; but it requires addressing a few things. Like connecting to a 5G network without relying on Qualcomm's proprietary software and hardware.
The real solution is not merely integrating these things as is and trying to reverse engineer them but engineer them from the ground up to work together and make sense together. That larger, open operating system does not really exist. And many proprietary equivalents on the market right now have an emergent/accidental design rather than something that was designed from the ground up.
When programmable shaders were introduced in GeForce 3 (2001), nobody really understood what to do with them. The consensus was that it’s incredibly hard to write custom shaders. OpenGL consortium refused to support shaders for almost a decade (GLSL 1.0 released in 2008), that’s one of the reasons of the success of Direct3D https://softwareengineering.stackexchange.com/a/88055
Yet look at them after 20 years of evolution. People no longer coding shaders in assembly, we have quite a few higher-level languages for them. People have built better APIs to interface with programmable GPUs, both low level close to metal (D3D12, Metal, Vulkan) and high-level (CUDA, TensorFlow, game engines). People built debuggers and profilers for these shaders. Overall, people embraced programmable GPUs, leaned to use them, and the results are amazing. Visual quality of games and other real-time 3D skyrocketed, despite the increase of pixel count and density in the displays.
I can see how the same path is possible for the rest of the programmable chips and pieces inside modern computers.
> and the benefit is very slim
Better products in very broad sense. For instance, when idle, a smartphone OS could power off not just the screen, but also CPU, RAM, and a few other components, and downscale itself to the slowest and the most power efficient core in the system.
> when idle, a smartphone OS could power off not just the screen, but also CPU, RAM, and a few other components, and downscale itself to the slowest and the most power efficient core in the system
Don't the proprietary versions already do that, though?
I don’t think they do. They switch to very low power states, on big.little systems they power off half of the CPU cores. But some CPU cores, and all of the RAM are still powered, the main OS doesn’t have other place to live.
With different OS design it might be possible to power off more components of the phone when idle, while being able to wake up fast enough.
> I don't see how this might be changed. Most of those little red circles are not just "tiny computers" but also different implementers in different companies, all trying to protect their little fiefdom against their customers
There are of course initiatives like libreboot/freeboot/whatever, and efforts to reverse-engineer the firmware of microcontrollers in peripherals, and there exists fully documented hardware such as the Raspberry Pi 4 (I think?), but even with full documentation, it's incredibly hard to write custom firmware, and the benefit is very slim (better security perhaps?)