**** BEGIN LOGGING AT Thu Jun 30 02:59:58 2016 Jun 30 03:00:16 if I have a question on my short testing code it's a pastebin away Jun 30 03:03:18 as long as what you're doing is visible i don't really care... Jun 30 03:04:04 you need to leave a trail somehow Jun 30 03:04:24 blog-y thing, wip branches, whatever Jun 30 03:05:10 otherwise nobody else can tell wtf Jun 30 03:06:28 maybe it would help if google just changed it GoogleSummerofExposingYourselfInPublic Jun 30 03:06:38 bad acronym i guess... Jun 30 03:06:59 heh, perhaps :) Jun 30 03:07:23 overheads either way, eh? getting somethign working doesn't cut it I guess Jun 30 03:08:51 well, that plusthey all want to see you Do It Jun 30 03:10:32 it's not like I'm going to stick it all in one massive commit once a week. would just be nice to be able to figure something out without worrying about how best to make a public show of it, you know? Jun 30 03:12:32 well, it's a "job" but it's not a job Jun 30 03:12:49 everything google-y is "special" Jun 30 03:14:03 and they put an emphasis on Code but then they also put an emphsis on Communication Jun 30 03:14:32 you got a solution? i'm all ears... Jun 30 03:15:19 i got nothin' left but the wife's Deadly Stare Jun 30 03:16:26 I don't have a problem with that (or so much of one... I'm trying). I think I've been fairly vocal about what's going on recently, including my separate testing code stuff Jun 30 03:17:01 I'm not certain why that's not sufficient, I suppose. putting even more time into throwaway code than I need to just seems counterproductive Jun 30 05:37:07 hmmm Jun 30 13:18:26 Visaoni: first, your repo is nowhere near the size where you'll start to have any issues with having a few different experimental branches (and if you're using git right that'll never be a problem) Jun 30 13:18:52 Visaoni: Second, it's a requirement that you show us what you're doing. At the start we said everyone needs to be pushing content 5 days/week, so if you're spending time working on little throwaway test code, we need to see that, as well as logs of the test results. If you're spending time debugging stuff, we need to see a blog post or wiki page where you show what you're trying and what errors you're getting, etc. Jun 30 13:19:40 Visaoni: it's not about you having a question on your short testing code, it's about us needing to see everything you're doing Jun 30 13:19:51 * alexhiam is catching up on the logs.. Jun 30 13:21:44 Visaoni: if you're really insistent on not making a new branch you can just make a tests/ directory in your repo and put that stuff there Jun 30 18:43:41 hey bradfa there? Jun 30 18:43:44 mdp^^? Jun 30 18:45:52 hi chanakya_vc Jun 30 18:46:00 * bradfa gets coffee, brb Jun 30 18:48:58 When I am compiling bradfa, I am getting this:http://pastebin.com/u0173nRF Jun 30 18:49:22 * chanakya_vc pulling his hair compiling this driver. Jun 30 18:49:30 lol :P Jun 30 18:52:53 chanakya_vc: CROSS_COMPILE=arm-linux-gnueabi- You're forgetting the trailing "-" :) Jun 30 18:55:21 CROSS_COMPILE=arm-linux-gnueabi "Path to kernel source" ? bradfa? Jun 30 18:55:30 This is what you mean? Jun 30 18:56:08 make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- -C ~/git/linux M=$PWD Jun 30 18:56:16 replace ~/git/linux with the actual path to your linux source code Jun 30 18:58:24 chanakya_vc: chanakya_vc ^^^^ Jun 30 18:59:42 chanakya_vc: my cross compiler prefix is "arm-ka-linux-gnueabi-" so my compile looks like this: http://pastebin.com/FhkFVFb8 Jun 30 19:12:30 * nerdboy keeps finding more TI pru stuff but it pretty much all points back to old code/pruss.drv/uio stuff Jun 30 19:16:54 http://pastebin.com/Zv4dhbmk bradfa Jun 30 19:17:00 Still some problems Jun 30 19:17:27 I think I am giving the path wrong. I used RCN's kernel builder to build my kernel Jun 30 19:18:08 chanakya_vc: hmmmm Jun 30 19:18:27 chanakya_vc: can you edit the kernel .config file and comment out the line which defines CONFIG_CC_STACKPROTECTOR_STRONG ? Jun 30 19:19:35 I took the easy way out bradfa, using RCN's kernel buider bradfa Jun 30 19:19:47 And that's why I have to debug so much :P Jun 30 19:19:57 looking Jun 30 19:20:55 i think we pretty much know what/where all the current upstream stuff is Jun 30 19:20:56 nerdboy: uio driver is still the "official" or status quo path Jun 30 19:21:17 "official" stable/old maybe Jun 30 19:21:41 chanakya_vc: I'm not sure what RCN's kernel builder is... Jun 30 19:21:48 TI devs are telling people "change your mailboxes to interrupts now" Jun 30 19:22:04 nerdboy: you can ignore this recommendation from TI for AM335x Jun 30 19:22:05 nerdboy: sure Jun 30 19:22:10 nerdboy: and AM43xx and AM57xx Jun 30 19:22:40 nerdboy: there is unannounced silicon which has no mailbox subsystem but does have PRUs coming, sometime in the future Jun 30 19:22:59 current am35xx/other pru stuff is v5 and 2.1.2 pru compiler Jun 30 19:23:03 TI is jut trying to keep the code common across the SoC which have PRUs Jun 30 19:23:08 Here bradfa:https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-LinuxKernel Jun 30 19:23:34 yeah, but you can't upgrade your "ti" kernel without hitting that Jun 30 19:23:46 nerdboy: oh, true... Jun 30 19:23:51 even jessie images break firmware now i think Jun 30 19:24:16 nerdboy: ti hasn't gotten this code upstream to mainline yet, iirc, so it may still change again :) Jun 30 19:24:41 well, it tells you that every time firmware loads Jun 30 19:25:16 chanakya_vc: ugh... Jun 30 19:25:24 all i'm saying is there's a lot of "official" churn and not a lot of clarity Jun 30 19:25:27 chanakya_vc: go into the kernel source directory you have from RCN Jun 30 19:25:33 chanakya_vc: make mrproper Jun 30 19:25:42 chanakya_vc: make ARCH=arm omap2plus_defconfig Jun 30 19:25:51 took me some non-trivial effort to figure at all out... Jun 30 19:25:55 chanakya_vc: make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- prepare Jun 30 19:26:09 not so good for students Jun 30 19:26:10 chanakya_vc: then try building your module against it Jun 30 19:26:22 nerdboy: not just students, it's fun to be a TI customer, too :) Jun 30 19:27:16 not really, especially when they drop hardware for which "support" was never comlpeted in the first place Jun 30 19:27:36 * bradfa was being very sarcastic :) Jun 30 19:27:44 dm8168 Jun 30 19:28:14 nerdboy: well, that situation is never going to change in the semi industry Jun 30 19:28:27 margins are too small to provide what they call "full silicon entitlement" Jun 30 19:28:31 mdp: don't bring your real world understandings into this, you'll just depress us all! :) Jun 30 19:28:31 unpossible Jun 30 19:28:43 sorry Jun 30 19:28:46 :) Jun 30 19:29:25 depending on volumes, I'd suspect they'd need to be 2x-5x costs to have enough s/w budget Jun 30 19:29:35 mdp: that's supposed to be top of the line and never got anything beyond a broken oc-classic/personal dev arago hack for support Jun 30 19:29:51 *oe-classic even Jun 30 19:30:15 bradfa, it worked Jun 30 19:30:18 should be able to do better than that... Jun 30 19:30:20 nerdboy: that's because it's a part that was targeted at a narrow vertical market and handled by a clueless group Jun 30 19:30:27 chanakya_vc: worked as in you get similar errors/warnings as me? Jun 30 19:30:32 I don't really understand what you did. Jun 30 19:30:34 Yes Jun 30 19:30:38 Ironic :P Jun 30 19:30:41 chanakya_vc: 'make mrproper' cleans everything up Jun 30 19:30:42 nerdboy: I remember it well from my TI days ;) Jun 30 19:30:50 closely related parts are much better supported Jun 30 19:30:54 nerdboy: no budget Jun 30 19:31:08 chanakya_vc: 'make ARCH=arm omap2plus_defconfig' sets up the in-kernel configuration file as the config for the kernel to build with (although we don't actually build a kernel) Jun 30 19:31:31 * nerdboy was willing to jump to the new oe/meta-ti and they were just scared Jun 30 19:31:33 chanakya_vc: 'make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- prepare' gets the kernel sources into the right state to have out of tree modules build against it Jun 30 19:32:06 chanakya_vc: for details, see https://www.kernel.org/doc/Documentation/kbuild/modules.txt Jun 30 19:32:07 stupid/scared/over-their-heads Jun 30 19:32:19 chanakya_vc: once you do that first run of rcn's script..then you never use it again in a development work flow Jun 30 19:32:41 Thanks bradfa. Now to get the errors out. Jun 30 19:32:47 chanakya_vc: :) Jun 30 19:32:50 chanakya_vc: what bradfa is demonstrating is the generic way that works across any architecture/platform to build the kernel Jun 30 19:33:05 chanakya_vc: which version did you check out, btw? Jun 30 19:33:43 mdp, I just used it to build the kernel so that I could use it as a source. I used v 4.4 Jun 30 19:33:52 nerdboy: they always have had to support certain cases so never wanted to move forward Jun 30 19:34:19 yes, do not run build_kernel.sh a second time Jun 30 19:34:31 Ohhh... Jun 30 19:34:36 Got it now. Jun 30 19:34:53 Thanks mdp, nerdboy Jun 30 19:34:53 once is all you need, then use tools/rebuild.sh Jun 30 19:35:20 * bradfa is not a huge fan of the helper scripts... Jun 30 19:35:33 Ohh.. And like a fool I deleted the directory and downloaded everything again when I messed up the first time :P Jun 30 19:35:40 meh, they're handy but not required Jun 30 19:36:05 although they package stuff up to install/match the uEnv config Jun 30 19:36:28 students should probably use them or apt-get a kernel image Jun 30 19:37:08 bradfa: I use it just to glue a repo together if I need the bb.org patches..then ignore it Jun 30 19:37:16 robert's are cleaner/less annoying than some other i've seen lately... Jun 30 19:37:59 bradfa, You would prefer something of this sort :https://sites.google.com/site/beagleboneblac/home/cross-compiling-linux-kernel-module Jun 30 19:38:05 mdp nerdboy ^^ Jun 30 19:38:43 there are modules packaged already too Jun 30 19:38:54 what are you building exactly? Jun 30 19:39:16 chanakya_vc: that's more or less what the script is doing in that tree Jun 30 19:39:41 Cross compiling a driver nerdboy. For that I require to build the kernel so that I could use that as kernel source on my host Jun 30 19:39:43 nm, i found it... Jun 30 19:39:43 the repo is just a pile of patches per kernel version that aren't upstream Jun 30 19:39:45 Ohh mdp Jun 30 19:42:51 Although mdp the first line where it starts building the kernel is:make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- beaglebone_defconfig Jun 30 19:43:01 might be easier on bb itself Jun 30 19:43:20 And bradfa's command had omap2plus Jun 30 19:43:25 do the kernel prep once and the driver should build/fail pretty fast... Jun 30 19:43:49 I don't get the difference. Jun 30 19:43:49 Ohh Jun 30 19:44:01 then you can forget all the cross-compile stuff and just make blah Jun 30 19:44:04 chanakya_vc: he was using omap2plus_defconfig as that's the generic upstream defconfig...(well multi_v7_defconfig is actually) Jun 30 19:44:06 chanakya_vc: I know the omap2plus defconfig works, I have no idea what the beaglebone defconfig is and you were having issues with some stack protector config options Jun 30 19:44:25 nerdboy: oh gosh no...let's no teach people to natively compile on an underpowered arm device ;) Jun 30 19:44:32 *not Jun 30 19:44:36 use the same kernel source/defconfig as rn kernel Jun 30 19:44:48 mdp: it's only one module Jun 30 19:45:14 i told them *don't* compile the whole that way Jun 30 19:45:27 chanakya_vc: beaglebone_defconfig is provided in this downstream kernel and is the recommended in that tree Jun 30 19:45:37 Ohh.. got it bradfa, Will have to read up on this a bit. Jun 30 19:46:10 nerdboy: not good as a generic kernel devel approach Jun 30 19:46:33 * nerdboy takes rcn defconfig and modifies it a bit Jun 30 19:46:48 when you debug..and need to change a kernel hacking flag that touches everything..now you want to know how to cross compile again Jun 30 19:47:12 remote kernel debugging is easier? Jun 30 19:47:46 cross compiling results in faster debug turn-around Jun 30 19:48:29 When you say it is in the downstream kernel , in my understanding it is a derivative of the omap2plus deconfig right. Like we say Linux mint is downstream from Ubuntu Jun 30 19:48:33 mdp ^^ Jun 30 19:48:42 depends on skills/toolset Jun 30 19:48:48 * chanakya_vc gets confused by terminologies Jun 30 19:49:06 unless you have some limited case where yes, you only ever build this one module and printk debug.. Jun 30 19:49:35 nerdboy: just trying to teach the skills ;) Jun 30 19:49:36 but no reason they can't do both (super-easy) small native builds and (easy-easy) cross builds Jun 30 19:50:06 kinda reinforces the difference maybe? Jun 30 19:51:14 chanakya_vc: so, the official bb.org kernel is a downstream kernel offering from that off the mainline linux kernel. it contains patches applied to the upstream kernel that offer additional functionality. This is analogous to the shipping Ubuntu kernel even for x86 having a bunch of patches maintained by that distro on top of the mainline Linux kernel. Jun 30 19:52:07 chanakya_vc: most visible are things like the cape manager support for which most HOWTOs are written around doing things on BBB Jun 30 19:52:21 * nerdboy has 5 gcc toolchain version with 9 total compiler options installed on this desktop Jun 30 19:52:28 2 of them are native Jun 30 19:52:56 not counting gnat-gcc which is still a separate ebuild Jun 30 19:53:10 there are many toolchains Jun 30 19:53:18 Ohh...okay so my question is that the mainline linux kernel is mantained for all architectures? Jun 30 19:53:26 mdp ^^ Jun 30 19:53:50 Because I believe that kernel is architecture dependent? Jun 30 19:54:10 chanakya_vc: yes, the kernel is maintained for all supported architectures Jun 30 19:54:45 chanakya_vc: these patches in the bb.org kernel have just not gone through the process to enter the upstream kernel. Jun 30 19:55:03 [which is a very long story in itself] Jun 30 19:55:19 maybe an infinite number when crossdev is installed... Jun 30 19:56:16 bb.org kernel isn't synced with current rcn patches but i'm not sure about the workflow for that Jun 30 19:56:26 Okay got that mdp.But the changes that bb.org is doing is only specific to the BBB right? So I mean is their possibility of that being merged upstream? Jun 30 19:56:30 eg, how often, etc Jun 30 19:56:43 RCN's stuff is upstream kernel right? Jun 30 19:57:42 chanakya_vc: when I refer to the upstream kernel, that means mainline/Linus' tree..there's possibility and active work to merge some form of some of the patches there, yes. Jun 30 19:57:55 chanakya_vc: RCN's kernel is a downstream distribution kernel. Jun 30 19:58:07 enhanced for BBB..does that make sense? Jun 30 19:58:17 rcn is the bleeding edge focal point Jun 30 19:58:22 Okay. Ya that does. Jun 30 19:58:57 Thanks mdp. I have never had the chance to talk to rcn but his work seems to be really cool :P Jun 30 19:59:15 but there are two bleeding edge patch sets, one for bb-kernel and one for ti-linux-kernel-dev Jun 30 19:59:20 and rcn is kind enough to maintain those patches building against each new upstream (linus) -rc release even. Jun 30 19:59:39 the ti-linux-kernel-dev stuff goes to denys and ti-staging kernel i believe Jun 30 19:59:50 chanakya_vc: as nerdboy points out..it's even more complication due to the TI kernel. Jun 30 20:00:20 ti-linux-kernel-dev has rpmsg stuff but bb-kernel does not Jun 30 20:00:21 chanakya_vc: and those ti kernel options are also more branches in the bb.org kernel repo Jun 30 20:00:48 meaning bb-kernel *repo* not beagleboard kernel Jun 30 20:01:21 * nerdboy still not sure exactly where bb.org kernel fits in Jun 30 20:02:00 all the rcn stuff is maintained as patches that apply to linux-stable (true mainline) Jun 30 20:02:27 what patches are in bb.org kernel i'm not exactly sure... Jun 30 20:02:48 ohh mdp, he does a lot of complicated work. So each change he makes ti kernel would actually amount to a differnt "Downstream "? Jun 30 20:03:09 branch of "Downstream" Jun 30 20:03:38 For bb.org kernel Jun 30 20:06:25 chanakya_vc: I have to run, but I'll be back tomorrow Jun 30 20:06:53 Np bradfa . I will work on those errors. Jun 30 20:07:05 Ask you stuff tomorrow or ask mdp. Jun 30 20:07:18 it looks like a random-ish collection of versions and named test branches Jun 30 20:07:19 Thanks for your help!! Jun 30 20:07:49 the bone branches would be backports/updates of rcn bb-kernel versions? Jun 30 20:08:39 are the numbered branches ti-dev patch sets? Jun 30 20:21:41 mdp: i think this describes your workflow? https://raw.githubusercontent.com/fpga-logi/logi-kernel/master/beaglebone-black/bbb_quick_setup.txt Jun 30 20:23:46 the cross-kernel/external-module bits Jun 30 20:26:29 yeah, except like bradfa, I don't use the canned scripts..I usually have some locally specific deployment compile/deploy script Jun 30 20:27:23 I generally nfsroot and do deploy that way Jun 30 20:29:00 small userspace tools for testing I will generally edit in that nfsroot from host..and either cross/natively compile in place Jun 30 20:29:21 so many workflows..that's just been my quickest way for a long time Jun 30 20:31:43 ^^ that could easily be adapted for students here Jun 30 20:32:32 with specific cape tips for green vs black vs other Jun 30 20:33:14 * nerdboy feels like we needed a kernel/version/repo/blahblah guidebook for this Jun 30 20:34:58 not enough time in GSoC to allow for much spinning... Jun 30 20:35:31 yeah, docs area always a problem Jun 30 20:35:37 s/area/are/ Jun 30 20:36:47 a little extra even Jun 30 23:05:07 * nerdboy has a new console image with test/sdk packages in it Jun 30 23:05:33 current ti kernel and cgt-pru-2.1.1 even **** ENDING LOGGING AT Fri Jul 01 02:59:58 2016