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

1. Memory 성능 향상 방법  

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

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

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

Bank Interleaving
 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부분을 잘보자.

1. 8bit DataBus DRAM  x 4 
2. 16bit DataBus DRAM x 2
3. 32bit DataBus DRAM x 1 
4. 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의 갯수는 상충관계에 있기 때문에 이는 정해놓고 이용하는 것이 옳을 것이다.

Memory 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 과 AM335x

TI의 EMIF Memory Config로 S/W Leveling 
  http://processors.wiki.ti.com/index.php/AM335x_EMIF_Configuration_tips

• DM8148

TI의 EMIF 관련부분 확인 
  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)

Dynamic Memory Manager (DMM)/TILER

- 6.1.1 Overview

- 6.1.3 Functional Block Diagram
- 6.2.1.6 Section Mapping

  - Figure 6-7. 128B and 256B Interleaving

  - Figure 6-8. 512KB and 1KB Interleaving

- 7.2.4 DDR2/DDR3 Memory Controller Subsystem Overview
  - Figure 7-3. DDR2/DDR3 Subsystem Block Diagram

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

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 한 것이며, 기본 개념은 아래에서 확인을 하자.

Interleved memory 
   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

1. RSIZE:  Row Address's size
2. PAGESIZE: Column Address's size
3. IBANK: DRAM의 실제 BANK
4. EBANK: DRAM의 갯수 

3. Burst Mode (prefetch buffer)

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

• DDR의 prefetch buffer system의 변화

1. DDR  :   2bit prefetch buffer system  (2 words)
2. DDR2 :  4bit prefetch buffer system  (4 words) 
3. 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이다,

      https://en.wikipedia.org/wiki/Delay-locked_loop

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

• DLL(Delay-Locked Loop) 과 PLL(Phase-Locked Loop)

일단 간단히 설명정리를 하면 PLL은 VCO기반으로 Phase 겹쳐서 증폭 목적으로 사용하는데, DLL은 주로 보면, DRAM의 Timing의 보정을 목적으로 한다. 

사용되는 목적이 다른 것 같으며, 상위 글과 아래의 글을 읽어보면, DLL의 경우 위상차를 찾아 이 타이밍을 개선하는 것이다.   

쉽게말해, 지연시간이 감지하고 이를 DRAM Timing 보정하는 것이다. 
    http://blog.naver.com/force1206/220359308301
    http://blog.naver.com/circlebird/60057431287

이곳에서 자세한 PLL과 DLL에 대한 것을 다루는 것은 나도 세부적으로 잘 모르기에 더 찾아봐야 하겠지만, 

PLL은 온도 와 환경 그리고, VCO에 따라 성능이 달라진다고 한다.


DDR SDRAM은 온칩 DLL(delay-locked loop)을 이용하여 DQS와 이에 상응하는 DQS를 클럭 아웃 시킴으로써 이들이 잘 일치하도록 하며, 전압 및 온도가 변화할 경우 서로를 추적할 수 있다
  http://www.eetkorea.com/ARTICLES/2006OCT/PDF/EEKOL_2006OCT16_INTD_STOR_TA_05.PDF?SOURCES=DOWNLOAD

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

아래의 DLL의 경우는, Leveling 보면 될 꺼 같다.
  https://ahyuo79.blogspot.com/2015/08/ddr-module-card.html

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의 기본구성 방법 

1. T-Branch : Bus의 길이가 같으며, Latency가 동일하다 
2. 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)

1. RDEYE_LVL_DIS
2. GATE_LVL_DIS
3. WR_LVL_DIS

• AM437x 의 설정 

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

1.  EMIF4D_READ_WRITE_LEVELING_RAMP_WINDOW
2.  EMIF4D_READ_WRITE_LEVELING_RAMP_CTRL
3.  EMIF4D_READ_WRITE_LEVELING_CTRL
4.  EMIF4D_STS Register

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


1.3 MBT와 ODT (On Die Termination)

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

1. MBT : 외부에 Ground 함께 저항 (pull-down)을 두고 연결하여 Termination  
2. 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) 증가시킨다고 함.

1. DQ : (Data bus: Data I/O) 4bit or 8bit 조정가능 
2. DM,  (Input data mask: I ) : Write data를 위한 input mask 
3. DQS, DQS# :(Data strobe: I/O): Data 신호 (Edge-aligned with read data,Center-aligned to write data) 
4. 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
                           

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; 

1. findfdt에서 board이름에 따라 fdtfile= *.dtb파일 결정 및 설정 (device tree)
2. mmcboot 시도
3. usbboot 시도
4. 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

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

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 순서

1. SOC(Rom Boot Loader)  :  SoC에 내장되어있으며, NAND의 1 Block을 읽어온다.
2. SPL                            : 1 Block Size의 작은 Boot Loader이며, Uboot 호출
3. 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 빌드과정

1. U-BOOT의 CONFIG .config에 CONFIG_SPL=y 설정 할 경우  
2. Makefile 안의  spl/u-boot-spl 에서 Makefile.spl이 spl-autoconf.mk 생성
3. 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 

1. MMC BOOT   (SD Card)
2. NAND BOOT

• 기본 부팅순서 

1. ROM Bootloader, (IPL, Initial Program Loader or (PPL, the Primary Program Loader) 
2. The binary for the (SPL, Secondary Program Loader) or the MLO.
3. 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

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 구성

1. App은 Gdb와 Gdbserver
2. 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에서 기본제공)

1. gcov
2. 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 추가

1. Add 로 사이트 추가 
2. Name : Linux Tools 
3. 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도 적용해보자.

1. PyDev   (Python IDE)
2. 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=

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의 모드구성  

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

1.1 CCS Edit 기본구성 

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

• CCS Edit의 사용용도 

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

• Index 관리 및 설정 

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

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

• CCS Edit 모드의 관련메뉴 

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

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

1. View->Project Explorer 
2. View->Target Configuration 
3. View->Console           
4. View->Problem          
5. View->Advice             
6. View->Outline   
7. View->Debug
8. View->Others->C/C++

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

1.2 CCS Debug 구성 

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

• CCS Debug의 사용용도 

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

• CCS Debug 모드의 관련메뉴

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

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

1. View->Debug
2. View->Console
3. View->Memory Browser 
4. View->Breakpoints  
5. View->Registers 
6. View->Disassembly
7. View->Expressions 
8. View->Variables  
9. View->Other->Debug 

1.3 CCS의 Simple 모드 

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

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

1. CCS 관련 설정 Update (CCS App Center, Getting Started )
2. Target Board의 상태관리 (Target Configuration) 
3. 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)

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

• Target Board 설정 및 상태 창(View)

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

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

• CCS Debug 관련설정 창(View) 

1. View->Memory Browser      : Memory 정보비교 및 저장, 수정 , Symbol Table
2. View->Registers                 : ARM Register 정보 확인 및 ARM Mode , PC확인
3. View->Script Console          : Script를 이용하여 Target의 정보를 볼수 있다. 
4. View->Expressions              : 소스의 전역변수 및 본인이 원하는 것을 조합가능
5. View->Variables                 : 소스의 Local 변수 및 Static 변수 Debug 
6. View->Disassembly             : 소스의 Assembly Code 분석 
7. View->Breakpoints              : JTAG Breakpoint 설정 및 Breakpoint 관련 Event 
8. View->Modules                  : COFF 파일의 Symbol Table 및 관련분석  
9. View->Other->Debug      : 세부 Debug를 위해 사용하는 창 
10. 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를 지속적으로 감시하고 싶다면아래와 같이 설정해보자.

1. Add new expression 
2. 관련 전역변수 추가 ( 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의 추가기능지원   (**중요)

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

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

• View->Other  

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

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

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 설정가능 및 에러율은 적고 커넥션하기가, 용이하다.

1. XDS100
2. XDS510 
3. XDS560 

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

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

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

• Target Configuration 창 설정 

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

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

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

New Target Configuration  선택    

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

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

• Basic->General Setup

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

• Basic->Advaced Setup

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

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

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

• *.ccxml 의 세부 설정구성 

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

• Advanced->Target Configuration 

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

1. ARM9 선택 
2. 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]

• 에러 해결방안

1.   JTAG 다시 연결 후 Test Connection 진행 
2.   JTAG USB Driver 인식 확인 
3.   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 와 연결   

1. Target Configurations의 창에서 해당 *.ccxml 파일 선택 후 우측버튼 클릭 
2. Launch Selected Configuration 실행 (아래 그림 참조)
3. Debug 창에서 Launch 된 *.ccxml 파일 확인
4. CPU가 여러 개 일수 있으므로, 개별 CPU를 Connect Target
5. 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 창으로 이동)

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

 B. KERNEL 동작확인

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

1. Target Disconnect 상태 유지 
2. Kernel Booting 후 보고 싶을 때, Connect를 시도
3. CPU의 상태는 Suspended로 변경되는 것을 확인 
4. Tools -> ARM Advanced Features -> MMU Enabled  ( OFF)  
5. View->Memory Browser 창 에서 본인이 찾고자하는 Register 확인 및 Data 확인 
6. Tools -> ARM Advanced Features -> MMU Enabled   (ON) 
7. 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. 확인방법

1. View->Scripting Console
2. tab key 가능한 명령 표시   (처음 tab key)
3. 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만 지원이 가능하며, 이미 만들어진 프로젝트는 아래와 같이 추가한다.

1. File->import->Code Composer Studio->Legacy CCSv3.3 Projects 선택 
2. 해당 프로젝트파일 *.pjt 검색 및 추가
3. Project Explorer에서 추가확인 
4. Project Exploer->Properties 확인하여 빌드옵션을 확인 (엔디안 및 컴파일러, ELF)

• 주의사항 

빌드를 했지만, 되지 않을 수도 있다. 이럴 경우, project 창 안에 log가 발생 할 것이니,
이부분을 자세히 보거나, migration 을 했을 경우 되지 않을 경우가 많다.

7. 추가 설치 및 Update

• Help->CCS App Center 

본인이 추가적으로 설치할 패키지를 설치
TI Cloud를 이용하면 현재 제공되는 예제를 쉽게 볼수 있다.

• Help->Check For Update 

기존 설치된 Package 체크하고 Update 관련부분을 Update 진행

• Help->Installation Details 

Installed Package 및 관련 Version 정보
Package History파악
Installed Package Uninstall

• Help->Install new software

Available Software Sites 선택하여 관련 설정을 확인하자
Code Composer Studio v6 Update
Code Generation Tools Updates
기타 등등

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