<div> </div><div> </div><div>14.01.2020, 13:52, "Brad Bishop" <bradleyb@fuzziesquirrel.com>:</div><blockquote><p><br /> </p><blockquote> On Jan 14, 2020, at 5:39 AM, Konstantin Klubnichkin <<a href="mailto:kitsok@yandex-team.ru">kitsok@yandex-team.ru</a>> wrote:<br /><br /><br /> Hello, Brad!<br /><br /> I'm doing this using overlay DTS.<br /> I have a startup script that detects board type by GPIO pins and loads corresponding overlay.</blockquote><p><br />Thanks for the reply Konstantin. Does that mean you have the overlay patch applied to your kernel tree?</p></blockquote><div><br />Yes, take a look at this commit: https://github.com/Xilinx/linux-xlnx/commit/380e5d653ab51a38af4411fb16f49cbd6eb3b690#diff-fef3d80c6ff95384f0077d2149ab8e81<br /> </div><blockquote><p>An alternative design that I am considering is having two complete device trees in a fit image, and u-boot reads the gpios to pick the correct dtb for linux. Did you consider a design like that and if so, was there anything specific that sent you in the direction of overlays?</p></blockquote><div><br />I thought about it, but U-Boot hacking looked more complex, paricularly handling of all possible exceptions like wrong combination of GPIO pins.</div><div> </div><div>Also I need to instantiate a specific device driver in a runtime on a certain condition, and overlay works just fine for this. An alternative could be a modules but overlays are already there.</div><div> <blockquote><p>thx - brad</p></blockquote><div> </div><div> </div><div>-- </div><div>Best regards,</div><div>Konstantin Klubnichkin,</div><div>lead firmware engineer,</div><div>server hardware R&D group,</div><div>Yandex Moscow office.</div><div>tel: +7-903-510-33-33</div><div> </div></div>