Ввиду занятости, не позволяющей многоуважаемому Padavan стать автором нашего сайта, выкладываю за него его изыскания по внутреннему устройству NMT-200, опубликованные на форуме IXBT.com, с разрешения автора и с некоторой модификацией текста (что может и не улучшит читаемость текста людям, далеким от мира Linux, но поможет жаждущим понимания). Этакий поток сознания – все в одном месте. Но полезно, поучительно, и по существу.

---

Дошли руки до поверхностного осмотра прошивки, встроенного линукса на попкорне а также самих Приложений NMT. Все что будет сказано далее, относится к последней, октябрьской прошивке и иногда будут сравнений с майской.

Syabas монтирует корневую систему Linux в RAMFS. Некоторые директории напрямую примонтированы к сигмаблокам, часть из них ROMFS, часть в SquashFS (оба read-only):

Есть два сигмаблока которые примонтированы в режиме чтения и записи и отформатированы в ext3:

То есть, в них можно записывать напрямую, как на обычный раздел диска.
Уточню – сигмаблоки это виртуальные партиции в NAND флеше.
Так как многие директории корневой системы Linux, включая /bin, /sbin, /usr реально распакованы в ОЗУ, то категорически не рекомендуется злоупотреблять устанавливаемыми через CSI приложениями, которые копируют в системные директории свой шлам. Это конкретно относится к CSI приложению busybox версии 1.14.1. При установке busybox, вы лишаетесь сразу более 7МБ ОЗУ, поскольку Ger Teunis какого-то лешего затолкал туда отлдачик gdb, который весит больше 6МБ. Это добро копируется в /bin (в скрипте запуска busybox) и сразу отбирает драгоценное ОЗУ. Если все же вам нужен полный busybox в замен порубленного штатного, просто удалите gdb, которым вы никогда пользоваться не будете (вы же не разработчик приложений для NMT?), для этого зайдите на NMT (по Samba или FTP) в папку /share/Apps/Busybox/ и отредактируйте файл startscript.sh, внеся ремарку # перед двумя строчками в секции start:

и перед одной строчкой в секции stop:

---

Далее развею миф о lighttpd. Все о нем говорят (так как CSI с некоторой версии стал его настойчиво рекомендовать к установке), но не многие понимают зачем оно. Не ставьте его и не морочьте другим голову, как это делает vaidyasr.
Не ускорит оно вам интерфейс ни на йоту, только внесет глюки.
Объясняю.
Весь пользовательский интерфейс попкорна, что мы видим на экране ТВ управляется одним огромным user-приложением, именуемым syb_framework. Оно делает все, что мы видим на экране и никто не способен его изменить, кроме Syabas. Если говорить грубо, то syb_framework – это и есть попкорновская оболочка, которая запускается под линуксом. Когда мы отдельно устанавливаем штатные Приложения NMT, то, как неотъемлемая часть приложений, запускается Web сервер. Не установим приложения, не будет Web сервера. Установим – он всегда будет стартовать, независимо от того, запущены какие-либо Приложения NMT или нет. Web сервер нужен чтобы подключаться к попкорну через http с клиентского компа и управлять извне через браузер приложениями:

• NZBGet (Usenet client);
• Transmission Gaya – причем не путать его с устанавливаемым через CSI Transmission-daemon, у которого свой собственный Web сервер. Лицо Transmission Gaya мы видим на ТВ в разделе //Веб сервисы//Торрент, его же можно увидеть извне через браузер;
• Доступ к интерфейсу попкорна через браузер;
• Доступ к некоторым другим CSI приложениям через браузер. Кроме тех, у кого встроенный Web-сервер (например, Oversight).

Syabas использует в качестве Web сервера Apache, он очень мощный, но довольно тяжеловатый. Причем используется конфигурация по умолчанию, и апач загружает сразу 6 процессов – основной и 5 дочерних, для обеспечения обработки запросов от огромного числа клиентов. Но так как попкорн это вам не Web сервер в интернете, то Apache можно настроить на один дочерний процесс, освободив ОЗУ и системные ресурсы.
А vaidyasr предлагает вместо Apache поставить lighttpd.
Но я бы не рекомендовал это делать, поскольку это довольно брутальное решение, так как, например, версия lighttpd 1.4.27 не тестирована вообще на C-200 и Web сервер не стартует на автомате, а только вручную через CSI. После загрузки плейера его нет в списках процессов. Версия 1.4.24 стартует. Также нужно грамотно настраивать Web сервер под конкретную версию NMT приложений, чего, естественно, никто не делал.
Подводя итог, хочу сказать что есть более изящное и прямое решение – достаточно отредактировать файл конфигурации httpd.conf от Apache, уменьшив количество дочерних процессов до 1, и тем самым освободить память и ресурсы системы. Для этого достаточно отредактировать файл /nmt/apps/server/php5server/httpd.conf, заменив следующие параметры следующими значениями:

Для того чтобы получить доступ на раздел к nmt приложениям, нужно иметь Lundman Shell и запущенный на попкорне Samba. Подключаемся через шелл и вводим команду:

После этого заходим по самбе на диск с приложениями и обнаруживаем директорию .nmt внутри Apps – это ссылка на системный раздел с NMT приложениями. Находим и редактируем там файл /server/php5server/httpd.conf, после чего перезапускаем попкорн.
После перезагрузки в процессах будет всего 2 процесса ./httpd.
Вуаля, прощай vaidyasr!

---

Немного по поводу сетевого MAC интерфейса SMP864x (их 2 штуки). Я исследовал их работу и сравнил драйверы tangox_enet в ядре майской и октябрьской прошивки. Различия есть. Прежде всего хочу сказать, что MAC интерфейсы SMP864x имеют слабое место и не позвояют на всю катушку работать даже в режиме 100Мбит/с. Речь идет от TX (передаче). Все что приходит к плейеру (RX) работает очень быстро. По NFS UDP достигается реальная скорость передачи 94Мбит/с, что очень хорошо. По TCP протоколу результаты немного хуже, из-за большого оверхеда TCP, но тоже хороши. По Samba достигается реальная скорость до 10.5 МБайт/с на прием. А вот с передачей у сигмы проблемы. Все что уходит от плеера (плеер – в роли сервера) имеет ограничение. На майской прошивке невозможно получить для TX ни на каком протоколе больше 6.4 МБайт/с. Даже по NFS UDP. Это потолок, в который MAC сигмы упирается и ничего сделать нельзя. Иными словами – сервер на базе сигма процессора при работе на встроенных MAC – плохой. В кернеле 2.6.22.19-27-4, который идет в августовской и октябрьской прошивке ситуация с tangox_enet улучшена, на RX скорость не изменилась (TCP ~10.5 МБайт/с), а вот TX стал лучше, причем заметно, получен потолок в 7.8 МБайт/с.
Речь шла о работе в чистом режиме 100Мбит FastEthernet.

Чтобы наглядно удостовериться в том что затык именно в MAC интерфейсах, подключил USB свисток DWA-140 revB2 (чип Ralink RT3070), загрузил через шелл модуль rt3070sta.ko, законнектился к точке доступа 11n и получил через USB свисток 12 МБайт/с по TX и 13 МБайт/с по RX. Беспроводной маршрутизатор DIR-655 A4, 11n 3xMIMO, LAN 1Гбит. В нем ограничений нет, в режиме гигабита с честными клиентами он прокачивает через свитч более 100 МБайт/с в обоих направлениях.

---

Раз пошла речь о WiFi, добавлю вот что. В октябрьской прошивке поддерживаются 3 типа адаптеров WiFI:

• MII-модуль NM-200 на Ralink RT2880;
• USB свистки на чипах Realtek RTL8188SU, RTL8191SU, RTL8192SU;
• USB свистки на чипах Ralink RT3070, RT3071, RT3072.

Причем сами модули ядра имеют очень большие списки поддерживаемых устройств по VID/PID, однако Syabas ограничил эти списки и в самом OSD-интерфейсе будет виден беспроводной адаптер, только если он:

• на базе USB Realtek чипа, свистки с vid/pid = 0bda/8172, 0bda/8174, 0bda/8171;
• на базе USB Ralink чипа, свистки с vid/pid = 148f/3070.

А в самих модулях ядра таблица поддерживаемых устройств в десятки раз больше, то есть, если драйвер загрузить руками, то свисток стартанет, но только не через OSD. Почему Syabas ввела ограничения? Наверное, чтобы покупали только “правильные свистки”.

---

Добавлю несколько копеек по поводу “недо-гигабита” у MAC интерфейса SMP864x. Хоть на оконечнике и установлен реально гигабитный PHY от Vitesse, я бы посоветовал воздержаться от использования гигабитного режима в C-200. Возможно на железе от Cisco ситуация и будет ровнее, но на тех рутерах домашнего применения, где стоит гигабитный 4-х портовый свитч Realtek RTL8366SR, а их очень много, включая популярный TP-Link TL-WR1043D и легендарный NetGear WNDR3700 – наблюдается следующая проблема при активизации гигабита:
Если кто помнит, в последних прошивках TCP Receive Window доступно только в режиме гигабита. В майской значение TCP Receive Window корректировалось и для 100Мбит (видно через sysctl), однако позже это исправили (оно не нужно для сотки). Дело в том, что TCP Receive Window – это не что иное, как “костыль” для работы псевдо-гигабитного MAC.

Вот системные параметры ядра без “костыля”:

А вот это с TCP Receive Window = 5289 (дефолтовый “костыль” для гигабита), видно что окно TCP зажато:

А вот это с TCP Receive Window = 32000 (больше нельзя поставить в этом поле через OSD):

Включаем гигабит. Если поставить TCP Receive Window = 32000, или совсем отключить “костыль” через sysctl, то в режиме гигабита начинаются проблемы, и MAC начинает в интерфейс пропускать мусор. В общем, имеем нарушение целостности пакетов, и при попытке проиграть поток, начинаются проблемы. При этом сеть как-бы работает, даные копирутся и причем быстро.
На гигабите TX уже перестает ограничиваться и дает около 13МБ/с (как будто 2 сложенных вместе MAC). RX также возрастает выше ограничения в 100Мбит. Если “костыль” вернуть в 5289, то все начинает работать почти нормально.
НО, это “костыль” для TCP!
А UDP при этом брошен на произвол судьбы!
И если подключиться попкорном к NFS серверу по NFS UDP-протоколу, то проиграть поток вообще невозможно. Идут ошибки и попкорн выбрасывает в меню или мертво подвисает в процессе проигрывания. Причем, если запустить на самом покорне NFS сервер и подключиться к нему с линукс клиента по NFS UDP, получаем впечатляющую скорость копирования, я получил более 18МБ/с. НО! данные могут содержать мусор!

После долгой возни я пришел к выводу, что “недо-гигабит” на текущей сигме – это действительно шаткий “костыль” и его лучше не использовать, а особенно для UDP. В процессе тестирования в режиме гигабита, получил 3 мертвых зависания на уровне ядра, и приходилось насильно выключать попкорн. Не реагировал на пульт, висело как OSD, так и сеть.

---

К вопросу о lighttpd, который запускает всего 3 процесса.

Apache с редактированным конфигом стартует всего 2 процесса (с завода 6). Даже если при этом апач сожрет чуть больше памяти, он лучше. Только потому что он настроен разработчиками (нужные модули, каталоги для Web хранилищ итд.). А так вы полагаетесь за настройку Web сервера от vaidyasr. То что vaidyasr ничего не тестирует, или тестирует плохо, мы видели по последним lighttpd и utils.

---

Насчет команд top и ps – они в столбцах процессов показывают не реально занимаемый объем в ОЗУ, а VMalloc. Реально занятие ОЗУ нужно смотреть по командам free, либо cat /proc/meminfo

---

По поводу ramfs и tmpfs, вы реально лишаетесь ровно столько ОЗУ, насколько скопировали в эти директории. Напомню, что у попкорна всего 192МБ ОЗУ под систему и отдать 6МБ под ненужный никому gdb из комплекта busybox – это преступление.
Его лучше отдать под кеш торрента, хотя я бы больше 8МБ не стал давать, так как если ОЗУ закончится, то попкорн зависнет. Не верите? Разрешите доступ на запись в папку /home путем chmod 777 /home и скопируйте туда файл в 100 МБ. Получите кирпич. Временно естественно, до выключения-включения плеера.

Попробую пояснить насчет ОЗУ и “шашечек”. Для Linux отведено всего 192МБ из имеющихся 512. Остальное ОЗУ отдано под HD декодеры и видеобуфер и недоступно операционной системе. При старте Linux кернела, он монтирует рут (/) в ramfs, и при этом распаковывает директории /bin /sbin /usr и некоторые другие прямо в ОЗУ. Т.е. все что в них находится, напрямую отбирает ОЗУ. Остальные директории монтируются в sysfs, proc (стандартно), /tmp монтируется в tmpfs (аналог ramfs). Часть директорий монтируется прямо из сигмаблоков и доступно для чтения (для ROMFS и SquashFS).

Если вы что-то копируете в директории, которые смонтированы как ramfs и tmpfs, вы сознательно отрезаете ОЗУ. Чем меньше ОЗУ, тем хуже. Для примера я предложил скопировать 100 -120 МБ в ramfs директорию, это приведет к полному зависанию системы. Так как ramfs директории распакованы в ОЗУ, любое изменение в них (удаление/добавление/модификация) будут иметь силу до перезагрузки системы. После новой загрузки в этих директориях будет оригинал, который распакуется их сигмаблоков.

---

Еще раз касательно busybox. То что находится в CSI – это просто скомпилированная версия busybox 1.14.1 со всеми апплетами. Оригинальная, входящая в комплект Linux-приложений в прошивке NMT, имеет версию старее и собрана без части апплетов.
GDB – это системный отладчик под Linux и он никаким боком к busybox не относится и лежит там как бонус. Чтобы грамотно установить busybox, нужно переделывать старт/стоп скрипты. Сейчас каждый раз при старте busybox из CSI архивирует старый (штатный) тут же прямо в /bin, копирует туда новый и запускает команду busybox –install, при которой создаются хард-линки на busybox (они не занимают места) и копирует gdb. Итого в /bin содержится старый и новый busybox и плюс gdb. Скрипт нужно переделать так, чтобы оригинальный busybox архивировался на диск (в /share/Apps/busybox/bin), а новый перезаписывался в /bin. И не устанавливать gdb.
То есть, в файле \\PCH-C200\share\Apps\Busybox\startscript.sh вместо существующего:

необходимо внести правки как:

Не забываем, что /bin это ramfs и после перезагрузки /bin всегда будет содержать оригинал (то что заложено в прошивке), так что напортачить тут невозможно, даже при всем желании.

Отдать 7МБ ОЗУ при текущей инсталляции базибокса из CSI это очень большая глупость. Эти 7МБ просто исчезнут для системы без дела. Как я уже говорил выше, лучше их отдать под кеш трансмишна, это будет гораздо полезнее.

Конфиг трансмишна также обязательно нужно редактировать, так как по дефолу 240 пиров и 60 пиров на торрент – это слишком жирно для встраиваемой системы. Я бы не стал делать больше 100 пиров тотал и 20-30 пиров на торрент, это более чем достаточно даже для канала в 5 Мбит/с. Чем больше пиров подсоединит трансмишен, тем меньше ОЗУ останется для системы, ведь каждый пир требует распределение блока памяти.