Am 05.05.23 um 11:39 schrieb Tony Lindgren:
* Nishanth Menon <nm@xxxxxx> [230504 14:33]:
Just wondering: if the carrier board can easily work with different
SoMs.. in which case, we could do overlay to create the som + carrier
overlay to create rdk dtb - this might allow the scheme to scale to
additional SoMs and carrier combinations.. and the SoM dtb could be
sufficient for something like a bootloader.
It might be best to limit the overlay usage to devices that might see
dual use on the carrier board.. Not sure if setting up the entire
carrier board makes sense as an overlay :) Not sure if folks want to
debug boot issues on a remote server for example if an overlay is
needed to boot with Ethernet :)
Our idea is to create overlays for SoM variants, e.g. an overlay for a SoM
without SPI NOR flash populated.
If we want to reuse a carrier board, we could factor out the carrier board dts
into a dtsi file and provide the needed combinations in form of different dts files.
In the bootloader world the situation is a bit different.
Here we would like to have a universal phycore_am62x "board" that should be able
to handle most carrier board designs using that SoM. And since u-boot is moving
towards having a single source of device trees, this concept will probably no
longer work anymore. So your idea with a SoM dtb sounds interesting.
I wonder what ideas other SoM vendors have or how it is handled on other
architectures.
Regards,
Wadim
Regards,
Tony
