[U-Boot-Users] Question about U-Boot in general and the AT91RM9200 in particular

Ivan Kuten ivan.kuten at promwad.com
Thu Jan 4 12:41:19 CET 2007 

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 <wd at denx.de>
> Subject: Re: [U-Boot-Users] Question about U-Boot in general and the
> 	AT91RM9200 in particular
> To: Javier Ruere <javierruere at apexar.com>
> Cc: u-boot-users at lists.sourceforge.net
> Message-ID: <20070104000525.86CB7352636 at atlas.denx.de>
> Content-Type: text/plain; charset=ISO-8859-1
>
> In message <200701031949.26084.javierruere at 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 <hbdok at ebookpizzazz.com>
> Subject: [U-Boot-Users] hazelnut negligently
> To: u-boot-users at lists.sourceforge.net
> Message-ID: <459C5247.6040803 at 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" <Wei.Zhang at freescale.com>
> Subject: Re: [U-Boot-Users] [PATCH] Fixed cfi flash read uchar bug.
> To: "Zhang Wei-r63237" <Wei.Zhang at freescale.com>, "Wolfgang Denk"
> 	<wd at denx.de>
> Cc: u-boot-users at lists.sourceforge.net
> Message-ID:
> 	<46B96294322F7D458F9648B60E15112C03EE48 at 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
> ******************************************
>

More information about the U-Boot mailing list