Re: Flash for persistent storage and hive based registry
From: Dean Ramsier (dramsiernospam_at_accelentnospam.com)
Date: 03/04/04
- Next message: Dean Ramsier: "Re: I2S Bus Driver"
- Previous message: Juan de la Cerda: "Re: Auto hiding Cursor"
- In reply to: A. User: "Re: Flash for persistent storage and hive based registry"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 4 Mar 2004 08:48:47 -0500
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 > > > > > >
- Next message: Dean Ramsier: "Re: I2S Bus Driver"
- Previous message: Juan de la Cerda: "Re: Auto hiding Cursor"
- In reply to: A. User: "Re: Flash for persistent storage and hive based registry"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
