Choosing FLASH + RAM options for ARM9 board

Development Boards MicroMod
1

I’m currently working on picking out Flash and RAM for my ARM9 board, which will be based on an EP9315 by Cirrus Logic.

The main concern I’m having is which choosing RAM. I’m going to have an IDE HDD plugged into the thing, but I would like to have the option to not have one and still support a minimal feature set. I would also like, if possible to provide more than the minimal features, which I assume would mean more Flash (OK, I know it would require more Flash…).

NAND Flash is significantly cheaper than NOR, I can get 1GByte (two 4Gbit chips), of NAND for $44, and only about 32MBbytes of NOR for the same price. I know that NAND is faster at writing / erasing, and slower at reading anything but sequential data, and uses a MUX’d A/D interface (of 8 or 16 bit widths)(some have NOR like interfaces), and that NOR is faster at reading and slower at writing / erasing, and provides a standard seperated Address/Data/Control style interface of either 16 or 32 bit widths.

I plan on running linux on the board, and know that there are drivers for the different types of peripherals connected, including flash (and I assume RAM as well).

My questions are as follows:

edit:
0) What are the benefits of the different formations of flash, ie, 16Mx8 vs 8Mx16.

  1. Which type of Flash do I choose and why.

edit again:
1.5) Would it not be cheaper to buy something like a CF or an SD card and use that for the Flash (If I decided to go with NAND, because these use NAND and have the same sort of DMA or NAND interface and are just designed for easy plugability, right?)

  1. Is it possible to not have any external Flash and boot right from the HDD, assuming its plugged it, why (not).

  2. How exactly does the driver / auto flash detect thing work with linux, could I not just connect any kind of flash I wanted, any way I wanted, so long as there was a driver to work with it.

  3. I haven’t gotten to choosing the RAM yet, but that looks like it should be a bit simpler task, anything I should know for when the time comes.

I really appreciate taking the time to read this post and helping me get through this stuff.

-Nate

2

First I want to say that these are just my personal experiences and there may be newer and better NAND implementations.

A big difference with the NOR and NAND devices I have worked with is that you can execute code straight from NOR flash (looks like RAM to your processor) but with NAND flash you need to first copy the code to RAM and execute from there.

I’m not familiar with EP9315, does it support booting from NAND ? If it doesn’t, then you need some flash to store the initial boot code that you can execute from. Some NAND implementations offer for example 1KB boot block that the processor can boot from and this initial code reads the further boot code from the NAND flash to RAM. I know some of the newer ARM9 processors from Atmel and Samsung support booting from NAND.

With many NOR implementations after executing the initial bootloader from the NOR flash the OS is copied to RAM anyway before booting it, like with NAND. With the systems that I have worked with, copying the code from NAND to RAM has been much slower than the same step with NOR flash, meaning much longer boot times.

If this is a small quantity device my suggestion would be to add at least a small amount of NOR flash to store the bootloader for additional flexibility (or check how easy to use NAND boot support your processor might have).

For easy to get stocked prices Digi-Key has 16MBit NOR flash for about $2.6 and 128MBit for $10.

Having the bootloader in this small NOR flash would also allow loading the rest from a HDD or CF/SD card.

With small quantity I’m pretty sure that a SD card + socket is cheaper than soldering NAND chips on the PCB. Of course when your quantities are large enough the bare NAND is cheaper as you don’t need the socket and the additional material the SD card has like the plastic cover.

reklipz:
0) What are the benefits of the different formations of flash, ie, 16Mx8 vs 8Mx16.[/i]

With wider bus width you can move more data in one cycle meaning reading is faster. But with narrower bus width you don't need as many PCB traces saving PCB area and making routing easier.

Also driving a 16 bit bus with half the lines probably takes less energy per cycle compared to a 32 bit bus, but to move the same amount of data you need twice the cycles. And if this is only used during booting it probably doesn’t matter that much.

reklipz:
2) Is it possible to not have any external Flash and boot right from the HDD, assuming its plugged it, why (not).

This was already somewhat covered but unless your processor has support for booting from a HDD, I'd say no. How is the processor supposed to know how to load the data from the HDD ?

But this could be handled with a small flash where bootloader is put and where the processor boots from and the bootloader loads the rest of the system from the HDD.

For the HDD, are you planning to put the HDD straight on the processor external bus or put some controller between those two ? Having a separate controller should make things faster and it could even provide DMA. Also having the controller should make the HDD access steal less cycles from the processor bus. Just some things to think about.

reklipz:
3) How exactly does the driver / auto flash detect thing work with linux, could I not just connect any kind of flash I wanted, any way I wanted, so long as there was a driver to work with it.

Linux has many kind drivers that you should be able to configure to your needs. But before booting linux you need to have your bootloader support the memory devices and initializing your hardware.

Please correct any mistakes I might have done here and if I missed some crucial things.

3

Henri:
I’m not familiar with EP9315, does it support booting from NAND?

After a bit of research, it seems that it does not support booting from NAND Flash. There are some newer NAND Flash chips, called DiskOnChip, that provide a NOR like interface and allow a beginning small block of code to be executed as though it was a NOR Flash, and I've seen them on digikey (by M-systems I believe). *An interesting document about NAND here: [http://www.linux-mtd.infradead.org/doc/nand.html](http://www.linux-mtd.infradead.org/doc/nand.html)*

Henri:
If this is a small quantity device …

And I think it will be, at least to begin with.

Henri:
… 128MBit for $10.

[http://www.digikey.com/scripts/DkSearch ... T5BTG65-ND](http://www.digikey.com/scripts/DkSearch/dksus.dll?PName?Name=TC58FVM7T5BTG65-ND)

http://www.digikey.com/scripts/DkSearch … 5BTG-65-ND

Those are 128Mbit (16Mx8 / 8Mx16), 65nS, 16bit bus, NOR Flash, top boot block and bottom boot block, respectively. If I want to use just one of them, does it matter which I get? When using both of them, I could connect the address lines to both, and put one bottom boot block on the lower 16 data lines, and the top boot block on the upper 16 data lines, correct? The users guide for the EP9315 was talking some gibberish about SDRAM not appearing continuous because of the way the address lines are hooked up. It shows a weird table that wasn’t making sense to me last night and probably wont right now either. The table showed assignments for bank/row/column of the address pins when in different bus widths / device types, and the address pins were out of order. When I looked at the datasheet for their development board though, it shows that the data pins are hooked up directly (for the most part), which was confusing. Is this something common to all buses of this type when using flash / sdram, or is this an EP9315 specific kind of thing (ie, can you help me understand this without having to take time to read up about it in the datasheet?)

edit: after some more researching, all of the above seems to be wrong (at least until the part about the weirdness of the address lines). The boot block is just talking about which part of the device is/can be protected, and used to store the boot code (woot! something that kind of makes sense). I’m still wondering though if its possible to connect them in such a way that they act as a 32bit wide chip. I think that would be a pain and it might just be easier to connect them up independently, no? Not sure…

Henri:
For the HDD, are you planning to put the HDD straight on the processor external bus or put some controller between those two ? Having a separate controller should make things faster and it could even provide DMA. Also having the controller should make the HDD access steal less cycles from the processor bus. Just some things to think about.

The EP9315 has a built in 2 device IDE controller. :)

Thank you so much for the help!

-Nate

4

reklipz:
There are some newer NAND Flash chips, called DiskOnChip, that provide a NOR like interface and allow a beginning small block of code to be executed as though it was a NOR Flash, and I’ve seen them on digikey (by M-systems I believe).

Before going with M-Systems parts please make sure that you have access to all the necessary documents. Check: [http://www.skippari.net/projects/2006/0 ... linux.html](http://www.skippari.net/projects/2006/07/21/cerfpod-255se-and-linux.html)

Not sure what the situation is with newer M-Systems parts.

reklipz:
edit: after some more researching, all of the above seems to be wrong (at least until the part about the weirdness of the address lines). The boot block is just talking about which part of the device is/can be protected, and used to store the boot code (woot! something that kind of makes sense). I’m still wondering though if its possible to connect them in such a way that they act as a 32bit wide chip. I think that would be a pain and it might just be easier to connect them up independently, no? Not sure…

Yes, the top and bottom boot block difference is just is this special block is in the beginning or end of the flash. You should be able to protect any block of the flash but these bootblocks might have some other special features. Check the datasheet page 20, "10.19. Hidden ROM Area".

Apparently you can permanently make this block read only and I assume you don’t want to do that in your application so it doesn’t matter which one you choose.

The talk about the RAM not appearing continuos is because if you place your RAM in two different banks, there is a some memory area reserved for the bank and when your RAM is smaller than this area reserved there will be empty space between the two banks in the memory map. Though you might find the contents of the RAM repeat several times in this “empty space”. Why this happens can be left as homework if you don’t already know it.

Usually the MMU is used to make the whole RAM appear in one piece to the OS.

If you just want to put two 16-bit devices side by side on a 32-bit bus they are seen as one bank. But with 4 16-bit devices on 32-bit bus you would need to put them in two different banks.

Someone who is a native english speaker could probably explain the above more understandably.

The EP9315 has a built in 2 device IDE controller. :slight_smile:

Ah, ok.
5

Henri made a good summary about NOR/NAND difference. In short, the two are so different not to be a replacement of the other.

  1. Is it possible to not have any external Flash and boot right from the HDD, assuming its plugged it, why (not).
It's impossible for you not to have NOR, in practice. You need to have SDRAM for sratch memory and NOR for program (often called bootloader or "monitor") to fetch the target OS (Linux in your case) off from HDD. Such the xfer is a complicated process.

It’s a technology trend that RISC SoC can boot off from NAND to eliminate NOR necessity, however, such the functionality has a design limitation and needs careful practice. SoC continues to have NOR boot facility since it’s a snip easy and established way.

There are number of alternatives for having HDD which ends up with more or less full-equipped computer-alike project. CF attracted many since the IDE HDD like (electric/programming) interface was prefered replacement of IDE. Down side is relatively high priced medium and no better performance than PIO.

SD has been gaining popularity, in particular for embeded application field, since the simplicity and lower price for huge capacity. It’s also a plus the growing number of RISC SoC have HW circuit to interface/drive SD. Some can even achieve DMA xfer. Down side is HW supports appear infant designs which are different each other in large degree. SD assumes FAT. The introduction of SDIO standard made things complicated.

It’s possible to have plain NAND chip for general purpose storage in place of above mentioned ways. With or without special HW NAND support feature by SoC. The problem is that you need to understand well about NAND technology short commings and overcome unescapable limitations by complex SW.

6

One kind of interesting technique that I had read about was as follows; The SoC allows for boot from SDRAM. The technique involves an external chip that copies the boot code / os from the non volatile storage, whether it be NOR / NAND Flash, or any other non volatile media, to RAM, and keep the SoC in resets while its doing this.

I personally do not like the above method, as it requires some external DMA chip, and is too much work when I can either just use the small amount of internal flash, or purchase a bit larger amount of external flash.