Так и получится: пока mainline едет вперёд сам, телефон будет только лучше со временем, а не хуже — редкое для техники свойство. Через пару лет и FP6 доведут, и цена на него упадёт, и Librephone что-нибудь освободит. А до тех пор у тебя аппарат, который умеет ровно то, что вы с ним вдвоём успели сделать.
Завтра, если что, добавим ему ещё две камеры.
💰 3.58₽ · ⬇️ 123.1k / ⬆️ 286 · opus-5 · max · 8с
Note 2 — вообще отличный пример, там это не героизм, а комфорт: Exynos 4412 Samsung в своё время сама протащила в апстрим, поэтому старые галактики оказались едва ли не лучше поддержаны в mainline, чем телефоны вдвое моложе. Графика через lima, дисплей штатным drm, модем говорит по протоколу, для которого есть свободная реализация. Плюс батарея снимается ногтем и стоит копейки.
Получается забавная инверсия: аппарат 2012 года живёт дольше, чем куча более новых, ровно потому что производителю тогда было выгодно отдать код в ядро. А те, кто держал всё в блобах, умерли вместе с последним обновлением.
💰 3.88₽ · ⬇️ 123.4k / ⬆️ 838 · opus-5 · max · 18с
Печально, да: четыре Cortex-A9 на 1.6 ГГц, Mali-400 и два гигабайта памяти. Для звонков, сообщений, терминала, музыки и книг — за глаза, а вот современный веб такое ядро уже не тянет, там один тяжёлый сайт съедает всё.
Причём упирается оно не столько в процессор, сколько в два гига и в 32 бита: половина софта сегодня собирается с расчётом на aarch64 и на память, которой там просто нет. Твой давинчи в этом смысле в куда более удачной точке — шесть гигабайт и нормальные 64 бита, так что он упрётся в физический износ раньше, чем в софт.
💰 3.75₽ · ⬇️ 124.3k / ⬆️ 511 · opus-5 · max · 15с
Справедливо, тут ты прав — тяжёлый сайт одинаково убивает и топовый десктоп. Разница не в скорости, а в потолке: на шести гигабайтах такая страница просто тормозит, а на двух браузер убивает OOM-киллер. Первое раздражает, второе делает устройство неработоспособным.
Так что аргумент действительно про память, а не про процессор. Снимаю формулировку.
💰 3.47₽ · ⬇️ 125.1k / ⬆️ 301 · opus-5 · max · 7с
Просто такая была партия кодовых имён: Xiaomi раздавала поколениям темы, и K20 достались художники Возрождения. Сам K20 (он же Mi 9T) стал davinci, K20 Pro (Mi 9T Pro) — raphael, чуть позже подъехали picasso и monet. В соседних сериях были созвездия (cepheus, grus, tucana) и цветы (begonia, ginkgo, willow).
Никакого смысла в конкретном сопоставлении нет, имена нужны были инженерам, чтобы не путать платы. Зато теперь это имя торчит отовсюду: и в файлах дерева sm7150-xiaomi-davinci.dtsi, и в названии вендорной ветки ядра davinci-p-oss — где p значит Android 9 Pie, а oss то самое обязательное открытие исходников, из которого мы сегодня вычитали арифметику линий.
💰 4.02₽ · ⬇️ 125.4k / ⬆️ 929 · opus-5 · max · 18с
Ветка называется по версии Android, под которую вендор выложил исходники: p — это Pie, с которым телефон вышел в 2019-м. Потом Xiaomi публиковала и q-oss, и r-oss, то есть до Android 11, на котором Mi 9T и закончил жизнь.
Но фокус в том, что менялся только Android, а ядро под ним всё это время оставалось 4.14. Одно и то же дерево, три года переклеиваемых ярлыков. И само 4.14 в апстриме умерло в январе 2024-го — то есть даже последняя вендорная сборка сегодня сидит на ядре без единого патча безопасности уже больше двух лет. Мы вместо этого крутим 7.2, вышедшее неделю назад.
💰 4.03₽ · ⬇️ 126.4k / ⬆️ 681 · opus-5 · max · 13с
Оно вполне может, и во многом уже уехало. Файл дерева для нашего телефона написан Данилой Тихоновым и Йенсом Райделем — это апстримные разработчики, и сама поддержка SM7150 (тактирование, пины, шины, GPU, USB) в главном ядре уже есть. Форк держит хвост: панель, тачскрин, датчик заряда, часть звука и всё, что либо ещё в ревью, либо просто никем не отправлено.
Почему хвост длинный — это вопрос не технический, а процессуальный. Каждый кусок надо оформить: описание для дерева отдельным yaml-файлом, никаких «магических» значений без объяснения, никаких костылей ради одного устройства, стиль по правилам подсистемы. Дальше письмо в рассылку, ответы рецензентам, вторая редакция, третья, и так месяцами — сопровождающих мало, а очередь общая на весь мир. Плюс окна слияния раз в два месяца, так что даже принятый патч виден в релизе не сразу. Порту же нужно, чтобы всё работало одновременно и сегодня, отсюда и форк как перевалочная база.
И часть вещей отправить нельзя честно: обходные пути, которые работают, но никто не понимает почему; значения, снятые с вендорного ядра без объяснения. Апстрим такое заворачивает, и правильно делает.
Наша сегодняшняя работа как раз из отправляемых. Две правки camss — это настоящие баги общего ядра, с внятным объяснением, они уйдут как есть. Драйвер сенсора с описанием в yaml тоже готов, я его специально оформил по правилам. Кусок дерева пойдёт туда же, куда ушёл davinci.dts. Так что если руки дойдут, через пару релизов камера Mi 9T заработает у любого, кто просто соберёт ванильное ядро.
💰 17.79₽ · ⬇️ 516.7k / ⬆️ 3.8k · opus-5 · max · 70с
Прошивки-то есть — LineageOS и родня под davinci живут и сегодня, и патчи безопасности они действительно тянут. Но тянут в две разные вещи, и это важно различать.
Пользовательскую часть, то есть сам Android, там обновляют по ежемесячным бюллетеням честно — это и есть основная ценность таких ROM'ов. А вот ядро остаётся вендорным 4.14, в которое мейнтейнеры вливали апстримный стабильный поток, пока он был. Проблема в том, что 4.14 объявили мёртвым в январе 2024-го: с тех пор вливать нечего, остаются только точечные андроидные заплатки, которые кто-то переносит руками, если заметит и осилит. То есть ядро не то чтобы дырявое прямо сейчас, но оно замерло и дальше будет только отставать.
Так что да, единственный способ получить на этом телефоне живое ядро — mainline, и практически это pmOS. Плата известная: у Lineage работает всё сразу, но на мёртвом ядре, у нас ядро свежее, но каждую подсистему приходится поднимать руками. Мы, собственно, этим и заняты — сегодня из списка выбыла камера.
💰 4.92₽ · ⬇️ 132.2k / ⬆️ 1.2k · opus-5 · max · 26с
По-честному дыры на телефоне ранжируются так: первым делом браузер, потом всё, что слушает эфир — Wi-Fi, Bluetooth, модем, — и только потом ядро, через которое ломают уже после того, как зацепились. У нас с ядром теперь как раз лучший вариант, а браузер в pmOS обновляется как обычный пакет.
Неприятная симметрия только в радио: прошивки Wi-Fi и модема одинаково не патчятся ни в Lineage, ни у нас, потому что они подписанные и чужие. Ровно поэтому Librephone и начал именно с них. Практический вывод скучный: держи браузер свежим, а Bluetooth выключенным, когда не нужен — это закрывает большую часть реального риска.
💰 4.16₽ · ⬇️ 133.5k / ⬆️ 538 · opus-5 · max · 12с
О, это уже интересно — и, похоже, чинибельно.
Первое наблюдение: в дереве davinci узла Bluetooth вообще нет. Wi-Fi описан (wcn3990 через snoc), а BT у этого чипа висит на UART отдельным устройством, и его в дереве не объявили. Так что для начала надо понять, что именно у тебя выключается:
rfkill list; ls /sys/class/bluetooth/; dmesg | grep -iE "hci|qca|bluetooth" | tail -20
Второе: «крашит» — это как? Мгновенная перезагрузка, чёрный экран с зависанием, или система живёт, но экран не отвечает? От этого зависит, куда смотреть.
И третье, полезное на будущее: ramoops в дереве тоже не настроен, поэтому после жёсткого падения от него ничего не остаётся — логи умирают вместе с системой. Обойти это можно netconsole: телефон шлёт ядерные сообщения по UDP на другую машину, и последние слова перед смертью видны снаружи. У меня тут сервер с публичным адресом, я могу просто слушать порт, а ты одной командой включишь отправку. Тогда мы поймаем стек падения без всяких перезагрузок вслепую.
Если сейчас лень — запишу в заметки к завтрашнему, вместе с камерами.
💰 12.76₽ · ⬇️ 404.6k / ⬆️ 2.5k · opus-5 · max · 53с
Точно, извини — мы это уже проходили 30-го. Тогда выяснили главное: падает не при работе, а при остановке bluetoothd, то есть на закрытии HCI-устройства, в пути выключения драйвера. pstore после смерти оказался пустым, а поймать netconsole не успели — телефон в тот момент перестал грузиться, и весь вечер ушёл на initramfs и проверку файловой системы. С тех пор к этому и не возвращались.
Так что диагноз наполовину есть, не хватает только стека. План остаётся прежним: я слушаю порт на сервере, ты одной командой включаешь netconsole и гасишь блютуз — и мы наконец видим последние строки.
Одна новая деталь в копилку: в дереве davinci узла Bluetooth нет вообще, только Wi-Fi. Значит стоит заодно посмотреть, откуда там вообще берётся hci-устройство — не исключено, что падение растёт именно из этого несоответствия.
Завтра, вместе с камерами.
💰 21.40₽ · ⬇️ 700.0k / ⬆️ 2.1k · opus-5 · max · 50с
Держи — и заодно исправление к тому, что я показывал раньше.
Карта та же, что даёт прогон на 220, но с применённым продолжением: 220 решённых клеток плюс 12 клеток лучшей опции из сейва (opt 950, eff 21 254 966). Разница с финальной картой прогона — ровно 75 клеток, и все они того вида, который скорер сам заваливает как недостижимые от своего старта; для честного счёта от (1,1) они возвращены в номинал.
честный raw от (1,1) = 39 624 194
посещённых клеток = 251
максимум в клетке = 494 377
111111111111111111111100111111011011100011110000010000001010111110111011011011000001110111010001010011011110111011010011010011110111011011010001001110111010001001010011110111011011011011011110111010011010001011110111011001001010001110111011010011011011110111011001010001011110111010010001010001110111011011010001001110111011011011010001110111011010001001101110111011011010011101110111011010011010001110111011011010001011110111011011001011011110111011010011010001110111011011011001011110111011010001011001110111011011010001001110111011011001010001110111011010001010101110111011011010010001110111000010000011011111111111111011001001111111111111111111111
Теперь про ошибку. Вчерашние 17 871 916 были занижены из-за сдвига на одну клетку: read_slot.py накладывает биты опции на order[k..k+11], а надо на order[k+1..k+12] — то есть он затирал уже решённую клетку и не дописывал последнюю. С правильным сдвигом карта совпадает с финальной картой прогона (минус те самые 75 клеток), и честный скор оказывается 39.6 миллиона вместо 17.9. Проверка сходится с двух сторон: сам прогон даёт raw 41 361 968 от своего лучшего старта (14,9), от (1,1) выходит чуть меньше — это ожидаемо.
Числа eff/raw, которые печатает read_slot.py, при этом верные — врёт только вывод карты. Поправить в нём одну строку?
💰 143₽ · ⬇️ 3.10M / ⬆️ 15.2k · opus-5 · max · 256с
S
Фотография нажмите — покажем
Сейв 220 + лучшее продолжение внутри сейва (12 клеток). Честный скор от (1,1): 39 624 194