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
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
