**** BEGIN LOGGING AT Fri Jul 29 02:59:58 2016 Jul 29 07:30:32 good morning Jul 29 08:44:26 Good Morning. I talked about compiling a new kernel module yesterday. I was able to compile the new kernel module yesterday with the kernel source code (for the header files) of my yocto/open embedded toolchain Jul 29 08:44:38 Now I wanted to write the recipie. Jul 29 08:44:50 For that I took a look at this example: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb Jul 29 08:45:45 But the question is now: in my case I have a *tar.gz file from the kernel module developer, and to compile the module I have to run: make install_static KDIR=${KERNEL_SRC} ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- Jul 29 08:45:54 How do I have to write this in my recipie Jul 29 08:54:40 HyP3r: i'm not sure about the details, you can add your .tar.gz in a file:// line, yocto will unpack that for you. Jul 29 08:55:10 from that point, if your module is compiled "the normal way" yocto should do everything for you... so just try the recipe and see if it works Jul 29 08:55:24 (i'm not sure, I havn't tweaked kernel recipes so far...) Jul 29 08:57:19 boucman_work: but how does yocto know how to run the makefile? and in which directory and so on Jul 29 08:57:57 and the next thing: the kernel module is will lay in a weird folder (csr/os-linux/driver) Jul 29 08:58:10 how does yocto know that there will be the *.ko file Jul 29 09:00:03 most kernel module are compiled in the same way, with the same arguments to make. yocto knows that Jul 29 09:00:35 I read this https://software.intel.com/sites/default/files/m/4/d/8/5/8/42868-11__Developing_Kernel_Module_on_Yocto.pdf and this http://wiki.kaeilos.com/index.php/Howto_build_a_kernel_module_out_of_the_kernel_tree Jul 29 09:00:54 They run with $(MAKE) -C $(KERNEL_SRC) M=$(SRC) modules Jul 29 09:01:00 as for the weird directory, you need to change the S= line to point to the right place. your tar.gz will be unpacked in ${WORKDIR} so you should point it to a subpath of that Jul 29 09:01:24 okay. But thats all a bit confusing :S Jul 29 09:01:46 HyP3r: a kernel module is not exactly the simplest recipe to start learning yocto :P Jul 29 09:02:34 Yep but the only thing what I have to do \o/ Jul 29 09:03:03 hehe Jul 29 09:03:37 well, let's work step by step. could you pastebin your recipe somewhere so I can look at it/comment it more easily ? Jul 29 09:07:30 boucman_work: wait, I'll try to write in the best way I can (...) and then I will post it here, now its looks like a car crash Jul 29 09:18:19 ok, np Jul 29 09:34:20 boucman_work: folder structure: http://pastebin.com/EeeQKnN2 and the recipie: http://pastebin.com/dSVdXme3 Jul 29 09:37:54 ok, did you run the recipe ? how far did it go ? what errors ? Jul 29 09:38:00 here are a couple of remarks Jul 29 09:38:15 no, I didn't run, I'm afaraid and I don't know how to do that sorry Jul 29 09:38:38 don't "cd" in do_compile. you should set the "S" as I pointed earlier, do_compile will then be run in the proper directory Jul 29 09:39:17 just "bitbake wf111-driver" should do the trick Jul 29 09:43:04 hi, is there something like pkg_preinst_${PN}lib which only runs on the target? Jul 29 09:43:20 install_prepend of some kind? Jul 29 09:55:18 lpapp: yes, gimme a sec to find my notes Jul 29 09:56:15 boucman_work: now I did something wrong: while running bitbake I get this: IOError: file conf/bitbake.conf not found in /.../oe-core/build (the first time I run it today it was working, but now this error comes) Jul 29 09:56:46 I grepped my history (zsh and bash) and I didn't delted this file Jul 29 09:56:49 we used FILESEXTRAPATHS_prepend, so it is possible that install_prepend would work, too? Jul 29 09:56:56 lpapp: http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#new-recipe-post-installation-scripts Jul 29 09:57:51 HyP3r: are you running bitbake from your build directory ? did you source oe-init-buildenv ? Jul 29 09:58:17 your build directory is in the env variable $BUILDDIR. if it's not set, then you probably didn't run the setup script Jul 29 09:59:22 boucman_work: I started with running ". export" in the directory with this export file Jul 29 09:59:26 boucman_work: I need preinstallation, not post. Jul 29 09:59:51 this script is changeing the directory to this build directory and there I was starting the bitbake command Jul 29 10:00:29 lpapp: no you don't :P Jul 29 10:01:00 boucman_work: I want to do something before installating things, hence pkg_preinst_${PN}lib Jul 29 10:01:11 once again, I can check for the existence of certain directories to identify the target. Jul 29 10:01:15 or do something clever Jul 29 10:01:30 but I thought there would be something like install_prepend similar to install_append Jul 29 10:01:39 although install_prepend would probably run in Yocto, too, gosh. Jul 29 10:01:42 there is _prepend and _append Jul 29 10:01:50 i'm not sure about the "run on target" part Jul 29 10:02:10 but you can probably check in a similar way as the postinst doc I pointed above Jul 29 10:02:50 lpapp: you usually want to make two packages, rather then check what to do at install time, those packages would target different MACHINE Jul 29 10:03:19 boucman_work: it seems that is related to booting. Jul 29 10:03:34 my use case is not related to booting, just simply packaging installation without any booting. Jul 29 10:03:46 I have only one machine. Jul 29 10:04:22 Also, this is not quite bullet-proof either: if [ x"$D" = "x" ]; then Jul 29 10:04:38 someone could define the D environment variable on the target, too, to screw it up. Jul 29 10:06:07 lpapp: that's the recommanded method, so I'd use it Jul 29 10:06:32 and I don't really understand your use-case at this point. I'm not sure why you think it's related to booting... Jul 29 10:06:49 boucman_work: even in my old directory this bitbake.conf is not in the conf directory Jul 29 10:06:50 the section speaks quite a bit about booting, that is why. Jul 29 10:06:56 Also, I do not like the recommended case. Jul 29 10:06:58 boucman_work: something cirtical is borken :( Jul 29 10:07:06 because it is easy to screw up a production system that way. Jul 29 10:07:23 with my approach of checking opkg's availability in the build environment looks cleaner. Jul 29 10:07:33 because that gives no room for screwing up a production system Jul 29 10:07:44 if anything, there could be a problem in the development (Yocto) environment. Jul 29 10:07:47 lpapp: that command is not run dicrecly, it's run by yocto at image-creation time. yocto is very good at sanitizing the environement Jul 29 10:07:54 so recommended or not as of the time being, I do not like it for that reason. Jul 29 10:08:17 again, if you set D, yocto will override it at image-creation time Jul 29 10:08:37 I do not know how that can even work then to be honest. Jul 29 10:08:44 and if it's run on the target, it's run by your package manager (opkg, rpm, dpkg) which probably sanitze the env too Jul 29 10:08:49 because that means it will be always defined. Jul 29 10:08:59 so it is never going to be empty, so it cannot actually work on the target as desired. Jul 29 10:09:26 at image-creation time, it's not empty. it's set by yocto Jul 29 10:10:07 so what makes it empty with 100% certainity at package installation time? Jul 29 10:10:42 (and now that I think of it, you probably can't run pre-install on the target in a 100% safe fashion...) Jul 29 10:11:10 lpapp: so. image creation is the time where yocto collects all the package built, and use them to create a rootfs. Jul 29 10:11:21 this is done on the build-system, not the target. Jul 29 10:12:23 yes, I know that part. Jul 29 10:12:34 once a packagee is installed, bitbake will run post-install scripts for that package. bitbake always sanitize the shell-environement before running shell commands and there is a verylimited list of whitelisted env variables that are allowed to carry through Jul 29 10:12:53 D is not one of them, and D is overridden by bitbake anyway Jul 29 10:13:41 if the post-install script fails (return 1) then bitbake will save that script on the target and try to run it again at first boot Jul 29 10:14:29 but I don't think a pre-install script can block the way a post-install does... maybe. you'll have to test it Jul 29 10:14:38 Jul 29 10:15:34 anyway, i'm pretty sure setting D won't carry to post-inst at image-built time. I'm less sure at first-boot time, it might depend on your packaging format, but I would be suprised if package managers didn't have that sort of safety in place Jul 29 10:16:26 but if you want to be really safe, you can test for being on the target in whatever other way you like... (run uname, check for something you know is only on the target) the important part is returning 1 for post-inst Jul 29 10:17:15 unfortunately, boot is absolutely irrelevant for me here. Jul 29 10:17:37 as packages get installed without booting as mentioned above. Jul 29 10:18:07 in fact, it is absolutely required in our case not to boot Jul 29 10:18:25 cause that would mean an undesired outage in the service we provide 7/24. Jul 29 10:34:54 lpapp: post-install is also run at package install time even if it's not first boot Jul 29 10:35:12 (and probably pre-install too, but again, you should test) Jul 29 10:37:25 I got it working my own way, it is ok, thanks. Jul 29 10:38:55 k Jul 29 12:10:29 boucman_work: well what I did in my local.conf: I removed all the autogenerated lines from hob Jul 29 12:10:46 I have creaated a second yocto directory Jul 29 12:11:04 Now if I compare the old with the new configurations I can see the 'problems' Jul 29 12:11:14 I hope I can solve that by this way... Jul 29 12:15:27 boucman_work: ok now everything works again, now I can try to run the recipie Jul 29 12:22:54 Its getting even worser, now the configuration files are repaired: http://pastebin.com/hg3uKYJi Jul 29 12:23:06 Now I get even more strange erros Jul 29 13:08:53 boucman_work: now I can compile again! The run.do_compile of my recipie does not set the Variable KERNEL_SRC. Is this Variable allready set when this script is called? Jul 29 13:09:02 The rest of the script looks good Jul 29 13:29:18 HyP3r: yes, it's set because you inherit kernel module Jul 29 13:37:58 boucman_work: yes it was set, I had another problem with my make script, in the source code are some __DATE__ and __TIME__ Macros \o/ Jul 29 13:40:59 boucman_work: I can't set the S variable, or I don't know how Jul 29 13:41:27 heres the new version http://pastebin.com/47nbs0gw Jul 29 13:41:55 S = ${WORKDIR}/wf111-linux-driver_${PV}-${PR}_armv7-a Jul 29 13:42:03 note : not ${S} Jul 29 13:42:25 I tried that too wait I'll try it again Jul 29 13:42:46 you don't need to call patch in do_compile. bitbake will see that the file is named .patch and should apply the patch by itself Jul 29 13:42:58 ERROR: ParseError at /home/x/Dokumente/x/ToradexVF61_01/oe-core/build/../stuff/meta-racechip/recipes-driver/wf111-driver_5.2.2.bb:20: unparsed line: 'S = ${WORKDIR}/wf111-linux-driver_${PV}-${PR}_armv7-a' Jul 29 13:43:16 and line 19, the unset LDFLAG seems suspicious. why are you doing that ? Jul 29 13:43:38 boucman_work: I saw that somewhere don'T know Jul 29 13:43:46 you need to also quote the whole thing (my bad, didn't see it at first) Jul 29 13:44:00 boucman_work: to what file, will bitbake apply the patch Jul 29 13:44:23 also remove the INSANE_SKIP line. if the problem apears, we will re-add it later Jul 29 13:44:34 boucman_work: the patch dosn't contain a information to what file it blongs Jul 29 13:44:56 it will apply it in the S directory. a patch file is supposed to contain it's own path and file name Jul 29 13:45:10 Oh then I created the patch wrong Jul 29 13:45:17 (and there is a way to pass -p1 to patch if needed, but that might not be needed Jul 29 13:45:24 I did this diff -crB Tb01 Tb02 > Tb02.patch Jul 29 13:46:21 hmm Jul 29 13:46:22 Oh sorry I did simply "diff ..." without any arguments Jul 29 13:46:32 But "-crB" is ok? Jul 29 13:46:43 crB should be ok Jul 29 13:47:13 could you pastebin the patch itself ? Jul 29 13:47:41 http://pastebin.com/Rb0g2DE3 seems strange Jul 29 13:48:04 I created simply a copy of the makefile, and added there the new lins Jul 29 13:48:17 But I think that ".bak" should not in the patch Jul 29 13:48:52 HyP3r: you are used to patches generated with the -u option, this one should work it's just not the format we are used to Jul 29 13:49:41 the patch seems ok. line 1 and 2 is what yocto use to know what file to apply it to. I assume there is a file called makefile in ${WORKDIR}/wf111-linux-driver_${PV}-${PR}_armv7-a right ? Jul 29 13:50:06 yes Jul 29 13:50:29 ok, then the patch should apply automagically Jul 29 13:50:59 wow, and this '.bak' will be ignored, because there will be no 'bak' file Jul 29 13:51:10 please run "bitbake -c fetch wf111-linux-driver" to force the whole process and see if it worked Jul 29 13:51:17 k Jul 29 13:51:35 not sure... we'll see what error bitbake reporst :P Jul 29 13:54:50 boucman_work: now bitbake created the bak file, makefile is unchanged Jul 29 13:55:47 boucman_work: how can I clean up the working directory? It seems like the compile script wasn't updated Jul 29 13:56:14 bitbake -c cleanall wf111-linux-driver Jul 29 13:56:40 was the makefile.bak created in the same directory as the makefile is ? Jul 29 13:57:12 http://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#ref-tasks-clean Jul 29 13:57:18 yes Jul 29 13:58:45 ok, good Jul 29 13:59:10 line 2 of your patch, could you change "Makefile.bak" to "Makefile" and see if it works ? Jul 29 14:00:15 your patch is a bit weird, though, it's as if makefile.bak contained the changes and makefile was the original file... Jul 29 14:01:23 http://pastebin.com/t0gXdmys Jul 29 14:01:59 Now I think the problem is that the patch file is under the work directory, and the Makefile in the subdirectory, I will apply the patch Jul 29 14:02:04 I will changes the path Jul 29 14:03:40 boucman_work: now the recpie works, compiling the kernel Jul 29 14:04:07 boucman_work: but I bit inconvenient, the patch contains now a satatic path Jul 29 14:04:26 http://pastebin.com/1N4LRNKN Jul 29 14:09:30 no, that looks fine, Jul 29 14:22:18 boucman_work: another thing: theres a kernel-source directory and in the same directory theres a kernel-build-artifacts and inside this directory is the .config file. But the compile runtime of this drivers needs this file inside the kernel-source directory Jul 29 14:22:34 boucman_work: at the moment it crashes because there is no .config file Jul 29 14:22:44 boucman_work: is there a way to merge those folders temporary? Jul 29 14:25:31 no idea Jul 29 14:27:54 well I could merge them now manual buts thats a really bad (?) hack Jul 29 14:33:32 might break stuff... can you tell the driver's build system where to look for .config via its command line ? Jul 29 14:53:29 As I started I found this driver script: https://github.com/engicam-stable/meta-engicam/blob/master/recipes-core/wf111-driver/wf111-driver.bb Jul 29 14:53:53 khem: on daisy (at least the version I'm stuck with) it appears I need to also delete 'tmp' (in addition to 'cache') to force re-caching to occur. Jul 29 14:54:04 Other kernel module driver use "inherit module" Jul 29 16:54:04 jmesmon: yes tmp/ should go too Jul 29 18:41:07 hi guys, is there some directory in poky/ that contains all popular licenses? like GPL/MIT/BSP etc. Jul 29 18:41:31 I'm preparing a simple recipe containing only udev rule and I need to get license file from somewhere to checksum it Jul 29 18:48:12 found it! meta/files/common-licenses **** ENDING LOGGING AT Sat Jul 30 02:59:58 2016