**** BEGIN LOGGING AT Tue Jun 16 02:59:59 2015 Jun 16 08:10:59 morning all Jun 16 08:28:43 morning Jun 16 09:41:06 morning all Jun 16 09:41:20 what's the best way these days to add a custom kernel recipe Jun 16 09:41:25 I see a lot of layers using linux.inc Jun 16 09:41:29 but all slightly modified Jun 16 09:41:59 is this really the best way to do it? take a copy from somewhere and hack it? Jun 16 10:05:28 jackmitchell: no... honestly I don't know what of those linux.inc files is still needed and if it is needed why on earth someone didn't just get it into kernel.bbclass Jun 16 10:05:57 jackmitchell: I'd suggest starting with meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb Jun 16 10:06:01 copy that and modify as desired Jun 16 10:06:28 you get support for config fragments, but no requirement to use the full linux-yocto structure (i.e. a meta branch) Jun 16 10:23:58 bluelightning: linux.inc stuff isn't in kernel.bbclass for political reason Jun 16 10:24:06 hopefully those reasons are gone now Jun 16 10:24:23 yes, politics is bullshit, we should fix any technical issues and set fire to the thing ;) Jun 16 10:30:27 bluelightning: if I was to use AUTOREV, it causes SRCPV to explode on parse, is this a known issue? Jun 16 10:31:02 jackmitchell: not if you're using it correctly it shouldn't - what is the error? Jun 16 10:31:35 bluelightning: http://pastebin.com/f0zFvwQk Jun 16 10:31:50 ah my bad Jun 16 10:31:52 git error Jun 16 11:43:35 bluelightning: I have a package recipe called package_git.bb Jun 16 11:43:59 What should be package tar name and SRC_URI for it. Jun 16 11:44:36 I am going to save the source into local git-source repo Jun 16 12:32:21 milan: er... I'm not quite sure I understand the question ... ? Jun 16 12:45:03 bluelightning: Here is an example. I have a recipe called calibrateproto_git.bb Jun 16 12:45:43 The SRC_URI looks like this : SRC_URI = "git://anongit.freedesktop.org/git/xorg/proto/calibrateproto;protocol=git \ Jun 16 12:46:39 and the source tar which gets downloaded is named as:git2_anongit.freedesktop.org.git.xorg.proto.calibrateproto.tar.gz Jun 16 12:47:15 Not the simple ${PN}-${PV}.tar.gz form it is Jun 16 12:48:11 Now if I want to save it in a local MIRROR to prevent against remote fetch errors anytime, I wonder what should be the tar file name Jun 16 12:48:51 git2_anongit.freedesktop.org.git.xorg.proto.calibrateproto.tar.gz Jun 16 12:49:02 Shall I retain the same git2_anongit.freedesktop.org.git.xorg.proto.calibrateproto.tar.gz , or change it to calibrateproto.tar.gz, before committing to local mirror Jun 16 12:50:24 JaMa: You mean I must retain the same name. I must not modify it. Jun 16 12:50:28 milan: if you place the file as it is already named in your local mirror *and* SRCREV has not changed (and is a fixed hash value) then it should be used instead of fetching from upstream repo Jun 16 12:50:38 in which case, there is no need to modify the recipe at all Jun 16 12:51:09 ok, Thanks! Jun 16 14:16:56 Crofton|work: do you know if the linux-xlnx 3.17 branch is stable enough for production use? (or at least as stable as the 3.14 branch) Jun 16 14:39:03 mago_: i skipped the linux-xlnx 3.17 branch cause it broken microblaze. Jun 16 14:40:13 nrossi: so whats the recommended kernel for zynq right now? Jun 16 14:40:31 mago_: Depends, do you need the features from the linux-xlnx kernel? Jun 16 14:41:35 nrossi: not sure what features linux-xlnx has that mainstream dont, but i'm using the fpga a lot (although I let the fsbl load it) Jun 16 14:43:06 nrossi: i'm fine with 3.14, but i'm trying to add a fixed eth phy for one of the zynq gems, and it seems like pre 3.16 can't do that through devicetree, and i would really like to avoid hacking/patching cadence macb driver Jun 16 14:43:27 mago_: There are a number of drivers that are not quite upstream yet. I suspect you may have dependence on them. If you want a stable kernel the 3.14 linux-xlnx kernel was the most well tested for the past few releases. Jun 16 14:43:55 mago_: fixed phy, you refering to a phy dt node? Jun 16 14:45:20 nrossi: no, i have connected gem1 to a fpga block and so there's no phy involved, it's just MII between gem1 and the IP block. In order to tell Linux this, i want to add a fixed phy saying it's a 100 Mbps full duplex link, and that the link is up Jun 16 14:47:26 nrossi: there's some stuff to do this in 3.14, such as drivers/net/phy/fixed.c, but it cannot be instanciated through a dt node. so you need to add code to your driver that calls this fixed_phy_add() function, and then later connect it to the mac Jun 16 14:47:32 which is really something i'd like to avoid Jun 16 14:51:03 mago_: is it not possible to have a fixed mdio bus, and then point the emac to the fixed phy's phandle? Jun 16 15:11:05 nrossi: yeah, that might work. haven't seen anyone do it that way though.. but assuming you can create both the fixed mdio bus and the fixed phy in dt, it should work. i'll give it a try, thanks Jun 16 15:12:18 mago_: im reading an old thread on the dt mailing list from 2013 which is talking about your usecase. I remember doing something a while back with the axi-ethernet driver, however i was setting the speed via ethtool at boot Jun 16 15:12:51 (my internet is very slow today... its taking a few minutes to load each email of thread :|) Jun 16 15:26:55 nrossi: but linux-xlnx 3.17 should work as long as i don't use the microblaze with linux? Jun 16 15:27:56 mago_: it should, at least for Zynq only stuff Jun 16 15:29:42 mago_: its the 'vivado' release tags that are less stable traditionally. The 'xlnx_*' branches are really just PetaLinux kernels :P Jun 16 15:31:00 nrossi: oh, okay. so meta-xilinx usually sticks with linux-xlnx master? Jun 16 15:34:14 mago_: Well going to try to push for linux-yocto as much as possible :), but that will take some time. But linux-xlnx recipes will move to a tracking master sort of approach, the old branches are not actually maintained by Xilinx for reference. Jun 16 15:34:34 okay, thats good to know Jun 16 15:35:20 i guess it makes sense to keep vivado and kernels in sync, otherwise the vivado devicetree generator (and maybe other stuff) will malfunction i suppose Jun 16 15:36:25 anyway, can't find a way of adding fixed mdio buses to the dt. i think it's time to give up for today :) will probably do some driver hacking tomorrow, just to make it work (tm). Thanks for your input nrossi Jun 16 15:36:34 mago_: mmm device tree generator.... never really trusted the output of that myself Jun 16 15:39:04 mago_: Once you get it sorted, i would be interested to know how. Cause i have a number of patches for the macb driver i want to upstream... and adding support for a fixed-phy would be worth doing :). Jun 16 15:41:36 nrossi: cool, although i think doing any modifications to macb that doesn't use the 3.16+ fixed-link stuff will not be accepted upstream Jun 16 15:41:53 but i'll look into it and get back to you. now -> hometime! laters Jun 16 16:31:26 * darknighte just realized that the ELCE submission deadline is tomorrow Jun 16 16:31:34 yup Jun 16 16:31:41 * fray submitted his talk today Jun 16 16:32:59 hehe Jun 16 16:33:23 fray: two days early! :) Jun 16 16:33:38 ya.. I only figured out the topic about 2 weeks ago Jun 16 16:34:07 (creating long-term sustainable binary distributions using oe/yp... focusing on problems and process around on-target package upgrades) Jun 16 16:34:19 we'll see if anyone cares... Jun 16 16:34:23 sounds interesting Jun 16 16:34:27 fray: hrmmm, I have been thinking about an update to my last YP talk from 2012/2013? geez, it's been a while. Jun 16 16:34:29 shame i likely can't make it :/ Jun 16 16:35:15 fray: good topic. update/upgrade path, in my experience, usually get left until the tail end of development with predictably bad consequences Jun 16 16:36:13 exactly.. there are things you need to think of from the beginning.. and a process you need to follow or you are going to get stuck holding the bag.. Jun 16 16:36:24 argh yes I knew there was something I was forgetting Jun 16 16:36:29 a large flaming bag of poo... Jun 16 16:37:42 * darknighte laughs himself sick while reading the last two lines together. Jun 16 16:39:12 haha Jun 16 16:40:31 rburton: indeed. comedy is in the timing, no? Jun 16 16:46:47 heh Jun 16 16:54:09 * Crofton|work should submit a talk on using oe-core and evolving into your custom distro layer Jun 16 16:54:49 that good be a good companion to mine.. since I'm focused on oe-core/yp + custom layers to create a binary distribution Jun 16 16:55:01 (I don't care so much about the contents of any of the layers) ;) Jun 16 17:04:46 my talk will be an update of my one at ELC... I know some folks missed it, hopefully it'll be useful and there'll definitely be new stuff to talk about Jun 16 17:04:58 (regarding developer workflow) Jun 16 17:05:01 bbl Jun 16 18:07:59 hm I guess there is no help in send-pull-request script to set the topic to patch v2 Jun 16 19:46:44 hi, what is standard method to create a non root user in yocto poky distribution? Jun 16 19:47:56 Looks like this grub gcc-5 fix can just be cherry-picked to fido: http://cgit.openembedded.org/openembedded-core/commit/meta/recipes-bsp/grub?id=7d79a7bfffbc39090b22bb7696cc5dbc832e49b6 Jun 16 19:48:57 bryan: http://www.yoctoproject.org/docs/1.8/mega-manual/mega-manual.html#ref-classes-extrausers **** ENDING LOGGING AT Wed Jun 17 02:59:59 2015