ffs.htm 65.3 KB

Raw Blame History Permalink

<html xmlns:v="urn:schemas-microsoft-com:vml"
xmlns:o="urn:schemas-microsoft-com:office:office"
xmlns:w="urn:schemas-microsoft-com:office:word"
xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=windows-1252">
<meta name=ProgId content=Word.Document>
<meta name=Generator content="Microsoft Word 9">
<meta name=Originator content="Microsoft Word 9">
<link rel=File-List href="./ffs_files/filelist.xml">
<link rel=Edit-Time-Data href="./ffs_files/editdata.mso">
<link rel=OLE-Object-Data href="./ffs_files/oledata.mso">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>Flash File System Definition</title>
<!--[if gte mso 9]><xml>
 <o:DocumentProperties>
  <o:Author>Andy Patti</o:Author>
  <o:LastAuthor>Andy Patti</o:LastAuthor>
  <o:Revision>2</o:Revision>
  <o:TotalTime>5734</o:TotalTime>
  <o:LastPrinted>2002-06-19T00:58:00Z</o:LastPrinted>
  <o:Created>2002-07-04T00:42:00Z</o:Created>
  <o:LastSaved>2002-07-04T00:42:00Z</o:LastSaved>
  <o:Pages>9</o:Pages>
  <o:Words>3660</o:Words>
  <o:Characters>20864</o:Characters>
  <o:Lines>173</o:Lines>
  <o:Paragraphs>41</o:Paragraphs>
  <o:CharactersWithSpaces>25622</o:CharactersWithSpaces>
  <o:Version>9.2720</o:Version>
 </o:DocumentProperties>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;
	mso-font-charset:2;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:0 268435456 0 0 -2147483648 0;}
@font-face
	{font-family:"Arial Unicode MS";
	mso-font-alt:Tahoma;
	mso-font-charset:128;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:-1 -369098753 63 0 4129023 0;}
@font-face
	{font-family:"\@Arial Unicode MS";
	mso-font-charset:128;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:-1 -369098753 63 0 4129023 0;}
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	mso-bidi-font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
h1
	{mso-style-next:Normal;
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	page-break-after:avoid;
	mso-outline-level:1;
	font-size:10.0pt;
	mso-bidi-font-size:12.0pt;
	font-family:"Times New Roman";
	mso-font-kerning:0pt;}
h2
	{mso-style-next:Normal;
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	page-break-after:avoid;
	mso-outline-level:2;
	font-size:10.0pt;
	mso-bidi-font-size:12.0pt;
	font-family:"Times New Roman";
	font-weight:normal;
	font-style:italic;}
p.MsoFootnoteText, li.MsoFootnoteText, div.MsoFootnoteText
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
span.MsoFootnoteReference
	{vertical-align:super;}
p.MsoTitle, li.MsoTitle, div.MsoTitle
	{margin:0in;
	margin-bottom:.0001pt;
	text-align:center;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	font-weight:bold;}
p.MsoSubtitle, li.MsoSubtitle, div.MsoSubtitle
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	mso-bidi-font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	font-weight:bold;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
 /* List Definitions */
@list l0
	{mso-list-id:468397577;
	mso-list-type:hybrid;
	mso-list-template-ids:-1904814366 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:38.25pt;
	mso-level-number-position:left;
	margin-left:38.25pt;
	text-indent:-.25in;
	font-family:Symbol;}
@list l1
	{mso-list-id:611866839;
	mso-list-type:hybrid;
	mso-list-template-ids:221417278 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l1:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;}
@list l1:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";
	mso-bidi-font-family:"Times New Roman";}
@list l2
	{mso-list-id:684327728;
	mso-list-type:hybrid;
	mso-list-template-ids:-359342024 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l2:level1
	{mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l3
	{mso-list-id:712273332;
	mso-list-type:hybrid;
	mso-list-template-ids:-686667740 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l3:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;}
@list l4
	{mso-list-id:1079443778;
	mso-list-type:hybrid;
	mso-list-template-ids:-209942490 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l4:level1
	{mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l5
	{mso-list-id:1273247992;
	mso-list-type:hybrid;
	mso-list-template-ids:-1885458352 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l5:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;}
@list l6
	{mso-list-id:1373920048;
	mso-list-type:hybrid;
	mso-list-template-ids:-241634386 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l6:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;}
@list l6:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";
	mso-bidi-font-family:"Times New Roman";}
@list l7
	{mso-list-id:2026127263;
	mso-list-type:hybrid;
	mso-list-template-ids:-761215808 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l7:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;}
@list l8
	{mso-list-id:2136561511;
	mso-list-type:hybrid;
	mso-list-template-ids:-1151963978 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l8:level1
	{mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>
</head>

<body lang=EN-US link=blue vlink=purple style='tab-interval:.5in'>

<div class=Section1>

<p class=MsoTitle>File System for Modular Nand-Flash</p>

<p class=MsoNormal align=center style='text-align:center'><b><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></b></p>

<h1><span style='font-weight:normal'>The BB hardware will use a storage module
that will contain both fixed (on-module) and pluggable nand-flash. This
document describes a file system for managing the storage module, using a
distributed FAT approach. It is not fully Smart-Media (SM) compliant, but since
we will also support SM storage for different purposes, we will be compliant
with the SM physical format where hardware will benefit (ECC, for instance).</span></h1>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<h1>Requirements/Attributes</h1>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<ol style='margin-top:0in' start=1 type=1>
 <li class=MsoNormal style='mso-list:l4 level1 lfo2;tab-stops:list .5in'>Support
     for fixed storage up to 64MB.</li>
 <li class=MsoNormal style='mso-list:l4 level1 lfo2;tab-stops:list .5in'>Support
     for total modular memory of up to 1GB.</li>
 <li class=MsoNormal style='mso-list:l4 level1 lfo2;tab-stops:list .5in'>Support
     up to 3 pluggable modules.</li>
 <li class=MsoNormal style='mso-list:l4 level1 lfo2;tab-stops:list .5in'>All
     licenses reside on the fixed storage.</li>
 <li class=MsoNormal style='mso-list:l4 level1 lfo2;tab-stops:list .5in'>Boot-ROM
     code for bootstrapping the Secure Kernel (SK) must be as simple as
     possible.</li>
 <li class=MsoNormal style='mso-list:l4 level1 lfo2;tab-stops:list .5in'>Secure
     Kernel (SK) code for launching the Browser application (BA) must be as
     simple as possible.</li>
 <li class=MsoNormal style='mso-list:l4 level1 lfo2;tab-stops:list .5in'>Bad
     blocks must be detected and avoided  both those that ship with the device
     and occur later in the field.</li>
 <li class=MsoNormal style='mso-list:l4 level1 lfo2;tab-stops:list .5in'>Nintendo
     game files must be stored such that they may be made to appear contiguous
     by a limited number (16?) of hardware segment registers (cannot be highly
     fragmented into separated blocks).</li>
 <li class=MsoNormal style='mso-list:l4 level1 lfo2;tab-stops:list .5in'>File
     System (FS) must be recoverable in the event of untimely power-downs.</li>
 <li class=MsoNormal style='mso-list:l4 level1 lfo2;tab-stops:list .5in'>Initialization
     under normal conditions must be quick (&lt;1sec).</li>
 <li class=MsoNormal style='mso-list:l4 level1 lfo2;tab-stops:list .5in'>For a
     given piece of content, a license (containing meta-data and security
     information), the encrypted content, and storage of associated persistent
     data must be logically linked.</li>
 <li class=MsoNormal style='mso-list:l4 level1 lfo2;tab-stops:list .5in'>Pluggable
     NandFlash modules must appear as a simple extension of available storage
     (files can cross boundaries between permanent and pluggable, and pluggable
     to pluggable).</li>
 <li class=MsoNormal style='mso-list:l4 level1 lfo2;tab-stops:list .5in'>Robust
     to Pluggable NandFlash being unplugged, replaced with different size
     modules, and plugged back in.</li>
 <li class=MsoNormal style='mso-list:l4 level1 lfo2;tab-stops:list .5in'>Files
     (content) stored completely on a single pluggable NandFlash module must be
     persistent over removal and replugin cycles. Content with portions stored
     on and off a given pluggable will be effectively deleted once that
     pluggable is removed.</li>
 <li class=MsoNormal style='mso-list:l4 level1 lfo2;tab-stops:list .5in'>Reliability
     through SM compliant ECC.</li>
</ol>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<h1><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></h1>

<h1>Overview of distributed FAT16 approach</h1>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal>The primary elements of the flash file system (FFS) are:</p>

<ul style='margin-top:0in' type=disc>
 <li class=MsoNormal style='mso-list:l5 level1 lfo3;tab-stops:list .5in'>FAT16-like
     table to track bad blocks, free blocks, and blocks chained together to
     form a file. This table is distributed to reside on both permanent
     (on-board) flash and (un)pluggable flash storage modules.</li>
 <li class=MsoNormal style='mso-list:l5 level1 lfo3;tab-stops:list .5in'>A root
     directory file with each entry describing a file and containing per-file
     data such as content-id, type (license, executable, media, ), starting
     block (points into FAT). This file MUST only reside on permanent storage
     and shares the same block as the permanent storage FAT.</li>
 <li class=MsoNormal style='mso-list:l5 level1 lfo3;tab-stops:list .5in'>A
     singe license file to hold all licenses. Since licenses contain
     unencrypted content metadata, all content the BB owner has rights to may
     be browsed by parsing this file. This file MUST only reside on permanent
     storage.</li>
 <li class=MsoNormal style='mso-list:l5 level1 lfo3;tab-stops:list .5in'>Not
     truly part of the filesystem, but two files have special placement.
     First, the fixed-size SK, which has no associated license, MUST reside on
     the first few good blocks of permanent storage. Second, the browser
     application has its license as the first in the license file, and ALL of
     its content blocks MUST reside sequentially in the first available good
     blocks of permanent storage directly following the SK blocks.</li>
 <li class=MsoNormal style='mso-list:l5 level1 lfo3;tab-stops:list .5in'>Ping-pong
     backup for FAT and Root directory file block, synchronized by serial
     number.</li>
 <li class=MsoNormal style='mso-list:l5 level1 lfo3;tab-stops:list .5in'>ECC
     using SM scheme and same usage of spare data area.</li>
</ul>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal>A FAT16 table will be used to chain together blocks in a
given file, and to keep both the free and bad block lists. After the FAT a DOS
file system would normally contain a root directory file with specific format.
Because of our own specific needs, we will not use a DOS-compatible root
directory file. A root directory file will still be used, but the fields
defined for each file entry will be a minimal set tailored to our use model.</p>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal>The single file for storage of licenses is done for two
reasons. First, a license is expected to be 1-2K in size (but less than 2K). If
each license were a separate file it would appear in its own block. Since a
block is likely to be 16K (or so) we would be wasting a good deal of space.
Using a single file allows us to pack multiple licenses into a single block.
Further, because licenses are added to the file, but not expected to be deleted
often, the block holding the license file should not need to be erased often at
all (just a few page writes to next available pages in the block will record
the file). Second, the license must be stored in the permanent storage area,
while content can be in pluggable storage areas. That means we cannot keep the
license with the content without either wasting space or requiring the first
bytes of content to reside on the permanent storage. This is not desirable
since a segment register would be wasted, and content could never reside
entirely on pluggable storage. Not residing entirely on pluggable storage
implies content will not persist over removal/re-insertion cycles.</p>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal>Figure 1 depicts a high level view of the FS elements in
relation to each other. To simplify the figure bad blocks have been ignored for
the moment. The permanent storage block layout has its FAT and root directory
file block, denoted FR, at the <i>last</i> good block location. Continuing in
from the last block, FR is followed by a ping-pong version, FR. The next
group of blocks stores the license file. To enable simpler SK code for loading
the browser application, we constrain the license file such that the first
entry must be the browser application license.<a style='mso-footnote-id:ftn1'
href="#_ftn1" name="_ftnref1" title=""><span class=MsoFootnoteReference><span
style='mso-special-character:footnote'><![if !supportFootnotes]>[1]<![endif]></span></span></a><span
style="mso-spacerun: yes"> </span>Occupying the first set of good blocks is
the SK, followed by the browser application. It is placed here to simplify the
boot-ROM bootstrap code required for loading the SK, and to simplify the SK
code for loading the browser. Note that the SK is a known, fixed size. Also, if
having the boot-ROM write the SK, or the SK write the browser, were necessary
during the recovery process this would be simplified as well. Next in permanent
storage, Content 2 is shown. This content resides on both the permanent and
pluggable storage. The starting block of Content2 and its block chain is
stored in FR/FR (this will be explained in detail later). The entry in the
root directory will also contain its CID. The license for Content2 will be
stored in the license file, and the license CID will allow logical linking of
the license to the content file.</p>

<p class=MsoNormal align=center style='text-align:center'><!--[if gte vml 1]><v:shapetype
 id="_x0000_t75" coordsize="21600,21600" o:spt="75" o:preferrelative="t"
 path="m@4@5l@4@11@9@11@9@5xe" filled="f" stroked="f">
 <v:stroke joinstyle="miter"/>
 <v:formulas>
  <v:f eqn="if lineDrawn pixelLineWidth 0"/>
  <v:f eqn="sum @0 1 0"/>
  <v:f eqn="sum 0 0 @1"/>
  <v:f eqn="prod @2 1 2"/>
  <v:f eqn="prod @3 21600 pixelWidth"/>
  <v:f eqn="prod @3 21600 pixelHeight"/>
  <v:f eqn="sum @0 0 1"/>
  <v:f eqn="prod @6 1 2"/>
  <v:f eqn="prod @7 21600 pixelWidth"/>
  <v:f eqn="sum @8 21600 0"/>
  <v:f eqn="prod @7 21600 pixelHeight"/>
  <v:f eqn="sum @10 21600 0"/>
 </v:formulas>
 <v:path o:extrusionok="f" gradientshapeok="t" o:connecttype="rect"/>
 <o:lock v:ext="edit" aspectratio="t"/>
</v:shapetype><v:shape id="_x0000_i1025" type="#_x0000_t75" style='width:6in;
 height:198pt' o:ole="">
 <v:imagedata src="./ffs_files/image001.wmz" o:title=""/>
</v:shape><![endif]--><![if !vml]><img width=576 height=264
src="./ffs_files/image002.gif" v:shapes="_x0000_i1025"><![endif]><!--[if gte mso 9]><xml>
 <o:OLEObject Type="Embed" ProgID="Word.Picture.8" ShapeID="_x0000_i1025"
  DrawAspect="Content" ObjectID="_1087223278">
 </o:OLEObject>
</xml><![endif]--></p>

<p class=MsoNormal><b>Figure 1. </b>Block layout for permanent and pluggable
storage. FR and FR reside on the last good blocks of permanent storage and
denote a FAT/root-directory block and its ping-pong companion, respectively.
The SK and BA is constrained to reside on the first sequence of permanent
storage good blocks. The hypothetical case has Content2 starting on permanent
storage and ending on Pluggable storage. The Pluggable storage also completely
contains Content3, and entries F/F are ping-pong FAT blocks residing on the last
two good blocks.</p>

<p class=MsoNormal><b><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></b></p>

<p class=MsoNormal>The pluggable storage contains a FAT of its own, but not a
root directory file or a license file. In the example depicted in Figure 1, the
pluggable storage contains the remainder of Content2 and all the blocks for
another piece of content, Content3. The FAT entries on the permanent storage
and pluggable are designed so that the block chain of Content2 can jump from
the permanent storage to the pluggable. The license for Content3 will be stored
in the license file on the permanent storage, and it will have a file entry in
FR/FR (permanent storage) containing the pluggable ID and starting block
therein.</p>

<h1><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></h1>

<h1>Distributed FAT</h1>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal>The FAT table is distributed across the permanent storage
and pluggables to satisfy the requirements of files extending over
permanent/pluggable storage boundaries, and fully on-pluggable content
persistence over pluggable removal/insertion cycles. The FAT format differs
slightly for the permanent storage vs. the pluggables. This is because some
omnipresent state may only be stored on the permanent storage. </p>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal>There are 2 copies of<span style="mso-spacerun: yes">
</span>FAT located on permanent storage and they occupy the last 2 good blocks
of on-board storage. Figure 2 depicts the permanent storage FAT structure. The
16-bit entries at the beginning of the structure contain typical FAT codes.
Each entrys position indicates the block of permanent storage being described
(i.e., the nth entry in from the left refers to the nth block of permanent
storage). The required number of entries is determined by the size of permanent
storage. Assuming the permanent storage is 64MB or less, and again assuming 16K
blocks, we need a maximum of 4096 16-bit entries. This translates to 8KB, which
is only half the size of a 16K block. We therefore have plenty of space for the
data to follow: characteristics for each inserted pluggable, state for
permanent storage, and the root file system.</p>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal>The 16-bit values themselves have meaning according to Table
1. Note that the 16-bit entry can reference blocks in the range 0x1 to 0xFFEF,
or 65519 total usable blocks. Assuming each block is 16K, which is typical for
16MB and 32MB NandFlash, table entries can reference approximately 64Kx16K, or
1GB, of storage (actually short be 256K). </p>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal align=center style='text-align:center'><!--[if gte vml 1]><v:shape
 id="_x0000_i1026" type="#_x0000_t75" style='width:6in;height:171pt' o:ole="">
 <v:imagedata src="./ffs_files/image003.wmz" o:title=""/>
</v:shape><![endif]--><![if !vml]><img width=576 height=228
src="./ffs_files/image004.gif" v:shapes="_x0000_i1026"><![endif]><!--[if gte mso 9]><xml>
 <o:OLEObject Type="Embed" ProgID="Word.Picture.8" ShapeID="_x0000_i1026"
  DrawAspect="Content" ObjectID="_1087223279">
 </o:OLEObject>
</xml><![endif]--></p>

<p class=MsoNormal align=center style='text-align:center'><b>Figure 2. </b>Permanent
storage FAT.<b><o:p></o:p></b></p>

<p class=MsoNormal align=center style='text-align:center'><b><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></b></p>

<div align=center>

<table border=1 cellpadding=0 style='mso-cellspacing:1.5pt'>
 <tr>
  <td valign=top style='padding:.75pt .75pt .75pt .75pt'>
  <p class=MsoNormal><b>FAT16 Value </b><b><span style='font-family:"Arial Unicode MS"'><o:p></o:p></span></b></p>
  </td>
  <td valign=top style='padding:.75pt .75pt .75pt .75pt'>
  <h1>Meaning <span style='font-family:"Arial Unicode MS"'><o:p></o:p></span></h1>
  </td>
 </tr>
 <tr>
  <td valign=top style='padding:.75pt .75pt .75pt .75pt'>
  <p class=MsoNormal>0000h <span style='font-family:"Arial Unicode MS"'><o:p></o:p></span></p>
  </td>
  <td valign=top style='padding:.75pt .75pt .75pt .75pt'>
  <p class=MsoNormal>block available <span style='font-family:"Arial Unicode MS"'><o:p></o:p></span></p>
  </td>
 </tr>
 <tr>
  <td valign=top style='padding:.75pt .75pt .75pt .75pt'>
  <p class=MsoNormal>FFF0-FFF6h <span style='font-family:"Arial Unicode MS"'><o:p></o:p></span></p>
  </td>
  <td valign=top style='padding:.75pt .75pt .75pt .75pt'>
  <p class=MsoNormal>reserved block <span style='font-family:"Arial Unicode MS"'><o:p></o:p></span></p>
  </td>
 </tr>
 <tr>
  <td valign=top style='padding:.75pt .75pt .75pt .75pt'>
  <p class=MsoNormal>FFF7h <span style='font-family:"Arial Unicode MS"'><o:p></o:p></span></p>
  </td>
  <td valign=top style='padding:.75pt .75pt .75pt .75pt'>
  <p class=MsoNormal>bad block <span style='font-family:"Arial Unicode MS"'><o:p></o:p></span></p>
  </td>
 </tr>
 <tr>
  <td valign=top style='padding:.75pt .75pt .75pt .75pt'>
  <p class=MsoNormal>FFF8h-FFFFh <span style='font-family:"Arial Unicode MS"'><o:p></o:p></span></p>
  </td>
  <td valign=top style='padding:.75pt .75pt .75pt .75pt'>
  <p class=MsoNormal>last block of file <span style='font-family:"Arial Unicode MS"'><o:p></o:p></span></p>
  </td>
 </tr>
 <tr>
  <td valign=top style='padding:.75pt .75pt .75pt .75pt'>
  <p class=MsoNormal>XXXXh <span style='font-family:"Arial Unicode MS"'><o:p></o:p></span></p>
  </td>
  <td valign=top style='padding:.75pt .75pt .75pt .75pt'>
  <p class=MsoNormal>next block in file <span style='font-family:"Arial Unicode MS"'><o:p></o:p></span></p>
  </td>
 </tr>
</table>

</div>

<p class=MsoNormal align=center style='text-align:center'><b>Table 1. </b>FAT
value mappings.<b><o:p></o:p></b></p>

<p class=MsoNormal><b><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></b></p>

<p class=MsoNormal>The initial number of 16-bit entries is the total required
to cover all permanent storage. The area that directly follows contains
information for all pluggable storage present. Each entry contains a 16bit ID,
a 16bit number of blocks the device holds, and a 16bit sequence number
referencing the pluggables FAT. There is space reserved for the number of
pluggables slots, but if a pluggable is not present the id value 0xFFFF will
signify this. The ID is assigned to each pluggable when it is plugged in. The
# blocks contains the total number of blocks for the pluggable. Each entrys
sequence number will be covered in more detail later. It is used to insure
consistency between permanent storage and the pluggable devices.</p>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal>Directly following the pluggable storage data is general FS
state. This includes the sequence number for this table and the next ID to be
assigned a pluggable device. The need for this will become apparent during the
discussion of plugin device removal and (re)insertion.</p>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal>Figure 3 depicts the FAT stored on the last valid blocks of
a pluggable. The first set of bytes represent regular FAT entries, as
previously described. Because of the 16K block-size, this table limits the size
for a given pluggable to 128M. To obtain 256M would require using an additional
block, unless the block size is increased accordingly. Starting from the blocks
at the end of the device and working backwards, local state is stored first.
Local state contains 16bit entries holding the ID of this pluggable, the offset
applied to its FAT entries, and its sequence number. Pairs of data
referencing other storage units (pluggable or permanent) are next. There is a
data pair for each storage unit referenced by the FAT of this pluggable. Each
pair contains the other units ID and a sequence number corresponding to the
minimum sequence number of that storages FAT to insure consistency.</p>

<p class=MsoNormal align=center style='text-align:center'><!--[if gte vml 1]><v:shape
 id="_x0000_i1027" type="#_x0000_t75" style='width:6in;height:171pt' o:ole="">
 <v:imagedata src="./ffs_files/image005.wmz" o:title=""/>
</v:shape><![endif]--><![if !vml]><img width=576 height=228
src="./ffs_files/image006.gif" v:shapes="_x0000_i1027"><![endif]><!--[if gte mso 9]><xml>
 <o:OLEObject Type="Embed" ProgID="Word.Picture.8" ShapeID="_x0000_i1027"
  DrawAspect="Content" ObjectID="_1087223280">
 </o:OLEObject>
</xml><![endif]--></p>

<p class=MsoNormal align=center style='text-align:center'><b>Figure 3.
Pluggable storage FAT.<o:p></o:p></b></p>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<h1>Offset usage and referencing blocks crossing pluggable boundaries</h1>

<p class=MsoNormal><b><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></b></p>

<p class=MsoNormal>The scheme for a permanent storage FAT entry to reference a
block on a pluggable is shown in the following pseudo-code. </p>

<p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Courier New"'>#
define PERM_BLOCKS &lt;<i>number of blocks of permanent storage</i>&gt;<o:p></o:p></span></p>

<p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Courier New"'>uint16
entry = &lt;<i>value of the FAT entry in question</i>&gt;<o:p></o:p></span></p>

<p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Courier New"'>uint16
blocks_id1 = <i>&lt;# blocks entry for first pluggable id</i>&gt;<o:p></o:p></span></p>

<p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Courier New"'>uint16
blocks_id2 = &lt;<i># blocks entry for second pluggable id&gt;</i><o:p></o:p></span></p>

<p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Courier New"'>//
if needed, same for blocks_id3, blocks_id4, <o:p></o:p></span></p>

<p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Courier New"'>if(entry&lt;PERM_BLOCKS){<o:p></o:p></span></p>

<p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Courier New"'><span
style="mso-spacerun: yes"> </span>// entry points to block of permanent
storage<o:p></o:p></span></p>

<p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Courier New"'>}<o:p></o:p></span></p>

<p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Courier New"'>//
now for each successive pluggable entry that appears in the<o:p></o:p></span></p>

<p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Courier New"'>//
permanent storage FAT (starts after PERM_BLOCKS 16-bit entries<o:p></o:p></span></p>

<p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Courier New"'>else
if(entry&lt;PERM_BLOCKS+blocks_id1){<o:p></o:p></span></p>

<p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Courier New"'><span
style="mso-spacerun: yes"> </span>// entry points into first listed FAT
pluggable, with<o:p></o:p></span></p>

<p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Courier New"'><span
style="mso-spacerun: yes"> </span>// associated ID,<o:p></o:p></span></p>

<p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Courier New"'><span
style="mso-spacerun: yes"> </span>offset_for_pluggable = &lt;<i>offset for
pluggable with id1&gt;<o:p></o:p></i></span></p>

<p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Courier New"'><span
style="mso-spacerun: yes"> </span>block_on_pluggable = entry
offset_for_pluggable;<o:p></o:p></span></p>

<p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Courier New"'>}<o:p></o:p></span></p>

<p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Courier New"'>else
if(entry&lt;PERM_BLOCKS+blocks_id1+blocks_id2){<o:p></o:p></span></p>

<p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Courier New"'><span
style="mso-spacerun: yes"> </span>// entry points into second FAT pluggable
with associated ID<o:p></o:p></span></p>

<p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Courier New"'><span
style="mso-spacerun: yes"> </span>// in permanent FAT following entries for
perm blocks<o:p></o:p></span></p>

<p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Courier New"'><span
style="mso-spacerun: yes"> </span>offset_for_pluggable = &lt;<i>offset for
pluggable with id2&gt;<o:p></o:p></i></span></p>

<p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Courier New"'><span
style="mso-spacerun: yes"> </span>block_on_pluggable = entry
offset_for_pluggable;<o:p></o:p></span></p>

<p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Courier New"'>}<o:p></o:p></span></p>

<p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Courier New"'>//
repeat else if for all pluggable id/#blocks entries<o:p></o:p></span></p>

<p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Courier New"'>//
in permanent strorage FAT<o:p></o:p></span></p>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal>Each entry in a pluggables FAT will apply its offset as
well. This allows the entries to reference blocks on the permanent storage as
well as other pluggables, so a file can span pluggable-pluggable boundaries. As
an example, suppose a given pluggable has offset 1024. Then, if a 16-bit
entrys value in that pluggables table is 1034, it will point to the 10th
block on the pluggable. In contrast, the 10th 16-bit entry in the table
relates to the 10th block (the value is interpreted as just described).</p>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal>Note that for the root directory file on permanent storage,
the pluggable starting block number is does NOT apply the offset. This is
because this directory entry contains the pluggables id, and is expected to
persist over removal/insertion cycles. As will be covered next, the offset
value will change at each re-insertion.</p>

<p class=MsoNormal><b><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></b></p>

<p class=MsoNormal><b><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></b></p>

<p class=MsoNormal><b>Root Directory File Contents<o:p></o:p></b></p>

<p class=MsoNormal><b><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></b></p>

<p class=MsoNormal>The root directory contains all the entries for files
appearing in the top level directory. Each entry may refer to a file or
directory, so the file system supports hierarchical structure. Each entry will
contain:</p>

<p class=MsoNormal style='margin-left:38.25pt;text-indent:-.25in;mso-list:l0 level1 lfo7;
tab-stops:list 38.25pt left 2.5in'><![if !supportLists]><span style='font-family:
Symbol'><span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]>CID<span style='mso-tab-count:1'> </span>(8
bytes)</p>

<p class=MsoNormal style='margin-left:38.25pt;text-indent:-.25in;mso-list:l0 level1 lfo7;
tab-stops:list 38.25pt left 2.5in'><![if !supportLists]><span style='font-family:
Symbol'><span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]>Type indicator<span style='mso-tab-count:1'> </span>(1
byte)</p>

<p class=MsoNormal style='margin-left:38.25pt;text-indent:-.25in;mso-list:l0 level1 lfo7;
tab-stops:list 38.25pt left 2.5in'><![if !supportLists]><span style='font-family:
Symbol'><span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]>Storage Ids<span style='mso-tab-count:1'> </span>(6-8
bytes, fixed but depends on number of pluggable slots)</p>

<p class=MsoNormal style='margin-left:38.25pt;text-indent:-.25in;mso-list:l0 level1 lfo7;
tab-stops:list 38.25pt left 2.5in'><![if !supportLists]><span style='font-family:
Symbol'><span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]>Start block<span style='mso-tab-count:1'> </span>(2
bytes)</p>

<p class=MsoNormal style='margin-left:38.25pt;text-indent:-.25in;mso-list:l0 level1 lfo7;
tab-stops:list 38.25pt left 2.5in'><![if !supportLists]><span style='font-family:
Symbol'><span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]>File Size<span style='mso-tab-count:1'> </span>(4
bytes)</p>

<p class=MsoNormal style='tab-stops:2.5in'><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal style='tab-stops:2.5in'>The CID essentially names each file
and allows linkage to the corresponding entry in the license file, and a file
with permanent storage (i.e., game state) if needed.</p>

<p class=MsoNormal style='tab-stops:2.5in'><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal style='tab-stops:2.5in'>The Type indicator field is coded to
allow at least the following types: </p>

<ul style='margin-top:0in' type=disc>
 <li class=MsoNormal style='mso-list:l3 level1 lfo8;tab-stops:list .5in left 2.5in'><i>License
     file: </i>the license file. The first entry in the root directory will be
     the license file.</li>
 <li class=MsoNormal style='mso-list:l3 level1 lfo8;tab-stops:list .5in left 2.5in'><i>Runnable
     Content:</i> indicates n64 games and the browser app. More types of
     runnable content may be considered in the future.</li>
 <li class=MsoNormal style='mso-list:l3 level1 lfo8;tab-stops:list .5in left 2.5in'><i>Content
     Permanent storage:</i> a file holding game state saved during play with
     Nintendo APIs.</li>
 <li class=MsoNormal style='mso-list:l3 level1 lfo8;tab-stops:list .5in left 2.5in'><i>Directory:</i>
     a sub-directory file with entries similar to the root directory file.</li>
</ul>

<p class=MsoNormal style='tab-stops:2.5in'><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal style='tab-stops:2.5in'>The Storage Ids is a string of 6-8
bytes, where each byte indicates the id of each storage module containing the
files blocks. Since each id is 2 bytes, if we have only 2 pluggable slots, we
would need only 6 bytes; 3 pluggable slots would require 8 bytes. The code
0xFFFF is a null entry, so the sequence 0x0000 0xFFFF 0xFFFF 0xFFFF would
indicate the content is entirely contained on the pluggable storage (it has ID
0x0000).</p>

<p class=MsoNormal style='tab-stops:2.5in'><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal style='tab-stops:2.5in'>The Start block is the starting
block for the content. No offset is applied in the case of pluggable storage.
This can be done because of the Storage Ids usage.</p>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal>The File Size contains the number of bytes in the file.</p>

<p class=MsoNormal>The number of possible root directory file entries is
determined by the number of bytes in a block that are not used by the FAT. In
the worst case (which is very unlikely to come to fruition) of 64MB permanent
storage, we have 15 pages left for the root directory file. Each entry is 23
bytes in the worst case scenario. Since each page is 512 bytes, we have 22
entries per page, and thus 330 entries at the root level. This should be plenty.</p>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal><b>Pluggable removal and insertion<o:p></o:p></b></p>

<p class=MsoNormal><b><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></b></p>

<p class=MsoNormal>Assuming the BB is first powered on with no pluggables
present, the pluggable storage referencing data in Figure 2 is initially
blank. At each power-up the FS code will look for all pluggables. When the
first new pluggable is found, we first determine if the pluggable has ever been
plugged into this BB and has files on it that may be usable. If the pluggable
has never been used, this can be detected according to manufacturers
specifications. The new pluggable is assigned the next ID value from the
permanent storage FAT (that value is then incremented and stored back to
permanent storage FAT the next time that FAT block is written). Based on the
device type, which is read utilizing hardware PI registers, the number of
blocks is determined. The initial sequence number of 0 is assigned for the FAT
to be written on the pluggable. The permanent storage FAT is written with the
ID/#blocks/seq# entries just assigned. This is now the first and only entry.
Bad-block detection is carried out on the new pluggable and the initial FAT for
the pluggable is written. The pluggables bad block list, assigned<span
style="mso-spacerun: yes"> </span>ID, and offset now reside on the pluggables
FAT.</p>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal>Ensuing power-ups can detect other new pluggables and the
same procedure is carried out. The permanent storage FAT will contain the
id/#blocks/seq# entries for each of the pluggables the system believes to be
plugged in.</p>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal>When a pluggable is removed, this will be detected at the
next power-up. The FS will determine a pluggable with a given ID is not
present. Two operations will be carried out in response to a missing pluggable.
First, the id/#blocks/seq# entry in permanent FAT will be removed, and the gap
will be filled by moving entries past the gap back. This will effect the
offset value for each pluggable with id that was moved. The permanent storage
FAT will be changed to reflect this, as will the FAT on affected pluggables.
The new offset values will be recorded, and each FAT entry will be adjusted
accordingly. This operation reclaims the address space for blocks in the
removed pluggable. If we did not perform this reclamation step the 16-bit
addressing range could be used up within a few insertion/removal cycles of
sufficiently large storage.</p>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal>The second operation is to remove entries in the root file
directory that did not have all blocks of a given piece of content residing on
the removed pluggable. This information will be stored in the root directory
file. That is, any content that spans the removed pluggable and any other will
have its entry removed from the root directory file. We could conceivably
support such spanning files, but this is not currently a requirement.</p>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal>When a pluggable with an existing FAT and ID is plugged in,
this will be detected at power-up. For the content on the pluggable to be
usable, there must be a file entry in the root directory file with an ID
matching that stored on the existing pluggable FAT. In this case, the pluggable
is assigned a new offset (likely to be different from the old one recorded in
its FAT), and its FAT is adjusted for this new offset. Stale FAT entries for
files that used to chain blocks from other pluggables, which are no longer
valid since the file information was removed from the root file directory, are
removed at this time.</p>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal><span style="mso-spacerun: yes"></span><b><o:p></o:p></b></p>

<p class=MsoNormal><b>Sequence number usage for maintaining consistency<o:p></o:p></b></p>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal>Sequence numbers are used for two purposes. First, they act
as a timestamp between ping-pong pairs of files, such as the two copies of FAT.
Second, a file spanning permanent and/or pluggable boundaries will require FAT
writes to succeed on multiple devices. Power could go down between writes so
that an operation is not completed. To detect the bogus files at power-up, the
sequence numbers are used to indicate consistency.</p>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal>Whenever a file is written to a particular FAT, the ID/seq
entries referencing the other spanned pluggables are increased to their current
value ON THE ACTUAL STORAGE WHERE THE BLOCKS RESIDE plus one. Since the
sequence number will be incremented when the FAT for the other pluggables is
written, we can verify consistency by insuring sequence number entries on one
pluggable, which reference another (or permanent), are always less than or
equal to the value on referenced pluggables FAT.</p>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal><b>Nand-Flash spare area format<o:p></o:p></b></p>

<p class=MsoNormal><b><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></b></p>

<p class=MsoNormal>For memory sizes of interest to us, each 512 byte page has
an associated 16 byte spare data area. The usage of this area is specified by
the SM forum physical format specification. For the most part we will not be
compliant, but we will keep certain bytes as specified by the forum. The spare
area layout is then:</p>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<div align=center>

<table border=1 cellspacing=0 cellpadding=0 style='margin-left:1.2in;
 border-collapse:collapse;border:none;mso-border-alt:solid windowtext .5pt;
 mso-padding-alt:0in 5.4pt 0in 5.4pt'>
 <tr>
  <td width=180 valign=top style='width:135.0pt;border:solid windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <h1>Spare Area Byte Position</h1>
  </td>
  <td width=295 valign=top style='width:221.4pt;border:solid windowtext .5pt;
  border-left:none;mso-border-left-alt:solid windowtext .5pt;padding:0in 5.4pt 0in 5.4pt'>
  <h1 align=center style='text-align:center'>Value</h1>
  </td>
 </tr>
 <tr>
  <td width=180 valign=top style='width:135.0pt;border:solid windowtext .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoNormal align=center style='text-align:center'>512</p>
  </td>
  <td width=295 valign=top style='width:221.4pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>
  </td>
 </tr>
 <tr>
  <td width=180 valign=top style='width:135.0pt;border:solid windowtext .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoNormal align=center style='text-align:center'>513</p>
  </td>
  <td width=295 valign=top style='width:221.4pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>
  </td>
 </tr>
 <tr>
  <td width=180 valign=top style='width:135.0pt;border:solid windowtext .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoNormal align=center style='text-align:center'>514</p>
  </td>
  <td width=295 valign=top style='width:221.4pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>
  </td>
 </tr>
 <tr>
  <td width=180 valign=top style='width:135.0pt;border:solid windowtext .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoNormal align=center style='text-align:center'>515</p>
  </td>
  <td width=295 valign=top style='width:221.4pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>
  </td>
 </tr>
 <tr>
  <td width=180 valign=top style='width:135.0pt;border:solid windowtext .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoNormal align=center style='text-align:center'>516</p>
  </td>
  <td width=295 valign=top style='width:221.4pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoNormal>Data Status</p>
  </td>
 </tr>
 <tr>
  <td width=180 valign=top style='width:135.0pt;border:solid windowtext .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoNormal align=center style='text-align:center'>517</p>
  </td>
  <td width=295 valign=top style='width:221.4pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoNormal>Block Status</p>
  </td>
 </tr>
 <tr>
  <td width=180 valign=top style='width:135.0pt;border:solid windowtext .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoNormal align=center style='text-align:center'>518</p>
  </td>
  <td width=295 valign=top style='width:221.4pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>
  </td>
 </tr>
 <tr>
  <td width=180 valign=top style='width:135.0pt;border:solid windowtext .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoNormal align=center style='text-align:center'>519</p>
  </td>
  <td width=295 valign=top style='width:221.4pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>
  </td>
 </tr>
 <tr>
  <td width=180 valign=top style='width:135.0pt;border:solid windowtext .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoNormal align=center style='text-align:center'>520</p>
  </td>
  <td width=295 valign=top style='width:221.4pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoNormal>ECC1</p>
  </td>
 </tr>
 <tr>
  <td width=180 valign=top style='width:135.0pt;border:solid windowtext .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoNormal align=center style='text-align:center'>521</p>
  </td>
  <td width=295 valign=top style='width:221.4pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoNormal>ECC1</p>
  </td>
 </tr>
 <tr>
  <td width=180 valign=top style='width:135.0pt;border:solid windowtext .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoNormal align=center style='text-align:center'>522</p>
  </td>
  <td width=295 valign=top style='width:221.4pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoNormal>ECC1</p>
  </td>
 </tr>
 <tr>
  <td width=180 valign=top style='width:135.0pt;border:solid windowtext .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoNormal align=center style='text-align:center'>523</p>
  </td>
  <td width=295 valign=top style='width:221.4pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>
  </td>
 </tr>
 <tr>
  <td width=180 valign=top style='width:135.0pt;border:solid windowtext .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoNormal align=center style='text-align:center'>524</p>
  </td>
  <td width=295 valign=top style='width:221.4pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>
  </td>
 </tr>
 <tr>
  <td width=180 valign=top style='width:135.0pt;border:solid windowtext .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoNormal align=center style='text-align:center'>525</p>
  </td>
  <td width=295 valign=top style='width:221.4pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoNormal>ECC2</p>
  </td>
 </tr>
 <tr>
  <td width=180 valign=top style='width:135.0pt;border:solid windowtext .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoNormal align=center style='text-align:center'>526</p>
  </td>
  <td width=295 valign=top style='width:221.4pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoNormal>ECC2</p>
  </td>
 </tr>
 <tr>
  <td width=180 valign=top style='width:135.0pt;border:solid windowtext .5pt;
  border-top:none;mso-border-top-alt:solid windowtext .5pt;padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoNormal align=center style='text-align:center'>527</p>
  </td>
  <td width=295 valign=top style='width:221.4pt;border-top:none;border-left:
  none;border-bottom:solid windowtext .5pt;border-right:solid windowtext .5pt;
  mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid windowtext .5pt;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoNormal>ECC2</p>
  </td>
 </tr>
</table>

</div>

<p class=MsoNormal align=center style='text-align:center'><b>Table 2. </b>Nand-Flash
spare data usage.<b><o:p></o:p></b></p>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal>The Data Status indicates if this page contains valid data.
If a bit were to be in error, the ECC mechanism would be capable of correcting
this. This is 0xFF for good data. If 4 or more bits are 0, the data is bad
(note that a 0x00 would be written, but the 4 bits of 0 rule is to take bad
bits into account).</p>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal>The Block Status indicates if the block is good or bad.
Since there are a number of pages per block (generally 32, but maybe more for
larger storage capacities) this value is used redundantly. The value 0xFF
indicates a good block. A defective block will contain 0x00. A late failure
block will have 0xF0. If 2 or more bits are 0 the block is bad. Most nand-Flash
being shipped uses this format.</p>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal>The ECC1 bytes apply to data bytes 0-255, while the ECC2
bytes apply to data bytes 256-511. Keeping the same placement and scheme for
the ECC bytes will make our hardware ECC mechanisms applicable to SM storage as
well. A description of the ECC scheme is beyond the scope of this document.</p>

<p class=MsoNormal><b><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></b></p>

<p class=MsoNormal><b><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></b></p>

<p class=MsoNormal><b>Example<o:p></o:p></b></p>

<p class=MsoNormal><b><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></b></p>

<p class=MsoNormal>NEED TO ADD THIS.</p>

<p class=MsoNormal><b><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></b></p>

<p class=MsoNormal><b><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></b></p>

<p class=MsoNormal><b>Ping-pong model for FAT and license file backup<o:p></o:p></b></p>

<p class=MsoNormal><b><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></b></p>

<p class=MsoNormal>This is accomplished by incrementing the sequence number
each time a FAT block is written, and alternating between the 2 FAT blocks for
each successive write. If power were to be lost following an erasure, the
sequence number for that block would be invalid, and the other block would be
used. The sequence number is always written last, so it essentially commits a
new, current FAT block.</p>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal><b><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></b></p>

<p class=MsoNormal><b>Startup sequence and the SK<o:p></o:p></b></p>

<p class=MsoNormal><b><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></b></p>

<p class=MsoFootnoteText><span style='mso-bidi-font-size:12.0pt'>Certain
aspects of this FS are designed to simplify the interaction between both the
boot-ROM and the SK with flash. A detailed description of this interaction is
given in a separate document, <a
href="http://intwww/bb/rf/doc/browser/bootup.html">BB Startup and Code
Partitioning</a>, but a summary is provided here.<o:p></o:p></span></p>

<p class=MsoFootnoteText><span style='mso-bidi-font-size:12.0pt'><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></p>

<p class=MsoFootnoteText><span style='mso-bidi-font-size:12.0pt'>The initial
boot is handled by boot-ROM. This code only functions to bootstrap the SK. To
make locating the SK as simple as possible, the SK is always located in the
first good blocks of permanent flash. Since the SK is a fixed size, the number
of blocks it occupies will be known.<o:p></o:p></span></p>

<p class=MsoFootnoteText><span style='mso-bidi-font-size:12.0pt'><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></p>

<p class=MsoFootnoteText><span style='mso-bidi-font-size:12.0pt'>The SK works
in conjunction with a first application called the browser app (BA).<span
style="mso-spacerun: yes"> </span>The SK will perform the minimum set of tasks
on its own before launching the BA. The two major tasks requiring SK and FS
interaction are launching the BA, and recovery (NOTE: recovery is no longer
handled through the SK, but this section will be left in case the need arises
again).<o:p></o:p></span></p>

<p class=MsoFootnoteText><span style='mso-bidi-font-size:12.0pt'><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></p>

<p class=MsoFootnoteText><span style='mso-bidi-font-size:12.0pt'>To launch the
BA, the SK must be able to find the BA license, load the license, find the BA
content and load that. The BA license is held as the first entry in the license
file. The license file starting block resides as the first entry in the root
file system. The root file system data is stored in a known location on one of
the last 2 good blocks at the end of permanent storage. To determine which of
the last blocks to use the sequence number for the 2 blocks in question is
examined. Thus, finding the BA license data and loading requires:<o:p></o:p></span></p>

<p class=MsoFootnoteText style='margin-left:.5in;text-indent:-.25in;mso-list:
l8 level1 lfo9;tab-stops:list .5in'><![if !supportLists]><span
style='mso-bidi-font-size:12.0pt'>1.<span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span style='mso-bidi-font-size:12.0pt'>locate the last
two good blocks according to physical format field Block Status from Table 2.<o:p></o:p></span></p>

<p class=MsoFootnoteText style='margin-left:.5in;text-indent:-.25in;mso-list:
l8 level1 lfo9;tab-stops:list .5in'><![if !supportLists]><span
style='mso-bidi-font-size:12.0pt'>2.<span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span style='mso-bidi-font-size:12.0pt'>Read the
sequence numbers from a fixed offset into each of these blocks. The block to
use for reading the root directory has the higher valid sequence number.<o:p></o:p></span></p>

<p class=MsoFootnoteText style='margin-left:.5in;text-indent:-.25in;mso-list:
l8 level1 lfo9;tab-stops:list .5in'><![if !supportLists]><span
style='mso-bidi-font-size:12.0pt'>3.<span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span style='mso-bidi-font-size:12.0pt'>Read a fixed
offset into the block from the previous step to determine the license file
starting block.<o:p></o:p></span></p>

<p class=MsoFootnoteText style='margin-left:.5in;text-indent:-.25in;mso-list:
l8 level1 lfo9;tab-stops:list .5in'><![if !supportLists]><span
style='mso-bidi-font-size:12.0pt'>4.<span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]><span style='mso-bidi-font-size:12.0pt'>Read the BA
license data from the beginning of the block from the previous step.<o:p></o:p></span></p>

<p class=MsoFootnoteText><span style='mso-bidi-font-size:12.0pt'><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></p>

<p class=MsoFootnoteText><span style='mso-bidi-font-size:12.0pt'>The BA content
could be located using steps similar to those for finding the license. This
isnt necessary, however, since the BA blocks will always be located in
sequence, directly following the SK blocks, within the first good blocks of
permanent storage. The number of blocks to load can be determined from the
license data.<o:p></o:p></span></p>

<p class=MsoFootnoteText><span style='mso-bidi-font-size:12.0pt'><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></p>

<p class=MsoFootnoteText><span style='mso-bidi-font-size:12.0pt'>Recovery will
potentially require the SK to write the BA content, but not the license.
Because the BA is located on the initial good blocks of permanent storage, the
SK will simply write the BA starting from the first good block and moving
forward. The BA is launched directly after this, and will complete the recovery
process by obtaining and writing its license. During recovery, the BA should
be launched with a code passed from the SK indicate recovery is in progress.
This allows the BA to perform the license download and writing, and perform any
FS fixes to recover from the SK BA writing. The BA can perform fixes by
determining which blocks were written with the new BA and comparing this to the
FAT entries.<o:p></o:p></span></p>

<p class=MsoFootnoteText><span style='mso-bidi-font-size:12.0pt'><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></p>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<h1><span style='color:red'>Known Issues</span><span style='color:red;
font-weight:normal'><o:p></o:p></span></h1>

<h1><span style='color:red;font-weight:normal'><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></h1>

<h1><span style='color:red;font-weight:normal'>Need a size/type field,
probably one byte, added to the FAT end to indicate device size. This will also
indicate the block size, which is 8KB for 8MB devices, 16KB for 16-128MB
devices.<o:p></o:p></span></h1>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

<p class=MsoNormal><span style='color:red'>Really need to nail down versioning,
since want to recycle old licenses when we get newer version.<o:p></o:p></span></p>

<h1><span style='font-weight:normal'><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></h1>

<p class=MsoNormal><![if !supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

</div>

<div style='mso-element:footnote-list'><![if !supportFootnotes]><br clear=all>

<hr align=left size=1 width="33%">

<![endif]>

<div style='mso-element:footnote' id=ftn1>

<p class=MsoFootnoteText><a style='mso-footnote-id:ftn1' href="#_ftnref1"
name="_ftn1" title=""><span class=MsoFootnoteReference><span style='mso-special-character:
footnote'><![if !supportFootnotes]>[1]<![endif]></span></span></a> The SK will
need to parse enough of the FAT/root-directory block to determine the license
file first block location. It is conceivable to use this blocks spare area in
flash storage to mark this block, then have the kernel simply search for the
mark (beginning at the last block and working backward). This would complicate
error recovery scenarios, though.</p>

</div>

</div>

</body>

</html>