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