August 2010 - U-Boot

[U-Boot] "UnCorrectable RS-ECC Error" occurs when reading NAND flash under u-boot 2009.08 for i.mx25
by dajiang 28 Aug '10

28 Aug '10

Hi, every one. This is my first time of posting a message here, firstly , thanks for any body who builds such a nice platform give help. In recent two weeks, I added a NAND flash driver support for Micron's MT29F2G08ABD (SLC;page size: x8 2048+64bytes; Block size: 64 pages; Device size: 2Gb) memory chip base on u-boot 2009.08 for i.mx25. Block Erasing and Page Programming functions worked properly, but when I do page reading operation, "UnCorrectable RS-ECC Error" error message prompted. I checked the NFC (NAND Flash Controller) spare area buffer and found that the 4th 512-byte spare area buffer's data were very weird, there is not any ECC code that should be generated by the FEC but contained the data what I programmed to the memory. In order to easy to do troubleshooting works, I make a simply testing process, what I do is, firstly, I only erase page 0 of block 0, and later I program the erased page with a 2k file which consisted of 2048 same character 'E', at last I read the page back , but "UnCorrectable RS-ECC Error" occurs. I pasted the contents of NFC's spare area buffer as following: bb001000: ffffffff 66ffffff bab935d1 22446bbd .......f.5...kD" bb001010: b935d166 ffffffba ffffffff ffffffff f.5............. bb001020: 5f7467b9 21650de8 4d97fbd0 3166372c .gt_..e!...M,7f1 bb001030: 3b7e8bef b1cf62a5 bb8f50f6 de0031b3 ..~;.b...P...1.. bb001040: ffffffff 66ffffff bab935d1 22446bbd .......f.5...kD" bb001050: b935d166 ffffffba ffffffff ffffffff f.5............. bb001060: bafcf1fa 0c0698ef 09089d72 e6200c80 ........r..... . bb001070: d638f5ef 20130b40 591dd763 e224f527 ..8.@.. c..Y'.$. bb001080: ffffffff 66ffffff bab935d1 22446bbd .......f.5...kD" bb001090: b935d166 ffffffba ffffffff ffffffff f.5............. bb0010a0: 76fa88ba 7a648809 d27bbc43 6b2b81cf ...v..dzC.{...+k bb0010b0: f6b95e3b 1286638e 73d324fb 22880ce5 ;^...c...$.s..." bb0010c0: 45454545 45454545 45454545 45454545 EEEEEEEEEEEEEEEE bb0010d0: 45454545 45454545 45454545 45454545 EEEEEEEEEEEEEEEE bb0010e0: 36d8f3d5 0099a9e7 eb289d07 11664624 ...6......(.$Ff. bb0010f0: 4fbb9f24 505ab041 25ff61f6 43280406 $..OA.ZP.a.%..(C Contents written in red characters should be ECC code, but changed to what I programmed to the memory in preverious programming process. Any advice, please feel free to tell me. Thanks very much in advance. -- View this message in context: http://old.nabble.com/%22UnCorrectable-RS-ECC-Error%22-occurs-when-reading-… Sent from the Uboot - Users mailing list archive at Nabble.com.

1 0

[U-Boot] [PATCH 3/3] mpc8610: refactor DIU initialization code to use existing bitmap function
by Timur Tabi 27 Aug '10

27 Aug '10

The Freescale MPC8610 DIU code has its own bitmap-drawing function, fsl_diu_display_bmp(), which is redundant. Instead, use the existing function video_display_bitmap(). Replacing fsl_diu_display_bmp() with video_display_bitmap() also requires refactoring the DIU initialization code. Signed-off-by: Timur Tabi <timur(a)freescale.com> --- This patch requires this other patch: video: cfb_console: add support for 4bpp bitmaps with GDF_32BIT_X888RGB board/freescale/common/fsl_diu_fb.c | 155 +++++++----------------- board/freescale/common/fsl_diu_fb.h | 7 +- board/freescale/mpc8610hpcd/mpc8610hpcd.c | 16 ++- board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c | 100 ++-------------- include/configs/MPC8610HPCD.h | 6 +- 5 files changed, 76 insertions(+), 208 deletions(-) diff --git a/board/freescale/common/fsl_diu_fb.c b/board/freescale/common/fsl_diu_fb.c index e740ad8..e0ff466 100644 --- a/board/freescale/common/fsl_diu_fb.c +++ b/board/freescale/common/fsl_diu_fb.c @@ -27,6 +27,9 @@ #include <i2c.h> #include <malloc.h> #include <asm/io.h> +#include <bmp_layout.h> +#include <stdio_dev.h> +#include <video_fb.h> #include "fsl_diu_fb.h" @@ -359,10 +362,15 @@ int fsl_diu_init(int xres, fb_initialized = 1; if (splash_bmp) { - info->logo_height = fsl_diu_display_bmp(splash_bmp, 0, 0, 0); + /* + * If we want a banner on top of the screen, we want to remember + * its size here, so that video_hw_init() can set the right + * display height. + */ + bmp_header_t *bmp = (bmp_header_t *)splash_bmp; + + info->logo_height = le32_to_cpu(bmp->height); info->logo_size = info->logo_height * info->line_length; - debug("logo height %d, logo_size 0x%x\n", - info->logo_height,info->logo_size); } /* Enable the DIU */ @@ -486,117 +494,44 @@ static int allocate_buf(struct diu_addr *buf, u32 size, u32 bytes_align) return 0; } -int fsl_diu_display_bmp(unsigned char *bmp, - int xoffset, - int yoffset, - int transpar) +/* + * The Graphic Device + */ +static GraphicDevice ctfb; + +/* Board-specific video initialization */ +void __board_diu_init(void) { - struct fb_info *info = &fsl_fb_info; - unsigned char r, g, b; - unsigned int *fb_t, val; - unsigned char *bitmap; - unsigned int palette[256]; - int width, height, bpp, ncolors, raster, offset, x, y, i, k, cpp; - - if (!bmp) { - printf("Must supply a bitmap address\n"); - return 0; - } +} +int board_diu_init(void) __attribute__((weak, alias("__board_diu_init"))); - raster = bmp[10] + (bmp[11] << 8) + (bmp[12] << 16) + (bmp[13] << 24); - width = (bmp[21] << 24) | (bmp[20] << 16) | (bmp[19] << 8) | bmp[18]; - height = (bmp[25] << 24) | (bmp[24] << 16) | (bmp[23] << 8) | bmp[22]; - bpp = (bmp[29] << 8) | (bmp[28]); - ncolors = bmp[46] + (bmp[47] << 8) + (bmp[48] << 16) + (bmp[49] << 24); - bitmap = bmp + raster; - cpp = info->var.bits_per_pixel / 8; - - debug("bmp = 0x%08x\n", (unsigned int)bmp); - debug("bitmap = 0x%08x\n", (unsigned int)bitmap); - debug("width = %d\n", width); - debug("height = %d\n", height); - debug("bpp = %d\n", bpp); - debug("ncolors = %d\n", ncolors); - - debug("xres = %d\n", info->var.xres); - debug("yres = %d\n", info->var.yres); - debug("Screen_base = 0x%x\n", (unsigned int)info->screen_base); - - if (((width+xoffset) > info->var.xres) || - ((height+yoffset) > info->var.yres)) { - printf("bitmap is out of range, image too large or too much offset\n"); - return 0; - } - if (bpp < 24) { - for (i = 0, offset = 54; i < ncolors; i++, offset += 4) - palette[i] = (bmp[offset+2] << 16) - + (bmp[offset+1] << 8) + bmp[offset]; - } +void *video_hw_init(void) +{ + struct fb_info *info; - switch (bpp) { - case 1: - for (y = height - 1; y >= 0; y--) { - fb_t = (unsigned int *) ((unsigned int)info->screen_base + (((y+yoffset) * info->var.xres) + xoffset)*cpp); - for (x = 0; x < width; x += 8) { - b = *bitmap++; - for (k = 0; k < 8; k++) { - if (b & 0x80) - *fb_t++ = palette[1]; - else - *fb_t++ = palette[0]; - b = b << 1; - } - } - for (i = (width / 2) % 4; i > 0; i--) - bitmap++; - } - break; - case 4: - for (y = height - 1; y >= 0; y--) { - fb_t = (unsigned int *) ((unsigned int)info->screen_base + (((y+yoffset) * info->var.xres) + xoffset)*cpp); - for (x = 0; x < width; x += 2) { - b = *bitmap++; - r = (b >> 4) & 0x0F; - g = b & 0x0F; - *fb_t++ = palette[r]; - *fb_t++ = palette[g]; - } - for (i = (width / 2) % 4; i > 0; i--) - bitmap++; - } - break; - case 8: - for (y = height - 1; y >= 0; y--) { - fb_t = (unsigned int *) ((unsigned int)info->screen_base + (((y+yoffset) * info->var.xres) + xoffset)*cpp); - for (x = 0; x < width; x++) { - *fb_t++ = palette[ *bitmap++ ]; - } - for (i = (width / 2) % 4; i > 0; i--) - bitmap++; - } - break; - case 24: - for (y = height - 1; y >= 0; y--) { - fb_t = (unsigned int *) ((unsigned int)info->screen_base + (((y+yoffset) * info->var.xres) + xoffset)*cpp); - for (x = 0; x < width; x++) { - b = *bitmap++; - g = *bitmap++; - r = *bitmap++; - val = (r << 16) + (g << 8) + b; - *fb_t++ = val; - } - for (; (x % 4) != 0; x++) /* 4-byte alignment */ - bitmap++; - } - break; - } + board_diu_init(); - return height; -} + /* fill in Graphic device struct */ + ctfb.frameAdrs = (unsigned int)fsl_fb_open(&info); + ctfb.winSizeX = info->xres; + ctfb.winSizeY = info->yres - info->logo_height; + ctfb.plnSizeX = ctfb.winSizeX; + ctfb.plnSizeY = ctfb.winSizeY; -void fsl_diu_clear_screen(void) -{ - struct fb_info *info = &fsl_fb_info; + ctfb.gdfBytesPP = 4; + ctfb.gdfIndex = GDF_32BIT_X888RGB; - memset(info->screen_base, 0, info->smem_len); + ctfb.isaBase = 0; + ctfb.pciBase = 0; + ctfb.memSize = info->screen_size - info->logo_size; + + /* Cursor Start Address */ + ctfb.dprBase = 0; + ctfb.vprBase = 0; + ctfb.cprBase = 0; + + sprintf(ctfb.modeIdent, + "%dx%dx%d %ukHz %uHz", info->xres, info->yres, 32, 64, 60); + + return &ctfb; } diff --git a/board/freescale/common/fsl_diu_fb.h b/board/freescale/common/fsl_diu_fb.h index 6deba32..da5fa76 100644 --- a/board/freescale/common/fsl_diu_fb.h +++ b/board/freescale/common/fsl_diu_fb.h @@ -51,6 +51,8 @@ struct fb_info { unsigned int line_length; /* length of a line in bytes */ char *screen_base; + unsigned int xres; + unsigned int yres; unsigned long screen_size; int logo_height; unsigned int logo_size; @@ -62,8 +64,3 @@ extern int fsl_diu_init(int xres, unsigned int pixel_format, int gamma_fix, unsigned char *splash_bmp); -extern void fsl_diu_clear_screen(void); -extern int fsl_diu_display_bmp(unsigned char *bmp, - int xoffset, - int yoffset, - int transpar); diff --git a/board/freescale/mpc8610hpcd/mpc8610hpcd.c b/board/freescale/mpc8610hpcd/mpc8610hpcd.c index 6578f58..a172fd7 100644 --- a/board/freescale/mpc8610hpcd/mpc8610hpcd.c +++ b/board/freescale/mpc8610hpcd/mpc8610hpcd.c @@ -33,11 +33,13 @@ #include <fdt_support.h> #include <spd_sdram.h> #include <netdev.h> +#include <bmp_layout.h> void sdram_init(void); phys_size_t fixed_sdram(void); -void mpc8610hpcd_diu_init(void); +extern unsigned int FSL_Logo_BMP[]; +int video_display_bitmap(unsigned long, int, int); /* called before any console output */ int board_early_init_f(void) @@ -54,6 +56,9 @@ int misc_init_r(void) { u8 tmp_val, version; u8 *pixis_base = (u8 *)PIXIS_BASE; +#ifdef CONFIG_VIDEO + bmp_header_t *bmp = (bmp_header_t *)FSL_Logo_BMP; +#endif /*Do not use 8259PIC*/ tmp_val = in_8(pixis_base + PIXIS_BRDCFG0); @@ -84,8 +89,13 @@ int misc_init_r(void) i2c_read(0x38, 0x0A, 1, &tmp_val, sizeof(tmp_val)); debug("DVI Encoder Read: 0x%02lx\n",tmp_val); -#ifdef CONFIG_FSL_DIU_FB - mpc8610hpcd_diu_init(); +#ifdef CONFIG_VIDEO + /* + * U-Boot has been told that the display is shorter than it really is, + * so we put the banner at a negative Y-axis. This draws it on the + * top of the screen, but it won't scroll off. + */ + video_display_bitmap((unsigned long)bmp, 0, -le32_to_cpu(bmp->height)); #endif return 0; diff --git a/board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c b/board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c index 781a7c8..747f5c7 100644 --- a/board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c +++ b/board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c @@ -32,14 +32,10 @@ #include "../common/fsl_diu_fb.h" #if defined(CONFIG_VIDEO) || defined(CONFIG_CFB_CONSOLE) -#include <stdio_dev.h> -#include <video_fb.h> #endif extern unsigned int FSL_Logo_BMP[]; -static int xres, yres; - void diu_set_pixel_clock(unsigned int pixclock) { volatile immap_t *immap = (immap_t *)CONFIG_SYS_IMMR; @@ -61,7 +57,7 @@ void diu_set_pixel_clock(unsigned int pixclock) debug("DIU: Modified value of CLKDVDR = 0x%08x\n", *guts_clkdvdr); } -void mpc8610hpcd_diu_init(void) +void board_diu_init(void) { char *monitor_port; int gamma_fix; @@ -69,14 +65,17 @@ void mpc8610hpcd_diu_init(void) unsigned char tmp_val; unsigned char pixis_arch; u8 *pixis_base = (u8 *)PIXIS_BASE; + struct fb_info *info; + + fsl_fb_open(&info); tmp_val = in_8(pixis_base + PIXIS_BRDCFG0); pixis_arch = in_8(pixis_base + PIXIS_VER); monitor_port = getenv("monitor"); if (!strncmp(monitor_port, "0", 1)) { /* 0 - DVI */ - xres = 1280; - yres = 1024; + info->xres = 1280; + info->yres = 1024; if (pixis_arch == 0x01) pixel_format = 0x88882317; else @@ -85,102 +84,29 @@ void mpc8610hpcd_diu_init(void) out_8(pixis_base + PIXIS_BRDCFG0, tmp_val | 0x08); } else if (!strncmp(monitor_port, "1", 1)) { /* 1 - Single link LVDS */ - xres = 1024; - yres = 768; + info->xres = 1024; + info->yres = 768; pixel_format = 0x88883316; gamma_fix = 0; out_8(pixis_base + PIXIS_BRDCFG0, (tmp_val & 0xf7) | 0x10); } else if (!strncmp(monitor_port, "2", 1)) { /* 2 - Double link LVDS */ - xres = 1280; - yres = 1024; + info->xres = 1280; + info->yres = 1024; pixel_format = 0x88883316; gamma_fix = 1; out_8(pixis_base + PIXIS_BRDCFG0, tmp_val & 0xe7); } else { /* DVI */ - xres = 1280; - yres = 1024; + info->xres = 1280; + info->yres = 1024; pixel_format = 0x88882317; gamma_fix = 0; out_8(pixis_base + PIXIS_BRDCFG0, tmp_val | 0x08); } - fsl_diu_init(xres, pixel_format, gamma_fix, + fsl_diu_init(info->xres, pixel_format, gamma_fix, (unsigned char *)FSL_Logo_BMP); } -int mpc8610diu_init_show_bmp(cmd_tbl_t *cmdtp, - int flag, int argc, char * const argv[]) -{ - unsigned int addr; - - if (argc < 2) - return cmd_usage(cmdtp); - - if (!strncmp(argv[1],"init",4)) { -#if defined(CONFIG_VIDEO) || defined(CONFIG_CFB_CONSOLE) - fsl_diu_clear_screen(); - drv_video_init(); -#else - mpc8610hpcd_diu_init(); -#endif - } else { - addr = simple_strtoul(argv[1], NULL, 16); - fsl_diu_clear_screen(); - fsl_diu_display_bmp((unsigned char *)addr, 0, 0, 0); - } - - return 0; -} - -U_BOOT_CMD( - diufb, CONFIG_SYS_MAXARGS, 1, mpc8610diu_init_show_bmp, - "Init or Display BMP file", - "init\n - initialize DIU\n" - "addr\n - display bmp at address 'addr'" -); - - -#if defined(CONFIG_VIDEO) || defined(CONFIG_CFB_CONSOLE) - -/* - * The Graphic Device - */ -GraphicDevice ctfb; -void *video_hw_init(void) -{ - GraphicDevice *pGD = (GraphicDevice *) &ctfb; - struct fb_info *info; - - mpc8610hpcd_diu_init(); - - /* fill in Graphic device struct */ - sprintf(pGD->modeIdent, - "%dx%dx%d %ldkHz %ldHz", - xres, yres, 32, 64, 60); - - pGD->frameAdrs = (unsigned int)fsl_fb_open(&info); - pGD->winSizeX = xres; - pGD->winSizeY = yres - info->logo_height; - pGD->plnSizeX = pGD->winSizeX; - pGD->plnSizeY = pGD->winSizeY; - - pGD->gdfBytesPP = 4; - pGD->gdfIndex = GDF_32BIT_X888RGB; - - pGD->isaBase = 0; - pGD->pciBase = 0; - pGD->memSize = info->screen_size - info->logo_size; - - /* Cursor Start Address */ - pGD->dprBase = 0; - pGD->vprBase = 0; - pGD->cprBase = 0; - - return (void *)pGD; -} - -#endif /* defined(CONFIG_VIDEO) || defined(CONFIG_CFB_CONSOLE) */ - #endif /* CONFIG_FSL_DIU_FB */ diff --git a/include/configs/MPC8610HPCD.h b/include/configs/MPC8610HPCD.h index 4d9606e..84979e4 100644 --- a/include/configs/MPC8610HPCD.h +++ b/include/configs/MPC8610HPCD.h @@ -22,9 +22,9 @@ #define CONFIG_FSL_DIU_FB 1 /* FSL DIU */ /* video */ -#undef CONFIG_VIDEO - -#if defined(CONFIG_VIDEO) +#define CONFIG_VIDEO +#ifdef CONFIG_VIDEO +#define CONFIG_CMD_BMP #define CONFIG_CFB_CONSOLE #define CONFIG_VGA_AS_SINGLE_DEVICE #endif -- 1.7.2.1

1 1

[U-Boot] [PATCH 2/2] cmp_bmp: allow negative X, Y values for display command
by Timur Tabi 27 Aug '10

27 Aug '10

The 'bmp display' command accepts optional X and Y values for the position of the image to be displayed. Change the code which parses the command line to accept negative values. This feature is useful if you want to use a frame buffer for the console, and you want a banner displayed on the top of the screen that never scrolls off. This can be accomplished by declaring that the width and height of the video screen is smaller than it really is, and then drawing an image in the undeclared area. For example, if you have 1280x1024 monitor, and you want to display a banner on the top of the screen that's 100 pixels tall, then video_hw_init() should say that display is really 1280x924, and then the banner should be drawn at position (0, -100). Signed-off-by: Timur Tabi <timur(a)freescale.com> --- 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 d51cc55..06c1547 100644 --- a/common/cmd_bmp.c +++ b/common/cmd_bmp.c @@ -122,8 +122,8 @@ static int do_bmp_display(cmd_tbl_t * cmdtp, int flag, int argc, char * const ar break; case 4: addr = simple_strtoul(argv[1], NULL, 16); - x = simple_strtoul(argv[2], NULL, 10); - y = simple_strtoul(argv[3], NULL, 10); + x = simple_strtol(argv[2], NULL, 10); + y = simple_strtol(argv[3], NULL, 10); break; default: return cmd_usage(cmdtp); -- 1.7.2.1

4 7

[U-Boot] [PATCH V3 0/4] Improve I2C for orion5x, kirkwood and ED Mini V2
by Albert Aribaud 27 Aug '10

27 Aug '10

SUMMARY: This patchset improves the driver for the Marvell TWSI interface found on orion5x and kirkwood SoCs and adds I2C support to the orion5x-based ED Mini V2 board. The mvtwsi driver is a complete rewrite, 50% shorter in source code lines, 25% smaller in object size, much simpler and way faster than the kirkwood_i2c driver it replaces. PATCH SET: Patch 1 removes dependencies on kirwkood_i2c from suen3, the only board that mentioned it. Patch 2 renames the driver from kirkwood_i2c to mvtwsi. Patch 3 replaces the old code with the new one. Patch 4 adds support for I2C in orion5x-based ED Mini V2. TESTS: This driver has been tested on an ED Mini V2 with basic u-boot i2c commands, on an 5C372a RTC and an HT24LC08 1 KB eeprom (read+write). HISTORY: V1: Initial submission as an addition rather than a replacement. V2: Fixed copyright line. Made mvtwsi a replacement for kirkwood_i2c. Made patches checkpatch-clean: 0 errors, 0 warnings. Various cosmetic changes. Removed useless i2c_end() function. V3: Reduced line lengths below 78 characters. Removed blank line after function description block comment. Albert Aribaud (4): suen3: remove CONFIG_HARD_I2C and related defines i2c: rename kirkwood_i2c to mvtwsi i2c: rewrite mvtwsi, support orion5x and kirkwood edminiv2: add I2C support using mvtwsi driver drivers/i2c/Makefile | 2 +- drivers/i2c/kirkwood_i2c.c | 496 -------------------------------------------- drivers/i2c/mvtwsi.c | 422 +++++++++++++++++++++++++++++++++++++ include/configs/edminiv2.h | 9 + include/configs/km_arm.h | 8 - 5 files changed, 432 insertions(+), 505 deletions(-) delete mode 100644 drivers/i2c/kirkwood_i2c.c create mode 100644 drivers/i2c/mvtwsi.c

3 11

[U-Boot] [PATCH] orion5x: fix comment-in-comment typo in cpu.h
by Albert Aribaud 27 Aug '10

27 Aug '10

Signed-off-by: Albert Aribaud <albert.aribaud(a)free.fr> --- arch/arm/include/asm/arch-orion5x/cpu.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/include/asm/arch-orion5x/cpu.h b/arch/arm/include/asm/arch-orion5x/cpu.h index 80717f8..6ce02a9 100644 --- a/arch/arm/include/asm/arch-orion5x/cpu.h +++ b/arch/arm/include/asm/arch-orion5x/cpu.h @@ -76,7 +76,7 @@ enum orion5x_cpu_attrib { /* * Device Address MAP BAR values -/* + * * All addresses and sizes not defined by board code * will be given default values here. */ -- 1.7.1

2 1

[U-Boot] NFS 'Loading: *_*** ERROR: Cannot mount'
by StephenPaulraj Chinnadurai-ERS,HCLTech 27 Aug '10

27 Aug '10

Dear Marek, I am getting following error message when tried to download zImage to the SDRAM. MDT-Boot> MDT-Boot> nfs a1300000 10.100.144.245:/var/bin/lib/tftpboot/zImage SMC91111: MAC 00:00:70:26:1e:01 Using SMC91111-0 device File transfer via NFS from server 10.100.144.245; our IP address is 10.100.144.90 Filename '/var/lib/tftpboot/zImage'. Load address: 0xa1300000 Loading: *_*** ERROR: Cannot mount Abort MDT-Boot> What is that I need to do to make nfs work? Thanks and Regards Stephen Paulraj C DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. -----------------------------------------------------------------------------------------------------------------------

2 1

Re: [U-Boot] u-boot-x86
by Graeme Russ 27 Aug '10

27 Aug '10

Hi Sk, Please keep the Cc list intact (specifically U-Boot Users). Although some of these questions are a little off-topic for the list, there is much confusion about U-Boot as an embedded boot loader, CoreBoot as a BIOS replacement which can boot the Linux kernel directly and x86 'Bootloaders' such as LILO, GRUB etc. Having this information in the mailing list archive is important On 25/08/10 17:58, sk ong wrote: > Graeme, > > Thanks for your response. > > I have not accessed gmail for few days, so I see this late, I will take > some time to digest and look at coreboot too. > > I do not fully understand, can I ask some questions? Sure - Questions are always welcome :) > > Board designer of embedded board knows the information, instead of BIOS, > how does u-boot pass this information to protected-mode entry of linux > kernel? The x86 Linux Kernel has two components, a 'Real-Mode' component (which has access to BIOS but very limited access to memory and devices) and a 'Protected-Mode' component (with no access to BIOS but full access to memory and devices). The 'Real-Mode' component of the Linux Kernel 'probes' BIOS (via BIOS interrupt calls) to build a list of fundamental information (primarily memory layout) in memory and invokes the 'Protected Mode' component passing a memory address of the information collected (from BIOS) in Real-Mode My intent is for U-Boot to replace the 'Real-Mode' component of Linux and build the necessary information and directly invoke the 'Protected Mode' component of the Linux Kernel (bypassing Real-Mode entirely). Because an embedded board designer designs all part of the system (RAM, ROM, device memory and interrupt maps etc), they can build this information without needing BIOS. > > Does uboot execute option rom, such as the option rom for PCI/PCIE video > controller, SATA controller, network controller, etc.? No (although you could write drivers to do so). I think U-Boot may already have drivers for common hardware already. Because of the GPL, any device supported by Linux can be ported to U-Boot be taking the existing Linux driver code (does need to be modified specifically for U-Boot, but all the hard work has already been done) > > What are the x86 CPU and board that can run uboot-x86? Currently U-Boot supports the AMD SC520 'Elan' embedded processor. I am about to port U-Boot to the VIA EPIA EN1200/1500 boards > > Is there a porting guide if I want to port uboot-x86 to another x86 board? > Unfortunately not > Can uboot-x86 boot x86 PC Linux like Fedora, Ubuntu, etc.? U-Boot cannot boot a PC. The VIA EPIA platform is marketed as 'Embedded' but it is (kind-of) a PC motherboard. PC's are very diverse - BIOS is intended to create an abstraction between the software and the hardware to some extent. To boot a PC, U-Boot would need to replace the BIOS and all the abstraction that entails which would, essentially, mimic coreboot (i.e. implementing such 'genericness' would be a complete waste of time) > > If uboot-x86 can boot x86 PC Linux, what stop it from booting Windows > (at least non-ACPI kernel WIndows)? U-Boot can boot other OS's. I think some have even booted Windows CE (the embedded version of windows) > > Without in13h in uboot-x86, how MBR/grub/lilo load Linux image from > storage such as SATA, SD, etc? Most embedded systems use Flash memory to store the filesystem. U-Boot has drivers to access file systems on MTD (Flash) devices. U-Boot also has a wide variety of driver to provide access to various storage devices (as well as network adapters, Serial ports, USB, video, PCMCIA etc) > > I am looking for uboot, not only for x86 PC, but also for other x86 > embedded OS. If you are booting a generic, off-the-shelf PC motherboard (Gigabyte, Tyan, Asus etc) then look at coreboot. If you are creating your own hardware design, use U-Boot > > Thanks, > SK > > > On Sat, Aug 21, 2010 at 9:42 AM, Graeme Russ <graeme.russ(a)gmail.com > <mailto:graeme.russ@gmail.com>> wrote: > > Hi SK, > > On 20/08/10 17:42, sk ong wrote: > > Hi, > > > > I notice there is u-boot for x86 architecture in the denx site. I > wonder > > whether the u-boot-x86 has the legacy BIOS services, such as > dispatching > > PCI/PCIE device option rom such as video, SATA, etc. Does it have > int13, > > int15 etc. services for x86 Linux to call during booting phase. > > The x86 port has an (extremely) limited BIOS primarily to provide > INT12 and > INT15 for the purpose of determining memory size during the Linux > Real-Mode > startup procedure. > > I don't think that Linux actually needs BIOS other than during the > initial > Real-Mode bootstrap. In an embedded environment, the board designer > knows > all the information the BIOS would otherwise provide. My goal is to > remove > the BIOS functionality from U-Boot and use the Protected-Mode entry > point > of the Linux kernel and avoid the switching back-and-forth between > Real and > Protected Modes > > It sounds like you might be looking at using U-Boot for booting a > x86 PC. > If this is the case, maybe you should take a look at coreboot > (http://www.coreboot.org/) > > Regards, > > Graeme > >

3 4

[U-Boot] Standalone application using saveenv
by Hans Tornquist 27 Aug '10

27 Aug '10

Hi, I will write a standalone application and I want to use saveenv from it. But saveenv is not included in exports.h. Are there any intentions to add saveenv function to exports.h in later U-boot releases? I don't want the standalone application to be a GPL program. What I understand when I have read some mailing list threads it is not allowed by myself to add new functions to be exported through the jump table without the standalone application must be a GPL program. What I mean with new functions are functions which already exists in U-boot but not already included in exports.h file, for example saveenv. Best regards /Hans Törnquist

1 0

Re: [U-Boot] Non-experimental U-Boot compilation
by Xu, Hong 27 Aug '10

27 Aug '10

Hi, > Dear all, > I am using the AT91SAM9G20EK kit and want to port Linux on this. Actually Atmel has already done this, see http://www.linux4sam.org > the AT91SAM9260ek configuration as it seems the closest. The problem is after > building the U-boot with the sources for this board, generating the .bin, > loading and a power on reset (POR), there isn't a command prompt exposed > (u-boot>). After POR, 1 1 2 1 1 2 continuosly prints on the hyperterminal. I > read from AT91.com that this is the expected behavior for the demo version. Yes, this is the expected behaviour for the demo package. When you see this, it means you do not boot from the media where you burn your U-Boot into. > What is rge procedure to get the prompt ? Are there any separate configuration > settings? AT91SAM9G20EK are well supported by both mainline code and Atmel's current binary. ( u-boot 1.3.4, a little bit old) For detailed steps to run U-Boot/Linux on your board, still, goto http://www.linux4sam.org BR, Eric

2 2

[U-Boot] [PATCH 1/2] I2C: add Marvell TWSI simple driver
by Albert Aribaud 27 Aug '10

27 Aug '10

This driver is for the Marvell TWSI/I2C module found in the orion and kirkwood families among others. Signed-off-by: Albert Aribaud <albert.aribaud(a)free.fr> --- While the 'kirkwood_i2c' driver for the Marvell TWSI module is already available in u-boot, this one is 25% smaller, less complex (no state machine) and much faster (i2c probe on an ED Mini V2 takes no noticeable time vs. half a second). drivers/i2c/Makefile | 1 + drivers/i2c/mvtwsi.c | 419 ++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 420 insertions(+), 0 deletions(-) create mode 100644 drivers/i2c/mvtwsi.c diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile index d2c2515..73c415d 100644 --- a/drivers/i2c/Makefile +++ b/drivers/i2c/Makefile @@ -30,6 +30,7 @@ COBJS-$(CONFIG_DRIVER_DAVINCI_I2C) += davinci_i2c.o COBJS-$(CONFIG_FSL_I2C) += fsl_i2c.o COBJS-$(CONFIG_I2C_KIRKWOOD) += kirkwood_i2c.o COBJS-$(CONFIG_I2C_MXC) += mxc_i2c.o +COBJS-$(CONFIG_I2C_DRIVER_MVTWSI) += mvtwsi.o COBJS-$(CONFIG_DRIVER_OMAP1510_I2C) += omap1510_i2c.o COBJS-$(CONFIG_DRIVER_OMAP24XX_I2C) += omap24xx_i2c.o COBJS-$(CONFIG_DRIVER_OMAP34XX_I2C) += omap24xx_i2c.o diff --git a/drivers/i2c/mvtwsi.c b/drivers/i2c/mvtwsi.c new file mode 100644 index 0000000..b591328 --- /dev/null +++ b/drivers/i2c/mvtwsi.c @@ -0,0 +1,419 @@ +/* + * Driver for the TWSI (i2c) controller on the Marvell orion5x + * + * Author: Albert Aribaud <albert.aribaud(a)free.fr> + * 2005 (c) MontaVista, Software, Inc. + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, + * MA 02110-1301 USA + */ + +#include <common.h> +#include <i2c.h> +#include <asm/errno.h> +#include <asm/io.h> + +/* + * include a file that will provide CONFIG_I2C_MVTWSI_BASE + * and possibly other settings + */ + +#if defined(CONFIG_ORION5X) +#include <asm/arch/orion5x.h> +#else +#error Driver mvtwsi not supported by SoC or board +#endif + +/* + * TWSI register structure + */ + +struct mvtwsi_registers { + u32 slave_address; + u32 data; + u32 control; + union { + u32 status; /* when reading */ + u32 baudrate; /* when writing */ + }; + u32 extended_slave_address; + u32 reserved[2]; + u32 soft_reset; +}; + +/* + * Control register fields + */ + +#define MVTWSI_CONTROL_ACK 0x00000004 +#define MVTWSI_CONTROL_IFLG 0x00000008 +#define MVTWSI_CONTROL_STOP 0x00000010 +#define MVTWSI_CONTROL_START 0x00000020 +#define MVTWSI_CONTROL_TWSIEN 0x00000040 +#define MVTWSI_CONTROL_INTEN 0x00000080 + +/* + * Status register values -- only those expected in normal master + * operation on non-10-bit-address devices; whatever status we don't + * expect in nominal conditions (bus errors, arbitration losses, + * missing ACKs...) we just pass back to the caller as an error + * code. + */ + +#define MVTWSI_STATUS_START 0x08 +#define MVTWSI_STATUS_REPEATED_START 0x10 +#define MVTWSI_STATUS_ADDR_W_ACK 0x18 +#define MVTWSI_STATUS_DATA_W_ACK 0x28 +#define MVTWSI_STATUS_ADDR_R_ACK 0x40 +#define MVTWSI_STATUS_ADDR_R_NAK 0x48 +#define MVTWSI_STATUS_DATA_R_ACK 0x50 +#define MVTWSI_STATUS_DATA_R_NAK 0x58 /* our NAK, not the slave's */ +#define MVTWSI_STATUS_IDLE 0xF8 + +/* + * The single instance of the controller we'll be dealing with + */ + +static struct mvtwsi_registers *twsi = + (struct mvtwsi_registers *) CONFIG_I2C_MVTWSI_BASE; + +/* + * Returned statuses are 0 for success and nonzero otherwise. + * Currently, cmd_i2c and cmd_eeprom do not interpret an error status. + * Thus to ease debugging, the return status contains some debug info: + * - bits 31..24 are an error class: 0x01 is timeout, 0x02 is 'status mismatch'. + * - bits 23..16 are the last value of the control register. + * - bits 15..8 are the last value of the status register. + * - bits 7..0 are the expected value of the status register. + */ + +#define MVTWSI_ERROR_WRONG_STATUS 0x01 +#define MVTWSI_ERROR_TIMEOUT 0x02 + +#define MVTWSI_ERROR(ec,lc,ls,es) ( ( (ec << 24) & 0xFF000000) | \ + ( (lc << 16) & 0x00FF0000) | ( (ls<<8) & 0x0000FF00) | (es & 0xFF) ) + +/* + * Wait for IFLG to raise, or return 'timeout'; then if status is as expected, + * return 0 (ok) or return 'wrong status'. + */ + +static int twsi_wait(int expected_status) +{ + int control,status; + int timeout = 1000; + do { + control = readl(&twsi->control); + if (control & MVTWSI_CONTROL_IFLG) { + status = readl(&twsi->status); + if (status==expected_status) + return 0; + else + return MVTWSI_ERROR(MVTWSI_ERROR_WRONG_STATUS,control, status, + expected_status); + } + udelay(10); + } while (timeout--); + status = readl(&twsi->status); + return MVTWSI_ERROR(MVTWSI_ERROR_TIMEOUT,control,status,expected_status); +} + +/* + * These flags are ORed to any write to the control register + * They allow global setting of TWSIEN and ACK. + * By default none are set. + * twsi_start() sets TWSIEN (in case the controller was disabled) + * twsi_recv() sets ACK or resets it depending on expected status. + */ + +static u8 twsi_control_flags = MVTWSI_CONTROL_TWSIEN; + +/* + * Assert the START condition, either in a single I2C transaction + * or inside back-to-back ones (repeated starts). + */ + +static int twsi_start(int expected_status) +{ + /* globally set TWSIEN in case it was not */ + twsi_control_flags |= MVTWSI_CONTROL_TWSIEN; + /* assert START */ + writel(twsi_control_flags | MVTWSI_CONTROL_START, &twsi->control); + /* wait for controller to process START */ + return twsi_wait(expected_status); +} + +/* + * Send a byte (i2c address or data). + */ + +static int twsi_send(u8 byte, int expected_status) +{ + /* put byte in data register for sending */ + writel(byte, &twsi->data); + /* clear any pending interrupt -- that'll cause sending */ + writel(twsi_control_flags, &twsi->control); + /* wait for controller to receive byte and check ACK */ + return twsi_wait(expected_status); +} + +/* + * Receive a byte. + * Global mvtwsi_control_flags variable says if we should ack or nak. + */ + +static int twsi_recv(u8 *byte) +{ + int expected_status, status; + /* compute expected status based on ACK bit in global control flags */ + if (twsi_control_flags & MVTWSI_CONTROL_ACK) + expected_status = MVTWSI_STATUS_DATA_R_ACK; + else + expected_status = MVTWSI_STATUS_DATA_R_NAK; + /* acknowledge *previous state* and launch receive */ + writel(twsi_control_flags, &twsi->control); + /* wait for controller to receive byte and assert ACK or NAK */ + status = twsi_wait(expected_status); + /* if we did receive expected byte then store it */ + if (status==0) + *byte = readl(&twsi->data); + /* return status */ + return status; +} + +/* + * Assert the STOP condition. + * This is also used to force the bus back in idle (SDA=SCL=1). + */ + +static int twsi_stop(void) +{ + int control,status; + int timeout = 1000; + /* assert STOP */ + control = MVTWSI_CONTROL_TWSIEN | MVTWSI_CONTROL_STOP; + writel(control, &twsi->control); + /* wait for idle condition. There won't be an IFLG so we cannot use twsi_wait(). */ + do { + status = readl(&twsi->status); + if (status==MVTWSI_STATUS_IDLE) + return 0; + udelay(10); + } while (timeout--); + control = readl(&twsi->control); + return MVTWSI_ERROR(MVTWSI_ERROR_TIMEOUT,control,status,MVTWSI_STATUS_IDLE); +} + +/* + * Ugly formula to convert m and n values to a frequency comes from + * TWSI specifications + */ + +#define TWSI_FREQUENCY(m,n) \ + ( (u8) (CONFIG_SYS_TCLK / (10 * (m + 1) * 2 * (1 << n))) ) + +/* + * These are required to be reprogrammed before enabling the controller + * because a reset loses them. + * Default values come from the spec, but a twsi_reset will change them. + */ + +static u8 twsi_baud_rate = 0x44; +static u8 twsi_actual_speed = TWSI_FREQUENCY(4,4); +static u8 twsi_slave_address = 0; + +/* + * Reset controller. + * Called at end of i2c_init unsuccessful i2c transactions. + * Controller reset also resets the baud rate and slave address, so + * re-establish them. + */ + +static void twsi_reset(void) +{ + /* ensure controller will be enabled by any twsi*() function */ + twsi_control_flags = MVTWSI_CONTROL_TWSIEN; + /* reset controller */ + writel(0, &twsi->soft_reset); + /* wait 2 ms -- this is what the Marvell LSP does */ + udelay(20000); + /* set baud rate */ + writel(twsi_baud_rate, &twsi->baudrate); + /* set slave address even though we don't use it */ + writel(twsi_slave_address, &twsi->slave_address); + writel(0, &twsi->extended_slave_address); + /* assert STOP but don't care for the result */ + (void) twsi_stop(); +} + +/* + * I2C init called by cmd_i2c when doing 'i2c reset'. + * Sets baud to the highest possible value not exceeding requested one. + */ + +void i2c_init(int requested_speed, int slaveadd) +{ + int tmp_speed, highest_speed, n, m; + int baud = 0x44; /* value at controller reset */ + /* use actual speed to collect progressively higher values */ + highest_speed = 0; + /* compute m,n setting for highest speed not above requested speed */ + for (n = 0; n < 8; n++) { + for (m = 0; m < 16; m++) { + tmp_speed = TWSI_FREQUENCY(m,n); + if (tmp_speed <= requested_speed) + if (tmp_speed > highest_speed) { + highest_speed = tmp_speed; + baud = (m << 3) | n; + } + } + } + /* save baud rate and slave for later calls to twsi_reset */ + twsi_baud_rate = baud; + twsi_actual_speed = highest_speed; + twsi_slave_address = slaveadd; + /* reset controller */ + twsi_reset(); +} + +/* + * Begin I2C transaction with expected start status, at given address. + * Common to i2c_probe, i2c_read and i2c_write. + * Expected address status will derive from direction bit (bit 0) in addr. + */ + +static int i2c_begin(int expected_start_status, u8 addr) +{ + int status, expected_addr_status; + /* compute expected address status from direction bit in addr */ + if (addr & 1) /* reading */ + expected_addr_status = MVTWSI_STATUS_ADDR_R_ACK; + else /* writing */ + expected_addr_status = MVTWSI_STATUS_ADDR_W_ACK; + /* assert START */ + status = twsi_start(expected_start_status); + /* send out the address if the start went well */ + if (status == 0) + status = twsi_send(addr, expected_addr_status); + /* return ok or status of first failure to caller */ + return status; +} + +/* + * End I2C transaction, of which the current status is given. + * Common to i2c_probe, i2c_read and i2c_write. + */ + +static int i2c_end(int status) +{ + /* if transaction went well so far, try to assert a STOP */ + /*if (status == 0)*/ + twsi_stop(); + /* if anything went wrong (including the STOP we tried), do a reset */ + /*else + twsi_reset();*/ + /* return ok or status of first failure to caller */ + return status; +} + +/* + * I2C probe called by cmd_i2c when doing 'i2c probe'. + * Begin read, nak data byte, end. + */ + +int i2c_probe(uchar chip) +{ + u8 dummy_byte; + int status; + /* begin i2c read */ + status = i2c_begin(MVTWSI_STATUS_START, (chip << 1) | 1 ); + /* dummy read was accepted: receive byte but NAK it. */ + if (status==0) + status = twsi_recv( &dummy_byte); + /* We expected either 0 (ok) or MVTWSI_STATUS_ADDR_R_NAK */ + return i2c_end( (status==MVTWSI_STATUS_ADDR_R_NAK) ? 0: status); +} + +/* + * I2C read called by cmd_i2c when doing 'i2c read' and by cmd_eeprom.c + * Begin write, send address byte(s), begin read, receive data bytes, end. + */ + +int i2c_read(u8 dev, uint addr, int alen, u8 *data, int length) +{ + int status; + /* begin i2c write to send the address bytes */ + status = i2c_begin(MVTWSI_STATUS_START, (dev << 1) ); + /* send addr bytes */ + while ( (status==0) && alen--) + status = twsi_send(addr >> (8*alen), MVTWSI_STATUS_DATA_W_ACK); + /* NOTE: should we send a stop before a start? That's eeprom-level stuff */ + /* begin i2c read to receive eeprom data bytes */ + if (status == 0) + status = i2c_begin(MVTWSI_STATUS_REPEATED_START, (dev << 1) | 1); + /* prepare ACK if at least one byte must be received */ + if (length > 0) + twsi_control_flags |= MVTWSI_CONTROL_ACK; + /* now receive actual bytes */ + while ( (status==0) && length-- ) { + /* reset NAK if we if no more to read now */ + if (length == 0) + twsi_control_flags &= ~MVTWSI_CONTROL_ACK; + /* read current byte */ + status = twsi_recv(data++); + } + /* end i2c transaction */ + return i2c_end(status); +} + +/* + * I2C write called by cmd_i2c when doing 'i2c write' and by cmd_eeprom.c + * Begin write, send address byte(s), send data bytes, end. + */ + +int i2c_write(u8 dev, uint addr, int alen, u8 *data, int length) +{ + int status; + /* begin i2c write to send the eeprom adress bytes then data bytes */ + status = i2c_begin(MVTWSI_STATUS_START, (dev << 1) ); + /* send addr bytes */ + while ( (status==0) && alen--) + status = twsi_send(addr >> (8*alen), MVTWSI_STATUS_DATA_W_ACK); + /* send data bytes */ + while ( (status==0) && (length-->0) ) + status = twsi_send(*(data++), MVTWSI_STATUS_DATA_W_ACK); + /* end i2c transaction */ + return i2c_end(status); +} + +/* + * Bus set/get routines: we only support bus 0. + */ + +int i2c_set_bus_num(unsigned int bus) +{ + if (bus > 0) { + return -1; + } + return 0; +} + +unsigned int i2c_get_bus_num(void) +{ + return 0; +} -- 1.7.1

5 12