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

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

[Javier Ruere]

Hello everyone,
	I have been working with an AT91RM9200-EK board for a couple of months now 
and we are about to make our own custom board. Lately I started investigating 
about U-Boot and how it works in this board and, though I have found a lot of 
bits of information, I am still quite confused.
	I would like to ask about U-Boot running from RAM. On the one hand, I have 
seen links [1] and [2] that say that it should not be done but, on the other 
hand, from the documentation from Atmel [3] I see it _is_ being run from RAM. 
I have done this myself with u-boot 1.1.6 defining CONFIG_SKIP_LOWLEVEL_INIT 
at the top of include/configs/at91rm9200dk.h, otherwise it wouldn't work. I 
found out about this define here [4]
	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 the 
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

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

[Wolfgang Denk]

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

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

[Ivan Kuten]

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@denx.de>
> Subject: Re: [U-Boot-Users] Question about U-Boot in general and the
> 	AT91RM9200 in particular
> To: Javier Ruere <javierruere@apexar.com>
> 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 <hbdok@ebookpizzazz.com>
> 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" <Wei.Zhang@freescale.com>
> Subject: Re: [U-Boot-Users] [PATCH] Fixed cfi flash read uchar bug.
> To: "Zhang Wei-r63237" <Wei.Zhang@freescale.com>, "Wolfgang Denk"
> 	<wd@denx.de>
> 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
> ******************************************
>

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

[Marco Cavallini]

Javier Ruere ha scritto:
> Hello everyone,
> 	I have been working with an AT91RM9200-EK board for a couple of months now 
> and we are about to make our own custom board. Lately I started investigating 
> about U-Boot and how it works in this board and, though I have found a lot of 
> bits of information, I am still quite confused.
> 	I would like to ask about U-Boot running from RAM. On the one hand, I have 
> seen links [1] and [2] that say that it should not be done but, on the other 
> hand, from the documentation from Atmel [3] I see it _is_ being run from RAM. 
> I have done this myself with u-boot 1.1.6 defining CONFIG_SKIP_LOWLEVEL_INIT 
> at the top of include/configs/at91rm9200dk.h, otherwise it wouldn't work. I 
> found out about this define here [4]
> 	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 the 
> 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

If you have a NOR flash romboot (boot.bin) is no longer necessary,
maybe this link could help as well :-)

  http://www.koansoftware.com/en/art.php?art=80

Ciao
-- 
Marco Cavallini
Koan s.a.s. - Bergamo - Italia
Embedded and Real-Time Software Engineering
  - Atmel Third Party Consultant
  - Intel PCA Developer Network Member
Tel. +39-(0)35-255.235 - Fax +39-178-223.9748
http://www.KoanSoftware.com  -  http://www.KaeilOS.com

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

[Sascha Erlacher]

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

Hello Ivan,
this is not correct. As Wolfgang points out you can boot directly from NOR
 flash.

It depends on the BootModeSelect (BMS) pin state of the AT91RM9200.
The datasheet states:

"Depending on the BMS pin state at reset and as a function of the remap
 command, the memory
mapped at address 0x0 is different. Before execution of the remap command
the on-chip ROM
(BMS = 1) or the 16-bit non-volatile memory connected to external chip
select zero (BMS = 0) is
mapped into Internal Memory Area 0."

When setting BMS=0 the AT91RM9200 internal boot rom code is not executed.
If the external (NOR) flash contains a valid U-Boot image it will be
executed directly,
and, in case it properly initializes an external SDRAM, will be able to
relocate itself to SDRAM
without going through internal SRAM.

Best regards,
Sascha

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

[Andreas Schweigstill]

Hello!

Sascha Erlacher schrieb:
> this is not correct. As Wolfgang points out you can boot directly from NOR
>  flash.
> 
> It depends on the BootModeSelect (BMS) pin state of the AT91RM9200.

Unfortunately due to errata #37 external NOR flash will be accessed with
zero waitstates, which gives an access time of 20ns, so very fast and
expensive memory has to be used. And there also shouldn't be used any
external address decoders or bus buffers.

So using a serial boot ROM (Dataflash or EEPROM) usually will be the
best solution. Even a very small EEPROM can be suitable because the
program just has to modify bus timing for chip select 0 and jump to the
"slow" parallel Flash memory.

With best regards
Andreas

-- 
Dipl.-Phys. Andreas Schweigstill
Schweigstill IT | Embedded Systems
Schauenburgerstra?e 116, D-24118 Kiel, Germany
Phone: (+49) 431 5606-435, Fax: (+49) 431 5606-436
Mobile: (+49) 171 6921973, Web: http://www.schweigstill.de/

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

[Ulf Samuelsson]

> Hello!
> 
> Sascha Erlacher schrieb:
>> this is not correct. As Wolfgang points out you can boot directly from NOR
>>  flash.
>> 
>> It depends on the BootModeSelect (BMS) pin state of the AT91RM9200.

> Unfortunately due to errata #37 external NOR flash will be accessed with
> zero waitstates, which gives an access time of 20ns, so very fast and
> expensive memory has to be used. And there also shouldn't be used any
> external address decoders or bus buffers.

> So using a serial boot ROM (Dataflash or EEPROM) usually will be the
> best solution. Even a very small EEPROM can be suitable because the
> program just has to modify bus timing for chip select 0 and jump to the
> "slow" parallel Flash memory.

That is also a misunderstanding.
BMS is used to select between booting from internal bootROM (BMS=1)
or external parallell flash (BMS=1).
All new Evaluation Kits from Atmel will use dataflash as its primary boot.
That is why I call this the "default". 

If BMS is set to 0, then the parts will boot from the external parallel flash
and the part will use maximum number of waitstates. Errata #37
does not affect the operation here.

If the AT91RM9200'BMS is set to 1, then the part will boot from
the internal boot ROM and will try the following cases:

1) SPI for dataflash
2) TWI for I2C EEPROM
3) External Bus Interface (EBI) for an 8 bit parallel flash.
    The code that initializes the EBI for this case will set
    the number of waitstates to zero, and no existing flash
    can handle this, so this is non-functional.

The BootROM in the AT91SAM926x chips does not support booting from 
parallel NOR flash chips (but you can set BMS=0).

While it is possible to set BMS=0 and boot from a parallell flash, without copying to 
SDRAM first, it is not generally the smartest way to use the AT91 chips.

Especially the AT91SAM9260 bootROM supports a failsafe programming
mode which will allow you to override the contents of the internal flash,
without any jumper.
This is useful both during production and if you want to do manual field upgrades.

It is possible to build equipment which can be updated by inserting a flashcard
into the equipment, and then you power cycle.
The AT91SAM9260 will then boot from the flash card instead of from the
internal flash, and can copy the contents of the flash card to the internal flash.

It is possible to boot from a secure microcontroller (emulating a dataflash), so that you can 
protect your equipment agains evil users.

You can use the override function also during production.
The part first tries SPI0.CS0 and then SPI0.CS1
Connect a bed of nails tester to the SPI0.CS0 and the internal dataflash
to SPI0.CS1. Then you will boot from the test equipment instead of 
from the (empty) internal dataflash, and the part will program itself.

> With best regards
> Andreas


Best Regards
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57

Technical support when I am not available:
AT89 C51 Applications Group: mailto:micro.hotline at nto.atmel.com
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
FPSLIC Application Group: mailto:fpslic at atmel.com
Best AVR  link: www.avrfreaks.net