alx2

И правильно делает, что выдает. Смотрите в руководстве, как надо указывать ссылки на файлы в архивах: You can also specify files within archives by writing a pattern matching the archive, a colon, then the pattern matching the file, with no whitespace around the colon. `archive:file' matches file within archive `archive:' matches the whole archive `:file' matches file but not one in an archive

Ну вот. Оказывается, файл-то не heap_1.o, а ..\obj\heap_1.o! То есть он не в текущем каталоге, а в ../obj. А в скрипте линкера Вы как этот файл указали?

Можете показать фрагмент map-файла, где говорится о загрузке этого файла (когда Вы собираете проект без вынесения его .bss в SDRAM)? В зависимости от того, отдельный ли это файл, или часть библиотели, либо указанием этого файла в командной строке линкера, либо указанием библиотеки через -l... Можете показать команду, которой линкуете проект?

Не понял, зачем Вы это здесь написали... Вам непонятна суть ошибки? Линкер не нашел указанный в скрипте объектный файл. Такой файл вообще в вашем проекте есть?

Наверное что-то типа .bss.sdram : { heap_1.o(.bss) } >SDRAM

Ну тогда либо у Вас в libm нет sinf/cosf (что вряд ли), либо баг линкера.

Кроме libm надо еще libc - там находятся memcpy/memset. Но Вы, похоже, и libm не указали, судя по тому, что линкер не находит powf, sinf и т.п., которые должны там быть... Если я правильно понял, memset требуется, например, функции wave_startrecording(). Смотрите map-файл - там должно быть написано, кто какой символ потребовал.

Видимо, те же символы линкер находил в какой-то еще из используемых Вами библиотек, и код там не очень адекватный... Смотрите map-файл, там много полезной информации о том, откуда что взяли...

Что плохого в самостоятельном строительстве?

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

Покажите полностью команду, которая завершается приведенными Вами выше ошибками. Покажите также (для полноты понимания ситуации) вывод команд: objdump -a <ваша библиотека> | grep syscalls nm <ваша библиотека> | grep _exit Ничего странного в этом нет. Если Вы при линковке, к примеру, сначала укажете библиотеку с файлом syscalls.o, на символы которого ссылок нет, то линкер, естественно, syscalls.o из библиотеки не загрузит. А потом Вы, допустим, укажете фйл, ссылающийся на что-то из syscalls.o - и, естественно, получите ошибку "символ не определен". Точно так же очевидно, что если Вы поменяете местами этот файл с библиотекой, ошибки не будет, так как на момент чтения библиотеки у линкера уже будет неопределенная ссылка, скажем, на тот же _exit, и линкер разрешит ее загрузкой syscalls.o из библиотеки.

Извините, но по-моему у Вас в голове каша. Линковка производится программой ld, так как именно это и есть линкер. Программа ar - это архиватор, который объединяет объектные файлы в архив (библиотеку). Программа же gcc - это просто враппер, который сам по себе никакой обработки компонентов программы не выполняет, а вызывает для этого другое программы - препроцессор, компилятор, ассемблер, линкер. Каким именно операции будут выполнены, зависит от параметров командной строки. Думаю, Вам стоит разобраться, из каких этапов (операций) состоит процесс сборки программы, что для каждого этапа является входными данными, а что - результатом. И сам вопрос ваш, действительно, непонятен. Если Вы знаете и как получить библиотеку, и как получить hex-файл, какая проблема выполнить и то, и другое? Указать кому/чему? make'у? Написать в Makefile что-то типа: liba.a: file1.o file2.o file3.o arm-none-eabi-gcc-ar cq $@ $^ arm-none-eabi-gcc-ranlib $@

Это не о том: NAME ldd - print shared library dependencies OPTIONS --version Print the version number of ldd.

Да, верно. В 2014.10 просто read бэдблоки пропускает. Я использую другую версию, там просто read не пропускает...

Не понял, о каком скрипте Вы говорите. Возможно, Вы не совсем понимаете, как работают менеджеры пакетов. В системе имеется список пакетов, установленных в текущий момент. При необходимости обновиться менеджер пакетов скачивает из репозитория свежий список пакетов и сравнивает с установленными. Если он видит в списке пакет более поздней версии, чем установленный, то новый пакет скачивается и устанавливается. Все это (и многое другое, я тут сильно упростил процесс) выполняет готовый менеджер пакетов, Вам как разработчику об этом заботиться не надо, разве что не забывать менять версию пакета (да и это можно автоматизировать, у меня версии пакетов формируются автоматически из ревизии SVN)... Хм... Да, mdt read нет. Но чем Вас не устраивает mtd verify? Смотрите документацию/код вашего бутлоадера. Вы, кстати, не сказали, каким бутлоадером пользуетесь. Например u-boot может читать как с учетом, так и без учета бэдблоков. В вашем случае, очевидно, бэдблоки надо учитывать, поэтому вместо nand read следует использовать nand read.jffs2 (если у Вас u-boot). То же самое касается nand write. В общем случае - не нормально. Это может быть нормально, если целевой раздел (куда мы копируем) больше размера копируемых данных, и даже при наличии бэдблоков данные в него заведомо влезут. Иначе, если в процессе записи будет пропуск бэдблока, запись "вылезет" за пределы раздела. У Вас здесь, кстати, вообще какая-то путаница с размерами: в первом сообщении Вы пишете, что размер раздела fdt 128k. А теперь Вы пишете в него данные размером 0x40000, то есть 256k! :) Надеюсь, это не ошибка, а Вы просто поменяли разбивку... Это - на Ваш вкус. Лично я именно nandwrite использую для обновления ядра. И еще вопрос - зачем Вы fdt и ядро переписываете дважды (через промежуточные разделы)? С файловой системой понятно - Вы не можете переписать ее пока она смонтирована. Но с fdt и kernel-то какая проблема? Вы не перемудрили ли здесь?

Поскольку никто Вам не отвечает, решил вставить реплику. Сразу скажу, что ответов на ваши конкретные вопросы у меня нет. Но есть другая мысль. Насколько я понял (после гугленья sysupgrade), Вы планируете делать апгрейд следующим образом: нужные файлы (например конфиги) сохраняются на другой FS, корневая FS полностью стирается и переписывается новым образом, после чего сохраненные файлы возвращаются на место. Суть моей реплики - нафига Вам переписывать всю файловую систему целиком? Почему бы не воспользоваться системой пакетов и каким-либо пакетным менеджером? Описанной проблемы тогда у Вас не будет в принципе, в процессе обновления будут переписываться только реально обновляемые файлы... Может Вы и ответа не получаете именно потому, что выбранным Вами путем мало кто идет? Еще несколько преимуществ использования пакетов: - Не надо заново выкачивать и перезаписывать образ всей файловой системы ради крошечного обновления (к примеру, чтобы обновить SSL-сертификат), достаточно одного малюсенького пакетика. - Перерыв в работе системы отсутствует совсем или минимален - после обновления требуется перезапуск только реально обновившихся компонентов. - Гибкость - на разных системах может быть разный набор пакетов.

А кто (какой код) в ядре будет обрабатывать этот ioctl запрос, если ни одного драйвера i2c не загружено? Да, я говорил о драйвере шины. Метценгерштейн упоминал, что там на шине есть звуковая карта. Я что-то сомневаюсь, что обмен со звуковой картой происходит через программный i2c. :) Наверняка там аппаратный контроллер... Метценгерштейн, думаю, пора уточнить, как у Вас подключена шина к контроллеру (есть ли аппаратный i2c), какие драйвера используются, что Вы запрашиваете через ioctl и какую ошибку ioctl возвращает. Без конкретики мы тут можем только гадать, и вряд ли чем-то сможем Вам помочь...

Что-то я не понял Вашу мысль... Если не загружено ни одного драйвера, использующего нашу шину, каким образом пользовательская программа сможет обратиться к устройству на этой шине??? Вот, например, у меня в устройстве в ядре присутствует один из драйверов из drivers/i2c/busses/. Пользовательские программы с его помощью (используя ioctl) обращаются к устройствам на шине. Если на момент обращения шина свободна, выполняется запрошенная операция. Если же на момент обращения шина занята (на шине присутствует другой мастер, который в данный момент выполняет операцию), наше устройство будет ждать освобождения шины, после чего начнет выполнять запрошенную операцию. Если другой мастер в этот момент захочет выполнить новую операцию, он будет ждать, когда завершится наша. Таким образом, несколько мастер-устройств вполне могут совместно использовать одну и ту же шину. И только в случае, если один из мастеров занял шину и не освобождает длительное время (например читает одной операцией большой объем данных или вообще завис), другой мастер получить доступ к шине не сможет. В этом случае ioctl вернет ошибку (timeout). Вот как-то так... Кстати, удерживать шину в занятом состоянии может и slave-устройство... Не понял... ioctl при попытке записи возвращает -1? Что при этом в errno?

Documentation/i2c/dev-interface Мультимастер? Не имеет значения, какие устройства физически есть на шине. Имеет значение, занята шина какой-то операцией в данный конкретный момент или нет. Шину i2c в любой момент времени может использовать только один мастер. Естественно, что если шина уже занята каким-то мастером, то другой мастер в это время работать с шиной не может. Он должен ждать освобождения шины.

Спасибо за ссылку. Возможная причина "умирания" FS понятна. Но, на мой взгляд, это особенность конкретной реализации, а не уязвимость журналирования как такового. Как мне кажется, ключевым моментом является то, что в рассмотренном примере при восстановлении после отказа питания решение о валидности записанных данных (или о чистоте стираемого блока) принимается на основании тестового чтения, а не на основании информации журнала. Насколько я понимаю принцип работы журналирования (безотновительно UBIFS или какой-либо другой конкретной FS), при операции, допустим, стирания блока: 1. в журнал записывается информация о планируемой операции; 2. выполняется собственно стирание; 3. после успешного завершения операции запись в журнале уничтожается, а блок считается чистым. Если в процессе выполнения п.2 отключилось питание, то при последующем старте файловая система читает журнал, видит, что операция стирания не была успешно завершена, и трактует блок как "грязный" (то есть требующий повторного стирания). Что читается из "грязного" блока, есть там нестабильные биты или нет, по идее, никого интересовать не должно... Аналогично для случая программирования страницы - если операция программирования не была успешно завершена, страница трактуется файловой системой как "грязная", то есть не содержащая полезных данных... Так что говорить "журнал - не панацея" без привязки к конкретной реализации я бы не стал... Интересно, применяется ли аналогичный подход (принятие решения о валидности данных на основании контрольного чтения) в jffs2...

shamrel в-основном уже ответил(а), а я дополню, что номер gpio, которому соответствует ваш пин, может быть разным в разных версиях линукса. Я наступил на эти грабли, когда после апгрейда линукса устройство перестало работать - оказалось, что вся нумерация сдвинулась на 32. Сейчас в программе стоит проверка версии ядра. Как Вам вариант сделать это в инит-скрипте? Пропишите там echo 96 >/sys/clagg/gpio/export ... и т.д. ... и будет ваш пин экспортироваться и настраиваться сразу при старте вашего устройства... Про прерывание я не понял. Что за прерывание может быть от сигнала включения питания USB, если это выход, и ваша программа сама выдает в него сигналы? Какого рода события на этом пине Вы ожидаете? И уж если Вы непременно хотите, чтобы при старте линукса пин сразу оказывался доступен без каких-либо дополнительных действий, что мешает объявить его как LED и работать с ним через /sys/class/leds, раз уж Вы говорите, что

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

Если под начальными настройками подразумевается возврат всей системы в исходное состояние, в котором оно было выпущено с завода, то напрашивается вариант хранить rootfs дважды: первая копия записывается на заводе и никогда не модифицируется, вторая копия - рабочая. Для возврата к начальным настройкам вторая копия переписывается первой.

Не совсем понятно, о языке для реализации серверной или клиентской стороны Вы спрашиваете. Если вопрос о том, на чем сделать HTTP-сервер для вашего встроенного приложения, то я рекомендую использовать libmicrohttpd (https://www.gnu.org/software/libmicrohttpd/). Соответственно, язык - C/C++. Документирована библиотека хорошо, разобраться нетрудно. Если же вопрос о собственно пользовательском интерфейсе (то что будет выполняться в веб-браузере пользователя), то это html/javascript. Причем, наверное, проще всего будет сразу начинать использовать jQuery (https://jquery.com/).

В общих чертах такие: 1. wget https://cdn.kernel.org/pub/linux/kernel/v3....x-3.16.7.tar.xz 2. tar xJf linux-3.16.7.tar.xz 3. cd linux-3.16.7 4. make menuconfig ... конфигурируем по потребностям... 5. make dep CC=arm-linux-gnueabi-gcc LD=arm-linux-gnueabi-ld AR=arm-linux-gnueabi-ar NM=arm-linux-gnueabi-nm OBJCOPY=arm-linux-gnueabi-objcopy 6. make zImage CC=arm-linux-gnueabi-gcc LD=arm-linux-gnueabi-ld AR=arm-linux-gnueabi-ar NM=arm-linux-gnueabi-nm OBJCOPY=arm-linux-gnueabi-objcopy 6. make modules CC=arm-linux-gnueabi-gcc LD=arm-linux-gnueabi-ld AR=arm-linux-gnueabi-ar NM=arm-linux-gnueabi-nm OBJCOPY=arm-linux-gnueabi-objcopy