IRQ Woes, Please Help!

Hello,

Not sure if this is the proper forum, or not, but...
We are working on bringing up a new set-top device, based heavily on
legacy-free pc hardware.
So far, we have had much success, basing our BSP heavily on CEPC. The
kernel is coming up, a very simple display driver is in place, and we are
able to launch userland processes. However, we have hit a major roadblock
that is beginning to cause us much grief.

Our device has a bit of a nonstandard PCI bus, so instead of using the PCI
enumerator we decided to 'hardcode' the device settings in the registry, as
there is really only one device we are concerned with, an OHCI usb
controller. This usb controller is on IRQ 1 and at a membase of 0xFED00000

So, we've set the relevant registry settings as:
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\OHCI]
"Prefix"="HCD"
"Dll"="ohci2.dll"
"Order"=dword:2
"Class"=dword:0c
"SubClass"=dword:03
"ProgIF"=dword:10
"IsrDll"="giisr.dll"
"IsrHandler"="ISRHandler"
"MemBase"=dword:fed00000
"MemLen"=dword:1000
"Irq"=dword:1
"SysIntr"=dword:11
"BusNumber"=dword:0
"DeviceNumber"=dword:2
"FunctionNumber"=dword:0

(Perhaps overkill, but...)

Now, when we boot, the driver loads alright, but the following appears:

0x839f58a8: CHub(Root tier 0)::HubStatusChangeThread - device attached on
port 1
0x839f58a8: +CHub(Root tier 0)::AttachDevice - port = 1, fIsLowSpeed = 0
0x839f58a8: CHub(Root tier 0)::AttachDevice - status =
DEVICE_CONFIG_STATUS_OPENING_ENDPOINT0_PIPE, failures = 0
0x839f58a8: CHub(Root tier 0)::AttachDevice - status =
DEVICE_CONFIG_STATUS_USING_ADDRESS0, failures = 0
0x839f58a8: CHub(Root tier 0)::AttachDevice - status =
DEVICE_CONFIG_STATUS_RESET_AND_ENABLE_PORT, failures = 0
0x839f58a8: USB HCD: DEBUGCHK failed in file
d:\mckendric\public\common\oak\drivers\usb\hcd\ohcd2\.\chw.cpp at line 994
0x839f58a8: DEBUG_BREAK @0258e866 Ignored.
0x839f58a8: CHub(Root tier 0)::AttachDevice - status =
DEVICE_CONFIG_STATUS_SCHEDULING_SET_ADDRESS, failures = 0

We've investigated, some, and it appears that what is happening is that the
driver is attempting to send a "reset" to the first port. When the port
receives this reset, it is supposed to reset (obviously) and generate some
interrupt (in some OHCI references we've seen this interrupt referred to as
"DEVICE_ATTACHED") which should, I'm assuming, call back into the driver,
clearing some PRSC flag. The code relevant to where the DEBUGCHK is failing
is:

DEBUGCHK ( m_portBase->HcRhPortStatus[port-1].PRSC == 1 );
RootHubFeature(port, USB_REQUEST_CLEAR_FEATURE,
USB_HUB_FEATURE_C_PORT_RESET);
DEBUGCHK ( m_portBase->HcRhPortStatus[port-1].PRSC == 0 );

It is the second DEBUGCHK that is failing.

From here, we're stuck. We're not sure where to go next, with this problem.
Any help, or a nudge in the right direction, would be GREATLY appreciated.

Thank you in advance,
--Nathan Cain

Geoff
Wed Nov 12 10:09:36 CST 2003


"IsrDll"="giisr.dll"
"IsrHandler"="ISRHandler"


You are using giisr to grab your interrupt - this will use a statically
mapped pointer so it can read the IRQ register on the PCI peripheral.
However, as you only have one PCI peripheral I assume you have only one PCI
interrupt source, hence there is no real need to use giisr if you don't want
to - you can map the sysintr for the PCI interrupt controller to the USB and
you should be ok.
The clean fis would be to use giisr - The static mapped variable used by
giisr must point to the correct place too - so you may want to check your
implmentation of TransBusAddrToStatic and HalTranslateBusAddress to ensure
they correctly point to your PCI bus.

Geoff
--
--
Geoff Smith
eMVP
http://www.BSQUARE.com
==
"I can't even spell eula."

Nathan
Wed Nov 12 13:46:46 CST 2003

Thank you for the prompt reply.

Perhaps I should have also specified that we are using CE.NET 4.20, and that
we would like to avoid touching the PCI bus at all, if possible. (As it
stands now, we aren't even (properly) loading the PCI bus driver... and we
have it loading AFTER the ohci driver. If the giisr relies on having the
PCI driver, then this may be the problem?)

All of the devices on the PCI bus are initialized with consistent IRQs and
Memory bases before we even get into the bootloader, so.... We shouldn't
NEED to touch the PCI bus at all. (Unless I'm confused.)

There are other devices on the PCI bus, but the OHCI is the only thing we
are concerned with bringing up right now.
We have a fixed mapping of IRQ 1 to SysIntr 0x11 in our bsp.

This is all very confusing and new to us, it's the first time we've done
this. Any additional help you can provide will be greatly appreciated.

--Nathan


"Geoff Smith" <smith.geoffrey@fixme.comcast.net> wrote in message
news:uufPNcTqDHA.1324@TK2MSFTNGP09.phx.gbl...
>
> "IsrDll"="giisr.dll"
> "IsrHandler"="ISRHandler"
>
>
> You are using giisr to grab your interrupt - this will use a statically
> mapped pointer so it can read the IRQ register on the PCI peripheral.
> However, as you only have one PCI peripheral I assume you have only one
PCI
> interrupt source, hence there is no real need to use giisr if you don't
want
> to - you can map the sysintr for the PCI interrupt controller to the USB
and
> you should be ok.
> The clean fis would be to use giisr - The static mapped variable used by
> giisr must point to the correct place too - so you may want to check your
> implmentation of TransBusAddrToStatic and HalTranslateBusAddress to ensure
> they correctly point to your PCI bus.
>
> Geoff
> --
> --
> Geoff Smith
> eMVP
> http://www.BSQUARE.com
> ==
> "I can't even spell eula."
>
>

David
Wed Nov 12 23:49:05 CST 2003

I believe this is not related to interrupt. The OHCI2 Hub detection is not
driven by interrupt. It works at polling mode at default. I think the
hardware address ("MemBase"=dword:fed00000)you put into the registry may be
wrong.

If you are using PDD from public\common\oak\drivers\usb\hcd\ohc, The address
in registry is bus-specific hardware address. I did not find any Bus Type
(it called InterfaceType), the system.c will assume it is PCIBus if it does
not find this entry. This address will be translated to system address then
mapped to virtual address by calling TransBusAddrToVirtual. You can verify
it by dump the memory contents pointed by CHW::m_portBase and check it
against OHCI specification to find out whether it make sense or not.

The Debug break indicate that Root Hub can not be reset correctly.

The installable ISR giisr is loaded or not depends on which pdd (system.c)
is used. If giisr is loaded and IRQ 1 is fired, the SysIntr ID 0x11 should
be return. If giisr is not loaded and IRQ 1 is fired, the default mapped
sysintr id (assume it is 0x11 as well) should be return. I do not think this
is related to the problem you have. I do not think PCIBus is related to this
problem either.

David Liao.

"Nathan Cain" <nate@suppleye.com> wrote in message
news:%23u9R4WVqDHA.2584@TK2MSFTNGP09.phx.gbl...
> Thank you for the prompt reply.
>
> Perhaps I should have also specified that we are using CE.NET 4.20, and
that
> we would like to avoid touching the PCI bus at all, if possible. (As it
> stands now, we aren't even (properly) loading the PCI bus driver... and we
> have it loading AFTER the ohci driver. If the giisr relies on having the
> PCI driver, then this may be the problem?)
>
> All of the devices on the PCI bus are initialized with consistent IRQs and
> Memory bases before we even get into the bootloader, so.... We shouldn't
> NEED to touch the PCI bus at all. (Unless I'm confused.)
>
> There are other devices on the PCI bus, but the OHCI is the only thing we
> are concerned with bringing up right now.
> We have a fixed mapping of IRQ 1 to SysIntr 0x11 in our bsp.
>
> This is all very confusing and new to us, it's the first time we've done
> this. Any additional help you can provide will be greatly appreciated.
>
> --Nathan
>
>
> "Geoff Smith" <smith.geoffrey@fixme.comcast.net> wrote in message
> news:uufPNcTqDHA.1324@TK2MSFTNGP09.phx.gbl...
> >
> > "IsrDll"="giisr.dll"
> > "IsrHandler"="ISRHandler"
> >
> >
> > You are using giisr to grab your interrupt - this will use a statically
> > mapped pointer so it can read the IRQ register on the PCI peripheral.
> > However, as you only have one PCI peripheral I assume you have only one
> PCI
> > interrupt source, hence there is no real need to use giisr if you don't
> want
> > to - you can map the sysintr for the PCI interrupt controller to the USB
> and
> > you should be ok.
> > The clean fis would be to use giisr - The static mapped variable used by
> > giisr must point to the correct place too - so you may want to check
your
> > implmentation of TransBusAddrToStatic and HalTranslateBusAddress to
ensure
> > they correctly point to your PCI bus.
> >
> > Geoff
> > --
> > --
> > Geoff Smith
> > eMVP
> > http://www.BSQUARE.com
> > ==
> > "I can't even spell eula."
> >
> >
>
>