U-Boot MMC SPL for OMAP4
Subsystems (3)
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%)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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
Bedia
PATCH 1/22 mkimage: Add OMAP boot image support
Aneesh,
Quoted 10 lines · Aneesh
From: John Rigby <[email protected]>
Signed-off-by 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 100644tools/omapimage.ccreate mode 100644tools/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
PATCH 1/22 mkimage: Add OMAP boot image support
Quoted 18 lines · Vaibhav
Aneesh,
Quoted 10 lines · Aneesh
From: John Rigby <[email protected]>
Signed-off-by 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 | ?229Quoted 4 lines
?+++++++++++++++++++++++++++++++++++++++++++++++++++++ ?tools/omapimage.h | ? 50 ++++++++++++ 7 files changed, 286 insertions(+), 0 deletions(-) ?create mode 100644
tools/omapimage.c?create mode 100644tools/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
PATCH 1/22 mkimage: Add OMAP boot image support
In reply to BediaHi Vaibhav,
Quoted 18 lines · Vaibhav
Aneesh,
Quoted 10 lines · Aneesh
From: John Rigby<[email protected]>
Signed-off-by 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 | 229Quoted 4 lines
+++++++++++++++++++++++++++++++++++++++++++++++++++++
tools/omapimage.h| 50 ++++++++++++ 7 files changed, 286
insertions(+), 0 deletions(-) create mode 100644tools/omapimage.ccreate mode 100644tools/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
Bedia
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/4IMHO, 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]
Bedia
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/4IMHO, 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
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/4IMHO, 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
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
@@ -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
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
@@ -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
@@ -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
@@ -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
PATCH 4/22 armv7: start.S: provide a hook for saving boot params
In reply to Aneesh VProvide 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
@@ -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
@@ -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
Bedia
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.Signed-off-by Aneesh V <[email protected]>---
This is an essential feature when there no x-loader in the picture. Thanks for posting a patch for this :)
Regards,
Vaibhav
PATCH 5/22 omap4: save parameters passed by ROM code to SPL
In reply to Aneesh VSave 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
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
@@ -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
@@ -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
PATCH 6/22 arm: new labels in the linker script file
Hi Aneesh,
Quoted 56 lines · Aneesh V
_bss_start_ofsis used instart.Sto 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
Signed-off-by Aneesh V <[email protected]>---
?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@@ -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-_startarch/arm/cpu/armv7/start.S +0
-0@@ -172,7 +176,7 @@ stack_setup:? ? ? ?beq ? ?
clear_bss? ? ? ? ? ? ? /* skip relocation */ ?#endif
? ? ? ?mov ? ? r1, r6 ? ? ? ? ? ? ? ? ?/* r1 <- scratch forcopy_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@@ -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
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
_endas end of image and has been applied to arm branch.
Quoted 8 lines
[U-Boot] [PATCH 1/2 v2] rename
_endto__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.htmlYou can use the newly added symbol
_end_ofsto replace your__flash_image_endhere.
Thanks for the pointer. I will do that in v2.
best regards,
Aneesh
PATCH 7/22 Add generic spl infrastructure
In reply to Aneesh VDefine 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
@@ -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
@@ -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
PATCH 8/22 armv7: start.S: add SPL support
In reply to Aneesh VChanges 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
@@ -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
PATCH 9/22 omap: add spl support
In reply to Aneesh VAdd 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
@@ -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
PATCH 10/22 omap4: add spl support for OMAP4 SDP
In reply to Aneesh VAdapted 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
@@ -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
@@ -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
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
@@ -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
@@ -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
@@ -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
@@ -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
PATCH 12/22 omap4: utility function to identify the context of hw init
In reply to Aneesh VThe 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
@@ -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; + asmvolatile ("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
@@ -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
PATCH 13/22 omap4: separate mux settings into essential and non essential parts
In reply to Aneesh VDo 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
@@ -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
@@ -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
@@ -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
@@ -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
PATCH 14/22 omap4: correct mux data for sdp4430
In reply to Aneesh Vsync 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
@@ -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
@@ -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
PATCH 15/22 omap4: add clock support
In reply to Aneesh VAdd 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
PATCH 16/22 omap4: add sdram init support
In reply to Aneesh VAdd 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
PATCH 17/22 omap4: calculate EMIF register values
In reply to Aneesh VCalculate 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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 */ + asmvolatile ("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 */ + asmvolatile ("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
@@ -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
@@ -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
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.
Signed-off-by Aneesh V <[email protected]>---
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 functionemif.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
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.
Signed-off-by Aneesh V<[email protected]>---
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 functionemif.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
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.
Signed-off-by Aneesh V<[email protected]>---
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 functionemif.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
PATCH 17/22 omap4: calculate EMIF register values
In reply to John RigbyQuoted 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
Signed-off-by Aneesh V<[email protected]>---
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 functionemif.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
PATCH 18/22 omap4: automatic sdram detection
In reply to Aneesh VIdentify 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
@@ -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 (®s, &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
@@ -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_regsvoid 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
@@ -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
PATCH 19/22 armv7: embed u-boot size within u-boot for use from SPL
In reply to Aneesh VEmbed 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
@@ -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
@@ -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
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
@@ -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
@@ -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
@@ -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
@@ -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
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
@@ -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
@@ -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
@@ -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
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
@@ -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
@@ -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
cover U-Boot MMC SPL for OMAP4
In reply to Aneesh VHi,
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 othersFeatures supported:
* Clock init - DPLL locking, clock domains/modules enabling
* SDRAM/DMM initialization
* Mux initialization
* MMC raw read support
* MMC FAT read supportImprovments over x-loader:
* Code completely revamped
* DPLL programming that works for allSYS_CLKfrequencies
* 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 platformsAneesh 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 PandaJohn Rigby (1):
mkimage: Add OMAP boot image supportMakefile | 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 100644arch/arm/cpu/armv7/omap4/clocks.c
create mode 100644arch/arm/cpu/armv7/omap4/emif.c
create mode 100644arch/arm/cpu/armv7/omap4/omap4_mux_data.hcreate mode 100644arch/arm/cpu/armv7/omap4/sdram_elpida.ccreate mode 100644arch/arm/include/asm/arch-omap4/clocks.hcreate mode 100644arch/arm/include/asm/arch-omap4/emif.h
copyarch/arm/{cpu/armv7/omap4/lowlevel_init.S=>include/asm/armv7.h} (62%) create mode 100644arch/arm/include/asm/omap_common.h
renameboard/ti/{sdp4430/sdp.h=>panda/panda_mux_data.h} (76%) renameboard/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 100644spl/board/ti/spl-omap.c
copyarch/arm/cpu/armv7/u-boot.lds=>spl/board/ti/spl-omap.lds(57%) create mode 100644tools/omapimage.c
copyarch/arm/cpu/armv7/omap4/lowlevel_init.S=>tools/omapimage.h(53%)
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 othersFeatures supported:
* Clock init - DPLL locking, clock domains/modules enabling
* SDRAM/DMM initialization
* Mux initialization
* MMC raw read support
* MMC FAT read supportImprovments over x-loader:
* Code completely revamped
* DPLL programming that works for allSYS_CLKfrequencies
* 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 platformsAneesh 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 PandaJohn Rigby (1):
mkimage: Add OMAP boot image supportQuoted 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 100644arch/arm/cpu/armv7/omap4/emif.c
create mode 100644arch/arm/cpu/armv7/omap4/omap4_mux_data.hcreate mode 100644arch/arm/cpu/armv7/omap4/sdram_elpida.ccreate mode 100644arch/arm/include/asm/arch-omap4/clocks.hcreate mode 100644arch/arm/include/asm/arch-omap4/emif.hcopyarch/arm/{cpu/armv7/omap4/lowlevel_init.S=>include/asm/armv7.h}(62%)
Quoted 9 lines
create mode 100644
arch/arm/include/asm/omap_common.hrenameboard/ti/{sdp4430/sdp.h=>panda/panda_mux_data.h} (76%) renameboard/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 100644spl/board/ti/spl-omap.c
copyarch/arm/cpu/armv7/u-boot.lds=>spl/board/ti/spl-omap.lds(57%) create mode 100644tools/omapimage.c
copyarch/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-----
cover U-Boot MMC SPL for OMAP4
Chander,
Quoted 4 lines · Chander M. Kashyap
Hi,
1. Please change spl directory name tommc_splin line withnand_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 allSYS_CLKfrequencies > * 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(-)
> copyarch/arm/cpu/armv7/{omap4/lowlevel_init.S=>
omap-common/utils.c} (50%)
> create mode 100644arch/arm/cpu/armv7/omap4/clocks.c
> create mode 100644arch/arm/cpu/armv7/omap4/emif.c
> create mode 100644arch/arm/cpu/armv7/omap4/omap4_mux_data.h
> create mode 100644arch/arm/cpu/armv7/omap4/sdram_elpida.c
> create mode 100644arch/arm/include/asm/arch-omap4/clocks.h
> create mode 100644arch/arm/include/asm/arch-omap4/emif.h
> copyarch/arm/{cpu/armv7/omap4/lowlevel_init.S=>
include/asm/armv7.h} (62%)
> create mode 100644arch/arm/include/asm/omap_common.h
> renameboard/ti/{sdp4430/sdp.h=>panda/panda_mux_data.h} (76%)
> renameboard/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 100644spl/board/ti/spl-omap.c
> copyarch/arm/cpu/armv7/u-boot.lds=>
spl/board/ti/spl-omap.lds(57%)
> create mode 100644tools/omapimage.c
> copyarch/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-----
v2 cover U-Boot MMC SPL for OMAP4
In reply to Aneesh VThis 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.hv2 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 othersThis series is depedent on the following series:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/95550Features supported:
* Clock init - DPLL locking, clock domains/modules enabling
* SDRAM/DMM initialization
* Mux initialization
* MMC raw read support
* MMC FAT read supportImprovments over x-loader:
* Code completely revamped
* DPLL programming that works for allSYS_CLKfrequencies
* 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 platformsV2:
* 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 seriesAneesh 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
PATCH v2 1/22 mkimage: Add OMAP boot image support
In reply to Aneesh VFrom: 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
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]>
Signed-off-by 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.hcommon/image.c +0
-0
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@@ -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
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]>
Signed-off-by 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 100644tools/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@@ -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@@ -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
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_toruint16_tto 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
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_toruint16_tto 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
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 "structgp_header" alone, not from the other structs?
PATCH v2 1/22 mkimage: Add OMAP boot image support
In reply to Wolfgang DenkHi 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_toruint16_tto 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
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_tversion" in "structch_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 BraunPATCH v2 1/22 mkimage: Add OMAP boot image support
In reply to Aneesh Vtools/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
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
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
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
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
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
@@ -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
@@ -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
@@ -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
PATCH v2 2/22 omap4: add OMAP4430 revision check
Dear Aneesh V,
Quoted 5 lines · In message <[email protected]> you wrote:
Signed-off-by Aneesh V <[email protected]>---
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@@ -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
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:
Signed-off-by Aneesh V<[email protected]>---
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@@ -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
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/98522If 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_CODEregister. 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 beOMAP4430_SILICON_ID_INVALIDin 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_INVALIDsituation inomap4_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
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 4you 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
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 22And 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 AugustinePATCH v2 3/22 armv7: start.S: provide a hook for saving boot params
In reply to Aneesh VProvide 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
@@ -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
@@ -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
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.Signed-off-by Aneesh V <[email protected]>
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.
PATCH v2 4/22 omap4: save parameters passed by ROM code to SPL
In reply to Aneesh VSave 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
@@ -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
@@ -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
@@ -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
@@ -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
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.
Signed-off-by Aneesh V <[email protected]>
...
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
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.
Signed-off-by Aneesh V<[email protected]>
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<- r1Why 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
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.
Signed-off-by Aneesh V<[email protected]>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<- r1Why 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 1753PATCH 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.
Signed-off-by Aneesh V<[email protected]>...
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<- r1Why 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
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
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
@@ -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
@@ -55,6 +55,8 @@ SECTIONS . = ALIGN(4); + __image_copy_end = .; + .rel.dyn : { __rel_dyn_start = .; *(.rel*)
Signature · 1 line
1.7.0.4
PATCH v2 6/22 Add generic spl infrastructure
In reply to Aneesh VDefine 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
@@ -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
@@ -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
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-levelMakefileto build such an splRationale 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
Signed-off-by Aneesh V <[email protected]>---
This patch generates 1 checkpatch warning due to declaration ofDECLARE_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.
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-levelMakefileto build such an splRationale 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
Signed-off-by Aneesh V<[email protected]>---
This patch generates 1 checkpatch warning due to declaration ofDECLARE_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
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_KERNELetc?
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.
PATCH v2 6/22 Add generic spl infrastructure
In reply to Aneesh VQuoted 28 lines · On Sun, 15 May 2011 20:51:24 +0530 Aneesh V <[email protected]> wrote:
Makefile +16
-0@@ -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
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
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@@ -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
-0nand_spl: $(TIMESTAMP_FILE) $(VERSION_FILE) depend + +$(NAND_SPL): $(TIMESTAMP_FILE) $(VERSION_FILE) dependYou 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)MLOWhat 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@@ -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
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
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
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.
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
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.
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
PATCH v2 6/22 Add generic spl infrastructure
In reply to Aneesh VQuoted 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@@ -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
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@@ -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_splcode, including ARM, that uses gd. E.g.putc()inboard/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 existingnand_splusers?
I would probably revert the change as advised by Wolfgang.
best regards,
Aneesh
PATCH v2 7/22 armv7: start.S: add SPL support
In reply to Aneesh VChanges 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
@@ -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
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_
PATCH v2 8/22 omap: add spl support
In reply to Aneesh VAdd 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
@@ -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
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.
Signed-off-by Aneesh V <[email protected]>--- 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"
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.
Signed-off-by Aneesh V<[email protected]>--- 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 100644spl/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_splandonenand_iplinto 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
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_splandonenand_iplinto 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 unknownPATCH 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_splandonenand_iplinto 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
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."
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
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>/MakefileThe idea is to have the board level
Makefilein '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
Makefileshould conditionally include the respective image file in the target 'all' based on CONFIG options. For instance 'all' may include 'onenand-ipl-2k.bin' ifCONFIG_ONENAND_U_BOOTis 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
PATCH v2 8/22 omap: add spl support
In reply to Aneesh VHi 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>/MakefileThe idea is to have the board level
Makefilein '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
Makefileshould conditionally include the respective image file in the target 'all' based on CONFIG options. For instance 'all' may include 'onenand-ipl-2k.bin' ifCONFIG_ONENAND_U_BOOTis 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
PATCH v2 8/22 omap: add spl support
In reply to Aneesh VDear 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
Makefilein '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
Makefileshould conditionally include the respective image file in the target 'all' based on CONFIG options. For instance 'all' may include 'onenand-ipl-2k.bin' ifCONFIG_ONENAND_U_BOOTis 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
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>/MakefileActually that would be
board/[<vendor>/]<board>/Quoted 3 lines
The idea is to have the board level
Makefilein '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
Makefileshould conditionally include the respective image file in the target 'all' based on CONFIG options. For instance 'all' may include 'onenand-ipl-2k.bin' ifCONFIG_ONENAND_U_BOOTis 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.
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
Makefilefor all the different spl's:
Quoted 4 lines
SPL :$(TIMESTAMP_FILE) $(VERSION_FILE) depend tools
$(MAKE) -C spl/board/$(BOARDDIR) allAnd 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
Makefilestructure. With the newMakefilestructure 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 2003PATCH 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
Makefilefor all the different spl's:Quoted 4 lines
SPL :$(TIMESTAMP_FILE) $(VERSION_FILE) depend tools
$(MAKE) -C spl/board/$(BOARDDIR) allAnd leave the rest to the board level Makefiles
We just discussed that there are cases where there may be no board level
Makefilebe 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
Makefilestructure. With the newMakefilestructure 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
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
Makefilestructure. With the newMakefilestructure you are suggesting this may not hold good.Why not?
I was saying that my suggestion of delegating everything to board level
Makefilewill 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
PATCH v2 8/22 omap: add spl support
In reply to Aneesh VQuoted 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_splandonenand_iplinto 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
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_splandonenand_iplinto 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.cornand_boot_fsl_nfc.cinstead ofnand_boot.c).
Quoted 7 lines
Renaming
nand_splseems 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
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
PATCH v2 8/22 omap: add spl support
In reply to Aneesh VDear Aneesh V,
Quoted 4 lines · In message <[email protected]> you wrote:
Add the basic spl framework and linker script common for OMAP3/4 platforms.
Signed-off-by Aneesh V <[email protected]>
...
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
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.
Signed-off-by Aneesh V<[email protected]>
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
PATCH v2 8/22 omap: add spl support
In reply to Aneesh VHi 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.
Signed-off-by Aneesh V <[email protected]>--- 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.ldsspl/board/ti/spl-omap.c new file +40
-0@@ -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@@ -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
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_splsupport. 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 toomap4_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
PATCH v2 9/22 omap4: add spl support for OMAP4 SDP
In reply to Aneesh VAdapted 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
@@ -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
@@ -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
@@ -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
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 fileSigned-off-by Aneesh V <[email protected]>---
V2:
* ChangedCONFIG_SYS_SPL_TEXT_BASEto0x40304350from0x40304360. 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@@ -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
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 fileSigned-off-by Aneesh V<[email protected]>---
V2:
* ChangedCONFIG_SYS_SPL_TEXT_BASEto0x40304350from0x40304360. 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 100644spl/board/ti/rules-omap.mk
Quoted 2 lines
We do you introduce these files? Please omit them, and use a plain
Makefileinstead.
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@@ -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 = 0x80100000NAK. Please define in board config header, and get rid of the config.mk file.
ok.
best regards,
Aneesh
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 100644spl/board/ti/rules-omap.mkWe do you introduce these files? Please omit them, and use a plain
Makefileinstead.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
Makefileof both panda and SDP.This re-use will be evident when you see a later patch that replicates the same
Makefilefor 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 unknownPATCH 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 100644spl/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
Makefileinstead.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
Makefileof both panda and SDP.This re-use will be evident when you see a later patch that replicates the same
Makefilefor 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
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
Makefilein 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 withinarch/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.
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
Makefilein the board directory, right?(quoted diff) +2
-0+SPL :$(TIMESTAMP_FILE) $(VERSION_FILE) depend tools + $(MAKE) -C spl/board/$(BOARDDIR) allMaybe 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 withinarch/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
Makefilestructure 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
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
Makefilefrom the top-levelMakefileand 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
Makefilestructure 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
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
Makefilefrom the top-levelMakefileand 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
Makefilestructure 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
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
Makefileis 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
Makefilefrom the top-levelMakefileand 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
Makefileneeds 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 theMakefile. 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,
AneeshQuoted 15 lines
Quoted 6 lines
Quoted 3 lines
Then we should adapt the directory and
Makefilestructure 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
PATCH v2 9/22 omap4: add spl support for OMAP4 SDP
In reply to Aneesh VHi 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
Makefileis 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
Makefilefrom the top-levelMakefileand 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
Makefileneeds 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 theMakefile. 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
PATCH v2 9/22 omap4: add spl support for OMAP4 SDP
In reply to Aneesh VDear 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
Makefileis 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
Makefileneeds 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_PATCH v2 9/22 omap4: add spl support for OMAP4 SDP
In reply to Aneesh VDear 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 fileSigned-off-by Aneesh V <[email protected]>---
V2:
* ChangedCONFIG_SYS_SPL_TEXT_BASEto0x40304350from0x40304360. 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@@ -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
PATCH v2 10/22 omap4: utility function to identify the context of hw init
In reply to Aneesh VThe 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
@@ -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; + asmvolatile ("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
@@ -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
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]
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
PATCH v2 11/22 omap4: separate mux settings into essential and non essential parts
In reply to Aneesh VDo 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
@@ -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
@@ -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
@@ -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
@@ -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
PATCH v2 12/22 omap4: correct mux data for sdp4430
In reply to Aneesh Vsync 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
@@ -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
@@ -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
PATCH v2 13/22 omap4: add clock support
In reply to Aneesh VAdd 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
Wolfgang Denk
NAKPATCH 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 modulesThis work draws upon previous work done for x-loader mainly by:
Santosh Shilimkar <[email protected]> Rajendra Nayak <[email protected]>Signed-off-by Aneesh V <[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@@ -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@@ -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.
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 modulesThis work draws upon previous work done for x-loader mainly by:
Santosh Shilimkar<[email protected]> Rajendra Nayak<[email protected]>Signed-off-by Aneesh V<[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.ccreate mode 100644arch/arm/cpu/armv7/omap4/clocks_get_m_n.ccreate mode 100644arch/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@@ -30,6 +30,7 @@ SOBJS += lowlevel_init.o COBJS += board.o COBJS += mem.o COBJS += sys_info.o +COBJS += clocks.oPlease 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@@ -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
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 LabsPATCH 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
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.
PATCH v2 13/22 omap4: add clock support
In reply to Aneesh VDear 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
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*constmy_regs= (structmy_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
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*constmy_regs= (structmy_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[] = {
&(((structmy_regs_struct*)0x1000)->reg1),
&(((structmy_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
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
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*constmy_regs= (structmy_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
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"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
PATCH v2 13/22 omap4: add clock support
In reply to Aneesh VQuoted 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
PATCH v2 13/22 omap4: add clock support
In reply to Aneesh VDear 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*constmy_regs= (structmy_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
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*constmy_regs= (structmy_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
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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
PATCH v2 15/22 omap4: add sdram init support
In reply to Aneesh VAdd 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
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).
Signed-off-by Aneesh V <[email protected]>V2:
* Changes for makefile changes
* Minor corrections indo_lpddr2_init()
* Minor corrections toread_idleinterval 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
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).
Signed-off-by Aneesh V<[email protected]>V2:
* Changes for makefile changes
* Minor corrections indo_lpddr2_init()
* Minor corrections toread_idleinterval 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.ccreate mode 100644arch/arm/cpu/armv7/omap4/sdram_elpida.ccreate mode 100644arch/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
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?
PATCH v2 15/22 omap4: add sdram init support
In reply to Aneesh VDear Aneesh V,
Quoted 9 lines · In message <[email protected]> you wrote:
Add support for the SDRAM controller (EMIF).
Signed-off-by Aneesh V <[email protected]>V2:
* Changes for makefile changes
* Minor corrections indo_lpddr2_init()
* Minor corrections toread_idleinterval 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?
PATCH v2 16/22 omap4: calculate EMIF register values
In reply to Aneesh VCalculate 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
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.
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
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
PATCH v2 16/22 omap4: calculate EMIF register values
In reply to Wolfgang DenkHi 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
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.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
PATCH v2 17/22 omap4: automatic sdram detection
In reply to Aneesh VIdentify 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
@@ -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 (®s, &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
@@ -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_regsvoid 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
@@ -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
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
Signed-off-by Aneesh V <[email protected]>--- 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.
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
Signed-off-by Aneesh V<[email protected]>--- 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
PATCH v2 18/22 armv7: embed u-boot size within u-boot for use from SPL
In reply to Aneesh VEmbed 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
@@ -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
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
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
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.Ssuch as_bss_end_ofs,_end_ofsetc. 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.
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.Ssuch as_bss_end_ofs,_end_ofsetc. 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?
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
0xCin 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_SPLis 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.
PATCH v2 18/22 armv7: embed u-boot size within u-boot for use from SPL
In reply to Aneesh VQuoted 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.
Signed-off-by Aneesh V <[email protected]>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
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
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.
Signed-off-by Aneesh V<[email protected]>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@@ -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
0xdeadbeefdoes 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
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
@@ -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
@@ -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
@@ -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
@@ -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
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
@@ -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
@@ -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
@@ -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
PATCH v2 20/22 omap: spl: add FAT support over MMC
Dear Aneesh V,
Quoted 9 lines · In message <[email protected]> you wrote:
Signed-off-by Aneesh V <[email protected]>---
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
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
@@ -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
@@ -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
@@ -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
@@ -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
Wolfgang Denk
NAKPATCH v2 21/22 omap4: add spl support for OMAP4 Panda
Dear Aneesh V,
Quoted 19 lines · In message <[email protected]> you wrote:
Signed-off-by Aneesh V <[email protected]>---
V2:
* ChangedCONFIG_SYS_SPL_TEXT_BASEto0x40304350for 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/Makefilearch/arm/cpu/armv7/omap4/emif.c +0
-0
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
-0mapped_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@@ -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?PATCH v2 22/22 omap: spl: add more debug traces
In reply to Aneesh VIn 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
@@ -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
@@ -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
@@ -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
@@ -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
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@@ -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
-0void 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
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
-1core_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
-0freq_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
-0arch/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
@@ -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
@@ -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
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 isinit_baudrate()needs global data and global data is initialized inboard_init_f(). Further, we can not move global data initialization earlier because for global data we reuse low level stack used bylowlevel_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
PATCH v2 22/22 omap: spl: add more debug traces
In reply to Aneesh VDear 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(). Beforeboard_init_f()typically a lot of(in fact most of) low level initialization happens through thelowlevel_init()function called fromstart.Sand the initial part ofinit_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 inlowlevel_init(). Some part of ourlowlevel_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 ChesterfieldPATCH 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
v3 cover U-Boot MMC SPL for OMAP4
In reply to Aneesh VThis 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