alx2

В корне u-boot'а есть файл README. В нем подробно и пошагово описано, как собрать u-boot.

Вообще-то это пишет не u-boot, а уже сам linux. Смотрите decompress_kernel() в arch/arm/boot/compressed/

Что уже странно, т.к. в Москве часовой пояс GMT+4. :) По поводу же часов могу сказать следующее. Судя по тому, что отображаемое в правом нижнем углу время отличается от реального не на целое число часов (значение минут тоже не совпадает с текущим), я думаю что проичина проблемы в неверном времени на сервере, только и всего.

Как уже неоднократно писалось, "свежаки" - это девелоперские снапшоты. Поэтому то, что они работают неправильно, или не работают вообще - совершенно нормально. Если Вы желаете поучаствовать в разработке компилятора, "свежаки" - для Вас. Тестируйте их и сообщайте об обнаруженных ошибках разработчикам. Если Вы бета-тестингом не увлекаетесь и не горите желанием вылавливать баги компилятора - пользуйтесь релизами, а не "свежаками".

Нет. Компилятор не может знать ревизию исходников, которые он компилирует. И не должен. Для отслеживания версии ПО пользуйтесь системами контроля версий (subversion/git/...), это их работа. Полученную от них версию ПО передавайте компилятору через -DREVISION=xxxxx.

Если она заработает или вообще зальется. Потому что если на плате, например, замыкание проводов на шине данных, выполнять программу она не сможет...

Да не надо уже. :) И так понятно, что у Вас там будет единственное устройство - /dev/fb0

Простите мне мое любопытство, сам я на практике j-link не использовал и, вероятно, чего-то не понимаю. Но вообще-то JTAG штатно предусматривает подключение одного адаптера к нескольким устройствам сразу, в таком случае устройства включаются по цепочке: TDO предыдущего подключается к TDI следующего. Зачем же Вам сразу два адаптера?

Он лежит на файловой системе, образ которой Вы залили из файла rootfs-sama5d3ek.ubi. Почитайте что-нибудь о процессе загрузки sysv-linux. Если кратко, то ядро запускает процесс init, который читает /etc/inittab и выполняет то, что там написано. Обычно это выполнение стартовых скриптов из каталога /etc/rc.x/. Вероятно, один из этих скриптов и запускает Ваш go.sh. Мне не совсем понятен Ваш вопрос. У Вас на плате что, более одного дисплея? :) Что выводит команда ls -l /dev/fb* ? Скорее всего у Вас в системе имеется единственное framebuffer-устройство. А вообще-то надо смотреть документацию на fbdevsink - это gstreamer-плагин, которым у Вас выводится видео...

??? Как это понимать? Супервизор стоит, но при включении ресет не формирует? :) Вы выложили только часть своего творения (функцию main()). А до выполнения main() у Вас, очевидно, выполняется много другого кода (стартап, инициализирующий .data/.bss, стек, возможно, переключающий режимы генераторов и т.п.). Этот код Вы нам не показали. И если, как Вы говорите, программа не стартует при включении питания, вероятно, выполнение до main() и не доходит вовсе, все останавливается где-то в стартапе (а может и вообще не стартует, если ваш супервизор не формирует reset при включении)...

Это нормально для языка C - там допустимо неявное приведение указателя к другому типу указываемого объекта. Поэтому только предупреждение. В языке C++ такое приведение не допускается - будет выдана ошибка.

syslog/syslogd за Вас делают целый ряд вещей: - добавляют к сообщениям дату/время; - добавляют к сообщениям имя хоста, с которого пришло сообщение; - добавляют facility и идентификационную строку отправителя; - добавляют PID процесса; - дублируют сообщения на консоль и в stderr; - фильтруют и раскладывают приходящие сообщения по разным файлам и пересылают их на другие хосты, передают на обработку скриптам и т.п.... Особо продвинутые логгеры имеют много других возможностей (смотрите, например, syslog-ng). У Вас есть выбор - использовать готовое решение или придумать свое собственное. У каждого из этих вариантов есть свои плюсы и минусы. По поводу openlog() - да, Вы можете его не использовать. Но тогда Вы лишаетесь возможности задать для отправляемых сообщений facility, идентификационную строку и опции. И да, ядро тоже пишет свои сообщения в syslog.

А что Вам мешает учесть размер этой секции в выравниваемой величине? Как-то так: . = ALIGN(. + SIZEOF(.ROdata), 0x10000); А это IMHO несколько другая задача - дополнение до конкретного фиксированного размера, а не до размера, кратного заданному значению. Подозреваю, что это выражение приведет к ошибке, если _edata будет больше чем 0x08040000, так как это получится попытка переместить location counter назад...

Не понимаю, какая связь между отладкой и наличием нативного gcc... Я прекрасно отлаживаю в целевом устройстве код, собранный кросс-компилятором на персональном компьютере...

В случае нативной сборки (без кросс-компиляции) такие вещи можно узнать на этапе конфигурации (при выполнении скрипта configure). Например в autoconf есть макрос AC_C_BIGENDIAN, который при обнаружении big-endian хоста генерирует дефайн WORDS_BIGENDIAN. В случае кросс-компиляции, наверное, для каждой target-архитектуры есть набор предопределенных дефайнов (если их не определяет сам компилятор). Можно, наверное, посмотреть, как это сделано, например, в glibc. Сам я специально этим не интересовался. То есть да, какой-то дефайн наверняка все равно где-то есть, но главное, что это проблема библиотеки (и ее авторов), а не программиста, эту библиотеку использующего. Я как пользователь просто пишу в своем коде ntohl(), и могу не задумываться о том, как оно в коде библиотеки устроено, а могу сосредоточиться на своем собственном коде. Конечно, если в библиотеке нет htonl/ntohl - тогда да, придется самому делать соответствующие дефайны и потом заботиться об их переопределении в случае смены целевой архитектуры...

Вы по-моему не понимаете, что имеете дело с двумя разными проблемами: 1. Проблема порядка байт с ловах (Big/Little endianness). Она решается использованием стандартных функций htonl/ntohl/htons/ntohs. 2. Проблема порядка расплоложения битовых полей в структуре/объединении. Она решается отказом от использования битовых полей в данном случае. Я говорил исключительно о второй проблеме. И обратил Ваше внимание на то, что код Flags |= TCP_FLAG_SYN; переносим, а код Flags.SYN = 1; - нет, так как порядок следования битовых полей может быть разным в разных компиляторах. Вот поэтому и надо по возможности использовать htnl/nthl для преборазования из формата слов. Если хост little-endian, эти функции будут менять порядок байт в слове. Если хост big-endian - вернут свой аргумент в неизменном виде. Тогда при смене хоста ничего не навернется...

Что такое "битовый массив"? Что "одно и то же"? Опишите подробнее, что, как Вам кажется, неправильно с приведенным вариантом. Например, если у Вас в переменной Flags лежат флаги TCP, то приведенный Вами код установит флаг SYN. И этот код (в отличие от битовых полей в объединении) уже не зависит от реализации компилятора...

Расположение битовых полей в объединении определяется реализацией компилятора. Вы уверены, что ваш компилятор располагает битовые поля именно в порядке от старшего бита к младшему (как у Вас в закомментаренном фрагменте), а не наоборот (как в раскомментаренном)? И, надеюсь, Вы понимаете, что из-за того что Вы закладываетесь на определенную реализацию компилятора, Ваш код становится непереносимым?

А где вопрос? :) man syslog man syslogd man syslog.conf

Не вижу причин не работать.

Правильно ли я понял, что проблема была в chip_select'е (было 2, а теперь Вы сделали 0)?

А gcc-то об этом и не знает! Почему же Вы конфигурируете с --libdir=/opt/cross/avr/lib, если библиотеки у Вас лежат не в /opt/cross/avr/lib, а в /usr/avr/lib? Вы определитесь с расположением библиотек, и - либо конфигурируйте gcc с --libdir=/usr/avr/lib; - либо устанавливайте библиотеки в /opt/cross/avr/lib; - либо, в крайнем случае (если по каким-то непонятным мне причинам Вы не хотите сообщить gcc реальное расположение библиотек при его конфигурации), указывайте расположение библиотек с помощью -L при линковке...

Стоп. Я, видимо, Вас изначально неправильно понял. Я думал, Вы делаете и хотите использовать свой собственный драйвер (spi1_custom). Но, насколько я вижу, оба имеющиеся у Вас мастера используют omap2_mcspi. Правильно ли я понял, что Вы хотите использовать уже имеющийся omap2_mcspi? Если да, то register_platform_device Вам делать не надо, это уже сделано. Надо только зарегистрировать spi-устройства на шине. Вы так и делаете, но результата нет (в /sys/class/spidev/ должно появиться spidev1.2)... В такой ситуации могу только посоветовать смотреть в spidev_probe() (которая находится в drivers/spi/spidev.c) - именно там регистрируются устройства spidevX.Y. Либо она у Вас вообще по каким-то причинам не выполняется, либо не может создать устройство. Попробуйте понавтыкать туда printk()...

Это не файл с описанием контроллера, это стартап-модуль. В чем Ваш вопрос? Почему не находит? Если да, то скажите, где у Вас лежит этот файл. В /opt/cross/avr/lib/avr5 ?

Хм... А spi_register_board_info() возвращает 0? А метод probe() Вашего драйвера вызывается? Если да, то что возвращает? Хотя, насколько я понимаю, если бы он возвращал ошибку, была бы хоть какая-то ругань в логах... Покажите вывод команды ls -l /sys/class/spi_master Ну и до кучи ls -l /sys/devices/platform И, кстати, почему у Вас в структуре platform_device .id равен -1? Мне казалось, что там должен быть номер шины, то есть в вашем случае 1...