Jeonghun (James) Lee: 7월 2015

7/31/2015

DRAM-2 Memory의 성능향상 방법 Bank Interleaving 과 Burst Mode 및 DLL

1. Memory 성능 향상 방법

Bank Interleaving 찾다가 아래의 사이트를 발견하고 이를 정리한다.
메모리 대역폭을 높이는 방법 중 Bank Interleaving 만 잘 모르것 같다.

메모리의 버스 폭(width)를 늘리는 방법. ( 이미 정해져 있을 거라고 본다)
메모리의 operating_clock을 높이는 방법 ( 한계가 있으며, DDR의 Chip 확인)
메모리에 interleaving을 적용하여 대역폭을 높이는 방법.

Interleave는 일반적으로 저장장소를 몇개로 나누어 이를 동시에 접근하도록 하는 것이다.

http://blog.naver.com/signal97/197538037

1.1. Memory Data Bus Bandwidth 조절

가장쉬운 방법이며, 사실 회로도를 봐도 성능이 더 나을 것이라는 것을 쉽게 파악이 가능하다.
하지만 주의사항이 있다. 왜냐하면 본인의 SOC가 정확히 어디까지 Bandwidth 까지 지원이 되는지를 정확히 파악을 하고 사용해야 하기때문이다.

우선 기본적인 SOC의 경우 외부 32Bit RAM Data Bus 아래와 같이 지원을 한다면, 1번이 가장 좋을 것이다.
TI의 경우 1번을 미지원하는 저렴한 SoC를 보면 외부는 32bit이지만, 내부 Memory Interface는 16bit를 사용하기 때문에 별소용이 없다.
그리고, 더불어 DRAM의 사용으로 인한 Power 소비와 가격 문제 및 부피 등을 고려해야 할때가 있으므로, SoC Memory Interface부분을 잘보자.

8bit DataBus DRAM x 4
16bit DataBus DRAM x 2
32bit DataBus DRAM x 1
16bit DataBus DRAM x 1 (TI는 지원)

상위에서 설명한 DLL을 Clock을 Overclock을 해서 사용하는 방법인데, 별로 권장할 사항은 아닌 것 같다.

1.2. Bank Interleaving로 성능향상

최근에 알게된 정보이며, 가장 관심을 가지고 있는 기능이다.

DRAM의 기본동작

DRAM은 Physical Address를 사용하지 않기 때문에 처음 Bank 단위로 선택하고 CAS 와 RAS를 사용한다.
예를 들면, 0x11001100 Bank 선택과 함께 Column Address 와 Row Address Read/Write Command와 Refresh Time 으로 동작한다.
그래서 SoC는 이를 Physical Address를 DRAM Address로 변경하는 작업이 필요하다.
(SRAM에 Refresh Time이 필요없다)

Bank Interleaving 의 기본이해

1개의 DRAM 안에는 8개 정도의 Bank가 있고, 이는 DRAM에 따라 다를 수 있으니 확인하자.
Embedded에서는 1~4개 정도의 DRAM을 주로 사용하며, 각각의 Bank 수를 따지면 상당수의 Bank가 존재한다,
이 Bank들을 각각 개별로 접근하고 지속적으로 순차적으로 읽고 쓴다면 성능이 향상이 된다는 개념이 바로 Bank Interleaving 이다.
물론 여기에도 한계는 존재하며, 그 이상의 Interleave는 필요가 없을 것이다.

Bank Interleaving의 동작 및 사용방법

일반적으로 Physical 주소를 접근한다고 하면 동일한 1개의 Bank를 선택하고 순차적으로 저장하겠지만, Bank interleaving을 사용하면,
SoC는 CS(Chip Select)선택이 된 후 , 각 개별 Bank를 선택하여 Read/Write를 진행을 한다.
한마디로 데이타를 분할하고 개별 Bank에 빠르게 거의동시에 접근이 가능하는 것이다.
이는 Memory Controller에서 설정을 변경으로 순차적으로, 각 Bank를 이용한다면 아래와 같이 1개의 DRAM에서 약간의 성능의 향상 볼수 있겠지만, 많은 성능 향상은 기대하기 힘들다.
DRAM의 Latency( Precharge time 등)을 줄이기 용도일 뿐 , Bank Interleaving 이용을 해도 많은 성능향상은 기대하기가 힘들다.

왜냐하면, DRAM의 Bank의 Latency(즉 precharge Time 등) 과 Bank Interleaving의 갯수는 상충관계에 있기 때문에 이는 정해놓고 이용하는 것이 옳을 것이다.

https://ko.wikipedia.org/wiki/%EB%A9%94%EB%AA%A8%EB%A6%AC_%EC%9D%B8%ED%84%B0%EB%A6%AC%EB%B9%99

Bank Interleaving 개념

이글을 읽어보면, Bank Interleaving 통하여, Precharge Time도 줄일수 있다고 한다.

http://www.kbench.com/?q=node/8417

2. TI의 Memory 설정방법

관련내용은 AM437x

http://processors.wiki.ti.com/index.php/AM335x_EMIF_Configuration_tips

DM8148

http://processors.wiki.ti.com/index.php/DM814x_Overview
http://www.ti.com/lit/ds/sprs647e/sprs647e.pdf

TMS320DM8127 and TMS320DM814x DaVinci™ Digital Media Processors TRM (Rev. G)

http://www.ti.com/lit/ug/sprugz8g/sprugz8g.pdf

Dynamic Memory Manager (DMM)
- 1162
- Figure 7-3. DDR2/DDR3 Subsystem Block Diagram

2.1 TI의 Bank Interleaving

TI 경우 Address mapping을 어떻게 하느냐에 따라 결정이 Bank Interleaving이 동작이 된다.
DRAM 인 경우 Cols , Bank , Row Addr 을 Command 처럼 사용하지만 내부는 logical로 사용)
CPU에 따라 다르지만, bus width 변경이 되는 것이 있지만, 안되는 것도 많은
특히 예전 AP들 AM437x는 OCP Interface를 사용하여 변경이 가능하지만, 변경을 하여도 속도가 2배로 증가되지는 않음.
(오히려, 관련 Threshold 설정이나, 다른 설정변경)

상위의 Bank당 8개식 Bank Interleaving 한 것이며, 기본 개념은 아래에서 확인을 하자.

https://en.wikipedia.org/wiki/Interleaved_memory
https://en.wikipedia.org/wiki/Interleaved_memory#/media/File:Interleaving.gif

위 그림은 개념만을 익히는 것으로 하고, 실제 AM487x 시리즈의 예를 보겠다.

Address Mapping (Bank Interleaving)

Bank interleaving을 제대로 사용하기 위해서는 Logical address을 RAM 주소로 Mapping을 제대로 이해해야한다.

정확히 말해서 OCP Address -> RAM 주소 변환이다. (OCP TI의 Device)

Address Mapping은 DRAM의 Read or Write Operation 순서가 Read or Write Command 다음에 Cols 과 Bank가 바로 필요하기에 우측에 항상 먼저 Cols과 필요한 Bank수를 기록하는 방식으로 Mapping을 한다.

그리고 이는 결정적으로 Bank interleaving의 갯수를 결정을 짓는다.

AM473x EX-1

REG_IBANK_POS(칩내부 뱅크)와 REG_EBANK_POS(외부 칩)는 위치를 결정하며,
Column Address 항상 맨 우측간다. 그리고, 그 다음 Bank Address Mapping과 CS(EBANK)
가 Mapping되어 총 4bit의 Address가 Mapping되어 16개의 Bank interleaving 가능

(CS(EBANK): 1bit IBANK:3bit))

AM473x EX-2

위와 동일하지만, IBANK: 2bit 와 CS:1bit Mapping이 Column Address 다음 Mapping되어
Bank Interleaving은 8개 밖에 지원을 못한다.
자세한 내용은 데이타시트

DM385

RSIZE: Row Address's size
PAGESIZE: Column Address's size
IBANK: DRAM의 실제 BANK
EBANK: DRAM의 갯수

3. Burst Mode (prefetch buffer)

Burst Mode는 기본적으로 read or write command 한번에 몇번의 data를 보내는 방식이다. 이 기능은 오래전부터 존재했지만, 아래와 같이 buffer의 크기에 따라 진화해 가고 있으며, 변화해 가고 있다.

DDR의 prefetch buffer system의 변화

DDR : 2bit prefetch buffer system (2 words)
DDR2 : 4bit prefetch buffer system (4 words)
DDR3 : 8bit prefetch buffer system (8 words)

Prefetch의 buffer size는 각각의 Data를 보낼 수 있는 능력을 말하며,
DDR3일 경우 연속으로 8번까지 보낼수 있다.

https://en.wikipedia.org/wiki/Prefetch_buffer

BC4 (burst chop)

DDR3의 새기능이지만, 내용을 보면 별다른기능이 아니다, 위에서 봤듯이 DDR2->DDR3로 변화하면서, 8bit buffer system에 맞게 BL4를 BL8 포맷에 변화한 기능이다.
BC4는 처음 4번은 전송하고 나머지 4번은 Mask 처리하는 방식인것이다.

*DDR3에서는 BL4 대신 BC4를 사용

http://www.rampedia.com/index.php/define-burst_chop

AM437x 인 경우

EMIF는 기본적으로 Burst Mode로 동작을 하는 것 같다. .
AM437x 인 경우,
EMIF4D_READ_WRITE_EXECUTION_THR
write or read를 사용하는 burst 수?

DDR3의 새기능 : burst chop은 8 burst 하는 아키텍처에서, BL4은 맞지 않기에, BL4를 새롭게 구현한 기능으로 , 4번을 동작하고, 나머지 4번을 Mask 처리하는 기능으로 BL4 대신 BC4을 사용한다.

MT41K512M8RH의 Datasheet 로 DDR3에서는 BL4 대신 BC4 or BL8사용

추가로, odering을 맘대로 변경이 가능

http://forum.falinux.com/zbxe/index.php?document_srl=530529&mid=hardware
http://forum.falinux.com/zbxe/index.php?document_srl=530859&mid=hardware

* DDR3L SDRAM (MT41K512M8) 4Gb_DDR3L_2133.pdf
* New Features of DDR3 SDRAM : E1503E10.pdf
* AM437x ARM® Cortex™-A9 Processors Technical Reference Manual: spruhl7c.pdf

4. DLL(Delay -Locked Loop)

100MHz -> 133MHz 변경 166MHz 변경
(이것은 DRAM의 Marking을 확인하고, 시도 )
현재 DDR인 경우 거의 기본 CLOCK을 133MHz로 사용하는 걸로 기억

PLL에 과 유사하며, DRAM에 제공되는 내부 CLOCK이다,
현재 AM437x인 경우, CLOCK을 두 가지 모드로 동시에 제공을 하며 이는 Power Consumption 을 줄이기 위해서 사용을 한다. 예를 들면 한 CLOCK은 133 사용 , 또 다른 CLOCK은 266사용으로 동시에 사용하므로써, 내부 PLL을 재 설정이 필요 없이 RAM의 CLOCK을 변경하고 Power Comsumption의 소비를 줄일 수 있다.

  https://en.wikipedia.org/wiki/Delay-locked_loop
  http://blog.naver.com/force1206/220359308301
  http://blog.naver.com/circlebird/60057431287

DDR SDRAM은 온칩 DLL(delay-locked loop)을 이용하여 DQS와 이에 상응하는 DQS를 클럭 아웃 시킴으로써 이들이 잘 일치하도록 하며, 전압 및 온도가 변화할 경우 서로를 추적할 수 있다

http://www.eetkorea.com/ARTICLES/2006OCT/PDF/EEKOL_2006OCT16_INTD_STOR_TA_05.PDF?SOURCES=DOWNLOAD

7/30/2015

DRAM-1 Module RAM의 구성과 Type 및 각 용어 설명

1. DRAM on the Module

E0593E20의 문서를 보면, Mother Board의 Termination은 signal refrection을 줄이기 위해서 추가한 저항이라고 나와 있다.

하지만 Embedded 쪽에서는 이 Termination이 필요성이 있는지 부터가 의문이 들었으며,
Embedded에서는 사용설정이 필요없을 것 같지만, 왜 사용하는지 정확히 파악하기 위해서
사용되어지는 용어와 구성요소들을 이해하기 위해서 비교하면서 적어본다.
일단 간단히 용어와 구성을 이해하고 넘어가자.

기본설명은 Module RAM 기반으로 하며, Embedded 의 구성과는 다소다르다.

1.1 Module RAM의 Topology

Module RAM과 Embedded의 Topology 구성은 다르며, 각각의 구성되는 부분을 알아보자.

Module RAM의 기본구성 방법

T-Branch : Bus의 길이가 같으며, Latency가 동일하다
fly-by Topology : Bus의 길이가 뒤로 갈수록 길어지기에, Latency가 달라진다.

Module RAM의 구성은 위와 같이 T-Branch와 fly-by Topology 방식이다.

Embedded 의 구성 (AM437x의 8bit 모드)

일반적인 Embedded SOC 32bit Bus를 가진 경우는 Memory Controller부분에 관한 회로설계를 각각 확인해봐야겠지만,

AM437x인 경우에는 fly-by Topology 방식으로 연결이 아래와 같이 되고 있으며,
EMIF에서는 32bit 이고 각 개별 RAM 마다 8bit의 모드로 연결이 되어 구성이 된다.
Data Bus로 4개의 DRAM개까지 다는 것이다.
물론 SOC에 따라 Memory의 8bit 모드도 지원이 되지 않을 수도 있어 16bit 모드로 2개 or 32bit로 단일로 구성할수도 있다.

DM8127인 경우 fly-by Topology 방식과 동일하지만 아래의 EMIF가 2개까지 확장이 가능

1.2 Leveling 이란

fly-by topology로 구성할 경우 CMD/ADD/CLK과 DQ/DM/QS사이 생기는 Timing 오차로 생기는 문제를 없애고자 함이다.
이런 신호전달지연과 같이 이 Timing 을 보정하여 극복하려는 문제이다.

Read Leveling 은 System calibration 작업에 사용이되며, 즉 DDR3이 predefined data pattern, micron일 경우, 0,1,0,1 or 0,1,0,1,0,1,0,1,0,1를 연속적으로 보내면, Controller는 DQ/DQS Capture Timing을 MPR을 사용하여 조절한다.

Writing Leveling은 DDR3는 변형된 CLK-DQS 보내고, Contoller는 CMD,ADD,CLK신호가 DDR3에 동시에 DQ, DM,DQS 신호 함께 도착하도록 이 Timing을 정보를 이용하여 조절한다.

DM8127 or DM8148

TI는 SOFT Leveling로 구현을 하며, trace length delay, 즉 선로 길이 지연을 보상한다.

http://processors.wiki.ti.com/index.php/TI814x-DDR3-Init-U-Boot
http://electronics.stackexchange.com/questions/86287/what-is-ddr-software-leveling

관련 Register DDRPHYCR (DDR PHY Control Register)

RDEYE_LVL_DIS
GATE_LVL_DIS
WR_LVL_DIS

AM437x 의 설정

HW Leveling 지원 및 PVT( Process, Voltage, Temperature)를 추측하는 기능이존재

EMIF4D_READ_WRITE_LEVELING_RAMP_WINDOW
EMIF4D_READ_WRITE_LEVELING_RAMP_CTRL
EMIF4D_READ_WRITE_LEVELING_CTRL
EMIF4D_STS Register

*HW Leveling 과 SW Leveling 의 차이는 SOC의 지원여부 및 설정되는 것이겠다.

1.3 MBT와 ODT (On Die Termination)

SOC는 각각의 DRAM과 통신하는 동안 신호의 반향 (Signal Reflection)을 막아주기 위해 Termination이 필요하다.
DRAM의 Termination의 방법은 아래와 같이 두가지 방법이 존재하다.

MBT : 외부에 Ground 함께 저항 (pull-down)을 두고 연결하여 Termination
ODT : 내부에서 Hi-Z로 Termination으로 종료하는 것 같다

ODT의 기본구성

다른 Device가 통신하는 동안 신호의 반향 (Signal Reflection)을 막는 것이 말 그대로, Termination 을 하는 것 같다.
하지만 DDR2와 DDR3는 구조가 다르지만 구현되는 구조는 동일한 것 같다.

https://en.wikipedia.org/wiki/On-die_termination#References.4F (Samsung)

ODT Resistor

외부의 RZQ라는 Termination 저항 240R을 GND에 묶어 사용하고, 위에서 처럼 RTT는 내부에서, 2, 4, 6, 8, or 12을 나누어 저항변경하여 사용하는 것 같다. 이는 위에서 언급한 signal refrection을 줄이는 기능이다.
동작방식은 최신기술인 Dynamic ODT인 경우 MRS Command 없이, ODT pin 값이 변경이 이 설정된 값으로 자동으로 변경이 된다. (ex. 240R/4 이는 MR Register 설정 가능 )

RTT= RZQ / 2,4,6,8 or 12

그리고 참고로, 이 RTT가 DQ,DM,DQS,DQS#, and TDQS,TDQS 영향이 끼친다고 한다고
하지만, 현재봐서는 Embeded에서 크게 사용되지 않을 것 같다.

Output Driver Impedance (Ron)

Ron 이라는 output driver 저항이 있는데, 이 부분이 Rtt와 동일한 것 같으며.

Rtt는 Writing 시에만,이용이 되지만, Ron만 사용하는 것이 아닌지? 지금 혼동이 됨.

Ron은 PVT (Process , Voltage, Temperature) 증가시킨다고 함.

DQ : (Data bus: Data I/O) 4bit or 8bit 조정가능
DM, (Input data mask: I ) : Write data를 위한 input mask
DQS, DQS# :(Data strobe: I/O): Data 신호 (Edge-aligned with read data,Center-aligned to write data)
TDQS, TDQS# (Termination data strobe: O ) : 현재 EVM에서 역시 사용안함.

DDR3 구조

2. Embeded 설정 필요성

Micron User Manual 문서와 Samsung 관련 및 엘피다 문서를 읽다보면 ODT 기능 및
Termination 저항 그리고, Writing 및 Reading Leveling 모두 Module RAM에만 종속이 되어있는 기술 같이 설명 되어있다.

그리고, 생각을 해보면, 그럴 것 같다. Embedded 쪽에서는 DDR을 8bit로 버스로 4개 혹은 16bit로 2개 사용하여, Waiting for access 및 대기 모드 상태 일때가 없고, 위와 같은 Termination 저항의 필요성 및 ODT가 필요할지 모르겠다. fly-by topology 문제도 없으니,
구지 Leveling 까지로 Timing 조절을 할 필요가 없을 것 같다.

아직 정확한 설정필요성의 여부를 판단하지 못하겠다. EVM에서도 역시 사용하지 않는 것 같다. TI의 DDR 관련 문서가 없고, 회로도에서 Rtt & Ron 저항을 발견을 못했다.
다만 설정에 Dynmic ODT사용을 하지 않으며 고정으로 저항값을 변경하여 설정했다 (Rtt)

  http://www.micron.com/parts/dram/ddr3-sdram/mt41k512m8rh-125

* New Features of DDR3 SDRAM :E1503E10.pdf
* New Features of DDR3 SDRAM :E1503E10.pdf
* New Function of DDR2 SDRAM On Die Termination (ODT) : E0593E20.pdf
* MT41K512M8RH Datasheet (ODT Characteristics)

  https://en.wikipedia.org/wiki/On-die_termination#Why_is_on-die_termination_needed.3F
참조문서

기타 참조사이트

  http://www.easytv.co.kr/93 (DDR3 ODT)
  http://www.easytv.co.kr/114 (DDR3 ZQ Calcaulation)
  http://www.easytv.co.kr/115 (DDR3 DYN ODT)
  http://www.easytv.co.kr/120 (DDR3 Prefetch
  https://en.wikipedia.org/wiki/On-die_termination
  https://en.wikipedia.org/wiki/On-die_termination#Why_is_on-die_termination_needed.3F

7/28/2015

Sitara(AM437x EVM) 정보 U-BOOT ENV설정

1. AM437x EVM 기본정보

BOARD NAME: AM43__GP
VERSION: 1.4
RAM: 4-Gb (512Mb × 8) DDR3L SDRAM (MT41K512M8RH)
NAND: 4-Gb (512M x 8) (MT29F4G08AB)

* board type은 rtc를 통해 설정됨
(Version: CCS에서 직접확인 )

1.1 GP-EVM 과 IDK-EVM (회로도 및 관련내용)

http://processors.wiki.ti.com/index.php/AM437X_EVM_Boards?keyMatch=AM437x%20evm&tisearch=Search-EN-Everything

B. GP-EVM HW 각 세부정보 (개발전 반드시 필독)

http://processors.wiki.ti.com/index.php/AM437x_General_Purpose_EVM_HW_User_Guide?keyMatch=AM437x%20evm&tisearch=Search-EN-Everything

C. AM437x 와 RAM(MTK512M8RH) Datasheet

AM437x

http://www.ti.com/lit/pdf/spruhl7

RAM

http://www.micron.com/parts/dram/ddr3-sdram/mt41k512m8rh-125

  http://www.ti.com/tool/tmdxevm437x
  http://www.ti.com/lit/ug/spruhw7/spruhw7.pdf

2. EVM Serial 설정

GP_EVM일 경우, 처음 아래와 같이 UART0을 설정.

  UART0 : 115200 bps, 8-bit, no parity, 1 stop bit and noflow control.
login: root

3. AM437x UBOOT ENV구성

U-BOOT의 기본 Boot모드는 SD Card (mmcboot) 와 USB 이며, 이를 network mode 변경도 쉽다.

U-Boot# pri
arch=arm
baudrate=115200
board=am43xx
board_name=AM43__GP
board_rev=1.4A
bootcmd=run findfdt; run mmcboot;run usbboot;run nandboot; 
bootdelay=1
bootdir=/boot
bootenv=uEnv.txt
bootfile=zImage
bootm_size=0x10000000
bootpart=0:2
console=ttyO0,115200n8
cpu=armv7
dfu_alt_info_emmc=MLO raw 0x100 0x100 mmcpart 0;u-boot.img raw 0x300 0x1000 mmcpart 0
dfu_alt_info_mmc=boot part 0 1;rootfs part 0 2;MLO fat 0 1;spl-os-args fat 0 1;spl-os-image fat 0 1;u-boot.img fat 0 1;uEnv.txt fat 0 1
dfu_alt_info_ram=kernel ram 0x80200000 0x4000000;fdt ram 0x80f80000 0x80000;ramdisk ram 0x81000000 0x4000000
dfu_bufsiz=0x10000
eth1addr=34:b1:f7:30:fb:00
ethact=cpsw
ethaddr=34:b1:f7:30:f7:fe
fdt_addr_r=0x88000000
fdtaddr=0x88000000
fdtfile=undefined
findfdt=if test $board_name = AM43EPOS; then setenv fdtfile am43x-epos-evm.dtb; fi; if test $board_name = AM43__GP; then setenv fdtfile am437x-gp-evm.dtb; fi; if test $board_name = AM43__SK; then setenv fdtfile am437x-sk-evm.dtb; fi; if test $fdtfile = undefined; then echo WARNING: Could not determine device tree; fi; 
importbootenv=echo Importing environment from mmc ...; env import -t $loadaddr $filesize
kernel_addr_r=0x82000000
loadaddr=0x82000000
loadbootenv=load ${devtype} ${devnum} ${loadaddr} ${bootenv}
loadfdt=load ${devtype} ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}
loadimage=load ${devtype} ${bootpart} ${loadaddr} ${bootdir}/${bootfile}
loadramdisk=load ${devtype} ${devnum} ${rdaddr} ramdisk.gz
mmcargs=setenv bootargs console=${console} ${optargs} root=${mmcroot} rootfstype=${mmcrootfstype}
mmcboot=mmc dev ${mmcdev}; setenv devnum ${mmcdev}; setenv devtype mmc; if mmc rescan; then echo SD/MMC found on device ${devnum};if run loadbootenv; then echo Loaded environment from ${bootenv};run importbootenv;fi;if test -n $uenvcmd; then echo Running uenvcmd ...;run uenvcmd;fi;if run loadimage; then run loadfdt; echo Booting from mmc${mmcdev} ...; run mmcargs; bootz ${loadaddr} - ${fdtaddr}; fi;fi;
mmcdev=0
mmcroot=/dev/mmcblk0p2 rw
mmcrootfstype=ext4 rootwait
mtdids=nand0=nand.0
mtdparts=mtdparts=nand.0:256k(NAND.SPL),256k(NAND.SPL.backup1),256k(NAND.SPL.backup2),256k(NAND.SPL.backup3),512k(NAND.u-boot-spl-os),1m(NAND.u-boot),256k(NAND.u-boot-env),256k(NAND.u-boot-env.backup1),7m(NAND.kernel),-(NAND.file-system)
nandargs=setenv bootargs console=${console} ${optargs} root=${nandroot} rootfstype=${nandrootfstype}
nandboot=echo Booting from nand ...; run nandargs; nand read ${fdtaddr} NAND.u-boot-spl-os; nand read ${loadaddr} NAND.kernel; bootz ${loadaddr} - ${fdtaddr}
nandroot=ubi0:rootfs rw ubi.mtd=NAND.file-system,4096
nandrootfstype=ubifs rootwait=1
netargs=setenv bootargs console=${console} ${optargs} root=/dev/nfs nfsroot=${serverip}:${rootpath},${nfsopts} rw ip=dhcp
netboot=echo Booting from network ...; setenv autoload no; dhcp; tftp ${loadaddr} ${bootfile}; tftp ${fdtaddr} ${fdtfile}; run netargs; bootz ${loadaddr} - ${fdtaddr}
nfsopts=nolock
partitions=uuid_disk=${uuid_gpt_disk};name=rootfs,start=2MiB,size=-,uuid=${uuid_gpt_rootfs}
ramargs=setenv bootargs console=${console} ${optargs} root=${ramroot} rootfstype=${ramrootfstype}
ramdisk_addr_r=0x88080000
ramroot=/dev/ram0 rw
ramrootfstype=ext2
rdaddr=0x88080000
rootpath=/export/rootfs
soc=am33xx
static_ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off
stderr=serial
stdin=serial
stdout=serial
usbargs=setenv bootargs console=${console} ${optargs} root=${usbroot} rootfstype=${usbrootfstype}
usbboot=setenv devnum ${usbdev}; setenv devtype usb; usb start ${usbdev}; if usb dev ${usbdev}; then if run loadbootenv; then echo Loaded environment from ${bootenv};run importbootenv;fi;if test -n $uenvcmd; then echo Running uenvcmd ...;run uenvcmd;fi;if run loadimage; then run loadfdt; echo Booting from usb ${usbdev}...; run usbargs;bootz ${loadaddr} - ${fdtaddr}; fi;fi;usb stop ${usbdev};
usbdev=0
usbnet_devaddr=34:b1:f7:30:fb:00
usbroot=/dev/sda2 rw
usbrootfstype=ext4 rootwait
vendor=ti
ver=U-Boot 2014.07-gfb6ab76 (Jul 06 2015 - 16:10:49)

Environment size: 4128/65532 bytes

3.1 기본 Boot 구성

위의 환경설정을 간단히 분석해보면,

bootcmd=run findfdt; run mmcboot;run usbboot;run nandboot;

findfdt에서 board이름에 따라 fdtfile= *.dtb파일 결정 및 설정 (device tree)
mmcboot 시도
usbboot 시도
nandboot 시도

3.2 Boot Mode 변경 (network)

DHCP Server 사용시

netboot는 되어있지 않으므로, findfdt와 netboot로 변경

U-Boot#  setenv bootcmd 'run findfdt; run netboot;'

DHCP Server 미사용시

DHCP Server를 운영하지 못할 경우, IP를 강제로 할당 및 환경값을 미리 설정하자.

U-Boot# setenv ipaddr '192.168.1.101'
U-Boot# setenv serverip '192.168.1.100'
U-Boot# setenv netmask '255.255.255.0'
U-Boot# setenv rootpath '/home/jhlee/am437x/targetNFS'
U-Boot# setenv netargs 'setenv bootargs console=${console} ${optargs} root=/dev/nfs nfsroot=${serverip}:${rootpath},${nfsopts} rw ip=${ipaddr}' 
U-Boot# setenv netboot1 'echo Booting from network ...; setenv autoload no; tftp ${loadaddr} ${bootfile}; tftp ${fdtaddr} ${fdtfile}; run netargs; bootz ${loadaddr} - ${fdtaddr}'
U-Boot# setenv bootcmd 'run findfdt; run netboot1;'

http://processors.wiki.ti.com/index.php/Booting_Linux_kernel_using_U-Boot

4. AM335x UBOOT Env 설정

=> pri
arch=arm
args_fit=setenv bootargs console=${console} 
args_mmc=run finduuid;setenv bootargs console=${console} ${optargs} root=PARTUUID=${uuid} rw rootfstype=${mmcrootfstype}
baudrate=115200
board=am335x
board_name=A335X_SK
board_rev=1.2B
board_serial=34124P192908
boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
boot_efi_binary=load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootarm.efi; if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r};elsebootefi ${kernel_addr_r} ${fdtcontroladdr};fi
boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}extlinux/extlinux.conf
boot_fdt=try
boot_fit=0
boot_net_usb_start=usb start
boot_prefixes=/ /boot/
boot_script_dhcp=boot.scr.uimg
boot_scripts=boot.scr.uimg boot.scr
boot_targets=mmc0 legacy_mmc0 mmc1 legacy_mmc1 nand0 pxe dhcp 
bootcmd=if test ${boot_fit} -eq 1; then run update_to_fit;fi;run findfdt; run init_console; run envboot; run distro_bootcmd
bootcmd_dhcp=run boot_net_usb_start; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi
bootcmd_legacy_mmc0=setenv mmcdev 0; setenv bootpart 0:2 ; run mmcboot
bootcmd_legacy_mmc1=setenv mmcdev 1; setenv bootpart 1:2 ; run mmcboot
bootcmd_mmc0=setenv devnum 0; run mmc_boot
bootcmd_mmc1=setenv devnum 1; run mmc_boot
bootcmd_nand=run nandboot
bootcmd_pxe=run boot_net_usb_start; dhcp; if pxe get; then pxe boot; fi
bootcount=5
bootdelay=2
bootdir=/boot
bootenvfile=uEnv.txt
bootfile=zImage
bootm_size=0x10000000
bootpart=0:2
bootscript=echo Running bootscript from mmc${mmcdev} ...; source ${loadaddr}
console=ttyO0,115200n8
cpu=armv7
dfu_alt_info_emmc=rawemmc raw 0 3751936
dfu_alt_info_mmc=boot part 0 1;rootfs part 0 2;MLO fat 0 1;MLO.raw raw 0x100 0x100;u-boot.img.raw raw 0x300 0x400;spl-os-args.raw raw 0x80 0x80;spl-os-image.raw raw 0x900 0x2000;spl-os-args fat 0 1;spl-os-image fat 0 1;u-boot.img fat 0 1;uEnv.txt fat 0 1
dfu_alt_info_nand=SPL part 0 1;SPL.backup1 part 0 2;SPL.backup2 part 0 3;SPL.backup3 part 0 4;u-boot part 0 5;u-boot-spl-os part 0 6;kernel part 0 8;rootfs part 0 9
dfu_alt_info_ram=kernel ram 0x80200000 0xD80000;fdt ram 0x80F80000 0x80000;ramdisk ram 0x81000000 0x4000000
distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done
efi_dtb_prefixes=/ /dtb/ /dtb/current/
envboot=mmc dev ${mmcdev}; if mmc rescan; then echo SD/MMC found on device ${mmcdev};if run loadbootscript; then run bootscript;else if run loadbootenv; then echo Loaded env from ${bootenvfile};run importbootenv;fi;if test -n $uenvcmd; then echo Running uenvcmd ...;run uenvcmd;fi;fi;fi;
eth1addr=d4:94:a1:86:70:e1
ethaddr=d4:94:a1:86:70:e0
fdt_addr_r=0x88000000
fdtaddr=0x88000000
fdtcontroladdr=8ef282f8
fdtfile=undefined
findfdt=if test $board_name = A335BONE; then setenv fdtfile am335x-bone.dtb; fi; if test $board_name = A335BNLT; then setenv fdtfile am335x-boneblack.dtb; fi; if test $board_name = BBG1; then setenv fdtfile am335x-bonegreen.dtb; fi; if test $board_name = A33515BB; then setenv fdtfile am335x-evm.dtb; fi; if test $board_name = A335X_SK; then setenv fdtfile am335x-evmsk.dtb; fi; if test $board_name = A335_ICE; then setenv fdtfile am335x-icev2.dtb; fi; if test $fdtfile = undefined; then echo WARNING: Could not determine device tree to use; fi; 
finduuid=part uuid mmc ${bootpart} uuid
fit_bootfile=fitImage.itb
fit_loadaddr=0x88000000
importbootenv=echo Importing environment from mmc${mmcdev} ...; env import -t ${loadaddr} ${filesize}
init_console=if test $board_name = A335_ICE; then setenv console ttyO3,115200n8;else setenv console ttyO0,115200n8;fi;
kernel_addr_r=0x82000000
load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}${efi_fdtfile}
loadaddr=0x82000000
loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenvfile}
loadbootscript=load mmc ${mmcdev} ${loadaddr} boot.scr
loadfdt=load ${devtype} ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}
loadfit=run args_fit; bootm ${loadaddr}#${fdtfile};
loadimage=load ${devtype} ${bootpart} ${loadaddr} ${bootdir}/${bootfile}
loadramdisk=load mmc ${mmcdev} ${rdaddr} ramdisk.gz
mmc_boot=if mmc dev ${devnum}; then setenv devtype mmc; run scan_dev_for_boot_part; fi
mmcboot=mmc dev ${mmcdev}; setenv devnum ${mmcdev}; setenv devtype mmc; if mmc rescan; then echo SD/MMC found on device ${mmcdev};if run loadimage; then if test ${boot_fit} -eq 1; then run loadfit; else run mmcloados;fi;fi;fi;
mmcdev=0
mmcloados=run args_mmc; if test ${boot_fdt} = yes || test ${boot_fdt} = try; then if run loadfdt; then bootz ${loadaddr} - ${fdtaddr}; else if test ${boot_fdt} = try; then bootz; else echo WARN: Cannot load the DT; fi; fi; else bootz; fi;
mmcrootfstype=ext4 rootwait
mtdids=nand0=nand.0
mtdparts=mtdparts=nand.0:128k(NAND.SPL),128k(NAND.SPL.backup1),128k(NAND.SPL.backup2),128k(NAND.SPL.backup3),256k(NAND.u-boot-spl-os),1m(NAND.u-boot),128k(NAND.u-boot-env),128k(NAND.u-boot-env.backup1),8m(NAND.kernel),-(NAND.file-system)
nandargs=setenv bootargs console=${console} ${optargs} root=${nandroot} rootfstype=${nandrootfstype}
nandboot=echo Booting from nand ...; run nandargs; nand read ${fdtaddr} NAND.u-boot-spl-os; nand read ${loadaddr} NAND.kernel; bootz ${loadaddr} - ${fdtaddr}
nandroot=ubi0:rootfs rw ubi.mtd=NAND.file-system,2048
nandrootfstype=ubifs rootwait=1
netargs=setenv bootargs console=${console} ${optargs} root=/dev/nfs nfsroot=${serverip}:${rootpath},${nfsopts} rw ip=dhcp
netboot=echo Booting from network ...; setenv autoload no; dhcp; run netloadimage; run netloadfdt; run netargs; bootz ${loadaddr} - ${fdtaddr}
netloadfdt=tftp ${fdtaddr} ${fdtfile}
netloadimage=tftp ${loadaddr} ${bootfile}
nfsopts=nolock
partitions=uuid_disk=${uuid_gpt_disk};name=rootfs,start=2MiB,size=-,uuid=${uuid_gpt_rootfs}
pxefile_addr_r=0x80100000
ramargs=setenv bootargs console=${console} ${optargs} root=${ramroot} rootfstype=${ramrootfstype}
ramboot=echo Booting from ramdisk ...; run ramargs; bootz ${loadaddr} ${rdaddr} ${fdtaddr}
ramdisk_addr_r=0x88080000
ramroot=/dev/ram0 rw
ramrootfstype=ext2
rdaddr=0x88080000
rootpath=/export/rootfs
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;run scan_dev_for_efi;
scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done
scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; if test -z "${fdtfile}" -a -n "${soc}"; then setenv efi_fdtfile ${soc}-${board}${boardver}.dtb; fi; for prefix in ${efi_dtb_prefixes}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${efi_fdtfile}; then run load_efi_dtb; fi;done;if test -e ${devtype} ${devnum}:${distro_bootpart} efi/boot/bootarm.efi; then echo Found EFI removable media binary efi/boot/bootarm.efi; run boot_efi_binary; echo EFI LOAD FAILED: continuing...; fi; setenv efi_fdtfile
scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}extlinux/extlinux.conf; then echo Found ${prefix}extlinux/extlinux.conf; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
scriptaddr=0x80000000
soc=am33xx
spiargs=setenv bootargs console=${console} ${optargs} root=${spiroot} rootfstype=${spirootfstype}
spiboot=echo Booting from spi ...; run spiargs; sf probe ${spibusno}:0; sf read ${loadaddr} ${spisrcaddr} ${spiimgsize}; bootz ${loadaddr}
spibusno=0
spiimgsize=0x362000
spiroot=/dev/mtdblock4 rw
spirootfstype=jffs2
spisrcaddr=0xe0000
static_ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off
stderr=serial@44e09000
stdin=serial@44e09000
stdout=serial@44e09000
update_to_fit=setenv loadaddr ${fit_loadaddr}; setenv bootfile ${fit_bootfile}
usb_boot=usb start; if usb dev ${devnum}; then setenv devtype usb; run scan_dev_for_boot_part; fi
usbnet_devaddr=de:ad:be:ef:00:01
vendor=ti
ver=U-Boot 2016.05-g6c5519b6fc (Dec 14 2016 - 19:14:27 -0500)

AM335x는 UBOOT에서 USB RNDIS를 지원을 한다고해서 위와 같은 설정을 해봤다.

http://processors.wiki.ti.com/index.php/Linux_Core_U-Boot_User%27s_Guide#Using_the_network_.28Wired_or_USB_Client.29

7/27/2015

AM437x 관련 기본정보 (TI-GUIDE) --- 추후 삭제

1. CPU의 기본 정보

Sitara는 TI에서 제공하는 OMAP계열의 한 파생 CPU모델이며, CPU의 기본정보는 다음과 같다.

AM437x Series Processors

	AM4379	AM4378	AM4377	AM4376
ARM Cortex-A9 MHz (Max.)	800/1000	800/1000	800/1000	300/800/1000
Graphics Acceleration	3D graphics	3D graphics
PRU-ICSS for slave (Programmable real-time unit and industrial communication sub-system) *	PRU-ICSS + EtherCat® slave	PRU-ICSS	PRU-ICSS + EtherCat® slave	PRU-ICSS
Package **	17x17 / 0.65mm	17x17 / 0.65mm	17x17 / 0.65mm	17x17 / 0.65mm
	Software and pin-for-pin compatible across devices

* PRU-ICSS is commonly used for slave industrial communication protocols such as PROFIBUS, PROFINET®, Powerlink, Ethernet/IP™ and EnDat
** Via Channel Array technology provides 0.8mm-pitch effective layout rules

SOC 세부기능

http://www.ti.com/lsds/ti/processors/sitara/arm_cortex-a9/am437x/overview.page?paramCriteria=no

각 모델별 특징비교

http://www.ti.com/product/am4376

2. TI GUIDE LINE

AM437x 관련 WIKI 정보

TI사에서 제공하는 AM437x에 관한 WIKI정보들이며, SDK 및 RAM , Power Consumption 등 자세한 설정방법 등 메뉴얼을 제공한다.

http://processors.wiki.ti.com/index.php/Category:AM437x?keyMatch=am437x&tisearch=Search-EN-Everything

회로도 체크사항

TI사에 제공해주는 HW 기본적인 Guide이며, RAM과 USB를 , RTC 한번 검토

http://processors.wiki.ti.com/index.php/AM437x_Schematic_Checklist

Power 관련내용

http://processors.wiki.ti.com/index.php/AM437x_Power_Consumption_Summary

3. AM437x 지원 TOOLS

A. OPEN OS 및 TI OS

TI사이트에서 제공하는 SDK는 두종류이며 LINUX SDK와 ISDK (Industrial SDK), 이외에도, Android version을 제공을 한다. 주로 Open OS와 TI 자사 OS를 지원하며, 이 위주로
메뉴얼을 작성.

LINUX SDK
ISDK
ANDROID

B. 상용 OS

이외, 지원하는 상용 OS는 아래와 같으나, SDK or 지원 TOOL 및 메뉴얼 아직 발견을 못했다. 해당 OS사에서 Package 형태로 제공되는 듯하다.

Neutrino
Integrity
Windows Embedded CE
VXWorks

http://www.ti.com/lsds/ti/processors/sitara/arm_cortex-a9/am437x/tools_software.page

C. ISDK (Industrial SDK) 관련기본정보

ISDK에 관한 자세한 내용 아래의 LINK들을 참조.

http://www.ti.com/tool/sysbiossdk-ind-sitara

ISDK 관련 교육 LINK

https://training.ti.com/am437x-industrial-communications-single-chip-drive

ISDK 관련 기본교육 사이트

- Getting Started Guide
   http://processors.wiki.ti.com/index.php/AM437x_SYSBIOS_Industrial_SDK_Getting_Started_Guide

- Release Note
   http://processors.wiki.ti.com/index.php/AM437x_SYSBIOS_Industrial_SDK_02.00.00.02_Release_Notes

- User Guide
   http://processors.wiki.ti.com/index.php/AM437x_SYSBIOS_Industrial_SDK_02.00.00.02_User_Guide

7/26/2015

Sitara(AM437x/AM335x) Uboot와 SPL 분석

1. Open Uboot (Denx)

TI에서 제공해주는 Uboot말고 opensource site(Denx)에 있는 걸로 직접사용을 해보자.
open source u-boot는 아래의 사이트에서 기본으로 제공을 해주고 있다.
아래사이트에서 download를 하여 소스를 받아 간단히 비교 분석해보자.

http://www.denx.de/wiki/U-Boot/WebHome

Tool Chain 설치
https://ahyuo79.blogspot.com/2015/11/arm-tool-chain.html

1.1 board config 설정 및 Build

Board config 확인

$ ls configs/am43*
am43xx_evm_defconfig
am43xx_evm_ethboot_defconfig
am43xx_evm_qspiboot_defconfig
am43xx_evm_usbhost_boot_defconfig

Board config 설정

Kernel 과 동일하게 Board config를 설정

$ make am43xx_evm_defconfig
//.config 가 configs/am43xx_evm_defconfig 기반으로 자동생성 
// Makefile을 보면 CONFIG_xxx 검색설정은 .config 기반  

$ make menuconfig CROSS_COMPILE=xxx 
//Kconfig 기반으로 Menu가 구성되고 최종으로 .config 저장

이제 config가 생성이 되었으니, 아래의 File들을 점검

include/config.h                //  include/configs/am43xx_evm.h  설정확인
include/configs/am43xx_evm.h    // 자신의 Board CONFIG 설정확인 
board/ti/am43xx/board.c         // board_init  분석 및 수정

Uboot Build

$ make CROSS_COMPILE=xxx          //u-boot Image 생성

1.2 General Uboot 기본확인사항

다음과 같이 요약할 수 있다.

1. board config에서 설정확인 (필요하다면 추가 CONFIG , make menuconfig)
2. board init 에서 DRAM TIMING 수정. (DRAM이 변경되었다면)
3. 함수들을 u-boot.map 이나 다른 map로 확인

RAM TIMING만 맞추고 CONFIG만 설정하면 된다.

1.3 일반적인 Uboot 메뉴얼 및 소스

일반적인 Uboot 메뉴얼

http://www.denx.de/wiki/DULG/Manual
http://www.denx.de/wiki/U-Boot/Documentation

Uboot download 및 소스확인

http://git.denx.de/?p=u-boot.git;a=summary

$ git clone git://git.denx.de/u-boot.git

2. TI Uboot와 일반 Uboot 설정 및 빌드비교

TI-Uboot는 기존 Uboot와 거의 기능이 유사하며, mkconfig(shell script)을 사용하여 config 설정하며 이외에도 Uboot에서 제공되지 않는 기능이
CONFIG가 몇개 추가 되었다. 기존에 Open Source에서 사용하던 config 설정에서 약간 변경이 되었다.

2.1 TI Uboot

Makefile

boards.cfg를 참조하며, mkconfig를 실행을 실행하여 설정하고, 빌드시 script와 새로 생성된 만들어진 Makefile Config 파일로 설정하여 빌드한다.

mkconfig

config를 만드는 shell script (TI에서 추가)

boards.cfg

board의 설정 및 정보

Board 설정 및 빌드

$ make am43xx_evm_config // mkconfig 수행 ( 설정시 boards.cfg 참조)
./arch/arm/include/asm/arch
./include/config.h          // GCC CONFIG       , include/configs/am43xx_evm.h 설정 
./include/config.mk         // Makefile CONFIG , ( 둘다 기존과 동일하지만 생성시점이 다르다)

$ make CROSS_COMPILE=xx 
./include/spl-autoconf.mk
./include/autoconf.mk

*다른설정을 원할 경우, boards.cfg 에서 참조
http://processors.wiki.ti.com/index.php/Linux_Core_U-Boot_User's_Guide

2.2 Open Uboot

board 설정 및 빌드

$ make am43xx_evm_defconfig
 .config        //Makefile Config     (TI-UBOOT 다른것으로 mkconfig 대체 )

$ make  CROSS_COMPILE=xx
include/config.h         // GCC       CONFIG    (기존과 동일)
include/autoconf.mk      // Makefile  CONFIG    (기존과 동일)

./include/config/auto.conf   // TI-UBOOT 없음 , Makefile CONFIG 설정 
./include/autoconf.mk       //  Makefile CONFIG 설정 
./include/config.h          //  configs/am43xx_evm.h

이외 부분은 아직 비슷한 FDT 나 SPL기능을 둘다 지원이 가능한 것 같으며,자세한 부분은 소스를 다 분석을 해야 할 것 같다.
http://www.denx.de/wiki/view/DULG/UBootCmdFDT

SPL과 TPL 설정 관련 설명 및 앞으로 변화

Chip Vendor와 상관 없이 Uboot의 설정이 점점 변경이 되고 있으며,TI도 이 흐름에 따라가고 있을 뿐인것 같다.
아래의 문서는 반드시 한번 읽어봐야한다.
http://www.denx.de/wiki/pub/U-Boot/MiniSummitELCE2014/uboot2014_kconfig.pdf

3. TI Uboot Guide

아래는 TI에서 제공해주는 Guide 이며, 반드시 개발하기 전에 읽어야 한다.

TI에서 제공하는 Sitara U-BOOT를 의 종합 기능설명

Sitara U-BOOT Build 및 BOOT모드 설정 및 환경구성 설명이며,
Sitara를 사용한다면, 반드시 한번 읽어봐야한다.
http://processors.wiki.ti.com/index.php/Linux_Core_U-Boot_User's_Guide

AM335x용 UBOOT User Guide

AM335x용 UserGuide로 각 BOOT 모드를 설명 및 Flashing 방법을 설명. (참고용)
http://processors.wiki.ti.com/index.php/AM335x_U-Boot_User's_Guide

ETHERNET 관련설정

http://processors.wiki.ti.com/index.php/Linux_Core_CPSW_User's_Guide

NAND Boot 할 경우 및 NAND 사용할 경우 Guide

http://processors.wiki.ti.com/index.php/Linux_Core_NAND_User's_Guide
http://processors.wiki.ti.com/index.php/Linux_Core_NAND_User%27s_Guide#Board_specific_configurations

4. SPL(Secondary Program Loader)의 개념 및 비교

Uboot에서 MLO , SPL 모르는 용어가 나와서 간단히 다시 Uboot를 대충 다시 분석하기로 했다.
Uboot-SPL은 MLO와 동일한 존재이며, Uboot안에 제공해주는 작은부트로더이다.
기존에 TI에서 제공된 UBL(User Boot Loader) 혹 X-Loader의 기능과 동일하며, 다른점은 Uboot 내에 소스가 포함이 되어 만들어지는 방법이 만들어진다.
이는 오래전에 제공되어진 솔루션(UBL 과 X-Loader)과는 다른점이며, AM437x는 기본적으로 OMAP 플랫폼을 동작되고 있다.

결론적으로 1st Boot Loader 이며,기능은 Uboot의 기능을 제한적사용가능

Boot 순서

SOC(Rom Boot Loader) : SoC에 내장되어있으며, NAND의 1 Block을 읽어온다.
SPL : 1 Block Size의 작은 Boot Loader이며, Uboot 호출
Uboot : Size 문제로 SPL를 사용하여 Uboot를 3번째로 호출된다.

Open Uboot

* SPL( Secondary Program Loader) : 작은 Uboot
* TPL( Tertiary Program Loader) : 보통 Uboot

http://www.denx.de/wiki/pub/U-Boot/MiniSummitELCE2013/tpl-presentation.pdf

For Davinci series (UBL)

* UBL 제공 및 사용 (RBL->UBL->UBOOT) BOOT
* 부가기능- UART BOOT로 Window에서 Flashing 과 loading 기능제공

1. DM644x Dvflasher (RBL -> UBL-> UBOOT) for Davinci series.
http://processors.wiki.ti.com/index.php/RBL_UBL_and_host_program

2. 기존 Davinci Series 와 OMAP-Lx Series 지원 (기능 동일)
http://processors.wiki.ti.com/index.php/Serial_Boot_and_Flash_Loading_Utility

For OMAP series (X-Loader ->SPL)

*초반에 X-Loader를 사용했으나, 이를 SPL 개념으로 변경
*기본개념은 상동
http://omappedia.org/wiki/Bootloader_Project
http://processors.wiki.ti.com/index.php/Boot_Sequence

참고사항

* 다른 CPU UBOOT SPL
http://www.wiki.xilinx.com/U-Boot+Secondary+Program+Loader

4.1 SPL 기본구조

기본 Makfile과 Makefile Config를 분석

 $ vi Makefile
...
ALL-$(CONFIG_SPL) += spl/u-boot-spl.bin
ALL-$(CONFIG_SPL_FRAMEWORK) += u-boot.img
......
spl/u-boot-spl.bin: spl/u-boot-spl
        @:
spl/u-boot-spl: tools prepare
        $(Q)$(MAKE) obj=spl -f $(srctree)/scripts/Makefile.spl all
...

tpl/u-boot-tpl.bin: tools prepare
        $(Q)$(MAKE) obj=tpl -f $(srctree)/scripts/Makefile.spl all CONFIG_TPL_BUILD=y

board config에서 SPL 설정하고 빌드를 진행하면, SPL dir이 새로 생성하게 되며,이 안에 작은 boot loader와 각각의 필요한 *.o, *.su, *.cmd 이 생성이 된다.

.su 파일 과 .cmd 파일기록으로 분석해보면, 기존의 소스로 컴파일 or link해서 사용하는것 같다.

$ cat spl/arch/arm/cpu/armv7/.cpu.o.cmd 
   source_spl/arch/arm/cpu/armv7/cpu.o := arch/arm/cpu/armv7/cpu.c
   xxxxx

$ cat spl/arch/arm/cpu/armv7/cpu.su 
 cpu.c:25:13:cpu_cache_initialization    0       static
 cpu.c:27:5:cleanup_before_linux 8       static

SPL 설정 (DM8127-IPNC예제)

dm8127-ipnc의 config 설정 각각의 설정에 따라, PROMPT를 SPL과 Uboot를 각각 변경하고 MINI Uboot인 SPL이 되어진다.

SPL은 각각의 내부 COMMAND와 별도의 설정가능하며,SPL의 역할은 DDR 설정 및 초기화 기능

$ vi ./include/configs/ti8148_ipnc.h 
#ifdef CONFIG_TI814X_MIN_CONFIG
...
# define CONFIG_CMD_LOADB       /* loadb                        */
# define CONFIG_CMD_LOADY       /* loady */
# define CONFIG_TI814X_CONFIG_DDR
# define CONFIG_TI814X_EVM_DDR3
# define CONFIG_SYS_PROMPT              "TI-MIN#"
....
#else
# include 
# define CONFIG_SKIP_LOWLEVEL_INIT      /* 1st stage would have done the basic init */
# define CONFIG_ENV_SIZE                        0x2000
# define CONFIG_SYS_MALLOC_LEN          (CONFIG_ENV_SIZE + (32 * 1024))
# define CONFIG_ENV_OVERWRITE
# define CONFIG_SYS_PROMPT              "TI8148_IPNC#"

# define CONFIG_MMC                     1
# define CONFIG_NAND                    1

#endif

U-BOOT 내의 Image 구성

$ cd board-support/u-boot-2014.07-g7e537bf
$ ls 
   MLO          : u-boot-spl.bin 의 최종 이미지      확인방법 cat .MLO.cmd  (동일한 존재)
   
   spl          : SPL 관련링크 및 Image 파일 
   
   u-boot.img   : U-BOOT bin 최종 파일               확인방법: cat .u-boot.img.cmd 

   xxx  (중략)

su file 관련내용

su file은 static stack의 사용량 분석하는 파일이니, 참고만 하면 되겠으며, 이 file로 최대 stack 사이즈를 알려고 하는 것 같다.

su file 관련내용
https://gcc.gnu.org/onlinedocs/gnat_ugn/Static-Stack-Usage-Analysis.html

su file 생성 관련수정 (Makefile 연계)
http://lists.denx.de/pipermail/u-boot/2014-February/172622.html

SPL 관련 문서

Uboot안에 SPL 관련문서를 제공
./doc/README.SPL

4.2 SPL 사용방법

TI-UBOOT는 Makefile CONFIG를 두개로 따로 관리(자동생성)를 하여, 관리하지만, 만약, SPL 관련 수정을 한다면, boards.cfg를 봐야할 것 같다.

Makefile은 (mkconfig 실행 와 boards.cfg 참조) Board Config들을 보려면 아래사항을 확인 해야할 것 같다.

Board Configuration

./include/configs/am43xx_evm.h
./include/configs/ti_armv7_common.h //SPL 관련 설정
// 위 Config 파일을 보면 각각 설정이 가능함.


//USB BOOT Mode일 경우 변경
          #define CONFIG_SPL_TEXT_BASE   0x402F4000     // SRAM 위치 , Link Sript 참조.
          #define CONFIG_SPL_MAX_SIZE             (220 << 10)     /* 220KB */
          #define CONFIG_SYS_SPL_ARGS_ADDR        (CONFIG_SYS_SDRAM_BASE + \
                                         (128 << 20))

          #define CONFIG_SPL_BOARD_INIT
          #define CONFIG_SPL_POWER_SUPPORT
          #define CONFIG_SPL_YMODEM_SUPPORT

Makefile의 CONFIG 파일 구성

./include/autoconf.mk       // CONFIG_SPL=y 선언
./include/spl-autoconf.mk  // CONFIG_SPL_BUILD=y 선언

SPL 빌드과정

U-BOOT의 CONFIG .config에 CONFIG_SPL=y 설정 할 경우
Makefile 안의 spl/u-boot-spl 에서 Makefile.spl이 spl-autoconf.mk 생성
SPL은 이 부분을 참조하여 빌드를 한다.

*CONFIG_SPL_BUILD=y //SPL 관련 Makefile CONFIG 이부분은 SPL문서 참조.

4.3 SPL 관련파일

SPL 관련자료는 board config에서 *CONFIG_SPL_BUILD=y 사용하겠다고 명시를 하면, 아래와 같이 기본기능과 각 BOOT MODE 맞게 생성이 되는 것 같다.
BSP 혹은 uboot version에 따라 조금씩 다른것 같다.

SPL의 기본소스

SPL의 기본소스는 존재하지만, U-BOOT와 공통되느는 부분은 동일하게 외부에서 가져다 쓰기에 이곳에 존재하지 않는다.

common/spl/

 $ vi common/spl/Makefile 
  11 ifdef CONFIG_SPL_BUILD
  12 obj-$(CONFIG_SPL_FRAMEWORK) += spl.o
  13 obj-$(CONFIG_SPL_NOR_SUPPORT) += spl_nor.o
  14 obj-$(CONFIG_SPL_YMODEM_SUPPORT) += spl_ymodem.o
  15 obj-$(CONFIG_SPL_NAND_SUPPORT) += spl_nand.o
  16 obj-$(CONFIG_SPL_ONENAND_SUPPORT) += spl_onenand.o
  17 obj-$(CONFIG_SPL_NET_SUPPORT) += spl_net.o
  18 obj-$(CONFIG_SPL_MMC_SUPPORT) += spl_mmc.o
  19 obj-$(CONFIG_SPL_USB_SUPPORT) += spl_usb.o
  20 obj-$(CONFIG_SPL_FAT_SUPPORT) += spl_fat.o
  21 obj-$(CONFIG_SPL_EXT_SUPPORT) += spl_ext.o
  22 obj-$(CONFIG_SPL_SATA_SUPPORT) += spl_sata.o
  23 endif

빌드 후에는 uboot/spl 에 모든 파일이 생성.

U-BOOT 설정

기본적으로, make board_config를 한 후에 가능

$ vi .config        // U-BOOT EVM CONFIG 설정  
$ vi ./u-boot.cfg   // U-BOOT Build 된 후 아래 CONFIG와 관련 CONFIG 전부  

$ vi ./spl/include/autoconf.mk  // U-BOOT-SPL, MLO의 설정 확인 
$ vi ./spl/u-boot-spl.cfg       // Build 된 후 CONFIG 포함

U-BOOT SPL 설정

$ vi ./spl/include/autoconf.mk  // U-BOOT-SPL, MLO의 설정 확인 
$ vi ./spl/u-boot-spl.cfg       // Build 된 후 CONFIG 포함

4.4 TI-SPL을 적용한 BOOT MODE

AM437X는 다양한 BOOT MODE를 제공하지만, 일단 기본적인 BOOT인 MMC와 NAND 보겠다.

자주사용할 Boot Mode

MMC BOOT (SD Card)
NAND BOOT

기본 부팅순서

ROM Bootloader, (IPL, Initial Program Loader or (PPL, the Primary Program Loader)
The binary for the (SPL, Secondary Program Loader) or the MLO.
The binary for U-Boot (TBL, Tertiary Program Loader)

NAND일 경우, PPL이 NAND 1st ~ 4th block 몇개를 SPL 찾기위해 검색을 Bad Block 생각해서, 그리고, SPL 진행하고 초기화

MMC와 USB일 경우, PPL이 FAT를 Mount하는 기능이 추가되어, SPL 파일을 찾아,SPL(MLO)를 진행하고 초기화

부팅관련용어 및 내용
http://elinux.org/Boot_U-Boot_from_UBI_volume

5. Boot Mode 기본분석 및 Memory Map

NAND BOOT 구조

NAND BOOT일 경우, 아래와 같은 구조로 구성이 될 것 같다.
아래는 AM33xx 인 경우 NAND 구조이며, SPL과 U-Boot.img Kernel 위치를 알수 있다.

+------------+-->0x00000000-> SPL start         (SPL copy on 1st block)
|            |
|            |-->0x0001FFFF-> SPL end 
|            |-->0x00020000-> SPL.backup1 start (SPL copy on 2nd block)
|            |
|            |-->0x0003FFFF-> SPL.backup1 end 
|            |-->0x00040000-> SPL.backup2 start (SPL copy on 3rd block)
|            |
|            |-->0x0005FFFF-> SPL.backup2 end 
|            |-->0x00060000-> SPL.backup3 start (SPL copy on 4th block)
|            |
|            |-->0x0007FFFF-> SPL.backup3 end
|            |-->0x00080000-> U-Boot start
|            |                                    
|            |-->0x002BFFFF-> U-Boot end 
|            |-->0x00260000-> ENV start
|            |
|            |
|            |-->0x0027FFFF-> ENV end
|            |-->0x00280000-> Linux Kernel start
|            |
|            |
|            |
|            |
|            |-->0x0077FFFF-> Linux Kernel end
|            |-->0x00780000-> File system start
|            |
|            |
|            |
|            |
|            |
|            |
|            |
|            |
|            |
|            |
|            |
|            |
+------------+-->0x10000000-> NAND end (Free end)

http://processors.wiki.ti.com/index.php/AM335x_U-Boot_User's_Guide

MMC와 eMMC 와 USB BOOT MODE일 경우 구조

Partition-1: FAT32: MLO(SPL) 와 u-boot.img
Partition-2: EXT3: Linux File system
(* fdisk로 각 파티션을 만들고, 분할)

Linker Script 확인

SPL때문에 Link Script을 다시 확인하게 되었지만, 기본 Link Script가 에서 다시 설정이 되어, spl directory에 최종결과물이 생성이 된다.

기본 확인방법 (Board Config)

$ vi include/configs/am43xx_evm.h 
...
#define CONFIG_SPL_LDSCRIPT  "$(CPUDIR)/omap-common/u-boot-spl.lds"
...
$ cat arch/arm/cpu/armv7/omap-common/u-boot-spl.lds //linker script 확인

https://sourceware.org/binutils/docs-2.25/ld/index.html
http://www.math.utah.edu/docs/info/ld_3.html

5.1 AM335x 관련정보

AM335x AM335x EVM-SK Info

http://processors.wiki.ti.com/index.php/AM335x_Starter_Kit
http://processors.wiki.ti.com/index.php/AM335x_Starter_Kit#Hardware_Documentation

AM335x EVM-SK 진단용

추후 QC Program응용가능
http://processors.wiki.ti.com/index.php/AM335x_Starter_Kit_Diagnostics

AM335x Battery Pack

http://processors.wiki.ti.com/index.php/AM335x_Starter_Kit_Battery_Pack

AM335x EVM-SK JTAG (XDS-100 V2) 설정

현재 이 EVM JTAG Header가 없다고해서 사용못한다고 한다. 설정방법
http://processors.wiki.ti.com/index.php/Starter_kit_jtag

AM335x SD Boot 일 경우 참고사항

http://processors.wiki.ti.com/index.php/Linux_Core_U-Boot_User's_Guide#Partitioning_eMMC_from_U-Boot

현재 SD Boot할 경우, Sandisk 16GB Class10 인 경우 제대로 동작이 안되지만, 기본적으로 ICS 4.0.3 포함한 SD Disk는 잘동작한다.
원인은 MLO에서 MMC를 정확히 인식을 못하는 것 같다.
http://processors.wiki.ti.com/index.php/TI-Android-ICS-4.0.3-DevKit-3.0.1_UserGuide#SD_Card_Recommendations

U-Boot SPL 2016.05 (Feb 20 2017 - 16:27:15)
Trying to boot from MMC1
** First descriptor is NOT a primary desc on 0:1 **
** Partition 1 not valid on device 0 **
spl_register_fat_device: fat register err - -1
** Partition 1 not valid on device 0 **
spl_register_fat_device: fat register err - -1
spl_load_image_fat: error reading image u-boot.img, err - -1
spl: no partition table found
spl: no partition table found
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

https://en.wikipedia.org/wiki/Secure_Digital#Micro

7/24/2015

CCS v6 기능확장 for Linux

1. CCS Debug

아래의 사이트 Modules Library 에서 원하는 CPU에서 각각의 모듈의 지원을 확인하자.

TI Main Wiki 관련문서 검색

관련 모드자료를 쉽게 검색이 가능하며, Training 에 가면 본인의 MPU에 맞게 훈련이 가능.
TI에서 제공하는 MCU들의 정보들을 그룹별로 간단하게 파악이 가능하다

http://processors.wiki.ti.com/index.php/Main_Page

TI Traning 관련자료

상위 Main-> Training 이며, 본인이 사용하는 MCU에 관한 Training 자료가 있으니,
반드시 참고하고 숙지해야 할 것 이다.

http://processors.wiki.ti.com/index.php/Hands-On_Training_for_TI_Embedded_Processors
https://training.ti.com/search-catalog/categories/products

TI CCS V6 Training 정보 및 CCSV6 칩 별로 기능지원확인

http://processors.wiki.ti.com/index.php/Category:CCSv6_Training#Videos

1.1 CCS or Eclipse LINUX Debug 구성

CCS는 기본적으로 Eclipse으로 기반으로 구성되어있기 때문에, 동일한 부분이 상당히 많으며, Eclipse를 나누어서 공통으로 생각해야 할 부분이 많다.

Linux 기본 Debugging 구성

App은 Gdb와 Gdbserver
Kernel JTAG을 이용한 Debug이지만, CCS에서 vmlinux로 실행

상세한내용은 아래의 TI에서 제공해주는 PPT 자료를 한번보자

http://processors.wiki.ti.com/index.php/CCS_Modules_Library#Linux_Debug
http://processors.wiki.ti.com/index.php/Linux_Debug_in_CCSv5

View->Other->Profiling (eclipse에서 기본제공)

gcov
gprof

1.2 Linux Tools Install (CCS or Ecplise에 설치)

Eclipse or CCS 동일하며, Linux Tools 라는 Profile Program을 제공을 해준다.
Valgrind, OProfile, RPM, SystemTap, GCov, GProf, LTTng의 기능을 제공을 해준다고 하는데, 이미 GCov와 GProf 기능은 존재한다.

Valgrind Heap Memory Profile 해주는 Tool , OProfile, SystemTap, LTTng 기능을 사용하고 싶지만, 아직 사용을 못해봤다.
하지만 설치는 가능하다.

관련설명
http://www.eclipse.org/linuxtools/

Help->Install New Software

1. Available Software Sites에서 현재 추가된 Site 확인가능

2. Linux Tools update Site 추가

Add 로 사이트 추가
Name : Linux Tools
Location: http://download.eclipse.org/linuxtools/update/

Linux Tool Package 설치방법

https://wiki.eclipse.org/Linux_Tools_Project/PluginInstallHelp

Linux Tool Download (강제설치 방법)

Linux Tool 관련 zip 파일 Download 한 후 상위에서 동일하게 Add로 추가
Archive Menu를 이용하여 직접 추가 한 후 강제로 설치
http://www.eclipse.org/linuxtools/downloads.php

Help->Install Details

Update or 설치된 Package를 제거 가능하다.

Help->Eclipse Marketplace

Eclipse에서 많이 사용되어지는 Package를 설치가능하고 최신 Package도 적용해보자.

PyDev (Python IDE)
Vrapper (Vim)

CCS를 Eclipse 처럼 동일하게 많이 이용하여 좋지만 CCS에는 TI에서 제공해주는 많은 Package도 설치하여 동작하기 때문에
가능하면 CCS의 본연의 기능으로 이용하는 것이 좋을 것 같다.
예를들면, TI의 Compiler version Package 문제로 빌드오류 발생 문제든지, 다른 Package로 문제성이 있겠다.

1.3 Kernel Debug on Window CCS

KERNEL DEBUG 환경설정 (요약)

Kernel Debug을 위해서는 JTAG을 사용하는데, zImage를 사용하지 않고, debugging을 포함한 vmlinux elf 포맷의 이미지를 사용한다, 그리고,
이를 CCS에서 Run->load -> Load Sysmbols로 ARM CPU에 올려준다.

이를 View->Modules 에서 올라간 vmlinux를 간단히 확인가능하지만, TI Reference 처럼 실행을 할 수가 없다.

참고로, KERNEL Source에서 menuconfig 할때에는 아래와 같이 ARCH를 넣어줘야함.
만약, 매번 넣기 귀찮다면, export 이용하거나 source를 이용함.

$ make ARCH=arm menuconfig
      Kernel hacking-> 필요한 debug 선택

다시 Kernel을 build 후 vmlinux 사용하기위해 u-boot 설정을 변경한다.
문제는 fdtfile을 사용하기에, kernel 의 arch/arm/mach-omap2에서 board-generic.c를 사용한다.
(DT_MACHINE_START(AM43_DT, 이곳에 breakpoint를 걸지라도 fdtfile 필요하다. )

1.4 Kernel Debug on Linux CCS

기본적으로 유사하지만, 이클립스에서 source를 Project를 만들어 hw breakpoint를 만들수 있다. 하지만 이클립스에서 Project를 만들 경우, kernel 및 uboot 소스가 변형이 된다.
그러므로, 이부분은 주의해야한다.

특히 커널은 메뉴가 x86로 자동으로 설정이 되어서, 에러가 발생이 된다.

TI LINUX DEBUG

최근에 새로 찾은 사이트이며, 아래 사이트가 정리가 잘되어있기에, 너무 좋음
TI 기본적으로, LINUX에서 CCS를 설치하는 것을 권장하는 것 같음

관련설정
http://processors.wiki.ti.com/index.php/Sitara_Linux_Training:_uboot_linux_debug_with_ccsv5

Linux Board Porting 관련 동영상

TI에서 제공해주는 Linux Porting Guide , 개발환경설치 Guide

https://training.ti.com/search-catalog?keyword_op=AND&keywords=Linux+Board+Porting+Series&start%5Bdate%5D=&end%5Bdate%5D=

7/23/2015

CCS v6 기본 사용법

1. CCS v6 의 모드 및 전체구성

TI에서 CCSv6는 Window과 Linux Version을 동시제공하며, 둘다 비슷하게 기능을 제공을 하고 있는 것 같다.
기본적으로 Linux 기반으로 개발을 한다면,Linux Version으로 사용해야 완벽한 Debugging을 사용하는 것 같다.

Linux 기반 설치는 아래의 설치 메뉴얼을 보자. (설치를 해봤지만, Virtual Box로 불편하다)
Window version으로 Samba로 연결하여 동작하려고 해보려고 했으나, 추후 시간이 있을 경우 시도.

CCS v6 모드설정

CCS는 상단우측에 3개의 모드로 구성하며 ,각 모드마다 창을 볼수 있는 권한이 정해져 있다.
처음 접하면 혼란스러울수 있으나, 사용하다보면 익숙해지고 편해질 것이다.
나의 경우는 3모드로 구성을 했지만, 본인이 추가를 한다면 몇개의 모드로도 구성이 가능하다.
하지만 모드가 많아질수록 헷갈리며, 추가되는 모드와 상단의 아이콘이 겹치므로, 가장 좋게 구성하는 것은 아래와 같이 구성하는 좋을 것 같다.

CCS의 모드구성

CCS Edit: 프로젝트관리 및 소스관리와 빌드 그리고, Target 설정 , Console
CCS Debug: CCS가 Target과 연결된 후 각종 정보를 얻으며, Debugging 하는 모드
CCS Simple: 상위 두창을 간단히 필요한 내용을 조합한 메뉴. (옵션)

1.1 CCS Edit 기본구성

CCS Edit모드의 기본구성은 CCS Project의 소스수정과 빌드 및 Target Board관리정도로 생각을 하면 될 것 같다. (BreakPoint 설정 및 관리)

CCS Edit의 사용용도

Target Configuration으로 Target Board 관리
CCS의 Project 소스 관리 및 빌드
CCS의 Project의 Index설정 ( 소스분석용이)
CCS의 Project의 소스편집 및 Breakpoint 설정

Index 관리 및 설정

Eclipse에 이는 기본기능이며 소스분석을 이용하여 쉽게 Call 흐름 분석 및 관련함수로 이동이된다.
아래와 같이 둘중 하나로 설정을 하며 Index File이 생성이 된다.

Project->C/C++ Index->Freshed All Files
Project Explorer를 이용하여 우측 마우스에서 Index 설정

CCS Edit 모드의 관련메뉴

File /Edit /View /Navigate /Project /Run/Scripts /Window /Help

CCS Edit 관련 창(View) 기본설정 (나의 경우)

View->Project Explorer
View->Target Configuration
View->Console
View->Problem
View->Advice
View->Outline
View->Debug
View->Others->C/C++

이외에도 본인이 원하면 관련부분을 세부 설정이 가능하며, GIT창을 추가도 가능하다.
Eclipse 의 사용해본 유저라면 쉽게 적응이 갈 것이며, Eclipse의 기본기능이라고 생각하면 되겠다.

1.2 CCS Debug 구성

CCS Debug 모드의 경우는 JTAG에 연결되었을 때 가능한 작업이며, 관련창도 이에 관련해서 구성을 하자

CCS Debug의 사용용도

설정된 Breakpoint 및 새로운 Breakpoint 설정
MPU의 Memory 정보확인 및 분석
Disassembly를 이용하여 정확한 기능확인
ARM의 Register 관련 확인 (e.g pc or ARM Mode)
Debug를 위해 Stack 및 전역변수 Debug

CCS Debug 모드의 관련메뉴

File /Edit /View /Project /Tools /Run /Scripts /Window /Help

CCS Edit 관련 창(View) 기본설정 (나의 경우)

View->Debug
View->Console
View->Memory Browser
View->Breakpoints
View->Registers
View->Disassembly
View->Expressions
View->Variables
View->Other->Debug

1.3 CCS의 Simple 모드

CCS의 Simple 모드의 경우는 나의 경우는 소스 분석전 필요한 것들을 쉽게 정리하거나, 관련보드 설정을 할수 있도록 구성을 한다.
그래서 필요한 것을 확인할 경우 본인이 원하는 것을 이곳에 넣자.

예를 들면 아래와 같이 필수적인 것 하나만을 넣어 구성을 하자 , 만약 필요없다면 이 모드는 사실 필요가 없다.

CCS 관련 설정 Update (CCS App Center, Getting Started )
Target Board의 상태관리 (Target Configuration)
CCS의 Project 의 관리

CCS Simple 모드의 관련메뉴

File /Edit /View /Project /Scripts /Window /Help

2. CCSv6 관련메뉴 설명

기본구성의 자세한 설명은 상위 TI-사이트를 참조하면 될 것 같으며, Getting Started를 보면, 아래는 주로 교육을 위는 App 자료로 구성이 되어 있다.

Project 메뉴기능은 이곳에서 생략하고, 이 부분은 빌드와 관련된 부분이기때문에 추후 다시 설명하도록 한다.

2.1 View Menu

CCS or Eclipse에서 제공해주는 View기능으로 대부분 모든 메뉴에서 설정은 가능하지만, 제한적이다.
상위에서 설명했듯이 JTAG이 연결되어 Debugging 모드로 동작했을 때 동작되는 View들이 존재하기 때문이다.

주요 Project 관리 및 빌드 창(View)

View->Project Explorer : 프로젝트 관리 및 Index 실행
View->Console : 빌드 상황 및 프로그램 실행 및 JTAG의 상태.
View->Problem : 빌드시 문제사항 및 기타 문제사항을 보고
View->Advice : Problem에 문제발생시 Advice를 볼수 있다.
View->Outline : 소스분석시 용이하게 관련함수를 보여준다.

Target Board 설정 및 상태 창(View)

View->Target Configuration : Target 설정 및 연결
View->Debug : Target의 Connection 및 Debug
View->Memory Browser : MPU에 연결된 DRAM(Memory) 상태확인
View->Registers : ARM Registers 정보 확인
View->Script Console : Script를 이용하여 Target의 정보를 볼수 있다.

** Target Configuration 중요하기 때문에 이부분은 별도 자세히 설명

CCS Debug 관련설정 창(View)

View->Memory Browser : Memory 정보비교 및 저장, 수정 , Symbol Table
View->Registers : ARM Register 정보 확인 및 ARM Mode , PC확인
View->Script Console : Script를 이용하여 Target의 정보를 볼수 있다.
View->Expressions : 소스의 전역변수 및 본인이 원하는 것을 조합가능
View->Variables : 소스의 Local 변수 및 Static 변수 Debug
View->Disassembly : 소스의 Assembly Code 분석
View->Breakpoints : JTAG Breakpoint 설정 및 Breakpoint 관련 Event
View->Modules : COFF 파일의 Symbol Table 및 관련분석
View->Other->Debug : 세부 Debug를 위해 사용하는 창
View->Other->Tracing : 아직 사용해보지 못함

Debug모드로 동작할 경우 , JTAG을 이용하여 a.out(COFF)를 MPU Memory에 로딩한 후 벌어지는 상황이다.

**Registers
주로 ARM계열을 사용을 할 것이지만, 다른 MPU를 사용한다면 해당 Register들이 표시가 될 것이다.
ARM으로 한다면, 당연히 ARM Mode와 기본 Register들의 이해가 필요하다.
또한 현재 실행 되는 부분을 ARM의 PC를 이용하여 변경하여 재실행도 가능하다.

**Modules
ELF는 아직 테스트를 못해봤으며, TI에서 제공되는 Compiler가 A.out(COFF) 만 지원하기 때문에 이를 이용하여 확인했으며, linux에서 readelf 정도라고 생각하면되겠다.

**Breakpoints
JTAG을 이용하여 Breakpoint 지점을 설정할 수 있며, 좀 더 세부적으로 사용하고 싶다면 관련설정을 변경하여 다른 것과 같이 사용해보자.
예를들면, Breakpoint가 꼭 멈추는 것이 아니라, 횟수 및 다른 Debug와 연결을해서 분석을 해보는 것이다

**Variables
Breakpoint와 함께 설정된 해당 함수의 Local 변수 및 Static 변수를 관찰하고 이를 Debug한다. (Stack 영역)

** Expression의 확장사용
Debug 모드로 동작할 경우, Expressions는 전역변수(Symbol Table)를 확인가능하며 본인이 별도로 설정하여 이를 지속적으로 관찰이 가능하다.

예를들면 전역변수 or 특정 Register를 지속적으로 감시하고 싶다면아래와 같이 설정해보자.

Add new expression
관련 전역변수 추가 ( Structure 추가시 관련부분 확인가능) or 본인이 아래와 같이 직접설정

본인이 아래와 같이 직접설정

*(unsigned int *)0x1112222
*(unsigned int *)(0x1112222+11)

원래 기본 Type은 int이지만 상위처럼 본인이 변경가능하며, Value도 Hex 및 Dec로 변경가능

https://www.youtube.com/watch?v=I1uwIgzNvNA
https://www.youtube.com/watch?v=JlHLqzsb3D4

CCS의 추가기능지원 (**중요)

View->CCS App Center : CCS의 Compiler 설치 및 기능 추가
View->Getting Started : CCS의 처음 시작할 경우 관련설명

Project or 설정을 하다보면, 지원을 못하는 Compiler or 추가기능을 이곳에서
설치 가능하다.

View->Other

다양한 기능 제공을 제공하고 있으며, 이부분은 Eclipse CDT와 거의 유사하지만, CCS에서만 제공되는 기능이 존재하고, Eclipse의 기능도 이용도 가능하다.

Remote Systems->Remote Systems : SSH및 SFTP 설정가능
Terminal->Terminal : RS-232 설정 가능
Debug->MMU Page Table
Debug->Pin Connect, Port Connect
Debug->Target Status
Debug->Memory Browser
Debug->Registers
Debug->이외 다양한 기능
Git : Git download , compare
기타 많은 기능을 포함하고 있다.

2.2 Tools Menu

CCS Debug 모드에서만 제공하는 Menu이며, Debugging 용도로 사용이 되고
각 정보상태를 확인 및 확인한다.

Tools->ARM Advanced Features : MMU ON/OFF , Cache Control 및 기타 ,
Tools->Gel Files : 현재 Gel 파일의 상태 알수 있다.
Tools->Memory Map : MMU의 Mapping 된 정보 확인
Tools->Pin Connect : 추후 사용해보고 수정
Tools->Port Connect : 추후 사용해보고 수정
Tools->Console : Console 기능 사용

Console : JTAG 의 Error 및 내부 관련 Message를 볼수 있으므로, 반드시 필요한다.

Tools->Runtime Object View (Debug 방법)

https://www.youtube.com/watch?v=MI_2iM2WbU8&t=101s

Pin Connect

http://processors.wiki.ti.com/index.php/Pin_Connect
http://processors.wiki.ti.com/images/1/10/Pin_connect.pdf

2.3 Run Menu

CCS Edit 와 CCS Debug 모드에 존재하지만 두 모드간의 Run 메뉴구성은 다르다.
기본목적은 Target Board를 연결과 실행과 직접 Debugging을 다루며
a.out/elf 를 load하여 실행도 가능하도록 하는 것이다.

Run->Connect /Disconnect : 상위 아이콘으로 존재하며 Target Board와 연결
Run->Load : A.out/ELF 파일 Load ,Symbol table 지원 및 미지원
Run : Load 한 파일 실행 및 Control 및 Debug

2.4 Script Menu

모든메뉴에서 사용이 가능하며, 주로 GEL 파일의 선택이 가능하다.

2.5 Window Menu

각 창의 설정을 독자적인 하고 싶거나, CCS의 전체 설정을 전반적으로 다루고 있는 부분이다.
본인이 새로운 창을 구성하고 싶다면 이곳을 이용해야한다.
이 부분은 중요 한곳이기에 추후 별도로 설명

3. Target Configuration 설정 과 JTAG 연결

CCS에서 Target Board와 연결하기 위해서는 JTAG이 필요할 것이다.
우선 필요한 정보는 본인의 Target Board의 정보와 JTAG의 정보이다. .

많이 사용되는 JTAG

- 아래의 모델 숫자가 증가할 수록 JTAG의 TCLK 설정가능 및 에러율은 적고 커넥션하기가, 용이하다.

XDS100
XDS510
XDS560

3.1 Target Configuration 생성 및 설정 (ccxml 생성)

CCS에서 제공하는 JTAG을 이용하여 Target board에 접속하기 위해서는 이 작업이 필수이며 관련된 자료가 필요하다.

CCS Debug or CCS Edit에서 가능하지만, 가능하면 CCS Edit에서 진행하자
아래의 절차대로 설정하고 변경을 하자.

Target Configuration 창 설정

Target Configuration 창이 없다면, view->Target Configuration생성
Target Configuration 창에서 본인이 만든 *.ccxml 파일을 더블 클릭

Target Config 생성방법 (둘 중 하나 선택)

File->New->Target Configuration File 선택
Target Configuration 창에서 User Define->New Target Configuration 선택

New Target Configuration 선택

(*.ccxml)->Basic 기본설정

좌측의 *.ccxml 파일을 Target 이름변경 (e.g AM335x.ccxml, DM368.ccxml)
ccxml 파일 선택하면 Basic/Advanced/Source 세부메뉴 설정가능
Basic을 선택
General Setup의 본인 JTAG 설정과 Board 설정
우측의 TEST Connection (JTAG SCAN TEST 진행 , 문제 발생시, 3.4 확인 )

Basic->General Setup

Connection : 510 or 560 , Others Emulator ( JTAG 설정)
Board or Device: Target Deivce 설정 현재 사용중인 Device 설정 ( MPU 설정)

Basic->Advaced Setup

Save Configuration-> Save
Test Connection ( JTAG이 Connected가 된경우가 동작이 됨)

새로생긴 CCXML 파일의 설정을 확인 (Connection / Board or Device)

본인의 JTAG을 설정 및 TEST Connection 진행

*.ccxml 의 세부 설정구성

Basic : JTAG 설정/ Board 설정/ JTAG SCAN TEST
Advanced : 각 CPU에 GET File 설정 가능
Source : XML 전체 소스 확인

Advanced->Target Configuration

보통 기본 GEl 파일이 제공되지만, Gel파일을 변경을 원할 경우, 아래와 같이 변경한다.

ARM9 선택
CPU Properties -> initialization script : GEL 파일 설정 및 변경

아래의 그림처럼 GEL파일 설정 한 후 Script에서 설정가능

http://processors.wiki.ti.com/index.php/GSG:Adding_GEL_files_to_a_target_configuration_v5

3.2 Custom Target Configuration

이부분은 거의 사용할 일 없을 것 같은데, Target Configuration의 내부 Deivce를
본인이 직접 세부적으로 설정하여 만드는 것이다.

이전 CCS에서도 이 기능을 이용하여 본인이 직접 설정하였다.

http://processors.wiki.ti.com/index.php/Target_Configuration_-_Custom_Configurations

3.3 Target Configuration Update

Help->Check For Update

http://processors.wiki.ti.com/index.php/Updating_CCSv6

아래 사이트를 이용하여 XML을 Download 후 CCS 에 추가하자

http://processors.wiki.ti.com/index.php/Device_support_files

Automotive File XML and GEL Download

http://processors.wiki.ti.com/index.php/Device_support_files?keyMatch=Automotive%20device%20support&tisearch=Search-EN#Automotive

3.4 Target Configuration JTAG TEST 문제생길 경우

[Start: Spectrum Digital XDS510USB Emulator_0]

Execute the command:

%ccs_base%/emulation/drivers/sdjtag.exe -f %boarddatafile% -v -X reset -X scantest

[Result]

** BoardFilePath: C:\Users\JHLEE\AppData\Local\TEXASI~1\CCS\ti\0\0\BrdDat\testBoard.dat
** Resetting Emulator
     ERROR -- XDS510USB Reset Failed
     ERROR -- Check power to your emulator/eZdsp
     ERROR -- Then check your port address

[End: Spectrum Digital XDS510USB Emulator_0]

에러 해결방안

JTAG 다시 연결 후 Test Connection 진행
JTAG USB Driver 인식 확인
TCLK 설정변경방법

http://processors.wiki.ti.com/index.php/Debugging_JTAG_Connectivity_Problems

CCS V3.3과 Target Config 호환성

기존의 CCS V3.3의 Setup과 동일하며, 다만 확장자가 달리 변경이 되었다.
Target을 설정하고, Launch를 하면 자동으로, CCS Debug로 화면이 이동한다.
기본 동작방식은 CCS V3.3과 유사하다.

CCS V3.3 Target Config File: *.ccs
CCS V6 Target Config File: *.ccxml

C:\Program Files (x86)\SpectrumDigital\Emulation\Drivers

4. Target Configuration Launch / Debugging

CCS의 상위 Taget JTAG 설정완료 되었으니, 이제 Target Board와 직접연결하여 해보자

Target Board 와 연결

Target Configurations의 창에서 해당 *.ccxml 파일 선택 후 우측버튼 클릭
Launch Selected Configuration 실행 (아래 그림 참조)
Debug 창에서 Launch 된 *.ccxml 파일 확인
CPU가 여러 개 일수 있으므로, 개별 CPU를 Connect Target
GEL 파일도 참고해서 볼수 있다.

아래와 같이 쉽게 그림으로 보자.
Target Configurations 창에서 설정한 target.ccxml 파일의 마우스 우측버튼이용.

** Target.ccxml-> Launch Selected Configuration

Launch Selected Configuration 선택

제대로 Launch가 되었다면, 우측 창의 Debug에 Launched Target Configuration의 Status를 볼수 있다. ( *.ccxml)
기본 상태는 Disconnected 이며 이를 이제 Connect Target를 이용하여 Target Board와 연결하자.

Target과 Connected가 된 후에는 CCS Debug 창을 이용하자

**해당 ARM Core -> Connect Target

아래는 DM368

아래는 AM335x의 연결상태

4.1 Script 메뉴에서 GEL 선택

상위 Target Configuration에서 설정된 GEL파일은 Target과 Connected과 된상태라면, Scirpt 메뉴에서 GEL 파일의 이용이 가능하다.
GEL 파일은 TI에서 제공해주는 Script파일이며, MPU의 쉽게 초기화 해주고 설정해주는 Script라고 생각하면되겠다.

Script->GEL 선택가능

아래와 같이 Video의 Color_bar TEST를 제공해주는 GEL File
아래와 같이 hotmenu로 제공되는 script들을 실행을 해보자.

4.2 a.out or ELF 실행

Target과 Connected과 된 상태라면,
CCS에서는 A.out 파일의 포맷을 실행파일을 실행이 지원이 가능하다.
이를 Run->Load 하여 Load 한 후에 Run을 이용하여 실행하자.

5. CCS Debug 모드

CCS Debug 모드는 Target과 Connected를 한 후에는 주로 이용을 되며,
CCS v3.3의 Main프로그램과 동일하게, Gel을 Control 할 수 있으며,

Reset 및 Load Program 및 Run이 가능하다.

5.1. Memory Browser

Connect 가 된후 View->Memory Browser 에서 원하는 Register 및 Data를 손쉽게
변경이 가능하다.

5.2 Gel Script 사용

Gel 파일의 Script를 사용하고 싶다면, 상위 Debug창에서 Connect Target 한 후
Scripts->선택 하여 Gel 파일의 함수를 이용하자

http://processors.wiki.ti.com/index.php/GEL

5.3 Target Reset

기본적으로 Reset이 제공이 되며, 모듈 Reset도 가능하다.
Run->System Reset

부분 모듈만 Reset 하고 싶다면, View->Registers 통해 모듈 Reset를 하자

5.4 Linux Kernel에서 Register 확인

Linux Kernel은 기본적으로 MMU를 사용하여 virtual address를 이용한다.
그래서 만약 직접적으로 register를 확인하고자 한다면, MMU기능을 OFF하고 확인이 가능

A. UBOOT 동작확인

우선 U-BOOT에서 기본적으로 확인해보자.
(Debug 창으로 이동)

Target Disconnect 상태 유지
U-BOOT Booting 확인
Connect Target 을 하면, CPU의 상태는 자동으로 Suspended로 변경
Run->Resume 으로 CPU의 상태를 Run으로 변경
U-BOOT 동작 확인

B. KERNEL 동작확인

Linux Kernel이 동작하면 MMU가 ON이 되어, MPU의 Register들을 볼수가 없다.
임시방편으로 보고 싶다면 MMU를 잠시 OFF하면 MPU의 Register 상태를 볼수가 있다
다만, Linux Kernel은 제대로 돌아가지 않는다.

Target Disconnect 상태 유지
Kernel Booting 후 보고 싶을 때, Connect를 시도
CPU의 상태는 Suspended로 변경되는 것을 확인
Tools -> ARM Advanced Features -> MMU Enabled ( OFF)
View->Memory Browser 창 에서 본인이 찾고자하는 Register 확인 및 Data 확인
Tools -> ARM Advanced Features -> MMU Enabled (ON)
Run -> Resume 변경 하고 CPU의 상태가 Running되는 것 확인

5.5 MPU 내부의 Register

CCS에서는 MPU의 Registers들을 직접 Control이 가능하며, 이를 설정이 가능하다.
View->Registers에서 ARM에 해당하는 Register를 Control 해보자.

5.6 Scripting Console (CCS 내부 Command)

CCS에서는 내부 Command를 제공할 뿐만 아니라 Script도 제공을 한다.
세부적으로 자동적으로 Control 하고 싶다면 이메뉴를 사용해야겠다.

http://processors.wiki.ti.com/index.php/Scripting_Console

A. 확인방법

View->Scripting Console
tab key 가능한 명령 표시 (처음 tab key)
help 각 명령어 입력

B. 기본 Command

reset 및 run , GEL 관련 기본 command들도 다수 존재

C. MMU 관련명령어

간단한 아래 명령으로 리눅스에서 Mapping되어있는 Address를 확인해보자.

https://www.youtube.com/watch?v=-txegVCHm8Y
http://processors.wiki.ti.com/index.php/Page_Table_Visibility_DSS_API's

D. 에러 사항 (MMU 관련 이용시)

아래와 같은 에러 발생,
추후 시간이 있다면 원인을 알아보자, 혹시 이 기능은 Linux version 만 제공이 되는지?

Wrapped java.lang.NullPointerException (C:\ti\ccsv6\eclipse\configuration\org.eclipse.osgi\343\0\.cp\resources\debugserver\pagetable.js#40)

5.7 Others

다른 Quick Tips

http://processors.wiki.ti.com/index.php/Quick_Tips

6. CCS v3.3 호환

CCSv3.3 호환은 Window version만 지원이 가능하며, 이미 만들어진 프로젝트는 아래와 같이 추가한다.