кто загружает файлы «bootcode.bin, start.elf, ...» ?

Берешь TRM к процу/соку и смотришь кто где и чё берет. Это касательно как загрузка идет. Касательно что грузится - ну типичный (или не очень) бутлоадер. Для почти всех армов это обычно связка [маленьки бутлоадер] + U-Boot. задача маленького бутлоадера минимально инициализировать ключевые компоненты, например контроллер памяти(сам он грузится обычно в SRAM, которой на соке буквально килобайты, обычно от 32к до 256к). Но это то шо касается современных Cortex A5/7/8/9/15.

получается какой-то аналог компьютерного биоса? (программный код которого намертво прошит прямо внутрь SoC ?).

интересно просто, что этот «биос» (так назрвём его в ковычках) — считывает файловую систему SD-карточки (fat32) и считывает из этой файловой системы файл загрузчика (bootcode.bin), а ,например, НЕ передаёт управление коду из самого первого сектора SD-карточки.

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

Raspberry Pi boot process

• The GPU starts executing the first stage bootloader, which is stored in ROM on the SoC. The first stage bootloader reads the SD card, and loads the second stage bootloader (bootcode.bin) into the L2 cache, and runs it.
• bootcode.bin enables SDRAM, and reads the third stage bootloader (loader.bin) from the SD card into RAM, and runs it.
• loader.bin reads the GPU firmware (start.elf).

ведь считывать самый первый сектор — на мой взгляд было БЫ решение более простое

Наверное из-за такого количества стадий загрузки и было принято решение размещать бинарники в файловой системе.

Если бы вендор мог, он бы упростил процесс, но т.к. GPU не его, то пришлось извращаться. Если бы GPU не участвовал в загрузке, то пришлось бы ставить что-то типа BIOS, что привело бы к удорожанию устройства.

GPU — это «видеокарта» чтоле? (в ковычках, потому что всё внутри одного чипа SoC).

«видеокарта» занимается начальной загрузкой железки?

офигеть..

что за изврат такой?

это точно — нормально? :-)

Если бы GPU не участвовал в загрузке, то пришлось бы ставить что-то типа BIOS, что привело бы к удорожанию устройства.

раньше помню на персональном компьютере — на плате звуковой карты — производители размещали +ещё и порт для игрового контроллера...

(хотя если подумать — какая может быть связь между звуковой картой и игровым контроллером? :-))

ну а эти (производители embedded-железок) — разместили «биос» внутри «видеокарты».. тоже «2 in 1» :)

получается какой-то аналог компьютерного биоса? (программный код которого намертво прошит прямо внутрь SoC ?).

Нет. Аналог х86 биоса это U-Boot. Это называется ромкод. Да он намертво вшит в сок

ясно, спасибо.

а ещё вопрос можно?.. он немножно оффтопик, относительно этой темы.

U-Boot способен запустить немодифицированный образ ядра? (то есть — формат не uImage, а тот образ который был до uImage).

например в каком-нибудь там config.txt — мы пропишем отдельно название файла образа ядра (не uImage формата) и отдельно название скомпилированного файла дерева устройств. есть такая возможность?

Да. юбут умеет штатно читать конфиги с раздела или с фата. Тока текстовичек утилиткой компильнуть в бинарь надо :-)

«биос» внутри «видеокарты»

Для RPI решение отличное. Современные GPU занимаются самоинициализацией, скрывая весь процесс чтобы защититься от реверсного инженеринга. Раз уж железка сама разгоняется, почему бы не использовать ее ресурс, чтобы сделать всю плату дешевле.