리눅스 시스템 구조와 부트 과정 이해(4) - Bootloader

앞선 게시글을 통해, 임베디드 리눅스 시스템에서 사용자 영역의 C 코드가 시스템 콜을 통해 커널 영역에 접근하고, 이를 통해 실제 하드웨어 자원(UART, GPIO 등)에 접근하는 흐름에 대해 대략적으로 이해했을 것이다.

 

이제 다시 근본적인 질문으로 돌아가 보자. 이렇게 동작하는 커널 시스템은 과연 어떻게 시스템에 로드되고, 우리가 작성한 C 코드가 이를 통해 하드웨어에 접근할 수 있게 되는 걸까? 큰 흐름을 살펴보자면 아래와 같다.

1. Power On
   시스템이 처음 켜질 때 전원이 공급됨
   이 단계에서 아무것도 로딩된 상태가 아님 (빈 CPU)
   
   
2. ROM Code (SoC 내부 Boot ROM)
   CPU에 하드코딩된 고정 펌웨어 코드
   제조사가 칩 내부에 구워놓은 코드로, 보통 ROM에 저장됨
   Booting device(SD, eMMC, NAND 등) 탐색
   부트로더의 위치 확인
   부트로더를 RAM으로 로딩하여 실행
   !!!!! 이 단계는 수정할 수 없음. SoC 제조사가 미리 정의
   
   
3. Booting Device 탐색
   ROM 코드가 미리 정의된 순서에 따라 부팅 장치를 찾음
   (eMMC → SD → USB → SPI NOR Flash)
   부트로더가 포함된 장치를 찾으면, 해당 섹터에서 부트로더 이미지를 메모리로 로딩
   
   
4.  Bootloader (U-Boot, Barebox, UEFI)
   여기서부터 사용자가 수정 가능
   RAM, 스택, 디바이스 트리 설정
   메모리 초기화 (Memory Init)
   커널 이미지(zImage 또는 uImage) 로딩
   !!!!!  이게 없다면 커널은 "내가 어디서 부팅됐는지, RAM 어디를 써야 하는지" 몰라서 실행 불가
   
   
5. Kernel
   시스템의 뇌 역할
   모든 드라이버 초기화
   파일 시스템 마운트
   메모리/프로세스/디바이스 관리
   
   
6. Platform (User Space, Application)
   실제 우리가 다루는 사용자 프로그램들이 실행되는 영역
   Shell, UART 프로그램, GUI 등
   여기부터 시스템 콜을 통해 커널과 통신 시작됨

---

우리가 라즈베리 파이를 맨 처음 설치할 때에 sd 카드에 부팅 디바이스를 설치하고 여기에 부트로더가 설치된다. 이를 실제로 확인해보자.

SD 카드의 부트 파티션(Windows에서 보이는 파일들)과 라즈베리파이에서 /boot/firmware로 마운트된 내용이 완벽히 일치함을 실제로 확인할 수 있다.

 

이를 다시 정리하자면,

1. 라즈베리파이 전원 인가
2. SoC 내부의 ROM 코드가 실행됨
3. SD 카드의 첫 번째 파티션(FAT32)을 읽음
4. bootcode.bin → start.elf 실행
5. config.txt, cmdline.txt 읽어서 설정 반영
6. kernel*.img 로딩하여 ARM CPU 부팅 시작

각 파일들의 역할은 위와 같다.