**** BEGIN LOGGING AT Sat May 04 02:59:58 2013
May 04 11:23:25 <jkroon> Hi. I'm using a Beaglebone, together with a custom "cape" which is a LCD-monitor, building a Linux-system using OpenEmbedded. If I understood correctly, I need to create a devicetree entry for the LCD monitor, specifying that the kernel should use the tilcd,panel driver, and that it should claim some of the IO pins. My question is, if I create this .dts-file, compile it into a .dtb-file, is it possible to append this data during boot ?
May 04 11:23:50 <jkroon> I'm using u-boot
May 04 13:37:26 <jkroon> When building an image, can I add a rule so that "deply" command is performed on relevant packages too ?
May 04 13:37:39 <jkroon> s/deply/deploy
May 04 14:22:39 <silviof> jkroon: what do you mean with append the dtb? Have you read the bootm-entry from DULG? http://www.denx.de/wiki/DULG/UBootCmdGroupExec
May 04 14:23:59 <jkroon> silviof, I think the kernel I'm using has a dtb already compiled into it, I wonder if I can append more dtb's from u-boot, so that they will get picked up by the kernel
May 04 14:24:06 <jkroon> silviof, thanks for the link, reading..
May 04 14:30:03 <silviof> well - jkroon you can join the u-boot channel and ask this question to this channel - it is more uboot specific :)
May 04 14:31:12 <jkroon> silviof, yeah... just thought maybe there was an "OpenEmbedded"-way of appending dtb's
May 04 19:19:07 <nerdboy> okay, looks like the rpi "userland" recipe needs some help...
May 04 19:20:58 <nerdboy> building a custom xfce image yields the "Multiple .bb files ..." error between the regular mesa recipe in meta and the rpi broadcom stuff
May 04 19:35:54 <nerdboy> i added the rreplaces/rconflicts stuff to userland but it doesn't seem to help...
May 04 19:38:28 <bluelightning> nerdboy: is this an error or a warning?
May 04 19:38:59 <nerdboy> error, but one of the few that's not fatal
May 04 19:41:19 <nerdboy> http://paste2.org/6kgKAzeI
May 04 19:42:04 <bluelightning> nerdboy: I wonder if something explicitly depends upon mesa
May 04 19:44:14 <nerdboy> i had to had the gnome/xfce layers to rpi and meta-oe
May 04 19:48:04 <nerdboy> http://paste2.org/UaXJAN3H  <= updated
May 04 19:49:24 <bluelightning> nerdboy: I think the problem might be that something that needs virtual/libgl or virtual/libgles1 is being requested
May 04 19:49:31 <bluelightning> which userland does not (and cannot) provide
May 04 19:49:42 <bluelightning> thus it can only resolve the situation by building mesa
May 04 19:52:32 <bluelightning> so the question then would be what is it that needs either of virtual/libgl or virtual/libgles1 ?
May 04 19:53:32 <nerdboy> the mesa-common.inc in meta has a PROVIDES = "virtual/libgl virtual/libgles1 virtual/libgles2 virtual/egl"
May 04 19:53:37 <bluelightning> right
May 04 19:53:49 <bluelightning> one quick way to find out would be to set COMPATIBLE_MACHINE_pn-mesa = "none" in your local.conf
May 04 19:54:11 <nerdboy> so it can't just provide just the first two?
May 04 19:54:29 <nerdboy> and let userland provide the other two?
May 04 19:54:39 <bluelightning> I don't think that's going to work
May 04 19:55:05 <bluelightning> this situation *is* a bug
May 04 19:55:17 <bluelightning> but the proper way to fix it is to stop mesa from needing to be built
May 04 20:06:40 <nerdboy> nothing i can grep depends on mesa
May 04 20:11:44 <bluelightning> nerdboy: can you try COMPATIBLE_MACHINE_pn-mesa = "none" as I suggested above?
May 04 20:27:37 <nerdboy> it's xorg-server-1.14
May 04 20:28:12 <nerdboy> lookslike maybe only the older TI mesa/xorg stuff works in their layer...
May 04 20:34:57 <bluelightning> nerdboy: probably something to post on the mailing list about I'd suggest
May 04 20:35:02 <bluelightning> gotta go
**** ENDING LOGGING AT Sun May 05 02:59:58 2013