Realtek sdk что это

Обновлено: 05.07.2024

Мы продолжаем серию публикаций об электронных компонентах тайваньской компании Realtek, которые можно использовать для разработки мультимедийной и сетевой электроники.

На днях в нашем распоряжении оказалась демо-плата многопортового коммутатора RTL_8332M_DDR3_DEMO_P2L_V1.0 на базе свитч-процессора Realtek 8332M, а также фирменный комплект средств разработки. Под катом мы расскажем, что собой представляет эта плата, опишем процесс сборки и загрузки прошивки на основе Realtek SDK, а также протестируем пропускную способность полученного коммутатора с проверкой работоспособности QoS.

Демо-плата предназначена для разработки и отладки ПО для управляемого многопортового коммутатора c 24 портами Fast Ethernet и 4 портами Gigabit Ethernet. Основа используемых свич-процессоров — CPU MIPS-4KEc 32bit@500MHz, они позволяет управлять всеми функциями коммутатора.

Возможно, у читателя возникнет вопрос: для чего в наше время, «когда космические корабли бороздят просторы вселенной» может понадобиться разработка коммутатора Fast Ethernet. На наш взгляд, данное недорогое решение может быть востребовано в системах, где не требуется высокая скорость передачи данных. Например, подключение IP-телефонии и камер видеонаблюдения.

Порты: 24-port Fast Ethernet + 4-port Gigabit Ethernet
Встроенный Fast Ethernet PHY на 8 портов
Поддержка двух независимых XSMII-интерфейсов к внешним Fast Ethernet PHY
Интерфейс QSGMII либо 2 пары интерфейсов RSGMII/SGMII/1000Base-X/100Base-FX
Поддержка Serial/Dual I/O mode 32 МБ SPI Flash
Интерфейс к внешней памяти до 128 МБ DDR1/DDR2 либо 256 МБ DDR3
Ядро MIPS-4KEc с поддержкой адресации виртуальной памяти (MMU) на частоте 500 МГц
Встроенная память SRAM объемом 128 Кбайт
Два последовательных порта для отладки и контроля через интерфейс командной строки (CLI)
Поддержка отладочного интерфейса EJTAG
Поддержка интерфейсов EEPROM, I2C и SPI
Поддержка EAV, 1588v2
Поддержка диагностики Cable Diagnostics (RTCT)
Поддержка режимов энергосбережения IEEE 802.3az Energy Efficient Ethernet (EEE)

Функционал L2 VLAN

Максимальное количество VLAN 4096
Поддержка до 64 независимых процессов для MSTP (IEEE 802.1s), RSTP и STP
Тегирование Q-in-Q и VLAN

Функционал L2 MAC

Длина сетевых пакетов до 10 КБ
Таблица на 8K L2 MAC-адресов
Таблица на 512 мультикаст-адресов
Поддержка IGMPv1/2/3 и MLDv1/2 snooping

Другая функциональность уровня L2

Контроль трафика broadcast, multicast, unknown- multicast и unknown-unicast
Поддержка зеркалирования траффика
Поддержка агрегации каналов (IEEE 802.3ad)
Поддержка распознавания и изоляции закольцованного траффика (RLPP/RLDP)

Функционал Access Control List (ACL)

Поддержка формата L2/L3/L4 (DMAC, SMAC и Ether-Type)
IPv6 ACL

Функции QoS

8 очередей на порт
Обработка очередей по алгоритмам Strict Priority (SP), Weighted Fair Queue (WFQ) и Weighted Round Robin (WRR)

Комплект поставки RTL_8332M_DDR3_DEMO_P2L_V1.0

На фото ниже представлен вид платы сбоку, на нем хорошо видно порты:

Полученные нами средства разработки включают в себя toolchain, SDK с исходниками Linux и u-boot, а также некоторую документацию.

Сборка прошивки из Realtek SDK

Распаковываем toolchain и сразу прописываем пути к нему в PATH, чтобы bash знал, где его искать:

Распаковываем SDK, а также исходники u-boot и uClinux:

Выбираем версию linux и uClibc:
В SDK было 2 версии ядра Линукс – 2.6.19 и 2.6.32.58. С версией ядра 2.6.19 используется uClibc 0.9.28, а с версией 2.6.32.58 – uClibc 0.9.30. Мы использовали последнюю версию.

С версией ядра 2.6.19 используется uClibc 0.9.28, а с версией 2.6.32.58 – uClibc 0.9.30.

В настройках SDK включаем поддержку свитч-процессора 8332M:

В опциях Chip Support и SDK Driver указываем чип 8380:

В menuconfig-е ядра нужно изменить параметры загрузки на ”debug console =ttyS0,115200 mem=128M”, т.к. у нас используется чип с 128M памяти:

Сборка (сборка проходит успешно только с правами рута, поэтому нужно экспортировать вышеуказанные пути также и в PATH рута):

При сборке, не смотря на проведенную настройку в menuconfig-е, в консоль высыпается пара вопросов по настройке RTK BSP. Указываем чип 8380:

Если всё сработало, на экране выводится информация о собранном образе, результаты сборки кладутся в image/:

Загрузка собранного ядра

2) В расшаренную через tftp папку скинуть собранный образ ядра:

3) Подключиться к плате через UART, настройки для minicom следующие:

4) На плате грузится u-boot, нужно из него загрузить собранное ядро через tftp:

После загрузки Линукса запускаем DiagShell – command line interface для управления настройками свича.
В нем включаем нужные порты (или все):

Прошивка запущена, коммутатор работает.

Тестирование скорости

Замеры скорости мы проводили, подключив к плате 2 ПК c помощью программы iperf в двух режимах –LAN- и VLAN-подключение свича.

Через DiagShell VLAN был настроен следующим образом (например, настройка для портов 25, 26, 27 и vlan >
При тестировании VLAN проявляется интересный эффект: если VLAN настроить на диапазон портов, включающий порты 100М и 1000М, то скорость будет ограничена на уровне 100 Мбит/с, даже если оба ПК подключены в гигабитные порты.

Вот такие получились результаты тестирования:

Порт	Режим тестирования	Замеренная скорость (Мбит/с)
100M	LAN	96,2
1000M	LAN	936
100M	VLAN	95,7
1000M	VLAN	936

Можно сказать, что пропускная способность соответствует заявленной.

Теперь попробуем настроить QoS. Данная функция очень пригодится при настройке офисной IP-телефонии.

Как мы уже говорили, коммутатор поддерживает два алгоритма обработки очередей: Strict Priority и WFQ.
Мы ограничились проверкой Strict Priority. Для проверки подключили к плате три ПК. На одном из ПК запустили iperf-сервер:

На двух других ПК — клиенты:

При этом на одном из клиентов установили в IP-пакетах в поле DS значение 0x20 (DSCP 0x8), используя не очень задокументированную опцию -S:

Результаты замеров пропускной способности показали, что трафик распределился примерно поровну.
Теперь попробуем настроить QoS. Для этого зададим для DSCP 0x8 максимальное значение приоритета (7).

В результате маркированный трафик занял всю полосу пропускания. Что ж, похоже, QoS действительно работает.

Добавим несколько слов про DiagShell. На наш взгляд, этот CLI довольно функционален и вполне может использоваться при разработке готового устройства. Конечно, в идеале хотелось бы иметь некий интуитивный веб-интерфейс, который на данный момент отсутствует в SDK. Для конечного устройства его придется разрабатывать.

В целом можно сказать, что в результате мы получили тестовую плату многопортового коммутатора с возможностью разработки ПО. Такую программно-аппаратную платформу можно использовать для разработки недорогих управляемых коммутаторов Fast Ethernet для подключения к основной сети через порты Gigabit Ethernet.

Порты: 24-port Fast Ethernet + 4-port Gigabit Ethernet
Встроенный Fast Ethernet PHY на 8 портов
Поддержка двух независимых XSMII-интерфейсов к внешним Fast Ethernet PHY
Интерфейс QSGMII либо 2 пары интерфейсов RSGMII/SGMII/1000Base-X/100Base-FX
Поддержка Serial/Dual I/O mode 32 МБ SPI Flash
Интерфейс к внешней памяти до 128 МБ DDR1/DDR2 либо 256 МБ DDR3
Ядро MIPS-4KEc с поддержкой адресации виртуальной памяти (MMU) на частоте 500 МГц
Встроенная память SRAM объемом 128 Кбайт
Два последовательных порта для отладки и контроля через интерфейс командной строки (CLI)
Поддержка отладочного интерфейса EJTAG
Поддержка интерфейсов EEPROM, I2C и SPI
Поддержка EAV, 1588v2
Поддержка диагностики Cable Diagnostics (RTCT)
Поддержка режимов энергосбережения IEEE 802.3az Energy Efficient Ethernet (EEE)

Функционал L2 VLAN

Функционал L2 MAC

Другая функциональность уровня L2

Функционал Access Control List (ACL)

Поддержка формата L2/L3/L4 (DMAC, SMAC и Ether-Type)
IPv6 ACL

Функции QoS

8 очередей на порт
Обработка очередей по алгоритмам Strict Priority (SP), Weighted Fair Queue (WFQ) и Weighted Round Robin (WRR)

Комплект поставки RTL_8332M_DDR3_DEMO_P2L_V1.0

На фото ниже представлен вид платы сбоку, на нем хорошо видно порты:

Сборка прошивки из Realtek SDK

Распаковываем toolchain и сразу прописываем пути к нему в PATH, чтобы bash знал, где его искать:

Распаковываем SDK, а также исходники u-boot и uClinux:

С версией ядра 2.6.19 используется uClibc 0.9.28, а с версией 2.6.32.58 – uClibc 0.9.30.

В настройках SDK включаем поддержку свитч-процессора 8332M:

В опциях Chip Support и SDK Driver указываем чип 8380:

Если всё сработало, на экране выводится информация о собранном образе, результаты сборки кладутся в image/:

Загрузка собранного ядра

2) В расшаренную через tftp папку скинуть собранный образ ядра:

3) Подключиться к плате через UART, настройки для minicom следующие:

4) На плате грузится u-boot, нужно из него загрузить собранное ядро через tftp:

Прошивка запущена, коммутатор работает.

Тестирование скорости

Вот такие получились результаты тестирования:

Порт	Режим тестирования	Замеренная скорость (Мбит/с)
100M	LAN	96,2
1000M	LAN	936
100M	VLAN	95,7
1000M	VLAN	936

Можно сказать, что пропускная способность соответствует заявленной.

Теперь попробуем настроить QoS. Данная функция очень пригодится при настройке офисной IP-телефонии.

На двух других ПК — клиенты:

В результате маркированный трафик занял всю полосу пропускания. Что ж, похоже, QoS действительно работает.

Многочисленным пользователям PС тайваньская компания Realtek известна по своим контроллерам сетевых (Ethernet) и беспроводных (WiFi) карт, а также по микросхемам AC97-аудиокодеков. Однако у Realtek есть процессоры не только для применения в PC, но также для сетевого оборудования.

В рамках данной статьи мы познакомимся с отладочной платой и сетевым процессором Realtek RTL8954C, соберём и запустим базовое ядро Linux, а также выполним тест пропускной способности Ethernet-портов.

На заглавном рисунке представлена отладочная плата Realtek для процессора RTL8954C, мы использовали её в нескольких проектах по разработке абонентских роутеров LAN/WAN/WiFi c поддержкой VoIP-телефонии.

• SOC
— Встраиваемый центральный процессор, архитектура MIPS, частота до 620 МГц с встроенной технологией Radiax

• Функции L2
— 6 Gigabit Ethernet MAC свитч с пятью передатчиками IEEE 802.3 10/100/1000Mbps
— 1 выделенный порт GMII/RGMII/MII для соединения с внешней сетью
— Поддержка VLAN (таблица VLAN на 4096 значение)

• Функции L3
— 8 одновременных PPPoE-сессий
— Автоматическая настройка PPPoE
— Автоматическая проверка и генерация контрольных сумм IPv4

• Функции L4
— Поддержка NAPT для TCP/UDP-протоколов
— Автоматическая проверка и генерация контрольных сумм TCP/UDP
— Автоматическая работа L4 TCP/UDP, проверка генерация контрольных сумм

• Функции Firewall
— Создание фильтров Ethernet, PPPoE, TCP, UDP, ICMP, и IGMP-протоколов

• QoS (качество обслуживания)
— Каждый порт поддерживает 6-уровневую систему приоритета трафика. Приоритет трафика может быть обеспечен следующими технологиями: based on Port, 802.1p tag, DSCP, ACL-based priority и NAT-based priority
— Последовательные периферийные интерфейсы
— Поддержка одного PCI Express Host и одного PCI Express Slave
— Встроено 2 PCI Express PHYs
— 1 USB 2.0 host controller для доступа к USB-периферии
— Встроен 1 USB PHY
— 2 16550 UART
— До 44 GPIO-пинов

• Memory-интерфейс
— Serial Flash (тип SPI)
— SDR DRAM
— DDR1 DRAM
— DDR2 DRAM
— I2S-интерфейс

Комплект платы Realtek RTL8954C

Приступая к разработке, мы подписали NDA с Realtek и получили доступ к Realtek SDK для RTL8954C. C помощью этого SDK получилось без проблем собрать ядро linux-2.6.30 и базовую rootfs. Кит изображен на фотографии ниже:

Разъем для DECT-модуля
Панель LED-индикации Ethernet
Панель LED-индикации VOIP (V400/401)
Разъем PCI Express (IOH)
Штыревая вилка для подключения JTAG
Модуль WIFI
Штыревая вилка (UART)
Процессор RTL8954C
Кнопка DECT
Кнопка WPS
Кнопка сброса настроек к по умолчанию
Модуль LE88221 — SLIC с двумя FXS-портами
Разъем FXS1
Разъем FXS0
Разъем подключения внешнего источника питания DC 12V (Power)
Разъем подключения USB-накопителя
Разъемы подключения 4-х LAN-портов
Разъемы подключения WAN-порта

OS Linux-2.6.30
Toolchain rsdk-1.3.6-5281-EB-2.6.30-0.9.30
SDK для реализации VOIP-функциональности
Небольшой набор популярного OpenSource ПО, включая Samba

1. Выполнить установку на ПК системы Debian7.

2. Скопировать архив с SDK от Realtek в пользовательский каталог:

3. Выполнить разархивирование SDK:

4. Выполнить настройку конфигурационного файла для сборки прошивки:

Выполнить настройку собираемой прошивки, как описано ниже (см. скриншоты):

Выполнить сборку прошивки:

5. В папке image, если процесс прошел успешно, будут лежать файлы fw.bin, webpages.bin

6. Выполнить копирование файлов прошивки в директорию tftp server на ПК:

На ПК должны быть установлены следующие программы:
А) tftp-hpa — программа Linux TFTP-клиент, установка в Linux с помощью команды:

Б) tftpd-hpa — программа Linux TFTP-сервер, установка в Linux с помощью команды:

Прошивка платы Realtek RTL8954C

1. Выполнить подключение по UART к плате как показано на скриншоте ниже.
Программа для подключения — minicom (команда запуска: minicom –s)

2. На плате по умолчанию работает программа-загрузчик bootloder, а не u-boot. Для работы с сетью по умолчанию настроен адрес 192.168.1.6/24. Для обновления прошивки нужно настроить на ПК адрес из подсети 192.168.1.1/24 и подключить ПК и нашу плату в свитч.

3. Включить питание платы и нажать сразу «ESC» из терминала.

4. Выполнить запись прошивки на плату с ПК с помощью команд:

После записи прошивки плата перегрузится, далее нужно нажать кнопку «ESC» из терминала и прошить веб-интерфейс для платы

5. Выполнить перезапуск платы, отключив и включив питание.

Результат работы прошивки платы:
А) Доступ по minicom к загруженной системе для работы с файлами:

Б) Доступ к веб-интерфейсу платы:

Тестирование скорости передачи данных на плате Realtek RTL8954C на интерфейсе LAN и WAN

Теперь посмотрим, что умеет эта плата в плане сетевой производительности. Некоторые сетевые роутеры выполняют часть операций по пересылке данных LAN/LAN и LAN/WAN программно, поэтому возникают проблемы с производительностью. Ниже по тексту приводим один тест производительности сети с помощью портативного сетевого анализатора Ethernet-трафика и два теста скорости пересылки данных с ПК на ПК.

Тест производительности сети (LAN Bridge, NAT) на базе портативного сетевого анализатора Ethernet-трафика

Цель: протестировать пропускную способность RTL8954C пакетами различного размера, используя генератор трафика.

Тут будем пробовать 'модифицировать' SDK3.5 для ускорения старта и потребления для автономных устройств. Но это позже. Сейчас рассмотрим то, что позволяет последний на сегодня SDK 3.5.

Часть кода, для информации что примерно будем исследовать:

Main() запускает соединение WiFi по записанным ранее в Flash установкам.
Дополнительно в код включена поддержка нескольких отладочных AT команд.
В итоге, в резерве, в RTL00 остается около 200 килобайт неиспользованной RAM (пик во время открытого socked).

По питанию это выглядит так:

(1 клетка = 1 секунда, 0.58 mA - аппаратная ошибка модуля)

Активный участник сообщества

Как видим, похоже, что в SDK3.5 WiFi для соединения сканирует все каналы (начальная пила по питанию), а потом уже подключается. Зачем сиё действо - неизвестно - канал, куда подключаться WiFi, указан в переданных ей настройках для соединения. Так-же очень наворочены задержки отключения в wifi_off().
При смене тика RTOS эти задержки изменяются - это говорит о том, что их встроили просто так (безответственность писателей SDK!) Частично я уже изменил кванты некоторых опросов состояний WiFi с 1 секунды(!) на 20 ms в открытом коде SDK, но есть ещё закрытые. К примеру, инициализация или ожидание соединения WiFi опрашивается 20 секунд с интервалом 1 сек . SDK 3.5 рассчитано на 166MHz CLK CPU (а модуль от PADI стартует c reset на 83MHz ) но есть ошибки, описанные в Таймеры RTL8711. За счет этого при смене частоты CLK CPU тик RTOS меняется и всякие vTaskDelay() ведут себя не корректно, а приложение об этом не знает , меняется даже пауза beacon .
В таком виде текущее официальное SDK пока не может позиционироваться для использования в автономных устройствах. Требуются множественные "патчи". У кого какие предложения?

Активный участник сообщества

Ещё одна 'беда', если устройство просыпается через срок менее 120 секунд (TCP TIME_WAIT) и пытается открывать один и тот-же IP: PORT на внешнем сервере используя TCP, а закрывает соединение сервер или связь модуля была прервана путем отключения WiFi (например батарейка садится и модуль принял решение 'уснуть').
Когда модуль стартует, то у него число random в текущем SDK всегда одинаково - начинается с фиксированной последовательности. По этому номеру LwIP открывает порт для связи - см. tcp_new_port() и

Активный участник сообщества

Её вызов происходит в закрытой части либы при старте InfraStart(), до исполнения main():

nikolz

Well-known member

правильно ли я вас понял, что минимальное время затрачиваемое RTL на выхода из deep-sleep+связь с сервером +вход в deep-sleep составляет в исходниках 5 секунд, в вашем варианте 1.4 секунды?
Если так, то почему Вы утверждаете что это меньше, чем 0.34 секунды в ESP?

Активный участник сообщества

Как всегда вы всё искажаете Ещё не надоела работать на рекламу Espressif? Меняйте работу.
У ESP в стандартном SDK время активности между deep_sleep при просыпании с подключением к AP, получением IP в DHCP, передачей и приемом с внешнего WEB сервера данных составляет более 2-х секунд, обычно за 3.

У RTL, при изменении всего одной переменной - 1.2 сек. Думаю, что починят SDK, т.к. имеющаяся - бета. На прошлой версии установка связи с внешней AP была значительно быстрее, но драйвер WiFi изменили - сменили структуру обращений к таймерам на семафоры с таймерами.

Время от старта до включения WiFi в стандартном варианте SDK3.5b у RTL составляет 300 ms.
У ESP - в зависимости от режима - при использовании ранее сохраненных настроек оно меньше, при калибровке - значительно больше. У RTL в SDK не вписано сохранение настроек - оставлено на усмотрение пользователя. Вы же сравниваете именно этот параметр А минимальные временные характеристики для ESP были получены и реализованы мной, в большей части в моем meSDK - вы их и приводите, не уточняя что и как. Время получения IP от роутера модулем ESP у меня составляет от 0.7 секунд до 1.5. Роутер - ASUS RT-N56U. Ошибка у ESP с засыпанием-просыпанием после deep_sleep в последних SDK ESP с учетом ранее сохраненных параметров так и не исправлена. Просыпание в его SDK идет по ветке старта после критической ошибки с полной калибровкой WiFi, т.к. ошибка в последней процедуре выхода в deep_sleep - процессор выскакивает в область отключенной flash и в зависимости что там он найдет летит на вектор "протектед" с записью этого состояния причины перезагрузки в RTC и другие регистры. т.е. как повезет - как будет читаться открытая шина Исправлено патчем либы только в meSDK.

Пока разбирал общий случай (аналог первого холодного включения модуля после прошивки) c не фиксированным IP в роутере и без прочих предустановках. Далее, после починки глупости с таймерами в SDK, предполагаю слепить специализированный вариант. Но чуть позже..

Различия SDK RTL и ESP глобальны – в SDK RTL любой может изменить практически всё что ему требуется, т.к. есть все исходники, кроме драйвера WiFi. Драйвер WiFi общается с остальной открытой системой через глобальную структуру, в которой вы можете изменить любые процедуры. В ESP эта часть и уровнем выше (сохранение и запись установок WiFi и т.д.) является закрытой частью в SDK, как и все процедуры включений и выключений разных режимов sleep.

По этому у RTL использую понятие – стандартный SDK – это если взять исходный SDK и ничего не менять, но он на такое не рассчитан, т.к. позволяет изменять любые используемые ресурсы под вашу задачу. Разницу прочувствовали?

PS: кароче это надоело - постоянно уточнять безграмотному рекламщику Espressif nikolz разницу подходов в SDK RTL и ESP. Уже неоднократно сказано - по 99% параметрам RTL-ы лучше ESP, а отличия давно разобраны.
Если вас действительно интересует уровень драйвера WiFi в RTL, то в SDK дан список команд в component/common/drivers/wlan/realtek/src/osdep/wireless.h
rtl00TstMinAmebaV35a/wireless.h at master · pvvx/rtl00TstMinAmebaV35a · GitHub
Но что-то мне подсказывает, что вы не полезете на такой уровень Это уже уровень для написания сканеров WiFi и он открыт в данном SDK.

nikolz

Well-known member

Читайте также: