On 2024/1/2 03:20, Antonio Borneo wrote:
On Wed, Nov 29, 2023 at 7:05 PM Randy Li <ay...@soulik.info> wrote:
Hello
Hello Randy,
sorry for replying late to your email.
I am so for late as well. I was moving when I received your email.
The TEE OS and trusted applications have been widely used in many ARM
platforms. The JTAG debugger would not longer only serve the Rich
Operating System Execution Environment kernel (likes Linux kernel) for
the problem that could hang the CPU.
Well, KGDB is much easier to use than JTAG to debug Linux
JTAG is preferable only to debug the very early stage of Linux boot.
I doubt about that dealing with dead locking or all CPU cores are
busying case.
Serial driver often failed to response.
But JTAG is key for debugging TEE.
The most of TEE OS don't have a scheduler, which means it could only be
executed when the REE trigger it (SMC instruction in ARM), that means
those tricks for linux kernel won't work for TEE OS.
I know how TEE works with Linux, but I don't understand your sentence
"... those tricks for linux ...". Which "tricks"?
I forgot what I try to say here.
I think a gdb target can't have two images for the base address. I just
wondering whether the hardware breakpoint would know which environemt it
should applied to?
Instead, GDB can handle multiple images! It's just a matter of OpenOCD
passing the right info to GDB!
I've started by analyzing how to manage the dynamic switch between 32
and 64 bit in Cortex-A35 with OpenOCD + GDB.
We can have Linux kernel 64 bit and user app 32 bit, or TEE 64 bit and
Linux kernel 32 bits.
aarch64-gdb reads the status (32 or 64 bits) the first time it
connects to OpenOCD and then "expects" the status to not change
anymore.
If the status changes, GDB gets mad and you need to quit from GDB and
re-attach. Broken debug.
I have found that this can be solved by assigning a different GDB
"task" for the two states.
OpenOCD should present to GDB one task 32 bits and one 64 bits.
aarch64-gdb accepts two tasks, one 32 and one 64 bits and can switch
between them.
Cool, but today's OpenOCD does not handle tasks!
The other problem is with breakpoints. We need to handle different
breakpoints for each "task"
To solve this, I thought to further extend the scope above, and have a
GDB "task" for each aarch64 EL and for secure/non-secure mode.
I expect one task in EL3-secure, N tasks for each EL2 state (S and
NS), M tasks for EL1 (OS virtualization and TEE), L tasks for EL0 (NS
for OS apps, S for TEE apps).
Linux puts the PID of the user application in the MMU context ASID, so
OpenOCD should associate a task EL0-NS for each Linux PID.
To be clarified how to associate the other tasks to the respective
context of the CPU.
TEE would be the task associated to EL1-S,
OpenOCD can already associate breakpoints to context, so it should be
easy once tasks are in place.
The symbols would be handled by GDB, as it is already able to load
symbols per task. It would probably need some help from OpenOCD to
associate tasks with ELF names, TBD.
Going back to the subject of this email, I think it would be better to
have a single GDB port where a single GDB will connect and handle all
the execution, switching from one task to another depending on the CPU
context.
I didn't think GDB could handle multiple tasks before. I should read it
then reply.
Apart from some high level investigation, I have not started any coding yet.
It's nice to get someone else interested in the topic.
Do you have feedback, concern, ideas, proposals on what I have written above?
Regards,
Antonio
If this approach is proper, I would try to develop this feature in the
future.
Sincerely
Randy
P.S. I sent another email to discuss those problems when I am trying to
debug kernel with JTAG.
https://lore.kernel.org/lkml/aed87c60-d802-45d0-a430-52fb9e7be...@synaptics.com/T/
