Можно ли загрузить телефон Android с USB-накопителя?
Есть ли способ загрузить телефон Android * с USB-накопителя с питанием от шины **? Если да, то какие шаги для этого?
* Например, один с функцией USB OTG.
Пожалуйста, уточните, какова цель и почему?
Телефоны Android имеют свои собственные загрузчики и не могут быть переопределены другими способами.
Это не похоже на BIOS ПК, где вы можете переключать порядок загрузки для загрузки с определенных устройств, таких как Network PXE, USB, Primary / Secondary HDD.
Редактировать:
После комментариев ниже и в связи с вопросом ОП
Есть ли способ загрузить телефон Android (например, с функцией USB OTG) через USB-накопитель с питанием от шины
Базовый загрузчик (* который находится на чипсете) не знает USB и т. Д., Поскольку lk (Little Kernel) больше заботится о том, чтобы перехватывать нажатия клавиш для цепной загрузки в восстановление или для загрузки непосредственно в среду Android (Удерживая клавишу Vol + Down в этом случае) — в псевдокоде ( это из контекста / аспекта lk, а также адреса памяти, относящиеся к чтению разделов, жестко запрограммированы в этом lk, поэтому умеешь обрабатывать логику! )
Ядро lk является стандартом де-факто Qualcomm для наборов микросхем MSM (Snapdragon) и принято такими производителями, как Sony, Motorola, LG, Samsung. Его можно найти в источнике AOSP в разделе bootable/bootloader .
если ( нажата клавиша уменьшения громкости? ), то
- Цепная загрузка ядра из /recovery раздела по определенному адресу в памяти, переход к нему и запуск выполнения при вызове среды восстановления.
еще
- Цепная загрузка ядра из /system раздела по определенному адресу в памяти, переход к нему и запуск выполнения при вызове среды Android.
конец если.
Поскольку ядро в lk довольно ограничено, учитывая, что двоичный образ ядра записан в чип и, следовательно, нет способа его изменить . А также следует отметить , что лк содержит fastboot протокол в рамках подготовки к мигающим /boot , /recovery , /system и /data перегородкам. Есть две последовательности для загрузки: основная загрузка и дополнительная загрузка как есть:
- Первичная загрузка -> lk (в зависимости от результата логики)
- Зайдите в Secondary Boot -> /boot или /recovery
Примечание: Samsung любит PBL / SBL (который является Primary Boot Loader и Secondary Boot Loader соответственно) в их жаргоне, когда дело доходит до моддинга. Что касается Samsung, так это то, что в некоторых телефонах PBL и SBL могут быть зашифрованы (Samsung Wave GT-S8500 является одним из таких примеров, когда портировать Android на него было практически невозможно из-за DRM в загрузчиках, что было кошмаром). иметь дело с моддингом и сделать его чрезвычайно трудным, тем не менее, это своего рода работа через эксплойт в коде FOTA!)
Вот почему нет никаких дополнительных средств, таких как функциональность OTG или что-либо еще, таких как последовательная связь, чтение с SDCard, графика и т. Д., Поскольку это сделает ядро lk больше, чем предполагалось. Другими словами, это наименьший возможный размер ядра, предназначенный для выполнения только что описанного выше псевдокода.
Кроме того , еще один способ смотреть на него это, и это зависит от Android версии — с USB OTG функциональность полностью вывела вверх в Android среды, то есть , когда знакомый появится домашний экран, то функциональность OTG является включена. К сожалению, это не так, если смотреть на это с точки зрения ЛК.
Источник
Запуск ОС Андроид с SD-карты для устройств на процессоре Amlogic S912
В статье детально, с приведением исходного кода, описывается работа, проведенная по переносу и запуску с SD-карты программной прошивки с ОС Андроид для устройств на процессоре Amlogic S912.
Мне нравятся миниатюрные компьютеры, выполненные по технологии система на чипе (SOC). За крошечные размеры и небольшое энергопотребление по сравнению с персональными компьютерами. Используя такие устройства, можно решать широкий круг задач. На миникомпьютеры можно установить как ОС Android (так делает большинство производителей данных «игрушек»), так и различные дистрибутивы Linux или Chrome OS.
Моя текущая работа — это разработка приложений для Андроид. В этой работе очень желательны тесты на реальных устройствах на различных версиях системы. Есть у меня пара миникомпьютеров от компаний Rockchip и Amlogic, на которых я также выполняю свои тесты. Андроид, как операционная система, довольно динамично развивается и сейчас на рынке используются ее модификации от 4.4 до 10 версии. А на подходе уже Андроид 11-й версии.
Многие компании, занимающиеся разработкой телеприставок на базе Андроид, вынуждены иметь недолгий срок сопровождения свои детищ в виду быстрого развития как аппаратных, так и программных средств. Один из моих основных рабочих инструментов для тестов — это приставка KM8P на процессоре S912 с двумя гигабайтами ОЗУ и предустановленной операционной системой Андроид версии 7.1. Время идет, и за пару-тройку лет на рынке последовательно появились версии 8.1, 9.0 и 10.0 ОС Андроид.
Очень хотелось бы потестировать свое приложение под этими самыми версиями. Но что делать? Или нужно покупать зверушки на новых процессорах и версиях Андроид, или заниматься самостоятельной адаптацией новых версий Андроида на имеющихся устройствах. Первый путь легок и прост: заплатив не очень большую сумму, проблема легко решается. Но легких путей мы не ищем, поэтому выбираем второй путь. Второй путь гораздо труднее, но интереснее. К тому же, и сам чип S912 является отличным 8-ядерным процессором, не намного уступающим по производительности новейшим процессорам Amlogic на чипе S905x.
Итак, был выбран второй вариант, как более интересный и отвечающий моим потребностям. Встал вопрос: а каким путем пойти? Текущая версия Андроид 7.1 под капотом имеет ядро Linux 3.14.29 и ПЗУ NAND на чипе SK Hynix H27UCG8T2ETR, для которого Amlogic разработала собственный драйвер aml_nftl_dev.ko.
Все новейшие версии Андроид базируются на ядре 4.9. И желательно использовать именно его. Однако, политика Amlogic такова, что последние несколько лет SDK Android компания предоставляет только юридическим компаниям, занимающимся производством устройств на базе чипов Amlogic.
Тем не менее, на просторах github’а можно найти исходники ядра 4.9 на основе SDK Android от Amlogic 2017-18 года. Например, git-репозитарий компании Khadas. Однако, дело, в том, что драйвер aml_nftl_dev для версии ядра 4.9 отсутствует. Что делать? Адаптировать данный драйвер для ядра 4.9? Но помимо адаптации драйвера, придется также править так называемое дерево устройств ядра. Это трудный путь.
Множество устройств на процессоре S912 имеет более современное ПЗУ с контроллером EMMC. К счастью, для обладателей таких устройств совсем недавно (в июне-июле 2020 года) появились прошивки на Андроид 9, собранные энтузиастами (ознакомиться можно здесь и здесь). Я не мог воспользоваться данными прошивками в виду отсутствия на моем устройстве чипа EMMC. Однако, прекрасно понимал, что имея на приставке слот для SD-карточки, для работы с которым используется все тот же драйвер MMC, что и для работы с микросхемой EMMC, можно попытаться использовать SD-карту вместо ПЗУ.
К сожалению, ситуация осложнялась тем, что Amlogic изначально не предусмотрел старт системы с SD-карты. Тем не менее, кое-что было. Amlogic реализовала возможность обновления прошивок с SD-карты. Эта и другие возможности были достигнуты компанией Amlogic путем существенной доработки загрузчика u-boot под свои нужды. В частности, имеется возможность запустить ядро системы с FAT-раздела SD-карты. Итак, было принято решение выяснить, можно ли адаптировать драйвер MMC для возможности старта с SD-карты. Я погрузился в изучение исходного кода драйвера.
Изучая исходный код, я выяснил, во-первых, что драйвер для монтирования загрузочного раздела ограничивается работой только с микросхемой EMMC, а остальные устройства игнорирует. А такими устройствами как раз является SDMMC-слот и SDIO-порт. А почему бы не изменить код так, чтобы драйвер не пропускал устройство SDMMC, а продолжал бы с ним работать, как с EMMC?
Во-вторых, было определено, что разработчики Amlogic используют собственную структуру данных для хранения таблицы разделов диска и записывают ее по некоторому смещению на диске. Структура данных несложная, в ней хранится смещение, имя, размер и некоторые другие характеристики раздела. После определения типа устройства, драйвер читает таблицу разделов на диске и создает блочные устройства в системе согласно этой таблице.
Получается, что разрешив драйверу работать с SDMMC, как с EMMC и записав таблицу разделов по заранее известному адресу на SD-карте, я смогу, таким образом, сымитировать EMMC и загрузить систему с SD-карты! Подумал, почему бы не сделать утилиту, которая будет записывать таблицу разделов в нужном формате и при необходимости проверять ее корректность. Сказано — сделано. Тем более, что сделать ее было несложно, благо практически вся инфраструктура уже была описана в исходном коде драйвера. Исходный код утилиты размещен на github’е, репозиторий amlpt. Утилита создана в ОС Ubuntu. Но, думаю, при необходимости, ее не сложно будет перенести и на Windows.
Для начала нужно заполнить параметры таблицы разделов в файле mmcparts_a9.c, указав там имена, смещения, размеры и тип разделов. Для обычных разделов указывается тип — 0x1, для разделов типа cache — 0x2, а для разделов типа data — 0x4. За начальное смещение первого раздела я взял значение 0x2800000 (40Мб). Далее заполнил имена, размеры и типы разделов в структурах partitions согласно таблице разделов из дерева устройств. Для 9-го Андроида таких разделов насчиталось 17.
Заполнив данные в файле mmcparts_a9.c, создаем утилиту для записи таблицы разделов, запустив скрипт make_amlptwrt.sh. Данный скрипт создает исполняемый файл amlptwrt, с помощью которого можно сформировать двоичный файл mmc_parts.bin. Это и есть наша таблица разделов, которую читает драйвер MMC. Аналогично запускаем скрипт make_amlptrdr.sh для создания утилиты чтения таблицы разделов amlptrdr, с помощью которой мы можем проверить правильность заполнения данной таблицы. После запуска amlptrdr в консоли отобразится таблица разделов с именами, смещениями и размерами в мегабайтах. Примерно так:
/AML/amlpt$ ./amlptrdr
[mmc_verify_partition_tbl] mmc read partition OK!
show_mmc_partitions
[disk p01] logo offset 40 Mb, size 8 Mb
[disk p02] recovery offset 48 Mb, size 24 Mb
[disk p03] misc offset 72 Mb, size 8 Mb
[disk p04] dtbo offset 80 Mb, size 8 Mb
[disk p05] cri_data offset 88 Mb, size 8 Mb
[disk p06] rsv offset 96 Mb, size 16 Mb
[disk p07] metadata offset 112 Mb, size 16 Mb
[disk p08] vbmeta offset 128 Mb, size 2 Mb
[disk p09] param offset 130 Mb, size 16 Mb
[disk p10] boot offset 146 Mb, size 16 Mb
[disk p11] tee offset 162 Mb, size 32 Mb
[disk p12] vendor offset 194 Mb, size 130 Mb
[disk p13] odm offset 324 Mb, size 128 Mb
[disk p14] system offset 452 Mb, size 1350 Mb
[disk p15] product offset 1802 Mb, size 128 Mb
[disk p16] cache offset 1930 Mb, size 1120 Mb
[disk p17] data offset 3050 Mb, size 4050 Mb
Для того, чтобы драйвер MMC заработал с устройством SDMMC, я внес два небольших исправления в исходный код драйвера, в файл drivers/amlogic/mmc/emmc_partitions.c:
а) Во-первых, разрешаем драйверу работать с устройствами, отличными от EMMC. Для этого меняем функцию is_card_emmc следующим образом:
Конечно, это самое никчемное изменение, которое можно было придумать, но для достижения моей цели этого достаточно. Как говорится, матушка-лень впереди планеты всей.
б) Определяем смещение, по которому будет читаться таблица разделов. Правку делаем в функции mmc_read_partition_tbl:
Если посмотрим на исходный код драйвера, то сумма констант MMC_BOOT_PARTITION_SIZE + MMC_BOOT_PARTITION_RESERVED равна 36 Мб. Следует отметить, что данные правки подходят для моего варианта, когда в устройстве отсутствует чип EMMC или в дереве устройств он отключен. Для других случаев придется придумывать более корректный вариант правок.
Итак, смещение, по которому будет записана таблица разделов на SD-карте равна 36 Мб. Для того, чтобы разместить нашу таблицу разделов, созданную утилитой amlptwrt, на SD-карте достаточно выполнить команду:
При этом предполагается, что /dev/sdb — это SD-карта.
Далее компилируем ядро, создаем boot.img с нулевым initrd и примерно такими параметрами ядра:
Вспомним, что u-boot от Amlogic умеет стартовать ядро Linux c SD-карты с раздела FAT. Создаем на SD-карте в самом начале раздел FAT размером 32 Мб. Этого вполне достаточно для размещения нашего boot.img и dtb.img. В дереве устройств dtb.img необходимо отключить EMMC, чтобы нашей SD-карте было присвоено имя /dev/mmcblk0. Или не отключать, но тогда нужно будет изменить в boot.img параметры ядра, чтобы ядро смогло успешно подключить системный раздел, который в данном случае будет иметь имя /dev/mmcblk0p14.
И, как заключительная часть марлезонского балета, осталось записать разделы Андроид-прошивки на SD-карту. Для этого распаковываем прошивку и записываем на SD-карту подходящие разделы согласно смещениям в таблице разделов:
Те разделы, которые отсутствуют в прошивке, я просто заполнял нулями. Некоторые разделы, такие как system или vendor и некоторые другие, могут являться sparse-разделами. Их предварительно необходимо преобразовать в обычные разделы:
С разделами cache и data нужно поступить немного по-другому. Смотрим нашу таблицу разделов, созданную утилитой amlptwrt, и с помощью программы fdisk создаем соответствующие разделы с нужными смещениями и размерами на SD-карте и форматируем их в файловую систему ext4:
После форматирования, с помощью той же утилиты fdisk, удаляем уже ненужные разделы /dev/sdb2 и /dev/sdb3.
Чтобы загрузчик u-boot распознал, что нужно загрузиться именно с SD-карты, размещаем в FAT-разделе файл aml_autoscript. Сам файл aml_autoscript может быть создан с помощью утилиты mkimage из простого текстового файла следующего содержания:
Вот и все, что необходимо для переноса прошивки с Андроид на борту на SD-карту.
Несколько прошивок, которые были сделаны по данному методу, опубликованы в соответствующей теме на форуме 4PDA. Если что-то непонятно, задавайте вопросы в комментариях. Чем смогу — помогу.
За сим позвольте откланяться и удачи всем в переносе прошивок!
Источник
Андроид не загружается с флешки
Android OS на x86
В этой теме обсуждаются вопросы общие для всех Андроидов на платформе x86, конкретно проект портирования Android-х86, а также его братья, не имеющие отдельных тем обсуждения на нашем форуме.
Android в виртуальную машину | Сайт и Форум проекта Android-х86 | Android от Intel
Вопросы, касающиеся только проектов Phoenix OS , Remix OS x86 и Bliss-x86 , обсуждаются в своих темах.
За работоспособность ваших устройств ответственность несёте исключительно Вы. Задавая вопрос, постарайтесь указать следующую информацию .
- Hardware List — список совместимого оборудования
- Графическое ускорение нормально работает на видеоадаптерах от AMD и Intel (кроме GMA 500, GMA 600, GMA 3600, GMA 3650, т.к. они основаны на PowerVR).
Графика nVidia поддерживается начиная с Android-x86 4.4-R3; новое поколение начинает поддерживаться после выхода следующего. - Ситуация с поддержкой планшетов, Критическое замечание о звуке.
- Чипы, которые реализуют одновременно и WiFi, и Bluetooth работают хуже, чем отдельные.
- Если Вы не нашли в шапке или в листе совместимости версию для вашего компьютера/ноутбука (модификации железа), то следует попробовать разные версии и опытным путём подобрать оптимальную.
- Загрузочную флешку или диск необходимо записать с помощью Rufus, UNetbootin, LiLi, или WinImage. UltraISO использовать не рекомендуется потому, что созданные им флешки мало где грузятся.
Раздел под Android рекомендуется форматировать в ext3 или ext4 (для версии 5.0 Lollipop и новее) чтобы иметь >4ГБ места под свои нужды и избежать проблем с SuperSU и другим софтом. Форматирование раздела лучше произвести до установки Android сторонним ПО (Acronis, GParted, др.): родной установщик не всегда справляется с этой задачей.
title Android-x86 5.1-rc1
kernel /android-5.1-rc1/kernel quiet root=/dev/ram0 androidboot.hardware=android_x86 SRC=/android-5.1-rc1
initrd /android-5.1-rc1/initrd.img
title Android-x86 5.1-rc1 (Debug mode)
kernel /android-5.1-rc1/kernel root=/dev/ram0 androidboot.hardware=android_x86 DEBUG=2 SRC=/android-5.1-rc1
initrd /android-5.1-rc1/initrd.img
title Android-x86 5.1-rc1 (Debug nomodeset)
kernel /android-5.1-rc1/kernel nomodeset root=/dev/ram0 androidboot.hardware=android_x86 DEBUG=2 SRC=/android-5.1-rc1
initrd /android-5.1-rc1/initrd.img
title Windows
rootnoverify (hd0,1)
chainloader +1
Тут default указывает номер пункта, котоый будет выбран автоматически после истечения timeout секунд. root и rootnoverify указывают с какого диска, и с какого его раздела загружать выбраную операционную систему. Как и в случае с default, нумерация начинается с нуля. Параметры загрузки прописываются в конец строки, которая начинается со слова kernel. Такими параметрами можно повлиять на многие аспекты работы Андроида с железом. К примеру настроить работу с внешним монитором.
GRUB 2 — следующая версия GRUB. Разработчики писали GRUB 2 «с нуля», чтобы добиться переносимости и модульности.
Используется в образах Android-x86 для компьютеров с новым UEFI-BIOS.
Может хранить свои настроки в файле grub.cfg либо menu.lst. Обычно этот файл лежит на отдельном системном разделе EFI (ESP). Типичное содержимое:
set timeout=60
set gfxmode=1024×768
terminal_output gfxterm
Источник
