Jump to content

    

alx2

Участник
  • Content Count

    340
  • Joined

  • Last visited

Community Reputation

0 Обычный

About alx2

  • Rank
    Местный
  • Birthday 06/02/1972

Контакты

  • Сайт
    Array

Информация

  • Город
    Array
  1. И правильно делает, что выдает. Смотрите в руководстве, как надо указывать ссылки на файлы в архивах: 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
  2. Ну вот. Оказывается, файл-то не heap_1.o, а ..\obj\heap_1.o! То есть он не в текущем каталоге, а в ../obj. А в скрипте линкера Вы как этот файл указали?
  3. Можете показать фрагмент map-файла, где говорится о загрузке этого файла (когда Вы собираете проект без вынесения его .bss в SDRAM)? В зависимости от того, отдельный ли это файл, или часть библиотели, либо указанием этого файла в командной строке линкера, либо указанием библиотеки через -l... Можете показать команду, которой линкуете проект?
  4. Не понял, зачем Вы это здесь написали... Вам непонятна суть ошибки? Линкер не нашел указанный в скрипте объектный файл. Такой файл вообще в вашем проекте есть?
  5. Наверное что-то типа .bss.sdram : { heap_1.o(.bss) } >SDRAM
  6. Ну тогда либо у Вас в libm нет sinf/cosf (что вряд ли), либо баг линкера.
  7. Кроме libm надо еще libc - там находятся memcpy/memset. Но Вы, похоже, и libm не указали, судя по тому, что линкер не находит powf, sinf и т.п., которые должны там быть... Если я правильно понял, memset требуется, например, функции wave_startrecording(). Смотрите map-файл - там должно быть написано, кто какой символ потребовал.
  8. Видимо, те же символы линкер находил в какой-то еще из используемых Вами библиотек, и код там не очень адекватный... Смотрите map-файл, там много полезной информации о том, откуда что взяли...
  9. Что плохого в самостоятельном строительстве?
  10. Проверьте, какие часовые пояса установлены на ваших двух компьютерах. Неоднократно обнаруживал на компьютерах коллег по работе, что в системе был установлен неверный часовой пояс. Причем пользователь компьютера этого не замечал, так как системное время также было установлено со сдвигом, компенсировавшим разницу часовых поясов.
  11. Покажите полностью команду, которая завершается приведенными Вами выше ошибками. Покажите также (для полноты понимания ситуации) вывод команд: objdump -a <ваша библиотека> | grep syscalls nm <ваша библиотека> | grep _exit Ничего странного в этом нет. Если Вы при линковке, к примеру, сначала укажете библиотеку с файлом syscalls.o, на символы которого ссылок нет, то линкер, естественно, syscalls.o из библиотеки не загрузит. А потом Вы, допустим, укажете фйл, ссылающийся на что-то из syscalls.o - и, естественно, получите ошибку "символ не определен". Точно так же очевидно, что если Вы поменяете местами этот файл с библиотекой, ошибки не будет, так как на момент чтения библиотеки у линкера уже будет неопределенная ссылка, скажем, на тот же _exit, и линкер разрешит ее загрузкой syscalls.o из библиотеки.
  12. Извините, но по-моему у Вас в голове каша. Линковка производится программой 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 $@
  13. Это не о том: NAME ldd - print shared library dependencies OPTIONS --version Print the version number of ldd.
  14. Да, верно. В 2014.10 просто read бэдблоки пропускает. Я использую другую версию, там просто read не пропускает...
  15. Не понял, о каком скрипте Вы говорите. Возможно, Вы не совсем понимаете, как работают менеджеры пакетов. В системе имеется список пакетов, установленных в текущий момент. При необходимости обновиться менеджер пакетов скачивает из репозитория свежий список пакетов и сравнивает с установленными. Если он видит в списке пакет более поздней версии, чем установленный, то новый пакет скачивается и устанавливается. Все это (и многое другое, я тут сильно упростил процесс) выполняет готовый менеджер пакетов, Вам как разработчику об этом заботиться не надо, разве что не забывать менять версию пакета (да и это можно автоматизировать, у меня версии пакетов формируются автоматически из ревизии SVN)... Хм... Да, mdt read нет. Но чем Вас не устраивает mtd verify? Смотрите документацию/код вашего бутлоадера. Вы, кстати, не сказали, каким бутлоадером пользуетесь. Например u-boot может читать как с учетом, так и без учета бэдблоков. В вашем случае, очевидно, бэдблоки надо учитывать, поэтому вместо nand read следует использовать nand read.jffs2 (если у Вас u-boot). То же самое касается nand write. В общем случае - не нормально. Это может быть нормально, если целевой раздел (куда мы копируем) больше размера копируемых данных, и даже при наличии бэдблоков данные в него заведомо влезут. Иначе, если в процессе записи будет пропуск бэдблока, запись "вылезет" за пределы раздела. У Вас здесь, кстати, вообще какая-то путаница с размерами: в первом сообщении Вы пишете, что размер раздела fdt 128k. А теперь Вы пишете в него данные размером 0x40000, то есть 256k! :) Надеюсь, это не ошибка, а Вы просто поменяли разбивку... Это - на Ваш вкус. Лично я именно nandwrite использую для обновления ядра. И еще вопрос - зачем Вы fdt и ядро переписываете дважды (через промежуточные разделы)? С файловой системой понятно - Вы не можете переписать ее пока она смонтирована. Но с fdt и kernel-то какая проблема? Вы не перемудрили ли здесь?