Jeonghun (James) Lee: 2015

12/18/2015

pointer

http://skmagic.tistory.com/entry/2%EC%B0%A8%EC%9B%90-%EB%B0%B0%EC%97%B4%EC%9D%84-%EB%A7%A4%EA%B0%9C%EB%B3%80%EC%88%98%EB%A1%9C-%EB%84%98%EA%B8%B8-%EB%95%8C

12/14/2015

1. ATmega128A Timer

Timer를 사용하는 이유는 다양하겠지만, 기본 Timer 와 추가 Timer를 사용하고 있으며,
기본 Timer는 일정 간격으로 Main 함수의 여러 기능의 함수를 Poling 방식 호출하는 데 사용하고 있다.
Linux의 일종의 HZ 설정 , 즉 jiffies 기능이다

기본구성을 처음 Timer 없이 Polling으로 Main 함수를 구현 했으며, 필요한 부분은
Delay를 사용을 했으나, 각 interrupt의 성능저하의 문제를 일으켜 delay대신 Timer로 변경하게되었다.

http://www.elecrom.com/2008/02/12/avr-tutorial-2-avr-input-output/

2. TIMER의 기본구성

AVR128은 Timer는 4개의 Timer로 구성이 되어있으며, 8bit와 16bit 각각 2개씩 구성이 되어있다.
그리고, 이 Timer는 많은 기능을 가지고 있어 나의 경우는 Timer로 밖에 사용하지 않았기에 다른 기능은 별로 중요하지 않았다.

아래와 같이, Timer 관련핀들

T1,T2,T3 : 외부의 별도의 Crystal를 사용하여 이를 Timer로 이용.
ICP1,3 : 외부의 신호 이용하여 Timer로 이용하는 것 같다.
OC0,OC1A 등 : 내가 설정한 값에 도달하면 이를 알려준다(비교기)

OCx관련된 핀으로 PWM 기능으로 사용한다.
그러므로, 만약 PWM기능이 필요없다면, 사용할 필요가 없을 거 같다.

Timer는 기본적은 PWM과 동작이 가능하며, 여러가지 모드를 제공을 한다.
현재 정확히 모든기능을 모두 사용을 해보지 못하고 테스트를 해보지도 못했다.

제공모드

Normal Mode
Clear Timer on Compare Match (CTC) Mode
Fast PWM Mode
Phase Correct PWM Mode
Phase and Frequency Correct PWM Mode

하지만, 내가하는 일은 PWM을 사용하는 일이 아니기에 필요가 없지만, PWM Motor 제어라든지 이때 사용하면 적합할껏 같다.

확인 Register

TIFR/ETIFR : Flag 설정
TIMSK/ETIMSK : Interrupt 설정

16bit timer의 구성

8bit timer 기본정의

TOP은 고정값 0XFF이외에도 OCR2에 저장된 값에 의해서도 사용이 가능하다. (유저셋팅)

16bit timer 기본정의

TOP은 고정값, 0xFF, 0x1FF,0x3FF 혹은 OCRnA의 ICRn에 저장된 값에 의해 변경이 가능

cbi(TCCR1A,WGM10);
sbi(TCCR1A,WGM11);
sbi(TCCR1B,WGM12);
sbi(TCCR1B,WGM13);

TOVn Flag Set on (Timer/Counter Overflow Flag) : Timer interrupt 발생 시점
Update of OCRnx at : OCRnX Register를 Update 해주는 시점
TOP : 위 의 정의 참조
BOTTOM: 위 정의 참조
MAX: 위 정의 참조

위 도표를 보면,
예를 들면, Mode 14 , Fast PWM 일 경우, TOP에 ICRn로 유저가 설정하고
그 TOP이 TOV에 적용이 된다. 그래서, User Timer로 사용이 가능하다.
15도 동일 할 것이다.

8bit timer

16bit Counter , 8bit는 유사함

아래와 같이 library를 사용해서 간단히 Timer를 쉽게 구현했다.

 timer1Init();
 timer1SetPrescaler(TIMER_CLK_DIV1024); // 11059200/1024 = 10800 HZ Tick . 
 timer1PWMInitICR(TIMER_DIV_VAL);       // 10800/1080 = 10Hz , 100ms  this timer is 16bit and  (timer 1) 
 timerAttach(TIMER1OVERFLOW_INT,setHandler);        // timer handler, 

   timer3Init();
 timer3SetPrescaler(TIMER_CLK_DIV1024);            // 11059200/1024 = 10800 HZ Tick . 
 timer3PWMInitICR(TIMER_DIV_VAL);                  // 10800/1080 = 10Hz , 100ms  this timer is 16bit and  (timer 3) 
 timerAttach(TIMER3OVERFLOW_INT,Timer2Handler);    // Timer2Handler

11/25/2015

RGB , YCbCr, YUV 및 영상 Format 정리

매번 영상관련부분을 할때 마다 관련부분을 읽까먹어서 아래와 같이 간단히 정리한다.

1. RGB (Red , Green, Blue)

일반적으로 RGB Color의 정확한 이해부터 해보도록 해보자.
어렸을 때 흔히 빛의 3원색과 색의 3원색을 배웠던 기억이 있을 것이다.
우선 RGB를 이해하기위해서는 빛의 3원색의 이해가 중요하다.
색의 3원색은 우리가 물감을 이용할때가 필요 할때이며, 빛의 3원색과 성질이 다르다.

1.1 빛의 3원색

이 세상에는 다양한 색이 존재하고 인간은 이를 많은 색상을 구분하는 것이 가능하다. (사람이 모든 색상을 완벽하게 구분을 하는 것은 아니지만)

색상의 기본적인 이해부터 해보도록 해보자. 일단 빛이 있어야 사람은 색상을 구분한다.
흔히 예전에 빛의 R, G, B로 색을 기본으로 합칠 경우 거의 모든색상이 표현이 되는데, 이를 빛의 3원색이다. 그리고, 이것이 RGB 이다.
기본적으로 존재하는 색상은 3가지 색상이며 이를 혼합하여 다른색상을 표현을 하는 것이 기본원리이다.
흔히 말하는 빛의 3원색이라고 한다. 빛의 경우 3가지 색상을 합칠 경우 흰색이 나온다.

RGB값을 이용하여 LCD 에 Display 할 경우 위와 같이 동작을 할것이며, 이를 적용하여 나온 것이며,

1.2 빛의 이론과 성질

빛의 이론으로 들어가면 빛도 일종의 파장과 진동수가 존재하며 이를 깊게 파고 들고자 한다면 (예전부터 과학동아 많이 봐왔기에 이 부분을 간단히 정리하겠다 )
빛은 파동설과 입자설 존재하며, 이 부분은 거의 정설로 되어져 있다. (이 부분까지 들어가며 설명이 길어질 것 같다, 사실 나도 자세히 모르겠다.)

간단히 설명하면, 빛도 일종의 파장을 가지고 있으며, 주파수를 가지고 있다고 하는 것이 기본 정설이다. 그래서 일종의 주파수 개념이라고 생각을 파면되겠다. 거기에 입자설까지 나왔는데, 그 부분은 나도 오래되어서 까먹었다. (추후 공부하겠지만, 현재부분과 별로 관계가 없다)
관련부분이 궁금하다면, 직접 검색을 추천 (이 부분은 이전에 과학동아에서 우주관련부분에서 많이 설명이 나왔다.)

그래서 결론적으로 RGB의 즉 빛은 3원색에서 각 색상에는 특정 파장(Wavelength) 과 진동수(Frequency ,Hz) 도 존재한다는 것이다.

일단 차근차근 살펴보자. 인간이 볼수 있는 가시광선부터 살펴보자.
아래의 그림처럼 Wavelength와 Frequency를 나타내어주고 있으며, 빨간색으로 갈수록 점점 Low Frequency 와 Wavelength가는 것을 볼수 있다. .
빛을 파동설로 보기때문에 이를 Microwave와 Radio 까지 연결시켜 볼수 있다.
빛을 일종의 전자파 개념으로 보는 것이다.

파동-입자설

https://ko.wikipedia.org/wiki/%EB%B9%9B
https://ko.wikipedia.org/wiki/%ED%8C%8C%EB%8F%99-%EC%9E%85%EC%9E%90_%EC%9D%B4%EC%A4%91%EC%84%B1

사람은 가시광선의 빛을 보고 색을 감지하기 때문에 이부분에 대해서 좀 더 자세히 알아보자.

RGB 색상혼합
http://yjh-phys.tistory.com/35
https://ko.wikipedia.org/wiki/RGB_%EA%B0%80%EC%82%B0%ED%98%BC%ED%95%A9

sRGB관련사항
https://en.wikipedia.org/wiki/SRGB
https://ko.wikipedia.org/wiki/SRGB

1.3 RGB의 표현

RGB16 (5:6:5)

Red,Blue에 5Bit를 할당하고, Green에 6bit에 할당하며, 이유는 Green 값이 Gamma 값과 밀접하기때문에 이곳에 더 할당값을 더 주었다.

그리고, 2Byte로 쉽게 표현이 가능하기에 , 이전에는 Video 영상보다는 거의 OSD에서 많이 사용되어져 왔으며 사용되었다.

RGB24 (8:8:8)

각각 8bit씩 할당하며, 이 값은 LCD에도 전달하기에도 편하고 많이 사용되어지고 있다.
흔히 True Color 라고 하며, RGB888이라고 한다.

RGBA

상위 RGB24와 거의 동일하지만, A 즉, 알파,Alpha 값 즉 투명값을 두어 32bit로 만들어 이를 사용하고 있다.

2. YUV

YUV를 논하기 전에 사람의 색상을 인식하는 방법에 대해서 좀 알아보도록하자.
인간은 어떻게 색을 구분하는지에 대해서 원리를 알아야 YUV에 대한 기본접근이 가능하기 때문이다.

상위 RGB는 물리적인 접근이라면, YUV는 사람이 색을 어떻게 감지하는지에 대해서 힌트를 얻어 만들어낸 접근방식이다.

2.1 인간의 색 인식 방법

인간은 망막을 가지고 있으며, 망막에는 망막에 상이 맺히며, 이 상을 시세포가 인지하여 색을 구분을 한다.
시세포는 다시 2가지로 구분이 되는데, 이 것이 간상세포와 원추세포이다.

각 세포의 역할을 살펴보면 다음과 같다.

간상세포(막대세포)

사람마다 다르겠지만, 대체적으로 약 1억 3천만개의 간상세포을 가지고 있다고 한다.
빛에 대한 감도는 원추세포보다는 간상세포가 더 뛰어나기때문에 물체의 명암을 구별을 해주고 빛에 민감하다고 한다.

https://ko.wikipedia.org/wiki/%EA%B0%84%EC%83%81%EC%84%B8%ED%8F%AC
https://en.wikipedia.org/wiki/Rod_cell

원추세포(원뿔세포)

사람마다 다르지만, 약 7백만개 정도를 가지고 있다고 하며, 원추세포의 역할은 자세한 모양과 색을 구별을 해주는 역할이다.
상위에서 RGB에서 배웠듯이 빛의 3원색에 각 빛에는 파장이 존재하며, 각 원추세포는 16개 정도의 원추세포가 존재하는 것으로 알려져있다.
대략 아래와 같이 3가지색으로 구분해보고 그 비율을 보면 아래와 같다.

장파장 L 원추세포인 로우(ρ)세포 (빨간영역)
중파장 M 원추세포인 감마(γ)세포 (초록색 과 노랑색 부분)
단파장 S 원추세포인 베타(β)세포 (파란색)

https://en.wikipedia.org/wiki/Cone_cell
https://ko.wikipedia.org/wiki/%EC%9B%90%EC%B6%94%EC%84%B8%ED%8F%AC

사람의 색 인지방법

http://yjh-phys.tistory.com/35
http://lovescience.pe.kr/ms/chapter2/color.htm

CIE-1931 Color Space

아래와 같이 각 빛의 Wavelength를 알아보자. (nm, Wavelength라고 보면되겠다)
X 축 Cb
Y 축 Cr

https://en.wikipedia.org/wiki/Chromaticity
https://en.wikipedia.org/wiki/CIE_1931_color_space

https://en.wikipedia.org/wiki/CIE_1931_color_space#CIE_xy_chromaticity_diagram_and_the_CIE_xyY_color_space

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

YCbCr 관련 사항 Link
  https://en.wikipedia.org/wiki/Chroma_subsampling
  https://ko.wikipedia.org/wiki/%ED%81%AC%EB%A1%9C%EB%A7%88_%EC%84%9C%EB%B8%8C%EC%83%98%ED%94%8C%EB%A7%81

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

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

  http://www.avsforum.com/forum/149-blu-ray-players/2762609-official-sony-ubp-x800-owners-thread-no-price-talk-69.html

  http://www.fourcc.org/yuv.php

  http://ryan.tistory.com/129

  https://msdn.microsoft.com/ko-kr/library/windows/desktop/bb970578(v=vs.85).aspx

11/21/2015

ARM 용 Tool Chain 설치 및 관련 설정

1. Tool Chain 설치준비

기존 LINK는 찾아봤는데, 끊기고, 되는 곳은 아래의 사이트가 동작.
공통된 ARM Core를 사용하기 때문에 DM8127 or DM8148 , DM368 다 동일하다.
이 GCC가 본인사용하는 ARM version 이 지원하는가 중요 할뿐이다.
하지만, ARM 64bit는 이야기가 다르기 때문에 이부분은 반드시 GCC Manual이나,
관련부분을 확인해야겠다.

지원사항 확인 및 설치방법

만약 아래의 Link가 살아있다면, 이것대로 하는것이 가장편하고 좋은 것 같다.
아래의 설명도 아래의 Link와 동일하다.
구지 아래의 문서를 보지 않아도 되겠다.

https://developer.ridgerun.com/wiki/index.php/Code_Sourcery_ARM_toolchain_2009q1-203

1.1 Download 및 How to Install

ARM 32bit용을 지원하며, 위에서 언급했듯이 거의 모든 Coretex에서 지원하여 사용한다.

Download Tool Chain

http://www.codesourcery.com/sgpp/lite/arm/portal/package4573/public/arm-none-linux-gnueabi/arm-2009q1-203-arm-none-linux-gnueabi.bin

1.2 기본환경구성 및 준비

본인은 Ubuntu를 사용하기 때문에 Ubuntu기반으로 설명
위의 Link 사이트에 들어가면 Red Hat에 관련 설명도 있으니, 이부분도 참고하시길

/opt/codesourcery 에 설치할 것이며, 본인이 원한다면 주소를 변경을 하여도 상관은 없다.

sudo mkdir -p /opt/codesourcery
sudo chmod ugo+wrx /opt/codesourcery

1. Download arm-2009q1-203-arm-none-linux-gnueabi.bin 파일
2. Ubuntu의 Terminal에서 이파일을 실행 준비

이 파일을 실행시키기 위해서 GTK관련부분이 필요하기에 아래와 같이 필요한 Package를 설치한다.

1.3 BASH 관련부분 설정 확인

sudo rm /bin/sh
sudo ln -s /bin/bash /bin/sh

1.4 GTK Package 설치

GTK 역시 32bit version으로 작성이 되어있으며, 만약 OS가 64bit이면 아래와 같이 32bit용을
별도로 설치해주어 동작을 진행하도록 하자.
64bit OS에서도 크게 문제없이 동작이 된다.

OS 32bit 인 경우

sudo apt-get install libgtk2.0-0:i386 libxtst6:i386 gtk2-engines-murrine:i386 libstdc++6 libxt6:i386
sudo apt-get install libdbus-glib-1-2:i386 libasound2:i386

OS 64bit일 경우

아래와 같이 32bit version으로 동작 하게 관련 Package 설치

sudo apt-get install ia32-libs ia32-libs-gtk

위와 같이 설치후, 32bit version과 동일

https://sourcery.mentor.com/sgpp/lite/arm/portal/kbentry62

1.5 Virtual Machine 설치

sudo apt-get install openjdk-6-jre

for Ubuntu 16.04

sudo add-apt-repository ppa:openjdk-r/ppa  
sudo apt-get update   
sudo apt-get install openjdk-7-jre

2. Tool chain 설치

UBuntu의 Terminal에서 실행모드를 추가 한 후, 실행하면

chmod ugo+x arm-2009q1-203-arm-none-linux-gnueabi.bin
./arm-2009q1-203-arm-none-linux-gnueabi.bin

2.1 기본설치

Next 와 I agree로 진행

설치되는 Tool Chain의 기본 Library 확인

Typical 선택 및 진행

/opt/codesourcery/arm-2009q1 으로 변경

Do not modify PATH로 진행

Link Folder -> Don't create Links 선택 진행
(이부분 동적 Library Link path 이므로 기억해야한다.)
만약 본인이 추가로 동적 Library를 사용한다면, others를 넣고 설정

위와 같이 설치 될 예정 Link Folder에 문제가 있지만,
추후 확장을 안한다면 문제가 없다.

2.2 본인 PATH 및 Link Folder 설정

본인의 Folder안에 설치가 가능하며, 위의 Link Folder를 이용하여 Link Folder도 설정가능하다.

솔직히, 2.1로 설치하는 것이 편하며, Link Folder 역시 별도로 아직 사용하지 않는것 같다.
Shared Library를 이곳에 추가 할일도 없는 것 같다.

3. Linux의 환경설정

아래의 설정을 .vimrc에 강제로 추가해도 되지만, source로 하는것이 더 편할것 같다.
UBOOT와 KERNEL에서 ARCH와 CROSS_COMPILE 환경변수는 필수이며,
INSTALL_MOD_PATH 는 Linux Kernel에서 Module의 설치 장소이다.

환경변수 설정

$ vi setPATH.sh
#!/bin/sh
# source setPATH.sh
export TOOLCHAIN_PATH=/opt/codesourcery/arm-2009q1/bin/
export TOOLCHAIN_PATH1=/home/jhlee/dm8148/CodeSourcery/Sourcery_G++_Lite/bin
export TOOLCHAIN_PATH2=/home/jhlee/dm8127/CodeSourcery/Sourcery_G++_Lite/bin

export PATH=$PATH:${TOOLCHAIN_PATH}

export ARCH=arm
export CROSS_COMPILE=arm-none-linux-gnueabi-
export INSTALL_MOD_PATH="${HOME}/dm8148/targetfs"

source를 이용하여 적용

$ source setPATH.sh

**source 사용이유

./setPATH.sh 만 실행할 경우, 이 shell script가 실행되는동안 이 PATH가 적용이 된다.
그래서 source를 사용하여 지속적으로 적용시킨다.

11/20/2015

AVR Studio 기본사용법

1. AVR STUDIO 기본사용법

ATMEL에서 제공해주는 IDE 개발 TOOLS 이며, AVR STUDIO이외에도 다양한 툴이 존재하는 것 같다.
대표적으로 Codevision 이지만, 사용해보지 않아 잘 모르겠다. 솔직히 10년만에 다시하는것라 익숙지가 않다.

AVR STUDIO는 다른 툴과 비슷하여 한번 사용한다면 쉽게 익힐 수가 있으며, 사용하기가 쉽지만
AVR과 PC의 Interface부분을 정확히 인지하고 용어를 정확히 알고 있어야 할 것 같다.
현재 ISP 인터페이스는 (Serial to SPI) 이며 AVR과 Connect 시도를 할때, AVR ISP 혹은 STK500으로 정하고, Serial로 연결하고 이를 Flash를 하면 된다.

Main->Read Signature 자신의 CPU Signature 값 확인.
Program->Flash Program으로 write 시도

1.1 AVR의 IDE 환경 및 Download

아래의 사이트에서 AVR의 IDE Tool을 Download하고 설치를 해보자.

AVR STUDIO4,6 및 Codecvision 관련사용법

http://binworld.kr/3
http://blog.daum.net/ledpark/20

AVR STUDIO- DOWNLOAD SITE

http://www.atmel.com/tools/STUDIOARCHIVE.aspx

http://binworld.kr/5

* 설치했던 AVR-STUDIO 버전들

Atmel Studio 6.2 sp2 (build 1563) Installer – with .NET

installer version은 toolchain을 포함하고 있습니다.

AVR Studio 4.19 (build 730)

Atmel AVR 8-bit and 32-bit Toolchain 3.4.1 - Windows

AVR STUDIO 6.2 설치

http://www.atmel.com/tools/atmelstudio.aspx

CODEVISON 관련사이트

http://www.codevision.be/atxmega-sbc-with-lcd/xg7100-atxmega-sbc

2. AVR Studio 4 기본사용법

현재 USB ISP 문제로 인하여, AVR Studio 4.19 Version을 사용하고 있다.
나의 USB ISP가 AVR Studio 상위 Version에서는 동작이 되지 않는다.
GCC도 역시 3.3 Version을 사용한다.

본인의 USB ISP를 구입시 이부분을 확인하기 바라며, 나와 같은 분이 없기를 바란다.

AVR Studio 4기본사용법

http://www.jkelec.co.kr/img/ucom/avr/avr_rabbit/avrstudio_programmer_manual.html

2.1 기본 프로젝트 생성

A. Project->New Project 선택

Project Name 선택 : 프로젝트 이름
Inital file 선택 : Main file 이름
Create folder : 부분체크

B. next 진행 ( 본인 device 선택 , )

저는 JTAG 이 없기에, 시뮬레이터를 선택했습니다.

2.2 ISP 연결

나의 USB ISP는 STK500을 사용하며 USB To Serial 형식을 취하고 있다.
그리고 Serial Interface에서 SPI 로 변경되어 연결이 되어있다.
이를 이용하여 빌드된 파일을 AVR128 Flash에 저장이 가능하다.

A. AVR Studio에서 ISP 장비 연결시도

(Tools -> Program AVR -> Connect or Con 아이콘 클릭)

Platform을 STK500 or AVRISP로 선택한후, Port는 연결된 Port를 선택한다

B. PC의 AVR Studio 와 ISP 장비 연결확인

아래의 MSG는 PC가 USB ISP의 연결이 되었다는 확인 메시지이며, ISP의 Firmware version 정보와 연결된 Port 정보 알수 있다.
하지만, Board에 연결이 되었다는 것은 알 수가 없다.
ISP에는 JTAG을 제공하지는 않고 있다.

C. ISP 와 AVR Board와 연결확인

Main으로 이동하여, AVR Board와 연결상태를 확인한다.
확인방법은 Read Signature를 사용하며 AVR Device에 따라 읽는 값이 다르다
값은 해당 Device의 Datasheet를 보시면 나온다.

D. Program Hex file

프래그래밍을 한 후, 빌드 하면, Hex 파일 생성이 되고 이 Hex 파일을 Flash ROM erase 하고 write하는 Tool 이다.
그리고, 백업이 가능하도록 Read도 제공하고 있다.

EEPROM 같은 경우는 EERPOM 초기 값을 attribute를 이용하여 정의해 놓고,
*.eep 부분 값이 생성된다. 이를 이용하여 초기값을 write이 가능하다.
반드시 OK Message는 확인해야 한다

E. 기타사항

ISP Firmware Version 확인

ISP Firmware Upgrade

(아직 미확인, 이 부분에서 Upgrade하면, AVR 6.2도 사용가능할 것 같다. )

ISP Status

초반에 SPI Interface를 다른 곳에 연결하여 삽질했다.
Hardware적으로 삽질하면, 필요하지 않을까 싶다.

11/17/2015

AVR LIBC 관련정보 및 예제

1. AVR LIBC

개발을 시작하다보니 AVR의 Device를 Control를 하려다 보니, 개별 예제 소스가 필요했는데, 마침 AVR의
각 Device를 쉽게 Control 할 수 있도록 Library 형태로 제공하는 source를 발견을 하였다.
그리고 사용자는 이를 include 하고 호출하는 형태로 이용하면 된다.

우선 아래의 사이트에서 본인의 AVR의, 지원여부를 확인하고 사용하자

http://www.nongnu.org/avr-libc/user-manual/index.html

1.1 기본 AVR LIBC 기본 정보

Module 정보

http://www.nongnu.org/avr-libc/user-manual/modules.html
http://www.eit.lth.se/fileadmin/eit/courses/edi021/avr-libc-user-manual/modules.html

유저메뉴얼

아래의 정보에서 Tool Chain 정보와 관련된 정보를 확인할수 있다.

http://www.nongnu.org/avr-libc/user-manual/pages.html

메모리영역

빌드시 각영역, 이부분은 나중에 빌드후 생성된 *.map과 보면 되겠다.
Linker script는 아직 찾지를 못했다.

http://www.nongnu.org/avr-libc/user-manual/mem_sections.html

TOOL CHAIN 소개

현재 GCC를 사용하고 있으며, 저 같은 경우, GCC 3.3 Version이다
  http://www.nongnu.org/avr-libc/user-manual/overview.html

GCC 메뉴얼
  https://gcc.gnu.org/onlinedocs/
  https://gcc.gnu.org/onlinedocs/gcc-3.2.3/gcc/

AVR Option을 확인하면 되고, attribute 기능은 현재 ldscript 혹은 gcc 옵션이랑 같이 연동되겠다.

기본 구현방법 및 예제

https://exploreembedded.com/wiki/AVR_C_Library

1.2 AVR LIBC 주요 Manual

내가 사용하는 Device 들이며, 이를 이용하여 구현을 할 것이라 자료수집

EEPROM 관련 메뉴얼

http://www.nongnu.org/avr-libc/user-manual/group__avr__eeprom.html

FLASHROM 관련 메뉴얼

http://www.nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html#ga963f816fc88a5d8479c285ed4c630229

ISR 관련메뉴얼

ISR or SIGNAL을 사용하시기전에 반드시 sei() 사용 해주시기 바랍니다.

자세한 내용은 아래사이트

  http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html
  https://ccrma.stanford.edu/courses/250a-fall-2005/docs/avr-libc-user-manual-1.2.5/group__avr__interrupts.html

2. 예제 Program 및 AVR library

위의 AVR Libc에서 다 지원이 되면 좋겠지만, 지원이 많이 되지 않기 때문에
필요 Library와 예제 Program을 아래에서 참조하자.

기본예제 및 기타 필수 Library Download

http://www.procyonengineering.com/embedded/avr/avrlib/docs/html/index.html
http://www.procyonengineering.com/embedded/avr/avrlib/docs/html/main.html

Timer 와 Delay

Timer와 Delay구현하기위해서 다음과 같은 부분을 읽고 참조했지만 결론적으로,

위에 library에 있는 timer128.h을 사용하여 쉽게 구현하여 이용했습니다.

  http://dal2iya.tistory.com/category/knowledge/AVR%20-%20ATMega128?page=1
  http://dal2iya.tistory.com/category/knowledge/AVR%20-%20ATMega128?page=2

  http://efundies.com/avr/avr_timer_interupts_c_simple.htm
  http://binworld.kr/35
  http://www.procyonengineering.com/embedded/avr/avrlib/docs/html/group__timer128.html

* HW Info
  http://blog.naver.com/PostView.nhn?blogId=jung4453&logNo=110017823188

UART

UART로 printf 구현하기 예제
http://www.appelsiini.net/2011/simple-usart-with-avr-libc

Memory Area and Malloc

http://www.eit.lth.se/fileadmin/eit/courses/edi021/avr-libc-user-manual/malloc.html

3. 기타 참고 예제

현재 AC 모터 제어와 온도 센서가 중요하기때문에, LCD의 제어 및 폰트기능등 각각을 참고하기 위해서 관련자료 수집.

http://cafe.naver.com/circuitsmanual/31137

http://cafe.naver.com/circuitsmanual/31137

http://kin.naver.com/qna/detail.nhn?d1id=11&dirId=1118&docId=102930127&qb=QVZSMTI4IOyGjOyKpA==&enc=utf8&section=kin&rank=1&search_sort=0&spq=0&pid=SmG/UsoRR1dsstxDDJ0sssssss8-260606&sid=YK6CEMPM7Y5vLF%2BCpXw8GQ%3D%3D

UART 관련소스

http://cafe.naver.com/circuitsmanual.cafe?iframe_url=/ArticleList.nhn%3Fsearch.clubid=18968931%26search.menuid=191%26search.boardtype=L

http://cafe.naver.com/carroty/85366

3상 모터

http://kin.naver.com/qna/detail.nhn?d1id=11&dirId=1118&docId=226863507&qb=M+yDgeuqqO2EsA==&enc=utf8&section=kin&rank=4&search_sort=0&spq=1&pid=SPdSdloRR0GssuQAvJGsssssssK-348429&sid=I5wRQrnBMHxsXknz/R0lXg%3D%3D

http://www.higenmotor.com/info/download_data.asp?no=334

3상 모터의 원리 (U V W)

  http://www.cnmmotor.com/data/Chapter%202.%EC%9C%A0%EB%8F%84%EB%AA%A8%ED%84%B0%EC%9D%98%20%EA%B8%B0%EC%B4%88.pdf

  https://www.youtube.com/watch?v=XLVWqMSvNtU

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

  http://tip.daum.net/question/56303326

10/14/2015

tree 와 aview / figlet (그림/문자표현) , rig (주석)

1. tree 명령

tree 형식으로 보여주는 command이며 기본적으로 설치되어 있지 않으며, 아래와 같이 별도로 설치하고 진행하자

$ sudo sudo apt-get install tree 
$ man tree
       tree [-adfghilnopqrstuvxACDFNS] [-L level [-R]] [-H baseHREF] [-T title] [-o filename] [--nolinks] [-P pattern] [-I pattern] [--inodes] [--device] [--noreport] [--dirsfirst] [--version]
       [--help] [--filelimit #] [directory ...]
SORTING OPTIONS
       -v     Sort the output by version
       -r     Sort the output in reverse
       -C     Turn colorization on always,
XML/HTML OPTIONS
       -X   : Turn on XML output
GRAPHICS OPTIONS
       -A     Turn on ANSI line graphics 
       -S     Turn on ASCII line graphics 

GRAPHICS OPTIONS
       -d     List directories only.
       -a     All files are printed. 
       -s     Print the size of each file
       -f     Prints the full path prefix 

       -L level
              Max display depth of the directory tree.

사용법

$ tree -d  //-d directory , 기본  ANSI Type , 현재기준  
.
├── Boot_Images
├── Filesystem
├── Media_Clips
│   ├── Audio
│   ├── Images
│   └── Video
└── START_HERE
    └── Setup_files

$ tree -X                // XML 로 전환 
.. XML 로 전환 ... 

$ tree -L 2             // Level을 설정하여 Tree의 단계를 설정 
....

$ tree -d -L 2 -A       //-d directory만 표시하고 -L를 이용하여 Level 제한 -A ANSI Type으로 표시 
....

$ tree -d  -A ./tools   // -d directory 와 -A ANSI Type 
...
$ tree -a ./tools   // -a 모든 File 
...
$ tree -as -A ./tools // File Size 

$ tree -t -L 1 --charset unicode     // -chartset Unicode 로 변경 
....

$ tree -t -L 1 --charset utf8        // -chartset utf8 로 변경 
...

2. aview/asciiview 명령

그림파일(아이콘)을 아래와 같이 문자로 변경하여 보여주며, 이를 소스에 적용하기가 좋은 명령어이다.

$ sudo sudo apt-get install aview
$ man aview
       aview [options] filename.p[ngbp]m
       asciiview [options] filename.xxx

       a,w,d,x
              Move the image one row/column.
       Z,+    Zoom in.
       z,-    Zoom out.
       q      Quit the viewer.

사용법

 $ asciiview /media/sf_SHARED/20180625000155_0.jpg

3. figlet/banner/toilet 명령

3개의 command의 기능이 동일하며, 목적은 글자를 그림으로 표현해주는 명령어들이다.
사용설명법은 생략.

$ sudo sudo apt-get install figlet
$ sudo apt-get install sysvbanner
$ sudo apt-get install toilet

사용법

가장 맘에 드는 것은 figlet 프로그램이며, 다른것은 그냥 그렇다.

$ figlet  HelloWorld
 _   _      _ _    __        __         _     _ 
| | | | ___| | | __\ \      / /__  _ __| | __| |
| |_| |/ _ \ | |/ _ \ \ /\ / / _ \| '__| |/ _` |
|  _  |  __/ | | (_) \ V  V / (_) | |  | | (_| |
|_| |_|\___|_|_|\___/ \_/\_/ \___/|_|  |_|\__,_|

$ banner HelloWorld
#     #                                 #     #
#     #  ######  #       #        ####  #  #  #   ####   #####   #       #####
#     #  #       #       #       #    # #  #  #  #    #  #    #  #       #    #
#######  #####   #       #       #    # #  #  #  #    #  #    #  #       #    #
#     #  #       #       #       #    # #  #  #  #    #  #####   #       #    #
#     #  #       #       #       #    # #  #  #  #    #  #   #   #       #    #
#     #  ######  ######  ######   ####   ## ##    ####   #    #  ######  #####

$ toilet HelloWorld
                                                                      
 m    m        ""#    ""#          m     m               ""#        # 
 #    #  mmm     #      #     mmm  #  #  #  mmm    m mm    #     mmm# 
 #mmmm# #"  #    #      #    #" "# " #"# # #" "#   #"  "   #    #" "# 
 #    # #""""    #      #    #   #  ## ##" #   #   #       #    #   # 
 #    # "#mm"    "mm    "mm  "#m#"  #   #  "#m#"   #       "mm  "#m##

4. rig 명령

가짜 이름 /주소/ 전화번로를 생성해주며, 처음 소스에 넣어 주면 편할 꺼 같다.

$ sudo apt-get install rig
$ rig
Donovan Armstrong
492 Old Pinbrick Dr
Sunnyvale, CA  94086
(408) xxx-xxxx

http://cloudsemina.com/index.php?mid=linux&document_srl=295

10/13/2015

ATMEGA-128A 기본정보 및 ISP 지원여부

1. 개발환경

AVR은 오랜된 MCU이며, 인터넷에 AVR 관련자료가 너무 많기에 찾는것은 상당히 고민 될것이며,
오래전에 사용했던 경험이 있어 이전의 기억으로 컴파일러도 제각각으로 였던걸로 기억이 되어 관련자료를 다시 검색했다.
관련 IDE TOOL은 AVR STUDIO에서 제공해주는 TOOL이 있으며, 타사에서 제공해주는 존재 한다
나의 경우는 ARTMEL사에서 제공하는 것으로 결정했으며 아래와 같이 사용하기로 했다.

1.1 AVR 개발환경

개발툴 : AVR STUDIO 4.19
CROSS COMPILER: GCC
ISP Driver : PL2303_Prolific_DriverInstaller_v1.5.0

1.2 개발보드구성

AVR128A 구성된 HW Board 2개 ( Main Board 와 Sub Board)
Serial로 Data 통신을 함.

2. ATMEGA-128A 기본정보

8bit 마이컴이며, Flash 와 EERPOM , SRAM을 포함하고 있어 , 다른 메모리 디바이스가
별도로 필요 없으며, CPU가 많은 예제소스를 제공하기에 다루기가 쉬우며, JTAG도 지원한다
그리고, 별도의 크리스탈로 없이 동작이 된다고 하지만 나의 보드 경우 Serial의 에러율문제인지 별도의 크리스탈을 사용한다.
아마도 성능문제로 외부 Clock을 사용하는 것 같다.

2.1 기본 정보

A. AVR128A Datasheet 및 TOOL 정보

http://www.atmel.com/devices/ATMEGA128A.aspx

*AVR 관련 Series 정보

  http://www.atmel.com/products/microcontrollers/avr/megaAVR.aspx

B. AVR128A 관련 한글정보

  http://cafe.naver.com/circuitsmanual/113706
  http://cafe.naver.com/circuitsmanual/16709

C. ATmega128A의 기본구성

D. ATmega128A의 의 Block Diagram

SERPROG : Serial ISP Interface 부분 (PEN, PDI, PDO, SCK , SPI Interface )
Timer 4개 : TC0,3 구성 ( OCxXX: 비교 Interrupt, Tx: Counter로 사용, ICPx: Input Capure)

3. AVR STUDIO 6.2 이상 지원여부

처음 개발할때 AVR 개발 TOOL을 AVR STUDIO 6.2를 사용했지만, ISP의 지원문제로 인하여
4.19로 변경을 하였다.
ToolChain은 이미 포함이 되어있으므로, 다른 IDE를 설치필요가 없고 아래 와 같이 그밖의 기능들은
Tools -> Extension Manager 를 이용하여 기능을 확장하자

Arduino IDE for Atme Studio
Atmel AVR 32bit GNU Toolchain Version

http://www.atmel.com/tools/STUDIOARCHIVE.aspx
http://blog.daum.net/ledpark/20

참고로 AVR STDUIO 6.2는 개별로 크로스 컴파일러인 GCC를 별도로 설치해 줘야한다.

Tools->Add Target 현재 잡힌 Port 추가
Tools->Device Programming 실행

3.1 AVR USB ISP 문제사항정리

ERROR Message 관련

Unable to connect to tool STK500
ModuleName: TCF (TCF command: Tool:connect failed.)
The signature of the attached tool is AVRISP_2, which is unexpected.

만약 저처럼 AVR STUDIO 6.2에서 아래의 메세지가 계속나올경우,

USB ISP AVR STUDIO 6 지원여부 확인

아래는 내가 사용하는 USB ISP이며 관련 Driver 와 간단한 설명이다.

  http://avr128.com/40
http://whiteat.com/pAVRISP

나의 USB ISP가 AVR STUDIO 6에서 지원이 되지 않아, 구입업체에 문의내용이다.

http://whiteat.com/index.php?mid=QnA&category=59053&document_srl=227224

***결론 AVR STUDIO 6 Version 이상  미지원

AVR USB ISP 추가확인사항

아래의 관련내용은 USB ISP의 Firmware를 사용하는데, firmware version을 변경을하면
AVR Stduio 6을 사용하는 것 같다.
하지만, 나의 USB ISP Chip과 모양다르며, 구입시 반드시 참고하시고 이 USB ISP로 구입하시기 바랍니다.

firmware의 version에 따라 AVR Studio의 동작 버전도 다르다고 한다.

(firmware to version 1.07 or later 이상을 사용해야한다고 한다.)

https://www.pololu.com/docs/0J36/3.b

https://www.pololu.com/docs/0J36/9

추가사항
XML을 추가
https://www.pololu.com/docs/0J36/3.b.1

IMX6 CAMERA MODULE 수정 및 Yocto 로 Patch 만들기

1. IMX6 CAMERA INTERFACE

현재 Freescale 의 I.MX6 의 Linux KERNEL은 device tree를 사용하고 있어, 수정 및 관리가 쉽다.

I.MX6의 camera capture의 interfaces는 Module 형태로 제공을 하고 있어,
만약, 해당부분을 추가한다면, module를 추가해서 넣고 테스트를 진행하면 된다.

1.1 CAMERA 관련문서확인

우선 Freescale에서 제공하는 문서와 Yocto File을 다운로드 하고 관련문서를 숙지하도록하자.

Freescale의 Camera 관련문서
https://www.freescale.com/webapp/sps/download/license.jsp?colCode=L3.10.17_1.0.0_LINUX_DOCS&appType=file1&location=null&DOWNLOAD_ID=null

Download

fsl-yocto-3.10.17_1.0.0.tar.gz ( Freescale site에서 download )

상위 관련문서

i.MX_6_SABRE-SD_Linux_Release_Notes.pdf
i.MX_6_Linux_Reference_Manual.pdf
i.MX_6_BSP_Porting_Guide.pdf

각 문서의 주요사항들을 아래와 같이 정리하다.

A. i.MX_6_SABRE-SD_Linux_Release_Notes.pdf

상위 문서에서 아래부분을 각각 확인하자.
Device Tree 부분은 나의 문서를 참조하고 기본개념을 파악하자.

TI Sitara Device Tree 관련내용(반드시 숙지)

https://ahyuo79.blogspot.com/2015/08/device-tree-2-am437xam335x.html

Device Tree 부분 참조

https://ahyuo79.blogspot.com/search/label/Linux-DeviceTree

그리고 나서 커널내부에서 제공하는 문서를 보자

Device Tree

uImage-imx6sl-evk-csi.dtb

상위문서의 아래부분들을 반드시 참고하고 확인하자

4 BSP Supported Features i.MX 6 SABRE-SD

Supported Features for i.MX 6 SABRE-SD
IPU V3 driver Yes Provides the interfaces to access IPU V3 modules
V4L2 Capture Yes Supports dual camera.
CSI Camera Yes Supports OV5640 camera sensor.
CSI Camera Yes Supports OV5640 camera sensor.

B. i.MX_6_Linux_Reference_Manual.pdf

기본적으로 Camera의 동작방식과 관련부분을 알고 있어야 아래 부분이 이해가 가능하다.

추후 Camera 관련내용제공

https://ahyuo79.blogspot.com/search/label/Camera

https://ahyuo79.blogspot.com/search/label/Camera-ISP

각 부분 카메라 관련 모듈 테스트 방법 과 IPU와 동작방법알아두자.
상위 문서의 아래부분을 참고

Ch 6 IPU (Image Processing Unit)

6.3 Source Code Structure
6.3.1 Menu Configuration Options ***
6.4 Unit Test 확인

$ insmod ipu_prp_enc.ko
$ insmod ipu_bg_overlay_sdc.ko
$ insmod ipu_fg_overlay_sdc.ko
$ insmod ipu_csi_enc.ko
$ insmod ov5640_camera.ko
$ insmod mxc_v4l2_capture.ko

Chapter 20 OmniVision Camera Driver
Chapter 21 MIPI CSI2 Driver

C. i.MX_6_BSP_Porting_Guide.pdf

iMX의 BSP를 수정하는 전반적인 방법에대해서 설명을 해주고 있으므로, 반드시 확인

1.2 KERNEL 구조파악

기본적으로 KERNEL에 Linux Module을 추가하려면, 아래와 같이 기본구조를 파악하자.

A. KERNEL CONFIG 의 확인

i.MX6에서 사용하는 Main Kernel Config 이며, 모든 Kernel Config 구성이 동일하다.

아래와 같이 동일한 역할을 하는 파일이지만, 위치가 다 다를 수 있다

$ ls kernelxxx/arch/arm/configs/xxxx_defconfig     //  본래 xxx_defconfig 위치는 이곳이며, make xxx_defconfig  (bitbake(yocto)에서도 사용)
$ defconfig                              //  실제 적용되는 defconfig로 이 기반으로 .config 생성       
  imx_v7_defconfig                       //  imx_v7_defconfig defconfig 동일하며,  arch/xxx/configs/에 위치함 
$ vi .config                             //  현재 설정된 kernel config 값으로 defconfig 기반으로 생성됨   
                                         //  defconfig 와 .config는 구조는 거의 비슷하지만, 생성되는 것은 Kernel에서 변경이됨 

원래 Linux kernel의 경우 아래와 같이 동작하지만 Yocto에서도 상위와 같이 각각의 defconfig 를 이해하자 
$ make xxx_defconfig    //arch/arm/configs/xxxx_defconfig 설정  후 .config 설정됨 
$ make menuconfig

B. KCONFIG 파일

Linux Kernel에서 직접 수정하도록 하자

//일반적인 Linux Kernel는 알다시피 아래와 같이 하지만, 현재 Yocto를 사용하므로 아래를 참조해가며 하자 

$ make menuconfig // Linux 메뉴설정을 위해 아래의 파일들을 점검하자 (Driver추가시)

// 상위 .config에 의해 실제 소스에 적용되는 #define 설정값 
$ cat include/generated/autoconf.h 

// make menuconfig  실행시 메뉴설정 파일 
// 해당 driver에서 Kconfig파일과 makefile을 동시에 수정을 해주면된다.
$ Kconfig     // Main 설정 
$ makefile    // 관련부분 검토 (커널 Version 확인)

// Linux Kernel Version 확인 
$ vi include/linux/version.h

2. CAMERA MODULE 수정

아래와 같이 build가 아니라 직접 source에 가서 수정하도록하자.

대신 수정하기전에, backup을 반드시 진행하고 수정을 하도록하자.

2.1 Kernel Module 수정 및 config 수정

$ cd ~/IMX6/fsl-community-bsp/build/tmp/work/imx6qsabreauto-poky-linux-gnueabi/linux-fslc-mx6/3.14-1.0.x+gitAUTOINC+4bae14aef7-r0/build/source

$ cp ./drivers/media/platform/mxc/capture/ov5642.c ./drivers/media/platform/mxc/capture/fpga.c

$ vi ./drivers/media/platform/mxc/capture/Makefile
fpga_camera-objs := fpga.o
obj-$(CONFIG_MXC_CAMERA_FPGA) += fpga_camera.o

$ vi ./drivers/media/platform/mxc/capture/Kconfig 
config MXC_CAMERA_FPGA
        tristate "FPGA camera support"
        depends on !VIDEO_MXC_EMMA_CAMERA && I2C
        ---help---
          If you plan to use the ov5642 Camera with your MXC system, say Y here.

$ cd ..      
$ vi . config                    //build directory.
CONFIG_MXC_CAMERA_OV5642=m
CONFIG_MXC_CAMERA_FPGA=m
$ cd .. 
$ vi defconfig 
CONFIG_MXC_CAMERA_OV5642=m
CONFIG_MXC_CAMERA_FPGA=m

상위와 같이 Kernel Config 와 관련 Driver 추가

2.2 make menuconfig시 설정정보

Video For Linux는 Camera기능에서 Capture기능을 담당하는 부분으로 중요하다
- Deivce Driver -> Multimedia Support -> V4L platform devices

3. PATCH 만들어 적용

Linux Kernel Patch를 직접 만들어서 이를 Yocto의 적용해보도록하자.

물론 bbappend를 사용할 것이다.

3.1 KERNEL Patch 생성

$ cd ~/IMX6/fsl-community-bsp/build/tmp/work/imx6qsabreauto-poky-linux-gnueabi/linux-fslc-mx6/3.14-1.0.x+gitAUTOINC+4bae14aef7-r0
$ mkdir jhlee  // backup 용 source 보관
$ cp -a  /home/jhlee/IMX6/fsl-community-bsp/build/tmp/work-shared/imx6qsabreauto/kernel-source/  org  // orginal source backup
$ cp -a  /home/jhlee/IMX6/fsl-community-bsp/build/tmp/work-shared/imx6qsabreauto/kernel-source/  new // after modified kernel 
$ diff -urN  org  new  > fpga.patch

상위와 같이 만들어진 patch를 확인한 후 필요한 부분만 사용

3.2 recipes-kernel 찾기

bitbake 사용시 중요한 것은 recipes 이므로 recipes-kernel 관련된 부분을 모두 찾아보자

내 kernel를 recipes 이름을 정확히 알고 있다면 . bb file 파일로 찾자

$ cd ~/IMX6/fsl-community-bsp/   // main으로 이동 
$ find . -name recipes-kernel
./sources/meta-openembedded/meta-initramfs/recipes-kernel
./sources/meta-openembedded/meta-oe/recipes-kernel
./sources/meta-openembedded/meta-networking/recipes-kernel
./sources/meta-fsl-arm-extra/recipes-kernel
./sources/poky/meta-yocto-bsp/recipes-kernel
./sources/poky/meta/recipes-kernel
./sources/poky/meta-skeleton/recipes-kernel
./sources/poky/scripts/lib/bsp/substrate/target/arch/arm/recipes-kernel
./sources/poky/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel
./sources/poky/scripts/lib/bsp/substrate/target/arch/x86_64/recipes-kernel
./sources/poky/scripts/lib/bsp/substrate/target/arch/powerpc/recipes-kernel
./sources/poky/scripts/lib/bsp/substrate/target/arch/mips/recipes-kernel
./sources/poky/scripts/lib/bsp/substrate/target/arch/qemu/recipes-kernel
./sources/poky/scripts/lib/bsp/substrate/target/arch/mips64/recipes-kernel
./sources/poky/scripts/lib/bsp/substrate/target/arch/common/recipes-kernel
./sources/meta-fsl-arm/openembedded-layer/recipes-kernel
./sources/meta-fsl-arm/recipes-kernel

3.3 Kernel recipes 의 BB file 확인

bb file의 예를 들면, 다음과 같다.

linux-fslc-mx6_3.14-1.0.x.bb

상위 구조를 보면 '_' 기준으로 PN(Package Name)과 PV(Package Version)를 나누어진다.

그러므로 아래와 같이 검색하면 쉽게 찾는다

나의 기본 KERNEL BB FILE 확인

상위구조를 이해했으며, 아래와 같이 쉽게 찾도록하자

$ find ./ -name linux-fslc-mx6*bb* // manual을 보고 이미 kernel recipe 파악 or show-recipe로 추측하자 
.....
$ cd ~/IMX6/fsl-community-bsp/   // main으로 이동 
$ vi ./sources/meta-fsl-arm/recipes-kernel/linux/linux-fslc-mx6_3.14-1.0.x.bb 
# Copyright (C) 2015 O.S. Systems Software LTDA.
# Released under the MIT license (see COPYING.MIT for the terms)

SUMMARY = "FSL Community BSP i.MX6 Linux kernel with backported features and fixes"
DESCRIPTION = "Linux kernel based on Freescale 3.14.28 GA release, used by FSL Community BSP in order to \
provide support for i.MX6 based platforms and include official Linux kernel stable updates, backported \
features and fixes coming from the vendors, kernel community or FSL Community itself."

include linux-fslc.inc

PV .= "+git${SRCPV}"

SRCBRANCH = "3.14-1.0.x-mx6"
SRCREV = "4bae14aef7b8f340f30598d2b076e9ed7b7cba56"

COMPATIBLE_MACHINE = "(mx6)"

상위 bb file 의 내부에 include가 있으므로, linux-fslc.inc 파일을 찾아 세부적으로 보자

Source 와 Build된 부분의 defconfig

현재 Kernel config 와 동일한지 우선 확인하자.

source 의 defconfig 값과 build의 defconfig를 비교를 해보고,

만약 defconfig를 설정을 변경하고자 하면 source에서 이를 맞춰서 변경해주면된다.

$ cd ~/IMX6/fsl-community-bsp/ 
$ diff  ./sources/meta-fsl-arm/recipes-kernel/linux/linux-fslc-mx6/defconfig   ~/IMX6/fsl-community-bsp/build/tmp/work/imx6qsabreauto-poky-linux-gnueabi/linux-fslc-mx6/3.14-1.0.x+gitAUTOINC+4bae14aef7-r0/defconfig   // 동일

3.4 Patch를 Yocoto *.bbappend 추가

상위에서 만들어진, 나의 Linux Patch를 Kernel Recipe에 bbappend로 아래와 같이 추가하자.

보통 bbappend 형식으로 많이 Patch관리를 한다.

$ cd ~/IMX6/fsl-community-bsp/   // main으로 이동 
$ cd ./sources/meta-fsl-arm/recipes-kernel/linux/  
$ cp ~/IMX6/fsl-community-bsp/build/tmp/work/imx6qsabreauto-poky-linux-gnueabi/linux-fslc-mx6/3.14-1.0.x+gitAUTOINC+4bae14aef7-r0/jhlee/fpga.patch . 
$ mkdir files             //  아래의 bbappend에 따라 subdirectory 생성하지만, files은 기본으로 찾음
$ mv fpga.patch files   // files에 copy 
$ ls
linux-fslc-mx6_3.14-1.0.x.bb        linux-imx                     linux-imx-rt-3.14.28     linux-ls1          linux-timesys-3.0.15
fpga.patch      linux-fslc-mx6_3.14-1.0.x.bbappend  linux-imx-3.14.38             linux-imx-rt_3.14.28.bb  linux-ls1.inc      linux-timesys_3.0.15.bb
linux-fslc      linux-fslc.inc                      linux-imx-mfgtool-3.14.28     linux-imx.inc            linux-ls1_3.12.bb
linux-fslc-mx6  linux-fslc_4.1.bb                   linux-imx-mfgtool_3.14.38.bb  linux-imx_3.14.38.bb     linux-mfgtool.inc

bbappend를 적용하여 patch진행

기본으로 recipe(*.bb)파일 위치기준으로 사용되어지는 files는 FILEPATH에 의해 local file들을 찾을 수 있다.

하지만, 아래와 같이 FILEPEXTRAATHS에 추가적으로 위치를 확장가능

SRC_URI 을 "file://" 사용할 경우 Local File을 사용하는 것이며,

THISDIR의 위치는 bbappend 파일의 위치이며, 아래와 같이 patch파일을 본인이 원하는 sub directory에 추가

주석처리 했지만, 다양하게 구성해서 해보자

$ vi linux-fslc-mx6_3.14-1.0.x.bbappend 
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
#FILESEXTRAPATHS_prepend := "${THISDIR}/v${PV}:"
#FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
#FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
SRC_URI += "file://fpga.patch"
#PRINC := "${@int(PRINC) + 1}"

* prepend는 맨앞에 할당
* append 는 맨뒤에 할당
* SRC_URI += append 의미이며, file:// 은 local file 의미

Patch 문제발생시 확인사항

상위를 추가하면 quilt 라는 것이 patch를 실행을 하는데, quilt에서 에러가 발생하면 path 내부에러문제인지 자세히 살펴보자.

3.4.1 상위 관련설정 세부사항 설명

FILEPATH

Local FILES들을 기본으로 찾는 PATH로 보통 *bb 파일의 위치로 설정 ({THISDIR}/files:)
https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#var-FILESPATH

FILESEXTRAPATHS

Local FILE들을 찾는위치를 추가로 확장하는 PATH로 본인이 원하는대로 확장
https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#var-FILESEXTRAPATHS

SRC_URI

prefix 와 suffix 값에 의해 동작이 결정된다고 생각하면된다. ";" 를 넣어 patchdir를 이용하여 patch dir로 변경가능
https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#var-SRC_URI
http://www.embeddedlinux.org.cn/OEManual/src_uri_variable.html

Kernel 관련수정방법

Kernel의 설정인 defconfig 부터 관련 driver 수정에 관련된 부분을 설명
  https://www.yoctoproject.org/docs/1.8/kernel-dev/kernel-dev.html
  https://www.yoctoproject.org/docs/1.8/kernel-dev/kernel-dev.html#changing-the-configuration
  https://www.yoctoproject.org/docs/1.8/kernel-dev/kernel-dev.html#creating-the-append-file

cfg 파일 만드는 방법

재미있는 것은 아래와 같이 diffconfig를 이용하면 .config 와 차이점을 *.cfg에 저장을 해준다.

$ bitbake linux-fslc-mx6 -c diffconfig

10/08/2015

IMX6 Kernel 빌드 및 적용 (Yocto)

1. iMX6의 KERNEL 수정

기본 YOCTO 커널은 세부적으로 나누어져 소스관리를 하는 것 같은데, 내가 사용하는 YOCTO는 조금 다른것 같다.
일단 개념을 파악하기 위해서 아래의 메뉴얼을 자세히 읽자.

Yocto의 BSP 부분의 이해
  http://www.yoctoproject.org/docs/2.0/dev-manual/dev-manual.html#developing-a-board-support-package-bsp

커널수정부분
  http://www.yoctoproject.org/docs/2.0/dev-manual/dev-manual.html#modifying-the-kernel

2. IMX6 관련 유용한 정보

아래의 정보는 나에게 상당한 도움이 되었다. 하지만, 똑같이 적용이 되지 않기에,
기본메뉴얼을 이해를 한 다음에 봐야 이해가 빠를것 같다.

IMX6 관련 F&A
  https://community.freescale.com/docs/DOC-94023 ** F/A
https://community.freescale.com/docs/DOC-95264 ** 직접 커널 빌드하는 방법.
https://community.freescale.com/docs/DOC-95003 **** 가장 빨리 커널 수정방법
https://community.freescale.com/docs/DOC-95252  *** 커널 패치하기

3. UBOOT와 KERNEL 소스

일단 가장 급한 것의 정확한 Uboot 소스 위치와 Kernel 소스 위치이며, 이를 찾는 것이 중요한 것 같다.

3.1 Uboot와 Kernel 소스 위치 파악하기

Yocto로 bitbake를 이용하여 기본빌드를 진행을 하면 Uboot와 Kernel 소스의 위치를 알기가 힘들다
그래서 내가 생각한 방법은 .config 기준으로 find로 uboot와 kernel의 실제위치를 찾는것이다
Yocto를 보면 Uboot 마다 다른 Version이 존재하여 .config를 사용하지만, 이전버전은 같이 존재 한다면 주의해야 겠다.

Kernel의 경우에는 *dts / *.dtb 이름으로 검색을 해도 될 것 같다

$ find . -name .config
./build/tmp/work/imx6qsabreauto-poky-linux-gnueabi/u-boot-fslc/v2015.07+gitAUTOINC+3f0c5353f9-r0/git/mx6qsabreauto_config/.config
./build/tmp/work/imx6qsabreauto-poky-linux-gnueabi/linux-fslc-mx6/3.14-1.0.x+gitAUTOINC+4bae14aef7-r0/jhlee/orgbuild/.config
./build/tmp/work/imx6qsabreauto-poky-linux-gnueabi/linux-fslc-mx6/3.14-1.0.x+gitAUTOINC+4bae14aef7-r0/build/.config
./build/tmp/work/i686-linux/perl-native/5.22.0-r0/perl-5.22.0/.config
./build/tmp/work/i686-nativesdk-pokysdk-linux/nativesdk-linux-libc-headers/4.1-r0/linux-4.1/.config
./build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/wpa-supplicant/2.4-r0/wpa_supplicant-2.4/wpa_supplicant/.config
./build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/linux-libc-headers/4.1-r0/linux-4.1/.config
./build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/busybox/1.23.2-r0/sysroot-destdir/usr/lib/busybox/ptest/.config
./build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/busybox/1.23.2-r0/image/usr/lib/busybox/ptest/.config
./build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/busybox/1.23.2-r0/busybox-1.23.2/.config
./build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/busybox/1.23.2-r0/package/usr/lib/busybox/ptest/.config
./build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/busybox/1.23.2-r0/packages-split/busybox-ptest/usr/lib/busybox/ptest/.config
./build/tmp/sysroots/imx6qsabreauto/usr/lib/busybox/ptest/.config

3.2 Uboot 와 Kernel 의 Recipes 검색

이제 상위에서 각 위치를 파악을 했지만, 이 Bitbake를 이용하여 Recipes 이를을 정확히 알아야 겠다.
위에서 나온 정보와 아래의 명령으로 비교하여 각각 recipes 이름을 찾아보자
그리고 정확한 정보를 알아 낸뒤에 아래와 같이 상위 위치와 비교해보자.

Uboot 와 Kernel Recipes 검색

$ bitbake-layers show-recipes       // 전부보기 (Uboot 와 Kernel 및 다른 recipe 파악) 

$ bitbake-layers show-recipes "*-image-*"  // Uboot를 찾기 위해서 했으나, 실패 

$ bitbake-layers show-recipes "*linux*"    // linux kernel 찾기위해 검색 (linux가 들어가면 다 검색)

각 recipes 의 Layer 정보확인

$ bitbake-layers show-recipes u-boot-fslc  // 검색을 통해 u-boot의 recipe를 찾음 
u-boot-fslc:
  meta-fsl-arm         v2015.07+gitAUTOINC+3f0c5353f9     // 각 recipe의 layer 정보확인 (가끔 두개의 Layer 가진것도 있음)

$ bitbake-layers show-recipes linux-fslc-mx6  // 검색을 통해 Kernel의 recipe 확인 (recipe의 Layer 확인)
linux-fslc-mx6:                                            
  meta-fsl-arm         3.14-1.0.x+gitAUTOINC+4bae14aef7   // 각 recipe의 layer 정보확인

각 recipes의 File 검색 및 설정확인

$ bitbake-layers show-layers  // 상위 정의된 recipe는의 모든 layer 확인 가능하며 PATH 확인가능  

$ find ./source  -name  linux-fslc-mx6*bb*   // linux kernel *.bb 와 *.bbappend (각 recipe확인)

$ find ./source  -name  u-boot-fslc*bb*   // uboot *.bb 와 *.bbappend (각 recipe확인)

각각의 Kernel 과 Uboot Recipe들을 다 확인을 해보자.

4. Yocto 설정 (build 설정)

bitbake를 사용하려면, 아래와 같이 설정을 해주어야 동작가능하다
만약 설정 후 bitbake가 동작이 안한다면 다시 한번 설정해주자

$ source setup-environment build

설정시 상위에 정의 된 build direcotyr가 생성되면 conf/local.conf / bblayers.conf 를 확인

4.1 BITBAKE를 이용한 커널 설정 및 빌드

현재 나의 커널 recipes 는 linux-fslc-mx6 이며, 이를 이용하여, menuconfig 및 빌드 , 이미지, 생성도 가능하다.
이 때 사용하는 옵션 -c 이며 이에 연결되는 *.bb에서 Task라고 하며 do_xxxx 라는 함수들을 호출한다.
-f 옵션은 강제로 실행을 시키는 명령

bitbake를 이용한 kernel 설정/빌드/배포

$ bitbake linux-fslc-mx6 -c menuconfig                                     // kernel 의 menuconfig 설정, Terminal에서 해야함.
// 커널의 설정을 확인하고 관련부분을 검토하자 , 저장을 해봐야 .config에 저장된다.

$ bitbake linux-fslc-mx6 -c compile -f                                     // kernel build  (device tree도 )

// yocto의 build 내부에서 강제로 build를 진행 이유는 build 내의 kernel source를 직접 수정하여 바로 build를 하기 위해서 사용.  
// 문서에는 권고하지는 않으며, 빠른 개발을 위해서만 사용한다. 
// 추후 Yocto에 적용하고자 한다면 별도의 Patch file을 만들어 *.bb 혹은 *.bbappend 에 patch 파일을 추가관리 

$ bitbake linux-fslc-mx6 -c deploy                                         // deploy 적용 (build/tmp/deploy/image/xxx 확인 
//

$ bitbake linux-fslc-mx6 -c diffconfig                                      
// 상위  bitbake linux-fslc-mx6 -c menuconfig 에서 본인이 변경한 것을 간단하게 알려주며 이를 이용하여 간단하게 defconfig도 patch도 가능 
// 상위 결과물: fragment.cfg 
//
// 아래와 같이 PATCH와 거의 비슷하게 아래와 같이 본인의 추가하여 defconfig and .config를 수정하도록 하자 
// FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
// SRC_URI += "file://fragment.cfg"
// do_configure_prepend  : config 하기전에 앞에 하는행동 
// do_configure_append   : config 한 후에 추가하는 행동

Kernel Source에서 menuconfig (Uboot 도 동일)

만약 상위의 menuconfig 가 문제가 있다면 소스에서 직접하자.
다만 ARCH 반드시 설정 해줘야 한다.

$ cd ~/IMX6/fsl-community-bsp/build/tmp/work/imx6qsabreauto-poky-linux-gnueabi/linux-fslc-mx6/3.14-1.0.x+gitAUTOINC+4bae14aef7-r0
$ ARCH=arm CROSS_COMPILE=arm-poky-linux-gnueabi- make menuconfig

4.2 Yocto의 Build의 커널 소스구조

Yocto의 Build 부분에 Kernel의 Source와 Build되는 부분을 보여주며 이 부분을 이해하도록하자.
이 부분은 Kernel의 *.bb에 의해 설정이 되며 git으로 kernel source를 fetch를 진행 한 후 defconfig를 설정을 진행한다.
그리고, 아래의 build 에 .config 가 설정이 되면서 build가 되고 image가 생성이 되면 이를 image로 복사한다.

$ cd ~/IMX6/fsl-community-bsp/build/tmp/work/imx6qsabreauto-poky-linux-gnueabi/linux-fslc-mx6/3.14-1.0.x+gitAUTOINC+4bae14aef7-r0 

// Yocto build 내부의 kernel 관련구조 
// git fetch를 하며 아래와 같이 kernel source는 link로 연결 

$ tree -d -L 1 
├── build   // kernel build 되는 곳 (.config 저장)
├── deploy-linux-fslc-mx6
├── deploy-rpms
├── git -> /home/jhlee/IMX6/fsl-community-bsp/build/tmp/work-shared/imx6qsabreauto/kernel-source   // linux kernel source
├── image
├── jhlee           // test 용 
├── license-destdir
├── package
├── packages-split
├── pkgdata
├── pseudo
├── sysroot-destdir
└── temp

$ ll
drwxr-xr-x 20 jhlee jhlee   4096 10월 13 11:12 build/        // kernel source 와 build되는 것으로 .config가 저장    
-rw-r--r--  1 jhlee jhlee   9704 10월  6 15:16 defconfig         // kernel의 defconfig로 kernel source에 있다면, arch/arm/configs 참조 
drwxr-xr-x  2 jhlee jhlee   4096 10월  6 20:31 deploy-linux-fslc-mx6/   // output 
drwxr-xr-x  3 jhlee jhlee   4096 10월  6 20:32 deploy-rpms/
lrwxrwxrwx  1 jhlee jhlee     85 10월  6 15:16 git -> /home/jhlee/IMX6/fsl-community-bsp/build/tmp/work-shared/imx6qsabreauto/kernel-source/
drwxr-xr-x  5 jhlee jhlee   4096 10월  6 18:57 image/         // kerenl의  image들 
drwxrwxr-x  3 jhlee jhlee   4096 10월  6 16:06 license-destdir/
-rw-r--r--  1 jhlee jhlee 121789 10월  6 20:32 linux-fslc-mx6.spec
drwxr-xr-x  4 jhlee jhlee   4096 10월  6 18:57 package/
drwxr-xr-x 90 jhlee jhlee   4096 10월  6 18:57 packages-split/
drwxr-xr-x  7 jhlee jhlee   4096 10월  6 18:57 pkgdata/
drwxrwxr-x  2 jhlee jhlee   4096 10월  6 20:50 pseudo/
drwxr-xr-x  3 jhlee jhlee   4096 10월  6 18:57 sysroot-destdir/
drwxrwxr-x  2 jhlee jhlee  12288 10월 13 11:12 temp/

// 상위 build 로 들어가면 kernel의 build된 값과 소스 System.map 확인 
// Kernel source는 아래와 같이 link로 연결 

$cd build  
$ ll
-rw-r--r--  1 jhlee jhlee    98120 10월 16 13:11 .config
-rw-r--r--  1 jhlee jhlee     9760 10월 16 13:11 .config.old
-rw-r--r--  1 jhlee jhlee     1054 10월 16 13:11 .missing-syscalls.d
-rw-r--r--  1 jhlee jhlee        0 10월 16 13:11 .scmversion
-rw-r--r--  1 jhlee jhlee  2264837 10월 16 13:22 .tmp_System.map
-rw-r--r--  1 jhlee jhlee  1655860 10월 16 13:22 .tmp_kallsyms1.o
-rw-r--r--  1 jhlee jhlee  1655860 10월 16 13:22 .tmp_kallsyms2.o
drwxr-xr-x  2 jhlee jhlee     4096 10월 16 13:11 .tmp_versions/
-rwxr-xr-x  1 jhlee jhlee 17118260 10월 16 13:22 .tmp_vmlinux1*
-rwxr-xr-x  1 jhlee jhlee 18224228 10월 16 13:22 .tmp_vmlinux2*
-rw-r--r--  1 jhlee jhlee        2 10월 16 13:22 .version
-rw-r--r--  1 jhlee jhlee      200 10월 16 13:22 .vmlinux.cmd
-rw-r--r--  1 jhlee jhlee      742 10월 16 13:11 Makefile
-rw-r--r--  1 jhlee jhlee   410666 10월 16 13:22 Module.symvers
-rw-r--r--  1 jhlee jhlee  2264837 10월 16 13:22 System.map
drwxr-xr-x  3 jhlee jhlee     4096 10월 16 13:11 arch/
drwxr-xr-x  3 jhlee jhlee     4096 10월 16 13:13 block/
drwxr-xr-x  2 jhlee jhlee     4096 10월 16 13:14 crypto/
drwxr-xr-x 59 jhlee jhlee     4096 10월 16 13:22 drivers/
drwxr-xr-x  3 jhlee jhlee     4096 10월 16 13:13 firmware/
drwxr-xr-x 28 jhlee jhlee     4096 10월 16 13:17 fs/
drwxr-xr-x  5 jhlee jhlee     4096 10월 16 13:11 include/
drwxr-xr-x  2 jhlee jhlee     4096 10월 16 13:22 init/
drwxr-xr-x  2 jhlee jhlee     4096 10월 16 13:11 ipc/
drwxr-xr-x 11 jhlee jhlee     4096 10월 16 13:16 kernel/
drwxr-xr-x  6 jhlee jhlee    12288 10월 16 13:15 lib/
drwxr-xr-x  2 jhlee jhlee     4096 10월 16 13:14 mm/
drwxr-xr-x 22 jhlee jhlee     4096 10월 16 13:22 net/
drwxr-xr-x  7 jhlee jhlee     4096 10월 16 13:11 scripts/
drwxr-xr-x  3 jhlee jhlee     4096 10월 16 13:11 security/
drwxr-xr-x 20 jhlee jhlee     4096 10월 16 13:14 sound/
lrwxrwxrwx  1 jhlee jhlee       85 10월 16 13:11 source -> /home/jhlee/IMX6/fsl-community-bsp/build/tmp/work-shared/imx6qsabreauto/kernel-source/
drwxr-xr-x  2 jhlee jhlee     4096 10월 16 13:11 usr/
-rwxr-xr-x  1 jhlee jhlee 18224228 10월 16 13:22 vmlinux*
-rw-r--r--  1 jhlee jhlee 22305936 10월 16 13:22 vmlinux.o

source에서 실제 소스를 수정해야한다.

4.3 Yocto Build의 deploy의 image 확인

build 디렉토리에서 각각의 Kernel 및 Uboot와 Device Tree 이미지를 확인가능하다.
Device Tree의 설정만 변경이 되면, 매번 Kernel 의 세부설정을 변경할 필요가 없을 것 같다.

$ ls tmp/deploy/images/imx6qsabreauto/  // build 기준으로 tmp/deploy/images 찾음 
README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt                                  zImage--3.14-1.0.x+git0+4bae14aef7-r0-imx6q-sabreauto-20151006054445.dtb
modules--3.14-1.0.x+git0+4bae14aef7-r0-imx6qsabreauto-20151006054445.tgz            zImage--3.14-1.0.x+git0+4bae14aef7-r0-imx6q-sabreauto-20151014014133.dtb
modules--3.14-1.0.x+git0+4bae14aef7-r0-imx6qsabreauto-20151014014133.tgz            zImage--3.14-1.0.x+git0+4bae14aef7-r0-imx6q-sabreauto-ecspi-20151006054445.dtb
modules-imx6qsabreauto.tgz                                                          zImage--3.14-1.0.x+git0+4bae14aef7-r0-imx6q-sabreauto-ecspi-20151014014133.dtb
qt4e-demo-image-imx6qsabreauto-20151006054445.rootfs.ext4                           zImage--3.14-1.0.x+git0+4bae14aef7-r0-imx6q-sabreauto-flexcan1-20151006054445.dtb
qt4e-demo-image-imx6qsabreauto-20151006054445.rootfs.manifest                       zImage--3.14-1.0.x+git0+4bae14aef7-r0-imx6q-sabreauto-flexcan1-20151014014133.dtb
qt4e-demo-image-imx6qsabreauto-20151006054445.rootfs.sdcard.gz                      zImage--3.14-1.0.x+git0+4bae14aef7-r0-imx6q-sabreauto-gpmi-weim-20151006054445.dtb
qt4e-demo-image-imx6qsabreauto.ext4                                                 zImage--3.14-1.0.x+git0+4bae14aef7-r0-imx6q-sabreauto-gpmi-weim-20151014014133.dtb
qt4e-demo-image-imx6qsabreauto.manifest                                             zImage--3.14-1.0.x+git0+4bae14aef7-r0-imx6qsabreauto-20151006054445.bin
qt4e-demo-image-imx6qsabreauto.sdcard.gz                                            zImage--3.14-1.0.x+git0+4bae14aef7-r0-imx6qsabreauto-20151014014133.bin
u-boot-imx6qsabreauto.imx                                                           zImage-imx6q-sabreauto-ecspi.dtb
u-boot-imx6qsabreauto.imx-sd                                                        zImage-imx6q-sabreauto-flexcan1.dtb
u-boot-sd-v2015.07+gitAUTOINC+3f0c5353f9-r0.imx                                     zImage-imx6q-sabreauto-gpmi-weim.dtb
u-boot.imx                                                                          zImage-imx6q-sabreauto.dtb
u-boot.imx-sd                                                                       zImage-imx6qsabreauto.bin

10/07/2015

YOCTO 기본사용방법

1. Yocto Project

요즘 임베디드 프로그램에서 개발환경에서 yocto project로 빌드하는 것이 대세 인것 같다.
TI를 비롯하여, Freescale의 iMX6, Raspberry pi 보드 등 대부분의 BSP를 Yocto를 지원해주고 있다.
하지만, 한번 빌드를 시작하면, 용량이 상당하여, 시간과 데이타양이 부담스럽지만, 편하게 이용할 수 있어 좋은 것 같다.
bootloader 부터시작하여, kernel 및 filesystem에 들어가는 관련 application 및 GUI Interface의 전체 소스를 받고 빌드를 하며 사용하기 쉽다고 하지만,
막상 Yocto 기반으로 개발을 진행을 하면 소스 추가하는 방법과 이를 관리하는 방법도 배워야 하니, 배울게 점점 더 늘어나 진다.

1.1 각 칩제조사별 Yocto Project

현재 TI의 경우 AM33xx or AM43xx 일 경우 관련 Yocto를 제공해주고 있으며 다른 SOC는 현재 잘모르겠다.
그리고, 반드시 알아야할 것이 아래의 메뉴얼과 본인이 사용하는 Yocto 구조가 많이 상이할수가 있는데, 이부분은 반드시 관련 Version과 관련 제조사 Manual을 반드시 참조해야한다.
하지만 기본구성과 기본사용법은 거의 비슷하므로 아래의 기본은 알아두도록하자

TI의 Arago Project

https://www.yoctoproject.org/product/arago-project

Freescale은 IMX6을 다루면서 잠시 아래와 같이 빌드했지만, Freescale에서 제공해주는 문서를 읽는 것이 더 편하게 느껴졌다.

Freescale iMX6

https://www.yoctoproject.org/organization/freescale-semiconductor
https://community.freescale.com/docs/DOC-1616
https://community.freescale.com/docs/DOC-93844

2. Yocto 기본매뉴얼

아래의 사이트에 가면 모든 메뉴얼이 존재하며, 반드시 가서 읽어봐야 하며, 가능하면,
최신 Manual을 읽는 것이 이해하는데 도움이 될 것이다.
이해를 한 다음에 본인 Version으로 가서 읽으면 이해가 쉬울 것 같다.

주의해야 할 사항은 아래 Manual 보다 칩제조사의 Manual이 우선되어야 할 것이다.

Yocto 모든 메뉴얼 소개

https://www.yoctoproject.org/documentation

전체메뉴얼

http://www.yoctoproject.org/docs/1.8/mega-manual/mega-manual.html

2.1 중요부분메뉴얼 (V1.8)

현재 최신 버전인 1.8 Version으로 메뉴얼을 봤지만, 추후 개발한다면 관련 Version을 알아
자신의 Version에 맞게 알아두자

커널 및 BSP관련 개발 ( BSP부분 중요)

Yocto Project Linux Kernel Development Manual
http://www.yoctoproject.org/docs/1.8/kernel-dev/kernel-dev.html

Yocto Project Development Manual
http://www.yoctoproject.org/docs/1.8/adt-manual/adt-manual.html

Yocto Project Board Support Package (BSP) Developer's Guide
http://www.yoctoproject.org/docs/1.8/bsp-guide/bsp-guide.html

Source Repositories:

http://git.yoctoproject.org/cgit/cgit.cgi

3. Yocto 기본동작

Yocto project는 꼭 임베디드 소스 개발환경에 제공되는 시스템이 아니며, 아래의 구조를 보고 천천히 이해를 하자
각각의 소스를 가져와 패치를 하고 설정을 하며, 원하는 패키지를 생성 후 테스트를 걸쳐, Image를 생성한다. 이것이 기본 Yocto project의 구성이다.

http://www.yoctoproject.org/docs/1.8/yocto-project-qs/yocto-project-qs.html

Yocto의 전체적인 동작방식 (상층의 화살표대로 보면 전체적인 이해가 됨)

Source Mirrors 존재 및 관리 (관련 Project들의 Source 집합체)
Source Mirror에서 Fetch (Download from remote Repositories)
좌측의 User Configuration Target 설정된 값들 기준으로 Build 를 진행
Build를 진행을 하면 좌측의 Metadata 와 Machine/Policy Configuration에 이용
Build 진행 후 Output이 생성되면 Package를 만들고 이를 QA TEST 진행
Image 와 SDK도 생성하여 각각의 Output을 생성

https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#source-fetching-dev-environment
https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#patching-dev-environment

용어정리

User Configuration: 빌드를 Control하는 Metadata라고 하며 config file
Metadata Layers: 상위 좌측의 3개 Metadata / Machine / Policy Configuration를 말함
Source Files: 상위 Source Mirros를 말하며 보통 Git로 관리.
Build System: Bitbake기반으로 recipe에 따라 source fetch / patch / build /package등을 진행한다

Fetcher / Fetching: Source는 다운로드하는 것

Embedded 시스템에서 보면 주요부분

Image Generation (Uboot 와 Kernel / Filesystem)
SDK
Package (rpm/deb/ipk) 다양한 Linux Package를 지원가능

최근에는 라지베리파이까지 지원되는 것으로 보아서 거의 관리부분은 Yocto 추세로 가는 것 같다.

QEMU의 지원

Target CPU 상위 User Configuration에서 설정 기준으로 Image가 생성되고 Depoly 된다
재미있는 것은 QEMU이라는 것이 존재하여 Target CPU를 테스트가 가상으로 TEST가 아래처럼 가능하다.

Quick Start

동작방식 및 처음사용법을 간단히 소개한다.
http://www.yoctoproject.org/docs/1.8/yocto-project-qs/yocto-project-qs.html

3.1 Yocto 전체구성

Yocto 전체구성을 보면 간단히 보면 Source 와 Build 구성이 된다.

Yocto 관련부분 (i.MX는 Source 변경)

Yocto의 Poky를 비롯하여 추가된 Yocto 의 다양한 Layer 들 (Open Embedded Layer 및 BSP Layer)이며, 이 설정기반으로 Build에 구성한다.
Yocto의 관리 프로그램이라고 생각하면된다.

Build (Yocto 기반으로 생성된 부분)

Source 기반으로 설정되어 생성되는 Directory 이며, Source 내부의 설정에 따라 변경이 되어진다.
User Configuration (conf/local.conf, conf/bblayers.conf) 를 비롯하여 각 필요한 소스를 Git로 Fetch(Download)를 하고 이를 Package를 진행하고 Image를 생성한다.
상위의 3. Yocto의 동작이 Build 내부에서 진행이 된다고 생각하면된다.

3.2 Yocto의 구성 (Poky)

Yocto는 Pocky만 있으면, 기본구성이 되어지며, 그리고 Yocto에 지원되는 다양한 Tool 및 Script들을 제공해주고 있다.

Poky: Yocto의 기본구성이며 bitbake를 비롯하여 기본이되는 명령어들이 존재
Open Embedded(OE): Yocto에서 많이 사용되어지는 Embedded Layer 들
Chip 제조사의 meta-layer: TI or Freescale 들은 본인들의 Layer들을 제공

Pock 관련부분
https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#structure-core

Chip 업체가 BSP Layer를 구성한다면 Pocky 기반으로 BSP Layer를 만들고 구성을 할 것이며, OpenSource에서 필요한 것들은 Open Embedded에서 보충할 것이다

3.3 Yocto의 Layer의 종류

하단그림의 Layers 부분의 좌측의 3개로 구성이 되어있으며, bitbake에 의해 각각의 기능을 수행하며, 각 Layers들은 Source Directory에 존재하며
각각의 conf 와 recipes들이 존재하며, 중요하게 봐야할 부분이 BSP Layer 부분일 것이다.

각 Configuration 과 Layer의 관계

Policy Configuration: Distro layer로 배포를 위해 전체 image or package 관련부분을 담당
Machine Configuration: BSP layer로 target arch에 해당하는 부분에 해당
Metadata : Software layer로 일반적인 open source들이 해당

Metadata, Machine Configuration, and Policy Configuration
https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#metadata-machine-configuration-and-policy-configuration

Distro Layer의 기본구성

전체 배포를 위한 규칙담당을 하기 때문에 많이 익숙해져야할 Layer이며 build directory의 conf/local.conf에 확인가능하며,
conf/layer.conf 와 conf/distro/***.conf가 존재하며, 보통 include 형식으로 연결되어있음.

classes : (*.bbclass)를 가지고 있으며, 배포를 위해 공유
conf : 상위에서 conf/local.conf에서 본인이 사용하는 distro layer 확인 (conf/distro/*.conf)
receipe-* : 일반적인 배포를 위한 recipe와 다양한 기능의 recipe 제공

BSP Layer의 기본구성

conf/layer.conf 와 conf/machine/machine_name.conf로 구성이 되며, 현재 사용중인 BSP Layer를 확인하고자 하면 build directory의 conf/local.conf 에서 확인가능
일반적으로 recipes-bsp, recipes-core, recipes-graphics, recipes-kernel 등으로 구성이되지만, 배포판마다 다를 수 있으므로 주의

BSP Layer의 구성
https://www.yoctoproject.org/docs/1.8/bsp-guide/bsp-guide.html

Software Layer의 기본구성

상위에서 설정된 배포방식으로 일반 Open source를 Package를 진행하며, Layer이기 때문에 conf/layer.conf가 존재

Distro/BSP/Software layer 관련사항
https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#distro-layer
https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#structure-meta-conf-machine

모든 Distro 와 BSP layer 찾기

$ find yocto/sources -name distro  // 모든 distro layer 위치확인가능  
.../conf/ditro
.../conf/ditro

$ find yocto/sources -name machine  // 모든 machine layer 위치확인가능  
.../conf/machine
.../conf/machine

Build 의 User Configuration 이용하여 Layer 정보찾기

Build directory 의 User Configuration 정보확인

$ cat yocto/build/conf/local.conf  // 현재 build directory의 distro layer 확인 
.....
MACHINE ??= 'armxxxxx'      // 사용될 BSP Layer 확인가능   (??= 는 다른곳에서 설정안할 경우) 
DISTRO ?= 'poky'            // 사용될 Distro Layer 확인가능 (?= 주의)   
DISTRO_FEATURES ?=         // 
PACKAGE_CLASSES ?= 'package_rpm'   // Package를 기본 rpm 구성 이외 deb 과 ipk 
.......

$ cat yocto/build/conf/bblayers.conf // 전체 Layer 확인 가능하며, Software Layer 구성확인가능 
.........
BBLAYERS = " \
  ${BSPDIR}/sources/poky/meta \
  ${BSPDIR}/sources/poky/meta-poky \
  \
  ${BSPDIR}/sources/meta-openembedded/meta-oe \
  ${BSPDIR}/sources/meta-openembedded/meta-multimedia \
  ...

BBLAYERS += "추가될 Layer "

$ find yocto/sources/ -name poky*.conf // DISTRO로 사용하는 Distro layer 확인가능 

$ find yocto/sources/ -name armxxxxx*.conf // MACHINE로 사용하는 BSP layer 확인가능

3.4 Yocto의 쉬운 Layer 확장 (중요)

Yocto는 본인이 가지고 있는 것에서 확장이 쉽게 가능하며 아래의 사이트에서 Layer를 찾아 추가하고
이를 build의 conf/bblayers.conf (User Configuration)에 적용하면 된다.
상위 BBLAYERS 부분에 추가

Yocto를 확장가능하게 해줄 다양한 Layer들 (Open Embedded)

https://layers.openembedded.org/layerindex/branch/master/layers/

Metadata ( poky의 meta)

좀 더 자세히 알고자 한다면 각각의 recipes들을 살펴보자
https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#structure-meta

Custom Layer 구성

상위 3가지 종류 중 본인이 원하는 것을 선택해서 Layer를 직접구성
https://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#understanding-and-creating-layers

4. Yocto의 Build Directory 기본구성

좌측은 Yocto의 Source
우측은 Yocto의 Build

build directory 설정방법

각 Yocto마다 이름은 조금씩 다를수 있지만, 기본은 enviornment 설정 후 bitbake를 사용가능
처음 source를 이용하여 build 설정할 경우(아래 예제참고)

build direcoty 생성
build의 User Configuration (Source에서 복사해옴)
build enviornment 설정가능 및 bitbake 와 yocto 명령사용가능

재설정 할 경우 (동일하게 입력, 아래 예제참고)

build directory 이미 기존생성것 이용
User configuration 이미 기존생성된것 이용
build enviornment 재설정 후 bitbake 및 yocto 명령어 이용가능

build directory 일반설정의 예

poky의 것을 사용하지만 좀 더 좋게 하기 위해서 이를 기반으로 Shell Script을 이용하는 기능을 추가하여 구성하는 경우도 있음

$ source poky/oe-init-build-env build  // build directory를 build로 생성 
or 
$ source poky/oe-init-build-env build-sample  // build directory를 build-sample로 생성 (이름변경은 마음대로)

Linux Terminal에서 기본적으로 login 할때마다 build enviornment를 설정되지 않기때문에 매번설정해야함

https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#structure-core-script

4.1 User Configuration

build directory를 설정 한 후 각각의 bblayers.conf 와 local.conf는 전체 설정에 반영이 되므로 중요하며 관련세부설정도 알아보자.

User configuration 의 구성

build의 conf/bblayers.conf : Layer정보로 Layer를 이곳에 직접추가가능
build의 conf/local.conf : 전체환경 설정값 e.g MACHINE 설정
source의 bblayers.conf.sample 과 local.conf.sample: build의 원본파일

bblayers.conf 환경설정

Layer 관련 추가 방법: BBLAYERS

local.conf 일반환경설정 (개인환경설정)

local.conf는 전체 환경설정값으로 모두 적용이 되므로, 필요한 것 있다면, 일반 설정 이외
본인 환경설정도 이곳에 정의해서 설정가능하다.
아래설정은 Yocto에서 보통 사용되어지는 일반환경설정들이며, 이부분은 좀 자세히 알아두자.

Build Parallelism Options: BB_NUMBER_THREADS , PARALLEL_MAKE , BB_NUMBER_PARSE_THREADS
Target Machine: MACHINE (Board 설정 및 MPU 설정)
Download Directory: DL_DIR (중요 각각의 Source를 Download 장소설정)
Shared State Directory: SSTATE_DIR
Build Output: Build의 될곳 TMPDIR
Distro 관련설정: DISTRO DISTRO_FEATURES
Package 종류설정: PACKAGE_CLASSES (rpm/ipk/deb) 중 설정 rpm이 default
Package 설정: PACKAGECONFIG
Image 설정: EXTRA_IMAGE_FEATURES
Disk Monitor 설정: BB_DISKMON_DIRS 모니터하며, 이 내부 Command 사용
PATCH 관련설정: PATCHRESOLVE (noop or user) 이며, patch가 실패했을 경우
CLASS 관련설정: USER_CLASSES inherit해서 설정할 수 있는 CLASS 영역설정

User Configuration 사항아래참고
https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#user-configuration

Build의 Directory 기본구성

Yocto 기반으로 Source를 Download하고 이를 Pacakge 및 Image를 만들어 아래의 장소에 넣고 작업을 한다.

build/tmp/deploy/images: Embedded System에 필요한 Image들
build/tmp/deploy/rpm or deb : 각 Package들
build/tmp/work : 보통 필요한 source들이 이 곳에 존재
build/tmp/work-shared: 공유가 필요한 Source들은 이곳에 존재

Build 의 구성
https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#structure-build

4.2 Bitbake 기본사용법

bitbake는 Yocto를 전체를 Control 해주는 system이며, shell과 python 사용하여 관리를 해주고 배포를 진행한다

bitbake 기본사용법

bitbake를 이용하여 아래와 같이 recipe를 실행을 해보고 세부 Task도 같이 실행을 해보자

$ bitbake foo   // foo 는 recipe/target 

$ bitbake foo  -c bar                  // do_bar Task 함수 동작진행 
or
$ bitbake -c bar foo 

$ bitbake recipe  -c bar -f   // do_bar Task 함수 강제실행  

$ bitbake recipe  -g foo     // graphviz를 제공  

$ bitbake -h  // 관련설명 확인 아래링크확인

$ bitbake -e   // 설정되어지는 환경설정값을 전부출력 (너무 오래걸림)

$ bitbake -e | grep ^VAR   // 값 설정되었는지 안되었는지 확인 및 검색 
// 1. 본인이 원하는 환경설정값을 검색하여 값 확인 
// 2. 이 값기준으로 검색하여 bb 파일 위치 파악

Bitbake Command (
https://www.yoctoproject.org/docs/1.8/bitbake-user-manual/bitbake-user-manual.html#bitbake-user-manual-command

Bitbake 전체 Manual
http://www.yoctoproject.org/docs/1.8/bitbake-user-manual/bitbake-user-manual.html

4.3 Bitbake 실행시 Yocto Sources 구성요소

기본적으로 Layer기반으로 구성이 되며, 아래의 요소들이 각각 구성이 각 필요로 한다.
이전의 Layer의 종류에 따라 각 필요하는 부분이 다르므로 관련부분에 대해 알아두도록하자.

Metadata(Recipes)

(*.bb) 파일로 파일 설정 및 빌드 방법 , 종속 문제 및 Recipes의 Version 등 종합적인 관리를 한다.

Configuration Files

(*.conf)로 구성이 되며 다양한 모든 Configuration 설정 을 담당하며, Main에 존재하는 bitbake.conf의 경우는 Compiler 관련 옵션 및 전체 설정을 담당한다.

Classes

(*.bbclass) 로 되며, metadata files사이들의 공유에 유용하며, classes라는 별도의 directory가 존재한다.
모든 recipes와 class가 자동적으로 항상 include 된 후 base.bbclass의 경우는 특별하다고 한다.
한마디라로 상위 metadata를 include할 때 사용하며, 특정 metadata와 공유하여, 각 상속개념으로 사용되어진다.
recipe안에서 class를 사용한다면, inherit를 이용하여 class를 사용한다.

Append Files

(*.bbappend)로 는 말그대로 파일을 추가하는 기능이며, 대신 이것을 이용하기 위해서는
(*.bb)와 이름과 동일하게 (*.bbappend) suffix가 다르게 사용하는 것이다.

Bitbake의 구성요소
https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#usingpoky-components-bitbake

Task

do_xxxx 로 구성이 되어있으며, Metadata(recipe) 안에 존재하며 이미 정해진 Task들도 존재하며, 본인 별도로 구성이 가능.
Task의 경우는 조금씩 달라질수 있으므로, 각각 Chip vendor에 따라 Yocto Manual을 참조

$ bitbake  recipe  -c task  // Task 실행
$ bitbake  recipe  -c task -f  // 강제로 Task 실행

일반적으로 사용되어지는 Task들 (Normal Recipe Task 참고)

do_fetch
do_unpack
do_patch
do_configure
do_compile
do_install
do_package
do_rootfs

Normal Recipe Task (참고)
  https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#normal-recipe-build-tasks

Kernel Task (참고)
  https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#kernel-related-tasks

Image Task
  https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#image-related-tasks

5. Bitbake의 순차적인 동작흐름

Bitbake의 시작을 보면 Source Mirror로 부터의 Source Fetch 진행를 시작으로 볼수 있겠으며, 이것이 행해지는 부분은 상위 Build Directory 안에서 진행이 된다.

bitbake 전체흐름
  https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#bitbake-dev-environment

Source Mirrors의 기본구성

Local Projects : Yocto의 내부에 포함되어진 File들
SCMs: Git , SVN
Upstream Project Releases: 정식으로 Release된 압축파일들

5.1 Source Fetch (Source Download)

Source Mirrors에서 do_fetch를 이용하여 download 하고 do_unpack으로 압축을 풀고 build directory에서 진행한다

sources: source의 recipe에 따라 fetch와 unpack를 진행
download : source mirrors에서 Upstream Project Releases 파일을 받아 저장 및 SCM 주소저장
build directory: download의 압축된 파일을 풀어 소스로 보관

사실 이 부분은 이해만 하고 recipe만들 경우 이미 Distro Layer에서 정해져있기 때문에 수정할 부분이 거의 없다고 생각하면 된다.
하지만, recipe를 만들 경우 Source Mirror에 따라 어떻게 사용방법이 다른지는 각각 파악하자

Task 작업

do_fetch: Source Mirrors에서 Source들을 가져오는 작업
do_unpack: 가져온 Source를 unpack하는 작업

주요환경변수 관련내용 (세부사항 아래링크)

TMPDIR: 상위 그림의 Build에서 tmp
PACKAGE_ARCH: 상위 그림을 보면 tmp/work/ 구성을 보면 알수 있다.
PN: Package Name ( Recipe name, Recipe를 작성시 PN_PV_PR.bb)
PV: Package Version ( Recipe version )
PR: Package Revision ( Recipe revision, default r0, 이며 거의 잘 사용안함)
WORKDIR: TMPDIR 안에 work
S: Build Directory에서 Package Source 위치

https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#source-fetching-dev-environment

5.2 Patching

Fetch를 하고, Download된 Source에 본인이 변경사항이 있다면, Source의 각 Layer의 receipe(*.bb)에 보통 *.bbappend를 만들어서 patch를 진행
이때 사용되어지는 Tool은 quilt (patch를 이용한 tool) 와 patch를 이용한다.

환경변수

S: Build directory의 Source의 위치이며, TMPDIR 기준으로 보면이해가 됨
TMPDIR: Build directory 의 tmp

Patch Files (*bb or *.bbappend)

SRC_URI: 각 Patch를 넣으면 Patch가 동작 하며 Suffix를 상위 (아래링크 참조)
FILESEXTRAPATHS_prepend: Patch할 File의 위치를 맨 앞에 등록

https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#patching-dev-environment

5.3 Config 및 Compile

Open source일 경우, 각 Configuration이 필요한 경우가 많으며, 이때 각각을 설정하며, compile 시 옵션도 추가가 가능하다

환경변수

S: Build directory의 Source의 위치
B: 기본적으로 S와 같지만, Build되는 곳을 말하는 것 같음
D: 목적지로 상위그림을 보면 image로 install되면 세부적으로 {bindir} 와 {libdir}

Task 구성

do_configure: download한 소스 configuration (meta/classes/autotools.bbclass) S 사용
do_compile: build 작업 이며 S와 B 사용
do_install : install작업이며 package 와 rootfs에 install 진행 (D의사용이지만, B도사용)

상위와 같이 구성이 되지만, do_configure는 생략이 가능하며, do_compile도 필요에 따라 생략이 가능하다.

https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#configuration-and-compilation-dev-environment

5.4 Package Splitting

Recipe의 경우 Package 기반으로 동작이 되기 때문에 Image를 만들 경우에도 사용되며, do_package를 이용하여 linux package를 지원한다.