Flash Issues - AT49BV6416-70TU

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Looking up the Flash used in the reference design it looks like its obsolete, along with practically all Atmel flash. (Lead Free Included)

So I need a substitute. Having worked with Atmel components before, I'm concerned what avr32program will recognize as "flash". Will it recognize anything with a CFI type interface? What my substitute.

I need at least uboot, linux-kernel and a basic filesystem so thinking of the following:

1. uboot - 256K bytes of storage
2. Linux Kernel - 1 Megabytes
3. Basic File system + applications 14Megabytes

In theory a 16Megabyte part is ok, but having done
this before 32 megabytes would be better
and 64 Megabytes would be best.

I'm planning on ussing a jffs2 filesystem.

So tell me what avr32program can reprogram

So a part number and the fact it will work with avr32program is what I need.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

glenn.west@aarcorp.com wrote:
Looking up the Flash used in the reference design it looks like its obsolete, along with practically all Atmel flash. (Lead Free Included)

The AT49BV6416 is indeed obsolete. AT49BV642D is a good replacement -- it's mostly compatible except for a couple of annoying misfeatures of the 6416, like the "flash is softlocked after reset" thing. 642D doesn't have the softlock "feature", so it's more compatible with other AMD-style flash.

Quote:
So I need a substitute. Having worked with Atmel components before, I'm concerned what avr32program will recognize as "flash". Will it recognize anything with a CFI type interface? What my substitute.

I'm not sure about the avr32program binary shipped with STK1000 BSP 1.0. I suspect it only supports 6416, but I'm pretty sure Atmel can send you a version that does CFI if you ask.

As for u-boot, I don't think the BSP 1.0 version will work out of the box with anything but 6416, although the changes needed to support 642D are probably minimal. Another alternative would be to use the latest upstream version with the 1.1.6-hs1 patch from http://avr32linux.org/twiki/bin/.... This should allow you use the standard cfi driver, but it's probably still a good idea to check the u-boot-users list to see which flash devices have actually been used successfully with this driver since lots of flash chips seem to be somewhat buggy wrt. CFI (I'm not talking about Atmel in particular here, although the 6416 is indeed a little buggy. The 642D much less so.)

The Linux kernel should be fine since the STK1000 port already uses the CFI driver. But again, if you find a chip that hasn't been used before, there's a chance you'll have to add a fixup for it. In particular, Intel-style flash is much more likely to have the "softlock" feature I mentioned above; if this is the case, you'll have to add MTD_STUPID_LOCK to mtd->flags just like for AT49BV6416:

static void fixup_use_atmel_lock(struct mtd_info *mtd, void *param)
{
        mtd->lock = cfi_atmel_lock;
        mtd->unlock = cfi_atmel_unlock;
        mtd->flags |= MTD_STUPID_LOCK;
}

Also, there are quite a few board-specific mapping drivers around which apply workarounds as well. IMO this is the wrong approach and should be replaced with a generic fixup like the one above. The STK1000 board code does not apply any fixups on its own (it uses the generic physmap driver.)

Quote:
In theory a 16Megabyte part is ok, but having done this before 32 megabytes would be better and 64 Megabytes would be best.

Ok, the AT49BV642D is only 8 megabytes, so I guess that won't cut it. I'm sorry, but I don't really know of any larger devices. You might want to consider a NAND or serial flash since those tend to be bigger, but you're still going to need a small parallel flash for booting.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well found the solution I wanted.
The answer is "Microsd"

The SD card is nice, but the problem is in most designed, its just to big. The better solution is
microsd. The card is tiny, smaller pysically than your typical nand flash. The socket is rugid. Digikey has a nice 3m socket that a $1 plus in qty 1, and pennys in volume. The best part, I tested it already. Got me a Sandisk Micro sd card from the retail shop, used the supplied adapter and did a dd under windows of the original image, and it boots and runs.

So if your having "space" issues with normal sd, this looks to be a nice solution. The cards can go up to 2 gig, and the avr32 can have 2.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Good call. Also, if you need something more mechanically robust, the Sandisk iNAND ( http://www.sandisk.com/Oem/Defau... ) is good too, it's effectively an SD card in a BGA package. Capacities to 4GB and you don't need to worry about sockets. They are a bit bigger than the MicroSD + socket but not so as you'd really notice.

S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Looking around over the weeknd, the microsd price is dropping like lead. So its seems to be a good choice. And the socket means I dont have to program it via jtag, or network interface. Can stick it in a pc card reader and zap it away.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Horses for courses: I'm not denying MicroSD is a great choice, but iNAND is just more mechanically sound. More inconveniant sure, but more robust.

S.