Subtle interactions in the embedded world - what bugs can teach us

Neil: a huge thanks for this article. Most people forget that hardware and software actually need to interact in very subtle ways. Although I was not involved in GTA itself, I was once part of the #gta02-core team. And I do a lot of embedded stuff, but in different areas. Back then we struggled to get HW and SW to co-operate, which was never an easy task (and swsuspend/resume was one of them, but there were others) like patching kernel to disable SD card clock so to not interfere with GPS, and so on [a huge thanks to Werner Almesberger for his amazing work on the GTA/#GTA02-core project].

Just a note for some people: Soc-based platforms are, nowadays, very complex devices. All designs aim to cut costs, but they need to evolve and be adapted due to sourcing problems (see Raspberry Pi xtal problems, for example). Hardware people (like myself, but I'm both hardware and software) focus primarily on these [cost,source] problems, and delegate on software people the task of actually putting things to work. Unfortunately this can lead to problems, because the two (software and hardware) teams [usually] only talk to each other when the hardware design is already finished. I wished that, before specifying the HW specs, the SW guys could look at it and help minimizing integration problems.

Again, thanks a lot for your clear explanation of the problem.