Wiznet makers

Project Overview

Oro Link is a hardware-in-the-loop test platform designed to validate Oro OS kernels and modules on physical computers, development boards, and other systems under test. The repository combines custom PCB designs, embedded firmware, and area-controller software intended to connect CI/CD jobs with real hardware in addition to emulated environments.

The project consists of two principal software components:

• link-firmware: asynchronous no_std firmware running on an STM32F479VG MCU.
• link-aread: a Tokio-based area-controller application intended to discover and coordinate Link devices on a local network. 

Project Type

System Architecture

Oro OS CI/CD / Build Infrastructure
                │
                ▼
      Area Controller: link-aread
      - Local Link discovery
      - Intended device coordination
                │
      External Management Network
                │
                ▼
   exteth: W5500 Ethernet Interface
   - DHCPv4 client
   - QUP TCP service
   - Redis communication path
                │
                ▼
       STM32F479VG Link Firmware
   ┌────────────┼─────────────────────┐
   │            │                     │
   ▼            ▼                     ▼
Power/VBUS   USB and UART         SD Card / OLED
Control      Routing              Status / Storage
   │
   ▼
System Under Test
   ▲
   │
syseth: W5500 Ethernet Interface
- Static IPv4: 10.0.0.1/8
- Private system-side network
- Wake-on-LAN and network services

The firmware initializes two separate embassy-net-wiznet network stacks. The external interface, named exteth, obtains its configuration through DHCPv4. The system-side interface, named syseth, uses the static address 10.0.0.1/8, assigns the same address as its DNS server, and does not configure a default gateway. This structure indicates separation between the management network and the network connected to the system under test.

The PCB source includes dedicated schematics for W5500 Ethernet, microSD, OLED, USB, UART/RS-232, power control, and status indicators. The firmware similarly exposes services for Ethernet devices, USB routing, USART, SD card access, power monitoring, LEDs, OLED output, Wake-on-LAN, and over-current protection.

Software and Control Flow

1. Boot and Self-Test

At startup, the firmware checks whether the previous boot ended in a critical failure. It then performs self-tests and waits until remote configuration has been received. A critical failure is reported through the OLED and status LEDs, and further operation is halted.

2. Network Initialization

Two SPI-connected WIZnet interfaces are initialized:

• exteth: external management Ethernet using DHCPv4.
• syseth: private system Ethernet using 10.0.0.1/8.

Each interface has an independent WIZnet runner and embassy-net stack runner.

3. Controller Communication

The QUP service waits for the external network stack to become available, opens a TCP listener on port 1883, and advertises an _orolink._tcp mDNS service. It then accepts a controller connection and synchronizes firmware variables over the QUP protocol. Port 1883 is used by this project’s QUP service and does not by itself indicate MQTT operation.

A separate Redis service connects to an endpoint provided through the area-controller configuration. It stores Link-specific variables using a link:{unique_id}: key prefix and periodically synchronizes modified state.

4. System-Under-Test Control

After configuration, the firmware can coordinate:

• System power and VBUS delivery
• USB path selection
• UART communication
• Wake-on-LAN
• SD-card access
• OLED and LED status indication
• Current monitoring and over-current shutdown

The repository describes an intended workflow in which builds are delivered from the CI/CD infrastructure to the target system and test results are returned. The complete build-image transfer and result-reporting implementation is not fully confirmed in the currently inspected firmware.

WIZnet Product Usage

WIZnet Product Role

The repository contains a W5500-specific PCB schematic, depends on w5500-ll, and instantiates two embassy-net-wiznet drivers in the embedded firmware. The exact assembled W5500 quantity is not separately documented in a verified bill of materials, but the firmware architecture defines two independent WIZnet Ethernet devices.

TOE Usage

Assessment: TOE socket offload is not used

The W5500 is operated in MACRAW mode. The embassy-net-wiznet driver initializes a WIZnet raw Ethernet socket and exposes Ethernet frames to embassy-net. TCP, UDP, DHCPv4, DNS, mDNS, and related protocol processing are handled in software through embassy-net and smoltcp on the STM32.

Application Services
        │
        ▼
embassy-net TCP/UDP API
        │
        ▼
smoltcp Software Network Stack
        │
        ▼
embassy-net-wiznet Driver
        │
        ▼
W5500 MACRAW Ethernet Frames over SPI

Therefore, this implementation is classified as:

• W5500 hardware TCP/IP socket register control: No
• Arduino Ethernet library: No
• ESP-IDF esp_eth / esp_netif: No
• Framework or driver path: Yes, embassy-net-wiznet
• Hardware TCP/IP offload for application sockets: No
• MACRAW Ethernet frame interface: Yes

The driver internally configures the W5500 socket required for MACRAW operation, but application-level TCP connections do not use the W5500 hardware socket API.

Hybrid Network Assessment

Assessment: Not a Hybrid Network

The system operates two wired Ethernet interfaces, but no Wi-Fi, cellular, or other wireless network implementation was identified in the firmware dependencies or PCB structure. The architecture is therefore a dual-Ethernet or multi-homed wired system, not a wired–wireless Hybrid Network.

External Wired Ethernet + System-Side Wired Ethernet
                         ≠
              Wired + Wireless Hybrid Network

Strengths

1. Real-hardware CI/CD validation
   Kernel and driver changes can be evaluated on physical systems rather than relying entirely on virtual machines or emulators. 
2. Separated Ethernet domains
   Independent management-side and system-side Ethernet stacks reduce coupling between controller communication and target-network testing. 
3. Asynchronous embedded Rust architecture
   Embassy tasks provide concurrency for networking, storage, display, USB, UART, power monitoring, and protection services without a conventional RTOS task model. 
4. Integrated physical control
   Power switching, VBUS current supervision, USB routing, UART, Wake-on-LAN, SD storage, and visual status output are handled within one controller. 
5. Explicit failure handling
   The firmware includes previous-boot failure detection, self-test handling, over-current failsafes, status reporting, and reset behavior for selected communication failures. 

Limitations

• The checked-in link-aread implementation currently focuses on mDNS registration and contains hard-coded development values. Full area-controller orchestration, scheduling, authentication, and job management are not yet evident in the inspected source. 
• Some main workflow sections remain incomplete or represented by placeholder delays, so end-to-end image deployment and automated result collection cannot be fully verified from the current code. 
• The firmware relies on project-specific forks or branches of Embassy networking components and smoltcp, increasing maintenance and upstream-integration requirements. 
• Security mechanisms for QUP, Redis communication, device authentication, and network encryption are not clearly documented in the repository.
• Manufacturing and deployment require a custom PCB and multiple controlled interfaces, making the platform more complex than a software-only CI runner. 
• Repository-level documentation does not provide confirmed performance measurements, long-duration reliability results, or complete test-coverage information.

Application Value

Oro Link provides a practical foundation for remote hardware laboratories and automated regression testing of operating-system kernels, boot flows, hardware drivers, and network stacks. Its separated Ethernet interfaces are particularly useful when the management channel must remain available while the target system’s network behavior is being tested or reconfigured.

The architecture can also be adapted for:

• Automated board bring-up
• Embedded Linux and RTOS regression testing
• Bootloader and firmware deployment validation
• Remote power-cycle and recovery testing
• Network appliance testing
• USB and serial compatibility testing
• Multi-board hardware test farms

Its primary technical value is the integration of network management, target-side connectivity, power control, peripheral routing, and telemetry into a single programmable HIL controller.

Author Information

The Cargo workspace identifies Joshua Lee Junon, GitHub account qix-, as the package author. The repository is maintained under the Oro OS organization and is distributed under the MIT License. Additional contributors are present in the repository history, but their individual project roles are not explicitly defined in the inspected documentation.

Oro Link: Oro OS CI/CD를 위한 듀얼 Ethernet 하드웨어 인 더 루프 제어기

프로젝트 개요

Oro Link는 Oro OS의 커널과 모듈을 실제 컴퓨터, 개발 보드 및 기타 시험 대상 시스템에서 검증하기 위한 하드웨어 인 더 루프 테스트 플랫폼이다. 사용자 정의 PCB, 임베디드 펌웨어, 영역 제어기 소프트웨어를 결합하여 에뮬레이션 환경뿐 아니라 실제 하드웨어에서도 CI/CD 작업을 수행하도록 설계되었다.

소프트웨어는 크게 두 구성으로 나뉜다.

• link-firmware: STM32F479VG에서 실행되는 비동기 no_std Rust 펌웨어
• link-aread: 로컬 네트워크에서 Link 장치를 발견하고 관리하기 위한 Tokio 기반 영역 제어기 애플리케이션 

시스템 구조

Oro OS CI/CD 및 빌드 인프라
                │
                ▼
       영역 제어기: link-aread
       - 로컬 Link 장치 검색
       - 장치 구성 및 관리 예정
                │
         외부 관리 네트워크
                │
                ▼
    exteth: W5500 Ethernet 인터페이스
    - DHCPv4
    - QUP TCP 서비스
    - Redis 통신 경로
                │
                ▼
       STM32F479VG Link 펌웨어
   ┌────────────┼─────────────────────┐
   │            │                     │
   ▼            ▼                     ▼
전원/VBUS     USB·UART             SD Card·OLED
제어          경로 제어             상태·저장
   │
   ▼
시험 대상 시스템
   ▲
   │
syseth: W5500 Ethernet 인터페이스
- 고정 IPv4 주소: 10.0.0.1/8
- 시험 대상 전용 사설 네트워크
- Wake-on-LAN 및 네트워크 서비스

펌웨어는 서로 독립된 두 개의 embassy-net-wiznet 네트워크 스택을 초기화한다. exteth로 명명된 외부 인터페이스는 DHCPv4로 네트워크 설정을 받는다. syseth로 명명된 시스템 측 인터페이스는 10.0.0.1/8을 고정 주소와 DNS 서버 주소로 사용하며 기본 게이트웨이는 설정하지 않는다. 코드 구조상 외부 관리망과 시험 대상 시스템 측 네트워크를 분리한 구성으로 판단된다.

PCB에는 W5500 Ethernet, microSD, OLED, USB, UART/RS-232, 전원 제어, 상태 표시 회로가 포함되어 있다. 펌웨어 역시 Ethernet 장치, USB 경로, USART, SD 카드, 전력 감시, LED, OLED, Wake-on-LAN 및 과전류 보호를 개별 서비스로 구성한다.

소프트웨어 및 동작 흐름

1. 부팅과 자체 점검

펌웨어는 시작 시 이전 부팅이 치명적인 오류로 종료되었는지 검사하고 자체 점검을 수행한다. 이후 원격 구성이 수신될 때까지 대기한다. 치명적 오류가 감지되면 OLED와 상태 LED에 오류를 표시하고 후속 동작을 중단한다.

2. 네트워크 초기화

SPI로 연결된 두 WIZnet Ethernet 경로가 초기화된다.

• exteth: DHCPv4를 사용하는 외부 관리용 Ethernet
• syseth: 10.0.0.1/8을 사용하는 시험 대상 시스템 전용 Ethernet

두 인터페이스는 각각 별도의 WIZnet 드라이버 실행기와 embassy-net 네트워크 스택 실행기를 갖는다.

3. 영역 제어기 통신

QUP 서비스는 외부 네트워크가 구성될 때까지 기다린 후 TCP 포트 1883에서 수신 대기한다. _orolink._tcp mDNS 서비스를 등록하고 영역 제어기의 연결을 받아 펌웨어 변수와 상태를 QUP 프로토콜로 동기화한다. 포트 번호가 1883이지만 현재 구현은 MQTT가 아니라 프로젝트 고유의 QUP 서비스로 구성되어 있다.

Redis 서비스는 영역 제어기 설정을 통해 전달된 endpoint에 연결한다. 각 Link 장치의 값을 link:{unique_id}: 접두사가 붙은 키로 관리하며, 변경된 상태를 주기적으로 동기화한다.

4. 시험 대상 시스템 제어

구성 정보가 수신되면 펌웨어는 다음 기능을 조정할 수 있다.

• 시스템 전원과 VBUS 공급
• USB 연결 경로 선택
• UART 통신
• Wake-on-LAN
• SD 카드 접근
• OLED 및 LED 상태 표시
• 전류 감시와 과전류 차단

README에는 CI/CD에서 생성된 빌드를 실제 시험 대상에 전달하고 결과를 반환하는 흐름이 설명되어 있다. 다만 현재 확인된 펌웨어에는 빌드 이미지 전달과 결과 보고의 전체 구현이 완성된 형태로 명확하게 나타나지 않는다.

WIZnet 제품 사용 여부와 역할

WIZnet Product Role

저장소에는 W5500 전용 PCB 회로도가 포함되어 있으며, 펌웨어는 w5500-ll과 embassy-net-wiznet을 사용해 두 개의 Ethernet 장치를 생성한다. 검증된 BOM에서 실제 조립 수량을 별도로 확인하지는 못했지만, 코드상으로는 두 개의 독립적인 WIZnet Ethernet 경로가 정의되어 있다.

TOE 사용 여부

판단: TOE socket offload를 사용하지 않음

이 프로젝트는 W5500을 MACRAW 모드로 사용한다. embassy-net-wiznet 드라이버가 WIZnet의 raw Ethernet socket을 초기화하고 Ethernet frame을 embassy-net에 전달한다. TCP, UDP, DHCPv4, DNS, mDNS 등의 프로토콜 처리는 STM32에서 실행되는 embassy-net과 smoltcp 소프트웨어 스택이 담당한다.

애플리케이션 서비스
        │
        ▼
embassy-net TCP/UDP API
        │
        ▼
smoltcp 소프트웨어 네트워크 스택
        │
        ▼
embassy-net-wiznet 드라이버
        │
        ▼
SPI 기반 W5500 MACRAW Ethernet frame

구현 방식은 다음과 같이 분류된다.

• W5500 hardware TCP/IP socket 직접 제어: 해당 없음
• Arduino Ethernet library 경유: 해당 없음
• ESP-IDF esp_eth / esp_netif 경유: 해당 없음
• 기타 framework 또는 driver 경유: embassy-net-wiznet
• 애플리케이션 socket의 하드웨어 TCP/IP offload: 사용하지 않음
• MACRAW Ethernet frame 인터페이스: 사용

드라이버 내부에서는 MACRAW 통신에 필요한 W5500 socket register를 설정하지만, 애플리케이션의 TCP 연결은 W5500의 하드웨어 TCP socket API를 사용하지 않는다.

Hybrid Network 여부

판단: Hybrid Network가 아님

펌웨어와 PCB에서 Wi-Fi, Cellular 또는 기타 무선 네트워크 구현은 확인되지 않는다. 두 개의 유선 Ethernet 인터페이스를 동시에 사용하지만, 이는 Dual-Ethernet 또는 유선 Multi-homed 구조이며 유선과 무선을 결합한 Hybrid Network에는 해당하지 않는다.

외부 유선 Ethernet + 시스템 측 유선 Ethernet
                         ≠
                유선 + 무선 Hybrid Network

장점

1. 실제 하드웨어 기반 CI/CD 검증
   가상 머신이나 에뮬레이터만으로 확인하기 어려운 커널과 드라이버 변경 사항을 실제 장치에서 시험할 수 있다. 
2. 관리망과 시험망의 분리
   관리 통신용 exteth와 시험 대상 연결용 syseth를 분리하여 대상 시스템의 네트워크 상태가 변경되더라도 제어 경로를 유지할 수 있는 구조를 제공한다. 
3. 비동기 Rust 임베디드 구조
   Embassy 기반 태스크를 통해 네트워크, 저장장치, 디스플레이, USB, UART, 전력 감시 서비스를 비동기적으로 구성한다. 
4. 물리 인터페이스 통합 제어
   전원, VBUS 전류, USB 경로, UART, Wake-on-LAN, SD 카드와 상태 표시 기능을 하나의 제어기에 통합한다. 
5. 장애 감지와 보호 기능
   이전 부팅 실패 감지, 자체 점검, 과전류 차단, OLED·LED 상태 표시 및 일부 통신 장애에 대한 자동 재시작 동작이 포함된다. 

한계

• 현재 link-aread 코드는 mDNS 서비스 등록을 중심으로 구성되어 있으며 개발용 IP 주소와 hostname이 하드코딩되어 있다. 장치 스케줄링, 작업 관리, 인증 및 전체 영역 제어 기능은 확인된 코드에서 완전하게 구현되어 있지 않다. 
• 메인 제어 흐름 일부에 placeholder 성격의 대기 코드가 남아 있어 이미지 배포와 결과 회수의 전체 자동화 경로를 현재 소스만으로 검증하기 어렵다. 
• Embassy networking과 smoltcp의 프로젝트 전용 fork 또는 branch에 의존하므로 upstream 변경 추적과 장기 유지보수가 필요하다. 
• QUP, Redis, 장치 인증 및 네트워크 암호화에 대한 보안 구조가 저장소 문서에 명확하게 정리되어 있지 않다.
• 사용자 정의 PCB와 여러 물리 인터페이스가 필요하므로 소프트웨어만으로 구성된 CI runner보다 제작과 배포가 복잡하다. 
• 성능 측정, 장시간 안정성 시험 및 전체 테스트 커버리지에 관한 자료는 저장소 내에서 확인되지 않는다.

적용 가치

Oro Link는 운영체제 커널, 부트 과정, 하드웨어 드라이버 및 네트워크 스택을 실제 장치에서 자동 검증하는 원격 하드웨어 시험 환경의 기반으로 활용할 수 있다. 관리용 Ethernet과 시험 대상용 Ethernet이 분리되어 있어 대상 장치의 네트워크를 변경하거나 재초기화하는 동안에도 관리 경로를 별도로 유지할 수 있다.

다음과 같은 분야로 확장할 수 있다.

• 개발 보드 자동 bring-up
• Embedded Linux 및 RTOS 회귀 시험
• Bootloader와 firmware 배포 검증
• 원격 전원 재가동 및 복구 시험
• 네트워크 장비와 gateway 시험
• USB 및 Serial 호환성 시험
• 다수 보드로 구성된 원격 하드웨어 팜

주요 적용 가치는 네트워크 관리, 대상 장치 연결, 전원 제어, peripheral 경로 설정 및 telemetry를 하나의 프로그래밍 가능한 HIL 제어기에 통합한 구조에 있다.

저자 정보

Cargo workspace에는 Joshua Lee Junon, GitHub 계정 **qix-**가 패키지 저자로 명시되어 있다. 저장소는 Oro OS 조직에서 관리되며 MIT License로 배포된다. 저장소 이력에는 추가 기여자가 존재하지만, 개별 기여자의 구체적인 역할은 확인된 문서에 명시되어 있지 않다.