Ninebot – Прошиваем из под Linux

Процесс резервирования/восстановления/обновления прошивки Ninebot One S2 в среде Windows через интерфейс SWD описан мной ранее - казалось бы тему можно считать закрытой. Однако набор инструментария и оборудования необходимого для реализации прошивки явно не пригоден для полевых условий (ноутбук с виндой, донгл JLink, инструмент для снятия крышки) … Да даже и дома крышку моноколеса часто снимать/ставить заморочишься и вскоре крючки сломаешь. Вобщем возникла идея реализации беспроводного доступа с целью перепрошивки моноколеса. Проект таков: для этого нам нужна «линуксовая машинка», которую мы спрячем внутрь моноколеса и будем иметь доступ к ее консоли через развернутую на ней точку доступа WiFi, понятно что также нужен интерфейс SWD и софт управления им.

Используем донгл JLink с одной из фруктово-ягодных платформ.

В Эске места не просто мало, а очень мало. Классического форм-фактора «малину/банану/апельсину» туда никак не запихнуть … Смотрим в сторону упрощенных версий «Zero». Квадратная «апельсина» отпадает из-за габаритных размеров, «малина» не имеет встроенного WiFi, да и проц всего одноядерный (как всегда малина в жопе) – а вот «банана» (как всегда на высоте) подходит вполне (BananaPi M2 Zero – цена порядка 20 баксов).

Для начала отлаживаем обкатанную под виндой цепочку с использованием донгла JLink – подбираем и настраиваем софт под линукс. Как нельзя кстати для данных целей подходит openocd.

  1. Устанавливаем OpenOCD:

    apt install openocd
     
  2. Добавляем в конфигурационный файл нашего донгла /usr/share/openocd/scripts/interface/jlink.cfg директиву выбора SWD-режима (по-умолчанию режим JTAG):

    transport select swd

  3. Запускаем openocd с указанием двух конфигурационных файлов (донгла и целевого контроллера), причем запускаем в режиме демона (символ & в конце строки, т.к. если этого не сделать, то для выполнения следующего шага нужно открывать еще одну терминальную сессию - до завершения, например по ^C, сервера openocd в текущей):

    openocd -f interface/jlink.cfg -f target/stm32f1x.cfg &

  4. Подключаемся к демонизированному openocd в текущей сессии (или открыв новую консольную сессию) следующей командой:

    telnet localhost 4444

  5. Работаем с целевым контроллером под открывшейся консольной telnet-сессией (внутри сессии ssh), где по условию задачи нам нужны всего две операции: чтение прошивки из контроллера моноколеса и запись прошивки обратно.

    Сохраняем полностью текущую прошивку в указанный файл (/var/dump.bin или в какой другой):

    dump_image /var/dump.bin 0x08000000 0x00040000

    Записываем нужный дамп обратно в контроллер, предварительно очистив его (выполняем последовательно три команды):

    reset halt
    flash write_image erase /var/dump.bin 0x08000000
    reset run

  6. В нашем простом примере можно и не демонизировать процесс, а обойтись вовсе без клиент-серверного режима openocd, используя соотвествующие команды вида:

    openocd -f interface/jlink.cfg -f target/stm32f1x.cfg -c "init" -c "dump_image /var/dump.bin 0x08000000 0x00040000" -c "reset run" -c "exit"

    openocd -f interface/jlink.cfg -f target/stm32f1x.cfg -c "init" -c "reset halt" -c " flash write_image erase /var/dump.bin 0x08000000" -c "reset run" -c "exit"

Задача технически решена. Ура! Однако расположить внутри корпуса Эски все необходимое (банану, донгл jlink, преобразователь питания, а также провода и переходники) непросто … и на текущий момент пока не реализовано. Но вместе с этим в процессе изучения openocd появилась мысль о возможности отказаться от донгла jlink и тем самым не только сократить количество плат, но и количество объемных проводов (с разъемами USB). Вместо же jlink использовать программный интерфейс-конвертер, основанный на gpio (программно управляемые порты ввода-вывода).

Попытка использования программного интерфейса GPIO в качестве программатора SWD

Нужно собрать openocd из исходников, т.к. в сборку из репозитория не включена поддержка gpio. Программный интерфейс связи хост-машины и отлаживаемого контроллера через gpio (в виде их софтового «дерганья») реализуется через драйвер (библиотеку) openocd под названием sysfsgpio, для малины есть еще альтернативная библиотека bcm2835gpio.

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

apt-get install git autoconf libtool make pkg-config libusb-1.0-0 libusb-1.0-0-dev
git clone https://git.code.sf.net/p/openocd/code openocd
cd openocd
./bootstrap
./configure --enable-sysfsgpio --enable-bcm2835gpio
make
make install

export PATH=$PATH:/usr/local/bin

Ноги выбираем по карте распиновки. Возможно не любыми из ног удастся подергать (почему-то?), также нужно (в зависимости от сборки ядра) дополнительно разрешить использование gpio путем активации соответствующего оверлейного модуля.

… Вобщем облом заключается в том, что драйвер sysfsgpio на разных платформах ругается одинаково на недопустимую скорость работы интерфейса, вне зависимости, что ему укажешь. А указываешь скорость строчкой подобного вида:

adapter_khz 400

На малине нативный драйвер, по крайней мере, дергает выводами gpio, но считать хотя бы правильный идентификатор подключенного контроллера – не удается. Возможно, нужно подбирать скорость (в зависимости от которой читаются разные, но не рандомные значения идентификатора).

openocd -f interface/raspberrypi2-native.cfg -f target/stm32f1x.cfg -c "bcm2835gpio_swd_nums 18 23" -c "transport select swd"

Итог: вариант использования программного интерфейса через gpio для программирования контроллера (тем боле в полевых условиях) видится нецелесообразным. Стабильность работы данного решения в любом случае обратно пропорционально скорости работы и оставляет желать лучшего …

Нужно пробовать упаковать внутрь отлаженный вариант с jlink-ом, возможно уже на Зетке, где места вроде как больше ;-))

MiGeRA (март-апрель 2019)

Заглавная » Разное » Ninebot – Прошиваем из под Linux