Hi all,
I am using 64-bit android on Juno r1 board, and get confused by the OS Lock when playing with ETM.
The armv8 manual tells that the OS lock is used to restrict the external debugger, and can be unlocked by writing 0 to OSLAR_EL1 register. Moreover, the OSLAR_EL1 register is supposed to be mapped to external debug register OSLAR_EL1, whose offset is 0x300 in the memory-mapped interface. In the ETM, we also have a pair of OS lock registers locates at offset 0x300/0x304. Since i am confused by these OS Locks, i did some experiments like the following:
Experiment 1:
a) Unlock the OS Lock by using "msr OSLAR_EL1, 0"
b) Read the OS Lock status by using "mrs X0, OSLSR_EL1"
c) Read the ETM OS Lock status by the memory-mapped interface
d) Unlock the ETM OS Lock by the memory-mapped interface and repeat c)
In b), we can find that the OS Lock is unlocked, however, the result in c) shows that the OS Lock in ETM is not unlocked. If we do d), then the OS Lock in ETM is unlocked. So, does that mean the OS Lock and ETM OS Lock are completely different locks?
Experiment 2:
a) Unlock the ETM OS Lock by the memory-mapped interface
b) Read the ETM OS Lock status by the memory-mapped interface
c) Make the GPU Mali access the ETM OS Lock status
In a) and b), we can find that the ETM OS Lock is unlocked as expected. In c), i made some tricks in the open source kernel-level mali driver and created an OpenCL buffer on the physic address of ETM. Then, I tried to access the ETM OS Lock. However, it surprised me that the ETM OS Lock status reading by Mali shows that the ETM OS Lock is locked. How could this be? Does that mean the OS Lock has multiple copies while reading from different devices?
Experiment 3:
a) Use Mali to unlock the ETM OS Lock
b) Use Mali to access the ETM OS Lock status
Surprise again. Even I use Mali to unlock the ETM OS Lock, the ETM OS Lock status still shows that the ETM OS Lock is locked. So, does that mean there are some restrictions on access to the ETM OS Lock?
Experiment 4:
a) Use Mali to unlock the ETM Software Lock (at offset 0xfb0)
b) Use Mali to read the ETM Software Lock status (at offset 0xfb4)
c) Use CPU to read the ETM Software Lock status
In this experiment, everything works as expected. In both step b) and c), the results show that the Software Lock is unlocked. I suppose that this means the Mali is at least capable of accessing the ETM registers, but why not the OS Lock?
Thanks in advance for any suggestions and discussions!
Best Regards,
Zhenyu
The debug OS Lock and ETM OS Lock are independent things, so I can at least confirm that.I don't know enough of the Juno R1 details to comment on the other parts of your question.
Hello Michael,
Nice to see you! Thanks so much for your confirmation. By further experiments, I found that the OS Lock Status Register in ETM did not reflect the real status of the OS lock sometimes, and it is not related to the GPU Mali at all.
Basically, I created a simple loadable kernel module. In the kernel module, I use ioremap to access the ETM registers. First, I check the OS Lock status and then unlock it. Finally, read the lock status again.
If I load the kernel module, the two read to the lock status show that the lock is locked and unlocked, respectively. This matches our expectation. The interesting thing is that the first read to the lock status shows that the lock is locked again if I load the same kernel module for the second time. However, since I already unlocked it in the first load, I don't really know how it got locked again.
By further check, I confirmed that the OS lock is not actually locked when I load the kernel module for the second time since I was able to write the other ETM configuration registers. So, that means the first read to the lock status while loading the kernel module for the second time did not get the correct status of the OS lock. Do you happen to know the reason?
Thanks again for your help!!
View all questions in Arm Development Platforms forum