임베디드 A/B 부팅 이중화 — OTA 안전성을 위한 부트 슬롯 설계

OTA 업데이트는 전원 끊김과 잘못 빌드된 펌웨어 둘 다에서 살아남아야 합니다. 전원 끊김은 쓰기 중인 슬롯을 망가뜨리고, 잘못된 펌웨어는 일단 다 쓰였더라도 부팅을 못 합니다. A/B 슬롯은 부팅 가능한 사본 한 벌을 항상 남겨 두는 방식으로 두 문제를 동시에 해결합니다.

#한 줄 요약

같은 부트 체인을 두 슬롯에 두고, U-Boot의 bootcount·altbootcmd로 부팅 실패를 감지해 자동 fallback 시키면 OTA가 어디서 끊겨도 시스템은 살아 있습니다.

#왜 A/B인가

업데이트 도중 시스템이 부서지지 않으려면, 지금 실행 중인 코드를 덮어쓰지 않는 사본을 따로 두어야 합니다. 한 슬롯에서 부팅 중일 때 다른 슬롯에 새 펌웨어를 쓰고, 다 쓰면 부팅 슬롯을 바꿔 재부팅합니다. 새 슬롯이 잘 부팅되면 그 슬롯이 active가 됩니다. 부팅이 실패하면 자동으로 이전 슬롯으로 되돌아옵니다.

1
[Slot A: active]              [Slot B: standby]
2
  bootcount = 0                 (이전 펌웨어)
3
       |
4
       v
5
  download new image -> write to B
6
       |
7
       v
8
  flag B as active, set bootcount limit
9
       |
10
       v
11
  reboot -> try B
12
       |
13
       +---- success: B becomes active
14
       |
15
       +---- fail (panic, no kernel): bootcount > bootlimit
16
                                       -> U-Boot picks A again

이 패턴이 라우터·셋톱·차량 ECU 모두에서 사실상의 표준입니다. Android 7부터의 A/B OTA도 같은 발상을 모바일에 가져온 것입니다.

#파티션 레이아웃

eMMC나 NOR 한 장에 슬롯 두 개를 올리는 표준 레이아웃입니다.

1
eMMC user area
2
+-----------------+ 0x000000
3
| GPT             |
4
+-----------------+
5
| boot_a (FIT)    |  10 MB
6
+-----------------+
7
| boot_b (FIT)    |  10 MB
8
+-----------------+
9
| rootfs_a        |  512 MB
10
+-----------------+
11
| rootfs_b        |  512 MB
12
+-----------------+
13
| data            |  나머지 (공유)
14
+-----------------+

data는 슬롯 공유입니다. 그렇지 않으면 업데이트 후 사용자 데이터가 사라집니다. 부팅에 필요한 것(커널·DT·initramfs)만 슬롯에 두고, 가변 데이터는 공유 파티션에 둡니다.

U-Boot 환경에는 슬롯 상태를 저장합니다.

1
=> printenv
2
BOOT_SLOT=A
3
BOOT_AB_TRYING=B
4
bootcount=0
5
bootlimit=3

#bootcount와 altbootcmd

U-Boot은 부트 횟수를 비휘발 저장소에 기록할 수 있습니다. 부팅이 성공하면 userspace가 bootcount=0으로 리셋합니다. 부팅이 실패하면 다음 부팅에서 bootcount가 증가만 합니다.

1
=> setenv bootcmd 'run boot_slot_${BOOT_SLOT}'
2
=> setenv altbootcmd 'run switch_slot ; run boot_slot_${BOOT_SLOT}'
3
=> setenv bootlimit 3
4
=> saveenv

bootcount가 bootlimit을 넘으면 U-Boot이 bootcmd 대신 altbootcmd를 실행합니다. switch_slot은 슬롯을 바꿔 끼우는 사용자 정의 명령이고, 그다음 다시 부팅합니다.

1
=> setenv switch_slot '
2
    if test "${BOOT_SLOT}" = "A"; then
3
        setenv BOOT_SLOT B;
4
    else
5
        setenv BOOT_SLOT A;
6
    fi;
7
    setenv bootcount 0;
8
    saveenv'
9
=> setenv boot_slot_A '
10
    setenv mmcpart 1;
11
    load mmc 0:${mmcpart} ${kernel_addr_r} boot.itb;
12
    bootm ${kernel_addr_r}'
13
=> setenv boot_slot_B '
14
    setenv mmcpart 2;
15
    load mmc 0:${mmcpart} ${kernel_addr_r} boot.itb;
16
    bootm ${kernel_addr_r}'

이렇게 짜 두면 bootlimit 횟수만큼 새 슬롯을 시도하다 실패하면 자동으로 이전 슬롯으로 되돌아갑니다.

#bootcount.c — U-Boot 측 구현

drivers/bootcount/에 백엔드별 구현이 들어 있습니다. SRAM·env·EEPROM·RTC·AT91SAM PMC 등 보드마다 골라 쓸 수 있습니다.

1
// drivers/bootcount/bootcount_env.c (요지)
2
void bootcount_store(ulong a)
3
{
4
    char buf[32];
5
    sprintf(buf, "%lu", a);
6
    env_set("bootcount", buf);
7
    env_save();
8
}
9

10
ulong bootcount_load(void)
11
{
12
    char *s = env_get("bootcount");
13
    return s ? simple_strtoul(s, NULL, 10) : 0;
14
}

defconfig에는 다음을 켭니다.

1
CONFIG_BOOTCOUNT_LIMIT=y
2
CONFIG_BOOTCOUNT_ENV=y
3
# 또는 더 안전한 백엔드
4
# CONFIG_BOOTCOUNT_I2C=y
5
# CONFIG_SYS_I2C_RTC_ADDR=0x68

env 백엔드는 env 자체가 망가지면 같이 사라지는 약점이 있습니다. 양산 시스템에서는 RTC SRAM이나 별도 EEPROM처럼 부트 환경과 독립된 비휘발 영역을 쓰는 편이 안전합니다.

#userspace에서 부팅 성공 표시

부팅이 성공한 기준은 시스템마다 다릅니다. systemd가 올라오는 것까지면 충분한 시스템도 있고, 네트워크 연결이 확인되어야 하는 시스템도 있고, 핵심 애플리케이션이 5분 동안 정상 동작해야 비로소 “부팅 성공”이라고 인정하는 시스템도 있습니다.

성공이 확정되면 fw_setenv로 카운터를 리셋합니다.

1
[Unit]
2
Description=Mark boot as successful
3
After=multi-user.target
4
Requires=critical-app.service
5

6
[Service]
7
Type=oneshot
8
ExecStart=/usr/sbin/fw_setenv bootcount 0
9
ExecStart=/usr/sbin/fw_setenv upgrade_available 0
10

11
[Install]
12
WantedBy=multi-user.target

upgrade_available은 업데이트 도구가 켜는 플래그입니다. “방금 새 슬롯으로 부팅했음”을 의미합니다. 성공이 확인되어야 이 플래그를 끄고, 그래야 다음 부팅 실패가 fallback을 발동시킬 수 있습니다.

#업데이트 흐름 전체

OTA 한 사이클의 단계를 정리하면 이렇습니다.

1. (active=A) update agent가 새 boot.itb·rootfs.img 다운로드.
2. agent가 비활성 슬롯 B에 기록 (atomic write 또는 부분 sync 후 fsync).
3. agent가 fw_setenv로 BOOT_SLOT=B, upgrade_available=1, bootcount=0, bootlimit=3을 설정.
4. reboot.
5. U-Boot이 bootcount=1로 올리고 B 부팅 시도.
6. 결과에 따라 분기.
   • 성공: systemd가 mark-boot-success 실행 → bootcount=0.
   • 실패: U-Boot이 다음 부팅에서 bootcount=2 → 또 실패 → 3 → altbootcmd.
7. altbootcmd가 BOOT_SLOT=A로 돌리고 A 부팅.

업데이트 에이전트가 직접 BOOT_SLOT을 토글하는 게 아니라 U-Boot에게 토글 권한을 주는 점이 핵심입니다. agent가 토글하면 agent를 트로이로 만들면 fallback 안전망이 동시에 깨집니다.

#Android A/B와의 비교

Android A/B는 같은 원리지만 훨씬 큰 단위에서 작동합니다. 슬롯 안에 boot·system·vendor·product·odm 등을 모두 두 벌 둡니다. Android는 bootloader_message_ab 구조체를 misc 파티션에 두고, U-Boot은 그것을 읽어 슬롯을 결정합니다.

1
struct slot_metadata {
2
    uint8_t priority;
3
    uint8_t tries_remaining;
4
    uint8_t successful_boot;
5
    uint8_t verity_corrupted;
6
} __attribute__((packed));

priority가 큰 슬롯부터 시도하고, 성공하면 successful_boot=1을 박습니다. 임베디드 시스템에서 자체 구조를 만들 때도 이 세 필드는 거의 그대로 따라가는 편이 안전합니다.

#CONFIG_BOOTCOUNT_LIMIT 깊이 — 백엔드와 atomic update

CONFIG_BOOTCOUNT_LIMIT은 U-Boot 빌드 옵션이고, 값을 어디에 저장할지는 별도의 백엔드 옵션이 결정합니다. 백엔드 선택은 신뢰성·복구 시나리오에 직접 영향을 줍니다.

권장 양산 defconfig 예:

1
CONFIG_BOOTCOUNT_LIMIT=y
2
CONFIG_BOOTCOUNT_I2C=y
3
CONFIG_SYS_BOOTCOUNT_ADDR=0x68
4
CONFIG_SYS_BOOTCOUNT_OFFSET=0x10
5
CONFIG_BOOTCOUNT_BOOTLIMIT=3

bootcount_store()는 write-then-readback 패턴이 안전합니다. 쓰기 직후 다시 읽어 같은 값인지 확인하고, 다르면 다른 백엔드(또는 마지막 값)로 폴백합니다. env 백엔드는 env_save() 한 번에 섹터 erase + write가 일어나므로 도중에 전원이 끊기면 env 전체가 손상될 수 있습니다. CONFIG_SYS_REDUNDAND_ENVIRONMENT를 켜고 env partition을 두 벌 두면 한쪽이 깨져도 다른 쪽에서 복구됩니다.

#altbootcmd 흐름 — 실패 감지부터 슬롯 전환까지

U-Boot의 메인 부팅 진입점은 bootcmd입니다. bootcount > bootlimit일 때 대신 실행되는 것이 altbootcmd입니다. 두 변수가 분리되어 있어 “정상 부팅 경로”와 “fallback 경로”를 명시적으로 다르게 짤 수 있습니다.

1
# boot.scr 소스 — mkimage -A arm -T script로 .scr 변환
2
setenv bootargs "root=/dev/mmcblk0p${rootpart} rootwait console=ttyS0,115200"
3

4
if test "${BOOT_COUNT}" -ge "${BOOT_LIMIT}"; then
5
    echo "*** bootcount exceeded, switching slot ***"
6
    if test "${BOOT_SLOT}" = "A"; then
7
        setenv BOOT_SLOT B
8
        setenv rootpart 4
9
        setenv kernelpart 2
10
    else
11
        setenv BOOT_SLOT A
12
        setenv rootpart 3
13
        setenv kernelpart 1
14
    fi
15
    setenv BOOT_COUNT 0
16
    saveenv
17
fi
18

19
load mmc 0:${kernelpart} ${kernel_addr_r} boot.itb
20
bootm ${kernel_addr_r}

이 script가 altbootcmd로 등록되어 있으면, bootcount 초과 시 U-Boot이 자동으로 호출합니다. 슬롯 전환 후 BOOT_COUNT를 0으로 리셋해야 전환된 슬롯도 같은 횟수만큼 시도할 기회를 가집니다. 리셋을 잊으면 한 번 fallback이 발동된 뒤 양 슬롯 모두 부팅 시도가 봉쇄됩니다.

#upgrade_available — RAUC·SWUpdate와 U-Boot의 계약

upgrade_available은 userspace 업데이트 도구와 U-Boot 사이의 단방향 깃발입니다. 도구가 새 슬롯에 이미지를 쓰고 1로 set 하고, 첫 부팅이 성공하면 userspace가 0으로 clear 합니다.

1
# RAUC post-install hook 또는 swupdate post-update 스크립트
2
fw_setenv upgrade_available 1
3
fw_setenv bootcount 0
4
fw_setenv BOOT_SLOT B
5
reboot

U-Boot 측에서는 이 플래그가 fallback을 발동할지의 조건으로 쓰입니다.

1
# bootcmd 일부
2
if test "${upgrade_available}" = "1"; then
3
    if test "${BOOT_COUNT}" -ge "${BOOT_LIMIT}"; then
4
        echo "Upgrade failed, falling back"
5
        run switch_slot
6
    fi
7
fi
8
run boot_slot_${BOOT_SLOT}

플래그가 0이면 fallback 로직 자체가 무시됩니다. 이미 정상 운영 중인 시스템에서 우연한 reset이 누적되어 fallback이 발동하지 않게 막는 안전장치입니다. RAUC는 system.conf의 [handler] 섹션에서 bootloader=uboot와 data-directory만 지정하면 이 플래그 토글을 자동으로 처리해 줍니다.

#Boot status 상태머신 — installed → trying → good/bad

A/B 시스템의 각 슬롯은 4-state 상태머신을 가집니다. 상태는 환경 변수(예: BOOT_A_STATE, BOOT_B_STATE)나 misc 파티션 metadata에 저장됩니다.

1
        OTA write              first boot
2
[ - ] --------------> [installed] -------> [trying]
3
                                              |
4
                       +----------------------+
5
                       |                      |
6
              health OK|              health/boot fail
7
                       v                      v
8
                    [good]                  [bad]
9
                       |                      |
10
                       | new OTA              | new OTA
11
                       v                      v
12
                  [installed]             [installed]

U-Boot의 슬롯 선택 규칙은 단순합니다. good을 우선, 없으면 trying, 둘 다 없으면 bad 중 우선순위가 높은 쪽을 마지막 수단으로 시도합니다. Android slot_metadata의 priority 필드가 이 우선순위를 표현합니다. bad로 마킹된 슬롯은 새 OTA가 다시 installed로 전환할 때까지 부팅 후보에서 빠집니다.

#Shared data partition — A/B 사이에서 살아남는 데이터

부팅 슬롯은 두 벌이지만, 사용자 데이터는 한 벌입니다. 어떤 데이터를 shared로 두고 어떤 것을 슬롯 안에 둘지가 업그레이드 후 데이터 손실과 마이그레이션 비용을 결정합니다.

shared 파티션의 스키마는 OTA가 책임집니다. v1 펌웨어가 만든 SQLite DB를 v2 펌웨어가 읽을 수 있어야 하고, 그 반대(rollback 후 v1이 v2의 DB를 만나는 경우)도 최소한 충돌 없이 무시되어야 합니다. shared 데이터에 버전 필드를 한 칸 두는 것이 가장 흔한 해법입니다.

1
// /var/lib/myapp/state.cbor 헤더
2
struct shared_state_header {
3
    uint32_t magic;       // 'MYAP'
4
    uint16_t version;     // 현재 schema version
5
    uint16_t min_version; // 이 데이터로 동작 가능한 최소 펌웨어
6
    uint8_t  body[];
7
};

min_version보다 낮은 펌웨어로 rollback되었을 때는 데이터를 무시하고 default로 시작하거나, 별도 backup에서 복구합니다.

#Rollback 시나리오 — 6가지 실패 패턴

부팅 실패가 발생하는 방식은 단일하지 않습니다. 각각이 다른 감지 메커니즘과 다른 fallback 트리거를 요구합니다.

(a)는 U-Boot 단독으로 처리합니다. (b)는 systemd의 RuntimeWatchdogSec이 트리거가 됩니다.

1
[Manager]
2
RuntimeWatchdogSec=30s
3
RebootWatchdogSec=10min

(c)는 애플리케이션이 명시적으로 health 실패를 보고합니다.

1
[Unit]
2
Description=Application health check
3
After=critical-app.service
4
Requires=critical-app.service
5

6
[Service]
7
Type=oneshot
8
ExecStart=/usr/bin/myapp --self-test
9
ExecStartPost=/usr/sbin/rauc-mark-good
10
# 실패 시 fw_setenv가 호출되지 않아 다음 부팅에서 bootcount 증가
11

12
[Install]
13
WantedBy=multi-user.target

성공 경로에서 rauc-mark-good이 호출되어 upgrade_available=0·bootcount=0을 set 합니다. 실패하면 ExecStartPost가 실행되지 않으므로 다음 부팅의 bootcount가 그대로 누적됩니다.

(f) boot loop는 짧은 시간 안의 다중 reset을 감지하는 별도의 카운터가 필요합니다. 일부 U-Boot 보드 코드는 bootcount_load() 직후의 timestamp 차이로 “비정상적으로 빠른” 부팅을 식별합니다.

#A/B와 secure boot의 결합

verified boot(Ch 16, Ch 27)을 A/B와 결합할 때 각 슬롯의 이미지가 별도로 서명되어 있어야 합니다. 동일 키로 서명하지만 별도의 서명 블록을 가집니다. 이유는 두 가지입니다.

1. 한 슬롯의 이미지를 부분적으로 업데이트할 때 서명이 깨지면, 다른 슬롯은 영향받지 않아야 합니다.
2. anti-rollback counter(NXP HABv4의 SRK fuse, ARM TF-A의 trusted counter, TPM PCR)가 슬롯별로 다른 값을 가질 수 있어야 합니다.

1
+---------+    +-------------+    +---------------+
2
| ROM     | -> | BL2 (TF-A)  | -> | FIP A or B    |
3
+---------+    +-------------+    +---------------+
4
                      |                  |
5
                verify BL2          verify slot
6
                with ROTPK         with anti-rb v

anti-rollback counter는 전체 디바이스의 단조 증가 값이지만, 슬롯 metadata에 각 슬롯이 요구하는 최소 counter 값을 두면 슬롯별로 검증할 수 있습니다. v3 펌웨어를 A에 설치하고 B는 v2로 남겨두면, B로 fallback할 때 anti-rollback counter는 v2의 최소값만 검증합니다. 단, 한 번 counter가 증가하면 되돌릴 수 없으므로, anti-rollback counter 증가는 새 펌웨어가 충분히 검증된 후에만 commit 합니다.

흔한 패턴은 anti-rollback의 증가를 rauc-mark-good 시점에 두는 것입니다. trying 상태에서는 이전 counter로 계속 동작하고, good 확정 시 counter를 한 단계 올립니다.

#자주 하는 실수

A/B 도입 시 자주 만나는 함정입니다.

• bootcount를 env에 두고, env 자체가 한 슬롯과 같이 망가지면서 카운터를 잃어버린다.
• userspace가 bootcount를 직접 결정한다. “응용이 올라왔으니 성공”이라고 하면, 응용은 올라왔지만 데이터가 부서졌어도 성공 처리됩니다. 별도 health check가 필요합니다.
• rootfs를 공유 파티션에 두고, 한 슬롯이 그것을 망가뜨리면 양 슬롯이 같이 죽는다.
• DTB는 슬롯에, 커널은 공통 파티션에 둔다. 새 커널이 옛 DTB로 부팅을 시도해 random panic을 일으킨다.
• bootlimit을 1로 설정한다. 첫 부팅의 우연한 실패까지 fallback으로 처리해 의도와 다른 슬롯에 갇힌다.
• upgrade_available 플래그를 잊는다. “정상 동작 중인데도 부팅 실패가 일어났을 때” fallback이 동작하지 않거나, “업데이트 시도가 아닌데도” fallback이 동작하는 두 가지 오작동이 모두 가능합니다.
• bootcount가 8-bit·overflow에 노출되어 있다. 일부 백엔드는 단일 바이트만 쓰는데, 256번째 재부팅에서 0으로 wrap 되어 fallback 안전망이 사라집니다. 32-bit 백엔드를 쓰거나 increment 시 saturate를 보장합니다.
• env partition이 redundant가 아닌 단일이다. CONFIG_SYS_REDUNDAND_ENVIRONMENT를 켜지 않으면 env save 도중 전원 끊김으로 전체 env 손실이 가능합니다. 양 슬롯이 한꺼번에 의미를 잃습니다.
• shared 데이터의 schema 버전을 관리하지 않는다. v2 펌웨어가 작성한 DB를 v1으로 rollback했을 때 v1이 파싱 실패로 crash 합니다. min_version 필드와 fallback 정책이 필요합니다.

#정리

• A/B 슬롯은 지금 실행 중인 코드를 덮지 않는 사본 한 벌을 항상 남겨 둡니다.
• U-Boot의 bootcount·bootlimit·altbootcmd가 자동 fallback의 핵심 트리오입니다.
• 부팅 성공의 기준은 시스템마다 다르지만, 그 판단을 userspace가 명시적으로 내려야 합니다.
• env 백엔드는 망가지기 쉬우니 RTC SRAM·EEPROM 같은 독립된 비휘발 영역을 권장합니다.
• 슬롯 토글 권한을 U-Boot에 두고 agent에 두지 않으면 안전망이 더 견고합니다.
• Android의 slot_metadata 세 필드(priority·tries·success)는 자체 구현에도 좋은 기준입니다.
• 가변 사용자 데이터는 슬롯 밖 공유 파티션에 두어야 양 슬롯이 함께 망가지지 않습니다.

#다음 장 예고

다음 장은 부트로더가 EFI가 되는 흐름을 봅니다. bootefi를 통해 U-Boot이 UEFI Boot Services를 노출하고, Linux EFI stub·GRUB·systemd-boot이 그 위에서 부팅됩니다.

#관련 항목

• Ch 13: U-Boot 환경변수 — env partition과 fw_setenv — BOOT_SLOT·bootcount가 사는 곳
• Ch 16: Verified Boot — RSA 서명과 public key 임베딩
• Ch 18: EFI in U-Boot — bootefi와 EFI loader
• Ch 20: RAUC / SWUpdate — 펌웨어 업데이트 프레임워크 — A/B를 위 레이어에서 다루는 도구
• Ch 27: Signed A/B — secure boot과 슬롯별 anti-rollback — 슬롯별 서명·counter 관리
• Ch 28: Flash layout과 파티션 사이즈 산정 — boot/rootfs/shared 영역 크기 결정
• Buildroot Ch 16: OTA 통합 — Buildroot 측 RAUC·SWUpdate 패키징
• 원문 — U-Boot doc/README.bootcount