| shenki | armin76: is v8 being built for arm or in that error message? | 00:29 |
|---|---|---|
| shenki | s/arm or/arm or thumb/ | 00:29 |
| === bjf is now known as bjf-afk | ||
| zooko` | Hello people of #ubuntu-arm! | 03:51 |
| persia | Hey zooko` | 03:51 |
| zooko` | 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 |
| zooko` | Now, I want to know if the difference between these algorithms would be significant in terms of battery life. | 03:52 |
| persia | Depends on what you're doing in general. | 03:52 |
| zooko` | Supposing your ARM CPU is battery powered, and you execute one or the other of these algorithms a few thousand times. | 03:53 |
| persia | 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 |
| persia | If most of the processor time is spent rendering html, then it doesn't matter as much :) | 03:53 |
| zooko` | 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 |
| persia | I'm not sure there's a direct relation. | 03:54 |
| persia | Generally, the more you spin the processor, the more power it uses. | 03:55 |
| zooko` | Isn't it linear? | 03:55 |
| persia | But, depending on the processor, some operations may take more power than others. | 03:55 |
| zooko` | Hm, because of RAM access? | 03:55 |
| persia | No, because of processor design. | 03:55 |
| zooko` | The algorithm that takes more CPU cycles also uses tables in RAM a lot. | 03:55 |
| zooko` | Where the other one just does a whole bunch of arithmetic. | 03:55 |
| persia | 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 |
| persia | These are going to have different power characteristics for the same instruction sequence. | 03:56 |
| zooko` | Right. | 03:57 |
| zooko` | So this page here says http://www.arm.com/products/CPUs/ARM_Cortex-A8.html | 03:57 |
| zooko` | 0.59 mW/MHz. | 03:57 |
| zooko` | I think that means that 45,000 cycles times 1000 executions is | 03:57 |
| zooko` | 26 W | 03:57 |
| persia | 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:57 |
| zooko` | Yes there is a big disclaimer right below that. | 03:58 |
| zooko` | Do you know how to get a number drawn from a real implementation? | 03:58 |
| zooko` | Say, one running Ubuntu that you happen to have at hand? :-) | 03:58 |
| persia | 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:58 |
| persia | I wouldn't be able to measure that: there's something wonky with the battery meter in my device. | 03:59 |
| zooko` | Anyway, is 26 W a significant amount | 04:00 |
| persia | Depends on the battery. | 04:00 |
| zooko` | huh-oh it is time for me to stop using electric lights and computer screens. | 04:00 |
| persia | If you're talking about a watch, yes. If you're talking about a workstation, not really. | 04:00 |
| zooko` | How big is the battery in your favorite smartphone | 04:00 |
| persia | Plus, 26W doesn't really mean anything without the context of runtime. | 04:01 |
| zooko` | Yes it does -- I want to know 26W per battery recharge. | 04:01 |
| zooko` | Is that going to mean I have to recharge more often, or is it negligible. | 04:01 |
| persia | I don't believe in smartphones :) But let's say something like 3Wh | 04:01 |
| persia | So 26W would drain the battery in something like 20 minutes. | 04:02 |
| zooko` | This here nexus one thingie http://www.google.com/phone/static/en_US-nexusone_tech_specs.html says 1400 mAH | 04:02 |
| persia | At what voltage? | 04:02 |
| persia | I'd guess it's probably about 1.8V, so somewhere like 2.5Wh | 04:03 |
| zooko` | Hrm, doesn't say. | 04:03 |
| zooko` | Ok. | 04:03 |
| zooko` | Okay so this tells me that this quick kludgey approximation shows that this difference is significant. | 04:03 |
| zooko` | Which means I have to approximate more carefully if I want to know if it is *really* significant. :-) | 04:04 |
| persia | Well, if you need to run the operation constantly. | 04:04 |
| zooko` | The estimate I was just doing was "if you want to do this thing 1000 times in a row" | 04:04 |
| zooko` | and the thing costs either 15,000 CPU cycles or 60,000 CPU cycles each time. | 04:04 |
| persia | Right, but you measured it in watts, which is energy/time | 04:04 |
| persia | So without knowing how long it takes to do it 1000 times in a row, it's meaningless. | 04:05 |
| zooko` | 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 |
| persia | No. | 04:05 |
| persia | That's 6 minutes. | 04:05 |
| zooko` | Oh, I'm really confusde. | 04:05 |
| persia | OK. | 04:05 |
| zooko` | 2.5 Wh is ability to provide 2.5 W for 1 h. | 04:05 |
| zooko` | ? | 04:05 |
| persia | So, energy is voltage times amperage | 04:05 |
| persia | And power is energy divided by time | 04:05 |
| persia | So 2.5Wh is a measure of energy (power * time) | 04:06 |
| persia | It's 2.5W for an hour, or 25W for 6 minutes. | 04:06 |
| zooko` | Ok. | 04:06 |
| persia | Or 1W for 2.5 hours. Doesn't matter. | 04:06 |
| zooko` | Okay that makes sense. | 04:06 |
| persia | 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 |
| zooko` | Waitasec, why are batteries measured in power * time. Instead of just in power. | 04:08 |
| zooko` | Err. | 04:08 |
| persia | And if there is *no* latency, we can then estimate the number of operations available for a given energy budget. | 04:08 |
| zooko` | Hm. | 04:08 |
| persia | Because batteries contain an amount of energy, rather than an amount of power. | 04:08 |
| zooko` | I see. | 04:08 |
| persia | 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 |
| zooko` | That makes sense. | 04:09 |
| persia | So, the average 3Wh battery you buy on the street probably can't be configured to give 3MW even for 3.6 milliseconds. | 04:09 |
| persia | And it probably can't handle a draw of 1 nanowatt for centuries. | 04:10 |
| zooko` | :-) | 04:10 |
| persia | 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:10 |
| zooko` | Right. | 04:11 |
| persia | 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 |
| persia | Running 45,000 operations 1,000 times is about 45MOps | 04:13 |
| persia | So that's something like 26.5 mJ | 04:13 |
| zooko` | Right. | 04:13 |
| zooko` | No I think 26.5 J | 04:14 |
| persia | 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:14 | |
| persia | 0.59 * 45 = 26.5 | 04:15 |
| persia | So the unit doesn't change. | 04:15 |
| zooko` | I'll run real benchmarks for time, but I'm not sure how to benchmark energy usage. | 04:15 |
| persia | It's usually done with power meters on development boards. | 04:15 |
| zooko` | Yes, but you left out the 1000 time. | 04:16 |
| persia | 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 |
| zooko` | a thing which takes 45,000 operations is about 26.5 mJ, so 1000 of those is 26.5 J, right? | 04:16 |
| persia | No, 45,000 operations * 1,000 times is 45,000,000 operations, or 45Mops. | 04:16 |
| zooko` | Oh. | 04:16 |
| zooko` | So it takes only 0.59 mJ to do that thing 1000 times. | 04:17 |
| persia | Right, which isn't that much. | 04:17 |
| zooko` | Why did this come out looking small when the other calculation came out looking large. | 04:18 |
| persia | 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:18 |
| zooko` | Where did I get that 26 W number earlier... | 04:19 |
| persia | Dunno, but 26W would be running the operations all in parallel for soemthing like 10 days. | 04:20 |
| persia | (at least if all the operations consume 26mJ) | 04:20 |
| zooko` | Heh. | 04:21 |
| zooko` | Off by a million error. | 04:21 |
| persia | Minor mistake :) | 04:22 |
| zooko` | Okay so if our *new* estimate is reasonable then the difference between these two algorithms is insignificant. :-) | 04:22 |
| persia | Well, depends on usage. | 04:23 |
| persia | If it's the primary application of the processor, a factor of more than 3 can make a difference. | 04:23 |
| persia | If it just happens once in a while, it doesn't matter. | 04:23 |
| zooko` | What do you mean a factor of more than 3. | 04:50 |
| persia | You said 45,000 vs. 15,000 and that the 45,000 one needed more RAM. | 04:51 |
| persia | So I read that as a factor of more than 3: 3 times the operations + potentially additional effort to pull from RAM. | 04:51 |
| amitk | 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 |
| amitk | *things | 04:59 |
| zooko` | I see. | 04:59 |
| armin76 | shenki: for arm, i'm not using the thumb option, although i believe -march=armv5te includes thumb? | 06:19 |
| shenki | armin76: try forcing it with a -marm | 06:21 |
| shenki | armin76: are you building locally? | 06:21 |
| shenki | s/locally/natively/ | 06:22 |
| * persia thinks -marm vs. -mthumb are different | 06:24 | |
| shenki | i would agree :) one will force your compiler to emit 32-bit arm code, the other will force 16-bit thumb code | 06:25 |
| shenki | well, the 16bit ness fo thumb is a bit blurry if you're building for thumb2 | 06:26 |
| persia | Well, yeah, but -march doesn't necessarily imply either, as far as I understand. | 06:31 |
| persia | (although this depends on toolchain config, and armin76 has a special toolchain) | 06:32 |
| shenki | yeah | 06:33 |
| shenki | i think we're on the same page, i was just suggesting he try -marm to make sure that isn't the issue | 06:33 |
| * shenki is the author of the v8 build file | 06:34 | |
| armin76 | shenki: persia: will try, but its weird since on armv7 works fine | 07:07 |
| armin76 | both toolchains are different, thoguh, armv5te is softfloat while armv7 is not | 07:07 |
| armin76 | though* | 07:07 |
| armin76 | so what i think is that maybe the assembler is using armv7-only code | 07:08 |
| armin76 | but i'm no expert | 07:08 |
| armin76 | and chromium builds fine without v8 | 07:08 |
| armin76 | what does -marm do? | 07:11 |
| persia | -marm and -mthumb specify which instruction set to target for the given -march | 07:11 |
| persia | (mind you, there are defaults hidden in the toolchain config, but this lets one be explicit) | 07:11 |
| armin76 | kHH | 07:12 |
| armin76 | nsh | 07:12 |
| armin76 | err | 07:12 |
| armin76 | i don't use -mthumb either :P | 07:12 |
| persia | But do you know which is implied by your toolchain config? | 07:12 |
| persia | The suggestion was to override, in case this was the problem | 07:12 |
| armin76 | http://dpaste.com/141952/ | 07:13 |
| armin76 | sure, i'll try | 07:13 |
| asac | hi | 11:04 |
| asac | armin76: you say with armv7=1 it bult? | 11:04 |
| asac | or just on armv7 without that flag | 11:05 |
| asac | ogra: ;) | 11:05 |
| armin76 | asac: without the flag | 11:05 |
| ogra | asac, yo | 11:06 |
| ogra | asac, well, i built mkimage from the tree now on x86, but still no go :( | 11:07 |
| asac | ogra: try the command i gave you ;) | 11:07 |
| asac | or was that identitical? | 11:07 |
| ogra | it was | 11:07 |
| asac | 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 |
| ogra | 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 |
| asac | the name is important ;) | 11:08 |
| ogra | haha | 11:08 |
| asac | i swear | 11:08 |
| ogra | *g* | 11:08 |
| asac | it must be != Linux ;) | 11:08 |
| asac | shall i upload that uImageN somewhere? | 11:08 |
| ogra | no | 11:09 |
| ogra | i have your old one | 11:09 |
| asac | ok | 11:09 |
| asac | right | 11:09 |
| asac | i used mkimage from karmic x86 | 11:09 |
| asac | if you use that it has to work for you too ;) | 11:09 |
| ogra | ogra@osiris:~/Desktop/tmp$ mkimage -l ./uimage|grep ^Data | 11:09 |
| ogra | Data Size: 3062156 Bytes = 2990.39 kB = 2.92 MB | 11:09 |
| ogra | ogra@osiris:~/Desktop/tmp$ mkimage -l ./uImage.asac.908000000|grep ^Data | 11:09 |
| ogra | Data Size: 3063148 Bytes = 2991.36 kB = 2.92 MB | 11:09 |
| ogra | the size differs | 11:09 |
| * ogra wonders why | 11:09 | |
| asac | the new size is different yes | 11:09 |
| asac | let me check what the new one has | 11:10 |
| asac | i thin kit was a different kernel | 11:10 |
| asac | Data Size: 3062156 Bytes = 2990.39 kB = 2.92 MB | 11:10 |
| asac | thats the new | 11:10 |
| asac | that boots | 11:10 |
| ogra | same as mine | 11:10 |
| asac | md5sum? | 11:10 |
| ogra | and you used mkimage from the archive this time ? | 11:10 |
| asac | 8c1cf14ad6e4ef9c1479678c8e606872 uImageN | 11:10 |
| asac | ogra: yes. i used x86 karmic mkimage | 11:11 |
| ogra | ogra@osiris:~/Desktop/tmp$ md5sum ./uimage | 11:11 |
| ogra | 6134a0836cb224e3135acbd8c862ed00 ./uimage | 11:11 |
| * ogra doesnt get it | 11:11 | |
| asac | right. you have a different name | 11:11 |
| asac | ;) | 11:11 |
| ogra | really ... | 11:11 |
| * ogra now tries with a different name juts for giggles | 11:11 | |
| asac | haha | 11:11 |
| asac | i tell you it will work. also no ./ | 11:12 |
| asac | ;) | 11:12 |
| * ogra wishes he had a clue whats wrong | 11:13 | |
| ogra | 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 |
| ogra | no change | 11:15 |
| asac | afte3r loading ... http://paste.ubuntu.com/352834/ | 11:15 |
| asac | does that work for you? | 11:15 |
| asac | iminfo? | 11:15 |
| ogra | i cant load | 11:15 |
| ogra | :P | 11:15 |
| ogra | else i'd try | 11:15 |
| asac | please run the same command so we can compare md5sums | 11:16 |
| ogra | 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 |
| ogra | ... | 11:17 |
| ogra | ogra@osiris:~/Desktop/tmp$ md5sum uImageN | 11:17 |
| ogra | 807feee5a32a1805eccf4509574211e3 uImageN | 11:17 |
| asac | 8c1cf14ad6e4ef9c1479678c8e606872 uImageN | 11:17 |
| asac | odd | 11:17 |
| asac | ii uboot-mkimage 0.4 | 11:18 |
| ogra | same | 11:18 |
| ogra | wait | 11:18 |
| ogra | i use a -pae kernel | 11:18 |
| asac | 9184c83fbca680969199928bfcb8748d boot/vmlinuz-2.6.31-601-imx51 | 11:18 |
| ogra | i wonder if that could make any difference | 11:18 |
| asac | 791f2ca366f78922a9a981bd173ba3b9 /usr/bin/mkimage | 11:18 |
| ogra | ogra@osiris:~/Desktop/tmp$ md5sum boot/vmlinuz-2.6.31-601-imx51 | 11:18 |
| ogra | 9184c83fbca680969199928bfcb8748d boot/vmlinuz-2.6.31-601-imx51 | 11:18 |
| ogra | aha ! | 11:19 |
| asac | thats the same | 11:19 |
| ogra | oh, i looked at mkimage :P | 11:19 |
| ogra | 791f2ca366f78922a9a981bd173ba3b9 /usr/bin/mkimage | 11:19 |
| asac | yeah | 11:19 |
| asac | so its obviously your computer ;) | 11:19 |
| ogra | you are on i386 ? | 11:19 |
| asac | uname -a | 11:20 |
| asac | Linux tinya 2.6.32-02063202-generic #02063202 SMP Sat Dec 19 11:00:49 UTC 2009 i686 GNU/Linux | 11:20 |
| asac | hmm. i am on a .32 kernel | 11:20 |
| asac | would be odd if thats causing it | 11:20 |
| ogra | ogra@osiris:~/Desktop/tmp$ uname -a | 11:20 |
| ogra | 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 |
| asac | yeah that would be extremely odd ;) | 11:20 |
| ogra | still using keybuks toy kernel | 11:20 |
| asac | shall i reboot into the karmic kernel? | 11:21 |
| ogra | letr me try on a different machine first | 11:21 |
| asac | i would suggest that you use a vanilla kernel too rather: http://kernel.ubuntu.com/~kernel-ppa/mainline/ | 11:22 |
| asac | i have v2.6.32.2/ afair | 11:22 |
| asac | what does pae do? memory shuffeling? | 11:22 |
| ogra | using above 3G | 11:23 |
| ogra | so yes | 11:23 |
| asac | above 3g? | 11:23 |
| asac | http://en.wikipedia.org/wiki/Physical_Address_Extension | 11:24 |
| ogra | 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 |
| asac | you have more than 4g? | 11:24 |
| ogra | ogra@heizung:~/tmp$ md5sum uImageN | 11:24 |
| ogra | 1ad5cba13bce2849dd49bf70ad221bef uImageN | 11:24 |
| ogra | no, i have 4G | 11:24 |
| ogra | the std generic kernel can only address 3 | 11:24 |
| ogra | the machine i tried now is on lucid though | 11:25 |
| asac | yeah. thats a different mkimage version? | 11:25 |
| ogra | nope | 11:25 |
| asac | wow | 11:25 |
| ogra | mkimage wasnt updated ever | 11:25 |
| asac | so how can it be so different? | 11:25 |
| asac | can you try to boot the kernel i have? | 11:25 |
| asac | 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 |
| asac | though i am quite sure i used the .31 kernel from plain karmic as well | 11:26 |
| asac | 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:26 |
| asac | 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 |
| ogra | well, the lucid try makes no difference | 11:27 |
| asac | 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 |
| asac | yeah. but the checksum is different too. really odd that its different in first place | 11:27 |
| ogra | err | 11:27 |
| ogra | ogra@heizung:~/tmp$ uname -a | 11:27 |
| ogra | Linux heizung 2.6.27-7-generic #1 SMP Fri Oct 24 06:42:44 UTC 2008 i686 GNU/Linux | 11:27 |
| ogra | hmm, why didnt that get upgraded | 11:27 |
| asac | let me see if the same run yields the same checksum | 11:27 |
| asac | so | 11:28 |
| asac | seems they add a timestamp or something | 11:28 |
| asac | so the checksum is useless | 11:28 |
| ogra | indeed | 11:28 |
| * ogra slaps forehead | 11:28 | |
| ogra | Created: Thu Jan 7 12:23:59 2010 | 11:28 |
| ogra | sigh | 11:28 |
| asac | yeah | 11:28 |
| asac | seeing it now too ;) | 11:28 |
| asac | maybe binary diff ;) | 11:29 |
| ogra | still doesnt explain why it doesnt work | 11:29 |
| ogra | it has to work with hardy btw | 11:29 |
| ogra | thats what the builder runs | 11:29 |
| ogra | give me your x86 created uImage | 11:30 |
| asac | http://people.canonical.com/~asac/tmp/uImageN.1 | 11:30 |
| asac | thats the one | 11:30 |
| asac | be back in 5 | 11:31 |
| ogra | hmm, hangs too here | 11:32 |
| asac | well. it hanged for me for the first try too | 11:33 |
| ogra | you used my script to create the card ? | 11:34 |
| asac | after reset it worked | 11:34 |
| ogra | i.e. same filesystem | 11:34 |
| asac | i did it manually at some point | 11:34 |
| asac | one sec | 11:34 |
| ogra | hmm | 11:34 |
| ogra | FAT32 here | 11:34 |
| asac | http://paste.ubuntu.com/352846/ | 11:35 |
| asac | so ... try it a few times | 11:36 |
| asac | maybe the uboot build you did is less reliable wrt to SD | 11:36 |
| asac | than mine | 11:36 |
| asac | do you have the script somewhere? | 11:37 |
| ogra | what script ? | 11:37 |
| asac | e.g. something i can use to create it like you do? | 11:37 |
| ogra | ah | 11:37 |
| ogra | its on the spec | 11:37 |
| asac | at best a script called: mkbootfloppy | 11:37 |
| asac | yes. i used that manually | 11:37 |
| ogra | http://paste.ubuntu.com/352850/ | 11:37 |
| ogra | the uboot binary is still stuck in NEW | 11:38 |
| asac | yes. our archive admin is lagging ;) | 11:38 |
| asac | hehe | 11:38 |
| asac | why is it in new? | 11:39 |
| asac | shouldnt we reuse package names? | 11:39 |
| ogra | the binary has a hardcoded version thanks to NC | 11:39 |
| asac | anyway. the other image still loads for you? | 11:39 |
| asac | e.g. the .asac uImage | 11:39 |
| asac | ? | 11:39 |
| * ogra tries that again | 11:39 | |
| asac | ogra: did you fix that this time? | 11:39 |
| asac | e.g. without version? | 11:39 |
| ogra | nope | 11:39 |
| ogra | i updated it ... | 11:40 |
| asac | so next time it would be thanks to you ;) | 11:40 |
| ogra | indeed :) | 11:40 |
| ogra | BBG U-Boot > fatload mmc 0:2 0x90800000 /uimage | 11:41 |
| ogra | reading /uimage | 11:41 |
| ogra | 3063212 bytes read | 11:41 |
| ogra | no prob with your old one | 11:41 |
| asac | try the new one right after that | 11:42 |
| asac | version | 11:43 |
| asac | U-Boot 2009.08 (Dec 07 2009 - 07:37:24) | 11:43 |
| ogra | U-Boot 2009.08 (Jan 06 2010 - 09:44:19) | 11:44 |
| ogra | same thing | 11:44 |
| ogra | built on the babbge from the updated source package | 11:44 |
| ogra | did you build it with -marm ? | 11:46 |
| asac | ogra: i just build it with the _bbg rule ... no tweaks added | 11:47 |
| ogra | on lucid ? | 11:47 |
| ogra | you need tewaks | 11:47 |
| ogra | *tweaks | 11:47 |
| asac | well. i tweaked some config | 11:48 |
| ogra | there are some inline finctions gcc will choke on | 11:48 |
| ogra | *func | 11:48 |
| asac | hmm | 11:48 |
| asac | anyway. let me fix your script to do all oob and then try | 11:48 |
| ogra | grab the sourcepackage for uboot-imx | 11:49 |
| ogra | 1000_fix_gcc_4.4_compatibility.patch is needed | 11:49 |
| ogra | i dont get how you got it building without that | 11:49 |
| ogra | at least on lucid | 11:49 |
| asac | ogra: put your uboot.bin somewhere ;) | 11:50 |
| asac | hmm | 11:50 |
| asac | ok | 11:50 |
| asac | i dont have a lucid install atm. only chroot. but i can try that i guess | 11:51 |
| asac | have .dsc link? | 11:51 |
| asac | ogra: ? | 11:51 |
| ogra | http://people.canonical.com/~ogra/uboot-imx51_to3.bin | 11:51 |
| ogra | apt-get source uboot-imx51 | 11:52 |
| asac | why is that to3? | 11:52 |
| asac | thx | 11:52 |
| asac | let me try the bin first | 11:52 |
| ogra | because FSL updated it to the tape out 3 release | 11:52 |
| ogra | for the .bin the -to3 name is right ... for the binary package name not so much | 11:53 |
| ogra | but its unlikely that we'll see something >to3 before lucid i guess | 11:54 |
| asac | so the get_part_data is busted somewhat | 11:56 |
| ogra | is it ? | 11:57 |
| asac | its empty | 11:57 |
| asac | e.g last dd is: | 11:57 |
| ogra | should make the first part end at the end of uboot | 11:57 |
| asac | dd conv=notrunc bs= if=./boot.img of=out.bin seek=1 | 11:57 |
| asac | "`(set -- $(get_part_data 1); echo "$2")`" | 11:58 |
| ogra | UBOOT_SIZE is correct ? | 11:58 |
| asac | what is $2? | 11:58 |
| asac | well. i reused $2 now for KERNEL ;) | 11:58 |
| asac | so thats the prob i guess | 11:58 |
| asac | but what is that ment to be? | 11:58 |
| ogra | good question, i have to check the redboot-install script | 11:59 |
| ogra | thats where it inherits from | 11:59 |
| asac | PART1_END_B="`(set -- $(get_part_data 1); echo "$2")`" | 11:59 |
| asac | i dont know what that means | 11:59 |
| asac | what does the set -- do? | 11:59 |
| asac | hmm. this doesnt create the .bin ;) | 12:00 |
| ogra | echo $2 should realte to the return of get_part_data | 12:00 |
| asac | how to best create the .bin? | 12:01 |
| ogra | no, its the proof of concept script | 12:01 |
| asac | just dd 4G? | 12:01 |
| asac | well i am fixing that now | 12:01 |
| asac | ;) | 12:01 |
| ogra | it expects that you either write to mmc directly or have a .img already | 12:01 |
| ogra | 4G ? | 12:01 |
| ogra | no, it should determine the size of the squashfs and roll the image based on that | 12:01 |
| asac | dd if=/dev/null of=$IMAGE bs=1 count=$IMAGE_SIZE | 12:01 |
| asac | like that? | 12:01 |
| ogra | thats all stuff i have to do when i sanitize it for debian-cd | 12:02 |
| asac | sure | 12:02 |
| asac | but is that ok? | 12:02 |
| ogra | bs=1 ? | 12:02 |
| ogra | thats 1 byte :) | 12:02 |
| ogra | use 1M | 12:02 |
| asac | right | 12:03 |
| asac | using IMAGE_SIZE and count=1 | 12:03 |
| ogra | i use the script directly on my mmc | 12:03 |
| ogra | so i dont care for images atm | 12:03 |
| ogra | and it cant be the scripts fault ... | 12:04 |
| ogra | given that your kernel works | 12:04 |
| asac | well. so just dd doesnt work | 12:04 |
| asac | file created is 0 bytes | 12:04 |
| asac | dd if=/dev/null of=out.bin bs=1M count=1 | 12:04 |
| * asac feels dumb | 12:05 | |
| ogra | if=/dev/null ? | 12:05 |
| ogra | better try zero | 12:05 |
| asac | great | 12:05 |
| ogra | sorry, didnt spot that above | 12:05 |
| asac | now things happen | 12:05 |
| ogra | note that BOOT_SIZE is set to 17M atm | 12:06 |
| ogra | so the image you write to should be 18M at least | 12:06 |
| asac | http://paste.ubuntu.com/352869/ | 12:07 |
| asac | so that feels better | 12:07 |
| ogra | looks ok | 12:07 |
| ogra | you added a mkimage -l :) | 12:08 |
| * asac pumps it to the sd | 12:08 | |
| asac | oh right | 12:08 |
| asac | good idea | 12:08 |
| ogra | or just a mkimage ? | 12:08 |
| asac | ogra: it already dumped that there | 12:09 |
| asac | mkimage itself does that at the end | 12:09 |
| asac | ;) | 12:09 |
| ogra | right, so you added the mkimage call :) | 12:10 |
| asac | ok ... dd'ing | 12:10 |
| asac | yes | 12:10 |
| asac | everything oob | 12:10 |
| ogra | apart from the proper defaults in uboot :) | 12:10 |
| asac | cat mkubootimg.sh | pastebinit | 12:10 |
| asac | http://pastebin.com/f3e4d51a7 | 12:10 |
| ogra | great | 12:11 |
| asac | hmm didnt work that great | 12:11 |
| asac | 1 512B 137kB 136kB primary | 12:11 |
| asac | 2 137kB 16.8MB 16.6MB primary lba | 12:11 |
| asac | fat32 is missing | 12:11 |
| ogra | whats that ? fdisk -l ? | 12:12 |
| asac | udo parted /dev/mmcblk0 print | 12:12 |
| asac | s | 12:12 |
| asac | sudo parted /dev/mmcblk0 print | 12:12 |
| asac | after dding | 12:12 |
| asac | same for the .bin directly | 12:13 |
| ogra | weird | 12:13 |
| ogra | line 52 in your script should have created it | 12:13 |
| ogra | err | 12:13 |
| * asac adds a set -e | 12:13 | |
| ogra | and line 56 indeed | 12:13 |
| asac | seems to not error at least | 12:14 |
| asac | parted -s out.bin mkpart primary fat32 136704B 16777216B | 12:14 |
| asac | thats what it runs | 12:14 |
| ogra | looks ok | 12:14 |
| asac | part data: 512B 136703B 136192B | 12:15 |
| asac | why is boot size 16M? | 12:17 |
| asac | hmm | 12:17 |
| ogra | just because :) | 12:17 |
| asac | thats what is printed | 12:17 |
| ogra | you can pick any value you like | 12:17 |
| asac | just not fat32 | 12:17 |
| ogra | 16M seems to well fit a kernel and initrd ... was enough for my testing | 12:17 |
| ogra | boot size should in the end actually be the image size | 12:18 |
| ogra | we only need one vfat partition for squashfs, kernel and initrd | 12:18 |
| ogra | i just picked a value that leaves enough space | 12:18 |
| asac | mkdosfs ./boot.img | 12:19 |
| asac | guess the dd where the boot.img gest dded wipes the part table bits | 12:19 |
| ogra | has nothing to do with parted | 12:19 |
| ogra | shouldnt | 12:19 |
| asac | oh | 12:20 |
| asac | ;) | 12:20 |
| asac | now it probably works ;) | 12:20 |
| ogra | what was missing ? | 12:20 |
| asac | well. i had an echo before the final dd ;) | 12:20 |
| asac | 2 137kB 16.8MB 16.6MB primary fat16 lba | 12:20 |
| asac | odd that its fat16 now | 12:20 |
| ogra | yeah | 12:20 |
| asac | is that normal? | 12:20 |
| ogra | nope | 12:20 |
| ogra | oh, wait, it is | 12:21 |
| ogra | 2 137kB 16,8MB 16,6MB primary fat16 lba | 12:21 |
| ogra | thats my sd | 12:21 |
| asac | ok let me use -F 32 | 12:21 |
| ogra | cfdisk will report fat32 though | 12:21 |
| ogra | or fdisk | 12:21 |
| asac | WARNING: Not enough clusters for a 32 bit FAT! | 12:21 |
| asac | but it worked | 12:22 |
| asac | 2 137kB 16.8MB 16.6MB primary fat32 lba | 12:22 |
| ogra | i guess we need to properly work with cylinder sizes | 12:23 |
| ogra | i.e. the first partition needs to become big enough to end at a cylinder | 12:23 |
| asac | ok | 12:24 |
| asac | so your 16m was just too small | 12:24 |
| ogra | boots ? | 12:24 |
| asac | 60 is better | 12:24 |
| asac | not there yet ;) | 12:24 |
| ogra | to small ? | 12:25 |
| ogra | for a 2.5M kernel binary ? | 12:25 |
| asac | for fat32 | 12:25 |
| ogra | oh | 12:25 |
| asac | seems it needs a minimums size > 16m | 12:25 |
| asac | i used 60 and the warning is gone | 12:25 |
| ogra | ah | 12:25 |
| asac | now dding | 12:25 |
| ogra | cool | 12:25 |
| asac | lets hope | 12:25 |
| asac | good | 12:26 |
| asac | it automounts here | 12:26 |
| asac | good... uboot prompt ;) | 12:26 |
| asac | http://paste.ubuntu.com/352878/ | 12:27 |
| asac | hmm | 12:27 |
| asac | invalid FAT entry | 12:27 |
| asac | but it read it | 12:27 |
| asac | Bad CRC | 12:27 |
| asac | darn ;) | 12:27 |
| asac | now i am not sure if its the SD card | 12:28 |
| asac | it never liked me much | 12:28 |
| asac | http://paste.ubuntu.com/352881/ | 12:28 |
| asac | wondering if i should just wipe the windows CE sandisk | 12:28 |
| asac | will i need that at some point? | 12:29 |
| asac | have no place to dd it to | 12:29 |
| ogra | you have a winCE sandisk ? | 12:29 |
| ogra | the b2.5 shipped with an ubuntu one | 12:29 |
| asac | http://pastebin.com/f63ce246d | 12:29 |
| asac | thats the last version | 12:29 |
| asac | yes | 12:29 |
| asac | i have two: windows CE + ubuntu | 12:29 |
| ogra | well, someone on the team will still have one i guess | 12:30 |
| asac | good point | 12:30 |
| ogra | JamieBennett, did you keep your WinCE babbage SD ? | 12:30 |
| asac | JamieBennett: can you keep your winCE SD? | 12:30 |
| asac | hehe | 12:30 |
| ogra | heh | 12:30 |
| asac | let me go through the script again | 12:31 |
| asac | maybe we truncate something | 12:31 |
| asac | let me try without F32 | 12:31 |
| ogra | i just tried with a manually created fat32 part (60M) | 12:32 |
| ogra | no change here for my uimage | 12:32 |
| asac | so fdisk really says 32 | 12:32 |
| ogra | Verifying Checksum ... Bad Data CRC | 12:32 |
| ogra | ERROR: can't get kernel image! | 12:32 |
| ogra | thats what i get after a reset | 12:32 |
| * ogra needs a break and fresh pain killers | 12:33 | |
| ogra | back soon | 12:34 |
| asac | kk | 12:35 |
| JamieBennett | ogra, asac: no, ran out of SD's and presumed it wasn't needed | 12:51 |
| JamieBennett | I think you can download it can't you? | 12:51 |
| asac | no clue | 12:51 |
| asac | its licensed i guess | 12:51 |
| JamieBennett | asac: http://www.microsoft.com/windowsembedded/en-us/products/windowsce/getting-started.mspx | 12:53 |
| JamieBennett | need to register though :( | 12:53 |
| asac | who knows if that is really the same anyway | 12:56 |
| asac | could be a custom build | 12:56 |
| JamieBennett | asac: indeed | 12:57 |
| asac | http://pastebin.com/f3bc21930 | 12:58 |
| asac | please run that like | 12:58 |
| asac | sh mkubootimg.sh out.bin data/vmlinuz-2.6.31-601-imx51 data/uboot-imx51_to3.bin 110M | 12:58 |
| asac | since you probably have a SD for experimenting ;) | 12:58 |
| asac | ls data/ | 12:58 |
| asac | uboot-imx51_to3.bin vmlinuz-2.6.31-601-imx51 | 12:58 |
| asac | ls data/ | 12:59 |
| asac | uboot-imx51_to3.bin vmlinuz-2.6.31-601-imx51 | 12:59 |
| asac | http://people.canonical.com/~ogra/uboot-imx51_to3.bin | 12:59 |
| asac | vm linuz just from the .deb | 12:59 |
| * asac dds wince somewhere | 13:00 | |
| === mcasadevall is now known as NCommander | ||
| JamieBennett | asac: Just checked, wince is on a disk in the bsp | 13:05 |
| JamieBennett | disk as in dvd (or cdrom, not sure) | 13:06 |
| ogra | re | 13:11 |
| ogra | asac, does it boot ? | 13:11 |
| asac | bad fatfs still | 13:13 |
| asac | but thats probably my SD card | 13:13 |
| asac | will now wipe the sandisk | 13:14 |
| asac | btw, saturn has two 4g sandisk for 12 EUR atm | 13:14 |
| asac | ;) | 13:14 |
| asac | yesterday TV advertisement | 13:14 |
| ogra | heh | 13:14 |
| asac | echo $((100000 * 512)) 1200000 | 13:15 |
| asac | 1200000 | 13:15 |
| asac | why is that? | 13:15 |
| asac | err | 13:15 |
| asac | that was two lines | 13:15 |
| asac | echo $((100000 * 512)) | 13:15 |
| asac | 1200000 | 13:15 |
| ogra | hmm | 13:15 |
| ogra | use bc insteadc ? | 13:15 |
| ogra | *instead | 13:15 |
| asac | bc? | 13:15 |
| asac | we use that syntax everywhere in the script | 13:16 |
| ogra | ogra@osiris:~/Desktop/tmp$ echo 1+1 |bc | 13:16 |
| ogra | 2 | 13:16 |
| asac | yes. but we use that everwhere | 13:16 |
| ogra | right | 13:16 |
| asac | wanted to ensure that its properly cylinder aligned | 13:16 |
| ogra | no idea why it prints 120000 | 13:16 |
| asac | but that / 512 * 512 doesnt work | 13:16 |
| asac | our arithmetics are unreliable | 13:16 |
| ogra | i get 5120000 here | 13:16 |
| ogra | as it should be | 13:17 |
| JamieBennett | ogra: as do I | 13:17 |
| asac | i am in bash | 13:17 |
| asac | you are in posh? | 13:17 |
| asac | ;) | 13:17 |
| ogra | asac, is using an upstream kernel ... missing the ubuntu-count patches :P | 13:17 |
| asac | haha | 13:17 |
| asac | and the uImage fixup mem patch | 13:17 |
| ogra | i'm in bash indeed | 13:18 |
| asac | thats the trade | 13:18 |
| asac | ;) | 13:18 |
| ogra | heh | 13:18 |
| asac | no calc, but good images | 13:18 |
| ogra | so your system cant count but produce proper images | 13:18 |
| ogra | ogra@osiris:~/Desktop/tmp$ sh -c "echo $((100000 * 512))" | 13:19 |
| ogra | 51200000 | 13:19 |
| ogra | dash is fine too | 13:19 |
| asac | ok trying | 13:19 |
| asac | so ... sandisk doesnt have probs like that ... but i hang on loading ;) | 13:20 |
| asac | so bash is broken for me ;) | 13:21 |
| asac | works in sh | 13:21 |
| ogra | intresting | 13:21 |
| ogra | lucid ? | 13:21 |
| ogra | or karmic | 13:21 |
| ogra | eek ! | 13:23 |
| ogra | i totally forgot we need a MIR for uboot ... its not in main yet | 13:24 |
| asac | karmic | 13:24 |
| ogra | asac, do you happen to have a buildlog from your uboot build ? | 13:25 |
| ogra | i noticed that gcc seems to forcefully be set to -march=armv5 in mine | 13:25 |
| asac | no ... all that was wiped | 13:28 |
| asac | have to reboot ... kernel doesnt release the SD anymore | 13:29 |
| * ogra drops the thumb disabling patch and checks if it FTBFS | 13:30 | |
| asac | so how to best figure cylinder boundaries? | 13:33 |
| ogra | fdisk probably | 13:35 |
| * ogra sighs, where does the -marm come from | 13:35 | |
| JamieBennett | anyone played with changing the initramfs on lucid? When I call sudo update-initramfs.distrib -u I get 5 "Can't open /scripts/casper-functions" error messages | 13:35 |
| ogra | not yet, no | 13:35 |
| JamieBennett | :( | 13:36 |
| asac | 32768 | 13:36 |
| asac | Units = cylinders of 64 * 512 = 32768 bytes | 13:36 |
| asac | let me try to align that | 13:36 |
| ogra | hmm -marm seems to be set upstream | 13:38 |
| asac | ogra: odd is that mkpart interprets last argument as size | 13:56 |
| asac | _while_ man says its "end" | 13:56 |
| asac | ogra: so have the same prob as you if i use that it seems | 14:05 |
| asac | the difference is that the SD that works really has a good partition table | 14:05 |
| asac | Device Boot Start End Blocks Id System | 14:06 |
| asac | /dev/mmcblk0p1 1 256 16383+ da Non-FS data | 14:06 |
| asac | /dev/mmcblk0p2 257 10587 661184 c W95 FAT32 (LBA) | 14:06 |
| ogra | ok | 14:13 |
| ogra | so its not uboot's fault, thats good to know | 14:14 |
| asac | darn. i killed my good SD by accident :( | 14:15 |
| asac | ogra: uboots fault? | 14:15 |
| asac | its our script that creates bad partitions | 14:15 |
| asac | i dont think its uboot... so far at least ;) | 14:15 |
| ogra | i was worried its the uboot in the package vs your home rolled one | 14:15 |
| asac | ogra: well. the image i gave you worked with your uboot :) | 14:15 |
| ogra | let me roll an SD manually | 14:15 |
| asac | darn i hate me for killing my uboot SD | 14:16 |
| asac | :( | 14:16 |
| asac | so my original uimage doesnt load either | 14:19 |
| asac | i think its your uboot bin | 14:19 |
| asac | or really the partition table. because mine is now busted too :( | 14:19 |
| ogra | HOORAYYY | 14:28 |
| ogra | http://paste.ubuntu.com/352937/ | 14:28 |
| ogra | wiping the table and just creating a vfat partition with gparted with enough offset and my images work too | 14:29 |
| ogra | so its definately the poartitioning | 14:29 |
| ogra | asac, well, for the live image we could just leave the first partition and only make sure the second one has enough offset | 14:31 |
| ogra | i.e. use a fixed value of say 500k | 14:32 |
| ogra | that should be enough to fit uboot in | 14:32 |
| ogra | or even 200k | 14:33 |
| ogra | no reason uboot should ever grow beyond that | 14:33 |
| * ogra takes asacs script and just sets UBOOT_SIZE to a fixed value ... lets see | 14:35 | |
| asac | i did all that already ... didnt help | 14:46 |
| asac | darn | 14:46 |
| asac | so i didnt wipe my uboot image (still have that | 14:46 |
| asac | but my boot floppy for my production system :( | 14:46 |
| ogra | aww | 14:47 |
| asac | ogra: so now i double checked | 14:48 |
| asac | the uboot thing that works really has good partition bounds | 14:48 |
| ogra | right | 14:48 |
| asac | http://paste.ubuntu.com/352945/ | 14:49 |
| asac | no complain | 14:49 |
| ogra | yep, same here | 14:49 |
| asac | same here? | 14:49 |
| asac | thought yours doesnt work ;) | 14:49 |
| ogra | read above | 14:49 |
| asac | how did you produce your partition table? | 14:49 |
| ogra | gparted | 14:49 |
| ogra | manually | 14:49 |
| asac | ok so how can we find good cylinder bounds? | 14:50 |
| ogra | i dd'ed uboot to the initialized SD | 14:50 |
| asac | seems that cylinder size is target media specific | 14:50 |
| ogra | thern created a partition with offset in gparted | 14:50 |
| ogra | copied uimage in there and it works with every uimage i have | 14:50 |
| asac | so ... why do we create this first partition with the odd fs id again? | 14:51 |
| * ogra checks if there is a chance we can use ext2 for /boot | 14:51 | |
| ogra | asac, to protect the space where the bootloader lives | 14:51 |
| asac | we need to enable ext2 in uboot for that | 14:51 |
| ogra | right | 14:51 |
| ogra | not sure how well it works | 14:51 |
| asac | protect in what way? | 14:51 |
| asac | if we just create one vfat partition with enough offset | 14:51 |
| ogra | from partitioning apps | 14:51 |
| asac | how is that not enough ? | 14:51 |
| asac | ok | 14:52 |
| ogra | if we re-use the SD later as bootfloppy that space should be protected | 14:52 |
| ogra | if we dont, we dont really need to care imho | 14:52 |
| asac | so ... how can we do that properly? seems that cylinder size is depending on the SD card | 14:52 |
| asac | i had one with 32K | 14:52 |
| asac | this one is 64K | 14:52 |
| ogra | it doesnt depend on the card ... | 14:52 |
| ogra | if you get it right in the image file | 14:52 |
| asac | really... then why do i have two different values? | 14:52 |
| asac | hmm | 14:53 |
| ogra | because you look at the partition table | 14:53 |
| ogra | the one thats initialized on the card | 14:53 |
| asac | yes | 14:53 |
| asac | so parted can set that? | 14:53 |
| ogra | if that lives in the image it shouldnt matter | 14:53 |
| armin76 | persia: shenki: fails exactly the same way with -marm | 14:53 |
| ogra | let me look into some docs | 14:53 |
| asac | ogra: does bbg just run the bootloader from 1024 ... or from first partition? | 14:53 |
| asac | probably doesnt matter ... fdisk -l on the .bin says cylinder size that is full | 14:54 |
| ogra | babbage doesnt care about partitions | 14:54 |
| ogra | it just tries to find the bootloader directly after the MBR | 14:55 |
| ogra | well, actually at the start of the SD but skips the MBR | 14:55 |
| armin76 | ogra: may i ask whats the point on supporting the babbage if real users are going to have it? will all the devices based on imx51 work like the babbage? | 14:56 |
| ogra | similar at least | 14:57 |
| armin76 | s/users are go/users aren't go/ | 14:57 |
| ogra | its a developer platform | 14:57 |
| armin76 | you guys have any plan on qualcomm stuff? | 14:58 |
| ogra | nope | 15:03 |
| ogra | asac, i think we need to shuffle around with the cylinders and heads a bit with fdisk | 15:04 |
| asac | with fdisk? | 15:06 |
| asac | parted is too dumb? | 15:06 |
| ogra | $imagesize_in_bytes / 255 / 63 / 512 = $number_of_cylinders | 15:10 |
| ogra | we somehow need to let the partition table know about that number of cylinders | 15:10 |
| asac | hmm | 15:12 |
| asac | ok | 15:12 |
| ogra | checking how parted can do that | 15:13 |
| asac | ogra: i am not sure that its really in the partition table | 15:13 |
| asac | if i check on the .bin | 15:13 |
| asac | its a different number than after dding it to SD | 15:14 |
| ogra | use fdisk -C | 15:14 |
| asac | i see that number with fdisk -l too | 15:14 |
| ogra | i dont get why it works with the reboot images | 15:15 |
| ogra | Device Boot Start End Blocks Id System | 15:15 |
| ogra | lucid-desktop-armel+imx51.img1 1 512 32767+ da Non-FS data | 15:15 |
| ogra | lucid-desktop-armel+imx51.img2 513 10591 645056 c W95 FAT32 (LBA) | 15:15 |
| asac | how are the bounds with B ? | 15:16 |
| asac | most likely they are just right? | 15:16 |
| ogra | the script is the same | 15:16 |
| ogra | the one we use to create the image | 15:16 |
| ogra | and we dont shuffle the partitions or the table in it | 15:17 |
| asac | damn. need to reboot again. this mmc driver stuff is really immature | 15:17 |
| asac | thats actually why i am running .32 kernel as its better there | 15:18 |
| ogra | on your laptop ? | 15:18 |
| asac | yes | 15:18 |
| ogra | never had instabilities | 15:18 |
| asac | if i dont unmount and unplug it sometimes hangs badly | 15:18 |
| ogra | oh, i always unmount | 15:18 |
| ogra | i'm lazy, using nautilus :) | 15:18 |
| asac | nautilus "eject" never worked for me | 15:19 |
| asac | unmount worked | 15:19 |
| asac | ok reboot | 15:19 |
| asac | most annoying after every reboot: | 15:25 |
| asac | screen /dev/ttyUSB0 115200 | 15:25 |
| asac | Cannot make directory '/var/run/screen': Permission denied | 15:25 |
| asac | ls -l /var/run/screen | 15:26 |
| asac | ls: cannot access /var/run/screen: No such file or directory | 15:26 |
| armin76 | asac: btw, i found out that chromium needs to have write access to /dev/shm | 15:26 |
| asac | sudo mkdir /var/run/screen | 15:26 |
| asac | yes | 15:26 |
| asac | thats why its not working in a bindmounted chroot | 15:26 |
| asac | because bindmount somewhat fails to keep permissions for /dev | 15:26 |
| ogra | use minicom not screen :) | 15:27 |
| asac | well. screen always worked ... just started to fall apart 2 month ago :( | 15:27 |
| asac | i blame upstart ;) | 15:27 |
| armin76 | asac: guess you need to bindmount /dev/shm as well, like you have to do with /dev/pts | 15:27 |
| ogra | yeah, always a good candidate | 15:28 |
| asac | armin76: that alone doesnt help | 15:29 |
| asac | i tried that ;) | 15:29 |
| asac | ogra: so loading uramdisk hangs | 15:29 |
| asac | ogra: sure gzip is enabled? | 15:29 |
| asac | you said you werent sure | 15:29 |
| armin76 | asac: wfm | 15:29 |
| armin76 | asac: blame upstart as well :D | 15:29 |
| armin76 | just tried it | 15:30 |
| asac | you are right | 15:31 |
| asac | have that mounted in lucid chroot | 15:31 |
| armin76 | asac fails | 15:31 |
| armin76 | i win | 15:31 |
| asac | you are late. thats all ;) | 15:32 |
| asac | armin76_the_lagger | 15:32 |
| armin76 | i don't have so many boards as you do, slacker | 15:32 |
| asac | ogra: try this: mkimage -A arm -O linux -T ramdisk -C gzip -a 0x0 -e 0x0 -n LinuxRocks -d boot/initrd.img-2.6.31-105-imx51 uRamdisk | 15:33 |
| asac | it doesnt load | 15:33 |
| asac | let me unpack that and use none | 15:33 |
| ogra | thats what debian on the sheevaplug uses: mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs -d initrd.img-2.6.29-2-kirkwood uInitrd | 15:34 |
| ogra | pretty much the same | 15:35 |
| asac | yes. i surely got it loading | 15:35 |
| asac | maybe i unpacked it | 15:35 |
| ogra | why would you ? | 15:36 |
| asac | because maybe uboot doesnt like gzip ;) | 15:36 |
| asac | yep | 15:36 |
| asac | taht worked | 15:36 |
| asac | gunzip the initrd | 15:36 |
| asac | put it in as none | 15:36 |
| asac | then it loads | 15:36 |
| ogra | well, i'm still chewing on the partitioning | 15:36 |
| asac | yeah | 15:36 |
| ogra | so you get to busybox ? | 15:37 |
| asac | i somehow need to get a boot floppy ;) | 15:37 |
| asac | as i wiped it and cannot even boot in my great prod environment anymore | 15:37 |
| asac | no | 15:37 |
| asac | i am now trying ;) | 15:37 |
| * asac sets root=UUID=6483f06d-1216-43df-931f-faddc9c1db27 | 15:37 | |
| asac | ogra: it doesnt like that root :( http://paste.ubuntu.com/352971/ | 15:40 |
| asac | so /dev/ram? | 15:40 |
| ogra | it doesnt find the initramfs | 15:41 |
| asac | hmm. thought i loaded it | 15:41 |
| ogra | but doesnt use it | 15:41 |
| asac | http://paste.ubuntu.com/352973/ | 15:41 |
| asac | thats what i did | 15:41 |
| * asac slaps himself | 15:43 | |
| asac | plugging the usb disk to the board might help ;) | 15:44 |
| asac | does that | 15:44 |
| ogra | not really | 15:44 |
| ogra | your initramfs doesnt get executed | 15:44 |
| ogra | by the kernel | 15:44 |
| asac | so what is wrong ;)? | 15:46 |
| asac | the address maybe? | 15:46 |
| asac | initrd=... wrong? | 15:47 |
| ogra | the latter i suspect | 15:47 |
| ogra | wait, try loading uinitrd first | 15:49 |
| ogra | flip the adresses in bootm | 15:49 |
| ogra | sigh, i really dont get that partition thing | 15:49 |
| ogra | why does it work with the redboot images | 15:50 |
| asac | uninitrd first? | 15:51 |
| ogra | flip the adresses | 15:53 |
| asac | bootm [addr [arg ...]] | 15:54 |
| asac | - boot application image stored in memory | 15:54 |
| asac | passing arguments 'arg ...'; when booting a Linux kernel, | 15:54 |
| asac | 'arg' can be the address of an initrd image | 15:54 |
| ogra | did you try it ? | 15:55 |
| ogra | bootm 0x90B00000 0x90008000 | 15:55 |
| asac | i read the doc and it says that initrd is second ;) | 15:56 |
| asac | now trying | 15:56 |
| asac | Wrong Image Type for bootm command | 15:57 |
| asac | ERROR: can't get kernel image! | 15:57 |
| asac | so expdected | 15:57 |
| asac | now trying to not load ramdisk, but rather loading it from vfat | 15:57 |
| ogra | ok, was worth a try | 15:57 |
| asac | great | 16:01 |
| asac | end of work | 16:01 |
| asac | board doesnt show any sign of live anymore :( | 16:01 |
| JamieBennett | asac: wait, I'm not the only one to have kill a board now ;) | 16:01 |
| ogra | did you trash your SD ? | 16:02 |
| asac | what do you mean? | 16:02 |
| ogra | note that it wont stay on if it doesnt find the bootrecord | 16:02 |
| asac | i dont see any lamp if i push on the button :( | 16:02 |
| ogra | oh | 16:02 |
| asac | yes | 16:02 |
| asac | but no lamp goes on | 16:02 |
| ogra | how did you manage that ? | 16:02 |
| asac | i dont know | 16:03 |
| asac | i put in the sd | 16:03 |
| * JamieBennett notes he killed his with the wrong power lead not in software | 16:03 | |
| * ogra hasnt seen anyone fry a board apart from using over-power | 16:03 | |
| JamieBennett | :) | 16:03 |
| armin76 | lol | 16:03 |
| asac | overpower? | 16:03 |
| armin76 | flowerpower! | 16:03 |
| JamieBennett | asac: in my case it was a mis-labelled (or rather not labelled) power lead running 12v so nothing for you to worry about | 16:04 |
| armin76 | asac: remove the sd :D | 16:04 |
| ogra | it wont power on without SD | 16:05 |
| JamieBennett | ogra: but it does light up for a second | 16:06 |
| armin76 | oh | 16:06 |
| JamieBennett | if you hold the power button | 16:06 |
| ogra | right, but if it doesnt do that anyway, the Sd shouldnt matter | 16:06 |
| JamieBennett | ogra: right | 16:06 |
| asac | sigh | 16:07 |
| asac | nothing | 16:07 |
| plars | ogra: we did have someone make a board produce "magic white smoke" though :) | 16:07 |
| ogra | plars, well, but he's known for his magic skills anyway :) | 16:07 |
| * ogra enables ext2 in uboot | 16:10 | |
| asac | JamieBennett: you have a bbg2? | 16:13 |
| asac | does that work with same power adapter? | 16:13 |
| JamieBennett | asac: I have a 2.0 and 2.5 | 16:13 |
| JamieBennett | 2.5 has same adapter | 16:14 |
| JamieBennett | 2.0 is 12v | 16:14 |
| asac | ah ok | 16:14 |
| asac | so i need to get the 12v from my other place | 16:14 |
| asac | beforei can continue on bbg2 | 16:14 |
| ogra | measure | 16:14 |
| ogra | pick a voltmeter and check if you have no voltage before playing with power adapters | 16:15 |
| ogra | the 2.5 should have a 5V adapter btw | 16:15 |
| ogra | not 12 | 16:16 |
| ogra | thats 2.0 | 16:16 |
| JamieBennett | ogra: yes as I pointed out above. 2.5 and 3.0 have 12v, 2.0 has 12v | 16:16 |
| JamieBennett | 5v that should of been | 16:16 |
| ogra | :) | 16:16 |
| ogra | i just wanted to prevent asac from plugging in 12V | 16:17 |
| JamieBennett | I'm in pain, took the kids in the snow for 30 mins sledging and now my backside hurts from a rather fast decent without the sledge :) | 16:17 |
| ogra | ouch | 16:17 |
| JamieBennett | ogra: yep, can't be too careful with them power adapters ;) | 16:18 |
| * ogra only leaves the house if absolutely necessary | 16:18 | |
| ogra | way to cold outside | 16:18 |
| asac | i definitly didnt replug any power adapter or so | 16:19 |
| asac | i have a warrenty thing for this board | 16:21 |
| asac | though i have no place of purchase | 16:22 |
| ogra | BBG U-Boot > ext2ls mmc 0:2 | 16:22 |
| ogra | <DIR> 1024 . | 16:22 |
| ogra | <DIR> 1024 .. | 16:22 |
| ogra | <DIR> 12288 lost+found | 16:22 |
| ogra | 64 uimage | 16:22 |
| asac | cool | 16:23 |
| ogra | BBG U-Boot > ext2load mmc 0:2 0x90008000 /uimage | 16:23 |
| ogra | Loading file "/uimage" from mmc device 0:2 (xxa2) | 16:23 |
| ogra | 64 bytes read | 16:23 |
| asac | but that doesnt matter for our problems ;) | 16:23 |
| asac | thats wrong | 16:23 |
| asac | 64 bytes read | 16:23 |
| ogra | no, the file is broken | 16:23 |
| asac | oh why it so small? | 16:23 |
| ogra | see the ls | 16:23 |
| asac | hehe | 16:23 |
| asac | yeah | 16:23 |
| ogra | well, has the same issues | 16:28 |
| crashfourit1 | hum... can any one here help me? getting a kernel panic when trying to start ubuntu arm in qemu. The error is "Attempted to kill init" | 16:30 |
| asac | fta: do you know where we can tweak the default profile for chromium? | 17:02 |
| asac | e.g. different homepage etc.? | 17:02 |
| asac | fta: seems todays chromium dailies failed | 17:16 |
| asac | probably needs some GL depends? | 17:17 |
| asac | fta: build-tree/src/third_party/gles_book_examples/ is in our orig too | 17:31 |
| asac | please strip that | 17:31 |
| asac | fta: http://pastebin.com/f5f971220 ... somehow the ForwardingHeaders matches are now working | 17:57 |
| fta | asac, i have a problem with the gl thing: for webgl, they have a patched glu because of http://crbug.com/16800 (nvidia has its own broken libgl), but for gpu (new), they want the system gl/glu headers | 17:57 |
| asac | the rest works well | 17:58 |
| asac | http://paste.ubuntu.com/353039/ | 17:58 |
| fta | so in the current state, i can't provide both gpu & webgl without breaking javascript (like the gmail timezone bug) | 17:59 |
| asac | ah ok. so thats not the reason for the build failure? | 17:59 |
| asac | why do we need both? | 17:59 |
| asac | what is webgl? | 17:59 |
| asac | oh thats chromium stuff | 18:00 |
| asac | how does that work for them then? | 18:00 |
| asac | seems we are not doing anything special ... e.g. use their webgl and system gl/glu headers for gpu | 18:00 |
| fta | the build failure could easily be solved with build-deps += mesa-common-dev libgl1-mesa-dev libglu1-mesa-dev but that means breaking js (http://crbug.com/16800) | 18:01 |
| asac | ok found the prob with the licensecheck i think | 18:02 |
| fta | webgl: http://arstechnica.com/open-source/news/2009/08/webgl-standard-to-bring-3d-web-without-browser-plugins.ars | 18:02 |
| fta | http://arstechnica.com/open-source/news/2009/12/webgl-draft-published-khronos-seeks-community-involvement.ars | 18:02 |
| asac | breaking js like their time thing? | 18:03 |
| asac | why does it work for them? | 18:04 |
| fta | because it only breaks if you're using the nvidia driver | 18:04 |
| fta | like i do | 18:04 |
| asac | ok. so they are happy with that? | 18:05 |
| fta | no | 18:05 |
| asac | otherwise i would suggest to file a bug and wait till they figure it out | 18:05 |
| asac | and for that time accept that nvidia is broken. feels like they will work on that with high prio | 18:05 |
| fta | they fixed it for webgl by patching glu to not load libGl.so.1 directly | 18:05 |
| fta | but it's back with the new gpu feature | 18:05 |
| asac | right | 18:05 |
| fta | so they will have to do something about gpu too | 18:06 |
| fta | i already reported that to the gpu guy | 18:06 |
| asac | right. thats why i think we should just do what they do and accept bugs they have for the time being | 18:06 |
| fta | (he's in california) | 18:06 |
| fta | the bot kicks off at 4am so i still still have time to discuss with upstream, maybe there's a better fix, if there's nothing, i'll add the build-deps | 18:11 |
| asac | yeah | 18:12 |
| asac | i would assume that if they build with both enabled they have the same time regression | 18:12 |
| asac | so we would just replicate their behaviour | 18:12 |
| fta | asac, http://groups.google.com/group/chromium-dev/browse_thread/thread/a7d337e88e63af6d# | 18:14 |
| armin76 | shenki: around? | 18:17 |
| armin76 | asac: did you try armv7=1? | 18:17 |
| asac | armin76: no, because we have no NEON in kernel and buld system doesnt allow to disable that | 18:19 |
| asac | is on my list to fix in build systme | 18:19 |
| armin76 | ah, right | 18:21 |
| armin76 | sorry i forgot *g* | 18:21 |
| === mcasadevall is now known as NCommander | ||
| === asac_ is now known as asac | ||
| === bjf-afk is now known as bjf | ||
| === cwillu_at_work is now known as IcantBelieveItsN | ||
| === IcantBelieveItsN is now known as cwillu_at_work | ||
| plars | asac: the firefox in that ppa seems to work for me on babbage | 21:46 |
| asac | plars: cool thanks. alrady set it to DONE :) | 21:46 |
| asac | (the item) | 21:46 |
| cwillu_at_work | lool, that was you I was talking to about pixman et al, right? | 22:06 |
| armin76 | cwillu_at_work: from ubuntu yes, the other guy was ssvb | 22:15 |
| lool | cwillu_at_work: Yes | 22:19 |
| lool | As armin76 said | 22:19 |
| cwillu_at_work | was just re-reading http://lists.cairographics.org/archives/cairo/2009-October/018421.html, looking for confirmation that an neon'ified pixman does what I think it does; I now think I misread it when I poked you just now :p | 22:25 |
| * cwillu_at_work raids cgit.freedesktop.org for unreleased neon pixman patches | 23:21 | |
| === bjf is now known as bjf-afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!