Skip to contentSkip to conversation

U-Boot MMC SPL for OMAP4

PATCH New Aneesh V 13 participants 244 messages Feb 28, 2011 – Aug 2, 2011 2 messages not in the archive Page 1 of 2

Subsystems (3)
lore
Share & tools
lore

Aneesh V

author
#0 lore raw

cover U-Boot MMC SPL for OMAP4

This series adds mmc SPL support for OMAP4. This is essentially an up-streaming effort for TI's x-loader for OMAP4 using the SPL framework

This work partly draws upon previous work done for x-loader by:
Santosh Shilimkar <[email protected]> Rajendra Nayak <[email protected]>
and many others

Features supported:
* Clock init - DPLL locking, clock domains/modules enabling
* SDRAM/DMM initialization
* Mux initialization
* MMC raw read support
* MMC FAT read support

Improvments over x-loader:
* Code completely revamped
* DPLL programming that works for all SYS_CLK frequencies
* Automatic SDRAM identification and initialization
* Board dependent parts(especially mux) deferred to u-boot. So, same SPL will work for Panda and SDP and most likely on any other board that comes along
* Determination of u-boot size to avoid reading extra content while loading U-Boot
* Modular apporach to enable future addition of support for all OMAP3/4 platforms

Aneesh V (21):
omap: add miscellaneous utility macros for bit-field operations
omap4: add OMAP4430 revision check
armv7: start.S: provide a hook for saving boot params
omap4: save parameters passed by ROM code to SPL
arm: new labels in the linker script file
Add generic spl infrastructure
armv7: start.S: add SPL support
omap: add spl support
omap4: add spl support for OMAP4 SDP
omap4: add serial console support to SPL
omap4: utility function to identify the context of hw init
omap4: separate mux settings into essential and non essential parts
omap4: correct mux data for sdp4430
omap4: add clock support
omap4: add sdram init support
omap4: calculate EMIF register values
omap4: automatic sdram detection
armv7: embed u-boot size within u-boot for use from SPL
omap: add MMC support to SPL
omap: spl: add FAT support over MMC
omap4: add spl support for OMAP4 Panda

John Rigby (1):
mkimage: Add OMAP boot image support

 Makefile                                           |   11 +
 arch/arm/cpu/armv7/cpu.c                           |    7 +
 arch/arm/cpu/armv7/omap-common/Makefile            |    1 +
 .../{omap4/lowlevel_init.S => omap-common/utils.c} |   58 +-
 arch/arm/cpu/armv7/omap4/Makefile                  |    3 +
 arch/arm/cpu/armv7/omap4/board.c                   |  117 ++-
 arch/arm/cpu/armv7/omap4/clocks.c                  |  717 +++++++++++
 arch/arm/cpu/armv7/omap4/emif.c                    | 1303 ++++++++++++++++++++
 arch/arm/cpu/armv7/omap4/lowlevel_init.S           |   31 +
 arch/arm/cpu/armv7/omap4/omap4_mux_data.h          |   76 ++
 arch/arm/cpu/armv7/omap4/sdram_elpida.c            |  267 ++++
 arch/arm/cpu/armv7/start.S                         |   50 +-
 arch/arm/cpu/armv7/u-boot.lds                      |    4 +
 arch/arm/include/asm/arch-omap4/clocks.h           |  504 ++++++++
 arch/arm/include/asm/arch-omap4/emif.h             | 1021 +++++++++++++++
 arch/arm/include/asm/arch-omap4/omap4.h            |   50 +-
 arch/arm/include/asm/arch-omap4/sys_proto.h        |   60 +-
 .../omap4/lowlevel_init.S => include/asm/armv7.h}  |   32 +-
 arch/arm/include/asm/global_data.h                 |    5 +
 arch/arm/include/asm/omap_common.h                 |  106 ++
 board/ti/panda/panda.c                             |   25 +-
 board/ti/{sdp4430/sdp.h => panda/panda_mux_data.h} |   76 +-
 board/ti/sdp4430/config.mk                         |    3 +-
 board/ti/sdp4430/sdp.c                             |   25 +-
 .../{panda/panda.h => sdp4430/sdp4430_mux_data.h}  |  128 +--
 common/image.c                                     |    1 +
 include/configs/omap4_panda.h                      |   24 +
 include/configs/omap4_sdp4430.h                    |   24 +
 include/image.h                                    |    1 +
 spl/board/ti/panda/Makefile                        |  219 ++++
 spl/board/ti/sdp4430/Makefile                      |  219 ++++
 spl/board/ti/spl-omap.c                            |  189 +++
 .../armv7/u-boot.lds => spl/board/ti/spl-omap.lds  |   70 +-
 tools/Makefile                                     |    2 +
 tools/mkimage.c                                    |    2 +
 tools/mkimage.h                                    |    1 +
 tools/omapimage.c                                  |  229 ++++
 .../omap4/lowlevel_init.S => tools/omapimage.h     |   49 +-
 38 files changed, 5390 insertions(+), 320 deletions(-)
 copy arch/arm/cpu/armv7/{omap4/lowlevel_init.S => omap-common/utils.c} (50%)
 create mode 100644 arch/arm/cpu/armv7/omap4/clocks.c
 create mode 100644 arch/arm/cpu/armv7/omap4/emif.c
 create mode 100644 arch/arm/cpu/armv7/omap4/omap4_mux_data.h
 create mode 100644 arch/arm/cpu/armv7/omap4/sdram_elpida.c
 create mode 100644 arch/arm/include/asm/arch-omap4/clocks.h
 create mode 100644 arch/arm/include/asm/arch-omap4/emif.h
 copy arch/arm/{cpu/armv7/omap4/lowlevel_init.S => include/asm/armv7.h} (62%)
 create mode 100644 arch/arm/include/asm/omap_common.h
 rename board/ti/{sdp4430/sdp.h => panda/panda_mux_data.h} (76%)
 rename board/ti/{panda/panda.h => sdp4430/sdp4430_mux_data.h} (67%)
 create mode 100644 spl/board/ti/panda/Makefile
 create mode 100644 spl/board/ti/sdp4430/Makefile
 create mode 100644 spl/board/ti/spl-omap.c
 copy arch/arm/cpu/armv7/u-boot.lds => spl/board/ti/spl-omap.lds (57%)
 create mode 100644 tools/omapimage.c
 copy arch/arm/cpu/armv7/omap4/lowlevel_init.S => tools/omapimage.h (53%)
author
#1 lore raw

PATCH 1/22 mkimage: Add OMAP boot image support

From: John Rigby <[email protected]>

---
 common/image.c    |    1 +
 include/image.h   |    1 +
 tools/Makefile    |    2 +
 tools/mkimage.c   |    2 +
 tools/mkimage.h   |    1 +
 tools/omapimage.c |  229 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 tools/omapimage.h |   50 ++++++++++++
 7 files changed, 286 insertions(+), 0 deletions(-)
 create mode 100644 tools/omapimage.c
 create mode 100644 tools/omapimage.h
common/image.c +1 -0
index f63a2ff..4198d76 100644
@@ -141,6 +141,7 @@ static const table_entry_t uimage_type[] = {
 	{	IH_TYPE_FLATDT,     "flat_dt",    "Flat Device Tree",	},
 	{	IH_TYPE_KWBIMAGE,   "kwbimage",   "Kirkwood Boot Image",},
 	{	IH_TYPE_IMXIMAGE,   "imximage",   "Freescale i.MX Boot Image",},
+	{	IH_TYPE_OMAPIMAGE,  "omapimage",  "TI OMAP CH/GP Boot Image",},
 	{	-1,		    "",		  "",			},
 };
 
include/image.h +1 -0
index 005e0d2..f74e2b9 100644
@@ -157,6 +157,7 @@
 #define IH_TYPE_FLATDT		8	/* Binary Flat Device Tree Blob	*/
 #define IH_TYPE_KWBIMAGE	9	/* Kirkwood Boot Image		*/
 #define IH_TYPE_IMXIMAGE	10	/* Freescale IMXBoot Image	*/
+#define IH_TYPE_OMAPIMAGE	11	/* TI OMAP Config Header Image	*/
 
 /*
  * Compression Types
tools/Makefile +2 -0
index 623f908..a1c4ed7 100644
@@ -84,6 +84,7 @@ OBJ_FILES-$(CONFIG_CMD_LOADS) += img2srec.o
 OBJ_FILES-$(CONFIG_INCA_IP) += inca-swap-bytes.o
 NOPED_OBJ_FILES-y += kwbimage.o
 NOPED_OBJ_FILES-y += imximage.o
+NOPED_OBJ_FILES-y += omapimage.o
 NOPED_OBJ_FILES-y += mkimage.o
 OBJ_FILES-$(CONFIG_NETCONSOLE) += ncb.o
 NOPED_OBJ_FILES-y += os_support.o
@@ -180,6 +181,7 @@ $(obj)mkimage$(SFX):	$(obj)crc32.o \
 			$(obj)fit_image.o \
 			$(obj)image.o \
 			$(obj)imximage.o \
+			$(obj)omapimage.o \
 			$(obj)kwbimage.o \
 			$(obj)md5.o \
 			$(obj)mkimage.o \
tools/mkimage.c +2 -0
index f5859d7..ec6d75e 100644
@@ -155,6 +155,8 @@ main (int argc, char **argv)
 	init_imx_image_type ();
 	/* Init FIT image generation/list support */
 	init_fit_image_type ();
+	/* Init TI OMAP Boot image generation/list support */
+	init_omap_image_type();
 	/* Init Default image generation/list support */
 	init_default_image_type ();
 
tools/mkimage.h +1 -0
index 9033a7d..3b49645 100644
@@ -143,5 +143,6 @@ void init_kwb_image_type (void);
 void init_imx_image_type (void);
 void init_default_image_type (void);
 void init_fit_image_type (void);
+void init_omap_image_type(void);
 
 #endif /* _MKIIMAGE_H_ */
tools/omapimage.c new file +229 -0

229 lines not on this page · raw message

tools/omapimage.h new file +50 -0

50 lines not on this page · raw message

Signature · 1 line
1.7.0.4
#2 lore raw

PATCH 1/22 mkimage: Add OMAP boot image support

Aneesh,

Quoted 10 lines · Aneesh

From: John Rigby <[email protected]>

---
 common/image.c    |    1 +
 include/image.h   |    1 +
 tools/Makefile    |    2 +
 tools/mkimage.c   |    2 +
 tools/mkimage.h   |    1 +
 tools/omapimage.c |  229
Quoted 4 lines

+++++++++++++++++++++++++++++++++++++++++++++++++++++
tools/omapimage.h | 50 ++++++++++++ 7 files changed, 286
insertions(+), 0 deletions(-) create mode 100644 tools/omapimage.c create mode 100644 tools/omapimage.h

As pointed in the RFC[1] which was posted by John, we should separate out the configuration header part as that is optional. We should also consider renaming it to make it generic. What do you think?

Regards,
Vaibhav

[1] http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/91511/focus=91808

#3 lore raw

PATCH 1/22 mkimage: Add OMAP boot image support

Quoted 18 lines · Vaibhav

Aneesh,

Quoted 10 lines · Aneesh

From: John Rigby <[email protected]>

---

?common/image.c ? ?| ? ?1 +
?include/image.h ? | ? ?1 +
?tools/Makefile ? ?| ? ?2 +
?tools/mkimage.c ? | ? ?2 +
?tools/mkimage.h ? | ? ?1 +
?tools/omapimage.c | ?229
Quoted 4 lines

?+++++++++++++++++++++++++++++++++++++++++++++++++++++ ?tools/omapimage.h | ? 50 ++++++++++++ 7 files changed, 286 insertions(+), 0 deletions(-) ?create mode 100644 tools/omapimage.c ?create mode 100644 tools/omapimage.h

Quoted 4 lines

As pointed in the RFC[1] which was posted by John, we should separate out the configuration header part as that is optional. We should also consider renaming it to make it generic. What do you think?

Vaibhav,

If you submit a patch that does this I will gladly ack it.

John

author
#4 lore raw

PATCH 1/22 mkimage: Add OMAP boot image support

In reply to Bedia

Hi Vaibhav,

Quoted 18 lines · Vaibhav

Aneesh,

Quoted 10 lines · Aneesh

From: John Rigby<[email protected]>

---
  common/image.c    |    1 +
  include/image.h   |    1 +
  tools/Makefile    |    2 +
  tools/mkimage.c   |    2 +
  tools/mkimage.h   |    1 +
  tools/omapimage.c |  229
Quoted 4 lines

+++++++++++++++++++++++++++++++++++++++++++++++++++++
tools/omapimage.h | 50 ++++++++++++ 7 files changed, 286
insertions(+), 0 deletions(-) create mode 100644 tools/omapimage.c create mode 100644 tools/omapimage.h

Quoted 3 lines

As pointed in the RFC[1] which was posted by John, we should separate out the configuration header part as that is optional. We should also consider renaming it to make it generic. What do you think?

For OMAP4:
1. An 8 byte GP header is enough for booting from external MMC FAT partition
2. A dummy CH with a dummy CHSETTINGS is essential for booting from the RAW partition of eMMC or external MMC. This works for FAT booting too.
3. A full configuration with proper CHSETTINGS and CHRAM will help us in directly booting from SDRAM avoiding the SPL, but this is not supported on all revisions of OMAP3/4

IMHO, let's have one image type(what John has created now) for (1) and (2). It doesn't really harm to have 512 bytes of additional header attached to your image when it makes it suitable for different types of booting.

For 3, if that is supported in U-Boot in future, we will need a new image type, maybe something like omapchimage.

Let me know if you had any special considerations for your SoC.

Best regards,
Aneesh

#5 lore raw

PATCH 1/22 mkimage: Add OMAP boot image support

On Tuesday, March 01, 2011 8:20 PM, V, Aneesh wrote:
[...]

Quoted 15 lines

For OMAP4:
1. An 8 byte GP header is enough for booting from external MMC FAT partition
2. A dummy CH with a dummy CHSETTINGS is essential for booting from the RAW partition of eMMC or external MMC. This works for FAT booting too.
3. A full configuration with proper CHSETTINGS and CHRAM will help us in directly booting from SDRAM avoiding the SPL, but this is not supported on all revisions of OMAP3/4

IMHO, let's have one image type(what John has created now) for
(1) and (2). It doesn't really harm to have 512 bytes of additional header attached to your image when it makes it suitable for different types of booting.

Quoted 4 lines

For 3, if that is supported in U-Boot in future, we will need a new image type, maybe something like omapchimage.

Let me know if you had any special considerations for your SoC.

(My response on this yesterday bounced back for some reason)

I will try out this patch and see if the additional 512 bytes works for us also.

Regards,
Vaibhav

A message that is not in the archive (sent off-list or not yet received): [email protected]

#7 lore raw

PATCH 1/22 mkimage: Add OMAP boot image support

Aneesh,

Quoted 20 lines · Vaibhav
Quoted 19 lines · Aneesh

For OMAP4:
1. An 8 byte GP header is enough for booting from external
MMC FAT partition
2. A dummy CH with a dummy CHSETTINGS is essential for booting from the RAW partition of eMMC or external MMC. This
works for FAT booting too.
3. A full configuration with proper CHSETTINGS and CHRAM will help us in directly booting from SDRAM avoiding the SPL, but this is not supported on all revisions of OMAP3/4

IMHO, let's have one image type(what John has created now) for
(1) and (2). It doesn't really harm to have 512 bytes of additional header attached to your image when it makes it suitable for different types of booting.

For 3, if that is supported in U-Boot in future, we will need a new image type, maybe something like omapchimage.

Quoted 7 lines
Quoted 2 lines

Let me know if you had any special considerations for your SoC.

I will have to check if the additional 512 bytes will cause a problem for TI81XX GP devices. We haven't tried with the extra 512 bytes yet.

I checked the image with the additional 512bytes on TI81XX. It does not work.

If its fine with you I'll work on using a version flag for attaching the 512byte. How about something on the lines of what was done for imximage did recently?

Regards,
Vaibhav

author
#8 lore raw

PATCH 1/22 mkimage: Add OMAP boot image support

Hi Vaibhav,

Quoted 31 lines · Vaibhav

Aneesh,

Quoted 20 lines · Vaibhav
Quoted 19 lines · Aneesh

For OMAP4:
1. An 8 byte GP header is enough for booting from external
MMC FAT partition
2. A dummy CH with a dummy CHSETTINGS is essential for booting from the RAW partition of eMMC or external MMC. This
works for FAT booting too.
3. A full configuration with proper CHSETTINGS and CHRAM will help us in directly booting from SDRAM avoiding the SPL, but this is not supported on all revisions of OMAP3/4

IMHO, let's have one image type(what John has created now) for
(1) and (2). It doesn't really harm to have 512 bytes of additional header attached to your image when it makes it suitable for different types of booting.

For 3, if that is supported in U-Boot in future, we will need a new image type, maybe something like omapchimage.

Quoted 7 lines
Quoted 2 lines

Let me know if you had any special considerations for your SoC.

I will have to check if the additional 512 bytes will cause a problem for TI81XX GP devices. We haven't tried with the extra 512 bytes yet.

Quoted 4 lines

I checked the image with the additional 512bytes on TI81XX. It does not work.

If its fine with you I'll work on using a version flag for attaching the 512byte. How about something on the lines of what was done for imximage did recently?

I really don't know what this scheme is. But if it works it will be really great.

Best regards,
Aneesh

author
#9 lore raw

PATCH 2/22 omap: add miscellaneous utility macros for bit-field operations

In reply to Aneesh V
---
 arch/arm/include/asm/omap_common.h |   51 ++++++++++++++++++++++++++++++++++++
 1 files changed, 51 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/include/asm/omap_common.h
arch/arm/include/asm/omap_common.h new file +51 -0
new file mode 100644
index 0000000..03db2f5
@@ -0,0 +1,51 @@
+/*
+ * (C) Copyright 2010
+ * Texas Instruments, <www.ti.com>
+ *
+ * Aneesh V <[email protected]>
+ *
+ * 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	_OMAP_COMMON_H_
+#define	_OMAP_COMMON_H_
+
+/* extract a bit field from a bit vector */
+#define get_bit_field(nr, start, mask)\
+	(((nr) & (mask)) >> (start))
+
+/* Set a field in a bit vector */
+#define set_bit_field(nr, start, mask, val)\
+	do { \
+		(nr) = ((nr) & ~(mask)) | (((val) << (start)) & (mask));\
+	} while (0);
+
+/*
+ * Utility macro for read-modify-write of a hardware register
+ *	addr - address of the register
+ *	shift - starting bit position of the field to be modified
+ *	msk - mask for the field
+ *	val - value to be shifted masked and written to the field
+ */
+#define modify_reg_32(addr, shift, msk, val) \
+	do {\
+		writel(((readl(addr) & ~(msk))|(((val) << (shift)) & (msk))),\
+		       (addr));\
+	} while (0);
+
+#endif /* _OMAP_COMMON_H_ */
Signature · 1 line
1.7.0.4
author
#10 lore raw

PATCH 3/22 omap4: add OMAP4430 revision check

In reply to Aneesh V
---
 arch/arm/cpu/armv7/omap4/board.c        |   35 +++++++++++++++++++++++++++++++
 arch/arm/include/asm/arch-omap4/omap4.h |   17 +++++++++-----
 arch/arm/include/asm/armv7.h            |   31 +++++++++++++++++++++++++++
 3 files changed, 77 insertions(+), 6 deletions(-)
 create mode 100644 arch/arm/include/asm/armv7.h
arch/arm/cpu/armv7/omap4/board.c +35 -0
index fcd29a7..7583a0d 100644
@@ -28,6 +28,7 @@
  * MA 02111-1307 USA
  */
 #include <common.h>
+#include <asm/armv7.h>
 #include <asm/arch/cpu.h>
 #include <asm/arch/sys_proto.h>
 #include <asm/sizes.h>
@@ -127,3 +128,37 @@ int arch_cpu_init(void)
 	set_muxconf_regs();
 	return 0;
 }
+
+static u32 cortex_a9_rev(void)
+{
+
+	unsigned int rev;
+
+	/* Read Main ID Register (MIDR) */
+	asm ("mrc p15, 0, %0, c0, c0, 0" : "=r" (rev));
+
+	return rev;
+}
+
+u32 omap4_revision(void)
+{
+	if (readl(CONTROL_ID_CODE) == OMAP4_CONTROL_ID_CODE_ES2_1)
+		return OMAP4430_ES2_1;
+	else if (readl(CONTROL_ID_CODE) == OMAP4_CONTROL_ID_CODE_ES2_2)
+		return OMAP4430_ES2_2;
+	/*
+	 * For some of the ES2/ES1 boards ID_CODE is not reliable:
+	 * Also, ES1 and ES2 have different ARM revisions
+	 * So use ARM revision for identification
+	 */
+	unsigned int rev = cortex_a9_rev();
+
+	switch (rev) {
+	case MIDR_CORTEX_A9_R0P1:
+		return OMAP4430_ES1_0;
+	case MIDR_CORTEX_A9_R1P2:
+		return OMAP4430_ES2_0;
+	default:
+		return OMAP4430_SILICON_ID_INVALID;
+	}
+}
arch/arm/include/asm/arch-omap4/omap4.h +11 -6
index a30bb33..1f88732 100644
@@ -51,6 +51,11 @@
 #define CONTROL_PADCONF_CORE	(OMAP44XX_L4_CORE_BASE + 0x100000)
 #define CONTROL_PADCONF_WKUP	(OMAP44XX_L4_CORE_BASE + 0x31E000)
 
+/* CONTROL_ID_CODE */
+#define CONTROL_ID_CODE		(CTRL_BASE + 0x204)
+
+#define OMAP4_CONTROL_ID_CODE_ES2_1	0x3B95C02F
+#define OMAP4_CONTROL_ID_CODE_ES2_2	0x4B95C02F
 /* UART */
 #define UART1_BASE		(OMAP44XX_L4_PER_BASE + 0x6a000)
 #define UART2_BASE		(OMAP44XX_L4_PER_BASE + 0x6c000)
@@ -121,11 +126,11 @@ struct s32ktimer {
 /* Temporary SRAM stack used while low level init is done */
 #define LOW_LEVEL_SRAM_STACK	NON_SECURE_SRAM_END
 
-/*
- * OMAP4 real hardware:
- * TODO: Change this to the IDCODE in the hw regsiter
- */
-#define CPU_OMAP4430_ES10	1
-#define CPU_OMAP4430_ES20	2
+/* Silicon revisions */
+#define OMAP4430_SILICON_ID_INVALID	0
+#define OMAP4430_ES1_0	1
+#define OMAP4430_ES2_0	2
+#define OMAP4430_ES2_1	3
+#define OMAP4430_ES2_2	4
 
 #endif
arch/arm/include/asm/armv7.h new file +31 -0
new file mode 100644
index 0000000..6c24a80
@@ -0,0 +1,31 @@
+/*
+ * (C) Copyright 2010
+ * Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Aneesh V <[email protected]>
+ *
+ * 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 ARMV7_H
+#define ARMV7_H
+
+#define MIDR_CORTEX_A9_R0P1	0x410FC091
+#define MIDR_CORTEX_A9_R1P2	0x411FC092
+
+#endif /* ARMV7_H */
Signature · 1 line
1.7.0.4
author
#11 lore raw

PATCH 4/22 armv7: start.S: provide a hook for saving boot params

In reply to Aneesh V

Provide a means by which u-boot/SPL can save parameters passed to it by ROM code or the pre-loader.

A new function 'save_boot_params' has been defined and a default implentation provided. Please note that we do not have a stack yet. So, any implementation of this function should not use stack.

---
 arch/arm/cpu/armv7/cpu.c   |    7 +++++++
 arch/arm/cpu/armv7/start.S |    1 +
 2 files changed, 8 insertions(+), 0 deletions(-)
arch/arm/cpu/armv7/cpu.c +7 -0
index a01e0d6..54533fc 100644
@@ -41,6 +41,13 @@
 
 static void cache_flush(void);
 
+void save_boot_params_default(u32 r0, u32 r1, u32 r2, u32 r3)
+{
+}
+
+void save_boot_params(u32 r0, u32 r1, u32 r2, u32 r3)
+	__attribute__((weak, alias("save_boot_params_default")));
+
 int cleanup_before_linux(void)
 {
 	unsigned int i;
arch/arm/cpu/armv7/start.S +1 -0
index cb4f92f..3618190 100644
@@ -103,6 +103,7 @@ IRQ_STACK_START_IN:
  */
 
 reset:
+	bl	save_boot_params
 	/*
 	 * set the cpu to SVC32 mode
 	 */
Signature · 1 line
1.7.0.4
#12 lore raw

PATCH 4/22 armv7: start.S: provide a hook for saving boot params

Quoted 10 lines · Aneesh

Provide a means by which u-boot/SPL can save parameters passed to it by ROM code or the pre-loader.

A new function 'save_boot_params' has been defined and a default implentation provided. Please note that we do not have a stack yet. So, any implementation of this function should not use stack.

---

This is an essential feature when there no x-loader in the picture. Thanks for posting a patch for this :)

Regards,
Vaibhav

author
#13 lore raw

PATCH 5/22 omap4: save parameters passed by ROM code to SPL

In reply to Aneesh V

Save boot device information passed by OMAP4 rom code

ROM code in OMAP4 passes information such as the media from which it picked up the first boot image(SPL in our case), the mode(raw mode/FAT mode) etc.

Save this information in SPL so that we can use the same media and mode to bootload u-boot.

---
 arch/arm/cpu/armv7/omap4/board.c            |   14 ++++++++++++
 arch/arm/cpu/armv7/omap4/lowlevel_init.S    |   31 +++++++++++++++++++++++++++
 arch/arm/include/asm/arch-omap4/omap4.h     |    8 +++++++
 arch/arm/include/asm/arch-omap4/sys_proto.h |    1 +
 arch/arm/include/asm/omap_common.h          |   20 +++++++++++++++++
 5 files changed, 74 insertions(+), 0 deletions(-)
arch/arm/cpu/armv7/omap4/board.c +14 -0
index 7583a0d..a5d585b 100644
@@ -35,6 +35,20 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+#ifdef CONFIG_PRELOADER
+u32 omap4_boot_device = BOOT_DEVICE_MMC1;
+u32 omap4_boot_mode = MMCSD_MODE_FAT;
+u32 omap_boot_device(void)
+{
+	return omap4_boot_device;
+}
+
+u32 omap_boot_mode(void)
+{
+	return omap4_boot_mode;
+}
+#endif
+
 /*
  * Routine: s_init
  * Description: Does early system init of muxing and clocks.
arch/arm/cpu/armv7/omap4/lowlevel_init.S +31 -0
index 026dfa4..250c73d 100644
@@ -27,6 +27,37 @@
  */
 
 #include <asm/arch/omap4.h>
+#ifdef CONFIG_PRELOADER
+.global save_boot_params
+save_boot_params:
+	/*
+	 * See if the rom code passed pointer is valid:
+	 * It is not valid if it is not in non-secure SRAM
+	 * This may happen if you are booting with the help of
+	 * debugger
+	 */
+	ldr     r2, =NON_SECURE_SRAM_START
+	cmp	r2, r0
+	bgt	1f
+	ldr	r2, =NON_SECURE_SRAM_END
+	cmp	r2, r0
+	blt	1f
+
+	/* Store the boot device in omap4_boot_device */
+	ldr     r2, [r0, #BOOT_DEVICE_OFFSET]	@ r1 <- value of boot device
+	and	r2, #BOOT_DEVICE_MASK
+	ldr	r3, =omap4_boot_device
+	str     r2, [r3]			@ omap4_boot_device <- r1
+
+	/* Store the boot mode (raw/FAT) in omap4_boot_mode */
+	ldr	r2, [r0, #DEV_DESC_PTR_OFFSET]	@ get the device descriptor ptr
+	ldr	r2, [r2, #DEV_DATA_PTR_OFFSET]	@ get the pDeviceData ptr
+	ldr	r2, [r2, #BOOT_MODE_OFFSET]	@ get the boot mode
+	ldr	r3, =omap4_boot_mode
+	str	r2, [r3]
+1:
+	bx	lr
+#endif
 
 .globl lowlevel_init
 lowlevel_init:
arch/arm/include/asm/arch-omap4/omap4.h +8 -0
index 1f88732..740ca9d 100644
@@ -133,4 +133,12 @@ struct s32ktimer {
 #define OMAP4430_ES2_1	3
 #define OMAP4430_ES2_2	4
 
+/* ROM code defines */
+/* Boot device */
+#define BOOT_DEVICE_MASK	0xFF
+#define BOOT_DEVICE_OFFSET	0x8
+#define DEV_DESC_PTR_OFFSET	0x4
+#define DEV_DATA_PTR_OFFSET	0x18
+#define BOOT_MODE_OFFSET	0x8
+
 #endif
arch/arm/include/asm/arch-omap4/sys_proto.h +1 -0
index 4813e9e..ce86b36 100644
@@ -23,6 +23,7 @@
 
 #include <asm/arch/omap4.h>
 #include <asm/io.h>
+#include <asm/omap_common.h>
 
 struct omap_sysinfo {
 	char *board_string;
arch/arm/include/asm/omap_common.h +20 -0
index 03db2f5..06c511c 100644
@@ -48,4 +48,24 @@
 		       (addr));\
 	} while (0);
 
+/* Boot device */
+#define BOOT_DEVICE_NONE	0
+#define BOOT_DEVICE_XIP		1
+#define BOOT_DEVICE_XIPWAIT	2
+#define BOOT_DEVICE_NAND	3
+#define BOOT_DEVICE_ONE_NAND	4
+#define BOOT_DEVICE_MMC1	5
+#define BOOT_DEVICE_MMC2	6
+
+/* Boot type */
+#define	MMCSD_MODE_UNDEFINED	0
+#define MMCSD_MODE_RAW		1
+#define MMCSD_MODE_FAT		2
+
+/* Magic number passed from SPL to U-Boot */
+#define OMAP_SPL_TO_UBOOT_MAGIC_NUMBER	0xDEADBEEF
+
+u32 omap_boot_device(void);
+u32 omap_boot_mode(void);
+
 #endif /* _OMAP_COMMON_H_ */
Signature · 1 line
1.7.0.4
author
#14 lore raw

PATCH 6/22 arm: new labels in the linker script file

In reply to Aneesh V

_bss_start_ofs is used in start.S to indicate end of copied image. This may not be correct when we have a discontiguous memory map. For instance, .bss may be placed in SDRAM for some SPLS while rest of the image is placed in SRAM.

Define a new label in linker script to indicate the end of the image copied during relocation and use it appropriately in start.S.

Also, add a new label to indicate the end of flash image. This will be useful in identifying the size of flash image

---
 arch/arm/cpu/armv7/start.S    |    6 +++++-
 arch/arm/cpu/armv7/u-boot.lds |    4 ++++
 2 files changed, 9 insertions(+), 1 deletions(-)
arch/arm/cpu/armv7/start.S +5 -1
index 3618190..8215d26 100644
@@ -77,6 +77,10 @@ _TEXT_BASE:
 _bss_start_ofs:
 	.word __bss_start - _start
 
+.global	_image_copy_end_ofs
+_image_copy_end_ofs:
+	.word 	__image_copy_end - _start
+
 .globl _bss_end_ofs
 _bss_end_ofs:
 	.word _end - _start
@@ -172,7 +176,7 @@ stack_setup:
 	beq	clear_bss		/* skip relocation */
 #endif
 	mov	r1, r6			/* r1 <- scratch for copy_loop */
-	ldr	r3, _bss_start_ofs
+	ldr	r3, _image_copy_end_ofs
 	add	r2, r0, r3		/* r2 <- source end address	    */
 
 copy_loop:
arch/arm/cpu/armv7/u-boot.lds +4 -0
index 5725c30..c3ad587 100644
@@ -55,6 +55,8 @@ SECTIONS
 
 	. = ALIGN(4);
 
+	__image_copy_end = .;
+
 	.rel.dyn : {
 		__rel_dyn_start = .;
 		*(.rel*)
@@ -66,6 +68,8 @@ SECTIONS
 		*(.dynsym)
 	}
 
+	__flash_image_end = .;
+
 	.bss __rel_dyn_start (OVERLAY) : {
 		__bss_start = .;
 		*(.bss)
Signature · 1 line
1.7.0.4
#15 lore raw

PATCH 6/22 arm: new labels in the linker script file

Hi Aneesh,

Quoted 56 lines · Aneesh V

_bss_start_ofs is used in start.S to indicate end of copied image. This may not be correct when we have a discontiguous memory map. For instance, .bss may be placed in SDRAM for some SPLS while rest of the image is placed in SRAM.

Define a new label in linker script to indicate the end of the image copied during relocation and use it appropriately in start.S.

Also, add a new label to indicate the end of flash image. This will be useful in identifying the size of flash image

---
?arch/arm/cpu/armv7/start.S ? ?| ? ?6 +++++-
?arch/arm/cpu/armv7/u-boot.lds | ? ?4 ++++
?2 files changed, 9 insertions(+), 1 deletions(-)

arch/arm/cpu/armv7/start.S +0 -0
index 3618190..8215d26 100644
@@ -77,6 +77,10 @@ _TEXT_BASE:

?_bss_start_ofs:
? ? ? ?.word __bss_start - _start

+.global ? ? ? ?_image_copy_end_ofs

arch/arm/cpu/armv7/start.S +3 -0
+_image_copy_end_ofs:
+ ? ? ? .word ? __image_copy_end - _start
+

?.globl _bss_end_ofs
?_bss_end_ofs:
? ? ? ?.word _end - _start

arch/arm/cpu/armv7/start.S +0 -0
@@ -172,7 +176,7 @@ stack_setup:

? ? ? ?beq ? ? clear_bss ? ? ? ? ? ? ? /* skip relocation */ ?#endif
? ? ? ?mov ? ? r1, r6 ? ? ? ? ? ? ? ? ?/* r1 <- scratch for copy_loop */
- ? ? ? ldr ? ? r3, _bss_start_ofs
+ ? ? ? ldr ? ? r3, _image_copy_end_ofs
? ? ? ?add ? ? r2, r0, r3 ? ? ? ? ? ? ?/* r2 <- source end address ? ? ? ? */

?copy_loop:

arch/arm/cpu/armv7/u-boot.lds +2 -0
index 5725c30..c3ad587 100644
@@ -55,6 +55,8 @@ SECTIONS
 
 ? ? ? ?. = ALIGN(4);
 
+ ? ? ? __image_copy_end = .;
+
 ? ? ? ?.rel.dyn : {
 ? ? ? ? ? ? ? ?__rel_dyn_start = .;
 ? ? ? ? ? ? ? ?*(.rel*)

arch/arm/cpu/armv7/u-boot.lds SECTIONS · line 75

Quoted 8 lines
arch/arm/cpu/armv7/u-boot.lds +2 -0
@@ -66,6 +68,8 @@ SECTIONS
 ? ? ? ? ? ? ? ?*(.dynsym)
 ? ? ? ?}
 
+ ? ? ? __flash_image_end = .;
+
 ? ? ? ?.bss __rel_dyn_start (OVERLAY) : {
 ? ? ? ? ? ? ? ?__bss_start = .;
 ? ? ? ? ? ? ? ?*(.bss)

There is a patch series which makes _end as end of image and has been applied to arm branch.

[U-Boot] [PATCH 1/2 v2] rename _end to __bss_end__
http://lists.denx.de/pipermail/u-boot/2011-March/088166.html

[U-Boot] [PATCH 2/2 v2] arm: fix incorrect monitor protection region in FLASH
http://lists.denx.de/pipermail/u-boot/2011-March/088139.html

You can use the newly added symbol _end_ofs to replace your __flash_image_end here.

best regards,
Po-Yu Chuang

author
#16 lore raw

PATCH 6/22 arm: new labels in the linker script file

Quoted 2 lines · Po-Yu Chuang

Hi Aneesh,

[snip ..]

Quoted 9 lines

arch/arm/cpu/armv7/u-boot.lds SECTIONS · line 75

Quoted 5 lines
arch/arm/cpu/armv7/u-boot.lds +2 -0
+       __flash_image_end = .;
+
        .bss __rel_dyn_start (OVERLAY) : {
                __bss_start = .;
                *(.bss)

There is a patch series which makes _end as end of image and has been applied to arm branch.

Quoted 8 lines

[U-Boot] [PATCH 1/2 v2] rename _end to __bss_end__
http://lists.denx.de/pipermail/u-boot/2011-March/088166.html

[U-Boot] [PATCH 2/2 v2] arm: fix incorrect monitor protection region in FLASH
http://lists.denx.de/pipermail/u-boot/2011-March/088139.html

You can use the newly added symbol _end_ofs to replace your __flash_image_end here.

Thanks for the pointer. I will do that in v2.

best regards,
Aneesh

author
#17 lore raw

PATCH 7/22 Add generic spl infrastructure

In reply to Aneesh V

Define a new type of SPL that is not tied to any particular media.
- Create a top level directory 'spl' that has a structure similar to the existing 'nand_spl'
- Make necessary changes to top-level Makefile to build such an spl

Rationale for this approach:
- There may be SPLs(like the OMAP x-loader) that support booting from multiple media.
- Also, there is no harm in keeping SPLs specific to a particular media also under this directory. In fact it makes sense to merge all the different spl directories into this one.

---
 Makefile                           |   11 +++++++++++
 arch/arm/include/asm/global_data.h |    5 +++++
 2 files changed, 16 insertions(+), 0 deletions(-)
Makefile +11 -0
index dc2e3d8..21e51c8 100644
@@ -293,6 +293,11 @@ NAND_SPL = nand_spl
 U_BOOT_NAND = $(obj)u-boot-nand.bin
 endif
 
+ifeq ($(CONFIG_SPL),y)
+.PHONEY : SPL
+ALL += SPL
+endif
+
 ifeq ($(CONFIG_ONENAND_U_BOOT),y)
 ONENAND_IPL = onenand_ipl
 U_BOOT_ONENAND = $(obj)u-boot-onenand.bin
@@ -402,6 +407,9 @@ $(LDSCRIPT):	depend
 $(obj)u-boot.lds: $(LDSCRIPT)
 		$(CPP) $(CPPFLAGS) $(LDPPFLAGS) -ansi -D__ASSEMBLY__ -P - <$^ >$@
 
+SPL		:$(TIMESTAMP_FILE) $(VERSION_FILE) depend tools
+		$(MAKE) -C spl/board/$(BOARDDIR) all
+
 $(NAND_SPL):	$(TIMESTAMP_FILE) $(VERSION_FILE) depend
 		$(MAKE) -C nand_spl/board/$(BOARDDIR) all
 
@@ -1138,6 +1146,7 @@ clean:
 	@rm -f $(obj)include/bmp_logo.h
 	@rm -f $(obj)lib/asm-offsets.s
 	@rm -f $(obj)nand_spl/{u-boot.lds,u-boot-spl,u-boot-spl.map,System.map}
+	@rm -f $(obj)spl/{u-boot-spl-generated.lds,u-boot-spl,u-boot-spl.map}
 	@rm -f $(obj)onenand_ipl/onenand-{ipl,ipl.bin,ipl.map}
 	@rm -f $(ONENAND_BIN)
 	@rm -f $(obj)onenand_ipl/u-boot.lds
@@ -1157,12 +1166,14 @@ clobber:	clean
 	@rm -f $(obj)u-boot $(obj)u-boot.map $(obj)u-boot.hex $(ALL)
 	@rm -f $(obj)u-boot.kwb
 	@rm -f $(obj)u-boot.imx
+	@rm -f $(obj)MLO
 	@rm -f $(obj)tools/{env/crc32.c,inca-swap-bytes}
 	@rm -f $(obj)arch/powerpc/cpu/mpc824x/bedbug_603e.c
 	@rm -fr $(obj)include/asm/proc $(obj)include/asm/arch $(obj)include/asm
 	@rm -fr $(obj)include/generated
 	@[ ! -d $(obj)nand_spl ] || find $(obj)nand_spl -name "*" -type l -print | xargs rm -f
 	@[ ! -d $(obj)onenand_ipl ] || find $(obj)onenand_ipl -name "*" -type l -print | xargs rm -f
+	@[ ! -d $(obj)spl ] || find $(obj)spl -name "*" -type l -print | xargs rm -f
 
 ifeq ($(OBJTREE),$(SRCTREE))
 mrproper \
arch/arm/include/asm/global_data.h +5 -0
index 2a84d27..2ce020e 100644
@@ -89,6 +89,11 @@ typedef	struct	global_data {
 #define GD_FLG_DISABLE_CONSOLE	0x00040	/* Disable console (in & out)		*/
 #define GD_FLG_ENV_READY	0x00080	/* Environment imported into hash table	*/
 
+#ifdef CONFIG_PRELOADER
+/* SPL works from internal RAM. gd pointer can be in .data section */
+#define DECLARE_GLOBAL_DATA_PTR     extern gd_t *gd
+#else
 #define DECLARE_GLOBAL_DATA_PTR     register volatile gd_t *gd asm ("r8")
+#endif
 
 #endif /* __ASM_GBL_DATA_H */
Signature · 1 line
1.7.0.4
author
#18 lore raw

PATCH 8/22 armv7: start.S: add SPL support

In reply to Aneesh V

Changes for supporting SPL

---
 arch/arm/cpu/armv7/start.S |   36 +++++++++++++++++++++++++-----------
 1 files changed, 25 insertions(+), 11 deletions(-)
arch/arm/cpu/armv7/start.S +25 -11
index 8215d26..f5f08d9 100644
@@ -42,7 +42,16 @@ _start: b	reset
 	ldr	pc, _not_used
 	ldr	pc, _irq
 	ldr	pc, _fiq
-
+#ifdef CONFIG_PRELOADER
+_undefined_instruction: .word _undefined_instruction
+_software_interrupt:	.word _software_interrupt
+_prefetch_abort:	.word _prefetch_abort
+_data_abort:		.word _data_abort
+_not_used:		.word _not_used
+_irq:			.word _irq
+_fiq:			.word _fiq
+_pad:			.word 0x12345678 /* now 16*4=64 */
+#else
 _undefined_instruction: .word undefined_instruction
 _software_interrupt:	.word software_interrupt
 _prefetch_abort:	.word prefetch_abort
@@ -51,6 +60,8 @@ _not_used:		.word not_used
 _irq:			.word irq
 _fiq:			.word fiq
 _pad:			.word 0x12345678 /* now 16*4=64 */
+#endif	/* CONFIG_PRELOADER */
+
 .global _end_vect
 _end_vect:
 
@@ -171,10 +182,9 @@ stack_setup:
 	mov	sp, r4
 
 	adr	r0, _start
-#ifndef CONFIG_PRELOADER
 	cmp	r0, r6
+	moveq	r9, #0		/* no relocation. relocation offset(r9) = 0 */
 	beq	clear_bss		/* skip relocation */
-#endif
 	mov	r1, r6			/* r1 <- scratch for copy_loop */
 	ldr	r3, _image_copy_end_ofs
 	add	r2, r0, r3		/* r2 <- source end address	    */
@@ -224,6 +234,15 @@ fixnext:
 	add	r2, r2, #8		/* each rel.dyn entry is 8 bytes */
 	cmp	r2, r3
 	blo	fixloop
+	b	clear_bss
+_rel_dyn_start_ofs:
+	.word __rel_dyn_start - _start
+_rel_dyn_end_ofs:
+	.word __rel_dyn_end - _start
+_dynsym_start_ofs:
+	.word __dynsym_start - _start
+
+#endif	/* #ifndef CONFIG_PRELOADER */
 
 clear_bss:
 	ldr	r0, _bss_start_ofs
@@ -237,7 +256,6 @@ clbss_l:str	r2, [r0]		/* clear loop...		    */
 	add	r0, r0, #4
 	cmp	r0, r1
 	bne	clbss_l
-#endif	/* #ifndef CONFIG_PRELOADER */
 
 /*
  * We are done. Do not return, instead branch to second part of board
@@ -257,13 +275,6 @@ jump_2_ram:
 _board_init_r_ofs:
 	.word board_init_r - _start
 
-_rel_dyn_start_ofs:
-	.word __rel_dyn_start - _start
-_rel_dyn_end_ofs:
-	.word __rel_dyn_end - _start
-_dynsym_start_ofs:
-	.word __dynsym_start - _start
-
 /*************************************************************************
  *
  * CPU_init_critical registers
@@ -300,6 +311,8 @@ cpu_init_crit:
 	bl	lowlevel_init		@ go setup pll,mux,memory
 	mov	lr, ip			@ restore link
 	mov	pc, lr			@ back to my caller
+
+#ifndef CONFIG_PRELOADER
 /*
  *************************************************************************
  *
@@ -488,3 +501,4 @@ fiq:
 	bl	do_fiq
 
 #endif
+#endif /* CONFIG_PRELOADER */
Signature · 1 line
1.7.0.4
author
#19 lore raw

PATCH 9/22 omap: add spl support

In reply to Aneesh V

Add the basic spl framework and linker script common for OMAP3/4 platforms.

---
 spl/board/ti/spl-omap.c   |   47 ++++++++++++++++++++++++++++++++++
 spl/board/ti/spl-omap.lds |   62 +++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 109 insertions(+), 0 deletions(-)
 create mode 100644 spl/board/ti/spl-omap.c
 create mode 100644 spl/board/ti/spl-omap.lds
spl/board/ti/spl-omap.c new file +47 -0
new file mode 100644
index 0000000..0e08f4f
@@ -0,0 +1,47 @@
+/*
+ *
+ * Clock initialization for OMAP4
+ *
+ * (C) Copyright 2010
+ * Texas Instruments, <www.ti.com>
+ *
+ * Aneesh V <[email protected]>
+ *
+ * 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 <asm/u-boot.h>
+#include <asm/arch/sys_proto.h>
+#include <timestamp_autogenerated.h>
+
+/* Define global data structure pointer to it*/
+gd_t gdata __attribute__ ((section(".data")));
+bd_t bdata __attribute__ ((section(".data")));
+gd_t *gd = &gdata;
+
+void board_init_f(ulong dummy)
+{
+	relocate_code(CONFIG_SYS_SPL_STACK, &gdata, CONFIG_SYS_SPL_TEXT_BASE);
+}
+
+void board_init_r(gd_t *id, ulong dummy)
+{
+	for (;;)
+		;
+}
spl/board/ti/spl-omap.lds new file +62 -0

62 lines not on this page · raw message

Signature · 1 line
1.7.0.4
author
#20 lore raw

PATCH 10/22 omap4: add spl support for OMAP4 SDP

In reply to Aneesh V

Adapted from: nand_spl/board/samsung/smdk6400/Makefile

- Add the SPL makefile for OMAP4430 SDP
- Add the necessary CONFIG flags in the board config file

---
 board/ti/sdp4430/config.mk      |    3 +-
 include/configs/omap4_sdp4430.h |   19 ++++++
 spl/board/ti/sdp4430/Makefile   |  120 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 141 insertions(+), 1 deletions(-)
 create mode 100644 spl/board/ti/sdp4430/Makefile
board/ti/sdp4430/config.mk +2 -1
index 33901a7..c62965d 100644
@@ -28,4 +28,5 @@
 # Linux-Kernel is expected to be at 8000'8000, entry 8000'8000
 # (mem base + reserved)
 
-CONFIG_SYS_TEXT_BASE = 0x80e80000
+# 1MB into the SDRAM to allow for SPL's bss at the beginning of SDRAM
+CONFIG_SYS_TEXT_BASE = 0x80100000
include/configs/omap4_sdp4430.h +19 -0
index 9a8bb73..5b20841 100644
@@ -122,7 +122,9 @@
 
 /* USB device configuration */
 #define CONFIG_USB_DEVICE		1
+#ifndef CONFIG_PRELOADER
 #define CONFIG_USB_TTY			1
+#endif
 #define CONFIG_SYS_CONSOLE_IS_IN_ENV	1
 
 /* Flash */
@@ -240,4 +242,21 @@
 					 CONFIG_SYS_INIT_RAM_SIZE - \
 					 GENERATED_GBL_DATA_SIZE)
 
+/* Defines for Clock init */
+#define CONFIG_SYS_OMAP4_ABE_SYSCK
+
+/* Defines for SDRAM init */
+#define CONFIG_SYS_AUTOMATIC_SDRAM_DETECTION	1
+#define CONFIG_SYS_EMIF_UPDATE_TIMINGS		1
+#define CONFIG_SYS_DEFAULT_LPDDR2_TIMINGS	1
+
+/* Defines for SPL */
+#define CONFIG_SPL
+#define CONFIG_SYS_SPL_TEXT_BASE	0x40304360
+#define CONFIG_SYS_SPL_MAX_SIZE		0x7800	/* 30 K */
+#define CONFIG_SYS_SPL_STACK		LOW_LEVEL_SRAM_STACK
+
+#define CONFIG_SYS_SPL_BSS_START_ADDR	0x80000000
+#define CONFIG_SYS_SPL_BSS_MAX_SIZE	0x80000		/* 512 KB */
+
 #endif /* __CONFIG_H */
spl/board/ti/sdp4430/Makefile new file +120 -0

120 lines not on this page · raw message

Signature · 1 line
1.7.0.4
author
#21 lore raw

PATCH 11/22 omap4: add serial console support to SPL

In reply to Aneesh V
---
 arch/arm/cpu/armv7/omap4/board.c   |    3 ++
 arch/arm/include/asm/omap_common.h |    1 +
 spl/board/ti/sdp4430/Makefile      |   40 ++++++++++++++++++++++++++++++++++++
 spl/board/ti/spl-omap.c            |   10 +++++++++
 4 files changed, 54 insertions(+), 0 deletions(-)
arch/arm/cpu/armv7/omap4/board.c +3 -0
index a5d585b..da79669 100644
@@ -57,6 +57,9 @@ u32 omap_boot_mode(void)
 void s_init(void)
 {
 	watchdog_init();
+#ifdef CONFIG_PRELOADER
+	preloader_console_init();
+#endif
 }
 
 /*
arch/arm/include/asm/omap_common.h +1 -0
index 06c511c..95116f4 100644
@@ -67,5 +67,6 @@
 
 u32 omap_boot_device(void);
 u32 omap_boot_mode(void);
+void preloader_console_init(void);
 
 #endif /* _OMAP_COMMON_H_ */
spl/board/ti/sdp4430/Makefile +40 -0
index dd56a40..6a6aa42 100644
@@ -28,6 +28,46 @@ include $(TOPDIR)/config.mk
 SOBJS =
 COBJS =
 
+# serial console
+$(obj)eabi_compat.c:
+	@rm -f $@
+	@ln -s $(TOPDIR)/arch/arm/lib/eabi_compat.c $@
+
+$(obj)string.c:
+	@rm -f $@
+	@ln -s $(TOPDIR)/lib/string.c $@
+
+$(obj)vsprintf.c:
+	@rm -f $@
+	@ln -s $(TOPDIR)/lib/vsprintf.c $@
+
+$(obj)console.c:
+	@rm -f $@
+	@ln -s $(TOPDIR)/common/console.c $@
+
+$(obj)stdio.c:
+	@rm -f $@
+	@ln -s $(TOPDIR)/common/stdio.c $@
+
+$(obj)serial.c:
+	@rm -f $@
+	@ln -s $(TOPDIR)/drivers/serial/serial.c $@
+
+$(obj)ns16550.c:
+	@rm -f $@
+	@ln -s $(TOPDIR)/drivers/serial/ns16550.c $@
+
+$(obj)div64.c:
+	@rm -f $@
+	@ln -s $(TOPDIR)/lib/div64.c $@
+
+$(obj)ctype.c:
+	@rm -f $@
+	@ln -s $(TOPDIR)/lib/ctype.c $@
+
+COBJS	+= serial.o ns16550.o string.o vsprintf.o console.o stdio.o
+COBJS	+= ctype.o eabi_compat.o div64.o
+
 # armv7
 $(obj)start.S:
 	@rm -f $@
spl/board/ti/spl-omap.c +10 -0
index 0e08f4f..57ddb7d 100644
@@ -45,3 +45,13 @@ void board_init_r(gd_t *id, ulong dummy)
 	for (;;)
 		;
 }
+
+void preloader_console_init(void)
+{
+	gd->bd = &bdata;
+	gd->flags |= GD_FLG_RELOC;
+	gd->baudrate = CONFIG_BAUDRATE;
+	serial_init();		/* serial communications setup */
+	printf("\nU-Boot SPL for Texas Instruments OMAP4 (%s - %s)\n",
+		U_BOOT_DATE, U_BOOT_TIME);
+}
Signature · 1 line
1.7.0.4
author
#22 lore raw

PATCH 12/22 omap4: utility function to identify the context of hw init

In reply to Aneesh V

The basic hardware init of OMAP4(s_init()) can happen in 4 different contexts:
1. SPL running from SRAM
2. U-Boot running from FLASH
3. Non-XIP U-Boot loaded to SDRAM by SPL
4. Non-XIP U-Boot loaded to SDRAM by ROM code using the Configuration Header feature

What level of hw initialization gets done depends on this context. Add a utility function to find this context.

---
 arch/arm/include/asm/arch-omap4/sys_proto.h |   47 +++++++++++++++++++++++++++
 arch/arm/include/asm/omap_common.h          |    6 +++
 2 files changed, 53 insertions(+), 0 deletions(-)
arch/arm/include/asm/arch-omap4/sys_proto.h +47 -0
index ce86b36..19da2e1 100644
@@ -38,6 +38,53 @@ void sr32(void *, u32, u32, u32);
 u32 wait_on_value(u32, u32, void *, u32);
 void sdelay(unsigned long);
 
+static inline u32 running_from_sdram(void)
+{
+	u32 pc;
+	asm volatile ("mov %0, pc" : "=r" (pc));
+	return ((pc >= OMAP44XX_DRAM_ADDR_SPACE_START) &&
+	    (pc < OMAP44XX_DRAM_ADDR_SPACE_END));
+}
+
+static inline u8 uboot_loaded_by_spl(void)
+{
+	/*
+	 * Configuration Header is not supported yet, so u-boot init running
+	 * from SDRAM implies that it was loaded by SPL. When this situation
+	 * changes one of these approaches could be taken:
+	 * i.  Pass a magic from SPL to U-Boot and U-Boot save it at a known
+	 *     location.
+	 * ii. Check the OPP. CH can support only 50% OPP while SPL initializes
+	 *     the DPLLs@100% OPP.
+	 */
+	return running_from_sdram();
+}
+/*
+ * The basic hardware init of OMAP(s_init()) can happen in 4
+ * different contexts:
+ *  1. SPL running from SRAM
+ *  2. U-Boot running from FLASH
+ *  3. Non-XIP U-Boot loaded to SDRAM by SPL
+ *  4. Non-XIP U-Boot loaded to SDRAM by ROM code using the
+ *     Configuration Header feature
+ *
+ * This function finds this context.
+ * Defining as inline may help in compiling out unused functions in SPL
+ */
+static inline u32 omap4_hw_init_context(void)
+{
+#ifdef CONFIG_PRELOADER
+	return OMAP_INIT_CONTEXT_SPL;
+#else
+	if (uboot_loaded_by_spl())
+		return OMAP_INIT_CONTEXT_UBOOT_LOADED_BY_SPL;
+	else if (running_from_sdram())
+		return OMAP_INIT_CONTEXT_UBOOT_LOADED_BY_CH;
+	else
+		return OMAP_INIT_CONTEXT_XIP_UBOOT;
+#endif
+}
+
 extern const struct omap_sysinfo sysinfo;
 
 #endif
arch/arm/include/asm/omap_common.h +6 -0
index 95116f4..50247af 100644
@@ -65,6 +65,12 @@
 /* Magic number passed from SPL to U-Boot */
 #define OMAP_SPL_TO_UBOOT_MAGIC_NUMBER	0xDEADBEEF
 
+/* HW Init Context */
+#define OMAP_INIT_CONTEXT_SPL			0
+#define OMAP_INIT_CONTEXT_XIP_UBOOT		1
+#define OMAP_INIT_CONTEXT_UBOOT_LOADED_BY_SPL	2
+#define OMAP_INIT_CONTEXT_UBOOT_LOADED_BY_CH	3
+
 u32 omap_boot_device(void);
 u32 omap_boot_mode(void);
 void preloader_console_init(void);
Signature · 1 line
1.7.0.4
author
#23 lore raw

PATCH 13/22 omap4: separate mux settings into essential and non essential parts

In reply to Aneesh V

Do the essential part from SPL and non-essential part from U-Boot
- Essential part is what is essential for u-boot to function
- Essential part is also largely board independent(at least as of now)
- So essential part is moved out to SoC directory instead of keeping in board directory. This helps in having single SPL that works for Panda and SDP.
- Non-essential part is what is set by u-boot for kernel to function correctly
- Ideally non-essential part should be phased out eventually

---
 arch/arm/cpu/armv7/omap4/board.c               |   53 ++++++++++++++++-
 arch/arm/cpu/armv7/omap4/omap4_mux_data.h      |   76 ++++++++++++++++++++++++
 arch/arm/include/asm/arch-omap4/sys_proto.h    |    4 +-
 board/ti/panda/panda.c                         |   25 ++------
 board/ti/panda/{panda.h => panda_mux_data.h}   |   45 ++------------
 board/ti/sdp4430/sdp.c                         |   25 ++------
 board/ti/sdp4430/{sdp.h => sdp4430_mux_data.h} |   47 ++-------------
 7 files changed, 151 insertions(+), 124 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/omap4/omap4_mux_data.h
 rename board/ti/panda/{panda.h => panda_mux_data.h} (83%)
 rename board/ti/sdp4430/{sdp.h => sdp4430_mux_data.h} (83%)
arch/arm/cpu/armv7/omap4/board.c +50 -3
index da79669..95b6a96 100644
@@ -32,9 +32,30 @@
 #include <asm/arch/cpu.h>
 #include <asm/arch/sys_proto.h>
 #include <asm/sizes.h>
+#include "omap4_mux_data.h"
 
 DECLARE_GLOBAL_DATA_PTR;
 
+void do_set_mux(u32 base, struct pad_conf_entry const *array, int size)
+{
+	int i;
+	struct pad_conf_entry *pad = (struct pad_conf_entry *) array;
+
+	for (i = 0; i < size; i++, pad++)
+		writew(pad->val, base + pad->offset);
+}
+
+static 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));
+}
+
 #ifdef CONFIG_PRELOADER
 u32 omap4_boot_device = BOOT_DEVICE_MMC1;
 u32 omap4_boot_mode = MMCSD_MODE_FAT;
@@ -49,14 +70,41 @@ u32 omap_boot_mode(void)
 }
 #endif
 
+static void set_mux_conf_regs(void)
+{
+	switch (omap4_hw_init_context()) {
+	case OMAP_INIT_CONTEXT_SPL:
+		set_muxconf_regs_essential();
+		break;
+	case OMAP_INIT_CONTEXT_UBOOT_LOADED_BY_SPL:
+		set_muxconf_regs_non_essential();
+		break;
+	case OMAP_INIT_CONTEXT_XIP_UBOOT:
+	case OMAP_INIT_CONTEXT_UBOOT_LOADED_BY_CH:
+		set_muxconf_regs_essential();
+		set_muxconf_regs_non_essential();
+		break;
+	}
+}
+
 /*
  * Routine: s_init
- * Description: Does early system init of muxing and clocks.
- *              - Called path is with SRAM stack.
+ * Description: Does early system init of watchdog, muxing, clocks, and
+ * sdram. Watchdog disable is done always. For the rest what gets done
+ * depends on the boot mode in which this function is executed
+ *   1. s_init of SPL running from SRAM
+ *   2. s_init of U-Boot running from FLASH
+ *   3. s_init of U-Boot loaded to SDRAM by SPL
+ *   4. s_init of U-Boot loaded to SDRAM by ROM code using the Configuration
+ *	Header feature
+ * Please have a look at the respective functions to see what gets done in
+ * each of these cases
+ * This function is called with SRAM stack.
  */
 void s_init(void)
 {
 	watchdog_init();
+	set_mux_conf_regs();
 #ifdef CONFIG_PRELOADER
 	preloader_console_init();
 #endif
@@ -142,7 +190,6 @@ int checkboard(void)
 */
 int arch_cpu_init(void)
 {
-	set_muxconf_regs();
 	return 0;
 }
 
arch/arm/cpu/armv7/omap4/omap4_mux_data.h new file +76 -0

76 lines not on this page · raw message

arch/arm/include/asm/arch-omap4/sys_proto.h +3 -1
index 19da2e1..33a1666 100644
@@ -24,6 +24,7 @@
 #include <asm/arch/omap4.h>
 #include <asm/io.h>
 #include <asm/omap_common.h>
+#include <asm/arch/mux_omap4.h>
 
 struct omap_sysinfo {
 	char *board_string;
@@ -33,7 +34,8 @@ void gpmc_init(void);
 void watchdog_init(void);
 u32 get_device_type(void);
 void invalidate_dcache(u32);
-void set_muxconf_regs(void);
+void do_set_mux(u32 base, struct pad_conf_entry const *array, int size);
+void set_muxconf_regs_non_essential(void);
 void sr32(void *, u32, u32, u32);
 u32 wait_on_value(u32, u32, void *, u32);
 void sdelay(unsigned long);
board/ti/panda/panda.c +6 -19
index 78e1910..9afed80 100644
@@ -25,7 +25,7 @@
 #include <asm/arch/sys_proto.h>
 #include <asm/arch/mmc_host_def.h>
 
-#include "panda.h"
+#include "panda_mux_data.h"
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -65,27 +65,14 @@ int misc_init_r(void)
 	return 0;
 }
 
-void do_set_mux(u32 base, struct pad_conf_entry const *array, int size)
+void set_muxconf_regs_non_essential(void)
 {
-	int i;
-	struct pad_conf_entry *pad = (struct pad_conf_entry *) array;
-
-	for (i = 0; i < size; i++, pad++)
-		writew(pad->val, base + pad->offset);
-}
-
-/**
- * @brief set_muxconf_regs Setting up the configuration Mux registers
- * specific to the board.
- */
-void set_muxconf_regs(void)
-{
-	do_set_mux(CONTROL_PADCONF_CORE, core_padconf_array,
-		   sizeof(core_padconf_array) /
+	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,
-		   sizeof(wkup_padconf_array) /
+	do_set_mux(CONTROL_PADCONF_WKUP, wkup_padconf_array_non_essential,
+		   sizeof(wkup_padconf_array_non_essential) /
 		   sizeof(struct pad_conf_entry));
 }
 
board/ti/panda/panda_mux_data.h renamed from board/ti/panda/panda.h +5 -40

99 lines not on this page · raw message

board/ti/sdp4430/sdp.c +6 -19
index b13c4c5..a5ea682 100644
@@ -27,7 +27,7 @@
 #include <asm/arch/sys_proto.h>
 #include <asm/arch/mmc_host_def.h>
 
-#include "sdp.h"
+#include "sdp4430_mux_data.h"
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -70,27 +70,14 @@ int misc_init_r(void)
 	return 0;
 }
 
-void do_set_mux(u32 base, struct pad_conf_entry const *array, int size)
+void set_muxconf_regs_non_essential(void)
 {
-	int i;
-	struct pad_conf_entry *pad = (struct pad_conf_entry *) array;
-
-	for (i = 0; i < size; i++, pad++)
-		writew(pad->val, base + pad->offset);
-}
-
-/**
- * @brief set_muxconf_regs Setting up the configuration Mux registers
- * specific to the board.
- */
-void set_muxconf_regs(void)
-{
-	do_set_mux(CONTROL_PADCONF_CORE, core_padconf_array,
-		   sizeof(core_padconf_array) /
+	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,
-		   sizeof(wkup_padconf_array) /
+	do_set_mux(CONTROL_PADCONF_WKUP, wkup_padconf_array_non_essential,
+		   sizeof(wkup_padconf_array_non_essential) /
 		   sizeof(struct pad_conf_entry));
 }
 
board/ti/sdp4430/sdp4430_mux_data.h renamed from board/ti/sdp4430/sdp.h +5 -42

100 lines not on this page · raw message

Signature · 1 line
1.7.0.4
author
#24 lore raw

PATCH 14/22 omap4: correct mux data for sdp4430

In reply to Aneesh V

sync up mux settings with the latest in x-loader

---
 board/ti/panda/panda_mux_data.h     |   89 ++++++++++++++++++-----------------
 board/ti/sdp4430/sdp4430_mux_data.h |   29 ++++++-----
 2 files changed, 61 insertions(+), 57 deletions(-)
board/ti/panda/panda_mux_data.h +45 -44
index 8bb7fe5..16cc0ad 100644
@@ -23,11 +23,9 @@
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
  * MA 02111-1307 USA
  */
+#ifndef _SDP4430_MUX_DATA_H
+#define _SDP4430_MUX_DATA_H
 
-#ifndef _PANDA_MUX_DATA_H_
-#define _PANDA_MUX_DATA_H_
-
-#include <asm/io.h>
 #include <asm/arch/mux_omap4.h>
 
 const struct pad_conf_entry core_padconf_array_non_essential[] = {
@@ -45,7 +43,7 @@ const struct pad_conf_entry core_padconf_array_non_essential[] = {
 	{GPMC_A19, (PTU | IEN | OFF_EN | OFF_PD | OFF_IN | M1)},	/* kpd_row7 */
 	{GPMC_A20, (IEN | M3)},						/* gpio_44 */
 	{GPMC_A21, (M3)},						/* gpio_45 */
-	{GPMC_A22, (M3)},						/* gpio_46 */
+	{GPMC_A22, (OFF_EN | OFF_PD | OFF_IN | M1)},			/* kpd_col6 */
 	{GPMC_A23, (OFF_EN | OFF_PD | OFF_IN | M1)},			/* kpd_col7 */
 	{GPMC_A24, (PTD | M3)},						/* gpio_48 */
 	{GPMC_A25, (PTD | M3)},						/* gpio_49 */
@@ -59,9 +57,9 @@ const struct pad_conf_entry core_padconf_array_non_essential[] = {
 	{GPMC_NBE0_CLE, (M3)},						/* gpio_59 */
 	{GPMC_NBE1, (PTD | M3)},					/* gpio_60 */
 	{GPMC_WAIT0, (PTU | IEN | M3)},					/* gpio_61 */
-	{GPMC_WAIT1,  (PTD | OFF_EN | OFF_PD | OFF_OUT_PTD | M3)},	/* gpio_62 */
+	{GPMC_WAIT1, (IEN | M3)},					/* gpio_62 */
 	{C2C_DATA11, (PTD | M3)},					/* gpio_100 */
-	{C2C_DATA12, (PTU | IEN | M3)},					/* gpio_101 */
+	{C2C_DATA12, (M1)},						/* dsi1_te0 */
 	{C2C_DATA13, (PTD | M3)},					/* gpio_102 */
 	{C2C_DATA14, (M1)},						/* dsi2_te0 */
 	{C2C_DATA15, (PTD | M3)},					/* gpio_104 */
@@ -86,14 +84,14 @@ const struct pad_conf_entry core_padconf_array_non_essential[] = {
 	{CAM_SHUTTER, (OFF_EN | OFF_PD | OFF_OUT_PTD | M0)},		/* cam_shutter */
 	{CAM_STROBE, (OFF_EN | OFF_PD | OFF_OUT_PTD | M0)},		/* cam_strobe */
 	{CAM_GLOBALRESET, (PTD | OFF_EN | OFF_PD | OFF_OUT_PTD | M3)},	/* gpio_83 */
-	{USBB1_ULPITLL_CLK, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M4)},/* usbb1_ulpiphy_clk */
-	{USBB1_ULPITLL_STP, (OFF_EN | OFF_OUT_PTD | M4)},		/* usbb1_ulpiphy_stp */
-	{USBB1_ULPITLL_DIR, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},	/* usbb1_ulpiphy_dir */
-	{USBB1_ULPITLL_NXT, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},	/* usbb1_ulpiphy_nxt */
-	{USBB1_ULPITLL_DAT0, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},	/* usbb1_ulpiphy_dat0 */
-	{USBB1_ULPITLL_DAT1, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},	/* usbb1_ulpiphy_dat1 */
-	{USBB1_ULPITLL_DAT2, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},	/* usbb1_ulpiphy_dat2 */
-	{USBB1_ULPITLL_DAT3, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},	/* usbb1_ulpiphy_dat3 */
+	{USBB1_ULPITLL_CLK, (IEN | OFF_EN | OFF_IN | M1)},		/* hsi1_cawake */
+	{USBB1_ULPITLL_STP, (IEN | OFF_EN | OFF_IN | M1)},		/* hsi1_cadata */
+	{USBB1_ULPITLL_DIR, (IEN | OFF_EN | OFF_IN | M1)},		/* hsi1_caflag */
+	{USBB1_ULPITLL_NXT, (OFF_EN | M1)},				/* hsi1_acready */
+	{USBB1_ULPITLL_DAT0, (OFF_EN | M1)},				/* hsi1_acwake */
+	{USBB1_ULPITLL_DAT1, (OFF_EN | M1)},				/* hsi1_acdata */
+	{USBB1_ULPITLL_DAT2, (OFF_EN | M1)},				/* hsi1_acflag */
+	{USBB1_ULPITLL_DAT3, (IEN | OFF_EN | OFF_IN | M1)},		/* hsi1_caready */
 	{USBB1_ULPITLL_DAT4, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},	/* usbb1_ulpiphy_dat4 */
 	{USBB1_ULPITLL_DAT5, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},	/* usbb1_ulpiphy_dat5 */
 	{USBB1_ULPITLL_DAT6, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},	/* usbb1_ulpiphy_dat6 */
@@ -106,8 +104,8 @@ const struct pad_conf_entry core_padconf_array_non_essential[] = {
 	{ABE_MCBSP2_DR, (IEN | OFF_EN | OFF_OUT_PTD | M0)},		/* abe_mcbsp2_dr */
 	{ABE_MCBSP2_DX, (OFF_EN | OFF_OUT_PTD | M0)},			/* abe_mcbsp2_dx */
 	{ABE_MCBSP2_FSX, (IEN | OFF_EN | OFF_PD | OFF_IN | M0)},	/* abe_mcbsp2_fsx */
-	{ABE_MCBSP1_CLKX, (IEN | M1)},					/* abe_slimbus1_clock */
-	{ABE_MCBSP1_DR, (IEN | M1)},					/* abe_slimbus1_data */
+	{ABE_MCBSP1_CLKX, (IEN | OFF_EN | OFF_PD | OFF_IN | M0)},	/* abe_mcbsp1_clkx */
+	{ABE_MCBSP1_DR, (IEN | OFF_EN | OFF_OUT_PTD | M0)},		/* abe_mcbsp1_dr */
 	{ABE_MCBSP1_DX, (OFF_EN | OFF_OUT_PTD | M0)},			/* abe_mcbsp1_dx */
 	{ABE_MCBSP1_FSX, (IEN | OFF_EN | OFF_PD | OFF_IN | M0)},	/* abe_mcbsp1_fsx */
 	{ABE_PDM_UL_DATA, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M0)},	/* abe_pdm_ul_data */
@@ -143,7 +141,7 @@ const struct pad_conf_entry core_padconf_array_non_essential[] = {
 	{MCSPI4_CS0, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M0)},	/* mcspi4_cs0 */
 	{UART4_RX, (IEN | M0)},						/* uart4_rx */
 	{UART4_TX, (M0)},						/* uart4_tx */
-	{USBB2_ULPITLL_CLK, (IEN | M3)},				/* gpio_157 */
+	{USBB2_ULPITLL_CLK, (PTD | IEN | M3)},				/* gpio_157 */
 	{USBB2_ULPITLL_STP, (IEN | M5)},				/* dispc2_data23 */
 	{USBB2_ULPITLL_DIR, (IEN | M5)},				/* dispc2_data22 */
 	{USBB2_ULPITLL_NXT, (IEN | M5)},				/* dispc2_data21 */
@@ -157,12 +155,12 @@ const struct pad_conf_entry core_padconf_array_non_essential[] = {
 	{USBB2_ULPITLL_DAT7, (IEN | M5)},				/* dispc2_data11 */
 	{USBB2_HSIC_DATA, (PTD | OFF_EN | OFF_OUT_PTU | M3)},		/* gpio_169 */
 	{USBB2_HSIC_STROBE, (PTD | OFF_EN | OFF_OUT_PTU | M3)},		/* gpio_170 */
-	{UNIPRO_TX0, (PTD | IEN | M3)},					/* gpio_171 */
+	{UNIPRO_TX0, (OFF_EN | OFF_PD | OFF_IN | M1)},			/* kpd_col0 */
 	{UNIPRO_TY0, (OFF_EN | OFF_PD | OFF_IN | M1)},			/* kpd_col1 */
 	{UNIPRO_TX1, (OFF_EN | OFF_PD | OFF_IN | M1)},			/* kpd_col2 */
 	{UNIPRO_TY1, (OFF_EN | OFF_PD | OFF_IN | M1)},			/* kpd_col3 */
-	{UNIPRO_TX2, (PTU | IEN | M3)},					/* gpio_0 */
-	{UNIPRO_TY2, (PTU | IEN | M3)},					/* gpio_1 */
+	{UNIPRO_TX2, (OFF_EN | OFF_PD | OFF_IN | M1)},			/* kpd_col4 */
+	{UNIPRO_TY2, (OFF_EN | OFF_PD | OFF_IN | M1)},			/* kpd_col5 */
 	{UNIPRO_RX0, (PTU | IEN | OFF_EN | OFF_PD | OFF_IN | M1)},	/* kpd_row0 */
 	{UNIPRO_RY0, (PTU | IEN | OFF_EN | OFF_PD | OFF_IN | M1)},	/* kpd_row1 */
 	{UNIPRO_RX1, (PTU | IEN | OFF_EN | OFF_PD | OFF_IN | M1)},	/* kpd_row2 */
@@ -173,13 +171,13 @@ const struct pad_conf_entry core_padconf_array_non_essential[] = {
 	{USBA0_OTG_DP, (IEN | OFF_EN | OFF_PD | OFF_IN | M0)},		/* usba0_otg_dp */
 	{USBA0_OTG_DM, (IEN | OFF_EN | OFF_PD | OFF_IN | M0)},		/* usba0_otg_dm */
 	{FREF_CLK1_OUT, (M0)},						/* fref_clk1_out */
-	{FREF_CLK2_OUT, (PTU | IEN | M3)},				/* gpio_182 */
+	{FREF_CLK2_OUT, (M0)},						/* fref_clk2_out */
 	{SYS_NIRQ1, (PTU | IEN | M0)},					/* sys_nirq1 */
-	{SYS_NIRQ2, (PTU | IEN | M0)},					/* sys_nirq2 */
+	{SYS_NIRQ2, (M7)},						/* sys_nirq2 */
 	{SYS_BOOT0, (PTU | IEN | M3)},					/* gpio_184 */
 	{SYS_BOOT1, (M3)},						/* gpio_185 */
 	{SYS_BOOT2, (PTD | IEN | M3)},					/* gpio_186 */
-	{SYS_BOOT3, (M3)},						/* gpio_187 */
+	{SYS_BOOT3, (PTD | IEN | M3)},					/* gpio_187 */
 	{SYS_BOOT4, (M3)},						/* gpio_188 */
 	{SYS_BOOT5, (PTD | IEN | M3)},					/* gpio_189 */
 	{DPM_EMU0, (IEN | M0)},						/* dpm_emu0 */
@@ -205,25 +203,28 @@ const struct pad_conf_entry core_padconf_array_non_essential[] = {
 };
 
 const struct pad_conf_entry wkup_padconf_array_non_essential[] = {
-	{PAD0_SIM_IO, (IEN | M0)},					/* sim_io */
-	{PAD1_SIM_CLK, (M0)},						/* sim_clk */
-	{PAD0_SIM_RESET, (M0)},						/* sim_reset */
-	{PAD1_SIM_CD, (PTU | IEN | M0)},				/* sim_cd */
-	{PAD0_SIM_PWRCTRL, (M0)},					/* sim_pwrctrl */
-	{PAD1_FREF_XTAL_IN, (M0)},					/* # */
-	{PAD0_FREF_SLICER_IN, (M0)},					/* fref_slicer_in */
-	{PAD1_FREF_CLK_IOREQ, (M0)},					/* fref_clk_ioreq */
-	{PAD0_FREF_CLK0_OUT, (M2)},					/* sys_drm_msecure */
-	{PAD1_FREF_CLK3_REQ, (M3)},					/* gpio_wk30 */
-	{PAD0_FREF_CLK3_OUT, (M0)},					/* fref_clk3_out */
-	{PAD1_FREF_CLK4_REQ, (PTU | OFF_EN | OFF_OUT_PTU | M3)},	/* led status_1 */
-	{PAD0_FREF_CLK4_OUT, (PTU | OFF_EN | OFF_OUT_PTU | M3)},	/* led status_2 */
-	{PAD0_SYS_NRESPWRON, (M0)},					/* sys_nrespwron */
-	{PAD1_SYS_NRESWARM, (M0)},					/* sys_nreswarm */
-	{PAD0_SYS_PWR_REQ, (PTU | M0)},					/* sys_pwr_req */
-	{PAD1_SYS_PWRON_RESET, (M3)},					/* gpio_wk29 */
-	{PAD0_SYS_BOOT6, (IEN | M3)},					/* gpio_wk9 */
-	{PAD1_SYS_BOOT7, (IEN | M3)},					/* gpio_wk10 */
+	{PAD0_SIM_IO, (IEN | M0)},		/* sim_io */
+	{PAD1_SIM_CLK, (M0)},			/* sim_clk */
+	{PAD0_SIM_RESET, (M0)},			/* sim_reset */
+	{PAD1_SIM_CD, (PTU | IEN | M0)},	/* sim_cd */
+	{PAD0_SIM_PWRCTRL, (M0)},		/* sim_pwrctrl */
+	{PAD1_FREF_XTAL_IN, (M0)},		/* # */
+	{PAD0_FREF_SLICER_IN, (M0)},		/* fref_slicer_in */
+	{PAD1_FREF_CLK_IOREQ, (M0)},		/* fref_clk_ioreq */
+	{PAD0_FREF_CLK0_OUT, (M2)},		/* sys_drm_msecure */
+	{PAD1_FREF_CLK3_REQ, (PTU | IEN | M0)},	/* # */
+	{PAD0_FREF_CLK3_OUT, (M0)},		/* fref_clk3_out */
+	{PAD1_FREF_CLK4_REQ, (PTU | IEN | M0)},	/* # */
+	{PAD0_FREF_CLK4_OUT, (M0)},		/* # */
+	{PAD0_SYS_NRESPWRON, (M0)},		/* sys_nrespwron */
+	{PAD1_SYS_NRESWARM, (M0)},		/* sys_nreswarm */
+	{PAD0_SYS_PWR_REQ, (PTU | M0)},		/* sys_pwr_req */
+	{PAD1_SYS_PWRON_RESET, (M3)},		/* gpio_wk29 */
+	{PAD0_SYS_BOOT6, (IEN | M3)},		/* gpio_wk9 */
+	{PAD1_SYS_BOOT7, (IEN | M3)},		/* gpio_wk10 */
+	{PAD1_FREF_CLK3_REQ, (M3)},		/* gpio_wk30 */
+	{PAD1_FREF_CLK4_REQ, (M3)},		/* gpio_wk7 */
+	{PAD0_FREF_CLK4_OUT, (M3)},		/* gpio_wk8 */
 };
 
-#endif /* _PANDA_MUX_DATA_H_ */
+#endif /* _SDP4430_MUX_DATA_H */
board/ti/sdp4430/sdp4430_mux_data.h +16 -13
index e6081dc..16cc0ad 100644
@@ -84,14 +84,14 @@ const struct pad_conf_entry core_padconf_array_non_essential[] = {
 	{CAM_SHUTTER, (OFF_EN | OFF_PD | OFF_OUT_PTD | M0)},		/* cam_shutter */
 	{CAM_STROBE, (OFF_EN | OFF_PD | OFF_OUT_PTD | M0)},		/* cam_strobe */
 	{CAM_GLOBALRESET, (PTD | OFF_EN | OFF_PD | OFF_OUT_PTD | M3)},	/* gpio_83 */
-	{USBB1_ULPITLL_CLK, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M4)},/* usbb1_ulpiphy_clk */
-	{USBB1_ULPITLL_STP, (OFF_EN | OFF_OUT_PTD | M4)},		/* usbb1_ulpiphy_stp */
-	{USBB1_ULPITLL_DIR, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},	/* usbb1_ulpiphy_dir */
-	{USBB1_ULPITLL_NXT, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},	/* usbb1_ulpiphy_nxt */
-	{USBB1_ULPITLL_DAT0, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},	/* usbb1_ulpiphy_dat0 */
-	{USBB1_ULPITLL_DAT1, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},	/* usbb1_ulpiphy_dat1 */
-	{USBB1_ULPITLL_DAT2, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},	/* usbb1_ulpiphy_dat2 */
-	{USBB1_ULPITLL_DAT3, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},	/* usbb1_ulpiphy_dat3 */
+	{USBB1_ULPITLL_CLK, (IEN | OFF_EN | OFF_IN | M1)},		/* hsi1_cawake */
+	{USBB1_ULPITLL_STP, (IEN | OFF_EN | OFF_IN | M1)},		/* hsi1_cadata */
+	{USBB1_ULPITLL_DIR, (IEN | OFF_EN | OFF_IN | M1)},		/* hsi1_caflag */
+	{USBB1_ULPITLL_NXT, (OFF_EN | M1)},				/* hsi1_acready */
+	{USBB1_ULPITLL_DAT0, (OFF_EN | M1)},				/* hsi1_acwake */
+	{USBB1_ULPITLL_DAT1, (OFF_EN | M1)},				/* hsi1_acdata */
+	{USBB1_ULPITLL_DAT2, (OFF_EN | M1)},				/* hsi1_acflag */
+	{USBB1_ULPITLL_DAT3, (IEN | OFF_EN | OFF_IN | M1)},		/* hsi1_caready */
 	{USBB1_ULPITLL_DAT4, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},	/* usbb1_ulpiphy_dat4 */
 	{USBB1_ULPITLL_DAT5, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},	/* usbb1_ulpiphy_dat5 */
 	{USBB1_ULPITLL_DAT6, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},	/* usbb1_ulpiphy_dat6 */
@@ -104,8 +104,8 @@ const struct pad_conf_entry core_padconf_array_non_essential[] = {
 	{ABE_MCBSP2_DR, (IEN | OFF_EN | OFF_OUT_PTD | M0)},		/* abe_mcbsp2_dr */
 	{ABE_MCBSP2_DX, (OFF_EN | OFF_OUT_PTD | M0)},			/* abe_mcbsp2_dx */
 	{ABE_MCBSP2_FSX, (IEN | OFF_EN | OFF_PD | OFF_IN | M0)},	/* abe_mcbsp2_fsx */
-	{ABE_MCBSP1_CLKX, (IEN | M1)},					/* abe_slimbus1_clock */
-	{ABE_MCBSP1_DR, (IEN | M1)},					/* abe_slimbus1_data */
+	{ABE_MCBSP1_CLKX, (IEN | OFF_EN | OFF_PD | OFF_IN | M0)},	/* abe_mcbsp1_clkx */
+	{ABE_MCBSP1_DR, (IEN | OFF_EN | OFF_OUT_PTD | M0)},		/* abe_mcbsp1_dr */
 	{ABE_MCBSP1_DX, (OFF_EN | OFF_OUT_PTD | M0)},			/* abe_mcbsp1_dx */
 	{ABE_MCBSP1_FSX, (IEN | OFF_EN | OFF_PD | OFF_IN | M0)},	/* abe_mcbsp1_fsx */
 	{ABE_PDM_UL_DATA, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M0)},	/* abe_pdm_ul_data */
@@ -141,7 +141,7 @@ const struct pad_conf_entry core_padconf_array_non_essential[] = {
 	{MCSPI4_CS0, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M0)},	/* mcspi4_cs0 */
 	{UART4_RX, (IEN | M0)},						/* uart4_rx */
 	{UART4_TX, (M0)},						/* uart4_tx */
-	{USBB2_ULPITLL_CLK, (IEN | M3)},				/* gpio_157 */
+	{USBB2_ULPITLL_CLK, (PTD | IEN | M3)},				/* gpio_157 */
 	{USBB2_ULPITLL_STP, (IEN | M5)},				/* dispc2_data23 */
 	{USBB2_ULPITLL_DIR, (IEN | M5)},				/* dispc2_data22 */
 	{USBB2_ULPITLL_NXT, (IEN | M5)},				/* dispc2_data21 */
@@ -173,11 +173,11 @@ const struct pad_conf_entry core_padconf_array_non_essential[] = {
 	{FREF_CLK1_OUT, (M0)},						/* fref_clk1_out */
 	{FREF_CLK2_OUT, (M0)},						/* fref_clk2_out */
 	{SYS_NIRQ1, (PTU | IEN | M0)},					/* sys_nirq1 */
-	{SYS_NIRQ2, (PTU | IEN | M0)},					/* sys_nirq2 */
+	{SYS_NIRQ2, (M7)},						/* sys_nirq2 */
 	{SYS_BOOT0, (PTU | IEN | M3)},					/* gpio_184 */
 	{SYS_BOOT1, (M3)},						/* gpio_185 */
 	{SYS_BOOT2, (PTD | IEN | M3)},					/* gpio_186 */
-	{SYS_BOOT3, (M3)},						/* gpio_187 */
+	{SYS_BOOT3, (PTD | IEN | M3)},					/* gpio_187 */
 	{SYS_BOOT4, (M3)},						/* gpio_188 */
 	{SYS_BOOT5, (PTD | IEN | M3)},					/* gpio_189 */
 	{DPM_EMU0, (IEN | M0)},						/* dpm_emu0 */
@@ -222,6 +222,9 @@ const struct pad_conf_entry wkup_padconf_array_non_essential[] = {
 	{PAD1_SYS_PWRON_RESET, (M3)},		/* gpio_wk29 */
 	{PAD0_SYS_BOOT6, (IEN | M3)},		/* gpio_wk9 */
 	{PAD1_SYS_BOOT7, (IEN | M3)},		/* gpio_wk10 */
+	{PAD1_FREF_CLK3_REQ, (M3)},		/* gpio_wk30 */
+	{PAD1_FREF_CLK4_REQ, (M3)},		/* gpio_wk7 */
+	{PAD0_FREF_CLK4_OUT, (M3)},		/* gpio_wk8 */
 };
 
 #endif /* _SDP4430_MUX_DATA_H */
Signature · 1 line
1.7.0.4
author
#25 lore raw

PATCH 15/22 omap4: add clock support

In reply to Aneesh V

Add support for:
1. DPLL locking
2. Initialization of clock domains and clock modules

This work draws upon previous work done for x-loader mainly by:
Santosh Shilimkar <[email protected]> Rajendra Nayak <[email protected]>

---
 arch/arm/cpu/armv7/omap4/Makefile           |    1 +
 arch/arm/cpu/armv7/omap4/board.c            |    1 +
 arch/arm/cpu/armv7/omap4/clocks.c           |  717 +++++++++++++++++++++++++++
 arch/arm/include/asm/arch-omap4/clocks.h    |  504 +++++++++++++++++++
 arch/arm/include/asm/arch-omap4/sys_proto.h |    6 +
 arch/arm/include/asm/omap_common.h          |    3 +
 spl/board/ti/sdp4430/Makefile               |    6 +-
 7 files changed, 1237 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/omap4/clocks.c
 create mode 100644 arch/arm/include/asm/arch-omap4/clocks.h
arch/arm/cpu/armv7/omap4/Makefile +1 -0
index 987dc9d..6154e86 100644
@@ -30,6 +30,7 @@ SOBJS	+= lowlevel_init.o
 COBJS	+= board.o
 COBJS	+= mem.o
 COBJS	+= sys_info.o
+COBJS	+= clocks.o
 
 SRCS	:= $(SOBJS:.o=.S) $(COBJS:.o=.c)
 OBJS	:= $(addprefix $(obj),$(COBJS) $(SOBJS))
arch/arm/cpu/armv7/omap4/board.c +1 -0
index 95b6a96..62a59ad 100644
@@ -105,6 +105,7 @@ void s_init(void)
 {
 	watchdog_init();
 	set_mux_conf_regs();
+	prcm_init();
 #ifdef CONFIG_PRELOADER
 	preloader_console_init();
 #endif
arch/arm/cpu/armv7/omap4/clocks.c new file +717 -0

717 lines not on this page · raw message

arch/arm/include/asm/arch-omap4/clocks.h new file +504 -0

504 lines not on this page · raw message

arch/arm/include/asm/arch-omap4/sys_proto.h +6 -0
index 33a1666..fd21afd 100644
@@ -39,6 +39,12 @@ void set_muxconf_regs_non_essential(void);
 void sr32(void *, u32, u32, u32);
 u32 wait_on_value(u32, u32, void *, u32);
 void sdelay(unsigned long);
+void prcm_init(void);
+void bypass_dpll(u32 base);
+void freq_update_core(void);
+u32 get_syc_clk_freq(void);
+u32 omap4_ddr_clk(void);
+u32 omap4_revision(void);
 
 static inline u32 running_from_sdram(void)
 {
arch/arm/include/asm/omap_common.h +3 -0
index 50247af..49daa85 100644
@@ -25,6 +25,9 @@
 #ifndef	_OMAP_COMMON_H_
 #define	_OMAP_COMMON_H_
 
+/* Max value for DPLL multiplier M */
+#define OMAP_DPLL_MAX_N	127
+
 /* extract a bit field from a bit vector */
 #define get_bit_field(nr, start, mask)\
 	(((nr) & (mask)) >> (start))
spl/board/ti/sdp4430/Makefile +5 -1
index 6a6aa42..40e3e79 100644
@@ -115,8 +115,12 @@ $(obj)board.c:$(obj)omap4_mux_data.h
 	@rm -f $@
 	@ln -s $(TOPDIR)/arch/arm/cpu/armv7/omap4/board.c $@
 
+$(obj)clocks.c:
+	@rm -f $@
+	@ln -s $(TOPDIR)/arch/arm/cpu/armv7/omap4/clocks.c $@
+
 SOBJS	+= lowlevel_init.o
-COBJS	+= board.o
+COBJS	+= board.o clocks.o
 
 # rules
 LDPPFLAGS += -include $(TOPDIR)/include/config.h
Signature · 1 line
1.7.0.4
author
#26 lore raw

PATCH 16/22 omap4: add sdram init support

In reply to Aneesh V

Add support for the SDRAM controller (EMIF).

---
 arch/arm/cpu/armv7/omap4/Makefile           |    3 +
 arch/arm/cpu/armv7/omap4/board.c            |    2 +-
 arch/arm/cpu/armv7/omap4/emif.c             |  281 +++++++++++
 arch/arm/cpu/armv7/omap4/sdram_elpida.c     |  118 +++++
 arch/arm/include/asm/arch-omap4/emif.h      |  719 +++++++++++++++++++++++++++
 arch/arm/include/asm/arch-omap4/omap4.h     |   11 +
 arch/arm/include/asm/arch-omap4/sys_proto.h |    1 +
 include/configs/omap4_sdp4430.h             |    5 -
 spl/board/ti/sdp4430/Makefile               |   10 +-
 9 files changed, 1143 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/omap4/emif.c
 create mode 100644 arch/arm/cpu/armv7/omap4/sdram_elpida.c
 create mode 100644 arch/arm/include/asm/arch-omap4/emif.h
arch/arm/cpu/armv7/omap4/Makefile +3 -0
index 6154e86..d9714fe 100644
@@ -31,6 +31,9 @@ COBJS	+= board.o
 COBJS	+= mem.o
 COBJS	+= sys_info.o
 COBJS	+= clocks.o
+COBJS	+= emif.o
+COBJS	+= sdram_elpida.o
+
 
 SRCS	:= $(SOBJS:.o=.S) $(COBJS:.o=.c)
 OBJS	:= $(addprefix $(obj),$(COBJS) $(SOBJS))
arch/arm/cpu/armv7/omap4/board.c +1 -1
index 62a59ad..89b1213 100644
@@ -109,6 +109,7 @@ void s_init(void)
 #ifdef CONFIG_PRELOADER
 	preloader_console_init();
 #endif
+	sdram_init();
 }
 
 /*
@@ -169,7 +170,6 @@ u32 sdram_size(void)
  */
 int dram_init(void)
 {
-
 	gd->ram_size = sdram_size();
 
 	return 0;
arch/arm/cpu/armv7/omap4/emif.c new file +281 -0

281 lines not on this page · raw message

arch/arm/cpu/armv7/omap4/sdram_elpida.c new file +118 -0

118 lines not on this page · raw message

arch/arm/include/asm/arch-omap4/emif.h new file +719 -0

719 lines not on this page · raw message

arch/arm/include/asm/arch-omap4/omap4.h +11 -0
index 740ca9d..a1c4883 100644
@@ -51,6 +51,17 @@
 #define CONTROL_PADCONF_CORE	(OMAP44XX_L4_CORE_BASE + 0x100000)
 #define CONTROL_PADCONF_WKUP	(OMAP44XX_L4_CORE_BASE + 0x31E000)
 
+/* LPDDR2 IO regs */
+#define CONTROL_LPDDR2IO1_0	(CONTROL_PADCONF_CORE + 0x0638)
+#define CONTROL_LPDDR2IO1_1	(CONTROL_PADCONF_CORE + 0x063C)
+#define CONTROL_LPDDR2IO1_2	(CONTROL_PADCONF_CORE + 0x0640)
+#define CONTROL_LPDDR2IO1_3	(CONTROL_PADCONF_CORE + 0x0644)
+#define CONTROL_LPDDR2IO2_0	(CONTROL_PADCONF_CORE + 0x0648)
+#define CONTROL_LPDDR2IO2_1	(CONTROL_PADCONF_CORE + 0x064C)
+#define CONTROL_LPDDR2IO2_2	(CONTROL_PADCONF_CORE + 0x0650)
+#define CONTROL_LPDDR2IO2_3	(CONTROL_PADCONF_CORE + 0x0654)
+#define CONTROL_EFUSE_2		(CONTROL_PADCONF_CORE + 0x0704)
+
 /* CONTROL_ID_CODE */
 #define CONTROL_ID_CODE		(CTRL_BASE + 0x204)
 
arch/arm/include/asm/arch-omap4/sys_proto.h +1 -0
index fd21afd..4beff42 100644
@@ -44,6 +44,7 @@ void bypass_dpll(u32 base);
 void freq_update_core(void);
 u32 get_syc_clk_freq(void);
 u32 omap4_ddr_clk(void);
+void sdram_init(void);
 u32 omap4_revision(void);
 
 static inline u32 running_from_sdram(void)
include/configs/omap4_sdp4430.h +0 -5
index 5b20841..07d45a0 100644
@@ -245,11 +245,6 @@
 /* Defines for Clock init */
 #define CONFIG_SYS_OMAP4_ABE_SYSCK
 
-/* Defines for SDRAM init */
-#define CONFIG_SYS_AUTOMATIC_SDRAM_DETECTION	1
-#define CONFIG_SYS_EMIF_UPDATE_TIMINGS		1
-#define CONFIG_SYS_DEFAULT_LPDDR2_TIMINGS	1
-
 /* Defines for SPL */
 #define CONFIG_SPL
 #define CONFIG_SYS_SPL_TEXT_BASE	0x40304360
spl/board/ti/sdp4430/Makefile +9 -1
index 40e3e79..1f25f77 100644
@@ -115,12 +115,20 @@ $(obj)board.c:$(obj)omap4_mux_data.h
 	@rm -f $@
 	@ln -s $(TOPDIR)/arch/arm/cpu/armv7/omap4/board.c $@
 
+$(obj)emif.c:
+	@rm -f $@
+	@ln -s $(TOPDIR)/arch/arm/cpu/armv7/omap4/emif.c $@
+
+$(obj)sdram_elpida.c:
+	@rm -f $@
+	@ln -s $(TOPDIR)/arch/arm/cpu/armv7/omap4/sdram_elpida.c $@
+
 $(obj)clocks.c:
 	@rm -f $@
 	@ln -s $(TOPDIR)/arch/arm/cpu/armv7/omap4/clocks.c $@
 
 SOBJS	+= lowlevel_init.o
-COBJS	+= board.o clocks.o
+COBJS	+= board.o clocks.o emif.o sdram_elpida.o
 
 # rules
 LDPPFLAGS += -include $(TOPDIR)/include/config.h
Signature · 1 line
1.7.0.4
author
#27 lore raw

PATCH 17/22 omap4: calculate EMIF register values

In reply to Aneesh V

Calculate EMIF register values based on AC timing parameters from the SDRAM datasheet and the DDR frequency rather than using the hard-coded values.

For a new board the user doen't have to go through the tedious process of calculating the register values. Instead, just provide the AC timings from the device data sheet as input and the driver will automatically calculate the register values.

---
 arch/arm/cpu/armv7/omap-common/Makefile     |    1 +
 arch/arm/cpu/armv7/omap-common/utils.c      |   61 ++
 arch/arm/cpu/armv7/omap4/Makefile           |    1 -
 arch/arm/cpu/armv7/omap4/board.c            |    9 +-
 arch/arm/cpu/armv7/omap4/emif.c             |  861 ++++++++++++++++++++++++++-
 arch/arm/cpu/armv7/omap4/sdram_elpida.c     |  152 +++++-
 arch/arm/include/asm/arch-omap4/emif.h      |  304 ++++++++++-
 arch/arm/include/asm/arch-omap4/omap4.h     |   18 +-
 arch/arm/include/asm/arch-omap4/sys_proto.h |    1 +
 arch/arm/include/asm/omap_common.h          |   21 +
 include/configs/omap4_sdp4430.h             |    5 +
 spl/board/ti/sdp4430/Makefile               |    6 +-
 12 files changed, 1424 insertions(+), 16 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/omap-common/utils.c
arch/arm/cpu/armv7/omap-common/Makefile +1 -0
index dc01ee5..8f698f8 100644
@@ -28,6 +28,7 @@ LIB	= $(obj)libomap-common.o
 SOBJS	:= reset.o
 
 COBJS	:= timer.o
+COBJS	+= utils.o
 
 SRCS	:= $(SOBJS:.o=.S) $(COBJS:.o=.c)
 OBJS	:= $(addprefix $(obj),$(SOBJS) $(COBJS))
arch/arm/cpu/armv7/omap-common/utils.c new file +61 -0

61 lines not on this page · raw message

arch/arm/cpu/armv7/omap4/Makefile +0 -1
index d9714fe..0b525e1 100644
@@ -34,7 +34,6 @@ COBJS	+= clocks.o
 COBJS	+= emif.o
 COBJS	+= sdram_elpida.o
 
-
 SRCS	:= $(SOBJS:.o=.S) $(COBJS:.o=.c)
 OBJS	:= $(addprefix $(obj),$(COBJS) $(SOBJS))
 
arch/arm/cpu/armv7/omap4/board.c +5 -4
index 89b1213..925601d 100644
@@ -32,6 +32,7 @@
 #include <asm/arch/cpu.h>
 #include <asm/arch/sys_proto.h>
 #include <asm/sizes.h>
+#include <asm/arch/emif.h>
 #include "omap4_mux_data.h"
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -148,13 +149,13 @@ u32 sdram_size(void)
 {
 	u32 section, i, total_size = 0, size, addr;
 	for (i = 0; i < 4; i++) {
-		section	= __raw_readl(DMM_LISA_MAP_BASE + i*4);
-		addr = section & DMM_LISA_MAP_SYS_ADDR_MASK;
+		section	= __raw_readl(OMAP44XX_DMM_LISA_MAP_BASE + i*4);
+		addr = section & OMAP44XX_SYS_ADDR_MASK;
 		/* See if the address is valid */
 		if ((addr >= OMAP44XX_DRAM_ADDR_SPACE_START) &&
 		    (addr < OMAP44XX_DRAM_ADDR_SPACE_END)) {
-			size	= ((section & DMM_LISA_MAP_SYS_SIZE_MASK) >>
-				    DMM_LISA_MAP_SYS_SIZE_SHIFT);
+			size	= ((section & OMAP44XX_SYS_SIZE_MASK) >>
+				   OMAP44XX_SYS_SIZE_SHIFT);
 			size	= 1 << size;
 			size	*= SZ_16M;
 			total_size += size;
arch/arm/cpu/armv7/omap4/emif.c +859 -2

905 lines not on this page · raw message

arch/arm/cpu/armv7/omap4/sdram_elpida.c +151 -1

173 lines not on this page · raw message

arch/arm/include/asm/arch-omap4/emif.h +303 -1

349 lines not on this page · raw message

arch/arm/include/asm/arch-omap4/omap4.h +12 -6
index a1c4883..fd8fb10 100644
@@ -86,12 +86,7 @@
 /* GPMC */
 #define OMAP44XX_GPMC_BASE	0x50000000
 
-/* DMM */
-#define OMAP44XX_DMM_BASE		0x4E000000
-#define DMM_LISA_MAP_BASE		(OMAP44XX_DMM_BASE + 0x40)
-#define DMM_LISA_MAP_SYS_SIZE_MASK	(7 << 20)
-#define DMM_LISA_MAP_SYS_SIZE_SHIFT	20
-#define DMM_LISA_MAP_SYS_ADDR_MASK	(0xFF << 24)
+
 /*
  * Hardware Register Details
  */
@@ -137,6 +132,17 @@ struct s32ktimer {
 /* Temporary SRAM stack used while low level init is done */
 #define LOW_LEVEL_SRAM_STACK	NON_SECURE_SRAM_END
 
+#define SRAM_SCRATCH_SPACE_ADDR		NON_SECURE_SRAM_START
+
+/*
+ * SRAM scratch space entries
+ */
+
+/* Boot parameter passed from SPL to U-Boot */
+#define OMAP4_SRAM_SCRATCH_EMIF_SIZE	SRAM_SCRATCH_SPACE_ADDR
+#define OMAP4_SRAM_SCRATCH_EMIF_T_NUM	(SRAM_SCRATCH_SPACE_ADDR + 0x8)
+#define OMAP4_SRAM_SCRATCH_EMIF_T_DEN	(SRAM_SCRATCH_SPACE_ADDR + 0xC)
+
 /* Silicon revisions */
 #define OMAP4430_SILICON_ID_INVALID	0
 #define OMAP4430_ES1_0	1
arch/arm/include/asm/arch-omap4/sys_proto.h +1 -0
index 4beff42..211d3b8 100644
@@ -44,6 +44,7 @@ void bypass_dpll(u32 base);
 void freq_update_core(void);
 u32 get_syc_clk_freq(void);
 u32 omap4_ddr_clk(void);
+void cancel_out(u32 *num, u32 *den, u32 den_limit);
 void sdram_init(void);
 u32 omap4_revision(void);
 
arch/arm/include/asm/omap_common.h +21 -0
index 49daa85..9f2616c 100644
@@ -51,6 +51,27 @@
 		       (addr));\
 	} while (0);
 
+/* find log2 of number n - rounded up */
+static inline u32 log_2_n_round_up(u32 n)
+{
+	u32 clz;
+	/* count leading zeros */
+	asm volatile ("CLZ %0, %1" : "=r" (clz) : "r" (n));
+	if (n & (n - 1))
+		return 31 - clz; /* power of 2 */
+	else
+		return 32 - clz; /* not power of 2 - round up */
+}
+
+/* find log2 of number n - rounded down */
+static inline u32 log_2_n_round_down(u32 n)
+{
+	u32 clz;
+	/* count leading zeros */
+	asm volatile ("CLZ %0, %1" : "=r" (clz) : "r" (n));
+	return 31 - clz;
+}
+
 /* Boot device */
 #define BOOT_DEVICE_NONE	0
 #define BOOT_DEVICE_XIP		1
include/configs/omap4_sdp4430.h +5 -0
index 07d45a0..c29b184 100644
@@ -245,6 +245,11 @@
 /* Defines for Clock init */
 #define CONFIG_SYS_OMAP4_ABE_SYSCK
 
+/* Defines for SDRAM init */
+#ifndef CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS
+#define CONFIG_SYS_DEFAULT_LPDDR2_TIMINGS	1
+#endif
+
 /* Defines for SPL */
 #define CONFIG_SPL
 #define CONFIG_SYS_SPL_TEXT_BASE	0x40304360
spl/board/ti/sdp4430/Makefile +5 -1
index 1f25f77..d89dea0 100644
@@ -81,6 +81,10 @@ SOBJS	+= start.o
 COBJS	+= syslib.o
 
 # omap-common
+$(obj)utils.c:
+	@rm -f $@
+	@ln -s $(TOPDIR)/arch/arm/cpu/armv7/omap-common/utils.c $@
+
 $(obj)timer.c:
 	@rm -f $@
 	@ln -s $(TOPDIR)/arch/arm/cpu/armv7/omap-common/timer.c $@
@@ -94,7 +98,7 @@ $(obj)spl-omap.c:
 	@ln -s $(TOPDIR)/spl/board/ti/spl-omap.c $@
 
 SOBJS	+= reset.o
-COBJS	+= timer.o spl-omap.o
+COBJS	+= utils.o timer.o spl-omap.o
 
 $(OBJTREE)/MLO:	$(splobj)u-boot-spl.bin
 	$(OBJTREE)/tools/mkimage -T omapimage \
Signature · 1 line
1.7.0.4
#28 lore raw

PATCH 17/22 omap4: calculate EMIF register values

Quoted 11 lines · Aneesh V

Calculate EMIF register values based on AC timing parameters from the SDRAM datasheet and the DDR frequency rather than using the hard-coded values.

For a new board the user doen't have to go through the tedious process of calculating the register values. Instead, just provide the AC timings from the device data sheet as input and the driver will automatically calculate the register values.

---

I get some warnings from arch/arm/cpu/armv7/omap4/emif.c:
emif.c: In function ?sdram_init?:
emif.c:1164:43: warning: ?section_map? may be used uninitialized in this function
emif.c:1166:27: warning: ?lis_map_regs_calculated$dmm_lisa_map_3? may be used uninitialized in this function
emif.c: In function ?sdram_init?:
emif.c:1166:27: warning: ?lis_map_regs_calculated$dmm_lisa_map_3? may be used uninitialized in this function

Looking at the code I see that these are initialized but the compiler can't firgure that out.

John

author
#29 lore raw

PATCH 17/22 omap4: calculate EMIF register values

Quoted 24 lines · John Rigby
Quoted 11 lines · Aneesh V

Calculate EMIF register values based on AC timing parameters from the SDRAM datasheet and the DDR frequency rather than using the hard-coded values.

For a new board the user doen't have to go through the tedious process of calculating the register values. Instead, just provide the AC timings from the device data sheet as input and the driver will automatically calculate the register values.

---

I get some warnings from arch/arm/cpu/armv7/omap4/emif.c:
emif.c: In function ?sdram_init?:
emif.c:1164:43: warning: ?section_map? may be used uninitialized in this function
emif.c:1166:27: warning: ?lis_map_regs_calculated$dmm_lisa_map_3? may be used uninitialized in this function
emif.c: In function ?sdram_init?:
emif.c:1166:27: warning: ?lis_map_regs_calculated$dmm_lisa_map_3? may be used uninitialized in this function

Quoted 2 lines

Looking at the code I see that these are initialized but the compiler can't firgure that out.

I don't see the warnings with my tool-chain ((Sourcery G++ Lite 2010q1-202) GCC 4.4.1)

I tried immediately after this patch and also after applying all the patches. Which compiler are you using?

best regards,
Aneesh

#30 lore raw

PATCH 17/22 omap4: calculate EMIF register values

Quoted 27 lines · Aneesh V
Quoted 26 lines · John Rigby
Quoted 5 lines · On Mon, Feb 28, 2011 at 4:46 AM, Aneesh V<[email protected]> ?wrote:

Calculate EMIF register values based on AC timing parameters from the SDRAM datasheet and the DDR frequency rather than using the hard-coded values.

Quoted 7 lines

For a new board the user doen't have to go through the tedious process of calculating the register values. Instead, just provide the AC timings from the device data sheet as input and the driver will automatically calculate the register values.

---

I get some warnings from arch/arm/cpu/armv7/omap4/emif.c:
emif.c: In function ?sdram_init?:
emif.c:1164:43: warning: ?section_map? may be used uninitialized in this function
emif.c:1166:27: warning: ?lis_map_regs_calculated$dmm_lisa_map_3? may be used uninitialized in this function
emif.c: In function ?sdram_init?:
emif.c:1166:27: warning: ?lis_map_regs_calculated$dmm_lisa_map_3? may be used uninitialized in this function

Quoted 8 lines
Quoted 2 lines

Looking at the code I see that these are initialized but the compiler can't firgure that out.

I don't see the warnings with my tool-chain ((Sourcery G++ Lite 2010q1-202) GCC 4.4.1)

I tried immediately after this patch and also after applying all the patches. Which compiler are you using?

The latest Linaro cross toolchain:

$ arm-linux-gnueabi-gcc --version
arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.5.2-1ubuntu3ppa1) 4.5.2
Quoted 4 lines

best regards,
Aneesh

author
#31 lore raw

PATCH 17/22 omap4: calculate EMIF register values

In reply to John Rigby
Quoted 10 lines · John Rigby
Quoted 9 lines · Aneesh V

Calculate EMIF register values based on AC timing parameters from the SDRAM datasheet and the DDR frequency rather than using the hard-coded values.

For a new board the user doen't have to go through the tedious process of calculating the register values. Instead, just provide the AC timings from the device data sheet as input and the driver will automatically calculate the register values.

Quoted 5 lines
Quoted 2 lines

---

I get some warnings from arch/arm/cpu/armv7/omap4/emif.c:

I installed Linaro GCC 4.5.2 and I see these warnings now.

Quoted 2 lines

emif.c: In function ?sdram_init?:
emif.c:1164:43: warning: ?section_map? may be used uninitialized in

Technically, I think this is a false alarm. Although section_map is initialized conditionally the use is also conditional. So, if the compiler had done proper data flow analysis it could see that this won't happen (I don't know if compilers do that kind of analysis) Nevertheless, we could avoid it. I will fix it in v2.

Quoted 6 lines

this function
emif.c:1166:27: warning: ?lis_map_regs_calculated$dmm_lisa_map_3? may be used uninitialized in this function
emif.c: In function ?sdram_init?:
emif.c:1166:27: warning: ?lis_map_regs_calculated$dmm_lisa_map_3? may be used uninitialized in this function

This is genuine. In one path it may be used uninitialized(this path is not expected in real scenarios). I will fix this.

Thanks,
Aneesh

author
#32 lore raw

PATCH 18/22 omap4: automatic sdram detection

In reply to Aneesh V

Identify SDRAM devices connected to EMIF automatically:
LPDDR2 devices have some Mode Registers that provide details about the device such as the type, density, bus width etc. EMIF has the capability to read these registers. If there are not devices connected to a given chip-select reading mode registers will return junk values. After reading as many such registers as possible and matching with expected ranges of values the driver can identify if there is a device connected to the respective CS. If we identify that a device is connected the values read give us complete details about the device.

This along with the base AC timings specified by JESD209-2 allows us to do a complete automatic initialization of SDRAM that works on all boards.

Please note that the default AC timings specified by JESD209-2 will be safe for all devices but not necessarily optimal. However, for the Elpida devices used on Panda and SDP the default timings are both safe and optimal.

---
 arch/arm/cpu/armv7/omap4/emif.c         |  177 +++++++++++++++++++++++++++++-
 arch/arm/cpu/armv7/omap4/sdram_elpida.c |    9 +-
 include/configs/omap4_sdp4430.h         |    1 +
 3 files changed, 176 insertions(+), 11 deletions(-)
arch/arm/cpu/armv7/omap4/emif.c +170 -5
index 1bdb1d2..006d065 100644
@@ -165,7 +165,8 @@ static const struct lpddr2_min_tck min_tck_jedec = {
 	.tFAW = 8
 };
 
-static const struct lpddr2_ac_timings *jedec_ac_timings[MAX_NUM_SPEEDBINS] = {
+static const struct lpddr2_ac_timings const*
+			jedec_ac_timings[MAX_NUM_SPEEDBINS] = {
 	&timings_jedec_200_mhz,
 	&timings_jedec_333_mhz,
 	&timings_jedec_400_mhz
@@ -779,6 +780,146 @@ void emif_reset_phy(u32 base)
 	writel(iodft, &emif->emif_iodft_tlgc);
 }
 
+#ifdef CONFIG_SYS_AUTOMATIC_SDRAM_DETECTION
+static void display_sdram_details(u32 emif_nr, u32 cs,
+				  struct lpddr2_device_details *device)
+{
+	const char *mfg_str;
+	const char *type_str;
+	char density_str[10];
+	u32 density;
+
+	debug("EMIF%d CS%d\t", emif_nr, cs);
+
+	if (!device) {
+		debug("None\n");
+		return;
+	}
+
+	mfg_str = get_lpddr2_manufacturer(device->manufacturer);
+	type_str = get_lpddr2_type(device->type);
+
+	density = lpddr2_density_2_size_in_mbytes[device->density];
+	if ((density / 1024 * 1024) == density) {
+		density /= 1024;
+		sprintf(density_str, "%d GB", density);
+	} else
+		sprintf(density_str, "%d MB", density);
+	if (mfg_str && type_str)
+		debug("%s\t\t%s\t%s\n", mfg_str, type_str, density_str);
+}
+
+static u8 is_lpddr2_sdram_present(u32 base, u32 cs,
+				  struct lpddr2_device_details *lpddr2_device)
+{
+	u32 mr = 0, temp;
+
+	mr = get_mr(base, cs, LPDDR2_MR0);
+	if (mr > 0xFF) {
+		/* Mode register value bigger than 8 bit */
+		return 0;
+	}
+
+	temp = get_bit_field(mr, LPDDR2_MR0_DI_SHIFT, LPDDR2_MR0_DI_MASK);
+	if (temp) {
+		/* Not SDRAM */
+		return 0;
+	}
+	temp = get_bit_field(mr, LPDDR2_MR0_DNVI_SHIFT, LPDDR2_MR0_DNVI_MASK);
+
+	if (temp) {
+		/* DNV supported - But DNV is only supported for NVM */
+		return 0;
+	}
+
+	mr = get_mr(base, cs, LPDDR2_MR4);
+	if (mr > 0xFF) {
+		/* Mode register value bigger than 8 bit */
+		return 0;
+	}
+
+	mr = get_mr(base, cs, LPDDR2_MR5);
+	if (mr >= 0xFF) {
+		/* Mode register value bigger than 8 bit */
+		return 0;
+	}
+
+	if (!get_lpddr2_manufacturer(mr)) {
+		/* Manufacturer not identified */
+		return 0;
+	}
+	lpddr2_device->manufacturer = mr;
+
+	mr = get_mr(base, cs, LPDDR2_MR6);
+	if (mr >= 0xFF) {
+		/* Mode register value bigger than 8 bit */
+		return 0;
+	}
+
+	mr = get_mr(base, cs, LPDDR2_MR7);
+	if (mr >= 0xFF) {
+		/* Mode register value bigger than 8 bit */
+		return 0;
+	}
+
+	mr = get_mr(base, cs, LPDDR2_MR8);
+	if (mr >= 0xFF) {
+		/* Mode register value bigger than 8 bit */
+		return 0;
+	}
+
+	temp = get_bit_field(mr, MR8_TYPE_SHIFT, MR8_TYPE_MASK);
+	if (!get_lpddr2_type(temp)) {
+		/* Not SDRAM */
+		return 0;
+	}
+	lpddr2_device->type = temp;
+
+	temp = get_bit_field(mr, MR8_DENSITY_SHIFT, MR8_DENSITY_MASK);
+	if (temp > LPDDR2_DENSITY_32Gb) {
+		/* Density not supported */
+		return 0;
+	}
+	lpddr2_device->density = temp;
+
+	temp = get_bit_field(mr, MR8_IO_WIDTH_SHIFT, MR8_IO_WIDTH_MASK);
+	if (!get_lpddr2_io_width(temp)) {
+		/* IO width unsupported value */
+		return 0;
+	}
+	lpddr2_device->io_width = temp;
+
+	/*
+	 * If all the above tests pass we should
+	 * have a device on this chip-select
+	 */
+	return 1;
+}
+
+static struct lpddr2_device_details *get_lpddr2_details(u32 base, u8 cs,
+			struct lpddr2_device_details *lpddr2_dev_details)
+{
+	u32 phy;
+	struct emif_reg_struct *emif = (struct emif_reg_struct *)base;
+
+	if (!lpddr2_dev_details)
+		return NULL;
+
+	/* Do the minimum init for mode register accesses */
+	if (!running_from_sdram()) {
+		phy = get_ddr_phy_ctrl_1(get_syc_clk_freq() / 2, RL_BOOT);
+		writel(phy, &emif->emif_ddr_phy_ctrl_1);
+	}
+
+	if (!(is_lpddr2_sdram_present(base, cs, lpddr2_dev_details)))
+		return NULL;
+
+	display_sdram_details(emif_num(base), cs, lpddr2_dev_details);
+
+	return lpddr2_dev_details;
+}
+#endif /* CONFIG_SYS_AUTOMATIC_SDRAM_DETECTION */
+
 static void do_lpddr2_init(u32 base, u32 cs)
 {
 	u32 mr_addr;
@@ -862,9 +1003,7 @@ static void emif_update_timings(u32 base, const struct emif_regs *regs)
 
 static void do_sdram_init(u32 base)
 {
-	struct emif_device_details dev_details;
 	const struct emif_regs *regs;
-
 	u32 in_sdram, emif_nr;
 
 	in_sdram = running_from_sdram();
@@ -872,6 +1011,7 @@ static void do_sdram_init(u32 base)
 
 #ifdef CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS
 	const struct emif_regs *tmp_regs;
+
 	emif_get_reg_dump(&regs, &tmp_regs);
 	regs = (emif_nr == 1) ? regs : tmp_regs;
 #else
@@ -879,23 +1019,48 @@ static void do_sdram_init(u32 base)
 	 * The user has not provided the register values. We need to
 	 * calculate it based on the timings and the DDR frequency
 	 */
+	struct emif_device_details dev_details = { NULL, NULL };
+	struct emif_regs calculated_regs;
 
+#if !defined(CONFIG_SYS_AUTOMATIC_SDRAM_DETECTION) || \
+	!defined(CONFIG_SYS_DEFAULT_LPDDR2_TIMINGS)
+
+	/* We need some input about the devices from the user */
 	const struct emif_device_details *dev_details_user_provided;
 	const struct emif_device_details *tmp_details;
-	struct emif_regs calculated_regs;
 
-	/* We need some input about the devices from the user */
 	emif_get_device_details(&dev_details_user_provided, &tmp_details);
 	dev_details_user_provided = (emif_nr == 1) ? dev_details_user_provided
 						   : tmp_details;
 	if (!dev_details_user_provided)
 		return;
+#endif
 
+#ifdef CONFIG_SYS_AUTOMATIC_SDRAM_DETECTION
+	struct lpddr2_device_details cs0_dev_details, cs1_dev_details;
+
+	/* Automatically find the device details */
+	if (!in_sdram) {
+		dev_details.cs0_device_details =
+		    get_lpddr2_details(base, CS0, &cs0_dev_details);
+		dev_details.cs1_device_details =
+		    get_lpddr2_details(base, CS1, &cs1_dev_details);
+		/*
+		 * Reset the PHY - if there is nothing connected on any
+		 * of the chip selects(typically CS1) mode register reads
+		 * will mess up with the PHY state and subsequent
+		 * initialization won't work. PHY reset brings back PHY to
+		 * a good state.
+		 */
+		emif_reset_phy(base);
+	}
+#else
 	dev_details.cs0_device_details =
 			dev_details_user_provided->cs0_device_details;
 	dev_details.cs1_device_details =
 			dev_details_user_provided->cs1_device_details;
 
+#endif
 	/* Return if no devices on this EMIF */
 	if (!dev_details.cs0_device_details &&
 	    !dev_details.cs1_device_details) {
arch/arm/cpu/armv7/omap4/sdram_elpida.c +4 -5
index e7d2bd5..8dfe6f9 100644
@@ -86,10 +86,8 @@ const struct dmm_lisa_map_regs lisa_map_2G_x_2_x_2 = {
 	.dmm_lisa_map_3 = 0x80640300
 };
 
-void emif_get_reg_dump_sdp(const struct emif_regs **emif1_regs,
-			const struct emif_regs **emif2_regs)
-
-#else
+#elif !defined(CONFIG_SYS_AUTOMATIC_SDRAM_DETECTION) || \
+	!defined(CONFIG_SYS_DEFAULT_LPDDR2_TIMINGS)
 
 static const struct lpddr2_ac_timings timings_elpida_400_mhz = {
 	.max_freq	= 400000000,
@@ -245,7 +243,8 @@ static void emif_get_dmm_regs_sdp(const struct dmm_lisa_map_regs
 void emif_get_dmm_regs(const struct dmm_lisa_map_regs **dmm_lisa_regs)
 	__attribute__((weak, alias("emif_get_dmm_regs_sdp")));
 
-#else
+#elif !defined(CONFIG_SYS_AUTOMATIC_SDRAM_DETECTION) || \
+	!defined(CONFIG_SYS_DEFAULT_LPDDR2_TIMINGS)
 
 static void emif_get_device_details_sdp(
 			const struct emif_device_details **emif1_details,
include/configs/omap4_sdp4430.h +1 -0
index c29b184..a4332b7 100644
@@ -247,6 +247,7 @@
 
 /* Defines for SDRAM init */
 #ifndef CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS
+#define CONFIG_SYS_AUTOMATIC_SDRAM_DETECTION	1
 #define CONFIG_SYS_DEFAULT_LPDDR2_TIMINGS	1
 #endif
 
Signature · 1 line
1.7.0.4
author
#33 lore raw

PATCH 19/22 armv7: embed u-boot size within u-boot for use from SPL

In reply to Aneesh V

Embed the u-boot flash image size at a known offset from the start of u-boot so that SPL can use it while loading u-boot from a non-XIP media.

---
 arch/arm/cpu/armv7/start.S |    6 +++++-
 spl/board/ti/spl-omap.lds  |    1 +
 2 files changed, 6 insertions(+), 1 deletions(-)
arch/arm/cpu/armv7/start.S +5 -1
index f5f08d9..1cbd128 100644
@@ -64,8 +64,12 @@ _pad:			.word 0x12345678 /* now 16*4=64 */
 
 .global _end_vect
 _end_vect:
+.global	_u_boot_size
+_u_boot_size:
+	.word	0xDEADBEEF
+	.word	__flash_image_end - _start
 
-	.balignl 16,0xdeadbeef
+.balignl 16,0xdeadbeef
 /*************************************************************************
  *
  * Startup Code (reset vector)
spl/board/ti/spl-omap.lds +1 -0
index 27b5295..64eb4c9 100644
@@ -50,6 +50,7 @@ SECTIONS
 	.data : { *(SORT_BY_ALIGNMENT(.data*)) } >.sram
 	. = ALIGN(4);
 	__image_copy_end = .;
+	__flash_image_end = .;
 
 	.bss :
 	{
Signature · 1 line
1.7.0.4
author
#34 lore raw

PATCH 20/22 omap: add MMC support to SPL

In reply to Aneesh V
---
 arch/arm/cpu/armv7/start.S         |    1 +
 arch/arm/include/asm/omap_common.h |    4 +
 include/configs/omap4_sdp4430.h    |    7 ++-
 spl/board/ti/sdp4430/Makefile      |   35 +++++++++++
 spl/board/ti/spl-omap.c            |  112 +++++++++++++++++++++++++++++++++++-
 5 files changed, 156 insertions(+), 3 deletions(-)
arch/arm/cpu/armv7/start.S +1 -0
index 1cbd128..927476c 100644
@@ -64,6 +64,7 @@ _pad:			.word 0x12345678 /* now 16*4=64 */
 
 .global _end_vect
 _end_vect:
+/* This label should be at the same location for SPL and U-Boot */
 .global	_u_boot_size
 _u_boot_size:
 	.word	0xDEADBEEF
arch/arm/include/asm/omap_common.h +4 -0
index 9f2616c..c2efa7c 100644
@@ -99,4 +99,8 @@ u32 omap_boot_device(void);
 u32 omap_boot_mode(void);
 void preloader_console_init(void);
 
+/* symbols from start.S */
+extern u32 _u_boot_size;
+extern u32 _start;
+
 #endif /* _OMAP_COMMON_H_ */
include/configs/omap4_sdp4430.h +5 -2
index a4332b7..0ed474d 100644
@@ -257,7 +257,10 @@
 #define CONFIG_SYS_SPL_MAX_SIZE		0x7800	/* 30 K */
 #define CONFIG_SYS_SPL_STACK		LOW_LEVEL_SRAM_STACK
 
-#define CONFIG_SYS_SPL_BSS_START_ADDR	0x80000000
-#define CONFIG_SYS_SPL_BSS_MAX_SIZE	0x80000		/* 512 KB */
+#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_SPL_BSS_START_ADDR		0x80000000
+#define CONFIG_SYS_SPL_BSS_MAX_SIZE		0x80000		/* 512 KB */
 
 #endif /* __CONFIG_H */
spl/board/ti/sdp4430/Makefile +35 -0
index d89dea0..18c5b8e 100644
@@ -68,6 +68,41 @@ $(obj)ctype.c:
 COBJS	+= serial.o ns16550.o string.o vsprintf.o console.o stdio.o
 COBJS	+= ctype.o eabi_compat.o div64.o
 
+
+# mmc
+$(obj)mmc.c:
+	@rm -f $@
+	@ln -s $(TOPDIR)/drivers/mmc/mmc.c $@
+
+$(obj)omap_hsmmc.c:
+	@rm -f $@
+	@ln -s $(TOPDIR)/drivers/mmc/omap_hsmmc.c $@
+
+$(obj)omap24xx_i2c.c: $(obj)omap24xx_i2c.h
+	@rm -f $@
+	@ln -s $(TOPDIR)/drivers/i2c/omap24xx_i2c.c $@
+
+$(obj)omap24xx_i2c.h:
+	@rm -f $@
+	@ln -s $(TOPDIR)/drivers/i2c/omap24xx_i2c.h $@
+
+$(obj)time.c:
+	@rm -f $@
+	@ln -s $(TOPDIR)/lib/time.c $@
+
+$(obj)part.c:
+	@rm -f $@
+	@ln -s $(TOPDIR)/disk/part.c $@
+
+$(obj)part_dos.c: $(obj)part_dos.h
+	@rm -f $@
+	@ln -s $(TOPDIR)/disk/part_dos.c $@
+
+$(obj)part_dos.h:
+	@rm -f $@
+	@ln -s $(TOPDIR)/disk/part_dos.h $@
+
+COBJS	+= omap_hsmmc.o omap24xx_i2c.o mmc.o time.o part.o part_dos.o
 # armv7
 $(obj)start.S:
 	@rm -f $@
spl/board/ti/spl-omap.c +111 -1

135 lines not on this page · raw message

Signature · 1 line
1.7.0.4
author
#35 lore raw

PATCH 21/22 omap: spl: add FAT support over MMC

In reply to Aneesh V
---
 include/configs/omap4_sdp4430.h |    1 +
 spl/board/ti/sdp4430/Makefile   |    8 ++++++++
 spl/board/ti/spl-omap.c         |   22 ++++++++++++++++++++++
 3 files changed, 31 insertions(+), 0 deletions(-)
include/configs/omap4_sdp4430.h +1 -0
index 0ed474d..dcc9e39 100644
@@ -259,6 +259,7 @@
 
 #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_SYS_SPL_BSS_START_ADDR		0x80000000
 #define CONFIG_SYS_SPL_BSS_MAX_SIZE		0x80000		/* 512 KB */
spl/board/ti/sdp4430/Makefile +8 -0
index 18c5b8e..8310db9 100644
@@ -103,6 +103,14 @@ $(obj)part_dos.h:
 	@ln -s $(TOPDIR)/disk/part_dos.h $@
 
 COBJS	+= omap_hsmmc.o omap24xx_i2c.o mmc.o time.o part.o part_dos.o
+
+# fat
+$(obj)fat.c:
+	@rm -f $@
+	@ln -s $(TOPDIR)/fs/fat/fat.c $@
+
+COBJS	+=  fat.o
+
 # armv7
 $(obj)start.S:
 	@rm -f $@
spl/board/ti/spl-omap.c +22 -0
index b64eac9..3612434 100644
@@ -29,6 +29,7 @@
 #include <asm/u-boot.h>
 #include <asm/arch/sys_proto.h>
 #include <mmc.h>
+#include <fat.h>
 #include <timestamp_autogenerated.h>
 #include <asm/omap_common.h>
 #include <asm/arch/mmc_host_def.h>
@@ -101,6 +102,25 @@ end:
 	}
 }
 
+static void mmc_load_uboot_fat(struct mmc *mmc)
+{
+	s32 err;
+
+	err = fat_register_device(&mmc->block_dev,
+				CONFIG_SYS_MMC_SD_FAT_BOOT_PARTITION);
+	if (err) {
+		printf("spl: fat register err - %d\n", err);
+		hang();
+	}
+
+	err = file_fat_read("u-boot.bin", (u8 *)CONFIG_SYS_TEXT_BASE, 0);
+
+	if (err <= 0) {
+		printf("spl: error reading u-boot.bin - %d\n", err);
+		hang();
+	}
+}
+
 static void mmc_load_uboot(u32 mmc_dev)
 {
 	struct mmc *mmc;
@@ -124,6 +144,8 @@ static void mmc_load_uboot(u32 mmc_dev)
 	boot_mode = omap_boot_mode();
 	if (boot_mode == MMCSD_MODE_RAW)
 		mmc_load_uboot_raw(mmc, mmc_dev);
+	else if (boot_mode == MMCSD_MODE_FAT)
+		mmc_load_uboot_fat(mmc);
 	else {
 		puts("spl: wrong MMC boot mode\n");
 		hang();
Signature · 1 line
1.7.0.4
author
#36 lore raw

PATCH 22/22 omap4: add spl support for OMAP4 Panda

In reply to Aneesh V
---
 arch/arm/include/asm/arch-omap4/emif.h |   10 +-
 include/configs/omap4_panda.h          |   24 ++++
 spl/board/ti/panda/Makefile            |  219 ++++++++++++++++++++++++++++++++
 3 files changed, 248 insertions(+), 5 deletions(-)
 create mode 100644 spl/board/ti/panda/Makefile
arch/arm/include/asm/arch-omap4/emif.h +5 -5
index 8cc3230..b95e545 100644
@@ -520,11 +520,11 @@
 
 /* Trap for invalid TILER PAT entries */
 #define DMM_LISA_MAP_0_INVAL_ADDR_TRAP		(\
-		(0  << OMAP44XX_SDRC_ADDR_SHIFT) |\
-		(DMM_SDRC_MAP_EMIF1_ONLY << OMAP44XX_SDRC_MAP_SHIFT)|\
-		(DMM_SDRC_ADDR_SPC_INVALID << OMAP44XX_SDRC_ADDRSPC_SHIFT)|\
-		(DMM_SDRC_INTL_NONE << OMAP44XX_SDRC_INTL_SHIFT)|\
-		(0xFF << OMAP44XX_SYS_ADDR_SHIFT))
+	(0  << OMAP44XX_SDRC_ADDR_SHIFT) |\
+	(DMM_SDRC_MAP_EMIF1_ONLY << OMAP44XX_SDRC_MAP_SHIFT)|\
+	(DMM_SDRC_ADDR_SPC_INVALID << OMAP44XX_SDRC_ADDRSPC_SHIFT)|\
+	(DMM_SDRC_INTL_NONE << OMAP44XX_SDRC_INTL_SHIFT)|\
+	(0xFF << OMAP44XX_SYS_ADDR_SHIFT))
 
 
 /* Reg mapping structure */
include/configs/omap4_panda.h +24 -0
index 2b03b0f..b389035 100644
@@ -117,7 +117,9 @@
 
 /* USB device configuration */
 #define CONFIG_USB_DEVICE		1
+#ifndef CONFIG_PRELOADER
 #define CONFIG_USB_TTY			1
+#endif
 #define CONFIG_SYS_CONSOLE_IS_IN_ENV	1
 
 /* Flash */
@@ -234,4 +236,26 @@
 					 CONFIG_SYS_INIT_RAM_SIZE - \
 					 GENERATED_GBL_DATA_SIZE)
 
+/* Defines for Clock init */
+#define CONFIG_SYS_OMAP4_ABE_SYSCK
+
+/* Defines for SDRAM init */
+#ifndef CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS
+#define CONFIG_SYS_AUTOMATIC_SDRAM_DETECTION	1
+#define CONFIG_SYS_DEFAULT_LPDDR2_TIMINGS	1
+#endif
+
+/* Defines for SPL */
+#define CONFIG_SPL
+#define CONFIG_SYS_SPL_TEXT_BASE	0x40304360
+#define CONFIG_SYS_SPL_MAX_SIZE		0x7800	/* 30 K */
+#define CONFIG_SYS_SPL_STACK		LOW_LEVEL_SRAM_STACK
+
+#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_SYS_SPL_BSS_START_ADDR	0x80000000
+#define CONFIG_SYS_SPL_BSS_MAX_SIZE		0x80000		/* 512 KB */
+
 #endif /* __CONFIG_H */
spl/board/ti/panda/Makefile new file +219 -0

219 lines not on this page · raw message

Signature · 1 line
1.7.0.4
author
#37 lore raw

cover U-Boot MMC SPL for OMAP4

In reply to Aneesh V

Hi,

Are there anymore comments on this series?

Quoted 111 lines · Aneesh V

This series adds mmc SPL support for OMAP4. This is essentially an up-streaming effort for TI's x-loader for OMAP4 using the SPL framework

This work partly draws upon previous work done for x-loader by:
Santosh Shilimkar<[email protected]> Rajendra Nayak<[email protected]>
and many others

Features supported:
* Clock init - DPLL locking, clock domains/modules enabling
* SDRAM/DMM initialization
* Mux initialization
* MMC raw read support
* MMC FAT read support

Improvments over x-loader:
* Code completely revamped
* DPLL programming that works for all SYS_CLK frequencies
* Automatic SDRAM identification and initialization
* Board dependent parts(especially mux) deferred to u-boot. So, same SPL will work for Panda and SDP and most likely on any other board that comes along
* Determination of u-boot size to avoid reading extra content while loading U-Boot
* Modular apporach to enable future addition of support for all OMAP3/4 platforms

Aneesh V (21):
omap: add miscellaneous utility macros for bit-field operations
omap4: add OMAP4430 revision check
armv7: start.S: provide a hook for saving boot params
omap4: save parameters passed by ROM code to SPL
arm: new labels in the linker script file
Add generic spl infrastructure
armv7: start.S: add SPL support
omap: add spl support
omap4: add spl support for OMAP4 SDP
omap4: add serial console support to SPL
omap4: utility function to identify the context of hw init
omap4: separate mux settings into essential and non essential parts
omap4: correct mux data for sdp4430
omap4: add clock support
omap4: add sdram init support
omap4: calculate EMIF register values
omap4: automatic sdram detection
armv7: embed u-boot size within u-boot for use from SPL
omap: add MMC support to SPL
omap: spl: add FAT support over MMC
omap4: add spl support for OMAP4 Panda

John Rigby (1):
mkimage: Add OMAP boot image support

  Makefile                                           |   11 +
  arch/arm/cpu/armv7/cpu.c                           |    7 +
  arch/arm/cpu/armv7/omap-common/Makefile            |    1 +
  .../{omap4/lowlevel_init.S =>  omap-common/utils.c} |   58 +-
  arch/arm/cpu/armv7/omap4/Makefile                  |    3 +
  arch/arm/cpu/armv7/omap4/board.c                   |  117 ++-
  arch/arm/cpu/armv7/omap4/clocks.c                  |  717 +++++++++++
  arch/arm/cpu/armv7/omap4/emif.c                    | 1303 ++++++++++++++++++++
  arch/arm/cpu/armv7/omap4/lowlevel_init.S           |   31 +
  arch/arm/cpu/armv7/omap4/omap4_mux_data.h          |   76 ++
  arch/arm/cpu/armv7/omap4/sdram_elpida.c            |  267 ++++
  arch/arm/cpu/armv7/start.S                         |   50 +-
  arch/arm/cpu/armv7/u-boot.lds                      |    4 +
  arch/arm/include/asm/arch-omap4/clocks.h           |  504 ++++++++
  arch/arm/include/asm/arch-omap4/emif.h             | 1021 +++++++++++++++
  arch/arm/include/asm/arch-omap4/omap4.h            |   50 +-
  arch/arm/include/asm/arch-omap4/sys_proto.h        |   60 +-
  .../omap4/lowlevel_init.S =>  include/asm/armv7.h}  |   32 +-
  arch/arm/include/asm/global_data.h                 |    5 +
  arch/arm/include/asm/omap_common.h                 |  106 ++
  board/ti/panda/panda.c                             |   25 +-
  board/ti/{sdp4430/sdp.h =>  panda/panda_mux_data.h} |   76 +-
  board/ti/sdp4430/config.mk                         |    3 +-
  board/ti/sdp4430/sdp.c                             |   25 +-
  .../{panda/panda.h =>  sdp4430/sdp4430_mux_data.h}  |  128 +--
  common/image.c                                     |    1 +
  include/configs/omap4_panda.h                      |   24 +
  include/configs/omap4_sdp4430.h                    |   24 +
  include/image.h                                    |    1 +
  spl/board/ti/panda/Makefile                        |  219 ++++
  spl/board/ti/sdp4430/Makefile                      |  219 ++++
  spl/board/ti/spl-omap.c                            |  189 +++
  .../armv7/u-boot.lds =>  spl/board/ti/spl-omap.lds  |   70 +-
  tools/Makefile                                     |    2 +
  tools/mkimage.c                                    |    2 +
  tools/mkimage.h                                    |    1 +
  tools/omapimage.c                                  |  229 ++++
  .../omap4/lowlevel_init.S =>  tools/omapimage.h     |   49 +-
  38 files changed, 5390 insertions(+), 320 deletions(-)

copy arch/arm/cpu/armv7/{omap4/lowlevel_init.S => omap-common/utils.c} (50%) create mode 100644 arch/arm/cpu/armv7/omap4/clocks.c
create mode 100644 arch/arm/cpu/armv7/omap4/emif.c
create mode 100644 arch/arm/cpu/armv7/omap4/omap4_mux_data.h create mode 100644 arch/arm/cpu/armv7/omap4/sdram_elpida.c create mode 100644 arch/arm/include/asm/arch-omap4/clocks.h create mode 100644 arch/arm/include/asm/arch-omap4/emif.h
copy arch/arm/{cpu/armv7/omap4/lowlevel_init.S => include/asm/armv7.h} (62%) create mode 100644 arch/arm/include/asm/omap_common.h
rename board/ti/{sdp4430/sdp.h => panda/panda_mux_data.h} (76%) rename board/ti/{panda/panda.h => sdp4430/sdp4430_mux_data.h} (67%) create mode 100644 spl/board/ti/panda/Makefile
create mode 100644 spl/board/ti/sdp4430/Makefile
create mode 100644 spl/board/ti/spl-omap.c
copy arch/arm/cpu/armv7/u-boot.lds => spl/board/ti/spl-omap.lds (57%) create mode 100644 tools/omapimage.c
copy arch/arm/cpu/armv7/omap4/lowlevel_init.S => tools/omapimage.h (53%)

#38 lore raw

cover U-Boot MMC SPL for OMAP4

Hi,
1. Please change spl directory name to mmc_spl in line with nand_spl. regards,
chander

Quoted 126 lines · Aneesh V

Hi,

Are there anymore comments on this series?

Quoted 54 lines · Aneesh V

This series adds mmc SPL support for OMAP4. This is essentially an up-streaming effort for TI's x-loader for OMAP4 using the SPL framework

This work partly draws upon previous work done for x-loader by:
Santosh Shilimkar<[email protected]> Rajendra Nayak<[email protected]>
and many others

Features supported:
* Clock init - DPLL locking, clock domains/modules enabling
* SDRAM/DMM initialization
* Mux initialization
* MMC raw read support
* MMC FAT read support

Improvments over x-loader:
* Code completely revamped
* DPLL programming that works for all SYS_CLK frequencies
* Automatic SDRAM identification and initialization
* Board dependent parts(especially mux) deferred to u-boot. So, same SPL will work for Panda and SDP and most likely on any other board that comes along
* Determination of u-boot size to avoid reading extra content while loading U-Boot
* Modular apporach to enable future addition of support for all OMAP3/4 platforms

Aneesh V (21):
omap: add miscellaneous utility macros for bit-field operations
omap4: add OMAP4430 revision check
armv7: start.S: provide a hook for saving boot params
omap4: save parameters passed by ROM code to SPL
arm: new labels in the linker script file
Add generic spl infrastructure
armv7: start.S: add SPL support
omap: add spl support
omap4: add spl support for OMAP4 SDP
omap4: add serial console support to SPL
omap4: utility function to identify the context of hw init
omap4: separate mux settings into essential and non essential parts
omap4: correct mux data for sdp4430
omap4: add clock support
omap4: add sdram init support
omap4: calculate EMIF register values
omap4: automatic sdram detection
armv7: embed u-boot size within u-boot for use from SPL
omap: add MMC support to SPL
omap: spl: add FAT support over MMC
omap4: add spl support for OMAP4 Panda

John Rigby (1):
mkimage: Add OMAP boot image support

Quoted 8 lines
  Makefile                                           |   11 +
  arch/arm/cpu/armv7/cpu.c                           |    7 +
  arch/arm/cpu/armv7/omap-common/Makefile            |    1 +
  .../{omap4/lowlevel_init.S =>  omap-common/utils.c} |   58 +-
  arch/arm/cpu/armv7/omap4/Makefile                  |    3 +
  arch/arm/cpu/armv7/omap4/board.c                   |  117 ++-
  arch/arm/cpu/armv7/omap4/clocks.c                  |  717 +++++++++++
  arch/arm/cpu/armv7/omap4/emif.c                    | 1303

++++++++++++++++++++

Quoted 7 lines
  arch/arm/cpu/armv7/omap4/lowlevel_init.S           |   31 +
  arch/arm/cpu/armv7/omap4/omap4_mux_data.h          |   76 ++
  arch/arm/cpu/armv7/omap4/sdram_elpida.c            |  267 ++++
  arch/arm/cpu/armv7/start.S                         |   50 +-
  arch/arm/cpu/armv7/u-boot.lds                      |    4 +
  arch/arm/include/asm/arch-omap4/clocks.h           |  504 ++++++++
  arch/arm/include/asm/arch-omap4/emif.h             | 1021

+++++++++++++++

Quoted 24 lines
  arch/arm/include/asm/arch-omap4/omap4.h            |   50 +-
  arch/arm/include/asm/arch-omap4/sys_proto.h        |   60 +-
  .../omap4/lowlevel_init.S =>  include/asm/armv7.h}  |   32 +-
  arch/arm/include/asm/global_data.h                 |    5 +
  arch/arm/include/asm/omap_common.h                 |  106 ++
  board/ti/panda/panda.c                             |   25 +-
  board/ti/{sdp4430/sdp.h =>  panda/panda_mux_data.h} |   76 +-
  board/ti/sdp4430/config.mk                         |    3 +-
  board/ti/sdp4430/sdp.c                             |   25 +-
  .../{panda/panda.h =>  sdp4430/sdp4430_mux_data.h}  |  128 +--
  common/image.c                                     |    1 +
  include/configs/omap4_panda.h                      |   24 +
  include/configs/omap4_sdp4430.h                    |   24 +
  include/image.h                                    |    1 +
  spl/board/ti/panda/Makefile                        |  219 ++++
  spl/board/ti/sdp4430/Makefile                      |  219 ++++
  spl/board/ti/spl-omap.c                            |  189 +++
  .../armv7/u-boot.lds =>  spl/board/ti/spl-omap.lds  |   70 +-
  tools/Makefile                                     |    2 +
  tools/mkimage.c                                    |    2 +
  tools/mkimage.h                                    |    1 +
  tools/omapimage.c                                  |  229 ++++
  .../omap4/lowlevel_init.S =>  tools/omapimage.h     |   49 +-
  38 files changed, 5390 insertions(+), 320 deletions(-)
Quoted 1 line

copy arch/arm/cpu/armv7/{omap4/lowlevel_init.S => omap-common/utils.c}

(50%)

Quoted 7 lines

create mode 100644 arch/arm/cpu/armv7/omap4/clocks.c
create mode 100644 arch/arm/cpu/armv7/omap4/emif.c
create mode 100644 arch/arm/cpu/armv7/omap4/omap4_mux_data.h create mode 100644 arch/arm/cpu/armv7/omap4/sdram_elpida.c create mode 100644 arch/arm/include/asm/arch-omap4/clocks.h create mode 100644 arch/arm/include/asm/arch-omap4/emif.h copy arch/arm/{cpu/armv7/omap4/lowlevel_init.S => include/asm/armv7.h}

(62%)

Quoted 9 lines

create mode 100644 arch/arm/include/asm/omap_common.h rename board/ti/{sdp4430/sdp.h => panda/panda_mux_data.h} (76%) rename board/ti/{panda/panda.h => sdp4430/sdp4430_mux_data.h} (67%) create mode 100644 spl/board/ti/panda/Makefile
create mode 100644 spl/board/ti/sdp4430/Makefile
create mode 100644 spl/board/ti/spl-omap.c
copy arch/arm/cpu/armv7/u-boot.lds => spl/board/ti/spl-omap.lds (57%) create mode 100644 tools/omapimage.c
copy arch/arm/cpu/armv7/omap4/lowlevel_init.S => tools/omapimage.h

(53%)

Quoted 1 line

_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Signature · 4 lines
thanks and regards,
Chander M. Kashyap
Contact Number: +919740798700
------- TENSION LENE KA NAHI, DENE KE-----
author
#39 lore raw

cover U-Boot MMC SPL for OMAP4

Chander,

Quoted 4 lines · Chander M. Kashyap

Hi,
1. Please change spl directory name to mmc_spl in line with nand_spl. regards,
chander

Please have a look at the commit message of 07/22.
This is done intentionally to be generic enough to be used for any media. We intend to add NAND support to the same SPL for OMAP3/4. You can potentially have the same SPL support MMC *and* NAND. Where it loads the U-Boot from will depend on a switch setting on the board.

best regards,
Aneesh

Quoted 147 lines

On Mon, Mar 21, 2011 at 1:51 PM, Aneesh V <[email protected] <mailto:[email protected]>> wrote:

Hi,

Are there anymore comments on this series?

On Monday 28 February 2011 05:16 PM, Aneesh V wrote:
> This series adds mmc SPL support for OMAP4. This is essentially > an up-streaming effort for TI's x-loader for OMAP4 using the SPL > framework
>
> This work partly draws upon previous work done for x-loader by:
> Santosh Shilimkar<[email protected]
<mailto:[email protected]>>
> Rajendra Nayak<rnayak at ti.com <mailto:[email protected]>>
> and many others
>
> Features supported:
> * Clock init - DPLL locking, clock domains/modules enabling > * SDRAM/DMM initialization
> * Mux initialization
> * MMC raw read support
> * MMC FAT read support
>
> Improvments over x-loader:
> * Code completely revamped
> * DPLL programming that works for all SYS_CLK frequencies > * Automatic SDRAM identification and initialization
> * Board dependent parts(especially mux) deferred to u-boot. So, same
> SPL will work for Panda and SDP and most likely on any other board
> that comes along
> * Determination of u-boot size to avoid reading extra content while
> loading U-Boot
> * Modular apporach to enable future addition of support for all
OMAP3/4
> platforms
>
> Aneesh V (21):
> omap: add miscellaneous utility macros for bit-field operations
> omap4: add OMAP4430 revision check
> armv7: start.S: provide a hook for saving boot params
> omap4: save parameters passed by ROM code to SPL
> arm: new labels in the linker script file
> Add generic spl infrastructure
> armv7: start.S: add SPL support
> omap: add spl support
> omap4: add spl support for OMAP4 SDP
> omap4: add serial console support to SPL
> omap4: utility function to identify the context of hw init
> omap4: separate mux settings into essential and non essential
parts
> omap4: correct mux data for sdp4430
> omap4: add clock support
> omap4: add sdram init support
> omap4: calculate EMIF register values
> omap4: automatic sdram detection
> armv7: embed u-boot size within u-boot for use from SPL
> omap: add MMC support to SPL
> omap: spl: add FAT support over MMC
> omap4: add spl support for OMAP4 Panda
>
> John Rigby (1):
> mkimage: Add OMAP boot image support
>
> Makefile | 11 +
> arch/arm/cpu/armv7/cpu.c | 7 +
> arch/arm/cpu/armv7/omap-common/Makefile | 1 +
> .../{omap4/lowlevel_init.S => omap-common/utils.c} | 58 +-
> arch/arm/cpu/armv7/omap4/Makefile | 3 +
> arch/arm/cpu/armv7/omap4/board.c | 117 ++-
> arch/arm/cpu/armv7/omap4/clocks.c | 717
+++++++++++
> arch/arm/cpu/armv7/omap4/emif.c | 1303
++++++++++++++++++++
> arch/arm/cpu/armv7/omap4/lowlevel_init.S | 31 +
> arch/arm/cpu/armv7/omap4/omap4_mux_data.h | 76 ++
> arch/arm/cpu/armv7/omap4/sdram_elpida.c | 267 ++++
> arch/arm/cpu/armv7/start.S | 50 +-
> arch/arm/cpu/armv7/u-boot.lds | 4 +
> arch/arm/include/asm/arch-omap4/clocks.h | 504 ++++++++
> arch/arm/include/asm/arch-omap4/emif.h | 1021
+++++++++++++++
> arch/arm/include/asm/arch-omap4/omap4.h | 50 +-
> arch/arm/include/asm/arch-omap4/sys_proto.h | 60 +-
> .../omap4/lowlevel_init.S => include/asm/armv7.h} | 32 +-
> arch/arm/include/asm/global_data.h | 5 +
> arch/arm/include/asm/omap_common.h | 106 ++
> board/ti/panda/panda.c | 25 +-
> board/ti/{sdp4430/sdp.h => panda/panda_mux_data.h} | 76 +-
> board/ti/sdp4430/config.mk <http://config.mk>
| 3 +-
> board/ti/sdp4430/sdp.c | 25 +-
> .../{panda/panda.h => sdp4430/sdp4430_mux_data.h} | 128 +--
> common/image.c | 1 +
> include/configs/omap4_panda.h | 24 +
> include/configs/omap4_sdp4430.h | 24 +
> include/image.h | 1 +
> spl/board/ti/panda/Makefile | 219 ++++
> spl/board/ti/sdp4430/Makefile | 219 ++++
> spl/board/ti/spl-omap.c | 189 +++
> .../armv7/u-boot.lds => spl/board/ti/spl-omap.lds | 70 +-
> tools/Makefile | 2 +
> tools/mkimage.c | 2 +
> tools/mkimage.h | 1 +
> tools/omapimage.c | 229 ++++
> .../omap4/lowlevel_init.S => tools/omapimage.h | 49 +-
> 38 files changed, 5390 insertions(+), 320 deletions(-)
> copy arch/arm/cpu/armv7/{omap4/lowlevel_init.S =>
omap-common/utils.c} (50%)
> create mode 100644 arch/arm/cpu/armv7/omap4/clocks.c
> create mode 100644 arch/arm/cpu/armv7/omap4/emif.c
> create mode 100644 arch/arm/cpu/armv7/omap4/omap4_mux_data.h
> create mode 100644 arch/arm/cpu/armv7/omap4/sdram_elpida.c
> create mode 100644 arch/arm/include/asm/arch-omap4/clocks.h
> create mode 100644 arch/arm/include/asm/arch-omap4/emif.h
> copy arch/arm/{cpu/armv7/omap4/lowlevel_init.S =>
include/asm/armv7.h} (62%)
> create mode 100644 arch/arm/include/asm/omap_common.h
> rename board/ti/{sdp4430/sdp.h => panda/panda_mux_data.h} (76%)
> rename board/ti/{panda/panda.h => sdp4430/sdp4430_mux_data.h}
(67%)
> create mode 100644 spl/board/ti/panda/Makefile
> create mode 100644 spl/board/ti/sdp4430/Makefile
> create mode 100644 spl/board/ti/spl-omap.c
> copy arch/arm/cpu/armv7/u-boot.lds =>
spl/board/ti/spl-omap.lds (57%)
> create mode 100644 tools/omapimage.c
> copy arch/arm/cpu/armv7/omap4/lowlevel_init.S =>
tools/omapimage.h (53%)
>
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de <mailto:[email protected]>
http://lists.denx.de/mailman/listinfo/u-boot

--
thanks and regards,
Chander M. Kashyap
Contact Number: +919740798700
------- TENSION LENE KA NAHI, DENE KE-----

author
#40 lore raw

v2 cover U-Boot MMC SPL for OMAP4

In reply to Aneesh V

This series adds mmc SPL support for OMAP4. This is essentially an up-streaming effort for TI's x-loader for OMAP4 using the SPL framework

This work partly draws upon previous work done for x-loader by:
Santosh Shilimkar <[email protected]> Rajendra Nayak <[email protected]>
and many others

This series is depedent on the following series:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/95550

Features supported:
* Clock init - DPLL locking, clock domains/modules enabling
* SDRAM/DMM initialization
* Mux initialization
* MMC raw read support
* MMC FAT read support

Improvments over x-loader:
* Code completely revamped
* DPLL programming that works for all SYS_CLK frequencies
* Automatic SDRAM identification and initialization
* Board dependent parts(especially mux) deferred to u-boot. So, same SPL will work for Panda and SDP and most likely on any other board that comes along
* Determination of u-boot size to avoid reading extra content while loading U-Boot
* Modular apporach to enable future addition of support for all OMAP3/4 platforms

V2:
* Some fixes in SDRAM init, clock init
* Use of pre-calculated M & N values for DPLL locking instead run-time calculation
* Change in make files to allow reuse of common rules between boards
* Console initialization moved further earlier in the boot allowing traces from even clock initialization code
* Reuse utility macros from a previous series

Aneesh V (21):
omap4: add OMAP4430 revision check
armv7: start.S: provide a hook for saving boot params
omap4: save parameters passed by ROM code to SPL
arm: new labels in the linker script file
Add generic spl infrastructure
armv7: start.S: add SPL support
omap: add spl support
omap4: add spl support for OMAP4 SDP
omap4: utility function to identify the context of hw init
omap4: separate mux settings into essential and non essential parts
omap4: correct mux data for sdp4430
omap4: add clock support
omap4: add serial console support to SPL
omap4: add sdram init support
omap4: calculate EMIF register values
omap4: automatic sdram detection
armv7: embed u-boot size within u-boot for use from SPL
omap: add MMC support to SPL
omap: spl: add FAT support over MMC
omap4: add spl support for OMAP4 Panda
omap: spl: add more debug traces

John Rigby (1):
mkimage: Add OMAP boot image support

 Makefile                                           |   24 +
 arch/arm/cpu/armv7/cpu.c                           |    7 +
 arch/arm/cpu/armv7/omap-common/Makefile            |    1 +
 .../{omap4/lowlevel_init.S => omap-common/utils.c} |   76 +-
 arch/arm/cpu/armv7/omap4/Makefile                  |    3 +
 arch/arm/cpu/armv7/omap4/board.c                   |  140 ++-
 arch/arm/cpu/armv7/omap4/clocks.c                  |  764 +++++++++++
 arch/arm/cpu/armv7/omap4/clocks_get_m_n.c          |  154 +++
 arch/arm/cpu/armv7/omap4/emif.c                    | 1340 ++++++++++++++++++++
 arch/arm/cpu/armv7/omap4/lowlevel_init.S           |   31 +
 arch/arm/cpu/armv7/omap4/omap4_mux_data.h          |   76 ++
 arch/arm/cpu/armv7/omap4/sdram_elpida.c            |  267 ++++
 arch/arm/cpu/armv7/start.S                         |   50 +-
 arch/arm/cpu/armv7/u-boot.lds                      |    2 +
 arch/arm/include/asm/arch-omap4/clocks.h           |  506 ++++++++
 arch/arm/include/asm/arch-omap4/emif.h             | 1021 +++++++++++++++
 arch/arm/include/asm/arch-omap4/omap4.h            |   50 +-
 arch/arm/include/asm/arch-omap4/sys_proto.h        |   62 +-
 arch/arm/include/asm/armv7.h                       |    6 +-
 arch/arm/include/asm/global_data.h                 |    5 +
 arch/arm/include/asm/omap_common.h                 |   62 +
 arch/arm/include/asm/utils.h                       |    6 +
 board/ti/panda/panda.c                             |   25 +-
 board/ti/{sdp4430/sdp.h => panda/panda_mux_data.h} |   76 +-
 board/ti/sdp4430/config.mk                         |    3 +-
 board/ti/sdp4430/sdp.c                             |   25 +-
 .../{panda/panda.h => sdp4430/sdp4430_mux_data.h}  |  128 +--
 common/image.c                                     |    1 +
 include/configs/omap4_panda.h                      |   24 +
 include/configs/omap4_sdp4430.h                    |   24 +
 include/image.h                                    |    1 +
 spl/board/ti/omap4.mk                              |  176 +++
 .../config.mk => spl/board/ti/panda/Makefile       |   21 +-
 spl/board/ti/rules-omap.mk                         |   74 ++
 .../config.mk => spl/board/ti/sdp4430/Makefile     |   21 +-
 spl/board/ti/spl-omap.c                            |  206 +++
 .../armv7/u-boot.lds => spl/board/ti/spl-omap.lds  |   69 +-
 tools/Makefile                                     |    2 +
 tools/mkimage.c                                    |    2 +
 tools/mkimage.h                                    |    1 +
 tools/omapimage.c                                  |  229 ++++
 tools/omapimage.h                                  |   50 +
 42 files changed, 5498 insertions(+), 313 deletions(-)
 copy arch/arm/cpu/armv7/{omap4/lowlevel_init.S => omap-common/utils.c} (50%)
 create mode 100644 arch/arm/cpu/armv7/omap4/clocks.c
 create mode 100644 arch/arm/cpu/armv7/omap4/clocks_get_m_n.c
 create mode 100644 arch/arm/cpu/armv7/omap4/emif.c
 create mode 100644 arch/arm/cpu/armv7/omap4/omap4_mux_data.h
 create mode 100644 arch/arm/cpu/armv7/omap4/sdram_elpida.c
 create mode 100644 arch/arm/include/asm/arch-omap4/clocks.h
 create mode 100644 arch/arm/include/asm/arch-omap4/emif.h
 create mode 100644 arch/arm/include/asm/omap_common.h
 rename board/ti/{sdp4430/sdp.h => panda/panda_mux_data.h} (76%)
 rename board/ti/{panda/panda.h => sdp4430/sdp4430_mux_data.h} (67%)
 create mode 100644 spl/board/ti/omap4.mk
 copy board/ti/sdp4430/config.mk => spl/board/ti/panda/Makefile (63%)
 create mode 100644 spl/board/ti/rules-omap.mk
 copy board/ti/sdp4430/config.mk => spl/board/ti/sdp4430/Makefile (63%)
 create mode 100644 spl/board/ti/spl-omap.c
 copy arch/arm/cpu/armv7/u-boot.lds => spl/board/ti/spl-omap.lds (57%)
 create mode 100644 tools/omapimage.c
 create mode 100644 tools/omapimage.h
author
#41 lore raw

v2 cover U-Boot MMC SPL for OMAP4

Dear Wolfgang,

Quoted 64 lines · Aneesh V

This series adds mmc SPL support for OMAP4. This is essentially an up-streaming effort for TI's x-loader for OMAP4 using the SPL framework

This work partly draws upon previous work done for x-loader by:
Santosh Shilimkar<[email protected]> Rajendra Nayak<[email protected]>
and many others

This series is depedent on the following series:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/95550

Features supported:
* Clock init - DPLL locking, clock domains/modules enabling
* SDRAM/DMM initialization
* Mux initialization
* MMC raw read support
* MMC FAT read support

Improvments over x-loader:
* Code completely revamped
* DPLL programming that works for all SYS_CLK frequencies
* Automatic SDRAM identification and initialization
* Board dependent parts(especially mux) deferred to u-boot. So, same SPL will work for Panda and SDP and most likely on any other board that comes along
* Determination of u-boot size to avoid reading extra content while loading U-Boot
* Modular apporach to enable future addition of support for all OMAP3/4 platforms

V2:
* Some fixes in SDRAM init, clock init
* Use of pre-calculated M& N values for DPLL locking instead run-time calculation
* Change in make files to allow reuse of common rules between boards
* Console initialization moved further earlier in the boot allowing traces from even clock initialization code
* Reuse utility macros from a previous series

Aneesh V (21):
omap4: add OMAP4430 revision check
armv7: start.S: provide a hook for saving boot params
omap4: save parameters passed by ROM code to SPL
arm: new labels in the linker script file
Add generic spl infrastructure
armv7: start.S: add SPL support
omap: add spl support
omap4: add spl support for OMAP4 SDP
omap4: utility function to identify the context of hw init
omap4: separate mux settings into essential and non essential parts
omap4: correct mux data for sdp4430
omap4: add clock support
omap4: add serial console support to SPL
omap4: add sdram init support
omap4: calculate EMIF register values
omap4: automatic sdram detection
armv7: embed u-boot size within u-boot for use from SPL
omap: add MMC support to SPL
omap: spl: add FAT support over MMC
omap4: add spl support for OMAP4 Panda
omap: spl: add more debug traces

Quoted 3 lines

John Rigby (1):
mkimage: Add OMAP boot image support

This work has mainly two parts:
1. Add the missing hardware support for OMAP4 such as clock init, sdram init etc (OMAP4 u-boot worked without these because it was always prececeded by x-loader)
2. Addd SPL support.

Now that SPL framework design is taking time, I was wondering whether I should split the series into two based on the two main tasks above.

That is, I can send out the hw initialization part immediately without waiting for the SPL design to be finalized and send out the SPL support once we concluded the SPL design discussions.

The patches themselves will not change much. Just that they will be separated into two different series. The reviews done so far will not be wasted.

Are you Ok with this approach?

best regards,
Aneesh

author
#42 lore raw

PATCH v2 1/22 mkimage: Add OMAP boot image support

In reply to Aneesh V

From: John Rigby <[email protected]>

---
 common/image.c    |    1 +
 include/image.h   |    1 +
 tools/Makefile    |    2 +
 tools/mkimage.c   |    2 +
 tools/mkimage.h   |    1 +
 tools/omapimage.c |  229 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 tools/omapimage.h |   50 ++++++++++++
 7 files changed, 286 insertions(+), 0 deletions(-)
 create mode 100644 tools/omapimage.c
 create mode 100644 tools/omapimage.h
common/image.c +1 -0
index e542a57..7f6fe1c 100644
@@ -141,6 +141,7 @@ static const table_entry_t uimage_type[] = {
 	{	IH_TYPE_FLATDT,     "flat_dt",    "Flat Device Tree",	},
 	{	IH_TYPE_KWBIMAGE,   "kwbimage",   "Kirkwood Boot Image",},
 	{	IH_TYPE_IMXIMAGE,   "imximage",   "Freescale i.MX Boot Image",},
+	{	IH_TYPE_OMAPIMAGE,  "omapimage",  "TI OMAP CH/GP Boot Image",},
 	{	-1,		    "",		  "",			},
 };
 
include/image.h +1 -0
index c31e862..c606644 100644
@@ -157,6 +157,7 @@
 #define IH_TYPE_FLATDT		8	/* Binary Flat Device Tree Blob	*/
 #define IH_TYPE_KWBIMAGE	9	/* Kirkwood Boot Image		*/
 #define IH_TYPE_IMXIMAGE	10	/* Freescale IMXBoot Image	*/
+#define IH_TYPE_OMAPIMAGE	11	/* TI OMAP Config Header Image	*/
 
 /*
  * Compression Types
tools/Makefile +2 -0
index 623f908..a1c4ed7 100644
@@ -84,6 +84,7 @@ OBJ_FILES-$(CONFIG_CMD_LOADS) += img2srec.o
 OBJ_FILES-$(CONFIG_INCA_IP) += inca-swap-bytes.o
 NOPED_OBJ_FILES-y += kwbimage.o
 NOPED_OBJ_FILES-y += imximage.o
+NOPED_OBJ_FILES-y += omapimage.o
 NOPED_OBJ_FILES-y += mkimage.o
 OBJ_FILES-$(CONFIG_NETCONSOLE) += ncb.o
 NOPED_OBJ_FILES-y += os_support.o
@@ -180,6 +181,7 @@ $(obj)mkimage$(SFX):	$(obj)crc32.o \
 			$(obj)fit_image.o \
 			$(obj)image.o \
 			$(obj)imximage.o \
+			$(obj)omapimage.o \
 			$(obj)kwbimage.o \
 			$(obj)md5.o \
 			$(obj)mkimage.o \
tools/mkimage.c +2 -0
index 60f7263..b6a7cb7 100644
@@ -156,6 +156,8 @@ main (int argc, char **argv)
 	init_imx_image_type ();
 	/* Init FIT image generation/list support */
 	init_fit_image_type ();
+	/* Init TI OMAP Boot image generation/list support */
+	init_omap_image_type();
 	/* Init Default image generation/list support */
 	init_default_image_type ();
 
tools/mkimage.h +1 -0
index 9033a7d..3b49645 100644
@@ -143,5 +143,6 @@ void init_kwb_image_type (void);
 void init_imx_image_type (void);
 void init_default_image_type (void);
 void init_fit_image_type (void);
+void init_omap_image_type(void);
 
 #endif /* _MKIIMAGE_H_ */
tools/omapimage.c new file +229 -0

229 lines not on this page · raw message

tools/omapimage.h new file +50 -0

50 lines not on this page · raw message

Signature · 1 line
1.7.0.4
#43 lore raw

PATCH v2 1/22 mkimage: Add OMAP boot image support

Dear Aneesh V,

Quoted 20 lines · In message <[email protected]> you wrote:

From: John Rigby <[email protected]>

---
 common/image.c    |    1 +
 include/image.h   |    1 +
 tools/Makefile    |    2 +
 tools/mkimage.c   |    2 +
 tools/mkimage.h   |    1 +
 tools/omapimage.c |  229 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 tools/omapimage.h |   50 ++++++++++++
 7 files changed, 286 insertions(+), 0 deletions(-)
 create mode 100644 tools/omapimage.c
 create mode 100644 tools/omapimage.h
common/image.c +0 -0
index e542a57..7f6fe1c 100644

common/image.c static const table_entry_t uimage_type[] = { · line 145

Quoted 5 lines
common/image.c +1 -0
@@ -141,6 +141,7 @@ static const table_entry_t uimage_type[] = {
 	{	IH_TYPE_FLATDT,     "flat_dt",    "Flat Device Tree",	},
 	{	IH_TYPE_KWBIMAGE,   "kwbimage",   "Kirkwood Boot Image",},
 	{	IH_TYPE_IMXIMAGE,   "imximage",   "Freescale i.MX Boot Image",},
+	{	IH_TYPE_OMAPIMAGE,  "omapimage",  "TI OMAP CH/GP Boot Image",},
 	{	-1,		    "",		  "",			},

Please keep list sorted / sort list.

Quoted 13 lines
tools/Makefile +1 -0
index 623f908..a1c4ed7 100644
@@ -84,6 +84,7 @@ OBJ_FILES-$(CONFIG_CMD_LOADS) += img2srec.o
 OBJ_FILES-$(CONFIG_INCA_IP) += inca-swap-bytes.o
 NOPED_OBJ_FILES-y += kwbimage.o
 NOPED_OBJ_FILES-y += imximage.o
+NOPED_OBJ_FILES-y += omapimage.o
 NOPED_OBJ_FILES-y += mkimage.o
 OBJ_FILES-$(CONFIG_NETCONSOLE) += ncb.o
 NOPED_OBJ_FILES-y += os_support.o

tools/Makefile $(obj)mkimage$(SFX): $(obj)crc32.o \ · line 187

Quoted 7 lines
tools/Makefile +1 -0
@@ -180,6 +181,7 @@ $(obj)mkimage$(SFX):	$(obj)crc32.o \
 			$(obj)fit_image.o \
 			$(obj)image.o \
 			$(obj)imximage.o \
+			$(obj)omapimage.o \
 			$(obj)kwbimage.o \
 			$(obj)md5.o \
 			$(obj)mkimage.o \

Please keep lists sorted.

Quoted 45 lines
tools/omapimage.c new file +42 -0
@@ -0,0 +1,229 @@
+/*
+ * (C) Copyright 2010
+ * Linaro LTD, www.linaro.org
+ * Author: John Rigby <[email protected]>
+ * Based on TI's signGP.c
+ *
+ * (C) Copyright 2009
+ * Stefano Babic, DENX Software Engineering, sbabic at denx.de.
+ *
+ * (C) Copyright 2008
+ * Marvell Semiconductor <www.marvell.com>
+ * Written-by: Prafulla Wadaskar <[email protected]>
+ *
+ * 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
+ */
+
+/* Required to obtain the getline prototype from stdio.h */
+#define _GNU_SOURCE
+
+#include "mkimage.h"
+#include <image.h>
+#include "omapimage.h"
+
+/* Header size is CH header rounded up to 512 bytes plus GP header */
+#define OMAP_CH_HDR_SIZE 512
+#define OMAP_GP_HDR_SIZE (sizeof(struct gp_header))

tools/omapimage.c line 52

Quoted 10 lines
tools/omapimage.c new file +10 -0
+#define OMAP_FILE_HDR_SIZE (OMAP_CH_HDR_SIZE+OMAP_GP_HDR_SIZE)
+
+static uint8_t omapimage_header[OMAP_FILE_HDR_SIZE];
+
+static int omapimage_check_image_types(uint8_t type)
+{
+	if (type == IH_TYPE_OMAPIMAGE)
+		return EXIT_SUCCESS;
+	else
+		return EXIT_FAILURE;

Maybe an error message would be helpful?

Quoted 17 lines
tools/omapimage.c new file +17 -0
+static void omapimage_print_section(struct ch_settings *chs)
+{
+	switch (chs->section_key) {
+	case KEY_CHSETTINGS:
+		printf("CHSETTINGS (%x) "
+			"valid:%x "
+			"version:%x "
+			"reserved:%x "
+			"flags:%x\n",
+			chs->section_key,
+			chs->valid,
+			chs->version,
+			chs->reserved,
+			chs->flags);
+		break;
+	default:
+		printf("UNKNOWNKEY (%x) "

tools/omapimage.c line 129

Quoted 10 lines
tools/omapimage.c new file +10 -0
+			"valid:%x "
+			"version:%x "
+			"reserved:%x "
+			"flags:%x\n",
+			chs->section_key,
+			chs->valid,
+			chs->version,
+			chs->reserved,
+			chs->flags);
+		break;

How about unifying these cases, and passing "CHSETTINGS" resp. "UNKNOWNKEY" as argument?

...

Quoted 9 lines
tools/omapimage.c new file +9 -0
+struct ch_toc {
+	uint32_t section_offset;
+	uint32_t section_size;
+	uint8_t unused[12];
+	uint8_t section_name[12];
+} __attribute__ ((__packed__));
+
+struct ch_settings {
+	uint32_t section_key;

tools/omapimage.c line 98

Quoted 10 lines
tools/omapimage.c new file +10 -0
+	uint8_t valid;
+	uint8_t version;
+	uint16_t reserved;
+	uint32_t flags;
+} __attribute__ ((__packed__));
+
+struct gp_header {
+	uint32_t size;
+	uint32_t load_addr;
+} __attribute__ ((__packed__));

Is there any good reason to have these "__attribute__ ((__packed__))" here? In general, these are only known to cause trouble and pain, and I cannot see a need here.

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"To IBM, 'open' means there is a modicum  of  interoperability  among
some of their equipment."                            - Harv Masterson
author
#44 lore raw

PATCH v2 1/22 mkimage: Add OMAP boot image support

Hi Wolfgang,

Quoted 18 lines · Wolfgang Denk

Dear Aneesh V,

Quoted 15 lines · In message<[email protected]> you wrote:

From: John Rigby<[email protected]>

---
  common/image.c    |    1 +
  include/image.h   |    1 +
  tools/Makefile    |    2 +
  tools/mkimage.c   |    2 +
  tools/mkimage.h   |    1 +
  tools/omapimage.c |  229 +++++++++++++++++++++++++++++++++++++++++++++++++++++
  tools/omapimage.h |   50 ++++++++++++
  7 files changed, 286 insertions(+), 0 deletions(-)

create mode 100644 tools/omapimage.c
create mode 100644 tools/omapimage.h

Quoted 12 lines

common/image.c static const table_entry_t uimage_type[] = { · line 145

Quoted 10 lines
common/image.c +1 -0
index e542a57..7f6fe1c 100644
@@ -141,6 +141,7 @@ static const table_entry_t uimage_type[] = {
  	{	IH_TYPE_FLATDT,     "flat_dt",    "Flat Device Tree",	},
  	{	IH_TYPE_KWBIMAGE,   "kwbimage",   "Kirkwood Boot Image",},
  	{	IH_TYPE_IMXIMAGE,   "imximage",   "Freescale i.MX Boot Image",},
+	{	IH_TYPE_OMAPIMAGE,  "omapimage",  "TI OMAP CH/GP Boot Image",},
  	{	-1,		    "",		  "",			},

Please keep list sorted / sort list.

Sort by the second field(kwbimage, omapimage etc), right?

Quoted 15 lines
Quoted 15 lines
tools/Makefile +1 -0
index 623f908..a1c4ed7 100644
@@ -84,6 +84,7 @@ OBJ_FILES-$(CONFIG_CMD_LOADS) += img2srec.o
  OBJ_FILES-$(CONFIG_INCA_IP) += inca-swap-bytes.o
  NOPED_OBJ_FILES-y += kwbimage.o
  NOPED_OBJ_FILES-y += imximage.o
+NOPED_OBJ_FILES-y += omapimage.o
  NOPED_OBJ_FILES-y += mkimage.o
  OBJ_FILES-$(CONFIG_NETCONSOLE) += ncb.o
  NOPED_OBJ_FILES-y += os_support.o
@@ -180,6 +181,7 @@ $(obj)mkimage$(SFX):	$(obj)crc32.o \
  			$(obj)fit_image.o \
Quoted 8 lines

tools/Makefile $(obj)mkimage$(SFX): $(obj)crc32.o \ · line 187

Quoted 6 lines
tools/Makefile +1 -0
  			$(obj)image.o \
  			$(obj)imximage.o \
+			$(obj)omapimage.o \
  			$(obj)kwbimage.o \
  			$(obj)md5.o \
  			$(obj)mkimage.o \

Please keep lists sorted.

Ok.

Quoted 4 lines
Quoted 4 lines
tools/omapimage.c new file +0 -0
@@ -0,0 +1,229 @@

...

Quoted 15 lines
Quoted 15 lines
tools/omapimage.c new file +15 -0
+struct ch_toc {
+	uint32_t section_offset;
+	uint32_t section_size;
+	uint8_t unused[12];
+	uint8_t section_name[12];
+} __attribute__ ((__packed__));
+
+struct ch_settings {
+	uint32_t section_key;
+	uint8_t valid;
+	uint8_t version;
+	uint16_t reserved;
+	uint32_t flags;
+} __attribute__ ((__packed__));
+
Quoted 8 lines

tools/omapimage.c

Quoted 4 lines
tools/omapimage.c new file +4 -0
+struct gp_header {
+	uint32_t size;
+	uint32_t load_addr;
+} __attribute__ ((__packed__));

Is there any good reason to have these "__attribute__ ((__packed__))" here? In general, these are only known to cause trouble and pain, and I cannot see a need here.

ROM code expects the header in a precise format. I think it will not be safe to leave it to the compiler to decide the field layout. For instance, the compiler may align the uint8_t or uint16_t to 32 bit boundary and that will break the Configuration Header.

Just curious, what are the issues caused by "__packed__"?

Quoted 5 lines

Best regards,

Wolfgang Denk

#45 lore raw

PATCH v2 1/22 mkimage: Add OMAP boot image support

Dear Aneesh V,

Quoted 11 lines · In message <[email protected]> you wrote:
Quoted 9 lines

common/image.c static const table_entry_t uimage_type[] = { · line 145

Quoted 7 lines
common/image.c +1 -0
@@ -141,6 +141,7 @@ static const table_entry_t uimage_type[] = {
  	{	IH_TYPE_FLATDT,     "flat_dt",    "Flat Device Tree",	},
  	{	IH_TYPE_KWBIMAGE,   "kwbimage",   "Kirkwood Boot Image",},
  	{	IH_TYPE_IMXIMAGE,   "imximage",   "Freescale i.MX Boot Image",},
+	{	IH_TYPE_OMAPIMAGE,  "omapimage",  "TI OMAP CH/GP Boot Image",},
  	{	-1,		    "",		  "",			},

Please keep list sorted / sort list.

Sort by the second field(kwbimage, omapimage etc), right?

First field, but the result is the same.

Quoted 24 lines
Quoted 15 lines
Quoted 15 lines
tools/omapimage.h new file +15 -0
+struct ch_toc {
+	uint32_t section_offset;
+	uint32_t section_size;
+	uint8_t unused[12];
+	uint8_t section_name[12];
+} __attribute__ ((__packed__));
+
+struct ch_settings {
+	uint32_t section_key;
+	uint8_t valid;
+	uint8_t version;
+	uint16_t reserved;
+	uint32_t flags;
+} __attribute__ ((__packed__));
+
Quoted 8 lines

tools/omapimage.h line 47

Quoted 4 lines
tools/omapimage.h new file +4 -0
+struct gp_header {
+	uint32_t size;
+	uint32_t load_addr;
+} __attribute__ ((__packed__));

Is there any good reason to have these "__attribute__ ((__packed__))" here? In general, these are only known to cause trouble and pain, and I cannot see a need here.

Quoted 4 lines

ROM code expects the header in a precise format. I think it will not be safe to leave it to the compiler to decide the field layout. For instance, the compiler may align the uint8_t or uint16_t to 32 bit boundary and that will break the Configuration Header.

No. Not in the structs listed above.

Quoted 1 line

Just curious, what are the issues caused by "__packed__"?

For example, 32 bit data may be accessed in 4 8-bit operations which may be fatal when accessing device registers.

Best regards,

Wolfgang Denk

Signature · 4 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
God may be subtle, but He isn't plain mean.         - Albert Einstein
author
#46 lore raw

PATCH v2 1/22 mkimage: Add OMAP boot image support

Hi Wolfgang,

Quoted 2 lines · Wolfgang Denk

Dear Aneesh V,

...

Quoted 25 lines
Quoted 25 lines
Quoted 24 lines
Quoted 10 lines
tools/omapimage.h new file +9 -0
+struct ch_toc {
+	uint32_t section_offset;
+	uint32_t section_size;
+	uint8_t unused[12];
+	uint8_t section_name[12];
+} __attribute__ ((__packed__));
+
+struct ch_settings {
+	uint32_t section_key;

tools/omapimage.h line 47

Quoted 10 lines
tools/omapimage.h new file +10 -0
+	uint8_t valid;
+	uint8_t version;
+	uint16_t reserved;
+	uint32_t flags;
+} __attribute__ ((__packed__));
+
+struct gp_header {
+	uint32_t size;
+	uint32_t load_addr;
+} __attribute__ ((__packed__));

Is there any good reason to have these "__attribute__ ((__packed__))" here? In general, these are only known to cause trouble and pain, and I cannot see a need here.

Quoted 6 lines
Quoted 4 lines

ROM code expects the header in a precise format. I think it will not be safe to leave it to the compiler to decide the field layout. For instance, the compiler may align the uint8_t or uint16_t to 32 bit boundary and that will break the Configuration Header.

No. Not in the structs listed above.

You mean "__packed__" should be removed from "struct gp_header" alone, not from the other structs?

best regards,
Aneesh

#47 lore raw

PATCH v2 1/22 mkimage: Add OMAP boot image support

Dear Aneesh V,

Quoted 3 lines · In message <[email protected]> you wrote:

You mean "__packed__" should be removed from "struct gp_header" alone, not from the other structs?

author
#48 lore raw

PATCH v2 1/22 mkimage: Add OMAP boot image support

In reply to Wolfgang Denk

Hi Wolfgang,

Quoted 41 lines · Wolfgang Denk

Dear Aneesh V,

Quoted 11 lines · In message<[email protected]> you wrote:
Quoted 9 lines

common/image.c static const table_entry_t uimage_type[] = { · line 145

Quoted 7 lines
common/image.c +1 -0
@@ -141,6 +141,7 @@ static const table_entry_t uimage_type[] = {
   	{	IH_TYPE_FLATDT,     "flat_dt",    "Flat Device Tree",	},
   	{	IH_TYPE_KWBIMAGE,   "kwbimage",   "Kirkwood Boot Image",},
   	{	IH_TYPE_IMXIMAGE,   "imximage",   "Freescale i.MX Boot Image",},
+	{	IH_TYPE_OMAPIMAGE,  "omapimage",  "TI OMAP CH/GP Boot Image",},
   	{	-1,		    "",		  "",			},

Please keep list sorted / sort list.

Sort by the second field(kwbimage, omapimage etc), right?

First field, but the result is the same.

Quoted 24 lines
Quoted 23 lines
Quoted 9 lines
tools/omapimage.h new file +9 -0
+struct ch_toc {
+	uint32_t section_offset;
+	uint32_t section_size;
+	uint8_t unused[12];
+	uint8_t section_name[12];
+} __attribute__ ((__packed__));
+
+struct ch_settings {
+	uint32_t section_key;

tools/omapimage.h line 47

Quoted 10 lines
tools/omapimage.h new file +10 -0
+	uint8_t valid;
+	uint8_t version;
+	uint16_t reserved;
+	uint32_t flags;
+} __attribute__ ((__packed__));
+
+struct gp_header {
+	uint32_t size;
+	uint32_t load_addr;
+} __attribute__ ((__packed__));

Is there any good reason to have these "__attribute__ ((__packed__))" here? In general, these are only known to cause trouble and pain, and I cannot see a need here.

Quoted 6 lines
Quoted 4 lines

ROM code expects the header in a precise format. I think it will not be safe to leave it to the compiler to decide the field layout. For instance, the compiler may align the uint8_t or uint16_t to 32 bit boundary and that will break the Configuration Header.

No. Not in the structs listed above.

Why do you think it will not create any problems. For instance, what if the field "uint8_t version" in "struct ch_settings" is aligned to a 32 bit boundary by the compiler for faster access? That is not the intended layout.

best regards,
Aneesh

#49 lore raw

PATCH v2 1/22 mkimage: Add OMAP boot image support

Dear Aneesh V,

Quoted 20 lines · In message <[email protected]> you wrote:
Quoted 20 lines
Quoted 20 lines
Quoted 20 lines
Quoted 20 lines
tools/omapimage.h new file +19 -0
+struct ch_toc {
+	uint32_t section_offset;
+	uint32_t section_size;
+	uint8_t unused[12];
+	uint8_t section_name[12];
+} __attribute__ ((__packed__));
+
+struct ch_settings {
+	uint32_t section_key;
+	uint8_t valid;
+	uint8_t version;
+	uint16_t reserved;
+	uint32_t flags;
+} __attribute__ ((__packed__));
+
+struct gp_header {
+	uint32_t size;
+	uint32_t load_addr;
+} __attribute__ ((__packed__));

...

Quoted 6 lines
Quoted 1 line

No. Not in the structs listed above.

Why do you think it will not create any problems. For instance, what if the field "uint8_t version" in "struct ch_settings" is aligned to a 32 bit boundary by the compiler for faster access? That is not the intended layout.

If the compiler did such a thing, this would indeed be bad. But I have never seen a compiler doing this, nor is there a reason to do so. The naturla alignment requirement for a uint8_t is a byte; ther eis no need to align it on 4 byte boundary.

Best regards,

Wolfgang Denk

Signature · 6 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Man is the best computer we can put aboard a spacecraft ...  and  the
only one that can be mass produced with unskilled labor.
                                                  - Wernher von Braun
#50 lore raw

PATCH v2 1/22 mkimage: Add OMAP boot image support

In reply to Aneesh V

tools/omapimage.c line 135

Quoted 3 lines · On Sunday, May 15, 2011 11:21:19 Aneesh V wrote:
tools/omapimage.c new file +3 -0
+static void omapimage_print_header(const void *ptr)
+{
+	struct ch_toc *toc = (struct ch_toc *)ptr;

you're casting away the void. something is fundamentally broken here. -mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110515/5079421d/attachment.pgp

#51 lore raw

PATCH v2 1/22 mkimage: Add OMAP boot image support

Quoted 6 lines · On Sunday, May 15, 2011 21:52:53 Mike Frysinger wrote:

tools/omapimage.c line 135

Quoted 3 lines · On Sunday, May 15, 2011 11:21:19 Aneesh V wrote:
tools/omapimage.c new file +3 -0
+static void omapimage_print_header(const void *ptr)
+{
+	struct ch_toc *toc = (struct ch_toc *)ptr;

you're casting away the void. something is fundamentally broken here.

err, obviously i meant "const" instead of "void" ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110515/729cd7d2/attachment.pgp

author
#52 lore raw

PATCH v2 1/22 mkimage: Add OMAP boot image support

Hi Mike,

Quoted 10 lines · Mike Frysinger
Quoted 6 lines · On Sunday, May 15, 2011 21:52:53 Mike Frysinger wrote:

tools/omapimage.c line 135

Quoted 3 lines · On Sunday, May 15, 2011 11:21:19 Aneesh V wrote:
tools/omapimage.c new file +3 -0
+static void omapimage_print_header(const void *ptr)
+{
+	struct ch_toc *toc = (struct ch_toc *)ptr;

you're casting away the void. something is fundamentally broken here.

err, obviously i meant "const" instead of "void" ... -mike

This is not my code. But I don't think it was intentional. The following didn't seem to cause any trouble. I shall add this fix in the next revision if this looks ok.

static void omapimage_print_header(const void *ptr) {
- struct ch_toc *toc = (struct ch_toc *)ptr;
+ const struct ch_toc *toc = (const struct ch_toc *)ptr;

Quoted 7 lines

_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

#53 lore raw

PATCH v2 1/22 mkimage: Add OMAP boot image support

Quoted 9 lines · On Monday, May 16, 2011 06:28:40 Aneesh V wrote:
Quoted 8 lines · Mike Frysinger
Quoted 6 lines · On Sunday, May 15, 2011 21:52:53 Mike Frysinger wrote:

tools/omapimage.c line 135

Quoted 3 lines · On Sunday, May 15, 2011 11:21:19 Aneesh V wrote:
tools/omapimage.c new file +3 -0
+static void omapimage_print_header(const void *ptr)
+{
+	struct ch_toc *toc = (struct ch_toc *)ptr;

you're casting away the void. something is fundamentally broken here.

Quoted 3 lines
Quoted 1 line

err, obviously i meant "const" instead of "void" ...

This is not my code.

you're submitting the patch with only your s-o-b on it. that means you're responsible for it all.

Review

Quoted 4 lines
  static void omapimage_print_header(const void *ptr)
  {
(quoted diff) +1 -1
-	struct ch_toc *toc = (struct ch_toc *)ptr;
+	const struct ch_toc *toc =  (const struct ch_toc *)ptr;

drop the cast entirely ... this isnt C++ after all:

	const struct ch_toc *toc =  ptr;

-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110516/715f6757/attachment.pgp

author
#54 lore raw

PATCH v2 1/22 mkimage: Add OMAP boot image support

Hi Mike,

Quoted 10 lines · Mike Frysinger
Quoted 9 lines · On Monday, May 16, 2011 06:28:40 Aneesh V wrote:
Quoted 8 lines · Mike Frysinger
Quoted 6 lines · On Sunday, May 15, 2011 21:52:53 Mike Frysinger wrote:

tools/omapimage.c line 135

Quoted 3 lines · On Sunday, May 15, 2011 11:21:19 Aneesh V wrote:
tools/omapimage.c new file +3 -0
+static void omapimage_print_header(const void *ptr)
+{
+	struct ch_toc *toc = (struct ch_toc *)ptr;

you're casting away the void. something is fundamentally broken here.

Quoted 6 lines
Quoted 3 lines
Quoted 1 line

err, obviously i meant "const" instead of "void" ...

This is not my code.

you're submitting the patch with only your s-o-b on it. that means you're responsible for it all.

No. both From and s-o-b are John's on this patch.

Quoted 8 lines

Review

Quoted 5 lines
   static void omapimage_print_header(const void *ptr)
   {
(quoted diff) +1 -1
-	struct ch_toc *toc = (struct ch_toc *)ptr;
+	const struct ch_toc *toc =  (const struct ch_toc *)ptr;

drop the cast entirely ... this isnt C++ after all:

	const struct ch_toc *toc =  ptr;

ok.

best regards,
Aneesh

author
#55 lore raw

PATCH v2 2/22 omap4: add OMAP4430 revision check

In reply to Aneesh V

---
V2:
* Added a revision string in addition to the revision number Helps in printing out the OMAP revision at bootup

---
 arch/arm/cpu/armv7/omap4/board.c        |   58 +++++++++++++++++++++++++++++++
 arch/arm/include/asm/arch-omap4/omap4.h |   17 ++++++---
 arch/arm/include/asm/armv7.h            |    6 +++-
 3 files changed, 74 insertions(+), 7 deletions(-)
arch/arm/cpu/armv7/omap4/board.c +58 -0
index fcd29a7..8ab7306 100644
@@ -28,6 +28,7 @@
  * MA 02111-1307 USA
  */
 #include <common.h>
+#include <asm/armv7.h>
 #include <asm/arch/cpu.h>
 #include <asm/arch/sys_proto.h>
 #include <asm/sizes.h>
@@ -127,3 +128,60 @@ int arch_cpu_init(void)
 	set_muxconf_regs();
 	return 0;
 }
+
+static u32 cortex_a9_rev(void)
+{
+
+	unsigned int rev;
+
+	/* Read Main ID Register (MIDR) */
+	asm ("mrc p15, 0, %0, c0, c0, 0" : "=r" (rev));
+
+	return rev;
+}
+
+u32 omap4_revision(void)
+{
+	if (readl(CONTROL_ID_CODE) == OMAP4_CONTROL_ID_CODE_ES2_1)
+		return OMAP4430_ES2_1;
+	else if (readl(CONTROL_ID_CODE) == OMAP4_CONTROL_ID_CODE_ES2_2)
+		return OMAP4430_ES2_2;
+	/*
+	 * For some of the ES2/ES1 boards ID_CODE is not reliable:
+	 * Also, ES1 and ES2 have different ARM revisions
+	 * So use ARM revision for identification
+	 */
+	unsigned int rev = cortex_a9_rev();
+
+	switch (rev) {
+	case MIDR_CORTEX_A9_R0P1:
+		return OMAP4430_ES1_0;
+	case MIDR_CORTEX_A9_R1P2:
+		return OMAP4430_ES2_0;
+	default:
+		return OMAP4430_SILICON_ID_INVALID;
+	}
+}
+
+const char *omap4_rev_string(void)
+{
+	const char *omap4_rev = NULL;
+	switch (omap4_revision()) {
+	case OMAP4430_ES1_0:
+		omap4_rev = "OMAP4430 ES1.0";
+		break;
+	case OMAP4430_ES2_0:
+		omap4_rev = "OMAP4430 ES2.0";
+		break;
+	case OMAP4430_ES2_1:
+		omap4_rev = "OMAP4430 ES2.1";
+		break;
+	case OMAP4430_ES2_2:
+		omap4_rev = "OMAP4430 ES2.2";
+		break;
+	default:
+		omap4_rev = "OMAP4 - Unknown Rev";
+		break;
+	}
+	return omap4_rev;
+}
arch/arm/include/asm/arch-omap4/omap4.h +11 -6
index a30bb33..1f88732 100644
@@ -51,6 +51,11 @@
 #define CONTROL_PADCONF_CORE	(OMAP44XX_L4_CORE_BASE + 0x100000)
 #define CONTROL_PADCONF_WKUP	(OMAP44XX_L4_CORE_BASE + 0x31E000)
 
+/* CONTROL_ID_CODE */
+#define CONTROL_ID_CODE		(CTRL_BASE + 0x204)
+
+#define OMAP4_CONTROL_ID_CODE_ES2_1	0x3B95C02F
+#define OMAP4_CONTROL_ID_CODE_ES2_2	0x4B95C02F
 /* UART */
 #define UART1_BASE		(OMAP44XX_L4_PER_BASE + 0x6a000)
 #define UART2_BASE		(OMAP44XX_L4_PER_BASE + 0x6c000)
@@ -121,11 +126,11 @@ struct s32ktimer {
 /* Temporary SRAM stack used while low level init is done */
 #define LOW_LEVEL_SRAM_STACK	NON_SECURE_SRAM_END
 
-/*
- * OMAP4 real hardware:
- * TODO: Change this to the IDCODE in the hw regsiter
- */
-#define CPU_OMAP4430_ES10	1
-#define CPU_OMAP4430_ES20	2
+/* Silicon revisions */
+#define OMAP4430_SILICON_ID_INVALID	0
+#define OMAP4430_ES1_0	1
+#define OMAP4430_ES2_0	2
+#define OMAP4430_ES2_1	3
+#define OMAP4430_ES2_2	4
 
 #endif
arch/arm/include/asm/armv7.h +5 -1
index 50cc167..772435b 100644
@@ -26,6 +26,10 @@
 #define ARMV7_H
 #include <linux/types.h>
 
+/* Cortex-A9 revisions */
+#define MIDR_CORTEX_A9_R0P1	0x410FC091
+#define MIDR_CORTEX_A9_R1P2	0x411FC092
+
 /* CCSIDR */
 #define CCSIDR_LINE_SIZE_OFFSET		0
 #define CCSIDR_LINE_SIZE_MASK		0x7
@@ -65,4 +69,4 @@ void v7_outer_cache_inval_all(void);
 void v7_outer_cache_flush_range(u32 start, u32 end);
 void v7_outer_cache_inval_range(u32 start, u32 end);
 
-#endif
+#endif /* ARMV7_H */
Signature · 1 line
1.7.0.4
#56 lore raw

PATCH v2 2/22 omap4: add OMAP4430 revision check

Dear Aneesh V,

Quoted 5 lines · In message <[email protected]> you wrote:

---
V2:
* Added a revision string in addition to the revision number Helps in printing out the OMAP revision at bootup

...

Quoted 6 lines
arch/arm/cpu/armv7/omap4/board.c +6 -0
+const char *omap4_rev_string(void)
+{
+	const char *omap4_rev = NULL;
+	switch (omap4_revision()) {
+	case OMAP4430_ES1_0:
+		omap4_rev = "OMAP4430 ES1.0";

arch/arm/cpu/armv7/omap4/board.c int arch_cpu_init(void) · line 181

Quoted 10 lines
arch/arm/cpu/armv7/omap4/board.c +10 -0
+		break;
+	case OMAP4430_ES2_0:
+		omap4_rev = "OMAP4430 ES2.0";
+		break;
+	case OMAP4430_ES2_1:
+		omap4_rev = "OMAP4430 ES2.1";
+		break;
+	case OMAP4430_ES2_2:
+		omap4_rev = "OMAP4430 ES2.2";
+		break;

Such code does not really scale well. Can this not be improved? I think we just had similar discussions for i.MX5x - please check what the result of these was.

arch/arm/cpu/armv7/omap4/board.c int arch_cpu_init(void) · line 184

Quoted 3 lines
arch/arm/cpu/armv7/omap4/board.c +3 -0
+	default:
+		omap4_rev = "OMAP4 - Unknown Rev";
+		break;

Please also output what the unknown revision was - this saves at least one debug round if you ever run into this case.

arch/arm/include/asm/arch-omap4/omap4.h line 55

Quoted 11 lines
(quoted diff) +1 -0
+}
arch/arm/include/asm/arch-omap4/omap4.h +2 -0
index a30bb33..1f88732 100644
@@ -51,6 +51,11 @@
 #define CONTROL_PADCONF_CORE	(OMAP44XX_L4_CORE_BASE + 0x100000)
 #define CONTROL_PADCONF_WKUP	(OMAP44XX_L4_CORE_BASE + 0x31E000)
 
+/* CONTROL_ID_CODE */
+#define CONTROL_ID_CODE		(CTRL_BASE + 0x204)

C struct?

Best regards,

Wolfgang Denk

Signature · 6 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Change is the essential process of all existence.
	-- Spock, "Let That Be Your Last Battlefield",
	   stardate 5730.2
author
#57 lore raw

PATCH v2 2/22 omap4: add OMAP4430 revision check

Hi Wolfgang,

Quoted 21 lines · Wolfgang Denk

Dear Aneesh V,

Quoted 5 lines · In message<[email protected]> you wrote:

---
V2:
* Added a revision string in addition to the revision number Helps in printing out the OMAP revision at bootup

...

Quoted 12 lines
arch/arm/cpu/armv7/omap4/board.c +12 -0
+const char *omap4_rev_string(void)
+{
+	const char *omap4_rev = NULL;
+	switch (omap4_revision()) {
+	case OMAP4430_ES1_0:
+		omap4_rev = "OMAP4430 ES1.0";
+		break;
+	case OMAP4430_ES2_0:
+		omap4_rev = "OMAP4430 ES2.0";
+		break;
+	case OMAP4430_ES2_1:
+		omap4_rev = "OMAP4430 ES2.1";
Quoted 8 lines

arch/arm/cpu/armv7/omap4/board.c int arch_cpu_init(void) · line 181

Quoted 4 lines
arch/arm/cpu/armv7/omap4/board.c +4 -0
+		break;
+	case OMAP4430_ES2_2:
+		omap4_rev = "OMAP4430 ES2.2";
+		break;

Such code does not really scale well. Can this not be improved? I think we just had similar discussions for i.MX5x - please check what the result of these was.

Are you referring to this one?
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/98522

If so, it may not work for us:

1. Please note that the above function is just for getting the string not for the revision itself. To get the revision we have omap4_revision().

2. In our case we do not have a 1:1 mapping between the revisions(monotonically increasing numbers) we need in the U-Boot and the value obtained from the ID_CODE register. So, a translation is inevitable.

3. We need increasing numbers for subsequent revisions so that we can have something like:

if (omap4_revision() >= OMAP4430_ES2_0)

	do_something();
Quoted 7 lines

arch/arm/cpu/armv7/omap4/board.c int arch_cpu_init(void) · line 184

Quoted 4 lines
arch/arm/cpu/armv7/omap4/board.c +3 -0
+	default:
+		omap4_rev = "OMAP4 - Unknown Rev";
+		break;

Please also output what the unknown revision was - this saves at least one debug round if you ever run into this case.

This function should be in sync with omap4_revision() function(unless there is a bug). So, the rev will be OMAP4430_SILICON_ID_INVALID in that case.

I shall print out the ARM revision and OMAP revision registers when I get into OMAP4430_SILICON_ID_INVALID situation in omap4_revision()

Quoted 10 lines
Quoted 10 lines
(quoted diff) +1 -0
+}
arch/arm/include/asm/arch-omap4/omap4.h +0 -0
index a30bb33..1f88732 100644
@@ -51,6 +51,11 @@
  #define CONTROL_PADCONF_CORE	(OMAP44XX_L4_CORE_BASE + 0x100000)
  #define CONTROL_PADCONF_WKUP	(OMAP44XX_L4_CORE_BASE + 0x31E000)
 
Quoted 4 lines

arch/arm/include/asm/arch-omap4/omap4.h line 55

Quoted 2 lines
arch/arm/include/asm/arch-omap4/omap4.h +2 -0
+/* CONTROL_ID_CODE */
+#define CONTROL_ID_CODE		(CTRL_BASE + 0x204)

C struct?

Ok. I shall convert defines to C structs globally for register addressing.

Quoted 6 lines

Best regards,

Wolfgang Denk

#58 lore raw

PATCH v2 2/22 omap4: add OMAP4430 revision check

Dear Aneesh V,

Quoted 20 lines · In message <[email protected]> you wrote:
Quoted 11 lines
Quoted 11 lines
arch/arm/cpu/armv7/omap4/board.c +10 -0
+	const char *omap4_rev = NULL;
+	switch (omap4_revision()) {
+	case OMAP4430_ES1_0:
+		omap4_rev = "OMAP4430 ES1.0";
+		break;
+	case OMAP4430_ES2_0:
+		omap4_rev = "OMAP4430 ES2.0";
+		break;
+	case OMAP4430_ES2_1:
+		omap4_rev = "OMAP4430 ES2.1";
Quoted 8 lines

arch/arm/cpu/armv7/omap4/board.c int arch_cpu_init(void) · line 181

Quoted 4 lines
arch/arm/cpu/armv7/omap4/board.c +4 -0
+		break;
+	case OMAP4430_ES2_2:
+		omap4_rev = "OMAP4430 ES2.2";
+		break;

Such code does not really scale well. Can this not be improved? I think we just had similar discussions for i.MX5x - please check what the result of these was.

Quoted 8 lines

Are you referring to this one?
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/98522

If so, it may not work for us:

1. Please note that the above function is just for getting the string not for the revision itself. To get the revision we have omap4_revision().

Well, when you already have such a funxction, then why cannot it be made to return useful values that are well-suited for formatting?

Instead of

	#define OMAP4430_ES1_0 1
	#define OMAP4430_ES2_0 2
	#define OMAP4430_ES2_1 3
	#define OMAP4430_ES2_2 4

you could use

	#define OMAP4430_ES1_0 10
	#define OMAP4430_ES2_0 20
	#define OMAP4430_ES2_1 21
	#define OMAP4430_ES2_2 22

And then use a plain

	sprintf(omap4_rev, "OMAP4430 ES%d.%d", rev/10, rev%10);

or similar.

Quoted 4 lines

2. In our case we do not have a 1:1 mapping between the revisions(monotonically increasing numbers) we need in the U-Boot and the value obtained from the ID_CODE register. So, a translation is inevitable.

This is not needed. See above. Any form of table driven approach would be suitable, too.

Quoted 2 lines

3. We need increasing numbers for subsequent revisions so that we can have something like:

Should be no problem, see above. Just define your number scheme. Instead of decimal packing you could also adapt something like the major/minor numbers for devices, and use the existing macros to extract the parts.

There are tons of existing solutions for this type of problem, just pick one that fits.

Quoted 10 lines
Quoted 6 lines

arch/arm/cpu/armv7/omap4/board.c int arch_cpu_init(void) · line 184

Quoted 3 lines
arch/arm/cpu/armv7/omap4/board.c +3 -0
+	default:
+		omap4_rev = "OMAP4 - Unknown Rev";
+		break;

Please also output what the unknown revision was - this saves at least one debug round if you ever run into this case.

This function should be in sync with omap4_revision() function(unless there is a bug). So, the rev will be OMAP4430_SILICON_ID_INVALID in that case.

In this case omap4_revision() should print the value it is reading. Whenever you are reading "unexpected? numbers the first thing you will do during debugging is to check _what_ exactly you are reawding - so you can help and safe one step by just printing thei information which you have ready in your hands.

Quoted 2 lines

I shall print out the ARM revision and OMAP revision registers when I get into OMAP4430_SILICON_ID_INVALID situation in omap4_revision()

Thanks.

Best regards,

Wolfgang Denk

Signature · 6 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"We have the right to survive!"
"Not be killing others."
	-- Deela and Kirk, "Wink of An Eye", stardate 5710.5
author
#59 lore raw

PATCH v2 2/22 omap4: add OMAP4430 revision check

Hi Wolfgang,

Quoted 2 lines · Wolfgang Denk

Dear Aneesh V,

...

Quoted 22 lines
Quoted 4 lines

1. Please note that the above function is just for getting the string not for the revision itself. To get the revision we have omap4_revision().

Well, when you already have such a funxction, then why cannot it be made to return useful values that are well-suited for formatting?

Instead of

	#define OMAP4430_ES1_0 1
	#define OMAP4430_ES2_0 2
	#define OMAP4430_ES2_1 3
	#define OMAP4430_ES2_2 4

you could use

	#define OMAP4430_ES1_0 10
	#define OMAP4430_ES2_0 20
	#define OMAP4430_ES2_1 21
	#define OMAP4430_ES2_2 22
Quoted 5 lines

And then use a plain

	sprintf(omap4_rev, "OMAP4430 ES%d.%d", rev/10, rev%10);

or similar.

This is a good idea. The only minor hitch is that OMAP4460 will come into picture in near future, again having at least ES1_0. But I think that can be worked out.

best regards,
Aneesh

#60 lore raw

PATCH v2 2/22 omap4: add OMAP4430 revision check

Dear Aneesh V,

Quoted 10 lines · In message <[email protected]> you wrote:
Quoted 10 lines

you could use

	#define OMAP4430_ES1_0 10
	#define OMAP4430_ES2_0 20
	#define OMAP4430_ES2_1 21
	#define OMAP4430_ES2_2 22

And then use a plain

Quoted 7 lines
Quoted 3 lines
	sprintf(omap4_rev, "OMAP4430 ES%d.%d", rev/10, rev%10);

or similar.

This is a good idea. The only minor hitch is that OMAP4460 will come into picture in near future, again having at least ES1_0. But I think that can be worked out.

Then go for something like

	#define OMAP4430_ES1_0 0x44300100
	#define OMAP4430_ES2_0 0x44300200
	#define OMAP4430_ES2_1 0x44300201
	#define OMAP4430_ES2_2 0x44300202

	sprintf(omap4_rev, "OMAP%x ES%x.%x",
		(rev >> 16) & 0xFFFF,
		(rev >> 8) & 0xFF,
		rev & 0xFF);

or so.

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The optimum committee has no members.
                                                   - Norman Augustine
author
#61 lore raw

PATCH v2 3/22 armv7: start.S: provide a hook for saving boot params

In reply to Aneesh V

Provide a means by which u-boot/SPL can save parameters passed to it by ROM code or the pre-loader.

A new function 'save_boot_params' has been defined and a default implentation provided. Please note that we do not have a stack yet. So, any implementation of this function should not use stack.

---
 arch/arm/cpu/armv7/cpu.c   |    7 +++++++
 arch/arm/cpu/armv7/start.S |    1 +
 2 files changed, 8 insertions(+), 0 deletions(-)
arch/arm/cpu/armv7/cpu.c +7 -0
index 5c69d04..1c9e297 100644
@@ -36,6 +36,13 @@
 #include <asm/system.h>
 #include <asm/armv7.h>
 
+void save_boot_params_default(u32 r0, u32 r1, u32 r2, u32 r3)
+{
+}
+
+void save_boot_params(u32 r0, u32 r1, u32 r2, u32 r3)
+	__attribute__((weak, alias("save_boot_params_default")));
+
 int cleanup_before_linux(void)
 {
 	/*
arch/arm/cpu/armv7/start.S +1 -0
index 13e2d44..e6e05e9 100644
@@ -119,6 +119,7 @@ IRQ_STACK_START_IN:
  */
 
 reset:
+	bl	save_boot_params
 	/*
 	 * set the cpu to SVC32 mode
 	 */
Signature · 1 line
1.7.0.4
#62 lore raw

PATCH v2 3/22 armv7: start.S: provide a hook for saving boot params

Dear Aneesh V,

Quoted 8 lines · In message <[email protected]> you wrote:

Provide a means by which u-boot/SPL can save parameters passed to it by ROM code or the pre-loader.

A new function 'save_boot_params' has been defined and a default implentation provided. Please note that we do not have a stack yet. So, any implementation of this function should not use stack.

As is, this is dead code. Please squash with next patch that uses this.

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
You don't have to stay up nights to succeed; you have to  stay  awake
days.
author
#63 lore raw

PATCH v2 4/22 omap4: save parameters passed by ROM code to SPL

In reply to Aneesh V

Save boot device information passed by OMAP4 rom code

ROM code in OMAP4 passes information such as the media from which it picked up the first boot image(SPL in our case), the mode(raw mode/FAT mode) etc.

Save this information in SPL so that we can use the same media and mode to bootload u-boot.

---
 arch/arm/cpu/armv7/omap4/board.c                   |   14 +++++++
 arch/arm/cpu/armv7/omap4/lowlevel_init.S           |   31 +++++++++++++++
 arch/arm/include/asm/arch-omap4/omap4.h            |    8 ++++
 arch/arm/include/asm/arch-omap4/sys_proto.h        |    1 +
 .../asm/{arch-omap4/sys_proto.h => omap_common.h}  |   41 +++++++++++--------
 5 files changed, 78 insertions(+), 17 deletions(-)
 copy arch/arm/include/asm/{arch-omap4/sys_proto.h => omap_common.h} (54%)
arch/arm/cpu/armv7/omap4/board.c +14 -0
index 8ab7306..046e3bf 100644
@@ -35,6 +35,20 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+#ifdef CONFIG_PRELOADER
+u32 omap4_boot_device = BOOT_DEVICE_MMC1;
+u32 omap4_boot_mode = MMCSD_MODE_FAT;
+u32 omap_boot_device(void)
+{
+	return omap4_boot_device;
+}
+
+u32 omap_boot_mode(void)
+{
+	return omap4_boot_mode;
+}
+#endif
+
 /*
  * Routine: s_init
  * Description: Does early system init of muxing and clocks.
arch/arm/cpu/armv7/omap4/lowlevel_init.S +31 -0
index 5e6c16f..d26d6e6 100644
@@ -27,6 +27,37 @@
  */
 
 #include <asm/arch/omap4.h>
+#ifdef CONFIG_PRELOADER
+.global save_boot_params
+save_boot_params:
+	/*
+	 * See if the rom code passed pointer is valid:
+	 * It is not valid if it is not in non-secure SRAM
+	 * This may happen if you are booting with the help of
+	 * debugger
+	 */
+	ldr     r2, =NON_SECURE_SRAM_START
+	cmp	r2, r0
+	bgt	1f
+	ldr	r2, =NON_SECURE_SRAM_END
+	cmp	r2, r0
+	blt	1f
+
+	/* Store the boot device in omap4_boot_device */
+	ldr     r2, [r0, #BOOT_DEVICE_OFFSET]	@ r1 <- value of boot device
+	and	r2, #BOOT_DEVICE_MASK
+	ldr	r3, =omap4_boot_device
+	str     r2, [r3]			@ omap4_boot_device <- r1
+
+	/* Store the boot mode (raw/FAT) in omap4_boot_mode */
+	ldr	r2, [r0, #DEV_DESC_PTR_OFFSET]	@ get the device descriptor ptr
+	ldr	r2, [r2, #DEV_DATA_PTR_OFFSET]	@ get the pDeviceData ptr
+	ldr	r2, [r2, #BOOT_MODE_OFFSET]	@ get the boot mode
+	ldr	r3, =omap4_boot_mode
+	str	r2, [r3]
+1:
+	bx	lr
+#endif
 
 .globl lowlevel_init
 lowlevel_init:
arch/arm/include/asm/arch-omap4/omap4.h +8 -0
index 1f88732..740ca9d 100644
@@ -133,4 +133,12 @@ struct s32ktimer {
 #define OMAP4430_ES2_1	3
 #define OMAP4430_ES2_2	4
 
+/* ROM code defines */
+/* Boot device */
+#define BOOT_DEVICE_MASK	0xFF
+#define BOOT_DEVICE_OFFSET	0x8
+#define DEV_DESC_PTR_OFFSET	0x4
+#define DEV_DATA_PTR_OFFSET	0x18
+#define BOOT_MODE_OFFSET	0x8
+
 #endif
arch/arm/include/asm/arch-omap4/sys_proto.h +1 -0
index 017f216..0026b75 100644
@@ -23,6 +23,7 @@
 
 #include <asm/arch/omap4.h>
 #include <asm/io.h>
+#include <asm/omap_common.h>
 
 struct omap_sysinfo {
 	char *board_string;
arch/arm/include/asm/omap_common.h renamed from arch/arm/include/asm/arch-omap4/sys_proto.h +24 -17

55 lines not on this page · raw message

Signature · 1 line
1.7.0.4
#64 lore raw

PATCH v2 4/22 omap4: save parameters passed by ROM code to SPL

Dear Aneesh V,

Quoted 10 lines · In message <[email protected]> you wrote:

Save boot device information passed by OMAP4 rom code

ROM code in OMAP4 passes information such as the media from which it picked up the first boot image(SPL in our case), the mode(raw mode/FAT mode) etc.

Save this information in SPL so that we can use the same media and mode to bootload u-boot.

...

arch/arm/cpu/armv7/omap4/lowlevel_init.S line 50

Quoted 5 lines
arch/arm/cpu/armv7/omap4/lowlevel_init.S +5 -0
+	/* Store the boot device in omap4_boot_device */
+	ldr     r2, [r0, #BOOT_DEVICE_OFFSET]	@ r1 <- value of boot device
+	and	r2, #BOOT_DEVICE_MASK
+	ldr	r3, =omap4_boot_device
+	str     r2, [r3]			@ omap4_boot_device <- r1

Why don't you use stadard global data here?

Best regards,

Wolfgang Denk

Signature · 6 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [email protected]
I object to intellect without discipline;  I object to power without
constructive purpose.
	-- Spock, "The Squire of Gothos", stardate 2124.5
author
#65 lore raw

PATCH v2 4/22 omap4: save parameters passed by ROM code to SPL

Hi Wolfgang,

Quoted 13 lines · Wolfgang Denk

Dear Aneesh V,

Quoted 10 lines · In message<[email protected]> you wrote:

Save boot device information passed by OMAP4 rom code

ROM code in OMAP4 passes information such as the media from which it picked up the first boot image(SPL in our case), the mode(raw mode/FAT mode) etc.

Save this information in SPL so that we can use the same media and mode to bootload u-boot.

Quoted 8 lines

...

arch/arm/cpu/armv7/omap4/lowlevel_init.S

Quoted 5 lines
arch/arm/cpu/armv7/omap4/lowlevel_init.S +5 -0
+	/* Store the boot device in omap4_boot_device */
+	ldr     r2, [r0, #BOOT_DEVICE_OFFSET]	@ r1<- value of boot device
+	and	r2, #BOOT_DEVICE_MASK
+	ldr	r3, =omap4_boot_device
+	str     r2, [r3]			@ omap4_boot_device<- r1

Why don't you use stadard global data here?

SPL has access to .data right from the beginning. Besides this is too early. global data is not initialized yet.

best regards,
Aneesh

#66 lore raw

PATCH v2 4/22 omap4: save parameters passed by ROM code to SPL

Dear Aneesh V,

Quoted 14 lines · In message <[email protected]> you wrote:
Quoted 5 lines
Quoted 5 lines

Save this information in SPL so that we can use the same media and mode to bootload u-boot.

Quoted 8 lines

...

arch/arm/cpu/armv7/omap4/lowlevel_init.S

Quoted 5 lines
arch/arm/cpu/armv7/omap4/lowlevel_init.S +5 -0
+	/* Store the boot device in omap4_boot_device */
+	ldr     r2, [r0, #BOOT_DEVICE_OFFSET]	@ r1<- value of boot device
+	and	r2, #BOOT_DEVICE_MASK
+	ldr	r3, =omap4_boot_device
+	str     r2, [r3]			@ omap4_boot_device<- r1

Why don't you use stadard global data here?

Quoted 2 lines

SPL has access to .data right from the beginning. Besides this is too early. global data is not initialized yet.

Please keep in mind that this is a special situation then. The code will not work as intended for example when running form NOR flash.

Best regards,

Wolfgang Denk

Signature · 6 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Good manners are the settled  medium  of  social,  as  specie  is  of
commercial, life; returns are equally expected for both.
           - Lord Chesterfield _Letters to his Son_, 25 December 1753
author
#67 lore raw

PATCH v2 4/22 omap4: save parameters passed by ROM code to SPL

Hi Wolfgang,

Quoted 17 lines · Wolfgang Denk

Dear Aneesh V,

Quoted 14 lines · In message<[email protected]> you wrote:
Quoted 13 lines
Quoted 5 lines

Save this information in SPL so that we can use the same media and mode to bootload u-boot.

...

arch/arm/cpu/armv7/omap4/lowlevel_init.S

Quoted 5 lines
arch/arm/cpu/armv7/omap4/lowlevel_init.S +5 -0
+	/* Store the boot device in omap4_boot_device */
+	ldr     r2, [r0, #BOOT_DEVICE_OFFSET]	@ r1<- value of boot device
+	and	r2, #BOOT_DEVICE_MASK
+	ldr	r3, =omap4_boot_device
+	str     r2, [r3]			@ omap4_boot_device<- r1

Why don't you use stadard global data here?

Quoted 5 lines
Quoted 2 lines

SPL has access to .data right from the beginning. Besides this is too early. global data is not initialized yet.

Please keep in mind that this is a special situation then. The code will not work as intended for example when running form NOR flash.

Yes, I realize that. The values passed in the ARM registers need to be saved before they are lost. At the moment only SPL needs them. We do not have a board with NOR flash yet. If there is a need in the future we may have to save it in some predefined special purpose memory such as the scratchpad memory of OMAP or some location in the internal RAM that is not used. But there is no such need at the moment.

best regards,
Aneesh

#68 lore raw

PATCH v2 4/22 omap4: save parameters passed by ROM code to SPL

Dear Aneesh V,

Quoted 7 lines · In message <[email protected]> you wrote:
Quoted 6 lines
Quoted 3 lines

SPL has access to .data right from the beginning. Besides this is too early. global data is not initialized yet.

Please keep in mind that this is a special situation then. The code will not work as intended for example when running form NOR flash.

Quoted 6 lines

Yes, I realize that. The values passed in the ARM registers need to be saved before they are lost. At the moment only SPL needs them. We do not have a board with NOR flash yet. If there is a need in the future we may have to save it in some predefined special purpose memory such as the scratchpad memory of OMAP or some location in the internal RAM that is not used. But there is no such need at the moment.

OK. Maybe you can add a comment that explains this situation.

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"It may be that our role on this planet is not to worship God but  to
create him."                                       - Arthur C. Clarke
author
#69 lore raw

PATCH v2 5/22 arm: new labels in the linker script file

In reply to Aneesh V

_bss_start_ofs is used in start.S to indicate end of copied image. This may not be correct when we have a discontiguous memory map. For instance, .bss may be placed in SDRAM for some SPLS while rest of the image is placed in SRAM.

Define a new label in linker script to indicate the end of the image copied during relocation and use it appropriately in start.S.

Also, add a new label to indicate the end of flash image. This will be useful in identifying the size of flash image

---
V2:
* Removed the label __flash_image_end because _end serves the same purpose after rebasing to latest mainline

---
 arch/arm/cpu/armv7/start.S    |    6 +++++-
 arch/arm/cpu/armv7/u-boot.lds |    2 ++
 2 files changed, 7 insertions(+), 1 deletions(-)
arch/arm/cpu/armv7/start.S +5 -1
index e6e05e9..13178cd 100644
@@ -89,6 +89,10 @@ _armboot_start:
 _bss_start_ofs:
 	.word __bss_start - _start
 
+.global	_image_copy_end_ofs
+_image_copy_end_ofs:
+	.word 	__image_copy_end - _start
+
 .globl _bss_end_ofs
 _bss_end_ofs:
 	.word __bss_end__ - _start
@@ -188,7 +192,7 @@ stack_setup:
 	beq	clear_bss		/* skip relocation */
 #endif
 	mov	r1, r6			/* r1 <- scratch for copy_loop */
-	ldr	r3, _bss_start_ofs
+	ldr	r3, _image_copy_end_ofs
 	add	r2, r0, r3		/* r2 <- source end address	    */
 
 copy_loop:
arch/arm/cpu/armv7/u-boot.lds +2 -0
index dbae54d..40ecf78 100644
@@ -55,6 +55,8 @@ SECTIONS
 
 	. = ALIGN(4);
 
+	__image_copy_end = .;
+
 	.rel.dyn : {
 		__rel_dyn_start = .;
 		*(.rel*)
Signature · 1 line
1.7.0.4
author
#70 lore raw

PATCH v2 6/22 Add generic spl infrastructure

In reply to Aneesh V

Define a new type of SPL that is not tied to any particular media.
- Create a top level directory 'spl' that has a structure similar to the existing 'nand_spl'
- Make necessary changes to top-level Makefile to build such an spl

Rationale for this approach:
- There may be SPLs(like the OMAP x-loader) that support booting from multiple media.
- Also, there is no harm in keeping SPLs specific to a particular media also under this directory. In fact it makes sense to merge all the different spl directories into this one.

---
This patch generates 1 checkpatch warning due to declaration of DECLARE_GLOBAL_DATA_PTR. This is un-avoidable

---
 Makefile                           |   24 ++++++++++++++++++++++++
 arch/arm/include/asm/global_data.h |    5 +++++
 2 files changed, 29 insertions(+), 0 deletions(-)
Makefile +24 -0
index 384a59e..d3f4bef 100644
@@ -289,6 +289,22 @@ LDPPFLAGS += \
 	$(shell $(LD) --version | \
 	  sed -ne 's/GNU ld version \([0-9][0-9]*\)\.\([0-9][0-9]*\).*/-DLD_MAJOR=\1 -DLD_MINOR=\2/p')
 
+ifeq ($(CONFIG_NAND_U_BOOT),y)
+NAND_SPL = nand_spl
+U_BOOT_NAND = $(obj)u-boot-nand.bin
+endif
+
+ifeq ($(CONFIG_SPL),y)
+.PHONEY : SPL
+ALL += SPL
+endif
+
+ifeq ($(CONFIG_ONENAND_U_BOOT),y)
+ONENAND_IPL = onenand_ipl
+U_BOOT_ONENAND = $(obj)u-boot-onenand.bin
+ONENAND_BIN ?= $(obj)onenand_ipl/onenand-ipl-2k.bin
+endif
+
 __OBJS := $(subst $(obj),,$(OBJS))
 __LIBS := $(subst $(obj),,$(LIBS)) $(subst $(obj),,$(LIBBOARD))
 
@@ -402,8 +418,13 @@ $(obj)u-boot.lds: $(LDSCRIPT)
 		$(CPP) $(CPPFLAGS) $(LDPPFLAGS) -ansi -D__ASSEMBLY__ -P - <$^ >$@
 
 nand_spl:	$(TIMESTAMP_FILE) $(VERSION_FILE) depend
+
+$(NAND_SPL):	$(TIMESTAMP_FILE) $(VERSION_FILE) depend
 		$(MAKE) -C nand_spl/board/$(BOARDDIR) all
 
+SPL		:$(TIMESTAMP_FILE) $(VERSION_FILE) depend tools
+		$(MAKE) -C spl/board/$(BOARDDIR) all
+
 $(obj)u-boot-nand.bin:	nand_spl $(obj)u-boot.bin
 		cat $(obj)nand_spl/u-boot-spl-16k.bin $(obj)u-boot.bin > $(obj)u-boot-nand.bin
 
@@ -1122,6 +1143,7 @@ clean:
 	@rm -f $(obj)include/bmp_logo.h
 	@rm -f $(obj)lib/asm-offsets.s
 	@rm -f $(obj)nand_spl/{u-boot.lds,u-boot-spl,u-boot-spl.map,System.map}
+	@rm -f $(obj)spl/{u-boot-spl-generated.lds,u-boot-spl,u-boot-spl.map}
 	@rm -f $(obj)onenand_ipl/onenand-{ipl,ipl.bin,ipl.map}
 	@rm -f $(ONENAND_BIN)
 	@rm -f $(obj)onenand_ipl/u-boot.lds
@@ -1141,12 +1163,14 @@ clobber:	clean
 	@rm -f $(obj)u-boot $(obj)u-boot.map $(obj)u-boot.hex $(ALL)
 	@rm -f $(obj)u-boot.kwb
 	@rm -f $(obj)u-boot.imx
+	@rm -f $(obj)MLO
 	@rm -f $(obj)tools/{env/crc32.c,inca-swap-bytes}
 	@rm -f $(obj)arch/powerpc/cpu/mpc824x/bedbug_603e.c
 	@rm -fr $(obj)include/asm/proc $(obj)include/asm/arch $(obj)include/asm
 	@rm -fr $(obj)include/generated
 	@[ ! -d $(obj)nand_spl ] || find $(obj)nand_spl -name "*" -type l -print | xargs rm -f
 	@[ ! -d $(obj)onenand_ipl ] || find $(obj)onenand_ipl -name "*" -type l -print | xargs rm -f
+	@[ ! -d $(obj)spl ] || find $(obj)spl -name "*" -type l -print | xargs rm -f
 
 ifeq ($(OBJTREE),$(SRCTREE))
 mrproper \
arch/arm/include/asm/global_data.h +5 -0
index 2a84d27..2ce020e 100644
@@ -89,6 +89,11 @@ typedef	struct	global_data {
 #define GD_FLG_DISABLE_CONSOLE	0x00040	/* Disable console (in & out)		*/
 #define GD_FLG_ENV_READY	0x00080	/* Environment imported into hash table	*/
 
+#ifdef CONFIG_PRELOADER
+/* SPL works from internal RAM. gd pointer can be in .data section */
+#define DECLARE_GLOBAL_DATA_PTR     extern gd_t *gd
+#else
 #define DECLARE_GLOBAL_DATA_PTR     register volatile gd_t *gd asm ("r8")
+#endif
 
 #endif /* __ASM_GBL_DATA_H */
Signature · 1 line
1.7.0.4
#71 lore raw

PATCH v2 6/22 Add generic spl infrastructure

Dear Aneesh V,

Quoted 11 lines · In message <[email protected]> you wrote:

Define a new type of SPL that is not tied to any particular media.
- Create a top level directory 'spl' that has a structure similar to the existing 'nand_spl'
- Make necessary changes to top-level Makefile to build such an spl

Rationale for this approach:
- There may be SPLs(like the OMAP x-loader) that support booting from multiple media.
- Also, there is no harm in keeping SPLs specific to a particular media also under this directory. In fact it makes sense to merge all the different spl directories into this one.

Thanks a lot for addressing this. This is an area that has long been on my mind, and I'm really happy to see someone starting to work on this.

In addition to booting from different types of media, I see at least two more topics that scould and should addressed by this work:

- Get rid of xloader. I cannot see any good reasons why we need it, i. e. which functions if performs that cannot be as well (and eventually even more efficiently) be performed in the U-Boot SPL code.

- Become more flexible regarding the kind of second stage payload. It is definitely very powerful and convenient during development to be able to load U-Boot with all it's capabilities as payload of the SPL, but then, except for image size and parameter passing, there is little or no difference to loading a Linux kernel directly instead (and actually this is what most of the super-fast booting approaches do). If done right, we may even have the flexibility to do both, just by providing different images as payload.

Quoted 8 lines

---
This patch generates 1 checkpatch warning due to declaration of DECLARE_GLOBAL_DATA_PTR. This is un-avoidable

---
 Makefile                           |   24 ++++++++++++++++++++++++
 arch/arm/include/asm/global_data.h |    5 +++++
 2 files changed, 29 insertions(+), 0 deletions(-)

Here the commit message and the implementation do not agree. You wrote "Create a top level directory 'spl'" - but I don't see any of that here?

I think this should be split into a separate patch series, and care should be taken that commit messages and implementaiton match.

Best regards,

Wolfgang Denk

Signature · 4 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Our business is run on trust.  We trust you will pay in advance.
author
#72 lore raw

PATCH v2 6/22 Add generic spl infrastructure

Hi Wolfgang,

Quoted 20 lines · Wolfgang Denk

Dear Aneesh V,

Quoted 11 lines · In message<[email protected]> you wrote:

Define a new type of SPL that is not tied to any particular media.
- Create a top level directory 'spl' that has a structure similar to the existing 'nand_spl'
- Make necessary changes to top-level Makefile to build such an spl

Rationale for this approach:
- There may be SPLs(like the OMAP x-loader) that support booting from multiple media.
- Also, there is no harm in keeping SPLs specific to a particular media also under this directory. In fact it makes sense to merge all the different spl directories into this one.

Thanks a lot for addressing this. This is an area that has long been on my mind, and I'm really happy to see someone starting to work on this.

Quoted 7 lines

In addition to booting from different types of media, I see at least two more topics that scould and should addressed by this work:

- Get rid of xloader. I cannot see any good reasons why we need it, i. e. which functions if performs that cannot be as well (and eventually even more efficiently) be performed in the U-Boot SPL code.

Indeed, SPL is seen as a replacement for x-loader.

Quoted 10 lines

- Become more flexible regarding the kind of second stage payload. It is definitely very powerful and convenient during development to be able to load U-Boot with all it's capabilities as payload of the SPL, but then, except for image size and parameter passing, there is little or no difference to loading a Linux kernel directly instead (and actually this is what most of the super-fast booting approaches do). If done right, we may even have the flexibility to do both, just by providing different images as payload.

How do we handle the differences you just mentioned, namely the size, parameter passing etc. Maybe, we should have special handling for each and define config flags like CONFIG_SPL_PAYLOAD_UBOOT, CONFIG_SPL_PAYLOAD_LINUX_KERNEL etc?

Quoted 10 lines
Quoted 9 lines

---
This patch generates 1 checkpatch warning due to declaration of DECLARE_GLOBAL_DATA_PTR. This is un-avoidable

---
  Makefile                           |   24 ++++++++++++++++++++++++
  arch/arm/include/asm/global_data.h |    5 +++++
  2 files changed, 29 insertions(+), 0 deletions(-)
Quoted 3 lines

Here the commit message and the implementation do not agree. You wrote "Create a top level directory 'spl'" - but I don't see any of that here?

In this patch, I just created the makefile infrastructure that expects this directory structure. The files are created later in an OMAP specific patch.

I think I should have used something like "define a directory structure" instead of "create".

Quoted 3 lines

I think this should be split into a separate patch series, and care should be taken that commit messages and implementaiton match.

Ok.

Quoted 5 lines

Best regards,

Wolfgang Denk

#73 lore raw

PATCH v2 6/22 Add generic spl infrastructure

Dear Aneesh V,

Quoted 7 lines · In message <[email protected]> you wrote:
Quoted 5 lines

- Get rid of xloader. I cannot see any good reasons why we need it, i. e. which functions if performs that cannot be as well (and eventually even more efficiently) be performed in the U-Boot SPL code.

Indeed, SPL is seen as a replacement for x-loader.

Excellent.

Quoted 4 lines

How do we handle the differences you just mentioned, namely the size, parameter passing etc. Maybe, we should have special handling for each and define config flags like CONFIG_SPL_PAYLOAD_UBOOT, CONFIG_SPL_PAYLOAD_LINUX_KERNEL etc?

None of this. Ideally, the code should not even see such a difference. U-Boot does not need any special arguments for booting, so we calways pass Linux-compatible args. And things like image size should be read from the image itself, or form other available meta information (like file size when reading from a FAT file system, etc.).

Quoted 11 lines
Quoted 7 lines
Quoted 3 lines
  Makefile                           |   24 ++++++++++++++++++++++++
  arch/arm/include/asm/global_data.h |    5 +++++
  2 files changed, 29 insertions(+), 0 deletions(-)

Here the commit message and the implementation do not agree. You wrote "Create a top level directory 'spl'" - but I don't see any of that here?

In this patch, I just created the makefile infrastructure that expects this directory structure. The files are created later in an OMAP specific patch.

Such a definition should include the rename / moving of the other, already existing code.

Best regards,

Wolfgang Denk

Signature · 4 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Computers are not intelligent. They only think they are.
#74 lore raw

PATCH v2 6/22 Add generic spl infrastructure

In reply to Aneesh V
Quoted 28 lines · On Sun, 15 May 2011 20:51:24 +0530 Aneesh V <[email protected]> wrote:
Makefile +16 -0
index 384a59e..d3f4bef 100644
@@ -289,6 +289,22 @@ LDPPFLAGS += \
 	$(shell $(LD) --version | \
 	  sed -ne 's/GNU ld version \([0-9][0-9]*\)\.\([0-9][0-9]*\).*/-DLD_MAJOR=\1 -DLD_MINOR=\2/p')
 
+ifeq ($(CONFIG_NAND_U_BOOT),y)
+NAND_SPL = nand_spl
+U_BOOT_NAND = $(obj)u-boot-nand.bin
+endif
+
+ifeq ($(CONFIG_SPL),y)
+.PHONEY : SPL
+ALL += SPL
+endif
+
+ifeq ($(CONFIG_ONENAND_U_BOOT),y)
+ONENAND_IPL = onenand_ipl
+U_BOOT_ONENAND = $(obj)u-boot-onenand.bin
+ONENAND_BIN ?= $(obj)onenand_ipl/onenand-ipl-2k.bin
+endif
+
 __OBJS := $(subst $(obj),,$(OBJS))
 __LIBS := $(subst $(obj),,$(LIBS)) $(subst $(obj),,$(LIBBOARD))
 

Makefile $(obj)u-boot.lds: $(LDSCRIPT) · line 422

Quoted 5 lines
Makefile +2 -0
@@ -402,8 +418,13 @@ $(obj)u-boot.lds: $(LDSCRIPT)
 		$(CPP) $(CPPFLAGS) $(LDPPFLAGS) -ansi -D__ASSEMBLY__ -P - <$^ >$@
 
 nand_spl:	$(TIMESTAMP_FILE) $(VERSION_FILE) depend
+
+$(NAND_SPL):	$(TIMESTAMP_FILE) $(VERSION_FILE) depend

You are reverting part of e935a374dbe5c745fdde05b2b07ced0bbe70887f. Merge accident?

Makefile clobber: clean · line 1166

Quoted 5 lines
Makefile +1 -0
@@ -1141,12 +1163,14 @@ clobber:	clean
 	@rm -f $(obj)u-boot $(obj)u-boot.map $(obj)u-boot.hex $(ALL)
 	@rm -f $(obj)u-boot.kwb
 	@rm -f $(obj)u-boot.imx
+	@rm -f $(obj)MLO

What is MLO?

Quoted 5 lines
arch/arm/include/asm/global_data.h +0 -0
index 2a84d27..2ce020e 100644

arch/arm/include/asm/global_data.h typedef struct global_data { · line 97

Quoted 9 lines
arch/arm/include/asm/global_data.h +5 -0
@@ -89,6 +89,11 @@ typedef	struct	global_data {
 #define GD_FLG_DISABLE_CONSOLE	0x00040	/* Disable console (in & out)		*/
 #define GD_FLG_ENV_READY	0x00080	/* Environment imported into hash table	*/
 
+#ifdef CONFIG_PRELOADER
+/* SPL works from internal RAM. gd pointer can be in .data section */
+#define DECLARE_GLOBAL_DATA_PTR     extern gd_t *gd
+#else
 #define DECLARE_GLOBAL_DATA_PTR     register volatile gd_t *gd asm ("r8")
+#endif

Is this appropriate for all ARM boards (e.g. those currently using nand_spl)?

-Scott

author
#75 lore raw

PATCH v2 6/22 Add generic spl infrastructure

Hi Scott,

Quoted 33 lines · Scott Wood
Quoted 30 lines · On Sun, 15 May 2011 20:51:24 +0530 Aneesh V<[email protected]> wrote:
Makefile +16 -0
index 384a59e..d3f4bef 100644
@@ -289,6 +289,22 @@ LDPPFLAGS += \
  	$(shell $(LD) --version | \
  	  sed -ne 's/GNU ld version \([0-9][0-9]*\)\.\([0-9][0-9]*\).*/-DLD_MAJOR=\1 -DLD_MINOR=\2/p')
 
+ifeq ($(CONFIG_NAND_U_BOOT),y)
+NAND_SPL = nand_spl
+U_BOOT_NAND = $(obj)u-boot-nand.bin
+endif
+
+ifeq ($(CONFIG_SPL),y)
+.PHONEY : SPL
+ALL += SPL
+endif
+
+ifeq ($(CONFIG_ONENAND_U_BOOT),y)
+ONENAND_IPL = onenand_ipl
+U_BOOT_ONENAND = $(obj)u-boot-onenand.bin
+ONENAND_BIN ?= $(obj)onenand_ipl/onenand-ipl-2k.bin
+endif
+
  __OBJS := $(subst $(obj),,$(OBJS))
  __LIBS := $(subst $(obj),,$(LIBS)) $(subst $(obj),,$(LIBBOARD))
 
@@ -402,8 +418,13 @@ $(obj)u-boot.lds: $(LDSCRIPT)
  		$(CPP) $(CPPFLAGS) $(LDPPFLAGS) -ansi -D__ASSEMBLY__ -P -<$^>$@
 
Quoted 7 lines

Makefile $(obj)u-boot.lds: $(LDSCRIPT) · line 422

Quoted 3 lines
Makefile +2 -0
  nand_spl:	$(TIMESTAMP_FILE) $(VERSION_FILE) depend
+
+$(NAND_SPL):	$(TIMESTAMP_FILE) $(VERSION_FILE) depend

You are reverting part of e935a374dbe5c745fdde05b2b07ced0bbe70887f. Merge accident?

Oops! That indeed seems like a merge accident. I will correct it in the next version.

Quoted 7 lines

Makefile clobber: clean · line 1166

Quoted 5 lines
Makefile +1 -0
@@ -1141,12 +1163,14 @@ clobber:	clean
  	@rm -f $(obj)u-boot $(obj)u-boot.map $(obj)u-boot.hex $(ALL)
  	@rm -f $(obj)u-boot.kwb
  	@rm -f $(obj)u-boot.imx
+	@rm -f $(obj)MLO

What is MLO?

MLO is the name of SPL created for OMAP. ROM code expects a file with this name as the first image when it boots from FAT.

Quoted 9 lines
Quoted 9 lines
arch/arm/include/asm/global_data.h +0 -0
index 2a84d27..2ce020e 100644
@@ -89,6 +89,11 @@ typedef	struct	global_data {
  #define GD_FLG_DISABLE_CONSOLE	0x00040	/* Disable console (in&  out)		*/
  #define GD_FLG_ENV_READY	0x00080	/* Environment imported into hash table	*/
 
Quoted 9 lines

arch/arm/include/asm/global_data.h typedef struct global_data { · line 97

Quoted 6 lines
arch/arm/include/asm/global_data.h +5 -0
+#ifdef CONFIG_PRELOADER
+/* SPL works from internal RAM. gd pointer can be in .data section */
+#define DECLARE_GLOBAL_DATA_PTR     extern gd_t *gd
+#else
  #define DECLARE_GLOBAL_DATA_PTR     register volatile gd_t *gd asm ("r8")
+#endif

Is this appropriate for all ARM boards (e.g. those currently using nand_spl)?

None of the SPL's other than this one seems to be using global data today. If anybody wants to use it this seems to be the logical option for me because by definition SPL runs from some kind of RAM so global data can be placed in the .data section of SPL.

best regards,
Aneesh

#76 lore raw

PATCH v2 6/22 Add generic spl infrastructure

Dear Aneesh V,

Quoted 5 lines · In message <[email protected]> you wrote:
Quoted 2 lines

What is MLO?

MLO is the name of SPL created for OMAP. ROM code expects a file with this name as the first image when it boots from FAT.

What does MLO mean?

Quoted 10 lines
Quoted 9 lines

arch/arm/include/asm/global_data.h typedef struct global_data { · line 97

Quoted 6 lines
arch/arm/include/asm/global_data.h +5 -0
+#ifdef CONFIG_PRELOADER
+/* SPL works from internal RAM. gd pointer can be in .data section */
+#define DECLARE_GLOBAL_DATA_PTR     extern gd_t *gd
+#else
  #define DECLARE_GLOBAL_DATA_PTR     register volatile gd_t *gd asm ("r8")
+#endif

Is this appropriate for all ARM boards (e.g. those currently using nand_spl)?

Quoted 4 lines

None of the SPL's other than this one seems to be using global data today. If anybody wants to use it this seems to be the logical option for me because by definition SPL runs from some kind of RAM so global data can be placed in the .data section of SPL.

But that's not what you are doing. You are not changing the storage of the global data itself, you are changing the storage of the POINTER TO the global data - and this makes no sense to me. The pointer can certainly remain in a register even if the data itself is somewhere else.

This will save us this #ifdef here.

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Witch!  Witch!  They'll burn ya!
	-- Hag, "Tomorrow is Yesterday", stardate unknown
author
#77 lore raw

PATCH v2 6/22 Add generic spl infrastructure

Hi Aneesh,

Quoted 10 lines · Wolfgang Denk

Dear Aneesh V,

Quoted 5 lines · In message<[email protected]> you wrote:
Quoted 2 lines

What is MLO?

MLO is the name of SPL created for OMAP. ROM code expects a file with this name as the first image when it boots from FAT.

What does MLO mean?

On looking up ROM code spec, this seems to stand for "MMC/SD Loader"

Quoted 17 lines
Quoted 12 lines
Quoted 11 lines

arch/arm/include/asm/global_data.h typedef struct global_data { · line 97

Quoted 8 lines
arch/arm/include/asm/global_data.h +5 -0
+#ifdef CONFIG_PRELOADER
+/* SPL works from internal RAM. gd pointer can be in .data section */
+#define DECLARE_GLOBAL_DATA_PTR     extern gd_t *gd
+#else
   #define DECLARE_GLOBAL_DATA_PTR     register volatile gd_t *gd asm ("r8")
+#endif

Is this appropriate for all ARM boards (e.g. those currently using nand_spl)?

Quoted 4 lines

None of the SPL's other than this one seems to be using global data today. If anybody wants to use it this seems to be the logical option for me because by definition SPL runs from some kind of RAM so global data can be placed in the .data section of SPL.

Quoted 5 lines

But that's not what you are doing. You are not changing the storage of the global data itself, you are changing the storage of the POINTER TO the global data - and this makes no sense to me. The pointer can certainly remain in a register even if the data itself is somewhere else.

Why do we want to waste a register in the entire SPL when global data can be accessed directly from .data section?

best regards,
Aneesh

#78 lore raw

PATCH v2 6/22 Add generic spl infrastructure

Dear Aneesh V,

Quoted 9 lines · In message <[email protected]> you wrote:
Quoted 6 lines

But that's not what you are doing. You are not changing the storage of the global data itself, you are changing the storage of the POINTER TO the global data - and this makes no sense to me. The pointer can certainly remain in a register even if the data itself is somewhere else.

Why do we want to waste a register in the entire SPL when global data can be accessed directly from .data section?

Because the resulting code is smaller?

I did not measure it on your hardware with your compiler, but IIRC this was the result on some other processors.

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It may be that your whole purpose in life is simply  to  serve  as  a
warning to others.
author
#79 lore raw

PATCH v2 6/22 Add generic spl infrastructure

Hi Wolfgang,

Quoted 10 lines · Wolfgang Denk

Dear Aneesh V,

Quoted 7 lines · In message<[email protected]> you wrote:
Quoted 6 lines

But that's not what you are doing. You are not changing the storage of the global data itself, you are changing the storage of the POINTER TO the global data - and this makes no sense to me. The pointer can certainly remain in a register even if the data itself is somewhere else.

Quoted 5 lines
Quoted 2 lines

Why do we want to waste a register in the entire SPL when global data can be accessed directly from .data section?

Because the resulting code is smaller?

I was thinking that it may be faster. More number of registers at disposal may mean less number of pushes to the stack, right? I am not sure if this will make a significant difference.

best regards,
Aneesh

#80 lore raw

PATCH v2 6/22 Add generic spl infrastructure

Dear Aneesh V,

Quoted 4 lines · In message <[email protected]> you wrote:

I was thinking that it may be faster. More number of registers at disposal may mean less number of pushes to the stack, right? I am not sure if this will make a significant difference.

It does not make a significant difference. Which is the reason I vote for avoiding the #ifdef.

Best regards,

Wolfgang Denk

Signature · 4 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Never put off until tomorrow what you can put off indefinitely.
author
#81 lore raw

PATCH v2 6/22 Add generic spl infrastructure

Hi Wolfgang,

Quoted 11 lines · Wolfgang Denk

Dear Aneesh V,

Quoted 4 lines · In message<[email protected]> you wrote:

I was thinking that it may be faster. More number of registers at disposal may mean less number of pushes to the stack, right? I am not sure if this will make a significant difference.

It does not make a significant difference. Which is the reason I vote for avoiding the #ifdef.

Ok. I shall change it.

best regards,
Aneesh

#82 lore raw

PATCH v2 6/22 Add generic spl infrastructure

In reply to Aneesh V
Quoted 21 lines · On Tue, 17 May 2011 12:24:34 +0530 Aneesh V <[email protected]> wrote:
Quoted 10 lines · Scott Wood
Quoted 8 lines · On Sun, 15 May 2011 20:51:24 +0530 Aneesh V<[email protected]> wrote:
arch/arm/include/asm/global_data.h +0 -0
index 2a84d27..2ce020e 100644
@@ -89,6 +89,11 @@ typedef	struct	global_data {
  #define GD_FLG_DISABLE_CONSOLE	0x00040	/* Disable console (in&  out)		*/
  #define GD_FLG_ENV_READY	0x00080	/* Environment imported into hash table	*/
 
Quoted 9 lines

arch/arm/include/asm/global_data.h typedef struct global_data { · line 97

Quoted 6 lines
arch/arm/include/asm/global_data.h +5 -0
+#ifdef CONFIG_PRELOADER
+/* SPL works from internal RAM. gd pointer can be in .data section */
+#define DECLARE_GLOBAL_DATA_PTR     extern gd_t *gd
+#else
  #define DECLARE_GLOBAL_DATA_PTR     register volatile gd_t *gd asm ("r8")
+#endif

Is this appropriate for all ARM boards (e.g. those currently using nand_spl)?

Quoted 4 lines

None of the SPL's other than this one seems to be using global data today. If anybody wants to use it this seems to be the logical option for me because by definition SPL runs from some kind of RAM so global data can be placed in the .data section of SPL.

There is nand_spl code, including ARM, that uses gd. E.g. putc() in board/davinci/da8xxevm/hawkboard_nand_spl.c.

This comment also applies to the other uses of CONFIG_PRELOADER -- are all of those changes appropriate for the existing nand_spl users?

-Scott

author
#83 lore raw

PATCH v2 6/22 Add generic spl infrastructure

Hi Scott,

Quoted 29 lines · Scott Wood
Quoted 21 lines · On Tue, 17 May 2011 12:24:34 +0530 Aneesh V<[email protected]> wrote:
Quoted 10 lines · Scott Wood
Quoted 8 lines · On Sun, 15 May 2011 20:51:24 +0530 Aneesh V<[email protected]> wrote:
arch/arm/include/asm/global_data.h +0 -0
index 2a84d27..2ce020e 100644
@@ -89,6 +89,11 @@ typedef	struct	global_data {
   #define GD_FLG_DISABLE_CONSOLE	0x00040	/* Disable console (in&   out)		*/
   #define GD_FLG_ENV_READY	0x00080	/* Environment imported into hash table	*/
 
Quoted 9 lines

arch/arm/include/asm/global_data.h typedef struct global_data { · line 97

Quoted 6 lines
arch/arm/include/asm/global_data.h +5 -0
+#ifdef CONFIG_PRELOADER
+/* SPL works from internal RAM. gd pointer can be in .data section */
+#define DECLARE_GLOBAL_DATA_PTR     extern gd_t *gd
+#else
   #define DECLARE_GLOBAL_DATA_PTR     register volatile gd_t *gd asm ("r8")
+#endif

Is this appropriate for all ARM boards (e.g. those currently using nand_spl)?

Quoted 4 lines

None of the SPL's other than this one seems to be using global data today. If anybody wants to use it this seems to be the logical option for me because by definition SPL runs from some kind of RAM so global data can be placed in the .data section of SPL.

Quoted 5 lines

There is nand_spl code, including ARM, that uses gd. E.g. putc() in board/davinci/da8xxevm/hawkboard_nand_spl.c.

This comment also applies to the other uses of CONFIG_PRELOADER -- are all of those changes appropriate for the existing nand_spl users?

I would probably revert the change as advised by Wolfgang.

best regards,
Aneesh

author
#84 lore raw

PATCH v2 7/22 armv7: start.S: add SPL support

In reply to Aneesh V

Changes for supporting SPL

---
 arch/arm/cpu/armv7/start.S |   36 +++++++++++++++++++++++++-----------
 1 files changed, 25 insertions(+), 11 deletions(-)
arch/arm/cpu/armv7/start.S +25 -11
index 13178cd..f92c6d9 100644
@@ -42,7 +42,16 @@ _start: b	reset
 	ldr	pc, _not_used
 	ldr	pc, _irq
 	ldr	pc, _fiq
-
+#ifdef CONFIG_PRELOADER
+_undefined_instruction: .word _undefined_instruction
+_software_interrupt:	.word _software_interrupt
+_prefetch_abort:	.word _prefetch_abort
+_data_abort:		.word _data_abort
+_not_used:		.word _not_used
+_irq:			.word _irq
+_fiq:			.word _fiq
+_pad:			.word 0x12345678 /* now 16*4=64 */
+#else
 _undefined_instruction: .word undefined_instruction
 _software_interrupt:	.word software_interrupt
 _prefetch_abort:	.word prefetch_abort
@@ -51,6 +60,8 @@ _not_used:		.word not_used
 _irq:			.word irq
 _fiq:			.word fiq
 _pad:			.word 0x12345678 /* now 16*4=64 */
+#endif	/* CONFIG_PRELOADER */
+
 .global _end_vect
 _end_vect:
 
@@ -187,10 +198,9 @@ stack_setup:
 	mov	sp, r4
 
 	adr	r0, _start
-#ifndef CONFIG_PRELOADER
 	cmp	r0, r6
+	moveq	r9, #0		/* no relocation. relocation offset(r9) = 0 */
 	beq	clear_bss		/* skip relocation */
-#endif
 	mov	r1, r6			/* r1 <- scratch for copy_loop */
 	ldr	r3, _image_copy_end_ofs
 	add	r2, r0, r3		/* r2 <- source end address	    */
@@ -240,6 +250,15 @@ fixnext:
 	add	r2, r2, #8		/* each rel.dyn entry is 8 bytes */
 	cmp	r2, r3
 	blo	fixloop
+	b	clear_bss
+_rel_dyn_start_ofs:
+	.word __rel_dyn_start - _start
+_rel_dyn_end_ofs:
+	.word __rel_dyn_end - _start
+_dynsym_start_ofs:
+	.word __dynsym_start - _start
+
+#endif	/* #ifndef CONFIG_PRELOADER */
 
 clear_bss:
 	ldr	r0, _bss_start_ofs
@@ -253,7 +272,6 @@ clbss_l:str	r2, [r0]		/* clear loop...		    */
 	add	r0, r0, #4
 	cmp	r0, r1
 	bne	clbss_l
-#endif	/* #ifndef CONFIG_PRELOADER */
 
 /*
  * We are done. Do not return, instead branch to second part of board
@@ -281,13 +299,6 @@ jump_2_ram:
 _board_init_r_ofs:
 	.word board_init_r - _start
 
-_rel_dyn_start_ofs:
-	.word __rel_dyn_start - _start
-_rel_dyn_end_ofs:
-	.word __rel_dyn_end - _start
-_dynsym_start_ofs:
-	.word __dynsym_start - _start
-
 /*************************************************************************
  *
  * CPU_init_critical registers
@@ -332,6 +343,8 @@ cpu_init_crit:
 	bl	lowlevel_init		@ go setup pll,mux,memory
 	mov	lr, ip			@ restore link
 	mov	pc, lr			@ back to my caller
+
+#ifndef CONFIG_PRELOADER
 /*
  *************************************************************************
  *
@@ -520,3 +533,4 @@ fiq:
 	bl	do_fiq
 
 #endif
+#endif /* CONFIG_PRELOADER */
Signature · 1 line
1.7.0.4
#85 lore raw

PATCH v2 7/22 armv7: start.S: add SPL support

Dear Aneesh V,

Quoted 1 line · In message <[email protected]> you wrote:

Changes for supporting SPL

As is, this is dead code. I think this patch should be much later in this patch series.

Best regards,

Wolfgang Denk

Signature · 7 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"You ain't experienced..." "Well, nor are you." "That's true. But the
point is ... the point is ... the point is we've been not experienced
for a lot longer than you. We've got  a  lot  of  experience  of  not
having any experience."           - Terry Pratchett, _Witches Abroad_
author
#86 lore raw

PATCH v2 8/22 omap: add spl support

In reply to Aneesh V

Add the basic spl framework and linker script common for OMAP3/4 platforms.

---
 spl/board/ti/spl-omap.c   |   47 ++++++++++++++++++++++++++++++++++
 spl/board/ti/spl-omap.lds |   62 +++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 109 insertions(+), 0 deletions(-)
 create mode 100644 spl/board/ti/spl-omap.c
 create mode 100644 spl/board/ti/spl-omap.lds
spl/board/ti/spl-omap.c new file +47 -0
new file mode 100644
index 0000000..0e08f4f
@@ -0,0 +1,47 @@
+/*
+ *
+ * Clock initialization for OMAP4
+ *
+ * (C) Copyright 2010
+ * Texas Instruments, <www.ti.com>
+ *
+ * Aneesh V <[email protected]>
+ *
+ * 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 <asm/u-boot.h>
+#include <asm/arch/sys_proto.h>
+#include <timestamp_autogenerated.h>
+
+/* Define global data structure pointer to it*/
+gd_t gdata __attribute__ ((section(".data")));
+bd_t bdata __attribute__ ((section(".data")));
+gd_t *gd = &gdata;
+
+void board_init_f(ulong dummy)
+{
+	relocate_code(CONFIG_SYS_SPL_STACK, &gdata, CONFIG_SYS_SPL_TEXT_BASE);
+}
+
+void board_init_r(gd_t *id, ulong dummy)
+{
+	for (;;)
+		;
+}
spl/board/ti/spl-omap.lds new file +62 -0

62 lines not on this page · raw message

Signature · 1 line
1.7.0.4
#87 lore raw

PATCH v2 8/22 omap: add spl support

Dear Aneesh V,

Quoted 10 lines · In message <[email protected]> you wrote:

Add the basic spl framework and linker script common for OMAP3/4 platforms.

---
 spl/board/ti/spl-omap.c   |   47 ++++++++++++++++++++++++++++++++++
 spl/board/ti/spl-omap.lds |   62 +++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 109 insertions(+), 0 deletions(-)
 create mode 100644 spl/board/ti/spl-omap.c
 create mode 100644 spl/board/ti/spl-omap.lds

Again, this appears to be not the right order.

I think, in the first step of this series, we should move the existing code from nand_spl and onenand_ipl into something like spl/nand and spl/onenand, respectivly, and make sure all teh existing systems still build. The we can add more such support.

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
When choosing between two evils, I always like to take the  one  I've
never tried before.                     -- Mae West, "Klondike Annie"
author
#88 lore raw

PATCH v2 8/22 omap: add spl support

Hi Wolfgang,

Quoted 14 lines · Wolfgang Denk

Dear Aneesh V,

Quoted 10 lines · In message<[email protected]> you wrote:

Add the basic spl framework and linker script common for OMAP3/4 platforms.

---
  spl/board/ti/spl-omap.c   |   47 ++++++++++++++++++++++++++++++++++
  spl/board/ti/spl-omap.lds |   62 +++++++++++++++++++++++++++++++++++++++++++++
  2 files changed, 109 insertions(+), 0 deletions(-)

create mode 100644 spl/board/ti/spl-omap.c
create mode 100644 spl/board/ti/spl-omap.lds

Quoted 6 lines

Again, this appears to be not the right order.

I think, in the first step of this series, we should move the existing code from nand_spl and onenand_ipl into something like spl/nand and spl/onenand, respectivly, and make sure all teh existing systems still build. The we can add more such support.

IMHO, we should just have spl/board/<vendor>/<board>/ .

Let spl/board/<vendor>/<board>/Makefile decide what it wants to build.

I mean something like this(similar changes for ONENAND):

+.PHONEY : SPL
+SPL :$(TIMESTAMP_FILE) $(VERSION_FILE) depend tools
+ $(MAKE) -C spl/board/$(BOARDDIR) all
+
+ifeq ($(CONFIG_SPL),y)
+ALL += SPL
+endif
+
__OBJS := $(subst $(obj),,$(OBJS))
__LIBS := $(subst $(obj),,$(LIBS)) $(subst $(obj),,$(LIBBOARD))

@@ -401,11 +409,8 @@ $(LDSCRIPT): depend
$(obj)u-boot.lds: $(LDSCRIPT)
$(CPP) $(CPPFLAGS) $(LDPPFLAGS) -ansi -D__ASSEMBLY__ -P - <$^ >$@

-nand_spl: $(TIMESTAMP_FILE) $(VERSION_FILE) depend
- $(MAKE) -C nand_spl/board/$(BOARDDIR) all
-
-$(obj)u-boot-nand.bin: nand_spl $(obj)u-boot.bin
- cat $(obj)nand_spl/u-boot-spl-16k.bin $(obj)u-boot.bin >
$(obj)u-boot-nand.bin
+$(obj)u-boot-nand.bin: SPL $(obj)u-boot.bin
+ cat $(obj)spl/u-boot-spl-16k.bin $(obj)u-boot.bin > $(obj)u-boot-nand.bin

Quoted 5 lines

Best regards,

Wolfgang Denk

#89 lore raw

PATCH v2 8/22 omap: add spl support

Dear Aneesh V,

Quoted 8 lines · In message <[email protected]> you wrote:
Quoted 7 lines

Again, this appears to be not the right order.

I think, in the first step of this series, we should move the existing code from nand_spl and onenand_ipl into something like spl/nand and spl/onenand, respectivly, and make sure all teh existing systems still build. The we can add more such support.

Quoted 4 lines

IMHO, we should just have spl/board/<vendor>/<board>/ .

Let spl/board/<vendor>/<board>/Makefile decide what it wants to build.

There are common, board independent parts both in spl/nand and spl/onenand.

Best regards,

Wolfgang Denk

Signature · 6 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
[Doctors and Bartenders], We both get the same two kinds of customers
-- the living and the dying.
	-- Dr. Boyce, "The Menagerie" ("The Cage"), stardate unknown
author
#90 lore raw

PATCH v2 8/22 omap: add spl support

Hi Wolfgang,

Quoted 11 lines · Wolfgang Denk

Dear Aneesh V,

Quoted 8 lines · In message<[email protected]> you wrote:
Quoted 7 lines

Again, this appears to be not the right order.

I think, in the first step of this series, we should move the existing code from nand_spl and onenand_ipl into something like spl/nand and spl/onenand, respectivly, and make sure all teh existing systems still build. The we can add more such support.

Quoted 8 lines
Quoted 4 lines

IMHO, we should just have spl/board/<vendor>/<board>/ .

Let spl/board/<vendor>/<board>/Makefile decide what it wants to build.

There are common, board independent parts both in spl/nand and spl/onenand.

How about having them at the root level in 'spl/' ?

best regards,
Aneesh

#91 lore raw

PATCH v2 8/22 omap: add spl support

Dear Aneesh V,

Quoted 5 lines · In message <[email protected]> you wrote:
Quoted 3 lines

There are common, board independent parts both in spl/nand and spl/onenand.

How about having them at the root level in 'spl/' ?

Why? It seems more logical to me to group nand and onenand related files in their own subdirectories.

Best regards,

Wolfgang Denk

Signature · 4 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Quantum Mechanics is God's version of "Trust me."
author
#92 lore raw

PATCH v2 8/22 omap: add spl support

Hi Wolfgang,

Quoted 11 lines · Wolfgang Denk

Dear Aneesh V,

Quoted 5 lines · In message<[email protected]> you wrote:
Quoted 3 lines

There are common, board independent parts both in spl/nand and spl/onenand.

How about having them at the root level in 'spl/' ?

Why? It seems more logical to me to group nand and onenand related files in their own subdirectories.

I do not have any issue in having media specific files in their respective directories. However, I would like to see the 'Makefile's coming from the same directory tree irrespective of the media. So, how about something like this:

spl/
mmc/
nand/
one-nand/
board/<vendor>/<board>/Makefile

The idea is to have the board level Makefile in 'spl/board/<vendor> /<board>/' no matter what the SPL type is. This will help in better consolidation of SPLs.

I see 3 SPL use-cases in general:
1. A single SPL that supports multiple media(suitable for SoCs with large internal RAM)
2. A single SPL supporting a single media(the board supports only one media)
3. Multiple SPLs for the same board each supporting a different memory device(maybe preferred over 1 to keep the foot-print of each small).

Supporting (1) and (2) is straight forward with the above directory structure.

To support (3) the board level Makefile should conditionally include the respective image file in the target 'all' based on CONFIG options. For instance 'all' may include 'onenand-ipl-2k.bin' if CONFIG_ONENAND_U_BOOT is defined and so on.

Please let me know if any of you have better ideas. I would like to finalize on this before re-working on my patch-set.

best regards,
Aneesh

author
#93 lore raw

PATCH v2 8/22 omap: add spl support

Hi Wolfgang,

Quoted 41 lines · Aneesh V

Hi Wolfgang,

Quoted 11 lines · Wolfgang Denk

Dear Aneesh V,

Quoted 5 lines · In message<[email protected]> you wrote:
Quoted 3 lines

There are common, board independent parts both in spl/nand and spl/onenand.

How about having them at the root level in 'spl/' ?

Why? It seems more logical to me to group nand and onenand related files in their own subdirectories.

I do not have any issue in having media specific files in their respective directories. However, I would like to see the 'Makefile's coming from the same directory tree irrespective of the media. So, how about something like this:

spl/
mmc/
nand/
one-nand/
board/<vendor>/<board>/Makefile

The idea is to have the board level Makefile in 'spl/board/<vendor> /<board>/' no matter what the SPL type is. This will help in better consolidation of SPLs.

I see 3 SPL use-cases in general:
1. A single SPL that supports multiple media(suitable for SoCs with large internal RAM)
2. A single SPL supporting a single media(the board supports only one media)
3. Multiple SPLs for the same board each supporting a different memory device(maybe preferred over 1 to keep the foot-print of each small).

Supporting (1) and (2) is straight forward with the above directory structure.

Quoted 7 lines

To support (3) the board level Makefile should conditionally include the respective image file in the target 'all' based on CONFIG options. For instance 'all' may include 'onenand-ipl-2k.bin' if CONFIG_ONENAND_U_BOOT is defined and so on.

Please let me know if any of you have better ideas. I would like to finalize on this before re-working on my patch-set.

What's your views on the above scheme.

best regards,
Aneesh

author
#94 lore raw

PATCH v2 8/22 omap: add spl support

In reply to Aneesh V

Hi Wolfgang,

Quoted 41 lines · Aneesh V

Hi Wolfgang,

Quoted 11 lines · Wolfgang Denk

Dear Aneesh V,

Quoted 5 lines · In message<[email protected]> you wrote:
Quoted 3 lines

There are common, board independent parts both in spl/nand and spl/onenand.

How about having them at the root level in 'spl/' ?

Why? It seems more logical to me to group nand and onenand related files in their own subdirectories.

I do not have any issue in having media specific files in their respective directories. However, I would like to see the 'Makefile's coming from the same directory tree irrespective of the media. So, how about something like this:

spl/
mmc/
nand/
one-nand/
board/<vendor>/<board>/Makefile

The idea is to have the board level Makefile in 'spl/board/<vendor> /<board>/' no matter what the SPL type is. This will help in better consolidation of SPLs.

I see 3 SPL use-cases in general:
1. A single SPL that supports multiple media(suitable for SoCs with large internal RAM)
2. A single SPL supporting a single media(the board supports only one media)
3. Multiple SPLs for the same board each supporting a different memory device(maybe preferred over 1 to keep the foot-print of each small).

Supporting (1) and (2) is straight forward with the above directory structure.

Quoted 7 lines

To support (3) the board level Makefile should conditionally include the respective image file in the target 'all' based on CONFIG options. For instance 'all' may include 'onenand-ipl-2k.bin' if CONFIG_ONENAND_U_BOOT is defined and so on.

Please let me know if any of you have better ideas. I would like to finalize on this before re-working on my patch-set.

Are you fine with this scheme. Appreciate if you could let me know your thoughts on this. I am waiting for your inputs to start the re-work.

best regards,
Aneesh

#95 lore raw

PATCH v2 8/22 omap: add spl support

In reply to Aneesh V

Dear Aneesh V,

Quoted 11 lines · In message <[email protected]> you wrote:

I do not have any issue in having media specific files in their respective directories. However, I would like to see the 'Makefile's coming from the same directory tree irrespective of the media. So, how about something like this:

spl/
mmc/
nand/
one-nand/
board/<vendor>/<board>/Makefile

Actually that would be

	 board/[<vendor>/]<board>/
Quoted 3 lines

The idea is to have the board level Makefile in 'spl/board/<vendor> /<board>/' no matter what the SPL type is. This will help in better consolidation of SPLs.

OK.

Quoted 5 lines

I see 3 SPL use-cases in general:
1. A single SPL that supports multiple media(suitable for SoCs with large internal RAM)
2. A single SPL supporting a single media(the board supports only one media)

1. and 2. are actually the same (2. being the special case of N=1)

Quoted 11 lines

3. Multiple SPLs for the same board each supporting a different memory device(maybe preferred over 1 to keep the foot-print of each small).

Supporting (1) and (2) is straight forward with the above directory structure.

To support (3) the board level Makefile should conditionally include the respective image file in the target 'all' based on CONFIG options. For instance 'all' may include 'onenand-ipl-2k.bin' if CONFIG_ONENAND_U_BOOT is defined and so on.

I don't get this. Why don't we just pass the required make target from the top level Makefile? If we want to build "onenand-ipl-2k.bin" then this would result in running "make onenand-ipl-2k.bin" in the respective directory - this is then also independent of whether this image contains support for one specific boot device or for any set of different devices.

Best regards,

Wolfgang Denk

Signature · 6 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I object to intellect without discipline;  I object to power without
constructive purpose.
	-- Spock, "The Squire of Gothos", stardate 2124.5
author
#96 lore raw

PATCH v2 8/22 omap: add spl support

Dear Wolfgang,

Quoted 45 lines · Wolfgang Denk

Dear Aneesh V,

Quoted 11 lines · In message<[email protected]> you wrote:

I do not have any issue in having media specific files in their respective directories. However, I would like to see the 'Makefile's coming from the same directory tree irrespective of the media. So, how about something like this:

spl/
mmc/
nand/
one-nand/
board/<vendor>/<board>/Makefile

Actually that would be

	 board/[<vendor>/]<board>/
Quoted 3 lines

The idea is to have the board level Makefile in 'spl/board/<vendor> /<board>/' no matter what the SPL type is. This will help in better consolidation of SPLs.

OK.

Quoted 5 lines

I see 3 SPL use-cases in general:
1. A single SPL that supports multiple media(suitable for SoCs with large internal RAM)
2. A single SPL supporting a single media(the board supports only one media)

1. and 2. are actually the same (2. being the special case of N=1)

Quoted 11 lines

3. Multiple SPLs for the same board each supporting a different memory device(maybe preferred over 1 to keep the foot-print of each small).

Supporting (1) and (2) is straight forward with the above directory structure.

To support (3) the board level Makefile should conditionally include the respective image file in the target 'all' based on CONFIG options. For instance 'all' may include 'onenand-ipl-2k.bin' if CONFIG_ONENAND_U_BOOT is defined and so on.

Quoted 6 lines

I don't get this. Why don't we just pass the required make target from the top level Makefile? If we want to build "onenand-ipl-2k.bin" then this would result in running "make onenand-ipl-2k.bin" in the respective directory - this is then also independent of whether this image contains support for one specific boot device or for any set of different devices.

Then you will have to deal with many such images in the top-level Makefile(u-boot/Makefile). Instead why not have just one rule like the below in the top-level Makefile for all the different spl's:

SPL :$(TIMESTAMP_FILE) $(VERSION_FILE) depend tools

     $(MAKE) -C spl/board/$(BOARDDIR) all

And leave the rest to the board level Makefiles

Of course, this is assuming the existing Makefile structure. With the new Makefile structure you are suggesting this may not hold good.

#97 lore raw

PATCH v2 8/22 omap: add spl support

Dear Aneesh,

Quoted 13 lines · In message <[email protected]> you wrote:
Quoted 7 lines

I don't get this. Why don't we just pass the required make target from the top level Makefile? If we want to build "onenand-ipl-2k.bin" then this would result in running "make onenand-ipl-2k.bin" in the respective directory - this is then also independent of whether this image contains support for one specific boot device or for any set of different devices.

Then you will have to deal with many such images in the top-level Makefile(u-boot/Makefile). Instead why not have just one rule like the below in the top-level Makefile for all the different spl's:

Quoted 4 lines

SPL :$(TIMESTAMP_FILE) $(VERSION_FILE) depend tools

     $(MAKE) -C spl/board/$(BOARDDIR) all

And leave the rest to the board level Makefiles

We just discussed that there are cases where there may be no board level Makefile be needed at all, because there is no board specific code to handle.

Also, why would there be many such images? We might just want to use more reasonable names. We have "u-boot.bin", and this works fine for all boards, so why cannot we make it that "u-boot-nand.bin" works for all boards booting from NAND, and in general "u-boot-<DEV>.bin" works for all boards booting from a <DEV> boot device?

Instead of "onenand-ipl-2k.bin", we would just have a generic "u-boot-onenand.bin"

Quoted 2 lines

Of course, this is assuming the existing Makefile structure. With the new Makefile structure you are suggesting this may not hold good.

Why not?

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Wenn das dann in die Hose geht, nehme ich es auf meine Kappe.
                                         -- Rudi V?ller, 15. Nov 2003
author
#98 lore raw

PATCH v2 8/22 omap: add spl support

Dear Wolfgang,

Quoted 31 lines · Wolfgang Denk

Dear Aneesh,

Quoted 13 lines · In message<[email protected]> you wrote:
Quoted 7 lines

I don't get this. Why don't we just pass the required make target from the top level Makefile? If we want to build "onenand-ipl-2k.bin" then this would result in running "make onenand-ipl-2k.bin" in the respective directory - this is then also independent of whether this image contains support for one specific boot device or for any set of different devices.

Then you will have to deal with many such images in the top-level Makefile(u-boot/Makefile). Instead why not have just one rule like the below in the top-level Makefile for all the different spl's:

Quoted 4 lines

SPL :$(TIMESTAMP_FILE) $(VERSION_FILE) depend tools

      $(MAKE) -C spl/board/$(BOARDDIR) all

And leave the rest to the board level Makefiles

We just discussed that there are cases where there may be no board level Makefile be needed at all, because there is no board specific code to handle.

Also, why would there be many such images? We might just want to use more reasonable names. We have "u-boot.bin", and this works fine for all boards, so why cannot we make it that "u-boot-nand.bin" works for all boards booting from NAND, and in general "u-boot-<DEV>.bin" works for all boards booting from a<DEV> boot device?

Quoted 7 lines

Instead of "onenand-ipl-2k.bin", we would just have a generic "u-boot-onenand.bin"

Quoted 2 lines

Of course, this is assuming the existing Makefile structure. With the new Makefile structure you are suggesting this may not hold good.

Why not?

I was saying that my suggestion of delegating everything to board level Makefile will not work with the new top-down approach you are suggesting in the other mail-chain.

best regards,
Aneesh

#99 lore raw

PATCH v2 8/22 omap: add spl support

Dear Aneesh V,

Quoted 9 lines · In message <[email protected]> you wrote:
Quoted 5 lines
Quoted 3 lines

Of course, this is assuming the existing Makefile structure. With the new Makefile structure you are suggesting this may not hold good.

Why not?

I was saying that my suggestion of delegating everything to board level Makefile will not work with the new top-down approach you are suggesting in the other mail-chain.

I did not suggest this. On contrary, I think I pointed out that we might have cases where no board directory (and thus no board specific Makefile) will be needed at all.

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Many Myths are based on truth
	-- Spock, "The Way to Eden",  stardate 5832.3
#100 lore raw

PATCH v2 8/22 omap: add spl support

In reply to Aneesh V
Quoted 8 lines · On Mon, 16 May 2011 19:40:30 +0530 Aneesh V <[email protected]> wrote:

Hi Wolfgang,

Quoted 4 lines · Wolfgang Denk

I think, in the first step of this series, we should move the existing code from nand_spl and onenand_ipl into something like spl/nand and spl/onenand, respectivly, and make sure all teh existing systems still build. The we can add more such support.

Quoted 4 lines

IMHO, we should just have spl/board/<vendor>/<board>/ .

Let spl/board/<vendor>/<board>/Makefile decide what it wants to build.

That's what we do in nand_spl/onenand_spl -- the common files are more like libraries that the board makefile may or may not pull in (e.g. many Freescale boards use nand_boot_fsl_elbc.c or nand_boot_fsl_nfc.c instead of nand_boot.c).

Renaming nand_spl seems like it should be the first step.

Quoted 3 lines

I mean something like this(similar changes for ONENAND):

+.PHONEY : SPL

.PHONY

-Scott

author
#101 lore raw

PATCH v2 8/22 omap: add spl support

Hi Scott,

Quoted 21 lines · Scott Wood
Quoted 8 lines · On Mon, 16 May 2011 19:40:30 +0530 Aneesh V<[email protected]> wrote:

Hi Wolfgang,

Quoted 4 lines · Wolfgang Denk

I think, in the first step of this series, we should move the existing code from nand_spl and onenand_ipl into something like spl/nand and spl/onenand, respectivly, and make sure all teh existing systems still build. The we can add more such support.

Quoted 4 lines

IMHO, we should just have spl/board/<vendor>/<board>/ .

Let spl/board/<vendor>/<board>/Makefile decide what it wants to build.

That's what we do in nand_spl/onenand_spl -- the common files are more like libraries that the board makefile may or may not pull in (e.g. many Freescale boards use nand_boot_fsl_elbc.c or nand_boot_fsl_nfc.c instead of nand_boot.c).

Quoted 7 lines

Renaming nand_spl seems like it should be the first step.

Quoted 3 lines

I mean something like this(similar changes for ONENAND):

+.PHONEY : SPL

.PHONY

Oops! I wonder how it was working then. My real patch too had the same mistake!

best regards,
Aneesh

#102 lore raw

PATCH v2 8/22 omap: add spl support

Quoted 7 lines · On Wed, 18 May 2011 10:35:56 +0530 Aneesh V <[email protected]> wrote:
Quoted 3 lines · Scott Wood
Quoted 1 line

+.PHONEY : SPL

.PHONY

Oops! I wonder how it was working then. My real patch too had the same mistake!

Well, .PHONY is mainly a performance hint if there's no actual file or rule with that name.

-Scott

#103 lore raw

PATCH v2 8/22 omap: add spl support

In reply to Aneesh V

Dear Aneesh V,

Quoted 4 lines · In message <[email protected]> you wrote:

Add the basic spl framework and linker script common for OMAP3/4 platforms.

...

spl/board/ti/spl-omap.c line 47

Quoted 5 lines
spl/board/ti/spl-omap.c new file +5 -0
+void board_init_r(gd_t *id, ulong dummy)
+{
+	for (;;)
+		;
+}

Also, this cannot be right.

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Committee, n.:  A group of men who individually can do nothing but as
a group decide that nothing can be done.                 - Fred Allen
author
#104 lore raw

PATCH v2 8/22 omap: add spl support

Hi Wolfgang,

Quoted 7 lines · Wolfgang Denk

Dear Aneesh V,

Quoted 4 lines · In message<[email protected]> you wrote:

Add the basic spl framework and linker script common for OMAP3/4 platforms.

Quoted 8 lines

...

spl/board/ti/spl-omap.c line 47

Quoted 5 lines
spl/board/ti/spl-omap.c new file +5 -0
+void board_init_r(gd_t *id, ulong dummy)
+{
+	for (;;)
+		;
+}

Also, this cannot be right.

I added the features one by one in the subsequent patches and removed that loop. Maybe I should squash some patches here too.

Quoted 5 lines

Best regards,

Wolfgang Denk

#105 lore raw

PATCH v2 8/22 omap: add spl support

In reply to Aneesh V

Hi Aneesh,

I recently started to work on a similar topic: omap3 (devkit8000) nand_spl support. So I'am really interested in your OMAP4/common work here ;)

In this patch comment you say its common for OMAP3/4 but in preloader_console_init() is a call to omap4_rev_string()):

Quoted 1 line

printf("Texas Instruments %s\n", omap4_rev_string());

Regards
Simon

2011/5/15 Aneesh V <[email protected]>

Quoted 142 lines

Add the basic spl framework and linker script common for OMAP3/4 platforms.

---
 spl/board/ti/spl-omap.c   |   47 ++++++++++++++++++++++++++++++++++
 spl/board/ti/spl-omap.lds |   62
+++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 109 insertions(+), 0 deletions(-)
 create mode 100644 spl/board/ti/spl-omap.c
 create mode 100644 spl/board/ti/spl-omap.lds
spl/board/ti/spl-omap.c new file +40 -0
new file mode 100644
index 0000000..0e08f4f
@@ -0,0 +1,47 @@
+/*
+ *
+ * Clock initialization for OMAP4
+ *
+ * (C) Copyright 2010
+ * Texas Instruments, <www.ti.com>
+ *
+ * Aneesh V <[email protected]>
+ *
+ * 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 <asm/u-boot.h>
+#include <asm/arch/sys_proto.h>
+#include <timestamp_autogenerated.h>
+
+/* Define global data structure pointer to it*/
+gd_t gdata __attribute__ ((section(".data")));
+bd_t bdata __attribute__ ((section(".data")));
+gd_t *gd = &gdata;
+
+void board_init_f(ulong dummy)
+{
+       relocate_code(CONFIG_SYS_SPL_STACK, &gdata,

CONFIG_SYS_SPL_TEXT_BASE);

spl/board/ti/spl-omap.c new file +7 -0
+}
+
+void board_init_r(gd_t *id, ulong dummy)
+{
+       for (;;)
+               ;
+}
spl/board/ti/spl-omap.lds new file +62 -1
new file mode 100644
index 0000000..674ef05
@@ -0,0 +1,62 @@
+/*
+ * (C) Copyright 2002
+ * Gary Jennejohn, DENX Software Engineering, <[email protected]>
+ *
+ * (C) Copyright 2010
+ * Texas Instruments, <www.ti.com>
+ *     Aneesh V <[email protected]>
+ *
+ * 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
+ */
+
+MEMORY { .sram : ORIGIN = CONFIG_SYS_SPL_TEXT_BASE,\
+                LENGTH = CONFIG_SYS_SPL_MAX_SIZE }
+MEMORY { .sdram : ORIGIN = CONFIG_SYS_SPL_BSS_START_ADDR, \
+                 LENGTH = CONFIG_SYS_SPL_BSS_MAX_SIZE }
+
+OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
+OUTPUT_ARCH(arm)
+ENTRY(_start)
+SECTIONS
+{
+       .text      :
+       {
+       __start = .;
+         start.o       (.text)
+         *(.text*)
+       } >.sram
+
+       . = ALIGN(4);
+       .rodata : { *(SORT_BY_ALIGNMENT(.rodata*)) } >.sram
+
+       . = ALIGN(4);
+       .data : { *(SORT_BY_ALIGNMENT(.data*)) } >.sram
+       . = ALIGN(4);
+       __image_copy_end = .;
+       _end = .;
+
+       .bss :
+       {
+               . = ALIGN(4);
+               __bss_start = .;
+               *(.bss*)
+               . = ALIGN(4);
+               __bss_end__ = .;
+       } >.sdram
+}
--

1.7.0.4

_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

author
#106 lore raw

PATCH v2 8/22 omap: add spl support

Hi Simon,

Quoted 9 lines · Simon Schwarz

Hi Aneesh,

I recently started to work on a similar topic: omap3 (devkit8000) nand_spl support. So I'am really interested in your OMAP4/common work here ;)

In this patch comment you say its common for OMAP3/4 but in preloader_console_init() is a call to omap4_rev_string()):

Quoted 1 line

printf("Texas Instruments %s\n", omap4_rev_string());

Thank you for pointing it out. I will change it to omap_rev_string()

best regards,
Aneesh

author
#107 lore raw

PATCH v2 9/22 omap4: add spl support for OMAP4 SDP

In reply to Aneesh V

Adapted from: nand_spl/board/samsung/smdk6400/Makefile

- Add the SPL makefile for OMAP4430 SDP
- Add the necessary CONFIG flags in the board config file

---
V2:
* Changed CONFIG_SYS_SPL_TEXT_BASE to 0x40304350 from 0x40304360. This exact address is needed for EMU devices.
* Removed un-necessary compiler options from CFLAGS and AFLAGS. These are already set by .mk files in U-Boot
* Reorganize the make files to re-use common rules between boards

---
 board/ti/sdp4430/config.mk                         |    3 +-
 include/configs/omap4_sdp4430.h                    |   19 +++++
 spl/board/ti/omap4.mk                              |   77 ++++++++++++++++++++
 spl/board/ti/rules-omap.mk                         |   74 +++++++++++++++++++
 .../config.mk => spl/board/ti/sdp4430/Makefile     |   21 +++---
 5 files changed, 183 insertions(+), 11 deletions(-)
 create mode 100644 spl/board/ti/omap4.mk
 create mode 100644 spl/board/ti/rules-omap.mk
 copy board/ti/sdp4430/config.mk => spl/board/ti/sdp4430/Makefile (63%)
board/ti/sdp4430/config.mk +2 -1
index 33901a7..c62965d 100644
@@ -28,4 +28,5 @@
 # Linux-Kernel is expected to be at 8000'8000, entry 8000'8000
 # (mem base + reserved)
 
-CONFIG_SYS_TEXT_BASE = 0x80e80000
+# 1MB into the SDRAM to allow for SPL's bss at the beginning of SDRAM
+CONFIG_SYS_TEXT_BASE = 0x80100000
include/configs/omap4_sdp4430.h +19 -0
index 0fd08b3..99247df 100644
@@ -121,7 +121,9 @@
 
 /* USB device configuration */
 #define CONFIG_USB_DEVICE		1
+#ifndef CONFIG_PRELOADER
 #define CONFIG_USB_TTY			1
+#endif
 #define CONFIG_SYS_CONSOLE_IS_IN_ENV	1
 
 /* Flash */
@@ -244,4 +246,21 @@
 #define CONFIG_SYS_PL310_BASE	0x48242000
 #endif
 
+/* Defines for Clock init */
+#define CONFIG_SYS_OMAP4_ABE_SYSCK
+
+/* Defines for SDRAM init */
+#define CONFIG_SYS_AUTOMATIC_SDRAM_DETECTION	1
+#define CONFIG_SYS_EMIF_UPDATE_TIMINGS		1
+#define CONFIG_SYS_DEFAULT_LPDDR2_TIMINGS	1
+
+/* Defines for SPL */
+#define CONFIG_SPL
+#define CONFIG_SYS_SPL_TEXT_BASE	0x40304350
+#define CONFIG_SYS_SPL_MAX_SIZE		0x7800	/* 30 K */
+#define CONFIG_SYS_SPL_STACK		LOW_LEVEL_SRAM_STACK
+
+#define CONFIG_SYS_SPL_BSS_START_ADDR	0x80000000
+#define CONFIG_SYS_SPL_BSS_MAX_SIZE	0x80000		/* 512 KB */
+
 #endif /* __CONFIG_H */
spl/board/ti/omap4.mk new file +77 -0

77 lines not on this page · raw message

spl/board/ti/rules-omap.mk new file +74 -0

74 lines not on this page · raw message

spl/board/ti/sdp4430/Makefile renamed from board/ti/sdp4430/config.mk +11 -10
similarity index 63%
copy from board/ti/sdp4430/config.mk
copy to spl/board/ti/sdp4430/Makefile
index 33901a7..81bf51c 100644
@@ -1,9 +1,13 @@
 #
-# (C) Copyright 2006-2009
-# Texas Instruments Incorporated, <www.ti.com>
+# (C) Copyright 2006-2007
+# Stefan Roese, DENX Software Engineering, sr at denx.de.
 #
-# OMAP 4430 SDP
-# see http://www.ti.com/ for more information on Texas Instruments
+# (C) Copyright 2008
+# Guennadi Liakhovetki, DENX Software Engineering, <[email protected]>
+#
+# (C) Copyright 2010
+# Texas Instruments, <www.ti.com>
+# Aneesh V <[email protected]>
 #
 # See file CREDITS for list of people who contributed to this
 # project.
@@ -15,7 +19,7 @@
 #
 # 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
+# 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
@@ -23,9 +27,6 @@
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 # MA 02111-1307 USA
 #
-# SDRAM Address Space:
-# 8000'0000 - 9fff'ffff (512 MB)
-# Linux-Kernel is expected to be at 8000'8000, entry 8000'8000
-# (mem base + reserved)
 
-CONFIG_SYS_TEXT_BASE = 0x80e80000
+include $(SRCTREE)/spl/board/$(VENDOR)/omap4.mk
+include $(SRCTREE)/spl/board/$(VENDOR)/rules-omap.mk
Signature · 1 line
1.7.0.4
#108 lore raw

PATCH v2 9/22 omap4: add spl support for OMAP4 SDP

Dear Aneesh V,

Quoted 15 lines · In message <[email protected]> you wrote:

Adapted from: nand_spl/board/samsung/smdk6400/Makefile

- Add the SPL makefile for OMAP4430 SDP
- Add the necessary CONFIG flags in the board config file

---
V2:
* Changed CONFIG_SYS_SPL_TEXT_BASE to 0x40304350 from 0x40304360. This exact address is needed for EMU devices.
* Removed un-necessary compiler options from CFLAGS and AFLAGS. These are already set by .mk files in U-Boot
* Reorganize the make files to re-use common rules between boards

Quoted 9 lines
---
 board/ti/sdp4430/config.mk                         |    3 +-
 include/configs/omap4_sdp4430.h                    |   19 +++++
 spl/board/ti/omap4.mk                              |   77 ++++++++++++++++++++
 spl/board/ti/rules-omap.mk                         |   74 +++++++++++++++++++
 .../config.mk => spl/board/ti/sdp4430/Makefile     |   21 +++---
 5 files changed, 183 insertions(+), 11 deletions(-)
 create mode 100644 spl/board/ti/omap4.mk
 create mode 100644 spl/board/ti/rules-omap.mk

We do you introduce these files? Please omit them, and use a plain Makefile instead.

board/ti/sdp4430/config.mk line 32

Quoted 11 lines
board/ti/sdp4430/config.mk +2 -1
index 33901a7..c62965d 100644
@@ -28,4 +28,5 @@
 # Linux-Kernel is expected to be at 8000'8000, entry 8000'8000
 # (mem base + reserved)
 
-CONFIG_SYS_TEXT_BASE = 0x80e80000
+# 1MB into the SDRAM to allow for SPL's bss at the beginning of SDRAM
+CONFIG_SYS_TEXT_BASE = 0x80100000

NAK. Please define in board config header, and get rid of the config.mk file.

Quoted 1 line

+++ b/spl/board/ti/sdp4430/Makefile

...

board/ti/sdp4430/config.mk

Quoted 2 lines
board/ti/sdp4430/config.mk +2 -0
+include $(SRCTREE)/spl/board/$(VENDOR)/omap4.mk
+include $(SRCTREE)/spl/board/$(VENDOR)/rules-omap.mk

NAK. Move the code into the Makefile, and dump these two files.

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"We don't have to protect the environment -- the Second Coming is  at
hand."                                                   - James Watt
author
#109 lore raw

PATCH v2 9/22 omap4: add spl support for OMAP4 SDP

Hi wolfgang,

Quoted 28 lines · Wolfgang Denk

Dear Aneesh V,

Quoted 22 lines · In message<[email protected]> you wrote:

Adapted from: nand_spl/board/samsung/smdk6400/Makefile

- Add the SPL makefile for OMAP4430 SDP
- Add the necessary CONFIG flags in the board config file

---
V2:
* Changed CONFIG_SYS_SPL_TEXT_BASE to 0x40304350 from

    0x40304360. This exact address is needed for EMU
    devices.
  * Removed un-necessary compiler options from CFLAGS and AFLAGS.
    These are already set by .mk files in U-Boot
  * Reorganize the make files to re-use common rules between
    boards
---
  board/ti/sdp4430/config.mk                         |    3 +-
  include/configs/omap4_sdp4430.h                    |   19 +++++
  spl/board/ti/omap4.mk                              |   77 ++++++++++++++++++++
  spl/board/ti/rules-omap.mk                         |   74 +++++++++++++++++++
  .../config.mk =>  spl/board/ti/sdp4430/Makefile     |   21 +++---
  5 files changed, 183 insertions(+), 11 deletions(-)
Quoted 2 lines

create mode 100644 spl/board/ti/omap4.mk
create mode 100644 spl/board/ti/rules-omap.mk

Quoted 2 lines

We do you introduce these files? Please omit them, and use a plain Makefile instead.

I introduced them because 'spl/board/ti/sdp4430/Makefile' and 'spl/board /ti/panda/Makefile' were exactly same and wanted to re-use the make rules.

I indeed wanted to abstract it out even further in future so that the make rules can be shared between OMAP3 and OMAP4 too. This way the changes needed to support a new board will be lesser and maintenance will be easier while adding new features.

For instance, if I have to add NAND support today I just need to update omap4.mk instead of updating the Makefile of both panda and SDP.

This re-use will be evident when you see a later patch that replicates the same Makefile for panda.

Quoted 9 lines
Quoted 9 lines
board/ti/sdp4430/config.mk +0 -0
index 33901a7..c62965d 100644
@@ -28,4 +28,5 @@
  # Linux-Kernel is expected to be at 8000'8000, entry 8000'8000
  # (mem base + reserved)
 
Quoted 6 lines

board/ti/sdp4430/config.mk line 32

Quoted 3 lines
board/ti/sdp4430/config.mk +2 -1
-CONFIG_SYS_TEXT_BASE = 0x80e80000
+# 1MB into the SDRAM to allow for SPL's bss at the beginning of SDRAM
+CONFIG_SYS_TEXT_BASE = 0x80100000

NAK. Please define in board config header, and get rid of the config.mk file.

ok.

best regards,
Aneesh

#110 lore raw

PATCH v2 9/22 omap4: add spl support for OMAP4 SDP

Dear Aneesh V,

Quoted 10 lines · In message <[email protected]> you wrote:
Quoted 6 lines
Quoted 3 lines

create mode 100644 spl/board/ti/omap4.mk
create mode 100644 spl/board/ti/rules-omap.mk

We do you introduce these files? Please omit them, and use a plain Makefile instead.

I introduced them because 'spl/board/ti/sdp4430/Makefile' and 'spl/board /ti/panda/Makefile' were exactly same and wanted to re-use the make rules.

But in the result, the Makefiles are still the same, aren't they?

Quoted 10 lines

I indeed wanted to abstract it out even further in future so that the make rules can be shared between OMAP3 and OMAP4 too. This way the changes needed to support a new board will be lesser and maintenance will be easier while adding new features.

For instance, if I have to add NAND support today I just need to update omap4.mk instead of updating the Makefile of both panda and SDP.

This re-use will be evident when you see a later patch that replicates the same Makefile for panda.

Can you please rather try and move this to a common directory level, then?

I have a bad feeling about this. If the Makefiles are the same, then the code is probably more or less the same, also. Eventually larger parts of the code should be moved to a common directory, too?

Best regards,

Wolfgang Denk

Signature · 6 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A man either lives life as it happens to him, meets  it  head-on  and
licks it, or he turns his back on it and starts to wither away.
	-- Dr. Boyce, "The Menagerie" ("The Cage"), stardate unknown
author
#111 lore raw

PATCH v2 9/22 omap4: add spl support for OMAP4 SDP

Hi Wolfgang,

Quoted 7 lines · Wolfgang Denk

Dear Aneesh V,

Quoted 4 lines · In message<[email protected]> you wrote:
Quoted 4 lines
Quoted 3 lines

create mode 100644 spl/board/ti/omap4.mk
create mode 100644 spl/board/ti/rules-omap.mk

Quoted 8 lines
Quoted 6 lines
Quoted 2 lines

We do you introduce these files? Please omit them, and use a plain Makefile instead.

I introduced them because 'spl/board/ti/sdp4430/Makefile' and 'spl/board /ti/panda/Makefile' were exactly same and wanted to re-use the make rules.

But in the result, the Makefiles are still the same, aren't they?

Yes, but the contents are not duplicated in two files. Easier for maintenance.

Quoted 6 lines
Quoted 6 lines

I indeed wanted to abstract it out even further in future so that the make rules can be shared between OMAP3 and OMAP4 too. This way the changes needed to support a new board will be lesser and maintenance will be easier while adding new features.

Quoted 8 lines
Quoted 5 lines

For instance, if I have to add NAND support today I just need to update omap4.mk instead of updating the Makefile of both panda and SDP.

This re-use will be evident when you see a later patch that replicates the same Makefile for panda.

Can you please rather try and move this to a common directory level, then?

The top-level make rule being the following, we will need a Makefile in the board directory, right?

+SPL :$(TIMESTAMP_FILE) $(VERSION_FILE) depend tools
+ $(MAKE) -C spl/board/$(BOARDDIR) all

Quoted 5 lines

I have a bad feeling about this. If the Makefiles are the same, then the code is probably more or less the same, also. Eventually larger parts of the code should be moved to a common directory, too?

In fact, code is already common. All OMAP code specific to SPL comes from spl/board/ti/spl-omap.c . All OMAP code shared with OMAP U-Boot comes from the respective directory within arch/arm/cpu/armv7/*

In the interest of simplicity I deferred all board specific initialization of OMAP4(mainly mux) to U-Boot. So, SPL is board independent today for OMAP4.

best regards,
Aneesh

#112 lore raw

PATCH v2 9/22 omap4: add spl support for OMAP4 SDP

Dear Aneesh V,

Review

Quoted 6 lines · In message <[email protected]> you wrote:

The top-level make rule being the following, we will need a Makefile in the board directory, right?

(quoted diff) +2 -0
+SPL    :$(TIMESTAMP_FILE) $(VERSION_FILE) depend tools
+    $(MAKE) -C spl/board/$(BOARDDIR) all

Maybe this needs to be tweaked to allow for boards that don;t require board specific code.

Quoted 7 lines

In fact, code is already common. All OMAP code specific to SPL comes from spl/board/ti/spl-omap.c . All OMAP code shared with OMAP U-Boot comes from the respective directory within arch/arm/cpu/armv7/*

In the interest of simplicity I deferred all board specific initialization of OMAP4(mainly mux) to U-Boot. So, SPL is board independent today for OMAP4.

Then we should adapt the directory and Makefile structure and allow for such common code without need for separate spl/board/ directories.

Best regards,

Wolfgang Denk

Signature · 4 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A mouse is an elephant built by the Japanese.
author
#113 lore raw

PATCH v2 9/22 omap4: add spl support for OMAP4 SDP

Hi Wolfgang,

Quoted 4 lines · Wolfgang Denk

Dear Aneesh V,

Quoted 1 line · In message<[email protected]> you wrote:
Quoted 9 lines

Review

Quoted 5 lines

The top-level make rule being the following, we will need a Makefile in the board directory, right?

(quoted diff) +2 -0
+SPL    :$(TIMESTAMP_FILE) $(VERSION_FILE) depend tools
+    $(MAKE) -C spl/board/$(BOARDDIR) all

Maybe this needs to be tweaked to allow for boards that don;t require board specific code.

And how do you distinguish between the two cases at the top level Makefile? Using a CONFIG flag or on a per platform basis?

Why not just invoke the board level Makefile from the top-level Makefile and let it decide about the code-reuse by doing something like I did?

Quoted 11 lines
Quoted 7 lines

In fact, code is already common. All OMAP code specific to SPL comes from spl/board/ti/spl-omap.c . All OMAP code shared with OMAP U-Boot comes from the respective directory within arch/arm/cpu/armv7/*

In the interest of simplicity I deferred all board specific initialization of OMAP4(mainly mux) to U-Boot. So, SPL is board independent today for OMAP4.

Then we should adapt the directory and Makefile structure and allow for such common code without need for separate spl/board/ directories.

Do you have any specific proposals? I have a feeling that this may get un-necessarily complicated.

Best regards,
Aneesh

#114 lore raw

PATCH v2 9/22 omap4: add spl support for OMAP4 SDP

Dear Aneesh V,

Quoted 3 lines · In message <[email protected]> you wrote:

And how do you distinguish between the two cases at the top level Makefile? Using a CONFIG flag or on a per platform basis?

The decision should not be make in the top level makefile, but in spl/Makefile. And this can simply check if a board directory exists in the first place.

Quoted 3 lines

Why not just invoke the board level Makefile from the top-level Makefile and let it decide about the code-reuse by doing something like I did?

Because then we need board specific directories and board specific Makefiles even for those boards where no board specific code exists, and all these Makefiles will be semi-identical copies of each other.

Quoted 6 lines
Quoted 3 lines

Then we should adapt the directory and Makefile structure and allow for such common code without need for separate spl/board/ directories.

Do you have any specific proposals? I have a feeling that this may get un-necessarily complicated.

Having to maintain multiple copies of identical Makefiles is more complicated and error prone in the long run. Let's rather spoend a few thoughts initially and solve this problem before it spreads.

Best regards,

Wolfgang Denk

Signature · 6 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"It ain't so much the things we don't know that get  us  in  trouble.
It's  the  things  we know that ain't so." - Artemus Ward aka Charles
Farrar Brown
author
#115 lore raw

PATCH v2 9/22 omap4: add spl support for OMAP4 SDP

Hi Wolfgang,

Quoted 10 lines · Wolfgang Denk

Dear Aneesh V,

Quoted 3 lines · In message<[email protected]> you wrote:

And how do you distinguish between the two cases at the top level Makefile? Using a CONFIG flag or on a per platform basis?

The decision should not be make in the top level makefile, but in spl/Makefile. And this can simply check if a board directory exists in the first place.

1. How about the case where there is some board dependent code but also code shared by the boards(SoC based code). Will we have different 'Makefile's then - one for board and one for SoC. Will we then build different libraries at each leavel and link them together etc?

2. I think one key thing that you are perhaps missing is that in SPL the board level Makefile is not just meant for board level files. Instead it is used to pull together files from all the layers and make a custom image. IMHO, we will get into un-necessary complexities if we lose this property of SPL. We may rather spend efforts on making the regular U-Boot more configurable.

Quoted 9 lines
Quoted 4 lines

Why not just invoke the board level Makefile from the top-level Makefile and let it decide about the code-reuse by doing something like I did?

Because then we need board specific directories and board specific Makefiles even for those boards where no board specific code exists, and all these Makefiles will be semi-identical copies of each other.

Considering point 2 above I think this is logical.

The board level Makefile needs to have all the files. For the SoC level selection of files and the SoC level rules, include the respective *.mk files. Because in this case there are no board specific files there is nothing more in the Makefile. Please note that this may not be the case in general. Most boards, I suspect, may have some board specific files too.

I wouldn't really consider the include statements as duplication of code. Instead, that was a way of avoiding duplication of code "given the constraints of the SPL model".

best regards,
Aneesh

Quoted 15 lines
Quoted 6 lines
Quoted 3 lines

Then we should adapt the directory and Makefile structure and allow for such common code without need for separate spl/board/ directories.

Do you have any specific proposals? I have a feeling that this may get un-necessarily complicated.

Having to maintain multiple copies of identical Makefiles is more complicated and error prone in the long run. Let's rather spoend a few thoughts initially and solve this problem before it spreads.

Best regards,

Wolfgang Denk

author
#116 lore raw

PATCH v2 9/22 omap4: add spl support for OMAP4 SDP

Hi Wolfgang,

What's your final view on the Makefile structure of SPL.

best regards,
Aneesh

Quoted 67 lines · Aneesh V

Hi Wolfgang,

Quoted 10 lines · Wolfgang Denk

Dear Aneesh V,

Quoted 3 lines · In message<[email protected]> you wrote:

And how do you distinguish between the two cases at the top level Makefile? Using a CONFIG flag or on a per platform basis?

The decision should not be make in the top level makefile, but in spl/Makefile. And this can simply check if a board directory exists in the first place.

1. How about the case where there is some board dependent code but also code shared by the boards(SoC based code). Will we have different 'Makefile's then - one for board and one for SoC. Will we then build different libraries at each leavel and link them together etc?

2. I think one key thing that you are perhaps missing is that in SPL the board level Makefile is not just meant for board level files. Instead it is used to pull together files from all the layers and make a custom image. IMHO, we will get into un-necessary complexities if we lose this property of SPL. We may rather spend efforts on making the regular U-Boot more configurable.

Quoted 9 lines
Quoted 4 lines

Why not just invoke the board level Makefile from the top-level Makefile and let it decide about the code-reuse by doing something like I did?

Because then we need board specific directories and board specific Makefiles even for those boards where no board specific code exists, and all these Makefiles will be semi-identical copies of each other.

Considering point 2 above I think this is logical.

The board level Makefile needs to have all the files. For the SoC level selection of files and the SoC level rules, include the respective *.mk files. Because in this case there are no board specific files there is nothing more in the Makefile. Please note that this may not be the case in general. Most boards, I suspect, may have some board specific files too.

I wouldn't really consider the include statements as duplication of code. Instead, that was a way of avoiding duplication of code "given the constraints of the SPL model".

best regards,
Aneesh

Quoted 15 lines
Quoted 6 lines
Quoted 3 lines

Then we should adapt the directory and Makefile structure and allow for such common code without need for separate spl/board/ directories.

Do you have any specific proposals? I have a feeling that this may get un-necessarily complicated.

Having to maintain multiple copies of identical Makefiles is more complicated and error prone in the long run. Let's rather spoend a few thoughts initially and solve this problem before it spreads.

Best regards,

Wolfgang Denk

author
#117 lore raw

PATCH v2 9/22 omap4: add spl support for OMAP4 SDP

In reply to Aneesh V

Hi Wolfgang,

Quoted 19 lines · Aneesh V

Hi Wolfgang,

Quoted 10 lines · Wolfgang Denk

Dear Aneesh V,

Quoted 3 lines · In message<[email protected]> you wrote:

And how do you distinguish between the two cases at the top level Makefile? Using a CONFIG flag or on a per platform basis?

The decision should not be make in the top level makefile, but in spl/Makefile. And this can simply check if a board directory exists in the first place.

1. How about the case where there is some board dependent code but also code shared by the boards(SoC based code). Will we have different 'Makefile's then - one for board and one for SoC. Will we then build different libraries at each leavel and link them together etc?

Quoted 6 lines

2. I think one key thing that you are perhaps missing is that in SPL the board level Makefile is not just meant for board level files. Instead it is used to pull together files from all the layers and make a custom image. IMHO, we will get into un-necessary complexities if we lose this property of SPL. We may rather spend efforts on making the regular U-Boot more configurable.

Do you have any thoughts on this yet.

Is it ok if I continue to use the current SPL Makefile structure and abstract out common content from board level 'Makefile's to something like omap4.mk

Quoted 20 lines
Quoted 10 lines
Quoted 5 lines

Why not just invoke the board level Makefile from the top-level Makefile and let it decide about the code-reuse by doing something like I did?

Because then we need board specific directories and board specific Makefiles even for those boards where no board specific code exists, and all these Makefiles will be semi-identical copies of each other.

Considering point 2 above I think this is logical.

The board level Makefile needs to have all the files. For the SoC level selection of files and the SoC level rules, include the respective *.mk files. Because in this case there are no board specific files there is nothing more in the Makefile. Please note that this may not be the case in general. Most boards, I suspect, may have some board specific files too.

Quoted 3 lines

I wouldn't really consider the include statements as duplication of code. Instead, that was a way of avoiding duplication of code "given the constraints of the SPL model".

best regards,
Aneesh

#118 lore raw

PATCH v2 9/22 omap4: add spl support for OMAP4 SDP

In reply to Aneesh V

Dear Aneesh V,

Quoted 4 lines · In message <[email protected]> you wrote:
Quoted 4 lines
Quoted 3 lines

And how do you distinguish between the two cases at the top level Makefile? Using a CONFIG flag or on a per platform basis?

Quoted 8 lines
Quoted 3 lines

The decision should not be make in the top level makefile, but in spl/Makefile. And this can simply check if a board directory exists in the first place.

1. How about the case where there is some board dependent code but also code shared by the boards(SoC based code). Will we have different 'Makefile's then - one for board and one for SoC. Will we then build different libraries at each leavel and link them together etc?

Yes. If a board directory exists the code there gets built and then linked.

Quoted 2 lines

2. I think one key thing that you are perhaps missing is that in SPL the board level Makefile is not just meant for board level files.

This probably should be reworked. We should have a Makefile in nand_spl/ which covers the general code and then runs the respective SoC and/or board specific sub-makes.

Quoted 2 lines

Instead it is used to pull together files from all the layers and make a custom image. IMHO, we will get into un-necessary complexities if we

Yes, but most of thisis actually not board specific, but more SoC specific, if not general at all.

Quoted 2 lines

lose this property of SPL. We may rather spend efforts on making the regular U-Boot more configurable.

Indeed we should allow for more fine granular selection.

Quoted 1 line

The board level Makefile needs to have all the files. For the SoC level

No. It needs only those files that are actually board specific.

Quoted 2 lines

selection of files and the SoC level rules, include the respective *.mk files. Because in this case there are no board specific files there is

I don;t think that this is actually board specific - if we follow that route, we will duplicate the same stuff for all boards that use the same SoC.

Quoted 3 lines

nothing more in the Makefile. Please note that this may not be the case in general. Most boards, I suspect, may have some board specific files too.

That's why I suggest to separate common, SoC specific and board specific stuff .

Best regards,

Wolfgang Denk

Signature · 7 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de

There were meetings. There were always meetings. And they were  dull,
which is part of the reason they were meetings. Dull likes company.
                                    - Terry Pratchett, _Making_Money_
#119 lore raw

PATCH v2 9/22 omap4: add spl support for OMAP4 SDP

In reply to Aneesh V

Dear Aneesh V,

Quoted 15 lines · In message <[email protected]> you wrote:

Adapted from: nand_spl/board/samsung/smdk6400/Makefile

- Add the SPL makefile for OMAP4430 SDP
- Add the necessary CONFIG flags in the board config file

---
V2:
* Changed CONFIG_SYS_SPL_TEXT_BASE to 0x40304350 from 0x40304360. This exact address is needed for EMU devices.
* Removed un-necessary compiler options from CFLAGS and AFLAGS. These are already set by .mk files in U-Boot
* Reorganize the make files to re-use common rules between boards

Quoted 9 lines
---
 board/ti/sdp4430/config.mk                         |    3 +-
 include/configs/omap4_sdp4430.h                    |   19 +++++
 spl/board/ti/omap4.mk                              |   77 ++++++++++++++++++++
 spl/board/ti/rules-omap.mk                         |   74 +++++++++++++++++++
 .../config.mk => spl/board/ti/sdp4430/Makefile     |   21 +++---
 5 files changed, 183 insertions(+), 11 deletions(-)
 create mode 100644 spl/board/ti/omap4.mk
 create mode 100644 spl/board/ti/rules-omap.mk

See previous comments. Please comine into plain Makefile.

board/ti/sdp4430/config.mk line 32

Quoted 11 lines
board/ti/sdp4430/config.mk +2 -1
index 33901a7..c62965d 100644
@@ -28,4 +28,5 @@
 # Linux-Kernel is expected to be at 8000'8000, entry 8000'8000
 # (mem base + reserved)
 
-CONFIG_SYS_TEXT_BASE = 0x80e80000
+# 1MB into the SDRAM to allow for SPL's bss at the beginning of SDRAM
+CONFIG_SYS_TEXT_BASE = 0x80100000

Please move #define into board header and get rid of the config.mk

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Es ist nicht genug zu wissen, man mu? auch anwenden; es ist nicht ge-
nug zu wollen, man mu? auch tun.   -- Goethe, Maximen und Reflexionen
author
#120 lore raw

PATCH v2 10/22 omap4: utility function to identify the context of hw init

In reply to Aneesh V

The basic hardware init of OMAP4(s_init()) can happen in 4 different contexts:
1. SPL running from SRAM
2. U-Boot running from FLASH
3. Non-XIP U-Boot loaded to SDRAM by SPL
4. Non-XIP U-Boot loaded to SDRAM by ROM code using the Configuration Header feature

What level of hw initialization gets done depends on this context. Add a utility function to find this context.

---
 arch/arm/include/asm/arch-omap4/sys_proto.h |   47 +++++++++++++++++++++++++++
 arch/arm/include/asm/omap_common.h          |    6 +++
 2 files changed, 53 insertions(+), 0 deletions(-)
arch/arm/include/asm/arch-omap4/sys_proto.h +47 -0
index 0026b75..fb4c72f 100644
@@ -37,6 +37,53 @@ void sr32(void *, u32, u32, u32);
 u32 wait_on_value(u32, u32, void *, u32);
 void sdelay(unsigned long);
 
+static inline u32 running_from_sdram(void)
+{
+	u32 pc;
+	asm volatile ("mov %0, pc" : "=r" (pc));
+	return ((pc >= OMAP44XX_DRAM_ADDR_SPACE_START) &&
+	    (pc < OMAP44XX_DRAM_ADDR_SPACE_END));
+}
+
+static inline u8 uboot_loaded_by_spl(void)
+{
+	/*
+	 * Configuration Header is not supported yet, so u-boot init running
+	 * from SDRAM implies that it was loaded by SPL. When this situation
+	 * changes one of these approaches could be taken:
+	 * i.  Pass a magic from SPL to U-Boot and U-Boot save it at a known
+	 *     location.
+	 * ii. Check the OPP. CH can support only 50% OPP while SPL initializes
+	 *     the DPLLs@100% OPP.
+	 */
+	return running_from_sdram();
+}
+/*
+ * The basic hardware init of OMAP(s_init()) can happen in 4
+ * different contexts:
+ *  1. SPL running from SRAM
+ *  2. U-Boot running from FLASH
+ *  3. Non-XIP U-Boot loaded to SDRAM by SPL
+ *  4. Non-XIP U-Boot loaded to SDRAM by ROM code using the
+ *     Configuration Header feature
+ *
+ * This function finds this context.
+ * Defining as inline may help in compiling out unused functions in SPL
+ */
+static inline u32 omap4_hw_init_context(void)
+{
+#ifdef CONFIG_PRELOADER
+	return OMAP_INIT_CONTEXT_SPL;
+#else
+	if (uboot_loaded_by_spl())
+		return OMAP_INIT_CONTEXT_UBOOT_LOADED_BY_SPL;
+	else if (running_from_sdram())
+		return OMAP_INIT_CONTEXT_UBOOT_LOADED_BY_CH;
+	else
+		return OMAP_INIT_CONTEXT_XIP_UBOOT;
+#endif
+}
+
 extern const struct omap_sysinfo sysinfo;
 
 #endif
arch/arm/include/asm/omap_common.h +6 -0
index 7e28e28..2063c36 100644
@@ -42,6 +42,12 @@
 /* Magic number passed from SPL to U-Boot */
 #define OMAP_SPL_TO_UBOOT_MAGIC_NUMBER	0xDEADBEEF
 
+/* HW Init Context */
+#define OMAP_INIT_CONTEXT_SPL			0
+#define OMAP_INIT_CONTEXT_XIP_UBOOT		1
+#define OMAP_INIT_CONTEXT_UBOOT_LOADED_BY_SPL	2
+#define OMAP_INIT_CONTEXT_UBOOT_LOADED_BY_CH	3
+
 u32 omap_boot_device(void);
 u32 omap_boot_mode(void);
 
Signature · 1 line
1.7.0.4
#121 lore raw

PATCH v2 10/22 omap4: utility function to identify the context of hw init

Dear Aneesh V,

Quoted 7 lines · In message <[email protected]> you wrote:

The basic hardware init of OMAP4(s_init()) can happen in 4 different contexts:
1. SPL running from SRAM
2. U-Boot running from FLASH
3. Non-XIP U-Boot loaded to SDRAM by SPL
4. Non-XIP U-Boot loaded to SDRAM by ROM code using the Configuration Header feature

...

arch/arm/include/asm/arch-omap4/sys_proto.h void sr32(void *, u32, u32, u32); · line 81

Quoted 4 lines
arch/arm/include/asm/arch-omap4/sys_proto.h +4 -0
+	if (uboot_loaded_by_spl())
+		return OMAP_INIT_CONTEXT_UBOOT_LOADED_BY_SPL;
+	else if (running_from_sdram())
+		return OMAP_INIT_CONTEXT_UBOOT_LOADED_BY_CH;

For reasons of consistency, should this not better be OMAP_INIT_CONTEXT_UBOOT_LOADED_BY_ROM ?

arch/arm/include/asm/arch-omap4/sys_proto.h void sr32(void *, u32, u32, u32); · line 83

Quoted 1 line
arch/arm/include/asm/arch-omap4/sys_proto.h +1 -0
+		return OMAP_INIT_CONTEXT_XIP_UBOOT;

What exactly is OMAP_INIT_CONTEXT_XIP_UBOOT?

Do you mean the situation when booting from NOR flash, before relocation?

Eventually the "loaded by" definition is not so good, as it does not really cover the NOR boot case.

arch/arm/include/asm/omap_common.h line 49

Quoted 5 lines
arch/arm/include/asm/omap_common.h +5 -0
+/* HW Init Context */
+#define OMAP_INIT_CONTEXT_SPL			0
+#define OMAP_INIT_CONTEXT_XIP_UBOOT		1
+#define OMAP_INIT_CONTEXT_UBOOT_LOADED_BY_SPL	2
+#define OMAP_INIT_CONTEXT_UBOOT_LOADED_BY_CH	3

Boot from NOR?

Best regards,

Wolfgang Denk

Signature · 7 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The Buddha, the Godhead, resides quite as comfortably in the circuits
of a digital computer or the gears of a cycle transmission as he does
at the top of a mountain or in the petals of a flower.
            - R.  Pirsig, "Zen and the Art of Motorcycle Maintenance"

A message that is not in the archive (sent off-list or not yet received): [email protected]

#123 lore raw

PATCH v2 10/22 omap4: utility function to identify the context of hw init

Dear Aneesh V,

Quoted 9 lines · In message <[email protected]> you wrote:
Quoted 7 lines

arch/arm/include/asm/arch-omap4/sys_proto.h void sr32(void *, u32, u32, u32); · line 83

Quoted 2 lines
arch/arm/include/asm/arch-omap4/sys_proto.h +1 -0
+		return OMAP_INIT_CONTEXT_XIP_UBOOT;

What exactly is OMAP_INIT_CONTEXT_XIP_UBOOT?

Do you mean the situation when booting from NOR flash, before relocation?

Yes, this is for the NOR case.

Then please call it like that. XIP has a special emaning, that may or may not be related to running from ROM.

Quoted 6 lines
Quoted 2 lines

Eventually the "loaded by" definition is not so good, as it does not really cover the NOR boot case.

Please note that "loaded by" definition is not there for all the options. The definition is the 'context' in which the init code is executing.

So please get rid of the "LOADED_BY" names.

Best regards,

Wolfgang Denk

Signature · 6 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Today's robots are very primitive, capable of understanding  only  a
few  simple  instructions  such  as 'go left', 'go right', and 'build
car'."                                                  - John Sladek
author
#124 lore raw

PATCH v2 11/22 omap4: separate mux settings into essential and non essential parts

In reply to Aneesh V

Do the essential part from SPL and non-essential part from U-Boot
- Essential part is what is essential for u-boot to function
- Essential part is also largely board independent(at least as of now)
- So essential part is moved out to SoC directory instead of keeping in board directory. This helps in having single SPL that works for Panda and SDP.
- Non-essential part is what is set by u-boot for kernel to function correctly
- Ideally non-essential part should be phased out eventually

---
 arch/arm/cpu/armv7/omap4/board.c               |   53 ++++++++++++++++-
 arch/arm/cpu/armv7/omap4/omap4_mux_data.h      |   76 ++++++++++++++++++++++++
 arch/arm/include/asm/arch-omap4/sys_proto.h    |    4 +-
 board/ti/panda/panda.c                         |   25 ++------
 board/ti/panda/{panda.h => panda_mux_data.h}   |   45 ++------------
 board/ti/sdp4430/sdp.c                         |   25 ++------
 board/ti/sdp4430/{sdp.h => sdp4430_mux_data.h} |   47 ++-------------
 7 files changed, 151 insertions(+), 124 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/omap4/omap4_mux_data.h
 rename board/ti/panda/{panda.h => panda_mux_data.h} (83%)
 rename board/ti/sdp4430/{sdp.h => sdp4430_mux_data.h} (83%)
arch/arm/cpu/armv7/omap4/board.c +50 -3
index 046e3bf..30bf801 100644
@@ -32,9 +32,30 @@
 #include <asm/arch/cpu.h>
 #include <asm/arch/sys_proto.h>
 #include <asm/sizes.h>
+#include "omap4_mux_data.h"
 
 DECLARE_GLOBAL_DATA_PTR;
 
+void do_set_mux(u32 base, struct pad_conf_entry const *array, int size)
+{
+	int i;
+	struct pad_conf_entry *pad = (struct pad_conf_entry *) array;
+
+	for (i = 0; i < size; i++, pad++)
+		writew(pad->val, base + pad->offset);
+}
+
+static 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));
+}
+
 #ifdef CONFIG_PRELOADER
 u32 omap4_boot_device = BOOT_DEVICE_MMC1;
 u32 omap4_boot_mode = MMCSD_MODE_FAT;
@@ -49,14 +70,41 @@ u32 omap_boot_mode(void)
 }
 #endif
 
+static void set_mux_conf_regs(void)
+{
+	switch (omap4_hw_init_context()) {
+	case OMAP_INIT_CONTEXT_SPL:
+		set_muxconf_regs_essential();
+		break;
+	case OMAP_INIT_CONTEXT_UBOOT_LOADED_BY_SPL:
+		set_muxconf_regs_non_essential();
+		break;
+	case OMAP_INIT_CONTEXT_XIP_UBOOT:
+	case OMAP_INIT_CONTEXT_UBOOT_LOADED_BY_CH:
+		set_muxconf_regs_essential();
+		set_muxconf_regs_non_essential();
+		break;
+	}
+}
+
 /*
  * Routine: s_init
- * Description: Does early system init of muxing and clocks.
- *              - Called path is with SRAM stack.
+ * Description: Does early system init of watchdog, muxing, clocks, and
+ * sdram. Watchdog disable is done always. For the rest what gets done
+ * depends on the boot mode in which this function is executed
+ *   1. s_init of SPL running from SRAM
+ *   2. s_init of U-Boot running from FLASH
+ *   3. s_init of U-Boot loaded to SDRAM by SPL
+ *   4. s_init of U-Boot loaded to SDRAM by ROM code using the Configuration
+ *	Header feature
+ * Please have a look at the respective functions to see what gets done in
+ * each of these cases
+ * This function is called with SRAM stack.
  */
 void s_init(void)
 {
 	watchdog_init();
+	set_mux_conf_regs();
 }
 
 /*
@@ -139,7 +187,6 @@ int checkboard(void)
 */
 int arch_cpu_init(void)
 {
-	set_muxconf_regs();
 	return 0;
 }
 
arch/arm/cpu/armv7/omap4/omap4_mux_data.h new file +76 -0

76 lines not on this page · raw message

arch/arm/include/asm/arch-omap4/sys_proto.h +3 -1
index fb4c72f..ebd5b7a 100644
@@ -24,6 +24,7 @@
 #include <asm/arch/omap4.h>
 #include <asm/io.h>
 #include <asm/omap_common.h>
+#include <asm/arch/mux_omap4.h>
 
 struct omap_sysinfo {
 	char *board_string;
@@ -32,7 +33,8 @@ struct omap_sysinfo {
 void gpmc_init(void);
 void watchdog_init(void);
 u32 get_device_type(void);
-void set_muxconf_regs(void);
+void do_set_mux(u32 base, struct pad_conf_entry const *array, int size);
+void set_muxconf_regs_non_essential(void);
 void sr32(void *, u32, u32, u32);
 u32 wait_on_value(u32, u32, void *, u32);
 void sdelay(unsigned long);
board/ti/panda/panda.c +6 -19
index 78e1910..9afed80 100644
@@ -25,7 +25,7 @@
 #include <asm/arch/sys_proto.h>
 #include <asm/arch/mmc_host_def.h>
 
-#include "panda.h"
+#include "panda_mux_data.h"
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -65,27 +65,14 @@ int misc_init_r(void)
 	return 0;
 }
 
-void do_set_mux(u32 base, struct pad_conf_entry const *array, int size)
+void set_muxconf_regs_non_essential(void)
 {
-	int i;
-	struct pad_conf_entry *pad = (struct pad_conf_entry *) array;
-
-	for (i = 0; i < size; i++, pad++)
-		writew(pad->val, base + pad->offset);
-}
-
-/**
- * @brief set_muxconf_regs Setting up the configuration Mux registers
- * specific to the board.
- */
-void set_muxconf_regs(void)
-{
-	do_set_mux(CONTROL_PADCONF_CORE, core_padconf_array,
-		   sizeof(core_padconf_array) /
+	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,
-		   sizeof(wkup_padconf_array) /
+	do_set_mux(CONTROL_PADCONF_WKUP, wkup_padconf_array_non_essential,
+		   sizeof(wkup_padconf_array_non_essential) /
 		   sizeof(struct pad_conf_entry));
 }
 
board/ti/panda/panda_mux_data.h renamed from board/ti/panda/panda.h +5 -40

99 lines not on this page · raw message

board/ti/sdp4430/sdp.c +6 -19
index b13c4c5..a5ea682 100644
@@ -27,7 +27,7 @@
 #include <asm/arch/sys_proto.h>
 #include <asm/arch/mmc_host_def.h>
 
-#include "sdp.h"
+#include "sdp4430_mux_data.h"
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -70,27 +70,14 @@ int misc_init_r(void)
 	return 0;
 }
 
-void do_set_mux(u32 base, struct pad_conf_entry const *array, int size)
+void set_muxconf_regs_non_essential(void)
 {
-	int i;
-	struct pad_conf_entry *pad = (struct pad_conf_entry *) array;
-
-	for (i = 0; i < size; i++, pad++)
-		writew(pad->val, base + pad->offset);
-}
-
-/**
- * @brief set_muxconf_regs Setting up the configuration Mux registers
- * specific to the board.
- */
-void set_muxconf_regs(void)
-{
-	do_set_mux(CONTROL_PADCONF_CORE, core_padconf_array,
-		   sizeof(core_padconf_array) /
+	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,
-		   sizeof(wkup_padconf_array) /
+	do_set_mux(CONTROL_PADCONF_WKUP, wkup_padconf_array_non_essential,
+		   sizeof(wkup_padconf_array_non_essential) /
 		   sizeof(struct pad_conf_entry));
 }
 
board/ti/sdp4430/sdp4430_mux_data.h renamed from board/ti/sdp4430/sdp.h +5 -42

100 lines not on this page · raw message

Signature · 1 line
1.7.0.4
author
#125 lore raw

PATCH v2 12/22 omap4: correct mux data for sdp4430

In reply to Aneesh V

sync up mux settings with the latest in x-loader

---
Several checkpatch warnings of lines over 80 characters in this patch. These are due to formatting of mux data array, which only makes it more readable.

---
 board/ti/panda/panda_mux_data.h     |   89 ++++++++++++++++++-----------------
 board/ti/sdp4430/sdp4430_mux_data.h |   29 ++++++-----
 2 files changed, 61 insertions(+), 57 deletions(-)
board/ti/panda/panda_mux_data.h +45 -44
index 8bb7fe5..16cc0ad 100644
@@ -23,11 +23,9 @@
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
  * MA 02111-1307 USA
  */
+#ifndef _SDP4430_MUX_DATA_H
+#define _SDP4430_MUX_DATA_H
 
-#ifndef _PANDA_MUX_DATA_H_
-#define _PANDA_MUX_DATA_H_
-
-#include <asm/io.h>
 #include <asm/arch/mux_omap4.h>
 
 const struct pad_conf_entry core_padconf_array_non_essential[] = {
@@ -45,7 +43,7 @@ const struct pad_conf_entry core_padconf_array_non_essential[] = {
 	{GPMC_A19, (PTU | IEN | OFF_EN | OFF_PD | OFF_IN | M1)},	/* kpd_row7 */
 	{GPMC_A20, (IEN | M3)},						/* gpio_44 */
 	{GPMC_A21, (M3)},						/* gpio_45 */
-	{GPMC_A22, (M3)},						/* gpio_46 */
+	{GPMC_A22, (OFF_EN | OFF_PD | OFF_IN | M1)},			/* kpd_col6 */
 	{GPMC_A23, (OFF_EN | OFF_PD | OFF_IN | M1)},			/* kpd_col7 */
 	{GPMC_A24, (PTD | M3)},						/* gpio_48 */
 	{GPMC_A25, (PTD | M3)},						/* gpio_49 */
@@ -59,9 +57,9 @@ const struct pad_conf_entry core_padconf_array_non_essential[] = {
 	{GPMC_NBE0_CLE, (M3)},						/* gpio_59 */
 	{GPMC_NBE1, (PTD | M3)},					/* gpio_60 */
 	{GPMC_WAIT0, (PTU | IEN | M3)},					/* gpio_61 */
-	{GPMC_WAIT1,  (PTD | OFF_EN | OFF_PD | OFF_OUT_PTD | M3)},	/* gpio_62 */
+	{GPMC_WAIT1, (IEN | M3)},					/* gpio_62 */
 	{C2C_DATA11, (PTD | M3)},					/* gpio_100 */
-	{C2C_DATA12, (PTU | IEN | M3)},					/* gpio_101 */
+	{C2C_DATA12, (M1)},						/* dsi1_te0 */
 	{C2C_DATA13, (PTD | M3)},					/* gpio_102 */
 	{C2C_DATA14, (M1)},						/* dsi2_te0 */
 	{C2C_DATA15, (PTD | M3)},					/* gpio_104 */
@@ -86,14 +84,14 @@ const struct pad_conf_entry core_padconf_array_non_essential[] = {
 	{CAM_SHUTTER, (OFF_EN | OFF_PD | OFF_OUT_PTD | M0)},		/* cam_shutter */
 	{CAM_STROBE, (OFF_EN | OFF_PD | OFF_OUT_PTD | M0)},		/* cam_strobe */
 	{CAM_GLOBALRESET, (PTD | OFF_EN | OFF_PD | OFF_OUT_PTD | M3)},	/* gpio_83 */
-	{USBB1_ULPITLL_CLK, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M4)},/* usbb1_ulpiphy_clk */
-	{USBB1_ULPITLL_STP, (OFF_EN | OFF_OUT_PTD | M4)},		/* usbb1_ulpiphy_stp */
-	{USBB1_ULPITLL_DIR, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},	/* usbb1_ulpiphy_dir */
-	{USBB1_ULPITLL_NXT, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},	/* usbb1_ulpiphy_nxt */
-	{USBB1_ULPITLL_DAT0, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},	/* usbb1_ulpiphy_dat0 */
-	{USBB1_ULPITLL_DAT1, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},	/* usbb1_ulpiphy_dat1 */
-	{USBB1_ULPITLL_DAT2, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},	/* usbb1_ulpiphy_dat2 */
-	{USBB1_ULPITLL_DAT3, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},	/* usbb1_ulpiphy_dat3 */
+	{USBB1_ULPITLL_CLK, (IEN | OFF_EN | OFF_IN | M1)},		/* hsi1_cawake */
+	{USBB1_ULPITLL_STP, (IEN | OFF_EN | OFF_IN | M1)},		/* hsi1_cadata */
+	{USBB1_ULPITLL_DIR, (IEN | OFF_EN | OFF_IN | M1)},		/* hsi1_caflag */
+	{USBB1_ULPITLL_NXT, (OFF_EN | M1)},				/* hsi1_acready */
+	{USBB1_ULPITLL_DAT0, (OFF_EN | M1)},				/* hsi1_acwake */
+	{USBB1_ULPITLL_DAT1, (OFF_EN | M1)},				/* hsi1_acdata */
+	{USBB1_ULPITLL_DAT2, (OFF_EN | M1)},				/* hsi1_acflag */
+	{USBB1_ULPITLL_DAT3, (IEN | OFF_EN | OFF_IN | M1)},		/* hsi1_caready */
 	{USBB1_ULPITLL_DAT4, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},	/* usbb1_ulpiphy_dat4 */
 	{USBB1_ULPITLL_DAT5, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},	/* usbb1_ulpiphy_dat5 */
 	{USBB1_ULPITLL_DAT6, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},	/* usbb1_ulpiphy_dat6 */
@@ -106,8 +104,8 @@ const struct pad_conf_entry core_padconf_array_non_essential[] = {
 	{ABE_MCBSP2_DR, (IEN | OFF_EN | OFF_OUT_PTD | M0)},		/* abe_mcbsp2_dr */
 	{ABE_MCBSP2_DX, (OFF_EN | OFF_OUT_PTD | M0)},			/* abe_mcbsp2_dx */
 	{ABE_MCBSP2_FSX, (IEN | OFF_EN | OFF_PD | OFF_IN | M0)},	/* abe_mcbsp2_fsx */
-	{ABE_MCBSP1_CLKX, (IEN | M1)},					/* abe_slimbus1_clock */
-	{ABE_MCBSP1_DR, (IEN | M1)},					/* abe_slimbus1_data */
+	{ABE_MCBSP1_CLKX, (IEN | OFF_EN | OFF_PD | OFF_IN | M0)},	/* abe_mcbsp1_clkx */
+	{ABE_MCBSP1_DR, (IEN | OFF_EN | OFF_OUT_PTD | M0)},		/* abe_mcbsp1_dr */
 	{ABE_MCBSP1_DX, (OFF_EN | OFF_OUT_PTD | M0)},			/* abe_mcbsp1_dx */
 	{ABE_MCBSP1_FSX, (IEN | OFF_EN | OFF_PD | OFF_IN | M0)},	/* abe_mcbsp1_fsx */
 	{ABE_PDM_UL_DATA, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M0)},	/* abe_pdm_ul_data */
@@ -143,7 +141,7 @@ const struct pad_conf_entry core_padconf_array_non_essential[] = {
 	{MCSPI4_CS0, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M0)},	/* mcspi4_cs0 */
 	{UART4_RX, (IEN | M0)},						/* uart4_rx */
 	{UART4_TX, (M0)},						/* uart4_tx */
-	{USBB2_ULPITLL_CLK, (IEN | M3)},				/* gpio_157 */
+	{USBB2_ULPITLL_CLK, (PTD | IEN | M3)},				/* gpio_157 */
 	{USBB2_ULPITLL_STP, (IEN | M5)},				/* dispc2_data23 */
 	{USBB2_ULPITLL_DIR, (IEN | M5)},				/* dispc2_data22 */
 	{USBB2_ULPITLL_NXT, (IEN | M5)},				/* dispc2_data21 */
@@ -157,12 +155,12 @@ const struct pad_conf_entry core_padconf_array_non_essential[] = {
 	{USBB2_ULPITLL_DAT7, (IEN | M5)},				/* dispc2_data11 */
 	{USBB2_HSIC_DATA, (PTD | OFF_EN | OFF_OUT_PTU | M3)},		/* gpio_169 */
 	{USBB2_HSIC_STROBE, (PTD | OFF_EN | OFF_OUT_PTU | M3)},		/* gpio_170 */
-	{UNIPRO_TX0, (PTD | IEN | M3)},					/* gpio_171 */
+	{UNIPRO_TX0, (OFF_EN | OFF_PD | OFF_IN | M1)},			/* kpd_col0 */
 	{UNIPRO_TY0, (OFF_EN | OFF_PD | OFF_IN | M1)},			/* kpd_col1 */
 	{UNIPRO_TX1, (OFF_EN | OFF_PD | OFF_IN | M1)},			/* kpd_col2 */
 	{UNIPRO_TY1, (OFF_EN | OFF_PD | OFF_IN | M1)},			/* kpd_col3 */
-	{UNIPRO_TX2, (PTU | IEN | M3)},					/* gpio_0 */
-	{UNIPRO_TY2, (PTU | IEN | M3)},					/* gpio_1 */
+	{UNIPRO_TX2, (OFF_EN | OFF_PD | OFF_IN | M1)},			/* kpd_col4 */
+	{UNIPRO_TY2, (OFF_EN | OFF_PD | OFF_IN | M1)},			/* kpd_col5 */
 	{UNIPRO_RX0, (PTU | IEN | OFF_EN | OFF_PD | OFF_IN | M1)},	/* kpd_row0 */
 	{UNIPRO_RY0, (PTU | IEN | OFF_EN | OFF_PD | OFF_IN | M1)},	/* kpd_row1 */
 	{UNIPRO_RX1, (PTU | IEN | OFF_EN | OFF_PD | OFF_IN | M1)},	/* kpd_row2 */
@@ -173,13 +171,13 @@ const struct pad_conf_entry core_padconf_array_non_essential[] = {
 	{USBA0_OTG_DP, (IEN | OFF_EN | OFF_PD | OFF_IN | M0)},		/* usba0_otg_dp */
 	{USBA0_OTG_DM, (IEN | OFF_EN | OFF_PD | OFF_IN | M0)},		/* usba0_otg_dm */
 	{FREF_CLK1_OUT, (M0)},						/* fref_clk1_out */
-	{FREF_CLK2_OUT, (PTU | IEN | M3)},				/* gpio_182 */
+	{FREF_CLK2_OUT, (M0)},						/* fref_clk2_out */
 	{SYS_NIRQ1, (PTU | IEN | M0)},					/* sys_nirq1 */
-	{SYS_NIRQ2, (PTU | IEN | M0)},					/* sys_nirq2 */
+	{SYS_NIRQ2, (M7)},						/* sys_nirq2 */
 	{SYS_BOOT0, (PTU | IEN | M3)},					/* gpio_184 */
 	{SYS_BOOT1, (M3)},						/* gpio_185 */
 	{SYS_BOOT2, (PTD | IEN | M3)},					/* gpio_186 */
-	{SYS_BOOT3, (M3)},						/* gpio_187 */
+	{SYS_BOOT3, (PTD | IEN | M3)},					/* gpio_187 */
 	{SYS_BOOT4, (M3)},						/* gpio_188 */
 	{SYS_BOOT5, (PTD | IEN | M3)},					/* gpio_189 */
 	{DPM_EMU0, (IEN | M0)},						/* dpm_emu0 */
@@ -205,25 +203,28 @@ const struct pad_conf_entry core_padconf_array_non_essential[] = {
 };
 
 const struct pad_conf_entry wkup_padconf_array_non_essential[] = {
-	{PAD0_SIM_IO, (IEN | M0)},					/* sim_io */
-	{PAD1_SIM_CLK, (M0)},						/* sim_clk */
-	{PAD0_SIM_RESET, (M0)},						/* sim_reset */
-	{PAD1_SIM_CD, (PTU | IEN | M0)},				/* sim_cd */
-	{PAD0_SIM_PWRCTRL, (M0)},					/* sim_pwrctrl */
-	{PAD1_FREF_XTAL_IN, (M0)},					/* # */
-	{PAD0_FREF_SLICER_IN, (M0)},					/* fref_slicer_in */
-	{PAD1_FREF_CLK_IOREQ, (M0)},					/* fref_clk_ioreq */
-	{PAD0_FREF_CLK0_OUT, (M2)},					/* sys_drm_msecure */
-	{PAD1_FREF_CLK3_REQ, (M3)},					/* gpio_wk30 */
-	{PAD0_FREF_CLK3_OUT, (M0)},					/* fref_clk3_out */
-	{PAD1_FREF_CLK4_REQ, (PTU | OFF_EN | OFF_OUT_PTU | M3)},	/* led status_1 */
-	{PAD0_FREF_CLK4_OUT, (PTU | OFF_EN | OFF_OUT_PTU | M3)},	/* led status_2 */
-	{PAD0_SYS_NRESPWRON, (M0)},					/* sys_nrespwron */
-	{PAD1_SYS_NRESWARM, (M0)},					/* sys_nreswarm */
-	{PAD0_SYS_PWR_REQ, (PTU | M0)},					/* sys_pwr_req */
-	{PAD1_SYS_PWRON_RESET, (M3)},					/* gpio_wk29 */
-	{PAD0_SYS_BOOT6, (IEN | M3)},					/* gpio_wk9 */
-	{PAD1_SYS_BOOT7, (IEN | M3)},					/* gpio_wk10 */
+	{PAD0_SIM_IO, (IEN | M0)},		/* sim_io */
+	{PAD1_SIM_CLK, (M0)},			/* sim_clk */
+	{PAD0_SIM_RESET, (M0)},			/* sim_reset */
+	{PAD1_SIM_CD, (PTU | IEN | M0)},	/* sim_cd */
+	{PAD0_SIM_PWRCTRL, (M0)},		/* sim_pwrctrl */
+	{PAD1_FREF_XTAL_IN, (M0)},		/* # */
+	{PAD0_FREF_SLICER_IN, (M0)},		/* fref_slicer_in */
+	{PAD1_FREF_CLK_IOREQ, (M0)},		/* fref_clk_ioreq */
+	{PAD0_FREF_CLK0_OUT, (M2)},		/* sys_drm_msecure */
+	{PAD1_FREF_CLK3_REQ, (PTU | IEN | M0)},	/* # */
+	{PAD0_FREF_CLK3_OUT, (M0)},		/* fref_clk3_out */
+	{PAD1_FREF_CLK4_REQ, (PTU | IEN | M0)},	/* # */
+	{PAD0_FREF_CLK4_OUT, (M0)},		/* # */
+	{PAD0_SYS_NRESPWRON, (M0)},		/* sys_nrespwron */
+	{PAD1_SYS_NRESWARM, (M0)},		/* sys_nreswarm */
+	{PAD0_SYS_PWR_REQ, (PTU | M0)},		/* sys_pwr_req */
+	{PAD1_SYS_PWRON_RESET, (M3)},		/* gpio_wk29 */
+	{PAD0_SYS_BOOT6, (IEN | M3)},		/* gpio_wk9 */
+	{PAD1_SYS_BOOT7, (IEN | M3)},		/* gpio_wk10 */
+	{PAD1_FREF_CLK3_REQ, (M3)},		/* gpio_wk30 */
+	{PAD1_FREF_CLK4_REQ, (M3)},		/* gpio_wk7 */
+	{PAD0_FREF_CLK4_OUT, (M3)},		/* gpio_wk8 */
 };
 
-#endif /* _PANDA_MUX_DATA_H_ */
+#endif /* _SDP4430_MUX_DATA_H */
board/ti/sdp4430/sdp4430_mux_data.h +16 -13
index e6081dc..16cc0ad 100644
@@ -84,14 +84,14 @@ const struct pad_conf_entry core_padconf_array_non_essential[] = {
 	{CAM_SHUTTER, (OFF_EN | OFF_PD | OFF_OUT_PTD | M0)},		/* cam_shutter */
 	{CAM_STROBE, (OFF_EN | OFF_PD | OFF_OUT_PTD | M0)},		/* cam_strobe */
 	{CAM_GLOBALRESET, (PTD | OFF_EN | OFF_PD | OFF_OUT_PTD | M3)},	/* gpio_83 */
-	{USBB1_ULPITLL_CLK, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M4)},/* usbb1_ulpiphy_clk */
-	{USBB1_ULPITLL_STP, (OFF_EN | OFF_OUT_PTD | M4)},		/* usbb1_ulpiphy_stp */
-	{USBB1_ULPITLL_DIR, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},	/* usbb1_ulpiphy_dir */
-	{USBB1_ULPITLL_NXT, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},	/* usbb1_ulpiphy_nxt */
-	{USBB1_ULPITLL_DAT0, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},	/* usbb1_ulpiphy_dat0 */
-	{USBB1_ULPITLL_DAT1, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},	/* usbb1_ulpiphy_dat1 */
-	{USBB1_ULPITLL_DAT2, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},	/* usbb1_ulpiphy_dat2 */
-	{USBB1_ULPITLL_DAT3, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},	/* usbb1_ulpiphy_dat3 */
+	{USBB1_ULPITLL_CLK, (IEN | OFF_EN | OFF_IN | M1)},		/* hsi1_cawake */
+	{USBB1_ULPITLL_STP, (IEN | OFF_EN | OFF_IN | M1)},		/* hsi1_cadata */
+	{USBB1_ULPITLL_DIR, (IEN | OFF_EN | OFF_IN | M1)},		/* hsi1_caflag */
+	{USBB1_ULPITLL_NXT, (OFF_EN | M1)},				/* hsi1_acready */
+	{USBB1_ULPITLL_DAT0, (OFF_EN | M1)},				/* hsi1_acwake */
+	{USBB1_ULPITLL_DAT1, (OFF_EN | M1)},				/* hsi1_acdata */
+	{USBB1_ULPITLL_DAT2, (OFF_EN | M1)},				/* hsi1_acflag */
+	{USBB1_ULPITLL_DAT3, (IEN | OFF_EN | OFF_IN | M1)},		/* hsi1_caready */
 	{USBB1_ULPITLL_DAT4, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},	/* usbb1_ulpiphy_dat4 */
 	{USBB1_ULPITLL_DAT5, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},	/* usbb1_ulpiphy_dat5 */
 	{USBB1_ULPITLL_DAT6, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)},	/* usbb1_ulpiphy_dat6 */
@@ -104,8 +104,8 @@ const struct pad_conf_entry core_padconf_array_non_essential[] = {
 	{ABE_MCBSP2_DR, (IEN | OFF_EN | OFF_OUT_PTD | M0)},		/* abe_mcbsp2_dr */
 	{ABE_MCBSP2_DX, (OFF_EN | OFF_OUT_PTD | M0)},			/* abe_mcbsp2_dx */
 	{ABE_MCBSP2_FSX, (IEN | OFF_EN | OFF_PD | OFF_IN | M0)},	/* abe_mcbsp2_fsx */
-	{ABE_MCBSP1_CLKX, (IEN | M1)},					/* abe_slimbus1_clock */
-	{ABE_MCBSP1_DR, (IEN | M1)},					/* abe_slimbus1_data */
+	{ABE_MCBSP1_CLKX, (IEN | OFF_EN | OFF_PD | OFF_IN | M0)},	/* abe_mcbsp1_clkx */
+	{ABE_MCBSP1_DR, (IEN | OFF_EN | OFF_OUT_PTD | M0)},		/* abe_mcbsp1_dr */
 	{ABE_MCBSP1_DX, (OFF_EN | OFF_OUT_PTD | M0)},			/* abe_mcbsp1_dx */
 	{ABE_MCBSP1_FSX, (IEN | OFF_EN | OFF_PD | OFF_IN | M0)},	/* abe_mcbsp1_fsx */
 	{ABE_PDM_UL_DATA, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M0)},	/* abe_pdm_ul_data */
@@ -141,7 +141,7 @@ const struct pad_conf_entry core_padconf_array_non_essential[] = {
 	{MCSPI4_CS0, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M0)},	/* mcspi4_cs0 */
 	{UART4_RX, (IEN | M0)},						/* uart4_rx */
 	{UART4_TX, (M0)},						/* uart4_tx */
-	{USBB2_ULPITLL_CLK, (IEN | M3)},				/* gpio_157 */
+	{USBB2_ULPITLL_CLK, (PTD | IEN | M3)},				/* gpio_157 */
 	{USBB2_ULPITLL_STP, (IEN | M5)},				/* dispc2_data23 */
 	{USBB2_ULPITLL_DIR, (IEN | M5)},				/* dispc2_data22 */
 	{USBB2_ULPITLL_NXT, (IEN | M5)},				/* dispc2_data21 */
@@ -173,11 +173,11 @@ const struct pad_conf_entry core_padconf_array_non_essential[] = {
 	{FREF_CLK1_OUT, (M0)},						/* fref_clk1_out */
 	{FREF_CLK2_OUT, (M0)},						/* fref_clk2_out */
 	{SYS_NIRQ1, (PTU | IEN | M0)},					/* sys_nirq1 */
-	{SYS_NIRQ2, (PTU | IEN | M0)},					/* sys_nirq2 */
+	{SYS_NIRQ2, (M7)},						/* sys_nirq2 */
 	{SYS_BOOT0, (PTU | IEN | M3)},					/* gpio_184 */
 	{SYS_BOOT1, (M3)},						/* gpio_185 */
 	{SYS_BOOT2, (PTD | IEN | M3)},					/* gpio_186 */
-	{SYS_BOOT3, (M3)},						/* gpio_187 */
+	{SYS_BOOT3, (PTD | IEN | M3)},					/* gpio_187 */
 	{SYS_BOOT4, (M3)},						/* gpio_188 */
 	{SYS_BOOT5, (PTD | IEN | M3)},					/* gpio_189 */
 	{DPM_EMU0, (IEN | M0)},						/* dpm_emu0 */
@@ -222,6 +222,9 @@ const struct pad_conf_entry wkup_padconf_array_non_essential[] = {
 	{PAD1_SYS_PWRON_RESET, (M3)},		/* gpio_wk29 */
 	{PAD0_SYS_BOOT6, (IEN | M3)},		/* gpio_wk9 */
 	{PAD1_SYS_BOOT7, (IEN | M3)},		/* gpio_wk10 */
+	{PAD1_FREF_CLK3_REQ, (M3)},		/* gpio_wk30 */
+	{PAD1_FREF_CLK4_REQ, (M3)},		/* gpio_wk7 */
+	{PAD0_FREF_CLK4_OUT, (M3)},		/* gpio_wk8 */
 };
 
 #endif /* _SDP4430_MUX_DATA_H */
Signature · 1 line
1.7.0.4
author
#126 lore raw

PATCH v2 13/22 omap4: add clock support

In reply to Aneesh V

Add support for:
1. DPLL locking
2. Initialization of clock domains and clock modules

This work draws upon previous work done for x-loader mainly by:
Santosh Shilimkar <[email protected]> Rajendra Nayak <[email protected]>

---
V2:
* Use pre-calculated M & N values instead of calculated ones
* Changes due to make file changes
* Some corrections
* Do all clock initialization in SPL itself instead of differing some work to u-boot

---
 arch/arm/cpu/armv7/omap4/Makefile           |    1 +
 arch/arm/cpu/armv7/omap4/board.c            |    1 +
 arch/arm/cpu/armv7/omap4/clocks.c           |  731 +++++++++++++++++++++++++++
 arch/arm/cpu/armv7/omap4/clocks_get_m_n.c   |  154 ++++++
 arch/arm/include/asm/arch-omap4/clocks.h    |  506 ++++++++++++++++++
 arch/arm/include/asm/arch-omap4/sys_proto.h |    6 +
 arch/arm/include/asm/omap_common.h          |    3 +
 spl/board/ti/omap4.mk                       |    7 +-
 8 files changed, 1408 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/omap4/clocks.c
 create mode 100644 arch/arm/cpu/armv7/omap4/clocks_get_m_n.c
 create mode 100644 arch/arm/include/asm/arch-omap4/clocks.h
arch/arm/cpu/armv7/omap4/Makefile +1 -0
index 987dc9d..6154e86 100644
@@ -30,6 +30,7 @@ SOBJS	+= lowlevel_init.o
 COBJS	+= board.o
 COBJS	+= mem.o
 COBJS	+= sys_info.o
+COBJS	+= clocks.o
 
 SRCS	:= $(SOBJS:.o=.S) $(COBJS:.o=.c)
 OBJS	:= $(addprefix $(obj),$(COBJS) $(SOBJS))
arch/arm/cpu/armv7/omap4/board.c +1 -0
index 30bf801..f83b6d7 100644
@@ -105,6 +105,7 @@ void s_init(void)
 {
 	watchdog_init();
 	set_mux_conf_regs();
+	prcm_init();
 }
 
 /*
arch/arm/cpu/armv7/omap4/clocks.c new file +731 -0

731 lines not on this page · raw message

arch/arm/cpu/armv7/omap4/clocks_get_m_n.c new file +154 -0

154 lines not on this page · raw message

arch/arm/include/asm/arch-omap4/clocks.h new file +506 -0

506 lines not on this page · raw message

arch/arm/include/asm/arch-omap4/sys_proto.h +6 -0
index ebd5b7a..4ba0ee0 100644
@@ -38,6 +38,12 @@ void set_muxconf_regs_non_essential(void);
 void sr32(void *, u32, u32, u32);
 u32 wait_on_value(u32, u32, void *, u32);
 void sdelay(unsigned long);
+void prcm_init(void);
+void bypass_dpll(u32 base);
+void freq_update_core(void);
+u32 get_sys_clk_freq(void);
+u32 omap4_ddr_clk(void);
+u32 omap4_revision(void);
 
 static inline u32 running_from_sdram(void)
 {
arch/arm/include/asm/omap_common.h +3 -0
index 2063c36..787dd88 100644
@@ -25,6 +25,9 @@
 #ifndef	_OMAP_COMMON_H_
 #define	_OMAP_COMMON_H_
 
+/* Max value for DPLL multiplier M */
+#define OMAP_DPLL_MAX_N	127
+
 /* Boot device */
 #define BOOT_DEVICE_NONE	0
 #define BOOT_DEVICE_XIP		1
spl/board/ti/omap4.mk +6 -1
index dffb53b..0374534 100644
@@ -73,5 +73,10 @@ $(obj)board.c:$(obj)omap4_mux_data.h
 	@rm -f $@
 	@ln -s $(TOPDIR)/arch/arm/cpu/armv7/omap4/board.c $@
 
+$(obj)clocks.c:
+	@rm -f $@
+	@ln -s $(TOPDIR)/arch/arm/cpu/armv7/omap4/clocks.c $@
+
+
 SOBJS	+= lowlevel_init.o
-COBJS	+= board.o
+COBJS	+= board.o clocks.o
Signature · 1 line
1.7.0.4
#127 lore raw

PATCH v2 13/22 omap4: add clock support

Dear Aneesh V,

Quoted 16 lines · In message <[email protected]> you wrote:

Add support for:
1. DPLL locking
2. Initialization of clock domains and clock modules

This work draws upon previous work done for x-loader mainly by:
Santosh Shilimkar <[email protected]> Rajendra Nayak <[email protected]>

---
V2:
* Use pre-calculated M & N values instead of calculated ones
* Changes due to make file changes
* Some corrections
* Do all clock initialization in SPL itself instead of differing some work to u-boot

Quoted 13 lines
---
 arch/arm/cpu/armv7/omap4/Makefile           |    1 +
 arch/arm/cpu/armv7/omap4/board.c            |    1 +
 arch/arm/cpu/armv7/omap4/clocks.c           |  731 +++++++++++++++++++++++++++
 arch/arm/cpu/armv7/omap4/clocks_get_m_n.c   |  154 ++++++
 arch/arm/include/asm/arch-omap4/clocks.h    |  506 ++++++++++++++++++
 arch/arm/include/asm/arch-omap4/sys_proto.h |    6 +
 arch/arm/include/asm/omap_common.h          |    3 +
 spl/board/ti/omap4.mk                       |    7 +-
 8 files changed, 1408 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/omap4/clocks.c
 create mode 100644 arch/arm/cpu/armv7/omap4/clocks_get_m_n.c
 create mode 100644 arch/arm/include/asm/arch-omap4/clocks.h

It appears this might be part of or taken from some bigger scope clocks framework. Otherwise it's diffcult for me to understand why OMAP4 needs 1400+ lines of code, when other SoCs appear to do with considerably less. Please comment.

arch/arm/cpu/armv7/omap4/Makefile SOBJS += lowlevel_init.o · line 33

Quoted 9 lines
arch/arm/cpu/armv7/omap4/Makefile +1 -0
index 987dc9d..6154e86 100644
@@ -30,6 +30,7 @@ SOBJS	+= lowlevel_init.o
 COBJS	+= board.o
 COBJS	+= mem.o
 COBJS	+= sys_info.o
+COBJS	+= clocks.o

Please keep lists sorted.

...

arch/arm/cpu/armv7/omap4/Makefile SOBJS += lowlevel_init.o

Quoted 7 lines
arch/arm/cpu/armv7/omap4/Makefile +7 -0
+static inline void do_bypass_dpll(u32 base)
+{
+	struct dpll_regs *dpll_regs = (struct dpll_regs *)base;
+
+	modify_reg_32(&dpll_regs->cm_clkmode_dpll,
+		      CM_CLKMODE_DPLL_DPLL_EN_SHIFT,
+		      CM_CLKMODE_DPLL_DPLL_EN_MASK, DPLL_EN_FAST_RELOCK_BYPASS);

NAK, please use standard macros (see previous messages).

Quoted 4 lines
arch/arm/cpu/armv7/omap4/Makefile +4 -0
+static void do_setup_dpll(u32 base, const struct dpll_params *params, u8 lock)
+{
+	u32 temp;
+	struct dpll_regs *dpll_regs = (struct dpll_regs *)base;

arch/arm/cpu/armv7/omap4/Makefile

Quoted 10 lines
arch/arm/cpu/armv7/omap4/Makefile +10 -0
+
+	bypass_dpll(base);
+
+	/* Set M & N */
+	temp = readl(&dpll_regs->cm_clksel_dpll);
+	set_bit_field(temp, CM_CLKSEL_DPLL_M_SHIFT, CM_CLKSEL_DPLL_M_MASK,
+			params->m);
+	set_bit_field(temp, CM_CLKSEL_DPLL_N_SHIFT, CM_CLKSEL_DPLL_N_MASK,
+			params->n);
+	writel(temp, &dpll_regs->cm_clksel_dpll);

NAK, please use standard macros (see previous messages).

...

Quoted 6 lines
arch/arm/cpu/armv7/omap4/clocks_get_m_n.c new file +0 -0
new file mode 100644
index 0000000..777ec11
@@ -0,0 +1,154 @@

...

Quoted 1 line

+void main(void)

It appears this is a host program, not part of U-Boot. I don't think that arch/arm/cpu/armv7/omap4/ is the right place for this program.

...

Quoted 3 lines
arch/arm/include/asm/arch-omap4/clocks.h new file +0 -0
@@ -0,0 +1,506 @@

...

Quoted 62 lines
arch/arm/include/asm/arch-omap4/clocks.h new file +62 -0
+#define CM_WKUP_CLKSTCTRL		(OMAP44XX_L4_WKUP_BASE + 0x7800)
+#define CM_WKUP_L4WKUP_CLKCTRL		(OMAP44XX_L4_WKUP_BASE + 0x7820)
+#define CM_WKUP_WDTIMER1_CLKCTRL		(OMAP44XX_L4_WKUP_BASE + 0x7828)
+#define CM_WKUP_WDTIMER2_CLKCTRL		(OMAP44XX_L4_WKUP_BASE + 0x7830)
+#define CM_WKUP_GPIO1_CLKCTRL		(OMAP44XX_L4_WKUP_BASE + 0x7838)
+#define CM_WKUP_GPTIMER1_CLKCTRL	(OMAP44XX_L4_WKUP_BASE + 0x7840)
+#define CM_WKUP_GPTIMER12_CLKCTRL		(OMAP44XX_L4_WKUP_BASE + 0x7848)
+#define CM_WKUP_SYNCTIMER_CLKCTRL	(OMAP44XX_L4_WKUP_BASE + 0x7850)
+#define CM_WKUP_USIM_CLKCTRL		(OMAP44XX_L4_WKUP_BASE + 0x7858)
+#define CM_WKUP_SARRAM_CLKCTRL		(OMAP44XX_L4_WKUP_BASE + 0x7860)
+#define CM_WKUP_KEYBOARD_CLKCTRL	(OMAP44XX_L4_WKUP_BASE + 0x7878)
+#define CM_WKUP_RTC_CLKCTRL		(OMAP44XX_L4_WKUP_BASE + 0x7880)
+#define CM_WKUP_BANDGAP_CLKCTRL		(OMAP44XX_L4_WKUP_BASE + 0x7888)
+
+/* DEVICE_PRM Registers */
+#define PRM_VC_VAL_BYPASS		(OMAP44XX_L4_WKUP_BASE + 0x7BA0)
+#define PRM_VC_CFG_CHANNEL		(OMAP44XX_L4_WKUP_BASE + 0x7BA4)
+#define PRM_VC_CFG_I2C_MODE		(OMAP44XX_L4_WKUP_BASE + 0x7BA8)
+#define PRM_VC_CFG_I2C_CLK		(OMAP44XX_L4_WKUP_BASE + 0x7BAC)
+
+/* CM1.CKGEN module registers */
+#define CM_CLKSEL_CORE			(OMAP44XX_L4_CORE_BASE + 0x4100)
+#define CM_CLKSEL_ABE			(OMAP44XX_L4_CORE_BASE + 0x4108)
+#define CM_DLL_CTRL			(OMAP44XX_L4_CORE_BASE + 0x4110)
+#define CM_CLKMODE_DPLL_CORE		(OMAP44XX_L4_CORE_BASE + 0x4120)
+#define CM_IDLEST_DPLL_CORE		(OMAP44XX_L4_CORE_BASE + 0x4124)
+#define CM_AUTOIDLE_DPLL_CORE		(OMAP44XX_L4_CORE_BASE + 0x4128)
+#define CM_CLKSEL_DPLL_CORE		(OMAP44XX_L4_CORE_BASE + 0x412c)
+#define CM_DIV_M2_DPLL_CORE		(OMAP44XX_L4_CORE_BASE + 0x4130)
+#define CM_DIV_M3_DPLL_CORE		(OMAP44XX_L4_CORE_BASE + 0x4134)
+#define CM_DIV_M4_DPLL_CORE		(OMAP44XX_L4_CORE_BASE + 0x4138)
+#define CM_DIV_M5_DPLL_CORE		(OMAP44XX_L4_CORE_BASE + 0x413c)
+#define CM_DIV_M6_DPLL_CORE		(OMAP44XX_L4_CORE_BASE + 0x4140)
+#define CM_DIV_M7_DPLL_CORE		(OMAP44XX_L4_CORE_BASE + 0x4144)
+#define CM_SSC_DELTAMSTEP_DPLL_CORE	(OMAP44XX_L4_CORE_BASE + 0x4148)
+#define CM_SSC_MODFREQDIV_DPLL_CORE	(OMAP44XX_L4_CORE_BASE + 0x414c)
+#define CM_EMU_OVERRIDE_DPLL_CORE	(OMAP44XX_L4_CORE_BASE + 0x4150)
+#define CM_CLKMODE_DPLL_MPU		(OMAP44XX_L4_CORE_BASE + 0x4160)
+#define CM_IDLEST_DPLL_MPU		(OMAP44XX_L4_CORE_BASE + 0x4164)
+#define CM_AUTOIDLE_DPLL_MPU		(OMAP44XX_L4_CORE_BASE + 0x4168)
+#define CM_CLKSEL_DPLL_MPU		(OMAP44XX_L4_CORE_BASE + 0x416c)
+#define CM_DIV_M2_DPLL_MPU		(OMAP44XX_L4_CORE_BASE + 0x4170)
+#define CM_SSC_DELTAMSTEP_DPLL_MPU	(OMAP44XX_L4_CORE_BASE + 0x4188)
+#define CM_SSC_MODFREQDIV_DPLL_MPU	(OMAP44XX_L4_CORE_BASE + 0x418c)
+#define CM_BYPCLK_DPLL_MPU		(OMAP44XX_L4_CORE_BASE + 0x419c)
+#define CM_CLKMODE_DPLL_IVA		(OMAP44XX_L4_CORE_BASE + 0x41a0)
+#define CM_IDLEST_DPLL_IVA		(OMAP44XX_L4_CORE_BASE + 0x41a4)
+#define CM_AUTOIDLE_DPLL_IVA		(OMAP44XX_L4_CORE_BASE + 0x41a8)
+#define CM_CLKSEL_DPLL_IVA		(OMAP44XX_L4_CORE_BASE + 0x41ac)
+#define CM_DIV_M4_DPLL_IVA		(OMAP44XX_L4_CORE_BASE + 0x41b8)
+#define CM_DIV_M5_DPLL_IVA		(OMAP44XX_L4_CORE_BASE + 0x41bc)
+#define CM_SSC_DELTAMSTEP_DPLL_IVA	(OMAP44XX_L4_CORE_BASE + 0x41c8)
+#define CM_SSC_MODFREQDIV_DPLL_IVA	(OMAP44XX_L4_CORE_BASE + 0x41cc)
+#define CM_BYPCLK_DPLL_IVA		(OMAP44XX_L4_CORE_BASE + 0x41dc)
+#define CM_CLKMODE_DPLL_ABE		(OMAP44XX_L4_CORE_BASE + 0x41e0)
+#define CM_IDLEST_DPLL_ABE		(OMAP44XX_L4_CORE_BASE + 0x41e4)
+#define CM_AUTOIDLE_DPLL_ABE		(OMAP44XX_L4_CORE_BASE + 0x41e8)
+#define CM_CLKSEL_DPLL_ABE		(OMAP44XX_L4_CORE_BASE + 0x41ec)
+#define CM_DIV_M2_DPLL_ABE		(OMAP44XX_L4_CORE_BASE + 0x41f0)
+#define CM_DIV_M3_DPLL_ABE		(OMAP44XX_L4_CORE_BASE + 0x41f4)
+#define CM_SSC_DELTAMSTEP_DPLL_ABE	(OMAP44XX_L4_CORE_BASE + 0x4208)
+#define CM_SSC_MODFREQDIV_DPLL_ABE	(OMAP44XX_L4_CORE_BASE + 0x420c)

arch/arm/include/asm/arch-omap4/clocks.h line 110

Quoted 10 lines
arch/arm/include/asm/arch-omap4/clocks.h new file +10 -0
+#define CM_CLKMODE_DPLL_DDRPHY		(OMAP44XX_L4_CORE_BASE + 0x4220)
+#define CM_IDLEST_DPLL_DDRPHY		(OMAP44XX_L4_CORE_BASE + 0x4224)
+#define CM_AUTOIDLE_DPLL_DDRPHY		(OMAP44XX_L4_CORE_BASE + 0x4228)
+#define CM_CLKSEL_DPLL_DDRPHY		(OMAP44XX_L4_CORE_BASE + 0x422c)
+#define CM_DIV_M2_DPLL_DDRPHY		(OMAP44XX_L4_CORE_BASE + 0x4230)
+#define CM_DIV_M4_DPLL_DDRPHY		(OMAP44XX_L4_CORE_BASE + 0x4238)
+#define CM_DIV_M5_DPLL_DDRPHY		(OMAP44XX_L4_CORE_BASE + 0x423c)
+#define CM_DIV_M6_DPLL_DDRPHY		(OMAP44XX_L4_CORE_BASE + 0x4240)
+#define CM_SSC_DELTAMSTEP_DPLL_DDRPHY	(OMAP44XX_L4_CORE_BASE + 0x4248)
+#define CM_SHADOW_FREQ_CONFIG1		(OMAP44XX_L4_CORE_BASE + 0x4260)

NAK. We do not accept base address plus offset notation. Please declare C structs instead.

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I think animal testing is a terrible idea; they get all  nervous  and
give the wrong answers.
author
#128 lore raw

PATCH v2 13/22 omap4: add clock support

Hi Wolfgang,

Quoted 33 lines · Wolfgang Denk

Dear Aneesh V,

Quoted 26 lines · In message<[email protected]> you wrote:

Add support for:
1. DPLL locking
2. Initialization of clock domains and clock modules

This work draws upon previous work done for x-loader mainly by:
Santosh Shilimkar<[email protected]> Rajendra Nayak<[email protected]>

---
V2:
* Use pre-calculated M& N values instead of calculated ones
* Changes due to make file changes
* Some corrections
* Do all clock initialization in SPL itself instead of differing some work to u-boot

---
  arch/arm/cpu/armv7/omap4/Makefile           |    1 +
  arch/arm/cpu/armv7/omap4/board.c            |    1 +
  arch/arm/cpu/armv7/omap4/clocks.c           |  731 +++++++++++++++++++++++++++
  arch/arm/cpu/armv7/omap4/clocks_get_m_n.c   |  154 ++++++
  arch/arm/include/asm/arch-omap4/clocks.h    |  506 ++++++++++++++++++
  arch/arm/include/asm/arch-omap4/sys_proto.h |    6 +
  arch/arm/include/asm/omap_common.h          |    3 +
  spl/board/ti/omap4.mk                       |    7 +-
  8 files changed, 1408 insertions(+), 1 deletions(-)
Quoted 3 lines

create mode 100644 arch/arm/cpu/armv7/omap4/clocks.c create mode 100644 arch/arm/cpu/armv7/omap4/clocks_get_m_n.c create mode 100644 arch/arm/include/asm/arch-omap4/clocks.h

Quoted 5 lines

It appears this might be part of or taken from some bigger scope clocks framework. Otherwise it's diffcult for me to understand why OMAP4 needs 1400+ lines of code, when other SoCs appear to do with considerably less. Please comment.

No. This code was written for SPL. Please note that a lot of it is tables used for PLL locking, clock enabling etc. OMAP4 supports different crystal frequencies. So, more entries in each table. Also, there are some special handling based on the OMAP4 revisions because of some frequency limitations. So, more number of tables.

Quoted 11 lines

arch/arm/cpu/armv7/omap4/Makefile SOBJS += lowlevel_init.o · line 33

Quoted 9 lines
arch/arm/cpu/armv7/omap4/Makefile +1 -0
index 987dc9d..6154e86 100644
@@ -30,6 +30,7 @@ SOBJS	+= lowlevel_init.o
  COBJS	+= board.o
  COBJS	+= mem.o
  COBJS	+= sys_info.o
+COBJS	+= clocks.o

Please keep lists sorted.

ok.

Quoted 44 lines

...

arch/arm/cpu/armv7/omap4/Makefile

Quoted 7 lines
arch/arm/cpu/armv7/omap4/Makefile +7 -0
+static inline void do_bypass_dpll(u32 base)
+{
+	struct dpll_regs *dpll_regs = (struct dpll_regs *)base;
+
+	modify_reg_32(&dpll_regs->cm_clkmode_dpll,
+		      CM_CLKMODE_DPLL_DPLL_EN_SHIFT,
+		      CM_CLKMODE_DPLL_DPLL_EN_MASK, DPLL_EN_FAST_RELOCK_BYPASS);

NAK, please use standard macros (see previous messages).

Quoted 4 lines
arch/arm/cpu/armv7/omap4/Makefile +4 -0
+static void do_setup_dpll(u32 base, const struct dpll_params *params, u8 lock)
+{
+	u32 temp;
+	struct dpll_regs *dpll_regs = (struct dpll_regs *)base;

arch/arm/cpu/armv7/omap4/Makefile

Quoted 10 lines
arch/arm/cpu/armv7/omap4/Makefile +10 -0
+
+	bypass_dpll(base);
+
+	/* Set M&  N */
+	temp = readl(&dpll_regs->cm_clksel_dpll);
+	set_bit_field(temp, CM_CLKSEL_DPLL_M_SHIFT, CM_CLKSEL_DPLL_M_MASK,
+			params->m);
+	set_bit_field(temp, CM_CLKSEL_DPLL_N_SHIFT, CM_CLKSEL_DPLL_N_MASK,
+			params->n);
+	writel(temp,&dpll_regs->cm_clksel_dpll);

NAK, please use standard macros (see previous messages).

...

Quoted 6 lines
arch/arm/cpu/armv7/omap4/clocks_get_m_n.c new file +0 -0
new file mode 100644
index 0000000..777ec11
@@ -0,0 +1,154 @@

...

Quoted 1 line

+void main(void)

It appears this is a host program, not part of U-Boot. I don't think that arch/arm/cpu/armv7/omap4/ is the right place for this program.

...

...

Quoted 5 lines
Quoted 5 lines
arch/arm/cpu/armv7/omap4/clocks_get_m_n.c new file +5 -0
+#define CM_CLKMODE_DPLL_DDRPHY		(OMAP44XX_L4_CORE_BASE + 0x4220)
+#define CM_IDLEST_DPLL_DDRPHY		(OMAP44XX_L4_CORE_BASE + 0x4224)
+#define CM_AUTOIDLE_DPLL_DDRPHY		(OMAP44XX_L4_CORE_BASE + 0x4228)
+#define CM_CLKSEL_DPLL_DDRPHY		(OMAP44XX_L4_CORE_BASE + 0x422c)
+#define CM_DIV_M2_DPLL_DDRPHY		(OMAP44XX_L4_CORE_BASE + 0x4230)
Quoted 9 lines

arch/arm/cpu/armv7/omap4/clocks_get_m_n.c

Quoted 5 lines
arch/arm/cpu/armv7/omap4/clocks_get_m_n.c new file +5 -0
+#define CM_DIV_M4_DPLL_DDRPHY		(OMAP44XX_L4_CORE_BASE + 0x4238)
+#define CM_DIV_M5_DPLL_DDRPHY		(OMAP44XX_L4_CORE_BASE + 0x423c)
+#define CM_DIV_M6_DPLL_DDRPHY		(OMAP44XX_L4_CORE_BASE + 0x4240)
+#define CM_SSC_DELTAMSTEP_DPLL_DDRPHY	(OMAP44XX_L4_CORE_BASE + 0x4248)
+#define CM_SHADOW_FREQ_CONFIG1		(OMAP44XX_L4_CORE_BASE + 0x4260)

NAK. We do not accept base address plus offset notation. Please declare C structs instead.

Ok. will do.

Again just curious, what's the reasoning behind this policy? Is it just aesthetics or something more?

best regards,
Aneesh

#129 lore raw

PATCH v2 13/22 omap4: add clock support

Dear Aneesh V,

Quoted 11 lines · In message <[email protected]> you wrote:
Quoted 5 lines

It appears this might be part of or taken from some bigger scope clocks framework. Otherwise it's diffcult for me to understand why OMAP4 needs 1400+ lines of code, when other SoCs appear to do with considerably less. Please comment.

No. This code was written for SPL. Please note that a lot of it is tables used for PLL locking, clock enabling etc. OMAP4 supports different crystal frequencies. So, more entries in each table. Also, there are some special handling based on the OMAP4 revisions because of some frequency limitations. So, more number of tables.

hm... is this really a type of selection that has to be done at runtime? In the real system, the frequencies will probably pretty much fixed, and not dynamically adjusted in U-Boot. So maybe we can compile at least poarts of this at build time?

Quoted 8 lines
Quoted 3 lines

NAK. We do not accept base address plus offset notation. Please declare C structs instead.

Ok. will do.

Again just curious, what's the reasoning behind this policy? Is it just aesthetics or something more?

It's more. When using base+offset, the compiler will know nothing about the data type, so it canot warn you if you use a 32 bit accessor on a 8 bit register, or vice versa. When you pass a struct element, it can check type information.

Best regards,

Wolfgang Denk

Signature · 7 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
How many seconds are there in a year? If I tell you there are 3.155 x
10^7, you won't even try to remember it. On the other hand, who could
forget that, to within half a percent, pi seconds is  a  nanocentury.
                                               -- Tom Duff, Bell Labs
author
#130 lore raw

PATCH v2 13/22 omap4: add clock support

Dear Wolfgang,

Quoted 2 lines · Wolfgang Denk

Dear Aneesh V,

[snip ...]

Quoted 6 lines
Quoted 6 lines
Quoted 3 lines

NAK. We do not accept base address plus offset notation. Please declare C structs instead.

Ok. will do.

Quoted 7 lines
Quoted 2 lines

Again just curious, what's the reasoning behind this policy? Is it just aesthetics or something more?

It's more. When using base+offset, the compiler will know nothing about the data type, so it canot warn you if you use a 32 bit accessor on a 8 bit register, or vice versa. When you pass a struct element, it can check type information.

Is this really valid in our context? readl()/writel() and friends just cast the address to the target type pointer. I tried writeb() on my 32 bit register represented using the struct approach and the compiler didn't give any warning (as expected)!

best regards,
Aneesh

#131 lore raw

PATCH v2 13/22 omap4: add clock support

Dear Aneesh V,

Quoted 10 lines · In message <[email protected]> you wrote:
Quoted 5 lines

It's more. When using base+offset, the compiler will know nothing about the data type, so it canot warn you if you use a 32 bit accessor on a 8 bit register, or vice versa. When you pass a struct element, it can check type information.

Is this really valid in our context? readl()/writel() and friends just cast the address to the target type pointer. I tried writeb() on my 32 bit register represented using the struct approach and the compiler didn't give any warning (as expected)!

Yes, we should fix the I/O accessors definitons on ARM to provide strict type checking.

Best regards,

Wolfgang Denk

Signature · 4 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
 The software required `Windows 95 or better', so I installed Linux.
author
#132 lore raw

PATCH v2 13/22 omap4: add clock support

In reply to Aneesh V

Dear Wolfgang,

On Sunday 15 May 2011 08:51 PM, Aneesh V wrote:
[snip ..]

Quoted 4 lines
arch/arm/cpu/armv7/omap4/clocks.c new file +4 -0
+static const u32 clk_modules_hw_auto_essential[] = {
+	CM_WKUP_GPIO1_CLKCTRL,
+	CM_L4PER_GPIO2_CLKCTRL,
+	CM_L4PER_GPIO3_CLKCTRL,

arch/arm/cpu/armv7/omap4/clocks.c line 184

Quoted 10 lines
arch/arm/cpu/armv7/omap4/clocks.c new file +10 -0
+	CM_L4PER_GPIO4_CLKCTRL,
+	CM_L4PER_GPIO5_CLKCTRL,
+	CM_L4PER_GPIO6_CLKCTRL,
+	CM_MEMIF_EMIF_1_CLKCTRL,
+	CM_MEMIF_EMIF_2_CLKCTRL,
+	CM_L3INIT_HSUSBOTG_CLKCTRL,
+	CM_L3INIT_USBPHY_CLKCTRL,
+	CM_L4CFG_L4_CFG_CLKCTRL,
+	0
+};

In this series you asked me to convert the base + offset mode of register address definition to struct based register address definition. While doing this I am facing a problem. Please note the above array that contain register addresses. This is a group of registers that control our clock modules. All these registers have similar bit fields and they can be programmed in same manner. So, I keep them in an array and pass the array to a function that iterates through array and does similar processing on all the registers(see below).

I am finding it difficult to implement this using the struct based approach. I tried the sample code below:

struct my_regs_struct {
	const unsigned int reg1;
	const unsigned int reg2;
	const unsigned int reg3;
};

static struct my_regs_struct *const my_regs = (struct my_regs_struct *)0x1000;

static unsigned int *const reg_arr[] = {
	&my_regs->reg1,
	&my_regs->reg3
};

void main(void)

{
	printf("regs %x %x \n", reg_arr[0], reg_arr[1]);
}

I am getting the following errors on compiling this:
main.c:10: error: initializer element is not constant main.c:10: error: (near initialization for ?reg_arr[0]?) main.c:12: error: initializer element is not constant main.c:12: error: (near initialization for ?reg_arr[1]?)

I can't make it work unless I make my_regs a statically defined structure itself and not a pointer - like this:

static struct my_regs_struct my_regs;

This seems quite strange(behavior is the same with gcc and Microsoft compiler). Am I missing something?

Any ideas to make it work? If not, can I go back to defines for the addresses. All the registers we have are 32 bit long and we always use u32 for them and use readl/writel for accessor functions. Using the wrong accessor function is highly unlikely.

[snip ...]

arch/arm/cpu/armv7/omap4/clocks.c line 599

Quoted 6 lines
arch/arm/cpu/armv7/omap4/clocks.c new file +6 -0
+	/* Clock modules that need to be put in HW_AUTO */
+	for (i = 0; (i<  max)&&  clock_modules_hw_auto[i]; i++) {
+		enable_clock_module(clock_modules_hw_auto[i],
+				    MODULE_CLKCTRL_MODULEMODE_HW_AUTO,
+				    wait_for_enable);
+	};

best regards,
Aneesh

author
#133 lore raw

PATCH v2 13/22 omap4: add clock support

Dear Wolfgang,

Quoted 38 lines · Aneesh V

Dear Wolfgang,

On Sunday 15 May 2011 08:51 PM, Aneesh V wrote:
[snip ..]

Quoted 4 lines
arch/arm/cpu/armv7/omap4/clocks.c new file +4 -0
+static const u32 clk_modules_hw_auto_essential[] = {
+ CM_WKUP_GPIO1_CLKCTRL,
+ CM_L4PER_GPIO2_CLKCTRL,
+ CM_L4PER_GPIO3_CLKCTRL,

arch/arm/cpu/armv7/omap4/clocks.c line 184

Quoted 10 lines
arch/arm/cpu/armv7/omap4/clocks.c new file +10 -0
+ CM_L4PER_GPIO4_CLKCTRL,
+ CM_L4PER_GPIO5_CLKCTRL,
+ CM_L4PER_GPIO6_CLKCTRL,
+ CM_MEMIF_EMIF_1_CLKCTRL,
+ CM_MEMIF_EMIF_2_CLKCTRL,
+ CM_L3INIT_HSUSBOTG_CLKCTRL,
+ CM_L3INIT_USBPHY_CLKCTRL,
+ CM_L4CFG_L4_CFG_CLKCTRL,
+ 0
+};

In this series you asked me to convert the base + offset mode of register address definition to struct based register address definition. While doing this I am facing a problem. Please note the above array that contain register addresses. This is a group of registers that control our clock modules. All these registers have similar bit fields and they can be programmed in same manner. So, I keep them in an array and pass the array to a function that iterates through array and does similar processing on all the registers(see below).

I am finding it difficult to implement this using the struct based approach. I tried the sample code below:

struct my_regs_struct {
const unsigned int reg1;
const unsigned int reg2;
const unsigned int reg3;
};

Quoted 7 lines

static struct my_regs_struct *const my_regs = (struct my_regs_struct *)0x1000;

static unsigned int *const reg_arr[] = {
&my_regs->reg1,
&my_regs->reg3
};

Apologies for the hasty mail. Looks like I can solve it by doing something like:

static unsigned int *const reg_arr[] = {
	&(((struct my_regs_struct *)0x1000)->reg1),
	&(((struct my_regs_struct *)0x1000)->reg3),
};

Analyzing this further right now. Hopefully, the issue can be solved cleanly.

best regards,
Aneesh

author
#134 lore raw

PATCH v2 13/22 omap4: add clock support

Quoted 52 lines · Aneesh V

Dear Wolfgang,

Quoted 38 lines · Aneesh V

Dear Wolfgang,

On Sunday 15 May 2011 08:51 PM, Aneesh V wrote:
[snip ..]

Quoted 4 lines
arch/arm/cpu/armv7/omap4/clocks.c new file +4 -0
+static const u32 clk_modules_hw_auto_essential[] = {
+ CM_WKUP_GPIO1_CLKCTRL,
+ CM_L4PER_GPIO2_CLKCTRL,
+ CM_L4PER_GPIO3_CLKCTRL,

arch/arm/cpu/armv7/omap4/clocks.c line 184

Quoted 10 lines
arch/arm/cpu/armv7/omap4/clocks.c new file +10 -0
+ CM_L4PER_GPIO4_CLKCTRL,
+ CM_L4PER_GPIO5_CLKCTRL,
+ CM_L4PER_GPIO6_CLKCTRL,
+ CM_MEMIF_EMIF_1_CLKCTRL,
+ CM_MEMIF_EMIF_2_CLKCTRL,
+ CM_L3INIT_HSUSBOTG_CLKCTRL,
+ CM_L3INIT_USBPHY_CLKCTRL,
+ CM_L4CFG_L4_CFG_CLKCTRL,
+ 0
+};

In this series you asked me to convert the base + offset mode of register address definition to struct based register address definition. While doing this I am facing a problem. Please note the above array that contain register addresses. This is a group of registers that control our clock modules. All these registers have similar bit fields and they can be programmed in same manner. So, I keep them in an array and pass the array to a function that iterates through array and does similar processing on all the registers(see below).

I am finding it difficult to implement this using the struct based approach. I tried the sample code below:

struct my_regs_struct {
const unsigned int reg1;
const unsigned int reg2;
const unsigned int reg3;
};

Quoted 7 lines

static struct my_regs_struct *const my_regs = (struct my_regs_struct *)0x1000;

static unsigned int *const reg_arr[] = {
&my_regs->reg1,
&my_regs->reg3
};

Apologies for the hasty mail. Looks like I can solve it by doing something like:

Quoted 8 lines

static unsigned int *const reg_arr[] = {
&(((struct my_regs_struct *)0x1000)->reg1),
&(((struct my_regs_struct *)0x1000)->reg3),
};

Analyzing this further right now. Hopefully, the issue can be solved cleanly.

Some more interesting information:

I can reproduce the problem with something as simple as this:

main.c:
const int const1 = 10;
const int const2 = 11;

int arr[] = {
	const1,
	const2
};
$ gcc main.c
main.c:5: error: initializer element is not constant
main.c:5: error: (near initialization for ?arr[0]?)
main.c:7: error: initializer element is not constant
main.c:7: error: (near initialization for ?arr[1]?)

The ARM compiler RVCT happily compiles this without an issue. GCC and Visual C++ compilers fail!

As a result, I will have to do something like this to populate my array:

static unsigned int *const reg_arr[] = {
	&(((struct my_regs_struct *const)OMAP4_PRCM_REG_BASE)->uart_clkctrl),
	&(((struct my_regs_struct *const)OMAP4_PRCM_REG_BASE)->i2c_clkctrl),
};

Is this acceptable?

best regards,
Aneesh

#135 lore raw

PATCH v2 13/22 omap4: add clock support

Dear Aneesh,

Quoted 6 lines · In message <[email protected]> you wrote:
$ gcc main.c
main.c:5: error: initializer element is not constant
main.c:5: error: (near initialization for ?arr[0]?)
main.c:7: error: initializer element is not constant
main.c:7: error: (near initialization for ?arr[1]?)

I have to admit that I don't understand either why this error is raised here; after all, from our understanding of the code these _are_ constant addresses.

You may want to ask this in a compiler group...

Quoted 9 lines

As a result, I will have to do something like this to populate my array:

static unsigned int *const reg_arr[] = {
	&(((struct my_regs_struct *const)OMAP4_PRCM_REG_BASE)->uart_clkctrl),
	&(((struct my_regs_struct *const)OMAP4_PRCM_REG_BASE)->i2c_clkctrl),
};

Is this acceptable?

No, please don't.

Note that the following code compiles fine:

----------------------------- snip ----------------------------- #include <stdio.h>

struct my_regs_struct {
	unsigned int reg1;
	unsigned int reg2;
	unsigned int reg3;
};

static struct my_regs_struct *const my_regs = (struct my_regs_struct *) 0x1000;

static void print_regs(void)

{
	unsigned int *const reg_arr[] = {
		&my_regs->reg1,
		&my_regs->reg3,
	};
	printf("regs %p %p \n", (void *)reg_arr[0], (void *)reg_arr[1]);
}

int main(void)

{
	print_regs();
	return 0;
}

----------------------------- snip -----------------------------

With "gcc -Wall -pedantic" you will get warnings "initializer element is not computable at load time [enabled by default]", but this can be avoided by adding "--std=c99" to the compiler options.

Best regards,

Wolfgang Denk

Signature · 4 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Wish not to seem, but to be, the best."                  - Aeschylus
author
#136 lore raw

PATCH v2 13/22 omap4: add clock support

Quoted 10 lines · Wolfgang Denk

Dear Aneesh,

Quoted 6 lines · In message<[email protected]> you wrote:
$ gcc main.c
main.c:5: error: initializer element is not constant
main.c:5: error: (near initialization for ?arr[0]?)
main.c:7: error: initializer element is not constant
main.c:7: error: (near initialization for ?arr[1]?)
Quoted 5 lines

I have to admit that I don't understand either why this error is raised here; after all, from our understanding of the code these _are_ constant addresses.

You may want to ask this in a compiler group...

Yes. I will.

Quoted 26 lines
Quoted 10 lines

As a result, I will have to do something like this to populate my array:

static unsigned int *const reg_arr[] = {
	&(((struct my_regs_struct *const)OMAP4_PRCM_REG_BASE)->uart_clkctrl),
	&(((struct my_regs_struct *const)OMAP4_PRCM_REG_BASE)->i2c_clkctrl),
};

Is this acceptable?

No, please don't.

Note that the following code compiles fine:

----------------------------- snip ----------------------------- #include<stdio.h>

struct my_regs_struct {
	unsigned int reg1;
	unsigned int reg2;
	unsigned int reg3;
};

static struct my_regs_struct *const my_regs = (struct my_regs_struct *) 0x1000;

Quoted 8 lines

static void print_regs(void)

{
	unsigned int *const reg_arr[] = {
		&my_regs->reg1,
		&my_regs->reg3,
	};
	printf("regs %p %p \n", (void *)reg_arr[0], (void *)reg_arr[1]);
}

In my function I am using 3 such arrays with quite a few entries in them. Won't it look ugly besides increasing the stack footprint.

Of course, I can try to break them down to different functions, if need be.

Or, how about using a utility macro and make it look better like this:

#define OMAP4_PRCM_REG_ADDR(reg)\
	(&(((struct my_regs_struct *)OMAP4_PRCM_BASE)->reg))

static unsigned int *const reg_arr[] = {
OMAP4_PRCM_REG_ADDR(uart_clkctrl),
OMAP4_PRCM_REG_ADDR(i2c_clkctrl)
};

This one doesn't generate any warning even with 'gcc -Wall -pedantic'.

Are you not comfortable with getting the address in this manner at all?

best regards,
Aneesh

#137 lore raw

PATCH v2 13/22 omap4: add clock support

Dear Aneesh V,

Quoted 3 lines · In message <[email protected]> you wrote:

In my function I am using 3 such arrays with quite a few entries in them. Won't it look ugly besides increasing the stack footprint.

I don;t see a significant difference whether you declare these arrays inside a function or with file scope.

Regarding the stack footprint: this would actually even be preferrable (assuming this code is run after relocation to RAM), and from what I've seen in the example, the compiler actually optimizes the code and does not really allocate such an array if you don't use it otherwise (like passing it to other functions).

Quoted 4 lines

Or, how about using a utility macro and make it look better like this:

#define OMAP4_PRCM_REG_ADDR(reg)\
	(&(((struct my_regs_struct *)OMAP4_PRCM_BASE)->reg))

I consider this code too ugly.

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Plan to throw one away. You will anyway."
                              - Fred Brooks, "The Mythical Man Month"
author
#138 lore raw

PATCH v2 13/22 omap4: add clock support

Quoted 4 lines · Wolfgang Denk

Dear Aneesh V,

Quoted 1 line · In message<[email protected]> you wrote:
Quoted 8 lines
Quoted 2 lines

In my function I am using 3 such arrays with quite a few entries in them. Won't it look ugly besides increasing the stack footprint.

I don;t see a significant difference whether you declare these arrays inside a function or with file scope.

Regarding the stack footprint: this would actually even be preferrable (assuming this code is run after relocation to RAM), and from what

Indeed this runs before relocation. But I think I can keep the array size to a reasonable level by splitting the function. Also, as you said if the array is optimized out there should not be any problem.

best regards,
Aneesh

author
#139 lore raw

PATCH v2 13/22 omap4: add clock support

In reply to Aneesh V
Quoted 11 lines · Aneesh V
Quoted 10 lines · Wolfgang Denk

Dear Aneesh,

Quoted 6 lines · In message<[email protected]> you wrote:
$ gcc main.c
main.c:5: error: initializer element is not constant
main.c:5: error: (near initialization for ?arr[0]?)
main.c:7: error: initializer element is not constant
main.c:7: error: (near initialization for ?arr[1]?)
Quoted 7 lines
Quoted 5 lines

I have to admit that I don't understand either why this error is raised here; after all, from our understanding of the code these _are_ constant addresses.

You may want to ask this in a compiler group...

Yes. I will.

I asked in the GCC mailing list and got this reply. That also seems to explain why the array as a local variable worked.

http://gcc.gnu.org/ml/gcc/2011-06/msg00291.html

best regards,
Aneesh

#140 lore raw

PATCH v2 13/22 omap4: add clock support

In reply to Aneesh V

Dear Aneesh V,

Quoted 18 lines · In message <[email protected]> you wrote:

I am finding it difficult to implement this using the struct based approach. I tried the sample code below:

struct my_regs_struct {
	const unsigned int reg1;
	const unsigned int reg2;
	const unsigned int reg3;
};

static struct my_regs_struct *const my_regs = (struct my_regs_struct *)0x1000;

static unsigned int *const reg_arr[] = {
	&my_regs->reg1,
	&my_regs->reg3
};
Quoted 4 lines

void main(void)

{
	printf("regs %x %x \n", reg_arr[0], reg_arr[1]);
}

Sorry, but I fail to understand the problem. Why is reg_arr[] needed? Why don't you use

	struct my_regs_struct {
		const unsigned int reg[3];
	};

?

Best regards,

Wolfgang Denk

Signature · 7 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
But it's real. And if it's real it can be affected ... we may not  be
able  to break it, but, I'll bet you credits to Navy Beans we can put
a dent in it.
	-- deSalle, "Catspaw", stardate 3018.2
author
#141 lore raw

PATCH v2 13/22 omap4: add clock support

Quoted 13 lines · Wolfgang Denk

Dear Aneesh V,

Quoted 10 lines · In message<[email protected]> you wrote:

I am finding it difficult to implement this using the struct based approach. I tried the sample code below:

struct my_regs_struct {
	const unsigned int reg1;
	const unsigned int reg2;
	const unsigned int reg3;
};

The const for structure fields above were not intended. I put them while debugging this issue and forgot to remove later.

Quoted 13 lines
Quoted 8 lines

static struct my_regs_struct *const my_regs = (struct my_regs_struct *)0x1000;

static unsigned int *const reg_arr[] = {
	&my_regs->reg1,
	&my_regs->reg3
};
Quoted 4 lines

void main(void)

{
	printf("regs %x %x \n", reg_arr[0], reg_arr[1]);
}
Quoted 7 lines

Sorry, but I fail to understand the problem. Why is reg_arr[] needed? Why don't you use

	struct my_regs_struct {
		const unsigned int reg[3];
	};

?

I want a number of register addresses in an array - an array of constant pointers. The array is populated at compile time with the addresses of all the modules that need to be initialized. At run-time I do a specific operation on all the registers given in this array.

best regards,
Aneesh

author
#142 lore raw

PATCH v2 14/22 omap4: add serial console support to SPL

In reply to Aneesh V
---
 arch/arm/cpu/armv7/omap4/board.c            |    3 ++
 arch/arm/cpu/armv7/omap4/clocks.c           |   27 ++++++++++++++++++
 arch/arm/include/asm/arch-omap4/sys_proto.h |    2 +
 arch/arm/include/asm/omap_common.h          |    1 +
 spl/board/ti/omap4.mk                       |   40 +++++++++++++++++++++++++++
 spl/board/ti/spl-omap.c                     |   20 +++++++++++++
 6 files changed, 93 insertions(+), 0 deletions(-)
arch/arm/cpu/armv7/omap4/board.c +3 -0
index f83b6d7..4a37171 100644
@@ -105,6 +105,9 @@ void s_init(void)
 {
 	watchdog_init();
 	set_mux_conf_regs();
+#ifdef CONFIG_PRELOADER
+	preloader_console_init();
+#endif
 	prcm_init();
 }
 
arch/arm/cpu/armv7/omap4/clocks.c +27 -0
index 802917f..c405b5c 100644
@@ -713,6 +713,33 @@ void lock_dpll(u32 base)
 	wait_for_lock(base);
 }
 
+void setup_clocks_for_console(void)
+{
+	/* Do not add any spl_debug prints in this function */
+	modify_reg_32(CM_L4PER_CLKSTCTRL, CD_CLKCTRL_CLKTRCTRL_SHIFT,
+		      CD_CLKCTRL_CLKTRCTRL_MASK, CD_CLKCTRL_CLKTRCTRL_SW_WKUP);
+
+	/* Enable all UARTs - console will be on one of them */
+	modify_reg_32(CM_L4PER_UART1_CLKCTRL, MODULE_CLKCTRL_MODULEMODE_SHIFT,
+			MODULE_CLKCTRL_MODULEMODE_MASK,
+			MODULE_CLKCTRL_MODULEMODE_SW_EXPLICIT_EN);
+
+	modify_reg_32(CM_L4PER_UART2_CLKCTRL, MODULE_CLKCTRL_MODULEMODE_SHIFT,
+			MODULE_CLKCTRL_MODULEMODE_MASK,
+			MODULE_CLKCTRL_MODULEMODE_SW_EXPLICIT_EN);
+
+	modify_reg_32(CM_L4PER_UART3_CLKCTRL, MODULE_CLKCTRL_MODULEMODE_SHIFT,
+			MODULE_CLKCTRL_MODULEMODE_MASK,
+			MODULE_CLKCTRL_MODULEMODE_SW_EXPLICIT_EN);
+
+	modify_reg_32(CM_L4PER_UART3_CLKCTRL, MODULE_CLKCTRL_MODULEMODE_SHIFT,
+			MODULE_CLKCTRL_MODULEMODE_MASK,
+			MODULE_CLKCTRL_MODULEMODE_SW_EXPLICIT_EN);
+
+	modify_reg_32(CM_L4PER_CLKSTCTRL, CD_CLKCTRL_CLKTRCTRL_SHIFT,
+		      CD_CLKCTRL_CLKTRCTRL_MASK, CD_CLKCTRL_CLKTRCTRL_HW_AUTO);
+}
+
 void prcm_init(void)
 {
 	switch (omap4_hw_init_context()) {
arch/arm/include/asm/arch-omap4/sys_proto.h +2 -0
index 4ba0ee0..3ac972d 100644
@@ -38,12 +38,14 @@ void set_muxconf_regs_non_essential(void);
 void sr32(void *, u32, u32, u32);
 u32 wait_on_value(u32, u32, void *, u32);
 void sdelay(unsigned long);
+void setup_clocks_for_console(void);
 void prcm_init(void);
 void bypass_dpll(u32 base);
 void freq_update_core(void);
 u32 get_sys_clk_freq(void);
 u32 omap4_ddr_clk(void);
 u32 omap4_revision(void);
+const char *omap4_rev_string(void);
 
 static inline u32 running_from_sdram(void)
 {
arch/arm/include/asm/omap_common.h +1 -0
index 787dd88..10fc9c8 100644
@@ -53,5 +53,6 @@
 
 u32 omap_boot_device(void);
 u32 omap_boot_mode(void);
+void preloader_console_init(void);
 
 #endif /* _OMAP_COMMON_H_ */
spl/board/ti/omap4.mk +40 -0
index 0374534..508dc3b 100644
@@ -32,6 +32,46 @@ include $(TOPDIR)/config.mk
 SOBJS =
 COBJS =
 
+# serial console
+$(obj)eabi_compat.c:
+	@rm -f $@
+	@ln -s $(TOPDIR)/arch/arm/lib/eabi_compat.c $@
+
+$(obj)string.c:
+	@rm -f $@
+	@ln -s $(TOPDIR)/lib/string.c $@
+
+$(obj)vsprintf.c:
+	@rm -f $@
+	@ln -s $(TOPDIR)/lib/vsprintf.c $@
+
+$(obj)console.c:
+	@rm -f $@
+	@ln -s $(TOPDIR)/common/console.c $@
+
+$(obj)stdio.c:
+	@rm -f $@
+	@ln -s $(TOPDIR)/common/stdio.c $@
+
+$(obj)serial.c:
+	@rm -f $@
+	@ln -s $(TOPDIR)/drivers/serial/serial.c $@
+
+$(obj)ns16550.c:
+	@rm -f $@
+	@ln -s $(TOPDIR)/drivers/serial/ns16550.c $@
+
+$(obj)div64.c:
+	@rm -f $@
+	@ln -s $(TOPDIR)/lib/div64.c $@
+
+$(obj)ctype.c:
+	@rm -f $@
+	@ln -s $(TOPDIR)/lib/ctype.c $@
+
+COBJS	+= serial.o ns16550.o string.o vsprintf.o console.o stdio.o
+COBJS	+= ctype.o eabi_compat.o div64.o
+
 # armv7
 $(obj)start.S:
 	@rm -f $@
spl/board/ti/spl-omap.c +20 -0
index 0e08f4f..855572f 100644
@@ -29,6 +29,7 @@
 #include <asm/u-boot.h>
 #include <asm/arch/sys_proto.h>
 #include <timestamp_autogenerated.h>
+#include <version_autogenerated.h>
 
 /* Define global data structure pointer to it*/
 gd_t gdata __attribute__ ((section(".data")));
@@ -45,3 +46,22 @@ void board_init_r(gd_t *id, ulong dummy)
 	for (;;)
 		;
 }
+
+void preloader_console_init(void)
+{
+	const char *u_boot_rev = U_BOOT_VERSION;
+
+	gd->bd = &bdata;
+	gd->flags |= GD_FLG_RELOC;
+	gd->baudrate = CONFIG_BAUDRATE;
+
+	setup_clocks_for_console();
+	serial_init();		/* serial communications setup */
+
+	/* Avoid a second "U-Boot" coming from this string */
+	u_boot_rev = &u_boot_rev[7];
+
+	printf("\nU-Boot SPL %s (%s - %s)\n", u_boot_rev, U_BOOT_DATE,
+		U_BOOT_TIME);
+	printf("Texas Instruments %s\n", omap4_rev_string());
+}
Signature · 1 line
1.7.0.4
author
#143 lore raw

PATCH v2 15/22 omap4: add sdram init support

In reply to Aneesh V

Add support for the SDRAM controller (EMIF).

V2:
* Changes for makefile changes
* Minor corrections in do_lpddr2_init()
* Minor corrections to read_idle interval calculation
* Sanity test of memory after doing the initialization
* Fixed warnings reported with with latest GCC compilers

---
 arch/arm/cpu/armv7/omap4/Makefile           |    3 +
 arch/arm/cpu/armv7/omap4/board.c            |    2 +-
 arch/arm/cpu/armv7/omap4/emif.c             |  298 +++++++++++
 arch/arm/cpu/armv7/omap4/sdram_elpida.c     |  118 +++++
 arch/arm/include/asm/arch-omap4/emif.h      |  719 +++++++++++++++++++++++++++
 arch/arm/include/asm/arch-omap4/omap4.h     |   11 +
 arch/arm/include/asm/arch-omap4/sys_proto.h |    1 +
 include/configs/omap4_sdp4430.h             |    5 -
 spl/board/ti/omap4.mk                       |    9 +-
 9 files changed, 1159 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/omap4/emif.c
 create mode 100644 arch/arm/cpu/armv7/omap4/sdram_elpida.c
 create mode 100644 arch/arm/include/asm/arch-omap4/emif.h
arch/arm/cpu/armv7/omap4/Makefile +3 -0
index 6154e86..d9714fe 100644
@@ -31,6 +31,9 @@ COBJS	+= board.o
 COBJS	+= mem.o
 COBJS	+= sys_info.o
 COBJS	+= clocks.o
+COBJS	+= emif.o
+COBJS	+= sdram_elpida.o
+
 
 SRCS	:= $(SOBJS:.o=.S) $(COBJS:.o=.c)
 OBJS	:= $(addprefix $(obj),$(COBJS) $(SOBJS))
arch/arm/cpu/armv7/omap4/board.c +1 -1
index 4a37171..7add46b 100644
@@ -109,6 +109,7 @@ void s_init(void)
 	preloader_console_init();
 #endif
 	prcm_init();
+	sdram_init();
 }
 
 /*
@@ -169,7 +170,6 @@ u32 sdram_size(void)
  */
 int dram_init(void)
 {
-
 	gd->ram_size = sdram_size();
 
 	return 0;
arch/arm/cpu/armv7/omap4/emif.c new file +298 -0

298 lines not on this page · raw message

arch/arm/cpu/armv7/omap4/sdram_elpida.c new file +118 -0

118 lines not on this page · raw message

arch/arm/include/asm/arch-omap4/emif.h new file +719 -0

719 lines not on this page · raw message

arch/arm/include/asm/arch-omap4/omap4.h +11 -0
index 740ca9d..a1c4883 100644
@@ -51,6 +51,17 @@
 #define CONTROL_PADCONF_CORE	(OMAP44XX_L4_CORE_BASE + 0x100000)
 #define CONTROL_PADCONF_WKUP	(OMAP44XX_L4_CORE_BASE + 0x31E000)
 
+/* LPDDR2 IO regs */
+#define CONTROL_LPDDR2IO1_0	(CONTROL_PADCONF_CORE + 0x0638)
+#define CONTROL_LPDDR2IO1_1	(CONTROL_PADCONF_CORE + 0x063C)
+#define CONTROL_LPDDR2IO1_2	(CONTROL_PADCONF_CORE + 0x0640)
+#define CONTROL_LPDDR2IO1_3	(CONTROL_PADCONF_CORE + 0x0644)
+#define CONTROL_LPDDR2IO2_0	(CONTROL_PADCONF_CORE + 0x0648)
+#define CONTROL_LPDDR2IO2_1	(CONTROL_PADCONF_CORE + 0x064C)
+#define CONTROL_LPDDR2IO2_2	(CONTROL_PADCONF_CORE + 0x0650)
+#define CONTROL_LPDDR2IO2_3	(CONTROL_PADCONF_CORE + 0x0654)
+#define CONTROL_EFUSE_2		(CONTROL_PADCONF_CORE + 0x0704)
+
 /* CONTROL_ID_CODE */
 #define CONTROL_ID_CODE		(CTRL_BASE + 0x204)
 
arch/arm/include/asm/arch-omap4/sys_proto.h +1 -0
index 3ac972d..3fce576 100644
@@ -44,6 +44,7 @@ void bypass_dpll(u32 base);
 void freq_update_core(void);
 u32 get_sys_clk_freq(void);
 u32 omap4_ddr_clk(void);
+void sdram_init(void);
 u32 omap4_revision(void);
 const char *omap4_rev_string(void);
 
include/configs/omap4_sdp4430.h +0 -5
index 99247df..ae009d6 100644
@@ -249,11 +249,6 @@
 /* Defines for Clock init */
 #define CONFIG_SYS_OMAP4_ABE_SYSCK
 
-/* Defines for SDRAM init */
-#define CONFIG_SYS_AUTOMATIC_SDRAM_DETECTION	1
-#define CONFIG_SYS_EMIF_UPDATE_TIMINGS		1
-#define CONFIG_SYS_DEFAULT_LPDDR2_TIMINGS	1
-
 /* Defines for SPL */
 #define CONFIG_SPL
 #define CONFIG_SYS_SPL_TEXT_BASE	0x40304350
spl/board/ti/omap4.mk +8 -1
index 508dc3b..85b40ca 100644
@@ -117,6 +117,13 @@ $(obj)clocks.c:
 	@rm -f $@
 	@ln -s $(TOPDIR)/arch/arm/cpu/armv7/omap4/clocks.c $@
 
+$(obj)emif.c:
+	@rm -f $@
+	@ln -s $(TOPDIR)/arch/arm/cpu/armv7/omap4/emif.c $@
+
+$(obj)sdram_elpida.c:
+	@rm -f $@
+	@ln -s $(TOPDIR)/arch/arm/cpu/armv7/omap4/sdram_elpida.c $@
 
 SOBJS	+= lowlevel_init.o
-COBJS	+= board.o clocks.o
+COBJS	+= board.o clocks.o emif.o sdram_elpida.o
Signature · 1 line
1.7.0.4
#144 lore raw

PATCH v2 15/22 omap4: add sdram init support

Dear Aneesh V,

Quoted 9 lines · In message <[email protected]> you wrote:

Add support for the SDRAM controller (EMIF).

V2:
* Changes for makefile changes
* Minor corrections in do_lpddr2_init()
* Minor corrections to read_idle interval calculation
* Sanity test of memory after doing the initialization
* Fixed warnings reported with with latest GCC compilers

Quoted 14 lines
---
 arch/arm/cpu/armv7/omap4/Makefile           |    3 +
 arch/arm/cpu/armv7/omap4/board.c            |    2 +-
 arch/arm/cpu/armv7/omap4/emif.c             |  298 +++++++++++
 arch/arm/cpu/armv7/omap4/sdram_elpida.c     |  118 +++++
 arch/arm/include/asm/arch-omap4/emif.h      |  719 +++++++++++++++++++++++++++
 arch/arm/include/asm/arch-omap4/omap4.h     |   11 +
 arch/arm/include/asm/arch-omap4/sys_proto.h |    1 +
 include/configs/omap4_sdp4430.h             |    5 -
 spl/board/ti/omap4.mk                       |    9 +-
 9 files changed, 1159 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/omap4/emif.c
 create mode 100644 arch/arm/cpu/armv7/omap4/sdram_elpida.c
 create mode 100644 arch/arm/include/asm/arch-omap4/emif.h

I'm really surprised to see this patch at this position in the middle of this patch series.

Can you please explain why you think this is the right place for it?

Best regards,

Wolfgang Denk

Signature · 4 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
2000 pounds of chinese soup                               = 1 Won Ton
author
#145 lore raw

PATCH v2 15/22 omap4: add sdram init support

Quoted 27 lines · Wolfgang Denk

Dear Aneesh V,

Quoted 20 lines · In message<[email protected]> you wrote:

Add support for the SDRAM controller (EMIF).

V2:
* Changes for makefile changes
* Minor corrections in do_lpddr2_init()
* Minor corrections to read_idle interval calculation
* Sanity test of memory after doing the initialization
* Fixed warnings reported with with latest GCC compilers

---
  arch/arm/cpu/armv7/omap4/Makefile           |    3 +
  arch/arm/cpu/armv7/omap4/board.c            |    2 +-
  arch/arm/cpu/armv7/omap4/emif.c             |  298 +++++++++++
  arch/arm/cpu/armv7/omap4/sdram_elpida.c     |  118 +++++
  arch/arm/include/asm/arch-omap4/emif.h      |  719 +++++++++++++++++++++++++++
  arch/arm/include/asm/arch-omap4/omap4.h     |   11 +
  arch/arm/include/asm/arch-omap4/sys_proto.h |    1 +
  include/configs/omap4_sdp4430.h             |    5 -
  spl/board/ti/omap4.mk                       |    9 +-
  9 files changed, 1159 insertions(+), 7 deletions(-)
Quoted 3 lines

create mode 100644 arch/arm/cpu/armv7/omap4/emif.c create mode 100644 arch/arm/cpu/armv7/omap4/sdram_elpida.c create mode 100644 arch/arm/include/asm/arch-omap4/emif.h

Quoted 4 lines

I'm really surprised to see this patch at this position in the middle of this patch series.

Can you please explain why you think this is the right place for it?

This is roughly the sequence I followed.
1. Make the basic infrastructure.
2. Have a working skeleton of SPL(Just boots but doesn't do the loading part yet)
3. Add mux support.
4. Add clock initialization
5. Add SDRAM initialization(clock patch is a pre-requisite for this)
6. Add support for MMC initialization and loading of U-Boot
7. Add FAT mode boot support.
8. Add support for Panda

I think this will change a bit when I do some squashing as you suggested.

best regards,
Aneesh

#146 lore raw

PATCH v2 15/22 omap4: add sdram init support

Dear Aneesh V,

Quoted 13 lines · In message <[email protected]> you wrote:
Quoted 2 lines

Can you please explain why you think this is the right place for it?

This is roughly the sequence I followed.
1. Make the basic infrastructure.
2. Have a working skeleton of SPL(Just boots but doesn't do the loading part yet)
3. Add mux support.
4. Add clock initialization
5. Add SDRAM initialization(clock patch is a pre-requisite for this)
6. Add support for MMC initialization and loading of U-Boot
7. Add FAT mode boot support.
8. Add support for Panda

Quoted 2 lines

I think this will change a bit when I do some squashing as you suggested.

Thanks for the explanation. It was really helpful.

Best regards,

Wolfgang Denk

Signature · 4 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Backed up the system lately?
#147 lore raw

PATCH v2 15/22 omap4: add sdram init support

In reply to Aneesh V

Dear Aneesh V,

Quoted 9 lines · In message <[email protected]> you wrote:

Add support for the SDRAM controller (EMIF).

V2:
* Changes for makefile changes
* Minor corrections in do_lpddr2_init()
* Minor corrections to read_idle interval calculation
* Sanity test of memory after doing the initialization
* Fixed warnings reported with with latest GCC compilers

Quoted 14 lines
---
 arch/arm/cpu/armv7/omap4/Makefile           |    3 +
 arch/arm/cpu/armv7/omap4/board.c            |    2 +-
 arch/arm/cpu/armv7/omap4/emif.c             |  298 +++++++++++
 arch/arm/cpu/armv7/omap4/sdram_elpida.c     |  118 +++++
 arch/arm/include/asm/arch-omap4/emif.h      |  719 +++++++++++++++++++++++++++
 arch/arm/include/asm/arch-omap4/omap4.h     |   11 +
 arch/arm/include/asm/arch-omap4/sys_proto.h |    1 +
 include/configs/omap4_sdp4430.h             |    5 -
 spl/board/ti/omap4.mk                       |    9 +-
 9 files changed, 1159 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/omap4/emif.c
 create mode 100644 arch/arm/cpu/armv7/omap4/sdram_elpida.c
 create mode 100644 arch/arm/include/asm/arch-omap4/emif.h

Note that this needs to be fixed anyway to use standard macros (get rid of modify_reg_32() etc.)

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Do you suppose the reason the ends of the `Intel Inside'  logo  don't
match up is that it was drawn on a Pentium?
author
#148 lore raw

PATCH v2 16/22 omap4: calculate EMIF register values

In reply to Aneesh V

Calculate EMIF register values based on AC timing parameters from the SDRAM datasheet and the DDR frequency rather than using the hard-coded values.

For a new board the user doen't have to go through the tedious process of calculating the register values. Instead, just provide the AC timings from the device data sheet as input and the driver will automatically calculate the register values.

---
V2:
* Changes for the make file changes

---
 arch/arm/cpu/armv7/omap-common/Makefile     |    1 +
 arch/arm/cpu/armv7/omap-common/utils.c      |   61 ++
 arch/arm/cpu/armv7/omap4/Makefile           |    1 -
 arch/arm/cpu/armv7/omap4/board.c            |    9 +-
 arch/arm/cpu/armv7/omap4/emif.c             |  861 ++++++++++++++++++++++++++-
 arch/arm/cpu/armv7/omap4/sdram_elpida.c     |  152 +++++-
 arch/arm/include/asm/arch-omap4/emif.h      |  304 ++++++++++-
 arch/arm/include/asm/arch-omap4/omap4.h     |   18 +-
 arch/arm/include/asm/arch-omap4/sys_proto.h |    1 +
 include/configs/omap4_sdp4430.h             |    5 +
 spl/board/ti/omap4.mk                       |    7 +-
 11 files changed, 1404 insertions(+), 16 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/omap-common/utils.c
arch/arm/cpu/armv7/omap-common/Makefile +1 -0
index dc01ee5..8f698f8 100644
@@ -28,6 +28,7 @@ LIB	= $(obj)libomap-common.o
 SOBJS	:= reset.o
 
 COBJS	:= timer.o
+COBJS	+= utils.o
 
 SRCS	:= $(SOBJS:.o=.S) $(COBJS:.o=.c)
 OBJS	:= $(addprefix $(obj),$(SOBJS) $(COBJS))
arch/arm/cpu/armv7/omap-common/utils.c new file +61 -0

61 lines not on this page · raw message

arch/arm/cpu/armv7/omap4/Makefile +0 -1
index d9714fe..0b525e1 100644
@@ -34,7 +34,6 @@ COBJS	+= clocks.o
 COBJS	+= emif.o
 COBJS	+= sdram_elpida.o
 
-
 SRCS	:= $(SOBJS:.o=.S) $(COBJS:.o=.c)
 OBJS	:= $(addprefix $(obj),$(COBJS) $(SOBJS))
 
arch/arm/cpu/armv7/omap4/board.c +5 -4
index 7add46b..a51d1bb 100644
@@ -32,6 +32,7 @@
 #include <asm/arch/cpu.h>
 #include <asm/arch/sys_proto.h>
 #include <asm/sizes.h>
+#include <asm/arch/emif.h>
 #include "omap4_mux_data.h"
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -148,13 +149,13 @@ u32 sdram_size(void)
 {
 	u32 section, i, total_size = 0, size, addr;
 	for (i = 0; i < 4; i++) {
-		section	= __raw_readl(DMM_LISA_MAP_BASE + i*4);
-		addr = section & DMM_LISA_MAP_SYS_ADDR_MASK;
+		section	= __raw_readl(OMAP44XX_DMM_LISA_MAP_BASE + i*4);
+		addr = section & OMAP44XX_SYS_ADDR_MASK;
 		/* See if the address is valid */
 		if ((addr >= OMAP44XX_DRAM_ADDR_SPACE_START) &&
 		    (addr < OMAP44XX_DRAM_ADDR_SPACE_END)) {
-			size	= ((section & DMM_LISA_MAP_SYS_SIZE_MASK) >>
-				    DMM_LISA_MAP_SYS_SIZE_SHIFT);
+			size	= ((section & OMAP44XX_SYS_SIZE_MASK) >>
+				   OMAP44XX_SYS_SIZE_SHIFT);
 			size	= 1 << size;
 			size	*= SZ_16M;
 			total_size += size;
arch/arm/cpu/armv7/omap4/emif.c +859 -2

905 lines not on this page · raw message

arch/arm/cpu/armv7/omap4/sdram_elpida.c +151 -1

173 lines not on this page · raw message

arch/arm/include/asm/arch-omap4/emif.h +303 -1

349 lines not on this page · raw message

arch/arm/include/asm/arch-omap4/omap4.h +12 -6
index a1c4883..fd8fb10 100644
@@ -86,12 +86,7 @@
 /* GPMC */
 #define OMAP44XX_GPMC_BASE	0x50000000
 
-/* DMM */
-#define OMAP44XX_DMM_BASE		0x4E000000
-#define DMM_LISA_MAP_BASE		(OMAP44XX_DMM_BASE + 0x40)
-#define DMM_LISA_MAP_SYS_SIZE_MASK	(7 << 20)
-#define DMM_LISA_MAP_SYS_SIZE_SHIFT	20
-#define DMM_LISA_MAP_SYS_ADDR_MASK	(0xFF << 24)
+
 /*
  * Hardware Register Details
  */
@@ -137,6 +132,17 @@ struct s32ktimer {
 /* Temporary SRAM stack used while low level init is done */
 #define LOW_LEVEL_SRAM_STACK	NON_SECURE_SRAM_END
 
+#define SRAM_SCRATCH_SPACE_ADDR		NON_SECURE_SRAM_START
+
+/*
+ * SRAM scratch space entries
+ */
+
+/* Boot parameter passed from SPL to U-Boot */
+#define OMAP4_SRAM_SCRATCH_EMIF_SIZE	SRAM_SCRATCH_SPACE_ADDR
+#define OMAP4_SRAM_SCRATCH_EMIF_T_NUM	(SRAM_SCRATCH_SPACE_ADDR + 0x8)
+#define OMAP4_SRAM_SCRATCH_EMIF_T_DEN	(SRAM_SCRATCH_SPACE_ADDR + 0xC)
+
 /* Silicon revisions */
 #define OMAP4430_SILICON_ID_INVALID	0
 #define OMAP4430_ES1_0	1
arch/arm/include/asm/arch-omap4/sys_proto.h +1 -0
index 3fce576..46064f1 100644
@@ -44,6 +44,7 @@ void bypass_dpll(u32 base);
 void freq_update_core(void);
 u32 get_sys_clk_freq(void);
 u32 omap4_ddr_clk(void);
+void cancel_out(u32 *num, u32 *den, u32 den_limit);
 void sdram_init(void);
 u32 omap4_revision(void);
 const char *omap4_rev_string(void);
include/configs/omap4_sdp4430.h +5 -0
index ae009d6..d5f98dc 100644
@@ -249,6 +249,11 @@
 /* Defines for Clock init */
 #define CONFIG_SYS_OMAP4_ABE_SYSCK
 
+/* Defines for SDRAM init */
+#ifndef CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS
+#define CONFIG_SYS_DEFAULT_LPDDR2_TIMINGS	1
+#endif
+
 /* Defines for SPL */
 #define CONFIG_SPL
 #define CONFIG_SYS_SPL_TEXT_BASE	0x40304350
spl/board/ti/omap4.mk +6 -1
index 85b40ca..a0e2142 100644
@@ -97,8 +97,13 @@ $(obj)spl-omap.c:
 	@rm -f $@
 	@ln -s $(TOPDIR)/spl/board/ti/spl-omap.c $@
 
+$(obj)utils.c:
+	@rm -f $@
+	@ln -s $(TOPDIR)/arch/arm/cpu/armv7/omap-common/utils.c $@
+
+
 SOBJS	+= reset.o
-COBJS	+= timer.o spl-omap.o
+COBJS	+= timer.o spl-omap.o utils.o
 
 # omap4
 $(obj)lowlevel_init.S:
Signature · 1 line
1.7.0.4
#149 lore raw

PATCH v2 16/22 omap4: calculate EMIF register values

Dear Aneesh V,

Quoted 8 lines · In message <[email protected]> you wrote:

Calculate EMIF register values based on AC timing parameters from the SDRAM datasheet and the DDR frequency rather than using the hard-coded values.

For a new board the user doen't have to go through the tedious process of calculating the register values. Instead, just provide the AC timings from the device data sheet as input and the driver will automatically calculate the register values.

Does it make sense to do this in the driver code? These parameters will never change, so why can we not rather perform the computation only once, at build time, and feed in the respective parameters to the driver?

Reasons why I am concerned about such an approach are code size and boot time. Both suffer ...

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Never underestimate the power of human stupidity  when  it  comes  to
using technology they don't understand.
#150 lore raw

PATCH v2 16/22 omap4: calculate EMIF register values

Quoted 12 lines · Wolfgang Denk

Dear Aneesh V,

Quoted 8 lines · In message <[email protected]> you wrote:

Calculate EMIF register values based on AC timing parameters from the SDRAM datasheet and the DDR frequency rather than using the hard-coded values.

For a new board the user doen't have to go through the tedious process of calculating the register values. Instead, just provide the AC timings from the device data sheet as input and the driver will automatically calculate the register values.

Quoted 4 lines

Does it make sense to do this in the driver code? These parameters will never change, so why can we not rather perform the computation only once, at build time, and feed in the respective parameters to the driver?

I agree, there should be no reason for doing this at runtime. I would think it possible to do with some C macros.

Signature · 2 lines
M?ns Rullg?rd
mans at mansr.com
author
#151 lore raw

PATCH v2 16/22 omap4: calculate EMIF register values

Hi Mans,

Quoted 14 lines · M?ns Rullg?rd
Quoted 12 lines · Wolfgang Denk

Dear Aneesh V,

Quoted 8 lines · In message<[email protected]> you wrote:

Calculate EMIF register values based on AC timing parameters from the SDRAM datasheet and the DDR frequency rather than using the hard-coded values.

For a new board the user doen't have to go through the tedious process of calculating the register values. Instead, just provide the AC timings from the device data sheet as input and the driver will automatically calculate the register values.

Quoted 8 lines
Quoted 4 lines

Does it make sense to do this in the driver code? These parameters will never change, so why can we not rather perform the computation only once, at build time, and feed in the respective parameters to the driver?

I agree, there should be no reason for doing this at runtime. I would think it possible to do with some C macros.

I had a C macro version earlier. But as I have mentioned in my reply to Wolfgang some of the inputs vary between different revisions of our silicon. I am doing a run-time identification of the revision and doing the settings accordingly.

Besides, the forest of MACROs was really ugly.

best regards,
Aneesh

author
#152 lore raw

PATCH v2 16/22 omap4: calculate EMIF register values

In reply to Wolfgang Denk

Hi Wolfgang,

Quoted 12 lines · Wolfgang Denk

Dear Aneesh V,

Quoted 8 lines · In message<[email protected]> you wrote:

Calculate EMIF register values based on AC timing parameters from the SDRAM datasheet and the DDR frequency rather than using the hard-coded values.

For a new board the user doen't have to go through the tedious process of calculating the register values. Instead, just provide the AC timings from the device data sheet as input and the driver will automatically calculate the register values.

Quoted 4 lines

Does it make sense to do this in the driver code? These parameters will never change, so why can we not rather perform the computation only once, at build time, and feed in the respective parameters to the driver?

Some of the parameters do change. For instance on one of the OMAP4 revisions the DDR runs at 200MHz, on another one at 380MHz and for the rest at 400MHz. Also, on ES1 we have 512 MB of memory where as on others we have 1GB. This driver is also doing discovery of SDRAM geometry, type, etc.

Quoted 4 lines

Reasons why I am concerned about such an approach are code size and boot time. Both suffer ...

I had the same concerns too. So, I have provided a CONFIG option - CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS - by which the user can provide the register values, so no computation will be done.

So, if somebody is concerned about the performance they can just compute the values using this driver and print them out by enabling the debug traces, fill it up in the structs provided for it and enable CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS. That should work.

Also, please note that I had measured the time taken for the entire SDRAM initialization and it was not at all significant(IIRC, it was less than 1ms).

best regards,
Aneesh

#153 lore raw

PATCH v2 16/22 omap4: calculate EMIF register values

Dear Aneesh V,

Quoted 4 lines · In message <[email protected]> you wrote:

I had the same concerns too. So, I have provided a CONFIG option - CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS - by which the user can provide the register values, so no computation will be done.

Ah, great. Sorry, I have missed this.

Quoted 4 lines

So, if somebody is concerned about the performance they can just compute the values using this driver and print them out by enabling the debug traces, fill it up in the structs provided for it and enable CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS. That should work.

Will this also comment out the respective code, so we don't waste the memory for it?

Quoted 3 lines

Also, please note that I had measured the time taken for the entire SDRAM initialization and it was not at all significant(IIRC, it was less than 1ms).

Thanks!

Best regards,

Wolfgang Denk

Signature · 6 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Mr. Cole's Axiom:
        The sum of the intelligence on the planet is a constant;
        the population is growing.
author
#154 lore raw

PATCH v2 16/22 omap4: calculate EMIF register values

Hi Wolfgang,

Quoted 10 lines · Wolfgang Denk

Dear Aneesh V,

Quoted 4 lines · In message<[email protected]> you wrote:

I had the same concerns too. So, I have provided a CONFIG option - CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS - by which the user can provide the register values, so no computation will be done.

Ah, great. Sorry, I have missed this.

Quoted 7 lines
Quoted 4 lines

So, if somebody is concerned about the performance they can just compute the values using this driver and print them out by enabling the debug traces, fill it up in the structs provided for it and enable CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS. That should work.

Will this also comment out the respective code, so we don't waste the memory for it?

In SPL yes, because I am using -ffunction-sections -fdata-sections along with --gc-sections, but not in U-Boot. I shall take care of this in the next revision.

BTW, I was thinking that I should enable -ffunction-sections -fdata-sections in OMAP U-Boot too. What do you think?

best regards,
Aneesh

author
#155 lore raw

PATCH v2 17/22 omap4: automatic sdram detection

In reply to Aneesh V

Identify SDRAM devices connected to EMIF automatically:
LPDDR2 devices have some Mode Registers that provide details about the device such as the type, density, bus width etc. EMIF has the capability to read these registers. If there are not devices connected to a given chip-select reading mode registers will return junk values. After reading as many such registers as possible and matching with expected ranges of values the driver can identify if there is a device connected to the respective CS. If we identify that a device is connected the values read give us complete details about the device.

This along with the base AC timings specified by JESD209-2 allows us to do a complete automatic initialization of SDRAM that works on all boards.

Please note that the default AC timings specified by JESD209-2 will be safe for all devices but not necessarily optimal. However, for the Elpida devices used on Panda and SDP the default timings are both safe and optimal.

---
 arch/arm/cpu/armv7/omap4/emif.c         |  177 +++++++++++++++++++++++++++++-
 arch/arm/cpu/armv7/omap4/sdram_elpida.c |    9 +-
 include/configs/omap4_sdp4430.h         |    1 +
 3 files changed, 176 insertions(+), 11 deletions(-)
arch/arm/cpu/armv7/omap4/emif.c +170 -5
index baa5ed6..b09aa8f 100644
@@ -166,7 +166,8 @@ static const struct lpddr2_min_tck min_tck_jedec = {
 	.tFAW = 8
 };
 
-static const struct lpddr2_ac_timings *jedec_ac_timings[MAX_NUM_SPEEDBINS] = {
+static const struct lpddr2_ac_timings const*
+			jedec_ac_timings[MAX_NUM_SPEEDBINS] = {
 	&timings_jedec_200_mhz,
 	&timings_jedec_333_mhz,
 	&timings_jedec_400_mhz
@@ -780,6 +781,146 @@ void emif_reset_phy(u32 base)
 	writel(iodft, &emif->emif_iodft_tlgc);
 }
 
+#ifdef CONFIG_SYS_AUTOMATIC_SDRAM_DETECTION
+static void display_sdram_details(u32 emif_nr, u32 cs,
+				  struct lpddr2_device_details *device)
+{
+	const char *mfg_str;
+	const char *type_str;
+	char density_str[10];
+	u32 density;
+
+	debug("EMIF%d CS%d\t", emif_nr, cs);
+
+	if (!device) {
+		debug("None\n");
+		return;
+	}
+
+	mfg_str = get_lpddr2_manufacturer(device->manufacturer);
+	type_str = get_lpddr2_type(device->type);
+
+	density = lpddr2_density_2_size_in_mbytes[device->density];
+	if ((density / 1024 * 1024) == density) {
+		density /= 1024;
+		sprintf(density_str, "%d GB", density);
+	} else
+		sprintf(density_str, "%d MB", density);
+	if (mfg_str && type_str)
+		debug("%s\t\t%s\t%s\n", mfg_str, type_str, density_str);
+}
+
+static u8 is_lpddr2_sdram_present(u32 base, u32 cs,
+				  struct lpddr2_device_details *lpddr2_device)
+{
+	u32 mr = 0, temp;
+
+	mr = get_mr(base, cs, LPDDR2_MR0);
+	if (mr > 0xFF) {
+		/* Mode register value bigger than 8 bit */
+		return 0;
+	}
+
+	temp = get_bit_field(mr, LPDDR2_MR0_DI_SHIFT, LPDDR2_MR0_DI_MASK);
+	if (temp) {
+		/* Not SDRAM */
+		return 0;
+	}
+	temp = get_bit_field(mr, LPDDR2_MR0_DNVI_SHIFT, LPDDR2_MR0_DNVI_MASK);
+
+	if (temp) {
+		/* DNV supported - But DNV is only supported for NVM */
+		return 0;
+	}
+
+	mr = get_mr(base, cs, LPDDR2_MR4);
+	if (mr > 0xFF) {
+		/* Mode register value bigger than 8 bit */
+		return 0;
+	}
+
+	mr = get_mr(base, cs, LPDDR2_MR5);
+	if (mr >= 0xFF) {
+		/* Mode register value bigger than 8 bit */
+		return 0;
+	}
+
+	if (!get_lpddr2_manufacturer(mr)) {
+		/* Manufacturer not identified */
+		return 0;
+	}
+	lpddr2_device->manufacturer = mr;
+
+	mr = get_mr(base, cs, LPDDR2_MR6);
+	if (mr >= 0xFF) {
+		/* Mode register value bigger than 8 bit */
+		return 0;
+	}
+
+	mr = get_mr(base, cs, LPDDR2_MR7);
+	if (mr >= 0xFF) {
+		/* Mode register value bigger than 8 bit */
+		return 0;
+	}
+
+	mr = get_mr(base, cs, LPDDR2_MR8);
+	if (mr >= 0xFF) {
+		/* Mode register value bigger than 8 bit */
+		return 0;
+	}
+
+	temp = get_bit_field(mr, MR8_TYPE_SHIFT, MR8_TYPE_MASK);
+	if (!get_lpddr2_type(temp)) {
+		/* Not SDRAM */
+		return 0;
+	}
+	lpddr2_device->type = temp;
+
+	temp = get_bit_field(mr, MR8_DENSITY_SHIFT, MR8_DENSITY_MASK);
+	if (temp > LPDDR2_DENSITY_32Gb) {
+		/* Density not supported */
+		return 0;
+	}
+	lpddr2_device->density = temp;
+
+	temp = get_bit_field(mr, MR8_IO_WIDTH_SHIFT, MR8_IO_WIDTH_MASK);
+	if (!get_lpddr2_io_width(temp)) {
+		/* IO width unsupported value */
+		return 0;
+	}
+	lpddr2_device->io_width = temp;
+
+	/*
+	 * If all the above tests pass we should
+	 * have a device on this chip-select
+	 */
+	return 1;
+}
+
+static struct lpddr2_device_details *get_lpddr2_details(u32 base, u8 cs,
+			struct lpddr2_device_details *lpddr2_dev_details)
+{
+	u32 phy;
+	struct emif_reg_struct *emif = (struct emif_reg_struct *)base;
+
+	if (!lpddr2_dev_details)
+		return NULL;
+
+	/* Do the minimum init for mode register accesses */
+	if (!running_from_sdram()) {
+		phy = get_ddr_phy_ctrl_1(get_sys_clk_freq() / 2, RL_BOOT);
+		writel(phy, &emif->emif_ddr_phy_ctrl_1);
+	}
+
+	if (!(is_lpddr2_sdram_present(base, cs, lpddr2_dev_details)))
+		return NULL;
+
+	display_sdram_details(emif_num(base), cs, lpddr2_dev_details);
+
+	return lpddr2_dev_details;
+}
+#endif /* CONFIG_SYS_AUTOMATIC_SDRAM_DETECTION */
+
 static void do_lpddr2_init(u32 base, u32 cs)
 {
 	u32 mr_addr;
@@ -879,9 +1020,7 @@ static void emif_update_timings(u32 base, const struct emif_regs *regs)
 
 static void do_sdram_init(u32 base)
 {
-	struct emif_device_details dev_details;
 	const struct emif_regs *regs;
-
 	u32 in_sdram, emif_nr;
 
 	in_sdram = running_from_sdram();
@@ -889,6 +1028,7 @@ static void do_sdram_init(u32 base)
 
 #ifdef CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS
 	const struct emif_regs *tmp_regs;
+
 	emif_get_reg_dump(&regs, &tmp_regs);
 	regs = (emif_nr == 1) ? regs : tmp_regs;
 #else
@@ -896,23 +1036,48 @@ static void do_sdram_init(u32 base)
 	 * The user has not provided the register values. We need to
 	 * calculate it based on the timings and the DDR frequency
 	 */
+	struct emif_device_details dev_details = { NULL, NULL };
+	struct emif_regs calculated_regs;
 
+#if !defined(CONFIG_SYS_AUTOMATIC_SDRAM_DETECTION) || \
+	!defined(CONFIG_SYS_DEFAULT_LPDDR2_TIMINGS)
+
+	/* We need some input about the devices from the user */
 	const struct emif_device_details *dev_details_user_provided;
 	const struct emif_device_details *tmp_details;
-	struct emif_regs calculated_regs;
 
-	/* We need some input about the devices from the user */
 	emif_get_device_details(&dev_details_user_provided, &tmp_details);
 	dev_details_user_provided = (emif_nr == 1) ? dev_details_user_provided
 						   : tmp_details;
 	if (!dev_details_user_provided)
 		return;
+#endif
 
+#ifdef CONFIG_SYS_AUTOMATIC_SDRAM_DETECTION
+	struct lpddr2_device_details cs0_dev_details, cs1_dev_details;
+
+	/* Automatically find the device details */
+	if (!in_sdram) {
+		dev_details.cs0_device_details =
+		    get_lpddr2_details(base, CS0, &cs0_dev_details);
+		dev_details.cs1_device_details =
+		    get_lpddr2_details(base, CS1, &cs1_dev_details);
+		/*
+		 * Reset the PHY - if there is nothing connected on any
+		 * of the chip selects(typically CS1) mode register reads
+		 * will mess up with the PHY state and subsequent
+		 * initialization won't work. PHY reset brings back PHY to
+		 * a good state.
+		 */
+		emif_reset_phy(base);
+	}
+#else
 	dev_details.cs0_device_details =
 			dev_details_user_provided->cs0_device_details;
 	dev_details.cs1_device_details =
 			dev_details_user_provided->cs1_device_details;
 
+#endif
 	/* Return if no devices on this EMIF */
 	if (!dev_details.cs0_device_details &&
 	    !dev_details.cs1_device_details) {
arch/arm/cpu/armv7/omap4/sdram_elpida.c +4 -5
index e7d2bd5..8dfe6f9 100644
@@ -86,10 +86,8 @@ const struct dmm_lisa_map_regs lisa_map_2G_x_2_x_2 = {
 	.dmm_lisa_map_3 = 0x80640300
 };
 
-void emif_get_reg_dump_sdp(const struct emif_regs **emif1_regs,
-			const struct emif_regs **emif2_regs)
-
-#else
+#elif !defined(CONFIG_SYS_AUTOMATIC_SDRAM_DETECTION) || \
+	!defined(CONFIG_SYS_DEFAULT_LPDDR2_TIMINGS)
 
 static const struct lpddr2_ac_timings timings_elpida_400_mhz = {
 	.max_freq	= 400000000,
@@ -245,7 +243,8 @@ static void emif_get_dmm_regs_sdp(const struct dmm_lisa_map_regs
 void emif_get_dmm_regs(const struct dmm_lisa_map_regs **dmm_lisa_regs)
 	__attribute__((weak, alias("emif_get_dmm_regs_sdp")));
 
-#else
+#elif !defined(CONFIG_SYS_AUTOMATIC_SDRAM_DETECTION) || \
+	!defined(CONFIG_SYS_DEFAULT_LPDDR2_TIMINGS)
 
 static void emif_get_device_details_sdp(
 			const struct emif_device_details **emif1_details,
include/configs/omap4_sdp4430.h +1 -0
index d5f98dc..13e7623 100644
@@ -251,6 +251,7 @@
 
 /* Defines for SDRAM init */
 #ifndef CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS
+#define CONFIG_SYS_AUTOMATIC_SDRAM_DETECTION	1
 #define CONFIG_SYS_DEFAULT_LPDDR2_TIMINGS	1
 #endif
 
Signature · 1 line
1.7.0.4
#156 lore raw

PATCH v2 17/22 omap4: automatic sdram detection

Dear Aneesh V,

Quoted 20 lines · In message <[email protected]> you wrote:

Identify SDRAM devices connected to EMIF automatically:
LPDDR2 devices have some Mode Registers that provide details about the device such as the type, density, bus width etc. EMIF has the capability to read these registers. If there are not devices connected to a given chip-select reading mode registers will return junk values. After reading as many such registers as possible and matching with expected ranges of values the driver can identify if there is a device connected to the respective CS. If we identify that a device is connected the values read give us complete details about the device.

This along with the base AC timings specified by JESD209-2 allows us to do a complete automatic initialization of SDRAM that works on all boards.

Please note that the default AC timings specified by JESD209-2 will be safe for all devices but not necessarily optimal. However, for the Elpida devices used on Panda and SDP the default timings are both safe and optimal.

Quoted 6 lines
---
 arch/arm/cpu/armv7/omap4/emif.c         |  177 +++++++++++++++++++++++++++++-
 arch/arm/cpu/armv7/omap4/sdram_elpida.c |    9 +-
 include/configs/omap4_sdp4430.h         |    1 +
 3 files changed, 176 insertions(+), 11 deletions(-)

How much of this is OMAP4 specific, and how much can be reused onother SoCs as well?

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is easier to write an incorrect program than understand a  correct
one.
author
#157 lore raw

PATCH v2 17/22 omap4: automatic sdram detection

Hi Wolfgang,

Quoted 30 lines · Wolfgang Denk

Dear Aneesh V,

Quoted 20 lines · In message<[email protected]> you wrote:

Identify SDRAM devices connected to EMIF automatically:
LPDDR2 devices have some Mode Registers that provide details about the device such as the type, density, bus width etc. EMIF has the capability to read these registers. If there are not devices connected to a given chip-select reading mode registers will return junk values. After reading as many such registers as possible and matching with expected ranges of values the driver can identify if there is a device connected to the respective CS. If we identify that a device is connected the values read give us complete details about the device.

This along with the base AC timings specified by JESD209-2 allows us to do a complete automatic initialization of SDRAM that works on all boards.

Please note that the default AC timings specified by JESD209-2 will be safe for all devices but not necessarily optimal. However, for the Elpida devices used on Panda and SDP the default timings are both safe and optimal.

Quoted 6 lines
---
  arch/arm/cpu/armv7/omap4/emif.c         |  177 +++++++++++++++++++++++++++++-
  arch/arm/cpu/armv7/omap4/sdram_elpida.c |    9 +-
  include/configs/omap4_sdp4430.h         |    1 +
  3 files changed, 176 insertions(+), 11 deletions(-)
Quoted 2 lines

How much of this is OMAP4 specific, and how much can be reused onother SoCs as well?

LPDDR2 provides registers. But OMAP4 EMIF controller provides the means to read them. In that sense it is closely tied to EMIF.

best regards,
Aneesh

author
#158 lore raw

PATCH v2 18/22 armv7: embed u-boot size within u-boot for use from SPL

In reply to Aneesh V

Embed the u-boot flash image size at a known offset from the start of u-boot so that SPL can use it while loading u-boot from a non-XIP media.

V2:
* Removed the linker script label '__flash_image_end' and its usage. Instead '_end' is used now

---
 arch/arm/cpu/armv7/start.S |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)
arch/arm/cpu/armv7/start.S +5 -1
index f92c6d9..f676d7d 100644
@@ -64,8 +64,12 @@ _pad:			.word 0x12345678 /* now 16*4=64 */
 
 .global _end_vect
 _end_vect:
+.global	_u_boot_size
+_u_boot_size:
+	.word	0xDEADBEEF
+	.word	_end - _start
 
-	.balignl 16,0xdeadbeef
+.balignl 16,0xdeadbeef
 /*************************************************************************
  *
  * Startup Code (reset vector)
Signature · 1 line
1.7.0.4
#159 lore raw

PATCH v2 18/22 armv7: embed u-boot size within u-boot for use from SPL

Dear Aneesh V,

Quoted 3 lines · In message <[email protected]> you wrote:

Embed the u-boot flash image size at a known offset from the start of u-boot so that SPL can use it while loading u-boot from a non-XIP media.

I don't think this is a good idea.

What you are doing here is defining an image format. Such an image format must be good enough not only for OMAP4 and for loading U-Boot as second stage, but for all other architectures and use cases as well.

We therefore should be very careful not to oversimplify things here. I suggest NOT to pot this information into the image itself, but rather to prepend it (for example, using the mkimage tool), so the actual payload image needs not to be modified.

Best regards,

Wolfgang Denk

Signature · 7 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Anyone who knows history, particularly the history of Europe, will, I
think, recognize that the domination of education or of government by
any one particular religious faith is never a happy  arrangement  for
the people.                                       - Eleanor Roosevelt
author
#160 lore raw

PATCH v2 18/22 armv7: embed u-boot size within u-boot for use from SPL

Hi Wolfgang,

Quoted 7 lines · Wolfgang Denk

Dear Aneesh V,

Quoted 3 lines · In message<[email protected]> you wrote:

Embed the u-boot flash image size at a known offset from the start of u-boot so that SPL can use it while loading u-boot from a non-XIP media.

Quoted 6 lines

I don't think this is a good idea.

What you are doing here is defining an image format. Such an image format must be good enough not only for OMAP4 and for loading U-Boot as second stage, but for all other architectures and use cases as well.

I am not defining and publishing a format for the external world. It's just an internal information much like any other info embedded in start.S such as _bss_end_ofs, _end_ofs etc. It's just that SPL, being an insider, can take advantage of it.

I feel creating a new mkimage target just for this will be an overkill. I will be happy loading the maximum image size always.

best regards,
Aneesh

#161 lore raw

PATCH v2 18/22 armv7: embed u-boot size within u-boot for use from SPL

Dear Aneesh V,

Quoted 7 lines · In message <[email protected]> you wrote:
Quoted 5 lines

What you are doing here is defining an image format. Such an image format must be good enough not only for OMAP4 and for loading U-Boot as second stage, but for all other architectures and use cases as well.

I am not defining and publishing a format for the external world. It's

In the essence this is what you are doing: you are defining an interface how the payload has to look like. Anything not meeting this "specification" or "image format" or "ABI" or whatever you call it will not be directly loadable by the SPL.

But I want to make sure that we can load arbitrary payloads as second stage, not only U-Boot images. Because we cannot guarantee that we can embed such information into other payloads we may want to load, we must prepend or append such information, but not embed it somewhere within the image itself.

Quoted 3 lines

just an internal information much like any other info embedded in start.S such as _bss_end_ofs, _end_ofs etc. It's just that SPL, being an insider, can take advantage of it.

This is not quite correct. SPL needs this information. We are defining an API here, and we should make sure it fits the use cases we can see now (and ideally is flexible enough so we can adjust/extend it for future use).

Quoted 1 line

I feel creating a new mkimage target just for this will be an overkill.

We don't have to create a new format. We can, for example, use the existing format with a prepended 64 byte header. The only thing that needs changes is that we now have to consider the header when loading the image, but the same problem will always exist when we accept that we cannot embed the information within the payload. We don't need any new code to implement this solution. We can easily create the images using "mkimage -T firmware -O u-boot".

Quoted 1 line

I will be happy loading the maximum image size always.

This makes no sense. What is "the maximum image size always"? 4 MB, so we can also load a Linux kernel as payload? 8 MB, so we can stil do this in a year from now?

Best regards,

Wolfgang Denk

Signature · 4 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A metaphor is like a simile.
author
#162 lore raw

PATCH v2 18/22 armv7: embed u-boot size within u-boot for use from SPL

Hi Wolfgang,

Quoted 9 lines · Wolfgang Denk

Dear Aneesh V,

Quoted 6 lines · In message<[email protected]> you wrote:
Quoted 5 lines

What you are doing here is defining an image format. Such an image format must be good enough not only for OMAP4 and for loading U-Boot as second stage, but for all other architectures and use cases as well.

Quoted 6 lines
Quoted 1 line

I am not defining and publishing a format for the external world. It's

In the essence this is what you are doing: you are defining an interface how the payload has to look like. Anything not meeting this "specification" or "image format" or "ABI" or whatever you call it will not be directly loadable by the SPL.

This is not exactly true. I had implemented a fall-back option albeit with a maximum size assumed for U-Boot.

Quoted 7 lines

But I want to make sure that we can load arbitrary payloads as second stage, not only U-Boot images. Because we cannot guarantee that we can embed such information into other payloads we may want to load, we must prepend or append such information, but not embed it somewhere within the image itself.

Quoted 8 lines
Quoted 3 lines

just an internal information much like any other info embedded in start.S such as _bss_end_ofs, _end_ofs etc. It's just that SPL, being an insider, can take advantage of it.

This is not quite correct. SPL needs this information. We are defining an API here, and we should make sure it fits the use cases we can see now (and ideally is flexible enough so we can adjust/extend it for future use).

Agree that mkimage approach works better for different types of payloads.

Quoted 10 lines
Quoted 2 lines

I feel creating a new mkimage target just for this will be an overkill.

We don't have to create a new format. We can, for example, use the existing format with a prepended 64 byte header. The only thing that needs changes is that we now have to consider the header when loading the image, but the same problem will always exist when we accept that we cannot embed the information within the payload. We don't need any new code to implement this solution. We can easily create the images using "mkimage -T firmware -O u-boot".

The existing target u-boot.img works for me. Just a couple of questions:

1. I see that size is at offset 0xC in this header. Is this a standard?
2. I see that the header is 64 bytes. Is that again a standard for mkimage.
3. Is it ok to add u-boot.img to the target "ALL"?
4. If not, is it ok to add it to "ALL" when CONFIG_SPL is defined? Something like this:

ifeq ($(CONFIG_SPL),y)
.PHONEY : SPL
-ALL += SPL
+ALL += SPL u-boot.img
endif

Is it ok to add support for kernel payload as a subsequent incremental step. That's, right now I intend to parse the mkimage header, find the size and load address and load the image and pass control to it, but *without* passing any parameters. Is that ok?

#163 lore raw

PATCH v2 18/22 armv7: embed u-boot size within u-boot for use from SPL

Dear Aneesh V,

Quoted 4 lines · In message <[email protected]> you wrote:

1. I see that size is at offset 0xC in this header. Is this a standard?
2. I see that the header is 64 bytes. Is that again a standard for mkimage.

Both are not really "standards" in the sense that any standardization group like ANSI or IEEE has approved this, but these are standard within U-Boot context. The header (struct image_header) is defined in "include/image.h"

Quoted 1 line

3. Is it ok to add u-boot.img to the target "ALL"?

No, because in the general case this is not needed, so it's just a waste of build time and disk space.

Review

Quoted 8 lines

4. If not, is it ok to add it to "ALL" when CONFIG_SPL is defined? Something like this:

  ifeq ($(CONFIG_SPL),y)
  .PHONEY : SPL
(quoted diff) +1 -1
-ALL += SPL
+ALL += SPL u-boot.img
  endif

IN principle this should be OK, but please pay attention not to break out-of-tree builds (You have to prefext target names with "$(obj)").

Quoted 4 lines

Is it ok to add support for kernel payload as a subsequent incremental step. That's, right now I intend to parse the mkimage header, find the size and load address and load the image and pass control to it, but *without* passing any parameters. Is that ok?

That's perfectly fine.

Best regards,

Wolfgang Denk

Signature · 4 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Due to lack of disk space, this fortune database has been discontinued.
#164 lore raw

PATCH v2 18/22 armv7: embed u-boot size within u-boot for use from SPL

In reply to Aneesh V
Quoted 17 lines · On Sun, 15 May 2011 20:51:36 +0530 Aneesh V <[email protected]> wrote:

Embed the u-boot flash image size at a known offset from the start of u-boot so that SPL can use it while loading u-boot from a non-XIP media.

V2:
* Removed the linker script label '__flash_image_end' and its usage. Instead '_end' is used now

---
 arch/arm/cpu/armv7/start.S |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)
arch/arm/cpu/armv7/start.S +0 -0
index f92c6d9..f676d7d 100644

arch/arm/cpu/armv7/start.S _pad: .word 0x12345678 /* now 16*4=64 */ · line 70

Quoted 7 lines
arch/arm/cpu/armv7/start.S +4 -0
@@ -64,8 +64,12 @@ _pad:			.word 0x12345678 /* now 16*4=64 */
 
 .global _end_vect
 _end_vect:
+.global	_u_boot_size
+_u_boot_size:
+	.word	0xDEADBEEF
+	.word	_end - _start

0xdeadbeef does not seem like a good magic value to identify this header format -- especially since it looks like that may have been the value present in the older images that don't have this header (depending on whether the .balignl needed to pad).

-Scott

author
#165 lore raw

PATCH v2 18/22 armv7: embed u-boot size within u-boot for use from SPL

Hi Scott,

Quoted 21 lines · Scott Wood
Quoted 18 lines · On Sun, 15 May 2011 20:51:36 +0530 Aneesh V<[email protected]> wrote:

Embed the u-boot flash image size at a known offset from the start of u-boot so that SPL can use it while loading u-boot from a non-XIP media.

V2:
* Removed the linker script label '__flash_image_end' and its usage. Instead '_end' is used now

---
  arch/arm/cpu/armv7/start.S |    6 +++++-
  1 files changed, 5 insertions(+), 1 deletions(-)
arch/arm/cpu/armv7/start.S +0 -0
index f92c6d9..f676d7d 100644
@@ -64,8 +64,12 @@ _pad:			.word 0x12345678 /* now 16*4=64 */
 
Quoted 11 lines

arch/arm/cpu/armv7/start.S _pad: .word 0x12345678 /* now 16*4=64 */ · line 70

Quoted 6 lines
arch/arm/cpu/armv7/start.S +4 -0
  .global _end_vect
  _end_vect:
+.global	_u_boot_size
+_u_boot_size:
+	.word	0xDEADBEEF
+	.word	_end - _start

0xdeadbeef does not seem like a good magic value to identify this header format -- especially since it looks like that may have been the value present in the older images that don't have this header (depending on whether the .balignl needed to pad).

Thanks for pointing this out. I will change it to something different.

best regards,
Aneesh

author
#166 lore raw

PATCH v2 19/22 omap: add MMC support to SPL

In reply to Aneesh V

---
V2:
* Changes for make file changes

---
 arch/arm/cpu/armv7/start.S         |    1 +
 arch/arm/include/asm/omap_common.h |    4 +
 include/configs/omap4_sdp4430.h    |    7 ++-
 spl/board/ti/omap4.mk              |   35 +++++++++++
 spl/board/ti/spl-omap.c            |  112 +++++++++++++++++++++++++++++++++++-
 5 files changed, 156 insertions(+), 3 deletions(-)
arch/arm/cpu/armv7/start.S +1 -0
index f676d7d..351276a 100644
@@ -64,6 +64,7 @@ _pad:			.word 0x12345678 /* now 16*4=64 */
 
 .global _end_vect
 _end_vect:
+/* This label should be at the same location for SPL and U-Boot */
 .global	_u_boot_size
 _u_boot_size:
 	.word	0xDEADBEEF
arch/arm/include/asm/omap_common.h +4 -0
index 10fc9c8..efd3b3c 100644
@@ -55,4 +55,8 @@ u32 omap_boot_device(void);
 u32 omap_boot_mode(void);
 void preloader_console_init(void);
 
+/* symbols from start.S */
+extern u32 _u_boot_size;
+extern u32 _start;
+
 #endif /* _OMAP_COMMON_H_ */
include/configs/omap4_sdp4430.h +5 -2
index 13e7623..0b67345 100644
@@ -261,7 +261,10 @@
 #define CONFIG_SYS_SPL_MAX_SIZE		0x7800	/* 30 K */
 #define CONFIG_SYS_SPL_STACK		LOW_LEVEL_SRAM_STACK
 
-#define CONFIG_SYS_SPL_BSS_START_ADDR	0x80000000
-#define CONFIG_SYS_SPL_BSS_MAX_SIZE	0x80000		/* 512 KB */
+#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_SPL_BSS_START_ADDR		0x80000000
+#define CONFIG_SYS_SPL_BSS_MAX_SIZE		0x80000		/* 512 KB */
 
 #endif /* __CONFIG_H */
spl/board/ti/omap4.mk +35 -0
index a0e2142..ecf605e 100644
@@ -72,6 +72,41 @@ $(obj)ctype.c:
 COBJS	+= serial.o ns16550.o string.o vsprintf.o console.o stdio.o
 COBJS	+= ctype.o eabi_compat.o div64.o
 
+# mmc
+$(obj)mmc.c:
+	@rm -f $@
+	@ln -s $(TOPDIR)/drivers/mmc/mmc.c $@
+
+$(obj)omap_hsmmc.c:
+	@rm -f $@
+	@ln -s $(TOPDIR)/drivers/mmc/omap_hsmmc.c $@
+
+$(obj)omap24xx_i2c.c: $(obj)omap24xx_i2c.h
+	@rm -f $@
+	@ln -s $(TOPDIR)/drivers/i2c/omap24xx_i2c.c $@
+
+$(obj)omap24xx_i2c.h:
+	@rm -f $@
+	@ln -s $(TOPDIR)/drivers/i2c/omap24xx_i2c.h $@
+
+$(obj)time.c:
+	@rm -f $@
+	@ln -s $(TOPDIR)/lib/time.c $@
+
+$(obj)part.c:
+	@rm -f $@
+	@ln -s $(TOPDIR)/disk/part.c $@
+
+$(obj)part_dos.c: $(obj)part_dos.h
+	@rm -f $@
+	@ln -s $(TOPDIR)/disk/part_dos.c $@
+
+$(obj)part_dos.h:
+	@rm -f $@
+	@ln -s $(TOPDIR)/disk/part_dos.h $@
+
+COBJS	+= omap_hsmmc.o omap24xx_i2c.o mmc.o time.o part.o part_dos.o
+
 # armv7
 $(obj)start.S:
 	@rm -f $@
spl/board/ti/spl-omap.c +111 -1

136 lines not on this page · raw message

Signature · 1 line
1.7.0.4
author
#167 lore raw

PATCH v2 20/22 omap: spl: add FAT support over MMC

In reply to Aneesh V

---
V2:
* Changes for make file changes

---
 include/configs/omap4_sdp4430.h |    1 +
 spl/board/ti/omap4.mk           |    7 +++++++
 spl/board/ti/spl-omap.c         |   22 ++++++++++++++++++++++
 3 files changed, 30 insertions(+), 0 deletions(-)
include/configs/omap4_sdp4430.h +1 -0
index 0b67345..cc64671 100644
@@ -263,6 +263,7 @@
 
 #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_SYS_SPL_BSS_START_ADDR		0x80000000
 #define CONFIG_SYS_SPL_BSS_MAX_SIZE		0x80000		/* 512 KB */
spl/board/ti/omap4.mk +7 -0
index ecf605e..e66a532 100644
@@ -107,6 +107,13 @@ $(obj)part_dos.h:
 
 COBJS	+= omap_hsmmc.o omap24xx_i2c.o mmc.o time.o part.o part_dos.o
 
+# fat
+$(obj)fat.c:
+	@rm -f $@
+	@ln -s $(TOPDIR)/fs/fat/fat.c $@
+
+COBJS	+=  fat.o
+
 # armv7
 $(obj)start.S:
 	@rm -f $@
spl/board/ti/spl-omap.c +22 -0
index 2174c55..81ca0d3 100644
@@ -29,6 +29,7 @@
 #include <asm/u-boot.h>
 #include <asm/arch/sys_proto.h>
 #include <mmc.h>
+#include <fat.h>
 #include <timestamp_autogenerated.h>
 #include <version_autogenerated.h>
 #include <asm/omap_common.h>
@@ -104,6 +105,25 @@ end:
 	}
 }
 
+static void mmc_load_uboot_fat(struct mmc *mmc)
+{
+	s32 err;
+
+	err = fat_register_device(&mmc->block_dev,
+				CONFIG_SYS_MMC_SD_FAT_BOOT_PARTITION);
+	if (err) {
+		printf("spl: fat register err - %d\n", err);
+		hang();
+	}
+
+	err = file_fat_read("u-boot.bin", (u8 *)CONFIG_SYS_TEXT_BASE, 0);
+
+	if (err <= 0) {
+		printf("spl: error reading u-boot.bin - %d\n", err);
+		hang();
+	}
+}
+
 static void mmc_load_uboot(u32 mmc_dev)
 {
 	struct mmc *mmc;
@@ -127,6 +147,8 @@ static void mmc_load_uboot(u32 mmc_dev)
 	boot_mode = omap_boot_mode();
 	if (boot_mode == MMCSD_MODE_RAW)
 		mmc_load_uboot_raw(mmc, mmc_dev);
+	else if (boot_mode == MMCSD_MODE_FAT)
+		mmc_load_uboot_fat(mmc);
 	else {
 		puts("spl: wrong MMC boot mode\n");
 		hang();
Signature · 1 line
1.7.0.4
#168 lore raw

PATCH v2 20/22 omap: spl: add FAT support over MMC

Dear Aneesh V,

Quoted 9 lines · In message <[email protected]> you wrote:

---
V2:
* Changes for make file changes

---
 include/configs/omap4_sdp4430.h |    1 +
 spl/board/ti/omap4.mk           |    7 +++++++
 spl/board/ti/spl-omap.c         |   22 ++++++++++++++++++++++
 3 files changed, 30 insertions(+), 0 deletions(-)

...

spl/board/ti/spl-omap.c end: · line 119

Quoted 1 line
spl/board/ti/spl-omap.c +1 -0
+	err = file_fat_read("u-boot.bin", (u8 *)CONFIG_SYS_TEXT_BASE, 0);

Please do not hard code the file name here. Keep the code flexible
and allow for other possibilities, too. At the very least, make this compile-time selectable.

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A quarrel is quickly settled when deserted by one party; there is  no
battle unless there be two.                                  - Seneca
author
#169 lore raw

PATCH v2 21/22 omap4: add spl support for OMAP4 Panda

In reply to Aneesh V

---
V2:
* Changed CONFIG_SYS_SPL_TEXT_BASE to 0x40304350 for Panda This is required for EMU devices
* Changes due to make file changes

---
 arch/arm/cpu/armv7/omap4/emif.c        |    5 +++--
 arch/arm/include/asm/arch-omap4/emif.h |   10 +++++-----
 include/configs/omap4_panda.h          |   24 ++++++++++++++++++++++++
 spl/board/ti/panda/Makefile            |   32 ++++++++++++++++++++++++++++++++
 4 files changed, 64 insertions(+), 7 deletions(-)
 create mode 100644 spl/board/ti/panda/Makefile
arch/arm/cpu/armv7/omap4/emif.c +3 -2
index b09aa8f..699a545 100644
@@ -1178,9 +1178,9 @@ static void dmm_init(u32 base)
 #ifdef CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS
 	emif_get_dmm_regs(&lisa_map_regs);
 #else
-	u32 emif1_size, emif2_size, mapped_size, section_map;
+	u32 emif1_size, emif2_size, mapped_size, section_map = 0;
 	u32 section_cnt, sys_addr;
-	struct dmm_lisa_map_regs lis_map_regs_calculated;
+	struct dmm_lisa_map_regs lis_map_regs_calculated = {0};
 
 	mapped_size = 0;
 	section_cnt = 3;
@@ -1253,6 +1253,7 @@ static void dmm_init(u32 base)
 		lis_map_regs_calculated.dmm_lisa_map_2 = section_map;
 		lis_map_regs_calculated.dmm_lisa_map_1 = 0;
 	}
+
 	/* TRAP for invalid TILER mappings in section 0 */
 	lis_map_regs_calculated.dmm_lisa_map_0 = DMM_LISA_MAP_0_INVAL_ADDR_TRAP;
 
arch/arm/include/asm/arch-omap4/emif.h +5 -5
index 8cc3230..b95e545 100644
@@ -520,11 +520,11 @@
 
 /* Trap for invalid TILER PAT entries */
 #define DMM_LISA_MAP_0_INVAL_ADDR_TRAP		(\
-		(0  << OMAP44XX_SDRC_ADDR_SHIFT) |\
-		(DMM_SDRC_MAP_EMIF1_ONLY << OMAP44XX_SDRC_MAP_SHIFT)|\
-		(DMM_SDRC_ADDR_SPC_INVALID << OMAP44XX_SDRC_ADDRSPC_SHIFT)|\
-		(DMM_SDRC_INTL_NONE << OMAP44XX_SDRC_INTL_SHIFT)|\
-		(0xFF << OMAP44XX_SYS_ADDR_SHIFT))
+	(0  << OMAP44XX_SDRC_ADDR_SHIFT) |\
+	(DMM_SDRC_MAP_EMIF1_ONLY << OMAP44XX_SDRC_MAP_SHIFT)|\
+	(DMM_SDRC_ADDR_SPC_INVALID << OMAP44XX_SDRC_ADDRSPC_SHIFT)|\
+	(DMM_SDRC_INTL_NONE << OMAP44XX_SDRC_INTL_SHIFT)|\
+	(0xFF << OMAP44XX_SYS_ADDR_SHIFT))
 
 
 /* Reg mapping structure */
include/configs/omap4_panda.h +24 -0
index 9acd340..e28b916 100644
@@ -116,7 +116,9 @@
 
 /* USB device configuration */
 #define CONFIG_USB_DEVICE		1
+#ifndef CONFIG_PRELOADER
 #define CONFIG_USB_TTY			1
+#endif
 #define CONFIG_SYS_CONSOLE_IS_IN_ENV	1
 
 /* Flash */
@@ -238,4 +240,26 @@
 #define CONFIG_SYS_PL310_BASE	0x48242000
 #endif
 
+/* Defines for Clock init */
+#define CONFIG_SYS_OMAP4_ABE_SYSCK
+
+/* Defines for SDRAM init */
+#ifndef CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS
+#define CONFIG_SYS_AUTOMATIC_SDRAM_DETECTION	1
+#define CONFIG_SYS_DEFAULT_LPDDR2_TIMINGS	1
+#endif
+
+/* Defines for SPL */
+#define CONFIG_SPL
+#define CONFIG_SYS_SPL_TEXT_BASE	0x40304350
+#define CONFIG_SYS_SPL_MAX_SIZE		0x7800	/* 30 K */
+#define CONFIG_SYS_SPL_STACK		LOW_LEVEL_SRAM_STACK
+
+#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_SYS_SPL_BSS_START_ADDR	0x80000000
+#define CONFIG_SYS_SPL_BSS_MAX_SIZE		0x80000		/* 512 KB */
+
 #endif /* __CONFIG_H */
spl/board/ti/panda/Makefile new file +32 -0
new file mode 100644
index 0000000..81bf51c
@@ -0,0 +1,32 @@
+#
+# (C) Copyright 2006-2007
+# Stefan Roese, DENX Software Engineering, sr at denx.de.
+#
+# (C) Copyright 2008
+# Guennadi Liakhovetki, DENX Software Engineering, <[email protected]>
+#
+# (C) Copyright 2010
+# Texas Instruments, <www.ti.com>
+# Aneesh V <[email protected]>
+#
+# 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 $(SRCTREE)/spl/board/$(VENDOR)/omap4.mk
+include $(SRCTREE)/spl/board/$(VENDOR)/rules-omap.mk
Signature · 1 line
1.7.0.4
#170 lore raw

PATCH v2 21/22 omap4: add spl support for OMAP4 Panda

Dear Aneesh V,

Quoted 19 lines · In message <[email protected]> you wrote:

---
V2:
* Changed CONFIG_SYS_SPL_TEXT_BASE to 0x40304350 for Panda This is required for EMU devices
* Changes due to make file changes

---
 arch/arm/cpu/armv7/omap4/emif.c        |    5 +++--
 arch/arm/include/asm/arch-omap4/emif.h |   10 +++++-----
 include/configs/omap4_panda.h          |   24 ++++++++++++++++++++++++
 spl/board/ti/panda/Makefile            |   32 ++++++++++++++++++++++++++++++++
 4 files changed, 64 insertions(+), 7 deletions(-)
 create mode 100644 spl/board/ti/panda/Makefile
arch/arm/cpu/armv7/omap4/emif.c +0 -0
index b09aa8f..699a545 100644

arch/arm/cpu/armv7/omap4/emif.c static void dmm_init(u32 base) · line 1183

Quoted 8 lines
arch/arm/cpu/armv7/omap4/emif.c +2 -2
@@ -1178,9 +1178,9 @@ static void dmm_init(u32 base)
 #ifdef CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS
 	emif_get_dmm_regs(&lisa_map_regs);
 #else
-	u32 emif1_size, emif2_size, mapped_size, section_map;
+	u32 emif1_size, emif2_size, mapped_size, section_map = 0;
 	u32 section_cnt, sys_addr;
-	struct dmm_lisa_map_regs lis_map_regs_calculated;
+	struct dmm_lisa_map_regs lis_map_regs_calculated = {0};

This iseems to be an unrelated change. Please split into separate patch.

arch/arm/cpu/armv7/omap4/emif.c static void dmm_init(u32 base) · line 1256

Quoted 7 lines
arch/arm/cpu/armv7/omap4/emif.c +1 -0
 	mapped_size = 0;
 	section_cnt = 3;
@@ -1253,6 +1253,7 @@ static void dmm_init(u32 base)
 		lis_map_regs_calculated.dmm_lisa_map_2 = section_map;
 		lis_map_regs_calculated.dmm_lisa_map_1 = 0;
 	}
+

Ditto.

Quoted 11 lines
arch/arm/cpu/armv7/omap4/emif.c +0 -0
 	/* TRAP for invalid TILER mappings in section 0 */
 	lis_map_regs_calculated.dmm_lisa_map_0 = DMM_LISA_MAP_0_INVAL_ADDR_TRAP;
 
arch/arm/include/asm/arch-omap4/emif.h +0 -0
index 8cc3230..b95e545 100644
@@ -520,11 +520,11 @@
 
 /* Trap for invalid TILER PAT entries */
 #define DMM_LISA_MAP_0_INVAL_ADDR_TRAP		(\

arch/arm/include/asm/arch-omap4/emif.h line 527

Quoted 10 lines
arch/arm/include/asm/arch-omap4/emif.h +5 -5
-		(0  << OMAP44XX_SDRC_ADDR_SHIFT) |\
-		(DMM_SDRC_MAP_EMIF1_ONLY << OMAP44XX_SDRC_MAP_SHIFT)|\
-		(DMM_SDRC_ADDR_SPC_INVALID << OMAP44XX_SDRC_ADDRSPC_SHIFT)|\
-		(DMM_SDRC_INTL_NONE << OMAP44XX_SDRC_INTL_SHIFT)|\
-		(0xFF << OMAP44XX_SYS_ADDR_SHIFT))
+	(0  << OMAP44XX_SDRC_ADDR_SHIFT) |\
+	(DMM_SDRC_MAP_EMIF1_ONLY << OMAP44XX_SDRC_MAP_SHIFT)|\
+	(DMM_SDRC_ADDR_SPC_INVALID << OMAP44XX_SDRC_ADDRSPC_SHIFT)|\
+	(DMM_SDRC_INTL_NONE << OMAP44XX_SDRC_INTL_SHIFT)|\
+	(0xFF << OMAP44XX_SYS_ADDR_SHIFT))

Ditto.

...

Quoted 2 lines
arch/arm/include/asm/arch-omap4/emif.h +1 -0
+++ b/spl/board/ti/panda/Makefile
@@ -0,0 +1,32 @@

...

arch/arm/include/asm/arch-omap4/emif.h

Quoted 2 lines
arch/arm/include/asm/arch-omap4/emif.h +2 -0
+include $(SRCTREE)/spl/board/$(VENDOR)/omap4.mk
+include $(SRCTREE)/spl/board/$(VENDOR)/rules-omap.mk

NAK, see previous messages.

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If a train station is a place where a train stops,
                                           then what's a workstation?
author
#171 lore raw

PATCH v2 22/22 omap: spl: add more debug traces

In reply to Aneesh V

In SPL console is enabled very early where as in U-Boot it's not. So, SPL can have traces in early init code while U-Boot can not have it in the same shared code.

Adding a debug print macro that will be defined in SPL but compiled out in U-Boot.

Also add some useful debug traces throughout SPL

---
 arch/arm/cpu/armv7/omap4/clocks.c |   10 ++++++++--
 arch/arm/cpu/armv7/omap4/emif.c   |   35 +++++++++++++++++++++++++++--------
 arch/arm/include/asm/utils.h      |    6 ++++++
 spl/board/ti/spl-omap.c           |   13 ++++++++++---
 4 files changed, 51 insertions(+), 13 deletions(-)
arch/arm/cpu/armv7/omap4/clocks.c +8 -2
index c405b5c..720e60f 100644
@@ -379,7 +379,7 @@ u32 omap4_ddr_clk(void)
 
 	core_dpll_params = get_core_dpll_params();
 
-	debug("sys_clk %d\n ", sys_clk_khz * 1000);
+	spl_debug("sys_clk %d\n ", sys_clk_khz * 1000);
 
 	/* Find Core DPLL locked frequency first */
 	ddr_clk = sys_clk_khz * 2 * core_dpll_params->m /
@@ -391,7 +391,7 @@ u32 omap4_ddr_clk(void)
 	ddr_clk = ddr_clk / 4 / core_dpll_params->m2;
 
 	ddr_clk *= 1000;	/* convert to Hz */
-	debug("ddr_clk %d\n ", ddr_clk);
+	spl_debug("ddr_clk %d\n ", ddr_clk);
 
 	return ddr_clk;
 }
@@ -400,6 +400,7 @@ static void setup_dplls(void)
 {
 	u32 sysclk_ind, temp;
 	const struct dpll_params *params;
+	spl_debug("setup_dplls\n");
 
 	sysclk_ind = get_sys_clk_index();
 
@@ -416,10 +417,12 @@ static void setup_dplls(void)
 	    (CLKSEL_L3_CORE_DIV_2 << CLKSEL_L3_SHIFT) |
 	    (CLKSEL_L4_L3_DIV_2 << CLKSEL_L4_SHIFT);
 	writel(temp, CM_CLKSEL_CORE);
+	spl_debug("Core DPLL configured\n");
 
 	/* lock PER dpll */
 	do_setup_dpll(CM_CLKMODE_DPLL_PER,
 			&per_dpll_params_1536mhz[sysclk_ind], DPLL_LOCK);
+	spl_debug("PER DPLL locked\n");
 
 	/* MPU dpll */
 	if (omap4_revision() == OMAP4430_ES1_0)
@@ -427,6 +430,7 @@ static void setup_dplls(void)
 	else
 		params = &mpu_dpll_params_1ghz[sysclk_ind];
 	do_setup_dpll(CM_CLKMODE_DPLL_MPU, params, DPLL_LOCK);
+	spl_debug("MPU DPLL locked\n");
 }
 
 static void setup_non_essential_dplls(void)
@@ -551,6 +555,7 @@ static void scale_vcores(void)
 
 static void enable_clock_domain(u32 clkctrl_reg, u32 enable_mode)
 {
+	spl_debug("Enable clock domain - 0x%08x\n", clkctrl_reg);
 	modify_reg_32(clkctrl_reg, CD_CLKCTRL_CLKTRCTRL_SHIFT,
 		      CD_CLKCTRL_CLKTRCTRL_MASK, enable_mode);
 }
@@ -570,6 +575,7 @@ static inline void wait_for_clk_enable(u32 clkctrl_addr)
 static void enable_clock_module(u32 clkctrl_addr, u32 enable_mode,
 				u32 wait_for_enable)
 {
+	spl_debug("Enable clock module - 0x%08x\n", clkctrl_addr);
 	modify_reg_32(clkctrl_addr, MODULE_CLKCTRL_MODULEMODE_SHIFT,
 			MODULE_CLKCTRL_MODULEMODE_MASK, enable_mode);
 	if (wait_for_enable)
arch/arm/cpu/armv7/omap4/emif.c +27 -8
index 699a545..fcb6d47 100644
@@ -34,7 +34,7 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-#define print_timing_reg(reg) debug(#reg" - 0x%08x\n", (reg))
+#define print_timing_reg(reg) spl_debug(#reg" - 0x%08x\n", (reg))
 
 static u32 *const T_num = (u32 *)OMAP4_SRAM_SCRATCH_EMIF_T_NUM;
 static u32 *const T_den = (u32 *)OMAP4_SRAM_SCRATCH_EMIF_T_DEN;
@@ -237,7 +237,7 @@ s8 addressing_table_index(u8 type, u8 density, u8 width)
 	else
 		index = density;
 
-	debug("emif: addressing table index %d\n", index);
+	spl_debug("emif: addressing table index %d\n", index);
 
 	return index;
 }
@@ -272,7 +272,7 @@ static const struct lpddr2_ac_timings *get_timings_table(const struct
 			timings = device_timings[i];
 		}
 	}
-	debug("emif: timings table: %d\n", freq_nearest);
+	spl_debug("emif: timings table: %d\n", freq_nearest);
 	return timings;
 }
 
@@ -637,7 +637,7 @@ static inline u32 get_mr(u32 base, u32 cs, u32 mr_addr)
 		mr = readl(&emif->emif_lpddr2_mode_reg_data_es2);
 	else
 		mr = readl(&emif->emif_lpddr2_mode_reg_data);
-	debug("get_mr: EMIF%d cs %d mr %08x val 0x%x\n", emif_num(base),
+	spl_debug("get_mr: EMIF%d cs %d mr %08x val 0x%x\n", emif_num(base),
 	      cs, mr_addr, mr);
 	return mr;
 }
@@ -790,10 +790,10 @@ static void display_sdram_details(u32 emif_nr, u32 cs,
 	char density_str[10];
 	u32 density;
 
-	debug("EMIF%d CS%d\t", emif_nr, cs);
+	spl_debug("EMIF%d CS%d\t", emif_nr, cs);
 
 	if (!device) {
-		debug("None\n");
+		spl_debug("None\n");
 		return;
 	}
 
@@ -807,7 +807,7 @@ static void display_sdram_details(u32 emif_nr, u32 cs,
 	} else
 		sprintf(density_str, "%d MB", density);
 	if (mfg_str && type_str)
-		debug("%s\t\t%s\t%s\n", mfg_str, type_str, density_str);
+		spl_debug("%s\t\t%s\t%s\n", mfg_str, type_str, density_str);
 }
 
 static u8 is_lpddr2_sdram_present(u32 base, u32 cs,
@@ -948,6 +948,8 @@ static void lpddr2_init(u32 base, const struct emif_regs *regs)
 {
 	struct emif_reg_struct *emif = (struct emif_reg_struct *)base;
 
+	spl_debug(">>lpddr2_init() %x\n", base);
+
 	/* Not NVM */
 	modify_reg_32(&emif->emif_lpddr2_nvm_config,
 		OMAP44XX_REG_CS1NVMEN_SHIFT, OMAP44XX_REG_CS1NVMEN_MASK, 0);
@@ -978,6 +980,7 @@ static void lpddr2_init(u32 base, const struct emif_regs *regs)
 		OMAP44XX_REG_INITREF_DIS_SHIFT,
 		OMAP44XX_REG_INITREF_DIS_MASK, 0);
 
+	spl_debug("<<lpddr2_init()\n");
 }
 
 static void emif_update_timings(u32 base, const struct emif_regs *regs)
@@ -1023,6 +1026,8 @@ static void do_sdram_init(u32 base)
 	const struct emif_regs *regs;
 	u32 in_sdram, emif_nr;
 
+	spl_debug(">>do_sdram_init() %x\n", base);
+
 	in_sdram = running_from_sdram();
 	emif_nr = (base == OMAP44XX_EMIF1) ? 1 : 2;
 
@@ -1115,6 +1120,8 @@ static void do_sdram_init(u32 base)
 
 	/* Write to the shadow registers */
 	emif_update_timings(base, regs);
+
+	spl_debug("<<do_sdram_init() %x\n", base);
 }
 
 void sdram_init_pads(void)
@@ -1187,7 +1194,7 @@ static void dmm_init(u32 base)
 	sys_addr = CONFIG_SYS_SDRAM_BASE;
 	emif1_size = emif_sizes[0];
 	emif2_size = emif_sizes[1];
-	debug("emif1_size 0x%x emif2_size 0x%x\n", emif1_size, emif2_size);
+	spl_debug("emif1_size 0x%x emif2_size 0x%x\n", emif1_size, emif2_size);
 
 	if (!emif1_size && !emif2_size)
 		return;
@@ -1296,11 +1303,14 @@ static void dmm_init(u32 base)
  */
 void sdram_init(void)
 {
+	spl_debug(">>sdram_init()\n");
+
 	if (omap4_hw_init_context() == OMAP_INIT_CONTEXT_UBOOT_LOADED_BY_SPL)
 		return;
 
 	u32 in_sdram;
 	in_sdram = running_from_sdram();
+	spl_debug("in_sdram = %d\n", in_sdram);
 
 	if (!in_sdram) {
 		sdram_init_pads();
@@ -1318,4 +1328,13 @@ void sdram_init(void)
 
 	/* for the shadow registers to take effect */
 	freq_update_core();
+
+	/* Do some basic testing */
+	writel(0xDEADBEEF, CONFIG_SYS_SDRAM_BASE);
+	if (readl(CONFIG_SYS_SDRAM_BASE) == 0xDEADBEEF)
+		spl_debug("SDRAM Init success!\n");
+	else
+		printf("SDRAM Init failed!!\n");
+
+	spl_debug("<<sdram_init()\n");
 }
arch/arm/include/asm/utils.h +6 -0
index d581539..3e847c1 100644
@@ -25,6 +25,12 @@
 #ifndef	_UTILS_H_
 #define	_UTILS_H_
 
+#if defined(DEBUG) && defined(CONFIG_PRELOADER)
+#define spl_debug(fmt, args...)	printf(fmt, ##args)
+#else
+#define spl_debug(fmt, args...)
+#endif
+
 /* extract a bit field from a bit vector */
 #define get_bit_field(nr, start, mask)\
 	(((nr) & (mask)) >> (start))
spl/board/ti/spl-omap.c +10 -3
index 81ca0d3..6db3675 100644
@@ -27,6 +27,7 @@
  */
 #include <common.h>
 #include <asm/u-boot.h>
+#include <asm/utils.h>
 #include <asm/arch/sys_proto.h>
 #include <mmc.h>
 #include <fat.h>
@@ -45,7 +46,9 @@ typedef void (*u_boot_entry_t)(void)__attribute__ ((noreturn));
 
 void board_init_f(ulong dummy)
 {
+	debug(">>board_init_f()\n");
 	relocate_code(CONFIG_SYS_SPL_STACK, &gdata, CONFIG_SYS_SPL_TEXT_BASE);
+	debug("<<board_init_f()\n");
 }
 
 inline void hang(void)
@@ -145,11 +148,13 @@ static void mmc_load_uboot(u32 mmc_dev)
 	}
 
 	boot_mode = omap_boot_mode();
-	if (boot_mode == MMCSD_MODE_RAW)
+	if (boot_mode == MMCSD_MODE_RAW) {
+		spl_debug("boot mode - RAW\n");
 		mmc_load_uboot_raw(mmc, mmc_dev);
-	else if (boot_mode == MMCSD_MODE_FAT)
+	} else if (boot_mode == MMCSD_MODE_FAT) {
+		spl_debug("boot mode - FAT\n");
 		mmc_load_uboot_fat(mmc);
-	else {
+	} else {
 		puts("spl: wrong MMC boot mode\n");
 		hang();
 	}
@@ -159,6 +164,7 @@ void board_init_r(gd_t *id, ulong dummy)
 {
 	u32 boot_device;
 	u_boot_entry_t u_boot_entry = (u_boot_entry_t) CONFIG_SYS_TEXT_BASE;
+	spl_debug(">>spl:board_init_r()\n");
 
 	timer_init();
 	i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
@@ -166,6 +172,7 @@ void board_init_r(gd_t *id, ulong dummy)
 	switch (boot_device) {
 	case BOOT_DEVICE_MMC1:
 	case BOOT_DEVICE_MMC2:
+		spl_debug("boot device - MMC2\n");
 		mmc_load_uboot(boot_device - BOOT_DEVICE_MMC1);
 		break;
 	default:
Signature · 1 line
1.7.0.4
#172 lore raw

PATCH v2 22/22 omap: spl: add more debug traces

Dear Aneesh V,

Quoted 2 lines · In message <[email protected]> you wrote:

In SPL console is enabled very early where as in U-Boot it's not. So, SPL can have traces in early init code

Console should _always_ be enabled as early as possible,

Quoted 4 lines

while U-Boot can not have it in the same shared code.

Adding a debug print macro that will be defined in SPL but compiled out in U-Boot.

Can we not rather change the code so both configurations behave the same?

arch/arm/cpu/armv7/omap4/clocks.c u32 omap4_ddr_clk(void) · line 382

Quoted 8 lines
arch/arm/cpu/armv7/omap4/clocks.c +1 -1
@@ -379,7 +379,7 @@ u32 omap4_ddr_clk(void)
 
 	core_dpll_params = get_core_dpll_params();
 
-	debug("sys_clk %d\n ", sys_clk_khz * 1000);
+	spl_debug("sys_clk %d\n ", sys_clk_khz * 1000);

Do we really need a new macro name? Can this not be the same debug() macro, just generating different code (if really needed) when building the SPL code?

arch/arm/cpu/armv7/omap4/clocks.c void sdram_init(void) · line 1339

Quoted 13 lines
arch/arm/cpu/armv7/omap4/clocks.c +9 -0
@@ -1318,4 +1328,13 @@ void sdram_init(void)
 
 	/* for the shadow registers to take effect */
 	freq_update_core();
+
+	/* Do some basic testing */
+	writel(0xDEADBEEF, CONFIG_SYS_SDRAM_BASE);
+	if (readl(CONFIG_SYS_SDRAM_BASE) == 0xDEADBEEF)
+		spl_debug("SDRAM Init success!\n");
+	else
+		printf("SDRAM Init failed!!\n");
+
+	spl_debug("<<sdram_init()\n");

This is beyond the scope of "adding debug traces". it must be split into separate patch.

Also, please do not mess witrhout need with the RAM content - at the very least, restore the previous values.

But then - I wonder why this is needed@all. Are you not using get_ram_size()? Maybe you should fix your code to using it!

arch/arm/include/asm/utils.h line 32

Quoted 13 lines
arch/arm/include/asm/utils.h +5 -0
index d581539..3e847c1 100644
@@ -25,6 +25,12 @@
 #ifndef	_UTILS_H_
 #define	_UTILS_H_
 
+#if defined(DEBUG) && defined(CONFIG_PRELOADER)
+#define spl_debug(fmt, args...)	printf(fmt, ##args)
+#else
+#define spl_debug(fmt, args...)
+#endif

NAK. This is neither the right place for such a definition, nor do I want to see this addressed like that.

I recommend to unify the code, so both SPL and non-SPL configurations can use teh same early console behaviour.

arch/arm/include/asm/utils.h

Quoted 5 lines
arch/arm/include/asm/utils.h +2 -0
 void board_init_f(ulong dummy)
 {
+	debug(">>board_init_f()\n");
 	relocate_code(CONFIG_SYS_SPL_STACK, &gdata, CONFIG_SYS_SPL_TEXT_BASE);
+	debug("<<board_init_f()\n");

This is overkill, isn't it?

arch/arm/include/asm/utils.h void board_init_r(gd_t *id, ulong dummy) · line 176

Quoted 6 lines
arch/arm/include/asm/utils.h +1 -0
@@ -166,6 +172,7 @@ void board_init_r(gd_t *id, ulong dummy)
 	switch (boot_device) {
 	case BOOT_DEVICE_MMC1:
 	case BOOT_DEVICE_MMC2:
+		spl_debug("boot device - MMC2\n");
 		mmc_load_uboot(boot_device - BOOT_DEVICE_MMC1);

This is wrong in the BOOT_DEVICE_MMC1 case.

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Marriage is like a cage; one sees the birds outside desperate to get
in, and those inside desperate to get out."               - Montaigne
author
#173 lore raw

PATCH v2 22/22 omap: spl: add more debug traces

Dear Wolfgang,

I just realized that I had not responded to this message.

Quoted 7 lines · Wolfgang Denk

Dear Aneesh V,

Quoted 2 lines · In message<[email protected]> you wrote:

In SPL console is enabled very early where as in U-Boot it's not. So, SPL can have traces in early init code

Console should _always_ be enabled as early as possible,

Unfortunately this is not the case with U-Boot today. Console initialization happens in board_init_f(). Before board_init_f() typically a lot of(in fact most of) low level initialization happens through the lowlevel_init() function called from start.S and the initial part of init_sequence()

Quoted 8 lines
Quoted 5 lines

while U-Boot can not have it in the same shared code.

Adding a debug print macro that will be defined in SPL but compiled out in U-Boot.

Can we not rather change the code so both configurations behave the same?

In SPL I had more flexibility, so I do a simplified init of console right at the beginning of lowlevel_init(), so I can use debug prints in lowlevel_init(). Some part of our lowlevel_init() that is executed in SPL path may also be executed by U-Boot if it runs from NOR flash, but in this case console wouldn't be ready. That's why I made the macro.

Quoted 5 lines
Quoted 5 lines
arch/arm/cpu/armv7/omap4/clocks.c +0 -0
@@ -379,7 +379,7 @@ u32 omap4_ddr_clk(void)
 
Quoted 8 lines

arch/arm/cpu/armv7/omap4/clocks.c u32 omap4_ddr_clk(void) · line 382

Quoted 4 lines
arch/arm/cpu/armv7/omap4/clocks.c +1 -1
  	core_dpll_params = get_core_dpll_params();
 
-	debug("sys_clk %d\n ", sys_clk_khz * 1000);
+	spl_debug("sys_clk %d\n ", sys_clk_khz * 1000);

Do we really need a new macro name? Can this not be the same debug() macro, just generating different code (if really needed) when building the SPL code?

No. That wouldn't serve the purpose. I need two macros to distinguish between the two cases.
1. 'debug()' - can be used in all places at which console is guaranteed to be initialized whether executed as part of U-Boot or SPL.
2. 'spl_debug()' to be used at places where console is initialized for SPL but not for U-Boot (eg. lowlevel_init()) - so emit no code for U-Boot.

Quoted 17 lines
Quoted 4 lines
arch/arm/cpu/armv7/omap4/clocks.c +0 -0
@@ -1318,4 +1328,13 @@ void sdram_init(void)
 
  	/* for the shadow registers to take effect */

arch/arm/cpu/armv7/omap4/clocks.c void sdram_init(void) · line 1339

Quoted 10 lines
arch/arm/cpu/armv7/omap4/clocks.c +9 -0
  	freq_update_core();
+
+	/* Do some basic testing */
+	writel(0xDEADBEEF, CONFIG_SYS_SDRAM_BASE);
+	if (readl(CONFIG_SYS_SDRAM_BASE) == 0xDEADBEEF)
+		spl_debug("SDRAM Init success!\n");
+	else
+		printf("SDRAM Init failed!!\n");
+
+	spl_debug("<<sdram_init()\n");

This is beyond the scope of "adding debug traces". it must be split into separate patch.

will do.

Quoted 3 lines

Also, please do not mess witrhout need with the RAM content - at the very least, restore the previous values.

Will do.

Quoted 3 lines

But then - I wonder why this is needed at all. Are you not using get_ram_size()? Maybe you should fix your code to using it!

It may make sense for us to do this as a memory test. For discovering the amount of memory installed we are using a technique based on reading of LPDDR2 mode registers.

The above was intended as a simple sanity testing.

Quoted 18 lines
Quoted 6 lines
arch/arm/include/asm/utils.h +0 -0
index d581539..3e847c1 100644

arch/arm/include/asm/utils.h line 32

Quoted 8 lines
arch/arm/include/asm/utils.h +5 -0
@@ -25,6 +25,12 @@
  #ifndef	_UTILS_H_
  #define	_UTILS_H_
 
+#if defined(DEBUG)&&  defined(CONFIG_PRELOADER)
+#define spl_debug(fmt, args...)	printf(fmt, ##args)
+#else
+#define spl_debug(fmt, args...)
+#endif

NAK. This is neither the right place for such a definition, nor do I want to see this addressed like that.

Quoted 2 lines

I recommend to unify the code, so both SPL and non-SPL configurations can use teh same early console behaviour.

I always thought this is a serious issue with U-Boot. I gave it a quick shot like below:

---

(quoted diff) +0 -0

b/arch/arm/cpu/armv7/omap4/board.c
index fcd29a7..56902e3 100644

arch/arm/cpu/armv7/omap4/board.c +1 -0
@@ -41,6 +41,7 @@ DECLARE_GLOBAL_DATA_PTR;
   */
  void s_init(void)
  {
+	printf("Hello World!!\n");
  	watchdog_init();
  }
 
(quoted diff) +0 -0

b/arch/arm/cpu/armv7/omap4/lowlevel_init.S
index 026dfa4..42264b2 100644

arch/arm/cpu/armv7/omap4/lowlevel_init.S +1 -12
@@ -31,17 +31,6 @@
  .globl lowlevel_init
  lowlevel_init:
  	/*
-	 * Setup a temporary stack
-	 */
-	ldr	sp, =LOW_LEVEL_SRAM_STACK
-
-	/*
-	 * Save the old lr(passed in ip) and the current lr to stack
-	 */
-	push	{ip, lr}
-
-	/*
  	 * go setup pll, mux, memory
  	 */
-	bl	s_init
-	pop	{ip, pc}
+	b	s_init
arch/arm/cpu/armv7/start.S +4 -3
index d91ae12..4a9251f 100644
@@ -307,10 +307,11 @@ cpu_init_crit:
  	 * basic memory. Go here to bump up clock rate and handle
  	 * wake up conditions.
  	 */
-	mov	ip, lr			@ persevere link reg across call
+	ldr	sp, =CONFIG_SYS_INIT_SP_ADDR
+	push	{lr}
+	bl	early_console_init
  	bl	lowlevel_init		@ go setup pll,mux,memory
-	mov	lr, ip			@ restore link
-	mov	pc, lr			@ back to my caller
+	pop	{pc}
  /*
   *************************************************************************
   *
arch/arm/lib/board.c +7 -3
index 1a784a1..0c696c2 100644
@@ -248,9 +248,6 @@ init_fnc_t *init_sequence[] = {
  	get_clocks,
  #endif
  	env_init,		/* initialize environment */
-	init_baudrate,		/* initialze baudrate settings */
-	serial_init,		/* serial communications setup */
-	console_init_f,		/* stage 1 init of console */
  	display_banner,		/* say that we are here */
  #if defined(CONFIG_DISPLAY_CPUINFO)
  	print_cpuinfo,		/* display cpu info (and speed) */
@@ -268,6 +265,13 @@ init_fnc_t *init_sequence[] = {
  	NULL,
  };
 
+void early_console_init(void)
+{
+	init_baudrate();	/* initialze baudrate settings */
+	serial_init();		/* serial communications setup */
+	console_init_f();	/* stage 1 init of console */
+}
+
  void board_init_f (ulong bootflag)
  {
  	bd_t *bd;

---

But this didn't work. It crashes at the first printf(). The reason is init_baudrate() needs global data and global data is initialized in board_init_f(). Further, we can not move global data initialization earlier because for global data we reuse low level stack used by lowlevel_init().

	gd = (gd_t *) ((CONFIG_SYS_INIT_SP_ADDR) & ~0x07);

So, we have an egg-and-chicken problem unless we find different spaces for low-level stack and global data(that should not be a problem for our board, but I am not sure of other boards).

Also, perhaps this needs to be done for all CPUs/archs.

IMHO, this will need a major overhaul and is not in the scope of my current activity. Please suggest how to go about this.

Do you think re-naming spl_debug to omap_spl_debug() and putting it in an OMAP header will help?:-) I am not sure if everybody has the same situation as we have(that is, U-Boot and SPL sharing low-level init code and console being initialized in one case while not in the other)

best regards,
Aneesh

author
#174 lore raw

PATCH v2 22/22 omap: spl: add more debug traces

Dear Wolfgang, Heiko,

Quoted 1 line · Aneesh V

Dear Wolfgang,

[snip ...]

Quoted 7 lines

But this didn't work. It crashes at the first printf(). The reason is init_baudrate() needs global data and global data is initialized in board_init_f(). Further, we can not move global data initialization earlier because for global data we reuse low level stack used by lowlevel_init().

gd = (gd_t *) ((CONFIG_SYS_INIT_SP_ADDR) & ~0x07);

On second thoughts I realize that the stack in internal RAM is still in use in board_init_f(). So, how does this work at all? The global data and the stack seems to be overlapping!

Please note the register dump after the above instruction. Note that R8(gd) and R13(sp) are very close.

N _  R0          0  R8   4030DF80  SP> 12345678
Z Z  R1         0A  R9   12345678  -04 80E80078
C C  R2   4030DED4  R10  40304350  FP> D78772CA
V _  R3       5555  R11  0002FE40  +04 4049A39E
I I  R4          0  R12  80E80068  +08 F5A73CF4
F F  R5         10  R13  4030DF78  +0C 7B317D39
T _  R6   12345678  R14  80E80078  +10 ED3CFCF0
J _  R7   12345678  PC   80E80880  +14 FEECEC6A
svc  SPSR        0  CPSR 600001D3  +18 6DB22EB2

Am I missing something?

best regards,
Aneesh

#175 lore raw

PATCH v2 22/22 omap: spl: add more debug traces

In reply to Aneesh V

Dear Aneesh V,

Quoted 8 lines · In message <[email protected]> you wrote:
Quoted 2 lines

Console should _always_ be enabled as early as possible,

Unfortunately this is not the case with U-Boot today. Console initialization happens in board_init_f(). Before board_init_f() typically a lot of(in fact most of) low level initialization happens through the lowlevel_init() function called from start.S and the initial part of init_sequence()

As the name LOWLEVEL_init() suggests, this is suppoed to contain always only the bare minimum of initialization that is necessary to get the CPU running. All more complex initializations should be delayed and only be run when we have a proper environment, including debug output on the console.

Quoted 8 lines
Quoted 2 lines

Can we not rather change the code so both configurations behave the same?

In SPL I had more flexibility, so I do a simplified init of console right at the beginning of lowlevel_init(), so I can use debug prints in lowlevel_init(). Some part of our lowlevel_init() that is executed in SPL path may also be executed by U-Boot if it runs from NOR flash, but in this case console wouldn't be ready. That's why I made the macro.

I do not understand this. How can you have more flexibility in the more restricted environment?

We definitely should unify this.

Quoted 7 lines

No. That wouldn't serve the purpose. I need two macros to distinguish between the two cases.
1. 'debug()' - can be used in all places at which console is guaranteed to be initialized whether executed as part of U-Boot or SPL.
2. 'spl_debug()' to be used at places where console is initialized for SPL but not for U-Boot (eg. lowlevel_init()) - so emit no code for U-Boot.

You see - this distinction is becoming a mess. Let's get rid of this and use common code for both cases.

Best regards,

Wolfgang Denk

Signature · 6 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Very ugly or very beautiful women should be flattered on their
understanding, and mediocre ones on their beauty.
                                       -- Philip Earl of Chesterfield
author
#176 lore raw

PATCH v2 22/22 omap: spl: add more debug traces

Dear Wolfgang,

Quoted 2 lines · Wolfgang Denk

Dear Aneesh V,

[snip ..]

Quoted 10 lines
Quoted 7 lines

No. That wouldn't serve the purpose. I need two macros to distinguish between the two cases.
1. 'debug()' - can be used in all places at which console is guaranteed to be initialized whether executed as part of U-Boot or SPL.
2. 'spl_debug()' to be used at places where console is initialized for SPL but not for U-Boot (eg. lowlevel_init()) - so emit no code for U-Boot.

You see - this distinction is becoming a mess. Let's get rid of this and use common code for both cases.

I replaced spl_debug() with debug() now. I moved sdram_init() out of lowlevel_init() for u-boot so that console is available by the time sdram_init() runs.

However, clock init needs to remain in lowlevel_init() and I still feel that some debug traces from this module will be a good debugging tool for SPL, so I retained the traces and added something like this in arch/arm/cpu/armv7/omap4/clocks.c:

/*
* printing to console doesn't work unless
* this code is executed from SPL
*/
#ifndef CONFIG_PRELOADER
#define printf(fmt, args...)
#define puts(s)
#endif

Is that fine?

best regards,
Aneesh

author
#177 lore raw

v3 cover U-Boot MMC SPL for OMAP4

In reply to Aneesh V

This series adds mmc SPL support for OMAP4. This is essentially an up-streaming effort for TI's x-loader for OMAP4 using the SPL framework

This work partly draws upon previous work done for x-loader by:
Santosh Shilimkar <[email protected]> Rajendra Nayak <[email protected]>
and many others

This series depends on the following series for the new SPL framework:
http://marc.info/?l=u-boot&m=131056990001719&w=2

Features supported:
* Clock init - DPLL locking, clock domains/modules enabling
* SDRAM/DMM initialization
* Mux initialization
* MMC raw read support
* MMC FAT read support

Improvments over x-loader:
* Code completely revamped
* DPLL programming that works for all SYS_CLK frequencies
* Automatic SDRAM identification and initialization
* Board dependent parts(especially mux) deferred to u-boot. So, same SPL will work for Panda and SDP and most likely on any other board that comes along
* Flexible about the payload. Any image with a mkimage header can be loaded.
* The core SPL logic is generic and available for OMAP3/4. So, OMAP3 platforms can easily extend this work to add SPL support for the respective boards.

V2:
* Some fixes in SDRAM init, clock init
* Use of pre-calculated M & N values for DPLL locking instead run-time calculation
* Change in make files to allow reuse of common rules between boards
* Console initialization moved further earlier in the boot allowing traces from even clock initialization code
* Reuse utility macros from a previous series

V3:
* Moved to the new SPL framework
* struct based register access for clock init
* Squashed together related patches as per Wolfgang's suggestions
* Re-organization of code in sdram init for better readability
* SPL loading the payload using mkimage header
* Avoided using custom bit-field accessor macros
* Several other minor changes(documented in respective patches)

Aneesh V (11):
omap4: utility function to identify the context of hw init
omap4: cleanup pin mux data
omap4: add OMAP4430 revision check
omap4: add clock support
omap4: add sdram init support
omap4: calculate EMIF register values
omap4: automatic sdram detection
armv7: start.S: fixes and enhancements for SPL
omap: add basic SPL support
Correct ih_os for u-boot.img
omap: add MMC and FAT support to SPL

John Rigby (1):
mkimage: Add OMAP boot image support

 Makefile                                           |    2 +-
 arch/arm/cpu/armv7/Makefile                        |    7 +-
 arch/arm/cpu/armv7/cpu.c                           |    7 +
 arch/arm/cpu/armv7/omap-common/Makefile            |    5 +
 arch/arm/cpu/armv7/omap-common/spl.c               |  272 ++++
 arch/arm/cpu/armv7/omap-common/u-boot-spl.lds      |   62 +
 arch/arm/cpu/armv7/omap-common/utils.c             |   57 +
 arch/arm/cpu/armv7/omap4/Makefile                  |    6 +
 arch/arm/cpu/armv7/omap4/board.c                   |  161 +++-
 arch/arm/cpu/armv7/omap4/clocks.c                  |  842 +++++++++++++
 .../panda => arch/arm/cpu/armv7/omap4}/config.mk   |   25 +-
 arch/arm/cpu/armv7/omap4/emif.c                    | 1305 ++++++++++++++++++++
 arch/arm/cpu/armv7/omap4/lowlevel_init.S           |   31 +
 arch/arm/cpu/armv7/omap4/omap4_mux_data.h          |   76 ++
 arch/arm/cpu/armv7/omap4/sdram_elpida.c            |  282 +++++
 arch/arm/cpu/armv7/start.S                         |   51 +-
 arch/arm/cpu/armv7/u-boot.lds                      |    2 +
 arch/arm/include/asm/arch-omap4/clocks.h           |  664 ++++++++++
 arch/arm/include/asm/arch-omap4/emif.h             | 1034 ++++++++++++++++
 arch/arm/include/asm/arch-omap4/omap4.h            |   52 +-
 arch/arm/include/asm/arch-omap4/sys_proto.h        |   72 ++-
 arch/arm/include/asm/armv7.h                       |    5 +
 arch/arm/include/asm/omap_common.h                 |   56 +
 board/ti/panda/Makefile                            |    2 +
 board/ti/panda/panda.c                             |   25 +-
 board/ti/{sdp4430/sdp.h => panda/panda_mux_data.h} |   76 +-
 board/ti/sdp4430/Makefile                          |    2 +
 board/ti/sdp4430/config.mk                         |   31 -
 board/ti/sdp4430/sdp.c                             |   25 +-
 .../{panda/panda.h => sdp4430/sdp4430_mux_data.h}  |  128 +--
 common/image.c                                     |    9 +-
 include/configs/omap4_panda.h                      |   37 +
 include/configs/omap4_sdp4430.h                    |   37 +
 include/image.h                                    |    1 +
 spl/Makefile                                       |    6 +
 tools/Makefile                                     |    2 +
 tools/mkimage.c                                    |    2 +
 tools/mkimage.h                                    |    1 +
 tools/omap/clocks_get_m_n.c                        |  197 +++
 tools/omapimage.c                                  |  224 ++++
 tools/omapimage.h                                  |   50 +
 41 files changed, 5668 insertions(+), 263 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/omap-common/spl.c
 create mode 100644 arch/arm/cpu/armv7/omap-common/u-boot-spl.lds
 create mode 100644 arch/arm/cpu/armv7/omap-common/utils.c
 create mode 100644 arch/arm/cpu/armv7/omap4/clocks.c
 rename {board/ti/panda => arch/arm/cpu/armv7/omap4}/config.mk (64%)
 create mode 100644 arch/arm/cpu/armv7/omap4/emif.c
 create mode 100644 arch/arm/cpu/armv7/omap4/omap4_mux_data.h
 create mode 100644 arch/arm/cpu/armv7/omap4/sdram_elpida.c
 create mode 100644 arch/arm/include/asm/arch-omap4/clocks.h
 create mode 100644 arch/arm/include/asm/arch-omap4/emif.h
 create mode 100644 arch/arm/include/asm/omap_common.h
 rename board/ti/{sdp4430/sdp.h => panda/panda_mux_data.h} (76%)
 delete mode 100644 board/ti/sdp4430/config.mk
 rename board/ti/{panda/panda.h => sdp4430/sdp4430_mux_data.h} (67%)
 create mode 100644 tools/omap/clocks_get_m_n.c
 create mode 100644 tools/omapimage.c
 create mode 100644 tools/omapimage.h