Сборка buildroot-а

сам gcc.hash на месте?

ну и учти, если у тебя на девайсе ubifs — у неё сложные отношения с симлинками, почитай http://lists.busybox.net/pipermail/buildroot/2018-November/236309.html

извиняюсь за глупый вопрос: gcc.hash - это что, библиотека или что?

прочитай тред по ссылке, там написано что это, где и что в нем должно храниться

симлинки на gcc6 есть…

привет

нет ли некоторого издевательства в том, что ты здороваешься с перечеркнутым ником?

итого файл gcc-initial.hash присутствует. данные в нем есть ссылка gcc.hash присутствует

покажи выхлоп

ls -la /home/user/buildroot/package/gcc

file /home/user/buildroot/package/gcc/gcc-initial/gcc-initial.hash 

cat /home/user/buildroot/package/gcc/gcc-initial/gcc-initial.hash 

root@debian-buildroot:/# ls -la /home/user/buildroot/package/gcc total 120 drwxr-xr-x 10 root root 4096 Feb 11 14:18 . drwxr-xr-x 1755 root root 53248 Feb 11 14:18 .. drwxr-xr-x 2 root root 4096 Feb 11 14:18 4.8.5 drwxr-xr-x 2 root root 4096 Feb 11 14:18 4.9.4 drwxr-xr-x 2 root root 4096 Feb 11 14:18 5.4.0 drwxr-xr-x 2 root root 4096 Feb 11 14:18 6.3.0 drwxr-xr-x 2 root root 4096 Feb 11 14:18 arc-2016.09-release -rwxrwx--- 1 root root 5972 Sep 24 2017 Config.in.host drwxr-xr-x 2 root root 4096 Feb 11 14:18 gcc-final -rwxrwx--- 1 root root 1730 Sep 24 2017 gcc.hash drwxr-xr-x 2 root root 4096 Feb 11 14:25 gcc-initial -rwxrwx--- 1 root root 12572 Sep 24 2017 gcc.mk drwxr-xr-x 2 root root 4096 Feb 11 14:18 musl-5.4.0

root@debian-buildroot:/# file /home/user/buildroot/package/gcc/gcc-initial/gcc-initial.hash /home/user/buildroot/package/gcc/gcc-initial/gcc-initial.hash: symbolic link to /home/user/buildroot/package/gcc/gcc.hash

root@debian-buildroot:/# cat /home/user/buildroot/package/gcc/gcc-initial/gcc-initial.hash # From ftp://gcc.gnu.org/pub/gcc/releases/gcc-4.5.4/sha512.sum sha512 78696b287d46aacd6f150920da376ea32f58ad9f0dafd2d3b7fa6dbdd8dd7afe659108d1dfaa5807617fc5248719f50b39c37ade0173ea5b9fec2091f4656115 gcc-4.5.4.tar.bz2 # From ftp://gcc.gnu.org/pub/gcc/releases/gcc-4.7.4/sha512.sum sha512 dfcb737073191e628231031a3571ec77ee760a59377630f4a6e4fdfa66f9ddad39fde47e3f0f227eb43cdf90e0d34cde5abdc9ac892c1e111a911062a66c9189 gcc-4.7.4.tar.bz2 # From ftp://gcc.gnu.org/pub/gcc/releases/gcc-4.8.5/sha512.sum sha512 47fdfeca0c0a624cdec9c4ae47137d056c918d5c386d4b96985bb3c8172aba377cb66cbcc30e80832fd244a7d98f562c20198056915c70cfef0977545073a8ea gcc-4.8.5.tar.bz2 # From ftp://gcc.gnu.org/pub/gcc/releases/gcc-4.9.4/sha512.sum sha512 93abb78e16277454f41a8e9810f41f66c0fdffdc539a762ff6b67d3037f78db971378683fd2ebf707d1d51c059fad2161fe42d110c330027f40214b7db0f3efe gcc-4.9.4.tar.bz2 # From ftp://gcc.gnu.org/pub/gcc/releases/gcc-5.4.0/sha512.sum sha512 2941cc950c8f2409a314df497631f9b0266211aa74746c1839c46e04f1c7c299afe2528d1ef16ea39def408a644ba48f97519ec7a7dd37d260c3e9423514265b gcc-5.4.0.tar.bz2 # From ftp://gcc.gnu.org/pub/gcc/releases/gcc-6.3.0/sha512.sum sha512 234dd9b1bdc9a9c6e352216a7ef4ccadc6c07f156006a59759c5e0e6a69f0abcdc14630eff11e3826dd6ba5933a8faa43043f3d1d62df6bd5ab1e82862f9bf78 gcc-6.3.0.tar.bz2

# Locally calculated (fetched from Github) sha512 faae6dc3f7843412068a52de5919797cd23e6ed1b8d140c230d0381f13fd38af67baaa4a09e581c03602127da3dd2fab6f9f5d7ac5d4270585bd079c673dda9a gcc-arc-2016.09-release.tar.gz # Locally calculated (fetched from Github) sha512 841101f7de45f327bf2e92f3efc73ca88a021e4b9b541458ce80a16e55882bd8606a8492d75c57c589ee2c10d42ae2865b67690155d7289a541df1d68096402f gcc-musl-5.4.0.tar.gz

ok, а теперь покажи

find /home/user/buildroot/dl/gcc/ -print0 | xargs -0 sha512sum

и зачем тебе такой древний gcc, покажи-ка

cat /home/user/buildroot/.config | grep GCC | grep -v '#' 

find /home/user/buildroot/dl/gcc/ -print0 | xargs -0 sha512sum find: ‘/home/user/buildroot/dl/gcc/’: No such file or directory cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e -

cat /home/user/buildroot/.config | grep GCC | grep -v ‘#’ BR2_HOST_GCC_AT_LEAST_4_5=y BR2_HOST_GCC_AT_LEAST_4_6=y BR2_HOST_GCC_AT_LEAST_4_7=y BR2_HOST_GCC_AT_LEAST_4_8=y BR2_HOST_GCC_AT_LEAST_4_9=y BR2_HOST_GCC_AT_LEAST_5=y BR2_HOST_GCC_AT_LEAST_6=y BR2_GCC_TARGET_ABI=«aapcs-linux» BR2_GCC_TARGET_CPU=«cortex-a7» BR2_GCC_TARGET_FPU=«vfpv4-d16» BR2_GCC_TARGET_FLOAT_ABI=«hard» BR2_GCC_TARGET_MODE=«arm» BR2_GCC_VERSION_6_X=y BR2_GCC_ARCH_HAS_CONFIGURABLE_DEFAULTS=y BR2_GCC_SUPPORTS_FINEGRAINEDMTUNE=y BR2_GCC_VERSION=«6.3.0» BR2_EXTRA_GCC_CONFIG_OPTIONS="" BR2_TOOLCHAIN_GCC_AT_LEAST_4_3=y BR2_TOOLCHAIN_GCC_AT_LEAST_4_4=y BR2_TOOLCHAIN_GCC_AT_LEAST_4_5=y BR2_TOOLCHAIN_GCC_AT_LEAST_4_6=y BR2_TOOLCHAIN_GCC_AT_LEAST_4_7=y BR2_TOOLCHAIN_GCC_AT_LEAST_4_8=y BR2_TOOLCHAIN_GCC_AT_LEAST_4_9=y BR2_TOOLCHAIN_GCC_AT_LEAST_5=y BR2_TOOLCHAIN_GCC_AT_LEAST_6=y BR2_TOOLCHAIN_GCC_AT_LEAST=«6»

но вообще для сборки используется следующая конфигурация

BR2_arm=y BR2_cortex_a7=y BR2_OPTIMIZE_2=y BR2_SSP_STRONG=y BR2_TOOLCHAIN_BUILDROOT_GLIBC=y BR2_KERNEL_HEADERS_4_9=y BR2_GLIBC_VERSION_2_24=y BR2_BINUTILS_VERSION_2_27_X=y BR2_GCC_VERSION_6_X=y BR2_TOOLCHAIN_BUILDROOT_CXX=y BR2_TARGET_GENERIC_ROOT_PASSWD=«root» BR2_TARGET_GENERIC_GETTY_PORT=«ttymxc0» BR2_TARGET_GENERIC_GETTY_BAUDRATE_115200=y BR2_ROOTFS_OVERLAY=«$(TOPDIR)/rootfs» BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_GIT=y BR2_LINUX_KERNEL_CUSTOM_REPO_URL=«git://git.freescale.com/imx/linux-imx.git» BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION=«imx-rel_imx_4.9.x_1.0.0_ga» BR2_LINUX_KERNEL_PATCH=«$(TOPDIR)/patches/linux» BR2_LINUX_KERNEL_DEFCONFIG=«imx_v7» BR2_LINUX_KERNEL_DTS_SUPPORT=y BR2_LINUX_KERNEL_INTREE_DTS_NAME=«imx6ull-14x14-nano» BR2_PACKAGE_BUSYBOX_SHOW_OTHERS=y BR2_PACKAGE_DOSFSTOOLS=y BR2_PACKAGE_DOSFSTOOLS_FSCK_FAT=y BR2_PACKAGE_E2TOOLS=y BR2_PACKAGE_MINICOM=y BR2_PACKAGE_DHCPCD=y BR2_PACKAGE_ETHTOOL=y BR2_TARGET_ROOTFS_CPIO=y BR2_TARGET_ROOTFS_CPIO_GZIP=y BR2_TARGET_ROOTFS_CPIO_UIMAGE=y BR2_TARGET_UBOOT=y BR2_TARGET_UBOOT_BOARDNAME=«mx6ull_14x14_evk» BR2_TARGET_UBOOT_CUSTOM_GIT=y BR2_TARGET_UBOOT_CUSTOM_REPO_URL=«git://git.freescale.com/imx/uboot-imx.git " BR2_TARGET_UBOOT_CUSTOM_REPO_VERSION=«imx-rel_imx_4.9.x_1.0.0_ga» BR2_TARGET_UBOOT_PATCH=»$(TOPDIR)/patches/uboot"

во-первых, прочитай о форматировании на форуме

во-вторых, особой разницы нет, и там и там древнее говно древнего говна. свежий билдрут такое не соберет, вечером могу поиграться со старыми версиями. какой именно «архив с билдрутом на всякий случай с https://buildroot.org/download.html» ты скачал?

почитаю

buildroot-2017.02.6.tar.gz

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

а попробуй-ка для начала проверить права на hash

у тебя

-rwxrwx--- 1 root root 1730 Sep 24 2017 gcc.hash

в дистрибутиве

-rw-rw-r-- 1 user user 1730 Sep 24 2017 gcc.hash

ты, конечно, запускаешь от рута (что само по себе нехорошо), поэтому не факт, что причина в этом, но как минимум разберись, кто тебе покоцал права на файлы

Buildroot может только под малинку собрать. Посмотри кто спонсирует этот буилдрут и ты все поймешь.

Всё собралось.

В итоге оказались каким-то странным образом битые линки gcc-initial и gcc-final

Хотя сам линукс говорил, что они в порядке

Пересоздал их и ОК.

Есть ещё вопрос. Может доводилось работать с утилитой MfgTools ? С ней какие-то странности.

Мы раньше стандартным образом всё грузили с прибор с СД-карты. Но это вечный геморой с передачей этих карточек с их недолговечностью при частом использовании и т.д. и тп

Решиди делать заливку с помощью утилиты. И попалди в ситуацию, когда то же самое, что записывается с СД карты и работает, записанное через утилиту начинает работать криво. В частности подвисает интерфейс Can

Всё один в один. И zImage и загрузчик (хотя он тут причем?) и rootfs.

C сд залитое - Can работает, через утилиту - не хочет.

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

В чем может быть дело?

конкретно MfgTools не пользовался, у нас самописные тулы для этого. создай отдельную тему с правильными тегами (arm, nxp, mfgtools а не всякие нерелевантные kernel debian), c логами зависаний can (syslog, что там еще), с описанием fs на девайсе — может кто поможет

пальцем в небо могу предположить неудаленные ошметки старых файлов, поэтому можешь сразу посмотреть du/df — нет ли разницы в случае полного затирания флешки (если я правильно понял, что значит «всё грузили с прибор с СД-карты») и в случае заливания утилитой

Ясно, спасибо. Вообще перед заливкой я насильственно забиваю нулями внутреннюю еmmc прибора через команду dd.