Всё-таки надо все факты заново собрать и изложить рядом. Скентоваться с обладателем такого же кита, проводить синхронные мероприятия...
Не только же в 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, отпишитесь плз, можно сделать пару быстрых тестов.

Сообщение отредактировал serjj - Feb 10 2015, 13:19

А как у Вас организован холодный сброс процессора?
ЕМНИП, 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 приложения на кастомной борде!

Сообщение отредактировал serjj - Feb 12 2015, 12:28

Ура!

Добрый день. У меня стоит задача реализовать автономный запуск 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 вдоль и поперек - все было валидно..