Заменяем бут-анимацию Android устройства на мелькающие логи Linux ядра

    После разработки кастомного загрузчика для своего телефона мне захотелось реализовать вывод ядерных логов на дисплей, как это умеют делать десктопные дистрибутивы Linux. А всё потому, что лично мне при загрузке телефона намного интереснее наблюдать мелькающие kmsg логи, нежели наблюдать сначала логотип загрузчика, а затем ещё и бут-анимацию Android системы. За два года «скучные обоины» уже приелись.

    Сейчас попытаюсь вкратце рассказать о модуле LLCON для Android ядра, который реализует низкоуровневый вывод kmsg логов на дисплей.

    Сразу упомяну о том, что в любом Linux ядре есть модуль, который занимается выводом ядерных логов на экран. Данный механизм ядра включается при помощи указания опции FRAMEBUFFER_CONSOLE. Но данный механизм работает только через драйвер дисплея, который обычно инициализируется в самую последнюю очередь (этап late_init). Из-за этой особенности первичный логотип загрузчика будет отображаться довольно значительное время.

    Слова «низкоуровневый вывод» я употребляю не спроста, т.к. модуль LLCON напрямую работает с видео-памятью (сразу вспоминаются юные поделки для MS-DOS) и при этом начинает свою работу перед инициализацией внутренних драйверов Linux ядра (early_init). Именно данные особенности и позволяют LLCON начать вывод логов ядра на экран как можно быстрее.

    После добавления LLCON модуля следует в конфиг ядра добавить следующие опции:
    CONFIG_VT=y
    CONFIG_LLCON=y
    CONFIG_FONTS=y
    CONFIG_FONT_6x11=y
    CONFIG_FONT_8x16=y
    CONFIG_FONT_SUN12x22=y

    В данном случае я указал 3 разных шрифта, т.к. в используемом мною загрузчике можно выбирать любой шрифт. Но если нужно соблюдать минимальный размер образа ядра, то следует указать только один шрифт.

    Перед стартом сборки доработанного ядра не стоит забыть предварительно добавить в BoardConfig новую опцию ядра:
    androidboot.llcon=<mode>,<delay>,<textwrap>,<fb_addr>,<fb_bpp>,<fb_height>,<fb_width>,<fb_stride>,<font_size>,<font_color>

    Расшифровка параметров
    • mode:
      0 = LLCON отключён
      1 = синхронный вывод логов (постраничный скроллинг)
      2 = асинхронный вывод логов (построчный скроллинг)
    • delay:
      задержка в миллисекундах (используется в потоке, выводящем графику на экран; рекомендуемое значение 100)
    • textwrap:
      0 = перенос текста на новые строки запрещён
      1 = перенос текста на новые строки разрешён
    • fb_addr:
      физический адрес FrameBuffer
    • fb_bpp:
      формат пикселей дисплея (сейчас игнорируется)
    • fb_height:
      высота дисплея в пикселях
    • fb_width:
      ширина дисплея в пикселях
    • fb_stride:
      размер одной строки в пикселях или в байтах
    • font_size:
      размер шрифта (поддерживаемые значения: 6, 8, 10, 12)
    • font_color:
      цвет символов в HEX формате

    Пример:
    androidboot.llcon=2,100,0,0x03200000,24,1280,720,720,8,0xFFFFFF

    Как узнать значение параметра fb_addr
    Физический адрес FrameBuffer'а можно подсмотреть в DeviceTree собираемого ядра. Для этого ищите параметр «qcom,memblock-reserve» в ветке «qcom,mdss_fb_primary». Так же очень часто адрес FrameBuffer'а фигурирует в kmsg логах ядра.


    Целиком копировать сюда исходники модуля LLCON я не стану, а только укажу ссылки на соответствующие патчи:

    Также стоит отметить, что без доработки init-модуля (который находится в ramdisk'е) при инициализации подсистем андройда начнётся воспроизводиться бут-анимация. Поэтому при использовании LLCON следует автоматизировать отключение бут-анимации, что выполняет вот этот патч.

    Демонстрация работы модуля LLCON:

    • LLCON 1 — постраничный режим, шрифт 6x11

    • LLCON 2 — построчный режим, шрифт 8x16


    Модуль LLCON так же имеет дополнительный функционал, который полезен для:
    • получения kmsg логов в случае экстренной перезагрузки SoC (когда даже last_kmsg бесполезен);
    • отладки ядра на самых ранних этапах инициализации (когда недоступны JTAG и UART).

    Но об этих возможностях LLCON я постараюсь рассказать в следующий раз.
    Поделиться публикацией

    Комментарии 28

      +1
      Это, конечно, круто, но если нет желания возиться с модулем ядра, для вывода logcat и dmesg можно установить приложение LiveBoot (требует root-прав).

      Ясно, что посыл статьи не в этом, но конкретно данную задачу можно решить проще.
        +3
        Вот для сравнения видео от создателя этой софтины:

        Можно сразу заметить, что нужно довольно долго ждать появления kmsg логов на дисплее (до начала работы самого андройда).
        В самом начале своей публикации я сразу упомянул о том, что я задавался целью именно самого раннего начала вывода kmsg логов на дисплей.
          0
          Гораздо проще заменить бут-анимацию ИМХО
        0
        acDev, давно присматриваюсь к системной разработке под android!
        Нет ли у вас планов написать статью «getting started» на эту тему?
        Как я понял начинать нужно с покупки смартфона семейства Nexus,
        поскольку по факту только они пригодны для использования прошивки
        из исходного кода?
          +6
          Такую статью не могу написать, т.к. я считаю себя виндузятником. Я весь код пишу на винде, который затем по SMB кидаю на Ubuntu тачку для сборки.
          Надеюсь меня за это никто не заминусует. Ну не могу я обходиться без родного TotalCmd и других.
          А касательно Nexus вот что скажу. Для разработки кастомных ядер Nexus не нужен. А вот когда разговор заходит о кастомном загрузчике, только тогда может чем то помочь специальная версия Nexus для разрабов. Но даже в этом случае я советую поискать китайский вариант, в котором отсутствует подпись загрузчика (либо используется тестовая подпись Qualcomm).
            +1
            Такую статью не могу написать, т.к. я считаю себя виндузятником. Я весь код пишу на винде, который затем по SMB кидаю на Ubuntu тачку для сборки.

            Ну это вдвойне интересно, вы же не единственный виндузятник :)

              +1
              Под Ubuntu как алтернативу Total Commander можете попробовать Double Commander
                0
                Да и под Windows тоже. Плагины ТС ест, настраивается, окна по умолчанию не модальные.
                  0
                  Главное не делать в нем операции с важными файлами, ибо крашится он с завидной периодичностью. Во всяком случае по OSX уж точно.
                    0
                    В Win и *buntu не подтверждаю, за два года в качестве основного ФМ — ни одного падения.
                +1
                Ну коли мой ответ на данный комментарий получил столько плюсиков, то по поводу статьи отвечу более конструктивно.
                Системной разработкой под Linux я занялся по одной лишь причине: отсутствие прошивок Android 4.4/5.1 для моего телефона, коим является Highscreen Boost 2 SE. Поэтому за неимением исходников стокового ядра пришлось реверсить это самое ядро. Но пришлось ещё реверсить и загрузчик. Более подробно можно почитать тут: http://syshwid.blogspot.ru/2014/11/arm.html (именно с этого и началось моё погружение в Linux).
                Поэтому мой путь к системной разработке под Linux очень и очень тернистый. Причём этот путь очень тесно переплетён с реверсом.
                Именно поэтому «getting started» я никак не могу написать, т.к. таким путём никто не отважится идти.
                Да и считаю такие статьи излишними. Лучше уж найти блог системного программиста Linux и почитать его с самого начала. Это самый лучший вариант.
                +2
                Чего только не переживал мой S3. Учитывая отсутствие навыков разработки, вероятность получить кирпич в этот раз как никогда велика
                  0
                  Зря вы так. Вероятность окирпичивания устройства прошивкой кастомного ядра довольно низка (на самом деле я считаю, что таковая вообще отсутсвует). А вот прошивка кастомного загрузчика реально может привести к окирпичиванию. Но и в этом случае можно раскирпичить устройство.
                  0
                  Не отображается ли последний кадр из вывода на долю секунды при разблокировке телефона? В версиях android 2.x был такой баг.
                    0
                    Впервые слышу о таком баге (устройство с Android 2.х имею).
                    Вывод LLCON должен затираться драйвером дисплея, т.к. LLCON работает только с основным FrameBuffer (т.е. без переключения страниц).
                      0
                      Такое было на Galaxy Tab P1000 и Acer Liquid S100.
                    0
                    Del
                      0
                      Знаете, зачем делают заставку при загрузке? Одна из причин — это просто украшательство, но это не основная.
                      Вот тут https://freedesktop.org/wiki/Software/systemd/Optimizations/ почитайте, п.7:
                      «Console output is slow. So if you measure your boot times and ship your system, make sure to use „quiet“ on the command line and disable systemd debug logging (if you enabled it before). „
                      Посмотрев видео, ужаснулся, как же долго загружается телефон. Конечно, не в логах основная проблема, но и в них тоже.
                        0
                        Знаете, зачем делают заставку при загрузке? Одна из причин — это просто украшательство, но это не основная.

                        Как раз таки использование бут-анимации замедляет загрузку. Особенно это заметно на SoC 2013 года, когда анимация использует 25 и более FPS.
                        Бутлого загрузчика ни на что не влияет.

                        Console output is slow… and disable systemd debug logging

                        Это относится только к стандартному FBCON модулю. К модулю LLCON мало относится, т.к. LLCON просто напросто записывает байтики во FrameBuffer.

                        Посмотрев видео, ужаснулся, как же долго загружается телефон.

                        Так используется бюджетный SoC 2013 года (msm8226). Мой тестовый телефон (он же и основной) при замене бут-анимации на вывод логов LLCON стал загружаться быстрее (сравнивал по выводу dmesg).

                        Конечно, не в логах основная проблема, но и в них тоже.

                        Прежде всего дело в медленном SoC.
                        На втором деморолике используется асинхронный вывод логов на дисплей (mode=2), при котором одно ядро SoC задействуется для периодического вывода логов. Поэтому при использовании асинхронного режима может быть замедление загрузки такое же, как и при использовании бут-анимации андройда.
                        При использовании синхронного режима (mode=1) замедление загрузки не должно превышать 0,5 секунд, т.к. LLCON просто пишет в видео-память байтики.
                          +1
                          Телефоны разные бывают. Да и на каждой версии Андроида свои тормоза.
                          30 сек для загрузки среднего смарта — это норма. Не у всех есть даже 2 ядерные модели, не говоря уже и о 4-х.
                          Полагаю тормоза от показа логов максимум добавили 1-2 секунды к общему времени — что не критично.
                          Тем более многим действительно больше нравится видеть реальный процесс загрузки чем просто рисунок, пусть и с анимацией.
                          А для отладки модуль автора — отличная штука!
                            0
                            Я бы предпочёл, чтобы не видеть ни логов, ни какой-то заставки — включил и работаешь. Хотя если не удаётся достичь скорости загрузки в пару секунд — то вывод логов поинформативней будет, несомненно, нежели графическая заставка.
                            90 секунд мой комп загружался с HDD, после перехода на SSD — 20-30с, а после некоторой оптимизации стало заметно быстрей:
                            [avx@localhost ~]$ systemd-analyze
                            Startup finished in 1.385s (kernel) + 1.383s (userspace) = 2.768s
                            Неужели на современных телефонах такая медленная флеш-память?
                          0
                          я помню, как возился в gentoo чтобы поменять логи ядра на красивую анимацию. а теперь в моде вместо анимации иметь логи ядра. мда…
                            0
                            Когда речь заходит о системных программистах, то не может быть никакой речи о моде.
                            А по части обычного обывателя вы конечно правы. Модуль LLCON уже несколько месяцев могут использовать все обладатели телефона Highscreen Boost 2 SE, т.к. этот модуль я внедрил в прошивку. Но при этом пользователь должен установить так же и кастомный загрузчик IBL (создавался при моем участии). Причем устанавливать этот загрузчик нужно не только ради забавы LLCON, а прежде всего для предотвращения окирпичивания при выходе из стоя чипа eMMC (на этом телефоне они умирают очень часто).
                            Так вот уже несколько пользователей откатились на стоковый загрузчик лишь по причине того, что они привыкли видеть стандартную заставку «Highscreen» при старте. При этом они пишут, что для них это важнее, чем «прививка» от окирпичивания.
                            0

                            А где пингвинчики по числу ядер?

                              0
                              У модуля LLCON нет ничего общего с FBCON. Хотя вру, оба используют одни и теже шрифты.
                              Да и не хочется выслушивать что то подобное: https://forum.altlinux.org/index.php?topic=28659.0
                              0
                              Да лучше её совсем отключить.

                              default.prop

                              # Включение (отключение) анимации загрузки 1 — выкл (0 — вкл)
                              debug.sf.nobootanimation=1
                                0
                                Полночи воевал с Nexus 5X, у которого в msm8992-mdss.dts прописано

                                mdss_fb0: qcom,mdss_fb_primary {
                                cell-index = <0>;
                                compatible = «qcom,mdss-fb»;
                                qcom,cont-splash-memory {
                                linux,contiguous-region = <&cont_splash_mem>;
                                };
                                };

                                Предположительно, cont_splash_mem — 0x03401000. Но при включении модуля (первый параметр не 0) загрузка останавливается. Где еще можно поискать адрес? В логах kmsg ничего похожего нет.
                                  0
                                  Предположительно, cont_splash_mem — 0x03401000
                                  Я в этом сомневаюсь. Мне кажется вам нужно смотреть вот сюда: msm8992-bullhead.dtsi
                                  В логах kmsg ничего похожего нет.
                                  Ну как же нету. Посмотрите сюда: dma-contiguous.c

                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                Самое читаемое