Patchwork [U-Boot] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)

login
register
mail settings
Submitter Lubomir Popov
Date April 1, 2013, 2:06 p.m.
Message ID <51599458.1000505@mm-sol.com>
Download mbox | patch
Permalink /patch/232739/
State Changes Requested
Delegated to: Tom Rini
Headers show

Comments

Lubomir Popov - April 1, 2013, 2:06 p.m.
Signed-off-by: Lubomir Popov <lpopov@mm-sol.com>

---

The som5_evb is an evaluation board for the APM-5 - a OMAP5430-based SOM (system
On a Module) designed by MMS and manufactured under license by Jorjin Technologies.

 arch/arm/include/asm/mach-types.h   |   13 ++
 board/mms/som5_evb/Makefile         |   49 +++++
 board/mms/som5_evb/s5evb_mux_data.h |  376 +++++++++++++++++++++++++++++++++++
 board/mms/som5_evb/som5_evb.c       |  200 +++++++++++++++++++
 boards.cfg                          |    1 +
 include/configs/omap5_som5_evb.h    |  336 +++++++++++++++++++++++++++++++
 6 files changed, 975 insertions(+)
 create mode 100644 board/mms/som5_evb/Makefile
 create mode 100644 board/mms/som5_evb/s5evb_mux_data.h
 create mode 100644 board/mms/som5_evb/som5_evb.c
 create mode 100644 include/configs/omap5_som5_evb.h
Tom Rini - April 25, 2013, 7:01 p.m.
On Mon, Apr 01, 2013 at 05:06:16PM +0300, Lubomir Popov wrote:

> Signed-off-by: Lubomir Popov <lpopov@mm-sol.com>

Thought I had reviewed this already, sorry.

> 
> ---
> 
> The som5_evb is an evaluation board for the APM-5 - a OMAP5430-based SOM (system
> On a Module) designed by MMS and manufactured under license by Jorjin Technologies.

Above the '---' so it's in the changelog.

> diff --git a/arch/arm/include/asm/mach-types.h b/arch/arm/include/asm/mach-types.h
> index a676b6d..236fa17 100644
> --- a/arch/arm/include/asm/mach-types.h
> +++ b/arch/arm/include/asm/mach-types.h
> @@ -1107,6 +1107,7 @@ extern unsigned int __machine_arch_type;
>  #define MACH_TYPE_OMAP5_SEVM           3777
>  #define MACH_TYPE_ARMADILLO_800EVA     3863
>  #define MACH_TYPE_KZM9G                4140
> +#define MACH_TYPE_SOM5_EVB             4545

Don't touch this file and instead add just this define to your config,
and then #define CONFIG_MACH_TYPE MACH_...  If you can't just support
DT-only.

[snip]
> +const struct pad_conf_entry core_padconf_array_non_essential[] = {
> +#if 0

Remove #if 0'd code.
> +	gd->bd->bi_arch_number = MACH_TYPE_SOM5_EVB;

CONFIG_MACH_TYPE in your config and you don't need this line

> +#ifdef CONFIG_TWL6035_AUDPWR
> +	/* Useful for measuring voltages around the codec.
> +	 * Works with a TWL604x only.
> +	 */

/*
 * Like this
 */

> +#ifdef CONFIG_I2C_INTERNAL_PULLUPS
> +	/* Enable internal I2C-compatible pullups on all buses
> +	 * TODO: Replace this ugly hardcoding with proper defines (omap.h)
> +	 * control_smart3io_padconf_0, control_i2c_0

Do please, thanks.

> +#define USB_HOST_HS_CLKCTRL_MASK	0x0100D7C0	/* CM_L3INIT_USB_HOST_HS_CLKCTRL */
> +#define USB_TLL_HS_CLKCTRL_MASK		0x00000700	/* CM_L3INIT_USB_TLL_HS_CLKCTRL */

Some header please.

> +	 * TODO: Replace this ugly hardcoding with proper defines
> +	 */
> +	writel(0x0100, 0x4ae0a310);

Again, do please.

> +#define CONFIG_OMAP5430			/* which is in a 5430 */
> +#define CONFIG_SOM5EVB			/* working with the SOM5 EVB */

Unused.

> +/* Machine type for Linux */
> +#define CONFIG_MACH_TYPE		MACH_TYPE_SOM5_EVB

Ah, since you do have this part already, just update the rest as I had
said.

> +/* Enable all clocks: */
> +/*#define CONFIG_SYS_CLOCKS_ENABLE_ALL*/
> +
> +#define CONFIG_SYS_ENABLE_PADS_ALL	/* Enable all PADS for now */

Not allowed.

> +#define CONFIG_SYS_CA15_VECTOR_BASE	SRAM_ROM_VECT_BASE

Introduced in the USB patches?

> +#define CONFIG_SYS_BAUDRATE_TABLE	{4800, 9600, 19200, 38400, \
> +					57600, 115200}

Please use the fallback table.

> +/* MMC ENV related defines */
> +#define CONFIG_ENV_IS_NOWHERE
> +#ifdef CONFIG_ENV_IS_IN_MMC
> +#define CONFIG_SYS_MMC_ENV_DEV		1	/* SLOT2: eMMC(1) */
> +#define CONFIG_ENV_OFFSET		0xE0000
> +#define CONFIG_CMD_SAVEENV
> +#endif

This is a little un-clear. If MMC will be in mmc like the uEVM, just do
so, and if no storage of env, leave it as NOWHERE.

> +#define	CONFIG_CMD_PING		/* PING support */

space not tab, fix globally.

> +#define CONFIG_NET_MULTI

Unused.

> +	"usbethaddr=9e:77:39:1b:c4:2d\0" \

Not allowed.

> +/*
> + * memtest setup
> + */
> +#define CONFIG_SYS_MEMTEST_START	0xb8000000
> +#define CONFIG_SYS_MEMTEST_END		(CONFIG_SYS_MEMTEST_START + (256 << 20))
> +/* Undef following two for simple mtest */
> +#define CONFIG_SYS_ALT_MEMTEST
> +#define CONFIG_SYS_MEMTEST_SCRATCH	0x81000000

Please see doc/README.memory-test and update as mtest is no longer a
default command.

Thanks!
Lubomir Popov - April 26, 2013, 3:59 p.m.
Hi Tom,

On 25/04/13 22:01, Tom Rini wrote:
> On Mon, Apr 01, 2013 at 05:06:16PM +0300, Lubomir Popov wrote:
> 
>> Signed-off-by: Lubomir Popov <lpopov@mm-sol.com>
> 
> Thought I had reviewed this already, sorry.
Thanks for your review. During the past month U-Boot has changed; I have tried to
follow as well (although I'm engaged with other stuff) and some of your remarks
have been already fixed. Please see my comments inline below.

Anyway, I guess that a V2 patch shall have to be referenced against the current master.
Or against u-boot-ti/next?

Please note that for this board to work with the defined configuration, the following
patches are also required (unfortunately some are already quite old and might cause
conflicts):

- Power: http://patchwork.ozlabs.org/patch/232732/. Potential conflict with Nishanth
  Menon's series of March 26, applied to u-boot-ti/next.
- For I2C support:
  * The patch series of Apr. 8 that enables I2C4 and I2C5 (applied to u-boot-ti/next;
    affects all OMAP5 boards).
  * The modified i2c driver: http://patchwork.ozlabs.org/patch/233823/ (useful for all
    OMAP3/4/5 boards). 
- For USB support:
  * http://patchwork.ozlabs.org/patch/235684/ (affects all OMAP5 boards)
  * http://patchwork.ozlabs.org/patch/232742/ (affects all OMAP5 boards)

> 
>>
>> ---
>>
>> The som5_evb is an evaluation board for the APM-5 - a OMAP5430-based SOM (system
>> On a Module) designed by MMS and manufactured under license by Jorjin Technologies.
> 
> Above the '---' so it's in the changelog.
OK, sure, my fault
> 
>> diff --git a/arch/arm/include/asm/mach-types.h b/arch/arm/include/asm/mach-types.h
>> index a676b6d..236fa17 100644
>> --- a/arch/arm/include/asm/mach-types.h
>> +++ b/arch/arm/include/asm/mach-types.h
>> @@ -1107,6 +1107,7 @@ extern unsigned int __machine_arch_type;
>>  #define MACH_TYPE_OMAP5_SEVM           3777
>>  #define MACH_TYPE_ARMADILLO_800EVA     3863
>>  #define MACH_TYPE_KZM9G                4140
>> +#define MACH_TYPE_SOM5_EVB             4545
> 
> Don't touch this file and instead add just this define to your config,
> and then #define CONFIG_MACH_TYPE MACH_...  If you can't just support
> DT-only.
OK
> 
> [snip]
>> +const struct pad_conf_entry core_padconf_array_non_essential[] = {
>> +#if 0
> 
> Remove #if 0'd code.
Done
>> +	gd->bd->bi_arch_number = MACH_TYPE_SOM5_EVB;
> 
> CONFIG_MACH_TYPE in your config and you don't need this line
All OMAP boards currently have it. Stay as is.
> 
>> +#ifdef CONFIG_TWL6035_AUDPWR
>> +	/* Useful for measuring voltages around the codec.
>> +	 * Works with a TWL604x only.
>> +	 */
> 
> /*
>  * Like this
>  */
Fixed
> 
>> +#ifdef CONFIG_I2C_INTERNAL_PULLUPS
>> +	/* Enable internal I2C-compatible pullups on all buses
>> +	 * TODO: Replace this ugly hardcoding with proper defines (omap.h)
>> +	 * control_smart3io_padconf_0, control_i2c_0
> 
> Do please, thanks.
Was already done.
> 
>> +#define USB_HOST_HS_CLKCTRL_MASK	0x0100D7C0	/* CM_L3INIT_USB_HOST_HS_CLKCTRL */
>> +#define USB_TLL_HS_CLKCTRL_MASK		0x00000700	/* CM_L3INIT_USB_TLL_HS_CLKCTRL */
> 
> Some header please.
Currently moved to board header. I wondered if a common OMAP header wouldn't be
more suitable, but having in mind that the utilized USB ports (and thus the clocks
that should be enabled) vary from board to board, perhaps this (i.e. board header)
is the best place.
> 
>> +	 * TODO: Replace this ugly hardcoding with proper defines
>> +	 */
>> +	writel(0x0100, 0x4ae0a310);
> 
> Again, do please.
This should be (*scrm)->auxclk0. The problem is that the omap5_scrm_regs struct
(holding the auxclk0 member) has to be defined somewhere in the common OMAP5
headers. Sricharan? Or should I hack around?
> 
>> +#define CONFIG_OMAP5430			/* which is in a 5430 */
>> +#define CONFIG_SOM5EVB			/* working with the SOM5 EVB */
> 
> Unused.
Long gone. BTW, board config now includes omap5_common.h.
> 
>> +/* Machine type for Linux */
>> +#define CONFIG_MACH_TYPE		MACH_TYPE_SOM5_EVB
> 
> Ah, since you do have this part already, just update the rest as I had
> said.
/* Machine type for Linux */
#ifndef MACH_TYPE_SOM5_EVB
#define MACH_TYPE_SOM5_EVB		4545
#endif
#define CONFIG_MACH_TYPE		MACH_TYPE_SOM5_EVB

Is this OK?

> 
>> +/* Enable all clocks: */
>> +/*#define CONFIG_SYS_CLOCKS_ENABLE_ALL*/
>> +
>> +#define CONFIG_SYS_ENABLE_PADS_ALL	/* Enable all PADS for now */
> 
> Not allowed.
Shall see to it. What if one needs to test pins and connections during
board bring-up, e.g. via gpio commands?
> 
>> +#define CONFIG_SYS_CA15_VECTOR_BASE	SRAM_ROM_VECT_BASE
> 
> Introduced in the USB patches?
Not used and removed a while ago.
> 
>> +#define CONFIG_SYS_BAUDRATE_TABLE	{4800, 9600, 19200, 38400, \
>> +					57600, 115200}
> 
> Please use the fallback table.
Already done.
> 
>> +/* MMC ENV related defines */
>> +#define CONFIG_ENV_IS_NOWHERE
>> +#ifdef CONFIG_ENV_IS_IN_MMC
>> +#define CONFIG_SYS_MMC_ENV_DEV		1	/* SLOT2: eMMC(1) */
>> +#define CONFIG_ENV_OFFSET		0xE0000
>> +#define CONFIG_CMD_SAVEENV
>> +#endif
> 
> This is a little un-clear. If MMC will be in mmc like the uEVM, just do
> so, and if no storage of env, leave it as NOWHERE.
Cerrently looks like this:
/* MMC ENV related defines */
#undef CONFIG_ENV_IS_IN_MMC
#undef CONFIG_SYS_MMC_ENV_DEV
#undef CONFIG_ENV_OFFSET
#define CONFIG_ENV_IS_NOWHERE

> 
>> +#define	CONFIG_CMD_PING		/* PING support */
> 
> space not tab, fix globally.
Done.
> 
>> +#define CONFIG_NET_MULTI
> 
> Unused.
Removed.
> 
>> +	"usbethaddr=9e:77:39:1b:c4:2d\0" \
> 
> Not allowed.
Gone.
> 
>> +/*
>> + * memtest setup
>> + */
>> +#define CONFIG_SYS_MEMTEST_START	0xb8000000
>> +#define CONFIG_SYS_MEMTEST_END		(CONFIG_SYS_MEMTEST_START + (256 << 20))
>> +/* Undef following two for simple mtest */
>> +#define CONFIG_SYS_ALT_MEMTEST
>> +#define CONFIG_SYS_MEMTEST_SCRATCH	0x81000000
> 
> Please see doc/README.memory-test and update as mtest is no longer a
> default command.
Now the config tail looks like this:

/* Undef/remove after bring-up: */
#define CONFIG_CMD_MEMTEST

/* Disabled commands */
#undef CONFIG_CMD_SAVEENV

/* Prompt */
#define CONFIG_SYS_PROMPT		"SOM5_EVB # "

#ifdef CONFIG_CMD_MEMTEST
/* Undef following two for simple mtest */
#define CONFIG_SYS_ALT_MEMTEST
#define CONFIG_SYS_MEMTEST_SCRATCH	0xb7fffff0
#ifdef CONFIG_SYS_ALT_MEMTEST
#undef CONFIG_SYS_MEMTEST_START
#define CONFIG_SYS_MEMTEST_START	0xb8000000
#undef CONFIG_SYS_MEMTEST_END
#define CONFIG_SYS_MEMTEST_END		(CONFIG_SYS_MEMTEST_START + (256 << 20))
#endif
#endif /* CONFIG_CMD_MEMTEST */

> 
> Thanks!
>
Tom Rini - May 13, 2013, 7:37 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/26/2013 11:59 AM, Lubomir Popov wrote:
> Hi Tom,
> 
> On 25/04/13 22:01, Tom Rini wrote:
>> On Mon, Apr 01, 2013 at 05:06:16PM +0300, Lubomir Popov wrote:
>> 
>>> Signed-off-by: Lubomir Popov <lpopov@mm-sol.com>
>> 
>> Thought I had reviewed this already, sorry.
> Thanks for your review. During the past month U-Boot has changed; I
> have tried to follow as well (although I'm engaged with other
> stuff) and some of your remarks have been already fixed. Please see
> my comments inline below.
> 
> Anyway, I guess that a V2 patch shall have to be referenced against
> the current master. Or against u-boot-ti/next?

OK, sorry for the late reply again.  Now that u-boot-arm has resynced
with master, I've also resynced and gotten a pull done.  You can use
either u-boot-arm/master or u-boot-ti/master.

> 
> Please note that for this board to work with the defined
> configuration, the following patches are also required
> (unfortunately some are already quite old and might cause 
> conflicts):
> 
> - Power: http://patchwork.ozlabs.org/patch/232732/. Potential
> conflict with Nishanth Menon's series of March 26, applied to
> u-boot-ti/next. - For I2C support: * The patch series of Apr. 8
> that enables I2C4 and I2C5 (applied to u-boot-ti/next; affects all
> OMAP5 boards). * The modified i2c driver:
> http://patchwork.ozlabs.org/patch/233823/ (useful for all OMAP3/4/5
> boards). - For USB support: *
> http://patchwork.ozlabs.org/patch/235684/ (affects all OMAP5
> boards) * http://patchwork.ozlabs.org/patch/232742/ (affects all
> OMAP5 boards)

OK.  Please make sure these still apply and if not update and re-send.
 I think I've already grabbed a few of these.

[snip]
>>> +#define USB_HOST_HS_CLKCTRL_MASK	0x0100D7C0	/*
>>> CM_L3INIT_USB_HOST_HS_CLKCTRL */ +#define
>>> USB_TLL_HS_CLKCTRL_MASK		0x00000700	/*
>>> CM_L3INIT_USB_TLL_HS_CLKCTRL */
>> 
>> Some header please.
> Currently moved to board header. I wondered if a common OMAP header
> wouldn't be more suitable, but having in mind that the utilized USB
> ports (and thus the clocks that should be enabled) vary from board
> to board, perhaps this (i.e. board header) is the best place.

The masks won't change tho, yes?  Common header somewhere.

>> 
>>> +	 * TODO: Replace this ugly hardcoding with proper defines +
>>> */ +	writel(0x0100, 0x4ae0a310);
>> 
>> Again, do please.
> This should be (*scrm)->auxclk0. The problem is that the
> omap5_scrm_regs struct (holding the auxclk0 member) has to be
> defined somewhere in the common OMAP5 headers. Sricharan? Or should
> I hack around?

Add it to the most likely struct in the headers.

[snip]
>> Ah, since you do have this part already, just update the rest as
>> I had said.
> /* Machine type for Linux */ #ifndef MACH_TYPE_SOM5_EVB #define
> MACH_TYPE_SOM5_EVB		4545 #endif #define CONFIG_MACH_TYPE
> MACH_TYPE_SOM5_EVB
> 
> Is this OK?

I think we'd decided in general to not do ifndef and just always
define it.

>>> +/* Enable all clocks: */ +/*#define
>>> CONFIG_SYS_CLOCKS_ENABLE_ALL*/ + +#define
>>> CONFIG_SYS_ENABLE_PADS_ALL	/* Enable all PADS for now */
>> 
>> Not allowed.
> Shall see to it. What if one needs to test pins and connections
> during board bring-up, e.g. via gpio commands?

Then code in what you need at the time, drop later.

[snip]
>> This is a little un-clear. If MMC will be in mmc like the uEVM,
>> just do so, and if no storage of env, leave it as NOWHERE.
> Cerrently looks like this: /* MMC ENV related defines */ #undef
> CONFIG_ENV_IS_IN_MMC #undef CONFIG_SYS_MMC_ENV_DEV #undef
> CONFIG_ENV_OFFSET #define CONFIG_ENV_IS_NOWHERE

Shouldn't need that now, omap5_common is common and the env bits got
moved to omap5_uevm.h

[snip]
>>> +/* + * memtest setup + */ +#define CONFIG_SYS_MEMTEST_START
>>> 0xb8000000 +#define CONFIG_SYS_MEMTEST_END
>>> (CONFIG_SYS_MEMTEST_START + (256 << 20)) +/* Undef following
>>> two for simple mtest */ +#define CONFIG_SYS_ALT_MEMTEST 
>>> +#define CONFIG_SYS_MEMTEST_SCRATCH	0x81000000
>> 
>> Please see doc/README.memory-test and update as mtest is no
>> longer a default command.
> Now the config tail looks like this:
> 
> /* Undef/remove after bring-up: */ #define CONFIG_CMD_MEMTEST
> 
> /* Disabled commands */ #undef CONFIG_CMD_SAVEENV
> 
> /* Prompt */ #define CONFIG_SYS_PROMPT		"SOM5_EVB # "
> 
> #ifdef CONFIG_CMD_MEMTEST /* Undef following two for simple mtest
> */ #define CONFIG_SYS_ALT_MEMTEST #define
> CONFIG_SYS_MEMTEST_SCRATCH	0xb7fffff0 #ifdef
> CONFIG_SYS_ALT_MEMTEST #undef CONFIG_SYS_MEMTEST_START #define
> CONFIG_SYS_MEMTEST_START	0xb8000000 #undef CONFIG_SYS_MEMTEST_END 
> #define CONFIG_SYS_MEMTEST_END		(CONFIG_SYS_MEMTEST_START + (256 <<
> 20)) #endif #endif /* CONFIG_CMD_MEMTEST */

OK.

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRkUEQAAoJENk4IS6UOR1WtscP/0RApAXEgttNem+eho1kFJMZ
FSi3UgiO0+XqGbETTyYuG/r6RTz9grDcbtSs9np6/9H3wrc2FjCtlqXygJmQgbmr
2idPh4fyHerFvkZTZexJ3Lr+GC/1cJJyJliPvhj281OujbL/iDICkI/SLsnS3rtA
hDC8MmrWWoDITtLzVNCbzkUk6gZVjFG/49dgjNMrRL9E8ctYp3NXtPK8VA4MpFnz
WWM7qXQAHdBOuPRmixU4XuxHgG7/PAAzXH8Ac5dqFjnas+H8PEHqO90LPJm8tsFS
8dgb2ieQKlLl7yRLyRoQNvLy/B5EKUu+LKp6Yr3UI0oLm1iUnLdplEnKBbxpNHLS
T+gQ7ScVCd/fFrx9oiF2tNurd6dhKTvAm8v7R9cfBAM/PjqZmoZGMAla8nvdw4XY
g41Q1inBVn5w5/QbIzJCDZsWl9CHfoLMUHvGOKXV11NFbhjhY/9eDXwBzQmsKUXr
3dQYnzlCi3MxaZfsnDV9uKNSJ5sn84uBK4t9TanqGMsshen3CN5UU+bKPZKC3yty
OQoxVTTAFnDlyJ+cQL77TmA/zkqDrL61qCrPBwZStX1f9lze1Ht7jcHwIthK3UzD
wORqMKYFs/1DV5N7x7Un298qPGuCq9nPObl9JcCP5QWuhX6RTBn+g8ULYolQTSY0
xWeTauEupQWcZNDUldwK
=D5d3
-----END PGP SIGNATURE-----
Lubomir Popov - May 14, 2013, 10:24 a.m.
Hi Tom,

I'm currently busy with other work; on the other hand, careful
rebasing shall require some time, especially the Palmas stuff.
What would be the deadline for a V2 submission?

Meanwhile could you please have a look at the (already old)
http://patchwork.ozlabs.org/patch/232743/? A simple patch,
shall be needed if we enable USB (for the uEVM along with
our board). In general, what are your plans regarding USB
(.../patch/232742/)?

And again on I2C (.../patch/233823/): what is you final
opinion? I'm confident that this patch is a major improvement
for OMAP4/5 at least.

Please see some more comments inline below.

On 13/05/13 22:37, Tom Rini wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 04/26/2013 11:59 AM, Lubomir Popov wrote:
>> Hi Tom,
>>
>> On 25/04/13 22:01, Tom Rini wrote:
>>> On Mon, Apr 01, 2013 at 05:06:16PM +0300, Lubomir Popov wrote:
>>>
>>>> Signed-off-by: Lubomir Popov <lpopov@mm-sol.com>
>>>
>>> Thought I had reviewed this already, sorry.
>> Thanks for your review. During the past month U-Boot has changed; I
>> have tried to follow as well (although I'm engaged with other
>> stuff) and some of your remarks have been already fixed. Please see
>> my comments inline below.
>>
>> Anyway, I guess that a V2 patch shall have to be referenced against
>> the current master. Or against u-boot-ti/next?
> 
> OK, sorry for the late reply again.  Now that u-boot-arm has resynced
> with master, I've also resynced and gotten a pull done.  You can use
> either u-boot-arm/master or u-boot-ti/master.
> 
>>
>> Please note that for this board to work with the defined
>> configuration, the following patches are also required
>> (unfortunately some are already quite old and might cause 
>> conflicts):
>>
>> - Power: http://patchwork.ozlabs.org/patch/232732/. Potential
>> conflict with Nishanth Menon's series of March 26, applied to
>> u-boot-ti/next. - For I2C support: * The patch series of Apr. 8
>> that enables I2C4 and I2C5 (applied to u-boot-ti/next; affects all
>> OMAP5 boards). * The modified i2c driver:
>> http://patchwork.ozlabs.org/patch/233823/ (useful for all OMAP3/4/5
>> boards). - For USB support: *
>> http://patchwork.ozlabs.org/patch/235684/ (affects all OMAP5
>> boards) * http://patchwork.ozlabs.org/patch/232742/ (affects all
>> OMAP5 boards)
> 
> OK.  Please make sure these still apply and if not update and re-send.
>  I think I've already grabbed a few of these.
> 
> [snip]
>>>> +#define USB_HOST_HS_CLKCTRL_MASK	0x0100D7C0	/*
>>>> CM_L3INIT_USB_HOST_HS_CLKCTRL */ +#define
>>>> USB_TLL_HS_CLKCTRL_MASK		0x00000700	/*
>>>> CM_L3INIT_USB_TLL_HS_CLKCTRL */
>>>
>>> Some header please.
>> Currently moved to board header. I wondered if a common OMAP header
>> wouldn't be more suitable, but having in mind that the utilized USB
>> ports (and thus the clocks that should be enabled) vary from board
>> to board, perhaps this (i.e. board header) is the best place.
> 
> The masks won't change tho, yes?  Common header somewhere.
These are in fact not masks, but enable bits (sort of confusing
terminology found throughout TI headers). Now renamed to
..._CLKCTRL_EN; staying in board header.
> 
>>>
>>>> +	 * TODO: Replace this ugly hardcoding with proper defines +
>>>> */ +	writel(0x0100, 0x4ae0a310);
>>>
>>> Again, do please.
>> This should be (*scrm)->auxclk0. The problem is that the
>> omap5_scrm_regs struct (holding the auxclk0 member) has to be
>> defined somewhere in the common OMAP5 headers. Sricharan? Or should
>> I hack around?
> 
> Add it to the most likely struct in the headers.
The entire struct (I call it omap5_scrm_regs in theory, similar to the
corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of
course I could define only the member that I need, but I guess it is
a (responsible) TI job to define hardware descriptors. Or I'm wrong?
Please advise. If I have time, I could do it myself - it's some 27
registers, almost identical to the OMAP4, and should go into 
arch/arm/include/asm/arch-omap5/clocks.h.
> 
> [snip]
>>> Ah, since you do have this part already, just update the rest as
>>> I had said.
>> /* Machine type for Linux */ #ifndef MACH_TYPE_SOM5_EVB #define
>> MACH_TYPE_SOM5_EVB		4545 #endif #define CONFIG_MACH_TYPE
>> MACH_TYPE_SOM5_EVB
>>
>> Is this OK?
> 
> I think we'd decided in general to not do ifndef and just always
> define it.
> 
>>>> +/* Enable all clocks: */ +/*#define
>>>> CONFIG_SYS_CLOCKS_ENABLE_ALL*/ + +#define
>>>> CONFIG_SYS_ENABLE_PADS_ALL	/* Enable all PADS for now */
>>>
>>> Not allowed.
>> Shall see to it. What if one needs to test pins and connections
>> during board bring-up, e.g. via gpio commands?
> 
> Then code in what you need at the time, drop later.
> 
> [snip]
>>> This is a little un-clear. If MMC will be in mmc like the uEVM,
>>> just do so, and if no storage of env, leave it as NOWHERE.
>> Cerrently looks like this: /* MMC ENV related defines */ #undef
>> CONFIG_ENV_IS_IN_MMC #undef CONFIG_SYS_MMC_ENV_DEV #undef
>> CONFIG_ENV_OFFSET #define CONFIG_ENV_IS_NOWHERE
> 
> Shouldn't need that now, omap5_common is common and the env bits got
> moved to omap5_uevm.h
> 
> [snip]
>>>> +/* + * memtest setup + */ +#define CONFIG_SYS_MEMTEST_START
>>>> 0xb8000000 +#define CONFIG_SYS_MEMTEST_END
>>>> (CONFIG_SYS_MEMTEST_START + (256 << 20)) +/* Undef following
>>>> two for simple mtest */ +#define CONFIG_SYS_ALT_MEMTEST 
>>>> +#define CONFIG_SYS_MEMTEST_SCRATCH	0x81000000
>>>
>>> Please see doc/README.memory-test and update as mtest is no
>>> longer a default command.
>> Now the config tail looks like this:
>>
>> /* Undef/remove after bring-up: */ #define CONFIG_CMD_MEMTEST
>>
>> /* Disabled commands */ #undef CONFIG_CMD_SAVEENV
>>
>> /* Prompt */ #define CONFIG_SYS_PROMPT		"SOM5_EVB # "
>>
>> #ifdef CONFIG_CMD_MEMTEST /* Undef following two for simple mtest
>> */ #define CONFIG_SYS_ALT_MEMTEST #define
>> CONFIG_SYS_MEMTEST_SCRATCH	0xb7fffff0 #ifdef
>> CONFIG_SYS_ALT_MEMTEST #undef CONFIG_SYS_MEMTEST_START #define
>> CONFIG_SYS_MEMTEST_START	0xb8000000 #undef CONFIG_SYS_MEMTEST_END 
>> #define CONFIG_SYS_MEMTEST_END		(CONFIG_SYS_MEMTEST_START + (256 <<
>> 20)) #endif #endif /* CONFIG_CMD_MEMTEST */
> 
> OK.
> 
> - -- 
> Tom
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBAgAGBQJRkUEQAAoJENk4IS6UOR1WtscP/0RApAXEgttNem+eho1kFJMZ
> FSi3UgiO0+XqGbETTyYuG/r6RTz9grDcbtSs9np6/9H3wrc2FjCtlqXygJmQgbmr
> 2idPh4fyHerFvkZTZexJ3Lr+GC/1cJJyJliPvhj281OujbL/iDICkI/SLsnS3rtA
> hDC8MmrWWoDITtLzVNCbzkUk6gZVjFG/49dgjNMrRL9E8ctYp3NXtPK8VA4MpFnz
> WWM7qXQAHdBOuPRmixU4XuxHgG7/PAAzXH8Ac5dqFjnas+H8PEHqO90LPJm8tsFS
> 8dgb2ieQKlLl7yRLyRoQNvLy/B5EKUu+LKp6Yr3UI0oLm1iUnLdplEnKBbxpNHLS
> T+gQ7ScVCd/fFrx9oiF2tNurd6dhKTvAm8v7R9cfBAM/PjqZmoZGMAla8nvdw4XY
> g41Q1inBVn5w5/QbIzJCDZsWl9CHfoLMUHvGOKXV11NFbhjhY/9eDXwBzQmsKUXr
> 3dQYnzlCi3MxaZfsnDV9uKNSJ5sn84uBK4t9TanqGMsshen3CN5UU+bKPZKC3yty
> OQoxVTTAFnDlyJ+cQL77TmA/zkqDrL61qCrPBwZStX1f9lze1Ht7jcHwIthK3UzD
> wORqMKYFs/1DV5N7x7Un298qPGuCq9nPObl9JcCP5QWuhX6RTBn+g8ULYolQTSY0
> xWeTauEupQWcZNDUldwK
> =D5d3
> -----END PGP SIGNATURE-----
> 

Best regards,
Lubo
Tom Rini - May 14, 2013, 2:52 p.m.
On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote:
> Hi Tom,
> 
> I'm currently busy with other work; on the other hand, careful
> rebasing shall require some time, especially the Palmas stuff.
> What would be the deadline for a V2 submission?
> 
> Meanwhile could you please have a look at the (already old)
> http://patchwork.ozlabs.org/patch/232743/? A simple patch,
> shall be needed if we enable USB (for the uEVM along with
> our board). In general, what are your plans regarding USB
> (.../patch/232742/)?

Thanks for the reminder, I'll grab 232743 soon.  232742 looks OK, but do
you have a patch around for uEVM still?

> And again on I2C (.../patch/233823/): what is you final
> opinion? I'm confident that this patch is a major improvement
> for OMAP4/5 at least.

I'm inclined to go with it, just need to mentally unswap the i2c notes
in my brain and think it over one more time.

[snip]
> >>>> +	 * TODO: Replace this ugly hardcoding with proper defines +
> >>>> */ +	writel(0x0100, 0x4ae0a310);
> >>>
> >>> Again, do please.
> >> This should be (*scrm)->auxclk0. The problem is that the
> >> omap5_scrm_regs struct (holding the auxclk0 member) has to be
> >> defined somewhere in the common OMAP5 headers. Sricharan? Or should
> >> I hack around?
> > 
> > Add it to the most likely struct in the headers.
> The entire struct (I call it omap5_scrm_regs in theory, similar to the
> corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of
> course I could define only the member that I need, but I guess it is
> a (responsible) TI job to define hardware descriptors. Or I'm wrong?
> Please advise. If I have time, I could do it myself - it's some 27
> registers, almost identical to the OMAP4, and should go into 
> arch/arm/include/asm/arch-omap5/clocks.h.

Whomever uses / needs it should do it.  I gave the TRM a quick read and
I don't see any conflicts per-se just some reserved areas being named
and vice versa.  So rename it to omap_scrm_regs and move to
<asm/omap_common.h>.  Thanks!
Lubomir Popov - May 14, 2013, 4:09 p.m.
Hi Tom,

On 14/05/13 17:52, Tom Rini wrote:
> On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote:
>> Hi Tom,
>>
>> I'm currently busy with other work; on the other hand, careful
>> rebasing shall require some time, especially the Palmas stuff.
>> What would be the deadline for a V2 submission?
>>
>> Meanwhile could you please have a look at the (already old)
>> http://patchwork.ozlabs.org/patch/232743/? A simple patch,
>> shall be needed if we enable USB (for the uEVM along with
>> our board). In general, what are your plans regarding USB
>> (.../patch/232742/)?
> 
> Thanks for the reminder, I'll grab 232743 soon.  232742 looks OK, but do
> you have a patch around for uEVM still?
Not yet (didn't have the opportunity to test, although some uEVMs should
be around at MMS). As you know, a patch shall be needed in the uEVM board
file along with the common USB stuff.
> 
>> And again on I2C (.../patch/233823/): what is you final
>> opinion? I'm confident that this patch is a major improvement
>> for OMAP4/5 at least.
> 
> I'm inclined to go with it, just need to mentally unswap the i2c notes
> in my brain and think it over one more time.
Just applied 233823 to current u-boot-ti master. Works fine.
> 
> [snip]
>>>>>> +	 * TODO: Replace this ugly hardcoding with proper defines +
>>>>>> */ +	writel(0x0100, 0x4ae0a310);
>>>>>
>>>>> Again, do please.
>>>> This should be (*scrm)->auxclk0. The problem is that the
>>>> omap5_scrm_regs struct (holding the auxclk0 member) has to be
>>>> defined somewhere in the common OMAP5 headers. Sricharan? Or should
>>>> I hack around?
>>>
>>> Add it to the most likely struct in the headers.
>> The entire struct (I call it omap5_scrm_regs in theory, similar to the
>> corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of
>> course I could define only the member that I need, but I guess it is
>> a (responsible) TI job to define hardware descriptors. Or I'm wrong?
>> Please advise. If I have time, I could do it myself - it's some 27
>> registers, almost identical to the OMAP4, and should go into 
>> arch/arm/include/asm/arch-omap5/clocks.h.
> 
> Whomever uses / needs it should do it.  I gave the TRM a quick read and
> I don't see any conflicts per-se just some reserved areas being named
> and vice versa.  So rename it to omap_scrm_regs and move to
> <asm/omap_common.h>.  Thanks!
I would argue that this is not very appropriate. Those regs that are
reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4;
on the other hand the OMAP5 has some modem clock regs that are reserved
on OMAP4. We shall probably have ugly #ifdefs again. And what about OMAP3
and below?

Currently the scrm struct is defined for OMAP4 in the asm/arch-omap4/clocks.h
file and I have already done the same for OMAP5 by analogy. I must admit
however that this approach does not correspond to the latest way by which
groups of OMAP hardware regs are defined, prcm in particular - a struct in
omap_common.h, holding only the required regs, no padding and such garbage,
and an init with the physical addresses in a .c file for the particular SoC
(prcm-regs.c). But still the Panda board, for example, uses the old way for
scrm. Therefore I did it the same for OMAP5, which was easier (I'm old and
lazy ;) ).

Otherwise (a struct in omap_common.h) we shall need new scrm-regs.c files for
every OMAP flavor. Which way to go?

Regards,
Lubo
Tom Rini - May 14, 2013, 4:41 p.m.
On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote:
> Hi Tom,
> 
> On 14/05/13 17:52, Tom Rini wrote:
> > On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote:
> >> Hi Tom,
> >>
> >> I'm currently busy with other work; on the other hand, careful
> >> rebasing shall require some time, especially the Palmas stuff.
> >> What would be the deadline for a V2 submission?
> >>
> >> Meanwhile could you please have a look at the (already old)
> >> http://patchwork.ozlabs.org/patch/232743/? A simple patch,
> >> shall be needed if we enable USB (for the uEVM along with
> >> our board). In general, what are your plans regarding USB
> >> (.../patch/232742/)?
> > 
> > Thanks for the reminder, I'll grab 232743 soon.  232742 looks OK, but do
> > you have a patch around for uEVM still?
> Not yet (didn't have the opportunity to test, although some uEVMs should
> be around at MMS). As you know, a patch shall be needed in the uEVM board
> file along with the common USB stuff.

Yeah, I can test it as well if you write it up, and may find the time if
you point me in the right direction.

> >> And again on I2C (.../patch/233823/): what is you final
> >> opinion? I'm confident that this patch is a major improvement
> >> for OMAP4/5 at least.
> > 
> > I'm inclined to go with it, just need to mentally unswap the i2c notes
> > in my brain and think it over one more time.
> Just applied 233823 to current u-boot-ti master. Works fine.

OK, thanks.

> > [snip]
> >>>>>> +	 * TODO: Replace this ugly hardcoding with proper defines +
> >>>>>> */ +	writel(0x0100, 0x4ae0a310);
> >>>>>
> >>>>> Again, do please.
> >>>> This should be (*scrm)->auxclk0. The problem is that the
> >>>> omap5_scrm_regs struct (holding the auxclk0 member) has to be
> >>>> defined somewhere in the common OMAP5 headers. Sricharan? Or should
> >>>> I hack around?
> >>>
> >>> Add it to the most likely struct in the headers.
> >> The entire struct (I call it omap5_scrm_regs in theory, similar to the
> >> corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of
> >> course I could define only the member that I need, but I guess it is
> >> a (responsible) TI job to define hardware descriptors. Or I'm wrong?
> >> Please advise. If I have time, I could do it myself - it's some 27
> >> registers, almost identical to the OMAP4, and should go into 
> >> arch/arm/include/asm/arch-omap5/clocks.h.
> > 
> > Whomever uses / needs it should do it.  I gave the TRM a quick read and
> > I don't see any conflicts per-se just some reserved areas being named
> > and vice versa.  So rename it to omap_scrm_regs and move to
> > <asm/omap_common.h>.  Thanks!
> I would argue that this is not very appropriate. Those regs that are
> reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4;
> on the other hand the OMAP5 has some modem clock regs that are reserved
> on OMAP4. We shall probably have ugly #ifdefs again. And what about OMAP3
> and below?

We don't need to use ifdefs since there's no conflicts, things are
either reserved in one case and used in the other.  And we can make sure
we don't try and use the omap5 bits on omap4 and vice versa.  I don't
see scrm in the first omap3 TRM I pulled up, so we don't need to worry
there.

> Currently the scrm struct is defined for OMAP4 in the asm/arch-omap4/clocks.h
> file and I have already done the same for OMAP5 by analogy. I must admit
> however that this approach does not correspond to the latest way by which
> groups of OMAP hardware regs are defined, prcm in particular - a struct in
> omap_common.h, holding only the required regs, no padding and such garbage,
> and an init with the physical addresses in a .c file for the particular SoC
> (prcm-regs.c). But still the Panda board, for example, uses the old way for
> scrm. Therefore I did it the same for OMAP5, which was easier (I'm old and
> lazy ;) ).

Yes, I'm OK starting off with moving things into omap_common.h as-is and
then updating them a bit later ala pcrm-regs.c.
Lubomir Popov - May 14, 2013, 7:42 p.m.
Hi Tom,

Just a couple of things to clarify below.

> On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote:
>> Hi Tom,
>>
>> On 14/05/13 17:52, Tom Rini wrote:
>> > On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote:
>> >> Hi Tom,
>> >>
>> >> I'm currently busy with other work; on the other hand, careful
>> >> rebasing shall require some time, especially the Palmas stuff.
>> >> What would be the deadline for a V2 submission?
>> >>
>> >> Meanwhile could you please have a look at the (already old)
>> >> http://patchwork.ozlabs.org/patch/232743/? A simple patch,
>> >> shall be needed if we enable USB (for the uEVM along with
>> >> our board). In general, what are your plans regarding USB
>> >> (.../patch/232742/)?
>> >
>> > Thanks for the reminder, I'll grab 232743 soon.  232742 looks OK, but
>> do
>> > you have a patch around for uEVM still?
>> Not yet (didn't have the opportunity to test, although some uEVMs should
>> be around at MMS). As you know, a patch shall be needed in the uEVM
>> board
>> file along with the common USB stuff.
>
> Yeah, I can test it as well if you write it up, and may find the time if
> you point me in the right direction.
OK, shall do it.
>
>> >> And again on I2C (.../patch/233823/): what is you final
>> >> opinion? I'm confident that this patch is a major improvement
>> >> for OMAP4/5 at least.
>> >
>> > I'm inclined to go with it, just need to mentally unswap the i2c notes
>> > in my brain and think it over one more time.
>> Just applied 233823 to current u-boot-ti master. Works fine.
>
> OK, thanks.
Just to avoid confusion: I applied it and tested on a locally cloned
version of u-boot-ti, not upstream (don't laugh please; just want to
clarify for those who don't know that it is your job).
>
>> > [snip]

>> Currently the scrm struct is defined for OMAP4 in the
>> asm/arch-omap4/clocks.h
>> file and I have already done the same for OMAP5 by analogy. I must admit
>> however that this approach does not correspond to the latest way by
>> which
>> groups of OMAP hardware regs are defined, prcm in particular - a struct
>> in
>> omap_common.h, holding only the required regs, no padding and such
>> garbage,
>> and an init with the physical addresses in a .c file for the particular
>> SoC
>> (prcm-regs.c). But still the Panda board, for example, uses the old way
>> for
>> scrm. Therefore I did it the same for OMAP5, which was easier (I'm old
>> and
>> lazy ;) ).
>
> Yes, I'm OK starting off with moving things into omap_common.h as-is and
> then updating them a bit later ala pcrm-regs.c.
Who is starting off, me or you? ;)
>
> --
> Tom
>
BR,
Lubo
Tom Rini - May 14, 2013, 8:36 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/14/2013 03:42 PM, Lubomir Popov wrote:
> Hi Tom,
> 
> Just a couple of things to clarify below.
> 
>> On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote:
>>> Hi Tom,
>>> 
>>> On 14/05/13 17:52, Tom Rini wrote:
>>>> On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov 
>>>> wrote:
>>>>> Hi Tom,
>>>>> 
>>>>> I'm currently busy with other work; on the other hand, 
>>>>> careful rebasing shall require some time, especially the 
>>>>> Palmas stuff. What would be the deadline for a V2 
>>>>> submission?
>>>>> 
>>>>> Meanwhile could you please have a look at the (already old)
>>>>> http://patchwork.ozlabs.org/patch/232743/? A simple patch,
>>>>> shall be needed if we enable USB (for the uEVM along with
>>>>> our board). In general, what are your plans regarding USB
>>>>> (.../patch/232742/)?
>>>> 
>>>> Thanks for the reminder, I'll grab 232743 soon.  232742
>>>> looks OK, but
>>> do
>>>> you have a patch around for uEVM still?
>>> Not yet (didn't have the opportunity to test, although some 
>>> uEVMs should be around at MMS). As you know, a patch shall be 
>>> needed in the uEVM board file along with the common USB stuff.
>> 
>> Yeah, I can test it as well if you write it up, and may find the 
>> time if you point me in the right direction.
> OK, shall do it.

Thanks!

[snip]
>>>> [snip]
>>> Currently the scrm struct is defined for OMAP4 in the 
>>> asm/arch-omap4/clocks.h file and I have already done the same 
>>> for OMAP5 by analogy. I must admit however that this approach 
>>> does not correspond to the latest way by which groups of OMAP 
>>> hardware regs are defined, prcm in particular - a struct in 
>>> omap_common.h, holding only the required regs, no padding and 
>>> such garbage, and an init with the physical addresses in a .c 
>>> file for the particular SoC (prcm-regs.c). But still the Panda 
>>> board, for example, uses the old way for scrm. Therefore I did 
>>> it the same for OMAP5, which was easier (I'm old and lazy ;) 
>>> ).
>> 
>> Yes, I'm OK starting off with moving things into omap_common.h 
>> as-is and then updating them a bit later ala pcrm-regs.c.
> Who is starting off, me or you? ;)

Since your series needs it (so we aren't writing to magic locations
which isn't allowed), you please.  Thanks!

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRkqBgAAoJENk4IS6UOR1WFVcQAIo9DgrABUaAwOTfYFXVlGQ6
/MFyQvtwFYtEwW1xtDZ8RWuv1zGI26IIw4XH+xhspj50w7ma9lji575U/tyQCtrN
G6xMW8bH/8Cxj+kFUcgeNXSqAF0OLOz8Rvow9dSW2RpnOu3yOPKnvgxjV974x595
IfBK26Xo5ldR6qX12EIwAfHZVRow97Kk25LOBoqR+qxTBrtKPWzywXyvTi94qY/b
jcy9L17AQQvNWQofps7noDsFM+acWlQxsTkjbdkynDu8gIQC0JZ8cEUPZ9XsYg+D
8SvXeY5ntCEOwxvB2TZ2GNC9/J5fVXMmewrexH1AdjsO1d0529ZjCX0995whV2pJ
xCYi0FAtXKW0fm1gitMXZ0J/pHzNdsr1s+rV0iUtppbhh9mQ+NQplXVPevB0UrWH
1UHHxe1Hsc5ZJHJRvvFyVAo9ySdZ85zrS6+TlMwfjK1LWtQmPJ0DA1Cddz8m/BI+
6ebQ36qgJuO990YhQ9GlfOV1rjp3RhrCmb+JKwjMN0OahnfAEvp4osCvbMClDXqT
VL83+gP1lKJ47B2VfuyqXW+ETBV6hhLprItj8wx+0sJx0rNKc98Q61pO8XSPZwoE
8hWzqeY7Dmlp2QxQ3ZyD5w5+DECGbj7ihCICkjquwHSB5v1R4R1XIwlV/3cd/Mm4
SMnFtv8rUQsfzi48bGt4
=lJAv
-----END PGP SIGNATURE-----
SRICHARAN R - May 15, 2013, 5:11 a.m.
Hi,
On Tuesday 14 May 2013 10:11 PM, Tom Rini wrote:
> On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote:
>> Hi Tom,
>>
>> On 14/05/13 17:52, Tom Rini wrote:
>>> On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote:
>>>> Hi Tom,
>>>>
>>>> I'm currently busy with other work; on the other hand, careful
>>>> rebasing shall require some time, especially the Palmas stuff.
>>>> What would be the deadline for a V2 submission?
>>>>
>>>> Meanwhile could you please have a look at the (already old)
>>>> http://patchwork.ozlabs.org/patch/232743/? A simple patch,
>>>> shall be needed if we enable USB (for the uEVM along with
>>>> our board). In general, what are your plans regarding USB
>>>> (.../patch/232742/)?
>>> Thanks for the reminder, I'll grab 232743 soon.  232742 looks OK, but do
>>> you have a patch around for uEVM still?
>> Not yet (didn't have the opportunity to test, although some uEVMs should
>> be around at MMS). As you know, a patch shall be needed in the uEVM board
>> file along with the common USB stuff.
> Yeah, I can test it as well if you write it up, and may find the time if
> you point me in the right direction.
>
>>>> And again on I2C (.../patch/233823/): what is you final
>>>> opinion? I'm confident that this patch is a major improvement
>>>> for OMAP4/5 at least.
>>> I'm inclined to go with it, just need to mentally unswap the i2c notes
>>> in my brain and think it over one more time.
>> Just applied 233823 to current u-boot-ti master. Works fine.
> OK, thanks.
>
>>> [snip]
>>>>>>>> +	 * TODO: Replace this ugly hardcoding with proper defines +
>>>>>>>> */ +	writel(0x0100, 0x4ae0a310);
>>>>>>> Again, do please.
>>>>>> This should be (*scrm)->auxclk0. The problem is that the
>>>>>> omap5_scrm_regs struct (holding the auxclk0 member) has to be
>>>>>> defined somewhere in the common OMAP5 headers. Sricharan? Or should
>>>>>> I hack around?
>>>>> Add it to the most likely struct in the headers.
>>>> The entire struct (I call it omap5_scrm_regs in theory, similar to the
>>>> corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of
>>>> course I could define only the member that I need, but I guess it is
>>>> a (responsible) TI job to define hardware descriptors. Or I'm wrong?
>>>> Please advise. If I have time, I could do it myself - it's some 27
>>>> registers, almost identical to the OMAP4, and should go into 
>>>> arch/arm/include/asm/arch-omap5/clocks.h.
>>> Whomever uses / needs it should do it.  I gave the TRM a quick read and
>>> I don't see any conflicts per-se just some reserved areas being named
>>> and vice versa.  So rename it to omap_scrm_regs and move to
>>> <asm/omap_common.h>.  Thanks!
>> I would argue that this is not very appropriate. Those regs that are
>> reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4;
>> on the other hand the OMAP5 has some modem clock regs that are reserved
>> on OMAP4. We shall probably have ugly #ifdefs again. And what about OMAP3
>> and below?
> We don't need to use ifdefs since there's no conflicts, things are
> either reserved in one case and used in the other.  And we can make sure
> we don't try and use the omap5 bits on omap4 and vice versa.  I don't
> see scrm in the first omap3 TRM I pulled up, so we don't need to worry
> there.
>
>> Currently the scrm struct is defined for OMAP4 in the asm/arch-omap4/clocks.h
>> file and I have already done the same for OMAP5 by analogy. I must admit
>> however that this approach does not correspond to the latest way by which
>> groups of OMAP hardware regs are defined, prcm in particular - a struct in
>> omap_common.h, holding only the required regs, no padding and such garbage,
>> and an init with the physical addresses in a .c file for the particular SoC
>> (prcm-regs.c). But still the Panda board, for example, uses the old way for
>> scrm. Therefore I did it the same for OMAP5, which was easier (I'm old and
>> lazy ;) ).
> Yes, I'm OK starting off with moving things into omap_common.h as-is and
> then updating them a bit later ala pcrm-regs.c.
>
>
 I am sorry for the very late response on this.
 Now then, why not add this register in to omap5_es2_prcm
 ??. That is how the  TRM sees it as well.. Of course, this is cleanup
 stuff for OMAP4  panda as you pointed out..

Regards,
 Sricharan
 

>
> _______________________________________________
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
Lubomir Popov - May 15, 2013, 7:55 a.m.
Hi Sricharan,

On 15/05/13 08:11, Sricharan R wrote:
> Hi,
> On Tuesday 14 May 2013 10:11 PM, Tom Rini wrote:
>> On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote:
>>> Hi Tom,
>>>
>>> On 14/05/13 17:52, Tom Rini wrote:
>>>> On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote:
>>>>> Hi Tom,
>>>>>
>>>>> I'm currently busy with other work; on the other hand, careful
>>>>> rebasing shall require some time, especially the Palmas stuff.
>>>>> What would be the deadline for a V2 submission?
>>>>>
>>>>> Meanwhile could you please have a look at the (already old)
>>>>> http://patchwork.ozlabs.org/patch/232743/? A simple patch,
>>>>> shall be needed if we enable USB (for the uEVM along with
>>>>> our board). In general, what are your plans regarding USB
>>>>> (.../patch/232742/)?
>>>> Thanks for the reminder, I'll grab 232743 soon.  232742 looks OK, but do
>>>> you have a patch around for uEVM still?
>>> Not yet (didn't have the opportunity to test, although some uEVMs should
>>> be around at MMS). As you know, a patch shall be needed in the uEVM board
>>> file along with the common USB stuff.
>> Yeah, I can test it as well if you write it up, and may find the time if
>> you point me in the right direction.
>>
>>>>> And again on I2C (.../patch/233823/): what is you final
>>>>> opinion? I'm confident that this patch is a major improvement
>>>>> for OMAP4/5 at least.
>>>> I'm inclined to go with it, just need to mentally unswap the i2c notes
>>>> in my brain and think it over one more time.
>>> Just applied 233823 to current u-boot-ti master. Works fine.
>> OK, thanks.
>>
>>>> [snip]
>>>>>>>>> +	 * TODO: Replace this ugly hardcoding with proper defines +
>>>>>>>>> */ +	writel(0x0100, 0x4ae0a310);
>>>>>>>> Again, do please.
>>>>>>> This should be (*scrm)->auxclk0. The problem is that the
>>>>>>> omap5_scrm_regs struct (holding the auxclk0 member) has to be
>>>>>>> defined somewhere in the common OMAP5 headers. Sricharan? Or should
>>>>>>> I hack around?
>>>>>> Add it to the most likely struct in the headers.
>>>>> The entire struct (I call it omap5_scrm_regs in theory, similar to the
>>>>> corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of
>>>>> course I could define only the member that I need, but I guess it is
>>>>> a (responsible) TI job to define hardware descriptors. Or I'm wrong?
>>>>> Please advise. If I have time, I could do it myself - it's some 27
>>>>> registers, almost identical to the OMAP4, and should go into 
>>>>> arch/arm/include/asm/arch-omap5/clocks.h.
>>>> Whomever uses / needs it should do it.  I gave the TRM a quick read and
>>>> I don't see any conflicts per-se just some reserved areas being named
>>>> and vice versa.  So rename it to omap_scrm_regs and move to
>>>> <asm/omap_common.h>.  Thanks!
>>> I would argue that this is not very appropriate. Those regs that are
>>> reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4;
>>> on the other hand the OMAP5 has some modem clock regs that are reserved
>>> on OMAP4. We shall probably have ugly #ifdefs again. And what about OMAP3
>>> and below?
>> We don't need to use ifdefs since there's no conflicts, things are
>> either reserved in one case and used in the other.  And we can make sure
>> we don't try and use the omap5 bits on omap4 and vice versa.  I don't
>> see scrm in the first omap3 TRM I pulled up, so we don't need to worry
>> there.
>>
>>> Currently the scrm struct is defined for OMAP4 in the asm/arch-omap4/clocks.h
>>> file and I have already done the same for OMAP5 by analogy. I must admit
>>> however that this approach does not correspond to the latest way by which
>>> groups of OMAP hardware regs are defined, prcm in particular - a struct in
>>> omap_common.h, holding only the required regs, no padding and such garbage,
>>> and an init with the physical addresses in a .c file for the particular SoC
>>> (prcm-regs.c). But still the Panda board, for example, uses the old way for
>>> scrm. Therefore I did it the same for OMAP5, which was easier (I'm old and
>>> lazy ;) ).
>> Yes, I'm OK starting off with moving things into omap_common.h as-is and
>> then updating them a bit later ala pcrm-regs.c.
>>
>>
>  I am sorry for the very late response on this.
>  Now then, why not add this register in to omap5_es2_prcm
>  ??. That is how the  TRM sees it as well.. Of course, this is cleanup
>  stuff for OMAP4  panda as you pointed out..

Yes, you are right in respect to fluent software integration and consistency
with current implementation. My only concern is that from architectural point
of view the SCRM, although related to the PRCM, is a separate module (described
correspondingly as such in the TRM). If we go this way, the SCRM regs shall
have to be referenced via the prcm pointer: (*prcm)->xxxxx, and this might be
confusing.

I'm OK to do it as above, that is, add the SCRM regs (for both OMAP4 and OMAP5)
to the prcm_regs declaration in omap_common.h, and the required init to the
appropriate omap5_esx_prcm in prcm-regs.c, but would suggest that for improved
clarity the SCRM register names, as they now exist in .../arch-omap4/clocks.h,
start with a scrm_ prefix.

Alternatively, a new scrm_regs struct could be declared in omap_common.h, along
with the appropriate pointers, and the corresponding definitions/inits added as
new structs in prcm-regs.c for every SoC. But then the file name prcm-regs shall
be a bit confusing.

What do you say?
> 
> Regards,
>  Sricharan
>  
> 
>>
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
> 

Best regards,
Lubo
SRICHARAN R - May 15, 2013, 9:04 a.m.
Hi,

On Wednesday 15 May 2013 01:25 PM, Lubomir Popov wrote:
> Hi Sricharan,
>
> On 15/05/13 08:11, Sricharan R wrote:
>> Hi,
>> On Tuesday 14 May 2013 10:11 PM, Tom Rini wrote:
>>> On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote:
>>>> Hi Tom,
>>>>
>>>> On 14/05/13 17:52, Tom Rini wrote:
>>>>> On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote:
>>>>>> Hi Tom,
>>>>>>
>>>>>> I'm currently busy with other work; on the other hand, careful
>>>>>> rebasing shall require some time, especially the Palmas stuff.
>>>>>> What would be the deadline for a V2 submission?
>>>>>>
>>>>>> Meanwhile could you please have a look at the (already old)
>>>>>> http://patchwork.ozlabs.org/patch/232743/? A simple patch,
>>>>>> shall be needed if we enable USB (for the uEVM along with
>>>>>> our board). In general, what are your plans regarding USB
>>>>>> (.../patch/232742/)?
>>>>> Thanks for the reminder, I'll grab 232743 soon.  232742 looks OK, but do
>>>>> you have a patch around for uEVM still?
>>>> Not yet (didn't have the opportunity to test, although some uEVMs should
>>>> be around at MMS). As you know, a patch shall be needed in the uEVM board
>>>> file along with the common USB stuff.
>>> Yeah, I can test it as well if you write it up, and may find the time if
>>> you point me in the right direction.
>>>
>>>>>> And again on I2C (.../patch/233823/): what is you final
>>>>>> opinion? I'm confident that this patch is a major improvement
>>>>>> for OMAP4/5 at least.
>>>>> I'm inclined to go with it, just need to mentally unswap the i2c notes
>>>>> in my brain and think it over one more time.
>>>> Just applied 233823 to current u-boot-ti master. Works fine.
>>> OK, thanks.
>>>
>>>>> [snip]
>>>>>>>>>> +	 * TODO: Replace this ugly hardcoding with proper defines +
>>>>>>>>>> */ +	writel(0x0100, 0x4ae0a310);
>>>>>>>>> Again, do please.
>>>>>>>> This should be (*scrm)->auxclk0. The problem is that the
>>>>>>>> omap5_scrm_regs struct (holding the auxclk0 member) has to be
>>>>>>>> defined somewhere in the common OMAP5 headers. Sricharan? Or should
>>>>>>>> I hack around?
>>>>>>> Add it to the most likely struct in the headers.
>>>>>> The entire struct (I call it omap5_scrm_regs in theory, similar to the
>>>>>> corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of
>>>>>> course I could define only the member that I need, but I guess it is
>>>>>> a (responsible) TI job to define hardware descriptors. Or I'm wrong?
>>>>>> Please advise. If I have time, I could do it myself - it's some 27
>>>>>> registers, almost identical to the OMAP4, and should go into 
>>>>>> arch/arm/include/asm/arch-omap5/clocks.h.
>>>>> Whomever uses / needs it should do it.  I gave the TRM a quick read and
>>>>> I don't see any conflicts per-se just some reserved areas being named
>>>>> and vice versa.  So rename it to omap_scrm_regs and move to
>>>>> <asm/omap_common.h>.  Thanks!
>>>> I would argue that this is not very appropriate. Those regs that are
>>>> reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4;
>>>> on the other hand the OMAP5 has some modem clock regs that are reserved
>>>> on OMAP4. We shall probably have ugly #ifdefs again. And what about OMAP3
>>>> and below?
>>> We don't need to use ifdefs since there's no conflicts, things are
>>> either reserved in one case and used in the other.  And we can make sure
>>> we don't try and use the omap5 bits on omap4 and vice versa.  I don't
>>> see scrm in the first omap3 TRM I pulled up, so we don't need to worry
>>> there.
>>>
>>>> Currently the scrm struct is defined for OMAP4 in the asm/arch-omap4/clocks.h
>>>> file and I have already done the same for OMAP5 by analogy. I must admit
>>>> however that this approach does not correspond to the latest way by which
>>>> groups of OMAP hardware regs are defined, prcm in particular - a struct in
>>>> omap_common.h, holding only the required regs, no padding and such garbage,
>>>> and an init with the physical addresses in a .c file for the particular SoC
>>>> (prcm-regs.c). But still the Panda board, for example, uses the old way for
>>>> scrm. Therefore I did it the same for OMAP5, which was easier (I'm old and
>>>> lazy ;) ).
>>> Yes, I'm OK starting off with moving things into omap_common.h as-is and
>>> then updating them a bit later ala pcrm-regs.c.
>>>
>>>
>>  I am sorry for the very late response on this.
>>  Now then, why not add this register in to omap5_es2_prcm
>>  ??. That is how the  TRM sees it as well.. Of course, this is cleanup
>>  stuff for OMAP4  panda as you pointed out..
> Yes, you are right in respect to fluent software integration and consistency
> with current implementation. My only concern is that from architectural point
> of view the SCRM, although related to the PRCM, is a separate module (described
> correspondingly as such in the TRM). If we go this way, the SCRM regs shall
> have to be referenced via the prcm pointer: (*prcm)->xxxxx, and this might be
> confusing.
>
> I'm OK to do it as above, that is, add the SCRM regs (for both OMAP4 and OMAP5)
> to the prcm_regs declaration in omap_common.h, and the required init to the
> appropriate omap5_esx_prcm in prcm-regs.c, but would suggest that for improved
> clarity the SCRM register names, as they now exist in .../arch-omap4/clocks.h,
> start with a scrm_ prefix.
>
> Alternatively, a new scrm_regs struct could be declared in omap_common.h, along
> with the appropriate pointers, and the corresponding definitions/inits added as
> new structs in prcm-regs.c for every SoC. But then the file name prcm-regs shall
> be a bit confusing.
>
> What do you say?
  At this point , i think just adding only the registers that you need in to the
 prcm structure should be ok.

Regards,
 Sricharan
Lubomir Popov - May 15, 2013, 10:46 a.m.
Hi Sricharan,

On 15/05/13 12:04, Sricharan R wrote:
> Hi,
> 
> On Wednesday 15 May 2013 01:25 PM, Lubomir Popov wrote:
>> Hi Sricharan,
>>
>> On 15/05/13 08:11, Sricharan R wrote:
>>> Hi,
>>> On Tuesday 14 May 2013 10:11 PM, Tom Rini wrote:
>>>> On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote:
>>>>> Hi Tom,
>>>>>
>>>>> On 14/05/13 17:52, Tom Rini wrote:
>>>>>> On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote:
>>>>>>> Hi Tom,
>>>>>>>
>>>>>>> I'm currently busy with other work; on the other hand, careful
>>>>>>> rebasing shall require some time, especially the Palmas stuff.
>>>>>>> What would be the deadline for a V2 submission?
>>>>>>>
>>>>>>> Meanwhile could you please have a look at the (already old)
>>>>>>> http://patchwork.ozlabs.org/patch/232743/? A simple patch,
>>>>>>> shall be needed if we enable USB (for the uEVM along with
>>>>>>> our board). In general, what are your plans regarding USB
>>>>>>> (.../patch/232742/)?
>>>>>> Thanks for the reminder, I'll grab 232743 soon.  232742 looks OK, but do
>>>>>> you have a patch around for uEVM still?
>>>>> Not yet (didn't have the opportunity to test, although some uEVMs should
>>>>> be around at MMS). As you know, a patch shall be needed in the uEVM board
>>>>> file along with the common USB stuff.
>>>> Yeah, I can test it as well if you write it up, and may find the time if
>>>> you point me in the right direction.
>>>>
>>>>>>> And again on I2C (.../patch/233823/): what is you final
>>>>>>> opinion? I'm confident that this patch is a major improvement
>>>>>>> for OMAP4/5 at least.
>>>>>> I'm inclined to go with it, just need to mentally unswap the i2c notes
>>>>>> in my brain and think it over one more time.
>>>>> Just applied 233823 to current u-boot-ti master. Works fine.
>>>> OK, thanks.
>>>>
>>>>>> [snip]
>>>>>>>>>>> +	 * TODO: Replace this ugly hardcoding with proper defines +
>>>>>>>>>>> */ +	writel(0x0100, 0x4ae0a310);
>>>>>>>>>> Again, do please.
>>>>>>>>> This should be (*scrm)->auxclk0. The problem is that the
>>>>>>>>> omap5_scrm_regs struct (holding the auxclk0 member) has to be
>>>>>>>>> defined somewhere in the common OMAP5 headers. Sricharan? Or should
>>>>>>>>> I hack around?
>>>>>>>> Add it to the most likely struct in the headers.
>>>>>>> The entire struct (I call it omap5_scrm_regs in theory, similar to the
>>>>>>> corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of
>>>>>>> course I could define only the member that I need, but I guess it is
>>>>>>> a (responsible) TI job to define hardware descriptors. Or I'm wrong?
>>>>>>> Please advise. If I have time, I could do it myself - it's some 27
>>>>>>> registers, almost identical to the OMAP4, and should go into 
>>>>>>> arch/arm/include/asm/arch-omap5/clocks.h.
>>>>>> Whomever uses / needs it should do it.  I gave the TRM a quick read and
>>>>>> I don't see any conflicts per-se just some reserved areas being named
>>>>>> and vice versa.  So rename it to omap_scrm_regs and move to
>>>>>> <asm/omap_common.h>.  Thanks!
>>>>> I would argue that this is not very appropriate. Those regs that are
>>>>> reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4;
>>>>> on the other hand the OMAP5 has some modem clock regs that are reserved
>>>>> on OMAP4. We shall probably have ugly #ifdefs again. And what about OMAP3
>>>>> and below?
>>>> We don't need to use ifdefs since there's no conflicts, things are
>>>> either reserved in one case and used in the other.  And we can make sure
>>>> we don't try and use the omap5 bits on omap4 and vice versa.  I don't
>>>> see scrm in the first omap3 TRM I pulled up, so we don't need to worry
>>>> there.
>>>>
>>>>> Currently the scrm struct is defined for OMAP4 in the asm/arch-omap4/clocks.h
>>>>> file and I have already done the same for OMAP5 by analogy. I must admit
>>>>> however that this approach does not correspond to the latest way by which
>>>>> groups of OMAP hardware regs are defined, prcm in particular - a struct in
>>>>> omap_common.h, holding only the required regs, no padding and such garbage,
>>>>> and an init with the physical addresses in a .c file for the particular SoC
>>>>> (prcm-regs.c). But still the Panda board, for example, uses the old way for
>>>>> scrm. Therefore I did it the same for OMAP5, which was easier (I'm old and
>>>>> lazy ;) ).
>>>> Yes, I'm OK starting off with moving things into omap_common.h as-is and
>>>> then updating them a bit later ala pcrm-regs.c.
>>>>
>>>>
>>>  I am sorry for the very late response on this.
>>>  Now then, why not add this register in to omap5_es2_prcm
>>>  ??. That is how the  TRM sees it as well.. Of course, this is cleanup
>>>  stuff for OMAP4  panda as you pointed out..
>> Yes, you are right in respect to fluent software integration and consistency
>> with current implementation. My only concern is that from architectural point
>> of view the SCRM, although related to the PRCM, is a separate module (described
>> correspondingly as such in the TRM). If we go this way, the SCRM regs shall
>> have to be referenced via the prcm pointer: (*prcm)->xxxxx, and this might be
>> confusing.
>>
>> I'm OK to do it as above, that is, add the SCRM regs (for both OMAP4 and OMAP5)
>> to the prcm_regs declaration in omap_common.h, and the required init to the
>> appropriate omap5_esx_prcm in prcm-regs.c, but would suggest that for improved
>> clarity the SCRM register names, as they now exist in .../arch-omap4/clocks.h,
>> start with a scrm_ prefix.
>>
>> Alternatively, a new scrm_regs struct could be declared in omap_common.h, along
>> with the appropriate pointers, and the corresponding definitions/inits added as
>> new structs in prcm-regs.c for every SoC. But then the file name prcm-regs shall
>> be a bit confusing.
>>
>> What do you say?
>   At this point , i think just adding only the registers that you need in to the
>  prcm structure should be ok.
OK, I just tend to add all registers, it shall be easier for later rework.
> 
> Regards,
>  Sricharan
> 

BR,
Lubo
SRICHARAN R - May 15, 2013, 11:25 a.m.
On Wednesday 15 May 2013 04:16 PM, Lubomir Popov wrote:
> Hi Sricharan,
>
> On 15/05/13 12:04, Sricharan R wrote:
>> Hi,
>>
>> On Wednesday 15 May 2013 01:25 PM, Lubomir Popov wrote:
>>> Hi Sricharan,
>>>
>>> On 15/05/13 08:11, Sricharan R wrote:
>>>> Hi,
>>>> On Tuesday 14 May 2013 10:11 PM, Tom Rini wrote:
>>>>> On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote:
>>>>>> Hi Tom,
>>>>>>
>>>>>> On 14/05/13 17:52, Tom Rini wrote:
>>>>>>> On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote:
>>>>>>>> Hi Tom,
>>>>>>>>
>>>>>>>> I'm currently busy with other work; on the other hand, careful
>>>>>>>> rebasing shall require some time, especially the Palmas stuff.
>>>>>>>> What would be the deadline for a V2 submission?
>>>>>>>>
>>>>>>>> Meanwhile could you please have a look at the (already old)
>>>>>>>> http://patchwork.ozlabs.org/patch/232743/? A simple patch,
>>>>>>>> shall be needed if we enable USB (for the uEVM along with
>>>>>>>> our board). In general, what are your plans regarding USB
>>>>>>>> (.../patch/232742/)?
>>>>>>> Thanks for the reminder, I'll grab 232743 soon.  232742 looks OK, but do
>>>>>>> you have a patch around for uEVM still?
>>>>>> Not yet (didn't have the opportunity to test, although some uEVMs should
>>>>>> be around at MMS). As you know, a patch shall be needed in the uEVM board
>>>>>> file along with the common USB stuff.
>>>>> Yeah, I can test it as well if you write it up, and may find the time if
>>>>> you point me in the right direction.
>>>>>
>>>>>>>> And again on I2C (.../patch/233823/): what is you final
>>>>>>>> opinion? I'm confident that this patch is a major improvement
>>>>>>>> for OMAP4/5 at least.
>>>>>>> I'm inclined to go with it, just need to mentally unswap the i2c notes
>>>>>>> in my brain and think it over one more time.
>>>>>> Just applied 233823 to current u-boot-ti master. Works fine.
>>>>> OK, thanks.
>>>>>
>>>>>>> [snip]
>>>>>>>>>>>> +	 * TODO: Replace this ugly hardcoding with proper defines +
>>>>>>>>>>>> */ +	writel(0x0100, 0x4ae0a310);
>>>>>>>>>>> Again, do please.
>>>>>>>>>> This should be (*scrm)->auxclk0. The problem is that the
>>>>>>>>>> omap5_scrm_regs struct (holding the auxclk0 member) has to be
>>>>>>>>>> defined somewhere in the common OMAP5 headers. Sricharan? Or should
>>>>>>>>>> I hack around?
>>>>>>>>> Add it to the most likely struct in the headers.
>>>>>>>> The entire struct (I call it omap5_scrm_regs in theory, similar to the
>>>>>>>> corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of
>>>>>>>> course I could define only the member that I need, but I guess it is
>>>>>>>> a (responsible) TI job to define hardware descriptors. Or I'm wrong?
>>>>>>>> Please advise. If I have time, I could do it myself - it's some 27
>>>>>>>> registers, almost identical to the OMAP4, and should go into 
>>>>>>>> arch/arm/include/asm/arch-omap5/clocks.h.
>>>>>>> Whomever uses / needs it should do it.  I gave the TRM a quick read and
>>>>>>> I don't see any conflicts per-se just some reserved areas being named
>>>>>>> and vice versa.  So rename it to omap_scrm_regs and move to
>>>>>>> <asm/omap_common.h>.  Thanks!
>>>>>> I would argue that this is not very appropriate. Those regs that are
>>>>>> reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4;
>>>>>> on the other hand the OMAP5 has some modem clock regs that are reserved
>>>>>> on OMAP4. We shall probably have ugly #ifdefs again. And what about OMAP3
>>>>>> and below?
>>>>> We don't need to use ifdefs since there's no conflicts, things are
>>>>> either reserved in one case and used in the other.  And we can make sure
>>>>> we don't try and use the omap5 bits on omap4 and vice versa.  I don't
>>>>> see scrm in the first omap3 TRM I pulled up, so we don't need to worry
>>>>> there.
>>>>>
>>>>>> Currently the scrm struct is defined for OMAP4 in the asm/arch-omap4/clocks.h
>>>>>> file and I have already done the same for OMAP5 by analogy. I must admit
>>>>>> however that this approach does not correspond to the latest way by which
>>>>>> groups of OMAP hardware regs are defined, prcm in particular - a struct in
>>>>>> omap_common.h, holding only the required regs, no padding and such garbage,
>>>>>> and an init with the physical addresses in a .c file for the particular SoC
>>>>>> (prcm-regs.c). But still the Panda board, for example, uses the old way for
>>>>>> scrm. Therefore I did it the same for OMAP5, which was easier (I'm old and
>>>>>> lazy ;) ).
>>>>> Yes, I'm OK starting off with moving things into omap_common.h as-is and
>>>>> then updating them a bit later ala pcrm-regs.c.
>>>>>
>>>>>
>>>>  I am sorry for the very late response on this.
>>>>  Now then, why not add this register in to omap5_es2_prcm
>>>>  ??. That is how the  TRM sees it as well.. Of course, this is cleanup
>>>>  stuff for OMAP4  panda as you pointed out..
>>> Yes, you are right in respect to fluent software integration and consistency
>>> with current implementation. My only concern is that from architectural point
>>> of view the SCRM, although related to the PRCM, is a separate module (described
>>> correspondingly as such in the TRM). If we go this way, the SCRM regs shall
>>> have to be referenced via the prcm pointer: (*prcm)->xxxxx, and this might be
>>> confusing.
>>>
>>> I'm OK to do it as above, that is, add the SCRM regs (for both OMAP4 and OMAP5)
>>> to the prcm_regs declaration in omap_common.h, and the required init to the
>>> appropriate omap5_esx_prcm in prcm-regs.c, but would suggest that for improved
>>> clarity the SCRM register names, as they now exist in .../arch-omap4/clocks.h,
>>> start with a scrm_ prefix.
>>>
>>> Alternatively, a new scrm_regs struct could be declared in omap_common.h, along
>>> with the appropriate pointers, and the corresponding definitions/inits added as
>>> new structs in prcm-regs.c for every SoC. But then the file name prcm-regs shall
>>> be a bit confusing.
>>>
>>> What do you say?
>>   At this point , i think just adding only the registers that you need in to the
>>  prcm structure should be ok.
> OK, I just tend to add all registers, it shall be easier for later rework.
 Actually no :). When were are not using them no good in adding. Especially
 those SCRM registers very less we will use all of them in bootloader.

Regards,
 Sricharan
Lubomir Popov - May 15, 2013, 1:10 p.m.
Hi Sricharan, Tom,

On 15/05/13 14:25, Sricharan R wrote:
> On Wednesday 15 May 2013 04:16 PM, Lubomir Popov wrote:
>> Hi Sricharan,
>>
>> On 15/05/13 12:04, Sricharan R wrote:
>>> Hi,
>>>
>>> On Wednesday 15 May 2013 01:25 PM, Lubomir Popov wrote:
>>>> Hi Sricharan,
>>>>
>>>> On 15/05/13 08:11, Sricharan R wrote:
>>>>> Hi,
>>>>> On Tuesday 14 May 2013 10:11 PM, Tom Rini wrote:
>>>>>> On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote:
>>>>>>> Hi Tom,
>>>>>>>
>>>>>>> On 14/05/13 17:52, Tom Rini wrote:
>>>>>>>> On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote:
>>>>>>>>> Hi Tom,
>>>>>>>>>
>>>>>>>>> I'm currently busy with other work; on the other hand, careful
>>>>>>>>> rebasing shall require some time, especially the Palmas stuff.
>>>>>>>>> What would be the deadline for a V2 submission?
>>>>>>>>>
>>>>>>>>> Meanwhile could you please have a look at the (already old)
>>>>>>>>> http://patchwork.ozlabs.org/patch/232743/? A simple patch,
>>>>>>>>> shall be needed if we enable USB (for the uEVM along with
>>>>>>>>> our board). In general, what are your plans regarding USB
>>>>>>>>> (.../patch/232742/)?
>>>>>>>> Thanks for the reminder, I'll grab 232743 soon.  232742 looks OK, but do
>>>>>>>> you have a patch around for uEVM still?
>>>>>>> Not yet (didn't have the opportunity to test, although some uEVMs should
>>>>>>> be around at MMS). As you know, a patch shall be needed in the uEVM board
>>>>>>> file along with the common USB stuff.
>>>>>> Yeah, I can test it as well if you write it up, and may find the time if
>>>>>> you point me in the right direction.
>>>>>>
>>>>>>>>> And again on I2C (.../patch/233823/): what is you final
>>>>>>>>> opinion? I'm confident that this patch is a major improvement
>>>>>>>>> for OMAP4/5 at least.
>>>>>>>> I'm inclined to go with it, just need to mentally unswap the i2c notes
>>>>>>>> in my brain and think it over one more time.
>>>>>>> Just applied 233823 to current u-boot-ti master. Works fine.
>>>>>> OK, thanks.
>>>>>>
>>>>>>>> [snip]
>>>>>>>>>>>>> +	 * TODO: Replace this ugly hardcoding with proper defines +
>>>>>>>>>>>>> */ +	writel(0x0100, 0x4ae0a310);
>>>>>>>>>>>> Again, do please.
>>>>>>>>>>> This should be (*scrm)->auxclk0. The problem is that the
>>>>>>>>>>> omap5_scrm_regs struct (holding the auxclk0 member) has to be
>>>>>>>>>>> defined somewhere in the common OMAP5 headers. Sricharan? Or should
>>>>>>>>>>> I hack around?
>>>>>>>>>> Add it to the most likely struct in the headers.
>>>>>>>>> The entire struct (I call it omap5_scrm_regs in theory, similar to the
>>>>>>>>> corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of
>>>>>>>>> course I could define only the member that I need, but I guess it is
>>>>>>>>> a (responsible) TI job to define hardware descriptors. Or I'm wrong?
>>>>>>>>> Please advise. If I have time, I could do it myself - it's some 27
>>>>>>>>> registers, almost identical to the OMAP4, and should go into 
>>>>>>>>> arch/arm/include/asm/arch-omap5/clocks.h.
>>>>>>>> Whomever uses / needs it should do it.  I gave the TRM a quick read and
>>>>>>>> I don't see any conflicts per-se just some reserved areas being named
>>>>>>>> and vice versa.  So rename it to omap_scrm_regs and move to
>>>>>>>> <asm/omap_common.h>.  Thanks!
>>>>>>> I would argue that this is not very appropriate. Those regs that are
>>>>>>> reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4;
>>>>>>> on the other hand the OMAP5 has some modem clock regs that are reserved
>>>>>>> on OMAP4. We shall probably have ugly #ifdefs again. And what about OMAP3
>>>>>>> and below?
>>>>>> We don't need to use ifdefs since there's no conflicts, things are
>>>>>> either reserved in one case and used in the other.  And we can make sure
>>>>>> we don't try and use the omap5 bits on omap4 and vice versa.  I don't
>>>>>> see scrm in the first omap3 TRM I pulled up, so we don't need to worry
>>>>>> there.
>>>>>>
>>>>>>> Currently the scrm struct is defined for OMAP4 in the asm/arch-omap4/clocks.h
>>>>>>> file and I have already done the same for OMAP5 by analogy. I must admit
>>>>>>> however that this approach does not correspond to the latest way by which
>>>>>>> groups of OMAP hardware regs are defined, prcm in particular - a struct in
>>>>>>> omap_common.h, holding only the required regs, no padding and such garbage,
>>>>>>> and an init with the physical addresses in a .c file for the particular SoC
>>>>>>> (prcm-regs.c). But still the Panda board, for example, uses the old way for
>>>>>>> scrm. Therefore I did it the same for OMAP5, which was easier (I'm old and
>>>>>>> lazy ;) ).
>>>>>> Yes, I'm OK starting off with moving things into omap_common.h as-is and
>>>>>> then updating them a bit later ala pcrm-regs.c.
>>>>>>
>>>>>>
>>>>>  I am sorry for the very late response on this.
>>>>>  Now then, why not add this register in to omap5_es2_prcm
>>>>>  ??. That is how the  TRM sees it as well.. Of course, this is cleanup
>>>>>  stuff for OMAP4  panda as you pointed out..
>>>> Yes, you are right in respect to fluent software integration and consistency
>>>> with current implementation. My only concern is that from architectural point
>>>> of view the SCRM, although related to the PRCM, is a separate module (described
>>>> correspondingly as such in the TRM). If we go this way, the SCRM regs shall
>>>> have to be referenced via the prcm pointer: (*prcm)->xxxxx, and this might be
>>>> confusing.
>>>>
>>>> I'm OK to do it as above, that is, add the SCRM regs (for both OMAP4 and OMAP5)
>>>> to the prcm_regs declaration in omap_common.h, and the required init to the
>>>> appropriate omap5_esx_prcm in prcm-regs.c, but would suggest that for improved
>>>> clarity the SCRM register names, as they now exist in .../arch-omap4/clocks.h,
>>>> start with a scrm_ prefix.
>>>>
>>>> Alternatively, a new scrm_regs struct could be declared in omap_common.h, along
>>>> with the appropriate pointers, and the corresponding definitions/inits added as
>>>> new structs in prcm-regs.c for every SoC. But then the file name prcm-regs shall
>>>> be a bit confusing.
>>>>
>>>> What do you say?
>>>   At this point , i think just adding only the registers that you need in to the
>>>  prcm structure should be ok.
>> OK, I just tend to add all registers, it shall be easier for later rework.
>  Actually no :). When were are not using them no good in adding. Especially
>  those SCRM registers very less we will use all of them in bootloader.
OK, agree. Done.

Now on USB in general: u-boot-ti master lags behind mainline master in respect to
drivers/usb/host/ehci-hcd.c (the other TI-specific files are OK). My old
.../patch/232742 applies to u-boot-ti correctly. Should we keep it (and then Tom
does the merge of ehci-hcd.c), or I rebase on mainline with a V2? Tom?
> 
> Regards,
>  Sricharan
> 
Regards,
Lubo
Tom Rini - May 15, 2013, 1:43 p.m.
On Wed, May 15, 2013 at 04:10:46PM +0300, Lubomir Popov wrote:
> Hi Sricharan, Tom,
[snip]
> Now on USB in general: u-boot-ti master lags behind mainline master in respect to
> drivers/usb/host/ehci-hcd.c (the other TI-specific files are OK). My old
> .../patch/232742 applies to u-boot-ti correctly. Should we keep it (and then Tom
> does the merge of ehci-hcd.c), or I rebase on mainline with a V2? Tom?

The patch still git am's fine on master (just checked), so it's OK
as-is.
Lubomir Popov - May 15, 2013, 2:31 p.m.
OK, thanks.

On 15/05/13 16:43, Tom Rini wrote:
> On Wed, May 15, 2013 at 04:10:46PM +0300, Lubomir Popov wrote:
>> Hi Sricharan, Tom,
> [snip]
>> Now on USB in general: u-boot-ti master lags behind mainline master in respect to
>> drivers/usb/host/ehci-hcd.c (the other TI-specific files are OK). My old
>> .../patch/232742 applies to u-boot-ti correctly. Should we keep it (and then Tom
>> does the merge of ehci-hcd.c), or I rebase on mainline with a V2? Tom?
> 
> The patch still git am's fine on master (just checked), so it's OK
> as-is.
> 
Lubo

Patch

diff --git a/arch/arm/include/asm/mach-types.h b/arch/arm/include/asm/mach-types.h
index a676b6d..236fa17 100644
--- a/arch/arm/include/asm/mach-types.h
+++ b/arch/arm/include/asm/mach-types.h
@@ -1107,6 +1107,7 @@  extern unsigned int __machine_arch_type;
 #define MACH_TYPE_OMAP5_SEVM           3777
 #define MACH_TYPE_ARMADILLO_800EVA     3863
 #define MACH_TYPE_KZM9G                4140
+#define MACH_TYPE_SOM5_EVB             4545
 
 #ifdef CONFIG_ARCH_EBSA110
 # ifdef machine_arch_type
@@ -14248,6 +14249,18 @@  extern unsigned int __machine_arch_type;
 # define machine_is_kzm9g()	(0)
 #endif
 
+#ifdef CONFIG_MACH_SOM5_EVB
+# ifdef machine_arch_type
+#  undef machine_arch_type
+#  define machine_arch_type     __machine_arch_type
+# else
+#  define machine_arch_type     MACH_TYPE_SOM5_EVB
+# endif
+# define machine_is_som5_evb()  (machine_arch_type == MACH_TYPE_SOM5_EVB)
+#else
+# define machine_is_som5_evb()  (0)
+#endif
+
 /*
  * These have not yet been registered
  */
diff --git a/board/mms/som5_evb/Makefile b/board/mms/som5_evb/Makefile
new file mode 100644
index 0000000..248e5cc
--- /dev/null
+++ b/board/mms/som5_evb/Makefile
@@ -0,0 +1,49 @@ 
+#
+# (C) Copyright 2000, 2001, 2002
+# Wolfgang Denk, DENX Software Engineering, wd@denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB	= $(obj)lib$(BOARD).o
+
+COBJS	:= som5_evb.o
+
+SRCS	:= $(COBJS:.o=.c)
+OBJS	:= $(addprefix $(obj),$(COBJS))
+
+$(LIB):	$(obj).depend $(OBJS)
+	$(call cmd_link_o_target, $(OBJS))
+
+clean:
+	rm -f $(OBJS)
+
+distclean:	clean
+	rm -f $(LIB) core *.bak $(obj).depend
+
+#########################################################################
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#########################################################################
diff --git a/board/mms/som5_evb/s5evb_mux_data.h b/board/mms/som5_evb/s5evb_mux_data.h
new file mode 100644
index 0000000..791a4ad
--- /dev/null
+++ b/board/mms/som5_evb/s5evb_mux_data.h
@@ -0,0 +1,376 @@ 
+/*
+ * Copyright (C) 2013 MM Solutions AD, <www.mm-sol.com>
+ *
+ * Lubomir Popov  <lpopov@mm-sol.com> <l-popov@ti.com>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+#ifndef _SOM5_EVB_MUX_DATA_H
+#define _SOM5_EVB_MUX_DATA_H
+
+#include <asm/arch/mux_omap5.h>
+
+const struct pad_conf_entry core_padconf_array_essential[] = {
+
+	{EMMC_CLK, (PTU | IEN | M0)},     /* EMMC_CLK      */
+	{EMMC_CMD, (PTU | IEN | M0)},     /* EMMC_CMD      */
+	{EMMC_DATA0, (PTU | IEN | M0)},   /* EMMC_DATA0    */
+	{EMMC_DATA1, (PTU | IEN | M0)},   /* EMMC_DATA1    */
+	{EMMC_DATA2, (PTU | IEN | M0)},   /* EMMC_DATA2    */
+	{EMMC_DATA3, (PTU | IEN | M0)},   /* EMMC_DATA3    */
+	{EMMC_DATA4, (PTU | IEN | M0)},   /* EMMC_DATA4    */
+	{EMMC_DATA5, (PTU | IEN | M0)},   /* EMMC_DATA5    */
+	{EMMC_DATA6, (PTU | IEN | M0)},   /* EMMC_DATA6    */
+	{EMMC_DATA7, (PTU | IEN | M0)},   /* EMMC_DATA7    */
+
+	{SDCARD_CLK, (PTU | IEN | M0)},   /* SDCARD_CLK    */
+	{SDCARD_CMD, (PTU | IEN | M0)},   /* SDCARD_CMD    */
+	{SDCARD_DATA0, (PTU | IEN | M0)}, /* SDCARD_DATA0  */
+	{SDCARD_DATA1, (PTU | IEN | M0)}, /* SDCARD_DATA1  */
+	{SDCARD_DATA2, (PTU | IEN | M0)}, /* SDCARD_DATA2  */
+	{SDCARD_DATA3, (PTU | IEN | M0)}, /* SDCARD_DATA3  */
+
+	{UART3_RX_IRRX, (PTU | IEN | M0)},/* UART3_RX_IRRX */
+	{UART3_TX_IRTX, (M0)},            /* UART3_TX_IRTX */
+
+	{HSI2_CAREADY, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M3)},    /*  USBB1_ULPIPHY_CLK    */
+	{HSI2_ACREADY, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M3)},    /*  USBB1_ULPIPHY_NXT    */
+	{HSI2_CAWAKE, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M3)},     /*  USBB1_ULPIPHY_DIR    */
+	{HSI2_ACWAKE, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M3)},     /*  USBB1_ULPIPHY_STP    */
+	{HSI2_CAFLAG, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M3)},     /*  USBB1_ULPIPHY_DATA0  */
+	{HSI2_CADATA, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M3)},     /*  USBB1_ULPIPHY_DATA1  */
+	{HSI2_ACFLAG, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M3)},     /*  USBB1_ULPIPHY_DATA2  */
+	{HSI2_ACDATA, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M3)},     /*  USBB1_ULPIPHY_DATA3  */
+	{UART2_RTS, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M3)},       /*  USBB1_ULPIPHY_DATA4  */
+	{UART2_CTS, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M3)},       /*  USBB1_ULPIPHY_DATA5  */
+	{UART2_RX, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M3)},        /*  USBB1_ULPIPHY_DATA6  */
+	{UART2_TX, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M3)},        /*  USBB1_ULPIPHY_DATA7  */
+
+	{USBB2_HSIC_STROBE, (PTU | IEN | M0)}, /*  USBB2_HSIC_STROBE  */
+	{USBB2_HSIC_DATA, (PTU | IEN | M0)},   /*  USBB2_HSIC_DATA    */
+	
+	{USBB3_HSIC_STROBE, (PTU | IEN | M0)}, /*  USBB3_HSIC_STROBE     */
+	{USBB3_HSIC_DATA, (PTU | IEN | M0)},   /*  USBB3_HSIC_DATA       */
+
+	{USBD0_HS_DP, (IEN | M0)},             /*  USBD0_HS_DP           */
+	{USBD0_HS_DM, (IEN | M0)},             /*  USBD0_HS_DM           */
+	{USBD0_SS_RX, (IEN | M0)},             /*  USBD0_SS_RX (LP: WTF is this for?) */
+
+};
+
+const struct pad_conf_entry wkup_padconf_array_essential[] = {
+
+	{SR_PMIC_SCL, (PTU | IEN | M0)},  /* SR_PMIC_SCL  */
+	{SR_PMIC_SDA, (PTU | IEN | M0)},  /* SR_PMIC_SDA  */
+
+	{SYS_32K, (IEN | M0)},            /* SYS_32K      */
+
+};
+
+const struct pad_conf_entry core_padconf_array_non_essential[] = {
+#if 0
+/* GPMC is actually not useable directly as we don't have
+   the GPMC_NOE_NRE signal available, and some external logic
+   shall be needed. Anyway, M4 is the reset default.
+*/
+	{C2C_DATAIN0, (IEN | M4)},             /*  GPMC_AD0      */
+	{C2C_DATAIN1, (IEN | M4)},             /*  GPMC_AD1      */
+	{C2C_DATAIN2, (IEN | M4)},             /*  GPMC_AD2      */
+	{C2C_DATAIN3, (IEN | M4)},             /*  GPMC_AD3      */
+	{C2C_DATAIN4, (IEN | M4)},             /*  GPMC_AD4      */
+	{C2C_DATAIN5, (IEN | M4)},             /*  GPMC_AD5      */
+	{C2C_DATAIN6, (IEN | M4)},             /*  GPMC_AD6      */
+	{C2C_DATAIN7, (IEN | M4)},             /*  GPMC_AD7      */
+	{C2C_CLKIN1,  (IEN | M4)},             /*  GPMC_CLK      */
+	{C2C_CLKIN0,  (M5)},                   /*  GPMC_NBE1     */
+	{C2C_CLKOUT0, (M4)},                   /*  GPMC_NADV_ALE */
+	{C2C_CLKOUT1, (M4)},                   /*  GPMC_NBE0_CLE */
+	{C2C_DATAOUT0, (IEN | M4)},            /*  GPMC_AD8      */
+	{C2C_DATAOUT1, (IEN | M4)},            /*  GPMC_AD9      */
+	{C2C_DATAOUT2, (IEN | M4)},            /*  GPMC_AD10     */
+	{C2C_DATAOUT3, (IEN | M4)},            /*  GPMC_AD11     */
+	{C2C_DATAOUT4, (IEN | M4)},            /*  GPMC_AD12     */
+	{C2C_DATAOUT5, (IEN | M4)},            /*  GPMC_AD13     */
+	{C2C_DATAOUT6, (IEN | M4)},            /*  GPMC_AD14     */
+	{C2C_DATAOUT7, (IEN | M4)},            /*  GPMC_AD15     */
+	{C2C_DATA8, (M4)},                     /*  GPMC_A16      */
+	{C2C_DATA9, (M4)},                     /*  GPMC_A17      */
+	{C2C_DATA10, (M4)},                    /*  GPMC_A18      */
+	{C2C_DATA11, (M4)},                    /*  GPMC_A19      */
+	{C2C_DATA12, (M4)},                    /*  GPMC_A20      */
+	{C2C_DATA13, (M4)},                    /*  GPMC_A21      */
+	{C2C_DATA14, (M4)},                    /*  GPMC_A22      */
+	{C2C_DATA15, (M4)},                    /*  GPMC_A23      */
+	{LLIA_WAKEREQOUT, (PTU | IEN | M4)},   /*  GPMC_WAIT0    */
+	{UART1_RTS, (M4)},                     /*  GPMC_NCS7     */
+#else
+/* Test in GPIO mode. Convention: left (odd) pins on connector are
+   outputs (initialized to PD), right (even) pins are inputs with PU.
+*/
+	{C2C_DATAIN0, (IEN | PTU | M6)},       /*  GPIO2_37   In J201:06 */
+	{C2C_DATAIN1, (IEN | PTU | M6)},       /*  GPIO2_38   In J201:04 */
+	{C2C_DATAIN2, (IEN | PTU | M6)},       /*  GPIO2_39   In J201:10 */
+	{C2C_DATAIN3, (IEN | PTU | M6)},       /*  GPIO2_40   In J201:08 */
+	{C2C_DATAIN4, (IEN | PTU | M6)},       /*  GPIO2_41   In J201:16 */
+	{C2C_DATAIN5, (IEN | PTU | M6)},       /*  GPIO2_42   In J201:12 */
+	{C2C_DATAIN6, (IEN | PTU | M6)},       /*  GPIO2_43   In J201:20 */
+	{C2C_DATAIN7, (IEN | PTU | M6)},       /*  GPIO2_44   In J201:18 */
+	{C2C_CLKIN1,  (PTD | M6)},             /*  GPIO2_36  Out J201:03 */
+	{C2C_CLKIN0,  (PTD | M6)},             /*  GPIO2_35  Out J201:11 */
+	{C2C_CLKOUT0, (PTD | M6)},             /*  GPIO2_33  Out J201:17 */
+	{C2C_CLKOUT1, (PTD | M6)},             /*  GPIO2_34  Out J201:09 */
+	{C2C_DATAOUT0, (PTD | M6)},            /*  GPIO2_56  Out J201:31 */
+	{C2C_DATAOUT1, (PTD | M6)},            /*  GPIO2_57  Out J201:23 */
+	{C2C_DATAOUT2, (PTD | M6)},            /*  GPIO2_58  Out J201:25 */
+	{C2C_DATAOUT3, (PTD | M6)},            /*  GPIO2_59  Out J201:15 */
+	{C2C_DATAOUT4, (PTD | M6)},            /*  GPIO2_60  Out J201:29 */
+	{C2C_DATAOUT5, (PTD | M6)},            /*  GPIO2_61  Out J201:21 */
+	{C2C_DATAOUT6, (IEN | PTU | M6)},      /*  GPIO2_62   In J201:22 */
+	{C2C_DATAOUT7, (IEN | PTU | M6)},      /*  GPIO2_63   In J201:24 */
+	{C2C_DATA8, (IEN | PTU | M6)},         /*  GPIO4_113  In J201:32 */
+	{C2C_DATA9, (IEN | PTU | M6)},         /*  GPIO4_114  In J201:30 */
+	{C2C_DATA10, (IEN | PTU | M6)},        /*  GPIO4_115  In J201:36 */
+	{C2C_DATA11, (IEN | PTU | M6)},        /*  GPIO4_116  In J201:26 */
+	{C2C_DATA12, (PTD | M6)},              /*  GPIO4_117 Out J201:35 */
+	{C2C_DATA13, (PTD | M6)},              /*  GPIO4_118 Out J201:33 */
+	{C2C_DATA14, (IEN | PTU | M6)},        /*  GPIO4_119  In J201:38 */
+	{C2C_DATA15, (IEN | PTU | M6)},        /*  GPIO4_120  In J201:34 */
+	{LLIA_WAKEREQOUT, (PTD | M6)},         /*  GPIO2_45  Out J201:07 */
+	{UART1_RTS, (PTD | M6)},               /*  GPIO3_75  Out J201:37 */
+#endif
+	{LLIB_WAKEREQOUT, (PTU | IEN | M6)},   /*  GPIO2_32  In I/O Exp Int */
+
+	{HSI1_ACREADY, (PTD | M6)},            /*  GPIO3_64 Out J701:28 */
+	{HSI1_CAREADY, (PTD | M6)},            /*  GPIO3_65 Out J701:26 */
+	{HSI1_ACWAKE,  (PTD | M6)},            /*  GPIO3_66 Out J801:25 */
+	{HSI1_CAWAKE,  (PTU | IEN | M6)},      /*  GPIO3_67  In SDcard:CD */
+	{HSI1_ACFLAG,  (PTU | IEN | M6)},      /*  GPIO3_68  In J801:22 */
+	{HSI1_ACDATA,  (PTD | M6)},            /*  GPIO3_69 Out J801:21 */
+	{HSI1_CAFLAG,  (PTU | IEN | M6)},      /*  GPIO3_70  In J801:32 */
+	{HSI1_CADATA,  (PTD | M6)},            /*  GPIO3_71 Out J801:29 */
+	{UART1_TX, (PTU | IEN | M6)},          /*  GPIO3_72  In J801:26 */
+	{UART1_CTS, (PTD | M6)},               /*  GPIO3_73 Out J801:31 */
+	{UART1_RX, (PTU | IEN | M6)},          /*  GPIO3_74  In J801:30 */
+
+	{USBB1_HSIC_STROBE, (PTU | IEN | M6)}, /*  GPIO3_92 In NU     */
+	{USBB1_HSIC_DATA, (PTU | IEN | M6)},   /*  GPIO3_93 In NU     */
+
+	{TIMER10_PWM_EVT, (PTD | M6)},         /*  GPIO6_188 Out J802:11 */
+	{DSIPORTA_TE0, (PTU | IEN | M6)},      /*  GPIO6_189  In J802:26 */
+	{DSIPORTA_LANE0X, (IEN | M0)},         /*  DSIPORTA_LANE0X J704  */
+	{DSIPORTA_LANE0Y, (IEN | M0)},         /*  DSIPORTA_LANE0Y J704  */
+	{DSIPORTA_LANE1X, (IEN | M0)},         /*  DSIPORTA_LANE1X J704  */
+	{DSIPORTA_LANE1Y, (IEN | M0)},         /*  DSIPORTA_LANE1Y J704  */
+	{DSIPORTA_LANE2X, (IEN | M0)},         /*  DSIPORTA_LANE2X J704  */
+	{DSIPORTA_LANE2Y, (IEN | M0)},         /*  DSIPORTA_LANE2Y J704  */
+	{DSIPORTA_LANE3X, (IEN | M0)},         /*  DSIPORTA_LANE3X J704  */
+	{DSIPORTA_LANE3Y, (IEN | M0)},         /*  DSIPORTA_LANE3Y J704  */
+	{DSIPORTA_LANE4X, (IEN | M0)},         /*  DSIPORTA_LANE4X J704  */
+	{DSIPORTA_LANE4Y, (IEN | M0)},         /*  DSIPORTA_LANE4Y J704  */
+
+	{TIMER9_PWM_EVT, (PTU | IEN | M6)},    /*  GPIO6_190  In J802:12 */
+	{DSIPORTC_TE0, (PTD | M6)},            /*  GPIO6_191 Out J802:15 */
+	{DSIPORTC_LANE0X, (IEN | M0)},         /*  DSIPORTC_LANE0X J702  */
+	{DSIPORTC_LANE0Y, (IEN | M0)},         /*  DSIPORTC_LANE0Y J702  */
+	{DSIPORTC_LANE1X, (IEN | M0)},         /*  DSIPORTC_LANE1X J702  */
+	{DSIPORTC_LANE1Y, (IEN | M0)},         /*  DSIPORTC_LANE1Y J702  */
+	{DSIPORTC_LANE2X, (IEN | M0)},         /*  DSIPORTC_LANE2X J702  */
+	{DSIPORTC_LANE2Y, (IEN | M0)},         /*  DSIPORTC_LANE2Y J702  */
+	{DSIPORTC_LANE3X, (IEN | M0)},         /*  DSIPORTC_LANE3X J702  */
+	{DSIPORTC_LANE3Y, (IEN | M0)},         /*  DSIPORTC_LANE3Y J702  */
+	{DSIPORTC_LANE4X, (IEN | M0)},         /*  DSIPORTC_LANE4X J702  */
+	{DSIPORTC_LANE4Y, (IEN | M0)},         /*  DSIPORTC_LANE4Y J702  */
+
+	{RFBI_HSYNC0, (M4)},                   /*  KBD_COL5 (Out) HOME   */
+	{RFBI_TE_VSYNC0, (PTD | M6)},          /*  GPIO6_161 Out J704:24 3D_MODE_EN */
+	{RFBI_WE, (PTD | M5)},                 /*  DRM_EMU2 (Out)        */
+	{RFBI_CS0, (PTD | M5)},                /*  DRM_EMU3 (Out)        */
+	{RFBI_RE, (M4)},                       /*  KBD_COL4 (Out) SEND   */
+	{RFBI_A0, (PTU | IEN | M6)},           /*  GPIO6_165 In SH2_SENS_INT */
+	{RFBI_DATA0, (PTD | M5)},              /*  DRM_EMU4 (Out)        */
+	{RFBI_DATA1, (PTD | M5)},              /*  DRM_EMU5 (Out)        */
+	{RFBI_DATA2, (PTD | M5)},              /*  DRM_EMU6 (Out)        */
+	{RFBI_DATA3, (PTD | M6)},              /*  GPIO6_169 Out J704:22 3D_LCD_BANK_SEL */
+	{RFBI_DATA4, (PTU | IEN | M6)},        /*  GPIO6_170 In TEMP_ALERT on SOM (OD) */
+	{RFBI_DATA5, (PTU | IEN | M6)},        /*  GPIO6_171  In J802:30 */
+	{RFBI_DATA6, (PTD | M6)},              /*  GPIO6_172 Out LAN9730 nRESET */
+	{RFBI_DATA7, (PTD | M6)},              /*  GPIO6_173 Out USB4640 nRESET */
+	{RFBI_DATA8, (M4)},                    /*  KBD_COL3 (Out) VOL-   */
+	{RFBI_DATA9, (PTD | M6)},              /*  GPIO6_175 Out MCLK_1E */
+	{RFBI_DATA10, (PTD | M6)},             /*  GPIO6_176 Out MCLK_2E */
+	{RFBI_DATA11, (PTD | M6)},             /*  GPIO6_177 Out MCLK_3E */
+	{RFBI_DATA12, (PTD | M6)},             /*  GPIO6_178 Out J703:25 CAM_SUBPM_EN */
+	{RFBI_DATA13, (PTU | IEN | M6)},       /*  GPIO6_179  In J704:27 TSCR_INT (OD) */
+	{RFBI_DATA14, (M4)},                   /*  KBD_COL7 (Out) SEARCH */
+	{RFBI_DATA15, (M4)},                   /*  KBD_COL6 (Out) END    */
+
+	{GPIO6_182, (PTU | IEN | M6)},         /*  GPIO6_182  In J802:28 */
+	{GPIO6_183, (PTD | M6)},               /*  GPIO6_183 Out J704:25 nLCD_RESET */
+	{GPIO6_184, (M4)},                     /*  KBD_COL2 (Out) VOL+   */
+	{GPIO6_185, (PTU | IEN | M6)},         /*  GPIO6_185  In J802:32 */
+	{GPIO6_186, (PTD | M6)},               /*  GPIO6_186 Out J802:25 */
+	{GPIO6_187, (PTU | IEN | M4)},         /*  KBD_ROW2 (In) All btns*/
+#if 0
+	{MCSPI2_CS0, (M0)},                    /*  MCSPI2_CS0 J802:31    */
+	{MCSPI2_CLK, (IEN | M0)},              /*  MCSPI2_CLK J802:23    */
+	{MCSPI2_SIMO, (IEN | M0)},             /*  MCSPI2_SIMO J802:29   */
+	{MCSPI2_SOMI, (PTU | IEN | M0)},       /*  MCSPI2_SOMI J802:18   */
+#else
+	{MCSPI2_CS0, (PTD | M6)},              /*  GPIO7_196 Out J802:31 */
+	{MCSPI2_CLK, (PTD | M6)},              /*  GPIO7_197 Out J802:23 */
+	{MCSPI2_SIMO, (PTD | M6)},             /*  GPIO7_198 Out J802:29 */
+	{MCSPI2_SOMI, (PTU | IEN | M6)},       /*  GPIO7_199  In J802:18 */
+#endif
+	{I2C4_SCL, (IEN | PTU | M0)},          /*  I2C4_SCL              */
+	{I2C4_SDA, (IEN | PTU | M0)},          /*  I2C4_SDA              */
+
+	{HDMI_CEC, (IEN | M0)},                /*  HDMI_CEC              */
+	{HDMI_HPD, (PTD | IEN | M0)},          /*  HDMI_HPD              */
+	{HDMI_DDC_SCL, (IEN | M0)},            /*  HDMI_DDC_SCL          */
+	{HDMI_DDC_SDA, (IEN | M0)},            /*  HDMI_DDC_SDA          */
+
+	{CSIPORTA_LANE0X, (IEN | M0)},         /*  CSIPORTA_LANE0X       */
+	{CSIPORTA_LANE0Y, (IEN | M0)},         /*  CSIPORTA_LANE0Y       */
+	{CSIPORTA_LANE1Y, (IEN | M0)},         /*  CSIPORTA_LANE1Y       */
+	{CSIPORTA_LANE1X, (IEN | M0)},         /*  CSIPORTA_LANE1X       */
+	{CSIPORTA_LANE2Y, (IEN | M0)},         /*  CSIPORTA_LANE2Y       */
+	{CSIPORTA_LANE2X, (IEN | M0)},         /*  CSIPORTA_LANE2X       */
+	{CSIPORTA_LANE3X, (IEN | M0)},         /*  CSIPORTA_LANE3X       */
+	{CSIPORTA_LANE3Y, (IEN | M0)},         /*  CSIPORTA_LANE3Y       */
+	{CSIPORTA_LANE4X, (IEN | M0)},         /*  CSIPORTA_LANE4X       */
+	{CSIPORTA_LANE4Y, (IEN | M0)},         /*  CSIPORTA_LANE4Y       */
+
+	{CSIPORTB_LANE0X, (IEN | M0)},         /*  CSIPORTB_LANE0X       */
+	{CSIPORTB_LANE0Y, (IEN | M0)},         /*  CSIPORTB_LANE0Y       */
+	{CSIPORTB_LANE1Y, (IEN | M0)},         /*  CSIPORTB_LANE1Y       */
+	{CSIPORTB_LANE1X, (IEN | M0)},         /*  CSIPORTB_LANE1X       */
+	{CSIPORTB_LANE2Y, (IEN | M0)},         /*  CSIPORTB_LANE2Y       */
+	{CSIPORTB_LANE2X, (IEN | M0)},         /*  CSIPORTB_LANE2X       */
+
+	{CSIPORTC_LANE0Y, (IEN | M0)},         /*  CSIPORTC_LANE0Y       */
+	{CSIPORTC_LANE0X, (IEN | M0)},         /*  CSIPORTC_LANE0X       */
+	{CSIPORTC_LANE1Y, (IEN | M0)},         /*  CSIPORTC_LANE1Y       */
+	{CSIPORTC_LANE1X, (IEN | M0)},         /*  CSIPORTC_LANE1X       */
+
+	{CAM_SHUTTER, (M0)},                   /*  CAM_SHUTTER/224     J701:22 */
+	{CAM_STROBE, (M0)},                    /*  CAM_STROBE/225      J701:24 */
+	{CAM_GLOBALRESET, (IEN | M0)},         /*  CAM_GLOBALRESET/226 J701:20 */
+	{TIMER11_PWM_EVT, (PTD | M6)},         /*  GPIO8_227 Out J703:26 PRIMARY_5M_RESET_N   */
+	{TIMER5_PWM_EVT, (PTD | M6)},          /*  GPIO8_228 Out J703:28 SECONDARY_5M_RESET_N */
+	{TIMER6_PWM_EVT, (PTD | M6)},          /*  GPIO8_229 Out J701:18 */
+	{TIMER8_PWM_EVT, (PTD | M6)},          /*  GPIO8_230 Out J701:16 */
+
+	{I2C3_SCL, (IEN | PTU | M0)},          /*  I2C3_SCL              */
+	{I2C3_SDA, (IEN | PTU | M0)},          /*  I2C3_SDA              */
+
+	{GPIO8_233, (PTD | M6)},               /*  GPIO8_233 Out J701:25 */
+
+	{ABE_CLKS, (IEN | M0)},                /*  ABE_CLKS              */
+	{ABEDMIC_DIN1, (PTD | M6)},            /*  GPIO4_97  Out J801:13 */
+	{ABEDMIC_DIN2, (PTU | IEN | M6)},      /*  GPIO4_98   In J801:12 */
+	{ABEDMIC_DIN3, (PTD | M6)},            /*  GPIO4_99  Out J801:11 */
+	{ABEDMIC_CLK1, (PTU | IEN | M6)},      /*  GPIO4_100  In J801:14 */
+
+	{ABEDMIC_CLK2, (IEN | M1)},            /*  ABEMCBSP1_FSX BT Aud  */
+	{ABEDMIC_CLK3, (M1)},                  /*  ABEMCBSP1_DX BT Aud   */
+	{ABESLIMBUS1_CLOCK, (IEN | M1)},       /*  ABEMCBSP1_CLKX BT Aud */
+	{ABESLIMBUS1_DATA, (IEN | M1)},        /*  ABEMCBSP1_DR BT Aud   */
+
+	{ABEMCBSP2_DR, (IEN | M0)},            /*  ABEMCBSP2_DR FM Aud   */
+	{ABEMCBSP2_DX, (M0)},                  /*  ABEMCBSP2_DX FM Aud   */
+	{ABEMCBSP2_FSX, (IEN | M0)},           /*  ABEMCBSP2_FSX FM Aud  */
+	{ABEMCBSP2_CLKX, (IEN | M0)},          /*  ABEMCBSP2_CLKX FM Aud */
+
+	{ABEMCPDM_UL_DATA, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M0)},    /*  ABEMCPDM_UL_DATA */
+	{ABEMCPDM_DL_DATA, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M0)},    /*  ABEMCPDM_DL_DATA */
+	{ABEMCPDM_FRAME, (PTU | IEN | OFF_EN | OFF_PD | OFF_IN | M0)},      /*  ABEMCPDM_FRAME   */
+	{ABEMCPDM_LB_CLK, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M0)},     /*  ABEMCPDM_LB_CLK  */
+
+	{WLSDIO_CLK, (PTU | IEN | M0)},        /*  WLSDIO_CLK            */
+	{WLSDIO_CMD, (PTU | IEN | M0)},        /*  WLSDIO_CMD            */
+	{WLSDIO_DATA0, (PTU | IEN | M0)},      /*  WLSDIO_DATA0          */
+	{WLSDIO_DATA1, (PTU | IEN | M0)},      /*  WLSDIO_DATA1          */
+	{WLSDIO_DATA2, (PTU | IEN | M0)},      /*  WLSDIO_DATA2          */
+	{WLSDIO_DATA3, (PTU | IEN | M0)},      /*  WLSDIO_DATA3          */
+
+	{UART5_RX, (PTU | IEN | M0)},          /*  UART5_RX BT HCI       */
+	{UART5_TX, (M0)},                      /*  UART5_TX BT HCI       */
+	{UART5_CTS, (PTU | IEN | M0)},         /*  UART5_CTS BT HCI      */
+	{UART5_RTS, (M0)},                     /*  UART5_RTS BT HCI      */
+
+	{I2C2_SCL, (IEN | M0)},                /*  I2C2_SCL              */
+	{I2C2_SDA, (IEN | M0)},                /*  I2C2_SDA              */
+
+	{MCSPI1_CLK, (PTD | M6)},              /*  GPIO5_140 Out WLAN EN */
+	{MCSPI1_SOMI, (PTD | M6)},             /*  GPIO5_141 Out J802:17 */
+	{MCSPI1_SIMO, (PTD | M6)},             /*  GPIO5_142 Out BT EN   */
+	{MCSPI1_CS0, (PTD | M6)},              /*  GPIO5_143 Out BT Wkup */
+	{MCSPI1_CS1, (PTD | IEN | M6)},        /*  GPIO5_144  In Host WU */
+
+	{I2C5_SCL, (IEN | PTU | M0)},          /*  I2C5_SCL              */
+	{I2C5_SDA, (IEN | PTU | M0)},          /*  I2C5_SDA              */
+
+	{PERSLIMBUS2_CLOCK, (PTD | M6)},       /*  GPIO5_145 Out AUDPWRON*/
+	{PERSLIMBUS2_DATA, (PTD | M6)},        /*  GPIO5_146 Out J802:27 */
+	{UART6_TX, (PTD | M6)},                /*  GPIO5_149 Out J802:13 */
+	{UART6_RX, (PTU | IEN | M6)},          /*  GPIO5_150  In J802:20 */
+	{UART6_CTS, (PTU | IEN | M6)},         /*  GPIO5_151  In J802:21 EXCEPTION TO RULE, SHORT WITH PIN 23 */
+	{UART6_RTS, (PTD | M6)},               /*  GPIO5_152 Out J802:19 */
+	{UART3_CTS_RCTX, (PTD | IEN | M6)},    /*  GPIO5_153  In J802:14 or SATA_ACTLED Out (M1). PTD! */
+	{UART3_RTS_IRSD, (PTU | IEN | M6)},    /*  GPIO5_154  In J802:16 */
+
+	{I2C1_PMIC_SCL, (PTU | IEN | M0)},     /*  I2C1_PMIC_SCL         */
+	{I2C1_PMIC_SDA, (PTU | IEN | M0)},     /*  I2C1_PMIC_SDA         */
+
+};
+
+const struct pad_conf_entry wkup_padconf_array_non_essential[] = {
+
+	{LLIA_WAKEREQIN, (PTU | IEN | M6)},    /*  GPIO1_WK14 In J201:19 */
+	{LLIB_WAKEREQIN, (PTU | IEN | M6)},    /*  GPIO1_WK15 In J801:18 */
+	{DRM_EMU0, (PTU | IEN | M0)},          /*  DRM_EMU0      */
+	{DRM_EMU1, (PTU | IEN | M0)},          /*  DRM_EMU1      */
+	{JTAG_NTRST, (IEN | M0)},              /*  JTAG_NTRST    */
+	{JTAG_TCK, (IEN | M0)},                /*  JTAG_TCK      */
+	{JTAG_RTCK, (M0)},                     /*  JTAG_RTCK     */
+	{JTAG_TMSC, (IEN | M0)},               /*  JTAG_TMSC     */
+	{JTAG_TDI, (IEN | M0)},                /*  JTAG_TDI      */
+	{JTAG_TDO, (M0)},                      /*  JTAG_TDO      */
+	{FREF_CLK_IOREQ, (PTU | IEN | M6)},    /*  GPIO1_WK13 In ETH_WAKE */
+	{FREF_CLK0_OUT, (M0)},                 /*  FREF_CLK0_OUT  */
+	{FREF_CLK1_OUT, (M0)},                 /*  FREF_CLK1_OUT  */
+	{FREF_CLK2_OUT, (M0)},                 /*  FREF_CLK2_OUT  */
+	{FREF_CLK2_REQ, (PTU | IEN | M6)},     /*  GPIO1_WK9 In WiLink Int */
+	{FREF_CLK1_REQ, (PTU | IEN | M6)},     /*  GPIO1_WK8 In SH2_MSP_INT */
+	{SYS_NRESPWRON, (IEN | M0)},           /*  SYS_NRESPWRON  */
+	{SYS_NRESWARM, (PTU | IEN | M0)},      /*  SYS_NRESWARM   */
+	{SYS_PWR_REQ, (M0)},                   /*  SYS_PWR_REQ    */
+	{SYS_NIRQ1, (PTU | IEN | M0)},         /*  SYS_NIRQ1      */
+	{SYS_NIRQ2, (PTU | IEN | M0)},         /*  SYS_NIRQ2      */
+	{SYS_BOOT0, (IEN | M0)},               /*  SYS_BOOT0      */
+	{SYS_BOOT1, (IEN | M0)},               /*  SYS_BOOT1      */
+	{SYS_BOOT2, (IEN | M0)},               /*  SYS_BOOT2      */
+	{SYS_BOOT3, (IEN | M0)},               /*  SYS_BOOT3      */
+	{SYS_BOOT4, (IEN | M0)},               /*  SYS_BOOT4      */
+	{SYS_BOOT5, (IEN | M0)},               /*  SYS_BOOT5      */
+
+};
+
+#endif /* _SOM5_EVB_MUX_DATA_H */
+
diff --git a/board/mms/som5_evb/som5_evb.c b/board/mms/som5_evb/som5_evb.c
new file mode 100644
index 0000000..a84672e
--- /dev/null
+++ b/board/mms/som5_evb/som5_evb.c
@@ -0,0 +1,200 @@ 
+/*
+ * Copyright (C) 2013 MM Solutions AD, <www.mm-sol.com>
+ *
+ * 02/2013 Derived from OMAP5 EVM and modified for the SOM5 EVB
+ *         by Lubomir Popov <lpopov@mm-sol.com> <l-popov@ti.com>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+#include <common.h>
+#include <twl6035.h>
+#include <asm/arch/sys_proto.h>
+#include <asm/arch/mmc_host_def.h>
+#include <asm/gpio.h>
+#include <asm/omap_common.h>
+
+#include "s5evb_mux_data.h"
+
+#ifdef CONFIG_USB_EHCI
+#include <usb.h>
+#include <asm/arch/ehci.h>
+#include <asm/ehci-omap.h>
+#endif
+
+DECLARE_GLOBAL_DATA_PTR;
+
+const struct omap_sysinfo sysinfo = {
+	"Board: MM Solutions SOM5 EVB\n"
+};
+
+/**
+ * @brief board_init
+ *
+ * @return 0
+ */
+int board_init(void)
+{
+	gpmc_init();
+	gd->bd->bi_arch_number = MACH_TYPE_SOM5_EVB;
+	gd->bd->bi_boot_params = (0x80000000 + 0x100);	/* boot param addr */
+
+	return 0;
+}
+
+int board_eth_init(bd_t *bis)
+{
+	return 0;
+}
+
+/**
+ * @brief misc_init_r - Configure SOM5 EVB board specific features
+ * such as power configurations, ethernet initialization as phase2
+ * of boot sequence
+ *
+ * @return 0
+ */
+int misc_init_r(void)
+{
+#ifdef CONFIG_TWL6035_POWER
+	twl6035_init_settings();
+#ifdef CONFIG_TWL6035_AUDPWR
+	/* Useful for measuring voltages around the codec.
+	 * Works with a TWL604x only.
+	 */
+	twl6035_audio_power(1);	/* Power on 2.1 V SMPS, enable 32 kHz */
+	udelay(1000);		/* Allow ramp-up */
+	/* Start TWL6040 internal power on sequence: */
+	gpio_request(CONFIG_OMAP_AUDPWRON_GPIO, "AUDPWRON");
+	gpio_direction_output(CONFIG_OMAP_AUDPWRON_GPIO, 1);	
+#endif
+#ifdef CONFIG_BB_CHRG
+	/* Board has a 3 V super-cap for BB */
+	twl6035_enable_bb_charge(BB_HIGH_ICHRG | BB_VSEL_3V0 | BB_CHRG_EN);
+#endif
+#endif	/* CONFIG_TWL6035_POWER */
+#ifdef CONFIG_SYSCLK_OUT_EN
+	/* Enable FREF_XTAL_CLK output (19.2 MHz).
+	 * Used as Audio MCLK; for measurement only.
+	 * TODO: Use proper defines
+	 * control_ckobuffer
+	 */
+	writel(0x10000000, 0x4ae0cdb4);
+#endif
+	return 0;
+}
+
+void set_muxconf_regs_essential(void)
+{
+	do_set_mux(CONTROL_PADCONF_CORE, core_padconf_array_essential,
+		   sizeof(core_padconf_array_essential) /
+		   sizeof(struct pad_conf_entry));
+
+	do_set_mux(CONTROL_PADCONF_WKUP, wkup_padconf_array_essential,
+		   sizeof(wkup_padconf_array_essential) /
+		   sizeof(struct pad_conf_entry));
+
+	/* Set the MSECURE Mode for GPIO234 pin */
+	if (get_device_type() == DEVICE_GP) {
+		u32 msecure_pad = CONTROL_PADCONF_CORE + GPIO8_234;
+		writew((readw(msecure_pad) & ~M7) | M1, msecure_pad);
+	}
+#ifdef CONFIG_I2C_INTERNAL_PULLUPS
+	/* Enable internal I2C-compatible pullups on all buses
+	 * TODO: Replace this ugly hardcoding with proper defines (omap.h)
+	 * control_smart3io_padconf_0, control_i2c_0
+	 */
+	writel(0x00554000, 0x4a002dc0);		/* First set drive strength */
+	writel(0, 0x4a002e04);			/* Now enable pull-ups */
+#endif
+}
+
+void set_muxconf_regs_non_essential(void)
+{
+	do_set_mux(CONTROL_PADCONF_CORE, core_padconf_array_non_essential,
+		   sizeof(core_padconf_array_non_essential) /
+		   sizeof(struct pad_conf_entry));
+
+	do_set_mux(CONTROL_PADCONF_WKUP, wkup_padconf_array_non_essential,
+		   sizeof(wkup_padconf_array_non_essential) /
+		   sizeof(struct pad_conf_entry));
+}
+
+#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_GENERIC_MMC)
+int board_mmc_init(bd_t *bis)
+{
+	omap_mmc_init(0, 0, 0, -1, -1);
+	omap_mmc_init(1, 0, 0, -1, -1);
+	return 0;
+}
+#endif
+
+#ifdef CONFIG_USB_EHCI
+
+#define USB_HOST_HS_CLKCTRL_MASK	0x0100D7C0	/* CM_L3INIT_USB_HOST_HS_CLKCTRL */
+#define USB_TLL_HS_CLKCTRL_MASK		0x00000700	/* CM_L3INIT_USB_TLL_HS_CLKCTRL */
+
+static struct omap_usbhs_board_data usbhs_bdata = {
+	.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,	/* USBB1: ULPI PHY TUSB1210 */
+	.port_mode[1] = OMAP_EHCI_PORT_MODE_HSIC,	/* USBB2: HSIC USB4640 hub */
+	.port_mode[2] = OMAP_EHCI_PORT_MODE_HSIC,	/* USBB3: HSIC LAN9730 Ethernet ctrl */
+};
+
+int ehci_hcd_init(int index, struct ehci_hccr **hccr, struct ehci_hcor **hcor)
+{
+	int ret;
+
+	/* Enbale all 3 USB ports UHH, UTMI and HSIC clocks */
+	setbits_le32((*prcm)->cm_l3init_hsusbhost_clkctrl,
+			USB_HOST_HS_CLKCTRL_MASK);
+
+	/* Enbale all 3 USB host ports TLL clocks */
+	setbits_le32((*prcm)->cm_l3init_hsusbtll_clkctrl,
+			USB_TLL_HS_CLKCTRL_MASK);
+
+	/* USBB1 ULPI PHY uses OMAP FREF_CLK0_OUT. Must turn it on.
+	 * TODO: Replace this ugly hardcoding with proper defines
+	 */
+	writel(0x0100, 0x4ae0a310);
+	udelay(1000);					/* Let PHY PLL lock */
+
+	ret = omap_ehci_hcd_init(&usbhs_bdata, hccr, hcor);
+	if (ret < 0)
+		return ret;
+
+	return 0;
+}
+
+int ehci_hcd_stop(void)
+{
+	int ret;
+
+	ret = omap_ehci_hcd_stop();
+	
+	clrbits_le32((*prcm)->cm_l3init_hsusbhost_clkctrl,
+			USB_HOST_HS_CLKCTRL_MASK);
+	clrbits_le32((*prcm)->cm_l3init_hsusbtll_clkctrl,
+			USB_TLL_HS_CLKCTRL_MASK);
+			
+	/* TODO: Replace this ugly hardcoding with proper defines
+	 */
+	writel(0, 0x4ae0a310);				/* Stop FREF_CLK0_OUT */
+	return ret;
+}
+#endif /* CONFIG_USB_EHCI */
+
diff --git a/boards.cfg b/boards.cfg
index 5fc70be..337dc42 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -292,6 +292,7 @@  twister                      arm         armv7       twister             technex
 nokia_rx51                   arm         armv7       rx51                nokia          omap3
 omap4_panda                  arm         armv7       panda               ti             omap4
 omap4_sdp4430                arm         armv7       sdp4430             ti             omap4
+omap5_som5_evb               arm         armv7       som5_evb            mms            omap5
 omap5_evm                    arm         armv7       omap5_evm           ti		omap5
 dra7xx_evm		     arm	 armv7	     dra7xx		 ti	        omap5
 s5p_goni                     arm         armv7       goni                samsung        s5pc1xx
diff --git a/include/configs/omap5_som5_evb.h b/include/configs/omap5_som5_evb.h
new file mode 100644
index 0000000..46a9c0c
--- /dev/null
+++ b/include/configs/omap5_som5_evb.h
@@ -0,0 +1,336 @@ 
+/*
+ * Copyright (C) 2013 MM Solutions AD, <www.mm-sol.com>
+ *
+ * 02/2013 Derived from OMAP5 EVM and modified for the SOM5 EVB
+ *         by Lubomir Popov <lpopov@mm-sol.com> <l-popov@ti.com>
+ *
+ * Configuration settings for the MMS SOM5 (APM-5) Evaluation Board.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.	 See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
+/*
+ * High Level Configuration Options
+ */
+#define CONFIG_ARMV7			/* This is an ARM V7 CPU core */
+#define CONFIG_OMAP			/* in a TI OMAP core */
+#define CONFIG_OMAP54XX			/* which is a 54XX */
+#define CONFIG_OMAP5430			/* which is in a 5430 */
+#define CONFIG_SOM5EVB			/* working with the SOM5 EVB */
+/* Machine type for Linux */
+#define CONFIG_MACH_TYPE		MACH_TYPE_SOM5_EVB
+
+#define CONFIG_OMAP_GPIO
+
+/* Get CPU defs */
+#include <asm/arch/cpu.h>
+#include <asm/arch/omap.h>
+
+/* Display CPU and Board Info */
+#define CONFIG_DISPLAY_CPUINFO
+#define CONFIG_DISPLAY_BOARDINFO
+
+/* Clock Defines */
+#define V_OSCK				19200000	/* Clock output from T2 */
+#define V_SCLK                   	V_OSCK
+/* Enable all clocks: */
+/*#define CONFIG_SYS_CLOCKS_ENABLE_ALL*/
+
+#define CONFIG_SYS_ENABLE_PADS_ALL	/* Enable all PADS for now */
+
+#define CONFIG_MISC_INIT_R
+
+#define CONFIG_OF_LIBFDT
+#define CONFIG_CMD_BOOTZ
+
+#define CONFIG_CMDLINE_TAG		/* enable passing of ATAGs */
+#define CONFIG_SETUP_MEMORY_TAGS
+#define CONFIG_INITRD_TAG
+
+/*
+ * Size of malloc() pool
+ * Total Size Environment - 128k
+ * Malloc - add 256k
+ */
+#define CONFIG_ENV_SIZE			(128 << 10)
+#define CONFIG_SYS_MALLOC_LEN		(CONFIG_ENV_SIZE + (256 << 10))
+/* Vector Base */
+#define CONFIG_SYS_CA15_VECTOR_BASE	SRAM_ROM_VECT_BASE
+
+/*
+ * Hardware drivers
+ */
+
+/*
+ * serial port - NS16550 compatible
+ */
+#define V_NS16550_CLK			48000000
+
+#define CONFIG_SYS_NS16550
+#define CONFIG_SYS_NS16550_SERIAL
+#define CONFIG_SYS_NS16550_REG_SIZE	(-4)
+#define CONFIG_SYS_NS16550_CLK		V_NS16550_CLK
+#define CONFIG_CONS_INDEX		3
+#define CONFIG_SYS_NS16550_COM3		UART3_BASE
+
+#define CONFIG_BAUDRATE			115200
+#define CONFIG_SYS_BAUDRATE_TABLE	{4800, 9600, 19200, 38400, \
+					57600, 115200}
+
+/* I2C  */
+#define CONFIG_HARD_I2C
+#define CONFIG_SYS_I2C_SPEED		100000
+#define CONFIG_SYS_I2C_SLAVE		0x00	/* Own slave addr */
+#define CONFIG_DRIVER_OMAP54XX_I2C
+#define CONFIG_I2C_MULTI_BUS
+/* MUST be defined if external pullups are not populated: */
+#define	CONFIG_I2C_INTERNAL_PULLUPS
+/* Define to use Repeated Start by i2c_read (otherwise Stop-Start
+ * shall be used between the address and data phases):
+ */
+#undef	CONFIG_I2C_REPEATED_START
+/* Used by i2c mm/mw; needed for correct write to EEPROM: */
+#define CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS	10
+
+/* TWL6035 */
+#ifndef CONFIG_SPL_BUILD
+#define CONFIG_TWL6035_POWER
+/* Undef to disable forced PWM mode for the 1.8 V SMPS: */
+#define CONFIG_TWL6035_SMPS7_FPWM
+/* Following define enables testing of the TWL6040 audio codec power
+ * supply environment: the PMIC 2.1 V SMPS, and the codec's internal
+ * REF, NCP and HS/LS LDOs. Undef to disable powering up codec.   */
+#define CONFIG_TWL6035_AUDPWR
+
+#ifdef CONFIG_TWL6035_AUDPWR
+#define CONFIG_OMAP_AUDPWRON_GPIO	145
+#endif
+/* Undef to disable BB (super-cap) charging: */
+#define CONFIG_BB_CHRG
+#endif /* CONFIG_SPL_BUILD */
+
+/* For Audio MCLK test/measurement only; enables the
+ * OMAP5 FREF_XTAL_CLK output: */
+#define CONFIG_SYSCLK_OUT_EN
+
+/* MMC */
+#define CONFIG_GENERIC_MMC
+#define CONFIG_MMC
+#define CONFIG_OMAP_HSMMC
+#define CONFIG_DOS_PARTITION
+
+/* MMC ENV related defines */
+#define CONFIG_ENV_IS_NOWHERE
+#ifdef CONFIG_ENV_IS_IN_MMC
+#define CONFIG_SYS_MMC_ENV_DEV		1	/* SLOT2: eMMC(1) */
+#define CONFIG_ENV_OFFSET		0xE0000
+#define CONFIG_CMD_SAVEENV
+#endif
+
+#define CONFIG_SYS_CONSOLE_IS_IN_ENV
+
+/* Flash */
+#define CONFIG_SYS_NO_FLASH
+
+/* Cache */
+#define CONFIG_SYS_CACHELINE_SIZE	64
+#define CONFIG_SYS_CACHELINE_SHIFT	6
+
+/* USB UHH support options */
+#define CONFIG_CMD_USB
+#define CONFIG_USB_HOST
+#define CONFIG_USB_EHCI
+#define CONFIG_USB_EHCI_OMAP
+#define CONFIG_USB_ULPI
+#define CONFIG_USB_ULPI_VIEWPORT_OMAP
+#define CONFIG_USB_STORAGE
+#define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS	3
+
+/* No signals to reset external PHYs on this board: */
+/*#define CONFIG_OMAP_EHCI_PHY1_RESET_GPIO	xxx */
+
+/* Due to HSIC connect ussues, device reset is required upon
+ * applying port power. A GPIO is needed per HSIC device:
+ */
+#define CONFIG_OMAP_HSIC_PORT2_RESET_GPIO	173	/* Combo hub */
+#define CONFIG_OMAP_HSIC_PORT3_RESET_GPIO	172	/* Ethernet Ctrlr */
+
+/* USB Networking options */
+
+#define CONFIG_USB_HOST_ETHER
+#define CONFIG_USB_ETHER_SMSC95XX
+
+/* Commands to include */
+#include <config_cmd_default.h>
+
+/* Enabled commands */
+#define CONFIG_CMD_NET		/* bootp, tftpboot, rarpboot */
+#define CONFIG_CMD_NFS		/* NFS support */
+#define CONFIG_CMD_DHCP		/* DHCP support */
+#define	CONFIG_CMD_PING		/* PING support */
+#define CONFIG_NET_MULTI
+
+#define CONFIG_CMD_EXT2		/* EXT2 support */
+#define CONFIG_CMD_FAT		/* FAT support */
+#define CONFIG_CMD_I2C		/* I2C serial bus support */
+#define CONFIG_CMD_MMC		/* MMC support */
+#define	CONFIG_CMD_GPIO		/* GPIO support */
+
+/* Disabled commands */
+#undef CONFIG_CMD_FPGA		/* FPGA configuration Support */
+#undef CONFIG_CMD_IMLS		/* List all found images */
+
+/*
+ * Environment setup
+ */
+#define CONFIG_BOOTDELAY	3
+
+#define CONFIG_ENV_OVERWRITE
+
+#define CONFIG_EXTRA_ENV_SETTINGS \
+	"usbethaddr=9e:77:39:1b:c4:2d\0" \
+	"loadaddr=0x82000000\0" \
+	"console=ttyO2,115200n8\0" \
+	"usbtty=cdc_acm\0" \
+	"vram=16M\0" \
+	"mmcdev=0\0" \
+	"mmcroot=/dev/mmcblk0p2 rw\0" \
+	"mmcrootfstype=ext3 rootwait\0" \
+	"mmcargs=setenv bootargs console=${console} " \
+		"vram=${vram} " \
+		"root=${mmcroot} " \
+		"rootfstype=${mmcrootfstype}\0" \
+	"loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0" \
+	"bootscript=echo Running bootscript from mmc${mmcdev} ...; " \
+		"source ${loadaddr}\0" \
+	"loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
+	"mmcboot=echo Booting from mmc${mmcdev} ...; " \
+		"run mmcargs; " \
+		"bootm ${loadaddr}\0" \
+
+#define CONFIG_BOOTCOMMAND \
+	"mmc dev ${mmcdev}; " \
+	"if mmc rescan ; then " \
+		"if run loadbootscript; then " \
+			"run bootscript; " \
+		"else " \
+			"if run loaduimage; then " \
+				"run mmcboot; " \
+			"fi; " \
+		"fi; " \
+	"fi "
+
+#define CONFIG_AUTO_COMPLETE		1
+
+/*
+ * Miscellaneous configurable options
+ */
+ 
+#define CONFIG_SYS_PROMPT		"SOM5_EVB # "
+
+#define CONFIG_SYS_LONGHELP		/* undef to save memory */
+#define CONFIG_SYS_HUSH_PARSER		/* use "hush" command parser */
+#define CONFIG_SYS_CBSIZE		256
+/* Print Buffer Size */
+#define CONFIG_SYS_PBSIZE		(CONFIG_SYS_CBSIZE + \
+					sizeof(CONFIG_SYS_PROMPT) + 16)
+#define CONFIG_SYS_MAXARGS		16
+/* Boot Argument Buffer Size */
+#define CONFIG_SYS_BARGSIZE		(CONFIG_SYS_CBSIZE)
+
+/*
+ * memtest setup
+ */
+#define CONFIG_SYS_MEMTEST_START	0xb8000000
+#define CONFIG_SYS_MEMTEST_END		(CONFIG_SYS_MEMTEST_START + (256 << 20))
+/* Undef following two for simple mtest */
+#define CONFIG_SYS_ALT_MEMTEST
+#define CONFIG_SYS_MEMTEST_SCRATCH	0x81000000
+
+/* Default load address */
+#define CONFIG_SYS_LOAD_ADDR		0x80000000
+
+/* Use General purpose timer 1 */
+#define CONFIG_SYS_TIMERBASE		GPT2_BASE
+#define CONFIG_SYS_PTV			2	/* Divisor: 2^(PTV+1) => 8 */
+#define CONFIG_SYS_HZ			1000
+
+/*
+ * SDRAM Memory Map
+ * Even though we use two CS all the memory
+ * is mapped to one contiguous block
+ */
+#define CONFIG_NR_DRAM_BANKS		1
+
+#define CONFIG_SYS_SDRAM_BASE		0x80000000
+
+#define CONFIG_SYS_INIT_SP_ADDR         (NON_SECURE_SRAM_END - \
+					 GENERATED_GBL_DATA_SIZE)
+
+#define CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS
+
+/* Defines for SDRAM init */
+#ifndef CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS
+#define CONFIG_SYS_AUTOMATIC_SDRAM_DETECTION
+#define CONFIG_SYS_DEFAULT_LPDDR2_TIMINGS
+#endif
+
+/* Defines for SPL */
+#define CONFIG_SPL
+#define CONFIG_SPL_FRAMEWORK
+#define CONFIG_SPL_TEXT_BASE		0x40300350
+#define CONFIG_SPL_MAX_SIZE		0x19000		/* 100K */
+#define CONFIG_SPL_STACK		CONFIG_SYS_INIT_SP_ADDR
+#define CONFIG_SPL_DISPLAY_PRINT
+
+#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR	0x300	/* address 0x60000 */
+#define CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS	0x200	/* 256 KB */
+#define CONFIG_SYS_MMC_SD_FAT_BOOT_PARTITION	1
+#define CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME	"u-boot.img"
+
+#define CONFIG_SPL_LIBCOMMON_SUPPORT
+#define CONFIG_SPL_LIBDISK_SUPPORT
+#define CONFIG_SPL_I2C_SUPPORT
+#define CONFIG_SPL_MMC_SUPPORT
+#define CONFIG_SPL_FAT_SUPPORT
+#define CONFIG_SPL_LIBGENERIC_SUPPORT
+#define CONFIG_SPL_SERIAL_SUPPORT
+#define CONFIG_SPL_LDSCRIPT "$(CPUDIR)/omap-common/u-boot-spl.lds"
+
+/*
+ * 64 bytes before this address should be set aside for u-boot.img's
+ * header. That is 0x80E7FFC0--0x80E80000 should not be used for any
+ * other needs.
+ */
+#define CONFIG_SYS_TEXT_BASE		0x80E80000
+
+/*
+ * BSS and malloc area 64MB into memory to allow enough
+ * space for the kernel at the beginning of memory
+ */
+#define CONFIG_SPL_BSS_START_ADDR	0x84000000
+#define CONFIG_SPL_BSS_MAX_SIZE		0x100000	/* 1 MB */
+#define CONFIG_SYS_SPL_MALLOC_START	0x84100000
+#define CONFIG_SYS_SPL_MALLOC_SIZE	0x100000	/* 1 MB */
+#define CONFIG_SPL_GPIO_SUPPORT
+
+#endif /* __CONFIG_H */