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

[Stefan Agner <stefan@agner.ch>]

Am 2014-08-04 19:16, schrieb 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.
> 

No there is no standardized way to detect the carrier board.

>> 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.

--
Stefan