소프트웨어 공장

1. Yocto meta-swupdate 기반 임베디드 리눅스 OTA 업데이트 도입 배경 및 무결성 검증의 중요성임베디드 리눅스 시스템 배포 후 원격 필드 장비의 OS 및 애플리케이션을 안전하게 갱신하는 OTA(Over-The-Air) 파이프라인 구축은 필수적입니다. 단순히 바이너리를 덮어쓰는 방식은 업데이트 도중 전원 차단이나 네트워크 단절 시 시스템이 벽돌(Bricked) 상태가 되는 리스크를 동반합니다.본 가이드에서는 Yocto Project에서 제공하는 meta-swupdate 레이어와 U-Boot 듀얼 파티션(A/B) 스위칭 구조를 연동하여 atomic 업데이트 및 자동 롤백 기능을 구현합니다. 또한 OpenSSL 비대칭 키 기반 패키지 서명 검증과 cve-check 클래스를 활용한 자동화된 보..

1. Yocto Project 기반 타겟 이미지 배포 및 U-Boot 부팅 환경 구축 배경 Embedded Linux 시스템 개발 시 Yocto Project 기반으로 생성된 빌드 아티팩트를 타겟 스토리지에 안정적으로 배포하는 프로세스는 필수적입니다. 특히 온보드 시스템 환경에서는 BootROM의 부팅 순서, 파티션 테이블 레이아웃, U-Boot bootcmd 메모리 주소 매핑 오류로 인해 부팅 실패 현상이 빈번하게 발생합니다.본 문서에서는 Yocto에서 생성된 .wic 아티팩트를 SD 카드 및 eMMC 스토리지에 정확히 플래싱하는 세부 프로세스를 설명합니다. 또한, 일반적인 임베디드 보드의 U-Boot 환경 변수(bootargs, bootcmd) 설정 시 발생하기 쉬운 실수를 바로잡고, 시리얼 콘솔 기..

1. Buildroot 기반 임베디드 리눅스 A/B 파티션 OTA 업데이트 배경: 무중단 시스템 복구와 고신뢰성 펌웨어 업데이트임베디드 리눅스 시스템 제어 및 필드 디바이스 운용 시, 원격 장치의 지속성을 보장하기 위한 Over-the-Air(OTA) 업데이트 구현은 필수적입니다.기존 포스팅의 방식처럼 쉘 스크립트로 런타임 중인 파일시스템 내부(TARGET_DIR="/opt/firmware")에 직접 tar -xzf로 덮어쓰거나 단순 파일 백업(mv) 후 업데이트하는 방식(In-place update)은 심각한 기술적 오류를 내포하고 있습니다. 라이팅 중 전원이 차단되거나 네트워크 중단이 발생할 경우 파일시스템 메타데이터가 손상되어 디바이스가 부팅 불능(Bricked) 상태에 빠집니다.본 포스팅에서는 B..

1. Buildroot 기반 임베디드 리눅스 A/B 파티션 OTA 업데이트 배경: 무중단 시스템 복구와 고신뢰성 펌웨어 업데이트 임베디드 리눅스 시스템 제어 및 필드 디바이스 운용 시, 원격 장치의 지속성을 보장하기 위한 Over-the-Air(OTA) 업데이트 구현은 필수적입니다. 단순히 단일 파티션 파일 시스템 전체를 덮어쓰는(In-place update) 방식은 전원 차단이나 네트워크 중단 시 시스템을 부팅 불능(Bricked) 상태로 만들 수 있습니다.본 포스팅에서는 Buildroot 빌드 시스템과 U-Boot 부트로더를 연동하여 A/B 듀얼 루트 파티션(Dual Rootfs) 구조를 설계하는 표준 기술을 설명합니다. 업데이트 패키지 다운로드부터 dd 기반 플래싱, fw_setenv를 통한 부팅 ..

1. Buildroot 기반 임베디드 리눅스 A/B 파티션 OTA 업데이트 배경: 무중단 시스템 복구와 고신뢰성 펌웨어 업데이트 임베디드 리눅스 시스템 제어 및 필드 디바이스 운용 시, 원격 장치의 지속성을 보장하기 위한 Over-the-Air(OTA) 업데이트 구현은 필수적입니다. 단순히 단일 파티션 파일 시스템 전체를 덮어쓰는(In-place update) 방식은 전원 차단이나 네트워크 중단 시 시스템을 부팅 불능(Bricked) 상태로 만들 수 있습니다.본 포스팅에서는 Buildroot 빌드 시스템과 U-Boot 부트로더를 연동하여 A/B 듀얼 루트 파티션(Dual Rootfs) 구조를 설계하는 표준 기술을 설명합니다. 업데이트 패키지 다운로드부터 dd 기반 플래싱, fw_setenv를 통한 부팅 ..

1. Buildroot 기반 임베디드 리눅스 Device Tree(DTS/DTB) 설정 배경: 하드웨어 추상화 계층의 중요성ARM 및 Risc-V 기반 임베디드 리눅스 시스템 개발에서 커널 코드를 수정하지 않고 하드웨어 변경 사항을 반영하기 위해 Device Tree(DTS/DTB)를 정교하게 구성하는 과정은 필수적입니다. Buildroot 빌드 시스템은 커널 컴파일 프로세스와 integration되어 Device Tree Source(.dts)를 Device Tree Blob(.dtb) 바이너리로 변환합니다.이 과정에서 DTS 노드 레지스터 오프셋(reg), 인터럽트 설정, 클록주파수(clock-frequency) 또는 compatible 문자열 명세를 잘못 정의하면, 커널 부팅 시 Probe 동작에 ..

1. Buildroot 기반 임베디드 리눅스 시스템 구축 배경: U-Boot 및 시스템 통합의 중요성 임베디드 리눅스 시스템 개발에서 부트로더(Bootloader)와 루트 파일 시스템(Root File System)은 운영체제를 구동하고 하드웨어를 제어하는 핵심 요소를 구성합니다. 타겟 보드에서 동작하는 맞춤형 OS를 구성하려면 크로스 컴파일러 Toolchain 설정, U-Boot 부트로더, Linux Kernel, 루트 파일 시스템이 일관되게 빌드되는 자동화 환경이 필요합니다.Buildroot는 Makefile 및 Kconfig 빌드 시스템을 기반으로 통합 툴체인과 펌웨어 이미지를 소스 코드로부터 자동 생성하는 빌드 도구입니다. 단순한 파일 시스템 생성에 그치지 않고 타겟 하드웨어에 맞는 Custom ..

1. Buildroot 기반 U-Boot 커스터마이징 배경: U-Boot 빌드 및 시스템 제어의 필요성 임베디드 리눅스 시스템 개발에서 부트로더(Bootloader)는 하드웨어 초기화, 커널 이미지 로드, Boot Parameter 전달을 담당하는 핵심 요소입니다. Buildroot 환경에서는 기본 U-Boot 바이너리 빌드 기능만을 제공하지 않으며, 타겟 하드웨어 제어에 맞는 Custom Device Tree(DTS) 수정, bootcmd/bootargs 환경변수 영구 반영, Custom Command 추가 기능이 필수적입니다.Buildroot 내부의 U-Boot 소스를 직접 수정하고 단일 make를 실행할 경우, make clean 동작 시 수정 사항이 유실되거나 덮어씌워지는 문제가 발생합니다. 본 ..

1. Buildroot 기반 임베디드 리눅스 부팅 파이프라인 구축 배경: U-Boot와 Kernel 빌드의 중요성 임베디드 리눅스 시스템 개발에서 안정적인 타겟 시스템을 구축하기 위해서는 크로스 컴파일 툴체인 관리와 함께 하드웨어 초기화를 담당하는 부트로더(U-Boot) 및 리눅스 커널(Linux Kernel)의 완벽한 상호작용이 필수적입니다.Buildroot는 루트 파일 시스템(RootFS) 생성뿐만 아니라 U-Boot 및 커널 소스 코드 다운로드, 패치 적용, 컴파일을 단일 빌드 시스템 내에서 통합 제어할 수 있는 자동화 환경을 제공합니다. 기존의 개별 수동 빌드 방식은 환경 변수 미설치, 툴체인 버전 불일치, Device Tree Blob(DTB) 지정 오류 등으로 인해 부팅 실패(Kernel Pa..