BIOS 및 펌웨어 엔지니어링

하드웨어는 부팅되지만 제품은 부팅되지 않음

보드가 전원이 켜진 후 펌웨어 엔지니어링이 시작됩니다.

마더보드가 POST를 정상적으로 완료했더라도, 실제 배포된 제품에는 적합하지 않을 수 있습니다. 부팅 장치가 잘못 지정되어 중단되거나, 전원 공급이 재개된 후에도 전원이 켜지지 않거나, 현장 운영자가 절대로 변경해서는 안 되는 설정 옵션이 노출되거나, 잘못된 제품 식별 정보를 보고하거나, 애플리케이션 소프트웨어가 응답을 중단했을 때 복구되지 않을 수 있습니다.

펌웨어 엔지니어링은 이러한 제품 요구 사항을 제어 가능한 플랫폼 동작으로 구현합니다. 그 출발점은 정확한 마더보드 릴리스, 현재 펌웨어 빌드, 운영 체제 이미지, 연결된 장치, 전원 상태 요구 사항, 보안 정책 및 업데이트 방법입니다.

맞춤형 Mini-ITX 보드 설계 → 플랫폼 사양 →

제품 수준 펌웨어 적용 범위

BIOS 및 UEFI 펌웨어에서 설정할 수 있는 항목

기본 설정

부팅 우선순위, 활성화된 장치, 가상화, 스토리지 모드, 직렬 설정, 보안 옵션 및 생산 환경의 기본값.

설정 액세스

선택한 메뉴를 숨기고, 변경을 제한하며, 관리자 액세스 권한을 설정하고, 공장 측에서 제어해야 하는 현장 서비스 옵션을 제거합니다.

부팅 정책

NVMe, SATA, USB, PXE 또는 지원되는 HTTP 부팅 우선순위, 대체 순서, 부팅 지연 시간 및 복구 항목 조건.

전력 정책

AC 전원 손실 복구, RTC 기상, 소프트 오프 동작, 지원되는 절전 모드, 및 보드별 기상 소스.

플랫폼 정체성

제조업체, 제품명, 일련번호 정보, 보드 식별 정보, SMBIOS 필드, 자산 데이터 및 승인된 부팅 로고 변경 사항.

보안 및 업데이트

보안 부팅 키 소유권, TPM 노출, 설정 보호, 서명된 업데이트 정책, 복구 경로 및 양산 프로비저닝.

전원 상태 요구 사항

부팅, 종료 및 AC 전원 복구 시 정확히 어떤 작업이 수행되는지 정의하기

무인 장비의 경우, 전원 이상 발생 후 기술자가 키를 누르는 것에만 의존해서는 안 됩니다. 부팅 및 전원 동작은 실제 UEFI 구현, 보드 전원 로직, 연결된 저장 장치, 네트워크 경로 및 OS 이미지를 기준으로 정의되어야 합니다.

전력 입력 플랫폼 →

이사회 차원의 통제

펌웨어는 보드가 노출하는 기능만 제어할 수 있다

임베디드 Mini-ITX 설계에는 종종 데스크톱 BIOS에는 나타나지 않는 제어 기능이 포함됩니다. 이러한 기능의 동작 방식은 장착된 Super I/O, 임베디드 컨트롤러, GPIO 확장기, 트랜시버, 워치독, 팬 컨트롤러 또는 칩셋에 따라 달라집니다.

여러 직렬 포트 → GPIO 및 CAN 플랫폼 →

펌웨어-OS 간 데이터

ACPI 및 SMBIOS는 출하된 하드웨어를 정확히 기술해야 합니다.

펌웨어는 운영 체제와 관리 소프트웨어가 구성, 전력 관리 및 하드웨어 인벤토리 관리에 사용하는 표준화된 정보를 제공합니다. 구조가 올바르다고 해서 충분한 것은 아니며, 데이터는 해당 생산 보드 및 제품 식별 정보와 정확히 일치해야 합니다.

부팅 전 신뢰

보안 부팅에는 정의된 키 소유자와 업데이트 경로가 필요합니다.

프로덕션 보안 부팅(Secure Boot)은 단순히 활성화/비활성화 설정에 그치는 것이 아닙니다. 해당 프로젝트는 플랫폼 키를 누가 관리하는지, 어떤 키 교환 키를 신뢰할지, 허용된 서명 데이터베이스에 어떤 항목이 포함되는지, 취소된 이미지가 dbx에 어떻게 등록되는지, 그리고 승인된 필드 업데이트를 어떻게 복구 가능한 상태로 유지할지를 정의해야 합니다.

현재 UEFI 요구 사항에 따르면 보안 부팅 플랫폼 키(Secure Boot Platform Key) 형식은 최소 RSA-2048이어야 하며, dbx에 저장된 UEFI 이미지 해시는 최소 SHA-256을 사용해야 합니다. 이는 최소 암호화 요구 사항일 뿐, 완전한 제품 보안 정책은 아닙니다.

PK 소유권

보안 부팅 소유권을 설정하는 데 사용되는 플랫폼 키를 OEM, 고객 또는 다른 승인된 소유자 중 누가 관리하는지 결정하십시오.

KEK, db 및 dbx

신뢰할 수 있는 업데이트 기관, 허용되는 이미지, 무효화된 서명, 그리고 운영 환경에서 사용되는 프로비저닝 방식을 정의하십시오.

TPM 2.0

지원되는 경우, 최종 시스템에서 정의한 소유권 및 배포 정책에 따라 플랫폼 TPM을 노출하고 프로비저닝합니다.

회복

업데이트 실패나 키 변경 시, 의도된 신뢰 정책을 우회하지 않으면서 승인된 복구 경로를 유지해야 합니다.

네트워크 보안 시스템 →

프로덕션 펌웨어 제어

바이너리를 보드, 기본값 및 변경 내역과 함께 배포하십시오.

펌웨어 파일은 그 식별 정보와 호환성이 관리될 때만 생산 아티팩트가 됩니다. 출시된 바이너리는 메인보드 리비전, 기본 구성, 보안 프로비저닝, 업데이트 방법 및 변경 사유와 반드시 연계되어 있어야 합니다.

1. 이진 정체성 펌웨어 버전, 정확한 보드 리비전, 파일 크기, SHA-256 해시값 및 출시일을 기록하십시오.
2. 생성 기본값 엔지니어링 디버그 설정 및 현장 기술자의 변경 사항과 별도로, 배송된 설정 값을 동결하십시오.
3. 기록 변경 변경된 기능, 영향을 받는 하드웨어 또는 OS 버전, 알려진 제약 사항, 그리고 필요한 회귀 테스트를 파악하십시오.
4. 업데이트 및 복구 승인된 플래싱 방법, 버전 정책, 전원 손실 시 주의 사항, 롤백 규칙 및 복구 경로를 정의하십시오.

참조 사양

펌웨어 인터페이스 및 참조 사양

UEFI 2.11

표준화된 OS 전(pre-OS) 펌웨어 환경, 부팅 서비스, 런타임 서비스, 변수 및 프로토콜에 대한 최신 UEFI 사양.

ACPI 6.6

OS 기반 장치 구성, 플랫폼 설명, 전원 관리 및 시스템 이벤트에 관한 최신 ACPI 사양.

SMBIOS 3.9.0

플랫폼 및 설치된 하드웨어에 대해 시스템 펌웨어가 제공하는 표준화된 관리 정보에 대한 DMTF 사양.

TCG TPM 2.0 v185

2026년 3월 TPM 2.0 라이브러리 사양으로, TPM 2.0 구현에서 사용되는 아키텍처, 구조 및 명령어를 정의합니다.

인증 및 품질 기준 →

펌웨어 릴리스 게이트

출시할 예정인 정확한 펌웨어 빌드를 확인하십시오

펌웨어 엔지니어링은 정의된 바이너리 및 생산 구성으로 마무리됩니다. 그 후 엔지니어링 검증 단계에서는 해당 릴리스를 대상 보드에서 예정된 OS 이미지, 주변기기, 전원 상태 시나리오, 보안 프로비저닝, 업데이트 방법 및 복구 경로와 함께 실행합니다.

엔지니어링 검증 → 모든 엔지니어링 서비스 →

자주 묻는 질문

BIOS 및 펌웨어 엔지니어링 관련 질문