[00:29] armin76: is v8 being built for arm or in that error message? [00:29] s/arm or/arm or thumb/ === bjf is now known as bjf-afk [03:51] Hello people of #ubuntu-arm! [03:51] Hey zooko` [03:52] Suppose I know that on a certain ARM CPU algorithm X takes 60,000 cycles per use and algorithm Y takes 15,000 cycles. [03:52] Now, I want to know if the difference between these algorithms would be significant in terms of battery life. [03:52] Depends on what you're doing in general. [03:53] Supposing your ARM CPU is battery powered, and you execute one or the other of these algorithms a few thousand times. [03:53] If most of the processor time of the system is spent in the algorithm, you'll likely do better with the one that takes less cycles. [03:53] If most of the processor time is spent rendering html, then it doesn't matter as much :) [03:54] So, we should be able to estimate whether 45,000 cycles times let's say 1000 executions of the algorithm adds up to a significant or insignificant fraction of your battery, maybe? [03:54] I'm not sure there's a direct relation. [03:55] Generally, the more you spin the processor, the more power it uses. [03:55] Isn't it linear? [03:55] But, depending on the processor, some operations may take more power than others. [03:55] Hm, because of RAM access? [03:55] No, because of processor design. [03:55] The algorithm that takes more CPU cycles also uses tables in RAM a lot. [03:55] Where the other one just does a whole bunch of arithmetic. [03:56] Let's say I have two processors that support vector operations. One does this with a parallel matrix, and the other spins really, really fast over the operations. [03:56] These are going to have different power characteristics for the same instruction sequence. [03:57] Right. [03:57] So this page here says http://www.arm.com/products/CPUs/ARM_Cortex-A8.html [03:57] 0.59 mW/MHz. [03:57] I think that means that 45,000 cycles times 1000 executions is [03:57] 26 W [03:57] I may be mistaken, but I believe that is for the reference implementation, which may or may not be the implementation on any actual processor in the wild. [03:58] Yes there is a big disclaimer right below that. [03:58] Do you know how to get a number drawn from a real implementation? [03:58] Say, one running Ubuntu that you happen to have at hand? :-) [03:58] Note that it also says "power with cache". If the algorithm that uses lots of RAM happens to exceed the cache, you may end up with unexpected latency of operation when polling RAM. [03:59] I wouldn't be able to measure that: there's something wonky with the battery meter in my device. [04:00] Anyway, is 26 W a significant amount [04:00] Depends on the battery. [04:00] huh-oh it is time for me to stop using electric lights and computer screens. [04:00] If you're talking about a watch, yes. If you're talking about a workstation, not really. [04:00] How big is the battery in your favorite smartphone [04:01] Plus, 26W doesn't really mean anything without the context of runtime. [04:01] Yes it does -- I want to know 26W per battery recharge. [04:01] Is that going to mean I have to recharge more often, or is it negligible. [04:01] I don't believe in smartphones :) But let's say something like 3Wh [04:02] So 26W would drain the battery in something like 20 minutes. [04:02] This here nexus one thingie http://www.google.com/phone/static/en_US-nexusone_tech_specs.html says 1400 mAH [04:02] At what voltage? [04:03] I'd guess it's probably about 1.8V, so somewhere like 2.5Wh [04:03] Hrm, doesn't say. [04:03] Ok. [04:03] Okay so this tells me that this quick kludgey approximation shows that this difference is significant. [04:04] Which means I have to approximate more carefully if I want to know if it is *really* significant. :-) [04:04] Well, if you need to run the operation constantly. [04:04] The estimate I was just doing was "if you want to do this thing 1000 times in a row" [04:04] and the thing costs either 15,000 CPU cycles or 60,000 CPU cycles each time. [04:04] Right, but you measured it in watts, which is energy/time [04:05] So without knowing how long it takes to do it 1000 times in a row, it's meaningless. [04:05] Wait if it has 2.5 Wh and you draw (let's say) 25 W doesn't that mean you drain it in one hour? [04:05] No. [04:05] That's 6 minutes. [04:05] Oh, I'm really confusde. [04:05] OK. [04:05] 2.5 Wh is ability to provide 2.5 W for 1 h. [04:05] ? [04:05] So, energy is voltage times amperage [04:05] And power is energy divided by time [04:06] So 2.5Wh is a measure of energy (power * time) [04:06] It's 2.5W for an hour, or 25W for 6 minutes. [04:06] Ok. [04:06] Or 1W for 2.5 hours. Doesn't matter. [04:06] Okay that makes sense. [04:08] Now, if there is a rough guide that x operations / second = x joules / second (1 watt = 1 joule / second), we can estimate the number of joules required for an operation. [04:08] Waitasec, why are batteries measured in power * time. Instead of just in power. [04:08] Err. [04:08] And if there is *no* latency, we can then estimate the number of operations available for a given energy budget. [04:08] Hm. [04:08] Because batteries contain an amount of energy, rather than an amount of power. [04:08] I see. [04:09] Batteries usually have upper and lower limits of power draw, but they can only present power to the total amount of stored energy. [04:09] That makes sense. [04:09] So, the average 3Wh battery you buy on the street probably can't be configured to give 3MW even for 3.6 milliseconds. [04:10] And it probably can't handle a draw of 1 nanowatt for centuries. [04:10] :-) [04:10] But for sane values, it's usually safe to assume that one is operating within the battery contraints, and just treat it as an energy storage device. [04:11] Right. [04:13] So, as long as we're doing wild speculation on potentially invalid specs, we can roughly say that <0.59mW/MHz is <0.59mJ/MOps [04:13] Running 45,000 operations 1,000 times is about 45MOps [04:13] So that's something like 26.5 mJ [04:13] Right. [04:14] No I think 26.5 J [04:14] Note that not every processor operates at one operation per clock cycle, so we're already in largely invalid calculations. [04:14] * zooko` nods [04:15] 0.59 * 45 = 26.5 [04:15] So the unit doesn't change. [04:15] I'll run real benchmarks for time, but I'm not sure how to benchmark energy usage. [04:15] It's usually done with power meters on development boards. [04:16] Yes, but you left out the 1000 time. [04:16] More usefully, it's probably going to be less power to run the algorithm that requires fewer operations, especially if it also requires fewer calls to RAM. [04:16] a thing which takes 45,000 operations is about 26.5 mJ, so 1000 of those is 26.5 J, right? [04:16] No, 45,000 operations * 1,000 times is 45,000,000 operations, or 45Mops. [04:16] Oh. [04:17] So it takes only 0.59 mJ to do that thing 1000 times. [04:17] Right, which isn't that much. [04:18] Why did this come out looking small when the other calculation came out looking large. [04:18] But because it calls to RAM, and because we made all sorts of assumptions to get that value, it's likely to be more than that in real-world usage. [04:19] Where did I get that 26 W number earlier... [04:20] Dunno, but 26W would be running the operations all in parallel for soemthing like 10 days. [04:20] (at least if all the operations consume 26mJ) [04:21] Heh. [04:21] Off by a million error. [04:22] Minor mistake :) [04:22] Okay so if our *new* estimate is reasonable then the difference between these two algorithms is insignificant. :-) [04:23] Well, depends on usage. [04:23] If it's the primary application of the processor, a factor of more than 3 can make a difference. [04:23] If it just happens once in a while, it doesn't matter. [04:50] What do you mean a factor of more than 3. [04:51] You said 45,000 vs. 15,000 and that the 45,000 one needed more RAM. [04:51] So I read that as a factor of more than 3: 3 times the operations + potentially additional effort to pull from RAM. [04:59] thinks get even more interesting when the processor does voltage and frequency scaling, because then 1 operation at 1GHz != 1 op at 500MHz [04:59] *things [04:59] I see. [06:19] shenki: for arm, i'm not using the thumb option, although i believe -march=armv5te includes thumb? [06:21] armin76: try forcing it with a -marm [06:21] armin76: are you building locally? [06:22] s/locally/natively/ [06:24] * persia thinks -marm vs. -mthumb are different [06:25] i would agree :) one will force your compiler to emit 32-bit arm code, the other will force 16-bit thumb code [06:26] well, the 16bit ness fo thumb is a bit blurry if you're building for thumb2 [06:31] Well, yeah, but -march doesn't necessarily imply either, as far as I understand. [06:32] (although this depends on toolchain config, and armin76 has a special toolchain) [06:33] yeah [06:33] i think we're on the same page, i was just suggesting he try -marm to make sure that isn't the issue [06:34] * shenki is the author of the v8 build file [07:07] shenki: persia: will try, but its weird since on armv7 works fine [07:07] both toolchains are different, thoguh, armv5te is softfloat while armv7 is not [07:07] though* [07:08] so what i think is that maybe the assembler is using armv7-only code [07:08] but i'm no expert [07:08] and chromium builds fine without v8 [07:11] what does -marm do? [07:11] -marm and -mthumb specify which instruction set to target for the given -march [07:11] (mind you, there are defaults hidden in the toolchain config, but this lets one be explicit) [07:12] kHH [07:12] nsh [07:12] err [07:12] i don't use -mthumb either :P [07:12] But do you know which is implied by your toolchain config? [07:12] The suggestion was to override, in case this was the problem [07:13] http://dpaste.com/141952/ [07:13] sure, i'll try [11:04] hi [11:04] armin76: you say with armv7=1 it bult? [11:05] or just on armv7 without that flag [11:05] ogra: ;) [11:05] asac: without the flag [11:06] asac, yo [11:07] asac, well, i built mkimage from the tree now on x86, but still no go :( [11:07] ogra: try the command i gave you ;) [11:07] or was that identitical? [11:07] it was [11:08] mkimage -A arm -O linux -T kernel -C none -a 0x90800000 -e 0x90800000 -n LinuxRocks -d boot/vmlinuz-2.6.31-601-imx51 uImageN [11:08] mkimage -A arm -O linux -T kernel -C none -a 0x90800000 -e 0x90800000 -n "Linux" -d ./boot/vmlinuz-2.6.31-601-imx51 ./uimage [11:08] the name is important ;) [11:08] haha [11:08] i swear [11:08] *g* [11:08] it must be != Linux ;) [11:08] shall i upload that uImageN somewhere? [11:09] no [11:09] i have your old one [11:09] ok [11:09] right [11:09] i used mkimage from karmic x86 [11:09] if you use that it has to work for you too ;) [11:09] ogra@osiris:~/Desktop/tmp$ mkimage -l ./uimage|grep ^Data [11:09] Data Size: 3062156 Bytes = 2990.39 kB = 2.92 MB [11:09] ogra@osiris:~/Desktop/tmp$ mkimage -l ./uImage.asac.908000000|grep ^Data [11:09] Data Size: 3063148 Bytes = 2991.36 kB = 2.92 MB [11:09] the size differs [11:09] * ogra wonders why [11:09] the new size is different yes [11:10] let me check what the new one has [11:10] i thin kit was a different kernel [11:10] Data Size: 3062156 Bytes = 2990.39 kB = 2.92 MB [11:10] thats the new [11:10] that boots [11:10] same as mine [11:10] md5sum? [11:10] and you used mkimage from the archive this time ? [11:10] 8c1cf14ad6e4ef9c1479678c8e606872 uImageN [11:11] ogra: yes. i used x86 karmic mkimage [11:11] ogra@osiris:~/Desktop/tmp$ md5sum ./uimage [11:11] 6134a0836cb224e3135acbd8c862ed00 ./uimage [11:11] * ogra doesnt get it [11:11] right. you have a different name [11:11] ;) [11:11] really ... [11:11] * ogra now tries with a different name juts for giggles [11:11] haha [11:12] i tell you it will work. also no ./ [11:12] ;) [11:13] * ogra wishes he had a clue whats wrong [11:15] mkimage -A arm -O linux -T kernel -C none -a 0x90800000 -e 0x90800000 -n Lalala -d boot/vmlinuz-2.6.31-601-imx51 uimage [11:15] no change [11:15] afte3r loading ... http://paste.ubuntu.com/352834/ [11:15] does that work for you? [11:15] iminfo? [11:15] i cant load [11:15] :P [11:15] else i'd try [11:16] please run the same command so we can compare md5sums [11:17] ogra@osiris:~/Desktop/tmp$ mkimage -A arm -O linux -T kernel -C none -a 0x90800000 -e 0x90800000 -n LinuxRocks -d boot/vmlinuz-2.6.31-601-imx51 uImageN [11:17] ... [11:17] ogra@osiris:~/Desktop/tmp$ md5sum uImageN [11:17] 807feee5a32a1805eccf4509574211e3 uImageN [11:17] 8c1cf14ad6e4ef9c1479678c8e606872 uImageN [11:17] odd [11:18] ii uboot-mkimage 0.4 [11:18] same [11:18] wait [11:18] i use a -pae kernel [11:18] 9184c83fbca680969199928bfcb8748d boot/vmlinuz-2.6.31-601-imx51 [11:18] i wonder if that could make any difference [11:18] 791f2ca366f78922a9a981bd173ba3b9 /usr/bin/mkimage [11:18] ogra@osiris:~/Desktop/tmp$ md5sum boot/vmlinuz-2.6.31-601-imx51 [11:18] 9184c83fbca680969199928bfcb8748d boot/vmlinuz-2.6.31-601-imx51 [11:19] aha ! [11:19] thats the same [11:19] oh, i looked at mkimage :P [11:19] 791f2ca366f78922a9a981bd173ba3b9 /usr/bin/mkimage [11:19] yeah [11:19] so its obviously your computer ;) [11:19] you are on i386 ? [11:20] uname -a [11:20] Linux tinya 2.6.32-02063202-generic #02063202 SMP Sat Dec 19 11:00:49 UTC 2009 i686 GNU/Linux [11:20] hmm. i am on a .32 kernel [11:20] would be odd if thats causing it [11:20] ogra@osiris:~/Desktop/tmp$ uname -a [11:20] Linux osiris 2.6.31-14-generic-pae #48+ureadahead2-Ubuntu SMP Wed Oct 28 16:24:28 UTC 2009 i686 GNU/Linux [11:20] yeah that would be extremely odd ;) [11:20] still using keybuks toy kernel [11:21] shall i reboot into the karmic kernel? [11:21] letr me try on a different machine first [11:22] i would suggest that you use a vanilla kernel too rather: http://kernel.ubuntu.com/~kernel-ppa/mainline/ [11:22] i have v2.6.32.2/ afair [11:22] what does pae do? memory shuffeling? [11:23] using above 3G [11:23] so yes [11:23] above 3g? [11:24] http://en.wikipedia.org/wiki/Physical_Address_Extension [11:24] ogra@heizung:~/tmp$ mkimage -A arm -O linux -T kernel -C none -a 0x90800000 -e 0x90800000 -n LinuxRocks -d boot/vmlinuz-2.6.31-601-imx51 uImageN [11:24] you have more than 4g? [11:24] ogra@heizung:~/tmp$ md5sum uImageN [11:24] 1ad5cba13bce2849dd49bf70ad221bef uImageN [11:24] no, i have 4G [11:24] the std generic kernel can only address 3 [11:25] the machine i tried now is on lucid though [11:25] yeah. thats a different mkimage version? [11:25] nope [11:25] wow [11:25] mkimage wasnt updated ever [11:25] so how can it be so different? [11:25] can you try to boot the kernel i have? [11:26] linux-image-2.6.32-02063202-generic 2.6.32-02063202 Linux kernel image for version 2.6.32 on x86/x86_64 [11:26] though i am quite sure i used the .31 kernel from plain karmic as well [11:26] http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32.2/linux-headers-2.6.32-02063202-generic_2.6.32-02063202_i386.deb [11:27] http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32.2/linux-headers-2.6.32-02063202_2.6.32-02063202_all.deb [11:27] well, the lucid try makes no difference [11:27] http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32.2/linux-image-2.6.32-02063202-generic_2.6.32-02063202_i386.deb [11:27] yeah. but the checksum is different too. really odd that its different in first place [11:27] err [11:27] ogra@heizung:~/tmp$ uname -a [11:27] Linux heizung 2.6.27-7-generic #1 SMP Fri Oct 24 06:42:44 UTC 2008 i686 GNU/Linux [11:27] hmm, why didnt that get upgraded [11:27] let me see if the same run yields the same checksum [11:28] so [11:28] seems they add a timestamp or something [11:28] so the checksum is useless [11:28] indeed [11:28] * ogra slaps forehead [11:28] Created: Thu Jan 7 12:23:59 2010 [11:28] sigh [11:28] yeah [11:28] seeing it now too ;) [11:29] maybe binary diff ;) [11:29] still doesnt explain why it doesnt work [11:29] it has to work with hardy btw [11:29] thats what the builder runs [11:30] give me your x86 created uImage [11:30] http://people.canonical.com/~asac/tmp/uImageN.1 [11:30] thats the one [11:31] be back in 5 [11:32] hmm, hangs too here [11:33] well. it hanged for me for the first try too [11:34] you used my script to create the card ? [11:34] after reset it worked [11:34] i.e. same filesystem [11:34] i did it manually at some point [11:34] one sec [11:34] hmm [11:34] FAT32 here [11:35] http://paste.ubuntu.com/352846/ [11:36] so ... try it a few times [11:36] maybe the uboot build you did is less reliable wrt to SD [11:36] than mine [11:37] do you have the script somewhere? [11:37] what script ? [11:37] e.g. something i can use to create it like you do? [11:37] ah [11:37] its on the spec [11:37] at best a script called: mkbootfloppy [11:37] yes. i used that manually [11:37] http://paste.ubuntu.com/352850/ [11:38] the uboot binary is still stuck in NEW [11:38] yes. our archive admin is lagging ;) [11:38] hehe [11:39] why is it in new? [11:39] shouldnt we reuse package names? [11:39] the binary has a hardcoded version thanks to NC [11:39] anyway. the other image still loads for you? [11:39] e.g. the .asac uImage [11:39] ? [11:39] * ogra tries that again [11:39] ogra: did you fix that this time? [11:39] e.g. without version? [11:39] nope [11:40] i updated it ... [11:40] so next time it would be thanks to you ;) [11:40] indeed :) [11:41] BBG U-Boot > fatload mmc 0:2 0x90800000 /uimage [11:41] reading /uimage [11:41] 3063212 bytes read [11:41] no prob with your old one [11:42] try the new one right after that [11:43] version [11:43] U-Boot 2009.08 (Dec 07 2009 - 07:37:24) [11:44] U-Boot 2009.08 (Jan 06 2010 - 09:44:19) [11:44] same thing [11:44] built on the babbge from the updated source package [11:46] did you build it with -marm ? [11:47] ogra: i just build it with the _bbg rule ... no tweaks added [11:47] on lucid ? [11:47] you need tewaks [11:47] *tweaks [11:48] well. i tweaked some config [11:48] there are some inline finctions gcc will choke on [11:48] *func [11:48] hmm [11:48] anyway. let me fix your script to do all oob and then try [11:49] grab the sourcepackage for uboot-imx [11:49] 1000_fix_gcc_4.4_compatibility.patch is needed [11:49] i dont get how you got it building without that [11:49] at least on lucid [11:50] ogra: put your uboot.bin somewhere ;) [11:50] hmm [11:50] ok [11:51] i dont have a lucid install atm. only chroot. but i can try that i guess [11:51] have .dsc link? [11:51] ogra: ? [11:51] http://people.canonical.com/~ogra/uboot-imx51_to3.bin [11:52] apt-get source uboot-imx51 [11:52] why is that to3? [11:52] thx [11:52] let me try the bin first [11:52] because FSL updated it to the tape out 3 release [11:53] for the .bin the -to3 name is right ... for the binary package name not so much [11:54] but its unlikely that we'll see something >to3 before lucid i guess [11:56] so the get_part_data is busted somewhat [11:57] is it ? [11:57] its empty [11:57] e.g last dd is: [11:57] should make the first part end at the end of uboot [11:57] dd conv=notrunc bs= if=./boot.img of=out.bin seek=1 [11:58] "`(set -- $(get_part_data 1); echo "$2")`" [11:58] UBOOT_SIZE is correct ? [11:58] what is $2? [11:58] well. i reused $2 now for KERNEL ;) [11:58] so thats the prob i guess [11:58] but what is that ment to be? [11:59] good question, i have to check the redboot-install script [11:59] thats where it inherits from [11:59] PART1_END_B="`(set -- $(get_part_data 1); echo "$2")`" [11:59] i dont know what that means [11:59] what does the set -- do? [12:00] hmm. this doesnt create the .bin ;) [12:00] echo $2 should realte to the return of get_part_data [12:01] how to best create the .bin? [12:01] no, its the proof of concept script [12:01] just dd 4G? [12:01] well i am fixing that now [12:01] ;) [12:01] it expects that you either write to mmc directly or have a .img already [12:01] 4G ? [12:01] no, it should determine the size of the squashfs and roll the image based on that [12:01] dd if=/dev/null of=$IMAGE bs=1 count=$IMAGE_SIZE [12:01] like that? [12:02] thats all stuff i have to do when i sanitize it for debian-cd [12:02] sure [12:02] but is that ok? [12:02] bs=1 ? [12:02] thats 1 byte :) [12:02] use 1M [12:03] right [12:03] using IMAGE_SIZE and count=1 [12:03] i use the script directly on my mmc [12:03] so i dont care for images atm [12:04] and it cant be the scripts fault ... [12:04] given that your kernel works [12:04] well. so just dd doesnt work [12:04] file created is 0 bytes [12:04] dd if=/dev/null of=out.bin bs=1M count=1 [12:05] * asac feels dumb [12:05] if=/dev/null ? [12:05]