I am working with the Intel IXDP425 BSP so I installed the
ARMV4I QFE's for 4.2 (there were 2 of them). After doing
so when I go back to my CEPC project, I am getting the
following linker errors:

z:\wince420\platform\cepc\sboot\main.obj() : error
LNK2019: unresolved external symbol _READ_PORT_UCHAR
referenced in function _OEMPlatformInit
z:\wince420\platform\cepc\sboot\debug.obj() : error
LNK2001: unresolved external symbol _READ_PORT_UCHAR
z:\wince420\platform\cepc\sboot\main.obj() : error
LNK2019: unresolved external symbol _WRITE_PORT_UCHAR
referenced in function _OEMPlatformInit
z:\wince420\platform\cepc\sboot\debug.obj() : error
LNK2001: unresolved external symbol _WRITE_PORT_UCHAR
z:\wince420\platform\cepc\target\x86\debug\sboot.exe() :
error LNK1120: 2 unresolved externals

I attempted to go back and reinstall the QFE's for the x86
but that didn't fix my problem.

Any guesses on what this problem might actually be?

Thanks
Wally

Re: Possible Problem with x86 after installing ARMV4I QFE by Vika

Vika
Tue Jan 13 22:05:36 CST 2004

What QFEs you have installed that cause the problem?
You said you installed ARMV4I QFEs, but the project you build is CEPC.
What CEPC configuration you try to build?

Victoria

"Wally" <anonymous@discussions.microsoft.com> wrote in message
news:017301c3da15$2bebfc00$a601280a@phx.gbl...
> I am working with the Intel IXDP425 BSP so I installed the
> ARMV4I QFE's for 4.2 (there were 2 of them). After doing
> so when I go back to my CEPC project, I am getting the
> following linker errors:
>
> z:\wince420\platform\cepc\sboot\main.obj() : error
> LNK2019: unresolved external symbol _READ_PORT_UCHAR
> referenced in function _OEMPlatformInit
> z:\wince420\platform\cepc\sboot\debug.obj() : error
> LNK2001: unresolved external symbol _READ_PORT_UCHAR
> z:\wince420\platform\cepc\sboot\main.obj() : error
> LNK2019: unresolved external symbol _WRITE_PORT_UCHAR
> referenced in function _OEMPlatformInit
> z:\wince420\platform\cepc\sboot\debug.obj() : error
> LNK2001: unresolved external symbol _WRITE_PORT_UCHAR
> z:\wince420\platform\cepc\target\x86\debug\sboot.exe() :
> error LNK1120: 2 unresolved externals
>
> I attempted to go back and reinstall the QFE's for the x86
> but that didn't fix my problem.
>
> Any guesses on what this problem might actually be?
>
> Thanks
> Wally



Re: Possible Problem with x86 after installing ARMV4I QFE by K

K
Tue Jan 13 23:07:11 CST 2004

Dear sir:
It is seems that you may checkout the wdm.h under your common\ddk\inc
the READ/WRITE _PORT_UCHAR has been removed from wdm.h
so you may modify the SOURCES file under sboot

to add this line

$(_COMMONOAKROOT)\lib\$(_CPUDEPPATH)\ddk_io.lib \
to your TARGETLIBS macro


"Wally" <anonymous@discussions.microsoft.com>
???????:017301c3da15$2bebfc00$a601280a@phx.gbl...
> I am working with the Intel IXDP425 BSP so I installed the
> ARMV4I QFE's for 4.2 (there were 2 of them). After doing
> so when I go back to my CEPC project, I am getting the
> following linker errors:
>
> z:\wince420\platform\cepc\sboot\main.obj() : error
> LNK2019: unresolved external symbol _READ_PORT_UCHAR
> referenced in function _OEMPlatformInit
> z:\wince420\platform\cepc\sboot\debug.obj() : error
> LNK2001: unresolved external symbol _READ_PORT_UCHAR
> z:\wince420\platform\cepc\sboot\main.obj() : error
> LNK2019: unresolved external symbol _WRITE_PORT_UCHAR
> referenced in function _OEMPlatformInit
> z:\wince420\platform\cepc\sboot\debug.obj() : error
> LNK2001: unresolved external symbol _WRITE_PORT_UCHAR
> z:\wince420\platform\cepc\target\x86\debug\sboot.exe() :
> error LNK1120: 2 unresolved externals
>
> I attempted to go back and reinstall the QFE's for the x86
> but that didn't fix my problem.
>
> Any guesses on what this problem might actually be?
>
> Thanks
> Wally



Re: Possible Problem with x86 after installing ARMV4I QFE by Wally

Wally
Wed Jan 14 13:42:11 CST 2004

I'll give a little more background...

While I was waiting for the release of the BSP for the
Intel IXDP425 evaluation board, I cut my WinCE teeth by
working with the CEPC. Everything was working great for
me.

On Monday, I found out the stuff for the Intel BSP was
posted on the Intel sight so I downloaded it. In order to
use it I needed to get install the latest QFE. I
installed WinCEPB42-030630-2003Q2-ARMV4I.EXE and WinCEPB42-
030930-2003Q3-ARMV4I.EXE. I was able to compile
everything for this micro but now I am waiting for the
WinCE personality kit (a specific Eth card, USB card,
display driver card, boot, docs) for our eval boards.

I decided to go back to working with the CEPC. When I
tried to rebuild a release version of the platform, it
didn't work. I tried to do a clean and then build but
that didn't work either. I also tried a debug build with
the same outcome. Next I tried installing the QFE's for
the x86 so I installed WinCEPB42-030630-2003Q2-X86.EXE and
WinCEPB42-030930-2003Q3-X86.EXE. That didn't work either.

I just attempted the fix given by K.S. Huang which did
solve that problem but now I have some more similar ones
so I'm guessing I should undo that fix because there is
probably a bigger issue. Here the new errors are:

z:\wince420\public\common\oak\csp\i486
\biosloader\loader\debug.obj() : error LNK2019: unresolved
external symbol _WRITE_PORT_UCHAR referenced in function
_OEMInitDebugSerial
z:\wince420\public\common\oak\csp\i486
\biosloader\loader\debug.obj() : error LNK2019: unresolved
external symbol _READ_PORT_UCHAR referenced in function
_OEMWriteDebugString
z:\wince420\public\common\oak\csp\i486
\biosloader\loader\main.obj() : error LNK2019: unresolved
external symbol _strcpy referenced in function _blMain
z:\wince420\public\common\oak\csp\i486
\biosloader\loader\main.obj() : error LNK2019: unresolved
external symbol _memset referenced in function
_InitBootArgs
z:\wince420\public\common\oak\csp\i486
\biosloader\loader\fat.obj() : error LNK2001: unresolved
external symbol _memset
z:\wince420\public\common\oak\csp\i486
\biosloader\loader\main.obj() : error LNK2019: unresolved
external symbol _memcpy referenced in function
_CopyDataSections
z:\wince420\public\common\oak\csp\i486
\biosloader\loader\fat.obj() : error LNK2001: unresolved
external symbol _memcpy
z:\wince420\public\common\oak\csp\i486
\biosloader\loader\fat.obj() : error LNK2019: unresolved
external symbol _memcmp referenced in function _InitFAT
z:\wince420\public\mycepc~1\wince420\cepc\oak\target\x86
\debug\bldr.exe() : error LNK1120: 6 unresolved externals

If I can provide any more info about anything, please let
me know.

Thanks
Wally
>-----Original Message-----
>What QFEs you have installed that cause the problem?
>You said you installed ARMV4I QFEs, but the project you
build is CEPC.
>What CEPC configuration you try to build?
>
>Victoria
>
>"Wally" <anonymous@discussions.microsoft.com> wrote in
message
>news:017301c3da15$2bebfc00$a601280a@phx.gbl...
>> I am working with the Intel IXDP425 BSP so I installed
the
>> ARMV4I QFE's for 4.2 (there were 2 of them). After
doing
>> so when I go back to my CEPC project, I am getting the
>> following linker errors:
>>
>> z:\wince420\platform\cepc\sboot\main.obj() : error
>> LNK2019: unresolved external symbol _READ_PORT_UCHAR
>> referenced in function _OEMPlatformInit
>> z:\wince420\platform\cepc\sboot\debug.obj() : error
>> LNK2001: unresolved external symbol _READ_PORT_UCHAR
>> z:\wince420\platform\cepc\sboot\main.obj() : error
>> LNK2019: unresolved external symbol _WRITE_PORT_UCHAR
>> referenced in function _OEMPlatformInit
>> z:\wince420\platform\cepc\sboot\debug.obj() : error
>> LNK2001: unresolved external symbol _WRITE_PORT_UCHAR
>> z:\wince420\platform\cepc\target\x86\debug\sboot.exe() :
>> error LNK1120: 2 unresolved externals
>>
>> I attempted to go back and reinstall the QFE's for the
x86
>> but that didn't fix my problem.
>>
>> Any guesses on what this problem might actually be?
>>
>> Thanks
>> Wally
>
>
>.
>

Re: Possible Problem with x86 after installing ARMV4I QFE by Vika

Vika
Wed Jan 14 20:54:23 CST 2004

We investigated this issue.

It looks like Intel may have provided one file that was customized (
wdm.h ).
This is a common file and it was overwritten once you installed ARM
packages.
You may want to contact Intel for support.

Vika

"Wally" <anonymous@discussions.microsoft.com> wrote in message
news:01cf01c3dad6$80d95890$a401280a@phx.gbl...
> I'll give a little more background...
>
> While I was waiting for the release of the BSP for the
> Intel IXDP425 evaluation board, I cut my WinCE teeth by
> working with the CEPC. Everything was working great for
> me.
>
> On Monday, I found out the stuff for the Intel BSP was
> posted on the Intel sight so I downloaded it. In order to
> use it I needed to get install the latest QFE. I
> installed WinCEPB42-030630-2003Q2-ARMV4I.EXE and WinCEPB42-
> 030930-2003Q3-ARMV4I.EXE. I was able to compile
> everything for this micro but now I am waiting for the
> WinCE personality kit (a specific Eth card, USB card,
> display driver card, boot, docs) for our eval boards.
>
> I decided to go back to working with the CEPC. When I
> tried to rebuild a release version of the platform, it
> didn't work. I tried to do a clean and then build but
> that didn't work either. I also tried a debug build with
> the same outcome. Next I tried installing the QFE's for
> the x86 so I installed WinCEPB42-030630-2003Q2-X86.EXE and
> WinCEPB42-030930-2003Q3-X86.EXE. That didn't work either.
>
> I just attempted the fix given by K.S. Huang which did
> solve that problem but now I have some more similar ones
> so I'm guessing I should undo that fix because there is
> probably a bigger issue. Here the new errors are:
>
> z:\wince420\public\common\oak\csp\i486
> \biosloader\loader\debug.obj() : error LNK2019: unresolved
> external symbol _WRITE_PORT_UCHAR referenced in function
> _OEMInitDebugSerial
> z:\wince420\public\common\oak\csp\i486
> \biosloader\loader\debug.obj() : error LNK2019: unresolved
> external symbol _READ_PORT_UCHAR referenced in function
> _OEMWriteDebugString
> z:\wince420\public\common\oak\csp\i486
> \biosloader\loader\main.obj() : error LNK2019: unresolved
> external symbol _strcpy referenced in function _blMain
> z:\wince420\public\common\oak\csp\i486
> \biosloader\loader\main.obj() : error LNK2019: unresolved
> external symbol _memset referenced in function
> _InitBootArgs
> z:\wince420\public\common\oak\csp\i486
> \biosloader\loader\fat.obj() : error LNK2001: unresolved
> external symbol _memset
> z:\wince420\public\common\oak\csp\i486
> \biosloader\loader\main.obj() : error LNK2019: unresolved
> external symbol _memcpy referenced in function
> _CopyDataSections
> z:\wince420\public\common\oak\csp\i486
> \biosloader\loader\fat.obj() : error LNK2001: unresolved
> external symbol _memcpy
> z:\wince420\public\common\oak\csp\i486
> \biosloader\loader\fat.obj() : error LNK2019: unresolved
> external symbol _memcmp referenced in function _InitFAT
> z:\wince420\public\mycepc~1\wince420\cepc\oak\target\x86
> \debug\bldr.exe() : error LNK1120: 6 unresolved externals
>
> If I can provide any more info about anything, please let
> me know.
>
> Thanks
> Wally
> >-----Original Message-----
> >What QFEs you have installed that cause the problem?
> >You said you installed ARMV4I QFEs, but the project you
> build is CEPC.
> >What CEPC configuration you try to build?
> >
> >Victoria
> >
> >"Wally" <anonymous@discussions.microsoft.com> wrote in
> message
> >news:017301c3da15$2bebfc00$a601280a@phx.gbl...
> >> I am working with the Intel IXDP425 BSP so I installed
> the
> >> ARMV4I QFE's for 4.2 (there were 2 of them). After
> doing
> >> so when I go back to my CEPC project, I am getting the
> >> following linker errors:
> >>
> >> z:\wince420\platform\cepc\sboot\main.obj() : error
> >> LNK2019: unresolved external symbol _READ_PORT_UCHAR
> >> referenced in function _OEMPlatformInit
> >> z:\wince420\platform\cepc\sboot\debug.obj() : error
> >> LNK2001: unresolved external symbol _READ_PORT_UCHAR
> >> z:\wince420\platform\cepc\sboot\main.obj() : error
> >> LNK2019: unresolved external symbol _WRITE_PORT_UCHAR
> >> referenced in function _OEMPlatformInit
> >> z:\wince420\platform\cepc\sboot\debug.obj() : error
> >> LNK2001: unresolved external symbol _WRITE_PORT_UCHAR
> >> z:\wince420\platform\cepc\target\x86\debug\sboot.exe() :
> >> error LNK1120: 2 unresolved externals
> >>
> >> I attempted to go back and reinstall the QFE's for the
> x86
> >> but that didn't fix my problem.
> >>
> >> Any guesses on what this problem might actually be?
> >>
> >> Thanks
> >> Wally
> >
> >
> >.
> >



Re: Possible Problem with x86 after installing ARMV4I QFE by Wally

Wally
Thu Jan 15 08:00:52 CST 2004

Thanks for looking into this for me.

I've sent this thread to my Intel Apps Engineer. I don't
know how long it'll take to actually get to an Intel sw
guy. When I get a response from them, I'll post their
recommended solution.

What's the best way for me to temporarily restore my wdm.h
so I can get my CEPC running again?

>-----Original Message-----
>We investigated this issue.
>
>It looks like Intel may have provided one file that was
customized (
>wdm.h ).
>This is a common file and it was overwritten once you
installed ARM
>packages.
>You may want to contact Intel for support.
>
>Vika
>
>"Wally" <anonymous@discussions.microsoft.com> wrote in
message
>news:01cf01c3dad6$80d95890$a401280a@phx.gbl...
>> I'll give a little more background...
>>
>> While I was waiting for the release of the BSP for the
>> Intel IXDP425 evaluation board, I cut my WinCE teeth by
>> working with the CEPC. Everything was working great for
>> me.
>>
>> On Monday, I found out the stuff for the Intel BSP was
>> posted on the Intel sight so I downloaded it. In order
to
>> use it I needed to get install the latest QFE. I
>> installed WinCEPB42-030630-2003Q2-ARMV4I.EXE and
WinCEPB42-
>> 030930-2003Q3-ARMV4I.EXE. I was able to compile
>> everything for this micro but now I am waiting for the
>> WinCE personality kit (a specific Eth card, USB card,
>> display driver card, boot, docs) for our eval boards.
>>
>> I decided to go back to working with the CEPC. When I
>> tried to rebuild a release version of the platform, it
>> didn't work. I tried to do a clean and then build but
>> that didn't work either. I also tried a debug build
with
>> the same outcome. Next I tried installing the QFE's for
>> the x86 so I installed WinCEPB42-030630-2003Q2-X86.EXE
and
>> WinCEPB42-030930-2003Q3-X86.EXE. That didn't work
either.
>>
>> I just attempted the fix given by K.S. Huang which did
>> solve that problem but now I have some more similar ones
>> so I'm guessing I should undo that fix because there is
>> probably a bigger issue. Here the new errors are:
>>
>> z:\wince420\public\common\oak\csp\i486
>> \biosloader\loader\debug.obj() : error LNK2019:
unresolved
>> external symbol _WRITE_PORT_UCHAR referenced in function
>> _OEMInitDebugSerial
>> z:\wince420\public\common\oak\csp\i486
>> \biosloader\loader\debug.obj() : error LNK2019:
unresolved
>> external symbol _READ_PORT_UCHAR referenced in function
>> _OEMWriteDebugString
>> z:\wince420\public\common\oak\csp\i486
>> \biosloader\loader\main.obj() : error LNK2019:
unresolved
>> external symbol _strcpy referenced in function _blMain
>> z:\wince420\public\common\oak\csp\i486
>> \biosloader\loader\main.obj() : error LNK2019:
unresolved
>> external symbol _memset referenced in function
>> _InitBootArgs
>> z:\wince420\public\common\oak\csp\i486
>> \biosloader\loader\fat.obj() : error LNK2001: unresolved
>> external symbol _memset
>> z:\wince420\public\common\oak\csp\i486
>> \biosloader\loader\main.obj() : error LNK2019:
unresolved
>> external symbol _memcpy referenced in function
>> _CopyDataSections
>> z:\wince420\public\common\oak\csp\i486
>> \biosloader\loader\fat.obj() : error LNK2001: unresolved
>> external symbol _memcpy
>> z:\wince420\public\common\oak\csp\i486
>> \biosloader\loader\fat.obj() : error LNK2019: unresolved
>> external symbol _memcmp referenced in function _InitFAT
>> z:\wince420\public\mycepc~1\wince420\cepc\oak\target\x86
>> \debug\bldr.exe() : error LNK1120: 6 unresolved
externals
>>
>> If I can provide any more info about anything, please
let
>> me know.
>>
>> Thanks
>> Wally
>> >-----Original Message-----
>> >What QFEs you have installed that cause the problem?
>> >You said you installed ARMV4I QFEs, but the project you
>> build is CEPC.
>> >What CEPC configuration you try to build?
>> >
>> >Victoria
>> >
>> >"Wally" <anonymous@discussions.microsoft.com> wrote in
>> message
>> >news:017301c3da15$2bebfc00$a601280a@phx.gbl...
>> >> I am working with the Intel IXDP425 BSP so I
installed
>> the
>> >> ARMV4I QFE's for 4.2 (there were 2 of them). After
>> doing
>> >> so when I go back to my CEPC project, I am getting
the
>> >> following linker errors:
>> >>
>> >> z:\wince420\platform\cepc\sboot\main.obj() : error
>> >> LNK2019: unresolved external symbol _READ_PORT_UCHAR
>> >> referenced in function _OEMPlatformInit
>> >> z:\wince420\platform\cepc\sboot\debug.obj() : error
>> >> LNK2001: unresolved external symbol _READ_PORT_UCHAR
>> >> z:\wince420\platform\cepc\sboot\main.obj() : error
>> >> LNK2019: unresolved external symbol _WRITE_PORT_UCHAR
>> >> referenced in function _OEMPlatformInit
>> >> z:\wince420\platform\cepc\sboot\debug.obj() : error
>> >> LNK2001: unresolved external symbol _WRITE_PORT_UCHAR
>> >> z:\wince420\platform\cepc\target\x86\debug\sboot.exe
() :
>> >> error LNK1120: 2 unresolved externals
>> >>
>> >> I attempted to go back and reinstall the QFE's for
the
>> x86
>> >> but that didn't fix my problem.
>> >>
>> >> Any guesses on what this problem might actually be?
>> >>
>> >> Thanks
>> >> Wally
>> >
>> >
>> >.
>> >
>
>
>.
>

Re: Possible Problem with x86 after installing ARMV4I QFE by K

K
Thu Jan 15 08:59:14 CST 2004

TRy to add the following code in your wdm.h for a temporaily solution before
you get the official update from intel

#if x86

int __cdecl _inp(unsigned short);
unsigned short __cdecl _inpw(unsigned short);
unsigned long __cdecl _inpd(unsigned short);

int __cdecl _outp(unsigned short, int);
unsigned short __cdecl _outpw(unsigned short, unsigned short);
unsigned long __cdecl _outpd(unsigned short, unsigned long);

ULONG __inline READ_PORT_ULONG(PULONG port)
{
return _inpd((USHORT)port);
}

VOID __inline WRITE_PORT_ULONG(PULONG port, ULONG value)
{
_outpd((USHORT)port, (value));
}

USHORT __inline READ_PORT_USHORT(PUSHORT port)
{
return _inpw((USHORT)port);
}

VOID __inline WRITE_PORT_USHORT(PUSHORT port, USHORT value)
{
_outpw((USHORT)port, (value));
}

UCHAR __inline READ_PORT_UCHAR(PUCHAR port)
{
return _inp((USHORT)port);
}

VOID __inline WRITE_PORT_UCHAR(PUCHAR port, UCHAR value)
{
_outp((USHORT)port, (value));
}

#define READ_REGISTER_ULONG(reg) \
(*(volatile unsigned long * const)(reg))

#define WRITE_REGISTER_ULONG(reg, val) \
(*(volatile unsigned long * const)(reg)) = (val)

#define READ_REGISTER_USHORT(reg) \
(*(volatile unsigned short * const)(reg))

#define WRITE_REGISTER_USHORT(reg, val) \
(*(volatile unsigned short * const)(reg)) = (val)

#define READ_REGISTER_UCHAR(reg) \
(*(volatile unsigned char * const)(reg))

#define WRITE_REGISTER_UCHAR(reg, val) \
(*(volatile unsigned char * const)(reg)) = (val)

// end of x86

#elif defined(MIPS) || defined(ARM)
#if 0 // re-direct macro version io routines to ceddk.
ULONG __inline READ_PORT_ULONG(PULONG port)
{
return *(volatile unsigned long * const)port;
}

VOID __inline WRITE_PORT_ULONG(PULONG port, ULONG value)
{
*(volatile unsigned long * const)port = value;
}

USHORT __inline READ_PORT_USHORT(PUSHORT port)
{
return *(volatile unsigned short * const)port;
}

VOID __inline WRITE_PORT_USHORT(PUSHORT port, USHORT value)
{
*(volatile unsigned short * const)port = value;
}

UCHAR __inline READ_PORT_UCHAR(PUCHAR port)
{
return *(volatile unsigned char * const)port;
}

VOID __inline WRITE_PORT_UCHAR(PUCHAR port, UCHAR value)
{
*(volatile unsigned char * const)port = value;
}

#define READ_REGISTER_ULONG(reg) \
(*(volatile unsigned long * const)(reg))

#define WRITE_REGISTER_ULONG(reg, val) \
(*(volatile unsigned long * const)(reg)) = (val)

#define READ_REGISTER_USHORT(reg) \
(*(volatile unsigned short * const)(reg))

#define WRITE_REGISTER_USHORT(reg, val) \
(*(volatile unsigned short * const)(reg)) = (val)

#define READ_REGISTER_UCHAR(reg) \
(*(volatile unsigned char * const)(reg))

#define WRITE_REGISTER_UCHAR(reg, val) \
(*(volatile unsigned char * const)(reg)) = (val)
#endif // re-direct macro version io routines to ceddk.
#elif SHx

ULONG READ_PORT_ULONG(PULONG port);

VOID WRITE_PORT_ULONG(PULONG port, ULONG value);

USHORT READ_PORT_USHORT(PUSHORT port);

VOID WRITE_PORT_USHORT(PUSHORT port, USHORT value);

UCHAR READ_PORT_UCHAR(PUCHAR port);

VOID WRITE_PORT_UCHAR(PUCHAR port, UCHAR value);

#define READ_REGISTER_ULONG(reg) \
(*(volatile unsigned long * const)(reg))

#define WRITE_REGISTER_ULONG(reg, val) \
(*(volatile unsigned long * const)(reg)) = (val)

#define READ_REGISTER_USHORT(reg) \
(*(volatile unsigned short * const)(reg))

#define WRITE_REGISTER_USHORT(reg, val) \
(*(volatile unsigned short * const)(reg)) = (val)

#define READ_REGISTER_UCHAR(reg) \
(*(volatile unsigned char * const)(reg))

#define WRITE_REGISTER_UCHAR(reg, val) \
(*(volatile unsigned char * const)(reg)) = (val)

#endif // MIPS

"Wally" <anonymous@discussions.microsoft.com>
???????:0cb001c3db6f$fce143a0$a101280a@phx.gbl...
> Thanks for looking into this for me.
>
> I've sent this thread to my Intel Apps Engineer. I don't
> know how long it'll take to actually get to an Intel sw
> guy. When I get a response from them, I'll post their
> recommended solution.
>
> What's the best way for me to temporarily restore my wdm.h
> so I can get my CEPC running again?
>
> >-----Original Message-----
> >We investigated this issue.
> >
> >It looks like Intel may have provided one file that was
> customized (
> >wdm.h ).
> >This is a common file and it was overwritten once you
> installed ARM
> >packages.
> >You may want to contact Intel for support.
> >
> >Vika
> >
> >"Wally" <anonymous@discussions.microsoft.com> wrote in
> message
> >news:01cf01c3dad6$80d95890$a401280a@phx.gbl...
> >> I'll give a little more background...
> >>
> >> While I was waiting for the release of the BSP for the
> >> Intel IXDP425 evaluation board, I cut my WinCE teeth by
> >> working with the CEPC. Everything was working great for
> >> me.
> >>
> >> On Monday, I found out the stuff for the Intel BSP was
> >> posted on the Intel sight so I downloaded it. In order
> to
> >> use it I needed to get install the latest QFE. I
> >> installed WinCEPB42-030630-2003Q2-ARMV4I.EXE and
> WinCEPB42-
> >> 030930-2003Q3-ARMV4I.EXE. I was able to compile
> >> everything for this micro but now I am waiting for the
> >> WinCE personality kit (a specific Eth card, USB card,
> >> display driver card, boot, docs) for our eval boards.
> >>
> >> I decided to go back to working with the CEPC. When I
> >> tried to rebuild a release version of the platform, it
> >> didn't work. I tried to do a clean and then build but
> >> that didn't work either. I also tried a debug build
> with
> >> the same outcome. Next I tried installing the QFE's for
> >> the x86 so I installed WinCEPB42-030630-2003Q2-X86.EXE
> and
> >> WinCEPB42-030930-2003Q3-X86.EXE. That didn't work
> either.
> >>
> >> I just attempted the fix given by K.S. Huang which did
> >> solve that problem but now I have some more similar ones
> >> so I'm guessing I should undo that fix because there is
> >> probably a bigger issue. Here the new errors are:
> >>
> >> z:\wince420\public\common\oak\csp\i486
> >> \biosloader\loader\debug.obj() : error LNK2019:
> unresolved
> >> external symbol _WRITE_PORT_UCHAR referenced in function
> >> _OEMInitDebugSerial
> >> z:\wince420\public\common\oak\csp\i486
> >> \biosloader\loader\debug.obj() : error LNK2019:
> unresolved
> >> external symbol _READ_PORT_UCHAR referenced in function
> >> _OEMWriteDebugString
> >> z:\wince420\public\common\oak\csp\i486
> >> \biosloader\loader\main.obj() : error LNK2019:
> unresolved
> >> external symbol _strcpy referenced in function _blMain
> >> z:\wince420\public\common\oak\csp\i486
> >> \biosloader\loader\main.obj() : error LNK2019:
> unresolved
> >> external symbol _memset referenced in function
> >> _InitBootArgs
> >> z:\wince420\public\common\oak\csp\i486
> >> \biosloader\loader\fat.obj() : error LNK2001: unresolved
> >> external symbol _memset
> >> z:\wince420\public\common\oak\csp\i486
> >> \biosloader\loader\main.obj() : error LNK2019:
> unresolved
> >> external symbol _memcpy referenced in function
> >> _CopyDataSections
> >> z:\wince420\public\common\oak\csp\i486
> >> \biosloader\loader\fat.obj() : error LNK2001: unresolved
> >> external symbol _memcpy
> >> z:\wince420\public\common\oak\csp\i486
> >> \biosloader\loader\fat.obj() : error LNK2019: unresolved
> >> external symbol _memcmp referenced in function _InitFAT
> >> z:\wince420\public\mycepc~1\wince420\cepc\oak\target\x86
> >> \debug\bldr.exe() : error LNK1120: 6 unresolved
> externals
> >>
> >> If I can provide any more info about anything, please
> let
> >> me know.
> >>
> >> Thanks
> >> Wally
> >> >-----Original Message-----
> >> >What QFEs you have installed that cause the problem?
> >> >You said you installed ARMV4I QFEs, but the project you
> >> build is CEPC.
> >> >What CEPC configuration you try to build?
> >> >
> >> >Victoria
> >> >
> >> >"Wally" <anonymous@discussions.microsoft.com> wrote in
> >> message
> >> >news:017301c3da15$2bebfc00$a601280a@phx.gbl...
> >> >> I am working with the Intel IXDP425 BSP so I
> installed
> >> the
> >> >> ARMV4I QFE's for 4.2 (there were 2 of them). After
> >> doing
> >> >> so when I go back to my CEPC project, I am getting
> the
> >> >> following linker errors:
> >> >>
> >> >> z:\wince420\platform\cepc\sboot\main.obj() : error
> >> >> LNK2019: unresolved external symbol _READ_PORT_UCHAR
> >> >> referenced in function _OEMPlatformInit
> >> >> z:\wince420\platform\cepc\sboot\debug.obj() : error
> >> >> LNK2001: unresolved external symbol _READ_PORT_UCHAR
> >> >> z:\wince420\platform\cepc\sboot\main.obj() : error
> >> >> LNK2019: unresolved external symbol _WRITE_PORT_UCHAR
> >> >> referenced in function _OEMPlatformInit
> >> >> z:\wince420\platform\cepc\sboot\debug.obj() : error
> >> >> LNK2001: unresolved external symbol _WRITE_PORT_UCHAR
> >> >> z:\wince420\platform\cepc\target\x86\debug\sboot.exe
> () :
> >> >> error LNK1120: 2 unresolved externals
> >> >>
> >> >> I attempted to go back and reinstall the QFE's for
> the
> >> x86
> >> >> but that didn't fix my problem.
> >> >>
> >> >> Any guesses on what this problem might actually be?
> >> >>
> >> >> Thanks
> >> >> Wally
> >> >
> >> >
> >> >.
> >> >
> >
> >
> >.
> >



Re: Possible Problem with x86 after installing ARMV4I QFE by Vika

Vika
Thu Jan 15 13:05:26 CST 2004

Open the following folder \public\common\ddk\inc

There should be wdm.h file and a few wdm.h that have been renamed
( example, wdm.h.030630-2003Q2.0 and others )

Find wdm.h that has "0" extention at the end. It should be the file that
was originally on the system before you installed the packages.

Vika


"Wally" <anonymous@discussions.microsoft.com> wrote in message
news:0cb001c3db6f$fce143a0$a101280a@phx.gbl...
> Thanks for looking into this for me.
>
> I've sent this thread to my Intel Apps Engineer. I don't
> know how long it'll take to actually get to an Intel sw
> guy. When I get a response from them, I'll post their
> recommended solution.
>
> What's the best way for me to temporarily restore my wdm.h
> so I can get my CEPC running again?
>
> >-----Original Message-----
> >We investigated this issue.
> >
> >It looks like Intel may have provided one file that was
> customized (
> >wdm.h ).
> >This is a common file and it was overwritten once you
> installed ARM
> >packages.
> >You may want to contact Intel for support.
> >
> >Vika
> >
> >"Wally" <anonymous@discussions.microsoft.com> wrote in
> message
> >news:01cf01c3dad6$80d95890$a401280a@phx.gbl...
> >> I'll give a little more background...
> >>
> >> While I was waiting for the release of the BSP for the
> >> Intel IXDP425 evaluation board, I cut my WinCE teeth by
> >> working with the CEPC. Everything was working great for
> >> me.
> >>
> >> On Monday, I found out the stuff for the Intel BSP was
> >> posted on the Intel sight so I downloaded it. In order
> to
> >> use it I needed to get install the latest QFE. I
> >> installed WinCEPB42-030630-2003Q2-ARMV4I.EXE and
> WinCEPB42-
> >> 030930-2003Q3-ARMV4I.EXE. I was able to compile
> >> everything for this micro but now I am waiting for the
> >> WinCE personality kit (a specific Eth card, USB card,
> >> display driver card, boot, docs) for our eval boards.
> >>
> >> I decided to go back to working with the CEPC. When I
> >> tried to rebuild a release version of the platform, it
> >> didn't work. I tried to do a clean and then build but
> >> that didn't work either. I also tried a debug build
> with
> >> the same outcome. Next I tried installing the QFE's for
> >> the x86 so I installed WinCEPB42-030630-2003Q2-X86.EXE
> and
> >> WinCEPB42-030930-2003Q3-X86.EXE. That didn't work
> either.
> >>
> >> I just attempted the fix given by K.S. Huang which did
> >> solve that problem but now I have some more similar ones
> >> so I'm guessing I should undo that fix because there is
> >> probably a bigger issue. Here the new errors are:
> >>
> >> z:\wince420\public\common\oak\csp\i486
> >> \biosloader\loader\debug.obj() : error LNK2019:
> unresolved
> >> external symbol _WRITE_PORT_UCHAR referenced in function
> >> _OEMInitDebugSerial
> >> z:\wince420\public\common\oak\csp\i486
> >> \biosloader\loader\debug.obj() : error LNK2019:
> unresolved
> >> external symbol _READ_PORT_UCHAR referenced in function
> >> _OEMWriteDebugString
> >> z:\wince420\public\common\oak\csp\i486
> >> \biosloader\loader\main.obj() : error LNK2019:
> unresolved
> >> external symbol _strcpy referenced in function _blMain
> >> z:\wince420\public\common\oak\csp\i486
> >> \biosloader\loader\main.obj() : error LNK2019:
> unresolved
> >> external symbol _memset referenced in function
> >> _InitBootArgs
> >> z:\wince420\public\common\oak\csp\i486
> >> \biosloader\loader\fat.obj() : error LNK2001: unresolved
> >> external symbol _memset
> >> z:\wince420\public\common\oak\csp\i486
> >> \biosloader\loader\main.obj() : error LNK2019:
> unresolved
> >> external symbol _memcpy referenced in function
> >> _CopyDataSections
> >> z:\wince420\public\common\oak\csp\i486
> >> \biosloader\loader\fat.obj() : error LNK2001: unresolved
> >> external symbol _memcpy
> >> z:\wince420\public\common\oak\csp\i486
> >> \biosloader\loader\fat.obj() : error LNK2019: unresolved
> >> external symbol _memcmp referenced in function _InitFAT
> >> z:\wince420\public\mycepc~1\wince420\cepc\oak\target\x86
> >> \debug\bldr.exe() : error LNK1120: 6 unresolved
> externals
> >>
> >> If I can provide any more info about anything, please
> let
> >> me know.
> >>
> >> Thanks
> >> Wally
> >> >-----Original Message-----
> >> >What QFEs you have installed that cause the problem?
> >> >You said you installed ARMV4I QFEs, but the project you
> >> build is CEPC.
> >> >What CEPC configuration you try to build?
> >> >
> >> >Victoria
> >> >
> >> >"Wally" <anonymous@discussions.microsoft.com> wrote in
> >> message
> >> >news:017301c3da15$2bebfc00$a601280a@phx.gbl...
> >> >> I am working with the Intel IXDP425 BSP so I
> installed
> >> the
> >> >> ARMV4I QFE's for 4.2 (there were 2 of them). After
> >> doing
> >> >> so when I go back to my CEPC project, I am getting
> the
> >> >> following linker errors:
> >> >>
> >> >> z:\wince420\platform\cepc\sboot\main.obj() : error
> >> >> LNK2019: unresolved external symbol _READ_PORT_UCHAR
> >> >> referenced in function _OEMPlatformInit
> >> >> z:\wince420\platform\cepc\sboot\debug.obj() : error
> >> >> LNK2001: unresolved external symbol _READ_PORT_UCHAR
> >> >> z:\wince420\platform\cepc\sboot\main.obj() : error
> >> >> LNK2019: unresolved external symbol _WRITE_PORT_UCHAR
> >> >> referenced in function _OEMPlatformInit
> >> >> z:\wince420\platform\cepc\sboot\debug.obj() : error
> >> >> LNK2001: unresolved external symbol _WRITE_PORT_UCHAR
> >> >> z:\wince420\platform\cepc\target\x86\debug\sboot.exe
> () :
> >> >> error LNK1120: 2 unresolved externals
> >> >>
> >> >> I attempted to go back and reinstall the QFE's for
> the
> >> x86
> >> >> but that didn't fix my problem.
> >> >>
> >> >> Any guesses on what this problem might actually be?
> >> >>
> >> >> Thanks
> >> >> Wally
> >> >
> >> >
> >> >.
> >> >
> >
> >
> >.
> >



Re: Possible Problem with x86 after installing ARMV4I QFE by Wally

Wally
Fri Jan 16 15:52:40 CST 2004

I gave this suggestion a try and it seems to have worked (I didn't actually
try running it yet). I moved the wdm.h from platform\intel\ixdp425\inc to
public\common\ddk\inc so it would get copied to my cesysgen\ddk\inc folder.
I was also undid the addition to the SOURCE file from your previous
suggestion.

Thanks for you help. Makes me wonder what else Intel did though...?


"K. S. Huang" <ks_huang@dlink.com.tw.remove.this> wrote in message
news:O7vxVg32DHA.1704@tk2msftngp13.phx.gbl...
> TRy to add the following code in your wdm.h for a temporaily solution
before
> you get the official update from intel
>
> #if x86
>
> int __cdecl _inp(unsigned short);
> unsigned short __cdecl _inpw(unsigned short);
> unsigned long __cdecl _inpd(unsigned short);
>
> int __cdecl _outp(unsigned short, int);
> unsigned short __cdecl _outpw(unsigned short, unsigned short);
> unsigned long __cdecl _outpd(unsigned short, unsigned long);
>
> ULONG __inline READ_PORT_ULONG(PULONG port)
> {
> return _inpd((USHORT)port);
> }
>
> VOID __inline WRITE_PORT_ULONG(PULONG port, ULONG value)
> {
> _outpd((USHORT)port, (value));
> }
>
> USHORT __inline READ_PORT_USHORT(PUSHORT port)
> {
> return _inpw((USHORT)port);
> }
>
> VOID __inline WRITE_PORT_USHORT(PUSHORT port, USHORT value)
> {
> _outpw((USHORT)port, (value));
> }
>
> UCHAR __inline READ_PORT_UCHAR(PUCHAR port)
> {
> return _inp((USHORT)port);
> }
>
> VOID __inline WRITE_PORT_UCHAR(PUCHAR port, UCHAR value)
> {
> _outp((USHORT)port, (value));
> }
>
> #define READ_REGISTER_ULONG(reg) \
> (*(volatile unsigned long * const)(reg))
>
> #define WRITE_REGISTER_ULONG(reg, val) \
> (*(volatile unsigned long * const)(reg)) = (val)
>
> #define READ_REGISTER_USHORT(reg) \
> (*(volatile unsigned short * const)(reg))
>
> #define WRITE_REGISTER_USHORT(reg, val) \
> (*(volatile unsigned short * const)(reg)) = (val)
>
> #define READ_REGISTER_UCHAR(reg) \
> (*(volatile unsigned char * const)(reg))
>
> #define WRITE_REGISTER_UCHAR(reg, val) \
> (*(volatile unsigned char * const)(reg)) = (val)
>
> // end of x86
>
> #elif defined(MIPS) || defined(ARM)
> #if 0 // re-direct macro version io routines to ceddk.
> ULONG __inline READ_PORT_ULONG(PULONG port)
> {
> return *(volatile unsigned long * const)port;
> }
>
> VOID __inline WRITE_PORT_ULONG(PULONG port, ULONG value)
> {
> *(volatile unsigned long * const)port = value;
> }
>
> USHORT __inline READ_PORT_USHORT(PUSHORT port)
> {
> return *(volatile unsigned short * const)port;
> }
>
> VOID __inline WRITE_PORT_USHORT(PUSHORT port, USHORT value)
> {
> *(volatile unsigned short * const)port = value;
> }
>
> UCHAR __inline READ_PORT_UCHAR(PUCHAR port)
> {
> return *(volatile unsigned char * const)port;
> }
>
> VOID __inline WRITE_PORT_UCHAR(PUCHAR port, UCHAR value)
> {
> *(volatile unsigned char * const)port = value;
> }
>
> #define READ_REGISTER_ULONG(reg) \
> (*(volatile unsigned long * const)(reg))
>
> #define WRITE_REGISTER_ULONG(reg, val) \
> (*(volatile unsigned long * const)(reg)) = (val)
>
> #define READ_REGISTER_USHORT(reg) \
> (*(volatile unsigned short * const)(reg))
>
> #define WRITE_REGISTER_USHORT(reg, val) \
> (*(volatile unsigned short * const)(reg)) = (val)
>
> #define READ_REGISTER_UCHAR(reg) \
> (*(volatile unsigned char * const)(reg))
>
> #define WRITE_REGISTER_UCHAR(reg, val) \
> (*(volatile unsigned char * const)(reg)) = (val)
> #endif // re-direct macro version io routines to ceddk.
> #elif SHx
>
> ULONG READ_PORT_ULONG(PULONG port);
>
> VOID WRITE_PORT_ULONG(PULONG port, ULONG value);
>
> USHORT READ_PORT_USHORT(PUSHORT port);
>
> VOID WRITE_PORT_USHORT(PUSHORT port, USHORT value);
>
> UCHAR READ_PORT_UCHAR(PUCHAR port);
>
> VOID WRITE_PORT_UCHAR(PUCHAR port, UCHAR value);
>
> #define READ_REGISTER_ULONG(reg) \
> (*(volatile unsigned long * const)(reg))
>
> #define WRITE_REGISTER_ULONG(reg, val) \
> (*(volatile unsigned long * const)(reg)) = (val)
>
> #define READ_REGISTER_USHORT(reg) \
> (*(volatile unsigned short * const)(reg))
>
> #define WRITE_REGISTER_USHORT(reg, val) \
> (*(volatile unsigned short * const)(reg)) = (val)
>
> #define READ_REGISTER_UCHAR(reg) \
> (*(volatile unsigned char * const)(reg))
>
> #define WRITE_REGISTER_UCHAR(reg, val) \
> (*(volatile unsigned char * const)(reg)) = (val)
>
> #endif // MIPS
>
> "Wally" <anonymous@discussions.microsoft.com>
> ???????:0cb001c3db6f$fce143a0$a101280a@phx.gbl...
> > Thanks for looking into this for me.
> >
> > I've sent this thread to my Intel Apps Engineer. I don't
> > know how long it'll take to actually get to an Intel sw
> > guy. When I get a response from them, I'll post their
> > recommended solution.
> >
> > What's the best way for me to temporarily restore my wdm.h
> > so I can get my CEPC running again?
> >
> > >-----Original Message-----
> > >We investigated this issue.
> > >
> > >It looks like Intel may have provided one file that was
> > customized (
> > >wdm.h ).
> > >This is a common file and it was overwritten once you
> > installed ARM
> > >packages.
> > >You may want to contact Intel for support.
> > >
> > >Vika
> > >
> > >"Wally" <anonymous@discussions.microsoft.com> wrote in
> > message
> > >news:01cf01c3dad6$80d95890$a401280a@phx.gbl...
> > >> I'll give a little more background...
> > >>
> > >> While I was waiting for the release of the BSP for the
> > >> Intel IXDP425 evaluation board, I cut my WinCE teeth by
> > >> working with the CEPC. Everything was working great for
> > >> me.
> > >>
> > >> On Monday, I found out the stuff for the Intel BSP was
> > >> posted on the Intel sight so I downloaded it. In order
> > to
> > >> use it I needed to get install the latest QFE. I
> > >> installed WinCEPB42-030630-2003Q2-ARMV4I.EXE and
> > WinCEPB42-
> > >> 030930-2003Q3-ARMV4I.EXE. I was able to compile
> > >> everything for this micro but now I am waiting for the
> > >> WinCE personality kit (a specific Eth card, USB card,
> > >> display driver card, boot, docs) for our eval boards.
> > >>
> > >> I decided to go back to working with the CEPC. When I
> > >> tried to rebuild a release version of the platform, it
> > >> didn't work. I tried to do a clean and then build but
> > >> that didn't work either. I also tried a debug build
> > with
> > >> the same outcome. Next I tried installing the QFE's for
> > >> the x86 so I installed WinCEPB42-030630-2003Q2-X86.EXE
> > and
> > >> WinCEPB42-030930-2003Q3-X86.EXE. That didn't work
> > either.
> > >>
> > >> I just attempted the fix given by K.S. Huang which did
> > >> solve that problem but now I have some more similar ones
> > >> so I'm guessing I should undo that fix because there is
> > >> probably a bigger issue. Here the new errors are:
> > >>
> > >> z:\wince420\public\common\oak\csp\i486
> > >> \biosloader\loader\debug.obj() : error LNK2019:
> > unresolved
> > >> external symbol _WRITE_PORT_UCHAR referenced in function
> > >> _OEMInitDebugSerial
> > >> z:\wince420\public\common\oak\csp\i486
> > >> \biosloader\loader\debug.obj() : error LNK2019:
> > unresolved
> > >> external symbol _READ_PORT_UCHAR referenced in function
> > >> _OEMWriteDebugString
> > >> z:\wince420\public\common\oak\csp\i486
> > >> \biosloader\loader\main.obj() : error LNK2019:
> > unresolved
> > >> external symbol _strcpy referenced in function _blMain
> > >> z:\wince420\public\common\oak\csp\i486
> > >> \biosloader\loader\main.obj() : error LNK2019:
> > unresolved
> > >> external symbol _memset referenced in function
> > >> _InitBootArgs
> > >> z:\wince420\public\common\oak\csp\i486
> > >> \biosloader\loader\fat.obj() : error LNK2001: unresolved
> > >> external symbol _memset
> > >> z:\wince420\public\common\oak\csp\i486
> > >> \biosloader\loader\main.obj() : error LNK2019:
> > unresolved
> > >> external symbol _memcpy referenced in function
> > >> _CopyDataSections
> > >> z:\wince420\public\common\oak\csp\i486
> > >> \biosloader\loader\fat.obj() : error LNK2001: unresolved
> > >> external symbol _memcpy
> > >> z:\wince420\public\common\oak\csp\i486
> > >> \biosloader\loader\fat.obj() : error LNK2019: unresolved
> > >> external symbol _memcmp referenced in function _InitFAT
> > >> z:\wince420\public\mycepc~1\wince420\cepc\oak\target\x86
> > >> \debug\bldr.exe() : error LNK1120: 6 unresolved
> > externals
> > >>
> > >> If I can provide any more info about anything, please
> > let
> > >> me know.
> > >>
> > >> Thanks
> > >> Wally
> > >> >-----Original Message-----
> > >> >What QFEs you have installed that cause the problem?
> > >> >You said you installed ARMV4I QFEs, but the project you
> > >> build is CEPC.
> > >> >What CEPC configuration you try to build?
> > >> >
> > >> >Victoria
> > >> >
> > >> >"Wally" <anonymous@discussions.microsoft.com> wrote in
> > >> message
> > >> >news:017301c3da15$2bebfc00$a601280a@phx.gbl...
> > >> >> I am working with the Intel IXDP425 BSP so I
> > installed
> > >> the
> > >> >> ARMV4I QFE's for 4.2 (there were 2 of them). After
> > >> doing
> > >> >> so when I go back to my CEPC project, I am getting
> > the
> > >> >> following linker errors:
> > >> >>
> > >> >> z:\wince420\platform\cepc\sboot\main.obj() : error
> > >> >> LNK2019: unresolved external symbol _READ_PORT_UCHAR
> > >> >> referenced in function _OEMPlatformInit
> > >> >> z:\wince420\platform\cepc\sboot\debug.obj() : error
> > >> >> LNK2001: unresolved external symbol _READ_PORT_UCHAR
> > >> >> z:\wince420\platform\cepc\sboot\main.obj() : error
> > >> >> LNK2019: unresolved external symbol _WRITE_PORT_UCHAR
> > >> >> referenced in function _OEMPlatformInit
> > >> >> z:\wince420\platform\cepc\sboot\debug.obj() : error
> > >> >> LNK2001: unresolved external symbol _WRITE_PORT_UCHAR
> > >> >> z:\wince420\platform\cepc\target\x86\debug\sboot.exe
> > () :
> > >> >> error LNK1120: 2 unresolved externals
> > >> >>
> > >> >> I attempted to go back and reinstall the QFE's for
> > the
> > >> x86
> > >> >> but that didn't fix my problem.
> > >> >>
> > >> >> Any guesses on what this problem might actually be?
> > >> >>
> > >> >> Thanks
> > >> >> Wally
> > >> >
> > >> >
> > >> >.
> > >> >
> > >
> > >
> > >.
> > >
>
>



Re: Possible Problem with x86 after installing ARMV4I QFE by Steve

Steve
Fri Jan 16 17:24:44 CST 2004

This would be why, twenty times a day, I chant the Mantra, NEVER TOUCH THE
COMMON CODE IN PLACE. Go ahead give it a try - you'll feel the peace and
love surround you. ;-)

OK, sarcasm aside, I'd also recommend modifying the CEPC stuff you cloned to
drop WDM.h completely. With the exception of 1394 drivers NOTHING should be
using anything WDM. Instead use CEDDK.H.

--
Steve Maillet (eMVP)
Entelechy Consulting
smaillet_AT_EntelechyConsulting_DOT_com



Re: Possible Problem with x86 after installing ARMV4I QFE by K

K
Sat Jan 17 11:41:07 CST 2004

But most of x86 Code highly depends on READ/WRITE_PORT_XXX macros in
Bootloader or in OAL, so how will these macros be??

Should they move some other header file or should we just static link the
ddk_io.lib??

Anyway, I think anyone who want to do the CE BSP porting should keep Steve's
Mantra, NEVER TOUCH THE
COMMON CODE IN PLACE, in mind :-)

"Steve Maillet (eMVP)" <nospam1@EntelechyConsulting.com> ¼¶¼g©ó¶l¥ó·s»D
:u0w5zfI3DHA.1184@TK2MSFTNGP10.phx.gbl...
> This would be why, twenty times a day, I chant the Mantra, NEVER TOUCH THE
> COMMON CODE IN PLACE. Go ahead give it a try - you'll feel the peace and
> love surround you. ;-)
>
> OK, sarcasm aside, I'd also recommend modifying the CEPC stuff you cloned
to
> drop WDM.h completely. With the exception of 1394 drivers NOTHING should
be
> using anything WDM. Instead use CEDDK.H.
>
> --
> Steve Maillet (eMVP)
> Entelechy Consulting
> smaillet_AT_EntelechyConsulting_DOT_com
>
>



Re: Possible Problem with x86 after installing ARMV4I QFE by Steve

Steve
Sat Jan 17 16:50:41 CST 2004

You should NOT use the MACRO versions but instead link to ddk_io.lib
statically for Boot loaders the OAL and Installable ISRs. That way you are
always using the appropriate function (which may be overridden in the
platform to do something other than the default - I've seen some pretty
harebrained implementations of the CEDDK functions to get around hardware
problems!)

--
Steve Maillet (eMVP)
Entelechy Consulting
smaillet_AT_EntelechyConsulting_DOT_com



Re: Possible Problem with x86 after installing ARMV4I QFE by Dani

Dani
Mon Jan 19 04:31:35 CST 2004

As K S Huang says, this BSP uses a customised ceddk and wdm.h to work around
issues with the standard READ/WRITE_PORT_XXX macros and the PCI controller
on the board. However third party drivers that live under public such as
RTL8139 and SMIVGX still rely on the public wdm.h. I think that's why MS
changed it when the QFE was released. What I don't understand is why x86
code was also affected.