[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