Jump to content

    

FLTI

Свой
  • Content Count

    399
  • Joined

  • Last visited

Everything posted by FLTI


  1. Цитата(toshas @ Feb 6 2016, 17:57) У "хороших" плат все слоты одинаковы и настраиваются в bios (x16/x8/x4, SSC SpreadSpectrumClock). Платы "похуже" в целях экономии рассчитаны на то, что карта будет только в одном слоте, а в остальных периферия, поэтому конфигурацию слотов и настроек задают жестко и неодинаково по слотам. И конечно длины трасс к дальним слотам больше, соответственно затухание сигнала сильнее. Приведите пожалуйста пример "хорошей" материнской платы и платы "похуже" на чипсете Intel 87 и 97.
  2. В нескольких темах на форуме в ответ на сообщение о неких проблемах видел совет - поставь плату в слот рядом с процессором. При прочих равных условиях чем может отличаться поведение платы PCIe х 4 в PCIe слоте рядом с процессором ( в том, в который обычно ставят граф. карту PCIe x 16 ) и в PCIe слоте, удалённом от процессор?
  3. Зависит ли скорость выполнения такого рода команд NIOS II : IOWR_ALTERA_AVALON_PIO_DATA IOWR_8DIRECT IORD_ALTERA_AVALON_PIO_DATA IORD_8DIRECT от того как он сконфигурирован - в режиме /e, /s или /f ? Если зависит, то насколько существенно? NIOS II тактируется клоком 50 МГц.
  4. Цитата(_Anatoliy @ Nov 4 2015, 09:36) Файл software\name_app\name_app.objdump У меня в папке software нет файлов с расширением .objdump Квартус 13.1
  5. Какого типа переменную возвращает IORD_ALTERA_AVALON_PIO_DATA (PIO_1_BASE) если чтение идёт из 1-битного порта? То есть если PIO_1 сконфигурирован в QSYS как input порт шириной 1 бит. Почему шириной 1 бит? Потому что больше не нужно. Или так лучше не делать и надо задавать стандартную ширину 32 бит и тогда возвращаемый тип будет unsigned int ? Поискал по IORD_ALTERA_AVALON_PIO_DATA по сайту Альтера, но ничего толком не нашёл.
  6. Любые ли действия, которые делаются вручную через GUI в Квартусе можно перенести в скрипт или есть какие-то ограничения? Не появилось ли в последних Квартусах ( а может и раньше было ? ) что-то типа "захватчика" тех действий, которые делаются вручную через GUI и автоматическое формирование из них скрипта?
  7. Цитата(doom13 @ Apr 24 2015, 22:42) Если сделать железный контроллер для управления RSU, думаю, в 100 мс вполне уложится (ещё, правда, от конфигурационного девайса будет зависеть и файл прошивки ужать. Можно поставить epcq-флэшку для загрузки в режиме 4х). Железный контроллер для управления RSU придётся делать с нуля или у Альтеры есть что-то готовое? У меня и так с учётом компрессии и прочих ухищрений ( отдельный клок 40 МГц через CLKUSR вход и ещё кое-что ) это время на пределе ( примерно 80 мс ), но всё работает устойчиво. То есть на что-то ещё дополнительно остаётся 10 -15 мс. В итоге получается, что остаётся только рискованный способ - без RSU напрямую писать по нулевому адресу EPCS? Какие приёмы обычно используют, чтобы надёжно писать в EPCS? Я буду писать со стороны ПК через промежуточную On-chip memory ( dual-clock / dual-port ) размером чуть меньше 1Кбайт ( 1Кбайт минус 16 байт ) . С одной стороны в эту память ПК пишет данные из RPD-файла ( примерно 500Кбайт ), а с другой НИОС читает эти данные и через команду epcs_write_buffer ( из драйвера epcs_commands.h ) записывает их кусками ( 1Кбайт минус 16 байт ) в EPCS. Поскольку память при одновременным доступе на запись и на чтение по одному и тому же адресу ( а это может произойти ) возвращает значение Don't care , то как обычно делают, чтобы избежать этой проблемы? Если использовать биты готовности ( для handshake ) , то в отношении их тоже есть вероятность того, что произойдёт одновременный доступ по адресу, где находится этот бит готовности. Как тут быть? Есть ли тут какое-нибудь стандартное решение?
  8. Здравствуйте! Хотел бы сделать возможность обновлять прошивку EPCS ( что-то типа Remote Update ) таким способом. На плате имеется Cyclone IV с кофигурационной схемой AS с возможностью загрузки .jic файла через JTAG ( SFL ). [attachment=90113:SFL.png] В EPCS находится единственный .jic файл, который был загружен туда через JTAG этой схеме. При включении питания .jic файл из EPCS конфигурирует и инициализирует Cyclone IV. Если этот .jic файл ( находящийся внутри EPCS ) нужно обновить ( сделать что-то типа Remote Update ), то можно ли это сделать через NIOS II не вручную, а в автоматическом режиме? Например так - новый .jic файл передаётся с обновлением ПО, становится доступным для NIOS II и NIOS II перезаписывает новый .jic файл в EPCS, затирая предыдущий. После следующего включения-выключения питания Cyclone IV конфигурируется и инициализируется уже с нового .jic файла. Как это сделать? Видимо это должна быть некая программа на C для NIOS II? Есть ли где это описано у Альтеры, есть ли пример такой программы?
  9. А есть ли способ избавится от зеркального отображения битов в байте или только самому перелопачивать чтобы вернуть в нормальное состояние? Вопрос относится к семейству Cyclone 4 GX и Q13.1.
  10. Цитата(doom13 @ Apr 24 2015, 21:02) а проще сгенерить RPD-файл и его заливать epcs_flash_controller-ом (сообщение #15). В RPD-файле - только полезные данные. Точно не поню, но, вероятно, придётся поменять порядок бит в каждом байте при записи RPD в EPCS. Да, всё точно так! В RPD-файле - только полезные данные. Благодарю Вас, doom13 и tvcam.
  11. Да, .jic файл сразу начинается с 0x4a 0x49 0x43, что соответствует кодам букв JIC , да - до 0x92 байта идёт текстовая информация. Байт 0x92 == это 0x20. Далее в .jic файле идут 10 байт 0x00, а из EPCS по 0x00 читаются 0xFF. То есть даже вырезка 0x92 байт текстовой информации не даёт совпадения между .jic файлом и данными в EPCS с адреса 0x00. Попробую прочитать побольше данных из EPCS ( хотя это муторно маленьким окном в 16 байт ) и тогда наверное будет ясна закономерность. В том числе учту Вашу информацию о том, что "переставлены биты в байтах зеркально".
  12. Мне нужно исходный .jic файл, записанный в EPCS по адресу 0x00 заменить на другой .jic файл командами epcs_write_buffer ( из драйвера epcs_commands.h ). Как это сделать?
  13. В EPCS c 0x00 первые 16 байт - это 0xFF, остальные пока не смотрел. Прочитано командой epcs_read_buffer из драйвера epcs_commands.h.
  14. Цитата(krux @ Apr 24 2015, 19:55) поэтому используйте смещение. Мне нужно исходный .jic файл, записанный в EPCS по адресу 0x00 заменить на другой .jic файл командами epcs_write_buffer ( из драйвера epcs_commands.h ). Как использовать смещение, поясните пожалуйста?
  15. Цитата(tvcam @ Apr 24 2015, 19:37) Насчёт меняет или не меняет: посмотрел свои исходники замены прошивки посредством Ниоса, почему то переставлены биты в байтах зеркально и вырезано 92(+-1) байта с начала. В качестве файла используется .jic. Но у меня интерфейс SPI обмена с EPCS, что в Ниосе, что в FPGA написаны саморучно по той простой причине что нужно было сильно ужаться. Ещё раз: биты переставлены хотя команды управления EPCS идут не переставленные. Вот это сюрприз! А это где-то документировано у Альтеры? Мне нужно исходный .jic файл, записанный в EPCS по по адресу 0x00 заменить на другой .jic файл. Вырезано 92(+-1) байта с начала - в смысле заменено на 0xff ? Я вижу, что именно так, но поскольку у меня маленькое окошко просмотра - всего 16 байт ( всё под завязку в ПЛИС заполнено ) , то пока не могу всю прошивку прочитать ( для этого надо прогу соответствующую писать - это чуть позже ).
  16. Цитата(serjj @ Apr 20 2015, 16:49) Нет, не меняет. Просто записывает его и всё. И если ниосом залить туже самую прошивку, то во флешке будет лежать тоже самое. Это Вы знаете на собственном опыте или из теории? Вот здесь я проверил - прочитанные из EPCS данные ( по крайней мере с нулевого смещения ) не совпадают с ранее туда записанным .jic файлом.
  17. По мотивам кодов в данной теме составил такой код: Код            unsigned int i;              alt_u8 data[16];                   // адрес EPCS контроллера              const alt_u32 EPCS_ADDR = EPCS_FLASH_CONTROLLER_0_BASE + EPCS_FLASH_CONTROLLER_0_REGISTER_OFFSET;              // смещение параметров модуля в EPCS - 0 байт              const alt_u32 EPCS_PARAMS_OFFSET = 0;              // режим байтов для EPCS              const alt_u32 EPCS_BYTE_MODE = 0;              epcs_read_buffer(EPCS_ADDR, EPCS_PARAMS_OFFSET, &data, 16, EPCS_BYTE_MODE);       for(i=0;i<16;i++)       {              IOWR_8DIRECT(ONCHIP_MEMORY2_0_BASE, 16+i, data[i]);       } Вроде всё нормально, но компилятор в Eclipse выдаёт предупреждение: warning: passing argument 3 of 'epcs_read_buffer' from incompatible pointer type [enabled by default] Что бы это значило? В EPCS записан .jic с таким .map файлом: BLOCK START ADDRESS END ADDRESS Page_0 0x00000000 0x0006AD41 ПЛИС Cyclone 4 GX с этого файла нормально стартует, правильно грузится прошивка и правильно выполняется программа НИОСа. Судя по всему если я буду читать эту EPCS с нулевого смещения , то первые три байта должны быть 0x4a 0x49 0x43, что соответствует кодам букв JIC ? Потому что эти 3 буквы я вижу с нулевого смещения в .jic файле если посмотреть его в HEX Editor. А чтение EPCS с нулевого смещения вышеприведённым кодом даёт первые 16 байт равные 0xFF. По более старшим адресам ( читаю окнами по 16 байт ) в EPCS лежат уже не 0xFF, но прочитанные значения не находятся в .jic файле если поискать их с помощью HEX Editor. UPD Сделал запись в область со смещением , а потом чтение, всё верно получается - прочитанное совпало с записанным. Код            int i;             int j;             alt_u8 data_A[16];             alt_u8 data_B[16];                  // адрес EPCS контроллера             const alt_u32 EPCS_ADDR = EPCS_FLASH_CONTROLLER_0_BASE + EPCS_FLASH_CONTROLLER_0_REGISTER_OFFSET;             // нулевое смещение параметров модуля в EPCS             const alt_u32 EPCS_PARAMS_OFFSET = 16*65536;             // режим байтов для EPCS             const alt_u32 EPCS_BYTE_MODE = 0; for(i=0;i<16;i++) { data_A[i]=i; } epcs_write_enable(EPCS_ADDR); epcs_sector_erase(EPCS_ADDR, EPCS_PARAMS_OFFSET, EPCS_BYTE_MODE); epcs_write_buffer(EPCS_ADDR, EPCS_PARAMS_OFFSET, &data_A, 16, EPCS_BYTE_MODE); epcs_read_buffer(EPCS_ADDR, EPCS_PARAMS_OFFSET, &data_B, 16, EPCS_BYTE_MODE); for(j=0;j<16;j++) { IOWR_8DIRECT(ONCHIP_MEMORY2_0_BASE, 16+j, data_B[j]); } Почему же прочитанный из EPCS .jic не совпадает с .jic файлом?
  18. Если использовать драйвер epcs_commands.h, то надо ли делать какую-нибудь инициализацию или сразу можно читать командой epcs_read_buffer ?
  19. Тогда в чём в итоге была проблема? Я сейчас похожую штуку буду применять, поэтому интересно. Не могу даже поиском по сайту Альтеры найти описание на epcs_commands.h чтобы понять - как это функция epcs_write_buffer возвращает тип alt_32 и что это вообще за тип alt_32.
  20. Цитата(Wic @ Oct 25 2011, 11:51) После прочтения темы Решил не пользоваться HAL, а использовать драйвер "epcs_commands.h". Написал такой код Код#define EPCS_ADR 523776 alt_u8 data[15]; alt_u32 j;      j = epcs_read_buffer(EPCS_FLASH_BASE+EPCS_FLASH_REGISTER_OFFSET, EPCS_ADR, &data, 15);      for(i=0;i<15;i++)      {          printf("%x\n",data[i]);      }      data[0]=0x00;      data[1]=0x01;      data[2]=0x02;      data[3]=0x03;      data[4]=0x04;      data[5]=0x05;      data[6]=0x06;      data[7]=0x10;      data[8]=0x20;      data[9]=0x30;      data[10]=0x40;      data[11]=0x50;      data[12]=0x6C;      data[13]=0xAA;      data[14]=0xFF;      j = epcs_write_buffer(EPCS_FLASH_BASE+EPCS_FLASH_REGISTER_OFFSET, EPCS_ADR , &data, 15);      j = epcs_read_buffer(EPCS_FLASH_BASE+EPCS_FLASH_REGISTER_OFFSET, EPCS_ADR, &data, 15);      for(i=0;i<15;i++)      {          printf("%x\n",data[i]);      } В пятницу всё прекрасно работало. Три дня меня не было, прихожу - часть переменных читается нулями, а в части лежат нужные данные. Пытаюсь писать туда нужные значения. Ничего не меняется. Подскажите в чем может быть причина. Возможно, что причина в этой строчке? j = epcs_write_buffer(EPCS_FLASH_BASE+EPCS_FLASH_REGISTER_OFFSET, EPCS_ADR , &data, 15); Что Вы хотели с её помощью получить? Как можно переменной j присваивать действие процедуры epcs_write_buffer ? Это корректно? Ведь в следующей строке этой же переменной j присваиватся результат действия процедуры epcs_read_buffer.
  21. Цитата(serjj @ Apr 20 2015, 15:21) Если использовать Nios flash programmer, утилиту встроенную в Eclipse, то да. Логично предположить, что если писать "вручную", то тоже да. Судя по Вашему ответу Вы меня не правильно поняли. Я просил сравнить 2 варианта записи одного и того же .jic файла в EPCS в 2-х вариантах: 1). в Квартусе через JTAG с помощью USB Blaster 2). командами NIOS-а используя соответствующие команды драйвера epcs_commands.h Вопрос: При условии корректной записи в обоих вариантах в EPCS получится один и тот же битстрим или будут отличаться? Другими словами, Квартус через JTAG с помощью USB Blaster-а записывает .jic файл в EPCS один в один или что-то в нём меняет перед записью?
  22. Цитата(sdimann @ Jul 23 2014, 05:33) В общем, частично разобрался. Я программировал флеш квартусом через индирект (.jic), предварительно конвертируя файлы. Скажите пожалуйста, если один и тот же .jic файл записывать в EPCS через JTAG в Квартусе с помощью USB Blaster и напрямую командами NIOS-а ( используя соответствующие команды драйвера epcs_commands.h ), то в EPCS получится один и тот же битстрим?
  23. Цитата(Stewart Little @ Feb 9 2015, 15:09) Давайте рассмотрим ситуацию, когда у Вас в процессе перезаписи EPCS'ки происходит сбой. В этом случае для приведения оборудования в чувство потребуется рукопашное вмешательство. Насколько высока вероятность сбоя в процессе перезаписи EPCS'ки? Это перестраховка или реально частые сбои? Цитата(Stewart Little @ Feb 9 2015, 15:09) Обычно делают не так. Создается две прошивки - базовая (factory) и приложение (application). И обновление приложения осуществляется из factory-прошивки. Вот какая у меня ситуация. Factory прошивка, которую надо обновлять у клиента, была залита в EPCS16 в виде .jic файла. Схема конфигурации - Active Serial. Вот как выглядит .map файл от .jic файла: BLOCK START ADDRESS END ADDRESS Page_0 0x00000000 0x00068E4A - All the addresses in this file are byte addresses Размер .jic файла примерно 420 Кбайт, т.е примерно 1/4 от размера EPCS16. Я планировал сделать так: 1). Записать с помощью NIOS-а ( используя соответствующие команды драйвера epcs_commands.h ) начиная с адреса 0x00080000 в EPCS16 новую Application прошивку в виде нового .jic файла. 2). Задать ( пока не выяснил - где именно ), чтобы при включении питания загрузка прошивки происходила не с адреса 0x00000000 ( там находится прошивка Factory ), а с адреса 0x00080000 ( там находится прошивка Application ). Поскольку прошивка в виде .jic файла содержит ядро PCIe, то у меня сделано так, что конфигурирование и инициализация Cyclone 4 GX выполняется за время менее 0,1 секунды ( иначе плата с ядром PCIe не будет опознана в ПК ). Я хотел бы понять, смогу ли я использовать Remote System Update, учитывая это ограничение по времени? Дело в том, что имеющаяся в Remote System Update проверка того, загрузилась ли нормально Application прошивка с адреса 0x00080000 или нет, и не надо ли вернуться к прошивке Factory не имеет смысла, т.к при этом время 0,1 с ( за которое должен успеть сконфигурироваться и инициализироваться Cyclone 4 GX ) будет упущено. По этой же причине не имеет смысла вариант когда сначала грузится прошивка Factory, а затем она грузит Application прошивку. Значит остаётся только вариант писать новую Application прошивку в виде нового .jic файла с помощью NIOS-а ( используя соответствующие команды драйвера epcs_commands.h ) начиная с адреса 0x00000000 в EPCS16., т.е затирая при этом Factory прошивку? Какие могут быть при этом сбои? Ведь можно после записи прошивки сделать её чтение и проверить, а если были ошибки, то перезаписать неправильные байты заново. Остаётся только риск того, что отключится питание во время записи или что-то ещё может произойти из-за чего новая прошивкка не перезапишется на место Factory?