Мне интересно, какова последовательность загрузки Raspberry Pi в типичной настройке (скажем, NOOBS), от приложения питания (или горячего сброса, если это не так) до, скажем, появления логотипа; или где это описано.
Помимо самой необходимой общей картины этой последовательности, меня больше всего интересуют ранние стадии:
- Что такое вектор сброса для процессора ARM, и как / где это определяется?
- Из какой памяти извлекаются первые инструкции процессора ARM? Где это и какие технологии используются для хранения этого кода?
- Это код ARM32 или Thumb (или, возможно, Jazelle)? Это зависит от младшего бита вектора сброса?
- Доступен ли исходный код (или разборка, или дамп) этого раннего загрузочного кода? Если нет, то что-нибудь техническое препятствует использованию порта JTAG для определения этого? Что касается юридического, я готов взять на себя риск доверять моему пониманию законодательства, применимого в том месте, где я живу (Франция), а именно, что я полностью могу анализировать свой собственный компьютер, по крайней мере, в отсутствие явного договорного Требование не делать этого.
- В каком порядке инициализируются периферийные устройства и каким фрагментом кода?
- Помимо процессора ARM, есть ли в BCM2835 какие-либо процессоры / автоматы, и положительно, как их последовательность загрузки связана с процессором ARM?
Я готов нырнуть в процессоре ARM в Техническом справочном руководстве и BCM2835 ARM Периферийных устройств , или любой другой документ.
Обновление: после публикации я обнаружил, что это и это , утверждая, что графический процессор BCM2835 действует как мастер для ARM и активно участвует в последовательности загрузки.
Ответы:
Последовательность загрузки Raspberry Pi в основном такая:
bootcode.bin
. Включает SDRAM и загружает этап 3loader.bin
. Он знает о.elf
формате и нагрузкахstart.elf
start.elf
грузыkernel.img
. Затем он также читаетconfig.txt
,cmdline.txt
иbcm2835.dtb
если файл dtb существует, он загружается в0×100
& kernel @.0×8000
Еслиdisable_commandline_tags
установлено, загружает ядро @.0×0
В противном случае он загружает ядро @0×8000
и помещает ATAGS в0×100
kernel.img
затем запустить на ARM.Все работает на GPU, пока не
kernel.img
будет загружен на ARM.Я нашел эту диаграмму довольно полезной:
источник
bootcode.bin
кодом, запускаемым графическим процессором, ARM (и затем каким типом кода), или их комбинацией? То же самое для 3-го этапаloader.bin
(если это не так, как кажется).kernel.img
которого запускается на ARM.loader.bin
больше не используется.bootcode.bin
непосредственно загружает вstart.elf
соответствии с этим Git commit