목차
1. 첫 번째 이식 uboot (uboot에 관한 모든 것은 커널을 시작하는 것입니다.)
넷째, 최종적으로 루트 파일 시스템(rootfs)을 이식합니다.
1. 첫 번째 이식 uboot (uboot에 관한 모든 것은 커널을 시작하는 것입니다.)
1. uboot란 무엇인가요?
Uboot는 커널을 부팅하고 시작하는 데 사용되는 일종의 부트로더 로, 궁극적인 목적은 플래시에서 커널을 읽어 메모리 에 넣고 커널을 시작하는 것입니다. 따라서 UBOOT에는 플래시를 읽고 쓸 수 있는 기능이 필요합니다.
2. uboot의 기능은 무엇입니까?
1) uboot의 주요 기능은 운영 체제 커널을 시작하는 것입니다 . 커널을 시작하는 uboot의 마지막 코드에 반영됩니다.
2) uboot는 전체 컴퓨터 시스템 배포도 담당합니다. 이는 uboot의 마지막 매개변수 전달에 반영됩니다.
3) uboot에는 Flash와 같은 보드의 하드웨어를 작동시키기 위한 드라이버도 있습니다. 예를 들어 직렬 포트를 인쇄해야 하며, 핑 네트워크가 성공했는지, 플래시 삭제 및 프로그래밍이 성공했는지 등을 확인해야 합니다.
4) uboot는 사람들이 작동할 수 있는 명령줄 인터페이스를 제공해야 합니다. 예: Linux 터미널 명령줄 인터페이스.
예: 컴퓨터의 Windows 시스템
모든 컴퓨터 시스템을 실행하는 데 필요한 주요 핵심 구성 요소는 CPU + 외부 메모리(플래시/하드 디스크) + 내부 메모리(DDR SDRAM/SDRAM/SRAM)의 3가지입니다. 일반적인 PC 시작 프로세스는 다음과 같습니다. PC 전원을 켠 후 BIOS 프로그램이 먼저 실행됩니다.(실제로 PC의 BIOS는 NorFlash입니다.) BIOS 프로그램은 DDR 메모리와 하드 디스크를 초기화하는 역할을 담당합니다. 하드 디스크의 OS 이미지를 DDR로 읽은 다음 DDR로 점프하여 OS가 시작될 때까지 OS를 실행합니다(OS가 시작된 후에는 BIOS가 쓸모가 없습니다).
따라서 임베디드 시스템의 시작 프로세스는 BIOS가 uboot가 되고 하드 디스크가 플래시가 된다는 점을 제외하면 PC의 시작 프로세스와 거의 동일합니다.
3. uboot 기능에 대한 자세한 설명
자체적으로 직접 시작할 수 있습니다.
1) 일반 SoC는 SD 카드 부팅, NorFlash 부팅, NandFlash 부팅 등과 같은 다양한 부팅 방법을 지원합니다. •••• uboot를 부팅하려면 특정 SoC 부팅 설계에 따라 uboot를 설계해야 합니다.
2) uboot는 해당 부트 미디어에서 부팅할 수 있도록 하드웨어에 해당하는 코드 레벨에서 변경 및 이식되어야 합니다. 이 부분은 uboot 첫 번째 단계의 start.S 파일에서 구체적으로 다룹니다.
운영 체제 커널을 부팅하고 매개변수를 커널에 전달할 수 있습니다.
1) uboot의 궁극적인 목표는 커널을 시작하는 것입니다.
2) 리눅스 커널을 설계할 때 매개변수로 전달할 수 있도록 설계한다 . 즉, uboot에서 Linux 커널에 대한 일부 시작 매개변수를 준비하여 메모리의 특정 위치에 배치하고 커널에 전달할 수 있습니다. 커널이 시작된 후 이 특정 위치로 이동하여 매개변수를 가져옵니다. uboot에 의해 전달된 다음 커널에서 구문 분석됩니다. 매개변수, 이 매개변수는 Linux 커널의 부팅 프로세스를 안내하는 데 사용됩니다.
시스템 배포 기능 제공 가능
1) uboot는 플래시에서 전체 시스템(uboot, 커널, rootfs 등 포함)의 굽기와 다운로드를 완료하기 위해 사람들이 사용할 수 있어야 합니다.
2) 베어 메탈 튜토리얼(ARM 베어 메탈의 세 번째 부분)에서의 플래싱은 uboot의 fastboot 기능을 사용하여 다양한 이미지를 iNand에 구운 다음 iNand에서 시작하는 것입니다.
SoC 수준 및 보드 수준 하드웨어 관리 가능
1) uboot는 일부 하드웨어의 제어 기능을 실현합니다(하드웨어의 일부는 uboot에서 초기화됩니다). 왜냐하면 uboot는 일부 작업을 완료하기 위해 이러한 하드웨어를 작동시켜야 하기 때문입니다. 예를 들어, uboot는 플래싱을 구현하기 위해 iNand를 구동할 수 있어야 합니다. 예를 들어, 플래싱할 때 LCD에 진행률 표시줄을 표시하려면 uboot가 LCD를 구동할 수 있어야 합니다. 예를 들어, uboot는 작업을 제공하기 위해 직렬 포트를 구동해야 합니다. 직렬 포트를 통한 인터페이스. 예를 들어 uboot가 네트워크 기능을 실현하려면 네트워크 카드 칩을 구동해야 합니다.
2) SoC 레벨(예: 직렬 포트)은 SoC의 내부 주변 장치이고 보드 레벨은 SoC 외부 개발 보드의 하드웨어(예: 네트워크 카드, iNand)입니다.
uboot의 "라이프 사이클"
1) uboot의 수명주기는 uboot가 실행을 시작하는 시점과 종료되는 시점을 나타냅니다.
2) uboot는 기본적으로 운영 체제가 아닌 베어 메탈 프로그램입니다. 일단 uboot가 시작되면 SoC는 단순히 uboot를 실행합니다(즉, uboot가 실행 중인 동안 다른 프로그램을 동시에 실행할 수 없음을 의미합니다). uboot 실행이 완료되면, 되돌릴 수 없습니다. uboot로(따라서 uboot가 커널을 시작한 후에 uboot 자체가 종료되었습니다. uboot 인터페이스를 다시 보려면 시스템을 다시 시작하면 됩니다. 지금 다시 시작해도 uboot가 다시 활성화되지는 않습니다. 다시 시작하는 것은 uboot의 또 다른 삶일 뿐입니다. uboot)
3) uboot의 입구와 출구. uboot의 시작은 부팅 시 자동으로 시작되는 것이고, uboot의 유일한 종료는 커널을 시작하는 것입니다. Uboot는 다른 많은 작업(예: 시스템 굽기)도 수행할 수 있지만, 다른 작업을 실행한 후 uboot 명령줄로 돌아가서 uboot 명령을 계속 실행할 수 있으며, boot kernel 명령이 실행되면 돌아갈 수 없습니다.
4. uboot 작동 방식
베어메탈 프로그램 이미지 uboot.bin에서 시작
1) uboot의 본질은 베어 메탈 프로그램입니다 . 이는 베어 메탈 컬렉션에 작성된 베어 메탈 프로그램 xx.bin과 근본적으로 다르지 않습니다. 차이점이 있다면, 우리가 작성하는 대부분의 내용은 16KB 미만이고 uboot는 16KB보다 큽니다(일반적으로 uboot는 180k-400k 사이입니다).
2) Uboot 자체는 여러 개의 .c 파일과 .h 파일로 구성된 오픈 소스 프로젝트입니다. 구성 및 컴파일 후에는 베어 메탈 프로그램 uboot의 이미지 파일인 uboot.bin이 생성됩니다. 그런 다음 이 이미지 파일은 부팅 미디어에 적절하게 구워지고 SoC에 제공되어 시작됩니다. 즉, uboot는 실행 중이 아닐 때 uboot.bin으로 동작하며 일반적으로 부팅 매체에 있습니다.
3) uboot가 실행되면 메모리에 로드된 다음 CPU에 전달되어 한 번에 하나의 명령을 실행합니다.
Uboot의 명령형 쉘 인터페이스
1) 일반적인 베어메탈 프로그램은 실행 시 바로 실행되며, 실행 효과는 코드와 관련이 있습니다.
2) 일부 프로그램은 사람과 상호 작용해야 하므로 프로그램에 쉘이 구현되고(쉘은 인간-컴퓨터 상호 작용을 제공하는 인터페이스이며 ARM Bare Metal Complete Works의 16번째 부분을 상기시킴) uboot는 쉘을 구현합니다.
참고: 셸은 운영 체제가 아니며 운영 체제와 아무 관련이 없습니다. Linux에서 터미널을 열면 쉘이 나오는데, 명령을 입력하고 Enter를 눌러 실행할 수 있습니다. uboot의 쉘 작업 모드는 Linux의 터미널 쉘 작업 모드와 매우 유사합니다(사실 거의 동일하지만 명령 세트가 다릅니다. 예를 들어 Linux에서는 ls를 사용할 수 있지만 uboot에서는 ls를 사용할 수 있습니다. 인식하지 못합니다).
uboot 사용의 두 가지 핵심 사항인 명령과 환경 변수를 마스터하세요.
1) uboot가 시작된 후 대부분의 시간과 작업은 셸에서 수행됩니다(예를 들어, uboot가 시스템을 배포하려면 셸 아래에 명령을 입력해야 하며, 환경 변수를 설정하려면 명령줄에도 있어야 합니다) , 커널을 시작하려면 명령줄 knock 명령 아래에 있어야 합니다.
2) 명령어는 uboot 쉘에서 인식할 수 있는 다양한 명령어입니다. uboot에는 수십 개의 명령이 있는데, 그 중 일부는 일반적으로 사용되며 일부는 일반적으로 사용되지 않습니다(우리는 스스로 uboot에 명령을 추가할 수도 있습니다). 그리고 우리는 몇 가지 수업 시간을 사용하여 uboot에서 일반적으로 사용되는 명령을 차례로 배울 것입니다 .
3) uboot 환경변수와 운영체제 환경변수의 작동 원리와 방법은 거의 동일합니다. Uboot는 운영 체제의 설계 개념의 도움으로 설계되었습니다(명령줄 작업 방법은 Linux 터미널 명령줄에서 차용하고, 환경 변수는 운영 체제의 환경 변수에서 차용하며, uboot의 드라이버 관리는 거의 완전히 복사됩니다). Linux의 드라이버 프레임워크).
4) 환경변수는 시스템의 전역변수라고 볼 수 있으며, 환경변수 이름은 시스템에 내장되어 있다(알면 아는 것이고, 모르면 모르는 것이다). , 이 부분은 PATH 등 시스템에 기본으로 제공되는 환경변수이지만, 환경변수는 우리가 직접 추가하는 부분도 있고, 우리가 직접 추가하는 시스템은 모르지만 우리가 알고 있는 부분도 있습니다. 시스템이나 자체 프로그램은 런타임 시 환경 변수를 읽어 프로그램 작동을 안내할 수 있습니다. 이러한 설계의 장점은 유연성입니다. 예를 들어 프로그램의 실행 방법을 변경하려는 경우 프로그램 코드를 다시 수정한 후 다시 컴파일하고 실행할 필요가 없고 해당 환경 변수만 수정하면 됩니다. .
5) 환경 변수는 런타임 시 구성 속성입니다.
둘째, 리눅스 커널을 이식한다
1. 리눅스 커널이란 무엇입니까?
Linux 커널은 컴퓨터의 하드웨어와 인터페이스하는 쉽게 교체할 수 있는 가장 낮은 수준의 소프트웨어입니다. 커널은 "사용자 모드"에서 실행되는 모든 응용 프로그램을 물리적 하드웨어에 연결하고 프로세스 간 통신을 사용하여 프로세스가 서로 정보를 얻을 수 있도록 하는 역할을 합니다. .
1,300만 줄 이상의 코드가 포함된 Linux 커널은 세계에서 가장 큰 오픈 소스 프로젝트 중 하나입니다.
2. Linux 커널에는 무엇이 들어있나요?
Linux 커널은 주로 프로세스 관리 , 메모리 관리 , 장치 드라이버 , 파일 시스템 , 네트워크 프로토콜 스택 및 시스템 호출 로 구성됩니다 .
소스 코드 구성
3. 장치 트리 파일을 다시 컴파일하고 이식합니다.
1. 디바이스 트리 파일이란 무엇인가요?
디바이스 트리의 본질도 레지스터를 동작시키는 것이지만, 레지스터의 관련 정보는 디바이스 트리에 위치하므로, 레지스터를 구성할 때 OF 함수를 사용하여 디바이스 트리에서 레지스터 데이터를 읽어온 다음, 그것을 구성하십시오.
Linux 3.x 이전에는 장치 트리가 없었으며, Linux는 ARM 아키텍처의 보드 수준 정보를 Arch/arm/mach-xxx 및 Arch/arm/plat-xxx 폴더의 보드 수준 설명 파일을 통해 설명했습니다. 커널 소스 코드. ARM 하드웨어의 종류가 많아질수록 보드와 관련된 장치 파일이 많아지면서 커널의 크기도 커지게 되는데, 사실 이러한 하드웨어 보드 수준의 정보는 커널과는 아무런 관련이 없습니다.
2011년 Linus는 이 문제를 발견한 후 PowerPC 및 기타 아키텍처에서 이미 채택한 장치 트리 메커니즘을 도입하고 보드 수준 정보를 커널에서 분리하여 전용 파일 형식(.dts 파일)으로 설명했습니다. 장치 트리의 역할은 부트로더에 의해 커널로 전달될 수 있는 하드웨어 플랫폼의 하드웨어 리소스를 설명하는 것이며, 커널은 장치 트리에서 하드웨어 정보를 얻을 수 있습니다. 하드웨어 리소스를 설명할 때 장치 트리에는 두 가지 특성이 있습니다.
- 하드웨어 리소스를 트리 구조로 설명
- 헤더 파일과 마찬가지로 장치 트리 파일은 다른 장치 트리 파일을 참조하여 코드 재사용을 달성할 수 있습니다.
2. 장치 트리 파일이란 무엇입니까?
DTS, DTSI, DTB, DTC 파일과 같은 네 가지 유형의 장치 트리 파일이 있습니다.
DTC 도구의 소스 코드는 Linux 커널의 scripts/dtc/Makefile 파일에 있습니다.
hostprogs-y:= dtc
always:= $(hostprogs-y)
dtc-objs:= dtc.o flattree.o fstree.o data.o livetree.o treesource.o srcpos.o checks.o util.o
dtc-objs+= dtc-lexer.lex.o dtc-parser.tab.o
......위에서 볼 수 있듯이 DTC 도구는 dtc.c, flattree.c, fstree.c 및 기타 파일에 의존하며 최종적으로 DTC 호스트 파일을 컴파일하고 링크합니다. DTS 파일을 컴파일하려면 Linux 소스 코드의 루트 디렉터리를 입력한 후 다음 명령을 실행하면 됩니다.
make all #编译Linux源码中的所有东西，包括zImage、.ko驱动模块以及设备树
make dtbs #只是编译设备树ARM 아키텍처를 기반으로 한 SOC는 많고 하나의 SOC는 여러 개의 보드를 생산할 수 있으며 각 보드에는 해당 DTS 파일이 있는데 어떤 DTS 파일을 컴파일할지 어떻게 결정합니까? I.MX6ULL 칩 보드를 예로 들어, Arch/arm/boot/dts/Makefile을 열면 다음 내용이 있습니다.
dtb-$(CONFIG_SOC_IMX6UL) += \
imx6ul-14x14-ddr3-arm2.dtb \
imx6ul-14x14-ddr3-arm2-emmc.dtb \
......
dtb-$(CONFIG_SOC_IMX6ULL) += \
imx6ull-14x14-ddr3-arm2.dtb \
imx6ull-14x14-ddr3-arm2-adc.dtb \
......I.MX6ULL을 선택한 후(예: CONFIG_SOC_IMX6ULL=y) 이 SOC를 사용하는 보드에 해당하는 모든 .dts 파일이 .dtb로 컴파일됩니다. 새 보드를 만드는 경우 해당 .dts 파일만 생성한 다음 해당 .dtb 파일 이름을 dtb-$(CONFIG_SOC_IMX6ULL)에 추가하면 장치를 컴파일할 때 해당 .dts가 바이너리로 컴파일됩니다. 트리 .dtb 파일
3. 디바이스 트리 소스 파일(.dts)의 구문 소개
장치 트리는 보드의 장치 정보를 설명하기 위해 트리 구조를 사용합니다. 각 장치는 장치 노드라고 불리는 노드입니다. 각 노드는 일부 속성 정보를 통해 노드 정보를 설명합니다. 속성은 키-값 쌍입니다.
node-name@unit-address{
属性1 = ...
属性2 = ...
子节点...
}
⏩ 노드 이름: node-name은 문자로 시작하고 장치 범주를 설명하는 노드 이름을 지정하는 데 사용됩니다(루트 노드는 슬래시로 표시됨).
⏩ 유닛 주소: @unit-address는 유닛 주소를 지정하는 데 사용됩니다. @는 구분 기호이며 그 뒤에 실제 유닛 주소가 옵니다. 해당 값은 reg 속성 값이 없는 경우 노드 reg 속성의 첫 번째 주소와 일치합니다. 단위는 주소를 생략할 수 있습니다.
⏩ 노드 속성: 노드의 중괄호 { } 안에 포함된 내용은 노드 속성입니다. 노드는 여러 속성 정보를 포함할 수 있습니다. 장치 트리의 주요 내용은 노드의 속성을 작성하는 것입니다. 속성에는 사용자 정의 속성과 표준 속성이 포함됩니다.
모델 속성: 장치의 제조업체 및 모델을 지정하는 데 사용되며 여러 문자열은 ","로 구분됩니다.
호환 속성: 하나 이상의 문자열로 구성되며 노드를 찾는 데 사용되는 방법 중 하나입니다.
상태 속성: 사용됨 장치의 작동 상태를 나타냅니다. 장치 및 장치는 상태
등록 속성을 통해 비활성화되거나 활성화될 수 있습니다. 상위 버스에 의해 정의된 주소 공간에 있는 장치 리소스의 주소를 설명합니다. 일반적으로 레지스터 #
address-cells의 시작 주소와 길이를 나타내는 데 사용됩니다. #size -cells: 이 두 속성이 동시에 존재하며, 전자는 서브노드 reg 속성에서 주소 정보가 차지하는 워드 길이를 결정하고, 후자는 길이 정보가 차지하는 워드 길이를 결정합니다. , 부모 주소 및 주소
공간 길이는 세 부분으로 구성됩니다
– child-bus-address: 하위 버스 주소 공간의 물리적 주소, 이 물리적 주소가 차지하는 단어 길이는 상위 노드 – parent-bus-address의 #address-cells에 의해 결정됩니다
. 상위 버스 주소 공간의 물리적 주소는 상위 노드의 #address-cells에 의해 결정됩니다
. 단어 길이
4. 장치 트리 OF 기능
커널은 장치 노드에서 해당 노드에 정의된 속성을 얻기 위해 일련의 함수를 제공하는데, 이러한 함수는 of_로 시작하며 OF 함수라고 합니다. 장치 트리 버전의 드라이버를 작성할 때 하드웨어 구성 측면에서 이러한 OF 함수를 사용하여 장치 트리 파일에서 레지스터 주소와 같은 정보를 얻은 다음 구성해야 합니다.
넷째, 최종적으로 루트 파일 시스템(rootfs)을 이식합니다.
1. 루트 파일 시스템이란 무엇입니까?
루트 파일 시스템은 우선 파일 시스템으로, 이 파일 시스템은 일반 파일 시스템의 데이터 파일을 저장하는 기능을 갖고 있을 뿐만 아니라, 일반 파일 시스템에 비해 커널 시작 시 마운트된다는 점에서 특별하다. (mount), 커널 코드의 이미지 파일은 루트 파일 시스템에 저장되고 시스템 부팅 프로그램은 루트 파일 시스템이 마운트된 후 일부 초기화 스크립트(예: rcS, inittab) 및 서비스를 메모리에 로드합니다. . 우리는 파일 시스템과 커널이 완전히 독립적인 두 부분이라는 것을 이해해야 합니다. 임베디드 시스템에 이식된 커널은 개발보드에 다운로드되는데, 실제로 리눅스 운영체제를 시작할 방법이 없고, 파일 시스템을 로드할 수 없다는 오류가 발생하게 됩니다.
2. 루트 파일 시스템이 왜 그렇게 중요한가요?
루트 파일 시스템에는 시스템 시작에 필요한 디렉터리와 중요 파일은 물론 다른 파일 시스템을 마운트하는 데 필요한 파일이 포함되어 있습니다. 예를 들어:
init 프로세스의 응용 프로그램은 루트 파일 시스템에서 실행되어야 하며,
루트 파일 시스템은 루트 디렉터리 "/"를 제공하고,
파티션을 마운트할 때 Linux가 의존하는 정보는 루트 파일 시스템 /etc/fstab 파일에 저장됩니다. 쉘
명령 프로그램은 ls, cd 및 기타 명령과 같은 루트 파일 시스템에서 실행되어야 합니다.
즉, Linux 시스템 세트, 커널 자체만 작동할 수 없으며 rootfs여야 합니다(rootfs의 etc 디렉토리에 있는 구성 파일). , /bin/sbin 및 기타 디렉터리) 셸 명령 및 /lib 디렉터리의 라이브러리 파일 등)은 함께만 작동할 수 있습니다.
Linux가 시작되면 가장 먼저 마운트해야 하는 것은 루트 파일 시스템이며, 시스템이 지정된 장치에서 루트 파일 시스템을 마운트할 수 없는 경우 시스템은 오류를 발생시키고 시작을 종료합니다. 성공하면 다른 파일 시스템을 자동 또는 수동으로 마운트할 수 있습니다. 따라서 한 시스템에 여러 파일 시스템이 동시에 존재할 수 있습니다. Linux에서 파일 시스템을 저장 장치와 연결하는 프로세스를 마운트라고 합니다. 현재 파일 시스템 계층(루트)에 파일 시스템을 연결하려면 mount 명령을 사용합니다. 마운트를 수행할 때 파일 시스템 유형, 파일 시스템 및 마운트 지점을 제공하십시오. 루트 파일 시스템이 루트 디렉터리 아래 "/"에 마운트되면 루트 디렉터리 아래에 루트 파일 시스템의 다양한 디렉터리, 파일: /bin /sbin /mnt 등이 있고 다른 파티션은 루트 디렉터리에 마운트됩니다. /mnt 디렉토리, /mnt 디렉토리 아래에는 이 파티션의 다양한 디렉토리와 파일이 있습니다.
루트 파일 시스템에는 최소한 다음 디렉터리가 포함됩니다.
/etc/: 중요한 구성 파일을 저장합니다.
/bin/: 부팅 시 사용해야 하는 자주 사용되는 실행 파일을 저장합니다.
/sbin/: 부팅 프로세스 중에 필요한 시스템 실행 파일을 저장합니다.
/lib/: /bin/, /sbin/ 실행 파일에 필요한 링크 라이브러리와 리눅스 커널 모듈이 저장됩니다.
/dev/: 저장 장치 파일.
참고: 5개의 주요 디렉터리는 루트 파일 시스템에 저장되어야 하며 그 중 어느 것도 생략될 수 없습니다.
3. 리눅스 파일 시스템의 공통 디렉터리
Linux 파일 시스템에는 일반적으로 다음 디렉터리가 있습니다.
/bin 디렉토리
모든 사용자가 사용할 수 있는 기본 명령이 저장되는 디렉토리로, 다른 파일 시스템을 마운트하기 전에도 사용할 수 있으므로 /bin 디렉토리는 루트 파일 시스템과 동일한 파티션에 있어야 한다.
/bin 디렉토리에서 일반적으로 사용되는 명령은 cat, chgrp, chmod, cp, ls, sh, kill, mount, umount, mkdir, mknod, test 등입니다. Busybox를 사용하여 루트 파일 시스템을 만들 때, bin 디렉토리에 생성하면 일부 실행 파일, 즉 사용 가능한 일부 명령을 볼 수 있습니다.
/sbin 디렉토리
시스템 명령어, 즉 관리자만이 사용할 수 있는 명령어가 저장되는 디렉토리로, /usr/sbin, /usr/local/sbin 디렉토리에도 시스템 명령어가 저장될 수 있으며, /sbin 디렉토리에는 기본적인 시스템 명령어가 저장된다. 이는 시스템 시작, 시스템 복구 등에 사용됩니다. /bin 디렉토리와 유사하게 /sbin은 다른 파일 시스템을 마운트하기 전에 사용할 수 있으므로 /sbin 디렉토리는 루트 파일 시스템과 동일한 파티션에 있어야 합니다.
/sbin 디렉토리에서 일반적으로 사용되는 명령에는 shutdown, 재부팅, fdisk, fsck 등이 있습니다. 로컬 사용자가 설치한 시스템 명령은 /usr/local/sbin 디렉토리에 있습니다.
/dev 디렉터리
에는 장치 파일이 저장되는 디렉터리로, 장치 파일은 Linux에서 고유한 파일 형식으로, Linux 시스템에서는 다양한 장치에 파일 형태로 접근, 즉 장치 파일을 읽고 써서 특정 하드웨어를 동작시킨다. . 예를 들어 직렬 포트 0은 "dev/ttySAC0" 파일을 통해 동작할 수 있고, MTD 장치의 두 번째 파티션은 "/dev/mtdblock1"을 통해 접근할 수 있다.
/etc 디렉터리
이 디렉터리는 다양한 구성 파일을 저장합니다. PC의 Linux 시스템의 경우 /etc 디렉터리 아래에 많은 파일과 디렉터리가 있습니다. 이러한 디렉터리 파일은 선택 사항이며 시스템의 응용 프로그램에 따라 다릅니다. 프로그램에는 구성 파일이 필요합니다. 임베디드 시스템에서는 이러한 내용을 크게 줄일 수 있습니다.
/lib 디렉토리는
공유 라이브러리와 로드 가능한(드라이버 프로그램)을 이 디렉토리에 저장하며, 공유 라이브러리는 시스템을 시작하는 데 사용됩니다. /bin /sbin 디렉토리에 있는 프로그램과 같이 루트 파일 시스템에서 실행 가능한 프로그램을 실행합니다.
/home 디렉터리
는 사용자 디렉터리로 선택 사항이며, 각 일반 사용자의 경우 /home 디렉터리 아래에 사용자 이름을 딴 하위 디렉터리가 있으며, 여기에는 사용자 관련 구성 파일이 저장됩니다.
/root 디렉토리
는 루트 사용자의 디렉토리이고, 이에 따라 일반 사용자의 디렉토리는 /home 아래의 하위 디렉토리이다.
/usr 디렉터리
/usr 디렉터리의 내용은 다른 파티션에 저장한 다음 시스템 시작 후 루트 파일 시스템의 /usr 디렉터리에 마운트할 수 있습니다. 이는 공유된 읽기 전용 프로그램과 데이터를 저장합니다. 이는 /usr 디렉토리의 내용이 여러 호스트 간에 공유될 수 있음을 의미하며 이는 주로 FHS 표준을 준수합니다. /usr에 있는 파일은 읽기 전용이어야 하며, 기타 호스트 관련 파일과 변수 파일은 /var 등의 다른 디렉터리에 저장되어야 합니다. /usr 디렉토리는 임베디드로 줄일 수 있습니다.
/var 디렉터리는
/usr 디렉터리의 반대 디렉터리로, /var 디렉터리에는 스풀 디렉터리(메일, 뉴스), 로그 파일, 임시 파일 등의 변수 데이터가 저장됩니다.
/proc 디렉토리
는 proc 파일 시스템의 마운트 지점으로 자주 사용되는 빈 디렉토리입니다. proc 파일 시스템은 가상 파일 시스템입니다. 실제 저장 장치가 없습니다. 디렉토리와 파일은 커널에 의해 임시로 생성됩니다. 시스템의 작동 상태를 나타내며, 그 안에 있는 파일 제어 시스템도 작동할 수 있습니다.
/mnt 디렉토리는
특정 파일 시스템의 마운트 지점을 임시로 마운트하는 데 사용되며 일반적으로 빈 디렉토리이며 /mnt/cdram /mnt/hda1과 같이 그 안에 빈 하위 디렉토리를 생성할 수도 있습니다. CD나 하드디스크를 임시로 마운트하는데 사용됩니다.
/tmp 디렉토리는
임시 파일을 생성해야 하는 일부 프로그램에서 사용하는 /tmp 디렉토리 아래에 임시 파일(일반적으로 빈 디렉토리)을 저장하는 데 사용됩니다. 따라서 /tmp 디렉토리가 존재하고 액세스 가능해야 합니다.