Boot Baremetal application from QSPI flash, on Altera SoC Development Board Опции

[WitFed]

Привет всем из раздела "Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Среды разработки - обсуждаем САПРы" (http://electronix.ru/forum/index.php?showforum=5) !
Там народу поменьше, спецы по другим областям обсуждают Квартус, и решил я, недоARMпрограммер за 2 месяца, обратиться в более людное место, вдруг счастья и гуру тут поболе !
Вот ссылки на мои вопли: http://electronix.ru/forum/index.php?showtopic=121120, http://electronix.ru/forum/index.php?showt...t&p=1254953. Тут я перешерстил всё за 3 часа и во "взрослом" ARM -- нет похожей тематики.

Купили мы "в одном флаконе" (rocketboards.org/foswiki/Documentation/AlteraSoCDevelopmentBoard) ПЛИС и 2 проца ARM-Cortex-A9 за хорошие деньги, масса периферии всякой, но пока не удаётся главное -- чтоб стартовало наше целиком самописное приложение из флэши, несмотря на многочисленные намёки в документации, бахвальство народа по форумам и смотря на отсутствие конкретного алгоритма нигде
Там в комплекте есть SD-карточка, из неё прекрасно и долго стартует Линух, но очень хочется чего-то полностью своего, без непонятных мегатонн кода, и из любой флэши.
...Ну и книжку хорошую на нашем языке по всем ARMам сразу, тут на форуме ж полно материала для научных обобщений! Думаю, участники даже скинутся на такой мегапроект!

У Альтеры есть образец программы hwlib.axf, который моргает диодиками, будучи загружен через отладчик ARM DS-5 (Altera Edition) и стартован, всё более-менее работает, кроме кучи мелких пакостных особенностей, а вот зашиваешь приложение во флэшь -- зацикл на векторе прерывания 1.
Система загрузки в этой AE такова: жёсткий BootROM на 64К с адреса 0, он что-то инитит в процессоре, потомв зависимости от замкнутости 3х внешних ног вызывает Preloader из некоторой флэши в 64К ОЗУ FFFF0000 (он инитит более большие RAM и пускает следующую стадию; исходники Прелоадера уже есть на базе стандартного u-boot, компилятся в u-boot-spl.axf -- second program loader). И этот Прелоадер должен грузить 3ю стадию с адреса и девайса, что ему указано в особом h-нике. Хорошо им грузится u-boot, а мой/Альтерный пример hwlib -- никак.
Я поставил перед пуском 3й стадии бесконечный цикл, включаю плату, подключаюсь туда отладчиком, прыгаю на следующую строку после зацикла, там прыг на адрес 02000000 загруженного приложения -- и кирдык команд через 8 стартапных в asm, на вызове SVC 0x123456 (ранее была SWI, как много где пишут, software interrupt, supervisor call). Идёт прыжок на адрес FFFF0008, где вечный зацикл, ибо из 8 векторов задан только первый, резетный, остальные циклят сами в себе. Причём бит расположения прерываний lo/hi в системном регистре указывает на таблицу прерываний по адресу 0! И даже если глянуть на адрес 0, там те же проблемы -- 1е прерывание обслужено вектором, остальные циклят.
Получается, что системный вызов упирается в неназначенный обработчик, который явно должен был быть назначенным в u-boot-spl.axf на 2й стадии, ибо в моём hwlib ещё очень и очень ранняя фаза загрузки. Это я только сегодня допёр, глядя как рыба об лёд на свои проблемы. Ну или в BootROM дожно быть нечто такое, хотя по логике он мало знает о dest приложениях, вряд ли сможет их обслужить. Плюс описания сервиса по SVC я не встретил нигде пока.
В моём приложении по адресу 02000000 тоже есть 8 обработок прерываний, но они также ограничиваются первым резетным, да и не могли ещё вступить в действие никак за 8 команд!
И самый Склиф состоит в том, что при запуске чисто моего hwlib-приложения под отладчиком вся эта многостадийная хрень стартует успешно!
Какие есть идеи, где собаки роются и как шаманят ? Разве сам отладчик может быть обработчиком запросов системного уровня ? Это же противоречит любым разумным предположениям, ибо наш код должен работать и самостоятельно, отладчик лишь приближает к этой ступени!
Пробовал также грузить тот же самый код Прелоадера, настроенного для дальнейшей работы из QSPI-флэши, из отладчика, доводить его до конечного перехода, там те же 8 команд -- и зацикл.
Во флэши у меня hwlib лежит абсолютно правильно -- выгружал память с 02000000 наружу во всех случаях, различий нет что при хорошем, что при плохом вариантах. Так же и с Прелоадерными кодами по адресу FFFF0000.
Мож какой-то другой отладчик посоветуете, чтоб работал по JTAG с нашим ПЛИС-ARM-ом ?

[WitFed]

Она-то разжёвана, но на другом уровне -- что в какой битик и регистр попадает при вызове, и как возвращаться обратно.
А вот смысл значений в регистре r0 (16) и регистре r1, которые заполняются перед вызовом "SVC 123456" на 8й исполняемой команде моего файла hwlib.axf, и самого этого 123456, мне пока не встретился нигде.
Там же на дороге народ вешает крючочек с попыткой продать нам платную версию компилятора вместо lite, которая ограничивает стек с кучей в сумме до 64К. Вдруг и DS-5 в этом замешана...
Т.е. похоже по дизассемблингу, что в r0 № функции, в r1 -- адрес, сама функция вертает что-то отрицательное при неудаче, а при удаче из того адреса можно будет получить результаты вызова семихостинга, типа адрес стека, начало кучи, назначить их в глобальные места...
И неясно, кто эти API-стандарты придумывает, ARM или Altera, или даже rocketboards, как производитель платы.
У меня в коде штук 10 вызовов этой самой "секретной добавки" "SVC 123456" с кодом EF123456 ! И ещё незнамо сколько всего без исходников, а из безмозглых либ...
Начал думать, как бы вообще подменить всё своими текстами, ибо иметь дело с непознанным в силу неописанности (Doxygen-овые приблуды в отдельном каталоге в расчёт не беру, они к исходникам ничего не прибавляют) очень тяжко который месяц.
Интересную особенность обнаружил сегодня -- если в успешно пускающемся непосредственно из DS-5 приложении написать в окне отладки команду "set semihosting enabled false", то оно начинает падать абсолютно аналогично загружаемому из флэши, т.е. логично -- нет обработчика, так циклим на дефолтном, а есть -- он вызывается. Чудеса исчезают, когда "SVC 123456" нормально отрабатывала с потусторонним миром !
А если попробовать "set semihosting enabled true" с грузимым из флэши, то он не подымается -- варнинг на эту операцию после старта приложения.
Я ж ещё нашёл опцию SEMIHOSTING в bsp-editor, она выключена сейчас. Думаю -- включу, и Прелоадер начнёт поддерживать то самое SVC-прерывание по адресу 08 для моего приложения, сообщит ему, жив ли хост, есть ли отладчик, перекомпилил его, зашил... Ан нет -- просто всё вешается гораздо ранее, после первой мессаги в RS, и из хоста отладчик достучаться не может.

...Слова "SVC" и "semihosting" на сайте Альтеры находятся несильно, у ARM этого добра выше крыши (хотя сайт infocenter.arm.com с фреймами, оставляющими на полезную информацию менее трети экрана, жутко неудобен, назад ходит не туда), похоже, они законодатели моды, в http://infocenter.arm.com/help/topic/com.a..._processors.pdf вроде бы нашлось что-то!..