About intel PSM(excerpt)
Storing code and Files in the same component or bank:
this configuration has two significant benefits:
1) It is lower cost.
2) It requires fewer components.
Code-size rarely matches the size of flash components,so if a component is dedicated to storing code,some portion of it will be wasted.If code and files are stored in a single device,whatever is not used by code can store files.
The net effect of all this is that when PSM is used in single component/bank configuration,the maximum interrupt latency will increas.
Storing code and files in separate components or bank:
While more expensive,this configuration has the highest performance.If the code and files are in separate components,no interrupt management is neccessary,and there will be no increase in the maximum interrupt latency.
Windows CE supports customized file systems using ths Installable File system(IFS) application program interface(API).This gives an OEM the capability of storing files on any media,but since the OS has no knowledge of what the media is,it relies completely on the OEM's file system,the IFS.to manage the media.The IFS must be able to handle all operations the OS performs on files and it must do so using the IFS API.
Intel PSM includes a complete file system for linear flash memory that adheres to the IFS API.
Intel PSM is complete,and most of it is in a .lib/.dll file.There is one source module that the OEM must edit,and then PB and the included build ".bat" file are used to create the final DLL.
Windows CE initializes the processors MMU and must be told what the memory map of the system is.This is done with a file that lists physical addresses,virtual addresses,and the nature of the memory space.If this table does not have an entry giving PSM access to the flash,it will be necessary to add one.
If a system will store both code and files in the same array controlled by a single chip select,and if that area has a MMU table entry,one need not be added.(Note that the physical addresses are fixed in hardware by particular CPU)
PSM needs to be told where the flash and file partition are located,and there is a structure,PSM_OEMInfo,in module Plat_api.c that does this.It lists the physical and virtual locations of flash along with other array parameters.so that PSM knows:
1) Where the flash array is.Both physical and virtual address are required.
2) Where the file partition is within the array.
3) What size accesses to use when writting to the array.
These addresses must correspond with those entered in the MMU initialization table.Beginning with PSM version 3.7,it is recommended that you use the cache region for these addresses for better performance.
Recall that some CPUs cannot write to a memory region that is read using page mode,so it is neccessary to use a second chip select to write to the flash.These are the addresses PSM should use to write to the flash,and they must correspond with those used in the initialization table.Writes must occur in the non-cache address region.
BurstReadBusWidth
This entry should normally be "0" for most platforms which use non-burst flash components(i.e.J3) or processors that do not support full burst memory.For burst capable processors and flash(i.e.,K3),this value should typically match the "ReadBusWidth" setting.
this configuration has two significant benefits:
1) It is lower cost.
2) It requires fewer components.
Code-size rarely matches the size of flash components,so if a component is dedicated to storing code,some portion of it will be wasted.If code and files are stored in a single device,whatever is not used by code can store files.
The net effect of all this is that when PSM is used in single component/bank configuration,the maximum interrupt latency will increas.
Storing code and files in separate components or bank:
While more expensive,this configuration has the highest performance.If the code and files are in separate components,no interrupt management is neccessary,and there will be no increase in the maximum interrupt latency.
Windows CE supports customized file systems using ths Installable File system(IFS) application program interface(API).This gives an OEM the capability of storing files on any media,but since the OS has no knowledge of what the media is,it relies completely on the OEM's file system,the IFS.to manage the media.The IFS must be able to handle all operations the OS performs on files and it must do so using the IFS API.
Intel PSM includes a complete file system for linear flash memory that adheres to the IFS API.
Intel PSM is complete,and most of it is in a .lib/.dll file.There is one source module that the OEM must edit,and then PB and the included build ".bat" file are used to create the final DLL.
Windows CE initializes the processors MMU and must be told what the memory map of the system is.This is done with a file that lists physical addresses,virtual addresses,and the nature of the memory space.If this table does not have an entry giving PSM access to the flash,it will be necessary to add one.
If a system will store both code and files in the same array controlled by a single chip select,and if that area has a MMU table entry,one need not be added.(Note that the physical addresses are fixed in hardware by particular CPU)
PSM needs to be told where the flash and file partition are located,and there is a structure,PSM_OEMInfo,in module Plat_api.c that does this.It lists the physical and virtual locations of flash along with other array parameters.so that PSM knows:
1) Where the flash array is.Both physical and virtual address are required.
2) Where the file partition is within the array.
3) What size accesses to use when writting to the array.
These addresses must correspond with those entered in the MMU initialization table.Beginning with PSM version 3.7,it is recommended that you use the cache region for these addresses for better performance.
Recall that some CPUs cannot write to a memory region that is read using page mode,so it is neccessary to use a second chip select to write to the flash.These are the addresses PSM should use to write to the flash,and they must correspond with those used in the initialization table.Writes must occur in the non-cache address region.
BurstReadBusWidth
This entry should normally be "0" for most platforms which use non-burst flash components(i.e.J3) or processors that do not support full burst memory.For burst capable processors and flash(i.e.,K3),this value should typically match the "ReadBusWidth" setting.
