=== bjf is now known as bjf-afk === ericm-Zzz is now known as ericm === doko__ is now known as doko === playya__ is now known as playya [15:44] ogra: your rootstock script looks for qemu, I believe you need qemu-arm-static? [15:48] or rather qemu-kvm-extras [15:54] ogra: await my trivial patch while a struggle through bzr [16:15] Okay, more fun with Karmic this morning --- [16:15] mountall:/proc/filesystems: No such file or directory [16:15] init: mountall main process (638) killed by SEGV signal [16:15] This is what I get at the end of the boot sequence... [16:15] [ 22.769409] Waiting for root device /dev/mmcblk0p2... [16:15] [ 22.794891] mmc0: new SDHC card at address 8fe4 [16:15] [ 22.800201] mmcblk0: mmc0:8fe4 SD04G 3.69 GiB [16:15] [ 22.805053] mmcblk0: p1 p2 [16:16] I'm assuming this is caused by the new init replacement? [16:16] Martyn: I recall lool talking about this and that it was fixed in the latest upload [16:16] I just built a rootstock 12 hours ago [16:16] is that upload newer than that rootstock? [16:17] (do you know if lool made a launchpad bug I could look it up against?) [16:17] Martyn: dunno, but I think it was fixed today [16:18] ogra: does rootstock work with apt-cacher-ng? -m isn't working. [16:21] urk .. today eh? [16:21] Well, I'll try building another rootstock then [16:21] I hate how long it takes [16:22] Martyn: hence the question about apt-cacher-ng above :) [16:23] I think rootstock should either be modified to cache the .debs in a local dir [16:23] or use apt-cacher-ng [16:23] It probably does, I am just too dense to figure out how [16:25] afik I haven't seen anything that lets it cache the .debs [16:27] which would, frankly, be awesome [16:30] though the biggest bottleneck isn't downloading the .debs, but installing them inside qemu (which isn't multi-core friendly) [16:57] Mine is downloading the .debs [16:58] Because right now it's at #268 [16:58] and still going [17:12] amitk: You need qemu-arm-static for rootstock [17:12] amitk: It uses binfmt misc to run the executables and cant work with a qemu needing shared libs [17:12] Martyn: mountall as fixed < 12 hours ago [17:12] +was [17:12] Martyn: You need .2 [17:13] Yeah, so I'm building a new rootstock [17:13] .2? [17:13] what's the fix? [17:14] /bin/sh /usr/bin/rootstock --fqdn beagleboard.i.smooth-stone.com --login default --password default --imagesize 2G --seed xfce4,gdm --dist karmic --serial ttyS2 --kernel-image http://rcn-ee.net/deb/kernel/beagle/karmic/v2.6.31-rc8-3777b1e-ang1.1/linux-image-2.6.31-rc8-ang1.1_1.0karmic_armel.deb [17:14] [17:14] That's my current build [17:37] Martyn: There are a bunch of changes [17:42] Martyn: any news wrt my ssh access? :) === bjf-afk is now known as bjf [18:33] lool : they should all appear in the rootstock I'm doing, right? [18:33] armin76 : Didn't I send you the ip/log/pass? [18:34] look for an email from martin@smooth-stone.com [18:35] hrm.. [18:36] Martyn: probably got marked as spam :/ can you resend it please? [18:37] when did you send it? [18:40] A long while ago [18:40] i got junk mails up-to 25th sept [18:41] pretty much after you first asked [18:41] Okay, later when I get a chance to hit the lab [18:41] :( [18:41] right now I'm still working on getting the new rootstock working [18:41] ok, thank you :) [18:45] init: procps main process (650) terminated with status 255 -- new error [18:45] It doesn't seem to affect much on the board when I boot ( it proceeds to doing keymap, etc ) [18:45] but still, it's odd that procps is dying [18:57] amitk, i use it with approx here, it doesnt work if you use localhost in the url [18:57] beyond that it should just work [18:58] ogra: do you have a pre-synced archive or does it cache on the fly? [18:58] on the fly [18:59] but given that i usually build one or two images a day it is usually up to date [19:01] huh .. so I should be able to use apt-cacher-ng, as long as I use the fqdn? [19:01] (and not localhost.localdomain?) [19:02] right [19:04] Martyn: hrm...i don't think i ever gave you my mail :P [19:04] I'll remember that for my next build [19:04] armin76@gentoo.org :) [19:11] ogra: what does the --kernel-image option do in rootstock? Since it can't really flash the kernel into the SD. [19:12] amitk, used by beagle, not my code [19:12] it didnt break the rest so i simply accepted the patch [19:12] ignore it for anything but beagle [19:12] (i think the manpage says that) [19:13] yep [19:13] and I'm using it on a beagle :) [19:13] looks remarkably good, actually.. latest rootstock only has the procps bug on boot [19:13] amitk: and you can flash the kernel onto the SD for some architectures :) [19:14] the PBX-A9 now has a u-boot loader that will look on the mmc card first, rather than nand [19:14] gumstix will even load u-boot from mmc before it loads it from nand [19:14] (_very_ convenient :) [19:17] X-Loader does rock that way :) [19:17] beagle can do, with the correct X-Loader [19:25] lool, at the risk of being dense, what specifically is the problem with mountall on dove (aside from the fact it breaks images)? [20:27] NCommander: I dont know [22:15] lool, meh, I guess its going to require bisection with the latest uploads to figure out what broke it :-/ [22:18] Why? [22:28] lool, well, mountall preventing the system from coming up even on installed systems. Its a regression based off one of the most recent updates, so I want to isolate what version it popped up in [22:35] Hmm. What's the supposed procedure to get an uimage to boot from using ubuntu kernels? linux-image- only gives me a vmlinuz?! [22:36] NCommander: it's not the latest version [22:36] NCommander: .2 should be fixed [22:36] ojn: Depends of the board [22:36] ojn: mkimage + flags [22:37] lool, .2? as in 0.2.2 of mkimage? [22:37] lool: oh, so no package will actually install an uimage for me, I have to do the wrapping by hand? [22:37] * ojn finds marvelldovefromscratch on the wiki [22:37] NCommander: of mountall [22:38] ojn: We support various boards via flash-kernel [22:38] lool, I'm pretty sure thats what I have on my dove when I dist-upgraded around noon [22:38] ojn, do you have a Y0 or Y1? [22:38] ojn: flash-kernel adjusts the kernel installation, sometimes doing a mkimage, depending on the hardware [22:38] NCommander: uhoh [22:38] lool: ah, thanks! [22:38] NCommander: Please flag this to keybuk asap if you have 0.2.2 [22:39] lool, let me recheck (aka, let me write a working live image) [22:39] NCommander: the latest live image has the old version [22:39] which is why I'm trying to respin [22:39] lool, right, but I dist-upgraded an installed system [22:39] lool, around noon, and it no longer boots, and hangs like the livefs [22:40] lool, that's why I brought it up [22:40] lool, (sidenote: partman-uboot is in main) [22:40] it is? [22:40] I'm going to try it then [22:41] Martyn, ? [22:41] Martyn, try partman-uboot? [22:41] yep [22:41] Martyn, its not part of the installer yet, ubiquity needs to be tweaked [22:41] Martyn, and only on armel+dove unless you override the sanity checks [22:41] but the tool is there, yes? [22:41] Martyn, no tool [22:41] oh, poot [22:42] Martyn, partman-uboot just defines to partman that it needs to make an ext2 partition as / or /boot [22:42] Martyn, its only of interest to the installer :-) [22:43] Martyn, what sorta tool are you looking for [22:43] a userspace tool to install and edit the uboot parameters [22:43] since I have them in an mtd [22:43] Martyn, uboot-envtools [22:43] already exists [22:43] AH.. that's the name of the package :) thanks [22:43] er [22:44] wrong package name [22:44] hold on === roxfan2 is now known as roxfan [22:44] Martyn, er, no, I was righ the first time [22:44] Martyn, you need to feed it a config file with the configuration partition and stuff [22:44] Martyn, although TBH, you might want to adapt what we're using for Dove. I modified the boot system so we never have to touch the bootloader from the userland [22:45] Martyn, (I kinda abused u-boots scripting functionality) [22:45] NCommander: So did you confirm your mountall version? [22:45] NCommander: Please get a bug on this ASAP [22:45] It's a critical bug at least on dove [22:45] lool, I'm still downloading the beta image, I zsync'ed over it by accident [22:47] lool : The latest buildroot I did, mountall works [22:47] lool : I get an odd procps error, but that's acceptable [22:47] Martyn: I think it's one of our kernel configs triggering that [22:47] binfmt misc support missing [22:47] oops [22:48] I need to run a custom kernel too .. so I'm using your kernel config + merge w/ mine to produce three different platforms [22:48] beagle w/ Zippyboard, PBX-A9, and secret-platform [22:48] so that I can test A8, A9 dual core, and A9 quad core [22:48] * NCommander drools at A9 quad core [22:49] Martyn, how long until I can get a netbook with one of those? :-) [22:49] AFIK, no manufacturer is using the quad core in a netbook [22:49] awwww [22:49] duals look like they are going to be present starting Q2 '10 [22:49] (and in handsets before that, if TI can get their act together and start producing OMAP4's) [22:50] Martyn, maybe my next Android device will have one of those [22:50] * NCommander loves his G1 [22:50] NCommander: Heh.. not before Apple pumps out a new phone with one [22:51] I don't know why its' [22:51] it's taking so long for dual core A9 chips to emerge [22:51] Martyn, the iPhone can bite me. Overpriced proprietary **** [22:51] I rather have a Windows Mobile device than an iPhone because at least I can load my own stuff [22:51] My company gets 'em pretty fast after they are produced, and I know we had to fight to get the PBX-A9's and secret-platforms [22:52] Back tomorrow. Time for me to head home. [22:52] Martyn, peace [22:52] I'm happy to at least have the Beagle working today. Good rootstock [22:53] I'll start another rootstock build for 8am tomorrow [22:53] (Central US) [22:53] Martyn, ogra will be happy [22:53] Martyn, BTW, you going to be at UDS? [22:53] yes, I'm confirmed for UDS [22:53] and I'll have a couple blueprints in tow for A9 related stuff, ARM-server stuff [22:53] Martyn, \o/. Bring shiny toys with you that we can gak at :-) [22:53] that's almost guaranteed [22:57] Any ARM experts want to implement a SHA-3 candidate optimized for the ARM architecture? [22:58] * NCommander wonders if that candidate can use ARM VFP [22:58] Else OW! [22:59] What's VFP? [22:59] zooko, VFP == the ARM's optional floating point unit :-) [23:00] The algorithm doesn't use floating point. [23:01] The CPU that they are using for benchmarking is actually an old StrongARM. :-) [23:01] Oh sorry, I mean XScale: 416MHz, ARM XScale-PXA270 rev 4 (v5l) [23:01] But I wouldn't say no if someone offered to implement on something newer with NEON or the like. [23:01] zooko, link to the algro? [23:01] http://cubehash.cr.yp.to/ [23:02] It is the simplest SHA-3 candidate, which makes it easier to implement. [23:02] zooko, actually this doesn't look too bad for ARM ... [23:02] Yeah, it is all 32-bit [23:02] * NCommander doesn't think theres a rotate op-code [23:03] zooko, I pity whoever had to implement this in Thumb :-) [23:03] I was trying to figure out how to make it more cache-friendly by reordering somehow [23:03] but I don't see it. [23:03] The performance sucks on the XScale. [23:03] 126 cycles per byte processed [23:03] zooko, ow [23:04] I would guess it is just compiling the C implementation with gcc. :-) [23:04] * NCommander is trying to think what is missing in the base instruction set [23:04] http://bench.cr.yp.to/results-hash.html [23:04] ARM's base instruction set isn't lean per-say, but your missing a ton of fun things [23:04] ^-- search in text for "arm," [23:05] zooko, no hardware XOR for one [23:05] * NCommander is kinda suprised on that one [23:05] Wow. [23:05] That is a limitation! [23:06] zooko, welcome to ARM. Leave your instructionset at the door. [23:06] What versions of ARM instruction set lack an XOR? [23:06] zooko, all of them. The base instruction set doesn't have it [23:06] zooko, it might be on the VFP [23:06] * zooko tries to imagine how to program without an XOR instruction. [23:07] zooko, you can make it out of the logical not/or/and, but I'm not actually sure if thats right [23:07] * NCommander is rechecking [23:09] EOR [23:09] is in thumb2 [23:09] neonfreon, yeah, but its not in th ebase set [23:10] There are a few instructions that only exist in thumb2, and not in the base ARM [23:10] * NCommander is still not sure [23:11] http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001m/QRC0001_UAL.pdf [23:11] it's hard to read [23:11] it looks like it may be in base [23:11] neonfreon, yeah, we're reading the same doc :-) [23:12] * NCommander eats his boot [23:12] neonfreon, yeah, its eor [23:12] wow, thats quirky [23:12] * NCommander has only done a few veyr basic things on ARM ASM [23:13] * NCommander was considering breaking out the reference manual but I believe thats overkill on this [23:14] Great! We have an XOR instruction. [23:14] So the naive implementation of CubeHash in ARM assembly would probably be fine. [23:15] I was wondering if there was some clever trick to do things in a different order so as to maximize re-use of the cache, but I'll bet that's not needed. [23:15] zooko, in ARM. I won't want to try it in Thumb :-) [23:15] The entire state is only 128 bytes, so I suppose the CPU will naturally keep it all in cache the whole time if it is implemented in the straightforward way. [23:16] NCommander: I don't really know what Thumb is. That was/is an optional architecture feature to have 16-bit opcodes? [23:16] zooko, yeah, its meant for really embedded stuff [23:16] Implementing CubeHash in Thumb would be close to pulling teeth I suspect [23:18] Does the XScale implement ARM? [23:23] yes [23:23] if you mean the instruction set [23:24] armv5 plus some extensions [23:24] i hear internally it's quite different (different pipeline and other stuff) [23:25] Cool. So a straightforward implementation of CubeHash in armv5 should (I hope) drastically improve the performance on that benchmark that I linked to. [23:29] it might, if you're using some v5 features [23:29] if your xscale has iwmmxt you probably could improve it even further [23:31] lool, confirmed, 0.2.2 doesn't seem to work on Dove. I just want to check one last thing, and then I'll file a bug [23:33] NCommander: arm does have xor [23:33] they just call it eor [23:33] ah nv, [23:33] nvm [23:33] roxfan, yeah. Exclusive-OR. Bit of a funny way to write it though [23:34] well, the isa was conceived in 80s or so, i think "xor" wasn't a common abbreviation back then [23:36] roxfan, x86 is from the 70s and that used xor :-) [23:36] (actually, I almost want to say 60s on that) [23:36] yes, but was it common? [23:37] what was used in 6502, 8051, 68k? [23:38] roxfan, yes, not sure, yes? [23:38] hmm interesting [23:38] er [23:38] sorry [23:38] 6502 is EOR [23:39] ah [23:39] that could be the reason then [23:39] first arm was a coprocessor for bbc micro or something [23:39] and main cpu was 6502 [23:39] ah, anyway, AFK, fire === bjf is now known as bjf-afk