**** BEGIN LOGGING AT Mon Jun 06 02:59:57 2011 Jun 06 16:51:30 o, sure ;) Jun 06 16:51:34 switch (strlen(hex)) Jun 06 16:53:00 I've switched rgb to rgba today Jun 06 16:53:22 parsed xpm icons was stored a bit strangely Jun 06 16:53:31 now just array of uint32's Jun 06 16:57:14 ok, I'lll rebuild a debug kernel this evening Jun 06 16:57:24 debug in keecboot is not the point... Jun 06 16:57:37 I'll send you some patches tonight Jun 06 16:58:17 just to see what happens behind.. could be SIGBUS if it's about alignments Jun 06 16:59:55 have to go home Jun 06 16:59:57 bbl Jun 06 17:00:08 see you Jun 06 17:25:33 6 hours difference, always fun. Jun 06 17:25:54 so Jay7 hows this all work ? Jun 06 17:26:14 I'm not grep'ing the methods of building/customizing to a board's kernel/hardware Jun 06 17:26:19 whse-work: at first, kexecboot is application itself Jun 06 17:26:27 aye Jun 06 17:26:33 but we call kernel + initramfs + kexecboot as kexecboot too :) Jun 06 17:26:45 grok'd all that Jun 06 17:26:57 so just decide how you want to use it Jun 06 17:27:20 we are using OpenEmbedded to build kernel + initramfs + kexecboot Jun 06 17:27:52 Mk, so kernel + initramfs w/ drivers and all, then loads kexecboot program (+kexec) to figure out which to boot. Jun 06 17:27:53 but there is no rocket science Jun 06 17:28:04 just use kexecboot as init Jun 06 17:28:08 we use a locally built compilers Jun 06 17:28:09 or run it from /etc/rc Jun 06 17:28:18 hmm interesting Jun 06 17:28:36 btw, good idea to place somewhere directory layout on site.. Jun 06 17:28:37 don't think I've managed a successful build yet though Jun 06 17:28:57 are you using zImage or uImage? Jun 06 17:29:10 we use a zimage Jun 06 17:29:15 *cough* Jun 06 17:29:21 nice, it should work ok Jun 06 17:29:24 currently, we use a uimage burnt to nand. Jun 06 17:29:34 uImage have some issues with kexec-tools Jun 06 17:29:46 the boards provided uboot sources are for uboot 1.1.2 (archaic) Jun 06 17:29:50 e.g. kexec binary can't handle compressed uImages iirc Jun 06 17:30:04 hehe.. like we have on Zauruses Jun 06 17:30:05 k, but, the end result wont be needed :) Jun 06 17:30:12 some archaic bootloader Jun 06 17:30:17 righto Jun 06 17:30:30 I was flipping through kexec use, and found reference to kexecboot Jun 06 17:30:37 "oh snap" Jun 06 17:30:42 :) Jun 06 17:31:01 but then of course, I was left with "ah shit" Jun 06 17:31:13 I know the parameters I need to be setup.. but Jun 06 17:31:23 hehe.. it happens Jun 06 17:31:30 I can't figure out where to place them, etc Jun 06 17:31:33 I have derived most of the automake setup Jun 06 17:32:21 check this http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/kexecboot/kexecboot.inc Jun 06 17:32:42 just as reference for configure options Jun 06 17:33:13 even as reference for real used options Jun 06 17:33:17 ah.. see that doesnt come in your tarball.. Jun 06 17:33:32 just all options may be found here: http://kexecboot.org/documentation/configure_options Jun 06 17:33:40 im looking at text-only, with a 5 sec timeout to default Jun 06 17:33:43 that is recipe from which we are building Jun 06 17:33:49 it's OE-specific Jun 06 17:34:10 we're based on Arch, but it's the linux kernel so ;p Jun 06 17:34:28 well.. then build it with --disable-fbui --enable-textui --enable-timeout=5 Jun 06 17:34:33 but I'm unsure about latest Jun 06 17:34:34 Oh, I've read all the options, end even have them all noted as to which to use/set, etc Jun 06 17:34:57 default timeout may be broken and have no indication right now Jun 06 17:34:58 well thats what the document says so that is what I used.. Jun 06 17:35:06 although I used --enable-fbui=no Jun 06 17:35:15 should work as well iirc Jun 06 17:35:44 where would I place that sort of inc file at? Jun 06 17:35:47 I should say that text ui isn't polished as well.. Jun 06 17:35:51 but should work Jun 06 17:36:04 that inc file is OE-specific Jun 06 17:36:10 well truth be told, no one will be messing with it anyways, except developers Jun 06 17:36:12 you don't needed it Jun 06 17:36:14 k Jun 06 17:36:32 so then, assume that it would be used in a standard kernel & os Jun 06 17:36:33 I've just shown it as reference of real configure options used for some hardware Jun 06 17:36:54 There are things I love about the PLX OXNAS and things I hate.. Jun 06 17:36:57 nice, just build kernel and initramfs with kexecboot inside Jun 06 17:37:15 then call it after boot anyhow Jun 06 17:37:33 So it has issues booting uImage kernels huh Jun 06 17:37:50 kexec have issues Jun 06 17:37:54 we can't workaround this Jun 06 17:38:05 but you may just check Jun 06 17:38:08 hmm Jun 06 17:38:14 might be problematic as the stock kernel is in uImage Jun 06 17:38:16 last time we was fighting with MIPS code Jun 06 17:38:23 may be ARM is better Jun 06 17:38:24 all arm here Jun 06 17:38:46 at least I remember that uImage for zauruses was booted ok Jun 06 17:39:12 CloudEngines has switched from the Marvell Kirkwood Feroceon board to the PLX OXNAS 7820 board, for all products Jun 06 17:39:32 btw, for uimage support add --enable-uimage to kexecboot's configure options as well Jun 06 17:39:33 +copro GbE -uboot suckass. Jun 06 17:39:44 yup, saw that Jun 06 17:40:40 I don't know how archlinux is building initramfs.. Jun 06 17:40:58 may be you should create some special things to built kexecboot inside Jun 06 17:40:58 I can ask my dev team about that as they have more experience Jun 06 17:41:20 I have to get it to build first :p Jun 06 17:41:26 and I suggest to check for working kexec before Jun 06 17:41:32 < have it Jun 06 17:41:53 because on Ben NanoNote e.g. we have kexecboot but have no working kexec Jun 06 17:41:59 which makes kexecboot unusable Jun 06 17:42:30 I've added this http://kexecboot.org/documentation/how_to_compile Jun 06 17:42:48 nothing special here.. Jun 06 17:42:54 from our builder Jun 06 17:42:55 Status of package 'kexec-tools' : repo=>extra, src=>abs, state=>done, blocked on: Jun 06 17:43:08 upstream % Successful builds: ARMv5: 3523 of 4287, 82.18% | ARMv7: 3105 of 4287, 72.43% Jun 06 17:43:29 most of those blockages are things like Qt4, & kde Jun 06 17:43:35 hehe Jun 06 17:43:43 plugbuild is *sweet* Jun 06 17:43:48 they are always blocking something :) Jun 06 17:44:18 so you are not using cross-compilation? Jun 06 17:44:23 compiling on targets? Jun 06 17:44:52 actually, we package the binaries on the platform, but we distcc to CT-NG cross compilers on 2-4 core ubuntu boxes Jun 06 17:45:08 ah Jun 06 17:45:14 interesting Jun 06 17:45:44 btw, another special thing - it's easy to build kexecboot against [e]glibc/uclibc Jun 06 17:45:56 but for initramfs we are building with klibc Jun 06 17:46:09 this may require something special from you Jun 06 17:46:37 we're using std glibc Jun 06 17:46:55 ah, then things should be easy Jun 06 17:47:53 this normal ? configure: WARNING: unrecognized options: --disable-fbui, --enable-text-ui, --enable-timeout, --enable-uimage Jun 06 17:48:21 hm.. no Jun 06 17:48:32 --enable-textui Jun 06 17:48:39 that's what I got stuck Jun 06 17:48:40 but other options should be ok Jun 06 17:48:49 meh, still, it barfs them ALL Jun 06 17:49:15 can you run ./configure --help by hands? Jun 06 17:49:39 * whse-work lets a re-run of autogen finish Jun 06 17:50:01 well.. it is possible to pass configure options to autogen.sh as well Jun 06 17:50:03 ah.. Jun 06 17:50:24 --with-fbmenu ... Jun 06 17:50:26 but ./configure should work, I'm using it sometimes Jun 06 17:50:46 mm Jun 06 17:50:57 says it ought to work with --enable-FEATURE Jun 06 17:51:15 what sources you are using? Jun 06 17:51:27 better to stick to git Jun 06 17:51:35 tarballs are outdated Jun 06 17:51:38 hmm Jun 06 17:51:42 0.5 have no text-ui Jun 06 17:51:44 yeah... Jun 06 17:51:53 kexecboot-git-20091220.tar.gz Jun 06 17:52:02 too old Jun 06 17:52:09 ouch, thats older than i wanteed. Jun 06 17:52:21 ty wherever the hell i got that.. Jun 06 17:52:30 http://git.linuxtogo.org/?p=groups/kexecboot/kexecboot.git;a=commit;h=698cf7185e013e873aa7df9388a31d857727d408 Jun 06 17:52:34 use latest rev Jun 06 17:53:08 all known bugs are inside fb ui :) Jun 06 17:53:28 lol good. Jun 06 17:53:29 text ui was working ok but looking not eye-candy.. Jun 06 17:53:37 i was just preparing to pull a git directly. Jun 06 17:53:41 need some love and polishing Jun 06 17:53:52 like I said, 99% of people will never see it anyways,. Jun 06 17:53:55 we will release soon Jun 06 17:54:18 but I can't say some real date Jun 06 17:55:40 btw, be careful, kexecboot grabbing all event devices exclusively Jun 06 17:56:45 and other bad thing.. we have no ubifs support Jun 06 17:56:54 * whse-work thud Jun 06 17:56:57 crap. Jun 06 17:57:03 but not required :p Jun 06 17:57:23 yeah.. real crap.. Jun 06 17:57:28 this blocking us Jun 06 17:57:51 someone should implement this.. Jun 06 17:59:25 on MIPS? Jun 06 17:59:36 or is it in general Jun 06 18:00:03 because your kernel should be handling that for you, and all you should need is the mtd-utils & ubifs support Jun 06 18:00:17 in general Jun 06 18:00:44 kexecboot is using klibc-derived routine to detect fs before mounting Jun 06 18:00:59 yeah, saw that. Jun 06 18:01:01 it have no ubifs support.. Jun 06 18:01:25 and I'm unsure that is enough.. Jun 06 18:01:51 I'll check one time.. but I'm short of time Jun 06 18:05:19 understandable. Jun 06 18:08:47 ah... no barf.. Jun 06 18:09:09 attempting make Jun 06 18:10:33 i think.. it compiled. Jun 06 18:10:45 it should ;) Jun 06 18:10:53 ~161k Jun 06 18:11:03 press q to exit :) Jun 06 18:11:11 i didnt run it :p Jun 06 18:11:13 just make Jun 06 18:11:20 havent make-install yet Jun 06 18:11:22 but you will one time ;) Jun 06 18:11:43 im ssh'd into the plug at home, som i'm leary of doing so at this moment :op Jun 06 18:11:46 but i want to! Jun 06 18:12:08 well, hope it will work ok for you Jun 06 18:12:12 bugreport here :) Jun 06 18:12:18 this supported in any way for non-zaurus ? Jun 06 18:12:21 patches are welcome, you know ;) Jun 06 18:12:34 yes, we trying to support it hw independent Jun 06 18:12:47 known to work on ipaqs and beagleboard Jun 06 18:15:13 beagle Jun 06 18:15:18 great Jun 06 18:15:41 we make this into a package... if it works out right Jun 06 18:16:32 it would be great Jun 06 18:16:51 I need known-to-work HW list on site Jun 06 18:17:20 it's not a part of arch at this point, but we keep our modified / supplimentary repo also Jun 06 18:18:58 we should do one like they have on openWRT site for known working. Jun 06 18:22:31 * Jay7 afk for ~30 min Jun 06 18:40:32 well, out of the box: fart ~ http://pastie.org/private/fhux513lmx9t9ofocyhh4q Jun 06 18:41:16 detected all the key fs's right.. Jun 06 18:41:23 took a shit on tty ? Jun 06 18:53:53 whse-work: no menu items found Jun 06 18:54:10 can't parse partition string Jun 06 18:55:14 whse-work: can you pastebin /cat /proc/partitions? Jun 06 18:55:44 well Jun 06 18:56:00 no tty is because you are running over ssh (I think) Jun 06 18:56:27 no menu items - you have no partitions with /boot/zImage, /boot/uImage or /boot/boot.cfg files on Jun 06 18:56:47 about partition string is more interesting for me Jun 06 18:56:57 actually it's because all my partitions are already mounted.. Jun 06 18:57:15 well, true Jun 06 18:57:30 ls /boot System.map26 System.map26-oxnas uImage Jun 06 18:57:36 thats on /dev/sda1 Jun 06 18:57:45 yes, you are right Jun 06 18:58:35 text ui is working with event devices, so it does not work now via ssh Jun 06 18:59:29 figures :p Jun 06 18:59:56 * Jay7 is tired today Jun 06 19:02:19 yeah, I wont have a "proper" tty until I get home over serial. Jun 06 19:02:40 but, it recognized the mtd devices :p Jun 06 19:03:59 have your board keyboard and video? Jun 06 19:04:10 these devices dont have video Jun 06 19:04:15 I have a serial console though.. Jun 06 19:04:23 well.. let's hope serial will work Jun 06 19:04:33 I'm not sure I've tested it over serial Jun 06 19:04:42 it may/may not recognize console=ttyS0,115200 Jun 06 19:04:47 anyway you need some real hardware Jun 06 19:04:55 keyboar Jun 06 19:04:57 I mean Jun 06 19:05:20 oy, I mean I can plug in a usb keyboard.. Jun 06 19:11:28 working that part in could be interesting.. Jun 06 20:39:35 Jay7, mind if I setup the hardware list on the wiki? Jun 06 20:40:15 ka6sox-away: did you mean kexecboot hw list on OE's wiki? Jun 06 20:40:37 I'll add it on kexecboot.org site later Jun 06 20:41:05 okay so you want it on oe's site first? Jun 06 20:41:11 thats fairly easy. Jun 06 20:41:37 no, I just trying to guess what wiki you mean :) Jun 06 20:42:04 I was thinking kexecboot one. Jun 06 20:42:27 its something I can do to help...not good at programming stuff (unless its things I've done) Jun 06 20:43:58 so Jay7, kexecboot will only recognize images on partitions it mounts? Jun 06 20:44:33 ka6sox-away: I'm happy with drupal now :) but thanks anyway Jun 06 20:44:41 whse-work: yes Jun 06 20:44:47 ah Jun 06 20:45:00 so i'd have to have something that *wasnt* mounted Jun 06 20:45:05 we have idea about using static boot.cfg from initramfs as well Jun 06 20:45:19 but just idea atm Jun 06 20:45:22 right Jun 06 20:45:34 ant__: hi Jun 06 20:45:36 oh right, drupal... Jun 06 20:45:37 nm Jun 06 20:45:37 I also see that it doesnt recognize the ubi fs Jun 06 20:46:11 yes, big whish Jun 06 20:46:12 whse-work: please pastebin your /proc/partitions Jun 06 20:46:34 there is no /proc/partitions Jun 06 20:46:57 it should be.. kexecboot can't work w/o partitions Jun 06 20:47:19 i have a /proc/mounts Jun 06 20:47:27 o_O Jun 06 20:47:51 oh i c it Jun 06 20:47:56 must have typoed Jun 06 20:48:30 http://pastie.org/private/aakcruu2nitf3ewbqtwfw Jun 06 20:51:03 hm.. strange Jun 06 20:51:19 why it fails to parse latest 2 lines then?.. Jun 06 20:52:18 ntfs? Jun 06 20:52:47 hmm no Jun 06 20:52:57 thats my ext4 3TB usb drive Jun 06 20:53:43 my guess: the extra digit. Jun 06 20:54:26 that extra digit in the string length probably bit you Jun 06 21:03:53 hm..unsigned long long Jun 06 21:16:28 vs the int you have it on.. yeah Jun 06 21:17:49 yup, that fixed it.. Jun 06 21:17:51 * ant__ is wondering: is static really easier to debug than shared? rephrase: klibc-static vs. eglibc-shared debug headers... Jun 06 21:18:44 Jay7: I'm still behind that alignment trap Jun 06 21:19:06 whse-work: great, which filesystem was it btw? Jun 06 21:19:27 whse-work: hm.. can you pastebin patch please Jun 06 21:19:57 or send it to me with git send-email :) Jun 06 21:20:34 lol Jun 06 21:20:54 * Jay7 is rewriting xpm processing code Jun 06 21:21:10 i just edited the devscan.c Jun 06 21:21:21 minor change to make blocks a ull vs int. Jun 06 21:21:28 idk which line :p Jun 06 21:22:12 unsigned long blocks; /* Device size in 1K blocks */ Jun 06 21:22:17 looks like this Jun 06 21:22:21 devicescan.h Jun 06 21:22:46 so replace it with unsigned long long.. Jun 06 21:23:02 http://pastie.org/private/zkhfwjxnfyro0ykj13mxhg Jun 06 21:23:35 ah.. even so Jun 06 21:24:03 yeah, thats my fault Jun 06 21:24:18 no biggy, fixed.. Jun 06 21:25:18 I see int blocks in header file too Jun 06 21:25:31 I'll replace it with long long everywhere Jun 06 21:31:21 pls fix the c2 - unassigned warnings Jun 06 21:34:51 Jay7: btw in OE we are packaging an empty kexecboot-dev package Jun 06 21:35:35 I'll have to fix it Jun 06 21:36:03 nice Jun 06 21:36:13 c2 should be fixed Jun 06 21:38:13 silly ? Jun 06 21:38:35 any particular reason it can't scan live FS ? Jun 06 21:39:12 aside from it's mounting practice Jun 06 21:43:35 Jay7: on the stripped binary I still get Jun 06 21:43:37 e17c: e5931000 ldr r1, [r3] Jun 06 21:43:52 try with unstripped one Jun 06 21:44:09 whse-work: it can't mount already mounted device Jun 06 21:44:26 it should be able to scan Jun 06 21:44:27 but why not Scan already mounted devices ? Jun 06 21:44:37 ah Jun 06 21:44:51 you mean look for kernel or boot.cfg Jun 06 21:45:09 right, if the fs is already mounted, then by not scan mntpt/blah Jun 06 21:45:18 instead of just going, "whoops" next.. Jun 06 21:45:29 not sure about this Jun 06 21:45:35 Jay7: I'm still perplexed about the debug symbols in the .debug Jun 06 21:45:59 ant__: pb give some advices Jun 06 21:46:24 check #oe logs Jun 06 21:48:44 now, I steal the unstripped binary from workdir after building it Jun 06 21:49:04 exactly Jun 06 21:49:20 I suppose the .debug package will be rebuilt afterward, with the stripped symbols Jun 06 21:49:33 still...hex2rgb has different address... Jun 06 21:49:52 * whse-work headed out Jun 06 21:50:02 thanks for the help, I'll play with it some tonight. Jun 06 21:53:39 Jay7: see, the dump of the unstripped binary is different Jun 06 21:54:03 if I grep for e5931000 Jun 06 21:54:46 stripped has b280 e17c e420 Jun 06 21:55:19 unstripped matches bd44 f16c f464 Jun 06 21:56:24 now I'll re-log both alignments in standalone mode Jun 06 22:05:08 argh Jun 06 22:05:11 well.. it even compiles Jun 06 22:05:12 now I see... Jun 06 22:05:18 * Jay7 wonders Jun 06 22:05:20 the .debug has changed :) Jun 06 22:05:29 now things are more clear Jun 06 22:05:59 e5931000 is always at bd44 f16c f464 Jun 06 22:06:01 :) Jun 06 22:06:20 I mixed the binaries :/ Jun 06 22:06:37 this evening seems better ;) Jun 06 22:11:01 yes yes Jun 06 22:11:02 Alignment trap: kexecboot (387) PC=0x0000f16c Instr=0xe5931000 Address=0x400e99bf FSR 0x013 Jun 06 22:11:28 now the stripped bin Jun 06 22:15:54 well Jun 06 22:16:13 rewrite is done Jun 06 22:16:24 but code need more testing Jun 06 22:16:31 I'll test tomorrow and push Jun 06 22:16:39 now sleep Jun 06 22:17:35 great Jun 06 22:18:07 Alignment trap: kexecboot (385) PC=0x0000f16c Instr=0xe5931000 Address=0x4010a9bf FSR 0x013 Jun 06 22:18:26 ok, mem address differs Jun 06 22:19:45 f16c is a different thing Jun 06 22:20:00 what code is there? Jun 06 22:20:09 <------>menu_action = (A_SELECT == action ? menu->current->current->id : action); Jun 06 22:20:09 f154:<----->e351000a <----->cmp<--->r1, #10 Jun 06 22:20:09 f158:<----->1a000004 <----->bne<--->f170 Jun 06 22:20:09 f15c:<----->e59f31ec <----->ldr<--->r3, [pc, #492]<>; f350 Jun 06 22:20:09 f160:<----->e5933010 <----->ldr<--->r3, [r3, #16] Jun 06 22:20:10 f164:<----->e5933010 <----->ldr<--->r3, [r3, #16] Jun 06 22:20:12 f168:<----->e593300c <----->ldr<--->r3, [r3, #12] Jun 06 22:20:14 f16c:<----->e5931000 <----->ldr<--->r1, [r3] Jun 06 22:20:16 f170:<----->e59f31d8 <----->ldr<--->r3, [pc, #472]<>; f350 Jun 06 22:20:18 f174:<----->e5831018 <----->str<--->r1, [r3, #24] Jun 06 22:20:22 <------>rc = 1; Jun 06 22:20:24 f178:<----->e3a02001 <----->mov<--->r2, #1 Jun 06 22:20:26 f17c:<----->e5832014 <----->str<--->r2, [r3, #20] Jun 06 22:20:48 hm.. interesting Jun 06 22:21:14 in fact, the .debug hinted at process_ctx_menu... Jun 06 22:21:23 that was my doubt :) Jun 06 22:21:48 menu->current->current->id Jun 06 22:22:10 but why?.. Jun 06 22:22:46 id is int Jun 06 22:22:50 kx_menu_id Jun 06 22:23:13 well.. I'll recheck it tomorrow too Jun 06 22:24:02 do you need the full dump? Jun 06 22:24:27 not sure.. just areas around PC pointer Jun 06 22:24:38 same op appears 3 times Jun 06 22:24:44 ifails just one... Jun 06 22:24:55 it is menu->current->current->id Jun 06 22:25:06 yes, the failing call Jun 06 22:25:25 3 -> ops Jun 06 22:26:21 firtst Jun 06 22:26:23 (unsigned long) fb_fix.smem_start % Jun 06 22:26:23 bd3c: e59d0024 ldr r0, [sp, #36] ; 0x24 Jun 06 22:26:23 bd40: e59f31c0 ldr r3, [pc, #448] ; bf08 Jun 06 22:26:23 bd44: e5931000 ldr r1, [r3] Jun 06 22:26:23 bd48: eb001ac4 bl 12860 <__aeabi_uidivmod> Jun 06 22:26:51 second is above Jun 06 22:26:54 third is Jun 06 22:26:56 { Jun 06 22:26:56 f458: e92d4008 push {r3, lr} Jun 06 22:26:56 #ifdef USE_FBMENU Jun 06 22:26:56 gui_show_text(params->gui, lg); Jun 06 22:26:56 f45c: e5900010 ldr r0, [r0, #16] Jun 06 22:26:58 f460: e59f3008 ldr r3, [pc, #8] ; f470 Jun 06 22:26:59 f464: e5931000 ldr r1, [r3] Jun 06 22:27:02 f468: ebfff61d bl cce4 Jun 06 22:27:03 #endif Jun 06 22:27:06 #ifdef USE_TEXTUI Jun 06 22:27:36 e5931000 ldr r1, [r3] Jun 06 22:27:44 ^^ Jun 06 22:28:06 first code you are pasted is suitable :) Jun 06 22:28:22 yes, is the last alignment trap I see Jun 06 22:28:46 then I suspect SIGBUS Jun 06 22:30:24 now I'll recompile a debug kernel Jun 06 22:30:36 (after 1/2 beer) Jun 06 22:31:06 good luck there ;) Jun 06 22:31:10 I'm gone Jun 06 22:31:15 good night as well :) Jun 06 22:31:30 gn **** ENDING LOGGING AT Tue Jun 07 02:59:57 2011