WIndows можно поставить на nvme если заменить дрйвера stornvme.sys и storarchi.sys на их мартовскую версию.
Без этих драйверов в любом случае выкидывает BSOD. Я интегрировал эти драйвера в образ. Еще раз повторю, "с Fanxiang S500 Pro PCIe 3.0 x4 приводил к BSOD еще на стадии запуска. Со старым диском Samsung SSD удалось запустить, однако при начале работы, при выполнение операций записи, система все равно выкидывала BSOD."
Даже с заменой драйверов stornvme.sys и storarchi.sys заработают только некоторые SSD.
При наличие SPI NOR, просто удобнее, в особенности если вы экспериментируете с двумя разными системами. Один загрузчик можно разместить на SPI NOR, другой на microSD карте. Спасибо за вопрос, @NutsUnderline подробно объяснил.
Допустим даже что текст не перевод и не компиляция.
Что значит допустим? Вы шо Еврей? Материал 500% авторский, мой. Полный список литературы могу отправить. На Хабре публикую сокращенный, потому что до этого модераторы Хабра говорили, что у меня очень много ссылок в посте. Поэтому ссылки на второстепенные источники режу.
Далее, "попробуй использовать Orange PI 5 Plus дальше запуска рабочего стола.". Нужно понимать что это первая водная статья. Тематика аппаратной виртуализации и программирование с использованием NPU, работа UEFI, вам подходит? Так, не все сразу.
Я же написал, предложите свои темы для рассмотрения, не вопрос. Если тема действительно окажется интересной и полезной для аудитории, то от меня благодарность и респект.
ссылки на Google Drive с которого не скачать из-за превышения лимита скачиваний
Я всегда качаю через VPN, никогда не было проблем. Если есть какие либо проблемы, могу без проблем продублировать на MEGA.NZ, там у меня большой лимит, надеюсь его хватит.
Я так понял у вас в наличие такая же плата Orange PI 5 Plus. Попробуйте вариант Joshua Riek дистрибутива как в этом после.
Кстати, как игрок заметил еще в варианте Joshua Riek небольшой лаг между движением мыши и указателя на экране. Он ничтожный, буквально наверное микросекунды, но он есть. Вначале замечаешь, но потом привыкаешь.
Но самое интересное, этого лага нет на этой же плате в варианте Windows 11. Пока как говорится без комментариев, детально тему не исследовал.
Вы же верно написали) К процессорам десятилетней давности, идет речь про low и middle сегмент по производительности ПК. Ок, говорим про low сегмент. т.е. сейчас ARM можно сказать нацеливается на low сегмент мини-ПК замещения x86 процессоров.
Half-Life 2 до последнего обновления на самом деле неплохо шел. Но после обновления в Steam, прям заметно стал тормозить. Визуально оценивать скорость игры сложно. Хотелось бы видеть в кадре значение fps. Оверлеи в Steam не работают. Сторонние средства, для Intel и NVIDIA игр, для так сказать нашего случая не нашел, может быть в курсе есть ли возможность отобразить fps в играх, раз вы так в этом хорошо разбираетесь?
На non-X86 SBC тоже может быть 40-pin GPIO, только есть нюанс. Два варианта рассмотрено в этом посте, текст начинается со слов "Еще один подвох одноплатных компьютеров на x86 процессорах заключается в управление GPIO ..."
Это вы зря "но можно не читать", для понимания ситуации лучше прочитать, но не претендую на истину в последней инстанции. Возможно я недостаточно акцентировал внимание именно на тренде изменений. То что было раньше 10 лет назад и сейчас, это просто день и ночь. За это время много что изменилось. Например, раньше Qualcomm тоже смеялась на MTK, но текущие продажи говорят что это MTK тогда нужно было смеяться.
Суть такова, что китайцы прут как не в себя. Это жесткая экономическая и информационная экспансия. Да, пока есть отставание и софт не допилен, но они однако уже дышат в спину.
И почему мне это интересно, я хочу получить мини-ПК в форм факторе телефона, с экраном и всеми плюшками, который будет в два раза толще обычного, с наличием контактов GPIO для программирования, с UEFI и запуском Android, Linux, Windows. Так сказать начать настоящую эру пост-ПК.
Кстати, хороший критерий оценки поста вы подали, по наличию комментариев и добавлений в закладки, отличная идея для написания своего расширения браузера.
Вы так и не поняли, про что вам говорят. Автор англоязычного исходного текста недостаточно точно написал, в контексте "wonky HAL libraries", потому что специалист должен выражаться максимально технически грамотно. В противном случае, пусть пишет прозу, там это пожалуйста. Что такое HAL?
Hardware Abstraction Layer (HAL, Слой аппаратных абстракций) — слой абстрагирования, реализованный в программном обеспечении, находящийся между физическим уровнем аппаратного обеспечения и программным обеспечением, запускаемом на этом компьютере. HAL предназначен для скрытия различий в аппаратном обеспечении от основной части ядраоперационной системы, таким образом, чтобы большая часть кода, работающая в режиме ядра, не нуждалась в изменении при её запуске на системах с различным аппаратным обеспечением. Источник wiki.
Самое простое понимание, упрощенно, HAL это драйвера, это не какая то отдельная библиотека для всех компьютеров.
Короче говоря, автор не смог написать правильно, и итоге получился проводник который бегал по проводам.
Суть следующая, автор говорит что ему сложно и неудобно работать с уровнем HAL на МК потому что, это достаточно низкий уровень управления устройства. т.е. wonky необходимо понимать в контексте СЛОЖНОСТИ ПРОГРАММИРОВАНИЯ, а не дословного перевода. Необходима высокая техническая база для написания просто элементарного кода.
Далее, следующий проводник бегающий по проводам это "Linux API гораздо надёжнее и стандартизированнее". Никакого абстрактного "стандарта Linux API" в понимание RFC не существует, есть конкретные стандарты, мало того от версии к версии ядра этот API постоянно меняется. Именно поэтому на OPi4LTS в версии ядра Linux 5.10, Wi-Fi на 5 ГГц работает, а в версии 6.X нет. Но тогда про что идет речь? Речь идет о стандарте подхода программирования используя API, это разные вещи. Если смотреть как вы перевели, то API само по себе как субъект не может быть надежным или нет, понятие надежности применимо к работающим информационным системам, но не как API.
В данном случае, автор под понятием "Linux API гораздо надёжнее и стандартизированнее", подразумевает не наличие некого стандарта так такового, а стандарта подхода программирования на примере символьных устройств, например, ваш текст "то мы сможем удобно отображать все эти устройства", как раз таки об этом и говорит. Просто читателю непонятно, где и как отображать эти устройства и вообще про что идет речь.
Программный код написания USB устройств между разными МК крайне сложно перенести. В случае использования Linux API, код можно переносить практически без изменений, потому что есть возможность использовать более высокий уровень абстракции. В своих постах я писал про nanoFramework и microFramework. В частности в microFramework я сделал конвертор USB устройства Microsoft Xbox 360 Controller Gamepad в HID-устройство клавиатура. Это было сделать не сложно, потому что использовался высокий уровень абстракции на базе платформы .NET.
Вот что я хотел до вас донести, в случае "сложных" технических постов делайте техническую экспертизу.
P.S. С литературной точки зрения, вы все равно неправильно перевели "wonky HAL libraries" дословно переводится не как "пользоваться неуклюжими библиотеками HAL", а "шаткие библиотеки HAL". Ключевое слово шаткий, запомните, английский язык это функциональный язык. Шаткий это функция, означающая перемены, изменчивость. На русский язык, так напрямую переводить нельзя, потому что получается хрень.
т.е. автор говорит что в случае использования МК эти библиотеки HAL каждый раз будут другими от перехода от одного МК к другому, этим он и говорит что для него HAL библиотеки и неудобны.
В русском язык слово шаткий, скорее всего читатель воспримет в контексте неустойчивости, что-то не прочное. Например, шаткие доводы, как говорит Толковый словарь Ожегова. Именно поэтому такое нельзя переводить дословно, и как вы перевели. А нужно писать нормальное технические разъяснение.
P.S.S это наверное тот случай, когда в комментариях более понятно, чем в посте.
При всем к вам уважении, ваш ответ эквивалентен выражению из анекдота, "это не дерьмо, а засахарилась". То что вы пишите, это показатель вашего отношения к аудитории, и вашего профессионализма. Говорить "пипл и так схавает", не вызывает никакого уважения. Существует такое понятие как профессиональная этика. Любой нормальный специалист никогда не позволит писать подобную дичь, именно так.
Да все мы люди, и ошибки допускаем. Но писать "неуклюжими библиотеками HAL", технически безграмотно, я не поверю что у вас, как минимум в штате, нет специалистов разбирающихся в архитектуре ОС и Linux. Мое предложение следующее, прежде чем взяться за пост, определяйте его маршрут.
Маршрут №1. Пост пишет автор на тему, в которой сам разбирается и готов как минимум ответить на 80% всех вопросов по данному посту (идеальный вариант).
Маршрут №2. Человек делает предварительную выборку интересных тем для переводов. Затем эта выборка передается специалистам для краткого анализа и исключения полной хрени еще до стадии перевода, помним правило информатики GIGO (Garbage in, garbage out). Далее, перевод желательно человеком, хоть отдаленно понимающий про что идет речь в оригинальном посте. Далее, профильный специалист из результата перевода вычищает дичь в стиле "неуклюжими библиотеками HAL".
Мне особо и помнить не надо). Напротив меня в книжную полку вставлена книга Стандарты и спецификация USB, толщина заметно больше Библии, скажу более, это одна из самых толстых моих книг. Но это не избавляет, хотя бы кратко технически грамотно описать предмет рассмотрения. Не буду первооткрывателем, тему можно разбить на два поста, первый стандарт и теория, второй практика. И основная моя претензия заключается в низком качестве исходного материала. Автору исходника претензий нет, он так чувствует, имеет на это право, а вот к переводчику есть. У меня есть пост Безопасность встраиваемых систем Linux. Тема безопасности знаете тоже не маленькая, но все же я считаю, что смог донести основную идею и концепцию исходного поста, Introduction to Embedded Linux Security. Я не занимался тупой копи-пастой, материал был не только переведен, а еще существенно изменен и дополнен, там, где требовалось пояснение. Потому что исходный пост рассчитан на западного читателя, специалиста по информационной безопасности.
В итоге: качественный исходный материал + качественная переработка + хорошая адаптация = дала хороший материал, который самому интересно почитать и другим не стыдно показать.
Не всякий текст на английском языке про МК и программирование хорошего качества.
"Linux API гораздо надёжнее и стандартизированнее" - про какой стандарт идет речь? И чем Linux API надежнее? т.е. МК не так надежны как Linux? С точки зрения теории систем, при условие наличие прямых рук, МК будет надежнее любой системы на базе Linux за счет меньшего количества узлов которые могут дать сбой. В ОС всегда больше кода чем в МК.
Кроме того, я воспринимаю Linux как слой HAL. Если на микроконтроллере можно запустить Linux, то мы сможем удобно отображать все эти устройства, нам не придётся пользоваться неуклюжими библиотеками HAL и так далее.
Вот это попробуйте перевести на нормальный человеческий язык.
Об этом и идет речь, что тип устройства необходимо было озвучить в заголовке или как минимум в аннотации. Далее хотя бы немного написать про классы устройств USB, и немного описать тип CDC, вот тогда пост был бы годным. А так +1 в копилку критикам корпоративных блогов, что публикуют материал низкого качества.
Это гарантирует, что наша плата Nucleo будет вести себя с точки зрения хоста как устройство последовательного порта (CDC). Благодаря этому хост сможет настроить подходящие драйверы для работы с нашим собственным устройством.
Ну и какие драйвера нам потребуются для Windows и Linux, какой все же тип устройства был реализован согласно стандарту USB?
Более современная тема - Building a Mini Vegas-Sphere
Без этих драйверов в любом случае выкидывает BSOD. Я интегрировал эти драйвера в образ. Еще раз повторю, "с Fanxiang S500 Pro PCIe 3.0 x4 приводил к BSOD еще на стадии запуска. Со старым диском Samsung SSD удалось запустить, однако при начале работы, при выполнение операций записи, система все равно выкидывала BSOD."
Даже с заменой драйверов stornvme.sys и storarchi.sys заработают только некоторые SSD.
При наличие SPI NOR, просто удобнее, в особенности если вы экспериментируете с двумя разными системами. Один загрузчик можно разместить на SPI NOR, другой на microSD карте. Спасибо за вопрос, @NutsUnderline подробно объяснил.
Просто экономят китайцы, что тут сказать. Мне тоже не нравится отсутствие поддержки PD на SBC.
Что значит допустим? Вы шо Еврей? Материал 500% авторский, мой. Полный список литературы могу отправить. На Хабре публикую сокращенный, потому что до этого модераторы Хабра говорили, что у меня очень много ссылок в посте. Поэтому ссылки на второстепенные источники режу.
Далее, "попробуй использовать Orange PI 5 Plus дальше запуска рабочего стола.". Нужно понимать что это первая водная статья. Тематика аппаратной виртуализации и программирование с использованием NPU, работа UEFI, вам подходит? Так, не все сразу.
Я же написал, предложите свои темы для рассмотрения, не вопрос. Если тема действительно окажется интересной и полезной для аудитории, то от меня благодарность и респект.
Я всегда качаю через VPN, никогда не было проблем. Если есть какие либо проблемы, могу без проблем продублировать на MEGA.NZ, там у меня большой лимит, надеюсь его хватит.
Я так понял у вас в наличие такая же плата Orange PI 5 Plus. Попробуйте вариант Joshua Riek дистрибутива как в этом после.
Кстати, как игрок заметил еще в варианте Joshua Riek небольшой лаг между движением мыши и указателя на экране. Он ничтожный, буквально наверное микросекунды, но он есть. Вначале замечаешь, но потом привыкаешь.
Но самое интересное, этого лага нет на этой же плате в варианте Windows 11. Пока как говорится без комментариев, детально тему не исследовал.
Вы же верно написали) К процессорам десятилетней давности, идет речь про low и middle сегмент по производительности ПК. Ок, говорим про low сегмент. т.е. сейчас ARM можно сказать нацеливается на low сегмент мини-ПК замещения x86 процессоров.
Half-Life 2 до последнего обновления на самом деле неплохо шел. Но после обновления в Steam, прям заметно стал тормозить. Визуально оценивать скорость игры сложно. Хотелось бы видеть в кадре значение fps. Оверлеи в Steam не работают. Сторонние средства, для Intel и NVIDIA игр, для так сказать нашего случая не нашел, может быть в курсе есть ли возможность отобразить fps в играх, раз вы так в этом хорошо разбираетесь?
Версия браузера не указана
Нормальные люди за предъяву "автор не разобрался, как включить аппаратное ускорение графики" после,
Вообще то извиняются, потому что ответь за свой базар не могут. Другое ядро, другой дистрибутив, другая история.
И еще напоминаю в преамбуле написано:
Весь смысл поста в отсутствие как таковых допилок и доделок, т.е. берется как есть. Если вы это не понимаете, то тогда вам к санитарам.
На non-X86 SBC тоже может быть 40-pin GPIO, только есть нюанс. Два варианта рассмотрено в этом посте, текст начинается со слов "Еще один подвох одноплатных компьютеров на x86 процессорах заключается в управление GPIO ..."
Это вы зря "но можно не читать", для понимания ситуации лучше прочитать, но не претендую на истину в последней инстанции. Возможно я недостаточно акцентировал внимание именно на тренде изменений. То что было раньше 10 лет назад и сейчас, это просто день и ночь. За это время много что изменилось. Например, раньше Qualcomm тоже смеялась на MTK, но текущие продажи говорят что это MTK тогда нужно было смеяться.
Суть такова, что китайцы прут как не в себя. Это жесткая экономическая и информационная экспансия. Да, пока есть отставание и софт не допилен, но они однако уже дышат в спину.
И почему мне это интересно, я хочу получить мини-ПК в форм факторе телефона, с экраном и всеми плюшками, который будет в два раза толще обычного, с наличием контактов GPIO для программирования, с UEFI и запуском Android, Linux, Windows. Так сказать начать настоящую эру пост-ПК.
Технически PXE в текущей версии EDKII доступен, но практически не проверял
Кстати, хороший критерий оценки поста вы подали, по наличию комментариев и добавлений в закладки, отличная идея для написания своего расширения браузера.
Вы так и не поняли, про что вам говорят. Автор англоязычного исходного текста недостаточно точно написал, в контексте "wonky HAL libraries", потому что специалист должен выражаться максимально технически грамотно. В противном случае, пусть пишет прозу, там это пожалуйста. Что такое HAL?
Hardware Abstraction Layer (HAL, Слой аппаратных абстракций) — слой абстрагирования, реализованный в программном обеспечении, находящийся между физическим уровнем аппаратного обеспечения и программным обеспечением, запускаемом на этом компьютере. HAL предназначен для скрытия различий в аппаратном обеспечении от основной части ядра операционной системы, таким образом, чтобы большая часть кода, работающая в режиме ядра, не нуждалась в изменении при её запуске на системах с различным аппаратным обеспечением. Источник wiki.
Самое простое понимание, упрощенно, HAL это драйвера, это не какая то отдельная библиотека для всех компьютеров.
Короче говоря, автор не смог написать правильно, и итоге получился проводник который бегал по проводам.
Суть следующая, автор говорит что ему сложно и неудобно работать с уровнем HAL на МК потому что, это достаточно низкий уровень управления устройства. т.е. wonky необходимо понимать в контексте СЛОЖНОСТИ ПРОГРАММИРОВАНИЯ, а не дословного перевода. Необходима высокая техническая база для написания просто элементарного кода.
Далее, следующий проводник бегающий по проводам это "Linux API гораздо надёжнее и стандартизированнее". Никакого абстрактного "стандарта Linux API" в понимание RFC не существует, есть конкретные стандарты, мало того от версии к версии ядра этот API постоянно меняется. Именно поэтому на OPi4LTS в версии ядра Linux 5.10, Wi-Fi на 5 ГГц работает, а в версии 6.X нет. Но тогда про что идет речь? Речь идет о стандарте подхода программирования используя API, это разные вещи. Если смотреть как вы перевели, то API само по себе как субъект не может быть надежным или нет, понятие надежности применимо к работающим информационным системам, но не как API.
В данном случае, автор под понятием "Linux API гораздо надёжнее и стандартизированнее", подразумевает не наличие некого стандарта так такового, а стандарта подхода программирования на примере символьных устройств, например, ваш текст "то мы сможем удобно отображать все эти устройства", как раз таки об этом и говорит. Просто читателю непонятно, где и как отображать эти устройства и вообще про что идет речь.
Программный код написания USB устройств между разными МК крайне сложно перенести. В случае использования Linux API, код можно переносить практически без изменений, потому что есть возможность использовать более высокий уровень абстракции. В своих постах я писал про nanoFramework и microFramework. В частности в microFramework я сделал конвертор USB устройства Microsoft Xbox 360 Controller Gamepad в HID-устройство клавиатура. Это было сделать не сложно, потому что использовался высокий уровень абстракции на базе платформы .NET.
Вот что я хотел до вас донести, в случае "сложных" технических постов делайте техническую экспертизу.
P.S. С литературной точки зрения, вы все равно неправильно перевели "wonky HAL libraries" дословно переводится не как "пользоваться неуклюжими библиотеками HAL", а "шаткие библиотеки HAL". Ключевое слово шаткий, запомните, английский язык это функциональный язык. Шаткий это функция, означающая перемены, изменчивость. На русский язык, так напрямую переводить нельзя, потому что получается хрень.
т.е. автор говорит что в случае использования МК эти библиотеки HAL каждый раз будут другими от перехода от одного МК к другому, этим он и говорит что для него HAL библиотеки и неудобны.
В русском язык слово шаткий, скорее всего читатель воспримет в контексте неустойчивости, что-то не прочное. Например, шаткие доводы, как говорит Толковый словарь Ожегова. Именно поэтому такое нельзя переводить дословно, и как вы перевели. А нужно писать нормальное технические разъяснение.
P.S.S это наверное тот случай, когда в комментариях более понятно, чем в посте.
UEFI уже сейчас неплохо работает. Дополнение к посту P. S. Неожиданные показатели бенчмарка в Windows 11
При всем к вам уважении, ваш ответ эквивалентен выражению из анекдота, "это не дерьмо, а засахарилась". То что вы пишите, это показатель вашего отношения к аудитории, и вашего профессионализма. Говорить "пипл и так схавает", не вызывает никакого уважения. Существует такое понятие как профессиональная этика. Любой нормальный специалист никогда не позволит писать подобную дичь, именно так.
Да все мы люди, и ошибки допускаем. Но писать "неуклюжими библиотеками HAL", технически безграмотно, я не поверю что у вас, как минимум в штате, нет специалистов разбирающихся в архитектуре ОС и Linux. Мое предложение следующее, прежде чем взяться за пост, определяйте его маршрут.
Маршрут №1. Пост пишет автор на тему, в которой сам разбирается и готов как минимум ответить на 80% всех вопросов по данному посту (идеальный вариант).
Маршрут №2. Человек делает предварительную выборку интересных тем для переводов. Затем эта выборка передается специалистам для краткого анализа и исключения полной хрени еще до стадии перевода, помним правило информатики GIGO (Garbage in, garbage out). Далее, перевод желательно человеком, хоть отдаленно понимающий про что идет речь в оригинальном посте. Далее, профильный специалист из результата перевода вычищает дичь в стиле "неуклюжими библиотеками HAL".
PROFIT!
Мне особо и помнить не надо). Напротив меня в книжную полку вставлена книга Стандарты и спецификация USB, толщина заметно больше Библии, скажу более, это одна из самых толстых моих книг. Но это не избавляет, хотя бы кратко технически грамотно описать предмет рассмотрения. Не буду первооткрывателем, тему можно разбить на два поста, первый стандарт и теория, второй практика. И основная моя претензия заключается в низком качестве исходного материала. Автору исходника претензий нет, он так чувствует, имеет на это право, а вот к переводчику есть. У меня есть пост Безопасность встраиваемых систем Linux. Тема безопасности знаете тоже не маленькая, но все же я считаю, что смог донести основную идею и концепцию исходного поста, Introduction to Embedded Linux Security. Я не занимался тупой копи-пастой, материал был не только переведен, а еще существенно изменен и дополнен, там, где требовалось пояснение. Потому что исходный пост рассчитан на западного читателя, специалиста по информационной безопасности.
В итоге: качественный исходный материал + качественная переработка + хорошая адаптация = дала хороший материал, который самому интересно почитать и другим не стыдно показать.
Категорически несогласен. Тут приведу свой комментарий цитату из вашего недавнего поста Создаём своё первое USB-устройство:
Не всякий текст на английском языке про МК и программирование хорошего качества.
"Linux API гораздо надёжнее и стандартизированнее" - про какой стандарт идет речь? И чем Linux API надежнее? т.е. МК не так надежны как Linux? С точки зрения теории систем, при условие наличие прямых рук, МК будет надежнее любой системы на базе Linux за счет меньшего количества узлов которые могут дать сбой. В ОС всегда больше кода чем в МК.
Вот это попробуйте перевести на нормальный человеческий язык.
Об этом и идет речь, что тип устройства необходимо было озвучить в заголовке или как минимум в аннотации. Далее хотя бы немного написать про классы устройств USB, и немного описать тип CDC, вот тогда пост был бы годным. А так +1 в копилку критикам корпоративных блогов, что публикуют материал низкого качества.
Ну и какие драйвера нам потребуются для Windows и Linux, какой все же тип устройства был реализован согласно стандарту USB?