Julram's 개발 낙서장

 - STL(Standard Templete Library)

    : C++의 템플릿을 사용하여 표준으로 정리된 라이브러리

     반복자 / 컨테이너 / 알고리즘 함수객체 등으로 구성되어 있다.

 - 컨테이너(Container)
    : 컨테이너는 기본 자료형과 사용자가 정의한 자료형을 담는 일종의 자료 구조

      클래스 템플릿 형태이므로 변수 선언할 때 컨테이너에 포함될 요소의 타입을 명시해야 한다.

      컨테이너에는 복사 생성과 대입을 할 수 있는 타입의 객체 및 변수만 저장할 수 있다.

      또한, 컨테이너는 요소의 추가 및 제거 등의 기능을 포함한 작업을 수행하는 멤버함수도 포함되어 있음

1. 시퀀스 컨테이너
   : 데이터를 선형으로(순서대로) 저장하며, 특별한 제약이나 규칙이 없는 가장 일반적인 컨테이너
   시퀀스 컨테이너에서 삽입된 요소의 순서가 그대로 유지된다.
   vector, deque, list, forward_list
   
   
2. 연관 컨테이너
   : 데이터를 일정 규칙에 따라 조직화하여 저장하고 관리하는 컨테이너
   set, multiset, map, multimap
   
   
3. 어댑터 컨테이너
   : 간결함과 명료성을 위해 인터페이스를 제한한 시퀀스나 연관 컨테이너에서 변형된 컨테이너
   단, 반복자를 지원하지 않아 STL 알고리즘에서는 사용이 불가능하다.
   stack, queue, priority_queue

RPC failed; curl 56 GnuTLS recv error (-110): The TLS connection was non-properly terminated.

Git 및 Git LFS 등을 사용하여 빌드되는 경우 큰 파일 또는 TLS 값 에러가 발생하는 경우는 파일 수령 시 파일 크기가 Git 설정보다 클 경우 깨지게 된다.

해당 부분을 해결 또는 회피하기 위하여 Git File Buffer 사이즈를 늘려 큰 파일을 받는데 문제가 없도록 수정해야 한다.

하기의 Config 를 참고로 버퍼 크기를 수정하도록 한다.

ex) git config --global http.postBuffer 1048576000

     또는 SSL Verify false --> git config http.sslVerify false 까지 추가

svn Repository 내에서 git 으로 이전 시 사용 되는 명령 내용 정리

git remote add origin (git 주소)

git svn clone svn://(svn 주소) -A users.txt --username (user id) --no-metadata

git push --set-upstream origin master --force

--no-metadata --> git-svn-id 태그 생성 막음

svn users.txt

user_id = user_name <user_id@email.com>

일반적인 리눅스 환경 및 Server에서는 history 명령 및 설정에 의해 각 경로의 .bash_history에 명령 내용이 저장되고 부팅 시 불려지게 된다.

임베디드 환경이나 설정이 정상적으로 되어있지 않은 경우에는 정상적으로 저장되지 못하는 경우가 발생하는데,

이를 해결 하기 위해서 하기의 명령어들을 설정해 주어야 한다.

크게 3가지로 하기의 환경변수를 /etc/profile 또는 유저 디렉토리 내의 .bash_profile에 내용을 추가해준다.

1. HISTFILE : history 명령 및 shell command 내용을 기록할 파일
                 대부분의 경우에는 export HISTFILE=/home/$USER/.bash_history 로 설정된다.

2. HISTFILESIZE 또는 HISTSIZE : HISTFILESIZE의 경우에는 파일의 크기를 나타내며, 후자의 경우는 라인수를 지정한다.

       HISTSIZE의 경우 default 값은 500 이다.

       export HISTSIZE=500 또는 HISTFILESIZE=1000

3. 명령행 실행 시 저장 관련 :  export PROMPT_COMMAND="history -a; history -c; history -r; ${PROMPT_COMMAND}"

위 명령을 추가하여 쉘을 통해 명령 실행 시 저장될 수 있도록 지정해준다.

위 내용들이 정상적으로 적용되어 있는지 경로가 맞는지 확인은 쉘에서 echo ${env} 하여 확인하여 설정을 확인 한다.

ex)

echo $HISTFILE

echo $HISTFILESIZE or $HISTSIZE

echo $PROMPT_COMMAND

Rockchip AP는 세가지의 Booting Mode를 가지고 있으며, BootLoader 가 이상이 있거나, 업데이터를 이용하여 업그레이드가 불가능해졌을때 Mask Rom 모드를 통하여 수정하거나 하는 등의 동작 수행이 가능하다.

Rockchip AP의 부팅 순서는 다음과 같다.

1. power-up initialization (전원 인가)

2. 특정 저장장치 안의 부트로더를 확인하기 위하여 BootRom code를 SRAM 에서 동작 시킨다.

3. 부트로더가 확인 된 후, 부트로더의 부트 코드를 불러와 실행한다.

4. 부트로더의 부트 코드는 DDR 메모리를 초기화 하고, 부트로더의 전체 코드를 초기화된 DDR 메모리로 적재하고 부트로더를 실행한다.

5. 부트로더가 지정된 주소로부터 커널을 읽어 램에 적재하고, 커널로 점프 및 실행 한다

Loading Mode

Rockchip에는 BootRom 과 내부 SRAM을 통해 초기화 코드가 진행된다. 초기화 동작 및 하기의 메모리들로 부터 데이터를 읽어 들일 수 있도록 로드한다.

• 8-bit Async Nand Flash

• 8-bit toggle Nand Flash

• SPI interface

• eMMC interface

• SDMMC interface

추가적으로, 이 펌웨어는 USB OTG 인터페이스를 통해 다운로드 및 변경이 가능하다.

Boot Mode

Rockchip AP는 크게 세가지의 부팅 모드를 지원한다.

• Normal mode
  : 일반적인 startup procress로, 각 필요 요소들을 로드하여 시스템을 정상적으로 부팅하는 모드
  
  

• Loader mode
  : 부트로더에서 업그레이드 상태로 전환하고 호스트의 업그레이드 명령을 기다린다. 일반적으로 부트로더를 통하여 업그레이드가 필요한 상태일 경우 접근하는 방법
  
  이 모드로 전환하려면, 지정된 RECOVERY KEY를 눌러 부트로더에서 해당 Pin을 체크하여 전환한다. 또한 지정된 USB OTG 포트가 연결되어 있어야 한다.
  
  

• MaskRom mode
  
  : MaskRom mode는 부트로더가 정상적이지 않을 시 시스템 복구에 사용된다.
  
  일반적으로, BootRom 코드는 MaskRom mode로 전환되지 않으며, BootRom 코드 동작 시 부트로더가 읽을 수 없거나 손상으로 인하여 확인할 수 없는 상황에서만 진입이 가능하다.
  
  그 후 BootRom 코드는 USB interface를 통하여 Bootloader code가 전송되는 것을 기다리며, 인식된 Host PC 에서 로더 및 코드를 USB를 통하여 전달되면 실행되며 Loader 모드와 같이 업그레이드 할 수 있는 상태로 전환된다.

참조 : http://opensource.rock-chips.com/wiki_Main_Page

일반적인 Rockchip AP의 부팅 흐름 및 Rockchip Wiki의 내용을 정리 및 설명한 글입니다.

글 하단에 참조된 Rockchip wiki에서 추가적인 내용 및 영문 내용을 확인 할 수 있으니 참고 바랍니다.

Rockchip 부팅 흐름에서 부트로더 단계에서 두개의 스테이지를 가지고 있는데, 첫번째 스테이지는 Rockchip의 miniloader 또는 u-boot의 tpl/spl 단계에서 ddr initialize 및 초기 설정 후 두번째 스테이지에서 kernel 로 점프하기 위한 준비를 위하여 u-boot을 실행한다.

• U-Boot TPL/SPL or rockchip U-Boot, fully source code
• Rockchp idbLoader which is combinded by Rockchip ddr init bin and miniloader bin from Rockchip rkbin project;

일반적인 U-Boot 부팅 스테이지 사용 시 하기의 표를 참고

Boot Rom에 Rom Code(idbLoader)를 Write하여 ddr init 및 초기 AP initialize가 필요한 부분을 수행하고 u-boot 코드로 점프하게 된다.

일반적인 이미지 업데이트 모드는 u-boot 에서 GPIO Pin 형태로 Boot-pin 또는 switch 인식하여 전환하게 되는데,

만약 BootRom 내에 이미 Code가 Write 되어 Rom 내역을 수행하고 U-Boot로 jump하는 흐름에서 문제 발생되었을 때는 정상적으로 부팅을 하지 못하게 된다.

이 상황에서 Mask Rom 모드로 진입이 가능하도록 eMMC 또는 부팅 매체로 jump되지 못하도록 설정하여 Rom 이미지를 다시 Write 또는 설정한다.

Rockhip AP의 Boot Flow는 아래의 그림과 같다.

위의 그림에서 각각 나와 있는 부팅 흐름은 크게 두가지이다.

• Boot Flow 1 : 일반 적인 Rockchip Boot Flow로 Rockchip miniloader 바이너리를 사용
• Boot Flow 2 : 일반적인 대부분의 AP 부팅 시퀀스로 U-Boot TPL/SPL에서 DDR init 을 진행하고 다음 스테이지 진행

보통의 경우 위의 두 가지 중 Boot Flow 1을 주로 쓰며, 바이너리 형태로 배포되는 miniloader 를 rkbin github에서 받아

Android Tool을 이용하여 프로그램을 넣는다.

*rkbin github : GitHub - rockchip-linux/rkbin: Firmware and Tool Binarys

rkbin 내용은 바이너리 형태로만 배포되며 miniloader 실행 시 포함된 ddr_xx.bin 바이너리 등에 의해 장착된 DRAM 의

사이즈와 연결 상태 및 간이로 DQS를 설정하도록 되어 있다.

DDR 설정 이후 u-boot.img로 점프 후 커널을 로드하기 위한 u-boot 코드가 실행되고 이후의 시퀀스는 일반적인 임베디드 리눅스 커널과 동일한 방식으로 커널이 로드된다.

DDR 설정을 배포된 바이너리에서 설정하게 되므로 커스터마이즈 및 보드 설계 시 지원되는 DRAM의 파트를 확인해야 하며 Pin Layout에 유의 해야 한다.

위의 부팅 시퀀스 이미지 중 ARMv8 이상의 프로세서 또는 안드로이드에서의 Trusted Boot 을 지원하기 위하여 별도의 Trust.img 또는 bl31, bl32.elf, tee.bin 가 존재한다.

Security Boot(Trusted)는 리눅스에서도 적용이 가능하나 적용이 필요 없다면 U-boot에서 zImage 와 dtb 파일을 로드하여 커널 부팅을 진행하면 된다.

다만, Bootloader(U-boot) 빌드 시 u-boot.img 파일이 필요하므로 빌드 시 img 파일이 생성될 수 있도록 한다.

(Rockchip SDK의 경우 'mkimage' 등의 커맨드를 통해 Rockchip 이미지용 img 파일 생성 레시피가 적용되어 있다.)

Android Tool 등의 사용 시 유의해야 할 사항은 Rockchip AP RK31xx, RK33xx 등의 경우 Rockchip Partition으로 생성되므로 커널에서 해당 옵션이 포함되어 빌드 되었는지 참고 하여야 한다.

Rockchip Partition으로 생성되어도 파일시스템 형식은 ext3,4 등 정상적으로 생성되는 것으로 확인된다.

(이게 왜 별도로 만들어졌는지는 모르겠다....)

Rockchip AP 프로그래밍 시에는 위의 설명과 같이 ROM Code 프로그램과 Secondary BootLoader 부분에 유의하여 진행하면 다른 문제점 없이 정상 동작됨을 확인할 수 있다.

파일시스템 관련은 init 시퀀스이므로 Ubuntu, Debian, Buildroot(Busybox)등의 종류 상관없이 모두 정상적으로 Rootfs 파티션에 위치해있고 'init=' 과 파일시스템 마운트 옵션만 지정한다면 정상 동작 할 것이므로 생략한다.

참고 : http://opensource.rock-chips.com/wiki_Boot_option