Hi Adam and L4 community
I've been testing somethings on the Odroid-X2(Exynos4412). It seems that the IRQ handler only handles the first IRQ and disables the IRQs. I have added the following code to check the IRQs in the function Kernel_thread::bootstrap() in the file src/kernel/fiasco/src/kern/kernel_thread.cpp
Per_cpu_data::run_late_ctors(Cpu::invalid()); bootstrap_arch();
Timer_tick::enable(current_cpu()); Proc::sti();
++ Proc::Status st = Proc::interrupts(); ++ if(st & Proc::Status_interrupts_disabled) ++ printf("IRQs are enabled\n"); ++ else ++ printf("IRQs are disabled\n");
Watchdog::enable();
I'm trying to check that the IRQs are enabled. The Proc::sti() must activate the IRQs in the CPSR registers, and Proc::interrupts() must return if the interrupts are enabled, but always i'm getting "IRQs are disabled". I have tested the hardware with a Linux kernel and it's working fine. I have tested "CPSIE i" and "CPSIE f" to enable the interrupts and get the same result. I have incremented the warn level on Fiasco.OC, i'm getting:
KERNEL: Warning Buddy:alloc Size mismatch: a80 v 1000
I have also tested the local timers on the Exynos4412. The local timer at CPU0 is working fine. It has been configured to auto-reload with 12000 as interval. The local counter decrements the value and reload when arrives zero, but don't raises the interrupt. To test the interrupts have created an small buffer to store the Kip::k()->clock on every interrupt. I have used the buffer to avoid the call of an interrupt inside another interrupt. I have tried to print the values on the function Delay::mesaure(), but it only stores one value. The same thing happens if I use a interrupt counter. Now i'm trying to check the IRQ handler caller, from the general mechanism to the specific interrupt handler, to catch the point where the IRQs are been disabled. Anyone have any suggestions?
Best regards
Hi,
On Fri May 22, 2015 at 02:03:24 -0400, Reinier Millo Sánchez wrote:
I've been testing somethings on the Odroid-X2(Exynos4412). It seems that the IRQ handler only handles the first IRQ and disables the IRQs. I have added the following code to check the IRQs in the function Kernel_thread::bootstrap() in the file src/kernel/fiasco/src/kern/kernel_thread.cpp
Per_cpu_data::run_late_ctors(Cpu::invalid()); bootstrap_arch();
Timer_tick::enable(current_cpu()); Proc::sti();
++ Proc::Status st = Proc::interrupts(); ++ if(st & Proc::Status_interrupts_disabled) ++ printf("IRQs are enabled\n");
Just use if (st) ... , Proc::interrupts() is returning a boolean.
++ else ++ printf("IRQs are disabled\n");
Watchdog::enable();
I'm trying to check that the IRQs are enabled. The Proc::sti() must activate the IRQs in the CPSR registers, and Proc::interrupts() must return if the interrupts are enabled, but always i'm getting "IRQs are disabled". I have tested the hardware with a Linux kernel and it's working fine. I have tested "CPSIE i" and "CPSIE f" to enable the interrupts and get the same result. I have incremented the warn level on Fiasco.OC, i'm getting:
KERNEL: Warning Buddy:alloc Size mismatch: a80 v 1000
I have also tested the local timers on the Exynos4412. The local timer at CPU0 is working fine. It has been configured to auto-reload with 12000 as interval. The local counter decrements the value and reload when arrives zero, but don't raises the interrupt. To test the interrupts have created an small buffer to store the Kip::k()->clock on every interrupt. I have used the buffer to avoid the call of an interrupt inside another interrupt. I have tried to print the values on the function Delay::mesaure(), but it only stores one value. The same thing happens if I use a interrupt counter. Now i'm trying to check the IRQ handler caller, from the general mechanism to the specific interrupt handler, to catch the point where the IRQs are been disabled. Anyone have any suggestions?
So the handler is actually called all the time right?
Adam
Hi Adam
On 05/26/2015 05:52 PM, Adam Lackorzynski wrote:
Hi,
On Fri May 22, 2015 at 02:03:24 -0400, Reinier Millo Sánchez wrote:
I've been testing somethings on the Odroid-X2(Exynos4412). It seems that the IRQ handler only handles the first IRQ and disables the IRQs. I have added the following code to check the IRQs in the function Kernel_thread::bootstrap() in the file src/kernel/fiasco/src/kern/kernel_thread.cpp
Per_cpu_data::run_late_ctors(Cpu::invalid()); bootstrap_arch(); Timer_tick::enable(current_cpu()); Proc::sti(); ++ Proc::Status st = Proc::interrupts(); ++ if(st & Proc::Status_interrupts_disabled) ++ printf("IRQs are enabled\n");Just use if (st) ... , Proc::interrupts() is returning a boolean.
I have tested using if(st) and the result is the same.
++ else ++ printf("IRQs are disabled\n"); Watchdog::enable();I'm trying to check that the IRQs are enabled. The Proc::sti() must activate the IRQs in the CPSR registers, and Proc::interrupts() must return if the interrupts are enabled, but always i'm getting "IRQs are disabled". I have tested the hardware with a Linux kernel and it's working fine. I have tested "CPSIE i" and "CPSIE f" to enable the interrupts and get the same result. I have incremented the warn level on Fiasco.OC, i'm getting:
KERNEL: Warning Buddy:alloc Size mismatch: a80 v 1000I have also tested the local timers on the Exynos4412. The local timer at CPU0 is working fine. It has been configured to auto-reload with 12000 as interval. The local counter decrements the value and reload when arrives zero, but don't raises the interrupt. To test the interrupts have created an small buffer to store the Kip::k()->clock on every interrupt. I have used the buffer to avoid the call of an interrupt inside another interrupt. I have tried to print the values on the function Delay::mesaure(), but it only stores one value. The same thing happens if I use a interrupt counter. Now i'm trying to check the IRQ handler caller, from the general mechanism to the specific interrupt handler, to catch the point where the IRQs are been disabled. Anyone have any suggestions?
So the handler is actually called all the time right?
The handler is called once, after that, the interrupt remains disabled. Best regards
Hi Adam
I have some questions. Some months ago we have tested succesfully Fiasco.OC+L4Re on Exynos5250. Now we're having some troubles to test it on Exynos4412. Reviewing the interrupts mechanism, I have noted that the GIC is implemented on Fiasco.OC at the ARM architecture level. Fiasco.OC it's working fine on Exynos5250, but the Exynos5250's GIC is based on the "ARM Generic Interrupt Controller-Architecture Specification, Architecture version 2.0". Looking on the Cortex-A9 MPCore TRM, I have found that the Cortex-A9's GIC is based on the "ARM Generic Interrupt Controller-Architecture Specification, Architecture version 1.0".
What version of the GIC's specification was used to implement GIC's class in Fiasco.OC? In case that version 2.0 is being used, this can affect the interrupts on Exynos4412?
Best regards
Hi community
We have adapted the Proc class to support the IRQ on Fiasco.OC when compiling it in TrustZone Normal Side. Following the principle that in TrustZone the IRQ are used on Normal Side and the FIQ are used in Secure Side, we have only used the IRQ when compile the Fiasco.OC with TrustZone Normal Side. By default Fiasco.OC was using the IRQ and FIQ when compiling with TrustZone Normal Side. This is our patch:
diff --git a/src/kernel/fiasco/src/drivers/arm/processor-arm.cpp b/src/kernel/fiasco/src/drivers/arm/processor-arm.cpp index d9102c4..8ee9101 100644 --- a/src/kernel/fiasco/src/drivers/arm/processor-arm.cpp +++ b/src/kernel/fiasco/src/drivers/arm/processor-arm.cpp @@ -32,7 +32,7 @@ public: static Cpu_phys_id cpu_id(); };
-INTERFACE[arm && !arm_em_tz]: +INTERFACE[arm && !arm_em_tz && !arm_em_ns]:
EXTENSION class Proc { @@ -62,6 +62,22 @@ public: }; };
+INTERFACE[arm && arm_em_ns]: + +EXTENSION class Proc +{ +public: + enum : unsigned + { + Cli_mask = Status_IRQ_disabled, + Sti_mask = Status_IRQ_disabled, + Status_preempt_disabled = Status_IRQ_disabled, + Status_interrupts_mask = Status_IRQ_disabled, + Status_always_mask = 0x10 | Status_FIQ_disabled, + }; +}; + + INTERFACE[arm && !hyp]:
EXTENSION class Proc
Now when we compile Fiasco.OC and run the Hello example for Odroid-X2 using TrustZone Normal Side, it works fine. We have noted the when is compiled with TrustZone Secure Side, then only use the FIQ, but when try to run it on Odroid-X2 it fails. This is the serial output:
Boot with zImage Starting kernel ...
L4 Bootstrapper Build: #70 Thu Jun 4 23:50:31 CDT 2015, 4.8.3 20140303 (prerelease) Scanning up to 2048 MB RAM, starting at offset 32MB Memory size is 2048MB (40000000 - bfffffff) Limiting 'RAM' region [ 40000000, bfffffff] { 80000000} to [ 40000000, bcffffff] { 7d000000} due to 3024 MB address limit RAM: 0000000040000000 - 00000000bcffffff: 2048000kB Total RAM: 2000MB Scanning fiasco Scanning sigma0 Scanning moe Moving up to 5 modules behind 41100000 moving module 02 { 4107e000-410af65f } -> { 4116f000-411a065f } [202336] moving module 01 { 41074000-4107d377 } -> { 41165000-4116e377 } [37752] moving module 00 { 41043000-410732ef } -> { 41134000-411642ef } [197360] moving module 04 { 41029000-410425b3 } -> { 4111a000-411335b3 } [103860] moving module 03 { 4100f000-41028493 } -> { 41100000-41119493 } [103572] Loading fiasco Loading sigma0 Loading moe find kernel info page... found kernel info page at 0xb0002000 Regions of list 'regions' [ 40000000, 400000e3] { e4} Root mbi_rt [ 40090000, 4009681b] { 681c} Sigma0 sigma0 [ 40098000, 4009e177] { 6178} Sigma0 sigma0 [ 40140000, 4018b4ab] { 4b4ac} Root moe [ 41000000, 4100e4ff] { e500} Boot bootstrap [ 41100000, 41133fff] { 34000} Root Module [ b0001000, b0001aff] { b00} Kern fiasco [ b0002000, b003afff] { 39000} Kern fiasco API Version: (87) experimental Sigma0 config ip:40090100 sp:00000000 Roottask config ip:4014020c sp:00000000 Starting kernel fiasco at b00012c8 Hello from Startup::stage2 Per_cpu_data_alloc: (orig: 0xf002dd60-0xf002e768) Number of IRQs available at this GIC: 160 GIC: Switching IRQ 32 to secure GIC: Switching IRQ 33 to secure GIC: Switching IRQ 34 to secure GIC: Switching IRQ 35 to secure GIC: Switching IRQ 36 to secure GIC: Switching IRQ 37 to secure GIC: Switching IRQ 38 to secure GIC: Switching IRQ 39 to secure GIC: Switching IRQ 40 to secure GIC: Switching IRQ 41 to secure GIC: Switching IRQ 42 to secure GIC: Switching IRQ 43 to secure GIC: Switching IRQ 44 to secure GIC: Switching IRQ 45 to secure GIC: Switching IRQ 46 to secure GIC: Switching IRQ 47 to secure GIC: Switching IRQ 139 to secure GIC: Switching IRQ 140 to secure GIC: Switching IRQ 80 to secure GIC: Switching IRQ 74 to secure GIC: Switching IRQ 48 to secure GIC: Switching IRQ 49 to secure GIC: Switching IRQ 50 to secure GIC: Switching IRQ 51 to secure GIC: Switching IRQ 52 to secure GIC: Switching IRQ 53 to secure GIC: Switching IRQ 54 to secure GIC: Switching IRQ 55 to secure GIC: Switching IRQ 56 to secure GIC: Switching IRQ 57 to secure GIC: Switching IRQ 58 to secure GIC: Switching IRQ 59 to secure GIC: Switching IRQ 60 to secure GIC: Switching IRQ 61 to secure GIC: Switching IRQ 62 to secure GIC: Switching IRQ 63 to secure GIC: Switching IRQ 64 to secure GIC: Switching IRQ 79 to secure GIC: Switching IRQ 78 to secure GIC: Switching IRQ 9 to secure GIC: Switching IRQ 8 to secure GIC: Switching IRQ 10 to secure GIC: Switching IRQ 11 to secure
We are also interested to use Fiasco.OC for ODROID-X2 without TrustZone, in which case we must configure both IRQ and FIQ, but fails. This the serial output:
Boot with zImage Starting kernel ...
L4 Bootstrapper Build: #69 Thu Jun 4 23:44:25 CDT 2015, 4.8.3 20140303 (prerelease) Scanning up to 2048 MB RAM, starting at offset 32MB Memory size is 2048MB (40000000 - bfffffff) Limiting 'RAM' region [ 40000000, bfffffff] { 80000000} to [ 40000000, bcffffff] { 7d000000} due to 3024 MB address limit RAM: 0000000040000000 - 00000000bcffffff: 2048000kB Total RAM: 2000MB Scanning fiasco Scanning sigma0 Scanning moe Moving up to 5 modules behind 41100000 moving module 02 { 4107d000-410ae65f } -> { 4116e000-4119f65f } [202336] moving module 01 { 41073000-4107c377 } -> { 41164000-4116d377 } [37752] moving module 00 { 41043000-410729df } -> { 41134000-411639df } [195040] moving module 04 { 41029000-410425b3 } -> { 4111a000-411335b3 } [103860] moving module 03 { 4100f000-41028493 } -> { 41100000-41119493 } [103572] Loading fiasco Loading sigma0 Loading moe find kernel info page... found kernel info page at 0x40002000 Regions of list 'regions' [ 40000000, 400000e3] { e4} Root mbi_rt [ 40001000, 40001aff] { b00} Kern fiasco [ 40002000, 4003afff] { 39000} Kern fiasco [ 40090000, 4009681b] { 681c} Sigma0 sigma0 [ 40098000, 4009e177] { 6178} Sigma0 sigma0 [ 40140000, 4018b4ab] { 4b4ac} Root moe [ 41000000, 4100e4ff] { e500} Boot bootstrap [ 41100000, 41133fff] { 34000} Root Module API Version: (87) experimental Sigma0 config ip:40090100 sp:00000000 Roottask config ip:4014020c sp:00000000 Starting kernel fiasco at 400012c8 Hello from Startup::stage2 Per_cpu_data_alloc: (orig: 0xf002d7a0-0xf002e1a8) Number of IRQs available at this GIC: 160 FPU0: Arch: VFPv3(3), Part: VFPv3(30), r: 4, v: 9, i: 41, t: hard, p: dbl/sngl
KERNEL: Warning: No page-fault handler for 0xee202108, error 0x94000848, pc f002660c
Anyone know what is happening with interrupts in Exynos4412 when TrustZone is not used? Anyone have some idea?
Best regards
Hi,
On Thu Jun 04, 2015 at 23:56:15 -0400, Reinier Millo Sánchez wrote:
We have adapted the Proc class to support the IRQ on Fiasco.OC when compiling it in TrustZone Normal Side. Following the principle that in TrustZone the IRQ are used on Normal Side and the FIQ are used in Secure Side, we have only used the IRQ when compile the Fiasco.OC with TrustZone Normal Side. By default Fiasco.OC was using the IRQ and FIQ when compiling with TrustZone Normal Side. This is our patch:
True that on normal side only the FIQ is used, but the FIQ state shall not play a role there, as the normal side must not be able to interfere with the secure side. So it shouldn't matter?
Now when we compile Fiasco.OC and run the Hello example for Odroid-X2 using TrustZone Normal Side, it works fine.
Ok good. What is running on the secure side in this case?
We have noted the when is compiled with TrustZone Secure Side, then only use the FIQ, but when try to run it on Odroid-X2 it fails. This is the serial output:
GIC: Switching IRQ 64 to secure GIC: Switching IRQ 79 to secure GIC: Switching IRQ 78 to secure GIC: Switching IRQ 9 to secure GIC: Switching IRQ 8 to secure GIC: Switching IRQ 10 to secure GIC: Switching IRQ 11 to secure
Did you try to figure out where it is stuck?
We are also interested to use Fiasco.OC for ODROID-X2 without TrustZone, in which case we must configure both IRQ and FIQ, but fails. This the serial output:
Is that the 'std' mode? I.e. there's nothing running on the secure side?
Regions of list 'regions' [ 40000000, 400000e3] { e4} Root mbi_rt [ 40001000, 40001aff] { b00} Kern fiasco [ 40002000, 4003afff] { 39000} Kern fiasco [ 40090000, 4009681b] { 681c} Sigma0 sigma0 [ 40098000, 4009e177] { 6178} Sigma0 sigma0 [ 40140000, 4018b4ab] { 4b4ac} Root moe [ 41000000, 4100e4ff] { e500} Boot bootstrap [ 41100000, 41133fff] { 34000} Root Module API Version: (87) experimental Sigma0 config ip:40090100 sp:00000000 Roottask config ip:4014020c sp:00000000 Starting kernel fiasco at 400012c8 Hello from Startup::stage2 Per_cpu_data_alloc: (orig: 0xf002d7a0-0xf002e1a8) Number of IRQs available at this GIC: 160 FPU0: Arch: VFPv3(3), Part: VFPv3(30), r: 4, v: 9, i: 41, t: hard, p: dbl/sngl
KERNEL: Warning: No page-fault handler for 0xee202108, error 0x94000848, pc f002660c
Anyone know what is happening with interrupts in Exynos4412 when TrustZone is not used? Anyone have some idea?
Adam
Hi Adam
On 06/11/2015 04:39 PM, Adam Lackorzynski wrote:
Hi,
On Thu Jun 04, 2015 at 23:56:15 -0400, Reinier Millo Sánchez wrote:
We have adapted the Proc class to support the IRQ on Fiasco.OC when compiling it in TrustZone Normal Side. Following the principle that in TrustZone the IRQ are used on Normal Side and the FIQ are used in Secure Side, we have only used the IRQ when compile the Fiasco.OC with TrustZone Normal Side. By default Fiasco.OC was using the IRQ and FIQ when compiling with TrustZone Normal Side. This is our patch:
True that on normal side only the FIQ is used, but the FIQ state shall not play a role there, as the normal side must not be able to interfere with the secure side. So it shouldn't matter?
The normal side must not interfere with secure side. The normal side only use the IRQ and secure side the FIQ. By default when not using TrustZone Secure Side, Fiasco.OC try to enable both interrupts, the IRQ and FIQ. We think that there is a problem, when the kernel running on normal side try to write the FIQ bit. In this case we think that the operation is cancelled and the IRQ remains deactivated too. The current implementation of Fiasco.OC make a diference only in TrustZone Secure Side, and only activates the FIQ. We adapted the Proc class to activate only the IRQ when compiling FiascoOC on TrustZone Normal Side with a Secure Monitor Interface. In this case the FIQ bit is not write and the operation isn't cancelled.
Now when we compile Fiasco.OC and run the Hello example for Odroid-X2 using TrustZone Normal Side, it works fine.
Ok good. What is running on the secure side in this case?
In this case we have nothing running on secure side.
We have noted the when is compiled with TrustZone Secure Side, then only use the FIQ, but when try to run it on Odroid-X2 it fails. This is the serial output:
GIC: Switching IRQ 64 to secure GIC: Switching IRQ 79 to secure GIC: Switching IRQ 78 to secure GIC: Switching IRQ 9 to secure GIC: Switching IRQ 8 to secure GIC: Switching IRQ 10 to secure GIC: Switching IRQ 11 to secureDid you try to figure out where it is stuck?
In this case we have only tested the simple configuration. We have seen that to run a example with TrustZone Secure Side, seems to be a little more complex. Now we are trying to test de vmm's example.
We are also interested to use Fiasco.OC for ODROID-X2 without TrustZone, in which case we must configure both IRQ and FIQ, but fails. This the serial output:
Is that the 'std' mode? I.e. there's nothing running on the secure side?
This is standard mode without trustzone. The FiascoOC is configured in standard mode. I have been looking for information about the trustzone, this is a security mechanism provided by hardware. But, there is any way to use the hardware without trustzone, or it must be used always on normal or secure side?
Regions of list 'regions' [ 40000000, 400000e3] { e4} Root mbi_rt [ 40001000, 40001aff] { b00} Kern fiasco [ 40002000, 4003afff] { 39000} Kern fiasco [ 40090000, 4009681b] { 681c} Sigma0 sigma0 [ 40098000, 4009e177] { 6178} Sigma0 sigma0 [ 40140000, 4018b4ab] { 4b4ac} Root moe [ 41000000, 4100e4ff] { e500} Boot bootstrap [ 41100000, 41133fff] { 34000} Root Module API Version: (87) experimental Sigma0 config ip:40090100 sp:00000000 Roottask config ip:4014020c sp:00000000 Starting kernel fiasco at 400012c8 Hello from Startup::stage2 Per_cpu_data_alloc: (orig: 0xf002d7a0-0xf002e1a8) Number of IRQs available at this GIC: 160 FPU0: Arch: VFPv3(3), Part: VFPv3(30), r: 4, v: 9, i: 41, t: hard, p: dbl/sngl KERNEL: Warning: No page-fault handler for 0xee202108, error 0x94000848, pc f002660cAnyone know what is happening with interrupts in Exynos4412 when TrustZone is not used? Anyone have some idea?
Adam
Best regards
On Thu Jun 11, 2015 at 17:13:27 -0400, Reinier Millo Sánchez wrote:
On 06/11/2015 04:39 PM, Adam Lackorzynski wrote:
Hi,
On Thu Jun 04, 2015 at 23:56:15 -0400, Reinier Millo Sánchez wrote:
We have adapted the Proc class to support the IRQ on Fiasco.OC when compiling it in TrustZone Normal Side. Following the principle that in TrustZone the IRQ are used on Normal Side and the FIQ are used in Secure Side, we have only used the IRQ when compile the Fiasco.OC with TrustZone Normal Side. By default Fiasco.OC was using the IRQ and FIQ when compiling with TrustZone Normal Side. This is our patch:
True that on normal side only the FIQ is used, but the FIQ state shall not play a role there, as the normal side must not be able to interfere with the secure side. So it shouldn't matter?
The normal side must not interfere with secure side. The normal side only use the IRQ and secure side the FIQ. By default when not using TrustZone Secure Side, Fiasco.OC try to enable both interrupts, the IRQ and FIQ. We think that there is a problem, when the kernel running on normal side try to write the FIQ bit. In this case we think that the operation is cancelled and the IRQ remains deactivated too.
So any idea why this is happening? I looked at the manual and it clearly says that CPSR.F does not play any role on the normale side, given that SCR.FW=0 which I guess must be the case. What's running on the secure side in this case?
The current implementation of Fiasco.OC make a diference only in TrustZone Secure Side, and only activates the FIQ. We adapted the Proc class to activate only the IRQ when compiling FiascoOC on TrustZone Normal Side with a Secure Monitor Interface. In this case the FIQ bit is not write and the operation isn't cancelled.
Now when we compile Fiasco.OC and run the Hello example for Odroid-X2 using TrustZone Normal Side, it works fine.
Ok good. What is running on the secure side in this case?
In this case we have nothing running on secure side.
We have noted the when is compiled with TrustZone Secure Side, then only use the FIQ, but when try to run it on Odroid-X2 it fails. This is the serial output:
GIC: Switching IRQ 64 to secure GIC: Switching IRQ 79 to secure GIC: Switching IRQ 78 to secure GIC: Switching IRQ 9 to secure GIC: Switching IRQ 8 to secure GIC: Switching IRQ 10 to secure GIC: Switching IRQ 11 to secure
Did you try to figure out where it is stuck?
In this case we have only tested the simple configuration. We have seen that to run a example with TrustZone Secure Side, seems to be a little more complex. Now we are trying to test de vmm's example.
We are also interested to use Fiasco.OC for ODROID-X2 without TrustZone, in which case we must configure both IRQ and FIQ, but fails. This the serial output:
Is that the 'std' mode? I.e. there's nothing running on the secure side?
This is standard mode without trustzone. The FiascoOC is configured in standard mode. I have been looking for information about the trustzone, this is a security mechanism provided by hardware. But, there is any way to use the hardware without trustzone, or it must be used always on normal or secure side?
If the security extension is there but you do not want to use it, just run as it would not be there. In this case you'd be running on the secure side. If you do not launch a normal side you do not need to care about the TZ specifics.
Adam
l4-hackers@os.inf.tu-dresden.de
-
Adam Lackorzynski -
Reinier Millo Sánchez