3 ms·

> Ever plugged in a GPU? How do you think the BIOS/EFI/GRUB/etc display things on the screen? That's because the BIOS is not an operating system--or at least

> Ever plugged in a GPU? How do you think the BIOS/EFI/GRUB/etc display things on the screen? That's because the BIOS is not an operating system--or at least used to not be. And it goes back to the CP/M architecture that's even older than the 1980's PC. Option ROMs are there for the BIOS and single-tasking "operating systems" that use it CP/M style. Modern operating systems don't need the layer there. I have a Guruplug (ARM platform) that boots Linux and what's in flash is U-Boot - a bootloader that loads Linux, the initrd, then it gets out of the way. The only reason why the PC platform can't work like this is because of ACPI. > Overwhelmingly what you think of as HW registers are actually mailbox interfaces to micro controllers running proprietary firmware. Oh I know. SATA is a communications interface (as was IDE, ATAPI, SCSI). USB is a communications interface. NVMe is a elaborate tagged/queued communications interface. Et cetera. I'm not sure why you are conflating CPU-facing hardware interface (registers) with anything that is physically peripheral side stuff except for this which I will address: I know a CPU I don't control and don't know the code it's running is on the other side of those links. That's fine--because it can't directly access my OS's RAM unless the OS allows DMA - and it's probably going to cause a device-level issue instead of a machine-level issue if there's a bug in that firmware. Not seeing the value add--other than saving some poor, poor Microsoft-aligned platform firmware developer's bit of time--of having to jump to a closed-source firmware routine to use those communications interfaces instead of letting the OS directly talk to them. > So, as I mentioned pretty much the entire HW docs for the RK3399 were released years ago, ... So what makes the PC platform avoid this mess is not the presence or absence of closed-source firmware running on the main CPUs, but simply the hardware platform itself being standardized. This is because people copied it from IBM. The BIOS was copied because DOS needed it, not because the hardware needed it other than a CPU requires ROM at it's initial boot address. There were well known addresses for each device, such as DMA channel 0/1, IDE channel 0/1, FDC 0/1, serial port 0/1/2/3, paralell port 0/1/2/3. I really want to know why we couldn't have a hardware standard for laptop power control interface instead of APM. The industry managed to settle on PCI in reaction to IBM's attempt to grab back the platform with MCA. PCI doesn't requre firmware, and it's registers to scan the bus are well known and standardized in hardware. So why did everyone say it was OK to hide the power-controlling hardware behind APM? DOS of course needed something like that but you had more than a couple commercial operating systems on the platform besides that (Xenix I think, OS/2 likely still kicking a bit, NT). Early 90's when APM started taking hold was also the time when Intel started to not publish certain things in its CPU manuals. Device trees should be easily obtainable from device datasheets. Overall the real problem with the ARM boards is an economy that values time to market and treat-your-first-X-customers-as-beta-testers over quality. Separate issue that we really should be unwilling to accept as an absolute requirement for unauditable code running on the same CPU my operating system is running on.

StillBored 5y ago
The option rom frequently is required to init the hardware so the OS can view something normal. Modern PC's aren't using 16-bit int services, rather UEFI GOP drivers sourced from option roms for early display, without which you can't interface with the machine until the OS starts. If you want something like a phone where you can't replace the OS, that is how one goes about it. Even uboot has noticed that standards matter as they slowly transform themselves into yet another UEFI firmware. I have a guruplug too, or rather an openrd, because all the guruplugs died. But that is 1980's PC level of simple HW, and its not SMP, doesn't support virtualization, or any power mgmt to speak of. The list of things it can't do is longer than the list of things you can do with it compared to a modern piece of HW. Modern PC's with ACPI aren't "standardized" outside of a few interfaces being used by the OS, that is my point. All those regulator drivers, clock controllers, pin muxing, I2C'ing, SPI'ing, to manage the platform is whatever the vendor put there in PC land (and arm land for that matter) is still there, only the OS doesn't have to worry about those details because it simply asks to power something on, and it happens, and some other processor takes over picking perf profiles and idling links/etc when needed. If there was a standard PMIC, wired up in a standard way it might make sense to attempt to use it, but there isn't. Instead its a bucket of parts wired up in every way imaginable. ACPI, doesn't dictate what is on the other side, it could be a SMM trap, or it could be a mgmt processor, or a BMC, or the function can be completely written in AML. That is the point, its just an OS API surface, it could just as well be a standardized pile of HW registers but that would remove the ability to run in cases where the vendor wants to save a penny and run everything on the main core as you suggest doing with DT. A large part of why you provide these interfaces is because having the main core waking up to fittle with some 100Khz SPI bus to flash a led is dumb, wastes power, and eats perf doing work that would be better handled with a small mgmt core. Your basic argument seems to be that you don't want the OS wasting cycles in the firmware, but your perfectly ok with the OS wasting even more cycles all the time doing these functions sub optimally in a kernel that doesn't understand the intricacies of power management on the most pwoer hungry core in the system. You seem to think ACPI is always just a SMM trap, and that isn't the case. The reason I conflate is its because in the case where the remote is a BMC/etc your effectively just poking a mailbox to get some other piece of hardware to do the work and those mailbox interfaces are no more standard than PMICs, so now you have thousands of them needed to talk to battery mgmt controllers, power/standby buttons, you name it. Instead of standardizing all that garbage, a software API was created. Its no different from openGL or any other standard except that it uses a bytecoded function call interface (ala openfirmware's forth). Do you hate openGL too because your game isn't fittling fake HW registers? And now that I point out what happens when a vendor just tosses those register maps you want over the wall you change the topic to how they are just creating beta level products while refusing to acknowledge that someone has to do the work. From the perspective of a vendor it costs a tiny fraction to have some closed source firmware that works across dozens of OS's and allows them to redesign their hardware vs hiring experts in a half dozen OSs to write piles of custom power mgmt code accessing dozens of drivers talking on dozens of SPI/I2C/mailbox/etc interfaces for a single machine. Its actually a little bit crazy that people in the arm space are trying this while simultaneously complaining about the HW vendors creating piles of patches that they can't get upstream so they build their own custom linux forks. Its the natural result of making the same claims your making. A vendor can either spend years fighting with kernel maintainers, or they can fork linux and ship it to their customers with a pile of patches that only work in linux. The middle ground is where a number of them have been going, its the rpi's proprietary mailbox interface that talks to the videocore to set the processor frequency. Multiply that mailbox by a few dozen SoC providers and you have the future of DT on arm and risc-v. In a decade or two they will end up standardizing the mailboxs and reinventing ACPI and openfirmware in order to support cross platform mailbox interfaces.

StillBored 5y ago

The option rom frequently is required to init the hardware so the OS can view something normal. Modern PC's aren't using 16-bit int services, rather UEFI GOP drivers sourced from option roms for early display, without which you can't interface with the machine until the OS starts. If you want something like a phone where you can't replace the OS, that is how one goes about it. Even uboot has noticed that standards matter as they slowly transform themselves into yet another UEFI firmware. I have a guruplug too, or rather an openrd, because all the guruplugs died. But that is 1980's PC level of simple HW, and its not SMP, doesn't support virtualization, or any power mgmt to speak of. The list of things it can't do is longer than the list of things you can do with it compared to a modern piece of HW. Modern PC's with ACPI aren't "standardized" outside of a few interfaces being used by the OS, that is my point. All those regulator drivers, clock controllers, pin muxing, I2C'ing, SPI'ing, to manage the platform is whatever the vendor put there in PC land (and arm land for that matter) is still there, only the OS doesn't have to worry about those details because it simply asks to power something on, and it happens, and some other processor takes over picking perf profiles and idling links/etc when needed. If there was a standard PMIC, wired up in a standard way it might make sense to attempt to use it, but there isn't. Instead its a bucket of parts wired up in every way imaginable. ACPI, doesn't dictate what is on the other side, it could be a SMM trap, or it could be a mgmt processor, or a BMC, or the function can be completely written in AML. That is the point, its just an OS API surface, it could just as well be a standardized pile of HW registers but that would remove the ability to run in cases where the vendor wants to save a penny and run everything on the main core as you suggest doing with DT. A large part of why you provide these interfaces is because having the main core waking up to fittle with some 100Khz SPI bus to flash a led is dumb, wastes power, and eats perf doing work that would be better handled with a small mgmt core. Your basic argument seems to be that you don't want the OS wasting cycles in the firmware, but your perfectly ok with the OS wasting even more cycles all the time doing these functions sub optimally in a kernel that doesn't understand the intricacies of power management on the most pwoer hungry core in the system. You seem to think ACPI is always just a SMM trap, and that isn't the case. The reason I conflate is its because in the case where the remote is a BMC/etc your effectively just poking a mailbox to get some other piece of hardware to do the work and those mailbox interfaces are no more standard than PMICs, so now you have thousands of them needed to talk to battery mgmt controllers, power/standby buttons, you name it. Instead of standardizing all that garbage, a software API was created. Its no different from openGL or any other standard except that it uses a bytecoded function call interface (ala openfirmware's forth). Do you hate openGL too because your game isn't fittling fake HW registers? And now that I point out what happens when a vendor just tosses those register maps you want over the wall you change the topic to how they are just creating beta level products while refusing to acknowledge that someone has to do the work. From the perspective of a vendor it costs a tiny fraction to have some closed source firmware that works across dozens of OS's and allows them to redesign their hardware vs hiring experts in a half dozen OSs to write piles of custom power mgmt code accessing dozens of drivers talking on dozens of SPI/I2C/mailbox/etc interfaces for a single machine. Its actually a little bit crazy that people in the arm space are trying this while simultaneously complaining about the HW vendors creating piles of patches that they can't get upstream so they build their own custom linux forks. Its the natural result of making the same claims your making. A vendor can either spend years fighting with kernel maintainers, or they can fork linux and ship it to their customers with a pile of patches that only work in linux. The middle ground is where a number of them have been going, its the rpi's proprietary mailbox interface that talks to the videocore to set the processor frequency. Multiply that mailbox by a few dozen SoC providers and you have the future of DT on arm and risc-v. In a decade or two they will end up standardizing the mailboxs and reinventing ACPI and openfirmware in order to support cross platform mailbox interfaces.