PandaBoard ES на том же SoC'е построен (TI OMAP4460) и стоит он что-то около 190 евро с учётом доставки в Россию. Вот характеристики: pandaboard.org/content/pandaboard-es
Вообще данный процессорный модуль очень смахивает на переразведённый PandaBoard ES
Вообще-то про Xorg речи даже и не шло. Кажется я пытался на нём запустить Xvesa ( www.pps.jussieu.fr/~jch/software/kdrive/ ). Он даже стартовал, но потом сразу вис, за давностью лет уже просто не помню.
Я ставил DeLi Linux на ноутбук Toshiba T3400CT с процессором 486SX 33MHz, 12Mb RAM. Экран с разрешением 640x480 и 256 цветов. С иксами у меня там что-то тогда не срослось, но mc, vi, fpc и gcc работали отлично, а больше и не надо. Работало всё это около 3 часов от родной батареи. И ещё часов 5 от аккумулятора ИБП (12В питание адаптера, так что можно было подключать напрямую). В dualboot-е ещё был DOS с NC и Doom Ultimate (который был благополучно полностью пройден на парах).
> Они выпускают драйвера под Linux, причём достаточно часто выпускают новые версии.
> И, надо сказать, что выпускают драйвера очень качественные и прекрасно работающие.
Вам просто повезло что вы с NVidia Tegra ничего общего не имели. Там драйвера под Linux в состоянии между «ужасно» и «вообще кошмар». Можете на эту тему с товарищем muromec пообщаться, он вам много «хорошего» про NVidia и их поддержку может рассказать.
А помните баг в стабильной ветке драйверов, который намертво вешал X-сервер при изменении размера консоли в KDE?
А про интеграцию я вообще молчу, все нативные конфигурялки определяют частоту развёртки 50 Гц (хотя по факту установлена нормальная рабочая частота для данного монитора).
Я сам давний пользователь карточек NVidia, но что-то в последнее время меня эта компания не радует.
Ну вообще Qt умеет очень неплохо «мимикрировать». Оно умеет выглядеть нативно (ну или почти нативно) как под Windows, так и в GTK-шном окружении. К тому же там вид виджетов может быть изменён до неузнаваемости, при необходимости.
WINE — Wine Is Not Emulator
Wine — это альтернативная реализация Windows API. Она не эмулирует процессор, то бишь wine на ARM-архитектуре вам никаким образом не поможет. Хотя есть «особые» случаи. Например, если доступны исходные коды виндового приложения, можно попробовать собрать его для ARM target-а с помощью winegcc прилинковавшись к libwine. Есть ещё один вариант — запускать wine с помощью qemu с использованием binfmt_misc. Это позволит относительно прозрачно запускать виндовые приложения на ARM, но работать это будет крайне медленно. wiki.winehq.org/ARM
In essence this means that Qt users may create proprietary applications that dynamically link to the LGPL-licensed Qt libraries provided he or she adheres to the requirements of the LGPL.
Таким образом получается что динамическая линковка возможна без каких-либо проблем, но нас интересует статическая. Посему едем дальше…
Открываем статью по LGPL в википедии: en.wikipedia.org/wiki/GNU_Lesser_General_Public_License
Читаем там следующее:
Alternatively, a statically linked library is allowed if either source code or linkable object files are provided.
You can thus distribute object files (and protect your source code)
and still comply with the requirements of the LGPL.
However, others (in particular, Richard Stallman) does not necessarily
interpret the LGPL in this way.
То бишь можно обойтись предоставлением уже скомпилированных объектников, но РМС это не одобряет (ну он и библиотеки призывает под чистой GPL распространять). Так что используйте, по возможности, динамическую линковку.
Смотрел я вот этот коммит: github.com/Ezekeel/GLaDOS-nexus-s/commit/0ad0e3261895844e9d7983c3332ec23b6d039978
Раскручивать изменения следует от файла drivers/misc/deep_idle.c, как раз там экспортятся sysfs атрибуты, через которые всё это включается. А далее смотрим кто использует функцию deepidle_is_enabled, думаю дальше разберётесь и всё сами увидите.
99$, ну что ж… Будем для простоты считать это около трёх тысяч рублей.
Например, за 4 т.р. уже можно взять такую плату: starterkit.ru/html/index.php?name=shop&op=view&id=48
А там уже 64 Mb DDR2 памяти, 256 Mb NAND-а, Ethernet 10/100 Mb ну и т.д. К тому же куча периферии (SD/MMC, USB, RS232) уже разведена, не нужно никаких дополнительных модулей на шлейфах. И для неё уже есть собранный и работающий образ с Linux.
Ну если нужно, то можно даже дешевле найти, вот за 2,5 т.р.: starterkit.ru/html/index.php?name=shop&op=view&id=23
Это плата на AT91SAM9260. Также работает на 200 МГц, как и плата в топике (автор почему-то опустил фразу «currently running at 200Mhz» из описания: www.ghielectronics.com/catalog/product/328 ), но имеет уже 32 Мб SDRAM-а и Ethernet. И да, тоже с уже распаянной периферией. А на внешнюю SD карту никто не запрещает поставить полноценный Debian.
Дешевле? Да. Памяти больше, модулей дополнительных не нужно.
Конкретно в данном случае, изменения внесены непосредственно в низкоуровневую часть ядра, которая всегда в него жёстко «вкомпиливается». Так что да, нужно перепрошивать телефон.
В случаях, когда нужную функциональность удаётся добавить с помощью модуля ядра, при использовании рутованного телефона перепрошивка является не обязательной, можно просто подгрузить новый модуль с помощью insmod/modprobe.
вот только это устройство nexus s. И софтовая часть за гуглом. Самсунг им присылает хардварные ревизии
Нет, нет и ещё раз нет.
1. S5PV210 — это application процессор, применяемый не только в Nexus S. Он может применяться ещё в миллионе различных железок, посему Nexus S в данном случае лишь частный случай.
2. Низкоуровневая софтовая часть за тем, кто точно знает как эта железка устроена. В данном случае это Samsung, что подтверждают копирайты в коде:
3. Google ожидает получить _готовый_ BSP Задача Google в данном случае, сводится к допиливанию именно пользовательского функционала, но никак не кода для работы с железом.
И для тех, кому было интересно, можно ли этот патч адаптировать для смартфонов на других процессорах, поясню: нет, нельзя. Данный патч специфичен для SoC Samsung S5PV210. Это значит что данный патч будет работать не только на Nexus S, но и на любой другой железке, построенной на том же процессоре.
Вы вообще в код смотрели?
Там куча платформо-зависимых изменений, тут Google вообще не при делах, такими вещами должен заниматься _производитель_. Модуль, добавляющий режим DEEP IDLE сводится к добавлению следующих атрибутов в sysfs: enabled, idle_stats, reset_stats и version.
Интересует нас только первый пункт, остальное это отображение статистики по времени, которое было проведено в idle, сброс этой статистики и версия модуля соответственно.
А вот запись единицы в файл атрибута enabled (echo «1» > enabled) как раз и врубает наш deep idle, фактически просто выставляя значение переменной deepidle_enabled. Модуль экспортит функцию bool deepidle_is_enabled(void) для получения значения этого флага. В зависимости от значения этого флага при попытке перехода системы в idle при определённых условиях может быть активирована функция s5p_enter_didle(true), которая является абсолютно _аппаратно-специфичной_. Она уже порождает выполнение кучи низкоуровневого кода.
К чему вся эта басня? А к тому, что это именно производитель конкретного железа не озаботился о данной проблеме.
>… чтобы приложение оказалось правильно написанным и работало на различных линуксах зачастую потребует большего времени…
Да, потребует. Только это требуется пройти всего один раз, после этого приходит понимание как можно делать, а как нельзя. К тому же, почти любой разработчик, который работает над созданием открытого проекта имел дело как минимум с двумя или тремя дистрами. Таким образом, он представляет чем отличаются дистрибьютивы друг от друга. По непонятным мне причинам, среди людей бытует мнение, что различные дистрибьютивы плохо совместимы друг с другом. Ну я вам так скажу, дома у меня ArchLinux с KDE, на сервере стабильная ветка Debian'а, на работе стоит Ubuntu 11.10 с Unity (всего три дня назад, до того как обновился, там был Gnome), а на нетбуке у меня тот же ArchLinux, только с LXDE. И знаете, мне всё равно с использованием какой библиотеки рисуется интерфейс и какой DE используется, мне важно что один и тот же софт работает _везде_. Я на всех перечисленных дистрах умудрялся запускать такого проприетарного монстра как Cadence IC (который сертифицирован только на использование с RHEL), или Quartus II. И они работают.
Различия между дистрами носят чисто косметический характер, и сводятся они к различным пакетным менеджерам и системам инициализации. Набор базовх библиотек везде один и тот же.
Каких граблей я в своё время только не насобирал делая маленький проектик для PIC-а. И проблемы с документацией к компилятору, и не очевидное поведение компилятора, даже аппаратные баги.
По каким-то неведомым причинам решили всё это писать с использованием компилятора C18. Так вот, очень часто встречалось, что пример из документации отказывался работать. При ближайшем рассмотрении кода примера выяснилось, что там проверяется условие, которое всегда ложно.
Или вот ещё, использовался PIC18F4431, там 8 каналов PWM, я использовал из них только 4, а оставшиеся пины хотел использовать как GPIO. Так эти пины во время работы PWM-а нельзя было установить в единицу. Пришлось лепить костыль: поставить подтяжки к питанию и дёргать TRIS-ы. Настраиваешь пин как вход — у тебя на выходе единица за счёт подтяжки, настраиваешь как выход — нуль. Мы долго смотрели в даташит, но нигде описания подобного поведения не обнаружили. Уж не знаю, может плохо смотрели.
> Я уже молчу про то, что deb/rpm никак не встанут на Gentoo или Slackware.
Это не совсем верно. Мне приходилось «ставить» rpm на Slackware, ничего такого в этом нет. Понятное дело, что приходится ручками перепаковывать пакет и внимательно смотреть в установочные скрипты, но сделать таки можно. Для тех же Debian/Ubuntu есть alien. Да, это всё, что называется, «костыли», но всё же. А в той же Gentoo для тех кто «в теме» написать ebuild, который правильно перепакует какой-либо проприетарный пакет из rpm вообще не проблема.
В любом случае, правильно написанное приложение будет работать на любом дистре без каких-либо проблем. С проприетарными приложениями чуть сложнее. Но тут спасает старинный принцип, очень часто применяемый в Windows, «всё своё носи с собой». Тащим с собой нужные библиотеки, переопределяем в запускном скрипте LD_LIBRARY_PATH и работаем себе спокойно.
Вообще данный процессорный модуль очень смахивает на переразведённый PandaBoard ES
> И, надо сказать, что выпускают драйвера очень качественные и прекрасно работающие.
Вам просто повезло что вы с NVidia Tegra ничего общего не имели. Там драйвера под Linux в состоянии между «ужасно» и «вообще кошмар». Можете на эту тему с товарищем muromec пообщаться, он вам много «хорошего» про NVidia и их поддержку может рассказать.
А помните баг в стабильной ветке драйверов, который намертво вешал X-сервер при изменении размера консоли в KDE?
А про интеграцию я вообще молчу, все нативные конфигурялки определяют частоту развёртки 50 Гц (хотя по факту установлена нормальная рабочая частота для данного монитора).
Я сам давний пользователь карточек NVidia, но что-то в последнее время меня эта компания не радует.
Wine — это альтернативная реализация Windows API. Она не эмулирует процессор, то бишь wine на ARM-архитектуре вам никаким образом не поможет. Хотя есть «особые» случаи. Например, если доступны исходные коды виндового приложения, можно попробовать собрать его для ARM target-а с помощью winegcc прилинковавшись к libwine. Есть ещё один вариант — запускать wine с помощью qemu с использованием binfmt_misc. Это позволит относительно прозрачно запускать виндовые приложения на ARM, но работать это будет крайне медленно.
wiki.winehq.org/ARM
И там же можно найти FAQ по лицензиям и использованию LGPL в частности: qt.nokia.com/about/licensing/frequently-asked-questions#what-is-the-lgpl
Таким образом получается что динамическая линковка возможна без каких-либо проблем, но нас интересует статическая. Посему едем дальше…
Открываем статью по LGPL в википедии: en.wikipedia.org/wiki/GNU_Lesser_General_Public_License
Читаем там следующее:
А вот что говорит другой источник answers.google.com/answers/threadview/id/439136.html:
То бишь можно обойтись предоставлением уже скомпилированных объектников, но РМС это не одобряет (ну он и библиотеки призывает под чистой GPL распространять). Так что используйте, по возможности, динамическую линковку.
Раскручивать изменения следует от файла drivers/misc/deep_idle.c, как раз там экспортятся sysfs атрибуты, через которые всё это включается. А далее смотрим кто использует функцию deepidle_is_enabled, думаю дальше разберётесь и всё сами увидите.
Сразу же узнал =)
Например, за 4 т.р. уже можно взять такую плату: starterkit.ru/html/index.php?name=shop&op=view&id=48
А там уже 64 Mb DDR2 памяти, 256 Mb NAND-а, Ethernet 10/100 Mb ну и т.д. К тому же куча периферии (SD/MMC, USB, RS232) уже разведена, не нужно никаких дополнительных модулей на шлейфах. И для неё уже есть собранный и работающий образ с Linux.
Ну если нужно, то можно даже дешевле найти, вот за 2,5 т.р.: starterkit.ru/html/index.php?name=shop&op=view&id=23
Это плата на AT91SAM9260. Также работает на 200 МГц, как и плата в топике (автор почему-то опустил фразу «currently running at 200Mhz» из описания: www.ghielectronics.com/catalog/product/328 ), но имеет уже 32 Мб SDRAM-а и Ethernet. И да, тоже с уже распаянной периферией. А на внешнюю SD карту никто не запрещает поставить полноценный Debian.
Дешевле? Да. Памяти больше, модулей дополнительных не нужно.
Может поможет. А так, могу только посочувствовать.
В случаях, когда нужную функциональность удаётся добавить с помощью модуля ядра, при использовании рутованного телефона перепрошивка является не обязательной, можно просто подгрузить новый модуль с помощью insmod/modprobe.
Нет, нет и ещё раз нет.
1. S5PV210 — это application процессор, применяемый не только в Nexus S. Он может применяться ещё в миллионе различных железок, посему Nexus S в данном случае лишь частный случай.
2. Низкоуровневая софтовая часть за тем, кто точно знает как эта железка устроена. В данном случае это Samsung, что подтверждают копирайты в коде:
3. Google ожидает получить _готовый_ BSP Задача Google в данном случае, сводится к допиливанию именно пользовательского функционала, но никак не кода для работы с железом.
Там куча платформо-зависимых изменений, тут Google вообще не при делах, такими вещами должен заниматься _производитель_. Модуль, добавляющий режим DEEP IDLE сводится к добавлению следующих атрибутов в sysfs: enabled, idle_stats, reset_stats и version.
Интересует нас только первый пункт, остальное это отображение статистики по времени, которое было проведено в idle, сброс этой статистики и версия модуля соответственно.
А вот запись единицы в файл атрибута enabled (echo «1» > enabled) как раз и врубает наш deep idle, фактически просто выставляя значение переменной deepidle_enabled. Модуль экспортит функцию bool deepidle_is_enabled(void) для получения значения этого флага. В зависимости от значения этого флага при попытке перехода системы в idle при определённых условиях может быть активирована функция s5p_enter_didle(true), которая является абсолютно _аппаратно-специфичной_. Она уже порождает выполнение кучи низкоуровневого кода.
К чему вся эта басня? А к тому, что это именно производитель конкретного железа не озаботился о данной проблеме.
Да, потребует. Только это требуется пройти всего один раз, после этого приходит понимание как можно делать, а как нельзя. К тому же, почти любой разработчик, который работает над созданием открытого проекта имел дело как минимум с двумя или тремя дистрами. Таким образом, он представляет чем отличаются дистрибьютивы друг от друга. По непонятным мне причинам, среди людей бытует мнение, что различные дистрибьютивы плохо совместимы друг с другом. Ну я вам так скажу, дома у меня ArchLinux с KDE, на сервере стабильная ветка Debian'а, на работе стоит Ubuntu 11.10 с Unity (всего три дня назад, до того как обновился, там был Gnome), а на нетбуке у меня тот же ArchLinux, только с LXDE. И знаете, мне всё равно с использованием какой библиотеки рисуется интерфейс и какой DE используется, мне важно что один и тот же софт работает _везде_. Я на всех перечисленных дистрах умудрялся запускать такого проприетарного монстра как Cadence IC (который сертифицирован только на использование с RHEL), или Quartus II. И они работают.
Различия между дистрами носят чисто косметический характер, и сводятся они к различным пакетным менеджерам и системам инициализации. Набор базовх библиотек везде один и тот же.
По каким-то неведомым причинам решили всё это писать с использованием компилятора C18. Так вот, очень часто встречалось, что пример из документации отказывался работать. При ближайшем рассмотрении кода примера выяснилось, что там проверяется условие, которое всегда ложно.
Или вот ещё, использовался PIC18F4431, там 8 каналов PWM, я использовал из них только 4, а оставшиеся пины хотел использовать как GPIO. Так эти пины во время работы PWM-а нельзя было установить в единицу. Пришлось лепить костыль: поставить подтяжки к питанию и дёргать TRIS-ы. Настраиваешь пин как вход — у тебя на выходе единица за счёт подтяжки, настраиваешь как выход — нуль. Мы долго смотрели в даташит, но нигде описания подобного поведения не обнаружили. Уж не знаю, может плохо смотрели.
Это не совсем верно. Мне приходилось «ставить» rpm на Slackware, ничего такого в этом нет. Понятное дело, что приходится ручками перепаковывать пакет и внимательно смотреть в установочные скрипты, но сделать таки можно. Для тех же Debian/Ubuntu есть alien. Да, это всё, что называется, «костыли», но всё же. А в той же Gentoo для тех кто «в теме» написать ebuild, который правильно перепакует какой-либо проприетарный пакет из rpm вообще не проблема.
В любом случае, правильно написанное приложение будет работать на любом дистре без каких-либо проблем. С проприетарными приложениями чуть сложнее. Но тут спасает старинный принцип, очень часто применяемый в Windows, «всё своё носи с собой». Тащим с собой нужные библиотеки, переопределяем в запускном скрипте LD_LIBRARY_PATH и работаем себе спокойно.