Hi all, I'm currently developing a 3.10.31-ltsi kernel that running on a Nios II-based system. This system also contains several components including an Altera JTAG UART, USB host controller and a timer. In Qsys, I assigned the following Nios II interrupts for these system components: jtaguart: IRQ 0 timer: IRQ 1 usbhc: IRQ 2 The device tree binary (.dtb), U-boot and the kernel are built using these assignments and stored to flash. However, when the kernel boots, the interrupt for the Altera JTAG UART is remapped to IRQ 2 as seen in the following KERNEL DEBUG message: ttyJ0 at MMIO 0x1001840 (irq = 2) is a Altera JTAG UART When this happens, the kernel is no longer able to attach the USB host contoller (usbhc) to IRQ 2 and the following error messages come up: genirq: flags mismatch irq 2. 00000000 (altera_jtaguart) vs. 00000080 (sls-hcd: usb1) altera_jtaguart: unable to attach altera jtag uart 0 interrupt vector=2 I have some questions about this process that I'm hoping someone can explain: - When the Altera JTAG component / device is added, why is the interrupt remapped from IRQ 0 to IRQ 2? - Why isn't the usbhc controller remapped from IRQ 2 to something else? In addition, when I forced the Altera JTAG UART interrupt to IRQ 0 to match the Qsys setting by modifying the altera_jtaguart driver, when the kernel attempts to attach IRQ 0 to the JTAG UART, the following error message was displayed: altera_jtaguart: unable to attach Altera JTAG UART 0 interrupt vector=0[/I][/I] However, the usbhc component was correctly added and attached to IRQ 2 as indicated by the following message:sls-hcd sls-hcd.0: irq2, io mem 0xe1008000[/I][/I] Any feedback that would help explain what is happening with these interrupts during the kernel booting sequence would be appreciated. - Brad

Hello Brad, At the beginning you mentioned following : --- Quote Start --- In Qsys, I assigned the following Nios II interrupts for these system components: timer: IRQ 0 jtaguart: IRQ 1 usbhc: IRQ 2 --- Quote End --- Later you mentioned following, --- Quote Start --- In addition, when I forced the Altera JTAG UART interrupt to IRQ 0 to match the Qsys setting by modifying the altera_jtaguart driver, when the kernel attempts to attach IRQ 0 to the JTAG UART, the following error message was displayed: altera_jtaguart: unable to attach Altera JTAG UART 0 interrupt vector=0 --- Quote End --- Should not you try to force Altera JTAG UART interrupt to IRQ 1, not IRQ 0 ( to match that with Qsys setting.)? Cheers, Bhaumik

Hi Brad, We tried to do some analysis on this here. Instead of forcing IRQ number in altera_jtag_probe, we tried to notice effect of manual change in dts file. In that we observed following, JTAG UART was assigned IRQ 1 when we set interrupts = <0> in DTS file for jtaguart. JTAG UART was assigned IRQ 2 when we set interrupts = <1> in DTS file for jtaguart. JTAG UART was assigned IRQ 2 when we set interrupts = <2> in DTS file for jtaguart. We did above only to notice effect of interrupt number assigned in DTS to jtaguart and how it is actually selected during build. This is for system in which Timer is at IRQ 0, JTAG is at 1 and Host Controller is at 2. This is little bit different than yours. But in this, we are getting same problem. Based on this, it seems (or say apparent ) it is making some mistake in interpreting interrupt number assigned to jtaguart during the time it parses DTS.If we can get location from where ( or how ) DTS information is get collected, we shall be able to get some breakthrough. This is just my thought. You might have better way for debugging. Thanks, Bhaumik

Hi Bhaumik, Thank you for the useful reference information. It's good to know that someone else can recreate the basic problem I have been seeing when setting the interrupt values in the .dts file to one value only to sometimes have the kernel remap to a different interrupt at boot up. My current setup has the timer using IRQ 0, JTAG UART using IRQ 1 and USB Host Controller using IRQ 2. I also have been using my modified altera_jtaguart_probe() function to force the IRQ to different values but so far the right combination has not been found. If you find out how the information that is entered into the .dts file ends up being associated (or not associated) with the kernel function(s) that end up doing the actual physical and virtual interrupt mapping, I would like to hear about it. I'll do the same if I find out anything on my end. I currently don't have a better way of debugging other than document the settings used and results from those settings in an attempt to eliminate some of the combinations being used to help narrow it down. Thanks again for your feedback. - Brad

Hello Brad, Both of us are facing same problem and this is something which needs to be figure out. So, we will surely post here if we get some breakthrough. As Parth suggested in other thread, there is some workaround which worked for us. We moved JTAG IRQ from 0 to 4 in Qsys system. And it worked. So if you wish (just for a try), you can request your team mate to re-build Qsys system with IRQ changed for JTAG and can try with that. Thanks, Bhaumik

Altera JTAG UART used by kernel does not match IRQ assignment made in Qsys

21 Replies

Altera_Forum
Honored Contributor
10 years ago
Hi Bhaumik,

Thank you for your responses. That clears up a couple misunderstandings I was having.

It sounds like you are testing a system that is very similar to the one I'm using. I will be interested in hearing about the output from your "cat /proc/interrupts" command.

Based on your previous comments, I assume you are using v3.10 of the linux kernel. Is that right? If not, what version are you using?

I look forward to your response tomorrow.

- Brad
Altera_Forum
Honored Contributor
10 years ago
Hi Brad,

See my comments below.

--- Quote Start ---
I will be interested in hearing about the output from your "cat /proc/interrupts" command.
--- Quote End ---

With working design, we are getting same IRQ numbers assigned to peripherals when we run "cat /proc/interrupts" command. See following :

root:/> cat /proc/interrupts
CPU0
1: 41566 NIOS2-INTC timer
2: 86 NIOS2-INTC sls-hcd:usb1
4: 70 NIOS2-INTC altera_jtaguart

With non-working design, we are unable to run this command. Because after getting JTAG IRQ mismatch message, our control over console is lost. We are not able to write any command via Key-board.

--- Quote Start ---
Based on your previous comments, I assume you are using v3.10 of the linux kernel. Is that right? If not, what version are you using?
--- Quote End ---

Yes, we are using v3.10 of Linux kernel.

Thanks,
Bhaumik
Altera_Forum
Honored Contributor
10 years ago
Hi Bhaumik,

I'm still a little confused. Didn't you say in an earlier post that you were using IRQ 0 for the timer?

--- Quote Start ---
We did above only to notice effect of interrupt number assigned in DTS to jtaguart and how it is actually selected during build. This is for system in which Timer is at IRQ 0, JTAG is at 1 and Host Controller is at 2. This is little bit different than yours. But in this, we are getting same problem.
--- Quote End ---

From the output from your "cat /proc/interrupts" it appears that the timer is actually using IRQ 1. Is that correct or have you actually set the timer to use IRQ 1 in Qys and the associated .dts file?

I look forward to your response.

- Brad
Altera_Forum
Honored Contributor
10 years ago
Hi Brad,

Sorry, my mistake. I have not made any change in system today. I had wrong information regarding irq numbers in my Mind. In short, irq numbers mentioned today are right.

Regards,
Bhaumik
Altera_Forum
Honored Contributor
10 years ago
Hi Bhaumik,

Thank for the reply. So just to confirm, the interrupt settings you are using are the following:

timer: IRQ 1
uschc: IRQ 2
jtaguart: IRQ 4

Is that right?

- Brad
Altera_Forum
Honored Contributor
10 years ago
Hi Brad,

I need to check it again. I will tell you Monday.

Bhaumik
Altera_Forum
Honored Contributor
10 years ago
Hi Bhaumik,

I received an e-mail from Walter Goossens that probably doesn't apply to a single Nios II processor system but might apply to my system that has multiple Nios II processors that both are using interrupts.

However, I thought I would send it along for your reference anyway.

***** Start of e-mail *****

Hi Brad,

sorry for chiming in late (was on vacation). You mentioned earlier you had two nios2 processors connected in the same system.
sopc2dts has a history of messing things up when there are multiple interrupt master for a slave component. You can eliminate the confusion by adding a irqmasterignore tag (see http://rocketboards.org/foswiki/view/documentation/gsrdv141devicetreegenerator#irqmasterignore_tag ) to eliminate niosB from niosA and vice-versa.

Walter

***** End of e-mail *****

I don't know if it will make a difference but I will look into it later. If you try it, let me know if it makes any difference.

- Brad
Altera_Forum
Honored Contributor
10 years ago
Hello Brad,

Thank you for providing link. Although I looked at link you provided, we have not yet tried that one. But I have something else to share with you.

I must appreciate your observation skill. You have correctly identified presence of some issue with Qsys IRQ assignment and IRQ numbers we are getting in Linux image. So far, I was in misconception that only JTAG IRQ is assigned wrong number. That's why I didn't notice IRQ number being assigned to Timer and considered it as correct until you pointed out.( Note: Edited previous post to eliminate confusion in future.)

Today we tried following. We have removed USB2.0 Host as well as HC DMA components from system. Now, there are only 2 interrupt generators ( Timer and JTAG). We tried to observe how IRQ numbers are being mapped by Linux kernel. Here are our observations so far.

case 1 :
Qsys System IRQ assignment: Timer - 0, JTAG - 1
Linux Image IRQ assignment: Timer - 1, JTAG - 2

case 2 :
Qsys System IRQ assignment: Timer - 2, JTAG - 3
Linux Image IRQ assignment: Timer - 2, JTAG - 3

case 3 :
Qsys System IRQ assignment: Timer - 1, JTAG - 2
Linux Image IRQ assignment: Timer - 1, JTAG - 2

We will continue our debug operation to figure out why IRQ numbers are being remapped by Linux Kernel v3.10. Meantime if you find something, please do share.

Thanks,
Bhaumik
Altera_Forum
Honored Contributor
10 years ago
Hello Brad,

We did one more test today and here is its result.

case 4 :
Qsys System IRQ assignment: Timer - 2, JTAG - 1
Linux Image IRQ assignment: Timer - 2, JTAG - 1

These results lead us to think that Linux image IRQ assignment differs from that of Qsys IRQ if we have assigned IRQ 0 to some component in Qsys design.

During some further research on internet, we came to know about "irq_create_mapping" function. This functin maps Hardware IRQ into virtual IRQ. More information on this can be found at following : https://www.kernel.org/doc/documentation/irq-domain.txt

We will continue our debug operation and will keep you posted. Meantime, as usual, if you come across any useful item, please share.

Cheers,
Bhaumik
Altera_Forum
Honored Contributor
10 years ago
Hello Brad,

Based on our primary testing, it looks like Linux v 3.10 reserves virtual IRQ 0 for some internal use. Hence if some item has assigned Hardware IRQ 0, it would be mapped to virtual IRQ 1. So driver should use Virtual IRQ assigned to it instead of Hardware IRQ numbers.

Thanks,
Bhaumik

Forum Discussion

Altera JTAG UART used by kernel does not match IRQ assignment made in Qsys

21 Replies

Recent Discussions

licensing.altera.com never worked

NiosV and juart-terminal

NIOS V/m dbg_reset_out signal (Q25.1 Std, MAX10)

JTAG_UART stuck in printf

Ashling IDE scripted project creation