SWUpdate (Software Update for Embedded Systems) 살펴보기

목차

1. 들어가기
2. 주요특징
3. SWUpdate 기초
4. SWUpdate 업데이트 모드
5. Future Plan (Road Map)
6. 마무리

들어가기

이전 포스팅(링크)에서는 Mender 솔루션에 대해서 살펴봤다. OTA 솔루션에 대한 시작 포스팅은 다음(링크)를 확인하자.

이번 포스팅에서는 SWUpdate에 대해서 살펴보기로 하자. github 홈페이지는 다음과 (링크) 같다.

주요특징

다음과 같은 주요특징을 가지고 있다. 참고로 라이센스는 MIT, GPLv2 그리고 GPLv2+ 이 혼재되어 있다.

• 파티션 레이아웃에 대한 제약사항이 없다. SWUpdate는 순수 flash 이미지, UBI 볼륨, 디스크 파티션 심지어 파일레벨까지 그 대상이될 수 있다.
• 플랫폼 저장에 대한 제약사항 또한 없다. 하나의 파티션에 있을 수도 있고 여러 개의 파티션에 나뉘어 있을 수도 있다. 심지어 스토리지 레벨에서 분산되어 있어도 무방하다. 다음 중 하나의 셋업으로 사용된다.
• rescue : 업데이트 모드로 부팅해서 업데이트가 진행되는 셋업. 하나의 플랫폼만이 시스템에 저장된다.
• dual-copy : 두 벌의 플랫폼이 존재한다. A/B System Updates라고 보면 된다.
• 업데이트 이미지는 아래와 같은 위치에 저장할 수 있다.
• 로컬 : USB 메모리 스틱, SD 카드 등
• 서버 : HTTP(S), FTP - libcurl을 이용해서 다운로드 받는다.
• 웹서버 : moongoose 서버를 지원한다.
• External Back-end connector를 이용해서 외부 서버에 접속가능하다. 현재 Hawkbit 서버가 지원된다.
• 클라이언트 요구사항
• rescue : meta-swupdate를 통해서 8MB 정도의 rescue 이미지를 생성가능하다. 해당 이미지를 통해서 업데이트 모드로 진입할 수 있다.
• dual-copy : active/passive rootfs 파티션이 필요하다.
• 빌트인 recovery mechanism은 없다. 만약 부팅이 실패하면 다시 업데이트 모드로 진입한다.
• rescue 모드에서는 두 번의 재부팅이 필요하다. 그리고 업데이트 중에서는 디바이스를 사용할 수 없다. 반면 dual-copy 모드에서는 런타임시에 업데이트가 진행된다. 다만 한번의 재부팅은 필수다.
• 보안을 위해 다음과 같은 기능이 준비되어 있다
• HTTPS를 통한 위부 서버 접속
• Signed 이미지 지원
• 암호화된 이미지 지원

SWUpdate 기초

SWUpdate는 타겟에서 실행되는 바이너리이다. SWUpdate 프로세스의 역할은 업데이트를 inactive 파티션에 설치하는 것이다. 현재는 U-Boot 기반으로 Beaglebone, RPI3을 지원한다.

Single Image Delivery

SWUpdate는 아래와 같은 하나의 이미지 포맷을 가진다. 참고로 확장자는 swu이다.

CPIO 헤더의 경우, 간단함과 stream이 가능하다는 이유로 헤더로 선택되었다. sw-description은 같이 패키징된 각각의 이미지에 대한 메타 정보를 가지고 있다. 업데이트 이미지의 파서는 sw-description 메터 정보를 바탕으로 필수적으로 업데이트 되어야하는 이미지를 판단하고 적절한 handler를 호출한다. Handler는 UBI, SD card, CFI flash와 관련된 것들이 준비되어 있다. 물론 확장을 통해서 커스텀 핸들러를 만들수도 있다.

아래는 sw-description의 실제 내용이다. SWUpdate는 이를 파싱하기 위해서 libconfig를 따른다.

sw-description의 문법 및 설명은 다음 링크 (링크)를 확인하자.

software =

{

        version = "0.1.0";

        description = "Firmware update for XXXXX Project";

        hardware-compatibility: [ "1.0", "1.2", "1.3"];

        /* partitions tag is used to resize UBI partitions */

        partitions: ( /* UBI Volumes */

                {

                        name = "rootfs";

                        device = "mtd4";

                        size = 104896512; /* in bytes */

                },

                {

                        name = "data";

                        device = "mtd5";

                        size = 50448384; /* in bytes */

                }

        );

        images: (

                {

                        filename = "rootfs.ubifs";

                        volume = "rootfs";

                },

                {

                        filename = "swupdate.ext3.gz.u-boot";

                        volume = "fs_recovery";

                },

                {

                        filename = "sdcard.ext3.gz";

                        device = "/dev/mmcblk0p1";

                        compressed = true;

                },

                {

                        filename = "bootlogo.bmp";

                        volume = "splash";

                },

                {

                        filename = "uImage.bin";

                        volume = "kernel";

                },

                {

                        filename = "fpga.txt";

                        type = "fpga";

                }

        );

        files: (

                {

                        filename = "README";

                        path = "/README";

                        device = "/dev/mmcblk0p1";

                        filesystem = "vfat"

                }

        );

        scripts: (

                {

                        filename = "erase_at_end";

                        type = "lua";

                },

                {

                        filename = "display_info";

                        type = "lua";

                }

        );

        bootenv: (

                {

                        filename = "bootloader-env";

                        type = "bootloader";

                },

                {

                        name = "vram";

                        value = "4M";

                },

                {

                        name = "addfb";

                        value = "setenv bootargs ${bootargs} omapfb.vram=1:2M,2:2M,3:2M omapdss.def_disp=lcd"

                }

        );

}

업데이트 과정

• sw-description을 파싱해서 수행해야할 activity들을 정리한다.
• CPIO 정보를 읽고 각각의 이미지의 checksum을 확인한다.
• sw-description의 H/W 호환성 정보를 읽어 호환성을 검증한다.
• sw-description의 내용과 CPIO 정보를 교차 검증한다.
• 필요하다면 UBI 불륨에 대한 사이즈를 수정한다.
• pre-install 스크립트들을 수행한다.
• 각 이미지를 순회하면서 적절한 핸들러를 호출한다.
• post-install 스크립트들을 수행한다.
• 부트로더 환경변수를 업데이트한다.

Handler

SWUpdate는 Mender 처럼 토털 솔루션을 지향하지 않고 프레임워크를 지향한다. 즉, 목적에 맞게 쉽게 확장이 가능하도록 구현되어 있다. 커스텀되는 부분에 대해서 Handler 라는 용어를 사용한다.

기본적으로 핸들러는 이미지 type과 연동된다. 다음의 handler들이 기본적으로 제공되는 핸들러들이다.

• flash devices in raw mode (both NOR and NAND)
• UBI volumes
• raw devices, such as a SD Card partition
• bootloader (U-Boot, GRUB, EFI Boot Guard) environment
• Lua scripts

위의 기본 핸들러들은 별문제가 없으면 자동으로 호출된다. 하지만 제공되는 핸들러로 처리가 되지 않는 경우에는 커스텀을 수행해야하는데 SWUpdate의 코드를 같이 수정해야 하는 것 같다.

일단 커스텀 Handler를 등록하기 위한 코드는 다음과 가탇.

__attribute__((constructor))

void my_handler_init(void)

{

        register_handler("mytype", my_handler, my_mask, data);

}

이제 mytype에 해당하는 이미지는 아래 my_handler를 호출하게 된다. register에 마지막 인자인 data는 커스텀 핸들러의 data로 전달된다. my_mask는 아래 핸들러의 첫번째 인자에 대한 enum값이다.

int my_handler(struct img_type *img,

        void __attribute__ ((__unused__)) *data)

Streaming feature

SWUpdate는 업데이트 이미지를 별도로 저장하지 않고 바로 인스톨이 가능하다. 각각의 image를 위한 handler는 image의 시작을 가리키는 file descriptor를 인자로 받는다.

SWUpdate 업데이트 모드

1. CLI 업데이트 모드

이 모드에서는 SWUpdate는 아래 명령을 통해서 업데이트를 진행한다. 즉, 로컬로 이미 다운로드가 된 이미지에 대해서만 업데이트가 가능하다.

$ swupdate -i <filename>

2. 로컬 웹서버 업데이트 모드

SWUpdate를 로컬 웹서버로 사용할 수 있다. Mongoose 프로젝트를 사용한다.

$ ./swupdate -l 5 -w '-r ./examples/www/v2 -p 8080' -p 'reboot'

Mongoose 솔루션의 경우 'http://<target_ip>:8080' URL로 접속하면 아래 화면을 볼 수 있다.

즉, 입베디드 웹서버를 통해서 업데이트를 진행할 수 있다. 실제로 업데이트를 진행하면 브라우저를 통해서 진행사항을 모니터링할 수 있다.

3. 데몬모드

데몬모드는 Suricatta라고 불리운다. 다음명령을 확인하자.

$ ./swupdate -l 5 -u '-t default -u http://10.0.0.2:8080 -i 25'

데몬모드에서 SWUpdate는 리모트 서버를 주기적으로 확인하고 다운로드&인스톨을 실시한다. 현재 hawkBit 서버를 리모트서버로 지원한다. 동시에 쉽게 확장가능하도록 인터페이스가 설계되어 있다. 위 명령어에서 hawkBit 서버의 IP는 10.0.0.2:8080 이다.

데몬모드를 위해서 '/etc/systemd/system/swupdate.service' systemd service 파일이 제공된다.

파일의 내용은 아래와 같다.

[Unit]

Description=SWUpdate daemon

Documentation=https://github.com/sbabic/swupdate

Documentation=https://sbabic.github.io/swupdate

[Service]

Type=notify

ExecStart=/usr/bin/swupdate -u '-t default -u http://localhost -i 25'

[Install]

WantedBy=multi-user.target

SWUpdate 데몬과 통신하기 위한 client 라이브러리 또한 제공된다.

아래는 해당 라이브러리 API이다.

int swupdate_async_start(writedata wr_func, getstatus status_func,

        terminated end_func)

typedef int (*writedata)(char **buf, int *size);

typedef int (*getstatus)(ipc_message *msg);

typedef int (*terminated)(RECOVERY_STATUS status);

wr_func 함수는 인스톨할 업데이트 이미지가 다운로드되면 호출된다. terminated 함수는 업데이트가 마무리 되면 호출된다.

Future Plan (Road Map)

현재 계획 중인 기능들을 소개한다. 다만 언제 구현되어 적용될지는 미정.

Gateway

IoT 디바이스 같이 리소스가 부족한 디바이스에 Full OTA를 구현하는 것은 비효율적이다. Security는 기본적으로 computing 파워를 많이 필요로 하고 안정적인 OTA를 위해서는 생각보다 리소스가 많이 든다.

Gateway 기능이란 전체 디바이스들이 직접 서버에 붙어서 OTA를 하는 것이 아니고 Gateway 클라이언트만 서버와 붙어서 업데이트 이미지를 받고 Gateway 클라이언트에서 다른 디바이스로 이미지를 내려주는 방식이다. 'swuforward' 핸들러를 통해서 소개된 기능이다.

Delta update

몇 가지 솔루션이 메일링리스트에서 논의가 되었다고 하는데 아직 계획은 없어보인다.

New handler

UART로 연결된 microcontroller에 대한 Handler, FPGA에 대한 Handler, deb package 핸들러 등이 논의되고 있다고 한다.

마무리

우선 굉장히 확장성이 좋다. 파티션 레이아웃이나 업데이트 이미지 형태, 업데이트 방법 등에 대해서 제약사항이 없다. 반면에 서버 솔루션이 포함되지 않은 것과 빌트인 recovery 방법이 없다는 것은 단점으로 볼 수 있다. 보안에 대해서도 애매한데 서버가 포함되지 않았으므로 사용자가 추가로 고려해야할 부분이 있을 것 같다.