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

smbd 실행 시 Out of Memory 또는 실행이 되더라도 정상적으로 동작하지 않을때, 디버깅 및 실행에 관련된 사항을

확인하기 위하여, smbd 를 foreground 및 stdout 옵션을 주어 실행되는 내용을 확인한다.

$ smbd -F -S --debuglevel 3

위와 같은 메세지가 출력되는 것을 확인 할 수 있으며, 아래와 같이 top 으로 확인 시 메모리가 계속해서 누수가 발생하여, 결국 Out of Memory 로 인해 커널에서 프로세스가 죽게된다.

이런 경우, 위의 Debug 메세지와 같이 iconv 에서 변환하려는 과정에서 Memory Leak 이 연속적으로 발생하게 되고,

메모리 한계치에 도달하게 되면 위와 같이 프로세스가 강제로 죽게된다.

이 문제점을 해결하기 위해 /etc/samba/smb.conf 에서 아래의 옵션을 추가하여 iconv 함수 내에서 memory leak을 우회하여, samba가 정상적으로 동작 할 수 있도록 설정하여 막을 수 있다.

dos charset = UTF-8
display charset = UTF-8

위의 옵션을 추가하여 재실행을 하거나, cp850.so 파일을 생성하여 해결이 가능하지만, utf-8 로 손쉽게 처리가 가능하다.

포팅된 touchscreen을 TSLIB에서 사용하기 위해서, ts_test 등의 tslib를 사용 할 때,

나타나는 현상

/dev/input/event0로에서 'cat /dev/input/event0 | hexdump' 를 통해 정상적 이벤트가 발생됨을 확인을 전제

TSLIB 환경변수 및 ts.conf 또한 정상적으로 세팅 되어있을때,

동작하지 않을경우에는 커널버전 과 TSLIB Protocol 버전 또는

evbit 등의 세팅이 맞지 않을경우이다.

최신의 TSLIB는 뜨지 않으며, 낮은버전을 사용할 경우 발생 하게 되는데

patch work를 통해 확인한 결과는 아래와 같다.

 static int check_fd(struct tslib_input *i)
 {
 	struct tsdev *ts = i->module.dev;
 	int version;
-	u_int32_t bit;
-	u_int64_t absbit;
+	long evbit[BITS_TO_LONGS(EV_CNT)];
+	long absbit[BITS_TO_LONGS(ABS_CNT)];
+	long keybit[BITS_TO_LONGS(KEY_CNT)];
 
-	if (! ((ioctl(ts->fd, EVIOCGVERSION, &version) >= 0) &&
-		(version == EV_VERSION) &&
-		(ioctl(ts->fd, EVIOCGBIT(0, sizeof(bit) * 8), &bit) >= 0) &&
-		(bit & (1 << EV_ABS)) &&
-		(ioctl(ts->fd, EVIOCGBIT(EV_ABS, sizeof(absbit) * 8), &absbit) >= 0) &&
-		(absbit & (1 << ABS_X)) &&
-		(absbit & (1 << ABS_Y)) && (absbit & (1 << ABS_PRESSURE)))) {
-		fprintf(stderr, "selected device is not a touchscreen I understand\n");
+	if (ioctl(ts->fd, EVIOCGVERSION, &version) < 0) {
+		fprintf(stderr, "tslib: Selected device is not a Linux input event device\n");
 		return -1;
 	}
 

위와 같이 input-raw.c 에서 EV_VERSION과 ,evbit과 absbit 등을 ioctl로 확인 후에 touch driver로 인식한다.

이 과정에서 맞지 않을 경우 비정상 종료가 이루어져 driver가 제대로 호출되지 않게 된다.

그에 따라 input driver의 bit세팅값 또는 EV_VERSION을 확인해야 한다.

단적인 예로

낮은버전은 0x010000이여야만 가능하다.

TSLIB가 높은 경우 + 코드와 같이 버전과 관계없이 실행된다.

File - "<kernel home>/include/linux/input.h"

-- #define EV_VERSION              0x010000

++ #define EV_VERSION              0x010001

이외의 상황이라면,

driver의 문제 또는 ts.conf의 값을 변경해야함

라이브러리 로딩 ld.so.conf

크로스 컴파일 실행파일 no such file or directory 문제

크로스 컴파일 하여 타겟 보드에 넣었을 때 실행되지 않고,

no such file or directory 가 출력되는 경우에 해결하는 방법입니다.

실행시 no such file or directory가 출력되는 실행파일을 file 명령어를 통해

Shared Library를 확인 합니다.

file 해당파일

ex)

test: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.16, not stripped

file 명령어를 실행하면 그 파일의 ELF 정보 및 사용하는 공유 라이브러리 정보가 나옵니다.

실행파일에서 사용하는 공유라이브러리가 /lib 혹은 /etc/ld.so.conf 파일에 저장되어 있는 경로에 있는지 확인 합니다.

없을 경우에는 타겟보드에 저장된 올바른 라이브러리 파일을 생성하거나 심볼릭 링크를 통해 생성 합니다.

ex) ld-linux.so.3 파일이 없어서 나타나는 경우

/lib 디렉토리내에 ld-linux.so.3가 없어 나타나는 경우에는 대게 arm 라이브러리 중 ld-linux-armhf.so.3가 있습니다.

ld-linux.so.3는 프로그램이 메모리에 적재되는 시점에서 실행에 필요한 라이브러리를 링킹해주는 파일입니다.

이 링킹은 target platform인 Arm 에서는 ld-linux-armhf.so.3가 담당합니다. 그에 따라 복사 또는 파일명 변경이 아닌 심볼릭 링크를 걸어주어야 합니다.

sudo ln -s /lib/ld-linux-armhf.so.3 /lib/ld-linux.so.3

정상적으로 파일을 생성 혹은 링크했다면, 재실행 시 문제되지 않고 정상 실행이 될 것 입니다.