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