갈길이 멀다

흐.. 쉬운게 없구나..

어제 드디어 dpslink를 돌려 볼려고 했다..

근데… 덴장… 이놈의 모듈들은 올라가지도 않고… loadandrun 이라는 DSP 쪽 로더로 보이는

넘은 실행도 안된다.(분명 파일이 있는데 자꾸 그런거 없단다.)

2.4 커널로 부팅해서 해보니, 여전히 loadandrun은 안되는데 모듈은 로드가 된다. 약간의

메시지가 출력되긴하지만..

아무래도 2.4대와 2.6대의 커널 모듈이 좀 다른듯 하다.. 단순히 확장자만 다른게 아니었단 말인가;;

(2.6에서 올릴려고 해보면 올바른 포맷이 아니라고 나온다)

일단은 모듈을 2.6에 올리는 작업부터 하기로 했다. 리눅스 커널 모듈 프로그래밍을 해 본적이

없는 나로써는 그야말로 앞이 깜깜했다.. 그래도 어쩌겠는가.. kldp로 가서 열심히 찾아보았다.

그래서 발견한 곳이

역시나 2.4에서 2.6으로 바뀌면서 변경된 부분이 많덴다..

일단 문서에 나왔있는 hello, world 모듈을 만들어서 PC에 올려보고…

OMAP에도 올려봤다.. 그런 대로 동작하는 듯 하다.

(이때, makefile은 커널 소스에 있는걸 땡겨 쓰는것 같은데 좀 어려워 보여서 그냥 썼다.)

이제 모듈 두 개를 2.6용으로 새로 만들어야 하는데… 이것참 막막하다-_-;;

dsplinkk.o 를 만드는 소스 쪽에서 모듈 초기화 등등의 인터페이스가 구현된 부분을 찾으려고 했는데..

도저히 못찾겠다. makefile도 분산되어서 여기저기서 include하기 땜에 복잡고 @_@

그래서 일단 pmr_drv.o 라는 넘을 바꿔보기로했다.

이넘은 미리 컴파일 되서 제공되는데… 다행히 소스가 rta_sdk_5_00/ti/bios/rta/sdk/src/pmrdrv에

있었다.

일단 모듈 인터페이스 부분을 고칠려고 봤더니.. 2.6 에서의 형식으로 되어있었다…

흠.. 전에도 썼던 방식인가… 그럼 컴파일만 새로 해보자…

음.. 근데 어떻게 해야 될지 잘몰라서… 일전의 예제에서 썼던 makefile을 복사해다가 수정해서 썼다.

그리고 make…

오호.. 일단은 pmr_drv.ko 라는 파일이 생겼다.

이걸 OMAP에 올려서 insmod를 하니까 문제 없이 올라간다.

흐흐.. 좋았어.. 다음은 다시 dsplinkk.

흠.. 근데 이게 좀 곤란하다.. 도저히 못찾겠다.

그때, 문득 꽁수가 떠올랐다. pmr_drv도 모듈인터페이스는 2.6방식이었으니까, 이놈도 그럴꺼다.

그리고, 앞의 두 경우를 봤을때, .ko 파일은 .o 파일을 바탕으로 만들어지는 듯 하다…

그렇다는 것은…..

커널의 makefile을 잘 이용하면 현재 만들어진 .o 파일을 .ko로 바꿀수 있지 않을까…

그래서 일전의 makefile을 복사하고, 더미로 dsplinkk.c 라는 파일을 만들고,

아무것도 안하는 dsplinkk.c 타겟을 makefile에 추가하고.. make!

오호.. 그 결과 dsplinkk.ko가 생겼다. 이걸 OMAP에 올려보니 잘 올라가는군 :)

근데 이게 진짜 제대로 만들어진 건지는 알수 없다. ;;;

방법은 예제를 돌려보는 것…

그러려면 일단 loadandrun 이 돌아가야 하는데…

아무래도 이게 실행이 안된다.. 그래서 고민하다가 OMAP의 파일 시스템을 둘러보던중…

웃…. 모든 명령이 busybox에 심볼릭 링크로 걸려있다.

이게 도대체 먼가;;;

이런저런 실험을 해본결과… 내가 얻은 결론은 이렇다.

이 루트 파일시스템에서 실제로 실행이 되는 파일은 busybox 밖에 없다.

(아.. busybox라는 넘은 유닉스계열에서 쓰는 웬만한 명령은 모두 내부 명령으로 포함하고 있는

작은 크기의 유용한 프로그램이다.)

그리고 나머지 명령들은 모두 busybox에 심볼릭 링크로 걸려있다. 그래서 각 명령을

실행하면 실제로는 busybox가 실행되면서 해당 명령을 수행한다.

예를 들어 ls를 실행하면,

실제로는 busybox가 실행되고, 이때 main()의 아규먼트 중 첫번째인 실행파일명은 ls가 된다.

busybox는 이를 이용해 ls 기능을 수행하고 결과를 보여준다.

아아.. 놀랍지 않은가… 쉘 내부 명령으로 처리한다기 보다는

실제로 busybox를 하나 더 실행하면서 파라메터로 수행해야되는 기능명을 넘겨서

해당 기능을 수행하는 것이다.

그건그렇고.. 그래서 도대체 왜… 그외의 외부 파일은 실행이 안되느냔 말이다-_-;

busybox의 소스를 뜯어고칠까도 생각했지만… 일단 기본 쉘을 bash로 바꾸면 간단할 거 같았다.

애당초 쉘로 busybox가 실행되기 때문이니까…

그래서 bash의 소스를 구해서 컴파일하고, 올려보았다.. 어라.. 근데 이게 잘 안된다..

그래서 요리조리 해보던중… 두둥…. init 마저도 busybox의 심볼릭 링크 였다-_-;

이렇게 되면 init도 새로 설치하고 만다~

그래서 이리 저리 해서 컴파일하고, 설정하고, 올렸는데…

이런이런… 부팅이 안된다-_-;

아씨.. 수련이 부족하다… 좀더 수련을 쌓아서 다시 도전해야겠다;;;

DSP/BIOS LINK 컴파일 성공

끙… 간신히 컴파일에 성공.

몬타비 스타 리눅스 깔아 볼랬더니…

패스워드 암만 쳐도 안되고..-_-;;;

해서 고민 하다가 결국…. make 파일을 뜯어 고치기 시작…

흠… 보니까 생각 보다 쉽더군…

딴게 아니고… 몬타비스타 리눅스에 포함된 툴체인 쪽으로 패스가 지정되어 있는 거두만..

그래서 그걸 우리의 gcc 툴체인쪽 패스로 변경…

문제 없이 잘되는 듯 하다가… 난데없이…
    current->prio

란 부분에서 prio가 스트럭쳐의 멤버가 아니라네;;;;

도대체 먼지…. 어디의 머하는 넘인지도 모르겠고…

여기저기 뒤져서 간신히 linux/sched.h 에 정의된 task_struct 라는거 까지 알았는데…

암만 봐도 멤버에 prio가 있거든;;;

결국 저 부분을 0으로 변경해서 일단 컴파일 통과~

방금은 ARM 쪽 DSP/BOIS Link였고.. 다음은 DSP 쪽…

흠.. 이쪽 make 파일도 가이드를 참조해서 수정하니.. 약간의 시행착오 뒤에 손쉽게 성공.

자.. 이제 남은 건 예제를 돌려 보는….

그러려니 OSK를 설치 해야 되잖아… 귀찮쿠로..-_-;;

그래서 일단 테스트는 다음으로 넘기고….

아까 문제의 prio 를 해결하기로 결정.

흠… 여기 저기 뒤적이다 보니 문득 생각나는게…

툴체인에서 리눅스쪽 헤더를 쓸때 어디껄 땡겨쓰지?

호스트의 리눅스 헤더는 아닐꺼 같고…. 흠…..

아… 툴체인 디렉토리 밑에 arm-linux란 디렉토리가 있었지.

음.. 역시… arm-linux/sys-include 를 확인하니 리눅스 헤더가 있군.

근데 여기 있는 linux/sched.h를 보니 prio 가 없다!!

대신 nice가 있네… 이건 2.4에 해당 사항인거 같은데…

아마 툴체인에 포함된 헤더가 2.4 인듯…

해서… omap용 리눅스 커널 소스에서 헤더를 가져다가 (심볼릭 링크) 다시 컴파일 해보니

문제의 prio 부분은 무사 통과….

근데 remap_page_range() 라는 함수의 파라메터 갯수가 DSP/BIOS Link 소스하고 헤더에 정의 된게 다르다..-_-;;

끙… 일단 첫번째에 파라메터를 추가한 다음에 다시 컴파일 하여 일단 작성은 성공.

자… 오늘은 여기까지 하고 나머지는 다음 번에…

흑… linux dsp tools….

머가 이렇냐..-_-

함 설치해볼라 했드만….

설치에 관련된 메이크 파일이 몬타비스타 리눅스 같은 거에 맞춰져 있고 이케…

그래서 머를 바꿔줘야 되는지 볼려고..

osk에 딸려 나오는 preview kit을 깔랬더니… 패스워드를 넣으라네;;;

패스워드는 사용자 등록하면 메일로 보내 준다나…

그래서… 사용자 등록까지 했건만…. 메일은 도대체 언제 오는거냐?-_-;;;

———————————————————————-

흐흐… 드디어 패스워드 도착…

 CaZsPQ6DY4ZVvJu

이제 설치 해 볼 수 있는 건가 @_@

— 낭창 (2004-11-19 16:37:23)

devfs

Device File System.

기존의 /dev 디렉토리를 대체하기 위한 가상 파일 시스템이다.

디스크에 직접 생성된 /dev 디렉토리를 사용할 경우에는 장치에 대한 파일을 MAKEDEV 프로그램을

이용해 직접(자동이든 수동이든) 만들어 주어야 하며,

devfs를 사용할 경우에는 디바이스 드라이버에 따라 자동적으로 파일이 표시된다.

(이 가상 파일 시스템이 마운트 되는 위치는 역시 /dev 이다.)

커널 2.3.46 이후 버전 부터 지원되며, 어디 까지나 옵션 사항으로 원한다면 얼마든지

기존의 디스크의 /dev 디렉토리 방식을 사용 할 수 있다.

머… 이외에도 이런 저런 내용이 많은데.. 아직은 잘 모르겠네..;;;;

암튼 메모리를 약간 더 먹는 거 말고는 이래저래 장점이 있는거 같은데…

udev라는게 또 이 devfs를 대체하기 위한 거라고 했던가?…;;;

암튼 devfs에 대해 자세한건 여기에…(링크가 죽어버렸다-_-)

initrd

부트 로더 초기 램 디스크 (boot loader initialized ram disk).

초기 커널 부팅 시 사용되는 특수한 목적의 램디스크라고나 할까….

부트 로더에 의해 커널과 함께 로드 되고,

커널에 의해서 루트 파일 시스템이 마운트 되기 전에 마운트 된다.

원래 목적은 시스템 설치 시에 모듈을 사용하여 커널 설정을 하기 위해서 였으며,

루트 파일 시스템을 사용하기 위해서 추가로 모듈이 필요한 경우 등에 쓰인다.

initrd가 마운트 된 상태에서 /linuxrc가 실행되며,

/linuxrc의 마지막에 실제 루트 파일 시스템이 루트 디렉토리에 마운트 되고 init이 실행,

그리고 initrd가 언마운트 된다.

initrd를 사용할 경우에는 initrd=<path> 가 부트로드에 의해 커널에 부트 파라메터로

전달되어야 하며, 사용하지 않은 경우에는 noinitrd가 전달되어야 한다.

또한, initrd로 사용되었던 램 디스크를 그대로 루트 파일 시스템으로 사용할 경우에는

root=/dev/ram0 (devfs 사용하지 않을때) 또는 root=/dev/rd/0 (devfs를 사용할 때)가

추가로 전달되어야 한다.
흠.. 이 정도가 내가 이해한 initrd에 대한 간단한 내용

자세한 내용은 여기 참조

램디스크 이미지 만들기

호… 임베디드 리눅스 어쩌고 하는 책을 뒤적이다가 램디스크 이미지 만드는 법을 익혔다.

$ dd if=/dev/zero of=ramdis_arm bs=1k count=5120

$ mke2fs ramdisk_arm

일단 1k 크기의 블럭을 5120개 가지는 빈 파일을 만들고(5120k),

mke2fs 등을 이용해서 파티션 생성한다.(램디스크 크기를 변경하면 커널 소스를 손봐야함)

$ mount -t ext2 -o loop rmadisk_arm ramdisk

그리고는 -o loop 를 사용해서 루프백 장치로 마운트.

아.. 이때, 루프백 장치를 커널에서 지원해야지만 사용가능 하다.

이렇게 하면 보통 파티션을 쓰는것 처럼 자유롭게 이미지 않에 읽고 쓰기가 가능.

$ gzip -vf9 ramdisk_arm

그리고… 실제로 쓰일때는 크기를 줄이기 위해서 gzip으로 압축해서 이미지 완성.

실제로 램디스크를 쓸때는 알아서 압축을 풀어서 쓰기 땜에 걱정할 필요는 없다.

/dev

흠… /dev에 파일이 없어서 드라이버가 하나도 없다고 생각 했는데…

devfs를 마운트 시키니까 다 보이는 구나…;;;

/dev가 실재하는 파티션이 아니고 그냥 /proc 처럼 가상적인 파티션인지…

아님 실제 파티션과 devfs를 사용한 가상 파티션 두가지가 있는건지 일단 알아봐야겠군…

그리고 새로 도입되었다는 udev 라는 것도…

크… 머리 아프다-_-;

부팅 완료 ^^v

드디어 부팅을 완료했다.

첨엔 nfs를 rootfs로 설정 하는걸 못해서 헤메다가-_-;

문서를 뒤적여서, 부트 파라메터에

root=/dev/nfs nfsroot=xxx.xxx.xxx.xx:/yyy/zzz

라고 적어 줘야 된다는걸 깨닫고 재시도.

그러나 실패-_-

도대체 왜 nfs를 못잡는 걸까…

2.4.x는 nfs를 잘 잡는걸로 봐서 nfs 설정 문제는 아니고…

우.. 정말 산넘어산….

그래도 혹시나 해서 커널 설정 메뉴를 뒤적여 보았다.

아무리 봐도 nfs support는 설정되어있는데…. 라고 생각하던 순간!

눈에 들어온것이 rootfs로 nfs 사용 이라는 옵션!!!

이거다! 바로 설정 하고 재컴파일

플래쉬롬에 복사하고… 리셋..

오… 드디어 부팅 성공~ ^^V

흐흐…

근데…

이젠 멀하지..-_-a

일단 생각해 볼 수 있는건 현재 상태에서 디바이스를 다 잡는것.

현재 2.6.9에서는 디바이스가 시리얼 밖에 없더라고;;; (흠.. 커널설정이나 디바이스 파일을 만들어주는 것 만으로 해결 될지도 모름)

다른건… 커널 올리는건 성공했으니까… 이제 DSP 쪽하고 연동하는 거에 대한 거 해보는거..(?DspLink 였나..)

음.. 암튼 천천히 생각해 볼 문제..
p.s. 쩝.. 앞으로는 tftp로 커널 올려야 겠다.. 시리얼 포트로 하는거 보다 훨씬 빠르고 이케-_-;;