> I’d rather just put a normal Linux distro there, however, I’m not feeling like waiting 8 seconds every time I turn in my car.
Suspend-to-RAM works decently to avoid this, and to avoid it sucking the battery dry, Suspend-to-Flash can be used. Yes this will take some time for restoring RAM... but again, to avoid the user noticing that time, why not start the wakeup process when the user unlocks their car / opens a door?
On desktops and laptops, it Usually Should Just Work (tm). The general culprits for issues are proprietary graphics and wifi drivers as well as shoddy BIOSes with broken ACPI tables, but I never had to dig this deep.
For embedded systems, the situation is more complex, as the chipset needs to support it - suspend itself is not the problem in most cases, but wakeup is - for example, the Raspberry Pi does not have a dedicated interrupt (https://github.com/raspberrypi/linux/issues/1281). If you're working with an embedded chipset, your best bet is the manufacturer, they have to deal with that in the BSP.
Whenever I read comments like this, I think "Why is he trying to use a 10+ years old Ubuntu, or similar"?
Or do I just make way luckier buying choices? Suspend to anything has worked flawlessly out of the box for my devices since 10+ years.
Do you have a specific example of what is not an "obviously bad hardware combination choice", but yet still does not correctly support Suspend-to-RAM?
Suspend-to-RAM works decently to avoid this, and to avoid it sucking the battery dry, Suspend-to-Flash can be used. Yes this will take some time for restoring RAM... but again, to avoid the user noticing that time, why not start the wakeup process when the user unlocks their car / opens a door?