'make clean'으로 이전 단계의 결과물을 깨끗이 정리한 후 'make'를 입력하면 01.Kernel32 디렉터리에 Kernel32.bin 파일이 생성되는 것을 확인할 수 있습니다.
Kernel32.bin 파일의 크기는 약 646byte 정도의 크기로, 2 섹터에 못 미치는 크기입니다.
이전에 설명했듯이 보호 모드 커널을 정상적으로 메모리에 로딩하고 실행하려면 부트 로더에 포함된 TOTALSECTORCOUNT의 값을 변경해야 합니다.
따라서 00.BootLoader 디렉터리에 있는 BootLoader.asm 파일의 TOTALSECTORCOUNT의 값을 2로 수정한 후 다시 빌드하면, 지금까지 잘 따라왔다면 오류 메시지 없이 Disk.img 파일이 생성될 것입니다.
하지만 아직 QEMU가 섹터 단위로 정렬된 디스크 이미지만 처리할 수 있기 때문에 QEMU를 실행해서 C 커널이 동작하는지 확인하면 실패할 것입니다.
보호 모드 커널 이미지가 약 646byte 정도로 2 섹터에 못 미치기 때문에 마지막 섹터를 로딩하는데 문제가 발생한 것이기에 디스크 이미지를 512byte 크기로 정렬하고, 모자란 부분을 0x00과 같은 임의의 값으로 채워주면 해결할 수 있습니다.
위의 작업을 수행해주는 간단한 프로그램을 제작하여 빌드 시에 cat 프로그램 대신 사용하고, 부가 기능으로 부트 로더에 TOTALSECTORCOUNT까지 자동으로 변경하는 기능도 추가하여 빌드할 때마다 값을 수정해야 했던 불편함도 없애겠습니다.
→ 이미지 메이커 프로그램 작성
앞에서 makefile을 수정하여 파일만 추가하면 자동으로 찾아 빌드해주게끔 하여 파일이 추가될 때마다 makefile을 수정해야 했던 수고를 덜었습니다.
하지만 부팅 과정을 확인하기가 무섭게 가상 머신이 리부팅되기 때문에 QEMU 실행 결과가 그리 정상적이지 않습니다.
앞에서 부트 로더의 앞부분에 있는 TOTALSECTORCOUNT를 2로 갱신하지 않았기 때문입니다.
아래와 같이 부트 로더를 수정하여 정상적으로 실행할 수 있게 해줍니다.
아직 소스 코드를 빌드하는 작업은 자동화지만, TOTALSECTORCOUNT는 수작업으로 수정하고 있으니 진정한 자동화가 아닙니다.
그렇기에 이미지 메이커 프로그램을 만드는데, 이 프로그램은 부트 로더와 커널 이미지를 통합하여 섹터(512byte) 크기로 정렬하고, 부트 로더의 TOTALSECTORCOUNT에 커널의 총 섹터 수를 업데이트하기 때문에 더 이상 부트 로더에 값을 변경하지 않아도 되며, 커널 빌드 과정을 더 편리하게 수행할 수 있습니다.
이미지를 생성하는 프로그램을 작성하기 전에 부트 로더 이미지 파일(BootLoader.bin)에 있는 TOTALSECTORCOUNT의 오프셋을 확인하기 위해 우분투에서 xxd 또는 hexdump(윈도에서는 HxD) 명령어로 이 파일을 열면 첫 부분이 아래와 같이 표시됩니다.
참고)
EA 07 00 C0 07 : jmp 0x7C0: START
02 00 : dw 0x2
이제 TOTALSECTORCOUNT의 위치를 알았으니 이를 바탕으로 이미지 메이커를 구현하는데
이미지 메이커를 빌드하기 위해 04.Utility 디렉터리에 00.ImageMaker 디렉터리를 생성한 후 ImageMaker.c 파일(04.Utility/00.ImageMaker/ImageMaker.c)을 생성한 뒤 아래의 내용을 입력합니다.
그리고 터미널에서 00.ImageMaker 디렉터리로 이동해서 커맨드 라인으로 'gcc -o ImageMaker ImageMaker.c'를 입력하거나 아래와 같이 makefile(04.Utility/00.ImageMaker/makefile)을 간단히 작성하여 make를 실행합니다.
makefile을 만들어서 빌드한다면, 추후의 편리를 위해서 04.Utility 디렉터리 밑에 makefile(04.Utility/makefile)을 만들어 아래의 두번 째 사진과 같은 내용을 입력합니다.
빌드가 성공적으로 끝나면 해당 ImageMaker 실행 파일이 최상위 디렉터리(FS64 OS/)에 생성됩니다.
→ Eclipse IDE 사용하는데 #include가 안될 경우
Eclipse에서 아래와 같이 뜬다면
자신의 OS 프로젝트 이름을 우클릭한 뒤 properties 클릭
C/C++ General -> Paths and Symbols -> GNU C -> Add...
Ubuntu
File system... -> /usr/include
File system... -> /lib/gcc/x86_64-linux-gnu/version/include
Windows
File system... -> C:\cygwin\usr\include
File system... -> C:\cygwin\usr\cross\lib\gcc\x86_64-pc-linux\version\include
한 뒤
OK 클릭
Apply and close
→ 커널 이미지 생성과 실행
이제 생성한 이미지 메이커 프로그램으로 디스크 이미지를 생성합니다.
지금까지는 cat 프로그램을 사용해서 디스크 이미지를 만들었지만, 이제 이를 이미지 메이커가 대신하므로 이미지 메이커 프로그램을 사용하도록 makefile(FS64 OS/makefile)을 수정합니다.
ImageMaker.c를 빌드하면 ImageMaker 프로그램이 생기는데 makefile(04.Utility/00.ImageMaker/makefile)에서 mv 명령으로 ImageMaker 프로그램을 최상위 디렉터리(FS64 OS/)로 이동시켜주기 때문에 아래와 같이 최상위 디렉터리의 makefile을 수정합니다.
(아래의 사진에서 "all: " 부분 중 Disk.img와 Utility의 순서를 사진과는 달리 바꿔 적어준다.)
(Disk.img를 생성하기 위해서는 ImageMaker가 필요한데, 그럴려면 Utility가 먼저 빌드되어야 동작되도록 위에서 04.Utility/ImageMaker/makefile의 내용을 작성했기 때문이다.)
수정을 완료한 뒤 다시 빌드를 수행하면 정확히 섹터 크기로 정렬된 Disk.img 파일을 확인할 수 있습니다.
QEMU를 통해 실행 결과를 보면 아래와 같습니다.
터미널에서 FS64 OS/ 디렉토리로 이동 -> make 하면 됩니다.
혹은
터미널에서 FS64 OS/ -> make clean -> 04.Utility/00.ImageMaker -> make -> FS64 OS/makefile -> make -> QEMU
이렇게 C 코드로 커널을 작성했습니다.
새로 작성한 makefile만 있으면 C 소스 파일과 헤더 파일을 Source 디렉터리에 추가하는 것만으로 커널 이미지를 생성할 수 있습니다.
앞으로 작성할 64bit 커널 역시 같은 형태의 makefile을 사용할 것입니다.
이제 IA-32e 모드로 전환하기 위한 준비의 일환으로 1MB 이상의 상위 메모리에 접근해서 데이터를 읽고 쓰는 테스트를 합니다.
보호 모드로 전환했지만 아직 4GB 영역까지 접근할 수 없습니다.
'시작하지 말았어야 했던 것 > 64비트 멀티코어 OS' 카테고리의 다른 글
| 64비트 멀티코어 OS[7] - 2. 1MB 주소와 A20게이트 그리고 A20게이트 적용과 메모리 크기 검사 (1) | 2021.03.15 |
|---|---|
| 64비트 멀티코어 OS[7] - 1. IA-32e 모드 커널과 메모리맵 그리고 IA-32e 모드 커널을 위한 메모리 초기화 (0) | 2021.03.13 |
| 64비트 멀티코어 OS[6] - 2. C 소스 파일 추가와 보호 모드 엔트리 포인트 통합 (0) | 2021.03.12 |
| 64비트 멀티코어 OS[6] - 1. 실행 가능한 C 코드 커널 생성 방법 (3) | 2021.03.11 |
| 64비트 멀티코어 OS[5] - 2. 보호 모드로 전환과 보호 모드용 커널 이미지 빌드와 가상 OS 이미지 교체 (0) | 2021.03.09 |