Freigeben über

Multi-function Update Loader

  • Artikel

Recently I was challenged with a flash corruption problem and was forced to figure out how to boot a RAM image (ie: image NOT stored to flash) on my p2Sample device. I thought I would be clever and start with a tiny_kernel image and simply add the filesystem components I needed to run my diagnostic tools. Unfortunately by the time I had trial & error’ed (emphasis on the error part) I was running into compatibility issues and certainly not saving any time.

 

Another developer suggested I simply boot with the Update Loader image since it already contains the filesystem information (it needs this to perform the actual update) and most importantly it loads into RAM. Using the Windows Mobile 5.0 AK system makes this extremely easy since SMARTFON and ULDR don’t share release directories – I simply clicked on the “Build ALL” shortcut and was halfway home.

 

Booting a generic Update Loader isn’t very helpful for most debugging purposes, we need to make some changes first:

 

1. Add Target Control  c:\wm520\buildscripts\smartfon_p2sample_retail\updateloaderenv.bat

…

REM Variables required by Optional Components

set SYSGEN_SHELL=1

REM Call passed in arguments so that BuildAll.bat can call blddemo.bat

%1 %2 %3 %4 %5 %6 %7 %8 %9

 

This will give you the Windows CE> prompt for debugging. Make certain that you close any build windows you have open and re-open them using the desktop shortcuts created by the AK

2. Replace updateApp.exe with private version

The Update Loader image will run an executable called updateApp.exe that is responsible for updating packages. Since this is not what we are after we need to replace the default updateApp.exe with our own private version that gives us the elbow-room to do what we want. The below test code will simply loop forever giving you time to debug your problem. Please feel free to copy the below code to a valid source file and program directory with a make file.

 

Personally, I like to include a message string that tells me I am running the correct version – if you don’t see the string in your debug output, chances are you are running the real updateApp.exe and not your test version.

 

// << begin sample code snippet >>

int WINAPI WinMain(

    HINSTANCE hInstance,

    HINSTANCE hPrevInstance,

    LPWSTR lpCmdLine,

    int iCmdShow)

{

    while(TRUE)

    {

        OutputDebugString(TEXT("Stuck in updateApp Main...."));

        Sleep(5000); // Adjust to suit

    }

}

// << end sample code snippet >>

 

You can either remake your image or use “Release Directory Modules” to load your private updateApp.exe to replace the default. Once booted, you should be able to see the periodic print statements in updateApp.exe displayed in the debug window. You should also have target control which will allow running additional tools to suit your debugging needs.

Comments