On 08/04/2014 12:38 PM, Stefan Agner wrote:
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.
There's already the --env command-line option which allows you to do this.
If necessary, it probably wouldn't be hard to add the ability for a particular tegra-uboot-flasher config file to automatically add the relevant --env option when run in flashing mode.