Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
4,119 Views

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

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
0 Kudos
21 Replies
Altera_Forum
Honored Contributor I
78 Views

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
Altera_Forum
Honored Contributor I
78 Views

TO_BE_DONE

Altera_Forum
Honored Contributor I
78 Views

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
Altera_Forum
Honored Contributor I
78 Views

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
Altera_Forum
Honored Contributor I
78 Views

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_Forum
Honored Contributor I
78 Views

Hi Bhaumik, 

 

Thanks for your feedback. 

 

I have not yet tried the workaround suggested by Parth by moving the jtaguart interrupt from IRQ 0 to IRQ 4 in Qsys. Although, based on another suggestion that I needed to dedicate my timer component to IRQ 0, I currently have my jtaguart is assigned to IRQ 1. However, I still will try and make another build with the JTAG UART assigned to IRQ 4 in Qys and see if it works. 

 

When you made this new assignment, did you also make the associated change in the .dts file, compile it and store it to your platform (or have it embedded in the kernel) as part of this workaround? 

 

Also, does your system contain a USB host controller component in Qsys? If not, can you say what Qsys components are included in your system? 

 

Please let me know if you have any questions and I look forward to your response. 

 

- Brad
Altera_Forum
Honored Contributor I
78 Views

Hello Brad, 

 

Our Qsys system was same in both cases with only exception in IRQ number for JTAG UART. ( Non working system had jtag irq set to 1 and working had irq set to 4.) 

 

Note that after moving irq to 4, we didn't require to make any manual change in DTS file for JTAG UART. 

 

Yes, in both cases, it had USB Host controller in it. 

 

Regards, 

Bhaumik
Altera_Forum
Honored Contributor I
78 Views

Hi Bhaumik, 

 

So if I understand you correctly, if you didn't make any changes to the .dts file then the entry for this component in the device tree blob was still set to 1, correct? If that's the case then what IRQ did the kernel end up using? There seems to be a direct conflict between the IRQ setting in Qsys (IRQ 4) and the .dts/.dtb file (IRQ 1). I have always had problems if the IRQ settings in the Qsys system and the .dts/.dtb files didn't match.  

 

I assume you are using Linux as your OS (or are you using a HAL-based system?). If you are using Linux would it be possible for you to run the "cat /proc/interrupts" command to see how the interrupts mapped to the kernel. 

 

Also, could you tell me what IRQ you have assigned to your USB Host Controller? Can you say which manufacturer of the USB Host Controller core you are using?  

 

I'm just trying to run down all the possible differences between our systems. 

 

Thanks again for all your help. Let me know if you have any questions and I look forward to your response. 

 

- Brad
Altera_Forum
Honored Contributor I
78 Views

Hello Brad, 

 

Let me give some more description. 

 

Initially I made a Qsys design with JTAG IRQ set to 1. I gave that design to our software engineer for testing with Linux version 2.68. It worked nicely.  

 

Then I asked him to test same design with Linux version 3.10. He reported to me that with Linux v3.10 he was getting IRQ mismatch related problem (same as you) JTAG was assigned IRQ 2 while actually it should have assigned to IRQ 1. 

 

We thought let see what happens if we change JTAG IRQ in Qsys. We tried that and regenerated Qsys system with JTAG IRQ set to 4. Now, as .sopcinfo had got changed, we also had to re run sopc2dts utility. We did that and got new dts file. We tried to make using new dts and it didn't gave any error. 

 

I hope this makes things more clear. 

 

Regards, 

Bhaumik
Altera_Forum
Honored Contributor I
78 Views

Hello Brad, 

 

Here are some answers to your questions: 

 

 

--- Quote Start ---  

So if I understand you correctly, if you didn't make any changes to the .dts file then the entry for this component in the device tree blob was still set to 1, correct?If that's the case then what IRQ did the kernel end up using? There seems to be a direct conflict between the IRQ setting in Qsys (IRQ 4) and the .dts/.dtb file (IRQ 1). I have always had problems if the IRQ settings in the Qsys system and the .dts/.dtb files didn't match.  

--- Quote End ---  

 

 

There is some misunderstanding. I said we didn't make any MANUAL change. As .sopcinfo had updated, we had to re run sopc2dts utility. So with new dts, device tree blob was set to 4 (same as assigned in Qsys)  

 

 

 

--- Quote Start ---  

I assume you are using Linux as your OS (or are you using a HAL-based system?). 

--- Quote End ---  

 

Yes, we are using Linux. 

 

 

--- Quote Start ---  

If you are using Linux would it be possible for you to run the "cat /proc/interrupts" command to see how the interrupts mapped to the kernel. 

--- Quote End ---  

 

We will try it tomorrow. 

 

 

--- Quote Start ---  

Also, could you tell me what IRQ you have assigned to your USB Host Controller? Can you say which manufacturer of the USB Host Controller core you are using? 

--- Quote End ---  

 

IRQ 2 have been assigned to USB Host Controller and IP core is from System Level Solutions (I) Pvt. Ltd. 

 

Let me know if you have any other confusion. 

 

Thanks, 

Bhaumik
Altera_Forum
Honored Contributor I
78 Views

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 I
78 Views

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 I
78 Views

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 I
78 Views

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 I
78 Views

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 I
78 Views

Hi Brad, 

 

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

 

Bhaumik
Altera_Forum
Honored Contributor I
78 Views

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 I
78 Views

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 I
78 Views

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 I
9 Views

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
Reply