Решения различных вопросов, возникающих при работе с аппаратной платформой LuckFox (серия плат для разработки на основе процессоров Rockchip RV1103 и RV1106).
# Откуда загружаться (target boot medium) exportRK_BOOT_MEDIUM=sd_card
# Конфигурация раздела в окружении # Формат RK_PARTITION_CMD_IN_ENV: # < partdef>[,< partdef>] # < partdef> := < size>[@< offset>](part-name) # Примечание: если смещение первого раздела не 0x0, то это должно быть добавлено. # Иначе добавлять не нужно. exportRK_PARTITION_CMD_IN_ENV="32K(env),512K@32K(idblock),256K(uboot),32M(boot),512M(oem),256M(userdata),6G(rootfs)"
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: указывается источник субмодулей.
Из описания в предыдущем разделе можно увидеть, что образ 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, примерно так:
exportLF_TARGET_ROOTFS=buildroot
3. Установите cross-compilation toolchain:
$ cd {SDK_PATH}/tools/linux/toolchain/arm-rockchip830-linux-uclibcgnueabihf/
$ source env_install_toolchain.sh
Примечание: когда компилируется Ubuntu, используйте sudo, чтобы избежать файловых ошибок системы. Следующие инструкции не делают различий между этими двумя вариантами компиляции, но вы действуйте в соответствии с вашей ситуацией.
[Компиляция по частям]
Отдельная компиляция загрузчика U-Boot:
$ ./build.sh clean uboot
$ ./build.sh uboot
Сгенерированные файлы образа: output/image/MiniLoaderAll.bin и output/image/uboot.img
Промышленные устройства, IoT, дроны, где важны размер и скорость
Разработка, прототипирование, когда нужен привычный Linux-инструментарий
Управление пакетами
Нет менеджера пакетов. Софт добавляется на этапе сборки.
Есть apt — можно ставить/удалять что угодно.
Init система
Обычно простой init или busybox init
systemd
Требования к правам
Обычные права пользователя (./build.sh)
Требуются права root (sudo ./build.sh)
[Подробное объяснение]
1. Compile busybox/buildroot
Это стандартный способ для embedded-устройств. Buildroot — это инструмент для сборки, который:
Берет ядро Linux (kernel).
Компилирует минимальный набор системных библиотек (например, uClibc или glibc).
Использует Busybox — "швейцарский нож", который заменяет собой сотни стандартных UNIX-утилит (ls, cp, mv, vi, ifconfig и т.д.) одним бинарным файлом, экономя огромное количество места.
Собирает всё это в компактный образ rootfs (корневой файловой системы).
Результат: Вы получаете минимальную, быструю и экономичную систему, идеально подходящую для финального продукта. Но установить новые программы "на лету" не получится — для этого нужно пересобирать весь образ.
Когда использовать: для готовых устройств, где важны размер, скорость загрузки и безопасность.
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 значительно ускорит процесс, если вы находитесь в Китае или используете китайское железо/провайдера.
В контексте одноплатных компьютеров 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`:
Если видите `eth0` и `eth1`, то скорее всего это Pico Mini B. Если видите только `eth0`, то скорее всего это Pico Mini A. Если Ethernet-интерфейсов нет вообще, то это базовая Pico (без Ethernet).
Проверить наличие аудиоустройства: команда `ls /dev/snd/`.
[root@luckfox ]# ls /dev/snd/ by-pathcontrolC0 pcmC0D0c pcmC0D0p
Наличие звуковых устройств характерно для моделей Plus и Pro.
[Способ 3: по надписям на упаковке или плате]
Производитель часто наносит шелкографию с названием модели на саму плату. Ищите надписи типа "Pico", "Pico Mini", "Pico Plus" или "Pico Pro".
Коробка или антистатический пакет, в котором пришла плата, почти всегда имеют наклейку с точным указанием модели (например, "LuckFox Pico Mini B").
Таким образом, какждая из этих команд представлена не отдельной программой, а всего лишь "ссылкой" на главный исполняемый файл `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.
Облачный диск не предоставляет образ системы 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-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.
$ 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 вы увидите что-то вроде:
Это покажет список всех узлов высокого уровня (например, `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 на вашем компьютере.
Строка `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
# Удалим предыдущий результат компиляции:
rmspi # Компиляция spi.c в исполняемый файл spi:
arm-rockchip830-linux-uclibcgnueabihf-gccspi.c-ospi # Удалить файл spi на целевом устройстве LuckFox Pico Mini:
adbshell"rm /oem/spitest/spi" # Записать в то же место обновленную версию файла:
adbpush./spi/oem/spitest
В этом примере команда adb shell "rm /oem/spitest/spi" удалит исполняемый файл на плате LuckFox Pico Mini, а команда adb push ./spi /oem/spitest запишет его обновленную версию.
Можно посмотреть и отфильтровать лог компиляции, но ИМХО самый простой и надежный способ - внести в файл *.dts намеренную ошибку. Можно временно переименовать измененный вами файл, либо вставить в него что-то недопустимое, например:
