Однако никто не мешает в будущем просто прошить раздел recovery вместо boot
Вот здесь хочется добавить: кое-что помешать может - это зависит от используемого инструментария для создания конечного .img образа. Всё дело в заголовках.
В структуре образа boot/recovery у старых мтк каждая часть имеет свой дополнительный заголовок. Ядро всегда имеет заголовок KERNEL. Рамдиск - ROOTFS либо RECOVERY, как раз в зависимости от раздела, с которого U-Boot производит загрузку.
Когда я пытался реализовать поддержку mt6577 в mainline-ядре, я задокументировал (вырвиглазно) этот момент, т.к. пару раз наступал на грабли нерабочего запуска. В моём случае дополнительно надо было делать рамдиск-обманку для удовлетворения требований U-Boot'a, тогда как на самом деле абсолютно всё необходимое склеивалось в состав единого zImage.
Вариантов решения проблемы - масса. Например, можно пропатчить образ U-Boot (недостаток - если устройство использует подписанную прошивку с файлами *-sign.img, то флештулом надо будет шиться через меню Write Memory вместо Download). Можно пропатчить U-Boot на уровне исходников, но, судя по отзывам с 4пда, начинается лютый карнавал при попытке его собрать. Самый очевидный вариант - банально прописать правильные заголовки для mkimage в своём Makefile или полностью отдать на откуп эту проблему "кухне", если она используется.
у 6573, 6575, 6577 и ещё нескольких звук в андроиде выводится через собственную мткшную подсистему yusu, костыльную настолько, что в андроиде приходится реализовывать фейковую alsa и обвязку для неё с пустыми роутами, конфигами. Драйвер AFE (audio front-end) там написан так, что без слёз не взглянешь. Пару раз садился за это дело, но в конечном счёте так и не смог разобраться, в каком порядке что взаимодействует для вывода звука на 6577. Там ещё и libbessound проприетарный на подхвате. Если хорошенько подумать, то уверен, что реализовать звук можно и без зависимости от андроида, достаточно будет сделать alsa-совместимую прослойку для AFE+YuSu.
Про самое главное не рассказали - ремонтопригодность аппарата. Рано или поздно ломается любая техника, и порой за ремонт можно отдать от половины стоимость нового устройства.
Перед покупкой понравившейся модели посмотреть пару видео с её разборкой, обслуживанием, ремонтом. Это даст некоторые представления о внутреннем устройстве компьютера и, возможно, информацию о типовых поломках, которые можно ожидать у этой модели.
Процессор / хаб / видик могут быть залиты компаундом. Снизу. Не только по периметру снаружи. Раньше таким очень славилась как минимум продукция леново. Если что-то из этого выйдет из строя, за работу по замене придётся заплатить намного больше.
Процессор и хаб на одном чипе. Если сломается что-то одно (например, появится крупный скол процессора из-за самостоятельной замены термухи или в хаб что-нибудь прилетит от неисправного юсб устройства), то придётся раскошелиться на новый комбочип, некоторые модели которых сейчас днём с огнём не сыщешь.
Распаянная на мамке оперативная память. На многих современных моделях присутствует только один слот памяти, и ещё одна планка распаяна на плате. Если с ней что-нибудь случится (типовая болячка у некоторых asus'ов), то надо будет потратиться на работу по отключению канала памяти или замене чипов на плате. Этого можно было бы избежать, если изначально брать ноут без распаянной оперативки
Я работал с мт65хх, так что вполне вероятно, что у 62хх по-другому, но вообще даже если подключить МТК к компьютеру в режиме прошивки, в lsusb он провисит не более 100 мс (период таймаута, в течение которого BROM в устройстве ждёт хендшейк от софта для прошивки после подключения по usb), поэтому на линуксе лучше, конечно, смотреть в dmesg, чтобы гарантированно не пропустить :)
чтение 16 бит по адресу 0x80000008
Адрес зависит от платформы. Скорее всего, у всей линейки мт62хх он одинаковый, но по-настоящему платформо-независимый способ узнать чип - это завершить хендшейк и получить ответ на команды:
0xFD - "GET_HW_CODE" - возвращает id процессора вида 0x6261
0xFC - "GET_HW_SW_VER" - возвращает значения HW_SUBVER (уточнение id процессора; было полезно для линейки 65xx, разные процы которой в ответ на 0xFD возвращали 0x6575), а также HW_VER и SW_VER (версия BROM)
Если подключенный телефон засветился в dmesg как продукция медиатек, можно использовать программы типа mtkclient, чтобы быстро и однозначно идентифицировать чип.
Бегло проанализировал бинарники в прошивке своего смартфона на базе Qualcomm на предмет интересных строк. Интересное нашлось в /vendor/bin/xtra-daemon:
Скорее всего, именно эта программа лезет в сеть за данными A-GPS. Судя по всему, исходников к ней нет, и она поставляется в уже скомпилированном виде для включения в прошивки. Из прикольного - выдержка из политики конфиденциальности:
XTRA uploads the following data types: a randomly generated unique ID, the chipset name and serial number, XTRA software version, the mobile country code and network code (allowing identification of country and wireless operator), the type of operating system and version, device make and model, the time since the last boot of the application processor and modem, and a list of our software on the device).
Связка SoC ID ("the chipset ... serial number") и всех остальных сливаемых данных в теории легко позволит выявить пользователей из России даже за семью проксями.
Всю информацию собирал, можно сказать, на ходу, поэтому стоит проверить, действительно ли xtra-daemon лезет за A-GPS и, если да, затем как-нибудь его пропатчить, перенаправив на свой прокси (в идеале - с помощью magisk и его systemless модификаций, чтобы не марать руки ручной заменой байт).
Действительно. Во время прочтения статьи ожидал увидеть именно запуск свежей связки mainline+rootfs. При наличии postmarketOS - дистрибутива alpine, который создан как раз для подобного рода устройств, с превосходным конфигуратором и сборщиком, - просто грех не попробовать, особенно для AllWinner/Rockchip, ведь там 90% уже в mainline ядре (если не больше). Остаётся лишь грамотно составить devicetree для ядра и конфиг для pmbootstrap. Такой замечательной возможностью определённо стоит воспользоваться, пока ТС не начал работать с продукцией медиатек - у некогда массовой линейки мт65хх поддержка в mainline околонулевая, а качество документации на эти чипы порой не позволяет её реализовать (убедился на личном опыте).
Вот здесь хочется добавить: кое-что помешать может - это зависит от используемого инструментария для создания конечного .img образа. Всё дело в заголовках.
В структуре образа boot/recovery у старых мтк каждая часть имеет свой дополнительный заголовок. Ядро всегда имеет заголовок KERNEL. Рамдиск - ROOTFS либо RECOVERY, как раз в зависимости от раздела, с которого U-Boot производит загрузку.
Когда я пытался реализовать поддержку mt6577 в mainline-ядре, я задокументировал (вырвиглазно) этот момент, т.к. пару раз наступал на грабли нерабочего запуска. В моём случае дополнительно надо было делать рамдиск-обманку для удовлетворения требований U-Boot'a, тогда как на самом деле абсолютно всё необходимое склеивалось в состав единого zImage.
Вариантов решения проблемы - масса. Например, можно пропатчить образ U-Boot (недостаток - если устройство использует подписанную прошивку с файлами *-sign.img, то флештулом надо будет шиться через меню Write Memory вместо Download). Можно пропатчить U-Boot на уровне исходников, но, судя по отзывам с 4пда, начинается лютый карнавал при попытке его собрать. Самый очевидный вариант - банально прописать правильные заголовки для mkimage в своём Makefile или полностью отдать на откуп эту проблему "кухне", если она используется.
у 6573, 6575, 6577 и ещё нескольких звук в андроиде выводится через собственную мткшную подсистему yusu, костыльную настолько, что в андроиде приходится реализовывать фейковую alsa и обвязку для неё с пустыми роутами, конфигами. Драйвер AFE (audio front-end) там написан так, что без слёз не взглянешь. Пару раз садился за это дело, но в конечном счёте так и не смог разобраться, в каком порядке что взаимодействует для вывода звука на 6577. Там ещё и libbessound проприетарный на подхвате. Если хорошенько подумать, то уверен, что реализовать звук можно и без зависимости от андроида, достаточно будет сделать alsa-совместимую прослойку для AFE+YuSu.
Про самое главное не рассказали - ремонтопригодность аппарата. Рано или поздно ломается любая техника, и порой за ремонт можно отдать от половины стоимость нового устройства.
Перед покупкой понравившейся модели посмотреть пару видео с её разборкой, обслуживанием, ремонтом. Это даст некоторые представления о внутреннем устройстве компьютера и, возможно, информацию о типовых поломках, которые можно ожидать у этой модели.
Процессор / хаб / видик могут быть залиты компаундом. Снизу. Не только по периметру снаружи. Раньше таким очень славилась как минимум продукция леново. Если что-то из этого выйдет из строя, за работу по замене придётся заплатить намного больше.
Процессор и хаб на одном чипе. Если сломается что-то одно (например, появится крупный скол процессора из-за самостоятельной замены термухи или в хаб что-нибудь прилетит от неисправного юсб устройства), то придётся раскошелиться на новый комбочип, некоторые модели которых сейчас днём с огнём не сыщешь.
Распаянная на мамке оперативная память. На многих современных моделях присутствует только один слот памяти, и ещё одна планка распаяна на плате. Если с ней что-нибудь случится (типовая болячка у некоторых asus'ов), то надо будет потратиться на работу по отключению канала памяти или замене чипов на плате. Этого можно было бы избежать, если изначально брать ноут без распаянной оперативки
Я работал с мт65хх, так что вполне вероятно, что у 62хх по-другому, но вообще даже если подключить МТК к компьютеру в режиме прошивки, в lsusb он провисит не более 100 мс (период таймаута, в течение которого BROM в устройстве ждёт хендшейк от софта для прошивки после подключения по usb), поэтому на линуксе лучше, конечно, смотреть в dmesg, чтобы гарантированно не пропустить :)
Адрес зависит от платформы. Скорее всего, у всей линейки мт62хх он одинаковый, но по-настоящему платформо-независимый способ узнать чип - это завершить хендшейк и получить ответ на команды:
0xFD - "
GET_HW_CODE" - возвращает id процессора вида 0x62610xFC - "
GET_HW_SW_VER" - возвращает значения HW_SUBVER (уточнение id процессора; было полезно для линейки 65xx, разные процы которой в ответ на 0xFD возвращали 0x6575), а также HW_VER и SW_VER (версия BROM)Если подключенный телефон засветился в dmesg как продукция медиатек, можно использовать программы типа mtkclient, чтобы быстро и однозначно идентифицировать чип.
Бегло проанализировал бинарники в прошивке своего смартфона на базе Qualcomm на предмет интересных строк. Интересное нашлось в
/vendor/bin/xtra-daemon:vendor/etc/izat.conf: GTP_PRIVACY_VERSION_URL = https://info.izatcloud.net/privacy/version.htmlvendor/bin/xtra-daemon: https://path1.xtracloud.net/xtra3Mgrbeji.bin
vendor/bin/xtra-daemon: nts.xtracloud.net
vendor/bin/xtra-daemon: time.xtracloud.net
vendor/bin/xtra-daemon: https://path1.xtracloud.net/xtra3grcej.bin
vendor/bin/xtra-daemon: https://path2.xtracloud.net/xtra3Mgrbeji.bin
vendor/bin/xtra-daemon: https://path2.xtracloud.net/xtra3grcej.bin
vendor/bin/xtra-daemon: https://path3.xtracloud.net/xtra3Mgrbeji.bin
vendor/bin/xtra-daemon: https://path3.xtracloud.net/xtra3grcej.bin
Скорее всего, именно эта программа лезет в сеть за данными A-GPS. Судя по всему, исходников к ней нет, и она поставляется в уже скомпилированном виде для включения в прошивки. Из прикольного - выдержка из политики конфиденциальности:
XTRA uploads the following data types: a randomly generated unique ID, the chipset name and serial number, XTRA software version, the mobile country code and network code (allowing identification of country and wireless operator), the type of operating system and version, device make and model, the time since the last boot of the application processor and modem, and a list of our software on the device).
Связка SoC ID ("the chipset ... serial number") и всех остальных сливаемых данных в теории легко позволит выявить пользователей из России даже за семью проксями.
Всю информацию собирал, можно сказать, на ходу, поэтому стоит проверить, действительно ли xtra-daemon лезет за A-GPS и, если да, затем как-нибудь его пропатчить, перенаправив на свой прокси (в идеале - с помощью magisk и его systemless модификаций, чтобы не марать руки ручной заменой байт).
Действительно. Во время прочтения статьи ожидал увидеть именно запуск свежей связки mainline+rootfs. При наличии postmarketOS - дистрибутива alpine, который создан как раз для подобного рода устройств, с превосходным конфигуратором и сборщиком, - просто грех не попробовать, особенно для AllWinner/Rockchip, ведь там 90% уже в mainline ядре (если не больше). Остаётся лишь грамотно составить devicetree для ядра и конфиг для pmbootstrap. Такой замечательной возможностью определённо стоит воспользоваться, пока ТС не начал работать с продукцией медиатек - у некогда массовой линейки мт65хх поддержка в mainline околонулевая, а качество документации на эти чипы порой не позволяет её реализовать (убедился на личном опыте).