View topic - devu-ohci problem

devu-ohci problem

Read-only archive of qnx.ddk (Writing device drivers for scanners, video card, optical mouse, etc) at inn.qnx.com

devu-ohci problem

Postby Paul » Tue Feb 10, 2004 6:05 pm

We are using Momentics 6.2.1A/B with the target as a Samsung S3C2410
processor with on board OHCI compliant USB.

When we run the devu-ohci program it complains with the error that it cannot
find the PCI server.

The processor doesn't have any PCI interface and documentation on OHCI
doesn't make reference to a PCI server.

What needs to be done to get the devu-ohci driver to run.

Yours

Paul.
Paul
 

Re: devu-ohci problem

Postby Martin Nylund » Wed Feb 11, 2004 9:05 am

Try: devu-ohci -a[base address] -i[interrupt]
The documentation doesn't mention these parameters

"Paul" <qnxnews@nospam.rochesterkent.freeserve.co.uk.nospam> schrieb im
Newsbeitrag news:c0b50o$n3s$1@inn.qnx.com...
We are using Momentics 6.2.1A/B with the target as a Samsung S3C2410
processor with on board OHCI compliant USB.

When we run the devu-ohci program it complains with the error that it
cannot
find the PCI server.

The processor doesn't have any PCI interface and documentation on OHCI
doesn't make reference to a PCI server.

What needs to be done to get the devu-ohci driver to run.

Yours

Paul.

Martin Nylund
 

Re: devu-ohci problem

Postby Paul » Wed Feb 11, 2004 11:26 am

Thanks,

what do the parameters mean though.

I have assumed the base address was the address of the register set for the
USB interface but could be wrong.

From other post the -i could be anything. Is it the address of the usb
interrupt control register or an actual interrupt level?

If I use the command

devu-ohci -a 0x54000000

then I don't get the pci server message but I then start to get Timeout
message.

Many Thanks

Paul


"Martin Nylund" <mnylund@emtrion.de> wrote in message
news:c0cpok$4ie$1@inn.qnx.com...
Try: devu-ohci -a[base address] -i[interrupt]
The documentation doesn't mention these parameters

"Paul" <qnxnews@nospam.rochesterkent.freeserve.co.uk.nospam> schrieb im
Newsbeitrag news:c0b50o$n3s$1@inn.qnx.com...
We are using Momentics 6.2.1A/B with the target as a Samsung S3C2410
processor with on board OHCI compliant USB.

When we run the devu-ohci program it complains with the error that it
cannot
find the PCI server.

The processor doesn't have any PCI interface and documentation on OHCI
doesn't make reference to a PCI server.

What needs to be done to get the devu-ohci driver to run.

Yours

Paul.



Paul
 

Re: devu-ohci problem

Postby Martin Nylund » Wed Feb 11, 2004 6:05 pm

"Paul" <qnxnews@nospam.rochesterkent.freeserve.co.uk.nospam> schrieb im
Newsbeitrag news:c0d209$bee$1@inn.qnx.com...
Thanks,

what do the parameters mean though.

I have assumed the base address was the address of the register set for
the
USB interface but could be wrong.

it's the base address for the registers

From other post the -i could be anything. Is it the address of the usb
interrupt control register or an actual interrupt level?

it's the interrupt vector. Refer to the BSP doc to find out its value


If I use the command

devu-ohci -a 0x54000000

then I don't get the pci server message but I then start to get Timeout
message.

I've never seen the devu-ohci internals so if it doesn't work with correct
base address and interrupt vector, I cant help you any further. We don't
have working USB because our USB controller wants to use its internal memory
for the descriptor queues and there's no way of telling that to the driver.


Many Thanks

Paul


"Martin Nylund" <mnylund@emtrion.de> wrote in message
news:c0cpok$4ie$1@inn.qnx.com...
Try: devu-ohci -a[base address] -i[interrupt]
The documentation doesn't mention these parameters

"Paul" <qnxnews@nospam.rochesterkent.freeserve.co.uk.nospam> schrieb im
Newsbeitrag news:c0b50o$n3s$1@inn.qnx.com...
We are using Momentics 6.2.1A/B with the target as a Samsung S3C2410
processor with on board OHCI compliant USB.

When we run the devu-ohci program it complains with the error that it
cannot
find the PCI server.

The processor doesn't have any PCI interface and documentation on OHCI
doesn't make reference to a PCI server.

What needs to be done to get the devu-ohci driver to run.

Yours

Paul.





Martin Nylund
 

Re: devu-ohci problem

Postby Paul » Wed Feb 11, 2004 8:26 pm

Thanks for this info, regards the interrup vector, ARM based processors
only have the one IRQ vector which presumably goes to a qnx ISR to determine
the cause of the interrupt. Is the interrupt vector the value of
vector_base in the intrinfo structure or something else?

Paul

..
"Martin Nylund" <mnylund@emtrion.de> wrote in message
news:c0dpd4$bj$1@inn.qnx.com...
"Paul" <qnxnews@nospam.rochesterkent.freeserve.co.uk.nospam> schrieb im
Newsbeitrag news:c0d209$bee$1@inn.qnx.com...
Thanks,

what do the parameters mean though.

I have assumed the base address was the address of the register set for
the
USB interface but could be wrong.

it's the base address for the registers


From other post the -i could be anything. Is it the address of the usb
interrupt control register or an actual interrupt level?

it's the interrupt vector. Refer to the BSP doc to find out its value

If I use the command

devu-ohci -a 0x54000000

then I don't get the pci server message but I then start to get Timeout
message.

I've never seen the devu-ohci internals so if it doesn't work with correct
base address and interrupt vector, I cant help you any further. We don't
have working USB because our USB controller wants to use its internal
memory
for the descriptor queues and there's no way of telling that to the
driver.



Many Thanks

Paul


"Martin Nylund" <mnylund@emtrion.de> wrote in message
news:c0cpok$4ie$1@inn.qnx.com...
Try: devu-ohci -a[base address] -i[interrupt]
The documentation doesn't mention these parameters

"Paul" <qnxnews@nospam.rochesterkent.freeserve.co.uk.nospam> schrieb
im
Newsbeitrag news:c0b50o$n3s$1@inn.qnx.com...
We are using Momentics 6.2.1A/B with the target as a Samsung S3C2410
processor with on board OHCI compliant USB.

When we run the devu-ohci program it complains with the error that
it
cannot
find the PCI server.

The processor doesn't have any PCI interface and documentation on
OHCI
doesn't make reference to a PCI server.

What needs to be done to get the devu-ohci driver to run.

Yours

Paul.







Paul
 

Re: devu-ohci problem

Postby Paul » Wed Feb 11, 2004 10:49 pm

Ahh,

I've just read the QNX documentation on interrupt handlers an I got it
completely wrong. It looks like all ISR will register with the same single
ARM ISR vector then all ISRs will be scheduled and it is up to the ISR to
decide if its device was the source of the interrupt.

If someone can confirm this is correct that would be great.

Paul.


"Paul" <qnxnews@nospam.rochesterkent.freeserve.co.uk.nospam> wrote in
message news:c0e1la$6ta$1@inn.qnx.com...
Thanks for this info, regards the interrup vector, ARM based processors
only have the one IRQ vector which presumably goes to a qnx ISR to
determine
the cause of the interrupt. Is the interrupt vector the value of
vector_base in the intrinfo structure or something else?

Paul

.
"Martin Nylund" <mnylund@emtrion.de> wrote in message
news:c0dpd4$bj$1@inn.qnx.com...

"Paul" <qnxnews@nospam.rochesterkent.freeserve.co.uk.nospam> schrieb im
Newsbeitrag news:c0d209$bee$1@inn.qnx.com...
Thanks,

what do the parameters mean though.

I have assumed the base address was the address of the register set
for
the
USB interface but could be wrong.

it's the base address for the registers


From other post the -i could be anything. Is it the address of the
usb
interrupt control register or an actual interrupt level?

it's the interrupt vector. Refer to the BSP doc to find out its value

If I use the command

devu-ohci -a 0x54000000

then I don't get the pci server message but I then start to get
Timeout
message.

I've never seen the devu-ohci internals so if it doesn't work with
correct
base address and interrupt vector, I cant help you any further. We don't
have working USB because our USB controller wants to use its internal
memory
for the descriptor queues and there's no way of telling that to the
driver.



Many Thanks

Paul


"Martin Nylund" <mnylund@emtrion.de> wrote in message
news:c0cpok$4ie$1@inn.qnx.com...
Try: devu-ohci -a[base address] -i[interrupt]
The documentation doesn't mention these parameters

"Paul" <qnxnews@nospam.rochesterkent.freeserve.co.uk.nospam> schrieb
im
Newsbeitrag news:c0b50o$n3s$1@inn.qnx.com...
We are using Momentics 6.2.1A/B with the target as a Samsung
S3C2410
processor with on board OHCI compliant USB.

When we run the devu-ohci program it complains with the error that
it
cannot
find the PCI server.

The processor doesn't have any PCI interface and documentation on
OHCI
doesn't make reference to a PCI server.

What needs to be done to get the devu-ohci driver to run.

Yours

Paul.









Paul
 

Re: devu-ohci problem

Postby cdm » Thu Feb 12, 2004 1:45 am

Paul <qnxnews@nospam.rochesterkent.freeserve.co.uk.nospam> wrote:
Ahh,

I've just read the QNX documentation on interrupt handlers an I got it
completely wrong. It looks like all ISR will register with the same single
ARM ISR vector then all ISRs will be scheduled and it is up to the ISR to
decide if its device was the source of the interrupt.

If someone can confirm this is correct that would be great.


No, that isn't exactly how it works.

There is a single phyiscal interrupt line. When that fires, there are
interrupt callouts (from your startup-* for the board you are using) that
go out to the interrupt controler(s) and identify which interrupt was fired.
This is then translated into an interrupt number which drivers use to
attach to. The mappings of what interrupts are what interrupt number are
setup in the startup code for the particular board (normally in a file
called init_intrinfo.c).

chris

--
Chris McKillop <cdm@qnx.com> "The faster I go, the behinder I get."
Software Engineer, QSSL -- Lewis Carroll --
http://qnx.wox.org/
cdm
QNX Master
 
Posts: 789
Joined: Fri Jul 05, 2002 9:38 am

Re: devu-ohci problem

Postby Paul » Thu Feb 12, 2004 2:52 pm

"Chris McKillop" <cdm@qnx.com> wrote in message
news:c0elrd$lp9$1@inn.qnx.com...
Paul <qnxnews@nospam.rochesterkent.freeserve.co.uk.nospam> wrote:
Ahh,

SNIP


If someone can confirm this is correct that would be great.


No, that isn't exactly how it works.

There is a single phyiscal interrupt line. When that fires, there are
interrupt callouts (from your startup-* for the board you are using) that
go out to the interrupt controler(s) and identify which interrupt was
fired.
This is then translated into an interrupt number which drivers use to
attach to. The mappings of what interrupts are what interrupt number are
setup in the startup code for the particular board (normally in a file
called init_intrinfo.c).


OK. I have looked at the init_intrinfo.c file which only shows support for
UARTs and A/D convertor and an external interrupt in the startup_intrinfo
array.

Can I add my own section to do this and if so where does the vector_base
number come from they appear they appear to start at an arbitary point e.g.
Uart0 is vector base 32. it then has a 3 for the number of ints presumably
rx,tx and error and then a cascade int number which ties up with the bit in
the interrupt mask for the processor I am using. I just can't work out
where the vector base number comes from. BTW the external interrupt for the
ethernet controller jumps to 108.


Also for the callbacks can I just point them at the default interrupt
handler in the callout_interrupt-*.s file or do I need to write a special
routine for the devu-ohci to work.

Paul
Paul
 

Re: devu-ohci problem

Postby Sunil Kittur » Thu Feb 12, 2004 3:35 pm

Paul wrote:

OK. I have looked at the init_intrinfo.c file which only shows support for
UARTs and A/D convertor and an external interrupt in the startup_intrinfo
array.

Can I add my own section to do this and if so where does the vector_base
number come from they appear they appear to start at an arbitary point e.g.
Uart0 is vector base 32. it then has a 3 for the number of ints presumably
rx,tx and error and then a cascade int number which ties up with the bit in
the interrupt mask for the processor I am using. I just can't work out
where the vector base number comes from. BTW the external interrupt for the
ethernet controller jumps to 108.

Each entry in that array describes an "interrupt controller".
The controller supports num_vectors interrupt sources, and
these are given interrupt vector numbers in the range
[vector_base, vector_base+num_vectors)

The cascade_vector describes the interrupt line on another
"controller" that this controller is cascaded from.

The choice of vector_base is essentially arbitrary and could
be any value chosen by the writer of the board startup program.
However, they must define distinct vector ranges.

The kernel just looks up the "vector" number by matching it
against the set of ranges defined in the intrinfo array.

The vector you need to use would depend on which "controller"
the USB interrupt was attached to. The build file for one
s3c2410 has comments that it is on the on-chip interrupt
controller, vector 26.

Also for the callbacks can I just point them at the default interrupt
handler in the callout_interrupt-*.s file or do I need to write a special
routine for the devu-ohci to work.

The callouts are for each "controller":
- one for the on-chip interrupt controller
- one for additional controllers cascaded from the on-chip one

If there are multiple USB interrupts that are all cascaded off
the single on-chip controller's interrupt line, you may have
to define a controller and write callouts to manage these
cascaded interrupts - the comment in the build file doesn't
say the USB interrupt is cascaded, so I don't know for sure.

Sunil.
Sunil Kittur
 

Re: devu-ohci problem

Postby Henry VanDyke » Tue Feb 17, 2004 3:50 pm

Try
devu-ohci -a 0x49000000 -i26


Sunil Kittur <skittur@qnx.com> wrote in message
news:c0g4na$13h$1@inn.qnx.com...
Paul wrote:

OK. I have looked at the init_intrinfo.c file which only shows support
for
UARTs and A/D convertor and an external interrupt in the
startup_intrinfo
array.

Can I add my own section to do this and if so where does the vector_base
number come from they appear they appear to start at an arbitary point
e.g.
Uart0 is vector base 32. it then has a 3 for the number of ints
presumably
rx,tx and error and then a cascade int number which ties up with the bit
in
the interrupt mask for the processor I am using. I just can't work out
where the vector base number comes from. BTW the external interrupt for
the
ethernet controller jumps to 108.

Each entry in that array describes an "interrupt controller".
The controller supports num_vectors interrupt sources, and
these are given interrupt vector numbers in the range
[vector_base, vector_base+num_vectors)

The cascade_vector describes the interrupt line on another
"controller" that this controller is cascaded from.

The choice of vector_base is essentially arbitrary and could
be any value chosen by the writer of the board startup program.
However, they must define distinct vector ranges.

The kernel just looks up the "vector" number by matching it
against the set of ranges defined in the intrinfo array.

The vector you need to use would depend on which "controller"
the USB interrupt was attached to. The build file for one
s3c2410 has comments that it is on the on-chip interrupt
controller, vector 26.

Also for the callbacks can I just point them at the default interrupt
handler in the callout_interrupt-*.s file or do I need to write a
special
routine for the devu-ohci to work.

The callouts are for each "controller":
- one for the on-chip interrupt controller
- one for additional controllers cascaded from the on-chip one

If there are multiple USB interrupts that are all cascaded off
the single on-chip controller's interrupt line, you may have
to define a controller and write callouts to manage these
cascaded interrupts - the comment in the build file doesn't
say the USB interrupt is cascaded, so I don't know for sure.

Sunil.
Henry VanDyke
 


Return to qnx.ddk

Who is online

Users browsing this forum: No registered users and 3 guests