Forum Discussion
Altera_Forum
Honored Contributor
Honored ContributorAltera 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. - Brad21 Replies
Altera_ForumHello 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
TO_BE_DONE
- Altera_Forum
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
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
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
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
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
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
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
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
