Re: [U-Boot] [PATCH] ARM: Fix __bss_start and __bss_end in linker scripts
Hi Benoît,
CC:ing Stephen Warren who wrote commit 2b7818d4 which git blame tells
me added the ASSERT() to arch/arm/cpu/u-boot.lds, and Tom Rini to help
decide what to do.
On Fri, 5 Apr 2013 05:44:55 +0200 (CEST), Benoît Thébaudeau
benoit.thebaud...@advansee.com wrote:
Hi Albert,
On Friday, April 5, 2013 1:54:38 AM, Albert ARIBAUD wrote:
Hi Benoît,
On Fri, 5 Apr 2013 01:13:51 +0200 (CEST), Benoît Thébaudeau
benoit.thebaud...@advansee.com wrote:
On Friday, April 5, 2013 1:05:53 AM, Benoît Thébaudeau wrote:
Hi Albert,
On Friday, April 5, 2013 12:13:53 AM, Albert ARIBAUD wrote:
Subject: [PATCH] ARM: Fix __bss_start and __bss_end in linker scripts
Commit 3ebd1cbc introduced compiler-generated __bss_start
and __bss_end__ and commit c23561e7 rewrote all __bss_end__
as __bss_end. Their merge caused silent and harmless but
potentially bug-inducing clashes between compiler- and linker-
enerated __bss_end symbols.
Make __bss_end and __bss_start compiler-only, and create
__bss_base and __bss_limit for linker-only use.
Reported-by: Benoît Thébaudeau benoit.thebaud...@advansee.com
Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net
---
arch/arm/cpu/ixp/u-boot.lds| 14 ++
arch/arm/cpu/u-boot.lds| 14 ++
board/actux1/u-boot.lds| 14 ++
board/actux2/u-boot.lds| 14 ++
board/actux3/u-boot.lds| 14 ++
board/dvlhost/u-boot.lds | 14 ++
board/freescale/mx31ads/u-boot.lds | 14 ++
7 files changed, 70 insertions(+), 28 deletions(-)
diff --git a/arch/arm/cpu/ixp/u-boot.lds b/arch/arm/cpu/ixp/u-boot.lds
index 8345b55..c999829 100644
--- a/arch/arm/cpu/ixp/u-boot.lds
+++ b/arch/arm/cpu/ixp/u-boot.lds
@@ -67,17 +67,23 @@ SECTIONS
_end = .;
+/*
+ * Compiler-generated __bss_start and __bss_end, see
arch/arm/lib/bss.c
+ * __bss_base and __bss_limit are for linker only (overlay ordering)
+ */
+
.bss_start __rel_dyn_start (OVERLAY) : {
KEEP(*(.__bss_start));
+ HIDDEN(__bss_base = .);
}
- .bss __bss_start (OVERLAY) : {
+ .bss __bss_base (OVERLAY) : {
*(.bss*)
. = ALIGN(4);
- __bss_end = .;
+ HIDDEN(__bss_limit = .);
}
- .bss_end __bss_end (OVERLAY) : {
- KEEP(*(__bss_end));
+ .bss_end __bss_limit (OVERLAY) : {
+ KEEP(*(.__bss_end));
}
/DISCARD/ : { *(.dynstr*) }
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
index 3a1083d..0543b06 100644
--- a/arch/arm/cpu/u-boot.lds
+++ b/arch/arm/cpu/u-boot.lds
@@ -81,18 +81,24 @@ SECTIONS
*(.mmutable)
}
+/*
+ * Compiler-generated __bss_start and __bss_end, see
arch/arm/lib/bss.c
+ * __bss_base and __bss_limit are for linker only (overlay ordering)
+ */
+
.bss_start __rel_dyn_start (OVERLAY) : {
KEEP(*(.__bss_start));
+ HIDDEN(__bss_base = .);
}
- .bss __bss_start (OVERLAY) : {
+ .bss __bss_base (OVERLAY) : {
*(.bss*)
. = ALIGN(4);
- __bss_end = .;
+ HIDDEN(__bss_limit = .);
}
- .bss_end __bss_end (OVERLAY) : {
- KEEP(*(__bss_end));
+ .bss_end __bss_limit (OVERLAY) : {
+ KEEP(*(.__bss_end));
}
/DISCARD/ : { *(.dynstr*) }
diff --git a/board/actux1/u-boot.lds b/board/actux1/u-boot.lds
index c76728a..7e5c4d8 100644
--- a/board/actux1/u-boot.lds
+++ b/board/actux1/u-boot.lds
@@ -74,17 +74,23 @@ SECTIONS
_end = .;
+/*
+ * Compiler-generated __bss_start and __bss_end, see
arch/arm/lib/bss.c
+ * __bss_base and __bss_limit are for linker only (overlay ordering)
+ */
+
.bss_start __rel_dyn_start (OVERLAY) : {
KEEP(*(.__bss_start));
+ HIDDEN(__bss_base = .);
}
- .bss __bss_start (OVERLAY) : {
+ .bss __bss_base (OVERLAY) : {
*(.bss*)
. = ALIGN(4);
- __bss_end = .;
+ HIDDEN(__bss_limit = .);
}
- .bss_end __bss_end (OVERLAY) : {
- KEEP(*(__bss_end));
+ .bss_end __bss_limit (OVERLAY) : {
+ KEEP(*(.__bss_end));
}
/DISCARD/ : { *(.dynstr*) }
diff --git a/board/actux2/u-boot.lds
Re: [U-Boot] PPC4XX Custom Board - Failing to read I2C
On 05.04.2013 02:04, txcotrader wrote:
After looking deeper I've found a difference in register values when
performing drivers/i2c/ppc4xx_i2c.c-i2c_transfer function.
v1.7.02 code yields:
/* Transfer is in progress
* we have to wait for upto 5 bytes of data
* 1 byte chip address+r/w bit then bc bytes
* of data.
* udelay(10) is 1 bit time at 100khz
* Doubled for slop. 20 is too small.
*/
i = 2*5*8;
do {
/* Get status */
status = in_8((u8 *)IIC_STS);
printf(gd_ do status-i = %d, status = %d\n, i, status);
udelay(20);
i--;
} while ((status IIC_STS_PT) !(status IIC_STS_ERR) (i
0));
gd_ do status-i = 80, status = 40
v2013.01.01 Yields:
i = 2 * 5 * 8;
do {
/* Get status */
status = in_8(i2c-sts);
printf(gd_ do status-i = %d, status = %d\n, i, status);
udelay(10);
i--;
} while ((status IIC_STS_PT) !(status IIC_STS_ERR)
(i 0));
gd_ do status-i = 80, status = 40
v1.7.02 - include/4xx_i2c.h:#define IIC_STS
(I2C_REGISTERS_BASE_ADDRESS+IICSTS)
v2013.01.01 - struct ppc4xx_i2c *i2c = (struct ppc4xx_i2c *)I2C_BASE_ADDR;
Newb question, but I should be able to add an offset to correct this issue
right?
The resulting addresses should be the same. The old version uses the
offset via a define and the new one the (recommended) struct access to
the register. I suggest you print the resulting address to verify that
it really is the same.
Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: omap4: Fix SDRAM AUTO DETECTION
+ Michael
On Friday 05 April 2013 11:21 AM, Lokesh Vutla wrote:
Commit 8602114 omap: emif: configure emif only when required
breaks SDRAM_AUTO_DETECTION.
The issue is dmm_init() depends on emif_sizes[](SDRAM Auto detection)
done in do_sdram_init(). The above commit moves dmm_init() above
do_sdram_init() because of which dmm_init() uses uninitialized
emif_sizes[].
So instead of using global emif_sizes[], get sdram details locally
and calculate emif sizes.
Reported-by: Michael Cashwell mboa...@prograde.net
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/cpu/armv7/omap-common/emif-common.c | 29 ++
arch/arm/cpu/armv7/omap4/emif.c |1 -
arch/arm/cpu/armv7/omap5/emif.c |1 -
arch/arm/include/asm/arch-omap4/omap.h |1 -
arch/arm/include/asm/arch-omap5/omap.h |1 -
arch/arm/include/asm/emif.h |1 -
6 files changed, 16 insertions(+), 18 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/emif-common.c
b/arch/arm/cpu/armv7/omap-common/emif-common.c
index 9eb1279..cdb4439 100644
--- a/arch/arm/cpu/armv7/omap-common/emif-common.c
+++ b/arch/arm/cpu/armv7/omap-common/emif-common.c
@@ -655,20 +655,27 @@ static u32 get_ddr_phy_ctrl_1(u32 freq, u8 RL)
return phy;
}
-static u32 get_emif_mem_size(struct emif_device_details *devices)
+static u32 get_emif_mem_size(u32 base)
{
u32 size_mbytes = 0, temp;
+ struct emif_device_details dev_details;
+ struct lpddr2_device_details cs0_dev_details, cs1_dev_details;
+ u32 emif_nr = emif_num(base);
- if (!devices)
- return 0;
+ emif_reset_phy(base);
+ dev_details.cs0_device_details = emif_get_device_details(emif_nr, CS0,
+ cs0_dev_details);
+ dev_details.cs1_device_details = emif_get_device_details(emif_nr, CS1,
+ cs1_dev_details);
+ emif_reset_phy(base);
- if (devices-cs0_device_details) {
- temp = devices-cs0_device_details-density;
+ if (dev_details.cs0_device_details) {
+ temp = dev_details.cs0_device_details-density;
size_mbytes += lpddr2_density_2_size_in_mbytes[temp];
}
- if (devices-cs1_device_details) {
- temp = devices-cs1_device_details-density;
+ if (dev_details.cs1_device_details) {
+ temp = dev_details.cs1_device_details-density;
size_mbytes += lpddr2_density_2_size_in_mbytes[temp];
}
/* convert to bytes */
@@ -1040,13 +1047,9 @@ static void do_sdram_init(u32 base)
/* Return if no devices on this EMIF */
if (!dev_details.cs0_device_details
!dev_details.cs1_device_details) {
- emif_sizes[emif_nr - 1] = 0;
return;
}
- if (!in_sdram)
- emif_sizes[emif_nr - 1] = get_emif_mem_size(dev_details);
-
/*
* Get device timings:
* - Default timings specified by JESD209-2 if
@@ -1108,8 +,8 @@ void dmm_init(u32 base)
mapped_size = 0;
section_cnt = 3;
sys_addr = CONFIG_SYS_SDRAM_BASE;
- emif1_size = emif_sizes[0];
- emif2_size = emif_sizes[1];
+ emif1_size = get_emif_mem_size(EMIF1_BASE);
+ emif2_size = get_emif_mem_size(EMIF2_BASE);
debug(emif1_size 0x%x emif2_size 0x%x\n, emif1_size, emif2_size);
if (!emif1_size !emif2_size)
diff --git a/arch/arm/cpu/armv7/omap4/emif.c b/arch/arm/cpu/armv7/omap4/emif.c
index ca4823d..53f6063 100644
--- a/arch/arm/cpu/armv7/omap4/emif.c
+++ b/arch/arm/cpu/armv7/omap4/emif.c
@@ -33,7 +33,6 @@
#ifndef CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS
u32 *const T_num = (u32 *)OMAP4_SRAM_SCRATCH_EMIF_T_NUM;
u32 *const T_den = (u32 *)OMAP4_SRAM_SCRATCH_EMIF_T_DEN;
-u32 *const emif_sizes = (u32 *)OMAP4_SRAM_SCRATCH_EMIF_SIZE;
#endif
#ifdef CONFIG_SYS_DEFAULT_LPDDR2_TIMINGS
diff --git a/arch/arm/cpu/armv7/omap5/emif.c b/arch/arm/cpu/armv7/omap5/emif.c
index 90d362c..9f53c90 100644
--- a/arch/arm/cpu/armv7/omap5/emif.c
+++ b/arch/arm/cpu/armv7/omap5/emif.c
@@ -34,7 +34,6 @@
#define print_timing_reg(reg) debug(#reg - 0x%08x\n, (reg))
u32 *const T_num = (u32 *)OMAP5_SRAM_SCRATCH_EMIF_T_NUM;
u32 *const T_den = (u32 *)OMAP5_SRAM_SCRATCH_EMIF_T_DEN;
-u32 *const emif_sizes = (u32 *)OMAP5_SRAM_SCRATCH_EMIF_SIZE;
#endif
#ifdef CONFIG_SYS_DEFAULT_LPDDR2_TIMINGS
diff --git a/arch/arm/include/asm/arch-omap4/omap.h
b/arch/arm/include/asm/arch-omap4/omap.h
index 5f321fe..ad984da 100644
--- a/arch/arm/include/asm/arch-omap4/omap.h
+++ b/arch/arm/include/asm/arch-omap4/omap.h
@@ -147,7 +147,6 @@ struct s32ktimer {
#define SRAM_SCRATCH_SPACE_ADDR NON_SECURE_SRAM_START
/* SRAM scratch space entries */
#define OMAP4_SRAM_SCRATCH_OMAP4_REV SRAM_SCRATCH_SPACE_ADDR
-#define OMAP4_SRAM_SCRATCH_EMIF_SIZE
Re: [U-Boot] [PATCH V8 9/9] COMMON: MMC: Command to support EMMC booting and to resize EMMC boot partition
Hi Amar,
On 04/03/2013 11:08 PM, Amar wrote:
This patch adds commands to access(open/close) and resize boot partitions on
EMMC.
Signed-off-by: Amar amarendra...@samsung.com
---
Changes since V1:
1)Combined the common piece of code between 'open' and 'close'
operations.
Changes since V2:
1)Updation of commit message and resubmition of proper patch set.
Changes since V3:
No change.
Changes since V4:
1)Added a new funtion boot_part_access() to combine the common parts of
'mmc open' and 'mmc close' functionalities.
2)Used the generic function mmc_boot_part_access() instead of
two functions mmc_boot_open() and mmc_boot_close(). By doing so user
can specify which boot partition to be accessed (opened / closed).
Changes since V5:
1)Updated minor nits in response to review comments.
Changes since V6:
No change.
Changes since V7:
1)The piece of code involved in open/close and resize of EMMC boot
partition has been made conditional and is enabled only if the macro
CONFIG_SUPPORT_EMMC_BOOT is defined.
common/cmd_mmc.c | 110
++-
1 file changed, 108 insertions(+), 2 deletions(-)
diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
index 8c53a10..c5f60a2 100644
--- a/common/cmd_mmc.c
+++ b/common/cmd_mmc.c
@@ -147,6 +147,36 @@ U_BOOT_CMD(
- display info of the current MMC device
);
+#ifdef CONFIG_SUPPORT_EMMC_BOOT
+static int boot_part_access(struct mmc *mmc, u32 ack, u32 part_num, u32
access)
Why do you use u32? I know that just used 8bit.
+{
+ int err;
+ err = mmc_boot_part_access(mmc, ack, part_num, access);
+
+ if ((err == 0) (access != 0)) {
+ printf(\t\t\t!!!Notice!!!\n);
+
+ printf(!You must close EMMC boot Partition);
+ printf(after all images are written\n);
+
+ printf(!EMMC boot partition has continuity);
+ printf(at image writing time.\n);
+
+ printf(!So, do not close the boot partition);
+ printf(before all images are written.\n);
+ return 0;
+ } else if ((err == 0) (access == 0))
+ return 0;
+ else if ((err != 0) (access != 0)) {
+ printf(EMMC boot partition-%d OPEN Failed.\n, part_num);
+ return 1;
+ } else {
+ printf(EMMC boot partition-%d CLOSE Failed.\n, part_num);
+ return 1;
+ }
+}
+#endif
+
static int do_mmcops(cmd_tbl_t *cmdtp, int flag, int argc, char * const
argv[])
{
enum mmc_state state;
@@ -248,8 +278,75 @@ static int do_mmcops(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[])
curr_device, mmc-part_num);
return 0;
- }
+#ifdef CONFIG_SUPPORT_EMMC_BOOT
+ } else if ((strcmp(argv[1], open) == 0) ||
+ (strcmp(argv[1], close) == 0)) {
+ int dev;
+ struct mmc *mmc;
+ u32 ack, part_num, access = 0;
+
+ if (argc == 4) {
+ dev = simple_strtoul(argv[2], NULL, 10);
+ part_num = simple_strtoul(argv[3], NULL, 10);
+ } else {
+ return CMD_RET_USAGE;
+ }
+ mmc = find_mmc_device(dev);
+ if (!mmc) {
+ printf(no mmc device at slot %x\n, dev);
+ return 1;
+ }
+
+ if (IS_SD(mmc)) {
+ printf(SD device cannot be opened/closed\n);
+ return 1;
+ }
+
+ if ((part_num = 0) || (part_num MMC_NUM_BOOT_PARTITION)) {
+ printf(Invalid boot partition number:\n);
+ printf(Boot partition number cannot be = 0\n);
+ printf(EMMC44 supports only 2 boot partitions\n);
What means? EMMC44 supports only 2 boot partitions?
+ return 1;
+ }
+
+ if (strcmp(argv[1], open) == 0)
+ access = part_num; /* enable R/W access to boot part*/
+ if (strcmp(argv[1], close) == 0)
else if?
+ access = 0; /* No access to boot partition */
+
+ /* acknowledge to be sent during boot operation */
+ ack = 1;
ack is always set to 1? then Can't initialize ack value as 1.
Otherwise, boot_part_access(mmc, 1, part_num, access)?
Best Regards,
Jaehoon Chung
+ return boot_part_access(mmc, ack, part_num, access);
+
+ } else if (strcmp(argv[1], bootpart) == 0) {
+ int dev;
+ dev = simple_strtoul(argv[2], NULL, 10);
+
+ u32 bootsize = simple_strtoul(argv[3], NULL, 10);
+ u32 rpmbsize = simple_strtoul(argv[4], NULL, 10);
+ struct mmc *mmc = find_mmc_device(dev);
+ if
Re: [U-Boot] [PATCH v2] BUGFIX: arm: data abort in get_bad_stack_swi
Hi Tetsuyuki,
On Fri, 5 Apr 2013 10:45:14 +0900, Tetsuyuki Kobayashi
k...@kmckk.co.jp wrote:
When swi instruction is executed, it is expected to get message
software interrupt in console and dump registers and reboot, as
do_software_interrupt() in arch/arm/lib/interrupts.c.
But, actually it causes data abort accessing wrong address in
get_bad_stack_swi
macro in arch/arm/cpu/v7/start.S.
This patch fixes this problem.
The same mistake in arch/arm/cpu/{arm1136,arm1176,pxa}/start.S.
Signed-off-by: Tetsuyuki Kobayashi k...@kmckk.co.jp
---
Changes for v2:
- added arch/arm/cpu/{arm1136,arm1176,pxa}/start.S
(But not tested, because I don't have test boards of them)
arm/arm/cpu/armv7/start.S is tested on KZM-A9-GT board.
arch/arm/cpu/arm1136/start.S |2 +-
arch/arm/cpu/arm1176/start.S |2 +-
arch/arm/cpu/armv7/start.S |2 +-
arch/arm/cpu/pxa/start.S |2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/cpu/arm1136/start.S b/arch/arm/cpu/arm1136/start.S
index eba2324..7b9db2b 100644
--- a/arch/arm/cpu/arm1136/start.S
+++ b/arch/arm/cpu/arm1136/start.S
@@ -392,7 +392,7 @@ cpu_init_crit:
str r0, [r13] @ save R0's value.
ldr r0, IRQ_STACK_START_IN @ get data regions start
str lr, [r0]@ save caller lr in position 0
of saved stack
- mrs r0, spsr@ get the spsr
+ mrs lr, spsr@ get the spsr
str lr, [r0, #4]@ save spsr in position 1 of
saved stack
ldr r0, [r13] @ restore r0
add r13, r13, #4@ pop stack entry
Sorry for not checking this in V1, but I see that get_bad_stack_swi does
not preserve lr, so when bad_save_user_regs is expanded, it will save
the wrong value for lr. You need to restore lr from [r0] before you
restore r0 from [r13].
diff --git a/arch/arm/cpu/arm1176/start.S b/arch/arm/cpu/arm1176/start.S
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
diff --git a/arch/arm/cpu/pxa/start.S b/arch/arm/cpu/pxa/start.S
Ditto for all four files, of course.
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 5/5] ARM: OMAP4/5: Make bootz as the default boot command
Hi Sricharan, On Fri, 5 Apr 2013 11:24:34 +0530, Sricharan R r.sricha...@ti.com wrote: So with OMAP added to multi platform kernel, the uImage no more contains a valid load address. With the uboot already supporting zImage, change the default boot command to bootz instead. Acked-by: Nishanth Menon n...@ti.com Signed-off-by: Sricharan R r.sricha...@ti.com Tested-by: Nishanth Menon n...@ti.com --- include/configs/omap4_common.h |4 ++-- include/configs/omap5_common.h |4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) Is there a reason why this patch does not have history? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 5/5] ARM: OMAP4/5: Make bootz as the default boot command
Hi Albert, On Friday 05 April 2013 12:36 PM, Albert ARIBAUD wrote: Hi Sricharan, On Fri, 5 Apr 2013 11:24:34 +0530, Sricharan R r.sricha...@ti.com wrote: So with OMAP added to multi platform kernel, the uImage no more contains a valid load address. With the uboot already supporting zImage, change the default boot command to bootz instead. Acked-by: Nishanth Menon n...@ti.com Signed-off-by: Sricharan R r.sricha...@ti.com Tested-by: Nishanth Menon n...@ti.com --- include/configs/omap4_common.h |4 ++-- include/configs/omap5_common.h |4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) Is there a reason why this patch does not have history? Amicalement, I had a minor change only in these two from the series. So reposted only these two with 'in-reply-to' threads. If this is not the right etiquette, then should it be update/appended in the original patch ? Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V8 9/9] COMMON: MMC: Command to support EMMC booting and to resize EMMC boot partition
Hi Jaehoon,
Please find the responses below
Thanks Regards
Amarendra Reddy
On 5 April 2013 11:51, Jaehoon Chung jh80.ch...@samsung.com wrote:
Hi Amar,
On 04/03/2013 11:08 PM, Amar wrote:
This patch adds commands to access(open/close) and resize boot
partitions on EMMC.
Signed-off-by: Amar amarendra...@samsung.com
---
Changes since V1:
1)Combined the common piece of code between 'open' and 'close'
operations.
Changes since V2:
1)Updation of commit message and resubmition of proper patch set.
Changes since V3:
No change.
Changes since V4:
1)Added a new funtion boot_part_access() to combine the common
parts of
'mmc open' and 'mmc close' functionalities.
2)Used the generic function mmc_boot_part_access() instead of
two functions mmc_boot_open() and mmc_boot_close(). By doing
so user
can specify which boot partition to be accessed (opened / closed).
Changes since V5:
1)Updated minor nits in response to review comments.
Changes since V6:
No change.
Changes since V7:
1)The piece of code involved in open/close and resize of EMMC boot
partition has been made conditional and is enabled only if the
macro
CONFIG_SUPPORT_EMMC_BOOT is defined.
common/cmd_mmc.c | 110
++-
1 file changed, 108 insertions(+), 2 deletions(-)
diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
index 8c53a10..c5f60a2 100644
--- a/common/cmd_mmc.c
+++ b/common/cmd_mmc.c
@@ -147,6 +147,36 @@ U_BOOT_CMD(
- display info of the current MMC device
);
+#ifdef CONFIG_SUPPORT_EMMC_BOOT
+static int boot_part_access(struct mmc *mmc, u32 ack, u32 part_num, u32
access)
Why do you use u32? I know that just used 8bit.
Yes, just 8bit would suffice. I will update it.
+{
+ int err;
+ err = mmc_boot_part_access(mmc, ack, part_num, access);
+
+ if ((err == 0) (access != 0)) {
+ printf(\t\t\t!!!Notice!!!\n);
+
+ printf(!You must close EMMC boot Partition);
+ printf(after all images are written\n);
+
+ printf(!EMMC boot partition has continuity);
+ printf(at image writing time.\n);
+
+ printf(!So, do not close the boot partition);
+ printf(before all images are written.\n);
+ return 0;
+ } else if ((err == 0) (access == 0))
+ return 0;
+ else if ((err != 0) (access != 0)) {
+ printf(EMMC boot partition-%d OPEN Failed.\n, part_num);
+ return 1;
+ } else {
+ printf(EMMC boot partition-%d CLOSE Failed.\n, part_num);
+ return 1;
+ }
+}
+#endif
+
static int do_mmcops(cmd_tbl_t *cmdtp, int flag, int argc, char * const
argv[])
{
enum mmc_state state;
@@ -248,8 +278,75 @@ static int do_mmcops(cmd_tbl_t *cmdtp, int flag,
int argc, char * const argv[])
curr_device, mmc-part_num);
return 0;
- }
+#ifdef CONFIG_SUPPORT_EMMC_BOOT
+ } else if ((strcmp(argv[1], open) == 0) ||
+ (strcmp(argv[1], close) == 0)) {
+ int dev;
+ struct mmc *mmc;
+ u32 ack, part_num, access = 0;
+
+ if (argc == 4) {
+ dev = simple_strtoul(argv[2], NULL, 10);
+ part_num = simple_strtoul(argv[3], NULL, 10);
+ } else {
+ return CMD_RET_USAGE;
+ }
+ mmc = find_mmc_device(dev);
+ if (!mmc) {
+ printf(no mmc device at slot %x\n, dev);
+ return 1;
+ }
+
+ if (IS_SD(mmc)) {
+ printf(SD device cannot be opened/closed\n);
+ return 1;
+ }
+
+ if ((part_num = 0) || (part_num
MMC_NUM_BOOT_PARTITION)) {
+ printf(Invalid boot partition number:\n);
+ printf(Boot partition number cannot be = 0\n);
+ printf(EMMC44 supports only 2 boot partitions\n);
What means? EMMC44 supports only 2 boot partitions?
As per the eMMC 4.4 specification, eMMC 4.4 has 1 RPMB partition, 2 Boot
partitions and 4 General Purpose partitions.
As there are only 2 Boot partitions, we restrict the user not to use an
invalid partition number.
+ return 1;
+ }
+
+ if (strcmp(argv[1], open) == 0)
+ access = part_num; /* enable R/W access to boot
part*/
+ if (strcmp(argv[1], close) == 0)
else if?
Even 'else if' is fine, but I wanted to explicitly check the string in both
cases.
+ access = 0; /* No access to boot partition */
+
+ /* acknowledge to
Re: [U-Boot] [STATUS] v2013.04-rc2 released
Hi, -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Simon Glass Sent: Thursday, April 04, 2013 10:25 PM To: Tom Rini Cc: U-Boot Mailing List Subject: Re: [U-Boot] [STATUS] v2013.04-rc2 released Hi Tom, On Wed, Apr 3, 2013 at 2:33 PM, Tom Rini tr...@ti.com wrote: Hey all, I've tagged and pushed v2013.04-rc2 now. We're getting closer to the expected release date, but I hope to meet the deadline still. [...] Given the interest in the TPM code, it would be good if we could bring in the pending TPM patches to this release so that U-Boot has everything up to date on that. For example the sboot code you pointed me to makes quite heavily use of the TPM and the 'tpm' command and associated that Che-Liang wrote would be useful here. If you are happy to bring that in for this release I will go through and create a bundle for it, and test it on snow. I also plan to send you a patman/buildman pull, plus get the We (at gdsys) are working on U-Boot code to support our new board and this code depends on Che-Liang Chious TPM patch. (We currently plan to submit the patch set soon and hope it gets into the the next release (2013.07).) I made some extensions to Che-Liangs TPM lib which adds support for authorized TPM commands and adds single authorized versions of two TPM commands (LoadKey2 and GetPubKey)). (Of course separatly configurable since this authorization stuff adds some amount of code.) But I'm not sure if I can submit a patch on the U-Boot ML which requires another patch (namely Che-Liang Chious TPM patch) which is not already in the main line. If Che-Liangs work gets into 2013.04 it would be great and we would happily base on it when we publish our next changes. Greetings, Reinhard Pfau. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 5/5] ARM: OMAP4/5: Make bootz as the default boot command
Hi Sricharan, On Fri, 5 Apr 2013 12:44:45 +0530, Sricharan R r.sricha...@ti.com wrote: Hi Albert, On Friday 05 April 2013 12:36 PM, Albert ARIBAUD wrote: Hi Sricharan, On Fri, 5 Apr 2013 11:24:34 +0530, Sricharan R r.sricha...@ti.com wrote: So with OMAP added to multi platform kernel, the uImage no more contains a valid load address. With the uboot already supporting zImage, change the default boot command to bootz instead. Acked-by: Nishanth Menon n...@ti.com Signed-off-by: Sricharan R r.sricha...@ti.com Tested-by: Nishanth Menon n...@ti.com --- include/configs/omap4_common.h |4 ++-- include/configs/omap5_common.h |4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) Is there a reason why this patch does not have history? Amicalement, I had a minor change only in these two from the series. So reposted only these two with 'in-reply-to' threads. If this is not the right etiquette, then should it be update/appended in the original patch ? My question is not about the series but only about 5/5 which has no patch history after the commit message delimiter (---) whereas 4/5 has history. If 5/5 has a minor change in V4, then it should have a history log indicating which minor change it was. Regards, Sricharan Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2013.04-rc2 released
Hi Reinhard, On Fri, 5 Apr 2013 09:48:55 +0200, Pfau, Reinhard p...@gdsys.de wrote: But I'm not sure if I can submit a patch on the U-Boot ML which requires another patch (namely Che-Liang Chious TPM patch) which is not already in the main line. Yes you can, provided you clearly state the dependency, and ideally, provided you submit rebased patches whenever the patch(es) you depend upon get a new version submitted -- especially if rebasing is not trivial. If Che-Liangs work gets into 2013.04 it would be great and we would happily base on it when we publish our next changes. Note that even if Che-Liang's work only went in for 2013.07, that would not prevent your patches from going into it as well. Greetings, Reinhard Pfau. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Require guidance
hello, I have read about U - boot from Emebedded Linux Primer 2nd Edition. I want more in depth knowledge of U - boot. Can you please suggest me or give me the references through which I get more in depth knowledge about U - boot? Regards Rajdeep Vaghasia ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Require guidance
Hi Rajdeep, On Fri, 5 Apr 2013 12:27:02 +0530, Rajdeep Vaghasia rajdeep.vagha...@gmail.com wrote: hello, I have read about U - boot from Emebedded Linux Primer 2nd Edition. I want more in depth knowledge of U - boot. Can you please suggest me or give me the references through which I get more in depth knowledge about U - boot? I will suggest the trivial, but... you should start by reading the Denx U-Boot site (http://www.denx.de/wiki/U-Boot/WebHome) and then study the code for specific parts of U-Boot that you need deeper understanding in. Regards Rajdeep Vaghasia Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCHv2 0/2] Add initial support for AQUILA-CYGNUS
IGEP COM AQUILA and CYGNUS are two computer-on-module based on AM3354 and AM3352 processors. Both use SODIMM from factor and are designed for industrial range purpose. Changes since v1 (As Tom suggested) * Remove ATAGS and FDT as we have no support. * Remove CMD_EXT2 as is not required. * Remove fdt related stuff from environment. * Reduce the space dedicated to u-boot in MTDPARTS * Remove SPL_NET, we don't use this. Enric Balletbo i Serra (2): Add DDR3 support for IGEP COM AQUILA/CYGNUS. ARM: Add support for IGEP COM AQUILA/CYGNUS MAINTAINERS |1 + arch/arm/include/asm/arch-am33xx/ddr_defs.h | 17 ++ board/isee/igep0033/Makefile| 46 + board/isee/igep0033/board.c | 232 ++ board/isee/igep0033/board.h | 27 +++ board/isee/igep0033/mux.c | 89 + boards.cfg |1 + include/configs/igep0033.h | 284 +++ 8 files changed, 697 insertions(+) create mode 100644 board/isee/igep0033/Makefile create mode 100644 board/isee/igep0033/board.c create mode 100644 board/isee/igep0033/board.h create mode 100644 board/isee/igep0033/mux.c create mode 100644 include/configs/igep0033.h -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCHv2 1/2] Add DDR3 support for IGEP COM AQUILA/CYGNUS.
These boards uses Samsung K4B2G1646E-BIH9 a 2Gb E-die DDR3 SDRAM. Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com --- arch/arm/include/asm/arch-am33xx/ddr_defs.h | 17 + 1 file changed, 17 insertions(+) diff --git a/arch/arm/include/asm/arch-am33xx/ddr_defs.h b/arch/arm/include/asm/arch-am33xx/ddr_defs.h index 260cc34..4ebc557 100644 --- a/arch/arm/include/asm/arch-am33xx/ddr_defs.h +++ b/arch/arm/include/asm/arch-am33xx/ddr_defs.h @@ -117,6 +117,23 @@ #define MT41J512M8RH125_PHY_WR_DATA0x74 #define MT41J512M8RH125_IOCTRL_VALUE 0x18B +/* Samsung K4B2G1646E-BIH9 */ +#define K4B2G1646EBIH9_EMIF_READ_LATENCY 0x06 +#define K4B2G1646EBIH9_EMIF_TIM1 0x0888A39B +#define K4B2G1646EBIH9_EMIF_TIM2 0x2A04011A +#define K4B2G1646EBIH9_EMIF_TIM3 0x501F820F +#define K4B2G1646EBIH9_EMIF_SDCFG 0x61C24AB2 +#define K4B2G1646EBIH9_EMIF_SDREF 0x093B +#define K4B2G1646EBIH9_ZQ_CFG 0x50074BE4 +#define K4B2G1646EBIH9_DLL_LOCK_DIFF 0x1 +#define K4B2G1646EBIH9_RATIO 0x40 +#define K4B2G1646EBIH9_INVERT_CLKOUT 0x1 +#define K4B2G1646EBIH9_RD_DQS 0x3B +#define K4B2G1646EBIH9_WR_DQS 0x85 +#define K4B2G1646EBIH9_PHY_FIFO_WE 0x100 +#define K4B2G1646EBIH9_PHY_WR_DATA 0xC1 +#define K4B2G1646EBIH9_IOCTRL_VALUE0x18B + /** * Configure DMM */ -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCHv2 2/2] ARM: Add support for IGEP COM AQUILA/CYGNUS
The IGEP COM AQUILA and CYGNUS are industrial processors modules with
following highlights:
o AM3352/AM3354 Texas Instruments processor
o Cortex-A8 ARM CPU
o 3.3 volts Inputs / Outputs use industrial
o 256 MB DDR3 SDRAM / 128 Megabytes FLASH
o MicroSD card reader on-board
o Ethernet controller on-board
o JTAG debug connector available
o Designed for industrial range purposes
Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com
---
MAINTAINERS |1 +
board/isee/igep0033/Makefile | 46 +++
board/isee/igep0033/board.c | 232 ++
board/isee/igep0033/board.h | 27
board/isee/igep0033/mux.c| 89 +
boards.cfg |1 +
include/configs/igep0033.h | 284 ++
7 files changed, 680 insertions(+)
create mode 100644 board/isee/igep0033/Makefile
create mode 100644 board/isee/igep0033/board.c
create mode 100644 board/isee/igep0033/board.h
create mode 100644 board/isee/igep0033/mux.c
create mode 100644 include/configs/igep0033.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 1614b91..6cfcf83 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -607,6 +607,7 @@ Enric Balletbo i Serra eballe...@iseebcn.com
igep0020ARM ARMV7 (OMAP3xx SoC)
igep0030ARM ARMV7 (OMAP3xx SoC)
igep0032ARM ARMV7 (OMAP3xx SoC)
+ igep0033ARM ARMV7 (AM33xx Soc)
Eric Benard e...@eukrea.com
diff --git a/board/isee/igep0033/Makefile b/board/isee/igep0033/Makefile
new file mode 100644
index 000..54a4b75
--- /dev/null
+++ b/board/isee/igep0033/Makefile
@@ -0,0 +1,46 @@
+#
+# Makefile
+#
+# Copyright (C) 2013, ISEE 2007 SL - http://www.isee.biz/
+#
+# 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 as is WITHOUT ANY WARRANTY of any
+# kind, whether express or implied; without even the implied warranty
+# of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+ifdef CONFIG_SPL_BUILD
+COBJS := mux.o
+endif
+
+COBJS += board.o
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+ $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+clean:
+ rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+ rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/isee/igep0033/board.c b/board/isee/igep0033/board.c
new file mode 100644
index 000..d315516
--- /dev/null
+++ b/board/isee/igep0033/board.c
@@ -0,0 +1,232 @@
+/*
+ * Board functions for IGEP COM AQUILA/CYGNUS based boards
+ *
+ * Copyright (C) 2013, ISEE 2007 SL - http://www.isee.biz/
+ *
+ * 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.
+ */
+
+#include common.h
+#include errno.h
+#include spl.h
+#include asm/arch/cpu.h
+#include asm/arch/hardware.h
+#include asm/arch/omap.h
+#include asm/arch/ddr_defs.h
+#include asm/arch/clock.h
+#include asm/arch/gpio.h
+#include asm/arch/mmc_host_def.h
+#include asm/arch/sys_proto.h
+#include asm/io.h
+#include asm/emif.h
+#include asm/gpio.h
+#include i2c.h
+#include miiphy.h
+#include cpsw.h
+#include board.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static struct wd_timer *wdtimer = (struct wd_timer *)WDT_BASE;
+#ifdef CONFIG_SPL_BUILD
+static struct uart_sys *uart_base = (struct uart_sys *)DEFAULT_UART_BASE;
+#endif
+
+/* MII mode defines */
+#define RMII_MODE_ENABLE 0x4D
+
+static struct ctrl_dev *cdev = (struct ctrl_dev *)CTRL_DEVICE_BASE;
+
+/* UART Defines */
+#ifdef CONFIG_SPL_BUILD
+#define UART_RESET (0x1 1)
+#define UART_CLK_RUNNING_MASK 0x1
+#define UART_SMART_IDLE_EN (0x1 0x3)
+
+static void rtc32k_enable(void)
+{
+ struct rtc_regs *rtc = (struct rtc_regs *)RTC_BASE;
+
+ /*
+* Unlock the RTC's registers. For more details please see the
+* RTC_SS section of the TRM. In order to unlock we need to
+* write
Re: [U-Boot] [PATCH V4 5/5] ARM: OMAP4/5: Make bootz as the default boot command
On Friday 05 April 2013 01:38 PM, Albert ARIBAUD wrote: Hi Sricharan, On Fri, 5 Apr 2013 12:44:45 +0530, Sricharan R r.sricha...@ti.com wrote: Hi Albert, On Friday 05 April 2013 12:36 PM, Albert ARIBAUD wrote: Hi Sricharan, On Fri, 5 Apr 2013 11:24:34 +0530, Sricharan R r.sricha...@ti.com wrote: So with OMAP added to multi platform kernel, the uImage no more contains a valid load address. With the uboot already supporting zImage, change the default boot command to bootz instead. Acked-by: Nishanth Menon n...@ti.com Signed-off-by: Sricharan R r.sricha...@ti.com Tested-by: Nishanth Menon n...@ti.com --- include/configs/omap4_common.h |4 ++-- include/configs/omap5_common.h |4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) Is there a reason why this patch does not have history? Amicalement, I had a minor change only in these two from the series. So reposted only these two with 'in-reply-to' threads. If this is not the right etiquette, then should it be update/appended in the original patch ? My question is not about the series but only about 5/5 which has no patch history after the commit message delimiter (---) whereas 4/5 has history. If 5/5 has a minor change in V4, then it should have a history log indicating which minor change it was. ok. 5/5 was just rebase on 4/5. Will add it though. Sorry for the miss. Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Require guidance
On Fri, Apr 5, 2013 at 8:57 AM, Rajdeep Vaghasia rajdeep.vagha...@gmail.com wrote: hello, I have read about U - boot from Emebedded Linux Primer 2nd Edition. I want more in depth knowledge of U - boot. Can you please suggest me or give me the references through which I get more in depth knowledge about U - boot? Regards Rajdeep Vaghasia Hi Rajdeep, Since your question was rather generic, my answer will be general too. There are lots of valuable documentation inside the U-Boot code repository: $ git clone git://git.denx.de/u-boot.git $ find u-boot -name README You can also learn by studying the relevant part of the source code that may interest you. Best regards, Javier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/6] omap_gpmc: add support for hw assisted BCH8
Hello Andreas, I have the following problem when switching from nandecc hw hamming to nandecc hw bch8. Thomas ---8-- U-Boot 2013.04-rc2-6-g9abd2ec (Apr 05 2013 - 09:58:48) OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 mHz OMAP3 DevKit8000 + LPDDR/NAND I2C: ready DRAM: 128 MiB NAND: 128 MiB MMC: OMAP SD/MMC: 0 *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial ethaddr not set, using Die ID Die ID #1d820004040365f90100b017 Net: dm9000 Hit any key to stop autoboot: 0 OMAP3 DevKit8000 # nandecc hw bch8 Unsupported HW ECC algorithm OMAP3 DevKit8000 # nandecc hw bch8 Unsupported HW ECC algorithm OMAP3 DevKit8000 # nandecc hw hamming 1-bit hamming HW ECC selected OMAP3 DevKit8000 # nandecc sw SW ECC selected OMAP3 DevKit8000 # nandecc hw bch8 Unsupported HW ECC algorithm OMAP3 DevKit8000 # nandecc hw hamming 1-bit hamming HW ECC selected OMAP3 DevKit8000 # nandecc hw bch8 Unsupported HW ECC algorithm No ECC functions supplied; Hardware ECC not possible BUG: failure at nand_base.c:3014/nand_scan_tail()! BUG! resetting ... ---8-- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] exynos: move tzpc_init to armv7/exynos
Dear Minkyu,
Thanks for the review.
On 29 March 2013 08:27, Minkyu Kang mk7.k...@samsung.com wrote:
Dear Inderpal Singh,
On 15/03/13 15:23, Inderpal Singh wrote:
tzpc_init is common for all exynos5 boards, hence move it to
armv7/exynos so that all other boards can use it.
Also update the smdk5250 Makefile and config file.
Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
Acked-by: Chander Kashyap chander.kash...@linaro.org
---
arch/arm/cpu/armv7/exynos/Makefile |2 +-
arch/arm/cpu/armv7/exynos/tzpc_init.c | 48
+++
arch/arm/include/asm/arch-exynos/tzpc.h | 28 ++
board/samsung/smdk5250/Makefile |1 -
board/samsung/smdk5250/setup.h | 25
board/samsung/smdk5250/tzpc_init.c | 48
---
include/configs/exynos5250-dt.h |2 --
7 files changed, 77 insertions(+), 77 deletions(-)
create mode 100644 arch/arm/cpu/armv7/exynos/tzpc_init.c
delete mode 100644 board/samsung/smdk5250/tzpc_init.c
diff --git a/arch/arm/cpu/armv7/exynos/Makefile
b/arch/arm/cpu/armv7/exynos/Makefile
index 9119961..b9cf921 100644
--- a/arch/arm/cpu/armv7/exynos/Makefile
+++ b/arch/arm/cpu/armv7/exynos/Makefile
@@ -22,7 +22,7 @@ include $(TOPDIR)/config.mk
LIB = $(obj)lib$(SOC).o
-COBJS+= clock.o power.o soc.o system.o pinmux.o
+COBJS+= clock.o power.o soc.o system.o pinmux.o tzpc_init.o
patch looks good.
but, do we need to build tzpc always?
and please rename tzpc_init.c to just tzpc.c.
Yes, we need it always.
I have renamed the file to tzpc.c in the v3 version.
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS))
diff --git a/arch/arm/cpu/armv7/exynos/tzpc_init.c
b/arch/arm/cpu/armv7/exynos/tzpc_init.c
new file mode 100644
index 000..81adb4b
--- /dev/null
+++ b/arch/arm/cpu/armv7/exynos/tzpc_init.c
@@ -0,0 +1,48 @@
+/*
+ * Lowlevel setup for SMDK5250 board based on S5PC520
+ *
+ * Copyright (C) 2012 Samsung Electronics
+ *
+ * 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 asm/arch/tzpc.h
+#include asm/io.h
+
+/* Setting TZPC[TrustZone Protection Controller] */
+void tzpc_init(void)
+{
+ struct exynos_tzpc *tzpc;
+ unsigned int addr;
+
+ for (addr = TZPC0_BASE; addr = TZPC9_BASE; addr +=
TZPC_BASE_OFFSET) {
+ tzpc = (struct exynos_tzpc *)addr;
+
+ if (addr == TZPC0_BASE)
+ writel(R0SIZE, tzpc-r0size);
+
+ writel(DECPROTXSET, tzpc-decprot0set);
+ writel(DECPROTXSET, tzpc-decprot1set);
+
+ if (addr != TZPC9_BASE) {
+ writel(DECPROTXSET, tzpc-decprot2set);
+ writel(DECPROTXSET, tzpc-decprot3set);
+ }
+ }
+}
diff --git a/arch/arm/include/asm/arch-exynos/tzpc.h
b/arch/arm/include/asm/arch-exynos/tzpc.h
index c5eb4b1..050ad70 100644
--- a/arch/arm/include/asm/arch-exynos/tzpc.h
+++ b/arch/arm/include/asm/arch-exynos/tzpc.h
@@ -47,6 +47,34 @@ struct exynos_tzpc {
unsigned int pcellid2;
unsigned int pcellid3;
};
+
+/* TZPC : Register Offsets */
+#define TZPC0_BASE 0x1010
+#define TZPC1_BASE 0x1011
+#define TZPC2_BASE 0x1012
+#define TZPC3_BASE 0x1013
+#define TZPC4_BASE 0x1014
+#define TZPC5_BASE 0x1015
+#define TZPC6_BASE 0x1016
+#define TZPC7_BASE 0x1017
+#define TZPC8_BASE 0x1018
+#define TZPC9_BASE 0x1019
we did not need these defines.
please use samsung_get_base_tzpc().
Yes, good point.
Have removed these macros and used samsung_get_base tzpc in v3.
With Regards,
Inder
+
+#define TZPC_BASE_OFFSET 0x1
+
+/*
+ * TZPC Register Value :
+ * R0SIZE: 0x0 : Size of secured ram
+ */
+#define R0SIZE 0x0
+
+/*
+ * TZPC Decode Protection Register Value :
+ * DECPROTXSET: 0xFF : Set Decode region to
[U-Boot] [PATCH v3 0/3] Make tzpc initialization common for exynos4 and exynos5
The first patch moves the tzpc_init file from smdk5250 to armv7/exynos. The second makes tzpc common for exynos4 and exynos5. And the third makes necessary changes to exynos4 based origen and smdkv310 boards. The patchset has been tested on exynos4 based origen and exynos5 based Arndale board. Changes in v2: - removed uninitialised warning for start and end variables - corrected the SPL_TEXT_BASE for origen and smdkv310 - Added Chander's Acked-by Changes in v3: As per Minkyu: - renamed the file as tzpc.c - implemented the samsung_get_base_tzpc - removed the TZPCx_BASE macros and used samsung_get_base_tzpc Inderpal Singh (3): exynos: move tzpc_init to armv7/exynos exynos: update tzpc to make it common for exynos4 and exynos5 exynos: Update origen and smdkv310 to use common tzpc_init arch/arm/cpu/armv7/exynos/Makefile |2 +- arch/arm/cpu/armv7/exynos/tzpc.c| 57 + arch/arm/cpu/armv7/s5p-common/Makefile |2 ++ arch/arm/include/asm/arch-exynos/cpu.h |4 +++ arch/arm/include/asm/arch-exynos/tzpc.h | 20 +++ board/samsung/origen/lowlevel_init.S| 44 ++- board/samsung/origen/origen_setup.h | 25 - board/samsung/smdk5250/Makefile |1 - board/samsung/smdk5250/lowlevel_init.S |2 ++ board/samsung/smdk5250/setup.h | 25 - board/samsung/smdk5250/tzpc_init.c | 48 - board/samsung/smdkv310/lowlevel_init.S | 60 ++- include/configs/exynos5250-dt.h |2 -- include/configs/origen.h|2 ++ include/configs/smdkv310.h |2 ++ spl/Makefile|4 +++ 16 files changed, 98 insertions(+), 202 deletions(-) create mode 100644 arch/arm/cpu/armv7/exynos/tzpc.c delete mode 100644 board/samsung/smdk5250/tzpc_init.c -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/3] exynos: update tzpc to make it common for exynos4 and exynos5
This requires that cpu_is_exynos4/5 should be made available before tzpc_init.
Hence this patch also makes necessary changes to have cpu_info in spl and
invokes arch_cpu_init before tzpc_init in low_level_init.S for smdk5250.
Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
Acked-by: Chander Kashyap chander.kash...@linaro.org
---
arch/arm/cpu/armv7/exynos/tzpc.c| 23 ---
arch/arm/cpu/armv7/s5p-common/Makefile |2 ++
arch/arm/include/asm/arch-exynos/cpu.h |4
arch/arm/include/asm/arch-exynos/tzpc.h | 14 +++---
board/samsung/smdk5250/lowlevel_init.S |2 ++
spl/Makefile|4
6 files changed, 31 insertions(+), 18 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/tzpc.c b/arch/arm/cpu/armv7/exynos/tzpc.c
index 81adb4b..f5e8e9c 100644
--- a/arch/arm/cpu/armv7/exynos/tzpc.c
+++ b/arch/arm/cpu/armv7/exynos/tzpc.c
@@ -22,6 +22,7 @@
* MA 02111-1307 USA
*/
+#include common.h
#include asm/arch/tzpc.h
#include asm/io.h
@@ -29,20 +30,28 @@
void tzpc_init(void)
{
struct exynos_tzpc *tzpc;
- unsigned int addr;
+ unsigned int addr, start = 0, end = 0;
- for (addr = TZPC0_BASE; addr = TZPC9_BASE; addr += TZPC_BASE_OFFSET) {
+ start = samsung_get_base_tzpc();
+
+ if (cpu_is_exynos5())
+ end = start + ((EXYNOS5_NR_TZPC_BANKS - 1) * TZPC_BASE_OFFSET);
+ else if (cpu_is_exynos4())
+ end = start + ((EXYNOS4_NR_TZPC_BANKS - 1) * TZPC_BASE_OFFSET);
+
+ for (addr = start; addr = end; addr += TZPC_BASE_OFFSET) {
tzpc = (struct exynos_tzpc *)addr;
- if (addr == TZPC0_BASE)
+ if (addr == start)
writel(R0SIZE, tzpc-r0size);
writel(DECPROTXSET, tzpc-decprot0set);
writel(DECPROTXSET, tzpc-decprot1set);
- if (addr != TZPC9_BASE) {
- writel(DECPROTXSET, tzpc-decprot2set);
- writel(DECPROTXSET, tzpc-decprot3set);
- }
+ if (cpu_is_exynos5() (addr == end))
+ break;
+
+ writel(DECPROTXSET, tzpc-decprot2set);
+ writel(DECPROTXSET, tzpc-decprot3set);
}
}
diff --git a/arch/arm/cpu/armv7/s5p-common/Makefile
b/arch/arm/cpu/armv7/s5p-common/Makefile
index 1705399..0c38bd0 100644
--- a/arch/arm/cpu/armv7/s5p-common/Makefile
+++ b/arch/arm/cpu/armv7/s5p-common/Makefile
@@ -26,9 +26,11 @@ include $(TOPDIR)/config.mk
LIB= $(obj)libs5p-common.o
COBJS-y+= cpu_info.o
+ifndef CONFIG_SPL_BUILD
COBJS-y+= timer.o
COBJS-y+= sromc.o
COBJS-$(CONFIG_PWM)+= pwm.o
+endif
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS-y) $(SOBJS))
diff --git a/arch/arm/include/asm/arch-exynos/cpu.h
b/arch/arm/include/asm/arch-exynos/cpu.h
index f76e489..36b98c8 100644
--- a/arch/arm/include/asm/arch-exynos/cpu.h
+++ b/arch/arm/include/asm/arch-exynos/cpu.h
@@ -38,6 +38,7 @@
#define EXYNOS4_CLOCK_BASE 0x1003
#define EXYNOS4_SYSTIMER_BASE 0x1005
#define EXYNOS4_WATCHDOG_BASE 0x1006
+#define EXYNOS4_TZPC_BASE 0x1011
#define EXYNOS4_MIU_BASE 0x1060
#define EXYNOS4_DMC0_BASE 0x1040
#define EXYNOS4_DMC1_BASE 0x1041
@@ -74,6 +75,7 @@
#define EXYNOS4X12_CLOCK_BASE 0x1003
#define EXYNOS4X12_SYSTIMER_BASE 0x1005
#define EXYNOS4X12_WATCHDOG_BASE 0x1006
+#define EXYNOS4X12_TZPC_BASE 0x1011
#define EXYNOS4X12_DMC0_BASE 0x1060
#define EXYNOS4X12_DMC1_BASE 0x1061
#define EXYNOS4X12_GPIO_PART4_BASE 0x106E
@@ -107,6 +109,7 @@
#define EXYNOS5_POWER_BASE 0x1004
#define EXYNOS5_SWRESET0x10040400
#define EXYNOS5_SYSREG_BASE0x1005
+#define EXYNOS5_TZPC_BASE 0x1010
#define EXYNOS5_WATCHDOG_BASE 0x101D
#define EXYNOS5_ACE_SFR_BASE0x1083
#define EXYNOS5_DMC_PHY0_BASE 0x10C0
@@ -233,6 +236,7 @@ SAMSUNG_BASE(watchdog, WATCHDOG_BASE)
SAMSUNG_BASE(power, POWER_BASE)
SAMSUNG_BASE(spi, SPI_BASE)
SAMSUNG_BASE(spi_isp, SPI_ISP_BASE)
+SAMSUNG_BASE(tzpc, TZPC_BASE)
#endif
#endif /* _EXYNOS4_CPU_H */
diff --git a/arch/arm/include/asm/arch-exynos/tzpc.h
b/arch/arm/include/asm/arch-exynos/tzpc.h
index 050ad70..4d9c3a3 100644
--- a/arch/arm/include/asm/arch-exynos/tzpc.h
+++ b/arch/arm/include/asm/arch-exynos/tzpc.h
@@ -48,18 +48,10 @@ struct exynos_tzpc {
unsigned int pcellid3;
};
-/* TZPC : Register Offsets */
-#define TZPC0_BASE 0x1010
-#define TZPC1_BASE 0x1011
-#define TZPC2_BASE 0x1012
-#define TZPC3_BASE 0x1013
-#define TZPC4_BASE 0x1014
-#define
Re: [U-Boot] [PATCH v3 5/6] omap_gpmc: add support for hw assisted BCH8
Dear Thomas Weber, On 04/05/2013 10:13 AM, Thomas Weber wrote: Hello Andreas, I have the following problem when switching from nandecc hw hamming to nandecc hw bch8. Thomas ---8-- U-Boot 2013.04-rc2-6-g9abd2ec (Apr 05 2013 - 09:58:48) OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 mHz OMAP3 DevKit8000 + LPDDR/NAND I2C: ready DRAM: 128 MiB NAND: 128 MiB MMC: OMAP SD/MMC: 0 *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial ethaddr not set, using Die ID Die ID #1d820004040365f90100b017 Net: dm9000 Hit any key to stop autoboot: 0 OMAP3 DevKit8000 # nandecc hw bch8 Unsupported HW ECC algorithm OMAP3 DevKit8000 # nandecc hw bch8 Unsupported HW ECC algorithm OMAP3 DevKit8000 # nandecc hw hamming 1-bit hamming HW ECC selected OMAP3 DevKit8000 # nandecc sw SW ECC selected OMAP3 DevKit8000 # nandecc hw bch8 Unsupported HW ECC algorithm OMAP3 DevKit8000 # nandecc hw hamming 1-bit hamming HW ECC selected OMAP3 DevKit8000 # nandecc hw bch8 Unsupported HW ECC algorithm No ECC functions supplied; Hardware ECC not possible BUG: failure at nand_base.c:3014/nand_scan_tail()! BUG! You are right. I'v never tested the nandecc changes without the new CONFIG_NAND_OMAP_BCH8 config parameter, many thanks to you! I've a fix for that and will repost v4 ASAP. Best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/3] exynos: move tzpc_init to armv7/exynos
tzpc_init is common for all exynos5 boards, hence move it to
armv7/exynos so that all other boards can use it.
Also update the smdk5250 Makefile and config file.
Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
Acked-by: Chander Kashyap chander.kash...@linaro.org
---
arch/arm/cpu/armv7/exynos/Makefile |2 +-
arch/arm/cpu/armv7/exynos/tzpc.c| 48 +++
arch/arm/include/asm/arch-exynos/tzpc.h | 28 ++
board/samsung/smdk5250/Makefile |1 -
board/samsung/smdk5250/setup.h | 25
board/samsung/smdk5250/tzpc_init.c | 48 ---
include/configs/exynos5250-dt.h |2 --
7 files changed, 77 insertions(+), 77 deletions(-)
create mode 100644 arch/arm/cpu/armv7/exynos/tzpc.c
delete mode 100644 board/samsung/smdk5250/tzpc_init.c
diff --git a/arch/arm/cpu/armv7/exynos/Makefile
b/arch/arm/cpu/armv7/exynos/Makefile
index 9119961..b2f9152 100644
--- a/arch/arm/cpu/armv7/exynos/Makefile
+++ b/arch/arm/cpu/armv7/exynos/Makefile
@@ -22,7 +22,7 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(SOC).o
-COBJS += clock.o power.o soc.o system.o pinmux.o
+COBJS += clock.o power.o soc.o system.o pinmux.o tzpc.o
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS))
diff --git a/arch/arm/cpu/armv7/exynos/tzpc.c b/arch/arm/cpu/armv7/exynos/tzpc.c
new file mode 100644
index 000..81adb4b
--- /dev/null
+++ b/arch/arm/cpu/armv7/exynos/tzpc.c
@@ -0,0 +1,48 @@
+/*
+ * Lowlevel setup for SMDK5250 board based on S5PC520
+ *
+ * Copyright (C) 2012 Samsung Electronics
+ *
+ * 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 asm/arch/tzpc.h
+#include asm/io.h
+
+/* Setting TZPC[TrustZone Protection Controller] */
+void tzpc_init(void)
+{
+ struct exynos_tzpc *tzpc;
+ unsigned int addr;
+
+ for (addr = TZPC0_BASE; addr = TZPC9_BASE; addr += TZPC_BASE_OFFSET) {
+ tzpc = (struct exynos_tzpc *)addr;
+
+ if (addr == TZPC0_BASE)
+ writel(R0SIZE, tzpc-r0size);
+
+ writel(DECPROTXSET, tzpc-decprot0set);
+ writel(DECPROTXSET, tzpc-decprot1set);
+
+ if (addr != TZPC9_BASE) {
+ writel(DECPROTXSET, tzpc-decprot2set);
+ writel(DECPROTXSET, tzpc-decprot3set);
+ }
+ }
+}
diff --git a/arch/arm/include/asm/arch-exynos/tzpc.h
b/arch/arm/include/asm/arch-exynos/tzpc.h
index c5eb4b1..050ad70 100644
--- a/arch/arm/include/asm/arch-exynos/tzpc.h
+++ b/arch/arm/include/asm/arch-exynos/tzpc.h
@@ -47,6 +47,34 @@ struct exynos_tzpc {
unsigned int pcellid2;
unsigned int pcellid3;
};
+
+/* TZPC : Register Offsets */
+#define TZPC0_BASE 0x1010
+#define TZPC1_BASE 0x1011
+#define TZPC2_BASE 0x1012
+#define TZPC3_BASE 0x1013
+#define TZPC4_BASE 0x1014
+#define TZPC5_BASE 0x1015
+#define TZPC6_BASE 0x1016
+#define TZPC7_BASE 0x1017
+#define TZPC8_BASE 0x1018
+#define TZPC9_BASE 0x1019
+
+#define TZPC_BASE_OFFSET 0x1
+
+/*
+ * TZPC Register Value :
+ * R0SIZE: 0x0 : Size of secured ram
+ */
+#define R0SIZE 0x0
+
+/*
+ * TZPC Decode Protection Register Value :
+ * DECPROTXSET: 0xFF : Set Decode region to non-secure
+ */
+#define DECPROTXSET0xFF
+void tzpc_init(void);
+
#endif
#endif
diff --git a/board/samsung/smdk5250/Makefile b/board/samsung/smdk5250/Makefile
index 47c6a5a..d079f4c 100644
--- a/board/samsung/smdk5250/Makefile
+++ b/board/samsung/smdk5250/Makefile
@@ -28,7 +28,6 @@ SOBJS := lowlevel_init.o
COBJS := clock_init.o
COBJS += dmc_common.o dmc_init_ddr3.o
-COBJS += tzpc_init.o
COBJS += smdk5250_spl.o
ifndef CONFIG_SPL_BUILD
diff --git a/board/samsung/smdk5250/setup.h b/board/samsung/smdk5250/setup.h
index 34d8bc3..eb91d13 100644
--- a/board/samsung/smdk5250/setup.h
+++ b/board/samsung/smdk5250/setup.h
@@ -28,18 +28,6 @@
#include config.h
#include asm/arch/dmc.h
-/* TZPC : Register Offsets */
[U-Boot] [PATCH v3 3/3] exynos: Update origen and smdkv310 to use common tzpc_init
Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
Acked-by: Chander Kashyap chander.kash...@linaro.org
---
board/samsung/origen/lowlevel_init.S | 44 ++-
board/samsung/origen/origen_setup.h| 25 -
board/samsung/smdkv310/lowlevel_init.S | 60 ++--
include/configs/origen.h |2 ++
include/configs/smdkv310.h |2 ++
5 files changed, 8 insertions(+), 125 deletions(-)
diff --git a/board/samsung/origen/lowlevel_init.S
b/board/samsung/origen/lowlevel_init.S
index 9daa0da..be9d418 100644
--- a/board/samsung/origen/lowlevel_init.S
+++ b/board/samsung/origen/lowlevel_init.S
@@ -87,12 +87,14 @@ lowlevel_init:
1:
/* for UART */
bl uart_asm_init
+ bl arch_cpu_init
bl tzpc_init
pop {pc}
wakeup_reset:
bl system_clock_init
bl mem_ctrl_asm_init
+ bl arch_cpu_init
bl tzpc_init
exit_wakeup:
@@ -353,45 +355,3 @@ uart_asm_init:
nop
nop
-/* Setting TZPC[TrustZone Protection Controller] */
-tzpc_init:
- ldr r0, =TZPC0_BASE
- mov r1, #R0SIZE
- str r1, [r0]
- mov r1, #DECPROTXSET
- str r1, [r0, #TZPC_DECPROT0SET_OFFSET]
- str r1, [r0, #TZPC_DECPROT1SET_OFFSET]
- str r1, [r0, #TZPC_DECPROT2SET_OFFSET]
- str r1, [r0, #TZPC_DECPROT3SET_OFFSET]
-
- ldr r0, =TZPC1_BASE
- str r1, [r0, #TZPC_DECPROT0SET_OFFSET]
- str r1, [r0, #TZPC_DECPROT1SET_OFFSET]
- str r1, [r0, #TZPC_DECPROT2SET_OFFSET]
- str r1, [r0, #TZPC_DECPROT3SET_OFFSET]
-
- ldr r0, =TZPC2_BASE
- str r1, [r0, #TZPC_DECPROT0SET_OFFSET]
- str r1, [r0, #TZPC_DECPROT1SET_OFFSET]
- str r1, [r0, #TZPC_DECPROT2SET_OFFSET]
- str r1, [r0, #TZPC_DECPROT3SET_OFFSET]
-
- ldr r0, =TZPC3_BASE
- str r1, [r0, #TZPC_DECPROT0SET_OFFSET]
- str r1, [r0, #TZPC_DECPROT1SET_OFFSET]
- str r1, [r0, #TZPC_DECPROT2SET_OFFSET]
- str r1, [r0, #TZPC_DECPROT3SET_OFFSET]
-
- ldr r0, =TZPC4_BASE
- str r1, [r0, #TZPC_DECPROT0SET_OFFSET]
- str r1, [r0, #TZPC_DECPROT1SET_OFFSET]
- str r1, [r0, #TZPC_DECPROT2SET_OFFSET]
- str r1, [r0, #TZPC_DECPROT3SET_OFFSET]
-
- ldr r0, =TZPC5_BASE
- str r1, [r0, #TZPC_DECPROT0SET_OFFSET]
- str r1, [r0, #TZPC_DECPROT1SET_OFFSET]
- str r1, [r0, #TZPC_DECPROT2SET_OFFSET]
- str r1, [r0, #TZPC_DECPROT3SET_OFFSET]
-
- mov pc, lr
diff --git a/board/samsung/origen/origen_setup.h
b/board/samsung/origen/origen_setup.h
index 930b948..926a4cc 100644
--- a/board/samsung/origen/origen_setup.h
+++ b/board/samsung/origen/origen_setup.h
@@ -121,19 +121,6 @@
#define UBRDIV_OFFSET 0x28
#define UFRACVAL_OFFSET0x2C
-/* TZPC : Register Offsets */
-#define TZPC0_BASE 0x1011
-#define TZPC1_BASE 0x1012
-#define TZPC2_BASE 0x1013
-#define TZPC3_BASE 0x1014
-#define TZPC4_BASE 0x1015
-#define TZPC5_BASE 0x1016
-
-#define TZPC_DECPROT0SET_OFFSET0x804
-#define TZPC_DECPROT1SET_OFFSET0x810
-#define TZPC_DECPROT2SET_OFFSET0x81C
-#define TZPC_DECPROT3SET_OFFSET0x828
-
/* CLK_SRC_CPU */
#define MUX_HPM_SEL_MOUTAPLL 0x0
#define MUX_HPM_SEL_SCLKMPLL 0x1
@@ -617,16 +604,4 @@
* UBRFRACVAL = 800MHz*10/(115200*16) -10))%10)*16/10)
*/
#define UFRACVAL_VAL 0x4
-
-/*
- * TZPC Register Value :
- * R0SIZE: 0x0 : Size of secured ram
- */
-#define R0SIZE 0x0
-
-/*
- * TZPC Decode Protection Register Value :
- * DECPROTXSET: 0xFF : Set Decode region to non-secure
- */
-#define DECPROTXSET0xFF
#endif
diff --git a/board/samsung/smdkv310/lowlevel_init.S
b/board/samsung/smdkv310/lowlevel_init.S
index 7a1ea98..31e0e2e 100644
--- a/board/samsung/smdkv310/lowlevel_init.S
+++ b/board/samsung/smdkv310/lowlevel_init.S
@@ -85,12 +85,14 @@ lowlevel_init:
1:
/* for UART */
bl uart_asm_init
+ bl arch_cpu_init
bl tzpc_init
pop {pc}
wakeup_reset:
bl system_clock_init
bl mem_ctrl_asm_init
+ bl arch_cpu_init
bl tzpc_init
exit_wakeup:
@@ -410,61 +412,3 @@ uart_asm_init:
nop
nop
nop
-
-/* Setting TZPC[TrustZone Protection Controller] */
-tzpc_init:
- ldr r0, =0x1011
- mov r1, #0x0
- str r1, [r0]
- mov r1, #0xff
- str r1, [r0, #0x0804]
- str r1, [r0, #0x0810]
- str r1, [r0, #0x081C]
- str r1, [r0, #0x0828]
-
- ldr r0, =0x1012
- mov r1, #0x0
- str r1, [r0]
- mov r1, #0xff
- str r1, [r0, #0x0804]
- str r1, [r0, #0x0810]
- str
[U-Boot] [PATCH V4 4/5] ARM: OMAP4/5: Change the default boot command to work with device tree
Now with kernel moving to all device tree, the default
boot command is changed to pass the device tree blob.
Also, adding the findfdt command to get the dt-blob
based on the board.
Thanks to Tom Rini tr...@ti.com for suggesting this.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[V4] Added environment variables bootdir, bootpart
and added loadimage, loadfdt commands as per
Tom's suggestion.
include/configs/omap4_common.h | 22 +++---
include/configs/omap5_common.h | 20 +---
2 files changed, 36 insertions(+), 6 deletions(-)
diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index 6ae6a0f..7af3989 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -138,6 +138,10 @@
*/
#define CONFIG_BOOTDELAY 3
+#define CONFIG_ENV_VARS_UBOOT_CONFIG
+#define CONFIG_CMD_FS_GENERIC
+#define CONFIG_CMD_EXT2
+#define CONFIG_CMD_EXT4
#define CONFIG_ENV_OVERWRITE
@@ -145,6 +149,10 @@
loadaddr=0x8200\0 \
console=ttyO2,115200n8\0 \
fdt_high=0x\0 \
+ fdtaddr=0x80f8\0 \
+ bootpart=0:2\0 \
+ bootdir=/boot\0 \
+ bootfile=uImage\0 \
usbtty=cdc_acm\0 \
vram=16M\0 \
mmcdev=0\0 \
@@ -160,12 +168,19 @@
loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0 \
importbootenv=echo Importing environment from mmc${mmcdev} ...; \
env import -t ${loadaddr} ${filesize}\0 \
- loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0 \
+ loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0 \
mmcboot=echo Booting from mmc${mmcdev} ...; \
run mmcargs; \
- bootm ${loadaddr}\0 \
+ bootm ${loadaddr} - ${fdtaddr}\0 \
+ findfdt=\
+ if test $board_name = sdp4430; then \
+ setenv fdtfile omap4-sdp.dtb; fi; \
+ if test $board_name = panda; then \
+ setenv fdtfile omap4-panda-es.dtb; fi\0 \
+ loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0 \
#define CONFIG_BOOTCOMMAND \
+ run findfdt; \
mmc dev ${mmcdev}; if mmc rescan; then \
echo SD/MMC found on device ${mmcdev}; \
if run loadbootscript; then \
@@ -179,7 +194,8 @@
run uenvcmd; \
fi; \
fi; \
- if run loaduimage; then \
+ if run loadimage; then \
+ run loadfdt; \
run mmcboot; \
fi; \
fi
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index 6d7aa7b..6fb0253 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -137,6 +137,10 @@
*/
#define CONFIG_BOOTDELAY 3
+#define CONFIG_ENV_VARS_UBOOT_CONFIG
+#define CONFIG_CMD_FS_GENERIC
+#define CONFIG_CMD_EXT2
+#define CONFIG_CMD_EXT4
#define CONFIG_ENV_OVERWRITE
@@ -144,6 +148,10 @@
loadaddr=0x8200\0 \
console=ttyO2,115200n8\0 \
fdt_high=0x\0 \
+ fdtaddr=0x80f8\0 \
+ bootpart=0:2\0 \
+ bootdir=/boot\0 \
+ bootfile=uImage\0 \
usbtty=cdc_acm\0 \
vram=16M\0 \
mmcdev=0\0 \
@@ -159,12 +167,17 @@
loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0 \
importbootenv=echo Importing environment from mmc${mmcdev} ...; \
env import -t ${loadaddr} ${filesize}\0 \
- loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0 \
+ loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0 \
mmcboot=echo Booting from mmc${mmcdev} ...; \
run mmcargs; \
- bootm ${loadaddr}\0 \
+ bootm ${loadaddr} - ${fdtaddr}\0 \
+ findfdt=\
+ if test $board_name = omap5_uevm; then \
+ setenv fdtfile omap5-uevm.dtb; fi;\0 \
+ loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile};\0 \
#define CONFIG_BOOTCOMMAND \
+ run findfdt; \
mmc dev ${mmcdev}; if mmc rescan; then \
if run loadbootscript; then \
run bootscript; \
@@ -177,7 +190,8 @@
run uenvcmd; \
fi; \
fi; \
- if run loaduimage; then \
+ if run loadimage; then \
+ run loadfdt; \
run mmcboot; \
fi; \
fi
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 5/5] ARM: OMAP4/5: Make bootz as the default boot command
So with OMAP added to multi platform kernel,
the uImage no more contains a valid load address.
With the uboot already supporting zImage,
change the default boot command to bootz
instead.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Tested-by: Nishanth Menon n...@ti.com
---
[V4] Just rebased on top of 4/5 th patch.
include/configs/omap4_common.h |4 ++--
include/configs/omap5_common.h |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index 7af3989..1fd3097 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -152,7 +152,7 @@
fdtaddr=0x80f8\0 \
bootpart=0:2\0 \
bootdir=/boot\0 \
- bootfile=uImage\0 \
+ bootfile=zImage\0 \
usbtty=cdc_acm\0 \
vram=16M\0 \
mmcdev=0\0 \
@@ -171,7 +171,7 @@
loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0 \
mmcboot=echo Booting from mmc${mmcdev} ...; \
run mmcargs; \
- bootm ${loadaddr} - ${fdtaddr}\0 \
+ bootz ${loadaddr} - ${fdtaddr}\0 \
findfdt=\
if test $board_name = sdp4430; then \
setenv fdtfile omap4-sdp.dtb; fi; \
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index 6fb0253..da0ead9 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -151,7 +151,7 @@
fdtaddr=0x80f8\0 \
bootpart=0:2\0 \
bootdir=/boot\0 \
- bootfile=uImage\0 \
+ bootfile=zImage\0 \
usbtty=cdc_acm\0 \
vram=16M\0 \
mmcdev=0\0 \
@@ -170,7 +170,7 @@
loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0 \
mmcboot=echo Booting from mmc${mmcdev} ...; \
run mmcargs; \
- bootm ${loadaddr} - ${fdtaddr}\0 \
+ bootz ${loadaddr} - ${fdtaddr}\0 \
findfdt=\
if test $board_name = omap5_uevm; then \
setenv fdtfile omap5-uevm.dtb; fi;\0 \
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 4/6] omap_gpmc: change nandecc command
With uppcoming BCH support on OMAP devices we need to decide between differnt
algorithms when switching the ECC engine. Currently we support 1-bit hammign
and 8-bit BCH on HW backend.
In order to switch between differnet ECC algorithms we need to change the
interface of omap_nand_switch_ecc() also.
Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com
Cc: Tom Rini tr...@ti.com
Cc: Thomas Weber thomas.weber.li...@googlemail.com
---
new in v2
since v2:
* use void omap_nand_switch_ecc(bool, uint32_t)
* print warning if unknown HW ecc strengs choosen
* fix alignment in help test
since v3:
* reset ecc.mode to NAND_ECC_NONE to prevent a BUG() on wrong eccstrength
input to changed omap_nand_switch_ecc();
With this change a user has the chance to switch back to another ECC mode
via nandecc command.
Many thanks to Thomas Weber for reporting this.
arch/arm/cpu/armv7/omap3/board.c | 31 ++
arch/arm/include/asm/arch-am33xx/sys_proto.h |2 +-
arch/arm/include/asm/arch-omap3/sys_proto.h |2 +-
drivers/mtd/nand/omap_gpmc.c | 57 ++
4 files changed, 56 insertions(+), 36 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap3/board.c b/arch/arm/cpu/armv7/omap3/board.c
index c6d9a42..b72fadc 100644
--- a/arch/arm/cpu/armv7/omap3/board.c
+++ b/arch/arm/cpu/armv7/omap3/board.c
@@ -328,14 +328,25 @@ void abort(void)
*/
static int do_switch_ecc(cmd_tbl_t * cmdtp, int flag, int argc, char * const
argv[])
{
- if (argc != 2)
+ if (argc 2 || argc 3)
goto usage;
- if (strncmp(argv[1], hw, 2) == 0)
- omap_nand_switch_ecc(1);
- else if (strncmp(argv[1], sw, 2) == 0)
- omap_nand_switch_ecc(0);
- else
+
+ if (strncmp(argv[1], hw, 2) == 0) {
+ if (argc == 2) {
+ omap_nand_switch_ecc(1, 1);
+ } else {
+ if (strncmp(argv[2], hamming, 7) == 0)
+ omap_nand_switch_ecc(1, 1);
+ else if (strncmp(argv[2], bch8, 4) == 0)
+ omap_nand_switch_ecc(1, 8);
+ else
+ goto usage;
+ }
+ } else if (strncmp(argv[1], sw, 2) == 0) {
+ omap_nand_switch_ecc(0, 0);
+ } else {
goto usage;
+ }
return 0;
@@ -345,9 +356,13 @@ usage:
}
U_BOOT_CMD(
- nandecc, 2, 1, do_switch_ecc,
+ nandecc, 3, 1, do_switch_ecc,
switch OMAP3 NAND ECC calculation algorithm,
- [hw/sw] - Switch between NAND hardware (hw) or software (sw) ecc
algorithm
+ hw [hamming|bch8] - Switch between NAND hardware 1-bit hamming and
+8-bit BCH\n
+ ecc calculation (second parameter may
+be omitted).\n
+ nandecc sw - Switch to NAND software ecc algorithm.
);
#endif /* CONFIG_NAND_OMAP_GPMC !CONFIG_SPL_BUILD */
diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h
b/arch/arm/include/asm/arch-am33xx/sys_proto.h
index 0910a94..c913b5f 100644
--- a/arch/arm/include/asm/arch-am33xx/sys_proto.h
+++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h
@@ -39,5 +39,5 @@ struct gpmc_cs;
void gpmc_init(void);
void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs *cs, u32
base,
u32 size);
-void omap_nand_switch_ecc(int);
+void omap_nand_switch_ecc(uint32_t, uint32_t);
#endif
diff --git a/arch/arm/include/asm/arch-omap3/sys_proto.h
b/arch/arm/include/asm/arch-omap3/sys_proto.h
index d60f2ad..dae1312 100644
--- a/arch/arm/include/asm/arch-omap3/sys_proto.h
+++ b/arch/arm/include/asm/arch-omap3/sys_proto.h
@@ -78,7 +78,7 @@ void sr32(void *, u32, u32, u32);
u32 wait_on_value(u32, u32, void *, u32);
void sdelay(unsigned long);
void make_cs1_contiguous(void);
-void omap_nand_switch_ecc(int);
+void omap_nand_switch_ecc(uint32_t, uint32_t);
void power_init_r(void);
void dieid_num_r(void);
void do_omap3_emu_romcode_call(u32 service_id, u32 parameters);
diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c
index c7d4999..3468c78 100644
--- a/drivers/mtd/nand/omap_gpmc.c
+++ b/drivers/mtd/nand/omap_gpmc.c
@@ -604,13 +604,14 @@ static int omap_read_page_bch(struct mtd_info *mtd,
struct nand_chip *chip,
#ifndef CONFIG_SPL_BUILD
/*
- * omap_nand_switch_ecc - switch the ECC operation b/w h/w ecc and s/w ecc.
- * The default is to come up on s/w ecc
- *
- * @hardware - 1 -switch to h/w ecc, 0 - s/w ecc
+ * omap_nand_switch_ecc - switch the ECC operation between different engines
+ * (h/w and s/w) and different algorithms (hamming and BCHx)
*
+ * @hardware - true if one of the HW engines should be used
+ * @eccstrength- the number of bits that could be corrected
+ *
Re: [U-Boot] [PATCH v2] BUGFIX: arm: data abort in get_bad_stack_swi
Hi Albert
(04/05/2013 04:04 PM), Albert ARIBAUD wrote:
Hi Tetsuyuki,
On Fri, 5 Apr 2013 10:45:14 +0900, Tetsuyuki Kobayashi
k...@kmckk.co.jp wrote:
When swi instruction is executed, it is expected to get message
software interrupt in console and dump registers and reboot, as
do_software_interrupt() in arch/arm/lib/interrupts.c.
But, actually it causes data abort accessing wrong address in
get_bad_stack_swi
macro in arch/arm/cpu/v7/start.S.
This patch fixes this problem.
The same mistake in arch/arm/cpu/{arm1136,arm1176,pxa}/start.S.
Signed-off-by: Tetsuyuki Kobayashi k...@kmckk.co.jp
---
Changes for v2:
- added arch/arm/cpu/{arm1136,arm1176,pxa}/start.S
(But not tested, because I don't have test boards of them)
arm/arm/cpu/armv7/start.S is tested on KZM-A9-GT board.
arch/arm/cpu/arm1136/start.S |2 +-
arch/arm/cpu/arm1176/start.S |2 +-
arch/arm/cpu/armv7/start.S |2 +-
arch/arm/cpu/pxa/start.S |2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/cpu/arm1136/start.S b/arch/arm/cpu/arm1136/start.S
index eba2324..7b9db2b 100644
--- a/arch/arm/cpu/arm1136/start.S
+++ b/arch/arm/cpu/arm1136/start.S
@@ -392,7 +392,7 @@ cpu_init_crit:
str r0, [r13] @ save R0's value.
ldr r0, IRQ_STACK_START_IN @ get data regions start
str lr, [r0]@ save caller lr in position 0
of saved stack
-mrs r0, spsr@ get the spsr
+mrs lr, spsr@ get the spsr
str lr, [r0, #4]@ save spsr in position 1 of
saved stack
ldr r0, [r13] @ restore r0
add r13, r13, #4@ pop stack entry
Sorry for not checking this in V1, but I see that get_bad_stack_swi does
not preserve lr, so when bad_save_user_regs is expanded, it will save
the wrong value for lr. You need to restore lr from [r0] before you
restore r0 from [r13].
Thank you, I was not aware that.
The dumped lr value was wrong.
I am going to post V3 patch for all 4 files.
diff --git a/arch/arm/cpu/arm1176/start.S b/arch/arm/cpu/arm1176/start.S
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
diff --git a/arch/arm/cpu/pxa/start.S b/arch/arm/cpu/pxa/start.S
Ditto for all four files, of course.
Amicalement,
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] BUGFIX: arm: data abort in get_bad_stack_swi
When swi instruction is executed, it is expected to get message
software interrupt in console and dump registers and reboot, as
do_software_interrupt() in arch/arm/lib/interrupts.c.
But, actually it causes data abort accessing wrong address in get_bad_stack_swi
macro in arch/arm/cpu/v7/start.S.
This patch fixes this problem.
The same mistake in arch/arm/cpu/{arm1136,arm1176,pxa}/start.S.
Signed-off-by: Tetsuyuki Kobayashi k...@kmckk.co.jp
---
Changes for v2:
- added arch/arm/cpu/{arm1136,arm1176,pxa}/start.S
Changes for v3:
- restore lr register in all 4 files.
Only arm/arm/cpu/armv7/start.S is tested on KZM-A9-GT board.
arch/arm/cpu/arm1136/start.S |3 ++-
arch/arm/cpu/arm1176/start.S |4 +++-
arch/arm/cpu/armv7/start.S |3 ++-
arch/arm/cpu/pxa/start.S |3 ++-
4 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/arm/cpu/arm1136/start.S b/arch/arm/cpu/arm1136/start.S
index eba2324..bccfdbf 100644
--- a/arch/arm/cpu/arm1136/start.S
+++ b/arch/arm/cpu/arm1136/start.S
@@ -392,8 +392,9 @@ cpu_init_crit:
str r0, [r13] @ save R0's value.
ldr r0, IRQ_STACK_START_IN @ get data regions start
str lr, [r0]@ save caller lr in position 0
of saved stack
- mrs r0, spsr@ get the spsr
+ mrs lr, spsr@ get the spsr
str lr, [r0, #4]@ save spsr in position 1 of
saved stack
+ ldr lr, [r0]@ restore lr
ldr r0, [r13] @ restore r0
add r13, r13, #4@ pop stack entry
.endm
diff --git a/arch/arm/cpu/arm1176/start.S b/arch/arm/cpu/arm1176/start.S
index 3c291fb..694f79d 100644
--- a/arch/arm/cpu/arm1176/start.S
+++ b/arch/arm/cpu/arm1176/start.S
@@ -480,9 +480,11 @@ phy_last_jump:
/* save caller lr in position 0 of saved stack */
str lr, [r0]
/* get the spsr */
- mrs r0, spsr
+ mrs lr, spsr
/* save spsr in position 1 of saved stack */
str lr, [r0, #4]
+ /* restore lr */
+ ldr lr, [r0]
/* restore r0 */
ldr r0, [r13]
/* pop stack entry */
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index 36a4c3c..e5e157b 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -465,9 +465,10 @@ ENDPROC(cpu_init_crit)
@ spots for abort stack
str lr, [r0]@ save caller lr in position 0
@ of saved stack
- mrs r0, spsr@ get the spsr
+ mrs lr, spsr@ get the spsr
str lr, [r0, #4]@ save spsr in position 1 of
@ saved stack
+ ldr lr, [r0]@ restore lr
ldr r0, [r13] @ restore r0
add r13, r13, #4@ pop stack entry
.endm
diff --git a/arch/arm/cpu/pxa/start.S b/arch/arm/cpu/pxa/start.S
index 456a783..9c525e8 100644
--- a/arch/arm/cpu/pxa/start.S
+++ b/arch/arm/cpu/pxa/start.S
@@ -387,8 +387,9 @@ cpu_init_crit:
str r0, [r13] @ save R0's value.
ldr r0, IRQ_STACK_START_IN @ get data regions start
str lr, [r0]@ save caller lr in position 0
of saved stack
- mrs r0, spsr@ get the spsr
+ mrs lr, spsr@ get the spsr
str lr, [r0, #4]@ save spsr in position 1 of
saved stack
+ ldr lr, [r0]@ restore lr
ldr r0, [r13] @ restore r0
add r13, r13, #4@ pop stack entry
.endm
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] env: fix potential stack overflow in environment functions
Dear Tom Rini, In message 20130403153014.GF7035@bill-the-cat you wrote: On Fri, Mar 22, 2013 at 11:26:21AM -, Rob Herring wrote: From: Rob Herring rob.herr...@calxeda.com Most of the various environment functions create CONFIG_ENV_SIZE buffers on the stack. At least on ARM and PPC which have 4KB stacks, this can overflow the stack if we have large environment sizes. So move all the buffers off the stack to static buffers. Signed-off-by: Rob Herring rob.herr...@calxeda.com Applied to u-boot/master, thanks! I'm unhappy about this. The patch makes no sense to me, and in addition it causes build warnings for some boards (PPC: debris, kvme080): env_nvram.c: In function 'env_init': env_nvram.c:124:16: warning: pointer targets in initialization differ in signedness [-Wpointer-sign] I tried to explain this before, but eventually you missed my remarks, so here they go again: * The functiuons we are talking about run after relocation, i. e. when we have a full standard C runtime environment. In this situation we can assume to have virtually unlimited stack space available - actually limited only by the RAM size. * Moving the buffers from the stack into BSS is bad, as this way we permanently lose the space for these buffers, nut we need them only for a very short time, so we are wasting lots of memory. * If some board have for some reasons unreasonable small stack sizes, these need to be fixed. Rob refers to LMB stack space in his previous message - if there are indeed such small stack sizes used there, this is a problem that needs to be fixed elsewhere, but NOT by adapting all the rest of the U-Boot code to an artifical small stack. I hereby request to revert that commit. Best regards, Wolfgang Denk -- 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: w...@denx.de How long does it take a DEC field service engineer to change a lightbulb? It depends on how many bad ones he brought with him. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Interrupt handling ARM cortex A9 ( Armv7) in u-boot
Hi all. I am working on registering a gpio interrupt in the u-boot. I am using the a Armv7 ( Arm cortex A9) platform. My question is about registering a IRQ handler for the interrupt. I tried writing the function pointer of my IRQ directly to Interrupt vector table ( which is at 0x in my case and my interrupt id is 56 and i calculated the address accordingly). What does thie CONFIG_USE_IRQ do and what is the purpose of the do_irq function and in short how can i register a IRQ for this particular HW interrupt. I am used to the higher level api's in the linux kernel and the lack of those api's in u-boot is giving a hard time for me ;). So kindly help me with this question Cheers, S -- View this message in context: http://u-boot.10912.n7.nabble.com/Interrupt-handling-ARM-cortex-A9-Armv7-in-u-boot-tp151648.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6 V4] Sound: MAX98095: Add the driver for codec
Hi all, I am working on ODROID PC Exynos-4 Board (Cortex-A9). In that board i am working MAX98089 Audio codec. How to initialize this audio codec and how to test this one in UBOOT level. Can you please help me on this. Thanks Prem V. On Sat, Feb 16, 2013 at 9:51 AM, Simon Glass s...@chromium.org wrote: On Thu, Feb 14, 2013 at 9:46 PM, Rajeshwari Shinde rajeshwar...@samsung.com wrote: This patch adds the driver for codec MAX98095 required by Snow Board Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/6] omap_gpmc: add support for hw assisted BCH8
Hello Andreas, On 04/03/2013 04:50 PM, Andreas Bießmann wrote: The kernel states: ---8--- The OMAP3 GPMC hardware BCH engine computes remainder polynomials, it does not provide automatic error location and correction: this step is implemented using the BCH library. ---8--- And we do so in u-boot. This implementation uses the same layout for BCH8 but it is fix. The current provided layout does only work with 64 Byte OOB. Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com Cc: Tom Rini tr...@ti.com Cc: Ilya Yanok ilya.ya...@cogentembedded.com Cc: Scott Wood scottw...@freescale.com Cc: Mansoor Ahamed mansoor.aha...@ti.com --- since v1: * cleanups (remove debug stuff) * make checkpach clean (still 2 warnings which I will not fix) * merge some code with the AM33XX implementation since v2: * fix all checkpatch warnings * add more comments * add NAND section in README.omap3 doc/README.omap3 | 19 +++ drivers/mtd/nand/omap_gpmc.c | 367 +++--- lib/Makefile |2 +- 3 files changed, 296 insertions(+), 92 deletions(-) diff --git a/doc/README.omap3 b/doc/README.omap3 index 0a37de0..56aca8e 100644 --- a/doc/README.omap3 +++ b/doc/README.omap3 @@ -145,6 +145,25 @@ int omap3_dma_wait_for_transfer(uint32_t chan) int omap3_dma_get_revision(uint32_t *minor, uint32_t *major) Read silicon Revision of the DMA module +NAND + + +Ther eare some OMAP3 devices out ther with NAND attached. Due to the fact that ther - there +OMAP3 ROM code can only handle 1-bit hamming ECC for accessing first page +(place where SPL lives) we require this setup for u-boot at least when reading +the second progam within SPL. A lot of newer NAND chips however require more +than 1-bit ECC for the pages, some can live with 1-bit for the first page. To +handle this we can switch to another ECC algorithm after reading the payload +within SPL. + +BCH8 + + +To enable hardware assisted BCH8 (8-bit BCH [Bose, Chaudhuri, Hocquenghem]) on +OMAP3 devices we can use the BCH library in lib/bch.c. To do so add CONFIG_BCH +to enable the library and CONFIG_NAND_OMAP_BCH8 to your board config. +The NAND OOB layout is the same as in linux kernel, if the linux kernel BCH8 +implementation for OMAP3 works for you so the u-boot version should also. Acknowledgements Thomas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 4/6] omap_gpmc: change nandecc command
Hello Andreas,
this patch fixes the reported BUG().
The output is now:
-8-
OMAP3 DevKit8000 # nandecc hw hamming
1-bit hamming HW ECC selected
OMAP3 DevKit8000 # nandecc hw bch8
Unsupported HW ECC algorithm
NAND_ECC_NONE selected by board driver. This is not recommended !!
OMAP3 DevKit8000 #
-8-
Thomas
On 04/05/2013 11:52 AM, Andreas Bießmann wrote:
With uppcoming BCH support on OMAP devices we need to decide between differnt
algorithms when switching the ECC engine. Currently we support 1-bit hammign
and 8-bit BCH on HW backend.
In order to switch between differnet ECC algorithms we need to change the
interface of omap_nand_switch_ecc() also.
Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com
Cc: Tom Rini tr...@ti.com
Cc: Thomas Weber thomas.weber.li...@googlemail.com
---
new in v2
since v2:
* use void omap_nand_switch_ecc(bool, uint32_t)
* print warning if unknown HW ecc strengs choosen
* fix alignment in help test
since v3:
* reset ecc.mode to NAND_ECC_NONE to prevent a BUG() on wrong eccstrength
input to changed omap_nand_switch_ecc();
With this change a user has the chance to switch back to another ECC mode
via nandecc command.
Many thanks to Thomas Weber for reporting this.
arch/arm/cpu/armv7/omap3/board.c | 31 ++
arch/arm/include/asm/arch-am33xx/sys_proto.h |2 +-
arch/arm/include/asm/arch-omap3/sys_proto.h |2 +-
drivers/mtd/nand/omap_gpmc.c | 57
++
4 files changed, 56 insertions(+), 36 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap3/board.c
b/arch/arm/cpu/armv7/omap3/board.c
index c6d9a42..b72fadc 100644
--- a/arch/arm/cpu/armv7/omap3/board.c
+++ b/arch/arm/cpu/armv7/omap3/board.c
@@ -328,14 +328,25 @@ void abort(void)
*/
static int do_switch_ecc(cmd_tbl_t * cmdtp, int flag, int argc, char * const
argv[])
{
- if (argc != 2)
+ if (argc 2 || argc 3)
goto usage;
- if (strncmp(argv[1], hw, 2) == 0)
- omap_nand_switch_ecc(1);
- else if (strncmp(argv[1], sw, 2) == 0)
- omap_nand_switch_ecc(0);
- else
+
+ if (strncmp(argv[1], hw, 2) == 0) {
+ if (argc == 2) {
+ omap_nand_switch_ecc(1, 1);
+ } else {
+ if (strncmp(argv[2], hamming, 7) == 0)
+ omap_nand_switch_ecc(1, 1);
+ else if (strncmp(argv[2], bch8, 4) == 0)
+ omap_nand_switch_ecc(1, 8);
+ else
+ goto usage;
+ }
+ } else if (strncmp(argv[1], sw, 2) == 0) {
+ omap_nand_switch_ecc(0, 0);
+ } else {
goto usage;
+ }
return 0;
@@ -345,9 +356,13 @@ usage:
}
U_BOOT_CMD(
- nandecc, 2, 1, do_switch_ecc,
+ nandecc, 3, 1, do_switch_ecc,
switch OMAP3 NAND ECC calculation algorithm,
- [hw/sw] - Switch between NAND hardware (hw) or software (sw) ecc
algorithm
+ hw [hamming|bch8] - Switch between NAND hardware 1-bit hamming and
+ 8-bit BCH\n
+ecc calculation (second parameter may
+ be omitted).\n
+ nandecc sw - Switch to NAND software ecc algorithm.
);
#endif /* CONFIG_NAND_OMAP_GPMC !CONFIG_SPL_BUILD */
diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h
b/arch/arm/include/asm/arch-am33xx/sys_proto.h
index 0910a94..c913b5f 100644
--- a/arch/arm/include/asm/arch-am33xx/sys_proto.h
+++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h
@@ -39,5 +39,5 @@ struct gpmc_cs;
void gpmc_init(void);
void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs *cs, u32
base,
u32 size);
-void omap_nand_switch_ecc(int);
+void omap_nand_switch_ecc(uint32_t, uint32_t);
#endif
diff --git a/arch/arm/include/asm/arch-omap3/sys_proto.h
b/arch/arm/include/asm/arch-omap3/sys_proto.h
index d60f2ad..dae1312 100644
--- a/arch/arm/include/asm/arch-omap3/sys_proto.h
+++ b/arch/arm/include/asm/arch-omap3/sys_proto.h
@@ -78,7 +78,7 @@ void sr32(void *, u32, u32, u32);
u32 wait_on_value(u32, u32, void *, u32);
void sdelay(unsigned long);
void make_cs1_contiguous(void);
-void omap_nand_switch_ecc(int);
+void omap_nand_switch_ecc(uint32_t, uint32_t);
void power_init_r(void);
void dieid_num_r(void);
void do_omap3_emu_romcode_call(u32 service_id, u32 parameters);
diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c
index c7d4999..3468c78 100644
--- a/drivers/mtd/nand/omap_gpmc.c
+++ b/drivers/mtd/nand/omap_gpmc.c
@@ -604,13 +604,14 @@ static int omap_read_page_bch(struct mtd_info *mtd,
struct nand_chip *chip,
#ifndef CONFIG_SPL_BUILD
/*
- * omap_nand_switch_ecc - switch the ECC operation b/w
Re: [U-Boot] [PATCH 2/6 V4] Sound: MAX98095: Add the driver for codec
Hi Prem S, We initialise MAX98095 using device tree, if you don't have a device tree support u need to have a asm/arch/sound.h which will initialise all values like sample rate, codec type, etc.. Actually in u-boot we have added audio support to play a beep sound. You can have look at drivers/sound/sound.c To test the same you can have look at common/cmd_sound.c, where we have 2 commands sound init and sound play. Hope this information will help you. -- Regards, Rajeshwari Shinde On Fri, Apr 5, 2013 at 4:41 PM, prem s prem...@gmail.com wrote: Hi all, I am working on ODROID PC Exynos-4 Board (Cortex-A9). In that board i am working MAX98089 Audio codec. How to initialize this audio codec and how to test this one in UBOOT level. Can you please help me on this. Thanks Prem V. On Sat, Feb 16, 2013 at 9:51 AM, Simon Glass s...@chromium.org wrote: On Thu, Feb 14, 2013 at 9:46 PM, Rajeshwari Shinde rajeshwar...@samsung.com wrote: This patch adds the driver for codec MAX98095 required by Snow Board Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 4/6] omap_gpmc: change nandecc command
Dear Thomas Weber, On 04/05/2013 01:48 PM, Thomas Weber wrote: Hello Andreas, this patch fixes the reported BUG(). The output is now: -8- OMAP3 DevKit8000 # nandecc hw hamming 1-bit hamming HW ECC selected OMAP3 DevKit8000 # nandecc hw bch8 Unsupported HW ECC algorithm NAND_ECC_NONE selected by board driver. This is not recommended !! OMAP3 DevKit8000 # -8- as expected. It is up to the user to choose the correct setup. Now he has the opportunity to switch back to hamming for example. Best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/6] omap_gpmc: add support for hw assisted BCH8
Dear Thomas Weber, On 04/05/2013 01:44 PM, Thomas Weber wrote: Hello Andreas, On 04/03/2013 04:50 PM, Andreas Bießmann wrote: snip diff --git a/doc/README.omap3 b/doc/README.omap3 index 0a37de0..56aca8e 100644 --- a/doc/README.omap3 +++ b/doc/README.omap3 @@ -145,6 +145,25 @@ int omap3_dma_wait_for_transfer(uint32_t chan) int omap3_dma_get_revision(uint32_t *minor, uint32_t *major) Read silicon Revision of the DMA module +NAND + + +Ther eare some OMAP3 devices out ther with NAND attached. Due to the fact that ther - there thank you for the hint, will fix. Are you trying this on devkit8000? Can you share your experience with us and maybe send a Tested-by? Best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: Fix __bss_start and __bss_end in linker scripts
On Fri, Apr 05, 2013 at 08:00:43AM +0200, Albert ARIBAUD wrote: Hi Beno??t, CC:ing Stephen Warren who wrote commit 2b7818d4 which git blame tells me added the ASSERT() to arch/arm/cpu/u-boot.lds, and Tom Rini to help decide what to do. [snip] Looks good, but what about the __bss_end in ASSERT(__bss_end (CONFIG_SPL_TEXT_BASE + CONFIG_SPL_MAX_SIZE), SPL image too big); ? Shouldn't it be replaced with __bss_limit, or even better, with __image_copy_end (why should BSS be taken into account for SPL image size?)? I meant __bss_base, not __image_copy_end. Part of SPL can use BSS, once board_init_f() has handed things over to board_init_r(), I agree with that. and this test is meant to ensure that .text+.data+.bss fits in the RAM available to SPL. This ASSERT() compares the upper limit of this RAM to the upper limit of the SPL needs, i.e. __bss_end. IOW, this ASSERT is about how much memory SPL will use when it runs, This is where there might be an issue with the definition / usage of CONFIG_SPL_MAX_SIZE. I had understood that this is the purpose of this assert, but this usage of CONFIG_SPL_MAX_SIZE, while frequent on arm, conflicts with its definition in README, as well as with some arm and other usages, e.g. in include/configs/am335x_evm.h or include/configs/p1_p2_rdb_pc.h. The README's definition is also how I understood this config when discussing it with Scott about my 16/30, which led to the #error test that was added at some point to this patch. Sorry, I'd missed that. Adding Stephen for any comment regarding the ASSERT() and CONFIG_SPL_MAX_SIZE semantics. Yes. I'm a little confused about this one as well now. According to README, CONFIG_SPL_MAX_SIZE is for text + data + rodata (i.e. for the size of the binary image file to be programmed on the target device), while CONFIG_SPL_BSS_MAX_SIZE is dedicated to the BSS. Hence, in order to comply with this definition, that assert should either use __bss_base/__bss_start, or compare against CONFIG_SPL_MAX_SIZE + CONFIG_SPL_BSS_MAX_SIZE, depending on whether it's supposed to test the binary image size or the memory footprint. There could even be asserts testing both. This would anyway be a new patch separate from this one. It would indeed be a different patch. IIUC, this future patch would increase the limit for SPL run-time size, as the constant against which the ASS tests __bss_end for would necessarily be greater than it is now. Correct? If so, this future patch should not break any target, as it would loosen the constraint, not tighten it. Tom, would such a patch, if posted today, be acceptable for 2013.04? So, lets talk things out. On (setting aside davinci) TI platforms, SPL's text/data/rodata is sitting in SRAM (starting at 0x4...) and we say BSS shall live in DDR (starting at 0x8...) and we configure DDR before clearing and using BSS. The max we set is mostly about trying to not possibly step on ourselves later on (SPL malloc, full U-Boot, etc). If I read all of the tegra files correctly, the way they work is that SPL and U-Boot are both loaded into memory, and thus they're ensuring that the BSS won't overlap with the full U-Boot that's right behind. So yes, a patch to correct the behavior is fine, and we can build test that easily enough as well. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: Fix __bss_start and __bss_end in linker scripts
Hi Albert,
On Friday, April 5, 2013 8:00:43 AM, Albert ARIBAUD wrote:
Hi Benoît,
CC:ing Stephen Warren who wrote commit 2b7818d4 which git blame tells
me added the ASSERT() to arch/arm/cpu/u-boot.lds, and Tom Rini to help
decide what to do.
On Fri, 5 Apr 2013 05:44:55 +0200 (CEST), Benoît Thébaudeau
benoit.thebaud...@advansee.com wrote:
Hi Albert,
On Friday, April 5, 2013 1:54:38 AM, Albert ARIBAUD wrote:
Hi Benoît,
On Fri, 5 Apr 2013 01:13:51 +0200 (CEST), Benoît Thébaudeau
benoit.thebaud...@advansee.com wrote:
On Friday, April 5, 2013 1:05:53 AM, Benoît Thébaudeau wrote:
Hi Albert,
On Friday, April 5, 2013 12:13:53 AM, Albert ARIBAUD wrote:
Subject: [PATCH] ARM: Fix __bss_start and __bss_end in linker
scripts
Commit 3ebd1cbc introduced compiler-generated __bss_start
and __bss_end__ and commit c23561e7 rewrote all __bss_end__
as __bss_end. Their merge caused silent and harmless but
potentially bug-inducing clashes between compiler- and linker-
enerated __bss_end symbols.
Make __bss_end and __bss_start compiler-only, and create
__bss_base and __bss_limit for linker-only use.
Reported-by: Benoît Thébaudeau benoit.thebaud...@advansee.com
Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net
---
arch/arm/cpu/ixp/u-boot.lds| 14 ++
arch/arm/cpu/u-boot.lds| 14 ++
board/actux1/u-boot.lds| 14 ++
board/actux2/u-boot.lds| 14 ++
board/actux3/u-boot.lds| 14 ++
board/dvlhost/u-boot.lds | 14 ++
board/freescale/mx31ads/u-boot.lds | 14 ++
7 files changed, 70 insertions(+), 28 deletions(-)
diff --git a/arch/arm/cpu/ixp/u-boot.lds
b/arch/arm/cpu/ixp/u-boot.lds
index 8345b55..c999829 100644
--- a/arch/arm/cpu/ixp/u-boot.lds
+++ b/arch/arm/cpu/ixp/u-boot.lds
@@ -67,17 +67,23 @@ SECTIONS
_end = .;
+/*
+ * Compiler-generated __bss_start and __bss_end, see
arch/arm/lib/bss.c
+ * __bss_base and __bss_limit are for linker only (overlay
ordering)
+ */
+
.bss_start __rel_dyn_start (OVERLAY) : {
KEEP(*(.__bss_start));
+ HIDDEN(__bss_base = .);
}
- .bss __bss_start (OVERLAY) : {
+ .bss __bss_base (OVERLAY) : {
*(.bss*)
. = ALIGN(4);
-__bss_end = .;
+HIDDEN(__bss_limit = .);
}
- .bss_end __bss_end (OVERLAY) : {
- KEEP(*(__bss_end));
+ .bss_end __bss_limit (OVERLAY) : {
+ KEEP(*(.__bss_end));
}
/DISCARD/ : { *(.dynstr*) }
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
index 3a1083d..0543b06 100644
--- a/arch/arm/cpu/u-boot.lds
+++ b/arch/arm/cpu/u-boot.lds
@@ -81,18 +81,24 @@ SECTIONS
*(.mmutable)
}
+/*
+ * Compiler-generated __bss_start and __bss_end, see
arch/arm/lib/bss.c
+ * __bss_base and __bss_limit are for linker only (overlay
ordering)
+ */
+
.bss_start __rel_dyn_start (OVERLAY) : {
KEEP(*(.__bss_start));
+ HIDDEN(__bss_base = .);
}
- .bss __bss_start (OVERLAY) : {
+ .bss __bss_base (OVERLAY) : {
*(.bss*)
. = ALIGN(4);
-__bss_end = .;
+HIDDEN(__bss_limit = .);
}
- .bss_end __bss_end (OVERLAY) : {
- KEEP(*(__bss_end));
+ .bss_end __bss_limit (OVERLAY) : {
+ KEEP(*(.__bss_end));
}
/DISCARD/ : { *(.dynstr*) }
diff --git a/board/actux1/u-boot.lds b/board/actux1/u-boot.lds
index c76728a..7e5c4d8 100644
--- a/board/actux1/u-boot.lds
+++ b/board/actux1/u-boot.lds
@@ -74,17 +74,23 @@ SECTIONS
_end = .;
+/*
+ * Compiler-generated __bss_start and __bss_end, see
arch/arm/lib/bss.c
+ * __bss_base and __bss_limit are for linker only (overlay
ordering)
+ */
+
.bss_start __rel_dyn_start (OVERLAY) : {
KEEP(*(.__bss_start));
+ HIDDEN(__bss_base = .);
}
- .bss __bss_start (OVERLAY) : {
+ .bss __bss_base (OVERLAY) : {
*(.bss*)
. = ALIGN(4);
-__bss_end = .;
+HIDDEN(__bss_limit = .);
}
- .bss_end __bss_end (OVERLAY) : {
- KEEP(*(__bss_end));
+ .bss_end __bss_limit (OVERLAY) : {
+
[U-Boot] [PATCH v4 5/6] omap_gpmc: add support for hw assisted BCH8
The kernel states:
---8---
The OMAP3 GPMC hardware BCH engine computes remainder polynomials, it does not
provide automatic error location and correction: this step is implemented using
the BCH library.
---8---
And we do so in u-boot.
This implementation uses the same layout for BCH8 but it is fix. The current
provided layout does only work with 64 Byte OOB.
Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com
Cc: Tom Rini tr...@ti.com
Cc: Ilya Yanok ilya.ya...@cogentembedded.com
Cc: Scott Wood scottw...@freescale.com
Cc: Mansoor Ahamed mansoor.aha...@ti.com
Cc: Thomas Weber thomas.weber.li...@googlemail.com
---
since v1:
* cleanups (remove debug stuff)
* make checkpach clean (still 2 warnings which I will not fix)
* merge some code with the AM33XX implementation
since v2:
* fix all checkpatch warnings
* add more comments
* add NAND section in README.omap3
since v3:
* fix typos in README (thanks to Thoams Weber)
* append required parameters for BCH8 in SPL
doc/README.omap3 | 28
drivers/mtd/nand/omap_gpmc.c | 367 +++---
lib/Makefile |2 +-
3 files changed, 305 insertions(+), 92 deletions(-)
diff --git a/doc/README.omap3 b/doc/README.omap3
index 0a37de0..1fbe79d 100644
--- a/doc/README.omap3
+++ b/doc/README.omap3
@@ -145,6 +145,34 @@ int omap3_dma_wait_for_transfer(uint32_t chan)
int omap3_dma_get_revision(uint32_t *minor, uint32_t *major)
Read silicon Revision of the DMA module
+NAND
+
+
+There are some OMAP3 devices out there with NAND attached. Due to the fact that
+OMAP3 ROM code can only handle 1-bit hamming ECC for accessing first page
+(place where SPL lives) we require this setup for u-boot at least when reading
+the second progam within SPL. A lot of newer NAND chips however require more
+than 1-bit ECC for the pages, some can live with 1-bit for the first page. To
+handle this we can switch to another ECC algorithm after reading the payload
+within SPL.
+
+BCH8
+
+
+To enable hardware assisted BCH8 (8-bit BCH [Bose, Chaudhuri, Hocquenghem]) on
+OMAP3 devices we can use the BCH library in lib/bch.c. To do so add CONFIG_BCH
+to enable the library and CONFIG_NAND_OMAP_BCH8 to to enable hardware assisted
+syndrom generation to your board config.
+The NAND OOB layout is the same as in linux kernel, if the linux kernel BCH8
+implementation for OMAP3 works for you so the u-boot version should also.
+When you require the SPL to read with BCH8 there are two more configs to
+change:
+
+ * CONFIG_SYS_NAND_ECCPOS (must be the same as .eccpos in
+ GPMC_NAND_HW_BCH8_ECC_LAYOUT defined in
+ arch/arm/include/asm/arch-omap3/omap_gpmc.h)
+ * CONFIG_SYS_NAND_ECCSIZE must be 512
+ * CONFIG_SYS_NAND_ECCBYTES must be 13 for this BCH8 setup
Acknowledgements
diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c
index 3468c78..bc1bcad 100644
--- a/drivers/mtd/nand/omap_gpmc.c
+++ b/drivers/mtd/nand/omap_gpmc.c
@@ -28,6 +28,7 @@
#include asm/arch/cpu.h
#include asm/omap_gpmc.h
#include linux/mtd/nand_ecc.h
+#include linux/bch.h
#include linux/compiler.h
#include nand.h
#ifdef CONFIG_AM33XX
@@ -37,6 +38,8 @@
static uint8_t cs;
static __maybe_unused struct nand_ecclayout hw_nand_oob =
GPMC_NAND_HW_ECC_LAYOUT;
+static __maybe_unused struct nand_ecclayout hw_bch8_nand_oob =
+ GPMC_NAND_HW_BCH8_ECC_LAYOUT;
/*
* omap_nand_hwcontrol - Set the address pointers corretly for the
@@ -239,13 +242,13 @@ static void __maybe_unused omap_enable_hwecc(struct
mtd_info *mtd, int32_t mode)
}
/*
- * BCH8 support (needs ELM and thus AM33xx-only)
+ * Generic BCH interface
*/
-#ifdef CONFIG_AM33XX
struct nand_bch_priv {
uint8_t mode;
uint8_t type;
uint8_t nibbles;
+ struct bch_control *control;
};
/* bch types */
@@ -253,21 +256,146 @@ struct nand_bch_priv {
#define ECC_BCH8 1
#define ECC_BCH16 2
+/* GPMC ecc engine settings */
+#define BCH_WRAPMODE_1 1 /* BCH wrap mode 1 */
+#define BCH_WRAPMODE_6 6 /* BCH wrap mode 6 */
+
/* BCH nibbles for diff bch levels */
#define NAND_ECC_HW_BCH ((uint8_t)(NAND_ECC_HW_OOB_FIRST) + 1)
#define ECC_BCH4_NIBBLES 13
#define ECC_BCH8_NIBBLES 26
#define ECC_BCH16_NIBBLES 52
-static struct nand_ecclayout hw_bch8_nand_oob = GPMC_NAND_HW_BCH8_ECC_LAYOUT;
-
-static struct nand_bch_priv bch_priv = {
+/*
+ * This can be a single instance cause all current users have only one NAND
+ * with nearly the same setup (BCH8, some with ELM and others with sw BCH
+ * library).
+ * When some users with other BCH strength will exists this have to change!
+ */
+static __maybe_unused struct nand_bch_priv bch_priv = {
.mode = NAND_ECC_HW_BCH,
.type = ECC_BCH8,
- .nibbles = ECC_BCH8_NIBBLES
+ .nibbles = ECC_BCH8_NIBBLES,
+ .control = NULL
};
/*
+ * omap_hwecc_init_bch - Initialize the BCH Hardware
Re: [U-Boot] env: fix potential stack overflow in environment functions
On 04/05/2013 06:17 AM, Wolfgang Denk wrote: Dear Tom Rini, In message 20130403153014.GF7035@bill-the-cat you wrote: On Fri, Mar 22, 2013 at 11:26:21AM -, Rob Herring wrote: From: Rob Herring rob.herr...@calxeda.com Most of the various environment functions create CONFIG_ENV_SIZE buffers on the stack. At least on ARM and PPC which have 4KB stacks, this can overflow the stack if we have large environment sizes. So move all the buffers off the stack to static buffers. Signed-off-by: Rob Herring rob.herr...@calxeda.com Applied to u-boot/master, thanks! I'm unhappy about this. The patch makes no sense to me, and in addition it causes build warnings for some boards (PPC: debris, kvme080): env_nvram.c: In function 'env_init': env_nvram.c:124:16: warning: pointer targets in initialization differ in signedness [-Wpointer-sign] I tried to explain this before, but eventually you missed my remarks, so here they go again: * The functiuons we are talking about run after relocation, i. e. when we have a full standard C runtime environment. In this situation we can assume to have virtually unlimited stack space available - actually limited only by the RAM size. * Moving the buffers from the stack into BSS is bad, as this way we permanently lose the space for these buffers, nut we need them only for a very short time, so we are wasting lots of memory. * If some board have for some reasons unreasonable small stack sizes, these need to be fixed. Rob refers to LMB stack space in his previous message - if there are indeed such small stack sizes used there, this is a problem that needs to be fixed elsewhere, but NOT by adapting all the rest of the U-Boot code to an artifical small stack. The stack size limit only comes into play when bootm runs and starts moving initrd and dtb to high addresses below the stack. At that point, the stack size does become limited because only 4KB (recently increase from 1KB) of space is reserved. So I had this in mind when I started debugging my environment getting corrupted and saw large buffers on the stack. My problem was ultimately that blank lines in mvenvimage input files are not handled correctly giving intermittent issues with the env import. I'm still not clear why the issue was intermittent, but I think mkenvimage should skip/remove blank lines. I still need to make a fix for that. I hereby request to revert that commit. That's fine with me. Rob Best regards, Wolfgang Denk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: Fix __bss_start and __bss_end in linker scripts
On 04/05/2013 07:53 AM, Tom Rini wrote: On Fri, Apr 05, 2013 at 08:00:43AM +0200, Albert ARIBAUD wrote: Hi Beno??t, CC:ing Stephen Warren who wrote commit 2b7818d4 which git blame tells me added the ASSERT() to arch/arm/cpu/u-boot.lds, and Tom Rini to help decide what to do. [snip] Looks good, but what about the __bss_end in ASSERT(__bss_end (CONFIG_SPL_TEXT_BASE + CONFIG_SPL_MAX_SIZE), SPL image too big); ? Shouldn't it be replaced with __bss_limit, or even better, with __image_copy_end (why should BSS be taken into account for SPL image size?)? I meant __bss_base, not __image_copy_end. Part of SPL can use BSS, once board_init_f() has handed things over to board_init_r(), I agree with that. and this test is meant to ensure that .text+.data+.bss fits in the RAM available to SPL. This ASSERT() compares the upper limit of this RAM to the upper limit of the SPL needs, i.e. __bss_end. IOW, this ASSERT is about how much memory SPL will use when it runs, This is where there might be an issue with the definition / usage of CONFIG_SPL_MAX_SIZE. I had understood that this is the purpose of this assert, but this usage of CONFIG_SPL_MAX_SIZE, while frequent on arm, conflicts with its definition in README, as well as with some arm and other usages, e.g. in include/configs/am335x_evm.h or include/configs/p1_p2_rdb_pc.h. The README's definition is also how I understood this config when discussing it with Scott about my 16/30, which led to the #error test that was added at some point to this patch. Sorry, I'd missed that. Adding Stephen for any comment regarding the ASSERT() and CONFIG_SPL_MAX_SIZE semantics. Yes. I'm a little confused about this one as well now. ... If I read all of the tegra files correctly, the way they work is that SPL and U-Boot are both loaded into memory, and thus they're ensuring that the BSS won't overlap with the full U-Boot that's right behind. Yes exactly. I'll explain the whole situation just so there's something to refer to in the archives. Tegra has two different types of CPU. As far as boot process goes, the AVP (Audio/Video Processor) is what is released from reset at system boot time, and what runs the built-in Tegra boot ROM and the U-Boot SPL. The AVP is an ARM7TDMI. The SPL initializes the main CPU complex (A9/A15), and causes it to execute the main U-Boot. The boot process is: * Entire U-Boot binary (SPL+pad+U-Boot) sits in boot flash. * Boot ROM code running on AVP: ** Initializes DRAM controller. ** Copies entire SPL+pad+U-Boot to DRAM byte-for-byte. ** Jumps to U-Boot SPL. * U-Boot SPL running on AVP: ** Initializes clocks/... required to boot A9 CPUs. ** Set up the A9 reset vector to point at the main U-Boot code, and releases A9 CPUs from reset. * Main U-Boot running on A9: ** Runs in the typical fashion, including regular relocation. Thus, the in-flash layout of SPL+U-Boot must match the in-DRAM layout, since the boot ROM just copies it byte-for-byte, and the SPL does nothing to move the appended main U-Boot out-of-the-way before executing. The gap between SPL and concatenated U-Boot must be large enough to hold the BSS (since SPL will use BSS without moving U-boot), but is also larger so that we can hard-code the TEXT_BASE of the main U-Boot to some stable value, without having to move it about often if SPL changes size. So the U-Boot binary layout in flash/DRAM is: +-+ | SPL | +-+ | Pad, including | | space for BSS | +-+ | Main U-Boot | +-+ The assert in question ensures that the start of the Main U-Boot in the diagram above is at a large enough address that it doesn't overlap the SPL's BSS usage in RAM. It's possible that I chose the wrong defines to validate when writing that assert. As long as the assert continues to ensure the above image layout in the generated u-boot*.bin, I have no problems with it being changed. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: Fix __bss_start and __bss_end in linker scripts
On Fri, Apr 05, 2013 at 03:56:46PM +0200, Beno??t Th??baudeau wrote: Hi Albert, On Friday, April 5, 2013 8:00:43 AM, Albert ARIBAUD wrote: Hi Beno??t, [snip] IIUC, this future patch would increase the limit for SPL run-time size, as the constant against which the ASS tests __bss_end for would necessarily be greater than it is now. Correct? If so, this future patch should not break any target, as it would loosen the constraint, not tighten it. Yes, it would either be the same or relaxed a bit, depending on the chosen option: - Define CONFIG_SPL_BSS_MAX_SIZE and test against CONFIG_SPL_MAX_SIZE + CONFIG_SPL_BSS_MAX_SIZE, the sum remaining the same as or being larger than currently, depending on the new values for CONFIG_SPL_MAX_SIZE and CONFIG_SPL_BSS_MAX_SIZE. - Define a new config meaning text + data + rodata + bss (e.g. CONFIG_SPL_MAX_RAM_SIZE or CONFIG_SPL_MAX_MEM_FOOTPRINT), and just replace CONFIG_SPL_MAX_SIZE with it for the users of arch/arm/cpu/u-boot*.lds, taking care that this was the only meaning those users were giving to CONFIG_SPL_MAX_SIZE. The first option would probably be preferable, using the same value for CONFIG_SPL_MAX_SIZE, and a non-zero value for CONFIG_SPL_BSS_MAX_SIZE. I think the problem is that Tegra really needs the second case as their constraint is must fit below next part of payload. We can assume the users of that linker script today care about footprint and update their define I believe. da850evm and the rest of the davinci platforms would also be a case to convert to this, but the omap*/am3* platforms would not. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] env: fix potential stack overflow in environment functions
Dear Rob Herring, In message 515eed36.9090...@gmail.com you wrote: The stack size limit only comes into play when bootm runs and starts moving initrd and dtb to high addresses below the stack. At that point, the stack size does become limited because only 4KB (recently increase from 1KB) of space is reserved. So I had this in mind when I started This looks to be conceptually broken to me. You cannot just lmb_reserve() arbitrary amounts of memory, when the documented, pubished memory map clearly states that this memory is free, and in use for the downward growing stack. If you need memory, you must reserve it in a clearly documented way. A part of the problem appears to be that it's actually very difficult to even understand how the mnemory concept of LMB has been designed - it it was designed at all. Is there any related documentation? debugging my environment getting corrupted and saw large buffers on the stack. My problem was ultimately that blank lines in mvenvimage input files are not handled correctly giving intermittent issues with the env import. I'm still not clear why the issue was intermittent, but I think mkenvimage should skip/remove blank lines. I still need to make a fix for that. No, it should not. It is supposed to keep the very formatting chosen by the implementor. The core of the problem is the illegal, and totally undocumented assumptions LMB appears to be making. _This_ is what needs to be fixed. Best regards, Wolfgang Denk -- 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: w...@denx.de ATTENTION: Despite Any Other Listing of Product Contents Found Here- on, the Consumer is Advised That, in Actuality, This Product Consists Of 99.99% Empty Space. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] env: fix potential stack overflow in environment functions
Dear Rob Herring, In message 515eed36.9090...@gmail.com you wrote: The stack size limit only comes into play when bootm runs and starts moving initrd and dtb to high addresses below the stack. At that point, the stack size does become limited because only 4KB (recently increase from 1KB) of space is reserved. So I had this in mind when I started BTW - the ARM code is simply broken - see arch/arm/lib/bootm.c: 74 lmb_reserve(lmb, sp, 75 gd-bd-bi_dram[0].start + gd-bd-bi_dram[0].size - sp); What if we have more than one memory bank? Then the computation above is pretty much random... Best regards, Wolfgang Denk -- 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: w...@denx.de It is more rational to sacrifice one life than six. -- Spock, The Galileo Seven, stardate 2822.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] OMAP5: Improve uEVM support
Today, the eMMC on the omap5_uevm cannot be booted from, due to a bug in the save_boot_params function that tests for a range of XIP to MMC2. But in the case of OMAP5, MMC2 is eMMC boot partition and MMC2_2 is eMMC (main), and uEVM can only boot from MMC2_2. We cannot just update the test as-is because other platforms define away MMC2_2 to 0xFF as they cannot be passed that value. I've fixed this by making it clearer in the comments what we do, and use a platform definable variable to say where we must check the range for. This part has been tested on some relevant platforms for each case. While doing this, the question arose of how to partition eMMC (since u-boot must be written RAW and not put on FAT), so I've added GPT support for this. Finally, while in here I see we weren't using the fallbacks baud rate table, so I changed to that. This series will mildly conflict (mainly over the rename) with Sricharan's current series of fixes, so I shall resolve that. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] OMAP3/4/5/AM33xx: Correct logic for checking FAT or RAW MMC
In the case of booting from certain peripherals, such as UART, we must not see what the device descriptor says for RAW or FAT mode because in addition to being nonsensical, it leads to a hang. This is why we have a test currently for the boot mode being within range. The problem however is that on some platforms we get MMC2_2 as the boot mode and not the defined value for MMC2, and in others we get the value for MMC2_2. This is required to fix eMMC booting on omap5_uevm. Tested on am335x_evm (UART, NAND, SD), omap3_beagle (NAND, SD on classic, SD only on xM rev C5) and omap5_uevm (SD, eMMC). Signed-off-by: Tom Rini tr...@ti.com --- arch/arm/cpu/armv7/omap-common/lowlevel_init.S | 10 +++--- arch/arm/include/asm/arch-am33xx/spl.h |3 +++ arch/arm/include/asm/arch-omap3/spl.h |3 +++ arch/arm/include/asm/arch-omap4/spl.h |2 ++ arch/arm/include/asm/arch-omap5/spl.h |2 ++ 5 files changed, 17 insertions(+), 3 deletions(-) diff --git a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S index b933fe8..90b3c8a 100644 --- a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S +++ b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S @@ -60,10 +60,14 @@ ENTRY(save_boot_params) ldr r3, =boot_params strbr2, [r3, #BOOT_DEVICE_OFFSET] @ spl_boot_device - r1 - /* boot mode is passed only for devices that can raw/fat mode */ - cmp r2, #BOOT_DEVICE_XIP + /* +* boot mode is only valid for device that can be raw or FAT booted. +* in other cases it may be fatal to look. While platforms differ +* in the values used for each MMC slot, they are contiguous. +*/ + cmp r2, #MMC_BOOT_DEVICES_START blt 2f - cmp r2, #BOOT_DEVICE_MMC2 + cmp r2, #MMC_BOOT_DEVICES_END bgt 2f /* Store the boot mode (raw/FAT) in omap_bootmode */ ldr r2, [r0, #DEV_DESC_PTR_OFFSET] @ get the device descriptor ptr diff --git a/arch/arm/include/asm/arch-am33xx/spl.h b/arch/arm/include/asm/arch-am33xx/spl.h index f60b086..14a2c7c 100644 --- a/arch/arm/include/asm/arch-am33xx/spl.h +++ b/arch/arm/include/asm/arch-am33xx/spl.h @@ -37,4 +37,7 @@ #define BOOT_DEVICE_USBETH 68 #define BOOT_DEVICE_CPGMAC 70 #define BOOT_DEVICE_MMC2_2 0xFF + +#define MMC_BOOT_DEVICES_START BOOT_DEVICE_MMC1 +#define MMC_BOOT_DEVICES_END BOOT_DEVICE_MMC2 #endif diff --git a/arch/arm/include/asm/arch-omap3/spl.h b/arch/arm/include/asm/arch-omap3/spl.h index dec4dac..84e6d7b 100644 --- a/arch/arm/include/asm/arch-omap3/spl.h +++ b/arch/arm/include/asm/arch-omap3/spl.h @@ -31,4 +31,7 @@ #define BOOT_DEVICE_MMC1 6 #define BOOT_DEVICE_XIPWAIT7 #define BOOT_DEVICE_MMC2_2 0xFF + +#define MMC_BOOT_DEVICES_START BOOT_DEVICE_MMC2 +#define MMC_BOOT_DEVICES_END BOOT_DEVICE_MMC1 #endif diff --git a/arch/arm/include/asm/arch-omap4/spl.h b/arch/arm/include/asm/arch-omap4/spl.h index 4e094f9..f61627f 100644 --- a/arch/arm/include/asm/arch-omap4/spl.h +++ b/arch/arm/include/asm/arch-omap4/spl.h @@ -32,4 +32,6 @@ #define BOOT_DEVICE_MMC2 6 #define BOOT_DEVICE_MMC2_2 0xFF +#define MMC_BOOT_DEVICES_START BOOT_DEVICE_MMC1 +#define MMC_BOOT_DEVICES_END BOOT_DEVICE_MMC2 #endif diff --git a/arch/arm/include/asm/arch-omap5/spl.h b/arch/arm/include/asm/arch-omap5/spl.h index 323cd63..d4d353c 100644 --- a/arch/arm/include/asm/arch-omap5/spl.h +++ b/arch/arm/include/asm/arch-omap5/spl.h @@ -32,4 +32,6 @@ #define BOOT_DEVICE_MMC26 #define BOOT_DEVICE_MMC2_2 7 +#define MMC_BOOT_DEVICES_START BOOT_DEVICE_MMC1 +#define MMC_BOOT_DEVICES_END BOOT_DEVICE_MMC2_2 #endif -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] omap5_evm.h: Move uEVM-specific choices to omap5_evm.h
The omap5_uevm platform has eMMC, and it makes sense to say that our
default env storage shall reside there. Other platforms may not, so
move this choice to the EVM config. In addition, we should provide some
way to partition the flash for later usage, so take advantage of the GPT
partition table support code and allow that to be setup with some
reasonable defaults.
Cc: Sricharan R r.sricha...@ti.com
Signed-off-by: Tom Rini tr...@ti.com
---
include/configs/omap5_common.h | 13 +
include/configs/omap5_evm.h| 18 ++
2 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index af97564..6ba5022 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -94,19 +94,12 @@
#define CONFIG_DRIVER_OMAP34XX_I2C
#define CONFIG_I2C_MULTI_BUS
-
/* MMC */
#define CONFIG_GENERIC_MMC
#define CONFIG_MMC
#define CONFIG_OMAP_HSMMC
#define CONFIG_DOS_PARTITION
-/* MMC ENV related defines */
-#define CONFIG_ENV_IS_IN_MMC
-#define CONFIG_SYS_MMC_ENV_DEV 1 /* SLOT2: eMMC(1) */
-#define CONFIG_ENV_OFFSET 0xE
-#define CONFIG_CMD_SAVEENV
-
#define CONFIG_SYS_CONSOLE_IS_IN_ENV
/* Flash */
@@ -124,7 +117,6 @@
#define CONFIG_CMD_FAT /* FAT support */
#define CONFIG_CMD_I2C /* I2C serial bus support */
#define CONFIG_CMD_MMC /* MMC support */
-#define CONFIG_CMD_SAVEENV
/* Disabled commands */
#undef CONFIG_CMD_NET
@@ -140,11 +132,16 @@
#define CONFIG_ENV_OVERWRITE
+#ifndef PARTS_DEFAULT
+#define PARTS_DEFAULT
+#endif
+
#define CONFIG_EXTRA_ENV_SETTINGS \
loadaddr=0x8200\0 \
console=ttyO2,115200n8\0 \
usbtty=cdc_acm\0 \
vram=16M\0 \
+ partitions= PARTS_DEFAULT \0 \
mmcdev=0\0 \
mmcroot=/dev/mmcblk0p2 rw\0 \
mmcrootfstype=ext3 rootwait\0 \
diff --git a/include/configs/omap5_evm.h b/include/configs/omap5_evm.h
index 22a8e13..e490523 100644
--- a/include/configs/omap5_evm.h
+++ b/include/configs/omap5_evm.h
@@ -28,6 +28,12 @@
#ifndef __CONFIG_OMAP5_EVM_H
#define __CONFIG_OMAP5_EVM_H
+/* Define the default GPT table for eMMC */
+#define PARTS_DEFAULT \
+ uuid_disk=${uuid_gpt_disk}; \
+ name=u-boot,size=1792KiB,uuid=${uuid_gpt_u-boot}; \
+ name=rootfs,size=-,uuid=${uuid_gpt_rootfs}
+
#include configs/omap5_common.h
/* TWL6035 */
@@ -35,6 +41,18 @@
#define CONFIG_TWL6035_POWER
#endif
+/* MMC ENV related defines */
+#define CONFIG_ENV_IS_IN_MMC
+#define CONFIG_SYS_MMC_ENV_DEV 1 /* SLOT2: eMMC(1) */
+#define CONFIG_ENV_OFFSET 0xE
+#define CONFIG_CMD_SAVEENV
+
+/* Enhance our eMMC support / experience. */
+#define CONFIG_CMD_GPT
+#define CONFIG_EFI_PARTITION
+#define CONFIG_PARTITION_UUIDS
+#define CONFIG_CMD_PART
+
#define CONFIG_SYS_PROMPT OMAP5430 EVM #
#endif /* __CONFIG_OMAP5_EVM_H */
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] omap5_common.h: Use fallback CONFIG_SYS_BAUDRATE_TABLE
Cc: Sricharan R r.sricha...@ti.com
Signed-off-by: Tom Rini tr...@ti.com
---
include/configs/omap5_common.h |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index 6ba5022..a6348a6 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -85,8 +85,7 @@
#define CONFIG_SYS_NS16550_COM3UART3_BASE
#define CONFIG_BAUDRATE115200
-#define CONFIG_SYS_BAUDRATE_TABLE {4800, 9600, 19200, 38400, 57600,\
- 115200}
+
/* I2C */
#define CONFIG_HARD_I2C
#define CONFIG_SYS_I2C_SPEED 10
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] env: fix potential stack overflow in environment functions
Dear Tom, dear Albert, In message 20130405111710.8c04c200...@gemini.denx.de I wrote: I hereby request to revert that commit. In addition to commit 60d7d5a env: fix potential stack overflow in environment functions discussed here, I think we should also revert commit fcfa696 ARM: increase lmb stack space reservation to 4KB because it is conceptually broken and just papers over the real problems. Best regards, Wolfgang Denk -- 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: w...@denx.de They say a little knowledge is a dangerous thing, but it is not one half so bad as a lot of ignorance. - Terry Pratchett, _Equal Rites_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-cfi-flash/master
On Thu, Apr 04, 2013 at 07:10:05AM +0200, Stefan Roese wrote: Hi Tom, please pull the updated cfi-flash repository with the build warning fix: The following changes since commit 5644369450635fa5c2967bee55b1ac41f6e988d0: Merge branch 'ag...@denx.de' of git://git.denx.de/u-boot-staging (2013-03-31 08:43:12 -0400) are available in the git repository at: git://www.denx.de/git/u-boot-cfi-flash.git master for you to fetch changes up to 81a4f7098ba137ea1961cb997ca16d57de2b3483: cfi_flash: Use uintptr_t for casts from u32 to void * (2013-04-04 07:07:30 +0200) Jagannadha Sutradharudu Teki (1): mtd: cfi_flash: Write buffer size adjustment for M29EW Numonyx devices Stefan Roese (1): cfi_flash: Use uintptr_t for casts from u32 to void * aaron.willi...@caviumnetworks.com (1): mtd: cfi_flash: Fix CFI flash driver for 8-bit bus support drivers/mtd/cfi_flash.c | 101 +--- include/mtd/cfi_flash.h | 41 ++-- 2 files changed, 99 insertions(+), 43 deletions(-) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add U_BOOT_TIMESTAMP definition
Dear Matt, In message CAKGA1bnoNJMYnj1qZUjrMZLvyrr0RT-S1y7-iYy=u2hebbw...@mail.gmail.com you wrote: I will submit this as a series shortly (with the configuration update) if this patch has been dropped already, alternatively I will just submit the configuration update and remark that it requires this patch. Is that okay? Both is fine wwith me. Best regards, Wolfgang Denk -- 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: w...@denx.de There are three ways to get something done: (1) Do it yourself. (2) Hire someone to do it for you. (3) Forbid your kids to do it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] env: fix potential stack overflow in environment functions
On 04/05/2013 11:24 AM, Wolfgang Denk wrote: Dear Tom, dear Albert, In message 20130405111710.8c04c200...@gemini.denx.de I wrote: I hereby request to revert that commit. In addition to commit 60d7d5a env: fix potential stack overflow in environment functions discussed here, I think we should also revert commit fcfa696 ARM: increase lmb stack space reservation to 4KB because it is conceptually broken and just papers over the real problems. Doing so will randomly break any system with a large command or print buffer. For extra fun, it is dependent on the initrd or dtb image size in terms of remainder of 4KB multiple. It is exactly the same code as PPC. It you look at the git history, PPC made exactly the same change (1 to 4KB increase) around the same time all the FDT boot code got copied from PPC to ARM. So ARM missed this change. If the stack is all of RAM, then what address should the initrd and dtb be copied to? Rob ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add U_BOOT_TIMESTAMP definition
Hi Wolfgang, On Sat, Mar 9, 2013 at 1:09 AM, Wolfgang Denk w...@denx.de wrote: Dear Matt, In message 1345733053-5023-1-git-send-email-m...@genesi-usa.com you wrote: This gives us a string like 20120822150855 which encodes the build time. This allows automated version checking and flashing of U-Boot to be performed, for example, in boot.scr files (or scripting in general). I just noticed that this was never applied. Sorry... No problem. Makefile |1 + 1 file changed, 1 insertion(+) diff --git a/Makefile b/Makefile index 1df4c1d..c042206 100644 --- a/Makefile +++ b/Makefile @@ -664,6 +664,7 @@ $(TIMESTAMP_FILE): @mkdir -p $(dir $(TIMESTAMP_FILE)) @LC_ALL=C date +'#define U_BOOT_DATE %b %d %C%y' $@.tmp @LC_ALL=C date +'#define U_BOOT_TIME %T' $@.tmp + @LC_ALL=C date +'#define U_BOOT_TIMESTAMP %Y%m%d%H%M%S' $@.tmp @cmp -s $@ $@.tmp rm -f $@.tmp || mv -f $@.tmp $@ But then - you only add a new #define to the build environment, without any users of it, i. e. dead code. Did you intend to post any code that would use this (in this case these patches should be merged into one, or at least into a series), or can we simply drop this patch? I did intend to submit a patch; what I wanted to do was gain some comments about it before I made our Efika MX configuration use it, and then it moved itself to development hell. I will submit this as a series shortly (with the configuration update) if this patch has been dropped already, alternatively I will just submit the configuration update and remark that it requires this patch. Is that okay? -- Matt Sealey m...@genesi-usa.com Product Development Analyst, Genesi USA, Inc. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] env: fix potential stack overflow in environment functions
Dear Rob, In message 515efe6f.1020...@gmail.com you wrote: In addition to commit 60d7d5a env: fix potential stack overflow in environment functions discussed here, I think we should also revert commit fcfa696 ARM: increase lmb stack space reservation to 4KB because it is conceptually broken and just papers over the real problems. Doing so will randomly break any system with a large command or print buffer. For extra fun, it is dependent on the initrd or dtb image size in terms of remainder of 4KB multiple. Well, yes, but that's because the LMB code makes unjustified assumptions about the memory usage, so it needs to be fixed there. It is exactly the same code as PPC. It you look at the git history, PPC made exactly the same change (1 to 4KB increase) around the same time all the FDT boot code got copied from PPC to ARM. So ARM missed this change. Thanks for pointing out. This adds commit 3882d7a ppc: unused memory region too close to current stack pointer to the list of patches that should bne reverted. If the stack is all of RAM, then what address should the initrd and dtb be copied to? Why do they have to be copied at all? Why cannot they remain where they have been loaded in the firtst place? The memcpy just costs time, which is a precious resource. Leave it to the user to find a reasonable location in RAM where he loads the data, and don't mess with it. Best regards, Wolfgang Denk -- 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: w...@denx.de We shall reach greater and greater platitudes of achievement. - Richard J. Daley ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: Fix __bss_start and __bss_end in linker scripts
Hi Tom, On Friday, April 5, 2013 6:00:30 PM, Tom Rini wrote: On Fri, Apr 05, 2013 at 03:56:46PM +0200, Beno??t Th??baudeau wrote: Hi Albert, On Friday, April 5, 2013 8:00:43 AM, Albert ARIBAUD wrote: Hi Beno??t, [snip] IIUC, this future patch would increase the limit for SPL run-time size, as the constant against which the ASS tests __bss_end for would necessarily be greater than it is now. Correct? If so, this future patch should not break any target, as it would loosen the constraint, not tighten it. Yes, it would either be the same or relaxed a bit, depending on the chosen option: - Define CONFIG_SPL_BSS_MAX_SIZE and test against CONFIG_SPL_MAX_SIZE + CONFIG_SPL_BSS_MAX_SIZE, the sum remaining the same as or being larger than currently, depending on the new values for CONFIG_SPL_MAX_SIZE and CONFIG_SPL_BSS_MAX_SIZE. - Define a new config meaning text + data + rodata + bss (e.g. CONFIG_SPL_MAX_RAM_SIZE or CONFIG_SPL_MAX_MEM_FOOTPRINT), and just replace CONFIG_SPL_MAX_SIZE with it for the users of arch/arm/cpu/u-boot*.lds, taking care that this was the only meaning those users were giving to CONFIG_SPL_MAX_SIZE. The first option would probably be preferable, using the same value for CONFIG_SPL_MAX_SIZE, and a non-zero value for CONFIG_SPL_BSS_MAX_SIZE. I think the problem is that Tegra really needs the second case as their constraint is must fit below next part of payload. We can assume the users of that linker script today care about footprint and update their define I believe. da850evm and the rest of the davinci platforms would also be a case to convert to this, but the omap*/am3* platforms would not. Yes, then let's have an assert in arch/arm/cpu/u-boot*.lds with a different config name (as in option 2 above) just for Tegra, and another assert for CONFIG_SPL_MAX_SIZE against __bss_start. And all users of CONFIG_SPL_MAX_SIZE should be checked to make sure that there is not another special case somewhere. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: Fix __bss_start and __bss_end in linker scripts
On Fri, Apr 05, 2013 at 07:32:54PM +0200, Beno??t Th??baudeau wrote: Hi Tom, On Friday, April 5, 2013 6:00:30 PM, Tom Rini wrote: On Fri, Apr 05, 2013 at 03:56:46PM +0200, Beno??t Th??baudeau wrote: Hi Albert, On Friday, April 5, 2013 8:00:43 AM, Albert ARIBAUD wrote: Hi Beno??t, [snip] IIUC, this future patch would increase the limit for SPL run-time size, as the constant against which the ASS tests __bss_end for would necessarily be greater than it is now. Correct? If so, this future patch should not break any target, as it would loosen the constraint, not tighten it. Yes, it would either be the same or relaxed a bit, depending on the chosen option: - Define CONFIG_SPL_BSS_MAX_SIZE and test against CONFIG_SPL_MAX_SIZE + CONFIG_SPL_BSS_MAX_SIZE, the sum remaining the same as or being larger than currently, depending on the new values for CONFIG_SPL_MAX_SIZE and CONFIG_SPL_BSS_MAX_SIZE. - Define a new config meaning text + data + rodata + bss (e.g. CONFIG_SPL_MAX_RAM_SIZE or CONFIG_SPL_MAX_MEM_FOOTPRINT), and just replace CONFIG_SPL_MAX_SIZE with it for the users of arch/arm/cpu/u-boot*.lds, taking care that this was the only meaning those users were giving to CONFIG_SPL_MAX_SIZE. The first option would probably be preferable, using the same value for CONFIG_SPL_MAX_SIZE, and a non-zero value for CONFIG_SPL_BSS_MAX_SIZE. I think the problem is that Tegra really needs the second case as their constraint is must fit below next part of payload. We can assume the users of that linker script today care about footprint and update their define I believe. da850evm and the rest of the davinci platforms would also be a case to convert to this, but the omap*/am3* platforms would not. Yes, then let's have an assert in arch/arm/cpu/u-boot*.lds with a different config name (as in option 2 above) just for Tegra, and another assert for CONFIG_SPL_MAX_SIZE against __bss_start. And all users of CONFIG_SPL_MAX_SIZE should be checked to make sure that there is not another special case somewhere. I didn't audit the PowerPC targets, but on ARM we have, roughly: - Tegra (covered in Stephen's email, and in short, must include BSS in size check) which uses SPL_MAX_SIZE to include BSS - OMAP*/AM3* which does not constrain BSS to SPL_MAX_SIZE - DaVinci which must also constrain BSS to the initial RAM, but for different reasons. - iMX which also uses SPL_BSS_MAX to cover the BSS separate from the rest of the program. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] env: fix potential stack overflow in environment functions
On 04/05/2013 12:13 PM, Wolfgang Denk wrote: Dear Rob, In message 515efe6f.1020...@gmail.com you wrote: In addition to commit 60d7d5a env: fix potential stack overflow in environment functions discussed here, I think we should also revert commit fcfa696 ARM: increase lmb stack space reservation to 4KB because it is conceptually broken and just papers over the real problems. Doing so will randomly break any system with a large command or print buffer. For extra fun, it is dependent on the initrd or dtb image size in terms of remainder of 4KB multiple. Well, yes, but that's because the LMB code makes unjustified assumptions about the memory usage, so it needs to be fixed there. It is exactly the same code as PPC. It you look at the git history, PPC made exactly the same change (1 to 4KB increase) around the same time all the FDT boot code got copied from PPC to ARM. So ARM missed this change. Thanks for pointing out. This adds commit 3882d7a ppc: unused memory region too close to current stack pointer to the list of patches that should bne reverted. If the stack is all of RAM, then what address should the initrd and dtb be copied to? Why do they have to be copied at all? Why cannot they remain where they have been loaded in the firtst place? The memcpy just costs time, which is a precious resource. Leave it to the user to find a reasonable location in RAM where he loads the data, and don't mess with it. I've got no freaking idea! I do turn that crap off in my environment with initrd_high=0x. But the default operation is to copy it. Rob ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] env: fix potential stack overflow in environment functions
Dear Rob, In message 515f1504.4090...@gmail.com you wrote: If the stack is all of RAM, then what address should the initrd and dtb be copied to? Why do they have to be copied at all? Why cannot they remain where they have been loaded in the firtst place? The memcpy just costs time, which is a precious resource. Leave it to the user to find a reasonable location in RAM where he loads the data, and don't mess with it. I've got no freaking idea! I do turn that crap off in my environment with initrd_high=0x. But the default operation is to copy it. Scott, Andy: I think I remember that some architectures really _need_ LMB - can you please shed a bit ligh on which these are, and why? And why it is enabled everywhere? Also, any information about the underlying design, intended memory map etc. would be highly welcome. Best regards, Wolfgang Denk -- 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: w...@denx.de 1 1 was a race-horse, 2 2 was 1 2. When 1 1 1 1 race, 2 2 1 1 2. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] env: fix potential stack overflow in environment functions
On Fri, Apr 05, 2013 at 01:16:36PM -0500, Rob Herring wrote: On 04/05/2013 12:13 PM, Wolfgang Denk wrote: Dear Rob, In message 515efe6f.1020...@gmail.com you wrote: In addition to commit 60d7d5a env: fix potential stack overflow in environment functions discussed here, I think we should also revert commit fcfa696 ARM: increase lmb stack space reservation to 4KB because it is conceptually broken and just papers over the real problems. Doing so will randomly break any system with a large command or print buffer. For extra fun, it is dependent on the initrd or dtb image size in terms of remainder of 4KB multiple. Well, yes, but that's because the LMB code makes unjustified assumptions about the memory usage, so it needs to be fixed there. It is exactly the same code as PPC. It you look at the git history, PPC made exactly the same change (1 to 4KB increase) around the same time all the FDT boot code got copied from PPC to ARM. So ARM missed this change. Thanks for pointing out. This adds commit 3882d7a ppc: unused memory region too close to current stack pointer to the list of patches that should bne reverted. If the stack is all of RAM, then what address should the initrd and dtb be copied to? Why do they have to be copied at all? Why cannot they remain where they have been loaded in the firtst place? The memcpy just costs time, which is a precious resource. Leave it to the user to find a reasonable location in RAM where he loads the data, and don't mess with it. I've got no freaking idea! I do turn that crap off in my environment with initrd_high=0x. But the default operation is to copy it. There's also fdt_high=0x which a number of platforms do to keep from FDT being thrown into highmem and unavailable to Linux. So, I shall revert the first commit in question today. For after v2013.04 we should: - Revert the other two commits Wolfgang found - See if there looks to be a real good reason for defaulting to relocating initrd/fdt, specifically up into the top of memory where we also know that U-Boot has / is alive and kicking. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: Fix __bss_start and __bss_end in linker scripts
Hi Tom, On Fri, 5 Apr 2013 13:55:21 -0400, Tom Rini tr...@ti.com wrote: On Fri, Apr 05, 2013 at 07:32:54PM +0200, Beno??t Th??baudeau wrote: Hi Tom, On Friday, April 5, 2013 6:00:30 PM, Tom Rini wrote: On Fri, Apr 05, 2013 at 03:56:46PM +0200, Beno??t Th??baudeau wrote: Hi Albert, On Friday, April 5, 2013 8:00:43 AM, Albert ARIBAUD wrote: Hi Beno??t, [snip] IIUC, this future patch would increase the limit for SPL run-time size, as the constant against which the ASS tests __bss_end for would necessarily be greater than it is now. Correct? If so, this future patch should not break any target, as it would loosen the constraint, not tighten it. Yes, it would either be the same or relaxed a bit, depending on the chosen option: - Define CONFIG_SPL_BSS_MAX_SIZE and test against CONFIG_SPL_MAX_SIZE + CONFIG_SPL_BSS_MAX_SIZE, the sum remaining the same as or being larger than currently, depending on the new values for CONFIG_SPL_MAX_SIZE and CONFIG_SPL_BSS_MAX_SIZE. - Define a new config meaning text + data + rodata + bss (e.g. CONFIG_SPL_MAX_RAM_SIZE or CONFIG_SPL_MAX_MEM_FOOTPRINT), and just replace CONFIG_SPL_MAX_SIZE with it for the users of arch/arm/cpu/u-boot*.lds, taking care that this was the only meaning those users were giving to CONFIG_SPL_MAX_SIZE. The first option would probably be preferable, using the same value for CONFIG_SPL_MAX_SIZE, and a non-zero value for CONFIG_SPL_BSS_MAX_SIZE. I think the problem is that Tegra really needs the second case as their constraint is must fit below next part of payload. We can assume the users of that linker script today care about footprint and update their define I believe. da850evm and the rest of the davinci platforms would also be a case to convert to this, but the omap*/am3* platforms would not. Yes, then let's have an assert in arch/arm/cpu/u-boot*.lds with a different config name (as in option 2 above) just for Tegra, and another assert for CONFIG_SPL_MAX_SIZE against __bss_start. And all users of CONFIG_SPL_MAX_SIZE should be checked to make sure that there is not another special case somewhere. I didn't audit the PowerPC targets, but on ARM we have, roughly: - Tegra (covered in Stephen's email, and in short, must include BSS in size check) which uses SPL_MAX_SIZE to include BSS - OMAP*/AM3* which does not constrain BSS to SPL_MAX_SIZE - DaVinci which must also constrain BSS to the initial RAM, but for different reasons. - iMX which also uses SPL_BSS_MAX to cover the BSS separate from the rest of the program. How about this? 1. In the u-boot*.lds files, doing separate asserts for SPL and SPL BSS max size, with the SPL assert being further divided in two cases depending on BSS max size being defined or not: #if defined(CONFIG_SPL_MAX_SIZE) #if defined(CONFIG_SPL_BSS_MAX_SIZE) ASSERT( __bss_end - __image_copy_start (CONFIG_SPL_TEXT_BASE + \ CONFIG_SPL_MAX_SIZE), SPL image code+BSS too big); #else ASSERT( __bss_end - __image_copy_start CONFIG_SPL_TEXT_BASE, \ CONFIG_SPL_MAX_SIZE), SPL image code too big); #endif #if defined(CONFIG_SPL_BSS_MAX_SIZE) ASSERT( __bss_end - __bss_start CONFIG_SPL_TEXT_BASE, \ CONFIG_SPL_BSS_MAX_SIZE), SPL image BSS too big); #endif 2. Defining CONFIG_SPL_BSS_MAX_SIZE only for Tegra, Davinci, IMX (where CONFIG_SPL_BSS_MAX_SIZE is actually the gap size) 3. *Not* defining CONFIG_SPL_MAX_SIZE or CONFIG_SPL_BSS_MAX_SIZE for OMAP*/AM3* 4. Adjusting README descriptions of CONFIG_SPL_[BSS_]MAX_SIZE and ensuring Makefile uses the right size for --pad-to, as well as the few other files which use CONFIG_SPL_MAX_SIZE. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: Fix __bss_start and __bss_end in linker scripts
On Fri, 5 Apr 2013 21:17:40 +0200, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Tom, On Fri, 5 Apr 2013 13:55:21 -0400, Tom Rini tr...@ti.com wrote: On Fri, Apr 05, 2013 at 07:32:54PM +0200, Beno??t Th??baudeau wrote: Hi Tom, On Friday, April 5, 2013 6:00:30 PM, Tom Rini wrote: On Fri, Apr 05, 2013 at 03:56:46PM +0200, Beno??t Th??baudeau wrote: Hi Albert, On Friday, April 5, 2013 8:00:43 AM, Albert ARIBAUD wrote: Hi Beno??t, [snip] IIUC, this future patch would increase the limit for SPL run-time size, as the constant against which the ASS tests __bss_end for would necessarily be greater than it is now. Correct? If so, this future patch should not break any target, as it would loosen the constraint, not tighten it. Yes, it would either be the same or relaxed a bit, depending on the chosen option: - Define CONFIG_SPL_BSS_MAX_SIZE and test against CONFIG_SPL_MAX_SIZE + CONFIG_SPL_BSS_MAX_SIZE, the sum remaining the same as or being larger than currently, depending on the new values for CONFIG_SPL_MAX_SIZE and CONFIG_SPL_BSS_MAX_SIZE. - Define a new config meaning text + data + rodata + bss (e.g. CONFIG_SPL_MAX_RAM_SIZE or CONFIG_SPL_MAX_MEM_FOOTPRINT), and just replace CONFIG_SPL_MAX_SIZE with it for the users of arch/arm/cpu/u-boot*.lds, taking care that this was the only meaning those users were giving to CONFIG_SPL_MAX_SIZE. The first option would probably be preferable, using the same value for CONFIG_SPL_MAX_SIZE, and a non-zero value for CONFIG_SPL_BSS_MAX_SIZE. I think the problem is that Tegra really needs the second case as their constraint is must fit below next part of payload. We can assume the users of that linker script today care about footprint and update their define I believe. da850evm and the rest of the davinci platforms would also be a case to convert to this, but the omap*/am3* platforms would not. Yes, then let's have an assert in arch/arm/cpu/u-boot*.lds with a different config name (as in option 2 above) just for Tegra, and another assert for CONFIG_SPL_MAX_SIZE against __bss_start. And all users of CONFIG_SPL_MAX_SIZE should be checked to make sure that there is not another special case somewhere. I didn't audit the PowerPC targets, but on ARM we have, roughly: - Tegra (covered in Stephen's email, and in short, must include BSS in size check) which uses SPL_MAX_SIZE to include BSS - OMAP*/AM3* which does not constrain BSS to SPL_MAX_SIZE - DaVinci which must also constrain BSS to the initial RAM, but for different reasons. - iMX which also uses SPL_BSS_MAX to cover the BSS separate from the rest of the program. How about this? 1. In the u-boot*.lds files, doing separate asserts for SPL and SPL BSS max size, with the SPL assert being further divided in two cases depending on BSS max size being defined or not: #if defined(CONFIG_SPL_MAX_SIZE) #if defined(CONFIG_SPL_BSS_MAX_SIZE) ASSERT( __bss_end - __image_copy_start (CONFIG_SPL_TEXT_BASE + \ CONFIG_SPL_MAX_SIZE), SPL image code+BSS too big); #else ASSERT( __bss_end - __image_copy_start CONFIG_SPL_TEXT_BASE, \ CONFIG_SPL_MAX_SIZE), SPL image code too big); #endif #endif (sorry) #if defined(CONFIG_SPL_BSS_MAX_SIZE) ASSERT( __bss_end - __bss_start CONFIG_SPL_TEXT_BASE, \ CONFIG_SPL_BSS_MAX_SIZE), SPL image BSS too big); #endif 2. Defining CONFIG_SPL_BSS_MAX_SIZE only for Tegra, Davinci, IMX (where CONFIG_SPL_BSS_MAX_SIZE is actually the gap size) 3. *Not* defining CONFIG_SPL_MAX_SIZE or CONFIG_SPL_BSS_MAX_SIZE for OMAP*/AM3* 4. Adjusting README descriptions of CONFIG_SPL_[BSS_]MAX_SIZE and ensuring Makefile uses the right size for --pad-to, as well as the few other files which use CONFIG_SPL_MAX_SIZE. Amicalement, Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: Fix __bss_start and __bss_end in linker scripts
On Fri, Apr 05, 2013 at 09:17:40PM +0200, Albert ARIBAUD wrote: Hi Tom, On Fri, 5 Apr 2013 13:55:21 -0400, Tom Rini tr...@ti.com wrote: On Fri, Apr 05, 2013 at 07:32:54PM +0200, Beno??t Th??baudeau wrote: Hi Tom, On Friday, April 5, 2013 6:00:30 PM, Tom Rini wrote: On Fri, Apr 05, 2013 at 03:56:46PM +0200, Beno??t Th??baudeau wrote: Hi Albert, On Friday, April 5, 2013 8:00:43 AM, Albert ARIBAUD wrote: Hi Beno??t, [snip] IIUC, this future patch would increase the limit for SPL run-time size, as the constant against which the ASS tests __bss_end for would necessarily be greater than it is now. Correct? If so, this future patch should not break any target, as it would loosen the constraint, not tighten it. Yes, it would either be the same or relaxed a bit, depending on the chosen option: - Define CONFIG_SPL_BSS_MAX_SIZE and test against CONFIG_SPL_MAX_SIZE + CONFIG_SPL_BSS_MAX_SIZE, the sum remaining the same as or being larger than currently, depending on the new values for CONFIG_SPL_MAX_SIZE and CONFIG_SPL_BSS_MAX_SIZE. - Define a new config meaning text + data + rodata + bss (e.g. CONFIG_SPL_MAX_RAM_SIZE or CONFIG_SPL_MAX_MEM_FOOTPRINT), and just replace CONFIG_SPL_MAX_SIZE with it for the users of arch/arm/cpu/u-boot*.lds, taking care that this was the only meaning those users were giving to CONFIG_SPL_MAX_SIZE. The first option would probably be preferable, using the same value for CONFIG_SPL_MAX_SIZE, and a non-zero value for CONFIG_SPL_BSS_MAX_SIZE. I think the problem is that Tegra really needs the second case as their constraint is must fit below next part of payload. We can assume the users of that linker script today care about footprint and update their define I believe. da850evm and the rest of the davinci platforms would also be a case to convert to this, but the omap*/am3* platforms would not. Yes, then let's have an assert in arch/arm/cpu/u-boot*.lds with a different config name (as in option 2 above) just for Tegra, and another assert for CONFIG_SPL_MAX_SIZE against __bss_start. And all users of CONFIG_SPL_MAX_SIZE should be checked to make sure that there is not another special case somewhere. I didn't audit the PowerPC targets, but on ARM we have, roughly: - Tegra (covered in Stephen's email, and in short, must include BSS in size check) which uses SPL_MAX_SIZE to include BSS - OMAP*/AM3* which does not constrain BSS to SPL_MAX_SIZE - DaVinci which must also constrain BSS to the initial RAM, but for different reasons. - iMX which also uses SPL_BSS_MAX to cover the BSS separate from the rest of the program. How about this? 1. In the u-boot*.lds files, doing separate asserts for SPL and SPL BSS max size, with the SPL assert being further divided in two cases depending on BSS max size being defined or not: #if defined(CONFIG_SPL_MAX_SIZE) #if defined(CONFIG_SPL_BSS_MAX_SIZE) ASSERT( __bss_end - __image_copy_start (CONFIG_SPL_TEXT_BASE + \ CONFIG_SPL_MAX_SIZE), SPL image code+BSS too big); #else ASSERT( __bss_end - __image_copy_start CONFIG_SPL_TEXT_BASE, \ CONFIG_SPL_MAX_SIZE), SPL image code too big); #endif #if defined(CONFIG_SPL_BSS_MAX_SIZE) ASSERT( __bss_end - __bss_start CONFIG_SPL_TEXT_BASE, \ CONFIG_SPL_BSS_MAX_SIZE), SPL image BSS too big); #endif #endif I think this is too complicated. Our cases are: 1. text/data/rodata/bss MUST fit within $size for $location 2. text/data/rodata MUST fit within $sizeA for $locationA and BSS must start at $locationB (which is at least $sizeB big) The problem is that CONFIG_SPL_MAX_SIZE is defined to mean #2 but the generic ARM SPL linker script was using it for #1. We should correct the generic ARM SPL linker script to test #2, and add in a new option to cover #1 and convert tegra (as they're the user of the generic script) to this new option. 2. Defining CONFIG_SPL_BSS_MAX_SIZE only for Tegra, Davinci, IMX (where CONFIG_SPL_BSS_MAX_SIZE is actually the gap size) No, this is wrong. These do not care about the BSS size, they care about the text/data/rodata/bss size. 3. *Not* defining CONFIG_SPL_MAX_SIZE or CONFIG_SPL_BSS_MAX_SIZE for OMAP*/AM3* This is wrong. The main reason for SPL_BSS_MAX_SIZE here is that we have the BSS at a very different location from the rest of the binary (text/data/rodata at 0x4... BSS at 0x8...) and use MEMORY constructs to place things correctly. So we must(?) define a start and end, and that's what BSS_MAX_SIZE is for. 4. Adjusting README descriptions of CONFIG_SPL_[BSS_]MAX_SIZE and ensuring Makefile uses the right size for --pad-to, as well as the few other files which use
Re: [U-Boot] [PATCH] logo: update to the new logo for ATMEL
Dear Josh Wu, Josh Wu josh...@atmel.com writes: Atmel change to new logo since 2012. This patch update the logo to new one. Signed-off-by: Josh Wu josh...@atmel.com --- tools/logos/atmel.bmp | Bin 26334 - 15478 bytes 1 file changed, 0 insertions(+), 0 deletions(-) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: Fix __bss_start and __bss_end in linker scripts
Hi Tom, On Fri, 5 Apr 2013 15:44:08 -0400, Tom Rini tr...@ti.com wrote: On Fri, Apr 05, 2013 at 09:17:40PM +0200, Albert ARIBAUD wrote: Hi Tom, On Fri, 5 Apr 2013 13:55:21 -0400, Tom Rini tr...@ti.com wrote: On Fri, Apr 05, 2013 at 07:32:54PM +0200, Beno??t Th??baudeau wrote: Hi Tom, On Friday, April 5, 2013 6:00:30 PM, Tom Rini wrote: On Fri, Apr 05, 2013 at 03:56:46PM +0200, Beno??t Th??baudeau wrote: Hi Albert, On Friday, April 5, 2013 8:00:43 AM, Albert ARIBAUD wrote: Hi Beno??t, [snip] IIUC, this future patch would increase the limit for SPL run-time size, as the constant against which the ASS tests __bss_end for would necessarily be greater than it is now. Correct? If so, this future patch should not break any target, as it would loosen the constraint, not tighten it. Yes, it would either be the same or relaxed a bit, depending on the chosen option: - Define CONFIG_SPL_BSS_MAX_SIZE and test against CONFIG_SPL_MAX_SIZE + CONFIG_SPL_BSS_MAX_SIZE, the sum remaining the same as or being larger than currently, depending on the new values for CONFIG_SPL_MAX_SIZE and CONFIG_SPL_BSS_MAX_SIZE. - Define a new config meaning text + data + rodata + bss (e.g. CONFIG_SPL_MAX_RAM_SIZE or CONFIG_SPL_MAX_MEM_FOOTPRINT), and just replace CONFIG_SPL_MAX_SIZE with it for the users of arch/arm/cpu/u-boot*.lds, taking care that this was the only meaning those users were giving to CONFIG_SPL_MAX_SIZE. The first option would probably be preferable, using the same value for CONFIG_SPL_MAX_SIZE, and a non-zero value for CONFIG_SPL_BSS_MAX_SIZE. I think the problem is that Tegra really needs the second case as their constraint is must fit below next part of payload. We can assume the users of that linker script today care about footprint and update their define I believe. da850evm and the rest of the davinci platforms would also be a case to convert to this, but the omap*/am3* platforms would not. Yes, then let's have an assert in arch/arm/cpu/u-boot*.lds with a different config name (as in option 2 above) just for Tegra, and another assert for CONFIG_SPL_MAX_SIZE against __bss_start. And all users of CONFIG_SPL_MAX_SIZE should be checked to make sure that there is not another special case somewhere. I didn't audit the PowerPC targets, but on ARM we have, roughly: - Tegra (covered in Stephen's email, and in short, must include BSS in size check) which uses SPL_MAX_SIZE to include BSS - OMAP*/AM3* which does not constrain BSS to SPL_MAX_SIZE - DaVinci which must also constrain BSS to the initial RAM, but for different reasons. - iMX which also uses SPL_BSS_MAX to cover the BSS separate from the rest of the program. How about this? 1. In the u-boot*.lds files, doing separate asserts for SPL and SPL BSS max size, with the SPL assert being further divided in two cases depending on BSS max size being defined or not: #if defined(CONFIG_SPL_MAX_SIZE) #if defined(CONFIG_SPL_BSS_MAX_SIZE) ASSERT( __bss_end - __image_copy_start (CONFIG_SPL_TEXT_BASE + \ CONFIG_SPL_MAX_SIZE), SPL image code+BSS too big); #else ASSERT( __bss_end - __image_copy_start CONFIG_SPL_TEXT_BASE, \ CONFIG_SPL_MAX_SIZE), SPL image code too big); #endif #if defined(CONFIG_SPL_BSS_MAX_SIZE) ASSERT( __bss_end - __bss_start CONFIG_SPL_TEXT_BASE, \ CONFIG_SPL_BSS_MAX_SIZE), SPL image BSS too big); #endif #endif I think this is too complicated. Our cases are: 1. text/data/rodata/bss MUST fit within $size for $location 2. text/data/rodata MUST fit within $sizeA for $locationA and BSS must start at $locationB (which is at least $sizeB big) The problem is that CONFIG_SPL_MAX_SIZE is defined to mean #2 but the generic ARM SPL linker script was using it for #1. We should correct the generic ARM SPL linker script to test #2, and add in a new option to cover #1 and convert tegra (as they're the user of the generic script) to this new option. 2. Defining CONFIG_SPL_BSS_MAX_SIZE only for Tegra, Davinci, IMX (where CONFIG_SPL_BSS_MAX_SIZE is actually the gap size) No, this is wrong. These do not care about the BSS size, they care about the text/data/rodata/bss size. Maybe I wasn't clear. I did not mean to define only BSS max size for those [and not image max size], but to define, only for those, BSS max size [in addition to image max size being defined for most of the boards including these] -- IOW, while most if not all boards want to check image size, only some boards seem to want to check BSS size in
[U-Boot] [PATCH] powerpc/mpc85xx: Clear L1 D-cache lock
dcbi instruction has been used to clear D-cache lock. However, the cache lock is presistent for e6500 core. Use dcblc to clear the lock explicitly. Signed-off-by: York Sun york...@freescale.com --- arch/powerpc/cpu/mpc85xx/start.S |1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S index 9359d83..bb568a2 100644 --- a/arch/powerpc/cpu/mpc85xx/start.S +++ b/arch/powerpc/cpu/mpc85xx/start.S @@ -2049,6 +2049,7 @@ unlock_ram_in_cache: slwir4,r4,(10 - 1 - L1_CACHE_SHIFT) mtctr r4 1: dcbir0,r3 + dcblc r0,r3 addir3,r3,CONFIG_SYS_CACHELINE_SIZE bdnz1b sync -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PULL] please pull u-boot-atmel/master
Dear Albert Aribaud, please pull the following late change into u-boot-arm/master. The other pending patches where way after merge window close and will end up in next branch these days. The following changes since commit fed029f3c31b7d5df674b5090a13356b631918c7: Merge branch 'u-boot-samsung/master' into 'u-boot-arm/master' (2013-04-04 15:44:57 +0200) are available in the git repository at: git://git.denx.de/u-boot-atmel.git master for you to fetch changes up to 8bf3c322856f42d4db8acd7fa4f2a17898564064: logo: update to the new logo for ATMEL (2013-04-05 21:49:37 +0200) Josh Wu (1): logo: update to the new logo for ATMEL tools/logos/atmel.bmp | Bin 26334 - 15478 bytes 1 file changed, 0 insertions(+), 0 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: Fix __bss_start and __bss_end in linker scripts
On Fri, Apr 05, 2013 at 10:04:02PM +0200, Albert ARIBAUD wrote: The two general ideas of my proposal are: 1) to separate testing the image (text,data,rodata,lists) size on the one hand and the image BSS size on the other hand, and 2) to consider that if a target defines an image max size and a BSS max size, then the image max size does not include the BSS size ; and if it defined an image max size but no BSS max size, then the image max size includes the BSS. The first idea allows boards with disjoint image and BSS to still check eahc part's size, a thing not feasible with the current code; the second idea allows fewer changes, but if one wants CONFIG_SPL_MAX_SIZE to have a strict meaning, we can drop idea #2 and still keep idea #1. Make it so, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6: fsl_esdhc: Fix waiting for DMA operation completion
On Apr 4, 2013, at 1:41 PM, Eric Nelson wrote:
Hi Andrew,
On 04/04/2013 11:03 AM, Gabbasov, Andrew wrote:
Hi Eric,
From: Eric Nelson [eric.nel...@boundarydevices.com]
Sent: Thursday, April 04, 2013 03:47
To: Gabbasov, Andrew
Cc: u-boot@lists.denx.de; Behme, Dirk - Bosch; Fabio Estevam
Subject: Re: [U-Boot] [PATCH] mx6: fsl_esdhc: Fix waiting for DMA operation
completion
So, do you think the latter (modified) loop condition
} while (!(irqstat IRQSTAT_TC) || !(irqstat IRQSTAT_DINT) ||
(esdhc_read32(regs-prsstat) PRSSTAT_DLA));
will be correct?
I think the right thing to do is eliminate the DLA test entirely,
so the loop condition can be simplified to something like this:
#define TRANSFER_COMPLETE (IRQSTAT_TC|IRQSTAT_DINT)
do {
...
} while (TRANSFER_COMPLETE != (irqstatTRANSFER_COMPLETE));
That looks right to me. I have been known to mistakenly write loops that are
supposed to wait for two conditions to only wait for one of those. Apparently I
need remedial boolean logic lessons.
If there is another part that needs to bail out on PRSSTAT_DLA,
it seems that the affected part should be the one with the #ifdef
I don't think we need a special case. Just correct logic. :/
Andy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5][v2] powerpc/mpc85xx:No NOR boot, do not compile IFC errata A003399
On 03/22/2013 02:07:48 AM, Prabhakar Kushwaha wrote: IFC errata A003399 is valid for IFC NOR boot i.e.if no on-board NOR flash or no NOR boot, do not compile its workaround. Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com --- Based upon git://git.denx.de/u-boot.git branch master Changes for v2: - Add CONFIG_A003399_NOR_WORKAROUND for errata workaround - Add CONFIG_A003399_NOR_WORKAROUND in README README|4 arch/powerpc/cpu/mpc85xx/cpu_init_early.c |9 ++--- arch/powerpc/cpu/mpc8xxx/fsl_ifc.c|2 +- 3 files changed, 11 insertions(+), 4 deletions(-) diff --git a/README b/README index 7f2506a..c4ad69d 100644 --- a/README +++ b/README @@ -414,6 +414,10 @@ The following options need to be configured: See Freescale App Note 4493 for more information about this erratum. + CONFIG_A003399_NOR_WORKAROUND + Enables a workaround for IFC erratum A003399. It is only + requred during NOR boot. + CONFIG_SYS_FSL_CORENET_SNOOPVEC_COREONLY This is the value to write into CCSR offset 0x18600 diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c index dacfdd1..3a4bfc5 100644 --- a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c +++ b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c @@ -25,7 +25,8 @@ DECLARE_GLOBAL_DATA_PTR; -#if defined(CONFIG_SYS_FSL_ERRATUM_IFC_A003399) !defined(CONFIG_SYS_RAMBOOT) +#if defined(CONFIG_SYS_FSL_ERRATUM_IFC_A003399)\ +defined(CONFIG_A003399_NOR_WORKAROUND) Why would CONFIG_A003399_NOR_WORKAROUND be enabled if CONFIG_SYS_FSL_ERRATUM_IFC_A003399 isn't? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5][v2] powerpc/mpc85xx: new SPL support for IFC NAND
On 03/22/2013 02:08:05 AM, Prabhakar Kushwaha wrote: diff --git a/board/freescale/common/Makefile b/board/freescale/common/Makefile index 75725b4..a4d521c 100644 --- a/board/freescale/common/Makefile +++ b/board/freescale/common/Makefile @@ -29,6 +29,15 @@ endif LIB= $(obj)libfreescale.o +MINIMAL= + +ifdef CONFIG_SPL_BUILD +ifdef CONFIG_SPL_INIT_MINIMAL +MINIMAL=y +endif +endif + +ifndef MINIMAL COBJS-$(CONFIG_FSL_CADMUS) += cadmus.o COBJS-$(CONFIG_FSL_VIA)+= cds_via.o COBJS-$(CONFIG_FMAN_ENET) += fman.o @@ -62,6 +71,7 @@ SUBLIB-$(CONFIG_P3041DS) += p_corenet/libp_corenet.o SUBLIB-$(CONFIG_P4080DS) += p_corenet/libp_corenet.o SUBLIB-$(CONFIG_P5020DS) += p_corenet/libp_corenet.o SUBLIB-$(CONFIG_P5040DS) += p_corenet/libp_corenet.o +endif SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c) OBJS := $(addprefix $(obj),$(COBJS-y)) If this is needed to avoid pulling in any files from this directory, why did p1_p2_rdb_pc not need this? Is there a particular file that is failing to build or failing to get optimized away? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [v3] command/cache: Add flush command
When we copy code/data to the main memory, we may need to flush the
cache if required by architecture. It uses the existing function
flush_cache. Syntax is
flush addr size
The addr and size are given in hexadecimal. Like memory command, there is
no sanity check for the parameters.
Signed-off-by: York Sun york...@freescale.com
---
Change since v2: rename flush_cache to flush
README |5 -
common/cmd_cache.c | 26 ++
2 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/README b/README
index dc6b0b3..b2f80d6 100644
--- a/README
+++ b/README
@@ -809,6 +809,7 @@ The following options need to be configured:
CONFIG_CMD_BSP * Board specific commands
CONFIG_CMD_BOOTD bootd
CONFIG_CMD_CACHE* icache, dcache
+ CONFIG_CMD_CACHE_FLUSH * flush cache by the address and range
CONFIG_CMD_CONSOLEconinfo
CONFIG_CMD_CRC32* crc32
CONFIG_CMD_DATE * support for RTC, date/time...
@@ -912,7 +913,9 @@ The following options need to be configured:
8260 (where accesses to the IMMR region must be
uncached), and it cannot be disabled on all other
systems where we (mis-) use the data cache to hold an
- initial stack and some data.
+ initial stack and some data. The CONFIG_CMD_CACHE_FLUSH
+ macro enables flushing cache by the address and range to
+ maintain coherency if required by architecture.
XXX - this list needs to get updated!
diff --git a/common/cmd_cache.c b/common/cmd_cache.c
index 5512f92..c228e0c 100644
--- a/common/cmd_cache.c
+++ b/common/cmd_cache.c
@@ -120,3 +120,29 @@ U_BOOT_CMD(
[on, off, flush]\n
- enable, disable, or flush data (writethrough) cache
);
+
+#ifdef CONFIG_CMD_CACHE_FLUSH
+int do_flush_cache(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ ulong addr, size;
+
+ switch (argc) {
+ case 3:
+ addr = simple_strtoul(argv[1], NULL, 16);
+ size = simple_strtoul(argv[2], NULL, 16);
+ flush_cache(addr, size);
+ break;
+ default:
+ return cmd_usage(cmdtp);
+ }
+ return 0;
+
+}
+
+U_BOOT_CMD(
+ flush, 3, 0, do_flush_cache,
+ flush cache for a range,
+ addr size\n
+ - flush cache for specificed range
+);
+#endif
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] please pull u-boot-atmel/master
Hi Andreas, On Fri, 5 Apr 2013 22:22:34 +0200, Andreas Bießmann andreas.de...@googlemail.com wrote: Dear Albert Aribaud, please pull the following late change into u-boot-arm/master. The other pending patches where way after merge window close and will end up in next branch these days. The following changes since commit fed029f3c31b7d5df674b5090a13356b631918c7: Merge branch 'u-boot-samsung/master' into 'u-boot-arm/master' (2013-04-04 15:44:57 +0200) are available in the git repository at: git://git.denx.de/u-boot-atmel.git master for you to fetch changes up to 8bf3c322856f42d4db8acd7fa4f2a17898564064: logo: update to the new logo for ATMEL (2013-04-05 21:49:37 +0200) Josh Wu (1): logo: update to the new logo for ATMEL tools/logos/atmel.bmp | Bin 26334 - 15478 bytes 1 file changed, 0 insertions(+), 0 deletions(-) Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [v3] command/cache: Add flush command
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/05/2013 04:50 PM, York Sun wrote: When we copy code/data to the main memory, we may need to flush the cache if required by architecture. It uses the existing function flush_cache. Syntax is flush addr size The addr and size are given in hexadecimal. Like memory command, there is no sanity check for the parameters. Signed-off-by: York Sun york...@freescale.com --- Change since v2: rename flush_cache to flush Wait, why? flush_cache was clear as to what we were doing, flush less so. At least that's my first reaction. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRXzttAAoJENk4IS6UOR1W3B8QAJAM49Zwv7WP4s6B+77U88wd sFqSoJIJM8djB/BllBYLZUKRc+o7ZfvA35VTzlaok3iqVec5v0Lk25ylDwebHr5f Ucj2p/WV8wXlNDYq+6mNbHPQ5qiRihQxpwKHv3Dk9B5wtG18rxIxRvYVq/lqAsMp AWzuFNyFqRmFIXAly5QcBgJLuFs9FcwL0mKQUuwGHlgkyrswnSbMuQiXwpvO9YkX cy8zC4UhIgtGu+SQdUB5/CFB8Q7oZW3yXXeWRlMUdq7vEzsWIjslnz6qhIihGGcW WnIiN7f9PY3q1UKFBZg2s+/xsUOQmxeVDbYqOi0/IuarinusWgKKcuyKfM6KgZGz 6kJ4wOSUg1xzSYB3brRRT8VchT2hCIJ9Iemm+M2kS6TP4LljZk/p93HrugPwtLXW gJbBC8TquNY8xst0fWHgREcVS0M0QAmqy2xtYAx7L6yg8aZAVBzvZi+UOV5oN5k9 jIK/scnU+mTiNkBKAfwQoTIJ8XrBQWZ0cGYsZW694U5a45FnVFqFFcqWxHuRG7XV Q3ZsySoC459g31sS5jHorYSBID6RQoebsXexxze3BmfNHZM5HN99y/IssBExkivG KOMQUHrwFKOJUy2JAdZStBm02/P4uSm6AzTS9UYKdp09ze4IiqzbXh0WedvNsJui WHBXfW68ts4nyTBhGkA3 =6vnO -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [v3] command/cache: Add flush command
On 04/05/2013 02:00 PM, Tom Rini wrote: On 04/05/2013 04:50 PM, York Sun wrote: When we copy code/data to the main memory, we may need to flush the cache if required by architecture. It uses the existing function flush_cache. Syntax is flush addr size The addr and size are given in hexadecimal. Like memory command, there is no sanity check for the parameters. Signed-off-by: York Sun york...@freescale.com --- Change since v2: rename flush_cache to flush Wait, why? flush_cache was clear as to what we were doing, flush less so. At least that's my first reaction. Scott suggested the underscore is not recommended for the command name. Shall I change it to cacheflush or flushcache? York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [v3] command/cache: Add flush command
Dear York Sun, In message 1365195056-20188-1-git-send-email-york...@freescale.com you wrote: When we copy code/data to the main memory, we may need to flush the cache if required by architecture. It uses the existing function flush_cache. Syntax is flush addr size Plain flush is way too generic a name. I think we should make it clear from the command invocation that we are dealing with caches here. Actually I think we should not even use a new command for this - we already have the dcahe and icache commands for this purpose. What do you think about implementiung this as a subcommand to dcache? Something like: So far: dcache on dcache off adding new: dcache flush= flush all dcache flush addr size = flush range I think this makes more sense. Comments? Best regards, Wolfgang Denk -- 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: w...@denx.de It is surely a great calamity for a human being to have no ob- sessions.- Robert Bly ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/mpc85xx: Clear L1 D-cache lock
Dear York Sun, In message 1365193024-11701-1-git-send-email-york...@freescale.com you wrote: dcbi instruction has been used to clear D-cache lock. However, the cache lock is presistent for e6500 core. Use dcblc to clear the lock explicitly. s/presistent/persistent/ ? Best regards, Wolfgang Denk -- 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: w...@denx.de I paid too much for it, but its worth it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] power: exynos-tmu: fix warnings and clean up code
From: Naveen Krishna Chatradhi ch.nav...@samsung.com
This patch does the folowing
1. change the data types for unsigned int variable to unsigned
2. change the tmu_base type to struct exynos5_tmu_reg *
3. Add timer functionality for get_cur_temp()
4. error handling in the get_tmu_fdt_values()
5. Add check for curr_temp reading
6. some cosmotic changes.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Reviewed-by: Vadim Bendebury vben...@google.com
---
arch/arm/include/asm/arch-exynos/tmu.h | 58 +++--
drivers/power/exynos-tmu.c | 112 ++--
2 files changed, 90 insertions(+), 80 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/tmu.h
b/arch/arm/include/asm/arch-exynos/tmu.h
index 7e0158e..cad3569 100644
--- a/arch/arm/include/asm/arch-exynos/tmu.h
+++ b/arch/arm/include/asm/arch-exynos/tmu.h
@@ -21,38 +21,30 @@
#define __ASM_ARCH_TMU_H
struct exynos5_tmu_reg {
- unsigned triminfo;
- unsigned rsvd1;
- unsigned rsvd2;
- unsigned rsvd3;
- unsigned rsvd4;
- unsigned triminfo_control;
- unsigned rsvd5;
- unsigned rsvd6;
- unsigned tmu_control;
- unsigned rsvd7;
- unsigned tmu_status;
- unsigned sampling_internal;
- unsigned counter_value0;
- unsigned counter_value1;
- unsigned rsvd8;
- unsigned rsvd9;
- unsigned current_temp;
- unsigned rsvd10;
- unsigned rsvd11;
- unsigned rsvd12;
- unsigned threshold_temp_rise;
- unsigned threshold_temp_fall;
- unsigned rsvd13;
- unsigned rsvd14;
- unsigned past_temp3_0;
- unsigned past_temp7_4;
- unsigned past_temp11_8;
- unsigned past_temp15_12;
- unsigned inten;
- unsigned intstat;
- unsigned intclear;
- unsigned rsvd15;
- unsigned emul_con;
+ u32 triminfo;
+ u32 rsvd1[4];
+ u32 triminfo_control;
+ u32 rsvd5[2];
+ u32 tmu_control;
+ u32 rsvd7;
+ u32 tmu_status;
+ u32 sampling_internal;
+ u32 counter_value0;
+ u32 counter_value1;
+ u32 rsvd8[2];
+ u32 current_temp;
+ u32 rsvd10[3];
+ u32 threshold_temp_rise;
+ u32 threshold_temp_fall;
+ u32 rsvd13[2];
+ u32 past_temp3_0;
+ u32 past_temp7_4;
+ u32 past_temp11_8;
+ u32 past_temp15_12;
+ u32 inten;
+ u32 intstat;
+ u32 intclear;
+ u32 rsvd15;
+ u32 emul_con;
};
#endif /* __ASM_ARCH_TMU_H */
diff --git a/drivers/power/exynos-tmu.c b/drivers/power/exynos-tmu.c
index d4b3e65..6d74bc7 100644
--- a/drivers/power/exynos-tmu.c
+++ b/drivers/power/exynos-tmu.c
@@ -50,15 +50,15 @@
/* Tmeperature threshold values for various thermal events */
struct temperature_params {
/* minimum value in temperature code range */
- unsigned int min_val;
+ unsigned min_val;
/* maximum value in temperature code range */
- unsigned int max_val;
+ unsigned max_val;
/* temperature threshold to start warning */
- unsigned int start_warning;
+ unsigned start_warning;
/* temperature threshold CPU tripping */
- unsigned int start_tripping;
+ unsigned start_tripping;
/* temperature threshold for HW tripping */
- unsigned int hardware_tripping;
+ unsigned hardware_tripping;
};
/* Pre-defined values and thresholds for calibration of current temperature */
@@ -66,25 +66,25 @@ struct tmu_data {
/* pre-defined temperature thresholds */
struct temperature_params ts;
/* pre-defined efuse range minimum value */
- unsigned int efuse_min_value;
+ unsigned efuse_min_value;
/* pre-defined efuse value for temperature calibration */
- unsigned int efuse_value;
+ unsigned efuse_value;
/* pre-defined efuse range maximum value */
- unsigned int efuse_max_value;
+ unsigned efuse_max_value;
/* current temperature sensing slope */
- unsigned int slope;
+ unsigned slope;
};
/* TMU device specific details and status */
struct tmu_info {
/* base Address for the TMU */
- unsigned tmu_base;
+ struct exynos5_tmu_reg *tmu_base;
/* pre-defined values for calibration and thresholds */
struct tmu_data data;
/* value required for triminfo_25 calibration */
- unsigned int te1;
+ unsigned te1;
/* value required for triminfo_85 calibration */
- unsigned int te2;
+ unsigned te2;
/* Value for measured data calibration */
int dc_value;
/* enum value indicating status of the TMU */
@@ -103,17 +103,24 @@ static struct tmu_info gbl_info;
*/
static int get_cur_temp(struct tmu_info *info)
{
- int cur_temp;
- struct exynos5_tmu_reg *reg = (struct exynos5_tmu_reg *)info-tmu_base;
+ struct exynos5_tmu_reg *reg = info-tmu_base;
+ ulong start;
+
[U-Boot] [PATCH 2/2] power: exynos-tmu: use the mux_addr bit fields in tmu_control register
From: Naveen Krishna Chatradhi ch.nav...@samsung.com
This patch implements the mux_addr bit fields defined in tmu_control
register (used for debugging purpose)
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Reviewed-by: Vadim Bendebury vben...@google.com
---
drivers/power/exynos-tmu.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/power/exynos-tmu.c b/drivers/power/exynos-tmu.c
index 6d74bc7..9a093a5 100644
--- a/drivers/power/exynos-tmu.c
+++ b/drivers/power/exynos-tmu.c
@@ -79,6 +79,8 @@ struct tmu_data {
struct tmu_info {
/* base Address for the TMU */
struct exynos5_tmu_reg *tmu_base;
+ /* mux Address for the TMU */
+ int tmu_mux;
/* pre-defined values for calibration and thresholds */
struct tmu_data data;
/* value required for triminfo_25 calibration */
@@ -204,6 +206,13 @@ static int get_tmu_fdt_values(struct tmu_info *info, const
void *blob)
}
info-tmu_base = (struct exynos5_tmu_reg *)addr;
+ /* Optional field. */
+ info-tmu_mux = fdtdec_get_int(blob,
+ node, samsung,mux, -1);
+ /* Take default value as per the user manual b(110) */
+ if (info-tmu_mux == -1)
+ info-tmu_mux = 0x6;
+
info-data.ts.min_val = fdtdec_get_int(blob,
node, samsung,min-temp, -1);
error |= (info-data.ts.min_val == -1);
@@ -307,7 +316,7 @@ static void tmu_setup_parameters(struct tmu_info *info)
/* TMU core enable */
con = readl(reg-tmu_control);
- con |= THERM_TRIP_EN | CORE_EN;
+ con |= THERM_TRIP_EN | CORE_EN | (info-tmu_mux 20);
writel(con, reg-tmu_control);
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [v3] command/cache: Add flush command
On 04/05/2013 03:09 PM, Wolfgang Denk wrote: Dear York Sun, In message 1365195056-20188-1-git-send-email-york...@freescale.com you wrote: When we copy code/data to the main memory, we may need to flush the cache if required by architecture. It uses the existing function flush_cache. Syntax is flush addr size Plain flush is way too generic a name. I think we should make it clear from the command invocation that we are dealing with caches here. Actually I think we should not even use a new command for this - we already have the dcahe and icache commands for this purpose. What do you think about implementiung this as a subcommand to dcache? Something like: So far: dcache on dcache off adding new: dcache flush= flush all dcache flush addr size = flush range I think this makes more sense. Comments? It would if the command only deals with dcache. This command flushes dcache _and_ invalidates icache. If flush_cache is acceptable, we can use v2. If not, please suggest one. My candidates are flushcache, cacheflush. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [v2] powerpc/mpc85xx: Clear L1 D-cache lock
dcbi instruction has been used to clear D-cache lock. However, the cache lock is persistent for e6500 core. Use dcblc to clear the lock explicitly. Signed-off-by: York Sun york...@freescale.com --- Change since v1: fix typo s/presistent/persistent/ arch/powerpc/cpu/mpc85xx/start.S |1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S index 4acfeb4..481b6f6 100644 --- a/arch/powerpc/cpu/mpc85xx/start.S +++ b/arch/powerpc/cpu/mpc85xx/start.S @@ -2045,6 +2045,7 @@ unlock_ram_in_cache: slwir4,r4,(10 - 1 - L1_CACHE_SHIFT) mtctr r4 1: dcbir0,r3 + dcblc r0,r3 addir3,r3,CONFIG_SYS_CACHELINE_SIZE bdnz1b sync -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] crc32: Correct endianness of crc32 result
When crc32 is handled by the hash library, it requires the data to be in big-endian format, since it reads it byte-wise. Thus at present the 'crc32' command reports incorrect data. For example, previously we might see: Peach # crc32 4000 100 CRC32 for 4000 ... 40ff == 0d968558 but instead with the hash library we see: Peach # crc32 4000 100 CRC32 for 4000 ... 40ff == 5885960d Correct this. Signed-off-by: Simon Glass s...@chromium.org Reviewed-by: Vadim Bendebury vben...@google.com --- lib/crc32.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/lib/crc32.c b/lib/crc32.c index 76205da..94720bf 100644 --- a/lib/crc32.c +++ b/lib/crc32.c @@ -10,6 +10,7 @@ #ifndef USE_HOSTCC #include common.h +#include asm/unaligned.h #endif #include compiler.h #include u-boot/crc.h @@ -256,5 +257,10 @@ void crc32_wd_buf(const unsigned char *input, unsigned int ilen, uint32_t crc; crc = crc32_wd(0, input, ilen, chunk_sz); +#ifdef USE_HOSTCC + crc = htobe32(crc); memcpy(output, crc, sizeof(crc)); +#else + put_unaligned_be32(crc, output); +#endif } -- 1.8.1.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] env: fix potential stack overflow in environment functions
On 04/05/2013 01:47:12 PM, Wolfgang Denk wrote: Dear Rob, In message 515f1504.4090...@gmail.com you wrote: If the stack is all of RAM, then what address should the initrd and dtb be copied to? Why do they have to be copied at all? Why cannot they remain where they have been loaded in the firtst place? The memcpy just costs time, which is a precious resource. Leave it to the user to find a reasonable location in RAM where he loads the data, and don't mess with it. I've got no freaking idea! I do turn that crap off in my environment with initrd_high=0x. But the default operation is to copy it. Scott, Andy: I think I remember that some architectures really _need_ LMB - can you please shed a bit ligh on which these are, and why? And why it is enabled everywhere? Also, any information about the underlying design, intended memory map etc. would be highly welcome. CCing Kumar, who added a lot of the lmb stuff -- but it looks like ramdisk copying predated lmb. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] crc32: Correct endianness of crc32 result
On Fri, Apr 05, 2013 at 04:11:10PM -0700, Simon Glass wrote: When crc32 is handled by the hash library, it requires the data to be in big-endian format, since it reads it byte-wise. Thus at present the 'crc32' command reports incorrect data. For example, previously we might see: Peach # crc32 4000 100 CRC32 for 4000 ... 40ff == 0d968558 but instead with the hash library we see: Peach # crc32 4000 100 CRC32 for 4000 ... 40ff == 5885960d Correct this. Signed-off-by: Simon Glass s...@chromium.org Reviewed-by: Vadim Bendebury vben...@google.com --- lib/crc32.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/lib/crc32.c b/lib/crc32.c index 76205da..94720bf 100644 --- a/lib/crc32.c +++ b/lib/crc32.c @@ -10,6 +10,7 @@ #ifndef USE_HOSTCC #include common.h +#include asm/unaligned.h #endif #include compiler.h #include u-boot/crc.h @@ -256,5 +257,10 @@ void crc32_wd_buf(const unsigned char *input, unsigned int ilen, uint32_t crc; crc = crc32_wd(0, input, ilen, chunk_sz); +#ifdef USE_HOSTCC + crc = htobe32(crc); memcpy(output, crc, sizeof(crc)); +#else + put_unaligned_be32(crc, output); +#endif } -- 1.8.1.3 Tested on Tegra114 Dalmore, verified crc32 comes out as expected now. Reviewed-by: Allen Martin amar...@nvidia.com Tested-by: Allen Martin amar...@nvidia.com -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] iomux-v3: Place pad control definitions into common file
From: Fabio Estevam fabio.este...@freescale.com
Instead of having the same PAD control definition in each MX6 variant pin file,
place it into a common location.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
arch/arm/include/asm/arch-mx6/mx6dl_pins.h | 27 ---
arch/arm/include/asm/arch-mx6/mx6q_pins.h | 27 ---
arch/arm/include/asm/imx-common/iomux-v3.h | 26 ++
3 files changed, 26 insertions(+), 54 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx6/mx6dl_pins.h
b/arch/arm/include/asm/arch-mx6/mx6dl_pins.h
index 9846f1b..0ed12f3 100644
--- a/arch/arm/include/asm/arch-mx6/mx6dl_pins.h
+++ b/arch/arm/include/asm/arch-mx6/mx6dl_pins.h
@@ -22,33 +22,6 @@
#include asm/imx-common/iomux-v3.h
-/* Use to set PAD control */
-#define PAD_CTL_HYS(1 16)
-#define PAD_CTL_PUS_100K_DOWN (0 14)
-#define PAD_CTL_PUS_47K_UP (1 14)
-#define PAD_CTL_PUS_100K_UP(2 14)
-#define PAD_CTL_PUS_22K_UP (3 14)
-
-#define PAD_CTL_PUE(1 13)
-#define PAD_CTL_PKE(1 12)
-#define PAD_CTL_ODE(1 11)
-#define PAD_CTL_SPEED_LOW (1 6)
-#define PAD_CTL_SPEED_MED (2 6)
-#define PAD_CTL_SPEED_HIGH (3 6)
-#define PAD_CTL_DSE_DISABLE(0 3)
-#define PAD_CTL_DSE_240ohm (1 3)
-#define PAD_CTL_DSE_120ohm (2 3)
-#define PAD_CTL_DSE_80ohm (3 3)
-#define PAD_CTL_DSE_60ohm (4 3)
-#define PAD_CTL_DSE_48ohm (5 3)
-#define PAD_CTL_DSE_40ohm (6 3)
-#define PAD_CTL_DSE_34ohm (7 3)
-#define PAD_CTL_SRE_FAST (1 0)
-#define PAD_CTL_SRE_SLOW (0 0)
-
-#define IOMUX_CONFIG_SION 0x10
-#define NO_MUX_I0
-#define NO_PAD_I0
enum {
MX6_PAD_CSI0_DAT10__UART1_TXD = IOMUX_PAD(0x0360, 0x004C, 3,
0x, 0, 0),
MX6_PAD_CSI0_DAT11__UART1_RXD = IOMUX_PAD(0x0364, 0x0050, 3,
0x08FC, 1, 0),
diff --git a/arch/arm/include/asm/arch-mx6/mx6q_pins.h
b/arch/arm/include/asm/arch-mx6/mx6q_pins.h
index 1c1c008..02a40d4 100644
--- a/arch/arm/include/asm/arch-mx6/mx6q_pins.h
+++ b/arch/arm/include/asm/arch-mx6/mx6q_pins.h
@@ -24,33 +24,6 @@
#include asm/imx-common/iomux-v3.h
-/* Use to set PAD control */
-#define PAD_CTL_HYS(1 16)
-#define PAD_CTL_PUS_100K_DOWN (0 14)
-#define PAD_CTL_PUS_47K_UP (1 14)
-#define PAD_CTL_PUS_100K_UP(2 14)
-#define PAD_CTL_PUS_22K_UP (3 14)
-
-#define PAD_CTL_PUE(1 13)
-#define PAD_CTL_PKE(1 12)
-#define PAD_CTL_ODE(1 11)
-#define PAD_CTL_SPEED_LOW (1 6)
-#define PAD_CTL_SPEED_MED (2 6)
-#define PAD_CTL_SPEED_HIGH (3 6)
-#define PAD_CTL_DSE_DISABLE(0 3)
-#define PAD_CTL_DSE_240ohm (1 3)
-#define PAD_CTL_DSE_120ohm (2 3)
-#define PAD_CTL_DSE_80ohm (3 3)
-#define PAD_CTL_DSE_60ohm (4 3)
-#define PAD_CTL_DSE_48ohm (5 3)
-#define PAD_CTL_DSE_40ohm (6 3)
-#define PAD_CTL_DSE_34ohm (7 3)
-#define PAD_CTL_SRE_FAST (1 0)
-#define PAD_CTL_SRE_SLOW (0 0)
-
-#define NO_MUX_I0
-#define NO_PAD_I0
-
enum {
MX6_PAD_SD2_DAT1__USDHC2_DAT1 = IOMUX_PAD(0x0360, 0x004C, 0,
0x, 0, 0),
MX6_PAD_SD2_DAT1__ECSPI5_SS0= IOMUX_PAD(0x0360, 0x004C, 1,
0x0834, 0, 0),
diff --git a/arch/arm/include/asm/imx-common/iomux-v3.h
b/arch/arm/include/asm/imx-common/iomux-v3.h
index c34bb76..32126a7 100644
--- a/arch/arm/include/asm/imx-common/iomux-v3.h
+++ b/arch/arm/include/asm/imx-common/iomux-v3.h
@@ -97,6 +97,32 @@ typedef u64 iomux_v3_cfg_t;
#define MUX_CONFIG_SION(0x1 4)
+#define PAD_CTL_HYS(1 16)
+#define PAD_CTL_PUS_100K_DOWN (0 14)
+#define PAD_CTL_PUS_47K_UP (1 14)
+#define PAD_CTL_PUS_100K_UP(2 14)
+#define PAD_CTL_PUS_22K_UP (3 14)
+
+#define PAD_CTL_PUE(1 13)
+#define PAD_CTL_PKE(1 12)
+#define PAD_CTL_ODE(1 11)
+#define PAD_CTL_SPEED_LOW (1 6)
+#define PAD_CTL_SPEED_MED (2 6)
+#define PAD_CTL_SPEED_HIGH (3 6)
+#define PAD_CTL_DSE_DISABLE(0 3)
+#define PAD_CTL_DSE_240ohm (1 3)
+#define PAD_CTL_DSE_120ohm (2 3)
+#define PAD_CTL_DSE_80ohm (3 3)
+#define PAD_CTL_DSE_60ohm (4 3)
+#define PAD_CTL_DSE_48ohm (5 3)
+#define PAD_CTL_DSE_40ohm (6 3)
+#define PAD_CTL_DSE_34ohm (7 3)
+#define PAD_CTL_SRE_FAST (1 0)
+#define PAD_CTL_SRE_SLOW (0 0)
+
+#define NO_MUX_I0
+#define NO_PAD_I0
+
int imx_iomux_v3_setup_pad(iomux_v3_cfg_t pad);
int imx_iomux_v3_setup_multiple_pads(iomux_v3_cfg_t const *pad_list,
unsigned count);
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] mx6: Add solo-lite variant support
From: Fabio Estevam fabio.este...@freescale.com
mx6 solo-lite is another member of the mx6 series.
For more information about mx6 solo-lite, please visit:
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX6SLnodeId=018rH3ZrDRB24A
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
arch/arm/cpu/armv7/mx6/clock.c | 38 -
arch/arm/include/asm/arch-mx6/crm_regs.h |5 +++
arch/arm/include/asm/arch-mx6/imx-regs.h | 63 +++-
arch/arm/include/asm/arch-mx6/mx6-pins.h |4 ++
arch/arm/include/asm/arch-mx6/mx6sl_pins.h | 25 +++
5 files changed, 132 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/include/asm/arch-mx6/mx6sl_pins.h
diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
index a50db70..8cba4fd 100644
--- a/arch/arm/cpu/armv7/mx6/clock.c
+++ b/arch/arm/cpu/armv7/mx6/clock.c
@@ -186,12 +186,16 @@ static u32 get_ipg_per_clk(void)
static u32 get_uart_clk(void)
{
u32 reg, uart_podf;
-
+ u32 freq = PLL3_80M;
reg = __raw_readl(imx_ccm-cscdr1);
+#ifdef CONFIG_MX6SL
+ if (reg MXC_CCM_CSCDR1_UART_CLK_SEL)
+ freq = MXC_HCLK;
+#endif
reg = MXC_CCM_CSCDR1_UART_CLK_PODF_MASK;
uart_podf = reg MXC_CCM_CSCDR1_UART_CLK_PODF_OFFSET;
- return PLL3_80M / (uart_podf + 1);
+ return freq / (uart_podf + 1);
}
static u32 get_cspi_clk(void)
@@ -252,6 +256,35 @@ static u32 get_emi_slow_clk(void)
return root_freq / (emi_slow_pof + 1);
}
+#ifdef CONFIG_MX6SL
+static u32 get_mmdc_ch0_clk(void)
+{
+ u32 cbcmr = __raw_readl(imx_ccm-cbcmr);
+ u32 cbcdr = __raw_readl(imx_ccm-cbcdr);
+ u32 freq, podf;
+
+ podf = (cbcdr MXC_CCM_CBCDR_MMDC_CH1_PODF_MASK) \
+MXC_CCM_CBCDR_MMDC_CH1_PODF_OFFSET;
+
+ switch ((cbcmr MXC_CCM_CBCMR_PRE_PERIPH2_CLK_SEL_MASK)
+ MXC_CCM_CBCMR_PRE_PERIPH2_CLK_SEL_OFFSET) {
+ case 0:
+ freq = decode_pll(PLL_BUS, MXC_HCLK);
+ break;
+ case 1:
+ freq = PLL2_PFD2_FREQ;
+ break;
+ case 2:
+ freq = PLL2_PFD0_FREQ;
+ break;
+ case 3:
+ freq = PLL2_PFD2_DIV_FREQ;
+ }
+
+ return freq / (podf + 1);
+
+}
+#else
static u32 get_mmdc_ch0_clk(void)
{
u32 cbcdr = __raw_readl(imx_ccm-cbcdr);
@@ -260,6 +293,7 @@ static u32 get_mmdc_ch0_clk(void)
return get_periph_clk() / (mmdc_ch0_podf + 1);
}
+#endif
static u32 get_usdhc_clk(u32 port)
{
diff --git a/arch/arm/include/asm/arch-mx6/crm_regs.h
b/arch/arm/include/asm/arch-mx6/crm_regs.h
index 7676457..b1ed62f 100644
--- a/arch/arm/include/asm/arch-mx6/crm_regs.h
+++ b/arch/arm/include/asm/arch-mx6/crm_regs.h
@@ -244,7 +244,12 @@ struct mxc_ccm_reg {
#define MXC_CCM_CSCDR1_USBOH3_CLK_PRED_MASK(0x7 8)
#define MXC_CCM_CSCDR1_USBOH3_CLK_PODF_OFFSET 6
#define MXC_CCM_CSCDR1_USBOH3_CLK_PODF_MASK(0x3 6)
+#ifdef CONFIG_MX6SL
+#define MXC_CCM_CSCDR1_UART_CLK_PODF_MASK 0x1F
+#define MXC_CCM_CSCDR1_UART_CLK_SEL(1 6)
+#else
#define MXC_CCM_CSCDR1_UART_CLK_PODF_MASK 0x3F
+#endif
#define MXC_CCM_CSCDR1_UART_CLK_PODF_OFFSET0
/* Define the bits in register CS1CDR */
diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h
b/arch/arm/include/asm/arch-mx6/imx-regs.h
index eaa7439..2d8fe69 100644
--- a/arch/arm/include/asm/arch-mx6/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx6/imx-regs.h
@@ -25,6 +25,13 @@
#define ROMCP_ARB_BASE_ADDR 0x
#define ROMCP_ARB_END_ADDR 0x000F
+
+#ifdef CONFIG_MX6SL
+#define GPU_2D_ARB_BASE_ADDR0x0220
+#define GPU_2D_ARB_END_ADDR 0x02203FFF
+#define OPENVG_ARB_BASE_ADDR0x02204000
+#define OPENVG_ARB_END_ADDR 0x02207FFF
+#else
#define CAAM_ARB_BASE_ADDR 0x0010
#define CAAM_ARB_END_ADDR 0x00103FFF
#define APBH_DMA_ARB_BASE_ADDR 0x0011
@@ -37,9 +44,14 @@
#define GPU_2D_ARB_END_ADDR 0x00137FFF
#define DTCP_ARB_BASE_ADDR 0x00138000
#define DTCP_ARB_END_ADDR 0x0013BFFF
-
+#endif /* CONFIG_MX6SL */
/* GPV - PL301 configuration ports */
+#ifdef CONFIG_MX6SL
+#define GPV2_BASE_ADDR 0x00D0
+#else
#define GPV2_BASE_ADDR 0x0020
+#endif
+
#define GPV3_BASE_ADDR 0x0030
#define GPV4_BASE_ADDR 0x0080
#define IRAM_BASE_ADDR 0x0090
@@ -70,10 +82,17 @@
#define WEIM_ARB_BASE_ADDR 0x0800
#define WEIM_ARB_END_ADDR 0x0FFF
+#ifdef CONFIG_MX6SL
+#define MMDC0_ARB_BASE_ADDR 0x8000
+#define MMDC0_ARB_END_ADDR 0x
+#define MMDC1_ARB_BASE_ADDR 0xC000
+#define MMDC1_ARB_END_ADDR
[U-Boot] [PATCH 3/3] mx6sl: Add initial support for mx6slevk board
From: Fabio Estevam fabio.este...@freescale.com mx6slevk board is a development board from Freescale based on the mx6 solo-lite processor. For details about mx6slevk, please refer to: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=IMX6SLEVKparentCode=i.MX6SLfpsp=1 Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- MAINTAINERS |1 + board/freescale/mx6slevk/Makefile | 28 + board/freescale/mx6slevk/imximage.cfg | 118 board/freescale/mx6slevk/mx6slevk.c | 102 ++ boards.cfg|1 + include/configs/mx6slevk.h| 189 + 6 files changed, 439 insertions(+) create mode 100644 board/freescale/mx6slevk/Makefile create mode 100644 board/freescale/mx6slevk/imximage.cfg create mode 100644 board/freescale/mx6slevk/mx6slevk.c create mode 100644 include/configs/mx6slevk.h diff --git a/MAINTAINERS b/MAINTAINERS index 0f19078..723a316 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -665,6 +665,7 @@ Fabio Estevam fabio.este...@freescale.com mx6qsabresd i.MX6Q mx6qsabreauto i.MX6Q wandboard i.MX6DL/S + mx6slevki.MX6SL Daniel Gorsulowski daniel.gorsulow...@esd.eu diff --git a/board/freescale/mx6slevk/Makefile b/board/freescale/mx6slevk/Makefile new file mode 100644 index 000..43af351 --- /dev/null +++ b/board/freescale/mx6slevk/Makefile @@ -0,0 +1,28 @@ +# (C) Copyright 2013 Freescale Semiconductor, Inc. +# +# 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. +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).o + +COBJS := mx6slevk.o + +SRCS := $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) + +$(LIB):$(obj).depend $(OBJS) + $(call cmd_link_o_target, $(OBJS)) + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/freescale/mx6slevk/imximage.cfg b/board/freescale/mx6slevk/imximage.cfg new file mode 100644 index 000..df39a16 --- /dev/null +++ b/board/freescale/mx6slevk/imximage.cfg @@ -0,0 +1,118 @@ +/* + * Copyright (C) 2013 Freescale Semiconductor, Inc. + * + * 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. + * + * Refer docs/README.imxmage for more details about how-to configure + * and create imximage boot image + * + * The syntax is taken as close as possible with the kwbimage + */ + +/* image version */ + +IMAGE_VERSION 2 + +/* + * Boot Device : one of + * spi, sd (the board has no nand neither onenand) + */ + +BOOT_FROM sd + +/* + * Device Configuration Data (DCD) + * + * Each entry must have the format: + * Addr-type AddressValue + * + * where: + * Addr-type register length (1,2 or 4 bytes) + * Address absolute address of the register + * value value to be stored in the register + */ +DATA 4 0x020c4018 0x00260324 + +DATA 4 0x020c4068 0x +DATA 4 0x020c406c 0x +DATA 4 0x020c4070 0x +DATA 4 0x020c4074 0x +DATA 4 0x020c4078 0x +DATA 4 0x020c407c 0x +DATA 4 0x020c4080 0x + +DATA 4 0x020e0344 0x3030 +DATA 4 0x020e0348 0x3030 +DATA 4 0x020e034c 0x3030 +DATA 4 0x020e0350 0x3030 +DATA 4 0x020e030c 0x0030 +DATA 4 0x020e0310 0x0030 +DATA 4 0x020e0314 0x0030 +DATA 4 0x020e0318 0x0030 +DATA 4 0x020e0300 0x0030 +DATA 4 0x020e031c 0x0030 +DATA 4 0x020e0338 0x0028 +DATA 4 0x020e0320 0x0030 +DATA 4 0x020e032c 0x +DATA 4 0x020e033c 0x0008 +DATA 4 0x020e0340 0x0008 +DATA 4 0x020e05c4 0x0030 +DATA 4 0x020e05cc 0x0030 +DATA 4 0x020e05d4 0x0030 +DATA 4 0x020e05d8 0x0030 +DATA 4 0x020e05ac 0x0030 +DATA 4 0x020e05c8 0x0030 +DATA 4 0x020e05b0 0x0002 +DATA 4 0x020e05b4 0x +DATA 4 0x020e05c0 0x0002 +DATA 4 0x020e05d0 0x0008 + +DATA 4 0x021b001c 0x8000 +DATA 4 0x021b085c 0x1b4700c7 +DATA 4 0x021b0800 0xa1390003 +DATA 4 0x021b0890 0x0030 +DATA 4 0x021b08b8 0x0800 +DATA 4 0x021b081c 0x +DATA 4 0x021b0820 0x +DATA 4 0x021b0824 0x +DATA 4 0x021b0828 0x +DATA 4 0x021b082c 0xf333 +DATA 4 0x021b0830 0xf333 +DATA 4 0x021b0834 0xf333 +DATA 4 0x021b0838 0xf333 +DATA 4 0x021b0848 0x4241444a +DATA 4 0x021b0850 0x3030312b +DATA 4 0x021b083c 0x2000 +DATA 4 0x021b0840 0x +DATA 4 0x021b08c0 0x24911492 +DATA 4
[U-Boot] [PATCH v4] i2c: s3c24xx: add hsi2c controller support
Add support for hsi2c controller available on exynos5420.
Note: driver currently supports only fast speed mode 100kbps
Change-Id: I02555b1dc8f4ac21c50aa5158179768563c92f43
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Signed-off-by: R. Chandrasekar rc.se...@samsung.com
Reviewed-by: Vadim Bendebury vben...@google.com
Reviewed-by: Simon Glass s...@google.com
---
Changes since v3:
1. Implemented get_timer instead of while and udelay for master busy function
2. Use reg base address from device tree
3. Split the timing function to check for the errors
4. Implemented reset function for to recover from failure cases
5. Implemented a comat string for hsi2c to distingush the channels
6. Minor cosmotic changes
Note: FIFOs will be implemented in subsequent patches
drivers/i2c/s3c24x0_i2c.c | 494 +
drivers/i2c/s3c24x0_i2c.h | 36
2 files changed, 486 insertions(+), 44 deletions(-)
diff --git a/drivers/i2c/s3c24x0_i2c.c b/drivers/i2c/s3c24x0_i2c.c
index 46d2506..32be91b 100644
--- a/drivers/i2c/s3c24x0_i2c.c
+++ b/drivers/i2c/s3c24x0_i2c.c
@@ -50,6 +50,60 @@
#define I2C_NOK_LA 3 /* Lost arbitration */
#define I2C_NOK_TOUT 4 /* time out */
+/* HSI2C specific register description */
+
+/* I2C_CTL Register bits */
+#define HSI2C_FUNC_MODE_I2C(1u 0)
+#define HSI2C_MASTER (1u 3)
+#define HSI2C_RXCHON (1u 6) /* Write/Send */
+#define HSI2C_TXCHON (1u 7) /* Read/Receive */
+#define HSI2C_SW_RST (1u 31)
+
+/* I2C_FIFO_CTL Register bits */
+#define HSI2C_RXFIFO_EN(1u 0)
+#define HSI2C_TXFIFO_EN(1u 1)
+#define HSI2C_TXFIFO_TRIGGER_LEVEL (0x20 16)
+#define HSI2C_RXFIFO_TRIGGER_LEVEL (0x20 4)
+
+/* I2C_TRAILING_CTL Register bits */
+#define HSI2C_TRAILING_COUNT (0xff)
+
+/* I2C_INT_EN Register bits */
+#define HSI2C_INT_TX_ALMOSTEMPTY_EN(1u 0)
+#define HSI2C_INT_RX_ALMOSTFULL_EN (1u 1)
+#define HSI2C_INT_TRAILING_EN (1u 6)
+#define HSI2C_INT_I2C_EN (1u 9)
+
+/* I2C_CONF Register bits */
+#define HSI2C_AUTO_MODE(1u 31)
+#define HSI2C_10BIT_ADDR_MODE (1u 30)
+#define HSI2C_HS_MODE (1u 29)
+
+/* I2C_AUTO_CONF Register bits */
+#define HSI2C_READ_WRITE (1u 16)
+#define HSI2C_STOP_AFTER_TRANS (1u 17)
+#define HSI2C_MASTER_RUN (1u 31)
+
+/* I2C_TIMEOUT Register bits */
+#define HSI2C_TIMEOUT_EN (1u 31)
+
+/* I2C_TRANS_STATUS register bits */
+#define HSI2C_MASTER_BUSY (1u 17)
+#define HSI2C_SLAVE_BUSY (1u 16)
+#define HSI2C_NO_DEV (1u 3)
+#define HSI2C_NO_DEV_ACK (1u 2)
+#define HSI2C_TRANS_ABORT (1u 1)
+#define HSI2C_TRANS_DONE (1u 0)
+#define HSI2C_TIMEOUT_AUTO (0u 0)
+
+#define HSI2C_SLV_ADDR_MAS(x) ((x 0x3ff) 10)
+
+/* Controller operating frequency, timing values for operation
+ * are calculated against this frequency
+ */
+#define HSI2C_FS_TX_CLOCK 100
+
+/* S3C I2C Controller bits */
#define I2CSTAT_BSY0x20/* Busy bit */
#define I2CSTAT_NACK 0x01/* Nack bit */
#define I2CCON_ACKGEN 0x80/* Acknowledge generation */
@@ -61,6 +115,7 @@
#define I2C_TIMEOUT 1 /* 1 second */
+#defineHSI2C_TIMEOUT 100
/*
* For SPL boot some boards need i2c before SDRAM is initialised so force
@@ -73,6 +128,15 @@ static struct s3c24x0_i2c_bus i2c_bus[CONFIG_MAX_I2C_NUM]
__attribute__((section(.data)));
#endif
+static struct s3c24x0_i2c_bus *get_bus(unsigned int bus_idx)
+{
+ if (bus_idx i2c_busses)
+ return i2c_bus[bus_idx];
+
+ debug(Undefined bus: %d\n, bus_idx);
+ return NULL;
+}
+
#if !(defined CONFIG_EXYNOS4 || defined CONFIG_EXYNOS5)
static int GetI2CSDA(void)
{
@@ -113,9 +177,23 @@ static int WaitForXfer(struct s3c24x0_i2c *i2c)
return (readl(i2c-iiccon) I2CCON_IRPND) ? I2C_OK : I2C_NOK_TOUT;
}
-static int IsACK(struct s3c24x0_i2c *i2c)
+static int hsi2c_wait_for_irq(struct exynos5_hsi2c *i2c)
{
- return !(readl(i2c-iicstat) I2CSTAT_NACK);
+ int i = HSI2C_TIMEOUT * 10;
+ int ret = I2C_NOK_TOUT;
+
+ while (i 0) {
+ /* wait for a while and retry */
+ udelay(100);
+ if (readl(i2c-usi_int_stat)
+ (HSI2C_INT_I2C_EN | HSI2C_INT_TX_ALMOSTEMPTY_EN)) {
+ ret = I2C_OK;
+ break;
+ }
+ i--;
+ }
+
+ return ret;
}
static void ReadWriteByte(struct s3c24x0_i2c *i2c)
@@ -123,6 +201,22 @@ static void ReadWriteByte(struct s3c24x0_i2c *i2c)
writel(readl(i2c-iiccon) ~I2CCON_IRPND, i2c-iiccon);
}
+static void
Re: [U-Boot] [PATCH 1/5][v2] powerpc/mpc85xx:No NOR boot, do not compile IFC errata A003399
On 04/06/2013 02:03 AM, Scott Wood wrote: On 03/22/2013 02:07:48 AM, Prabhakar Kushwaha wrote: IFC errata A003399 is valid for IFC NOR boot i.e.if no on-board NOR flash or no NOR boot, do not compile its workaround. Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com --- Based upon git://git.denx.de/u-boot.git branch master Changes for v2: - Add CONFIG_A003399_NOR_WORKAROUND for errata workaround - Add CONFIG_A003399_NOR_WORKAROUND in README README|4 arch/powerpc/cpu/mpc85xx/cpu_init_early.c |9 ++--- arch/powerpc/cpu/mpc8xxx/fsl_ifc.c|2 +- 3 files changed, 11 insertions(+), 4 deletions(-) diff --git a/README b/README index 7f2506a..c4ad69d 100644 --- a/README +++ b/README @@ -414,6 +414,10 @@ The following options need to be configured: See Freescale App Note 4493 for more information about this erratum. +CONFIG_A003399_NOR_WORKAROUND +Enables a workaround for IFC erratum A003399. It is only +requred during NOR boot. + CONFIG_SYS_FSL_CORENET_SNOOPVEC_COREONLY This is the value to write into CCSR offset 0x18600 diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c index dacfdd1..3a4bfc5 100644 --- a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c +++ b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c @@ -25,7 +25,8 @@ DECLARE_GLOBAL_DATA_PTR; -#if defined(CONFIG_SYS_FSL_ERRATUM_IFC_A003399) !defined(CONFIG_SYS_RAMBOOT) +#if defined(CONFIG_SYS_FSL_ERRATUM_IFC_A003399)\ + defined(CONFIG_A003399_NOR_WORKAROUND) Why would CONFIG_A003399_NOR_WORKAROUND be enabled if CONFIG_SYS_FSL_ERRATUM_IFC_A003399 isn't? originally i tried the same but it did not work. As P1010RDB.h does not include config_mpc85xx.h. Only arch/powerpc/cpu/mpc85xx/*.c files includes both P1010RDB.h and config_mpc85xx.h Regards, Prabhakar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5][v2] powerpc/mpc85xx: new SPL support for IFC NAND
On 04/06/2013 02:10 AM, Scott Wood wrote: On 03/22/2013 02:08:05 AM, Prabhakar Kushwaha wrote: diff --git a/board/freescale/common/Makefile b/board/freescale/common/Makefile index 75725b4..a4d521c 100644 --- a/board/freescale/common/Makefile +++ b/board/freescale/common/Makefile @@ -29,6 +29,15 @@ endif LIB= $(obj)libfreescale.o +MINIMAL= + +ifdef CONFIG_SPL_BUILD +ifdef CONFIG_SPL_INIT_MINIMAL +MINIMAL=y +endif +endif + +ifndef MINIMAL COBJS-$(CONFIG_FSL_CADMUS)+= cadmus.o COBJS-$(CONFIG_FSL_VIA)+= cds_via.o COBJS-$(CONFIG_FMAN_ENET)+= fman.o @@ -62,6 +71,7 @@ SUBLIB-$(CONFIG_P3041DS)+= p_corenet/libp_corenet.o SUBLIB-$(CONFIG_P4080DS)+= p_corenet/libp_corenet.o SUBLIB-$(CONFIG_P5020DS)+= p_corenet/libp_corenet.o SUBLIB-$(CONFIG_P5040DS)+= p_corenet/libp_corenet.o +endif SRCS:= $(SOBJS:.o=.S) $(COBJS-y:.o=.c) OBJS:= $(addprefix $(obj),$(COBJS-y)) If this is needed to avoid pulling in any files from this directory, why did p1_p2_rdb_pc not need this? Is there a particular file that is failing to build or failing to get optimized away I cannot avoid this directory :(. because new SPL compile this directory even after undef QIXIS defines #ifndef CONFIG_SPL_BUILD #define CONFIG_FSL_QIXIS #endif make[3]: Leaving directory `/home/b32579/Workspace/MERGE/OPENSRC/U-BOOT/u-boot/board/freescale/bsc9132qds' make -C /home/b32579/Workspace/MERGE/OPENSRC/U-BOOT/u-boot/board/freescale/common/ make[3]: Entering directory `/home/b32579/Workspace/MERGE/OPENSRC/U-BOOT/u-boot/board/freescale/common' -- -- /opt/freescale/usr/local/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc-linux-gnu-gcc -g -Os -fpic -mrelocatable -ffunction-sections -fdata-sections -meabi -D__KERNEL__ -ffunction-sections -fdata-sections -DCONFIG_SYS_TEXT_BASE=0x00201000 -DCONFIG_SPL_TEXT_BASE=0xE000 -DCONFIG_SPL_BUILD -I/home/b32579/Workspace/MERGE/OPENSRC/U-BOOT/u-boot/include -fno-builtin -ffreestanding -nostdinc -isystem /opt/freescale/usr/local/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/lib/gcc/powerpc-linux-gnu/4.5.1/include -pipe -DCONFIG_PPC -D__powerpc__ -ffixed-r2 -Wa,-me500 -msoft-float -mno-string -mspe=yes -mno-spe -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -o /home/b32579/Workspace/MERGE/OPENSRC/U-BOOT/u-boot/spl/board/freescale/common/qixis.o qixis.c -c qixis.c: In function 'qixis_read': --- qixis.c:36:20: error: 'QIXIS_BASE' undeclared (first use in this function) qixis.c:36:20: note: each undeclared identifier is reported only once for each function it appears in make: *** [BSC9132QDS_NAND_DDRCLK133] Error 2 Regards, Prabhakar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] freescale i.MX28 mxsboot NAND booting on mx28evk bad blocks
On 4/4/2013 3:09 AM, Trent Piepho wrote: It's something to do with the way u-boot writes to nand. If I write with nandwrite it doesn't happen, nandtest doesn't find any bad Hmm, I'm pretty sure I tested burning the u-boot generated nand image with nandwrite under Linux with exactly the same result, it seems to be inherent in the underlying data, not the burn method. Did you use the --oob option to nandwrite? The u-boot generated image is actually written in two separate steps, the initial piece is written raw and includes oob data, the second piece is written normally and the ecc/oob is generated by the hardware. To burn it under linux, you need to split the u-boot nand image into those two pieces, and write the first with -oob, and the second normally. A bad block on that chip is marked with a non-0xff as the first OOB byte in the 1st page of a block. So, my guess is that when u-boot writes the FCB data it also writes something to the OOB data. Yes, as would linux if you used the --oob option to nandwrite. You said you've booted from NAND. Did you have to program any of the OTP fuses to do this? No. All I did was install the actual NAND chip and update the boot dip switches. Testing u-boot, I followed the script in the default environment other than updating it to load the firmware from SD rather than tftp. For testing under Linux, I used dd to split the u-boot nand image into two pieces, corresponding to the u-boot burn instructions. nandwrite didn't seem to want to program the blocks after they were marked bad. The only way fix this seemed to be to scrub nand from u-boot. So it's a problem if you want to be able to flash the bootloader from Linux, unless there is some way to get the blocks written when they have been marked bad. No, from what I understand there is no way to clear bad block markers from within linux short of modifying the mtd driver. I followed up with Otavio off list, he said he had ordered some nand chips for his board and would get back to me once he had received them and had a chance to replicate the issue. Are you targeting burning the nand with u-boot or linux? If you are using an older kernel, the kobs-ng that comes with the mx28 BSP works fine. It does not work with newer kernels though, there is a newer version of kobs-ng that comes with a different chip BSP that I've heard will work correctly on current kernels, it is on my to do list to try it out. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
