public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Tapani Utriainen <tapani@technexion.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] SPL boot on iMX6
Date: Tue, 27 Aug 2013 12:07:24 +0800	[thread overview]
Message-ID: <20130827120724.4b7f5752@triceratops> (raw)
In-Reply-To: <521B5944.5030500@denx.de>

On Mon, 26 Aug 2013 15:33:56 +0200
Stefano Babic <sbabic@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).

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)


Of course the syntax can be different. One experience is that this de-clutters 
the board file (compared with having arrays and arrays of padconf definitions).

The catch is, I guess, that the generated code could be a little larger than 
otherwise, but defining cpu_is_mx6q() with __attribute__((pure)) (or similar) should 
cause gcc to optimize away most of the comparisons and calls to cpu_is_mx6q().

//Tapani

  parent reply	other threads:[~2013-08-27  4:07 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-26  7:17 [U-Boot] SPL boot on iMX6 Tapani Utriainen
2013-08-26  7:42 ` Stefano Babic
2013-08-26 11:12   ` Tapani
2013-08-26 13:33     ` Stefano Babic
2013-08-26 14:23       ` Eric Nelson
2013-08-27 12:53         ` Stefano Babic
2013-08-27  4:07       ` Tapani Utriainen [this message]
2013-08-27 13:00         ` Stefano Babic
2013-08-27 15:00         ` Eric Nelson
2013-08-26 13:28 ` Fabio Estevam

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130827120724.4b7f5752@triceratops \
    --to=tapani@technexion.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox