On 2018-04-17 15:17, Giovani Gracioli wrote: > It is not completely the same configurations, one is the root-cell and > another one is a bare-metal cell based on the gic-demo. I attached both here. > > I believe the Linux program is correct, because I can see the number of > interrupts increasing by outputting /proc/interrupts. It basically maps > 0xfc100000 using mmap and then writes 1 to mapped_adress + 3. >
Root cell and non-root cell are still sharing interrupts /wrt the virtual pci host controller and ivshmem. Just derive your inmate config from configs/arm64/zynqmp-zcu102-linux-demo[-2].c, those work. Jan >> On 2018-04-16 23:53, Giovani Gracioli wrote: >>> I instrumented the code with several prints. >>> >>> When I start the bare-metal cell, I can see that an interrupt from CPU 3 is >>> issued and handled by CPU 0: >>> >>> Started cell "gic-demo-ivshmem" >>> ivshmem_register_mmio() mmio->address = 8, mmio->is_write = 0, current cpu >>> = 3 >>> ivshmem_register_mmio() mmio->address = 0, mmio->is_write = 1, current cpu >>> = 3 >>> arch_ivshmem_update_intx(ive=0x0000ffffc02450a0), >>> device->info->num_msix_vectors = 0, ctrl eg intx enable = 1 >>> ivshmem_register_mmio() mmio->address = 12, mmio->is_write = 1, current cpu >>> = 3 >>> @@@@@ ivshmem_remote_interrupt() ive->remote: 0x0000ffffc0245000, current >>> cpu = 3 >>> arch_ivshmem_trigger_interrupt(ive:0x0000ffffc0245000), irq_id:136, current >>> cpu = 3 >>> irqchip_set_pending(), local_injection = 0, sender (current cpu) = 3 >>> irqchip_set_pending() -> inside if(!cpu_data) >>> irqchip_handle_irq(cpu_data:0x0000ffffc021d000, irq_id:136), is_sgi(irq_id) >>> = 0 >>> irqchip_handle_irq() this_cpu_data() = 0x0000ffffc021d000, current cpu 0, >>> cpu_data->cpu_id = 0 >>> arch_handle_phys_irq calling >>> irqchip_set_pending(cpu_data=0x0000ffffc021d000, irqn=136), cpu_id = 0 >>> irqchip_set_pending(), local_injection = 1, sender (current cpu) = 0 >>> irqchip_set_pending() -> just return after irqchip.inject_irq, >>> cpu_data->cpu_id = 0 >>> irqchip_set_pending(), local_injection = 1, sender (current cpu) = 0 >>> irqchip_set_pending() -> just return after irqchip.inject_irq, >>> cpu_data->cpu_id = 0 >>> >>> When I run the program to generate an interrupt from Linux, I got the >>> following output: >>> >>> /dev/mem opened. >>> Memory mapped at address 0x7f988f2000. >>> Writing 1 to 0x7f988f200c >>> ivshmem_register_mmio() mmio->address = 12, mmio->is_write = 1, current cpu >>> = 1 >>> @@@@@ ivshmem_remote_interrupt() ive->remote: 0x0000ffffc02450a0, current >>> cpu = 1 >>> arch_ivshmem_trigger_interrupt(ive:0x0000ffffc02450a0), irq_id:136, current >>> cpu = 1 >>> irqchip_set_pending(), local_injection = 0, sender (current cpu) = 1 >>> irqchip_set_pending() -> inside if(!cpu_data) >>> irqchip_handle_irq(cpu_data:0x0000ffffc021d000, irq_id:136), is_sgi(irq_id) >>> = 0 >>> irqchip_handle_irq() this_cpu_data() = 0x0000ffffc021d000, current cpu 0, >>> cpu_data->cpu_id = 0 >>> arch_handle_phys_irq calling >>> irqchip_set_pending(cpu_data=0x0000ffffc021d000, irqn=136), cpu_id = 0 >>> irqchip_set_pending(), local_injection = 1, sender (current cpu) = 0 >>> irqchip_set_pending() -> just return after irqchip.inject_irq, >>> cpu_data->cpu_id = 0 >>> irqchip_handle_irq(cpu_data:0x0000ffffc021d000, irq_id:25), is_sgi(irq_id) >>> = 0 >>> irqchip_handle_irq() this_cpu_data() = 0x0000ffffc021d000, current cpu 0, >>> cpu_data->cpu_id = 0 >>> irqchip_set_pending(), local_injection = 1, sender (current cpu) = 0 >>> irqchip_set_pending() -> just return after irqchip.inject_irq, >>> cpu_data->cpu_id = 0 >>> >>> Seems that the connection between Linux (root-cell) and the bare-metal one >>> is not correct, but the other way around is fine. Why is that? >> >> Just to confirm my understanding: You have the same cell configurations, >> just switching the binary executed in the non-root cell between Linux >> and a bare-metal inmate, right? >> >> Is the root Linux programming the INTX_CTRL register properly (not part >> of your trace)? >> >> Jan >> >> -- >> Siemens AG, Corporate Technology, CT RDA IOT SES-DE >> Corporate Competence Center Embedded Linux > -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
