Patchwork [U-Boot,05/10] am33xx: add ti814x specific register definitions

login
register
mail settings
Submitter Matt Porter
Date Feb. 13, 2013, 2:43 p.m.
Message ID <1360766644-9901-6-git-send-email-mporter@ti.com>
Download mbox | patch
Permalink /patch/220154/
State Deferred
Delegated to: Tom Rini
Headers show

Comments

Matt Porter - Feb. 13, 2013, 2:43 p.m.
Support the ti814x specific register definitions within
arch-am33xx.

Signed-off-by: Matt Porter <mporter@ti.com>
---
 arch/arm/cpu/armv7/am33xx/sys_info.c        |    3 +++
 arch/arm/include/asm/arch-am33xx/cpu.h      |   11 +++++----
 arch/arm/include/asm/arch-am33xx/hardware.h |   32 +++++++++++++++++++++++++++
 arch/arm/include/asm/arch-am33xx/omap.h     |    7 ++++++
 arch/arm/include/asm/arch-am33xx/spl.h      |    5 +++++
 5 files changed, 54 insertions(+), 4 deletions(-)
Tom Rini - Feb. 15, 2013, 4:37 p.m.
On Wed, Feb 13, 2013 at 09:43:59AM -0500, Matt Porter wrote:

> Support the ti814x specific register definitions within
> arch-am33xx.
> 
> Signed-off-by: Matt Porter <mporter@ti.com>

Reviewed-by: Tom Rini <trini@ti.com>
Peter Korsgaard - Feb. 17, 2013, 8:28 p.m.
>>>>> "Matt" == Matt Porter <mporter@ti.com> writes:

 Matt> Support the ti814x specific register definitions within
 Matt> arch-am33xx.

 Matt> Signed-off-by: Matt Porter <mporter@ti.com>
 Matt> ---
 Matt>  arch/arm/cpu/armv7/am33xx/sys_info.c        |    3 +++
 Matt>  arch/arm/include/asm/arch-am33xx/cpu.h      |   11 +++++----
 Matt>  arch/arm/include/asm/arch-am33xx/hardware.h |   32 +++++++++++++++++++++++++++
 Matt>  arch/arm/include/asm/arch-am33xx/omap.h     |    7 ++++++
 Matt>  arch/arm/include/asm/arch-am33xx/spl.h      |    5 +++++
 Matt>  5 files changed, 54 insertions(+), 4 deletions(-)
 
 Matt> diff --git a/arch/arm/include/asm/arch-am33xx/hardware.h b/arch/arm/include/asm/arch-am33xx/hardware.h
 Matt> index 41ab2c0..786c159 100644
 Matt> --- a/arch/arm/include/asm/arch-am33xx/hardware.h
 Matt> +++ b/arch/arm/include/asm/arch-am33xx/hardware.h
 Matt> @@ -20,9 +20,14 @@
 Matt>  #define __AM33XX_HARDWARE_H
 
 Matt>  #include <asm/arch/omap.h>
 Matt> +#include <config.h>

Quite some of the base addresses are similar, but I wonder if it
wouldn't be cleaner to simply have a hardware-am33xx.h /
hardware-ti814x.h instead of all these ifdef / elif?
 
 Matt>  /* Control Module Base Address */
 Matt> +#ifdef CONFIG_AM33XX
 Matt>  #define CTRL_BASE			0x44E10000
 Matt>  #define CTRL_DEVICE_BASE		0x44E10600
 Matt> +#elif defined(CONFIG_TI814X)
 Matt> +#define CTRL_BASE			0x48140000
 Matt> +#endif

No CTRL_DEVICE_BASE on ti814x?


 Matt> --- a/arch/arm/include/asm/arch-am33xx/spl.h
 Matt> +++ b/arch/arm/include/asm/arch-am33xx/spl.h
 Matt> @@ -25,8 +25,13 @@
 
 Matt>  #define BOOT_DEVICE_XIP       	2
 Matt>  #define BOOT_DEVICE_NAND	5
 Matt> +#ifdef CONFIG_AM33XX
 Matt>  #define BOOT_DEVICE_MMC1	8
 Matt>  #define BOOT_DEVICE_MMC2	9	/* eMMC or daughter card */
 Matt> +#elif defined(CONFIG_TI814X)
 Matt> +#define BOOT_DEVICE_MMC1	9
 Matt> +#define BOOT_DEVICE_MMC2	8	/* ROM only supports 2nd instance */

Argh! Couldn't we just swap the meaning of mmc1/mmc2 or would that be
too confusing?

 Matt> +#endif
 Matt>  #define BOOT_DEVICE_SPI		11
 Matt>  #define BOOT_DEVICE_UART	65
 Matt>  #define BOOT_DEVICE_CPGMAC	70
 Matt> -- 
 Matt> 1.7.9.5

 Matt> _______________________________________________
 Matt> U-Boot mailing list
 Matt> U-Boot@lists.denx.de
 Matt> http://lists.denx.de/mailman/listinfo/u-boot
Tom Rini - Feb. 18, 2013, 3:18 p.m.
On Sun, Feb 17, 2013 at 09:28:33PM +0100, Peter Korsgaard wrote:
> >>>>> "Matt" == Matt Porter <mporter@ti.com> writes:
> 
>  Matt> Support the ti814x specific register definitions within
>  Matt> arch-am33xx.
> 
>  Matt> Signed-off-by: Matt Porter <mporter@ti.com>
>  Matt> ---
>  Matt>  arch/arm/cpu/armv7/am33xx/sys_info.c        |    3 +++
>  Matt>  arch/arm/include/asm/arch-am33xx/cpu.h      |   11 +++++----
>  Matt>  arch/arm/include/asm/arch-am33xx/hardware.h |   32 +++++++++++++++++++++++++++
>  Matt>  arch/arm/include/asm/arch-am33xx/omap.h     |    7 ++++++
>  Matt>  arch/arm/include/asm/arch-am33xx/spl.h      |    5 +++++
>  Matt>  5 files changed, 54 insertions(+), 4 deletions(-)
>  
>  Matt> diff --git a/arch/arm/include/asm/arch-am33xx/hardware.h b/arch/arm/include/asm/arch-am33xx/hardware.h
>  Matt> index 41ab2c0..786c159 100644
>  Matt> --- a/arch/arm/include/asm/arch-am33xx/hardware.h
>  Matt> +++ b/arch/arm/include/asm/arch-am33xx/hardware.h
>  Matt> @@ -20,9 +20,14 @@
>  Matt>  #define __AM33XX_HARDWARE_H
>  
>  Matt>  #include <asm/arch/omap.h>
>  Matt> +#include <config.h>
> 
> Quite some of the base addresses are similar, but I wonder if it
> wouldn't be cleaner to simply have a hardware-am33xx.h /
> hardware-ti814x.h instead of all these ifdef / elif?

Since I suspect the things common from ti814x and am33xx are also common
to ti816x (which has been left as an exercise to whomever needs that
next), I think we can re-structure this into something like that, but
keeping the common parts within hardware.h still.

>  Matt>  /* Control Module Base Address */
>  Matt> +#ifdef CONFIG_AM33XX
>  Matt>  #define CTRL_BASE			0x44E10000
>  Matt>  #define CTRL_DEVICE_BASE		0x44E10600
>  Matt> +#elif defined(CONFIG_TI814X)
>  Matt> +#define CTRL_BASE			0x48140000
>  Matt> +#endif
> 
> No CTRL_DEVICE_BASE on ti814x?

I think this is a side-effect of Matt not supporting the things attached
to it (USB in the case of am335x).

>  Matt> --- a/arch/arm/include/asm/arch-am33xx/spl.h
>  Matt> +++ b/arch/arm/include/asm/arch-am33xx/spl.h
>  Matt> @@ -25,8 +25,13 @@
>  
>  Matt>  #define BOOT_DEVICE_XIP       	2
>  Matt>  #define BOOT_DEVICE_NAND	5
>  Matt> +#ifdef CONFIG_AM33XX
>  Matt>  #define BOOT_DEVICE_MMC1	8
>  Matt>  #define BOOT_DEVICE_MMC2	9	/* eMMC or daughter card */
>  Matt> +#elif defined(CONFIG_TI814X)
>  Matt> +#define BOOT_DEVICE_MMC1	9
>  Matt> +#define BOOT_DEVICE_MMC2	8	/* ROM only supports 2nd instance */
> 
> Argh! Couldn't we just swap the meaning of mmc1/mmc2 or would that be
> too confusing?

IMHO, that will lead to further confusion down the line.  I talked with
Matt about this before and well, it's funky.
Peter Korsgaard - Feb. 18, 2013, 3:21 p.m.
>>>>> "Tom" == Tom Rini <trini@ti.com> writes:

Hi,

 >> Quite some of the base addresses are similar, but I wonder if it
 >> wouldn't be cleaner to simply have a hardware-am33xx.h /
 >> hardware-ti814x.h instead of all these ifdef / elif?

 Tom> Since I suspect the things common from ti814x and am33xx are also common
 Tom> to ti816x (which has been left as an exercise to whomever needs that
 Tom> next), I think we can re-structure this into something like that, but
 Tom> keeping the common parts within hardware.h still.

FYI, I might very well be that guy as I've recently started work on a
ti816x based project.

 >> Argh! Couldn't we just swap the meaning of mmc1/mmc2 or would that be
 >> too confusing?

 Tom> IMHO, that will lead to further confusion down the line.  I talked with
 Tom> Matt about this before and well, it's funky.

Ok.
Brian Hutchinson - Feb. 21, 2013, 10:08 p.m.
I need ti816x u-boot too!  Maybe I can help too. Need 3.x kernel too but I
guess that is for another list :)

Regards,

Brian

On Feb 18, 2013 7:21 AM, "Peter Korsgaard" <jacmet@sunsite.dk> wrote:
>
> >>>>> "Tom" == Tom Rini <trini@ti.com> writes:
>
> Hi,
>
>  >> Quite some of the base addresses are similar, but I wonder if it
>  >> wouldn't be cleaner to simply have a hardware-am33xx.h /
>  >> hardware-ti814x.h instead of all these ifdef / elif?
>
>  Tom> Since I suspect the things common from ti814x and am33xx are also
common
>  Tom> to ti816x (which has been left as an exercise to whomever needs that
>  Tom> next), I think we can re-structure this into something like that,
but
>  Tom> keeping the common parts within hardware.h still.
>
> FYI, I might very well be that guy as I've recently started work on a
> ti816x based project.
>
>  >> Argh! Couldn't we just swap the meaning of mmc1/mmc2 or would that be
>  >> too confusing?
>
>  Tom> IMHO, that will lead to further confusion down the line.  I talked
with
>  Tom> Matt about this before and well, it's funky.
>
> Ok.
>
> --
> Bye, Peter Korsgaard
> _______________________________________________
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
Peter Korsgaard - Feb. 22, 2013, 3:37 p.m.
>>>>> "Brian" == Brian Hutchinson <b.hutchman@gmail.com> writes:

Hi,

 Brian> I need ti816x u-boot too!  Maybe I can help too. Need 3.x kernel
 Brian> too but I guess that is for another list :)

Antoine is working on it, and the basics are running:

U-Boot SPL 2013.01-00297-gf592f9c-dirty (Feb 22 2013 - 16:25:01)
OMAP SD/MMC: 0
boot mode - FAT
reading u-boot.img
reading u-boot.img


U-Boot 2013.01-00297-gf592f9c-dirty (Feb 22 2013 - 16:25:01)

AMTI81XX-GP rev 1
DRAM:  1 GiB
WARNING: Caches not enabled
MMC:   OMAP SD/MMC: 0
Using default environment

Net:   DaVinci-EMAC
Hit any key to stop autoboot:  0

I'm looking at the emac driver at the moment. It still needs some more
work and cleanup, but I would imagine an early series could be posted
next week or so is Antoine agrees.
Tom Rini - Feb. 22, 2013, 3:51 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/22/2013 10:37 AM, Peter Korsgaard wrote:
>>>>>> "Brian" == Brian Hutchinson <b.hutchman@gmail.com>
>>>>>> writes:
> 
> Hi,
> 
> Brian> I need ti816x u-boot too!  Maybe I can help too. Need 3.x
> kernel Brian> too but I guess that is for another list :)
> 
> Antoine is working on it, and the basics are running:
> 
> U-Boot SPL 2013.01-00297-gf592f9c-dirty (Feb 22 2013 - 16:25:01) 
> OMAP SD/MMC: 0 boot mode - FAT reading u-boot.img reading
> u-boot.img
> 
> 
> U-Boot 2013.01-00297-gf592f9c-dirty (Feb 22 2013 - 16:25:01)
> 
> AMTI81XX-GP rev 1 DRAM:  1 GiB WARNING: Caches not enabled MMC:
> OMAP SD/MMC: 0 Using default environment
> 
> Net:   DaVinci-EMAC Hit any key to stop autoboot:  0
> 
> I'm looking at the emac driver at the moment. It still needs some
> more work and cleanup, but I would imagine an early series could be
> posted next week or so is Antoine agrees.

Can we please make the emac driver switch to phylib while you're in
there?  Thanks!

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

iQIcBAEBAgAGBQJRJ5PvAAoJENk4IS6UOR1WbzMP/jj3pbTEdKtC3ZVoPIPAXSt7
cOqiqgEZT8eeP9EPOTuM/Gp11W5ARHhxbD9x/6QG3fVqDSO+aMR5RBcfvRllIMXP
3KqI0hrGrrW5l0mkN/y0TH9A2rwGeqs4NxkV0QK6USQz7ei11iqSf9bW4fhQ6/9i
BkzCxrK4Jl1BMcPHx8x4EnTAzscteQQeKmQGrPjI1HjdPeQ7R9v/Azl7rtBbNeGd
JwSBGWiiZAL6C3tYQi5N90zgeGlk1lChJkTB3knunD2IGnFL1KpAy2I7q/IEf55i
sc6R4TNZlKpp/IOEvd69KYjAQzefcAMryiLQJsMlw8L6XTDuVEC2H1EztfLqawGZ
pUkVUDRKqKXzZYZQNgv0f/+euUWB04IOzSw1lI0SqLK43h8Mkdh0UTcRIOEFhlR/
j7LKi2Nw3PTwub9tCXHd3a9iOtUtMT55CuPOFaj3jBOBU3PADiFoD9zvD49oir8Z
ruc7Mtm/stvTnAsW/IsPuXXyxhv3wO5YrMO2AzbaZTqf3hvNcaIQStWVCZLdjs7U
rsvDW5P4ocoYgQfexXsg4/sOuJfu7JCIzmejovuNsJMxJREjuCIdMrQlW0SaGuf6
5wZKakYgNKyITyJFDtM9FatflOwpYTLP4MnnDNnFuup0/yuUHwYHoCyaiiscDsYv
7eaCMGN9K0g6q1+EWhCR
=WPpm
-----END PGP SIGNATURE-----
Peter Korsgaard - Feb. 22, 2013, 4:34 p.m.
>>>>> "Tom" == Tom Rini <trini@ti.com> writes:

Hi,

 >> I'm looking at the emac driver at the moment. It still needs some
 >> more work and cleanup, but I would imagine an early series could be
 >> posted next week or so is Antoine agrees.

 Tom> Can we please make the emac driver switch to phylib while you're
 Tom> in there?  Thanks!

I can have a look, but I don't have access to any of the older devices
using the driver.
Matt Porter - Feb. 25, 2013, 2:46 p.m.
On Mon, Feb 18, 2013 at 03:18:42PM +0000, Tom Rini wrote:
> On Sun, Feb 17, 2013 at 09:28:33PM +0100, Peter Korsgaard wrote:
> > >>>>> "Matt" == Matt Porter <mporter@ti.com> writes:
> > 
> >  Matt> Support the ti814x specific register definitions within
> >  Matt> arch-am33xx.
> > 
> >  Matt> Signed-off-by: Matt Porter <mporter@ti.com>
> >  Matt> ---
> >  Matt>  arch/arm/cpu/armv7/am33xx/sys_info.c        |    3 +++
> >  Matt>  arch/arm/include/asm/arch-am33xx/cpu.h      |   11 +++++----
> >  Matt>  arch/arm/include/asm/arch-am33xx/hardware.h |   32 +++++++++++++++++++++++++++
> >  Matt>  arch/arm/include/asm/arch-am33xx/omap.h     |    7 ++++++
> >  Matt>  arch/arm/include/asm/arch-am33xx/spl.h      |    5 +++++
> >  Matt>  5 files changed, 54 insertions(+), 4 deletions(-)
> >  
> >  Matt> diff --git a/arch/arm/include/asm/arch-am33xx/hardware.h b/arch/arm/include/asm/arch-am33xx/hardware.h
> >  Matt> index 41ab2c0..786c159 100644
> >  Matt> --- a/arch/arm/include/asm/arch-am33xx/hardware.h
> >  Matt> +++ b/arch/arm/include/asm/arch-am33xx/hardware.h
> >  Matt> @@ -20,9 +20,14 @@
> >  Matt>  #define __AM33XX_HARDWARE_H
> >  
> >  Matt>  #include <asm/arch/omap.h>
> >  Matt> +#include <config.h>
> > 
> > Quite some of the base addresses are similar, but I wonder if it
> > wouldn't be cleaner to simply have a hardware-am33xx.h /
> > hardware-ti814x.h instead of all these ifdef / elif?
> 
> Since I suspect the things common from ti814x and am33xx are also common
> to ti816x (which has been left as an exercise to whomever needs that
> next), I think we can re-structure this into something like that, but
> keeping the common parts within hardware.h still.

Sounds good. I'll restructure with only the common parts in hardware.h.

> >  Matt>  /* Control Module Base Address */
> >  Matt> +#ifdef CONFIG_AM33XX
> >  Matt>  #define CTRL_BASE			0x44E10000
> >  Matt>  #define CTRL_DEVICE_BASE		0x44E10600
> >  Matt> +#elif defined(CONFIG_TI814X)
> >  Matt> +#define CTRL_BASE			0x48140000
> >  Matt> +#endif
> > 
> > No CTRL_DEVICE_BASE on ti814x?
> 
> I think this is a side-effect of Matt not supporting the things attached
> to it (USB in the case of am335x).

I tried to avoid defining things I'm not yet using. For CTRL_DEVICE_BASE,
I would add it once I get to adding cpsw support as we need to read the
efused macid value from that area.

> >  Matt> --- a/arch/arm/include/asm/arch-am33xx/spl.h
> >  Matt> +++ b/arch/arm/include/asm/arch-am33xx/spl.h
> >  Matt> @@ -25,8 +25,13 @@
> >  
> >  Matt>  #define BOOT_DEVICE_XIP       	2
> >  Matt>  #define BOOT_DEVICE_NAND	5
> >  Matt> +#ifdef CONFIG_AM33XX
> >  Matt>  #define BOOT_DEVICE_MMC1	8
> >  Matt>  #define BOOT_DEVICE_MMC2	9	/* eMMC or daughter card */
> >  Matt> +#elif defined(CONFIG_TI814X)
> >  Matt> +#define BOOT_DEVICE_MMC1	9
> >  Matt> +#define BOOT_DEVICE_MMC2	8	/* ROM only supports 2nd instance */
> > 
> > Argh! Couldn't we just swap the meaning of mmc1/mmc2 or would that be
> > too confusing?
> 
> IMHO, that will lead to further confusion down the line.  I talked with
> Matt about this before and well, it's funky.

This is definitely a quirky area wrt TI814x. AFAIK it's the only
OMAP-ish part where the ROM only allows boot from a single MMC instance.
Further, that single MMC instance is actually the 2nd one as noted in
the comment. This means to keep all the existing SPL mmc init logic
intact, we need to define as above so that the unimplemented first MMC
instance (which does exist on the part) does not get intialized when the
ROM drops a bootdevice of "8".

-Matt

Patch

diff --git a/arch/arm/cpu/armv7/am33xx/sys_info.c b/arch/arm/cpu/armv7/am33xx/sys_info.c
index 507b618..402127c 100644
--- a/arch/arm/cpu/armv7/am33xx/sys_info.c
+++ b/arch/arm/cpu/armv7/am33xx/sys_info.c
@@ -98,6 +98,9 @@  int print_cpuinfo(void)
 	case AM335X:
 		cpu_s = "AM335X";
 		break;
+	case TI81XX:
+		cpu_s = "TI81XX";
+		break;
 	default:
 		cpu_s = "Unknown cpu type";
 		break;
diff --git a/arch/arm/include/asm/arch-am33xx/cpu.h b/arch/arm/include/asm/arch-am33xx/cpu.h
index 16e8a80..3d3a7c8 100644
--- a/arch/arm/include/asm/arch-am33xx/cpu.h
+++ b/arch/arm/include/asm/arch-am33xx/cpu.h
@@ -42,9 +42,10 @@ 
 #define HS_DEVICE			0x2
 #define GP_DEVICE			0x3
 
-/* cpu-id for AM33XX family */
+/* cpu-id for AM33XX and TI81XX family */
 #define AM335X				0xB944
-#define DEVICE_ID			0x44E10600
+#define TI81XX				0xB81E
+#define DEVICE_ID			(CTRL_BASE + 0x0600)
 
 /* This gives the status of the boot mode pins on the evm */
 #define SYSBOOT_MASK			(BIT(0) | BIT(1) | BIT(2)\
@@ -52,9 +53,11 @@ 
 
 /* Reset control */
 #ifdef CONFIG_AM33XX
-#define PRM_RSTCTRL			0x44E00F00
-#define PRM_RSTST			0x44E00F08
+#define PRM_RSTCTRL			(PRCM_BASE + 0x0F00)
+#elif defined(CONFIG_TI814X)
+#define PRM_RSTCTRL			(PRCM_BASE + 0x00A0)
 #endif
+#define PRM_RSTST			(PRM_RSTCTRL + 8)
 #define PRM_RSTCTRL_RESET		0x01
 #define PRM_RSTST_WARM_RESET_MASK	0x232
 
diff --git a/arch/arm/include/asm/arch-am33xx/hardware.h b/arch/arm/include/asm/arch-am33xx/hardware.h
index 41ab2c0..786c159 100644
--- a/arch/arm/include/asm/arch-am33xx/hardware.h
+++ b/arch/arm/include/asm/arch-am33xx/hardware.h
@@ -20,9 +20,14 @@ 
 #define __AM33XX_HARDWARE_H
 
 #include <asm/arch/omap.h>
+#include <config.h>
 
 /* Module base addresses */
+#ifdef CONFIG_AM33XX
 #define UART0_BASE			0x44E09000
+#elif defined(CONFIG_TI814X)
+#define UART0_BASE			0x48020000
+#endif
 
 /* DM Timer base addresses */
 #define DM_TIMER0_BASE			0x4802C000
@@ -37,20 +42,39 @@ 
 /* GPIO Base address */
 #define GPIO0_BASE			0x48032000
 #define GPIO1_BASE			0x4804C000
+#ifdef CONFIG_AM33XX
 #define GPIO2_BASE			0x481AC000
+#endif
 
 /* BCH Error Location Module */
 #define ELM_BASE			0x48080000
 
 /* Watchdog Timer */
+#ifdef CONFIG_AM33XX
 #define WDT_BASE			0x44E35000
+#elif defined(CONFIG_TI814X)
+#define WDT_BASE			0x481C7000
+#endif
 
 /* Control Module Base Address */
+#ifdef CONFIG_AM33XX
 #define CTRL_BASE			0x44E10000
 #define CTRL_DEVICE_BASE		0x44E10600
+#elif defined(CONFIG_TI814X)
+#define CTRL_BASE			0x48140000
+#endif
 
 /* PRCM Base Address */
+#ifdef CONFIG_AM33XX
 #define PRCM_BASE			0x44E00000
+#elif defined(CONFIG_TI814X)
+#define PRCM_BASE			0x48180000
+#endif
+
+/* PLL Subsystem Base Address */
+#ifdef CONFIG_TI814X
+#define PLL_SUBSYS_BASE			0x481C5000
+#endif
 
 /* EMIF Base address */
 #define EMIF4_0_CFG_BASE		0x4C000000
@@ -99,10 +123,18 @@ 
 
 /* CPSW Config space */
 #define CPSW_BASE			0x4A100000
+#ifdef CONFIG_AM33XX
 #define CPSW_MDIO_BASE			0x4A101000
+#elif defined(CONFIG_TI814X)
+#define CPSW_MDIO_BASE			0x4A100800
+#endif
 
 /* RTC base address */
+#ifdef CONFIG_AM33XX
 #define RTC_BASE			0x44E3E000
+#elif defined(CONFIG_TI814X)
+#define RTC_BASE			0x480C0000
+#endif
 
 /* OTG */
 #define USB0_OTG_BASE			0x47401000
diff --git a/arch/arm/include/asm/arch-am33xx/omap.h b/arch/arm/include/asm/arch-am33xx/omap.h
index 850f8a5..ba4f6d2 100644
--- a/arch/arm/include/asm/arch-am33xx/omap.h
+++ b/arch/arm/include/asm/arch-am33xx/omap.h
@@ -23,13 +23,20 @@ 
 #ifndef _OMAP_H_
 #define _OMAP_H_
 
+#include <config.h>
+
 /*
  * Non-secure SRAM Addresses
  * Non-secure RAM starts at 0x40300000 for GP devices. But we keep SRAM_BASE
  * at 0x40304000(EMU base) so that our code works for both EMU and GP
  */
+#ifdef CONFIG_AM33XX
 #define NON_SECURE_SRAM_START	0x40304000
 #define NON_SECURE_SRAM_END	0x4030E000
+#elif defined(CONFIG_TI814X)
+#define NON_SECURE_SRAM_START	0x40300000
+#define NON_SECURE_SRAM_END	0x40320000
+#endif
 
 /* ROM code defines */
 /* Boot device */
diff --git a/arch/arm/include/asm/arch-am33xx/spl.h b/arch/arm/include/asm/arch-am33xx/spl.h
index 644ff35..9b5fe9e 100644
--- a/arch/arm/include/asm/arch-am33xx/spl.h
+++ b/arch/arm/include/asm/arch-am33xx/spl.h
@@ -25,8 +25,13 @@ 
 
 #define BOOT_DEVICE_XIP       	2
 #define BOOT_DEVICE_NAND	5
+#ifdef CONFIG_AM33XX
 #define BOOT_DEVICE_MMC1	8
 #define BOOT_DEVICE_MMC2	9	/* eMMC or daughter card */
+#elif defined(CONFIG_TI814X)
+#define BOOT_DEVICE_MMC1	9
+#define BOOT_DEVICE_MMC2	8	/* ROM only supports 2nd instance */
+#endif
 #define BOOT_DEVICE_SPI		11
 #define BOOT_DEVICE_UART	65
 #define BOOT_DEVICE_CPGMAC	70