**** BEGIN LOGGING AT Mon Sep 22 03:00:00 2014 Sep 22 06:48:51 good morning Sep 22 06:49:07 gm Sep 22 06:52:08 howdy Sep 22 08:13:28 morning all Sep 22 08:23:45 hi bluelightning Sep 22 08:23:59 hi mckoan Sep 22 08:25:24 hi bluelightning Sep 22 08:25:31 hi woglinde Sep 22 09:40:08 how can I list the licenses used for a deployed image? tmp-eglibc/deploy/licenses only lists per-recipe Sep 22 09:55:00 oh, nevermind. found the image-recipe-folder in licenses holds exactly what I need! Sep 22 10:11:48 mago_: you should find a directory there for the image as well Sep 22 11:51:31 Hello All Sep 22 11:52:24 Can i get glibc_2.11.3x bb files on web? Sep 22 11:53:15 Hi Sep 22 11:53:49 I want to use glibc-2.11.3 version....can i get recipes for this version? Sep 22 11:54:01 with patches Sep 22 12:16:24 bryan_: you keep asking this question but it's rather unlikely you will get a different answer than the one already given Sep 22 12:41:43 what is the most common watchdog setup when using embedded Linux? it seems like 99% are using the built-in wdt which is available in the SoC. During the boot process, you either keep the WDT off, or you set a really long timeout. Once the system is up, you let a userspace app configure a shorter timeout and then periodically kick it. What if your customers biggest fear is that runaway code (or a hacker) could bypass the WDT and wants a WDT which ca Sep 22 12:41:44 nnot be controlled from software (other than kicking it). How would you deal with the situation? With an external watchdog (and a fixed timeout), you'd have to kick it from both U-boot and Linux, and you probably have to do it several times during boot (in non-standard places), before the userspace takes over. It also seems like Linux requires that all WDT drivers implement a start & stop function, which would not be possible in this case. Is an e Sep 22 12:41:44 xternal non-controllable WDT a really poor design for Linux systems? Sep 22 13:25:48 Hi Sep 22 13:26:51 I am new to OE porting on ARM. So i have few questions. Hope some of you guys can answer Sep 22 13:27:12 mago_, well it depends on your watchdog needs Sep 22 13:27:26 How do we sign kernel and BL for a ARM SOC ? Sep 22 13:27:39 rob_w, basically detect runaway code Sep 22 13:27:39 if you dont want it , dont use it, if you have sec issues then revise your sec requirenments Sep 22 13:27:55 mago_, u mean cpu eaters ? Sep 22 13:28:18 rob_w, yeah, or something that would make the system unresponsive Sep 22 13:29:10 well so i want high end featured watchdog, doubt that you get a external wdg with ip ping or such Sep 22 13:29:14 or cpu load tests Sep 22 13:30:17 well, you can still do the checks in software. the only difference with a external "dumb" watchdog is that you cannot stop it, and you cannot change the timeout period. Sep 22 13:30:23 S_A, well u talking about a new SOC ? Sep 22 13:30:56 linux kernel watchdogs do have nowayout features ,, Sep 22 13:31:34 so once fired , you might never disable it again Sep 22 13:32:19 and "external" is relative here Sep 22 13:32:39 i rather want to use the CPU / SOC own watchdog then a simple one Sep 22 13:32:45 rob_w, only if enabled with the CONFIG_ option. The problem is really the boot up sequence (before Linux comes online). A dumb watchdog will require frequent kicking from the second the system is powered, with a more configurable watchdog you can instead have a long timeout during boot, and then shorten the delay once system is up and operational Sep 22 13:34:01 well you need to stretch over the acutal kernel load after init your free to kick it anytime in userspace Sep 22 13:34:29 if that is even not enough, feel free to hack the kernel directly ;-) Sep 22 13:34:33 rob_w: Exynos SoC Sep 22 13:35:53 S_A, did you get your head around oe / poky etc already ? Sep 22 13:36:30 i am sure you can find a conf/machine/ANYOTHER.conf and base your work around that Sep 22 13:38:06 mago_, i cant see the security problem directly .. if the system is compromised already then the wdg is not in charge anyway Sep 22 13:39:02 rob_w, yeah, thats basically the problem. if it needs to stretch over the entire kernel load (and bootloader stuff), we could be looking at up to 15s or something. Sep 22 13:39:18 rob_w: yes. I did see it & in the process of building it. It will produce a kernel and rootfs. But will it give me signed uboot or signed kernel ? Sep 22 13:40:02 S_A, dunno about "signed" but basicly yes Sep 22 13:40:28 mago_, do you feel 15s to be long ? Sep 22 13:40:30 rob_w: i guess I will need to sign them manually for secure booting Sep 22 13:40:55 rob_w, there seems to be very few external watchdogs with a fixed delay that support this long timeout (most are <1s) Sep 22 13:41:37 a omap watchdog supports upto 30s for example Sep 22 13:42:16 those feel to be devices designed for microcontrollers or such Sep 22 13:45:05 mago_, also i cant imagine a wdg with <1s in a linux system, when you mentioned higher functions, like ping tests, or cpu load tests, Sep 22 13:45:44 rob_w, ok, thanks. i think you more or less confirm my thoughts on this aswell Sep 22 13:46:21 well glad help Sep 22 13:46:36 while waiting my kernel git to sync Sep 22 16:26:16 morning Sep 22 17:06:28 hello, I have this ZTE MF93E (R212 Vodafone) 4G hotspot with "OpenEmbedded Linux 9615-cdp", and I want to check the battery state from the command line. How can i get the battery information? I cannot find anything relevant in /sys or /proc Sep 22 19:27:31 hi Sep 22 20:07:48 i need to build a plugin that depends on the sources of another package, so i have two recipes, but i don't know how one recipe can access the source code of another one, any idea ? Sep 22 20:09:55 hm just checkout the source again Sep 22 20:10:10 see other recipes which handles two sources Sep 22 20:11:26 hm to have the versions in sync you could require plugin-1 and than overwrite each VAR maybe some needs to be set empty Sep 22 20:11:35 woglinde, i thought about it, but how can i guaranty that both recipe will use the same version of the sources ? Sep 22 20:11:51 than use SOURCES_LIST += to add the sources of your plugin Sep 22 20:11:52 2 Sep 22 20:12:47 try as I said require and override with VAR = Sep 22 20:12:56 except SOURCES_LIST Sep 22 20:13:23 i don't get it :) Sep 22 20:13:37 or if you have the recipes in one dir Sep 22 20:13:46 make a sources.inc of plugin-1 Sep 22 20:13:54 ha Sep 22 20:13:56 and require this in each other recipe Sep 22 20:14:27 but if you do that you break the PN versioning in sources.inc Sep 22 20:14:40 both packages does not have the same version number Sep 22 20:14:54 and? Sep 22 20:15:53 and that sucks :) Sep 22 20:15:58 or i did not get it Sep 22 20:16:57 version is comming from the .bb Sep 22 20:17:12 just try out what I said Sep 22 20:17:53 or maybe best is to manually sync the versions Sep 22 20:20:09 :/ Sep 22 20:21:39 let me rephrase, let's say i have daemon_1.0.bb and daemon-plugin_0.2.bb... your idea is to write source.inc that contains daemon SRC_URI to a fixed version and require this .inc in both .bb ? Sep 22 20:22:28 yes Sep 22 20:24:09 that could be funny if daemon_1.0.bb requires sources-${PN}.inc and daemon-plugin_0.2.bb requires sources-1.0.inc Sep 22 20:24:16 but it looks a bit messy Sep 22 20:29:44 anyone familiar with X/matchbox? Sep 22 20:30:00 how can i tell it to reverse the usb mouse in L/R direction Sep 22 23:26:07 hmm Sep 22 23:26:16 I think I need qtsvg **** ENDING LOGGING AT Tue Sep 23 03:00:00 2014