4 ms·

Heh. Device Tree only deals with a fraction of the problem. Here's what I think would help: (warning: lots of work!) 1. Large database of free peripherals and

Heh. Device Tree only deals with a fraction of the problem. Here's what I think would help: (warning: lots of work!) 1. Large database of free peripherals and foundational blocks. Not just UARTs and SATA controllers, but also network interconnects (crossbar), SDRAM controllers, and all the other bits that go into a modern System-On-Chip (SoC). Power management is a huge pain in general, and is widely different among chip families even from the same vendor. 1.A. Obviously, the above implies a decent set of open-source drivers for multiple operating systems for the peripherals. At the very least, you need support for a bootloader, a real-time OS, and Linux. Preferably with no binary blobs. 2. A standard for enumeration of these on-chip peripherals. There should be a way to query the chip itself to see what is included in the SoC, what device addresses they have, what options are enabled (like how many interrupts), and how the peripheral lines (if any) are connected (IO mapping). 3. Some widely-accepted standard for storing the board configuration as well. This could just be a I2C EEPROM, but it has to have a listing of everything connected to the SoC and how. This I2C is mapped to these pins, and has this accelerometer connected at this I2C address. And all the hardware manufacturers (who produce the boards) have to be convinced this is a good idea to have this extra cost (and space) built into their products. Only after all that would you have a fighting chance to boot a relatively generic kernel and have it actually run. And then have a fighting chance to have the ability for the end-user to upgrade the software after the manufacturer has ceased support. The cross-platform situation with PCs is light-years ahead of where we are in the embedded space.

cjbprime 9y ago
Step 3 is often achieved by having the firmware append a device tree blob to the kernel which contains all of the board setup. I think it's pretty widely adopted?
- ansible 9y ago
  Yes, it is headed in that direction. There's more work needed in areas like uniform conventions for configuring peripheral pins and such, in my opinion. And then there's clock configuration, which is kind of a mess, because everything is hooked up differently on different SoCs that I've seen. It would also be nice if vendors always shipped up-to-date device tree source files for any board they ship.
throwaway613834 9y ago
For those of us who don't know what is involved in power management, would you mind giving a quick explanation of what it involves and why it's painful? What power is there even to manage unless you want to put the computer to sleep or shut it down? Or are those the sole things your are referring to?
- cjbprime 9y ago
  Not the OP, but there are many (tens of) "power domains" on the system, and if you care about power/battery life then you want to power each of them down when they're unused, automatically, even while the rest of the system stays running. i.e. why pay the battery life cost for powering a USB hub when there are no USB devices plugged in, or for a DSP when there's no sound being played right now. But the calculation of when it's safe to power down any of the power domains can be very complicated -- you can't turn off a power supply unless everything that depends on it is unused, so there's a subtle and board-dependent graph/dependency problem to solve.
  - throwaway613834 9y ago
    Awesome, thank you!
  - klodolph 9y ago
    Piggybacking on this—what can make it worse is that some chips might not properly power back on reliably, in spite of the manufacturer's claims.
- ansible 9y ago
  In addition to what cjbprime mentioned... There's a lot going on in a modern (or even one from 10 years ago) SoC with regards to power management. Just the processor cores themselves can run at different voltages and frequencies, and these are tied to the software workload. And then you've got the big / little stuff from ARM now, which is an asymmetric multiprocessor, and which cores you use depends on the workload. At how it works and the interface to it changes from vendor to vendor, sometimes from chip to chip. So it usually isn't implemented all that well, nor is it maintained for very long either. If (big if) we had more standardized interfaces to this functionality, we could use common drivers that can be upgraded independently. Like I said, the desktop people may not realize how easy they've got it, where most things are accessed via a standardized bus interface (PCIe or USB). There's no virtuous cycle of software and interface re-use, like there is in desktop land.
deleted 9y ago
[deleted]

cjbprime 9y ago

Step 3 is often achieved by having the firmware append a device tree blob to the kernel which contains all of the board setup. I think it's pretty widely adopted?

ansible 9y ago
Yes, it is headed in that direction. There's more work needed in areas like uniform conventions for configuring peripheral pins and such, in my opinion. And then there's clock configuration, which is kind of a mess, because everything is hooked up differently on different SoCs that I've seen. It would also be nice if vendors always shipped up-to-date device tree source files for any board they ship.

throwaway613834 9y ago

For those of us who don't know what is involved in power management, would you mind giving a quick explanation of what it involves and why it's painful? What power is there even to manage unless you want to put the computer to sleep or shut it down? Or are those the sole things your are referring to?

cjbprime 9y ago
Not the OP, but there are many (tens of) "power domains" on the system, and if you care about power/battery life then you want to power each of them down when they're unused, automatically, even while the rest of the system stays running. i.e. why pay the battery life cost for powering a USB hub when there are no USB devices plugged in, or for a DSP when there's no sound being played right now. But the calculation of when it's safe to power down any of the power domains can be very complicated -- you can't turn off a power supply unless everything that depends on it is unused, so there's a subtle and board-dependent graph/dependency problem to solve.
- throwaway613834 9y ago
  Awesome, thank you!
- klodolph 9y ago
  Piggybacking on this—what can make it worse is that some chips might not properly power back on reliably, in spite of the manufacturer's claims.
ansible 9y ago
In addition to what cjbprime mentioned... There's a lot going on in a modern (or even one from 10 years ago) SoC with regards to power management. Just the processor cores themselves can run at different voltages and frequencies, and these are tied to the software workload. And then you've got the big / little stuff from ARM now, which is an asymmetric multiprocessor, and which cores you use depends on the workload. At how it works and the interface to it changes from vendor to vendor, sometimes from chip to chip. So it usually isn't implemented all that well, nor is it maintained for very long either. If (big if) we had more standardized interfaces to this functionality, we could use common drivers that can be upgraded independently. Like I said, the desktop people may not realize how easy they've got it, where most things are accessed via a standardized bus interface (PCIe or USB). There's no virtuous cycle of software and interface re-use, like there is in desktop land.

deleted 9y ago

[deleted]