**** BEGIN LOGGING AT Sat May 18 03:00:11 2019 May 18 03:48:10 Hi guys! Just a little update regards my yesterday problems (cross compile simple kernel module against old 4.1.15 headers for BBB) May 18 03:48:28 Using the linaro 4.9 gcc toolchain as suggested by zmatt and LetoThe2nd I have been able to CC a linux 4.1 TI kernel, so the toolchain problem have been solved. May 18 03:48:55 Later, I tried to CC my kernel module against the 4.1.15 headers, which as stated in (https://www.kernel.org/doc/Documentation/kbuild/modules.txt) should have been a simple operation, but guess what? it was not. May 18 03:49:16 I had many errors like: May 18 03:49:19 I didn't "suggest" it, I merely observed that that was the toolchain that rcn's script would automatically download (for that kernel) May 18 03:49:47 and since I have full priviledges on the disk partition I am working on, May 18 03:50:05 it was clear that the problem was something else May 18 03:50:15 many error like... what? May 18 03:50:20 In fact, the recordmcount whom sh was complaining about is compiled for ARM architecture May 18 03:50:37 many errors like /bin/sh: ./scripts/recordmcount: Permission denied May 18 03:52:36 Then, using the same kernel config retrieved from the BBB, I CCed the Linux 4.1 TI kernel, moved its scripts/ folder (which contained x86 binaries) to the 4.1.15 headers folder May 18 03:52:57 uhh what? May 18 03:53:03 and finally I was able to CC out-of-tree kernel modules against the 4.1.15 headers I found on BBB. May 18 03:53:09 ???? May 18 03:53:12 everything seems really ODD May 18 03:53:50 yes, including what you're describing. why would you still use the headers from the BBB when you have a complete kernel directory on your (intel) build machine May 18 03:54:05 zmatt: Sorry, I wrote "suggested" as a direct translation from my mother tongue May 18 03:55:12 and the executables in scripts/ should be compiled for the architecture of your build machine, not the target, so I have no idea how you'd manage to get an ARM executable there May 18 03:55:21 ok, saying that I want the kernel module to be compatible with a particular kernel version, shouldn't I use those headers instead of the ones on my machine? May 18 03:56:17 you're right, I think that the scripts folder on the BBB was alread populated with ARM binaries, I'll check this in the next minutes May 18 03:56:53 but you specifically produced the kernel tree on your intel machine to match your intended kernel, right? May 18 03:57:08 correct May 18 03:57:49 i.e. you should have a correct kernel tree to build your kernel module against May 18 03:58:21 don't start also somehow involving files from the bbb, it sounds like you're just making a weird mess May 18 03:59:10 my thinking process was "I can't CC my kernel module using the kernel headers I found on the BBB, so I'll try to download the sources of the (almost) same version, try to CC the kernel module against them and check if it is ok on the BBB" May 18 03:59:24 yes May 18 04:00:17 so why were you mentioning a headers folder? May 18 04:00:45 its ok to make a weird mess beacuse I am still learning May 18 04:02:09 the entire process should take place on your intel build machine and shouldn't really require anything besides your kernel tree (in the KERNEL directory after running rcn's build script) and your kernel module May 18 04:02:13 I mentioned the headers folder because (erroneously?) thinking that I needed the exact same kernel version May 18 04:02:32 and since I coulnd't find it on any repo, eneded up using the files on the BBB May 18 04:04:07 you may need the exact right version yes, although I'm not 100% sure about that. but I thought you already concluded the headers package on the bbb didn't work for you? May 18 04:04:42 correct, at this point this is my conclusion May 18 04:04:51 if you don't want to use the latest 4.1-ti-rt kernel you just built, then switch to the tag for the exact kernel you do want to build for May 18 04:05:26 (just in case also toss the KERNEL directory to make sure it's cleanly rebuilt) May 18 04:05:31 unfortunately I can't find 4.1.15-ti-rt-r43 May 18 04:06:14 I can May 18 04:06:52 https://pastebin.com/rgSp2Wby it's right there May 18 04:07:17 all kernels released by rcn as debian packages should have a corresponding git tag May 18 04:08:15 well, shame for me for not being able to find this. May 18 11:49:06 zmatt: just to point out why I usually try to avoid using scripts May 18 11:50:07 cloning the RNS ti-linux-kernel-dev repo, switching to 4.1.15-ti-rt-r43 branch May 18 11:50:49 either the build_deb.sh and build_kernel.sh scripts fail for different reasons: in a new ubuntu machine (18.04.2) May 18 11:51:15 with the error: Unrecognized deb based system May 18 11:51:46 on an Archlinux machine (I know, not supported) with error: pathspec 'master' did not match any file(s) known to git May 18 11:52:33 in both cases system.sh was present and customized as needed May 18 18:16:39 zero_notezero_note if you are still around, the solution to that is to use "yakbuild" https://github.com/RobertCNelson/yakbuild Remember, 18.04 didn't exist in 4.1.15... May 19 00:16:31 the scripts have always worked fine for me, but I'll admit I've never felt the urge to rebuild ancient kernels :P May 19 00:16:52 rcn-ee[m]: why is that a problem anyway, and how is yakbuild different? May 19 02:06:44 zmatt: when a user check's out an old git commit, the host checker built-into the repo, is only good for the date of the tag.. Where as the yakbuild scripts just has the host side of stuff, and uses git to pull to clone the old tag.. May 19 02:07:36 ahh, it's just about host system compatiility May 19 02:07:52 *compatibility May 19 02:11:22 it basically figures out what you need installed, there's some pre multi-arch, pre ia32-libs, etc.. In the end everything is either a Debian or Ubuntu clone, but there are a few odd cases. May 19 02:12:47 now that all Linaro/ARM tools are built for 64bit, it's not as bad, as getting the correct 32bit libs on different versions of ubuntu/debian thru pre mult-arch era made things fun.. May 19 02:13:39 ahh May 19 02:15:07 installing the distro's own gcc-arm-linux-gnueabihf package and using that instead of linaro would avoid that particular issue right? although I'll admit I've not always had success with those toolchains, but that's a different problem (some resulted in kernel misbuilds for me, I never figured out why) May 19 02:18:14 That was one of the things i was working on before.. But then Ubuntu pushed Unity and I jumped ship after Maverick to pure Debian.. They now have good cross-compilers built-in, i didn't want to test every variant. The CC flag in system.sh still allows you to set those thou.. May 19 02:19:43 it was basically easier to recommend one version of linaro gcc, that i also used for testing, then figure out each version in every 6 month release of ubuntu's version they pushed.. May 19 02:20:05 I can imagine May 19 02:24:13 zero_note: why are you stuck on some specific ancient kernel anyway? not even just an old series but an old release within the series. it's evidently not because you can't upgrade the system, considering you're working on getting a kernel module compiled for it :P May 19 02:27:03 zmatt: well, as a technical part for a job interview the company lead engineer gave me this beaglebone black with a accelerometer May 19 02:27:23 the jumpers and all the other stuff needed May 19 02:28:33 then, they sent the test documentation that we can summarize in "write an i2c driver for the accelerometer, push your sources to a github repo" May 19 02:29:04 zero_note: maybe ask for clarification whether you can flash the latest official image to the beaglebone, or whether trying to get shit working on an embedded system that is running an ancient, unmaintained, unsupported is representative of the work you'll be doing there May 19 02:29:14 *unsupported system May 19 02:29:19 and obviously I have to tell them which steps are needed to CC the module, with the correct toolchain etc.. May 19 02:29:21 since in the latter case, get out while you can May 19 02:29:51 you can't image how much I agree with you May 19 02:29:55 imagine* May 19 02:30:24 especially if you're going to write a new driver, you'll want to do so for the latest kernel May 19 02:30:36 making a driver for an ancient kernel is a huge waste of time May 19 02:30:44 you'll have nowhere to contribute it to May 19 02:31:13 the funny thing is that a driver this specific accelerometer already exist May 19 02:32:13 so I suppose they just want to check how fast I can retrieve already existing sources and adapt them to the actual use context May 19 02:32:57 backporting drivers to an ancient kernel sounds like a dream job to me :P May 19 02:32:59 also, I didn't know (last time I worked on a beaglebone was 2015) that from u-boot 2017.x the overlays May 19 02:33:07 are managed by u-boot itself May 19 02:33:35 so things like "echo my_overlay_name > /sys/devices/platform/bone_capemgr/slots" won't work anymore May 19 02:33:38 yes, runtime overlays have always been buggy and there was no hope of getting them upstream May 19 02:34:00 so that has been moved into u-boot May 19 02:34:19 so I had to create a new initramfs with my dtbo included and now it is being loaded on boot May 19 02:34:29 uhh no May 19 02:34:31 initramfs is irrelevant May 19 02:34:37 the file needs to be in /lib/firmware/ May 19 02:34:56 I am sorry but no May 19 02:35:01 if u-boot is in charge May 19 02:35:19 you can't just put your dtbo in your /lib/firmware May 19 02:35:22 u-boot reads dtbos directly from the filesystem, the contents of initramfs is opaque May 19 02:35:39 initramfs is for the kernel, not for u-boot May 19 02:36:47 I can imagine having dtbos inside initramfs would allow them to be loaded during early boot back when runtime overlays were still used May 19 02:36:50 the only way I solved this was creating a new initrd, just putting my dtbo in /lib/firmware and adding my overlay do uEnv.txt May 19 02:37:03 wasn't enough May 19 02:37:24 then you're not using u-boot overlays May 19 02:38:26 uhm ok, so do you have any idea why the kernel wasn't able to load the overlay? May 19 02:38:41 I mean without touching inird and uEnv.txt May 19 02:38:43 if the kernel is doing anything with overlays whatsoever, you're not using u-boot overlays May 19 02:39:04 I mean, that part sounds consistent with using u-boot overlays, so mostly your story sounds confusing to me May 19 02:39:41 no problem, I can start again following your instructions May 19 02:39:45 but I am 100% sure that u-boot loads overlays directly from the filesystem, and I'm pretty sure it's actually *incapable* of extracing files from initramfs May 19 02:40:07 initramfs is also entirely optional, I don't use it on any beaglebone May 19 02:40:28 (they boot faster without it) May 19 02:41:40 this assumes a recent kernel though, there were problems booting without initramfs on old kernels May 19 02:42:16 wait, you're not trying to use a 4.1 kernel with a recent u-boot I hope? because that sounds like masochism May 19 02:42:33 uhm no, no worries :) May 19 02:42:45 phew May 19 02:43:10 U-Boot 2016.01-00001-g4eb802e (Jan 13 2016 - 11:14:31 -0600), Build: jenkins-github_Bootloader-Builder-313 May 19 02:43:34 not so recent May 19 02:43:56 okay, so why is u-boot overlays being discussed, since this predates it May 19 02:44:43 (I'm pretty sure) May 19 02:45:18 beacuse just putting the overlay in /lib/firmware and writing cape_enable=bone_capemgr.enable_partno=BB-MY-MOD May 19 02:45:30 in /boot/uEnv.txt wasn't enough May 19 02:46:20 that option already implies u-boot overlays are not used May 19 02:46:51 as for why you have trouble getting your overlay loaded by the kernel, no idea... like I said, runtime overlays have always been buggy May 19 02:47:11 perfect, so at this point (dtbo in /lib/firmware and uEnv.txt modified as said) the overlay wasn't loaded May 19 02:47:29 check kernel log for errors May 19 02:47:38 are any other overlays loaded according to the slots file? May 19 02:47:38 and then, creating a initrd with my overlay in /lib/firmware solved the problem May 19 02:47:56 nope May 19 02:48:32 oh I guess it makes sense that if you want overlays to be loaded during boot, and an initramfs is being used, that the overlays need to be in the initramfs May 19 02:48:52 probably the script that loads them (based on /proc/cmdline) is part of initramfs May 19 02:48:55 this was also my assumption at the end May 19 02:49:30 this has nothing to do with u-boot overlays though, those are loaded (from the filesystem) by u-boot and applied to the main dtb before passing it to the kernel May 19 02:49:50 ok, thanks for the clarification May 19 02:50:09 you're basically learning an obsolete still though, runtime overlays are deprecated and will be removed May 19 02:50:14 *skill May 19 02:51:03 now I thinking "if u-boot is not the problem, why I can't just put my overlay in /lib/firmare and use echo ... > /sys/devices/platform/bone_capemgr/slots to enable it?" May 19 02:51:24 check kernel log for errors? May 19 02:51:34 or, what error did echo give? May 19 02:51:46 it was "Permission denied" May 19 02:52:12 so I thought something else was using the same slot May 19 02:52:15 btw, what does your overlay contain anyway? if you're just declaring the existence of an i2c device, you can also add it at runtime via ls /sys/bus/i2c/devices/i2c-2/new_device May 19 02:52:22 did you perform the echo command as root? May 19 02:52:35 yes May 19 02:53:10 (note: "sudo echo yada yada >file" will _not_ work, since that causes the shell to try to open the file as normal user and write the output of "sudo echo yada yada" to it) May 19 02:53:40 uuuh WAIT May 19 02:53:47 you're right! May 19 02:53:47 haha May 19 02:54:09 echo yada yada | sudo tee filename is one workaround May 19 02:54:09 let me check this. May 19 02:54:15 or sudo -i May 19 02:54:18 or that May 19 02:54:35 see this is what happen after 10 months of iOS development May 19 02:55:27 or sudo sh -c 'echo yada yada >file' May 19 02:55:32 lots of options May 19 02:56:11 I'll do some tests and let you know May 19 02:56:21 as always thank you so much. **** ENDING LOGGING AT Sun May 19 02:59:57 2019