MYIR-YA157C 보드 개발 환경 세팅

5 분 소요

배경
1. 어떤 OS 이미지를 쓸 것인가: Ubuntu vs myir-image-full
2. eMMC에 myir-image-full 플래싱
- 2.1 보드 부팅 모드 (딥스위치 B2/B1/B0)
- 2.2 STM32CubeProgrammer로 플래싱
3. WSL2 + MYIR SDK 설치
4. Qt Creator 개발 환경 구성
- 4.1 패키지 설치
- 4.2 가장 많이 겪은 함정: PATH 오염
- 4.3 Kit 두 개 구성
- 4.4 CMake vs qmake
5. 크로스컴파일 & 보드 배포
6. 런타임 트러블슈팅: 화면을 아무도 못 잡는 문제
7. 원격 디버깅 (진행 중, 미해결)
- 방법 A: 수동 gdbserver — 이론상 가능, 안내만 하고 실제 검증은 아직
- 방법 B: Qt Creator Device 연동 (F5로 자동 디버깅) — 현재 막힌 상태
8. 현재까지 상태 요약

MYD-YA157C 보드로 전기차 충전기 개발 환경 구축기

배경

전기차 충전기(터치스크린 HMI 포함, 양산/제품화 목표)를 개발하기 위해 MYIR의 MYD-YA157C(STM32MP157 기반) 보드를 사용하기로 했다. 이 글은 보드 초기 설정부터 Qt 크로스컴파일 개발 환경 구축, 그리고 원격 디버깅 시도까지의 전체 과정을 정리한 기록이다.

1. 어떤 OS 이미지를 쓸 것인가: Ubuntu vs myir-image-full

MYIR은 이 보드용으로 두 가지 완전히 다른 소프트웨어 스택을 제공한다.

구분	Ubuntu (Ubuntu System Dev Guide)	myir-image-full (Linux System Dev Guide)
빌드 방식	ubuntu-base + chroot + apt-get	Yocto/OpenSTLinux (bitbake)
데스크톱	XFCE4, chromium-browser 등 데스크톱 풀세트	Qt5.14 기반 경량 HMI (풀 데스크톱 아님)
계정	myir/123456 (root도 123456)	별도 문서화 안 됨
용도	빠른 프로토타이핑, apt로 라이브러리 자유 설치	양산/제품화, 보안 표면 최소화, HMI 개발 특화

전기차 충전기는 양산/인증을 목표로 하는 제품이고 터치스크린 HMI가 필요했기 때문에, 불필요한 데스크톱 패키지가 많은 Ubuntu보다 Qt5.14 기반 myir-image-full을 최종 선택했다. Yocto 기반이라 이미지 경량화·재현 가능한 빌드가 가능해 인증 심사에도 유리하다.

2. eMMC에 myir-image-full 플래싱

2.1 보드 부팅 모드 (딥스위치 B2/B1/B0)

USB 다운로드 모드: 0, 0, 0
SD카드 부팅: 1, 0, 1
eMMC 부팅 값은 공식 소프트웨어 가이드에 안 나와있어 하드웨어 매뉴얼에서 별도 확인 필요

2.2 STM32CubeProgrammer로 플래싱

USB Type-C(J5, OTG 포트)로 PC와 연결하고 딥스위치를 다운로드 모드(000)로 설정한 뒤 STM32CubeProgrammer GUI로 진행.

겪었던 삽질들:

“Please specify Binaries path” 에러: tsv 레이아웃 파일(Open file)만 지정하고 실제 바이너리가 있는 폴더(Browse)를 별도로 안 잡아줘서 발생. 반드시 두 단계 모두 필요.
sdcard용 tsv와 emmc용 tsv 혼동: eMMC로 구울 땐 FlashLayout_sdcard_*.tsv가 아니라 FlashLayout_emmc_*.tsv를 써야 한다.
ubuntu-rootfs.tar.gz를 바이너리 폴더에 잘못 넣음: STM32CubeProgrammer는 tsv에 명시된 정확한 이름의 .stm32(tf-a, u-boot), .ext4(rootfs 등) 바이너리만 인식한다. tar.gz는 아예 쓸 수 없는 형식.
다운로드가 0%에서 멈춤: USB 케이블(데이터 지원 여부), Windows 드라이버(DFU 모드 인식), USB 전원 관리(선택적 절전) 확인으로 해결.

3. WSL2 + MYIR SDK 설치

Windows에서 Qt 앱 개발을 하려면 크로스컴파일 툴체인이 필요한데, MYIR이 제공하는 SDK(SDK-qt.tar.xz)는 Linux 전용 self-extracting 셸 스크립트라 순수 Windows에서는 설치 불가. 공식 문서에도 Yocto 빌드 호스트로 “Linux, VM, 또는 WSL2”를 명시하고 있어 WSL2를 선택.

# Windows PowerShell (관리자)
wsl --install -d Ubuntu-20.04

WSL2 안에서 SDK 설치:

mkdir -p ~/work && cd ~/work
tar -Jxvf sdk-qt.tar.xz
chmod +x meta-toolchain-qt5-openstlinux-eglfs-myir-x86_64-toolchain-3.1-snapshot.sh
./meta-toolchain-qt5-openstlinux-eglfs-myir-x86_64-toolchain-3.1-snapshot.sh
# 기본 경로 /opt/st/myir/3.1-snapshot 로 설치

테스트:

source /opt/st/myir/3.1-snapshot/environment-setup-cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi
$CC --version   # arm-ostl-linux-gnueabi-gcc (GCC) 9.3.0 확인

참고: 실제로는 Ubuntu 24.04에서 진행하게 됐는데, SDK 자체는 자기 완결적(self-contained) 툴체인이라 호스트 버전과 무관하게 잘 동작했다. 다만 이 SDK는 Yocto Dunfell(3.1) 계열이라, 나중에 bitbake로 전체 이미지를 다시 빌드해야 하는 상황이 오면 24.04는 Python/glibc가 너무 최신이라 실패할 가능성이 높다 — 그때는 Ubuntu 20.04를 별도로 준비해야 한다.

4. Qt Creator 개발 환경 구성

4.1 패키지 설치

sudo apt update
sudo apt install -y build-essential cmake ninja-build gdb \
    qtbase5-dev qt5-qmake qtchooser qtcreator

4.2 가장 많이 겪은 함정: PATH 오염

source environment-setup-...를 실행한 터미널에서 그대로 Qt Creator를 띄우면, Desktop Kit까지 ARM용 SDK의 qmake/cmake를 잘못 인식해서 기본 데스크탑 빌드조차 실패하는 문제가 반복적으로 발생했다.

증상: qmake --version, cmake --version이 /opt/st/myir/... 경로를 가리킴 (정상은 /usr/lib/qt5/bin/qmake, /usr/bin/cmake)
해결: Qt Creator는 반드시 아무것도 source하지 않은 새 터미널에서 실행하고, ARM Kit은 Kit 설정 안에서 절대경로로 직접 등록해서 터미널 환경에 의존하지 않게 구성

4.3 Kit 두 개 구성

Desktop Kit — 시스템 Qt(5.15.13) 자동 인식, 로컬 테스트용

MYD-YA157C ARM Kit — 수동 등록:

항목	경로
C 컴파일러	`/opt/st/myir/3.1-snapshot/sysroots/x86_64-ostl_sdk-linux/usr/bin/arm-ostl-linux-gnueabi/arm-ostl-linux-gnueabi-gcc`
C++ 컴파일러	위와 동일 폴더의 `arm-ostl-linux-gnueabi-g++`
Qt version(qmake)	`/opt/st/myir/3.1-snapshot/sysroots/x86_64-ostl_sdk-linux/usr/bin/qmake`
Debugger	`/opt/st/myir/.../arm-ostl-linux-gnueabi-gdb`
Sysroot	`/opt/st/myir/3.1-snapshot/sysroots/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi`

4.4 CMake vs qmake

새 프로젝트를 CMake로 만들었더니 빌드 시 아래 에러 발생:

No CMake configuration for build type "Debug" found.

원인은 Qt Creator가 CMake에 -DCMAKE_C_COMPILER_TARGET / -DCMAKE_CXX_COMPILER_TARGET 옵션을 자동으로 넘기는데, 이건 Clang용 --target= 플래그라서 순수 GCC 크로스컴파일러(arm-ostl-linux-gnueabi-gcc)와 충돌해 컴파일러 sanity check 단계에서 실패하는 것으로 추정.

이 SDK는 애초에 qmake 기준으로 설계되어 있어서(문서에도 cmake 언급 없음), 새 프로젝트를 만들 때 Build System을 qmake로 선택하는 것으로 우회 — 이후 정상적으로 빌드 성공.

5. 크로스컴파일 & 보드 배포

빌드 성공 후 ARM 바이너리 확인:

file build-*/프로젝트이름
# ELF 32-bit LSB ... ARM 이면 정상

보드로 배포 (SSH 호스트키 이슈 발생):

Unable to negotiate with <IP> port 22: no matching host key type found. Their offer: ssh-rsa

최신 OpenSSH가 보안상 legacy ssh-rsa 호스트키를 기본 차단해서 생기는 문제. 해결:

# ~/.ssh/config
Host <보드IP>
    HostKeyAlgorithms +ssh-rsa
    PubkeyAcceptedAlgorithms +ssh-rsa
    User root

이후 정상 배포:

scp 프로젝트실행파일 root@<보드IP>:/home/root/
ssh root@<보드IP>
./프로젝트실행파일

6. 런타임 트러블슈팅: 화면을 아무도 못 잡는 문제

앱 실행 시 계속 이 에러가 발생:

Attribute Qt::AA_ShareOpenGLContexts must be set before QCoreApplication is created.
Failed to commit atomic request (code=-13)

-13은 리눅스 errno EACCES — 다른 프로세스가 이미 디스플레이(DRM)를 독점하고 있다는 뜻. 범인을 하나씩 제거해나갔다:

weston(Wayland 컴포지터)이 떠있었음 → kill로 제거했지만 재부팅하면 다시 뜸 → systemctl disable weston 필요
tty1의 agetty(콘솔 로그인 화면)가 프레임버퍼를 잡고 있었음 → systemctl stop getty@tty1
최종 범인: /home/mxapp2 — MYIR이 기본 탑재한 MEasy HMI2.0 데모 앱이 myir.service를 통해 부팅 시 자동 실행되며 EGLFS로 화면을 독점하고 있었음

ps aux | grep mxapp2
# root 999 ... /home/mxapp2 -platform eglfs

systemctl stop myir.service
systemctl disable myir.service

이후 정상적으로 자체 앱이 화면을 잡고 실행되는 것을 확인.

foreground로 뜬 GUI 앱을 종료하는 법도 정리:

SSH 세션 하나 더 열어서 kill -9 <PID>
세션이 하나뿐이면 Ctrl+C → 안 되면 Ctrl+Z로 일시정지 후 kill -9 %1

7. 원격 디버깅 (진행 중, 미해결)

방법 A: 수동 gdbserver — 이론상 가능, 안내만 하고 실제 검증은 아직

# 보드
gdbserver :2345 ./앱이름

# WSL2
source /opt/st/myir/3.1-snapshot/environment-setup-cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi
arm-ostl-linux-gnueabi-gdb ./빌드경로/앱이름
(gdb) target remote <보드IP>:2345
(gdb) break main
(gdb) continue

방법 B: Qt Creator Device 연동 (F5로 자동 디버깅) — 현재 막힌 상태

Preferences → Devices에 Generic Linux Device로 보드를 등록하고 Connectivity Test를 시도했으나 계속 실패.

디버깅 과정:

수동 ssh는 되는데 Qt Creator Device Test만 실패 → ssh-rsa 이슈로 의심했으나 ~/.ssh/config 수정 후에도 재현
로그 확인 결과: Failed to install shell script: Timeout while waiting for shell script installation + Wayland 관련 에러(Failed to create wl_display)가 반복 출력되는 것을 확인
원인 추적: myir.service(mxapp2 자동실행)가 우리가 강제 종료한 뒤 failed 상태로 남아 Wayland를 계속 찾다가 에러를 반복 출력 → 이게 SSH 세션 출력에 계속 쌓이며 스크립트 설치를 방해하는 것으로 추정
systemctl disable myir.service로 정리 시도 중 — 아직 재테스트 결과 미확인

현재 결론: 방법 A(수동 gdbserver)는 실용적인 대안으로 확보해뒀고, 방법 B는 SSH 라이브러리 + 잔여 서비스 문제가 겹쳐서 계속 디버깅 중.

8. 현재까지 상태 요약

보드 이미지 선정 (myir-image-full)
eMMC 플래싱
WSL2 + MYIR SDK 설치
Qt Creator Desktop/ARM Kit 구성
크로스컴파일 빌드 성공
보드 배포 및 실행 성공
화면 점유 문제(weston/mxapp2) 해결
Qt Creator 원격 디버깅(F5) 연동 — 진행 중
충전기 제어 로직/HMI 앱 본격 개발 — 다음 단계

이 글은 MYD-YA157C 보드 기반 전기차 충전기 개발 환경을 처음부터 구축하며 겪은 시행착오를 기록한 것입니다. 비슷한 STM32MP1 계열 보드로 Qt 임베디드 개발을 시작하는 분들께 참고가 되길 바랍니다.

Twitter Facebook LinkedIn

이 정훈