From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ivan Kuten Date: Thu, 4 Jan 2007 13:41:19 +0200 (EET) Subject: [U-Boot-Users] Question about U-Boot in general and the AT91RM9200 in particular In-Reply-To: References: Message-ID: <43025.127.0.0.1.1167910879.squirrel@localhost> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello, AT91RM9200 is quite specific in that ROM Boot program copies initial bootloader in SRAM (see ch.13 in AT91RM9200 manual): The main features of the Boot Program are: ? Downloads and runs an application from external storage media into internal SRAM ? Downloaded code size depends on embedded SRAM size thus in any way you must use a small (<12Kb) initial bootloader, which in turn loads u-boot from dataflash or NOR flash in SDRAM. ------------------------------------ Best regards, Ivan Embedded Linux Engineer Promwad - www.promwad.com ------------------------------------ > Hello everyone, > For what I gather from the instructions from Atmel, there is always a > bootloader before U-Boot, loading it from the dataflash, serial port or > Flash > and this could explain why I must define CONFIG_SKIP_LOWLEVEL_INIT, so > that the hardware is not initialized twice. > Would it work to put an uncompressed image of U-Boot at the beginning of > flash memory and let it initialize the board if I don't add the define I > mentioned before? > Thank you all for your time and help. > > Regards, > Javier Ruere > > > [1] > http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/25551/focus=25596 > [2] > http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM > [3] > http://www.atmel.com/dyn/resources/prod_documents/UBootFlashProgramming.zip > [4] > http://www.at91.com/www/phpBB2_mirror/viewtopic.php4?t=1300&highlight=at91rm9200ek+uboot > > > > ------------------------------ > > Message: 2 > Date: Thu, 04 Jan 2007 01:05:25 +0100 > From: Wolfgang Denk > Subject: Re: [U-Boot-Users] Question about U-Boot in general and the > AT91RM9200 in particular > To: Javier Ruere > Cc: u-boot-users at lists.sourceforge.net > Message-ID: <20070104000525.86CB7352636@atlas.denx.de> > Content-Type: text/plain; charset=ISO-8859-1 > > In message <200701031949.26084.javierruere@apexar.com> you wrote: >> >> For what I gather from the instructions from Atmel, there is always a >> bootloader before U-Boot, loading it from the dataflash, serial port or >> Flash > > No, this is NOT correct. If you have NOR flash on your board (which > we consider a standard configuration) then U-Boot can boot directly, > without a primary bootstrap loader. This is the mode of operation you > want to have if your task is to get new hardware running. > >> Would it work to put an uncompressed image of U-Boot at the beginning >> of the >> flash memory and let it initialize the board if I don't add the define I >> mentioned before? > > If "flash memory" means NOR flash, then yes, this will work fine. > Actually this is the recommended (by me) mode of operation. > > Best regards, > > Wolfgang Denk > > -- > Software Engineering: Embedded and Realtime Systems, Embedded Linux > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de > "An organization dries up if you don't challenge it with growth." > - Mark Shepherd, former President and CEO of Texas Instruments > > > > ------------------------------ > > Message: 3 > Date: Thu, 4 Jan 2007 02:03:03 +0100 > From: Stanley F. Lynn > Subject: [U-Boot-Users] hazelnut negligently > To: u-boot-users at lists.sourceforge.net > Message-ID: <459C5247.6040803@ebookpizzazz.com> > Content-Type: text/plain; charset="us-ascii" > > An HTML attachment was scrubbed... > URL: > http://sourceforge.net/mailarchive/forum.php?forum=u-boot-users/attachments/20070104/a661d9ab/attachment.html > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: contravention.gif > Type: image/gif > Size: 8361 bytes > Desc: not available > Url : > http://sourceforge.net/mailarchive/forum.php?forum=u-boot-users/attachments/20070104/a661d9ab/attachment.gif > > ------------------------------ > > Message: 4 > Date: Thu, 4 Jan 2007 10:07:18 +0800 > From: "Zhang Wei-r63237" > Subject: Re: [U-Boot-Users] [PATCH] Fixed cfi flash read uchar bug. > To: "Zhang Wei-r63237" , "Wolfgang Denk" > > Cc: u-boot-users at lists.sourceforge.net > Message-ID: > <46B96294322F7D458F9648B60E15112C03EE48@zch01exm26.fsl.freescale.net> > Content-Type: text/plain; charset="utf-8" > > Hi, Wolfgang, > > Any feedback about this mail? > > Thanks! > > Zhang Wei > >> -----Original Message----- >> From: u-boot-users-bounces at lists.sourceforge.net >> [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf >> Of Zhang Wei >> Sent: Tuesday, December 26, 2006 2:05 PM >> To: Wolfgang Denk >> Cc: u-boot-users at lists.sourceforge.net >> Subject: Re: [U-Boot-Users] [PATCH] Fixed cfi flash read uchar bug. >> >> Hi, Wolfgang, >> >> Wolfgang Denk wrote: >> > Now this is what I want to understand. What exactly is the >> "potential >> > problem"? >> > >> That's the issue in the flash 'Spinsion S29GL064M90TFIR6' with x16 >> connection. After running flash_read_jedec_ids(), any follow >> CFI query >> command will get the data with high 8bit = 0xff, but the low 8bit is >> valid. And if we only read low 8bit, we'll get the 0xff too. In >> addition, the second follow CFI query command has no that >> issue. So, I >> read the full 16bit date and only take the valid low 8bit. >> > Can you please point out which specific part of the Linux >> MTD code you >> > mean? And which version of the code? >> > >> The reference codes is in Linux Kernel 2.6.19. >> >> drivers/mtd/chips/cfi_probe.c: cfi_chip_setup() calls: >> int num_erase_regions = cfi_read_query(map, base + (0x10 + >> 28)*ofs_factor); >> include/linux/mtd/cfi.h: cfi_read_query() calls: >> map_word val = map_read(map, addr); >> include/linux/mtd/map.h defines: >> #define map_read(map, ofs) inline_map_read(map, ofs) >> include/linux/mtd/map.h: function inline_map_read() body: >> static inline map_word inline_map_read(struct map_info *map, unsigned >> long ofs) >> { >> map_word r; >> >> if (map_bankwidth_is_1(map)) >> r.x[0] = __raw_readb(map->virt + ofs); >> else if (map_bankwidth_is_2(map)) >> r.x[0] = __raw_readw(map->virt + ofs); >> else if (map_bankwidth_is_4(map)) >> r.x[0] = __raw_readl(map->virt + ofs); >> #if BITS_PER_LONG >= 64 >> else if (map_bankwidth_is_8(map)) >> r.x[0] = __raw_readq(map->virt + ofs); >> #endif >> else if (map_bankwidth_is_large(map)) >> memcpy_fromio(r.x, map->virt+ofs, map->bankwidth); >> >> return r; >> } >> And the 'map_word' definition in include/linux/mtd/map.h is below: >> typedef union { >> unsigned long x[MAX_MAP_LONGS]; >> } map_word; >> >> > I have to admit that I don't really understand this. I would not be >> > surprised that some statement like this can be found in some chip >> > errata, but I would like to know this for certain first. >> > >> I only find one clue from 'Spinsion S29GL064M90TFIR6' specification, >> which is the comment 'Data bits DQ15?DQ8 are don?t care. ' >> for 'RESET' >> command. And the comment has not found in some other AMD, >> Spinsion chips >> specifications. >> > For me this is an indication that the problem is actually >> somewhere >> > else, and while your modification might actually fix the >> symptoms, I >> > doubt that it is the correct fix - or the correct problem. >> If your >> > explanation was right, this should not depend on compiler versions. >> > >> >> This is a real weird issue. The compiler is also a factor. Chris's >> different compilers get the different results. In fact, the same gcc >> with different size codes will also get different results. >> >> Thanks! >> >> Best Regards, >> Zhang Wei >> >> >> -------------------------------------------------------------- >> ----------- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the >> chance to share your >> opinions on IT & business topics through brief surveys - and earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge > &CID=DEVDEV >> _______________________________________________ >> U-Boot-Users mailing list >> U-Boot-Users at lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/u-boot-users >> > > ------------------------------ > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > ------------------------------ > > _______________________________________________ > U-Boot-Users mailing list > U-Boot-Users at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users > > > End of U-Boot-Users Digest, Vol 8, Issue 5 > ****************************************** >