리눅스 Device Tree stdout-path 기준 정리

본문 중간의 쿠팡 추천 상품 구매시 쿠팡 파트너스에서 일정액의 수수료를 제공받습니다.

리눅스 Device Tree stdout-path 기준 정리

/chosen/stdout-path는 Devicetree에서 부팅 초기 콘솔 출력 장치를 가리키는 문자열 속성이다. 2026년 7월 13일 확인 기준 Devicetree Specification은 이 값이 장치 노드의 full path를 가리키며 alias도 허용하고, 문자열 안에 :가 나오면 그 앞까지만 경로로 해석한다고 설명한다. Linux 커널 문서는 /chosen 노드가 부팅 인자 같은 초기 런타임 설정을 전달하는 위치라고 정리한다.

실무에서는 DTS에 UART 노드가 있어도 stdout-path를 어떻게 적어야 하는지, alias와 실제 경로 중 무엇을 써야 하는지, 커널 파라미터의 console=와 어떤 관계인지 헷갈리기 쉽다. 이 글은 stdout-path의 의미, /chosen 안에서의 역할, linux,stdout-path 호환성, 안전한 작성 기준만 정리한다.

stdout-path는 어디에 두는 속성일까?

stdout-path는 루트 바로 아래의 /chosen 노드에 들어가는 선택 속성이다. Devicetree Specification은 /chosen 자체가 실제 하드웨어 장치를 나타내지 않고, 시스템 펌웨어가 실행 시점에 정한 파라미터를 담는 용도라고 설명한다.

Linux 커널 문서도 같은 흐름으로 /chosen를 초기 부팅 설정 전달 지점으로 다룬다. 대표적으로 bootargs가 커널 인자를 담고, 같은 자리에서 콘솔 출력 장치도 지정할 수 있다.

값은 무엇을 가리켜야 할까?

사양 기준 stdout-path 값은 콘솔로 사용할 장치 노드의 문자열 경로다. 보통은 /serial@... 같은 full path를 넣지만, aliases 노드에 등록된 별칭을 써도 된다.

즉, 아래 두 형태 모두 사양 범위 안에 있다.

/ {
    chosen {
        stdout-path = "/serial@f00:115200n8";
    };
};

/ {
    aliases {
        serial0 = &uart0;
    };

    chosen {
        stdout-path = "serial0:115200n8";
    };
};

실제 프로젝트에서는 alias를 이미 일관되게 관리하고 있다면 alias 표기가 유지보수에 유리할 수 있다. 반대로 보드별 alias naming이 자주 바뀌거나 부트 체인 단계마다 관례가 다르면 full path가 더 직관적일 수 있다.

: 뒤 문자열은 무엇일까?

Devicetree Specification은 stdout-path 안에 : 문자가 있으면 그 지점에서 경로가 끝난다고 명시한다. 즉 경로 해석 대상은 콜론 앞까지이고, 뒤쪽 문자열은 장치별 콘솔 설정에 쓰일 수 있는 부가 정보로 남는다.

많이 보이는 형태가 115200n8 같은 UART 설정 문자열이다. 다만 사양이 여기서 모든 장치에 대해 공통 포맷을 세세하게 정의하는 것은 아니다. 그래서 특정 드라이버나 부트로더가 어떤 접미 형식을 기대하는지는 해당 플랫폼 문서를 따로 확인하는 편이 안전하다.

alias와 full path 중 무엇이 더 무난할까?

상황	무난한 선택	이유
보드군 전체에서 serial0 같은 alias 규칙이 안정적이다	alias 사용	보드별 실제 주소가 달라도 DTS 가독성을 유지하기 쉽다
특정 노드를 정확히 가리켜야 하고 alias 관리가 느슨하다	full path 사용	해석 경로가 명확하다
오버레이나 보드 변형에서 alias가 자주 재정의된다	full path 우선 검토	추적 비용을 줄일 수 있다
부트 체인 문서가 alias 표기를 전제로 한다	그 관례 따름	펌웨어와 커널 설정 설명이 일치하기 쉽다

console= 커널 파라미터와 같은 것일까?

같은 개념은 아니다. Linux 커널 문서에서 /chosen는 부팅 인자와 초기 설정을 전달하는 위치이며, bootargs는 커널 파라미터 문자열을 담는다. 반면 stdout-path는 Devicetree 안에서 부팅 콘솔 장치를 가리키는 별도 속성이다.

즉, 하나는 커널 인자 문자열이고 다른 하나는 Devicetree 속성이다. 실제 부팅 결과는 플랫폼의 펌웨어 전달 방식과 커널 초기화 흐름에 따라 함께 영향을 받을 수 있으므로, 두 설정이 서로 모순되지 않게 유지하는 편이 안전하다.

 

 

stdin-path가 없으면 어떻게 볼까?

Devicetree Specification은 stdin-path가 따로 없으면 stdout-path가 입력 장치까지 정의하는 것으로 간주할 수 있다고 적고 있다. 즉 콘솔 입출력을 같은 장치로 잡는 전형적인 시나리오를 염두에 둔 규칙이다.

다만 모든 플랫폼이 실제 운영에서 동일한 입력 경로를 노출한다고 단정하면 안 된다. 글자 그대로 사양상 기본 가정일 뿐이므로, 부트로더나 보드 지원 코드가 별도 입력 장치 정책을 두는지는 별도 확인이 필요하다.

linux,stdout-path는 아직 써도 될까?

Devicetree Specification은 오래된 트리에서 deprecated 형태인 linux,stdout-path를 볼 수 있다고 설명한다. 그리고 stdout-path가 없을 때 호환성을 위해 클라이언트 프로그램이 linux,stdout-path를 지원할 수 있다고 적고 있다.

따라서 새 DTS를 쓸 때는 표준 속성인 stdout-path를 우선하는 편이 맞다. 기존 보드 파일이나 오래된 부트 체인과의 호환이 필요할 때만 과거 속성 존재 여부를 함께 점검하는 편이 안전하다.

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

확인 항목	이유
/chosen 아래에 속성이 있는지	stdout-path는 해당 위치의 속성으로 정의된다
값이 실제 UART 등 콘솔 장치 노드를 가리키는지	alias든 full path든 해석 대상이 분명해야 한다
: 앞 경로와 뒤 설정 문자열을 구분했는지	콜론 뒤를 경로 일부로 오해하면 잘못 읽기 쉽다
bootargs의 console=와 충돌하지 않는지	초기 콘솔 설정 해석을 복잡하게 만들 수 있다
레거시 트리에서 linux,stdout-path만 남아 있지 않은지	오래된 DTS 호환 문제를 빨리 찾을 수 있다

FAQ

Q. stdout-path에는 꼭 UART만 들어가야 할까?

사양 문구는 부팅 콘솔 출력에 사용할 장치 노드를 가리킨다고 설명한다. UART 예제가 가장 흔하지만, 핵심은 "부팅 콘솔 출력 장치"라는 점이다.

Q. alias를 쓰면 항상 full path보다 더 낫다고 볼 수 있을까?

그렇지는 않다. alias 규칙이 안정적이면 읽기 쉽지만, 보드 변형이나 오버레이에서 alias가 자주 바뀌면 오히려 추적이 어려워질 수 있다. 유지보수 관례가 더 중요한 기준이다.

Q. 새 DTS에서도 linux,stdout-path만 넣어도 될까?

권장하기 어렵다. 사양은 linux,stdout-path를 deprecated 호환 형태로 설명한다. 새 트리라면 표준 속성인 stdout-path를 우선하는 편이 안전하다.

정리

/chosen/stdout-path를 볼 때 핵심은 네 가지다. 이 속성은 실제 장치가 아니라 초기 부팅 설정을 담는 /chosen에 들어가고, 값은 콘솔 장치의 full path 또는 alias를 가리키며, : 뒤 문자열은 경로와 분리해서 봐야 하고, 오래된 트리에서는 linux,stdout-path가 남아 있을 수 있다.

실무에서 가장 무난한 기준은 "이 값이 어떤 장치를 가리키는지 사람이 바로 읽을 수 있는가"다. alias 관리가 잘 되어 있으면 alias를, 그렇지 않으면 full path를 택하고, bootargs의 console=와 모순되지 않게 유지하는 편이 안전하다.

참고 자료

• Devicetree Specification: /chosen Node
• Linux Kernel Documentation: Linux and the Devicetree