XIP vs RAM

From: A.User (a_user_at_home.com)
Date: 03/04/04 

Date: Thu, 4 Mar 2004 12:09:48 -0500

Thanks for the info Dean.
I copied to responses to a new discussion thread as the subject title really
did not apply.
Would like some more input if anyone else who would like to chime in.
I would think a biggey would be $$. Not having the OS in RAM would save
megabytes (my images are approaching 25Meg) this is now freeed for
scratch. Maybe the system can even get away with the next small size RAM
($$).
Does anyone know if/what the premimum of the "K" Strata FLASH is?

I would think the XIP OS would also be inherently more stable as it's
exicuting
from Read Only Memory, therefor there is less of a chance the OS could self
destruct
itsself??

Also what are the steps needed to transition to a XIP OS? I know the
bootloader
would need some work. Is it a simple matter of checking the "Enable image
for flash" ???

See inline... 

-- 
Dean Ramsier - eMVP
Accelent Systems
http://www.accelent.com
"A. User" <dve@byby.com> wrote in message
news:u00PCkeAEHA.2480@TK2MSFTNGP11.phx.gbl...
> I am very interested in Dean's comments.
>
> I was under the impression there was quite a difference between executing
> from Flash as opposed to RAM. Do you have any numbers?
>
> I would like to see a comparison ... something like this:
> feel free to expand and/or correct me where needed.
> All opinions welcome
>
> FLASH (XIP)
> Slower execution
Yes, Flash is slower than RAM, no question.  However, the impact can be
minimized by making use of high performance features in flash.  For example,
using the burst mode of regular J3 strataflash is much faster than standard
access.  If you switch over to using synchronous strataflash (K3) it's very
fast.  Approaches the performance of running from RAM.  Other techniques
include compressing modules that impact performance.  This causes them to be
decompressed and run from RAM.  Careful tuning of the system this way can do
wonders.
> Saves RAM, system needs less RAM as RAM is only needed for stack,heap,
> variables etc. and not OS
> bootup time faster.
> harder to setup (?)
Not sure where this comes from, booting from XIP flash is the simplest thing
possible.  There are no extra steps to be concerned about - just get the
image into flash and you're done.
> harder to do OS Flash upgrades
If you're upgrading from within the OS, yes.  It's very challenging to
upgrade flash when you're executing from it, for several reasons.  This is
why most solutions rely on the bootloader to do upgrades.  This can be a
shared task with the OS if desired and there's enough RAM available.
> does (not) work with debugger (??)
You can't step through code if it's in flash (the debugger can't set
breakpoints in ROM).  Other aspects of the debugger do work.  You can get
around this by loading the image into RAM when doing debugging.  You can
also set the C flag to compress the module you're interested in.  That will
cause the module to be loaded into RAM, where it can be debugged.
> does (not) work with emulators (??)
Don't know how this applies.  Why be concerned about where the image is
stored if you're running from an emulator?
>
> RAM
> traditional build
> faster
> on line FLASH OS upgrades easer as OS is in RAM
>
>
> I know some are subjective any other pros/cons you can think of ?
>
>
>
> "Dean Ramsier" <dramsiernospam@accelentnospam.com> wrote in message
> news:eMdf4mSAEHA.2348@TK2MSFTNGP09.phx.gbl...
> > Since you're using BinFS and not attempting to XIP from strataflash (a
> > questionable decision in my opinion) you should be able to use the NOR
> flash
> > driver available in PB.   In fact, since BinFS is already running, the
> block
> > driver is apparently already there.  All you need to do is get the
> registry
> > settings correct to format/partition/mount the remaining part of the
> flash.
> > The hive registry can then be targeted to that file system.  This can
all
> > happen automatically.
> >
> > Why are you choosing to use BinFS instead of executing directly from
> flash?
> > It's much more complicated, and comes with performance penalties over
> > executing directly in place.  The only advantage is that SDRAM is faster
> > than J3 flash, but paging code in and out will negate much or all of
that
> > advantage.  It also costs you RAM space.  BinFS is primarily intended
for
> > devices where the image is stored on a media that doesn't support XIP,
> NAND
> > flash.
> >
> > -- 
> > Dean Ramsier - eMVP
> > Accelent Systems
> > http://www.accelent.com
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Have an opinion on the effectiveness of Microsoft Embedded newsgroups?
> Tell
> > Microsoft!
> > https://www.windowsembeddedeval.com/community/newsgroups
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> >
> > "Fabio - ElettronicaGF" <fmelandri@elettronicagf.it> wrote in message
> > news:3ad3b9c6.0403030250.684fbadf@posting.google.com...
> > > Hi all,
> > > I'm a newbie in WCE.NET and Platform Builder 4.2 and i'm trying to
> > > understand how to use my on-board flash for the OS image and
> > > data/registry storaging.
> > > My platform is a pxa255 processor board with 32M strata flash (2 x
> > > 28f128j3a) and 64M sdram.
> > > My bootloader create a BINFS partition and an EXTENDED partition on
> > > the rest of the flash memory.
> > > The BINFS partition serves for the OS image (non-XIP mode).
> > > Is it possible to use the EXT partition for persistent storage and
> > > hive based registry ?
> > > Do I need for something like Intel IPSM or the NOR strata flash driver
> > > (from PB) and some registry settings (as I see in PB Help) are enough?
> > > Do I have to modify my bootloader to create a FAT partition instead of
> > > an EXTENDED?
> > > Now, when my platform boot, I can see (with stguil) only a BINFS
> > > partition.
> > > I would like to have the storage/registry partition automatically
> > > created at boot time, is it possible?
> > >
> > >
> > > Thanks in advance,
> > > best regards.
> > >
> > > Fabio Melandri
> > > ElettronicaGF
> >
> >
>
>

Relevant Pages

  • Re: What File System supports Application XIP
    ... > You won't gain at runtime by using XIP though. ... I thought that when you XIPed from flash, ... directly back to the flash memory address. ... There shouldn't be a RAM ...
    (Linux-Kernel)
  • RE: Dynamically partitoning flash memory from Bootloader.
    ... I could find some E-boot source somewhere in the bulverde 4.2 bsp, ... "Program RAM Image into Flash". ... This one actuallly donwloads the Nk.bin RAMIMAGE (Write Image to flash ... disabled), in to the RAM, Creates a partition in the flash (one for storing ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Flash for persistent storage and hive based registry
    ... > from Flash as opposed to RAM. ... Yes, Flash is slower than RAM, no question. ... In fact, since BinFS is already running, the ... >>> My bootloader create a BINFS partition and an EXTENDED partition on ...
    (microsoft.public.windowsce.platbuilder)
  • Re: [RFC] Advanced XIP File System
    ... > expensive slow flash instead of cheap fast RAM?" ... If I store libfoo.so as an XIP ... But the JFFS2 version would need ...
    (Linux-Kernel)
  • Re: [RFC] Advanced XIP File System
    ... borrow the compression from Squashfs. ... expensive slow flash instead of cheap fast RAM?" ... If I store libfoo.so as an XIP ... 2MiB of RAM to store that library when used while the XIP system uses ...
    (Linux-Kernel)