Bare metal EMAC драйвер на Cortex-A9, EMAC на Altera SOC HPS Опции

[serjj]

Всем доброго.
Вожусь сейчас с ARM Cortex-A9 в составе Altera Cyclone V HPS. Интересует следующее. На борту имеется EMAC Synopsys DesignWare 3504-0 Universal Ethernet MAC в числе двух штук. Разбираюсь с bare metal приложением. У Альтеры на EMAC не нашел ни одного примера по работе с ним и в библиотеки для bare metal (hwlib) тоже ничего к EMAC относящегося не нашел (при этом есть остальные интерфейсы кроме USB). При этом под линухом EMAC разумеется поднимается и в U-Boot тоже. Но ОС на него ставить пока в планы не входило. Вообще хотелось бы узнать насколько это неблагодарное занятие в bare metal поднимать Ethernet драйвер на ARM?
И возможно кто-то уже работал с этим Eth контроллером и на него можно достать готовые драйвера? (ARM же он ARM и есть) У меня пока каша в голове по поводу процессора, не программировал его раньше.

В общем хотелось бы услышать совета от спецов по ARMу

PS Раньше на простеньком Nios и самописном контроллере делал простой драйвер и надстройку в виде UDP/ARP и всё было просто, а тут такие дебри.

[serjj]

Коллеги, спасибо что отозвались.

в смысле, что без линуха поднимать это дело глупо, тупо и безнадежно

Тут дело такое, у меня изделие должно полностью грузиться в пределах секунды Линукс разве так умеет? И какие есть альтернативы bare metal для очень быстрой загрузки проца?

Так ведь u-boot и Linux есть в качестве примера. Драйвер u-boot вряд ли стоит рассматривать серьёзно, но для старта и он сойдет

Там беда в том, что их там целая куча под разные семейства-конфигурации-вендоров, при этом разной степени вменяемости (где-то init, packet_read, packet_write, а где-то тонна всякого хлама)

У меня есть вариант перенести на проц старое решение с Nios'a с самодельным контроллером, т.к. у меня Eth только для отладки нужен. Но хотелось всё таки со штатным EMAC разобраться, а то их там целых 2 и как-то странно свой ставить.

И раз про ОС речь зашла: насколько это вообще жизненная идея делать bare metal проект на ARM? Основные задачи - обработка сигналов, управление, решения, обмен с FPGA. Высокоуровневые сервисы а-ля web, snmp не нужны. Высокоскоростных интерфейсов тоже не планируется.

[aaarrr]

Там беда в том, что их там целая куча под разные семейства-конфигурации-вендоров, при этом разной степени вменяемости (где-то init, packet_read, packet_write, а где-то тонна всякого хлама)

Ну а в данном случае как?

И раз про ОС речь зашла: насколько это вообще жизненная идея делать bare metal проект на ARM? Основные задачи - обработка сигналов, управление, решения, обмен с FPGA. Высокоуровневые сервисы а-ля web, snmp не нужны. Высокоскоростных интерфейсов тоже не планируется.

Нормальная идея: ставить Linux просто из тех соображений, что железо это позволяет сделать, тоже неразумно.