[serjj1333 0]

Доброго времени суток :rolleyes: Вопрос про Cyclone V HPS, но вопрос скорее процессорный, поэтому решил написать здесь. Код и отладка в DS5. Есть две платы с CV HPS (Cortex-A9): на одной плате DDR3 1Гб, на другой - LPDDR2 0,5Гб. Загружаю на армовскую внутреннюю память preloader (U-Boot SPL 2013.01.01), он успешно выполняется, память инициализируется, могу в нее писать или читать из нее. На плате с DDR3 по JTAG загружаю в SDRAM приложение с точкой входа например 0x00100040 в дебагере командой loadfile, далее start - программа доходит до main(), могу выполнять дальше, все ок. На плате с LPDDR2 загружаю точно такое же приложение, загружается нормально, проверяю в просмотрщике памяти, но если сделать start, то проц уходит в ребут с последующим перегрузом preloader'a (наблюдаю перезагрузку в терминале).

 

Есть идеи, почему такое может быть?

Спасибо.

[WitFed 1]

HelloWorld "короткий" на ончипе нормально запускается ?

В общем случае аксиоматически у Альтеры -- на каждую систему должен быть рождён свой Прелоадер изменением настроек, подключением подходящего каталога handoff и его перекомпиляцией. "Классический" Прелоадер только в паре с Альтерной поставленной прошивкой и должен уметь стартовать.

Хотя я не очень понимаю, зачем это "вечно", если все устройства HPS-а впаяны в него самого, а у разных вендоров отладочных плат меняется только периферия у ПЛИС-ины, которая вдруг иниту и не должна подвергаться.

В данном случае память у проца другая, а её инициализация делается как раз в Прелоадере, он же типа и грузит в неё код 3й стадии, передаёт управление, может не хватило крохи какой-то в стандартном Прел, да на жёстком месте падёж... Производитель платы с 512 М LPDDR2 никакого каталога handoff не выкладывал вдруг ? Мануалы от него есть на примерный запуск из своей DDR ?

По-любому, можно узнать вектор причины, по которой всё начинается -- в DS-5 поставить точки останова на все векторы и пуститься, в LR после ловли будет адрес последней работавшей "падшей" инструкции.

Тест памяти должен быть первым в пробном приложении -- записать-прочитать-сравнить 10 раз несколько статических К, потом вывести в консоль что-то...

У меня в мае и CRC сбоила "памятная", и wathdog срабатывал, всё отключал в bsp-editor и перекомпиливал Прелоадер.

 

Модераторы пусть определят вслух или метлой, куда такие темы пихать -- я пока лично этот HPS к DSP отнести не могу никак, пока не научусь достойно работать с NEON.

Есть где-то внизу Главной Страницы SoC в заголовке, это ближе к телу. И в Альтерные места такое раньше пихали -- эта дурная многоступенчатая идеология загрузок ими проповедуется, вместо более родного нашему менталитету "БистрО".

[serjj1333 0]

Нашёл решение. Проблема оказалась в разнице объема SDRAM. Для сборки в Makefile используется линкер скрипт (файл .ld), дефолтный скрипт от альтеры подразумевает, что на плате установлено 1Гб памяти, что отображается в секции MEMORY линкер скрипта. На нашей плате установлено только 0,5Гб памяти. Есть предположение, что дебаггер не передает управление программе собранной с неправильной картой памяти. Детали пока не понятны, но я подкорректировал скрипт:

MEMORY
{
  boot_rom (rx) : ORIGIN = 0xfffd0000, LENGTH = 64K
  oc_ram (rwx) : ORIGIN = 0xffff0000, LENGTH = 64K
  /* Need to have 64bytes available before start of program, to store the mkimage header */
  ram (rwx) : ORIGIN = 0x100000 + 0x40, LENGTH = 511M - 0x40
}

и программа начала запускаться и выполняться. Пробовал unhosted и hosted приложение. Такие дела. Про линкер скрипты можно почитать например здесь, если кому интересно. От альтеры разъяснений пока не дождешься, есть документация на gcc, который используется для компиляции от Mentor graphics (да да такая вот ирония: GNU от Mentor'ов). Лежит это как оказалось в *quartus_folder*\embedded\host_tools\mentor\gnu\arm\baremetal\share\doc\sourceryg++-arm-altera-eabi\pdf.

 

Прошу перенести тему в раздел ПЛИС/Системы на ПЛИС - System on a Programmable Chip (SoPC), ошибся, всё таки пусть все темы по soc обитают в одном месте.

Изменено 4 февраля, 2015 пользователем serjj

[WitFed 1]

Отлично ! Причина всегда где-то сидит и не так глубоко, как голове хотелось бы... ;)

Похоже, стартовый указатель стека (его обычно наверх отсылают) вылез за пределы, в ту область мож что и писалось "навсегда", а обратно при возврате из функций читалась уже точно ерунда. И это можно было чисто пошаговой отладкой углядеть на -O0 ?

[serjj1333 0]

Я пробовал использовать команду step, но тогда где-то в preloader'e бродишь, пока не уйдешь в зависон. Для меня не прозрачен переход между preloader'ом и приложением. В случае если приложение грузится автоматически используется, как я понял jump_to_image_no_args функция (это если нету ОСи). Я как-то пошагово доходил до последней строки preloader'a, но мало что дало. Если приложение грузится дебагером, то что там происходит вообще не ясно. Получалось так, что если приложение собрано невалидным линкер скриптом, то дебагер просто не отдает ему управление и так и сидит в preloader'e. Соответственно пошаговая отладка тут ничего не даст, зависон. Беда в том, что софт никаких подсказок не дает, что что-то не так. В логах пишет, что все загрузилось успешно, но на выполнение не переходит. Поэтому приходиться гадать и читать документацию на gcc.