[sdimann 0]

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

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

Добавил в программу следующее:

 

#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 файле, которым была прошита конфигурационная флешка.

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

 

 

[doom13 0]

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

ALTERA_AVALON_EPCS_FLASH_CONTROLLER_INSTANCE(EPCS_FLASH_CONTROLLER_0, epcs_flash);

void epcs_loader_test()
{
    char buf[8];
    int offset = 0, i;


    ALTERA_AVALON_EPCS_FLASH_CONTROLLER_INIT(EPCS_FLASH_CONTROLLER_0, epcs_flash);

    for(i = 0; i < 65536; i++)
    {
        alt_epcs_flash_read(&epcs_flash.dev, offset, (void *) buf, 8);
        offset += 8;
    }
}

[sdimann 0]

Давно делал не помню всех нюансов, но если глянуть старый код, то для инициализации контроллера я использовал макрос 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, генерируемых квартусом для программирования этой флешки?

 

[Swup 0]

Я реализовывал прошивку памяти через ниос и там было примерно так:

- нужно стереть память всю. стерается она по секторам. стертый байт - 0xFF

- получить файл .bin из .flash командой:

 

# Convert to binary

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

 

- заливать в память .bin

- снять и подать питание

 

Это я к чему. Может вы не то проверяете?

Не претендую на 100% достоверность.

 

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

Изменено 21 июля, 2014 пользователем Swup

[sdimann 0]

- заливать в память .bin

- снять и подать питание

 

Это я к чему. Может вы не то проверяете?

Не претендую на 100% достоверность.

 

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

 

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

И не совпадает с тем, что я читаю из флеш. Пробовал по разным адресам, и с 0, и с конца.

[doom13 0]

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

И не совпадает с тем, что я читаю из флеш. Пробовал по разным адресам, и с 0, и с конца.

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

 

[sdimann 0]

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

 

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

Единственное, там есть упоминание про компрессию какую-то, может, она влияет?

[Golikov 0]

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

 

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

[sdimann 0]

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

 

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

 

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

[doom13 0]

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

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

Для V-х FPGA, такой способ не подойдёт, там есть какя-то проблема с генерацией rbf. Ну и компрессию пока убирайте.

[sdimann 0]

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

Но теперь у меня (после апгрейда ниос) флеш в ниосе не читается стандартными функциями. Буду сегодня разбираться.

 

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

Для V-х FPGA, такой способ не подойдёт, там есть какя-то проблема с генерацией rbf. Ну и компрессию пока убирайте.

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

[gosu-art 0]

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

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

 

[doom13 0]

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

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

 

[FLTI 0]

В общем, частично разобрался. Я программировал флеш квартусом через индирект (.jic), предварительно конвертируя файлы.

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

[serjj1333 0]

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

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