[U-Boot] Test and hello
Hi, just wanted to test out my subscription and say hello. FYI I'm using u-boot on a PengPod1000 / Allwinner10 soc / sunxi. MfG Goswin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v1 1/2] blackfin: bf609: implement soft switch
From: Sonic Zhang sonic.zh...@analog.com
Set up soft switch pins properly in board init code.
Signed-off-by: Sonic Zhang sonic.zh...@analog.com
Signed-off-by: Scott Jiang scott.ji...@analog.com
Signed-off-by: Bob Liu lliu...@gmail.com
---
board/bf609-ezkit/soft_switch.c | 180 +++
board/bf609-ezkit/soft_switch.h | 71 +++
2 files changed, 251 insertions(+), 0 deletions(-)
create mode 100644 board/bf609-ezkit/soft_switch.c
create mode 100644 board/bf609-ezkit/soft_switch.h
diff --git a/board/bf609-ezkit/soft_switch.c b/board/bf609-ezkit/soft_switch.c
new file mode 100644
index 000..2e1404f
--- /dev/null
+++ b/board/bf609-ezkit/soft_switch.c
@@ -0,0 +1,180 @@
+/*
+ * U-boot - main board file
+ *
+ * Copyright (c) 2008-2011 Analog Devices Inc.
+ *
+ * Licensed under the GPL-2 or later.
+ */
+
+#include common.h
+#include asm/blackfin.h
+#include asm/io.h
+#include i2c.h
+#include soft_switch.h
+
+#define SWITCH_ADDR 0x21
+
+#define NUM_SWITCH 3
+#define IODIRA 0x0
+#define IODIRB 0x1
+#define OLATA 0x14
+#define OLATB 0x15
+
+struct switch_config {
+ uchar dir0; /* IODIRA */
+ uchar dir1; /* IODIRB */
+ uchar value0; /* OLATA */
+ uchar value1; /* OLATB */
+};
+
+static struct switch_config switch_config_array[NUM_SWITCH] = {
+ {
+/*
+ U45 Port A U45 Port B
+
+ 7--- RMII_CLK_EN | 7--- ~TEMP_THERM_EN
+ | 6- ~CNT0ZM_EN| | 6- ~TEMP_IRQ_EN
+ | | 5--- ~CNT0DG_EN| | | 5--- ~UART0CTS_146_EN
+ | | | 4- ~CNT0UD_EN| | | | 4- ~UART0CTS_RST_EN
+ | | | | 3--- ~CAN0RX_EN| | | | | 3--- ~UART0CTS_RTS_LPBK
+ | | | | | 2- ~CAN0_ERR_EN | | | | | | 2- ~UART0CTS_EN
+ | | | | | | 1--- ~CAN_STB | | | | | | | 1--- ~UART0RX_EN
+ | | | | | | | 0- CAN_EN | | | | | | | | 0- ~UART0RTS_EN
+ | | | | | | | || | | | | | | | |
+ O O O O O O O O| O O O O O O O O (I/O direction)
+ 1 0 0 0 0 0 1 1| 1 1 1 1 1 0 0 0 (value being set)
+*/
+ .dir0 = 0x0, /* all output */
+ .dir1 = 0x0, /* all output */
+ .value0 = RMII_CLK_EN | CAN_STB | CAN_EN,
+ .value1 = TEMP_THERM_EN | TEMP_IRQ_EN | UART0CTS_146_EN
+ | UART0CTS_RST_EN | UART0CTS_RTS_LPBK,
+ },
+ {
+/*
+ U46 Port A U46 Port B
+
+ 7--- ~LED4_GPIO_EN | 7--- EMPTY
+ | 6- ~LED3_GPIO_EN | | 6- ~SPI0D3_EN
+ | | 5--- ~LED2_GPIO_EN | | | 5--- ~SPI0D2_EN
+ | | | 4- ~LED1_GPIO_EN | | | | 4- ~SPIFLASH_CS_EN
+ | | | | 3--- SMC0_LP0_EN| | | | | 3--- ~SD_WP_EN
+ | | | | | 2- EMPTY | | | | | | 2- ~SD_CD_EN
+ | | | | | | 1--- SMC0_EPPI2 | | | | | | | 1--- ~PUSHBUTTON2_EN
+ _LP1_SWITCH
+ | | | | | | | 0- OVERRIDE_SMC0 | | | | | | | | 0- ~PUSHBUTTON1_EN
+ _LP0_BOOT
+ | | | | | | | | | | | | | | | | |
+ O O O O O O O O | O O O O O O O O (I/O direction)
+ 0 0 0 0 0 X 0 1 | X 0 0 0 0 0 0 0 (value being set)
+*/
+ .dir0 = 0x0, /* all output */
+ .dir1 = 0x0, /* all output */
+#ifdef CONFIG_BFIN_LINKPORT
+ .value0 = OVERRIDE_SMC0_LP0_BOOT,
+#else
+ .value0 = SMC0_EPPI2_LP1_SWITCH,
+#endif
+ .value1 = 0x0,
+ },
+ {
+/*
+ U47 Port A U47 Port B
+
+ 7--- ~PD2_SPI0MISO | 7--- EMPTY
+ _EI3_EN
+ | 6- ~PD1_SPI0D3 | | 6- EMPTY
+ _EPPI1D17
+ _SPI0SEL2
+ _EI3_EN
+ | | 5--- ~PD0_SPI0D2 | | | 5--- EMPTY
+ _EPPI1D16
+ _SPI0SEL3
+ _EI3_EN
+ | | | 4- ~WAKE_PUSH| | | | 4- EMPTY
+ BUTTON_EN
+ | | | | 3--- ~ETHERNET_EN | | | | | 3--- EMPTY
+ | | | | | 2- PHYAD0 | | | | | | 2- EMPTY
+ | | | | | | 1--- PHY_PWR | | | | | | | 1--- ~PD4_SPI0CK_EI3_EN
+ _DWN_INT
+ | | | | | | | 0- ~PHYINT_EN| | | | | | | | 0- ~PD3_SPI0MOSI_EI3_EN
+ | | | | | | | || | | | | | | | |
+ O O O O O I I O| O O O O O O O O (I/O direction)
+ 1 1 1 0 0 0 0 0| X X X X X X 1 1 (value being set)
+*/
+ .dir0 = 0x6, /* bits 1 and 2 input, all others
[U-Boot] [PATCH v1 2/2] blackfin: bf609: add softswitch config command
From: Bob Liu lliu...@gmail.com
Add softswitch_output command for bf609-ezkit to enable softswitches.
Signed-off-by: Bob Liu lliu...@gmail.com
Signed-off-by: Sonic Zhang sonic.zh...@analog.com
---
arch/blackfin/include/asm/soft_switch.h | 18 +
board/bf609-ezkit/soft_switch.c | 11 +---
board/bf609-ezkit/soft_switch.h | 25 +--
common/Makefile |1 +
common/cmd_softswitch.c | 41 +++
include/configs/bf609-ezkit.h |1 +
6 files changed, 79 insertions(+), 18 deletions(-)
create mode 100644 arch/blackfin/include/asm/soft_switch.h
create mode 100644 common/cmd_softswitch.c
diff --git a/arch/blackfin/include/asm/soft_switch.h
b/arch/blackfin/include/asm/soft_switch.h
new file mode 100644
index 000..ff8e44d
--- /dev/null
+++ b/arch/blackfin/include/asm/soft_switch.h
@@ -0,0 +1,18 @@
+/*
+ * U-boot - main board file
+ *
+ * Copyright (c) 2008-2012 Analog Devices Inc.
+ *
+ * Licensed under the GPL-2 or later.
+ */
+
+#ifndef __SOFT_SWITCH_H__
+#define __SOFT_SWITCH_H__
+
+#define IO_PORT_A 0
+#define IO_PORT_B 1
+#define IO_PORT_INPUT 0
+#define IO_PORT_OUTPUT 1
+
+int config_switch_bit(int num, int port, int bit, int dir, uchar value);
+#endif
diff --git a/board/bf609-ezkit/soft_switch.c b/board/bf609-ezkit/soft_switch.c
index 2e1404f..e0c8d93 100644
--- a/board/bf609-ezkit/soft_switch.c
+++ b/board/bf609-ezkit/soft_switch.c
@@ -12,14 +12,6 @@
#include i2c.h
#include soft_switch.h
-#define SWITCH_ADDR 0x21
-
-#define NUM_SWITCH 3
-#define IODIRA 0x0
-#define IODIRB 0x1
-#define OLATA 0x14
-#define OLATB 0x15
-
struct switch_config {
uchar dir0; /* IODIRA */
uchar dir1; /* IODIRB */
@@ -126,9 +118,8 @@ static int setup_soft_switch(int addr, struct switch_config
*config)
return i2c_write(addr, IODIRB, 1, config-dir1, 1);
}
-int config_switch_bit(int num, int port, int bit, int dir, uchar value)
+int config_switch_bit(int addr, int port, int bit, int dir, uchar value)
{
- int addr = SWITCH_ADDR + num;
int ret, data_reg, dir_reg;
uchar tmp;
diff --git a/board/bf609-ezkit/soft_switch.h b/board/bf609-ezkit/soft_switch.h
index 8da0e44..d147fe1 100644
--- a/board/bf609-ezkit/soft_switch.h
+++ b/board/bf609-ezkit/soft_switch.h
@@ -6,8 +6,10 @@
* Licensed under the GPL-2 or later.
*/
-#ifndef __SOFT_SWITCH_H__
-#define __SOFT_SWITCH_H__
+#ifndef __BOARD_SOFT_SWITCH_H__
+#define __BOARD_SOFT_SWITCH_H__
+
+#include asm/soft_switch.h
/* switch 0 port A */
#define CAN_EN 0x1
@@ -61,11 +63,18 @@
#define PD3_SPI0MOSI_EN0x1
#define PD4_SPI0CK_EN 0x2
-#define IO_PORT_A 0
-#define IO_PORT_B 1
-#define IO_PORT_INPUT 0
-#define IO_PORT_OUTPUT 1
+#ifdef CONFIG_BFIN_BOARD_VERSION_1_0
+#define SWITCH_ADDR 0x21
+#else
+#define SWITCH_ADDR 0x20
+#endif
+
+#define NUM_SWITCH 3
+#define IODIRA 0x0
+#define IODIRB 0x1
+#define OLATA 0x14
+#define OLATB 0x15
-int config_switch_bit(int num, int port, int bit, int dir, uchar value);
int setup_board_switches(void);
-#endif
+
+#endif /* __BOARD_SOFT_SWITCH_H__ */
diff --git a/common/Makefile b/common/Makefile
index 54fcc81..80fee78 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -157,6 +157,7 @@ COBJS-$(CONFIG_CMD_SF) += cmd_sf.o
COBJS-$(CONFIG_CMD_SCSI) += cmd_scsi.o
COBJS-$(CONFIG_CMD_SHA1SUM) += cmd_sha1sum.o
COBJS-$(CONFIG_CMD_SETEXPR) += cmd_setexpr.o
+COBJS-$(CONFIG_CMD_SOFTSWITCH) += cmd_softswitch.o
COBJS-$(CONFIG_CMD_SPI) += cmd_spi.o
COBJS-$(CONFIG_CMD_SPIBOOTLDR) += cmd_spibootldr.o
COBJS-$(CONFIG_CMD_STRINGS) += cmd_strings.o
diff --git a/common/cmd_softswitch.c b/common/cmd_softswitch.c
new file mode 100644
index 000..f75d926
--- /dev/null
+++ b/common/cmd_softswitch.c
@@ -0,0 +1,41 @@
+/*
+ * cmd_softswitch.c - set the softswitch for bf60x
+ *
+ * Copyright (c) 2012 Analog Devices Inc.
+ *
+ * Licensed under the GPL-2 or later.
+ */
+
+#include common.h
+#include command.h
+#include asm/blackfin.h
+#include asm/soft_switch.h
+
+int do_softswitch(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ int switchaddr, value, pin, port;
+
+ if (argc != 5)
+ return CMD_RET_USAGE;
+
+ if (strcmp(argv[2], GPA) == 0)
+ port = IO_PORT_A;
+ else if (strcmp(argv[2], GPB) == 0)
+ port = IO_PORT_B;
+ else
+ return CMD_RET_USAGE;
+
+ switchaddr = simple_strtoul(argv[1], NULL, 16);
+ pin = simple_strtoul(argv[3], NULL, 16);
+ value = simple_strtoul(argv[4], NULL, 16);
+
+ config_switch_bit(switchaddr, port, (1 pin), IO_PORT_OUTPUT, value);
+
+ return 0;
+}
+
+U_BOOT_CMD(
+ softswitch_output, 5, 1, do_softswitch,
+
Re: [U-Boot] [RFC PATCH v2 02/15] at91: Correct CONFIG_AUTOBOOT_PROMPT definition for pm9263
Hi Simon, On Mon, Feb 25, 2013 at 11:28 PM, Simon Glass s...@chromium.org wrote: Hi Joe, On Sun, Feb 24, 2013 at 11:53 AM, Joe Hershberger joe.hershber...@gmail.com wrote: Hi Simon, On Sun, Feb 24, 2013 at 11:26 AM, Simon Glass s...@chromium.org wrote: This is not currently used, since autoboot is not enabled for this board, but the string is missing a parameter. Add it. Why not enable autoboot for this board so that this setting gets testing? Actually with autoconf this setting is tested, which is how I found the problem. The old code used #ifdef and so the problem was masked. Or do you think I should enable because that was probably the board vendor's indent? What I was thinking is that if the board sets the configuration for this, then they surely want this feature to work. It should be enabled by default for this board (unless the maintainer explicitly declares no, in which case the configuration should be removed completely). ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] am335x_evm: Add CONFIG_CMD_MTDPARTS and relevant defaults
Tom == Tom Rini tr...@ti.com writes: Tom Signed-off-by: Tom Rini tr...@ti.com Tom --- Tom include/configs/am335x_evm.h |9 + Tom 1 file changed, 9 insertions(+) Tom diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h Tom index 59647d1..61b861d 100644 Tom --- a/include/configs/am335x_evm.h Tom +++ b/include/configs/am335x_evm.h Tom @@ -60,6 +60,8 @@ Tom fdtfile=\0 \ Tom console=ttyO0,115200n8\0 \ Tom optargs=\0 \ Tom + mtdids= MTDIDS_DEFAULT \0 \ Tom + mtdparts= MTDPARTS_DEFAULT \0 \ Tom mmcdev=0\0 \ Tom mmcroot=/dev/mmcblk0p2 ro\0 \ Tom mmcrootfstype=ext4 rootwait\0 \ Tom @@ -341,6 +343,13 @@ Tom /* NAND support */ Tom #ifdef CONFIG_NAND Tom #define CONFIG_CMD_NAND Tom +#define CONFIG_CMD_MTDPARTS Tom +#define MTDIDS_DEFAULT nand0=omap2-nand.0 Tom +#define MTDPARTS_DEFAULT mtdparts=omap2-nand.0:128k(SPL), \ Tom + 128k(SPL.backup1), \ Tom + 128k(SPL.backup2), \ Tom + 128k(SPL.backup3),1920k(u-boot), \ Tom + 128k(u-boot-env),5m(kernel),-(rootfs) Is there a particular reason why the u-boot partition is so big? -- Bye, Peter Korsgaard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v1 2/2] blackfin: Correct early serial mess output in BYPASS boot mode.
From: Sonic Zhang sonic.zh...@analog.com
The early serial should not be configured again in initcode() for BYPASS
boot mode and in start() for the other LDR boot modes.
In BYPASS boot mode, the start up code is located in Nor flash address other
than the DRAM address defined in link script. The code embedded string can't
be addressed by its compile time symbol. Calculate it according to the flash
offset.
Signed-off-by: Sonic Zhang sonic.zh...@analog.com
---
arch/blackfin/cpu/initcode.c |2 ++
arch/blackfin/cpu/serial.h| 17 +++--
arch/blackfin/cpu/serial1.h |5 +
arch/blackfin/include/asm/clock.h |6 +-
4 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/arch/blackfin/cpu/initcode.c b/arch/blackfin/cpu/initcode.c
index 5c12726..4b10b6c 100644
--- a/arch/blackfin/cpu/initcode.c
+++ b/arch/blackfin/cpu/initcode.c
@@ -193,10 +193,12 @@ static inline void serial_init(void)
}
#endif
+#if CONFIG_BFIN_BOOT_MODE != BFIN_BOOT_BYPASS
if (BFIN_DEBUG_EARLY_SERIAL) {
serial_early_init(uart_base);
serial_early_set_baud(uart_base, CONFIG_BAUDRATE);
}
+#endif
}
__attribute__((always_inline))
diff --git a/arch/blackfin/cpu/serial.h b/arch/blackfin/cpu/serial.h
index 9200339..d67fd81 100644
--- a/arch/blackfin/cpu/serial.h
+++ b/arch/blackfin/cpu/serial.h
@@ -78,19 +78,31 @@ static inline void serial_early_puts(const char *s)
#else
.macro serial_early_init
-#ifdef CONFIG_DEBUG_EARLY_SERIAL
+#if defined(CONFIG_DEBUG_EARLY_SERIAL) defined(BFIN_BOOT_BYPASS)
call _serial_initialize;
#endif
.endm
.macro serial_early_set_baud
-#ifdef CONFIG_DEBUG_EARLY_SERIAL
+#if defined(CONFIG_DEBUG_EARLY_SERIAL) defined(BFIN_BOOT_BYPASS)
R0.L = LO(CONFIG_BAUDRATE);
R0.H = HI(CONFIG_BAUDRATE);
call _serial_set_baud;
#endif
.endm
+#if CONFIG_BFIN_BOOT_MODE == BFIN_BOOT_BYPASS
+#define update_serial_early_string_addr \
+ R1.L = _start; \
+ R1.H = _start; \
+ R0 = R0 - R1; \
+ R1.L = 0; \
+ R1.H = 0x2000; \
+ R0 = R0 + R1;
+#else
+#define update_serial_early_string_addr
+#endif
+
/* Since we embed the string right into our .text section, we need
* to find its address. We do this by getting our PC and adding 2
* bytes (which is the length of the jump instruction). Then we
@@ -108,6 +120,7 @@ static inline void serial_early_puts(const char *s)
.previous; \
R0.L = 7b; \
R0.H = 7b; \
+ update_serial_early_string_addr \
call _serial_puts;
#else
# define serial_early_puts(str)
diff --git a/arch/blackfin/cpu/serial1.h b/arch/blackfin/cpu/serial1.h
index 52f1c62..467d381 100644
--- a/arch/blackfin/cpu/serial1.h
+++ b/arch/blackfin/cpu/serial1.h
@@ -287,8 +287,13 @@ static inline void serial_early_set_baud(uint32_t
uart_base, uint32_t baud)
* weird multiplication is to make sure we over sample just
* a little rather than under sample the incoming signals.
*/
+#if CONFIG_BFIN_BOOT_MODE == BFIN_BOOT_BYPASS
+ uint16_t divisor = (early_get_uart_clk() + baud * 8) / (baud * 16)
+ - ANOMALY_05000230;
+#else
uint16_t divisor = early_division(early_get_uart_clk() + (baud * 8),
baud * 16) - ANOMALY_05000230;
+#endif
serial_set_divisor(uart_base, divisor);
}
diff --git a/arch/blackfin/include/asm/clock.h
b/arch/blackfin/include/asm/clock.h
index df6cd68..f1fcd40 100644
--- a/arch/blackfin/include/asm/clock.h
+++ b/arch/blackfin/include/asm/clock.h
@@ -10,7 +10,7 @@
#include asm/blackfin.h
#ifdef PLL_CTL
#include asm/mach-common/bits/pll.h
-# define pll_is_bypassed() (bfin_read_PLL_STAT() DF)
+# define pll_is_bypassed() (bfin_read_PLL_CTL() BYPASS)
#else
#include asm/mach-common/bits/cgu.h
# define pll_is_bypassed() (bfin_read_CGU_STAT() PLLBP)
@@ -55,7 +55,11 @@ static inline uint32_t early_get_uart_clk(void)
if (!pll_is_bypassed()) {
div = bfin_read_PLL_DIV();
ssel = (div SSEL) SSEL_P;
+#if CONFIG_BFIN_BOOT_MODE == BFIN_BOOT_BYPASS
+ sclk = vco/ssel;
+#else
sclk = early_division(vco, ssel);
+#endif
}
uclk = sclk;
#ifdef CGU_DIV
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v1 1/2] blackfin: Set correct early debug serial baudrate.
From: Sonic Zhang sonic.zh...@analog.com
Calculate the early uart clock from the system clock registers set by
the bootrom other than the predefine uboot clock macros.
Split the early baudrate setting function and the normal baudrate
setting one.
Signed-off-by: Sonic Zhang sonic.zh...@analog.com
---
arch/blackfin/cpu/initcode.c | 43 +++--
arch/blackfin/cpu/serial.c| 12 +-
arch/blackfin/cpu/serial1.h | 43 -
arch/blackfin/cpu/serial4.h | 27 -
arch/blackfin/include/asm/clock.h | 74 +
arch/blackfin/lib/clocks.c| 12 +-
6 files changed, 123 insertions(+), 88 deletions(-)
create mode 100644 arch/blackfin/include/asm/clock.h
diff --git a/arch/blackfin/cpu/initcode.c b/arch/blackfin/cpu/initcode.c
index e8ea0ba..5c12726 100644
--- a/arch/blackfin/cpu/initcode.c
+++ b/arch/blackfin/cpu/initcode.c
@@ -194,15 +194,8 @@ static inline void serial_init(void)
#endif
if (BFIN_DEBUG_EARLY_SERIAL) {
- int enabled = serial_early_enabled(uart_base);
-
serial_early_init(uart_base);
-
- /* If the UART is off, that means we need to program
-* the baud rate ourselves initially.
-*/
- if (!enabled)
- serial_early_set_baud(uart_base, CONFIG_BAUDRATE);
+ serial_early_set_baud(uart_base, CONFIG_BAUDRATE);
}
}
@@ -714,37 +707,29 @@ program_clocks(ADI_BOOT_DATA *bs, bool put_into_srfs)
__attribute__((always_inline)) static inline void
update_serial_clocks(ADI_BOOT_DATA *bs, uint sdivB, uint divB, uint vcoB)
{
- serial_putc('a');
-
/* Since we've changed the SCLK above, we may need to update
* the UART divisors (UART baud rates are based on SCLK).
* Do the division by hand as there are no native instructions
* for dividing which means we'd generate a libgcc reference.
*/
- if (CONFIG_BFIN_BOOT_MODE == BFIN_BOOT_UART) {
- unsigned int sdivR, vcoR;
- int dividend = sdivB * divB * vcoR;
- int divisor = vcoB * sdivR;
- unsigned int quotient;
+ unsigned int sdivR, vcoR;
+ unsigned int dividend = sdivB * divB * vcoR;
+ unsigned int divisor = vcoB * sdivR;
+ unsigned int quotient;
- serial_putc('b');
+ serial_putc('a');
#ifdef __ADSPBF60x__
- sdivR = bfin_read_CGU_DIV();
- sdivR = ((sdivR 8) 0x1f) * ((sdivR 5) 0x7);
- vcoR = (bfin_read_CGU_CTL() 8) 0x7f;
+ sdivR = bfin_read_CGU_DIV();
+ sdivR = ((sdivR 8) 0x1f) * ((sdivR 5) 0x7);
+ vcoR = (bfin_read_CGU_CTL() 8) 0x7f;
#else
- sdivR = bfin_read_PLL_DIV() 0xf;
- vcoR = (bfin_read_PLL_CTL() 9) 0x3f;
+ sdivR = bfin_read_PLL_DIV() 0xf;
+ vcoR = (bfin_read_PLL_CTL() 9) 0x3f;
#endif
-
- for (quotient = 0; dividend 0; ++quotient)
- dividend -= divisor;
- serial_early_put_div(quotient - ANOMALY_05000230);
- serial_putc('c');
- }
-
- serial_putc('d');
+ quotient = early_division(dividend, divisor);
+ serial_early_put_div(quotient - ANOMALY_05000230);
+ serial_putc('c');
}
__attribute__((always_inline)) static inline void
diff --git a/arch/blackfin/cpu/serial.c b/arch/blackfin/cpu/serial.c
index 9847e9f..36d2a5c 100644
--- a/arch/blackfin/cpu/serial.c
+++ b/arch/blackfin/cpu/serial.c
@@ -195,6 +195,14 @@ static void uart_loop(uint32_t uart_base, int state)
#endif
+static inline void __serial_set_baud(uint32_t uart_base, uint32_t baud)
+{
+ uint16_t divisor = (get_uart_clk() + (baud * 8)) / (baud * 16)
+ - ANOMALY_05000230;
+
+ /* Program the divisor to get the baud rate we want */
+ serial_set_divisor(uart_base, divisor);
+}
#ifdef CONFIG_SYS_BFIN_UART
static void uart_puts(uint32_t uart_base, const char *s)
@@ -209,7 +217,7 @@ static int uart##n##_init(void) \
const unsigned short pins[] = { _P_UART(n, RX), _P_UART(n, TX), 0, }; \
peripheral_request_list(pins, bfin-uart); \
uart_init(MMR_UART(n)); \
- serial_early_set_baud(MMR_UART(n), gd-baudrate); \
+ __serial_set_baud(MMR_UART(n), gd-baudrate); \
uart_lsr_clear(MMR_UART(n)); \
return 0; \
} \
@@ -221,7 +229,7 @@ static int uart##n##_uninit(void) \
\
static void uart##n##_setbrg(void) \
{ \
- serial_early_set_baud(MMR_UART(n), gd-baudrate); \
+ __serial_set_baud(MMR_UART(n), gd-baudrate); \
} \
\
static int uart##n##_getc(void) \
diff --git a/arch/blackfin/cpu/serial1.h b/arch/blackfin/cpu/serial1.h
index a20175b..52f1c62 100644
--- a/arch/blackfin/cpu/serial1.h
+++ b/arch/blackfin/cpu/serial1.h
@@ -15,6 +15,8 @@
#ifndef __ASSEMBLY__
+#include asm/clock.h
+
Re: [U-Boot] [RFC PATCH v2 01/15] Implement autoconf header file
Hi Simon, On Mon, Feb 25, 2013 at 12:10 AM, Simon Glass s...@chromium.org wrote: Hi Joe, On Sun, Feb 24, 2013 at 11:50 AM, Joe Hershberger joe.hershber...@gmail.com wrote: Hi Simon, On Sun, Feb 24, 2013 at 11:25 AM, Simon Glass s...@chromium.org wrote: Add support for generating an autoconf.h header file that can be used in the source instead of #ifdef. For example, instead of: #ifdef CONFIG_VERSION_VARIABLE setenv(ver, version_string); /* set version variable */ #endif you can do: if (autoconf_version_variable()) setenv(ver, version_string); /* set version variable */ You are changing the meaning between these two examples. The old code was #ifDEF, which means the new example needs to be autoconf_HAS_*. Is there a reason to muddy the waters by recommending people use this automatic value of 0 instead of using the has function? Any more than without this patch we should go change most all the #ifdef to #if? Thanks much for going through this so carefully. No problem. Here is my thinking on this point - I will respond to the rest of your comments when I get back to this. I believe we should get rid of the 'has' function eventually. Fair enough. I think it would be nice if your mechanism provided a way to segregate these two. Some sort of naming convention that differed between the two cases. The cases should be easy to identify. If it's an enable switch, then it will be #define'd, but with no value. If it is defined to a value, then it is configuration. This will also help to end the bad practice of board configs using #define CONFIG_ENABLE_MY_FEATURE 1, which of course it only checked for defined or not... then the unsuspecting user juct changes the 1 to a 0 and gets no change in behavior. By using a different naming convention, adding that 1 would prevent the feature from working up front. The more I see autoconf the more I think that people will confuse this with GNU autoconf. maybe it would be good to avoid that. Most features are anyway just a 0 or a 1 - either the feature is enabled or it is disabled. There are some where a value is provided, and that means that the feature is automatically enabled. I'm not a huge fan of that. To me we should have two completely different concepts in U-Boot: - enabling an option, which generally just affects which files are compiled - i.e. an option that should generally only appear in Makefiles - configuring something, by which I mean giving the code a value to work with. This should come either from CONFIG for compile-time config, or device tree for run-time config At present these two are mixed up, and I don't think it aids clarity. Maybe something like enable_[lower-case-name]() and config_[lower-case name](). But in matching your current feature-set, you would not even need to generate the config_ functions... only the enable_ functions. There are very very few CONFIGs that need this 'has' option I think. I know about BOOTDELAY, and I'm sure there are others, but there was recent discussion on the list about whether we should separate out the bootdelay/autoboot value from the enablement, wasn't there? Indeed. It was a patch I submitted for this release. http://patchwork.ozlabs.org/patch/219303/ It at least removed he dependence on the default value. Even better would be to separate the default value from the selection of building in support as a separate variable. The compiler will ensure that the dead code is eliminated, so the result is the same. Where the value of the CONFIG define is 0, you can use the autoconf_has...() form. For example CONFIG_BOOTDELAY can be -ve, 0 or +ve, but if it is defined at all, it affects behaviour: #if defined(CONFIG_BOOTDELAY) (CONFIG_BOOTDELAY = 0) s = getenv (bootdelay); #endif So we use: if (autoconf_has_bootdelay() autoconf_bootdelay() = 0) s = getenv (bootdelay); This later form should only be used for such 'difficult' defines where a zero value still means that the CONFIG should be considered to be defined. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: - Split out changes to main.c into separate patches - Fix up a few errors and comments in the original RFC - Use autoconf_...() instead of config_...() - Use autoconf_has_...() instead of config_..._enabled() - Add a grep to the sed/sort pipe to speed up processing Makefile | 42 - README| 87 +-- include/common.h | 3 ++ include/config_drop.h | 17 + tools/scripts/define2conf.sed | 37 ++ tools/scripts/define2list.sed | 31 +++ 6 files changed, 213 insertions(+), 4 deletions(-) create mode 100644 include/config_drop.h create mode 100644 tools/scripts/define2conf.sed create mode 100644
Re: [U-Boot] [PATCH v3 09/16] main: Use autoconf for boot_delay code
Hi Simon, On Tue, Feb 26, 2013 at 10:11 AM, Simon Glass s...@chromium.org wrote: Convert this function and its children to use autoconf instead of #ifdef. Some header files must now be included unconditionally, so remove some of the #ifdefs from the header section, and put these header files into the right order. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v3: - Simplify code for finding out bootdelay from config or environment Changes in v2: None common/main.c | 107 ++--- include/menu.h | 2 -- 2 files changed, 42 insertions(+), 67 deletions(-) Acked-by: Joe Hershberger joe.hershber...@ni.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 12/16] main: Use autoconf in command line reading
Hi Simon, On Tue, Feb 26, 2013 at 10:11 AM, Simon Glass s...@chromium.org wrote: Remove #ifdefs in favour of autoconf for this code. This involves removing a few unnecessary #ifdefs in headers also. We have two versions of the code - one that handles command line editing and one that is just a simple implementation. Create a new function called readline_into_buffer() which calls either cread_line() or the new simple_readline(), created to hold the 'simple' code. The cread_print_hist_list() function is not actually used anywhere, so punt it. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v3: None Changes in v2: None common/main.c | 164 -- include/command.h | 2 - include/common.h | 2 - 3 files changed, 73 insertions(+), 95 deletions(-) Reviewed-by: Joe Hershberger joe.hershber...@ni.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v2 12/15] main: Use autoconf in main_loop()
Hi Simon,
On Mon, Feb 25, 2013 at 11:50 PM, Simon Glass s...@chromium.org wrote:
Hi Joe,
On Sun, Feb 24, 2013 at 1:33 PM, Joe Hershberger
joe.hershber...@gmail.com wrote:
Hi Simon,
On Sun, Feb 24, 2013 at 11:26 AM, Simon Glass s...@chromium.org wrote:
Convert main_loop() over to use autoconf, and add a required prototype
to common.h.
The do_mdm_init variable is now always defined, but this seems like an
acceptable compromise.
In fdt_support.h the #ifdef used is CONFIG_OF_LIBFDT. However, even if
this is not defined we want to make the functions available for our
conditional-compilation scheme. The only place where we really don't
have access to these support functions is when USE_HOSTCC is defined.
So change the #ifdef to that.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2: None
common/main.c | 77
+++
include/common.h | 1 +
include/fdt_support.h | 4 +--
3 files changed, 37 insertions(+), 45 deletions(-)
diff --git a/common/main.c b/common/main.c
index 3966321..40a79b7 100644
--- a/common/main.c
+++ b/common/main.c
@@ -63,10 +63,7 @@ static int retry_time = -1; /* -1 so can call
readline before main_loop */
#defineendtick(seconds) (get_ticks() + (uint64_t)(seconds) *
get_tbclk())
-#ifdef CONFIG_MODEM_SUPPORT
int do_mdm_init = 0;
-extern void mdm_init(void); /* defined in board.c */
-#endif
/***
* Watch for 'delay' seconds for autoboot stop or autoboot delay string.
@@ -383,51 +380,47 @@ void main_loop(void)
int len;
int rc = 1;
int flag;
-#ifdef CONFIG_PREBOOT
- char *p;
-#endif
bootstage_mark_name(BOOTSTAGE_ID_MAIN_LOOP, main_loop);
-#ifdef CONFIG_MODEM_SUPPORT
- debug(DEBUG: main_loop: do_mdm_init=%d\n, do_mdm_init);
- if (do_mdm_init) {
- char *str = strdup(getenv(mdm_cmd));
- setenv(preboot, str); /* set or delete definition */
- if (str != NULL)
- free(str);
- mdm_init(); /* wait for modem connection */
+ if (autoconf_modem_support()) {
Why not just remove do_mdm_init and use gd-do_mdm_init here?
Would that be valid? There is board code to set that - I am not sure
what the intent is but it seems beyond the scope of this patch to
change it.
From the looks of the source, it's perfectly valid. I can certainly
see your position about it being beyond the scope of this patch. It
would be great if someone who cares about this modem code would clean
up the mess.
+ debug(DEBUG: main_loop: do_mdm_init=%d\n, do_mdm_init);
+ if (do_mdm_init) {
+ char *str = strdup(getenv(mdm_cmd));
+
+ setenv(preboot, str); /* set or delete
definition */
+ if (str != NULL)
+ free(str);
+ mdm_init(); /* wait for modem connection */
+ }
}
-#endif /* CONFIG_MODEM_SUPPORT */
-#ifdef CONFIG_VERSION_VARIABLE
- {
+ if (autoconf_version_variable())
setenv(ver, version_string); /* set version variable */
- }
-#endif /* CONFIG_VERSION_VARIABLE */
-#ifdef CONFIG_SYS_HUSH_PARSER
- u_boot_hush_start();
-#endif
+ if (autoconf_sys_hush_parser())
+ u_boot_hush_start();
-#if defined(CONFIG_HUSH_INIT_VAR)
- hush_init_var();
-#endif
+ if (autoconf_hush_init_var())
+ hush_init_var();
+
+ if (autoconf_preboot()) {
+ char *p = getenv(preboot);
+
+ if (p) {
+ int prev;
-#ifdef CONFIG_PREBOOT
- p = getenv(preboot);
- if (p) {
-# ifdef CONFIG_AUTOBOOT_KEYED
- int prev = disable_ctrlc(1);/* disable Control C
checking */
-# endif
+ /* disable Control C checking */
+ if (autoconf_autoboot_keyed())
+ prev = disable_ctrlc(1);
- run_command_list(p, -1, 0);
+ run_command_list(p, -1, 0);
-# ifdef CONFIG_AUTOBOOT_KEYED
- disable_ctrlc(prev);/* restore Control C checking */
-# endif
+ /* restore Control C checking */
+ if (autoconf_autoboot_keyed())
+ disable_ctrlc(prev);
+ }
}
-#endif /* CONFIG_PREBOOT */
if (autoconf_update_tftp())
update_tftp(0UL);
@@ -435,9 +428,8 @@ void main_loop(void)
if (autoconf_has_bootdelay() autoconf_bootdelay() = 0)
process_boot_delay();
-#if defined CONFIG_OF_CONTROL
- set_working_fdt_addr((void *)gd-fdt_blob);
-#endif /* CONFIG_OF_CONTROL */
+ if
Re: [U-Boot] [PATCH v3 13/16] main: Use autoconf in main_loop()
Hi Simon, On Tue, Feb 26, 2013 at 10:11 AM, Simon Glass s...@chromium.org wrote: Convert main_loop() over to use autoconf, and add a required prototype to common.h. The do_mdm_init variable is now always defined, but this seems like an acceptable compromise. In fdt_support.h the #ifdef used is CONFIG_OF_LIBFDT. However, even if this is not defined we want to make the functions available for our conditional-compilation scheme. The only place where we really don't have access to these support functions is when USE_HOSTCC is defined. So change the #ifdef to that. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v3: - Remove the extra config_of_libfdt() condition in main_loop() Changes in v2: None common/main.c | 77 +++ include/common.h | 1 + include/fdt_support.h | 4 +-- 3 files changed, 37 insertions(+), 45 deletions(-) Reviewed-by: Joe Hershberger joe.hershber...@ni.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 11/16] main: Fix typos and checkpatch warnings in command line reading
Hi Simon, On Tue, Feb 26, 2013 at 10:11 AM, Simon Glass s...@chromium.org wrote: There are a few over-long lines and other checkpatch problems in this area of the code. Prepare the ground for the next patch by tidying these up. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v3: - Separate out checkpatch fixes in command line reading code into new patch Changes in v2: None common/main.c | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) Reviewed-by: Joe Hershberger joe.hershber...@ni.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/9] Exynos: Change get_timer() to work correctly
At present get_timer() does not return sane values. It should count up
smoothly in milliscond intervals.
We can change the PWM to count down at 1MHz, providing a resolution
of 1us and a range of about an hour between required get_timer() calls.
TEST=sf probe 1:0; time sf read 40008000 0 1000
Try with different numbers of bytes and see that sane values are obtained
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Akshay Saraswat aksha...@samsung.com
---
arch/arm/cpu/armv7/s5p-common/pwm.c | 6 ++
arch/arm/cpu/armv7/s5p-common/timer.c | 100 +-
2 files changed, 44 insertions(+), 62 deletions(-)
diff --git a/arch/arm/cpu/armv7/s5p-common/pwm.c
b/arch/arm/cpu/armv7/s5p-common/pwm.c
index 44d7bc3..3147f59 100644
--- a/arch/arm/cpu/armv7/s5p-common/pwm.c
+++ b/arch/arm/cpu/armv7/s5p-common/pwm.c
@@ -174,6 +174,12 @@ int pwm_init(int pwm_id, int div, int invert)
/* set count value */
offset = pwm_id * 3;
+
+ /*
+* TODO(sjg): Use this as a countdown timer for now. We count down
+* from the maximum value to 0, then reset.
+*/
+ timer_rate_hz = -1;
writel(timer_rate_hz, pwm-tcntb0 + offset);
val = readl(pwm-tcon) ~(0xf TCON_OFFSET(pwm_id));
diff --git a/arch/arm/cpu/armv7/s5p-common/timer.c
b/arch/arm/cpu/armv7/s5p-common/timer.c
index e78c716..c48a297 100644
--- a/arch/arm/cpu/armv7/s5p-common/timer.c
+++ b/arch/arm/cpu/armv7/s5p-common/timer.c
@@ -39,13 +39,33 @@ static inline struct s5p_timer *s5p_get_base_timer(void)
return (struct s5p_timer *)samsung_get_base_timer();
}
+/**
+ * Read the countdown timer.
+ *
+ * This operates at 1MHz and counts downwards. It will wrap about every
+ * hour (2^32 microseconds).
+ *
+ * @return current value of timer
+ */
+static unsigned long timer_get_us_down(void)
+{
+ struct s5p_timer *const timer = s5p_get_base_timer();
+
+ return readl(timer-tcnto4);
+}
+
int timer_init(void)
{
/* PWM Timer 4 */
- pwm_init(4, MUX_DIV_2, 0);
+ pwm_init(4, MUX_DIV_4, 0);
pwm_config(4, 0, 0);
pwm_enable(4);
+ /* Use this as the current monotonic time in us */
+ gd-arch.timer_reset_value = 0;
+
+ /* Use this as the last timer value we saw */
+ gd-arch.lastinc = timer_get_us_down();
reset_timer_masked();
return 0;
@@ -56,48 +76,28 @@ int timer_init(void)
*/
unsigned long get_timer(unsigned long base)
{
- return get_timer_masked() - base;
+ ulong now = timer_get_us_down();
+
+ /*
+* Increment the time by the amount elapsed since the last read.
+* The timer may have wrapped around, but it makes no difference to
+* our arithmetic here.
+*/
+ gd-arch.timer_reset_value += gd-arch.lastinc - now;
+ gd-arch.lastinc = now;
+
+ /* Divide by 1000 to convert from us to ms */
+ return gd-arch.timer_reset_value / 1000 - base;
}
/* delay x useconds */
void __udelay(unsigned long usec)
{
- struct s5p_timer *const timer = s5p_get_base_timer();
- unsigned long tmo, tmp, count_value;
-
- count_value = readl(timer-tcntb4);
-
- if (usec = 1000) {
- /*
-* if big number, spread normalization
-* to seconds
-* 1. start to normalize for usec to ticks per sec
-* 2. find number of ticks to wait to achieve target
-* 3. finish normalize.
-*/
- tmo = usec / 1000;
- tmo *= (CONFIG_SYS_HZ * count_value);
- tmo /= 1000;
- } else {
- /* else small number, don't kill it prior to HZ multiply */
- tmo = usec * CONFIG_SYS_HZ * count_value;
- tmo /= (1000 * 1000);
- }
-
- /* get current timestamp */
- tmp = get_current_tick();
-
- /* if setting this fordward will roll time stamp */
- /* reset advancing timestamp to 0, set lastinc value */
- /* else, set advancing stamp wake up time */
- if ((tmo + tmp + 1) tmp)
- reset_timer_masked();
- else
- tmo += tmp;
-
- /* loop till event */
- while (get_current_tick() tmo)
- ; /* nop */
+ unsigned long count_value;
+
+ count_value = timer_get_us_down();
+ while ((int)(count_value - timer_get_us_down()) (int)usec)
+ ;
}
void reset_timer_masked(void)
@@ -109,30 +109,6 @@ void reset_timer_masked(void)
gd-arch.tbl = 0;
}
-unsigned long get_timer_masked(void)
-{
- struct s5p_timer *const timer = s5p_get_base_timer();
- unsigned long count_value = readl(timer-tcntb4);
-
- return get_current_tick() / count_value;
-}
-
-unsigned long get_current_tick(void)
-{
- struct s5p_timer *const timer = s5p_get_base_timer();
- unsigned long now = readl(timer-tcnto4);
- unsigned long
[U-Boot] [PATCH 2/9] Exynos: Add timer_get_us function
timer_get_us returns the time in microseconds since a certain reference
point of history. However, it does not guarantee to return an accurate
time after a long period; instead, it wraps around (that is, the
reference point is reset to some other point of history) after some
periods. The frequency of wrapping around is about an hour (or 2^32
microseconds).
TEST=sf probe 1:0; time sf read 40008000 0 1000
Try with different numbers of bytes and see that sane values are obtained
Signed-off-by: Che-Liang Chiou clch...@chromium.org
Signed-off-by: Akshay Saraswat aksha...@samsung.com
---
arch/arm/cpu/armv7/s5p-common/timer.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/cpu/armv7/s5p-common/timer.c
b/arch/arm/cpu/armv7/s5p-common/timer.c
index c48a297..de61405 100644
--- a/arch/arm/cpu/armv7/s5p-common/timer.c
+++ b/arch/arm/cpu/armv7/s5p-common/timer.c
@@ -90,6 +90,21 @@ unsigned long get_timer(unsigned long base)
return gd-arch.timer_reset_value / 1000 - base;
}
+unsigned long timer_get_us(void)
+{
+ static unsigned long base_time_us;
+
+ struct s5p_timer *const timer =
+ (struct s5p_timer *)samsung_get_base_timer();
+ unsigned long now_downward_us = readl(timer-tcnto4);
+
+ if (!base_time_us)
+ base_time_us = now_downward_us;
+
+ /* Note that this timer counts downward. */
+ return base_time_us - now_downward_us;
+}
+
/* delay x useconds */
void __udelay(unsigned long usec)
{
--
1.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/9] Exynos: pwm: Fix two bugs in the exynos pwm configuration code
First, the div value was being used incorrectly to compute the frequency of
the PWM timer. The value passed in is a constant which reflects the value
that would be found in a configuration register, 0 to 4. That should
correspond to a scaling factor of 1, 2, 4, 8, or 16, 1 div, but div + 1 was
being used instead.
Second, the reset value of the timers were being calculated to give an overall
frequency, thrown out, and set to a maximum value. This was done so that PWM 4
could be used as the system clock by counting down from a high value, but it
was applied indiscriminantly. It should at most be applied only to PWM 4.
This change also takes the opportunity to tidy up the pwm_init function.
TEST=sf probe 1:0; time sf read 40008000 0 1000
Try with different numbers of bytes and see that sane values are obtained
Build and boot U-boot with this patch, backlight works properly.
Signed-off-by: Gabe Black gabebl...@google.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
---
arch/arm/cpu/armv7/s5p-common/pwm.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/arch/arm/cpu/armv7/s5p-common/pwm.c
b/arch/arm/cpu/armv7/s5p-common/pwm.c
index 3147f59..02156d1 100644
--- a/arch/arm/cpu/armv7/s5p-common/pwm.c
+++ b/arch/arm/cpu/armv7/s5p-common/pwm.c
@@ -143,7 +143,7 @@ int pwm_init(int pwm_id, int div, int invert)
u32 val;
const struct s5p_timer *pwm =
(struct s5p_timer *)samsung_get_base_timer();
- unsigned long timer_rate_hz;
+ unsigned long ticks_per_period;
unsigned int offset, prescaler;
/*
@@ -167,20 +167,24 @@ int pwm_init(int pwm_id, int div, int invert)
val |= (div 0xf) MUX_DIV_SHIFT(pwm_id);
writel(val, pwm-tcfg1);
- timer_rate_hz = get_pwm_clk() / ((prescaler + 1) *
- (div + 1));
+ if (pwm_id == 4) {
+ /*
+* TODO(sjg): Use this as a countdown timer for now. We count
+* down from the maximum value to 0, then reset.
+*/
+ ticks_per_period = -1UL;
+ } else {
+ const unsigned long pwm_hz = 1000;
+ unsigned long timer_rate_hz = get_pwm_clk() /
+ ((prescaler + 1) * (1 div));
- timer_rate_hz = timer_rate_hz / CONFIG_SYS_HZ;
+ ticks_per_period = timer_rate_hz / pwm_hz;
+ }
/* set count value */
offset = pwm_id * 3;
- /*
-* TODO(sjg): Use this as a countdown timer for now. We count down
-* from the maximum value to 0, then reset.
-*/
- timer_rate_hz = -1;
- writel(timer_rate_hz, pwm-tcntb0 + offset);
+ writel(ticks_per_period, pwm-tcntb0 + offset);
val = readl(pwm-tcon) ~(0xf TCON_OFFSET(pwm_id));
if (invert (pwm_id 4))
--
1.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/9] Exynos: Avoid a divide by zero by specifying a non-zero period for pwm 4
The pwm_config function in the exynos pwm driver divides by its period
period parameter. A function was calling pwm_config with a 0ns period and a
0ns duty cycle. That doesn't actually make any sense physically, and results
in a divide by zero in the driver. This change changes the paremters to be a
10ns period and duty cycle.
TEST=sf probe 1:0; time sf read 40008000 0 1000
Try with different numbers of bytes and see that sane values are obtained
Build and boot U-boot with this patch, backlight works properly.
Signed-off-by: Gabe Black gabebl...@google.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
---
arch/arm/cpu/armv7/s5p-common/timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/s5p-common/timer.c
b/arch/arm/cpu/armv7/s5p-common/timer.c
index de61405..6a0fa58 100644
--- a/arch/arm/cpu/armv7/s5p-common/timer.c
+++ b/arch/arm/cpu/armv7/s5p-common/timer.c
@@ -58,7 +58,7 @@ int timer_init(void)
{
/* PWM Timer 4 */
pwm_init(4, MUX_DIV_4, 0);
- pwm_config(4, 0, 0);
+ pwm_config(4, 10, 10);
pwm_enable(4);
/* Use this as the current monotonic time in us */
--
1.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/9] Fix and Re-organise PWM Timer
This patch set tries to fix few bugs in timer and re-organises PWM clock code. Akshay Saraswat (9): Exynos: Change get_timer() to work correctly Exynos: Add timer_get_us function Exynos: pwm: Fix two bugs in the exynos pwm configuration code Exynos: Avoid a divide by zero by specifying a non-zero period for pwm 4 Exynos: Tidy up the pwm_config function in the exynos pwm driver Exynos: Add peripherial id for pwm Exynos: clock: Add generic api to get the clk freq Exynos: clock: Correct pwm source clk selection Exynos: pwm: Use generic api to get pwm clk freq arch/arm/cpu/armv7/exynos/clock.c | 127 ++ arch/arm/cpu/armv7/s5p-common/pwm.c | 45 +-- arch/arm/cpu/armv7/s5p-common/timer.c | 117 +-- arch/arm/include/asm/arch-exynos/clk.h| 27 +++ arch/arm/include/asm/arch-exynos/periph.h | 5 ++ board/samsung/smdk5250/setup.h| 2 +- 6 files changed, 237 insertions(+), 86 deletions(-) -- 1.8.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/9] Exynos: Tidy up the pwm_config function in the exynos pwm driver
Some small fixes in the exynos pwm driver:
1. NS_IN_HZ is non-sensical since these are not compatible units. This
constant actually describes the number of nanoseconds in a second. Renamed it
to NS_IN_SEC. Also dropped the unnecessary parenthesis.
2. The variable period is not used to hold a period, it's used to hold a
frequency. Renamed it to frequency.
3. tcmp is an unsigned value, so (tcmp 0) will never be true and the if
which checks that condition will never execute. Also, there should be no
problem if the pwm never switches, so there's no reason to subtract one from
tcmp and therefore no reason to compare it against zero. Removed both ifs. If
they weren't removed, tcmp should be a signed value.
4. Add a check for a 0 period.
TEST=sf probe 1:0; time sf read 40008000 0 1000
Try with different numbers of bytes and see that sane values are obtained
Build and boot U-boot with this patch, backlight works properly.
Signed-off-by: Gabe Black gabebl...@google.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
---
arch/arm/cpu/armv7/s5p-common/pwm.c | 22 ++
1 file changed, 6 insertions(+), 16 deletions(-)
diff --git a/arch/arm/cpu/armv7/s5p-common/pwm.c
b/arch/arm/cpu/armv7/s5p-common/pwm.c
index 02156d1..6f401b8 100644
--- a/arch/arm/cpu/armv7/s5p-common/pwm.c
+++ b/arch/arm/cpu/armv7/s5p-common/pwm.c
@@ -70,7 +70,7 @@ static unsigned long pwm_calc_tin(int pwm_id, unsigned long
freq)
return tin_parent_rate / 16;
}
-#define NS_IN_HZ (10UL)
+#define NS_IN_SEC 10UL
int pwm_config(int pwm_id, int duty_ns, int period_ns)
{
@@ -79,7 +79,7 @@ int pwm_config(int pwm_id, int duty_ns, int period_ns)
unsigned int offset;
unsigned long tin_rate;
unsigned long tin_ns;
- unsigned long period;
+ unsigned long frequency;
unsigned long tcon;
unsigned long tcnt;
unsigned long tcmp;
@@ -89,34 +89,24 @@ int pwm_config(int pwm_id, int duty_ns, int period_ns)
* fact that anything faster than 1GHz is easily representable
* by 32bits.
*/
- if (period_ns NS_IN_HZ || duty_ns NS_IN_HZ)
+ if (period_ns NS_IN_SEC || duty_ns NS_IN_SEC || period_ns == 0)
return -ERANGE;
if (duty_ns period_ns)
return -EINVAL;
- period = NS_IN_HZ / period_ns;
+ frequency = NS_IN_SEC / period_ns;
/* Check to see if we are changing the clock rate of the PWM */
- tin_rate = pwm_calc_tin(pwm_id, period);
+ tin_rate = pwm_calc_tin(pwm_id, frequency);
- tin_ns = NS_IN_HZ / tin_rate;
+ tin_ns = NS_IN_SEC / tin_rate;
tcnt = period_ns / tin_ns;
/* Note, counters count down */
tcmp = duty_ns / tin_ns;
tcmp = tcnt - tcmp;
- /*
-* the pwm hw only checks the compare register after a decrement,
-* so the pin never toggles if tcmp = tcnt
-*/
- if (tcmp == tcnt)
- tcmp--;
-
- if (tcmp 0)
- tcmp = 0;
-
/* Update the PWM register block. */
offset = pwm_id * 3;
if (pwm_id 4) {
--
1.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/9] Exynos: Add peripherial id for pwm
Add peripherial id for pwm inorder to support
generic api to get the clk frequency
TEST=sf probe 1:0; time sf read 40008000 0 1000
Try with different numbers of bytes and see that sane values are obtained
Build and boot U-boot with this patch, backlight works properly.
Signed-off-by: Padmavathi Venna padm...@samsung.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
---
arch/arm/include/asm/arch-exynos/periph.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/include/asm/arch-exynos/periph.h
b/arch/arm/include/asm/arch-exynos/periph.h
index 89bcdfc..e5aed4b 100644
--- a/arch/arm/include/asm/arch-exynos/periph.h
+++ b/arch/arm/include/asm/arch-exynos/periph.h
@@ -61,6 +61,11 @@ enum periph_id {
PERIPH_ID_SPI3,
PERIPH_ID_SPI4,
PERIPH_ID_SDMMC4,
+ PERIPH_ID_PWM0,
+ PERIPH_ID_PWM1,
+ PERIPH_ID_PWM2,
+ PERIPH_ID_PWM3,
+ PERIPH_ID_PWM4,
PERIPH_ID_COUNT,
PERIPH_ID_NONE = -1,
--
1.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/9] Exynos: clock: Add generic api to get the clk freq
Add generic api to get the frequency of the required peripherial. This
API gets the source clock frequency and returns the required frequency
by dividing with first and second dividers based on the requirement.
TEST=sf probe 1:0; time sf read 40008000 0 1000
Try with different numbers of bytes and see that sane values are obtained
Build and boot U-boot with this patch, backlight works properly.
Signed-off-by: Padmavathi Venna padm...@samsung.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
---
arch/arm/cpu/armv7/exynos/clock.c | 127 +
arch/arm/include/asm/arch-exynos/clk.h | 27 +++
2 files changed, 154 insertions(+)
diff --git a/arch/arm/cpu/armv7/exynos/clock.c
b/arch/arm/cpu/armv7/exynos/clock.c
index 956427c..a7a3066 100644
--- a/arch/arm/cpu/armv7/exynos/clock.c
+++ b/arch/arm/cpu/armv7/exynos/clock.c
@@ -27,6 +27,39 @@
#include asm/arch/clk.h
#include asm/arch/periph.h
+/* src_bit div_bit prediv_bit */
+static struct clk_bit_info clk_bit_info[PERIPH_ID_COUNT] = {
+ {0, 0, -1},
+ {4, 4, -1},
+ {8, 8, -1},
+ {12,12, -1},
+ {0, 0, 8},
+ {4, 16, 24},
+ {8, 0, 8},
+ {12,16, 24},
+ {-1,-1, -1},
+ {16,0, 8},
+ {20,16, 24},
+ {24,0, 8},
+ {0, 0, 4},
+ {4, 12, 16},
+ {-1,-1, -1},
+ {-1,-1, -1},
+ {-1,24, 0},
+ {-1,24, 0},
+ {-1,24, 0},
+ {-1,24, 0},
+ {-1,24, 0},
+ {-1,24, 0},
+ {-1,24, 0},
+ {-1,24, 0},
+ {24,0, -1},
+ {24,0, -1},
+ {24,0, -1},
+ {24,0, -1},
+ {24,0, -1},
+};
+
/* Epll Clock division values to achive different frequency output */
static struct set_epll_con_val exynos5_epll_div[] = {
{ 19200, 0, 48, 3, 1, 0 },
@@ -201,6 +234,100 @@ static unsigned long exynos5_get_pll_clk(int pllreg)
return fout;
}
+unsigned long exynos5_get_periph_rate(enum periph_id peripheral)
+{
+ struct clk_bit_info *bit_info = clk_bit_info[peripheral];
+ unsigned long sclk, sub_clk;
+ unsigned int src, div, sub_div;
+ struct exynos5_clock *clk =
+ (struct exynos5_clock *)samsung_get_base_clock();
+
+ switch (peripheral) {
+ case PERIPH_ID_UART0:
+ case PERIPH_ID_UART1:
+ case PERIPH_ID_UART2:
+ case PERIPH_ID_UART3:
+ src = readl(clk-src_peric0);
+ div = readl(clk-div_peric0);
+ break;
+ case PERIPH_ID_PWM0:
+ case PERIPH_ID_PWM1:
+ case PERIPH_ID_PWM2:
+ case PERIPH_ID_PWM3:
+ case PERIPH_ID_PWM4:
+ src = readl(clk-src_peric0);
+ div = readl(clk-div_peric3);
+ break;
+ case PERIPH_ID_SPI0:
+ case PERIPH_ID_SPI1:
+ src = readl(clk-src_peric1);
+ div = readl(clk-div_peric1);
+ break;
+ case PERIPH_ID_SPI2:
+ src = readl(clk-src_peric1);
+ div = readl(clk-div_peric2);
+ break;
+ case PERIPH_ID_SPI3:
+ case PERIPH_ID_SPI4:
+ src = readl(clk-sclk_src_isp);
+ div = readl(clk-sclk_div_isp);
+ break;
+ case PERIPH_ID_SDMMC0:
+ case PERIPH_ID_SDMMC1:
+ case PERIPH_ID_SDMMC2:
+ case PERIPH_ID_SDMMC3:
+ src = readl(clk-src_fsys);
+ div = readl(clk-div_fsys1);
+ break;
+ case PERIPH_ID_I2C0:
+ case PERIPH_ID_I2C1:
+ case PERIPH_ID_I2C2:
+ case PERIPH_ID_I2C3:
+ case PERIPH_ID_I2C4:
+ case PERIPH_ID_I2C5:
+ case PERIPH_ID_I2C6:
+ case PERIPH_ID_I2C7:
+ sclk = exynos5_get_pll_clk(MPLL);
+ sub_div = ((readl(clk-div_top1) bit_info-div_bit) 0x7)
+ 1;
+ div = ((readl(clk-div_top0) bit_info-prediv_bit) 0x7) +
1;
+ return (sclk / sub_div) / div;
+ default:
+ debug(%s: invalid peripheral %d, __func__, peripheral);
+ return -1;
+ };
+
+ src = (src bit_info-src_bit) 0xf;
+ if (src == SRC_MPLL)
+ sclk = exynos5_get_pll_clk(MPLL);
+ else if (src == SRC_EPLL)
+ sclk = exynos5_get_pll_clk(EPLL);
+ else if (src == SRC_VPLL)
+ sclk = exynos5_get_pll_clk(VPLL);
+ else
+ return 0;
+
+ sub_div = (div bit_info-div_bit) 0xf;
+ sub_clk = sclk / (sub_div + 1);
+
+ if (peripheral == PERIPH_ID_SDMMC0 || peripheral == PERIPH_ID_SDMMC2) {
+ div = (div bit_info-prediv_bit) 0xff;
+ return sub_clk / (div + 1);
+ }
+
+ return sub_clk;
+}
+
+unsigned long
[U-Boot] [PATCH 9/9] Exynos: pwm: Use generic api to get pwm clk freq
Use generic api to get the pwm clock frequency
TEST=sf probe 1:0; time sf read 40008000 0 1000
Try with different numbers of bytes and see that sane values are obtained
Build and boot U-boot with this patch, backlight works properly.
Signed-off-by: Padmavathi Venna padm...@samsung.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
---
arch/arm/cpu/armv7/s5p-common/pwm.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/cpu/armv7/s5p-common/pwm.c
b/arch/arm/cpu/armv7/s5p-common/pwm.c
index 6f401b8..06e0351 100644
--- a/arch/arm/cpu/armv7/s5p-common/pwm.c
+++ b/arch/arm/cpu/armv7/s5p-common/pwm.c
@@ -28,6 +28,7 @@
#include asm/io.h
#include asm/arch/pwm.h
#include asm/arch/clk.h
+#include asm/arch/periph.h
int pwm_enable(int pwm_id)
{
@@ -60,7 +61,7 @@ static unsigned long pwm_calc_tin(int pwm_id, unsigned long
freq)
unsigned long tin_parent_rate;
unsigned int div;
- tin_parent_rate = get_pwm_clk();
+ tin_parent_rate = clock_get_periph_rate(PERIPH_ID_PWM0);
for (div = 2; div = 16; div *= 2) {
if ((tin_parent_rate / (div 16)) freq)
@@ -165,8 +166,8 @@ int pwm_init(int pwm_id, int div, int invert)
ticks_per_period = -1UL;
} else {
const unsigned long pwm_hz = 1000;
- unsigned long timer_rate_hz = get_pwm_clk() /
- ((prescaler + 1) * (1 div));
+ unsigned long timer_rate_hz = clock_get_periph_rate(
+ PERIPH_ID_PWM0) / ((prescaler + 1) * (1 div));
ticks_per_period = timer_rate_hz / pwm_hz;
}
--
1.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 8/9] Exynos: clock: Correct pwm source clk selection
MPLL is selected as the source clk of pwm by default TEST=sf probe 1:0; time sf read 40008000 0 1000 Try with different numbers of bytes and see that sane values are obtained Build and boot U-boot with this patch, backlight works properly. Signed-off-by: Padmavathi Venna padm...@samsung.com Signed-off-by: Akshay Saraswat aksha...@samsung.com --- board/samsung/smdk5250/setup.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/samsung/smdk5250/setup.h b/board/samsung/smdk5250/setup.h index a159601..34d8bc3 100644 --- a/board/samsung/smdk5250/setup.h +++ b/board/samsung/smdk5250/setup.h @@ -343,7 +343,7 @@ #define TOP2_VAL 0x011 /* CLK_SRC_PERIC0 */ -#define PWM_SEL0 +#define PWM_SEL6 #define UART3_SEL 6 #define UART2_SEL 6 #define UART1_SEL 6 -- 1.8.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] problem with USB storage STALL status
Greetings, I faced with problem: when I read data from USB Storage It unpredictably goes to 'RESET:stall' condition. After this read continuously fall down to usb_stor_BBB_reset() function Comment to this function told about Reset recovery: * For Reset Recovery the host shall issue in the following order: * a) a Bulk-Only Mass Storage Reset * b) a Clear Feature HALT to the Bulk-In endpoint * c) a Clear Feature HALT to the Bulk-Out endpoint * * This is done in 3 steps. * * If the reset doesn't succeed, the device should be port reset. Whereas Universal Serial Bus Specification Revision 2.0 in section 8.5.3 describes that STALL handshake will be returned on all succeeding accesses until a SETUP PID is received. I can't understand how correctly work with STALL status and where is a root of problem. Debug information is following: STATUS phase dev=3f3b03d8, pipe=c8008383, buffer=3f1f7490, length=13, req=(null) TOKEN=0x80008d00 .read10: start 7c70 blocks 28 COMMAND phase dev=3f3b03d8, pipe=c8008303, buffer=3f1f7444, length=31, req=(null) TOKEN=0x80008c00 DATA phase dev=3f3b03d8, pipe=c8008383, buffer=0058e000, length=20480, req=(null) TOKEN=0x8000dd08 usb_bulk_msg error status 32 BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 dev=3f3b03d8, pipe=88000303, buffer=(null), length=0, req=3f1f7430 req=255 (0xff), type=33 (0x21), value=0 (0x0), index=0 TOKEN=0x80248 RESET:stall Read ERROR COMMAND phase dev=3f3b03d8, pipe=c8008303, buffer=3f1f7444, length=31, req=(null) dev=3, usbsts=0x88, p[1]=0x8001205, p[2]=0x0 usb_stor_BBB_comdat:usb_bulk_msg error failed to send CBW status -2147483648 BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 dev=3f3b03d8, pipe=88000303, buffer=(null), length=0, req=3f1f7430 req=255 (0xff), type=33 (0x21), value=0 (0x0), index=0 TOKEN=0x80248 RESET:stall Request Sense returned 00 00 00 .read10: start 7c70 blocks 28 COMMAND phase dev=3f3b03d8, pipe=c8008303, buffer=3f1f7444, length=31, req=(null) dev=3, usbsts=0x88, p[1]=0x8001205, p[2]=0x0 usb_stor_BBB_comdat:usb_bulk_msg error failed to send CBW status -2147483648 BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 dev=3f3b03d8, pipe=88000303, buffer=(null), length=0, req=3f1f7430 req=255 (0xff), type=33 (0x21), value=0 (0x0), index=0 TOKEN=0x80248 RESET:stall Read ERROR COMMAND phase dev=3f3b03d8, pipe=c8008303, buffer=3f1f7444, length=31, req=(null) dev=3, usbsts=0x88, p[1]=0x8001205, p[2]=0x0 usb_stor_BBB_comdat:usb_bulk_msg error failed to send CBW status -2147483648 BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 dev=3f3b03d8, pipe=88000303, buffer=(null), length=0, req=3f1f7430 req=255 (0xff), type=33 (0x21), value=0 (0x0), index=0 TOKEN=0x80248 RESET:stall Request Sense returned 00 00 00 .read10: start 7c70 blocks 28 COMMAND phase dev=3f3b03d8, pipe=c8008303, buffer=3f1f7444, length=31, req=(null) dev=3, usbsts=0x88, p[1]=0x8001205, p[2]=0x0 usb_stor_BBB_comdat:usb_bulk_msg error failed to send CBW status -2147483648 BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 dev=3f3b03d8, pipe=88000303, buffer=(null), length=0, req=3f1f7430 req=255 (0xff), type=33 (0x21), value=0 (0x0), index=0 TOKEN=0x80248 RESET:stall Read ERROR -- Best regards, Anton Vasilyev. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Flash protection and fw_setenv tool
Hi again, I just found this thread: [U-Boot] fw_setenv on protected flash It deals with exactly the same problem. I updated my kernel with the patch mentioned there to support flash protection and everything is ok now. The patch I provided here is useless now. Regards Georg -Ursprüngliche Nachricht- Von: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] Im Auftrag von Waibel Georg Gesendet: Dienstag, 26. Februar 2013 16:04 An: 'Eibach, Dirk'; u-boot@lists.denx.de Cc: Stefan Roese Betreff: Re: [U-Boot] Flash protection and fw_setenv tool Hi Dirk, I enabled the flash protection to protect the UBoot from being overwritten, since this means that customers need to send back the device for reprogramming the UBoot (without a valid bootloader, our MPC5200 target can only be accesses by a programmer like the BDI2000 debugger). Thus for our application it makes sense to have the protection on. Having the CONFIG_ENV_UNPROTECTED option fits to our requirements pretty well. I was just wondering if this option is something that is commonly useful... Thanks and regards Georg -Ursprüngliche Nachricht- Von: Eibach, Dirk [mailto:eib...@gdsys.de] Gesendet: Dienstag, 26. Februar 2013 15:07 An: Waibel Georg; u-boot@lists.denx.de Cc: Stefan Roese Betreff: RE: [U-Boot] Flash protection and fw_setenv tool Hi Georg, maybe removing CONFIG_SYS_FLASH_PROTECTION from your configuration does already what you want to achieve. BTW Linux support should be available here: http://patchwork.ozlabs.org/patch/213602/ Cheers Dirk -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Waibel Georg Sent: Tuesday, February 26, 2013 1:46 PM To: u-boot@lists.denx.de Subject: Re: [U-Boot] Flash protection and fw_setenv tool Hi again, the previous patch missed some places to apply the unprotect switch. Here's an improved version: Index: common/env_flash.c == = --- common/env_flash.c(revision 4065) +++ common/env_flash.c(working copy) @@ -218,9 +218,12 @@ done: if (saved_data) free(saved_data); + +#ifndef CONFIG_ENV_UNPROTECTED /* try to re-protect */ flash_sect_protect(1, (ulong)flash_addr, end_addr); flash_sect_protect(1, (ulong)flash_addr_new, end_addr_new); +#endif return rc; } @@ -310,7 +313,9 @@ if (saved_data) free(saved_data); /* try to re-protect */ +#ifndef CONFIG_ENV_UNPROTECTED flash_sect_protect(1, (long)flash_addr, end_addr); +#endif return rc; } #endif /* CMD_SAVEENV */ @@ -340,7 +345,9 @@ flash_write(flag, (ulong)(flash_addr_new-flags), sizeof(flash_addr_new-flags)); +#ifndef CONFIG_ENV_UNPROTECTED flash_sect_protect(1, (ulong)flash_addr_new, end_addr_new); +#endif } if (flash_addr-flags != ACTIVE_FLAG @@ -352,7 +359,9 @@ flash_write(flag, (ulong)(flash_addr-flags), sizeof(flash_addr-flags)); +#ifndef CONFIG_ENV_UNPROTECTED flash_sect_protect(1, (ulong)flash_addr, end_addr); +#endif } if (gd-env_valid == 2) Index: drivers/mtd/cfi_flash.c == = --- drivers/mtd/cfi_flash.c (revision 4065) +++ drivers/mtd/cfi_flash.c (working copy) @@ -2294,7 +2294,7 @@ #endif /* Environment protection ON by default */ -#ifdef CONFIG_ENV_IS_IN_FLASH +#if defined(CONFIG_ENV_IS_IN_FLASH) !defined(CONFIG_ENV_UNPROTECTED) flash_protect(FLAG_PROTECT_SET, CONFIG_ENV_ADDR, CONFIG_ENV_ADDR + CONFIG_ENV_SECT_SIZE - 1, @@ - 2302,7 +2302,7 @@ #endif /* Redundant environment protection ON by default */ -#ifdef CONFIG_ENV_ADDR_REDUND +#if defined(CONFIG_ENV_ADDR_REDUND) !defined(CONFIG_ENV_UNPROTECTED) flash_protect(FLAG_PROTECT_SET, CONFIG_ENV_ADDR_REDUND, CONFIG_ENV_ADDR_REDUND + CONFIG_ENV_SECT_SIZE - 1, Regards Georg -- -- Messe-Highlights 2013. Wir freuen uns auf Ihren Besuch. Broadcast Video Expo 2013 London - 26.02. bis 28.02.2013 - Stand B22 CeBIT 2013 In Hannover - 05.03. bis 09.03.2012 - Halle 11, Stand D31 ATC Global 2013 Amsterdam - 12.03. bis 14.03.2012 - Halle 10, Stand D202 -- -- Besuchen Sie unseren Blog auf http://blog.gdsys.de oder folgen Sie uns auf: twitter: http://twitter.com/#!/gdsys facebook:
Re: [U-Boot] [PATCH v2 2/2] mtd: nand: mxc_nand: Fix is_16bit_nand()
Hi Fabio, Le Tue, 26 Feb 2013 15:35:20 -0300, Fabio Estevam fabio.este...@freescale.com a écrit : Currently is_16bit_nand() is a per SoC function and it decides the bus nand width by reading some boot related registers. This method works when NAND is the boot medium, but does not work if another boot medium is used. For example: booting from a SD card and then using NAND to store the environment variables, would lead to the following error: NAND bus width 16 instead 8 bit No NAND device found!!! 0 MiB Use CONFIG_SYS_NAND_BUSWIDTH_16BIT symbol to decide the bus width. If it is defined in the board file, then consider 16-bit NAND bus-width, otherwise assume 8-bit NAND is used. This also aligns with Documentation/devicetree/bindings/mtd/nand.txt, which states: nand-bus-width : 8 or 16 bus width if not present 82 are you sure that your patch won't break current boards booting on nand flash (and so which can use the current functions to detect the nand width) ? Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] mtd: nand: mxc_nand: Fix is_16bit_nand()
Hi Eric, On Wednesday, February 27, 2013 12:11:04 PM, Eric Bénard wrote: Hi Fabio, Le Tue, 26 Feb 2013 15:35:20 -0300, Fabio Estevam fabio.este...@freescale.com a écrit : Currently is_16bit_nand() is a per SoC function and it decides the bus nand width by reading some boot related registers. This method works when NAND is the boot medium, but does not work if another boot medium is used. For example: booting from a SD card and then using NAND to store the environment variables, would lead to the following error: NAND bus width 16 instead 8 bit No NAND device found!!! 0 MiB Use CONFIG_SYS_NAND_BUSWIDTH_16BIT symbol to decide the bus width. If it is defined in the board file, then consider 16-bit NAND bus-width, otherwise assume 8-bit NAND is used. This also aligns with Documentation/devicetree/bindings/mtd/nand.txt, which states: nand-bus-width : 8 or 16 bus width if not present 82 are you sure that your patch won't break current boards booting on nand flash (and so which can use the current functions to detect the nand width) ? This code is not used for NAND boot, for which the SPL version of this driver and CONFIG_SYS_NAND_BUSWIDTH_16 are used. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] mtd: nand: mxc_nand: Fix is_16bit_nand()
Hi Benoît, Le Wed, 27 Feb 2013 13:53:10 +0100 (CET), Benoît Thébaudeau benoit.thebaud...@advansee.com a écrit : This code is not used for NAND boot, for which the SPL version of this driver and CONFIG_SYS_NAND_BUSWIDTH_16 are used. I didn't follow SPL migration (I have to come back to it so the next question may be stupid sorry in advance) but once u-boot is running isn't it using the standard driver and no more the SPL one ? Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] mtd: nand: mxc_nand: Fix is_16bit_nand()
Hi Eric, On Wed, Feb 27, 2013 at 8:11 AM, Eric Bénard e...@eukrea.com wrote: are you sure that your patch won't break current boards booting on nand flash (and so which can use the current functions to detect the nand width) ? If a board is booting from NAND, then it is required that the boot jumpers are correctly set to specify NAND boot mode and the NAND type (8-bit versus 16-bit width, for example). I revisited all the i.mx boards that use MXC_NAND driver and could not see anyone using 16-bit NAND (ie, no 16-bit NAND IOMUX setting), so it is safe to assume that all the current boards are using 8-bit width NAND. If a board has 16-bit width NAND, then the boot jumpers need to reflect that and CONFIG_SYS_NAND_BUSWIDTH_16BIT must be specified in the config file. So I don't envision any breakage here. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] am335x_evm: Add CONFIG_CMD_MTDPARTS and relevant defaults
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/27/2013 03:54 AM, Peter Korsgaard wrote: Tom == Tom Rini tr...@ti.com writes: Tom Signed-off-by: Tom Rini tr...@ti.com Tom --- Tom include/configs/am335x_evm.h |9 + Tom 1 file changed, 9 insertions(+) Tom diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h Tom index 59647d1..61b861d 100644 Tom --- a/include/configs/am335x_evm.h Tom +++ b/include/configs/am335x_evm.h Tom @@ -60,6 +60,8 @@ Tom fdtfile=\0 \ Tom console=ttyO0,115200n8\0 \ Tom optargs=\0 \ Tom + mtdids= MTDIDS_DEFAULT \0 \ Tom + mtdparts= MTDPARTS_DEFAULT \0 \ Tom mmcdev=0\0 \ Tom mmcroot=/dev/mmcblk0p2 ro\0 \ Tom mmcrootfstype=ext4 rootwait\0 \ Tom @@ -341,6 +343,13 @@ Tom /* NAND support */ Tom #ifdef CONFIG_NAND Tom #define CONFIG_CMD_NAND Tom +#define CONFIG_CMD_MTDPARTS Tom +#define MTDIDS_DEFAULT nand0=omap2-nand.0 Tom +#define MTDPARTS_DEFAULT mtdparts=omap2-nand.0:128k(SPL), \ Tom + 128k(SPL.backup1), \ Tom + 128k(SPL.backup2), \ Tom + 128k(SPL.backup3),1920k(u-boot), \ Tom + 128k(u-boot-env),5m(kernel),-(rootfs) Is there a particular reason why the u-boot partition is so big? Convention (which would allow for redundant copies of U-Boot within this area) I believe. Same as some of the semi-related boards. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRLghGAAoJENk4IS6UOR1WU20QAJZdE9KI282/72AA6i47SDzG G1TLymHDOddNBp2ylcjyxkdWNKRxk348Z/bGJ25VIv+jcbRv/SubTnyXsT1RkFX2 qxzJU5/hsMqEQ5++jVbAjph0zBCBFYR68XJ7r4vjLO0N9/eJKR/zNkxqMeQMMY2j LVsdju2DfRYAWn9d8CuM2vRrf5iscK3PB6AEqO4SafMtHCxkzLScmAsvQMEUekkZ sWkYRVnLEbSmdSnRdnHi0Yt0jiMSULVoGelMbyOA+I9FEsgQaaY0S4Sy7YOOR6ml Ajkv8j7TZvHsOZRponsxv6dsJq9CZlnzlSLrhrXi1EjAKnSlUukF6D4mWdkMQnXX MoX2o1ICLL5qti1fqlv6f+JWeT5a0PydWRHy9Y8+g3kZCRcXFLKwrdVb1F/x7AVt 5z1g6f9QEzw9CoJZDSRSLnc2+wdntsZs4KGGeoWFfqzQfej5eW11j43Is23zNkys XB+6EILlotNttLoHJ2SzcHUG5dRKJ+I6sCuVDtWd90Bw7uFO1i9p+uwYcNhOiDXz qbxu11ZSvH8A7/XD5vfdsDmStGl7+SMikO/rY0YHrS575AWcbOC4tcUaJtSHpyMD nUDOsQ25G59pdA0+B2CoY22nbRM4tRpQA5S+jlSuAtYpPL5GcSifE6zXvO96zX9D lUzhyJmHgxs8/caWWgFe =NVWs -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] mtd: nand: mxc_nand: Fix is_16bit_nand()
Hi Eric, On Wednesday, February 27, 2013 2:15:21 PM, Eric Bénard wrote: Hi Benoît, Le Wed, 27 Feb 2013 13:53:10 +0100 (CET), Benoît Thébaudeau benoit.thebaud...@advansee.com a écrit : This code is not used for NAND boot, for which the SPL version of this driver and CONFIG_SYS_NAND_BUSWIDTH_16 are used. I didn't follow SPL migration (I have to come back to it so the next question may be stupid sorry in advance) but once u-boot is running isn't it using the standard driver and no more the SPL one ? Yes, that's correct (unless you need to access NAND only from SPL). But if any board booting from NAND had a 16-bit NAND, CONFIG_SYS_NAND_BUSWIDTH_16 would have to be defined, which no board does, so none of these boards needs CONFIG_SYS_NAND_BUSWIDTH_16BIT either. And the rest of the explanation is what Fabio has just said. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] nand: Extend nand_(read|write)_skip_bad with *actual and limit parameters
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/26/2013 09:08 PM, Scott Wood wrote:
On 02/26/2013 09:56:08 AM, Tom Rini wrote:
We make these two functions take a size_t pointer to how much
space was used on NAND to read or write the buffer (when
reads/writes happen) so that bad blocks can be accounted for.
We also make them take an loff_t limit on how much data can be
read or written. This means that we can now catch the case of
when writing to a partition would exceed the partition size due
to bad blocks. To do this we also need to make check_skip_len
care about total actual size used rather than block_size chunks
used. All callers of nand_(read|write)_skip_bad are adjusted to
call these with the most sensible limits available.
The changes were started by Pantelis and finished by Tom.
Cc: Scott Wood scottw...@freescale.com Signed-off-by: Pantelis
Antoniou pa...@antoniou-consulting.com Signed-off-by: Tom Rini
tr...@ti.com --- common/cmd_nand.c| 61
+ common/env_nand.c |
5 ++-- drivers/mtd/nand/nand_util.c | 62
+++--- include/nand.h |4
+-- 4 files changed, 82 insertions(+), 50 deletions(-)
diff --git a/common/cmd_nand.c b/common/cmd_nand.c index
1568594..e091e02 100644 --- a/common/cmd_nand.c +++
b/common/cmd_nand.c @@ -137,7 +137,8 @@ static inline int
str2long(const char *p, ulong *num) return *p != '\0' *endptr
== '\0'; }
-static int get_part(const char *partname, int *idx, loff_t *off,
loff_t *size) +static int get_part(const char *partname, int
*idx, loff_t *off, loff_t *size, +loff_t *maxsize) {
#ifdef CONFIG_CMD_MTDPARTS struct mtd_device *dev; @@ -160,6
+161,7 @@ static int get_part(const char *partname, int *idx,
loff_t *off, loff_t *size)
*off = part-offset; *size = part-size; +*maxsize =
part-offset + part-size; *idx = dev-id-num;
The name maxsize suggests that it's a size, not a position.
OK, I'll call it maxoff (because it's the max offset within the NAND
for a given partition, or end of the NAND).
ret = set_dev(*idx); @@ -173,10 +175,11 @@ static int
get_part(const char *partname, int *idx, loff_t *off, loff_t
*size) #endif }
-static int arg_off(const char *arg, int *idx, loff_t *off,
loff_t *maxsize) +static int arg_off(const char *arg, int *idx,
loff_t *off, loff_t *size, +loff_t *maxsize) { if
(!str2off(arg, off)) -return get_part(arg, idx, off,
maxsize); +return get_part(arg, idx, off, size,
maxsize);
if (*off = nand_info[*idx].size) { puts(Offset exceeds device
limit\n);
...and in the get_part case arg-off is still treating maxsize as a
size.
OK, bug here then I missed. Making sure both *size and *maxoff are
set when get_part doesn't set them.
[snip]
-ret = nand_write_skip_bad(nand, off, rwsize, -
(u_char *)addr, +ret = nand_write_skip_bad(nand,
off, rwsize, actual, +maxsize, (u_char
*)addr, WITH_DROP_FFS);
Do we care about actual here? Let the skip_bad functions accept
NULL if the caller doesn't care.
Will make it so.
diff --git a/drivers/mtd/nand/nand_util.c
b/drivers/mtd/nand/nand_util.c index 2ba0c5e..5ed5b1d 100644 ---
a/drivers/mtd/nand/nand_util.c +++ b/drivers/mtd/nand/nand_util.c
@@ -397,34 +397,38 @@ int nand_unlock(struct mtd_info *mtd,
loff_t start, size_t length, * blocks fits into device * * @param
nand NAND device - * @param offset offset in flash + * @param
offsetp offset in flash (on exit offset where it's ending) *
@param length image length * @return 0 if the image fits and
there are no bad blocks * 1 if the image fits, but there are bad
blocks *-1 if the image does not fit */ -static int
check_skip_len(nand_info_t *nand, loff_t offset, size_t length)
+static int check_skip_len(nand_info_t *nand, loff_t *offset,
size_t length)
Comment changed offset to offsetp but code did not.
Oops.
Can we use a different parameter to return the end offset (or
actual size)? That way we don't need the tmp_offset stuff, and
there should be fewer changes to this function.
First, the big changes to the function are so that we track (and
report back) the correct amount of a partial block we would use for
the request. I'll see if I can't do something like loff_t offset,
*something else.
[snip]
Traditionally U-Boot style has been to use braces on both sides of
an if/else if one side needs them.
OK, fixing.
-offset += block_len; +*offset += block_len; }
return ret; @@ -459,22 +463,26 @@ static size_t drop_ffs(const
nand_info_t *nand, const u_char *buf, * Write image to NAND
flash. * Blocks that are marked bad are skipped and the is
written to the next * block instead as long as the image is
short enough to fit even after - * skipping the bad blocks. + *
skipping the bad blocks. Note that the actual size needed may
exceed + * both
[U-Boot] [PATCH 3/4] gen: Add sha256 command
sha256 command is added which can be used to test SHA 256 hash
algorithm.
TEST=sha256 0x40008000 0x2B 0x40009000
Used mm and md to write a standard string to memory location
0x40008000 and ran the above command to verify the output.
Signed-off-by: ARUN MANKUZHI aru...@samsung.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
---
common/Makefile | 1 +
common/cmd_sha256.c | 69 +
2 files changed, 70 insertions(+)
create mode 100644 common/cmd_sha256.c
diff --git a/common/Makefile b/common/Makefile
index 54fcc81..6170ed5 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -201,6 +201,7 @@ COBJS-$(CONFIG_MENU) += menu.o
COBJS-$(CONFIG_MODEM_SUPPORT) += modem.o
COBJS-$(CONFIG_UPDATE_TFTP) += update.o
COBJS-$(CONFIG_USB_KEYBOARD) += usb_kbd.o
+COBJS-$(CONFIG_CMD_SHA256) += cmd_sha256.o
COBJS-$(CONFIG_CMD_DFU) += cmd_dfu.o
COBJS-$(CONFIG_CMD_GPT) += cmd_gpt.o
endif
diff --git a/common/cmd_sha256.c b/common/cmd_sha256.c
new file mode 100644
index 000..e4f6b56
--- /dev/null
+++ b/common/cmd_sha256.c
@@ -0,0 +1,69 @@
+/*
+ * Copyright 2000-2009
+ * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include command.h
+#ifdef CONFIG_EXYNOS_ACE_SHA
+#include asm/arch/ace_sha.h
+#else
+#include sha256.h
+#endif
+
+int do_sha256(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ unsigned long inlen;
+ unsigned char *input, *out;
+ int i;
+#ifndef CONFIG_EXYNOS_ACE_SHA
+ sha256_context sha_cnxt;
+#endif
+ if (argc 4) {
+ printf(usage: sha256 input input length output\n);
+ return 0;
+ }
+ input = (unsigned char *)simple_strtoul(argv[1], NULL, 16);
+ inlen = simple_strtoul(argv[2], NULL, 16);
+ out = (unsigned char *)simple_strtoul(argv[3], NULL, 16);
+
+#ifdef CONFIG_EXYNOS_ACE_SHA
+ ace_sha_hash_digest(out, input, inlen, 2);
+#else
+ sha256_starts(sha_cnxt);
+
+ sha256_update(sha_cnxt, input, inlen);
+
+ sha256_finish(sha_cnxt, out);
+#endif
+
+ for (i = 0; i 32; i++)
+ printf(0x%02X , out[i]);
+ printf(\n);
+
+ return 0;
+}
+
+U_BOOT_CMD(
+ sha256, 4, 1, do_sha256,
+ print hash result,
+ input inputlength output
+);
--
1.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] Exynos: Flush memory region before starting SHA DMA operation
SHA256 commands weren't giving desired output since the data we set
in the memory addresses through mw.l commands was not getting updated
in actual memory. Adding this patch resolves the issue.
TEST=sha256 0x40008000 0x2B 0x40009000
Used mm and md to write a standard string to memory location
0x40008000 and ran the above command to verify the output.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
---
arch/arm/cpu/armv7/exynos/ace_sha.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/cpu/armv7/exynos/ace_sha.c
b/arch/arm/cpu/armv7/exynos/ace_sha.c
index 2715a03..9ac34be 100644
--- a/arch/arm/cpu/armv7/exynos/ace_sha.c
+++ b/arch/arm/cpu/armv7/exynos/ace_sha.c
@@ -51,6 +51,11 @@ int ace_sha_hash_digest(
struct exynos_ace_sfr *ace_sha_reg =
(struct exynos_ace_sfr *) samsung_get_base_ace_sfr();
+ /* Flush input and output memory buffers berore starting DMA */
+ flush_dcache_range((unsigned long) pout, (unsigned long)(pout + 0x20));
+ flush_dcache_range((unsigned long) pbuf,
+ (unsigned long)(pbuf + buf_len));
+
if (buf_len == 0) {
/* ACE H/W cannot compute hash value for empty string */
if (hash_type == ACE_SHA_TYPE_SHA1)
--
1.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] Exynos: Add hardware accelerated SHA 256
SHA-256 and SHA-1 accelerated using ACE hardware.
TEST=sha256 0x40008000 0x2B 0x40009000
Used mm and md to write a standard string to memory location
0x40008000 and ran the above command to verify the output.
Signed-off-by: ARUN MANKUZHI aru...@samsung.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
---
arch/arm/cpu/armv7/exynos/Makefile | 4 +
arch/arm/cpu/armv7/exynos/ace_sha.c| 118 +++
arch/arm/include/asm/arch-exynos/ace_sfr.h | 310 +
arch/arm/include/asm/arch-exynos/ace_sha.h | 41
arch/arm/include/asm/arch-exynos/cpu.h | 4 +
5 files changed, 477 insertions(+)
create mode 100644 arch/arm/cpu/armv7/exynos/ace_sha.c
create mode 100644 arch/arm/include/asm/arch-exynos/ace_sfr.h
create mode 100644 arch/arm/include/asm/arch-exynos/ace_sha.h
diff --git a/arch/arm/cpu/armv7/exynos/Makefile
b/arch/arm/cpu/armv7/exynos/Makefile
index 9119961..0a93a52 100644
--- a/arch/arm/cpu/armv7/exynos/Makefile
+++ b/arch/arm/cpu/armv7/exynos/Makefile
@@ -24,6 +24,10 @@ LIB = $(obj)lib$(SOC).o
COBJS += clock.o power.o soc.o system.o pinmux.o
+ifdef CONFIG_EXYNOS_ACE_SHA
+COBJS += ace_sha.o
+endif
+
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS))
diff --git a/arch/arm/cpu/armv7/exynos/ace_sha.c
b/arch/arm/cpu/armv7/exynos/ace_sha.c
new file mode 100644
index 000..2715a03
--- /dev/null
+++ b/arch/arm/cpu/armv7/exynos/ace_sha.c
@@ -0,0 +1,118 @@
+/*
+ * Advanced Crypto Engine - SHA Firmware
+ *
+ * Copyright (c) 2012 Samsung Electronics
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+#include common.h
+#include asm/arch/ace_sha.h
+#include asm/arch/ace_sfr.h
+
+/* Maximum input data size is 8 MB. Timeout observed for data size above 8MB */
+#define TIMEOUT_MS 100
+
+#define SHA1_DIGEST_LEN20
+#define SHA256_DIGEST_LEN 32
+
+/* SHA1 value for the message of zero length */
+static const unsigned char sha1_digest_emptymsg[SHA1_DIGEST_LEN] = {
+ 0xDA, 0x39, 0xA3, 0xEE, 0x5E, 0x6B, 0x4B, 0x0D,
+ 0x32, 0x55, 0xBF, 0xFF, 0x95, 0x60, 0x18, 0x90,
+ 0xAF, 0xD8, 0x07, 0x09};
+
+/* SHA256 value for the message of zero length */
+static const unsigned char sha256_digest_emptymsg[SHA256_DIGEST_LEN] = {
+ 0xE3, 0xB0, 0xC4, 0x42, 0x98, 0xFC, 0x1C, 0x14,
+ 0x9A, 0xFB, 0xF4, 0xC8, 0x99, 0x6F, 0xB9, 0x24,
+ 0x27, 0xAE, 0x41, 0xE4, 0x64, 0x9B, 0x93, 0x4C,
+ 0xA4, 0x95, 0x99, 0x1B, 0x78, 0x52, 0xB8, 0x55};
+
+int ace_sha_hash_digest(
+ unsigned char *pout, unsigned char *pbuf,
+ unsigned int buf_len, unsigned int hash_type)
+{
+ unsigned int i, reg, len;
+ unsigned int *pdigest;
+ ulong start;
+ struct exynos_ace_sfr *ace_sha_reg =
+ (struct exynos_ace_sfr *) samsung_get_base_ace_sfr();
+
+ if (buf_len == 0) {
+ /* ACE H/W cannot compute hash value for empty string */
+ if (hash_type == ACE_SHA_TYPE_SHA1)
+ memcpy(pout, sha1_digest_emptymsg, SHA1_DIGEST_LEN);
+ else
+ memcpy(pout, sha256_digest_emptymsg, SHA256_DIGEST_LEN);
+ return 0;
+ }
+
+ /* Flush HRDMA */
+ writel(ACE_FC_HRDMACFLUSH_ON, ace_sha_reg-fc_hrdmac);
+ writel(ACE_FC_HRDMACFLUSH_OFF, ace_sha_reg-fc_hrdmac);
+
+ /* Set byte swap of data in */
+ writel(ACE_HASH_SWAPDI_ON | ACE_HASH_SWAPDO_ON | ACE_HASH_SWAPIV_ON,
+ ace_sha_reg-hash_byteswap);
+
+ /* Select Hash input mux as external source */
+ reg = readl(ace_sha_reg-fc_fifoctrl);
+ reg = (reg ~ACE_FC_SELHASH_MASK) | ACE_FC_SELHASH_EXOUT;
+ writel(reg, ace_sha_reg-fc_fifoctrl);
+
+ /* Set Hash as SHA1 or SHA256 and start Hash engine */
+ reg = (hash_type == ACE_SHA_TYPE_SHA1) ?
+ ACE_HASH_ENGSEL_SHA1HASH : ACE_HASH_ENGSEL_SHA256HASH;
+ reg |= ACE_HASH_STARTBIT_ON;
+ writel(reg, ace_sha_reg-hash_control);
+
+ /* Enable FIFO mode */
+ writel(ACE_HASH_FIFO_ON, ace_sha_reg-hash_fifo_mode);
+
+ /* Set message length */
+ writel(buf_len, ace_sha_reg-hash_msgsize_low);
+ writel(0, ace_sha_reg-hash_msgsize_high);
+
+ /* Set HRDMA */
+
[U-Boot] [PATCH 2/4] Exynos: config: Enable ACE HW for SHA 256 for Exynos
This enables SHA 256 for exynos. TEST=sha256 0x40008000 0x2B 0x40009000 Used mm and md to write a standard string to memory location 0x40008000 and ran the above command to verify the output. Signed-off-by: ARUN MANKUZHI aru...@samsung.com Signed-off-by: Akshay Saraswat aksha...@samsung.com --- include/configs/exynos5250-dt.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h index cabd2f2..3963aaf 100644 --- a/include/configs/exynos5250-dt.h +++ b/include/configs/exynos5250-dt.h @@ -45,6 +45,9 @@ /* Keep L2 Cache Disabled */ #define CONFIG_SYS_DCACHE_OFF +#define CONFIG_CMD_SHA256 +#define CONFIG_EXYNOS_ACE_SHA + #define CONFIG_SYS_SDRAM_BASE 0x4000 #define CONFIG_SYS_TEXT_BASE 0x43E0 -- 1.8.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/4] Add ACE HW support for SHA 256
This patch set adds hardware acceleration for SHA 256 with the help of ACE. Akshay Saraswat (4): Exynos: Add hardware accelerated SHA 256 Exynos: config: Enable ACE HW for SHA 256 for Exynos gen: Add sha256 command Exynos: Flush memory region before starting SHA DMA operation arch/arm/cpu/armv7/exynos/Makefile | 4 + arch/arm/cpu/armv7/exynos/ace_sha.c| 123 arch/arm/include/asm/arch-exynos/ace_sfr.h | 310 + arch/arm/include/asm/arch-exynos/ace_sha.h | 41 arch/arm/include/asm/arch-exynos/cpu.h | 4 + common/Makefile| 1 + common/cmd_sha256.c| 69 +++ include/configs/exynos5250-dt.h| 3 + 8 files changed, 555 insertions(+) create mode 100644 arch/arm/cpu/armv7/exynos/ace_sha.c create mode 100644 arch/arm/include/asm/arch-exynos/ace_sfr.h create mode 100644 arch/arm/include/asm/arch-exynos/ace_sha.h create mode 100644 common/cmd_sha256.c -- 1.8.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Tegra114: fdt: Sync DT nodes with kernel DT files (GPIO, tegra_car)
Stephen, On Tue, Feb 26, 2013 at 3:35 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 02/26/2013 03:08 PM, Tom Warren wrote: Minor edit to tegra_car node, add gpio node. diff --git a/arch/arm/dts/tegra114.dtsi b/arch/arm/dts/tegra114.dtsi - compatible = nvidia,tegra114-car; ... + compatible = nvidia,tegra114-car, nvidia,tegra30-car; The former is actually correct; the kernel DT is wrong here (the bug was actually needed to temporarily work around not having a Tegra114 clock driver), and a patch will be applied to fix this as soon as I can start applying patches for 3.10. It's part of: http://patchwork.ozlabs.org/patch/220736/ The GPIO change looks fine. OK, car compatible string fixed, V2 on it's way. Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Tegra114: fdt: Sync DT nodes with kernel DT files (GPIO, tegra_car)
Minor edit to tegra_car node, add gpio node.
Signed-off-by: Tom Warren twar...@nvidia.com
---
v2: Remove Tegra30 from tegra_car compatible field as per StephenW
arch/arm/dts/tegra114.dtsi | 19 ++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/arch/arm/dts/tegra114.dtsi b/arch/arm/dts/tegra114.dtsi
index f0f82de..dfeac53 100644
--- a/arch/arm/dts/tegra114.dtsi
+++ b/arch/arm/dts/tegra114.dtsi
@@ -11,12 +11,29 @@
i2c4 = /i2c@7000c700;
};
- tegra_car: clock@60006000 {
+ tegra_car: clock {
compatible = nvidia,tegra114-car;
reg = 0x60006000 0x1000;
#clock-cells = 1;
};
+ gpio: gpio {
+ compatible = nvidia,tegra114-gpio, nvidia,tegra30-gpio;
+ reg = 0x6000d000 0x1000;
+ interrupts = 0 32 0x04
+ 0 33 0x04
+ 0 34 0x04
+ 0 35 0x04
+ 0 55 0x04
+ 0 87 0x04
+ 0 89 0x04
+ 0 125 0x04;
+ #gpio-cells = 2;
+ gpio-controller;
+ #interrupt-cells = 2;
+ interrupt-controller;
+ };
+
i2c@7000c000 {
compatible = nvidia,tegra114-i2c;
reg = 0x7000c000 0x100;
--
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 1/5] Tegra30: fdt: Add SDMMC (sdhci) nodes for T30 boards (Cardhu for now)
Stephen/Rhyland,
On Tue, Feb 26, 2013 at 4:10 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 02/26/2013 01:46 PM, Tom Warren wrote:
Took these values directly from the kernel dts files.
diff --git a/arch/arm/dts/tegra30.dtsi b/arch/arm/dts/tegra30.dtsi
+ sdhci@7800 {
+ compatible = nvidia,tegra30-sdhci, nvidia,tegra20-sdhci;
Looking at this more, I /think/ this should only include the Tegra30
compatible value, since there are new quirks that are required to be
enabled on Tegra30 relative to Tegra20 or the HW won't work. The kernel
DT file is no doubt buggy here.
Looking at the SDMMC reg space in the T20 and T30 TRMs, I don't see
anything major that would make the MMC driver not work on T30 as is
(in fact, I know it works just fine w/o modification). Looking at the
sdhci-tegra.c driver source, the only quirk difference is
DATA_TIMEOUT_USES_SDCLK. The U-Boot Tegra MMC driver doesn't reference
the caps Timeout Clock Frequency bits, so this quirk/difference
doesn't matter.
Cc'ing Rhyland and Pavan to confirm this. (Note: this is
Tegra30-vs-Tegra20, not Tegra114-vs-Tegra30 that we just discussed
downstream).
Let's see what Rhyland/Pavan have to say before I change this.
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] nand: Extend nand_(read|write)_skip_bad with *actual and limit parameters
On Tue, Feb 26, 2013 at 10:56:08AM -0500, Tom Rini wrote:
We make these two functions take a size_t pointer to how much space
was used on NAND to read or write the buffer (when reads/writes happen)
so that bad blocks can be accounted for. We also make them take an
loff_t limit on how much data can be read or written. This means that
we can now catch the case of when writing to a partition would exceed
the partition size due to bad blocks. To do this we also need to make
[snip]
int nand_read_skip_bad(nand_info_t *nand, loff_t offset, size_t *length,
-u_char *buffer)
+size_t *actual, loff_t lim, u_char *buffer)
[snip]
+ if (*actual lim) {
+ puts(Size of read exceeds partition or device limit\n);
+ *length = 0;
+ return -EFBIG;
+ }
The more I look at this and try testing things, I think I shouldn't be
introducing a change here. Before you could do:
nand read ${address} partname-with-badblock
And it would suceed but bleed into the next partition if it wasn't the
last one. So your production system could do nand read ${address}
kernel and be OK. But with this change, it would fail because reading
the whole partition is now too large with a bad block (you would need
partition+(blocksize*number bad blocks).
So I'm going to put this back to a check simply against requested size
being greater than lim rather than required size greater than lim (since
required size exceeds device is still caught).
--
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] nand: adjust erase/read/write partition/chip size for bad blocks
On 02/26/2013 09:04:22 PM, Harvey Chapman wrote: On Feb 26, 2013, at 8:42 PM, Scott Wood scottw...@freescale.com wrote: No need to be quite so verbose in the comments. If someone tries to change size to rwsize the compiler will complain about the type mismatch. Actually, it does give a warning that flies by and is buried inside the compile log. Then, it'll let you run and walk on memory. Ask me how I know. :) Warnings are easier to spot if you pass -s to make (or use MAKEALL which does this). -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] Tegra30: MMC: Add SD bus power-rail and SDMMC pad init routines
Stephen,
On Tue, Feb 26, 2013 at 4:26 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 02/26/2013 01:46 PM, Tom Warren wrote:
T30 requires specific SDMMC pad programming, and bus power-rail bringup.
diff --git a/board/nvidia/cardhu/cardhu.c b/board/nvidia/cardhu/cardhu.c
+/*
+ * Do I2C/PMU writes to bring up SD card bus power
+ *
+ */
+void board_sdmmc_voltage_init(void)
We really shouldn't be adding to board files if we're remotely serious
about device tree; the whole point of DT is to remove code from the
board files, and describe the desired configuration as data in DT instead.
This function should be replaced by regulator nodes/properties in the
device tree, and the MMC (core?) driver calling into the board-specific
regulator driver to request the desired voltages.
But so long as we file a bug to replace this code with an explicit
regulator driver in the future, I guess it's fine for now.
I'll file a bug for doing all PMU/power rail work from DT. I think it
makes much more sense as a separate (non-MMC) patch.
+{
+ uchar reg, data_buffer[1];
+ int i;
+
+ i2c_set_bus_num(0); /* PMU is on bus 0 */
+
+ data_buffer[0] = 0x65;
+ reg = 0x32;
We should at least comment what those register numbers and values mean.
Unfortunately, that's not documented in any downstream/NV-generated
code that I've seen. I'll have to find the PMU spec and decode what
these writes are doing.
BTW, I just noticed that commit f01b631 Tegra30: Add/enable Cardhu
build (T30 reference board) adds a file called
board/nvidia/cardhu/cardhu.c.mmc. That's a mistake, right?
Yep, that's the Cardhu file I was hacking on for MMC support way back
when. I can remove it in V2 of these patches, or would you prefer a
single, separate patch to do that?
diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c
Hmm. This seems like SoC code, not board code...
+void pad_init_mmc(struct tegra_mmc *reg)
+{
+#if defined(CONFIG_TEGRA30)
+ /* Set the pad drive strength for SDMMC1 or 3 only */
+ if (offset != TEGRA_SDMMC1_BASE offset != TEGRA_SDMMC3_BASE) {
+ debug(%s: settings are only valid for SDMMC1/SDMMC3!\n,
+ __func__);
+ return;
+ }
Perhaps pass in the MMC instance ID instead of the base address. That'd
avoid having to know the base addresses in this code.
I still need to know if I've got a SDIO or eMMC ID, though, and I
don't think the flags for that in the mmc/host structs (mmc-version,
etc.) get populated until the mmc driver has done some I/O with the
device (eMMC or SD-card), and I need to set up the pads before that.
In fact, just putting this code into the pinmux driver (which owns these
registers) seems like a better idea; there's no need to only do this
when the SD controller is enabled, is there?
Half of these regs are in the SD controller register space
(sdmemcmpctl and autocalcfg), and get reset when the controller gets
reset (mmc_reset). So they need to be set each time a reset occurs. It
makes sense to keep the GP SDIOCFG writes here, too.
As to where the pad_init_mmc function belongs, it is SoC-specific,
yes. T20 doesn't need it (no sdmemcmpctl or autocalcfg regs on T20
SDMMC), and T30 and T114 use slightly different bits/values for GP
SDIOCFG and sdmemcmpctl/autocalcfg. But the differences are small
enough that I thought this routine should be placed in a common area,
and not duplicated for each SoC, so I put it here.
Do you have a suggestion of where it would be better placed?
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] nand: Extend nand_(read|write)_skip_bad with *actual and limit parameters
On 02/27/2013 10:49:55 AM, Tom Rini wrote:
On Tue, Feb 26, 2013 at 10:56:08AM -0500, Tom Rini wrote:
We make these two functions take a size_t pointer to how much space
was used on NAND to read or write the buffer (when reads/writes
happen)
so that bad blocks can be accounted for. We also make them take an
loff_t limit on how much data can be read or written. This means
that
we can now catch the case of when writing to a partition would
exceed
the partition size due to bad blocks. To do this we also need to
make
[snip]
int nand_read_skip_bad(nand_info_t *nand, loff_t offset, size_t
*length,
- u_char *buffer)
+ size_t *actual, loff_t lim, u_char *buffer)
[snip]
+ if (*actual lim) {
+ puts(Size of read exceeds partition or device
limit\n);
+ *length = 0;
+ return -EFBIG;
+ }
The more I look at this and try testing things, I think I shouldn't be
introducing a change here. Before you could do:
nand read ${address} partname-with-badblock
And it would suceed but bleed into the next partition if it wasn't the
last one. So your production system could do nand read ${address}
kernel and be OK. But with this change, it would fail because
reading
the whole partition is now too large with a bad block (you would need
partition+(blocksize*number bad blocks).
You wouldn't be quite so OK if it were a write instead.
So I'm going to put this back to a check simply against requested size
being greater than lim rather than required size greater than lim
(since
required size exceeds device is still caught).
No, please retain the check. The other issue is a separate (though
related) bug, and there's a patch from Harvey Chapman to deal with it.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] nand: Extend nand_(read|write)_skip_bad with *actual and limit parameters
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/27/2013 12:09 PM, Scott Wood wrote:
On 02/27/2013 10:49:55 AM, Tom Rini wrote:
On Tue, Feb 26, 2013 at 10:56:08AM -0500, Tom Rini wrote:
We make these two functions take a size_t pointer to how much
space was used on NAND to read or write the buffer (when
reads/writes happen) so that bad blocks can be accounted for.
We also make them take an loff_t limit on how much data can be
read or written. This means that we can now catch the case of
when writing to a partition would exceed the partition size due
to bad blocks. To do this we also need to make
[snip]
int nand_read_skip_bad(nand_info_t *nand, loff_t offset,
size_t
*length,
- u_char *buffer) + size_t *actual,
loff_t lim, u_char *buffer)
[snip]
+if (*actual lim) { +puts(Size of read exceeds
partition or device limit\n); +*length = 0; +
return -EFBIG; +}
The more I look at this and try testing things, I think I
shouldn't be introducing a change here. Before you could do:
nand read ${address} partname-with-badblock
And it would suceed but bleed into the next partition if it
wasn't the last one. So your production system could do nand
read ${address} kernel and be OK. But with this change, it
would fail because reading the whole partition is now too large
with a bad block (you would need partition+(blocksize*number bad
blocks).
You wouldn't be quite so OK if it were a write instead.
Correct. But the check is now inside of nand_(read|write)_skip_bad.
So the write case will fail (without trying to write), but the read
case should not.
So I'm going to put this back to a check simply against requested
size being greater than lim rather than required size greater
than lim (since required size exceeds device is still caught).
No, please retain the check. The other issue is a separate
(though related) bug, and there's a patch from Harvey Chapman to
deal with it.
I could be missing something, but I'm not sure how to otherwise adjust
things here. With all of the checking moved to nand_util.c and
check_skip_len not knowing if we're a read or write it can only say
fits using X or exceeds device, then it's up to the caller to
decide the next action.
- --
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRLj+TAAoJENk4IS6UOR1WJAAP/RLxsGHN4HqoEC0zfe2eIDZe
ZJU+sevT/murom6fNOfKFuC8pwPavy64FGdXNspwdpJCRTcXIs503k4x4ZMy9USC
HszV9NKF42HyscQi3RmBqlIUb9WQ6UikMZEUpteO0ZGQajRKho3nL3M1qjQsASG9
745qrmJijQEjEu3MsnfEZYEzyliVCpHHiIylhBALizwpjEwzKwlebe/ZrmbTPYO6
QXyfHLd+/5iNUJEjXOaXP/z7gXU+85m2uwxRhyLB1PmULGkmh7A+cvByTPt8TcxK
HTWnL3at4S+OvWqlnYTdTYbsCBUQ3jp/wnLF39vq9E5VIPv7UshwPponeNbFEGzt
GOZP1fIGMWcSFJHd3usR7wkhA5tJZu9329Av283ckwIbSlwz/tOP/efwFF/Zsrc5
oLn4ezRrA+RSKCtCujYJPhnAyEJEkncvpA4Imx6R9v9LZlXu3z8w5AQKcuAlsrxm
FDcjtcAA6y804I2jGPvL9laoCy9li1SVMHbd71zVtRwRJBMYUMfw7aI6uUwBslLJ
4GlnVKKsfEAkEb7APZ5v5YJrwD+mgSJ4TR1fwtoirbQKpG3OrMnXNhzZSBD5UFv6
DUxhMRL+EOawFJIl5AUPHHB7LdvV4qtDwee1bPg31ZXetnimQGLHn8qzppioMIvC
suvFme3/03ZGTDFwUUjp
=My8j
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] mtd: nand: mxc_nand: Fix is_16bit_nand()
Hi Benoît and Fabio, Le Wed, 27 Feb 2013 14:40:51 +0100 (CET), Benoît Thébaudeau benoit.thebaud...@advansee.com a écrit : On Wednesday, February 27, 2013 2:15:21 PM, Eric Bénard wrote: Hi Benoît, Le Wed, 27 Feb 2013 13:53:10 +0100 (CET), Benoît Thébaudeau benoit.thebaud...@advansee.com a écrit : This code is not used for NAND boot, for which the SPL version of this driver and CONFIG_SYS_NAND_BUSWIDTH_16 are used. I didn't follow SPL migration (I have to come back to it so the next question may be stupid sorry in advance) but once u-boot is running isn't it using the standard driver and no more the SPL one ? Yes, that's correct (unless you need to access NAND only from SPL). But if any board booting from NAND had a 16-bit NAND, CONFIG_SYS_NAND_BUSWIDTH_16 would have to be defined, which no board does, so none of these boards needs CONFIG_SYS_NAND_BUSWIDTH_16BIT either. And the rest of the explanation is what Fabio has just said. thanks to both of you for the details. Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] nand: Extend nand_(read|write)_skip_bad with *actual and limit parameters
On Wed, Feb 27, 2013 at 12:17:07PM -0500, Tom Rini wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/27/2013 12:09 PM, Scott Wood wrote:
On 02/27/2013 10:49:55 AM, Tom Rini wrote:
On Tue, Feb 26, 2013 at 10:56:08AM -0500, Tom Rini wrote:
We make these two functions take a size_t pointer to how much
space was used on NAND to read or write the buffer (when
reads/writes happen) so that bad blocks can be accounted for.
We also make them take an loff_t limit on how much data can be
read or written. This means that we can now catch the case of
when writing to a partition would exceed the partition size due
to bad blocks. To do this we also need to make
[snip]
int nand_read_skip_bad(nand_info_t *nand, loff_t offset,
size_t
*length,
- u_char *buffer) + size_t *actual,
loff_t lim, u_char *buffer)
[snip]
+if (*actual lim) { +puts(Size of read exceeds
partition or device limit\n); +*length = 0; +
return -EFBIG; +}
The more I look at this and try testing things, I think I
shouldn't be introducing a change here. Before you could do:
nand read ${address} partname-with-badblock
And it would suceed but bleed into the next partition if it
wasn't the last one. So your production system could do nand
read ${address} kernel and be OK. But with this change, it
would fail because reading the whole partition is now too large
with a bad block (you would need partition+(blocksize*number bad
blocks).
You wouldn't be quite so OK if it were a write instead.
Correct. But the check is now inside of nand_(read|write)_skip_bad.
So the write case will fail (without trying to write), but the read
case should not.
So I'm going to put this back to a check simply against requested
size being greater than lim rather than required size greater
than lim (since required size exceeds device is still caught).
No, please retain the check. The other issue is a separate
(though related) bug, and there's a patch from Harvey Chapman to
deal with it.
I could be missing something, but I'm not sure how to otherwise adjust
things here. With all of the checking moved to nand_util.c and
check_skip_len not knowing if we're a read or write it can only say
fits using X or exceeds device, then it's up to the caller to
decide the next action.
OK, I see it now. Yes, I think they should be able to live together
nicely.
--
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 1/4] common: imx: Implement generic u-boot.nand target
On Tue, Feb 26, 2013 at 12:33:52PM +0100, Beno??t Th??baudeau wrote: On Tuesday, February 26, 2013 8:19:42 AM, Marek Vasut wrote: Dear Beno??t Th??baudeau, Dear Scott Wood, On Tuesday, February 26, 2013 12:07:25 AM, Scott Wood wrote: On 02/25/2013 05:03:30 PM, Marek Vasut wrote: Dear Scott Wood, So maybe we need a more general (but optional) CONFIG_BUILD_TARGET. Can you elaborate? Same as CONFIG_SPL_TARGET, but not SPL-specific. Basically a way for a board config file to add to $(ALL-y). So each one would set the appropriate CONFIG_BUILD_TARGET for whatever needs to get built, and then something like CONFIG_NAND_IMAGE could hold the image name that should be linked to produce a standard u-boot-nand.bin output. Yea, sounds reasonable. But why call it CONFIG_ , it can't be stored in the board.h files, it has to be somewhere in the Makefile hierarchy. Why can't it go in the board.h files? We could do all that, but should we? As I said to Marek, I think that it's a big mistake to omit the SPL here. The only other solution to get a reliable boot would be the DBBT, but it's very hard to use in real life, away from a production line. The SPL is really easy to enable here, and it's only a matter of time before someone gets bitten by this lack of reliability, so why not just do things right? The boot time and footprint of an SPL would really be negligible, and it's not because other implementations omit both SPL and a valid DBBT that U-Boot should do the same. I'm not against SPL, but then we're starting to drift away from the whole idea of generating u-boot-nand.bin or similar image. Being able to generate u-boot- nand.bin or u-boot-sd.bin etc ... on a per-CPU basis (since this is CPU specific) is the ultimate goal here, whatever is embedded in the image. OK, I didn't know that this was your goal here. If the contents of the image do not matter, then my u-boot-with-nand-spl.imx could be renamed into your u-boot-nand.bin with the appropriate FCB header, and CONFIG_SPL_TARGET could be changed to something more generic as Scott explained. I wonder how the rules start looking. In the end, some way to say Here is the image to write to NAND, called u-boot-nand.bin which will have whatever board needs (say spl/u-boot-spl.bin + some header attached followed by pad, followed by u-boot.img). And also allow for u-boot-nand.bin to be what someone else needs (say a different header on u-boot-spl.bin), etc. -- 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 1/4] sf: Add extended address register writing support
Hi Thomas,
-Original Message-
From: Langer Thomas (LQDE RD ST PON SW)
[mailto:thomas.lan...@lantiq.com]
Sent: 24 February 2013 21:21
To: Jagannadha Sutradharudu Teki; u-boot@lists.denx.de
Cc: mic...@theia.denx.de; Jagannadha Sutradharudu Teki
Subject: AW: [U-Boot] [PATCH 1/4] sf: Add extended address register writing
support
Hello Jagan,
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 00aece9..232ccc0 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -269,6 +269,47 @@ int spi_flash_cmd_write_status(struct spi_flash
*flash, u8 sr)
return 0;
}
+int spi_flash_cmd_extaddr_write(struct spi_flash *flash, u8 ear) {
+ u8 cmd;
+ u8 idcode0;
+ int ret;
+
+ ret = spi_flash_cmd(flash-spi, CMD_READ_ID, idcode0, 1);
+ if (ret) {
+ debug(SF: fail to read read id\n);
+ return ret;
+ }
Instead of reading the id each time this function is executed, it should be
decided during flash probing, if the feature is available and calling this
functions should be done only then.
Means you wanted to store the idcode0 on to spi_flash structure during flash
probe time,
So that based on idcode0 we can assign the command..is it?
+
+ if (idcode0 == 0x01)
+ cmd = CMD_EXT_BRWR;
+ else {
+ printf(SF: unable to support extaddr reg write
+for %s flash\n, flash-name);
This error will be hit every time for non-Spansion flashes, after you add the
calls in patch 3/4 unconditionally!
The main reason for adding this print is currently I am adding support for
winbond, spansion and
numonyx flashes, if any flash vendor other than these are using this support
they should add the
respective command. so they may come to know from this print.
I didn't see any other flashes currently have 16MB sizes in the
drivers/mtd/spi/ other than these.
Was my thinking valid..?
Thanks,
Jagan.
+ return -1;
+ }
+
+ ret = spi_flash_cmd_write_enable(flash);
+ if (ret 0) {
+ debug(SF: enabling write failed\n);
+ return ret;
+ }
+
+ ret = spi_flash_cmd_write(flash-spi, cmd, 1, ear, 1);
+ if (ret) {
+ debug(SF: fail to write ext addr register\n);
+ return ret;
+ }
+
+ ret = spi_flash_cmd_wait_ready(flash, SPI_FLASH_PROG_TIMEOUT);
+ if (ret 0) {
+ debug(SF: write config register timed out\n);
+ return ret;
+ }
+
+ return 0;
+}
+
/*
* The following table holds all device probe functions
*
diff --git a/drivers/mtd/spi/spi_flash_internal.h
b/drivers/mtd/spi/spi_flash_internal.h
index 141cfa8..dbceb81 100644
--- a/drivers/mtd/spi/spi_flash_internal.h
+++ b/drivers/mtd/spi/spi_flash_internal.h
@@ -28,6 +28,9 @@
#define CMD_ERASE_64K 0xd8
#define CMD_ERASE_CHIP0xc7
+/* Extended addr acess commands */
+#define CMD_EXT_BRWR 0x17
Please comment, that this is the Spansion-only code.
+
/* Common status */
#define STATUS_WIP0x01
@@ -77,6 +80,9 @@ static inline int spi_flash_cmd_write_disable(struct
spi_flash *flash)
/* Program the status register. */
int spi_flash_cmd_write_status(struct spi_flash *flash, u8 sr);
+/* Program the extended address register */ int
+spi_flash_cmd_extaddr_write(struct spi_flash *flash, u8 ear);
+
/*
* Same as spi_flash_cmd_read() except it also claims/releases the SPI
* bus. Used as common part of the -read() operation.
Best Regards,
Thomas
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] sf: Add extended address access support
-Original Message-
From: Langer Thomas (LQDE RD ST PON SW)
[mailto:thomas.lan...@lantiq.com]
Sent: 24 February 2013 21:21
To: Jagannadha Sutradharudu Teki; u-boot@lists.denx.de
Cc: mic...@theia.denx.de; Jagannadha Sutradharudu Teki
Subject: AW: [U-Boot] [PATCH 3/4] sf: Add extended address access support
Hello Jagan,
Am 23.02.2013 12:39, schrieb Jagannadha Sutradharudu Teki:
This patch provides support to access an extended addressing in 3-byte
address mode.
The current implementation in spi_flash supports 3-byte address mode
due to this up to 16MB amount of flash is able to access for those
flashes which has an actual size of 16MB.
extended/bank address register contains an information to access the
4th byte addressing hence the flashes which has 16MB can be accessible.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
drivers/mtd/spi/spi_flash.c | 81
++
drivers/mtd/spi/spi_flash_internal.h |8 +++
2 files changed, 89 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index c168c1c..16e5f59 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -23,6 +23,30 @@ static void spi_flash_addr(u32 addr, u8 *cmd)
cmd[3] = addr 0;
}
+static int spi_flash_check_extaddr_access(struct spi_flash *flash,
+u32 *offset) {
+ int ret;
+
+ if (*offset = 0x100) {
+ ret = spi_flash_extaddr_access(flash,
STATUS_EXTADDR_ENABLE);
Restricting this to a single bit here would give the next size limit at 32M.
Please make it future-prov as much as possible: Why not directly use the
upper byte of the offset as parameter?
I didn't get you clearly, can you please elaborate.
+ if (ret) {
+ debug(SF: fail to %s ext addr bit\n,
+ STATUS_EXTADDR_ENABLE ? set : reset);
+ return ret;
+ }
+ *offset -= 0x100;
Are you sure that manipulating the value of the caller has no side-effect?
Is it even necessary, if the callers only do 3-byte-addressing and probably
ignore the upper byte?
May be you are not getting my exact code context.
From the current implementation on spi, we have 3-byte addressing means we are
able to access
only up to 16MB-- means 0 to 0x FF
If the flash has 32MB, if the user is giving an offset 0x100 it will again
pointing to 0x0.
Because we have 3-byte addressing able to access only first 16MB of flash but
the actual flash size is 32MB.
So, from my implementation if user is giving an offset of 0x100 then we
have enable the bank register
for pointing to second 16MB area on 32 MB flash and we must subtract the offset
from 16MB as we are using 3-byte
addressing. Means we are accessing 4-byte addressing in 3-byte address mode. Ie
is the reason I am subtracting it from16MB.
Please comment and let me know if you're not clear.
+ } else {
+ ret = spi_flash_extaddr_access(flash,
STATUS_EXTADDR_DISABLE);
+ if (ret) {
+ debug(SF: fail to %s ext addr bit\n,
+ STATUS_EXTADDR_DISABLE ? set : reset);
+ return ret;
+ }
+ }
+
+ return ret;
+}
+
static int spi_flash_read_write(struct spi_slave *spi,
const u8 *cmd, size_t cmd_len,
const u8 *data_out, u8 *data_in, @@ -73,6
+97,14 @@ int
spi_flash_cmd_write_multi(struct spi_flash *flash, u32 offset,
int ret;
u8 cmd[4];
+ if (flash-size 0x100) {
As already said in my comments to patch 1/4, this check (and the check for
manufacturer ID) should be done only once once during probing of the flash.
Then, if necessary, adapted functions for read, write and erase should be
assigned to the function-pointers.
Or use an additional function-pointer, which can be set to this or a similar
function.
Then the call of this function should be included in the loops, which all
these
functions have.
Otherwise, as with your current code, you have a problem if the current
accessed block crosses the boundary at 16M. Have you ever tried this?
Means this check should be in probe call, by adding one member in spi_flash
structure, is it?.
I am not understanding extra function pointers concept, will you please explain.
+ ret = spi_flash_check_extaddr_access(flash, offset);
+ if (ret) {
+ debug(SF: fail to acess ext_addr\n);
+ return ret;
+ }
+ }
+
page_size = flash-page_size;
page_addr = offset / page_size;
byte_addr = offset % page_size;
@@ -139,6 +171,15 @@ int spi_flash_cmd_read_fast(struct spi_flash
*flash, u32 offset,
size_t len, void *data)
{
u8 cmd[5];
+ int ret;
+
+ if
Re: [U-Boot] [PATCH v2] Tegra114: fdt: Sync DT nodes with kernel DT files (GPIO, tegra_car)
On 02/27/2013 08:52 AM, Tom Warren wrote: Minor edit to tegra_car node, add gpio node. Reviewed-by: Stephen Warren swar...@nvidia.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] Tegra30: fdt: Add SDMMC (sdhci) nodes for T30 boards (Cardhu for now)
On 02/27/2013 09:20 AM, Tom Warren wrote:
Stephen/Rhyland,
On Tue, Feb 26, 2013 at 4:10 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 02/26/2013 01:46 PM, Tom Warren wrote:
Took these values directly from the kernel dts files.
diff --git a/arch/arm/dts/tegra30.dtsi b/arch/arm/dts/tegra30.dtsi
+ sdhci@7800 {
+ compatible = nvidia,tegra30-sdhci, nvidia,tegra20-sdhci;
Looking at this more, I /think/ this should only include the Tegra30
compatible value, since there are new quirks that are required to be
enabled on Tegra30 relative to Tegra20 or the HW won't work. The kernel
DT file is no doubt buggy here.
Looking at the SDMMC reg space in the T20 and T30 TRMs, I don't see
anything major that would make the MMC driver not work on T30 as is
(in fact, I know it works just fine w/o modification). Looking at the
sdhci-tegra.c driver source, the only quirk difference is
DATA_TIMEOUT_USES_SDCLK. The U-Boot Tegra MMC driver doesn't reference
the caps Timeout Clock Frequency bits, so this quirk/difference
doesn't matter.
The compatible value does not document whether the U-Boot driver will
operate on the HW without changes, but rather whether there are
incompatible HW changes.
Now, those changes might only affect some theoretical driver that
doesn't actually exist. However, that is not relevant; compatible is
purely about describing HW compatibility or not.
I'll note that both the current upstream U-Boot MMC driver and likely
the current upstream Linux kernel MMC driver probably don't take
advantage of many of the performance or power-saving features present in
the HW, so it's likely pretty easy for their to be a HW difference that
could affect a driver, but not actually yet affect either of these two
particular drivers.
In particular, the difference in DATA_TIMEOUT_USES_SDCLK would probably
be enough on its own to merit not marking Tegra30 as
backwards-compatible with Tegra20, since it's a bug WAR or issue that a
Tegra30 driver apparently would need to be aware of but not a Tegra20
driver (if that feature is used by the driver).
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] sf: Accessing 16MBytes flashes in existing 3-byte addr mode.
Hi Thomas, -Original Message- From: Langer Thomas (LQDE RD ST PON SW) [mailto:thomas.lan...@lantiq.com] Sent: 24 February 2013 21:21 To: Jagannadha Sutradharudu Teki; u-boot@lists.denx.de Cc: mic...@theia.denx.de; Jagannadha Sutradharudu Teki Subject: AW: [U-Boot] [PATCH 0/4] sf: Accessing 16MBytes flashes in existing 3-byte addr mode. Hello Jagan, thanks for your contribution. As there is currently no explicit custodian for sf, I would like to give some comments to your code. Am 23.02.2013 12:38, schrieb Jagannadha Sutradharudu Teki: The current implementation in spi_flash supports 3-byte address mode due to this up to 16MB amount of flash is able to access for those flashes which has an actual size of 16MB. List of flashes: S25FL256S N25Q256 N25Q256A W25Q256(not yet mainlined) extended/bank address register contains an information to access the 4th byte addressing hence the flashes which has 16MB can be accessible. I don't see a config option described here (and also don't find it in the patches). Please keep in mind that the code size for existing boards should not increase! See http://www.denx.de/wiki/U-Boot/DesignPrinciples , points 1 and 5 The code might fit for your use-case, but has influence on other boards/systems, and this is not acceptable. Please add a config option for this new code and also use the existing options, like CONFIG_SPI_FLASH_SPANSION, in your code. The main reason for not adding CONFIG macro is like this entire support requires spansion, winbond and numonyx flashes. I As I have added support for spansion, I will send few more patches for winbond and numonyx support as well. Can I send all the patches again including winbond and numonyx support with RESEND as prefix? Is still a config macro required if the code opt for these 3 flashes? Thanks, Jagan. This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] Tegra30: MMC: Add SD bus power-rail and SDMMC pad init routines
On 02/27/2013 09:59 AM, Tom Warren wrote:
Stephen,
On Tue, Feb 26, 2013 at 4:26 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 02/26/2013 01:46 PM, Tom Warren wrote:
T30 requires specific SDMMC pad programming, and bus power-rail bringup.
diff --git a/board/nvidia/cardhu/cardhu.c b/board/nvidia/cardhu/cardhu.c
+/*
+ * Do I2C/PMU writes to bring up SD card bus power
+ *
+ */
+void board_sdmmc_voltage_init(void)
We really shouldn't be adding to board files if we're remotely serious
about device tree; the whole point of DT is to remove code from the
board files, and describe the desired configuration as data in DT instead.
This function should be replaced by regulator nodes/properties in the
device tree, and the MMC (core?) driver calling into the board-specific
regulator driver to request the desired voltages.
But so long as we file a bug to replace this code with an explicit
regulator driver in the future, I guess it's fine for now.
I'll file a bug for doing all PMU/power rail work from DT. I think it
makes much more sense as a separate (non-MMC) patch.
Yes, certainly a separate patch. Ideally it'd be implemented before
other code that relies on it. That's why I think we need to take a
higher-level look at DT support in U-Boot, rather than simply finding
these issue accidentally while implementing the features we already know
we need.
BTW, I just noticed that commit f01b631 Tegra30: Add/enable Cardhu
build (T30 reference board) adds a file called
board/nvidia/cardhu/cardhu.c.mmc. That's a mistake, right?
Yep, that's the Cardhu file I was hacking on for MMC support way back
when. I can remove it in V2 of these patches, or would you prefer a
single, separate patch to do that?
Is the commit that adds that file already pulled into higher-level
repos? If not, I would simply rebase it to remove that file. If it has,
then a separate patch to delete it before this series would make sense.
diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c
Hmm. This seems like SoC code, not board code...
+void pad_init_mmc(struct tegra_mmc *reg)
+{
+#if defined(CONFIG_TEGRA30)
+ /* Set the pad drive strength for SDMMC1 or 3 only */
+ if (offset != TEGRA_SDMMC1_BASE offset != TEGRA_SDMMC3_BASE) {
+ debug(%s: settings are only valid for SDMMC1/SDMMC3!\n,
+ __func__);
+ return;
+ }
Perhaps pass in the MMC instance ID instead of the base address. That'd
avoid having to know the base addresses in this code.
I still need to know if I've got a SDIO or eMMC ID, though, and I
don't think the flags for that in the mmc/host structs (mmc-version,
etc.) get populated until the mmc driver has done some I/O with the
device (eMMC or SD-card), and I need to set up the pads before that.
In fact, just putting this code into the pinmux driver (which owns these
registers) seems like a better idea; there's no need to only do this
when the SD controller is enabled, is there?
Half of these regs are in the SD controller register space
(sdmemcmpctl and autocalcfg), and get reset when the controller gets
reset (mmc_reset). So they need to be set each time a reset occurs. It
makes sense to keep the GP SDIOCFG writes here, too.
As to where the pad_init_mmc function belongs, it is SoC-specific,
yes. T20 doesn't need it (no sdmemcmpctl or autocalcfg regs on T20
SDMMC), and T30 and T114 use slightly different bits/values for GP
SDIOCFG and sdmemcmpctl/autocalcfg. But the differences are small
enough that I thought this routine should be placed in a common area,
and not duplicated for each SoC, so I put it here.
Do you have a suggestion of where it would be better placed?
For the pinmux registers, I think they should be programmed by the
pinmux driver at the same time as the rest of the pinmux is programmed.
For the SD registers, I guess we need to program them from the SD driver
as you say, but need to add some more properties to the DT in order to
parameterize this.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] common/main: move set_working_fdt_addr to enable usage of $fdtaddr
When using $fdtaddr in $bootcmd and $bootcmd is automatically called, $fdtaddr is yet not defined. Signed-off-by: Barak Wasserstrom wba...@gmail.com --- common/main.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/common/main.c b/common/main.c index e2d2e09..77b9076 100644 --- a/common/main.c +++ b/common/main.c @@ -378,6 +378,10 @@ void main_loop (void) bootstage_mark_name(BOOTSTAGE_ID_MAIN_LOOP, main_loop); +#if defined CONFIG_OF_CONTROL + set_working_fdt_addr((void *)gd-fdt_blob); +#endif /* CONFIG_OF_CONTROL */ + #ifdef CONFIG_BOOTCOUNT_LIMIT bootcount = bootcount_load(); bootcount++; @@ -500,10 +504,6 @@ 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.11.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 V2] EXYNOS5: Add initial DTS file for Snow.
Hi Rajeshwari,
On Wed, Feb 20, 2013 at 10:43 PM, Rajeshwari Shinde
rajeshwar...@samsung.com wrote:
This patch adds the DTS file for Snow Board.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes in V2:
- None
board/samsung/dts/exynos5250-snow.dts | 69
+
1 files changed, 69 insertions(+), 0 deletions(-)
create mode 100644 board/samsung/dts/exynos5250-snow.dts
diff --git a/board/samsung/dts/exynos5250-snow.dts
b/board/samsung/dts/exynos5250-snow.dts
new file mode 100644
index 000..360d3bd
--- /dev/null
+++ b/board/samsung/dts/exynos5250-snow.dts
@@ -0,0 +1,69 @@
+/*
+ * SAMSUNG Snow board device tree source
+ *
+ * Copyright (c) 2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/dts-v1/;
+/include/ ARCH_CPU_DTS
+
+/ {
+ model = Google Snow;
+ compatible = google,snow, samsung,exynos5250;
+
+ aliases {
+ i2c0 = /i2c@12c6;
+ i2c1 = /i2c@12c7;
+ i2c2 = /i2c@12c8;
+ i2c3 = /i2c@12c9;
+ i2c4 = /i2c@12ca;
+ i2c5 = /i2c@12cb;
+ i2c6 = /i2c@12cc;
+ i2c7 = /i2c@12cd;
+ spi0 = /spi@12d2;
+ spi1 = /spi@12d3;
+ spi2 = /spi@12d4;
+ spi3 = /spi@131a;
+ spi4 = /spi@131b;
+ };
+
+ sromc@1225 {
+ bank = 1;
+ srom-timing = 1 9 12 1 6 1 1;
+ width = 2;
+ lan@500 {
+ compatible = smsc,lan9215, smsc,lan;
+ reg = 0x500 0x100;
+ phy-mode = mii;
+ };
+ };
I don't think snow has Ethernet.
+
+ sound@12d6 {
+ samsung,i2s-epll-clock-frequency = 19200;
+ samsung,i2s-sampling-rate = 48000;
+ samsung,i2s-bits-per-sample = 16;
+ samsung,i2s-channels = 2;
+ samsung,i2s-lr-clk-framesize = 256;
+ samsung,i2s-bit-clk-framesize = 32;
+ samsung,codec-type = max98095;
+ };
+
+ i2c@12cd {
+ soundcodec@22 {
+ reg = 0x22;
+ compatible = maxim,max98095-codec;
+ };
+ };
+
+ i2c@12c6 {
+ pmic@9 {
+ reg = 0x9;
+ compatible = maxim,max77686_pmic;
+ };
+ };
+};
--
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 0/2] Protect splashimage from improperly aligned addresses
On Sun, Feb 24, 2013 at 06:19:21PM +0200, Nikita Kiryanov wrote: As discussed in the links below, one needs to be careful about choosing an address for a splash image BMP file when working on architectures that can't handle unaligned memory accesses. A bad address may lead to a bricked board, and the safe addresses are not obvious due to the internal structure of BMP files. This patchset documents the problem and implements an optional callback that prevents the environment variable from being set to a bad value. Finally, it turns this protection on for cm_t35. http://lists.denx.de/pipermail/u-boot/2013-January/144666.html http://lists.denx.de/pipermail/u-boot/2013-February/146021.html Nikita Kiryanov (2): lcd: implement a callback for splashimage cm_t35: prevent splashimage from being set to a bad value To be clear, this series is the only part required of all of the various ones that have been posted about splash images? Or are others still needed here. 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] CONFIG_BOOTDELAY default should not affect runtime
Hi Tom, On Mon, Feb 18, 2013 at 11:20 AM, Tom Rini tr...@ti.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/09/2013 11:21 AM, Otavio Salvador wrote: Hello Wolfgang, On Sat, Feb 9, 2013 at 4:54 AM, Wolfgang Denk w...@denx.de wrote: Dear Joe Hershberger, In message 1360355280-1197-1-git-send-email-joe.hershber...@ni.com you wrote: Because the code that handles bootdelay is compiled in conditionally based on the default value, you are restricted in the default, regardless of what you want the runtime options to be. Change the source to always check if any default is given so that other values can be selected and used at runtime. Signed-off-by: Joe Hershberger joe.hershber...@ni.com --- common/main.c | 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/common/main.c b/common/main.c index e2d2e09..0973c59 100644 --- a/common/main.c +++ b/common/main.c @@ -95,7 +95,7 @@ extern void mdm_init(void); /* defined in board.c */ * Watch for 'delay' seconds for autoboot stop or autoboot delay string. * returns: 0 - no key string, allow autoboot 1 - got key string, abort */ -#if defined(CONFIG_BOOTDELAY) (CONFIG_BOOTDELAY = 0) +#if defined(CONFIG_BOOTDELAY) Careful!! This is probably changing behaviour of a number of boards significantly. we have to check if we really want this, and if yes, we have to announce it and provide a grace period (eventually using doc/feature-removal-schedule.txt ?) It seems the CONFIG_BOOTDELAY as 0 is not very common: ~/hacking/u-boot% git grep CONFIG_BOOTDELAY | egrep 'BOOTDELAY\s* \-[0-9]' include/configs/RPXsuper.h:#define CONFIG_BOOTDELAY -1 include/configs/ep8260.h:#define CONFIG_BOOTDELAY-1 include/configs/espt.h:#define CONFIG_BOOTDELAY-1 include/configs/scb9328.h:#define CONFIG_BOOTDELAY -1 include/configs/sh7763rdp.h:#define CONFIG_BOOTDELAY-1 I count 49 boards with git grep -E 'CONFIG_BOOTDELAY[[:blank:]]+-[0-9]' so it's not _that_ uncommon. So maybe those could have CONFIG_BOOTDELAY undefined keeping them working as before? The problem is that as I read the README, we document CONFIG_BOOTDELAY as having a valid value range of from -2 to sane positive value. So yes, if we want to change this we need to (a) change the README too and (b) give some sort of heads-up. Off the top of my head, we could change to: CONFIG_AUTOBOOT_DISABLED and CONFIG_FORCE_AUTOBOOT_NO_DELAY and update doc/README.autoboot as well and add some sanity #warning checks for a release or two in some common generated config related file or something like that. The change has no effect on the behavior, it simply changes what is compiled in. If the default value is not changed, then the behavior is unchanged. The only impact this may have on existing boards is to make the code size slightly larger. If that is an issue for some reason, then CONFIG_BOOTDELAY can be undefined. If we want to add other config options, that's fine, but that's more involved that I was hoping for. Thanks, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Allow u-boot to be silent without forcing Linux to be
That's a bit presumptuous of you, u-boot!
Signed-off-by: Joe Hershberger joe.hershber...@ni.com
---
Changes in v2:
- Added info about the change to README.silent
common/cmd_bootm.c | 8
doc/README.silent | 4 +++-
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 7ae5d5b..435c980 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -83,7 +83,7 @@ extern flash_info_t flash_info[]; /* info for FLASH chips */
static int do_imls(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]);
#endif
-#ifdef CONFIG_SILENT_CONSOLE
+#if defined(CONFIG_SILENT_CONSOLE) !defined(CONFIG_SILENT_U_BOOT_ONLY)
static void fixup_silent_linux(void);
#endif
@@ -694,7 +694,7 @@ int do_bootm(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
bootstage_mark(BOOTSTAGE_ID_CHECK_BOOT_OS);
-#ifdef CONFIG_SILENT_CONSOLE
+#if defined(CONFIG_SILENT_CONSOLE) !defined(CONFIG_SILENT_U_BOOT_ONLY)
if (images.os.os == IH_OS_LINUX)
fixup_silent_linux();
#endif
@@ -1258,7 +1258,7 @@ U_BOOT_CMD(
/***/
/* helper routines */
/***/
-#ifdef CONFIG_SILENT_CONSOLE
+#if defined(CONFIG_SILENT_CONSOLE) !defined(CONFIG_SILENT_U_BOOT_ONLY)
static void fixup_silent_linux(void)
{
char buf[256], *start, *end;
@@ -1651,7 +1651,7 @@ static int do_bootz(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
usb_stop();
#endif
-#ifdef CONFIG_SILENT_CONSOLE
+#if defined(CONFIG_SILENT_CONSOLE) !defined(CONFIG_SILENT_U_BOOT_ONLY)
fixup_silent_linux();
#endif
arch_preboot_os();
diff --git a/doc/README.silent b/doc/README.silent
index 70202ce..6d90a0e 100644
--- a/doc/README.silent
+++ b/doc/README.silent
@@ -23,4 +23,6 @@ The following actions are taken if silent is set at boot
time:
- When booting a linux kernel, the bootargs are fixed up so that
the argument console= will be in the command line, no matter how
- it was set in bootargs before.
+ it was set in bootargs before. If you don't want the linux command
+ line to be affected, define CONFIG_SILENT_U_BOOT_ONLY in your board
+ config file as well, and this part of the feature will be disabled.
--
1.7.11.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] gen: Add sha256 command
Hi Akshay,
On Wed, Feb 27, 2013 at 7:24 AM, Akshay Saraswat aksha...@samsung.com wrote:
sha256 command is added which can be used to test SHA 256 hash
algorithm.
TEST=sha256 0x40008000 0x2B 0x40009000
Used mm and md to write a standard string to memory location
0x40008000 and ran the above command to verify the output.
Signed-off-by: ARUN MANKUZHI aru...@samsung.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
---
common/Makefile | 1 +
common/cmd_sha256.c | 69
+
2 files changed, 70 insertions(+)
create mode 100644 common/cmd_sha256.c
Rather than adding this command, can you please use 'hash sha256'
instead? This is in common/hash.c.
Regards,
Simon
diff --git a/common/Makefile b/common/Makefile
index 54fcc81..6170ed5 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -201,6 +201,7 @@ COBJS-$(CONFIG_MENU) += menu.o
COBJS-$(CONFIG_MODEM_SUPPORT) += modem.o
COBJS-$(CONFIG_UPDATE_TFTP) += update.o
COBJS-$(CONFIG_USB_KEYBOARD) += usb_kbd.o
+COBJS-$(CONFIG_CMD_SHA256) += cmd_sha256.o
COBJS-$(CONFIG_CMD_DFU) += cmd_dfu.o
COBJS-$(CONFIG_CMD_GPT) += cmd_gpt.o
endif
diff --git a/common/cmd_sha256.c b/common/cmd_sha256.c
new file mode 100644
index 000..e4f6b56
--- /dev/null
+++ b/common/cmd_sha256.c
@@ -0,0 +1,69 @@
+/*
+ * Copyright 2000-2009
+ * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include command.h
+#ifdef CONFIG_EXYNOS_ACE_SHA
+#include asm/arch/ace_sha.h
+#else
+#include sha256.h
+#endif
+
+int do_sha256(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ unsigned long inlen;
+ unsigned char *input, *out;
+ int i;
+#ifndef CONFIG_EXYNOS_ACE_SHA
+ sha256_context sha_cnxt;
+#endif
+ if (argc 4) {
+ printf(usage: sha256 input input length output\n);
+ return 0;
+ }
+ input = (unsigned char *)simple_strtoul(argv[1], NULL, 16);
+ inlen = simple_strtoul(argv[2], NULL, 16);
+ out = (unsigned char *)simple_strtoul(argv[3], NULL, 16);
+
+#ifdef CONFIG_EXYNOS_ACE_SHA
+ ace_sha_hash_digest(out, input, inlen, 2);
+#else
+ sha256_starts(sha_cnxt);
+
+ sha256_update(sha_cnxt, input, inlen);
+
+ sha256_finish(sha_cnxt, out);
+#endif
+
+ for (i = 0; i 32; i++)
+ printf(0x%02X , out[i]);
+ printf(\n);
+
+ return 0;
+}
+
+U_BOOT_CMD(
+ sha256, 4, 1, do_sha256,
+ print hash result,
+ input inputlength output
+);
--
1.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] Exynos: config: Enable ACE HW for SHA 256 for Exynos
Hi Akshay, On Wed, Feb 27, 2013 at 7:24 AM, Akshay Saraswat aksha...@samsung.com wrote: This enables SHA 256 for exynos. TEST=sha256 0x40008000 0x2B 0x40009000 Used mm and md to write a standard string to memory location 0x40008000 and ran the above command to verify the output. Signed-off-by: ARUN MANKUZHI aru...@samsung.com Signed-off-by: Akshay Saraswat aksha...@samsung.com --- include/configs/exynos5250-dt.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h index cabd2f2..3963aaf 100644 --- a/include/configs/exynos5250-dt.h +++ b/include/configs/exynos5250-dt.h @@ -45,6 +45,9 @@ /* Keep L2 Cache Disabled */ #define CONFIG_SYS_DCACHE_OFF +#define CONFIG_CMD_SHA256 This should not be needed, you can use CONFIG_CMD_HASH instead. +#define CONFIG_EXYNOS_ACE_SHA + #define CONFIG_SYS_SDRAM_BASE 0x4000 #define CONFIG_SYS_TEXT_BASE 0x43E0 -- 1.8.0 Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] gen: Add sha256 command
Hi Akshay,
On Wed, Feb 27, 2013 at 12:22 PM, Simon Glass s...@chromium.org wrote:
Hi Akshay,
On Wed, Feb 27, 2013 at 7:24 AM, Akshay Saraswat aksha...@samsung.com wrote:
sha256 command is added which can be used to test SHA 256 hash
algorithm.
TEST=sha256 0x40008000 0x2B 0x40009000
Used mm and md to write a standard string to memory location
0x40008000 and ran the above command to verify the output.
Signed-off-by: ARUN MANKUZHI aru...@samsung.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
---
common/Makefile | 1 +
common/cmd_sha256.c | 69
+
2 files changed, 70 insertions(+)
create mode 100644 common/cmd_sha256.c
Rather than adding this command, can you please use 'hash sha256'
instead? This is in common/hash.c.
And to be a bit more clear, if you plumb in your sha256 implementation
into the list of implementations at the top of hash.c, and put it
earlier than the software implementation, then it will get priority.
Regards,
Simon
Regards,
Simon
diff --git a/common/Makefile b/common/Makefile
index 54fcc81..6170ed5 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -201,6 +201,7 @@ COBJS-$(CONFIG_MENU) += menu.o
COBJS-$(CONFIG_MODEM_SUPPORT) += modem.o
COBJS-$(CONFIG_UPDATE_TFTP) += update.o
COBJS-$(CONFIG_USB_KEYBOARD) += usb_kbd.o
+COBJS-$(CONFIG_CMD_SHA256) += cmd_sha256.o
COBJS-$(CONFIG_CMD_DFU) += cmd_dfu.o
COBJS-$(CONFIG_CMD_GPT) += cmd_gpt.o
endif
diff --git a/common/cmd_sha256.c b/common/cmd_sha256.c
new file mode 100644
index 000..e4f6b56
--- /dev/null
+++ b/common/cmd_sha256.c
@@ -0,0 +1,69 @@
+/*
+ * Copyright 2000-2009
+ * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include command.h
+#ifdef CONFIG_EXYNOS_ACE_SHA
+#include asm/arch/ace_sha.h
+#else
+#include sha256.h
+#endif
+
+int do_sha256(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ unsigned long inlen;
+ unsigned char *input, *out;
+ int i;
+#ifndef CONFIG_EXYNOS_ACE_SHA
+ sha256_context sha_cnxt;
+#endif
+ if (argc 4) {
+ printf(usage: sha256 input input length output\n);
+ return 0;
+ }
+ input = (unsigned char *)simple_strtoul(argv[1], NULL, 16);
+ inlen = simple_strtoul(argv[2], NULL, 16);
+ out = (unsigned char *)simple_strtoul(argv[3], NULL, 16);
+
+#ifdef CONFIG_EXYNOS_ACE_SHA
+ ace_sha_hash_digest(out, input, inlen, 2);
+#else
+ sha256_starts(sha_cnxt);
+
+ sha256_update(sha_cnxt, input, inlen);
+
+ sha256_finish(sha_cnxt, out);
+#endif
+
+ for (i = 0; i 32; i++)
+ printf(0x%02X , out[i]);
+ printf(\n);
+
+ return 0;
+}
+
+U_BOOT_CMD(
+ sha256, 4, 1, do_sha256,
+ print hash result,
+ input inputlength output
+);
--
1.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ARM: tegra: make CONFIG_CMD_PART common
On 02/26/2013 04:00 PM, Stephen Warren wrote: This is useful on all Tegras, so that boot.scr on all devices can use the same commands. Hence, move it to tegra-common.h. Unfortunately, this breaks Tegra114 builds because no partition types are enabled, and CONFIG_CMD_PART requires functionality that's only enabled if some partition types are supported. There are two possible solutions: 1) Conditionally enable PARTITION_UUIDS and CMD_PART in tegra-common-post.h only if some partition type is enabled. 2) Also enable DOS and EFI partitions in tegra-common.h, along with all of FS_EXT4, FS_FAT, CMD_EXT2, CMD_FAT, CMD_FS_GENERIC. For most boards this won't be any change. For the Colibri T20 and Avionic Design boards, this ends up enabling a few more options. (or perhaps enable all of those in tegra-common-post.h only if support for any block device is enabled) I prefer option (2). Does anyone object? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Tegra114: I2C: Take DVFS out of reset to allow I2C5 (PWR_I2C) to work
I2C driver can now probe dev 0 (PWR_I2C, where the PMU, etc. lives). This is needed so that the SDIO slot power can be brought up for the MMC driver, so it has to precede those commits. Signed-off-by: Tom Warren twar...@nvidia.com --- arch/arm/cpu/arm720t/tegra114/cpu.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/cpu/arm720t/tegra114/cpu.c b/arch/arm/cpu/arm720t/tegra114/cpu.c index 5962e15..0b2157a 100644 --- a/arch/arm/cpu/arm720t/tegra114/cpu.c +++ b/arch/arm/cpu/arm720t/tegra114/cpu.c @@ -201,6 +201,7 @@ void t114_init_clocks(void) reset_set_enable(PERIPH_ID_MSELECT, 0); reset_set_enable(PERIPH_ID_EMC1, 0); reset_set_enable(PERIPH_ID_MC1, 0); + reset_set_enable(PERIPH_ID_DVFS, 0); debug(t114_init_clocks exit\n); } -- 1.7.0.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-x86.git
Hi Tom, I have pulled the latest series into a branch in the x86 tree. You can also get it from patchwork. If you are happy with it, please see below. I haven't seen any comments for a few days. The following changes since commit 47104c37de076e2be35ae1b3d144614f4d24a766: MAKEALL: add support for per architecture toolchains (2013-02-20 09:40:34 -0500) are available in the git repository at: git://git.denx.de/u-boot-x86.git mem for you to fetch changes up to dc63c7ccecee7b22fdc06f2c9d62d53bd5511b00: hash: Use lower case for hash algorithm names (2013-02-27 13:13:16 -0800) Allen Martin (1): sandbox: fix compiler warning Simon Glass (21): Tidy up error checking and fix bug in hash command Update print_buffer() to use const sandbox: Add un/map_sysmen() to deal with sandbox's ram_buf sandbox: Change memory commands to use map_physmem Split out the memory tests into separate functions Use common mtest iteration counting Fix mtest indenting Bring mtest putc() into common code Reduce casting in mtest Update set_working_fdt_addr() to use setenv_addr() common: Use new numeric setenv functions fs: Use new numeric setenv functions net: Use new numeric setenv functions image: Use crc header file instead of C prototypes hash: Add a flag to support saving hashes in the environment Roll crc32 into hash infrastructure sandbox: config: Enable hash functions and mtest Move CONFIG_SYS_MEMTEST_SCRATCH #ifdef to top of file sandbox: Update mtest to fix crashes sandbox: Allow hash functions to work correctly hash: Use lower case for hash algorithm names Taylor Hutt (1): sandbox: Improve sandbox serial port keyboard interface README| 9 + arch/sandbox/config.mk| 1 + arch/sandbox/cpu/os.c | 8 + arch/sandbox/cpu/start.c | 3 + arch/sandbox/include/asm/io.h | 10 + common/cmd_bootm.c| 11 +- common/cmd_cbfs.c | 4 +- common/cmd_cramfs.c | 4 +- common/cmd_fdos.c | 4 +- common/cmd_fdt.c | 11 +- common/cmd_hash.c | 14 +- common/cmd_jffs2.c| 4 +- common/cmd_load.c | 12 +- common/cmd_mem.c | 798 +- common/cmd_mtdparts.c | 4 +- common/cmd_nand.c | 12 +- common/cmd_nvedit.c | 11 +- common/cmd_reiser.c | 4 +- common/cmd_setexpr.c | 39 ++- common/cmd_sha1sum.c | 6 +- common/cmd_unzip.c| 4 +- common/cmd_ximg.c | 7 +- common/cmd_zfs.c | 3 +- common/cmd_zip.c | 4 +- common/hash.c | 194 +++--- common/image.c| 4 +- drivers/net/fm/fm.c | 4 +- drivers/serial/sandbox.c | 44 ++- fs/fs.c | 4 +- fs/ubifs/ubifs.c | 4 +- include/common.h | 29 +- include/configs/sandbox.h | 9 +- include/hash.h| 13 +- include/os.h | 10 + include/u-boot/crc.h | 11 + lib/crc32.c | 9 + lib/display_options.c | 3 +- net/net.c | 8 +- 38 files changed, 750 insertions(+), 583 deletions(-) Regards, Simon On Mon, Feb 18, 2013 at 9:22 PM, Simon Glass s...@chromium.org wrote: Hi Tom, On Mon, Feb 18, 2013 at 2:52 PM, Tom Rini tr...@ti.com wrote: On Sun, Feb 17, 2013 at 01:32:58PM -0800, Simon Glass wrote: Hi Wolfgang, On Sun, Feb 17, 2013 at 12:58 PM, Wolfgang Denk w...@denx.de wrote: Dear Simon Glass, In message capnjgz2p6sbdxiwxw2tecdjadmhkn5inbgrpzbtvwmqutyv...@mail.gmail.com you wrote: Hi Tom, This series includes the sandbox map_sysmem() feature, and gets the memory and hashing functions running on sandbox to allow testing/code coverage. I have run it through buildman and it seems clean, with the proviso that I don't have fully-working toolchains for all architectures. NAK. It is not correct to push changes that affect global code through a arch-specific custodian tree, especially if the submitter of the patche(es) is identical to the custodian of the very tree, and even more so if there have been not ANY independent Acked-by: or at least Tested-by: messages. This is NOT how the peer review process is supposed to work!! Especially as a custodian you must not do such things. OK, I was not quite sure what to do, so may have misunderstood Tom's instructions - there is a short thread here http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/153342 I have created a patchwork bundle instead. http://patchwork.ozlabs.org/bundle/sjg/sandbox-mem/ OK, I thought I said, but maybe I didn't, I'm OK with re-using the tree, but _not_
[U-Boot] [PATCH] Fix a couple typoes in tools/env/README
Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca --- diff --git a/tools/env/README b/tools/env/README index df020e4..1020b57 100644 --- a/tools/env/README +++ b/tools/env/README @@ -8,7 +8,7 @@ In order to cross-compile fw_printenv, run in the root directory of the U-Boot distribution. For example, make HOSTCC=arm-linux-gcc env -For the run-time utiltity configuration uncomment the line +For the run-time utility configuration uncomment the line #define CONFIG_FILE /etc/fw_env.config in fw_env.h. @@ -34,7 +34,7 @@ following lines are relevant: #define DEVICE2_ESIZE 0x4000 #define DEVICE2_ENVSECTORS 2 -Un-define HAVE_REDUND, if you want to use the utlities on a system +Un-define HAVE_REDUND, if you want to use the utilities on a system that does not have support for redundant environment enabled. If HAVE_REDUND is undefined, DEVICE2_NAME is ignored, as is ENV2_SIZE and DEVICE2_ESIZE. -- rday Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Tegra114: I2C: Take DVFS out of reset to allow I2C5 (PWR_I2C) to work
On 02/27/2013 02:10 PM, Tom Warren wrote: I2C driver can now probe dev 0 (PWR_I2C, where the PMU, etc. lives). This is needed so that the SDIO slot power can be brought up for the MMC driver, so it has to precede those commits. Reviewed-by: Stephen Warren swar...@nvidia.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mxs: spl_mem_init: Align DDR2 init with FSL bootlets source
From: Fabio Estevam fabio.este...@freescale.com
Currently the following kernel hang happens when loading a 2.6.35 kernel from
Freeescale on a mx28evk board:
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Bus freq driver module loaded
IMX usb wakeup probe
usb h1 wakeup device is registered
mxs_cpu_init: cpufreq init finished
...
Loading the same kernel using the bootlets from the imx-bootlets-src-10.12.01
package, the hang does not occur.
Comparing the DDR2 initialization from the bootlets code against the U-boot
one, we can notice some mismatches, and after applying the same initialization
into U-boot the 2.6.35 kernel can boot normally.
Also tested with 'mtest' command, which runs succesfully.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 87 ++---
1 file changed, 43 insertions(+), 44 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
index f8392f6..d80746f 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
@@ -36,55 +36,54 @@ static uint32_t dram_vals[] = {
* i.MX28 DDR2 at 200MHz
*/
#if defined(CONFIG_MX28)
- 0x, 0x, 0x, 0x,
- 0x, 0x, 0x, 0x,
- 0x, 0x, 0x, 0x,
- 0x, 0x, 0x, 0x,
- 0x, 0x0100, 0x, 0x,
- 0x, 0x, 0x, 0x,
- 0x, 0x, 0x00010101, 0x01010101,
- 0x000f0f01, 0x0f02020a, 0x, 0x00010101,
- 0x0100, 0x0100, 0x, 0x0002,
- 0x0101, 0x05060302, 0x06005003, 0x0ac8,
- 0x02009c40, 0x030c, 0x0036a609, 0x031a0612,
- 0x02030202, 0x00c8001c, 0x, 0x,
- 0x00012100, 0x0303, 0x00012100, 0x0303,
+ 0x, 0x, 0x, 0x,
+ 0x, 0x, 0x, 0x,
+ 0x, 0x, 0x, 0x,
+ 0x, 0x, 0x, 0x,
+ 0x, 0x0100, 0x, 0x,
+ 0x, 0x, 0x, 0x,
+ 0x, 0x, 0x00010101, 0x01010101,
+ 0x000f0f01, 0x0f02020a, 0x, 0x00010101,
+ 0x0100, 0x0100, 0x, 0x0002,
+ 0x0101, 0x07080403, 0x06005003, 0x0ac8,
+ 0x02009c40, 0x0002030c, 0x0036a609, 0x031a0612,
+ 0x02030202, 0x00c8001c, 0x, 0x,
+ 0x00012100, 0x0303, 0x00012100, 0x0303,
0x00012100, 0x0303, 0x00012100, 0x0303,
- 0x0003, 0x, 0x, 0x,
- 0x, 0x, 0x, 0x,
- 0x, 0x, 0x0612, 0x01000F02,
- 0x06120612, 0x0200, 0x00020007, 0xf5014b27,
- 0xf5014b27, 0xf5014b27, 0xf5014b27, 0x07000300,
- 0x07000300, 0x07000300, 0x07000300, 0x0006,
- 0x, 0x, 0x0100, 0x01020408,
- 0x08040201, 0x000f1133, 0x, 0x1f04,
- 0x1f04, 0x1f04, 0x1f04, 0x1f04,
+ 0x0003, 0x, 0x, 0x,
+ 0x, 0x, 0x, 0x,
+ 0x, 0x, 0x0612, 0x01000f02,
+ 0x06120612, 0x0200, 0x00020007, 0xf4004a27,
+ 0xf4004a27, 0xf4004a27, 0xf4004a27, 0x07000300,
+ 0x07000300, 0x07400300, 0x07400300, 0x0005,
+ 0x, 0x, 0x0100, 0x01020408,
+ 0x08040201, 0x000f1133, 0x, 0x1f04,
+ 0x1f04, 0x1f04, 0x1f04, 0x1f04,
0x1f04, 0x1f04, 0x1f04, 0x,
+ 0x, 0x, 0x, 0x,
+ 0x, 0x, 0x, 0x,
+ 0x, 0x, 0x, 0x,
+ 0x, 0x, 0x, 0x,
+ 0x, 0x, 0x, 0x,
+ 0x, 0x, 0x, 0x,
0x, 0x, 0x, 0x,
- 0x, 0x, 0x, 0x,
- 0x, 0x, 0x, 0x,
- 0x, 0x, 0x, 0x,
- 0x, 0x, 0x, 0x,
- 0x, 0x, 0x, 0x,
- 0x, 0x, 0x, 0x,
- 0x, 0x, 0x, 0x,
- 0x, 0x, 0x, 0x,
- 0x, 0x, 0x, 0x,
- 0x, 0x, 0x, 0x,
- 0x, 0x, 0x, 0x,
- 0x, 0x, 0x, 0x,
- 0x, 0x, 0x, 0x,
-
Re: [U-Boot] [PATCH 2/2] ARM: tegra: make CONFIG_CMD_PART common
On Wed, Feb 27, 2013 at 02:03:37PM -0700, Stephen Warren wrote: On 02/26/2013 04:00 PM, Stephen Warren wrote: This is useful on all Tegras, so that boot.scr on all devices can use the same commands. Hence, move it to tegra-common.h. Unfortunately, this breaks Tegra114 builds because no partition types are enabled, and CONFIG_CMD_PART requires functionality that's only enabled if some partition types are supported. There are two possible solutions: 1) Conditionally enable PARTITION_UUIDS and CMD_PART in tegra-common-post.h only if some partition type is enabled. 2) Also enable DOS and EFI partitions in tegra-common.h, along with all of FS_EXT4, FS_FAT, CMD_EXT2, CMD_FAT, CMD_FS_GENERIC. For most boards this won't be any change. For the Colibri T20 and Avionic Design boards, this ends up enabling a few more options. (or perhaps enable all of those in tegra-common-post.h only if support for any block device is enabled) I prefer option (2). Does anyone object? Fine with me. I recently posted patches that enable some of these options as part of boot script support on Tamonten boards anyway. Thierry pgpxfnNBbdiLL.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 1/1] nand: adjust erase/read/write partition/chip size for bad blocks
On 02/26/2013 09:57:14 PM, Harvey Chapman wrote: Adjust the sizes calculated for whole partition/chip operations by removing the size of bad blocks so we don't try to erase/read/write past a partition/chip boundary. Signed-off-by: Harvey Chapman hchap...@3gfp.com --- common/cmd_nand.c | 35 +++ 1 file changed, 35 insertions(+) I don't think we want to do this adjustment for erase -- the value you pass in there is already defined as being the range of blocks on the flash, rather than the amount of data you want to be able to store in the range (except for the .spread variant, but that can't be used with .part or .chip). This makes me wonder if a better approach would be a flag that tells the nand_read|write_skip_bad() function whether size is meant as good data size or actual size? Then we could just set that flag for whole-chip/whole-partition accesses, and let the existing bad block skipping code handle it with some minor tweaks. This would be similar to opts-spread for erase. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] smdk5250: move board specific options to board specific config file
Hi, On Mon, Feb 25, 2013 at 9:13 PM, Inderpal Singh inderpal.si...@linaro.org wrote: Signed-off-by: Inderpal Singh inderpal.si...@linaro.org Acked-by: Chander Kashyap chander.kash...@linaro.org --- include/configs/exynos5250-dt.h | 60 --- include/configs/smdk5250.h | 35 +++ 2 files changed, 35 insertions(+), 60 deletions(-) diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h Sorry I have only just seen this - I don't think this patch is wholly correct. The intent with the -dt.h file is to enable things that might be used by exynos5250 boards. For example it is OK to enable multiple pmic drivers, SPI, MMC, etc. even if not all boards use them. Device tree nodes have a 'status = disabled feature to deal with turning individual peripherals on/ff. I agree that the smdk5250 string is wrong, but you should perhaps change this to exynos5250 instead. By all means undef and define things in your board, but we should not defeat the purpose of the -dt.h file. The device tree should be used to configure/enable drivers where possible. Now I realise that what I am saying is not entirely possible right now (in that for example some drivers are not device tree-enabled), but we should try to avoid just treating this file as an exynos 'common' file. Regards, Simon index 3fa86b2..d4a589c 100644 --- a/include/configs/exynos5250-dt.h +++ b/include/configs/exynos5250-dt.h @@ -73,7 +73,6 @@ #define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (4 20)) /* select serial console configuration */ -#define CONFIG_SERIAL3 /* use SERIAL 3 */ #define CONFIG_BAUDRATE115200 #define EXYNOS5_DEFAULT_UART_OFFSET0x01 @@ -139,7 +138,6 @@ /* Miscellaneous configurable options */ #define CONFIG_SYS_LONGHELP/* undef to save memory */ #define CONFIG_SYS_HUSH_PARSER /* use hush command parser*/ -#define CONFIG_SYS_PROMPT SMDK5250 # #define CONFIG_SYS_CBSIZE 256 /* Console I/O Buffer Size */ #define CONFIG_SYS_PBSIZE 384 /* Print Buffer Size */ #define CONFIG_SYS_MAXARGS 16 /* max number of command args */ @@ -179,7 +177,6 @@ /* FLASH and environment organization */ #define CONFIG_SYS_NO_FLASH #undef CONFIG_CMD_IMLS -#define CONFIG_IDENT_STRING for SMDK5250 #define CONFIG_SYS_MMC_ENV_DEV 0 @@ -232,57 +229,10 @@ #define CONFIG_I2C_EDID /* PMIC */ -#define CONFIG_PMIC -#define CONFIG_PMIC_I2C -#define CONFIG_PMIC_MAX77686 - -/* 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 - -/* PMIC */ #define CONFIG_POWER #define CONFIG_POWER_I2C #define CONFIG_POWER_MAX77686 -/* 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 - /* Ethernet Controllor Driver */ #ifdef CONFIG_CMD_NET #define CONFIG_SMC911X @@ -314,14 +264,4 @@ #define CONFIG_SHA1 #define CONFIG_SHA256 -/* Display */ -#define CONFIG_LCD -#ifdef CONFIG_LCD -#define CONFIG_EXYNOS_FB -#define CONFIG_EXYNOS_DP -#define LCD_XRES 2560 -#define LCD_YRES 1600 -#define LCD_BPPLCD_COLOR16 -#endif - #endif /* __CONFIG_H */ diff --git a/include/configs/smdk5250.h b/include/configs/smdk5250.h index 81f83a8..51c4215 100644 --- a/include/configs/smdk5250.h +++ b/include/configs/smdk5250.h @@ -30,4 +30,39 @@ #undef CONFIG_DEFAULT_DEVICE_TREE #define CONFIG_DEFAULT_DEVICE_TREE exynos5250-smdk5250 +#define CONFIG_SYS_PROMPT SMDK5250 # +#define CONFIG_SERIAL3 /* use SERIAL 3 */ +#define CONFIG_IDENT_STRING for SMDK5250 + +/* SPI */ +#define CONFIG_ENV_IS_IN_SPI_FLASH +#define CONFIG_SPI_FLASH + +#ifdef CONFIG_SPI_FLASH +#define CONFIG_EXYNOS_SPI +#define
Re: [U-Boot] [PATCH v2 1/4] nand: Extend nand_(read|write)_skip_bad with *actual and limit parameters
On 02/27/2013 08:20:19 AM, Tom Rini wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/26/2013 09:08 PM, Scott Wood wrote: The name maxsize suggests that it's a size, not a position. OK, I'll call it maxoff (because it's the max offset within the NAND for a given partition, or end of the NAND). Wouldn't it be less intrusive to just make it actually be the size instead of an offset? -offset += block_len; +*offset += block_len; } return ret; @@ -459,22 +463,26 @@ static size_t drop_ffs(const nand_info_t *nand, const u_char *buf, * Write image to NAND flash. * Blocks that are marked bad are skipped and the is written to the next * block instead as long as the image is short enough to fit even after - * skipping the bad blocks. + * skipping the bad blocks. Note that the actual size needed may exceed + * both the length and available NAND due to bad blocks. If that happens, then the function returns failure. Are the contents of actual well-defined when the function returns failure? They are as well defined as what happens with length. If we say we can't write, we set both to 0 and return an error. I'll take this as a request to expand the comment and do so. The comments could use expanding (it doesn't even explain what happens to length in the non-error case), but also it looks like there are some error paths where actual doesn't get cleared, in the CONFIG_CMD_NAND_YAFFS section. I was also wondering about the case where check_skip_bad() says it doesn't fit. It doesn't return the actual in that case -- it returns offset as of when it stopped. So a caller of nand_read|write_skip_bad() would see the same actual as if it just barely fit. I'm not sure that this function ever would return an actual size that exceeds the available NAND. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] common: imx: Implement generic u-boot.nand target
Hi Marek, On Monday, February 25, 2013 7:19:54 PM, Marek Vasut wrote: Implement u-boot.nand target that can be reused with a small amount of churn across all CPU models. The idea is to delegate the u-boot.nand target out of the main Makefile and into the CPU's Makefile (very similar to what u-boot.imx does now). The main Makefile shall only contain path to which the u-boot.nand target is delegated. Hopefully this will not produce too much bloat in the main Makefile. To demonstrate this implementation, add u-boot.nand target for i.MX53. Signed-off-by: Marek Vasut ma...@denx.de Cc: Benoît Thébaudeau benoit.thebaud...@advansee.com Cc: Fabio Estevam fabio.este...@freescale.com Cc: Stefano Babic sba...@denx.de --- Makefile | 18 ++ arch/arm/imx-common/Makefile |6 ++ 2 files changed, 24 insertions(+) diff --git a/Makefile b/Makefile index 41054b7..8b1010a 100644 --- a/Makefile +++ b/Makefile @@ -470,6 +470,23 @@ $(obj)u-boot.img:$(obj)u-boot.bin $(obj)u-boot.imx: $(obj)u-boot.bin depend $(MAKE) -C $(SRCTREE)/arch/arm/imx-common $(obj)u-boot.imx +# +# Generic u-boot.nand target. +# +# Every CPU that needs u-boot.nand must add a path to an implementation of +# the actual u-boot.nand generator below. +# +ifdef CONFIG_MX53 +CONFIG_NAND_TRG_PATH := $(SRCTREE)/arch/arm/imx-common +endif + +$(obj)u-boot.nand: $(obj)u-boot.bin depend + if [ X$(CONFIG_NAND_TRG_PATH)X = XX ] ; then \ + echo This CPU does not support u-boot.nand target! ; \ + exit 1 ; \ + fi + $(MAKE) -C $(CONFIG_NAND_TRG_PATH) $(obj)u-boot.nand + $(obj)u-boot.kwb: $(obj)u-boot.bin $(obj)tools/mkimage -n $(CONFIG_SYS_KWD_CONFIG) -T kwbimage \ -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_TEXT_BASE) -d $ $@ @@ -857,6 +874,7 @@ clobber: tidy @rm -f $(obj)u-boot.kwb @rm -f $(obj)u-boot.pbl @rm -f $(obj)u-boot.imx + @rm -f $(obj)u-boot.nand @rm -f $(obj)u-boot.ubl @rm -f $(obj)u-boot.ais @rm -f $(obj)u-boot.dtb diff --git a/arch/arm/imx-common/Makefile b/arch/arm/imx-common/Makefile index 5d5c5b2..71ea36f 100644 --- a/arch/arm/imx-common/Makefile +++ b/arch/arm/imx-common/Makefile @@ -50,6 +50,12 @@ $(obj)u-boot.imx: $(OBJTREE)/u-boot.bin $(OBJTREE)/$(patsubst %,%,$(CONFIG_IMX $(OBJTREE)/tools/mkimage -n $(filter-out %.bin,$^) -T imximage \ -e $(CONFIG_SYS_TEXT_BASE) -d $ $@ +$(obj)u-boot.nand: $(obj)u-boot.imx + ( \ + echo -ne '\x00\x00\x00\x00\x46\x43\x42\x20\x01' ; \ ^ It does not work in my environment (Ubuntu 12.10). -ne is interpreted as text, so the FCB is broken. This is because /bin/sh (set to dash) is invoked by default on my machine here. It would work with the /bin/bash set by the main Makefile for SHELL, but this is not passed to the sub-make. So what do you think we should do: 1) Add export SHELL to the main Makefile? 2) Move the SHELL assignment from the main Makefile to the top-level config.mk? 3) Set SHELL=$(SHELL) on the command line when invoking the sub-make? 4) Use printf instead of echo? 5) Something else? I like 1). Do you see possible side effects? I will add a patch for that in my v8 once we have made a choice if this choice is a global fix (i.e. 1 or 2). + dd if=/dev/zero bs=1015 count=1 2/dev/null ) | \ + cat - $ $@ + $(obj)SPL: $(OBJTREE)/spl/u-boot-spl.bin $(OBJTREE)/$(patsubst %,%,$(CONFIG_IMX_CONFIG)).cfgtmp $(OBJTREE)/tools/mkimage -n $(filter-out %.bin,$^) -T imximage \ -e $(CONFIG_SPL_TEXT_BASE) -d $ $@ Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] nand: Extend nand_(read|write)_skip_bad with *actual and limit parameters
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/27/2013 05:04 PM, Scott Wood wrote: On 02/27/2013 08:20:19 AM, Tom Rini wrote: [snip] -offset += block_len; +*offset += block_len; } return ret; @@ -459,22 +463,26 @@ static size_t drop_ffs(const nand_info_t *nand, const u_char *buf, * Write image to NAND flash. * Blocks that are marked bad are skipped and the is written to the next * block instead as long as the image is short enough to fit even after - * skipping the bad blocks. + * skipping the bad blocks. Note that the actual size needed may exceed + * both the length and available NAND due to bad blocks. If that happens, then the function returns failure. Are the contents of actual well-defined when the function returns failure? They are as well defined as what happens with length. If we say we can't write, we set both to 0 and return an error. I'll take this as a request to expand the comment and do so. The comments could use expanding (it doesn't even explain what happens to length in the non-error case), but also it looks like there are some error paths where actual doesn't get cleared, in the CONFIG_CMD_NAND_YAFFS section. I've dropped actual for everything except for DFU where it's really needed. And I've expanded the big comment block (not the @param) lines with what happens to length and actual. I was also wondering about the case where check_skip_bad() says it doesn't fit. It doesn't return the actual in that case -- it returns offset as of when it stopped. So a caller of nand_read|write_skip_bad() would see the same actual as if it just barely fit. I'm not sure that this function ever would return an actual size that exceeds the available NAND. No? check_skip_bad only bails out totally on end of NAND (and doesn't care about limit). I've re-worked things so check_skip_bad treats actual as a size not an offset, but yes, in the case of actual exceeds NAND, actual is only as far as we calculated. If we're going to start fiddling around in here with these cases for non-human users (IOW, the You've exceeded the device size print wouldn't be seen) then we need to start using more than just -EINVAL so we can differentiate No space and Too Big. At least with v3 (which I was about to send and saw your email) should address everything. I jsut want to re-read your comments above with the code and a fresh mind in the morning before re-posting. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRLpiJAAoJENk4IS6UOR1Wj4MP/08nqOakLldtjLUWBhFhTQA5 8kjaDZj0pP/RFkVUgprDuOM+JTWSY08KVVQ25pooXUN7C5OxivLgZPPcsExKeXWd TiO8ADzVqns24Cg/RmS16ZZzpNiwjhzR/oWoaI+Zi6t1S4pSx7UBMQVQhH81sXOn VQzWzGithY74bsFzUwQQkIIeWL+WqgCZuySop09JIB1mXcleiV4FB9/5aXmWEzOg YhtE10cR6RCHVPBJR50qMbelvtS+h2DzFSrvz66YlicBWXdoD8gkLJ2WdM0zojuP cetdpFSsbgadpjp8MO4SQLpim7ytdTm3IWpqGUFFTFLoaEiAxcqts82I+NcPIxF7 c9q3iS2P5h+NT9ZUqW+j+BcEz8fvJv1lWwB6t3CTsLE4EynK9iZaCNfAa8eZ3457 a3G4eVmCCFH5ZaLgmnDQR1ol6Pc2iuoZH6XX6I5JWMdSRRs5arHMaF8LCydSuPcE gII59PK3O+RbpJYGE8nvFwByamGPtaNhTzBqBSkdGp3+lKhkEWM31dvUR0s6GGRS 5rTdEIXkHqLpu0+4YMDVFp2PAYuITnkuZCynOWyjJSojufEYTcwJiX4GRFfL+o+x SCMsWdzqAnzrVQAP9Re+MDU+6qiPw4GRe36SOu5uq/QNwyAyFM1xC6dXogcfHYSH rgmSTadLscWZBaR3guc4 =hPgQ -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] common: imx: Implement generic u-boot.nand target
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/27/2013 05:18 PM, Benoît Thébaudeau wrote: Hi Marek, On Monday, February 25, 2013 7:19:54 PM, Marek Vasut wrote: Implement u-boot.nand target that can be reused with a small amount of churn across all CPU models. The idea is to delegate the u-boot.nand target out of the main Makefile and into the CPU's Makefile (very similar to what u-boot.imx does now). The main Makefile shall only contain path to which the u-boot.nand target is delegated. Hopefully this will not produce too much bloat in the main Makefile. To demonstrate this implementation, add u-boot.nand target for i.MX53. Signed-off-by: Marek Vasut ma...@denx.de Cc: Benoît Thébaudeau benoit.thebaud...@advansee.com Cc: Fabio Estevam fabio.este...@freescale.com Cc: Stefano Babic sba...@denx.de --- Makefile | 18 ++ arch/arm/imx-common/Makefile |6 ++ 2 files changed, 24 insertions(+) diff --git a/Makefile b/Makefile index 41054b7..8b1010a 100644 --- a/Makefile +++ b/Makefile @@ -470,6 +470,23 @@ $(obj)u-boot.img:$(obj)u-boot.bin $(obj)u-boot.imx: $(obj)u-boot.bin depend $(MAKE) -C $(SRCTREE)/arch/arm/imx-common $(obj)u-boot.imx +# +# Generic u-boot.nand target. +# +# Every CPU that needs u-boot.nand must add a path to an implementation of +# the actual u-boot.nand generator below. +# +ifdef CONFIG_MX53 +CONFIG_NAND_TRG_PATH := $(SRCTREE)/arch/arm/imx-common +endif + +$(obj)u-boot.nand: $(obj)u-boot.bin depend +if [ X$(CONFIG_NAND_TRG_PATH)X = XX ] ; then \ + echo This CPU does not support u-boot.nand target! ; \ + exit 1 ;\ + fi + $(MAKE) -C $(CONFIG_NAND_TRG_PATH) $(obj)u-boot.nand + $(obj)u-boot.kwb: $(obj)u-boot.bin $(obj)tools/mkimage -n $(CONFIG_SYS_KWD_CONFIG) -T kwbimage \ -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_TEXT_BASE) -d $ $@ @@ -857,6 +874,7 @@ clobber: tidy @rm -f $(obj)u-boot.kwb @rm -f $(obj)u-boot.pbl @rm -f $(obj)u-boot.imx + @rm -f $(obj)u-boot.nand @rm -f $(obj)u-boot.ubl @rm -f $(obj)u-boot.ais @rm -f $(obj)u-boot.dtb diff --git a/arch/arm/imx-common/Makefile b/arch/arm/imx-common/Makefile index 5d5c5b2..71ea36f 100644 --- a/arch/arm/imx-common/Makefile +++ b/arch/arm/imx-common/Makefile @@ -50,6 +50,12 @@ $(obj)u-boot.imx: $(OBJTREE)/u-boot.bin $(OBJTREE)/$(patsubst %,%,$(CONFIG_IMX $(OBJTREE)/tools/mkimage -n $(filter-out %.bin,$^) -T imximage \ -e $(CONFIG_SYS_TEXT_BASE) -d $ $@ +$(obj)u-boot.nand: $(obj)u-boot.imx + ( \ + echo -ne '\x00\x00\x00\x00\x46\x43\x42\x20\x01' ; \ ^ It does not work in my environment (Ubuntu 12.10). -ne is interpreted as text, so the FCB is broken. This is because /bin/sh (set to dash) is invoked by default on my machine here. It would work with the /bin/bash set by the main Makefile for SHELL, but this is not passed to the sub-make. So what do you think we should do: 1) Add export SHELL to the main Makefile? 2) Move the SHELL assignment from the main Makefile to the top-level config.mk? 3) Set SHELL=$(SHELL) on the command line when invoking the sub-make? 4) Use printf instead of echo? 5) Something else? I like 1). Do you see possible side effects? It looks like in these cases the kernel does $(shell echo -...), or is that also not working on your setup? - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRLppcAAoJENk4IS6UOR1WiXoP/1wy8CU/bEgreOP/aPu2xsEA 7oh6CRRVLqGhioTo766IjaaDWD21uNmUpI3VK8wF8FBrPmmgS+IU9icYjd39ZsoL m0riocPX3TS6SJFqs/xJpgsCFSCnw7MAjz8Eo/RphV8pohMnsqUrKX4TiPiZKxeS 2wky4E9PcMDdf07ahJEUC3Y73BNBXrml+MGh59sKrAKpvES7OutbUHCHD+ZeX3WC Tk3nbFis3Sb+VY8vnMllyqVyCZQAI+MhJxm9zHTW2GzkX3/FsQ8tUND+DT8JmKv9 RQMkVCY92cdO5+0y+8RGO7WUwY0YghMdzfIkkr3ZQGlu9ccghcwvm21d2zVt7zCa UfRyl1NK3xgFIfAsyBWVF8q75WkQUVT06YJo2SJTfcvIa/hlGH6FvN9fODcxeris WAIan5Z3haZ7EiIGjn/KHq4dHYhS7c3iKqsi4FIQcoGsbwI9oFVqIQ98JW1UbWpS 174DvASSobba487fuAYTKgCwa2Qm9LHmy7XvJfb7CQTjrJuzsuRBWuhy3DD70AOC Mo/Ewq4b1juvS/vTwT+d/eJcnBklDYvvJ31FMuf+P+EBwyz3AmIAmzBKRhRP37SV EIKjB7GKHSuxrvJV6SjPAJW6suY4TiDSUh/myeXnGs/1+KDeGj91I5Dja4Cidl0o TpP52BmyQrPVs2hS1PpC =UQTu -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] common: imx: Implement generic u-boot.nand target
Hi Tom, On Thursday, February 28, 2013 12:44:28 AM, Tom Rini wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/27/2013 05:18 PM, Benoît Thébaudeau wrote: Hi Marek, On Monday, February 25, 2013 7:19:54 PM, Marek Vasut wrote: Implement u-boot.nand target that can be reused with a small amount of churn across all CPU models. The idea is to delegate the u-boot.nand target out of the main Makefile and into the CPU's Makefile (very similar to what u-boot.imx does now). The main Makefile shall only contain path to which the u-boot.nand target is delegated. Hopefully this will not produce too much bloat in the main Makefile. To demonstrate this implementation, add u-boot.nand target for i.MX53. Signed-off-by: Marek Vasut ma...@denx.de Cc: Benoît Thébaudeau benoit.thebaud...@advansee.com Cc: Fabio Estevam fabio.este...@freescale.com Cc: Stefano Babic sba...@denx.de --- Makefile | 18 ++ arch/arm/imx-common/Makefile |6 ++ 2 files changed, 24 insertions(+) diff --git a/Makefile b/Makefile index 41054b7..8b1010a 100644 --- a/Makefile +++ b/Makefile @@ -470,6 +470,23 @@ $(obj)u-boot.img: $(obj)u-boot.bin $(obj)u-boot.imx: $(obj)u-boot.bin depend $(MAKE) -C $(SRCTREE)/arch/arm/imx-common $(obj)u-boot.imx +# +# Generic u-boot.nand target. +# +# Every CPU that needs u-boot.nand must add a path to an implementation of +# the actual u-boot.nand generator below. +# +ifdef CONFIG_MX53 +CONFIG_NAND_TRG_PATH := $(SRCTREE)/arch/arm/imx-common +endif + +$(obj)u-boot.nand: $(obj)u-boot.bin depend + if [ X$(CONFIG_NAND_TRG_PATH)X = XX ] ; then\ + echo This CPU does not support u-boot.nand target! ;\ + exit 1 ;\ + fi + $(MAKE) -C $(CONFIG_NAND_TRG_PATH) $(obj)u-boot.nand + $(obj)u-boot.kwb: $(obj)u-boot.bin $(obj)tools/mkimage -n $(CONFIG_SYS_KWD_CONFIG) -T kwbimage \ -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_TEXT_BASE) -d $ $@ @@ -857,6 +874,7 @@ clobber: tidy @rm -f $(obj)u-boot.kwb @rm -f $(obj)u-boot.pbl @rm -f $(obj)u-boot.imx + @rm -f $(obj)u-boot.nand @rm -f $(obj)u-boot.ubl @rm -f $(obj)u-boot.ais @rm -f $(obj)u-boot.dtb diff --git a/arch/arm/imx-common/Makefile b/arch/arm/imx-common/Makefile index 5d5c5b2..71ea36f 100644 --- a/arch/arm/imx-common/Makefile +++ b/arch/arm/imx-common/Makefile @@ -50,6 +50,12 @@ $(obj)u-boot.imx: $(OBJTREE)/u-boot.bin $(OBJTREE)/$(patsubst %,%,$(CONFIG_IMX $(OBJTREE)/tools/mkimage -n $(filter-out %.bin,$^) -T imximage \ -e $(CONFIG_SYS_TEXT_BASE) -d $ $@ +$(obj)u-boot.nand: $(obj)u-boot.imx + ( \ + echo -ne '\x00\x00\x00\x00\x46\x43\x42\x20\x01' ; \ ^ It does not work in my environment (Ubuntu 12.10). -ne is interpreted as text, so the FCB is broken. This is because /bin/sh (set to dash) is invoked by default on my machine here. It would work with the /bin/bash set by the main Makefile for SHELL, but this is not passed to the sub-make. So what do you think we should do: 1) Add export SHELL to the main Makefile? 2) Move the SHELL assignment from the main Makefile to the top-level config.mk? 3) Set SHELL=$(SHELL) on the command line when invoking the sub-make? 4) Use printf instead of echo? 5) Something else? I like 1). Do you see possible side effects? It looks like in these cases the kernel does $(shell echo -...), or is that also not working on your setup? I'll test that tomorrow, but I don't see how it could work better since $(shell ...) will very likely invoke $(SHELL) -c /bin/echo works though, but is this portable enough for U-Boot? Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] ARM: implement some Cortex-A9 errata workarounds
On Tue, Feb 26, 2013 at 2:28 PM, Stephen Warren swar...@wwwdotorg.org wrote: From: Stephen Warren swar...@nvidia.com Various errata exist in the Cortex-A9 CPU, and may be worked around by setting some bits in a CP15 diagnostic register. Add code to implement the workarounds, enabled by new CONFIG_ options. This code was taken from the Linux kernel, v3.8, arch/arm/mm/proc-v7.S, and modified to remove the logic to conditionally apply the WAR (since we know exactly which CPU we're running on given the U-Boot configuration), and use r0 instead of r10 for consistency with the rest of U-Boot's cpu_init_cp15(). Signed-off-by: Stephen Warren swar...@nvidia.com Acked-by: Simon Glass s...@chromium.org Good to have. Although I wonder why we wouldn't want to probe it in U-Boot as with Linux? --- README | 10 ++ arch/arm/cpu/armv7/start.S | 19 +++ 2 files changed, 29 insertions(+) diff --git a/README b/README index d8cb394..f2b1c88 100644 --- a/README +++ b/README @@ -485,6 +485,16 @@ The following options need to be configured: Thumb2 this flag will result in Thumb2 code generated by GCC. + CONFIG_ARM_ERRATA_742230 + CONFIG_ARM_ERRATA_743622 + CONFIG_ARM_ERRATA_751472 + + If set, the workarounds for these ARM errata are applied early + during U-Boot startup. Note that these options force the + workarounds to be applied; no CPU-type/version detection + exists, unlike the similar options in the Linux kernel. Do not + set these options unless they apply! + - Linux Kernel Interface: CONFIG_CLOCKS_IN_MHZ diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index 6b59529d..30f02d3 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -309,6 +309,25 @@ ENTRY(cpu_init_cp15) orr r0, r0, #0x1000 @ set bit 12 (I) I-cache #endif mcr p15, 0, r0, c1, c0, 0 + +#ifdef CONFIG_ARM_ERRATA_742230 + mrc p15, 0, r0, c15, c0, 1 @ read diagnostic register + orr r0, r0, #1 4 @ set bit #4 + mcr p15, 0, r0, c15, c0, 1 @ write diagnostic register +#endif + +#ifdef CONFIG_ARM_ERRATA_743622 + mrc p15, 0, r0, c15, c0, 1 @ read diagnostic register + orr r0, r0, #1 6 @ set bit #6 + mcr p15, 0, r0, c15, c0, 1 @ write diagnostic register +#endif + +#ifdef CONFIG_ARM_ERRATA_751472 + mrc p15, 0, r0, c15, c0, 1 @ read diagnostic register + orr r0, r0, #1 11@ set bit #11 + mcr p15, 0, r0, c15, c0, 1 @ write diagnostic register +#endif + mov pc, lr @ back to my caller ENDPROC(cpu_init_cp15) -- 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 1/2 V3] EXYNOS5: Add initial DTS file for Snow.
Hi Rajeshwari,
On Mon, Feb 25, 2013 at 3:07 AM, Rajeshwari Shinde
rajeshwar...@samsung.com wrote:
This patch adds the DTS file for Snow Board.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes in V2:
- None
Changes in V3:
- None
board/samsung/dts/exynos5250-snow.dts | 69
+
1 files changed, 69 insertions(+), 0 deletions(-)
create mode 100644 board/samsung/dts/exynos5250-snow.dts
diff --git a/board/samsung/dts/exynos5250-snow.dts
b/board/samsung/dts/exynos5250-snow.dts
new file mode 100644
index 000..360d3bd
--- /dev/null
+++ b/board/samsung/dts/exynos5250-snow.dts
@@ -0,0 +1,69 @@
+/*
+ * SAMSUNG Snow board device tree source
+ *
+ * Copyright (c) 2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/dts-v1/;
+/include/ ARCH_CPU_DTS
+
+/ {
+ model = Google Snow;
+ compatible = google,snow, samsung,exynos5250;
+
+ aliases {
+ i2c0 = /i2c@12c6;
+ i2c1 = /i2c@12c7;
+ i2c2 = /i2c@12c8;
+ i2c3 = /i2c@12c9;
+ i2c4 = /i2c@12ca;
+ i2c5 = /i2c@12cb;
+ i2c6 = /i2c@12cc;
+ i2c7 = /i2c@12cd;
+ spi0 = /spi@12d2;
+ spi1 = /spi@12d3;
+ spi2 = /spi@12d4;
+ spi3 = /spi@131a;
+ spi4 = /spi@131b;
+ };
+
+ sromc@1225 {
+ bank = 1;
+ srom-timing = 1 9 12 1 6 1 1;
+ width = 2;
+ lan@500 {
+ compatible = smsc,lan9215, smsc,lan;
+ reg = 0x500 0x100;
+ phy-mode = mii;
+ };
+ };
I think the Ethernet should be removed since snow does not have this.
+
+ sound@12d6 {
+ samsung,i2s-epll-clock-frequency = 19200;
+ samsung,i2s-sampling-rate = 48000;
+ samsung,i2s-bits-per-sample = 16;
+ samsung,i2s-channels = 2;
+ samsung,i2s-lr-clk-framesize = 256;
+ samsung,i2s-bit-clk-framesize = 32;
+ samsung,codec-type = max98095;
+ };
+
+ i2c@12cd {
+ soundcodec@22 {
+ reg = 0x22;
+ compatible = maxim,max98095-codec;
+ };
+ };
+
+ i2c@12c6 {
+ pmic@9 {
+ reg = 0x9;
+ compatible = maxim,max77686_pmic;
+ };
+ };
+};
--
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 1/3] ARM: implement some Cortex-A9 errata workarounds
On 02/27/2013 05:30 PM, Simon Glass wrote: On Tue, Feb 26, 2013 at 2:28 PM, Stephen Warren swar...@wwwdotorg.org wrote: From: Stephen Warren swar...@nvidia.com Various errata exist in the Cortex-A9 CPU, and may be worked around by setting some bits in a CP15 diagnostic register. Add code to implement the workarounds, enabled by new CONFIG_ options. This code was taken from the Linux kernel, v3.8, arch/arm/mm/proc-v7.S, and modified to remove the logic to conditionally apply the WAR (since we know exactly which CPU we're running on given the U-Boot configuration), and use r0 instead of r10 for consistency with the rest of U-Boot's cpu_init_cp15(). Signed-off-by: Stephen Warren swar...@nvidia.com Acked-by: Simon Glass s...@chromium.org Good to have. Although I wonder why we wouldn't want to probe it in U-Boot as with Linux? I figured it wasn't worth the complexity initially. Right now, U-Boot is built for a specific board (or just perhaps a small set of almost identical boards), so we know exactly which CPU rev is present. If this becomes false (e.g. DT works so well we can do a combined Tegra20+Tegra30 U-Boot), we can always add the conditional logic in when we need it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 V3] EXYNOS5: Snow: Add a configuration file
On Mon, Feb 25, 2013 at 3:07 AM, Rajeshwari Shinde rajeshwar...@samsung.com wrote: This patch adds the configuration file for Snow Board and defines the same in boards.cfg. Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com Acked-by: Simon Glass s...@chromium.org --- Changes in V2: - Added Maintainer Changes in V3: - Added Maintainer in aphabetical order. MAINTAINERS|4 boards.cfg |1 + include/configs/snow.h | 33 + 3 files changed, 38 insertions(+), 0 deletions(-) create mode 100644 include/configs/snow.h diff --git a/MAINTAINERS b/MAINTAINERS index 45e2dd4..f6723ef 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -910,6 +910,10 @@ Matt Sealey m...@genesi-usa.com Bo Shen voice.s...@atmel.com at91sam9x5ekARM926EJS (AT91SAM9G15,G25,G35,X25,X35 SoC) +Rajeshwari Shinde rajeshwar...@samsung.com + + snowARM ARMV7 (EXYNOS5250 SoC) + Michal Simek mon...@monstr.eu zynqARM ARMV7 (Zynq SoC) diff --git a/boards.cfg b/boards.cfg index b1319aa..54357eb 100644 --- a/boards.cfg +++ b/boards.cfg @@ -286,6 +286,7 @@ s5p_goni arm armv7 goni samsung smdkc100 arm armv7 smdkc100 samsungs5pc1xx origen arm armv7 origen samsungexynos s5pc210_universalarm armv7 universal_c210 samsungexynos +snowarm armv7 smdk5250 samsungexynos smdk5250arm armv7 smdk5250 samsungexynos smdkv310arm armv7 smdkv310 samsungexynos tratsarm armv7 trats samsungexynos diff --git a/include/configs/snow.h b/include/configs/snow.h new file mode 100644 index 000..b8460fd --- /dev/null +++ b/include/configs/snow.h @@ -0,0 +1,33 @@ +/* + * Copyright (C) 2013 Samsung Electronics + * + * Configuration settings for the SAMSUNG EXYNOS5 Snow board. + * + * 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 __CONFIG_SNOW_H +#define __CONFIG_SNOW_H + +#include configs/exynos5250-dt.h + +#undef CONFIG_DEFAULT_DEVICE_TREE +#define CONFIG_DEFAULT_DEVICE_TREE exynos5250-snow + +#endif /* __CONFIG_SNOW_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] [PATCH 1/3] ARM: implement some Cortex-A9 errata workarounds
HI Stephen, On Wed, Feb 27, 2013 at 4:36 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 02/27/2013 05:30 PM, Simon Glass wrote: On Tue, Feb 26, 2013 at 2:28 PM, Stephen Warren swar...@wwwdotorg.org wrote: From: Stephen Warren swar...@nvidia.com Various errata exist in the Cortex-A9 CPU, and may be worked around by setting some bits in a CP15 diagnostic register. Add code to implement the workarounds, enabled by new CONFIG_ options. This code was taken from the Linux kernel, v3.8, arch/arm/mm/proc-v7.S, and modified to remove the logic to conditionally apply the WAR (since we know exactly which CPU we're running on given the U-Boot configuration), and use r0 instead of r10 for consistency with the rest of U-Boot's cpu_init_cp15(). Signed-off-by: Stephen Warren swar...@nvidia.com Acked-by: Simon Glass s...@chromium.org Good to have. Although I wonder why we wouldn't want to probe it in U-Boot as with Linux? I figured it wasn't worth the complexity initially. Right now, U-Boot is built for a specific board (or just perhaps a small set of almost identical boards), so we know exactly which CPU rev is present. If this becomes false (e.g. DT works so well we can do a combined Tegra20+Tegra30 U-Boot), we can always add the conditional logic in when we need it. Fair enough, thank you. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] EXYNOS: Correct ordering of SPL machine_params
On Mon, Feb 18, 2013 at 10:32 PM, Rajeshwari Shinde
rajeshwar...@samsung.com wrote:
From: Simon Glass s...@chromium.org
The mem_manuf is not in the correct order according to the string table.
This causes cros_bundle_firmware to get the BL2 settings in the wrong
order. This patch fixes the same.
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
arch/arm/include/asm/arch-exynos/spl.h |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/spl.h
b/arch/arm/include/asm/arch-exynos/spl.h
index 306b41d..46b25a6 100644
--- a/arch/arm/include/asm/arch-exynos/spl.h
+++ b/arch/arm/include/asm/arch-exynos/spl.h
@@ -78,11 +78,12 @@ struct spl_machine_param {
*/
u32 uboot_size;
enum boot_mode boot_source;/* Boot device */
- enum mem_manuf mem_manuf; /* Memory Manufacturer */
unsignedfrequency_mhz; /* Frequency of memory in MHz */
unsignedarm_freq_mhz; /* ARM Frequency in MHz */
u32 serial_base;/* Serial base address */
u32 i2c_base; /* i2c base address */
+ u32 board_rev_gpios;/* Board revision GPIOs */
+ enum mem_manuf mem_manuf; /* Memory Manufacturer */
} __attribute__((__packed__));
#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 v3] Exynos5: Pinmux: Add fdt for pinmux
Hi Akshay,
On Mon, Feb 25, 2013 at 10:04 AM, Akshay Saraswat aksha...@samsung.com wrote:
Hi Simon,
Hi Akshay,
On Thu, Feb 21, 2013 at 11:05 AM, Akshay Saraswat aksha...@samsung.com
wrote:
This patch adds fdt nodes for peripherals which require
pin muxing and configuration. Device tree bindings for pinctrl
are kept same as required for Linux. Existing pinmux code
modified to retrieve gpio range and function related info from fdt.
Depends-on: [U-Boot] [PATCH 0/4 V3] EXYNOS5: Add GPIO numbering feature
URL: http://lists.denx.de/pipermail/u-boot/2013-February/146151.html
Signed-off-by: Akshay Saraswat aksha...@samsung.com
---
Changes since v2:
- Rebased as per new version of GPIO numbering patch-set.
This looks pretty reasonable to me. Please find some comment below.
As a general comment, it seems to read from the FDT each time anything
is changed. I suppose that is efficient on space, and allows it to
work prior to malloc() being available, but isn't it slow? Perhaps the
data should be cached?
Malloc is not present initially with us which you have already highlighted,
adding to that we dont use same value more than once.
Hence, I found it better to stick with FDT reading instead of creating a
linked list of all nodes.
Please suggest a location where we shall create the list if we need to
maintain the cache.
I think this is OK for a start.
arch/arm/cpu/armv7/exynos/pinmux.c | 379 +++
arch/arm/dts/exynos5250-pinctrl.dtsi | 675
++
arch/arm/dts/exynos5250.dtsi |1 +
doc/device-tree-bindings/samsung-pinctrl.txt | 253 ++
include/fdtdec.h |1 +
lib/fdtdec.c |1 +
6 files changed, 1204 insertions(+), 106 deletions(-)
create mode 100644 arch/arm/dts/exynos5250-pinctrl.dtsi
create mode 100644 doc/device-tree-bindings/samsung-pinctrl.txt
diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c
b/arch/arm/cpu/armv7/exynos/pinmux.c
index a01ce0c..f4dccad 100644
--- a/arch/arm/cpu/armv7/exynos/pinmux.c
+++ b/arch/arm/cpu/armv7/exynos/pinmux.c
@@ -27,6 +27,18 @@
#include asm/arch/pinmux.h
#include asm/arch/sromc.h
+DECLARE_GLOBAL_DATA_PTR;
+
+/* Struct for storing pin function and gpio related info */
+struct pin_group {
+ void *dev_name;
What is this for?
This is the device name to search for corresponding node.
Since we cannot declare a compatible property for every node,
so I used names to search for nodes.
OK I see - the comment help thank you.
+ int npins;
+ int function;
+ int pull_mode;
+ int drive_strength;
Should add comments about the S5P_GPIO... defines to use in each case.
+ enum exynos5_gpio_pin gpio[];
This array has no members?
This is a dynamic array because we do not know exact number of pins in every
node.
+};
+
struct gpio_name_num_table exynos5_gpio_table[] = {
{ 'a', GPIO_A00 },
{ 'b', GPIO_B00 },
@@ -42,87 +54,202 @@ struct gpio_name_num_table exynos5_gpio_table[] = {
{ 'z', GPIO_Z0 },
};
-static void exynos5_uart_config(int peripheral)
+static void get_pins(const struct fdt_property *fprop, struct pin_group
*pingrp)
{
- int i, start, count;
+ int i;
+ char gpio[5];
+
+ pingrp-npins = 0;
+
+ for (i = 0; !(fprop-data[i] == (int)NULL
+ fprop-data[i-1] == (int)NULL); i += 7) {
This is a bit obtuse - please add a comment
+ int pin_num = -1;
+
+ gpio[0] = fprop-data[i];
+ gpio[1] = fprop-data[i + 1];
+ gpio[2] = fprop-data[i + 2];
+ gpio[3] = fprop-data[i + 3];
+ gpio[4] = fprop-data[i + 5];
What is this doing? Please add a comment.
+
+ pin_num = name_to_gpio(gpio);
+
+ if (pin_num = 0) {
+ pingrp-gpio[pingrp-npins] = pin_num;
This seems to be assigning to something with no members.
Actually I tried to make a dynamic array because we dont know the exact
number of pins for every node.
Please tell me if this introduces any bug. I'll try to figure some other
solution.
+ pingrp-npins++;
+ }
+ }
+}
+
+static int get_fdt_values(struct pin_group *pingrp)
Please add a function comment.
+{
+ int i;
+ int node, subnode;
+ const struct fdt_property *fprop;
+
+ for (i = 0; i 4; i++) {
Why 4? I think you should just continue until node returns -ve.
+ /* Get the node from FDT for pinctrl */
+ node = fdtdec_next_compatible(gd-fdt_blob, 0,
+ COMPAT_SAMSUNG_PINCTRL);
+ if (node 0) {
+ printf(PINCTRL: No node for pinctrl in device
tree\n);
debug()
Only give this error if you don't
Re: [U-Boot] [PATCH v4] Exynos5: Pinmux: Add fdt for pinmux
Hi Akshay,
On Mon, Feb 25, 2013 at 10:27 AM, Akshay Saraswat aksha...@samsung.com wrote:
This patch adds fdt nodes for peripherals which require
pin muxing and configuration. Device tree bindings for pinctrl
are kept same as required for Linux. Existing pinmux code
modified to retrieve gpio range and function related info from fdt.
Depends-on: [U-Boot] [PATCH 0/4 V3] EXYNOS5: Add GPIO numbering feature
URL: http://lists.denx.de/pipermail/u-boot/2013-February/146151.html
Signed-off-by: Akshay Saraswat aksha...@samsung.com
---
Changes since v3:
- Added comments to reduce ambiguity and increase readability.
- Fixed few other nits.
arch/arm/cpu/armv7/exynos/pinmux.c | 404 +++
arch/arm/dts/exynos5250-pinctrl.dtsi | 675
++
arch/arm/dts/exynos5250.dtsi |1 +
doc/device-tree-bindings/samsung-pinctrl.txt | 253 ++
include/fdtdec.h |1 +
lib/fdtdec.c |1 +
6 files changed, 1229 insertions(+), 106 deletions(-)
create mode 100644 arch/arm/dts/exynos5250-pinctrl.dtsi
create mode 100644 doc/device-tree-bindings/samsung-pinctrl.txt
diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c
b/arch/arm/cpu/armv7/exynos/pinmux.c
index a01ce0c..ba34560 100644
--- a/arch/arm/cpu/armv7/exynos/pinmux.c
+++ b/arch/arm/cpu/armv7/exynos/pinmux.c
@@ -27,6 +27,21 @@
#include asm/arch/pinmux.h
#include asm/arch/sromc.h
+DECLARE_GLOBAL_DATA_PTR;
+
+/*
+ * Struct for temporarily storing pin numbers and
+ * pin function related info.
+ */
+struct pin_group {
+ void *dev_name; /* Name of the Peripheral device */
+ int npins; /* Number of pins to be configured */
+ int function; /* Pin function */
+ int pull_mode; /* Pin pull mode */
+ int drive_strength; /* Pin drive strength */
+ enum exynos5_gpio_pin gpio[]; /* Pin numbers to be configured */
+};
+
struct gpio_name_num_table exynos5_gpio_table[] = {
{ 'a', GPIO_A00 },
{ 'b', GPIO_B00 },
@@ -42,87 +57,224 @@ struct gpio_name_num_table exynos5_gpio_table[] = {
{ 'z', GPIO_Z0 },
};
-static void exynos5_uart_config(int peripheral)
+/* Populate exynos5_gpio_pin array in a particular pin_group */
+static void pinmux_get_pin_numbers(const struct fdt_property *fprop,
+ struct pin_group *pingrp)
You only use fprop-data here, so you should pass that in instead of fprop.
+{
+ int i;
+ char gpio[5];
+
+ pingrp-npins = 0;
+
+ /*
+* Get all the pin names from fdt and fill the gpio array
+* with corresponding enum values(Pin numbers).
+*/
+ for (i = 0; !(fprop-data[i] == (int)NULL
+ fprop-data[i-1] == (int)NULL); i += 7) {
+ int pin_num = -1;
+
+ /*
+* Modify pin name retrieved from fdt,
+* so that name_to_gpio may understand.
+*/
+ gpio[0] = fprop-data[i];
+ gpio[1] = fprop-data[i + 1];
+ gpio[2] = fprop-data[i + 2];
+ gpio[3] = fprop-data[i + 3];
+ gpio[4] = fprop-data[i + 5];
+
+ pin_num = name_to_gpio(gpio);
+
+ /*
+* If pin number is valid, add it to the pin array
+* and increment pin count.
+*/
+ if (pin_num = 0) {
+ pingrp-gpio[pingrp-npins] = pin_num;
+ pingrp-npins++;
+ }
+ }
+}
+
+/* Extract all the config info for a node from fdt */
+static int pinmux_get_fdt_values(struct pin_group *pingrp)
{
- int i, start, count;
+ int node, subnode;
+ const struct fdt_property *fprop;
+
+ /* Loop for all pinctrl nodes in fdt */
+ for (node = fdtdec_next_compatible(gd-fdt_blob, 0,
+ COMPAT_SAMSUNG_PINCTRL); node = 0;
+ node = fdtdec_next_compatible(gd-fdt_blob, node,
+ COMPAT_SAMSUNG_PINCTRL)) {
+ /* Get the subnode from FDT for this peripheral*/
+ subnode = fdt_subnode_offset(gd-fdt_blob,
+ node, pingrp-dev_name);
+ if (subnode 0)
+ continue;
+
+ /* Get names of pins to be configured from fdt */
+ fprop = fdt_get_property(gd-fdt_blob,
+ subnode, samsung,pins, NULL);
Can you use fdt_getprop() here? Also you should check for a NULL return value.
+
+ /* Convert pin names to pin numbers */
+ pinmux_get_pin_numbers(fprop, pingrp);
Re: [U-Boot] [PATCH] video: Fix splash screen alignment
On Fri, Feb 15, 2013 at 5:35 AM, Matthias Weisser weiss...@arcor.de wrote: commit d484b52 video: Skip bitmaps which do not fit into the screen in cfb_console breaks splash screen alignment which is passed in as magic (BMP_ALIGN_CENTER) x/y coordinates. Moving the check after the alignment block fixes this. Signed-off-by: Matthias Weisser weiss...@arcor.de Acked-by: Simon Glass s...@chromium.org --- drivers/video/cfb_console.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c index 26f673a..61e1058 100644 --- a/drivers/video/cfb_console.c +++ b/drivers/video/cfb_console.c @@ -1515,13 +1515,6 @@ int video_display_bitmap(ulong bmp_image, int x, int y) padded_line = (((width * bpp + 7) / 8) + 3) ~0x3; - /* -* Just ignore elements which are completely beyond screen -* dimensions. -*/ - if ((x = VIDEO_VISIBLE_COLS) || (y = VIDEO_VISIBLE_ROWS)) - return 0; - #ifdef CONFIG_SPLASH_SCREEN_ALIGN if (x == BMP_ALIGN_CENTER) x = max(0, (VIDEO_VISIBLE_COLS - width) / 2); @@ -1534,6 +1527,13 @@ int video_display_bitmap(ulong bmp_image, int x, int y) y = max(0, VIDEO_VISIBLE_ROWS - height + y + 1); #endif /* CONFIG_SPLASH_SCREEN_ALIGN */ + /* +* Just ignore elements which are completely beyond screen +* dimensions. +*/ + if ((x = VIDEO_VISIBLE_COLS) || (y = VIDEO_VISIBLE_ROWS)) + return 0; + if ((x + width) VIDEO_VISIBLE_COLS) width = VIDEO_VISIBLE_COLS - x; if ((y + height) VIDEO_VISIBLE_ROWS) -- 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] EXYNOS5: FDT: Add compatible strings for Serial
Hi
On Tue, Feb 26, 2013 at 10:01 PM, Rajeshwari Shinde
rajeshwar...@samsung.com wrote:
Add required compatible information for s5p serial driver
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
include/fdtdec.h |1 +
lib/fdtdec.c |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 77f244f..cca9be1 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -81,6 +81,7 @@ enum fdt_compat_id {
COMPAT_SAMSUNG_EXYNOS_EHCI, /* Exynos EHCI controller */
COMPAT_SAMSUNG_EXYNOS_USB_PHY, /* Exynos phy controller for usb2.0 */
COMPAT_MAXIM_MAX77686_PMIC, /* MAX77686 PMIC */
+ COMPAT_SAMSUNG_EXYNOS5_SERIAL, /* Exynos5 UART */
COMPAT_COUNT,
};
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 3ae348d..ec19c4b 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -56,6 +56,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
COMPAT(SAMSUNG_EXYNOS_EHCI, samsung,exynos-ehci),
COMPAT(SAMSUNG_EXYNOS_USB_PHY, samsung,exynos-usb-phy),
COMPAT(MAXIM_MAX77686_PMIC, maxim,max77686_pmic),
+ COMPAT(SAMSUNG_EXYNOS5_SERIAL, samsung,exynos-uart),
The kernel seems to have this:
serial@12C0 {
compatible = samsung,exynos4210-uart;
reg = 0x12C0 0x100;
interrupts = 0 51 0;
};
Should we use the same compatible string in U-Boot, or are you
planning the change the kernel?
Regards,
Simon
};
const char *fdtdec_get_compatible(enum fdt_compat_id id)
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 46/58] avr32: Use generic global_data
Hi, On Thu, Feb 14, 2013 at 8:15 AM, Tom Rini tr...@ti.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/14/2013 11:11 AM, Andreas Biemann wrote: Hi Simon, On 02/14/2013 03:25 PM, Simon Glass wrote: Hi Andreas, On Thu, Feb 14, 2013 at 2:29 AM, Andreas Biemann andreas.de...@googlemail.com wrote: Dear Simon Glass, On 12/14/2012 07:49 AM, Simon Glass wrote: Move avr32 over to use generic global_data. Signed-off-by: Simon Glass s...@chromium.org this one produces compile warning in board.c for mimc200, I will try to fix it but can not test it on real hardware (cc'ing board maintainer). Actually these boards failed for be even before the patch: avr32: + hammerhead + atngw100mkii + grasshopper + favr-32-ezkit + atstk1006 + atstk1004 + atstk1003 + atstk1002 + atngw100 + mimc200 It might be my toolchain - can you suggest an avr32 toolchain to use? Not currently, I use a self patched OSELAS toolchain which is not yet mainline. Maybe I should try to add avr32 toolchain to ELDK for reference? The short answer is that if OpenEmbedded supports avr32 (and I'm a little rusty, but I see general avr32 bits and pieces) then yes, taking ELDK and building for AVR32 should be doable, or at least provide an interesting failure :) Well if someone can point me to a binary or a build script I would very much like to get an avr32 toolchain that fully works. Thanks, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] S5P: Serial: Add fdt support to driver
On Tue, Feb 26, 2013 at 10:01 PM, Rajeshwari Shinde rajeshwar...@samsung.com wrote: This patch adds FDT support to the serial s5p driver. At present disabling the serial console (from the device tree) crashes U-Boot. Add checks for this case, so that execution can continue without a serial console. It also enables the serial_s5p driver recognize the silent_console option. Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com Signed-off-by: Gabe Black gabebl...@google.com Signed-off-by: Simon Glass s...@chromium.org Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com Acked-by: Simon Glass s...@chromium.org --- drivers/serial/serial_s5p.c | 80 +++ 1 files changed, 80 insertions(+), 0 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] CONFIG: EXYNOS5: Enable silent console
On Tue, Feb 26, 2013 at 10:01 PM, Rajeshwari Shinde rajeshwar...@samsung.com wrote: This patch enables CONFIG_SILENT_CONSOLE for EXYNOS5. Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com Acked-by: Simon Glass s...@chromium.org --- include/configs/exynos5250-dt.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h index cabd2f2..3bf7d1b 100644 --- a/include/configs/exynos5250-dt.h +++ b/include/configs/exynos5250-dt.h @@ -85,6 +85,8 @@ stdout=serial,lcd\0 \ stderr=serial,lcd\0 +#define CONFIG_SILENT_CONSOLE + #define CONFIG_EXTRA_ENV_SETTINGS \ EXYNOS_DEVICE_SETTINGS -- 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 1/9] Exynos: Change get_timer() to work correctly
On Wed, Feb 27, 2013 at 2:02 AM, Akshay Saraswat aksha...@samsung.com wrote:
At present get_timer() does not return sane values. It should count up
smoothly in milliscond intervals.
We can change the PWM to count down at 1MHz, providing a resolution
of 1us and a range of about an hour between required get_timer() calls.
TEST=sf probe 1:0; time sf read 40008000 0 1000
Try with different numbers of bytes and see that sane values are obtained
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Akshay Saraswat aksha...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
arch/arm/cpu/armv7/s5p-common/pwm.c | 6 ++
arch/arm/cpu/armv7/s5p-common/timer.c | 100
+-
2 files changed, 44 insertions(+), 62 deletions(-)
diff --git a/arch/arm/cpu/armv7/s5p-common/pwm.c
b/arch/arm/cpu/armv7/s5p-common/pwm.c
index 44d7bc3..3147f59 100644
--- a/arch/arm/cpu/armv7/s5p-common/pwm.c
+++ b/arch/arm/cpu/armv7/s5p-common/pwm.c
@@ -174,6 +174,12 @@ int pwm_init(int pwm_id, int div, int invert)
/* set count value */
offset = pwm_id * 3;
+
+ /*
+* TODO(sjg): Use this as a countdown timer for now. We count down
+* from the maximum value to 0, then reset.
+*/
+ timer_rate_hz = -1;
writel(timer_rate_hz, pwm-tcntb0 + offset);
val = readl(pwm-tcon) ~(0xf TCON_OFFSET(pwm_id));
diff --git a/arch/arm/cpu/armv7/s5p-common/timer.c
b/arch/arm/cpu/armv7/s5p-common/timer.c
index e78c716..c48a297 100644
--- a/arch/arm/cpu/armv7/s5p-common/timer.c
+++ b/arch/arm/cpu/armv7/s5p-common/timer.c
@@ -39,13 +39,33 @@ static inline struct s5p_timer *s5p_get_base_timer(void)
return (struct s5p_timer *)samsung_get_base_timer();
}
+/**
+ * Read the countdown timer.
+ *
+ * This operates at 1MHz and counts downwards. It will wrap about every
+ * hour (2^32 microseconds).
+ *
+ * @return current value of timer
+ */
+static unsigned long timer_get_us_down(void)
+{
+ struct s5p_timer *const timer = s5p_get_base_timer();
+
+ return readl(timer-tcnto4);
+}
+
int timer_init(void)
{
/* PWM Timer 4 */
- pwm_init(4, MUX_DIV_2, 0);
+ pwm_init(4, MUX_DIV_4, 0);
pwm_config(4, 0, 0);
pwm_enable(4);
+ /* Use this as the current monotonic time in us */
+ gd-arch.timer_reset_value = 0;
+
+ /* Use this as the last timer value we saw */
+ gd-arch.lastinc = timer_get_us_down();
reset_timer_masked();
return 0;
@@ -56,48 +76,28 @@ int timer_init(void)
*/
unsigned long get_timer(unsigned long base)
{
- return get_timer_masked() - base;
+ ulong now = timer_get_us_down();
+
+ /*
+* Increment the time by the amount elapsed since the last read.
+* The timer may have wrapped around, but it makes no difference to
+* our arithmetic here.
+*/
+ gd-arch.timer_reset_value += gd-arch.lastinc - now;
+ gd-arch.lastinc = now;
+
+ /* Divide by 1000 to convert from us to ms */
+ return gd-arch.timer_reset_value / 1000 - base;
}
/* delay x useconds */
void __udelay(unsigned long usec)
{
- struct s5p_timer *const timer = s5p_get_base_timer();
- unsigned long tmo, tmp, count_value;
-
- count_value = readl(timer-tcntb4);
-
- if (usec = 1000) {
- /*
-* if big number, spread normalization
-* to seconds
-* 1. start to normalize for usec to ticks per sec
-* 2. find number of ticks to wait to achieve target
-* 3. finish normalize.
-*/
- tmo = usec / 1000;
- tmo *= (CONFIG_SYS_HZ * count_value);
- tmo /= 1000;
- } else {
- /* else small number, don't kill it prior to HZ multiply */
- tmo = usec * CONFIG_SYS_HZ * count_value;
- tmo /= (1000 * 1000);
- }
-
- /* get current timestamp */
- tmp = get_current_tick();
-
- /* if setting this fordward will roll time stamp */
- /* reset advancing timestamp to 0, set lastinc value */
- /* else, set advancing stamp wake up time */
- if ((tmo + tmp + 1) tmp)
- reset_timer_masked();
- else
- tmo += tmp;
-
- /* loop till event */
- while (get_current_tick() tmo)
- ; /* nop */
+ unsigned long count_value;
+
+ count_value = timer_get_us_down();
+ while ((int)(count_value - timer_get_us_down()) (int)usec)
+ ;
}
void reset_timer_masked(void)
@@ -109,30 +109,6 @@ void reset_timer_masked(void)
gd-arch.tbl = 0;
}
-unsigned long get_timer_masked(void)
-{
- struct s5p_timer *const timer = s5p_get_base_timer();
- unsigned long count_value =
Re: [U-Boot] [PATCH 2/9] Exynos: Add timer_get_us function
On Wed, Feb 27, 2013 at 2:02 AM, Akshay Saraswat aksha...@samsung.com wrote:
timer_get_us returns the time in microseconds since a certain reference
point of history. However, it does not guarantee to return an accurate
time after a long period; instead, it wraps around (that is, the
reference point is reset to some other point of history) after some
periods. The frequency of wrapping around is about an hour (or 2^32
microseconds).
TEST=sf probe 1:0; time sf read 40008000 0 1000
Try with different numbers of bytes and see that sane values are obtained
Signed-off-by: Che-Liang Chiou clch...@chromium.org
Signed-off-by: Akshay Saraswat aksha...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
arch/arm/cpu/armv7/s5p-common/timer.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/cpu/armv7/s5p-common/timer.c
b/arch/arm/cpu/armv7/s5p-common/timer.c
index c48a297..de61405 100644
--- a/arch/arm/cpu/armv7/s5p-common/timer.c
+++ b/arch/arm/cpu/armv7/s5p-common/timer.c
@@ -90,6 +90,21 @@ unsigned long get_timer(unsigned long base)
return gd-arch.timer_reset_value / 1000 - base;
}
+unsigned long timer_get_us(void)
+{
+ static unsigned long base_time_us;
+
+ struct s5p_timer *const timer =
+ (struct s5p_timer *)samsung_get_base_timer();
+ unsigned long now_downward_us = readl(timer-tcnto4);
+
+ if (!base_time_us)
+ base_time_us = now_downward_us;
+
+ /* Note that this timer counts downward. */
+ return base_time_us - now_downward_us;
+}
+
/* delay x useconds */
void __udelay(unsigned long usec)
{
--
1.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Exynos: Add hardware accelerated SHA 256
On Wed, 27 Feb 2013 10:24:39 -0500
Akshay Saraswat aksha...@samsung.com wrote:
SHA-256 and SHA-1 accelerated using ACE hardware.
TEST=sha256 0x40008000 0x2B 0x40009000
Used mm and md to write a standard string to memory location
0x40008000 and ran the above command to verify the output.
can we get rid of this TEST= infrastructure format? It's not used
on upstream u-boot.
Signed-off-by: ARUN MANKUZHI aru...@samsung.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
---
arch/arm/cpu/armv7/exynos/Makefile | 4 +
arch/arm/cpu/armv7/exynos/ace_sha.c| 118 +++
arch/arm/include/asm/arch-exynos/ace_sfr.h | 310
+
arch/arm/include/asm/arch-exynos/ace_sha.h | 41
arch/arm/include/asm/arch-exynos/cpu.h | 4 +
5 files changed, 477 insertions(+)
create mode 100644 arch/arm/cpu/armv7/exynos/ace_sha.c
create mode 100644 arch/arm/include/asm/arch-exynos/ace_sfr.h
create mode 100644 arch/arm/include/asm/arch-exynos/ace_sha.h
I doubt there's anything binding this to arch-exynos, and I bet the
h/w is going to be available - if not already - on some other parts,
so it probably belongs in a new drivers/crypto directory.
+/* Maximum input data size is 8 MB. Timeout observed for data size above 8MB
*/
+#define TIMEOUT_MS 100
So if there's a drop in processor frequency, the driver times out
too early? Not good.
+#define SHA1_DIGEST_LEN 20
+#define SHA256_DIGEST_LEN32
don't duplicate definitions that already exist in include/sha*.h.
+ if (buf_len == 0) {
+ /* ACE H/W cannot compute hash value for empty string */
+ if (hash_type == ACE_SHA_TYPE_SHA1)
+ memcpy(pout, sha1_digest_emptymsg, SHA1_DIGEST_LEN);
+ else
+ memcpy(pout, sha256_digest_emptymsg, SHA256_DIGEST_LEN);
+ return 0;
+ }
there's no protection from buf_len going over the h/w 8MB limit
mentioned above - why not fall back to the s/w implementation in
both those cases? Or, if the h/w can be programmed to perform
multiple hash updates in 8MB data chunks, add support to do that.
+ /* Read hash result */
+ pdigest = (unsigned int *)pout;
+ len = (hash_type == ACE_SHA_TYPE_SHA1) ? 5 : 8;
magic numbers - use SHAx_SUM_LEN / 4.
Kim
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/9] Exynos: pwm: Fix two bugs in the exynos pwm configuration code
On Wed, Feb 27, 2013 at 2:02 AM, Akshay Saraswat aksha...@samsung.com wrote:
First, the div value was being used incorrectly to compute the frequency of
the PWM timer. The value passed in is a constant which reflects the value
that would be found in a configuration register, 0 to 4. That should
correspond to a scaling factor of 1, 2, 4, 8, or 16, 1 div, but div + 1 was
being used instead.
Second, the reset value of the timers were being calculated to give an overall
frequency, thrown out, and set to a maximum value. This was done so that PWM 4
could be used as the system clock by counting down from a high value, but it
was applied indiscriminantly. It should at most be applied only to PWM 4.
This change also takes the opportunity to tidy up the pwm_init function.
TEST=sf probe 1:0; time sf read 40008000 0 1000
Try with different numbers of bytes and see that sane values are obtained
Build and boot U-boot with this patch, backlight works properly.
Signed-off-by: Gabe Black gabebl...@google.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
Acked-by: Simon Glass s...@chromium.org
If you redo this patch, I suggest you remove the TODOs.
---
arch/arm/cpu/armv7/s5p-common/pwm.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/arch/arm/cpu/armv7/s5p-common/pwm.c
b/arch/arm/cpu/armv7/s5p-common/pwm.c
index 3147f59..02156d1 100644
--- a/arch/arm/cpu/armv7/s5p-common/pwm.c
+++ b/arch/arm/cpu/armv7/s5p-common/pwm.c
@@ -143,7 +143,7 @@ int pwm_init(int pwm_id, int div, int invert)
u32 val;
const struct s5p_timer *pwm =
(struct s5p_timer *)samsung_get_base_timer();
- unsigned long timer_rate_hz;
+ unsigned long ticks_per_period;
unsigned int offset, prescaler;
/*
@@ -167,20 +167,24 @@ int pwm_init(int pwm_id, int div, int invert)
val |= (div 0xf) MUX_DIV_SHIFT(pwm_id);
writel(val, pwm-tcfg1);
- timer_rate_hz = get_pwm_clk() / ((prescaler + 1) *
- (div + 1));
+ if (pwm_id == 4) {
+ /*
+* TODO(sjg): Use this as a countdown timer for now. We count
+* down from the maximum value to 0, then reset.
+*/
+ ticks_per_period = -1UL;
+ } else {
+ const unsigned long pwm_hz = 1000;
+ unsigned long timer_rate_hz = get_pwm_clk() /
+ ((prescaler + 1) * (1 div));
- timer_rate_hz = timer_rate_hz / CONFIG_SYS_HZ;
+ ticks_per_period = timer_rate_hz / pwm_hz;
+ }
/* set count value */
offset = pwm_id * 3;
- /*
-* TODO(sjg): Use this as a countdown timer for now. We count down
-* from the maximum value to 0, then reset.
-*/
- timer_rate_hz = -1;
- writel(timer_rate_hz, pwm-tcntb0 + offset);
+ writel(ticks_per_period, pwm-tcntb0 + offset);
val = readl(pwm-tcon) ~(0xf TCON_OFFSET(pwm_id));
if (invert (pwm_id 4))
--
1.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/9] Exynos: Avoid a divide by zero by specifying a non-zero period for pwm 4
On Wed, Feb 27, 2013 at 2:02 AM, Akshay Saraswat aksha...@samsung.com wrote:
The pwm_config function in the exynos pwm driver divides by its period
period parameter. A function was calling pwm_config with a 0ns period and a
0ns duty cycle. That doesn't actually make any sense physically, and results
in a divide by zero in the driver. This change changes the paremters to be a
10ns period and duty cycle.
TEST=sf probe 1:0; time sf read 40008000 0 1000
Try with different numbers of bytes and see that sane values are obtained
Build and boot U-boot with this patch, backlight works properly.
Signed-off-by: Gabe Black gabebl...@google.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
arch/arm/cpu/armv7/s5p-common/timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/s5p-common/timer.c
b/arch/arm/cpu/armv7/s5p-common/timer.c
index de61405..6a0fa58 100644
--- a/arch/arm/cpu/armv7/s5p-common/timer.c
+++ b/arch/arm/cpu/armv7/s5p-common/timer.c
@@ -58,7 +58,7 @@ int timer_init(void)
{
/* PWM Timer 4 */
pwm_init(4, MUX_DIV_4, 0);
- pwm_config(4, 0, 0);
+ pwm_config(4, 10, 10);
pwm_enable(4);
/* Use this as the current monotonic time in us */
--
1.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/9] Exynos: Tidy up the pwm_config function in the exynos pwm driver
On Wed, Feb 27, 2013 at 2:02 AM, Akshay Saraswat aksha...@samsung.com wrote:
Some small fixes in the exynos pwm driver:
1. NS_IN_HZ is non-sensical since these are not compatible units. This
constant actually describes the number of nanoseconds in a second. Renamed it
to NS_IN_SEC. Also dropped the unnecessary parenthesis.
2. The variable period is not used to hold a period, it's used to hold a
frequency. Renamed it to frequency.
3. tcmp is an unsigned value, so (tcmp 0) will never be true and the if
which checks that condition will never execute. Also, there should be no
problem if the pwm never switches, so there's no reason to subtract one from
tcmp and therefore no reason to compare it against zero. Removed both ifs. If
they weren't removed, tcmp should be a signed value.
4. Add a check for a 0 period.
TEST=sf probe 1:0; time sf read 40008000 0 1000
Try with different numbers of bytes and see that sane values are obtained
Build and boot U-boot with this patch, backlight works properly.
Signed-off-by: Gabe Black gabebl...@google.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
arch/arm/cpu/armv7/s5p-common/pwm.c | 22 ++
1 file changed, 6 insertions(+), 16 deletions(-)
diff --git a/arch/arm/cpu/armv7/s5p-common/pwm.c
b/arch/arm/cpu/armv7/s5p-common/pwm.c
index 02156d1..6f401b8 100644
--- a/arch/arm/cpu/armv7/s5p-common/pwm.c
+++ b/arch/arm/cpu/armv7/s5p-common/pwm.c
@@ -70,7 +70,7 @@ static unsigned long pwm_calc_tin(int pwm_id, unsigned long
freq)
return tin_parent_rate / 16;
}
-#define NS_IN_HZ (10UL)
+#define NS_IN_SEC 10UL
int pwm_config(int pwm_id, int duty_ns, int period_ns)
{
@@ -79,7 +79,7 @@ int pwm_config(int pwm_id, int duty_ns, int period_ns)
unsigned int offset;
unsigned long tin_rate;
unsigned long tin_ns;
- unsigned long period;
+ unsigned long frequency;
unsigned long tcon;
unsigned long tcnt;
unsigned long tcmp;
@@ -89,34 +89,24 @@ int pwm_config(int pwm_id, int duty_ns, int period_ns)
* fact that anything faster than 1GHz is easily representable
* by 32bits.
*/
- if (period_ns NS_IN_HZ || duty_ns NS_IN_HZ)
+ if (period_ns NS_IN_SEC || duty_ns NS_IN_SEC || period_ns == 0)
return -ERANGE;
if (duty_ns period_ns)
return -EINVAL;
- period = NS_IN_HZ / period_ns;
+ frequency = NS_IN_SEC / period_ns;
/* Check to see if we are changing the clock rate of the PWM */
- tin_rate = pwm_calc_tin(pwm_id, period);
+ tin_rate = pwm_calc_tin(pwm_id, frequency);
- tin_ns = NS_IN_HZ / tin_rate;
+ tin_ns = NS_IN_SEC / tin_rate;
tcnt = period_ns / tin_ns;
/* Note, counters count down */
tcmp = duty_ns / tin_ns;
tcmp = tcnt - tcmp;
- /*
-* the pwm hw only checks the compare register after a decrement,
-* so the pin never toggles if tcmp = tcnt
-*/
- if (tcmp == tcnt)
- tcmp--;
-
- if (tcmp 0)
- tcmp = 0;
-
/* Update the PWM register block. */
offset = pwm_id * 3;
if (pwm_id 4) {
--
1.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/9] Exynos: Add peripherial id for pwm
Hi Akshay,
On Wed, Feb 27, 2013 at 2:02 AM, Akshay Saraswat aksha...@samsung.com wrote:
Add peripherial id for pwm inorder to support
generic api to get the clk frequency
TEST=sf probe 1:0; time sf read 40008000 0 1000
Try with different numbers of bytes and see that sane values are obtained
Build and boot U-boot with this patch, backlight works properly.
Signed-off-by: Padmavathi Venna padm...@samsung.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
---
arch/arm/include/asm/arch-exynos/periph.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/include/asm/arch-exynos/periph.h
b/arch/arm/include/asm/arch-exynos/periph.h
index 89bcdfc..e5aed4b 100644
--- a/arch/arm/include/asm/arch-exynos/periph.h
+++ b/arch/arm/include/asm/arch-exynos/periph.h
@@ -61,6 +61,11 @@ enum periph_id {
PERIPH_ID_SPI3,
PERIPH_ID_SPI4,
PERIPH_ID_SDMMC4,
+ PERIPH_ID_PWM0,
+ PERIPH_ID_PWM1,
+ PERIPH_ID_PWM2,
+ PERIPH_ID_PWM3,
+ PERIPH_ID_PWM4,
I don't believe this file is used now.
Regards,
Simon
PERIPH_ID_COUNT,
PERIPH_ID_NONE = -1,
--
1.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] Exynos: Flush memory region before starting SHA DMA operation
On Wed, 27 Feb 2013 10:24:42 -0500 Akshay Saraswat aksha...@samsung.com wrote: SHA256 commands weren't giving desired output since the data we set in the memory addresses through mw.l commands was not getting updated in actual memory. Adding this patch resolves the issue. why not use the dcache flush command instead? Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/9] Exynos: clock: Add generic api to get the clk freq
Hi Akshay,
On Wed, Feb 27, 2013 at 2:02 AM, Akshay Saraswat aksha...@samsung.com wrote:
Add generic api to get the frequency of the required peripherial. This
API gets the source clock frequency and returns the required frequency
by dividing with first and second dividers based on the requirement.
TEST=sf probe 1:0; time sf read 40008000 0 1000
Try with different numbers of bytes and see that sane values are obtained
Build and boot U-boot with this patch, backlight works properly.
Please remove the TEST= stuff. patman might do the first line for you
(and will print a warning).
Signed-off-by: Padmavathi Venna padm...@samsung.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
---
arch/arm/cpu/armv7/exynos/clock.c | 127
+
arch/arm/include/asm/arch-exynos/clk.h | 27 +++
2 files changed, 154 insertions(+)
diff --git a/arch/arm/cpu/armv7/exynos/clock.c
b/arch/arm/cpu/armv7/exynos/clock.c
index 956427c..a7a3066 100644
--- a/arch/arm/cpu/armv7/exynos/clock.c
+++ b/arch/arm/cpu/armv7/exynos/clock.c
@@ -27,6 +27,39 @@
#include asm/arch/clk.h
#include asm/arch/periph.h
+/* src_bit div_bit prediv_bit */
+static struct clk_bit_info clk_bit_info[PERIPH_ID_COUNT] = {
+ {0, 0, -1},
+ {4, 4, -1},
+ {8, 8, -1},
+ {12,12, -1},
+ {0, 0, 8},
+ {4, 16, 24},
+ {8, 0, 8},
+ {12,16, 24},
+ {-1,-1, -1},
+ {16,0, 8},
+ {20,16, 24},
+ {24,0, 8},
+ {0, 0, 4},
+ {4, 12, 16},
+ {-1,-1, -1},
+ {-1,-1, -1},
+ {-1,24, 0},
+ {-1,24, 0},
+ {-1,24, 0},
+ {-1,24, 0},
+ {-1,24, 0},
+ {-1,24, 0},
+ {-1,24, 0},
+ {-1,24, 0},
+ {24,0, -1},
+ {24,0, -1},
+ {24,0, -1},
+ {24,0, -1},
+ {24,0, -1},
+};
+
/* Epll Clock division values to achive different frequency output */
static struct set_epll_con_val exynos5_epll_div[] = {
{ 19200, 0, 48, 3, 1, 0 },
@@ -201,6 +234,100 @@ static unsigned long exynos5_get_pll_clk(int pllreg)
return fout;
}
+unsigned long exynos5_get_periph_rate(enum periph_id peripheral)
+{
+ struct clk_bit_info *bit_info = clk_bit_info[peripheral];
+ unsigned long sclk, sub_clk;
+ unsigned int src, div, sub_div;
+ struct exynos5_clock *clk =
+ (struct exynos5_clock *)samsung_get_base_clock();
+
+ switch (peripheral) {
+ case PERIPH_ID_UART0:
+ case PERIPH_ID_UART1:
+ case PERIPH_ID_UART2:
+ case PERIPH_ID_UART3:
+ src = readl(clk-src_peric0);
+ div = readl(clk-div_peric0);
+ break;
+ case PERIPH_ID_PWM0:
+ case PERIPH_ID_PWM1:
+ case PERIPH_ID_PWM2:
+ case PERIPH_ID_PWM3:
+ case PERIPH_ID_PWM4:
+ src = readl(clk-src_peric0);
+ div = readl(clk-div_peric3);
+ break;
+ case PERIPH_ID_SPI0:
+ case PERIPH_ID_SPI1:
+ src = readl(clk-src_peric1);
+ div = readl(clk-div_peric1);
+ break;
+ case PERIPH_ID_SPI2:
+ src = readl(clk-src_peric1);
+ div = readl(clk-div_peric2);
+ break;
+ case PERIPH_ID_SPI3:
+ case PERIPH_ID_SPI4:
+ src = readl(clk-sclk_src_isp);
+ div = readl(clk-sclk_div_isp);
+ break;
+ case PERIPH_ID_SDMMC0:
+ case PERIPH_ID_SDMMC1:
+ case PERIPH_ID_SDMMC2:
+ case PERIPH_ID_SDMMC3:
+ src = readl(clk-src_fsys);
+ div = readl(clk-div_fsys1);
+ break;
+ case PERIPH_ID_I2C0:
+ case PERIPH_ID_I2C1:
+ case PERIPH_ID_I2C2:
+ case PERIPH_ID_I2C3:
+ case PERIPH_ID_I2C4:
+ case PERIPH_ID_I2C5:
+ case PERIPH_ID_I2C6:
+ case PERIPH_ID_I2C7:
+ sclk = exynos5_get_pll_clk(MPLL);
+ sub_div = ((readl(clk-div_top1) bit_info-div_bit)
0x7) + 1;
+ div = ((readl(clk-div_top0) bit_info-prediv_bit) 0x7)
+ 1;
+ return (sclk / sub_div) / div;
+ default:
+ debug(%s: invalid peripheral %d, __func__, peripheral);
+ return -1;
+ };
+
+ src = (src bit_info-src_bit) 0xf;
+ if (src == SRC_MPLL)
+ sclk = exynos5_get_pll_clk(MPLL);
+ else if (src == SRC_EPLL)
+ sclk = exynos5_get_pll_clk(EPLL);
+ else if (src == SRC_VPLL)
+ sclk = exynos5_get_pll_clk(VPLL);
+ else
+ return 0;
+
+ sub_div =
Re: [U-Boot] [PATCH 9/9] Exynos: pwm: Use generic api to get pwm clk freq
On Wed, Feb 27, 2013 at 2:02 AM, Akshay Saraswat aksha...@samsung.com wrote:
Use generic api to get the pwm clock frequency
TEST=sf probe 1:0; time sf read 40008000 0 1000
Try with different numbers of bytes and see that sane values are obtained
Build and boot U-boot with this patch, backlight works properly.
Signed-off-by: Padmavathi Venna padm...@samsung.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
arch/arm/cpu/armv7/s5p-common/pwm.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/cpu/armv7/s5p-common/pwm.c
b/arch/arm/cpu/armv7/s5p-common/pwm.c
index 6f401b8..06e0351 100644
--- a/arch/arm/cpu/armv7/s5p-common/pwm.c
+++ b/arch/arm/cpu/armv7/s5p-common/pwm.c
@@ -28,6 +28,7 @@
#include asm/io.h
#include asm/arch/pwm.h
#include asm/arch/clk.h
+#include asm/arch/periph.h
int pwm_enable(int pwm_id)
{
@@ -60,7 +61,7 @@ static unsigned long pwm_calc_tin(int pwm_id, unsigned long
freq)
unsigned long tin_parent_rate;
unsigned int div;
- tin_parent_rate = get_pwm_clk();
+ tin_parent_rate = clock_get_periph_rate(PERIPH_ID_PWM0);
for (div = 2; div = 16; div *= 2) {
if ((tin_parent_rate / (div 16)) freq)
@@ -165,8 +166,8 @@ int pwm_init(int pwm_id, int div, int invert)
ticks_per_period = -1UL;
} else {
const unsigned long pwm_hz = 1000;
- unsigned long timer_rate_hz = get_pwm_clk() /
- ((prescaler + 1) * (1 div));
+ unsigned long timer_rate_hz = clock_get_periph_rate(
+ PERIPH_ID_PWM0) / ((prescaler + 1) * (1 div));
ticks_per_period = timer_rate_hz / pwm_hz;
}
--
1.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4] mxs: timrot: Add support to i.MX23
From: Fadil Berisha f.kol...@gmail.com
This patch add timer support to i.MX23 and complete bit fields and values
on regs-timrot.h.
Testet on imx23-olinuxino board.
Signed-off-by: Fadil Berisha f.kol...@gmail.com
Acked-by: Marek Vasut ma...@denx.de
Cc: Marek Vasut ma...@denx.de
Cc: Otavio Salvador ota...@ossystems.com.br
Cc: Fabio Estevam fabio.este...@freescale.com
Cc: Stefano Babic sba...@denx.de
---
v2 - Updated the struct mxs_timrot_regs so the mapping works for all registers
v3 - Revert macro MX28_INCREMENTER_HZ, MX28_HW_DIGCTL_MICROSECONDS and fix
whitespaces
v4 - Fixed comment and style corrections
arch/arm/cpu/arm926ejs/mxs/timer.c | 23 +-
arch/arm/include/asm/arch-mxs/regs-timrot.h | 101 +++
2 files changed, 122 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/timer.c
b/arch/arm/cpu/arm926ejs/mxs/timer.c
index 4ed75e6..fc0a2af 100644
--- a/arch/arm/cpu/arm926ejs/mxs/timer.c
+++ b/arch/arm/cpu/arm926ejs/mxs/timer.c
@@ -32,7 +32,11 @@
#include asm/arch/sys_proto.h
/* Maximum fixed count */
-#define TIMER_LOAD_VAL 0x
+#if defined(CONFIG_MX23)
+#define TIMER_LOAD_VAL 0x
+#elif defined(CONFIG_MX28)
+#define TIMER_LOAD_VAL 0x
+#endif
DECLARE_GLOBAL_DATA_PTR;
@@ -69,7 +73,11 @@ int timer_init(void)
mxs_reset_block(timrot_regs-hw_timrot_rotctrl_reg);
/* Set fixed_count to 0 */
+#if defined(CONFIG_MX23)
+ writel(0, timrot_regs-hw_timrot_timcount0);
+#elif defined(CONFIG_MX28)
writel(0, timrot_regs-hw_timrot_fixed_count0);
+#endif
/* Set UPDATE bit and 1Khz frequency */
writel(TIMROT_TIMCTRLn_UPDATE | TIMROT_TIMCTRLn_RELOAD |
@@ -77,7 +85,11 @@ int timer_init(void)
timrot_regs-hw_timrot_timctrl0);
/* Set fixed_count to maximal value */
+#if defined(CONFIG_MX23)
+ writel(TIMER_LOAD_VAL - 1, timrot_regs-hw_timrot_timcount0);
+#elif defined(CONFIG_MX28)
writel(TIMER_LOAD_VAL, timrot_regs-hw_timrot_fixed_count0);
+#endif
return 0;
}
@@ -86,9 +98,16 @@ unsigned long long get_ticks(void)
{
struct mxs_timrot_regs *timrot_regs =
(struct mxs_timrot_regs *)MXS_TIMROT_BASE;
+ uint32_t now;
/* Current tick value */
- uint32_t now = readl(timrot_regs-hw_timrot_running_count0);
+#if defined(CONFIG_MX23)
+ /* Upper bits are the valid ones. */
+ now = readl(timrot_regs-hw_timrot_timcount0)
+ TIMROT_RUNNING_COUNTn_RUNNING_COUNT_OFFSET;
+#elif defined(CONFIG_MX28)
+ now = readl(timrot_regs-hw_timrot_running_count0);
+#endif
if (lastdec = now) {
/*
diff --git a/arch/arm/include/asm/arch-mxs/regs-timrot.h
b/arch/arm/include/asm/arch-mxs/regs-timrot.h
index 529a3bc..f8537f1 100644
--- a/arch/arm/include/asm/arch-mxs/regs-timrot.h
+++ b/arch/arm/include/asm/arch-mxs/regs-timrot.h
@@ -31,6 +31,16 @@
struct mxs_timrot_regs {
mxs_reg_32(hw_timrot_rotctrl)
mxs_reg_32(hw_timrot_rotcount)
+#if defined(CONFIG_MX23)
+ mxs_reg_32(hw_timrot_timctrl0)
+ mxs_reg_32(hw_timrot_timcount0)
+ mxs_reg_32(hw_timrot_timctrl1)
+ mxs_reg_32(hw_timrot_timcount1)
+ mxs_reg_32(hw_timrot_timctrl2)
+ mxs_reg_32(hw_timrot_timcount2)
+ mxs_reg_32(hw_timrot_timctrl3)
+ mxs_reg_32(hw_timrot_timcount3)
+#elif defined(CONFIG_MX28)
mxs_reg_32(hw_timrot_timctrl0)
mxs_reg_32(hw_timrot_running_count0)
mxs_reg_32(hw_timrot_fixed_count0)
@@ -47,6 +57,7 @@ struct mxs_timrot_regs {
mxs_reg_32(hw_timrot_running_count3)
mxs_reg_32(hw_timrot_fixed_count3)
mxs_reg_32(hw_timrot_match_count3)
+#endif
mxs_reg_32(hw_timrot_version)
};
#endif
@@ -71,7 +82,11 @@ struct mxs_timrot_regs {
#defineTIMROT_ROTCTRL_OVERSAMPLE_1X(0x3 10)
#defineTIMROT_ROTCTRL_POLARITY_B (1 9)
#defineTIMROT_ROTCTRL_POLARITY_A (1 8)
+#if defined(CONFIG_MX23)
+#defineTIMROT_ROTCTRL_SELECT_B_MASK(0x7 4)
+#elif defined(CONFIG_MX28)
#defineTIMROT_ROTCTRL_SELECT_B_MASK(0xf 4)
+#endif
#defineTIMROT_ROTCTRL_SELECT_B_OFFSET 4
#defineTIMROT_ROTCTRL_SELECT_B_NEVER_TICK (0x0 4)
#defineTIMROT_ROTCTRL_SELECT_B_PWM0(0x1 4)
@@ -79,12 +94,21 @@ struct mxs_timrot_regs {
#defineTIMROT_ROTCTRL_SELECT_B_PWM2(0x3 4)
#defineTIMROT_ROTCTRL_SELECT_B_PWM3(0x4 4)
#defineTIMROT_ROTCTRL_SELECT_B_PWM4(0x5 4)
+#if defined(CONFIG_MX23)
+#defineTIMROT_ROTCTRL_SELECT_B_ROTARYA (0x6 4)
+#defineTIMROT_ROTCTRL_SELECT_B_ROTARYB (0x7 4)
+#elif defined(CONFIG_MX28)
#defineTIMROT_ROTCTRL_SELECT_B_PWM5(0x6 4)
#define
