Paul
Thu Jul 12 18:05:50 CDT 2007
Is that debug stuff from Windows CE or the bootloader? If Windows CE, which
it appears to be, it could still be what Marco suggested, but it's not what
I was talking about. You're going to have to contact the person responsible
for the bootload and OAL and find out what's going on. This isn't going to
be a high-level, set this item in the registry fix...
Paul T.
"PaulK" <PaulK@discussions.microsoft.com> wrote in message
news:1E5E787F-BA4C-4C63-93F5-1CD8E9177DA8@microsoft.com...
>I have been working with debug builds of the OS are I get the following
>when
> I boot the device in CSF2:
>
> 0x8b726400: GASocket is: 1
> 0x8b726400: STSocket is: 1
> 0x8b726400: Interrupt Events are: b3
> pREgBaseAddr=[0x450000]
> ***NDIS*** (a, 474) ==>NdisMRegisterInterrupt: Miniport 00046AC0 Vector 10
> ***NDIS*** (a, 645) <==NdisMRegisterInterrupt: Miniport 00046AC0, Status 0
> 0x8bdac64c: STSocket is: 1
> 0x8bdac64c: Interrupt Events are: b3
> ==>NdisMRegisterAdapterShutdownHandler: Miniport 00046AC0
> <==NdisMRegisterAdapterShutdownHandler: Miniport 00046AC0
> 0x8b726400: +OpenIFConfigEx(Comm\SDCCF10G1\Params\TCPIP Handle 0x848E6D4)
> 0x8b726400: +OpenIFConfig(Comm\SDCCF10G1\Params\TCPIP Handle 0x848E6D4)
> 0x8b726400: Opened registry info for Comm\SDCCF10G1\Params\TCPIP
> 0x8b726400: -OpenIFConfig(Comm\SDCCF10G1\Params\TCPIP\*Handle 0x848E6D4,
> BOOL REt: 1)
> 0x8b726400: -OpenIFConfigEx(Comm\SDCCF10G1\Params\TCPIP\*Handle 0x848E6D4,
> BOOL REt: 1)
> 0x8b726400: *CloseIFConfig(Handle 0xA3850)
> 0x8b726400: +OpenIFConfig(Comm\SDCCF10G1\Params\TCPIP Handle 0x848E4D4)
> 0x8b726400: Opened registry info for Comm\SDCCF10G1\Params\TCPIP
> 0x8b726400: -OpenIFConfig(Comm\SDCCF10G1\Params\TCPIP\*Handle 0x848E4D4,
> BOOL REt: 1)
> 0x8b726400: +GetGeneralIFConfig(ConfigInfo 0x83FE4C98 Handle 0xA2730)
> 0x8b726400: GetGeneralIFConfig:Unable to read DefaultGateway
> value!
> 0x8b726400: GetGeneralIFConfig:Unable to read DNS value!
> 0x8b726400: GetGeneralIFConfig:Unable to read WINS value!
> 0x8b726400: GetGeneralIFConfig:Unable to read UseZeroBroadcast
> value!
> 0x8b726400: All-nets boadcasts will be addressed to 255.255.255.255
> 0x8b726400: -GetGeneralIFConfig(ConfigInfo 0x848E4C8 Handle 0xA3850 Ret:
> TRUE)
> 0x8b726400: +GetIFAddrList(NumAddr* 0x848E590 Handle 0xA3850)
> 0x8b726400: *IPAddNTE: calling ARPDynRegister
>
> Note: at this point the device is in a hung state....
>
> I didn't write the bootloader and so I am unfamiliar with the code.
> However, I think you are Marco are suggesting similar ideas regarding card
> types and/or a socket reset issue.
>
> Just quickely looking through some code, I see the BSP guy has modified
> and
> commented out code in Post.c, CELoad.c, Socket.c, Init.c, and Config.c
> with
> regards to the CF card slots.
>
>
>
>
>
>
> "Paul G. Tobey [eMVP]" wrote:
>
>> First you have to figure out what's actually going on. A DEBUG build of
>> the
>> bootloader and the OS should give you some idea (read the debug messages
>> and
>> see what's actually going on). At a guess, I'd say that the bootloader
>> was
>> written to check CFS2 for memory cards first, but maybe wasn't fully
>> implemented to ignore cards of other types. When you put your WiFi card
>> in
>> that slot, the bootloader tries to use it as a memory card and load the
>> OS
>> which, of course, never works.
>>
>> Paul T.
>>
>> "PaulK" <PaulK@discussions.microsoft.com> wrote in message
>> news:18618E1C-7F7F-4C02-AE67-0AF60099D350@microsoft.com...
>> > Our platform is a PXA255 CE 4.2 with two Compact Flash Slots (CFS1 &
>> > CFS2).
>> >
>> > The device normally starts up by loading a CE 4.2 image into RAM that
>> > is
>> > stored on a CF memory card and inserted into CFS1.
>> >
>> > We desire to add WiFi connectivity to our legacy product by inserting a
>> > WLAN
>> > adpater into our normally unused CFS2.
>> >
>> > The WLAN driver has been successfully added to the CE 4.2 image,
>> > however,
>> > the problem is that our device experiences a hung state when we start
>> > with
>> > the WLAN adapter inserted into CFS2.
>> >
>> > Based on further testing, there appears to be a contention issue
>> > between
>> > CFS1 and CFS2 with CFS1 being given priority.
>> >
>> > For our implementation, we must have the WLAN adapter operate on CFS2.
>> > The
>> > following tests are the best method I know to describe the situation.
>> >
>> >
>> > Test #1 *** Failure ***
>> >
>> > 1. Insert memory card into CFS1
>> > 2. Insert WLAN adapter into CFS2
>> > 3. Power device
>> > 4. Device starts up into a hung state shortly after displaying the CE
>> > desktop.
>> > Display will blank out.
>> > 5. Remove the WLAN adapter from CFS2 (or apply 3.3V to the CFS2 WAIT
>> > line)
>> > and the CE desktop re-appears.
>> >
>> > Note: this test represents the problem as we must startup and operate
>> > with
>> > WLAN adapter preinserted into CFS2.
>> >
>> >
>> > Test #2 *** Success ***
>> >
>> > 1. Insert memory card into CFS2
>> > 2. Insert WLAN adapter into CFS1
>> > 3. Power device
>> > 4. Device startup succeeds with WiFi connectivity.
>> >
>> >
>> > Test #3 *** Success ***
>> >
>> > 1. Insert memory card into CFS1
>> > 2. Power device
>> > 3. Device starts up into CE desktop
>> > 4. Remove memory card from CFS1
>> > 5. Insert WLAN adapter into CFS2
>> > 6. Device succeeds with WiFi connectivity
>> >
>> >
>> > Test #4 *** Success ***
>> >
>> > 1. Insert memory card into CFS2
>> > 2. Power device
>> > 3. Device start up into CE desktop
>> > 4. Remove memory card from CFS2
>> > 5. Insert WLAN adapter into CFS2
>> > 6. Device succeeds with WiFi connectivity
>> >
>> > Note: CFS1 remains unused during Test #4.
>> >
>> > Any ideas on how to resolve the hung state being experienced with Test
>> > #1?
>> >
>> > Thanks.
>> >
>>
>>
>>