[U-Boot] [PATCH] ARM: tegra: add Colibri T30 board support

[Tom Rini]

On Mon, Aug 04, 2014 at 11:02:28AM -0600, Stephen Warren wrote:
> On 08/02/2014 08:09 AM, Stefan Agner wrote:
> >Am 2014-07-31 20:21, schrieb Stephen Warren:
> >>On 07/31/2014 11:36 AM, Stefan Agner wrote:
> >>>This adds board support for the Toradex Colibri T30 module.
> >>>
> >>>Working functions:
> >>>- SD card boot
> >>>- eMMC environment and boot
> >>>- USB host/USB client (on the dual role port)
> >>>- Network (via ASIX USB)
> 
> >>>+#define BOARD_EXTRA_ENV_SETTINGS \
> >>>+	"board_name=colibri-eval-v3\0" \
> >>>+	"fdtfile=tegra30-colibri-eval-v3.dtb\0"
> >>
> >>It'd be nice to name the board the same in U-Boot as the kernel DT
> >>filename. Then you wouldn't need to manually override the default
> >>values here.
> >
> >This is a somewhat complicated topic in our case. Our products are
> >named:
> >
> >"Colibri T20"
> >"Colibri T30"
> >"Apalis T30"
> >
> >Since quite a long time, we use those names, except replacing the space
> >by an underline character and preferable use small caps. Hence e.g. the
> >U-Boot configurations in the downstream tree:
> >
> >colibri_t20_config
> >colibri_t30_config
> >apalis_t30_config
> >
> >However, in the kernel world, since device tree was introduced there is
> >this reverse notation, SoC-board.dts... e.g. tegra30-colibri_t30.dts. We
> >descided to drop that t30, since its somewhat duplicated. Not sure this
> >was the right description, but its in the kernel that way right now.
> >
> >Additionally, this whole carrier board (Evaluation Board v3)/module
> >(Colibri T30) relation is also taken into account at kernel side, hence
> >the full name today
> >tegra30-colibri-eval-v3.dts
> ...
> >Also we use the same boot
> >loader configuration for our three own Carrier Boards.
> 
> OK, it mostly makes sense to have U-Boot configuration names that
> only mention the CPU module and not the carrier board in that case.
> 
> However, if the U-Boot default environment defines the full kernel
> DTB name, then that isn't possible. A U-Boot board will be tied to a
> particular carrier-board configuration that way.
> 
> Perhaps remove the DT filename from the default environment, and
> require the user or flashing process to set the correct value?

Is there a run-time way to discover what board (or perhaps rather, what
DT we would want to load) we're on?  That's how we solve this on various
TI platforms.

> Alternatively, perhaps add the core U-Boot support under one
> (primary configuration and board directory) name, and add additional
> entry to boards.cfg/Kconfig to override that one fdtfile value in
> the environment? I see quite a few other boards do so something
> similar, albeit likely for larger variations than just one
> environment variable:-)

But yes, we'll need to sort out a way to setup the default environment,
with some this-that-or-something-else tweaks in any case.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140804/fd50636d/attachment.pgp>