wooya510’s blog

x86에서 간단히 사용할 수 있는 방법을 적어 보았습니다.
간단하지만 유용하게 사용되길 바랍니다…

■ Test 환경
- WinCE5.0 + VIA(PLE) 800 + HDD(DOM 256MB)

■ Test 방법

1. 아래 컴포넌트를 추가
- Hive-based Registry, FAT File System, ATAPI PCI/IDE Storage Block Driver

2. PB Menu > Platform > Settings…에서 Environment 탭으로 이동하고 New하여 아래 환경변수 추가
- PRJ_BOOTDEVICE_ATAPI = 1
- PRJ_ENABLE_FSMOUNTASROOT = 1
- PRJ_ENABLE_FSREGHIVE = 1

3. PB Menu > Sysgen > Build OS > Sysgen 하여 다시 Build 함.
4. OS Download 후 레지스트리를 변경하고 다시 부팅한다.(레지스트리가 변경된 것으로 되어 있는지 확인).
5. Hive완료.

In Platform Builder, when you choose to build a run-time image based on an operating system (OS) design, the build system executes sequential phases:

1. The Compile Phase
2. The Sysgen Phase
3. The Release Copy Phase
4. The Make Run-Time Image Phase

Each phase also executes a secondary phase defined as the Localize phase, when resources and executables are translated into selected locales. For more information about localization, see OS Localization.

The build system completes the following tasks during these phases:

1. Generates header files
2. Links modules
3. Copies the resulting modules to a release directory
4. Generates a run-time image

Target devices can include a variety of devices, including the Emulator or a CEPC. For more information, see
Emulator and
How to Set Up a CEPC.

The following image map shows the sequence of large-scale tasks in the build process.

To link to topics containing information about the elements in the image map, move your pointer over the element and then choose the element.

Windows CE 5.0 – Include some files in the O/S

source : http://blogs.msdn.com/mikehall/archive/2004/07/26/197337.aspx 

This question has come up a number of times recently – You’ve built your Windows CE 5.0 operating system, you’ve written the worlds coolest Windows CE application in eMbedded Visual C++ or Visual Studio .NET 2003 and now want to include the applicaiton and a bunch of support files into the final operating system image – but how to make this happen ?

There are a number of steps needed to add a new file or application to the operating system.

First, the file(s) need to be in your _FLATRELEASEDIR, this is the build release directory – typically C:\Wince500\PBWorkspaces\<Your_Workspace>\RelDir\ – you would normally expect to find a Debug and Release subfolder here – so you need some way to copy your files into this folder.

Second, you *may* have registry information associated with your application or driver, so you need to be able to add your own .REG file or modify the existing project.reg

Next, you might want to have specific O/S dependencies for your application – what if your application is a C# .NET Compact Framework application, in this case you would want to set dependencies on SYSGEN_DOTNET – and possibly other O/S dependencies – you could add these dependencies through the Platform | Setitngs menu option, but this would set the dependencies for this build of the O/S – if you generate another platform that also included this application then you would also need to remember to set the environment variables for the new platform.

And what about setting the startup location of the application – by default all application binaries for the O/S are in the \windows folder, you might want to auto-start your application at boot time, in this case you can either add a [HKLM\Init] key to the registry or map the application to the \Windows\Startup folder – and this needs modifications to a .DAT file.

So, right now you need to modify .BIB, .REG, .DAT files, set SYSGEN dependencies through Platform | Settings, and also somehow copy your applicaiton and support files to the _FLATRELEASEDIR – sounds like a ton of work to accomplish what would appear to be a simple task, right ?

Wouldn’t it be SO much easier to have an ‘atomic’ stand-alone component that contained it’s own BIB, REG, DAT, DB files, that also contained the set of O/S dependencies needed on the O/S, and lived in the catalog so it was portable between operating system platforms ? (and could be shared with other developers). You Bet !

As mentioned earlier, I had a number of questions about adding an application to a Windows CE 5.0 O/S image that I decided to write an FAQ around this process – I got about 30 minutes into the process and then decided to give up ! – Was this because I’d not had my Grande Vanilla Latte for the day ? – no, it’s because I decided the best way to do would be to create a tool that makes this process simple.

Introducing CEFileWiz - a ”Skunk” development project that will hopefully save you a ton of time when adding files or applications to a Windows CE 5.0 O/S image.

Here’s how the UI looks…

Simply add your files (notice how the application will automatically show the files/applications in FILES or MODULES sections) – Also note how, when you add a .NET Compact Framework application that the application is added to the FILES section – this is needed for the .NET Compact Framework application to run correctly on the Windows CE device.

That’s the files added to the “component” – what about setting dependencies on the O/S ? – simple, click the “Add SYSGEN’s” button and start adding SYSGEN variables – what ? – you don’t know what the SYSGEN is that you need ? – go take a look at the catalog in Platform Builder – right click on a component and hit the SYSGEN tab – here’s the SYSGEN information for the .NET Compact Framework

The CEFileWiz application detects that an application is .NET Compact Framework and automatically adds the appropriate SYSGEN’s to the project, like so – you can see that SYSGEN_DOTNET, DOTNET_SUPPORT, and VS_SD_AUTH (the Visual Studio .NET 2003 Smart Device Authentication Utilities) have all been added to the project – you can also add your own SYSGEN’s to the project, for example adding SYSGEN_HTTPD would add the HTTP Web Server to your O/S image.

So, that leaves three items to complete.

Component Name- This is the, errr, ummm, name of the component as you want it to appear in the Windows CE 5.0 Catalog.

Platform – Select the Windows CE 5.0 Platform you want to add this project folder to

Device Folder- Where you want the files to be mapped in the O/S image (by default this is the \Windows folder) – if you want your application in the \Windows\Startup Folder then simply change the text to be \Windows\Startup – the project will create any folders that don’t exist in the O/S image.

and now, hit Build… That’s it ! – your component is now created… Here’s how the output folder looks.

Notice the list of files that have been created in the output folder.

Foo.bib – the files to be added to the O/S image
Foo.cec – the .CEC file to be added to Platform Builder
Foo.dat – Folders to be created in the O/S
Foo.db – Database (normally empty)
Foo.pbpxml – the workspace file (pointed to by the .CEC file)
Foo.reg – the registry file (add your custom registry information here)
makefile – Makefile
postlink.bat – This batch file is called in the build process and copies all the files in this component to the _FLATRELEASEDIR
prelink.bat – Empty (dummy) batch file
projsysgen.bat – the projsysgen.bat file adds the O/S dependencies to the O/S (through the SYSGEN variables)
readme.txt – a list of what’s been added to this component.
sources – makefile for the component

All we need to do now is add the .CEC file that’s been created to Platform Builder – in Platform builder, go to File | Manage Catalog Items, add the .CEC file you’ve just created, then, under Third Party Components either drag your new component over to your platform workspace or right click and “add”.

Now build your platform – that’s it ! – A couple of clicks, add some dependency information and you’re all set to have a stand-alone component that exposes it’s own set of registry information, folders, BIB, etc…

Let me know if this tool is at all useful…

- Mike

FSRAMPERCENT는 전체메모리에서 얼마를 storage로 사용할것인가를 정하는것입니다. FSRAMPERCENT는 총 4 byte로 구성됩니다. 첫 3byte가 의미하는것은(0xN) 2MB RAM에서 MB당 4KB block *N를 storage로 사용하겠다는 것입니다. 4번째 byte는 나머지 RAM에 대해서 MB당 4KB block *N를 storage로 사용한다는 의미입니다. 예를들면 FSRAMPERCENT=0X10203040이라고 하면 첫번째 byte 0×40이 의미하는것은 첫번째 2MB중에서 MB당 256KB(4KB*0×40)를 storage로 사용한다는 말입니다. 결국 512KB가 storage로 할당됩니다. 나머지 1.5MB는 program memory로 사용됩니다. 두번째 byte 0×30은 두번째 2MB중에서 MB당 192KB(4KB*0×30)를 storage로 사용한다는 말입니다. 그래서, 384KB가 storage로 사용되고 나머지 (2MB-384KB)가 program memory로 사용됩니다. 이런식으로 계산해서 각각을 다 더하면 전체 메모리에서 storage vs program memory의 사용량이 결정됩니다.

http://www.microsoft.com/korea/eseminar/Seminar_player7.aspx?number=933&asf=300K

Oringin : http://blogs.msdn.com/sloh/archive/2005/02/25/380475.aspx 

I want to blog about how to resolve symbols manually, and realized I would have to assume that the reader would understand the CE VM layout.  So I figure I’d better explain that first.  You don’t need to know everything about the VM layout in order to work with Windows CE, but it can be handy at times to at least understand the basics.  You need to understand some of it in order to be effective at debugging.

There are a few spots in this discussion that I could go into more “whys” but I avoided them because the answers aren’t necessary in order to debug.  We can discuss them separately if they bug you.

Anybody who has worked with CE for very long knows that there are a maximum of 32 processes, and each process gets a maximum of 32MB of virtual address space to work inside.  Part of the reason for that is because Windows CE keeps all processes’ address spaces available at all times, even when those processes are not running.  What it means is that the lower part of the address space is split into 32MB “slots.”  The important details to internalize are:

• 32MB in hex is 0×02000000
• Slot 0 is 0×00000000 through 0×01FFFFFF
• Slot 1 is 0×02000000 through 0×03FFFFFF
• The last process ends at 0×41FFFFFF
• Memory from 0×42000000 to 0×7FFFFFFF is mostly the “shared area” used for VirtualAllocs and memory-mapped files.  In other words there will never be any symbols there.
• Memory above 0×80000000 is “kernel stuff” – the kernel does run there, as well as DLLs that load into the kernel, like installable interrupt service routine (ISR) DLLs.

If you do the math, that adds up to 33 slots.  Slots 0 & 1 are special slots that aren’t used by processes, and I’ll explain that in a bit.  That leaves 31 slots for process to run inside – and the 32nd process is the kernel, which lives elsewhere in RAM somewhere above the 0×80000000 mark.  [OK detail hounds, in CE 3.0 and earlier, the kernel ran in slot 1 instead of in the upper 2GB.]

Slot 0 is a special slot whose contents change depending on what process is running.  The current process is always mapped into slot 0 in addition to having its own unique slot.  Most of the addresses a processes is given to work with, are in slot 0.  Get the address of a variable or function from an EXE in the debugger, and you’ll see something like 0×00012345.  But if that variable is from a process that’s running in the slot from 0×12000000 to 0×13FFFFFF, that same variable will be present at address 0×12012345.

• Try it out.  Break into the debugger while your EXE is running.  Use the Modules & Symbols Window to figure out what slot your process is in, then change a slot 0 address into one from the process slot and see if you get the same data.

Understanding slot 0 is actually very important for debugging.  If you hit the “break” button at a random time, your process might not be running at that time.  If you use the Watch Window to try to look at a global variable inside your process – the debugger might know what address the variable is at, without knowing the value of the variable.  For example, John Eldridge already blogged a bit about how to use the Watch Window to look at a variable inside a specific module.  Suppose you did this:

      Watch Window
      {,,helloworld.exe} &MyGlobalVar     0×00012345
      {,,helloworld.exe} MyGlobalVar      ???
 
If helloworld.exe isn’t the process that’s running at the moment you break into the debugger, the debugger knows what the address of the global variable is, but not the value.  But you can manually map the slot 0 address to the right slot, if you know what slot the process is running in.  If helloworld.exe is running in the slot starting at 0×12000000, then you can add the slot start address to the slot 0 address, like this:

      Watch Window
      {,,helloworld.exe} &MyGlobalVar     0×00012345
      {,,helloworld.exe} MyGlobalVar      ???
      *((DWORD*)0×12012345)               72

(yes, that’s not a DWORD-aligned address, please close your eyes if it bugs you)

Also, if you switch the debugger to helloworld.exe, it can figure things out.  I usually use the Callstack Window and select a thread from helloworld.exe to switch to.  Then the contents of the Watch Window might change.

      Watch Window
      {,,helloworld.exe} &MyGlobalVar     0×00012345
      {,,helloworld.exe} MyGlobalVar      72
 
The difference is that now the slot 0 address refers to the same slot the debugger is currently pointed at.

Slot 1 is also a special slot.  All DLLs that are stored in the “MODULES” section of ROM load in slot 1.  The code – not the data – for as many DLLs as possible loads in slot 1.  Only ROM DLLs load in slot 1.  If you drop a new copy of a DLL onto a device, to replace a DLL that was in ROM, that new DLL will not load in slot 1.

• Check it out.  Open the Modules & Symbols Window and view the addresses that various DLLs are loaded at.  Some will be in slot 0, some will be in slot 1.  A few will be in the kernel range.
• So now look back at the addresses John Eldridge posted on his blog entry, and you can see that the DLL addresses he posted were all from slot 1.

Slot 1 stays the same no matter what the current process is.  That’s why only code can load there; if two processes load the same slot 1 DLL, they will share the same code, but the two instances of the DLL will have different globals.  The globals are stored in the process slot – so they will most often be referenced in slot 0 just like everything else the process owns.

The main point to all of this description of slot 0 & 1 is that you need to understand when the memory you need to look at is process-specific, and how to view process-specific memory.  If a DLL loads into multiple processes, and you want to look at a global variable inside the DLL, the value could be different in different processes.  You need to know which process you’re looking at, and how to change it if necessary.

One other detail that’s handy to know, is that EXE code loads at the very bottom of the slot (closest to 0×00000000), while DLL code & data load from the top of the slot down (closest to 0×1FFFFFFF).  In between are heap allocations, thread stacks, small VirtualAllocs, and other “goodies” that don’t have symbols.

With practice you will develop one of the ninja debugging skillz: recognizing the location of an address just by looking at it.  Here’s some practice:

• 0×00012345 is probably code or global variables from an EXE.  0×0056789A is probably not.  Why?  Too big, that’s a gigantic EXE.  It’s more likely to be stack or heap, some other dynamically allocated memory, not EXE or DLL contents.  It’s easy to ballpark if you can look at the actual size of the EXE.
• 0×03123456 is a slot 1 DLL.  So is 0×02123456.
• Address 0×3456789A is inside the process that’s running in the slot that starts at 0×34000000; you can use the Modules and Symbols window to figure out which process that is.  But it’s most likely not code or global variables – for the exact same reason as 0×0056789A in my first bullet.  This is just a “slot-mapped” version of the same address.
• Address 0×019ABCDE is probably from a DLL.  It's near the top of the slot so it's more likely to be a DLL than heap or stack.  The same with 0×3519ABCDE.  Get used to noticing whether the 2nd nibble of the address is odd or even.
• Address 0×6789ABCD is not from a module.  Maybe something from VirtualAlloc or a memory-mapped file, but you’ll never find a symbol that matches that address.
• While we’re at it, okay, I am using bad sample addresses. 0×00012345 is not DWORD-aligned.  Things are much more likely to be aligned on a 4-byte boundary: ending in 0, 4, 8 or C.  Using consecutive numbers just seems more “friendly” to me, so I’m sorry if that bugs you.  If you noticed, then you already have some ninja debugging skillz.  It’s a good thing to be attuned to, since non-x86 processors can’t cope with accessing 4-byte values that are not 4-byte aligned.

Doug Boling, one of our MVPs, has written a paper that explains the virtual address space, and its implications, in much more detail.  You should review that if you have more questions.  I was just trying to cover the aspects that are important for debugging.

Next I’ll write about how to resolve symbols for addresses (how to go from address –> symbol), and after that I’ll write about the other direction, how to figure out an address for a particular function or variable (symbol –> address).

[Note: This applies to all Windows CE versions up through 5.0; with the exception I already noted about the kernel running in slot 1 in CE 3.0 and earlier.]