Показаны сообщения с ярлыком arm. Показать все сообщения
Показаны сообщения с ярлыком arm. Показать все сообщения

Fixing console UART on Quartz64 Model B

Recently, I've obtained Quartz64 Model B single board computer (the board revision is 1.4 2022.06.06). It is equipped with so-called RasbperryPi-compatible 40-pin extension header, which provides access to UART console. The board is powered by Rockchip RK3566 Quad-Core ARM Processor and default UART baudrate is 1500000 as it was for RK3328 for instance.

Surprisingly, I had nothing on the console when I powered the board up. Even though HDMI output works fine, and the board was booting successfully. It took some time to realize that something is wrong with the board itself. Then it appeared that other people also suffer from the similar issue: https://forum.pine64.org/showthread.php?tid=17131&pid=115539#pid115539

At some point I attached an oscilloscope to the UART TX pin:

These saw teeth are supposed to be rectangular for not-disturbed signal. So, the hardware origin of the issue became more evident. Unfortunately, Pine64 support didn't help me with this issue, they only adviced to try different OS, different power supply, etc. All of that didn't helped.

The board schematic is not very complicated for UART TX (the same is valid for RX):

The resistors can be probed relatively easily, it appeared that all of them have correct nominals. So, the final decision appeared to replace Q1 (for RX line) and Q2 (for TX line) SOT-323 MOSFETs. There are only two components of SOT-323 size on the board and they can be easily located with the help of components placement:

The MOSFETs have KN on their case and three pins and each located at its own side of the board. The pars are relatively big to be manually resoldered. I used Pine64 Pencil with ILS soldering tip. It seems that high-temperature lead-free soldering was used on the factory, so the temperature close to 400C was required to unsolder the parts. After the parts were replaced with the spares supplied by local electronic distributor, UART console has been working as initially expected.

OBS: локальная сборка под ARM

Когда требуется локально пересобрать пакет под одну из архитектур ARM, например для тестирования сборки, можно воспользоваться следующим медленным подходом.

osc build --clean --alternative-project openSUSE:Factory:ARM qemu armv7l name.spec

Здесь указывается, что используется альтернативный проект для сборки — openSUSE:Factory:ARM (версию подставить по желанию), используется репозиторий qemu, который есть в этом проекте. Поэтому и указывается этот альтернативный проект.

Несмотря на то, что в данном примере указана архитектура armv7l, технически, это x86_64. В среду сборки будет установлен бинарный транслятор qemu, работающий через подсистему ядра binfmt. При инициализации ядро настраивается таким образом, что при виде сигнатуры ELF для архитектуры ARM вызывает бинарик как qemu-arm /usr/bin/..., подобно тому, как при виде символов "#!" в начале исполняемого файла вызывается указанный интерпретатор. Работает поэтому достаточно медленно.

К сожалению, с пакетами kiwi такое не проходит.

Сетевой стек на ATSAMD20

В предыдущих выпусках рассматривалась демонстрационная плата на базе 32-битного микроконтроллера ATSAMD20. Далее рассмотрим как прикрутить к нему сетевое приложение. Так как сам микроконтроллер не снабжен интерфейсом Ethernet, возьмем какое-нибудь готовое решение на базе ENC28J60 и прикрутим его через SPI.

Нам понадобится:
  • Atmel Software Framework — распространяемая под странным образом модифицированной BSD лицензией библиотека, реализующая удобный уровень индирекции при работе с переферией микроконтроллеров Atmel. Мы ей воспользуемся для работы через SPI. Внутри библиотеки весьма красивый код, понятный API и гора документации, исполненной в doxygen. Поэтому, основываясь на чувстве прекрасного, будем её использовать.
  • ec28j60driver — драйвер для ENC28J60, реализует высокоуровневые функции работы с Ethernet путем обмена через SPI. Возьмем этот, потому-что написан он не левой пяткой и был достаточно легко портирован для работы с Atmel Software Framework. (см. ветку asf)
  • lwIP — легковесный стек TCP/IP. Он отсылает или принимает Ethernet-пакеты через драйвер устройства и дальше разбирается что-же там внутри пришло. На сайте присутствует куча примеров.

Настройки для lwIP следующие:

lwoptions.h:
#define MEM_LIBC_MALLOC 1
#define MEMP_MEM_MALLOC 1
#define MEM_ALIGNMENT 4

cc.h:
#define BYTE_ORDER  LITTLE_ENDIAN

Стиль программирования приложений, определяемый использованием RAW API библиотеки lwIP, через 5 минут создает полное ощущение, что ты пишешь gen_server на erlang, но последний почему-то кривой, неудобный и недоделанный.

Далее в таблице приводится размер кода прошивки, получаемый при различных вариантах конфигурации:
config -O3 -Os
TCP/IP + DHCP + DEBUG(printf) 96k 82k
TCP/IP + DHCP 54k 40k
TCP/IP 45k 36k
UDP/IP + SNMP 54k 43k
UDP/IP 28k 24k

Как-то так оно и работает.

openSUSE 13.1 на BeagleBone Black

BeagleBone Black — одноплатный компьютер на основе процессора TI AM3358 (Cortex-A8), выпущенный весной прошлого года:

На нем вполне успешно может загрузиться и даже работать openSUSE 13.1. Готовые образы для нанесения на microSD карточку находятся здесь. Эти же самые образы должны в теории работать и на BeagleBone. Конечно, пока все на этапе интеграции и поиска ошибок, поэтому имеется подробная инструкция по запуску:
  1. Скачать, распаковать и сделать dd на карточку образ системы *.raw.xz
  2. Подключить отладочный TTL-RS232 порт (можно использовать, например, такой, но важно помнить, что разработчики BeagleBone Black не поставили на свою плату преобразователь уровней и сигнал с отладочного RS232 идет в виде 3.3V. Подключение через обычный COM-порт на большом компьютере обречено на провал.), руководствуясь распиновкой. Используя screen /dev/ttyUSB0 115200, во-первых, можно будет легко видеть все этапы начиная от работы u-boot. Во-вторых, запустится Yast2 firstboot и попросит вас задать root пароль, завести пользователя, установить временную зону и системное время (аналогично тому, как это происходит на соответствующем этапе установки с DVD), а для этого потребуется интерактивное взаимодействие.
  3. Помните, что для загрузки с внешней карты памяти при подаче питания на устройство нужно удерживать кнопку S2 (она же boot select switch). Подсказка — загрузившись с SD карты можно подмонтировать раздел встроенной MMC памяти и переименовать или удалить файл загрузчика MLO, после этого загрузка будет всегда начинаться с SD, но загрузиться с MMC больше не получится.

Технические подробности (тем, кто хочет продолжить ковыряния) изложены в списке рассылки: http://lists.opensuse.org/opensuse-arm/2014-01/msg00001.html.

Atmel ATSAMD20-XPRO: собираем компилятор

Поскольку сборка компилятора привела к боли и страданиям, она будет тут сохранена для истории (такими историями гугл полнится).

Возьмем последний binutils-2.24:
./configure  --target=arm-none-eabi -enable-interwork   --enable-multilib --disable-nls  --disable-libssp --prefix=/opt/arm-none-eabi
make
make install-strip
export PATH=$PATH:/opt/arm-none-eabi/bin

Возьмем newlib-2.0.0 и распакуем его, пусть проветривается.

Возьмем gcc-4.8.2 который слышал о cortex-m0plus. Возьмем дебиановские патчи отсюда. Наложим их и скомпилируем:
mkdir build
../configure  --target=arm-none-eabi --prefix=/opt/arm-none-eabi --enable-languages="c,c++" --enable-interwork --enable-multilib  --with-
newlib --with-headers=/path/to/src/newlib-2.0.0/newlib/libc/include/  --disable-nls --disable-libssp  --with-system-zlib --with-multilib-lis
t=armv6-m
# в этом месте ./configure может ругаться, надо проследить чтобы он заголовки смог переписать на место
make
make all-gcc
make install-gcc

newlib собирается со следующими ключами (без --disable-newlib-supplied-syscalls не собираются некоторые куски для armv6-m, и atmel-овский asf ругается на дублирующиеся определения функций из syscalls):
./configure --target=arm-none-eabi -enable-interwork --enable-multilib --disable-libssp --disable-nls --prefix=/opt/arm-none-eabi --disable-newlib-supplied-syscalls  --enable-newlib-register-fini --enable-newlib-io-long-long
make
make install

После доделываем gcc:
cd build
make all
make install

openSUSE@ARM

Оказывается, после того как OBS научился собирать пакеты под самые хитрые архитектуры, возникла логичная идея портировать openSUSE на ARM (v5 и v7). Некоторые пакеты уже доступны: http://download.opensuse.org/repositories/Ports:/ARM:/, есть описание в виде презентации на openSUSE conference '09. В ней же, объяснено о том, что такое прозрачная кросс-компиляция.

Ожидается, что к концу лета будет доступен полностью портированный openSUSE 11.2. В свете того, что на июль запланирован выход 11.3 следует ожидать, что вскоре будет готова и эта версия. В данный момент архитектура ARM в различных вариантах используется во множестве встраиваемых устройств, промышленных компьютеров, мобильных телефонов, в то же время и в некоторых моделях нетбуков.

AVR32: Atmel NGW100

Рассказ о маленьком одомашненном роутере. В качестве роутера я использую Atmel NGW100 Network Gateway Kit, плату на процессоре AT32AP7000. Розничная цена, для справки, чуть менее $100. Один из серьезных недостатков — не имеет USB-host контроллера, однако может подсоединяться как USB-устройство, таким образом сразу до трех сетевых интерфейсов доступно для использования(два Ethernet и один USB). Две флеш-микросхемы по 8Mb, оперативная память — 32Mb, устройство для чтения SD-карт, вывод программатора JTAG и много выводов GPIO, которые могут быть использованы произвольным образом.

AVR32 — это RISC-архитектура процессоров, выпускаемых компанией Atmel, основанная на ARM. На двух флеш-модлях NGW100 расположен загрузчик U-Boot и файловые системы ОС Busybox/Linux. Все свежие исходники и готовые бинарные образы можно взять на сайте Atmel. Исходники представляют собой модифицированный BuildRoot, куда положены все необходимые для сборки и работы с архитектурой AVR32 патчи для GCC, U-Boot, Linux.

После года вполне успешной работы, я решил обновить систему на роутере, добавив туда блек-джек и шлюх новых приложений. Процессор AT32AP7000 экспортирует терминал через COM-порт, поэтому кабель RS232 облегчает работу с платой: соедините ваш компьютер и NGW100 и используйте minicom или какой-нибудь другой терминал для связи, вам будет доступна командная строка загрузчика U-Boot(необходимо быстро нажать пробел, когда об этом просят, иначе начинается загрузка), а так-же командная строка ОС, когда она загрузится. Так-же приветствуется наличие TFTP-сервера на вашем компьютере, поскольку загрузка образов через KERMIT происходит достаточно долго. Исходники и инструкции для сборки полностью доступны на сайте Atmel.

К процессу конфигурации и сборки никаких комментариев добавить невозможно, поскольку тут все достаточно очевидно и инструкции доступны. После распаковки исходников:

# make atngw100_defconfig
# make menuconfig
# make source
# make

После компиляции получится три файла: образ u-boot, образ корневой файловой системы и /usr в формате jffs2. Все образы также доступны в готовом виде на сайте Atmel.

На странице AVRFreaks Firmware_upgrade доступны исчерпывающие инструкции по обновлению микрокодов. Общая схема обновления примерно следующая: находясь в командной строке загрузчика uBoot необходимый образ загружается в оперативную память, используя тот или иной канал связи(TFTP, KERMIT, SD-карта, etc.); снимается защита с нужного участка флеш-памяти и образ копируется на флеш-память. Загрузчик uBoot, корневая файловая система и настройки uBoot располагаются на первом флеш-модуле, файловая система /usr полностью занимает второй. Чтобы обновить загрузчик, можно воспользоваться либо программкой flash-upgrade, доступной на сайте Atmel, либо непосредственно загрузить образ uBoot, как описывается на сайте AVRFreaks. Если при обновлении загрузчик окажется поврежден, то для его восстановления понадобится программатор JTAG.

Проверьте, чтобы у вас загружается правильное ядро, у меня почему-то получилось так, что загрузчик искал ядро в /uImage, а лежало оно в /boot/uImage. для этого нужно соответствующим образом изменить переменную окружения загрузчика (bootcmd=fsload /boot/uImage;bootm). На странице U-Boot command reference есть полный список команд U-Boot с описаниями.

Обновление корневой файловой системы выглядит следующим образом: загружается её образ, очищается место для корневой системы, образ копируется на флеш. Команда копирования принимает три аргумента, последний из которых — размер копируемой области в шестнадцатеричном формате:

> set ipaddr 192.168.0.50
> set serverip 192.168.0.1
> tftp 0x90000000 rootfs.avr32.jffs2-root
> protect off 0x20000 0x7EFFFF
> erase 0x20000 0x7EFFFF
> cp.b 0x90000000 0x20000 0xSIZE
> protect on all


Обновление файловой системы /usr производится из успешно(но с ошибками из-за рассогласования версий файловых систем) загруженной операционной системы, вначале образ загружается в директорию /tmp (обратите внимание, что /tmp смонтирован в ramdisk, попытка временно разместить образ в другом месте не увенчается успехом по двум причинам: не хватит места, скорость записи на флеш очень медленная), устройство /dev/mtd3 отмонтируется, очищается и туда копируется содержимое образа:

> tftp -g -r rootfs.avr32.jffs2-usr 192.168.0.1
> flash_eraseall /dev/mtd3
> dd if=/tmp/rootfs.avr32.jffs2-usr of=/dev/mtd3 bs=1056
> reboot


Обновленная операционная система полностью готова к дальнейшей настройке и использованию.



Небольшое добавление: почему-то busybox 1.13.1 обладает очень интересным поведением: ifup гасит DHCP-клиент сразу после того, как тот получит IP-адрес, это означает, что когда аренда адреса истечет, никто её не обновит. Поэтому перед сборкой busybox надо найти busybox.config в target/device и выключить там опцию CONFIG_FEATURE_IFUPDOWN_EXTERNAL_DHCP, включив CONFIG_APP_UDHCPC.
Будет использовать DHCP-клиент из набора busybox, однако в такой конфигурации он будет запущен постоянно.

Еще одно небольшое добавление: возможно придется использовать патч busybox-1.13.1-bindtodevice.patch, исправляющий проблемы с падением udhcpc во время попытки обновить аренду.