라즈베리파이 Zero 2 W가 품절이다 — Luckfox Lyra Zero W로 갈아타 보기

발단 — 라즈베리파이가 없다

우리가 만드는 저가형 산업용 컨트롤러 ZPi Controller의 심장은 라즈베리파이 Zero 2 W다. 정가 15달러, 국내에서 3만원 언저리에 WiFi·블루투스· 쿼드코어를 다 주는, 소형 자동화에 딱 맞는 보드였다. 였다, 과거형인 이유는 간단하다.

품절이다. 그것도 한두 군데가 아니라 전방위로. 하나 재고 뜨면 금방 사라지고, 가격은 정가의 두세 배로 붙는다. 제품을 만들어 파는 입장에서 “심장 부품을 구할 수 없다”는 건 그냥 못 판다는 뜻이다.

그래서 대체품을 찾기 시작했다. 조건은 명확했다.

• 비슷한 크기·가격 — Zero 2 W 폼팩터를 크게 벗어나지 않을 것
• WiFi 내장 — 무선으로 붙는 게 ZPi의 전제라 필수
• 리눅스 + .NET — 우리 소프트웨어 스택이 여기서 돈다
• 구할 수 있을 것 — 이게 사실 제일 중요했다

그러다 만난 게 Luckfox Lyra Zero W다.

후보 — Luckfox Lyra Zero W는 뭔가

Rockchip RK3506B SoC를 얹은 소형 SBC다. 이름부터 대놓고 “Zero W”라 라즈베리파이 Zero를 겨냥한 물건이다. 스펙을 나란히 놓으면 이렇다.

RAM은 같고, 무선은 오히려 최신(WiFi6). 결정적으로 눈에 들어온 건 맨 아래 두 줄이었다. CAN이 SoC에 내장돼 있다. 산업용 컨트롤러를 만드는 입장에선 이게 은근히 큰 차이다. Pi로는 CAN을 쓰려면 외부 칩을 SPI에 달아야 했는데, 이 녀석은 그냥 있다.

다만 공짜 점심은 없다. 32비트 전용이고 HDMI가 없다. 이 두 개가 나중에 발목을 잡는지 아닌지가 이 글의 절반이다.

옮기기 1 — 이미지 굽는 법부터 다르다

Pi를 쓰던 사람이 제일 먼저 당황하는 지점이다. Raspberry Pi Imager로 안 된다. balenaEtcher로도 안 된다.

라즈베리파이는 SD 카드에 이미지를 통째로(raw) 굽는 방식이라 어떤 도구든 쓸 수 있다. 그런데 Rockchip 계열은 부트로더·파티션테이블·루트파일시스템이 한 덩어리로 묶인 전용 이미지(update.img)를 쓴다. 이걸 raw로 그냥 쓰면 부트롬이 인식을 못 한다.

정답은 Rockchip 전용 도구다. microSD에 구울 때는 SDDiskTool, 온보드 NAND에 넣을 때는 RKDevTool. 이미지도 “SD용”과 “Flash용”이 따로 있어서 바꿔 쓰면 안 된다. 이거 하나 알기까지 반나절 날렸다. Pi에서 넘어온다면 이 대목만 기억하면 된다 — 굽는 도구가 완전히 다르다.

옮기기 2 — 32비트라서, HDMI가 없어서

이미지를 넣고 부팅하니 리눅스는 잘 떴다. 그런데 우리 소프트웨어를 올리려니 두 가지가 걸렸다.

첫째, 32비트. .NET은 문제없이 돌지만 linux-arm64가 아니라 linux-arm으로 빌드해야 한다. Pi(64비트)에서 쓰던 빌드가 그대로 안 올라간다. 다행히 타깃만 바꾸면 되는 일이라 크진 않았다. 실행 시작 1초, 메모리 25MB 수준으로 잘 돌았다.

둘째, HDMI가 없다. 화면을 붙이려면 DSI 패널을 써야 한다. 여기서 한 번 크게 헤맸다. 기본 설정이 특정 해상도 패널로 잡혀 있어서, 우리가 붙인 800×480 패널에는 아무것도 안 나왔다. 신호가 안 맞으면 백라이트만 켜지고 화면은 까맣다. 리눅스가 지원하는 패널 프로파일을 바꿔주고 나서야 화면이 들어왔다. HDMI 모니터 꽂으면 바로 나오는 Pi에 익숙하다면, 여기서도 한 번 멈칫하게 된다.

화면이 뜨고 나서는 오히려 재미있었다. GPU 없이 프레임버퍼에 직접 그리는 방식으로 상태 대시보드(네트워크·CPU·로그)를 띄웠는데, 2초 갱신 정도의 산업용 상태화면에는 충분했다.

위 화면이 실제로 이 보드의 DSI 패널에 나오고 있는 대시보드다. 별도 모니터도, 데스크톱 환경도 없이 프레임버퍼에 바로 그린 것이라 부팅하자마자 켜진다.

옮기기 3 — WiFi가 애를 먹인다

무선이 필수 조건이었는데, 이게 은근히 속을 썩였다. 연결은 되는데 몇 분 지나면 통신이 죽는 현상이 있었다. 원인은 WiFi 칩의 절전 모드였고, 절전을 끄는 옵션으로 잡았다.

그리고 하나 더 — 기본이 외장 안테나였는데, 외장 안테나가 불량이라 신호가 약했다. 온보드 칩 안테나로 바꾸니 신호가 확 좋아졌다(−58dBm → −32dBm). 소형 보드는 안테나 선택이 생각보다 성능을 크게 가른다.

여기서 교훈 하나. 리눅스에서 ping이 안 된다고 통신이 안 되는 게 아니다. 우리 공유기는 ICMP(핑) 응답을 막아둬서, 핑은 실패해도 실제 TCP 통신은 멀쩡했다. 한동안 이걸 통신 장애로 오해하고 엉뚱한 데를 팠다. 핑 말고 실제 포트로 확인하자.

없는 건 직접 만들었다 — 커널 재빌드

여기가 이 프로젝트의 하이라이트다. ZPi 급으로 쓰려면 유선 이더넷과 추가 CAN을 표준 리눅스 인터페이스(eth0, SocketCAN)로 붙이고 싶었다. 캐리어 보드에는 이더넷 칩(W5500)과 CAN 컨트롤러(MCP2515)가 SPI로 달려 있는데, 기본 커널에는 이 드라이버가 빠져 있었다.

방법은 두 가지. 하나는 실행 중에 장치트리 조각을 끼워 넣는 것, 다른 하나는 아예 커널을 다시 빌드하는 것. 전자를 먼저 시도했는데 드라이버가 계속 인터럽트를 못 잡았다. 원인을 파고드니 실행 중 오버레이 방식이 참조 번호를 재배치하면서 인터럽트 연결이 어긋나는 문제였다. 정공법은 커널 소스에 직접 넣고 다시 빌드하는 것이었다.

SDK를 받아 커널 설정에 이더넷·CAN 드라이버를 켜고, 장치트리에 두 칩을 정확한 핀으로 기술한 뒤 다시 빌드했다. 결과는 깔끔했다.

• eth0 — 유선 이더넷이 표준 리눅스 인터페이스로 올라옴
• can0 — 추가 CAN이 SocketCAN으로 동작
• 여기에 SoC 내장 CAN까지 더하면 CAN 채널이 넉넉하다

Pi에서는 CAN 하나 붙이기도 번거로웠는데, 이쪽은 오히려 CAN이 남아도는 상황이 됐다. 산업 현장에서 이건 분명한 장점이다.

마무리 — 실제 제어까지 돌려봤다

세팅만 하고 끝내면 반쪽이다. 우리 산업용 PLC 소프트웨어(Senbrix)를 올리고, CAN 확장보드를 실제로 붙였다. 아날로그 입력 보드와 디지털 IO 보드 두 대를 CAN 버스에 물리고, 마지막에 릴레이가 딸깍 하고 떨어지는 것까지 확인했다.

여기서도 소소한 삽질이 있었다. 확장보드 한 대가 안 붙길래 통신을 들여다보니, 그 보드에 펌웨어를 다른 종류로 잘못 구워 놨더라. 맞는 펌웨어로 다시 넣으니 바로 붙었다. 하드웨어 문제가 아니라 사람 실수였다는, 늘 있는 그런 이야기다.

어쨌든 결과는 이렇다. HMI 화면 → PLC 로직 → CAN 확장보드 → 릴레이로 이어지는 제어 체인이 라즈베리파이가 아니라 Luckfox Lyra Zero W 위에서 끝까지 돌았다.

그래서, 대체 가능한가?

헤드리스 산업용 컨트롤러라면 — 충분히, 오히려 낫다.

• CAN이 내장이라 산업 통신에 유리하다
• 커널을 만질 수 있으니 유선랜·CAN을 표준 인터페이스로 붙일 수 있다
• WiFi6에 온보드 안테나까지, 무선도 준수하다
• 구할 수 있다 (이게 제일 크다)

단, 이런 경우엔 주의:

• HDMI 모니터를 꽂아 쓰던 용도라면 DSI 패널로 넘어가야 한다. 꽂으면 나오는 편의는 없다.
• 64비트 소프트웨어를 쓰던 프로젝트라면 32비트로 다시 빌드해야 한다.
• 굽고 세팅하는 방법이 Pi와 다르다. Rockchip 생태계를 처음 만진다면 러닝커브가 있다.

정리하면, “라즈베리파이를 그대로 꽂아 쓰던 사람”에게는 낯선 구석이 많다. 하지만 CAN·유선랜을 붙여 제대로 된 산업용 컨트롤러로 쓰려는 사람에게는, 품절된 Pi를 기다리는 것보다 이쪽이 더 나은 선택일 수 있다. 우리는 ZPi의 다음 세대를 이 위에서 준비해 보기로 했다.