Question about U-Boot in general and the AT91RM9200 in particular

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 <[email protected]>
Subject: Re: [U-Boot-Users] Question about U-Boot in general and the
AT91RM9200 in particular
To: Javier Ruere <[email protected]>
Cc: u-boot-users at lists.sourceforge.net
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1

Quoted 4 lines · In message <[email protected]> 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.

Quoted 4 lines

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 <[email protected]>
Subject: [U-Boot-Users] hazelnut negligently
To: u-boot-users at lists.sourceforge.net
Message-ID: <[email protected]>
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" <[email protected]>
Subject: Re: [U-Boot-Users] [PATCH] Fixed cfi flash read uchar bug.
To: "Zhang Wei-r63237" <[email protected]>, "Wolfgang Denk"

	<[email protected]>
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

Quoted 92 lines

-----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,

Quoted 1 line · Wolfgang Denk

Now this is what I want to understand. What exactly is the

"potential

Quoted 2 lines

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.

Quoted 1 line

Can you please point out which specific part of the Linux

MTD code you

Quoted 2 lines

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;

Quoted 4 lines

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.

Quoted 1 line

For me this is an indication that the problem is actually

somewhere

Quoted 1 line

else, and while your modification might actually fix the

symptoms, I

Quoted 1 line

doubt that it is the correct fix - or the correct problem.

If your

Quoted 2 lines

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

Quoted 7 lines

--------------------------------------------------------------
-----------
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

Quoted 5 lines

_______________________________________________
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
******************************************