**** BEGIN LOGGING AT Thu Sep 13 03:00:00 2012 Sep 13 06:25:42 prahal2: I have no idea, this is some ubuntu build Sep 13 06:26:28 prahal2: aha, that patch should have been sent upstream to git.openmoko.org Sep 13 06:31:02 PaulFertser: can you pull https://github.com/shr-distribution/meta-smartphone/blob/shr/meta-openmoko/recipes-bsp/qi/files/0001-start_qi-add-include-for-stddef.h-with-gcc-4.7.1-it-.patch to git.openmoko.org qi repo? Sep 13 06:31:18 bbl Sep 13 06:32:44 prahal2: http://build.shr-project.org/tests/jama/bootchart/ Sep 13 06:32:59 prahal2: you need few kernel options to get usable bootchart Sep 13 10:25:53 lindi-: sure thing, will do it tomorrow, or is it urgent? Sep 13 10:34:54 lindi-: since gprs is good enough here just tried, alas git push ssh://git@git.openmoko.org/qi.git master:master gives me an error, fatal: The remote end hung up unexpectedly Sep 13 10:35:27 Probably i've forgotten how to properly push there... Sep 13 10:36:54 Or my key was purged/deactivated (due to server upgrade etc). Sep 13 10:48:01 hey PaulFertser Sep 13 10:48:48 mickey_office: having more time again it seems. Hired enough people to be CTO and just do community research? ;) Sep 13 10:51:44 PaulFertser: not urgen Sep 13 10:52:05 PaulFertser: but would be nice so that people don't need to find the solution themselves again and again Sep 13 10:52:22 stefan_schmidt_w: not yet… but working on it ;) Sep 13 10:52:44 mickey_office: great :) Sep 13 10:53:02 mickey_office: any chance you will bet at ELC-E this year? Sep 13 10:54:26 stefan_schmidt_w: unfortunately not. i was three days away for SmartDevCon recently and will be two more days away for Munich OpenHardware/Software workshop. That's about all I can do for this year. Sep 13 10:54:41 (considering Lara Marie is still so small… later on i can take her with me, but not now) Sep 13 10:55:20 mickey_office: yeah, that is why I wrote by any chance. Its not clear here for me either yet. Sep 13 10:55:34 mickey_office: To bad. But we will see each other at some point again. :) Sep 13 10:56:52 definitely Sep 13 12:06:26 mickey_office: any idea if i should be able to push to git.openmoko.org that way? Sep 13 12:06:32 mahi :) Sep 13 12:06:41 mickey_office: meant hi :) Sep 13 12:07:09 sorry, i lost connection in between. which way? Sep 13 12:07:50 git push ssh://git@git.openmoko.org/qi master:master gives me an error, fatal: The remote end hung up unexpectedly Sep 13 12:11:40 hmm… it's been ages i used that. i'm afraid i have no idea Sep 13 12:11:52 who's maintaining that these days? Sep 13 12:31:51 damn, something's broken wrt connectivity here Sep 13 15:51:24 mickey_office, hi Sep 13 15:51:48 hi Sep 13 15:52:13 do you prefer smartphones or features phones? Sep 13 15:52:51 because with aurora and such you seemed to prefer features-phones Sep 13 15:54:56 (there are projects to have free as in freedom features phones) Sep 13 15:57:53 good question. it depends. while i love the many things you can do with smartphones, there are many times when i wish i had a feature phone. One of the fundamental ideas when thinking about aurora development was that feature phones would be a lower hanging fruit to target, since smartphones are much more complex. Sep 13 15:58:29 i still would love to have a simple feature phone stack for everyday use Sep 13 15:58:37 composed out of free software Sep 13 15:58:40 ok Sep 13 15:58:54 do you know osmocombb? Sep 13 15:59:12 mickey_office: but finding a phone you could put it on would be impossible :) Sep 13 15:59:15 there are projects to port the layer2 and 3 on the target phone Sep 13 15:59:31 GNUtoo: That is to low for mickey_office :P Sep 13 15:59:41 that's what I fear..... Sep 13 15:59:42 lol Sep 13 15:59:44 stefan_schmidt_w is right Sep 13 16:00:00 don't get me wrong, i don't think i need to have a feature phone hardware just to put a feature phone stack on it Sep 13 16:00:05 i love a big touchscreen Sep 13 16:00:08 no problem with that Sep 13 16:00:08 :) Sep 13 16:00:10 ok Sep 13 16:00:11 mickey_office: heh Sep 13 16:00:24 there are 2 approaches for the feature phone thing: Sep 13 16:00:35 crippling devices. That remembers me of the infamous OM meeting October 07. Sep 13 16:00:49 The new marketing idea :) Sep 13 16:00:57 1) port layer 2,3 on top of layer1 in osmocombb and implement the scheduler etc...and the missing parts (malloc), it's beeing worked on not by me Sep 13 16:01:16 2) port everything to nuttx (I'm involved in it) Sep 13 16:01:58 GNUtoo: mickey_office wants something that use normal toolkits and kernels but just implements basic phone feature Sep 13 16:02:09 yes I understood Sep 13 16:02:13 Still linux but only one app from init doing all the work Sep 13 16:02:16 for example Sep 13 16:02:29 not going done to realtime OS directly on the baseband Sep 13 16:02:48 exactly. i'd be happy with something like that. either EFL or QML or whatever Sep 13 16:02:50 yes I feared that he wouldn't want to jump in the baseband world Sep 13 16:03:03 osmocom is impressive but _way_ to lowlevel for me Sep 13 16:03:15 little spare time means high abstractions wanted ;) Sep 13 16:03:31 mickey_office: you need to leave your comfort zone. I know you already wrote a led driver for ezx :) Sep 13 16:03:37 heh Sep 13 16:03:46 that's eons ago Sep 13 16:04:01 lol indeed Sep 13 16:04:11 I wrote an LCD driver for nuttx for instance.... Sep 13 16:04:31 mickey_office: so objective-c did overwrite all basic c knowledge? ;) Sep 13 16:04:42 stefan_schmidt_w: pretty much, yea :) Sep 13 16:04:47 ah ouch Sep 13 16:04:58 GNUtoo: yeah, but you love to tinker on the lower levels. mickey_office not Sep 13 16:05:06 ok Sep 13 16:05:09 GNUtoo: the thing is, if i ever dive into such a project again, i want to do something that has _really high_ probabilities to be in a useful state soon Sep 13 16:05:19 ok Sep 13 16:05:21 which means… really useful, like… using it day2day Sep 13 16:05:42 basically in the nuttx approach we have the c155 supported Sep 13 16:05:43 i don't think i have the energy to do again one or two years of hacking until anything works Sep 13 16:05:55 with the LCD,poweroff,spi,keypad etc... Sep 13 16:05:57 cool Sep 13 16:06:03 the keypad is not yet upstream tough Sep 13 16:06:26 someone will start to port layer1 soon Sep 13 16:06:33 enough joking, I call it a day. cu guys Sep 13 16:06:44 cu stefan_schmidt_w Sep 13 16:06:48 see you Sep 13 16:06:52 i like the framebuffer approach though ;) Sep 13 16:07:03 http://bb.osmocom.org/trac/wiki/nuttx-bb/drivers Sep 13 16:07:04 these days everything seems to move to openGL ES Sep 13 16:07:24 mickey_office: to be honest. I think you can stop that. Sep 13 16:07:39 and directfb does not keep up on the accel driver level Sep 13 16:07:50 I see no way around it. If one likes that or not. Sep 13 16:07:58 in replicant and SHR we have software compositing Sep 13 16:07:59 openGL or X? Sep 13 16:08:01 and it's fast enough Sep 13 16:08:15 never was really fond of directFB, the software Sep 13 16:08:17 mickey_office: opengl Sep 13 16:08:18 really, on galaxy nexus I don't see the difference Sep 13 16:08:26 it's so fast.... Sep 13 16:08:29 anyway, need to catch my train. cu Sep 13 16:08:32 cu Sep 13 16:08:35 ok, see you Sep 13 16:08:53 i'd like to see how our QML stuff runs on galaxy nexus Sep 13 16:09:01 I can try if you want Sep 13 16:09:03 on the pre it was pretty sluggy Sep 13 16:09:11 is there is an easy way to try? Sep 13 16:09:21 note that galaxy nexus is dual-core Sep 13 16:09:46 no idea offhand… do we have a target in OE-core to build a minimal image for the nexus? Sep 13 16:09:52 (or OE, which I'm more familiar with...) Sep 13 16:10:07 it boots SHR but lacks fso configs Sep 13 16:10:22 so you have ssh, xorg etc... Sep 13 16:10:49 camera is non-standard Sep 13 16:11:02 wifi, bluetooth,alsa works fine Sep 13 16:11:27 display also works fine Sep 13 16:11:57 it also works in replicant with telephony,wifi,bluetooth,display Sep 13 16:15:23 camera may spy(DMA+non-free firmware etc...) and is probably supported here: Sep 13 16:15:48 http://www.gitorious.org/gstreamer-omap Sep 13 17:35:18 hi Alex[sp3dev] Sep 13 17:35:26 do you know how to have UART serial from galaxy s2 ? Sep 13 17:36:05 paulk-desktop: just solder a 619K or 523K resistor between the OTG ID and GND Sep 13 17:36:21 ah ok Sep 13 17:36:26 these are not the values I was using Sep 13 17:36:47 paulk-desktop, maybe we could do that: a plugable resistor stuff on the bottom of the sparkfun connector Sep 13 17:36:59 and then we put a note on each resistor? Sep 13 17:37:04 like galaxy SII Sep 13 17:37:08 or nexus S? Sep 13 17:37:53 GNUtoo, actually I'm using a breadboard already Sep 13 17:37:55 so it's easy Sep 13 17:37:58 ok nice Sep 13 17:38:06 do you have pictures? Sep 13 17:39:07 I can take and upload some if you want :) Sep 13 17:39:16 also I added a log of galaxy s bootloader Sep 13 17:39:19 ok Sep 13 17:39:20 nice Sep 13 17:39:33 paulk-desktop: look what I have here http://pastebin.com/n0tPvkxR Sep 13 17:40:37 Alex[sp3dev], how's the partition map done? Sep 13 17:40:42 trough variables Sep 13 17:40:43 ? Sep 13 17:40:44 GNUtoo: GPT Sep 13 17:40:48 ok Sep 13 17:42:09 so what's the bootchain exactly: rom->xloader->uboot->l4? Sep 13 17:42:16 yes Sep 13 17:42:19 woww Sep 13 17:42:37 does uboot works without serial? Sep 13 17:42:41 actually I need to write the framebuffer init for uboot and port the usb-otg to genode.. Sep 13 17:42:44 GNUtoo: sure Sep 13 17:43:11 GNUtoo: it's a drop-in replacement for SBL. but you have to compile the kernel with forced fb reinit for now Sep 13 17:43:23 ah, that's all, wow Sep 13 17:43:39 what is signed on tuna/maguro? Sep 13 17:43:56 and how to load the code? Sep 13 17:44:04 GNUtoo: xloader is signed. you can't replace it therefore Sep 13 17:44:19 GNUtoo: well, I just dd it to /dev/block/something/by-name/sbl Sep 13 17:44:38 GNUtoo: in case we brick the device, there's OMAPFlash for windows which can flash xloader + sbl via usb Sep 13 17:44:55 I've no windows at all here..... Sep 13 17:45:36 does pserial works? Sep 13 17:45:39 what about pusb? Sep 13 17:46:03 GNUtoo: living in the world dominated by the economics of shit you have to use shitty hardware and software. I can't make my own SoC yet so I have to use OMAP and deal with it Sep 13 17:46:32 I meant, did you try pusb or pserial? Sep 13 17:46:34 GNUtoo: you have the device, go ahead and try. Didn't work for me. probably needs some signature and authentication Sep 13 17:46:43 ok Sep 13 17:48:01 omap4 framebuffer + dss + panel init is so complex. Too hard to write code for uboot. Maybe I should just pull the whole linux driver as is? Sep 13 17:48:19 barebox? Sep 13 17:48:56 barebox is essentially uboot. I mean, hardware initialization is complex and I don't really want to read TRM Sep 13 17:49:09 Alex[sp3dev], where's the code for uboot? Sep 13 17:50:15 https://github.com/Ksys-labs/uboot-tuna or look up my gitorious profile, there's a mirror there Sep 13 17:51:58 GNUtoo: one problem is that ram size is incorrectly initialized on tuna. I have hacked the uboot code in a dirty way. If you want to help me upstream uboot support, I'll take a look at it Sep 13 17:52:25 I'll try to load it first..... Sep 13 17:52:37 rebuild the kernel first Sep 13 17:52:42 ok Sep 13 17:52:57 there's no DFU, no fastboot. trash recovery and boot -> have to use windows to load sbl Sep 13 17:53:18 I want to make a combined binary Sep 13 17:53:21 for pusb Sep 13 17:53:21 you may want to edit the config to enable serial *input* Sep 13 17:53:37 because I've no serial.... Sep 13 17:53:47 I'm in France without a soldering iron.... Sep 13 17:53:51 you can edit the omap4_tuna.h and disable the SPL_BUILD define and you can flash uboot instead of kernel/recovery without erasing SBL Sep 13 17:54:00 ok Sep 13 17:54:24 I'll try to extract the normal bootloaders first Sep 13 17:54:30 and then try to load them trough pusb Sep 13 18:03:29 GNUtoo: did you sort out your userspace boot to slow ? Sep 13 18:03:43 no, not yet Sep 13 18:03:48 I was waiting for JaMa Sep 13 18:04:40 ok I proceed to phase out a way to do a partial boot bootchart then :) Sep 13 18:06:29 at least bootchart2 can be stopped in the middle of the boot . it needs fiddling but the only point left I have is how to tell systemd to stop it after a timeout (I use systmed timer ... the only issue left is how to stop the timer on success . Sep 13 18:07:44 ok Sep 13 18:07:58 then I might look into bootchart (1) if time permit (bootchart2 con is that it requires rebuild of the kernel to add a few features, but is faster Sep 13 18:08:26 ok Sep 13 18:33:32 k, on SHR `unstable` lite, by sending sms through python script i get this in /var/log/fsogsmd.log: Sep 13 18:33:32 2011-08-22T12:03:51.110510Z [WARN] libfsotransport <0710:2>: Timeout while waiting for an answer to '0011000D81007360875078F80000A70CF4F29C0E6A97E7F3F0B90C' Sep 13 18:33:50 any way to debug this? :< Sep 13 18:34:00 iface.SendTextMessage('0037067805878', 'test message', False) Sep 13 18:34:08 this is the line that sends sms in python script Sep 13 18:38:35 SHR: 03shr-devel 07buildhistory * rd97cdd4fea27 10/ (662 files in 662 dirs): packages: Build 201209130847 of shr 20120913 for machine nokia900 on opmbuild Sep 13 18:44:59 Alex[sp3dev], I found that: Sep 13 18:45:07 https://github.com/swetland/omap4boot Sep 13 18:45:41 it however fails to compile: Sep 13 18:45:57 trusted.S:10: Error: selected processor does not support ARM mode `smc 1' Sep 13 18:46:00 strange.... Sep 13 19:02:39 hmmm Sep 13 19:02:41 there is a fix Sep 13 19:02:46 https://github.com/swetland/omap4boot/issues/8 Sep 13 19:19:08 as advised I'll install another toolchain to compile uboot Sep 13 19:25:16 Alex[sp3dev], I'll try another compiler again: Sep 13 19:25:34 clocks.c:440:13: internal compiler error: in decode_addr_const, at varasm.c:2638 Sep 13 19:25:50 you're doin' it wrong then Sep 13 19:25:54 ah? Sep 13 19:26:06 make CROSS_COMPILE="arm-linux-gnueabi-" clean Sep 13 19:26:10 make CROSS_COMPILE="arm-linux-gnueabi-" distclean Sep 13 19:26:19 make CROSS_COMPILE="arm-linux-gnueabi-" omap4_tuna_config Sep 13 19:26:21 export ARCH=arm; export CROSS_COMPILE=$PATH_TO_TOOLCHAIN/bin/arm-none-eabi; make omap4_tuna_config; make Sep 13 19:26:21 make CROSS_COMPILE="arm-linux-gnueabi-" Sep 13 19:26:29 ahh ARCH=arm Sep 13 19:26:30 sorry Sep 13 19:26:31 weird Sep 13 19:26:42 well, ARCH should not matter.or maybe it does Sep 13 19:26:56 indeed it does Sep 13 19:27:08 same.... Sep 13 19:28:03 same.... Sep 13 19:28:11 the linaro ubuntu compiler is bad Sep 13 19:29:28 and it seems that export is not sufficent Sep 13 19:29:32 you must pass it stuff Sep 13 19:29:34 right? Sep 13 19:29:41 ah no Sep 13 19:30:06 it uses gcc at the beginning and arm-*-gcc after.... Sep 13 19:30:22 still the first error with the oe compiler Sep 13 19:35:11 http://pastebin.com/TP0DZXhS dunno, afair, linaro worked. I've just compiled with codesourcery btw Sep 13 19:36:01 I'm downloading official linaro toolchain Sep 13 19:36:45 I've also codesourcey Sep 13 19:39:37 it worked finally, let's try it on target now Sep 13 19:40:58 remembered to compile it as non-spl? Sep 13 19:42:00 http://pastie.org/private/pvdrhx7ixdjfmlqbv36jg Sep 13 19:42:04 no Sep 13 19:42:45 it won't work because you're using an HS device and unsigned images Sep 13 19:43:29 what if I try to use signed images Sep 13 19:43:35 like my extracted xloader? Sep 13 19:44:26 nothing, xloader is not expecting images over usb. Loading the proprietary bootloader from omapflash might work, but then you'll have to use its custom usb protocol to load xloader/sbl Sep 13 19:44:40 ouch Sep 13 19:44:53 I've tried that too Sep 13 19:45:00 but I don't know exactly what file to try Sep 13 19:45:09 there is a tuna dir Sep 13 19:45:20 well, I don't want to try it out right now Sep 13 19:45:46 sbl.img ? Sep 13 19:45:49 ok Sep 13 19:46:13 ah sorry Sep 13 19:46:17 maybe that one: MLO_4460_HS_PRO Sep 13 19:46:20 I'll try that Sep 13 19:46:28 either way I want to paravirtualize linux. I think if we don't have manpower to reverse proprietary binaries, then we should sandbox them. But running software from the 90s with the performance of the phones from the 2000 because of 'no blobs' is obscurantism Sep 13 19:48:08 you seem not to have tried crespo under replicant.... Sep 13 19:49:04 a system without opengl and dsp is irrelevant today for anything except internet browsing Sep 13 19:49:13 I'll try your work in some days then....because I don't have serial here and I will get it in some days Sep 13 19:49:28 again android without opengl is fast enough Sep 13 19:49:29 GNUtoo: no, MLO is not for usbloader. You see, there's the 'Configurations' dir. omapflash sets up SDRAM, clocks etc. then it loads the binary from 2ndloaders Sep 13 19:49:37 ok Sep 13 19:49:46 then, 2ndloader sets up usb transport with a custom protocol to upload xloader Sep 13 19:49:52 yes Sep 13 19:50:20 I'll have serial in some days Sep 13 19:50:23 well, we could sniff the usb traffic from omapflash Sep 13 19:50:27 ah right Sep 13 19:50:33 with wireshark 1.8? Sep 13 19:50:48 I've no windows here either Sep 13 19:51:02 with some windows crappy tool. wireshark under windows is pain. Sep 13 19:51:04 I'll have to wait for getting access to a not-mine windows computer.... Sep 13 19:51:06 ok Sep 13 19:51:34 does an embedded device works? Sep 13 19:51:36 for instance: Sep 13 19:51:56 windows with USB->beagle board with some tool->the phone Sep 13 19:52:31 what's the point? Sep 13 19:53:26 to sniff it on beagle board so it's less a pain? Sep 13 19:53:42 there is a project to do that if I remember well Sep 13 19:54:22 the problem is that you like to talk too much and come up with complex solutions for simple problems. Let me just make a dump right now Sep 13 19:54:52 I don't know how to sniff USB under windows so I say wrong things, that's all Sep 13 19:55:21 the problem is that adding a beagleboard proxy will likely make everything fail because of timings Sep 13 19:55:57 ah right Sep 13 20:08:29 GNUtoo: http://rghost.ru/40350170 Sep 13 20:10:04 doesn't seem to be complet for some reason. or maybe it is complete. dunno Sep 13 20:11:09 ok Sep 13 20:12:34 thanks a lot Sep 13 20:16:45 I'll go bye Sep 13 20:19:25 SHR: 03shr-devel 07buildhistory * re1be695244ed 10/packages/om_gta04-oe-linux-gnueabi/ (11 files in 11 dirs): packages: Build 201209132053 of shr 20120913 for machine om-gta04 on opmbuild Sep 13 21:04:03 I wonder what is the cause of not supporting init= in qi via append-GTA02 ... Sep 13 21:04:23 or if there is a way/need to fix that Sep 13 21:08:39 prahal2: what support does it need? Sep 13 21:09:09 currently to bootchart one has to flash qi-bootchart Sep 13 21:09:29 prahal2: why? Sep 13 21:10:10 because init=/usr/sbin/bootchartd cannot get passed to qi to feed the kernel commandline Sep 13 21:10:17 otherwise Sep 13 21:10:49 prahal2: why not? Sep 13 21:11:03 that s the question :) Sep 13 21:11:20 prahal2: how does it fail if you do that? Sep 13 21:11:33 it simply does not call bootchartd Sep 13 21:11:52 even if one add init=/usr/sbin/bootchartd to /boot/append-GTA02 Sep 13 21:12:10 I bet qi parse the file and does not support the init= token Sep 13 21:12:45 so qi-bootloader way to get this init=/usr/sbin/bootchartd is to replace the default command line in qi code Sep 13 21:13:35 I am merely asking if there is a cause to this lack of support of init= (ie I see none at leastsecurity wise, but I am still new on the battlefield) Sep 13 21:14:45 the current fix means either we flash a qi that calls bootchartd always or one that never calls it Sep 13 21:16:37 lindi-: btw ... what did you think of my idea that maybe the use of variables to hold the stack and registers into the fqi code might not be that specific to the stackoverflow code I used ? Sep 13 21:16:57 ie if this is not an issue I could send the new fiq assembly code as is Sep 13 21:18:00 fiq code Sep 13 21:18:10 prahal2: qi does not parse it Sep 13 21:18:55 ok then the issue might be as easy as to remove init=/sbin/init from default commandline Sep 13 21:19:17 prahal2: can you tell me what happens if you cp /sbin/init /sbin/init2 and then boot with init=/sbin/init2? Sep 13 21:19:19 it is the default after all Sep 13 21:20:04 it won't work ... there is a hardcoded init=/sbin/init ... I will remove the hardcoded init=/sbin/init and it should be good to go Sep 13 21:20:06 prahal2: I'm not quite sure what the deal with the fiq code was. were you trying to upstream the c fiq support? Sep 13 21:20:14 prahal2: what does "won't work" mean? Sep 13 21:20:45 I mean qi tells the kernel init is at /sbin/init ... if I move it , it will not be found by the kernel Sep 13 21:21:04 oh sorry I misread Sep 13 21:21:08 prahal2: so what does dmesg show after boot? Sep 13 21:21:20 ie I will try Sep 13 21:24:05 reboot in progress . about the fiq code ... I was merely doing this work to get a backtrace and fix the underlying issue (what was the code that was doing a printk under fiq context Sep 13 21:24:36 but it turned out it worked better than expected (I got a full backtrace of the issue , even if it happend in fiq context Sep 13 21:26:30 so I believe this is useful. Otherwise I am not even confident fiq c code is such a good idea ... Maybe a fiq tagged "c subset - really we mean subset" Sep 13 21:27:18 prahal2: ok Sep 13 21:27:27 prahal2: I'm mostly interested in getting stuff upstreamed Sep 13 21:27:35 ie it stress the kernel api machine specific low level layers which is good ... with the new fiq c code giving a backtrace it is remotely usefull as a debug tool Sep 13 21:28:32 but it cannot be included as is and people expect it to work (even if they follow the guidelines ... because it turns out any calls that ought not to schedule ... do schedule Sep 13 21:31:02 it turns out gpio stuff for samsung platform is quite layered so it is really tricky to find out the base addresses and such if one want to implement a fiq handler in assembly . So a "c" fiq handler is good ... Sep 13 21:34:49 I believe for to upstream the c fiq support ... one have to talk to the developpers of the other implementations : the gnu; the partial c one from amstrad already upstreamed Sep 13 21:35:37 ie kernel maintainers tends to avoid code that duplicate functionality Sep 13 21:36:13 prahal2: yep Sep 13 21:36:28 SHR: 03shr-devel 07buildhistory * r993c9707a2a2 10/packages/crespo-oe-linux-gnueabi/ (11 files in 11 dirs): packages: Build 201209132229 of shr 20120913 for machine crespo on opmbuild Sep 13 21:36:32 if at the same time it can serve as basis for other external implementation to get included too ... I bet it is a straightforward "yes" from maints Sep 13 21:38:27 the "gnu" one : http://www.gnudd.com/sw/fiq-engine.html Sep 13 21:39:09 might be too bloated for kernel inclusion ... though if we could let it use our jump to c code that would help Sep 13 21:50:56 about qi and init= : "Kernel command line: loglevel=4 console=tty0 console=ttySAC2,115200 init=/usr/sbin/bootchartd printk.time=y initcall_debug=1 rw mtdparts=physmap-flash:-(nor);neo1973-nand:0x00040000(qi),0x00040000(depr-ub-env),0x00800000(kernel),0x000a0000(depr),0x00040000(identity-ext2),0x0f6a0000(rootfs) g_ether.dev_addr=00:1F:11:01:91:A6 g_ether.host_addr=00:1F:11:01:91:A7 root=/dev/mmcblk0p1 rootwait init=/sbin/ Sep 13 21:50:58 init2 loglevel=3" Sep 13 21:51:12 that is with qi-bootloader Sep 13 21:53:50 I will try removing init=<> from default qi kernel commandline Sep 13 21:54:05 prahal2: if you give multiple init= options which one does linux use? Sep 13 21:54:09 sorry qi-bootchart Sep 13 21:54:24 I guess the first one, will check doc Sep 13 22:49:52 checked source code : seems there is a bug in the port from 2.4 to 2.6 : http://www.takatan.net/lxr/source/init/main.c?v=2.4.21-47.EL#L280 => http://lxr.free-electrons.com/source/init/main.c#L290 . Sep 13 22:50:12 or at least the comment which stayed makes no sense with current code Sep 13 22:51:05 it was bypassing every item=X until item == "init" .. now it set to NULL every but the first value passed as init= Sep 13 22:52:02 so this first only is specific to init= :/ Sep 13 22:54:59 well I am not confident there is a bug in the code ... but the comment should go away or get updated Sep 13 23:08:03 http://lwn.net/Articles/18040/ <- removal of 2.4 code in 2.5.51, adding it back adapted to 2.5.52 https://lkml.org/lkml/2002/12/22/112 Sep 13 23:10:02 well I found that the comment and code still matches but the code is a bit buggy Sep 13 23:10:52 ie I bet the init_setup return 1 prevents processing further iteration ... as that would discard all other parameters passed before the last init= Sep 13 23:12:24 so new codes behaves a bit better than old one Sep 13 23:16:20 as old one was handling all init= but still discarding all "init" params before init= (thus if init= was last nothing else was passed Sep 13 23:20:32 cat /proc/1/cmdline => "/sbin/init2" when I pass init=/sbin/init2 as last kernel commandline item Sep 13 23:30:41 so in short it works Sep 13 23:33:05 and the qi patch 0007-use-bootchart-as-init.patch would useless Sep 13 23:33:08 be Sep 13 23:34:09 still init= has to be before the other "init" parameters Sep 13 23:34:38 ie unknown boot options passed to the kernel for init consumption **** ENDING LOGGING AT Fri Sep 14 02:59:59 2012