[U-Boot] [PATCH 7/7] omap3_logic: Add Device Tree Support and more DM drivers

Tom Rini trini at konsulko.com
Wed Apr 12 19:49:48 UTC 2017


On Wed, Apr 12, 2017 at 02:38:58PM -0500, Adam Ford wrote:
> On Wed, Apr 12, 2017 at 2:18 PM, Tom Rini <trini at konsulko.com> 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 <aford173 at gmail.com>
> >> Reviewed-by: Lokesh Vutla <lokeshvutla at ti.com>
> >
> > 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: <http://lists.denx.de/pipermail/u-boot/attachments/20170412/05b8a39b/attachment.sig>


More information about the U-Boot mailing list