[U-Boot] SPL boot on iMX6

[Eric Nelson]

Hi Tapani,

On 08/26/2013 09:07 PM, Tapani Utriainen wrote:
 > On Mon, 26 Aug 2013 15:33:56 +0200
 > Stefano Babic <sbabic at denx.de> wrote:
 >
 >> Hi Tapani,
 >>
 >>>
 >>> 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.
 >
 > Yes, this is the productive approach.
 >
 >> 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.
 >>
 >
 > Your suggestion is similar to what I would first think of, but you do
 > the extra kludging to make it work with the current syntax. My
 > approach would be to introduce new namings in parallel to the current
 > ones (similar, if not the same, as the linux kernel uses) until most
 > imx6 boards have been cleaned to use the new namings (which might
 > take a while).
 >

No matter how we implement this, there are some pre-requisites.

I believe we're all in agreement that we should be able to express
a pad value in one place which defines the use of a particular pad
on a particular board.

We need some cleanup to get there though.
For example, pad CSI0_DAT13 has this option in mx6q_pins.h:

     MX6_PAD_CSI0_DAT13__PCIE_CTRL_MUX_17

but this value in mx6dl_pins.h
     MX6_PAD_CSI0_DAT13__PCIE_CTRL_DIAG_STATUS_BUS_MUX_17

I'm created sorted lists of pad names for dual-quad and solo
processors for easy comparison:
	http://linode.boundarydevices.com/imx6quad-pad-names.txt
	http://linode.boundarydevices.com/imx6solo-pad-names.txt

Most of the differences are simply name changes, with an extra
underscore in one versus the other.

Some of them are functional differences though (e.g. SATA isn't
present on solo). No matter how the pad names get changed, these
should be easy to identify in the resulting code.

 > For the accessor macro, our experiences from the Wandboard kernel
 > have been very positive with the following:
 >
 > To set the above mentioned pad, the board file does:
 >
 >     IMX6_SETUP_PAD( SD2_DAT1__USDHC2_DAT1 );
 >
 > where the macro IMX6_SETUP_PAD is defined as:
 >
 > #define IMX6_SETUP_PAD(p) \
 >     if (cpu_is_mx6q()) \
 >         mxc_iomux_v3_setup_pad(MX6Q_PAD_##p);\
 >     else \
 >         mxc_iomux_v3_setup_pad(MX6DL_PAD_##p)
 >

Please, no!

You'd never write code like this by hand, and putting it behind a
macro doesn't make it better. It just hides the ugliness.

Regards,


Eric