Ninebot – Прошиваем из под Linux
Процесс резервирования/восстановления/обновления прошивки Ninebot One S2 в среде Windows через интерфейс SWD описан мной ранее - казалось бы тему можно считать закрытой. Однако набор инструментария и оборудования необходимого для реализации прошивки явно не пригоден для полевых условий (ноутбук с виндой, донгл JLink, инструмент для снятия крышки) … Да даже и дома крышку моноколеса часто снимать/ставить заморочишься и вскоре крючки сломаешь. Вобщем возникла идея реализации беспроводного доступа с целью перепрошивки моноколеса. Проект таков: для этого нам нужна «линуксовая машинка», которую мы спрячем внутрь моноколеса и будем иметь доступ к ее консоли через развернутую на ней точку доступа WiFi, понятно что также нужен интерфейс SWD и софт управления им.
Используем донгл JLink с одной из фруктово-ягодных платформ.
В Эске места не просто мало, а очень мало. Классического форм-фактора «малину/банану/апельсину» туда никак не запихнуть … Смотрим в сторону упрощенных версий «Zero». Квадратная «апельсина» отпадает из-за габаритных размеров, «малина» не имеет встроенного WiFi, да и проц всего одноядерный (как всегда малина в жопе) – а вот «банана» (как всегда на высоте) подходит вполне (BananaPi M2 Zero – цена порядка 20 баксов).
Для начала отлаживаем обкатанную под виндой цепочку с использованием донгла JLink – подбираем и настраиваем софт под линукс. Как нельзя кстати для данных целей подходит openocd.
- Устанавливаем OpenOCD:
apt install openocd
- Добавляем в конфигурационный файл нашего донгла /usr/share/openocd/scripts/interface/jlink.cfg директиву выбора SWD-режима (по-умолчанию режим JTAG):
transport select swd - Запускаем openocd с указанием двух конфигурационных файлов (донгла и целевого контроллера), причем запускаем в режиме демона (символ & в конце строки, т.к. если этого не сделать, то для выполнения следующего шага нужно открывать еще одну терминальную сессию - до завершения, например по ^C, сервера openocd в текущей):
openocd -f interface/jlink.cfg -f target/stm32f1x.cfg & - Подключаемся к демонизированному openocd в текущей сессии (или открыв новую консольную сессию) следующей командой:
telnet localhost 4444 - Работаем с целевым контроллером под открывшейся консольной telnet-сессией (внутри сессии ssh), где по условию задачи нам нужны всего две операции: чтение прошивки из контроллера моноколеса и запись прошивки обратно.
Сохраняем полностью текущую прошивку в указанный файл (/var/dump.bin или в какой другой):
dump_image /var/dump.bin 0x08000000 0x00040000
Записываем нужный дамп обратно в контроллер, предварительно очистив его (выполняем последовательно три команды):
reset halt
flash write_image erase /var/dump.bin 0x08000000
reset run - В нашем простом примере можно и не демонизировать процесс, а обойтись вовсе без клиент-серверного режима 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)