3 ms·

Has it? What is the difference from the perspective of a generic OS whether the disk controller is provided by BrokenHWCo and plugged into an ISA slot, or its p

Has it? What is the difference from the perspective of a generic OS whether the disk controller is provided by BrokenHWCo and plugged into an ISA slot, or its provided by SoCInc and glued to a AXI bus in the SoC? In both cases an engineer has to get involved to describe the address/interrupt/configuration mechanism to the OS, and likely provide a driver or set of tweaks for every single OS in existence that might ever run on the platform. The point of the standardization is that SoCInc adds a device that behaves like one of the standard device in the ecosystem (say NVMe, AHCI or SDHCI for a disk) does the low level platform specific configuration in the firmware and hands the OS something that looks to be a standard PCI, ACPI, USB, or whatever device. Then it can boot one of the dozen OS's or hypervisors the end customer might be interested in using the drivers they already have built in. The onboard mgmt processor then does all the realtime power/perf monitoring in response to course grained OS/ACPI requests and custom code which is aware of SoC specific load/bus utilization/thermal/etc values. So, all this ends up being an engineering tradeoff, is it worth while to attempt to cram ones application into a ESP8266 (its after-all quite capable and has excellent wifi/web style interfaces built in) or run a full blown linux kernel/etc. By the time your running linux, your already talking about a pretty massive system just to get to the capabilities of that ESP8266, so the overhead of these standards is quite trivial. They were after all invented for machines with performance and resource requirements closer to that ESP8266 than anything in the entire Cortex-A line. The choice to dedicate engineers at SocInc to duplicate the efforts of those at Microsoft, or Canonical to shave frontend engineering costs off is likely a very poor choice. As I mentioned above, its probably a large reason why so many IoT and Android devices don't get updates after a year or two. Those engineers are off writing new autoexec.bat files for the latest SoC's. Dedicating them to fixing security holes and bugs in the Os for the next 20 years for every SoC shipped costs a lot of money. There is very nearly 0 value add to hiring an engineer to design an interrupt controller, another to write a driver for every OS in existence for it, and another for 20 years to maintain the result. For what? Lower interrupt latency? To save a thousand transistors or a license fee? If your customer doesn't have some very specific use case for that interrupt controller the value is likely negative.

monocasa 6y ago
They're not spending 20 years supporting it though. They're spending six months and then moving all of their engineers to the next chip. An important customer might be able to get them to get a couple of interns to look at something, but even that's like pulling teeth. Interrupt controllers take made a couple weeks to design and write a driver for from my experience. Round up and call it a man month. It doesn't take a lot of units sold for that to be cheaper than licensing an IP core.
- StillBored 6y ago
  I designed and wrote an entire CPU in Verilog in a couple weeks in college. I suspect there is a large difference between wired OR interrupts and something that can inform all the arm exception levels, IPI's, direct injection into VM's, etc. AKA all the things required to run Linux on a modern Arm core in a reasonable fashion.
  - monocasa 6y ago
    No, like I've wrote shipping to customers interrupt controllers, not a school project. The meat of most of what you're talking about happens in the CPU cores. The interrupt controller just exports "this is the highest priority interrupt" signal based on some signals input, and some interrupt signals that can be triggered off of a memory write (IPIs). The shit's really almost hello world HDL. VM passthrough is just a parrallel set of comparison logic and another "this is the highest priority signal" to the CPU core. But you didn't address the important part, that your calculus is wrong on the support time frames. They aren't supporting these things for 20 years. And I guarantee you they've cranked the numbers, so much of these designs are focused at taking a fraction of a penny off of each shipped unit. Adding to that, the underlying piece is that they don't care about the bootloader being nice, and 'they' is several entities with their own goals and requirements. The chips in SBCs are almost entirely leftovers. They made too much for some big customer that for whatever reason didn't use the whole batch, and went to sell them off at fire sale prices. Then some incredibly cost conscious shop buys them up, sticks them on cost reduced dev boards with the custom kernel and calls it a day. The chip company doesn't care because the major customers don't care. The major customers (ie. the integrator for who the chip was designed in the first place) don't care because they just want a Linux kernel booting, and don't care how that happens. The SBC customer doesn't care because they're already running on such low margins they can't afford to do anything to software as it is.

monocasa 6y ago

They're not spending 20 years supporting it though. They're spending six months and then moving all of their engineers to the next chip. An important customer might be able to get them to get a couple of interns to look at something, but even that's like pulling teeth. Interrupt controllers take made a couple weeks to design and write a driver for from my experience. Round up and call it a man month. It doesn't take a lot of units sold for that to be cheaper than licensing an IP core.

StillBored 6y ago
I designed and wrote an entire CPU in Verilog in a couple weeks in college. I suspect there is a large difference between wired OR interrupts and something that can inform all the arm exception levels, IPI's, direct injection into VM's, etc. AKA all the things required to run Linux on a modern Arm core in a reasonable fashion.
- monocasa 6y ago
  No, like I've wrote shipping to customers interrupt controllers, not a school project. The meat of most of what you're talking about happens in the CPU cores. The interrupt controller just exports "this is the highest priority interrupt" signal based on some signals input, and some interrupt signals that can be triggered off of a memory write (IPIs). The shit's really almost hello world HDL. VM passthrough is just a parrallel set of comparison logic and another "this is the highest priority signal" to the CPU core. But you didn't address the important part, that your calculus is wrong on the support time frames. They aren't supporting these things for 20 years. And I guarantee you they've cranked the numbers, so much of these designs are focused at taking a fraction of a penny off of each shipped unit. Adding to that, the underlying piece is that they don't care about the bootloader being nice, and 'they' is several entities with their own goals and requirements. The chips in SBCs are almost entirely leftovers. They made too much for some big customer that for whatever reason didn't use the whole batch, and went to sell them off at fire sale prices. Then some incredibly cost conscious shop buys them up, sticks them on cost reduced dev boards with the custom kernel and calls it a day. The chip company doesn't care because the major customers don't care. The major customers (ie. the integrator for who the chip was designed in the first place) don't care because they just want a Linux kernel booting, and don't care how that happens. The SBC customer doesn't care because they're already running on such low margins they can't afford to do anything to software as it is.