IMGLOADNETHIGH stuck on in .pbxml caused much later sysgen image f

I have been struggling with several odd PB problems that turned out to all be
caused by the same thing. The problems were:

1) Sometimes a project change would create a non-booting nk.bin image
(failed soon out of OemInit), and backing out the change didn't work; the
project remained corrupted and required reload of WINCE500 folder tree.

2) Copying a working WINCE500 folder tree to another machine and Sysgening
produced a non-booting nk.bin image.

3) Putting PBWorkspaces and BSP source files under source control without
changing any files caused the next Sysgen to produce a non-booting nk.bin
image.

The problem turned out to be that at some time in the distant past,
something caused PB to add lines like this to xxxxx.pbxml:
<string>IMGLOADNETHIGH=1</string>

The IMGLOADNETHIGH parameter had not previously been turned on, as far as I
know, and the working build of nk.bin was created with the option off.

This addition of IMGLOADNETHIGH to the pbxml file should have caused the
next Sysgen to rebuild any files that referenced this symbol in #if etc. (In
particular, in my case with the Intel 465 BSP, the file
Src/Kernel/Hal/cfw_ixp425.c should have been out-of-date after that symbol
was added to the pbxml file). However, this did not happen. If it had,
those files would have recompiled, and the resulting nk.bin would have failed
during booting, and the programmer would have looked for something he just
did to cause it to fail.

Instead, what happens is that the next time you touch a file in the
dependency tree of any file that uses IMGLOADNETHIGH, it triggers recompile
of that file, and at that time, the nk.bin stops working, and you have no
idea why.

I do not know why turning on the IMGLOADNETHIGH option should fail; perhaps
it has never been fully implemented in my particular BSP.

There was no way to examine the value of IMGLOADNETHIGH from PB. It didn't
show it anywhere. To fix this problem, I had to manually edit the .pbxml
file, delete the IMGLOADNETHIGH lines (two of them), touch some files that
used the symbol in order to trigger recompile, and do a Sysgen. The nk.bin
then worked.

I have no idea what caused the symbol line to be added to the .pbxml in the
first place.

TedToalSierraVideoSystems
Sun Dec 24 19:28:00 CST 2006

Note that the time between the symbol being added to the .pbxml and the time
at which you touch a critical file and trigger production of a non-working
nk.bin may be a long time. In our case, it was months.

Once you've made a change that triggers recompile of the critical files,
undoing that change has no effect. The problem was doomed to happen whenever
the critical file was recompiled, change or no change.

Copying WINCE500 to another machine may or may not touch file dates,
depending on how you do the copy. If it does touch them, it will trigger the
problem to occur on the new machine.

Putting files under source control generally touches their dates, triggering
recompile.

Since this can happen with IMGLOADNETHIGH, it can probably happen with other
symbols.

Opening a build window from PB and doing SET shows the environment
variables; they will include the incorrect IMGLOADNETHIGH=1, giving the
impression when comparing a working and non-working build-PC that environment
variables are not the problem. However, if one were able to compare the EV's
at the time the critical files were built, they would be seen to be not the
same.

PB ought to clean everything if any environment variable (that affects the
build) has changed. Also, it ought not to add these environment variables in
such a blind manner, and it should be possible to examine each variable
setting using the PB project properties dialog.

Sue
Thu Jan 04 11:47:25 CST 2007

Ted, thanks for posting such detailed info and I'm sorry for all your
trouble. I'm trying to figure out what to do about this. I'd report it as
a bug except that IMGLOADNETHIGH does not exist in CE 6.0 anymore.

One thing that puzzles me though. All "IMG" variables are supposed to only
affect the makeimg process, the very last step of build, and nothing else.
They should not affect sysgen or compilation. I can't explain why this
setting would cause files to be recompiled or stop working. If the BSP code
actually compiles based on this setting then it should be named "BSP_" or
"PRJ_" instead of "IMG." :-( I think that's just convention and doesn't
actually affect how the build system works, though. So maybe it makes no
practical difference to you. Except that we typically say whenever you
change a PRJ variable you should rerun sysgen. And I believe for a BSP
variable change you should rebuild your BSP.

Well anyway, I hope that helps you at least a little.

Sue
sloh@microsoft.com (remove "online" from reply-to address)
http://blogs.msdn.com/ce_base/
_____________________________________________________________
This posting is provided "AS IS" with no warranties, and confers no rights.
_____________________________________________________________

TedToalSierraVideoSystems
Fri Jan 05 02:03:01 CST 2007

Hi Sue,

I did a search for IMGLOADNETHIGH just now and found it in some reg files
and in Src\Kernel\Hal\cfw_ixp425.c, Src\Kernel\Hal\makefile.inc, and
Src\Kernel\Hal\sources. The cfw_ixp425.c file uses it to decide whether to
include the whole CheckDlls() logic. It appeared to me that the actual
failure may have somehow had something to do with unicode string functions
included in cfw_ixp425.c as a result of this CheckDlls() logic; I saw similar
nk.bin failures when using unicode strings in debug messages in certain files
that should have used ASCII strings.

Again - rebuilding the BSP is what triggered the error. But the error was
introduced long before the BSP was rebuilt, so when the BSP rebuild failed,
we had no idea why.

Now that I figured it out, things are working much much better. It even
fixed an ethernet bug that I thought was totally unrelated!

Ted Toal


"Sue Loh [MS]" wrote:

> Ted, thanks for posting such detailed info and I'm sorry for all your
> trouble. I'm trying to figure out what to do about this. I'd report it as
> a bug except that IMGLOADNETHIGH does not exist in CE 6.0 anymore.
>
> One thing that puzzles me though. All "IMG" variables are supposed to only
> affect the makeimg process, the very last step of build, and nothing else.
> They should not affect sysgen or compilation. I can't explain why this
> setting would cause files to be recompiled or stop working. If the BSP code
> actually compiles based on this setting then it should be named "BSP_" or
> "PRJ_" instead of "IMG." :-( I think that's just convention and doesn't
> actually affect how the build system works, though. So maybe it makes no
> practical difference to you. Except that we typically say whenever you
> change a PRJ variable you should rerun sysgen. And I believe for a BSP
> variable change you should rebuild your BSP.
>
> Well anyway, I hope that helps you at least a little.
>
> Sue
> sloh@microsoft.com (remove "online" from reply-to address)
> http://blogs.msdn.com/ce_base/
> _____________________________________________________________
> This posting is provided "AS IS" with no warranties, and confers no rights.
> _____________________________________________________________
>
>
>

Dean
Fri Jan 05 08:13:34 CST 2007

IMGLOADNETHIGH is part of a mechanism that causes networking dlls to be
loaded into kernel memory space. When you do this, you gain performance
advantages, but you make your system much more vulnerable. Any problem in
those dlls will cause the kernel itself to crash.

What the variable actually does depends on your BSP, because the mechanism
that supports this requires both source code changes and bib file changes.

The IXP line of processors is another special case entirely, because of the
big endian issues internal to the processor and the network processing
engines that exist. The bsp for this processor family is very fragile in my
experience, it is not surprising that a change (any change) ends up causing
a problem. Something like IMGLOADNETHIGH is a major change at least in the
networking area.

--
Dean Ramsier - eMVP
BSQUARE Corporation


"Ted Toal, Sierra Video Systems"
<TedToalSierraVideoSystems@discussions.microsoft.com> wrote in message
news:ECD3423D-656D-4956-8A9F-FDD1AB3A577F@microsoft.com...
> Hi Sue,
>
> I did a search for IMGLOADNETHIGH just now and found it in some reg files
> and in Src\Kernel\Hal\cfw_ixp425.c, Src\Kernel\Hal\makefile.inc, and
> Src\Kernel\Hal\sources. The cfw_ixp425.c file uses it to decide whether
> to
> include the whole CheckDlls() logic. It appeared to me that the actual
> failure may have somehow had something to do with unicode string functions
> included in cfw_ixp425.c as a result of this CheckDlls() logic; I saw
> similar
> nk.bin failures when using unicode strings in debug messages in certain
> files
> that should have used ASCII strings.
>
> Again - rebuilding the BSP is what triggered the error. But the error was
> introduced long before the BSP was rebuilt, so when the BSP rebuild
> failed,
> we had no idea why.
>
> Now that I figured it out, things are working much much better. It even
> fixed an ethernet bug that I thought was totally unrelated!
>
> Ted Toal
>
>
> "Sue Loh [MS]" wrote:
>
>> Ted, thanks for posting such detailed info and I'm sorry for all your
>> trouble. I'm trying to figure out what to do about this. I'd report it
>> as
>> a bug except that IMGLOADNETHIGH does not exist in CE 6.0 anymore.
>>
>> One thing that puzzles me though. All "IMG" variables are supposed to
>> only
>> affect the makeimg process, the very last step of build, and nothing
>> else.
>> They should not affect sysgen or compilation. I can't explain why this
>> setting would cause files to be recompiled or stop working. If the BSP
>> code
>> actually compiles based on this setting then it should be named "BSP_" or
>> "PRJ_" instead of "IMG." :-( I think that's just convention and doesn't
>> actually affect how the build system works, though. So maybe it makes no
>> practical difference to you. Except that we typically say whenever you
>> change a PRJ variable you should rerun sysgen. And I believe for a BSP
>> variable change you should rebuild your BSP.
>>
>> Well anyway, I hope that helps you at least a little.
>>
>> Sue
>> sloh@microsoft.com (remove "online" from reply-to address)
>> http://blogs.msdn.com/ce_base/
>> _____________________________________________________________
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>> _____________________________________________________________
>>
>>
>>