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

[Stefan Agner]

Am 2014-08-04 19:02, schrieb Stephen Warren:
> 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?
> 

Since a lot of people use the bootloader binaries unmodified, such a
solution would be preferable. I guess I could use fdtput or even extend
the existing tegra-uboot-flasher for this purpose.

> 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:-)

Yes, such a lightweight carrier board/module support would be
maintainable too I guess.

I will try to implement the first approach first. One way would be
setting the board_name by overriding boardcmd. Or maybe a bit more
problem specific, getting the fdtfile/board_name from dts
/config/fdtfile node...

--
Stefan