Follow the reference design as closely as possible and only deviate when you have a really good reason to do so. Even simple HW changes can result in a lot of work. Often this requires careful HW review and some negotiation with the hardware developers. Getting the device-tree files correct is an iterative process that is very device-specific, and typically requires the following:
your reference design kernel/u-boot source in Git
Linux/U-boot sources for custom design in Git that is easy to diff with reference design sources
reference design schematics
custom schematics with a list of what changed from the reference design
a spreadsheet with all SOC IOs comparing reference design to custom design, alt functions used, etc.
And it is not getting any easier as devices get more complex.
If you’re using a TI SOC, the TI pinmux tools are very powerful and are super helpful during schematic capture to make sure you can connect the right things to the right pins in the design. Definitely recommend leveraging the TI pinmux tools!
I’m personally of the opinion that most reference design boards are really really horrible in terms of design foresight and manufacturing quality. I’ve seen enough “follow the reference design” projects hit very unexpected product development snags, especially around parts sourcing and emissions compliance or corner cases where the reference design states that something is supported but that there’s tremendous nuance to what they mean by “supported.”
Definitely learn on the firmware/software side with the officially supported dev kit, but I personally don’t give the dev kit much weight when doing actual product development. Know what your design needs are and make sure you thoroughly understand the documentation and reference design, but then feel free to deviate wildly from the reference design as the reference designers probably don’t have much real world experience making the product you’re making.
