**** BEGIN LOGGING AT Fri Nov 13 02:59:59 2015 Nov 13 07:48:42 hi all. In my embedded device, one of the requirements is fast boot time. For this reason, I am thinking about hibernating/suspending ram. Could anyone tell me if this is possible with oe? Nov 13 07:51:43 dol: OE is a build system, not a distribution. so basically theres no reason it should either be possible or impossible Nov 13 07:53:15 LetoThe2nd, I know, I just wanted to know if it is commonly done using oe. I don't want to be the first one who is trying to achieve this Nov 13 07:55:13 dol: i'd be more focusing on the actual hardware platform in use. if somebody has done it there, it can always be poured into some kind of recipe. Nov 13 07:56:08 LetoThe2nd, it's an AMD based platform, so I guess it souldn't be a problem. Nov 13 07:56:14 actually I am now choosing the storage device and trying to calculate how long it will take to suspend the ram. I have 4GB memory and my current storage device has 80 MB/s capability. In this calculation, I end up 50 seconds, I find it a bit high. Nov 13 07:57:16 well without being a powersaving expert, that sounds like the worst case basically. form my understanding, things like caches etc. don't need to be hibernated. Nov 13 07:57:57 ok, so you mean it should take shorter in practice Nov 13 07:58:27 dol: and "AMD based" also doesn't mean that much, i'd really look into everything involved, especially the chipset, and ver very especially anything usb-related. Nov 13 07:58:48 why usb-related? Nov 13 07:59:10 because usb device standby-resume can the the absolute PITA. Nov 13 07:59:53 and if you use something usb that has a crappy driver, it will just break your suspend-resume, or be disfunctional after. no gain then in picking faster storage :) Nov 13 08:00:07 haha :) Nov 13 08:00:24 * LetoThe2nd was not joking at all. Nov 13 08:01:15 currently I use slc type of SATA DOM and it seems quite fast but there are even faster ones Nov 13 08:01:26 so I was wondering if I should go for them or not Nov 13 08:02:11 boot to UI has been demonstrated repeatedly in <5s Nov 13 08:02:42 depending on the definition of UI, but basically true Nov 13 08:02:55 tbr, 5 seconds is very promising. in my case it is about 1 minute : Nov 13 08:02:56 :0 Nov 13 08:03:21 sure if your app needs to do expensive memory setup and other crap, it might take minutes Nov 13 08:03:24 huh? Nov 13 08:03:52 I have init.d scripts which initializes everything one by one Nov 13 08:03:56 and that takes some time Nov 13 08:04:10 and there is dependency between some services too Nov 13 08:04:12 yeah, with sequential, no way Nov 13 08:04:16 i suspect you can easily bring up the core system in <20seconds without massive invest in infrastructure and optimization. the rest ist up to your application. Nov 13 08:04:33 tbr, is there any parallel way? Nov 13 08:04:37 and with core system, i don't mean a sequential 80s-style init. Nov 13 08:04:52 dol: you mean like.... systemd? Nov 13 08:04:59 *JEHOVA* Nov 13 08:05:03 :) Nov 13 08:05:24 LetoThe2nd, I am quite new in embedded development, so I don't know what is state-of-the-art Nov 13 08:06:31 can you share a source where I can read up about fast booting or state-of-the-art booting mechanism? Nov 13 08:06:47 dol: um.. its really not like systemd is embedded specific, nor is it new. it more like, being kind of general knowledge in the last 3 years. Nov 13 08:07:12 even debian uses it by now :) Nov 13 08:07:33 and your avarage yöp build too Nov 13 08:07:35 so, systemd is my remedy? is this what you mean? Nov 13 08:07:48 it's one part of the puzzle Nov 13 08:07:57 dol: i'm saying that its the most obvious part to look at. Nov 13 08:08:05 I see Nov 13 08:08:05 turning off bootloader delays is another Nov 13 08:08:27 ok then I will read about systemd Nov 13 08:08:44 ripping out that crappy sata controller who takes 30seconds to init itself to the bios is even one more nice way. Nov 13 08:09:02 (generally speaking) Nov 13 08:09:09 so basically, "it depends"" Nov 13 08:09:23 .oO(on your definition of) Nov 13 08:09:43 well, I see that getting IP address is taking quite some time during boot. and there is no need to wait for getting IP during boot. Nov 13 08:10:49 ok. let me read a bit and come back later with more info :) Nov 13 08:10:50 thanks all Nov 13 09:07:36 khem: just rememembered that I forgot the linux-driver-package patch in Jetson that I started. Nov 13 09:07:57 I think it's an important fix, but I don't know how to do it. Nov 13 09:08:13 these are my changes: http://pastebin.com/8mktYhEh Nov 13 09:09:18 it's the postprocess step that modifies ld.so.conf I don't know how to solve properly Nov 13 11:28:36 new topic: systemd-resolved issues. anyone seen stuff like this before? http://pastebin.com/94R43XYp Nov 13 12:33:21 would anyone object to autotools.bbclass passing —enable-maintainer-mode on the off-chance that upstream is stupid and uses AM_MAINTAINER_MODE Nov 13 13:06:44 rburton: sounds sensible to me... there's surprisingly many projects that use it though (even if not counting "AM_MAINTAINER_MODE([enable])") Nov 13 14:12:33 koen: what do you think of adding http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-edison/tree/utils/flash/ifwi/edison to your https://github.com/koenkooi/meta-edison to build flashable images? Nov 13 14:12:55 afaict they are under MIT license as it's the only COPYING file in their repo Nov 13 14:50:52 rburton: do we actually want maintainer mode? iirc that just adds the rules to regenerate the files we already generate, no? e.g. re-run autoconf when configure.* changes? Nov 13 14:51:09 hmm Nov 13 14:51:36 that's not what it does Nov 13 14:52:02 AM_MAINTAINER_MODE in the autoconf *disables* the rules to rebuild makefiles and other stuff as required Nov 13 14:52:25 if a rebuild is needed it silently skips it Nov 13 14:52:28 which is less than helpful Nov 13 14:52:57 if someone has that in their configure you need to —enable-maintainer-mode to get the rules back again Nov 13 14:53:06 (of course that then makes binutils fail to configure) Nov 13 14:57:02 funman: it's on my TODO, but don't hesitate to send a patch Nov 13 14:57:52 ahh Nov 13 15:00:35 koen: great, will work on it **** ENDING LOGGING AT Sat Nov 14 02:59:59 2015