I am trying to design a new board based on the AT91SAM9260 processor and had a few questions :
- Any idea if the DP83848CVV Phyter from National Semi would work with this proc. (it supports both RMII and MII)
- I am not clear as to point of having both 16-bit NAND flash and serial DataFlash as shown in the AT91SAM9260-EK. It seems like one could use either flash chips for running linux, presumeably either one should be enough on a board, right? I was hoping to use only a single
8-pin serial flash chip on my board.
-From what I understood so far, if BMS is set to 0 the proc loads data (bootloader - uboot) off the dataflash into the SRAM and starts executing, and then uboot somehow loads up the kernel. I can't seem to figure out the exact process though, is there a link to a flow chart somewhere which can explain it.
- toolchain etc : is there a clear guide somewhere which explains a step by step process of compiling/packaging and running linux on that board. Atmel has a bunch of links to linuxlink but its an expensive fee.
Okay so i think I have a better idea now. I will use the DataFlash in my current design (is fast/small/cheap enough for me) but will also leave pads for a nand flash, if atmel ever stops making the Dataflash parts in the future.
about using the Debug UART : how will this work if I had a brand new chip (blank flash), or for whatever reason I had to reflash the device completely ?
Any clues about the toolchain? clear guides on how to compile a custom kernel for this board?
When you get to software debugging, the software engineers will hate you for not putting on a JTAG connector. The connector costs pennies. You will recover the cost of every connector you ever use on your first software problem.
The chip specification was modified to support this part, but it has nto been tested in practice by Atmel. The advantage oft he PHYTER is the clock output which can be used to drive the main clock of the AT91SAM9260. Thus you can build a system with only one crystal.
The crystal is connected to the PHYTER which probvids the clock to the SAM9260, and by setting OSCSEL to use the internal R/C oscillator, you do not need the 32 kHz crystal.
The recommended use of the bootROM is to have an SPI connector which uses chip select 0 and use chip select 1 for the internal dataflash.
This allows easy production, since you can have a test system containing a dataflash and to factory program, you only connect a flatcable between the SPI connector and the test system.
The SAM9260 will then find a valid image in the test system dataflash, and will boot from that. The code will then copy the contents of the test system dataflash to the internal dataflash on chip select 1. If I were you I would use chip select 2 for a second dataflash. There will be pin compatible 16 and 32 MB dataflash chips in the future.
If BMS is set to "1" (not "0") , the CPU starts executing from the internal bootROM. This will search SPI0.NPCS0 and then SPI0.NPCS1 and then NAND flash for a valid image. An image is deemed valid, if a valid exception table is found.
If an image is found, it is copied into 4 kB of internal SRAM and the image is executed.
The typical image is "at91-bootstrap".
"at91-bootstrap" will initialize the SDRAM and copy u-Boot from 0x8000 in the dataflash to SDRAM, and jump to the start of U-boot.
Within U-boot, you can download linux and root file system to dataflash. Before linux boot, the "bootcmd" will load the linux kernel from flash to SDRAM and if a ramdisk is used, this will be loaded as well. If JFFS2 is used, this is not neccessary.
Try buildroot.uclibc.org to build a root file system Have my own version at
as a project. but there are a few issues that needs to be fixed still.
where does it talk about copying data between serial flash memories in the datasheet? Are you suggesting the following scenario : the micro will read data from the SD card connected on SPI0_NPCS0 and directly copy it over to the onboard SPI Dataflash on SPI0_NPCS1. So the next time we boot, the board dataflash will contain the valid image ready to go?