Comments 20
Подскажите, а есть ли возможность арендовать сервер с ARM процессором у вас?
Спасибо! :)
Да, есть возможность арендовать сервер фиксированной конфигурации. Либо протестировать ARM-процессор в сборке бесплатно — в нашей лаборатории Selectel Lab (единственное — там есть очередь на тест).
Анекдот.
Интревью с Ф. Бондарчуком:
-- Скажите, Федор, как Вам фильм "Пираты карибского моря 4"?
-- О, это замечательный фильм! Отличная режиссерская работа! Я снимаю шляпу!
-- Федор, мы знаем, что Вы снимаете! Расскажите, как Вам фильм?
(не про вас, это просто вспомнил, прочитав комментарий)
Ура, датацентры начали понимать боль embedder'ов. И уж поверьте - сетевая загрузка, логгирование и прочее - это ерунда. А вот зоопарк видеосистем, media-систем, power-management'ов и прочего (имя им легион - включая самые разные пенки в (u)EFI, включая полное отсутствие оного) - во это да...
Жить с aarch64 можно, но... Или лезть глубоко и не иметь никаких гарантий повторяемости достигнутого результата на другой платформе, или... замыкаться на одном вендоре и надеяться на его вечную молодость и конкурентоспособность. А равно на его умение держать обещания. Увы, но пока все довольно грустно.
Именно поэтому особенно забавно смотреть на попытки некоторых удивительных людей саботировать внедрение UEFI и ACPI на большие aarch64-машины, под предлогом того, что "нам этого переусложненного хлама тут не надо, мы отлично справляемся с нашими Device Tree и трехстадийными патченными-перепатченными загрузчиками такого же патченного-перепатченного ядра линукса".
Замечательно справляетесь, пацаны, продолжайте. /s
А тут вопрос сильно сложнее...
В целом, я абсолютно согласен. Есть такой момент. Тем более, что для EBBR многого и не надо. Да и не запрещает он использовать device-tree. Потому как ACPI штука хорошая, но... не родная что-ли. Если б все выполняли требования данного документа (в мире встраиваемых систем) или его аналога для остальных - жизнь была бы сильно более простой.
С другой стороны - у меня на столе TCL Book 14 Go - как думаете что там с ACPI? Можно ли его нормально загрузить без dtb'irb (которую еще надо как-то сделать)? Так вот - со всей ответственностью - нельзя. И тут ситуация как и на x86 - гора платформенно зависимых патчей. С другой стороны вопрос заводки того же Linux на этой машине - это выкладывание DTS'ки производителем. И, честно скажу, на месте производителя я бы сильно задумался что проще - сделать DTS или исправить косяки в DSDT.
Но повторюсь - в идеальном мире правильная ACPI везде было бы лучшим решением. К сожалению это не получилось даже на x86/x64, потому и на ARM64 к этой штуке есть много вопросов...
Ну я тут иронизирую не по поводу Device Tree конкретно, потому что с ними как раз нет особых проблем (а еще потому, что у меня самого рыло в пуху по самый хвост, и на больших aarch64-машинах, к которым я уже несколько лет прикладываю руку, никаких UEFI и ACPI нет, зато без Device Tree они не грузятся дальше iBoot-та первой стадии), а именно по поводу позиции "к черту вашу сложную гадость, у нас тут все хорошо".
Настолько хорошо, что сама arm буквально запрещает использовать Device Tree на системах, реализующих Server Base Boot Requirements:
Systems using SBBR recipe must meet the requirements that are specified in section 5 (PSCI/SMCCC), section 6 (Secondary Core Boot), section 7 (UEFI), section 8 (ACPI), and section 9 (SMBIOS).
Хорошо это или плохо - очень дискуссионный вопрос, но на мой взгляд, скорее хорошо. Безобразно, зато единообразно, бери любой дистрибутив любой популярной ОС и ставь его прямо из ISO-образа, а не вот это все.
Как по мне, так надо просто различать миры Server, Consumer и Embedded. Первые два просто обязаны грузиться единообразно, и, в идеале, унифицировано с привычной уже архитектурой x86/amd64. Т.е. UEFI, т.е. ACPI, т.е. SecureBoot. У них не меняется состав системы и им не надо оперативно вносить серьезные правки в DSTD. Они по сути законченное техническое решение, у которого шины позволяют динамическое изменение конфигурации. И уже не так важно на горячую или с остановкой.
А вот со встраиваемыми... Тут точно без DTS не обойтись. По той простой причине, что довольно распространенная ситуация выглядит так - процессор на модуле (и базовая DTS с PMIC, внешними шинами, GPIO). Далее модуль на базовой плате (и довесок к DTS в виде кнопок, датчиков, исполнителей, источников и прочего). Базовая плата в изделии разных модификаций под разные нужды - а значит опять с разными дополнительными кусками в DTS. Которая может лежать тупо на накопителе и быть разной для разных итоговых изделий. С ACPI и ее DSDT такое сделать сильно сложнее.
А вот зоопарк загрузчиков... Вот это да... У меня одна плата работает только с патченым-перепатченым U-Boot аж от 2017-ого года. При том, что вроде последний ванильный для нее даже собирается, но... В нашем мире собирается и работает - это две большие разницы. А уж работает полнофункционально - это вообще третье.
В целом DenX молодцы. У них есть код, который позволяет соответствовать EBBR, но дьявол как всегда в деталях. В частности крайне плохо решается вопрос с efi-vars. Единственное сколько-нить серьезное решение - это хранение их в файле на ESP разделе, но... Я уже вижу как вы улыбаетесь.
Так что как обычно - все сильно зависит от вендоров. А они друг с другом договариваться ой как не любят. С другой стороны может оно и к лучшему - без работы я точно не останусь.
Убунта в свое время неприятно “порадовала”, когда после очередного обновления версии оказалось, что перестал поддерживаться старый встроенный видеоадаптер. Причем это стало понятно через несколько версий, потому как доступ к серверу был через Путти и веб интерфэйс. А когда сервер пришлось настраивать напрямую оказалось что вместо текста на экране каша из символов. Так что там не только новые архитектуры могут глючить, но и старые.
Для всего этого мы использует кастомную сборку Arch Linux — внутри компании мы называем этот дистрибутив rescue.
Как пользователь Arch Linux хочу спросить: почему для этого вы используете именно Arch?
Есть несколько причин - нам нужно максимально свежее ядро для поддержки нового железа, относительно просто модифицировать образ для наших потребностей, отсутствие лишних пакетов. Ну и самая главная - так исторически сложилось :)
Очень хочется «пощупать» это железо и протестировать работу нашего софта на нём, а мощностей малинки будет маловато (особенно по части оперативной памяти), есть конечно вариант сделать кластер из малинок, но очень не хочется заморачиваться таким.
А почему не подходит аренда сервера с ARM-процессором? Потестируете и сдадите.
Не по серверам, но по поводу сборки арча под арм. Я хотел сделать свою сборку под Pinephone Pro - сама сборка была довольно простой, я даже нормально собрал своё ядро, но все сложности начались с драйверами.
Ничего не работало ни со стандартным ядром, когда я пытался загружать модули, что со своим ядром, когда я при сборке отмечал галочками и всё, что имело отношение к видеочипу и к сетевому. Скорее всего, дело было в firmware, или в fdt, но я так и не разобрался.
Это вам не x86_64. Проблемы сборки Arch Linux под ARM-архитектуру и как мы их решали