From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jonathan Dumaresq Date: Thu, 10 Jan 2008 09:57:18 -0500 Subject: [Buildroot] How is the RM9200 status of buildroot ? In-Reply-To: <027601c8531e$73c08420$6103170a@atmel.com> References: <05f701c85243$52e4c530$6e00a8c0@JONATHAN><01ce01c8524a$65be7fa0$080514ac@atmel.com><000001c852cc$8bd69100$6e00a8c0@JONATHAN><014901c852ed$4ce2d500$6103170a@atmel.com> <009e01c852f8$fe7078d0$6e00a8c0@JONATHAN> <027601c8531e$73c08420$6103170a@atmel.com> Message-ID: <006801c85399$1868c440$6e00a8c0@JONATHAN> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net 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 at 81.80.104.162/