Actually she asked me to mail Regards, Afzal Nadirshah
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Wednesday, February 18, 2009 4:22 PM To: [email protected] Subject: U-Boot Digest, Vol 9, Issue 217 Send U-Boot mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit http://lists.denx.de/mailman/listinfo/u-boot or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of U-Boot digest..." Today's Topics: 1. Re: [PATCH] 7/12 Multiadapter/multibus I2C, drivers part 4 (Wolfgang Denk) 2. Re: RAM Probing for ads5121rev4 (Wolfgang Denk) 3. AT91RM9200 U-Boot can not load initrd from flash (Dmitry K) 4. Re: U-Boot Makefile question (Frank Svendsb?e) 5. what are the configurations needed for new board (ABIRAMA SUNDARI) 6. which file have memory map information (ABIRAMA SUNDARI) 7. Re: flash configuration in u-boot (zix) 8. Re: flash configuration in u-boot (ABIRAMA SUNDARI) 9. Re: AT91RM9200 U-Boot can not load initrd from flash (Wolfgang Denk) 10. [U-BOOT][PATCH 1/4] mflash : Change MG_BASE define to inline function (unsik Kim) ---------------------------------------------------------------------- Message: 1 Date: Wed, 18 Feb 2009 09:55:16 +0100 From: Wolfgang Denk <[email protected]> Subject: Re: [U-Boot] [PATCH] 7/12 Multiadapter/multibus I2C, drivers part 4 To: [email protected] Cc: U-Boot user list <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1 Dear Heiko, In message <[email protected]> you wrote: > > >> But is is possible to use that code when running from flash, if > >> this current pointer is writeable ... > > > > Yes, it is possible, but then - ther eis no need for it. > > For what is no need? For dynamic reconfiguration of I2C busses before relocation. 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: [email protected] Pig: An animal (Porcus omnivorous) closely allied to the human race by the splendor and vivacity of its appetite, which, however, is in- ferior in scope, for it balks at pig. - Ambrose Bierce ------------------------------ Message: 2 Date: Wed, 18 Feb 2009 10:01:33 +0100 From: Wolfgang Denk <[email protected]> Subject: Re: [U-Boot] RAM Probing for ads5121rev4 To: Emanuele Placidi <[email protected]> Cc: [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1 Dear Emanuele Placidi, In message <[email protected]> you wrote: > > In your opinion it is possible to probe the ram before initialize it? > Unfortunately there are some rev4 which are equipped with different ram > model. > Examples are welcomed. It is a standard feature in U-Boot (and has always been right from the start with PPCBoot nearly 10 years ago) that we auto-detected the memory configuration on the boards, both for RAM and flash. Some boards / architectures did not bother to implement this, but the feature itself is present. The details depend on processor, memory controller properties, specific RAM types used, etc. In case of the Micron/Elpida issue on the ADS5121, that should be not too difficult to solve. 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: [email protected] How many QA engineers does it take to screw in a lightbulb? 3: 1 to screw it in and 2 to say "I told you so" when it doesn't work. ------------------------------ Message: 3 Date: Wed, 18 Feb 2009 12:06:11 +0300 From: Dmitry K <[email protected]> Subject: [U-Boot] AT91RM9200 U-Boot can not load initrd from flash To: <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset="us-ascii"; format="flowed" Hello I've a board quite similar to AT91RM9200DK. I've compiled U-Boot 1.1.2 and 1.3.4 for it and both work fine with images loaded via tftp. When I try to boot same images from flash I got kernel running fine until this: ... No filesystem could mount root, tried: ext2 cramfs vfat romfs Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) Seems like initrd is not copied to RAM by U-Boot. The u-boot environment is: setenv ipaddr 192.168.1.1 setenv serverip 192.168.1.10 setenv bootargs 'root=/dev/ram rw initrd=20a00000,500000 ramdisk_size=8192 console=ttyS0,115200 mem=32M mtdparts=phys_mapped_flash:64K(boot),64K(uboot),2944K(kernel),4608K(initrd),256K(settings),-(unused)' setenv bootcmd "bootm 10020000 10300000" The images are: U-Boot> imls Legacy Image at 10020000: Image Name: K_2009-01-12_13:47:42 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 2443456 Bytes = 2.3 MB Load Address: 20008000 Entry Point: 20008000 Verifying Checksum ... OK Legacy Image at 10300000: Image Name: FS_2009-01-12_14:13:24 Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 3446369 Bytes = 3.3 MB Load Address: 20a00000 Entry Point: 20a00000 Verifying Checksum ... OK What am I missing? -- Dmitry K. ------------------------------ Message: 4 Date: Wed, 18 Feb 2009 10:34:11 +0100 From: Frank Svendsb?e <[email protected]> Subject: Re: [U-Boot] U-Boot Makefile question To: Steven Zedeck <[email protected]> Cc: [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1 Hi Steven, I recommend you to read the GNU make manual. See http://www.gnu.org/software/make/manual/ On Tue, Feb 17, 2009 at 2:43 PM, Steven Zedeck <[email protected]> wrote: > > Hi all, > I am new to u-boot. But I am ramping up pretty fast. My primary issue is > understanding the Makefile syntax. Is there a good tutorial somewhere that > explains how u-boot uses the Makefiles and their syntax? > > For example, I'm having problems understanding what this means in a > Makefile: > > COBJS-$(CONFIG_HAS_DATAFLASH) += at45.o > COBJS-$(CONFIG_FLASH_CFI_DRIVER) += cfi_flash.o > COBJS-$(CONFIG_HAS_DATAFLASH) += dataflash.o > COBJS-$(CONFIG_FLASH_CFI_LEGACY) += jedec_flash.o > COBJS-$(CONFIG_MW_EEPROM) += mw_eeprom.o > > COBJS := $(COBJS-y) > SRCS := $(COBJS:.o=.c) > OBJS := $(addprefix $(obj),$(COBJS)) > > This is from drivers/mtd/Makefile. > > How does COBJS get initially defined upon entry into the Makefile? > > Does at45.o get added to the list of objects to be built only if the > CONFIG_HAS_DATAFLASH flag is set? > > What does the "-" sign mean before the "$" ? > > What does this mean? COBJS := $(COBJS-y) > > I'm sorry for the "dumb" questions. Any help with the understanding of > Makefiles would be greatly appreciated. > > Thanks in advance, > Steve > -- > View this message in context: > http://www.nabble.com/U-Boot-Makefile-question-tp22057574p22057574.html > Sent from the Uboot - Users mailing list archive at Nabble.com. > > _______________________________________________ > U-Boot mailing list > [email protected] > http://lists.denx.de/mailman/listinfo/u-boot > ------------------------------ Message: 5 Date: Wed, 18 Feb 2009 01:42:49 -0800 (PST) From: ABIRAMA SUNDARI <[email protected]> Subject: [U-Boot] what are the configurations needed for new board To: [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset=us-ascii hi all i am new to u-boot.i dont know what are configurations are necessary for me to change for adding new board. by abirama -- View this message in context: http://www.nabble.com/what-are-the-configurations-needed-for-new-board-tp22075338p22075338.html Sent from the Uboot - Users mailing list archive at Nabble.com. ------------------------------ Message: 6 Date: Wed, 18 Feb 2009 01:49:29 -0800 (PST) From: ABIRAMA SUNDARI <[email protected]> Subject: [U-Boot] which file have memory map information To: [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset=us-ascii -- View this message in context: http://www.nabble.com/which-file-have-memory-map-information-tp22075445p22075445.html Sent from the Uboot - Users mailing list archive at Nabble.com. ------------------------------ Message: 7 Date: Wed, 18 Feb 2009 01:50:00 -0800 (PST) From: zix <[email protected]> Subject: Re: [U-Boot] flash configuration in u-boot To: [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset=us-ascii hi everybody, any idea about this? I am desperately looking for an answer in this regard...not finding anything in any forums also...am very new to uboot.. Regards, zix zix wrote: > > Hi, I am configuring u-boot to my board running on arm926ejs core atmel > board. the > flash is Nand512-A, 64Mbyte, configured on 8bit I/O bus. > page size: 512 bytes > block size: 16k > > Now, in u-boot they accept in sectors, but am not having any clue how > this is related to sectors. > > Can anybody please advice what values should I give for > CFG_MAX_FLASH_SECT, CFG_ENV_ADDR(considering if I have to write my env > in 2nd sector, then I need to know the sector size).....the datasheet > doesnot seem to provide information about this..actually, i am trying > to correlate between, pages, blocks and sectors as in flash data sheet > and sector size meant by uboot. And also wondering which flash driver > I should select from u-boot as my board is not listed there. > > Thanks a lot, > zix > -- View this message in context: http://www.nabble.com/flash-configuration-in-u-boot-tp22071753p22075448.html Sent from the Uboot - Users mailing list archive at Nabble.com. ------------------------------ Message: 8 Date: Wed, 18 Feb 2009 02:00:05 -0800 (PST) From: ABIRAMA SUNDARI <[email protected]> Subject: Re: [U-Boot] flash configuration in u-boot To: [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset=us-ascii hi me too new to u-boot .pls tell me what are configuration files i need to chage for new board. by abi zix wrote: > > hi everybody, any idea about this? I am desperately looking for an answer > in this regard...not finding anything in any forums also...am very new to > uboot.. > > Regards, > zix > > > zix wrote: >> >> Hi, I am configuring u-boot to my board running on arm926ejs core atmel >> board. the >> flash is Nand512-A, 64Mbyte, configured on 8bit I/O bus. >> page size: 512 bytes >> block size: 16k >> >> Now, in u-boot they accept in sectors, but am not having any clue how >> this is related to sectors. >> >> Can anybody please advice what values should I give for >> CFG_MAX_FLASH_SECT, CFG_ENV_ADDR(considering if I have to write my env >> in 2nd sector, then I need to know the sector size).....the datasheet >> doesnot seem to provide information about this..actually, i am trying >> to correlate between, pages, blocks and sectors as in flash data sheet >> and sector size meant by uboot. And also wondering which flash driver >> I should select from u-boot as my board is not listed there. >> >> Thanks a lot, >> zix >> > > -- View this message in context: http://www.nabble.com/flash-configuration-in-u-boot-tp22071753p22075622.html Sent from the Uboot - Users mailing list archive at Nabble.com. ------------------------------ Message: 9 Date: Wed, 18 Feb 2009 11:46:46 +0100 From: Wolfgang Denk <[email protected]> Subject: Re: [U-Boot] AT91RM9200 U-Boot can not load initrd from flash To: Dmitry K <[email protected]> Cc: [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1 Dear Dmitry, In message <[email protected]> you wrote: > > I've a board quite similar to AT91RM9200DK. I've compiled U-Boot 1.1.2 > and 1.3.4 for it and both work fine with images loaded via tftp. When I > try to boot same images from flash I got kernel running fine until this: > ... > No filesystem could mount root, tried: ext2 cramfs vfat romfs > Kernel panic - not syncing: VFS: Unable to mount root fs on > unknown-block(1,0) Yes, that's a know limitation (or call it feature, or bug, as you like) of the ARM kernel. > Seems like initrd is not copied to RAM by U-Boot. No, of course it is not copied. Why should we copy the compressed image to ram? That's just a waste of CPU cycles. The kernel can read it from flash as well. Patches for this problem were submitted a few times since kenrel version 2.4.17 or so, and posted and re-posted again and again here on the ML. Search the archives for details. > What am I missing? You're running on ARM... 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: [email protected] 1st Old Man: Gee, its windy today. 2nd Old Man: No it's not... it's Thursday. 3rd Old Man: Yeh, me too. Let's go for a beer. ------------------------------ Message: 10 Date: Wed, 18 Feb 2009 19:51:34 +0900 From: unsik Kim <[email protected]> Subject: [U-Boot] [U-BOOT][PATCH 1/4] mflash : Change MG_BASE define to inline function To: Jean-Christophe PLAGNIOL-VILLARD <[email protected]> Cc: [email protected], [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset=UTF-8; format=flowed Signed-off-by: unsik Kim <[email protected]> --- drivers/block/mg_disk.c | 45 ++++++++++++++++++++++++--------------------- 1 files changed, 24 insertions(+), 21 deletions(-) diff --git a/drivers/block/mg_disk.c b/drivers/block/mg_disk.c index bbfeeda..26b6a80 100644 --- a/drivers/block/mg_disk.c +++ b/drivers/block/mg_disk.c @@ -34,10 +34,13 @@ #define MG_RES_SEC ((CONFIG_MG_DISK_RES) << 1) -#define MG_BASE (host.drv_data->base) - static struct mg_host host; +static inline u32 mg_base(void) +{ + return host.drv_data->base; +} + static block_dev_desc_t mg_disk_dev = { .if_type = IF_TYPE_ATAPI, .part_type = PART_TYPE_UNKNOWN, @@ -122,7 +125,7 @@ static unsigned int mg_wait (u32 expect, u32 msec) reset_timer(); from = get_timer(0); - status = readb(MG_BASE + MG_REG_STATUS); + status = readb(mg_base() + MG_REG_STATUS); do { cur = get_timer(from); if (status & MG_REG_STATUS_BIT_BUSY) { @@ -131,7 +134,7 @@ static unsigned int mg_wait (u32 expect, u32 msec) } else { /* Check the error condition! */ if (status & MG_REG_STATUS_BIT_ERROR) { - err = readb(MG_BASE + MG_REG_ERROR); + err = readb(mg_base() + MG_REG_ERROR); mg_dump_status("mg_wait", status, err); break; } @@ -144,7 +147,7 @@ static unsigned int mg_wait (u32 expect, u32 msec) if (status & MG_REG_STATUS_BIT_DATA_REQ) break; } - status = readb(MG_BASE + MG_REG_STATUS); + status = readb(mg_base() + MG_REG_STATUS); } while (cur < msec); if (cur >= msec) @@ -160,15 +163,15 @@ static int mg_get_disk_id (void) u32 i, err, res; u16 *buff = (u16 *)iobuf; - writeb(MG_CMD_ID, MG_BASE + MG_REG_COMMAND); + writeb(MG_CMD_ID, mg_base() + MG_REG_COMMAND); err = mg_wait(MG_REG_STATUS_BIT_DATA_REQ, 3000); if (err) return err; for(i = 0; i < (MG_SECTOR_SIZE / sizeof(u32)) >> 1; i++) - buff[i] = readw(MG_BASE + MG_BUFF_OFFSET + i * 2); + buff[i] = readw(mg_base() + MG_BUFF_OFFSET + i * 2); - writeb(MG_CMD_RD_CONF, MG_BASE + MG_REG_COMMAND); + writeb(MG_CMD_RD_CONF, mg_base() + MG_REG_COMMAND); err = mg_wait(MG_STAT_READY, 3000); if (err) return err; @@ -235,18 +238,18 @@ static int mg_disk_reset (void) /* soft reset on */ writeb(MG_REG_CTRL_RESET | MG_REG_CTRL_INTR_DISABLE, - MG_BASE + MG_REG_DRV_CTRL); + mg_base() + MG_REG_DRV_CTRL); err = mg_wait(MG_REG_STATUS_BIT_BUSY, 3000); if(err) return err; /* soft reset off */ - writeb(MG_REG_CTRL_INTR_DISABLE, MG_BASE + MG_REG_DRV_CTRL); + writeb(MG_REG_CTRL_INTR_DISABLE, mg_base() + MG_REG_DRV_CTRL); err = mg_wait(MG_STAT_READY, 3000); if(err) return err; - init_status = readb(MG_BASE + MG_REG_STATUS) & 0xf; + init_status = readb(mg_base() + MG_REG_STATUS) & 0xf; if (init_status == 0xf) return MG_ERR_INIT_STAT; @@ -265,13 +268,13 @@ static unsigned int mg_out(unsigned int sect_num, if (err) return err; - writeb((u8)sect_cnt, MG_BASE + MG_REG_SECT_CNT); - writeb((u8)sect_num, MG_BASE + MG_REG_SECT_NUM); - writeb((u8)(sect_num >> 8), MG_BASE + MG_REG_CYL_LOW); - writeb((u8)(sect_num >> 16), MG_BASE + MG_REG_CYL_HIGH); + writeb((u8)sect_cnt, mg_base() + MG_REG_SECT_CNT); + writeb((u8)sect_num, mg_base() + MG_REG_SECT_NUM); + writeb((u8)(sect_num >> 8), mg_base() + MG_REG_CYL_LOW); + writeb((u8)(sect_num >> 16), mg_base() + MG_REG_CYL_HIGH); writeb((u8)((sect_num >> 24) | MG_REG_HEAD_LBA_MODE), - MG_BASE + MG_REG_DRV_HEAD); - writeb(cmd, MG_BASE + MG_REG_COMMAND); + mg_base() + MG_REG_DRV_HEAD); + writeb(cmd, mg_base() + MG_REG_COMMAND); return err; } @@ -293,11 +296,11 @@ static unsigned int mg_do_read_sects(void *buff, u32 sect_num, u32 sect_cnt) /* TODO : u16 unaligned case */ for(j = 0; j < MG_SECTOR_SIZE >> 1; j++) { *(u16 *)buff_ptr = - readw(MG_BASE + MG_BUFF_OFFSET + (j << 1)); + readw(mg_base() + MG_BUFF_OFFSET + (j << 1)); buff_ptr += 2; } - writeb(MG_CMD_RD_CONF, MG_BASE + MG_REG_COMMAND); + writeb(MG_CMD_RD_CONF, mg_base() + MG_REG_COMMAND); MG_DBG("%u (0x%8.8x) sector read", sect_num + i, (sect_num + i) * MG_SECTOR_SIZE); @@ -426,11 +429,11 @@ static int mg_do_write_sects(void *buff, u32 sect_num, u32 sect_cnt) /* TODO : u16 unaligned case */ for(j = 0; j < MG_SECTOR_SIZE >> 1; j++) { writew(*(u16 *)buff_ptr, - MG_BASE + MG_BUFF_OFFSET + (j << 1)); + mg_base() + MG_BUFF_OFFSET + (j << 1)); buff_ptr += 2; } - writeb(MG_CMD_WR_CONF, MG_BASE + MG_REG_COMMAND); + writeb(MG_CMD_WR_CONF, mg_base() + MG_REG_COMMAND); MG_DBG("%u (0x%8.8x) sector write", sect_num + i, (sect_num + i) * MG_SECTOR_SIZE); -- 1.5.6.6 ------------------------------ _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot End of U-Boot Digest, Vol 9, Issue 217 ************************************** http://www.mindtree.com/email/disclaimer.html _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
