우오오오~

 

성공했다~ T-T

어젠 마저 안 썼지만…

2.6.9 는 디버깅 모드에서도 암것도 안 찍어 줬지만…

우리의 2.6.8-rc3는~~~

Error: a

를 찍어 주었더랬다!!!

빠밤…. 그럼 도대체.. Error: a는 무엇이냐

커널에 디버깅 옵션이 켜져 있을 때만 찍어주는 메시지 인데…

부트로더(이 경우에는 u-boo)는 커널(이 경우에는 linux)을 시작 시킬 때, 정보를 넘겨 주게 되어 있다.

이게 arm 계열의 경우가 스트럭쳐 였던가… ppc 가 그랬던가는 기억이 잘 안나지만…

암튼 그래서…

그 정보중에는 아키텍쳐 번호(architecture number)라는 것이 있어서…

이 넘이 커널이 알고 있는 것과 맞아야만 부팅이 진행되는 것이다.(아마 보드 종류인거 같다)

Error: a 라는 것은 바로 이 아키텍쳐 번호가 커널이 알고 있는 거 중에 없다는것.

그럼 봐야 할 곳은 u-boot에 설정된 아키텍처 번호와 리눅스 커널에 설정된 아키텍처 번호이다.

(당근 omap5912osk의 아키텍처 번호)

일단 u-boot에서 아키텍처 번호를 알수 있는 메뉴를 찾아보았다.

그때 눈에 띈 것이 bdinfo! 역시나 이 명령은 보드의 정보를 보여주는 것으로

제일 첫 줄에 아키텍처 번호가 나왔다.

?OMAP5912 OSK # bdinfo

arch_number = 0x000000EA

env_t = 0x00000000

boot_params = 0x10000100

DRAM bank = 0x00000000

-> start = 0x10000000

-> size = 0x02000000

ethaddr = 00:00:00:00:00:00

ip_addr = 100.101.1.2

baudrate = 115200 bps

0x000000EA 라… 십진수로 바꿔보면 234. u-boot 소스 중에 board/omap5912/omap5912osk.c의

65 번째 줄에서 arch_number라는 것을 설정하는 것을 찾을 수 있었다.

/* arch number of OMAP 1510-Board */

/* to be changed for OMAP 1610 Board */

gd->bd->bi_arch_number = 234

흠.. 주석에 OMAP 1510-Board 라고 되어 있는 것이 수상쩍다.

이번에서 리눅스 커널 소스에서 아키텍처 번호를 찾아 보자…

여기 저기 뒤적이다가 발견한 것이 arch/arm/tools/march-types.

파일을 열어 보니.. 오오~ 아키텍처 번호로 보이는 것들이 주욱 쓰여져 있다.

omap_innovator MACH_OMAP_INNOVATOR OMAP_INNOVATOR 234

예상대로… 234는 ?OMAP1510 을 쓰는 omap innovator의 것이었다.

그럼 ?OMAP5912 OSK는?

omap_osk MACH_OMAP_OSK OMAP_OSK 515

원래는 515였군… 으.. 썩을 u-boot 같으니… 어쩌면 2.4에는 osk가 따로 없었는지도 모르니

일단은 참기로 하고…

u-boot 쪽과 리눅스 커널 쪽의 아키텍처 번호가 다르니 한쪽을 고쳐 줘야 되는데…

u-boot를 고치는게 맞겠지만.. 그렇게 할려면 u-boot를 새로 올려야 되니…

일단 리눅스 커널쪽을 고쳐서 재컴파일….

커널을 올리고… 두근 거리는 맘으로 bootm.

Starting kernel …

Uncompressing Linux………………………………………………………

이까지 나왔을 때 얼마나 조마조마 하던지……

다음 순간…

주루륵 올라가는 글자들!

순간 만세를 부르면 뛰쳐… 나가지는 않고 뒤로 발라당 넘어져 버렸다~

(집에서 컴퓨터를 쓸때는 침대에 걸터 앉아있음)

아… 이렇게 기쁠 수가.. 장장 2~3주간 끌어오던 문제가 해결되는 순간 이었다.

이 기쁜 소식을 빨리 누군가에게 전하고 싶어 당장 msn을 켜고 한승훈에게 말해줬지.

음하하~

아… 물론 부팅에 완전히 성공한 것은 아니다. 부트 파라메터를 잘못줘서 rootfs를 마운트 하지 못했다.

흐.. 하지만 이런건 좀 손보면 되는 문제니까 :)

오늘은 발뻗고 잘 수 있겠다.

아…

한가지 더 덧붙이자면…

리눅스 커널이 처음 부팅될때, 아키텍처 번호를 검사하기에 앞서 프로세서 타입(Processor Type)을 검사한다.

이 때도 역시 맞지 않으면, p 라는 에러 메시지를 출력한다.(물론 디버깅 옵션이 켜져있으면)

이 정보는 리눅스에서는 arch/arm/mm/proc-arm926.S에 __arm926_proc_info에 나오는 듯 하고,

u-boot에서는 잘 모르겠다-_-;

암튼… 오늘은 요까이~

원인

Uncompressing………………………………….

done, booting the kernel.

라고 나오며 더 이상 부팅이 진행 되지 않는 경우…

즉, 현재 내가 겪고 있는 문제의 경우…

다음과 같은 것이 원인 일 수 있는거 같다.

  • 컴파일시 커널 주소설정과 로딩한 주소가 맞지 않은 경우
  • 콘솔로 시리얼 포트외의 다른 장치(LCD 등)이 설정된 경우
  • 부트로더와 커널의 시리얼 포트 설정이 서로 맞지 않은 경우
  • TEXTADDR 값을 이상하게 고친 경우-_-
  • 시리얼 포트 설정을 잘못한 경우(포트 번호나 baudrate 등)
  • 부트 로더 설정이 잘못된 경우
  • 커널 패치를 제대로 안 해준 경우

(from http://www.kelp.or.kr)

흠… 내 경우에는 어떤 것이 원인일지…;;

u-boot 명령

중 가장 많이 쓰고 있는 것들…

>> loadb

>> erase 1:8-16

>> cp.b 0x10000000 0x100000 6cd45

>> bootm

파일을 받아서 ram시작주소(0x10000000)에 저장하고,

flashrom bank 1의 sector 8에서 16까지 지우고,

0x10000000에서 0x100000로 6cd45 만큼 복사하고,

부팅~

지겹다=_=

결국…

압축을 풀고 제대로 점프한다는걸 알았다-_-

0x10008000 에 풀고, 점프~

저번에 어떤 문서에서 ARM은 ram시작 주소(osk는 0x10000000)에서 0x8000 떨어진 곳(0x10000000 + 0x8000 = 0x10008000)에서 부터 커널이 들어가야 된다고 본거 같은데..

그럼 주소도 맞고…

그럼…

도대체…

머가 문제라서 점프 후 무소식이란 말인가=_=

u-boot용 이미지 만들기

리눅스 커널 컴파일을 하여 이미지를 생성한 후에,

$ arm-linux-objcopy -O binary -R .note -R .comment

-S arch/arm/boot/compressed/vmlinux linux.bin

$ gzip -9 linux.bin $ mkimage -A arm -O linux -T kernel -C gzip -a 0x10008000 -e 0x10008000

-n “?LInux Kernel Image -d linux.bin.gz uImage.cc

현재…

u-boot에 커널이미지를 올려서 커널을 로딩하는데 까지는 성공한 상태이나..

커널이 압축을 해제한 다음 실제 시작점으로 점프하는 부분부터 안되고 있음.

이 부분이 점프하는 주소가 잘못된 것이라 추측하고….

압축 푸는 주소, 점프하는 주소, omap5912 부팅시 써야 하는 주소 등등을 고려중..