리눅스 Device Tree bootargs 기준 정리

리눅스 Device Tree bootargs 기준 정리

/chosen/bootargs는 Devicetree에서 부팅 인자를 담는 선택 문자열 속성이다. 2026년 7월 30일 확인 기준 Devicetree Specification은 이 값이 클라이언트 프로그램의 boot arguments를 지정하는 문자열이며, 인자가 필요 없으면 null string일 수도 있다고 설명한다. Linux 커널 문서는 Linux 부팅에서 이 값이 kernel parameters string, 즉 커널 command line로 쓰인다고 정리한다.

실무에서는 bootargs가 꼭 필요한지, stdout-path나 initrd 정보와 어떻게 구분해야 하는지, DTS에 적은 값이 최종 부팅 인자와 항상 같은지 헷갈리기 쉽다. 이 글은 bootargs의 의미, Linux에서의 해석, 안전한 작성 기준만 짧게 정리한다.

bootargs는 어디에 두는 속성일까?

bootargs는 루트 바로 아래의 /chosen 노드에 들어간다. Devicetree Specification은 /chosen가 실제 하드웨어 장치를 나타내는 노드가 아니라, 시스템 펌웨어가 실행 시점에 선택하거나 지정한 파라미터를 설명하는 자리라고 정의한다.

따라서 bootargs를 주변 장치 노드 안에 넣는 식으로 이해하면 안 된다. 이 값은 보드 하드웨어 설명이라기보다 부팅 시점 설정 전달에 가깝다.

값의 타입과 의미는 무엇일까?

사양 기준 bootargs의 값 타입은 <string>이다. 즉 숫자 셀 배열이나 phandle이 아니라, 공백으로 구분된 부팅 인자 문자열을 담는 방식으로 봐야 한다.

Devicetree Specification은 인자가 필요 없으면 값이 null string일 수도 있다고 적고 있다. 그래서 모든 DTS가 반드시 긴 커널 파라미터 문자열을 가져야 하는 것은 아니다.

/ {
    chosen {
        bootargs = "console=ttyS0,115200 root=/dev/mmcblk0p2 rw";
    };
};

Linux에서는 어떻게 해석할까?

Linux 커널 문서는 /chosen 노드가 런타임 구성 데이터를 전달하는 위치라고 설명하며, 예시에서 bootargs를 kernel parameters string으로 보여 준다. 이어서 bootargs는 kernel arguments를 담고, initrd-start와 initrd-end는 initrd blob의 주소와 크기를 정의한다고 구분한다.

즉 Linux 관점에서 bootargs는 "문자열 형태의 커널 명령행"으로 이해하는 것이 가장 안전하다. 반대로 initrd 주소나 콘솔 장치 경로 같은 다른 성격의 정보는 별도 속성으로 분리해서 봐야 한다.

stdout-path와 무엇이 다를까?

속성	의미	값 형태
bootargs	클라이언트 프로그램 또는 Linux 커널에 전달할 부팅 인자	문자열
stdout-path	부팅 콘솔 출력 장치를 가리키는 경로 또는 alias	장치 경로 문자열
initrd-start, initrd-end	initrd 위치와 범위	주소 값

헷갈리기 쉬운 지점은 console=ttyS0,115200 같은 커널 파라미터가 bootargs 안에 들어갈 수 있다는 점이다. 하지만 그 사실이 bootargs와 stdout-path를 같은 속성으로 만들지는 않는다. 하나는 command line 문자열이고, 다른 하나는 콘솔 장치 선택 속성이다.

DTS에 적은 값이 최종 값이라고 단정해도 될까?

그렇게 단정하는 것은 안전하지 않다. Devicetree Specification은 /chosen를 시스템 펌웨어가 실행 시점에 정한 파라미터를 담는 노드로 설명한다. 또 Linux의 오래된 공식 문서인 Booting the Linux kernel without Open Firmware는 flattened format을 쓰는 플랫폼에서 U-Boot가 /chosen 노드를 생성하고 채우는 경우가 있다고 적고 있다.

따라서 소스 DTS에 적힌 bootargs만 보고 끝내기보다, 실제 부트 체인에서 마지막 단계의 펌웨어나 부트로더가 이 값을 덮어쓰거나 추가하는지 함께 확인하는 편이 안전하다. 이 문장은 특정 부트로더가 항상 덮어쓴다는 뜻이 아니라, 최종 값의 책임 위치가 DTS 원본 하나로 고정되지 않을 수 있다는 의미다.

실무에서 확인할 기준은 무엇일까?

확인 항목	이유
/chosen 아래에 정의했는지	사양이 그 위치를 전제로 한다
값을 문자열로 넣었는지	bootargs는 <string> 속성이다
커널 인자만 담고 다른 의미의 값을 섞지 않았는지	콘솔 장치 경로와 initrd 주소는 별도 속성으로 구분된다
인자가 없을 때 빈 문자열 또는 생략이 더 맞는지 검토했는지	사양은 null string 가능성을 허용한다
최종 부트로더 단계가 값을 수정하는지 확인했는지	실행 시점에 채워지는 구조라 원본 DTS와 실제 값이 다를 수 있다

FAQ

Q. bootargs는 모든 Device Tree에 꼭 있어야 할까?

아니다. Devicetree Specification에서 bootargs는 optional 속성이다. 또 boot arguments가 필요 없으면 null string일 수도 있다고 설명한다.

Q. bootargs 안에 console=가 있으면 stdout-path는 필요 없을까?

두 속성의 역할이 다르므로 그렇게 일반화하면 안 된다. console=는 커널 command line 일부이고, stdout-path는 Devicetree의 콘솔 장치 선택 속성이다. 플랫폼 문서와 부트 체인 동작을 함께 봐야 한다.

Q. DTS 원본에 적힌 bootargs만 보면 실제 부팅 인자를 알 수 있을까?

항상 그렇지는 않다. 공식 문서들은 /chosen가 실행 시점 파라미터를 담는 자리라고 설명하고, Linux의 관련 문서는 일부 플랫폼에서 U-Boot가 이 노드를 채운다고 적고 있다. 실제 시스템에서는 최종 부트로더 단계도 함께 봐야 한다.

정리

/chosen/bootargs를 볼 때 핵심은 다섯 가지다. 이 속성은 실제 장치 정보가 아니라 부팅 시점 파라미터이고, 위치는 /chosen 아래이며, 값 타입은 문자열이고, Linux에서는 커널 command line로 해석되며, 최종 값은 부트 체인 마지막 단계에서 바뀔 수 있다.

실무에서 가장 무난한 기준은 "이 값이 커널 인자 문자열인지, 그리고 실제 부팅 직전에 누가 최종 값을 결정하는지"를 분리해서 보는 것이다. stdout-path, initrd-start, initrd-end와 혼동하지 않으면 대부분의 오해를 줄일 수 있다.

참고 자료

• Devicetree Specification: /chosen Node
• Linux Kernel Documentation: Linux and the Devicetree
• Linux Kernel Documentation: Booting the Linux/ppc kernel without Open Firmware