Всем доброго дня. Хочу использовать лишнюю память во флешке для своих нужд.
Для начала пытаюсь прочитать содержимое, записанное в процессе конфигурации.
Добавил в программу следующее:

#define ALT_USE_EPCS_FLASH
#include <altera_avalon_epcs_flash_controller.h>

ALTERA_AVALON_EPCS_FLASH_CONTROLLER_INSTANCE ( EPCS_FLASH_CONTROLLER_0, epcs_flash_controller_0);

Далее, в main:

alt_epcs_flash_init(&epcs_flash_controller_0);

И пытаюсь прочитать область памяти:

alt_u8 buf_FL[32];
int offset = 0x019520;
int length = 32;
int var = 0;
for(var=0; var<32; var++){buf_FL[var]=0;}
alt_epcs_flash_read(&epcs_flash_controller_0.dev, offset, buf_FL, length);

В результате, у меня в буфере что-то появляется, но совсем не то, что лежит в .flash файле, которым была прошита конфигурационная флешка.
В остальном весь проект работает, и из флэш, и в режиме отладки. Может, кто подскажет - что я делаю не так?

Давно делал не помню всех нюансов, но если глянуть старый код, то для инициализации контроллера я использовал макрос ALTERA_AVALON_EPCS_FLASH_CONTROLLER_INIT.

Спасибо за ответ, значит я по крайней мере на правильном пути.
Это на самом деле одно и тоже, этот макрос определен в файле altera_avalon_epcs_flash_controller.h :

#define ALTERA_AVALON_EPCS_FLASH_CONTROLLER_INIT(name, dev) \
alt_epcs_flash_init(&dev)

Может, я сам себя обманываю? Должно ли содержимое флешки соответствовать содержимому файлов .flash, генерируемых квартусом для программирования этой флешки?

Я реализовывал прошивку памяти через ниос и там было примерно так:
- нужно стереть память всю. стерается она по секторам. стертый байт - 0xFF
- получить файл .bin из .flash командой:

# Convert to binary
nios2-elf-objcopy -I srec -O binary my_project.flash my_project.bin

- заливать в память .bin
- снять и подать питание

Это я к чему. Может вы не то проверяете?
Не претендую на 100% достоверность.

ПС Да, при чтении из памяти получается в точности содержимое .bin файла

Сгенерировал бин, проверил. Что .bin, что .hex, что .flash - во всех файлах одинаковые данные, только смотреть их надо по-разному.
И не совпадает с тем, что я читаю из флеш. Пробовал по разным адресам, и с 0, и с конца.

Hex - это прошивка самого Nios, она лежит в EPCS с какого-то там адреса, правильно ли Вы его считываете? Возмите rbf, он уж точно лежит с нулевых адресов в EPCS, и пробуйте его прочитать.

Я смотрел с учетом адреса, в hex и во flash в начале строки адрес стоит. Если файл сгенерен правильно, то по одинаковым адресам во всех файлах одинаковые данные.
Единственное, там есть упоминание про компрессию какую-то, может, она влияет?

у ксалинкса, например, часть файлов в ASCII кодировке, то есть вместо 0xA5 в памяти лежит буква А и 5, также это все собрано строками и перед ними стоит сдвиг адреса, а в конце контрольная сумма строки, это какой-то стандартизованный формат, не помню чей. Естественно при прошивке отрезается начало со сдвигом адреса, отбрасывается контрольная сумма, и 2 символа преобразуются в правильный один. Вы эти нюансы учли?

Попробуйте внешними средствами считать флэшку с понятного адреса.

Ну да, это hex формат так устроен. Конечно я это учел. Похоже, у меня какая-то проблема с реализацией BSP или QSYS. Сейчас пробую прочитать флешку на уровне SPI.

Сгенерте совместно с другими файлами конфигурации rbf, залейте прошивку в EPCS, посмотрите сходятся ли прочитанные данные с 0-х адресов с данными в rbf.
Для V-х FPGA, такой способ не подойдёт, там есть какя-то проблема с генерацией rbf. Ну и компрессию пока убирайте.

В общем, частично разобрался. Я программировал флеш квартусом через индирект (.jic), предварительно конвертируя файлы. Глянул в создаваемый .map файл, а в нем действительно начала и концы сегментов не совпадают с теми, что во .flash файлах, то есть при конвертации в .jic квартус как-то преобразует данные. А при программировании с помощью ниос программера все данные совпадают - проверил считав флеш по SPI.
Но теперь у меня (после апгрейда ниос) флеш в ниосе не читается стандартными функциями. Буду сегодня разбираться.


Подскажите, пожалуйста, каким образом rbf генерировать?

меню FILE --> Conver tProgramming File. так же как и jic

Или можете в Assignments->Device->Device and Pin Options->Programming Files поставить галку напротив Raw Binary File (.rbf), тогда он будет автоматом генерироваться при каждой компиляции.

Скажите пожалуйста, если один и тот же .jic файл записывать в EPCS через JTAG в Квартусе с помощью USB Blaster и напрямую командами NIOS-а ( используя соответствующие команды драйвера epcs_commands.h ), то в EPCS получится один и тот же битстрим?

Если использовать Nios flash programmer, утилиту встроенную в Eclipse, то да. Логично предположить, что если писать "вручную", то тоже да.

Судя по Вашему ответу Вы меня не правильно поняли.
Я просил сравнить 2 варианта записи одного и того же .jic файла в EPCS в 2-х вариантах:
1). в Квартусе через JTAG с помощью USB Blaster
2). командами NIOS-а используя соответствующие команды драйвера epcs_commands.h

Вопрос:
При условии корректной записи в обоих вариантах в EPCS получится один и тот же битстрим или будут отличаться?
Другими словами, Квартус через JTAG с помощью USB Blaster-а записывает .jic файл в EPCS один в один или что-то в нём меняет перед записью?

Нет, не меняет. Просто записывает его и всё. И если ниосом залить туже самую прошивку, то во флешке будет лежать тоже самое.

Это Вы знаете на собственном опыте или из теории?
Вот здесь я проверил - прочитанные из EPCS данные ( по крайней мере с нулевого смещения ) не совпадают с ранее туда записанным .jic файлом.

Насчёт меняет или не меняет: посмотрел свои исходники замены прошивки посредством Ниоса, почему то переставлены биты в байтах зеркально и вырезано 92(+-1) байта с начала. В качестве файла используется .jic. Но у меня интерфейс SPI обмена с EPCS, что в Ниосе, что в FPGA написаны саморучно по той простой причине что нужно было сильно ужаться. Ещё раз: биты переставлены хотя команды управления EPCS идут не переставленные.

Вот это сюрприз!
А это где-то документировано у Альтеры?
Мне нужно исходный .jic файл, записанный в EPCS по по адресу 0x00 заменить на другой .jic файл.

Вырезано 92(+-1) байта с начала - в смысле заменено на 0xff ?
Я вижу, что именно так, но поскольку у меня маленькое окошко просмотра - всего 16 байт ( всё под завязку в ПЛИС заполнено ) , то пока не могу всю прошивку прочитать ( для этого надо прогу соответствующую писать - это чуть позже ).

hint:
jic это не просто sof + hex(elf? или ещё что у вас там)

в нём ещё указана прошивка-загрузчик (из состава квартуса), обеспечивающая доступ к микросхеме EPCS через JTAG, и использующаяся на время прошивки этих самых (sof + hex) через JTAG при помощи quartus programmer.

поэтому используйте смещение.
либо откажитесь от jic.

Мне нужно исходный .jic файл, записанный в EPCS по адресу 0x00 заменить на другой .jic файл командами epcs_write_buffer ( из драйвера epcs_commands.h ).
Как использовать смещение, поясните пожалуйста?

>>Вырезано 92(+-1) байта с начала - в смысле заменено на 0xff ?
Просто выброшены.
На сколько помню у меня тоже было под завязку забита FPGA , поэтому и переписал всё. Стандартный модуль обмена с EPCS в FPGA занимал драгоценные блоки памяти и ресурсы (триггера) и ещё при подключении функций обмена в Ниосе (типа epcs_commands.h) жрёт ещё пару килобайт или больше. И всё это работает чёрти знает как медленно, перегоняет из блока памяти из FPGA в массив выделенный в Ниосе. Самописный- в Ниосе килобайт 700 (включая буфер 256) и в FPGA 35 триггера.
Считайте EPCS Ниосом c адреса 0x00, сравните с .jic со смещением 92 развернув байты.

В EPCS c 0x00 первые 16 байт - это 0xFF, остальные пока не смотрел.
Прочитано командой epcs_read_buffer из драйвера epcs_commands.h.

Посмотрел несколько файлов .jic hex редактором начиная с 92 байта практически у всех идёт 0xff.
В некоторых вторые 16 байт после 92 уже не 0xff, а в некоторых и дальше 0xff. Это наверно зависит от прошивки.
Там в hex редакторе чётко видно что до 92 байта идёт текстовая информация.
А вот первые три байта с 0x00 в файле .jic похоже равны всегда 4A4943 по ним я и определяю что файл правильный для FPGA.

Да, .jic файл сразу начинается с 0x4a 0x49 0x43, что соответствует кодам букв JIC , да - до 0x92 байта идёт текстовая информация.
Байт 0x92 == это 0x20.
Далее в .jic файле идут 10 байт 0x00, а из EPCS по 0x00 читаются 0xFF.
То есть даже вырезка 0x92 байт текстовой информации не даёт совпадения между .jic файлом и данными в EPCS с адреса 0x00.

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

Непонятно, что вам непонятно. Сначала записать посредством JTAG файл .jic в EPCS, проект должен работать(насколько я понял вы это умеете). Считать не первые 16, а вторые или следующие байты из EPCS с помощью ниоса, байты должны отличаться от 0xff. Найти эти байты в .jic файле на компьютере с помощью HEX редактора. Сделать вывод о том нужно их переворачивать (менять местами биты) и сделать вывод где лежат эти байты в EPCS (смещение). На сколько я понимаю по исходникам они будут лежать со смещением +92. Затем Ниосом читать файл .jic на компьютере (какой у вас интерфейс обмена с компьютером я не знаю), записывать этот файл в EPCS стандартными командами, только первые 92 байта точно не записывать, и если нужно разворачивать биты. 92-й байт из файла .jic должен записаться в EPCS по нулевому адресу. Возможно я где то ошибаюсь, давно это было, но у меня вроде так.

В начале JIC-файла идёт шапка (Q2 Programmer не шьёт её в EPCS), её надо отбросить, а остальное писать в EPCS (ещё "хвост" можно обрезать), а проще сгенерить RPD-файл и его заливать epcs_flash_controller-ом (сообщение #15). В RPD-файле - только полезные данные. Точно не поню, но, вероятно, придётся поменять порядок бит в каждом байте при записи RPD в EPCS.

Да, всё точно так! В RPD-файле - только полезные данные.
Благодарю Вас, doom13 и tvcam.

Может и не новость, но в Q2 Programmer-e есть галка examine. C её помощью можно считать всё содержимое EPCS, сохранить в JIC.

А есть ли способ избавится от зеркального отображения битов в байте или только самому перелопачивать чтобы вернуть в нормальное состояние?
Вопрос относится к семейству Cyclone 4 GX и Q13.1.

Я, тупо переставляю ещё в компьютере в программе которая передаёт файл jic в Ниос.
Она же и убирает первые 92 байта.
Кусочек на Delphi (shr - сдвиг):
for k:=1 to 256 do
begin
Result:=0;
for a:=0 to 7 do
Begin
Result:=Result or ((SendBuff[k] shr a) and 1) shl (7-a);
End;
DSendBuff[k] := Result;
end;
Правильно подмечено- передавать можно не всё до конца, у меня прошивка для EP3C5 заканчивалась где то на 0x40010.

В моём случае Ниос сам биты переставляет, но можно и конвертор для файла прошивки сделать.