Comments 29
UFO just landed and posted this here
TARGET_DEVICE для Nexus S действительно crespo. Но нас интересует TARGET_BOOTLOADER_BOARD_NAME. Когда вы выполняете команду lunch full_crespo-eng, система определяет опции, которые надо использовать при компиляции для этой платформы (эти опции находятся в BoardConfig.mk). TARGET_BOOTLOADER_BOARD_NAME находится именно там. Хотя я не очень хорошо знаком с системой компиляции, так что мог что-то напутать.
Радует, что цикл статей не закончился на первой)
Сам с недавних пор разрабатываю под Android, так что ваши статьи очень кстати. Спасибо.
Сам с недавних пор разрабатываю под Android, так что ваши статьи очень кстати. Спасибо.
Я постараюсь, чтобы он продолжался )
Здесь пару дней назад один автор выбросил цикл статей по asp.net. И хотя я уже давно не интересуюсь этой темой поставил плюсы автору, где только смог, потому что теперь представляю, какую работу он проделал. Как раз там в комментариях был поднят вопрос, как надо делать — выбрасывать ли всё полностью и сразу или писать по чуть-чуть. Так вот мне кажется, что я бы не смог написать всё сразу — просто бы не хватило терпения и запала. А так, даже если и заброшу написание, уже очень много останется информации, которую найти очень сложно (именно поэтому я так часто употребляю «мне кажется», «я думаю» и т.д. — это просто мое представление, как работает система). Просто у меня на одну статью уходит где-то 6-8 часов и это без учета времени ночью и в дороге, когда я обдумываю структуру и различные интересные моменты, которые надо описать.
Хотя свои цели при написании этих статей я тоже преследую. Во-первых, мне очень важно оценить правильность моих рассуждений. Во-вторых, возможно появятся новые мысли в какую сторону дальше делать ресерч. В-третьих, эти статьи структурируют информацию, которая находится в голове и которая, конечно же, забывается, если её не повторять. А так, когда есть статья, всегда можно вернуться к ней и освежить свои знания.
P.S. А Вы разрабатываете под Андроид или копаетесь с самой операционной системе?
Здесь пару дней назад один автор выбросил цикл статей по asp.net. И хотя я уже давно не интересуюсь этой темой поставил плюсы автору, где только смог, потому что теперь представляю, какую работу он проделал. Как раз там в комментариях был поднят вопрос, как надо делать — выбрасывать ли всё полностью и сразу или писать по чуть-чуть. Так вот мне кажется, что я бы не смог написать всё сразу — просто бы не хватило терпения и запала. А так, даже если и заброшу написание, уже очень много останется информации, которую найти очень сложно (именно поэтому я так часто употребляю «мне кажется», «я думаю» и т.д. — это просто мое представление, как работает система). Просто у меня на одну статью уходит где-то 6-8 часов и это без учета времени ночью и в дороге, когда я обдумываю структуру и различные интересные моменты, которые надо описать.
Хотя свои цели при написании этих статей я тоже преследую. Во-первых, мне очень важно оценить правильность моих рассуждений. Во-вторых, возможно появятся новые мысли в какую сторону дальше делать ресерч. В-третьих, эти статьи структурируют информацию, которая находится в голове и которая, конечно же, забывается, если её не повторять. А так, когда есть статья, всегда можно вернуться к ней и освежить свои знания.
P.S. А Вы разрабатываете под Андроид или копаетесь с самой операционной системе?
Хорошая статья, как раз в тему того, что я сейчас пытаюсь провернуть с китайским планшетом. Не могли бы вы подсказать, что лучше посмотреть на тему начальной загрузки Android-устройств и модификации загрузчика? Суть в чем: есть девайс Gadmei E6 (построен на весьма распространенном чипе Allwinner), я хочу сделать, чтобы он мог грузиться только с microSD карты. Чип в нем устроен как вы описали — начинает загрузку с определенного адреса, потом тащит u-boot, который потом уже загружает систему. На данный момент мне не хватает какой-то структурированной информации о загрузчиках — в интернете все весьма разрозненно и максимум чего я добился — это то, что устройство подвисает на загрузке =)
К Embedded Android я обязательно обращусь, а что еще можете посоветовать?
К Embedded Android я обязательно обращусь, а что еще можете посоветовать?
UFO just landed and posted this here
Спасибо. Очень интересно. Жду продолжения.
Хочу заметить, что большинство ARM процессоров в Android девайсах сами по себе в рабочее состояние не включаются. Поэтому при подаче питания сначала запускается видео-карта (в мобилках видеокарты обычно полноценные APU с заблокированным блоком этого самого APU), с определённого места читает свой собственный бутлоадер, который уже вводит CPU в работу, говорит ему откуда брать его родной бутлоадер и т.д. У nVidia даже есть тулза — nvflash, которая позволяет управлять всем этим процессом.
Я не знаком с такими низкоуровневыми технологиями. Вообще, про загрузку я написал для того, чтобы объяснить, как она происходит в моем понимании, а также показать основные её этапы. Они, в общем-то, необходимы для понимания архитектуры системы. Ну и если бы раньше кто-то что-то подобное написал на Хабре, то я бы ему был очень-очень благодарен, а так приходилось по крупицам собирать знания.
Спасибо Вам за уточнение, пополнил свои знания ) Хотелось бы спросить, а такой процесс запуска характерен только для SOC на базе nVidia или для других SOC тоже? Может эти требования есть в спецификации архитектуры?
Спасибо Вам за уточнение, пополнил свои знания ) Хотелось бы спросить, а такой процесс запуска характерен только для SOC на базе nVidia или для других SOC тоже? Может эти требования есть в спецификации архитектуры?
Поэтому при подаче питания сначала запускается видео-карта
Что-то очень странное вы написали. Возможно трудности перевода? Процессор всегда инициализируется первым, выполняет свой BootROM, который загружает bootloader, который потом загружает ядро операционной системы. Видеокарта тут вторична. Её может инициализировать bootloader, а потом ядро. А часто видеокарты нет вообще, зачем она, например, в роутере?
Вот тут описан процесс загрузки типичного ARM-процессора. Могу ещё на Freescale i.MX51 доки (выдержки) кинуть, одно время я с ними поковырялся прилично.
Попробуйте инициализировать Raspberry Pi без GPU (:
Raspberry Pi — это микрокомпьютер, а вы писали про ARM-микропроцессор. Это разный вещи.
И кроме того, да — ничто не мешает инициализировать этот Пи без GPU. Именно так я и делал, когда устанавливал Android на плату с i.MX51. Система загружалась (при чёрном экране), а я через текстовый терминал на последовательном порту смотрел сообщения загрузчика, ядра и Android-а, и пересобирал, перепрошивал, опять смотрел, и так, пока не добился работоспособной (почти) системы.
И кроме того, да — ничто не мешает инициализировать этот Пи без GPU. Именно так я и делал, когда устанавливал Android на плату с i.MX51. Система загружалась (при чёрном экране), а я через текстовый терминал на последовательном порту смотрел сообщения загрузчика, ядра и Android-а, и пересобирал, перепрошивал, опять смотрел, и так, пока не добился работоспособной (почти) системы.
Еще раз — большинство SOC на ARM в мобильниках инициализируются через GPU внутри. Это факт.
Ну тогда либо давайте ссылку на документацию, либо это не факт, а фейл.
www.raspberrypi.org/phpBB3/viewtopic.php?f=72&t=29944
Ссылку про тегру и квалком сходу не найду. Бут лоченный на тегре ломают через гпу, ибо там код срабатывает до цпу и можно натворить дел.
Тащемта гугл ит.
Ссылку про тегру и квалком сходу не найду. Бут лоченный на тегре ломают через гпу, ибо там код срабатывает до цпу и можно натворить дел.
Тащемта гугл ит.
Aux, спасибо что зацепили, пришлось искать документацию, узнал очень много интересного. Это тема для отдельной статьи.
Но вкратце, действительно можно говорить о том, что на некоторых SoC загрузкой управляет GPU (?!). Только это будет не совсем точно (технически).
Для Raspberry Pi вот что получается. Есть основной процессор (CPU) ARM1176JZF-S, есть графический сопроцессор (GPU) VideoCore IV® Multimedia Co-Processor, внутри (на территории) которого есть маленький сопроцессор, который управляет начальной загрузкой и также обеспечивает многие системные функци. Тут процесс загрузки описывают так:
Таким образом, на мой взгляд, корректным определением было бы такое: «Начальной загрузкой управляет сопроцессор, находящийся в VPU»
У Qualcomm ещё интересней:
С Tegra-ми инфы больше:
Но вкратце, действительно можно говорить о том, что на некоторых SoC загрузкой управляет GPU (?!). Только это будет не совсем точно (технически).
Для Raspberry Pi вот что получается. Есть основной процессор (CPU) ARM1176JZF-S, есть графический сопроцессор (GPU) VideoCore IV® Multimedia Co-Processor, внутри (на территории) которого есть маленький сопроцессор, который управляет начальной загрузкой и также обеспечивает многие системные функци. Тут процесс загрузки описывают так:
At power-up, the CPU is offline, and a small RISC core on the GPU is responsible for booting the SoC, therefore most of the boot components are actually run on the GPU code, not the CPU.На картинке FIG. 1B видно, что внутри Video Processing Core (на который часто ссылаются, как на GPU), есть ещё один блочёк, который тоже называется GPU — собственно та часть, которая обрабатывает 3D-графику и имеет право так называться.
Таким образом, на мой взгляд, корректным определением было бы такое: «Начальной загрузкой управляет сопроцессор, находящийся в VPU»
У Qualcomm ещё интересней:
There are two processors in the MSM 7x30, an ARM9 for the radio and an ARM11 auxiliary applications processorи далее
The ARM9 running REX loads the eMMC «hboot» partition into memory at 0x8D00000 (virtual) and starts the ARM11 auxiliary applications processor executing at this location.Таким образом можно сказать, что начальной загрузкой управляет сопроцессор радиомодуля!
С Tegra-ми инфы больше:
A co-processor known as the AVP (Audio-Video Processor), or sometimes by its legacy name, COP. This processor implements the initial boot process. This processor need not be the same architecture nor implementation as the main CPU complex; on all current Tegra variants, it is an ARM7TDMI.и
When Tegra is powered on, the AVP executes code from the boot ROM. The main CPU complex is not started.Т.е. тут загрузкой занимается сопроцессор, входящий в состав Аудио-Видео-Процессор-а.
Классно! Вы, действительно, провели отличное исследование! Я потом добавлю ссылку на Ваш комментарий в статью. Единственный вопрос, который меня беспокоит, зачем? Может это как-то связано с безопасностью, с залоченными бутлодерами?
зачем? Может это как-то связано с безопасностью, с залоченными бутлодерами?Мне тоже очень интересно. На забугорных форумах этот вопрос довольно активно обсуждается, выдвигаются разные версии. Например такая. Что это связано с безопасностью и защитой know-how технологий от чужих глаз. Дело в том, что спецификации ARM ядер доступны всем лицензиатам, а вот проприетарные видеоядра — это тайна за семью печатями, соответственно если производителю нужно что-то «спрятать», то это лучшее место, где это можно сделать. Косвенно эту теорию подтверждает тот факт, что на SoC-ах с открытым (лицензируемым) видеоядром (PowerVR, Manli) процесс загрузки отличается.
А по поводу настоящей безопасности, то ARM (и некоторые лицензиаты — AMD, Samsung) активно продвигают технологию TrustZone, аппаратно поддерживаемую современными ARM-ядрами. Позволяет, в том числе, и обеспечить безопасную загрузку. Пока она не особо используется, но попытки есть — "Android app taps secure resources via ARM TrustZone" и Samsung Galaxy S3 may be the first smartphone with full ARM TrustZone support for enabling 100% security in everything online.
UFO just landed and posted this here
Скорее всего вместо
переформатировать всё устройстводолжно быть «стереть всю страницу». Т.к. по приведённой ссылке написано
MTD device sectors must be erased before rewriting — which is why they are more commonly called erase-blocks.а в http://www.linux-mtd.infradead.org/doc/nand.html
One major problem for using NAND Flash is, that you cannot write as often as you want to a page. The consecutive writes to a page, before erasing it again, are restricted to 1-3 writes, depending on the manufacturers specifications.
Спасибо за статью. Как раз в данный момент занимаюсь портированием CyanogenMod 10.1 на новое устройство, возникла проблема с рамдиском-не монтируется системный раздел. Начал разбирать скрипты, в ходе разборки у меня возник впопрос: зависит ли порядок выполнения скриптов от порядка в котором они импортируются?
То есть, на примере init.rc:
import /init.usb.rc
import /init.${ro.hardware}.rc
import /init.trace.rc
import /init.carrier.rc
Сначала выполнится init.usb.rc, затем init.${ro.hardware}.rc и тд. или как?
То есть, на примере init.rc:
import /init.usb.rc
import /init.${ro.hardware}.rc
import /init.trace.rc
import /init.carrier.rc
Сначала выполнится init.usb.rc, затем init.${ro.hardware}.rc и тд. или как?
Насколько я помню, в конец init.rc добавятся последовательно комманды из init.usb.rc, init.${ro.hardware}.rc, init.trace.rc, init.carrier.rc и т.д. Т.е. сначала выполняться комманды из init.rc, а потом последовательно комманды из всех импортируемых файлов.
Спасибо, да, все-таки видимо так оно и есть, судя по:
Я сначала как-то не догадался в readme поискать
import <filename>
Parse an init config file, extending the current configuration.Я сначала как-то не догадался в readme поискать
Sign up to leave a comment.
Основы безопасности операционной системы Android. Native user space, ч.1