Документацію написано англійською.

Сотовая связь: состояние и план порта

Сейчас сотовая связь в HakiOS не работает, но модем уже запускается из XNU (см. «21 октября» ниже). Wi-Fi использует WPSS и свой GLINK/QRTR; модем MPSS — отдельный процессор с другим каналом. hakios.qmi.c кодирует сообщения QMI и теперь позволяет привязать клиент к заданному транспорту QRTR, но канал к MPSS ещё не реализован. У iOS также нет драйверов AppleBaseband и AppleIPAppender для этого аппаратного пути. Запуск CommCenter без них уже проверялся: он завершается аварийно (см. README, раздел «Телефония»).

Проверка python3 devices/redwood/tools/modem_firmware.py --dtb devices/redwood/prebuilt/device-tree.dtb --firmware-dir fw-modem --node /soc/qcom,mss@4080000 сопоставила 28 сегментов штатной прошивки с областью mpss@8b800000 (PAS ID 4). MODEM=1 SYSTEM=1 ... userland/build.sh теперь может положить эти локальные файлы в системный APFS после проверки. Это только подготовка образа: наличие прошивки в /fw не запускает MPSS. Исходник hakios.nas.c содержит клиент QMI NAS для заданного транспорта QRTR: он ищет службу, запрашивает регистрацию и силу сигнала, разбирает ответы и сбрасывает состояние при исчезновении службы. Уровень bars остаётся нулевым без подтверждённой регистрации. MPSS-транспорта в XNU пока нет, поэтому этот клиент ещё не получает сообщения с телефона и не подключён к статус-бару iOS. Форматы NAS сверены с описанием libqmi.

Проверка на телефоне, 20 октября 2026

На redwood через fastboot boot временно запущены xnuloader и образ iOS 16.5. Системный APFS загружен в ОЗУ; разделы телефона не прошивались. launchd запустил SpringBoard, и на дисплее открылся интерфейс «Настройки». Это подтверждает загрузку iOS и работу экрана, но не работу модема. В журнале mg_test показывает telephony = true и cellular-data = false; запросы com.apple.commcenter.xpc и com.apple.basebandd.xpc остаются без службы. Значение telephony = true — ответ MobileGestalt о возможностях устройства, а не регистрация в сети. Тест выполнен с готовым ядром из prebuilt, поэтому изменения QMI в исходниках XNU в этой загрузке не проверялись. Дальнейший аппаратный тест требует сборки ядра с MPSS/QRTR и интеграции с iOS.

Что установлено по redwood

devices/redwood/prebuilt/device-tree.dtb содержит зарезервированную память mpss@8b800000, qcom,smp2p-modem, qcom,glink/modem/qcom,modem_qrtr, qcom,ipa@1e00000 и qcom,rmnet-ipa. Это разные части тракта: запуск прошивки модема, сигнализация, управляющий QMI-канал и передача IP-пакетов. Дерево Android redwood включает full_base_telephony.mk; его init.qcom.rc запускает vendor.qcrild и vendor.qcrild2. Ветка araxys с ядром/DTB пригодна как аппаратный справочник. Бинарники Android RIL нельзя просто запустить в iOS: им нужны Android binder, HAL, службы и ABI.

Проверка по USB 20 октября 2026 года: fastboot определил продукт redwood и разблокированный загрузчик; Android сообщил ro.boot.hardware.sku=redwood, ro.soc.model=SM7325. Под Android подсистема modem и прошивка yupik_ipa_fws были ONLINE, vendor.qcrild, vendor.qcrild2, vendor.qrtr-ns — running; присутствовали rmnet_ipa0 и rmnet_data0–rmnet_data5. Состояние SIM: ABSENT,LOADED для двух слотов. Временная загрузка xnuloader через fastboot boot и его selftest прошли (selftest-ok); это проверка загрузчика, а не сотовой связи в XNU.

Android dmesg уточняет последовательность: сначала поднимается yupik_ipa_fws, затем MPSS загружает modem.mdt и сегменты в 0x8b800000..0x9ae00000, получает Power/Clock ready, после чего QRTR фиксирует готовность QMI. Штатные modem.mdt/modem.b* (около 85 МиБ) сохранены локально в игнорируемом Git каталоге fw-modem/ и не входят в исходники. Их ELF-заголовок содержит 30 программных заголовков и 28 загружаемых сегментов; все файлы совпали по размеру, а сегменты лежат в зарезервированном окне. Загрузчик WPSS ограничен 16 сегментами; путь ADSP рассчитан на 48, но использует собственные ресурсы памяти, SMP2P и GLINK и не может запускать MPSS простым изменением имени прошивки.

Границы общей реализации

Общими для устройств должны быть контракт транспорта QRTR, разбор QMI, состояние SIM/сети и интерфейс передачи IP-пакетов. Запуск прошивки MPSS, ресурсы памяти, прерывания, SMMU, IPA и прошивки остаются в профиле и драйвере конкретного SoC/устройства. По наличию qcom,glink нельзя объявлять поддержку всех Qualcomm или других телефонов.

Порядок доведения до работающей связи:

  1. На подключённом Android собрать отчёт python3 devices/redwood/tools/cellular_probe.py --adb и сверить DTB, версию прошивки и активные службы. Скрипт читает только открытые свойства и не собирает IMEI, IMSI и номера SIM.
  2. Поднять MPSS в XNU с собственным GLINK/QRTR-каналом, отдельным от WPSS; проверить обнаружение QMI-служб, не отправляя команд регистрации или передачи данных.
  3. Реализовать QMI DMS/UIM/NAS/WDS и состояние SIM/сети; отдельно включить путь IPA/rmnet для мобильных данных.
  4. Подключить эти возможности к CoreTelephony/CommCenter через совместимый сервис и аппаратный драйвер, затем проверить SIM, регистрацию, входящие/исходящие вызовы, SMS и мобильные данные на телефоне. VoLTE/IMS — отдельная работа.

Пока пункт 2 не подтверждён на устройстве, не включать узел baseband и не переключать систему на cellular CommCenter: это создаёт аварийные циклы без радио.

Команды до и после подключения

python3 devices/redwood/tools/cellular_probe.py > modem-dtb.json
# После подключения телефона с разрешённой USB-отладкой:
python3 devices/redwood/tools/cellular_probe.py --adb > modem-android.json

Для другого устройства передать его DTB через --dtb PATH; прошивку на телефон инструмент не записывает.

21 октября 2026: модем запущен из XNU

Ядро теперь собирается на этом Mac (см. xnu/README.md, «Сборка на macOS»), и драйвер drivers/modem/hakios.mpss.c — копия пути аудио‑DSP (hakios.adsp.c) с числами модема — проверен на телефоне через xl run с modem_step=11 modem_return=1:

  • шаги 1–10 проходят: прошивка modem.* из /fw системного образа (85 МБ, 28 сегментов) записана в 0x8b800000 и прочитана обратно без расхождений; TrustZone принял подпись (образ 4) и область 0xf600000 байт; шины CX и MSS запрошены у RPMh на уровне 384; AOP получил modem: on; через 63 мс после старта модем сказал slave-kernel = 0x6 (поднялся и взял питание сам); GLINK согласован, канал IPCRTR открыт в обе стороны; QRTR: hello в обе стороны, модем — узел 0;
  • модем объявил только две службы: 43 (SSCTL, экземпляр 18) и 66 (реестр служб). DMS и NAS не появились за 40 с, поэтому шаг 11 (DMS «online», опрос NAS) не выполнен;
  • по просьбе модем остановился за 43 мс (0x10e), TrustZone выключил его, AOP получил modem: off; телефон вернулся в загрузчик штатно.

Причина отсутствия DMS/NAS — у модема нет доступа к своим файловым системам: на Android их отдаёт демон rmtfs (служба QMI 14 поверх QRTR, linux-msm/rmtfs). В драйвер добавлена такая служба: четыре раздела (modemst1, modemst2, fsc, fsg) читаются при старте шагов целиком в память ядра через hakios_ufs_read_partition() (нужен ufs=2 в аргументах ядра — блочная служба загрузчика), модем открывает их по путям /boot/modem_fs1 и т. д., получает буфер 2,5 МБ (qcom,rmtfs_sharedmem@0), в который TrustZone пускает модем вызовом SCM MP ASSIGN (HLOS + MSS_MSA, чтение и запись), и читает или пишет секторы через него. Записи остаются в памяти ядра: разделы телефона не записываются. Служба объявляется модему в ответ на hello и на lookup (наша сторона сервиса имён QRTR). Это ещё не проверено на телефоне: после предыдущего прогона телефон исчез с USB (сторожевой таймер загрузчика), нужен ручной перезапуск в fastboot.

Запуск теста:

./xl enter && ./xl ramdisk userland/system.apfs    # образ с MODEM=1 SYSTEM=1 (один раз после входа в загрузчик)
XL_CMDLINE="debug=0x8 rd=md0 hv_wdt_pet=1 bootcpu=7 cpus=8 cpufreq=1 sb_delay=600 ufs=2 modem_step=11 modem_return=1 modem_new=12 modem_nas_wait=60" XL_SECS=300 XL_FOLLOW=3 ./xl run

modem=1 в обычной загрузке делает всё то же на своём потоке и оставляет модем включённым, опрашивая NAS каждые две секунды; результат — в sysctl kern.hakios.cellular_up, cellular_registered, cellular_bars, cellular_dbm, cellular_radio. Палочки в статус‑баре iOS из этого ещё не получаются: нужна либо часть CommCenter, либо подмена элемента статус‑бара в libhakios.sb.dylib по этим sysctl (следующий шаг).

23 октября 2026: буфер RMTFS и перезапуски телефона

Ночные прогоны (tools/macos-bin: adb из platform-tools r34 — сервер adb 37.0.1 на этом Mac убивается через две секунды после запуска; xl возвращает телефон в Android после каждого прогона) показали:

  • буфер RMTFS должен лежать ниже 4 ГБ: адреса в запросах модема 32‑битные (с буфером 0x197508000 модем пишет «xpu lock failed» по усечённому адресу и сдаётся);
  • память CDSP (0x9c700000) не годится: после её передачи TrustZone отказывается запускать модем (-3145799); память видеокодека (0x8ae00000) и ramoops (0xb0000000) — модем стартует, но телефон сбрасывается при первой нашей записи сектора; свободная память UEFI (0xa8000000, modem_buffer=) — то же, пока буфер отдан только HLOS и MSS;
  • Android отдаёт буфер трём владельцам: HLOS, MSS_MSA (15) и NAV (0x2b) — в DTB телефона у qcom,rmtfs_sharedmem@0 стоит qcom,vm-nav-path. С тремя владельцами запись в буфер после «замка» модема проходит без сброса (цикл 2: сектор записан, модему отказано — ядро вернулось штатно). Обратная передача ({HLOS, MSS, NAV} → {HLOS}) при остановке отказывает (-2, ответ 0x56): видимо, пока держится замок модема; на перезагрузку это не влияет;
  • опыты включаются ключами modem_share_test=1 (пробная запись после передачи), modem_rmtfs_rw_off=1 (отказ в чтении), modem_rmtfs_rw_fake=1 (запись есть, ответ «нет»), modem_rmtfs_delay=S (пауза перед первым чтением), modem_share_off=1, modem_no_nav=1.

Паника copyio.c:89 Assertion failed: pan != 0 в пользовательских процессах iOS встречалась в двух прогонах с модемом; её причина не найдена.

23 октября 2026, вечер: модем читает файлы, выходит в ONLINE

С буфером в 0xa8000000, отданным HLOS, MSS и NAV, модем читает свои файловые системы и за ~30 с объявляет все службы (88 объявлений: DMS 2, NAS 3, UIM 11, WDS 1, ...). Дальше он стоит в режиме OFFLINE и на DMS Set Operating Mode = online отвечает «устройство не готово» (52), на low power — «недопустимый переход» (60): он ждёт двух служб процессора приложений, которые на Android дают демоны pd-mapper и tqftpserv:

  • реестр служб (QMI 64, версия 257): модем спрашивает, где tms/servreg и другие; ответ — домены (msm/modem/root_pd, экземпляр 180) из *.jsn раздела прошивки;
  • TFTP поверх QRTR (QMI 4096): модем пишет /readwrite/server_check.txt, читает /readonly/firmware/image/modem_pr/so/665_0_0.mbn кусками (опции rsize, seek, wsize, blksize), просит /readwrite/ota_firewall/ruleset (нет — не страшно).

Обе службы теперь в hakios.mpss.c (разделы «TFTP over QRTR» и «the service registry's locator»): файлы берутся из /fw/image системного образа (fw-modem/image — копия /vendor/firmware_mnt/image телефона, снятая adb pull; MODEM=1 SYSTEM=1 userland/build.sh кладёт её в образ), записи модема хранятся в памяти ядра на время прогона. Сервер имён QRTR объявляет наши службы модему при hello и отвечает на его lookup.

Результат (прогон 23:00): после обслуживания файлов модем согласился перейти в ONLINE, NAS ответил «не зарегистрирован, CS/PS отключены», и через несколько секунд модем упал в задаче enl2_dl (LTE L2, downlink) с нулевым адресом. Предположительно при выходе в сеть он обращается к IPA, которого с нашей стороны нет; проверяется ответ «IPA недоступен» через SMP2P (modem_ipa=1), дальше — либо запуск прошивки IPA и его тактов, либо иной обход.

24 октября 2026: IPA — прошивка, такт, SMMU

Падение enl2_dl повторяется в каждом прогоне через несколько секунд после ONLINE. Гипотеза — модему нужен работающий IPA (пакетный ускоритель, через него идут данные LTE), и в hakios.mpss.c появился его минимальный драйвер («the IPA» в файле), по образцу drivers/net/ipa Linux (версия IPA 4.11, sc7280):

  • такт: без голоса RPMh за BCM IP0 (ipa_clock()) TrustZone отвечает на AUTH_AND_RESET образа 15 «Unhandled implementation specific error»; с голосом прошивка yupik_ipa_fws (перемещаемый ELF, кладётся от 0x8b700000) стартует, микроконтроллер отвечает «booted» (ipa_status());
  • память IPA: ipa_memory_init() обнуляет локальную память (0x3000), пишет канарейки и базу контекстов обработки; раскладка — ipa_data-v4.11.c;
  • QMI 0x31: наш хост (экземпляр 1) посылает модемному драйверу IPA INIT_DRIVER с раскладкой памяти (таблиц маршрутов 15, иначе модем падает на num_indices >= rtng_tbl_max), модем подписывается на индикацию; ответ INIT_COMPLETE ещё не дождались;
  • SMMU: IPA ходит в память через SMMU процессора приложений потоками 0x480 (AP) и 0x482 (микроконтроллер). Поток без совпадения даёт отказ, обход (bypass) гипервизор не даёт. Контекст с нашими таблицами (тождественное отображение гигабайта DDR от 0x80000000 и imem 0x146a8000) гипервизор принял (sctlr стал 0x127, s2cr — наш), но регистр совпадения с потоком 0x480 и маской 0x2 он сбросил в 0. У Wi-Fi (0x1c00, маска 1, как в дереве устройств) прошло. В дереве устройств у потоков IPA маска 0 — гипервизор, видимо, сверяет пару (поток, маска) со списком хозяев. Прогон 21: по регистру совпадения на каждый поток, маска 0.

Телефон после каждого прогона возвращается в Android (cycle.sh); разделы не пишутся.

24 октября, ночь: что говорит сам Android

Android телефона рутован (KernelSU), и его dmesg, debugfs (/d/ipa, /d/gsi) и IPC-логи (/d/ipc_logging/ipa/log, gsi/log) читаются по adb. По ним:

  • SMMU: прогон 21 подтвердил догадку — гипервизор принял по регистру совпадения на поток (0x480 и 0x482, маска 0, оба в контекст 7), отказов IPA не было;
  • модем не отвечал на INIT_DRIVER вовсе (13 с до падения enl2_dl). У Android ответ приходит через 11 мс, и запрос другой: platform_type 3 (мы слали 1 — «data card»), num_indices 7 (мы 14), область модема 0x27d8 размером 0x800 (мы 0x1f18/0x100c, раскладка upstream v4.11 не совпадает с раскладкой ipa_4_11_mem_part из techpack/dataipa), контексты обработки 0xad0 размером 0xac0, статистика квот 0x1d00/0x30, дропов 0x27b0/0x20; TLV 0x18 (is_ssr_bootup) при первой загрузке не посылается;
  • после ответа модем шлёт INIT_MODEM_DRIVER_CMPLT (0x35), CONFIG (0x27), INSTALL_FILTER_RULE (0x23), FILTER_INSTALLED_NOTIF (0x24) — Android отвечает успехом; индикацию INIT_COMPLETE (0x22) шлёт сразу после ответа на INIT_DRIVER;
  • микроконтроллер IPA загружает модем (его события «booted» приходят после ответа), нам его область (0x0..0x288) трогать не надо;
  • прошивка IPA у Android кладётся с 0x8b710000 (reserved ipa_fw@8b700000 0x10000, ipa_gsi@8b710000 0xa000); окно SRAM — ipa-base + 0x40000 + 0x10000 = 0x1e50000, 0x3000 байт (блок в драйвере был отображён на 4 КБ — исправлено на 0x4000).

Источник раскладки и обработчиков: techpack/dataipa/drivers/platform/msm/ipa/ipa_v3 (ipa_utils.c: ipa_4_11_mem_part, ipa_qmi_service.c), ядро Atom-X-Devs/android_kernel_xiaomi_sm7325 (у MiCode ветка hakios-s-oss).

Прогон 23 (01:11): служба IPA модема отвечает — но не на INIT_DRIVER

Пробный запрос (сообщение 0x7fff) на порт службы IPA модема получает ответ через 1 мс (result 1, error 0x39 — неизвестное сообщение): транспорт в обе стороны работает. INIT_DRIVER (0x21), посланный тем же портом за мгновение до того, ответа не получает ни разу — модем его декодирует (иначе был бы ответ об ошибке) и зависает в обработчике, то есть на обращении к железу IPA (свои GSI-каналы, таблицы через команды, загрузка микроконтроллера). Регистры, которые Android пишет до модема (QSB, Qtime, COMP_CFG, группы ресурсов, маршрут), теперь выставлены (ipa_hardware_init()), это не помогло. Следующие кандидаты: GSI со стороны модема (Android регистрирует GSI и поднимает свои каналы до модема — возможно, модему нужны прерывания/GSI_EE общие регистры), голоса шины SN8/SH0/MC0/ACV (имена есть в cmd_db) на время рукостискания, и чтение через adb того, что делает модем Android в первые 11 мс после INIT_DRIVER (/d/ipc_logging/gsi/log вокруг 33.31 с).

Прогони 24–26 (ранок 24 жовтня)

  • 24 (skip_uc_load=1): модем падає інакше — ipa_qsh.c:1241: IPA_QSH failed to send analysis to IPA_CTL msgQ: черга задачі IPA_CTL переповнена, задача стоїть незалежно від мікроконтролера.
  • 25: TrustZone кладе сегменти образу IPA у внутрішню пам'ять GSI (0x1e1f000) і мікроконтролера (0x1e81000) байт у байт (перевірено читанням), GSI_CFG = 0x205 — як пише gsi_enable_fw(). Прошивка GSI увімкнена, адреса образу в DDR (0x8b700000 чи 0x8b710000, як у Android) ні на що не впливає. Сегмент мікроконтролера — лише 0x3c8 байт: завантажувальний стаб; повну прошивку йому дає модем. Пробний запит службі IPA модема відповідається за 1 мс, INIT_DRIVER — ніколи.
  • 26: Android при старті драйвера виділяє в SMEM (розділ apps–modem) елемент SMEM_IPA_FILTER_TABLE (497) на 0x9000 байт (qcom,ipa-q6-smem-size) і відображає його в SMMU-контекст IPA: модем кладе туди свої таблиці фільтрів. Тепер елемент робиться на кроці 6 (раніше, 22 жовтня, його вимкнули: без працюючого IPA модем, знайшовши елемент, падав до появи служб). modem_ipa_item=0 — не робити.

Прогін 28 (08:49): РУКОСТИСКАННЯ IPA ПРОЙШЛО

Розгадка — у рядках образу модема: IPA_SMP2P: Could not wait for inbound SMP2P channel readiness. Драйвер IPA модема при ініціалізації чекає, поки в елементі SMP2P процесора застосунків з'явиться запис «ipa» (у Android він є з завантаження: qcom,smp2p-ipa-1-out), і без нього задача IPA_CTL стоїть вічно — звідси мовчання на INIT_DRIVER і падіння enl2_dl. З modem_ipa=3 (запис «ipa» = біт 0 «відповідь дійсна» + біт 1 «такт IPA увімкнено») модем за 10 мс прийняв INIT_DRIVER, надіслав INIT_MODEM_DRIVER_CMPLT, CONFIG і 27 правил фільтрів (INSTALL_FILTER_RULE). Впав на звірці ідентифікаторів правил з нашої відповіді (ipa_ipfltr.c:6246): rule_id у структурі правила лежить на зміщенні 168, не 163 — виправлено (прогін 29). Елемент SMEM 497 і голоси за шини (SN8, SH0, MC0, ACV) лишаються.

Прогони 29–30: модем живе, але не шукає мережу — SIM у другому слоті

  • 29: з вірними rule_id модем пережив установку правил, вийшов в ONLINE і прожив усі 120 с опитування NAS, зупинився коректно. NAS: «registration 0 (none), CS 2, PS 2», радіоінтерфейс 0 (немає сервісу), сигналу нема — модем навіть не шукає.
  • 30: додані запити після ONLINE (sim_probe()): UIM Get Card Status (0x2f) — слот 1: карта ERROR (код 3), слот 2: PRESENT, USIM READY; NAS Get System Selection Preference (0x34): режим GSM|UMTS|LTE, вибір автоматичний; NAS Initiate Network Register (0x22) — відмова, помилка 37. Android бачить ту саму SIM (Kyivstar, ICCID 8938…4340) активною. Первинна підписка (NAS, що опитуємо) прив'язана до логічного слота 1 без картки — звідси «no service». Прогін 31: UIM Switch Slot (0x46): логічний слот 1 → фізичний слот 2, потім повторні запити.
  • Прогони з modem_step=11 тримають SpringBoard 600 с (телефон стоїть на логотипі Apple); тепер tools/modem-cycle.sh бере XL_SB_DELAY з оточення, і прогін 31 — повне завантаження iOS з модемом у фоні (modem=1).

Прогін 31 (09:12): повне завантаження iOS, перемикання слота, ПЕРШИЙ СИГНАЛ

XL_SB_DELAY=8 + modem=1: SpringBoard стартує одразу (телефон більше не стоїть на логотипі Apple під час тестів), модем піднімається у фоні. Після UIM Switch Slot (логічний 1 → фізичний 2) картка з'явилась у слоті 1 у стані «detected», і NAS уперше прочитав сигнал: -80…-87 dBm, UMTS — радіо працює, модем бачить мережу; реєстрації ще нема (помилка 37 на Initiate Network Register = UIM_UNINITIALIZED: SIM ще ініціалізується після перемикання). Тепер крок 11 раз на 10 с питає стан картки та NAS Get System Info (0x4d).

Статус-бар: у SpringBoard iOS 16.5 стільникові пункти заповнює SBStatusBarStateAggregator через _updateSignalStrengthItem:withData:SIMInfo:barsGetter:barsSetter: і _setItem:enabled: (селектори знайдені в кеші dyld). inject_sb.c тепер перехоплює цей метод: коли kern.hakios.cellular_registered, виставляє палички через barsSetter і вмикає пункт; раз на 3 с просить пункт оновитися, коли стан у ядрі змінюється; список методів агрегатора пишеться в лог.

Прогін 32 (25 жовтня): хук статус-бару живий; підписка ні до чого не прив'язана

  • Хук у SpringBoard працює: _updateSignalStrengthItem:withData:SIMInfo:barsGetter:barsSetter: викликається для пунктів 4 (основна SIM) і 5 (друга), setter-и передаються, і за нашим проханням пункт оновлюється; повний список методів агрегатора є в лозі (_postItem:withState:inList:, _updateBatteryItems, …).
  • UIM після перемикання слота: USIM у логічному слоті 1 READY, PIN1 вимкнений, але первинний GW-додаток — 0xffff (немає), і NAS System Info показує service 4 (power save) по всіх радіо. Тобто підписці не призначено USIM. Прогін 33: UIM Change Provisioning Session (0x38): primary GW, activate, слот 1 + AID USIM, потім повторне Initiate Network Register.
  • Прогони з самим модемом не вмикали решту заліза: GPU (gpu=1), DSP/батарея (adsp=1), вібро (haptic=5), Wi-Fi (wifi=1) — звідси «no GPU to draw with», SOC=-1%, без вібрації. Прогін 33 — з усім разом. Тач працює, коли екран увімкнений (iOS гасить його через ~25 с бездіяльності; кнопка живлення будить).

Прогони 33–34: усе залізо разом

  • 33 (gpu=1 adsp=1 sound=4 wifi=1 haptic=5 modem=1): ядро стартувало, і телефон зник з USB у перші секунди — як у прогоні 31. 32-й (той самий modem=1, але без GPU/DSP/Wi-Fi/вібро) прожив 10 хвилин. У коді модема є давня примітка: після старту DSP Wi-Fi старт модема скидав телефон. Прогін 34 — те саме без wifi=1, щоб звузити винуватця.
  • 33-й також перший із provisioning-сесією UIM (0x38): результат ще не отримано.

Прогони 35–37 (25 жовтня, вечір): перейменоване ядро, прошивка в образі, SIM у слоті 1

  • 35 (перейменоване ядро, gpu adsp haptic modem, без Wi-Fi): знову смерть до першого рядка лога. Винуватець серед GPU/DSP/вібро ще не знайдений; модем сам по собі (36, 37) живе.
  • 36: модем упав на кроці 2 («прошивка», nothing written) одразу — образ system.apfs після перейменування зібрали без MODEM=1, прошивки модема в ньому не було. Правильно: REST=1 MODEM=1 SYSTEM=1 userland/build.sh (з bash).
  • 37 (той самий образ з прошивкою): модем піднявся, IPA пройшов рукостискання, NAS бачить мережу (−83 dBm UMTS), але реєстрації нема. SIM тепер у логічному слоті 1 (слот 2 порожній), її USIM у стані 1 «detected» — не READY, і первинний GW-додаток «немає». Наш код прив'язував provisioning-сесію лише до READY-карти, тож нічого не робив. Виправлено: «detected» USIM теж робиться первинним GW-додатком (UIM 0x38), після чого модем має її ініціалізувати.
  • «Absent» наприкінці кожного прогону — не крах: лоадер годує watchdog гіпервізора лише loader_return_after + 60 с, далі телефон скидається і за 2–3 хвилини сам завантажує Android.

2.0: канал даних IPA і en1 (25 жовтня)

  • hakios.ipa.c: наша сторона IPA, як у Linux drivers/net/ipa для IPA 4.11 — чотири канали GSI з кільцями подій (команди: канал 5/ендпоінт 7; LAN-прийом 14/9; передача модему 2/2; прийом від модему 7/16), ендпоінти (QMAP-заголовки, деагрегація на виході, агрегація до 12 КБ або 500 мкс на вході, без checksum offload і без status-пакетів), таблиці фільтрів/маршрутів/заголовків негайними командами — усе до старту модема, щоб він додав свої правила до чинних таблиць. Кільця опитуються потоком інтерфейсу, переривань GSI не беремо. Пам'ять DDR для IPA показано цілком (1 ГБ блоки в корені таблиці SMMU).
  • hakios.cell.c: en1 — Ethernet-подібний інтерфейс із вигаданим роутером за ним; ядро відповідає на ARP за будь-яку адресу і на DHCP налаштуваннями сесії (адреса, /24 довкола неї, роутер .1, DNS з модема, MTU), тож configd налаштовує його як USB-Ethernet. IPv6 не носимо.
  • hakios.net.c вміє два інтерфейси (en0 радіо/virtio, en1 модем).
  • У драйвері модема перед сесією: WDA Set Data Format (raw IP у QMAP без checksum, embedded port, iface 1) і WDS Bind Mux Data Port (mux 1); налаштування сесії йдуть у hakios_cell_session().
  • Статус-бар: setter-и елементів — блоки, а викликались як функції (впало б при реєстрації); виправлено, і назва оператора (kern.hakios.cellular_operator) ставиться в service item.
  • Прогін 38 — перший з усім цим: чи піднімається канал (ipa: THE DATA PATH IS UP), чи реєструється модем після provisioning «detected» USIM, чи стартує сесія і чи отримує en1 адресу по DHCP.

Вихідний код цієї сторінки