Анализируем CFlash B&R

Ошибка

На одном из эксплуатируемых объектов произошла следующая ошибка:

Синий экран смерти от B&R Industrial Automation GmbH 😆 И начали мы разбираться. Самой главным тормозящим фактором стало то, что у нас отсутствовали исходники исходного проекта, залитого на флеш карту.

Первым делом через стандартную утилиту Runtime Utility Center делаем бэкап флеш карты (вот пример видео на Youtube).

Имеющаяся карта на 4 гигабайта не подходила по байтам, поэтому бэкап этой же утилитой не получалось развернуть.

Я купил 16 гиговую cf card, бэкап восстановился, но панель-контроллер с неё не загрузился. Эксперимент с загрузкой 8 гиговой картой проведут позже, как проверим - отпишусь).

Файлы

Пока перейдём к эспериментам с 8 гиговой картой памяти. Бэкап на неё был успешно восстановлен и я перешёл к просмотру файлов HEX редактором. Из анализа файлов я сделал следующие выводы.

Работает это чудо на VxWorks 6.9.4.1 (файл bootrom.sys) - всем известная система реального времени.

В папке \System\TOC есть файлы fscfg.xml и ftoc.xml. fscfg.xml описывает структуру памяти FILESYSTEMCONFIGURATION - в ней можно узнать, что, где и для чего используются нужные папки и разделы. ftoc.xml описывает TOC (Table of Contents судя по всему). В ней можно узнать нужные нам файлы, принадлежащие к ОС. По идее, в корне должны были сохраниться резервной копии mbr.dat и bootloader.dat (которых не хватало моей флешке).

Для копии MBR под Linux нужно всего пару команд (мы просто копируем первые 512 байт в файл), но мы работаем под Windows, поэтому воспользуемся утилитой: mbr-backup.

Для бинарной копии карты воспользовался утилитой ImageUSB (копирует разделы вместе с MBR) - бэкап развернуть на 4 гиговую флешку меньше объема проведу в ближайшее время. Но так же советуют все утилиту usb-image-tool - пока не пользовался, ничего про неё не скажу.

Расположеный в корне файл arimg - это ELF файл. Это одна из разновидностей форматов для исполняемых и объектных файлов, используемых в UNIX-системах. Ничего интересного в целом там не нашел, можно увидеть, откуда и какие библиотеки компилировались при сборке проекта.

Больше всего интересного нашел в файлах папки \RPSHD\SYSROM.

Почитав официальную документацию (страница 46), нашел способ посмотреть логи через файл arlogsys.br. У Automation Studio есть модуль Automation Studio Logger (логичное название) - через него можно посмотреть события, произошедшие в контроллере.

В корне есть много файлов с именами 00000003-9.br Нас интересует больше два файла: 00000003 и 00000006 (либо 00000008 - они одинаковые по составу).

В 00000003.br можно увидеть всю структуру корзины (и удаленной тоже).

В 00000006.br: у порта IF3 можно увидеть IP адрес -

<n ID="IF3">
<d ID="DeviceParam" dt:dt="string">/EDDN=gei /HOST= /BD=0 /DEV=IF3 /IP=192...   /SNMK=255... /SNMP=2 /EDDN=gei</d>
</n>

SDM включен (и веб сервер тоже), поэтому диагностика через Web интерфейс пойдет:

<n ID="SDM">
<d ID="enable" dt:dt="string">1</d>

SMB и FTP влючены, но пароли по FTP шифрованы опять не понятно каким алгоритмом.

<n ID="ETHERNET">
<d ID="DefaultUserName" dt:dt="string">guest</d>
<d ID="DefaultPassword" dt:dt="string">password</d>
<n ID="SOFTWARE">
<n ID="FTP">
<d ID="enable" dt:dt="string">1</d>
<d ID="protocol" dt:dt="string">1</d>

А, и название проекта есть ещё:

<n ID="SETTINGS">
<d ID="PrjId" dt:dt="string">Name_Config</d></n>

В папке \RPSHD\USERROM хранятся файлы проекта AU, из самого большого файла можно вытащить картинки в jpg/png (что я и делал). Там в целом ничего интересног для нас, остальные файлы представляют из себя xml либо базу sqlite с лишними байтами в конце.

На этом эксперименты с бэкапом флешки закончены и я перешёл к другому эксперименту.

Эксперимент №2

Скачал за пару часов последнюю Automation studio 4.2 и под ночь её поставил себе на ноутбук.

Я провел следующие эксперименты. Мне скинули проект с похожего объекта, что дали нам в поддержке B&R.

Билд полноценно не прошел (5 ошибок, не хватало шрифта какого-то гостовского), но саму систему собирает, что мне и нужно было.

В этом проекте сделано по уму: флешка разбита на три раздела - один системный, другие два под файлы проекта. Видимо, для экономии места, наш проект решили делать все в одном разделе. Создал загрузочную флешку, проверил MBR - записал его в файл.

Посмотрел так же файлы проекта на флешке - структура файлов в папке Sysrom аналогична, посмотрел готовые xml файлы и сравнил с нашим проектом. IP совпадает, название проекта совпадает - остальное различается, но это и логично. Выгрузил mbr в файл для следующей проверки.

MBR чистой флешки:

MBR флешки с проектом:

Произвел развертывание бэкапа, что восстанавливал в предыдущем эксперименте. Опять сравнил mbr - разница в пару байт, но так в целом совпадает. Так как панель сделана на Atom’e от Интел, то по сути - это простой ПК.

Скачал “надстройку” над Qemu - MobaLiveCD, которая позволяет запускать не только с ISO файла, но и загрузочные флешки. Попробовал на каждом проекте - каждый из них запускается (пример видео ниже).

Из этого следует, что карта памяти на 16 гигов должна была развернуться должным образом, но контроллер не понимает такой большой объем памяти. Осталось только проверить загрузку 8 гиговой карты памяти и произвести восстановление бэкапа 8 гиговой карты на 4 гиговую. Как обычно по результатам добавлю текст)

Эксперимент №3

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