* [U-Boot] [PATCH 09/39] GCC4.6: Squash warning in cfb_console.c
From: Marek Vasut @ 2011-10-22 0:17 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319242654-15534-1-git-send-email-marek.vasut@gmail.com>
cfb_console.c: In function 'video_display_bitmap':
cfb_console.c:1148: warning: format '%d' expects type 'int', but argument 2 has
type 'long unsigned int'
cfb_console.c:1148: warning: format '%d' expects type 'int', but argument 3 has
type 'long unsigned int'
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Mike Frysinger <vapier@gentoo.org>
---
drivers/video/cfb_console.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
index 3a93b64..f590250 100644
--- a/drivers/video/cfb_console.c
+++ b/drivers/video/cfb_console.c
@@ -1145,7 +1145,7 @@ int video_display_bitmap(ulong bmp_image, int x, int y)
colors = le32_to_cpu(bmp->header.colors_used);
compression = le32_to_cpu(bmp->header.compression);
- debug("Display-bmp: %d x %d with %d colors\n",
+ debug("Display-bmp: %ld x %ld with %d colors\n",
width, height, colors);
if (compression != BMP_BI_RGB
--
1.7.6.3
^ permalink raw reply related
* [U-Boot] [PATCH 08/39] GCC4.6: Squash warning in mpc5121ads.c
From: Marek Vasut @ 2011-10-22 0:17 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319242654-15534-1-git-send-email-marek.vasut@gmail.com>
mpc5121ads.c: In function 'misc_init_r':
mpc5121ads.c:256: warning: format '%02lx' expects type 'long unsigned int', but
argument 2 has type 'int'
mpc5121ads.c:263: warning: format '%02lx' expects type 'long unsigned int', but
argument 2 has type 'int'
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Mike Frysinger <vapier@gentoo.org>
---
board/freescale/mpc5121ads/mpc5121ads.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/freescale/mpc5121ads/mpc5121ads.c b/board/freescale/mpc5121ads/mpc5121ads.c
index b356a47..97eeab3 100644
--- a/board/freescale/mpc5121ads/mpc5121ads.c
+++ b/board/freescale/mpc5121ads/mpc5121ads.c
@@ -253,14 +253,14 @@ int misc_init_r(void)
/* Verify if enabled */
tmp_val = 0;
i2c_read(0x38, 0x08, 1, &tmp_val, sizeof(tmp_val));
- debug("DVI Encoder Read: 0x%02lx\n", tmp_val);
+ debug("DVI Encoder Read: 0x%02x\n", tmp_val);
tmp_val = 0x10;
i2c_write(0x38, 0x0A, 1, &tmp_val, sizeof(tmp_val));
/* Verify if enabled */
tmp_val = 0;
i2c_read(0x38, 0x0A, 1, &tmp_val, sizeof(tmp_val));
- debug("DVI Encoder Read: 0x%02lx\n", tmp_val);
+ debug("DVI Encoder Read: 0x%02x\n", tmp_val);
return 0;
}
--
1.7.6.3
^ permalink raw reply related
* [U-Boot] [PATCH 07/39] PowerPC: Squash warning in mpc512x serial.c
From: Marek Vasut @ 2011-10-22 0:17 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319242654-15534-1-git-send-email-marek.vasut@gmail.com>
serial.c: In function 'serial_setbrg_dev':
serial.c:143: warning: format '%d' expects type 'int', but argument 4 has type
'long unsigned int'
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Mike Frysinger <vapier@gentoo.org>
---
arch/powerpc/cpu/mpc512x/serial.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/cpu/mpc512x/serial.c b/arch/powerpc/cpu/mpc512x/serial.c
index 5ee9cef..7c53346 100644
--- a/arch/powerpc/cpu/mpc512x/serial.c
+++ b/arch/powerpc/cpu/mpc512x/serial.c
@@ -140,7 +140,7 @@ void serial_setbrg_dev(unsigned int idx)
if (br_env)
baudrate = simple_strtoul(br_env, NULL, 10);
- debug("%s: idx %d, baudrate %d\n", __func__, idx, baudrate);
+ debug("%s: idx %d, baudrate %ld\n", __func__, idx, baudrate);
}
/* calculate divisor for setting PSC CTUR and CTLR registers */
--
1.7.6.3
^ permalink raw reply related
* [U-Boot] [PATCH 06/39] GCC4.6: Squash subsequent warnings in usb_storage.c
From: Marek Vasut @ 2011-10-22 0:17 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319242654-15534-1-git-send-email-marek.vasut@gmail.com>
usb_storage.c: In function ?us_one_transfer?:
usb_storage.c:377:7: warning: format ?%X? expects argument of type ?unsigned
int?, but argument 2 has type ?long unsigned int? [-Wformat]
usb_storage.c:389:6: warning: format ?%d? expects argument of type ?int?, but
argument 2 has type ?long unsigned int? [-Wformat]
usb_storage.c:394:6: warning: format ?%d? expects argument of type ?int?, but
argument 2 has type ?long unsigned int? [-Wformat]
usb_storage.c: In function ?usb_stor_BBB_reset?:
usb_storage.c:442:2: warning: format ?%X? expects argument of type ?unsigned
int?, but argument 3 has type ?long unsigned int? [-Wformat]
usb_storage.c:448:2: warning: format ?%X? expects argument of type ?unsigned
int?, but argument 3 has type ?long unsigned int? [-Wformat]
usb_storage.c:454:2: warning: format ?%X? expects argument of type ?unsigned
int?, but argument 3 has type ?long unsigned int? [-Wformat]
usb_storage.c: In function ?usb_stor_CB_reset?:
usb_storage.c:482:2: warning: format ?%X? expects argument of type ?unsigned
int?, but argument 3 has type ?long unsigned int? [-Wformat]
usb_storage.c: In function ?usb_stor_CB_comdat?:
usb_storage.c:572:3: warning: format ?%X? expects argument of type ?unsigned
int?, but argument 3 has type ?long unsigned int? [-Wformat]
usb_storage.c:584:4: warning: format ?%X? expects argument of type ?unsigned
int?, but argument 3 has type ?long unsigned int? [-Wformat]
usb_storage.c: In function ?usb_stor_BBB_transport?:
usb_storage.c:782:3: warning: format ?%d? expects argument of type ?int?, but
argument 3 has type ?long unsigned int? [-Wformat]
usb_storage.c: In function ?usb_stor_CB_transport?:
usb_storage.c:807:2: warning: format ?%X? expects argument of type ?unsigned
int?, but argument 3 has type ?long unsigned int? [-Wformat]
usb_storage.c:830:3: warning: format ?%X? expects argument of type ?unsigned
int?, but argument 2 has type ?long unsigned int? [-Wformat]
usb_storage.c:857:3: warning: format ?%d? expects argument of type ?int?, but
argument 2 has type ?long unsigned int? [-Wformat]
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Remy Bohmer <linux@bohmer.net>
---
common/usb_storage.c | 26 +++++++++++++-------------
1 files changed, 13 insertions(+), 13 deletions(-)
NOTE: Checkpatch issue here would need much deeper rework of the usb_storage.c,
please bear with it.
Remy, can you take care of this please? ;-)
diff --git a/common/usb_storage.c b/common/usb_storage.c
index eb9a30e..d665a87 100644
--- a/common/usb_storage.c
+++ b/common/usb_storage.c
@@ -373,7 +373,7 @@ static int us_one_transfer(struct us_data *us, int pipe, char *buf, int length)
usb_clear_halt(us->pusb_dev, pipe);
us->pusb_dev->status = stat;
if (this_xfer == partial) {
- USB_STOR_PRINTF("bulk transferred with error %X, but data ok\n", us->pusb_dev->status);
+ USB_STOR_PRINTF("bulk transferred with error %lX, but data ok\n", us->pusb_dev->status);
return 0;
}
else
@@ -385,12 +385,12 @@ static int us_one_transfer(struct us_data *us, int pipe, char *buf, int length)
}
USB_STOR_PRINTF("bulk transferred with error");
if (this_xfer == partial) {
- USB_STOR_PRINTF(" %d, but data ok\n",
+ USB_STOR_PRINTF(" %ld, but data ok\n",
us->pusb_dev->status);
return 0;
}
/* if our try counter reaches 0, bail out */
- USB_STOR_PRINTF(" %d, data %d\n",
+ USB_STOR_PRINTF(" %ld, data %d\n",
us->pusb_dev->status, partial);
if (!maxtry--)
return result;
@@ -438,19 +438,19 @@ static int usb_stor_BBB_reset(struct us_data *us)
/* long wait for reset */
wait_ms(150);
- USB_STOR_PRINTF("BBB_reset result %d: status %X reset\n", result,
+ USB_STOR_PRINTF("BBB_reset result %d: status %lX reset\n", result,
us->pusb_dev->status);
pipe = usb_rcvbulkpipe(us->pusb_dev, us->ep_in);
result = usb_clear_halt(us->pusb_dev, pipe);
/* long wait for reset */
wait_ms(150);
- USB_STOR_PRINTF("BBB_reset result %d: status %X clearing IN endpoint\n",
+ USB_STOR_PRINTF("BBB_reset result %d: status %lX clearing IN endpoint\n",
result, us->pusb_dev->status);
/* long wait for reset */
pipe = usb_sndbulkpipe(us->pusb_dev, us->ep_out);
result = usb_clear_halt(us->pusb_dev, pipe);
wait_ms(150);
- USB_STOR_PRINTF("BBB_reset result %d: status %X"
+ USB_STOR_PRINTF("BBB_reset result %d: status %lX"
" clearing OUT endpoint\n", result,
us->pusb_dev->status);
USB_STOR_PRINTF("BBB_reset done\n");
@@ -478,7 +478,7 @@ static int usb_stor_CB_reset(struct us_data *us)
/* long wait for reset */
wait_ms(1500);
- USB_STOR_PRINTF("CB_reset result %d: status %X"
+ USB_STOR_PRINTF("CB_reset result %d: status %lX"
" clearing endpoint halt\n", result,
us->pusb_dev->status);
usb_clear_halt(us->pusb_dev, usb_rcvbulkpipe(us->pusb_dev, us->ep_in));
@@ -569,7 +569,7 @@ int usb_stor_CB_comdat(ccb *srb, struct us_data *us)
srb->cmd, srb->cmdlen,
USB_CNTL_TIMEOUT * 5);
USB_STOR_PRINTF("CB_transport: control msg returned %d,"
- " status %X\n", result, us->pusb_dev->status);
+ " status %lX\n", result, us->pusb_dev->status);
/* check the return code for the command */
if (result < 0) {
if (us->pusb_dev->status & USB_ST_STALLED) {
@@ -581,7 +581,7 @@ int usb_stor_CB_comdat(ccb *srb, struct us_data *us)
us->pusb_dev->status = status;
}
USB_STOR_PRINTF(" error during command %02X"
- " Stat = %X\n", srb->cmd[0],
+ " Stat = %lX\n", srb->cmd[0],
us->pusb_dev->status);
return result;
}
@@ -778,7 +778,7 @@ again:
usb_stor_BBB_reset(us);
return USB_STOR_TRANSPORT_FAILED;
} else if (data_actlen > srb->datalen) {
- USB_STOR_PRINTF("transferred %dB instead of %dB\n",
+ USB_STOR_PRINTF("transferred %dB instead of %ldB\n",
data_actlen, srb->datalen);
return USB_STOR_TRANSPORT_FAILED;
} else if (csw.bCSWStatus == CSWSTATUS_FAILED) {
@@ -803,7 +803,7 @@ int usb_stor_CB_transport(ccb *srb, struct us_data *us)
/* issue the command */
do_retry:
result = usb_stor_CB_comdat(srb, us);
- USB_STOR_PRINTF("command / Data returned %d, status %X\n",
+ USB_STOR_PRINTF("command / Data returned %d, status %lX\n",
result, us->pusb_dev->status);
/* if this is an CBI Protocol, get IRQ */
if (us->protocol == US_PR_CBI) {
@@ -826,7 +826,7 @@ do_retry:
/* do we have to issue an auto request? */
/* HERE we have to check the result */
if ((result < 0) && !(us->pusb_dev->status & USB_ST_STALLED)) {
- USB_STOR_PRINTF("ERROR %X\n", us->pusb_dev->status);
+ USB_STOR_PRINTF("ERROR %lX\n", us->pusb_dev->status);
us->transport_reset(us);
return USB_STOR_TRANSPORT_ERROR;
}
@@ -853,7 +853,7 @@ do_retry:
status = usb_stor_CBI_get_status(psrb, us);
if ((result < 0) && !(us->pusb_dev->status & USB_ST_STALLED)) {
- USB_STOR_PRINTF(" AUTO REQUEST ERROR %d\n",
+ USB_STOR_PRINTF(" AUTO REQUEST ERROR %ld\n",
us->pusb_dev->status);
return USB_STOR_TRANSPORT_ERROR;
}
--
1.7.6.3
^ permalink raw reply related
* [U-Boot] [PATCH 05/39] GCC4.6: Squash warning in usb_storage.c
From: Marek Vasut @ 2011-10-22 0:17 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319242654-15534-1-git-send-email-marek.vasut@gmail.com>
usb_storage.c: In function ?usb_stor_CB_reset?:
usb_storage.c:466:6: warning: variable ?result? set but not used
[-Wunused-but-set-variable]
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Mike Frysinger <vapier@gentoo.org>
---
common/usb_storage.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/common/usb_storage.c b/common/usb_storage.c
index 16667f3..eb9a30e 100644
--- a/common/usb_storage.c
+++ b/common/usb_storage.c
@@ -56,16 +56,17 @@
#include <part.h>
#include <usb.h>
-#undef USB_STOR_DEBUG
#undef BBB_COMDAT_TRACE
#undef BBB_XPORT_TRACE
#ifdef USB_STOR_DEBUG
-#define USB_STOR_PRINTF(fmt, args...) printf(fmt , ##args)
+#define USB_BLK_DEBUG 1
#else
-#define USB_STOR_PRINTF(fmt, args...)
+#define USB_BLK_DEBUG 0
#endif
+#define USB_STOR_PRINTF(fmt, args...) debug_cond(USB_BLK_DEBUG, fmt, ##args)
+
#include <scsi.h>
/* direction table -- this indicates the direction of the data
* transfer for each command code -- a 1 indicates input
--
1.7.6.3
^ permalink raw reply related
* [U-Boot] [PATCH 04/39] GCC4.6: Squash warning in cmd_date.c
From: Marek Vasut @ 2011-10-22 0:16 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319242654-15534-1-git-send-email-marek.vasut@gmail.com>
cmd_date.c: In function ?do_date?:
cmd_date.c:50:6: warning: variable ?old_bus? set but not used
[-Wunused-but-set-variable]
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Mike Frysinger <vapier@gentoo.org>
---
include/i2c.h | 32 +++++++++++++++++++++++---------
1 files changed, 23 insertions(+), 9 deletions(-)
diff --git a/include/i2c.h b/include/i2c.h
index 8ceb4c8..ee31034 100644
--- a/include/i2c.h
+++ b/include/i2c.h
@@ -46,16 +46,16 @@
*/
#define I2C_RXTX_LEN 128 /* maximum tx/rx buffer length */
-#if defined(CONFIG_I2C_MULTI_BUS)
-#if !defined(CONFIG_SYS_MAX_I2C_BUS)
-#define CONFIG_SYS_MAX_I2C_BUS 2
-#endif
-#define I2C_GET_BUS() i2c_get_bus_num()
-#define I2C_SET_BUS(a) i2c_set_bus_num(a)
+#ifdef CONFIG_I2C_MULTI_BUS
+#define MAX_I2C_BUS 2
+#define I2C_MULTI_BUS 1
#else
-#define CONFIG_SYS_MAX_I2C_BUS 1
-#define I2C_GET_BUS() 0
-#define I2C_SET_BUS(a)
+#define MAX_I2C_BUS 1
+#define I2C_MULTI_BUS 0
+#endif
+
+#if !defined(CONFIG_SYS_MAX_I2C_BUS)
+#define CONFIG_SYS_MAX_I2C_BUS MAX_I2C_BUS
#endif
/* define the I2C bus number for RTC and DTT if not already done */
@@ -236,4 +236,18 @@ int i2c_set_bus_speed(unsigned int);
unsigned int i2c_get_bus_speed(void);
+/* NOTE: These two functions MUST be always_inline to avoid code growth! */
+static inline unsigned int I2C_GET_BUS(void) __attribute__((always_inline));
+static inline unsigned int I2C_GET_BUS(void)
+{
+ return I2C_MULTI_BUS ? i2c_get_bus_num() : 0;
+}
+
+static inline void I2C_SET_BUS(unsigned int bus) __attribute__((always_inline));
+static inline void I2C_SET_BUS(unsigned int bus)
+{
+ if (I2C_MULTI_BUS)
+ i2c_set_bus_num(bus);
+}
+
#endif /* _I2C_H_ */
--
1.7.6.3
^ permalink raw reply related
* [U-Boot] [PATCH 03/39] GCC4.6: Squash warning in cmd_ide.c
From: Marek Vasut @ 2011-10-22 0:16 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319242654-15534-1-git-send-email-marek.vasut@gmail.com>
cmd_ide.c: In function ?ide_read?:
cmd_ide.c:1227:2: warning: format ?%LX? expects argument of type ?long long
unsigned int?, but argument 3 has type ?lbaint_t? [-Wformat]
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Mike Frysinger <vapier@gentoo.org>
---
common/cmd_ide.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/cmd_ide.c b/common/cmd_ide.c
index da5189c..74e6504 100644
--- a/common/cmd_ide.c
+++ b/common/cmd_ide.c
@@ -1224,7 +1224,7 @@ ulong ide_read (int device, lbaint_t blknr, ulong blkcnt, void *buffer)
lba48 = 1;
}
#endif
- debug ("ide_read dev %d start %LX, blocks %lX buffer at %lX\n",
+ debug("ide_read dev %d start %lX, blocks %lX buffer at %lX\n",
device, blknr, blkcnt, (ulong)buffer);
ide_led (DEVICE_LED(device), 1); /* LED on */
--
1.7.6.3
^ permalink raw reply related
* [U-Boot] [PATCH 02/39] GCC4.6: Squash warnings in common/usb.c
From: Marek Vasut @ 2011-10-22 0:16 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319242654-15534-1-git-send-email-marek.vasut@gmail.com>
usb.c: In function ?usb_parse_config?:
usb.c:331:17: warning: variable ?ch? set but not used
[-Wunused-but-set-variable]
usb.c: In function ?usb_hub_port_connect_change?:
usb.c:1123:29: warning: variable ?portchange? set but not used
[-Wunused-but-set-variable]
usb.c: In function ?usb_hub_configure?:
usb.c:1183:25: warning: variable ?hubsts? set but not used
[-Wunused-but-set-variable]
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Mike Frysinger <vapier@gentoo.org>
---
common/usb.c | 21 +++++++--------------
1 files changed, 7 insertions(+), 14 deletions(-)
diff --git a/common/usb.c b/common/usb.c
index 2cd50db..bed5116 100644
--- a/common/usb.c
+++ b/common/usb.c
@@ -56,16 +56,16 @@
#endif
#ifdef DEBUG
-#define USB_DEBUG
-#define USB_HUB_DEBUG
-#endif
-
-#ifdef USB_DEBUG
-#define USB_PRINTF(fmt, args...) printf(fmt , ##args)
+#define USB_DEBUG 1
+#define USB_HUB_DEBUG 1
#else
-#define USB_PRINTF(fmt, args...)
+#define USB_DEBUG 0
+#define USB_HUB_DEBUG 0
#endif
+#define USB_PRINTF(fmt, args...) debug_cond(USB_DEBUG, fmt, ##args)
+#define USB_HUB_PRINTF(fmt, args...) debug_cond(USB_HUB_DEBUG, fmt, ##args)
+
#define USB_BUFSIZ 512
static struct usb_device usb_dev[USB_MAX_DEVICE];
@@ -968,13 +968,6 @@ void usb_scan_devices(void)
* Probes device for being a hub and configurate it
*/
-#ifdef USB_HUB_DEBUG
-#define USB_HUB_PRINTF(fmt, args...) printf(fmt , ##args)
-#else
-#define USB_HUB_PRINTF(fmt, args...)
-#endif
-
-
static struct usb_hub_device hub_dev[USB_MAX_HUB];
static int usb_hub_index;
--
1.7.6.3
^ permalink raw reply related
* [U-Boot] [PATCH 01/39] DEBUG: Fix debug macros
From: Marek Vasut @ 2011-10-22 0:16 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319242654-15534-1-git-send-email-marek.vasut@gmail.com>
The current implementation of debug doesn't play well with GCC4.6.
This implementation also fixes GCC4.6 complaints about unused variables
while maintaining code size.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Simon Glass <sjg@chromium.org>
---
include/common.h | 20 ++++++++++++--------
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/include/common.h b/include/common.h
index eb19a44..c3b23551 100644
--- a/include/common.h
+++ b/include/common.h
@@ -116,20 +116,24 @@ typedef volatile unsigned char vu_char;
#include <flash.h>
#include <image.h>
-#ifdef DEBUG
-#define debug(fmt,args...) printf (fmt ,##args)
-#define debugX(level,fmt,args...) if (DEBUG>=level) printf(fmt,##args);
-#else
-#define debug(fmt,args...)
-#define debugX(level,fmt,args...)
-#endif /* DEBUG */
-
#ifdef DEBUG
# define _DEBUG 1
#else
# define _DEBUG 0
#endif
+#define debug_cond(cond, fmt, args...) \
+ do { \
+ if (cond) \
+ printf(fmt, ##args); \
+ } while (0)
+
+#define debug(fmt, args...) \
+ debug_cond(_DEBUG, fmt, ##args)
+
+#define debugX(level, fmt, args...) \
+ debug_cond((_DEBUG && DEBUG >= (level)), fmt, ##args)
+
/*
* An assertion is run-time check done in debug mode only. If DEBUG is not
* defined then it is skipped. If DEBUG is defined and the assertion fails,
--
1.7.6.3
^ permalink raw reply related
* [U-Boot] [RFC] [PATCH 00/39] Rework of the debug() macro
From: Marek Vasut @ 2011-10-22 0:16 UTC (permalink / raw)
To: u-boot
This patch series reworks the debug() and debugX() macro in include/common.h to
be compatible with GCC 4.6.
This series needs further discussion:
* Some files suffer size growth with gcc4.2, why ?
- Possibility is that the GCC4.2 is incapable to optimize code out so deep
* Does this change break any platforms? Compile tested on PowerPC.
- Please run MAKEALL on your platforms to test this.
Marek Vasut (39):
DEBUG: Fix debug macros
GCC4.6: Squash warnings in common/usb.c
GCC4.6: Squash warning in cmd_ide.c
GCC4.6: Squash warning in cmd_date.c
GCC4.6: Squash warning in usb_storage.c
GCC4.6: Squash subsequent warnings in usb_storage.c
PowerPC: Squash warning in mpc512x serial.c
GCC4.6: Squash warning in mpc5121ads.c
GCC4.6: Squash warning in cfb_console.c
GCC4.6: Squash warning in cfi_flash.c
GCC4.6: Squash warnings in denali_data_eye.c
GCC4.6: Squash warnings in denali_spd_ddr2.c
GCC4.6: Squash warnings in diu.c
GCC4.6: Squash warnings in mpc8610hpcd.c
GCC4.6: Squash warnings in tqm834x.c
GCC4.6: Squash warning in jedec_flash.c
GCC4.6: Squash warnings in 44x_spd_ddr.c
GCC4.6: Squash warnings in 4xx_enet.c
GCC4.6: Squash warnings in 4xx_ibm_ddr2_autocalib.c
GCC4.6: Squash warnings in 4xx_pcie.c
GCC4.6: Squash warnings in ahci.c
GCC4.6: Squash warning in cmd_pmc440.c
GCC4.6: Use dst instead of l2srbar in cpu_early_init.c
GCC4.6: Squash warnings in ddr[123]_dimm_params.c
GCC4.6: Squash warnings in fsl_espi.c
GCC4.6: Squash warnings in fsl_pci_init.c
GCC4.6: Squash warnings in pmc405de.c
GCC4.6: Squash warnings in sata_sil3114.c
GCC4.6: Squash warnings in tqm8xx_pcmcia.c
GCC4.6: Squash undefined variable in cmd_mtdparts.c
GCC4.6: Squash warnings in serial_xuartlite.c
GCC4.6: Squash warnings in mpc86xx/interrupts.c
GCC4.6: Squash warnings in r360mpi/flash.c
GCC4.6: Squash warnings in PPChameleonEVB/flash.c
GCC4.6: Squash error in pcmcia/i82365.c
GCC4.6: Squash error in cpc45/pd67290.c
RFT GCC4.6: Fix muas3001 and IDS8247
GCC4.6: Squash GTREADREG related errors
GCC4.6: Add macros to mv_gen_reg.h
arch/powerpc/cpu/mpc512x/serial.c | 2 +-
arch/powerpc/cpu/mpc85xx/cpu_init_early.c | 4 +-
arch/powerpc/cpu/mpc86xx/interrupts.c | 12 +++---
arch/powerpc/cpu/mpc8xxx/ddr/ddr1_dimm_params.c | 2 +-
arch/powerpc/cpu/mpc8xxx/ddr/ddr2_dimm_params.c | 2 +-
arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c | 2 +-
arch/powerpc/cpu/ppc4xx/44x_spd_ddr.c | 17 ++++---
arch/powerpc/cpu/ppc4xx/4xx_ibm_ddr2_autocalib.c | 8 ++--
arch/powerpc/cpu/ppc4xx/4xx_pcie.c | 3 +-
arch/powerpc/cpu/ppc4xx/denali_data_eye.c | 10 ++--
arch/powerpc/cpu/ppc4xx/denali_spd_ddr2.c | 52 +++++++++++-----------
board/Marvell/include/mv_gen_reg.h | 8 +++
board/cpc45/pd67290.c | 6 +--
board/dave/PPChameleonEVB/flash.c | 3 +-
board/esd/pmc405de/pmc405de.c | 2 +-
board/esd/pmc440/cmd_pmc440.c | 2 +-
board/freescale/mpc5121ads/mpc5121ads.c | 4 +-
board/freescale/mpc8610hpcd/mpc8610hpcd.c | 4 +-
board/freescale/p1022ds/diu.c | 2 +-
board/r360mpi/flash.c | 4 +-
board/tqc/tqm834x/tqm834x.c | 6 +-
common/cmd_ide.c | 2 +-
common/cmd_mtdparts.c | 2 -
common/usb.c | 21 +++------
common/usb_storage.c | 33 +++++++-------
drivers/block/ahci.c | 2 +-
drivers/block/sata_sil3114.c | 2 +-
drivers/mtd/cfi_flash.c | 2 +-
drivers/mtd/jedec_flash.c | 5 +-
drivers/net/4xx_enet.c | 6 +-
drivers/pci/fsl_pci_init.c | 8 ++--
drivers/pcmcia/i82365.c | 6 +--
drivers/pcmcia/tqm8xx_pcmcia.c | 15 +++++-
drivers/serial/serial_xuartlite.c | 2 +-
drivers/spi/fsl_espi.c | 6 +-
drivers/video/cfb_console.c | 2 +-
include/common.h | 20 +++++---
include/configs/IDS8247.h | 4 ++
include/configs/PCIPPC2.h | 4 ++
include/configs/PCIPPC6.h | 4 ++
include/configs/mpc7448hpc2.h | 4 ++
include/configs/muas3001.h | 4 ++
include/configs/p3mx.h | 4 ++
include/configs/ppmc7xx.h | 4 ++
include/i2c.h | 32 ++++++++++----
45 files changed, 201 insertions(+), 148 deletions(-)
Cc: Wolfgang Denk <wd@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Mike Frysinger <vapier@gentoo.org>
--
1.7.6.3
^ permalink raw reply
* SCSI HA problems
From: Michael Robbert @ 2011-10-22 0:08 UTC (permalink / raw)
To: linux-scsi@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 814 bytes --]
I want some technical advice from the SCSI/SAS/SATA experts. We are trying to setup a low cost HA storage system with multiple servers that have SAS HBAs, SAS JBOD, and desktop SATA disks. When we first set it up everything appeared to work. I created RAID6 on one host and put it into a corosync/pacemaker config. I was then able to migrate the RAID from one host to another. A short while later a failover failed and I noticed that some of the drives became inaccessible on one of the hosts. The kernel was showing timeouts to the device.
Oct 21 17:55:34 haraid-12-1 kernel: sd 1:0:3:0: timing out command, waited 10s
So, my question is this, is this setup technically possible or are the 2 HBAs going to conflict with each other when talking over the same SAS bus to the SATA drives?
Thanks,
Mike
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* RE: [PATCH -v2 -mm] add extra free kbytes tunable
From: Satoru Moriya @ 2011-10-22 0:11 UTC (permalink / raw)
To: David Rientjes, Rik van Riel
Cc: Randy Dunlap, Satoru Moriya, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, lwoodman@redhat.com, Seiji Aguchi,
Andrew Morton, Hugh Dickins, hannes@cmpxchg.org
In-Reply-To: <alpine.DEB.2.00.1110122210030.7572@chino.kir.corp.google.com>
On 10/13/2011 01:22 AM, David Rientjes wrote:
> On Thu, 13 Oct 2011, Rik van Riel wrote:
>
>> Furthermore, I am not sure that giving kswapd more CPU time is
>> going to help, because kswapd could be stuck on some lock, held
>> by a lower priority (or sleeping) context.
>>
>> I agree that the BFS patch would be worth a try, and would be
>> very pleasantly surprised if it worked, but I am not very
>> optimistic about it...
>>
>
> It may require a combination of Con's patch, increasing the priority of
> kswapd if a higher priority task kicks it in the page allocator, and an
> extra bonus on top of the high watermark if it was triggered by a
> rt-thread -- similar to ALLOC_HARDER but instead reclaiming to
> (high * 1.25).
I tested Con's patch. The results are following.
1. delayacct result
RECLAIM count delay total delay average
---------------------------------------------------------------
normal task w/o Con's patch 210 42685857 203us
rt task w/o Con's patch 32 4922368 153us
rt task w Con's patch 29 4399320 151us
2. /proc/vmstat result
normal task w/o rt task w/o rt task w/
Con's patch Con's patch Con's patch
---------------------------------------------------------------------
nr_vmscan_write 0 13160 14536
pgsteal_dma 0 0 0
pgsteal_dma32 182710 175049 169871
pgsteal_normal 10260 9499 13077
pgsteal_movable 0 0 0
pgscan_kswapd_dma 0 0 0
pgscan_kswapd_dma32 127159 149096 147924
pgscan_kswapd_normal 26094 49011 33186
pgscan_kswapd_movable 0 0 0
pgscan_direct_dma 0 0 0
pgscan_direct_dma32 55551 25923 21947
pgscan_direct_normal 7128 3624 2816
pgscan_direct_movable 0 0 0
kswapd_steal 134481 157951 159556
kswapd_inodesteal 0 0 0
kswapd_low_wmark_hit_quickly 0 0 6
kswapd_high_wmark_hit_quickly 0 0 0
allocstall 324 151 128
Unfortunately, it seems that Con's patch does not improve my
testcase so much. We may need extra bonus on the high watermark if
we take the way above. But necessary bonus depends on workloads,
hardware etc., so it can't be solved with fixed bonus, I think.
> If we're going to go with extra_free_kbytes, then I'd like to see the test
> case posted with a mathematical formula to show me what I should tune it
> to be depending on my machine's memory capacity and amount of free RAM
> when started (and I can use mem= to test it for various capacities). For
> this to be merged, there should be a clear expression that shows what the
> ideal setting of the tunable should be rather than asking for trial-and-
> error to see what works and what doesn't. If such an expression doesn't
> exist, then it's clear that the necessary setting will vary significantly
> as the implementation changes from kernel to kernel.
Hmm, try and error is tuning itself, isn't it? When we tune a system,
we usually set some knobs, run some benchmarks/tests/etc., evaluate
the results and decide which is the appropriate value.
Regards,
Satoru
^ permalink raw reply
* RE: [PATCH -v2 -mm] add extra free kbytes tunable
From: Satoru Moriya @ 2011-10-22 0:11 UTC (permalink / raw)
To: David Rientjes, Rik van Riel
Cc: Randy Dunlap, Satoru Moriya, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, lwoodman@redhat.com, Seiji Aguchi,
Andrew Morton, Hugh Dickins, hannes@cmpxchg.org
In-Reply-To: <alpine.DEB.2.00.1110122210030.7572@chino.kir.corp.google.com>
On 10/13/2011 01:22 AM, David Rientjes wrote:
> On Thu, 13 Oct 2011, Rik van Riel wrote:
>
>> Furthermore, I am not sure that giving kswapd more CPU time is
>> going to help, because kswapd could be stuck on some lock, held
>> by a lower priority (or sleeping) context.
>>
>> I agree that the BFS patch would be worth a try, and would be
>> very pleasantly surprised if it worked, but I am not very
>> optimistic about it...
>>
>
> It may require a combination of Con's patch, increasing the priority of
> kswapd if a higher priority task kicks it in the page allocator, and an
> extra bonus on top of the high watermark if it was triggered by a
> rt-thread -- similar to ALLOC_HARDER but instead reclaiming to
> (high * 1.25).
I tested Con's patch. The results are following.
1. delayacct result
RECLAIM count delay total delay average
---------------------------------------------------------------
normal task w/o Con's patch 210 42685857 203us
rt task w/o Con's patch 32 4922368 153us
rt task w Con's patch 29 4399320 151us
2. /proc/vmstat result
normal task w/o rt task w/o rt task w/
Con's patch Con's patch Con's patch
---------------------------------------------------------------------
nr_vmscan_write 0 13160 14536
pgsteal_dma 0 0 0
pgsteal_dma32 182710 175049 169871
pgsteal_normal 10260 9499 13077
pgsteal_movable 0 0 0
pgscan_kswapd_dma 0 0 0
pgscan_kswapd_dma32 127159 149096 147924
pgscan_kswapd_normal 26094 49011 33186
pgscan_kswapd_movable 0 0 0
pgscan_direct_dma 0 0 0
pgscan_direct_dma32 55551 25923 21947
pgscan_direct_normal 7128 3624 2816
pgscan_direct_movable 0 0 0
kswapd_steal 134481 157951 159556
kswapd_inodesteal 0 0 0
kswapd_low_wmark_hit_quickly 0 0 6
kswapd_high_wmark_hit_quickly 0 0 0
allocstall 324 151 128
Unfortunately, it seems that Con's patch does not improve my
testcase so much. We may need extra bonus on the high watermark if
we take the way above. But necessary bonus depends on workloads,
hardware etc., so it can't be solved with fixed bonus, I think.
> If we're going to go with extra_free_kbytes, then I'd like to see the test
> case posted with a mathematical formula to show me what I should tune it
> to be depending on my machine's memory capacity and amount of free RAM
> when started (and I can use mem= to test it for various capacities). For
> this to be merged, there should be a clear expression that shows what the
> ideal setting of the tunable should be rather than asking for trial-and-
> error to see what works and what doesn't. If such an expression doesn't
> exist, then it's clear that the necessary setting will vary significantly
> as the implementation changes from kernel to kernel.
Hmm, try and error is tuning itself, isn't it? When we tune a system,
we usually set some knobs, run some benchmarks/tests/etc., evaluate
the results and decide which is the appropriate value.
Regards,
Satoru
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: OMAP3 ISP with digital sensor
From: Laurent Pinchart @ 2011-10-21 16:34 UTC (permalink / raw)
To: Gary Thomas; +Cc: linux-media@vger.kernel.org
In-Reply-To: <4E9447A9.2020005@mlbassoc.com>
Hi Gary,
Aarrghhhh, I'm sorry for the very late reply. Your mail splipped through the
cracks :-/
(94 mails to go in my inbox, then I'll move to my mailing lists backlog :-))
On Tuesday 11 October 2011 15:42:01 Gary Thomas wrote:
> Laurent,
>
> Do you have an example of how to use a digital sensor, in particular
> the MT9P031, with the OMAP3 ISP?
Yes, you can find sample board code in the omap3isp-sensors-board branch of
the git://linuxtv.org/pinchartl/media.git repository.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code
From: Tom Rini @ 2011-10-22 0:04 UTC (permalink / raw)
To: u-boot
In-Reply-To: <201110220145.08852.marek.vasut@gmail.com>
On Fri, Oct 21, 2011 at 4:45 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> On Saturday, October 22, 2011 01:08:43 AM Albert ARIBAUD wrote:
>> Le 22/10/2011 00:46, Marek Vasut a ?crit :
>> > On Saturday, October 22, 2011 12:44:06 AM Albert ARIBAUD wrote:
>> >> Le 22/10/2011 00:00, Marek Vasut a ?crit :
>> >>> On Friday, October 21, 2011 11:52:23 PM Albert ARIBAUD wrote:
>> >>>> Hi Marek,
>> >>>>
>> >>>> Le 21/10/2011 22:44, Marek Vasut a ?crit :
>> >>>>> On Thursday, October 06, 2011 02:13:26 AM Marek Vasut wrote:
>> >>>>>> This allows the SPL to avoid compiling in the CPU support code.
>> >>>>>>
>> >>>>>> Signed-off-by: Marek Vasut<marek.vasut@gmail.com>
>> >>>>>> Cc: Stefano Babic<sbabic@denx.de>
>> >>>>>> Cc: Wolfgang Denk<wd@denx.de>
>> >>>>>> Cc: Detlev Zundel<dzu@denx.de>
>> >>>>>> Cc: Scott Wood<scottwood@freescale.com>
>> >>>>>> ---
>> >>>>>>
>> >>>>>> ? ? arch/arm/cpu/arm926ejs/Makefile | ? ?7 +++++++
>> >>>>>> ? ? 1 files changed, 7 insertions(+), 0 deletions(-)
>> >>>>>>
>> >>>>>> diff --git a/arch/arm/cpu/arm926ejs/Makefile
>> >>>>>> b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..3f9b0f1 100644
>> >>>>>> --- a/arch/arm/cpu/arm926ejs/Makefile
>> >>>>>> +++ b/arch/arm/cpu/arm926ejs/Makefile
>> >>>>>> @@ -28,6 +28,13 @@ LIB = $(obj)lib$(CPU).o
>> >>>>>>
>> >>>>>> ? ? START ? ? ?= start.o
>> >>>>>> ? ? COBJS ? ? ?= cpu.o
>> >>>>>>
>> >>>>>> +ifdef CONFIG_SPL_BUILD
>> >>>>>> +ifdef CONFIG_SPL_NO_CPU_SUPPORT_CODE
>> >>>>>> +START :=
>> >>>>>> +COBJS :=
>> >>>>>> +endif
>> >>>>>> +endif
>> >>>>>> +
>> >>>>>>
>> >>>>>> ? ? SRCS ? ? ? := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c)
>> >>>>>> ? ? OBJS ? ? ? := $(addprefix $(obj),$(COBJS) $(SOBJS))
>> >>>>>> ? ? START ? ? ?:= $(addprefix $(obj),$(START))
>> >>>>>
>> >>>>> Hi Albert,
>> >>>>>
>> >>>>> can we get this applied please?
>> >>>>
>> >>>> I still don't understand what this is supposed to do -- why not
>> >>>> linking this code is required.
>> >>>>
>> >>>> Amicalement,
>> >>>
>> >>> Hi Albert,
>> >>>
>> >>> I use very different start.S in SPL. And I don't need cpu.o at all.
>> >>
>> >> That I understand; but is there a /problem/ in linking cpu.o in?
>> >
>> > I suppose it'll be optimized out at link time ?
>>
>> That indirectly answers my question: what you want to achieve is
>> removing dead code.
>
> The code IS USED in U-Boot, but IS NOT USED in SPL !
Right, but linked and unused code in SPL is (or should be!) thrown
away, is what's
trying to be driven home right now. If the file is going to go away,
and it's compiled
thrown away at final link of SPL, lets just ignore that it exists for
a little longer, and
then it won't.
--
Tom
^ permalink raw reply
* Re: [PATCH -V7 21/26] richacl: xattr mapping functions
From: Andreas Gruenbacher @ 2011-10-21 23:58 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: J. Bruce Fields, Christoph Hellwig, akpm, viro, dhowells,
linux-fsdevel, linux-nfs, linux-kernel
In-Reply-To: <871uu65vzh.fsf@linux.vnet.ibm.com>
On Fri, 2011-10-21 at 18:42 +0530, Aneesh Kumar K.V wrote:
> diff --git a/fs/richacl_xattr.c b/fs/richacl_xattr.c
> index 02a7986..31e33b5 100644
> --- a/fs/richacl_xattr.c
> +++ b/fs/richacl_xattr.c
> @@ -58,19 +58,14 @@ richacl_from_xattr(const void *value, size_t size)
> goto fail_einval;
>
> richacl_for_each_entry(ace, acl) {
> - const char *who = (void *)(xattr_ace + 1), *end;
> - ssize_t used = (void *)who - value;
>
> - if (used > size)
> - goto fail_einval;
> - end = memchr(who, 0, size - used);
> - if (!end)
> + if (((void *)xattr_ace + sizeof(*xattr_ace)) > (value + size))
> goto fail_einval;
This check can be moved out of the loop now.
Other than that, I'm happy with the patch; acked.
Thanks,
Andreas
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2011, #08; Fri, 21)
From: Jakub Narebski @ 2011-10-21 23:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Kato Kazuyoshi
In-Reply-To: <7vzkgu6jrf.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> * lh/gitweb-site-html-head (2011-10-21) 1 commit
> - gitweb: provide a way to customize html headers
>
> Looked Ok.
> Will merge to 'next'.
Nice.
> * kk/gitweb-side-by-side-diff (2011-10-17) 2 commits
> - gitweb: add a feature to show side-by-side diff
> - gitweb: change format_diff_line() to remove leading SP from $diff_class
>
> Fun.
> Will keep in 'pu' until the planned re-roll comes.
I think this needs some more work, not only re-roll...
BTW. the bottom commit could be I think replaced by mine
- gitweb: Refactor diff body line classification
Anyway, thanks for putting it in 'pu', it saves me trouble of fixing
whitespace issues in patch :-P
--
Jakub Narębski
^ permalink raw reply
* RE: [PATCH -v2 -mm] add extra free kbytes tunable
From: Satoru Moriya @ 2011-10-21 23:48 UTC (permalink / raw)
To: Rik van Riel, Andrew Morton
Cc: David Rientjes, Randy Dunlap, Satoru Moriya,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
lwoodman@redhat.com, Seiji Aguchi, hughd@google.com,
hannes@cmpxchg.org
In-Reply-To: <4E95F167.5050709@redhat.com>
On 10/12/2011 03:58 PM, Rik van Riel wrote:
> On 10/12/2011 03:20 PM, Andrew Morton wrote:
>> On Wed, 12 Oct 2011 09:09:17 -0400
>> Rik van Riel<riel@redhat.com> wrote:
>>
>> Do we actually have a real-world application which is hurting from
>> this?
>
> Satoru-san?
Sorry for late reply.
We do.
Basically we need this kind of feature for almost all our latency
sensitive applications to avoid latency issue in memory allocation.
Currently we run those applications on custom kernels which this
kind of patch is applied to. But it is hard for us to support every
kernel version for it. Also there are several customers who can't
accept a custom kernel and so they must use other commercial Unix.
If this feature is accepted, they will definitely use it on their
systems.
Thanks,
Satoru
^ permalink raw reply
* RE: [PATCH -v2 -mm] add extra free kbytes tunable
From: Satoru Moriya @ 2011-10-21 23:48 UTC (permalink / raw)
To: Rik van Riel, Andrew Morton
Cc: David Rientjes, Randy Dunlap, Satoru Moriya,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
lwoodman@redhat.com, Seiji Aguchi, hughd@google.com,
hannes@cmpxchg.org
In-Reply-To: <4E95F167.5050709@redhat.com>
On 10/12/2011 03:58 PM, Rik van Riel wrote:
> On 10/12/2011 03:20 PM, Andrew Morton wrote:
>> On Wed, 12 Oct 2011 09:09:17 -0400
>> Rik van Riel<riel@redhat.com> wrote:
>>
>> Do we actually have a real-world application which is hurting from
>> this?
>
> Satoru-san?
Sorry for late reply.
We do.
Basically we need this kind of feature for almost all our latency
sensitive applications to avoid latency issue in memory allocation.
Currently we run those applications on custom kernels which this
kind of patch is applied to. But it is hard for us to support every
kernel version for it. Also there are several customers who can't
accept a custom kernel and so they must use other commercial Unix.
If this feature is accepted, they will definitely use it on their
systems.
Thanks,
Satoru
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [U-Boot] [PATCH 3/5 v1] integrator: do not test first part of the memory
From: Albert ARIBAUD @ 2011-10-21 23:47 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CACRpkdb+HDRHpSLBpnPXq6c5b7fKjSACp-0YJTguwEWVoir88A@mail.gmail.com>
Le 17/10/2011 13:57, Linus Walleij a ?crit :
> Hi Arnaud,
>
> On Sun, Oct 16, 2011 at 5:51 PM, Albert ARIBAUD
> <albert.u.boot@aribaud.net> wrote:
>> Le 18/09/2011 09:52, Linus Walleij a ?crit :
>>>
>>> When booting from Flash, the Integrator remaps its flash memory
>>> from 0x24000000 to 0x00000000, and starts executing it at
>>> 0x00000000. This ROM thus hides the RAM underneath and first
>>> 0x40000 bytes of the memory cannot be tested by get_ram_size().
>>> So let's test from 0x40000 to the end of detected memory
>>> instead.
>>
>> Is this masking of RAM by FLASH a hardware thing that cannot be avoided?
>> Can't the U-Boot startup code somehow remap the FLASH elsewhere, and then
>> proceed to really test the whole RAM?
>
> Well, it is unmapped in board_init() but that is post-RAM-test.
>
> The reason I cannot unmapp it in dram_init() is that at this point
> U-Boot is running from flash and has not relocated itself (it wants to test
> RAM before relocating of course) and the flash it is running from is
> exactly that which is in the way of the RAM test.
>
> So on integrator, the flash memory remaps itself to address 0x00000000
> when booting from flash, and U-Boot has text base 0x00000000 in
> this case, and is running in flash relative 0x00000000.
>
> If it would remap the flash at this point it would unmap itself,
> and crash.
>
> This way of having the flash containing U-Boot remap itself over the
> system RAM seems to be uncommon, but I'd share the problem with
> anyone else trying to do something similar I guess.
There is a technique for remapping running code memory, which relies on
the mapping controller being able to map the same device twice: usually
you start with one window already defined for the boot device, then you
create another window where you want the device to end up, then you jump
to that new address, then at that new address you can unmap the original
window. I sort of did that for orion5x, for a slightly different reason
-- see orion5x_config_adr_windows() in cpu.c.
Otherwise, I don't suppose there is static RAM that the FLASH code could
use as a pivot? If there was, you could boot from flash @ 'bad'
location, copy a flash-remapping routine into SRAM, jump to it, once
remapped, the routine jumps to flash@ 'good' location and then you can
test the whole RAM.
> Yours,
> Linus Walleij
Amicalement,
--
Albert.
^ permalink raw reply
* [U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code
From: Marek Vasut @ 2011-10-21 23:45 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EA1FB7B.5020008@aribaud.net>
On Saturday, October 22, 2011 01:08:43 AM Albert ARIBAUD wrote:
> Le 22/10/2011 00:46, Marek Vasut a ?crit :
> > On Saturday, October 22, 2011 12:44:06 AM Albert ARIBAUD wrote:
> >> Le 22/10/2011 00:00, Marek Vasut a ?crit :
> >>> On Friday, October 21, 2011 11:52:23 PM Albert ARIBAUD wrote:
> >>>> Hi Marek,
> >>>>
> >>>> Le 21/10/2011 22:44, Marek Vasut a ?crit :
> >>>>> On Thursday, October 06, 2011 02:13:26 AM Marek Vasut wrote:
> >>>>>> This allows the SPL to avoid compiling in the CPU support code.
> >>>>>>
> >>>>>> Signed-off-by: Marek Vasut<marek.vasut@gmail.com>
> >>>>>> Cc: Stefano Babic<sbabic@denx.de>
> >>>>>> Cc: Wolfgang Denk<wd@denx.de>
> >>>>>> Cc: Detlev Zundel<dzu@denx.de>
> >>>>>> Cc: Scott Wood<scottwood@freescale.com>
> >>>>>> ---
> >>>>>>
> >>>>>> arch/arm/cpu/arm926ejs/Makefile | 7 +++++++
> >>>>>> 1 files changed, 7 insertions(+), 0 deletions(-)
> >>>>>>
> >>>>>> diff --git a/arch/arm/cpu/arm926ejs/Makefile
> >>>>>> b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..3f9b0f1 100644
> >>>>>> --- a/arch/arm/cpu/arm926ejs/Makefile
> >>>>>> +++ b/arch/arm/cpu/arm926ejs/Makefile
> >>>>>> @@ -28,6 +28,13 @@ LIB = $(obj)lib$(CPU).o
> >>>>>>
> >>>>>> START = start.o
> >>>>>> COBJS = cpu.o
> >>>>>>
> >>>>>> +ifdef CONFIG_SPL_BUILD
> >>>>>> +ifdef CONFIG_SPL_NO_CPU_SUPPORT_CODE
> >>>>>> +START :=
> >>>>>> +COBJS :=
> >>>>>> +endif
> >>>>>> +endif
> >>>>>> +
> >>>>>>
> >>>>>> SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c)
> >>>>>> OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS))
> >>>>>> START := $(addprefix $(obj),$(START))
> >>>>>
> >>>>> Hi Albert,
> >>>>>
> >>>>> can we get this applied please?
> >>>>
> >>>> I still don't understand what this is supposed to do -- why not
> >>>> linking this code is required.
> >>>>
> >>>> Amicalement,
> >>>
> >>> Hi Albert,
> >>>
> >>> I use very different start.S in SPL. And I don't need cpu.o at all.
> >>
> >> That I understand; but is there a /problem/ in linking cpu.o in?
> >
> > I suppose it'll be optimized out at link time ?
>
> That indirectly answers my question: what you want to achieve is
> removing dead code.
The code IS USED in U-Boot, but IS NOT USED in SPL !
>
> Now, about your question, you can check this if you build the board you
> intend to apply this to, and do an objdump of the generated SPL: you'll
> see if the cpu.o functions are present or not.
>
> (my point being that if cpu.o is to disappear because its functions are
> either useless or should move elsewhere, then the interest of a patch
> making cpu.o optional is short-lived.)
I just prodded Hong about his cache patches.
>
> > Cheers
>
> Amicalement,
^ permalink raw reply
* Re: where to find ipw2200 driver files for backtrac 5
From: Gábor Stefanik @ 2011-10-21 23:35 UTC (permalink / raw)
To: Patrick Trépanier-Gravelle; +Cc: linux-wireless
In-Reply-To: <CALVkfMpoyY9j3g3GjnWAdvZSuWMjDQT-m1HAMtJJMJXy2pot+A@mail.gmail.com>
I'm pretty sure BackTrack 5 has the ipw2200 driver included already.
Try "modprobe ipw2200".
2011/10/22 Patrick Trépanier-Gravelle <ptrepanierg@gmail.com>:
> I cant find the driver for my dell inspiron 700m laptop I tried the
> NDISSwrapper method but I cant extract the .inf file from the .EXE
> seems it isn't the right type of file.
> I would like to know where I could find the linux native drivers for
> ipw2200bg card.
>
> Thank you,
>
> Patrick
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: Getting SIMX86.exe
From: Ivan Baldo @ 2011-10-21 23:35 UTC (permalink / raw)
To: Robert Supansic; +Cc: linux-msdos
In-Reply-To: <4EA1A539.3040903@gmail.com>
Hello.
El 21/10/11 15:00, Robert Supansic escribió:
> Ivan Baldo wrote:
>> Make sure that the DOSEmu configuration file doesn't have
>> $_cpu_emu option uncommented (without #) and thats it.
>> You don't need SIMX86.EXE.
> The $_cpu_emu configuration variable does not exist in my dosemu.conf
> file.
> It is not mentioned in any documentation of my version of DOSemu
> (version 1.2.2.0)
> I have not been able to find any reference to it in the on-line
> documentation for version 1.2 or version 1.4.
It is on my dosemu.conf.
>> # Usage of cpu emulation: "off" (requires /proc/sys/vm/mmap_min_addr=
>> 0),
>> # "vm86" only (default) or "full" (vm86 and DPMI, experimental!).
>> # Use "vm86sim" or "fullsim" to use simulation instead of JIT code
>> generation.
>>
>> # $_cpu_emu = "vm86"
> Are these comments your own or are the taken from your dosemu.conf file?
Thats an extract from my dosemu.conf file.
>> If you still have problems, please send your .dosemu/boot.log file.
> -----Text of my boot.log file-------
> CONF: config variable parser_version_3 set
> CONF: config variable c_system set
> CONF: Parsing built-in dosemu.conf file.
> CONF: config variable version_3_style_used set
> CONF: Parsing built-in global.conf file.
> CONF: config variable version_3_style_used unset
> CONF: config variable version_3_style_used set
> CONF: opened include file /etc/dosemu/dosemu.conf
> CONF: closed include file /etc/dosemu/dosemu.conf
> debug flags: -a+cw
> CONF: Disabling use of pentium timer
> CONF: dosbanner on
> CONF: timer freq=18, update=54925
> CONF: CPU set to 586
> CONF: 8192k bytes XMS memory
> CONF: 2048k bytes EMS memory
> CONF: EMS-frame = 0xe000
> CONF: DPMI-Server on
> CONF: dosemu running on console
> SER: directory /var/lock namestub LCK.. binary No
> MOUSE: no device specified, type 0 using internaldriver: yes,
> emulate3buttons: no baudrate: 0
> CONF: Keyboard-layout keyb-user
> CONF: Keyboard-layout auto
> device: /dev/fd0 type 2 h: 0 s: 0 t: 0 floppy A:
> CONF: fastfloppy = 1
> CONF: IPX support off
> CONF(LPT0) f: (null) c: lpr o: -Plp t: 20 port: 0
> CONF: not allowing speaker port access
> CONF: Packet Driver disabled.
> device: /root/.dosemu/drives/c type 4 h: -1 s: -1 t: -1 drive C:
> CONF: config variable c_system unset
> CONF: running exclusively as ROOT: uid=0 (cached 0) gid=0 (cached 0)
> DBG_FD already set
> DOSEMU-1.2.2.0 is coming up on Linux version 2.6.13-15-default
> ----End of boot.log file-----
>
In my boot.log I have the following 2 lines:
WARN: vm86plus service not available in your kernel
WARN: using CPU emulation for vm86()
Maybe thats a feature of DOSEMU 1.4 only and is not available in
1.2.2.0.
Try DOSEmu 1.4, it should fix the problem and run fine under a
64bit kernel without the need for SIMX86.EXE.
> Thank you for your help.
>
You are welcome!
Good luck!
--
Ivan Baldo - ibaldo@adinet.com.uy - http://ibaldo.codigolibre.net/
From Montevideo, Uruguay, at the south of South America.
Freelance programmer and GNU/Linux system administrator, hire me!
Alternatives: ibaldo@codigolibre.net - http://go.to/ibaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Xen-users] Re: Xen document day (Oct 12 or 26)
From: Joseph Glanville @ 2011-10-21 23:33 UTC (permalink / raw)
To: Lars Kurth
Cc: Andrew Bobulsky, xen-users@lists.xensource.com,
xen-devel@lists.xensource.com, Ian Campbell,
Konrad Rzeszutek Wilk
In-Reply-To: <4EA18FAD.7080102@xen.org>
[-- Attachment #1.1: Type: text/plain, Size: 6284 bytes --]
On 22 October 2011 02:28, Lars Kurth <lars.kurth@xen.org> wrote:
> On 21/10/2011 04:44, Joseph Glanville wrote:
>
>> I think we should aim to get a meeting of interested parties happening on
>> IRC before we action on a date or plan.
>> I just don't want to get started on something that will stall due to lack
>> of direction.
>>
>> <rant>
>>
> I am happy to hang out with a few the day before the docs day and
> coordinate a bit
> I think there is a lot we can do though
>
>
> I am happy to contribute my time to do a significant amount of the work
>> that bofh has requested but to do so effectively I really think we need
>> somewhat of a clean start.
>> The current wiki contains too much content that just doesn't belong in the
>> wiki, job postings, WIP status on projects that have long since died etc.
>>
> Agreed that some stuff should just be deleted. The key issues is that the
> wiki today has a flat structure.
> I am happy to delete stuff like job postings, old minutes, WIP status and
> truly dead stuff and archive plain old stuff (which may still be of value to
> some people.
>
> I think its unfair to say Xen is a schizophrenic project. The issue has
> been that the Wiki has not been managed ever and MoinMoin is inherently
> unmanageable
Aye, I didn't mean to say Xen was schizophrenic, infact I think it is
precisely the opposite. My point was that the wiki and current documentation
don't reflect this very wel.
>
>
> I did get started on a full categorization of pages in the wiki but that
>> quickly become something that is abit much to do in one session or alone for
>> that matter.
>>
> Agreed and categories don't work well with MoinMoin
>
>
> It also highlighted some severe problems with how the current wiki is used
>> - in my opinion atleast. It is my view that the official wiki should be
>> reserved for highly relevant documentation.
>>
> I would agree with you, if we were in a perfect world. But we have baggage,
> so to some degree this discussion is moot. I also think that this question
> is handled quite differently by different projects.
As I noted, this is just my opinion, its not my place to decide how people
want to use it but if we could have to idea of what should and shouldn't be
in there it makes it easy to then structure the information.
>
>
> I think we need to setup a guided rewrite/refactor of the core
>> documentation so it resembles something close to this:
>>
>> Overview (brief introduction, architecture, why xen is different and maybe
>> abit of xen philosophy)
>> Getting started guide ( Installation of Xen on Debian - probably the
>> simplest and easiest way to get started with Xen at the moment, start a
>> Debian PV guest, start at Windows HVM guest)
>> Installation guide ( More indepth covering all the core distros and some
>> more advanced installations including compilation from source and using the
>> Linux 3.1 kernel, networking options etc)
>> Administration guide ( This bit requires atlot of discussion, do we
>> recommend xm still? should we only support xl? If that is the case how to we
>> recommend stuff like managed domains etc..)
>> Advanced topics.. stuff like Networking, PCI passthrough etc deserve their
>> own pages
>>
> Are you suggesting we restructure the wiki front-page around this?
Yes, maybe not -exactly- this format but something resembling it would be of
value I think. Guiding people towards the beginners documentation and making
it quite clear there is a reading progression will show much stronger
cohesion.
>
>
> There also needs to be a developers section, preferably seperate entirely
>> from the user documentation. If XCP could be sectioned off in some matter
>> also that would be advantageous - basically to prevent confusion.
>>
> We do not have that many XCP pages. MoinMoin sucks at sectioning stuff off.
> The only thing which could sort of work is to use <namespace>/<pagename> ...
> we could have XCP/<pagename> and so on. If categories worked properly, they
> could be used too.
Fair enough, that would work well enough for this purpose.
>
>
> The current wiki is poluted with alot of architecture and design info that
>> isn't of interest to a general user but is still key to understanding Xen
>> from a developers point of view.
>>
> Part of the issue is that it is hard for me to identify what is what. If I
> had a good approximation of what is what, I (or others) could just go
> through the motions and re-encode stuff accordingly.
I have exactly the same problem, I just need to undertand what needs to be
done and where.
>
>
> What the primary aim would be is to integrate as much best practices into
>> these pages rather than having them spread around hundreds of wiki pages and
>> even more mailing list posts.
>> To be honest I rarely look to the wiki if I want to know how to do
>> something with Xen I am unfamilar with.. my first course of action is to
>> search my archive of xen-devel/xen-users which isn't exactly a good thing.
>>
>> The biggest issue with this sort of compaction is that Xen is fraught with
>> choices.. there is just so many different ways of doing things.
>>
>> I'm not trying to be critical of those that have spent many hours writing
>> the current documentation, it is appreciated.
>> I just think we need a really concentrated effort around making the simple
>> Xen tasks easier before expanding out to include the more complicated stuff.
>> Alot of us take for granted that we have been using Xen for a long time
>> and many of these things come so naturally to us - whereas from the outside
>> it all seems too difficult.
>>
>> </rant>
>>
> I think what you seem to be saying is that there would be extremely high
> value in having a "Getting started" guide and some other entry level
> documentation (even if just an index page) accessible from the wiki front
> page.
>
Precisely, documenting the more advanced features of Xen seems to be
something that we can approach over time. Beginner documentation is
immeadiately lacking and seems to be an easier target that would benefit
more people.
>
> Lars
>
Thanks for reading the rant. :)
Joseph.
--
*
Founder | Director | VP Research
Orion Virtualisation Solutions* | www.orionvm.com.au | Phone: 1300 56 99 52
| Mobile: 0428 754 846
[-- Attachment #1.2: Type: text/html, Size: 9071 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* [U-Boot] [PATCH v3] arm926ejs: add NXP LPC32x0 cpu series support
From: Albert ARIBAUD @ 2011-10-21 23:31 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1318953340-30248-1-git-send-email-vz@mleia.com>
Hi Vladimir,
Le 18/10/2011 17:55, Vladimir Zapolskiy a ?crit :
> This change adds initial support for NXP LPC32x0 SoC series.
>
> Signed-off-by: Vladimir Zapolskiy<vz@mleia.com>
> ---
> Changes from v2 to v3:
> * checkpatch.pl reports zero errors and warnings
>
> Changes from v1 to v2:
> * BIT(n) and SBF(s, v) macro are not used anymore
> * removed NS16550 and 14-clock UART definitions from uart.h
> * added devices.c file, which contains standard UART preinitialization routine
> * added get_serial_clock() function, it returns actual frequency of UART clock
> * __udelay() realization is simplified, no need of interrupt handling
As it stands, this is dead code until some board uses it; I imagine you
have board waiting for this support. Can you submit the SoC and board
code as a patch set? This way, it will be obvious for all that the SoC
code in this patch has actual use.
Amicalement,
--
Albert.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.