Добрый день! Помогите разобраться в множестве понятий, относящихся к embedded linux и к SoC от Altera (плата Arrow SoCkit)
Передо мной стоит задача передать поток данных с ПЛИС на ПК через ethernet.
Решил на процессор поставить linux, на linux написать программу для передачи данных по ethernet и с помощью терминальной программы принимать данные (16-ти битное слово с частотой 500 кГц)
На сайте http://rocketboards.org/ начал изучать материалы по этому вопросу и немного запутался с терминами:
1) Golden System Reference Design - provides a set of essential hardware and software system components that can be used as a starting point for various custom user design.
Получается что GSRD - это набор драйверов, preloader, bootloader, дистрибутив linux, компонент процессора в qsys, bsp? Т.е это готовый toolchain для заливки в fpga?
2) BSP - из wiki - набор драйверов, встраиваемый в ОС.
Получается в каждый дистрибутив идет без bsp и его надо подключать отдельно?
3) В квикстарте http://rocketboards.org/foswiki/view/Documentation/ArrowSoCKITEvaluationBoard141LinuxGettingStarted описан процесс загрузки линукса, в котором мы делаем загрузочную SD-карту и получаем линукс, которым мы можем управлять с помощью терминальной программы (putty), хотя в мануале по HPS (hard processor system) явно указано, что для загрузки линукса требуется bootrom, preloader, bootloader.
Так что требуется для загрузки linux?

У вас все в кучу свалено.

Рассматривайте SoC как два отдельных устрйоства.
Процессор с ARM Cortex-A9 и FGPA.

Сейчас я рассматриваю SoC именно как два разных устройства.
Сообщения выше относятся к ARM Cortex-A9, так как именно на него я буду ставить linux.
Как раз таки я хочу разгрести эту кучу и расставить все по полочкам.

Тут описан процесс загрузки линукса.
http://rocketboards.org/foswiki/view/Docum...1#HPS_Boot_Flow

Вкратце - вам надо собрать Preloader, U-boot и найти образ ядра под свою плату. Или собрать свое ядро, если плата уникальная.

Какая скорость? Какой протокол?

В первом сообщении я дал ссылку на мануал, в котором описывался процесс загрузки линукса без preloader и bootloader. Сделал все по этому мануалу и получилось через терминал (putty) поморгать диодиками на плате. Поэтому у меня возник вопрос - а почему так получилось? Так как я не собирал ни прилодер, ни бутлодер!


Данные - это 32 разрядное слово идет с частотой 500 кГц.
Как мне посоветовали надо делать tcp/ip

Получилось потому что Вы прошили готовые образы для платы на SD карту и все.
Вся работа по сборке была сделана за Вас.

вот тут почитайте, вполне доступно расписано:
http://habrahabr.ru/company/metrotek/blog/235707/

Ну это всего 8 Мбит/с. Посылать 4 байта через Eth нецелесообразно, если есть возможность, то лучше копить несколько слов, хотя бы байт до 32-64, а потом уже слать их. Eth не предназначен для частой посылки сверхмалых пакетов. Гораздо выгоднее слать сразу пачку. У вас точка-точка или устройство должно будет работать в сети со сложной топологией? Зачем вам tcp/ip? Может лучше взять обычный udp, который прост как валинок? Если у вас данные супер отвественные, то можно сгородить собственную систему подтверждения доставки и запроса на пересылку в случае ошибки. Если всё так, то вам можно не связываться с EMAC в составе HPS, линухом, dma и прочим. Вы можете взять свой/чужой простенький Eth контроллер с интерфейсом Avalon/AXI4, он на ура подключается к AMR через FPGA2HPS bridge. На него пишется простенький драйвер с поддержкой UDP/ARP/ICMP, больше вам ничего не понадобится.

Спасибо за разъяснение, где то вычитал, что bootrom находится во флеш-памяти процессора, поэтому и ввел самого себя в заблуждение.


Сразу наткнулся на эту статью, но так как процесс заливки отличался от того, что представлено на rocketbard, решил повременить с разбором этой статьи.




У меня точка-точка. tcp/ip - потому что на форуме посоветовали.
Был вариант разбираться с bare-metal, но информации оказалось очень мало.
Вариант с линуксом я выбрал, так как опыта написания дров у меня нет, вещи то может быть это и простые, но представления у меня о них очень слабые.

Зачем для такой задачи Linux и SoC?
Может хватит обычного микроконтроллера?

Цифровая обработка происходит в fpga, в SoC находится еще и процессор! Думаю отличный повод начать изучать что-то новое.

Вам tcp/ip тут совершенно не нужен. Точка-точка, смешная скорость, udp пойдёт на ура, а с tcp запаритесь, кроме того у него избыточность выше чем у udp, он ещё меньше подходит для вашей задачи частой передачи маленьких сообщений.
А в чём проблема с baremetal? Суть такая же как и в Nios. Для периферии используется hwlib. Хелпом на него являются его исходники, а именно h файлы, там по каждой функции избыточная справка дана.
Дрова вам нужно будет писать не на HPS компонент, а на собственный eth, банальнейший memory map device. Если есть опыт с avl, но нет с axi, то можно смело писать под avl, т.к. qsys автоматически обеспечивает поддержку с avalon'ом при подключении hps компонента через fpga2hps. К драйверу нужно добавить 3 простых протокола: arp(для определения в сети), icmp(пинг) и udp(данные), а в программулине у вас сделать если требуется надстройку в виде контроля целостности (например по frame id, но это уже совсем тривиально).
Здесь всё будет прозрачно и написано вами. А теперь представте, что у вас на вашей плате (не отладочной) под линухом, который вы доблестно собрали начинаются проблемы с tcp/ip, ваши действия?

Если написано arp, icmp, udp, то добавив тривиальщину в виде контроля целостности пакета, и контроля пропуска-повторения, что вас будет отличать от ТСР?
А потом захочется чтобы IP плате выдали, и чтобы в хаб оно воткнулось, и чтобы из другой подсети было доступно, и чтобы настройки сетевые можно передать, и понеслась....

так что я бы сказал есть 2 варианта:
1. это просто формирователь UDP пакетов и все, есть даже реализация полностью в железе
2. полноценный стэк до TCP/IP с DHCP, всякие виртуальные сети и каналы в целом можно опустить.

И конечно же его не надо писать, надо взять готовый, стабильных и полноценных вариантов в природе много. В этом стеке мало славы, много надо написать, мало что придумать, обертки данных и обсчеты CRC, и зачем это самим писать?

то что это не весь стек, а только опция, которая вам нужна, для обеспечения надежности передачи важной информации, если таковая требуется. При этом добавляемые избыточность/сложность минимальны и определяются разработчиком.

ip входит в udp. Через хаб это работать будет. Настроить ip адрес по сетке через предложенную схему тоже можно (я собственно так и делаю).
Я в своих рассуждениях отталкивался только от оговоренной задачи. Исходя из условий, не вижу тут никакой надобности в универсальном сетевом изделии с поддержкой всевозможных протоколов, имхо для простой связи железка - свич - пк перечисленных трех протоколов хватает.
ps. ну и если есть желание включать железку, которая работает по точка-точка, в большую сеть, то есть немалая вероятность призвать админов