GDT,IDT,TSS 세그먼트 추가햇는데 오류 ,,, 

헤더에 분명 저렇게 잘 선언해놧고,

소스코드 확인해봣는데도 문제가 없는데 

main.c에서 헤더를 끌어썻는데 kInitializeIDTTables 를 읽지를 못한다.. 아직 원인을 모르겟음 ... 

좀더 찾아보던지 아니면 일단 넘어가던지 해야겟다 .. 

키보드 디바이스 드라이버를 추가해주었는데 뻑이나서.. 왜그런가 햇더니 함수명 중에

kActivateKeyboard(void)를 kActivekeyboard라고 적어놈 ㅡㅡ ;

그래서 함수를 콜해서 쓰는 부분에서 제대로 못읽어줘서 오류가낫엇음 

결과적으로 고쳐 주니 성공 

$ make all

=================== Build Boot Loader ===================

make    -C      00.BootLoader

make[1]: Entering directory '/cygdrive/c/MINT64_symnoisy/00.BootLoader'

nasm    -o      BootLoader.bin  BootLoader.asm

make[1]: Leaving directory '/cygdrive/c/MINT64_symnoisy/00.BootLoader'

=================== Build Complete ===================

=================== Build 32bit Kernel ===================

make    -C      01.Kernel32

make[1]: Entering directory '/cygdrive/c/MINT64_symnoisy/01.Kernel32'

mkdir   -p      Temp

nasm    -o      Temp/EntryPoint.bin     Source/EntryPoint.s

=== Make Dependancy File ===

make    -C      Temp    -f      ../makefile     InternalDependency

make[2]: Entering directory '/cygdrive/c/MINT64_symnoisy/01.Kernel32/Temp'

x86_64-pc-linux-gcc.exe -c -m32 -ffreestanding  -MM     ../Source/page.c ../Source/Main.c    >Dependency.dep

make[2]: Leaving directory '/cygdrive/c/MINT64_symnoisy/01.Kernel32/Temp'

=== Dependancy Search Complete ==

make    -C      Temp    -f      ../makefile     Kernel32.elf

make[2]: Entering directory '/cygdrive/c/MINT64_symnoisy/01.Kernel32/Temp'

x86_64-pc-linux-gcc.exe -c -m32 -ffreestanding  -c      ../Source/Main.c

x86_64-pc-linux-gcc.exe -c -m32 -ffreestanding  -c      ../Source/page.c

nasm    -f      elf32   -o      ModeSwitch.o    ../Source/ModeSwitch.asm

x86_64-pc-linux-ld.exe -melf_i386 -T ../elf_i386.x -nostdlib -e Main -Ttext 0x10200 -o       Kernel32.elf    Main.o page.o ModeSwitch.o

x86_64-pc-linux-ld: warning: cannot find entry symbol Main; defaulting to 0000000000010200

make[2]: Leaving directory '/cygdrive/c/MINT64_symnoisy/01.Kernel32/Temp'

x86_64-pc-linux-objcopy -j .text -j .data -j .rodata -j .bss -S -O binary       Temp/Kernel32.elf    Temp/Kernel32.elf.bin

cat     Temp/EntryPoint.bin Temp/Kernel32.elf.bin       >       Kernel32.bin

make[1]: Leaving directory '/cygdrive/c/MINT64_symnoisy/01.Kernel32'

=================== Build Complete ===================

=================== Build 64bit Kernel ===================

make    -C      02.Kernel64

make[1]: Entering directory '/cygdrive/c/MINT64_symnoisy/02.Kernel64'

mkdir   -p      Temp

=== Make Dependancy File ===

make    -C      Temp    -f      ../makefile     InternalDependency

make[2]: Entering directory '/cygdrive/c/MINT64_symnoisy/02.Kernel64/Temp'

x86_64-pc-linux-gcc.exe -c -m64 -ffreestanding  -MM     ../Source/Keyboard.c ../Source/Main.c>Dependency.dep

make[2]: Leaving directory '/cygdrive/c/MINT64_symnoisy/02.Kernel64/Temp'

=== Dependancy Search Complete ==

make    -C      Temp    -f      ../makefile     Kernel64.elf

make[2]: Entering directory '/cygdrive/c/MINT64_symnoisy/02.Kernel64/Temp'

nasm    -f      elf64   -o      EntryPoint.o    ../Source/EntryPoint.s

x86_64-pc-linux-gcc.exe -c -m64 -ffreestanding  -c      ../Source/Keyboard.c

x86_64-pc-linux-gcc.exe -c -m64 -ffreestanding  -c      ../Source/Main.c

nasm    -f      elf64   -o      AssemblyUtility.o       ../Source/AssemblyUtility.asm

x86_64-pc-linux-ld.exe -melf_x86_64 -T ../elf_x86_64.x -nostdlib -e Main -Ttext 0x200000     -o      Kernel64.elf    EntryPoint.o Keyboard.o Main.o AssemblyUtility.o

make[2]: Leaving directory '/cygdrive/c/MINT64_symnoisy/02.Kernel64/Temp'

x86_64-pc-linux-objcopy -j .text -j .data -j .rodata -j .bss -S -O binary       Temp/Kernel64.elf    Kernel64.bin

make[1]: Leaving directory '/cygdrive/c/MINT64_symnoisy/02.Kernel64'

=================== Build Complete ===================

=================== Disk Image Build Start ===================

./ImageMaker.exe        00.BootLoader/BootLoader.bin 01.Kernel32/Kernel32.bin 02.Kernel64/Kernel64.bin

[INFO] Copy boot loader to image file

[INFO] File size is aligned 512 byte

[INFO] 00.BootLoader/BootLoader.bin size = [512] and sector count = [1]

[INFO] Copy protected mode kernel to image file

[INFO] File size [2699] and fill [373] byte

[INFO] 01.Kernel32/Kernel32.bin size = [2699] and sector count = [6]

[INFO] Copy IA-32e mode kernel to image file

[INFO] File size [2738] and fill [334] byte

[INFO] 02.Kernel64/Kernel64.bin size = [2738] and sector count = [6]

[INFO] Start to write kernel information

[INFO] Total sector count except boot loader [12]

[INFO] Total sector count of protected mode kernel [6]

[INFO] Image file create complete

=================== All Build Complete ===================

================== Utility Build Start ===================

make    -C      04.Utility

make[1]: Entering directory '/cygdrive/c/MINT64_symnoisy/04.Utility'

make[1]: *** No targets specified and no makefile found.  Stop.

make[1]: Leaving directory '/cygdrive/c/MINT64_symnoisy/04.Utility'

makefile:48: recipe for target 'Utility' failed

make: *** [Utility] Error 2

~>유틸리티 부분에는 makefile 을 생성해놓지 않아서 오류가 발생하는 거라서 이전 포스팅과 같게 이부분에서는 오류가남 

캬 .. .드디어 성공햇습니다... 

따라만들기 수준에 그치고있는데도 코드작성이라는거 만만치가 않네요.. 

드디어 64bit로 넘어옴과 더불어 Disk.img 생성까지 모두 성공적으로 이뤄졌습니다 .. 

너무행복합니다 .. 오늘은 발뻗고 잘 수 있겟어요 ..

내일(4/8)은 코드게이트 컨퍼런스에 가야해서 ㅋㅋ 그전까지 키보드 디바이스 드라이버까지 추가시키려 합니다

슬슬 시험기간이 다가오긴 하는데 .. OS 만드는거 너무재밋네요 ... 

예전에 자꾸 뻑나서 짜증나서 64비트 진입도 못하고 접어버렷는데 ... 장벽을 드디어 허물어버렷습니다 만세 ! 

(유틸리티 부분에서 오류나는 이유는 makefile 을따로 만들어주지 않아서 그러는거라 오류가아닙니다 ㅎㅎ ) 

처음부터 다시만들면서

부트로더 ,리얼모드로의 전환, 보호모드로의 전환까지 진행하였고, 

64bit로 전환하기 전에  A20 게이트를 활성화 시켜줘서 메모리를 4GB이상 접근할수 있게 해주었으며, 

현재는 페이징기법을 활성화 시키기 직전 단계까지 다다랏다 ,... 근데 문제가 .. 

makefile 프로그램에서 뻑나는건지 아니면  어디서뻑나는건지 ..

 A20 게이트 활성화 하면서 메모리 확장 확인 소스를 추가해준 뒤부터 자꾸 Disk.img가 생성이 되지 않는다 .. 소스자체에도 문제가없는데 .. 

해결함 ) :키우는 고양이 아리가 내가 딴짓할때 makefile 프로그램에 커서가 올라가있엇는데 코드안에 스페이스 갈기고 도망갓던거엿음 ㅡㅡ ;고침

+)우분투에서 진행하다가 장애물에 굉장히 많이 부딪혓는데 .. 정신차려보니 설정이 되어있는 이미지를 받고있엇다 ㄷㄷ ; 

부트로더부터 시작해서 리얼모드(16bit) , 보호모드(32bit) , IA-32e(64bit) 모드까지 천천히 넘어오면서 ,

페이징도 활성화시키고, GDT 도활성화 시키고 여튼 잘 넘어왓는데 아래에 첨부한것처럼 ,, 

@echo에서 왠 엑박이뜬다;; 도무지이해할수가 없다 오류나는 부분 ExecuteInternalBuild에서 

오류가 난다고 하는데, 내생각엔 아마도 Kernel32 부분에서 컴파일될떄 생성되는 Kernel32.bin 이나 

Kernel32.elf부분에서 컴파일 오류가 나는거같다.. 분명 make clean으로 싹지우고 다시 컴파일 했는데 .. 

이부분은 정말 모르겟어서  내가보고있는 책 저자 사이트에 질문을 올려두었다 ..

문제가 해결되면 수정하겟다 ..

+)생각보다 진도가 굉장히 빨리나가고 있다.. 시스템 공부처음할때 이책을 삿엇다..

 그때는 봐도 뭔말인지 하나도 몰랏는데 이제 조금 이해가 되서 재미가 붙은것 같다 ^오^

 이제 디바이스드라이버를 구성해볼 차례인데,, 

커널까지 만들었는데 1권의 1/4밖에 안봣다니 .. ;; ( 1500페이지 가량되는데 이게 두권임 =_=) 

여튼 빨리완성하고싶다! 

저처럼 헤매지마시고 http://www.youtube.com/watch?v=p9JthOVFVyM 보고 설치하세요 ㅠㅠ 

현재 까지 만든 보호 모드의 커널은 엔트리 포인트 소스 파일 하나로 구성되어 있고, 512 바이트로 정렬 되어 OS 이미지 파일에 결합되는 구조를 하고 있다.

이번 포스팅에서는 C 소스 파일을 추가하고, 이를 빌드하여 보호 모드 커널 이미지에 통합할 것이다.

~>C 코드는 어셈블리어 코드와 달리 '컴파일'과 '링크 과정'을 거쳐서 최종 결과물이 생성된다.

컴파일

-소스 파일을 중간 단계인 Object File로 변환하는 과정

-소스 파일을 해석하여 코드 영역과 데이터 영역으로 나눈다.

-이러한 메모리 영역에 대한 정보를  생성하는 단계

그렇다고 C 코드를 빌드해서 합치기만 한다고 보호 모드 엔트리 포인트가 뒷부분의 커널을 실행할 수 있는 것은 아니다.

엔트리 포인트가 C 코드를 실행하려면 다음 세가지 조건을 만족해야 한다.

1.C 라이브러리를 사용하지 않게 빌드해야 한다(-ffreestanding 옵션 추가)

~> 부팅된 후 보호 모드 커널이 실행되면 C 라이브러리가 없으므로 라이브러리에 포함된 함수를 호출할 수 없음

~>커널은 자신을 실행하기 위한 최소한의 환경만 설정해서 라이브러리 함수가 정상적으로 실행되지 않는다.

2. 0x10200 위치에서 실행하게끔 빌드해야 한다

~> 0x10000 위치는 이전 포스팅에서 작성했던 한 섹터 크기의 보호 모드 엔트리 포인트가 있으니까 결합된 C 코드는 512바이트 이후인 0x10200의 위치부터 로딩된다.

~>그래서 커널 부분을 빌드할 때 0x10200 위치에서 실행되는 것을 전제로 해야 하고, 해당 위치의 코드는 C 코드 중 가장 먼저 실행되어야 하는 함수가 위치해야 한다.

*커널이 실행되는 어드레스가 중요한 이유

선형 주소를 참조하게 생성된 코드나 데이터 때문

~>C언어에서 전역 변수의 어드레스나 함수의 어드레스를 참조하는 경우 실제로 존재하는 선형 주소로 변환된다.

3. 코드나 데이터 외에 기타 정보를 포함하지 않는 순수한 바이너리 파일 형태여야 한다.

이제부터 오브젝트 파일을 링크해 실행파일을 만들건데 , 그 이전에 실행 파일을 구성하는 섹션의 배치와 로딩될 어드레스, 코드 내에서 가장 먼저 실행될 코드인  엔트리 포인트를 지정해주어야 한다.

섹션(Section)

-실행 파일 또는 오브젝트 파일에 이씅며 공통된 속성(코드, 데이터, 각종 심볼과 디버깅 정보 등)을 담는 영역

-text 섹션

-실행 가능한 코드가 들어있는 섹션

-우리가 작성한 main()이나 함수의 실제 코드가 저장되는 영역

-수정될 일이 거의 없어서 일반적으로 Read-Only로 설정

-data 섹션

-초기화 된 데이터가 들어있는 섹션

-초기화 된 전역 변수(Global Variable) 또는 0이 아닌 값으로 초기화된 정적 변수(Static Variable)를 포함

-데이터를 저장하는 섹션이여서 일반적으로 Read,Write로 설정

-.bss 섹션

-초기화 되지 않은 데이터가 들어있는 섹션

-.data 섹션에 포함되는 데이터와 거의 같지만 초기화 되지 않은 변수만 포함한다는 것이 특징

-해당 섹션은 0으로 초기화 될 뿐, 실제 데이터가 없어서 실행 파일이나 오브젝트 파일 상에는 별도의 영역을 차지하지 않는다.

-하지만 여기서 중요한 point는 '메모리에 로딩되었을 때 코드는 해당 영역 변수들이 초깃값이 0이라 가정한다'

-정상적인 프로그램 실행을 원한다면 메모리에 로딩할때 .bss 영역을 모두 0으로 초기화 해주어야한다.

~>소스 코드를 컴파일하여 생성한 오브젝트 파일은 각 섹션의 크기와 파일 내에 있는 오프셋 정보만 들어 있다.

~>오브젝트 파일은 중간 단계의 생성물로 다른 오브젝트 파일과 합쳐지기 때문

~>합쳐지는 순서에 따라 섹션의 어드레스는 얼마든지 바뀔 수 있다.

~>여기서 오브젝트 파일들을 결합하여 정리하고 실제 메모리에 로딩될 위치를 결정하는 것이 바로 '링커'

*링커의 주된 역할은 오브젝트 파일을 모아 섹션을 통합하고 그에 따라 어드레스를 조정하며, 외부 라이브러리에 있는 함수를 연결 해는 것

*하지만 단지 링커로만 이것이 가능한게 아니다. 링커가 실행 파일을 만들려면 파일 구성에 대한 정보가 필요한데 이때 사용하는 '링커 스크립트' 가 필요하다

~>링커 스크립트에는 각 센션의 배치 순서와 시작 어드레스, 섹션 크기 정렬등의 정보를 저장해 놓은 텍스트 형태의 파일이다.

[링커 스크립트]

섹션의 재배치

- 실행 파일이 링크될 때 코드나 데이터 이외에 디버깅 관련 정보와 심볼 정보등이 포함되기 때문

-이러한 정보들은 커널을 실행하는 데 직접적인 관련이 없으므로, 최종 바이너리 파일을 실행할 떄 이를 제거하려고 섹션을 재배치 하는것.

-텍스트나 데이터와 관계없는 섹션의 기본구조 전체를 코드 및 데이터 섹션의 뒷 부분으로 이동하거나 코드 및 데이터에 관련된 섹션을 가장 앞으로 이동함으로써 처리할 수 있다.(보통 후자의 경우를 많이 사용)

로딩할 메모리 어드레스와 엔트리 포인트 지정

-메모리를 미리 예측하고 그에 맞춰 이미지를 생성하지 않는다면 전역 변수와 같이 선형 어드레스를 직접 참조하는 코드는 모두 잘못된 어드레스에 접근하게 된다.

-링커 스크립트를 수정하는 방법, 링커(LD) 프로그램의 명령줄 옵션으로 지정하는 방식

-전자의 경우 .text 섹션을 수정한다. 해당 섹션을 수정하게 되면 .data와 .bss같은 섹션은 자동으로  .text가 로딩되는 어드레스 이후로 계산된다.

커널의 엔트리 포인트 파일 생성(EntryPoint.s)

-보호 모드 커널의 가장 앞부분에 위치하는 코드

-보호 모드 전환과 초기화를 수행하여 이후에 위치하는 코드를 위한 환경을 제공

-Entry Point

-외부에서 해당 모듈을 실행할 때 실행을 시작하는 지점

여기서 새로운 파일이 추가되었으므로 추가된 파일을 빌드할 수 있게 makefile을 다음과 같이 수정해준다.(Kernel32의 makefile)

$< ~> Dependency의 첫 번째 파일을 의미하는 매크로

마찬가지로 최상위 디렉토리의 makefile도 수정해준다.

~> 지금 이 상태로 QEMU를 실행해보면 정상적으로 실행이 되지않는다. 왜냐면 부트로더에 OS이미지가 1024로 설정되어 있기 때문이다. 빌드한 보호 모드의 커널 이미지 크기가 512바이트밖에 되지 않아서 부트로더가 한 섹터를 로딩한 후 나머지 1023 섹터를 읽으려다가 정지한 것이다.

따라서 BootLoader.asm 의 TOTALSECTORCOUNT를 TOTALSECTORCOUNT:    dw    1 

로 수정해준다.

해당 OS의 이미지

-부트 로더

-보호 모드 커널

-IA-32e 모드 커널

~>각 부분은 섹터 단위로 정렬해서 하나의 부팅 이미지 파일로 합침

~>따라서 디스크의 두 번째 섹터부터 읽어서 특정 메모리 어드레스에 순서대로 복사하면 이미지 로딩은 끝!

~>여기서 플로피 디스크 두번 째 부터 로딩하는 이유는 첫 번째 섹터는 부트로더로 BIOS가 메모리에 로딩하기 떄문

~>플로피 디스크의 섹터는 섹터->헤드->트랙 순으로 배열되어 있으므로 순서만 지킨다면 문제 없이 로딩할 수 있음

*BIOS 섹터 읽기 기능은 최대 128섹터까지 읽을 수 있으므로 한 트랙에 있는 섹터의 배수 단위(18 섹터)로 읽게 하면 코드를 간단히 할 수 있다.

스택 초기화& 함수 구현~> 스택에대한 내용을 분명어디다가 정리를 해둿는데 어따가 해놧는지 기억이안나네요 .,.나중에 따로 링크걸겟습니다 

-x86 프로세서에서 함수를 사용하려면 스택(Stack)을 꼭 사용해야 한다.

-LIFO(Last In First Out)구조

-함수 호출을 위해 가장 먼저 해야 할일 ~> '스택 생성'

-SS(Stack Segment) 

-스택 영역으로 사용할 세그먼트의 기준 주소 지정

-스택 세그먼트의 범위는 지정할 수 있지만, 실제 스택의 크기는 지정 불가

-SP(Stack Pointer)

-데이터를 삽입하고 제거하는 상위 지정

-실제 스택의 크기 지정

-BP(Base Pointer)

-스택의 기준 주소를 임시로 지정할 때 사용

-실제 스택의 크기 지정

~>각 레지스터&어셈블 명령어의 자세한 내용이 궁금하다면 ' system - 기초' 포스팅을 참조하기 바람

[스택 초기화 코드]

 ; 스택을 0x0000 :0000 ~ 0x0000:FFFF영역에 64KB 크기로 생성한다 가정

mov ax,0x0000

mov ss, ax

mov sp,0xFFFE

mov bp,0xFFFE

*스택에 삽입된 파라미터에 접근하려면 가변적인 SP 대신 스택에 고정된 값을 가리키는 레지스터를 사용하는 것이 편리하다. 이러한 역할을 하는 것이 BP이며, 호출된 함수는 BP+offset으로 파라미터에 접근하게 된다.

[보호 모드에서 사용되는 세가지 함수 호출 규약]

~>리얼 모드의 경우 스택의 기본 크기가 word(2byte)엿지만 보호모드의 경우 스택의 기본크기가 dword(4byte)임

호출 규약(Calling Convention)

-함수를 호출할 때 파라미터와 복귀 어드레스 등을 지정하는 규칙

-stdcall(Standard Call)

-파라미터를 스택에 저장

-호출된 쪽에서 스택을 정리

-함수의 반환 값을 'EAX'를 사용하여 스택에서 파라미터를 제거

-cdecl(C-Declare Call)

-파라미터를 스택에 저장

-함수를 호출할 쪽에서 스택을 정리

-즉, 호출한 함수가 대신 처리한다.

-fastcall

-각 컴파일러마다 구현하는 방식이 조금씩 다름

-일부 파라미터를 레지스터에 저장하는 것을 제외하면 stdcall방식과 같음

-MS사 컴파일러 경우, 처음 파라미터를 ECX와 EDX 레지스터에 삽입하는 것을 제외하고는 stdcall과 같음

[최종 부트로더 소스]~>왠일로 한큐에 잘 돌아가서 기분이 날아갈것 같습니다.. haha

이전 포스팅에서는 PC 부팅과정, 부트로더 코드를 보았다. 이어서 이번 포스팅 부터는 OS 이미지를 메모리로 복사하는 기능을 추가할 것이다.

~> 빌드가 끝나면 MINT64 OS의 최종 이미지는 플로피 디스크용으로 생성된다

~>부트 로더가 플로피 디스크에서 OS 이미지를 읽어 메모리로 복사 해야 한다는 것을 의미

플로피 디스크를 제어하는 방법

1.직접 플로피 디스크 컨트롤러에 접근하는 방법

2.BIOS 서비스를 이용하는 방법(이번 포스팅에서 사용할 방법)

BIOS(Basic Input/Output System)

-우리가 일반적으로 많이 사용하는 라이브러리 파일과 자신의 기능을 특별한 방법으로 외부에 제공한다.

-함수의 어드레스를 인터럽트 벡터 테이블(Interrupt Vector Table)에 넣어 두고, 소프트웨어 인터럽트(SWI;SoftWare Interrupt)를 호출하는 방법을 사용

-인터럽트 벡터 테이블은 메모리 어드레스 0에 있는 테이블로, 특정 번호의 인터럽트가 발생했을 때 인터럽트를 처리하는 함수(인터럽트 핸들러, Interrupt Handler) 검색에 사용

-테이블의 각 항목은 인덱스에 해당하는 인터럽트가 발생했을 때 처리하는 함수 어드레스가 저장되어 있고, 각 항목의 크기는 4 바이트

-최대 256개 까지 설정 가능(256*4 =1024)

[리얼 모드의 주요 인터럽트 벡터 테이블]

~>그래서 '레지스터'를 이용한다.

[리셋과 섹터 읽기에 사용하는 레지스터]

[플로피 디스크의 내부 구조]

헤드

-디스크의 표면

-디스크의 하나는 두 개의 표면으로 구성, 각 표면에 데이터 저장이 가능

-헤드의 수 = 디스크 수 *2

-0부터 시작하기 0,1 값을 갖는다

트랙

-디스크를 여러 개의 동심원으로 나눴을 때, 동심원 하나가 가지는 영역

-80개의 동신원으로 구분하기 때문에 트랙의 수는 모두 80개

-0~79 

섹터(개당 512 byte)

-디스크를 구성하는 가장 작은 단위

-트랙을 다시 여러 조각으로 자른 것

-한 트랙당 18개의 같은 크기로 구분하므로 트랙에 포함된 섹터는 모두 18개

-1~18

~>디스크의 물리적인 구조는 섹터, 트랙, 헤드로 구성되지만, 논리적인 관점에서 보면 디스크는 순차적으로 정렬된 섹터의 집합이다.

~>섹터(1-18) -> 헤드(0-1) -> 트랙(0-79)