**** BEGIN LOGGING AT Thu Dec 13 02:59:58 2012 **** ENDING LOGGING AT Fri Dec 14 02:59:35 2012 **** BEGIN LOGGING AT Fri Dec 14 03:00:19 2012 Dec 14 10:14:35 nareshbhat: [PATCH] kexec-zImage-arm: add code to support --command-line along with --dtb Dec 14 10:22:02 hi Dec 14 10:27:39 hello there, any success with your cmdline options? Dec 14 10:37:16 ant_work: no :( Dec 14 10:38:48 which is above patch can you give me the commit ID ? Dec 14 10:44:16 is on the mailing list Dec 14 10:46:55 ok Dec 14 10:47:29 is it a kernel patch ot kexec-tools patch ? Dec 14 10:47:59 latter Dec 14 10:48:47 http://lists.infradead.org/pipermail/kexec/2012-December/007526.html Dec 14 10:50:21 oops ..yesterday pushed it ? Dec 14 10:50:54 no, I don't see it yet http://git.kernel.org/?p=utils/kernel/kexec/kexec-tools.git;a=summary Dec 14 10:51:16 hopefully will be in v2.0.4 final Dec 14 10:51:51 the patch http://lists.infradead.org/pipermail/kexec/2012-December/007526.html belongs to kernel right ? they have pushed it yesterday Dec 13th 2012 Dec 14 10:54:23 this patch is for userspace Dec 14 10:55:32 ok great, I can tryout this patch Dec 14 13:51:50 ant_work: Hi Dec 14 13:52:53 I don't understand "Sven Neumann" on which target he used, which kernel he used for testing. You have any idea ? Dec 14 13:57:57 well, I tagged one of his previous mails Dec 14 13:57:58 http://lists.infradead.org/pipermail/kexec/2012-November/007414.html Dec 14 13:58:36 seems he was testing --atags on arv5tel on kernel 3.04 when he wrote that Dec 14 13:58:54 but now he's testing --dtb Dec 14 14:11:05 ant_work: thanks..I sent a e-mail to him Dec 14 14:12:16 ant_work: I am using latest 3.4.22 kernel Dec 14 14:22:34 I am executing the following command Dec 14 14:22:50 kexec -f zImage --dtb=vexpress.dtb --append="root=/dev/nfs rw ip=dhcp nfsroot= console=ttyAMA0,38400n8" Dec 14 14:22:56 is that correct ? Dec 14 14:23:09 seems so Dec 14 14:23:50 is there anything specific I should enable/disable in kernel ? Dec 14 14:24:33 only in the launcher kernel, you need kexec syscall Dec 14 14:24:37 CONFIG_KEXEC Dec 14 14:24:54 I have enabled it in kernel Dec 14 14:24:58 ok Dec 14 14:29:16 ant_work: It looks like PROC_DEVICETREE also required, and THUMB2_KERNEL disable Dec 14 14:35:30 patch is now applied Dec 14 14:36:21 (63 mins ago) Dec 14 16:31:08 nareshbhat: good luck Dec 14 16:31:09 bbl Dec 14 17:16:46 jay7x: How about we clean up kexecboot source tree a bit? i was thinking we should put *.[ch] into src/ directory Dec 14 18:11:10 dromede_: why not Dec 14 18:11:50 ok, i'll deal with that Dec 14 18:11:54 now, about immediate_boot Dec 14 18:12:16 currently it will only abort the boot sequence and show the menu if you press KEY_LEFT Dec 14 18:12:30 as you said this should be expanded to support all keys that we check in evdevs.c Dec 14 18:13:07 the problem is, if we check for KEY_ENTER for instance, the input buffer will be filled with KEY_ENTER keys Dec 14 18:13:40 and then when we show the menu, the event loop will gladly take these from the input buffer Dec 14 18:13:51 same goes for KEY_UP and KEY_DOWN Dec 14 18:14:22 why input buffer will be filled? Dec 14 18:14:51 do you have some special check? not like other keys? Dec 14 18:16:14 a key needs to be held down so we can check if it is pressed just before we show the menu Dec 14 18:16:26 if a key is pressed - we abort immediate boot and show the menu Dec 14 18:16:36 if not, we boot the kernel immediately Dec 14 18:17:01 well, you may flush input Dec 14 18:17:22 how? Dec 14 18:17:28 but I'd prefer to have same routine to check keypresses Dec 14 18:18:30 dromede_: https://github.com/kexecboot/kexecboot/blob/master/util.c#L296 Dec 14 18:20:00 i see two ways of checking keypresses Dec 14 18:20:33 either you hold the key down at the same time the check is running Dec 14 18:21:08 or you monitor the inputs constantly; this requires and event loop am i right? Dec 14 18:21:38 s/and/an/g Dec 14 18:28:13 i dont know, i'll just implement detection of all those keys and we'll see how i works Dec 14 18:28:49 dromede_: yes, waiting for keypress need loop Dec 14 18:29:26 that is why I'm talking about try to reuse same code Dec 14 18:29:53 hmmm Dec 14 18:31:24 int inputs_process_evdev(int fd) Dec 14 18:31:39 right Dec 14 18:32:10 but you need to move all input layer initialization to start of main() Dec 14 18:32:15 before UI init Dec 14 18:32:21 i didn't consider that function since i thought that inputs would be initialized later than i needed them Dec 14 18:32:32 i'll try Dec 14 18:33:15 https://github.com/kexecboot/kexecboot/blob/master/kexecboot.c#L1085 Dec 14 18:33:32 here is input_init() and company :) Dec 14 18:34:05 so you may want to move it upper Dec 14 18:34:53 but you need to move build_menu() call as well then Dec 14 18:35:17 this all have one drawback Dec 14 18:35:47 you can't show progress to user Dec 14 18:37:18 build_menu may take some time (long time in case of broken jffs e.g.) Dec 14 18:38:03 ah no, not build_menu but scan_devices() Dec 14 18:40:27 so I'd prefer to initialize UI and then show some message like "press any key to choose kernel" and timer Dec 14 18:40:40 but then it's more like autoboot feature we already have Dec 14 18:40:54 but just w/o menu Dec 14 18:45:35 i can't use input_process or input_process_evdev since they both block and wait for input Dec 14 18:45:55 and that completely defeats the point of immediate_boot Dec 14 18:46:22 now that you mention it, autoboot might be a better name for this feature :) Dec 14 19:16:45 they wait for timeout Dec 14 19:17:00 check select() call Dec 14 19:17:06 last argument Dec 14 19:17:16 iirc, there should be about 1 second Dec 14 19:18:00 or at least I've thought about setting timeout to 1 second to realise autoboot time indication Dec 14 19:18:17 s/realise/make/ Dec 14 19:38:02 i came up with a different solution; i simply check for _any_ kind of input on _all_ devices where fdtypes[i] == KX_IT_EVDEV is true Dec 14 19:38:20 this works on my workstation and on my akita Dec 14 19:38:26 but it doesn't seem to like my mouse Dec 14 19:38:39 i get inconsistent results when i try to detect mouse input Dec 14 19:38:47 but keyboards and touchscreen work fine Dec 14 20:30:52 dromede_: so, don't you want to initialize UI at all? Dec 14 20:31:44 just silent boot first kernel Dec 14 20:34:03 UI is initalized Dec 14 20:34:12 autoboot just doesn't go to do_main_loop Dec 14 20:35:27 here's the patch: Dec 14 20:35:29 http://pastebin.com/1eF5vcrk Dec 14 20:36:21 take a look at kexecboot.c changes **** ENDING LOGGING AT Sat Dec 15 02:59:58 2012