Re: Another bug in TIPCCARD (CE 5.0)

Every case is different. Can you turn on debug zone on pcc_tipccard.dll to
find out why?

David Liao.

"david" <dajun.chen@xxxxxxxxx> wrote in message
Hi folks,

I am struggling in find a PCI to PCCARD bridge card supported by Wince
5.0 to allow me to testing my PCMCIA device drivers. I've bought
several card (ti1410/1420, ene 1400, ricoh) and none of them works
properly under CE (all works well under XP).

After adding VID and DID to the TIPCCARD.reg, the ti cards are
recognized (seen in registry), but does nothing when a PCMCIA card
inserted to the socket(s), even power was not switched on.

Similar to TIs, power to pcmcia card was switched on and never off
after card inserted.

WinCE does not recognise the ENE ones at all.

Your advices will be high appreciated.



Rémi de Gravelaine wrote:
> Hi, David.
> Thanks for your reply.
> > Do you know who write the mapping windows before this driver loaded? Is
> > it BIOS or PCIBUS?
> >> As for any PC compliant with Microsoft's recommendation for PCI-to-PCI
> >> and CardBus bridges (see
> >> and
> >>,
> >> the BIOS configures the CardBus Bridge (TI1410) with one 4KB memory
> >> window, one 64MB memory window and two 256B I/O windows.
> All PCI configuration is made by the BIOS, and only by the BIOS (i.e.
> NoConfig=1)
> My CEPC is an embedded device (mainly used in busses and cars) but is also
> a very compatible PC. It is not intended to run *only* under CE and some
> customers use it with other popular OS like Linux or XP/XPE. XP/XPE won't
> be able to use the TI1410 if this CardBus Bridge is not configured as
> mentioned before (one 4KB memory window, then one 64MB memory window), so
> my platform's BIOS configures the memory windows as asked by Microsoft.
> As far as I could understand, the code in TIPCCARD does not specially
> assume that PCIBUS did the PCI configuration. In
> CPCCardBusBridge::InitCardBusBridge, it checks for previously made
> initializations and respects them. In
> CPCCardBusBridge::SetupWindowResources, it searches for *two* I/O and
> *two* memory windows (by the way, what is the justification for the
> windows invalidation that follows detection?) and when
> CCardBusResource::CCardBusResource is called, it is given all the
> information in a DDKWINDOWINFO structure:
> dwi.dwNumIoWindows = 2
> dwi.ioWindows[0].dwBase = 0x1000
> dwi.ioWindows[0].dwLength = 0x100
> dwi.ioWindows[1].dwBase = 0x1400
> dwi.ioWindows[1].dwLength = 0x100
> dwi.dwNumMemWindows = 2
> dwi.memWindows[0].dwBase = 0x80000000
> dwi.memWindows[0].dwLength = 0x1000
> dwi.memWindows[1].dwBase = 0x84000000
> dwi.memWindows[1].dwLength = 0x4000000
> The code in CCardBusResource::CCardBusResource ignores the fact that 2
> memory windows exist and that 2 I/O windows exists, but the code in
> CResourceMgr::AllocateResource does not!!!
> I will soon work on a clean fix and keep you in touch.
> --
> Remi de Gravelaine
> gravelaine at aton dash sys dot fr