Автор Тема: Анонс регулярных сборок для armh и aarch64  (Прочитано 7095 раз)

Оффлайн Антон Мидюков

  • alt linux team
  • ***
  • Сообщений: 3 988
  • antohami@
Добрый день.

Началось формирование еженедельных регулярных сборок для одноплатных компьютеров с архитектурой aarch64 и armh на основе репозитория Sisyphus.

На данный момент их 4:
regular-lxde
regular-lxqt
regular-mate
regular-xfce

Представляют собой архивы файловой системы для самостоятельной распаковки на предварительно подготовленную SD-карту по инструкции.
Статья на вики: https://www.altlinux.org/Regular/arm

Тестировал на Raspberry Pi 3 B+ и Orange Pi Prime. У Orange Pi Prime на данный момент аппаратное ускорение видео не поддерживается. На Raspberry Pi для включения аппаратного ускорения нужно удалить /etc/X11/xorg.conf.d/99-modesetting-noglamor.conf

В Mate и xfce отключены эффекты для повышения производительности. На xfce наблюдаются из-за этого артефакты в трее.

О замеченных проблемах и предложения по улучшению пишите мне.

Оффлайн Антон Мидюков

  • alt linux team
  • ***
  • Сообщений: 3 988
  • antohami@
Началось формирование еженедельных регулярных сборок для одноплатных компьютеров с архитектурой aarch64 и armh на основе репозитория Sisyphus.

Небольшое пояснение по поводу еженедельности. На странице вики прямые ссылки на загрузки указывают сборки, помеченные как tested. В случае каких-то проблем сборки не будут помечаться как tested, и может получиться, что ссылки не будут обновляться 2-3 недели подряд. Но раз в месяц тестовая сборка должна обновиться, если конечно ЧП какое не случится.

В течение месяца набирается 4 еженедельных снапшота:

http://nightly.altlinux.org/sisyphus-armh/snapshots/

http://nightly.altlinux.org/sisyphus-aarch64/snapshots/

Уже есть два. Последний помечен, как tested. Ведутся сhangelog:

http://nightly.altlinux.org/sisyphus-armh/ChangeLog

http://nightly.altlinux.org/sisyphus-aarch64/ChangeLog

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



Оффлайн Grommit

  • Давно тут
  • **
  • Сообщений: 82
Добрый день.

На xfce наблюдаются из-за этого артефакты в трее.

До сих пор наблюдаются... Есть ли какое то решение?

Онлайн Skull

  • Глобальный модератор
  • *****
  • Сообщений: 18 551
    • Домашняя страница
    • Email
Да. Включить аппаратное ускорение.
Андрей Черепанов (cas@)

Оффлайн Balbes

  • Мастер
  • ***
  • Сообщений: 555
Пробую последние версии регулярок и старткитов на разных железках (Jetson-nano rk3399 rk3328 H6).
Плохая новость - обнаружил ряд багов, которые мешают процессу запуска. Инфы много, но мало времени, поэтому буду писать "кусками".
Хорошая - бегло посмотрел, все баги решаемы малыми средствами.

1. Jetson-Nano. Пробовал разные варианты - все не рабочие. Судя по получаемым разделам после записи образов на носители - используется старая схема, которая больше не поддерживается. Нужно менять структуру. С начала года NVIDIA перешли на нормальную версию u-boot (который автоматом обновляется в SPI при запуске последней официальной версии SD образа) и больше не нужно записывать ни какой u-boot в состав образа или на носители, все отлично работает без него. Попутно нормально заработал старт с USB носителей. Кстати, есть основная поддержка Nano в основном ядре и можно использовать для сборки образов.

2. rk3399. Есть ошибка в ядре, которое используется для образов. Не верный конфиг и не правильное размещение DTB файлов.

Оффлайн Антон Мидюков

  • alt linux team
  • ***
  • Сообщений: 3 988
  • antohami@
1. Jetson-Nano. Пробовал разные варианты - все не рабочие. Судя по получаемым разделам после записи образов на носители - используется старая схема, которая больше не поддерживается. Нужно менять структуру. С начала года NVIDIA перешли на нормальную версию u-boot (который автоматом обновляется в SPI при запуске последней официальной версии SD образа) и больше не нужно записывать ни какой u-boot в состав образа или на носители, все отлично работает без него. Попутно нормально заработал старт с USB носителей. Кстати, есть основная поддержка Nano в основном ядре и можно использовать для сборки образов.

При помощи alt-rootfs-installer используем старый SDK и всё работает.
Я пробовал записывать в SPI новый u-boot с новым SDK. Ядра std-def и un-def не смогли загрузиться. Ядро mp загрузилось с SD-карты, но не работает usb. Что ещё надо включить в ядрах, я не знаю.

2. rk3399. Есть ошибка в ядре, которое используется для образов. Не верный конфиг и не правильное размещение DTB файлов.

Неверное размещение dtb от того, что используется не альтовский u-boot. А если расскажете, что поправить в конфиге ядра, будем благодарны.

Оффлайн Balbes

  • Мастер
  • ***
  • Сообщений: 555
При помощи alt-rootfs-installer используем старый SDK и всё работает.
Я пробовал записывать в SPI новый u-boot с новым SDK. Ядра std-def и un-def не смогли загрузиться. Ядро mp загрузилось с SD-карты, но не работает usb. Что ещё надо включить в ядрах, я не знаю.

Неверное размещение dtb от того, что используется не альтовский u-boot. А если расскажете, что поправить в конфиге ядра, будем благодарны.

Я использовал  инструмент alt-rootfs-installer для подготовки образов. Такой вариант допустим для начального этапа, и только для ограниченного применения разработчиками. Для использования обычными пользователями (для реальной эксплуатации) это явно не подходит. Например, что делать пользователям, у которых нет Альтов и есть только винда ? Кстати, сам инструмент очень не удобный, нужно вводить всё полностью руками и малейшая опечатка\ошибка грозит проблемами. Для пользователей всё должно быть предельно просто. Скачал архив образа (обращаю внимание, не архив рутфс, а полноценный образ), распаковал, записал штатными инструментами той системы, что есть у пользователя на носитель. Подключил к устройству и всё запускается. В некоторых случаях допускается простейшая донастройками (указать другой DTB, параметры запуска ядра и т.д.), опять же штатными инструментами (любым текстовым редактором). Только в этом случае можно рассчитывать на перспективы, что пользователи станут этим пользоваться массово. Что мешает перенести весь функционал по созданию готового образа в профиль сборки ?

Вы тестировали запуск образов (со старым SDK) на Jetson-Nano с правильно обновлённым u-boot (SPI) ? NVIDIA не просто так перешли на новый вариант, это сразу решило много проблем и они настоятельно рекомендуют всем переходит на новый вариант. Поэтому предлагать сейчас старый вариант - не разумно.

Основное ядро (я так полагаю std-def и un-def основаны на исходниках Linux 5.х, а не BSP 4.9 от NVIDIA ? ) отлично запускается и правильно работает на Jetson-Nano с новым u-boot SPI. Достаточно правильного конфига extlinux.conf и правильно собрать ядро (DTB, конфиг, прошивки).
Дайте ссылку на профиль сборки, я подскажу, что и где нужно изменить, что-бы всё нормально работало и что нужно добавить для USB. Как пример, вы может попробовать версии Armbian для Nano, есть варианты с ядром BSP (Legacy 4.9) и с основным ядром 5.х.

https://disk.yandex.ru/d/srrtn6kpnsKz2

Сейчас я тестирую изменённое ядро mp (добавил не большие исправления, что-бы правильно формировалась структура DTB и изменил конфиг для поддержки платформ RK AW Jetson-Nano). По окончанию тестирования и отладки, я выложу изменения, которые делаю в исходниках gear.  Кстати, вопрос, как прописать в спеке, что-бы накладывать сразу все патчи в алфавитном порядке из определённой директории ?

Что значит "используется не альтовский u-boot" для rk3399 ?

Посмотрел тему про запуск на RK3399, похоже у вас не верное представление о работе процесса запуска на этой платформе. Для информации. Консоль UART на rk33xx работает исключительно на скорости 1500000, и требует правильной настройки в extlinux.conf. Когда я тестировал образы альтов на rk3399, я изменил настройки на правильные, и отлично вижу весь процесс запуска, поэтому точно знаю, в чём у вас проблема. :)

п.с. я не просто пытаюсь нагнать критики, я планирую принять практическое участие и довести до рабочего состояния (простого использования любым пользователем) Альтов на платформе ARM, пусть не полностью, но хотя бы близко, к тому, как это сейчас есть в Armbian. :)

Оффлайн Антон Мидюков

  • alt linux team
  • ***
  • Сообщений: 3 988
  • antohami@
Например, что делать пользователям, у которых нет Альтов и есть только винда ?

На других Линуксах работает. Распаковываем архив и запускаем. На винде только в виртуалке. Регулярки и стартеркиты не предназначены для обычных пользователей Windows. Для Raspberry Pi выпускаем образ, который можно записать хоть через ALT Media Writer, хоть через утилиту от создателей малины.

Что мешает перенести весь функционал по созданию готового образа в профиль сборки ?

Есть несколько причин:
1 Придётся собирать ещё больше образов, а я этого не потяну. Собираю на Raspberry Pi 4 8 ГБ. Почему больше потребует? Потому что для Rockchip нужен GPT и отступ в 16 МБ. А для Allwinner нужен mbr. GPT на малине будет грузиться только с USB. Т.е. придётся умножить на два.
2 u-boot у каждой платы свой. Т.е. пользователю его всё равно придётся записать самому. Далеко не увсех плат u-boot можно записать в spi flash.
3 сейчас img создаются с использование /dev/loop с повышенными привилегиями. Это жутко неудобно, но пока не удаётся засесть и переделать, чтобы образ собирался с использованием https://www.altlinux.org/Usermode-fs-tools

1 и 2 можно было бы решить, записывая u-boot в spi flash платы. Но не для всех это возможно.

Вы тестировали запуск образов (со старым SDK) на Jetson-Nano с правильно обновлённым u-boot (SPI) ?

Нет. Я записал новый SDK в SPI и пробовал грузить rootfs с обычными ядрами 5.10.x и 5.12.x, не записывая в них ничего от SDK.

Основное ядро (я так полагаю std-def и un-def основаны на исходниках Linux 5.х, а не BSP 4.9 от NVIDIA ? ) отлично запускается и правильно работает на Jetson-Nano с новым u-boot SPI. Достаточно правильного конфига extlinux.conf и правильно собрать ядро (DTB, конфиг, прошивки).

extlinux.conf правильный. dtb я копировал в правильное место, чтобы u-boot загрузил. А вот конфиг ядра под вопросом. Я сравнивал с Armbian, разницу устранил, но не помогло.

Дайте ссылку на профиль сборки, я подскажу, что и где нужно изменить, что-бы всё нормально работало и что нужно добавить для USB. Как пример, вы может попробовать версии Armbian для Nano, есть варианты с ядром BSP (Legacy 4.9) и с основным ядром 5.х.

Ядра?

Консоль UART на rk33xx работает исключительно на скорости 1500000, и требует правильной настройки в extlinux.conf. Когда я тестировал образы альтов на rk3399, я изменил настройки на правильные, и отлично вижу весь процесс запуска, поэтому точно знаю, в чём у вас проблема. :)

Нет. Мы записываем u-boot на SD-карту. И грузим u-boot с неё. Альтовский u-boot берёт dtb из правильного места и использует скорость 115200.
Как записать u-boot на плату, я не разобрался, к сожалению.

Кстати, вопрос, как прописать в спеке, что-бы накладывать сразу все патчи в алфавитном порядке из определённой директории ?

Ну, можно же закоммитить все патчи, тогда в спеке ничего патчить не придётся.

п.с. я не просто пытаюсь нагнать критики, я планирую принять практическое участие и довести до рабочего состояния (простого использования любым пользователем) Альтов на платформе ARM, пусть не полностью, но хотя бы близко, к тому, как это сейчас есть в Armbian. :)

Спасибо! Я открыт для помощи :-)

Оффлайн Merblud

  • Давно тут
  • **
  • Сообщений: 404
2 Balbes
А можете подсказать, в чем может быть причина такого поведения платы на rk3399.
Насколько я помню, загрузчик, прошитый в SoC на заводе сначала пробует грузиться с sd-карточки. Если её нет он грузит загрузчик из набортной флэшки.
До какого-то момента времени это так и работало. У меня в нбортную флэшку прошит древний дистрибутив от вендора железяки. Так что, если карточка не вставлена, то он и грузился из флэшки. Если вставить карточку, то грузился дистрибутив с карточки.
Но с какого-то момента времени стало недостаточно вставить карточку в плату, чтобы с неё загрузиться. Стало необходимо ещё зажимать кнопку boot. Но кроме того, её еще необходимо вовремя отпустить, иначе загрузка не идет дальше. Такое впечатление, что загрузчик с карточки пытается подгрузить какой-то очередной компонент с набортной флэшки. Если не отпустить кнопку boot, то эта флэшка останется недоступной и процесс циклится.

Оффлайн Balbes

  • Мастер
  • ***
  • Сообщений: 555
Цейтнот со временем, поэтому сори, что отвечать буду "постепенно кусками".

На других Линуксах работает. Распаковываем архив и запускаем.
Не всё работает даже на родных Альтах. Например, при создании образа из архива, нужно указывать полный путь, куда размещать образ, если по вики (указать только имя образа), процесс проходит, но образа нет, есть и другие неудобства - нет подстановки имени\каталогов, нужно всё писать руками и малейшая опечатка - на выходе ошибка. Лично я бы не рискнул запускать чужой софт , который напрямую пишет на носители в других системах (если ошибка в поведении софта на чужой системе, снёс всю систему или затёр бинарно диск).

На винде только в виртуалке. Регулярки и стартеркиты не предназначены для обычных пользователей Windows.
Если уже сейчас не начать использовать нормальную технологию, удобную для обычных пользователей, это так и останется в зачаточном состоянии для "фанатов-гиков".  И про продвижение Альтов на ARM можно забыть.

Придётся собирать ещё больше образов
Сейчас вы собираете много не нужного и не востребованного. Вы смотрели кол. закачек того, что есть ? Лучше иметь несколько гарантированно работающих и используемых систем (образов), чем кучу не пользующегося ни каким спросом, только отнимающее ресурсы (на сборку и размещение).

Потому что для Rockchip нужен GPT и отступ в 16 МБ. А для Allwinner нужен mbr. GPT на малине будет грузиться только с USB. Т.е. придётся умножить на два.
У тебя не верная информация. RK отлично работает с любой таблицей. И нет ни каких проблем собрать разные образы на ARM. Рекомендую посмотреть сборочную среду Armbian, там всё давно уже реализовано и отлично работает, можно собирать образы хоть на x86, хоть на любом ARM.  Например я собираю на Station P1 все образы (для RK AW Jetson-Nano с основным ядром и т.д.). Обращаю внимание, это полный цикл сборки (u-boot ядро все доп.пакеты которых нет в сетевом репе) и на выходе готовые упакованные образы с контрольными суммами, которые сразу можно грузить на скачку.

2 u-boot у каждой платы свой. Т.е. пользователю его всё равно придётся записать самому. Далеко не увсех плат u-boot можно записать в spi flash.
Пользователю ни чего не нужно записывать дополнительно, всё уже есть в готовом образе и u-boot и настройки DTB и прочее, специфичное для каждой модели. Это всё легко решается профилем сборки.

1 и 2 можно было бы решить, записывая u-boot в spi flash платы. Но не для всех это возможно.
Судя по этому и другим сообщениям у тебя не верное представление о загрузке и особенностях для разных платформ, придётся тебя "подтягивать и обучать"  :)

Что-бы не путаться, пока всё сказанное будет по платформе RK, по Jetson-nano нужно делать отдельный "ликбез", вижу там то же пробелы с правильным пониманием процесса запуска  ... :)

Альтовский u-boot берёт dtb из правильного места и использует скорость 115200.
Не-а  :)   не правильно указаны настройки откуда брать DTB, не правильные настройки UART и прочее ... У тебя есть реальное железо с RK ?

Как записать u-boot на плату, я не разобрался, к сожалению.
и это хорошо ... а то бы угрохали железки и прошлось скакать с маскромо ... :)
Установка системы (в том числе u-boot в eMMC \ SPI) уже давно отработанно в Armbian и LE и отлично себя показало. Со временем сделаю и для альтов.

Ну, можно же закоммитить все патчи, тогда в спеке ничего патчить не придётся.
С этого места и подробно для бестолковых, нужно существенно изменять текущие ядра, что-бы они полноценно работали на RK\AW. В идеале нужен другой пакет ядра, без дерьмо патчей от RPi (RPI4 - это самое дерьмовое железо, которое я встречал на ARM).

А можете подсказать, в чем может быть причина такого поведения платы на rk3399.
Насколько я помню, загрузчик, прошитый в SoC на заводе сначала пробует грузиться с sd-карточки. Если её нет он грузит загрузчик из набортной флэшки.
До какого-то момента времени это так и работало. У меня в нбортную флэшку прошит древний дистрибутив от вендора железяки. Так что, если карточка не вставлена, то он и грузился из флэшки. Если вставить карточку, то грузился дистрибутив с карточки.
Но с какого-то момента времени стало недостаточно вставить карточку в плату, чтобы с неё загрузиться. Стало необходимо ещё зажимать кнопку boot. Но кроме того, её еще необходимо вовремя отпустить, иначе загрузка не идет дальше. Такое впечатление, что загрузчик с карточки пытается подгрузить какой-то очередной компонент с набортной флэшки. Если не отпустить кнопку boot, то эта флэшка останется недоступной и процесс циклится.
О какой модели речь? Nano PC T4  ? И подробнее о систем, которую запускаете с SD карты.

п.с. Надеюсь Антон без обид за наезды со знаниями железок, но тяжко читать "ересь" от отвечающего за выпуск ARM в альтах  ... :)
и кстати, какое у тебя железо в наличии (что-бы понимать, что советовать) ?

Оффлайн Антон Мидюков

  • alt linux team
  • ***
  • Сообщений: 3 988
  • antohami@
п.с. Надеюсь Антон без обид за наезды со знаниями железок, но тяжко читать "ересь" от отвечающего за выпуск ARM в альтах  ... :)

Я отвечаю за выпуск регулярок и стартеркитов для i586, x86_64, aarch64, armh. Также я ответственный за инструмент сборки образов mkimage-profiles. Да, я не специалист по ARM.

и кстати, какое у тебя железо в наличии (что-бы понимать, что советовать) ?

Raspberry Pi 3B Plus, Raspberry Pi 4B 4 ГБ, Raspberry Pi 4B 8 ГБ, Orange Pi Prime, Nano PC T4.

С этого места и подробно для бестолковых, нужно существенно изменять текущие ядра, что-бы они полноценно работали на RK\AW. В идеале нужен другой пакет ядра, без дерьмо патчей от RPi (RPI4 - это самое дерьмовое железо, которое я встречал на ARM).

В ядрах std-def и un-def точно нет специальных патчей для поддержки Raspberry Pi. Они собираются из git. Так что не вижу проблем сделать изменение прямо в исходных кодах.
http://git.altlinux.org/gears/k/kernel-image-std-def.git
http://git.altlinux.org/gears/k/kernel-image-un-def.git
Но сам ядра не собирал, так что могу ошибаться.

Не-а  :)   не правильно указаны настройки откуда брать DTB, не правильные настройки UART и прочее ... У тебя есть реальное железо с RK ?

Есть Nano PC T4. Посмотри на u-boot альтовский, потом утверждай. Пакет u-boot-rockchip. Я же загружался. Ядро mp одно время нормально грузилось (ну как нормально? PCI не работал). Мы грузим dtb от ядер.

Пользователю ни чего не нужно записывать дополнительно, всё уже есть в готовом образе и u-boot и настройки DTB и прочее, специфичное для каждой модели. Это всё легко решается профилем сборки.

Ну подожди. Я конечно, подозреваю что u-boot для одного SoC, но разных плат отличаются только dtb, но для других SoC даже этого производителя u-boot то уже другой же? А записываются в одно и тоже место.

Обращаю внимание, это полный цикл сборки (u-boot ядро все доп.пакеты которых нет в сетевом репе) и на выходе готовые упакованные образы с контрольными суммами, которые сразу можно грузить на скачку.

Мы так не делаем. Мы собираем строго из пакетов в репозитории. Но, если ты мне распишешь, какая должна быть универсальная таблица разделов (какие разделы, с какими параметрами и т.д.) и куда писать u-boot, то я доделаю вмиг tar2fs и буду выдавать на гора img.xz.
« Последнее редактирование: 16.07.2021 15:58:26 от Антон Мидюков »

Оффлайн Merblud

  • Давно тут
  • **
  • Сообщений: 404
О какой модели речь? Nano PC T4  ? И подробнее о систем, которую запускаете с SD карты.

Она самая. Система Альтовская, регулярные сборки. С какого момента времени такое начало происходить уже не припомню. Но, вроде бы, Armbian тоже стал так же себя вести.

Оффлайн Balbes

  • Мастер
  • ***
  • Сообщений: 555
Orange Pi Prime, Nano PC T4.
Из приличного, только две модели. Но H5 слабоват для сборки (нет возможности подключить быстрый носитель для размещения системы), хотя для лёгкого десктопа с не большим разрешением и тестирования подходит.
Остаётся Т4,  NVMe на ней есть ?

Посмотри на u-boot альтовский, потом утверждай.
Улыбнуло .... вообще в природе есть только два вида u-boot для RK - апстримный и модифицированный и древний от Rockchip. Хочешь сказать, альты изготовили новую оригинальную версию ?  :)

Я же загружался. Ядро mp одно время нормально грузилось (ну как нормально? PCI не работал). Мы грузим dtb от ядер.
Что-бы конкретно объяснить, что нужно исправить, предлагаю две вещи. Выкладывай куда-нибудь образ (не архив, а именно образ) для Т4 и второе - выкладывай полный лог UART твоего процесса запуска этого образа на Т4. Я знаю, в чём проблема, но на конкретном примере проще показать, что исправлять.

что u-boot для одного SoC, но разных плат отличаются только dtb,
Не только разные DTB, но и часто разные конфиги. Есть близкие по конфигу модели, а есть не совместимые, с которыми ты ни когда не сможешь полноценно (или вообще) запустить другую модель.

.
А записываются в одно и тоже место.
Не в одно и тоже место. У разных платформ свои правила формирования u-boot и правила записи (адреса). Но в принципе можно иметь один универсальный образ для всех платформ RK AW AML и потом только накладывать (записывать) свой вариант u-boot для конкретной общей группы устройств. Кстати, это можно делать даже из под винды. Ранее я выпускал такие универсальные образы сразу для всех платформ и пользователь тупо из под винды мог с начала записать образ и после этого, сразу записать образ загрузчика. Но там есть неудобство для разработчика - поддерживать наборы загрузчиков и пользователю еще нужно руками править extlinux.conf (оставлять строки настроек под своё железо).

Но, если ты мне распишешь, какая должна быть универсальная таблица разделов (какие разделы, с какими параметрами и т.д.) и куда писать u-boot, то я доделаю вмиг tar2fs и буду выдавать на гора img.xz.
Самая простая для использования - mbr (легче авторасшринеие делать, проще управлять). С ней проще работать и ее достаточно для размеров текущих носителей, которые массово используются на этом железе. Раздела хватит одного ext4 (с автоматическим расширением на весь носитель при первом запуске). Перед разделом оставляешь 16 Мб места, для размещения загрузчика. Размер выбираем по самый требовательный RK, ему нужно 16Мб. Остальные загрузчики легко укладываются в это и тоже работают.

Но, вроде бы, Armbian тоже стал так же себя вести.
Точная версия образа, и очень желательно лог UART.