Re: [U-Boot] [PATCH 05/14] fdt: Export fdtdec_find_alias_node() function
On Thu, Oct 25, 2012 at 07:31:02PM -0700, Simon Glass wrote: > This function is useful outside fdtdec, so export it. Hrm. fdt_path_offset() in libfdt itself will already look up aliases if given a path that doesn't start with '/'. So it's not clear why you need this function at all. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 9/9 V4] SMDK5250: Enable Sound
This patch enables sound support for EXYNOS5 Signed-off-by: Rajeshwari Shinde Acked-by: Chander Kashyap Acked-by: Simon Glass --- Changes in V2: - corrected the commit message. Changes in V3: - None. Changes in V4: - None. include/configs/smdk5250.h |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/include/configs/smdk5250.h b/include/configs/smdk5250.h index 91da167..4cb43b5 100644 --- a/include/configs/smdk5250.h +++ b/include/configs/smdk5250.h @@ -218,6 +218,14 @@ #define CONFIG_MENU #endif +/* Sound */ +#define CONFIG_CMD_SOUND +#ifdef CONFIG_CMD_SOUND +#define CONFIG_SOUND +#define CONFIG_I2S +#define CONFIG_SOUND_WM8994 +#endif + /* Enable devicetree support */ #define CONFIG_OF_LIBFDT -- 1.7.4.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 8/9 V4] EXYNOS: Add clock for I2S
This patch adds clock support for I2S
Signed-off-by: R. Chandrasekar
Signed-off-by: Rajeshwari Shinde
Acked-by: Simon Glass
---
Changes in V2:
- None
Changes in V3:
- Changes clock function names as suggested by Minkyu Kang.
Changes in V4:
- None
arch/arm/cpu/armv7/exynos/clock.c| 120 ++
arch/arm/include/asm/arch-exynos/clk.h |3 +
arch/arm/include/asm/arch-exynos/clock.h | 29 +++
3 files changed, 152 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/clock.c
b/arch/arm/cpu/armv7/exynos/clock.c
index 4f3b451..5f7d884 100644
--- a/arch/arm/cpu/armv7/exynos/clock.c
+++ b/arch/arm/cpu/armv7/exynos/clock.c
@@ -26,6 +26,16 @@
#include
#include
+/* Epll Clock division values to achive different frequency output */
+static struct set_epll_con_val exynos5_epll_div[] = {
+ { 19200, 0, 48, 3, 1, 0 },
+ { 18000, 0, 45, 3, 1, 0 },
+ { 73728000, 1, 73, 3, 3, 47710 },
+ { 67737600, 1, 90, 4, 3, 20762 },
+ { 49152000, 0, 49, 3, 3, 9961 },
+ { 45158400, 0, 45, 3, 3, 10381 },
+ { 180633600, 0, 45, 3, 1, 10381 }
+};
/* exynos4: return pll clock frequency */
static unsigned long exynos4_get_pll_clk(int pllreg)
{
@@ -732,6 +742,93 @@ static unsigned long exynos5_get_i2c_clk(void)
return aclk_66;
}
+int exynos5_set_epll_clk(unsigned long rate)
+{
+ unsigned int epll_con, epll_con_k;
+ unsigned int i;
+ unsigned int lockcnt;
+ unsigned int start;
+ struct exynos5_clock *clk =
+ (struct exynos5_clock *)samsung_get_base_clock();
+
+ epll_con = readl(&clk->epll_con0);
+ epll_con &= ~((EPLL_CON0_LOCK_DET_EN_MASK <<
+ EPLL_CON0_LOCK_DET_EN_SHIFT) |
+ EPLL_CON0_MDIV_MASK << EPLL_CON0_MDIV_SHIFT |
+ EPLL_CON0_PDIV_MASK << EPLL_CON0_PDIV_SHIFT |
+ EPLL_CON0_SDIV_MASK << EPLL_CON0_SDIV_SHIFT);
+
+ for (i = 0; i < ARRAY_SIZE(exynos5_epll_div); i++) {
+ if (exynos5_epll_div[i].freq_out == rate)
+ break;
+ }
+
+ if (i == ARRAY_SIZE(exynos5_epll_div))
+ return -1;
+
+ epll_con_k = exynos5_epll_div[i].k_dsm << 0;
+ epll_con |= exynos5_epll_div[i].en_lock_det <<
+ EPLL_CON0_LOCK_DET_EN_SHIFT;
+ epll_con |= exynos5_epll_div[i].m_div << EPLL_CON0_MDIV_SHIFT;
+ epll_con |= exynos5_epll_div[i].p_div << EPLL_CON0_PDIV_SHIFT;
+ epll_con |= exynos5_epll_div[i].s_div << EPLL_CON0_SDIV_SHIFT;
+
+ /*
+* Required period ( in cycles) to genarate a stable clock output.
+* The maximum clock time can be up to 3000 * PDIV cycles of PLLs
+* frequency input (as per spec)
+*/
+ lockcnt = 3000 * exynos5_epll_div[i].p_div;
+
+ writel(lockcnt, &clk->epll_lock);
+ writel(epll_con, &clk->epll_con0);
+ writel(epll_con_k, &clk->epll_con1);
+
+ start = get_timer(0);
+
+while (!(readl(&clk->epll_con0) &
+ (0x1 << EXYNOS5_EPLLCON0_LOCKED_SHIFT))) {
+ if (get_timer(start) > TIMEOUT_EPLL_LOCK) {
+ debug("%s: Timeout waiting for EPLL lock\n", __func__);
+ return -1;
+ }
+ }
+ return 0;
+}
+
+void exynos5_set_i2s_clk_source(void)
+{
+ struct exynos5_clock *clk =
+ (struct exynos5_clock *)samsung_get_base_clock();
+
+ clrsetbits_le32(&clk->src_peric1, AUDIO1_SEL_MASK,
+ (CLK_SRC_SCLK_EPLL));
+}
+
+int exynos5_set_i2s_clk_prescaler(unsigned int src_frq,
+ unsigned int dst_frq)
+{
+ struct exynos5_clock *clk =
+ (struct exynos5_clock *)samsung_get_base_clock();
+ unsigned int div;
+
+ if ((dst_frq == 0) || (src_frq == 0)) {
+ debug("%s: Invalid requency input for prescaler\n", __func__);
+ debug("src frq = %d des frq = %d ", src_frq, dst_frq);
+ return -1;
+ }
+
+ div = (src_frq / dst_frq);
+ if (div > AUDIO_1_RATIO_MASK) {
+ debug("%s: Frequency ratio is out of range\n", __func__);
+ debug("src frq = %d des frq = %d ", src_frq, dst_frq);
+ return -1;
+ }
+ clrsetbits_le32(&clk->div_peric4, AUDIO_1_RATIO_MASK,
+ (div & AUDIO_1_RATIO_MASK));
+ return 0;
+}
+
unsigned long get_pll_clk(int pllreg)
{
if (cpu_is_exynos5())
@@ -803,3 +900,26 @@ void set_mipi_clk(void)
if (cpu_is_exynos4())
exynos4_set_mipi_clk();
}
+
+int set_i2s_clk_prescaler(unsigned int src_frq, unsigned int dst_frq)
+{
+
+ if (cpu_is_exynos5())
+ return exynos5_set_i2s_clk_prescaler(src_frq, dst_frq);
+ else
+ return 0;
+}
+
+void set_i2s_clk_source(void)
+{
+ if (cpu_is_exynos5())
+ exyn
[U-Boot] [PATCH 7/9 V4] EXYNOS: Add I2S base address
This patch adds base address for I2S Signed-off-by: Rajeshwari Shinde Acked-by: Chander Kashyap Acked-by: Simon Glass --- Changes in V2: - None Changes in V3: - None Changes in V4: - None arch/arm/include/asm/arch-exynos/cpu.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/include/asm/arch-exynos/cpu.h b/arch/arm/include/asm/arch-exynos/cpu.h index 2cd4ae1..ace40e5 100644 --- a/arch/arm/include/asm/arch-exynos/cpu.h +++ b/arch/arm/include/asm/arch-exynos/cpu.h @@ -54,6 +54,7 @@ #define EXYNOS4_PWMTIMER_BASE 0x139D #define EXYNOS4_MODEM_BASE 0x13A0 #define EXYNOS4_USBPHY_CONTROL 0x10020704 +#define EXYNOS4_I2S_BASE 0xE210 #define EXYNOS4_GPIO_PART4_BASEDEVICE_NOT_AVAILABLE #define EXYNOS4_DP_BASEDEVICE_NOT_AVAILABLE @@ -81,6 +82,7 @@ #define EXYNOS5_SROMC_BASE 0x1225 #define EXYNOS5_UART_BASE 0x12C0 #define EXYNOS5_I2C_BASE 0x12C6 +#define EXYNOS5_I2S_BASE 0x12D6 #define EXYNOS5_PWMTIMER_BASE 0x12DD #define EXYNOS5_GPIO_PART2_BASE0x1340 #define EXYNOS5_FIMD_BASE 0x1440 @@ -156,6 +158,7 @@ SAMSUNG_BASE(dp, DP_BASE) SAMSUNG_BASE(sysreg, SYSREG_BASE) SAMSUNG_BASE(fimd, FIMD_BASE) SAMSUNG_BASE(i2c, I2C_BASE) +SAMSUNG_BASE(i2s, I2S_BASE) SAMSUNG_BASE(mipi_dsim, MIPI_DSIM_BASE) SAMSUNG_BASE(gpio_part1, GPIO_PART1_BASE) SAMSUNG_BASE(gpio_part2, GPIO_PART2_BASE) -- 1.7.4.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/9 V4] EXYNOS: Add pinmux for I2S
This patch adds pinmux support for I2S1
Signed-off-by: Rajeshwari Shinde
Acked-by: Simon Glass
---
Changes in V2:
- made exynos_i2s_config pinmux function static.
Changes in V3:
- Incorporated comments from Simon Glass
Changes in V4:
- None
arch/arm/cpu/armv7/exynos/pinmux.c| 13 +
arch/arm/include/asm/arch-exynos/periph.h |1 +
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c
b/arch/arm/cpu/armv7/exynos/pinmux.c
index 5796d56..d99daa0 100644
--- a/arch/arm/cpu/armv7/exynos/pinmux.c
+++ b/arch/arm/cpu/armv7/exynos/pinmux.c
@@ -230,6 +230,16 @@ static void exynos5_i2c_config(int peripheral, int flags)
}
}
+static void exynos5_i2s_config(int peripheral)
+{
+ int i;
+ struct exynos5_gpio_part1 *gpio1 =
+ (struct exynos5_gpio_part1 *) samsung_get_base_gpio_part1();
+
+ for (i = 0; i < 5; i++)
+ s5p_gpio_cfg_pin(&gpio1->b0, i, GPIO_FUNC(0x02));
+}
+
static int exynos5_pinmux_config(int peripheral, int flags)
{
switch (peripheral) {
@@ -257,6 +267,9 @@ static int exynos5_pinmux_config(int peripheral, int flags)
case PERIPH_ID_I2C7:
exynos5_i2c_config(peripheral, flags);
break;
+ case PERIPH_ID_I2S1:
+ exynos5_i2s_config(peripheral);
+ break;
default:
debug("%s: invalid peripheral %d", __func__, peripheral);
return -1;
diff --git a/arch/arm/include/asm/arch-exynos/periph.h
b/arch/arm/include/asm/arch-exynos/periph.h
index 082611c..673f4c7 100644
--- a/arch/arm/include/asm/arch-exynos/periph.h
+++ b/arch/arm/include/asm/arch-exynos/periph.h
@@ -38,6 +38,7 @@ enum periph_id {
PERIPH_ID_I2C5,
PERIPH_ID_I2C6,
PERIPH_ID_I2C7,
+ PERIPH_ID_I2S1,
PERIPH_ID_SDMMC0,
PERIPH_ID_SDMMC1,
PERIPH_ID_SDMMC2,
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/9 V4] EXYNOS: Add parameters required by I2S
This patch adds the audio parameters required by the I2S to play the predefined audio data. Signed-off-by: Rajeshwari Shinde Acked-by: Simon Glass --- Changes in V2: - None Changes in V3: - Changed codec I2C address to 0x1a. Changes in V4: - None arch/arm/include/asm/arch-exynos/sound.h | 44 ++ 1 files changed, 44 insertions(+), 0 deletions(-) create mode 100644 arch/arm/include/asm/arch-exynos/sound.h diff --git a/arch/arm/include/asm/arch-exynos/sound.h b/arch/arm/include/asm/arch-exynos/sound.h new file mode 100644 index 000..d1bd2f6 --- /dev/null +++ b/arch/arm/include/asm/arch-exynos/sound.h @@ -0,0 +1,44 @@ +/* + * Copyright (C) 2012 Samsung Electronics + * Rajeshwari Shinde + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + + +#ifndef __SOUND_ARCH_H__ +#define __SOUND_ARCH_H__ + +/* I2S values */ +#define I2S_PLL_CLK19200 +#define I2S_SAMPLING_RATE 48000 +#define I2S_BITS_PER_SAMPLE16 +#define I2S_CHANNELS 2 +#define I2S_RFS256 +#define I2S_BFS32 + +/* I2C values */ +#define AUDIO_I2C_BUS 1 +#define AUDIO_I2C_REG 0x1a + +/* Audio Codec */ +#define AUDIO_CODEC"wm8994" + +#define AUDIO_COMPAT 1 +#endif -- 1.7.4.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] Bring in new I2C framework
Hello Simon,
On 25.10.2012 23:37, Simon Glass wrote:
On Mon, Oct 22, 2012 at 10:40 AM, Heiko Schocher wrote:
rebased/reworked the I2C multibus patches from Simon Glass found
here:
http://www.mail-archive.com/u-boot@lists.denx.de/msg75530.html
It seems the timing is coming, to bring this in mainline and
move boards over to the new i2c framework. As an example I
converted the soft-i2c driver (and all boards using it) to
the new framework, so this patchseries has to be tested
intensively, as I can check compile only ...
I am very happy to see this, thank you.
I am too ;-) and Sorry that I am only now ready ...
I have brought this in and tried to get it running for Tegra. A few points:
1. The methods in struct i2c_adapter should IMO be passed a struct
i2c_adapter *, so they can determine which adapter is being accessed.
Otherwise I can't see how they would know.
They can get the current used adapter through the defines in
include/i2c.h:
[...]
#define I2C_ADAP_NR(bus)i2c_adap[i2c_bus[bus].adapter]
#define I2C_BUS ((struct i2c_bus_hose *)gd->cur_i2c_bus)
#define I2C_ADAPi2c_adap[I2C_BUS->adapter]
#define I2C_ADAP_HWNR (I2C_ADAP->hwadapnr)
preparing just the fsl i2c driver and there I do for example:
drivers/i2c/fsl_i2c.c
[...]
static const struct fsl_i2c *i2c_dev[2] = {
(struct fsl_i2c *) (CONFIG_SYS_IMMR + CONFIG_SYS_FSL_I2C_OFFSET),
#ifdef CONFIG_SYS_FSL_I2C2_OFFSET
(struct fsl_i2c *) (CONFIG_SYS_IMMR + CONFIG_SYS_FSL_I2C2_OFFSET)
#endif
};
[...]
static int fsl_i2c_probe(uchar chip)
{
struct fsl_i2c *dev = (struct fsl_i2c *)i2c_dev[I2C_ADAP_HWNR];
[...]
but of course, we still can change the "struct i2c_adapter" if
needed ... but we have one more parameter ... Ok, not really a bad
problem.
2. The init is a bit odd, in that we can call init() repeatedly.
Perhaps that function should be renamed to reset, and the init should
be used for calling just once at the start?
What do you mean here exactly? I couldn´t parse this ...
3. Rather than each device having to call i2c_get_bus_num() to find
out what bus is referred to, why not just pass this information in? In
fact the adapter pointer can serve for this.
Not the "struct i2c_adapter" must passed, but the "struct
i2c_bus"!
And each device should know, which i2c bus it uses, or? So at
the end we should have something like i2c_read(struct i2c_bus *bus, ...)
calls ... and the i2c core can detect, if this bus is the
current, if so go on, if not switch to this bus. So at the
end i2c_set_bus_num would be go static ...
4. So perhaps the i2c read/write functions should change from:
int i2c_read(uchar chip, uint addr, int alen, uchar *buffer, int len)
to:
int i2c_read((struct i2c_adapter *adapter, uint addr, int alen, uchar
*buffer, int len)
Yep, exactly, see comments to point 3 ...
That would be the best (and I think in previous discussions I defined
this as one goal ...), but this would be (another) big change,
because this is an *API* change, with maybe a lot of config file
changes ...
Let us bring in the new i2c framework with all i2c drivers converted,
and then do the next step ... maybe one step more, if mareks device
model is ready, we can switch easy to DM ... and maybe get this API
change for free ...
Later, I wonder whether the concept of a 'current' i2c bus should be
maintained by the command line interpreter, rather than the i2c
system. Because to be honest, most of the drivers I see have to save
the current bus number, set the current bus, do the operation, then
set the bus back how they found it (to preserve whatever the user
things is the current bus).
Yes, suboptimal ... but this is independent from the new i2c framework
patches!
It is possible (with old/new i2c bus framework) to introduce a
"current commandline i2c bus", and then, before calling i2c_read/write
from the commandline, call a i2c_set_bus_num() ... then we can get rid
of this store/restore current i2c bus ... waiting for patches ;-)
Granted there is overhead with i2c muxes, but the i2c core can
remember the state of these muxes and doesn't have to switch things
until there has been a change since the last transaction.
This exactly do the i2c_set_bus_num() now!
This last suggestion can be dealt with later, but I thought I would bring it up.
I am happy about every comment! :-)
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/9 V4] EXYNOS: Add I2S registers
This patch add I2S registers Signed-off-by: R. Chandrasekar Signed-off-by: Rajeshwari Shinde Acked-by: Simon Glass --- Changes in V2: - None Changes in V3: - None Changes in V4: - None arch/arm/include/asm/arch-exynos/i2s-regs.h | 66 +++ 1 files changed, 66 insertions(+), 0 deletions(-) create mode 100644 arch/arm/include/asm/arch-exynos/i2s-regs.h diff --git a/arch/arm/include/asm/arch-exynos/i2s-regs.h b/arch/arm/include/asm/arch-exynos/i2s-regs.h new file mode 100644 index 000..2326ca0 --- /dev/null +++ b/arch/arm/include/asm/arch-exynos/i2s-regs.h @@ -0,0 +1,66 @@ +/* + * Copyright (C) 2012 Samsung Electronics + * R. Chandrasekar + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#ifndef __I2S_REGS_H__ +#define __I2S_REGS_H__ + +#define CON_TXFIFO_FULL(1 << 8) +#define CON_TXCH_PAUSE (1 << 4) +#define CON_ACTIVE (1 << 0) + +#define MOD_BLCP_SHIFT 24 +#define MOD_BLCP_16BIT (0 << MOD_BLCP_SHIFT) +#define MOD_BLCP_8BIT (1 << MOD_BLCP_SHIFT) +#define MOD_BLCP_24BIT (2 << MOD_BLCP_SHIFT) +#define MOD_BLCP_MASK (3 << MOD_BLCP_SHIFT) + +#define MOD_BLC_16BIT (0 << 13) +#define MOD_BLC_8BIT (1 << 13) +#define MOD_BLC_24BIT (2 << 13) +#define MOD_BLC_MASK (3 << 13) + +#define MOD_SLAVE (1 << 11) +#define MOD_MASK (3 << 8) +#define MOD_LR_LLOW(0 << 7) +#define MOD_LR_RLOW(1 << 7) +#define MOD_SDF_IIS(0 << 5) +#define MOD_SDF_MSB(1 << 5) +#define MOD_SDF_LSB(2 << 5) +#define MOD_SDF_MASK (3 << 5) +#define MOD_RCLK_256FS (0 << 3) +#define MOD_RCLK_512FS (1 << 3) +#define MOD_RCLK_384FS (2 << 3) +#define MOD_RCLK_768FS (3 << 3) +#define MOD_RCLK_MASK (3 << 3) +#define MOD_BCLK_32FS (0 << 1) +#define MOD_BCLK_48FS (1 << 1) +#define MOD_BCLK_16FS (2 << 1) +#define MOD_BCLK_24FS (3 << 1) +#define MOD_BCLK_MASK (3 << 1) + +#define MOD_CDCLKCON (1 << 12) + +#define FIC_TXFLUSH(1 << 15) +#define FIC_RXFLUSH(1 << 7) + +#endif /* __I2S_REGS_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 3/9 V4] Sound: Add command for audio playback
This patch adds command to test audio playback.
sound init - Initialises the audio subsystem (i2s and wm8994 codec)
sound play - Plays predefined the audio data when specified length
and frequency.
Signed-off-by: Rajeshwari Shinde
Acked-by: Simon Glass
---
Changes in V2:
- None
Changes in V3:
- Incorporated comments from Simon Glass.
Changes in V4:
- None
common/Makefile|1 +
common/cmd_sound.c | 96
2 files changed, 97 insertions(+), 0 deletions(-)
create mode 100644 common/cmd_sound.c
diff --git a/common/Makefile b/common/Makefile
index fdfead7..3f9f001 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -74,6 +74,7 @@ COBJS-$(CONFIG_CMD_CONSOLE) += cmd_console.o
COBJS-$(CONFIG_CMD_CPLBINFO) += cmd_cplbinfo.o
COBJS-$(CONFIG_DATAFLASH_MMC_SELECT) += cmd_dataflash_mmc_mux.o
COBJS-$(CONFIG_CMD_DATE) += cmd_date.o
+COBJS-$(CONFIG_CMD_SOUND) += cmd_sound.o
ifdef CONFIG_4xx
COBJS-$(CONFIG_CMD_SETGETDCR) += cmd_dcr.o
endif
diff --git a/common/cmd_sound.c b/common/cmd_sound.c
new file mode 100644
index 000..459d1eb
--- /dev/null
+++ b/common/cmd_sound.c
@@ -0,0 +1,96 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics
+ * Rajeshwari Shinde
+ *
+ * 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
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* Initilaise sound subsystem */
+static int do_init(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[])
+{
+ int ret;
+
+ ret = sound_init();
+ if (ret) {
+ printf("Initialise Audio driver failed\n");
+ return CMD_RET_FAILURE;
+ }
+
+ return 0;
+}
+
+/* play sound from buffer */
+static int do_play(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[])
+{
+ int ret = 0;
+ int msec = 1000;
+ int freq = 400;
+
+ if (argc > 1)
+ msec = simple_strtoul(argv[1], NULL, 10);
+ if (argc > 2)
+ freq = simple_strtoul(argv[2], NULL, 10);
+
+ ret = sound_play(msec, freq);
+ if (ret) {
+ printf("play failed");
+ return CMD_RET_FAILURE;
+ }
+
+ return 0;
+}
+
+static cmd_tbl_t cmd_sound_sub[] = {
+ U_BOOT_CMD_MKENT(init, 0, 1, do_init, "", ""),
+ U_BOOT_CMD_MKENT(play, 2, 1, do_play, "", ""),
+};
+
+/* process sound command */
+static int do_sound(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[])
+{
+ cmd_tbl_t *c;
+
+ if (argc < 1)
+ return CMD_RET_USAGE;
+
+ /* Strip off leading 'sound' command argument */
+ argc--;
+ argv++;
+
+ c = find_cmd_tbl(argv[0], &cmd_sound_sub[0], ARRAY_SIZE(cmd_sound_sub));
+
+ if (c)
+ return c->cmd(cmdtp, flag, argc, argv);
+ else
+ return CMD_RET_USAGE;
+}
+
+U_BOOT_CMD(
+ sound, 4, 1, do_sound,
+ "sound sub-system",
+ "init - initialise the sound driver\n"
+ "sound play [len] [freq] - play a sound for len ms at freq hz\n"
+);
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/9 V4] SOUND: Add WM8994 codec
This patch adds driver for audio codec WM8994
Signed-off-by: R. Chandrasekar
Signed-off-by: Rajeshwari Shinde
Acked-by: Simon Glass
---
Changes in V2:
- None
Changes in V3:
- Incorporated comments from Simon Glass.
Changes in V4:
- None
drivers/sound/Makefile |1 +
drivers/sound/wm8994.c | 792 ++
drivers/sound/wm8994.h | 87 +
drivers/sound/wm8994_registers.h | 299 ++
4 files changed, 1179 insertions(+), 0 deletions(-)
create mode 100644 drivers/sound/wm8994.c
create mode 100644 drivers/sound/wm8994.h
create mode 100644 drivers/sound/wm8994_registers.h
diff --git a/drivers/sound/Makefile b/drivers/sound/Makefile
index 18ad2c9..8fdffb1 100644
--- a/drivers/sound/Makefile
+++ b/drivers/sound/Makefile
@@ -27,6 +27,7 @@ LIB := $(obj)libsound.o
COBJS-$(CONFIG_SOUND) += sound.o
COBJS-$(CONFIG_I2S)+= samsung-i2s.o
+COBJS-$(CONFIG_SOUND_WM8994) += wm8994.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/sound/wm8994.c b/drivers/sound/wm8994.c
new file mode 100644
index 000..293903a
--- /dev/null
+++ b/drivers/sound/wm8994.c
@@ -0,0 +1,792 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics
+ * R. Chandrasekar
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "wm8994.h"
+#include "wm8994_registers.h"
+
+/* defines for wm8994 system clock selection */
+#define SEL_MCLK1 0x00
+#define SEL_MCLK2 0x08
+#define SEL_FLL1 0x10
+#define SEL_FLL2 0x18
+
+/* fll config to configure fll */
+struct wm8994_fll_config {
+ int src;/* Source */
+ int in; /* Input frequency in Hz */
+ int out;/* output frequency in Hz */
+};
+
+/* codec private data */
+struct wm8994_priv {
+ enum wm8994_type type; /* codec type of wolfson */
+ int revision; /* Revision */
+ int sysclk[WM8994_MAX_AIF]; /* System clock frequency in Hz */
+ int mclk[WM8994_MAX_AIF]; /* master clock frequency in Hz */
+ int aifclk[WM8994_MAX_AIF]; /* audio interface clock in Hz */
+ struct wm8994_fll_config fll[2]; /* fll config to configure fll */
+};
+
+/* wm 8994 supported sampling rate values */
+static unsigned int src_rate[] = {
+8000, 11025, 12000, 16000, 22050, 24000,
+32000, 44100, 48000, 88200, 96000
+};
+
+/* op clock divisions */
+static int opclk_divs[] = { 10, 20, 30, 40, 55, 60, 80, 120, 160 };
+
+/* lr clock frame size ratio */
+static int fs_ratios[] = {
+ 64, 128, 192, 256, 348, 512, 768, 1024, 1408, 1536
+};
+
+/* bit clock divisors */
+static int bclk_divs[] = {
+ 10, 15, 20, 30, 40, 50, 60, 80, 110, 120, 160, 220, 240, 320, 440, 480,
+ 640, 880, 960, 1280, 1760, 1920
+};
+
+static struct wm8994_priv g_wm8994_info;
+static unsigned char g_wm8994_i2c_dev_addr;
+
+/*
+ * Initialise I2C for wm 8994
+ *
+ * @param bus no i2c bus number in which wm8994 is connected
+ */
+static void wm8994_i2c_init(int bus_no)
+{
+ i2c_set_bus_num(bus_no);
+}
+
+/*
+ * Writes value to a device register through i2c
+ *
+ * @param reg reg number to be write
+ * @param data data to be writen to the above registor
+ *
+ * @return int value 1 for change, 0 for no change or negative error code.
+ */
+static int wm8994_i2c_write(unsigned int reg, unsigned short data)
+{
+ unsigned char val[2];
+
+ val[0] = (unsigned char)((data >> 8) & 0xff);
+ val[1] = (unsigned char)(data & 0xff);
+ debug("Write Addr : 0x%04X, Data : 0x%04X\n", reg, data);
+
+ return i2c_write(g_wm8994_i2c_dev_addr, reg, 2, val, 2);
+}
+
+/*
+ * Read a value from a device register through i2c
+ *
+ * @param reg reg number to be read
+ * @param data address of read data to be stored
+ *
+ * @return int value 0 for success, -1 in case of error.
+ */
+static unsigned int wm8994_i2c_read(unsigned int reg , unsigned short *data)
+{
+ unsigned char val[2];
+ int ret;
+
+ ret = i2c_read(g_wm8994_i2c_dev_addr, reg, 2, val, 2);
+ if (ret
[U-Boot] [PATCH 1/9 V4] SOUND: SAMSUNG: Add I2S driver
This patch adds driver for I2S interface specific to samsung.
Signed-off-by: R. Chandrasekar
Signed-off-by: Rajeshwari Shinde
Acked-by: Simon Glass
---
Changes in V2:
- renamed i2s.c to samsung-i2s.c.
Changes in V3:
- wave sine table removed and the same in calculated in a function.
Changes in V4:
- Corrected the coding style issues suggested by Simon Glass.
- Global variables in sound.c were made static.
Makefile|1 +
drivers/sound/Makefile | 47 ++
drivers/sound/samsung-i2s.c | 358 +++
drivers/sound/sound.c | 228 +++
include/i2s.h | 127 +++
include/sound.h | 62
6 files changed, 823 insertions(+), 0 deletions(-)
create mode 100644 drivers/sound/Makefile
create mode 100644 drivers/sound/samsung-i2s.c
create mode 100644 drivers/sound/sound.c
create mode 100644 include/i2s.h
create mode 100644 include/sound.h
diff --git a/Makefile b/Makefile
index 08eecbb..ee4fb7f 100644
--- a/Makefile
+++ b/Makefile
@@ -311,6 +311,7 @@ LIBS-y += arch/powerpc/cpu/mpc8xxx/lib8xxx.o
endif
LIBS-y += drivers/rtc/librtc.o
LIBS-y += drivers/serial/libserial.o
+LIBS-y += drivers/sound/libsound.o
LIBS-$(CONFIG_GENERIC_LPC_TPM) += drivers/tpm/libtpm.o
LIBS-y += drivers/twserial/libtws.o
LIBS-y += drivers/usb/eth/libusb_eth.o
diff --git a/drivers/sound/Makefile b/drivers/sound/Makefile
new file mode 100644
index 000..18ad2c9
--- /dev/null
+++ b/drivers/sound/Makefile
@@ -0,0 +1,47 @@
+#
+# Copyright (C) 2012 Samsung Electronics
+# R. Chandrasekar
+#
+# 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 $(TOPDIR)/config.mk
+
+LIB:= $(obj)libsound.o
+
+COBJS-$(CONFIG_SOUND) += sound.o
+COBJS-$(CONFIG_I2S)+= samsung-i2s.o
+
+COBJS := $(COBJS-y)
+SRCS := $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+
+all: $(LIB)
+
+$(LIB):$(obj).depend $(OBJS)
+ $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/drivers/sound/samsung-i2s.c b/drivers/sound/samsung-i2s.c
new file mode 100644
index 000..9f3117d
--- /dev/null
+++ b/drivers/sound/samsung-i2s.c
@@ -0,0 +1,358 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics
+ * R. Chandrasekar
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define FIC_TX2COUNT(x)(((x) >> 24) & 0xf)
+#define FIC_TX1COUNT(x)(((x) >> 16) & 0xf)
+#define FIC_TXCOUNT(x) (((x) >> 8) & 0xf)
+#define FIC_RXCOUNT(x) (((x) >> 0) & 0xf)
+#define FICS_TXCOUNT(x)(((x) >> 8) & 0x7f)
+
+#define TIMEOUT_I2S_TX 100 /* i2s transfer timeout */
+
+/*
+ * Sets the frame size for I2S LR clock
+ *
+ * @param i2s_reg i2s regiter address
+ * @param rfs Frame Size
+ */
+static void i2s_set_lr_framesize(struct i2s_reg *i2s_reg, unsigned int rfs)
+{
+ unsigned int mod = readl(&i2s_reg->mod);
+
+ mod &= ~MOD_RCLK_MASK;
+
+ switch (rfs) {
+ case 768:
+ mod |= MOD_RCLK_768FS;
+ break;
+ case 512:
+ mod |= MOD_RCLK_512FS;
+ break;
+ case 384:
+ mod |= MOD_RCLK_384FS;
+ break;
+ def
[U-Boot] [PATCH 0/9 V4] EXYNOS5: Add Audio support
This patchset adds the audio support for EXYNOS5. This patchset plays a predefined beep sound. Rajeshwari Shinde (9): SOUND: SAMSUNG: Add I2S driver SOUND: Add WM8994 codec Sound: Add command for audio playback EXYNOS: Add I2S registers EXYNOS: Add parameters required by I2S EXYNOS: Add pinmux for I2S EXYNOS: Add I2S base address EXYNOS: Add clock for I2S SMDK5250: Enable Sound Changes in V2: - renamed i2s.c to samsung-i2s.c. - made exynos_i2s_config pinmux function static. - corrected the commit message for "Enable sound" patch. Changes in V3: - Incorporated comments from Simon Glass and Minkyu Kang. Changes in V4: - Corrected the coding style issues suggested by Simon Glass. Makefile|1 + arch/arm/cpu/armv7/exynos/clock.c | 120 arch/arm/cpu/armv7/exynos/pinmux.c | 13 + arch/arm/include/asm/arch-exynos/clk.h |3 + arch/arm/include/asm/arch-exynos/clock.h| 29 + arch/arm/include/asm/arch-exynos/cpu.h |3 + arch/arm/include/asm/arch-exynos/i2s-regs.h | 66 +++ arch/arm/include/asm/arch-exynos/periph.h |1 + arch/arm/include/asm/arch-exynos/sound.h| 44 ++ common/Makefile |1 + common/cmd_sound.c | 96 drivers/sound/Makefile | 48 ++ drivers/sound/samsung-i2s.c | 358 drivers/sound/sound.c | 228 drivers/sound/wm8994.c | 792 +++ drivers/sound/wm8994.h | 87 +++ drivers/sound/wm8994_registers.h| 299 ++ include/configs/smdk5250.h |8 + include/i2s.h | 127 + include/sound.h | 62 +++ 20 files changed, 2386 insertions(+), 0 deletions(-) create mode 100644 arch/arm/include/asm/arch-exynos/i2s-regs.h create mode 100644 arch/arm/include/asm/arch-exynos/sound.h create mode 100644 common/cmd_sound.c create mode 100644 drivers/sound/Makefile create mode 100644 drivers/sound/samsung-i2s.c create mode 100644 drivers/sound/sound.c create mode 100644 drivers/sound/wm8994.c create mode 100644 drivers/sound/wm8994.h create mode 100644 drivers/sound/wm8994_registers.h create mode 100644 include/i2s.h create mode 100644 include/sound.h -- 1.7.4.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
Hi Tom, On Thu, 25 Oct 2012 11:49:22 -0700, Tom Rini wrote: > Hello, > > The following changes since commit 39826f09978a0a7070999acc15babf88f03e4051: > > arm: fdt: Relocate fdt along with other data (2012-10-19 21:38:27 +0200) > > are available in the git repository at: > > git://git.denx.de/u-boot-ti.git master > > for you to fetch changes up to c7d35bef255dedb3ec3856982f042dde514676b0: > > am33xx/ddr_defs.h: rename DDR2/DDR3 defines to their actual part numbers > (2012-10-25 11:31:38 -0700) > > > Andrew Bradford (1): > configs: Fix usage of mmc rescan > > Igor Grinberg (1): > cm-t35: clean unused defines from config > > Joel A Fernandes (1): > am33xx: Enable DDR3 for DDR3 version of beaglebone > > Pankaj Bharadiya (1): > USB: musb_udc: Make musb_peri_rx_ep check for MUSB_RXCSR_RXPKTRDY > > Peter Korsgaard (7): > omap3_spi: introduce CONFIG_OMAP3_SPI_D0_D1_SWAPPED > am33xx/board.c: make wdtimer/uart_base static > am33xx: move ti i2c baseboard header handling to board/ti/am335x/ > am33xx/board: use cpu_mmc_init() for default mmc initialization > am33xx: move generic parts of pinmux handling out from board/ti/am335x > am33xx: support board specific ddr settings > am33xx/ddr_defs.h: rename DDR2/DDR3 defines to their actual part numbers > > Stefano Babic (5): > OMAP3: mt_ventoux: power on USB at startup > OMAP3: updated pinmux and environment for new revision of mcx board > OMAP3: mcx: updated to new hardware revision > VIDEO: add macro to set LCD size for DSS driver > OMAP3: add video support to the mcx board > > Tom Rini (2): > omapimage: Add support for byteswapped SPI images > am33xx: Add SPI SPL as an option > > Vaibhav Hiremath (1): > am335x: Enable RTC 32K OSC clock > > arch/arm/cpu/armv7/am33xx/Makefile |1 + > arch/arm/cpu/armv7/am33xx/board.c| 239 +--- > arch/arm/cpu/armv7/am33xx/clock.c|6 + > arch/arm/cpu/armv7/am33xx/config.mk |1 + > arch/arm/cpu/armv7/am33xx/emif4.c| 114 +--- > arch/arm/cpu/armv7/am33xx/mux.c | 33 +++ > arch/arm/include/asm/arch-am33xx/cpu.h | 15 + > arch/arm/include/asm/arch-am33xx/ddr_defs.h | 69 ++--- > arch/arm/include/asm/arch-am33xx/hardware.h |4 + > arch/arm/include/asm/arch-am33xx/mux.h | 261 ++ > arch/arm/include/asm/arch-am33xx/spl.h |1 + > arch/arm/include/asm/arch-am33xx/sys_proto.h | 27 -- > arch/arm/include/asm/arch-omap3/dss.h|1 + > board/htkw/mcx/mcx.c | 48 +++- > board/htkw/mcx/mcx.h | 30 +- > board/teejet/mt_ventoux/mt_ventoux.c |8 + > board/ti/am335x/Makefile |1 + > board/ti/am335x/board.c | 376 > ++ > board/ti/am335x/board.h | 49 > board/ti/am335x/mux.c| 250 + > drivers/spi/omap3_spi.c | 11 +- > drivers/usb/musb/musb_udc.c | 11 +- > include/configs/am335x_evm.h |9 +- > include/configs/am3517_crane.h |2 +- > include/configs/am3517_evm.h |2 +- > include/configs/cm_t35.h | 14 +- > include/configs/devkit8000.h |2 +- > include/configs/igep00x0.h |2 +- > include/configs/mcx.h| 31 ++- > include/configs/mx28evk.h|2 +- > include/configs/mx51evk.h|2 +- > include/configs/mx53ard.h|2 +- > include/configs/mx53evk.h|2 +- > include/configs/mx53loco.h |2 +- > include/configs/mx53smd.h|2 +- > include/configs/mx6qarm2.h |2 +- > include/configs/mx6qsabrelite.h |2 +- > include/configs/omap3_beagle.h |2 +- > include/configs/omap3_evm.h |2 +- > include/configs/omap3_logic.h|2 +- > include/configs/omap3_overo.h|2 +- > include/configs/omap3_zoom1.h|2 +- > include/configs/omap4_common.h |2 +- > include/configs/omap5_evm.h |2 +- > include/configs/tricorder.h |2 +- > spl/Makefile |9 +- > tools/omapimage.c| 83 -- > 47 files changed, 998 insertions(+), 744 deletions(-) > create mode 100644 arch/arm/cpu/armv7/am33xx/mux.c > create mode 100644 arch/arm/include/asm/arch-am33xx/mux.h > create mode 100644 board/ti/am335x/board.c > create mode 100644 board/ti/am335x/board.h > > Thanks! > Appli
Re: [U-Boot] Merging device trees at runtime for module-based systems
On Thu, Oct 25, 2012 at 10:46:32PM +0200, Wolfgang Denk wrote: > Dear Daniel, > > In message <50893633.6070...@gmail.com> you wrote: > > > > Overwrites must be addressed in the first place. The most common example > > is that a more generic part (the module tree) registers all details > > about a peripheral up-front but then sets its status to 'disabled'. That > > way, the more specific part (the base board tree) can overwrite this > > property to 'okay' at wish to enable it and not care for the pre-defined > > details. This is also how we do things in our device-trees. > > Agreed. > > > > I definitely can see the benefit of such a feature and would be happy > > > if you could go forward and implement it. > > > > Ok then. I guess this should be something that can eventually be merged > > back into libfdt? > > I can't speak for the FDT custodian, but I think this makes a lot of > sense. As a rule I'm happy to see more functionality for libfdt. I've only seen bits and pieces of this thread, though, so I'd need to see a summary of what exactly is being proposed. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/9 V3] SOUND: Add WM8994 codec
Hi Simon Glass, Thank you for the comments. On Thu, Oct 25, 2012 at 10:37 PM, Simon Glass wrote: > > Hi, > > On Mon, Oct 22, 2012 at 11:57 PM, Rajeshwari Shinde > wrote: > > This patch adds driver for audio codec WM8994 > > > > Signed-off-by: R. Chandrasekar > > Signed-off-by: Rajeshwari Shinde > > Acked-by: Simon Glass > > > --- > > Changes in V2: > > - None > > Changes in V3: > > - Incorporated comments from Simon Glass. > > Sometimes it is better to list the actual changes made. Will take care of the same in future. > > > drivers/sound/Makefile |1 + > > drivers/sound/wm8994.c | 792 > > ++ > > drivers/sound/wm8994.h | 87 + > > drivers/sound/wm8994_registers.h | 299 ++ > > 4 files changed, 1179 insertions(+), 0 deletions(-) > > create mode 100644 drivers/sound/wm8994.c > > create mode 100644 drivers/sound/wm8994.h > > create mode 100644 drivers/sound/wm8994_registers.h > > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot Regards, Rajeshwari Shinde. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/9 V3] SOUND: SAMSUNG: Add I2S driver
Hi Simon Glass, Thank you for the comments. Will correct the issues mentioned. Regards, Rajeshwari Shinde. On Thu, Oct 25, 2012 at 10:32 PM, Simon Glass wrote: > Hi, > > On Mon, Oct 22, 2012 at 11:57 PM, Rajeshwari Shinde > wrote: > > This patch adds driver for I2S interface specific to samsung. > > > > Signed-off-by: R. Chandrasekar > > Signed-off-by: Rajeshwari Shinde > > --- > > Changes in V2: > > - renamed i2s.c to samsung-i2s.c. > > Changes in V3: > > - wave sine table removed and the same in calculated in a function. > > This looks great. There are a few style nits that you might want to > correct, but: > > Acked-by: Simon Glass > > > Makefile|1 + > > drivers/sound/Makefile | 47 ++ > > drivers/sound/samsung-i2s.c | 358 > +++ > > drivers/sound/sound.c | 228 +++ > > include/i2s.h | 127 +++ > > include/sound.h | 62 > > 6 files changed, 823 insertions(+), 0 deletions(-) > > create mode 100644 drivers/sound/Makefile > > create mode 100644 drivers/sound/samsung-i2s.c > > create mode 100644 drivers/sound/sound.c > > create mode 100644 include/i2s.h > > create mode 100644 include/sound.h > > > > diff --git a/Makefile b/Makefile > > index a40d4cc..f7d7f47 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -293,6 +293,7 @@ LIBS-y += arch/powerpc/cpu/mpc8xxx/lib8xxx.o > > endif > > LIBS-y += drivers/rtc/librtc.o > > LIBS-y += drivers/serial/libserial.o > > +LIBS-y += drivers/sound/libsound.o > > LIBS-$(CONFIG_GENERIC_LPC_TPM) += drivers/tpm/libtpm.o > > LIBS-y += drivers/twserial/libtws.o > > LIBS-y += drivers/usb/eth/libusb_eth.o > > diff --git a/drivers/sound/Makefile b/drivers/sound/Makefile > > new file mode 100644 > > index 000..18ad2c9 > > --- /dev/null > > +++ b/drivers/sound/Makefile > > @@ -0,0 +1,47 @@ > > +# > > +# Copyright (C) 2012 Samsung Electronics > > +# R. Chandrasekar > > +# > > +# 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 $(TOPDIR)/config.mk > > + > > +LIB:= $(obj)libsound.o > > + > > +COBJS-$(CONFIG_SOUND) += sound.o > > +COBJS-$(CONFIG_I2S)+= samsung-i2s.o > > + > > +COBJS := $(COBJS-y) > > +SRCS := $(COBJS:.o=.c) > > +OBJS := $(addprefix $(obj),$(COBJS)) > > + > > +all: $(LIB) > > + > > +$(LIB):$(obj).depend $(OBJS) > > + $(call cmd_link_o_target, $(OBJS)) > > + > > > +# > > + > > +# defines $(obj).depend target > > +include $(SRCTREE)/rules.mk > > + > > +sinclude $(obj).depend > > + > > +# > > diff --git a/drivers/sound/samsung-i2s.c b/drivers/sound/samsung-i2s.c > > new file mode 100644 > > index 000..3ce0b59 > > --- /dev/null > > +++ b/drivers/sound/samsung-i2s.c > > @@ -0,0 +1,358 @@ > > +/* > > + * Copyright (C) 2012 Samsung Electronics > > + * R. Chandrasekar > > + * > > + * 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 > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#define FIC_TX2COUNT(x)(((x) >> 24) & 0xf) > > +#define FIC_TX1COUNT(x)(((x) >> 16) & 0xf) > > +#define FIC_TXCOUNT(x) (((x) >> 8) & 0xf) > > +#define FIC_RXCOUNT(x) ((
Re: [U-Boot] [PATCH 20/20] x86: config: Enable AHCI support for coreboot
Hi Simon, On Fri, Oct 26, 2012 at 1:36 PM, Simon Glass wrote: > Hi Graeme, > > On Mon, Oct 22, 2012 at 11:33 PM, Graeme Russ wrote: >> Hi Simon, >> >> On Oct 23, 2012 4:42 PM, "Simon Glass" wrote: >>> >>> Hi Graeme, >>> >>> On Mon, Oct 22, 2012 at 10:38 PM, Graeme Russ >>> wrote: >>> > Hi Simon, >>> > [snip] >>> > I plan on doing dev work on a AMD E350 based board 'soon'. The E350 is >>> > already supported by coreboot, so I'm planning on getting coreboot >>> > ported for this board and then run U-Boot from coreboot. So we can no >>> > longer assume all coreboot boards will be Intel based. >>> >>> Sounds good! Shall we rename coreboot.h to something like >>> chromebook-x86.h? >> >> Even better would be to use the model name (which I assume would make the >> x86 tag redundant) > > Well, the model is very device-specific. So far as U-Boot cares all > the models are basically the same. What differences there are are > taken care of by device tree differences. This is try on ARM for > machines which share the some SOC, and true for basically all x86 > platforms. Key words: "So far" :) - If all the x86 chromebooks are essentially the same as far as U-Boot is concerned, then chromebook-x86.h will be fine. I assume the plan is to create a common U-Boot binary with drivers for all supported chromebook hardware and use the device tree (initially built by passing coreboot tables, but maybe one day in the future passed by coreboot) to determine which drivers to initialise? The device tree would then be further fleshed out by U-Boot and passed to the Linux kernel? Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 32/32] drivers/serial/serial_ns16550.c: sparse fixes
On Tue, Oct 16, 2012 at 02:28:48PM -, Kim Phillips wrote: > serial_ns16550.c:222:1: warning: symbol 'eserial1_init' was not declared. > Should it be static? > serial_ns16550.c:222:1: warning: symbol 'eserial1_setbrg' was not declared. > Should it be static? > serial_ns16550.c:222:1: warning: symbol 'eserial1_getc' was not declared. > Should it be static? > serial_ns16550.c:222:1: warning: symbol 'eserial1_tstc' was not declared. > Should it be static? > serial_ns16550.c:222:1: warning: symbol 'eserial1_putc' was not declared. > Should it be static? > serial_ns16550.c:222:1: warning: symbol 'eserial1_puts' was not declared. > Should it be static? > serial_ns16550.c:225:1: warning: symbol 'eserial2_init' was not declared. > Should it be static? > serial_ns16550.c:225:1: warning: symbol 'eserial2_setbrg' was not declared. > Should it be static? > serial_ns16550.c:225:1: warning: symbol 'eserial2_getc' was not declared. > Should it be static? > serial_ns16550.c:225:1: warning: symbol 'eserial2_tstc' was not declared. > Should it be static? > serial_ns16550.c:225:1: warning: symbol 'eserial2_putc' was not declared. > Should it be static? > serial_ns16550.c:225:1: warning: symbol 'eserial2_puts' was not declared. > Should it be static? > serial_ns16550.c:228:1: warning: symbol 'eserial3_init' was not declared. > Should it be static? > serial_ns16550.c:228:1: warning: symbol 'eserial3_setbrg' was not declared. > Should it be static? > serial_ns16550.c:228:1: warning: symbol 'eserial3_getc' was not declared. > Should it be static? > serial_ns16550.c:228:1: warning: symbol 'eserial3_tstc' was not declared. > Should it be static? > serial_ns16550.c:228:1: warning: symbol 'eserial3_putc' was not declared. > Should it be static? > serial_ns16550.c:228:1: warning: symbol 'eserial3_puts' was not declared. > Should it be static? > serial_ns16550.c:231:1: warning: symbol 'eserial4_init' was not declared. > Should it be static? > serial_ns16550.c:231:1: warning: symbol 'eserial4_setbrg' was not declared. > Should it be static? > serial_ns16550.c:231:1: warning: symbol 'eserial4_getc' was not declared. > Should it be static? > serial_ns16550.c:231:1: warning: symbol 'eserial4_tstc' was not declared. > Should it be static? > serial_ns16550.c:231:1: warning: symbol 'eserial4_putc' was not declared. > Should it be static? > serial_ns16550.c:231:1: warning: symbol 'eserial4_puts' was not declared. > Should it be static? > > Signed-off-by: Kim Phillips 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] [U-Boot,27/32] drivers/i2c/fsl_i2c.c: sparse fix
On Tue, Oct 16, 2012 at 02:28:43PM -, Kim Phillips wrote: > fsl_i2c.c:217:14: warning: symbol 'get_i2c_clock' was not declared. Should it > be static? > > Signed-off-by: Kim Phillips > Acked-by: Heiko Schocher 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 V4 1/3] FAT: remove cur_part_nr
On Wed, Oct 17, 2012 at 10:44:57AM -0600, Stephen Warren wrote: > From: Stephen Warren > > A future patch will implement the more standard filesystem API > fat_set_blk_dev(). This API has no way to know which partition number > the partition represents. Equally, future DM rework will make the > concept of partition number harder to pass around. > > So, simply remove cur_part_nr from fat.c; its only use is in a > diagnostic printf, and the context where it's printed should make it > obvious which partition is referred to anyway (since the partition ID > would come from the user command-line that caused it). > > Signed-off-by: Stephen Warren > --- > v4: New patch: Dropped addition of part number of disk_partition_t, and > replaced it with this patch. For the series, 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 0/2] Standardize on run-time board ID variables
Hi,
On Wed, Oct 24, 2012 at 12:05 PM, Stephen Warren wrote:
> On 10/24/2012 12:41 PM, Tom Rini wrote:
>> On Wed, Oct 24, 2012 at 11:50:38AM -0600, Stephen Warren wrote:
>>> On 10/24/2012 11:28 AM, Tom Rini wrote:
Hey all,
I've been thinking about one of the problems we need to solve
over in TI AM335x land and that is given that we support a
number of different boards with a single binary (and we have an
i2c eeprom that tells us what board and revision we are on),
the user needs to be able to easily determine what board we are
on so they know what dtb file to load so they can boot. To
this end I've added CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG to the
README which says when set we have board_name and board_rev set
at run-time. Then for am335x[1]
>>>
>>> With CONFIG_ENV_VARS_UBOOT_CONFIG set, there's a environment
>>> variable named $board that indicates which board U-Boot is
>>> running on (and other related variables). The idea is that the
>>> user can:
>>>
>>> fsload ${devtype} ${devnum}:${rootpart} ${fdt_addr_r} \
>>> /boot/${soc}-${board}.dtb
>>>
>>> Now, CONFIG_ENV_VARS_UBOOT_CONFIG sets $board at compile-time,
>>> since the config variable was created in the context on a U-Boot
>>> that runs on a single board. However, I see no reason why we
>>> can't maintain the user-visible results of this config option
>>> even in other cases, so that everything is consistent to the
>>> user
>>
>> This works assuming that board maps to the device tree name. A bit
>> more below...
>
> True. I've made sure of that for Tegra.
>
>>> To that end, can we make CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG set
>>> $board instead of $board_name?
>>
>> I had talked with Joe about this on IRC briefly and he seemed to
>> be against overwriting "board"
>
> Why is that? Perhaps alternatively, CONFIG_ENV_VARS_UBOOT_CONFIG
> should set both board and a default value for board_name.
>
>>> Adding $board_rev sounds like a very good idea; the filename in
>>> the above command could be modified to:
>>>
>>> ${soc}-${board}${boardrev}.dtb
>>
>> Indeed, I know we'll need to do this in the future for one of the
>> boards in this family.
>>
>>> Or, do you think it'd be better for boot.scr to always reference
>>> $fdtfile, and so modify Tegra's default environment to derive
>>> $fdtfile from $soc, $board, $boardrev?
>>
>> Or uEnv.txt, but yes, fdtfile seems to be the standard variable
>> name for the device tree to use.
>
> Ah, I do see quite a few U-Boot config headers defining that.
>
>> Doing something to derive this also means that custom development
>> can be a bit easier too since you can just set fdtfile directly and
>> work out the logic for auto-detection later.
>
> Hmm. So I can't really put the following into Tegra's default environment:
>
> "fdtfile=${soc}-${board}${boardrev}.dtb"
>
> ... since that would require any use of "${fdtfile}" in a command to
> first expand fdtfile itself, then expand it a second time to pick up
> the actual soc/board/... values, and that's not how the shell works.
>
> That implies that e.g. Tegra's scriptboot (seed BOOTCMDS_COMMON in
> include/configs/tegra-common-post.h) would need to do something like:
>
> setenv fdtfile ${soc}-${board}${boardrev}.dtb
>
> ... before executing the loaded boot.scr. But then, how would it know
> whether to do that, or whether the user wanted to override the fdtfile
> value?
>
> In theory, I could do the following in Tegra's default environment:
>
> "fdtfile=" CONFIG_SYS_SOC "-" CONFIG_SYS_BOARD" ".dtb"
>
> But then that wouldn't allow for the fdtfile value to vary at run-time
> based on $boardrev.
I did create a patch to make environment variables recursive. It is a
right pain to have to 'setenv' them to get them to work in this way.
However I wasn't really sure how to control it. Can we just move to
recursive environment variable evaluation, or would that break things?
Perhaps a CONFIG_ option?
Re this discussion, if the board itself can detect its revision then
great. If it can't, then presumably the factory process writes the
correct fdt to the board during manufacture.
>
>> Also not hard-coding in the path makes it easier for whichever
>> distro to fill in that logic.
>
> By the path, do you mean "/boot", or the way the filename is
> construced? "/boot" in my fsload example above was a quote from the
> boot.scr I use, not something U-Boot provides, so I'd expect distros
> could customize it to their needs. If you mean the filename - I'd
> certainly advocate enforcing that U-Boot and the kernel board names
> and DT filenames be in sync.
>
>>
>>> (This general discussion might usefully happen on the
>>> cross-distro mailing list too?)
>>
>> Yes. Where? :)
>
> cross-dis...@lists.linaro.org
> __
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 20/20] x86: config: Enable AHCI support for coreboot
Hi Graeme,
On Mon, Oct 22, 2012 at 11:33 PM, Graeme Russ wrote:
> Hi Simon,
>
> On Oct 23, 2012 4:42 PM, "Simon Glass" wrote:
>>
>> Hi Graeme,
>>
>> On Mon, Oct 22, 2012 at 10:38 PM, Graeme Russ
>> wrote:
>> > Hi Simon,
>> >
>> > On Tue, Oct 23, 2012 at 4:34 PM, Simon Glass wrote:
>> >> Hi Graeme,
>> >>
>> >> On Thu, Oct 18, 2012 at 9:12 PM, Graeme Russ
>> >> wrote:
>> >>> Hi Simon,
>> >>>
>> >>> On Fri, Oct 19, 2012 at 2:45 PM, Simon Glass wrote:
>> Enable AHCI driver for Intel SATA devices.
>>
>> Signed-off-by: Simon Glass
>> ---
>> include/configs/coreboot.h | 21 +
>> 1 files changed, 21 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/configs/coreboot.h b/include/configs/coreboot.h
>> index 3df085b..968a9c5 100644
>> --- a/include/configs/coreboot.h
>> +++ b/include/configs/coreboot.h
>> @@ -45,6 +45,27 @@
>> #undef CONFIG_WATCHDOG
>> #undef CONFIG_HW_WATCHDOG
>>
>> +/* SATA AHCI storage */
>> +
>> +#define CONFIG_SCSI_AHCI
>> +
>> +#ifdef CONFIG_SCSI_AHCI
>> +#define CONFIG_SATA_INTEL 1
>> +#define CONFIG_SCSI_DEV_LIST {PCI_VENDOR_ID_INTEL, \
>> + PCI_DEVICE_ID_INTEL_NM10_AHCI}, \
>> + {PCI_VENDOR_ID_INTEL, \
>> + PCI_DEVICE_ID_INTEL_COUGARPOINT_AHCI_MOBILE},
>> \
>> + {PCI_VENDOR_ID_INTEL, \
>> +
>> PCI_DEVICE_ID_INTEL_COUGARPOINT_AHCI_SERIES6}, \
>> + {PCI_VENDOR_ID_INTEL, \
>> + PCI_DEVICE_ID_INTEL_PANTHERPOINT_AHCI_MOBILE}
>> >>>
>> >>> This implies every coreboot board is Intel. When you start to
>> >>> introduce hardware specific U-Boot components, you need to introduce a
>> >>> board specific config file.
>> >>>
>> >>> Would it be better to have a CONFIG_X86_COREBOOT and a coreboot 'SoC'
>> >>> and no coreboot board?
>> >>
>> >> I am not sure about using the SOC - after all we might need that
>> >> concept soon on x86. Maybe we should create a new board config that
>> >> includes coreboot.h?
>> >
>> > SoC was the wrong abstraction - I think coreboot library is better
>> > (see my email I just sent)
>>
>> Yes, ok. I can do a patch to move it, or do you want to?
>
> I think it would be best for you to move it.
>
> Presumably
>> this would come in after the patches that are already pending on the
>> mailing list?
>
> Yes. No big hurry
>
>>
>> >
>> >> Having said that I'm not sure how important it is right now. So far,
>> >> coreboot.h is actually a particular class of boards, all Intel based.
>> >> We can name it whatever we want when we actually have other boards
>> >> which are coreboot but not Intel. Up to you
>> >
>> > I plan on doing dev work on a AMD E350 based board 'soon'. The E350 is
>> > already supported by coreboot, so I'm planning on getting coreboot
>> > ported for this board and then run U-Boot from coreboot. So we can no
>> > longer assume all coreboot boards will be Intel based.
>>
>> Sounds good! Shall we rename coreboot.h to something like
>> chromebook-x86.h?
>
> Even better would be to use the model name (which I assume would make the
> x86 tag redundant)
Well, the model is very device-specific. So far as U-Boot cares all
the models are basically the same. What differences there are are
taken care of by device tree differences. This is try on ARM for
machines which share the some SOC, and true for basically all x86
platforms.
Regards,
Simon
>
> Regards,
>
> Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 03/14] fdt: Add fdtdec_decode_region() to decode memory region
A memory region has a start and a size and is often specified in
a node by a 'reg' property. Add a function to decode this information
from the fdt.
Signed-off-by: Simon Glass
---
include/fdtdec.h | 19 +++
lib/fdtdec.c | 17 +
2 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index e828662..341e6a1 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -40,10 +40,12 @@
typedef u64 fdt_addr_t;
#define FDT_ADDR_T_NONE (-1ULL)
#define fdt_addr_to_cpu(reg) be64_to_cpu(reg)
+#define fdt_size_to_cpu(reg) be64_to_cpu(reg)
#else
typedef u32 fdt_addr_t;
#define FDT_ADDR_T_NONE (-1U)
#define fdt_addr_to_cpu(reg) be32_to_cpu(reg)
+#define fdt_size_to_cpu(reg) be32_to_cpu(reg)
#endif
/* Information obtained about memory from the FDT */
@@ -408,4 +410,21 @@ int fdtdec_get_byte_array(const void *blob, int node,
const char *prop_name,
*/
const u8 *fdtdec_locate_byte_array(const void *blob, int node,
const char *prop_name, int count);
+
+/**
+ * Look up a property in a node which contains a memory region address and
+ * size. Then return a pointer to this address.
+ *
+ * The property must hold one address with a length. This is only tested on
+ * 32-bit machines.
+ *
+ * @param blob FDT blob
+ * @param node node to examine
+ * @param prop_namename of property to find
+ * @param ptrp returns pointer to region, or NULL if no address
+ * @param size returns size of region
+ * @return 0 if ok, -1 on error (propery not found)
+ */
+int fdtdec_decode_region(const void *blob, int node,
+ const char *prop_name, void **ptrp, size_t *size);
#endif
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 2d60c8a..5570972 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -542,3 +542,20 @@ char *fdtdec_get_config_string(const void *blob, const
char *prop_name)
return (char *)nodep;
}
+
+int fdtdec_decode_region(const void *blob, int node,
+ const char *prop_name, void **ptrp, size_t *size)
+{
+ const fdt_addr_t *cell;
+ int len;
+
+ debug("%s: %s\n", __func__, prop_name);
+ cell = fdt_getprop(blob, node, prop_name, &len);
+ if (!cell || (len != sizeof(fdt_addr_t) * 2))
+ return -1;
+
+ *ptrp = (void *)fdt_addr_to_cpu(*cell);
+ *size = fdt_size_to_cpu(cell[1]);
+ debug("%s: size=%zx\n", __func__, *size);
+ 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 06/14] fdt: Export fdtdec_lookup() and fix the name
The name of this function is not consistent, so fix it, and export
the function for external use.
Signed-off-by: Simon Glass
---
include/fdtdec.h | 13 +
lib/fdtdec.c |2 +-
2 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index e566e47..3f1840c 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -110,6 +110,19 @@ int fdtdec_next_alias(const void *blob, const char *name,
enum fdt_compat_id id, int *upto);
/**
+ * Find the compatible ID for a given node.
+ *
+ * Generally each node has at least one compatible string attached to it.
+ * This function looks through our list of known compatible strings and
+ * returns the corresponding ID which matches the compatible string.
+ *
+ * @param blob FDT blob to use
+ * @param node Node containing compatible string to find
+ * @return compatible ID, or COMPAT_UNKNOWN if we cannot find a match
+ */
+enum fdt_compat_id fdtdec_lookup(const void *blob, int node);
+
+/**
* Look in the FDT for an alias with the given name and return its node.
*
* @param blob FDT blob
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 16435b7..efe9afe 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -128,7 +128,7 @@ int fdtdec_get_is_enabled(const void *blob, int node)
return 1;
}
-enum fdt_compat_id fd_dec_lookup(const void *blob, int node)
+enum fdt_compat_id fdtdec_lookup(const void *blob, int node)
{
enum fdt_compat_id id;
--
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/14] fdt: Add fdtdec_get_uint64 to decode a 64-bit value from a property
From: Che-Liang Chiou
It decodes a 64-bit value from a property that is at least 8 bytes long.
Signed-off-by: Che-Liang Chiou
Signed-off-by: Simon Glass
---
include/fdtdec.h | 15 +++
lib/fdtdec.c | 13 +
2 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 82fdb99..12f73a7 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -191,6 +191,21 @@ s32 fdtdec_get_int(const void *blob, int node, const char
*prop_name,
s32 default_val);
/**
+ * Look up a 64-bit integer property in a node and return it. The property
+ * must have at least 8 bytes of data (2 cells). The first two cells are
+ * concatenated to form a 8 bytes value, where the first cell is top half and
+ * the second cell is bottom half.
+ *
+ * @param blob FDT blob
+ * @param node node to examine
+ * @param prop_namename of property to find
+ * @param default_val default value to return if the property is not found
+ * @return integer value, if found, or default_val if not
+ */
+uint64_t fdtdec_get_uint64(const void *blob, int node, const char *prop_name,
+ uint64_t default_val);
+
+/**
* Checks whether a node is enabled.
* This looks for a 'status' property. If this exists, then returns 1 if
* the status is 'ok' and 0 otherwise. If there is no status property,
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index fbb2827..6c417d2 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -111,6 +111,19 @@ s32 fdtdec_get_int(const void *blob, int node, const char
*prop_name,
return default_val;
}
+uint64_t fdtdec_get_uint64(const void *blob, int node, const char *prop_name,
+ uint64_t default_val)
+{
+ const uint64_t *cell64;
+ int length;
+
+ cell64 = fdt_getprop(blob, node, prop_name, &length);
+ if (!cell64 || length < sizeof(*cell64))
+ return default_val;
+
+ return fdt64_to_cpu(*cell64);
+}
+
int fdtdec_get_is_enabled(const void *blob, int node)
{
const char *cell;
--
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/14] fdt: Export fdtdec_find_alias_node() function
This function is useful outside fdtdec, so export it.
Signed-off-by: Simon Glass
---
include/fdtdec.h |9 +
lib/fdtdec.c |6 +++---
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index e70714b..e566e47 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -110,6 +110,15 @@ int fdtdec_next_alias(const void *blob, const char *name,
enum fdt_compat_id id, int *upto);
/**
+ * Look in the FDT for an alias with the given name and return its node.
+ *
+ * @param blob FDT blob
+ * @param name alias name to look up
+ * @return node offset if found, or an error code < 0 otherwise
+ */
+int fdtdec_find_alias_node(const void *blob, const char *name);
+
+/**
* Find the next compatible node for a peripheral.
*
* Do the first call with node = 0. This function will return a pointer to
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 32f03cc..16435b7 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -59,12 +59,12 @@ const char *fdtdec_get_compatible(enum fdt_compat_id id)
* @param name alias name to look up
* @return node offset if found, or an error code < 0 otherwise
*/
-static int find_alias_node(const void *blob, const char *name)
+int fdtdec_find_alias_node(const void *blob, const char *name)
{
const char *path;
int alias_node;
- debug("find_alias_node: %s\n", name);
+ debug("%s: %s\n", __func__, name);
alias_node = fdt_path_offset(blob, "/aliases");
if (alias_node < 0)
return alias_node;
@@ -171,7 +171,7 @@ int fdtdec_next_alias(const void *blob, const char *name,
/* snprintf() is not available */
assert(strlen(name) < MAX_STR_LEN);
sprintf(str, "%.*s%d", MAX_STR_LEN, name, *upto);
- node = find_alias_node(blob, str);
+ node = fdtdec_find_alias_node(blob, str);
if (node < 0)
return node;
err = fdt_node_check_compatible(blob, node, compat_names[id]);
--
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/14] fdt: Add function to get a config string from device tree
Add a function to look up a configuration string such as board name
and returns its value. We look in the "/config" node for this.
Signed-off-by: Simon Glass
---
include/fdtdec.h | 10 ++
lib/fdtdec.c | 28 ++--
2 files changed, 28 insertions(+), 10 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index d880fe8..e828662 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -367,6 +367,16 @@ int fdtdec_setup_gpio(struct fdt_gpio_state *gpio);
int fdtdec_get_config_int(const void *blob, const char *prop_name,
int default_val);
+/**
+ * Look in the FDT for a config item with the given name and return its value
+ * as a string.
+ *
+ * @param blob FDT blob
+ * @param prop_name property name to look up
+ * @returns property string, NULL on error.
+ */
+char *fdtdec_get_config_string(const void *blob, const char *prop_name);
+
/*
* Look up a property in a node and return its contents in a byte
* array of given length. The property must have at least enough data for
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 1f50022..2d60c8a 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -513,16 +513,6 @@ const u8 *fdtdec_locate_byte_array(const void *blob, int
node,
return cell;
}
-/**
- * Look in the FDT for a config item with the given name and return its value
- * as a 32-bit integer. The property must have at least 4 bytes of data. The
- * value of the first cell is returned.
- *
- * @param blob FDT blob to use
- * @param prop_nameNode property name
- * @param default_val default value to return if the property is not found
- * @return integer value, if found, or default_val if not
- */
int fdtdec_get_config_int(const void *blob, const char *prop_name,
int default_val)
{
@@ -534,3 +524,21 @@ int fdtdec_get_config_int(const void *blob, const char
*prop_name,
return default_val;
return fdtdec_get_int(blob, config_node, prop_name, default_val);
}
+
+char *fdtdec_get_config_string(const void *blob, const char *prop_name)
+{
+ const char *nodep;
+ int nodeoffset;
+ int len;
+
+ debug("%s: %s\n", __func__, prop_name);
+ nodeoffset = fdt_path_offset(blob, "/config");
+ if (nodeoffset < 0)
+ return NULL;
+
+ nodep = fdt_getprop(blob, nodeoffset, prop_name, &len);
+ if (!nodep)
+ return NULL;
+
+ return (char *)nodep;
+}
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 01/14] fdt: Add function to get config int from device tree
From: Abhilash Kesavan
Add a function to look up a configuration item such as machine id
and return its value.
Note: The code has been taken as is from the Chromium u-boot development
tree and needs Simon Glass' sign-off.
Signed-off-by: Abhilash Kesavan
Signed-off-by: Simon Glass
---
include/fdtdec.h | 13 +
lib/fdtdec.c | 22 ++
2 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 0b14075..d880fe8 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -354,6 +354,19 @@ int fdtdec_decode_gpio(const void *blob, int node, const
char *prop_name,
*/
int fdtdec_setup_gpio(struct fdt_gpio_state *gpio);
+/**
+ * Look in the FDT for a config item with the given name and return its value
+ * as a 32-bit integer. The property must have at least 4 bytes of data. The
+ * value of the first cell is returned.
+ *
+ * @param blob FDT blob to use
+ * @param prop_nameNode property name
+ * @param default_val default value to return if the property is not found
+ * @return integer value, if found, or default_val if not
+ */
+int fdtdec_get_config_int(const void *blob, const char *prop_name,
+ int default_val);
+
/*
* Look up a property in a node and return its contents in a byte
* array of given length. The property must have at least enough data for
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 4c23f45..1f50022 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -512,3 +512,25 @@ const u8 *fdtdec_locate_byte_array(const void *blob, int
node,
return NULL;
return cell;
}
+
+/**
+ * Look in the FDT for a config item with the given name and return its value
+ * as a 32-bit integer. The property must have at least 4 bytes of data. The
+ * value of the first cell is returned.
+ *
+ * @param blob FDT blob to use
+ * @param prop_nameNode property name
+ * @param default_val default value to return if the property is not found
+ * @return integer value, if found, or default_val if not
+ */
+int fdtdec_get_config_int(const void *blob, const char *prop_name,
+ int default_val)
+{
+ int config_node;
+
+ debug("%s: %s\n", __func__, prop_name);
+ config_node = fdt_path_offset(blob, "/config");
+ if (config_node < 0)
+ return default_val;
+ return fdtdec_get_int(blob, config_node, prop_name, default_val);
+}
--
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/14] fdt: Add polarity-aware gpio functions to fdtdec
From: Sean Paul
Add get and set gpio functions to fdtdec that take into account the
polarity field in fdtdec_gpio_state.flags.
Signed-off-by: Sean Paul
Signed-off-by: Simon Glass
---
include/fdtdec.h | 16
lib/fdtdec.c | 20
2 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 12f73a7..17daa99 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -90,6 +90,22 @@ struct fdt_gpio_state {
#define fdt_gpio_isvalid(x) ((x)->gpio != FDT_GPIO_NONE)
/**
+ * Read the GPIO taking into account the polarity of the pin.
+ *
+ * @param gpio pointer to the decoded gpio
+ * @return value of the gpio if successful, < 0 if unsuccessful
+ */
+int fdtdec_get_gpio(struct fdt_gpio_state *gpio);
+
+/**
+ * Write the GPIO taking into account the polarity of the pin.
+ *
+ * @param gpio pointer to the decoded gpio
+ * @return 0 if successful
+ */
+int fdtdec_set_gpio(struct fdt_gpio_state *gpio, int val);
+
+/**
* Find the next numbered alias for a peripheral. This is used to enumerate
* all the peripherals of a certain type.
*
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 6c417d2..91ba558 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -487,6 +487,26 @@ int fdtdec_decode_gpio(const void *blob, int node, const
char *prop_name,
return err == 1 ? 0 : err;
}
+int fdtdec_get_gpio(struct fdt_gpio_state *gpio)
+{
+ int val;
+
+ if (!fdt_gpio_isvalid(gpio))
+ return -1;
+
+ val = gpio_get_value(gpio->gpio);
+ return gpio->flags & FDT_GPIO_ACTIVE_LOW ? val ^ 1 : val;
+}
+
+int fdtdec_set_gpio(struct fdt_gpio_state *gpio, int val)
+{
+ if (!fdt_gpio_isvalid(gpio))
+ return -1;
+
+ val = gpio->flags & FDT_GPIO_ACTIVE_LOW ? val ^ 1 : val;
+ return gpio_set_value(gpio->gpio, val);
+}
+
int fdtdec_setup_gpio(struct fdt_gpio_state *gpio)
{
/*
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 04/14] fdt: Add function for decoding multiple gpios globally available
From: Abhilash Kesavan
Samsung's SDHCI bindings require multiple gpios to be parsed and
configured at a time. Export the already available fdtdec_decode_gpios
for this purpose.
Signed-off-by: Abhilash Kesavan
Commit-Ready: Che-Liang Chiou
Signed-off-by: Simon Glass
---
include/fdtdec.h | 16
lib/fdtdec.c |5 ++---
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 341e6a1..e70714b 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -345,6 +345,22 @@ int fdtdec_decode_gpio(const void *blob, int node, const
char *prop_name,
struct fdt_gpio_state *gpio);
/**
+ * Decode a list of GPIOs from an FDT. This creates a list of GPIOs with no
+ * terminating item.
+ *
+ * @param blob FDT blob to use
+ * @param node Node to look at
+ * @param prop_nameNode property name
+ * @param gpio Array of gpio elements to fill from FDT. This will be
+ * untouched if either 0 or an error is returned
+ * @param max_countMaximum number of elements allowed
+ * @return number of GPIOs read if ok, -FDT_ERR_BADLAYOUT if max_count would
+ * be exceeded, or -FDT_ERR_NOTFOUND if the property is missing.
+ */
+int fdtdec_decode_gpios(const void *blob, int node, const char *prop_name,
+ struct fdt_gpio_state *gpio, int max_count);
+
+/**
* Set up a GPIO pin according to the provided gpio information. At present
this
* just requests the GPIO.
*
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 5570972..32f03cc 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -426,9 +426,8 @@ int fdtdec_get_bool(const void *blob, int node, const char
*prop_name)
* @return number of GPIOs read if ok, -FDT_ERR_BADLAYOUT if max_count would
* be exceeded, or -FDT_ERR_NOTFOUND if the property is missing.
*/
-static int fdtdec_decode_gpios(const void *blob, int node,
- const char *prop_name, struct fdt_gpio_state *gpio,
- int max_count)
+int fdtdec_decode_gpios(const void *blob, int node, const char *prop_name,
+ struct fdt_gpio_state *gpio, int max_count)
{
const struct fdt_property *prop;
const u32 *cell;
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 12/14] fdt: Allow device tree to specify secure booting
From: Doug Anderson
When secure booting is chosen:
* The u-boot shell is never invoked during boot--we just do a simple
table lookup to find the command. This means we could even remove
the shell parsing from u-boot and still be able to boot.
* The boot command can't be interruped.
* Failure doesn't cause us to fall back to the shell.
Signed-off-by: Gabe Black
Signed-off-by: Doug Anderson
Signed-off-by: Simon Glass
---
common/main.c | 62 +
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/common/main.c b/common/main.c
index cf1b5f9..03c63b4 100644
--- a/common/main.c
+++ b/common/main.c
@@ -283,6 +283,59 @@ int abortboot(int bootdelay)
# endif/* CONFIG_AUTOBOOT_KEYED */
#endif /* CONFIG_BOOTDELAY >= 0 */
+/*
+ * Runs the given boot command securely. Specifically:
+ * - Doesn't run the command with the shell (run_command or
parse_string_outer),
+ * since that's a lot of code surface that an attacker might exploit.
+ * Because of this, we don't do any argument parsing--the secure boot command
+ * has to be a full-fledged u-boot command.
+ * - Doesn't check for keypresses before booting, since that could be a
+ * security hole; also disables Ctrl-C.
+ * - Doesn't allow the command to return.
+ *
+ * Upon any failures, this function will drop into an infinite loop after
+ * printing the error message to console.
+ */
+
+#if defined(CONFIG_BOOTDELAY) && (CONFIG_BOOTDELAY >= 0) && \
+ defined(CONFIG_OF_CONTROL)
+static void secure_boot_cmd(char *cmd)
+{
+ cmd_tbl_t *cmdtp;
+ int rc;
+
+ if (!cmd) {
+ printf("## Error: Secure boot command not specified\n");
+ goto err;
+ }
+
+ /* Disable Ctrl-C just in case some command is used that checks it. */
+ disable_ctrlc(1);
+
+ /* Find the command directly. */
+ cmdtp = find_cmd(cmd);
+ if (!cmdtp) {
+ printf("## Error: \"%s\" not defined\n", cmd);
+ goto err;
+ }
+
+ /* Run the command, forcing no flags and faking argc and argv. */
+ rc = (cmdtp->cmd)(cmdtp, 0, 1, &cmd);
+
+ /* Shouldn't ever return from boot command. */
+ printf("## Error: \"%s\" returned (code %d)\n", cmd, rc);
+
+err:
+ /*
+* Not a whole lot to do here. Rebooting won't help much, since we'll
+* just end up right back here. Just loop.
+*/
+ hang();
+}
+
+#endif /* CONFIG_OF_CONTROL */
+
+
//
void main_loop (void)
@@ -397,6 +450,15 @@ void main_loop (void)
env = fdtdec_get_config_string(gd->fdt_blob, "bootcmd");
if (env)
s = env;
+
+ /*
+* If the bootsecure option was chosen, use secure_boot_cmd().
+* Always use 'env' in this case, since bootsecure requres that the
+* bootcmd was specified in the FDT too.
+*/
+ if (fdtdec_get_config_int(gd->fdt_blob, "bootsecure", 0))
+ secure_boot_cmd(env);
+
#endif /* CONFIG_OF_CONTROL */
debug ("### main_loop: bootcmd=\"%s\"\n", s ? s : "");
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 11/14] fdt: Tell the FDT library where the device tree is
From: Gabe Black This change adds a call to set_working_fdt_addr near the end of u-boot initialization which tells the fdt command/library where the device tree is. This makes it possible to use the fdt command to look at the active device tree since otherwise there would be no way to know what address it was at to set things up manually. Signed-off-by: Gabe Black Signed-off-by: Simon Glass --- common/main.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/common/main.c b/common/main.c index 23a68ee..cf1b5f9 100644 --- a/common/main.c +++ b/common/main.c @@ -45,6 +45,10 @@ #include #endif +#ifdef CONFIG_OF_LIBFDT +#include +#endif /* CONFIG_OF_LIBFDT */ + #include #include #include @@ -418,6 +422,10 @@ void main_loop (void) #endif /* CONFIG_MENUKEY */ #endif /* CONFIG_BOOTDELAY */ +#if defined CONFIG_OF_CONTROL + set_working_fdt_addr((void *)gd->fdt_blob); +#endif /* CONFIG_OF_CONTROL */ + /* * Main Loop for Monitor Command Processing */ -- 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/14] fdt: Add function to read boolean property
From: Gabe Black
Signed-off-by: Vincent Palatin
Commit-Ready: Vincent Palatin
Commit-Ready: Gabe Black
Signed-off-by: Simon Glass
---
include/fdtdec.h | 10 ++
lib/fdtdec.c | 14 ++
2 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 3f1840c..82fdb99 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -408,6 +408,16 @@ int fdtdec_get_config_int(const void *blob, const char
*prop_name,
int default_val);
/**
+ * Look in the FDT for a config item with the given name
+ * and return whether it exists.
+ *
+ * @param blob FDT blob
+ * @param prop_nameproperty name to look up
+ * @return 1, if it exists, or 0 if not
+ */
+int fdtdec_get_config_bool(const void *blob, const char *prop_name);
+
+/**
* Look in the FDT for a config item with the given name and return its value
* as a string.
*
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index efe9afe..fbb2827 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -524,6 +524,20 @@ int fdtdec_get_config_int(const void *blob, const char
*prop_name,
return fdtdec_get_int(blob, config_node, prop_name, default_val);
}
+int fdtdec_get_config_bool(const void *blob, const char *prop_name)
+{
+ int config_node;
+ const void *prop;
+
+ debug("%s: %s\n", __func__, prop_name);
+ config_node = fdt_path_offset(blob, "/config");
+ if (config_node < 0)
+ return 0;
+ prop = fdt_get_property(blob, config_node, prop_name, NULL);
+
+ return prop != NULL;
+}
+
char *fdtdec_get_config_string(const void *blob, const char *prop_name)
{
const char *nodep;
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 13/14] fdt: Add option to default to most compatible conf in a fit image
From: Gabe Black
When booting a fit image with multiple configurations, the user either has to
specify which configuration to use explicitly, or there has to be a default
defined which is chosen automatically. This change adds an option to change
that behavior so that a configuration can be selected explicitly, or the
configuration which has the device tree that claims to be compatible with the
earliest item in U-Boot's device tree.
In other words, if U-Boot claimed to be compatible with A, B, and then C, and
the configurations claimed to be compatible with A, D and B, D and D, E, the
first configuration, A, D, would be chosen. Both the first and second
configurations match, but the first one matches a more specific entry in
U-Boot's device tree. The order in the kernel's device tree is ignored.
Signed-off-by: Gabe Black
Commit-Ready: Gabe Black
Signed-off-by: Simon Glass
---
README | 11 +
common/cmd_bootm.c | 11 +
common/image.c | 127
include/image.h|1 +
4 files changed, 150 insertions(+), 0 deletions(-)
diff --git a/README b/README
index 69da2b8..3912150 100644
--- a/README
+++ b/README
@@ -2582,6 +2582,17 @@ FIT uImage format:
-150 common/cmd_nand.c Incorrect FIT image format
151 common/cmd_nand.c FIT image format OK
+- FIT image support:
+ CONFIG_FIT
+ Enable support for the FIT uImage format.
+
+ CONFIG_FIT_BEST_MATCH
+ When no configuration is explicitly selected, default to the
+ one whose fdt's compatibility field best matches that of
+ U-Boot itself. A match is considered "best" if it matches the
+ most specific compatibility entry of U-Boot's fdt's root node.
+ The order of entries in the configuration's fdt is ignored.
+
- Standalone program support:
CONFIG_STANDALONE_LOAD_ADDR
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 83fa5d7..4e6042c 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -949,8 +949,19 @@ static void *boot_get_kernel(cmd_tbl_t *cmdtp, int flag,
int argc,
* node
*/
bootstage_mark(BOOTSTAGE_ID_FIT_NO_UNIT_NAME);
+#ifdef CONFIG_FIT_BEST_MATCH
+ if (fit_uname_config)
+ cfg_noffset =
+ fit_conf_get_node(fit_hdr,
+ fit_uname_config);
+ else
+ cfg_noffset =
+ fit_conf_find_compat(fit_hdr,
+gd->fdt_blob);
+#else
cfg_noffset = fit_conf_get_node(fit_hdr,
fit_uname_config);
+#endif
if (cfg_noffset < 0) {
bootstage_error(BOOTSTAGE_ID_FIT_NO_UNIT_NAME);
return NULL;
diff --git a/common/image.c b/common/image.c
index 750a98b..8877395 100644
--- a/common/image.c
+++ b/common/image.c
@@ -3049,6 +3049,133 @@ int fit_check_format(const void *fit)
return 1;
}
+
+/**
+ * fit_conf_find_compat
+ * @fit: pointer to the FIT format image header
+ * @fdt: pointer to the device tree to compare against
+ *
+ * fit_conf_find_compat() attempts to find the configuration whose fdt is the
+ * most compatible with the passed in device tree.
+ *
+ * Example:
+ *
+ * / o image-tree
+ * |-o images
+ * | |-o fdt@1
+ * | |-o fdt@2
+ * |
+ * |-o configurations
+ * |-o config@1
+ * | |-fdt = fdt@1
+ * |
+ * |-o config@2
+ * |-fdt = fdt@2
+ *
+ * / o U-Boot fdt
+ * |-compatible = "foo,bar", "bim,bam"
+ *
+ * / o kernel fdt1
+ * |-compatible = "foo,bar",
+ *
+ * / o kernel fdt2
+ * |-compatible = "bim,bam", "baz,biz"
+ *
+ * Configuration 1 would be picked because the first string in U-Boot's
+ * compatible list, "foo,bar", matches a compatible string in the root of fdt1.
+ * "bim,bam" in fdt2 matches the second string which isn't as good as fdt1.
+ *
+ * returns:
+ * offset to the configuration to use if one was found
+ * -1 otherwise
+ */
+int fit_conf_find_compat(const void *fit, const void *fdt)
+{
+ int ndepth = 0;
+ int noffset, confs_noffset, images_noffset;
+ const void *fdt_compat;
+ int fdt_compat_len;
+ int best_match_offset = 0;
+ int best_match_pos = 0;
+
+ confs_noffset = fdt_path_offset(fit, FIT_CONFS_PATH);
+ images_noffset = fdt_path_offset(fit, FIT_IMAGES_PATH);
+ if (confs_noffset < 0 || images_noffset < 0) {
+ debug("Can't find configurations or images nodes.\n");
+ return -1;
+ }
+
+ fdt_compat = fdt_getprop(fdt, 0, "compatible", &fdt_compat_len);
+
[U-Boot] [PATCH 14/14] fdt: Set kernaddr if fdt indicates a kernel is present
If kernel-offset is specified in the fdt, set an environment variable
so that scripts can access the attached kernel.
This can be used by a packaging program to tell U-Boot about a kernel
that has been downloaded alongside U-Boot. The value in the fdt is
the offset of the kernel from the start of the U-Boot image, so we can
find it just by adding CONFIG_SYS_TEXT_BASE.
It is then fairly easy to put something like this in the environment
variables in the board header file:
"if test ${kernaddr} != \"\"; then "\
"echo \"Using bundled kernel\"; "\
"bootm ${kernaddr};" \
"fi; "\
/* rest of boot sequence follows here */
Signed-off-by: Simon Glass
---
common/main.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/common/main.c b/common/main.c
index 03c63b4..3137b75 100644
--- a/common/main.c
+++ b/common/main.c
@@ -333,6 +333,20 @@ err:
hang();
}
+static void process_fdt_options(const void *blob)
+{
+ ulong addr;
+
+ /* Add an env variable to point to a kernel payload, if available */
+ addr = fdtdec_get_config_int(gd->fdt_blob, "kernel-offset", 0);
+ if (addr)
+ setenv_addr("kernaddr", (void *)(CONFIG_SYS_TEXT_BASE + addr));
+
+ /* Add an env variable to point to a root disk, if available */
+ addr = fdtdec_get_config_int(gd->fdt_blob, "rootdisk-offset", 0);
+ if (addr)
+ setenv_addr("rootaddr", (void *)(CONFIG_SYS_TEXT_BASE + addr));
+}
#endif /* CONFIG_OF_CONTROL */
@@ -451,6 +465,8 @@ void main_loop (void)
if (env)
s = env;
+ process_fdt_options(gd->fdt_blob);
+
/*
* If the bootsecure option was chosen, use secure_boot_cmd().
* Always use 'env' in this case, since bootsecure requres that the
--
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/14] fdt: Load boot command from device tree
From: Che-Liang Chiou
Load boot command from /config/bootcmd of device tree if present.
Signed-off-by: Tom Wai-Hong Tam
Signed-off-by: Che-Liang Chiou
Signed-off-by: Simon Glass
---
common/main.c | 16 +++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/common/main.c b/common/main.c
index 9507cec..23a68ee 100644
--- a/common/main.c
+++ b/common/main.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
#ifdef CONFIG_MODEM_SUPPORT
@@ -40,6 +41,10 @@
#include
#endif
+#ifdef CONFIG_OF_CONTROL
+#include
+#endif
+
#include
#include
#include
@@ -284,7 +289,10 @@ void main_loop (void)
int rc = 1;
int flag;
#endif
-
+#if defined(CONFIG_BOOTDELAY) && (CONFIG_BOOTDELAY >= 0) && \
+ defined(CONFIG_OF_CONTROL)
+ char *env;
+#endif
#if defined(CONFIG_BOOTDELAY) && (CONFIG_BOOTDELAY >= 0)
char *s;
int bootdelay;
@@ -380,6 +388,12 @@ void main_loop (void)
else
#endif /* CONFIG_BOOTCOUNT_LIMIT */
s = getenv ("bootcmd");
+#ifdef CONFIG_OF_CONTROL
+ /* Allow the fdt to override the boot command */
+ env = fdtdec_get_config_string(gd->fdt_blob, "bootcmd");
+ if (env)
+ s = env;
+#endif /* CONFIG_OF_CONTROL */
debug ("### main_loop: bootcmd=\"%s\"\n", s ? s : "");
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/14] fdt: Add various device tree utilities and features
This series contains a number of features related to CONFIG_OF_CONTROL, such as: - reading fdt values - reading configuration from the fdt - allowing the fdt to specify a boot command Abhilash Kesavan (2): fdt: Add function to get config int from device tree fdt: Add function for decoding multiple gpios globally available Che-Liang Chiou (2): fdt: Add fdtdec_get_uint64 to decode a 64-bit value from a property fdt: Load boot command from device tree Doug Anderson (1): fdt: Allow device tree to specify secure booting Gabe Black (3): fdt: Add function to read boolean property fdt: Tell the FDT library where the device tree is fdt: Add option to default to most compatible conf in a fit image Sean Paul (1): fdt: Add polarity-aware gpio functions to fdtdec Simon Glass (5): fdt: Add function to get a config string from device tree fdt: Add fdtdec_decode_region() to decode memory region fdt: Export fdtdec_find_alias_node() function fdt: Export fdtdec_lookup() and fix the name fdt: Set kernaddr if fdt indicates a kernel is present README | 11 + common/cmd_bootm.c | 11 + common/image.c | 127 common/main.c | 102 +- include/fdtdec.h | 121 + include/image.h|1 + lib/fdtdec.c | 107 +--- 7 files changed, 472 insertions(+), 8 deletions(-) -- 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 v2 02/19] scsi: Provide support for a list of AHCI controllers.
Hi Tom, On Thu, Oct 25, 2012 at 5:52 PM, Simon Glass wrote: > From: Vadim Bendebury > > Many AHCI controllers are identical, the main (and often the > only) difference being the PCI Vendor ID/Device ID combination > reported by the device. > > This change allows the config file to define a list of PCI vendor > ID/device ID pairs. The driver would scan the list and initialize > the first device it finds. > > No actual multiple device list is introduced yet, this change > just add the framework. > > Signed-off-by: Vadim Bendebury > Signed-off-by: Taylor Hutt > Signed-off-by: Simon Glass > --- > Changes in v2: > - Use struct pci_device_id instead of defining new struct scsi_device > - Squash in CONFIG_PCI patch Please note that I squashed in patch 13 of the series. I marked http://patchwork.ozlabs.org/patch/192521/ superseded in patchwork. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 02/19] scsi: Provide support for a list of AHCI controllers.
From: Vadim Bendebury
Many AHCI controllers are identical, the main (and often the
only) difference being the PCI Vendor ID/Device ID combination
reported by the device.
This change allows the config file to define a list of PCI vendor
ID/device ID pairs. The driver would scan the list and initialize
the first device it finds.
No actual multiple device list is introduced yet, this change
just add the framework.
Signed-off-by: Vadim Bendebury
Signed-off-by: Taylor Hutt
Signed-off-by: Simon Glass
---
Changes in v2:
- Use struct pci_device_id instead of defining new struct scsi_device
- Squash in CONFIG_PCI patch
common/cmd_scsi.c | 40 +++-
1 files changed, 35 insertions(+), 5 deletions(-)
diff --git a/common/cmd_scsi.c b/common/cmd_scsi.c
index 22d0119..5cb3390 100644
--- a/common/cmd_scsi.c
+++ b/common/cmd_scsi.c
@@ -34,6 +34,9 @@
#include
#include
+#ifdef CONFIG_SCSI_DEV_LIST
+#define SCSI_DEV_LIST CONFIG_SCSI_DEV_LIST
+#else
#ifdef CONFIG_SCSI_SYM53C8XX
#define SCSI_VEND_ID 0x1000
#ifndef CONFIG_SCSI_DEV_ID
@@ -49,8 +52,12 @@
#elif !defined(CONFIG_SCSI_AHCI_PLAT)
#error no scsi device defined
#endif
+#define SCSI_DEV_LIST {SCSI_VEND_ID, SCSI_DEV_ID}
+#endif
-
+#ifdef CONFIG_PCI
+DEFINE_PCI_DEVICE_TABLE(scsi_device_list) = { SCSI_DEV_LIST };
+#endif
static ccb tempccb;/* temporary scsi command buffer */
static unsigned char tempbuff[512]; /* temporary data buffer */
@@ -178,15 +185,38 @@ removable:
void scsi_init(void)
{
int busdevfunc;
+ int i;
+ /*
+* Find a device from the list, this driver will support a single
+* controller.
+*/
+ for (i = 0; i < ARRAY_SIZE(scsi_device_list); i++) {
+ /* get PCI Device ID */
+ busdevfunc = pci_find_device(scsi_device_list[i].scsi_vendor_id,
+scsi_device_list[i].scsi_dev_id,
+0);
+ if (busdevfunc != -1)
+ break;
+ }
- busdevfunc=pci_find_device(SCSI_VEND_ID,SCSI_DEV_ID,0); /* get PCI
Device ID */
- if(busdevfunc==-1) {
- printf("Error SCSI Controller (%04X,%04X) not
found\n",SCSI_VEND_ID,SCSI_DEV_ID);
+ if (busdevfunc == -1) {
+ printf("Error: SCSI Controller(s) ");
+ for (i = 0; i < ARRAY_SIZE(scsi_device_list); i++) {
+ printf("%04X:%04X ",
+ scsi_device_list[i].scsi_vendor_id,
+ scsi_device_list[i].scsi_dev_id);
+ }
+ printf("not found\n");
return;
}
#ifdef DEBUG
else {
- printf("SCSI Controller (%04X,%04X) found
(%d:%d:%d)\n",SCSI_VEND_ID,SCSI_DEV_ID,(busdevfunc>>16)&0xFF,(busdevfunc>>11)&0x1F,(busdevfunc>>8)&0x7);
+ printf("SCSI Controller (%04X,%04X) found (%d:%d:%d)\n",
+ scsi_device_list[i].scsi_vendor_id,
+ scsi_device_list[i].scsi_dev_id,
+ (busdevfunc >> 16) & 0xFF,
+ (busdevfunc >> 11) & 0x1F,
+ (busdevfunc >> 8) & 0x7);
}
#endif
scsi_low_level_init(busdevfunc);
--
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] serial: remove calls to serial_assign()
Hi Allen, On Thu, Oct 25, 2012 at 6:30 PM, Allen Martin wrote: > Remove calls to serial_assign() that are failing now that it returns a > proper error code. This calls were not actually doing anything > because they passed the name of a stdio_dev when a serial_device name > is exptectd. > > Signed-off-by: Allen Martin > --- Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] serial: remove calls to serial_assign()
Remove calls to serial_assign() that are failing now that it returns a proper error code. This calls were not actually doing anything because they passed the name of a stdio_dev when a serial_device name is exptectd. Signed-off-by: Allen Martin --- common/cmd_nvedit.c |3 --- common/iomux.c | 10 -- 2 files changed, 13 deletions(-) diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c index 1f9c674..68c38f4 100644 --- a/common/cmd_nvedit.c +++ b/common/cmd_nvedit.c @@ -238,9 +238,6 @@ int env_check_apply(const char *name, const char *oldval, /* Try assigning specified device */ if (console_assign(console, newval) < 0) return 1; - - if (serial_assign(newval) < 0) - return 1; #endif /* CONFIG_CONSOLE_MUX */ } diff --git a/common/iomux.c b/common/iomux.c index dbc2312..6a75704 100644 --- a/common/iomux.c +++ b/common/iomux.c @@ -135,16 +135,6 @@ int iomux_doenv(const int console, const char *arg) */ if (console_assign(console, start[j]) < 0) continue; - /* -* This was taken from common/cmd_nvedit.c. -* This will never work because serial_assign() returns -* 1 upon error, not -1. -* This would almost always return an error anyway because -* serial_assign() expects the name of a serial device, like -* serial_smc, but the user generally only wants to set serial. -*/ - if (serial_assign(start[j]) < 0) - continue; cons_set[cs_idx++] = dev; } free(console_args); -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI
On Thu, Oct 25, 2012 at 04:18:11PM -0700, Joe Hershberger wrote: > Hi Allen, > > On Thu, Oct 25, 2012 at 5:53 PM, Allen Martin wrote: > > On Thu, Oct 25, 2012 at 03:47:09PM -0700, Joe Hershberger wrote: > >> Hi Stephen, > >> > >> On Thu, Oct 25, 2012 at 5:45 PM, Stephen Warren > >> wrote: > >> > On 10/25/2012 04:36 PM, Joe Hershberger wrote: > >> >> Hi Allen, > >> >> > >> >> On Thu, Oct 25, 2012 at 4:59 PM, Allen Martin > >> >> wrote: > >> >>> Add a new special environment variable "serial" that allows selection > >> >>> of serial device when CONFIG_SERIAL_MULTI is defined. This replaces > >> >>> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c > >> >>> that were not doing anything. > >> > ... > >> >> Changes to this directly conflict with the environment callback series > >> >> I sent out RFC (soon be be a real series). Can we hold off on this > >> >> until that happens? > >> > > >> > The problem here is that serial output on Tegra simply doesn't work > >> > (after some point in boot?) without this patch. It seems better to get > >> > everything working before adding new features doesn't it? Otherwise, if > >> > the environment callback stuff (or any other change right now) breaks > >> > something Tegra-specific, there would be no way to identify which change > >> > broke it. > >> > >> Fair enough. However I don't think this patch is the right way to fix it. > >> > > > > Ok, would removing the existing calls to serial_assign() from iomux.c > > and cmd_nvedit.c be an ok first step? They don't appear to do > > anything useful right now and that would fix tegra and raspberry pi. > > I think that's fine to just remove those 2 calls. Seem like a good > short-term solution. > Ok, I'll send out a patch for that now, thanks. -Allen -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI
Hi Allen, On Thu, Oct 25, 2012 at 5:53 PM, Allen Martin wrote: > On Thu, Oct 25, 2012 at 03:47:09PM -0700, Joe Hershberger wrote: >> Hi Stephen, >> >> On Thu, Oct 25, 2012 at 5:45 PM, Stephen Warren >> wrote: >> > On 10/25/2012 04:36 PM, Joe Hershberger wrote: >> >> Hi Allen, >> >> >> >> On Thu, Oct 25, 2012 at 4:59 PM, Allen Martin wrote: >> >>> Add a new special environment variable "serial" that allows selection >> >>> of serial device when CONFIG_SERIAL_MULTI is defined. This replaces >> >>> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c >> >>> that were not doing anything. >> > ... >> >> Changes to this directly conflict with the environment callback series >> >> I sent out RFC (soon be be a real series). Can we hold off on this >> >> until that happens? >> > >> > The problem here is that serial output on Tegra simply doesn't work >> > (after some point in boot?) without this patch. It seems better to get >> > everything working before adding new features doesn't it? Otherwise, if >> > the environment callback stuff (or any other change right now) breaks >> > something Tegra-specific, there would be no way to identify which change >> > broke it. >> >> Fair enough. However I don't think this patch is the right way to fix it. >> > > Ok, would removing the existing calls to serial_assign() from iomux.c > and cmd_nvedit.c be an ok first step? They don't appear to do > anything useful right now and that would fix tegra and raspberry pi. I think that's fine to just remove those 2 calls. Seem like a good short-term solution. -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI
Hi Allen, On Thu, Oct 25, 2012 at 5:50 PM, Allen Martin wrote: > On Thu, Oct 25, 2012 at 03:46:01PM -0700, Joe Hershberger wrote: >> Hi Stephen, >> >> On Thu, Oct 25, 2012 at 5:43 PM, Stephen Warren >> wrote: >> > On 10/25/2012 03:59 PM, Allen Martin wrote: >> >> Add a new special environment variable "serial" that allows selection >> >> of serial device when CONFIG_SERIAL_MULTI is defined. This replaces >> >> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c >> >> that were not doing anything. >> > >> > So I think this requires (for example) the following environment variables: >> > >> > stdout=serial >> > serial=eserial0 >> > >> > Is it possible to allow the following instead: >> > >> > stdout=eserial0 >> >> This is precisely what the patch I had pre-Marek serial did. > > In your patch would "stdout=serial" still work for case where there is > only one serial port? I think it's important to try to preserve that > to no be too disruptive. It used to support stdout=serial based on not being CONFIG_SERIAL_MULTI. Now that that's gone, I'm guessing it would simply be based on only having one registered serial device. >> >> > That way, one could presumably set: >> > >> > stdout=eserial0,eserial3 >> >> Though it didn't allow this. >> > > Shouldn't that be (nearly) transparent through iomux? If that's what iomux does, then sure! I haven't used I/O mux on a device before. -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] usb: tegra: move Tegra EHCI implementation to correct place
Move the Tegra EHCI implementation to the correct directory in the tree.
This code is specific to the Tegra EHCI controller, not to the Tegra SoC
in general.
This is not just a move of the code, but also some small changes squashed in.
Most notable:
- removed some unneeded parameters from function calls, to make functions
more self contained
- decrease max controller count to 3, both Tegra 2 and 3 have at most 3
EHCI controllers, we can aleays increase this later if the need arises
- controllers only get activated at ehci_hcd_init time, not at board_usb_init,
which is the more obvious init point and saves time if you are not going
to use usb in your boot process at all
Signed-off-by: Lucas Stach
---
This patch is based on the u-boot-usb tree
I've tested this on the Colibri T20 platform with no functional regressions.
All 3 USB controllers (both UTMI and ULPI) work as before the change.
---
arch/arm/cpu/armv7/tegra20/Makefile| 2 -
.../tegra20/usb.c => drivers/usb/host/ehci-tegra.c | 210 +++--
2 Dateien geändert, 109 Zeilen hinzugefügt(+), 103 Zeilen entfernt(-)
rename arch/arm/cpu/armv7/tegra20/usb.c => drivers/usb/host/ehci-tegra.c (87%)
diff --git a/arch/arm/cpu/armv7/tegra20/Makefile
b/arch/arm/cpu/armv7/tegra20/Makefile
index 09a0314..2c4d5c9 100644
--- a/arch/arm/cpu/armv7/tegra20/Makefile
+++ b/arch/arm/cpu/armv7/tegra20/Makefile
@@ -27,8 +27,6 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(SOC).o
-COBJS-$(CONFIG_USB_EHCI_TEGRA) += usb.o
-
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS))
diff --git a/arch/arm/cpu/armv7/tegra20/usb.c b/drivers/usb/host/ehci-tegra.c
similarity index 87%
rename from arch/arm/cpu/armv7/tegra20/usb.c
rename to drivers/usb/host/ehci-tegra.c
index 1bccf2b..0646028 100644
--- a/arch/arm/cpu/armv7/tegra20/usb.c
+++ b/drivers/usb/host/ehci-tegra.c
@@ -1,6 +1,7 @@
/*
* Copyright (c) 2011 The Chromium OS Authors.
- * (C) Copyright 2010,2011 NVIDIA Corporation
+ * Copyright (c) 2009-2012 NVIDIA Corporation
+ * Copyright (c) 2012 Lucas Stach
*
* See file CREDITS for list of people who contributed to this
* project.
@@ -22,6 +23,12 @@
*/
#include
+#include
+#include
+#include
+#include
+
+#include
#include
#include
#include
@@ -29,12 +36,11 @@
#include
#include
#include
-#include
#include
#include
#include
-#include
-#include
+
+#include "ehci.h"
#ifdef CONFIG_USB_ULPI
#ifndef CONFIG_USB_ULPI_VIEWPORT
@@ -43,9 +49,7 @@
#endif
#endif
-enum {
- USB_PORTS_MAX = 4,/* Maximum ports we allow */
-};
+#define USB_PORTS_MAX 3 /* maximum number of ports we allow */
/* Parameters we need for USB */
enum {
@@ -146,6 +150,23 @@ static const u8 utmip_elastic_limit = 16;
/* UTMIP High Speed Sync Start Delay */
static const u8 utmip_hs_sync_start_delay = 9;
+/*
+ * A known hardware issue where Connect Status Change bit of PORTSC register
+ * of USB1 controller will be set after Port Reset.
+ * We have to clear it in order for later device enumeration to proceed.
+ * This ehci_powerup_fixup overrides the weak function ehci_powerup_fixup
+ * in "ehci-hcd.c".
+ */
+void ehci_powerup_fixup(uint32_t *status_reg, uint32_t *reg)
+{
+ mdelay(50);
+ if (((u32) status_reg & TEGRA_USB_ADDR_MASK) != TEGRA_USB1_BASE)
+ return;
+ /* For EHCI_PS_CSC to be cleared in ehci_hcd.c */
+ if (ehci_readl(status_reg) & EHCI_PS_CSC)
+ *reg |= EHCI_PS_CSC;
+}
+
/* Put the port into host mode */
static void set_host_mode(struct fdt_usb *config)
{
@@ -190,19 +211,15 @@ void usbf_reset_controller(struct fdt_usb *config, struct
usb_ctlr *usbctlr)
/* Enable the UTMIP PHY */
if (config->utmi)
setbits_le32(&usbctlr->susp_ctrl, UTMIP_PHY_ENB);
-
- /*
-* TODO: where do we take the USB1 out of reset? The old code would
-* take USB3 out of reset, but not USB1. This code doesn't do either.
-*/
}
/* set up the UTMI USB controller with the parameters provided */
-static int init_utmi_usb_controller(struct fdt_usb *config,
- struct usb_ctlr *usbctlr, const u32 timing[])
+static int init_utmi_usb_controller(struct fdt_usb *config)
{
u32 val;
int loop_count;
+ u32 *timing;
+ struct usb_ctlr *usbctlr = config->reg;
clock_enable(config->periph_id);
@@ -229,6 +246,8 @@ static int init_utmi_usb_controller(struct fdt_usb *config,
* PLL Delay CONFIGURATION settings. The following parameters control
* the bring up of the plls.
*/
+ timing = usb_pll[clock_get_osc_freq()];
+
val = readl(&usbctlr->utmip_misc_cfg1);
clrsetbits_le32(&val, UTMIP_PLLU_STABLE_COUNT_MASK,
timing[PARAM_STABLE_COUNT] << UTMIP_PLLU_STABLE_COUNT_SHIFT);
@@ -331,12 +350,12 @@ static int init_utmi_usb_controller(s
Re: [U-Boot] [PATCH v9] [RFC] Add dmmalloc module for DM.
Hi Tomas,
On Fri, Oct 26, 2012 at 6:16 AM, Tomas Hlavacek wrote:
> Hello Graeme,
>
> On Thu, Oct 25, 2012 at 3:40 AM, Graeme Russ wrote:
>
>>> diff --git a/arch/arm/include/asm/global_data.h
>>> b/arch/arm/include/asm/global_data.h
>>> index 2b9af93..9045829 100644
>>> --- a/arch/arm/include/asm/global_data.h
>>> +++ b/arch/arm/include/asm/global_data.h
>>> @@ -82,6 +82,9 @@ 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
>>> +#ifdef CONFIG_SYS_EARLY_MALLOC
>>> + void*early_heap;/* heap for early_malloc */
>>> +#endif
>>
>> Why not early_heap_header *early_heap; ?
>>
>
> It might be.
>
> Actually it is a good point because I am using 3 different ways of
> dealing with addresses: 1) struct early_heap header * or struct
> early_block_header * - I am using this when I want to access members
> of the stucture or compute address past the structure (which is where
> the heap or block starts); 2) phys_addr_t - which is plain integer and
> I use this for simple computations when I do not want to worry about
> pointer arithmetic; 3) void * when I have just plain address,
> especially when I want to pass an addres among logical parts of the
> mallocator or outside. This may a bit controversial and perhaps I
> should replace it by specific strucutre pointers internally.
>
> I am unable to decide: Should I remove struct early_heap_header from
> dmmalloc.h making it publicly unavailable or should I rather change
> the void * to struct early_heap_header * in the GD structure? What do
> you think is better?
I think struct early_heap_header * in the GD structure is the better way to
go as that is exactly what it is.
[snip]
>>> + h = (struct early_heap_header *)CONFIG_SYS_EARLY_HEAP_ADDR;
>>> + b = (struct early_block_header *)(h + 1);
>>
>> Hmmm, does this really work? I would have thought:
>>
>> b = (struct early_block_header *)(h + sizeof(struct early_heap_header));
>>
>> but I could be mistaken
>
> It seems that it works as it is (at least I wrote bunch of tests and I
> inspected resulting heaps and it was all right). I believe that since
> h is a pointer to the struct early_heap_header then pointer arithmetic
> is in effect and h+1 actually means "next element in the array of
> struct early_heap_header". Which is the address past the header that
> equals beginning of the heap data block. (?)
As I said, I could be mistaken - it appears I am :)
>>> +int early_malloc_active(void)
>>> +{
>>> + return ((gd->flags & GD_FLG_RELOC) != GD_FLG_RELOC);
>>> +}
>>
>> I think we need another flag - GD_FLG_RELOC gets set before the permanent
>> heap is initialised, so there is a window of opportunity where things may
>> break
>
> Well, as I wrote in the commit message - this is only a temporary
> implementation. I suppose I am going to change this when we have more
> coarse initialization flags wired into DM (which I believe we are
> going to have it anyway). So now I am just working around "forward
> dependency" here.
>
>>
>>> +
>>> +void early_heap_dump(struct early_heap_header *h)
>>> +{
>>> + struct early_block_header *b;
>>> +
>>> + debug("heap: h=%p, h->size=%d\n", h, h->size);
>>> +
>>> + b = (struct early_block_header *)(h+1);
>>> + while ((phys_addr_t)b + sizeof(struct early_block_header)
>>> + < (phys_addr_t)h + h->size) {
>>> + debug("block: h=%p h->size=%d b=%p b->size=%d
>>> b->(used)=%d\n",
>>> + h, h->size, b, BLOCK_SIZE(b->size),
>>> + BLOCK_USED(b->size));
>>> + assert(BLOCK_SIZE(b->size) > 0);
>>> + b = (struct early_block_header *)((phys_addr_t)b +
>>> + sizeof(struct early_block_header) +
>>> + BLOCK_SIZE(b->size));
>>> + }
>>> + debug("--- heap dump end ---\n");
>>> +}
>>
>> Nice touch, but could we just iterate through all ealry heap chunks starting
>> from gd->early_heap?
>
> Or I can have two functions. One heap specific and one for all heaps.
> I think both might be useful when somebody needs to debug early_malloc
> or memory usage etc. in the early stage. Thanks.
True, just adding another function which iterates through the heaps and
calls this function would be fine.
[snip]
>>> +static inline void *dmrealloc(void *oldaddr, size_t bytes)
>>> +{
>>> +#ifdef CONFIG_SYS_EARLY_MALLOC
>>> + char *addr;
>>> + struct early_block_header *h;
>>> + if (early_malloc_active()) {
>>> + addr = dmmalloc(bytes);
>>> + if (addr == NULL)
>>> + return NULL;
>>> +
>>> + h = BLOCK_HEADER(oldaddr);
>>> + if (BLOCK_FREE(h->size))
>>> + return NULL;
>>> +
>>> + if (bytes > BLOCK_SIZE(h->siz
Re: [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI
On Thu, Oct 25, 2012 at 03:47:09PM -0700, Joe Hershberger wrote: > Hi Stephen, > > On Thu, Oct 25, 2012 at 5:45 PM, Stephen Warren wrote: > > On 10/25/2012 04:36 PM, Joe Hershberger wrote: > >> Hi Allen, > >> > >> On Thu, Oct 25, 2012 at 4:59 PM, Allen Martin wrote: > >>> Add a new special environment variable "serial" that allows selection > >>> of serial device when CONFIG_SERIAL_MULTI is defined. This replaces > >>> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c > >>> that were not doing anything. > > ... > >> Changes to this directly conflict with the environment callback series > >> I sent out RFC (soon be be a real series). Can we hold off on this > >> until that happens? > > > > The problem here is that serial output on Tegra simply doesn't work > > (after some point in boot?) without this patch. It seems better to get > > everything working before adding new features doesn't it? Otherwise, if > > the environment callback stuff (or any other change right now) breaks > > something Tegra-specific, there would be no way to identify which change > > broke it. > > Fair enough. However I don't think this patch is the right way to fix it. > Ok, would removing the existing calls to serial_assign() from iomux.c and cmd_nvedit.c be an ok first step? They don't appear to do anything useful right now and that would fix tegra and raspberry pi. -Allen -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI
On Thu, Oct 25, 2012 at 03:46:01PM -0700, Joe Hershberger wrote: > Hi Stephen, > > On Thu, Oct 25, 2012 at 5:43 PM, Stephen Warren wrote: > > On 10/25/2012 03:59 PM, Allen Martin wrote: > >> Add a new special environment variable "serial" that allows selection > >> of serial device when CONFIG_SERIAL_MULTI is defined. This replaces > >> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c > >> that were not doing anything. > > > > So I think this requires (for example) the following environment variables: > > > > stdout=serial > > serial=eserial0 > > > > Is it possible to allow the following instead: > > > > stdout=eserial0 > > This is precisely what the patch I had pre-Marek serial did. In your patch would "stdout=serial" still work for case where there is only one serial port? I think it's important to try to preserve that to no be too disruptive. > > > That way, one could presumably set: > > > > stdout=eserial0,eserial3 > > Though it didn't allow this. > Shouldn't that be (nearly) transparent through iomux? -Allen -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI
Hi Stephen, On Thu, Oct 25, 2012 at 5:45 PM, Stephen Warren wrote: > On 10/25/2012 04:36 PM, Joe Hershberger wrote: >> Hi Allen, >> >> On Thu, Oct 25, 2012 at 4:59 PM, Allen Martin wrote: >>> Add a new special environment variable "serial" that allows selection >>> of serial device when CONFIG_SERIAL_MULTI is defined. This replaces >>> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c >>> that were not doing anything. > ... >> Changes to this directly conflict with the environment callback series >> I sent out RFC (soon be be a real series). Can we hold off on this >> until that happens? > > The problem here is that serial output on Tegra simply doesn't work > (after some point in boot?) without this patch. It seems better to get > everything working before adding new features doesn't it? Otherwise, if > the environment callback stuff (or any other change right now) breaks > something Tegra-specific, there would be no way to identify which change > broke it. Fair enough. However I don't think this patch is the right way to fix it. -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI
Hi Stephen, On Thu, Oct 25, 2012 at 5:43 PM, Stephen Warren wrote: > On 10/25/2012 03:59 PM, Allen Martin wrote: >> Add a new special environment variable "serial" that allows selection >> of serial device when CONFIG_SERIAL_MULTI is defined. This replaces >> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c >> that were not doing anything. > > So I think this requires (for example) the following environment variables: > > stdout=serial > serial=eserial0 > > Is it possible to allow the following instead: > > stdout=eserial0 This is precisely what the patch I had pre-Marek serial did. > That way, one could presumably set: > > stdout=eserial0,eserial3 Though it didn't allow this. -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI
On 10/25/2012 04:36 PM, Joe Hershberger wrote: > Hi Allen, > > On Thu, Oct 25, 2012 at 4:59 PM, Allen Martin wrote: >> Add a new special environment variable "serial" that allows selection >> of serial device when CONFIG_SERIAL_MULTI is defined. This replaces >> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c >> that were not doing anything. ... > Changes to this directly conflict with the environment callback series > I sent out RFC (soon be be a real series). Can we hold off on this > until that happens? The problem here is that serial output on Tegra simply doesn't work (after some point in boot?) without this patch. It seems better to get everything working before adding new features doesn't it? Otherwise, if the environment callback stuff (or any other change right now) breaks something Tegra-specific, there would be no way to identify which change broke it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI
On 10/25/2012 03:59 PM, Allen Martin wrote: > Add a new special environment variable "serial" that allows selection > of serial device when CONFIG_SERIAL_MULTI is defined. This replaces > the existing calls to serial_assign() from cmd_nvedit.c and iomux.c > that were not doing anything. So I think this requires (for example) the following environment variables: stdout=serial serial=eserial0 Is it possible to allow the following instead: stdout=eserial0 That way, one could presumably set: stdout=eserial0,eserial3 and hence allow the use of multiple serial consoles? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] serial: Reorder serial_assign()
Hi Allen, On Thu, Oct 25, 2012 at 4:19 PM, Allen Martin wrote: > On Thu, Oct 25, 2012 at 02:02:55PM -0700, Simon Glass wrote: >> Hi, >> >> On Thu, Oct 25, 2012 at 12:03 PM, Marek Vasut wrote: >> > Dear Simon Glass, >> > >> >> Hi, >> >> >> >> On Mon, Oct 22, 2012 at 10:23 AM, Allen Martin wrote: >> >> > On Sat, Oct 20, 2012 at 01:19:00AM -0700, Marek Vasut wrote: >> >> >> Dear Allen Martin, >> >> >> >> >> >> [...] >> >> >> >> >> >> > Hi Marek, the change to return value here broke serial output on >> >> >> > tegra. What I see is that the serial device name (s->name) is >> >> >> > "eserial0" as set by serial_ns16550.c, and the name passed in from >> >> >> > the >> >> >> > stdout environment is "serial" so they don't match and it fails. >> >> >> > This >> >> >> > always used to be ok because the return code didn't indicate failure >> >> >> > and iomux_doenv() would continue on happily, but now it causes >> >> >> > iomux_doenv() to fail and no printfs() work after that. >> >> >> > >> >> >> > Not sure what the right fix is, should stdout really be set to >> >> >> > "eserial0"? It seems "serial" should mean "the default serial >> >> >> > device" >> >> >> > which for the normal case is the one and only device. >> >> >> >> >> >> Looking at the source, the obvious course of action is to fix iomux.c . >> >> > >> >> > I've been looking at this call to serial_assign() from iomux.c and I'm >> >> > not convinced this code does anything meaningful at all. It passes >> >> > the name of a struct stdio_dev device which serial_assign() then tries >> >> > to match against the registered struct serial_devices, which will >> >> > never match. >> >> > >> >> > What I don't understand is the case where you have a board that >> >> > actually has more than one physical serial port and how the mapping >> >> > from stdio_dev to serial_device happens. >> >> > >> >> > Also, looking at the code to cmd_nvedit, I think your change also broke >> >> > "setenv stdout" for boards that don't define CONFIG_CONSOLE_MUX. We >> >> > always have this on for tegra, so we don't go down this code path, but >> >> > it looks identical to the code in iomux.c >> >> >> >> Sorry if I missed it - what was the resolution here? Should we revert >> >> that change? >> > >> > Definitelly not. We should fix the iomux.c , possibly by flipping the >> > inequation >> > mark as a short term solution. >> >> OK that's fine. Is someone working on a patch? >> > > I'll send out my proposal for a patch. Unfortunately I don't have a > board with multiple serial ports to correctly test CONFIG_SERIAL_MULTI One of the boards I'm working on does this (has more than one). At least before the serial rework from Marek, the stdout was either the serial device directly (each serial device was added as a console device as well) so the serial setting was redundant. You could just set them directly to the serial port (which is more flexible). I had two patches (not sent to ML before Marek made them highly conflicting) that take the opposite approach you were, since it preserves the flexibility. It removed the "serial" setting to each of the std* variables and instead sets it to the default serial device. I'll remake that patch on top of the new serial landscape sometime soon. -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/85xx: implement check for erratum A-004849 work-around
The work-around for erratum A-004849 ("CoreNet fabric (CCF) can exhibit a
deadlock under certain traffic patterns causing the system to hang") is
implemented via the PBI (pre-boot initialization code, typically attached
to the RCW binary). This is because the work-around is easier to implement
in PBI than in U-Boot itself.
It is still useful, however, for the 'errata' command to tell us whether
the work-around has been applied. For A-004849, we can do this by verifying
that the values in the specific registers that the work-around says to
update.
Signed-off-by: Timur Tabi
---
arch/powerpc/cpu/mpc85xx/cmd_errata.c | 63 +
arch/powerpc/include/asm/config_mpc85xx.h |3 +
2 files changed, 66 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
index 2be192d..ccfad56 100644
--- a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
+++ b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
@@ -25,6 +25,65 @@
#include
#include
+#ifdef CONFIG_SYS_FSL_ERRATUM_A004849
+/*
+ * This work-around is implemented in PBI, so just check to see if the
+ * work-around was actually applied. To do this, we check for specific data
+ * at specific addresses in DCSR.
+ *
+ * Array offsets[] contains a list of offsets within DCSR. According to the
+ * erratum document, the value at each offset should be 2.
+ */
+static void check_erratum_a4849(uint32_t svr)
+{
+ void __iomem *dcsr = (void *)CONFIG_SYS_DCSRBAR + 0xb;
+ unsigned int i;
+
+#if defined(CONFIG_PPC_P2041) || defined(CONFIG_PPC_P3041)
+ static const uint8_t offsets[] = {
+ 0x50, 0x54, 0x58, 0x90, 0x94, 0x98
+ };
+#endif
+#ifdef CONFIG_PPC_P4080
+ static const uint8_t offsets[] = {
+ 0x60, 0x64, 0x68, 0x6c, 0xa0, 0xa4, 0xa8, 0xac
+ };
+#endif
+ uint32_t x108; /* The value that should be at offset 0x108 */
+
+ for (i = 0; i < ARRAY_SIZE(offsets); i++) {
+ if (in_be32(dcsr + offsets[i]) != 2) {
+ printf("Work-around for Erratum A004849 is not
enabled\n");
+ return;
+ }
+ }
+
+#if defined(CONFIG_PPC_P2041) || defined(CONFIG_PPC_P3041)
+ x108 = 0x12;
+#endif
+
+#ifdef CONFIG_PPC_P4080
+ /*
+* For P4080, the erratum document says that the value at offset 0x108
+* should be 0x12 on rev2, or 0x1c on rev3.
+*/
+ if (SVR_MAJ(svr) == 2)
+ x108 = 0x12;
+ if (SVR_MAJ(svr) == 3)
+ x108 = 0x1c;
+#endif
+
+ if (in_be32(dcsr + 0x108) != x108) {
+ printf("Work-around for Erratum A004849 is not enabled\n");
+ return;
+ }
+
+ /* Everything matches, so the erratum work-around was applied */
+
+ printf("Work-around for Erratum A004849 enabled\n");
+}
+#endif
+
static int do_errata(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
#ifdef CONFIG_SYS_FSL_ERRATUM_NMG_CPU_A011
@@ -137,6 +196,10 @@ static int do_errata(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
#ifdef CONFIG_SYS_FSL_ERRATUM_A_004934
puts("Work-around for Erratum A004934 enabled\n");
#endif
+#ifdef CONFIG_SYS_FSL_ERRATUM_A004849
+ /* This work-around is implemented in PBI, so just check for it */
+ check_erratum_a4849(svr);
+#endif
return 0;
}
diff --git a/arch/powerpc/include/asm/config_mpc85xx.h
b/arch/powerpc/include/asm/config_mpc85xx.h
index 03baaee..3bde0f4 100644
--- a/arch/powerpc/include/asm/config_mpc85xx.h
+++ b/arch/powerpc/include/asm/config_mpc85xx.h
@@ -343,6 +343,7 @@
#define CONFIG_SYS_FSL_ERRATUM_A004510_SVR_REV20x11
#define CONFIG_SYS_FSL_CORENET_SNOOPVEC_COREONLY 0xf000
#define CONFIG_SYS_FSL_ERRATUM_SRIO_A004034
+#define CONFIG_SYS_FSL_ERRATUM_A004849
#elif defined(CONFIG_PPC_P3041)
#define CONFIG_SYS_FSL_QORIQ_CHASSIS1
@@ -375,6 +376,7 @@
#define CONFIG_SYS_FSL_ERRATUM_A004510_SVR_REV20x11
#define CONFIG_SYS_FSL_CORENET_SNOOPVEC_COREONLY 0xf000
#define CONFIG_SYS_FSL_ERRATUM_SRIO_A004034
+#define CONFIG_SYS_FSL_ERRATUM_A004849
#elif defined(CONFIG_PPC_P4080) /* also supports P4040 */
#define CONFIG_SYS_FSL_QORIQ_CHASSIS1
@@ -417,6 +419,7 @@
#define CONFIG_SYS_FSL_ERRATUM_A004510_SVR_REV 0x20
#define CONFIG_SYS_FSL_CORENET_SNOOPVEC_COREONLY 0xff00
#define CONFIG_SYS_FSL_ERRATUM_SRIO_A004034
+#define CONFIG_SYS_FSL_ERRATUM_A004849
#elif defined(CONFIG_PPC_P5020) /* also supports P5010 */
#define CONFIG_SYS_PPC64 /* 64-bit core */
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI
Hi Allen,
On Thu, Oct 25, 2012 at 4:59 PM, Allen Martin wrote:
> Add a new special environment variable "serial" that allows selection
> of serial device when CONFIG_SERIAL_MULTI is defined. This replaces
> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c
> that were not doing anything.
>
> Signed-off-by: Allen Martin
> ---
> common/cmd_nvedit.c |7 ++-
> common/iomux.c | 10 --
> doc/driver-model/UDM-serial.txt |5 +++--
> 3 files changed, 9 insertions(+), 13 deletions(-)
>
> diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
> index 1f9c674..d1ee07d 100644
> --- a/common/cmd_nvedit.c
> +++ b/common/cmd_nvedit.c
> @@ -238,11 +238,16 @@ int env_check_apply(const char *name, const char
> *oldval,
> /* Try assigning specified device */
> if (console_assign(console, newval) < 0)
> return 1;
> +#endif /* CONFIG_CONSOLE_MUX */
> + }
>
> +#ifdef CONFIG_SERIAL_MULTI
> + /* Check for serial redirection */
> + if (strcmp(name, "serial") == 0) {
> if (serial_assign(newval) < 0)
> return 1;
> -#endif /* CONFIG_CONSOLE_MUX */
> }
> +#endif /* CONFIG_SERIAL_MULTI */
Changes to this directly conflict with the environment callback series
I sent out RFC (soon be be a real series). Can we hold off on this
until that happens?
> /*
> * Some variables like "ethaddr" and "serial#" can be set only once
> and
> diff --git a/common/iomux.c b/common/iomux.c
> index dbc2312..6a75704 100644
> --- a/common/iomux.c
> +++ b/common/iomux.c
> @@ -135,16 +135,6 @@ int iomux_doenv(const int console, const char *arg)
> */
> if (console_assign(console, start[j]) < 0)
> continue;
> - /*
> -* This was taken from common/cmd_nvedit.c.
> -* This will never work because serial_assign() returns
> -* 1 upon error, not -1.
> -* This would almost always return an error anyway because
> -* serial_assign() expects the name of a serial device, like
> -* serial_smc, but the user generally only wants to set
> serial.
> -*/
> - if (serial_assign(start[j]) < 0)
> - continue;
> cons_set[cs_idx++] = dev;
> }
> free(console_args);
> diff --git a/doc/driver-model/UDM-serial.txt b/doc/driver-model/UDM-serial.txt
> index 9feb2e5..66f3e6b 100644
> --- a/doc/driver-model/UDM-serial.txt
> +++ b/doc/driver-model/UDM-serial.txt
> @@ -26,8 +26,9 @@ and serial_setbrg() are often called from
> platform-dependent places.
> It's important to consider current implementation of CONFIG_SERIAL_MULTI
> though.
> This resides in common/serial.c and behaves as a multiplexer for serial
> ports.
> This, by calling serial_assign(), allows user to switch I/O from one serial
> port
> -to another. Though the environmental variables "stdin", "stdout", "stderr"
> -remain set to "serial".
> +to another. The environment variable "serial" is used to select which of the
> +serial ports is the currently active port. The environmental variables
> +"stdin", "stdout", "stderr" remain set to "serial".
>
> These variables are managed by the IOMUX. This resides in common/iomux.c and
> manages all console input/output from U-Boot. For serial port, only one
> IOMUX is
> --
> 1.7.10.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
Re: [U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI
On Thu, Oct 25, 2012 at 02:59:50PM -0700, Allen Martin wrote: > Add a new special environment variable "serial" that allows selection > of serial device when CONFIG_SERIAL_MULTI is defined. This replaces > the existing calls to serial_assign() from cmd_nvedit.c and iomux.c > that were not doing anything. > > Signed-off-by: Allen Martin Two things. First, should I or should I not need to have CONFIG_CONSOLE_MUX set? If I set it, adding serial=eserial3 to my default environment switches from eserial0 to eserial3 when we get to that point in the boot, otherwise I do have to manually setenv serial eserial3 for anything to happen. And the second thing, I can't get any output on the other UART, either way. It goes away from eserial0 but nothing ever shows up to eserial3 (the easiest one here to test). -- 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] serial: add environment control for SERIAL_MULTI
Dear Allen Martin,
> Add a new special environment variable "serial" that allows selection
> of serial device when CONFIG_SERIAL_MULTI is defined. This replaces
> the existing calls to serial_assign() from cmd_nvedit.c and iomux.c
> that were not doing anything.
>
> Signed-off-by: Allen Martin
> ---
> common/cmd_nvedit.c |7 ++-
> common/iomux.c | 10 --
> doc/driver-model/UDM-serial.txt |5 +++--
> 3 files changed, 9 insertions(+), 13 deletions(-)
>
> diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
> index 1f9c674..d1ee07d 100644
> --- a/common/cmd_nvedit.c
> +++ b/common/cmd_nvedit.c
> @@ -238,11 +238,16 @@ int env_check_apply(const char *name, const char
> *oldval, /* Try assigning specified device */
> if (console_assign(console, newval) < 0)
> return 1;
> +#endif /* CONFIG_CONSOLE_MUX */
> + }
>
> +#ifdef CONFIG_SERIAL_MULTI
Drop this, it's default. There's no CONFIG_SERIAL_MULTI in the tree at all
anymore.
> + /* Check for serial redirection */
> + if (strcmp(name, "serial") == 0) {
> if (serial_assign(newval) < 0)
> return 1;
> -#endif /* CONFIG_CONSOLE_MUX */
> }
> +#endif /* CONFIG_SERIAL_MULTI */
>
> /*
>* Some variables like "ethaddr" and "serial#" can be set only once and
> diff --git a/common/iomux.c b/common/iomux.c
> index dbc2312..6a75704 100644
> --- a/common/iomux.c
> +++ b/common/iomux.c
> @@ -135,16 +135,6 @@ int iomux_doenv(const int console, const char *arg)
>*/
> if (console_assign(console, start[j]) < 0)
> continue;
> - /*
> - * This was taken from common/cmd_nvedit.c.
> - * This will never work because serial_assign() returns
> - * 1 upon error, not -1.
> - * This would almost always return an error anyway because
> - * serial_assign() expects the name of a serial device, like
> - * serial_smc, but the user generally only wants to set serial.
> - */
> - if (serial_assign(start[j]) < 0)
> - continue;
> cons_set[cs_idx++] = dev;
> }
> free(console_args);
> diff --git a/doc/driver-model/UDM-serial.txt
> b/doc/driver-model/UDM-serial.txt index 9feb2e5..66f3e6b 100644
> --- a/doc/driver-model/UDM-serial.txt
> +++ b/doc/driver-model/UDM-serial.txt
> @@ -26,8 +26,9 @@ and serial_setbrg() are often called from
> platform-dependent places. It's important to consider current
> implementation of CONFIG_SERIAL_MULTI though. This resides in
> common/serial.c and behaves as a multiplexer for serial ports. This, by
> calling serial_assign(), allows user to switch I/O from one serial port
> -to another. Though the environmental variables "stdin", "stdout",
> "stderr" -remain set to "serial".
> +to another. The environment variable "serial" is used to select which of
> the +serial ports is the currently active port. The environmental
> variables +"stdin", "stdout", "stderr" remain set to "serial".
>
> These variables are managed by the IOMUX. This resides in common/iomux.c
> and manages all console input/output from U-Boot. For serial port, only
> one IOMUX is
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] serial: add environment control for SERIAL_MULTI
Add a new special environment variable "serial" that allows selection
of serial device when CONFIG_SERIAL_MULTI is defined. This replaces
the existing calls to serial_assign() from cmd_nvedit.c and iomux.c
that were not doing anything.
Signed-off-by: Allen Martin
---
common/cmd_nvedit.c |7 ++-
common/iomux.c | 10 --
doc/driver-model/UDM-serial.txt |5 +++--
3 files changed, 9 insertions(+), 13 deletions(-)
diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index 1f9c674..d1ee07d 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -238,11 +238,16 @@ int env_check_apply(const char *name, const char *oldval,
/* Try assigning specified device */
if (console_assign(console, newval) < 0)
return 1;
+#endif /* CONFIG_CONSOLE_MUX */
+ }
+#ifdef CONFIG_SERIAL_MULTI
+ /* Check for serial redirection */
+ if (strcmp(name, "serial") == 0) {
if (serial_assign(newval) < 0)
return 1;
-#endif /* CONFIG_CONSOLE_MUX */
}
+#endif /* CONFIG_SERIAL_MULTI */
/*
* Some variables like "ethaddr" and "serial#" can be set only once and
diff --git a/common/iomux.c b/common/iomux.c
index dbc2312..6a75704 100644
--- a/common/iomux.c
+++ b/common/iomux.c
@@ -135,16 +135,6 @@ int iomux_doenv(const int console, const char *arg)
*/
if (console_assign(console, start[j]) < 0)
continue;
- /*
-* This was taken from common/cmd_nvedit.c.
-* This will never work because serial_assign() returns
-* 1 upon error, not -1.
-* This would almost always return an error anyway because
-* serial_assign() expects the name of a serial device, like
-* serial_smc, but the user generally only wants to set serial.
-*/
- if (serial_assign(start[j]) < 0)
- continue;
cons_set[cs_idx++] = dev;
}
free(console_args);
diff --git a/doc/driver-model/UDM-serial.txt b/doc/driver-model/UDM-serial.txt
index 9feb2e5..66f3e6b 100644
--- a/doc/driver-model/UDM-serial.txt
+++ b/doc/driver-model/UDM-serial.txt
@@ -26,8 +26,9 @@ and serial_setbrg() are often called from platform-dependent
places.
It's important to consider current implementation of CONFIG_SERIAL_MULTI
though.
This resides in common/serial.c and behaves as a multiplexer for serial ports.
This, by calling serial_assign(), allows user to switch I/O from one serial
port
-to another. Though the environmental variables "stdin", "stdout", "stderr"
-remain set to "serial".
+to another. The environment variable "serial" is used to select which of the
+serial ports is the currently active port. The environmental variables
+"stdin", "stdout", "stderr" remain set to "serial".
These variables are managed by the IOMUX. This resides in common/iomux.c and
manages all console input/output from U-Boot. For serial port, only one IOMUX
is
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] Bring in new I2C framework
Hi Heiko, On Mon, Oct 22, 2012 at 10:40 AM, Heiko Schocher wrote: > rebased/reworked the I2C multibus patches from Simon Glass found > here: > > http://www.mail-archive.com/u-boot@lists.denx.de/msg75530.html > > It seems the timing is coming, to bring this in mainline and > move boards over to the new i2c framework. As an example I > converted the soft-i2c driver (and all boards using it) to > the new framework, so this patchseries has to be tested > intensively, as I can check compile only ... I am very happy to see this, thank you. I have brought this in and tried to get it running for Tegra. A few points: 1. The methods in struct i2c_adapter should IMO be passed a struct i2c_adapter *, so they can determine which adapter is being accessed. Otherwise I can't see how they would know. 2. The init is a bit odd, in that we can call init() repeatedly. Perhaps that function should be renamed to reset, and the init should be used for calling just once at the start? 3. Rather than each device having to call i2c_get_bus_num() to find out what bus is referred to, why not just pass this information in? In fact the adapter pointer can serve for this. 4. So perhaps the i2c read/write functions should change from: int i2c_read(uchar chip, uint addr, int alen, uchar *buffer, int len) to: int i2c_read((struct i2c_adapter *adapter, uint addr, int alen, uchar *buffer, int len) Later, I wonder whether the concept of a 'current' i2c bus should be maintained by the command line interpreter, rather than the i2c system. Because to be honest, most of the drivers I see have to save the current bus number, set the current bus, do the operation, then set the bus back how they found it (to preserve whatever the user things is the current bus). Granted there is overhead with i2c muxes, but the i2c core can remember the state of these muxes and doesn't have to switch things until there has been a change since the last transaction. This last suggestion can be dealt with later, but I thought I would bring it up. Regards, Simon > > Cc: Simon Glass > Cc: Piotr Wilczek > > Heiko Schocher (3): > i2c: add i2c_core and prepare for new multibus support > i2c: common changes for multibus/multiadapter support > i2c, soft-i2c: switch to new multibus/multiadapter support > > README| 89 +++- > arch/arm/include/asm/global_data.h|3 + > arch/arm/lib/board.c | 15 +- > arch/avr32/include/asm/global_data.h |3 + > arch/blackfin/include/asm/global_data.h |4 +- > arch/blackfin/lib/board.c |7 + > arch/m68k/include/asm/global_data.h |3 + > arch/m68k/lib/board.c | 15 +- > arch/microblaze/include/asm/global_data.h |3 + > arch/mips/include/asm/global_data.h |3 + > arch/mips/lib/board.c |7 + > arch/nds32/include/asm/global_data.h |3 + > arch/nds32/lib/board.c| 10 +- > arch/nios2/include/asm/global_data.h |3 + > arch/powerpc/cpu/mpc8xx/video.c |4 + > arch/powerpc/include/asm/global_data.h|3 + > arch/powerpc/lib/board.c | 16 +- > arch/sh/include/asm/global_data.h |3 + > arch/sparc/include/asm/global_data.h |3 + > arch/x86/include/asm/global_data.h|3 + > board/BuS/eb_cpux9k2/cpux9k2.c|2 +- > board/BuS/vl_ma2sc/vl_ma2sc.c |2 +- > board/atc/atc.c |2 +- > board/bluewater/snapper9260/snapper9260.c |2 +- > board/cm5200/cm5200.c |4 +- > board/cpu86/cpu86.c |2 +- > board/cpu87/cpu87.c |2 +- > board/emk/top9000/top9000.c |8 +- > board/eukrea/cpuat91/cpuat91.c|2 +- > board/freescale/m52277evb/README |2 +- > board/freescale/m53017evb/README |2 +- > board/freescale/m5373evb/README |2 +- > board/freescale/m54455evb/README |2 +- > board/freescale/m547xevb/README |2 +- > board/ids8247/ids8247.c |2 +- > board/keymile/common/common.c |3 +- > board/keymile/common/ivm.c| 15 +- > board/keymile/km82xx/km82xx.c |2 +- > board/keymile/km_arm/km_arm.c |8 +- > board/lwmon/lwmon.c |2 +- > board/lwmon/pcmcia.c |4 +- > board/pm826/pm826.c |2 +- > board/pm828/pm828.c |2 +- > board/sacsng/ioconfig.h |2 +- > board/sandburst/karef/karef.c |1 - > board/siemens/SCM/scm.c |2 +- > board/tqc/tqm8260/tqm8260.c |2 +- > board/tqc/tqm8272/tqm8272.c |2 +- > board/tqc/tqm8272/tqm8272.h |2 +- > common/cmd_da
Re: [U-Boot] [PATCH 3/6] serial: Reorder serial_assign()
On Thu, Oct 25, 2012 at 02:27:24PM -0700, Tom Rini wrote: > * PGP Signed by an unknown key > > On 10/25/12 14:19, Allen Martin wrote: > > On Thu, Oct 25, 2012 at 02:02:55PM -0700, Simon Glass wrote: > >> Hi, > >> > >> On Thu, Oct 25, 2012 at 12:03 PM, Marek Vasut > >> wrote: > >>> Dear Simon Glass, > >>> > Hi, > > On Mon, Oct 22, 2012 at 10:23 AM, Allen Martin > wrote: > > On Sat, Oct 20, 2012 at 01:19:00AM -0700, Marek Vasut > > wrote: > >> Dear Allen Martin, > >> > >> [...] > >> > >>> Hi Marek, the change to return value here broke serial > >>> output on tegra. What I see is that the serial device > >>> name (s->name) is "eserial0" as set by > >>> serial_ns16550.c, and the name passed in from the > >>> stdout environment is "serial" so they don't match and > >>> it fails. This always used to be ok because the > >>> return code didn't indicate failure and iomux_doenv() > >>> would continue on happily, but now it causes > >>> iomux_doenv() to fail and no printfs() work after > >>> that. > >>> > >>> Not sure what the right fix is, should stdout really be > >>> set to "eserial0"? It seems "serial" should mean "the > >>> default serial device" which for the normal case is the > >>> one and only device. > >> > >> Looking at the source, the obvious course of action is to > >> fix iomux.c . > > > > I've been looking at this call to serial_assign() from > > iomux.c and I'm not convinced this code does anything > > meaningful at all. It passes the name of a struct > > stdio_dev device which serial_assign() then tries to match > > against the registered struct serial_devices, which will > > never match. > > > > What I don't understand is the case where you have a board > > that actually has more than one physical serial port and > > how the mapping from stdio_dev to serial_device happens. > > > > Also, looking at the code to cmd_nvedit, I think your > > change also broke "setenv stdout" for boards that don't > > define CONFIG_CONSOLE_MUX. We always have this on for > > tegra, so we don't go down this code path, but it looks > > identical to the code in iomux.c > > Sorry if I missed it - what was the resolution here? Should > we revert that change? > >>> > >>> Definitelly not. We should fix the iomux.c , possibly by > >>> flipping the inequation mark as a short term solution. > >> > >> OK that's fine. Is someone working on a patch? > >> > > > > I'll send out my proposal for a patch. Unfortunately I don't have > > a board with multiple serial ports to correctly test > > CONFIG_SERIAL_MULTI > > Andrew's recent set of patches for am335x means I do. If I follow > correctly, you're describing the case where >1 port for a driver is > known, we default to say 0 but want to use 1, via the env? Yes, exactly. I assume that's what the current calls to serial_assign() were supposed to be doing, but weren't. -Allen -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] serial: Reorder serial_assign()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/25/12 14:19, Allen Martin wrote: > On Thu, Oct 25, 2012 at 02:02:55PM -0700, Simon Glass wrote: >> Hi, >> >> On Thu, Oct 25, 2012 at 12:03 PM, Marek Vasut >> wrote: >>> Dear Simon Glass, >>> Hi, On Mon, Oct 22, 2012 at 10:23 AM, Allen Martin wrote: > On Sat, Oct 20, 2012 at 01:19:00AM -0700, Marek Vasut > wrote: >> Dear Allen Martin, >> >> [...] >> >>> Hi Marek, the change to return value here broke serial >>> output on tegra. What I see is that the serial device >>> name (s->name) is "eserial0" as set by >>> serial_ns16550.c, and the name passed in from the >>> stdout environment is "serial" so they don't match and >>> it fails. This always used to be ok because the >>> return code didn't indicate failure and iomux_doenv() >>> would continue on happily, but now it causes >>> iomux_doenv() to fail and no printfs() work after >>> that. >>> >>> Not sure what the right fix is, should stdout really be >>> set to "eserial0"? It seems "serial" should mean "the >>> default serial device" which for the normal case is the >>> one and only device. >> >> Looking at the source, the obvious course of action is to >> fix iomux.c . > > I've been looking at this call to serial_assign() from > iomux.c and I'm not convinced this code does anything > meaningful at all. It passes the name of a struct > stdio_dev device which serial_assign() then tries to match > against the registered struct serial_devices, which will > never match. > > What I don't understand is the case where you have a board > that actually has more than one physical serial port and > how the mapping from stdio_dev to serial_device happens. > > Also, looking at the code to cmd_nvedit, I think your > change also broke "setenv stdout" for boards that don't > define CONFIG_CONSOLE_MUX. We always have this on for > tegra, so we don't go down this code path, but it looks > identical to the code in iomux.c Sorry if I missed it - what was the resolution here? Should we revert that change? >>> >>> Definitelly not. We should fix the iomux.c , possibly by >>> flipping the inequation mark as a short term solution. >> >> OK that's fine. Is someone working on a patch? >> > > I'll send out my proposal for a patch. Unfortunately I don't have > a board with multiple serial ports to correctly test > CONFIG_SERIAL_MULTI Andrew's recent set of patches for am335x means I do. If I follow correctly, you're describing the case where >1 port for a driver is known, we default to say 0 but want to use 1, via the env? - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQia68AAoJENk4IS6UOR1W4NYP/jlbMsXtRojPz7FOVdVSUV+K OK3Pgzc0RD1LMREnHJGRrH42Y5k9s2op0eex/yRLGVjpdyQuM8MykvJ944pDihwX +0Rw8z3oNDg1IeB3R2cgwVCH5vBRGARxr/WdvCQc51uaMDZLwwWM3smHfTvDEeeJ bYIUH9JrAjkpq7DBYCSTq9FR91iJ7hMbLaJjULQaG4Fo64ZBG9A4Llf6+hotADEd 3rHrQN8mJNuYiUYmdbP3B94NNp9+hWXb6r10I8vj2Bb331tBqCHGPOWF4U2h9D2j AHofm8hj22SDTiXNR4SRfGSjqWqc8ZrocaoKxjBTnvlqxgN9+o/w+JNogCJcJ07y zNn73DdxiztgDvoRzWz7oYiI2jF5KGAXVjPRTkY6P5v8Ybh8QF+/CX3NaHjlO7GX VvK3s9AOMqyVz69EZX0OVnaL47WEaz21cG3pA2u595/5kNKrrEbUDEc6tNzLg+vy 5ah1P/g1kqNmKIgN4UtYSKCjCRA4vC5gHs4ixqhPw31aI54YnkbMq/y0SVhvd7Fk iBpsojMQnuHPwRNLtfffqKtkcSMuTxrk2U90KXMg9DSm3cOqPXZgFwfaZH8GXUAV W0Oo7QKpzgoEY4Qm0TjME2/BA/xGh7fBqiu3SAQuE89+w9rGEpQamCkuFFEKYKRt YjHt4C0QHEjwb4kqkINx =D41e -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] serial: Reorder serial_assign()
On Thu, Oct 25, 2012 at 02:02:55PM -0700, Simon Glass wrote: > Hi, > > On Thu, Oct 25, 2012 at 12:03 PM, Marek Vasut wrote: > > Dear Simon Glass, > > > >> Hi, > >> > >> On Mon, Oct 22, 2012 at 10:23 AM, Allen Martin wrote: > >> > On Sat, Oct 20, 2012 at 01:19:00AM -0700, Marek Vasut wrote: > >> >> Dear Allen Martin, > >> >> > >> >> [...] > >> >> > >> >> > Hi Marek, the change to return value here broke serial output on > >> >> > tegra. What I see is that the serial device name (s->name) is > >> >> > "eserial0" as set by serial_ns16550.c, and the name passed in from the > >> >> > stdout environment is "serial" so they don't match and it fails. This > >> >> > always used to be ok because the return code didn't indicate failure > >> >> > and iomux_doenv() would continue on happily, but now it causes > >> >> > iomux_doenv() to fail and no printfs() work after that. > >> >> > > >> >> > Not sure what the right fix is, should stdout really be set to > >> >> > "eserial0"? It seems "serial" should mean "the default serial device" > >> >> > which for the normal case is the one and only device. > >> >> > >> >> Looking at the source, the obvious course of action is to fix iomux.c . > >> > > >> > I've been looking at this call to serial_assign() from iomux.c and I'm > >> > not convinced this code does anything meaningful at all. It passes > >> > the name of a struct stdio_dev device which serial_assign() then tries > >> > to match against the registered struct serial_devices, which will > >> > never match. > >> > > >> > What I don't understand is the case where you have a board that > >> > actually has more than one physical serial port and how the mapping > >> > from stdio_dev to serial_device happens. > >> > > >> > Also, looking at the code to cmd_nvedit, I think your change also broke > >> > "setenv stdout" for boards that don't define CONFIG_CONSOLE_MUX. We > >> > always have this on for tegra, so we don't go down this code path, but > >> > it looks identical to the code in iomux.c > >> > >> Sorry if I missed it - what was the resolution here? Should we revert > >> that change? > > > > Definitelly not. We should fix the iomux.c , possibly by flipping the > > inequation > > mark as a short term solution. > > OK that's fine. Is someone working on a patch? > I'll send out my proposal for a patch. Unfortunately I don't have a board with multiple serial ports to correctly test CONFIG_SERIAL_MULTI -Allen -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,3/6] fdt: Add get commands to fdt
On Fri, Aug 17, 2012 at 10:34:37AM -, Joe Hershberger wrote: > Add commands to access data in the fdt. This allows data from a dtb > or itb to be accessed from the shell scripts. > > Signed-off-by: Joe Hershberger This adds: $ uboot-build.sh sandbox Testing sandbox on -00386-g5e8f983 Thu Oct 25 14:07:28 MST 2012 Configuring for sandbox board... textdata bss dec hex filename 1431016424 28488 178013 2b75d sandbox/u-boot cmd_fdt.c: In function 'do_fdt': cmd_fdt.c:378:29: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] -- 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 3/6] serial: Reorder serial_assign()
Hi, On Thu, Oct 25, 2012 at 12:03 PM, Marek Vasut wrote: > Dear Simon Glass, > >> Hi, >> >> On Mon, Oct 22, 2012 at 10:23 AM, Allen Martin wrote: >> > On Sat, Oct 20, 2012 at 01:19:00AM -0700, Marek Vasut wrote: >> >> Dear Allen Martin, >> >> >> >> [...] >> >> >> >> > Hi Marek, the change to return value here broke serial output on >> >> > tegra. What I see is that the serial device name (s->name) is >> >> > "eserial0" as set by serial_ns16550.c, and the name passed in from the >> >> > stdout environment is "serial" so they don't match and it fails. This >> >> > always used to be ok because the return code didn't indicate failure >> >> > and iomux_doenv() would continue on happily, but now it causes >> >> > iomux_doenv() to fail and no printfs() work after that. >> >> > >> >> > Not sure what the right fix is, should stdout really be set to >> >> > "eserial0"? It seems "serial" should mean "the default serial device" >> >> > which for the normal case is the one and only device. >> >> >> >> Looking at the source, the obvious course of action is to fix iomux.c . >> > >> > I've been looking at this call to serial_assign() from iomux.c and I'm >> > not convinced this code does anything meaningful at all. It passes >> > the name of a struct stdio_dev device which serial_assign() then tries >> > to match against the registered struct serial_devices, which will >> > never match. >> > >> > What I don't understand is the case where you have a board that >> > actually has more than one physical serial port and how the mapping >> > from stdio_dev to serial_device happens. >> > >> > Also, looking at the code to cmd_nvedit, I think your change also broke >> > "setenv stdout" for boards that don't define CONFIG_CONSOLE_MUX. We >> > always have this on for tegra, so we don't go down this code path, but >> > it looks identical to the code in iomux.c >> >> Sorry if I missed it - what was the resolution here? Should we revert >> that change? > > Definitelly not. We should fix the iomux.c , possibly by flipping the > inequation > mark as a short term solution. OK that's fine. Is someone working on a patch? Regards, Simon > > Best regards, > Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/6] fdt: Limit printed hex in fdt print and list commands
On Fri, Aug 17, 2012 at 10:34:36AM -, Joe Hershberger wrote: > Prevent printing the entire image in a itb. It is most likely unhelpful > to have the hex of the entire image scroll for minutes on your slow > serial console. > > Signed-off-by: Joe Hershberger This causes: $ uboot-build.sh sandboxTesting sandbox on -4-gf0a29d4 Thu Oct 25 13:59:03 MST 2012 Configuring for sandbox board... textdata bss dec hex filename 1402456332 28472 175049 2abc9 sandbox/u-boot cmd_fdt.c: In function 'print_data': cmd_fdt.c:679:32: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] cmd_fdt.c:691:32: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] -- 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 3/6] serial: Reorder serial_assign()
On Thu, Oct 25, 2012 at 12:03:47PM -0700, Marek Vasut wrote: > Dear Simon Glass, > > > Hi, > > > > On Mon, Oct 22, 2012 at 10:23 AM, Allen Martin wrote: > > > On Sat, Oct 20, 2012 at 01:19:00AM -0700, Marek Vasut wrote: > > >> Dear Allen Martin, > > >> > > >> [...] > > >> > > >> > Hi Marek, the change to return value here broke serial output on > > >> > tegra. What I see is that the serial device name (s->name) is > > >> > "eserial0" as set by serial_ns16550.c, and the name passed in from the > > >> > stdout environment is "serial" so they don't match and it fails. This > > >> > always used to be ok because the return code didn't indicate failure > > >> > and iomux_doenv() would continue on happily, but now it causes > > >> > iomux_doenv() to fail and no printfs() work after that. > > >> > > > >> > Not sure what the right fix is, should stdout really be set to > > >> > "eserial0"? It seems "serial" should mean "the default serial device" > > >> > which for the normal case is the one and only device. > > >> > > >> Looking at the source, the obvious course of action is to fix iomux.c . > > > > > > I've been looking at this call to serial_assign() from iomux.c and I'm > > > not convinced this code does anything meaningful at all. It passes > > > the name of a struct stdio_dev device which serial_assign() then tries > > > to match against the registered struct serial_devices, which will > > > never match. > > > > > > What I don't understand is the case where you have a board that > > > actually has more than one physical serial port and how the mapping > > > from stdio_dev to serial_device happens. > > > > > > Also, looking at the code to cmd_nvedit, I think your change also broke > > > "setenv stdout" for boards that don't define CONFIG_CONSOLE_MUX. We > > > always have this on for tegra, so we don't go down this code path, but > > > it looks identical to the code in iomux.c > > > > Sorry if I missed it - what was the resolution here? Should we revert > > that change? > > Definitelly not. We should fix the iomux.c , possibly by flipping the > inequation > mark as a short term solution. Adding Joe Hershberger to cc I think its safe to remove the call to serial_assign() altogether, as it's written now it will always fail. Reading through doc/driver-model/UDM-serial.txt the CONFIG_SERIAL_MULTI case should be handled transparently underneath iomux. The part that still not clear to me is what mechanism is supposed to be used to select the current serial port in a CONFIG_SERIAL_MULTI configuration? AFAICT the only caller of serial_assign() that actually passes the name of a serial device is in serial_initialize(): serial_assign(default_serial_console()->name); Should there be another environemnt variable that maps the stdio_dev "serial" to the current serial_device so you could do something like: ; get input from first serial port and USB keyboard # setenv serial eserial0 # setenv stdin serial,usbkbd ; get input from second serial port and USB keyboard # setenv serial eserial1 # setenv stdin seriak,usbkbd -Allen -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Merging device trees at runtime for module-based systems
Dear Daniel, In message <50893633.6070...@gmail.com> you wrote: > > Overwrites must be addressed in the first place. The most common example > is that a more generic part (the module tree) registers all details > about a peripheral up-front but then sets its status to 'disabled'. That > way, the more specific part (the base board tree) can overwrite this > property to 'okay' at wish to enable it and not care for the pre-defined > details. This is also how we do things in our device-trees. Agreed. > > I definitely can see the benefit of such a feature and would be happy > > if you could go forward and implement it. > > Ok then. I guess this should be something that can eventually be merged > back into libfdt? I can't speak for the FDT custodian, but I think this makes a lot of sense. 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 When the bosses talk about improving productivity, they are never talking about themselves. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] serial: Reorder serial_assign()
Dear Simon Glass, > Hi, > > On Mon, Oct 22, 2012 at 10:23 AM, Allen Martin wrote: > > On Sat, Oct 20, 2012 at 01:19:00AM -0700, Marek Vasut wrote: > >> Dear Allen Martin, > >> > >> [...] > >> > >> > Hi Marek, the change to return value here broke serial output on > >> > tegra. What I see is that the serial device name (s->name) is > >> > "eserial0" as set by serial_ns16550.c, and the name passed in from the > >> > stdout environment is "serial" so they don't match and it fails. This > >> > always used to be ok because the return code didn't indicate failure > >> > and iomux_doenv() would continue on happily, but now it causes > >> > iomux_doenv() to fail and no printfs() work after that. > >> > > >> > Not sure what the right fix is, should stdout really be set to > >> > "eserial0"? It seems "serial" should mean "the default serial device" > >> > which for the normal case is the one and only device. > >> > >> Looking at the source, the obvious course of action is to fix iomux.c . > > > > I've been looking at this call to serial_assign() from iomux.c and I'm > > not convinced this code does anything meaningful at all. It passes > > the name of a struct stdio_dev device which serial_assign() then tries > > to match against the registered struct serial_devices, which will > > never match. > > > > What I don't understand is the case where you have a board that > > actually has more than one physical serial port and how the mapping > > from stdio_dev to serial_device happens. > > > > Also, looking at the code to cmd_nvedit, I think your change also broke > > "setenv stdout" for boards that don't define CONFIG_CONSOLE_MUX. We > > always have this on for tegra, so we don't go down this code path, but > > it looks identical to the code in iomux.c > > Sorry if I missed it - what was the resolution here? Should we revert > that change? Definitelly not. We should fix the iomux.c , possibly by flipping the inequation mark as a short term solution. 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 1/4 V3] kerneldoc: Implant DocBook from Linux kernel
Dear Tom Rini, [...] > > > make --version ? > > > > GNU Make 3.81 > > OK, found it, posting a patch now. What exactly did you find? I don't see this problem with make 3.81 . 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 00/32] Initial sparse fix series
On Thu, Oct 25, 2012 at 01:59:45PM -0500, Kim Phillips wrote: > On Thu, 25 Oct 2012 10:46:54 -0700 > Tom Rini wrote: > > > On Tue, Oct 16, 2012 at 07:28:16PM -0500, Kim Phillips wrote: > > > > > This 32-patch series only begins to address making u-boot source more > > > 'sparseable,' or sparse-clean, ultimately to catch type, address space, > > > and endianness mismatches and generally improve code quality. E.g., in > > > this > > > initial dose whose main purpose is to reduce the output volume to workable > > > levels, a couple of endianness bugs are found and fixed in > > > of_bus_default_translate() and fdt_get_base_address(). See [PATCH 14/32] > > > common/fdt_support.c: sparse fixes. > > > > I want to repeat myself that I want to see sparse fixes come in. That > > said, I expect that for v2 you will have done MAKEALL -a $arch for every > > arch there's an ELDK 5.2.x toolchain for, at least, and there's no new > > so power, arm, and mips. Correct. > > problems popping up. If you like I can pastebin my MAKEALL wrapper that > > lets you tell it things like --arch arm --eldk-521 and it sets up the > > environment for the toolchain. > > please do. http://pastebin.com/rkRSL2d3 has it now. It's a little clumsy at times, for example for not-arm (biased, sorry) you need to do uboot-build.sh --arch powerpc --eldk-521 --cpu mpc85xx so that it sets up for arch/powerpc, and then the toolchain and then re-sets itself for cpu/mpc85xx. arch/cpu/soc default to NCPUS=1 NBUILDS=`grep -c processor /proc/cpuinfo` and single board targets default to letting MAKEALL guess right. I'm pretty sure that even on the bigger boxes this is still right. -- 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 2/2] mmc: Split device init to decouple OCR-polling delay
Hi, On Sun, Oct 21, 2012 at 1:12 AM, RgC wrote: > Hi All, > > On 2012.10/20, Simon Glass wrote: >> From: Che-Liang Chiou >> >> Most of time that MMC driver spends on initializing a device is polling >> OCR (operation conditions register). To decouple this polling loop, >> device init is split into two parts: The first part fires the OCR query >> command, and the second part polls the result. So the caller is now no >> longer bound to the OCR-polling delay; he may fire the query, go >> somewhere and then come back later for the result. >> >> To use this, call mmc_set_preinit() on any device which needs this. >> >> This can save significant amounts of time on boot (e.g. 200ms) by >> hiding the MMC init time behind other init. >> > > Please note that this patch has a conflict with the patch from Kim Phillips' > [U-Boot,28/32] drivers/mmc/mmc.c: sparse fixes (191937 in patchworks) > > I had to apply this patch first before patching Kim's modifications which > succeeds with the hunk offsets adjusted. It builds OK with the eldk 5.2.1 > for powerpc. Will test these on an ml507 when I have time. Yes I found the same. In fact Kim's patches don't apply to master for me. co upstream/master Note: checking out 'upstream/master'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b new_branch_name HEAD is now at 186fc4d... ColdFire: Add Freescale MCF54418TWR ColdFire development board support ~/u> patch -p1 <~/Downloads/U-Boot-28-32-drivers-mmc-mmc.c-sparse-fixes.patch patching file drivers/mmc/mmc.c Hunk #1 succeeded at 47 with fuzz 2 (offset -87 lines). Hunk #2 succeeded at 109 (offset -92 lines). Hunk #3 succeeded at 153 (offset -92 lines). Hunk #4 succeeded at 346 (offset -92 lines). Hunk #5 succeeded at 417 (offset -92 lines). Hunk #6 succeeded at 438 (offset -92 lines). Hunk #7 succeeded at 503 (offset -92 lines). Hunk #8 succeeded at 567 (offset -92 lines). Hunk #9 succeeded at 589 (offset -92 lines). Hunk #10 succeeded at 611 (offset -92 lines). Hunk #11 succeeded at 681 (offset -92 lines). Hunk #12 succeeded at 702 (offset -92 lines). Hunk #13 succeeded at 841 (offset -92 lines). Hunk #14 succeeded at 859 (offset -92 lines). Hunk #15 succeeded at 1014 (offset -92 lines). Hunk #16 succeeded at 1149 (offset -92 lines). Regards, Simon > > Regards, > Rommel > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v9] [RFC] Add dmmalloc module for DM.
Hello Graeme,
On Thu, Oct 25, 2012 at 3:40 AM, Graeme Russ wrote:
>> diff --git a/arch/arm/include/asm/global_data.h
>> b/arch/arm/include/asm/global_data.h
>> index 2b9af93..9045829 100644
>> --- a/arch/arm/include/asm/global_data.h
>> +++ b/arch/arm/include/asm/global_data.h
>> @@ -82,6 +82,9 @@ 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
>> +#ifdef CONFIG_SYS_EARLY_MALLOC
>> + void*early_heap;/* heap for early_malloc */
>> +#endif
>
> Why not early_heap_header *early_heap; ?
>
It might be.
Actually it is a good point because I am using 3 different ways of
dealing with addresses: 1) struct early_heap header * or struct
early_block_header * - I am using this when I want to access members
of the stucture or compute address past the structure (which is where
the heap or block starts); 2) phys_addr_t - which is plain integer and
I use this for simple computations when I do not want to worry about
pointer arithmetic; 3) void * when I have just plain address,
especially when I want to pass an addres among logical parts of the
mallocator or outside. This may a bit controversial and perhaps I
should replace it by specific strucutre pointers internally.
I am unable to decide: Should I remove struct early_heap_header from
dmmalloc.h making it publicly unavailable or should I rather change
the void * to struct early_heap_header * in the GD structure? What do
you think is better?
> diff --git a/common/Makefile b/common/Makefile
>> index fdfead7..bfb4d7a 100644
>> --- a/common/Makefile
>> +++ b/common/Makefile
>> @@ -209,6 +209,7 @@ COBJS-y += dlmalloc.o
>> COBJS-y += image.o
>> COBJS-y += memsize.o
>> COBJS-y += stdio.o
>> +COBJS-$(CONFIG_DM) += dmmalloc.o
>
> COBJS-$(CONFIG_SYS_EARLY_MALLOC) += dmmalloc.o ?
Oh yes, now it is redundant to #ifdef CONFIG_SYS_EARLY_MALLOC inside
the dmmalloc.c file. I had a plan to extend the dmmalloc.c file by
relocation routines and then it would make sense. But I will shufle
the code a bit in the v10 anyway and we will see if the #ifdefs can
still be reduced.
>> +
>> +#include /* for ROUND_UP */
>> +#include
>> +#include /* for gd_t and gd */
>> +#include /* for phys_addr_t and size_addt_t */
>> +
>> +#include
>> +#include
>> +
>> +#include
>> +
>> +DECLARE_GLOBAL_DATA_PTR;
>> +
>> +#ifdef CONFIG_SYS_EARLY_MALLOC
>
> If you use COBJS-$(CONFIG_SYS_EARLY_MALLOC) += dmmalloc.o in the Makefile,
> you can drop this #ifdef
Yes, that is redundant now.
>
>> +__weak struct early_heap_header *early_brk(size_t size)
>> +{
>> + struct early_heap_header *h;
>> + struct early_block_header *b;
>> +
>> + if (gd->early_heap != NULL)
>> + return NULL;
>> +
>> + h = (struct early_heap_header *)CONFIG_SYS_EARLY_HEAP_ADDR;
>> + b = (struct early_block_header *)(h + 1);
>
> Hmmm, does this really work? I would have thought:
>
> b = (struct early_block_header *)(h + sizeof(struct early_heap_header));
>
> but I could be mistaken
It seems that it works as it is (at least I wrote bunch of tests and I
inspected resulting heaps and it was all right). I believe that since
h is a pointer to the struct early_heap_header then pointer arithmetic
is in effect and h+1 actually means "next element in the array of
struct early_heap_header". Which is the address past the header that
equals beginning of the heap data block. (?)
>> +int early_malloc_active(void)
>> +{
>> + return ((gd->flags & GD_FLG_RELOC) != GD_FLG_RELOC);
>> +}
>
> I think we need another flag - GD_FLG_RELOC gets set before the permanent
> heap is initialised, so there is a window of opportunity where things may
> break
Well, as I wrote in the commit message - this is only a temporary
implementation. I suppose I am going to change this when we have more
coarse initialization flags wired into DM (which I believe we are
going to have it anyway). So now I am just working around "forward
dependency" here.
>
>> +
>> +void early_heap_dump(struct early_heap_header *h)
>> +{
>> + struct early_block_header *b;
>> +
>> + debug("heap: h=%p, h->size=%d\n", h, h->size);
>> +
>> + b = (struct early_block_header *)(h+1);
>> + while ((phys_addr_t)b + sizeof(struct early_block_header)
>> + < (phys_addr_t)h + h->size) {
>> + debug("block: h=%p h->size=%d b=%p b->size=%d
>> b->(used)=%d\n",
>> + h, h->size, b, BLOCK_SIZE(b->size),
>> + BLOCK_USED(b->size));
>> + assert(BLOCK_SIZE(b->size) > 0);
>> + b = (struct early_block_header *)((phys_addr_t)b +
>> + sizeof(struct early_block_header) +
>> + BLOCK_SIZE(b->size));
>> + }
>> + debug("--- heap dump end ---\n");
>> +}
>
> Nice touch, but could we just iterate thr
Re: [U-Boot] [PATCH] common/cmd_ext_common: measure throughput
On Wed, Oct 17, 2012 at 12:16:14PM +0200, Andreas Bie??mann wrote:
> Dear Wolfgang Denk,
>
> On 17.10.2012 12:05, Wolfgang Denk wrote:
> > Dear Andreas Bie??mann,
> >
> > In message <1350467910-2014-1-git-send-email-andreas.de...@googlemail.com>
> > you wrote:
> >> This patch adds time measurement and throughput calculation for the
> >> ext2load and
> >> ext4load commands.
> > ...
> >> + unsigned long time_start;
> > ...
> >> + time_start = get_timer(0);
> >>if (ext4fs_read((char *)addr, filelen) != filelen) {
> >>printf("** Unable to read \"%s\" from %s %d:%d **\n",
> >> filename, argv[1], dev, part);
> >>ext4fs_close();
> >>goto fail;
> >>}
> >> + time_start = get_timer(time_start);
> >
> > There, "time_start" is clearly a mis-nomer. How about
> > s/time_start/time/ ?
>
> sounds better, however this is a plane copy from Simons tftp measurement
> patch.
>
> >> + print_size(filelen / time_start * 1000, "/s");
> >
> > Does this give reasonable results for small files, say when loading a
> > 20 byte file ?
>
> Well, possible no:
>
> ---8<---
> U-Boot> ext2load mmc 0 1002 /etc/hosts
> Loading file "/etc/hosts" from mmc device 0:1
> 20 bytes read in 0 ms
> U-Boot> ext2load mmc 0 1002 /etc/shadow
> Loading file "/etc/shadow" from mmc device 0:1
> 95 bytes read in 0 ms
> U-Boot> ext2load mmc 0 1002 /etc/passwd
> Loading file "/etc/passwd" from mmc device 0:1
> 366 bytes read in 0 ms
> U-Boot> ext2load mmc 0 1002 /etc/services
> Loading file "/etc/services" from mmc device 0:1
> 18465 bytes read in 3 ms (5.9 MiB/s)
> U-Boot>
> --->8---
>
> But as you see extremely short transfers are omitted due to time
> difference of '0' (at least on my avr32 system here).
> The main aim for this patch was to measure performance gain of Josh Wu's
> gen_atmel_mci patch for multiple block access, hopefully this is useful
> for others.
> I would like to have some feedback how the measurement is for very small
> files on other systems. Then I could provide a v2 which uses another
> variable name for the time.
I'm fine with not giving a speed on <1 ms transactions. Lets see a v2
with the new variable name, 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 00/32] Initial sparse fix series
On Thu, 25 Oct 2012 10:46:54 -0700 Tom Rini wrote: > On Tue, Oct 16, 2012 at 07:28:16PM -0500, Kim Phillips wrote: > > > This 32-patch series only begins to address making u-boot source more > > 'sparseable,' or sparse-clean, ultimately to catch type, address space, > > and endianness mismatches and generally improve code quality. E.g., in this > > initial dose whose main purpose is to reduce the output volume to workable > > levels, a couple of endianness bugs are found and fixed in > > of_bus_default_translate() and fdt_get_base_address(). See [PATCH 14/32] > > common/fdt_support.c: sparse fixes. > > I want to repeat myself that I want to see sparse fixes come in. That > said, I expect that for v2 you will have done MAKEALL -a $arch for every > arch there's an ELDK 5.2.x toolchain for, at least, and there's no new so power, arm, and mips. > problems popping up. If you like I can pastebin my MAKEALL wrapper that > lets you tell it things like --arch arm --eldk-521 and it sets up the > environment for the toolchain. please do. > I also needed to not apply patch 01/32 and so I can really only take 27 > and 32 right now (I'll reply separately once I really do). that's fine, thanks. Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MAKEALL: Add -s to '${MAKE} tidy' section
When BUILD_NBUILDS is > 1 we run the tidy command. With the addition of
DocBook this now includes a -C doc/DocBook and a 'entering/leaving' pair
of messages happen. Since we don't want to see what's being cleaned
here, we can just invoke make -s like we do when building.
Signed-off-by: Tom Rini
---
MAKEALL |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAKEALL b/MAKEALL
index 63f8bef..84a5c92 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -640,7 +640,7 @@ build_target() {
fi
if [ $BUILD_MANY == 1 ] ; then
- ${MAKE} tidy
+ ${MAKE} -s tidy
if [ -s ${LOG_DIR}/${target}.ERR ] ; then
cp ${LOG_DIR}/${target}.ERR
${OUTPUT_PREFIX}/ERR/${target}
--
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 1/4 V3] kerneldoc: Implant DocBook from Linux kernel
On Tue, Oct 23, 2012 at 04:03:29PM -0500, Andy Fleming wrote: > On Tue, Oct 23, 2012 at 3:58 PM, Tom Rini wrote: > > On Tue, Oct 23, 2012 at 02:56:58PM -0500, Andy Fleming wrote: > >> On Tue, Oct 23, 2012 at 2:30 AM, Marek Vasut wrote: > >> > Dear Andy Fleming, > >> > > >> > [...] > >> > > >> >> This patch makes it so that MAKEALL doesn't build silently anymore: > >> >> > >> >> > >> >> make[1]: Entering directory `/local/afleming/u-boot/doc/DocBook' > >> >> make[1]: Leaving directory `/local/afleming/u-boot/doc/DocBook' > >> >> > >> >> > >> >> Any ideas how we can fix that? > >> > > >> > I thought this was fixed, where do you see it? > >> > > >> > $ BUILD_DIR=/tmp/test ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- > >> > ./MAKEALL m28evk > >> > Configuring for m28evk board... > >> >textdata bss dec hex filename > >> > 4245797784 288876 721239 b0157 /tmp/test/u-boot > >> >6984 760 077441e40 /tmp/test/spl/u-boot-spl > >> > >> > >> Hmm, with the latest tree I get: > >> > >> [afleming@right u-boot (master)]$ ./MAKEALL P2020RDB_NAND > >> Configuring for P2020RDB_NAND - Board: P1_P2_RDB, Options: P2020RDB,NAND > >> make[1]: Entering directory `/local/afleming/u-boot/doc/DocBook' > >> make[1]: Leaving directory `/local/afleming/u-boot/doc/DocBook' > >>textdata bss dec hex filename > >> 399394 16752 267792 683938 a6fa2 ./build/P2020RDB_NAND/u-boot > > > > make --version ? > > GNU Make 3.81 OK, found it, posting a patch now. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-ti/master
Hello, The following changes since commit 39826f09978a0a7070999acc15babf88f03e4051: arm: fdt: Relocate fdt along with other data (2012-10-19 21:38:27 +0200) are available in the git repository at: git://git.denx.de/u-boot-ti.git master for you to fetch changes up to c7d35bef255dedb3ec3856982f042dde514676b0: am33xx/ddr_defs.h: rename DDR2/DDR3 defines to their actual part numbers (2012-10-25 11:31:38 -0700) Andrew Bradford (1): configs: Fix usage of mmc rescan Igor Grinberg (1): cm-t35: clean unused defines from config Joel A Fernandes (1): am33xx: Enable DDR3 for DDR3 version of beaglebone Pankaj Bharadiya (1): USB: musb_udc: Make musb_peri_rx_ep check for MUSB_RXCSR_RXPKTRDY Peter Korsgaard (7): omap3_spi: introduce CONFIG_OMAP3_SPI_D0_D1_SWAPPED am33xx/board.c: make wdtimer/uart_base static am33xx: move ti i2c baseboard header handling to board/ti/am335x/ am33xx/board: use cpu_mmc_init() for default mmc initialization am33xx: move generic parts of pinmux handling out from board/ti/am335x am33xx: support board specific ddr settings am33xx/ddr_defs.h: rename DDR2/DDR3 defines to their actual part numbers Stefano Babic (5): OMAP3: mt_ventoux: power on USB at startup OMAP3: updated pinmux and environment for new revision of mcx board OMAP3: mcx: updated to new hardware revision VIDEO: add macro to set LCD size for DSS driver OMAP3: add video support to the mcx board Tom Rini (2): omapimage: Add support for byteswapped SPI images am33xx: Add SPI SPL as an option Vaibhav Hiremath (1): am335x: Enable RTC 32K OSC clock arch/arm/cpu/armv7/am33xx/Makefile |1 + arch/arm/cpu/armv7/am33xx/board.c| 239 +--- arch/arm/cpu/armv7/am33xx/clock.c|6 + arch/arm/cpu/armv7/am33xx/config.mk |1 + arch/arm/cpu/armv7/am33xx/emif4.c| 114 +--- arch/arm/cpu/armv7/am33xx/mux.c | 33 +++ arch/arm/include/asm/arch-am33xx/cpu.h | 15 + arch/arm/include/asm/arch-am33xx/ddr_defs.h | 69 ++--- arch/arm/include/asm/arch-am33xx/hardware.h |4 + arch/arm/include/asm/arch-am33xx/mux.h | 261 ++ arch/arm/include/asm/arch-am33xx/spl.h |1 + arch/arm/include/asm/arch-am33xx/sys_proto.h | 27 -- arch/arm/include/asm/arch-omap3/dss.h|1 + board/htkw/mcx/mcx.c | 48 +++- board/htkw/mcx/mcx.h | 30 +- board/teejet/mt_ventoux/mt_ventoux.c |8 + board/ti/am335x/Makefile |1 + board/ti/am335x/board.c | 376 ++ board/ti/am335x/board.h | 49 board/ti/am335x/mux.c| 250 + drivers/spi/omap3_spi.c | 11 +- drivers/usb/musb/musb_udc.c | 11 +- include/configs/am335x_evm.h |9 +- include/configs/am3517_crane.h |2 +- include/configs/am3517_evm.h |2 +- include/configs/cm_t35.h | 14 +- include/configs/devkit8000.h |2 +- include/configs/igep00x0.h |2 +- include/configs/mcx.h| 31 ++- include/configs/mx28evk.h|2 +- include/configs/mx51evk.h|2 +- include/configs/mx53ard.h|2 +- include/configs/mx53evk.h|2 +- include/configs/mx53loco.h |2 +- include/configs/mx53smd.h|2 +- include/configs/mx6qarm2.h |2 +- include/configs/mx6qsabrelite.h |2 +- include/configs/omap3_beagle.h |2 +- include/configs/omap3_evm.h |2 +- include/configs/omap3_logic.h|2 +- include/configs/omap3_overo.h|2 +- include/configs/omap3_zoom1.h|2 +- include/configs/omap4_common.h |2 +- include/configs/omap5_evm.h |2 +- include/configs/tricorder.h |2 +- spl/Makefile |9 +- tools/omapimage.c| 83 -- 47 files changed, 998 insertions(+), 744 deletions(-) create mode 100644 arch/arm/cpu/armv7/am33xx/mux.c create mode 100644 arch/arm/include/asm/arch-am33xx/mux.h create mode 100644 board/ti/am335x/board.c create mode 100644 board/ti/am335x/board.h Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 04/20] scsi: Add function and env var to report number of scsi drives
From: Stefan Reinauer
Add a new function to find out the number of available SCSI disks. Also
set the 'scsidevs' environment variable after each scan.
Signed-off-by: Stefan Reinauer
Signed-off-by: Simon Glass
---
Changes in v2:
- Set 'scsidevs' environment variable to number of SCSI disks
README|3 +++
common/cmd_scsi.c |8
include/scsi.h|2 ++
3 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/README b/README
index 69da2b8..801772c 100644
--- a/README
+++ b/README
@@ -1039,6 +1039,9 @@ The following options need to be configured:
devices.
CONFIG_SYS_SCSI_SYM53C8XX_CCF to fix clock timing (80Mhz)
+The environment variable 'scsidevs' is set to the number of
+SCSI devices found during the last scan.
+
- NETWORK Support (PCI):
CONFIG_E1000
Support for Intel 8254x/8257x gigabit chips.
diff --git a/common/cmd_scsi.c b/common/cmd_scsi.c
index 30d8d12..5e7b480 100644
--- a/common/cmd_scsi.c
+++ b/common/cmd_scsi.c
@@ -182,6 +182,14 @@ removable:
scsi_curr_dev=0;
else
scsi_curr_dev = -1;
+
+ printf("Found %d device(s).\n", scsi_max_devs);
+ setenv("scsidevs", scsi_max_devs);
+}
+
+int scsi_get_disk_count(void)
+{
+ return scsi_max_devs;
}
#ifdef CONFIG_PCI
diff --git a/include/scsi.h b/include/scsi.h
index 89ae45f..9681d19 100644
--- a/include/scsi.h
+++ b/include/scsi.h
@@ -189,6 +189,8 @@ void scsi_low_level_init(int busdevfunc);
void scsi_init(void);
void scsi_scan(int mode);
+/** @return the number of scsi disks */
+int scsi_get_disk_count(void);
#define SCSI_IDENTIFY 0xC0 /* not used */
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
On Tue, Oct 23, 2012 at 11:19:29AM -0700, Tom Rini wrote: > Hello, > > The following changes since commit 39826f09978a0a7070999acc15babf88f03e4051: > > arm: fdt: Relocate fdt along with other data (2012-10-19 21:38:27 +0200) > > are available in the git repository at: > > git://git.denx.de/u-boot-ti.git master > > for you to fetch changes up to 6b943a40273f847a29586e6aa0e756f90d75f38f: > > am33xx: Add SPI SPL as an option (2012-10-23 08:34:10 -0700) This has been superseded by another request I will be sending shortly. -- 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 V3 5/5] ARM: tegra: don't request GPIO from Seaboard's SPL
Hi, On Mon, Oct 22, 2012 at 9:19 AM, Stephen Warren wrote: > From: Stephen Warren > > Seaboard has a GPIO that switches an external mux between Tegra's debug > UART and SPI flash. This is initialized from the SPL so that SPL debug > output can be seen. Simplify the code that does this, and don't actually > request the GPIO in the SPL; just program it. This saves ~4.5K from the > size of the SPL, mostly BSS due to the large gpio_names[] table that is > no longer required. This makes Seaboard's SPL fit within the current max > size. > > Signed-off-by: Stephen Warren > Acked-by: Simon Glass > Acked-by: Allen Martin I tested this series on seaboard. Tested-by: Simon Glass > --- > v3: No change. > v2: New patch to replace modification of CONFIG_SYS_TEXT_BASE. > --- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 4/5] ARM: tegra: select between Seaboard/Ventana at compile time
On Mon, Oct 22, 2012 at 9:19 AM, Stephen Warren wrote: > From: Stephen Warren > > Seaboard and Ventana are very similar boards, and so share the seaboard.c > board file. The one difference needed so far is detected at run-time by > calling machine_is_ventana(). This bloats the Ventana build with code > that is never used. Switch to detecting Ventana at compile time to remove > bloat. This shaves ~5K off the SPL size on Ventana, and makes the SPL fit > within the max size. > > Signed-off-by: Stephen Warren I tested this series on seaboard. Acked-by: Simon Glass Tested-by: Simon Glass > --- > v3: Combined back-to-back #ifdefs. > v2: New patch to replace modification of CONFIG_SYS_TEXT_BASE. > --- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 3/5] ARM: tegra: derive CONFIG_SPL_MAX_SIZE instead of hard-coding it
On Mon, Oct 22, 2012 at 9:19 AM, Stephen Warren wrote: > From: Stephen Warren > > For Tegra, the SPL and main U-Boot are concatenated together to form a > single memory image. Hence, the maximum SPL size is the different in > TEXT_BASE for SPL and main U-Boot. Instead of manually calculating > SPL_MAX_SIZE based on those two TEXT_BASE, which can lead to errors if > one TEXT_BASE is changed without updating SPL_MAX_SIZE, simply perform > the calculation automatically. > > Signed-off-by: Stephen Warren > Acked-by: Simon Glass > Acked-by: Allen Martin I tested this series on seaboard. Tested-by: Simon Glass > --- > v3: No change. > v2: New patch. > --- > include/configs/tegra20-common.h |3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/include/configs/tegra20-common.h > b/include/configs/tegra20-common.h > index 70c5cfb..c0c93e5 100644 > --- a/include/configs/tegra20-common.h > +++ b/include/configs/tegra20-common.h > @@ -188,7 +188,8 @@ > #define CONFIG_SPL > #define CONFIG_SPL_NAND_SIMPLE > #define CONFIG_SPL_TEXT_BASE 0x00108000 > -#define CONFIG_SPL_MAX_SIZE0x4000 > +#define CONFIG_SPL_MAX_SIZE(CONFIG_SYS_TEXT_BASE - \ > + CONFIG_SPL_TEXT_BASE) > #define CONFIG_SYS_SPL_MALLOC_START0x0009 > #define CONFIG_SYS_SPL_MALLOC_SIZE 0x0001 > #define CONFIG_SPL_STACK 0x000c > -- > 1.7.0.4 > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 2/5] ARM: enhance u-boot.lds to detect over-sized SPL
On Mon, Oct 22, 2012 at 10:52 AM, Tom Rini wrote: > On Mon, Oct 22, 2012 at 10:19:33AM -0600, Stephen Warren wrote: > >> From: Stephen Warren >> >> Add an ASSERT() to u-boot.lds to detect an SPL that doesn't fit within >> SPL_TEXT_BASE..SPL_MAX_SIZE. >> >> Different .lds files implement this check in two possible ways: >> 1) An ASSERT() like this >> 2) Defining a MEMORY region of size SPL_MAX_SIZE, and re-directing all >>linker output into that region. Since u-boot.lds is used for both >>SPL and main U-Boot, this would entail only sometimes defining a >>MEMORY region, and only sometimes performing that redirection, and >>hence option (1) was deemed much simpler, and hence implemented. >> >> Note that this causes build failures at least for NVIDIA Tegra Seaboard >> and Ventana. However, these are legitimate; the SPL doesn't fit within >> the required space, and this does cause runtime issues. >> >> Signed-off-by: Stephen Warren >> Acked-by: Simon Glass >> Acked-by: Allen Martin I tested this series on seaboard. Tested-by: Simon Glass > > This isn't quite what I envisoned at first (see > arch/arm/cpu/armv7/omap-common/u-boot-spl.lds) but I think for the > generic linker script, this is the least instrusive method. > > Acked-by: Tom Rini > > And since parts 1 and 2 are generic code, I've assigned them to Albert > in patchwork. It's his call if he wants to take them or have them all > come via the tegra tree. > > -- > Tom > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 1/5] ARM: fix u-boot.lds for -ffunction-sections/-fdata-sections
On Mon, Oct 22, 2012 at 9:19 AM, Stephen Warren wrote: > From: Stephen Warren > > When -ffunction-sections or -fdata-section are used, symbols are placed > into sections such as .data.eserial1_device and .bss.serial_current. > Update the linker script to explicitly include these. Without this > change (at least with my gcc-4.5.3 built using crosstool-ng), I see that > the sections do end up being included, but __bss_end__ gets set to the > same value as __bss_start. > > Signed-off-by: Stephen Warren > Acked-by: Allen Martin I tested this series on seaboard. Acked-by: Simon Glass Tested-by: Simon Glass Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] serial: Reorder serial_assign()
Hi, On Mon, Oct 22, 2012 at 10:23 AM, Allen Martin wrote: > On Sat, Oct 20, 2012 at 01:19:00AM -0700, Marek Vasut wrote: >> Dear Allen Martin, >> >> [...] >> > >> > Hi Marek, the change to return value here broke serial output on >> > tegra. What I see is that the serial device name (s->name) is >> > "eserial0" as set by serial_ns16550.c, and the name passed in from the >> > stdout environment is "serial" so they don't match and it fails. This >> > always used to be ok because the return code didn't indicate failure >> > and iomux_doenv() would continue on happily, but now it causes >> > iomux_doenv() to fail and no printfs() work after that. >> > >> > Not sure what the right fix is, should stdout really be set to >> > "eserial0"? It seems "serial" should mean "the default serial device" >> > which for the normal case is the one and only device. >> >> Looking at the source, the obvious course of action is to fix iomux.c . >> > > I've been looking at this call to serial_assign() from iomux.c and I'm > not convinced this code does anything meaningful at all. It passes > the name of a struct stdio_dev device which serial_assign() then tries > to match against the registered struct serial_devices, which will > never match. > > What I don't understand is the case where you have a board that > actually has more than one physical serial port and how the mapping > from stdio_dev to serial_device happens. > > Also, looking at the code to cmd_nvedit, I think your change also broke > "setenv stdout" for boards that don't define CONFIG_CONSOLE_MUX. We > always have this on for tegra, so we don't go down this code path, but > it looks identical to the code in iomux.c Sorry if I missed it - what was the resolution here? Should we revert that change? Regards, Simon > > -Allen > -- > nvpublic > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] USB detection
Truncated CCs Hi, On 2012.10/25, Manukumar wrote: > Dear All > > While board bring up in custom board > iam getting below mentioned error > > I2C: ready > DRAM: DDR: failed to read SPD from address It seems you are using a DIMM for your memory (as opposed to directly soldered on the board). Simply put, DDR DIMMs have a small EEPROM which contains data about the device. You access the SPD EEPROM via an I2C address. If the DIMM detection code talks to this address and does not detect correct data, then you have the problem you are encountering. Since you are using a custom board, you should read your specs or ask your HW people about the correct SPD address. > > I googled it but i am un able to rectify it.. > Please resole ASAP > manukumar > All the best, RgC pgpgpFkXy88XO.pgp Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/32] Initial sparse fix series
On Tue, Oct 16, 2012 at 07:28:16PM -0500, Kim Phillips wrote: > This 32-patch series only begins to address making u-boot source more > 'sparseable,' or sparse-clean, ultimately to catch type, address space, > and endianness mismatches and generally improve code quality. E.g., in this > initial dose whose main purpose is to reduce the output volume to workable > levels, a couple of endianness bugs are found and fixed in > of_bus_default_translate() and fdt_get_base_address(). See [PATCH 14/32] > common/fdt_support.c: sparse fixes. I want to repeat myself that I want to see sparse fixes come in. That said, I expect that for v2 you will have done MAKEALL -a $arch for every arch there's an ELDK 5.2.x toolchain for, at least, and there's no new problems popping up. If you like I can pastebin my MAKEALL wrapper that lets you tell it things like --arch arm --eldk-521 and it sets up the environment for the toolchain. I also needed to not apply patch 01/32 and so I can really only take 27 and 32 right now (I'll reply separately once I really do). -- 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 01/32] include/linux/byteorder: import latest endian definitions from linux
On Tue, Oct 16, 2012 at 07:28:17PM -0500, Kim Phillips wrote: > u-boot's byteorder headers did not contain endianness attributions > for use with sparse, causing a lot of false positives. Import the > kernel's latest definitions, and enable them by including compiler.h > and types.h. They come with 'const' added for some swab functions, so > fix those up, too: > > include/linux/byteorder/big_endian.h:46:2: warning: passing argument 1 of > '__swab64p' discards 'const' qualifier from pointer target type [enabled by > default] > > Also, note: u-boot's historic __BYTE_ORDER definition has been > preserved (for the time being at least). > > Signed-off-by: Kim Phillips This causes: $ uboot-build.sh afeb9260 Testing afeb9260 on -00382-g8391387 Thu Oct 25 10:36:06 MST 2012 Configuring for afeb9260 board... textdata bss dec hex filename 1980345648 72652 276334 4376e afeb9260/u-boot macb.c:54:0: warning: "barrier" redefined [enabled by default] .../include/linux/compiler-gcc.h:12:0: note: this is the location of the previous definition -- 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 13/32] common/misc: sparse fixes
On Tue, Oct 16, 2012 at 07:28:29PM -0500, Kim Phillips wrote: > command.c:44:38: error: bad constant expression > console.c:537:18: warning: symbol 'search_device' was not declared. Should it > be static? > dlmalloc.c:1468:2: warning: Using plain integer as NULL pointer > dlmalloc.c:1468:5: warning: Using plain integer as NULL pointer > dlmalloc.c:2176:12: warning: Using plain integer as NULL pointer > dlmalloc.c:2179:31: warning: Using plain integer as NULL pointer > dlmalloc.c:2382:14: warning: Using plain integer as NULL pointer > dlmalloc.c:2436:14: warning: Using plain integer as NULL pointer > dlmalloc.c:2582:31: warning: Using plain integer as NULL pointer > dlmalloc.c:2585:17: warning: Using plain integer as NULL pointer > dlmalloc.c:2646:14: warning: Using plain integer as NULL pointer > dlmalloc.c:2659:19: warning: Using plain integer as NULL pointer > dlmalloc.c:2692:19: warning: Using plain integer as NULL pointer > dlmalloc.c:2707:19: warning: Using plain integer as NULL pointer > dlmalloc.c:2708:14: warning: Using plain integer as NULL pointer > dlmalloc.c:2786:31: warning: Using plain integer as NULL pointer > dlmalloc.c:2801:12: warning: Using plain integer as NULL pointer > dlmalloc.c:2801:22: warning: Using plain integer as NULL pointer > dlmalloc.c:2926:27: warning: Using plain integer as NULL pointer > dlmalloc.c:2928:14: warning: Using plain integer as NULL pointer > dlmalloc.c:2929:12: warning: Using plain integer as NULL pointer > dlmalloc.c:3075:14: warning: Using plain integer as NULL pointer > hush.c:292:14: warning: symbol 'last_return_code' was not declared. Should it > be static? > hush.c:293:5: warning: symbol 'nesting_level' was not declared. Should it be > static? > hush.c:2175:20: warning: Using plain integer as NULL pointer > hush.c:2175:34: warning: Using plain integer as NULL pointer > hush.c:2210:41: warning: Using plain integer as NULL pointer > hush.c:2216:45: warning: Using plain integer as NULL pointer > hush.c:2249:25: warning: Using plain integer as NULL pointer > hush.c:2332:13: warning: symbol 'new_pipe' was not declared. Should it be > static? > hush.c:2390:5: warning: symbol 'reserved_word' was not declared. Should it be > static? > hush.c:2927:5: warning: symbol 'parse_stream' was not declared. Should it be > static? > hush.c:3127:6: warning: symbol 'mapset' was not declared. Should it be static? > hush.c:3133:6: warning: symbol 'update_ifs_map' was not declared. Should it > be static? > hush.c:3161:5: warning: symbol 'parse_stream_outer' was not declared. Should > it be static? > hush.c:3295:34: warning: Using plain integer as NULL pointer > hush.c:3631:5: warning: symbol 'do_showvar' was not declared. Should it be > static > image.c:1282:29: warning: Using plain integer as NULL pointer > image.c:1315:41: warning: Using plain integer as NULL pointer > image.c:1330:25: warning: Using plain integer as NULL pointer > image.c:1706:25: warning: Using plain integer as NULL pointer > main.c:510:10: warning: symbol 'hist_num' was not declared. Should it be > static? > main.c:512:5: warning: symbol 'hist_list' was not declared. Should it be > static? > main.c:513:6: warning: symbol 'hist_lines' was not declared. Should it be > static? > usb_storage.c:195:6: warning: symbol 'usb_show_progress' was not declared. > Should it be static? > usb_storage.c:440:48: warning: Using plain integer as NULL pointer > usb_storage.c:503:5: warning: symbol 'usb_stor_BBB_comdat' was not declared. > Should it be static? > usb_storage.c:551:5: warning: symbol 'usb_stor_CB_comdat' was not declared. > Should it be static? > usb_storage.c:629:55: warning: Using plain integer as NULL pointer > usb_storage.c:620:5: warning: symbol 'usb_stor_CBI_get_status' was not > declared. Should it be static? > usb_storage.c:675:43: warning: Using plain integer as NULL pointer > usb_storage.c:668:5: warning: symbol 'usb_stor_BBB_clear_endpt_stall' was not > declared. Should it be static? > usb_storage.c:679:5: warning: symbol 'usb_stor_BBB_transport' was not > declared. Should it be static? > usb_storage.c:801:5: warning: symbol 'usb_stor_CB_transport' was not > declared. Sh > xyzModem.c:104:1: warning: symbol 'CYGACC_COMM_IF_GETC_TIMEOUT' was not > declared. Should it be static? > xyzModem.c:122:1: warning: symbol 'CYGACC_COMM_IF_PUTC' was not declared. > Should it be static? > xyzModem.c:169:1: warning: symbol 'parse_num' was not declared. Should it be > stat > > note: hush.c's nesting_level deleted because not used. > > Signed-off-by: Kim Phillips This causes problems such as: $ uboot-build.sh netspace_lite_v2 Testing netspace_lite_v2 on -00399-gef44c78 Thu Oct 25 10:31:26 MST 2012 Configuring for netspace_lite_v2 - Board: lacie_kw, Options:NETSPACE_LITE_V2 console.c:537:26: error: static declaration of 'search_device' follows non-static declaration -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-B
Re: [U-Boot] [PATCH 0/6 V7] EXYNOS5: Enable SPI support
Hi Hatin, On Mon, Oct 22, 2012 at 4:52 AM, Hatim Ali wrote: > This patch set adds SPI driver for EXYNOS5 and enables same. > This patch set is based on latest Mainline u-boot.git tree. I have acked all of these. Regards, Simon > > Changes in V2: > - Correted the Commit message. > Changes in V3: > - Removed SPI_SLAVE Flag. > - Corrected warning messages. > Changes in V4: > - Rebased on mainline u-boot.git > - Incorporated review comments for SPI driver. > Changes in V5: > - Rebased on u-boot-samsung.git > - Incorporated review comments by Simon Glass > Changes in V6: > - Incorporated review comments by Minkyu Kang > Changes in V7: > - Incorporated review comments by Minkyu Kang & Simon Glass > > Rajeshwari Shinde (6): > EXYNOS5: Add pinmux support for SPI > EXYNOS: Add clock for SPI. > EXYNOS5: Add base address for SPI. > SPI: Add SPI Driver for EXYNOS. > EXYNOS5: Enable SPI > EXYNOS5: Enable SPI booting. > > arch/arm/cpu/armv7/exynos/clock.c | 125 ++ > arch/arm/cpu/armv7/exynos/pinmux.c| 51 > arch/arm/include/asm/arch-exynos/clk.h|2 +- > arch/arm/include/asm/arch-exynos/cpu.h|6 + > arch/arm/include/asm/arch-exynos/periph.h |5 + > arch/arm/include/asm/arch-exynos/spi.h| 78 ++ > board/samsung/smdk5250/Makefile |2 +- > board/samsung/smdk5250/mmc_boot.c | 58 - > board/samsung/smdk5250/smdk5250.c |4 + > board/samsung/smdk5250/spl_boot.c | 85 +++ > drivers/spi/Makefile |1 + > drivers/spi/exynos_spi.c | 366 > + > include/configs/smdk5250.h| 27 ++- > 13 files changed, 749 insertions(+), 61 deletions(-) > create mode 100644 arch/arm/include/asm/arch-exynos/spi.h > delete mode 100644 board/samsung/smdk5250/mmc_boot.c > create mode 100644 board/samsung/smdk5250/spl_boot.c > create mode 100644 drivers/spi/exynos_spi.c > > -- > 1.7.2.3 > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6 V7] EXYNOS5: Enable SPI booting.
On Mon, Oct 22, 2012 at 4:52 AM, Hatim Ali wrote: > From: Rajeshwari Shinde > > This patch enables SPI Booting for EXYNOS5 > > Signed-off-by: Rajeshwari Shinde Acked-by: Simon Glass > --- > Changes since v4: > No Change > Changes since v5: > No Change > Changes since v6: > No Change > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6 V7] EXYNOS5: Enable SPI
On Mon, Oct 22, 2012 at 4:52 AM, Hatim Ali wrote:
> From: Rajeshwari Shinde
>
> This patch enables SPI driver for EXYNOS5.
>
> Signed-off-by: Rajeshwari Shinde
> Signed-off-by: Hatim Ali
Acked-by: Simon Glass
> ---
> Changes since v4:
> - Rebased on u-boot-samsung.git
> Changes since v5:
> No change
> Changes since v6:
> Removed unused define from the config file
>
>
> diff --git a/board/samsung/smdk5250/smdk5250.c
> b/board/samsung/smdk5250/smdk5250.c
> index a5816e4..069c9e8 100644
> --- a/board/samsung/smdk5250/smdk5250.c
> +++ b/board/samsung/smdk5250/smdk5250.c
> @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -63,6 +64,9 @@ static int smc9115_pre_init(void)
> int board_init(void)
> {
> gd->bd->bi_boot_params = (PHYS_SDRAM_1 + 0x100UL);
> +#ifdef CONFIG_EXYNOS_SPI
> + spi_init();
> +#endif
> return 0;
> }
>
> diff --git a/include/configs/smdk5250.h b/include/configs/smdk5250.h
> index 9e3b55b..604c61e 100644
> --- a/include/configs/smdk5250.h
> +++ b/include/configs/smdk5250.h
> @@ -164,7 +164,6 @@
> #undef CONFIG_CMD_IMLS
> #define CONFIG_IDENT_STRING" for SMDK5250"
>
> -#define CONFIG_ENV_IS_IN_MMC
> #define CONFIG_SYS_MMC_ENV_DEV 0
>
> #define CONFIG_SECURE_BL1_ONLY
> @@ -213,6 +212,27 @@
> #define CONFIG_ENV_SROM_BANK 1
> #endif /*CONFIG_CMD_NET*/
>
> +/* SPI */
> +#define CONFIG_ENV_IS_IN_SPI_FLASH
> +#define CONFIG_SPI_FLASH
> +
> +#ifdef CONFIG_SPI_FLASH
> +#define CONFIG_EXYNOS_SPI
> +#define CONFIG_CMD_SF
> +#define CONFIG_CMD_SPI
> +#define CONFIG_SPI_FLASH_WINBOND
> +#define CONFIG_SF_DEFAULT_MODE SPI_MODE_0
> +#define CONFIG_SF_DEFAULT_SPEED5000
> +#define EXYNOS5_SPI_NUM_CONTROLLERS5
> +#endif
> +
> +#ifdef CONFIG_ENV_IS_IN_SPI_FLASH
> +#define CONFIG_ENV_SPI_MODESPI_MODE_0
> +#define CONFIG_ENV_SECT_SIZE CONFIG_ENV_SIZE
> +#define CONFIG_ENV_SPI_BUS 1
> +#define CONFIG_ENV_SPI_MAX_HZ 5000
> +#endif
> +
> /* Enable PXE Support */
> #ifdef CONFIG_CMD_NET
> #define CONFIG_CMD_PXE
> --
> 1.7.2.3
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6 V7] EXYNOS: Add clock for SPI.
On Mon, Oct 22, 2012 at 4:52 AM, Hatim Ali wrote: > From: Rajeshwari Shinde > > This patch adds api to calculate and set the clock for SPI channels > > Signed-off-by: James Miller > Signed-off-by: Simon Glass > Signed-off-by: Rajeshwari Shinde > Signed-off-by: Hatim Ali Acked-by: Simon Glass > --- > Changes since v4: > Added Signed-off-by of James Miller > Changes since v5: > Incorporated review comments by Minkyu Kang > Changes since v6: > Based on the review by Minkyu Kang, moved the include periph.h define > to > clock.c file > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6 V7] EXYNOS5: Add pinmux support for SPI
On Mon, Oct 22, 2012 at 4:52 AM, Hatim Ali wrote:
> From: Rajeshwari Shinde
>
> This patch adds pinmux support for SPI channels
>
> Signed-off-by: Rajeshwari Shinde
> Signed-off-by: Hatim Ali
Acked-by: Simon Glass
> ---
> Changes since v4:
> Fixed minor nits suggested by Simon Glass
> Changes since v5:
> No change
> Changes since v6:
> Incorporated review comments by Simon Glass & Minkyu Kang
>
> diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c
> b/arch/arm/cpu/armv7/exynos/pinmux.c
> index 5796d56..3ecbf7d 100644
> --- a/arch/arm/cpu/armv7/exynos/pinmux.c
> +++ b/arch/arm/cpu/armv7/exynos/pinmux.c
> @@ -112,6 +112,7 @@ static int exynos5_mmc_config(int peripheral, int flags)
> s5p_gpio_set_pull(bank, i, GPIO_PULL_UP);
> s5p_gpio_set_drv(bank, i, GPIO_DRV_4X);
> }
> +
> return 0;
> }
>
> @@ -230,6 +231,49 @@ static void exynos5_i2c_config(int peripheral, int flags)
> }
> }
>
> +void exynos5_spi_config(int peripheral)
> +{
> + int cfg = 0, pin = 0, i;
> + struct s5p_gpio_bank *bank = NULL;
> + struct exynos5_gpio_part1 *gpio1 =
> + (struct exynos5_gpio_part1 *) samsung_get_base_gpio_part1();
> + struct exynos5_gpio_part2 *gpio2 =
> + (struct exynos5_gpio_part2 *) samsung_get_base_gpio_part2();
> +
> + switch (peripheral) {
> + case PERIPH_ID_SPI0:
> + bank = &gpio1->a2;
> + cfg = GPIO_FUNC(0x2);
> + pin = 0;
> + break;
> + case PERIPH_ID_SPI1:
> + bank = &gpio1->a2;
> + cfg = GPIO_FUNC(0x2);
> + pin = 4;
> + break;
> + case PERIPH_ID_SPI2:
> + bank = &gpio1->b1;
> + cfg = GPIO_FUNC(0x5);
> + pin = 1;
> + break;
> + case PERIPH_ID_SPI3:
> + bank = &gpio2->f1;
> + cfg = GPIO_FUNC(0x2);
> + pin = 0;
> + break;
> + case PERIPH_ID_SPI4:
> + for (i = 0; i < 2; i++) {
> + s5p_gpio_cfg_pin(&gpio2->f0, i + 2, GPIO_FUNC(0x4));
> + s5p_gpio_cfg_pin(&gpio2->e0, i + 4, GPIO_FUNC(0x4));
> + }
> + break;
> + }
> + if (peripheral != PERIPH_ID_SPI4) {
> + for (i = pin; i < pin + 4; i++)
> + s5p_gpio_cfg_pin(bank, i, cfg);
> + }
> +}
> +
> static int exynos5_pinmux_config(int peripheral, int flags)
> {
> switch (peripheral) {
> @@ -257,6 +301,13 @@ static int exynos5_pinmux_config(int peripheral, int
> flags)
> case PERIPH_ID_I2C7:
> exynos5_i2c_config(peripheral, flags);
> break;
> + case PERIPH_ID_SPI0:
> + case PERIPH_ID_SPI1:
> + case PERIPH_ID_SPI2:
> + case PERIPH_ID_SPI3:
> + case PERIPH_ID_SPI4:
> + exynos5_spi_config(peripheral);
> + break;
> default:
> debug("%s: invalid peripheral %d", __func__, peripheral);
> return -1;
> diff --git a/arch/arm/include/asm/arch-exynos/periph.h
> b/arch/arm/include/asm/arch-exynos/periph.h
> index 082611c..4054fb6 100644
> --- a/arch/arm/include/asm/arch-exynos/periph.h
> +++ b/arch/arm/include/asm/arch-exynos/periph.h
> @@ -44,6 +44,11 @@ enum periph_id {
> PERIPH_ID_SDMMC3,
> PERIPH_ID_SDMMC4,
> PERIPH_ID_SROMC,
> + PERIPH_ID_SPI0,
> + PERIPH_ID_SPI1,
> + PERIPH_ID_SPI2,
> + PERIPH_ID_SPI3,
> + PERIPH_ID_SPI4,
> PERIPH_ID_UART0,
> PERIPH_ID_UART1,
> PERIPH_ID_UART2,
> --
> 1.7.2.3
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6 V7] SPI: Add SPI Driver for EXYNOS.
Hi Hatim,
On Mon, Oct 22, 2012 at 4:52 AM, Hatim Ali wrote:
> From: Rajeshwari Shinde
>
> This patch adds SPI driver for EXYNOS.
>
> Signed-off-by: Simon Glass
> Signed-off-by: Padmavathi Venna
> Signed-off-by: Gabe Black
> Signed-off-by: Rajeshwari Shinde
> Signed-off-by: Hatim Ali
> Acked-by: Mike Frysinger
> Tested-by: jy0922.s...@samsung.com
Acked-by: Simon Glass
> ---
> Changes since V4:
> - Changed SPI bus frequency to 10 Mhz
> Changes since V5:
> - Incorporated changes by Minkyu Kang
> Changes since V6:
> - No Change
>
>
> diff --git a/arch/arm/include/asm/arch-exynos/spi.h
> b/arch/arm/include/asm/arch-exynos/spi.h
> new file mode 100644
> index 000..7cab1e9
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-exynos/spi.h
> @@ -0,0 +1,78 @@
> +/*
> + * (C) Copyright 2012 SAMSUNG Electronics
> + * Padmavathi Venna
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> + */
> +
> +#ifndef __ASM_ARCH_EXYNOS_COMMON_SPI_H_
> +#define __ASM_ARCH_EXYNOS_COMMON_SPI_H_
> +
> +#ifndef __ASSEMBLY__
> +
> +/* SPI peripheral register map; padded to 64KB */
> +struct exynos_spi {
> + unsigned intch_cfg; /* 0x00 */
> + unsigned char reserved0[4];
> + unsigned intmode_cfg; /* 0x08 */
> + unsigned intcs_reg; /* 0x0c */
> + unsigned char reserved1[4];
> + unsigned intspi_sts;/* 0x14 */
> + unsigned inttx_data;/* 0x18 */
> + unsigned intrx_data;/* 0x1c */
> + unsigned intpkt_cnt;/* 0x20 */
> + unsigned char reserved2[4];
> + unsigned char reserved3[4];
> + unsigned intfb_clk; /* 0x2c */
> + unsigned char padding[0xffd0];
> +};
> +
> +#define EXYNOS_SPI_MAX_FREQ5000
> +
> +#define SPI_TIMEOUT_MS 10
> +
> +/* SPI_CHCFG */
> +#define SPI_CH_HS_EN (1 << 6)
> +#define SPI_CH_RST (1 << 5)
> +#define SPI_SLAVE_MODE (1 << 4)
> +#define SPI_CH_CPOL_L (1 << 3)
> +#define SPI_CH_CPHA_B (1 << 2)
> +#define SPI_RX_CH_ON (1 << 1)
> +#define SPI_TX_CH_ON (1 << 0)
> +
> +/* SPI_MODECFG */
> +#define SPI_MODE_CH_WIDTH_WORD (0x2 << 29)
> +#define SPI_MODE_BUS_WIDTH_WORD(0x2 << 17)
> +
> +/* SPI_CSREG */
> +#define SPI_SLAVE_SIG_INACT(1 << 0)
> +
> +/* SPI_STS */
> +#define SPI_ST_TX_DONE (1 << 25)
> +#define SPI_FIFO_LVL_MASK 0x1ff
> +#define SPI_TX_LVL_OFFSET 6
> +#define SPI_RX_LVL_OFFSET 15
> +
> +/* Feedback Delay */
> +#define SPI_CLK_BYPASS (0 << 0)
> +#define SPI_FB_DELAY_90(1 << 0)
> +#define SPI_FB_DELAY_180 (2 << 0)
> +#define SPI_FB_DELAY_270 (3 << 0)
> +
> +/* Packet Count */
> +#define SPI_PACKET_CNT_EN (1 << 16)
> +
> +#endif /* __ASSEMBLY__ */
> +#endif
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> index f0b82c6..824d357 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -34,6 +34,7 @@ COBJS-$(CONFIG_BFIN_SPI) += bfin_spi.o
> COBJS-$(CONFIG_CF_SPI) += cf_spi.o
> COBJS-$(CONFIG_CF_QSPI) += cf_qspi.o
> COBJS-$(CONFIG_DAVINCI_SPI) += davinci_spi.o
> +COBJS-$(CONFIG_EXYNOS_SPI) += exynos_spi.o
> COBJS-$(CONFIG_KIRKWOOD_SPI) += kirkwood_spi.o
> COBJS-$(CONFIG_MPC52XX_SPI) += mpc52xx_spi.o
> COBJS-$(CONFIG_MPC8XXX_SPI) += mpc8xxx_spi.o
> diff --git a/drivers/spi/exynos_spi.c b/drivers/spi/exynos_spi.c
> new file mode 100644
> index 000..4ee774b
> --- /dev/null
> +++ b/drivers/spi/exynos_spi.c
> @@ -0,0 +1,366 @@
> +/*
> + * (C) Copyright 2012 SAMSUNG Electronics
> + * Padmavathi Venna
> + *
> + * 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.
> + *
Re: [U-Boot] [PATCH 0/9 V3] EXYNOS5: Add Audio support
Hi, On Mon, Oct 22, 2012 at 11:57 PM, Rajeshwari Shinde wrote: > This patchset adds the audio support for EXYNOS5. > This patchset plays a predefined beep sound. > > Rajeshwari Shinde (9): > SOUND: SAMSUNG: Add I2S driver > SOUND: Add WM8994 codec > Sound: Add command for audio playback > EXYNOS: Add I2S registers > EXYNOS: Add parameters required by I2S > EXYNOS: Add pinmux for I2S > EXYNOS: Add I2S base address > EXYNOS: Add clock for I2S > SMDK5250: Enable Sound > > Changes in V2: > - renamed i2s.c to samsung-i2s.c. > - made exynos_i2s_config pinmux function static. > - corrected the commit message for "Enable sound" patch. > Changes in V3: > - Incorporated comments from Simon Glass and Minkyu Kang. I have been through this again and it seems good to me, thanks. > > Makefile|1 + > arch/arm/cpu/armv7/exynos/clock.c | 120 > arch/arm/cpu/armv7/exynos/pinmux.c | 13 + > arch/arm/include/asm/arch-exynos/clk.h |3 + > arch/arm/include/asm/arch-exynos/clock.h| 29 + > arch/arm/include/asm/arch-exynos/cpu.h |3 + > arch/arm/include/asm/arch-exynos/i2s-regs.h | 66 +++ > arch/arm/include/asm/arch-exynos/periph.h |1 + > arch/arm/include/asm/arch-exynos/sound.h| 44 ++ > common/Makefile |1 + > common/cmd_sound.c | 96 > drivers/sound/Makefile | 48 ++ > drivers/sound/samsung-i2s.c | 358 > drivers/sound/sound.c | 228 > drivers/sound/wm8994.c | 792 > +++ > drivers/sound/wm8994.h | 87 +++ > drivers/sound/wm8994_registers.h| 299 ++ > include/configs/smdk5250.h |8 + > include/i2s.h | 127 + > include/sound.h | 62 +++ > 20 files changed, 2386 insertions(+), 0 deletions(-) > create mode 100644 arch/arm/include/asm/arch-exynos/i2s-regs.h > create mode 100644 arch/arm/include/asm/arch-exynos/sound.h > create mode 100644 common/cmd_sound.c > create mode 100644 drivers/sound/Makefile > create mode 100644 drivers/sound/samsung-i2s.c > create mode 100644 drivers/sound/sound.c > create mode 100644 drivers/sound/wm8994.c > create mode 100644 drivers/sound/wm8994.h > create mode 100644 drivers/sound/wm8994_registers.h > create mode 100644 include/i2s.h > create mode 100644 include/sound.h > > -- > 1.7.4.4 > Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/9 V3] EXYNOS: Add clock for I2S
On Mon, Oct 22, 2012 at 11:57 PM, Rajeshwari Shinde wrote: > This patch adds clock support for I2S > > Signed-off-by: R. Chandrasekar > Signed-off-by: Rajeshwari Shinde Acked-by: Simon Glass > --- > Changes in V2: > - None > Changes in V3: > - Changes clock function names as suggested by Minkyu Kang. > arch/arm/cpu/armv7/exynos/clock.c| 120 > ++ > arch/arm/include/asm/arch-exynos/clk.h |3 + > arch/arm/include/asm/arch-exynos/clock.h | 29 +++ > 3 files changed, 152 insertions(+), 0 deletions(-) > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/9 V3] Sound: Add command for audio playback
On Mon, Oct 22, 2012 at 11:57 PM, Rajeshwari Shinde
wrote:
> This patch adds command to test audio playback.
> sound init - Initialises the audio subsystem (i2s and wm8994 codec)
> sound play - Plays predefined the audio data when specified length
> and frequency.
>
> Signed-off-by: Rajeshwari Shinde
Acked-by: Simon Glass
> ---
> Changes in V2:
> - None
> Changes in V3:
> - Incorporated comments from Simon Glass.
> common/Makefile|1 +
> common/cmd_sound.c | 96
>
> 2 files changed, 97 insertions(+), 0 deletions(-)
> create mode 100644 common/cmd_sound.c
>
> diff --git a/common/Makefile b/common/Makefile
> index 5442fbb..c0aa4a3 100644
> --- a/common/Makefile
> +++ b/common/Makefile
> @@ -74,6 +74,7 @@ COBJS-$(CONFIG_CMD_CONSOLE) += cmd_console.o
> COBJS-$(CONFIG_CMD_CPLBINFO) += cmd_cplbinfo.o
> COBJS-$(CONFIG_DATAFLASH_MMC_SELECT) += cmd_dataflash_mmc_mux.o
> COBJS-$(CONFIG_CMD_DATE) += cmd_date.o
> +COBJS-$(CONFIG_CMD_SOUND) += cmd_sound.o
> ifdef CONFIG_4xx
> COBJS-$(CONFIG_CMD_SETGETDCR) += cmd_dcr.o
> endif
> diff --git a/common/cmd_sound.c b/common/cmd_sound.c
> new file mode 100644
> index 000..459d1eb
> --- /dev/null
> +++ b/common/cmd_sound.c
> @@ -0,0 +1,96 @@
> +/*
> + * Copyright (C) 2012 Samsung Electronics
> + * Rajeshwari Shinde
> + *
> + * 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
> +#include
> +#include
> +#include
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +/* Initilaise sound subsystem */
> +static int do_init(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[])
> +{
> + int ret;
> +
> + ret = sound_init();
> + if (ret) {
> + printf("Initialise Audio driver failed\n");
> + return CMD_RET_FAILURE;
> + }
> +
> + return 0;
> +}
> +
> +/* play sound from buffer */
> +static int do_play(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[])
> +{
> + int ret = 0;
> + int msec = 1000;
> + int freq = 400;
> +
> + if (argc > 1)
> + msec = simple_strtoul(argv[1], NULL, 10);
> + if (argc > 2)
> + freq = simple_strtoul(argv[2], NULL, 10);
> +
> + ret = sound_play(msec, freq);
> + if (ret) {
> + printf("play failed");
> + return CMD_RET_FAILURE;
> + }
> +
> + return 0;
> +}
> +
> +static cmd_tbl_t cmd_sound_sub[] = {
> + U_BOOT_CMD_MKENT(init, 0, 1, do_init, "", ""),
> + U_BOOT_CMD_MKENT(play, 2, 1, do_play, "", ""),
> +};
> +
> +/* process sound command */
> +static int do_sound(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[])
> +{
> + cmd_tbl_t *c;
> +
> + if (argc < 1)
> + return CMD_RET_USAGE;
> +
> + /* Strip off leading 'sound' command argument */
> + argc--;
> + argv++;
> +
> + c = find_cmd_tbl(argv[0], &cmd_sound_sub[0],
> ARRAY_SIZE(cmd_sound_sub));
> +
> + if (c)
> + return c->cmd(cmdtp, flag, argc, argv);
> + else
> + return CMD_RET_USAGE;
> +}
> +
> +U_BOOT_CMD(
> + sound, 4, 1, do_sound,
> + "sound sub-system",
> + "init - initialise the sound driver\n"
> + "sound play [len] [freq] - play a sound for len ms at freq hz\n"
> +);
> --
> 1.7.4.4
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/9 V3] SOUND: Add WM8994 codec
Hi, On Mon, Oct 22, 2012 at 11:57 PM, Rajeshwari Shinde wrote: > This patch adds driver for audio codec WM8994 > > Signed-off-by: R. Chandrasekar > Signed-off-by: Rajeshwari Shinde Acked-by: Simon Glass > --- > Changes in V2: > - None > Changes in V3: > - Incorporated comments from Simon Glass. Sometimes it is better to list the actual changes made. > drivers/sound/Makefile |1 + > drivers/sound/wm8994.c | 792 > ++ > drivers/sound/wm8994.h | 87 + > drivers/sound/wm8994_registers.h | 299 ++ > 4 files changed, 1179 insertions(+), 0 deletions(-) > create mode 100644 drivers/sound/wm8994.c > create mode 100644 drivers/sound/wm8994.h > create mode 100644 drivers/sound/wm8994_registers.h > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/9 V3] SOUND: SAMSUNG: Add I2S driver
Hi,
On Mon, Oct 22, 2012 at 11:57 PM, Rajeshwari Shinde
wrote:
> This patch adds driver for I2S interface specific to samsung.
>
> Signed-off-by: R. Chandrasekar
> Signed-off-by: Rajeshwari Shinde
> ---
> Changes in V2:
> - renamed i2s.c to samsung-i2s.c.
> Changes in V3:
> - wave sine table removed and the same in calculated in a function.
This looks great. There are a few style nits that you might want to
correct, but:
Acked-by: Simon Glass
> Makefile|1 +
> drivers/sound/Makefile | 47 ++
> drivers/sound/samsung-i2s.c | 358
> +++
> drivers/sound/sound.c | 228 +++
> include/i2s.h | 127 +++
> include/sound.h | 62
> 6 files changed, 823 insertions(+), 0 deletions(-)
> create mode 100644 drivers/sound/Makefile
> create mode 100644 drivers/sound/samsung-i2s.c
> create mode 100644 drivers/sound/sound.c
> create mode 100644 include/i2s.h
> create mode 100644 include/sound.h
>
> diff --git a/Makefile b/Makefile
> index a40d4cc..f7d7f47 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -293,6 +293,7 @@ LIBS-y += arch/powerpc/cpu/mpc8xxx/lib8xxx.o
> endif
> LIBS-y += drivers/rtc/librtc.o
> LIBS-y += drivers/serial/libserial.o
> +LIBS-y += drivers/sound/libsound.o
> LIBS-$(CONFIG_GENERIC_LPC_TPM) += drivers/tpm/libtpm.o
> LIBS-y += drivers/twserial/libtws.o
> LIBS-y += drivers/usb/eth/libusb_eth.o
> diff --git a/drivers/sound/Makefile b/drivers/sound/Makefile
> new file mode 100644
> index 000..18ad2c9
> --- /dev/null
> +++ b/drivers/sound/Makefile
> @@ -0,0 +1,47 @@
> +#
> +# Copyright (C) 2012 Samsung Electronics
> +# R. Chandrasekar
> +#
> +# 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 $(TOPDIR)/config.mk
> +
> +LIB:= $(obj)libsound.o
> +
> +COBJS-$(CONFIG_SOUND) += sound.o
> +COBJS-$(CONFIG_I2S)+= samsung-i2s.o
> +
> +COBJS := $(COBJS-y)
> +SRCS := $(COBJS:.o=.c)
> +OBJS := $(addprefix $(obj),$(COBJS))
> +
> +all: $(LIB)
> +
> +$(LIB):$(obj).depend $(OBJS)
> + $(call cmd_link_o_target, $(OBJS))
> +
> +#
> +
> +# defines $(obj).depend target
> +include $(SRCTREE)/rules.mk
> +
> +sinclude $(obj).depend
> +
> +#
> diff --git a/drivers/sound/samsung-i2s.c b/drivers/sound/samsung-i2s.c
> new file mode 100644
> index 000..3ce0b59
> --- /dev/null
> +++ b/drivers/sound/samsung-i2s.c
> @@ -0,0 +1,358 @@
> +/*
> + * Copyright (C) 2012 Samsung Electronics
> + * R. Chandrasekar
> + *
> + * 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
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define FIC_TX2COUNT(x)(((x) >> 24) & 0xf)
> +#define FIC_TX1COUNT(x)(((x) >> 16) & 0xf)
> +#define FIC_TXCOUNT(x) (((x) >> 8) & 0xf)
> +#define FIC_RXCOUNT(x) (((x) >> 0) & 0xf)
> +#define FICS_TXCOUNT(x)(((x) >> 8) & 0x7f)
> +
> +#define TIMEOUT_I2S_TX 100 /* i2s transfer timeout */
> +
> +/*
> + * Sets the frame size for I2S LR clock
> + *
> + * @param i2s_reg i2s regiter address
> + * @param rfs Frame Size
> + */
> +static void i2s_set_lr_framesize(struct i2s_reg *i2s_reg, unsigned int rfs)
> +{
> + unsigned int mod = readl(&i2s_reg->mod);
>
