Asahi Linux 7.1 진행 보고서

2 hours ago 2

Linux 7.1 기준 Asahi Linux는 M3 지원 확대, macOS 27 베타 호환성, AVD 비디오 디코딩, m1n1 1.6.0 변화가 동시에 진행 중임
macOS 27 Golden Gate 개발자 베타에서는 Asahi 부팅 항목이 Startup Disk와 부트 피커에서 사라졌지만, 파티션과 데이터는 남아 있었고 APFS 부팅 플래그 설정으로 복구 가능함
SMC 펌웨어 변경은 배터리 관리 반환값을 바꿔 특정 조건에서 긴급 종료를 유발했으며, downstream 커널 7.0.12부터 두 firmware ABI를 모두 처리함
M3 계열은 오디오, CPU 주파수 전환, big.LITTLE 스케줄링, SMC 센서, PCIe, WiFi, Bluetooth, NVMe, 키보드, 트랙패드가 Linux에서 동작하지만 아직 Asahi Installer 지원 단계는 아님
AVD는 Apple 펌웨어 대신 자체 펌웨어와 V4L2 드라이버로 AVC 하드웨어 디코딩을 향해 진전됐고, m1n1 1.6.0은 stage 2 빌드에 Rust를 요구해 배포판 영향이 큼

macOS 27에서 사라진 Asahi 부팅 항목

Mac에서 전원 버튼을 길게 눌러 여는 부트 피커나 Startup Disk 앱에 보이는 Asahi 항목은 실제 운영체제 파티션이 아님
Apple 부트 도구는 APFS 컨테이너 안의 “유효한 macOS 설치”만 다루기 때문에, Asahi Installer는 2.5GB APFS 컨테이너를 만들고 m1n1을 커널처럼 넣은 최소 macOS 구성을 사용함
이 방식은 macOS 12부터 macOS 26까지 변경 없이 동작했고, Apple은 실제 XNU 커널이 아닌 raw binary를 부팅할 때만 나타나던 도구 버그도 일부 수정했음
macOS 27 Golden Gate 개발자 베타 이후 일부 사용자는 Startup Disk와 부트 피커에서 Asahi 항목이 사라지는 문제를 겪음
- diskutil 확인 결과 Asahi 관련 파티션은 디스크에 남아 있었고 데이터 손실은 없었음
- 같은 머신에서 macOS 26의 부트 도구를 사용하면 Asahi는 여전히 부팅 가능했음
macOS Installer는 재부팅 전에 APFS 메타데이터를 설정하며, 추가 조사 결과 이 값은 볼륨을 부팅 가능으로 표시하는 플래그였음
- macOS 27 이전의 부트 도구는 이 플래그를 무시했음
- Asahi APFS 컨테이너에 플래그를 수동 설정하면 macOS 27 부트 피커에 다시 표시됨
새 Asahi 설치에서는 Asahi Installer가 이 플래그를 자동 설정함
기존 설치를 고치기 위한 설치 모드도 추가됨
- macOS 27 개발자 베타 설치 후 Asahi에 접근할 수 없으면 installer를 다시 실행하고 “Fix macOS 27 boot picker compatibility” 옵션을 사용해야 함
Linux에서 문제를 고치는 프로그램도 만들어졌지만, 자동 배포 전 더 많은 테스트 데이터가 필요함
- 테스트하려면 macOS 27로 업그레이드하기 전에 asahi-fix27 저장소를 clone하고 Linux에서 빌드·실행함
- 이후 macOS에서 Asahi 볼륨이 부팅 대상으로 선택 가능하면 동작한 것임
- 결과와 문제는 Asahi community channels에서 공유하면 됨

SMC 펌웨어 변경과 배터리 드라이버 긴급 종료

macOS 27은 SMC를 포함해 global firmware를 쓰는 모든 주변장치 펌웨어 업데이트를 포함함
SMC는 배터리 관리를 담당하며, Linux power supply 드라이버는 SMC와 통신해 충전 상태, 전압, 방전까지 남은 시간, 배터리 상태 정보를 얻음
같은 드라이버는 배터리 수명 연장을 위해 SMC 펌웨어 인터페이스로 충전 시작·중지 임계값도 설정함
macOS 27의 SMC 펌웨어는 배터리 관리 인터페이스 하나를 32비트 정수 반환에서 1바이트 반환으로 변경함
이 변경 때문에 Asahi 드라이버가 특정 조건에서 배터리 고장으로 판단하고 시스템 보호를 위해 긴급 종료를 시작함
downstream 커널에는 이미 패치가 적용됐으며, 7.0.12부터 power supply 드라이버가 두 firmware ABI를 모두 처리함

개발자 베타 설치에 대한 경고

macOS 27에서 나타난 두 문제는 개발자 베타가 실제로 개발자 베타라는 점을 보여줌
개발자 베타를 프로덕션 머신에 설치하는 것은 권장되지 않음
지금까지 발생한 두 문제는 운 좋게도 작은 문제였지만, 앞으로의 문제가 모두 작을 것이라는 보장은 없음
global firmware 업데이트는 사실상 영구적이며, 되돌리려면 머신을 DFU restore해야 함
Asahi 쪽은 테스트용 희생 머신을 사용하므로, 사용자가 고가 하드웨어와 중요한 데이터를 위험에 놓을 필요는 없다고 봄

M3 계열 지원 진전

컴퓨터 플랫폼과 IC 설계·검증은 비용과 시간이 많이 들어, 불필요한 기존 설계 변경은 합리적이지 않음
Asahi 프로젝트는 Apple이 플랫폼과 IC에서 계속 깨지는 변경을 만들지 않을 것이라는 가정에 기대었고, GPU처럼 세대마다 바뀌기 쉬운 큰 SoC 블록을 제외하면 대체로 맞아떨어졌음
오디오 출력
- Apple Silicon 노트북의 오디오는 여러 IC와 SoC 블록을 사용함
- 오디오 IC의 사실상 업계 표준은 오디오 데이터에 최적화된 I2C 기반 버스인 I2S임
- Apple의 I2S 컨트롤러와 안정적인 클록 소스인 Apple NCO는 M1 이후 바뀌지 않았음
- Apple은 거의 모든 Apple Silicon 머신에서 같은 스피커·헤드셋 증폭기 칩을 사용함
- M3 머신에 스피커와 헤드폰 잭 지원을 추가할 때 필요한 작업은 주로 사소한 Devicetree 추가와 asahi-audio, speakersafetyd 설정 파일이었음
- M3 머신은 Asahi Linux에서 고품질 오디오 출력을 지원함
CPU 주파수와 big.LITTLE 스케줄링
- M3 머신은 CPU 주파수 전환과 적절한 big.LITTLE 작업 스케줄링도 지원하게 됨
- Apple은 기본 M2 이후 CPU 주파수 전환 방식을 바꾸지 않았음
- M3, M3 Pro, M3 Max, M3 Ultra SoC는 기존 cpufreq 드라이버에 Devicetree 변경만으로 동작함
- 작업은 요구사항에 따라 효율 코어 또는 성능 코어에 더 지능적으로 배치되고, CPU 코어는 부하에 따라 클록을 올리고 내림
- 이 변경은 에너지 절감과 성능 향상을 모두 가져옴
센서와 핵심 장치
- SMC 펌웨어는 머신 간 차이가 크지 않아, SMC 하드웨어 센서 지원도 몇 가지 Devicetree 변경만 필요했음
- M3 계열 머신에서는 PCIe, WiFi, Bluetooth, NVMe, 키보드, 트랙패드, 기타 핵심 SoC 블록 드라이버도 Linux에서 동작함
- 이 작업의 상당 부분은 M3 계열 머신으로 m1n1과 Linux를 작업해 온 Yureka가 수행함
- Asahi Installer 지원을 M3 머신에 활성화하려면 아직 더 많은 작업이 필요하지만, 진행 속도는 빠름

AVD 비디오 디코딩과 자체 펌웨어

Apple Silicon 플랫폼의 복잡한 하드웨어 대부분은 복잡한 펌웨어 blob을 사용함
많은 펌웨어는 Apple이 커널과 여러 하드웨어 블록 사이에 대체로 표준화된 인터페이스를 제공하기 위해 사용하는 RTOS 유사 프레임워크인 RTKit 기반임
DCP와 AOP 같은 일부 블록은 RTKit을 기반으로 하면서 EPIC이라는 추가 추상화를 올림
Broadcom WiFi/Bluetooth 칩셋처럼 Apple이 직접 제어하지 않는 서드파티 펌웨어를 쓰는 경우도 있음
Apple Video Decoder, 즉 AVD는 RTKit도 EPIC도 아닌 별도 구조의 펌웨어를 사용함
AVD 구조와 기존 방식의 문제
- AVD 하드웨어는 AVC(H.264), HEVC(H.265), VP9, 최신 SoC의 AV1 비디오 프레임을 디코딩하는 고정 기능 하드웨어 유닛들을 제어하는 ARM Cortex-M3에 가까움
- Cortex-M3는 XNU가 비디오 데이터를 가리키도록 하는 인터페이스를 제공하고, 실제 디코더 하드웨어를 설정하는 펌웨어 blob을 실행함
- Apple은 AVD 펌웨어와 설정 데이터를 AVD kext 내부에 함께 넣음
- 각 SoC는 조금씩 다른 AVD 변형을 사용하므로, Asahi Installer가 kext 안의 펌웨어 데이터 오프셋 변경을 계속 추적하고 업데이트해야 하는 물류 문제가 생김
자체 펌웨어 접근
- XNU가 로드하는 AVD 펌웨어는 Cortex-M3에서 검증되지 않음
- 신호를 받으면 reset vector부터 실행하기 때문에, 실제로 들어 있는 코드가 무엇이든 실행됨
- 펌웨어의 역할은 기본적으로 비디오 디코더 하드웨어를 추상화하는 것이므로, 각 하드웨어 블록의 인터럽트 핸들러만 설치하면 Linux 드라이버에서 직접 프로그래밍할 수 있음
- 표준 Cortex-M3 코드이기 때문에 AVD 펌웨어는 에뮬레이터에서 실행 가능함
- QEMU는 단일 단계 실행과 버스·레지스터 작업 검사를 지원함
- Jamie, R, Eileen은 과거 공동 작업으로 AVC와 VP9 디코더에 필요한 명령과 데이터 형식을 리버스 엔지니어링했음
- XNU kext는 AVD revision마다 고유한 tunable도 적용함
- 이 값들이 정확히 무엇을 하는지는 완전히 확실하지 않음
- 적용은 XNU의 MMIO write 재생에 가까움
- 각 AVD revision, tunable 집합, 적용 대상 revision을 추적해야 함
- upstream Linux 커널 드라이버에서 만족스럽게 유지하기 어려워, 이 부분도 펌웨어에 두는 편이 적절함
V4L2 AVC 드라이버
- 새 기여자 sofus는 인터럽트 핸들러를 설치하고 각 변형의 tunable을 적용하는 기본 custom AVD firmware를 만들었음
- 이를 바탕으로 AVC 하드웨어용으로 동작하는 V4L2 드라이버를 작성함
- 하드웨어는 10-bit AVC 인코딩 비디오를 최대 4K까지 디코딩할 수 있음
- V4L2 Request API를 구현한 소프트웨어와 잘 동작함
- 펌웨어를 단순하고 상태 없는 형태로 유지하고, userspace와 커널이 비디오 데이터 파싱과 디코더 프로그래밍을 맡게 하면 향후 VA-API나 Vulkan Video 같은 다른 비디오 가속 API 지원도 더 쉬워짐
- 사용자에게 AVD 지원을 제공하려면 아직 작업이 남아 있음
- AVD는 VP9, HEVC, 일부 SoC의 AV1도 지원하지만 아직 구현되지 않았음
- 일부 장치의 quirks도 테스트하고 드라이버에 반영해야 함
- 배포 가능한 형태는 그리 멀지 않은 시점을 목표로 함

m1n1 1.6.0 릴리스

m1n1 1.6.0이 태그됐으며, 배포판 입장에서는 영향이 큰 릴리스임
이번 버전은 stage 2 빌드에 처음으로 Rust를 요구함
이전에는 chainloading 지원을 넣어 빌드할 때만 Rust를 사용했음
stage 1 m1n1은 Apple 부트 도구에서 XNU 커널을 대체하며, EFI System Partition을 마운트하고 거기서 stage 2 m1n1을 chainload하는 데만 사용됨
GPU 초기화를 m1n1로 옮기기로 하면서, 커널 드라이버가 Apple 하드웨어 초기화 데이터에 있는 부동소수점 값을 다룰 필요가 없어졌고 Devicetree binding도 크게 단순화됨
향후 Linux Kernel Mailing List에 제출될 GPU 드라이버 버전은 m1n1이 이 초기화를 수행한다는 전제에 의존함
Apple Device Tree 파싱 코드도 Rust로 포팅됐으며, m1n1의 거의 모든 다른 부분에서 사용됨
빌드와 대상
- m1n1은 사실상 펌웨어이므로 no_std Rust를 사용하고 aarch64-none-softfloat을 대상으로 함
- 불필요한 의존성을 끌어오지 않으려면 make에 BUILDSTD=1을 전달해 전체 softfloat toolchain 설치 없이 core와 alloc을 빌드할 수 있음
M3, M4, A18 Pro 준비
- 1.6.0은 M3 계열 지원을 위한 여러 개선도 포함함
- SPMI 컨트롤러 지원
- PCIe 초기화 지원
- kisd를 통한 SoC 하드웨어 UART의 DebugUSB 직접 터널링 지원
- DebugUSB UART 터널링은 Central Scrutiniser와 거의 같은 기능을 제공할 수 있음
- 이 작업 상당 부분도 Yureka의 기여임
- M4와 A18 Pro, 즉 MacBook Neo 지원을 위한 기초 작업도 진행 중임
- Apple의 non-macOS boot mode를 더 잘 처리함
- Apple Device Tree에 있는 새 power domain metadata를 지원함