---------------------------------------------------------------------------------
* Enviroment
---------------------------------------------------------------------------------
Host Platform : Ubuntu 9.04, i386
Target Platofrm : Corebell LDS2000 (PXA255)
Cross Compiler : - Android bulit-in arm-gcc (EABI)
- Codesourcery arm-gcc toolchain
---------------------------------------------------------------------------------
1. 기존 LDS2000 의 2.4.19 kernel 에서 lds2000.c / sa1111.c 를 2.6.27 로 포팅 후 컴파일
- Kernel 로딩부터 무응답
- Trouble 을 발생시킨 이유를 알 수 없어 패스
2. Android 지원 Platform 인 Intel DBPXA 255 (lubbock.c) 에 lds2000.c 의 메모리 맵 정보를 옮겨 컴파일
2.1 Uncompressing kernel image... => hanging -_-
- TFTP 로 load 하는 위치 (address) 변경 => Kernel 시작 실패
=> Bad magic number
- Kernel Image 의 Load / Entry Point 변경 => Bad gzipped data
=> Out of memory (in uncompressing) 이어지는 System halt
** head.S -> misc.c -> piggy 로 이어지는 과정 추적
1. head.S 시작 후 decompress_kernel 함수 호출, 여기서 gunzip() 수행 시 에러 발생
- out of memory 또는 prefetch abort, 아니면 아예 대답없는 빌어먹을...
2. gunzip() 함수를 수행하지 않도록 주석 처리
- 역시나 예상을 빗나가지 않는 prefetch abort....
3. piggy.gz 의 압축을 풀고, decompress_kernel 을 패스 한 후 바로 piggy 로 부팅 시도
- 역시나 당신은 대답없는 개자식...
** Google 에서 u-boot gunzip hanging 으로 검색
1. SVN r44, Intel SDRAM
- u-boot 에서 Intel SDRAM 의 Refresh rate 가 너무 낮게 설정되어 drop 되는 bit 발생
- Refresh rate 를 수정하고 정상 작동 되었다 함
2. Gumstix 보드에서의 gunzip hanging
- 1번과 유사한 문제로 추정.
- 한놈은 inflate 함수에서 delay 를 통한 지연으로 낮은 Refresh rate 를 넘김
- 다른 한놈은 CPU Memory rate 조작으로 해결
* delay 적용 해 봤지만............역시나. 아아, 이 아름다운 개색히.
3. gzip 의 문제.
- gzip 사용시 이놈도 계속 uncompressing 중 hanging
- bzip, bzip2 등을 이용하여 압축 시 uncompressing 중 hanging 이 발생하지 않았다 함
* 될지 않될지도 모르는 bzip2 패치 언제 하고 앉았냐....-_-
** head.S
1. 2.4.19 Kernel 의 head.S 가지고 해봐도 실패
2. 인터넷에서 구한 head.S 가지고 해봐도 실패 (꽤 예전걸로 보임)
3. 어떤 head.S 든 uncompressing 중 hanging / prefetch abort / out of memory 로 이어지는 크리...
4. 결론은 주소 값이 뭔가 잘못 지정되었다는 건데.........(head.S - 12월 32일. (feat. 과제 제출 날짜))
** 특이점
1. misc.c 의 decompress_kernel() 함수에서 gunzip() 함수의 콜을 주석 처리 했을 때에는
decompress_kernel() 의 인자로 넘어오는 커널 시작 포인트가 Makefile.boot 에서 지정한 것과
동일한 주소가 넘어옴
그러나 gunzip() 함수 수행시, Makefile.boot 에서 지정한 zreladdr-y=0xA0100000 과 다른 주소값이
넘어옴. 어떤게 맞는 건지 아직은 모르겠다. 젠장.
2. 아무래도 주소 문제인 것 같은데...커널이 시작이라도 되는 양반들은 안드로메다에서 오신건가?
3. Kernel Image 의 크기는 990KB, 약 1MB, 따라서, TFTP 로 0xA0000000 으로 로드하면 1MB 뒤는
0xA0100000 이므로 Load / Entry Point 를 0xA0100000 으로 잡았는데....이게 문제인가...
이거 보면....0xA0008000 에 Load / Entry Point 를 잡을 경우, Kernel Image 가 씹히게 되는데....
설마 gunzip() 함수 라이브러리가 문제 있는건 아닐테고....
(구글 뒤져봐도 이게 잘못됐다는 소리는 없고....게다가 현재 라이브러리는 최신....니미럴)
** 중간결산
1. Kernel 이 시작 되도 손봐야 할게 한두군데가 아닌데....기한내에 할 수 있겠니;;;;;;
2. 정 않되면 bzip2 패치도 하고, u-boot 에서 RAM refresh rate 조정 해서 다시 올리고...
(어느 세월에................엿먹을 안드로이드, 신의 저주 있으라-_-니미)
3. Kernel 이 시작이라도 하는 양반들은 안드로메다 행성에서 오신거임.
** 2009. 6. 1 추가
1. gunzip 의 문제가 아닌 Relocation Code 를 압축 해체된 커널 이미지 뒤로 copy 하는 부분에서의 문제
2. Debugging 자료
- decompressed kernel length : 0x001E02B0 (1.9MB, 압축전 piggy의 크기는 1.9MB, 따라서 정상)
- 압축 해제는 정상적으로 진행된 것으로 판단
- reloc_start address : 0xA01003C0
- reloc_end address : 0xA01007B0
- relocation code length : 0x03F0 = 1008 bytes
=> 1008 bytes 의 경우, ldmia 명령어로, 6개 register 로 읽어오면, 1008 / 24 = 42,
ldmia, stmia 를 42회 반복해야 함
=> 원래 코드에서는 단 2회 반복
=> 이것으로 볼 때, reloc_start 부터 call_kernel 이전 까지만 옮긴다고 생각 할 수 있음
=> 그럼 call_kernel 을 비롯한 뒤의 나머지들은 어쩌라는겨??????
=> 최소한 call_kernel 까지는 옮겨야 커널 시작점이 발생된다고 생각하는데....
=> reloc_start + call_kernel 은 대략 96 bytes, 따라서, ldmia, stmia 최소 4회 반복해야 할 것인가?
=> 2009. 6. 2 수정. 루프 구간이였다. 48 bytes 씩-_- 멍청하긴;;
- arch/arm/boot/compressed/head.S (line: 264)
bl decompress_kernel
add r0, r0, #127 + 128 @ alignment + stack
bic r0, r0, #127 @ align the kernel length
/*
* r0 = decompressed kernel length
* r1-r3 = unused
* r4 = kernel execution address
* r5 = decompressed kernel start
* r6 = processor ID
* r7 = architecture ID
* r8 = atags pointer
* r9-r14 = corrupted
*/
add r1, r5, r0 @ end of decompressed kernel
/** r1 : 압축 해제된 kernel image 의 끝 위치 (address) : 0xA03E6CAC*/
adr r2, reloc_start
/** r2 : reloc_star 의 위치 (address, 압출 풀린 kernel image 의 relocation code
: 0xA01003E0 */
ldr r3, LC1
/** r3 : LC1 (reloc_end - reloc_start), reloc_start 의 코드 길이 : 0x000003F0 */
add r3, r2, r3
/** r3 : reloc_end 의 위치 (address) */
1: ldmia r2!, {r9 - r14} @ copy relocation code <== 여기서 시스템 패닉!!!!!!!
stmia r1!, {r9 - r14}
ldmia r2!, {r9 - r14}
stmia r1!, {r9 - r14}
/** r9 - r14, 6 개 register, 길이는 6 * 4 bytes = 24 bytes
reloc_start 를 24 bytes 씩 읽어서, 압축 해제된 kernel image 의 뒤로 reloc_start 를 이동
따라서 총 48 bytes 이동 */
cmp r2, r3
blo 1b
add sp, r1, #128 @ relocate the stack
bl cache_clean_flush
add pc, r5, r0 @ call relocation code <== 이동시킨 relocation code 수행
3. 유사한 문제점들
- KELP(kelp.or.kr) 에서 s3c2800 포팅 시 상기 문제와 동일한 문제 발생 확인
- 최초 작업 시 ldmia, stmia 한번 더 수행하므로서 해결
- 실제 release 에서는 저 부분이 삭제 됨 (원래 코드로 수행)
- 실제는 하드웨어와 부트 로더 문제였으며, 그 둘을 수정함으로써 해결했다함
** 중간결산2
1. 위에 gunzip 문제와 같이, 결론적으로는 부트로더를 손봐야 한다는 결론에 도달
2. 그럼 대체 부트로더 수정없이 커널 도는 양반들은 진짜 안드로메다에서 온거냐?????????
3. 어느 세월에 부트로더 수정하고 있냐....어디 수정해야 할지도 모르는데....염병-_-
4. 그런데 이상한건....relocation code 복사하고 나서 call_kernel 이 씹히는 바람에 시스템 패닉은
이해가 된다지만....대체 왜 LDMIA r2!, {r9 - r14} 에서 시스템 패닉이 일어나냐는 거다.
이건 정말 희한한 문제란 말이지.......
5. LDS2000 에서의 RAM 영역은 0xA0000000 부터 0xA4000000 인데...메모리 영역이 잘못 잡힌것도
아니고..........답이 없다 썅-_-
** 2009. 6. 2 05:30 AM 추가
1. 위에 추가한 문제로 시스템 패닉 아닌 것으로 판명됨
2. LDMIA 에서의 시스템 패닉은 bl print_reg_value 를 호출하는 과정에서 다른 레지스터의 값이
변경되므로써 발생하는것으로 확인
3. 따라서 레지스터 값을 저장/복구 시켜가며 확인한 결과 call_cache_fn 에서
old ARM ID (value: 0x00000000) 에 걸리면서 System hanging 이 발생한 것으로 확인
4. call_cache_fn 에서는 각 CPU 타입마다 서로 다른 mmu_cache 함수를 호출하는데,
make menuconfig 에서 PXA2xx/3xx -> LDS2000, 또는 LUBBOCK 선택 시 CPU_PROCESSOR_ID
값이 설정되지 않음
5. 이로 인하여 적절한 mmu_cache 함수를 선택하지 못하고 무한루프 / prefetch abort 발생
6. XScale PXA-255 는 ARMv5TE 에 포함되므로 이것으로 CPU_ID 값을 변경하도록 함
7. ((real_id ^ match value) & mask) == 0 인 경우 같은 것이므로,
ldr r6, =CONFIG_PROCESSOR_ID
대신, ARMv5TE 의 match value 인 0x00050000 값을 대입
ldr r6, =#0x00050000
gpio_test.zip
