Re: [U-Boot] [PATCH 2/3] fw_env: fix incorrect usage of open(O_CREAT)
Hi,
On Sun, Nov 11, 2012 at 6:47 AM, Mike Frysinger vap...@gentoo.org wrote:
When using open(), the O_CREAT flag must be given a mode, otherwise it
uses random garbage from the stack. Also, it can fail to build:
In file included from /usr/include/fcntl.h:290:0,
from fw_env_main.c:42:
In function 'open',
inlined from 'main' at fw_env_main.c:97:9:
/usr/include/bits/fcntl2.h:50:24: error: call to '__open_missing_mode'
declared
with attribute error: open with O_CREAT in second argument needs 3
arguments
Could someone please pick up this patchset?
http://patchwork.ozlabs.org/patch/198241/
http://patchwork.ozlabs.org/patch/198243/
http://patchwork.ozlabs.org/patch/198242/
make env is currently broken for me.
Thank you!
Regards, Christian
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
tools/env/fw_env_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/env/fw_env_main.c b/tools/env/fw_env_main.c
index c855f4c..40ea3f6 100644
--- a/tools/env/fw_env_main.c
+++ b/tools/env/fw_env_main.c
@@ -94,7 +94,7 @@ int main(int argc, char *argv[])
int lockfd = -1;
int retval = EXIT_SUCCESS;
- lockfd = open(lockname, O_WRONLY | O_CREAT | O_TRUNC);
+ lockfd = open(lockname, O_WRONLY | O_CREAT | O_TRUNC, 0666);
if (-1 == lockfd) {
fprintf(stderr, Error opening lock file %s\n, lockname);
return EXIT_FAILURE;
--
1.7.12.4
___
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] [PATCH v2 01/58] Add architecture-specific global data
We plan to move architecture-specific data into a separate structure so
that we can make the rest of it common.
As a first step, create struct arch_global_data to hold these fields.
Initially it is empty.
This patch applies to all archs at once. I can split it if this is really
a pain.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2:
- Rebase to master
arch/arm/include/asm/global_data.h|6 ++
arch/avr32/include/asm/global_data.h |5 +
arch/blackfin/include/asm/global_data.h |5 +
arch/m68k/include/asm/global_data.h |6 ++
arch/microblaze/include/asm/global_data.h |6 ++
arch/mips/include/asm/global_data.h |5 +
arch/nds32/include/asm/global_data.h |6 ++
arch/nios2/include/asm/global_data.h |5 +
arch/openrisc/include/asm/global_data.h |6 ++
arch/powerpc/include/asm/global_data.h|5 +
arch/sandbox/include/asm/global_data.h|6 ++
arch/sh/include/asm/global_data.h |5 +
arch/sparc/include/asm/global_data.h |5 +
arch/x86/include/asm/global_data.h| 10 --
14 files changed, 79 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/global_data.h
b/arch/arm/include/asm/global_data.h
index 2b9af93..8ca45ca 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -23,6 +23,11 @@
#ifndef__ASM_GBL_DATA_H
#define __ASM_GBL_DATA_H
+
+/* Architecture-specific global data */
+struct arch_global_data {
+};
+
/*
* The following data structure is placed in some memory which is
* available very early after boot (like DPRAM on MPC8xx/MPC82xx, or
@@ -82,6 +87,7 @@ typedef struct global_data {
unsigned long post_log_res; /* success of POST test */
unsigned long post_init_f_time; /* When post_init_f started */
#endif
+ struct arch_global_data arch; /* architecture-specific data */
} gd_t;
#include asm-generic/global_data_flags.h
diff --git a/arch/avr32/include/asm/global_data.h
b/arch/avr32/include/asm/global_data.h
index bf661e2..236a9da 100644
--- a/arch/avr32/include/asm/global_data.h
+++ b/arch/avr32/include/asm/global_data.h
@@ -22,6 +22,10 @@
#ifndef __ASM_GLOBAL_DATA_H__
#define __ASM_GLOBAL_DATA_H__
+/* Architecture-specific global data */
+struct arch_global_data {
+};
+
/*
* The following data structure is placed in some memory wich is
* available very early after boot (like DPRAM on MPC8xx/MPC82xx, or
@@ -48,6 +52,7 @@ typedef struct global_data {
#endif
void**jt; /* jump table */
charenv_buf[32];/* buffer for getenv() before reloc. */
+ struct arch_global_data arch; /* architecture-specific data */
} gd_t;
#include asm-generic/global_data_flags.h
diff --git a/arch/blackfin/include/asm/global_data.h
b/arch/blackfin/include/asm/global_data.h
index d91e5a4..109069f 100644
--- a/arch/blackfin/include/asm/global_data.h
+++ b/arch/blackfin/include/asm/global_data.h
@@ -30,6 +30,10 @@
#include asm/u-boot.h
+/* Architecture-specific global data */
+struct arch_global_data {
+};
+
/*
* The following data structure is placed in some memory wich is
* available very early after boot (like DPRAM on MPC8xx/MPC82xx, or
@@ -57,6 +61,7 @@ typedef struct global_data {
void**jt; /* jump table */
charenv_buf[32];/* buffer for getenv() before reloc. */
+ struct arch_global_data arch; /* architecture-specific data */
} gd_t;
#include asm-generic/global_data_flags.h
diff --git a/arch/m68k/include/asm/global_data.h
b/arch/m68k/include/asm/global_data.h
index 0cdb11c..fd8aacb 100644
--- a/arch/m68k/include/asm/global_data.h
+++ b/arch/m68k/include/asm/global_data.h
@@ -23,6 +23,11 @@
#ifndef__ASM_GBL_DATA_H
#define __ASM_GBL_DATA_H
+
+/* Architecture-specific global data */
+struct arch_global_data {
+};
+
/*
* The following data structure is placed in some memory wich is
* available very early after boot (like DPRAM on MPC8xx/MPC82xx, or
@@ -66,6 +71,7 @@ typedef struct global_data {
#endif
void**jt; /* Standalone app jump table */
charenv_buf[32];/* buffer for getenv() before reloc. */
+ struct arch_global_data arch; /* architecture-specific data */
} gd_t;
#include asm-generic/global_data_flags.h
diff --git a/arch/microblaze/include/asm/global_data.h
b/arch/microblaze/include/asm/global_data.h
index 2111c7c..025131c 100644
--- a/arch/microblaze/include/asm/global_data.h
+++ b/arch/microblaze/include/asm/global_data.h
@@ -24,6 +24,11 @@
#ifndef__ASM_GBL_DATA_H
#define __ASM_GBL_DATA_H
+
+/* Architecture-specific global data */
+struct arch_global_data {
+};
+
/*
* The following data structure is placed in some memory wich is
* available very early after boot (like DPRAM
[U-Boot] [PATCH v2] mpc5200: Add a4m2k board port
This patch adds the a4m2k MPC5200B board port. Its a derivate of
the a3m071 board with only minor changes.
Additionally this patch includes some clean-up changes:
- Remove I2C support from a3m071 as its unused
- Fix/enhance default env variables
- Fix some comments
- Add newly introduced CONFIG_SPL_TARGET to automatically build
u-boot-img.bin
Signed-off-by: Stefan Roese s...@denx.de
---
v2:
- Enable CAN1 on I2C in GPS Port Configuration for a4m2k
MAINTAINERS| 1 +
board/a3m071/a3m071.c | 91 +---
board/a3m071/is46r16320d.h | 35 ++
boards.cfg | 1 +
include/configs/a3m071.h | 112 ++---
5 files changed, 186 insertions(+), 54 deletions(-)
create mode 100644 board/a3m071/is46r16320d.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 428b006..e48288f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -389,6 +389,7 @@ Ricardo Ribalda ricardo.riba...@uam.es
Stefan Roese s...@denx.de
a3m071 MPC5200
+ a4m2k MPC5200
P3M7448 MPC7448
diff --git a/board/a3m071/a3m071.c b/board/a3m071/a3m071.c
index 89ced82..0a86e9a 100644
--- a/board/a3m071/a3m071.c
+++ b/board/a3m071/a3m071.c
@@ -24,10 +24,15 @@
#include mpc5xxx.h
#include pci.h
#include miiphy.h
+#include linux/compiler.h
#include asm/processor.h
#include asm/io.h
+#ifdef CONFIG_A4M2K
+#include is46r16320d.h
+#else
#include mt46v16m16-75.h
+#endif
DECLARE_GLOBAL_DATA_PTR;
@@ -63,6 +68,12 @@ static void sdram_start(int hi_addr)
/* normal operation */
out_be32((void *)MPC5XXX_SDRAM_CTRL, control);
+
+ /*
+* Wait a short while for the DLL to lock before accessing
+* the SDRAM
+*/
+ udelay(100);
}
#endif
@@ -157,12 +168,6 @@ static void get_revisions(int *failsavelevel, int
*digiboardversion,
struct mpc5xxx_gpt_0_7 *gpt = (struct mpc5xxx_gpt_0_7 *)MPC5XXX_GPT;
u8 val;
- /*
-* Figure out failsavelevel
-* see ticket dsvk#59
-*/
- *failsavelevel = 0; /* 0=failsave, 1=board ok, 2=fpga ok */
-
/* read digitalboard-version from TMR[2..4] */
val = 0;
val |= (gpt-gpt2.sr (1 (31 - 23))) ? (1) : 0;
@@ -170,6 +175,17 @@ static void get_revisions(int *failsavelevel, int
*digiboardversion,
val |= (gpt-gpt4.sr (1 (31 - 23))) ? (1 2) : 0;
*digiboardversion = val;
+ /*
+* A4M2K only supports digiboardversion. No failsavelevel and
+* fpgaversion here.
+*/
+#if !defined(CONFIG_A4M2K)
+ /*
+* Figure out failsavelevel
+* see ticket dsvk#59
+*/
+ *failsavelevel = 0; /* 0=failsave, 1=board ok, 2=fpga ok */
+
if (*digiboardversion == 0) {
*failsavelevel = 1; /* digiboard-version ok */
@@ -183,6 +199,7 @@ static void get_revisions(int *failsavelevel, int
*digiboardversion,
if (*fpgaversion == 1)
*failsavelevel = 2; /* fpga-version ok */
}
+#endif
}
/*
@@ -196,6 +213,11 @@ void spl_board_init(void)
struct mpc5xxx_gpio *gpio = (struct mpc5xxx_gpio *)MPC5XXX_GPIO;
struct mpc5xxx_mmap_ctl *mm =
(struct mpc5xxx_mmap_ctl *)CONFIG_SYS_MBAR;
+
+#if defined(CONFIG_A4M2K)
+ /* enable CS3 and CS5 (FPGA) */
+ setbits_be32(mm-ipbi_ws_ctrl, (1 19) | (1 21));
+#else
int digiboardversion;
int failsavelevel;
int fpgaversion;
@@ -219,6 +241,7 @@ void spl_board_init(void)
/* And write new value back to register */
out_be32(mm-ipbi_ws_ctrl, val);
+#endif
/*
* No need to change the pin multiplexing (MPC5XXX_GPS_PORT_CONFIG)
@@ -234,6 +257,55 @@ void spl_board_init(void)
*/
setbits_be32((void *)MPC5XXX_WU_GPIO_ENABLE, 1 (31 - 0));
+#if defined(CONFIG_A4M2K)
+ /* Setup USB[x] as MPCDiag[0..3] GPIO outputs */
+
+ /* set USB0,6,7,8 (MPCDiag[0..3]) direction to output */
+ gpio-simple_ddr |= 1 (31 - 15);
+ gpio-simple_ddr |= 1 (31 - 14);
+ gpio-simple_ddr |= 1 (31 - 13);
+ gpio-simple_ddr |= 1 (31 - 12);
+
+ /* enable USB0,6,7,8 (MPCDiag[0..3]) as GPIO */
+ gpio-simple_gpioe |= 1 (31 - 15);
+ gpio-simple_gpioe |= 1 (31 - 14);
+ gpio-simple_gpioe |= 1 (31 - 13);
+ gpio-simple_gpioe |= 1 (31 - 12);
+
+ /* Setup PSC2[0..2] as STSLED[0..2] GPIO outputs */
+
+ /* set PSC2[0..2] (STSLED[0..2]) direction to output */
+ gpio-simple_ddr |= 1 (31 - 27);
+ gpio-simple_ddr |= 1 (31 - 26);
+ gpio-simple_ddr |= 1 (31 - 25);
+
+ /* enable PSC2[0..2] (STSLED[0..2]) as GPIO */
+ gpio-simple_gpioe |= 1 (31 - 27);
+ gpio-simple_gpioe |= 1 (31 - 26);
+ gpio-simple_gpioe |= 1 (31 - 25);
+
+ /* Setup PSC6[2] as MRST2 self reset GPIO output */
+
+ /* set
Re: [U-Boot] [PATCH 2/2] FAT: use toupper/tolower instead of recoding them
On 13/12/2012 11:47, Richard Genoud wrote:
toupper/tolower function are already declared, so use them.
Signed-off-by: Richard Genoud richard.gen...@gmail.com
---
fs/fat/fat.c |3 ++-
fs/fat/fat_write.c |3 ++-
include/fat.h |3 ---
3 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index c79e3e3..cff0526 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -33,6 +33,7 @@
#include part.h
#include malloc.h
#include linux/compiler.h
+#include linux/ctype.h
#ifdef CONFIG_SUPPORT_VFAT
#define VFAT_ENABLED 1
@@ -46,7 +47,7 @@
static void downcase(char *str)
{
while (*str != '\0') {
- TOLOWER(*str);
+ *str = tolower(*str);
str++;
}
}
diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
index ed3eaa0..13c4de1 100644
--- a/fs/fat/fat_write.c
+++ b/fs/fat/fat_write.c
@@ -28,6 +28,7 @@
#include fat.h
#include asm/byteorder.h
#include part.h
+#include linux/ctype.h
#include fat.c
static void uppercase(char *str, int len)
@@ -35,7 +36,7 @@ static void uppercase(char *str, int len)
int i;
for (i = 0; i len; i++) {
- TOUPPER(*str);
+ *str = toupper(*str);
str++;
}
}
diff --git a/include/fat.h b/include/fat.h
index 706cd7a..b28c3fd 100644
--- a/include/fat.h
+++ b/include/fat.h
@@ -98,9 +98,6 @@
#endif
#endif
-#define TOLOWER(c) if((c) = 'A' (c) = 'Z'){(c)+=('a' - 'A');}
-#define TOUPPER(c) if ((c) = 'a' (c) = 'z') \
- (c) -= ('a' - 'A');
#define START(dent) (FAT2CPU16((dent)-start) \
+ (mydata-fatsize != 32 ? 0 : \
(FAT2CPU16((dent)-starthi) 16)))
Acked-by: Stefano Babic sba...@denx.de
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] imls: Add support to list images in NAND device
On 12/14/2012 3:29 AM, Scott Wood wrote:
On 12/13/2012 04:38:18 AM, Vipin Kumar wrote:
+ for (off = 0; off nand-size; off += nand-erasesize) {
+ const image_header_t *header;
+ int ret;
+
+ if (nand_block_isbad(nand, off))
+ continue;
+
+ len = sizeof(buffer);
+
+ ret = nand_read(nand, off, len, (u8 *)buffer);
+ if (ret 0 ret != -EUCLEAN)
+ continue;
Might want to make some noise if you get an uncorrectable error.
OK..
+
+ switch (genimg_get_format(buffer)) {
+ case IMAGE_FORMAT_LEGACY:
+ header = (const image_header_t *)buffer;
+ len = image_get_image_size(header);
+
+ ret = nand_imls_legacyimage(nand, nand_dev,
+ off, len);
+ if (ret 0 ret != -ENOMEM)
+ return ret;
+ break;
+#if defined(CONFIG_FIT)
+ case IMAGE_FORMAT_FIT:
+ len = fit_get_size(buffer);
+ ret = nand_imls_fitimage(nand, nand_dev,
+ off, len);
+ if (ret 0 ret != -ENOMEM)
+ return ret;
+ break;
+#endif
+ }
Do you really mean to return from the main imls function just because
one image has an error? By use return I meant return from the
subfunction.
I thought about it a little bit. How do you suggest
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] usbh/ehci: Increase timeout for enumeration
On 12/13/2012 6:41 PM, Marek Vasut wrote: Dear Vipin Kumar, The current logic reads the port status just once after usb_hub_power_on and expects the portstatus and portchange to report the connection status immediately and correctly. Few pen drives are not able to report both of them immediately ie. those pens report the connection change but not the connected state after the first read. This opportunity once lost is gone for ever because the u-boot, unlike linux or any other OS, works in polling mode. This patch modifies the logic to read the port status continuously until the portstatus and portchange both report a connection change as well as a connected state or no connection change and no connection. This logic is placed in a timeout of 10 sec. At the end of it, the pen drive would have either reported a ONE or a ZERO in bit 1 of portstatus as well as portchange. It enhances the set of pen drives which can eventually be detected by u-boot Note: This 10 second timeout is based purely on several experiments done with the broken pen drives Signed-off-by: Vipin Kumarvipin.ku...@st.com Acked-by: Igor Grinberggrinb...@compulab.co.il Applied, tested. Thanks Thanks Marek Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Exynos: clock: support get_mmc_clk for exynos
On 12/07/2012 02:34 PM, Minkyu Kang wrote:
Dear Jaehoon,
On 22/11/12 13:22, Jaehoon Chung wrote:
To get exactly clock value for mmc, support the get_mmc_clk() like
set_mmc_clk().
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/cpu/armv7/exynos/clock.c | 107
arch/arm/include/asm/arch-exynos/clk.h |1 +
2 files changed, 108 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/clock.c
b/arch/arm/cpu/armv7/exynos/clock.c
index fe61f88..731bbff 100644
--- a/arch/arm/cpu/armv7/exynos/clock.c
+++ b/arch/arm/cpu/armv7/exynos/clock.c
@@ -373,6 +373,100 @@ static unsigned long exynos5_get_uart_clk(int
dev_index)
return uclk;
}
+static unsigned long exynos4_get_mmc_clk(int dev_index)
+{
+struct exynos4_clock *clk =
+(struct exynos4_clock *)samsung_get_base_clock();
+unsigned long uclk, sclk;
+unsigned int sel, ratio, pre_ratio;
+int shift;
+
+sel = readl(clk-src_fsys);
+sel = (sel (dev_index 2)) 0xf;
+
+if (sel == 0x6)
+sclk = get_pll_clk(MPLL);
+else if (sel == 0x7)
+sclk = get_pll_clk(EPLL);
+else if (sel == 0x8)
+sclk = get_pll_clk(VPLL);
+else
+return 0;
+
+switch (dev_index) {
+case 0:
+case 1:
+ratio = readl(clk-div_fsys1);
+pre_ratio = readl(clk-div_fsys1);
+break;
+case 2:
+case 3:
+ratio = readl(clk-div_fsys2);
+pre_ratio = readl(clk-div_fsys2);
+break;
+case 4:
+ratio = readl(clk-div_fsys3);
+pre_ratio = readl(clk-div_fsys3);
+break;
+default:
+return 0;
+}
+
+if (dev_index == 1 || dev_index == 3)
+shift = 16;
+
+ratio = (ratio shift) 0xf;
+pre_ratio = (pre_ratio (shift + 8)) 0xff;
+uclk = (sclk / (ratio + 1)) / (pre_ratio + 1);
+
+return uclk;
+}
+
+static unsigned long exynos5_get_mmc_clk(int dev_index)
+{
+struct exynos5_clock *clk =
+(struct exynos5_clock *)samsung_get_base_clock();
+unsigned long uclk, sclk;
+unsigned int sel, ratio, pre_ratio;
+int shift;
+
+sel = readl(clk-src_fsys);
+sel = (sel (dev_index 2)) 0xf;
+
+if (sel == 0x6)
+sclk = get_pll_clk(MPLL);
+else if (sel == 0x7)
+sclk = get_pll_clk(EPLL);
+else if (sel == 0x8)
+sclk = get_pll_clk(VPLL);
+else
+return 0;
+
+switch (dev_index) {
+case 0:
+case 1:
+ratio = readl(clk-div_fsys1);
+pre_ratio = readl(clk-div_fsys1);
+break;
+case 2:
+case 3:
+ratio = readl(clk-div_fsys2);
+pre_ratio = readl(clk-div_fsys2);
+break;
+default:
+return 0;
+}
+
+if (dev_index == 1 || dev_index == 3)
+shift = 16;
+
+ratio = (ratio shift) 0xf;
+pre_ratio = (pre_ratio (shift + 8)) 0xff;
+uclk = (sclk / (ratio + 1)) / (pre_ratio + 1);
+
+return uclk;
+}
+
/* exynos4: set the mmc clock */
static void exynos4_set_mmc_clk(int dev_index, unsigned int div)
{
@@ -386,9 +480,14 @@ static void exynos4_set_mmc_clk(int dev_index, unsigned
int div)
* MMC0_PRE_RATIO [15:8], MMC1_PRE_RATIO [31:24]
* CLK_DIV_FSYS2
* MMC2_PRE_RATIO [15:8], MMC3_PRE_RATIO [31:24]
+ * CLK_DIV_FSYS3
+ * MMC4_PRE_RATIO [15:8]
*/
if (dev_index 2) {
addr = (unsigned int)clk-div_fsys1;
+} else if (dev_index == 4) {
+addr = (unsigned int)clk-div_fsys3;
+dev_index -= 4;
unrelated change.
you means this change is related with set_mmc_clk?
Then i will separate it.
} else {
addr = (unsigned int)clk-div_fsys2;
dev_index -= 2;
@@ -963,6 +1062,14 @@ unsigned long get_uart_clk(int dev_index)
return exynos4_get_uart_clk(dev_index);
}
+unsigned long get_mmc_clk(int dev_index)
+{
+if (cpu_is_exynos5())
+return exynos5_get_mmc_clk(dev_index);
+else
+return exynos4_get_mmc_clk(dev_index);
+}
+
void set_mmc_clk(int dev_index, unsigned int div)
{
if (cpu_is_exynos5())
diff --git a/arch/arm/include/asm/arch-exynos/clk.h
b/arch/arm/include/asm/arch-exynos/clk.h
index cd12323..ff155d8 100644
--- a/arch/arm/include/asm/arch-exynos/clk.h
+++ b/arch/arm/include/asm/arch-exynos/clk.h
@@ -34,6 +34,7 @@ unsigned long get_arm_clk(void);
unsigned long get_i2c_clk(void);
unsigned long get_pwm_clk(void);
unsigned long get_uart_clk(int dev_index);
+unsigned long get_mmc_clk(int deV_index);
typo. deV_index
Sorry..will fix.
Best Regards,
Jaehoon Chung
void set_mmc_clk(int dev_index, unsigned int div);
unsigned
Re: [U-Boot] [PATCH v2] imls: Add support to list images in NAND device
On 12/14/2012 3:22 AM, Scott Wood wrote:
On 12/13/2012 12:10:58 AM, Vipin Kumar wrote:
Or better, just have one CONFIG_CMD_IMLS and have it operate on
whatever flash types are configured into U-Boot.
I didn't do it because until now the CONFIG_CMD_IMLS config is
tightly bound with flash only eg config_cmd_default.h enables
CONFIG_CMD_IMLS only when CONFIG_SYS_NO_FLASH is not defined. I
thought there might be other places as well
Still, it might be better to fix that than to build upon a
no-longer-accurate assumption.
OK, I would try that in v4
+#if defined(CONFIG_CMD_IMLS_NAND)
+static void do_imls_nand(void)
+{
+ nand_info_t *nand;
+ int nand_dev = nand_curr_device;
+ size_t read_size;
+ loff_t off;
+ u8 buffer[512];
Why 512?
Basically there are 2 image types supported as of today.
* Legacy: 64 byte header
* FIT: 512 byte header
After reading the first 512 bytes from each block of NAND, we try to
validate the header and only if the header validation is successful,
we malloc the space for the whole image and read the image into it
Do you really need 512 bytes for fdt_check_header() to work?
I have reduced it already to 64 bytes in v3
+ nand =nand_info[nand_dev];
+ if (!nand-name || !nand-size)
+ continue;
+
+ for (off = 0; off nand-size; off += nand-erasesize)
{
+ int ret;
+ void *imgdata;
+
+ if (nand_block_isbad(nand, off))
+ goto next_block;
+
+ read_size = sizeof(buffer);
+
+ ret = nand_read(nand, off,read_size, buffer);
+ if (ret 0 ret != -EUCLEAN)
+ goto next_block;
s/goto next_block/continue/
hmmm, OK.
I copied the original code ie for listing images from nor flash.
Should I also correct it !!
If you want to do that as a separate patch, that's fine -- but the code
is sufficiently different that I don't think there's a strong
consistency argument to be made.
Check if it is OK in v3
+ header = (const image_header_t *)buffer;
+
+ switch (genimg_get_format(buffer)) {
+ case IMAGE_FORMAT_LEGACY:
+ if (!image_check_hcrc(header))
+ goto next_block;
+
+ read_size =
image_get_image_size(header);
+
+ imgdata = malloc(read_size);
+ if (!imgdata) {
+ printf(Not able to list all
images \
+ (Low memory)\n);
Don't line-wrap error strings.
80 column ?
Error strings are an exception for the sake of greppability. From
Linux's Documentation/CodingStyle:
Statements longer than 80 columns will be broken into sensible
chunks, unless
exceeding 80 columns significantly increases readability and does
not hide
information. Descendants are always substantially shorter than the
parent and
are placed substantially to the right. The same applies to function
headers
with a long argument list. However, never break user-visible strings
such as
printk messages, because that breaks the ability to grep for them.
Yes, thanks for reminding. The error strings are more readable already
in v3. Please take a look
Why is the no-memory error message different for FIT versus legacy
images? I realize that at this point you don't know if it's a FIT
versus some other dtb, but why do you print the device and offset
here
but not in the legacy case? Why Low memory(cannot allocate memory
for
image) versus just (Low memory)?
Typo :(
I would give the following print for both
printf(May be a FIT Image at NAND \
device %d offset %08llX:\n,
nand_dev, off);
printf( Low memory(cannot allocate \
memory for image)\n);
It's a little more verbose than I'd have done, but OK. Can you put a
space between memory and (cannot, though?
Sure. I will do that in v4
-Vipin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH resend] armv7/ltimer: Add support for local timer on armv7 cpus
ping again
On 12/6/2012 2:52 PM, Vipin KUMAR wrote:
Certain ARMV7 cpus eg. CortexA9 contains a local and a global timer within the
CPU core itself. This patch adds generic support for local timer.
Signed-off-by: Vipin Kumarvipin.ku...@st.com
---
arch/arm/cpu/armv7/Makefile | 11 ++-
arch/arm/cpu/armv7/ca9_ltimer.c | 152 ++
arch/arm/include/asm/ca9_ltimer.h | 40 ++
3 files changed, 199 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/cpu/armv7/ca9_ltimer.c
create mode 100644 arch/arm/include/asm/ca9_ltimer.h
diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile
index 4fdbee4..3ef01f6 100644
--- a/arch/arm/cpu/armv7/Makefile
+++ b/arch/arm/cpu/armv7/Makefile
@@ -27,15 +27,18 @@ LIB = $(obj)lib$(CPU).o
START := start.o
-COBJS += cache_v7.o
+COBJS-y+= cache_v7.o
-COBJS += cpu.o
-COBJS += syslib.o
+COBJS-y+= cpu.o
+COBJS-y+= syslib.o
+COBJS-$(CONFIG_ARMV7_CA9LTIMER) += ca9_ltimer.o
ifneq ($(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TEGRA20),)
-SOBJS += lowlevel_init.o
+SOBJS-y+= lowlevel_init.o
endif
+COBJS := $(sort $(COBJS-y))
+SOBJS := $(sort $(SOBJS-y))
SRCS := $(START:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS))
START := $(addprefix $(obj),$(START))
diff --git a/arch/arm/cpu/armv7/ca9_ltimer.c b/arch/arm/cpu/armv7/ca9_ltimer.c
new file mode 100644
index 000..cbf1552
--- /dev/null
+++ b/arch/arm/cpu/armv7/ca9_ltimer.c
@@ -0,0 +1,152 @@
+/*
+ * (C) Copyright 2012
+ * Vipin Kumar, ST Micoelectronics, vipin.ku...@st.com.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#includecommon.h
+#includeasm/io.h
+#includeasm/ca9_ltimer.h
+#includeasm/arch/hardware.h
+
+#define READ_TIMER() readl(ca9_timer_p-count)
+
+static struct ca9_timer_regs *const ca9_timer_p =
+ (struct ca9_timer_regs *)CONFIG_ARMV7_LTIMER_BASE;
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define timestamp gd-tbl
+#define lastdecgd-lastinc
+#define tickshzgd-timer_rate_hz
+#define ticksper10usec gd-tbu
+
+int timer_init(void)
+{
+ u32 prescaler, timertickshz;
+ /*
+* Genrally, CortexA9 MPUs are operating from 500MHz to 1500MHz which
+* means that CA9 local timer clock would be in the range of 250 MHz to
+* 750MHz.
+* Try to find a prescaler which can perfectly divide the local timer
+* clock. Take prescaler as 200 if nothing is found
+*/
+ for (prescaler = 255; prescaler 1; prescaler--) {
+ if (CONFIG_ARMV7_LTMR_CLK ==
+ (CONFIG_ARMV7_LTMR_CLK / prescaler) * prescaler)
+ break;
+ }
+
+ if (prescaler == 1)
+ prescaler = 200;
+ timertickshz = CONFIG_ARMV7_LTMR_CLK / prescaler;
+ ticksper10usec = timertickshz / (100 * 1000);
+ tickshz = timertickshz / CONFIG_SYS_HZ;
+
+ /* disable timers */
+ writel(((prescaler - 1) 8) | AUTO_RELOAD,ca9_timer_p-control);
+
+ /* load value for free running */
+ writel(FREE_RUNNING,ca9_timer_p-load);
+
+ /* auto reload, start timer */
+ setbits_le32(ca9_timer_p-control, TIMER_ENABLE);
+
+ reset_timer_masked();
+
+ return 0;
+}
+
+/*
+ * timer without interrupts
+ */
+
+void reset_timer(void)
+{
+ reset_timer_masked();
+}
+
+ulong get_timer(ulong base)
+{
+ return (get_timer_masked() / tickshz) - base;
+}
+
+void set_timer(ulong t)
+{
+ timestamp = t;
+}
+
+void __udelay(unsigned long usec)
+{
+ ulong tmo;
+ ulong start = get_timer_masked();
+ ulong rndoff;
+
+ rndoff = (usec % 10) ? 1 : 0;
+ tmo = ((usec / 10) + rndoff) * ticksper10usec;
+
+ while ((ulong) (get_timer_masked() - start) tmo);
+}
+
+void reset_timer_masked(void)
+{
+ /* reset time */
+ lastdec = READ_TIMER();
+ timestamp = 0;
+}
+
+ulong get_timer_masked(void)
+{
+ ulong now = READ_TIMER();
+
+ if (now= lastdec) {
+ /* normal mode */
+ timestamp += lastdec - now;
+ } else {
+ /* we have an overflow ... */
+
Re: [U-Boot] [PATCH v3] imls: Add support to list images in NAND device
+
+ switch (genimg_get_format(buffer)) {
+ case IMAGE_FORMAT_LEGACY:
+ header = (const image_header_t *)buffer;
+ len = image_get_image_size(header);
+
+ ret = nand_imls_legacyimage(nand,
nand_dev,
+ off, len);
+ if (ret 0 ret != -ENOMEM)
+ return ret;
+ break;
+#if defined(CONFIG_FIT)
+ case IMAGE_FORMAT_FIT:
+ len = fit_get_size(buffer);
+ ret = nand_imls_fitimage(nand, nand_dev,
+ off, len);
+ if (ret 0 ret != -ENOMEM)
+ return ret;
+ break;
+#endif
+ }
Do you really mean to return from the main imls function just because
one image has an error? By use return I meant return from the
subfunction.
This return only corresponds to the situation when there is an error
returned from nand read routine. In that case, I don't think there is
any use reading the NAND any further.
What do you think ?
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 49/58] microblaze: Use generic global_data
Hi Simon, 2012/12/14 Simon Glass s...@chromium.org: Move microblaze over to use generic global_data. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: None arch/microblaze/include/asm/global_data.h | 27 +-- 1 files changed, 1 insertions(+), 26 deletions(-) will be better to provide link to any git repo/branch which I can just download and test. Anyway I have tested it on real hw without any issue. Tested-by: Michal Simek mon...@monstr.eu Thanks, Michal -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 00/16] SMDK5250: Add FDT support
This patch set adds FDT support to I2C, I2S, SPI drivers for SMDK5250. Based on: 1) [PATCH 0/5 v2] Add DT based ethernet driver for SMDK5250 http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/146555; 2) fdt: Export fdtdec_lookup() and fix the name http://permalink.gmane.org/gmane.linux.drivers.devicetree/23287; merged in u-boot-fdt with commit number 7cde397b21a347134a39c40e24355a0e438adae3 Separate patch sets for each driver are rebased on lastest u-boot-samsung. Following is the link for each driver patch set combined 1) I2C V4: http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/148199; 2) I2S V3: http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/148208; 3) SPI V2: http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/148662; Changes Rajeshwari Shinde (16): EXYNOS5: FDT: Add I2C device node data EXYNOS5 : FDT: Add Aliases for I2C device FDT: Add compatible string for I2C EXYNOS5: FDT : Decode peripheral id I2C: Driver changes for FDT support SMDK5250: Initialise I2C using FDT EXYNOS5: FDT: Add sound device node data EXYNOS5: FDT: Add sound and codec device node EXYNOS5: FDT: Add compatible strings for sound Sound: Add FDT support to driver Sound: WM8994: Add FDT support to codec Sound: Add FDT support to CMD. EXYNOS5: FDT: Add compatible strings for SPI EXYNOS5 : FDT: Add Aliases for SPI device EXYNOS5: FDT: Add SPI device node data SPI: EXYNOS: Add FDT support to driver. arch/arm/cpu/armv7/exynos/pinmux.c | 28 + arch/arm/dts/exynos5250.dtsi| 110 + arch/arm/include/asm/arch-exynos/periph.h | 31 +++-- arch/arm/include/asm/arch-exynos/pinmux.h |8 ++ board/samsung/dts/exynos5250-smdk5250.dts | 33 + board/samsung/smdk5250/smdk5250.c | 20 +--- common/cmd_sound.c |2 +- doc/device-tree-bindings/exynos/isp-spi.txt | 22 doc/device-tree-bindings/exynos/sound.txt | 27 drivers/i2c/s3c24x0_i2c.c | 83 +- drivers/i2c/s3c24x0_i2c.h |8 ++ drivers/sound/sound.c | 173 --- drivers/sound/wm8994.c | 76 - drivers/sound/wm8994.h |6 +- drivers/spi/exynos_spi.c| 96 ++- include/fdtdec.h|4 + include/i2c.h | 26 include/sound.h |4 +- lib/fdtdec.c|4 + 19 files changed, 643 insertions(+), 118 deletions(-) create mode 100644 doc/device-tree-bindings/exynos/isp-spi.txt create mode 100644 doc/device-tree-bindings/exynos/sound.txt -- 1.7.4.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 01/16] EXYNOS5: FDT: Add I2C device node data
Add I2C device node data for exynos
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes in V1:
-Rebased on latest u-boot-samsung
arch/arm/dts/exynos5250.dtsi | 64 ++
1 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/arch/arm/dts/exynos5250.dtsi b/arch/arm/dts/exynos5250.dtsi
index fa4d498..7a50b2e 100644
--- a/arch/arm/dts/exynos5250.dtsi
+++ b/arch/arm/dts/exynos5250.dtsi
@@ -28,4 +28,68 @@
#address-cells = 1;
#size-cells = 0;
};
+
+ i2c@12c6 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = samsung,s3c2440-i2c;
+ reg = 0x12C6 0x100;
+ interrupts = 0 56 0;
+ };
+
+ i2c@12c7 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = samsung,s3c2440-i2c;
+ reg = 0x12C7 0x100;
+ interrupts = 0 57 0;
+ };
+
+ i2c@12c8 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = samsung,s3c2440-i2c;
+ reg = 0x12C8 0x100;
+ interrupts = 0 58 0;
+ };
+
+ i2c@12c9 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = samsung,s3c2440-i2c;
+ reg = 0x12C9 0x100;
+ interrupts = 0 59 0;
+ };
+
+ i2c@12ca {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = samsung,s3c2440-i2c;
+ reg = 0x12CA 0x100;
+ interrupts = 0 60 0;
+ };
+
+ i2c@12cb {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = samsung,s3c2440-i2c;
+ reg = 0x12CB 0x100;
+ interrupts = 0 61 0;
+ };
+
+ i2c@12cc {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = samsung,s3c2440-i2c;
+ reg = 0x12CC 0x100;
+ interrupts = 0 62 0;
+ };
+
+ i2c@12cd {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = samsung,s3c2440-i2c;
+ reg = 0x12CD 0x100;
+ interrupts = 0 63 0;
+ };
};
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 02/16] EXYNOS5 : FDT: Add Aliases for I2C device
This patch adds aliases for I2C.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
Acked-by: Simon Glass s...@chromium.org
Acked-by: Heiko Schocher h...@denx.de
---
Changes in V1:
-Rebased on latest u-boot-samsung
board/samsung/dts/exynos5250-smdk5250.dts | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/board/samsung/dts/exynos5250-smdk5250.dts
b/board/samsung/dts/exynos5250-smdk5250.dts
index b6fbb67..0f971c0 100644
--- a/board/samsung/dts/exynos5250-smdk5250.dts
+++ b/board/samsung/dts/exynos5250-smdk5250.dts
@@ -16,6 +16,17 @@
model = SAMSUNG SMDK5250 board based on EXYNOS5250;
compatible = samsung,smdk5250, samsung,exynos5250;
+ aliases {
+ i2c0 = /i2c@12c6;
+ i2c1 = /i2c@12c7;
+ i2c2 = /i2c@12c8;
+ i2c3 = /i2c@12c9;
+ i2c4 = /i2c@12ca;
+ i2c5 = /i2c@12cb;
+ i2c6 = /i2c@12cc;
+ i2c7 = /i2c@12cd;
+ };
+
sromc@1225 {
bank = 1;
srom-timing = 1 9 12 1 6 1 1;
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 03/16] FDT: Add compatible string for I2C
Add required compatible information for I2C driver.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
Acked-by: Simon Glass s...@chromium.org
Acked-by: Heiko Schocher h...@denx.de
---
Changes in V1:
-Rebased on latest u-boot-samsung
include/fdtdec.h |1 +
lib/fdtdec.c |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index da2054a..567ad13 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -70,6 +70,7 @@ enum fdt_compat_id {
COMPAT_NVIDIA_TEGRA20_DC, /* Tegra 2 Display controller */
COMPAT_SMSC_LAN9215,/* SMSC 10/100 Ethernet LAN9215 */
COMPAT_SAMSUNG_EXYNOS5_SROMC, /* Exynos5 SROMC */
+ COMPAT_SAMSUNG_S3C2440_I2C, /* Exynos I2C Controller */
COMPAT_COUNT,
};
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index f10ef5a..6ae2dd0 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -47,6 +47,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
COMPAT(NVIDIA_TEGRA20_DC, nvidia,tegra20-dc),
COMPAT(SMSC_LAN9215, smsc,lan9215),
COMPAT(SAMSUNG_EXYNOS5_SROMC, samsung,exynos-sromc),
+ COMPAT(SAMSUNG_S3C2440_I2C, samsung,s3c2440-i2c),
};
const char *fdtdec_get_compatible(enum fdt_compat_id id)
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 04/16] EXYNOS5: FDT : Decode peripheral id
Api is added to decode peripheral id based on the interrupt number
of the peripheral.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
Acked-by; Simon Glass s...@chromium.org
---
Changes in V1:
-Rebased on latest u-boot-samsung
arch/arm/cpu/armv7/exynos/pinmux.c| 28 ++
arch/arm/include/asm/arch-exynos/periph.h | 31
arch/arm/include/asm/arch-exynos/pinmux.h |8 +++
3 files changed, 54 insertions(+), 13 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c
b/arch/arm/cpu/armv7/exynos/pinmux.c
index f02f441..f9f6911 100644
--- a/arch/arm/cpu/armv7/exynos/pinmux.c
+++ b/arch/arm/cpu/armv7/exynos/pinmux.c
@@ -22,6 +22,7 @@
*/
#include common.h
+#include fdtdec.h
#include asm/arch/gpio.h
#include asm/arch/pinmux.h
#include asm/arch/sromc.h
@@ -396,3 +397,30 @@ int exynos_pinmux_config(int peripheral, int flags)
return -1;
}
}
+
+#ifdef CONFIG_OF_CONTROL
+static int exynos5_pinmux_decode_periph_id(const void *blob, int node)
+{
+ int err;
+ u32 cell[3];
+
+ err = fdtdec_get_int_array(blob, node, interrupts, cell,
+ ARRAY_SIZE(cell));
+ if (err)
+ return PERIPH_ID_NONE;
+
+ if ((131 cell[1]) || (cell[1] 31))
+ return cell[1];
+
+ debug( invalid peripheral id\n);
+ return PERIPH_ID_NONE;
+}
+
+int pinmux_decode_periph_id(const void *blob, int node)
+{
+ if (cpu_is_exynos5())
+ return exynos5_pinmux_decode_periph_id(blob, node);
+ else
+ return PERIPH_ID_NONE;
+}
+#endif
diff --git a/arch/arm/include/asm/arch-exynos/periph.h
b/arch/arm/include/asm/arch-exynos/periph.h
index 13abd2d..783b77c 100644
--- a/arch/arm/include/asm/arch-exynos/periph.h
+++ b/arch/arm/include/asm/arch-exynos/periph.h
@@ -25,12 +25,17 @@
#define __ASM_ARM_ARCH_PERIPH_H
/*
- * Peripherals requiring clock/pinmux configuration. List will
+ * Peripherals requiring pinmux configuration0. List will
* grow with support for more devices getting added.
+ * Numbering based on interrupt table.
*
*/
enum periph_id {
- PERIPH_ID_I2C0,
+ PERIPH_ID_UART0 = 51,
+ PERIPH_ID_UART1,
+ PERIPH_ID_UART2,
+ PERIPH_ID_UART3,
+ PERIPH_ID_I2C0 = 56,
PERIPH_ID_I2C1,
PERIPH_ID_I2C2,
PERIPH_ID_I2C3,
@@ -38,22 +43,22 @@ enum periph_id {
PERIPH_ID_I2C5,
PERIPH_ID_I2C6,
PERIPH_ID_I2C7,
- PERIPH_ID_I2S1,
- PERIPH_ID_SDMMC0,
+ PERIPH_ID_SPI0 = 68,
+ PERIPH_ID_SPI1,
+ PERIPH_ID_SPI2,
+ PERIPH_ID_SDMMC0 = 75,
PERIPH_ID_SDMMC1,
PERIPH_ID_SDMMC2,
PERIPH_ID_SDMMC3,
- PERIPH_ID_SDMMC4,
- PERIPH_ID_SROMC,
- PERIPH_ID_SPI0,
- PERIPH_ID_SPI1,
- PERIPH_ID_SPI2,
+ PERIPH_ID_I2S1 = 99,
+
+/* Since following peripherals do not have shared peripheral interrupts (SPIs)
+ * they are numbered arbitiraly after the maximum SPIs Exynos has (128)
+ */
+ PERIPH_ID_SROMC = 128,
PERIPH_ID_SPI3,
PERIPH_ID_SPI4,
- PERIPH_ID_UART0,
- PERIPH_ID_UART1,
- PERIPH_ID_UART2,
- PERIPH_ID_UART3,
+ PERIPH_ID_SDMMC4,
PERIPH_ID_COUNT,
PERIPH_ID_NONE = -1,
diff --git a/arch/arm/include/asm/arch-exynos/pinmux.h
b/arch/arm/include/asm/arch-exynos/pinmux.h
index 10ea736..00cbb0d 100644
--- a/arch/arm/include/asm/arch-exynos/pinmux.h
+++ b/arch/arm/include/asm/arch-exynos/pinmux.h
@@ -55,4 +55,12 @@ enum {
*/
int exynos_pinmux_config(int peripheral, int flags);
+/**
+ * Decode the peripheral id using the interrpt numbers.
+ *
+ * @param blob Device tree blbo
+ * @param node FDT I2C node to find
+ * @return peripheral id if ok, PERIPH_ID_NONE on error
+ */
+int pinmux_decode_periph_id(const void *blob, int node);
#endif
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 05/16] I2C: Driver changes for FDT support
Functions added to get the I2C bus number and reset I2C bus using
FDT node.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
Acked-by: Simon Glass s...@chromium.org
Acked-by: Heiko Schocher h...@denx.de
---
Changes in V1:
-Rebased on latest u-boot-samsung
drivers/i2c/s3c24x0_i2c.c | 83 -
drivers/i2c/s3c24x0_i2c.h |8
include/i2c.h | 26 ++
3 files changed, 116 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/s3c24x0_i2c.c b/drivers/i2c/s3c24x0_i2c.c
index 9bc4c7f..94a093e 100644
--- a/drivers/i2c/s3c24x0_i2c.c
+++ b/drivers/i2c/s3c24x0_i2c.c
@@ -27,9 +27,11 @@
*/
#include common.h
+#include fdtdec.h
#ifdef CONFIG_EXYNOS5
#include asm/arch/clk.h
#include asm/arch/cpu.h
+#include asm/arch/pinmux.h
#else
#include asm/arch/s3c24x0_cpu.h
#endif
@@ -60,7 +62,14 @@
#define I2C_TIMEOUT 1 /* 1 second */
-static unsigned int g_current_bus; /* Stores Current I2C Bus */
+/*
+ * For SPL boot some boards need i2c before SDRAM is initialised so force
+ * variables to live in SRAM
+ */
+static unsigned int g_current_bus __attribute__((section(.data)));
+static struct s3c24x0_i2c_bus i2c_bus[CONFIG_MAX_I2C_NUM]
+ __attribute__((section(.data)));
+static int i2c_busses __attribute__((section(.data)));
#ifndef CONFIG_EXYNOS5
static int GetI2CSDA(void)
@@ -507,4 +516,76 @@ int i2c_write(uchar chip, uint addr, int alen, uchar
*buffer, int len)
(i2c, I2C_WRITE, chip 1, xaddr[4 - alen], alen, buffer,
len) != 0);
}
+
+#ifdef CONFIG_OF_CONTROL
+void board_i2c_init(const void *blob)
+{
+
+ int node_list[CONFIG_MAX_I2C_NUM];
+ int count, i;
+
+ count = fdtdec_find_aliases_for_id(blob, i2c,
+ COMPAT_SAMSUNG_S3C2440_I2C, node_list,
+ CONFIG_MAX_I2C_NUM);
+ for (i = 0; i count; i++) {
+ struct s3c24x0_i2c_bus *bus;
+ int node = node_list[i];
+
+ if (node = 0)
+ continue;
+ bus = i2c_bus[i];
+ bus-regs = (struct s3c24x0_i2c *)
+ fdtdec_get_addr(blob, node, reg);
+ bus-id = pinmux_decode_periph_id(blob, node);
+ bus-node = node;
+ bus-bus_num = i2c_busses++;
+ exynos_pinmux_config(bus-id, 0);
+ }
+
+}
+
+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;
+}
+
+int i2c_get_bus_num_fdt(int node)
+{
+ int i;
+
+ for (i = 0; i i2c_busses; i++) {
+ if (node == i2c_bus[i].node)
+ return i;
+ }
+
+ debug(%s: Can't find any matched I2C bus\n, __func__);
+ return -1;
+}
+
+int i2c_reset_port_fdt(const void *blob, int node)
+{
+ struct s3c24x0_i2c_bus *i2c;
+
+ int bus;
+
+ bus = i2c_get_bus_num_fdt(node);
+ if (bus 0) {
+ debug(could not get bus for node %d\n, node);
+ return -1;
+ }
+ i2c = get_bus(bus);
+ if (!i2c) {
+ debug(get_bus() failed for node node %d\n, node);
+ return -1;
+ }
+
+ i2c_ch_init(i2c-regs, CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
+
+ return 0;
+}
+#endif
+
#endif /* CONFIG_HARD_I2C */
diff --git a/drivers/i2c/s3c24x0_i2c.h b/drivers/i2c/s3c24x0_i2c.h
index 2dd4b06..1243bf1 100644
--- a/drivers/i2c/s3c24x0_i2c.h
+++ b/drivers/i2c/s3c24x0_i2c.h
@@ -30,4 +30,12 @@ struct s3c24x0_i2c {
u32 iicds;
u32 iiclc;
};
+
+struct s3c24x0_i2c_bus {
+ int node; /* device tree node */
+ int bus_num;/* i2c bus number */
+ struct s3c24x0_i2c *regs;
+ enum periph_id id;
+};
+
#endif /* _S3C24X0_I2C_H */
diff --git a/include/i2c.h b/include/i2c.h
index 16f099d..c60d075 100644
--- a/include/i2c.h
+++ b/include/i2c.h
@@ -262,4 +262,30 @@ extern int get_multi_scl_pin(void);
extern int get_multi_sda_pin(void);
extern int multi_i2c_init(void);
#endif
+
+/**
+ * Get FDT values for i2c bus.
+ *
+ * @param blob Device tree blbo
+ * @return the number of I2C bus
+ */
+void board_i2c_init(const void *blob);
+
+/**
+ * Find the I2C bus number by given a FDT I2C node.
+ *
+ * @param blob Device tree blbo
+ * @param node FDT I2C node to find
+ * @return the number of I2C bus (zero based), or -1 on error
+ */
+int i2c_get_bus_num_fdt(int node);
+
+/**
+ * Reset the I2C bus represented by the given a FDT I2C node.
+ *
+ * @param blob Device tree blbo
+ * @param node FDT I2C node to find
+ * @return 0 if port was reset, -1 if not found
+ */
+int i2c_reset_port_fdt(const void *blob, int node);
#endif /* _I2C_H_ */
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
[U-Boot] [PATCH 06/16] SMDK5250: Initialise I2C using FDT
This patch initialises I2C using FDT.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
Acked-by: Simon Glass s...@chromium.org
Acked-by: Heiko Schocher h...@denx.de
---
Changes in V1:
-Rebased on latest u-boot-samsung
board/samsung/smdk5250/smdk5250.c | 20 +---
1 files changed, 1 insertions(+), 19 deletions(-)
diff --git a/board/samsung/smdk5250/smdk5250.c
b/board/samsung/smdk5250/smdk5250.c
index ac7346d..4d24978 100644
--- a/board/samsung/smdk5250/smdk5250.c
+++ b/board/samsung/smdk5250/smdk5250.c
@@ -236,24 +236,6 @@ static int board_uart_init(void)
return 0;
}
-#ifdef CONFIG_SYS_I2C_INIT_BOARD
-static int board_i2c_init(void)
-{
- int i, err;
-
- for (i = 0; i CONFIG_MAX_I2C_NUM; i++) {
- err = exynos_pinmux_config((PERIPH_ID_I2C0 + i),
- PINMUX_FLAG_NONE);
- if (err) {
- debug(I2C%d not configured\n, (PERIPH_ID_I2C0 + i));
- return err;
- }
- }
- i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
- return 0;
-}
-#endif
-
#ifdef CONFIG_BOARD_EARLY_INIT_F
int board_early_init_f(void)
{
@@ -264,7 +246,7 @@ int board_early_init_f(void)
return err;
}
#ifdef CONFIG_SYS_I2C_INIT_BOARD
- err = board_i2c_init();
+ board_i2c_init(gd-fdt_blob);
#endif
return err;
}
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 07/16] EXYNOS5: FDT: Add sound device node data
Add sound device node data for exynos
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes in V1:
-Rebased on latest u-boot-samsung
arch/arm/dts/exynos5250.dtsi |5 +
doc/device-tree-bindings/exynos/sound.txt | 27 +++
2 files changed, 32 insertions(+), 0 deletions(-)
create mode 100644 doc/device-tree-bindings/exynos/sound.txt
diff --git a/arch/arm/dts/exynos5250.dtsi b/arch/arm/dts/exynos5250.dtsi
index 7a50b2e..dc13f29 100644
--- a/arch/arm/dts/exynos5250.dtsi
+++ b/arch/arm/dts/exynos5250.dtsi
@@ -92,4 +92,9 @@
reg = 0x12CD 0x100;
interrupts = 0 63 0;
};
+
+ sound@12d6 {
+ compatible = samsung,exynos-sound;
+ reg = 0x12d6 0x20;
+ };
};
diff --git a/doc/device-tree-bindings/exynos/sound.txt
b/doc/device-tree-bindings/exynos/sound.txt
new file mode 100644
index 000..98d1798
--- /dev/null
+++ b/doc/device-tree-bindings/exynos/sound.txt
@@ -0,0 +1,27 @@
+Exynos Sound Subsystem
+
+The device node for sound subsytem which contains codec and i2s block
+that is a part of Exynos5250
+
+Required properties :
+ - compatible : Should be samsung,exynos-sound for sound
+ - samsung,i2s-epll-clock-frequency : epll clock output frequency in Hz
+ - samsung,i2s-sampling-rate : sampling rate, default is 48000
+ - samsung,i2s-bits-per-sample : sample width, defalut is 16 bit
+ - samsung,i2s-channels : nummber of channels, default is 2
+ - samsung,i2s-lr-clk-framesize : lr clock frame size
+ - samsung,i2s-bit-clk-framesize : bit clock frame size
+ - samsung,codec-type : sound codec type
+
+Example:
+
+sound@12d6 {
+ compatible = samsung,exynos-sound
+ samsung,i2s-epll-clock-frequency = 19200;
+ samsung,i2s-sampling-rate = 48000;
+ samsung,i2s-bits-per-sample = 16;
+ samsung,i2s-channels = 2;
+ samsung,i2s-lr-clk-framesize = 256;
+ samsung,i2s-bit-clk-framesize = 32;
+ samsung,codec-type = wm8994;
+};
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 08/16] EXYNOS5: FDT: Add sound and codec device node
Adds sound and codec device node parameters
Signed-off-by: R. Chandrasekar rcse...@samsung.com
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes in V1:
-Rebased on latest u-boot-samsung
board/samsung/dts/exynos5250-smdk5250.dts | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/board/samsung/dts/exynos5250-smdk5250.dts
b/board/samsung/dts/exynos5250-smdk5250.dts
index 0f971c0..14f73d8 100644
--- a/board/samsung/dts/exynos5250-smdk5250.dts
+++ b/board/samsung/dts/exynos5250-smdk5250.dts
@@ -37,4 +37,21 @@
phy-mode = mii;
};
};
+
+ sound@12d6 {
+ samsung,i2s-epll-clock-frequency = 19200;
+ samsung,i2s-sampling-rate = 48000;
+ samsung,i2s-bits-per-sample = 16;
+ samsung,i2s-channels = 2;
+ samsung,i2s-lr-clk-framesize = 256;
+ samsung,i2s-bit-clk-framesize = 32;
+ samsung,codec-type = wm8994;
+ };
+
+ i2c@12c7 {
+ soundcodec@1a {
+ reg = 0x1a;
+ compatible = wolfson,wm8994-codec;
+ };
+ };
};
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 09/16] EXYNOS5: FDT: Add compatible strings for sound
Add required compatible information for sound driver.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes in V1:
-Rebased on latest u-boot-samsung
include/fdtdec.h |2 ++
lib/fdtdec.c |2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 567ad13..976c9f3 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -71,6 +71,8 @@ enum fdt_compat_id {
COMPAT_SMSC_LAN9215,/* SMSC 10/100 Ethernet LAN9215 */
COMPAT_SAMSUNG_EXYNOS5_SROMC, /* Exynos5 SROMC */
COMPAT_SAMSUNG_S3C2440_I2C, /* Exynos I2C Controller */
+ COMPAT_SAMSUNG_EXYNOS5_SOUND, /* Exynos Sound */
+ COMPAT_WOLFSON_WM8994_CODEC,/* Wolfson WM8994 Sound Codec */
COMPAT_COUNT,
};
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 6ae2dd0..43affaa 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -48,6 +48,8 @@ static const char * const compat_names[COMPAT_COUNT] = {
COMPAT(SMSC_LAN9215, smsc,lan9215),
COMPAT(SAMSUNG_EXYNOS5_SROMC, samsung,exynos-sromc),
COMPAT(SAMSUNG_S3C2440_I2C, samsung,s3c2440-i2c),
+ COMPAT(SAMSUNG_EXYNOS5_SOUND, samsung,exynos-sound),
+ COMPAT(WOLFSON_WM8994_CODEC, wolfson,wm8994-codec),
};
const char *fdtdec_get_compatible(enum fdt_compat_id id)
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 10/16] Sound: Add FDT support to driver
This patch adds FDT support to the sound driver.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes in V1:
-Rebased on latest u-boot-samsung
drivers/sound/sound.c | 173 +
include/sound.h |4 +-
2 files changed, 105 insertions(+), 72 deletions(-)
diff --git a/drivers/sound/sound.c b/drivers/sound/sound.c
index 4c74534..fa8432d 100644
--- a/drivers/sound/sound.c
+++ b/drivers/sound/sound.c
@@ -24,111 +24,159 @@
#include malloc.h
#include common.h
#include asm/io.h
+#include libfdt.h
+#include fdtdec.h
#include i2c.h
#include i2s.h
#include sound.h
-#include wm8994.h
#include asm/arch/sound.h
+#include wm8994.h
/* defines */
#define SOUND_400_HZ 400
#define SOUND_BITS_IN_BYTE 8
static struct i2stx_info g_i2stx_pri;
-static struct sound_codec_info g_codec_info;
/*
- * get_sound_fdt_values gets fdt values for i2s parameters
+ * get_sound_i2s_values gets values for i2s parameters
*
* @param i2stx_info i2s transmitter transfer param structure
- * @param blob FDT blob
- */
-static void get_sound_i2s_values(struct i2stx_info *i2s)
-{
- i2s-base_address = samsung_get_base_i2s();
- i2s-audio_pll_clk = I2S_PLL_CLK;
- i2s-samplingrate = I2S_SAMPLING_RATE;
- i2s-bitspersample = I2S_BITS_PER_SAMPLE;
- i2s-channels = I2S_CHANNELS;
- i2s-rfs = I2S_RFS;
- i2s-bfs = I2S_BFS;
-}
-
-/*
- * Gets fdt values for wm8994 config parameters
- *
- * @param pcodec_info codec information structure
- * @param blob FDT blob
- * @return int value, 0 for success
+ * @param blob FDT blob if enabled else NULL
*/
-static int get_sound_wm8994_values(struct sound_codec_info *pcodec_info)
+static int get_sound_i2s_values(struct i2stx_info *i2s, const void *blob)
{
+#ifdef CONFIG_OF_CONTROL
+ int node;
int error = 0;
+ int base;
- switch (AUDIO_COMPAT) {
- case AUDIO_COMPAT_SPI:
- debug(%s: Support not added for SPI interface\n, __func__);
+ node = fdtdec_next_compatible(blob, 0,
+ COMPAT_SAMSUNG_EXYNOS5_SOUND);
+ if (node = 0) {
+ debug(EXYNOS_SOUND: No node for sound in device tree\n);
return -1;
- break;
- case AUDIO_COMPAT_I2C:
- pcodec_info-i2c_bus = AUDIO_I2C_BUS;
- pcodec_info-i2c_dev_addr = AUDIO_I2C_REG;
- debug(i2c dev addr = %d\n, pcodec_info-i2c_dev_addr);
- break;
- default:
- debug(%s: Unknown compat id %d\n, __func__, AUDIO_COMPAT);
+ }
+
+ /*
+* Get the pre-defined sound specific values from FDT.
+* All of these are expected to be correct otherwise
+* wrong register values in i2s setup parameters
+* may result in no sound play.
+*/
+ base = fdtdec_get_addr(blob, node, reg);
+ if (base == FDT_ADDR_T_NONE) {
+ debug(%s: Missing i2s base\n, __func__);
return -1;
}
+ i2s-base_address = base;
+ i2s-audio_pll_clk = fdtdec_get_int(blob,
+ node, samsung,i2s-epll-clock-frequency, -1);
+ error |= i2s-audio_pll_clk;
+ debug(audio_pll_clk = %d\n, i2s-audio_pll_clk);
+ i2s-samplingrate = fdtdec_get_int(blob,
+ node, samsung,i2s-sampling-rate, -1);
+ error |= i2s-samplingrate;
+ debug(samplingrate = %d\n, i2s-samplingrate);
+ i2s-bitspersample = fdtdec_get_int(blob,
+ node, samsung,i2s-bits-per-sample, -1);
+ error |= i2s-bitspersample;
+ debug(bitspersample = %d\n, i2s-bitspersample);
+ i2s-channels = fdtdec_get_int(blob,
+ node, samsung,i2s-channels, -1);
+ error |= i2s-channels;
+ debug(channels = %d\n, i2s-channels);
+ i2s-rfs = fdtdec_get_int(blob,
+ node, samsung,i2s-lr-clk-framesize, -1);
+ error |= i2s-rfs;
+ debug(rfs = %d\n, i2s-rfs);
+ i2s-bfs = fdtdec_get_int(blob,
+ node, samsung,i2s-bit-clk-framesize, -1);
+ error |= i2s-bfs;
+ debug(bfs = %d\n, i2s-bfs);
if (error == -1) {
- debug(fail to get wm8994 codec node properties\n);
+ debug(fail to get sound i2s node properties\n);
return -1;
}
-
+#else
+ i2s-base_address = samsung_get_base_i2s();
+ i2s-audio_pll_clk = I2S_PLL_CLK;
+ i2s-samplingrate = I2S_SAMPLING_RATE;
+ i2s-bitspersample = I2S_BITS_PER_SAMPLE;
+ i2s-channels = I2S_CHANNELS;
+ i2s-rfs = I2S_RFS;
+ i2s-bfs = I2S_BFS;
+#endif
return 0;
}
/*
- * Gets fdt values for codec config parameters
+ * Init codec
*
- * @param pcodec_info codec information structure
- * @param blob
[U-Boot] [PATCH 11/16] Sound: WM8994: Add FDT support to codec
This patch adds FDT support to the codec.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes in V1:
-Rebased on latest u-boot-samsung
drivers/sound/wm8994.c | 76 ++-
drivers/sound/wm8994.h |6 +--
2 files changed, 76 insertions(+), 6 deletions(-)
diff --git a/drivers/sound/wm8994.c b/drivers/sound/wm8994.c
index 293903a..a528502 100644
--- a/drivers/sound/wm8994.c
+++ b/drivers/sound/wm8994.c
@@ -26,9 +26,11 @@
#include asm/io.h
#include common.h
#include div64.h
+#include fdtdec.h
#include i2c.h
#include i2s.h
#include sound.h
+#include asm/arch/sound.h
#include wm8994.h
#include wm8994_registers.h
@@ -77,6 +79,7 @@ static int bclk_divs[] = {
static struct wm8994_priv g_wm8994_info;
static unsigned char g_wm8994_i2c_dev_addr;
+static struct sound_codec_info g_codec_info;
/*
* Initialise I2C for wm 8994
@@ -747,13 +750,82 @@ err:
return -1;
}
+/*
+ * Gets fdt values for wm8994 config parameters
+ *
+ * @param pcodec_info codec information structure
+ * @param blob FDT blob
+ * @return int value, 0 for success
+ */
+static int get_codec_values(struct sound_codec_info *pcodec_info,
+ const void *blob)
+{
+ int error = 0;
+#ifdef CONFIG_OF_CONTROL
+ enum fdt_compat_id compat;
+ int node;
+ int parent;
+
+ /* Get the node from FDT for codec */
+ node = fdtdec_next_compatible(blob, 0, COMPAT_WOLFSON_WM8994_CODEC);
+ if (node = 0) {
+ debug(EXYNOS_SOUND: No node for codec in device tree\n);
+ debug(node = %d\n, node);
+ return -1;
+ }
+
+ parent = fdt_parent_offset(blob, node);
+ if (parent 0) {
+ debug(%s: Cannot find node parent\n, __func__);
+ return -1;
+ }
+
+ compat = fdtdec_lookup(blob, parent);
+ switch (compat) {
+ case COMPAT_SAMSUNG_S3C2440_I2C:
+ pcodec_info-i2c_bus = i2c_get_bus_num_fdt(parent);
+ error |= pcodec_info-i2c_bus;
+ debug(i2c bus = %d\n, pcodec_info-i2c_bus);
+ pcodec_info-i2c_dev_addr = fdtdec_get_int(blob, node,
+ reg, 0);
+ error |= pcodec_info-i2c_dev_addr;
+ debug(i2c dev addr = %d\n, pcodec_info-i2c_dev_addr);
+ break;
+ default:
+ debug(%s: Unknown compat id %d\n, __func__, compat);
+ return -1;
+ }
+#else
+ pcodec_info-i2c_bus = AUDIO_I2C_BUS;
+ pcodec_info-i2c_dev_addr = AUDIO_I2C_REG;
+ debug(i2c dev addr = %d\n, pcodec_info-i2c_dev_addr);
+#endif
+
+ pcodec_info-codec_type = CODEC_WM_8994;
+
+ if (error == -1) {
+ debug(fail to get wm8994 codec node properties\n);
+ return -1;
+ }
+
+ return 0;
+
+}
+
+
/*wm8994 Device Initialisation */
-int wm8994_init(struct sound_codec_info *pcodec_info,
- enum en_audio_interface aif_id,
+int wm8994_init(const void *blob, enum en_audio_interface aif_id,
int sampling_rate, int mclk_freq,
int bits_per_sample, unsigned int channels)
{
int ret = 0;
+ struct sound_codec_info *pcodec_info = g_codec_info;
+
+ /* Get the codec Values */
+ if (get_codec_values(pcodec_info, blob) 0) {
+ debug(FDT Codec values failed\n);
+ return -1;
+ }
/* shift the device address by 1 for 7 bit addressing */
g_wm8994_i2c_dev_addr = pcodec_info-i2c_dev_addr;
diff --git a/drivers/sound/wm8994.h b/drivers/sound/wm8994.h
index a8f0de1..a1e8335 100644
--- a/drivers/sound/wm8994.h
+++ b/drivers/sound/wm8994.h
@@ -69,8 +69,7 @@ enum wm8994_type {
/*
* intialise wm8994 sound codec device for the given configuration
*
- * @param pcodec_info pointer value of the sound codec info structure
- * parsed from device tree
+ * @param blob FDT node for codec values
* @param aif_id enum value of codec interface port in which
* soc i2s is connected
* @param sampling_rateSampling rate ranges between from 8khz
to 96khz
@@ -80,8 +79,7 @@ enum wm8994_type {
*
* @returns -1 for error and 0 Success.
*/
-int wm8994_init(struct sound_codec_info *pcodec_info,
- enum en_audio_interface aif_id,
+int wm8994_init(const void *blob, enum en_audio_interface aif_id,
int sampling_rate, int mclk_freq,
int bits_per_sample, unsigned int channels);
#endif /*__WM8994_H__ */
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 12/16] Sound: Add FDT support to CMD.
This patch adds FDT support to sound init in CMD.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes in V1:
-Rebased on latest u-boot-samsung
common/cmd_sound.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/cmd_sound.c b/common/cmd_sound.c
index 459d1eb..cfca9dd 100644
--- a/common/cmd_sound.c
+++ b/common/cmd_sound.c
@@ -33,7 +33,7 @@ static int do_init(cmd_tbl_t *cmdtp, int flag, int argc, char
*const argv[])
{
int ret;
- ret = sound_init();
+ ret = sound_init(gd-fdt_blob);
if (ret) {
printf(Initialise Audio driver failed\n);
return CMD_RET_FAILURE;
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 13/16] EXYNOS5: FDT: Add compatible strings for SPI
Add required compatible information for SPI driver.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes in V1:
-Rebased on latest u-boot-samsung
include/fdtdec.h |1 +
lib/fdtdec.c |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 976c9f3..539bb1b 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -73,6 +73,7 @@ enum fdt_compat_id {
COMPAT_SAMSUNG_S3C2440_I2C, /* Exynos I2C Controller */
COMPAT_SAMSUNG_EXYNOS5_SOUND, /* Exynos Sound */
COMPAT_WOLFSON_WM8994_CODEC,/* Wolfson WM8994 Sound Codec */
+ COMPAT_SAMSUNG_EXYNOS_SPI, /* Exynos SPI */
COMPAT_COUNT,
};
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 43affaa..44c249d 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -50,6 +50,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
COMPAT(SAMSUNG_S3C2440_I2C, samsung,s3c2440-i2c),
COMPAT(SAMSUNG_EXYNOS5_SOUND, samsung,exynos-sound),
COMPAT(WOLFSON_WM8994_CODEC, wolfson,wm8994-codec),
+ COMPAT(SAMSUNG_EXYNOS_SPI, samsung,exynos-spi),
};
const char *fdtdec_get_compatible(enum fdt_compat_id id)
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 14/16] EXYNOS5 : FDT: Add Aliases for SPI device
This patch adds aliases for SPI.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes in V1:
-Rebased on latest u-boot-samsung
board/samsung/dts/exynos5250-smdk5250.dts |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/board/samsung/dts/exynos5250-smdk5250.dts
b/board/samsung/dts/exynos5250-smdk5250.dts
index 14f73d8..a8e62da 100644
--- a/board/samsung/dts/exynos5250-smdk5250.dts
+++ b/board/samsung/dts/exynos5250-smdk5250.dts
@@ -25,6 +25,11 @@
i2c5 = /i2c@12cb;
i2c6 = /i2c@12cc;
i2c7 = /i2c@12cd;
+ spi0 = /spi@12d2;
+ spi1 = /spi@12d3;
+ spi2 = /spi@12d4;
+ spi3 = /spi@131a;
+ spi4 = /spi@131b;
};
sromc@1225 {
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 15/16] EXYNOS5: FDT: Add SPI device node data
Add SPI device node data for exynos.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes in V1:
-Rebased on latest u-boot-samsung
arch/arm/dts/exynos5250.dtsi| 41 +++
doc/device-tree-bindings/exynos/isp-spi.txt | 22 ++
2 files changed, 63 insertions(+), 0 deletions(-)
create mode 100644 doc/device-tree-bindings/exynos/isp-spi.txt
diff --git a/arch/arm/dts/exynos5250.dtsi b/arch/arm/dts/exynos5250.dtsi
index dc13f29..1008797 100644
--- a/arch/arm/dts/exynos5250.dtsi
+++ b/arch/arm/dts/exynos5250.dtsi
@@ -97,4 +97,45 @@
compatible = samsung,exynos-sound;
reg = 0x12d6 0x20;
};
+
+ spi@12d2 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = samsung,exynos-spi;
+ reg = 0x12d2 0x30;
+ interrupts = 0 68 0;
+ };
+
+ spi@12d3 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = samsung,exynos-spi;
+ reg = 0x12d3 0x30;
+ interrupts = 0 69 0;
+ };
+
+ spi@12d4 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = samsung,exynos-spi;
+ reg = 0x12d4 0x30;
+ clock-frequency = 5000;
+ interrupts = 0 70 0;
+};
+
+ spi@131a {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = samsung,exynos-spi;
+ reg = 0x131a 0x30;
+ interrupts = 0 129 0;
+ };
+
+ spi@131b {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = samsung,exynos-spi;
+ reg = 0x131b 0x30;
+ interrupts = 0 130 0;
+ };
};
diff --git a/doc/device-tree-bindings/exynos/isp-spi.txt
b/doc/device-tree-bindings/exynos/isp-spi.txt
new file mode 100644
index 000..b8086e8
--- /dev/null
+++ b/doc/device-tree-bindings/exynos/isp-spi.txt
@@ -0,0 +1,22 @@
+Exynos ISP SPI Subsystem
+
+The device node for ISP SPI subsytem.
+Since Peripheral id in EXYNOS is decoded based on Interrupts, currently
+ISP SPI have no individual interrupts hence we add ad dummy interrupt node
+which will have a value beyond the maximum number of interrupts exynos5 can
+support.
+
+Required properties :
+ - compatible : Should be samsung,exynos-spi for spi.
+ - reg : Base adrress of the the subsystem.
+ - interrupts : A value which is beyond the maximum number of interrupts
+exynos5 can support.
+
+Example:
+spi@131a {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = samsung,exynos-spi;
+ reg = 0x131a 0x30;
+ interrupts = 0 129 0;
+};
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 16/16] SPI: EXYNOS: Add FDT support to driver.
This patch adds FDT support to the SPI driver.
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes in V1:
-Rebased on latest u-boot-samsung
drivers/spi/exynos_spi.c | 96 +++---
1 files changed, 90 insertions(+), 6 deletions(-)
diff --git a/drivers/spi/exynos_spi.c b/drivers/spi/exynos_spi.c
index 3e6c18f..7ecc566 100644
--- a/drivers/spi/exynos_spi.c
+++ b/drivers/spi/exynos_spi.c
@@ -20,6 +20,7 @@
#include common.h
#include malloc.h
#include spi.h
+#include fdtdec.h
#include asm/arch/clk.h
#include asm/arch/clock.h
#include asm/arch/cpu.h
@@ -28,16 +29,20 @@
#include asm/arch-exynos/spi.h
#include asm/io.h
+DECLARE_GLOBAL_DATA_PTR;
+
/* Information about each SPI controller */
struct spi_bus {
enum periph_id periph_id;
s32 frequency; /* Default clock frequency, -1 for none */
struct exynos_spi *regs;
int inited; /* 1 if this bus is ready for use */
+ int node;
};
/* A list of spi buses that we know about */
static struct spi_bus spi_bus[EXYNOS5_SPI_NUM_CONTROLLERS];
+static unsigned int bus_count;
struct exynos_spi_slave {
struct spi_slave slave;
@@ -50,7 +55,7 @@ struct exynos_spi_slave {
static struct spi_bus *spi_get_bus(unsigned dev_index)
{
- if (dev_index EXYNOS5_SPI_NUM_CONTROLLERS)
+ if (dev_index bus_count)
return spi_bus[dev_index];
debug(%s: invalid bus %d, __func__, dev_index);
@@ -347,21 +352,100 @@ static inline struct exynos_spi *get_spi_base(int
dev_index)
(dev_index - 3);
}
+/*
+ * Read the SPI config from the device tree node.
+ *
+ * @param blob FDT blob to read from
+ * @param node Node offset to read from
+ * @param bus SPI bus structure to fill with information
+ * @return 0 if ok, or -FDT_ERR_NOTFOUND if something was missing
+ */
+static int spi_get_config(const void *blob, int node, struct spi_bus *bus)
+{
+ bus-node = node;
+ bus-regs = (struct exynos_spi *)fdtdec_get_addr(blob, node, reg);
+ bus-periph_id = pinmux_decode_periph_id(blob, node);
+ if (bus-periph_id == PERIPH_ID_NONE) {
+ debug(%s: Invalid peripheral ID %d\n, __func__,
+ bus-periph_id);
+ return -FDT_ERR_NOTFOUND;
+ }
+
+ /* Use 500KHz as a suitable default */
+ bus-frequency = fdtdec_get_int(blob, node, spi-max-frequency,
+ 50);
+
+ return 0;
+}
+
+
+/*
+ * Process a list of nodes, adding them to our list of SPI ports.
+ *
+ * @param blob fdt blob
+ * @param node_list list of nodes to process (any =0 are ignored)
+ * @param count number of nodes to process
+ * @param is_dvc1 if these are DVC ports, 0 if standard I2C
+ * @return 0 if ok, -1 on error
+ */
+static int process_nodes(const void *blob, int node_list[], int count)
+{
+ int i;
+
+ /* build the i2c_controllers[] for each controller */
+ for (i = 0; i count; i++) {
+ int node = node_list[i];
+ struct spi_bus *bus;
+
+ if (node = 0)
+ continue;
+
+ bus = spi_bus[i];
+ if (spi_get_config(blob, node, bus)) {
+ printf(exynos spi_init: failed to decode bus %d\n,
+ i);
+ return -1;
+ }
+
+ debug(spi: controller bus %d at %p, periph_id %d\n,
+ i, bus-regs, bus-periph_id);
+ bus-inited = 1;
+ bus_count++;
+ }
+
+ return 0;
+}
+
/* Sadly there is no error return from this function */
void spi_init(void)
{
- int i;
+ int count;
+
+#ifdef CONFIG_OF_CONTROL
+ int node_list[EXYNOS5_SPI_NUM_CONTROLLERS];
+ const void *blob = gd-fdt_blob;
+
+ count = fdtdec_find_aliases_for_id(blob, spi,
+ COMPAT_SAMSUNG_EXYNOS_SPI, node_list,
+ EXYNOS5_SPI_NUM_CONTROLLERS);
+ if (process_nodes(blob, node_list, count))
+ return;
+
+#else
struct spi_bus *bus;
- for (i = 0; i EXYNOS5_SPI_NUM_CONTROLLERS; i++) {
- bus = spi_bus[i];
- bus-regs = get_spi_base(i);
- bus-periph_id = PERIPH_ID_SPI0 + i;
+ for (count = 0; i EXYNOS5_SPI_NUM_CONTROLLERS; i++) {
+ bus = spi_bus[count];
+ bus-regs = get_spi_base(count);
+ bus-periph_id = PERIPH_ID_SPI0 + count;
/* Although Exynos5 supports upto 50Mhz speed,
* we are setting it to 10Mhz for safe side
*/
bus-frequency = 1000;
bus-inited = 1;
+ bus-node = 0;
+ bus_count =
Re: [U-Boot] Booting an i.MX53 from NAND with u-boot
On Thursday, December 13, 2012 11:41:29 PM, Benoît Thébaudeau wrote: On Thursday, December 13, 2012 5:01:00 PM, Bernhard Walle wrote: I used the kobs-ng-11.09.01 software from Freescale to write the bootloader to NAND, since it also writes the necessary boot header and has support for bad pages. Is it correct to use 'u-boot.bin' (and not 'u-boot.imx')? There's some information floating around in the internet that I need some proprietary tool to convert 'u-boot.bin' to some 'streaming' format. But that information is for i.MX 28 and not for i.MX 53. I found also tools/mxsboot.c in the u-boot sources which seems to be a replacement for kobs-ng. There are several possible solutions. First, you need an SPL because the ROM bootloader does not handle all bad blocks properly, especially if the bootloader image spans several blocks. You have the choice between the old NAND SPL, which is being obsoleted, and the new generic SPL, which still requires some refinements to support NAND boot on i.MX. NAND SPL is currently the quickest solution, but generic SPL is the long term solution. For my board, I went with NAND SPL, which generates a u-boot-nand.bin file to flash. I had to customize the linker script and the startup files to add the DCD stuff to the image. Another solution could have been to generate a u-boot.imx for NAND SPL, which I will do for generic SPL at some point. Also, contrary to usual u-boot images, u-boot.imx should be flashed at offset 0x400, which may be surprising for NAND. 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 v2 08/58] ixp: Move timestamp to arch_global_data
Dear Simon Glass,
Move this field into arch_global_data and tidy up.
Signed-off-by: Simon Glass s...@chromium.org
I think we should kill IXP. Did the IXP custodian show any activity? If not,
let's just remove this piece of junk.
Otherwise Acked-by: Marek Vasut ma...@denx.de
---
Changes in v2: None
arch/arm/cpu/ixp/timer.c |8
arch/arm/include/asm/global_data.h |6 +++---
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/cpu/ixp/timer.c b/arch/arm/cpu/ixp/timer.c
index 0450b51..663d989 100644
--- a/arch/arm/cpu/ixp/timer.c
+++ b/arch/arm/cpu/ixp/timer.c
@@ -70,14 +70,14 @@ unsigned long long get_ticks(void)
if (readl(IXP425_OSST) IXP425_OSST_TIMER_TS_PEND) {
/* rollover of timestamp timer register */
- gd-timestamp += (0x - gd-arch.lastinc) + now + 1;
+ gd-arch.timestamp += (0x - gd-arch.lastinc) + now + 1;
writel(IXP425_OSST_TIMER_TS_PEND, IXP425_OSST);
} else {
/* move stamp forward with absolut diff ticks */
- gd-timestamp += (now - gd-arch.lastinc);
+ gd-arch.timestamp += (now - gd-arch.lastinc);
}
gd-arch.lastinc = now;
- return gd-timestamp;
+ return gd-arch.timestamp;
}
@@ -86,7 +86,7 @@ void reset_timer_masked(void)
/* capture current timestamp counter */
gd-arch.lastinc = readl(IXP425_OSTS_B);
/* start advancing time stamp from 0 */
- gd-timestamp = 0;
+ gd-arch.timestamp = 0;
}
ulong get_timer_masked(void)
diff --git a/arch/arm/include/asm/global_data.h
b/arch/arm/include/asm/global_data.h index 95e23e1..35d07d0 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -41,6 +41,9 @@ struct arch_global_data {
unsigned long tbl;
unsigned long lastinc;
unsigned long long timer_reset_value;
+#ifdef CONFIG_IXP425
+ unsigned long timestamp;
+#endif
};
/*
@@ -65,9 +68,6 @@ typedef struct global_data {
#ifdef CONFIG_FSL_ESDHC
unsigned long sdhc_clk;
#endif
-#ifdef CONFIG_IXP425
- unsigned long timestamp;
-#endif
unsigned long relocaddr; /* Start address of U-Boot in RAM */
phys_size_t ram_size; /* RAM size */
unsigned long mon_len;/* monitor len */
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 0/7] gpt: GUID Partition Table (GPT) restoration
On Tue, Dec 11, 2012 at 11:09:41AM +0100, Piotr Wilczek wrote:
This patch series provides a new command - gpt for eMMC partition table
(in the GPT format) restoration.
As a pre-work, some cleanup at the part_efi.c file was performed to
remove custom macros and make GPT related structures more readable.
Moreover the part_efi.h file has been moved to ./include directory to
be easily available from other subsystems.
The GPT detailed description has been written to README.gpt file.
Tested at:
- Exynos4210 rev.1 - TRATS Samsung development board
Chang Hyun Park (1):
gpt: The leXX_to_int() calls replaced with ones defined at
compiler.h
Lukasz Majewski (5):
vsprintf:fix: Change type returned by ustrtoul
part:efi: Move part_efi.h file to ./include
gpt:doc: GPT (GUID Partition Table) documentation
gpt: Support for GPT (GUID Partition Table) restoration
gpt: Enable support for GPT partition table restoration at Samsung's
Trats
Piotr Wilczek (1):
gpt: Support for new gpt command
common/Makefile |1 +
common/cmd_gpt.c | 333 +++
disk/part_efi.c | 394
++
doc/README.gpt | 201 +
include/configs/trats.h | 28 ++-
include/exports.h|2 +-
include/part.h | 52 ++
{disk = include}/part_efi.h | 89 +-
lib/vsprintf.c |2 +-
9 files changed, 982 insertions(+), 120 deletions(-)
create mode 100644 common/cmd_gpt.c
create mode 100644 doc/README.gpt
rename {disk = include}/part_efi.h (66%)
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 v5 0/20] Add environment call-back and flags capability
On Tue, Dec 11, 2012 at 10:16:17PM -0600, Joe Hershberger wrote: When a variable with a registered callback is inserted, deleted, or overwritten the callback is called and gives the system an opportunity to do something in response to the change. It also has the opportunuty to reject the change by returning non-zero. The flags on variables can control their type as well as their allowed access. The format of the list is: type_attribute = [s|d|x|b|i|m] attributes = type_attribute entry = variable_name[:attributes] list = entry[,list] The type attributes are: s - String (default) d - Decimal x - Hexadecimal b - Boolean ([1yYtT|0nNfF]) i - IP address m - MAC address The access attributes are: a - Any (default) r - Read-only o - Write-once c - Change-default Changes in v5: - Manually relocate change_ok() pointer - Add support for CONFIG_NEEDS_MANUAL_RELOC boards - Fixed comment typo - Fixed callbacks command help - Compare current callback against pre-relocation address manually - Fixed out-of-bounds array access in env_flags_parse_vartype() - Fixed out-of-bounds array access in env_flags_parse_varaccess() Changes in v4: - Prevent crash on relocation import - Fixed help text - Add help text for env flags command - Add force support to setenv - Implement delete Changes in v3: - Rebase onto Gerlando Falauto's env patches - Refactor himport_r() and hsearch_r()'s parameters - Split hdelete_r() into the core delete and the validation before delete - Delete vars on failed insertion - Use Marek's linker lists instead of implementing it directly - Rebase onto latest master - Add flags parameter to callbacks - Implement reverse search in env_attr_lookup() - Fix space skipping in env_attr_lookup() - All errors coming back from hsearch_r() are no longer fatal. Don't abort import on failed ENTER action. - Removed checkpatch.pl warning Changes in v2: - Added much-needed documentation - Factored out prevch and nextch in env_attr_lookup() Joe Hershberger (20): Make linux kernel string funcs available to tools env: Refactor do_apply to a flag env: Consolidate common code in hsearch_r() env: Refactor apply into change_ok env: Use getenv_yesno() more generally env: Hide '.' variables in env print by default env: Add support for callbacks to environment vars env: Add a command to view callbacks env: Add a bootfile env handler env: Add a baudrate env handler env: Add a loadaddr env handler env: Add a console env handler env: Add a silent env handler env: Add environment variable flags tools/env: Add environment variable flags support env: Add a command to display details about env flags env: Add support for access control to .flags env: Add setenv force support env: Implement the env delete command env: Handle write-once ethaddr and serial# generically README | 80 ++ arch/arm/lib/board.c| 4 +- arch/m68k/lib/board.c | 3 +- arch/microblaze/lib/board.c | 4 +- arch/powerpc/cpu/mpc85xx/mp.c | 4 +- arch/powerpc/lib/board.c| 9 +- arch/sparc/lib/board.c | 3 +- board/Marvell/db64360/db64360.c | 10 +- board/Marvell/db64460/db64460.c | 10 +- board/esd/cpci750/cpci750.c | 10 +- board/esd/pmc440/cmd_pmc440.c | 2 +- board/gw8260/gw8260.c | 10 +- board/prodrive/p3mx/p3mx.c | 10 +- common/Makefile | 6 + common/cmd_nvedit.c | 406 + common/console.c| 75 +- common/env_attr.c | 229 common/env_callback.c | 144 +++ common/env_common.c | 61 +++-- common/env_dataflash.c | 2 +- common/env_eeprom.c | 2 +- common/env_fat.c| 2 +- common/env_flags.c | 560 common/env_flash.c | 4 +- common/env_mmc.c| 2 +- common/env_nand.c | 4 +- common/env_nvram.c | 2 +- common/env_onenand.c| 2 +- common/env_sf.c | 4 +- common/image.c | 21 +- doc/README.silent | 14 +- drivers/serial/serial.c | 70 + include/common.h| 5 + include/env_attr.h | 55 include/env_callback.h | 75 ++ include/env_default.h | 8 + include/env_flags.h | 172 include/environment.h | 15 +- include/image.h | 1 - include/linux/linux_string.h| 8
[U-Boot] [PATCH] powerpc/mpc85xx: Reserve default boot page
The boot page in memory is already reserved so OS won't overwrite.
As long as the boot page translation is active, the default boot page
also needs to be reserved in case the memory is 4GB or more.
Signed-off-by: York Sun york...@freescale.com
---
arch/powerpc/cpu/mpc85xx/fdt.c | 16
1 file changed, 16 insertions(+)
diff --git a/arch/powerpc/cpu/mpc85xx/fdt.c b/arch/powerpc/cpu/mpc85xx/fdt.c
index 5af2661..43a8e6d 100644
--- a/arch/powerpc/cpu/mpc85xx/fdt.c
+++ b/arch/powerpc/cpu/mpc85xx/fdt.c
@@ -100,6 +100,22 @@ void ft_fixup_cpu(void *blob, u64 memory_limit)
printf(Failed to reserve memory for bootpg: %s\n,
fdt_strerror(off));
}
+
+#ifndef CONFIG_MPC8xxx_DISABLE_BPTR
+ /*
+* Reserve the default boot page so OSes dont use it.
+* The default boot page is always mapped to bootpg above using
+* boot page translation.
+*/
+ if (0xf000ull memory_limit) {
+ off = fdt_add_mem_rsv(blob, 0xf000ull, (u64)4096);
+ if (off 0) {
+ printf(Failed to reserve memory for 0xf000: %s\n,
+ fdt_strerror(off));
+ }
+ }
+#endif
+
/* Reserve spin table page */
if (spin_tbl_addr memory_limit) {
off = fdt_add_mem_rsv(blob,
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 49/58] microblaze: Use generic global_data
Hi Michal, On Fri, Dec 14, 2012 at 2:45 AM, Michal Simek mon...@monstr.eu wrote: Hi Simon, 2012/12/14 Simon Glass s...@chromium.org: Move microblaze over to use generic global_data. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: None arch/microblaze/include/asm/global_data.h | 27 +-- 1 files changed, 1 insertions(+), 26 deletions(-) will be better to provide link to any git repo/branch which I can just download and test. Anyway I have tested it on real hw without any issue. Tested-by: Michal Simek mon...@monstr.eu Thanks. I have pushed the source tree here for now: http://git.denx.de/u-boot-x86.git(branch us-board-gc6) Regards, Simon Thanks, Michal -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Conflicting commits for seaboard USB keyboard handling
Albert, On Thu, Dec 13, 2012 at 12:20 PM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Tom, On Mon, 10 Dec 2012 14:15:10 -0700, Tom Warren twarren.nvi...@gmail.com wrote: u-boot-arm/master and u-boot-tegra/next should have the same base commit (b8a7c46), so merging them isn't a big deal, and goes smoothly for me. If I then take u-boot/master and merge it, I see a conflict in drivers/power/power_fls.c and include/configs/mx35pdk.h and mx53loco.h, but no problems with Tegra code. I could resolve those conflicts and continue with the rebase, but ... Correct me if I'm wrong, but u-boot-tegra and u-boot-usb are both pulled into u-boot-arm, and (I thought) u-boot-arm is then (or eventually) pulled into u-boot/master. I don't pull from u-boot-usb (or any other 'sub' repo), since that would appear to create conflicts when Albert pulls into u-boot-arm. I also don't pull from u-boot/master, since it's essentially 2 levels above me. Albert - if you can, please show me exactly what fetch/merge or rebase command sequence is failing for you. I'm still not clear on what the exact merge conflict error is, nor how to fix it. Or Allen, if you have better visibility into exactly what the merge conflict is w/Tegra that I'm just not seeing, maybe you could provide either a patchset that'll fix it or steps I can take to do the same. As for what I did, it was simply to try and merge u-boot-tegra into u-boot-arm. U-boot-tegra/master is synced up with u-boot-arm/master, i.e. both are at top commit b8a7c46. git fetch git://git.denx.de/u-boot-arm master shows a FETCH_HEAD of b8a7c467960ffb4d5a5e1eef5f7783fb6f594542branch 'master' of git://git.denx.de/u-boot-arm which is the top commit of my current u-boot-tegra/master on denx.de. So merging the two should be seamless and pain-free. Regarding u-boot-usb, it is not usually pulled into u-boot-arm; but if it was needed by, and pulled into, u-boot-tegra, then it would have automatically been pulled into u-boot-arm when I fetched u-boot-tegra, and merged when I did the merge. Would it not? As to u-boot-usb, I made a mistaken assumption that you pull it into u-boot-arm because I saw commits with: Merge master of u-boot-usb.git in the commit log, but those came from u-boot/master, not from you. My bad. I don't (and won't) pull from any other repo into u-boot-tegra, except when I merge w/my 'parent', u-boot-arm/master, just before I issue a pull request to you. I'm at the very bottom of the chain, and only feed into your repo, with no one feeding into mine (except when I merge w/you, of course, to stay in sync). Allen has offered to resolve the conflict with his USB patches in seaboard.h and tegra-common.h. Please work with him to get a patchset that can be applied to the ARM or USB repos to resolve this problem. IMO, u-boot-tegra/master is OK as is and not the source of the conflict (correct me if I'm wrong). Thanks, Tom Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] UBI Fixable bit-flip issue.
Hello, I'm seeing a fixable bit-flip in the current u-boot (v2012.10) on a i.Mx6 Solo based custom board. The problem is similar to the one explained here [1]. As observed by the thread's author, does reverting the commit 1b1f9a9 solves the issue? Did someone face a similar issue? Thanks, Vikram [1] http://lists.denx.de/pipermail/u-boot/2011-September/100237.html [2] http://lists.denx.de/pipermail/u-boot/2011-September/101887.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] imls: Add support to list images in NAND device
On 12/14/2012 03:32:04 AM, Vipin Kumar wrote:
+
+ switch (genimg_get_format(buffer)) {
+ case IMAGE_FORMAT_LEGACY:
+ header = (const image_header_t *)buffer;
+ len = image_get_image_size(header);
+
+ ret = nand_imls_legacyimage(nand,
nand_dev,
+ off, len);
+ if (ret 0 ret != -ENOMEM)
+ return ret;
+ break;
+#if defined(CONFIG_FIT)
+ case IMAGE_FORMAT_FIT:
+ len = fit_get_size(buffer);
+ ret = nand_imls_fitimage(nand, nand_dev,
+ off, len);
+ if (ret 0 ret != -ENOMEM)
+ return ret;
+ break;
+#endif
+ }
Do you really mean to return from the main imls function just because
one image has an error? By use return I meant return from the
subfunction.
This return only corresponds to the situation when there is an error
returned from nand read routine. In that case, I don't think there is
any use reading the NAND any further.
Just because one page has an uncorrectable error doesn't mean the
entire NAND is bad. Note that this is different from what you
currently do if you get an error on the initial read where you look for
a header.
Might want to bail out if you get an excessive amount of errors
(particularly consecutive), though, suggesting that the NAND might not
be working at all. The user probably doesn't want to wait for
thousands of error messages to scroll by in that case.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] imls: Add support to list images in NAND device
On 12/14/2012 03:23:26 AM, Vipin Kumar wrote:
On 12/14/2012 3:22 AM, Scott Wood wrote:
On 12/13/2012 12:10:58 AM, Vipin Kumar wrote:
+ imgdata = malloc(read_size);
+ if (!imgdata) {
+ printf(Not able to list all
images \
+ (Low memory)\n);
Don't line-wrap error strings.
80 column ?
Error strings are an exception for the sake of greppability. From
Linux's Documentation/CodingStyle:
Statements longer than 80 columns will be broken into sensible
chunks, unless
exceeding 80 columns significantly increases readability and does
not hide
information. Descendants are always substantially shorter than
the
parent and
are placed substantially to the right. The same applies to
function
headers
with a long argument list. However, never break user-visible
strings
such as
printk messages, because that breaks the ability to grep for
them.
Yes, thanks for reminding. The error strings are more readable
already in v3. Please take a look
No, you're still breaking up strings (and you also have a totally
unnecessary backslash). If it's on one line in the output, it should
be on one line in the source.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ns16550: allow UART address to be set dynamically
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/13/12 16:51, Simon Glass wrote:
[snip]
And from there we can move on and say On ${SoC} we get a
device tree (that we can't quite parse as we don't have enough
resources) AND $some-data (OMDATA or an abbreviated device tree
or $whatever), lets translate that into something we can make
use of very early rather than a hard-coded initial console
location
It seems like you're saying that once we have dynamic serial
port assignment working based on DT, you'll be fine using ODMDATA
to initialize the early console, but not before then? If so, I'm
having a hard time understanding why enabling the DT-based
support blocks using ODMDATA, since the code would be pretty
orthogonal.
Yes well dynamic console selection sounds find to me, ODMDATA or
otherwise. To me it is a Tegra feature that should be supported as
such. Perhaps we can allow the FDT console alias to specify
odmdata to mean that, and/or (as you suggest I think) set the
console to USE_ODMDATA, which then selects CONFIG_SYS_NS16550_COMx
accordingly.
There's two parts to it. One part is that sure, Tegra and only Tegra
has ODMDATA. But on am33xx if we poke the i2c eeprom (on platforms
that do the eeprom) we can then know ... And I bet other SoCs have
other tricks for this or that. So it's not just tegra that can tell
us the initial console is $here or $there if we just ...something.
The other part is, take a look at the Allwinner thread from a week or
so ago. We really need to define how we want early board specific
data to come in because if we start saying we'll accept per-SoC
solutions we'll be drowning in them in short time. We want to say
here's our preferred way to pass this information in.
- --
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQIcBAEBAgAGBQJQy47RAAoJENk4IS6UOR1W/wIP/1CyXg8ShiITZAS6/R52Aj89
X7mhTHWUg3m+BtEN8TGkI8foznHjpv5JK7Exlf8XgKuoH6idBYd/5eF6nRXGfePY
rQAad+hHeBYSBfvaP6GIaSTMm5x6KDMILExDkxue0mNcdkRL568ac0oR/HsVPM/N
d75PVHsK77dAIzm9DbT3m2zilHC6balbplG1LtnKx0+sKb/PGpfXT5GYCZUUc9es
R2Uzkyx+f25ZTlVRzdrh+h8SDhNzuACszJtqY11SxhLUZevvkja0jm6LykBsyJGH
wh1wydRRPN6LKWRVQgUAHBJBEebf6Olck+PPBBA3+LypN5kSuj+bKixoyNxTQHIf
E8qJb59rB7bnXLVb43AudcbUWe/PqdwZ8Yha3dmMrT/r8k0eXfNLBXlIP8BDXPis
4ssoH/DZXqv0+QvsmX+NPoF/3pBSy/Uc1g13w20xbdy12ovGEVgOWwioOPKgWgCR
b34CvOT7MR+8zMixCHP287ITyTrpY/K7gxo2rF8EQ+o6QW1JCphTJFpVqlTVWEAT
5vPMnt7y7w9WtImCxUpa7itMfeVOgnbv+2bB2Ipxj6VjOZcIvdqB405wN39bGYux
fzatCFurtbdaSQ7aFR1ZFRp51rjl/rC7QxODD0H84Ip7AbVO2qLPOTri2wwYfaPN
EXPCI+T8YtDbI2/RW92B
=DR6s
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 01/10] x86: Add function to get top of usable ram
The memory layout calculations are done in calculate_relocation_address(),
and coreboot has its own version of this function. But in fact all we
really need is to set the top of usable RAM, and then the base version
will work as is.
So instead of allowing the whole calculate_relocation_address() function
to be replaced, create board_get_usable_ram_top() which can be used by
a board to specify the top of the area where U-Boot relocations to.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/x86/cpu/coreboot/sdram.c | 18 --
arch/x86/lib/init_helpers.c | 28 ++--
2 files changed, 22 insertions(+), 24 deletions(-)
diff --git a/arch/x86/cpu/coreboot/sdram.c b/arch/x86/cpu/coreboot/sdram.c
index 76274cb..a8136a0 100644
--- a/arch/x86/cpu/coreboot/sdram.c
+++ b/arch/x86/cpu/coreboot/sdram.c
@@ -60,12 +60,8 @@ unsigned install_e820_map(unsigned max_entries, struct
e820entry *entries)
* address, and how far U-Boot is moved by relocation are set in the global
* data structure.
*/
-int calculate_relocation_address(void)
+ulong board_get_usable_ram_top(ulong total_size)
{
- const uint64_t uboot_size = (uintptr_t)__bss_end -
- (uintptr_t)__text_start;
- const uint64_t total_size = uboot_size + CONFIG_SYS_MALLOC_LEN +
- CONFIG_SYS_STACK_SIZE;
uintptr_t dest_addr = 0;
int i;
@@ -87,21 +83,15 @@ int calculate_relocation_address(void)
continue;
/* Use this address if it's the largest so far. */
- if (end - uboot_size dest_addr)
+ if (end dest_addr)
dest_addr = end;
}
/* If no suitable area was found, return an error. */
if (!dest_addr)
- return 1;
+ panic(No available memory found for relocation);
- dest_addr -= uboot_size;
- dest_addr = ~((1 12) - 1);
- gd-relocaddr = dest_addr;
- gd-reloc_off = dest_addr - (uintptr_t)__text_start;
- gd-start_addr_sp = dest_addr - CONFIG_SYS_MALLOC_LEN;
-
- return 0;
+ return (ulong)dest_addr;
}
int dram_init_f(void)
diff --git a/arch/x86/lib/init_helpers.c b/arch/x86/lib/init_helpers.c
index 3eec9a6..1a097f1 100644
--- a/arch/x86/lib/init_helpers.c
+++ b/arch/x86/lib/init_helpers.c
@@ -73,26 +73,34 @@ int init_baudrate_f(void)
return 0;
}
-__weak int calculate_relocation_address(void)
+/* Get the top of usable RAM */
+__weak ulong board_get_usable_ram_top(ulong total_size)
{
- ulong text_start = (ulong)__text_start;
- ulong bss_end = (ulong)__bss_end;
+ return gd-ram_size;
+}
+
+int calculate_relocation_address(void)
+{
+ const ulong uboot_size = (uintptr_t)__bss_end -
+ (uintptr_t)__text_start;
+ ulong total_size;
ulong dest_addr;
+ total_size = ALIGN(uboot_size, 1 12) + CONFIG_SYS_MALLOC_LEN +
+ CONFIG_SYS_STACK_SIZE;
+
/*
* NOTE: All destination address are rounded down to 16-byte
* boundary to satisfy various worst-case alignment
* requirements
*/
+ dest_addr = board_get_usable_ram_top(total_size);
- /* Stack is at top of available memory */
- dest_addr = gd-ram_size;
-
- /* U-Boot is at the top */
- dest_addr -= (bss_end - text_start);
- dest_addr = ~15;
+ /* U-Boot is below the FDT */
+ dest_addr -= uboot_size;
+ dest_addr = ~((1 12) - 1);
gd-relocaddr = dest_addr;
- gd-reloc_off = (dest_addr - text_start);
+ gd-reloc_off = dest_addr - (uintptr_t)__text_start;
/* Stack is at the bottom, so it can grow down */
gd-start_addr_sp = dest_addr - CONFIG_SYS_MALLOC_LEN;
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ns16550: allow UART address to be set dynamically
Hi Tom,
On Fri, Dec 14, 2012 at 12:40 PM, Tom Rini tr...@ti.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/13/12 16:51, Simon Glass wrote:
[snip]
And from there we can move on and say On ${SoC} we get a
device tree (that we can't quite parse as we don't have enough
resources) AND $some-data (OMDATA or an abbreviated device tree
or $whatever), lets translate that into something we can make
use of very early rather than a hard-coded initial console
location
It seems like you're saying that once we have dynamic serial
port assignment working based on DT, you'll be fine using ODMDATA
to initialize the early console, but not before then? If so, I'm
having a hard time understanding why enabling the DT-based
support blocks using ODMDATA, since the code would be pretty
orthogonal.
Yes well dynamic console selection sounds find to me, ODMDATA or
otherwise. To me it is a Tegra feature that should be supported as
such. Perhaps we can allow the FDT console alias to specify
odmdata to mean that, and/or (as you suggest I think) set the
console to USE_ODMDATA, which then selects CONFIG_SYS_NS16550_COMx
accordingly.
There's two parts to it. One part is that sure, Tegra and only Tegra
has ODMDATA. But on am33xx if we poke the i2c eeprom (on platforms
that do the eeprom) we can then know ... And I bet other SoCs have
other tricks for this or that. So it's not just tegra that can tell
us the initial console is $here or $there if we just ...something.
The other part is, take a look at the Allwinner thread from a week or
so ago. We really need to define how we want early board specific
data to come in because if we start saying we'll accept per-SoC
solutions we'll be drowning in them in short time. We want to say
here's our preferred way to pass this information in.
Yes there is a general problem to be solved here. Assuming that the
problem is solved in U-Boot itself with device tree, then:
1. It would be nice to keep a single source for this information so
that SPL and U-Boot are consistent. Where we invent a new mechanism
for efficiency reasons it would be best if there was a 1-1 mapping
from device tree to this new mechanism.
2. It would be nice if we could write a simple tool which is generic
across architectures and configures an SPL given a device tree file.
I'm not sure if that is a problem worth solving or not.
3. From the SPL point of view, the less code required to get at the
information, the better.
For one possible solution, see:
arch/arm/include/asm/arch-exynos/spl.h
Basically it works (for a small number of parameters) by giving each a
letter, and listing the required parameters in the structure. An
external tool can then fairly easily fill in the values it needs from
the device tree, without worrying about the format being wrong, etc.
I'm not sure that it scales to all SOCs though.
Personally I would like to see the simplest option possible and avoid
inventing a new infrastructure just for SPL.
Regards,
Simon
- --
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQIcBAEBAgAGBQJQy47RAAoJENk4IS6UOR1W/wIP/1CyXg8ShiITZAS6/R52Aj89
X7mhTHWUg3m+BtEN8TGkI8foznHjpv5JK7Exlf8XgKuoH6idBYd/5eF6nRXGfePY
rQAad+hHeBYSBfvaP6GIaSTMm5x6KDMILExDkxue0mNcdkRL568ac0oR/HsVPM/N
d75PVHsK77dAIzm9DbT3m2zilHC6balbplG1LtnKx0+sKb/PGpfXT5GYCZUUc9es
R2Uzkyx+f25ZTlVRzdrh+h8SDhNzuACszJtqY11SxhLUZevvkja0jm6LykBsyJGH
wh1wydRRPN6LKWRVQgUAHBJBEebf6Olck+PPBBA3+LypN5kSuj+bKixoyNxTQHIf
E8qJb59rB7bnXLVb43AudcbUWe/PqdwZ8Yha3dmMrT/r8k0eXfNLBXlIP8BDXPis
4ssoH/DZXqv0+QvsmX+NPoF/3pBSy/Uc1g13w20xbdy12ovGEVgOWwioOPKgWgCR
b34CvOT7MR+8zMixCHP287ITyTrpY/K7gxo2rF8EQ+o6QW1JCphTJFpVqlTVWEAT
5vPMnt7y7w9WtImCxUpa7itMfeVOgnbv+2bB2Ipxj6VjOZcIvdqB405wN39bGYux
fzatCFurtbdaSQ7aFR1ZFRp51rjl/rC7QxODD0H84Ip7AbVO2qLPOTri2wwYfaPN
EXPCI+T8YtDbI2/RW92B
=DR6s
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 04/10] x86: Add an __end symbol to signal the end of the U-Boot binary
With this symbol we can easy append something (e.g. an FDT) to the U-Boot
binary and access it from within U-Boot.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/x86/cpu/u-boot.lds |2 ++
arch/x86/include/asm/u-boot-x86.h |1 +
arch/x86/lib/init_helpers.c |2 +-
3 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/x86/cpu/u-boot.lds b/arch/x86/cpu/u-boot.lds
index 0c6f0e3..2a7d0fd 100644
--- a/arch/x86/cpu/u-boot.lds
+++ b/arch/x86/cpu/u-boot.lds
@@ -67,6 +67,8 @@ SECTIONS
__rel_dyn_start = .;
.rel.dyn : { *(.rel.dyn) }
__rel_dyn_end = .;
+ . = ALIGN(4);
+ __end = .;
/DISCARD/ : { *(.dynstr*) }
/DISCARD/ : { *(.dynamic*) }
diff --git a/arch/x86/include/asm/u-boot-x86.h
b/arch/x86/include/asm/u-boot-x86.h
index 99062e5..ef0da4f 100644
--- a/arch/x86/include/asm/u-boot-x86.h
+++ b/arch/x86/include/asm/u-boot-x86.h
@@ -31,6 +31,7 @@ extern ulong __rel_dyn_start;
extern ulong __rel_dyn_end;
extern ulong __bss_start;
extern ulong __bss_end;
+extern ulong __end;
/* cpu/.../cpu.c */
int x86_cpu_init_r(void);
diff --git a/arch/x86/lib/init_helpers.c b/arch/x86/lib/init_helpers.c
index 1a097f1..9a72f3b 100644
--- a/arch/x86/lib/init_helpers.c
+++ b/arch/x86/lib/init_helpers.c
@@ -188,7 +188,7 @@ int find_fdt(void)
gd-fdt_blob = _binary_dt_dtb_start;
#elif defined CONFIG_OF_SEPARATE
/* FDT is at end of image */
- gd-fdt_blob = (void *)(_end_ofs + _TEXT_BASE);
+ gd-fdt_blob = (ulong *)__end;
#endif
/* Allow the early environment to override the fdt address */
gd-fdt_blob = (void *)getenv_ulong(fdtcontroladdr, 16,
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 02/10] x86: Add basic cache operations
At present most x86 cache operations are undefined. Add a basic
implementation for these.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/x86/cpu/cpu.c | 23 +++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
index 315e87a..fe6e568 100644
--- a/arch/x86/cpu/cpu.c
+++ b/arch/x86/cpu/cpu.c
@@ -226,3 +226,26 @@ void flush_dcache_range(unsigned long start, unsigned long
stop)
void invalidate_dcache_range(unsigned long start, unsigned long stop)
{
}
+
+void dcache_enable(void)
+{
+ enable_caches();
+}
+
+void dcache_disable(void)
+{
+ disable_caches();
+}
+
+void icache_enable(void)
+{
+}
+
+void icache_disable(void)
+{
+}
+
+int icache_status(void)
+{
+ return 1;
+}
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 06/10] x86: Support relocation of FDT on start-up
With CONFIG_OF_CONTROL we may have an FDT in the BSS region. Relocate
it up with the rest of U-Boot to keep the rest of memory free.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/x86/include/asm/global_data.h |1 +
arch/x86/include/asm/init_helpers.h |2 ++
arch/x86/include/asm/relocate.h |1 +
arch/x86/lib/board.c|3 +++
arch/x86/lib/init_helpers.c | 23 +--
arch/x86/lib/init_wrappers.c|1 +
arch/x86/lib/relocate.c | 17 +
7 files changed, 46 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/global_data.h
b/arch/x86/include/asm/global_data.h
index dc6402b..2f3644e 100644
--- a/arch/x86/include/asm/global_data.h
+++ b/arch/x86/include/asm/global_data.h
@@ -59,6 +59,7 @@ struct global_data {
phys_size_t ram_size; /* RAM size */
unsigned long reset_status; /* reset status register at boot */
const void *fdt_blob; /* Our device tree, NULL if none */
+ void*new_fdt; /* Relocated FDT */
void**jt; /* jump table */
charenv_buf[32];/* buffer for getenv() before reloc. */
};
diff --git a/arch/x86/include/asm/init_helpers.h
b/arch/x86/include/asm/init_helpers.h
index 2f437e0..d018b29 100644
--- a/arch/x86/include/asm/init_helpers.h
+++ b/arch/x86/include/asm/init_helpers.h
@@ -38,5 +38,7 @@ int flash_init_r(void);
int status_led_set_r(void);
int set_load_addr_r(void);
int init_func_spi(void);
+int find_fdt(void);
+int prepare_fdt(void);
#endif /* !_INIT_HELPERS_H_ */
diff --git a/arch/x86/include/asm/relocate.h b/arch/x86/include/asm/relocate.h
index 33129ef..d371c9d 100644
--- a/arch/x86/include/asm/relocate.h
+++ b/arch/x86/include/asm/relocate.h
@@ -27,6 +27,7 @@
#include common.h
int copy_uboot_to_ram(void);
+int copy_fdt_to_ram(void);
int clear_bss(void);
int do_elf_reloc_fixups(void);
diff --git a/arch/x86/lib/board.c b/arch/x86/lib/board.c
index 22bc26d..555301a 100644
--- a/arch/x86/lib/board.c
+++ b/arch/x86/lib/board.c
@@ -32,6 +32,7 @@
*/
#include common.h
+#include fdtdec.h
#include watchdog.h
#include stdio_dev.h
#include asm/u-boot-x86.h
@@ -131,6 +132,7 @@ init_fnc_t *init_sequence_f[] = {
init_fnc_t *init_sequence_f_r[] = {
init_cache_f_r,
copy_uboot_to_ram,
+ copy_fdt_to_ram,
clear_bss,
do_elf_reloc_fixups,
@@ -217,6 +219,7 @@ static void do_init_loop(init_fnc_t **init_fnc_ptr)
void board_init_f(ulong boot_flags)
{
+ gd-fdt_blob = gd-new_fdt = NULL;
gd-flags = boot_flags;
do_init_loop(init_sequence_f);
diff --git a/arch/x86/lib/init_helpers.c b/arch/x86/lib/init_helpers.c
index 9a72f3b..5b28dcf 100644
--- a/arch/x86/lib/init_helpers.c
+++ b/arch/x86/lib/init_helpers.c
@@ -22,6 +22,7 @@
*/
#include common.h
#include command.h
+#include fdtdec.h
#include stdio_dev.h
#include version.h
#include malloc.h
@@ -85,17 +86,35 @@ int calculate_relocation_address(void)
(uintptr_t)__text_start;
ulong total_size;
ulong dest_addr;
+ ulong fdt_size = 0;
+#if defined(CONFIG_OF_SEPARATE) defined(CONFIG_OF_CONTROL)
+ if (gd-fdt_blob)
+ fdt_size = ALIGN(fdt_totalsize(gd-fdt_blob) + 0x1000, 32);
+#endif
total_size = ALIGN(uboot_size, 1 12) + CONFIG_SYS_MALLOC_LEN +
- CONFIG_SYS_STACK_SIZE;
+ CONFIG_SYS_STACK_SIZE + fdt_size;
+ dest_addr = board_get_usable_ram_top(total_size);
/*
* NOTE: All destination address are rounded down to 16-byte
* boundary to satisfy various worst-case alignment
* requirements
*/
- dest_addr = board_get_usable_ram_top(total_size);
+ dest_addr = ~15;
+#if defined(CONFIG_OF_SEPARATE) defined(CONFIG_OF_CONTROL)
+ /*
+* If the device tree is sitting immediate above our image then we
+* must relocate it. If it is embedded in the data section, then it
+* will be relocated with other data.
+*/
+ if (gd-fdt_blob) {
+ dest_addr -= fdt_size;
+ gd-new_fdt = (void *)dest_addr;
+ dest_addr = ~15;
+ }
+#endif
/* U-Boot is below the FDT */
dest_addr -= uboot_size;
dest_addr = ~((1 12) - 1);
diff --git a/arch/x86/lib/init_wrappers.c b/arch/x86/lib/init_wrappers.c
index cca018f..19af875 100644
--- a/arch/x86/lib/init_wrappers.c
+++ b/arch/x86/lib/init_wrappers.c
@@ -22,6 +22,7 @@
*/
#include common.h
#include environment.h
+#include fdtdec.h
#include serial.h
#include kgdb.h
#include scsi.h
diff --git a/arch/x86/lib/relocate.c b/arch/x86/lib/relocate.c
index 23edca9..e9188a7 100644
--- a/arch/x86/lib/relocate.c
+++ b/arch/x86/lib/relocate.c
@@ -32,6 +32,7 @@
*/
#include common.h
+#include libfdt.h
#include malloc.h
#include asm/u-boot-x86.h
[U-Boot] [PATCH 03/10] x86: Permit bootstage and timer data to be used prior to relocation
It is useful to be able to access the timer before U-Boot has relocated
so that we can fully support bootstage.
Move the relevant variables to the data region to support this.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/x86/cpu/coreboot/coreboot.c |4 ++--
arch/x86/cpu/interrupts.c|2 +-
arch/x86/lib/timer.c |2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/cpu/coreboot/coreboot.c b/arch/x86/cpu/coreboot/coreboot.c
index 9c9431e..22474f5 100644
--- a/arch/x86/cpu/coreboot/coreboot.c
+++ b/arch/x86/cpu/coreboot/coreboot.c
@@ -68,8 +68,8 @@ int board_early_init_r(void)
void show_boot_progress(int val)
{
#if MIN_PORT80_KCLOCKS_DELAY
- static uint32_t prev_stamp;
- static uint32_t base;
+ static uint32_t prev_stamp __attribute__((section(.data)));
+ static uint32_t base __attribute__((section(.data)));
/*
* Scale the time counter reading to avoid using 64 bit arithmetics.
diff --git a/arch/x86/cpu/interrupts.c b/arch/x86/cpu/interrupts.c
index dd30a05..60ae950 100644
--- a/arch/x86/cpu/interrupts.c
+++ b/arch/x86/cpu/interrupts.c
@@ -626,7 +626,7 @@ asm(.globl irq_common_entry\n \
*/
u64 get_ticks(void)
{
- static u64 tick_base;
+ static u64 tick_base __attribute__((section(.data)));
u64 now_tick = rdtsc();
if (!tick_base)
diff --git a/arch/x86/lib/timer.c b/arch/x86/lib/timer.c
index a13424b..6303ca5 100644
--- a/arch/x86/lib/timer.c
+++ b/arch/x86/lib/timer.c
@@ -37,7 +37,7 @@ struct timer_isr_function {
static struct timer_isr_function *first_timer_isr;
static unsigned long system_ticks;
-static uint64_t base_value;
+static uint64_t base_value __attribute__((section(.data)));
/*
* register_timer_isr() allows multiple architecture and board specific
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 07/10] x86: Add error checking to x86 relocation code
This does not actually change normal behaviour, but adds a check that
should detect corruption of relocation data (e.g. by using BSS data
prior to relocation).
Also add additional debugging output when enabled.
During this investigation, two situations have been seen:
1. calculate_relocation_address():
uintptr_t size = (uintptr_t)__bss_end - (uintptr_t)__text_start;
turns into
66f: b8 83 c4 17 01 mov$0x117c483,%eax
whih is beyond the end of bss:
0117b484 g .bss __bss_end
Somehow the __bss_end here is 255 bytes ahead.
2. do_elf_reloc_fixups():
uintptr_t size = (uintptr_t)__bss_end - (uintptr_t)__text_start;
Here the __text_start is 0 in the file:
d9f: bb a0 e0 13 01 mov$0x113e0a0,%ebx
da4:81 ef 00 00 00 00 sub$0x0,%edi
As it happens, both of these are in pre-relocation code.
For these reasons we silent check and ignore bad relocations.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/x86/lib/relocate.c | 20 ++--
1 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/x86/lib/relocate.c b/arch/x86/lib/relocate.c
index e9188a7..e893c2b 100644
--- a/arch/x86/lib/relocate.c
+++ b/arch/x86/lib/relocate.c
@@ -73,12 +73,16 @@ int clear_bss(void)
return 0;
}
+/*
+ * This function has more error checking than you might expect. Please see
+ * the commit message for more informaiton.
+ */
int do_elf_reloc_fixups(void)
{
Elf32_Rel *re_src = (Elf32_Rel *)(__rel_dyn_start);
Elf32_Rel *re_end = (Elf32_Rel *)(__rel_dyn_end);
- Elf32_Addr *offset_ptr_rom;
+ Elf32_Addr *offset_ptr_rom, *last_offset = NULL;
Elf32_Addr *offset_ptr_ram;
/* The size of the region of u-boot that runs out of RAM. */
@@ -89,7 +93,8 @@ int do_elf_reloc_fixups(void)
offset_ptr_rom = (Elf32_Addr *)re_src-r_offset;
/* Check that the location of the relocation is in .text */
- if (offset_ptr_rom = (Elf32_Addr *)CONFIG_SYS_TEXT_BASE) {
+ if (offset_ptr_rom = (Elf32_Addr *)CONFIG_SYS_TEXT_BASE
+ offset_ptr_rom last_offset) {
/* Switch to the in-RAM version */
offset_ptr_ram = (Elf32_Addr *)((ulong)offset_ptr_rom +
@@ -100,8 +105,19 @@ int do_elf_reloc_fixups(void)
*offset_ptr_ram =
(CONFIG_SYS_TEXT_BASE + size)) {
*offset_ptr_ram += gd-reloc_off;
+ } else {
+ debug( %p: rom reloc %x, ram %p, value %x,
+limit %lx\n, re_src,
+ re_src-r_offset, offset_ptr_ram,
+ *offset_ptr_ram,
+ CONFIG_SYS_TEXT_BASE + size);
}
+ } else {
+ debug( %p: rom reloc %x, last %p\n, re_src,
+ re_src-r_offset, last_offset);
}
+ last_offset = offset_ptr_rom;
+
} while (++re_src re_end);
return 0;
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 05/10] x86: Rearrange the output input to remove BSS
At present BSS data is including in the image, which wastes binary space.
Remove it by rearranging the sections so that BSS is last.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/x86/cpu/u-boot.lds | 19 ---
1 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/arch/x86/cpu/u-boot.lds b/arch/x86/cpu/u-boot.lds
index 2a7d0fd..e455fb9 100644
--- a/arch/x86/cpu/u-boot.lds
+++ b/arch/x86/cpu/u-boot.lds
@@ -46,9 +46,6 @@ SECTIONS
.data : { *(.data*) }
. = ALIGN(4);
- .dynsym : { *(.dynsym*) }
-
- . = ALIGN(4);
.hash : { *(.hash*) }
. = ALIGN(4);
@@ -58,10 +55,7 @@ SECTIONS
__data_end = .;
. = ALIGN(4);
- __bss_start = ABSOLUTE(.);
- .bss (NOLOAD) : { *(.bss) }
- . = ALIGN(4);
- __bss_end = ABSOLUTE(.);
+ .dynsym : { *(.dynsym*) }
. = ALIGN(4);
__rel_dyn_start = .;
@@ -70,6 +64,17 @@ SECTIONS
. = ALIGN(4);
__end = .;
+ . = ALIGN(4);
+
+ __end = .;
+ .bss __rel_dyn_start (OVERLAY) : {
+ __bss_start = .;
+ *(.bss)
+ *(COM*)
+ . = ALIGN(4);
+ __bss_end = .;
+ }
+
/DISCARD/ : { *(.dynstr*) }
/DISCARD/ : { *(.dynamic*) }
/DISCARD/ : { *(.plt*) }
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 10/10] x86: Remove real mode code for coreboot
We don't need this code with coreboot. Signed-off-by: Simon Glass s...@chromium.org --- include/configs/coreboot.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/configs/coreboot.h b/include/configs/coreboot.h index 5f736f2..fd383ff 100644 --- a/include/configs/coreboot.h +++ b/include/configs/coreboot.h @@ -38,6 +38,7 @@ #define CONFIG_SHOW_BOOT_PROGRESS #define CONFIG_LAST_STAGE_INIT #define CONFIG_X86_NO_RESET_VECTOR +#define CONFIG_X86_NO_REAL_MODE #define CONFIG_SYS_VSNPRINTF #define CONFIG_INTEL_CORE_ARCH /* Sandy bridge and ivy bridge chipsets. */ #define CONFIG_ZBOOT_32 -- 1.7.7.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 08/10] x86: Adjust link device tree include file
This is currently set to coreboot.dtsi, but we cannot support this on
old device tree compilers (dtc = 1.3), so adjust to use ARCH_CPU_DTS
to let the Makefile preprocessor sort this out.
Signed-off-by: Simon Glass s...@chromium.org
---
board/chromebook-x86/dts/link.dts |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/board/chromebook-x86/dts/link.dts
b/board/chromebook-x86/dts/link.dts
index af60f59..ae8217d 100644
--- a/board/chromebook-x86/dts/link.dts
+++ b/board/chromebook-x86/dts/link.dts
@@ -1,6 +1,6 @@
/dts-v1/;
-/include/ coreboot.dtsi
+/include/ ARCH_CPU_DTS
/ {
#address-cells = 1;
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 09/10] x86: Enable CONFIG_OF_CONTROL on coreboot
Make use of a device tree on coreboot boards, and set the default to link. Signed-off-by: Simon Glass s...@chromium.org --- include/configs/coreboot.h |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/include/configs/coreboot.h b/include/configs/coreboot.h index adeace0..5f736f2 100644 --- a/include/configs/coreboot.h +++ b/include/configs/coreboot.h @@ -43,6 +43,12 @@ #define CONFIG_ZBOOT_32 #define CONFIG_PHYSMEM +#define CONFIG_LMB +#define CONFIG_OF_LIBFDT +#define CONFIG_OF_CONTROL +#define CONFIG_OF_SEPARATE +#define CONFIG_DEFAULT_DEVICE_TREE link + /*--- * Watchdog Configuration */ -- 1.7.7.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ns16550: allow UART address to be set dynamically
On 12/14/2012 01:40 PM, Tom Rini wrote:
On 12/13/12 16:51, Simon Glass wrote:
[snip]
And from there we can move on and say On ${SoC} we get a
device tree (that we can't quite parse as we don't have
enough resources) AND $some-data (OMDATA or an abbreviated
device tree or $whatever), lets translate that into something
we can make use of very early rather than a hard-coded
initial console location
It seems like you're saying that once we have dynamic serial
port assignment working based on DT, you'll be fine using
ODMDATA to initialize the early console, but not before then?
If so, I'm having a hard time understanding why enabling the
DT-based support blocks using ODMDATA, since the code would be
pretty orthogonal.
Yes well dynamic console selection sounds find to me, ODMDATA or
otherwise. To me it is a Tegra feature that should be supported
as such. Perhaps we can allow the FDT console alias to specify
odmdata to mean that, and/or (as you suggest I think) set the
console to USE_ODMDATA, which then selects
CONFIG_SYS_NS16550_COMx accordingly.
There's two parts to it. One part is that sure, Tegra and only
Tegra has ODMDATA. But on am33xx if we poke the i2c eeprom (on
platforms that do the eeprom) we can then know ... And I bet other
SoCs have other tricks for this or that. So it's not just tegra
that can tell us the initial console is $here or $there if we just
...something.
That's certainly true.
I personally view the method of retrieving this kind of information as
part of an SoC's boot architecture, or as part of a board's design. As
you have mentioned above, different SoCs/boards already have
mechanisms to represent/determine this information. These mechanisms
are already in-place and defined by the SoC or board designers.
The other part is, take a look at the Allwinner thread from a week
or so ago. We really need to define how we want early board
specific data to come in because if we start saying we'll accept
per-SoC solutions we'll be drowning in them in short time. We want
to say here's our preferred way to pass this information in.
I don't understand why you think U-Boot is in a position to mandate
that the existing solutions that are already in place are incorrect,
and must be replaced with some alternative.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [STATUS] v2013.01-rc2 released
Hey all, I've tagged and pushed v2013.01-rc2 now. The next branch has been open for a little bit, and is still open now, and in sync. Here's where we're at: - I expect a USB pull request from Marek soon. - I've locally build-tested Simon's gd-arch series and will run-time test it on a few platforms I have soon now. - I know Albert is around and working on a u-boot-arm pull request. In my TODO list in patchwork, nothing strikes me as new feature posted before the merge window closed. I see a few bug fixes I might pull in, or might sit on to make sure they don't cause surprises. It's of course possible I missed something, or something is assigned to someone else so if this strikes anyone as wrong, please speak up now. Also, if you have any bugfixes you expect me to pull, please get them out sooner rather than later. The release is still planned for Jan 15, a month away, but there's holidays in there which mean both some folks are not working and other folks have some free time for hobby projects. Thanks all! -- 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] ns16550: allow UART address to be set dynamically
On 12/14/2012 02:14 PM, Simon Glass wrote:
Hi Tom,
On Fri, Dec 14, 2012 at 12:40 PM, Tom Rini tr...@ti.com wrote: On
12/13/12 16:51, Simon Glass wrote:
[snip]
And from there we can move on and say On ${SoC} we get
a device tree (that we can't quite parse as we don't have
enough resources) AND $some-data (OMDATA or an
abbreviated device tree or $whatever), lets translate
that into something we can make use of very early rather
than a hard-coded initial console location
It seems like you're saying that once we have dynamic
serial port assignment working based on DT, you'll be fine
using ODMDATA to initialize the early console, but not
before then? If so, I'm having a hard time understanding
why enabling the DT-based support blocks using ODMDATA,
since the code would be pretty orthogonal.
Yes well dynamic console selection sounds find to me, ODMDATA
or otherwise. To me it is a Tegra feature that should be
supported as such. Perhaps we can allow the FDT console alias
to specify odmdata to mean that, and/or (as you suggest I
think) set the console to USE_ODMDATA, which then selects
CONFIG_SYS_NS16550_COMx accordingly.
There's two parts to it. One part is that sure, Tegra and only
Tegra has ODMDATA. But on am33xx if we poke the i2c eeprom (on
platforms that do the eeprom) we can then know ... And I bet other
SoCs have other tricks for this or that. So it's not just tegra
that can tell us the initial console is $here or $there if we just
...something.
The other part is, take a look at the Allwinner thread from a week
or so ago. We really need to define how we want early board
specific data to come in because if we start saying we'll accept
per-SoC solutions we'll be drowning in them in short time. We want
to say here's our preferred way to pass this information in.
Yes there is a general problem to be solved here. Assuming that
the problem is solved in U-Boot itself with device tree, then:
1. It would be nice to keep a single source for this information
so that SPL and U-Boot are consistent. Where we invent a new
mechanism for efficiency reasons it would be best if there was a
1-1 mapping from device tree to this new mechanism.
Many (most, I assume) U-Boot builds don't use device tree at all
(yet?). I'm not sure we should tie any new mechanism for low-level
boot information into device tree, since that severely limits where it
can be used.
2. It would be nice if we could write a simple tool which is
generic across architectures and configures an SPL given a device
tree file. I'm not sure if that is a problem worth solving or
not.
I'm not sure the information is generic enough to even represent in
device tree, or that it even makes sense to do so.
After all, what the Tegra ODMDATA2 fields are representing is pinmux
setup. Every piece of hardware does pinmux differently; at the very
least, the pin IDs and available mux selection options are different.
Some SoCs mux pins individually, some in groups. Sometimes more than
just mux options must be selected. Some SoCs don't need pinmux. Some
SoCs would allow the data to be embedded into some boot flash in a
SoC-defined manner, whereas other SoCs' boards might require reading
GPIOs, I2C EEPROMs, ... to get the information, etc. All this means
that the information required, and the format needed to represent it,
really is different in every case. The only way to avoid this would be
to retro-actively redesign every SoC and board to always have the same
requirements for what data needs to represent the UART selection
process, and implement in the same way. That's obviously impossible to
do, and so having any kind of remotely generic tool to handle the
representation of this data also seems quite impossible.
3. From the SPL point of view, the less code required to get at
the information, the better.
For one possible solution, see:
arch/arm/include/asm/arch-exynos/spl.h
A certain amount of that information duplicates what's in the Tegra
BCT, which is essentially part of the HW itself, since it's handled by
the non-modifiable boot ROM code. I really don't think U-Boot should
be mandating some data structure that requires duplication of
information that's already present.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: nand flash
The following changes since commit 6e9005bd96ff0f0548a787ffafee10664a57a8e1: omap3_evm: Let CONFIG_EFI_PARTITION be set for SPL (2012-12-13 13:58:27 -0700) are available in the git repository at: git://git.denx.de/u-boot-nand-flash.git master for you to fetch changes up to 71779d5b873186941652188a30bf703c951b1616: m28evk/mx28evk: fix nand_update_full (2012-12-14 16:04:06 -0600) Eric Benard (1): m28evk/mx28evk: fix nand_update_full Scott Wood (1): Merge remote-tracking branch 'origin/master' Wolfram Sang (1): mtd: nand: mxs: reset BCH earlier, too, to avoid NAND startup problems drivers/mtd/nand/mxs_nand.c |3 +++ include/configs/m28evk.h|2 +- include/configs/mx28evk.h |2 +- 3 files changed, 5 insertions(+), 2 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/10] x86: Permit bootstage and timer data to be used prior to relocation
Hi Simon,
On 15/12/12 08:13, Simon Glass wrote:
It is useful to be able to access the timer before U-Boot has relocated
so that we can fully support bootstage.
Move the relevant variables to the data region to support this.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/x86/cpu/coreboot/coreboot.c |4 ++--
arch/x86/cpu/interrupts.c|2 +-
arch/x86/lib/timer.c |2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/cpu/coreboot/coreboot.c
b/arch/x86/cpu/coreboot/coreboot.c
index 9c9431e..22474f5 100644
--- a/arch/x86/cpu/coreboot/coreboot.c
+++ b/arch/x86/cpu/coreboot/coreboot.c
@@ -68,8 +68,8 @@ int board_early_init_r(void)
void show_boot_progress(int val)
{
#if MIN_PORT80_KCLOCKS_DELAY
- static uint32_t prev_stamp;
- static uint32_t base;
+ static uint32_t prev_stamp __attribute__((section(.data)));
+ static uint32_t base __attribute__((section(.data)));
NAK
This may work for coreboot where SDRAM is already initialised and you've
loaded U-Boot into RAM, but it will not work when U-Boot is in Flash as all
sections (including .data) are read-only until after relocation.
The stack and Global Data are the only guaranteed read/write locations
prior to relocation
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH resend] armv7/ltimer: Add support for local timer on armv7 cpus
Dear Vipin Kumar, In message 50caf0cb.1050...@st.com you wrote: ping again pong ;-) On 12/6/2012 2:52 PM, Vipin KUMAR wrote: Certain ARMV7 cpus eg. CortexA9 contains a local and a global timer within the CPU core itself. This patch adds generic support for local timer. What would be the use of such timer support? Is there any code that actually needs it, and why does it need anything beyond the existing timer support we have? 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 is a time in the tides of men, Which, taken at its flood, leads on to success. On the other hand, don't count on it. - T. K. Lawson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ns16550: allow UART address to be set dynamically
Hi Stephen,
On Fri, Dec 14, 2012 at 2:03 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 12/14/2012 02:14 PM, Simon Glass wrote:
Hi Tom,
On Fri, Dec 14, 2012 at 12:40 PM, Tom Rini tr...@ti.com wrote: On
12/13/12 16:51, Simon Glass wrote:
[snip]
And from there we can move on and say On ${SoC} we get
a device tree (that we can't quite parse as we don't have
enough resources) AND $some-data (OMDATA or an
abbreviated device tree or $whatever), lets translate
that into something we can make use of very early rather
than a hard-coded initial console location
It seems like you're saying that once we have dynamic
serial port assignment working based on DT, you'll be fine
using ODMDATA to initialize the early console, but not
before then? If so, I'm having a hard time understanding
why enabling the DT-based support blocks using ODMDATA,
since the code would be pretty orthogonal.
Yes well dynamic console selection sounds find to me, ODMDATA
or otherwise. To me it is a Tegra feature that should be
supported as such. Perhaps we can allow the FDT console alias
to specify odmdata to mean that, and/or (as you suggest I
think) set the console to USE_ODMDATA, which then selects
CONFIG_SYS_NS16550_COMx accordingly.
There's two parts to it. One part is that sure, Tegra and only
Tegra has ODMDATA. But on am33xx if we poke the i2c eeprom (on
platforms that do the eeprom) we can then know ... And I bet other
SoCs have other tricks for this or that. So it's not just tegra
that can tell us the initial console is $here or $there if we just
...something.
The other part is, take a look at the Allwinner thread from a week
or so ago. We really need to define how we want early board
specific data to come in because if we start saying we'll accept
per-SoC solutions we'll be drowning in them in short time. We want
to say here's our preferred way to pass this information in.
Yes there is a general problem to be solved here. Assuming that
the problem is solved in U-Boot itself with device tree, then:
1. It would be nice to keep a single source for this information
so that SPL and U-Boot are consistent. Where we invent a new
mechanism for efficiency reasons it would be best if there was a
1-1 mapping from device tree to this new mechanism.
Many (most, I assume) U-Boot builds don't use device tree at all
(yet?). I'm not sure we should tie any new mechanism for low-level
boot information into device tree, since that severely limits where it
can be used.
Perhaps I can make the point another way. Assuming that the SOC in
question is ARM-based and has Linux support it either supports FDT now
or presumably will fairly soon. We found that some of the things we
want to know about at the low level are hardware properties that are
already sit in a node in the FDT. For example the memory controller
may have information about the memory type attached to it.
Given this, my suggestion is that this hardware information be kept in
one place (FDT) where possible, even if it unfortunately temporarily
needs to be translated into some simpler format as part of the SPL
build for efficiency reasons.
As to platforms that support FDT, that is true, only a few. Adding
basic support for a new board is very easy though.
But looking at your comments below, I worry that this might be a
sledgehammer to crack a nut. As I understand it, you really just have
a 32-word which selects the console UART and a few other things. It
seems like you solved that problem a few emails back.
2. It would be nice if we could write a simple tool which is
generic across architectures and configures an SPL given a device
tree file. I'm not sure if that is a problem worth solving or
not.
I'm not sure the information is generic enough to even represent in
device tree, or that it even makes sense to do so.
After all, what the Tegra ODMDATA2 fields are representing is pinmux
setup. Every piece of hardware does pinmux differently; at the very
least, the pin IDs and available mux selection options are different.
Some SoCs mux pins individually, some in groups. Sometimes more than
just mux options must be selected. Some SoCs don't need pinmux. Some
SoCs would allow the data to be embedded into some boot flash in a
SoC-defined manner, whereas other SoCs' boards might require reading
GPIOs, I2C EEPROMs, ... to get the information, etc. All this means
that the information required, and the format needed to represent it,
really is different in every case. The only way to avoid this would be
to retro-actively redesign every SoC and board to always have the same
requirements for what data needs to represent the UART selection
process, and implement in the same way. That's obviously impossible to
do, and so having any kind of remotely generic tool to handle the
representation of this data also seems quite impossible.
3. From the SPL point of view, the less code required to get at
the information, the better.
Re: [U-Boot] [PATCH] ns16550: allow UART address to be set dynamically
Dear Tom Rini, In message 50cb8ed1.7020...@ti.com you wrote: The other part is, take a look at the Allwinner thread from a week or so ago. We really need to define how we want early board specific data to come in because if we start saying we'll accept per-SoC solutions we'll be drowning in them in short time. We want to say here's our preferred way to pass this information in. ACK! And we already have a well-defined way to do this, which is the device tree. So any attempts to implement something different should be reviewed very carefully. 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 KLB is an acronym for `Known Lazy Bastard', aka non-FAQ reader, aka person who would rather make someone take their time to explain something basic than look it up in a FAQ. -- Tom Christiansen in 6aq547$mnr$2...@csnews.cs.colorado.edu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ns16550: allow UART address to be set dynamically
Dear Stephen Warren, In message 50cb9f9f.5010...@wwwdotorg.org you wrote: I don't understand why you think U-Boot is in a position to mandate that the existing solutions that are already in place are incorrect, and must be replaced with some alternative. There will always be times when common agreement on a new, superior solution will enforce adaption of the existing implementations, or they will break and drop out of mainline. I don't claim this is such a case, but it could well be so. 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 Of all the things I've lost, I miss my mind the most. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 12/58] x86: Move gd_addr into arch_global_data
Hi Simon,
On 14/12/12 17:48, Simon Glass wrote:
Move this field into arch_global_data and tidy up.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2: None
arch/x86/include/asm/global_data.h |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/global_data.h
b/arch/x86/include/asm/global_data.h
index 9a4f141..eded279 100644
--- a/arch/x86/include/asm/global_data.h
+++ b/arch/x86/include/asm/global_data.h
@@ -28,6 +28,7 @@
/* Architecture-specific global data */
struct arch_global_data {
+ struct global_data *gd_addr;/* Location of Global Data */
};
/*
@@ -44,8 +45,6 @@ typedef struct global_data gd_t;
struct global_data {
struct arch_global_data arch; /* architecture-specific data */
- /* NOTE: gd_addr MUST be first member of struct global_data! */
- gd_t *gd_addr; /* Location of Global Data */
bd_t*bd;
unsigned long flags;
unsigned intbaudrate;
NAK - You've broken bisectability - patch 13 (slightly modified) needs to
come first
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ns16550: allow UART address to be set dynamically
Dear Stephen Warren, In message 50cba217.3070...@wwwdotorg.org you wrote: Many (most, I assume) U-Boot builds don't use device tree at all (yet?). I'm not sure we should tie any new mechanism for low-level boot information into device tree, since that severely limits where it can be used. We're talking about ways to pass hardware cosnfiguration information to the boot loader. From the software engineering point of view, there should be just one implementation for this feature, which is then used everywhere. The de-factor satndard for this functionaity is the device tree. Which means that any other approaches either need very strong reasons to exist, or should be adapted. I'm not sure the information is generic enough to even represent in device tree, or that it even makes sense to do so. The DT is as good a place for such information as any other. A certain amount of that information duplicates what's in the Tegra BCT, which is essentially part of the HW itself, since it's handled by There is more SoCs around than just Tegra, and a solution that fits all is definitely better than everybody implementing hos own private thingy. 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 Voodoo Programming: Things programmers do that they know shouldn't work but they try anyway, and which sometimes actually work, such as recompiling everything. - Karl Lehenbauer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/10] x86: Permit bootstage and timer data to be used prior to relocation
Hi Graeme,
On Fri, Dec 14, 2012 at 2:15 PM, Graeme Russ graeme.r...@gmail.com wrote:
Hi Simon,
On 15/12/12 08:13, Simon Glass wrote:
It is useful to be able to access the timer before U-Boot has relocated
so that we can fully support bootstage.
Move the relevant variables to the data region to support this.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/x86/cpu/coreboot/coreboot.c |4 ++--
arch/x86/cpu/interrupts.c|2 +-
arch/x86/lib/timer.c |2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/cpu/coreboot/coreboot.c
b/arch/x86/cpu/coreboot/coreboot.c
index 9c9431e..22474f5 100644
--- a/arch/x86/cpu/coreboot/coreboot.c
+++ b/arch/x86/cpu/coreboot/coreboot.c
@@ -68,8 +68,8 @@ int board_early_init_r(void)
void show_boot_progress(int val)
{
#if MIN_PORT80_KCLOCKS_DELAY
- static uint32_t prev_stamp;
- static uint32_t base;
+ static uint32_t prev_stamp __attribute__((section(.data)));
+ static uint32_t base __attribute__((section(.data)));
NAK
This may work for coreboot where SDRAM is already initialised and you've
loaded U-Boot into RAM, but it will not work when U-Boot is in Flash as all
sections (including .data) are read-only until after relocation.
The stack and Global Data are the only guaranteed read/write locations
prior to relocation
Ah yes, I was thinking of your comment that all boards would move to
use coreboot. If that is not the case, then I will need to add
something to global data for the timer. And I don't want to do that
while generic board is in progress since it creates conflicts.
Regards,
Simon
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 13/58] x86: Set up the global data pointer in C instead of asm
Hi Simon, On 14/12/12 17:48, Simon Glass wrote: We currently assume that the global data pointer is at the start of struct global_data. We want to remove this restriction, and it is easiest to do this in C. Remove the asm code and add equivalent code in C. This idea was proposed by Graeme Russ here: http://patchwork.ozlabs.org/patch/199741/ Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: - Add new patch to move gd pointer by C to asm on x86 arch/x86/cpu/cpu.c |4 +++- arch/x86/cpu/start.S |6 -- 2 files changed, 3 insertions(+), 7 deletions(-) diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c index 315e87a..6a23974 100644 --- a/arch/x86/cpu/cpu.c +++ b/arch/x86/cpu/cpu.c @@ -100,7 +100,9 @@ void setup_gdt(gd_t *id, u64 *gdt_addr) gdt_addr[X86_GDT_ENTRY_32BIT_DS] = GDT_ENTRY(0xc093, 0, 0xf); /* FS: data, read/write, 4 GB, base (Global Data Pointer) */ - gdt_addr[X86_GDT_ENTRY_32BIT_FS] = GDT_ENTRY(0xc093, (ulong)id, 0xf); + id-arch.gd_addr = id; + gdt_addr[X86_GDT_ENTRY_32BIT_FS] = GDT_ENTRY(0xc093, + (ulong)id-arch.gd_addr, 0xf); This patch needs to come before #12 as: - gdt_addr[X86_GDT_ENTRY_32BIT_FS] = GDT_ENTRY(0xc093, (ulong)id, 0xf); + id-gd_addr = id; + gdt_addr[X86_GDT_ENTRY_32BIT_FS] = GDT_ENTRY(0xc093, +(ulong)id-gd_addr, 0xf); Then you can move gd_addr into arch-specific global data Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 3/4] video: Modify exynos_fimd driver to support LCD console
Hi Ajay,
On Thu, Dec 13, 2012 at 3:29 AM, Ajay Kumar ajaykumar...@samsung.com wrote:
Currently, exynos FIMD driver is being used to support only TIZEN LOGOs.
In order to get LCD console, we need to enable half word swap feature
of FIMD and use 16 BPP.
LCD console and proprietary Logo cannot be used simultaneously.
You should define CONFIG_CMD_BMP for proprietary Logo, and if
CONFIG_CMD_BMP is not defined you get output console on LCD.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
drivers/video/exynos_fb.c |5 -
drivers/video/exynos_fimd.c | 10 --
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/video/exynos_fb.c b/drivers/video/exynos_fb.c
index 39d3b74..cb19192 100644
--- a/drivers/video/exynos_fb.c
+++ b/drivers/video/exynos_fb.c
@@ -65,6 +65,7 @@ static void exynos_lcd_init(vidinfo_t *vid)
exynos_fimd_lcd_init(vid);
}
+#ifdef CONFIG_CMD_BMP
static void draw_logo(void)
{
int x, y;
@@ -87,6 +88,7 @@ static void draw_logo(void)
addr = panel_info.logo_addr;
bmp_display(addr, x, y);
}
+#endif
static void lcd_panel_on(vidinfo_t *vid)
{
@@ -146,12 +148,13 @@ void lcd_ctrl_init(void *lcdbase)
void lcd_enable(void)
{
+#ifdef CONFIG_CMD_BMP
if (panel_info.logo_on) {
memset(lcd_base, 0, panel_width * panel_height *
(NBITS(panel_info.vl_bpix) 3));
draw_logo();
}
-
+#endif
lcd_panel_on(panel_info);
}
diff --git a/drivers/video/exynos_fimd.c b/drivers/video/exynos_fimd.c
index 06eae2e..0776b6d 100644
--- a/drivers/video/exynos_fimd.c
+++ b/drivers/video/exynos_fimd.c
@@ -88,14 +88,20 @@ static void exynos_fimd_set_par(unsigned int win_id)
/* DATAPATH is DMA */
cfg |= EXYNOS_WINCON_DATAPATH_DMA;
- /* bpp is 32 */
+#ifdef CONFIG_CMD_BMP /* To get proprietary LOGO */
cfg |= EXYNOS_WINCON_WSWP_ENABLE;
+#else /* To get output console on LCD */
+ cfg |= EXYNOS_WINCON_HAWSWP_ENABLE;
+#endif
It seems like you should use CONFIG_LCD_LOGO instead of
CONFIG_CMD_BMP, since people might want that command for other
reasons. Or do want a specific CONFIG for this feature?
/* dma burst is 16 */
cfg |= EXYNOS_WINCON_BURSTLEN_16WORD;
- /* pixel format is unpacked RGB888 */
+#ifdef CONFIG_CMD_BMP /* To get proprietary LOGO */
cfg |= EXYNOS_WINCON_BPPMODE_24BPP_888;
+#else /* To get output console on LCD */
+ cfg |= EXYNOS_WINCON_BPPMODE_16BPP_565;
+#endif
writel(cfg, (unsigned int)fimd_ctrl-wincon0 +
EXYNOS_WINCON(win_id));
--
1.7.1
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 12/58] x86: Move gd_addr into arch_global_data
Hi Graeme,
On Fri, Dec 14, 2012 at 2:32 PM, Graeme Russ graeme.r...@gmail.com wrote:
Hi Simon,
On 14/12/12 17:48, Simon Glass wrote:
Move this field into arch_global_data and tidy up.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2: None
arch/x86/include/asm/global_data.h |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/global_data.h
b/arch/x86/include/asm/global_data.h
index 9a4f141..eded279 100644
--- a/arch/x86/include/asm/global_data.h
+++ b/arch/x86/include/asm/global_data.h
@@ -28,6 +28,7 @@
/* Architecture-specific global data */
struct arch_global_data {
+ struct global_data *gd_addr;/* Location of Global Data */
};
/*
@@ -44,8 +45,6 @@ typedef struct global_data gd_t;
struct global_data {
struct arch_global_data arch; /* architecture-specific data */
- /* NOTE: gd_addr MUST be first member of struct global_data! */
- gd_t *gd_addr; /* Location of Global Data */
bd_t*bd;
unsigned long flags;
unsigned intbaudrate;
NAK - You've broken bisectability - patch 13 (slightly modified) needs to
come first
I build tested each commit, but did not run-test each unfortunately.
Yes I agree it would be annoying to break this even within a series,
unless it is unavoidable. I will retest, assuming the basic concept
passes muster.
Regards,
Simon
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ns16550: allow UART address to be set dynamically
On 12/14/2012 03:22 PM, Simon Glass wrote: Hi Stephen, ... Perhaps I can make the point another way. Assuming that the SOC in question is ARM-based and has Linux support it either supports FDT now or presumably will fairly soon. Sure, but I'm *explicitly* avoiding relying on DT for this, because there are plenty of things that happen before DT can or should be touched that might warrant serial port output. The kernel has exactly the same kind of feature; log messages can be sent out through an SoC-specific earlyprintk mechanism. In the U-Boot case though, I don't plan on replacing the serial port based on information from DT, but simply setting it up much much earlier via a simpler mechanism. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 19/20] x86: coreboot: Enable io command
Enable the io command for x86 on coreboot. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v3: None Changes in v2: - Add x86 patch to enable io command for coreboot include/configs/coreboot.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/configs/coreboot.h b/include/configs/coreboot.h index a010adc..50f6964 100644 --- a/include/configs/coreboot.h +++ b/include/configs/coreboot.h @@ -152,6 +152,7 @@ #define CONFIG_CMD_FPGA #define CONFIG_CMD_IMI #undef CONFIG_CMD_IMLS +#define CONFIG_CMD_IO #define CONFIG_CMD_IRQ #define CONFIG_CMD_ITEST #define CONFIG_CMD_LOADB -- 1.7.7.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 20/20] x86: Add coreboot version to u-boot's version command
From: Stefan Reinauer reina...@chromium.org Since U-Boot runs from coreboot on x86, the Coreboot version is an important part of the boot state. This version information is available in the coreboot tables, so print it when the 'version' command is used. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v3: None Changes in v2: - Add x86 tag to version command patch common/cmd_version.c |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/common/cmd_version.c b/common/cmd_version.c index ab4c560..e8f40d3 100644 --- a/common/cmd_version.c +++ b/common/cmd_version.c @@ -25,6 +25,9 @@ #include command.h #include version.h #include linux/compiler.h +#ifdef CONFIG_SYS_COREBOOT +#include asm/arch/sysinfo.h +#endif const char __weak version_string[] = U_BOOT_VERSION_STRING; @@ -37,7 +40,9 @@ static int do_version(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) #ifdef LD_VERSION_STRING puts(LD_VERSION_STRING \n); #endif - +#ifdef CONFIG_SYS_COREBOOT + printf(coreboot-%s (%s)\n, lib_sysinfo.version, lib_sysinfo.build); +#endif return 0; } -- 1.7.7.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ns16550: allow UART address to be set dynamically
Hi Wolfgang, On 15/12/12 09:26, Wolfgang Denk wrote: Dear Tom Rini, In message 50cb8ed1.7020...@ti.com you wrote: The other part is, take a look at the Allwinner thread from a week or so ago. We really need to define how we want early board specific data to come in because if we start saying we'll accept per-SoC solutions we'll be drowning in them in short time. We want to say here's our preferred way to pass this information in. ACK! And we already have a well-defined way to do this, which is the device tree. So any attempts to implement something different should be reviewed very carefully. I'm not sure I 100% get this, but from what I understand, the SoC (or maybe even some EEPROM on a particular board family) may contain device enumeration data in some vendor specific format (i.e. not in a device tree compatible format). The way I see it, there is no way that U-Boot can dictate to SoC and board vendors and say that data must be stored in DT format. So shouldn't U-Boot instead implement a board/SoC specific translation layer which converts this custom data into DT format (maybe in SPL if possible)? But the other problem is if this data includes console specific information (UART configuration). We are left blind until the DT functions become available. So maybe we need some small standard interface to allow the console to be configured early. But we need to prevent this from being abused (i.e. being used to do all kinds of hardware setting from the raw data and bypassing DT) Am I understanding this right? Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] x86: Add mention of the new io command in README
Add a short description for this command. Signed-off-by: Simon Glass s...@chromium.org --- README |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/README b/README index b5c1c03..6bf678a 100644 --- a/README +++ b/README @@ -838,6 +838,7 @@ The following options need to be configured: CONFIG_CMD_IMMAP* IMMR dump support CONFIG_CMD_IMPORTENV* import an environment CONFIG_CMD_INI * import data from an ini file into the env + CONFIG_CMD_IO * x86 IO access CONFIG_CMD_IRQ * irqinfo CONFIG_CMD_ITEST Integer/string test of 2 values CONFIG_CMD_JFFS2* JFFS2 Support -- 1.7.7.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Atheros ART data crc calculation
Hello again Allan, Can you on work device (with correct ART section and with no checksum error), enter the u-boot command - printenv ? Also would you please share your ART section of the same device? Idea is this, it is necessary to calculate the checksum of ART section (only not clearly what part of the calculate, with empty sectors FF or workspace) in CRC32 format, then correct this checksum in buf_crc environment variable. https://forum.openwrt.org/viewtopic.php?pid=153580#p153580 Best regards, Dmytro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ns16550: allow UART address to be set dynamically
Dear Graeme Russ, In message 50cbb346.30...@gmail.com you wrote: And we already have a well-defined way to do this, which is the device tree. So any attempts to implement something different should be reviewed very carefully. I'm not sure I 100% get this, but from what I understand, the SoC (or maybe even some EEPROM on a particular board family) may contain device enumeration data in some vendor specific format (i.e. not in a device tree compatible format). Yes, this may, and will, happen. And we will have to support it. The question is, how to do that. I definitely do not want to see any uncontrolled growth of more and more such board or SoC specific code. The way I see it, there is no way that U-Boot can dictate to SoC and board vendors and say that data must be stored in DT format. So shouldn't U-Boot We cannot dictate, but we can encourage and discourage such decisions. If we communicate a clear position, we may even prevent ugly things from happening. instead implement a board/SoC specific translation layer which converts this custom data into DT format (maybe in SPL if possible)? Do you want to see each board grow it's own code to do that? Because this is the extreme that could result from such a decision, and I seriously dislike any such thought. Which is why I'm questioning the general approach when I see it first. But the other problem is if this data includes console specific information (UART configuration). We are left blind until the DT functions become available. So maybe we need some small standard interface to allow the console to be configured early. But we need to prevent this from being abused (i.e. being used to do all kinds of hardware setting from the raw data and bypassing DT) Why do we have to support such dynamic hardware configuration for a very basic thing as the console port at all? If the hardware designers cannot fix their minds and use a fixed console port, they should be willing to suffer fromthe penalty that they will have to use board specific board configurations that match the actual consoles settings. Why should we bend and do ugly stuff? Just because software is so much easier to change than hardware? I'm not going to buy this argument. 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 All this doesn't alter anything, you know. The world is still full of stupid people. They don't use their brains. They don't seem to want to think straight.- Terry Pratchett, _Soul Music_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] env: don't generate callback list entries for SPL
SPL doesn't use the environment. These list entries prevent the
functions from being garbage-collected, even though nothing will look at
the list. This caused several SPL builds (e.g. P2020RDB-PC_NAND) to
break due to size limitations.
A static inline function is used to provide a context in which we
can consume the callback, and thus avoid unused function warnings.
Signed-off-by: Scott Wood scottw...@freescale.com
---
include/env_callback.h |8
1 file changed, 8 insertions(+)
diff --git a/include/env_callback.h b/include/env_callback.h
index 47fdc6f..c583120 100644
--- a/include/env_callback.h
+++ b/include/env_callback.h
@@ -68,8 +68,16 @@ void env_callback_init(ENTRY *var_entry);
* when associated through the .callbacks environment variable, the callback
* will be executed any time the variable is inserted, overwritten, or deleted.
*/
+#ifdef CONFIG_SPL_BUILD
+#define U_BOOT_ENV_CALLBACK(name, callback) \
+ static inline void _u_boot_env_noop_##name(void) \
+ { \
+ (void)callback; \
+ }
+#else
#define U_BOOT_ENV_CALLBACK(name, callback) \
ll_entry_declare(struct env_clbk_tbl, name, env_clbk, env_clbk) = \
{#name, callback}
+#endif
#endif /* __ENV_CALLBACK_H__ */
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ns16550: allow UART address to be set dynamically
Hi Wolfgang, On 15/12/12 11:32, Wolfgang Denk wrote: Dear Graeme Russ, In message 50cbb346.30...@gmail.com you wrote: And we already have a well-defined way to do this, which is the device tree. So any attempts to implement something different should be reviewed very carefully. I'm not sure I 100% get this, but from what I understand, the SoC (or maybe even some EEPROM on a particular board family) may contain device enumeration data in some vendor specific format (i.e. not in a device tree compatible format). Yes, this may, and will, happen. And we will have to support it. The question is, how to do that. I definitely do not want to see any uncontrolled growth of more and more such board or SoC specific code. The way I see it, there is no way that U-Boot can dictate to SoC and board vendors and say that data must be stored in DT format. So shouldn't U-Boot We cannot dictate, but we can encourage and discourage such decisions. If we communicate a clear position, we may even prevent ugly things from happening. Understood, but in the end, board and SoC vendors will do what is most expedient for them, and that may well be a raw binary data format buried in some reserved ROM area (either on-time-writable or EEPROM) instead implement a board/SoC specific translation layer which converts this custom data into DT format (maybe in SPL if possible)? Do you want to see each board grow it's own code to do that? Because this is the extreme that could result from such a decision, and I seriously dislike any such thought. Which is why I'm questioning the general approach when I see it first. Well if the SoC or board (but more likely SoC) has already defined the data structure, you a bit stuck. I fully agree that board developers that choose U-Boot as their primary bootloader should be following U-Boot conventions. But the other problem is if this data includes console specific information (UART configuration). We are left blind until the DT functions become available. So maybe we need some small standard interface to allow the console to be configured early. But we need to prevent this from being abused (i.e. being used to do all kinds of hardware setting from the raw data and bypassing DT) Why do we have to support such dynamic hardware configuration for a very basic thing as the console port at all? You may not find as much in consumer devices (set-top-boxes, mobile phones, tablets etc.) but you will in industrial devices. I can give you an example - Remote Telemetry Units (RTUs). They usually have a number of serial ports. The number of ports may vary based on the sub-model. Some ports may be RS-232, some may be RS-485 or RS-422. Depending on what additional devices you want to communicate with, you may need to use the 'console/diag' port to connect to a real device. So what you want to do is route console to another port (if available) or even netconsole. If the hardware designers cannot fix their minds and use a fixed console port, they should be willing to suffer fromthe penalty that they will have to use board specific board configurations that match the actual consoles settings. Why should we bend and do ugly stuff? Just because software is so much easier to change than hardware? I'm not going to buy this argument. I do get your point of view. But I think a combination of storing the dynamic console info in a DT format, the pre-console buffer and getting DT available as early as possible can yield a 'non-cludgy' solution. For board or SoC vendors who, for whatever reason, have implemented non-DT storage of hardware enumeration data they will be stuck with the penalty of having to translate that data into DT format before it can be parsed by U-Boot. Maybe this could be done in SPL. Yes, it's a hack, but if it can't be worked around, push it as low as possible and as far away from the U-Boot core as possible Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] UBI Fixable bit-flip issue.
Ccing the Author of [1]. On 12/14/2012 11:33 PM, Vikram Narayanan wrote: Hello, I'm seeing a fixable bit-flip in the current u-boot (v2012.10) on a i.Mx6 Solo based custom board. The problem is similar to the one explained here [1]. As observed by the thread's author, does reverting the commit 1b1f9a9 solves the issue? Did someone face a similar issue? Thanks, Vikram [1] http://lists.denx.de/pipermail/u-boot/2011-September/100237.html [2] http://lists.denx.de/pipermail/u-boot/2011-September/101887.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/4] EXYNOS5: Change parent clock of FIMD to MPLL
Dear Donghwa, On 13/12/12 20:29, Ajay Kumar wrote: With VPLL as source clock to FIMD, Exynos DP Initializaton was failing sometimes with unstable clock. Changing FIMD source to MPLL resolves this issue. Signed-off-by: Ajay Kumar ajaykumar...@samsung.com Acked-by: Simon Glass s...@chromium.org --- arch/arm/cpu/armv7/exynos/clock.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/cpu/armv7/exynos/clock.c b/arch/arm/cpu/armv7/exynos/clock.c index fe61f88..bfcd5f7 100644 --- a/arch/arm/cpu/armv7/exynos/clock.c +++ b/arch/arm/cpu/armv7/exynos/clock.c @@ -603,7 +603,7 @@ void exynos5_set_lcd_clk(void) */ cfg = readl(clk-src_disp1_0); cfg = ~(0xf); - cfg |= 0x8; + cfg |= 0x6; Please check it. writel(cfg, clk-src_disp1_0); /* Thanks. Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 4/4] EXYNOS5: Add support for FIMD and DP
Dear Ajay,
On 13/12/12 20:29, Ajay Kumar wrote:
Add panel_info structure required by LCD driver
and DP panel platdata for SMDK5250.
Add GPIO configuration for LCD.
Enable FIMD and DP support on SMDK5250.
DP Panel size: 2560x1600.
We use 16BPP resolution to get LCD console.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
board/samsung/smdk5250/smdk5250.c | 98
+
include/configs/smdk5250.h|8 +++
2 files changed, 106 insertions(+), 0 deletions(-)
diff --git a/board/samsung/smdk5250/smdk5250.c
b/board/samsung/smdk5250/smdk5250.c
index 4c50342..4c21742 100644
--- a/board/samsung/smdk5250/smdk5250.c
+++ b/board/samsung/smdk5250/smdk5250.c
@@ -24,12 +24,15 @@
#include asm/io.h
#include i2c.h
#include netdev.h
+#include lcd.h
#include spi.h
#include asm/arch/cpu.h
#include asm/arch/gpio.h
#include asm/arch/mmc.h
+#include asm/arch/power.h
#include asm/arch/pinmux.h
#include asm/arch/sromc.h
+#include asm/arch/dp_info.h
#include pmic.h
DECLARE_GLOBAL_DATA_PTR;
@@ -181,6 +184,101 @@ static int board_uart_init(void)
return 0;
}
+vidinfo_t panel_info = {
+ .vl_freq= 60,
+ .vl_col = 2560,
+ .vl_row = 1600,
+ .vl_width = 2560,
+ .vl_height = 1600,
+ .vl_clkp= CONFIG_SYS_LOW,
+ .vl_hsp = CONFIG_SYS_LOW,
+ .vl_vsp = CONFIG_SYS_LOW,
+ .vl_dp = CONFIG_SYS_LOW,
+ .vl_bpix= 4,/* LCD_BPP = 2^4, for output conosle on LCD */
+
+ /* wDP panel timing infomation */
+ .vl_hspw= 32,
+ .vl_hbpd= 80,
+ .vl_hfpd= 48,
+
+ .vl_vspw= 6,
+ .vl_vbpd= 37,
+ .vl_vfpd= 3,
+ .vl_cmd_allow_len = 0xf,
+
+ .win_id = 3,
+ .cfg_gpio = NULL,
+ .backlight_on = NULL,
+ .lcd_power_on = NULL,
+ .reset_lcd = NULL,
+ .dual_lcd_enabled = 0,
+
+ .init_delay = 0,
+ .power_on_delay = 0,
+ .reset_delay= 0,
+ .interface_mode = FIMD_RGB_INTERFACE,
+ .dp_enabled = 1,
+};
+
+static struct edp_device_info edp_info = {
+ .disp_info = {
+ .h_res = 2560,
+ .h_sync_width = 32,
+ .h_back_porch = 80,
+ .h_front_porch = 48,
+ .v_res = 1600,
+ .v_sync_width = 6,
+ .v_back_porch = 37,
+ .v_front_porch = 3,
+ .v_sync_rate = 60,
+ },
+ .lt_info = {
+ .lt_status = DP_LT_NONE,
+ },
+ .video_info = {
+ .master_mode = 0,
+ .bist_mode = DP_DISABLE,
+ .bist_pattern = NO_PATTERN,
+ .h_sync_polarity = 0,
+ .v_sync_polarity = 0,
+ .interlaced = 0,
+ .color_space = COLOR_RGB,
+ .dynamic_range = VESA,
+ .ycbcr_coeff = COLOR_YCBCR601,
+ .color_depth = COLOR_8,
+ },
+};
+
+static struct exynos_dp_platform_data dp_platform_data = {
+ .phy_enable = set_dp_phy_ctrl,
+ .edp_dev_info = edp_info,
+};
+
+static void cfg_lcd_gpio(void)
+{
+ struct exynos5_gpio_part1 *gpio1 =
+ (struct exynos5_gpio_part1 *) samsung_get_base_gpio_part1();
+
+ /* For Backlight */
+ s5p_gpio_cfg_pin(gpio1-b2, 0, GPIO_OUTPUT);
+ s5p_gpio_set_value(gpio1-b2, 0, 1);
+
+ /* LCD power on */
+ s5p_gpio_cfg_pin(gpio1-x1, 5, GPIO_OUTPUT);
+ s5p_gpio_set_value(gpio1-x1, 5, 1);
+
+ /* Set Hotplug detect for DP */
+ s5p_gpio_cfg_pin(gpio1-x0, 7, GPIO_FUNC(0x3));
+}
+
+void init_panel_info(vidinfo_t *vid)
+{
+ vid-rgb_mode = MODE_RGB_P,
+
+ exynos_set_dp_platform_data(dp_platform_data);
+ cfg_lcd_gpio();
why don't you use cfg_gpio in panel_info structure?
+}
+
#ifdef CONFIG_SYS_I2C_INIT_BOARD
static int board_i2c_init(void)
{
diff --git a/include/configs/smdk5250.h b/include/configs/smdk5250.h
index e412da8..a9b3b8b 100644
--- a/include/configs/smdk5250.h
+++ b/include/configs/smdk5250.h
@@ -256,6 +256,14 @@
#define CONFIG_SOUND_WM8994
#endif
+/* Display */
+#define CONFIG_LCD
+#define CONFIG_EXYNOS_FB
+#define CONFIG_EXYNOS_DP
+#define LCD_XRES 2560
+#define LCD_YRES 1600
+#define LCD_BPP LCD_COLOR16
+
/* Enable devicetree support */
#define CONFIG_OF_LIBFDT
Thanks.
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RESEND 2/4] video: Fix compilation dependency of exynos_dp and exynos_mipi on exynos_fb
Dear Ajay,
On 13/12/12 20:29, Ajay Kumar wrote:
When only DP is used, we need not enable CONFIG_EXYNOS_MIPI_DSIM.
Similarly, when only MIPI is used, we need not enable CONFIG_EXYNOS_DP.
But the current structuring of code forces us to enable both
CONFIG_EXYNOS_MIPI_DSIM and CONFIG_EXYNOS_DP.
This patch adds conditional compilation check to remove the dependency.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
drivers/video/exynos_fb.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/video/exynos_fb.c b/drivers/video/exynos_fb.c
index d9a3f9a..39d3b74 100644
--- a/drivers/video/exynos_fb.c
+++ b/drivers/video/exynos_fb.c
@@ -103,8 +103,10 @@ static void lcd_panel_on(vidinfo_t *vid)
udelay(vid-power_on_delay);
+#ifdef CONFIG_EXYNOS_DP
if (vid-dp_enabled)
exynos_init_dp();
+#endif
Unnecessary.
please see arch/arm/include/asm/arch-exynos/dp_info.h
#ifdef CONFIG_EXYNOS_DP
unsigned int exynos_init_dp(void);
#else
unsigned int exynos_init_dp(void)
{
return 0;
}
#endif
if (vid-reset_lcd) {
vid-reset_lcd();
@@ -120,8 +122,10 @@ static void lcd_panel_on(vidinfo_t *vid)
if (vid-enable_ldo)
vid-enable_ldo(1);
+#ifdef CONFIG_EXYNOS_MIPI_DSIM
if (vid-mipi_enabled)
exynos_mipi_dsi_init();
+#endif
This should be modified like exynos_init_dp?
Donghwa, how you think?
}
void lcd_ctrl_init(void *lcdbase)
Thanks.
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] EXYNOS4: Add ORIGEN_QUAD board support
Dear Jeong-Hyeon Kim,
On 13/12/12 19:37, Jeong-Hyeon Kim wrote:
ORIGEN_QUAD board is based on Samsung's Exynos4412 SoC.
Signed-off-by: Jeong-Hyeon Kim jh...@insignal.co.kr
---
Makefile |2 +-
board/samsung/origen_quad/Makefile| 59 ++
board/samsung/origen_quad/boot.c | 72 +++
board/samsung/origen_quad/clock.c | 103 ++
board/samsung/origen_quad/dmc.c | 163
board/samsung/origen_quad/lowlevel_init.S | 151 +++
board/samsung/origen_quad/origen_quad.c | 163
board/samsung/origen_quad/setup.h | 300
+
boards.cfg|1 +
include/configs/origen_quad.h | 179 +
tools/Makefile|2 +
11 files changed, 1194 insertions(+), 1 deletion(-)
create mode 100644 board/samsung/origen_quad/Makefile
create mode 100644 board/samsung/origen_quad/boot.c
create mode 100644 board/samsung/origen_quad/clock.c
create mode 100644 board/samsung/origen_quad/dmc.c
create mode 100644 board/samsung/origen_quad/lowlevel_init.S
create mode 100644 board/samsung/origen_quad/origen_quad.c
create mode 100644 board/samsung/origen_quad/setup.h
create mode 100644 include/configs/origen_quad.h
missing MAINTAINER entry.
+void save_boot_params(u32 r0, u32 r1, u32 r2, u32 r3) {}
diff --git a/board/samsung/origen_quad/clock.c
b/board/samsung/origen_quad/clock.c
new file mode 100644
index 000..7570039
--- /dev/null
+++ b/board/samsung/origen_quad/clock.c
@@ -0,0 +1,103 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics
+ *
+ * Copyright (C) 2012 Insignal
+ *
+ * Clock setup for the Insignal OrigenQUAD board (Exynos4x12)
+ *
+ * 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 config.h
+#include asm/io.h
+#include asm/arch/cpu.h
+#include asm/arch/clock.h
+#include setup.h
+
+void clock_ctrl_init(void)
+{
+ struct exynos4x12_clock *clk =
+ (struct exynos4x12_clock *)EXYNOS4_CLOCK_BASE;
please use samsung_get_base_clock() function.
+
+ /* CLK_SRC_CPU */
+ writel(0x, clk-src_cpu);
+ sdelay(0x1);
+
+ /* CLK_DIV_DMC */
+ writel(CLK_DIV_DMC0_VAL, clk-div_dmc0);
+ writel(CLK_DIV_DMC1_VAL, clk-div_dmc1);
+
+ /* CLK_SRC_TOP */
+ writel(CLK_SRC_TOP0_VAL, clk-src_top0);
+ writel(CLK_SRC_TOP1_VAL, clk-src_top1);
+ sdelay(0x1);
+ writel(CLK_DIV_TOP_VAL, clk-div_top);
+
+ /* LEFTBUS */
+ writel(CLK_SRC_LEFTBUS_VAL, clk-src_leftbus);
+ sdelay(0x1);
+ writel(CLK_DIV_LEFTBUS_VAL, clk-div_leftbus);
+ /* RIGHTBUS */
+ writel(CLK_SRC_RIGHTBUS_VAL, clk-src_rightbus);
+ sdelay(0x1);
+ writel(CLK_DIV_RIGHTBUS_VAL, clk-div_rightbus);
+
+ /* PLL locktime */
+ writel(APLL_LOCK_VAL, clk-apll_lock);
+ writel(MPLL_LOCK_VAL, clk-mpll_lock);
+ writel(EPLL_LOCK_VAL, clk-epll_lock);
+ writel(VPLL_LOCK_VAL, clk-vpll_lock);
+
+ /* CLK_DIV_CPU0/1 */
+ writel(CLK_DIV_CPU0_VAL, clk-div_cpu0);
+ writel(CLK_DIV_CPU1_VAL, clk-div_cpu1);
+
+ /* APLL */
+ writel(APLL_CON1_VAL, clk-apll_con1);
+ writel(APLL_CON0_VAL, clk-apll_con0);
+ /* MPLL */
+ writel(MPLL_CON1_VAL, clk-mpll_con1);
+ writel(MPLL_CON0_VAL, clk-mpll_con0);
+ /* EPLL */
+ writel(EPLL_CON2_VAL, clk-epll_con2);
+ writel(EPLL_CON1_VAL, clk-epll_con1);
+ writel(EPLL_CON0_VAL, clk-epll_con0);
+ /* VPLL */
+ writel(VPLL_CON2_VAL, clk-vpll_con2);
+ writel(VPLL_CON1_VAL, clk-vpll_con1);
+ writel(VPLL_CON0_VAL, clk-vpll_con0);
+ sdelay(0x4);
+
+ writel(CLK_SRC_CPU_VAL, clk-src_cpu);
+ writel(CLK_SRC_DMC_VAL, clk-src_dmc);
+ writel(CLK_SRC_TOP0_VAL, clk-src_top0);
+ writel(CLK_SRC_TOP1_VAL, clk-src_top1);
+ sdelay(0x1);
+
+ /* UART */
+ writel(CLK_SRC_PERIL0_VAL, clk-src_peril0);
+ writel(CLK_DIV_PERIL0_VAL, clk-div_peril0);
+
+ /* for IROM */
+ /* CLK_DIV_FSYS2 */
+ writel(0x000F,
Re: [U-Boot] [PATCH] env: don't generate callback list entries for SPL
Hi Scott, On Fri, Dec 14, 2012 at 6:54 PM, Scott Wood scottw...@freescale.com wrote: SPL doesn't use the environment. These list entries prevent the functions from being garbage-collected, even though nothing will look at the list. This caused several SPL builds (e.g. P2020RDB-PC_NAND) to break due to size limitations. A static inline function is used to provide a context in which we can consume the callback, and thus avoid unused function warnings. Signed-off-by: Scott Wood scottw...@freescale.com Sorry about that. Acked-by: Joe Hershberger joe.hershber...@ni.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/11] usb: net: asix: Do a fast init if link already established
Hi Simon,
On Wed, Dec 12, 2012 at 7:55 PM, Simon Glass s...@chromium.org wrote:
The Asix driver takes the link down during init() and then brings it back up.
This commit changes this so that if a link has already been established
successfully we simply check that the link is still good.
Also fix up asix_halt() to actually halt RX on the interface. Previously this
was not done, so the device would continue to operate evern when halted,
violating a U-Boot requirement.
This reduces the delay between successive network commands.
Signed-off-by: Simon Glass s...@chromium.org
---
drivers/usb/eth/asix.c | 40
include/usb_ether.h|1 +
2 files changed, 33 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/eth/asix.c b/drivers/usb/eth/asix.c
index 75ec8f7..a991fea 100644
--- a/drivers/usb/eth/asix.c
+++ b/drivers/usb/eth/asix.c
@@ -84,6 +84,7 @@
#define AX_DEFAULT_RX_CTL \
(AX_RX_CTL_SO | AX_RX_CTL_AB)
+#define AX_DISABLE_RX_CTL AX_RX_CTL_AB
/* GPIO 2 toggles */
#define AX_GPIO_GPO2EN 0x10/* GPIO2 Output enable */
@@ -410,17 +411,16 @@ static int asix_basic_reset(struct ueth_data *dev)
return 0;
}
-/*
- * Asix callbacks
- */
-static int asix_init(struct eth_device *eth, bd_t *bd)
+static int full_init(struct eth_device *eth)
{
- struct ueth_data*dev = (struct ueth_data *)eth-priv;
- int timeout = 0;
-#define TIMEOUT_RESOLUTION 50 /* ms */
- int link_detected;
+ struct ueth_data *dev = (struct ueth_data *)eth-priv;
debug(** %s()\n, __func__);
+ if (asix_basic_reset(dev))
+ goto out_err;
+
+ if (asix_write_rx_ctl(dev, AX_DEFAULT_RX_CTL) 0)
+ goto out_err;
dev-phy_id = asix_get_phy_addr(dev);
if (dev-phy_id 0)
@@ -446,6 +446,25 @@ static int asix_init(struct eth_device *eth, bd_t *bd)
debug(Write IPG,IPG1,IPG2 failed\n);
goto out_err;
}
+ return 0;
+out_err:
+ return -1;
+}
+
+/*
+ * Asix callbacks
+ */
+static int asix_init(struct eth_device *eth, bd_t *bd)
+{
+ struct ueth_data *dev = (struct ueth_data *)eth-priv;
+ int timeout = 0;
+#define TIMEOUT_RESOLUTION 50 /* ms */
+ int link_detected;
+
+ debug(** %s()\n, __func__);
+
+ if (!dev-has_been_running full_init(eth))
+ return -1;
if (asix_write_rx_ctl(dev, AX_DEFAULT_RX_CTL) 0)
goto out_err;
@@ -467,6 +486,7 @@ static int asix_init(struct eth_device *eth, bd_t *bd)
printf(unable to connect.\n);
goto out_err;
}
+ dev-has_been_running = 1;
return 0;
out_err:
@@ -571,7 +591,11 @@ static int asix_recv(struct eth_device *eth)
static void asix_halt(struct eth_device *eth)
{
+ struct ueth_data *dev = (struct ueth_data *)eth-priv;
+
+ /* Disable packet reception */
debug(** %s()\n, __func__);
+ (void)asix_write_rx_ctl(dev, AX_DISABLE_RX_CTL);
}
/*
diff --git a/include/usb_ether.h b/include/usb_ether.h
index 7c7aecb..6145210 100644
--- a/include/usb_ether.h
+++ b/include/usb_ether.h
@@ -49,6 +49,7 @@ struct ueth_data {
unsigned char subclass; /* as in overview */
unsigned char protocol; /* .. */
unsigned char irqinterval;/* Intervall for IRQ Pipe */
+ char has_been_running; /* PHY already inited */
/* driver private */
void *dev_priv;
Acked-by: Joe Hershberger joe.hershber...@ni.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ns16550: allow UART address to be set dynamically
Dear Graeme Russ, In message 50cbd313.60...@gmail.com you wrote: I can give you an example - Remote Telemetry Units (RTUs). They usually have a number of serial ports. The number of ports may vary based on the sub-model. Some ports may be RS-232, some may be RS-485 or RS-422. Depending on what additional devices you want to communicate with, you may need to use the 'console/diag' port to connect to a real device. So what you want to do is route console to another port (if available) or even netconsole. Netconsole is always an option, and I think we also support switching to other serial ports here and there (after relocation, that is). But if you need console output before relocation (i. e. during debugging), then I do not see why we cannot demand that the console port is statically configured, and that you need corectly configured images to have an early working console. I do get your point of view. But I think a combination of storing the dynamic console info in a DT format, the pre-console buffer and getting DT available as early as possible can yield a 'non-cludgy' solution. For board or SoC vendors who, for whatever reason, have implemented non-DT storage of hardware enumeration data they will be stuck with the penalty of having to translate that data into DT format before it can be parsed by U-Boot. Maybe this could be done in SPL. Yes, it's a hack, but if it can't be worked around, push it as low as possible and as far away from the U-Boot core as possible I mostly agree here. But I still fail to see why we havet os upport this combination of early and dynamic - and only this is what causes some issues. 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 Neckties strangle clear thinking. -- Lin Yutang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
