<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
Haavard Skinnemoen wrote:
<blockquote
cite="mid:20080618142851.0c4a51a3@hskinnemo-gx745.norway.atmel.com"
type="cite">
<pre wrap="">Andrejs Cainikovs <a class="moz-txt-link-rfc2396E" href="mailto:AndrejsC@GlobalAutomationSystems.com"><AndrejsC@GlobalAutomationSystems.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Our boards flash driver is the same as in board/atmel/at91rm9200dk/flash.c
The only thing that was modified is the flash identification routine, as
there was no support for AT49BV642D.
</pre>
</blockquote>
<pre wrap=""><!---->
This chip is supported by the CFI driver (the ATNGW100 board relies on
that.)
</pre>
<blockquote type="cite">
<pre wrap="">The flash organization for this chip is the same as in AT49BV6416 which
exists in the sources, so we haven't changed a lot.
</pre>
</blockquote>
<pre wrap=""><!---->
This chip is not yet supported by the CFI driver. It needs a fixup due
to reversed erase region information, but since the CFI driver only
reads the low 8 bits of the ID, there's currently no way to tell it
apart from AT49BV642D, which doesn't need this fixup.
If someone can figure out how to read a 16-bit ID when appropriate, I
suspect we can get rid of quite a few board-specific flash drivers
(including the one for ATSTK1000).
Unfortunately, I don't have the time to look into this myself at the
moment.
Haavard
</pre>
</blockquote>
+1 goes to Atmel people. Thanks, Haavard!<br>
<br>
Kind reagards,<br>
Andrejs Cainikovs.<br>
</body>
</html>