2020년 9월 14일 (월) 10:18 기준 최신판

최근 복잡한 SoC 구조에 따라 Target 디버깅 설정이 매우 어렵고 번거롭워 지고 있는 실정으로 iTSP는 TRACE32 Debugger에 대한 기본 지식이 없는 초기 사용자라 할지라도 쉽게 설정하여 사용할 수 있도록 도와주는 TRACE32 Script Platform 입니다. 기본적으로 GUI로 구성되어 쉽게 설정이 가능합니다.

또한 iTSP를 RAM dump 분석용으로 사용할 경우Command Line구동을 지원하여 사용 편의성을 제공하며 다음처럼 여러가지 이점을 제공할 수 있습니다.

1) Process Management Tool과의 연동을 통한 자동화가 가능합니다.

2) 각 개발자가 iTSP 사용방법에 익숙하지 않더라도 정형화된 Project인 경우 Make Utility등을 이용하여 단순화 할 수 있어 사용 편의성을 제공해 줍니다.

3) GUI 방식은 물론 Command Line방식을 자유롭게 사용할 수 있습니다.

사용 및 설정 방법은 [2. How to setup]을 참조하시기 바랍니다.

또한 필요할 경우 요청하시면 해당 SoC를 추가하고 있으니 참조하시기 바랍니다. 현재는 주로 Linux/ Android/QnX/Nucleus/SLP/L4/WinCE6/WinCE7/WP8 등의 OS에 대한 iTSP를 제공하고 있습니다.

iTSP 지원 환경

iTSP사용을 위한 TRACE32 Version 정보입니다. iTSP는 반드시 License Maintenace를 보유한 상태에서 사용이 가능합니다. 상세한 사항은 아래 표를 참고하시기 바랍니다.

iTSP 사용목적	Supported TRACE32	License 여부
Real Target Mode디버깅	2012. 09 이상 버전	License Maintenance 유
GUI based RAM dump Analysis in Simulation Mode	2016. 02 이상 버전	License Maintenance 유 (유지보수 기간 내 장비 연결 필수)
Command Line based RAM dump in Simulation Mode	2016. 03 이상 버전	License Maintenance 유 (유지보수 기간 내 장비 연결 필수)

l 참고

TRACE32 command line 입력 개수는 2016.05 버전까지는 18개 2016년 06월 버전이후는 28개까지 지원하며 초과 시 사용 방법은 [2.7 OS command Line을 이용한 iTSP 사용]을 참조하시기 바랍니다.

How to setup

iTSP를 이용한 Debug Setup에 대해 알아 봅니다.

iTSP 설치와 TRACE32 Update

iTSP와 TRACE32 Update는 TRACE32 HomePage(www.trace32.com)에서 가능합니다.

iTSP 설치하기

1) 다운로드 받고자 하는 SoC 제조사를 선택합니다.

2) 다운로드 받고자 하는 SoC를 선택합니다.

3) 선택한 iTSP를 다운(압축된 iTSP 파일 이름은 “iTSP_<SoC명>.zip”) 받고 C:\T32 폴더에 복사합니다.

4) 만약을 위해 기존 iTSP를 Backup하시고 복사한 iTSP 파일을 압축해제 합니다.

폴더 경로를 맞추기 위해 “여기에 압축풀기”를 선택합니다. 즉 iTSP 폴더 구조는 C:\T32\iTSP 입니다.

5) 기존에 설치되어 있는 iTSP에 중복된 파일이 있다면 “덮어쓰기”를 실행합니다.

6) 아래 그림은 iTSP설치 폴더 구조를 보이고 있으며 설치 SoC 폴더에 해당 SoC 이름이 있음을 확인할 수 있습니다.

TRACE32 Update

1) http://trace32.com/wiki/index.php/TRACE32_Update Web Page를 여시고 원하는 SoC와 Software Version을 찾아 다운 받습니다.

- 날짜별 Update 버전을 확인한 후 보유한 License Mainternace 기간 내의 SW 다운 받습니다.

2) Unzip 후 압축 해제된 파일들을 TRACE32가 설치된 루트 폴더(Ex. C:\T32\)에 덮어 씌웁니다.

아래 그림은 Unzip했들 때 파일들이며 다음 그림은 TRACE32가 설치된 루트의 폴더 구조입니다.

Starting TRACE32 PowerView

iTSP 설치가 완료되면 아래 그림과 같이 설치 폴더에 iTSP 실행 Link들이 만드어져 있습니다. iTSP는 Real Target과 연결하여 디버깅하는 Target Mode와 RAM dump 데이터 분석과 같은 목적으로 사용하는 Simulation Mode가 있습니다. Target Mode 실행 시 ARMv8 Core(CortexA5x series) Debugging의 경우는 “TRACE32 ICD Target ARM 64.lnk” 파일을, ARMv7(CortexA15x/Ax/Rx/Mx) Core의 경우 “TRACE32 ICD Target ARM.lnk” 파일을 더블클릭하여 TRACE32 PowerView를 실행합니다.

실행하게 되면 아래 그림과 같이 연결할 SoC용 iTSP 선택 Dialog가 열리게 되는데 원하는 Target SoC와 OS를 선택한 후 Start 버튼을 클릭합니다.

그러면 해당 SoC와 OS에 맞는 Target 메뉴가 생성되며 추가로 두개의 아이콘도 생성됩니다. 다음은 디버깅할 Target의 Boot Loader나 OS에 대한 iTSP설정 후 디버징 작업을 진행하면 되겠습니다.

iTSP Setup for u-boot debugging & Linux Kernel & Android

u-boot 나 Kernel debugging을 위한 iTSP 환경 Setup에 대하여 알아 봅니다. 아래 그림과 같이 Target Setting 아이콘을 클릭하면 iTSP Setup 윈도우가 열립니다.

프로젝트마다 사용될 iTSP 프로젝트 이름, 각종 심볼 경로 등 디버깅에 필요한 필수 정보들을 설정해 줍니다. 설정이 필요한 항목은 다음과 같습니다.

Project

5개까지 프로젝트 별로 iTSP 설정을 저장 가능

#Bootloader

- Symbol

부트로더 심볼(ELF) 파일 선택

#Linux Kernel

- Symbol

리눅스 커널 심볼 파일인 vmlinux ELF 파일 선택

- SourcePath

start_kernel (kernel의 시작 함수나 break하고자 하는 함수 입력)

Source code 경로 선택 Kernel Symbol 정보인 vmlinux 파일을 선택, Kernel 디버깅 정보 입력

- Address

Kernel Start address (Physical)

Kernel Virtual address와 mapping되는 physical address를 적어줌

- KASLR

KASLR (Kernel Address Space Layout Randomization) 사용여부에 따라 ON/OFF 옵션 적용

#Android

Symbol

Directory

Android 빌드 시 생성되는 out 폴더 내에 있는 Anroid ELF 파일들을 모아 놓은 symbols라는 폴더의 Network 경로를 지정

ex) <Android Root>\out\target\product\smdkc210\symbols

#Reset Mode

Debugger - JTAG 으로 리셋(nSRST)을 제어

User - 사용자 타깃을 껐다켜서 리셋 제어, 사용자 모드일 경우 JTAG으로 리셋을 할 수 없는 환경이거나 JTAG 으로 리셋을 하면 정상 모드로 동작하지 않을 경우 설정

#Secure JTAG

Advanced 클릭하여 Secure JTAG 옵션 적용(Default OFF)

Secure JTAG 이 적용되어 있는 타깃 환경일 경우 Secure JTAG Enable 이 되어 있다는 설정과 disable 처리하는 cmm 을 찾아 적용

Symbol Path

위의 Android Symbol Directory에 설정된 폴더에 위치하지 않은 image를 디버깅 하고자 한다면 해당 ELF image가 있는 폴더 위치를 추가로 지정하기 위한 설정

모든 설정이 완료된 후 설정을 Save하고 Target Power를 OFF >> ON 한 다음 아래 그림과 같이

Kernel-Debug 버튼을 클릭하게 되면

Target은 booting 후 Start_Kernel()까지 실행하고 멈추게 되는데 여기까지 동작이 확인 되면 모든 설정이 정상적으로 완료된 것이라고 생각해도 되겠습니다.

마지막으로 Kernel Address Range의 정확한 확인을 위해 Target를 일정시간(3~5초) 실행시켜 멈춘 후 TRACE32 Command line에서

MMU.List.PageTable 0xC0000000

or

MMU.List.KernelPageTable

입력하여 실행하면 정확한 Kernel Physical Range를 확인할 수 있습니다. MMU Table에서 리니어하게 배치된 커널 물리 영역을 얻어 냅니다.

<32bit Kernel에서 Kernel MMU Table List>

위 예제의 경우 0x40000000—0x6F7FFFFF가 됩니다.

만약 ARMv8의 경우라면

MMU.List.PageTable 0xFFFFFFC000000000

를 실행하면

아래와 같이 64bit Address space를 갖는 형태로 현재 Mapping된 MMU Table List를 보여줍니다.

<64bit Kernel에서 Kernel MMU Table List>

참고로 Target의 Kernel Binary Image와 로드된 vmlinux 파일의 일치 여부를 확인하기 위해 TRACE32 Command Line에서

TASK.TEST

명령을 실행하면 정확한 Linux text banner와 현재 사용된 Linux 정보들을 확인할 수 있습니다. 만약

<32bit Kernel에서 TASK.TEST 결과>

Binary Image와 vmlinux 파일이 같은 빌드시 생성된 것이 아니(다른 경우)라면 banner의 String이 일부 보이지 않거나 모두 보이지 않는 현상을 볼 수 있습니다.

<64bit Kernel에서 TASK.TEST 결과>

위와 같이 64bit Linux Kernel이라면 “ptr size”와 “MMU format”이 64bit 인것을 확인할 수 있습니다.

u-boot Debugging

앞의 iTSP 설정이 완료되고 난 후 u-boot debugging을 위해서는 Target 메뉴 >> boot-Debug 항목을 클릭하게 되면 u-boot의 맨처음 실행되는 C-함수 실행 중 멈추게 됩니다.

만약 JTAG debugging을 위해 JTAG Port에 “System Reset” 신호가 연결되어 있지 않은 경우나, JTAG Port의 “System Reset”에 연결된 신호에 의해 재부팅 제어가 불가한 경우는 Target을 재 부팅시킬 수 없기 때문에 Power를 Off 한 후 ON 하고 “boot-Debug” 항목을 클릭하도록 합니다.

Kernel Debugging

Kernel debugging시 경우에 따라

1) start_kernel() 코드 실행부터 디버깅 하기

2) smp_cpus_done() 코드 실행부터 debugging 하기

를 원하는 경우가 있을 것입니다. SMP 환경에서 모든 core들이 깨어난 뒤 Kernel 코드실행을 보고자 한다면 smp_cpus_done() 코드 실행부터 debugging 하기를 따라하시면 되겠습니다.

start_kernel() 함수부터 debugging 하기

앞의 iTSP 설정이 완료되고 난 후 Target 메뉴 >> Kernel-Debug 항목을 클릭하게 되면 Kernel의 start_kernel()함수 실행 시작에서 멈추게 됩니다.

만약 debugging을 위한 JTAG Port에 “System Reset”이 연결되어 있지 않은 경우나 JTAG Port의 “System Reset” 핀에 연결된 신호에 의해 재부팅 제어가 불가능한 경우는 Target을 재 부팅시킬 수 없기 때문에 Power를 Off 한 후 ON 한 다음 바로 Kernel-Debug 항목을 클릭하도록 합니다.

smp_cpus_done() 함수부터 debugging 하기

앞의 iTSP 설정이 완료되고 난 후 Target 메뉴 >> Kernel SMP-Debug 항목을 클릭하게 되면 Kernel의 smp_cpus_done()함수 실행 시작에서 멈추게 됩니다.

만약 debugging을 위한 JTAG Port에 “System Reset”이 연결되어 있지 않은 경우나 JTAG Port의 “System Reset” 핀에 연결된 신호에 의해 재부팅 제어가 불가능한 경우는 TRACE32가 Target을 재 부팅시킬 수 없기 때문에 Power를 Off 한 다음 ON 하고 바로 Kernel SMP-Debug 항목을 클릭하도록 합니다.

부팅후 Kernel 동작 중 중간에 연결하여 디버깅하기

앞의 iTSP 설정이 완료되고 난 후 Target 메뉴 >> Kernel-Attach 나 Kernel SMP(Attach)-Debug 항목을 클릭하게 되면 Target Reset을 실행하지 않고 Target 동작 중 중간에 연결하여 디버깅 모드로 진입하게 됩니다.

Kernel-Attach 항목은 SMP core 중 main core 하나만 연결하게 되며 Kernel SMP(Attach)-Debug는 SMP로 구성된 모든 core를 연결하여 디버깅 상태로 전환합니다.

특정 Process/Module/Library Code Debugging

본장에서는 Linux Kernel이 동작하는 Target 위에서 특정 code에 BreakPoint를 설정하여 멈춰 디버깅하는 방법을 학습합니다.

특정 process의 Main 함수에 BreakPoint를 설정하여 멈추기

특정 process의 Main함수는 Process가 만들어지고 한번만 실행될 것입니다. 따라서 Main 함수에서 멈추도록 하기 위해서는 해당 Process가 만들어 지는 시점 후 Process Symbol을 로드하고 Main함수에 BreakPoint를 설정하여 실행하면 멈추게 될 것입니다. 이 과정은 상당히 복잡한 과정을 거쳐야 하지만 TRACE32의 Linux Awareness를 사용하게 되면 쉽게 가능합니다.

1) 해당 Process가 실행되기 전 Target을 Stop시킨 후 Linux 메뉴 >> Process Debugging >> Debug Process on Main... 을 클릭합니다.

2) 1)의 과정을 실행하게 되면 아래 디버깅 Process이름 입력 윈도우가 열립니다. 디버깅을 원하는 Process 이름 입력 후 OK 버튼을 클릭합니다.

3) 이후 해당 Process가 실행되면 자동으로 해당 Process의 Main함수에 BreakPoint를 설정해 멈추도록 합니다. 다음 그림은 Main함수에서 멈춘 상태를 보여주고 있으며 TASK.Process윈도우에 보면 현재 Process가 입력했던 Process인 것을 확인할 수 있습니다.

특정 process의 함수에 BreakPoint 설정하기

Linux Platform에서는 대단히 많은 process들이 로드되어 실행되고 있습니다. 따라서 이 Process들에 대한 모든 symbol을 로드 해놓은 상태에서 디버깅하는 것은 장점보다는 단점들이 더 많은 상태가 될 것입니다.

TRACE32는 기본적으로 필요에 따라 symbol을 로드해 사용하는 정책을 가지며 다음과 같은 순서로 원하는 함수에 BreakPoint를 설정하시기 바랍니다.

1) 다음 그림과 같이 TASK.Process윈도우를 통해 해당 Process symbol을 로드합니다.

2) 1)을 실행하고 Symbol 윈도우()를 열고 Up 버튼()을 클릭해 상위로 올라가면 현재 어떤 ELF symbol 들이 로드되었는지 확인할 수 있습니다. 다음은 아래 symbol 윈도우에서 해당 ELF(netd>> )를 클릭해 들어가거나(해당 ELF에 대한 symbol들만 보임), 버튼을 클릭해 들어간 후 다시 한번 클릭하면 로드된 모든 ELF의 symbol들을 보여줍니다.

3) 설정하고자 하는 함수를 찾아 더블클릭하여 Data.List윈도우를 열고 원하는 소스라인에 더블클릭하여 BreakPoint를 설정합니다.

4) 해당 Process에서만 멈추고자 한다면 아래 그림과 같이 Break.List 창에서 우클릭후 Change를 클릭하

여 TASK 필드를 해당 Process로 설정해 줍니다.

특정 process 내의 Library 함수에 BreakPoint 설정하기

우리는 필요에 따라 특정 Process에서 로드하여 사용하는 특정 Library의 함수를 디버깅하고자 하는 경우가 있습니다. 다음과 같은 순서로 우리는 쉽게 해당 함수에서 BreakPoint를 설정하여 디버깅 할 수 있습니다.

1) 특정 Process의 Library Symbol을 로드하기 위해 Linux메뉴 >> Display Process... 항목을 클릭(또는 Command line에서 TASK.Process 입력)하여 디버깅하고자 하는 Process를 찾고 더블클릭하여 해당 Process 정보를 엽니다.

2) 여러 정보 중 Code File 항목은 해당 Process가 사용하는 Resource들에 대한 정보를 담고 있는 부분으로 디버깅하고자 하는 Library의 파일 이름을 찾습니다. 해당 파일을 찾은 후 우클릭하고 PopUp 메뉴의 Load Library Symbols 항목을 클릭하면 자동으로 해당 Library Symbol을 로드하게 됩니다. 만약 해당 .so 파일을 찾지 못한 경우 File Browse 윈도우가 띄우게 되는데 해당 .so 파일을 찾아 지정하면 되겠습니다.

3) 2)를 실행하고 Symbol 윈도우()를 열고 Up 버튼()을 클릭해 상위로 올라가면 현재 어떤 ELF symbol 들이 로드되었는지 확인할 수 있습니다. 다음은 아래 symbol 윈도우에서 해당 ELF(netd >> )를 클릭해 들어가거나(해당 ELF에 대한 symbol들만 보임), 버튼을 클릭해 들어간 후 다시 한번 클릭하면 로드된 모든 ELF의 symbol들을 보여줍니다.

4) Symbol 중 원하는 함수를 찾아 BreakPoint를 설정합니다. 해당 함수를 찾았다면 더블클릭하여그 함수의 Data.List 윈도우를 열고 원하는 소스라인에 더블 클릭하여 BreakPoint를 설정합니다. 설정이 완료 되었으며 Target을 Run하면 해당 함수가 실행될 경우 멈추게 될 것입니다.

5) 만약 해당 Process에서만 멈추고자 한다면 아래 그림과 같이 Break.List 창에서 우클릭한 후 Change를 클릭하고 TASK 필드에 해당 Process를 설정해 줍니다.

특정 kernel module 이 loading 될 때 Init 함수에 BreakPoint 설정하여 멈추기

Module이 로딩될 때 symbol을 올린 후 Init 함수에 BreakPoint를 설정하여 멈추도록 하는 개념을 갖습니다. 이 과정을 수동으로 하는 것은 생각보다 상당히 복잡한 과정을 거쳐야 합니다. 하지만 TRACE32의 Linux Awareness를 사용하게 되면 쉽게 가능합니다.

1) 우선 모듈이 로딩되기전 Linux 메뉴 >> Module Debugging >> Debug Module on Init... 항목을 클릭합니다. 클릭하면 우측과 같은 디버깅할 모듈이름 입력 윈도우가 열립니다. 모듈이름을 입력하고 Ok 버튼을 클릭하면 Module이 로딩 될때까지 waiting 합니다.

2) 사용자에 의해 Module이 로딩된 후 TRACE32는 로딩된 것을 인식하고 해당 Module의 symbol을 자동으로 로드하게 될 것이며 모듈의 Init함수에 BreakPoint를 설정하고 다시 Run을 시키게 됩니다.

다음 그림은 위의 과정을 통해 해당 모듈의 Init 함수에서 멈춘 상태를 보여주고 있습니다.

Linux Kernel Module(LKM)이 적용된 커널 버젼에서 모듈(.ko)파일 로딩하기

Linux kernel 5.4이상의 경우 Built in Driver 대부분 Module 형태로 구현이 됩니다. 이 경우 iTSP셋팅 + Linux Awareness Autoloader를 사용하여 쉽게 로딩 할 수 있습니다.

Module(.ko) 선택 로딩을 하기 위해서는 "sYmbol.AutoLOAD.List"의 Touch를 선택하면 됩니다.

List에 표시된 모든 symbol을 로딩하기 위해서는 “sYmbol.AutoLOAD.TOUCH” 명령을 사용하시면 됩니다.

user_fault/kernel_fault/panic 등 의도하지 않은 exception 발생 대비 BreakPoint 설정

Linux Kernel은 Data Abort/Prepatch Abort/Undefined Exception을 임의의 용도로 사용하고 있습니다. 따라서 잘못된 코드 동작에 의한 excetption 발생에서 excetpion을 구분하여야 하며 이는 Kernel에서 제공하고 있습니다. 만약 의도하지 않은 Excetption 발생할 경우 특정 코드를 타도록 되어 있습니다.

따라서 의도하지 않은 Exception 발생 시 타는 특정 코드가 Debugging Point가 될 것이며 우리는 이곳에 BreakPoint를 설정하여 Trigger시 이 코드를 보는 작업을 하게 됩니다.

Linux의 경우 TRACE32에서는 좀더 간편한 Exception Debugging을 지원하기 위해 SegV.cmm이라는 파일을 제공하고 있는데 바로 의도하지 않은 Exception발생시 실행되는 코드에 자동으로 BreakPoint를 설정해 주고 BreakPoint Trigger시 자동으로 Exception위치를 추적해 주는 기능을 담당해 줍니다.

ARMv8을 Debugging 시 본기능을 사용하기 위해서는 반드시 iTSP version 3.8.5이상을 추천합니다.

1) Exception 발생이 확인되었다면 system을 다시 시작하고 해당 Exception발생 전 아래 그림과 같이 SegV.cmm을 실행해 주는 ”Segment Violation” 버튼을 클릭하여 의도하지 않은 Exception발생시 실행되는 코드에 BreakPoint를 설정합니다.

SegV.cmm을 실행하면 die()/__do_user_fault()/__do_kernel_fault()/panic() 함수에 BreakPoint를 자동으로 설정하게 됩니다.

2) 다음은 Target을 실행시켜 Exception을 재현합니다. Exception이 재현되면 아래와 같이 의도하지 않은 Exeption발생 시 실행되는 Kernel 함수에서 멈추게 됩니다.

3) 다음으로는 Exception이 발생한 위치를 확인하기 위해 다시 ”Segment Violation” 버튼()을 클릭합니다. 그러면 아래 그림과 같이 Exeption이 발생했던 위치를 추적해 직전 상태를 보여 줍니다. 아래 원인을 살펴보면 Exception의 원인은 ldr r0,[r12]이며 R12가 가리키는 번지인 0번지(MMU에 Mapping되지 않은)로부터 데이터를 읽어 R0에 옮기는 작업을 진행하다 발생한 것임을 알 수 있습니다.

다음은 ARMv8용linux Kernel64에서의 해당 기능을 사용한 예입니다. 어떤 원인에 의해 “Kernel Fault”에서 멈춘 것을 확인할 수 있습니다. 이 상태에서 다시 ”Segment Violation” 버튼()을 클릭하시면

다음 그림과 같이 Fault를 발생시킨 코드 위치를 추적하여 찾아 오게 됩니다.

OS command Line을 이용한 iTSP 사용

TRACE32 PowerView SW 및 iTSP 구동을 위한 Command Line 명령 사용은 RAM dump Simulation Mode만 지원 가능합니다.

Widows의 경우

>> t32marm64.exe -c config-sim.t32, startup.cmm %SYS_PATH% 10 1 . . [--iTSP설정인자] ; 32bit ARM debugger

>> t32marm.exe -c config-sim.t32, startup.cmm %SYS_PATH% 10 1 . . [--iTSP설정인자] ; 64bit ARM debugger

Linux의 경우

>> t32marm64 -c config-sim.t32, startup.cmm %SYS_PATH% 10 1 . . [--iTSP설정인자] ; 32bit ARM debugger

>> t32marm -c config-sim.t32, startup.cmm %SYS_PATH% 10 1 . . [--iTSP설정인자] ; 64bit ARM debugger

형식을 갖습니다. 실행파일의 위치는 설치폴더\bin\사용OS에 있으며 환경변수에 path를 설정해 주시거나 실행 시 full path로 실행합니다.

[iTSP설정인자]

설정인자는 기존 GUI 형식으로 설정하던 인자 들을 Command Line방식으로 설정할 수 있도록 하는 지시자(directives)입니다. Command Line 구동을 위한 설정인자는 [--설정구분자=설정값] 형식을 가지며 여러 개 나열 시 인자 간 Space Bar로 구분 합니다. 주의할 점은

1) 설정구분자의 경우 소문자이며

2) 설정구분자와 ‘=’, ‘=’과 설정값은 반드시 붙여쓰기하여야 합니다.

3) 세팅된 설정인자 값들(path 명 등) 사이에 Space Bar가 18개(~2016.05버전) 또는 28개(2016.06~)를 넘는 경우 Command Line Error 가 발생하며 이 경우 설정인자들 전체를 “ ”로 씌워줍니다.

사용예제는 iTSP폴더의 RAMdumpCMDlineExARM.bat와 RAMdumpCMDlineExARM64.bat 파일을 참조하시기 바랍니다.

--soc

타깃의 SoC 이름을 전달하며 기본 값은 “ ”입니다. Ex) --soc=Exynos42xx

--os

타깃의 OS 이름을 전달하며 기본 값은 “ “입니다. Android와 Linux가 가능합니다. Ex) --os=Android

--regcmm

RAM dump시 저장된 core register 값 복원을 담당하는 cmm 파일을 지정하며 기본 값은 “ ”입니다.

Ex) --regcmm=D:\T32\Linux\ISTOR ramdump SMP8\reg.cmm

--syscmm

RAM dump시 저장된 MMU관련 설정 값들을 복원하는 cmm 파일을 지정하며 기본 값은 “ “입니다.

Ex) --syscmm=D:\T32\Linux\ISTOR ramdump SMP8\mmu.cmm

--kernel-bus-length

Kernel위 bitwidth를 설정하는 구분자이며 기본 값은 64bit입니다. 32bit과 64bit이 가능합니다.

Ex) --kernel-bus-length=32bit

--ramdumpdir

RAM dump폴더를 지정하는 구분자이며 기본 값은 “ “입니다.

Ex) --ramdumpdir=D:\T32\Linux\ISTOR ramdump SMP8

--kernel-symbol

vmlinux ELF 파일을 지정하는 구분자이며 기본 값은 “ “입니다.

Ex) --kernel-symbol=D:\T32\Linux\ISTOR ramdump SMP8\vmlinux

--android-symboldir

Android default symbol path를 지정하는 구분자이며 기본 값은 “ “입니다.

Ex) --android-symboldir=E:\Android Image\PV310EDU_JB\android\out\target\product\origen\symbols

--phy-kernel-startaddr

Kernel의 Physical Start Address를 지정하는 구분자이며 기본값은 0x80000000입니다.

Ex) -phy-kernel-startaddr=0x40000000

--phy-kernel-endaddr

--phy-kernel-endaddr=0x6FEFFFFF

Kernel의 Physical End Address를 지정하는 구분자이며 기본값은 0x8FFFFFFF입니다.

--kaslr

KASLR (Kernel Address Space Layout Randomization) 사용여부에 따라 ON/OFF 옵션 적용합니다.

--add-sym-paths

Android default symbol path외에 다른 위치에 추가로 symbol 파일들이 있는 경우 추가 Path를 지정하기 위한 구분자이며 기본 값은 “ ”입니다. 여러 개의 path를 지정할 경우 “;”로 구분합니다.

Ex) --add-sym-paths=E:\Android Image\PV310EDU;E:\Android Image; E:\additionalPath

만약 설정인자들 사이에 TRACE32 PowerView의 실행 파일이 받을 수 있는 인자 개수(18개(~2016.05버전) 또는 28개(2016.06~)) 보다 Space Bar가 많은 경우 “ ”로 씌워 줍니다.

Ex) start %T32_PATH%\t32marm64.exe -c %iTSP_PATH%\config-sim.t32, %iTSP_PATH%\startup.cmm %SYS_PATH% 10 1 . . "--os=Android --soc=S5PV310 --kernel-bus-length=64bit --ramdumpdir=d:\03.DUMP\xxx --kernel-symbol=d:\03.DUMP\xxx\vmlinux --phy-kernel-startaddr=0x80000000 --kaslr=ON"

만약 Command Line 실행 중 “ “ 처리하지 않아 실행인자 사이에 Space Bar 허용 개수(실행 인자) 초과 시 다음 경고 Message를 만날 수 있습니다. 다음과 같은 Message를 만날 경우 반드 시 실행 인자 전체를 “ “로 묶어주시기 바랍니다.

다음 그림은 Command Line 설정인자의 구분자와 GUI Mapping을 보여줍니다.

iTSP 구동 Trouble Shooting

iTSP는 반드시 License Maintenance를 보유한 상태에서 사용가능합니다. 다음은 iTSP를 사용이 불가 할 때 나오는 메시지와 대처 방법을 기술합니다.

1) License Maintenance 없이 Target Mode로 연결하는 경우

해결방법: License Maintenance가 유효한 JTAG Cable(Dongle)을 연결 후 다시 시도합니다.

2) License Maintenance 없이 RAM Dump Simulation Mode로 실행한 경우

해결방법: License Maintenance가 유효한 JTAG Cable(Dongle)을 연결 후 다시 시도합니다.

3) RAM Dump Simulation Mode로 2016년 01월 이하 버전 실행 시

iTSP를 이용한 RAM Dump Simulation Mode는 2016년 02월 25일 버전이상에서만 지원합니다.

해결방법: 2016년 02월 25일 이상버전으로 Update합니다.

4) iTSP를 일반 Simulation Mode로 실행한 경우

iTSP는 일반 Simulation Mode를 지원한지 않습니다.

해결방법: 2016년 02월 25일 이상버전에서 License Maintenance 있는 JTAG Cable(Dongle)을 TRACE32

본체(Power Debug Module)에 체결하고 PC에 USB Cable을 연결 한 후 재실행 합니다.

5) iTSP RAM Dump Mode를 지원하지 않는 2016년 02월 버전(25일 미만) 사용 시

해결방법: 2016년 02월 25일 이상버전에서 License Maintenance 있는 JTAG Cable(Dongle)을 TRACE32

본체(Power Debug Module)에 체결하고 PC에 USB Cable을 연결 한 후 재실행 합니다.

6) iTSP 최신 버전이 아닐 경우

해결방법 : 최신 버전에 대한 release note 를 확인합니다.

최신 버전에 대한 사용이 필요할 경우 TRACE32 홈페이지를 통해 다운로드 합니다.

MDSTECH

"ITSP User's Guide"의 두 판 사이의 차이