임베디드 펌웨어 업데이트 — RAUC vs SWUpdate 비교

A/B 슬롯·서명·다운로드·진행 보고·롤백 정책을 직접 짜기 시작하면, 비슷한 코드를 여러 프로젝트에서 다시 짜는 자신을 발견합니다. RAUC와 SWUpdate는 그 반복되는 뼈대를 미리 마련해 둔 오픈소스 프레임워크입니다. 둘 다 U-Boot의 A/B 슬롯과 정확히 맞물려 동작합니다.

#한 줄 요약

RAUC는 bundle이라는 서명된 업데이트 단위로 슬롯을 갈아 끼우고, SWUpdate는 sw-description이라는 YAML/Lua 스크립트로 더 유연한 업데이트를 지원합니다. 둘 다 U-Boot의 env로 슬롯을 표시합니다.

#왜 프레임워크인가

직접 짜면 다음을 모두 다뤄야 합니다.

• 다운로드 (HTTP/HTTPS/MQTT/USB)
• 무결성 검증 (체크섬·서명)
• 슬롯 선택과 토글
• 진행 상태 표시·로그
• 실패 시 롤백
• 부분 업데이트 (rootfs만, bootloader만, etc.)
• 동시성 (다운로드 중에도 정상 서비스)

매번 다시 만들면 버그가 매번 새로 들어옵니다. 프레임워크는 이 흐름을 검증된 형태로 묶어 둡니다. RAUC와 SWUpdate가 가장 널리 쓰입니다.

#RAUC와 SWUpdate의 철학 차이

성격을 한 줄로 추리면, RAUC는 기본을 안전하게 깔아 두는 도구이고, SWUpdate는 복잡한 시나리오까지 유연하게 짤 수 있는 도구입니다. 표준 A/B만 필요하면 RAUC가 빠르고, 부분 업데이트·복잡한 시퀀스·자체 hook이 많으면 SWUpdate 쪽이 자유롭습니다.

#RAUC — system.conf

장치 측에서 RAUC가 어떤 슬롯·어떤 키로 동작할지 적는 파일입니다.

1
[system]
2
compatible=boardX-v1
3
bootloader=uboot
4
mountprefix=/run/rauc
5

6
[keyring]
7
path=/etc/rauc/keyring.pem
8

9
[handlers]
10
post-install=/usr/lib/rauc/post-install.sh
11

12
[slot.rootfs.0]
13
device=/dev/mmcblk0p2
14
type=ext4
15
bootname=A
16

17
[slot.rootfs.1]
18
device=/dev/mmcblk0p3
19
type=ext4
20
bootname=B
21

22
[slot.kernel.0]
23
device=/dev/mmcblk0p4
24
type=raw
25
parent=rootfs.0
26

27
[slot.kernel.1]
28
device=/dev/mmcblk0p5
29
type=raw
30
parent=rootfs.1

bootname=A·bootname=B가 U-Boot env의 BOOT_SLOT 값과 매핑됩니다. RAUC는 부팅 성공이 확정되면 이 값을 자동으로 토글합니다.

#RAUC bundle 만들기

bundle은 서명된 SquashFS입니다. manifest.raucm과 이미지를 묶어 빌드 호스트에서 만듭니다.

1
[update]
2
compatible=boardX-v1
3
version=2026.05.0
4

5
[bundle]
6
format=verity
7

8
[image.rootfs]
9
filename=rootfs.ext4
10
sha256=...
11

12
[image.kernel]
13
filename=boot.itb
14
sha256=...

1
rauc --cert=cert.pem --key=key.pem \
2
     bundle ./bundle-content/ \
3
     boardX-v2026.05.0.raucb

.raucb 한 파일이 결과물입니다. CMS 서명이 박혀 있고, compatible이 안 맞으면 RAUC가 거부합니다. 다른 보드의 bundle을 실수로 받아 끼우는 사고가 그래서 잘 안 일어납니다.

#RAUC 설치 흐름

장치 측에서 한 줄입니다.

1
# 다운로드한 bundle 설치
2
rauc install /tmp/boardX-v2026.05.0.raucb

RAUC가 내부에서 다음을 합니다.

1. bundle 서명 확인 (keyring.pem의 인증서로).
2. compatible·version 검사.
3. 비활성 슬롯 결정 (현재 A면 B).
4. 비활성 슬롯에 이미지 기록.
5. fw_setenv로 BOOT_SLOT=B, bootcount=0, upgrade_available=1 설정.
6. (옵션) post-install handler 실행.
7. exit.

그다음 reboot은 사용자(또는 update agent)가 합니다. 자동 reboot이 항상 좋은 동작이 아니라 그렇게 분리한 설계입니다.

부팅 성공 표시는 rauc status mark-good이 담당합니다.

1
# systemd unit (부팅 성공 확정 시 실행)
2
ExecStart=/usr/bin/rauc status mark-good booted

이 명령이 호출되면 RAUC가 fw_setenv bootcount=0·upgrade_available=0을 박아 다음 부팅에서 fallback이 발동하지 않게 합니다.

#SWUpdate — sw-description

SWUpdate의 같은 시나리오는 bundle 안에 sw-description 파일이 들어 있는 형태입니다.

1
software =
2
{
3
    version = "2026.05.0";
4
    description = "boardX rootfs + kernel update";
5

6
    boardX = {
7
        stable = {
8
            copy-1 = {
9
                images: (
10
                    {
11
                        filename = "rootfs.ext4";
12
                        device = "/dev/mmcblk0p3";
13
                        type = "raw";
14
                        sha256 = "...";
15
                    },
16
                    {
17
                        filename = "boot.itb";
18
                        device = "/dev/mmcblk0p5";
19
                        type = "raw";
20
                        sha256 = "...";
21
                    }
22
                );
23

24
                bootenv: (
25
                    {
26
                        name = "BOOT_SLOT";
27
                        value = "B";
28
                    },
29
                    {
30
                        name = "bootcount";
31
                        value = "0";
32
                    },
33
                    {
34
                        name = "upgrade_available";
35
                        value = "1";
36
                    }
37
                );
38
            };
39
        };
40
    };
41
};

copy-1이 비활성 슬롯 한 벌입니다. copy-2까지 정의해 두면 SWUpdate가 어느 슬롯이 비활성인지에 따라 알아서 선택합니다.

bundle은 cpio로 묶습니다.

1
ls files/
2
sw-description rootfs.ext4 boot.itb
3

4
cd files
5
for f in sw-description rootfs.ext4 boot.itb; do
6
    echo $f
7
done | cpio -ov -H crc > ../boardX-v2026.05.0.swu

서명은 별도 sw-description.sig를 함께 cpio에 넣어 처리합니다.

#SWUpdate 설치 흐름

swupdate 데몬이 늘 떠 있고, 웹 UI·MQTT·USB·HTTP 등 다양한 소스에서 .swu를 받습니다.

1
# /etc/swupdate.cfg (요지)
2
globals: {
3
    verbose = true;
4
    loglevel = 5;
5
    public-key-file = "/etc/swupdate/key.pub";
6
};
7

8
webserver: {
9
    document_root = "/usr/share/swupdate/www";
10
    port = 8080;
11
};
12

13
suricatta: {
14
    tenant = "default";
15
    id = "boardX-0001";
16
    url = "https://hawkbit.example.com";
17
};

1
# CLI로 직접 설치
2
swupdate -i /tmp/boardX-v2026.05.0.swu

웹 UI나 hawkBit 콘솔에서 push해도 같은 결과입니다. SWUpdate는 설치 후 Lua hook으로 추가 동작을 끼워 넣을 수 있어 “설치 직후 디바이스 ID 등록”·“수동 reboot 대신 5분 카운트다운” 같은 시나리오가 자연스럽습니다.

#U-Boot 측 설정

두 프레임워크 모두 U-Boot 측 부담은 거의 같습니다.

1
# defconfig
2
CONFIG_BOOTCOUNT_LIMIT=y
3
CONFIG_BOOTCOUNT_ENV=y
4
CONFIG_CMD_SAVEENV=y
5
CONFIG_ENV_IS_IN_MMC=y
6

7
# boot script
8
setenv altbootcmd 'run switch_slot; run boot_active'
9
setenv bootcmd 'run boot_active'
10
setenv boot_active '
11
    if test "${BOOT_SLOT}" = "A"; then
12
        load mmc 0:1 ${kernel_addr_r} boot.itb;
13
    else
14
        load mmc 0:2 ${kernel_addr_r} boot.itb;
15
    fi;
16
    bootm ${kernel_addr_r}'
17
setenv switch_slot '
18
    if test "${BOOT_SLOT}" = "A"; then
19
        setenv BOOT_SLOT B;
20
    else
21
        setenv BOOT_SLOT A;
22
    fi;
23
    setenv bootcount 0;
24
    saveenv'
25
saveenv

이 부분이 Ch 17의 A/B 셋업과 거의 같습니다. RAUC·SWUpdate는 그 위에서 동작합니다.

#어느 도구를 고르나

선택 기준을 정리하면 이렇습니다.

둘 중 무엇이든, 직접 짜는 것보다는 거의 항상 안전합니다.

#자주 하는 실수

OTA 운영에서 자주 만나는 함정입니다.

• mark-good을 너무 빨리 호출한다. 부팅 직후 systemd unit으로 mark-good을 박으면 문제가 5분 뒤 드러나는 경우 fallback이 동작하지 않습니다. 핵심 서비스가 안정될 때까지 지연시키는 편이 안전합니다.
• compatible 필드를 보드 모델로만 정한다. SoC revision이 바뀌었는데 같은 compatible로 잡혀 잘못된 bundle이 설치됩니다. revision까지 포함시키는 편이 안전합니다.
• 서명 검증 키를 squashfs 안에 같이 둔다. 키를 자기 검증에 쓰는 셈이라 chain이 의미가 없습니다. 키는 불변 영역 또는 읽기 전용 rootfs에 박혀 있어야 합니다.
• fw_setenv가 atomic이라고 가정한다. 실제로는 env 한 사본을 통째로 다시 쓰는 동작이라, 두 사본을 두는 redundant env 설정을 권합니다.
• bundle을 그대로 슬롯에 dd한다. rauc·swupdate가 각 image 별로 별도 슬롯에 풉니다. bundle 자체는 슬롯에 들어가지 않습니다.
• post-install handler에서 reboot한다. RAUC가 비활성 슬롯에 마운트한 상태에서 reboot이 일어나면 sync가 덜 된 상태로 끝납니다. reboot은 RAUC 종료 이후 별도 명령으로.

#정리

• RAUC는 bundle 단위, SWUpdate는 image 단위로 업데이트를 다룹니다.
• 둘 다 비활성 슬롯에 기록하고 U-Boot env를 토글해 다음 부팅에서 새 슬롯을 시도합니다.
• 부팅 성공 표시는 mark-good(RAUC) 또는 후속 스크립트(SWUpdate)가 담당합니다.
• compatible·version 검사가 잘못된 bundle 끼우는 사고를 막아 줍니다.
• RAUC는 빠른 표준, SWUpdate는 유연한 hook과 웹 UI가 강점입니다.
• U-Boot 측은 Ch 17의 A/B 셋업과 거의 같고, 프레임워크는 그 위에서 동작합니다.
• mark-good 호출 시점이 실제 fallback 안전망의 두께를 결정합니다.

#다음 장 예고

이제까지 부트로더의 기능을 봤다면, 다음 두 장은 실전 작업입니다. 새 보드를 U-Boot에 어떻게 포팅하는지(Ch 21), 그리고 부트로더 자체가 문제 일으킬 때 어떻게 디버깅하는지(Ch 22)를 봅니다.

#관련 항목

• Ch 17: A/B 업데이트와 boot 이중화
• Ch 21: 새 보드 포팅 — defconfig부터 첫 부팅까지
• 원문 — RAUC documentation
• 원문 — SWUpdate documentation