'Embedded/Xhyper255A'에 해당하는 글 7건

** 2009. 6. 2   10:11 AM  추가

 

                1. reloc_start 실행 이후 call_kernel 까지는 정상적으로 진행

 

                2. call_kernel 에서 kernel entry point 인 0xA0008000 으로 점프 후 System hanging

                    (DEBUG 모드에서 0xA0008000 으로 점프 확인)

 

                3. 대체 뭐가 문제냐.......나도 지친다.....-_-;;

 

                4. 이젠 arch/arm/boot/compress/head.S 문제는 아닌데....보면 쳐 볼수록 짜증이 치솟냐....에휴;

 


  ** 2009. 6. 10 추가

 

............엄청 오랜만에 추가네;;

 

            1. 위의 문제는 부트 파라메터 오류로 인한 문제

                   - console=ttyS0,115600  =>  console=ttyS0,9600 으로 수정

 

            1.5. DMA 초기화 과정에서 system hanging 발생

 

                        pxa_dma_init() 에서 dma 레지스터 접근 시 그대로 system hanging

                        원인은 dma 레지스터의 주소를 어디서 찝적(겹칩)됬기 때문이라는데...

                        걍 dma 초기화 루틴을 수행하지 않도록 변경

 

                       ==> ethernet device(cs89x0) 에서 DMA 를 사용하긴 하지만, cs89x0.c 에서 ALLOWDMA 를 0으로 해버

                             리면 상관 없음. 시스템이 느려지긴 할테지만, 에러가 나진 않을 거 같음.

                               DMA 따위, 안쓰면 그만이지. 제기랄-_-;

 

            2. 이제 문제는 ethernet device 드라이버..

 

            3. ./driver/net/cs89x0.c 수정 작업 시작

 

            4. cs89x0 드라이버에서 접근할 가상 어드레스 0xF0000000 + 0x300 으로 설정

               (eth1 은 disable 시킴, 우선 하나만 되면 되지 뭐....)

               (eth1 의 가상 어드레스는 0xF2000000 + 0x300, IRQ 는 13)

 

           5. IRQ 는 0 으로 설정. IRQ_GPIO(0) 은 IRQ x is not in our map of allowable IRQs 발생시킴

 

  ** 4,5 번 내용은 모두 cs89x0.c 상에서 수정해야 하는 내용임!!

 

           6. 현재 기본 IP 설정까진 완료된 상태로 넘어가나... (192.168.1.101, 255.255.255.0)

 

                                        eth0: using half-duplex 10Base-T (RJ-45)

                                        IP-Config: Complete:

                                             device=eth0, addr=192.168.1.101, mask=255.255.255.0 gw=255.255.255.255

                                             host=192.168.1.101, domain=, nis-domain=(none),

                                             bootserver=192.168.1.100,

                                             rootserver=192.168.1.100,

                                             rootpath=,

 

           7. 아, 빼먹은건, u-boot 상에서 printenv 로 eth0, eth1 의 MAC address 확인하고, cs89x0 드라이버 상에서

             LUBBOCK 보드 선택 시 위의 MAC 주소를 강제로 입력하는 코드 추가해야 함

            (기본적으로 EEPROM 에서 읽어오는데, 없으므로, MAC address 를 만들어주어야 함)

              ==> u-boot 상의 MAC address 와 다르면, eth0: Failed to open eth0 가 발생함.

 

           8. Looking up port of RPC 100003/2 on 192.168.1.100

 

              여기서부터 오류 발생......NETDEV WATCHDOG: eth0 () : transmit timed out......얘는 대체 뭘까??

              스택 덤프 한번 해주고,

              rpcbind: server 192.168.1.100 not responding, timed out

              Root-NFS: unable to get mountd port number from server, using default

              eth0: transmit timed out, IRQ conflict ??          <== 뜬금없는 왠 IRQ conflict....

 

              그 다음은 VFS 오류 후 당연한 Kernel panic...

 

         ==> 이걸 eth0 설정은 다 된거지만, NFS 설정을 잘못해서 난 오류로 봐야할까 아니면 eth0 가 안잡힌 걸로 봐야할까....그런데 IP 설정이 제대로 된걸 보면 eth0 가 안잡혀서 그런거 같진 않은데...애매하다. 지금은 계속 이거 알아보는 중.

 


'Embedded > Xhyper255A' 카테고리의 다른 글

Android porting to XScale PXA255  (0) 2009.06.16
kernel error  (0) 2009.06.08
[답글]255A보드에서 GPIO제어.  (0) 2009.06.08
[답글]X-Hyper255A에서 커널에 대해...  (0) 2009.06.08
[XHYPER255] 커널 2.6 컴파일  (0) 2009.06.05

WRITTEN BY
RootFriend
개인적으로... 나쁜 기억력에 도움되라고 만들게되었습니다.

,

---------------------------------------------------------------------------------

 * 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

'Embedded > Xhyper255A' 카테고리의 다른 글

Android porting to XScale PXA255 (2)  (0) 2009.06.16
kernel error  (0) 2009.06.08
[답글]255A보드에서 GPIO제어.  (0) 2009.06.08
[답글]X-Hyper255A에서 커널에 대해...  (0) 2009.06.08
[XHYPER255] 커널 2.6 컴파일  (0) 2009.06.05

WRITTEN BY
RootFriend
개인적으로... 나쁜 기억력에 도움되라고 만들게되었습니다.

,

kernel error

Embedded/Xhyper255A 2009. 6. 8. 15:39
넵. 안녕하세요.

1. 죄송하게도 저희가 제공해드린 부트로더 소스에 약간의 문제가 있었습니다~
부트로더에서 메모리 설정값을 변경을 해주셔야 합니다.

변경해야 할 부분은
Boot-XHYPER255/src/include/start_xscale.h

#define MDCNFG_VALUE 0x00001AC9
->
#define MDCNFG_VALUE 0x00001AA9

로 변경하신후 부트로더를 다시 올리시면 됩니다~
값을 보시면 아시겠지만, 위의 값을 사용하시면 SDRAM을 16M 밖에 사용하지 못합니다.
row, col 값을 변경하셔야 SDRAM을 32M로 접근할수 있습니다.~

그렇기에 application이 돌면서 시간이 지나면 없는 SDRAM address에 접근해서 생기는 문제입니다.

불편드려 죄송합니다.~

2. kupdated는 kernel thread인데 정확한 용도는 잘 모르겠네요. ^^;

3. top이여?
top 소스가 있으면 cross compile을 해서 올리시면 되구요.
소스가 없다면 arm으로 된 바이너리를 받아서 넣어주시기만 하면 됩니다.

저희 download에 보시면 업데이트된 bootloader가 있으니 그걸 받아서 사용하시면 될껍니다.

http://www.hybus.net/download/image/255A/Boot-XHYPER255-R1.1.tar.gz


> 안녕하세요..
>
> Hyper255A를 구매해서 제가 만는 어플리케이션 프로그램을 실행해보면
> 일정 시간이 지나면 다음과 같은 에러가 발생하면서 시스템은 동작을 멈춥니다..
>
> 어플리케이션의 문제일 수도 있게지만, 에러의 내용을 보면 kupdated와
> 연관성이 있는것으로 보이는데
> 1) 혹 원인을 알수 있을까요??
> 2) kupdated의 역활도 알고 싶습니다.
> 3) 그리고 cpu와 memory의 점유율을 알기 위해 top 명령어를 추가 하고 싶은데 방법을 좀 알려 주세요..
>
> 그럼 수고하세요..
>
>
> --- 아 래 ---
> Unable to handle kernel paging request at virtual address
> 6c69660e
> pgd = c0004000
> *pgd = 00000000, *pmd = 00000000
> Internal error: Oops: ffffffff
> CPU: 0
> pc : [] lr : [] Not tainted
> sp : c02cff9c ip : c02cffc0 fp : c02cffbc
> r10: a0014ab4 r9 : 69052d06 r8 : c01c0a78
> r7 : c03ee060 r6 : c03ee000 r5 : 400149c0 r4 : c0015400
> r3 : 6c69660a r2 : 73253d65 r1 : 400149c8 r0 : 00000000
> Flags: nzcv IRQs on FIQs on Mode SVC_32 Segment kernel
> Control: 397F Table: A1998000 DAC: 0000001D
> Process kupdated (pid: 6, stackpage=c02cf000)
> Stack: (0xc02cff8c to 0xc02d0000)
> ff80: c0096740 c00a6f30 00000013 ffffffff c0015400
> ffa0: c02ce000 c02ce334 c02ce344 c01bec40 c02cffd4 c02cffc0 c0096740 c00a6f00
> ffc0: c0015400 c02ce000 c02cfff4 c02cffd8 c0096abc c009673c 00000000 00010e00
> ffe0: c01cd178 c01cd16c 00000000 c02cfff8 c0064a5c c0096990 ffffffff efffffff
> Backtrace:
> Function entered at [] from []
> r8 = C01BEC40 r7 = C02CE344 r6 = C02CE334 r5 = C02CE000
> r4 = C0015400
> Function entered at [] from []
> r5 = C02CE000 r4 = C0015400
> Function entered at [] from []
> r7 = C01CD16C r6 = C01CD178 r5 = 00010E00 r4 = 00000000
> Code: ea00004a e5912004 e5913000 e2415008 (e5832004)
> Unable to handle kernel paging request at virtual address 626d7972
> pgd = c1c88000
> *pgd = 00000000, *pmd = 00000000
> Internal error: Oops: 0
> CPU: 0
> pc : [<626d7972>] lr : [] Not tainted
> sp : c1c8de60 ip : 40014c0c fp : c1c8dea0
> r10: c03ee0cc r9 : c1ff5900 r8 : c1c8de74
> r7 : c0046240 r6 : c0046240 r5 : c0062100 r4 : c1e88200
> r3 : 00000044 r2 : 00000000 r1 : 00bcedd0 r0 : 40014c0c
> Flags: NzCv IRQs on FIQs on Mode SVC_32 Segment user
> Control: 397F Table: A1C88000 DAC: 00000015
> Process syslogd (pid: 39, stackpage=c1c8d000)
> Stack: (0xc1c8de50 to 0xc1c8e000)
> de40: c00e45d0 626d7972 a0000033 ffffffff
> de60: c1c8de74 c0062100 c1c8de74 00000000 c02829e0 c01fa000 c1e88200 c02829e0
> de80: c0046240 c0046240 c03b8005 00000002 00000010 c1c8dec0 c1c8dea4 c00e9c74
> dea0: c00e457c 00000008 c1c8df58 c1c8c000 c1c8df58 c1c8ded8 c1c8dec4 c00e9d24
> dec0: c00e9b84 ffffffec c1c8c000 c1c8df10 c1c8dedc c009ca1c c00e9d1c c0046240
> dee0: c03b8001 00000003 0029ab98 c03b8000 00000000 c1c8df58 00000d42 00000000
> df00: 00000000 c1c8df20 c1c8df14 c009cf7c c009c5d8 c1c8df54 c1c8df24 c009d70c
> df20: c009cf68 00000180 c006dc2c 00000d41 00000d41 00000180 c03b8000 c0063824
> df40: c1c8c000 00000000 c1c8df84 c1c8df58 c0090fc0 c009d668 c02f0420 c027d2e0
> df60: c009bf24 c0088b7c c03b8000 00000010 00000001 00000003 c1c8dfa4 c1c8df88
> df80: c0091334 c0090f98 00000d41 00000000 ffffffff 00000005 00000000 c1c8dfa8
> dfa0: c00636a0 c00912fc 00000d41 c0069408 0201bde8 00000d41 00000180 02025f68
> dfc0: 00000d41 00000000 ffffffff 00000d41 0201bde8 40133c88 00000000 bffffde8
> dfe0: 02026730 bfffed04 02017688 400df574 80000010 0201bde8 ffffffff ffffffff
> Backtrace:
> Function entered at [] from []
> Function entered at [] from []
> r6 = C1C8DF58 r5 = C1C8C000 r4 = C1C8DF58
> Function entered at [] from []
> r5 = C1C8C000 r4 = FFFFFFEC
> Function entered at [] from []
> Function entered at [] from []
> Function entered at [] from []
> Function entered at [] from []
> r4 = 00000003
> Function entered at [] from []
> r7 = 00000005 r6 = FFFFFFFF r5 = 00000000 r4 = 00000D41
> Code: bad PC value.

WRITTEN BY
RootFriend
개인적으로... 나쁜 기억력에 도움되라고 만들게되었습니다.

,

GPIO 핀을 제어 할려고 하는데

메뉴얼이나 씨디에는 마땅한 예제 소스가 없네요.

Init,Open,Read,Write 를 사용하는 예제 소스 좀 부탁드립니다.

GPIO핀은 외부 다른 Device와 통신하기 위해서 사용할겁니다.

제가 사용 하는 보드는 255A이고

리눅스용과 윈도우용 둘다 보내주셨으면 합니다 ^^


=====================답글내용=======================


안녕하세요..


255보드의 GPIO실습용 테스트 프로그램을 첨부해드립니다.(리눅스)


wince용은 따로 만들어 놓은 것이 없네요..


참고하셔서 좋은 결과가 있기를 바랍니다.


감사합니다.

'Embedded > Xhyper255A' 카테고리의 다른 글

Android porting to XScale PXA255  (0) 2009.06.16
kernel error  (0) 2009.06.08
[답글]X-Hyper255A에서 커널에 대해...  (0) 2009.06.08
[XHYPER255] 커널 2.6 컴파일  (0) 2009.06.05
JTAG Compile  (0) 2009.06.05

WRITTEN BY
RootFriend
개인적으로... 나쁜 기억력에 도움되라고 만들게되었습니다.

,

타겟보드의 사용할 리눅스 커널버전은 어떤것으로 하건 상관이 없습니다.


선택한 커널버전에 알맞게 수정작업을 해주면 됩니다.


제공되는 255용 커널은 수 많은 응용사례를 통하여 안정성을 확인한 것입니다.


사용해보지 않은 커널버전에 문제가 있는지 없는지는 말할수 없습니다.

=====================답글내용=======================



매뉴얼을 보면


225A는 커널 2.4.18을 사용합니다.
2.6.xx는 사용할 수 없는지요?
없다면 그 이유는 무엇입니까?


있다면 그 방법은 어떻게 됩니까?


 


그리고 2.4.18 말고


2.4.20-8이나 2.4.34로 선택을 해도 문제는 없는지 궁금합니다.

'Embedded > Xhyper255A' 카테고리의 다른 글

Android porting to XScale PXA255  (0) 2009.06.16
kernel error  (0) 2009.06.08
[답글]255A보드에서 GPIO제어.  (0) 2009.06.08
[XHYPER255] 커널 2.6 컴파일  (0) 2009.06.05
JTAG Compile  (0) 2009.06.05

WRITTEN BY
RootFriend
개인적으로... 나쁜 기억력에 도움되라고 만들게되었습니다.

,
1. kernel 2.6.10 .www.kernel.org
2. kernel-2.6.10-patch www.hybus.net
3. toolchain
    http://www.falinux.com/pds/toolchain.html
    arm-toolchain-3.4.3.tar.gz
 
Patch
# gzio -cd ../linux-2[1].6.10-hybus-patch.gz | patch -p1

make mrproper
make xhyper255b_deconfig    (/usr/src/kernels/kernel-2.6.10/arch/arm/configs/xhyper255_deconfig)
make



'Embedded > Xhyper255A' 카테고리의 다른 글

Android porting to XScale PXA255  (0) 2009.06.16
kernel error  (0) 2009.06.08
[답글]255A보드에서 GPIO제어.  (0) 2009.06.08
[답글]X-Hyper255A에서 커널에 대해...  (0) 2009.06.08
JTAG Compile  (0) 2009.06.05

WRITTEN BY
RootFriend
개인적으로... 나쁜 기억력에 도움되라고 만들게되었습니다.

,

JTAG Compile

Embedded/Xhyper255A 2009. 6. 5. 04:12
JTAG란?
이반적으로 JTAG라는 말 보다는 Boundary-Scan이란 말을 더 많이 사용한다. JTAG는 칩 내부에 Boundary Cell이란 것을 두어 외부의 핀과 일대 일로 연결시켜 프로세서가 할 수있는 동작을 중간에  Cell을 통해 모든 동작을 인위적으로 수행할 수 있어 여러가지 하드웨어 테스트나 연결 상태 등을 체크 할 수있다.

JTAG 기능
프로세서 상태와는상관없이 디바이스의 모든 외부 핀을 구동시키거나 값을 읽어 들일 수 있는 기능을 제공한다.
  • 디바이스 내에서 모든 외부와의 연결점을 가로챈다.(외부로 나가는 각각의 핀들과 일대 일로 연결)
  • 각각의 sell은 serial-regisher(boundary scan register)형성하기 위해서 서로 연결되어 있다.
  • 전체적인 인터페이스는 5개의 핀에 의해서 제어된다 (TDI, TMS, TCK, nTRST, TDO)
  • 회로의 배선과 소자의 저기적 연결상태 Test
  • 디바이스간의 연결상태 Test
  • Flash memory fusing

JTAG Building
#cd /home/embed/xhyper/Jflash-PXA255
#vi Compile_switches.h
/*****************************************                                                                   
**  FILENAME:       Compile_switches.h
**
**  PURPOSE:        collects the optional switches for this program.
**
**  LAST MODIFIED:  2003.06.03
*****************************************/
//#define DEBUG
//#define INSIGHT_JTAG
#define PARALLEL_JTAG
                                              
/*
* HyBus pxa255 board platform
*/
#define XHYPER255A   // 16bit flash memory
//#define XHYPER255B   // 32bit flash memory

그리고 main.c에서  #include <asm/io.h> 를 #include <sys/io.h> 로 바꿔준다

레드헷 리눅스 9.0에서는 void main() 함수를 쓰지 않고 int main() 함수를 씀으로 바꿔줘야 한다. 아래 빨간색 int로 바꿔 주자.
#vi main.c
/*
*******************************************************************************
*
* FUNCTION:         main
*
* DESCRIPTION:      Entry point for utility
*
* INPUT PARAMETERS: uses optional input parameters:
*                       argv[1] = filename to flash (binary files only)
*                       argv[2] = program options, currently only 'P' for Program
*                       argv[3] = block number (used to compute base_address)*
* RETURNS:          void
*
*******************************************************************************
*/
int main( int argc, char *argv[] )
{
   time_t start;
       DWORD fsize = 0;
       DWORD last_non_zero = 0 ;
       DWORD last_non_ff = 0;
//      DWORD li;
       int block_number = 0;
#make clean
rm -f *.o Jflash-Xhyper255
#make
g++ -O2 -s -g -D__linux__ Jflash.cpp -o Jflash-Xhyper255
/tmp/ccp8kA4v.o(.text+0x42b): In function `main':
/home/embed/xhyper/Jflash-PXA255/Jflash.cpp:199: the `gets' function is dangerous and should not be used.
#ls
Compile_switches.h  Jflash.dsw  RelNote_Jflash_CL.htm  jflash
Debug               Jflash.h    SWLicense.pdf          jflash_cl.exe
Giveio.zip          Jflash.ncb  giveio.inf             load_sample.bat
Jflash-Xhyper255    Jflash.opt  giveio.ini             xhyper255jtag.h
Jflash.cpp          Jflash.plg  giveio.sys
Jflash.dsp          Makefile    instdrv.exe




Jflash-Xhyper255 바이너리 파일이 만들어 져 있을 것이다. Bootloader Compile 한 후 간단한 사용 방법을 보자.

'Embedded > Xhyper255A' 카테고리의 다른 글

Android porting to XScale PXA255  (0) 2009.06.16
kernel error  (0) 2009.06.08
[답글]255A보드에서 GPIO제어.  (0) 2009.06.08
[답글]X-Hyper255A에서 커널에 대해...  (0) 2009.06.08
[XHYPER255] 커널 2.6 컴파일  (0) 2009.06.05

WRITTEN BY
RootFriend
개인적으로... 나쁜 기억력에 도움되라고 만들게되었습니다.

,