[U-Boot] [PATCH 3/4] OMAP3: twister: add video support
Signed-off-by: Stefano Babic
---
board/technexion/twister/twister.c | 49
include/configs/twister.h | 10
2 files changed, 59 insertions(+)
diff --git a/board/technexion/twister/twister.c
b/board/technexion/twister/twister.c
index b927586..c1281b9 100644
--- a/board/technexion/twister/twister.c
+++ b/board/technexion/twister/twister.c
@@ -25,12 +25,15 @@
#include
#include
+#include
+#include
#include
#include
#include
#include
#include
#include
+#include
#include
#include
#ifdef CONFIG_USB_EHCI
@@ -39,8 +42,23 @@
#endif
#include "twister.h"
+#define XRES 480
+#define YRES 272
+
DECLARE_GLOBAL_DATA_PTR;
+static GraphicDevice panel;
+static const struct panel_config lcd_cfg = {
+ .timing_h = 0x01101d1b, /* Horizontal timing */
+ .timing_v = 0x01400b02, /* Vertical timing */
+ .pol_freq = 0x00023000, /* Pol Freq */
+ .divisor= 0x0001000d, /* 33Mhz Pixel Clock */
+ .lcd_size = ((YRES - 1) << 16 | (XRES - 1)),
+ .panel_type = 0x01, /* TFT */
+ .data_lines = 0x03, /* 24 Bit RGB */
+ .load_mode = 0x02 /* Frame Mode */
+};
+
/* Timing definitions for Ethernet Controller */
static const u32 gpmc_smc911[] = {
NET_GPMC_CONFIG1,
@@ -135,6 +153,37 @@ int board_mmc_init(bd_t *bis)
{
return omap_mmc_init(0);
}
+
+void *video_hw_init(void)
+{
+
+ void *fb;
+ u32 size;
+
+ size = XRES * YRES * lcd_cfg.data_lines;
+ fb = malloc(size);
+ if (!fb) {
+ printf("Frame buffer not allocated\n");
+ return NULL;
+ }
+
+ panel.winSizeX = XRES;
+ panel.winSizeY = YRES;
+ panel.plnSizeX = XRES;
+ panel.plnSizeY = YRES;
+
+ panel.frameAdrs = (u32)fb;
+ panel.memSize = size;
+
+ panel.gdfBytesPP = 2;
+ panel.gdfIndex = GDF_16BIT_565RGB;
+
+ omap3_dss_panel_config(&lcd_cfg);
+ omap3_dss_enable();
+ omap3_dss_setfb(fb);
+
+ return (void *)&panel;
+}
#endif
#ifdef CONFIG_SPL_OS_BOOT
diff --git a/include/configs/twister.h b/include/configs/twister.h
index a852481..fb96f30 100644
--- a/include/configs/twister.h
+++ b/include/configs/twister.h
@@ -48,6 +48,16 @@
#define CONFIG_SMC911X_BASE0x2C00
#define CONFIG_SMC911X_NO_EEPROM
+#define CONFIG_VIDEO
+#define CONFIG_CFB_CONSOLE
+#define CONFIG_VGA_AS_SINGLE_DEVICE
+#define CONFIG_SPLASH_SCREEN
+#define CONFIG_VIDEO_LOGO
+#define CONFIG_VIDEO_BMP_RLE8
+#define CONFIG_CMD_BMP
+#define CONFIG_VIDEO_OMAP3 /* DSS Support */
+#define CONFIG_SYS_CONSOLE_IS_IN_ENV
+
#defineCONFIG_EXTRA_ENV_SETTINGS CONFIG_TAM3517_SETTINGS \
"bootcmd=run nandboot\0"
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] video: omap3_dss: add setup for LCD
Signed-off-by: Stefano Babic
---
arch/arm/include/asm/arch-omap3/dss.h | 23 ---
drivers/video/omap3_dss.c | 40 -
2 files changed, 59 insertions(+), 4 deletions(-)
diff --git a/arch/arm/include/asm/arch-omap3/dss.h
b/arch/arm/include/asm/arch-omap3/dss.h
index 4c56e5e..911cc9a 100644
--- a/arch/arm/include/asm/arch-omap3/dss.h
+++ b/arch/arm/include/asm/arch-omap3/dss.h
@@ -60,6 +60,17 @@ struct dispc_regs {
u32 global_alpha; /* 0x74 */
u32 size_dig; /* 0x78 */
u32 size_lcd; /* 0x7C */
+ u32 gfx_base[2];
+ u32 gfx_position; /* 0x88 */
+ u32 gfx_size; /* 0x8C */
+ u32 reserved_3[4]; /* 0x90 */
+ u32 gfx_attributes; /* 0xA0 */
+ u32 gfx_fifo_threshold; /* 0xA4 */
+ u32 gfx_fifo_size_status; /* 0xA8 */
+ u32 gfx_row_inc;/* 0xAC */
+ u32 gfx_pixel_inc; /* 0xB0 */
+ u32 gfx_window_skip;/* 0xB4 */
+ u32 gfx_table_ba; /* 0xB8 */
};
/* VENC Registers */
@@ -120,6 +131,7 @@ struct venc_regs {
/* Few Register Offsets */
#define FRAME_MODE_SHIFT 1
+#define FUNC_GATED_SHIFT 9
#define TFTSTN_SHIFT 3
#define DATALINES_SHIFT8
@@ -132,13 +144,16 @@ struct venc_regs {
#define GP_OUT1(1 << 16)
#define DISPC_ENABLE (LCD_ENABLE | \
-DIG_ENABLE | \
GO_LCD | \
-GO_DIG | \
GP_OUT0| \
GP_OUT1)
-/* Configure VENC DSS Params */
+#define DISPC_PCK_FREE_ENABLE (1 << 27)
+
+/* Register DSS_CONTROL */
+#define DISPC_CLK_SWITCH (1 << 0)
+#define DSI_CLK_SWITCH (1 << 1)
+#define VENC_CLOCK_MODE(1 << 2)
#define VENC_CLK_ENABLE(1 << 3)
#define DAC_DEMEN (1 << 4)
#define DAC_POWERDN(1 << 5)
@@ -148,6 +163,7 @@ struct venc_regs {
DAC_DEMEN | \
DAC_POWERDN | \
VENC_OUT_SEL)
+
/*
* Panel Configuration
*/
@@ -170,5 +186,6 @@ void omap3_dss_venc_config(const struct venc_regs *venc_cfg,
u32 height, u32 width);
void omap3_dss_panel_config(const struct panel_config *panel_cfg);
void omap3_dss_enable(void);
+void omap3_dss_setfb(void *addr);
#endif /* DSS_H */
diff --git a/drivers/video/omap3_dss.c b/drivers/video/omap3_dss.c
index b322cc3..6e5849a 100644
--- a/drivers/video/omap3_dss.c
+++ b/drivers/video/omap3_dss.c
@@ -28,6 +28,8 @@
#include
#include
#include
+#include
+#include
/*
* Configure VENC for a given Mode (NTSC / PAL)
@@ -105,16 +107,43 @@ void omap3_dss_venc_config(const struct venc_regs
*venc_cfg,
void omap3_dss_panel_config(const struct panel_config *panel_cfg)
{
struct dispc_regs *dispc = (struct dispc_regs *) OMAP3_DISPC_BASE;
+ struct dss_regs *dss = (struct dss_regs *) OMAP3_DSS_BASE;
writel(panel_cfg->timing_h, &dispc->timing_h);
writel(panel_cfg->timing_v, &dispc->timing_v);
writel(panel_cfg->pol_freq, &dispc->pol_freq);
writel(panel_cfg->divisor, &dispc->divisor);
writel(panel_cfg->lcd_size, &dispc->size_lcd);
- writel((panel_cfg->load_mode << FRAME_MODE_SHIFT), &dispc->config);
+ writel((panel_cfg->load_mode << FRAME_MODE_SHIFT) |
+ (1 << FUNC_GATED_SHIFT),
+ &dispc->config);
writel(((panel_cfg->panel_type << TFTSTN_SHIFT) |
(panel_cfg->data_lines << DATALINES_SHIFT)), &dispc->control);
writel(panel_cfg->panel_color, &dispc->default_color0);
+
+ writel(panel_cfg->lcd_size, &dispc->gfx_size);
+ writel(0x91, &dispc->gfx_attributes);
+ writel(0x01, &dispc->gfx_row_inc);
+ writel(0x01, &dispc->gfx_pixel_inc);
+ writel(0x00, &dispc->gfx_window_skip);
+
+ writel(VENC_CLK_ENABLE | DAC_DEMEN,
+ &dss->control);
+
+}
+
+void omap3_dss_clock_enable(int enable)
+{
+ struct prcm *prcm_base = (struct prcm *)PRCM_BASE;
+
+ if (enable) {
+ setbits_le32(&prcm_base->fclken_dss, FCK_DSS_ON);
+ setbits_le32(&prcm_base->iclken_dss, ICK_DSS_ON);
+ } else {
+ clrbits_le32(&prcm_base->fcl
[U-Boot] [PATCH 2/4] OMAP3: added clock definitions for OMAP3 DSS driver
Signed-off-by: Stefano Babic --- arch/arm/include/asm/arch-omap3/clocks.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/include/asm/arch-omap3/clocks.h b/arch/arm/include/asm/arch-omap3/clocks.h index bed0002..ab7b703 100644 --- a/arch/arm/include/asm/arch-omap3/clocks.h +++ b/arch/arm/include/asm/arch-omap3/clocks.h @@ -36,7 +36,7 @@ #define ICK_CORE2_ON 0x001f #define FCK_WKUP_ON0x00e9 #define ICK_WKUP_ON0x003f -#define FCK_DSS_ON 0x0005 +#define FCK_DSS_ON 0x0007 #define ICK_DSS_ON 0x0001 #define FCK_CAM_ON 0x0001 #define ICK_CAM_ON 0x0001 -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] OMAP3: mt_ventoux: add video/ splashscreen support
Signed-off-by: Stefano Babic
---
board/teejet/mt_ventoux/mt_ventoux.c | 63 ++
board/teejet/mt_ventoux/mt_ventoux.h |2 +-
include/configs/mt_ventoux.h | 17 +
3 files changed, 81 insertions(+), 1 deletion(-)
diff --git a/board/teejet/mt_ventoux/mt_ventoux.c
b/board/teejet/mt_ventoux/mt_ventoux.c
index c5eb42c..ecf91f7 100644
--- a/board/teejet/mt_ventoux/mt_ventoux.c
+++ b/board/teejet/mt_ventoux/mt_ventoux.c
@@ -21,13 +21,16 @@
#include
#include
+#include
#include
+#include
#include
#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -50,6 +53,28 @@ DECLARE_GLOBAL_DATA_PTR;
#define FPGA_INIT 119
#define FPGA_DONE 154
+#define LCD_PWR138
+#define LCD_PON_PIN139
+#define XRES 480
+#define YRES 272
+
+static const struct panel_config lcd_cfg = {
+
+ .timing_h = ((4 /* hpb */ - 1) << 20) |
+ ((8 /*hfp */- 1) << 8) |
+ (41 /* hsw */ - 1), /* Horizontal timing */
+ .timing_v = (2 /*vbp */ << 24) |
+ (4 /* vfp */ << 8) |
+ (10 - 1), /* Vertical timing */
+ .pol_freq = 0x, /* Pol Freq */
+ .divisor= 0x0001000d, /* 33Mhz Pixel Clock */
+ .lcd_size = ((YRES - 1) << 16 | (XRES - 1)),
+ .panel_type = 0x01, /* TFT */
+ .data_lines = 0x03, /* 24 Bit RGB */
+ .load_mode = 0x02, /* Frame Mode */
+ .panel_color= 0,
+};
+
/* Timing definitions for FPGA */
static const u32 gpmc_fpga[] = {
FPGA_GPMC_CONFIG1,
@@ -231,3 +256,41 @@ int board_mmc_init(bd_t *bis)
return omap_mmc_init(0);
}
#endif
+
+#if defined(CONFIG_VIDEO) && !defined(CONFIG_SPL_BUILD)
+static GraphicDevice panel;
+
+void *video_hw_init(void)
+{
+
+ void *fb;
+ u32 size;
+
+ panel.gdfBytesPP = 4;
+ panel.gdfIndex = GDF_32BIT_X888RGB;
+ size = XRES * YRES * panel.gdfBytesPP * 2 + 1024;
+
+ fb = (void *)0x8050;
+
+ printf("Frame buffer address 0x%p\n", fb);
+
+ gpio_request(LCD_PWR, "LCD Power");
+ gpio_request(LCD_PON_PIN, "LCD Pon");
+ gpio_direction_output(LCD_PWR, 0);
+ gpio_direction_output(LCD_PON_PIN, 1);
+
+ panel.winSizeX = XRES;
+ panel.winSizeY = YRES;
+ panel.plnSizeX = XRES;
+ panel.plnSizeY = YRES;
+
+ panel.frameAdrs = (u32)fb;
+ panel.memSize = size;
+
+ omap3_dss_panel_config(&lcd_cfg);
+ omap3_dss_setfb(fb);
+ omap3_dss_enable();
+
+ return (void *)&panel;
+}
+#endif
diff --git a/board/teejet/mt_ventoux/mt_ventoux.h
b/board/teejet/mt_ventoux/mt_ventoux.h
index 9b2e43e..90331f4 100644
--- a/board/teejet/mt_ventoux/mt_ventoux.h
+++ b/board/teejet/mt_ventoux/mt_ventoux.h
@@ -221,7 +221,7 @@ const omap3_sysinfo sysinfo = {
MUX_VAL(CP(MMC2_DAT5), (IDIS | PTU | EN | M4)) \
MUX_VAL(CP(MMC2_DAT6), (IDIS | PTU | EN | M4)) \
/* GPIO_138: LCD_ENVD */\
- MUX_VAL(CP(MMC2_DAT7), (IDIS | PTU | EN | M4)) \
+ MUX_VAL(CP(MMC2_DAT7), (IDIS | PTD | EN | M4)) \
/* GPIO_139: LCD_PON */\
/* McBSP */\
MUX_VAL(CP(MCBSP_CLKS), (IEN | PTU | DIS | M0)) \
diff --git a/include/configs/mt_ventoux.h b/include/configs/mt_ventoux.h
index 5db6d57..8ea0dc2 100644
--- a/include/configs/mt_ventoux.h
+++ b/include/configs/mt_ventoux.h
@@ -2,6 +2,9 @@
* Copyright (C) 2011
* Stefano Babic, DENX Software Engineering, sba...@denx.de.
*
+ *
+ * Configuration settings for the Teejet mt_ventoux board.
+ *
* Copyright (C) 2009 TechNexion Ltd.
*
* This program is free software; you can redistribute it and/or modify
@@ -24,6 +27,10 @@
#include "tam3517-common.h"
+#undef CONFIG_SYS_MALLOC_LEN
+#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (128 << 10) + \
+ 6 * 1024 * 1024)
+
#define MACH_TYPE_AM3517_MT_VENTOUX3832
#define CONFIG_MACH_TYPE MACH_TYPE_AM3517_MT_VENTOUX
@@ -62,6 +69,16 @@
#define CONFIG_FPGA_DELAY() udelay(1)
#define CONFIG_SYS_FPGA_PROG_FEEDBACK
+#define CONFIG_VIDEO
+#define CONFIG_CFB_CONSOLE
+#define CONFIG_VGA_AS_SINGLE_DEVICE
+#define CONFIG_SPLASH_SCREEN
+/* #define CONFIG_VIDEO_LOGO */
+#define CONFIG_VIDEO_BMP_RLE8
+#define CONFIG_CMD_BMP
+#define CONFIG_VIDEO_OMAP3 /* DSS Support */
+#define CONFIG_SYS_CONSOLE_IS_IN_ENV
+
#defineCONFIG_EXTRA_ENV_SETTINGS CONFIG_TAM3517_SETTINGS \
"bootcmd=run net_nfs\0"
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] OMAP3: mcx: set pinmux for uart4
Signed-off-by: Stefano Babic
CC: Tom Rini
---
board/htkw/mcx/mcx.h | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/board/htkw/mcx/mcx.h b/board/htkw/mcx/mcx.h
index d675a48..867cc9e 100644
--- a/board/htkw/mcx/mcx.h
+++ b/board/htkw/mcx/mcx.h
@@ -284,9 +284,14 @@ const omap3_sysinfo sysinfo = {
/* HSUSB2_dat3 */\
/* CCDC */\
MUX_VAL(CP(CCDC_PCLK), (IEN | PTD | EN | M4)) \
- MUX_VAL(CP(CCDC_FIELD), (IEN | PTD | EN | M4)) \
- MUX_VAL(CP(CCDC_HD),(IEN | PTD | EN | M4)) \
- MUX_VAL(CP(CCDC_VD),(IEN | PTD | EN | M4)) \
+ /* CCDC_FIELD: gpio_95, uP-TXD4 */ \
+ MUX_VAL(CP(CCDC_FIELD), (IDIS | PTD | DIS | M2)) \
+ /* CCDC_HD: gpio_96, uP-RTS4# */ \
+ MUX_VAL(CP(CCDC_HD),(IDIS | PTD | DIS | M2)) \
+ /* CCDC_VD: gpio_97, uP-CTS4# */ \
+ MUX_VAL(CP(CCDC_VD),(IEN | PTD | EN | M2)) \
+ /* CCDC_WEN: gpio_98, uP-RXD4 */ \
+ MUX_VAL(CP(CCDC_WEN), (IEN | PTD | DIS | M2)) \
MUX_VAL(CP(CCDC_WEN), (IEN | PTD | EN | M4)) \
MUX_VAL(CP(CCDC_DATA0), (IEN | PTD | EN | M4)) \
MUX_VAL(CP(CCDC_DATA1), (IEN | PTD | EN | M4)) \
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] mcx: increased buffer for command line
Signed-off-by: Stefano Babic CC: Tom Rini --- include/configs/mcx.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/mcx.h b/include/configs/mcx.h index 1315c3c..6159268 100644 --- a/include/configs/mcx.h +++ b/include/configs/mcx.h @@ -230,7 +230,7 @@ #define CONFIG_SYS_HUSH_PARSER /* use "hush" command parser */ #define CONFIG_SYS_PROMPT_HUSH_PS2 "> " #define CONFIG_SYS_PROMPT V_PROMPT -#define CONFIG_SYS_CBSIZE 512 /* Console I/O Buffer Size */ +#define CONFIG_SYS_CBSIZE 1024/* Console I/O Buffer Size */ /* Print Buffer Size */ #define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + \ sizeof(CONFIG_SYS_PROMPT) + 16) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] OMAP3: mcx: read hot-water-button after reset
Detect hot-water-button to start a differnt image.
Signed-off-by: Stefano Babic
CC: Tom Rini
---
board/htkw/mcx/mcx.c | 23 +++
include/configs/mcx.h |2 ++
2 files changed, 25 insertions(+)
diff --git a/board/htkw/mcx/mcx.c b/board/htkw/mcx/mcx.c
index e593b43..f7d92e8 100644
--- a/board/htkw/mcx/mcx.c
+++ b/board/htkw/mcx/mcx.c
@@ -37,6 +37,8 @@
DECLARE_GLOBAL_DATA_PTR;
+#define HOT_WATER_BUTTON 38
+
#ifdef CONFIG_USB_EHCI
static struct omap_usbhs_board_data usbhs_bdata = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
@@ -79,6 +81,27 @@ int misc_init_r(void)
return 0;
}
+#ifdef CONFIG_BOARD_LATE_INIT
+int board_late_init(void)
+{
+ if (gpio_request(HOT_WATER_BUTTON, "hot-water-button") < 0) {
+ puts("Failed to get hot-water-button pin\n");
+ return -ENODEV;
+ }
+ gpio_direction_input(HOT_WATER_BUTTON);
+
+ /*
+* if hot-water-button is pressed
+* change bootcmd
+*/
+ if (gpio_get_value(HOT_WATER_BUTTON))
+ return 0;
+
+ setenv("bootcmd", "run swupdate");
+ return 0;
+}
+#endif
+
/*
* Routine: set_muxconf_regs
* Description: Setting up the configuration Mux registers specific to the
diff --git a/include/configs/mcx.h b/include/configs/mcx.h
index d9bd089..02e009d 100644
--- a/include/configs/mcx.h
+++ b/include/configs/mcx.h
@@ -30,6 +30,7 @@
#define MACH_TYPE_MCX 3656
#define CONFIG_MACH_TYPE MACH_TYPE_MCX
+#define CONFIG_BOARD_LATE_INIT
#define CONFIG_SYS_CACHELINE_SIZE 64
@@ -140,6 +141,7 @@
#define CONFIG_MTD_PARTITIONS
#define CONFIG_MTD_DEVICE
#define CONFIG_CMD_MTDPARTS
+#define CONFIG_CMD_GPIO
#undef CONFIG_CMD_FLASH/* flinfo, erase, protect */
#undef CONFIG_CMD_FPGA /* FPGA configuration Support */
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] OMAP3: mcx: updated default environment
Patch drops also not used CFI setup in the
configuration file.
Signed-off-by: Stefano Babic
CC: Tom Rini
---
include/configs/mcx.h | 128 +++--
1 file changed, 91 insertions(+), 37 deletions(-)
diff --git a/include/configs/mcx.h b/include/configs/mcx.h
index 6159268..d9bd089 100644
--- a/include/configs/mcx.h
+++ b/include/configs/mcx.h
@@ -185,38 +185,95 @@
#define CONFIG_BOOTFILE"uImage"
+#define xstr(s)str(s)
+#define str(s) #s
+
+/* Setup MTD for NAND on the SOM */
+#define MTDIDS_DEFAULT "nand0=omap2-nand.0"
+#define MTDPARTS_DEFAULT "mtdparts=omap2-nand.0:512k(MLO)," \
+ "1m(u-boot),256k(env1),"\
+ "256k(env2),6m(kernel),6m(k_recovery)," \
+ "8m(fs_recovery),-(common_data)"
+
+#define CONFIG_HOSTNAME mcx
#define CONFIG_EXTRA_ENV_SETTINGS \
- "loadaddr=0x8200\0" \
- "console=ttyO2,115200n8\0" \
- "mmcargs=setenv bootargs console=${console} " \
- "root=/dev/mmcblk0p2 rw " \
- "rootfstype=ext3 rootwait\0" \
- "nandargs=setenv bootargs console=${console} " \
- "root=/dev/mtdblock4 rw " \
- "rootfstype=jffs2\0" \
- "loadbootscript=fatload mmc 0 ${loadaddr} boot.scr\0" \
- "bootscript=echo Running bootscript from mmc ...; " \
- "source ${loadaddr}\0" \
- "loaduimage=fatload mmc 0 ${loadaddr} uImage\0" \
- "mmcboot=echo Booting from mmc ...; " \
- "run mmcargs; " \
- "bootm ${loadaddr}\0" \
- "nandboot=echo Booting from nand ...; " \
- "run nandargs; " \
- "nand read ${loadaddr} 28 40; " \
- "bootm ${loadaddr}\0" \
+ "adddbg=setenv bootargs ${bootargs} trace_buf_size=64M\0" \
+ "adddebug=setenv bootargs ${bootargs} earlyprintk=serial\0" \
+ "addeth=setenv bootargs ${bootargs} ethaddr=${ethaddr}\0" \
+ "addfb=setenv bootargs ${bootargs} vram=6M "\
+ "omapfb.vram=1:2M,2:2M,3:2M omapdss.def_disp=lcd\0" \
+ "addip_sta=setenv bootargs ${bootargs} "\
+ "ip=${ipaddr}:${serverip}:${gatewayip}:"\
+ "${netmask}:${hostname}:eth0:off\0" \
+ "addip_dyn=setenv bootargs ${bootargs} ip=dhcp\0" \
+ "addip=if test -n ${ipdyn};then run addip_dyn;" \
+ "else run addip_sta;fi\0" \
+ "addmisc=setenv bootargs ${bootargs} ${misc}\0" \
+ "addtty=setenv bootargs ${bootargs} " \
+ "console=${consoledev},${baudrate}\0" \
+ "addmtd=setenv bootargs ${bootargs} ${mtdparts}\0" \
+ "baudrate=115200\0" \
+ "consoledev=ttyO2\0"\
+ "hostname=" xstr(CONFIG_HOSTNAME) "\0" \
+ "loadaddr=0x8200\0" \
+ "load=tftp ${loadaddr} ${u-boot}\0" \
+ "load_k=tftp ${loadaddr} ${bootfile}\0" \
+ "loaduimage=fatload mmc 0 ${loadaddr} uImage\0" \
+ "loadmlo=tftp ${loadaddr} ${mlo}\0" \
+ "mlo=" xstr(CONFIG_HOSTNAME) "/MLO\0" \
+ "mmcargs=root=/dev/mmcblk0p2 rw " \
+ "rootfstype=ext3 rootwait\0"\
+ "mmcboot=echo Booting from mmc ...; " \
+ "run mmcargs; " \
+ "run addip addtty addmtd addfb addeth addmisc;" \
+ "run loaduimage; " \
+ "bootm ${loadaddr}\0" \
+ "net_nfs=run load_k; " \
+ "run nfsargs; " \
+ "run addip addtty addmtd addfb addeth addmisc;" \
+ "bootm ${loadaddr}\0" \
+ "nfsargs=setenv bootargs root=/dev/nfs rw " \
+ "nfsroot=${serverip}:${rootpath}\0" \
+ "u-boot=" xstr(CONFIG_HOSTNAME) "/u-boot.img\0" \
+ "uboot_addr=0x8\0" \
+ "update=nandecc sw;nand erase ${uboot_addr} 10;"\
+ "nand write ${loadaddr} ${uboot_addr} 8\0" \
+ "updatemlo=nandecc hw;nand erase 0 2;" \
+ "nand write ${loadaddr} 0
[U-Boot] [PATCH 1/1] tegra: usb: Fix device enumeration problem of USB1
For some reason, bit 1 (connect status change) of PORTSC will be set after issuing Port Reset (like "usb reset" in u-boot command line). This will be treated as an error and stops later device enumeration. Therefore we add a definition in header file to ignore checking of that bit after Port Reset. CONFIG_USB_RESET_IGNORE_CONNECT_CHANGE Signed-off-by: Jim Lin --- To reproduce this issue, you can modify board .dts file to set as the following to build u-boot binary. " usb0 = "/usb@c500"; usb1 = "/usb@c5008000"; " Install device on USB1 port (address at 0xc500). And run "usb reset" in u-boot console to enumerate device. common/usb_hub.c|4 include/configs/tegra2-common.h |7 +++ 2 files changed, 11 insertions(+), 0 deletions(-) diff --git a/common/usb_hub.c b/common/usb_hub.c index e0edaad..8e6bdd8 100644 --- a/common/usb_hub.c +++ b/common/usb_hub.c @@ -180,8 +180,12 @@ int hub_port_reset(struct usb_device *dev, int port, (portstatus & USB_PORT_STAT_CONNECTION) ? 1 : 0, (portstatus & USB_PORT_STAT_ENABLE) ? 1 : 0); +#ifdef CONFIG_USB_RESET_IGNORE_CONNECT_CHANGE + if (!(portstatus & USB_PORT_STAT_CONNECTION)) +#else if ((portchange & USB_PORT_STAT_C_CONNECTION) || !(portstatus & USB_PORT_STAT_CONNECTION)) +#endif return -1; if (portstatus & USB_PORT_STAT_ENABLE) diff --git a/include/configs/tegra2-common.h b/include/configs/tegra2-common.h index 1931179..904c17e 100644 --- a/include/configs/tegra2-common.h +++ b/include/configs/tegra2-common.h @@ -111,6 +111,13 @@ #define CONFIG_EHCI_IS_TDI #define CONFIG_EHCI_DCACHE +/* + * For some reason, bit 1 (Connect Status Change) of PORTSC register will be + * set after issuing Port Reset. This setting is to ignore checking of that + * bit after reset. + */ +#define CONFIG_USB_RESET_IGNORE_CONNECT_CHANGE + /* Total I2C ports on Tegra2 */ #define TEGRA_I2C_NUM_CONTROLLERS 4 -- 1.7.3 nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] powerpc/83xx/km: use tuxx1.h for kmsupx5 target
Hi Kim, On 03/21/2012 01:42 PM, Holger Brunck wrote: > This additional header is unneeded, we can use the tuxx1.h for this > target. > > Signed-off-by: Holger Brunck > cc: Kim Phillips > cc: Valentin Longchamp > cc: Gerlando Falauto > cc: Heiko Schocher > --- when do you find the time to pick up these two patch series or is something missing? : http://lists.denx.de/pipermail/u-boot/2012-March/120694.html http://lists.denx.de/pipermail/u-boot/2012-May/123755.html Thanks in advance! Best regards Holger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] FW: Is RSA algorithm support for the software authentication in u-boot?
From: Surendra Barku Dhobale Sent: Thursday, June 14, 2012 6:02 PM To: 'U-Boot@lists.denx.de' Subject: Is RSA algorithm support for the software authentication in u-boot? Hi , I am looking for the RSA , public key authentication for the images like u-boot.img ,uImage from the u-boot. In u-boot already support for the SHA1 and md5,that's great!!!. But I want to use RSA algorithm for more security and official firmware releases. Is there any support for that in u-boot?. Or we have to integrate it.? Please gives us the suggestions... Surendra. CAUTION - Disclaimer * This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS End of Disclaimer INFOSYS*** ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Is RSA algorithm support for the software authentication in u-boot?
Hi , I am looking for the RSA , public key authentication for the images like u-boot.img ,uImage from the u-boot. In u-boot already support for the SHA1 and md5,that's great!!!. But I want to use RSA algorithm for more security and official firmware releases. Is there any support for that in u-boot?. Or we have to integrate it.? Please gives us the suggestions... Surendra. CAUTION - Disclaimer * This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS End of Disclaimer INFOSYS*** ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] MMC: DWMMC: Add DWMMC driver
Hi Rajeshwari,
This patch has too many dependence with other patches.
(Pinmux and PeripID, patches for MSHCI setting).
And as i mentioned, designWare controller isn't exynos specific.
I think good that separate two files. (dw_mmc.c and exynos_dw_mmc.c)
Like this...dw_mmc.c is generic code and exynos_dw_mmc.c is samsung specific
code..
If you want, I will send to you patch that related with them. (based-on your
patch)
And Added some comment
On 06/12/2012 06:33 PM, Rajeshwari Birje wrote:
> Hi Jaehoon Chung,
>
> Yes you need to apply the following patchset
> http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/132754
>
> Regards,
> Rajeshwari Shinde.
>
> On Tue, Jun 12, 2012 at 2:07 PM, Jaehoon Chung wrote:
>> Hi Rajeshwari,
>>
>> Before applied this patch, it must apply your patch for PINMUX. right?
>>
>> Best Regards,
>> Jaehoon Chung
>>
>> On 06/12/2012 03:14 PM, Chander Kashyap wrote:
>>
>>> Hi,
>>>
>>> On 11 June 2012 19:26, Rajeshwari Birje wrote:
Hi All,
ccing Jaehoon Chung
Regards,
Rajeshwari Shinde.
On Mon, Jun 11, 2012 at 6:18 PM, Rajeshwari Shinde
wrote:
> Add DWMMC driver support and resgister description for same.
>
> Signed-off-by: Alim Akhtar
> Signed-off-by: Terry Lambert
> Signed-off-by: Rajeshwari Shinde
> ---
> Changes in V2:
>- Incorporated comments from Jaehung Chung.
>- Renamed MSHCI to DWMMC through out the driver.
>- Renamed files to exynos_dwmmc from exynos_mshc.
>- Removed major hard codings of values.
>- Wrote dw_mci_writel and dw_mci_readl functions for writel and
> readl.
>- Removed structure of registers and defined each one separately.
> orch/arm/include/asm/arch-exynos/exynos_dwmmc.h | 229 +
> drivers/mmc/Makefile|1 +
> drivers/mmc/exynos_dwmmc.c | 566
> +++
> 3 files changed, 796 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/include/asm/arch-exynos/exynos_dwmmc.h
> create mode 100644 drivers/mmc/exynos_dwmmc.c
>
> diff --git a/arch/arm/include/asm/arch-exynos/exynos_dwmmc.h
> b/arch/arm/include/asm/arch-exynos/exynos_dwmmc.h
> new file mode 100644
> index 000..349bd75
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-exynos/exynos_dwmmc.h
> @@ -0,0 +1,229 @@
> +/*
> + * (C) Copyright 2012 SAMSUNG Electronics
> + * Abhilash Kesavan
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
> USA
> + *
> + */
> +#ifndef __ASM_ARCH_COMMON_DWMMC_H
> +#define __ASM_ARCH_COMMON_DWMMC_H
> +
> +#include
> +
> +#ifndef __ASSEMBLY__
> +struct dw_mci_host {
> + void*ioaddr;
> + unsigned intclock; /* Current clock in MHz */
> + enum periph_id peripheral;
> + unsigned intverid; /* SDHCI spec. version */
> + unsigned intdata_offset;/* DATA offset */
> +};
> +
> +/*
> + * Struct idma
> + * Holds the descriptor list
> + */
> +struct dw_mci_idmac {
> + u32 des0;
> + u32 des1;
> + u32 des2;
> + u32 des3;
> +};
> +
>>> #endif
> +/* Control Register Register */
> +#define DWMCI_CONTROL 0x00
> +#define CTRL_RESET (0x1 << 0)
> +#define FIFO_RESET (0x1 << 1)
> +#define DMA_RESET (0x1 << 2)
> +#define DMA_ENABLE (0x1 << 5)
> +#define SEND_AS_CCSD (0x1 << 10)
> +#define ENABLE_IDMAC(0x1 << 25)
> +
> +/* Power Enable Register */
> +#define DWMCI_PWREN0x04
> +#define POWER_ENABLE (0x1 << 0)
> +
> +#define DWMCI_CLKDIV 0x08
> +#define DWMCI_CLKSRC 0x0c
> +
> +/* Clock Enable Register */
> +#define DWMCI_CLKENA 0x10
> +#define CLK_ENABLE (0x1 << 0)
> +#define CLK_DISABLE(0x0 << 0)
> +
> +/* Timeout Register */
> +#define DWMCI_TMOUT0x14
> +#define TMOUT_MAX 0x
> +
> +/* Card Type Register */
> +#
[U-Boot] [PATCH] i.MX6 USDHC: Use the ESDHC clock
From: Michael Langer
The commit "i.mx: fsl_esdhc: add the i.mx6q support" (4692708d) introduces
support for the i.MX6Q MMC host controller USDHC.
MXC_IPG_PERCLK sets the clock to 66MHz. This seems to be the default clock
of the ESDHC IP found in < i.MX6 silicon. However, the default clock for the
USDHC
IP found in i.MX6 is 200MHz (MXC_ESDHC_CLK). This difference will cause a 3
times
higher clock on SD_CLK than expected (see fsl_esdh.c -> set_sysctl()).
Signed-off-by: Michael Langer
CC: Stefano Babic
CC: Jason Liu
---
arch/arm/cpu/armv7/imx-common/speed.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/armv7/imx-common/speed.c
b/arch/arm/cpu/armv7/imx-common/speed.c
index 2187e8e..80989c4 100644
--- a/arch/arm/cpu/armv7/imx-common/speed.c
+++ b/arch/arm/cpu/armv7/imx-common/speed.c
@@ -35,7 +35,11 @@ DECLARE_GLOBAL_DATA_PTR;
int get_clocks(void)
{
#ifdef CONFIG_FSL_ESDHC
+#ifdef CONFIG_FSL_USDHC
+ gd->sdhc_clk = mxc_get_clock(MXC_ESDHC_CLK);
+#else
gd->sdhc_clk = mxc_get_clock(MXC_IPG_PERCLK);
#endif
+#endif
return 0;
}
--
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] ARM: support for cache coherent allocations
Hi All, On Thu, May 31, 2012 at 1:41 AM, Ilya Yanok wrote: > This is a draft implementation of cache coherent memory allocator. > This simple implementation just reserves memory area below malloc > space and leave it uncached even if data cache is enabled. > Allocations are even simpler: code just verifies that we have > enough space and increments the offset counter. No deallocations > supported for now. In future versions we could probably use > dlmalloc allocator to get space out of coherent pool. > Any comments on this? Regards, Ilya. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/3] Bug fixes for LaCie devices
On Wed, Jun 06, 2012 at 01:15:57AM +0200, Simon Guinot wrote: > This patch series provides bug fixes for LaCie devices (mostly for > Internet Space v2 and 2Big Network v2). > > Changes for v2: > - Move bug fixes into a separate patch set. > > Simon Guinot (3): > lacie_kw: fix SDRAM banks number for net2big_v2 > lacie_kw: fix CONFIG_SYS_KWD_CONFIG for inetspace_v2 > ARM: don't probe PHY address for LaCie boards > > board/LaCie/common/common.c | 23 +++ > board/LaCie/common/common.h |2 +- > board/LaCie/edminiv2/edminiv2.c |2 +- > board/LaCie/net2big_v2/net2big_v2.c |2 +- > board/LaCie/netspace_v2/netspace_v2.c |2 +- > include/configs/lacie_kw.h|6 +- > 6 files changed, 12 insertions(+), 25 deletions(-) Hi Prafulla, Please could you pick this patches ? Thanks, Simon 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 v2 0/4] Board support and feature for LaCie devices
On Wed, Jun 06, 2012 at 01:16:49AM +0200, Simon Guinot wrote: > Changes for v2: > - Move board support and feature into a separate patch set. > - Move mach-types update into a separate patch. > > Simon Guinot (4): > lacie_kw: add support for EFI partitions > ARM: add netspace_mini_v2 to mach-types.h > ARM: add support for Network Space v2 Lite and Mini > ARM: add support for d2 Network v2 > > arch/arm/include/asm/mach-types.h | 13 +++ > board/LaCie/common/common.c | 36 ++- > board/LaCie/common/common.h |1 + > board/LaCie/netspace_v2/kwbimage-ns2l.cfg | 162 > + > board/LaCie/netspace_v2/netspace_v2.c |4 + > boards.cfg|3 + > include/configs/lacie_kw.h| 42 ++-- > 7 files changed, 252 insertions(+), 9 deletions(-) > create mode 100644 board/LaCie/netspace_v2/kwbimage-ns2l.cfg Please could you pick this patches too ? Thanks, Simon signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] cpsw: add driver for cpsw ethernet device
Tom, guys, I've just found that I forgot to mention that this version requires my patch [1] to work with enabled D-Cache correctly. Hope to get some comments on it soon. [1] http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/132464 Regards, Ilya. On Fri, Jun 8, 2012 at 5:12 PM, Ilya Yanok wrote: > From: Cyril Chemparathy > > CPSW is an on-chip ethernet switch that is found on various SoCs from Texas > Instruments. This patch adds a simple driver (based on the Linux driver) > for > this hardware module. > > This patch also adds support to clean and flush dcache during packet send > and receive. > > Changes by Sandhya: Added support to clean and flush dcache during packet >send/receive and added timeouts. > > Changes by Ilya: Cleaner cache handling, some style cleanup > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/3] Bug fixes for LaCie devices
> -Original Message- > From: Simon Guinot [mailto:si...@sequanux.org] > Sent: 14 June 2012 20:41 > To: Simon Guinot > Cc: Prafulla Wadaskar; u-boot@lists.denx.de > Subject: Re: [U-Boot] [PATCH v2 0/3] Bug fixes for LaCie devices > > On Wed, Jun 06, 2012 at 01:15:57AM +0200, Simon Guinot wrote: > > This patch series provides bug fixes for LaCie devices (mostly for > > Internet Space v2 and 2Big Network v2). > > > > Changes for v2: > > - Move bug fixes into a separate patch set. > > > > Simon Guinot (3): > > lacie_kw: fix SDRAM banks number for net2big_v2 > > lacie_kw: fix CONFIG_SYS_KWD_CONFIG for inetspace_v2 > > ARM: don't probe PHY address for LaCie boards > > > > board/LaCie/common/common.c | 23 +++--- > - > > board/LaCie/common/common.h |2 +- > > board/LaCie/edminiv2/edminiv2.c |2 +- > > board/LaCie/net2big_v2/net2big_v2.c |2 +- > > board/LaCie/netspace_v2/netspace_v2.c |2 +- > > include/configs/lacie_kw.h|6 +- > > 6 files changed, 12 insertions(+), 25 deletions(-) > > Hi Prafulla, > > Please could you pick this patches ? > Sure, I will do it. Hopefully by tomorrow Regards.. Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] tegra: seaboard: Initialize multiple USB controllers at once
On 06/13/2012 10:17 PM, Jim Lin wrote:
> Add support for command line "usb reset" or "usb start" to initialize
> , "usb stop" to stop multiple USB controllers at once.
> Other commands like "usb tree" also support multiple controllers.
These patches also need to be sent to the USB maintainer since they
touch core USB code. (Now CC'd)
Rather than one mega-patch that touch the USB core, and the Tegra
driver, can't the patch be split up a bit so that one patch adds the
ability to support multiple controllers, and then another patch modifies
the Tegra USB driver to support this, etc. Many smaller patches are much
easier to review.
This patch adds a huge number of ifdefs. I'm sure many of them can be
removed completely. For example, in the following code, why not /always/
get the rootdev from dev->controller->rootdev, and remove the global
variable. I would guess that the code size increase would be extremely
minimal, but it would make the code a lot more maintainable by removing
all the ifdefs.
> submit_control_msg(struct usb_device *dev, unsigned long pipe, void *buffer,
>int length, struct devrequest *setup)
> {
> +#ifdef CONFIG_USB_INIT_MULTI
> + struct ehci_ctrl *ctrl = dev->controller;
> +#endif
>
> if (usb_pipetype(pipe) != PIPE_CONTROL) {
> debug("non-control pipe (type=%lu)", usb_pipetype(pipe));
> return -1;
> }
>
> +#ifdef CONFIG_USB_INIT_MULTI
> + if (usb_pipedevice(pipe) == ctrl->rootdev) {
> + if (ctrl->rootdev == 0)
> +#else
> if (usb_pipedevice(pipe) == rootdev) {
> if (rootdev == 0)
> +#endif
> dev->speed = USB_SPEED_HIGH;
> return ehci_submit_root(dev, pipe, buffer, length, setup);
> }
The patch above removes the use of the global variable "rootdev", but I
don't see anywhere that ifdef's that variable out of existence. Not
doing so would allow code to accidentally use the global when it should
be using the per-device value; how can you be sure you've patched all
the places in the code that you need to? What about future changes to
the code by people who aren't aware of the USB_INIT_MULTI feature?
Similarly, why not just outright change the prototype of
tegrausb_stop_port() so that it always takes a port number; the existing
calls can hard-code a port ID of 0 for compatibility:
> +#ifdef CONFIG_USB_INIT_MULTI
> +int ehci_hcd_stop(int index)
> +{
> + tegrausb_stop_port(index);
> + return 0;
> +}
> +#else
> int ehci_hcd_stop(void)
> {
> tegrausb_stop_port();
> return 0;
> }
>> +#endif
In the end, I think if you rework the patch to remove all/most of the
ifdefs, the only thing that's left will be that the loop to initialize
USB would loop over either just device 0 or devices 0..n-1, and even
that wouldn't need to be ifdef'd...
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] tegra: usb: Fix device enumeration problem of USB1
On 06/14/2012 04:40 AM, Jim Lin wrote: > For some reason, bit 1 (connect status change) of PORTSC will be set > after issuing Port Reset (like "usb reset" in u-boot command line). > This will be treated as an error and stops later device enumeration. > > Therefore we add a definition in header file to ignore checking of that bit > after Port Reset. > CONFIG_USB_RESET_IGNORE_CONNECT_CHANGE (Again, I'm CC'ing the USB maintainer here) Looking at the Linux kernel's Tegra EHCI driver: a) This WAR is only needed on the first USB port, not all of them. b) This WAR is not complete; there's a loop in the kernel that resets the port twice in order to guarantee that the port will become enabled. c) The kernel driver actively clears this CSC bit rather than leaving it set and ignoring it. Is there any implication to this difference? So, rather than just ifdef'ing this fix into the driver, wouldn't it be better to add a callback from the USB core into the USB driver, so that the Tegra EHCI driver could choose to only implement this WAR for port 1, and also do the multiple-reset-loop thing. Finally, in the change description, the text "for some reason" is quite unclear; it sounds like you have absolutely no idea why this happens. Is this a known and root-caused HW bug for which this fix has been fully validated? Or, is this patch just some random hack that seems to work for you? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FW: Is RSA algorithm support for the software authentication in u-boot?
Dear Surendra Barku Dhobale, > From: Surendra Barku Dhobale > Sent: Thursday, June 14, 2012 6:02 PM > To: 'U-Boot@lists.denx.de' > Subject: Is RSA algorithm support for the software authentication in > u-boot? > > Hi , > I am looking for the RSA , public key authentication for the > images like u-boot.img ,uImage from the u-boot. In u-boot already support > for the SHA1 and md5,that's great!!!. But I want to use RSA algorithm for > more security and official firmware releases. Is there any support for > that in u-boot?. Or we have to integrate it.? Please gives us the > suggestions... Basically, you want to not only prevent software corruption, but lock down the device? Why ... But either way, yes, you'd have to implement support for RSA into uboot. > > Surendra. > The stuff below is nonsense and it takes half of the space in this email, can you please fix it? > CAUTION - Disclaimer * > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended > solely for the use of the addressee(s). If you are not the intended > recipient, please notify the sender by e-mail and delete the original > message. Further, you are not to copy, disclose, or distribute this e-mail > or its contents to any other person and any such actions are unlawful. > This e-mail may contain viruses. Infosys has taken every reasonable > precaution to minimize this risk, but is not liable for any damage you may > sustain as a result of any virus in this e-mail. You should carry out your > own virus checks before opening the e-mail or attachment. Infosys reserves > the right to monitor and review the content of all messages sent to or > from this e-mail address. Messages sent to or from this e-mail address may > be stored on the Infosys e-mail system. > ***INFOSYS End of Disclaimer INFOSYS*** Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] tegra: seaboard: Initialize multiple USB controllers at once
Dear Stephen Warren, > On 06/13/2012 10:17 PM, Jim Lin wrote: > > Add support for command line "usb reset" or "usb start" to initialize > > , "usb stop" to stop multiple USB controllers at once. > > Other commands like "usb tree" also support multiple controllers. > > These patches also need to be sent to the USB maintainer since they > touch core USB code. (Now CC'd) Ok, waiting for smaller patches indeed, Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/4] USB and cache related fixes
Hey all, In commit b8adb12 the cache flushing behavior was changed for the EHCI stack. This change showed a few different problems on TI platforms (where our cacheline size is 64 not 32). First, the dcache_off call that ehci-omap had been doing was now not happening soon enough to paper over the cache issues. This call is removed in patch 1. Second, when we have dcache support compiled in but turned off via 'dcache off' the cache routines spam the console about alignment issues when a cache flush is attempted. This is a problem in that it makes operations extremely slow (as we're spending all our time spitting messages to console). The second patch makes the flush routines return when the dcache is off. The last two patches deal with the same problem, for EHCI and for MUSB. The USB spec says that 32 bytes is the minimum alignment but we need larger alignment when the cache is larger. Note that we can't use MAX() here as gcc doesn't allow that expansion inside of align(..). Tested on omap3_beagle (which was previously broken) and a MAKEALL -a arm looks good too. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] ehci-hcd.c: Add a new USB_DMA_MINALIGN define for cache alignment
The USB spec says that 32 bytes is the minimum required alignment.
However on some platforms we have a larger minimum requirement for cache
coherency. In those cases, use that value rather than the USB spec
minimum.
Cc: Marek Vasut
Signed-off-by: Tom Rini
---
drivers/usb/host/ehci-hcd.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 04300be..45725f5 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -29,12 +29,23 @@
#include "ehci.h"
-int rootdev;
-struct ehci_hccr *hccr;/* R/O registers, not need for volatile */
-volatile struct ehci_hcor *hcor;
+/*
+ * The EHCI spec says that we must align to at least 32 bytes. However,
+ * some platforms require larger alignment.
+ */
+#if ARCH_DMA_MINALIGN > 32
+#define USB_DMA_MINALIGN ARCH_DMA_MINALIGN
+#else
+#define USB_DMA_MINALIGN 32
+#endif
+
+int rootdev __attribute__((aligned(USB_DMA_MINALIGN)));
+/* R/O registers, not need for volatile */
+struct ehci_hccr *hccr __attribute__((aligned(USB_DMA_MINALIGN)));
+volatile struct ehci_hcor *hcor __attribute__((aligned(USB_DMA_MINALIGN)));
static uint16_t portreset;
-static struct QH qh_list __attribute__((aligned(32)));
+static struct QH qh_list __attribute__((aligned(USB_DMA_MINALIGN)));
static struct descriptor {
struct usb_hub_descriptor hub;
@@ -207,8 +218,8 @@ static int
ehci_submit_async(struct usb_device *dev, unsigned long pipe, void *buffer,
int length, struct devrequest *req)
{
- static struct QH qh __attribute__((aligned(32)));
- static struct qTD qtd[3] __attribute__((aligned (32)));
+ static struct QH qh __attribute__((aligned(USB_DMA_MINALIGN)));
+ static struct qTD qtd[3] __attribute__((aligned(USB_DMA_MINALIGN)));
int qtd_counter = 0;
volatile struct qTD *vtd;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] cache_v7: Check for dcache enablement in dcache flush functions
If we are built with D-CACHE enabled but have run 'dcache off' and then
attempt to flush unaligned regions we spam the console with problems
that aren't true (as the cache was off).
Signed-off-by: Tom Rini
---
arch/arm/cpu/armv7/cache_v7.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/cpu/armv7/cache_v7.c b/arch/arm/cpu/armv7/cache_v7.c
index 1b4e808..1c0f5b0 100644
--- a/arch/arm/cpu/armv7/cache_v7.c
+++ b/arch/arm/cpu/armv7/cache_v7.c
@@ -250,6 +250,9 @@ static void v7_inval_tlb(void)
void invalidate_dcache_all(void)
{
+ if (!dcache_status())
+ return;
+
v7_maint_dcache_all(ARMV7_DCACHE_INVAL_ALL);
v7_outer_cache_inval_all();
@@ -261,6 +264,9 @@ void invalidate_dcache_all(void)
*/
void flush_dcache_all(void)
{
+ if (!dcache_status())
+ return;
+
v7_maint_dcache_all(ARMV7_DCACHE_CLEAN_INVAL_ALL);
v7_outer_cache_flush_all();
@@ -272,6 +278,8 @@ void flush_dcache_all(void)
*/
void invalidate_dcache_range(unsigned long start, unsigned long stop)
{
+ if (!dcache_status())
+ return;
v7_dcache_maint_range(start, stop, ARMV7_DCACHE_INVAL_RANGE);
@@ -285,6 +293,9 @@ void invalidate_dcache_range(unsigned long start, unsigned
long stop)
*/
void flush_dcache_range(unsigned long start, unsigned long stop)
{
+ if (!dcache_status())
+ return;
+
v7_dcache_maint_range(start, stop, ARMV7_DCACHE_CLEAN_INVAL_RANGE);
v7_outer_cache_flush_range(start, stop);
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] musb_core.h: Add a new USB_DMA_MINALIGN define for cache alignment
The USB spec says that 32 bytes is the minimum required alignment.
However on some platforms we have a larger minimum requirement for cache
coherency. In those cases, use that value rather than the USB spec
minimum.
Cc: Marek Vasut
Signed-off-by: Tom Rini
---
drivers/usb/musb/musb_core.h | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index a8adcce..bd1ad82 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -74,6 +74,16 @@ struct musb_epN_regs {
u8 fifosize;
};
+/*
+ * The EHCI spec says that we must align to at least 32 bytes. However,
+ * some platforms require larger alignment.
+ */
+#if ARCH_DMA_MINALIGN > 32
+#define USB_DMA_MINALIGN ARCH_DMA_MINALIGN
+#else
+#define USB_DMA_MINALIGN 32
+#endif
+
/* Mentor USB core register overlay structure */
#ifndef musb_regs
struct musb_regs {
@@ -145,7 +155,7 @@ struct musb_regs {
struct musb_epN_regs epN;
} ep[16];
-} __attribute__((packed, aligned(32)));
+} __attribute__((packed, aligned(USB_DMA_MINALIGN)));
#endif
/*
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] u-boot on c6x CPU ( texas instruments c6000 )
Can i share patches for start u-boot on tms320c6745 processor (http://www.ti.com/product/tms320c6745)? What is the best way? May be somebody already make support c6000 (c6x) arch in u-boot? For information: C6X family of processors supported by gcc from version 4.7.0. C6745 pin compatible with AM1705 (http://www.ti.com/product/am1705), only CPU core is different, because drivers for davinci work ok on c6745. I'm work on this SOM http://inmys.ru/?_=/products/som_c6745 Now work: uart, nand, ethernet (drivers/serial/ns16550.c, drivers/mtd/nand/davinci_nand.c, drivers/net/davinci_emac.c) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] ehci-omap: Do not call dcache_off from omap_ehci_hcd_init
This has never been completely sufficient and now happens too late to paper over the cache coherency problems with the current USB stack. Signed-off-by: Tom Rini --- drivers/usb/host/ehci-omap.c |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c index 1ed7710..292673b 100644 --- a/drivers/usb/host/ehci-omap.c +++ b/drivers/usb/host/ehci-omap.c @@ -246,7 +246,6 @@ int omap_ehci_hcd_init(struct omap_usbhs_board_data *usbhs_pdata) if (is_ehci_phy_mode(usbhs_pdata->port_mode[i])) omap_ehci_soft_phy_reset(i); - dcache_disable(); hccr = (struct ehci_hccr *)(OMAP_EHCI_BASE); hcor = (struct ehci_hcor *)(OMAP_EHCI_BASE + 0x10); -- 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 3/4] ehci-hcd.c: Add a new USB_DMA_MINALIGN define for cache alignment
Dear Tom Rini,
> The USB spec says that 32 bytes is the minimum required alignment.
> However on some platforms we have a larger minimum requirement for cache
> coherency. In those cases, use that value rather than the USB spec
> minimum.
>
> Cc: Marek Vasut
> Signed-off-by: Tom Rini
> ---
> drivers/usb/host/ehci-hcd.c | 23 +--
> 1 file changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
> index 04300be..45725f5 100644
> --- a/drivers/usb/host/ehci-hcd.c
> +++ b/drivers/usb/host/ehci-hcd.c
> @@ -29,12 +29,23 @@
>
> #include "ehci.h"
>
> -int rootdev;
> -struct ehci_hccr *hccr; /* R/O registers, not need for volatile */
> -volatile struct ehci_hcor *hcor;
> +/*
> + * The EHCI spec says that we must align to at least 32 bytes. However,
> + * some platforms require larger alignment.
> + */
> +#if ARCH_DMA_MINALIGN > 32
> +#define USB_DMA_MINALIGN ARCH_DMA_MINALIGN
> +#else
> +#define USB_DMA_MINALIGN 32
> +#endif
Don't we have some common header for these?
> +
> +int rootdev __attribute__((aligned(USB_DMA_MINALIGN)));
> +/* R/O registers, not need for volatile */
> +struct ehci_hccr *hccr __attribute__((aligned(USB_DMA_MINALIGN)));
> +volatile struct ehci_hcor *hcor
> __attribute__((aligned(USB_DMA_MINALIGN)));
>
> static uint16_t portreset;
> -static struct QH qh_list __attribute__((aligned(32)));
> +static struct QH qh_list __attribute__((aligned(USB_DMA_MINALIGN)));
>
> static struct descriptor {
> struct usb_hub_descriptor hub;
> @@ -207,8 +218,8 @@ static int
> ehci_submit_async(struct usb_device *dev, unsigned long pipe, void
> *buffer, int length, struct devrequest *req)
> {
> - static struct QH qh __attribute__((aligned(32)));
> - static struct qTD qtd[3] __attribute__((aligned (32)));
> + static struct QH qh __attribute__((aligned(USB_DMA_MINALIGN)));
> + static struct qTD qtd[3] __attribute__((aligned(USB_DMA_MINALIGN)));
> int qtd_counter = 0;
>
> volatile struct qTD *vtd;
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] ehci-hcd.c: Add a new USB_DMA_MINALIGN define for cache alignment
On 06/14/2012 12:29 PM, Marek Vasut wrote: > Dear Tom Rini, > >> The USB spec says that 32 bytes is the minimum required alignment. >> However on some platforms we have a larger minimum requirement for cache >> coherency. In those cases, use that value rather than the USB spec >> minimum. >> >> Cc: Marek Vasut >> Signed-off-by: Tom Rini >> --- >> drivers/usb/host/ehci-hcd.c | 23 +-- >> 1 file changed, 17 insertions(+), 6 deletions(-) >> >> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c >> index 04300be..45725f5 100644 >> --- a/drivers/usb/host/ehci-hcd.c >> +++ b/drivers/usb/host/ehci-hcd.c >> @@ -29,12 +29,23 @@ >> >> #include "ehci.h" >> >> -int rootdev; >> -struct ehci_hccr *hccr; /* R/O registers, not need for volatile */ >> -volatile struct ehci_hcor *hcor; >> +/* >> + * The EHCI spec says that we must align to at least 32 bytes. However, >> + * some platforms require larger alignment. >> + */ >> +#if ARCH_DMA_MINALIGN > 32 >> +#define USB_DMA_MINALIGNARCH_DMA_MINALIGN >> +#else >> +#define USB_DMA_MINALIGN32 >> +#endif > > Don't we have some common header for these? For ECHI and musb? I did not spot one unless we go all the way up to common.h or similar. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] ehci-hcd.c: Add a new USB_DMA_MINALIGN define for cache alignment
Dear Tom Rini, > On 06/14/2012 12:29 PM, Marek Vasut wrote: > > Dear Tom Rini, > > > >> The USB spec says that 32 bytes is the minimum required alignment. > >> However on some platforms we have a larger minimum requirement for cache > >> coherency. In those cases, use that value rather than the USB spec > >> minimum. > >> > >> Cc: Marek Vasut > >> Signed-off-by: Tom Rini > >> --- > >> > >> drivers/usb/host/ehci-hcd.c | 23 +-- > >> 1 file changed, 17 insertions(+), 6 deletions(-) > >> > >> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c > >> index 04300be..45725f5 100644 > >> --- a/drivers/usb/host/ehci-hcd.c > >> +++ b/drivers/usb/host/ehci-hcd.c > >> @@ -29,12 +29,23 @@ > >> > >> #include "ehci.h" > >> > >> -int rootdev; > >> -struct ehci_hccr *hccr; /* R/O registers, not need for volatile */ > >> -volatile struct ehci_hcor *hcor; > >> +/* > >> + * The EHCI spec says that we must align to at least 32 bytes. > >> However, + * some platforms require larger alignment. > >> + */ > >> +#if ARCH_DMA_MINALIGN > 32 > >> +#define USB_DMA_MINALIGN ARCH_DMA_MINALIGN > >> +#else > >> +#define USB_DMA_MINALIGN 32 > >> +#endif > > > > Don't we have some common header for these? > > For ECHI and musb? I did not spot one unless we go all the way up to > common.h or similar. Ok, that's crappy :-/ Don't we have ehci.h or usb.h? Is musb ehci or not? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] ehci-hcd.c: Add a new USB_DMA_MINALIGN define for cache alignment
On 06/14/2012 12:41 PM, Marek Vasut wrote: > Dear Tom Rini, > >> On 06/14/2012 12:29 PM, Marek Vasut wrote: >>> Dear Tom Rini, >>> The USB spec says that 32 bytes is the minimum required alignment. However on some platforms we have a larger minimum requirement for cache coherency. In those cases, use that value rather than the USB spec minimum. Cc: Marek Vasut Signed-off-by: Tom Rini --- drivers/usb/host/ehci-hcd.c | 23 +-- 1 file changed, 17 insertions(+), 6 deletions(-) diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index 04300be..45725f5 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -29,12 +29,23 @@ #include "ehci.h" -int rootdev; -struct ehci_hccr *hccr; /* R/O registers, not need for volatile */ -volatile struct ehci_hcor *hcor; +/* + * The EHCI spec says that we must align to at least 32 bytes. However, + * some platforms require larger alignment. + */ +#if ARCH_DMA_MINALIGN > 32 +#define USB_DMA_MINALIGN ARCH_DMA_MINALIGN +#else +#define USB_DMA_MINALIGN 32 +#endif >>> >>> Don't we have some common header for these? >> >> For ECHI and musb? I did not spot one unless we go all the way up to >> common.h or similar. > > Ok, that's crappy :-/ > > Don't we have ehci.h or usb.h? Is musb ehci or not? MUSB is Mentor USB. But, good spotting, include/usb.h is in both ehci-hcd.c (and other places) and musb_core.h, moving there. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] ehci-hcd.c: Add a new USB_DMA_MINALIGN define for cache alignment
Dear Tom Rini, > On 06/14/2012 12:41 PM, Marek Vasut wrote: > > Dear Tom Rini, > > > >> On 06/14/2012 12:29 PM, Marek Vasut wrote: > >>> Dear Tom Rini, > >>> > The USB spec says that 32 bytes is the minimum required alignment. > However on some platforms we have a larger minimum requirement for > cache coherency. In those cases, use that value rather than the USB > spec minimum. > > Cc: Marek Vasut > Signed-off-by: Tom Rini > --- > > drivers/usb/host/ehci-hcd.c | 23 +-- > 1 file changed, 17 insertions(+), 6 deletions(-) > > diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c > index 04300be..45725f5 100644 > --- a/drivers/usb/host/ehci-hcd.c > +++ b/drivers/usb/host/ehci-hcd.c > @@ -29,12 +29,23 @@ > > #include "ehci.h" > > -int rootdev; > -struct ehci_hccr *hccr; /* R/O registers, not need for volatile */ > -volatile struct ehci_hcor *hcor; > +/* > + * The EHCI spec says that we must align to at least 32 bytes. > However, + * some platforms require larger alignment. > + */ > +#if ARCH_DMA_MINALIGN > 32 > +#define USB_DMA_MINALIGNARCH_DMA_MINALIGN > +#else > +#define USB_DMA_MINALIGN32 > +#endif > >>> > >>> Don't we have some common header for these? > >> > >> For ECHI and musb? I did not spot one unless we go all the way up to > >> common.h or similar. > > > > Ok, that's crappy :-/ > > > > Don't we have ehci.h or usb.h? Is musb ehci or not? > > MUSB is Mentor USB. But, good spotting, include/usb.h is in both > ehci-hcd.c (and other places) and musb_core.h, moving there. Heh, my clairvoiance can now do git-grep-alike actions without touching the repo ... I have to praise myself :-) Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/3] ehci-omap: Do not call dcache_off from omap_ehci_hcd_init
This has never been completely sufficient and now happens too late to paper over the cache coherency problems with the current USB stack. Signed-off-by: Tom Rini --- drivers/usb/host/ehci-omap.c |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c index 1ed7710..292673b 100644 --- a/drivers/usb/host/ehci-omap.c +++ b/drivers/usb/host/ehci-omap.c @@ -246,7 +246,6 @@ int omap_ehci_hcd_init(struct omap_usbhs_board_data *usbhs_pdata) if (is_ehci_phy_mode(usbhs_pdata->port_mode[i])) omap_ehci_soft_phy_reset(i); - dcache_disable(); hccr = (struct ehci_hccr *)(OMAP_EHCI_BASE); hcor = (struct ehci_hcor *)(OMAP_EHCI_BASE + 0x10); -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/3] USB and cache related fixes
Hey all, In commit b8adb12 the cache flushing behavior was changed for the EHCI stack. This change showed a few different problems on TI platforms (where our cacheline size is 64 not 32). First, the dcache_off call that ehci-omap had been doing was now not happening soon enough to paper over the cache issues. This call is removed in patch 1. Second, when we have dcache support compiled in but turned off via 'dcache off' the cache routines spam the console about alignment issues when a cache flush is attempted. This is a problem in that it makes operations extremely slow (as we're spending all our time spitting messages to console). The second patch makes the flush routines return when the dcache is off. The last patch deal with the same problem, for EHCI and for MUSB. The USB spec says that 32 bytes is the minimum alignment but we need larger alignment when the cache is larger. Note that we can't use MAX() here as gcc doesn't allow that expansion inside of align(..). Tested on omap3_beagle (which was previously broken) and a MAKEALL -a arm looks good too. Changes in v2: - Condense last two patches into one that puts the test into -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/3] ehci-hcd.c, musb_core, usb.h: Add USB_DMA_MINALIGN define for cache alignment
The USB spec says that 32 bytes is the minimum required alignment.
However on some platforms we have a larger minimum requirement for cache
coherency. In those cases, use that value rather than the USB spec
minimum. We add a cpp check to to define USB_DMA_MINALIGN and
make use of it in ehci-hcd.c and musb_core.h. We cannot use MAX() here
as we are not allowed to have tests inside of align(...).
Cc: Marek Vasut
Signed-off-by: Tom Rini
--
Changes in v2:
- Move test to , expand comment.
---
drivers/usb/host/ehci-hcd.c | 13 +++--
drivers/usb/musb/musb_core.h |2 +-
include/usb.h| 10 ++
3 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 04300be..5a86117 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -29,12 +29,13 @@
#include "ehci.h"
-int rootdev;
-struct ehci_hccr *hccr;/* R/O registers, not need for volatile */
-volatile struct ehci_hcor *hcor;
+int rootdev __attribute__((aligned(USB_DMA_MINALIGN)));
+/* R/O registers, not need for volatile */
+struct ehci_hccr *hccr __attribute__((aligned(USB_DMA_MINALIGN)));
+volatile struct ehci_hcor *hcor __attribute__((aligned(USB_DMA_MINALIGN)));
static uint16_t portreset;
-static struct QH qh_list __attribute__((aligned(32)));
+static struct QH qh_list __attribute__((aligned(USB_DMA_MINALIGN)));
static struct descriptor {
struct usb_hub_descriptor hub;
@@ -207,8 +208,8 @@ static int
ehci_submit_async(struct usb_device *dev, unsigned long pipe, void *buffer,
int length, struct devrequest *req)
{
- static struct QH qh __attribute__((aligned(32)));
- static struct qTD qtd[3] __attribute__((aligned (32)));
+ static struct QH qh __attribute__((aligned(USB_DMA_MINALIGN)));
+ static struct qTD qtd[3] __attribute__((aligned(USB_DMA_MINALIGN)));
int qtd_counter = 0;
volatile struct qTD *vtd;
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index a8adcce..e914369 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -145,7 +145,7 @@ struct musb_regs {
struct musb_epN_regs epN;
} ep[16];
-} __attribute__((packed, aligned(32)));
+} __attribute__((packed, aligned(USB_DMA_MINALIGN)));
#endif
/*
diff --git a/include/usb.h b/include/usb.h
index 6da91e7..ba3d169 100644
--- a/include/usb.h
+++ b/include/usb.h
@@ -29,6 +29,16 @@
#include
#include
+/*
+ * The EHCI spec says that we must align to at least 32 bytes. However,
+ * some platforms require larger alignment.
+ */
+#if ARCH_DMA_MINALIGN > 32
+#define USB_DMA_MINALIGN ARCH_DMA_MINALIGN
+#else
+#define USB_DMA_MINALIGN 32
+#endif
+
/* Everything is aribtrary */
#define USB_ALTSETTINGALLOC4
#define USB_MAXALTSETTING 128 /* Hard limit */
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/3] cache_v7: Check for dcache enablement in dcache flush functions
If we are built with D-CACHE enabled but have run 'dcache off' and then
attempt to flush unaligned regions we spam the console with problems
that aren't true (as the cache was off).
Signed-off-by: Tom Rini
---
arch/arm/cpu/armv7/cache_v7.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/cpu/armv7/cache_v7.c b/arch/arm/cpu/armv7/cache_v7.c
index 1b4e808..1c0f5b0 100644
--- a/arch/arm/cpu/armv7/cache_v7.c
+++ b/arch/arm/cpu/armv7/cache_v7.c
@@ -250,6 +250,9 @@ static void v7_inval_tlb(void)
void invalidate_dcache_all(void)
{
+ if (!dcache_status())
+ return;
+
v7_maint_dcache_all(ARMV7_DCACHE_INVAL_ALL);
v7_outer_cache_inval_all();
@@ -261,6 +264,9 @@ void invalidate_dcache_all(void)
*/
void flush_dcache_all(void)
{
+ if (!dcache_status())
+ return;
+
v7_maint_dcache_all(ARMV7_DCACHE_CLEAN_INVAL_ALL);
v7_outer_cache_flush_all();
@@ -272,6 +278,8 @@ void flush_dcache_all(void)
*/
void invalidate_dcache_range(unsigned long start, unsigned long stop)
{
+ if (!dcache_status())
+ return;
v7_dcache_maint_range(start, stop, ARMV7_DCACHE_INVAL_RANGE);
@@ -285,6 +293,9 @@ void invalidate_dcache_range(unsigned long start, unsigned
long stop)
*/
void flush_dcache_range(unsigned long start, unsigned long stop)
{
+ if (!dcache_status())
+ return;
+
v7_dcache_maint_range(start, stop, ARMV7_DCACHE_CLEAN_INVAL_RANGE);
v7_outer_cache_flush_range(start, stop);
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot on c6x CPU ( texas instruments c6000 )
Dear Dmitry Bondar, > Can i share patches for start u-boot on tms320c6745 processor > (http://www.ti.com/product/tms320c6745)? Yes you can share patches. > What is the best way? Use "git send-email" and send them to this list. > May be somebody already make support c6000 (c6x) arch in u-boot? Is it really a self-standing architecture? > For information: > C6X family of processors supported by gcc from version 4.7.0. > C6745 pin compatible with AM1705 (http://www.ti.com/product/am1705), > only CPU core is different, because drivers for davinci work ok on > c6745. So it's not ARM I take it? > I'm work on this SOM http://inmys.ru/?_=/products/som_c6745 > Now work: uart, nand, ethernet (drivers/serial/ns16550.c, > drivers/mtd/nand/davinci_nand.c, drivers/net/davinci_emac.c) Nice going! Please share the patches :-) Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] ehci-omap: Do not call dcache_off from omap_ehci_hcd_init
Dear Tom Rini, > This has never been completely sufficient and now happens too late to > paper over the cache coherency problems with the current USB stack. Poor USB maintainer isn't CCed :'-( > > Signed-off-by: Tom Rini But this is always a good thing to see. Acked-by: Marek Vasut > --- > drivers/usb/host/ehci-omap.c |1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c > index 1ed7710..292673b 100644 > --- a/drivers/usb/host/ehci-omap.c > +++ b/drivers/usb/host/ehci-omap.c > @@ -246,7 +246,6 @@ int omap_ehci_hcd_init(struct omap_usbhs_board_data > *usbhs_pdata) if (is_ehci_phy_mode(usbhs_pdata->port_mode[i])) > omap_ehci_soft_phy_reset(i); > > - dcache_disable(); > hccr = (struct ehci_hccr *)(OMAP_EHCI_BASE); > hcor = (struct ehci_hcor *)(OMAP_EHCI_BASE + 0x10); Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] cache_v7: Check for dcache enablement in dcache flush functions
Dear Tom Rini,
> If we are built with D-CACHE enabled but have run 'dcache off' and then
> attempt to flush unaligned regions we spam the console with problems
> that aren't true (as the cache was off).
>
> Signed-off-by: Tom Rini
> ---
> arch/arm/cpu/armv7/cache_v7.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm/cpu/armv7/cache_v7.c b/arch/arm/cpu/armv7/cache_v7.c
> index 1b4e808..1c0f5b0 100644
> --- a/arch/arm/cpu/armv7/cache_v7.c
> +++ b/arch/arm/cpu/armv7/cache_v7.c
> @@ -250,6 +250,9 @@ static void v7_inval_tlb(void)
>
> void invalidate_dcache_all(void)
> {
> + if (!dcache_status())
> + return;
Will this get optimized out of the dcache is disabled altogether in uboot
config?
btw this is 20% cooler in 10 seconds flat!
https://plus.google.com/102150693225130002912/posts/9gntjh57dXt
> +
> v7_maint_dcache_all(ARMV7_DCACHE_INVAL_ALL);
>
> v7_outer_cache_inval_all();
[...]
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] USB and cache related fixes
Dear Tom Rini, > Hey all, > > In commit b8adb12 the cache flushing behavior was changed for the EHCI > stack. This change showed a few different problems on TI platforms (where > our cacheline size is 64 not 32). Good thing, it made a bug surface ;-) > First, the dcache_off call that > ehci-omap had been doing was now not happening soon enough to paper over > the cache issues. Hm, is the dcache_off() call implemented properly so nothing is lost when you shut off the cache btw? > This call is removed in patch 1. Second, when we have > dcache support compiled in but turned off via 'dcache off' the cache > routines spam the console about alignment issues when a cache flush is > attempted. This is a problem in that it makes operations extremely slow > (as we're spending all our time spitting messages to console). The second > patch makes the flush routines return when the dcache is off. The last two > patches deal with the same problem, for EHCI and for MUSB. The USB spec > says that 32 bytes is the minimum alignment but we need larger alignment > when the cache is larger. Note that we can't use MAX() here as gcc doesn't > allow that expansion inside of align(..). > > Tested on omap3_beagle (which was previously broken) and a MAKEALL -a arm > looks good too. Good job Tom, thanks for spending time on fixing this! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] cache_v7: Check for dcache enablement in dcache flush functions
On 06/14/2012 03:00 PM, Marek Vasut wrote:
> Dear Tom Rini,
>
>> If we are built with D-CACHE enabled but have run 'dcache off' and then
>> attempt to flush unaligned regions we spam the console with problems
>> that aren't true (as the cache was off).
>>
>> Signed-off-by: Tom Rini
>> ---
>> arch/arm/cpu/armv7/cache_v7.c | 11 +++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/arch/arm/cpu/armv7/cache_v7.c b/arch/arm/cpu/armv7/cache_v7.c
>> index 1b4e808..1c0f5b0 100644
>> --- a/arch/arm/cpu/armv7/cache_v7.c
>> +++ b/arch/arm/cpu/armv7/cache_v7.c
>> @@ -250,6 +250,9 @@ static void v7_inval_tlb(void)
>>
>> void invalidate_dcache_all(void)
>> {
>> +if (!dcache_status())
>> +return;
>
> Will this get optimized out of the dcache is disabled altogether in uboot
> config?
That's another side of #ifs and that has empty functions.
> btw this is 20% cooler in 10 seconds flat!
> https://plus.google.com/102150693225130002912/posts/9gntjh57dXt
Ha.
--
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] USB and cache related fixes
On 06/14/2012 03:02 PM, Marek Vasut wrote: > Dear Tom Rini, > >> Hey all, >> >> In commit b8adb12 the cache flushing behavior was changed for the EHCI >> stack. This change showed a few different problems on TI platforms (where >> our cacheline size is 64 not 32). > > Good thing, it made a bug surface ;-) > >> First, the dcache_off call that >> ehci-omap had been doing was now not happening soon enough to paper over >> the cache issues. > > Hm, is the dcache_off() call implemented properly so nothing is lost when you > shut off the cache btw? As best I can tell, yes. It will do a dcache_flush_all() and then set the correct bits. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] ehci-omap: Do not call dcache_off from omap_ehci_hcd_init
On 06/14/2012 02:57 PM, Marek Vasut wrote: > Dear Tom Rini, > >> This has never been completely sufficient and now happens too late to >> paper over the cache coherency problems with the current USB stack. > > Poor USB maintainer isn't CCed :'-( Whoops, forgot. I don't know why I thought it was you :) > >> >> Signed-off-by: Tom Rini > > But this is always a good thing to see. > > Acked-by: Marek Vasut > >> --- >> drivers/usb/host/ehci-omap.c |1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c >> index 1ed7710..292673b 100644 >> --- a/drivers/usb/host/ehci-omap.c >> +++ b/drivers/usb/host/ehci-omap.c >> @@ -246,7 +246,6 @@ int omap_ehci_hcd_init(struct omap_usbhs_board_data >> *usbhs_pdata) if (is_ehci_phy_mode(usbhs_pdata->port_mode[i])) >> omap_ehci_soft_phy_reset(i); >> >> -dcache_disable(); >> hccr = (struct ehci_hccr *)(OMAP_EHCI_BASE); >> hcor = (struct ehci_hcor *)(OMAP_EHCI_BASE + 0x10); > > Best regards, > Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 03/19] fdt: Add function to look up a phandle's register address
On 06/13/2012 10:19 AM, Simon Glass wrote: > This is a commonly-used requirement, so add a function to support it > easily. Uggh. Why would this ever be needed; shouldn't the driver for the node referenced by the phandle fully control its own registers; why would any other driver randomly trample on them? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] cache_v7: Check for dcache enablement in dcache flush functions
Dear Tom Rini,
> On 06/14/2012 03:00 PM, Marek Vasut wrote:
> > Dear Tom Rini,
> >
> >> If we are built with D-CACHE enabled but have run 'dcache off' and then
> >> attempt to flush unaligned regions we spam the console with problems
> >> that aren't true (as the cache was off).
> >>
> >> Signed-off-by: Tom Rini
> >> ---
> >>
> >> arch/arm/cpu/armv7/cache_v7.c | 11 +++
> >> 1 file changed, 11 insertions(+)
> >>
> >> diff --git a/arch/arm/cpu/armv7/cache_v7.c
> >> b/arch/arm/cpu/armv7/cache_v7.c index 1b4e808..1c0f5b0 100644
> >> --- a/arch/arm/cpu/armv7/cache_v7.c
> >> +++ b/arch/arm/cpu/armv7/cache_v7.c
> >> @@ -250,6 +250,9 @@ static void v7_inval_tlb(void)
> >>
> >> void invalidate_dcache_all(void)
> >> {
> >>
> >> + if (!dcache_status())
> >> + return;
> >
> > Will this get optimized out of the dcache is disabled altogether in uboot
> > config?
>
> That's another side of #ifs and that has empty functions.
Ok, that's good :-)
>
> > btw this is 20% cooler in 10 seconds flat!
> > https://plus.google.com/102150693225130002912/posts/9gntjh57dXt
>
> Ha.
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] USB and cache related fixes
Dear Tom Rini, > On 06/14/2012 03:02 PM, Marek Vasut wrote: > > Dear Tom Rini, > > > >> Hey all, > >> > >> In commit b8adb12 the cache flushing behavior was changed for the EHCI > >> stack. This change showed a few different problems on TI platforms > >> (where our cacheline size is 64 not 32). > > > > Good thing, it made a bug surface ;-) > > > >> First, the dcache_off call that > >> ehci-omap had been doing was now not happening soon enough to paper over > >> the cache issues. > > > > Hm, is the dcache_off() call implemented properly so nothing is lost when > > you shut off the cache btw? > > As best I can tell, yes. It will do a dcache_flush_all() and then set > the correct bits. Ok, good Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/19] tegra: Add display support to funcmux
On 06/13/2012 10:19 AM, Simon Glass wrote:
> Add support for a default pin mapping for display1.
> +static const struct pingroup_config disp1_default[] = {
> + PINMUX(LM0, RSVD4, NORMAL,NORMAL),
> + PINMUX(LPW1, RSVD4, NORMAL,TRISTATE),
Do you really need to explicitly program these pingroups that aren't
used by display? It seems like it'll probably still work fine
irrespective of whether those are actually configured to output display
controller signals or not. However, if those pingroups are used by
something else, then changing their configuration here may stop the
other functionality from working.
> + PINMUX(SLXD, SPDIF, NORMAL,NORMAL),
Similarly here, yet SLXD doesn't ever support any display functionality,
so there should definitely be no need for this entry.
> @@ -185,6 +210,20 @@ int funcmux_select(enum periph_id id, int config)
> + case PERIPH_ID_DISP1:
> + if (config == FUNCMUX_DEFAULT) {
Shouldn't this option have some kind of name in funcmux.h; there are
many many many possible configurations for display, so just assuming
this as some kind of default seems a little presumptuous.
But, given the number of possibilities, I wonder if it isn't time to
replace funcmux with the device tree pinctrl bindings?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 07/19] tegra: fdt: Add LCD definitions for Tegra
On 06/13/2012 10:19 AM, Simon Glass wrote: > Add LCD definitions and also a proposed binding for LCD displays. > > The PWFM is in progress on the device-tree-discuss list, so only a > very basic binding is offered here. I believe we have settled on a final representation, it just hasn't been added into linux-next yet. See: http://gitorious.org/linux-pwm/linux-pwm/commit/d3ce73e5dc86646a6302f2b0f7dd40e8c552fa04 > I am not sure if it is better to have the lcd within the display > controller as with i2c/spi, or a separate node. From a hardware point > of view the LCD is certainly connected to the display controller, so > perhaps this version makes most sense. We could have a stand-alone > top-level lcd node with a phandle pointing to the display controller, > but these doesn't seem to be an obvious advantage to that approach. Equally, there's been extensive discussion re: how to represent the NVIDIA display controller in DT. I strongly believe that U-Boot shouldn't go ahead in isolation with a binding that's completely unrelated to what's happening in the kernel. Please can you take what Thierry is working on for the kernel, and/or contribute to that binding etc., so we don't end up with multiple ways of doing the same thing. Part of the whole point of DT is to have a single way of representing HW that multiple OSs (or perhaps bootloaders) cna use. If everyone just goes and does their own thing, we've lost. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 08/19] tegra: Add support for PWFM
On 06/13/2012 10:19 AM, Simon Glass wrote: > The pulse width/frequency modulation peripheral supports generating > a repeating pulse. It is useful for controlling LCD brightness. Surely this should be modeled as a driver that's instantiated from DT, which provides n PWMs. As such, I'd expect the driver to have some kind of init/probe function, and: > +void pwfm_enable(struct pwfm_ctlr *pwfm, int rate, int pulse_width, > + int freq_divider); to take a pwm_id parameter too. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 09/19] tegra: Add SOC support for display/lcd
On 06/13/2012 10:19 AM, Simon Glass wrote: > From: Wei Ni > > Add support for the LCD peripheral at the Tegra2 SOC level. A separate > LCD driver will use this functionality to configure the display. > diff --git a/arch/arm/include/asm/arch-tegra2/display.h > b/arch/arm/include/asm/arch-tegra2/display.h > +/** > + * Perform the next stage of the LCD init if it is time to do so. > + * > + * LCD init can be time-consuming because of the number of delays we need > + * while waiting for the backlight power supply, etc. This function can > + * be called at various times during U-Boot operation to advance the > + * initialization of the LCD to the next stage if sufficient time has > + * passed since the last stage. It keeps track of what stage it is up to > + * and the time that it is permitted to move to the next stage. > + * > + * The final call should have wait=1 to complete the init. > + * > + * @param blob fdt blob containing LCD information > + * @param wait 1 to wait until all init is complete, and then return > + * 0 to return immediately, potentially doing nothing if it is > + * not yet time for the next init. > + */ > +int tegra_lcd_check_next_stage(const void *blob, int wait); The prototype in the header seems to be the only mention of this function. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 10/19] tegra: Add LCD driver
On 06/13/2012 10:19 AM, Simon Glass wrote:
> This driver supports driving a single LCD and providing a U-Boot console
> on it.
> +int fdt_decode_lcd(const void *blob, struct fdt_lcd *config)
> + fdtdec_decode_gpio(blob, display_node, "nvidia,backlight-vdd-gpios",
> +&config->backlight_vdd);
Given that's a power supply control, I expect this to be represented as
a regulator in the DT, not as a simple GPIO (it could be controlled by a
register bit in a PMU on some boards).
> +void lcd_enable(void)
> +{
> + /*
> + * Backlight and power init will be done separately in
> + * tegra_lcd_check_next_stage(), which should be called in
> + * board_late_init().
> + *
> + * U-Boot code supports only colour depth, selected at compile time.
> + * The device tree setting should match this. Otherwise the display
> + * will not look right, and U-Boot may crash.
> + */
> + if (config.log2_bpp != LCD_BPP) {
> + printf("%s: Error: LCD depth configured in FDT (%d = %dbpp)"
> + " must match setting of LCD_BPP (%d)\n", __func__,
> +config.log2_bpp, config.bpp, LCD_BPP);
> + }
> +}
I wonder why even read the configuration from DT if the value can't be used?
> diff --git a/lib/fdtdec.c b/lib/fdtdec.c
> @@ -43,6 +43,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
> + COMPAT(NVIDIA_TEGRA20_DISPLAY, "nvidia,tegra20-display"),
Surely all the DT plumbing for the display controller itself should be
in the previous patch that adds the display controller driver.
The LCD stuff that sits on top of that seems like it should be a
separate node in DT, and the two patches kept much more separate.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 11/19] tegra: Add LCD support to Nvidia boards
On 06/13/2012 10:19 AM, Simon Glass wrote: > Add calls to the LCD driver from Nvidia board code. > diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c > @@ -87,6 +88,9 @@ int board_init(void) > +#ifdef CONFIG_VIDEO_TEGRA2 > + tegra_lcd_check_next_stage(gd->blob, 0); > +#endif This seems to be conflating video support with LCD support. It would be quite possible to have a board with no LCD, yet supporting display over HDMI for example. In other words, shouldn't the ifdef above be something more like: #if define(CONFIG_LCD_SUPPORT) register_lcd_driver(); #endif #if defined(CONFIG_VIDEO_TEGRA2) tegra_display_init(...); #endif and internal to tegra_display_init(), the DT is searched for LCD controller nodes, and if any are found, they're matched to the LCD driver registered by the first call above. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 12/19] arm: Add control over cachability of memory regions
On 06/13/2012 10:19 AM, Simon Glass wrote: > Add support for adjusting the cachability of an L1 section by updating > the MMU. The mmu_set_region_dcache() function allows drivers to make > these changes after the MMU is set up. > > It is implemented only for ARMv7 at present. > > This is needed for LCD support, where we want to make the LCD frame buffer > write-through (or off) rather than write-back. Wouldn't performance be significantly better if the region was fully cached, but flushed after each display surface update? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 14/19] lcd: Add support for flushing LCD fb from dcache after update
On 06/13/2012 10:19 AM, Simon Glass wrote:
> This provides an option for the LCD to flush the dcache after each update
> (puts, scroll or clear).
> diff --git a/common/cmd_echo.c b/common/cmd_echo.c
> + /* Use puts() so that the LCD sees it as a new line */
> if (putnl)
> - putc('\n');
> + puts("\n");
That seems fragile - what if someone comes along and uses putc() in some
other code without having a clue that this requirement exists? What
stops putc() from detecting \n just like puts()?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 V6] EXYNOS5: PINMUX: Added default pinumx settings
On 10 June 2012 05:13, Simon Glass wrote: > On Wed, Jun 6, 2012 at 10:54 PM, Rajeshwari Shinde > wrote: > >> This patch performs the pinmux configuration in a common file. >> As of now only EXYNOS5 pinmux for SDMMC, UART and Ethernet is >> supported. >> >> Signed-off-by: Abhilash Kesavan >> Signed-off-by: Che-Liang Chiou >> Signed-off-by: Rajeshwari Shinde >> Acked-by: Chander Kashyap >> Acked-by: Simon Glass >> > > Acked-by: Simon Glass > > >> --- >> Changes in V2: >> - Adding pinmux.c to Makefile moved to this patch. >> - exynos5_pinmux_config made static >> Changes in V3: >> - Separate functions made for each peripheral >> - enum periph_id moved to a separate periph.h >> Changes in V4: >> - removed variable declarations from exynos5_pinmux_config >> Changes in V5: >> - added a return statement for function exynos5_mmc_config >> and added a check for same >> Changes in V6: >> - Added a blank line >> arch/arm/cpu/armv7/exynos/Makefile | 2 +- >> arch/arm/cpu/armv7/exynos/pinmux.c | 220 >> + >> arch/arm/include/asm/arch-exynos/periph.h | 47 ++ >> arch/arm/include/asm/arch-exynos/pinmux.h | 58 >> 4 files changed, 326 insertions(+), 1 deletions(-) >> create mode 100644 arch/arm/cpu/armv7/exynos/pinmux.c >> create mode 100644 arch/arm/include/asm/arch-exynos/periph.h >> create mode 100644 arch/arm/include/asm/arch-exynos/pinmux.h >> applied to u-boot-samsung. Thanks. Minkyu Kang. -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 V6] EXYNOS: SMDK5250: Enable the pinmux setup
On 10 June 2012 05:15, Simon Glass wrote: > On Wed, Jun 6, 2012 at 10:54 PM, Rajeshwari Shinde > wrote: > >> Use the pinmux configuration function for SMDK5250. >> >> Signed-off-by: Abhilash Kesavan >> Signed-off-by: Rajeshwari Shinde >> Acked-by: Chander Kashyap >> Acked-by: Simon Glass >> > > Acked-by: Simon Glass > > >> --- >> Changes in V2: >> - Removed exynos5_gpio_part1 *gpio1 global variable as initialised >> in >> pinmux.c. >> Changes in V3: >> - Added a error return for smc9115_pre_init and board_uart_init. >> Changes in V6: >> - none >> board/samsung/smdk5250/smdk5250.c | 176 >> - > applied to u-boot-samsung. Thanks. Minkyu Kang. -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] cache_v7: Check for dcache enablement in dcache flush functions
Hi Tom,
On Fri, Jun 15, 2012 at 12:31 AM, Tom Rini wrote:
> If we are built with D-CACHE enabled but have run 'dcache off' and then
> attempt to flush unaligned regions we spam the console with problems
> that aren't true (as the cache was off).
>
Today we do cache maintenance operations after the dcache is turned off.
One example is before jumping to kernel, we try to invalidate the caches,
in cache turned off state. So with this patch those maintenance calls will
do nothing, which is not correct.
If it is a problem with unaligned regions, then that is the only
thing to be fixed
right ?. Just trying to understand why this change is required ?
Thanks,
Sricharan
> Signed-off-by: Tom Rini
> ---
> arch/arm/cpu/armv7/cache_v7.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm/cpu/armv7/cache_v7.c b/arch/arm/cpu/armv7/cache_v7.c
> index 1b4e808..1c0f5b0 100644
> --- a/arch/arm/cpu/armv7/cache_v7.c
> +++ b/arch/arm/cpu/armv7/cache_v7.c
> @@ -250,6 +250,9 @@ static void v7_inval_tlb(void)
>
> void invalidate_dcache_all(void)
> {
> + if (!dcache_status())
> + return;
> +
> v7_maint_dcache_all(ARMV7_DCACHE_INVAL_ALL);
>
> v7_outer_cache_inval_all();
> @@ -261,6 +264,9 @@ void invalidate_dcache_all(void)
> */
> void flush_dcache_all(void)
> {
> + if (!dcache_status())
> + return;
> +
> v7_maint_dcache_all(ARMV7_DCACHE_CLEAN_INVAL_ALL);
>
> v7_outer_cache_flush_all();
> @@ -272,6 +278,8 @@ void flush_dcache_all(void)
> */
> void invalidate_dcache_range(unsigned long start, unsigned long stop)
> {
> + if (!dcache_status())
> + return;
>
> v7_dcache_maint_range(start, stop, ARMV7_DCACHE_INVAL_RANGE);
>
> @@ -285,6 +293,9 @@ void invalidate_dcache_range(unsigned long start,
> unsigned long stop)
> */
> void flush_dcache_range(unsigned long start, unsigned long stop)
> {
> + if (!dcache_status())
> + return;
> +
> v7_dcache_maint_range(start, stop, ARMV7_DCACHE_CLEAN_INVAL_RANGE);
>
> v7_outer_cache_flush_range(start, stop);
> --
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
