> Ну, время непосредственно загрузки кода из NAND ребята учли отдельноДа, не входит: для основной части чтения нанда, как то копирование линуксного ядра в раму они померяли отдельное время. Время копирования X-loader'а в RAM бутромом сильно меньше и видимо было включено в "время инициализации железа", ибо там работает bootROM и отделить где он там закончил инициализировать железо и начал копирование нанда в рам - скорее всего не особо то и просто :).
А вот время которое уже X-Loader читает линуксовое ядро в RAM - они померяли. Там все как-то проще, ибо своего X-Loader'а можно попросить в нужный момент что-то характерное и простое в измерении сделать.
> Не знаю, к сожалению, что навернули техасцы именно в этом чипе,
Техасцы вполне себе выложили даташит на омап3/4. Как ни странно. Можно просто пойти и почитать, если интересно. Правда описание "секурной" загрузки они честно выпилили (при том в новых версиях почему-то еще масштабнее чем в старых).
> но их же dsp-чипы, например, относительно медленно стартовали за счет того,
> что все параметры по-умолчанию были "выкручены" на минимум.
Я не вижу принципиальных проблем ввинтить параметры на максимум где-то в первых же инструкциях... только вот много-много "первых инструкций" будут там не ваши а техасского бутрома. А вы сможете что-то изменить лишь когда бутром отдаст процессор вам на растерзание, не раньше. При том он делает довольно много всего, нужного и не очень, ряд операций имеет ощутимые таймауты и прочая. Откуда и напрашивается способ скостить это время - есть режим быстрой загрузки когда ром делает минимум операций и быстро прыгает в NOR-флеху на CS0 без лишних проверок. Режим максимально приближенный к "классическому старту" обычной "классической" системы (с классической шиной адреса и данных и девайсом с правильным кодом в нужных адресах с которых проц тянет первые команды). При этом можно инициализировать только ту периферию которая нужна, делать только нужные операции и не ждать таймаутов, етц, етц. А бутром делался из соображений максимальной универсальности загрузки - от старта с MMC карты до загрузки через USB. Ессно он делает уйму разных действий по этому поводу.
> И это логично, поскольку им неизвестно с каким именно железом придется работать,
> поэтому всё ворочалось на очень низких частотах
Сами по себе частоты можно поднять чуть ли не первыми командами своего кода. После того как он запустится. Не вижу в этом фатальной проблемы - если код заранее знает параметры железа, он может грубо и влобовую прописать заведомо известные ему параметры и с этого момента работать на той скорости которую позволяет по максимуму конкретное железо.
> (при том, что там нет уж очень хитрого auto-detect'a устройств и т. п.).
А вот бутром у техасцев сделан довольно навернутым. Вплоть до взаимодействия с техасским чипом управления питания умеет, чтобы например питанием юсб рулить если с юсб вдруг грузиться захочется. Я так понимаю что при горячем ребуте можно не инициализировать чип питания + возможно избавиться от попадания в бутром или сильно сократить время в оном. Ну и ессно всяких там времен на заряд конденсаторов при горячем старте нет.
> Правда они же и дали возможность это все преодолеть - можно было прямо
> в начало прошивки добавить значения для разных регистров и они применялись ДО начала
> загрузки
Судя по описальнику, у этого сигнальника тоже был boot ROM который читал эти значения, применял их и потом начинал грузить код. В общем то этой технологии - сто лет в обед, а техасцы вероятно применяют похожие подходы в разных чипах. Стиль мышления инженеров врядли меняется на 180 градусов вот так запросто.
> В этих чипах, случайно, ничего подобного нет?
В принципе там есть возможность задать некие параметры специальной формировкой образа. Бутром распарсит и кой-что может поменять. Но я предложил еще более брутальный и эффективный метод - можно отказаться от услуг бутрома по максимуму, почти сразу прыганув в внешнюю NOR флеху и оттуда уже инициализируя только то что реально надо, минимизировав инициализацию, избавившись от таймаутов и лишних действий бутрома, подняв параметры в самом начале до максимальных и прочая. Я так понимаю что техасцы сделали подобный режим специально для таких случаев+это эмуляция загрузки в классическом олдскульном стиле с классической олдскульной шины с почти всеми свойствами оной, как то проц почти сразу после включения - под ВАШИМ контролем, а не какого-то там техасского рома который делает то что было задумано техасцами и при том врядли техасцы сильно упирались по части минимизации именно времени старта в ROM. Скорее, они упирались по части универсальности ака загрузки отовсюду. Что расширяет выбор загрузочных устройств -> процу в плюс (можно делать систему из того что есть :D).
> Или из каких-нибудь соображений "секьюрности" это убрали?
До некоторой степени АФАЙК бутром техасского проца умеет парсить некоторые параметры. Для секурности они поступают проще - проверяют подписи загрузчика. Если подпись не совпала, загрузчик запущен вообще не будет как я понимаю. Сами техасцы "немного забыли" документировать что там у них с секурностью и можно только гадать. Там и тут вылезают забавные останки от этого режима даже в "несекурных" девайсах. Где-то у них ус отклеился и видимо "секурные" и "не секурные" чипы - это физически один и тот же проц, только с разной конфигурацией фьюзов + может еще что по мелочи. Техасцы как-то не очень это освещают, общедоступный даташит описывает только "несекурные" варианты чипов.
> Еще, конечно, возможное отличие в том, что встроенный их bootloader
> в dsp инициализировал только то, что нужно для загрузки, да и то по-минимуму
В OMAP конечно тоже есть DSP и даже еще ряд менее крутых процессоров, но он там весьма дополнительный и поэтому я тут сугубо о том что делает ARMовское ядро омапа, линукс один фиг на нем грузится, именно оно выполняет код бутрома после включения и активность проца в целом после включения - определяется именно этим ромом и этим ядром. Ну я и предложил как можно максимально укоротить время пребывания в бутроме и почти сразу прыгнуть в свой код в NOR флехе. У дспшников поди нет такого режима загрузки - у них мерзкая гарвардская сущность же во весь рост, с делением на памяти данных и программ. У арма такое деление есть только с точки зрения кешей, но для внешнего мира это не гарвардец а неймановец, поэтому у него логически 1 адресное пространство на все. Сие позволяет ему грузиться с классической внешней шины в олдскульненьком таком режиме, в духе того как процы стартовали с ROM на внешней шине, где ROM был вывешен по "правильным" адресам шины :). OMAP умеет этот режим и бутром как я понимаю валит в него почти сразу, весьма близко эмулируя поведение "классических" систем. Что там дальше код в флехе сделает - да его дело. При этом "техасского бутлоадера" по сути нет (он крайне быстро отдает "не глядя" управление во флеху) - есть код в флехе. По сути вместо него. И если цель быстро грузануться, вот этот код уже можно фигурно опилить для максимальной скорости загрузки, как то например если у вас не техасский чип управления питанием - то и переговоры пытаться вести не надо, если вы не хотите бутаться с уартов и юсб - ну и таймаутов тогда ждать не надо, етц, етц, етц :).По сути это возможность отобрать у бутрома управление на весьма ранней стадии. Техас утверждает что это возможно только в "несекурных" вариантах процов, кстати (т.к. управление передается коду в флехе не глядя, это, очевидно, нагибает проверку подписей по полной :D).
> инициализация всего остального была задачей приложения (ну или 2nd stage loader'a)
В описанном мной режиме fast boot можно считать что "техасского рома" почти нет в природе, а есть "тупой проц" и есть "классическая шина" (с линиями адреса и данных). Проц может бутануться с флехи на этой шине. Весьма быстро. И не копируя ничего в раму, т.к. данная шина адресабельна напрямую: запрос на чтение по адресу эн ... транслируется в соответствующее состояние линий адреса и данных, флеха выдает данные, что чертовски логично и позволяет процу напрямую выполнять код из устройств типа NOR флехи [в старые времена на шинах такого плана висел настоящий ROM] :). Подозреваю что у дспушников так не катит из-за деления на программы и данные (гарвард же) и поэтому они наверное не умеют грузиться в "классическом" виде с "классической" шины.
Вариант для распечатки
(??) on 14-Апр-11, 13:55 
