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. > 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. 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 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. 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
