strata-instance.html

ecos3.0 beta 的官方文档,html格式

16-bit bus it should be 16.
    </P
><P
>The <CODE
CLASS="STRUCTFIELD"
>block_info</CODE
> field consists of one or
more pairs of the block size in bytes and the number of blocks of that
size. The order must match the actual hardware device since the flash
code will use the table to determine the start and end locations of
each block. The table can be initialized in one of three ways:
    </P
><P
></P
><OL
TYPE="1"
><LI
><P
>If the driver initialization function is set to
<CODE
CLASS="FUNCTION"
>cyg_strata_init_nop</CODE
> or
<CODE
CLASS="FUNCTION"
>cyg_strata_init_check_devid_XX</CODE
> then the block
information should be provided statically. This is appropriate if the
board will also be manufactured using the same flash chip.
      </P
></LI
><LI
><P
>If <CODE
CLASS="FUNCTION"
>cyg_strata_init_cfi_XX</CODE
> is used then this
will fill in the block info table. Hence there is no need for static
initialization.
      </P
></LI
><LI
><P
>If a platform-specific initialization function is used then either
this should fill in the block info table, or the info should be
provided statically.
      </P
></LI
></OL
><P
>The size of the <CODE
CLASS="STRUCTFIELD"
>block_info</CODE
> table is
determined by the configuration option
<CODE
CLASS="VARNAME"
>CYGNUM_DEVS_FLASH_STRATA_V2_ERASE_REGIONS</CODE
>.
This has a default value of 2, which should suffice for nearly all
Strata flash devices. If more entries are needed then the platform
HAL's CDL script should require a larger value.
    </P
><P
>If the <CODE
CLASS="STRUCTNAME"
>cyg_strata_dev</CODE
> structure is
statically initialized then it can be <TT
CLASS="LITERAL"
>const</TT
>. This
saves a small amount of memory in ROM startup applications. If the
structure may be updated at run-time, either by
<CODE
CLASS="FUNCTION"
>cyg_strata_init_cfi_XX</CODE
> or by a
platform-specific initialization routine, then it cannot be
<TT
CLASS="LITERAL"
>const</TT
>.
    </P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="STRATA-INSTANCE-FLASH"
></A
><H2
>Flash Structure</H2
><P
>Internally the flash code works in terms of
<CODE
CLASS="STRUCTNAME"
>cyg_flash_dev</CODE
> structures, and the platform
HAL should define one of these. The structure should be placed in the
<TT
CLASS="LITERAL"
>cyg_flashdev</TT
> table. The following fields need to be
provided:
    </P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
><CODE
CLASS="STRUCTFIELD"
>funs</CODE
></DT
><DD
><P
>This should point at the table of functions.
        </P
></DD
><DT
><CODE
CLASS="STRUCTFIELD"
>start</CODE
></DT
><DD
><P
>The base address of the flash in the address map. On
some board the flash may be mapped into memory several times, for
example it may appear in both cached and uncached parts of the address
space. The <CODE
CLASS="STRUCTFIELD"
>start</CODE
> field should correspond to
the cached address.
        </P
></DD
><DT
><CODE
CLASS="STRUCTFIELD"
>end</CODE
></DT
><DD
><P
>The address of the last byte in the flash. It can
either be statically initialized, or
<CODE
CLASS="FUNCTION"
>cyg_strata_init_cfi_XX</CODE
> will calculate
its value at run-time.
        </P
></DD
><DT
><CODE
CLASS="STRUCTFIELD"
>num_block_infos</CODE
></DT
><DD
><P
>This should be the number of entries in the
<CODE
CLASS="STRUCTFIELD"
>block_info</CODE
> table. It can either be
statically initialized or it will be filled in by
<CODE
CLASS="FUNCTION"
>cyg_strata_init_cfi_XX</CODE
>.
        </P
></DD
><DT
><CODE
CLASS="STRUCTFIELD"
>block_info</CODE
></DT
><DD
><P
>The table with the block information is held in the
<CODE
CLASS="STRUCTNAME"
>cyg_strata_dev</CODE
> structure, so this field
should just point into that structure.
        </P
></DD
><DT
><CODE
CLASS="STRUCTFIELD"
>priv</CODE
></DT
><DD
><P
>This field is reserved for use by the device driver. For the Strata
driver it should point at the appropriate
<CODE
CLASS="STRUCTNAME"
>cyg_strata_dev</CODE
> structure. 
        </P
></DD
></DL
></DIV
><P
>The <CODE
CLASS="STRUCTNAME"
>cyg_flash_dev</CODE
> structure contains a number
of other fields which are manipulated only by the generic flash code.
Some of these fields will be updated at run-time so the structure
cannot be declared <TT
CLASS="LITERAL"
>const</TT
>.
    </P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="STRATA-INSTANCE-SERIAL"
></A
><H2
>Multiple Devices</H2
><P
>A board may have several flash devices in parallel, for example two
16-bit devices on a 32-bit bus. It may also have several such banks
to increase the total amount of flash. If each device provides 2MB,
there could be one bank of 2 parallel flash devices at 0xFF800000 and
another bank at 0xFFC00000, giving a total of 8MB. This setup can be
described in several ways. One approach is to define two
<CODE
CLASS="STRUCTNAME"
>cyg_flash_dev</CODE
> structures. The table of
function pointers can usually be shared, as can the
<CODE
CLASS="STRUCTNAME"
>cyg_strata_dev</CODE
> structure. Another approach
is to define a single <CODE
CLASS="STRUCTNAME"
>cyg_flash_dev</CODE
>
structure but with a larger <CODE
CLASS="STRUCTFIELD"
>block_info</CODE
>
table, covering the blocks in both banks of devices. The second
approach makes more efficient use of memory.
    </P
><P
>Many variations are possible, for example a small slow flash device
may be used for initial bootstrap and holding the configuration data,
while there is also a much larger and faster device to hold a file
system. Such variations are usually best described by separate
<CODE
CLASS="STRUCTNAME"
>cyg_flash_dev</CODE
> structures.
    </P
><P
>If more than one <CODE
CLASS="STRUCTNAME"
>cyg_flash_dev</CODE
> structure is
instantiated then the platform HAL's CDL script should implement the
CDL interface <CODE
CLASS="VARNAME"
>CYGHWR_IO_FLASH_DEVICE</CODE
> once for every
device past the first. Otherwise the generic code may default to the
case of a single flash device and optimize for that.
    </P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="STRATA-INSTANCE-PLATFORM"
></A
><H2
>Platform-Specific Macros</H2
><P
>The Strata driver source code includes the header files
<TT
CLASS="FILENAME"
>cyg/hal/hal_arch.h</TT
> and
<TT
CLASS="FILENAME"
>cyg/hal/hal_io.h</TT
>, and hence
indirectly the corresponding platform header files (if defined).
Optionally these headers can define macros which are used inside the
driver, thus giving the HAL limited control over how the driver works.
    </P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="STRATA-INSTANCE-CACHE"
></A
><H2
>Cache Management</H2
><P
>By default the strata driver assumes that the flash can be accessed
uncached, and it will use the HAL
<CODE
CLASS="FUNCTION"
>CYGARC_UNCACHED_ADDRESS</CODE
> macro to map the cached
address in the <CODE
CLASS="STRUCTFIELD"
>start</CODE
> field of the
<CODE
CLASS="STRUCTNAME"
>cyg_flash_dev</CODE
> structure into an uncached
address. If for any reason this HAL macro is inappropriate for the
flash then an alternative macro
<CODE
CLASS="FUNCTION"
>HAL_STRATA_UNCACHED_ADDRESS</CODE
> can be defined
instead. However fixing the
<CODE
CLASS="FUNCTION"
>CYGARC_UNCACHED_ADDRESS</CODE
> macro is normally the
better solution.
    </P
><P
>If there is no way of bypassing the cache then the platform HAL should
implement the CDL interface
<CODE
CLASS="VARNAME"
>CYGHWR_DEVS_FLASH_STRATA_V2_CACHED_ONLY</CODE
>. The flash
driver will now disable and re-enable the cache as required. For
example a program operation will involve the following:
    </P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>    STRATA_INTSCACHE_STATE;
    STRATA_INTSCACHE_BEGIN();
    while ( ! finished ) {
        program data
    }
    STRATA_INTSCACHE_END();
    </PRE
></TD
></TR
></TABLE
><P
>The default implementations of these INTSCACHE macros are as follows:
<CODE
CLASS="VARNAME"
>STATE</CODE
> defines any local variables that may be
needed, e.g. to save the current interrupt state;
<CODE
CLASS="FUNCTION"
>BEGIN</CODE
> disables interrupts, synchronizes the data
caches, disables it, and invalidates the current contents;
<CODE
CLASS="FUNCTION"
>END</CODE
> re-enables the cache and then
interrupts. The cache is only disabled when interrupts are disabled,
so there is no possibility of an interrupt handler running or a
context switch occurring while the cache is disabled, potentially
leaving the system running very slowly. The data cache synchronization
ensures that there are no dirty cache lines, so when the cache is
disabled the low-level flash write code will not see stale data in
memory. The invalidate ensures that at the end of the operation
higher-level code will not pick up stale cache contents instead of the
newly written flash data.
    </P
><P
>Some implementations of the HAL cache macros may not provide the exact
semantics required by the flash driver. For example
<CODE
CLASS="FUNCTION"
>HAL_DCACHE_DISABLE</CODE
> may have an unwanted side
effect, or it may do more work than is needed here. The driver will
check for alternative macros
<CODE
CLASS="FUNCTION"
>HAL_STRATA_INTSCACHE_STATE</CODE
>,
<CODE
CLASS="FUNCTION"
>HAL_STRATA_INTSCACHE_BEGIN</CODE
> and
<CODE
CLASS="FUNCTION"
>HAL_STRATA_INTSCACHE_END</CODE
>, using these instead of
the defaults.
    </P
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="strata.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="ecos-ref.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="strata-api-other.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Overview</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="devs-flash-strata.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Strata-Specific Functions</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>