Use previous Windows Embedded CE 6.0 Rx install for your next project

Using your previous Windows Embedded CE 6.0 Rx install for your next project should actually be a valid use case. But as a feedback from yesterdays post in this blog I got a phone call from one of my colleagues asking: "Look: Half of my development team has build problems after installing the new BSP in our new project. Any idea?"

I remembered the Peanuts comics, smiled and said: "The doctor is in! So tell me..."

Doing a blddemo -q build errors occur stating error C2677: Undefined assembler operation. The current build directory is c:\wince600\platform\common\src\soc\....blabla...

So what's happening here?

error C2677 is a MIPS Error Message. The directory above is listing the SOC (System On Chip) designs supported by all installed BSPs. Inside that directory we identified BSP support for various SOCs. These causing the problems and used in previous projects were Freescale's iMX27, iMX31, and iMX35. And these are non MIPS but ARM core SOC designs. And surely the selected MIPS assembler does not know how to handle ARM assembler operations.

So I suggested to deinstall these iMX BSPs which would surely solve the build problem. But that's not a valid solution if you still have to support the old project.

2nd proposal is to introduce some logic checking an environment variable defining the CPU or SOC (TGTCPU) selected for the current build in the C:\WINCE600\PLATFORM\COMMON\SRC\SOC\dirs until now stating to traverse all subdirectories (DIRS=*). But that's most likely causing maintenance issues on this file for upcoming BSP installs or removals that have to be solved manually even if these BSPs do not have the drawbacks from Freescales BSPs mentioned.

So how and where do other BSPs control if they are MIPS or ARM or whatever?

Well, directly in the sources files inside the subdirectories below C:\WINCE600\PLATFORM\COMMON\SRC\SOC\. Inside these sources files you can use NOMIPS16CODE=1 or identify ARM assembler sources by ARM_SOURCES= foobar.s ...

So you can add this type of control where needed in the sources files of the iMX BSPs coming from Freescale. Surprisingly this takes just a few minor changes.

Surely it would be nice if Freescale would solve these build issues directly in their BSPs to improve such compatibility issues in multi platform scenarios with different target CPU cores.

So much for project hopping from Freescale iMX (ARM core) to MIPS II FP. You mean I have not explained how this is solved in x86 or SH? Correct! I haven't... But there always has to be some magic left over. Especially at this time of the year...

-- Oliver Merkel

"Christmas waves a magic wand over this world, and behold, everything is softer and more beautiful." --N. V. Peale