zlacker

>>fghtr+(OP)
Naive question, but with a commercial product like the i.MX8M from NXP Semiconductors, is there really not enough in it for them to develop Linux support for their product, rather than leaving it to other parties? Presumably some OS supported things like the i.MX8M’s accelerometer from the launch date, or are these chips shipped to OEMs on the basis that the low level functions work, but all OS support has to be created by someone else?

>>gorgoi+u3
For some reason, every hardware company, without exception, it terrible at software development. They just can’t do it right. It’s probably a cultural difference, somehow, with the developent style and/or NDA requirements possibly having their impact.

>>teddyh+k6
I'm not really a hardware guy (just a hobbyist), but I've worked with a few. As far as I can tell it's typically a mix of things, largely related to managing unique difficulties of hardware bringup and treating software development as part of the hardware product development cycle instead of really having its own planning/management authority. For example:

- Doing a hard fork of the software stack for every product family/generation/platform, because it's assumed up front that hardware differences/bugs and changes in product definition will require non-portable changes throughout the stack (e.g. things like GUI element sizes and line lengths are often hardcoded to fit the layout to a particular screen, various GPIO pins/buttons/LEDs/connectors change identity/significance, hardware gains/loses capabilities needed for a feature so UI elements related to that feature need to be added/removed/altered)

- Expecting the vast majority of development effort to be on shipping new products because already-shipping products are "in the can" and the big deals have already been closed

- Management belief that hardware is hard and software is easy (which is arguably sometimes rational from the perspective of managing product-dooming risks)

- Upstream vendors wasting developers' time with shenanigans around stuff like documentation (oh, you wanted the real manual that actually says what the registers do?) and firmware (some vendors apparently forget to mention that there is firmware until you ask your SE/FAE why something isn't working)

- Uncertainty around whether a given problem ought to be fixed in hardware or software