[Buildroot] How is the RM9200 status of buildroot ?

Jonathan Dumaresq jdumaresq at cimeq.qc.ca
Thu Jan 10 14:57:18 UTC 2008


Hi,

Since this board was designed some time ago, we have choose to use the
rm9200 because we already have some test board with this chip. This is only
for educational purpose. So we wan to explore how an arm9 work. Debugging
methode etc. 

So if we go into a commercial project, we will probably use the AVR32. Bu
this sould be the same process of debugging .

Again 

I'll appreciate your valuable information

Jonathan

-----Message d'origine-----
De : Ulf Samuelsson [mailto:ulf.samuelsson at atmel.com] 
Envoyé : 9 janvier 2008 18:58
À : Jonathan Dumaresq; buildroot at uclibc.org
Objet : Re: [Buildroot] How is the RM9200 status of buildroot ?

Great information ulf,

I already have my board in hand. I done some basic testing with a jtag
interface with openocd. I can talk to the cpu this is a good news in some
way. Then I try to talk to the flash and got some response. So I think I'm
in good position to continue testing my board. 

What I will do next is to try to use the jtag interface and write to sdram. 

As for why we use parallel flash ... I' don't know. I have access to sd
memory also. This can be a good thing ? 

==> You should look at the Atmel website for dataflash = AT45DB642D.
        Also, choosing the AT91RM9200 at this point of time may be a mistake
        The AT91SAM9260 has about the same functionality,
        fixes some bugs, and is cheaper.
        The BootROM has a failsafe mode, which I am really fond of (I
defined it :-)
        There will be a pin compatible part (AT91SAM9260A) running at 400
MHz.
        Samples are going to be shipped to a few customers about now, rest
        of the customers has to wait.
        There is also a pin compatible flash version AT91SAM92XE 
        (First ARM flash microcontroller at 200 MHz?)    - Available real
soon now...

        The only reason to start designing with the AT91RM9200 is that
        you want to have the ETM (Embedded Trace Module) or you
        are interested in the lower power consumption of the ARM920T
hardcore
        in the AT91RM9200 compared to the ARM926EJ-S in the AT91SAM9260.
        The AT91RM9200 also have a few more I/O pins than the SAM9260 due
        to its 256 BGA package compared to the 217 BGA in the SAM9260.

        This is my personal opinion, (as I usually indicate in the
signature)
        Both AT91RM9200 and the SAM9260 will be produced for a long time
        so availability has nothing to do with the decision.




I think we based our design on the EK board. I will have to talk about this
to the engineer that builds up the schematics. 

Again, 

I'll appreciate your information.

Jonathan

-----Message d'origine-----
De : Ulf Samuelsson [mailto:ulf at atmel.com] 
Envoyé : 9 janvier 2008 13:27
À : Jonathan Dumaresq; buildroot at uclibc.org
Objet : Re: [Buildroot] How is the RM9200 status of buildroot ?

I would like to thanks you guys to point me to the right thing. 

Here a little bit of information about our board.

CPU = RM9200
FLASH = AT49BV642D connected in a 16bit data bus
SDRAM = 2 x MT48LC8M16A2P-7E from Micron Technology. We have 2 SDRAM
connected in parallel with 16 bits databus. I think we based this design on
the dk board supplies by atmel. 

Since a relatively new to all of the arm9 cpu + linux, I think I will have
some fun to get all of this working :)

I would like to know if it is possible to do some basinc testing on my board
to know if my memories setup is working correctly before going to far with
linux etc. ? I have acces to a jtag interface if this can help. 

==> Traditionally, the process of getting an AT91RM9200 to run from a 
        parallel flash is to set BMS high to boot from the bootROM,
        Download "loader.bin" using X-Modem to the internal SRAM,
        "loader.bin" will start a new x-modem session and you use this
        to download "boot.bin", which gets programmed into the first sector
        of the parallel flash.
        You will then program the u-boot.gz into a nearby sector of the
flash.

        After a reset, the board will execute "boot.bin" which will 
        decompress u-boot.gz into SDRAM and jump to the start of the U-boot.

        You will need to check with your local contact to get source of
"loader.bin"
        and "boot.bin". They were originally compiled by gcc-2.95.3 and
        using gcc-3.x.x does not work as far as I know.
        I am not aware of anyone trying with gcc-4.x.x.

        boot.bin/loader.bin binaries might work, but they were written for
        the somewhat compatible AT49BV6416.

        There is not a lot of support from Atmel on booting the AT91SAM926x
chips
        from a parallel flash, but many customers has succeeded in getting
        them to run anyway.
        Hopefully, next generation of AT91Bootstrap will support parallel
flash,
        but the AT91RM9200 is not supported at all by the bootstrap.

        Why parallel flash in the first place???
        
        Please be aware that the AT91RM9200DK has some critical flaws.
        The AT91RM9200EK was designed to get rid of those flaws.
        Again, discuss with your local Atmel FAE to have your schematics
reviewed.

Best Regards
Ulf Samuelsson



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:
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
AVR32 Applications Group        mailto:avr32 at atmel.com
http://www.avrfreaks.net/;            http://avr32linux.org/
http://www.at91.com/ ;                ftp://at91dist:distrib@81.80.104.162/




More information about the buildroot mailing list