Инструкция [1], под Ubuntu 24.04.3 LTS:

1. Установка зависимостей:

$ sudo apt update
$ sudo apt-get install -y git ssh make gcc gcc-multilib g++-multilib module-assistant expect g++ gawk \
 texinfo libssl-v bison flex fakeroot cmake unzip gperf autoconf device-tree-compiler libncurses5-dev \
 pkg-config bc python-is-python3 passwd openssl openssh-server openssh-client vim file cpio rsync

2. Клонирование последнего SDK:

$ git clone https://gitee.com/LuckfoxTECH/luckfox-pico.git

[Структура каталога SDK (luckfox-pico)]

├── build.sh -> project/build.sh ---- скрипт компиляции SDK
├── media --------------------------- Multimedia encoding/decoding, ISP, etc.⁽¹⁾
├── sysdrv -------------------------- U-Boot, kernel, rootfs⁽¹⁾
├── project ------------------------- Образцовые приложения, конфигурации компиляции, директория scripts
├── output -------------------------- Для сохранения файлов образа после компиляции SDK
└── tools --------------------------- прошивка образа и утилиты прошивки

Примечание (1): можно компилировать независимо.

Директория хранилища образа:

output/
├── image
│   ├── download.bin ---------------- Программа на стороне устройства для обновления коммуникации
|   |                                 с утилитами прошивки, загружается только в память платы
│   ├── env.img --------------------- Таблица разделов (partition table) и параметры загрузки
|   |                                 (boot parameters)
│   ├── uboot.img ------------------- U-Boot image
│   ├── idblock.img ----------------- Loader image
│   ├── boot.img -------------------- Kernel image
│   ├── rootfs.img ------------------ Kernel image
│   └── userdata.img ---------------- Userdata image
└── out
    ├── app_out --------------------- Файлы, компилируемые после компиляции reference application
    ├── media_out ------------------- Файлы, компилируемые после media-related компиляции
    ├── rootfs_xxx ------------------ File system packaging directory
    ├── S20linkmount ---------------- Partition mounting script
    ├── sysdrv_out ------------------ Файлы, компилируемые после sysdrv компиляции
    └── userdata -------------------- Userdata

[Файл конфигурации SDK]

1. Файлы конфигурации Luckfox-Pico series SDK находятся в папке project/cfg/BoardConfig_IPC.

luckfox-pico$ ls project/cfg/BoardConfig_IPC -1BoardConfig-EMMC-Buildroot-RV1106_Luckfox_Pico_86Panel-IPC.mk
BoardConfig-EMMC-Buildroot-RV1106_Luckfox_Pico_86Panel_W-IPC.mk
BoardConfig-EMMC-Buildroot-RV1106_Luckfox_Pico_Pi-IPC.mk
BoardConfig-EMMC-Buildroot-RV1106_Luckfox_Pico_Pi_W-IPC.mk
BoardConfig-EMMC-Buildroot-RV1106_Luckfox_Pico_Ultra-IPC.mk
BoardConfig-EMMC-Buildroot-RV1106_Luckfox_Pico_Ultra_W-IPC.mk
BoardConfig-EMMC-Buildroot-RV1106_Luckfox_Pico_Zero-IPC.mk
BoardConfig-EMMC-Busybox-RV1106_Luckfox_Pico_Ultra-IPC_FASTBOOT.mk
BoardConfig-SD_CARD-Buildroot-RV1103_Luckfox_Pico-IPC.mk
BoardConfig-SD_CARD-Buildroot-RV1103_Luckfox_Pico_Mini-IPC.mk
BoardConfig-SD_CARD-Buildroot-RV1103_Luckfox_Pico_Plus-IPC.mk
BoardConfig-SD_CARD-Buildroot-RV1103_Luckfox_Pico_WebBee-IPC.mk
BoardConfig-SD_CARD-Buildroot-RV1106_Luckfox_Pico_Pro_Max-IPC.mk
BoardConfig-SPI_NAND-Buildroot-RV1103_Luckfox_Pico_Mini-IPC.mk
BoardConfig-SPI_NAND-Buildroot-RV1103_Luckfox_Pico_Plus-IPC.mk
BoardConfig-SPI_NAND-Buildroot-RV1103_Luckfox_Pico_WebBee-IPC.mk
BoardConfig-SPI_NAND-Buildroot-RV1106_Luckfox_Pico_Pro_Max-IPC.mk
BoardConfig-SPI_NAND-Busybox-RV1106_Luckfox_Pico_Pro_Max-IPC_FASTBOOT.mk
luckfox-buildroot-nocsi-oem-pre.sh
luckfox-buildroot-oem-pre.sh
luckfox-glibc-oem-pre.sh
luckfox-rv1106-tb-emmc-post.sh
luckfox-rv1106-tb-spi_nand-post.sh
luckfox-systemd-off-modem-post.sh
luckfox-userdata-pre.sh
overlay

2. Если взять в качестве примера конфиг BoardConfig-SD_CARD-Buildroot-RV1106_Luckfox_Pico_Pro_Max-IPC.mk, то можно рассмотреть его основные ключи.

# Размер CMA в окружении
export RK_BOOTARGS_CMA_SIZE="66M"

# Kernel dts
export RK_KERNEL_DTS=rv1106g-luckfox-pico-pro-max.dts

# Откуда загружаться (target boot medium)
export RK_BOOT_MEDIUM=sd_card

# Конфигурация раздела в окружении
# Формат RK_PARTITION_CMD_IN_ENV:
#     < partdef>[,< partdef>]
#       < partdef> := < size>[@< offset>](part-name)
# Примечание: если смещение первого раздела не 0x0, то это должно быть добавлено.
# Иначе добавлять не нужно.
export RK_PARTITION_CMD_IN_ENV="32K(env),512K@32K(idblock),256K(uboot),32M(boot),512M(oem),256M(userdata),6G(rootfs)"

# Target rootfs
export LF_TARGET_ROOTFS=buildroot

# SUBMODULES : gitee/gitee
export LF_SUBMODULES_BY=gitee

# Buildroot defconfig
export RK_BUILDROOT_DEFCONFIG=luckfox_pico_defconfig

Здесь:

RK_BOOTARGS_CMA_SIZE: выделение памяти для камеры; если камера не используется, измените это значение на 1M.

RK_KERNEL_DTS: указывает файл дерева устройств (device tree file, DTS).

RK_BOOT_MEDIUM: указывает носитель загрузки (target boot medium), который может быть emmc (карта SD), sd_card (карта SD), spi_nor (SPI NOR Flash) или spi_nand (SPI NAND Flash).

RK_PARTITION_CMD_IN_ENV: эта информация используется для конфигурирования таблицы разделов. Если вам нужно сопоставить дисковое пространство с SD-картой, то вы можете изменить раздел rootfs.

LF_TARGET_ROOTFS: указывается корневая файловая система target (Root File System).

LF_SUBMODULES_BY: указывается источник субмодулей.

RK_BUILDROOT_DEFCONFIG: указывается конфигурационный файл Buildroot.

[Компиляция образов]

Из описания в предыдущем разделе можно увидеть, что образ Ubuntu поддерживает загрузку только с SD-карточки (SD card boot), в то время как образ Buildroot поддерживает как загрузку с TF-карты (TransFlash), так и загрузку из микросхемы памяти (SPI NAND FLASH boot).

1. Если вам нужно компилировать образ для системы Ubuntu и использовать gitee, то измените соответствующий mk-файл, задающий тип платы, чтобы отредактировать LF_SUBMODULES_BY для gitee, примерно так:

LF_SUBMODULES_BY=gitee

2. Если вы хотите компилировать образ Buildroot для загрузки TF card boot, то измените соответствующий файл BoardConfig-EMMC-Ubuntu-xxx.mk, чтобы поменять LF_TARGET_ROOTFS на buildroot, примерно так:

export LF_TARGET_ROOTFS=buildroot

3. Установите cross-compilation toolchain:

$ cd {SDK_PATH}/tools/linux/toolchain/arm-rockchip830-linux-uclibcgnueabihf/
$ source env_install_toolchain.sh

4. Скомпилируйте все образы:

$ cd luckfox-pico

# Компиляция busybox/buildroot
$ ./build.sh lunch
$ ./build.sh

# Компиляция ubuntu
$ sudo ./build.sh lunch
$ sudo ./build.sh

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

[Компиляция по частям]

Отдельная компиляция загрузчика U-Boot:

$ ./build.sh clean uboot
$ ./build.sh uboot

Сгенерированные файлы образа: output/image/MiniLoaderAll.bin и output/image/uboot.img

Отдельная компиляция ядра:

$ ./build.sh clean kernel
$ ./build.sh kernel

Сгенерированный файл образа: output/image/boot.img

Отдельная компиляция корневой файловой системы:

$ ./build.sh clean rootfs
$ ./build.sh rootfs

Примечание: после компиляции используйте команду ./build.sh firmware для переупаковки.

Отдельная компиляция media:

$ ./build.sh clean media
$ ./build.sh media

Файлы сохраняются в директории: output/out/media_out. После компиляции используйте команду ./build.sh firmware для переупаковки.

Отдельная компиляция образцовых приложений:

$ ./build.sh clean app
$ ./build.sh app

Примечания: app зависит от media. После компиляции используйте команду ./build.sh firmware для переупаковки.

Упаковка прошивки (firmware packaging):

$ ./build.sh firmware

Компиляция busybox/buildroot:

$ ./build.sh lunch
$ ./build.sh

Компиляция Ubuntu:

$ sudo ./build.sh lunch
$ sudo ./build.sh

Это принципиально разные подходы к сборке операционной системы для вашего Luckfox Pico. Сравнительная таблица:

[Подробное объяснение]

1. Compile busybox/buildroot

Это стандартный способ для embedded-устройств. Buildroot — это инструмент для сборки, который:

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

2. Compile ubuntu

Это способ для тех, кому нужна полноценная и привычная среда. Здесь скрипты не собирают систему с нуля, а кастомизируют и адаптируют готовые образы Ubuntu (чаще всего Ubuntu Base или Core) под архитектуру Luckfox Pico. В результате вы получаете почти ту же Ubuntu, что и на ПК, но собранную для ARM-процессора. В ней есть менеджер пакетов apt, вы можете легко установить python3, gcc, vim или любой другой пакет из репозиториев Ubuntu.

Почему нужен sudo? Процесс адаптации образа часто involves mounting образы файловых систем и выполнение операций, требующих прав суперпользователя (например, chroot для установки пакетов или настройки).

Когда использовать: Для разработки и отладки, когда вам нужен доступ к большому количеству инструментов и библиотек без необходимости их самостоятельной кросс-компиляции.

[Итог: Какой вариант выбрать?]

Если вы разработчик и хотите быстро протестировать код, использовать привычные инструменты (apt, systemd)? Тогда выбирайте Ubuntu. Если же вы создаете устройство для продажи или развертывания, где критически важен минимальный размер образа и максимальная скорость? Выбирайте Buildroot/Busybox.

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

Gitee Source (или Gitee источник) — это серверы-зеркала (репозитории) на платформе Gitee.com, которые хранят копии исходного кода и пакетов с других открытых платформ (в первую очередь — GitHub). Их основная цель — ускорение доступа к этим ресурсам для разработчиков внутри Китая.

Если говорить проще, Gitee Source — это "зеркало" или "кэш" для исходного кода.

Детальное объяснение:

Для чего это нужно?

• Обход ограничений: прямой доступ к международным платформам, like GitHub, из Китая может быть медленным, нестабильным или вовсе ограниченным (из-за Великого файрвола).

• Высокая скорость: Gitee-зеркала расположены на территории Китая, поэтому местные разработчики и системы CI/CD (как в вашем случае со сборкой Luckfox Pico) могут скачивать код и пакеты с огромной скоростью.

• Национальная безопасность: создание локальных копий критически важного opensource-кода является элементом технологического суверенитета.

Как это работает?

• Платформа Gitee автоматически или вручную периодически синхронизируется (копирует) популярные репозитории с GitHub и других платформ.

• Когда вы в процессе сборки (как примере с ./build.sh) указываете использовать gitee source, система не идет на GitHub за исходным кодом ядра Linux, тулчейна (toolchain) или библиотек, а скачивает их с быстрого локального зеркала на Gitee.

Где вы с этим сталкиваетесь?

Именно в сценариях, подобных вашему — при сборке прошивок для embedded-устройств (Luckfox Pico, Raspberry Pi, Orange Pi и т.д.) с помощью скриптов вроде build.sh. Внутри таких скриптов часто есть выбор source (источника для загрузки). Обычно это выглядит так:

• github (оригинальный, медленный для Китая)
• gitee (зеркало, быстрое для Китая)
• Иногда gitlab или другие.

Пример из практики: допустим, скрипту сборки нужен исходный код ядра Linux (linux.git). Вместо того чтобы клонировать его с https://github.com/torvalds/linux, что будет медленно, он клонирует его с https://gitee.com/mirrors/linux.git, что происходит почти мгновенно.

Итог:

Gitee Source — это техническое решение для ускорения и стабилизации разработки внутри Китая путем создания локальных копий международных opensource-репозиториев. Когда вы в процессе сборки видите упоминание gitee, это означает, что инструменты будут качать код не с медленного GitHub, а с его быстрого китайского зеркала.

В вашем случае, при выполнении ./build.sh lunch, вам, скорее всего, предложат выбрать платформу (например, luckfox_pico) и, возможно, источник для загрузки (github или gitee). Выбор gitee значительно ускорит процесс, если вы находитесь в Китае или используете китайское железо/провайдера.

TF card — это старое название карт microSD. По современным стандартам это одно и то же. Подробности см. в Википедии.

В контексте одноплатных компьютеров LuckFox (и других подобных плат на процессорах Rockchip), термин `media` имеет очень конкретное и важное значение.

`Media` здесь — это сокращение от "Multimedia" и относится к подсистеме обработки мультимедиа внутри процессора (SoC). Это целый набор аппаратных блоков (IP-ядер) и программного обеспечения, отвечающих за работу с видео и изображениями.

Если говорить просто, `media` в LuckFox — это всё, что позволяет плате "видеть" и "показывать".

[Что входит в подсистему Media?]

Эта подсистема включает в себя два основных направления:

1. Видеозахват (Video Input - VI). Это аппаратные блоки и драйверы, отвечающие за приём видео от камер.

ISP (Image Signal Processor): "Мозги" обработки изображения. Он преобразует сырые данные (raw data) с матрицы камеры в привычное нам изображение, выполняя:

       • Дебейеризацию (Demosaic) — преобразование сырых данных с Bayer-фильтра в цветное изображение.
       • Коррекцию белого (AWB)
       • Автоэкспозицию (AE)
       • Подавление шумов (3DNR)
       • Резкость (Sharpness)
       • Коррекцию линз (LSC)

MIPI CSI (Camera Serial Interface): hardware-интерфейс, к которому физически подключаются современные камерные модули (например, ваши камеры LuckFox).

VIPP (Video Input Post Processor): блок для дальнейшей обработки уже сформированного изображения (масштабирование, обрезка).

2. Видеовывод и Кодирование/Декодирование (Video Output & Codec). Это аппаратные блоки, отвечающие за сжатие, распаковку и вывод видео.

VPU (Video Processing Unit): hardware-энкодер и декодер. Именно он позволяет кодировать (сжимать) видео с камеры в форматы **H.264** или **H.265 (HEVC)** с очень малым потреблением энергии процессора. Это критически важно для видеорегистраторов, камер наблюдения.

VOP (Video Output Processor): блок, управляющий выводом изображения на дисплей (например, по HDMI или через LVDS-интерфейс).

[Где вы встречаетесь с термином "media" в LuckFox?]

1. В Device Tree (`*.dts`): конфигурация всей подсистемы `media` (какие камеры подключены, их разрешение, режимы работы ISP) прописывается в файле дерева устройств.

2. В ядре Linux (`kernel/`): драйверы, находящиеся в разделах типа `drivers/media/platform/rockchip/isp/`, `.../mipi-csi/`, `.../rkcif/`.

3. В пользовательском пространстве:

    • Утилита `rkisp_demo`: позволяет тестировать и настраивать работу ISP (задавать параметры цветокоррекции, резкости и т.д.).
    • Утилита `v4l2-ctl`: стандартная Linux-утилита для работы с видеоустройствами (Video4Linux2). Через неё можно посмотреть список доступных камер (`v4l2-ctl --list-devices`), получить формат изображения с камеры и т.д.
    • Утилита `rkmpp`: набор утилит для работы с hardware-кодеком (VPU) — кодирование, декодирование видео.

Пример рабочего потока (pipeline) `media`:

Камера (Sensor)

    -> MIPI CSI-2 Interface 
    -> CIF (Capture Input Frame) 
    -> ISP (Image Signal Processor) 
    -> RGA (для rotation/scaling) 
    -> VPU (для кодирования в H.264) 
    -> Файл или сеть (RTSP-поток).

Итог:

В контексте LuckFox термин `media` — это не абстрактное "медиа", а конкретное название мощной аппаратно-программной подсистемы, которая отвечает за:

* Захват видео с камеры
* Обработку изображения (улучшение качества)
* Кодирование и декодирование видео
* Вывод видео на дисплей

Именно эта подсистема является ключевым преимуществом процессоров Rockchip и делает платы LuckFox такими популярными для проектов компьютерного зрения, видеонаблюдения и потокового вещания.

Buildroot — это не дистрибутив Linux (как Ubuntu или Debian), а система автоматизации сборки. Её главная задача — собрать всё необходимое для работы встроенной системы (embedded Linux) из исходного кода с помощью инструмента make.

Представьте себе конструктор или конвейер, который по вашему заказу:

• Скачивает исходные коды нужной версии ядра Linux, библиотек и программ.
• Настраивает и компилирует их друг за другом, учитывая все зависимости.
• На выходе выдает готовые образы: ядро (kernel.img), Device Tree (dtb) и, самое главное, корневую файловую систему (rootfs) — то есть набор всех библиотек, системных утилит и ваших программ, упакованный в один файл.

Главная философия Buildroot — создавать минималистичные и эффективные системы без лишнего софта, что идеально для устройств с ограниченными ресурсами, наподобие плат разработчика Luckfox Pico Mini.

Buildroot предоставляется производителем (Luckfox) в составе Software Development Kit (SDK), и внутри этого SDK Buildroot является основным движком для сборки всей операционной системы.

Когда вы скачиваете официальный SDK для Luckfox Pico, его структура обычно включает:

buildroot/ — Сама система Buildroot с конфигурациями и настройками от Luckfox.
linux/ — Исходный код ядра Linux, патченного для поддержки чипа RV1103.
uboot/ — Исходный код загрузчика U-Boot.
output/ — Директория, куда помещаются готовые образы после сборки.

Процесс разработки выглядит так:

1. Вы входите в директорию SDK.

2. Запускаете команду ./build.sh (это скрипт-обертка от Luckfox). Он скрипт запускает Buildroot, который, в свою очередь:

- Компилирует кросс-компилятор (gcc) для архитектуры ARM.
- Конфигурирует и компилирует ядро Linux.
- Компилирует загрузчик U-Boot.
- Собирает корневую файловую систему: берет базовый набор утилит (BusyBox), добавляет именно те библиотеки и программы, которые указаны в конфигурации (например, поддержку Wi-Fi, инструменты для работы с GPIO, примеры кода для работы с камерой и NPU).

3. В результате в папке output/ вы получаете файлы rootfs.img, kernel.img и другие, которые можно прошить на вашу плату с помощью инструмента RKDevTool.

Buildroot для Luckfox Pico Mini используется по следующим оображениям:

• Легковесность: итоговая система получается очень маленькой. Образ rootfs.img может весить всего несколько десятков мегабайт, что идеально для встроенных устройств.
• Простота и скорость: процесс сборки полностью автоматизирован одной командой. Не нужно вручную собирать каждую библиотеку.
• Полный контроль: вы можете тонко настроить систему через конфигурационное меню (make menuconfig), чтобы включить или выключить тысячи опций, добавить конкретные библиотеки или свои приложения. Это избавляет систему от любого "мусора".
• Повторяемость: процесс сборки детерминирован. Вы можете быть уверены, что соберете абсолютно идентичную систему на другой машине, что критически важно для разработки и промышленного применения.

[Альтернативы Buildroot]

Часто Buildroot сравнивают с Yocto Project. Оба решают одну задачу, но по-разному:

Buildroot: Проще в освоении, быстрее собирает систему, идеален для относительно простых устройств и быстрого прототипирования (как в случае с Luckfox Pico).

Yocto: Более мощный, гибкий и сложный инструмент, предназначенный для создания промышленных дистрибутивов с поддержкой множества пакетов и архитектур. Его кривая обучения значительно круче.

Итог:

Buildroot в контексте Luckfox Pico Mini — это "сердце" процесса сборки прошивки. Это инструмент, который превращает исходные коды ядра Linux, загрузчика U-Boot и сотен отдельных программ в единый, готовый к прошивке, минималистичный и оптимизированный образ операционной системы, который превращает голое "железо" Luckfox Pico в работающий мини-компьютер с Linux, способный выполнять ваши задачи.

Без Buildroot вам пришлось бы вручную компилировать и компоновать все части ОС, что является невероятно сложной и трудоемкой задачей. Buildroot автоматизирует этот процесс до одной команды.

Определить модель платы LuckFox Pico можно несколькими способами, от самого простого (визуальный осмотр) до более сложных (программных).

[Способ 1: визуальный осмотр (cамый быстрый и простой)]

Это первый и часто самый эффективный шаг. Посмотрите на вашу плату и найдите ключевые отличия. Ниже перечислены ключевые признаки для идентификации.

1. Размер и форма платы:

LuckFox Pico: самая маленькая плата (примерно 20x20 мм), квадратной формы. Выглядит как "голый" модуль без портов.
LuckFox Pico Plus: чуть больше (примерно 30x30 мм), тоже квадратной формы. Часто на модуле есть металлическая крышка-радиатор.
LuckFox Pico Mini: имеет вытянутую прямоугольную форму (примерно 56x26 мм). Все компоненты распаяны прямо на плате, модульной конструкции нет. На нижней стороне платы (противоположной кнопке BOOT) шелкографией нанесена надпись "Luckfox Pico Mini".
LuckFox Pico Pro: cамая большая плата (примерно 56x56 мм), имеет прямоугольную форму с множеством разъемов.

2. Наличие и тип интерфейсов:

Ethernet (Сетевой порт RJ45): есть только у LuckFox Pico Mini A и LuckFox Pico Mini B. У модели "A" один порт, у модели "B" два порта.
USB Type-C (для питания и данных): есть у всех моделей Mini, Plus и Pro. У базового Pico его нет (присутствуют только контакты для пайки).
Разъем для камеры (MIPI CSI): есть у Mini B, Plus и Pro. У Mini A и базового Pico его нет.
Разъем для дисплея (MIPI DSI): есть только у LuckFox Pico Pro.

3. Количество и расположение контактов GPIO:

LuckFox Pico: 24 контакта (2 ряда по 12 с каждой стороны).
LuckFox Pico Mini: 22 контакта (2 ряда по 11 вдоль длинной стороны).
LuckFox Pico Plus: 38 контактов.
LuckFox Pico Pro: 48 контактов.

LuckFox Pico:

LuckFox Pico Mini A/B:

LuckFox Pico Plus:

LuckFox Pico Pro/Max:

LuckFox Pico Ultra/Ultra W:

[Способ 2: определение через Linux (если плата уже прошита)]

Если плата запускается, и у вас есть доступ к её командной строке (через UART, SSH или ADB []), то вы можете использовать несколько команд.

1. Посмотреть модель в `proc/device-tree/` (самый точный способ). Проприетарные параметры платы хранятся в Device Tree. Выполните команду:

# cat /proc/device-tree/model

Результат будет прямо указывать на модель, например:

`luckfox,pico` → LuckFox Pico
`luckfox,pico-mini` → LuckFox Pico Mini
`luckfox,pico-plus` → LuckFox Pico Plus
`luckfox,pico-pro` → LuckFox Pico Pro

2. Посмотреть информацию о процессоре. Следующая команда покажет не модель платы, а модель чипа, это тоже может быть полезно.

[root@luckfox ]# cat /proc/cpuinfo
processor	: 0
model name	: ARMv7 Processor rev 5 (v7l)
BogoMIPS	: 26.08
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xc07
CPU revision	: 5

Hardware	: Rockchip (Device Tree)
Revision	: 0000
Serial		: 359238bf91d2b5a8

3. Проверить наличие определенных устройств (косвенный метод). Проверить сетевые интерфейсы позволяет команда `ifconfig -a` или `ip addr`:

[root@luckfox ]# ifconfig -a
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:11948 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11948 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:884044 (863.3 KiB)  TX bytes:884044 (863.3 KiB)
usb0      Link encap:Ethernet  HWaddr 06:2C:70:05:43:2B  
          inet addr:172.32.0.93  Bcast:172.32.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2043 errors:0 dropped:1563 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:334536 (326.6 KiB)  TX bytes:0 (0.0 B)

[root@luckfox ]# ip addr
1: lo: < LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: usb0: < BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 06:2c:70:05:43:2b brd ff:ff:ff:ff:ff:ff
    inet 172.32.0.93/16 brd 172.32.255.255 scope global usb0
       valid_lft forever preferred_lft forever

Если видите `eth0` и `eth1`, то скорее всего это Pico Mini B. Если видите только `eth0`, то скорее всего это Pico Mini A. Если Ethernet-интерфейсов нет вообще, то это базовая Pico (без Ethernet).

Проверить наличие аудиоустройства: команда `ls /dev/snd/`.

[root@luckfox ]# ls /dev/snd/
by-path    controlC0  pcmC0D0c   pcmC0D0p

Наличие звуковых устройств характерно для моделей Plus и Pro.

[Способ 3: по надписям на упаковке или плате]

Производитель часто наносит шелкографию с названием модели на саму плату. Ищите надписи типа "Pico", "Pico Mini", "Pico Plus" или "Pico Pro".

Коробка или антистатический пакет, в котором пришла плата, почти всегда имеют наклейку с точным указанием модели (например, "LuckFox Pico Mini B").

BusyBox — это единственный исполняемый файл, который заменяет собой сотни маленьких стандартных UNIX-утилит (команд), таких как:

`ls`, `cp`, `mv`, `mkdir`, `rm` (команды работы с файлами)
`sh`, `bash` (командная оболочка)
`grep`, `awk`, `sed` (поиск, обработка текста)
`ping`, `ifconfig`, `netstat` (для работы с сетью)
`vi` (простой текстовый редактор)

И также многие другие команды. Это видно по множеству символических ссылок с команд на единственный исполняемый файл busybox:

[root@luckfox ]# ls -la /bin
total 5936
drwxrwxr-x    2 1000     1000          5768 Sep 16  2025 .
drwxr-xr-x   20 1000     1000          1584 Sep 16  2025 ..
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 arch -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 ash -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 base32 -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 base64 -> busybox
-rwxr-xr-x    1 1000     1000        990960 Sep 16  2025 bash
-rwxr-xr-x    1 1000     1000        857296 Sep 16  2025 busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 cat -> busybox
-rwxr-xr-x    1 1000     1000          9304 Sep 16  2025 chattr
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 chgrp -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 chmod -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 chown -> busybox
-rwxr-xr-x    1 1000     1000          1342 Sep 16  2025 compile_et
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 cp -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 cpio -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 date -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 dd -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 df -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 dmesg -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 dnsdomainname -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 dumpkmap -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 echo -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 egrep -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 false -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 fdflush -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 fgrep -> busybox
-rwxr-xr-x    1 1000     1000          3477 Sep 16  2025 gcore
-rwxr-xr-x    1 1000     1000       3486000 Sep 16  2025 gdb
-rwxr-xr-x    1 1000     1000          4045 Sep 16  2025 gdb-add-index
-rwxr-xr-x    1 1000     1000        253404 Sep 16  2025 gdbserver
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 getopt -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 grep -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 gunzip -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 gzip -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 hostname -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 kill -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 link -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 linux32 -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 linux64 -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 ln -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 login -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 ls -> busybox
-rwxr-xr-x    1 1000     1000          9304 Sep 16  2025 lsattr
-rwxrwxr-x    1 1000     1000         17900 Sep 16  2025 memtester
-rwxr-xr-x    1 1000     1000          1102 Sep 16  2025 mk_cmds
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 mkdir -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 mknod -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 mktemp -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 more -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 mount -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 mountpoint -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 mt -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 mv -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 netstat -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 nice -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 nuke -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 pidof -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 ping -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 pipe_progress -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 printenv -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 ps -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 pwd -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 resume -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 rm -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 rmdir -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 run-parts -> busybox
-rwxrwxr-x    1 1000     1000            88 Sep 16  2025 sdkinfo
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 sed -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 setarch -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 setpriv -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 setserial -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 sh -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 sleep -> busybox
-rwxr-xr-x    1 1000     1000        236644 Sep 16  2025 stressapptest
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 stty -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 su -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 sync -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 tar -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 touch -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 true -> busybox
-rwxr-xr-x    1 1000     1000        178592 Sep 16  2025 udevadm
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 umount -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 uname -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 usleep -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 vi -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 watch -> busybox
lrwxrwxrwx    1 1000     1000             7 Sep 16  2025 zcat -> busybox

Таким образом, какждая из этих команд представлена не отдельной программой, а всего лишь "ссылкой" на главный исполняемый файл `busybox`. Например, когда вывы вызываете команду `ls`, на самом деле система запускает `busybox ls`, и BusyBox "понимает", что нужно выполнить функцию `ls`.

Почему BusyBox КРИТИЧЕСКИ важен для LuckFox Pico Mini? Именно здесь преимущества BusyBox раскрываются в полной мере:

1. Экономия места файловой системы (что крайне важно!):

- LuckFox Pico Mini имеет ограниченный объем флеш-памяти (обычно 4GB или 16GB eMMC), часть которой занята ядром Linux и вашими приложениями.
- Если бы все утилиты (`ls`, `cp`, `ping` и т.д.) были полноценными отдельными бинарными файлами (как в Ubuntu), они заняли бы десятки мегабайт.
- BusyBox упаковывает все эти функции в один исполняемый файл размером всего 1-2 мегабайта. Это огромная экономия драгоценного пространства.

2. Экономия оперативной памяти: запущенные программы занимают оперативную память (RAM). Так как BusyBox — это одна программа, а не множество, она использует меньше RAM при выполнении различных задач.

3. Упрощение сборки и управления: разработчикам встраиваемых устройств проще управлять одним пакетом (BusyBox), который предоставляет весь базовый функционал, вместо того чтобы отслеживать сотни отдельных мелких утилит. При сборке прошивки с помощью Buildroot (см. Q002) просто выбирается конфигурация BusyBox с нужным набором функций.

4. Скорость и эффективность: BusyBox оптимизирован для работы на системах с ограниченными ресурсами, таких как LuckFox Pico Mini. Его код написан с упором на минимализм и скорость.

Итак, когда вы подключаетесь к своей плате через UART, SSH или ADB и попадаете в командную строку встраиваемой системы, практически с каждым вашим действием происходит взаимодейстие с BusyBox.

Проверка, что вы используете BusyBox: введите любую команду с ключом --help, и вы увидите сигнатуру BusyBox. Например:

.[root@luckfox ]# ls --help
BusyBox v1.36.1 (2025-09-16 13:42:36 MSK) multi-call binary.
Usage: ls [-1AaCxdLHRFplinshrSXvctu] [-w WIDTH] [FILE]...
List directory contents
	-1	One column output
	-a	Include names starting with .
	-A	Like -a, but exclude . and ..
	-x	List by lines
	-d	List directory names, not contents
	-L	Follow symlinks
	-H	Follow symlinks on command line
...

Первая строка четко указывает, что это BusyBox.

Можно посмотреть, какие функции встроены в BusyBox. Для этого выполните команду `busybox` без аргументов, и она выведет большой список всех поддерживаемых applets (маленьких приложений-функций).

Таким образом, BusyBox в контексте LuckFox — это фундаментальный строительный блок встраиваемой операционной системы. Это минималистичная, невероятно эффективная и универсальная замена всем стандартным UNIX-инструментам, которая позволяет уместить мощную и функциональную командную среду Linux в несколько мегабайт, что идеально соответствует ограниченным ресурсам платы. Без BusyBox встроенные Linux-системы like LuckFox Pico Mini были бы гораздо больше, дороже и менее эффективны.

На самой плате поддерживаются busybox, buildroot и Ubuntu 22.04. На машине разработчика для кросс-компиляции может использоваться Ubuntu 24.04 или Docker.

Запустите SocToolKit с правами администратора, и затем установите TF-карту. Если она все еще не распознается, закройте ПО антивируса. Попробуйте также загрузить новую версию SocToolKit.

Емкость TF-карты слишком маленькая; рекомендуется использовать 8GB или больше.

При использовании SocToolKit для прошивки firmware платы Luckfox Pico, утилита показывает, что файл luckfox pico\image\media.img не существует.

Причина в том, что Luckfox Pico поддерживает только лишь загрузку с TF-карты (TF card boot), и она должна быть записана с помощью картридера.

Облачный диск не предоставляет образ системы buildroot, подходящий для загрузки с карты SD. Вам нужно самостоятельно скомпилировать его в соответствии с секцией SDK. Поскольку емкость SD-карт может быть разной, вам необходимо вручную подстроить емкость раздела.

При установке TF-карты в плату Luckfox Pico и подключении к компьютеру SocToolKit показывает режим Maskrom, и программа не может быть прошита.

Причина в том, что Luckfox Pico поддерживает только лишь загрузку с TF-карты (TF card boot). Используйте картридер для записи карты в соответствии с пошаговым руководством [], после чего установите карту в слот платы для запуска системы.

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

Для решения проблемы сконфигурируйте виртуальный сетевой интерфейс RNDIS (см. []).

Проверьте совместимость уровней логики последовательного интерфейса, и не перепутаны ли прием с передачей (сигналы RX и TX). Luckfox-Pico работает с сигналами уровня логики 3.3V, и требует соответствующей установки уровней на модуле переходника USB - TTL UART.

На официальном сайте заявлено, что у Luckfox-Pico и Luckfox-Pico-Mini/Plus установлено 64MB памяти, но фактический объем памяти около 34 MB.

Вероятно проблема в том, что память выделена системой и работающим программным обеспечением. Пример вывода:

[ 0.000000] Memory: 34328K/65536K available (3452K kernel code, 283K rwdata, 1644K rodata,
 144K init, 127K bss, 6632K reserved, 24576K cma-reserved)

Для Luckfox-Pico-Pro/Max фактический размер памяти меньше 128MB и 256MB. Если камера не используется, то вы можете освободить память модификацией переменной RK_BOOTARGS_CMA_SIZE, изменив значение 66M на 1M.

Если взять в качестве примера Luckfox-Pico-Pro, то модификация выглядит следующим образом:

После подключения Luckfox-Pico-Plus/Pro/Max через последовательный порт устройство все время посылает сообщение "udhcpc: sending discover".

Если сетевой кабель не подключен, то в лог будет выводиться сообщение "udhcpc: sending discover". Подключите сетевой кабель, или используйте команду kill для остановки процесса udhcpc.

# ps | grep udhcpc
  248 root      1196 S    udhcpc -i eth0
  311 root      1192 S    grep udhcpc
# kill 248
udhcpc: received SIGTERM

Причина в том, что factory image предназначен главным образом для тестирования функционала GPIO. Вам необходимо самостоятельно прошить образ из онлайн-репозитория.

Вы должны использовать инструментарий кросс-компиляции из SDK. После кросс-компиляции на хосте Ubuntu или виртуальной машине выгрузите результат компиляции на плату.

При загрузке виртуальной машины VirtualBox появляется ошибка "VT-x is disabled in the BIOS for both all CPU modes (VERR_VMX_MSR_ALL_VMX_DI)".

Причина ошибки в том, что не разрешена технология виртуализации CPU на материнской плате хоста. Выполните следующие шаги, основываясь на модели вашей материнской платы для доступа к BIOS компьютера:

1. Например, материнские платы ASUS для входа в BIOS используют клавишу F2 во время запуска.
2. Выберите Advanced settings.
3. Найдите раздел CPU Configuration и установите резрешенной опцию Intel Virtualization Technology.
4. В завершение нажмите F10 для сохранения изменений и перезапуска компьютера.

Программа VLC по умолчанию использует видеобуфер размером в 1 секунду (1000ms = 1s). Можно умеренно сократить время буферизации для улучшения real-time производительности, но слишком низкая задержка может привести к потере пакетов и заиканию. Не рекомендуется устанавливать размер буфера меньше 300ms.

VBUS подключен ко входному напряжению интерфейса Type-C; VSYS это входное напряжение основной системы, с напряжением в диапазоне от 4.5V до 5.5V.

Плата распознается, но во время программирования происходит ошибка: "Error: Write LBA failed, can't read flash id from device".

Решение: удалите USB HUB и подключите кабель платы напрямую к компьютеру.

$ sudo cp -r luckfox-pico/ ~/Luckfox-test/
$ cd ~/Luckfox-test/luckfox-pico/
$ ./build.sh lunch
ls: cannot access 'BoardConfig*.mk': No such file or directory

You're building on Linux
Lunch menu... pick a combo:
... показываются варианты для выбора платы ...
Which would you like? [0]: 2
ln: failed to create symbolic link '/home/luckfox/Luckfox-test/luckfox-pico/.BoardConfig.mk':
 Permission denied
[build.sh:error] Running build_select_board failed!
[build.sh:error] exit code 1 from line 191:
[build.sh:info]     ln -rfs $TARGET_PRODUCT_DIR/$RK_BUILD_TARGET_BOARD $BOARD_CONFIG

Возможная причина ошибки в том, что используется команда sudo в процессе копирования, поэтому могут быть измерены права доступа к файлам в SDK. Удалите и заново выполните копирование с правами обычного пользователя.

При компиляции происходит ошибка загрузки модуля драйвера Linux, SDK не компилируется после clean.

Случай 1:

Решение: используйте ./build.sh для полной перекомпиляции.

Случай 2:

Решение: выполните команду:

$ make ARCH=arm CROSS_COMPILE=/home/luckfox/Luckfox-Pico/luckfox-pico/tools/linux/toolchain/\
arm-rockchip830-linux-uclibcgnueabihf/bin/arm-rockchip830-linux-uclibcgnueabihf-

На платах LuckFox, включая Pico Mini, нет единой универсальной команды, которая бы просто вывела "список разрешенных периферийных устройств". Вместо этого используется комбинация команд для анализа Device Tree (дерева устройств) и состояния ядра Linux.

Вот как это правильно сделать:

1. Основной способ: анализ Device Tree

Device Tree (DT) — это структура данных, которая описывает аппаратное обеспечение платы ядру Linux. Именно в ней "разрешаются" или "запрещаются" периферийные устройства.

Самая важная команда:

# cat /sys/firmware/devicetree/base/compatible

Эта команда покажет модель вашей платы, которую ядро использует для загрузки правильной конфигурации. Для LuckFox Pico Mini вы увидите что-то вроде:

$ adb shell
[root@luckfox ]# cat /sys/firmware/devicetree/base/compatible
rockchip,rv1103g-38x38-ipc-v10rockchip,rv1103

Чтобы посмотреть, какие устройства "включены" в текущей Device Tree, используйте:

a) Просмотр всех узлов (devices) в дереве:

[root@luckfox ]# ls /proc/device-tree/
#address-cells                 pwm@ff350010
#size-cells                    pwm@ff350020
acodec-sound                   pwm@ff350030
acodec@ff480000                pwm@ff360000
adc-keys                       pwm@ff360010
aliases                        pwm@ff360020
arm-debug@ff200000             pwm@ff360030
arm-pmu                        pwm@ff490000
chosen                         pwm@ff490010
clock-controller@ff3a0000      pwm@ff490020
clocks                         pwm@ff490030
compatible                     restart-poweroff
cpu0-opp-table                 rga@ff980000
cpuinfo                        rkcif-dvp
cpus                           rkcif-mipi-lvds
csi2-dphy-hw@ff3e8000          rkcif-mipi-lvds-sditf
csi2-dphy0                     rkcif-mipi-lvds1
csi2-dphy1                     rkcif@ffa10000
csi2-dphy2                     rkdvbm@ffa70000
dht11_sensor                   rkisp-vir0
dma-controller@ff420000        rkisp@ffa00000
ethernet@ffa80000              rkvenc-pp@ffa60000
fiq-debugger                   rkvenc@ffa50000
i2c@ff310000                   rng@ff448000
i2c@ff320000                   rockchip-amp
i2c@ff450000                   rockchip-suspend
i2c@ff460000                   rockchip-system-monitor
i2c@ff470000                   rve@ffad0000
i2s@ffae0000                   saradc@ff3c0000
interrupt-controller@ff1f0000  serial-number
interrupt-parent               serial@ff4a0000
leds                           serial@ff4b0000
memory                         serial@ff4c0000
mipi-csi2-hw@ffa20000          serial@ff4d0000
mipi-csi2-hw@ffa30000          serial@ff4e0000
mipi0-csi2                     serial@ff4f0000
mmc@ff9a0000                   spi@ff500000
mmc@ffa90000                   spi@ff510000
mmc@ffaa0000                   spi@ffac0000
model                          sram@ff6c0000
mpp-srv                        syscon@ff000000
mpp-vcodec                     syscon@ff388000
name                           syscon@ff538000
npu@ff660000                   thermal-zones
otp@ff3d0000                   timer
pinctrl                        tsadc@ff3c8000
power-management@ff300000      usb2-phy@ff3e0000
psci                           usbdrd
pvtm@ff240000                  vcc-1v8
pvtm@ff390000                  vcc-3v3
pwm@ff350000                   vdd-arm

Это покажет список всех узлов высокого уровня (например, `gpio@fdd60000`, `serial@ff9c0000`). Это не названия периферии в привычном виде, а технические имена.

b) Поиск по ключевым словам (самый практичный метод). Используйте `grep` для поиска упоминаний конкретных интерфейсов в смонтированном дереве устройств.

Для UART (последовательный порт):

# find /proc/device-tree/ -name "*uart*" | head -5

Для I2C:

# find /proc/device-tree/ -name "*i2c*" | head -5

Для SPI:

# find /proc/device-tree/ -name "*spi*" | head -5

Для PWM:

# find /proc/device-tree/ -name "*pwm*" | head -5

Если команда возвращает пути к файлам (например, `/proc/device-tree/pwm@fdd70000`), значит, этот контроллер активирован в Device Tree.

2. Проверка, загрузились ли драйверы устройств. Даже если устройство разрешено в DT, стоит проверить, увидело ли его ядро и загрузило ли драйвер.

a) Просмотр списка зарегистрированных устройств:

# ls /sys/devices/platform/

Здесь вы увидите список платформенных устройств, которые были обнаружены ядром.

b) Проверка конкретных интерфейсов.

I2C: посмотреть, какие I2C адаптеры (шины) доступны в системе.

# i2cdetect -l

SPI: проверить, есть ли устройства SPI.

# ls /dev/spidev*

PWM: посмотреть, экспортированы ли каналы PWM.

# ls /sys/class/pwm/

GPIO: управление GPIO происходит через sysfs.

# ls /sys/class/gpio/

UART: последовательные порты.

# ls /dev/ttyS*

3. Прямой просмотр исходного файла Device Tree (если есть доступ). Самый полный, но и самый сложный способ — посмотреть исходный файл *.dts. Его обычно нет на самой плате, но он есть в SDK на вашем компьютере.

Путь в SDK, на примере платы LuckFox Pico Mini:

$ find . -name rv1103g-luckfox-pico-mini.dts
./sysdrv/source/kernel/arch/arm/boot/dts/rv1103g-luckfox-pico-mini.dts

В этом файле вы можете найти все блоки вида:

&pwm0 {
    status = "okay";
};

Строка `status = "okay";` означает, что устройство разрешено. Если стоит `status = "disabled";` — устройство отключено.

Краткий итог для быстрой проверки на плате LuckFox Pico Mini:

1. UART: `ls /dev/ttyS*` (должен быть `ttyS0` и другие).
2. I2C: `i2cdetect -l` (должна быть как минимум одна шина, например `i2c0`).
3. SPI: `ls /dev/spidev*` (часто по умолчанию отключен для экономии энергии).
4. PWM: `ls /sys/class/pwm/` (должны быть видны `pwmchip0`, `pwmchip4` и т.д.).

Вывод: не существует команды наподобие `list-peripherals`. Чтобы узнать список разрешенных устройств, нужно анализировать дерево устройств через `/proc/device-tree/` и проверять состояние драйверов в `/sys/` и `/dev/`.

Предположим, что на плате LuckFox Pico Mini есть директория /oem/spitest, и в ней вы тестируете программу в исполняемом файл spi, который для обновления нужно каждый раз перезаписывать. Тогда скрипт компиляции может выглядеть примерно так:

#!/bin/bash

# Удалим предыдущий результат компиляции:
rm spi
# Компиляция spi.c в исполняемый файл spi:
arm-rockchip830-linux-uclibcgnueabihf-gcc spi.c -o spi
# Удалить файл spi на целевом устройстве LuckFox Pico Mini:
adb shell "rm /oem/spitest/spi"
# Записать в то же место обновленную версию файла:
adb push ./spi /oem/spitest

В этом примере команда adb shell "rm /oem/spitest/spi" удалит исполняемый файл на плате LuckFox Pico Mini, а команда adb push ./spi /oem/spitest запишет его обновленную версию.

Можно посмотреть и отфильтровать лог компиляции, но ИМХО самый простой и надежный способ - внести в файл *.dts намеренную ошибку. Можно временно переименовать измененный вами файл, либо вставить в него что-то недопустимое, например:

...
/**********USB**********/
&usbdrd_dwc3 {
   status = "okay";
   dr_mode = "peripheral";
};

// Мне надо проверить, компилируется ли это место в файле DTS:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

/**********SPI**********/
/* SPI0_M0 */
&spi0 {
   status = "okay";
   spidev@0 {
      spi-max-frequency = < 50000000>;
   };
};
...

Выполните команду ./build.sh, и если этот исправленный файл компилируется, то скрипт выдаст ошибку:

...
Error: /home/user/luckfox-pico/sysdrv/source/kernel/arch/arm/boot/dts/rv1103g-luckfox-pico-mini.dts:
 61.1-45 syntax error
FATAL ERROR: Unable to parse input tree
make[4]: *** [scripts/Makefile.lib:381: arch/arm/boot/dts/rv1103g-luckfox-pico-mini.dtb] Error 1
make[3]: *** [/home/user/luckfox-pico/sysdrv/source/kernel/Makefile:1464: rv1103g-luckfox-pico-mini.dtb]
 Error 2
make[3]: *** Waiting for unfinished jobs....
  CALL    /home/user/luckfox-pico/sysdrv/source/kernel/scripts/atomic/check-atomics.sh
  CALL    /home/user/luckfox-pico/sysdrv/source/kernel/scripts/checksyscalls.sh
make[2]: *** [arch/arm/Makefile:375: rv1103g-luckfox-pico-mini.img] Error 2
make[2]: Leaving directory '/home/user/luckfox-pico/sysdrv/source/objs_kernel'
make[1]: *** [Makefile:185: __sub-make] Error 2
make[1]: Leaving directory '/home/user/luckfox-pico/sysdrv/source/kernel'
make: *** [Makefile:486: kernel] Error 1
make: Leaving directory '/home/user/luckfox-pico/sysdrv'
[build.sh:error] Running build_kernel failed!
[build.sh:error] exit code 2 from line 847:
[build.sh:info]     make kernel -C ${SDK_SYSDRV_DIR} $kernel_build_options KERNEL_DTS=${RK_KERNEL_DTS}
 KERNEL_CFG=${RK_KERNEL_DEFCONFIG} KERNEL_CFG_FRAGMENT=${RK_KERNEL_DEFCONFIG_FRAGMENT}