[U-Boot] [PATCH 1/1] imx-common: cpu: add fdt_file environment variable

Marek Vasut
2014-03-31T19:47:34Z

On Monday, March 31, 2014 at 09:38:02 PM, Otavio Salvador wrote:
> On Mon, Mar 31, 2014 at 4:22 PM, Marek Vasut <marex@denx.de> wrote:
> > On Monday, March 31, 2014 at 08:36:55 PM, Troy Kisky wrote:
> >> On 3/29/2014 4:11 PM, Eric Nelson wrote:
> >> > Hi Troy,
> >> >
> >> > On 03/29/2014 03:34 PM, Troy Kisky wrote:
> >> >> This removes one block in the move toward 1 u-boot
> >> >> for both a mx6q (quad) and mx6dl (duallite) processor.
> >> >>
> >> >> Now fdt_file hardcoded value can be removed.
> >> >>
> >> >> Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
> >> >> ---
> >> >>
> >> >> arch/arm/imx-common/cpu.c | 44
> >> >> ++++++++++++++++++++++++++++++++++++++++++++ arch/arm/lib/board.c
> >> >>
> >> >> | 7 +++++++
> >> >>
> >> >> 2 files changed, 51 insertions(+)
> >> >>
> >> >> diff --git a/arch/arm/imx-common/cpu.c b/arch/arm/imx-common/cpu.c
> >> >> index a77c4de..5d48011 100644
> >> >> --- a/arch/arm/imx-common/cpu.c
> >> >> +++ b/arch/arm/imx-common/cpu.c
> >> >> @@ -180,3 +180,47 @@ void arch_preboot_os(void)
> >> >>
> >> >> ipuv3_fb_shutdown();
> >> >>
> >> >> }
> >> >> #endif
> >> >>
> >> >> +
> >> >> +const char *get_dtb_prefix(u32 imxtype)
> >> >> +{
> >> >> + switch (imxtype) {
> >> >> + case MXC_CPU_MX6Q:
> >> >> + case MXC_CPU_MX6D:
> >> >> + return "imx6q"; /* Quad/Dual-core version of the mx6
> >> >> */ + case MXC_CPU_MX6DL:
> >> >> + case MXC_CPU_MX6SOLO:
> >> >> + return "imx6dl"; /* Dual Lite/Solo version of the mx6 */
> >> >> + case MXC_CPU_MX6SL:
> >> >> + return "imx6sl"; /* Solo-Lite version of the mx6 */
> >> >> + case MXC_CPU_MX51:
> >> >> + return "imx51";
> >> >> + case MXC_CPU_MX53:
> >> >> + return "imx53";
> >> >> + }
> >> >> + return "??";
> >> >> +}
> >> >> +
> >> >
> >> > I really dislike this implementation of naming policy in code.
> >>
> >> It is not truly a policy. It is a convenience which can be ignored
> >> if so desired. Though I do agree that cpu and board environment
> >> variables would also be useful. Still, a cpu variable would still
> >> require some scripting to combine the quad/dual, duallite/solo. So,
> >> your way is not as convenient for dtb file names.
> >
> > You can make the CPU code set the CPU type into some variable.
> > Afterwards, some scripts in the HUSH can assemble the DTB name based on
> > those variables. This would be much more generic and re-usable than this
> > ...
>
> The problem is this script will be mostly the same for most boards.

This does by no means justify poluting code with non-reusable convoluted stuff.
A script which is part of the environment can be tweaked on a running system as
seen fit at any later date, updating bootloader on a running system is often not
an option.

Furthermore, having partial information which can be used for decisionmaking is
much better than having a lengthy string which needs to be parsed first.
Especially with the limited parsing options we have in some configurations of U-
Boot.

Best regards,
Marek Vasut