Intel предлагает использовать Yocto для всех своих embedded-проектов, процесс его поддержки отлажен, и а пользователю не мешают устанавливать нужные ему «нормальные» дистрибутивы, было бы желание. Просто над Yocto у Intel контроля больше, чем над, скажем, Debian, вот и все.
Я, кстати, очень рад, что эту платформу выпустили на урезаном Atom, а не на разогнанном Quark — у Atom'ов все в порядке и с многопоточностью и с совместимостью с x86, а то на нынешних Quark'ах без патчей компилятора или собранных бинарей большая часть приложений просто сегфолтится при попытке исполнить код с префиксом lock, и сделать с этим Intel пока ничего не может, а без этого установка Debian на Galileo превращается в прогулку по граблям, ибо внезапное обновление патченного eglibc может сломать половину системы.
Более того, этот же вендор потом решает, собирать и выкладывать остальные пакеты, которые есть у него в BSP (чтобы потом можно было доустановить их через opkg install xxx), или нет. И если вдруг решил не выкладывать ни исходники BSP, ни пакеты для обновления — собранный образ yocto получается ничем не лучше какой-нибудь пропретарной прошивки для SOHO-роутера.
Yocto, как говорят сами авторы проекта, is not an embedded Linux distribution – it creates a custom one for you.
Пока не кину, прошу искреннего пардону. Если WR не выложили, значит описание пока еще под NDA.
Зато могу расказать, как там это практически бесполезное ядро Quark на 100 Мгц оказалось внутри SoC — у нормальных Atom на нем выполянется Trusted Execution Engine, который является аналогом Management Engine с уменьшенной функциональностью и использует ядро Quark и неизвестную мне ОС (бьюсь об заклад, что это WR VxWorks), в то время как ME использует лицензированное у Synopsys ядро ARC4 и работает под управлением ThreadX RTOS. В результате для Edison процессор почикали, и ядро Quark осталось без работы, и ее теперь нужно срочно придумать, для чего спешно пилится «ViperOS», о которой потому никаких сведений в открытом доступе и нет.
А теперь все тоже самое, только на этот раз точнее:
1. Никаких вариантов нет, плата выпущена на обрезанном SoC с кодовым именем «Tangier», который является обрезанным Atom Z34xx, у котороего есть основной 2х -ядерный CPU Atom (Silvermont) @ 500 Мгц и «пока еще неиспользуемое» ядро Quark @ 100 Мгц (которое, добавлю, в необрезанных процессорах используется под TXT).
2. Неизвестная RTOS — это ViperOS, обезанная VxWorks от Wind River.
Чаще всего контролер GPIO находится на шине APB, которая тактуется у разных SoC по разному, но высоких частот там обычно нет, максимум — 66 или 100 Мгц, конкретно для GPIO больше 50 Мгц я не видел нигде, кроме дорогих FPGA.
На работы мы, благодаря приверженности решениям, «прошедшим проверку временем», до сих пользуемся PVCS, древнее которой только мамонты (первый релиз был в 1985 году, на год раньше CVS). Используется система потому, что она одновременно и простая в обслуживании, и тесно интегрирована с IDE (AMI Visual eBIOS 4). Как только AMI наконец добавят интеграцию с Git в VeB 5 — тут же на него и перейдем, но и выбросить PVCS не получится, пока последний проект на базе Aptio 4 не получит статус EOL, т.е. еще минимум лет 5-7. Вот такой вот энтерпрайз, позавчерашние технологии уже сегодня.
КОГДА МЕНЮ ОРЕТ НА ПОЛЬЗОВАТЕЛЯ — ЭТО ВЫГЛЯДИТ УЖАСНО.
Прошу прощения за повышение шрифта на ни в чем не повинного читателя, просто продемонстрировал, насколько оно «неплохо».
Нужны не obj-файлы билиотеки, а obj-файлы, собранные из вашего проприетарного кода, чтобы можно было собрать себе версию вашего приложения со своей версией библиотеки.
LGPL не требует выкладывания исходников слинкованного статически кода, зато требует предоставления пользователю возможности самостоятельной линковки со статическими библиотеками под LGPL. Распространяйте в архиве с приложением ваши obj-файлы и краткий readme по самостоятельной линковке (необязательно, но большой плюс в карму) и лицензия вам не страшна.
Добавлю еще, что согласно вот этому документу, продукт получил статус «obsolete» ранее 21 июля 2009 года (дата последней модификации документа, надпись «Obsolote Product(s)» присутствует на каждой странице), а сайт st.com с 2011 года уже несколько раз обновлялся практически полностью (можно сравнить снапшоты Internet Wayback Macnine), поэтому не удивительно, что информация о давно устаревших продуктах на новых версиях сайта отсутствует.
Оценивайте, ваше право никто не отнимает.
Сайт ST, скорее всего, ведется автоматизированной системой Product Lifecycle Management, и когда устаревшие продукты переезжают в архив, вся информация о них удаляется с сайта автоматически.
Я не говорю, что это хорошо, лишь пытаюсь сказать, что претензии такого рода, по моему мнению, не обоснованны.
Давайте по пунктам:
1. «Информация о старых микросхемах выпилена». 2 года после EOL — достаточный срок для ее выпиливания, никто не обещал поддерживать продукты вечно.
2. «Вся серия DSM брошена, на замену ничего не предполагается». Серия, судя по тому же документу, продавалась плохо. Какой смысл ее продолжать, если даже затраты на НИОКР могут не окупиться?
3. «Служба поддержки молчит». Договор о технической поддержке у вас с ST заключен? Если нет, то рассчитывать на моментальный ответ бесплатной технической поддержки для всех — неразумно.
Поймите, ST — это не богадельня, а коммерческая компания, которая работает ради прибыли и стремится снижать издержки. И если завтра серия STM32 станет вдруг убыточной — выкинут и её, вместе с сайтом, документацией и ответами на вопросы к тех. поддержке.
Внезапно нагуглился вот такой документ, в котором написано, что поставки микросхем этой серии полностью прерваны в 2012 году вследствие низких продаж.
Не нужно обвинять ST в том, что они вас не проинформировали, т.к. судя по этому же документу, информация о прекращении поставок была доведена до клиентов еще 25 ноября 2010 года, а сам документ от 12 января того же года.
Проворонили слегка, вот и все.
При складывании размер листа не меняется, меняется только форма. Поэтому сколько лист размером 297х210 мм2 не складывай — он так и останется листом А4.
Не понимаю смысла такого стола, т.к. за возможность один раз отрегулировать как надо и забыть (а основная часть пользователей сделает именно так) предлагается заплатить какие-то кошмарные деньги, получив в итоге фактически парту с максимальной нагрузкой на столешницу в 70 кг (т.е на этот стол даже сесть можно далеко не всем).
Подозреваю, что за те же деньги можно заказать себе идеальный стол под себя у любого толкового мебельщика, такой, что он будет стоять сто лет и выдержит любые удары судьбы.
Напряжения задаются как раз правильные, т.е. те, которые Intel рекомендует для этой модели процессора. Другой вопрос, что большая часть экземпляров этой модели способна работать на более низком напряжении при сохранении как частоты, так и стабильности на этой частоте, чем автор и воспользовался. На деле на методы и таблицы ACPI сильно полагается только OSX, так как на ПК в них море ошибок и современные OS научились эти ошибки обходить. Получается замкнутый круг, когда разработчики БИОСов не исправляют баги в таблицах потому, что все и так работает, а разработчики ОС встраивают свои костыли для их обхода. Более того, большинство разработчиков БИОСов, которые закупают код платформы у AMI, Phoenix или Insyde (а это вообще все производители ПК, кроме Intel и Microsoft) в 90% AML-кода даже не заглядывали никогда, т.к. он пришел непосредственно от вендора. Описанные в статье методы и таблицы, к примеру, являются частью CPU Support Package и пока они кое-как работают — никто туда не полезет, ибо есть миллион более важных мест, в которых надо исправлять баги прямо сейчас.
Потому что это своя версия БИОСа на каждый выпущенный экземпляр и куча далеко не бесплатного времени отдела тестирования. Рассматривайте эту возможность в том же ключе, что и возможность разгона, т.к. вы используете процессор в нестандартных для него условиях (в какую строну отклонение от стандарта — другой вопрос).
На самом деле, можно переписать метод _PSS так, чтобы он брал значения VID для каждого P-state не из кода, а из NVRAM, а туда их писать при помощи BIOS Setup, тогда можно отдать тонкую настройку на откуп пользователю. Не делают так потому, что это почти никому не нужно и это снова дополнительное время и деньги на реализацию и поддержку.
Автор понижает не частоту, а напряжение на каждом P-состоянии, которое по умолчанию задрано настолько, чтобы работали даже самы неудачные экземпляры процессоров. В итоге получается снижение тепловыделения и увеличение времени работы от батареи конкретного экземпляра ценой пары часов поиска стабильных VID'ов и последующего изменения DSDT. Минус тут только один — на каждом ноутбуке нужно будет подбирать свои оптимальные значения VID.
Добавлю к этой статье предупреждение: запись в NVRAM из ОС — достаточно опасная операция, которая может приводить к «кирпичу» на некоторых моделях ноутбуков с BIOSами на платформе Phoenix SCT. У автора BIOS на платформа AMI Aptio, и с ним таких проблем нет.
Именно поэтому я настоятельно не рекомендую использовать на ноутбуках как саму efibootmgr, так и все, что ее вызывает, и устанавливать любые загрузчики вручную, либо заменяя имеющийся загрузчик по умолчанию (fs0:/EFI/BOOT/bootx64.efi), либо прописывая новый загрузчик из UEFI Shell командой bсfg boot add 0 fs0:/path/to/bootloader.efi «My Fancy Bootloader» — это намного безопаснее.
EFI умеет грузиться с чего угодно, если для этого чего-угодно создан Device Path. Если производитель материнской платы нужный драйвер в firmware положил — можно смело грузиться хоть с RAID, хоть с USB, хоть с LAN, хоть с COM-порта.
Стандарт говорит о том, что в любой реализации UEFI должен быть драйвер FAT, и что с раздела с вышеприведеннным GUID будет осуществлена автоматическая загрузка, если таковой будет найден, но ESP от этого не становится обязательным. Другой вопрос, что и производители не торопятся добавлять в firmware драйверы всего подряд, и я их прекрасно понимаю.
Я, кстати, очень рад, что эту платформу выпустили на урезаном Atom, а не на разогнанном Quark — у Atom'ов все в порядке и с многопоточностью и с совместимостью с x86, а то на нынешних Quark'ах без патчей компилятора или собранных бинарей большая часть приложений просто сегфолтится при попытке исполнить код с префиксом lock, и сделать с этим Intel пока ничего не может, а без этого установка Debian на Galileo превращается в прогулку по граблям, ибо внезапное обновление патченного eglibc может сломать половину системы.
Yocto, как говорят сами авторы проекта, is not an embedded Linux distribution – it creates a custom one for you.
Зато могу расказать, как там это практически бесполезное ядро Quark на 100 Мгц оказалось внутри SoC — у нормальных Atom на нем выполянется Trusted Execution Engine, который является аналогом Management Engine с уменьшенной функциональностью и использует ядро Quark и неизвестную мне ОС (бьюсь об заклад, что это WR VxWorks), в то время как ME использует лицензированное у Synopsys ядро ARC4 и работает под управлением ThreadX RTOS. В результате для Edison процессор почикали, и ядро Quark осталось без работы, и ее теперь нужно срочно придумать, для чего спешно пилится «ViperOS», о которой потому никаких сведений в открытом доступе и нет.
1. Никаких вариантов нет, плата выпущена на обрезанном SoC с кодовым именем «Tangier», который является обрезанным Atom Z34xx, у котороего есть основной 2х -ядерный CPU Atom (Silvermont) @ 500 Мгц и «пока еще неиспользуемое» ядро Quark @ 100 Мгц (которое, добавлю, в необрезанных процессорах используется под TXT).
2. Неизвестная RTOS — это ViperOS, обезанная VxWorks от Wind River.
Прошу прощения за повышение шрифта на ни в чем не повинного читателя, просто продемонстрировал, насколько оно «неплохо».
Сайт ST, скорее всего, ведется автоматизированной системой Product Lifecycle Management, и когда устаревшие продукты переезжают в архив, вся информация о них удаляется с сайта автоматически.
Я не говорю, что это хорошо, лишь пытаюсь сказать, что претензии такого рода, по моему мнению, не обоснованны.
1. «Информация о старых микросхемах выпилена». 2 года после EOL — достаточный срок для ее выпиливания, никто не обещал поддерживать продукты вечно.
2. «Вся серия DSM брошена, на замену ничего не предполагается». Серия, судя по тому же документу, продавалась плохо. Какой смысл ее продолжать, если даже затраты на НИОКР могут не окупиться?
3. «Служба поддержки молчит». Договор о технической поддержке у вас с ST заключен? Если нет, то рассчитывать на моментальный ответ бесплатной технической поддержки для всех — неразумно.
Поймите, ST — это не богадельня, а коммерческая компания, которая работает ради прибыли и стремится снижать издержки. И если завтра серия STM32 станет вдруг убыточной — выкинут и её, вместе с сайтом, документацией и ответами на вопросы к тех. поддержке.
Не нужно обвинять ST в том, что они вас не проинформировали, т.к. судя по этому же документу, информация о прекращении поставок была доведена до клиентов еще 25 ноября 2010 года, а сам документ от 12 января того же года.
Проворонили слегка, вот и все.
Подозреваю, что за те же деньги можно заказать себе идеальный стол под себя у любого толкового мебельщика, такой, что он будет стоять сто лет и выдержит любые удары судьбы.
На самом деле, можно переписать метод _PSS так, чтобы он брал значения VID для каждого P-state не из кода, а из NVRAM, а туда их писать при помощи BIOS Setup, тогда можно отдать тонкую настройку на откуп пользователю. Не делают так потому, что это почти никому не нужно и это снова дополнительное время и деньги на реализацию и поддержку.
Именно поэтому я настоятельно не рекомендую использовать на ноутбуках как саму efibootmgr, так и все, что ее вызывает, и устанавливать любые загрузчики вручную, либо заменяя имеющийся загрузчик по умолчанию (fs0:/EFI/BOOT/bootx64.efi), либо прописывая новый загрузчик из UEFI Shell командой bсfg boot add 0 fs0:/path/to/bootloader.efi «My Fancy Bootloader» — это намного безопаснее.
Стандарт говорит о том, что в любой реализации UEFI должен быть драйвер FAT, и что с раздела с вышеприведеннным GUID будет осуществлена автоматическая загрузка, если таковой будет найден, но ESP от этого не становится обязательным. Другой вопрос, что и производители не торопятся добавлять в firmware драйверы всего подряд, и я их прекрасно понимаю.