Welcome to MSDN Blogs Sign in | Join | Help
Cache Me If You Can

There are generally two trends when creating new configurations- one group import their pmq into Component Designer and create a macro component out of them which they then import into Target Designer and can thereafter add to their configurations. The other group imports their pmq directly into Target Designer and this forms the basis of their configuration. However, with this second method, if you have to build a new configuration that uses that pmq you have to start from scratch and re-import the pmq which takes a significant chunk of time. You also encounter this time hit if you need to import multiple pmqs into Target Designer because you want to build an image for different sets of hardware.

For those using the second method there is an easy tweak you can make that will speed up this import process. It involves setting a registry key, so before I proceed let me stress that you need to use caution when changing anything in the registry, as you can possibly corrupt your OS. On your development machine (the machine that you have installed the XP Embedded suite of tools on):

  • Go to Start >Run
  • Type regedit to open the registry
  • Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Embedded\Target Designer
  • Right-click on the key and select "New > String Value"
  • Name the value "EnableCache"
  • Double-click the new Key value name and enter the value data as "True"

The result of this setting is that a cache of the component data in the database will be created the first time you import a pmq into the database. Thereafter, any subsequent pmq imports will utilize the cached data to resolve the data in the pmq to components, rather than having to research the entire database for this information. The cache will be valid for as long as your database remains the same, so any imports into the database of hot fixes, updates or custom components would render the cache out of date and a new cache would need to be created on the import of the next pmq.

- Lynda

Posted: Tuesday, August 07, 2007 1:41 PM by Embedded
Filed under:

Comments

Jeff said:

The two ways to get a PMQ into a build mentioned in this article are:

1. Import it each time (which is time consuming)

  OR

2. Set a reg key to cache it in the DB.

But, if the DB is restored to a clean DB, the user would have to reset this reg key each time.

A third option would be to create a generic SLX template that already has the PMQ imported, and does not require any reg changes.

Run Check Dependencies on it (resolving any additional  dependencies) and then save it.

When this PMQ is needed for a build, just open up this SLX, add in the components needed, and save it with a different name.

Then, run Check Dependencies and build it.

# August 22, 2007 12:58 PM

MattKell_MSFT said:

As mentioned in the article, you can also create a custom component in Component Designer that contains the driver mappings brought in by importing the PMQ.  Depending on your needs, this might be preferable to saving a template SLX, as there is less chance that you'll accidentally overwrite the template SLX with a completed runtime configuration.

Also, restoring the database (via dbrestore.vbs or another means) shouldn't have any impact on that registry key, since the key is not affected directly by database operations.  The key is owned by the XP Embedded Tools, so the only way I'm aware of for this key to be changed (other than changing it manually) would be to uninstall and reinstall the tools.  (It might get changed in Tools updates - not sure.)

Hope this helps. :)

-- Matt

# August 22, 2007 1:15 PM

Jeff said:

A backup of the SLX could be saved in another location just in case the one being used accidentally gets overwritten.

Also, with the custom component, it takes additional time during Check Dependencies because it is being run for the first time in the SLX.

If the template SLX has run Check Dependencies before saving, this will save a lot of time since this won't have to be done on each new SLX/Build made.

Just one less group of dependencies that need to be resolved when making a build. :)

Jeff

# August 22, 2007 1:35 PM

MattKell_MSFT said:

Good points. :)  The only argument I'd make against pre-resolving your hardware dependencies is that it might potentially introduce conflicts later on, such as for the version of NTLDR if you need to use EWF, or the version of NTDETECT should you decide to use USB Boot.  It's not a big deal, though - different development styles for different people. :)

Thank you for your comments.

-- Matt

# August 22, 2007 1:42 PM

Jeff said:

Correct.

I'd leave the Tasks like choosing "Minlogon vs Winlogon" and "NTLDR vs EWF", etc. as unresolved if they are going to change on a per build basis.

But, the rest of the dependencies (95%+) will already be pre-resolved, and save time. :)

Jeff

# August 22, 2007 1:52 PM
Leave a Comment

(required) 

(required) 

(optional)

(required) 

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Page view tracker