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