From mboxrd@z Thu Jan  1 00:00:00 1970
From: Eric Nelson <eric.nelson@boundarydevices.com>
Date: Mon, 26 Aug 2013 07:23:37 -0700
Subject: [U-Boot] SPL boot on iMX6
In-Reply-To: <521B5944.5030500@denx.de>
References: <20130826151743.20e384d4@triceratops> <521B06E6.5030306@denx.de>
	<20130826191200.64a8bc5c@triceratops> <521B5944.5030500@denx.de>
Message-ID: <521B64E9.4090203@boundarydevices.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On 08/26/2013 06:33 AM, Stefano Babic wrote:
> Hi Tapani,
>
> On 26/08/2013 13:12, Tapani wrote:
>>>
>>> Macros wee added exactly in the time they needed, and maybe a global
>>> look was missing.
>>>
>>> However, can you provide much more detail about this ? Which macros, in
>>> which files ?
>>>
>>
>> The macros I refer to is the MX6_PAD_ ones. The semantics of them depends on
>> the target cpu. See arch/arm/include/asm/arch-mx6/mx6-pins.h
>
> Ok - these files are not thought to be used in the same binary, we have
> to change something, taking into account we should remain compatible
> without breaking the currently supported boards.
>
> Let's start with some proposals. Maybe you have already introduced a
> CONFIG_ switch, because at the moment only one SOC per image is
> supported, and one of MX6Q, MX6DL must be set. We have also the same
> issue with -ddr files (mx6q-ddr and mx6dl-ddr). Let's say we add a
> CONFIG_MX6_MULTI to support all SocS at the same time.
>
> Then we could change the file you mention adding a suffix to each pin.
> For example, in mx6q_pins.h we could add something like this:
>
> #ifdef CONFIG_MX6_MULTI
> #define PAD_SUFFIX _6Q
> #else
> #define PAD_SUFFIX
> #endif
>
> And we add the macro to each pin, such as
> enum {
>          MX6_PAD_SD2_DAT1__USDHC2_DAT1##PAD_SUFFIX
>
> In this way we could have different names only if we support multiple
> SOCs. We need then some accessors to get the right pin, something like
> mx6_pin(soc_type, pin_name), that returns the right configuration. Of
> course, this is a very first draft, and someone else can start with
> different proposals.
>
:)

This is where we started on i.MX6, with prefixes MX6Q and MX6DL.
See commit cfb8b9d.

> Generally I would avoid to convert the enums into tables, because they
> will increase the footprint for each board.
>

Functionally, we still need table(s) for any image which supports either
variant so the proper set of pads are configured.

See this for an example
	http://lists.denx.de/pipermail/u-boot/2012-October/136394.html

The construct used in that patch set was to define FOR_DL_SOLO,
then include the pad file.
	#ifdef CONFIG_MX6Q
	#include "pads.h"
	#endif
	#if defined(CONFIG_MX6DL) || defined(CONFIG_MX6S)
	#define FOR_DL_SOLO
	#include "pads.h"
	#endif

Troy's implementation used a naming convention of mx6q_X
and mx6dl_solo_X such that a board supporting both would have
variables

	static iomux_v3_cfg_t mx6q_usdhc3_pads = ...

followed by

	static iomux_v3_cfg_t mx6dl_solo_usdhc3_pads = ...

Some other data structures were also duplicated with the
same naming convention (see i2c_pads).

Regards,


Eric