From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Wed, 12 Apr 2017 15:49:48 -0400 Subject: [U-Boot] [PATCH 7/7] omap3_logic: Add Device Tree Support and more DM drivers In-Reply-To: References: <1492000816-12092-1-git-send-email-aford173@gmail.com> <20170412191839.GJ19897@bill-the-cat> Message-ID: <20170412194948.GM19897@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Wed, Apr 12, 2017 at 02:38:58PM -0500, Adam Ford wrote: > On Wed, Apr 12, 2017 at 2:18 PM, Tom Rini wrote: > > On Wed, Apr 12, 2017 at 07:40:16AM -0500, Adam Ford wrote: > > > >> The previous version of omap3_logic_defconfig supported either > >> Torpedo or SOM-LV. Now with the device tree, there are two > >> different defconfig files: > >> > >> omap3_logic_defconfig = torpedo > >> omap3_logic_somlv_defconfig = SOM-LV > >> > >> This patch also removes all the excessive code in trying to > >> determine the differences between these boards as well as removing > >> the some of the unnecessary NS16550 intiailization as the device > >> tree can do that now. This also adds DM_I2C and DM_MMC since > >> the overlying drivers have the built-in support already. The > >> corresponding include/config/omap3_logic.h also reduced in size > >> due to the new device tree support. > >> > >> The device trees were sync'd with 4.9.y stable with two changes: > >> disable mmc2 and stdout-path = &uart1. Both of those two changes > >> will be submitted to the linux-omap list. > >> > >> Signed-off-by: Adam Ford > >> Reviewed-by: Lokesh Vutla > > > > OK, why can't we support both in a single defconfig? And perhaps a > > README to say that if you need to support only one, modify the config as > > follows... ? Thanks! > > I can certainly do a readme file. Is there a way to build U-Boot with > two different device tree options? The SOM-LV and Torpedo have > separate device trees. The original code had a mechanism to > autodetect which hardware was being used and would then select the > corresponding dtb. With the device tree integrated into U-Boot it > seemed to me like the auto detect code didn't make sense since the > U-Boot with the corresponding DTB would have to be loaded from the > beginning. I looked at the variety of am33xx boards, and it seemed > like different versions have different _defconfig files. I would > prefer to have a since defconfig and separate U-Boot files generated > for each DTB, but it wasn't clear to me whether or not that was > possible. If you have an example I can look at that and redo this to > eliminate the second defconfig. No, and yes, is how I would answer the first question. For SPL, this is much trickier (and I would recommend a fake dts file that works well enough for SPL and runs on both boards). But for U-Boot itself, yes, with U-Boot in a FIT image and all DTB files included as well, SPL can get the right one for the board at run time. So, no, we cannot make N MLO+u-boot.img (of legacy uImage-style u-boot.bin). But we can make MLO+u-boot.img (as a FIT image of u-boot + N dtb files). See am335x_evm for an example. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: