Есть интересный прибор, под названием "Устройство концентрации данных", с предустановленным линуксом (урезанным по самые помидоры) на борту, и неким набором софта, который работает не так как надо (вообще не работает).
Нажмите для просмотра прикрепленного файла

Устройство размещается на подстанции и подключается к силовой линии, после чего посредством связи через PLC модем опрашивает счетчики электроэнергии.
Все это было сделано некими аутсорс-индусами, которые ничего не довели до ума, и по факту получили неработающую платформу сбора данных (и полтыщи вот таких железяк). В дополнение к этому не было получено никакой документации или схем.

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

Разобрав его, внутри обнаруживается чудная штука, а именно 2 платы, 1 плата - сам одноплатный компьютер с (слева направо) 2*100мбит сетевухами, 1 usb, 1 rs232 и разъемом под собственные модемы. (чудной гребенкой справа - соединяются платы между собой, да, корпус не экранирован и да, гребенка открытая )
Нажмите для просмотра прикрепленного файла

2 плата - непосредственно плата питания и plc-модем.
Нажмите для просмотра прикрепленного файла


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

Одноплатник построен на базе Freescale imx258(arm926ej-s, armv5te), 128ram и 256mb flash.

Нажмите для просмотра прикрепленного файла



Есть подозрения, что flash глючит, в консоли вылетают crc-ошибки, и концентратор периодами зависает.



Поэтому было принято решение поставить линукс на заведомо рабочую usb-flash и заставить устройство грузиться с него. В качестве образа был выбран пока arch arm linux для armv5te. Но железка упорно отказывается грузится с него.

Судя по документации на проц - он поддерживает загрузку как с внутренней памяти, так и с внешней по usb.
Для выбора режима загрузки используются "boot_pins"


Режим выставляется пинами, а конкретно W20 и V19, но как это сделать, не могу их найти разведенными на плате, надеюсь более опытные коллеги подскажут направление в котором надо рыть дальше.

Нажмите для просмотра прикрепленного файла

Вы представляете себе работу полноценного линукса на такой платформе?? У меня на мх6 подтормаживал, а проц гораздо шустрее вашего, памяти было 512оперы и сд-карта на 4 гига. То, что там было урезано по самые помидоры - сделано не просто так, а чтоб хоть что-то "крутилось". Но это все лирика, по сути - для данной платформы есть прога - MfgTools - скачайте с сайта фрискейла, так же есть еще прога - Cfimager - для создания загрузочной карты памяти. С усб-флехи этот чип не грузится.

По-моему, рекомендуемый производителем линукс - timesys buildroot, копайте в эту сторону, про всякие полные дебианы и убунту - забудте.

ЗЫ. Зделано довольно профессионально, уверены, что это не какой-либо фирменный девайс? Может к нему уже есть нормальный софт?

Не сочтите за флуд, но слава всем электронным богам, что эта хрень и 500 ей подобных не работают!

Того гада, что PLC придумал, надо было во младенчестве удавить!

Радиоприем на СВ, КВ из-за этой порнографии теперь не доступен как класс!!!

Полноценный не в плане какой-то супер производительности - а в плане поддержки библиотек и софта. Какой-то мощности особой не требуется от него, а собранные образы тоже слаквари под armv5te (с 64мб озу) намекают что это вполне жизнеспособно.
За наводку на проги - спасибо, буду пробовать



Железка проектировалась французской конторой sagemcom, права на железку (в плане эксплуатации и переделок) передали нам, но никакой документации или образов нет и на запросы вежливо посылают

mfgtools не поддерживает чипы imx25 (была какая-то версия, но так и не допилили - забили болт). С imx25 работает Advanced Toolkit (давно не поддерживается, работает только под XP).


Насчет профессионализма не уверен но деньги на плату явно не жалели.

О как еще оказывается!! Право передали, а доки нет... Похоже вас просто кинули на бабки, к сожалению. Так понимаю, что и схем никаких нет, если так, то похоже придется просто забить болт, как писал вышеуказанный товарищ, или платить еще немалые деньги, чтоб специалист срисовывал схему с многослоек, включая "убийство" одного комплекта для этого, и хорошо разбирающегося в линухах, чтоб допилил проги под конкретную задачу...Как-то так.



Я конечно не суперспец в плане линух, но дело было... Так вот с такой конфигой нормально работали только очень обрезанные линухи, аля openwrt и подобные, да еще винСЕ, 5 версии, все остальное тормозило, и даже очень...



Да, каюсь, с 5 мх-ой попутал Но ТСу скорей будет нужна Cfimager, для флешек, ну а тулзом, только если во встроенный нанд писать захочет.



Не гоните!!! Нормальный ПЛК, но для этих задач его нужно было проектировать на стм32ф4хх или подобных, тогда можно было проги писать в "чистую" и ненадо пилить линухи и т.д...

PLC в данном случае означало Power Line Communication - технология, вполне заменяющая "глушилки" радиостанций времён холодной войны. Только лучше и надежнее, чем они.

А главное помеха максимально приближена к приемнику

Никто не запрещает и здесь "проги писать в чистую". Другое дело, сколько это займет времени.

Тут в другом дело - ТС сказал, что плата вообще без документации, ну поставит он какую-нить линуху, а дальше? Ну заработает сетевая карта, если там физика разведена по референсу... Там навеняка еще куча всяких gpioшек куда-то идет, плюс спецмодемы и еще фиг знает чего, линуха ведь не "знает" это оборудование... Что под линухой, что без - это сложновато.



Точно, я это сокращение все, как логические контроллеры понимаю

По хорошему и надо только чтобы сетевуха заработала и plc-модем, он подключен по i2c шине.

Ну тогда поставить какую-нибудь FreeRTOS. Запустить под ним LwIP, а модем обслужить самостоятельно.
Модем - пустякое устройство. По любому пишется за месяц - два в худшем случае.

Ну да, ради этого я с линухами бы связываться не стал, тут даже без РТОСины можно.. Хотя есть уже порты на АРМ9 и для фриртос..



Странное какое-то подключение, модемы вроде как по уартам в основном включаются

внешняя флешка - это usb флешка чтоли? сомневаюсь, что он умеет грузится с mass storage.
это нужно корень монтировать на usb

Это сд карта, с усб он не грузится. Еще на плате есть нанд, но с ним сложнее.

Почему собственно линукс хочется "нормальный", всеми этими железками надо рулить удаленно (выдавать задания на опрос и включение\отключение потребителей) и мониторить их состояние (а их порядка 500 штук и счетчиков почти 50000 тысяч будет) - писать своим костыли и велосипеды для управления совсем не хочется, когда есть уже куча готовых. К примеру - управление puppet\ansible, мониторинг nagios\nrpe, доступ по ssh с ключами. Понятно что железо .....гомно, но что есть, то есть

Это все можно сделать через lwip. Конечно, я не настаиваю, если вы хорошый спец по линухам - то в добрый путь

тема загрузчика не раскрыта. Что у вас в качестве загрузчика? u-boot?
Как вы выполняете uname -a? Консоль? ssh?

psL
да, консоль через usb-rs232, а дальше уже sh

остановите юбут и посмотрите командой

есть ли переменная bootargs и что в ней хранится..
потом грузите систему, втыкаете юсб флешку и смотрите в логе появление юсб устройства
если все так, то есть смысл двигаться дальше..

Тут еще шальная мысль пробежала, если с данной SoC у нас проблемы, в части flash-памяти, производительности, линукса и тд - не проще ли будет попытаться провести распиновку коннектора (что соединяет платы plc-модема и SoC, 24-пиновый, справа на плате) и подключить туда что-нибудь аналогичное той же raspberry pi?

Судя по обрывкам документации модем подключается не по i2c, а по SPI. А проблем с его поддержкой у малинки, как я понимаю нет. Начальство такой вариант приняло.

Поставте туда стм407 или подобный, подключите модем по спи и еще что, там надо и будет вам счастье, запилите lwip, самое лучшее - вот платка, сразу с сетевухой уже - http://www.starterkit.ru/html/index.php?na...view&id=118

Дешего и сердито, в индустриальном диапазоне.

Все эти rpi и прочее - бытовка для студентов.

можно сделать сделать образы с текущей системы, а потом залить эти образы на usb-flash или nfs.
Для этого определяете что в каком разделе лежит через cat /proc/mtd и делаете образы dd , например так: http://wiki.openwrt.org/doc/howto/generic.backup
Потом из этих образов собираете rootfs и кладете его на usb-flash или nfs.

Ну или тупо скопировать всю фс на usb-flash или nfs и поменять параметры u-boot или fstab


ну да, lwIp конечно круче полноценного tcpip стека...

Видимо основная ценность прошивки в ПО управления модемом по spi. Если это ПО есть в исходниках или его можно запустить на сторонней системе, то имеет смысл поменять процессорный модуль. В противном случае видимо это будет разработка системы почти с нуля.

Кстати, Это не nand "глючит". Это особенности работы jffs на NFC freescale. Здесь http://www.spinics.net/lists/u-boot-v2/msg05730.html например пишут, что нужно использовать ubifs

А причем тут круче?? Его вполне хватает для организации удаленного управления и вебморды, сомневаюсь, что ТСу очень нужны скриптовые языки, апачи и т.п.



Вряд-ли, ТС писал, что ему отдали голую железяку без софта и доков..

Вот не знаю, зачем давать советы из разряда "...до основания, а затем..."
Интересно, как для lwIp реализовать следующее: управление puppet\ansible, мониторинг nagios\nrpe, доступ по ssh...? Один месяц для такой задачи как-то оптимистично.

Можете доходчиво объяснить, для чего это все в задаче ТСа?? Ну, ssh я еще могу понять, но зачем инструментарий для управления серверами масштаба предприятия??

Это нужно, например, для создания централизованной системы мониторинга на основе этих 500 устройств.
nagios\nrpe - для запуска команд монитринга на устройстве;
puppet\ansible - для централизованного управления параметрами парка устройств;

Или nagios им тоже с нуля написать?

C lwip можно разве что через snmp v1 все это обьеденить, а лезть на 500 устройств через веб-интерфейс настраивать - не комильфо.

Я делал мониторинг 1000 устройств по gprs-модему с использованием tcp пакетов без всяких наворотов на авр контроллере, конфиг был тоже по tcp. Все работает уже 4й год, так что будте проще - и к вам потянутся, будет надежная и стабильная работа

А на сервера вы тоже по ssh любите ходить, особенно если их больше 20 штук? К примеру чтобы обновить пакет на них или конфиг чуть-чуть подправить? Конечно это можно сделать все и на АВР, вопрос в том - сколько костылей придется еще собрать\написать и как это дело поддерживать.



Именно так, выдавать команды на включение\отключение потребителей, проводить мониторинг, обновление по, а так же внедрение дополнительных концентраторов и счетчиков. Со своими костылями это ни чем не будет отличаться от сегодняшней системы. Тут либо пытаться использовать что-то стандартизованное, распространенное, либо совсем уходить в сторону вендорских решений, типа матрицы, энергосферы и тд.

Говоря о системе управления в текущем виде....кхм...

Первым делом было предложено отказаться от тех граблей(Софт учета и опроса - тоже дикий самопал, раскидан по 7 linux-серверам, тут и centos\debian\ubuntu\ubuntu server\opensuse, тут и postgresql, mysql, ibm db2, и еще много классных штук, вроде rabbitmq, своих скриптов на python 2.7, python 3, java, bash......в общем тот еще ад, трэш и содомия) и барахла, что установлено и перейти на матрицу\энергосферу, с адаптацией их концентраторов под наши счетчики. Выставили ценник под 10млн только за доработку и начальство сказало - думаем сами, что сделать с текущим добром. По бюджету - Уложиться надо в 50-70 евро на 1 концентратор(это прям потолок), без учета стоимости разработки ПО для опроса счетчиков по PLC, но там тоже не ахти деньги.

Оборудование серверное - навороченные netapp'ы, dell'ы, cisco, juniper, hp. Все настроено так же на от...ись, к примеру полки и сервера по 1gbit iscsi подключены....вот...

И да, это коммерческий учет, хотя и "опытная эксплуатация".

Софт по большей части закрытый, без исходников. Поэтому и было принято решение постепенно отказаться от этого добра. Ах да, потрачено было очень много денег, вот прям много, для такого качества

Понимаю, что малинка это из разряда индуского добра, и это не самый правильный вариант. Однако на нее подталкивают ошибки CRC флэш памяти в логах и рандомные зависания концентраторов, а так же необходимость использовать только родные 3g модемы, которые 220 евро стоят и выходят из строя с завидной регулярностью. Распаивать usb-хаб на плате считаю еще большими костылями слотов под microsd нет, usb всего 1


Ах да, отдельно доставляет тот факт, что данную SoC и плату питания с PLC модемом соединяет вот такая прикольная гребенка, при том что корпус не экранированный и устанавливается это добро как правило просто на стене
Нажмите для просмотра прикрепленного файла

Я приводил пример взаимодействия конечного оборудования (контроллера сбора данных с модемом) и сервера в инете. Мониторингом самих серверов занимался другой человек, что он там наставил была не моя задача. Мной было сделано - сами контроллеры, протокол обмена и настройки и та часть на сервере, которая "общалась" с удаленными девайсами, складывая данные в базу на мускуле...

mantech
Конечно использование здесь Rpi + puppet - это немного из пушки по воробьям, но опять же повторюсь - написание своей системы управления, системы мониторинга встанет еще дороже, нежели все их проапгрейдить до Rpi и использовать готовые, проверенные компоненты.

Может мы о разных вещах говорим, но в чем сложность сформировать пакет с параметрами, сунуть его в tcp сокет и послать девайсу, а от него получить данные по счетчикам или еще что, и послать серваку, в таком же пакете, а там уже распарсить его хоть тем-же пхп, например?? Создать базу данных конфига и принятых данных от девайса и обрабатывать их дальше, как нужно в задаче?? Ну на 10 лямов точно не тянет
Я за всю разработку и тестирование взял всего 500к руб.
Хотя каждый сам за себя решает, что ему ближе

ЗЫ. Сомневаюсь, что для всего 500 девайсов нужны какие-то навороченные серваки, да еще и во множественном числе, разве, что в горячем резерве... Скорости опроса и поток данных там скорей всего никакой.

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

Я это все прекрасно понимал и поэтому выбрал modbus-tcp и просто и стандартно, чем не вариант? Или сейчас все считают, что он безвозвратно устарел...

Если есть NAND то можно оттуда стартовать - сделать rootfs ro. USB монтировать если надо конфиги там держать