On Monday, March 31, 2014 at 09:38:02 PM, Otavio Salvador wrote: > On Mon, Mar 31, 2014 at 4:22 PM, Marek Vasut <ma...@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.ki...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot