Re: [U-Boot] u-boot fails to uncompress a gzip'ed -9 kernel
This is a MPC8313E-RDB board problem. We have 2 REV A4 boards. I can reproduce this problem on both of the MPC8313E-RDB boards with any version of u-boot with a compressed file which contains 1 or more dynamic codes blocks and a final fixed codes block. I have a 5k gzipped file for which the problem (already) occurs. I could test on a PQ2FADS board. The problem doesn't occur on this board. I did some memory tests (which I should've done a bit earlier) and the same problem (soft reset due to checkstop) occurs. I'll make a new thread for this. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Add 16bpp BMP support
This patch adds 16bpp BMP support to the common lcd code.
At the moment it's only been tested on the MIMC200 AVR32 board, but the hooks
are in place to extend this to other platforms.
Signed-off-by: Mark Jackson m...@mimc.co.uk
---
common/lcd.c | 54 --
1 files changed, 44 insertions(+), 10 deletions(-)
diff --git a/common/lcd.c b/common/lcd.c
index ae79051..93dbd3c 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -84,7 +84,7 @@ extern void lcd_enable (void);
static void *lcd_logo (void);
-#if LCD_BPP == LCD_COLOR8
+#if (LCD_BPP == LCD_COLOR8) || (LCD_BPP == LCD_COLOR16)
extern void lcd_setcolreg (ushort regno,
ushort red, ushort green, ushort blue);
#endif
@@ -656,7 +656,7 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
bpix = NBITS(panel_info.vl_bpix);
- if ((bpix != 1) (bpix != 8)) {
+ if ((bpix != 1) (bpix != 8) (bpix != 16)) {
printf (Error: %d bit/pixel mode not supported by U-Boot\n,
bpix);
return 1;
@@ -738,17 +738,51 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
bmap = (uchar *)bmp + le32_to_cpu (bmp-header.data_offset);
fb = (uchar *) (lcd_base +
(y + height - 1) * lcd_line_length + x);
- for (i = 0; i height; ++i) {
- WATCHDOG_RESET();
- for (j = 0; j width ; j++)
+
+ switch (bpix) {
+ case 1: /* pass through */
+ case 8:
+ for (i = 0; i height; ++i) {
+ WATCHDOG_RESET();
+ for (j = 0; j width ; j++)
#if defined(CONFIG_PXA250) || defined(CONFIG_ATMEL_LCD)
- *(fb++) = *(bmap++);
+ *(fb++) = *(bmap++);
#elif defined(CONFIG_MPC823) || defined(CONFIG_MCC200)
- *(fb++)=255-*(bmap++);
+ *(fb++)=255-*(bmap++);
#endif
- bmap += (width - padded_line);
- fb -= (width + lcd_line_length);
- }
+ bmap += (width - padded_line);
+ fb -= (width + lcd_line_length);
+ }
+ break;
+
+ case 16:
+ for (i = 0; i height; ++i) {
+ WATCHDOG_RESET();
+ for (j = 0; j width; j++) {
+#if defined(CONFIG_PXA250)
+#error 16 bpp support not added for PXA250
+#elif defined(CONFIG_ATMEL_LCD)
+#if defined(CONFIG_ATMEL_LCD_BGR555)
+ *(fb++) = ((bmap[0] 0x1f) 2) | (bmap[1]
0x03);
+ *(fb++) = (bmap[0] 0xe0) | ((bmap[1] 0x7c)
2);
+ bmap += 2;
+#else
+ *(fb++) = *(bmap++);
+ *(fb++) = *(bmap++);
+#endif
+#elif defined(CONFIG_MPC823)
+#error 16 bpp support not added for MPC823
+#elif defined(CONFIG_MCC200)
+#error 16 bpp support not added for MCC200
+#endif
+ }
+ bmap += (padded_line - width) * 2;
+ fb -= (width * 2 + lcd_line_length);
+ }
+ break;
+ default:
+ break;
+ };
return (0);
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add 16bpp BMP support
Dear Mark Jackson,
In message 497edf68.7050...@mimc.co.uk you wrote:
This patch adds 16bpp BMP support to the common lcd code.
At the moment it's only been tested on the MIMC200 AVR32 board, but the hooks
are in place to extend this to other platforms.
Signed-off-by: Mark Jackson m...@mimc.co.uk
---
...
+ case 16:
+ for (i = 0; i height; ++i) {
+ WATCHDOG_RESET();
+ for (j = 0; j width; j++) {
+#if defined(CONFIG_PXA250)
+#error 16 bpp support not added for PXA250
+#elif defined(CONFIG_ATMEL_LCD)
+#if defined(CONFIG_ATMEL_LCD_BGR555)
Oops. Right in the middle of a for loop?
This is probably not exactly a good
place for the placement of such a generic compile time check.
+ *(fb++) = ((bmap[0] 0x1f) 2) | (bmap[1]
0x03);
+ *(fb++) = (bmap[0] 0xe0) | ((bmap[1] 0x7c)
2);
+ bmap += 2;
+#else
+ *(fb++) = *(bmap++);
+ *(fb++) = *(bmap++);
+#endif
+#elif defined(CONFIG_MPC823)
+#error 16 bpp support not added for MPC823
+#elif defined(CONFIG_MCC200)
+#error 16 bpp support not added for MCC200
+#endif
Ditto here.
I don't like this approach. The code is too ugly. If you need dfferent
versions, thatn factor out the different code into functions, or
similar.
NAK.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Even historians fail to learn from history -- they repeat the same
mistakes.
-- John Gill, Patterns of Force, stardate 2534.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Remove static type from gunzip_bmp()
THe current bmp routines support gzipped files, but compilation fails due to
the gunzip_bmp() function being defined as static.
This patch fixes this problem.
Signed-off-by: Mark Jackson m...@mimc.co.uk
---
common/cmd_bmp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/cmd_bmp.c b/common/cmd_bmp.c
index bc08b26..2104e59 100644
--- a/common/cmd_bmp.c
+++ b/common/cmd_bmp.c
@@ -46,7 +46,7 @@ int gunzip(void *, int, unsigned char *, unsigned long *);
* didn't contain a valid BMP signature.
*/
#ifdef CONFIG_VIDEO_BMP_GZIP
-static bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp)
+bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp)
{
void *dst;
unsigned long len;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Add 16bpp BMP support
This patch adds 16bpp BMP support to the common lcd code.
At the moment it's only been tested on the MIMC200 AVR32 board, but the hooks
are in place to extend this to other platforms.
Signed-off-by: Mark Jackson m...@mimc.co.uk
---
common/lcd.c | 55 +--
1 files changed, 45 insertions(+), 10 deletions(-)
diff --git a/common/lcd.c b/common/lcd.c
index ae79051..8cbb540 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -84,7 +84,7 @@ extern void lcd_enable (void);
static void *lcd_logo (void);
-#if LCD_BPP == LCD_COLOR8
+#if (LCD_BPP == LCD_COLOR8) || (LCD_BPP == LCD_COLOR16)
extern void lcd_setcolreg (ushort regno,
ushort red, ushort green, ushort blue);
#endif
@@ -656,7 +656,7 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
bpix = NBITS(panel_info.vl_bpix);
- if ((bpix != 1) (bpix != 8)) {
+ if ((bpix != 1) (bpix != 8) (bpix != 16)) {
printf (Error: %d bit/pixel mode not supported by U-Boot\n,
bpix);
return 1;
@@ -738,17 +738,52 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
bmap = (uchar *)bmp + le32_to_cpu (bmp-header.data_offset);
fb = (uchar *) (lcd_base +
(y + height - 1) * lcd_line_length + x);
- for (i = 0; i height; ++i) {
- WATCHDOG_RESET();
- for (j = 0; j width ; j++)
+
+ switch (bpix) {
+ case 1: /* pass through */
+ case 8:
+ for (i = 0; i height; ++i) {
+ WATCHDOG_RESET();
+ for (j = 0; j width ; j++)
#if defined(CONFIG_PXA250) || defined(CONFIG_ATMEL_LCD)
- *(fb++) = *(bmap++);
+ *(fb++) = *(bmap++);
#elif defined(CONFIG_MPC823) || defined(CONFIG_MCC200)
- *(fb++)=255-*(bmap++);
+ *(fb++)=255-*(bmap++);
#endif
- bmap += (width - padded_line);
- fb -= (width + lcd_line_length);
- }
+ bmap += (width - padded_line);
+ fb -= (width + lcd_line_length);
+ }
+ break;
+
+#if defined(CONFIG_PXA250)
+#error 16 bpp support not added for PXA250
+#elif defined(CONFIG_ATMEL_LCD)
+ case 16:
+ for (i = 0; i height; ++i) {
+ WATCHDOG_RESET();
+ for (j = 0; j width; j++) {
+#if defined(CONFIG_ATMEL_LCD_BGR555)
+ *(fb++) = ((bmap[0] 0x1f) 2) | (bmap[1]
0x03);
+ *(fb++) = (bmap[0] 0xe0) | ((bmap[1] 0x7c)
2);
+ bmap += 2;
+#else
+ *(fb++) = *(bmap++);
+ *(fb++) = *(bmap++);
+#endif
+ }
+ bmap += (padded_line - width) * 2;
+ fb -= (width * 2 + lcd_line_length);
+ }
+ break;
+#elif defined(CONFIG_MPC823)
+#error 16 bpp support not added for MPC823
+#elif defined(CONFIG_MCC200)
+#error 16 bpp support not added for MCC200
+#endif
+
+ default:
+ break;
+ };
return (0);
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Remove static type from gunzip_bmp()
The current bmp routines support gzipped files, but compilation fails (under
AVR32) due to the gunzip_bmp() function being defined as static.
This patch fixes this problem.
Signed-off-by: Mark Jackson m...@mimc.co.uk
---
common/cmd_bmp.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/common/cmd_bmp.c b/common/cmd_bmp.c
index bc08b26..084ef98 100644
--- a/common/cmd_bmp.c
+++ b/common/cmd_bmp.c
@@ -46,7 +46,7 @@ int gunzip(void *, int, unsigned char *, unsigned long *);
* didn't contain a valid BMP signature.
*/
#ifdef CONFIG_VIDEO_BMP_GZIP
-static bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp)
+bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp)
{
void *dst;
unsigned long len;
@@ -85,7 +85,7 @@ static bmp_image_t *gunzip_bmp(unsigned long addr, unsigned
long *lenp)
return bmp;
}
#else
-static bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp)
+bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp)
{
return NULL;
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 9/9] AVR32: Board support for ATEVK1100
On Mon, Jan 26, 2009 at 8:50 PM, Wolfgang Denk w...@denx.de wrote: Dear ?ISO-8859-1?Q?Gunnar_Rangøy?, In message e1b3d0a60901260635s668877b9j7368427832acf...@mail.gmail.com you wrote: ... +#undef CONFIG_CMD_AUTOSCRIPT Is there a specific reason for not allowing to use shell scripts? ... No, not really. We did this because this was done in other AVR32 boards we used as references. Then pleasse don't - let's overcome the bad examples. OK, this is fixed. Regards Gunnar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Add 16bpp BMP support
Dear Mark Jackson,
In message 497ef0c4.3060...@mimc.co.uk you wrote:
This patch adds 16bpp BMP support to the common lcd code.
At the moment it's only been tested on the MIMC200 AVR32 board, but the hooks
are in place to extend this to other platforms.
...
+#if defined(CONFIG_PXA250)
+#error 16 bpp support not added for PXA250
+#elif defined(CONFIG_ATMEL_LCD)
+ case 16:
+ for (i = 0; i height; ++i) {
+ WATCHDOG_RESET();
+ for (j = 0; j width; j++) {
+#if defined(CONFIG_ATMEL_LCD_BGR555)
+ *(fb++) = ((bmap[0] 0x1f) 2) | (bmap[1]
0x03);
+ *(fb++) = (bmap[0] 0xe0) | ((bmap[1] 0x7c)
2);
+ bmap += 2;
+#else
+ *(fb++) = *(bmap++);
+ *(fb++) = *(bmap++);
+#endif
+ }
+ bmap += (padded_line - width) * 2;
+ fb -= (width * 2 + lcd_line_length);
+ }
+ break;
+#elif defined(CONFIG_MPC823)
+#error 16 bpp support not added for MPC823
+#elif defined(CONFIG_MCC200)
+#error 16 bpp support not added for MCC200
+#endif
No, this still makes no sense to me. Listing all the accrhitectures
where this is implemented or not is error prone, and this file should
definitely be as independent from specific hardware properties as
possible.
Can we not agree on some generic name (like CONFIG_BMP_16BPP) and
#define this only on those boards that can do it / need it? Then we
can omit all the elif ... lists.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
If a man had a child who'd gone anti-social, killed perhaps, he'd
still tend to protect that child.
-- McCoy, The Ultimate Computer, stardate 4731.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Remove static type from gunzip_bmp()
Dear Mark Jackson, In message 497ef15a.6050...@mimc.co.uk you wrote: The current bmp routines support gzipped files, but compilation fails (under AVR32) due to the gunzip_bmp() function being defined as static. This patch fixes this problem. Signed-off-by: Mark Jackson m...@mimc.co.uk As mentioned before: if you make this function publicly visible, then please also add a prototype declaration for it (and get rid of any private external ... declararions elsewhere). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The greatest warriors are the ones who fight for peace. - Holly Near ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Add 16bpp BMP support
Dear Mark, In message 497efc3e.8050...@mimc.co.uk you wrote: What if I just remove all the extranous #defines all together ? And just leave the inner #if defined(CONFIG_ATMEL_LCD_BGR555) ? Well, we probably don't need to add code for 16bpp support on systems that cannot make use of it. Let's keep the memory footprint as small as possible. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Too many people are ready to carry the stool when the piano needs to be moved. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Add 16bpp BMP support
Wolfgang Denk wrote: Dear Mark, In message 497efc3e.8050...@mimc.co.uk you wrote: What if I just remove all the extranous #defines all together ? And just leave the inner #if defined(CONFIG_ATMEL_LCD_BGR555) ? Well, we probably don't need to add code for 16bpp support on systems that cannot make use of it. Let's keep the memory footprint as small as possible. No problem ... I'll fix that up. Mark ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] Remove static type from gunzip_bmp()
The current bmp routines support gzipped files, but compilation fails (under
AVR32) due to the gunzip_bmp() function being defined as static.
This patch fixes this problem.
The gunzip_bmp routine has also now been defined in the lcd.h header file.
Signed-off-by: Mark Jackson m...@mimc.co.uk
---
common/cmd_bmp.c |4 ++--
common/lcd.c |4
include/lcd.h|4
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/common/cmd_bmp.c b/common/cmd_bmp.c
index bc08b26..084ef98 100644
--- a/common/cmd_bmp.c
+++ b/common/cmd_bmp.c
@@ -46,7 +46,7 @@ int gunzip(void *, int, unsigned char *, unsigned long *);
* didn't contain a valid BMP signature.
*/
#ifdef CONFIG_VIDEO_BMP_GZIP
-static bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp)
+bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp)
{
void *dst;
unsigned long len;
@@ -85,7 +85,7 @@ static bmp_image_t *gunzip_bmp(unsigned long addr, unsigned
long *lenp)
return bmp;
}
#else
-static bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp)
+bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp)
{
return NULL;
}
diff --git a/common/lcd.c b/common/lcd.c
index 8cbb540..23196d6 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -789,10 +789,6 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
}
#endif
-#ifdef CONFIG_VIDEO_BMP_GZIP
-extern bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp);
-#endif
-
static void *lcd_logo (void)
{
#ifdef CONFIG_SPLASH_SCREEN
diff --git a/include/lcd.h b/include/lcd.h
index 3184803..41ee6bc 100644
--- a/include/lcd.h
+++ b/include/lcd.h
@@ -208,6 +208,10 @@ void lcd_show_board_info(void);
# include asm/byteorder.h
#endif
+#ifdef CONFIG_VIDEO_BMP_GZIP
+extern bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp);
+#endif
+
/*
* Information about displays we are using. This is for configuring
* the LCD controller and memory allocation. Someone has to know what
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Reset command on u-boot command line not working
Hello ,
We have a custom board similar to EP8548A board, custom board has MPC8548E
alone with 4 onboard DDR2 SDRAM(total 512MB). Only one chip select is used.
Below is the code snippet in u-boot, which will initialize the DDR2 SDRAM.
Fortunately,
When ever I give a hard reset( via switch) HRST# will be asserted and board
will be
Come up with the u-boot prompt.
But, when I give the command reset on the u-boot command line, system
hangs printing
The below on the console:
/***/
U-Boot 1.2.0 (Jan 27 2009 - 17:17:39)
CPU: 8548_E, Version: 2.1, (0x80390021)
Core: E500, Version: 2.2, (0x80210022)
Clock Configuration:
CPU: 999 MHz, CCB: 399 MHz,
DDR: 199 MHz, LBC: 49 MHz
L1:D-cache 32 kB enabled
I-cache 32 kB enabled
Board:
I2C: ready
DRAM: Initializing
DDR: 512 MB
/***/
1) What might be the problem???
2) I guess, after reinitializing the RAM this happened, but it is fine when
I give a hard reset(using switch).
3) Is there any way that I should follow before re initializing the RAM.???
4) As far as I know, in the below code snippet I'm doing the required
stuffs.
Pls help me in this regard, at the earliest
/*** ON Board, DDR2 SDRAM Initialization CODE
Snippet?
long int custom_sdram(void)
{
volatile immap_t *immap = (immap_t *)CFG_IMMR;
volatile ccsr_ddr_t *ddr = immap-im_ddr;
unsigned int memsize;
/*ddr sdram config: MEM_HALT disable*/
ddr-sdram_cfg = 0x0302;
udelay(200);
/*Below are the calculated DDR2 controller register values*/
ddr-cs0_bnds = 0x001f; /* 0x2000 - DDR Chip Select 0 Memory Bounds
*/
ddr-cs1_bnds = 0x; /* 0x2008 - DDR Chip Select 1 Memory Bounds
*/
ddr-cs2_bnds = 0x; /* 0x2010 - DDR Chip Select 2 Memory Bounds
*/
ddr-cs3_bnds = 0x; /* 0x2018 - DDR Chip Select 3 Memory Bounds
*/
ddr-cs0_config = 0x80814102;/* 0x2080 - DDR Chip Select Configuration */
ddr-cs1_config = 0x;/* 0x2084 - DDR Chip Select Configuration */
ddr-cs2_config = 0x;/* 0x2088 - DDR Chip Select Configuration */
ddr-cs3_config = 0x;/* 0x208c - DDR Chip Select Configuration */
ddr-ext_refrec = 0x;/* 0x2100 - DDR SDRAM Extended Refresh
Recovery */
ddr-timing_cfg_0 = 0xFF220802;/* 0x2104 - DDR SDRAM Timing Configuration
Register 0 */
ddr-timing_cfg_1 = 0x3835a322;/* 0x2108 - DDR SDRAM Timing Configuration
Register 1 */
ddr-timing_cfg_2 = 0x23108cca;/* 0x210c - DDR SDRAM Timing Configuration
Register 2 */
ddr-sdram_mode = 0x40140432; /* 0x2118 - DDR SDRAM Mode Configuration */
ddr-sdram_interval = 0x06180100; /* 0x2124 - DDR SDRAM Interval
Configuration */
asm(sync;isync;msync);
udelay(500);
ddr-sdram_cfg_2 = 0x04401000; /* 0x2114 - DDR SDRAM Control
Configuration 2 */
ddr-sdram_clk_cntl = 0x0200; /* 0x2130 - DDR SDRAM Clock Control */
udelay(200);
ddr-sdram_cfg = 0xc3008000;
asm(sync;isync;msync);
udelay(500);
/*
* Figure out memory size in Megabytes.
*/
memsize = 512;
/*
* Establish Local Access Window and TLB mappings for DDR memory.
*/
memsize = setup_laws_and_tlbs(memsize);
if (memsize == 0) {
return 0;
}
return memsize * 1024 * 1024;
}
/***/
Thanks,
Ajeesh Kumar
The information contained in this electronic message and any attachments to
this message are intended for the exclusive use of the addressee(s) and may
contain proprietary, confidential or privileged information. If you are not the
intended recipient, you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately and destroy all copies of this message and
any attachments contained in it.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Reset command on u-boot command line not working
Hello 2009/1/27, Ajeesh Kumar aje...@tataelxsi.co.in: [skip] But, when I give the command reset on the u-boot command line, system hangs printing The below on the console: /***/ U-Boot 1.2.0 (Jan 27 2009 - 17:17:39) [skip] Probably the first thing you should do is grab the latest U-Boot. The version you're experimenting is quite old, I'm afraid. -- Roman Mashak ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ne2000: take MAC address from config if available
Picking up an acient thread, On Sun, Dec 14, 2008 at 12:39:10PM +0100, Daniel Mack wrote: On Sun, Dec 14, 2008 at 12:12:24PM +0100, Wolfgang Denk wrote: This adds CONFIG_NE2000_NOPROM. If set, the ethernet MAC address is taken from the environment variable 'ethaddr' and the NIC is configured accordingly. Needed for boards that don't have an EEPROM to store this setting permanently. Signed-off-by: Daniel Mack dan...@caiaq.de --- ne2000_base.c | 38 -- 1 file changed, 28 insertions(+), 10 deletions(-) Why do we need a special CONFIG_ option? is it not possible to detect (by software) that there is no EEPROM available, and auto-adjust? Hmm, what's bad about a special config variable? I agree that in general, auto-probing is a good thing, but in U-Boot with its per-board configuration file concept, I don't see much advantage. It is very unlikely that a certain board is produced with and without an EEPROM. Note that there is existing policy how to handle the situation that we have both a MAC address stored in some other storeage (like EEPROM on the NIC) and in the ethaddr environment variable (see for example drivers/net/cs8900.c). In the end, the code shall always only rely on the U-Boot environment settings. I can send a new version of this patch following this, but I wonder why such a logic has to be implemented in the ethernet drivers and did not find a well-defined place in some kind of layer all drivers make use of? Wouldn't it make more sense to put some effort in this direction? Is there any reason why there was no reply to this anymore suddenly? Did it sound like too much work for anyone to do it the right way? I'll get back to this project soon and will need to address the same problems agains like many weeks ago, and unfortunately, nothing happened to all the issues I pointed out back then, not a single patch I sent in has been taken. Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] arm: fix some arch_number definition
On 13:02 Tue 27 Jan , Detlev Zundel wrote: Hi Jean-Christophe, Note that there are other places where this is used - these must be changed, too - for example: board/lpc2292sodimm/lpc2292sodimm.c: 42 /* arch number MACH_TYPE_ARMADILLO - not official*/ 43 gd-bd-bi_arch_number = 83; I've not find it in the official list so I've let as 83 (non registered board) You canged the old MACH_TYPE_ARMADILLO / 83 setting in one place but not in others? This will cause inconsistent behaviour. You must not do that. Either leave ALL of these as they are, or fix ALL of them in the SAME way. the other board are not a ARMODILLO correct if I wrong Why not correct the wrong comment? I think this is the consistent thing to do, as there certainly is no definition for 83 in the kernel and 83 has nothing to do with ARMADILLO. This make sense anyway normaly no new arm board will not have a valid machine id now Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ne2000: take MAC address from config if available
Dear Daniel, In message 20090127130912.ga25...@buzzloop.caiaq.de you wrote: I can send a new version of this patch following this, but I wonder why such a logic has to be implemented in the ethernet drivers and did not find a well-defined place in some kind of layer all drivers make use of? Wouldn't it make more sense to put some effort in this direction? Is there any reason why there was no reply to this anymore suddenly? Did it sound like too much work for anyone to do it the right way? I'll get Well, let me answer with a quote from my signature list: There are three ways to get something done: do it yourself, hire someone, or forbid your kids to do it. back to this project soon and will need to address the same problems agains like many weeks ago, and unfortunately, nothing happened to all the issues I pointed out back then, not a single patch I sent in has been taken. You know the reasons why they were rejected. As for the nothing happened part - see signature below :-) Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Business is like a wheelbarrow. Nothing ever happens until you start pushing. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Nasty gunzip problem on MPC8313E-RDB
We have 2 MPC8313E-RDB REVA4 boards. u-boot always fails to uncompress certain compressed files. Either the board will hang or a checkstop occurs. The problem occurs on both our MPC8313E-RDB REVA4 boards. Probably memory is overwritten at the end of RAM (where u-boot is relocated to). When using a jtag debugger no problem occurs. The stock u-boot (shipped by Freescale) has the problem, any custom built u-boot (v2008.10 or v2009-rc3) also has the problem. I tested with u-boot.v2009-rc3 on another board (a PQ2FADS board). The problem doesn't occur on this board. I would like to find this problem and I could use all the help I can get. I'm a bit stuck at the moment. It's not the watchdog, nor the compiler toolchain. The watchdog is completely disabled anyway and other compiler toolchains (including the ones from Freescale) make no difference. I already tried to raise the u-boot malloc() area, it makes no difference either. when compressing using bzip2 (either --best or --fast) no problem occurs. The problem occurs only for gzip compressed files which have one or more dynamic codes blocks and a final fixed codes block. I made a very small one, it's attached. It's only 5802 bytes and md5sum = d5e5a4c95451d256520f1b2a7ace8fa5 Btw. mostly gzip compressed files have dynamic codes blocks only. This file is in fact a collection of random bytes compressed with gzip -9 and a u-boot header in front. If I load this file into RAM (with tftp) and try to uncompress it (by trying to bootm it) the problem always occurs. If anybody is willing to try this file on a MPC8313E-RDB and/or help me with this problem please reply. uImage Description: Binary data ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Reset command on u-boot command line not working
Hello Mashak, I'm using the u-boot what I got with the development board (EP8548A) and we have a custom board Which is pretty similar to that. And I don't want to take any risk in changing the u-boot because is have Stipulated time. I'm done with the custom board bring up as of now, I have issues only in the reset. Please help me in this regard Thanks, Ajeesh Kumar -Original Message- From: Roman Mashak [mailto:romez...@gmail.com] Sent: Tuesday, January 27, 2009 6:46 PM To: aje...@tataelxsi.co.in Cc: Wolfgang Denk; u-boot@lists.denx.de; u-b...@avr32linux.org; Raghavendra T; Siba Prasad Sahu Subject: Re: [U-Boot] Reset command on u-boot command line not working Hello 2009/1/27, Ajeesh Kumar aje...@tataelxsi.co.in: [skip] But, when I give the command reset on the u-boot command line, system hangs printing The below on the console: /***/ U-Boot 1.2.0 (Jan 27 2009 - 17:17:39) [skip] Probably the first thing you should do is grab the latest U-Boot. The version you're experimenting is quite old, I'm afraid. -- Roman Mashak The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3 v3] MIPS: Add VCT board series support (Part 1/3)
Wolfgang Denk wrote: Stefan, I'm going to fold all patches into sinble commit, ok? That's ok with me. Not sure if Wolfgang has an objection though, since he might have problems tracking the status of the patches. Wolfgang, an objections from you? Yes, indeed. I like to see commits matching patches as posted on the mailing list. Ok, sorry for the noise. I'll send a pull request soon. Shinya ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Reset command on u-boot command line not working
Hello, I too got this info, but due to stipulated time, I cant shift to newer version now. I assumed that as development used the same u-boot thought of going with the same. Please help me. Thanks, Ajeesh Kumar -Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Tuesday, January 27, 2009 7:21 PM To: aje...@tataelxsi.co.in Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Reset command on u-boot command line not working Dear Ajeesh Kumar, In message vsnlchnfe0010mg7vas00055...@vsnlchnfe001.vsnlxchange.com you wrote: I'm using the u-boot what I got with the development board (EP8548A) and we have a custom board Which is pretty similar to that. And I don't want to take any risk in changing the u-boot because is have Stipulated time. I'm done with the custom board bring up as of now, I have issues only in the reset. You must not expect much help with obsolete code. U-Boot 1.2.0 is close to 2 years old. A zillion problems has been fixed since in general, and especially for the 8548. Frankly, it makes zero sense to use 1.2.0 on a new custom board. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Everyting looks interesting until you do it. Then you find it's just another job. - Terry Pratchett, _Moving Pictures_ The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [GIT PULL] MIPS updates
Hi Wolfgang, please pull U-Boot/MIPS repository to pick up the following changes. Thanks in advance, Shinya --- The following changes since commit 8f86a3636ef88427f880610638e80991adc41896: Wolfgang Denk (1): Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx are available in the git repository at: git://git.denx.de/u-boot-mips.git master Stefan Roese (4): MIPS: Add flush_dcache_range() and invalidate_dcache_range() MIPS: Add VCT board series support (Part 1/3) MIPS: Add VCT board series support (Part 2/3) MIPS: Add VCT board series support (Part 3/3) MAINTAINERS |4 + MAKEALL | 12 + Makefile | 35 ++ board/micronas/vct/Makefile | 57 +++ board/micronas/vct/bcu.h | 170 + board/micronas/vct/config.mk | 31 ++ board/micronas/vct/dcgu.c| 258 + board/micronas/vct/dcgu.h| 179 + board/micronas/vct/ebi.c | 48 +++ board/micronas/vct/ebi.h | 95 + board/micronas/vct/ebi_nor_flash.c | 131 +++ board/micronas/vct/ebi_onenand.c | 198 ++ board/micronas/vct/ebi_smc911x.c | 94 + board/micronas/vct/ehci.c| 110 ++ board/micronas/vct/gpio.c| 88 + board/micronas/vct/scc.c | 669 ++ board/micronas/vct/scc.h | 205 +++ board/micronas/vct/smc_eeprom.c | 394 board/micronas/vct/top.c | 289 +++ board/micronas/vct/u-boot.lds| 71 board/micronas/vct/vct.c | 117 ++ board/micronas/vct/vct.h | 104 ++ board/micronas/vct/vcth/reg_dcgu.h | 36 ++ board/micronas/vct/vcth/reg_ebi.h| 242 board/micronas/vct/vcth/reg_fwsram.h | 73 board/micronas/vct/vcth/reg_gpio.h | 32 ++ board/micronas/vct/vcth/reg_scc.h| 102 + board/micronas/vct/vcth/reg_usbh.h | 33 ++ board/micronas/vct/vcth/reg_wdt.h| 24 ++ board/micronas/vct/vcth2/reg_ebi.h | 290 +++ board/micronas/vct/vctv/reg_dcgu.h | 25 ++ board/micronas/vct/vctv/reg_ebi.h| 290 +++ board/micronas/vct/vctv/reg_gpio.h | 32 ++ board/micronas/vct/vctv/reg_wdt.h| 24 ++ cpu/mips/cpu.c | 28 ++ include/common.h |2 + include/configs/vct.h| 340 + 37 files changed, 4932 insertions(+), 0 deletions(-) create mode 100644 board/micronas/vct/Makefile create mode 100644 board/micronas/vct/bcu.h create mode 100644 board/micronas/vct/config.mk create mode 100644 board/micronas/vct/dcgu.c create mode 100644 board/micronas/vct/dcgu.h create mode 100644 board/micronas/vct/ebi.c create mode 100644 board/micronas/vct/ebi.h create mode 100644 board/micronas/vct/ebi_nor_flash.c create mode 100644 board/micronas/vct/ebi_onenand.c create mode 100644 board/micronas/vct/ebi_smc911x.c create mode 100644 board/micronas/vct/ehci.c create mode 100644 board/micronas/vct/gpio.c create mode 100644 board/micronas/vct/scc.c create mode 100644 board/micronas/vct/scc.h create mode 100644 board/micronas/vct/smc_eeprom.c create mode 100644 board/micronas/vct/top.c create mode 100644 board/micronas/vct/u-boot.lds create mode 100644 board/micronas/vct/vct.c create mode 100644 board/micronas/vct/vct.h create mode 100644 board/micronas/vct/vcth/reg_dcgu.h create mode 100644 board/micronas/vct/vcth/reg_ebi.h create mode 100644 board/micronas/vct/vcth/reg_fwsram.h create mode 100644 board/micronas/vct/vcth/reg_gpio.h create mode 100644 board/micronas/vct/vcth/reg_scc.h create mode 100644 board/micronas/vct/vcth/reg_usbh.h create mode 100644 board/micronas/vct/vcth/reg_wdt.h create mode 100644 board/micronas/vct/vcth2/reg_ebi.h create mode 100644 board/micronas/vct/vctv/reg_dcgu.h create mode 100644 board/micronas/vct/vctv/reg_ebi.h create mode 100644 board/micronas/vct/vctv/reg_gpio.h create mode 100644 board/micronas/vct/vctv/reg_wdt.h create mode 100644 include/configs/vct.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] Add 16bpp BMP support
This patch adds 16bpp BMP support to the common lcd code.
Use CONFIG_BMP_16BPP and set LCD_BPP to LCD_COLOR16 to enable the code.
At the moment it's only been tested on the MIMC200 AVR32 board, but extending
this to other platforms should be a simple task !!
Signed-off-by: Mark Jackson m...@mimc.co.uk
---
common/lcd.c | 49 +++--
1 files changed, 39 insertions(+), 10 deletions(-)
diff --git a/common/lcd.c b/common/lcd.c
index ae79051..16d6f2a 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -84,7 +84,7 @@ extern void lcd_enable (void);
static void *lcd_logo (void);
-#if LCD_BPP == LCD_COLOR8
+#if (LCD_BPP == LCD_COLOR8) || (LCD_BPP == LCD_COLOR16)
extern void lcd_setcolreg (ushort regno,
ushort red, ushort green, ushort blue);
#endif
@@ -656,7 +656,7 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
bpix = NBITS(panel_info.vl_bpix);
- if ((bpix != 1) (bpix != 8)) {
+ if ((bpix != 1) (bpix != 8) (bpix != 16)) {
printf (Error: %d bit/pixel mode not supported by U-Boot\n,
bpix);
return 1;
@@ -738,17 +738,46 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
bmap = (uchar *)bmp + le32_to_cpu (bmp-header.data_offset);
fb = (uchar *) (lcd_base +
(y + height - 1) * lcd_line_length + x);
- for (i = 0; i height; ++i) {
- WATCHDOG_RESET();
- for (j = 0; j width ; j++)
+
+ switch (bpix) {
+ case 1: /* pass through */
+ case 8:
+ for (i = 0; i height; ++i) {
+ WATCHDOG_RESET();
+ for (j = 0; j width ; j++)
#if defined(CONFIG_PXA250) || defined(CONFIG_ATMEL_LCD)
- *(fb++) = *(bmap++);
+ *(fb++) = *(bmap++);
#elif defined(CONFIG_MPC823) || defined(CONFIG_MCC200)
- *(fb++)=255-*(bmap++);
+ *(fb++)=255-*(bmap++);
#endif
- bmap += (width - padded_line);
- fb -= (width + lcd_line_length);
- }
+ bmap += (width - padded_line);
+ fb -= (width + lcd_line_length);
+ }
+ break;
+
+#if defined(CONFIG_BMP_16BPP)
+ case 16:
+ for (i = 0; i height; ++i) {
+ WATCHDOG_RESET();
+ for (j = 0; j width; j++) {
+#if defined(CONFIG_ATMEL_LCD_BGR555)
+ *(fb++) = ((bmap[0] 0x1f) 2) | (bmap[1]
0x03);
+ *(fb++) = (bmap[0] 0xe0) | ((bmap[1] 0x7c)
2);
+ bmap += 2;
+#else
+ *(fb++) = *(bmap++);
+ *(fb++) = *(bmap++);
+#endif
+ }
+ bmap += (padded_line - width) * 2;
+ fb -= (width * 2 + lcd_line_length);
+ }
+ break;
+#endif /* CONFIG_BMP_16BPP */
+
+ default:
+ break;
+ };
return (0);
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Reset command on u-boot command line not working
On Jan 27, 2009, at 8:13 AM, Ajeesh Kumar wrote: Hello, I too got this info, but due to stipulated time, I cant shift to newer version now. I assumed that as development used the same u-boot thought of going with the same. Please help me. Thanks, Ajeesh Kumar Odds are that the reset command isn't doing a full board reset and just resetting the core and thus you are seeing some hang from that. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH/RFC, 0/2] I2C rework -- what do you think?
Hello ksi, k...@koi8.net wrote: Hi everyone, Here is the first draft of major I2C subsystem rework. This is not a patch that should be applied to the tree--it will break systems with I2C busses over multiplexers and probably something else--but rather a Request For Comments. I would like to here all the objections, suggestions etc. before I go on and undertake a big job to change all the boards and other stuff to the new code. It is a big job and I don't want to spend a lot of time doing something that nobody would accept. Yes, this would be a big job, and how do you want to test this for ~200 boards? My goal is to somehow untie I2C subsystem from platform-specific parts. This Isn t this so? is not an attempt for a code cleanup though some cleanup could be achieved in process. But this is not a goal, it is just a probable side effect. Primary goal is to allow multiple I2C busses on a board served by different I2C controllers (on-SoC, external, bit-banging.) As of now we have rudimentary support for multiple BUILT-IN adapters in some SoCs (e.g. fsl_i2c.c) but this support is platform specific and does NOT allow any additional (external etc.) adapters. Ah... okay, this lacks in the actual u-boot i2c layer. I see here to ways: a) Rewriting the complete code. This is really a big change (maybe, I am not a I2C expert, the cleaner way, but this will need a long time and a good test period ...) b) It should be possible to extend the i2c hardware specific functions, to allow more then one i2c platform adapter. Switching between those should possible with the i2c dev command (Which I think is the reason for this command) also i2c bus should be extend to choose, which real I2C Bus it uses. Something like this comes in my mind: i2c bus devid=[muxtype:muxaddr:muxchannel] with devid (an existing device id see i2c dev command) if devid= is missing, old behaviour (backward compatible) This is not a problem for a vast majority of supported boards that usually have a single I2C bus but there are cases when boards have several busses served by different I2C adapters. I personally have the first prototype of [...] Here is a little manifest... First of all, there is a basic entity, I2C bus. It can be a simple I2C bus from the only I2C adapter on a SoC, several busses from several adapters, both on-SoC and external, and several busses growing off of several adapters via I2C multiplexers/switches (e.g. PCA9544 etc.) They are all the same for the rest of code accessed with single set of i2c_read()/i2c_write() and friends for all busses no matter what adapter they are on and if they are directly connected to an adapter or reached through a set of I2C mux chips. Any I2C operation is performed on the CURRENT bus. Current bus is set with i2c_set_bus_num(). In case of directly connected busses it merely changes a global variable that is used as an index into an array. If some busses are connected via I2C muxes, it disconnects the previously connected muxes if any and sets all chips along the path to the new bus so next access will go to that bus. All those paths are statically allocated at compile time according to Why must be this statically defined? Think of a Hardwaremanufacturer who has several boardvariants. In your case, he must have for every board a config file - different binaries. In the case using i2c bus he has one binary which is able to work with all of his variants! And he can connect on a running system on an actual not used I2C Bus, another mux for example, and can configure this new bus per commandline without generating a new binary, flashing, resetting the board! Ah, now I understand why you have to change all config files for all existing boards which uses I2C. Think of my suggestion to integrate the multi real bus in the existing code, so you dont have to do this ... boards which have only one Hardware I2C Bus automagically use this bus, because i2c_bus_cur = 0! board's config file. That means we can use I2C from flash before U-Boot is relocated to DRAM thus allowing us to use SPD for DRAM initialization. It is You can also use in actual code SPD EEprom for DRAM initialization. Guess the following example: SPD EEprom reached over 2 muxes: define an Environment var like: SPD_EEprom =pca9554a:70:5:pca9544a:71:4 now make bevor accessing the SPD EEprom: i2c_mux_ident_muxstring_f (getenv (SPD_EEprom); and you can access the SPD EEProm! (And nice side effect, the way to your SPD EEprom is not fix in the code, you can choose it easy per Env var!) But, so my feeling, it would be a good idea, to connect a SPD EEprom not over a mux, at least only on channel 0, so no mux commands are necessary to read from the SPD EEprom after reset. also means we do NOT need that i2c bus or whatever command to setup a bus behind muxes for consecutive access--we just choose
Re: [U-Boot] Reset command on u-boot command line not working
Dear Ajeesh Kumar, In message vsnlchnfe00165wytn400055...@vsnlchnfe001.vsnlxchange.com you wrote: I too got this info, but due to stipulated time, I cant shift to newer version now. I assumed that as development used the same u-boot thought of going with the same. Please help me. Feel free to check the history of changes in the git repository for commits that have impact on the initialization and reset of the 8548. There should be several. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Always borrow money from a pessimist; they don't expect to be paid back. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot fails to uncompress a gzip'ed -9 kernel
Hi Norbert,
I missed the start of this thread. So my apologies if im barking up the
wrong tree :)
We had problems uncompressing zImages on our 8313 board. But always
suspected some memory timing issues, or perhaps some strangeness in
8313.
I tracked our problems down to a specific line in lib_generic/zlib.c And
by adding a small delay there our problems went away. (I know this is
not good practice. But with time limited that is what you do.)
Inlined (Pasted) is our patch that solved our problem:
8-
--- [74f22482c362bbc50f1188bd5d31203e7995a9b4] zlib.c
+++ [88e71e289d0241baaa9db0624b98f00b5f1774b5] zlib.c
@@ -1604,6 +1604,7 @@
while (p != Z_NULL)
{
q = (--p)-next;
+ udelay(10);
ZFREE(z, p, p-word.Nalloc * sizeof(inflate_huft));
p = q;
}
8-
/Tor
On Tue, 2009-01-27 at 11:05 +0100, Norbert van Bolhuis wrote:
This is a MPC8313E-RDB board problem. We have 2 REV A4 boards.
I can reproduce this problem on both of the MPC8313E-RDB boards
with any version of u-boot with a compressed file which contains
1 or more dynamic codes blocks and a final fixed codes block.
I have a 5k gzipped file for which the problem (already) occurs.
I could test on a PQ2FADS board. The problem doesn't occur on this
board.
I did some memory tests (which I should've done a bit earlier) and
the same problem (soft reset due to checkstop) occurs.
I'll make a new thread for this.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Reset command on u-boot command line not working
Dear Ajeesh Kumar, Odds are that the reset command isn't doing a full board reset and just resetting the core and thus you are seeing some hang from that. - k You may check your board design also. Is HRESET routed to all components on your board? Is the switch giving HRESET or triggering any power control IC? Regards, Jayakrishnan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Backup Booting
Hi Guys, I was wondering if there is any think like backup booting and secondary image for example lets say i am booting an image and it fails CRC check etc... i want to to validate that the backup image is good and then overwrite the current image with the backup image and be able to boot of the backup image. Second option of failure is image start booting and it fails in middle of booting maybe watchdog kicks in and reset the board. Is there a way to tell image fail booting and uses back instead. Pawel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Backup Booting
Dear Pawel Pastuszak, In message 8ff29df80901270734h2791b9f3qf72b99830860c...@mail.gmail.com you wrote: I was wondering if there is any think like backup booting and secondary image for example lets say i am booting an image and it fails CRC check etc... i want to to validate that the backup image is good and then overwrite the current image with the backup image and be able to boot of the backup image. Yes, there is such a thing, and you would know it if you had read the manual. Second option of failure is image start booting and it fails in middle of booting maybe watchdog kicks in and reset the board. Is there a way to tell image fail booting and uses back instead. Yes, there is such a thing, and you would know it if you had read the manual. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Nobody will ever need more than 640k RAM! -- Bill Gates, 1981 Windows 95 needs at least 8 MB RAM. -- Bill Gates, 1996 Nobody will ever need Windows 95. -- logical conclusion ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Backup Booting
Where do i find the manual? On Tue, Jan 27, 2009 at 10:41 AM, Wolfgang Denk w...@denx.de wrote: Dear Pawel Pastuszak, In message 8ff29df80901270734h2791b9f3qf72b99830860c...@mail.gmail.com you wrote: I was wondering if there is any think like backup booting and secondary image for example lets say i am booting an image and it fails CRC check etc... i want to to validate that the backup image is good and then overwrite the current image with the backup image and be able to boot of the backup image. Yes, there is such a thing, and you would know it if you had read the manual. Second option of failure is image start booting and it fails in middle of booting maybe watchdog kicks in and reset the board. Is there a way to tell image fail booting and uses back instead. Yes, there is such a thing, and you would know it if you had read the manual. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Nobody will ever need more than 640k RAM! -- Bill Gates, 1981 Windows 95 needs at least 8 MB RAM. -- Bill Gates, 1996 Nobody will ever need Windows 95. -- logical conclusion ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Watchdog timer and booting in Linux kernel
Hi,
I am using u-boot and linux kernel on our custom PPC440gx board.
The board was booting without any issue.
The board started rebooting while booting in linux kernel after enabled
the watchdog timer in u-boot by defining 'CONFIG_WATCHDOG'.
I have observed that the board gets reset while booting in Linux.
I followed the discussion available on:
http://osdir.com/ml/boot-loaders.u-boot/2001-07/msg00121.html
I modified the code given in above link to run it on ppc440gx processor.
I have written a function 'reset_watchdog()' in kernel which will reset
the Watchdog Timer (same as available in u-boot) and called in
'timer_interrupt()' of /arch/ppc/kernel/time.c' But the function is not
giving any effect. The board is still getting rebooted.
8-arch/ppc/kernel/time.c
unsigned long sched_watchdog_counter = 0;
void reset_watchdog()
{
unsigned long val = 0;
char buff[20];
local_irq_disable();
val = mfspr(0x150);
mtspr(0x150, !(val) | 0x4000);
val = mfspr(0x150);
sprintf(buff,val = %x\n,val);
local_irq_enable();
}
void timer_interrupt(struct pt_regs * regs)
{
:
:
:
reset_watchdog();
irq_exit();
}
8-arch/ppc/kernel/time.c
Can you help me to boot the board in Linux kernel with watchdog enabled
in u-boot?
Regards,
Sachin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Backup Booting
Dear Pawel Pastuszak, In message 8ff29df80901270743t7962d14aia1cf7b613899d...@mail.gmail.com you wrote: Where do i find the manual? Hm.. does google u-boot manual ring a bell? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Contrary to popular belief, thinking does not cause brain damage. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Watchdog timer and booting in Linux kernel
Dear Sachin Rane, In message 73fa539107892c4c8c7a5aca10c161c85be...@mx2.alphioncorp.local you wrote: I am using u-boot and linux kernel on our custom PPC440gx board. The board was booting without any issue. The board started rebooting while booting in linux kernel after enabled the watchdog timer in u-boot by defining 'CONFIG_WATCHDOG'. That is to be expected unless you have working watchdog support in your Linux kernel, too. I have observed that the board gets reset while booting in Linux. Yes, the watchdog is supposed to do exactly that. So everything is indeed working as expected. I followed the discussion available on: http://osdir.com/ml/boot-loaders.u-boot/2001-07/msg00121.html Ouch. That is a *bit* old, it deems. I modified the code given in above link to run it on ppc440gx processor. Why don't you use the existing code for example for 440EPx from our kernel tree? I have written a function 'reset_watchdog()' in kernel which will reset the Watchdog Timer (same as available in u-boot) and called in 'timer_interrupt()' of /arch/ppc/kernel/time.c' But the function is not giving any effect. The board is still getting rebooted. arch/ppc/ ? arch/ppc/ is dead. It has been removed from the Linux kernel tree a long time ago. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de For every problem there is one solution which is simple, neat, and wrong.- H. L. Mencken ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/5] OMAP3: Add common power code, README, and BeagleBoard
Add BeagleBoard support, common power code and README.
Signed-off-by: Jason Kridner jkrid...@beagleboard.org
Signed-off-by: Dirk Behme dirk.be...@googlemail.com
---
Changes in v3:
- Fix missing entry in MAKEALL
This patch replaces v2 version of this patch. All other v2 version
patches are still valid.
MAINTAINERS|4
MAKEALL| 28 +--
Makefile |7
board/omap3/beagle/Makefile| 49 +
board/omap3/beagle/beagle.c| 90 +
board/omap3/beagle/beagle.h| 376 +
board/omap3/beagle/config.mk | 33 +++
board/omap3/beagle/u-boot.lds | 63 ++
board/omap3/common/Makefile| 50 +
board/omap3/common/power.c | 74
doc/README.omap3 | 72 +++
include/configs/omap3_beagle.h | 325 +++
12 files changed, 1161 insertions(+), 10 deletions(-)
create mode 100644 board/omap3/beagle/Makefile
create mode 100644 board/omap3/beagle/beagle.c
create mode 100644 board/omap3/beagle/beagle.h
create mode 100644 board/omap3/beagle/config.mk
create mode 100644 board/omap3/beagle/u-boot.lds
create mode 100644 board/omap3/common/Makefile
create mode 100644 board/omap3/common/power.c
create mode 100644 doc/README.omap3
create mode 100644 include/configs/omap3_beagle.h
Index: u-boot-arm/MAINTAINERS
===
--- u-boot-arm.orig/MAINTAINERS
+++ u-boot-arm/MAINTAINERS
@@ -486,6 +486,10 @@ Rowel Atienza ro...@diwalabs.com
armadillo ARM720T
+Dirk Behme dirk.be...@gmail.com
+
+ omap3_beagleARM CORTEX-A8 (OMAP3530 SoC)
+
Rishi Bhattacharya ri...@ti.com
omap5912osk ARM926EJS
Index: u-boot-arm/MAKEALL
===
--- u-boot-arm.orig/MAKEALL
+++ u-boot-arm/MAKEALL
@@ -545,6 +545,13 @@ LIST_ARM11= \
#
+## ARM Cortex-A8 Systems
+#
+LIST_ARM_CORTEX_A8= \
+ omap3_beagle\
+
+
+#
## AT91 Systems
#
@@ -598,15 +605,16 @@ LIST_ixp=\
## ARM groups
#
-LIST_arm= \
- ${LIST_SA} \
- ${LIST_ARM7}\
- ${LIST_ARM9}\
- ${LIST_ARM10} \
- ${LIST_ARM11} \
- ${LIST_at91}\
- ${LIST_pxa} \
- ${LIST_ixp} \
+LIST_arm= \
+ ${LIST_SA} \
+ ${LIST_ARM7}\
+ ${LIST_ARM9}\
+ ${LIST_ARM10} \
+ ${LIST_ARM11} \
+ ${LIST_ARM_CORTEX_A8} \
+ ${LIST_at91}\
+ ${LIST_pxa} \
+ ${LIST_ixp} \
#
@@ -822,7 +830,7 @@ build_target() {
for arg in $@
do
case $arg in
- arm|SA|ARM7|ARM9|ARM10|ARM11|at91|ixp|pxa \
+ arm|SA|ARM7|ARM9|ARM10|ARM11|ARM_CORTEX_A8|at91|ixp|pxa \
|avr32 \
|blackfin \
|coldfire \
Index: u-boot-arm/Makefile
===
--- u-boot-arm.orig/Makefile
+++ u-boot-arm/Makefile
@@ -2905,6 +2905,13 @@ SMN42_config : unconfig
@$(MKCONFIG) $(@:_config=) arm arm720t SMN42 siemens lpc2292
#
+## ARM CORTEX Systems
+#
+
+omap3_beagle_config : unconfig
+ @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 beagle omap3 omap3
+
+#
## XScale Systems
#
Index: u-boot-arm/board/omap3/beagle/Makefile
===
--- /dev/null
+++ u-boot-arm/board/omap3/beagle/Makefile
@@ -0,0 +1,49 @@
+#
+# (C) Copyright 2000, 2001, 2002
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See
Re: [U-Boot] Backup Booting
Yes i found it. http://www.denx.de/wiki/view/DULG/UBootBootCountLimit Thanks for your kind words. ;-) Regards, Pawel On Tue, Jan 27, 2009 at 11:57 AM, Wolfgang Denk w...@denx.de wrote: Dear Pawel Pastuszak, In message 8ff29df80901270743t7962d14aia1cf7b613899d...@mail.gmail.com you wrote: Where do i find the manual? Hm.. does google u-boot manual ring a bell? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Contrary to popular belief, thinking does not cause brain damage. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] IP_t should be a packed struct
Hi ML,
I'm working on a mips target and I used qemu_mips target to simulate my target
(that I hope to have in the next week...)
Following my activities I noticed that IP_t structure is no defined with
attribute packed. I noticed this issue because using a self-made toolchain
(gcc4.2.4+binutils2.8+uclibc0.9.30) the compiler has aligned all bytes to
32bit boundary. This is not ok, because the packets IP_t can be non aligned
(see the /net/net.c PingSend function, for an example).
The dirty solution is to define the structure with the
__attribute__((__packed__))... but, from my point of view, a better packet
forging mechanism should be implemented into the net.c stack.
I attached a trivial patch that solved the issue on my target.
Any comments is welcome.
best regards,
luigi
--
Luigi Mantellini
RD - Software
Industrie Dial Face S.p.A.
Via Canzo, 4
20068 Peschiera Borromeo (MI), Italy
Tel.: +39 02 5167 2813
Fax: +39 02 5167 2459
Email: luigi.mantell...@idf-hit.com
diff --git a/include/net.h b/include/net.h
index d2d394f..c04f84c 100644
--- a/include/net.h
+++ b/include/net.h
@@ -198,7 +198,7 @@ typedef struct {
ushort udp_dst; /* UDP destination port */
ushort udp_len; /* Length of UDP packet */
ushort udp_xsum; /* Checksum */
-} IP_t;
+} __attribute__((__packed__)) IP_t;
#define IP_OFFS 0x1fff /* ip offset *= 8 */
#define IP_FLAGS 0xe000 /* first 3 bits */
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Backup Booting
Dear Pawel Pastuszak, In message 8ff29df80901271011m3b7adc76u627162f9c5b3a...@mail.gmail.com you wrote: Yes i found it. http://www.denx.de/wiki/view/DULG/UBootBootCountLimit Thisi s only part two. The first part (using an alternative image in case the first one has a bad CRC, etc. can for example be found in http://www.denx.de/wiki/view/DULG/CommandLineParsing Thanks for your kind words. ;-) Did you understand why I was replying like I did? Give a man a fish, and you feed him for a day. Teach a man to fish, and he'll invite himself over for dinner. - Calvin Keegan You got it? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Men of peace usually are [brave]. -- Spock, The Savage Curtain, stardate 5906.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ppc4xx] Please pull git://www.denx.de/git/u-boot-ppc4xx.git
Dear Stefan Roese, In message 200901261047.36562...@denx.de you wrote: The following changes since commit 8f86a3636ef88427f880610638e80991adc41896: Wolfgang Denk (1): Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx are available in the git repository at: git://www.denx.de/git/u-boot-ppc4xx.git master Dirk Eibach (2): ppc4xx: Improve DDR autodetect ppc4xx: Add GDsys PowerPC 440 ETX board support. Matthias Fuchs (1): ppc4xx: Remove CONFIG_SYS_IGNORE_405_UART_ERRATA_59 from config files Stefan Roese (1): ppc4xx: Remove compilation warning in gdppc440etc.c MAINTAINERS |1 + MAKEALL |1 + Makefile |3 + board/gdsys/gdppc440etx/Makefile | 51 + board/gdsys/gdppc440etx/config.mk | 44 + board/gdsys/gdppc440etx/gdppc440etx.c | 323 + board/gdsys/gdppc440etx/init.S| 75 board/gdsys/gdppc440etx/u-boot.lds| 144 +++ cpu/ppc4xx/sdram.c| 55 +- include/configs/ASH405.h |1 - include/configs/CATcenter.h |1 - include/configs/CMS700.h |1 - include/configs/CPCI2DP.h |1 - include/configs/CPCI405.h |1 - include/configs/CPCI4052.h|1 - include/configs/CPCI405AB.h |1 - include/configs/CPCI405DT.h |1 - include/configs/DP405.h |1 - include/configs/G2000.h |1 - include/configs/HH405.h |1 - include/configs/HUB405.h |1 - include/configs/OCRTC.h |1 - include/configs/ORSG.h|1 - include/configs/PCI405.h |1 - include/configs/PLU405.h |1 - include/configs/PMC405.h |1 - include/configs/PPChameleonEVB.h |1 - include/configs/VOH405.h |1 - include/configs/VOM405.h |1 - include/configs/WUH405.h |1 - include/configs/csb272.h |1 - include/configs/csb472.h |1 - include/configs/gdppc440etx.h | 194 include/configs/sbc405.h |1 - 34 files changed, 886 insertions(+), 29 deletions(-) create mode 100644 board/gdsys/gdppc440etx/Makefile create mode 100644 board/gdsys/gdppc440etx/config.mk create mode 100644 board/gdsys/gdppc440etx/gdppc440etx.c create mode 100644 board/gdsys/gdppc440etx/init.S create mode 100644 board/gdsys/gdppc440etx/u-boot.lds create mode 100644 include/configs/gdppc440etx.h Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de To understand a program you must become both the machine and the program. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [cfi-flash] Please pull git://www.denx.de/git/u-boot-cfi-flash.git
Dear Stefan Roese, In message 200901261125.51840...@denx.de you wrote: The following changes since commit 8f86a3636ef88427f880610638e80991adc41896: Wolfgang Denk (1): Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx are available in the git repository at: git://www.denx.de/git/u-boot-cfi-flash.git master Jens Gehrlein (2): CFI: avoid redundant function call in single word programming mode CFI: increase performance of function find_sector() Richard Retanubun (1): CFI: Add geometry reversal for STMicro M29W320ET drivers/mtd/cfi_flash.c | 50 +- 1 files changed, 40 insertions(+), 10 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de More software projects have gone awry for lack of calendar time than for all other causes combined. - Fred Brooks, Jr., _The Mythical Man Month_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] MIPS updates
Dear Shinya Kuribayashi, In message 497f1752.1060...@ruby.dti.ne.jp you wrote: Hi Wolfgang, please pull U-Boot/MIPS repository to pick up the following changes. Thanks in advance, Shinya --- The following changes since commit 8f86a3636ef88427f880610638e80991adc41896: Wolfgang Denk (1): Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx are available in the git repository at: git://git.denx.de/u-boot-mips.git master Stefan Roese (4): MIPS: Add flush_dcache_range() and invalidate_dcache_range() MIPS: Add VCT board series support (Part 1/3) MIPS: Add VCT board series support (Part 2/3) MIPS: Add VCT board series support (Part 3/3) MAINTAINERS |4 + MAKEALL | 12 + Makefile | 35 ++ board/micronas/vct/Makefile | 57 +++ board/micronas/vct/bcu.h | 170 + board/micronas/vct/config.mk | 31 ++ board/micronas/vct/dcgu.c| 258 + board/micronas/vct/dcgu.h| 179 + board/micronas/vct/ebi.c | 48 +++ board/micronas/vct/ebi.h | 95 + board/micronas/vct/ebi_nor_flash.c | 131 +++ board/micronas/vct/ebi_onenand.c | 198 ++ board/micronas/vct/ebi_smc911x.c | 94 + board/micronas/vct/ehci.c| 110 ++ board/micronas/vct/gpio.c| 88 + board/micronas/vct/scc.c | 669 ++ board/micronas/vct/scc.h | 205 +++ board/micronas/vct/smc_eeprom.c | 394 board/micronas/vct/top.c | 289 +++ board/micronas/vct/u-boot.lds| 71 board/micronas/vct/vct.c | 117 ++ board/micronas/vct/vct.h | 104 ++ board/micronas/vct/vcth/reg_dcgu.h | 36 ++ board/micronas/vct/vcth/reg_ebi.h| 242 board/micronas/vct/vcth/reg_fwsram.h | 73 board/micronas/vct/vcth/reg_gpio.h | 32 ++ board/micronas/vct/vcth/reg_scc.h| 102 + board/micronas/vct/vcth/reg_usbh.h | 33 ++ board/micronas/vct/vcth/reg_wdt.h| 24 ++ board/micronas/vct/vcth2/reg_ebi.h | 290 +++ board/micronas/vct/vctv/reg_dcgu.h | 25 ++ board/micronas/vct/vctv/reg_ebi.h| 290 +++ board/micronas/vct/vctv/reg_gpio.h | 32 ++ board/micronas/vct/vctv/reg_wdt.h| 24 ++ cpu/mips/cpu.c | 28 ++ include/common.h |2 + include/configs/vct.h| 340 + 37 files changed, 4932 insertions(+), 0 deletions(-) create mode 100644 board/micronas/vct/Makefile create mode 100644 board/micronas/vct/bcu.h create mode 100644 board/micronas/vct/config.mk create mode 100644 board/micronas/vct/dcgu.c create mode 100644 board/micronas/vct/dcgu.h create mode 100644 board/micronas/vct/ebi.c create mode 100644 board/micronas/vct/ebi.h create mode 100644 board/micronas/vct/ebi_nor_flash.c create mode 100644 board/micronas/vct/ebi_onenand.c create mode 100644 board/micronas/vct/ebi_smc911x.c create mode 100644 board/micronas/vct/ehci.c create mode 100644 board/micronas/vct/gpio.c create mode 100644 board/micronas/vct/scc.c create mode 100644 board/micronas/vct/scc.h create mode 100644 board/micronas/vct/smc_eeprom.c create mode 100644 board/micronas/vct/top.c create mode 100644 board/micronas/vct/u-boot.lds create mode 100644 board/micronas/vct/vct.c create mode 100644 board/micronas/vct/vct.h create mode 100644 board/micronas/vct/vcth/reg_dcgu.h create mode 100644 board/micronas/vct/vcth/reg_ebi.h create mode 100644 board/micronas/vct/vcth/reg_fwsram.h create mode 100644 board/micronas/vct/vcth/reg_gpio.h create mode 100644 board/micronas/vct/vcth/reg_scc.h create mode 100644 board/micronas/vct/vcth/reg_usbh.h create mode 100644 board/micronas/vct/vcth/reg_wdt.h create mode 100644 board/micronas/vct/vcth2/reg_ebi.h create mode 100644 board/micronas/vct/vctv/reg_dcgu.h create mode 100644 board/micronas/vct/vctv/reg_ebi.h create mode 100644 board/micronas/vct/vctv/reg_gpio.h create mode 100644 board/micronas/vct/vctv/reg_wdt.h create mode 100644 include/configs/vct.h Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There are certain things men must do to remain men. -- Kirk, The Ultimate Computer, stardate 4929.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix gunzip in case of insufficient output buffer
Dear Matthias Fuchs, In message 200901021511.42036.matthias.fu...@esd-electronics.com you wrote: U-Boot's gunzip() function does not handle the return code of zlib's inflate() function correctly. gunzip() is implemented to uncompress all input data in one run. So the correct return code for the good case is Z_STREAM_END. In case of insufficient output buffer memory inflate returns Z_OK. For gunzip() this is an error. It also makes sense to me to call inflateEnd() also in case of an error. Signed-off-by: Matthias Fuchs matthias.fu...@esd-electronics.com --- common/cmd_bootm.c |2 +- lib_generic/gunzip.c |3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de HEALTH WARNING: Care Should Be Taken When Lifting This Product, Since Its Mass, and Thus Its Weight, Is Dependent on Its Velocity Relative to the User. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Backup Booting
Yeah i understand completely . thanks for pointing me in the right direction... P.S: I like this quote better ;-) Give a man a fish and he won't starve for a day. Teach a man how to fish and he won't starve for his entire life. -- Calvin Keegan Regards, Pawel On Tue, Jan 27, 2009 at 2:28 PM, Wolfgang Denk w...@denx.de wrote: Dear Pawel Pastuszak, In message 8ff29df80901271011m3b7adc76u627162f9c5b3a...@mail.gmail.com you wrote: Yes i found it. http://www.denx.de/wiki/view/DULG/UBootBootCountLimit Thisi s only part two. The first part (using an alternative image in case the first one has a bad CRC, etc. can for example be found in http://www.denx.de/wiki/view/DULG/CommandLineParsing Thanks for your kind words. ;-) Did you understand why I was replying like I did? Give a man a fish, and you feed him for a day. Teach a man to fish, and he'll invite himself over for dinner. - Calvin Keegan You got it? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Men of peace usually are [brave]. -- Spock, The Savage Curtain, stardate 5906.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] sprintf side effect, a bug?
On Monday 26 January 2009 04:30:36 pm Wolfgang Denk wrote:
Dear E Robertson,
In message 200901261453.10434.e.robertson@gmail.com you wrote:
It seems that sprintf() is modifying at least two bytes from the source
and I have duplicate this with different varibles.
For instance, I have a mac address defined as unsigned char [6]:
Doing the following sets the environment variable correctly, however
bytes [0] and [1], are modified at the source.
sprintf(env_ethaddr,%02X:%02X:%02X:%02X:%02X:%02X, MACAddress[0],
MACAddress[1],
MACAddress[2], MACAddress[3],
MACAddress[4], MACAddress[5]);
Has anyone noticed this before?
I don't think the machine matters but I am building for an arm at91.
Hmm... I think I wouldbe surprised. What exactly does your test code
look like?
I tried this one:
...
unsigned char buf[128];
unsigned char a[6] = { 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, };
int i;
...
printf (Before: ); for (i=0; i6; ++i) printf ( %02X,a[i]); putc
('\n'); sprintf (buf, %02X:%02X:%02X:%02X:%02X:%02X, a[0], a[1], a[2],
a[3], a[4], a[5]); printf (After: ); for (i=0; i6; ++i) printf (
%02X,a[i]); putc ('\n'); printf (buf=\%s\\n, buf);
...
And this is what I got:
Before: 11 22 33 44 55 66
After: 11 22 33 44 55 66
buf=11:22:33:44:55:66
Hi,
I did the following:
memcpy (gd-bd-bi_enetaddr, MACAddress, sizeof(gd-bd-bi_enetaddr));
memcpy (dupMACAddress, MACAddress, sizeof(dupMACAddress));
printf(Before %02X:%02X:%02X:%02X:%02X:%02X\n,dupMACAddress[0],
dupMACAddress[1],
dupMACAddress[2], dupMACAddress[3],
dupMACAddress[4], dupMACAddress[5]);
sprintf(env_ethaddr,%02X:%02X:%02X:%02X:%02X:%02X,dupMACAddress[0],
dupMACAddress[1],
dupMACAddress[2], dupMACAddress[3],
dupMACAddress[4], dupMACAddress[5]);
printf(After %02X:%02X:%02X:%02X:%02X:%02X\n,dupMACAddress[0],
dupMACAddress[1],
dupMACAddress[2], dupMACAddress[3],
dupMACAddress[4], dupMACAddress[5]);
printf(ethaddr %02X:%02X:%02X:%02X:%02X:%02X\n,gd-bd-bi_enetaddr[0],
gd-bd-bi_enetaddr[1],
gd-bd-bi_enetaddr[2], gd-bd-bi_enetaddr[3],
gd-bd-bi_enetaddr[4], gd-bd-bi_enetaddr[5]);
and I got this:
Before 00:04:A6:00:6A:E6
After 36:00:A6:00:6A:E6
ethaddr 00:04:A6:00:6A:E6
Alse env_ethaddr has the correct correct.
I make a duplicate before did the sprintf.
I'm also on v 1.3.4 and haven't tried it on the latest git.
Looks sane to me...
Best regards,
Wolfgang Denk
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] sprintf side effect, a bug?
E Robertson wrote: I did the following: memcpy (gd-bd-bi_enetaddr, MACAddress, sizeof(gd-bd-bi_enetaddr)); memcpy (dupMACAddress, MACAddress, sizeof(dupMACAddress)); printf(Before %02X:%02X:%02X:%02X:%02X:%02X\n,dupMACAddress[0], dupMACAddress[1], dupMACAddress[2], dupMACAddress[3], dupMACAddress[4], dupMACAddress[5]); sprintf(env_ethaddr,%02X:%02X:%02X:%02X:%02X:%02X,dupMACAddress[0], dupMACAddress[1], dupMACAddress[2], dupMACAddress[3], dupMACAddress[4], dupMACAddress[5]); printf(After %02X:%02X:%02X:%02X:%02X:%02X\n,dupMACAddress[0], dupMACAddress[1], dupMACAddress[2], dupMACAddress[3], dupMACAddress[4], dupMACAddress[5]); printf(ethaddr %02X:%02X:%02X:%02X:%02X:%02X\n,gd-bd-bi_enetaddr[0], gd-bd-bi_enetaddr[1], gd-bd-bi_enetaddr[2], gd-bd-bi_enetaddr[3], gd-bd-bi_enetaddr[4], gd-bd-bi_enetaddr[5]); and I got this: Before 00:04:A6:00:6A:E6 After 36:00:A6:00:6A:E6 ethaddr 00:04:A6:00:6A:E6 Alse env_ethaddr has the correct correct. Looks like you're overflowing a buffer -- 0x36 0x00 are the last two bytes of the sprintf output. Where are env_ethaddr and dupMACaddress defined? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] fat.c:707: warning: array subscript is above array bounds
Dear David Hawkins, In message 49443c7f.3020...@ovro.caltech.edu you wrote: In message 2008121325.gn15...@game.jcrosoft.org you wrote: 705 /* Terminate fs_type string. Writing past the end of vistart 706is ok - it's just the buffer. */ 707 vistart-fs_type[8] = '\0'; ... How about something in the same vein then char *c = vistart-fstype; c[8] = '\0'; Thanks - this is what I actually did. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de ...though his invention worked superbly -- his theory was a crock of sewage from beginning to end. - Vernor Vinge, The Peace War ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers/net/e1000.c: missing terminator for supported devices
Dear Stefan Althoefer,
In message gije76$19...@ger.gmane.org you wrote:
Signed-off-by: Stefan Althoefer stefan.althoe...@web.de
---
Fu. copy and paste. This is the tab correct patch.
drivers/net/e1000.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index 2dcaa2c..a52749d 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -82,6 +82,7 @@ static struct pci_device_id supported[] = {
{PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82540EM_LOM},
{PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82541ER},
{PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82541GI_LF},
+ {}
};
/* Function forward declarations */
Applied, thanks.
Ben, this looked simple and obvious to me so I applied it directly.
Hope that's OK with you.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Morality is one thing. Ratings are everything.
- A Network 23 executive on Max Headroom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] SATA: do not auto-initialize during boot
Dear Mike Frysinger, In message 1230009039-20117-1-git-send-email-vap...@gentoo.org you wrote: Rather than have the board code initialize SATA automatically during boot, make the user manually run sata init. This brings the SATA subsystem in line with common U-Boot policy. Rather than having a dedicated weak function is_sata_supported, people can override sata_initialize() to do their weird board stuff. Then they can call the actual __sata_initialize(). Signed-off-by: Mike Frysinger vap...@gentoo.org --- v3 - redo how the board weak is handled to be less bloated when screwing over everyone else v2 - auto run `sata init` if needed when doing other `sata ...` cmds board/freescale/mpc8536ds/mpc8536ds.c |6 +++--- common/cmd_sata.c | 12 +++- include/sata.h|1 + lib_ppc/board.c | 20 4 files changed, 15 insertions(+), 24 deletions(-) Sorry, this doesn;t apply any more: error: patch failed: board/freescale/mpc8536ds/mpc8536ds.c:582 error: board/freescale/mpc8536ds/mpc8536ds.c: patch does not apply Using index info to reconstruct a base tree... error: patch failed: board/freescale/mpc8536ds/mpc8536ds.c:582 error: board/freescale/mpc8536ds/mpc8536ds.c: patch does not apply Did you hand edit your patch? It does not apply to blobs recorded in its index. Cannot fall back to three-way merge. Patch failed at 0001. Please rebase and resubmit. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A verbal contract isn't worth the paper it's printed on. - Samuel Goldwyn ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] nand sector size is zero in jffs2 cmds
Dear Derek Ou, In message 497dfe89.7020...@siconix.com you wrote: The following patch was tested some time ago. I am in the middle of another task and can not verify this patch with the latest code. Should I just reformat my patch and submit it or should I wait till I can test it with the latest code? I think the fix is obvious, so feel free to repost after adding your signed-off-by line and fixing yourmailer not to cwrap long lines. I recommend you use git-send-email to submit the patch. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Business is like a wheelbarrow. Nothing ever happens until you start pushing. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers/net/e1000.c: missing terminator for supported devices
Wolfgang Denk wrote:
Dear Stefan Althoefer,
In message gije76$19...@ger.gmane.org you wrote:
Signed-off-by: Stefan Althoefer stefan.althoe...@web.de
---
Fu. copy and paste. This is the tab correct patch.
drivers/net/e1000.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index 2dcaa2c..a52749d 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -82,6 +82,7 @@ static struct pci_device_id supported[] = {
{PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82540EM_LOM},
{PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82541ER},
{PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82541GI_LF},
+{}
};
/* Function forward declarations */
Applied, thanks.
Ben, this looked simple and obvious to me so I applied it directly.
Hope that's OK with you.
No problem. I'm a bit behind and hope to get caught up in the next day
or too, so this helps.
Best regards,
Wolfgang Denk
regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Minor bug found in board/zylonite/lowlevel_init.S. 0x300 changed to 300.
Dear Tom, In message 4959a41f.50...@ceos.com.au you wrote: | commit 9d803d8c0b7fd9aeb2e708e9e48dd76d7287856d | Author: Markus Klotzb^(n)cher Markus Klotzb^(n)m...@pollux.(none) | Date: Wed Feb 8 18:56:28 2006 +0100 | | Changes: | | * lots of bugfixes in the assembler code | * reverted hardware.h back to original | * enabled hardware DRAM calibration | * GCC-4 fix: modified GLOBAL_DATA_POINTER macro | $ git diff | af646e865f4bc67623ca957dfe3d3e4a95ff0468.. | 9d803d8c0b7fd9aeb2e708e9e48dd76d7287856d | board/zylonite/lowlevel_init.S | ... | + /* mk: replaced with wait macro */ | +/* ldr r3, =OSCR /\* reset the OS Timer Count to zero *\/ */ | +/* mov r2, #0 */ | +/* str r2, [r3] */ | +/* ldr r4, =0x300/\* really 0x2E1 is about 200usec, *\/ */ | +/* /\* so 0x300 should be plenty*\/ */ | +/* 1: */ | +/* ldr r2, [r3] */ | +/* cmp r4, r2 */ | +/* bgt 1b */ | + wait #300 Note that the linear code has been replaced with a macro. The comments above the code above state: /* Step 1: Wait for at least 200 microsedonds to allow internal */ /* clocks to settle. Only necessary after hard reset... */ The bug is that =0x300 has been changed to #300, and the latter is interpreted by the assembler as a decimal number. So the code is only waiting for 92us instead of 200 (13MHz clock divided by 4, divided by 300). I don't know if this causes any problems. The code doesn't match the comments, and it probably isn't following the manufacturer's specification for this timing either. Anyone else based of the Zylonite port might like to check their code. I fixed this for the delta and zylonite boards now. Thanks for pointing out. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There are three principal ways to lose money: wine, women, and engi- neers. While the first two are more pleasant, the third is by far the more certain. - Baron Rothschild, ca. 1800 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] soft_i2c.c add option for repeated start in i2c_read()
Dear Andrew Dyer, In message 49595ee1.8040...@righthandtech.com you wrote: This patch adds a #define to optionally change the behaviour of i2c_read() in soft_i2c.c to send an I2C repeated start instead of a stop-start between sending the device address pointer write and reading back the data. The current behaviour is retained as the default. While most devices will work either way, I have a smart battery(*) that requires repeated start, and someone at some point found a device that required a stop-start. (*) http://www.inspired-energy.com/Standard_Products/NL2054/NL2054%20Rev1.0%20Data%20Sheet.pdf Signed-off-by: Andrew Dyer ad...@righthandtech.com --- README |9 + drivers/i2c/soft_i2c.c | 12 +++- 2 files changed, 20 insertions(+), 1 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A wise person makes his own decisions, a weak one obeys public opinion. -- Chinese proverb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add AMD 29LV160DB FLASH support to SBC2410 board.
Dear Daniel Schuler, In message 7909dbcf0812292347x63b36946r7b7feb90dcbb5...@mail.gmail.com you wrote: The new SBC-2410A board from Embest now ships with 2MB NOR FLASH, for which CONFIG_AMD_LV160 has been defined in include/configs/sbc2410x.h This chip is already supported in other architectures, so AMD_ID_LV160B has been used as-is in board/sbc2410x/flash.c Signed-off-by: Daniel Schuler dbschu...@gmail.com --- board/sbc2410x/flash.c |6 ++ include/configs/sbc2410x.h | 21 ++--- 2 files changed, 20 insertions(+), 7 deletions(-) Your patch has been corrupted by your mailer which wrapped long lines. But I also think that's the wrong approach. Instead of spending (or more precisely wasting) efforts on that old custom flash driver you should change the code to use the generic CFI driver instead. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Save yourself! Reboot in 5 seconds! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] saveenv: standardize enablement
Dear Mike Frysinger, In message 1230623965-16546-1-git-send-email-vap...@gentoo.org you wrote: Rather than special casing each environment type for enabling the saveenv command, have them all behave the same. This avoids bitrot as new env sources are added/removed. Signed-off-by: Mike Frysinger vap...@gentoo.org --- common/cmd_nvedit.c | 26 -- 1 files changed, 8 insertions(+), 18 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Our way is peace. -- Septimus, the Son Worshiper, Bread and Circuses, stardate 4040.7. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH/RFC, 0/2] I2C rework -- what do you think?
On Tue, 27 Jan 2009, Heiko Schocher wrote: Hello ksi, k...@koi8.net wrote: Hi everyone, Here is the first draft of major I2C subsystem rework. This is not a patch that should be applied to the tree--it will break systems with I2C busses over multiplexers and probably something else--but rather a Request For Comments. I would like to here all the objections, suggestions etc. before I go on and undertake a big job to change all the boards and other stuff to the new code. It is a big job and I don't want to spend a lot of time doing something that nobody would accept. Yes, this would be a big job, and how do you want to test this for ~200 boards? It's physically impossible -- I simply don't have all those board even if I had time to do it. However we have people with those boards who can test their parts. I can test if it compiles for all boards. It is not black magic, just logical code and if it worked for several boards I can't see why it wouldn't work for majority of others. Those few that required some kind of magical touch and got broken we'll fix. My goal is to somehow untie I2C subsystem from platform-specific parts. This Isn t this so? is not an attempt for a code cleanup though some cleanup could be achieved in process. But this is not a goal, it is just a probable side effect. Primary goal is to allow multiple I2C busses on a board served by different I2C controllers (on-SoC, external, bit-banging.) As of now we have rudimentary support for multiple BUILT-IN adapters in some SoCs (e.g. fsl_i2c.c) but this support is platform specific and does NOT allow any additional (external etc.) adapters. Ah... okay, this lacks in the actual u-boot i2c layer. I see here to ways: a) Rewriting the complete code. This is really a big change (maybe, I am not a I2C expert, the cleaner way, but this will need a long time and a good test period ...) Eh, it ain't rocket science... Yes, it would require some time but nothing special... b) It should be possible to extend the i2c hardware specific functions, to allow more then one i2c platform adapter. Switching between those should possible with the i2c dev command (Which I think is the reason for this command) also i2c bus should be extend to choose, which real I2C Bus it uses. Something like this comes in my mind: i2c bus devid=[muxtype:muxaddr:muxchannel] with devid (an existing device id see i2c dev command) if devid= is missing, old behaviour (backward compatible) It makes no sence to me. Having just several busses--some direct, some via muxes--looks more natural, IMHO. If one wanted to check the exact path to that bus he could use i2c bus bus_no command. Other than that I can't see any reason for such information. And remember, all those i2c xyz commands are just interactive commands that are usually used for debugging purposes or during board bringup process. The internal interface is more important and it is much easier an logical to just do i2c_set_bus(N) and then use regular i2c_read/i2_write or whatever is required. That makes the entire code uniform, without special treatment for muxed busses etc. Kinda like Unix where everything's a file :) This is not a problem for a vast majority of supported boards that usually have a single I2C bus but there are cases when boards have several busses served by different I2C adapters. I personally have the first prototype of [...] Here is a little manifest... First of all, there is a basic entity, I2C bus. It can be a simple I2C bus from the only I2C adapter on a SoC, several busses from several adapters, both on-SoC and external, and several busses growing off of several adapters via I2C multiplexers/switches (e.g. PCA9544 etc.) They are all the same for the rest of code accessed with single set of i2c_read()/i2c_write() and friends for all busses no matter what adapter they are on and if they are directly connected to an adapter or reached through a set of I2C mux chips. Any I2C operation is performed on the CURRENT bus. Current bus is set with i2c_set_bus_num(). In case of directly connected busses it merely changes a global variable that is used as an index into an array. If some busses are connected via I2C muxes, it disconnects the previously connected muxes if any and sets all chips along the path to the new bus so next access will go to that bus. All those paths are statically allocated at compile time according to Why must be this statically defined? Think of a Hardwaremanufacturer who has several boardvariants. In your case, he must have for every board a config file - different binaries. In the case using i2c bus he has one binary which is able to work with all of his variants! And he can connect on a running system on an actual not used I2C Bus, another mux for example, and can configure this new bus per commandline without
[U-Boot] [PATCH] NAND jffs2 bug fix - sector size not initialized
NAND jffs2 bug fix - sector size not initialized. Signed-off-by: Derek Ou d...@siconix.com --- common/cmd_jffs2.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/common/cmd_jffs2.c b/common/cmd_jffs2.c index 7866c80..f6966f3 100644 --- a/common/cmd_jffs2.c +++ b/common/cmd_jffs2.c @@ -1853,6 +1853,8 @@ int mtdparts_init(void) if (part-size == SIZE_REMAINING) part-size = id-size - part-offset; + part-sector_size = nand_info[id-num].erasesize; + DEBUGF(part : name = %s, size = 0x%08lx, offset = 0x%08lx\n, part-name, part-size, part-offset); -- 1.5.4.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mpc83xx: fix undefined reference to `flush_cache' error in simpc8313 build
extend commit c70564e6b1bd08f3230182392238907f3531a87e NAND: Fix cache and memory inconsistency issue to add the cache.o dependency to the simpc8313 build and fix this: ...Large Page NAND...Configuring for SIMPC8313 board... nand_boot_fsl_elbc.o: In function `nand_boot': nand_spl/board/sheldon/simpc8313/nand_boot_fsl_elbc.c:150: undefined reference to `flush_cache' make[1]: *** [/home/r1aaha/git/u-boot-mpc83xx/nand_spl/u-boot-spl] Error 1 make: *** [nand_spl] Error 2 Signed-off-by: Kim Phillips kim.phill...@freescale.com --- Ron, if you ack/confirm this doesn't break your board, I'll apply this to u-boot-mpc83xx. Thanks, Kim nand_spl/board/sheldon/simpc8313/Makefile |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/nand_spl/board/sheldon/simpc8313/Makefile b/nand_spl/board/sheldon/simpc8313/Makefile index b0967a3..416e176 100644 --- a/nand_spl/board/sheldon/simpc8313/Makefile +++ b/nand_spl/board/sheldon/simpc8313/Makefile @@ -34,7 +34,8 @@ AFLAGS+= -DCONFIG_NAND_SPL CFLAGS += -DCONFIG_NAND_SPL SOBJS = start.o ticks.o -COBJS = nand_boot_fsl_elbc.o $(BOARD).o sdram.o ns16550.o nand_init.o time.o +COBJS = nand_boot_fsl_elbc.o $(BOARD).o sdram.o ns16550.o nand_init.o \ + time.o cache.o SRCS := $(addprefix $(obj),$(SOBJS:.o=.S) $(COBJS:.o=.c)) OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS)) @@ -78,6 +79,9 @@ $(obj)ns16550.c: $(obj)nand_init.c: ln -sf $(SRCTREE)/cpu/mpc83xx/nand_init.c $ +$(obj)cache.c: + ln -sf $(SRCTREE)/lib_ppc/cache.c $ + $(obj)time.c: ln -sf $(SRCTREE)/lib_ppc/time.c $ -- 1.6.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Move is_valid_ether_addr() to include/net.h
Import the is_valid_ether_addr() function from the Linux kernel.
Signed-off-by: Mike Frysinger vap...@gentoo.org
CC: Ben Warren biggerbadder...@gmail.com
---
board/bf537-stamp/bf537-stamp.c | 16
include/net.h | 16
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/board/bf537-stamp/bf537-stamp.c b/board/bf537-stamp/bf537-stamp.c
index 7303f1b..cec2b26 100644
--- a/board/bf537-stamp/bf537-stamp.c
+++ b/board/bf537-stamp/bf537-stamp.c
@@ -34,22 +34,6 @@
#include asm/mach-common/bits/bootrom.h
#include netdev.h
-/**
- * is_valid_ether_addr - Determine if the given Ethernet address is valid
- * @addr: Pointer to a six-byte array containing the Ethernet address
- *
- * Check that the Ethernet address (MAC) is not 00:00:00:00:00:00, is not
- * a multicast address, and is not FF:FF:FF:FF:FF:FF.
- *
- * Return true if the address is valid.
- */
-static inline int is_valid_ether_addr(const u8 * addr)
-{
- /* FF:FF:FF:FF:FF:FF is a multicast address so we don't need to
-* explicitly check for it here. */
- return !is_multicast_ether_addr(addr) !is_zero_ether_addr(addr);
-}
-
DECLARE_GLOBAL_DATA_PTR;
#define POST_WORD_ADDR 0xFF903FFC
diff --git a/include/net.h b/include/net.h
index d2d394f..bbe0d4b 100644
--- a/include/net.h
+++ b/include/net.h
@@ -474,6 +474,22 @@ static inline int is_multicast_ether_addr(const u8 *addr)
return (0x01 addr[0]);
}
+/**
+ * is_valid_ether_addr - Determine if the given Ethernet address is valid
+ * @addr: Pointer to a six-byte array containing the Ethernet address
+ *
+ * Check that the Ethernet address (MAC) is not 00:00:00:00:00:00, is not
+ * a multicast address, and is not FF:FF:FF:FF:FF:FF.
+ *
+ * Return true if the address is valid.
+ */
+static inline int is_valid_ether_addr(const u8 * addr)
+{
+ /* FF:FF:FF:FF:FF:FF is a multicast address so we don't need to
+* explicitly check for it here. */
+ return !is_multicast_ether_addr(addr) !is_zero_ether_addr(addr);
+}
+
/* Convert an IP address to a string */
extern voidip_to_string (IPaddr_t x, char *s);
--
1.6.1.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] jffs2: Fix zero sector_size when not using CONFIG_JFFS2_CMDLINE
Dear Tomasz Figa, In message 200812301835.57435.tomasz.f...@gmail.com you wrote: This patch fixes a bug (?) introduced after inclusion of the new JFFS2 code. When not using CONFIG_JFFS2_CMDLINE, the code in cmd_jffs2.c doesn't fill in part-sector_size (keeping it as 0), but a correct value is needed by the code in jffs2_1pass.c. This causes all JFFS2 accesses to be in the same place of the memory, what obviously means impossibility to use the JFFS2 partition. This problem is fixed in this patch by including sector size calculation in non-CONFIG_JFFS2_CMDLINE mtdparts_init variant. Signed-off-by: Tomasz Figa tomasz.figa_at_gmail.com Applied, thanks, but please be a bit more careful next time; this patch had a lot of trailing whitespace issues, and some wrapped long lines. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de To program is to be. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] nand potential div0
Dear Ryan J M,
In message dcf6addc0812301719m4af2fcd3teeca516e62681...@mail.gmail.com you
wrote:
I thought it would be better to check whether chip-ecc.size equal 0
here, I forgot to set ecc.size in board_nand_init() and it trigs a
div0 hang.
driver/mtd/nand/nand_base.c
2786 /*
2787 * Set the number of read / write steps for one page
depending on ECC
2788 * mode
2789 */
2790 chip-ecc.steps = mtd-writesize / chip-ecc.size;
2791 if(chip-ecc.steps * chip-ecc.size != mtd-writesize) {
2792 printk(KERN_WARNING Invalid ecc parameters\n);
2793 BUG();
2794 }
2795 chip-ecc.total = chip-ecc.steps * chip-ecc.bytes;
2796
Please submit a proper patch - see
http://www.denx.de/wiki/U-Boot/Patches for instructions.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Q: Do you know what the death rate around here is?
A: One per person.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] Command usage cleanup
Dear Peter Tyser, In message 1230746884-6510-1-git-send-email-pty...@xes-inc.com you wrote: This patch series attempts to clean up how the usage field of the cmd_tbl_s structure is used. It does 3 things: 1. Adds a cmd_usage() function to print a command's usage 2. Removes the command name from the usage field for all commands 3. Removes newlines from the usage field of all commands The benefits of these changes are: 1. Command formatting in the help command output will always be properly aligned. A fair number of commands currently aren't properly formated, eg cmd1 - description vs cmd2- description. 2. Command definitions are reduced in size/complexity. The patch shaved off 1.1KB from the XPedite5370 image for example. Most of the changes were done via scripts, so let me know if anything looks fishy. Dear Peter, unfortunately this patch series does not apply any more. Patch # 3 (Standardize command usage messages with cmd_usage()) bails out: Applying: Standardize command usage messages with cmd_usage() error: patch failed: common/cmd_nand.c:464 error: common/cmd_nand.c: patch does not apply error: patch failed: common/cmd_onenand.c:28 error: common/cmd_onenand.c: patch does not apply Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... Auto-merged common/cmd_bootm.c Auto-merged common/cmd_jffs2.c Auto-merged common/cmd_mem.c Auto-merged common/cmd_nand.c Auto-merged common/cmd_nvedit.c Auto-merged common/cmd_onenand.c CONFLICT (content): Merge conflict in common/cmd_onenand.c Auto-merged common/main.c Failed to merge in the changes. Patch failed at 0003. Can you please rebase these patches and resubmit? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de All a hacker needs is a tight PUSHJ, a loose pair of UUOs, and a warm place to shift. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [REBASED] part_efi: Fix partition size calculation due to inclusive ending LBA.
Dear Richard Retanubun, In message 497dbe6a.5090...@ruggedcom.com you wrote: The ending LBA is inclusive. Hence, the partition size should be ((ending-LBA + 1) - starting-LBA) to get the proper partition size. This is confirmed against the results from the parted tool. (e.g. use parted /dev/sda -s unit S print) and observe the size. Signed-off-by: Richard Retanubun richardretanu...@ruggedcom.com --- Hi Wolfgang, Here is the patch rebased against commit 8f86a3636ef88427f880610638e80991adc41896 Thanks for the help -Richard disk/part_efi.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) Applied, thanks, but... diff --git a/disk/part_efi.c b/disk/part_efi.c index cc188ee..d8a8111 100644 --- a/disk/part_efi.c +++ b/disk/part_efi.c @@ -163,7 +163,9 @@ int get_partition_info_efi(block_dev_desc_t * dev_desc, int part, ^^ Line wrapped. Please fix your mailer! Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Democracy is mob rule, but with income taxes. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 02/07 V2] Coldfire: cmd_bdinfo cleanup
CONFIG_M68K bdinfo cleanup: Fixed compiler warning about baudrate printing. format '%d' expects type 'int', but argument 2 has type 'long unsigned int'. Added printing of cpufreq Signed-off-by: Richard Retanubun richardretanu...@ruggedcom.com --- V2: Same a V1, but fixed the line wrapped @@ lines in previous submissions. common/cmd_bdinfo.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/common/cmd_bdinfo.c b/common/cmd_bdinfo.c index 6675241..d12a9b1 100644 --- a/common/cmd_bdinfo.c +++ b/common/cmd_bdinfo.c @@ -283,6 +283,7 @@ int do_bdinfo ( cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) #if defined(CONFIG_SYS_MBAR) print_num (mbar, bd-bi_mbar_base); #endif + print_str (cpufreq, strmhz(buf, bd-bi_intfreq)); print_str (busfreq, strmhz(buf, bd-bi_busfreq)); #ifdef CONFIG_PCI print_str (pcifreq, strmhz(buf, bd-bi_pcifreq)); @@ -322,7 +323,7 @@ int do_bdinfo ( cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) puts (\nip_addr = ); print_IPaddr (bd-bi_ip_addr); #endif - printf (\nbaudrate= %d bps\n, bd-bi_baudrate); + printf (\nbaudrate= %ld bps\n, bd-bi_baudrate); return 0; } -- 1.5.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mflash u-boot support
Dear Kim,
In message 57afda040901052341g3b00f741r445c0ce8d33b7...@mail.gmail.com you
wrote:
I wrote mflash IO mode block device driver for U-Boot.
Thanks for your contribution. Here a few comments:
diff --git a/common/Makefile b/common/Makefile
index 93e3963..f93e575 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -57,6 +57,7 @@ COBJS-$(CONFIG_ENV_IS_IN_NAND) += env_nand.o
COBJS-$(CONFIG_ENV_IS_IN_NVRAM) += env_nvram.o
COBJS-$(CONFIG_ENV_IS_IN_ONENAND) += env_onenand.o
COBJS-$(CONFIG_ENV_IS_IN_SPI_FLASH) += env_sf.o
+COBJS-$(CONFIG_ENV_IS_IN_MG_DISK) += env_mgdisk.o
COBJS-$(CONFIG_ENV_IS_NOWHERE) += env_nowhere.o
# command
@@ -138,6 +139,7 @@ endif
COBJS-$(CONFIG_CMD_XIMG) += cmd_ximg.o
COBJS-$(CONFIG_YAFFS2) += cmd_yaffs2.o
COBJS-$(CONFIG_VFD) += cmd_vfd.o
+COBJS-$(CONFIG_CMD_MG_DISK) += cmd_mgdisk.o
Please keep such lists sorted.
...
+U_BOOT_CMD(
+ mgd,5, 0, do_mg_disk_cmd,
+ mgd - mgine m[g]flash command\n,
+ : mgine mflash IO mode (disk) command\n
+ \t- initialize : mgd init\n
+ \t- random read : mgd read [from] [to] [size]\n
+ \t\tbelow example read 256 bytes from 0x30 of mflash\n
+ \t\tto 0xA010 of host memory\n
+ \t\tex) mgd read 0x30 0xA010 256\n
+ \t- random write : mgd write [from] [to] [size]\n
+ \t\tex) mgd write 0xA010 0x30 256\n
+ \t- sector read : mgd readsec [sector] [to] [counts]\n
+ \t\tbelow example read 10 sectors starts from 400 sector\n
+ \t\tto 0xA010\n
+ \t\tex) mgd readsec 400 0xA010 10\n
+ \t- sector write : mgd writesec [from] [sector] [counts]\n
+);
Please avoid using TAB characters here.
Also,pleas ebe terse - don;t give examples here. Rather add a
README.mflash file to the doc/ directory.
diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index 85025da..4945aeb 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -59,8 +59,9 @@ DECLARE_GLOBAL_DATA_PTR;
!defined(CONFIG_ENV_IS_IN_NAND) \
!defined(CONFIG_ENV_IS_IN_ONENAND)\
!defined(CONFIG_ENV_IS_IN_SPI_FLASH) \
+!defined(CONFIG_ENV_IS_IN_MG_DISK)\
!defined(CONFIG_ENV_IS_NOWHERE)
Please keep lists sorted.
-# error Define one of
CONFIG_ENV_IS_IN_{NVRAM|EEPROM|FLASH|DATAFLASH|ONENAND|SPI_FLASH|NOWHERE}
+# error Define one of
CONFIG_ENV_IS_IN_{NVRAM|EEPROM|FLASH|DATAFLASH|ONENAND|SPI_FLASH|MG_DISK|NOWHERE}
Please keep lists sorted.
Also note that your mailer wrapped long lines here, thus corrupting
the patch. Please fix your mailer.
And please avoid such long lines, too!
...
+void env_relocate_spec(void)
+{
+ unsigned int err;
+ err = mg_disk_read(CONFIG_ENV_ADDR, (u_char *) env_ptr,
CONFIG_ENV_SIZE);
+ if (err) {
+ puts (*** Warning - mg_disk_read error, using default
environment\n\n);
Line too long.
+ set_default_env();
+ return;
+ }
+
+ if (crc32(0, env_ptr-data, ENV_SIZE) != env_ptr-crc) {
+ puts (*** Warning - CRC error, using default environment\n\n);
+ set_default_env();
+ }
+}
+
+int saveenv(void)
+{
+ unsigned int err;
+ env_ptr-crc = crc32(0, env_ptr-data, ENV_SIZE);
+ err = mg_disk_write(CONFIG_ENV_ADDR, (u_char *) env_ptr,
CONFIG_ENV_SIZE);
Line too long.
+ if (err)
+ puts (*** Warning - mg_disk_write error\n\n);
+ return (int)err;
The cast should not be needed here.
diff --git a/disk/part.c b/disk/part.c
index e353cee..c007060 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -39,7 +39,8 @@
defined(CONFIG_CMD_SCSI) || \
defined(CONFIG_CMD_USB) || \
defined(CONFIG_MMC) || \
- defined(CONFIG_SYSTEMACE) )
+ defined(CONFIG_SYSTEMACE) || \
+ defined(CONFIG_CMD_MG_DISK))
Please keep lists sorted.
@@ -95,7 +99,8 @@ block_dev_desc_t *get_dev(char* ifname, int dev)
defined(CONFIG_CMD_SCSI) || \
defined(CONFIG_CMD_USB) || \
defined(CONFIG_MMC) || \
- defined(CONFIG_SYSTEMACE) )
+ defined(CONFIG_SYSTEMACE) || \
+ defined(CONFIG_CMD_MG_DISK))
Ditto.
@@ -207,7 +212,8 @@ void dev_print (block_dev_desc_t *dev_desc)
defined(CONFIG_CMD_SCSI) || \
defined(CONFIG_CMD_USB) || \
defined(CONFIG_MMC) || \
- defined(CONFIG_SYSTEMACE) )
+ defined(CONFIG_SYSTEMACE) || \
+ defined(CONFIG_CMD_MG_DISK))
Ditto.
diff --git a/disk/part_amiga.c b/disk/part_amiga.c
index 6c3d748..b4c2820 100644
--- a/disk/part_amiga.c
+++ b/disk/part_amiga.c
@@ -30,7 +30,8 @@
defined(CONFIG_CMD_SCSI) || \
defined(CONFIG_CMD_USB) || \
defined(CONFIG_MMC) || \
- defined(CONFIG_SYSTEMACE) ) defined(CONFIG_AMIGA_PARTITION)
+ defined(CONFIG_SYSTEMACE) || \
+ defined(CONFIG_CMD_MG_DISK)) defined(CONFIG_AMIGA_PARTITION)
Ditto.
@@ -40,6 +41,8 @@
#define PRINTF(fmt, args...)
#endif
+#define
Re: [U-Boot] [PATCH v4] SATA: do not auto-initialize during boot
Dear Mike Frysinger, In message 1233090741-3150-1-git-send-email-vap...@gentoo.org you wrote: Rather than have the board code initialize SATA automatically during boot, make the user manually run sata init. This brings the SATA subsystem in line with common U-Boot policy. Rather than having a dedicated weak function is_sata_supported, people can override sata_initialize() to do their weird board stuff. Then they can call the actual __sata_initialize(). Signed-off-by: Mike Frysinger vap...@gentoo.org --- v4 - rebase against latest master v3 - redo how the board weak is handled to be less bloated when screwing over everyone else v2 - auto run `sata init` if needed when doing other `sata ...` board/freescale/mpc8536ds/mpc8536ds.c |6 +++--- common/cmd_sata.c | 12 +++- include/sata.h|1 + lib_ppc/board.c | 20 4 files changed, 15 insertions(+), 24 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. -- Albert Einstein ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] NAND jffs2 bug fix - sector size not initialized
Dear Derek, In message 541d21dc51a2ad9d7eb18755215f5605.squir...@webmail.siconix.com you wrote: NAND jffs2 bug fix - sector size not initialized. Signed-off-by: Derek Ou d...@siconix.com --- common/cmd_jffs2.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/common/cmd_jffs2.c b/common/cmd_jffs2.c index 7866c80..f6966f3 100644 --- a/common/cmd_jffs2.c +++ b/common/cmd_jffs2.c @@ -1853,6 +1853,8 @@ int mtdparts_init(void) if (part-size == SIZE_REMAINING) part-size = id-size - part-offset; + part-sector_size = nand_info[id-num].erasesize; + DEBUGF(part : name = %s, size = 0x%08lx, offset = 0x%08lx\n, part-name, part-size, part-offset); I think this has been fixed in the meantime. Please see commit b5b004ad8a0ac6f98bd5708ec8b22fbddd1c1042 Author: Tomasz Figa tomasz.f...@gmail.com Date: Tue Dec 30 18:35:57 2008 +0100 jffs2: Fix zero sector_size when not using CONFIG_JFFS2_CMDLINE Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Monday is an awful way to spend one seventh of your life. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5 v2] Clean up diufb command definitions
The diufb command usage formatting is non-standard. It was made standard in preparation for larger command usage updates. Signed-off-by: Peter Tyser pty...@xes-inc.com --- board/ads5121/ads5121_diu.c |2 +- board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/board/ads5121/ads5121_diu.c b/board/ads5121/ads5121_diu.c index 11450aa..896900b 100644 --- a/board/ads5121/ads5121_diu.c +++ b/board/ads5121/ads5121_diu.c @@ -101,7 +101,7 @@ int ads5121diu_init_show_bmp(cmd_tbl_t *cmdtp, U_BOOT_CMD( diufb, CONFIG_SYS_MAXARGS, 1, ads5121diu_init_show_bmp, - diufb init | addr - Init or Display BMP file\n, + diufb - Init or Display BMP file\n, init\n- initialize DIU\n addr\n- display bmp at address 'addr'\n ); diff --git a/board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c b/board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c index cd25d4a..08eaf10 100644 --- a/board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c +++ b/board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c @@ -138,7 +138,7 @@ int mpc8610diu_init_show_bmp(cmd_tbl_t *cmdtp, U_BOOT_CMD( diufb, CONFIG_SYS_MAXARGS, 1, mpc8610diu_init_show_bmp, - diufb init | addr - Init or Display BMP file\n, + diufb - Init or Display BMP file\n, init\n- initialize DIU\n addr\n- display bmp at address 'addr'\n ); -- 1.6.0.2.GIT ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/5 v2] Command usage cleanup
Changes since v1: - Rebase on top of tree This patch series attempts to clean up how the usage field of the cmd_tbl_s structure is used. It does 3 things: 1. Adds a cmd_usage() function to print a command's usage 2. Removes the command name from the usage field for all commands 3. Removes newlines from the usage field of all commands The benefits of these changes are: 1. Command formatting in the help command output will always be properly aligned. A fair number of commands currently aren't properly formated, eg cmd1 - description vs cmd2- description. 2. Command definitions are reduced in size/complexity. The patch shaved off 1.1KB from the XPedite5370 image for example. Most of the changes were done via scripts, so let me know if anything looks fishy. Best, Peter Peter Tyser (5): Clean up diufb command definitions pcs440ep: Clean up led command definition Standardize command usage messages with new cmd_usage() function amcc: Clean up command usage output Command usage cleanup README|3 + board/BuS/EB+MCF-EV123/EB+MCF-EV123.c |4 +- board/MAI/AmigaOneG3SE/cmd_boota.c|2 +- board/MAI/menu/cmd_menu.c |2 +- board/ads5121/ads5121_diu.c |4 +- board/amcc/acadia/cmd_acadia.c|4 +- board/amcc/canyonlands/bootstrap.c|4 +- board/amcc/katmai/cmd_katmai.c|4 +- board/amcc/kilauea/cmd_pll.c |8 ++-- board/amcc/luan/luan.c|4 +- board/amcc/makalu/cmd_pll.c |8 ++-- board/amcc/sequoia/cmd_sequoia.c |4 +- board/amcc/taihu/lcd.c| 14 +++--- board/amcc/taihu/taihu.c | 10 ++-- board/amcc/taihu/update.c |2 +- board/amcc/taishan/lcd.c | 20 +- board/amcc/taishan/showinfo.c |6 +- board/amcc/taishan/update.c |2 +- board/amcc/yucca/cmd_yucca.c |4 +- board/amirix/ap1000/ap1000.c | 10 ++-- board/amirix/ap1000/powerspan.c |2 +- board/barco/barco.c |8 ++-- board/bc3450/cmd_bc3450.c | 10 ++-- board/bf537-stamp/cmd_bf537led.c |2 +- board/cm5200/cmd_cm5200.c |2 +- board/delta/delta.c |2 +- board/esd/ar405/ar405.c |6 +- board/esd/cms700/cms700.c |2 +- board/esd/common/auto_update.c|2 +- board/esd/common/cmd_loadpci.c|2 +- board/esd/common/lcd.c|4 +- board/esd/common/xilinx_jtag/micro.c |2 +- board/esd/cpci2dp/cpci2dp.c |2 +- board/esd/cpci405/cpci405.c |6 +- board/esd/cpci5200/cpci5200.c |2 +- board/esd/cpci750/cpci750.c |2 +- board/esd/dasa_sim/cmd_dasa_sim.c |4 +- board/esd/du440/du440.c | 16 board/esd/hh405/hh405.c |2 +- board/esd/ocrtc/cmd_ocrtc.c |4 +- board/esd/pci405/cmd_pci405.c |2 +- board/esd/pci405/pci405.c |2 +- board/esd/pf5200/pf5200.c |6 +- board/esd/plu405/plu405.c |2 +- board/esd/pmc405/pmc405.c |2 +- board/esd/pmc440/cmd_pmc440.c | 18 board/esd/tasreg/tasreg.c | 12 +++--- board/esd/voh405/voh405.c |2 +- board/evb64260/zuma_pbb.c |6 +- board/freescale/common/pixis.c|4 +- board/freescale/common/sys_eeprom.c |4 +- board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c |4 +- board/g2000/g2000.c |6 +- board/hymod/bsp.c |8 ++-- board/keymile/common/keymile_hdlc_enet.c |4 +- board/lwmon/lwmon.c | 10 ++-- board/lwmon5/kbd.c|2 +- board/lwmon5/lwmon5.c |6 +- board/mpl/common/common_util.c|2 +- board/mpl/mip405/cmd_mip405.c |2 +- board/mpl/pati/cmd_pati.c |2 +- board/mpl/pip405/cmd_pip405.c |2 +- board/mpl/vcma9/cmd_vcma9.c |2 +- board/pcippc2/pcippc2.c |4 +- board/pcs440ep/pcs440ep.c |6 +- board/pn62/cmd_pn62.c |8 ++-- board/prodrive/pdnb3/pdnb3.c |4 +- board/pxa255_idp/pxa_idp.c|2 +- board/r360mpi/r360mpi.c |
[U-Boot] [PATCH 2/5 v2] pcs440ep: Clean up led command definition
The pcs440ep's led command usage formatting is non-standard. It was made standard in preparation for larger command usage updates. Signed-off-by: Peter Tyser pty...@xes-inc.com --- board/pcs440ep/pcs440ep.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/board/pcs440ep/pcs440ep.c b/board/pcs440ep/pcs440ep.c index 271005f..73a7a08 100644 --- a/board/pcs440ep/pcs440ep.c +++ b/board/pcs440ep/pcs440ep.c @@ -761,7 +761,7 @@ int do_led (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) U_BOOT_CMD( led,2, 1, do_led, - led [bitmask] - set the DIAG-LED\n, + led- set the DIAG-LED\n, [bitmask] 0x01 = DIAG 1 on\n 0x02 = DIAG 2 on\n 0x04 = DIAG 3 on\n -- 1.6.0.2.GIT ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/5 v2] amcc: Clean up command usage output
Update taihu and taishan commands to use cmd_usage() function
to display usage messages.
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
board/amcc/taihu/lcd.c |6 +++---
board/amcc/taihu/taihu.c |6 +++---
board/amcc/taishan/lcd.c |6 +++---
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/board/amcc/taihu/lcd.c b/board/amcc/taihu/lcd.c
index 3d042df..7cc094a 100644
--- a/board/amcc/taihu/lcd.c
+++ b/board/amcc/taihu/lcd.c
@@ -140,7 +140,7 @@ static int do_lcd_clear (cmd_tbl_t * cmdtp, int flag, int
argc, char *argv[])
static int do_lcd_puts (cmd_tbl_t * cmdtp, int flag, int argc, char *argv[])
{
if (argc 2) {
- printf(%s, cmdtp-usage);
+ cmd_usage(cmdtp);
return 1;
}
lcd_puts(argv[1]);
@@ -151,7 +151,7 @@ static int do_lcd_puts (cmd_tbl_t * cmdtp, int flag, int
argc, char *argv[])
static int do_lcd_putc (cmd_tbl_t * cmdtp, int flag, int argc, char *argv[])
{
if (argc 2) {
- printf(%s, cmdtp-usage);
+ cmd_usage(cmdtp);
return 1;
}
lcd_putc((char)argv[1][0]);
@@ -166,7 +166,7 @@ static int do_lcd_cur (cmd_tbl_t * cmdtp, int flag, int
argc, char *argv[])
char cur_addr;
if (argc 3) {
- printf(%s, cmdtp-usage);
+ cmd_usage(cmdtp);
return 1;
}
diff --git a/board/amcc/taihu/taihu.c b/board/amcc/taihu/taihu.c
index 6e9330f..a98c186 100644
--- a/board/amcc/taihu/taihu.c
+++ b/board/amcc/taihu/taihu.c
@@ -102,13 +102,13 @@ static int do_led_ctl(cmd_tbl_t* cmd_tp, int flags, int
argc, char *argv[])
int led_no;
if (argc != 3) {
- printf(%s, cmd_tp-usage);
+ cmd_usage(cmd_tp);
return -1;
}
led_no = simple_strtoul(argv[1], NULL, 16);
if (led_no != 1 led_no != 2) {
- printf(%s, cmd_tp-usage);
+ cmd_usage(cmd_tp);
return -1;
}
@@ -123,7 +123,7 @@ static int do_led_ctl(cmd_tbl_t* cmd_tp, int flags, int
argc, char *argv[])
else
gpio_write_bit(31, 0);
} else {
- printf(%s, cmd_tp-usage);
+ cmd_usage(cmd_tp);
return -1;
}
diff --git a/board/amcc/taishan/lcd.c b/board/amcc/taishan/lcd.c
index 624ae40..4e14bbc 100644
--- a/board/amcc/taishan/lcd.c
+++ b/board/amcc/taishan/lcd.c
@@ -167,7 +167,7 @@ static int do_lcd_clear(cmd_tbl_t * cmdtp, int flag, int
argc, char *argv[])
static int do_lcd_puts(cmd_tbl_t * cmdtp, int flag, int argc, char *argv[])
{
if (argc 2) {
- printf(%s, cmdtp-usage);
+ cmd_usage(cmdtp);
return 1;
}
lcd_puts(argv[1]);
@@ -176,7 +176,7 @@ static int do_lcd_puts(cmd_tbl_t * cmdtp, int flag, int
argc, char *argv[])
static int do_lcd_putc(cmd_tbl_t * cmdtp, int flag, int argc, char *argv[])
{
if (argc 2) {
- printf(%s, cmdtp-usage);
+ cmd_usage(cmdtp);
return 1;
}
lcd_putc((char)argv[1][0]);
@@ -189,7 +189,7 @@ static int do_lcd_cur(cmd_tbl_t * cmdtp, int flag, int
argc, char *argv[])
char cur_addr;
if (argc 3) {
- printf(%s, cmdtp-usage);
+ cmd_usage(cmdtp);
return 1;
}
--
1.6.0.2.GIT
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] V2 NAND_SPL support for phycore imx31to Scott Wood
In message on Friday 12 December 2008 04:55:49 Scott Wood wrote:
On Fri, Dec 05, 2008 at 02:13:51PM +0300, Maxim Artamonov wrote:
+#ifdef CONFIG_NAND_SPL
+/* somewhat macro to reduce bin size for CONFIG_NAND_SPL*/
+.macro FILLREGS begreg, val, count, step
Why not use this macro always?
Why not? But, I think this 'll lose clearity of code. Let's discuss this.
@@ -32,6 +35,15 @@
#include version.h
.globl _start
_start: b reset
+#ifdef CONFIG_NAND_SPL
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+#else
#ifdef CONFIG_ONENAND_IPL
#elif
Do NAND and OneNAND really have different requirements here?
@@ -156,9 +169,9 @@ relocate: /* relocate
U-Boot to RAM */
adr r0, _start /* r0 - current position of code */
ldr r1, _TEXT_BASE /* test if we run from flash or RAM */
cmp r0, r1 /* don't reloc during debug */
-#ifndef CONFIG_ONENAND_IPL
+#if !defined(CONFIG_ONENAND_IPL) !defined(CONFIG_NAND_SPL)
Should define one symbol that is set if either of the above are set, to
simplify the ifdefs.
I don't work with OneNAND flash and reference to hang is deeply in source
tree, and we have only 2kB on
NAND in-place of 4kB on OneNand. Unhappily, I don't have anytime to learn
about OneNand and to change its code.
+#define NFC_BUF_SIZE(*((volatile u16 *)(NFC_BASE_ADDR +
0xE00)))
+#define NFC_BUF_ADDR(*((volatile u16 *)(NFC_BASE_ADDR +
0xE04)))
...
+#define NFC_CONFIG1 (*((volatile u16 *)(NFC_BASE_ADDR +
0xE1A)))
+#define NFC_CONFIG2 (*((volatile u16 *)(NFC_BASE_ADDR +
0xE1C)))
Use I/O accessors,
What you about, tell me please?
and move the NFC register layout to a
non-arch-specific header file (preferably as a struct), as it's shared
with other chips.
Which chips? This is a system's integration task, but I wrote only for imx-31
phycore. I don't
understand in this.
#defineCONFIG_EXTRA_ENV_SETTINGS
\
- bootargs_base=setenv bootargs console=ttySMX0,115200\0
\
- bootargs_nfs=setenv bootargs $(bootargs) root=/dev/nfs ip=dhcp
nfsroot=$(serverip):$(nfsrootfs),v3,tcp\0 \
- bootargs_flash=setenv bootargs $(bootargs) root=/dev/mtdblock2
rootfstype=jffs2 \
- bootargs_mtd=setenv bootargs $(bootargs) $(mtdparts)
\
+ jffs2=root-pcm037.jffs2\0
\
+ uimage=uImage-pcm037\0
\
+ nfsrootfs=/nfsroot\0
\
bootcmd=run bootcmd_net\0
\
+ mtdids=nor0=phys_mapped_flash\0
\
+ bootargs_base=setenv bootargs console=ttymxc0,115200\0
\
+ bootargs_nfs=setenv bootargs $(bootargs) root=/dev/nfs ip=dhcp
nfsroot=$(serverip):$(nfsrootfs),v3,tcp\0 \
+ bootargs_mtd=setenv bootargs $(bootargs) $(mtdparts)\0
\
+ bootargs_flash=setenv bootargs $(bootargs) root=/dev/mtdblock3
rootfstype=jffs2\0 \
There are changes in here that don't seem to be related to nand boot.
Yes, it's so. I'll change code.
+static void mx31_wait_ready(void)
+{
+ while (1)
+ if (NFC_CONFIG2 NFC_INT){
+ NFC_CONFIG2 = NFC_CONFIG2 (~NFC_INT);/*int
flag reset*/
+ break;
+ }
+}
There's an extra indentation level in the if-body.
Braces around the while-body. Space before and after braces (here and
elsewhere).
+static void mx31_nand_init(void)
+{
+ /*unlocking RAM Buff*/
+ NFC_CONFIG = 0x2;
+
+ /*hardware ECC checking and correct*/
+ NFC_CONFIG1 = NFC_ECC_EN;
Space after /*, before */
It will apply.
+ if (mx31_nand_check_ecc ())
+ while (1){
+ break;};/*!*/
What is this?
Ok, let's it be infinitive while-cycle.
+ p1 = (u32 *)MAIN_AREA0;
+ p2 = (u32 *)buf;
+
+ /*main copy loop from NAND-buffer to SDRAM memory*/
+ for (i=0; i (CFG_NAND_PAGE_SIZE / 4); i++){
+ *p2 = *p1;
+ p1++;
+ p2++;
+ }
+
+ p1 = (u32 *)SPARE_AREA0;
+
+ /*it is hardware specific code for 8-bit 512kB NAND-flash
[U-Boot] [PATCH]V3 NAND_SPL support for phycore imx31
V3 NAND_SPL support for phycore imx31 This patch is applied on U-Boot v2008.10 release. Changelog: * Added infinitive loop for ecc-error cases; * Correct to code-style; * Was changed mx31_nand_data_output function for support 2-k NAND page chips (Magnus Lilja proposal); * Was changed name of CFG_NAND_PAGE_COUNT by CFG_NAND_PAGES_PER_BLOCK; V2 NAND_SPL support for phycore imx31 Changelog: * Added bad block verify skip; * Correct to code-style; * Added few comments; V1 nand booting support (SPL) for phyCORE-i.MX31 This patch allows Phytec phyCORE-i.MX31 based system to boot from embed NAND-flash memory. It not add support for NAND cmd and/or driver for U-BOOT, it is only SPL for U-BOOT. For NAND support in U-BOOT I give refer to Magnus Lilja's aug/2008 patch series for PDK/Litekit boards. ([U-Boot] [PATCH v3 4/6] i.MX31: Add i.MX31 NAND Flash Controller driver.; MID 1219998982- 21289-5-git-send-email-lilja.mag...@gmail.com) Some note: by default, Phytec phyCORE-i.MX31 board (pcm-037 on pcm-970) is not suitable for nand-bootloading, because of SW5 switchers block haven't appropriate modes(8-bit, 2k page or 16-bit, 512B page) for BOOTPINS[4:0] and nand-flash(8-bit mode, 512B page) contemporary. There is require to make RESOLDER for really nand-booting either BOOTPIN state or JN1/2 and RN41/42. This nand-spl work with 8-bit, 512B page size nand-flash. Signed-off-by: Maxim Artamonov scn1874 at yandex.ru --- MAKEALL |1 + Makefile|9 ++- board/imx31_phycore/config.mk | 10 ++ board/imx31_phycore/lowlevel_init.S | 27 - board/imx31_phycore/u-boot-nand.lds | 62 ++ cpu/arm1136/start.S | 36 -- include/asm-arm/arch-mx31/mx31-regs.h | 96 +++ include/configs/imx31_phycore.h | 33 + nand_spl/board/imx31_phycore/Makefile | 95 +++ nand_spl/board/imx31_phycore/config.mk | 33 + nand_spl/board/imx31_phycore/u-boot.lds | 65 ++ nand_spl/nand_boot_mx31.c | 200 +++ 12 files changed, 656 insertions(+), 11 deletions(-) create mode 100644 board/imx31_phycore/u-boot-nand.lds create mode 100644 nand_spl/board/imx31_phycore/Makefile create mode 100644 nand_spl/board/imx31_phycore/config.mk create mode 100644 nand_spl/board/imx31_phycore/u-boot.lds create mode 100644 nand_spl/nand_boot_mx31.c diff --git a/MAKEALL b/MAKEALL index 9ccb9ac..1f639a8 100755 --- a/MAKEALL +++ b/MAKEALL @@ -522,6 +522,7 @@ LIST_ARM11=\ apollon \ imx31_litekit \ imx31_phycore \ + imx31_phycore_nand \ mx31ads \ smdk6400\ diff --git a/Makefile b/Makefile index 58b8331..7519dfe 100644 --- a/Makefile +++ b/Makefile @@ -353,7 +353,7 @@ $(NAND_SPL):$(VERSION_FILE) $(obj)include/autoconf.mk $(MAKE) -C nand_spl/board/$(BOARDDIR) all $(U_BOOT_NAND):$(NAND_SPL) $(obj)u-boot.bin $(obj)include/autoconf.mk - cat $(obj)nand_spl/u-boot-spl-16k.bin $(obj)u-boot.bin $(obj)u-boot-nand.bin + cat $(obj)nand_spl/u-boot-spl-aligned.bin $(obj)u-boot.bin $(obj)u-boot-nand.bin $(ONENAND_IPL):$(VERSION_FILE) $(obj)include/autoconf.mk $(MAKE) -C onenand_ipl/board/$(BOARDDIR) all @@ -2805,6 +2805,13 @@ imx31_litekit_config : unconfig imx31_phycore_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm1136 imx31_phycore NULL mx31 +imx31_phycore_nand_config : unconfig + @mkdir -p $(obj)include $(obj)board/imx31_phycore + @mkdir -p $(obj)nand_spl/board/imx31_phycore + @echo #define CONFIG_NAND_U_BOOT $(obj)include/config.h + @$(MKCONFIG) -n $@ -a imx31_phycore arm arm1136 imx31_phycore NULL mx31 + @echo CONFIG_NAND_U_BOOT = y $(obj)include/config.mk + mx31ads_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm1136 mx31ads freescale mx31 diff --git a/board/imx31_phycore/config.mk b/board/imx31_phycore/config.mk index d34dc02..412defc 100644 --- a/board/imx31_phycore/config.mk +++ b/board/imx31_phycore/config.mk @@ -1 +1,11 @@ +# +# (C) Copyright 2008 +# was changed by Maxim Artamonov, scn1874 at yandex.ru +# + +ifndef CONFIG_NAND_SPL TEXT_BASE = 0x87f0 +else +TEXT_BASE = 0x87ec +endif + diff --git a/board/imx31_phycore/lowlevel_init.S b/board/imx31_phycore/lowlevel_init.S index c5d6eb0..afae317 100644 --- a/board/imx31_phycore/lowlevel_init.S +++ b/board/imx31_phycore/lowlevel_init.S @@ -1,5 +1,7 @@ /* - * + * (C) Copyright 2008 + * Maxim Artamonov, scn1874 at yandex.ru + * * (c) 2007 Pengutronix, Sascha Hauer
[U-Boot] [PATCH] MIPS: Fix compile warning in au1x00_eth.c
This patch fixes this compilation warning:
./MAKEALL dbau1000
Configuring for dbau1x00 board...
au1x00_eth.c: In function 'au1x00_send':
au1x00_eth.c:158: warning: passing argument 1 of 'virt_to_phys' discards
qualifiers from pointer target type
...
Seens with ELDK 4.2 (GCC 4.2.2).
Signed-off-by: Stefan Roese s...@denx.de
---
cpu/mips/au1x00_eth.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/cpu/mips/au1x00_eth.c b/cpu/mips/au1x00_eth.c
index 6272a3a..5546800 100644
--- a/cpu/mips/au1x00_eth.c
+++ b/cpu/mips/au1x00_eth.c
@@ -155,7 +155,7 @@ static int au1x00_send(struct eth_device* dev, volatile
void *packet, int length
/* tx fifo should always be idle */
fifo_tx[next_tx].len = length;
- fifo_tx[next_tx].addr = (virt_to_phys(packet))|TX_DMA_ENABLE;
+ fifo_tx[next_tx].addr = (virt_to_phys((void *)packet))|TX_DMA_ENABLE;
au_sync();
udelay(1);
@@ -208,7 +208,8 @@ static int au1x00_recv(struct eth_device* dev){
NetReceive(NetRxPackets[next_rx], length - 4);
}
- fifo_rx[next_rx].addr =
(virt_to_phys(NetRxPackets[next_rx]))|RX_DMA_ENABLE;
+ fifo_rx[next_rx].addr =
+ virt_to_phys((void
*)NetRxPackets[next_rx])|RX_DMA_ENABLE;
next_rx++;
if(next_rx=NO_OF_FIFOS){
@@ -249,7 +250,8 @@ static int au1x00_init(struct eth_device* dev, bd_t * bd){
for(i=0;iNO_OF_FIFOS;i++){
fifo_tx[i].len = 0;
fifo_tx[i].addr = virt_to_phys(txbuf[0]);
- fifo_rx[i].addr = (virt_to_phys(NetRxPackets[i]))|RX_DMA_ENABLE;
+ fifo_rx[i].addr =
+ virt_to_phys((void *)NetRxPackets[i])|RX_DMA_ENABLE;
}
/* Put mac addr in little endian */
--
1.6.1.1.230.gdfb04
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/9] AVR32: macb - Disable 100mbps if clock is slow
Hi Gunnar, Gunnar Rangøy wrote: On Fri, Jan 23, 2009 at 4:38 PM, Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com wrote: On 12:56 Fri 23 Jan , Gunnar Rangoy wrote: From: Olav Morken olav...@gmail.com For 100mbps operation, the ethernet controller requires a 25 MHz clock in MII mode, and a 50 MHz clock in RMII mode. If the clock is slower, disable 100 Mbps mode. Signed-off-by: Gunnar Rangoy gun...@rangoy.com Signed-off-by: Paul Driveklepp pauldrivekl...@gmail.com Signed-off-by: Olav Morken olav...@gmail.com --- drivers/net/macb.c | 12 +++- 1 files changed, 11 insertions(+), 1 deletions(-) diff --git a/drivers/net/macb.c b/drivers/net/macb.c index 08bebf7..d47a052 100644 --- a/drivers/net/macb.c +++ b/drivers/net/macb.c @@ -297,7 +297,17 @@ static void macb_phy_reset(struct macb_device *macb) int i; u16 status, adv; - adv = ADVERTISE_CSMA | ADVERTISE_ALL; + adv = ADVERTISE_CSMA | ADVERTISE_ALL ; ?? Oops... Will fix this. + +#ifdef CONFIG_MACB_FORCE10M + printf(%s: 100Mbps is not supported on this board - forcing 10Mbps.\n, +netdev-name); + + adv = ~ADVERTISE_100FULL; + adv = ~ADVERTISE_100HALF; + adv = ~ADVERTISE_100BASE4; +#endif not a fan could you be more specific about the problem? Best Regards, J. On the EVK1100 board, the CPU (UC3A0512) is connected to the PHY via an RMII bus. This requires the CPU clock to be at least 50 MHz. Unfortunately, the chip on current EVK1100 boards may be unable to run at more than 50 MHz, and with the oscillator on the board, the closest frequency we can generate is 48 MHz. This patch makes it possible to limit the macb to 10 MBit for this case. We are open for suggestions for other solutions. How about using a PHY capability override CONFIG. Something like this: #if defined(CONFIG_MACB_PHY_CAPAB)-- insert better name here adv = ADVERTISE_CSMA | CONFIG_MACB_PHY_CAPAB; #else adv = ADVERTISE_CSMA | ADVERTISE_ALL #endif Just an idea... regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/9] Fix IP alignement problem
Gunnar Rangoy wrote:
From: Olav Morken olav...@gmail.com
This patch removes volatile from:
volatile IP_t *ip = (IP_t *)xip;
Due to a bug, avr32-gcc will assume that ip is aligned on a word boundary when
using volatile, which causes an exception since xip isn't aligned on a word
boundary.
Signed-off-by: Gunnar Rangoy gun...@rangoy.com
Signed-off-by: Paul Driveklepp pauldrivekl...@gmail.com
Signed-off-by: Olav Morken olav...@gmail.com
---
net/net.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/net.c b/net/net.c
index 313d5d8..405ca6e 100644
--- a/net/net.c
+++ b/net/net.c
@@ -1685,7 +1685,7 @@ NetSetEther(volatile uchar * xet, uchar * addr, uint
prot)
void
NetSetIP(volatile uchar * xip, IPaddr_t dest, int dport, int sport, int len)
{
- volatile IP_t *ip = (IP_t *)xip;
+ IP_t *ip = (IP_t *)xip;
/*
* If the data is an odd number of bytes, zero the
This seems reasonable. I'll try it out and will get back to you soon.
regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] include/image.h: Use explicit function definitions instead of macro trickery
Signed-off-by: Petri Lehtinen petri.lehti...@inoi.fi
---
I got frustrated while grepping through the sources, trying to find
the definitions of these functions. Thinking back, the obvious place
to look in the first place would of course have been include/image.h,
but it didn't even cross my mind that there could be some macro
trickery behind these functions.
Anyway, I think that explicit is better than implicit and that this
kind of macro usage is ugly.
include/image.h | 154 +++
1 files changed, 110 insertions(+), 44 deletions(-)
diff --git a/include/image.h b/include/image.h
index 4609200..e3c33ca 100644
--- a/include/image.h
+++ b/include/image.h
@@ -333,28 +333,60 @@ static inline uint32_t image_get_header_size (void)
return (sizeof (image_header_t));
}
-#define image_get_hdr_l(f) \
- static inline uint32_t image_get_##f(image_header_t *hdr) \
- { \
- return uimage_to_cpu (hdr-ih_##f); \
- }
-image_get_hdr_l (magic);
-image_get_hdr_l (hcrc);
-image_get_hdr_l (time);
-image_get_hdr_l (size);
-image_get_hdr_l (load);
-image_get_hdr_l (ep);
-image_get_hdr_l (dcrc);
-
-#define image_get_hdr_b(f) \
- static inline uint8_t image_get_##f(image_header_t *hdr) \
- { \
- return hdr-ih_##f; \
- }
-image_get_hdr_b (os);
-image_get_hdr_b (arch);
-image_get_hdr_b (type);
-image_get_hdr_b (comp);
+static inline uint32_t image_get_magic (image_header_t *hdr)
+{
+ return uimage_to_cpu (hdr-ih_magic);
+}
+
+static inline uint32_t image_get_hcrc (image_header_t *hdr)
+{
+ return uimage_to_cpu (hdr-ih_hcrc);
+}
+
+static inline uint32_t image_get_time (image_header_t *hdr)
+{
+ return uimage_to_cpu (hdr-ih_time);
+}
+
+static inline uint32_t image_get_size (image_header_t *hdr)
+{
+ return uimage_to_cpu (hdr-ih_size);
+}
+
+static inline uint32_t image_get_load (image_header_t *hdr)
+{
+ return uimage_to_cpu (hdr-ih_load);
+}
+
+static inline uint32_t image_get_ep (image_header_t *hdr)
+{
+ return uimage_to_cpu (hdr-ih_ep);
+}
+
+static inline uint32_t image_get_dcrc (image_header_t *hdr)
+{
+ return uimage_to_cpu (hdr-ih_dcrc);
+}
+
+static inline uint8_t image_get_os (image_header_t *hdr)
+{
+ return hdr-ih_os;
+}
+
+static inline uint8_t image_get_arch (image_header_t *hdr)
+{
+ return hdr-ih_arch;
+}
+
+static inline uint8_t image_get_type (image_header_t *hdr)
+{
+ return hdr-ih_type;
+}
+
+static inline uint8_t image_get_comp (image_header_t *hdr)
+{
+ return hdr-ih_comp;
+}
static inline char *image_get_name (image_header_t *hdr)
{
@@ -386,33 +418,67 @@ static inline uint32_t image_get_image_size
(image_header_t *hdr)
{
return (image_get_size (hdr) + image_get_header_size ());
}
+
static inline ulong image_get_image_end (image_header_t *hdr)
{
return ((ulong)hdr + image_get_image_size (hdr));
}
-#define image_set_hdr_l(f) \
- static inline void image_set_##f(image_header_t *hdr, uint32_t val) \
- { \
- hdr-ih_##f = cpu_to_uimage (val); \
- }
-image_set_hdr_l (magic);
-image_set_hdr_l (hcrc);
-image_set_hdr_l (time);
-image_set_hdr_l (size);
-image_set_hdr_l (load);
-image_set_hdr_l (ep);
-image_set_hdr_l (dcrc);
-
-#define image_set_hdr_b(f) \
- static inline void image_set_##f(image_header_t *hdr, uint8_t val) \
- { \
- hdr-ih_##f = val; \
- }
-image_set_hdr_b (os);
-image_set_hdr_b (arch);
-image_set_hdr_b (type);
-image_set_hdr_b (comp);
+
+static inline void image_set_magic (image_header_t *hdr, uint32_t val)
+{
+ hdr-ih_magic = cpu_to_uimage (val);
+}
+
+static inline void image_set_hcrc (image_header_t *hdr, uint32_t val)
+{
+ hdr-ih_hcrc = cpu_to_uimage (val);
+}
+
+static inline void image_set_time (image_header_t *hdr, uint32_t val)
+{
+ hdr-ih_time = cpu_to_uimage (val);
+}
+
+static inline void image_set_size (image_header_t *hdr, uint32_t val)
+{
+ hdr-ih_size = cpu_to_uimage (val);
+}
+
+static inline void image_set_load (image_header_t *hdr, uint32_t val)
+{
+ hdr-ih_load = cpu_to_uimage (val);
+}
+
+static inline void image_set_ep (image_header_t *hdr, uint32_t val)
+{
+ hdr-ih_ep = cpu_to_uimage (val);
+}
+
+static inline void image_set_dcrc (image_header_t *hdr, uint32_t val)
+{
+ hdr-ih_dcrc = cpu_to_uimage (val);
+}
+
+static inline void image_set_os (image_header_t *hdr, uint8_t val)
+{
+ hdr-ih_os = val;
+}
+
+static inline void image_set_arch (image_header_t *hdr, uint8_t val)
+{
+ hdr-ih_arch = val;
+}
+
+static inline void image_set_type (image_header_t *hdr, uint8_t val)
+{
+ hdr-ih_type = val;
+}
+
+static inline void image_set_comp (image_header_t *hdr, uint8_t val)
+{
+ hdr-ih_comp = val;
+}
static inline void image_set_name (image_header_t *hdr, const char *name)
{
--
1.6.0.4
___
U-Boot
Re: [U-Boot] [PATCH] ppc4xx: Fix initialization of SDRAM_CODT register in ppc_4xx_ddr2.c
Stefan, Carolyn, Yes, I do intend on sending out an AMCC patch to remove the definition for SDRAM_CODT_FEEBBACK_RCV_SINGLE_END and SDRAM_CODT_FEEBBACK_DRV_SINGLE_END. My apologies Carolyn as I should have notified you of this intent. My AMCC patch to remove these SDRAM_CODT bit definitions may come after your patch Carolyn, so in your patch do not include the usage of these (SDRAM_CODT_FEEBBACK_RCV_SINGLE_END and SDRAM_CODT_FEEBBACK_DRV_SINGLE_END) bits. According to our AMCC PPC4xx chip hardware designers, the SDRAM_CODT IP feedback signal is single ended (i.e. SDRAM_CODT bits 29 and 30). The PPC4xx SDRAM_CODT bits 29 and 30 are reserved non-changeable bits as they are set in the IP to single-ended mode: SDRAM_CODT bit 29 0 Sets feedback receiver to differential mode 1 Sets feedback receiver to single ended mode (mode set for the AMCC 4xx SoC chips) bit 30 0 Sets feedback driver to differential mode 1 Sets feedback driver to single ended mode (mode set for the AMCC 4xx SoC chips) Best, Adam -Original Message- From: Stefan Roese [mailto:s...@denx.de] Sent: Monday, January 26, 2009 9:47 PM To: u-boot@lists.denx.de Cc: carolyn.j.sm...@tektronix.com; Adam Graham Subject: Re: [U-Boot] [PATCH] ppc4xx: Fix initialization of SDRAM_CODT register in ppc_4xx_ddr2.c On Monday 26 January 2009, carolyn.j.sm...@tektronix.com wrote: This fixes the initialization of the SDRAM_CODT register in the ppc4xx DDR2 initialization code. The changes were discussed with Stefan Roese and Adam Graham and tested by Adam. General comment: The line The changes were discussed... should be placed below the --- since it doesn't really belong to the patch description. Signed-off-by: Carolyn Smith carolyn.sm...@tektronix.com --- diff -w -uprN old/cpu/ppc4xx/44x_spd_ddr2.c new/cpu/ppc4xx/44x_spd_ddr2.c --- old/cpu/ppc4xx/44x_spd_ddr2.c 2009-01-20 13:00:33.0 -0800 +++ new/cpu/ppc4xx/44x_spd_ddr2.c 2009-01-23 16:00:49.0 -0800 @@ -1104,11 +1104,14 @@ static void program_codt(unsigned long * * Set the SDRAM Controller On Die Termination Register *-*/ mfsdram(SDRAM_CODT, codt); - codt |= (SDRAM_CODT_IO_NMODE - (~SDRAM_CODT_DQS_SINGLE_END -~SDRAM_CODT_CKSE_SINGLE_END -~SDRAM_CODT_FEEBBACK_RCV_SINGLE_END -~SDRAM_CODT_FEEBBACK_DRV_SINGLE_END)); + + codt |= SDRAM_CODT_IO_NMODE; + + codt = ~(SDRAM_CODT_DQS_SINGLE_END | + SDRAM_CODT_CKSE_SINGLE_END | + SDRAM_CODT_FEEBBACK_RCV_SINGLE_END | + SDRAM_CODT_FEEBBACK_DRV_SINGLE_END); + I don't think that this is correct. As I understood from Adam, those bits it questions are undefined/reserevd on all 4xx PPC's. So we should better remove the code referencing those values. Here is what Adam wrote: It is in fact the case for all the AMCC 4xx SoC chips that have the IBM SDRAM memory controller core IP, the SDRAM_CODT register, bits 29 and 30 are reserved bits. Thanks Carolyn for finding this issue. We will update the 44x_spd_ddr2.c file and send out a patch shortly for this SDRAM_CODT register bits 29-30 issue. Adam, do you still plan to send a patch for this? Or did I misunderstand you and the patch above is ok? Thanks. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5 v2] Command usage cleanup
Dear Peter Tyser, In message 1233100992-30871-1-git-send-email-pty...@xes-inc.com you wrote: Changes since v1: - Rebase on top of tree This patch series attempts to clean up how the usage field of the cmd_tbl_s structure is used. It does 3 things: 1. Adds a cmd_usage() function to print a command's usage 2. Removes the command name from the usage field for all commands 3. Removes newlines from the usage field of all commands The benefits of these changes are: 1. Command formatting in the help command output will always be properly aligned. A fair number of commands currently aren't properly formated, eg cmd1 - description vs cmd2- description. 2. Command definitions are reduced in size/complexity. The patch shaved off 1.1KB from the XPedite5370 image for example. Most of the changes were done via scripts, so let me know if anything looks fishy. Best, Peter Peter Tyser (5): Clean up diufb command definitions pcs440ep: Clean up led command definition Standardize command usage messages with new cmd_usage() function amcc: Clean up command usage output Command usage cleanup All patches applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Whom the gods would destroy, they first teach BASIC. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
