**** BEGIN LOGGING AT Wed Mar 25 02:59:57 2020 Mar 25 20:12:02 just wondering, should cross compiling with autotools work for baremetal stuff or is that a bad idea? Mar 25 20:12:20 sorry for the offtopic :> Mar 25 20:12:44 assuming you have the baremetal configured properly -- it works fine.. (at least for newlib and libgloss) Mar 25 20:14:00 hmm. I can't get pass "c compiler cant create executables" so I am clearly doing something wrong then Mar 25 20:14:21 are you using newlib/libgloss or something as as your compiler's C library? Mar 25 20:14:42 easiest thing to do though is look at the config.log file, and see what the actual C compiler error was.. it may be obvious from there Mar 25 20:15:02 (NOT the temp/log.do_configure, but the actualy config.log from the build directory) Mar 25 20:15:25 well, I did look at that and its complaining about undefined reference to _exit Mar 25 20:15:46 as for newlib: I am trying out the arm-none-eabi compiler that comes on fedora, it does use newlib Mar 25 20:15:47 depending on the newlib configuration, libgloss and/or the linker script provides the _exit Mar 25 20:16:11 the newlib (and libgloss) combo built in can generate a working baremetal for arm Mar 25 20:16:29 but it's definitely more configure heavy then other parts.. :P Mar 25 20:17:13 so what do you pass to configure? do you have a line that you use for me to compare? Mar 25 20:17:34 I am trying to build for cortex m4 btw Mar 25 20:17:39 sec Mar 25 20:18:22 What I'm passing: Mar 25 20:18:23 TCLIBC = "newlib" Mar 25 20:18:23 TCLIBCAPPEND ="" Mar 25 20:18:30 LIBC_DEPENDENCIES_append = " newlib-staticdev libgloss-staticdev" Mar 25 20:18:42 DISTRO_FEATURES_BACKFILL_xilinx-standalone = "" Mar 25 20:18:43 VIRTUAL-RUNTIME_init_manager_xilinx-standalone = "" Mar 25 20:18:43 PREFERRED_PROVIDER_virtual/kernel = "linux-dummy" Mar 25 20:18:57 TOOLCHAIN_NEED_CONFIGSITE_CACHE = "" Mar 25 20:19:03 thats the distro file Mar 25 20:19:20 wait, you're building baremetal stuff with yocto? wow, I did not know that was possible Mar 25 20:19:32 for cortex r5 (similar to m) should be something like this: Mar 25 20:19:43 (tune file) Mar 25 20:19:44 require conf/machine/include/arm/arch-armv8a.inc Mar 25 20:19:50 TUNEVALID[armrm] = "Enable ARM Cortex-R/M Family" Mar 25 20:19:50 MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armrm', 'armrm:', '' ,d)}" Mar 25 20:19:57 TUNEVALID[cortexr5] = "Enable Cortex-r5 specific processor optimizations" Mar 25 20:19:57 TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexr5', ' -mcpu=cortex-r5', '', d)}" Mar 25 20:19:57 AVAILTUNES += "cortexr5" Mar 25 20:19:57 ARMPKGARCH_tune-cortexr5 = "cortexr5" Mar 25 20:20:02 TUNE_FEATURES_tune-cortexr5 = "armrm cortexr5" Mar 25 20:20:02 PACKAGE_EXTRA_ARCHS_tune-cortexr5 = "${TUNE_PKGARCH}" Mar 25 20:20:02 AVAILTUNES += "cortexr5f" Mar 25 20:20:02 ARMPKGARCH_tune-cortexr5f = "cortexr5f" Mar 25 20:20:11 TUNE_FEATURES_tune-cortexr5f = "armrm cortexr5 vfpv3d16 callconvention-hard" Mar 25 20:20:11 PACKAGE_EXTRA_ARCHS_tune-cortexr5f = "${TUNE_PKGARCH}" Mar 25 20:20:20 You should be able to add a similar entry for cortex m Mar 25 20:20:42 well, actually that is a bit too far in the sense that I am trying to set up an autotools based project for some M4 code that I have here Mar 25 20:20:52 I also have defined a bare bones 'machine' called cortexr5-generic that includes the tune and sets the defaulttune to cortexr5f Mar 25 20:20:58 so you are already several steps ahead :) Mar 25 20:21:17 could you please paste me the beginning of your log.do_configure where it passes all the parameters to the configure script? Mar 25 20:21:18 You can use the Yocto Project to build the newlib and the toolchain (meta-toolchain build)... that is where we started Mar 25 20:21:26 the distro/machine/tune are still needed for that Mar 25 20:21:37 this is actaully pretty cool Mar 25 20:21:39 let me see, I may not have a recent build Mar 25 20:22:54 newlib-3.1.0/configure --build=x86_64-linux --target=aarch64-xilinx-elf --host=aarch64-xilinx-elf --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --libdir=/usr/lib --includedir=/usr/include --enable-languages=c --with-newlib --with-gnu-as --with-gnu-ld --disable-multilib Mar 25 20:23:10 ewlib-io-c99-formats --enable-newlib-io-long-long --enable-newlib-io-float --enable-newlib-io-long-double --disable-newlib-supplied-syscalls Mar 25 20:23:47 (the reason I'm doing this is you can, with a multiconfig build, build both the Linxu side and any baremetal stuff.. cortexr5 or other controllers for firmware you may have in a single build.. we're still very much prototyping that, but expect to start using it within a year Mar 25 20:23:51 but whats the use case of building a "distro" for baremetal? mostly in the meta-toolchain, i.e. building a toolchain for baremetal, right? because if I understasnd correctly - you can only have exactly one binary loaded there and thats it? Mar 25 20:24:12 two use-cases.. first is simply to build the toolchain.. that is the most immediate.. Mar 25 20:24:19 I thought you could build that in a single build already? Mar 25 20:24:30 well, by having a recipe that downloads the toolchain Mar 25 20:24:35 and then setting CC in the recipe Mar 25 20:24:37 but I guess thats hacky Mar 25 20:24:40 the second is for use to built either cortex r5 and microblaze control software.. so it can be included as firmware Mar 25 20:24:47 aha Mar 25 20:24:49 exactly.. we want to get rid of the hacky Mar 25 20:24:55 nice! Mar 25 20:25:12 IMHO, eventually u-boot, and other baremetal stuff should be built using this apporch and NOT hacky build scripts in the linux side of the cross build.. Mar 25 20:25:17 thanks for the paste, let me see if I find out what I am missing compared to yours, actually I am trying it by hand in the console now Mar 25 20:25:27 (eventually may be a while in the furture to be honest) Mar 25 20:26:22 I've completely replaced the ARM and Linaro supplied toolchains at this point with Yocto Project derived toolchains.. lets us have a single common source code base for all of the supported target architectures (not just arm) Mar 25 20:26:39 that'd be super cool Mar 25 20:26:43 (At Xilinx we have arm, arm64 and microblaze we have to support.. both baremetal and linux) Mar 25 20:28:00 does make sense to get rid of the "hacky" indeed then... Mar 25 20:28:16 I generally am always cautions towards anything that comes in as "precompiled binaries" Mar 25 20:28:21 *cautious Mar 25 20:28:49 same.. thus the move to YP derived.. I can do a custom build and product the necessary baremetal or target (linux) toolchains... Mar 25 20:29:05 the other tricky bit, is I had an ask to duplicate the insanity that is the ARM baremetal toolchain.. Mar 25 20:30:13 that meant enabling the -21- ARM multilibs in a single configuration Mar 25 20:30:33 the system takes about 10 minuts just to parse so it can build and construct meta-toolchain target Mar 25 20:30:51 doing it the crosstool-ng way would have been faster, but then it's "yet another tool to support" Mar 25 20:30:53 heh Mar 25 20:33:22 if I look at newlibs configure.ac I think I know why mine won't work... tons of special stuff in there Mar 25 20:33:45 I guess autoconf does not support baremetal "out of the box" unless I am not seeing something obvious Mar 25 20:33:51 newlib, like glibc, does a LOT of stuff to setup expecting a mostly not working compilier Mar 25 20:34:15 hm Mar 25 20:34:31 well in theory just passing --build and --host should be enough Mar 25 20:35:03 but that does not work for me Mar 25 21:19:21 fray: -nostdlib in CFLAGS made the configure.ac to actually not do the compiler test **** ENDING LOGGING AT Thu Mar 26 03:04:25 2020