Re: Configuring RAM to 256MB on CEPC - Windows Mobile 5.0 ??

(a) The Mobile Windows 5 I installed on my PPC was not an OEM
version/upgrade. It was installed from VS2005 when I created and ran a Mob
Windows 5 app on my device (having installed the Win Mob. 5 development
tools/SDK for VS 2005).
(b) I was was just stating that for an "ordinary" CE developer using PB
that Win Mobile 5 is not an option.
(c) I was unaware that there was a platform tree form Win Mobile 5 for CE,
but then I guess its needed for Win Mobile 5 phones etc.

(Q) Will this be made generally available as a feature pack for CE or in the
next version?

Thanks for the clarifications.

--
David Jones
Senior Lecturer
School of Electrical & Computer Engineering
RMIT University
+61 3 99255318


"Dean Ramsier" wrote:

You're confused on what's really going on. You downloaded an upgrade from a
device manufacturer that allowed your particular device to move from PPC2003
to WM5. That upgrade is only available for your device, and is a binary
release. You can't install it on any other device, including a CEPC.

The original poster is a device builder - he has access to the actual
WindowsMobile tree with source code based on the contents of the post. He
is building the operating system, you are just using one provided by your
OEM. Since he has the tree, he can do a build targeted to any CPU supported
by the tree, including X86 if that exists.

--
Dean Ramsier - eMVP
BSQUARE Corporation


"David Jones" <davejones@xxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:B008D4E8-066A-41D2-BE4F-D9DDAE4C8457@xxxxxxxxxxxxxxxx
Whilst I have downloaded Windows Mobile 5.0 to my PPC 2003 and it works
OK, I
undertsood that an embedded CE system (eg CEPC) created from Platform
Builder
5.0, running activesysnch, .NETCF won't support Windows Mobile 5. I
haven't
tried this.
--
David Jones
Senior Lecturer
School of Electrical & Computer Engineering
RMIT University
+61 3 99255318


"Dean Ramsier" wrote:

Windows Mobile is based on CE5, and doesn't really have any dependencies
that CE5 can't support. This post does appear to be in reference to a
build
on WindowsMobile, but not for a real device since the CPU in question is
x86. That tree is usually always present because many developers use it
as
a test platform.

--
Dean Ramsier - eMVP
BSQUARE Corporation


"David Jones" <davejones@xxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:E6F7FF4F-E2C1-4E06-A690-48F1A9622351@xxxxxxxxxxxxxxxx
I thought Windows Mobile 5 was not available for Windows CE 5?
When you say Windows Mobile 5 do you mean Windows CE 5?

Windows Mobile 5 has significant hardware considerations not addressed
by
CE5.
It came out 12 months after CE5.

--
David Jones
Senior Lecturer
School of Electrical & Computer Engineering
RMIT University
+61 3 99255318


"Sathish" wrote:

Hi Guys,

I am using Windows Mobile 5.0. The CEPC has 256MB of RAM, but when i
see the memory tab in "start->settings->system->memory" tab it shows
that there is only 15MB program and around 97MB storage memory. I have
made some changes in config.bib, oeminit.asm and startup.asm to make
my
CEPC recognize the 256MB ram, but i see that it's of no use.

The changes made are as follows

config.bib:

RAMFMD 80200000 01000000 RESERVED
NK 81200000 00A00000 RAMIMAGE
RAM 81C00000 E400000 RAM

startup.asm:

_OEMAddressTable:
;
; OEMAddressTable defines the mapping between Physical and
Virtual Address
; o MUST be in a READONLY Section
; o First Entry MUST be RAM, mapping from 0x80000000 ->
0x00000000
; o each entry is of the format ( VA, PA, cbSize )
; o cbSize must be multiple of 4M
; o last entry must be (0, 0, 0)
; o must have at least one non-zero entry

; RAM 0x80000000 -> 0x00000000, size 64M
; dd 80000000h, 0, 04000000h
dd 80000000h, 0, 10000000h

; FLASH and other memory, if any
; dd FlashVA, FlashPA, FlashSize

; Last entry, all zeros
dd 0, 0, 0

oeminit.asm:

_OEMAddressTable:
;
; OEMAddressTable defines the mapping between Physical and
Virtual Address
; o MUST be in a READONLY Section
; o First Entry MUST be RAM, mapping from 0x80000000 ->
0x00000000
; o each entry is of the format ( VA, PA, cbSize )
; o cbSize must be multiple of 4M
; o last entry must be (0, 0, 0)
; o must have at least one non-zero entry

; RAM 0x80000000 -> 0x00000000, size 64M
;dd 80000000h, 0, 04000000h
dd 80000000h, 0, 10000000h

; FLASH and other memory, if any
; dd FlashVA, FlashPA, FlashSize

; Last entry, all zeros
dd 0, 0, 0

After these changes, i have executed the following commands in the
path
"C:\WM500\PUBLIC\COMMON\OAK\CSP\X86\OAL"

1. build
2. sysgen i486oal
3. Blddemo -c clean cleanplat

After all these changes, i see no result.

Can you guys tell me whether what i've done is right or wrong? Also
can
you tell me what to do, if i've done it wrong or missed something.

Thanks,
Sathish








.

Relevant Pages

  • Re: Tree style property sheet
    ... The CTtreePropSheet has a feature that allows you to have a small image next to each entry in the tree. ... Some of them in the screenshots on the codeproject atricles look familiar so I guess they must be part of Windows. ...
    (microsoft.public.vc.mfc)
  • Re: Executable enty points incorrectly documented
    ... All these things are correct but this is more specific and related to the .NET Framework than to Windows API and the C++ linker and does not mention the actual entry point signatures either. ... The documentation problem to which you allude is that it is the CRT entry point that calls one of the versions of main / WinMain that is defined in your program. ... This is the signature of the managed entry point that has nothing to do with native executables/DLLs. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Executable enty points incorrectly documented
    ... You wrote that WinMain is not a starting function in CRT, but an user-defined entry point for a Windows application. ... I believe that the fact that this function is called by the C/C++ runtime clearly backs my opinion that WinMain has nothing to do with the operating system. ... Even if WinMain documentation remains in Windows SDK it would be wise to explicitly state that support for this entry point is provided by the C/C++ runtime rather than Windows itself. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Executable enty points incorrectly documented
    ... I was speaking about Windows SDK not MSDN Library entirely, but even if Windows SDK conatins C/C++ documentation I believe that main/WinMain belong to C/C++ documentation rather than Windows API documentation. ... It's correct about the default entry point names used by the linker and also correct about what those entry points call and because this is the ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Executable enty points incorrectly documented
    ... The function signature is there though ... belong to C/C++ documentation rather than Windows API documentation. ... As for the entry point signature: ...
    (microsoft.public.win32.programmer.kernel)