아사히 리눅스 7.1 진행 보고서, M3 지원과 애플 펌웨어 삽질이 같이 왔다

macOS 27 베타가 Asahi 부팅을 깨뜨린 이유

• macOS 27 Golden Gate 개발자 베타를 올린 뒤 Asahi Linux 부트 항목이 사라지는 문제가 보고됨

  • 전원 버튼 길게 눌러 나오는 부트 피커와 Startup Disk 앱에서 Asahi가 안 보이는 증상임
  • 다행히 디스크를 확인해보니 Asahi 관련 파티션은 그대로 있었고, 데이터 유실은 아니었음

• 원인은 APFS 볼륨의 ‘부팅 가능’ 메타데이터 플래그였음

  • Asahi Installer는 애플 부트로더를 쓰기 위해 2.5GB짜리 작은 APFS 컨테이너를 만들고, 그 안에 macOS처럼 보이는 최소 구성과 m1n1을 넣어둠
  • macOS 12부터 macOS 26까지는 애플 부트 도구가 이 플래그를 사실상 무시했는데, macOS 27부터는 이 플래그가 없으면 부트 피커에 안 띄우는 쪽으로 바뀐 것

• 새 Asahi 설치는 앞으로 이 플래그를 자동으로 설정함

  • 이미 macOS 27 베타를 설치해서 Asahi가 안 보이는 사용자는 설치 프로그램을 다시 실행하고 “Fix macOS 27 boot picker compatibility” 옵션을 쓰면 됨
  • 리눅스에서 직접 고치는 프로그램도 개발됐지만, 파일시스템을 망가뜨리지 않는다는 테스트 데이터가 더 필요해서 자동 배포는 아직 조심하는 중임

세 바이트 차이로 긴급 종료까지 간 SMC 변경

• macOS 27은 SMC를 포함한 글로벌 펌웨어도 업데이트함

  • SMC는 배터리 상태, 전압, 방전까지 남은 시간, 배터리 건강도 같은 정보를 제공함
  • Asahi의 리눅스 전원 드라이버는 SMC와 통신해서 충전 시작/중지 임계값도 설정함

• 문제는 배터리 관리 인터페이스 하나가 32비트 정수 반환에서 1바이트 반환으로 바뀐 것임

  • 기존 드라이버는 이 변화를 배터리 고장처럼 해석할 수 있었고, 특정 조건에서 시스템 보호를 위해 긴급 종료를 걸었음
  • Asahi downstream 커널은 이미 패치됐고, 7.0.12부터 전원 드라이버가 두 펌웨어 ABI를 모두 처리함

M3 지원은 꽤 빠르게 앞으로 가는 중

• M3 기기에서 고품질 오디오 출력 지원이 들어옴

  • 애플의 I2S 컨트롤러는 M1 이후 크게 바뀌지 않았고, 오디오 클럭을 다루는 NCO도 그대로였음
  • 스피커와 헤드셋 앰프 칩도 대부분의 애플 실리콘 기기에서 같아서, Devicetree 추가와 asahi-audio, speakersafetyd 설정만으로 많은 부분을 살릴 수 있었음

• M3는 CPU 주파수 전환과 proper big.LITTLE 작업 스케줄링도 지원하게 됨

  • 애플은 기본 M2 이후 CPU 주파수 전환 방식을 바꾸지 않았고, M3, M3 Pro, M3 Max, M3 Ultra도 기존 cpufreq 드라이버에 Devicetree 변경만으로 붙일 수 있었음
  • 작업을 효율 코어와 성능 코어에 더 똑똑하게 배치하고, 부하에 따라 코어 클럭을 올리고 내리므로 전력과 성능 양쪽에 도움이 됨

• M3 시리즈에서 PCIe, WiFi, Bluetooth, NVMe, 키보드, 트랙패드 같은 핵심 블록도 이미 리눅스에서 동작 중임

  • 그래도 Asahi Installer에서 M3 지원을 켤 정도까진 아직 남은 작업이 있음
  • 보고서에 따르면 진행 속도는 빠른 편이고, M4와 A18 Pro 기반 MacBook Neo 지원을 위한 기반 작업도 들어가고 있음

애플 비디오 디코더는 아예 펌웨어를 직접 쓰는 방향으로 감

• Apple Video Decoder(AVD)는 RTKit도 EPIC도 아닌 별도 펌웨어 구조를 쓰는 특이한 블록임

  • 하드웨어는 ARM Cortex-M3가 AVC(H.264), HEVC(H.265), VP9, 최신 SoC의 AV1 같은 고정 기능 디코더를 제어하는 구조임
  • 문제는 애플이 AVD 펌웨어와 설정 데이터를 AVD kext 안에 묶어두고, SoC마다 AVD 변형도 조금씩 다르다는 점임

• Asahi 팀은 애플 펌웨어를 추출해 따라가는 대신 자체 펌웨어를 쓰는 쪽을 택함

  • AVD의 CM3는 로드된 펌웨어를 검증하지 않고 리셋 벡터에서 실행을 시작함
  • 그래서 인터럽트 핸들러를 설치하고 각 변형별 튜닝 값을 적용하는 아주 기본적인 커스텀 펌웨어를 올린 뒤, 실제 디코더 제어는 리눅스 드라이버가 맡는 설계가 가능해짐

• 새 기여자 sofus가 이 빈칸을 메우면서 AVC 하드웨어용 V4L2 드라이버가 동작하는 단계까지 감

  • 현재 10비트 AVC 인코딩 비디오를 최대 4K까지 디코딩할 수 있고, V4L2 Request API를 구현한 소프트웨어와 잘 동작함
  • VP9, HEVC, 일부 SoC의 AV1 지원은 아직 미구현이고, 기기별 quirks도 더 테스트해야 함

m1n1 1.6.0부터 Rust가 더 중요해짐

• m1n1 1.6.0은 배포판 입장에서 꽤 큰 릴리스임

  • stage 2 빌드에 처음으로 Rust가 필수가 됐음
  • 이전엔 chainloading 지원을 켤 때만 Rust를 썼지만, 이제 Apple Device Tree 파싱 코드와 여러 핵심 경로가 Rust로 옮겨졌음

• GPU 초기화를 m1n1로 옮긴 것도 중요한 설계 변화임

  • 애플 하드웨어 초기화 데이터에 들어 있는 부동소수점 값을 커널 드라이버가 직접 다루지 않아도 됨
  • 나중에 리눅스 커널 메일링 리스트에 제출할 GPU 드라이버는 m1n1이 이 초기화를 먼저 해준다는 전제에 의존하게 됨

• m1n1은 사실상 펌웨어처럼 동작하므로 no_std Rust와 aarch64-none-softfloat 타깃을 씀

  • 불필요한 의존성을 피하려면 make에 BUILDSTD=1을 넘겨 core와 alloc을 빌드할 수 있음
  • 1.6.0에는 M3용 SPMI 컨트롤러, PCIe 초기화, DebugUSB 위로 하드웨어 UART를 터널링하는 기능도 들어감

---

기술 맥락

• Asahi Linux의 어려움은 “리눅스 드라이버를 하나 더 만든다” 수준이 아니에요. 애플 부트 도구, APFS 메타데이터, m1n1, Devicetree, 커널 드라이버, 펌웨어 ABI가 한 줄로 이어져 있어서 한쪽이 살짝 바뀌면 전체 부팅 경험이 흔들리거든요.

• macOS 27 부트 피커 문제는 좋은 예예요. 리눅스 파티션 자체는 멀쩡했지만, 애플 부트 도구가 어떤 APFS 볼륨을 부팅 가능하다고 보는 기준이 바뀌면서 사용자 입장에선 OS가 사라진 것처럼 보였어요. 그래서 Asahi Installer가 애플의 기대 형식까지 맞춰줘야 해요.

• SMC 버그도 펌웨어 ABI 의존성이 얼마나 민감한지 보여줘요. 반환값 크기가 32비트에서 1바이트로 바뀐 것만으로 전원 드라이버가 배터리 고장이라고 판단할 수 있었고, 그 결과가 긴급 종료였어요. 저수준 드라이버에선 작은 타입 변경이 사용자 데이터 보호 문제로 바로 이어질 수 있어요.

• AVD 쪽 선택은 더 과감해요. 애플 kext 안의 펌웨어 오프셋을 계속 추적하는 대신, 검증되지 않는 Cortex-M3 펌웨어 경로를 이용해 최소 펌웨어를 직접 올리고 리눅스 드라이버가 디코더를 제어하게 만든 거예요. 유지보수 가능한 업스트림 드라이버를 만들려면 이런 식으로 불안정한 애플 내부 포맷과 거리를 둬야 해요.

• m1n1에 Rust와 GPU 초기화가 들어가는 것도 같은 맥락이에요. 커널 드라이버가 애플 하드웨어 초기화의 복잡함을 전부 떠안기보다, 부트 단계에서 필요한 정리를 해두면 커널 쪽 인터페이스가 단순해져요. 배포판 입장에선 빌드 요구사항이 늘지만, 장기적으로는 드라이버를 업스트림하기 쉬운 구조가 돼요.