[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 mpfj@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); }

Dear Mark Jackson,
In message 497EF0C4.3060907@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

Wolfgang Denk wrote:
Dear Mark Jackson,
<snip>
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.
Ah yes ... a much cleaner solution.
In fact, I guess there's no reason to #define any of this, since we're switching on the bpp anyway !!
What if I just remove all the extranous #defines all together ? And just leave the inner "#if defined(CONFIG_ATMEL_LCD_BGR555)" ?
Regards Mark

Dear Mark,
In message 497EFC3E.8050403@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

Wolfgang Denk wrote:
Dear Mark,
In message 497EFC3E.8050403@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

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 = 0x03000002; udelay(200);
/*Below are the calculated DDR2 controller register values*/ ddr->cs0_bnds = 0x0000001f; /* 0x2000 - DDR Chip Select 0 Memory Bounds */ ddr->cs1_bnds = 0x00000000; /* 0x2008 - DDR Chip Select 1 Memory Bounds */ ddr->cs2_bnds = 0x00000000; /* 0x2010 - DDR Chip Select 2 Memory Bounds */ ddr->cs3_bnds = 0x00000000; /* 0x2018 - DDR Chip Select 3 Memory Bounds */
ddr->cs0_config = 0x80814102;/* 0x2080 - DDR Chip Select Configuration */ ddr->cs1_config = 0x00000000;/* 0x2084 - DDR Chip Select Configuration */ ddr->cs2_config = 0x00000000;/* 0x2088 - DDR Chip Select Configuration */ ddr->cs3_config = 0x00000000;/* 0x208c - DDR Chip Select Configuration */
ddr->ext_refrec = 0x00000000;/* 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 = 0x02000000; /* 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.

Hello
2009/1/27, Ajeesh Kumar ajeesh@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.

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:romez777@gmail.com] Sent: Tuesday, January 27, 2009 6:46 PM To: ajeesh@tataelxsi.co.in Cc: Wolfgang Denk; u-boot@lists.denx.de; u-boot@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 ajeesh@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.

Dear "Ajeesh Kumar",
In message VSNLCHNFE0010mG7VAS00055aac@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

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:wd@denx.de] Sent: Tuesday, January 27, 2009 7:21 PM To: ajeesh@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 VSNLCHNFE0010mG7VAS00055aac@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

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

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

Hi All,
Reset problem got fixed, actually the reset command isn't doing a full board reset and just the core was regging resetted. Now its solved. Thanks a lot.
Thanks, Ajeesh Kumar
-----Original Message----- From: Jayakrishnan M [mailto:jay.krishnanm@gmail.com] Sent: Tuesday, January 27, 2009 8:35 PM To: Kumar Gala Cc: ajeesh@tataelxsi.co.in; u-boot@lists.denx.de Subject: 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
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.

Dear "Ajeesh Kumar",
In message VSNLCHNFE00165WYtn400055fef@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
participants (7)
-
Ajeesh Kumar
-
Jayakrishnan M
-
Kumar Gala
-
Mark Jackson
-
Mark Jackson
-
Roman Mashak
-
Wolfgang Denk