Всем доброго времени суток.
Продолжение Циклониады V В свете последних событий по загрузке baremetal приложения из SD/MMC на радостях решил на отладочной плате отработать загрузку из QSPI флеша. Собрал preloader для этих целей, залил его HPS flash programmer'ом (quartus_hps) как положено в виде 4 копий, такой вот командой (из под soc eds, 4 копии он делает сам, какой молодец):

Программа сказала, что флеш успешно прошит. Щелкнул питанием на плате, посмотрел, что preloader запускается вплоть до загрузки приложения, SDRAM проинитилось, можно в него подгружать что-нибудь. Следующим шагом хотелось залить на флеш простенькую прогу а-ля helloworld, чтобы preloader ее запустил. Но флеш перестала прошиваться! вот что в консоли пишет по этому поводу:
Нажмите для просмотра прикрепленного файла
Не читается ID флеша. wtf? пробовал переключить BSEL на плате - тогда он не подключается к флешу, типа "BSEL не соответствует ни QSPI ни NAND boot'у". Еще пробовал запустить альтеровский пример Altera-SoCFPGA-HardwareLib-QSPI-CV-GNU, программа выдает ошибку, подключался дебагером, вроде тоже проблема в чтении ID (функция alt_qspi_device_rdid()) на этапе инициализации QSPI интерфейса и флеш контроллера.
Кто-нибудь уже работал с загрузкой из QSPI флешки? В чем может быть проблема и как можно эту беду победить?

Была такая же проблема.
Загрузился c SD карты, в u-boot почистил flash командой sf erase.

После этого flash стала определяться HPS flash programmer'ом.

А как запустить именно u-boot? Я попробовал с SD загрузить линух, но в нем такой команды нет. Может есть какие то альтернативы под линухом?

Все это делается в загрузчике u-boot.

Загрузиться с SD карты.
В консоль будет выводиться инофрмация о процессе загрузки:


При появлении строки
Hit any key to stop autoboot
необходимо нажать любую клавишу.

Это прервет дальнейшую загрузку Linux.

Далее вводим команду sf probe



Командой sf erase очищаем QSPI flash.

COMA, спасибо, запустил u-boot.
Но вот, что пишет:
Нажмите для просмотра прикрепленного файла
Нет доступа к флешу. Пробова для BSEL = 0x101.
Попробовал для BSEL = 0x111, таже петрушка.
Вот в исходниках убута есть такое место:

Это пока всё, что может гугл об этом сказать... Такое ощущение, что проблема не во флеше а в контроллере qspi, до флеша не доходит дело, с другой стороны если BSEL = 0x111 preloader грузится, т.к. инитится SDRAM, факт. Дела..

У меня BSEL = 0x101, флешка доступна.

Попробуй запустить команду sf erase.
Может прокатит.

Пишет:

Остаётся выпаять и заменить.

R.I.P...
Надо понять в чём была фатальная ошибка, сделал одно прошивание, которое в eds консоли прошло как успешное. Губить флешки в один клик мышки/клавиатуры это уже слишком

serjj
Можно попробывать отключить QSPI в QSYS и настроить выводы как PIO, затем программно дрыгая ножками попробывать считать ID или стереть. Можно попробывать ножки перенаправить в FPGA и от туда добираться до флешки например Ниосом. К примеру Ethernet и RS232 у меня перенаправлены в FPGA.

Жесть... Думал уж на отладках то должно быть все дуракоустойчиво. Буду со своей платкой осторожнее....

А как вообще работоспособность контролера QSPI может зависеть от положения пинов BSEL ?
Они лишь указывают Прелестям Альтерным, откуда нужно грузить следующую фазу кодов. Даже если стоит установка на SD, читать-писать девайс QSPI должно быть возможно.
Сам девайс энергонезависимой памяти никоим образом не знает про остальную систему и раскоряки там.
Только если предыдущие стадии ПО что-то где-то перемудрили, как у Альтеры часто бывает... Но по ошибке они должны были всё вернуть в нормальное состояние, если мудрости хотят.

...serjj, у тебя получилось стартовать отладку HPS из DS-5 под нажатым резетом и остановиться на самой первой команде BootROM ? Чтобы никакое влияние BOOTSEL ещё не успело произойти после подачи питания ?
На странице http://www.altera.com/support/examples/soc/soc.html есть ещё один QSPI-проект "Quad SPI Porting", там обещают "support more quad SPI flash devices". Возможно, в Arrow-ките стоит какая-то не такая микросхема, а ошибка вылазит чисто из-за несоответствия ID требуемому. А успешные зашивания 4х64К просто приснились... Логов-то небось для quartus_hps нету всех от Первого Включения ?
Одна работа по стандартному интерфейсу не должна испортить железо при нормальной организации, вряд ли в протоколе есть команда kill.
...Ну или под микроскопом глянуть на плату -- вдруг на неё падало что-то в последнее время.
У вас же есть вторая самодельная плата -- на ней те же грабли ?
Частоты у QSPI точно где-то можно крутить, PLL такая была.

AlteraHazard!

Так можно перенаправить некоторые интерфейсы с ножек HPS на ножки FPGA, но если микросхема припаяна уже к ножкам HPS, то если я перенаправлю на другие ножки, то с ней просто не будет контакта. Тут нужно наоборот залезть из FPGA на ножки HPS, а это страшное табу (ну или я просто еще до этого не дорос ) А про то, что вы говорите, я так на нашей борде юарт перенаправил на ножки FPGA, но это не то. Или я что то не понял?

Это нужно только для утилиты quartus_hps, работать с QSPI можно при любом BSEL, эта конфигурация действительно не влияет на контроллер (что логично)

Есть альтеровский пример работы с QSPI флешой, я пробовал его под всякими BSEL, не работает, таймаут на этапе чтения ID, на этапе инициализации QSPI контроллера в функции alt_qspi_enable()->alt_qspi_device_rdid()->alt_qspi_stig_rd_cmd()->alt_qspi_stig_cmd_helper(), в последней висит до таймаута:

Это похоже на ошибку чтения по QSPI. Перекликается с тем, что u-boot тоже жаловался на недоступность именно QSPI.

А на кастомной пока нет qspi, поэтому отлаживаю такую загрузку на arrow.
За ссылку спасибо, гляну.

У меня пишет

Хотя я еще не прикасался к процессорной флешки

Ну это нормальный октлик на команду, флеш читается.
Смотрю сейчас осцилом на qspi-й клок, который идет на флеш, при BSEL = 0x111, когда перезаливаю .sof файл вижу, что клок идет и в терминале грузится preloader с флеша. Через некоторое время (2-3 сек) в терминале вылазит вот что:

После чего любые попытки обратиться к QSPI проваливаются. Если BSEL не 0х111, то клоков тоже нет.

Всё-таки надо все факты заново собрать и изложить рядом. Скентоваться с обладателем такого же кита, проводить синхронные мероприятия...
Не только же в quartus_hps она не работает, а вообще напрочь в данный момент ? Противоречиво всё выше.
Или где-то можно прочитать-записать хотя бы, закомментив чтение ID ? Меня интересует восстановление первых 256 К, которые пострадали, от неконтролируемого исполнения Прелоадера, из которого портится всё остальное.
Можно как-то испортить первые байты каждого из 4х кусков, выпросить у народа более нормальное содержимое (мусор тоже должен сгодиться -- он не исполнится), вдруг и Arrow его даёт вместе с инструкциями... Или это некритичное и нестолбовое направление, мы там как ёжики в тумане ?
Бывают же случаи, когда Прелоадер стартует классический, не самодельный, где раньше определялось ? Там в первой строке его дата компиляции есть как минимум. Или вдруг самодельный копируется из выходного каталога в любой компилируемый проект, да всё поганит каждый раз ? И надо как вируса его выгресть
Вообще, чтение ID -- это базовая операция всего стандарта, просто так она отпасть не должна.
В Альтерных примерах есть ещё что-то про связь двух SPI, но это я не пробовал.

Good news everyone!

alexPec, можете записывать на флешку любой хлам, нашёл решение проблемы.

Проблема как обычно в голове preloader'e. Необходимо было его пересобрать с нуля после добавления в Qsys проекте QSPI контроллера (добавление его в периферии HPS компонента). Preloader'ы, которые я зашивал до этого не имели никакой информации о том, что у меня будет QSPI контроллер использоваться, все попытки программно к нему обратиться из системы, запущенной таким preloader'ом не давали результата. Отсюда недоступность QSPI контроллера, про которую я тут писал. Простая проверка: если взять невалидный preloader и попробовать прочитать регистр по адресу 0xff705000 (регистр конфигурации QSPI), то он вернёт 0x00000000, т.к. модуль не доступен. Если использовать preloader с поддержкой QSPI, то при чтении этого адреса возвращается значение 0x80780000 или 0x00780000 (старший бит = флаг idle).

Лечение. Пересобрал preloader с нуля после добавления QSPI в Qsys. Подгрузил его через JTAG. Запустил пример от альтеры Altera-SoCFPGA-HardwareLib-QSPI-CV-GNU. В нем нужна инициализация (DMA можно закоментировать) и функция стирания. Запускаю, вот что в дебаг консоли выходит:

Скорее всего если пересобрать также uboot, то можно сделать стирание в нём с помощью sf erase команды. Я, т.к. нацелен на baremetal, делаю всё сразу на низком уровне.

После этого выключил плату, выставил BSEL = 0x111 и теперь, читая Silicon ID, получаю правильный отклик от флешки:
Нажмите для просмотра прикрепленного файла

Теперь с ней можно возиться дальше

Спасибо за информацию!

Не хочу плодить темы, пишу тут, сейчас осваиваю взаимодействие с NAND флешом на кастомной борде. Использую hwlib библиотека alt_nand_flash. Получилось сделать инициализацию (не без бубнов), стирание, запись, чтение. Больших тестов пока не делал.

Собственно интересная особенность. Все это работает, если я после подачи питания заливаю preloader и сразу запускаю приложение. Если я сначала залью sof файл, в котором есть hps компонент, установленный в qsys, то контроллер NAND оказывается недоступен (чтение возвращает 0xff, нет сигнала чтения от проца, если смотреть осцилографом). В peripheral pins в Mux Table пробовал задавать явно использование соответсвующих ног под NAND, не работает. Если наоборот отключить эти ноги, то не работает все равно. При этом если загружать sof без hps, то все работает. Рассматривал hps компонент, единственный пункт, который явно относится к NAND, это NAND clock frequency в HPS Clocks/Output Clocks. Но он не доступен для редактирования. Есть идеи, что это может быть?

Кто-нибудь уже ковырялся с NAND из под HPS? Особенно интересует применения hwlib для baremetal.

Немного шаманства и мракобесия..
Ковыряю проблему и вот к чему пришёл. На нашей плате сделана такая вот схема для BSEL ножек проца:
Нажмите для просмотра прикрепленного файла

т.е. значение BSEL задается в FPGA части, ножки FPGA соединены с соответствующими BSEL. Для CSEL тоже самое. Так было сделано, потому что изначально планировалось сперва загружать FPGA, а потом, выставляя там нужные BSEL грузить HPS. Так вот, если я эти ножки из проекта выкидываю, оставляя их в tri-state, NAND контроллер нормально видится софтом и читается/пишется. Если я их подключаю, он отваливается. Проверял на совершенно пустом проекте, в котором буквально есть только клок и означенные ножки.

Так вот, может быть тут какой-то очевидный схемотехнический косяк и так делать нельзя? Или это пасхалка от Altera? Если кто-нибудь является обладателем отладочной борды с NAND, отпишитесь плз, можно сделать пару быстрых тестов.

А как у Вас организован холодный сброс процессора?
ЕМНИП, BSEL'ы защелкиваются системным менеджером при снятии сигнала холодного сброса.
Ну и еще в процессе загрузки состояние BSEL'ов не должно изменяться.

Холодный сброс генерируется как задержанный сигнал pll_locked (где-то 300 тактов), пробовал и с ним (в большом проекте с qsys) и без него (в маленьком тестовом пустом)
BSEL задаются жёстко, не меняются

Нашёл решение своей проблемы!

Причина: ножка BSEL2 и NAND_WE физически находятся на одном пине процессора. Когда я с FPGA жёстко задаю значение BSEL2 как 0 или 1, контроллер не может управлять NAND. Когда я убираю из FPGA проекта ножки управления BSEL2, на линии по умолчанию tri-state, контроллер может выставить 0 или 1, NAND управляется.

Решение: на отладочной борде сделано так
Нажмите для просмотра прикрепленного файла

Как видно из схемы установленные резисторы не дают конфигурационному уровню заблокировать доступ контроллера NAND к линии.
На нашей плате ножка проца и ножка FPGA закорочены. Что бы освободить линию для NAND контроллера сделал следующую конструкцию:

где CONFSTART и CONFEND выбираются таким образом, что бы сигнал confsel выставлялся в 1 перед подачей сброса на HPS и падал в 0 после снятия сброса с некоторой задержкой (у меня более 10000 тактов), т.к. инитный код процессора читает состояние BSEL в некоторый момент времени после снятия сброса.

После такой модификации проекта утилита quartus_hps определила NAND на плате, я смог зашить в неё образы preloader'a и простейшего baremetal приложения
Нажмите для просмотра прикрепленного файла

Когда я перешиваю sof, происходит сброс HPS и в терминале выводится статусная информация preloader'a и собственно вывод программы
Нажмите для просмотра прикрепленного файла

Есть автономный запуск простейшего baremetal приложения на кастомной борде!

Ура!

Добрый день. У меня стоит задача реализовать автономный запуск FPGA и HPS(baremetall) частей при подаче питания на плате. Грубо говоря есть .sof и .axf. Необходимо залить это на плату для боевого режима. Как я понял необходимо использовать QSPI. Для начала сформировал файлы preloader-mkpimage.bin, u-boot-spl.bin и soc_system.rbf в соответствии с описанием. Файл soc_system.rbf получил командой quartus_cpf -c -o soc_system.sof soc_system.rbf. Саму QSPI прошивал утилитой quartus_hps. Адреса для прошивки брал всё из того же описания (табличка в пункте 6). Для примера со стороны FPGA был сделан простой индикатор мигания светодиодом, по Jtag'у он работает. После прошивки в QSPI ничего не завелось. Вот лог консоли:

U-Boot SPL 2013.01.01 (Aug 18 2016 - 16:22:01)
BOARD : Altera SOCFPGA Cyclone V Board
CLOCK: EOSC1 clock 25000 KHz
CLOCK: EOSC2 clock 25000 KHz
CLOCK: F2S_SDR_REF clock 0 KHz
CLOCK: F2S_PER_REF clock 0 KHz
CLOCK: MPU clock 925 MHz
CLOCK: DDR clock 400 MHz
CLOCK: UART clock 100000 KHz
CLOCK: MMC clock 50000 KHz
CLOCK: QSPI clock 370000 KHz
RESET: WARM
INFO : Watchdog enabled
SDRAM: Initializing MMR registers
SDRAM: Calibrating PHY
SEQ.C: Preparing to start memory calibration
SEQ.C: CALIBRATION PASSED
SDRAM: 1024 MiB
SDRAM: Initializing SDRAM ECC
SDRAM: ECC initialized successfully with 1589 ms
SDRAM: ECC Enabled
FPGA : Programming FPGA
SF: Read data capture delay calibrated to 3 (0 - 7)
SF: Detected N25Q512 with page size 65536, total: 67108864

Почему то три раза одно и тоже(этот лог три раза подряд вываливается при подаче питания). Куда заливать HPS часть пока не знаю, но могу предположить, что вместо линукса из этого описания. Может кто прошёл этот путь поделитесь опытом, заранее благодарен. Интересует именно связка FPGA+HSP(baremetall). Могу составить потом подробную инструкцию как и что делать для этого по пунктам. Дебаг дебагом, но в результате то приложение должно автономно запускаться. Год назад прошивал QSPI для запуска HPS, теперь даже этого повторить не могу. Заранее благодарен.

Я u-boot не использую, юзаю MPL (mlnimal preloader).
Он загружает с SD карты сначала rbf файл для fpga, затем оттуда же baremetal приложение.
Конфигурируется также, как и стандартный SPL прелоадер, через bsp-editor, плюс в конфигурационном .h файле надо указать имя образа для fpga.
Затем собирается в DS5.

sonycman, спасибо. Скачал 16 версию,там есть пример Altera-SoCFPGA-HardwareLib-MPL, как раз то о чём Вы говорите. Но опять же сделал упор на прошивку QSPI из README.txt. В итоге после всех телодвижений и прошивки QSPI в консоль вывалилось следующее:

INIT: MPL build: Aug 19 2016 14:22:49
INIT: Initializing board.
INIT: MPU clock = 925 MHz
INIT: DDR clock = 400 MHz
INIT: Initializing successful.
MPL: SDRAM Size is 1048576KB.
MPL: Booting from QSPI.
QSPI: Initializing QSPI.
QSPI: Start loading image.
QSPI: Image loaded successfully.
MPL: SDRAM ECC Clearing is enabled.
MPL: SDRAM Boot Region: 0x01000000 to 0x02000000.
ERROR: Boot Image at 0x00200000+0x3d0 is outside of Boot Region.
ERROR: Adjust BSP settings or re-link Application.
ERROR: Error in boot process. Halting.

Надо разбираться с mpl.c, т.к. эти ошибки из этого исходника (функция prepare_launch()). У Альтеры есть ещё видео на тему MPL. Вариант с SD картой пока не попробовал, но если заведется, может и останемся на нём, хотя SD карта в автономном приборе не очень хорошее решение.

Не надо трогать исходники MPL!

Ведь написано, что у Вас загружаемое приложение размещается по адресу 0x00200000, а в настройках прелоадера SDRAM Boot Region определён как 0x01000000 to 0x02000000.
Просто исправьте в bsp-editor адрес начала boot region на 0x00200000, или исправьте линкер скрипт приложения так, чтобы код был размещён начиная с адреса 0x01000000.

ЗЫ: я вообще отключил опции SDRAM SCRUBBING, так как у меня на плате нет ECC.
Тогда даже адреса править не надо...

По поводу автономной загрузки приложения из QSPI вопрос решился, с адресами разобрался. Но появилась потребность, помимо загрузки из QSPI, выделить, например в конце этой памяти, некую небольшую область для хранения параметров. По Jtag всё пишется и читается и данные валидные. Если по Jtag заполнить эту область тестовыми данными и в QSPI зашить программу(для автономного пуска из QSPI), которая эти данные читает, то данные получаются не валидными. Т.е. то что было записано в конец QSPI не соответсвует тому что считывается при автономном старте из QSPI. Может у кого было такое.

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

Вот мой алгоритм:
1. В версии для Jtag инициализирую небольшой кусок с конца QSPI записью известной последовательности чисел.
2. Делаю версию проги, которая зашивается в QSPI для автономного запуска. Её назначение считать и проверить эти данные. При этом запись утилитой quartus_hps вроде как всю QSPI не стирает.
3. Включаю питание, загрузчик грузится, прога стартует, данные не валидны.

Можете кусок кода чтения/записи из убута выложить. Больше запись интересует. В автономном режиме зависает в процессе операции записи. Спасибо.

День добрый!

У меня несколько более странная проблема с NANDом: читаются верные идентификаторы, верный boot info, всё сходится с реальными данными микросхемы... Но при этом утилита (programmer) сваливается с ошибкой, вернее с нулём ошибок (0 errors, 0 warnings). Забавно - ошибка есть, но её ноль.
Мне пока не удалось найти такой наполовину хорошей, наполовину плохой ситуации. Если бы аппаратные проблемы были, тогда не читались бы индентификаторы. А тут...
На всякий случай: BSEL=011 (NAND 3V), CSEL=11 (Fosc * 5/25).

Какие будут соображения?




Вот ещё вдогонку одна картинка; снято на другой машине.

Тут информации чуть больше. В частности пишут про 'Invalid flash parameter'

Вопрос по-прежнему актуален.