일반적으로 임베디드 시스템에서 NAND 플래시 메모리는 네 부분으로 나뉩니다.
- 부트로더용 파티션(여기서는 uboot.bin)
- uboot는 환경 변수를 저장하는 작은 파티션입니다
- 커널 파티션(여기서는 uImage.bin)
- rootfs 파티션
이제 몇 가지 질문이 있습니다.--
1> 32비트 ARM MCU에는 DRAM, NAND 또는 NOR 플래시 메모리와 같은 많은 외부 메모리 인터페이스가 연결되어 있습니다. 32비트 ARM MCU는 Uboot를 가져올 NAND의 주소를 어떻게 알 수 있나요? Uboot는 RAM의 어느 주소에 로드됩니까?
2> AVR과 같은 8비트 MCU에서는 RESET 벡터 주소가 0x0000이며 내장 FLASH 메모리에 위치합니다. 32비트 ARM MCU는 다양한 유형의 외부 메모리 인터페이스와 인터페이스하므로 RESET 벡터를 지정하는 방법입니다.
3> 32비트 ARM MCU인 경우 먼저 Uboot가 RAM에 들어간 다음 압축된 uimage를 RAM에 로드한 다음 uboot가 uIMage를 LOADADDR로 압축 해제합니다. 그러면 LOADADDR(압축되지 않은 이미지 주소)을 정의할 때 (uboot 자체 + RAM에 로드할 압축된 uImage) 공간을 고려해야 합니까? LOADADDR을 정의하기 위해 uImage를 어떻게 사용하나요?
4> Linux uImage가 rootfs에 내장되어 있습니까, 아니면 별도의 엔터티입니까? rootfs가 NAND에 위치한 별도의 엔터티인 경우 커널은 NAND에서 rootfs가 어디에 있는지 어떻게 알 수 있습니까?
답변1
1) 일반적으로 참조 매뉴얼에 정의된 각 부팅 가능한 인터페이스에는 오프셋이 있습니다. 예를 들어, NOR, NAND 등으로 매핑된 메모리에서 부팅할 수 있습니다. 예를 들어 NOR은 0x1000, NAND 0x4000일 수 있습니다. 참조 매뉴얼의 시작에 관한 장에서 알려줄 것입니다.
2) 1 참조
3) 일반적으로 uboot는 단지 "RAM으로 들어갈" 수는 없습니다. 이는 첫 번째 단계 부트로더를 통해 수행되어야 합니다. U-boot에는 이를 수행하는 SPL(보조 프로그램 로더) 기능이 있습니다. 이 SPL의 임무는 프로세서 SRAM 외부에서 실행하고 시스템 DRAM을 초기화하여 완전한 U-boot 실행 파일을 로드하는 데 사용할 수 있도록 하는 것입니다. 그러면 U-boot에는 사용 중인 보드/칩에 적합한 LOADADDR이 필요합니다. U-boot는 부팅 시 커널의 압축을 풀지 않습니다. 레거시적인 이유로 이는 일반적으로 커널 자체의 작업입니다. 분명히 커널은 메모리에 맞을 수 있어야 하며 커널 자체의 압축을 풀 때 다른 구성 요소(rootfs, 장치 트리)를 덮어쓰지 않도록 할 수 있습니다.
4) 두 옵션 중 하나가 존재하며 유효합니다. rootfs가 독립형이라면 어떤 유형의 파일 시스템인지 알아야 합니다. initramfs인 경우 원시 NAND에 저장되는 위치를 정의할 수 있습니다. 영구 파일 시스템(ext4)인 경우 U-boot는 파티션 매핑을 처리하는 방법을 알아야 합니다. 완료되면 실제로 주소 대신 장치 경로를 커널에 전달하게 됩니다.