**** BEGIN LOGGING AT Wed Jan 06 02:59:57 2010 Jan 06 09:51:02 Anyone around to take a look at a boot chart output from the ARM live-cd? Casper is the obvious cause of major slowness and I've documented it at https://wiki.ubuntu.com/ARM/LiveCDSpeedup#Casper, after Casper I can't see many worth-while wins though. Link - https://wiki.ubuntu.com/ARM/LiveCDSpeedup#BootChart Jan 06 09:53:40 looks like adduser and the keyboard stuff are the worst Jan 06 09:54:28 ogra: yeah, all due to debconf-communicate Jan 06 09:54:35 adduser is taking 10sec ! Jan 06 09:54:47 err Jan 06 09:54:54 30, sorry Jan 06 09:55:27 JamieBennett: Did you ever track down precisely why debconf-communicate is acting so slow? Jan 06 09:55:31 JamieBennett, try adding a sscript that calls debconf-coomunicate Jan 06 09:55:52 ogra, persia: done and the findings are on the wiki page I liked to. Jan 06 09:55:53 something that sets only one value and see if that also uses 30sec Jan 06 09:56:12 i suspect thats a fixed value we see there Jan 06 09:56:29 JamieBennett: Hrm? In the "Conclusion" section, or somewhere else? Jan 06 09:56:33 i.e. each call to debconf adds 30sec Jan 06 09:56:57 I'm seeing clear indication that it *is* debconf-communicate, but I still don't understand why there is a performance skew when compared to other architectures. Jan 06 09:57:02 ogra: each call to debconf-communicate takes 4 seconds due to loading templates.dat via perl code Jan 06 09:57:23 what about the other 26 ? Jan 06 09:57:40 ogra: where are you getting 30 secs from? Jan 06 09:58:20 oh, i only looked at the kbd stuff, adduser simply calls it multiple times Jan 06 09:58:26 Yes - https://wiki.ubuntu.com/ARM/LiveCDSpeedup#19keyboard Jan 06 09:58:44 well, twice actually Jan 06 09:59:12 ogra - 5 times - casper-preseed calls debconf-communicate Jan 06 09:59:38 i only see it twice in adduser Jan 06 09:59:45 at least in the chart Jan 06 10:00:00 ogra: The detailed breakdown of the adduser case is above. Jan 06 10:00:19 above what ? Jan 06 10:00:36 a 7-sec call to debconf-communicate, wondering about in user-setup-apply (which talks to debconf a lot), and then a final 4 seconds in another debconf-communicate. Jan 06 10:00:41 Above the chart on the wiki page. Jan 06 10:01:15 ogra: are you talking adduser or keyboard? Jan 06 10:01:23 adduser Jan 06 10:01:30 only looking at the bootchart Jan 06 10:01:37 ah, yes thats two calls Jan 06 10:01:40 keyboard is 5 Jan 06 10:01:58 the chart shows only one very long one Jan 06 10:02:00 JamieBennett: Are you *sure* there's no debconf-communicate in user-setup-apply? I thought I remembered a fair bit. Jan 06 10:02:01 for kbd Jan 06 10:02:13 persia: maybe, I can investigate. Jan 06 10:02:32 ogra: persia: so continuing discussion on the our ACTION to document what needs to be backported from .32 Jan 06 10:02:42 right Jan 06 10:02:43 to .31 kernel Jan 06 10:02:53 i see aufs and apparmor as critical Jan 06 10:02:54 JamieBennett: What I'm most curious about is *why* perl is so slow at reading that cache on armel. I suspect there's a deeper bug that would be nice to address with lots of improvements all over. Jan 06 10:02:59 how should we do this Jan 06 10:02:59 ? Jan 06 10:03:08 do we already know the areas where we need backports? Jan 06 10:03:11 make a list of kernel features we knoe Jan 06 10:03:17 *know Jan 06 10:03:19 akk? Jan 06 10:03:22 all? Jan 06 10:03:25 that feels bad ;) Jan 06 10:03:26 no Jan 06 10:03:32 persia: lool had some thoughts about perl slowness, I'll talk to him to see if he has investigated it at all Jan 06 10:03:33 all that are developed inhouse Jan 06 10:03:35 ok brainstroming :) Jan 06 10:03:42 you say aufs and apparmor ... Jan 06 10:03:44 Could we simply compare the kernel-generated header files for .31 and .32, and backport stuff where the API has changed? Jan 06 10:03:54 i remember persia mentioned ureadahead or something Jan 06 10:04:07 ogra@osiris:~/Desktop/uboot/package/uboot-imx-2009.08$ ls /lib/modules/2.6.31-14-generic-pae/kernel/ubuntu/ Jan 06 10:04:08 aufs compcache dm-raid4-5 drbd iscsitarget lenovo-sl-laptop lirc misc ndiswrapper rfkill Jan 06 10:04:25 Mine were more userspacey, like ALSA and bluetooth. Jan 06 10:04:30 i guess we can ignore the lenovo stuff :) Jan 06 10:04:48 and ndiswrapper Jan 06 10:04:57 so why are we looking at kernel/ubuntu only? Jan 06 10:05:10 we dont Jan 06 10:05:12 asac: How do you mean? Jan 06 10:05:19 but thats the easy and obvious part Jan 06 10:05:23 yeah Jan 06 10:05:25 ok Jan 06 10:05:52 we surely need to add stuff that happens inline in the kernel, plus what persia said Jan 06 10:06:12 though i think the alsa HW specific stuff isnt that intresting Jan 06 10:06:25 we dont need intel fixes on arm :) Jan 06 10:06:38 What is interesting is keeping sync between userspace and kernelspace interfaces. Jan 06 10:06:42 persia: we could check the header approach, and see if we get useful results. Jan 06 10:06:46 right Jan 06 10:06:56 I don't care about the individual bits of hardware, but I do care if something moved in ALSA, and sound doesn't work. Jan 06 10:07:04 Most ARM hardware should be using ASoC anyway. Jan 06 10:08:02 asac: To do that, should we generate linux-headers-2.6.31-foo out of the ARM kernel sources, or do you think there are other sources of API changes? Jan 06 10:08:58 hmm. are linux-headers really the headers exported to userspace? Jan 06 10:09:18 not linux-libc-dev ? Jan 06 10:09:41 Well, both are exposed, actually. Jan 06 10:09:48 really? Jan 06 10:09:54 * persia goes to read up on stuff Jan 06 10:09:57 i thought linux-headers was just for kernel modules Jan 06 10:10:23 apt-cache show linux-libc-dev Jan 06 10:10:25 stop ... Jan 06 10:10:28 Right. Sorry. I was confused by "linux-kernel-headers" which was an old name for linux-libc-dev Jan 06 10:10:34 This package provides headers from the Linux kernel. These headers Jan 06 10:10:34 are used by the installed headers for GNU glibc and other system Jan 06 10:10:34 libraries. They are NOT meant to be used to build third-party modules for Jan 06 10:10:34 your kernel. Use linux-headers-* packages for that. Jan 06 10:10:34 we had that discussion multiple times Jan 06 10:10:48 thats a kernel team job Jan 06 10:11:08 ogra: what do you mean? Jan 06 10:11:47 * ogra tries to find the mail with the discussion about linux-headers vs libc-dev Jan 06 10:12:02 asac, armel is a special case Jan 06 10:12:21 and it took us weeks to agree on a specific setup everybody was happy with Jan 06 10:13:11 * persia isn't entirely convinced it's safe to special-case headers against which userspace is built. Jan 06 10:13:21 i know apw summarized it, i cant find it atm Jan 06 10:14:45 persia, i think we need to use linux-kernel-headers-*SoC* for our stuff iirc Jan 06 10:15:08 but i need the notes Jan 06 10:15:16 the email was titled Jan 06 10:15:19 Subject: arm headers issue Jan 06 10:15:36 apw: To which list was it sent, and about when? Jan 06 10:15:59 Anyway, I thought linux-libc-dev *replaced* linux-kernel-headers some time back. Jan 06 10:16:05 it was sent to a few people direct Jan 06 10:16:11 Ah, tricky those. Jan 06 10:16:32 apw, gracias, got it Jan 06 10:16:38 asac, forwarding to you Jan 06 10:16:55 i don't recall it being contentious, just not interesting to the general reader in the raw form it was Jan 06 10:17:07 yeah Jan 06 10:17:18 but important knowledge if you work on armel Jan 06 10:17:41 and surely important to know for asac who became our fearless tech lead now ;) Jan 06 10:17:42 But the summary was that there are linux-kernel-headers-${SoC} packages being built that are just like linux-libc-dev except for the different ARM kernels? Jan 06 10:18:13 persia, forwarded to you too Jan 06 10:18:33 * persia likes smart search tools that automatically update Jan 06 10:20:03 * persia is still confused Jan 06 10:20:12 Is this just about arm-specific headers, or *all* headers? Jan 06 10:21:30 arm Jan 06 10:21:51 its presumably about apps needing vile arm specific driver headers Jan 06 10:21:55 That's completely different from what I'm looking for. Let's call that solved for now (for all that I think it's a bit of a mess) Jan 06 10:21:57 right Jan 06 10:22:25 I was looking to compare linux-libc-dev from the SoC kernels to linux-libc-dev in the master kernel. Jan 06 10:22:34 Where those differ, we have a candidate problem. Jan 06 10:22:34 persia, that counts in SoC specific userspace API libs Jan 06 10:22:43 Right, I don't care about backporting any of that stuff. Jan 06 10:22:47 right, you cant Jan 06 10:22:59 right :) Jan 06 10:23:00 since linux-libc-dev on armel comes from the main source Jan 06 10:23:10 linux-libc-dev for armel ... what he said Jan 06 10:23:30 Right, so like I said, shall we have the SoC kernel sources provide linux-libc-dev-${SoC} for comparison purposes? Jan 06 10:23:38 apw, hmm, how do you handle that with the .32 vs .31 issue btw ? Jan 06 10:23:45 And then if we find discrepancies, backport what we need. Jan 06 10:23:47 persia, no Jan 06 10:23:51 Why not? Jan 06 10:23:58 read the mail :) Jan 06 10:24:04 colin will slay you Jan 06 10:24:06 ogra, we don't Jan 06 10:24:07 This is *completely* unrelated to the mail. Jan 06 10:24:18 The mail is about SoC-specific headers. I'm talking about general headers. Jan 06 10:24:35 I don't expect them to be used by anything: I just want them for reference. Jan 06 10:24:41 If anything builds against them, we failed. Jan 06 10:24:41 apw, evil ... what if vendors build stuff based on linux-libc-dev ? it will likely be boroken Jan 06 10:25:06 We can put ***DON'T USE THIS*** **YOUR APPLICATION WILL FAIL*** in the description. Jan 06 10:25:16 arm is in a world of pain by refusing to be at the same version as the rest of the system Jan 06 10:25:50 we are assuming some level of compatibility between releases and literally crossing everything Jan 06 10:25:55 apw: Well, we're hoping to avoid some of that with backporting. For instance, backporting ALSA should be relatively painless. Jan 06 10:26:23 its already backported for non-arm so i assume so Jan 06 10:26:32 Right :) Jan 06 10:26:45 apw, well, i'm more concerned about things like aufs Jan 06 10:26:54 The trick is to determine what needs to be backported to avoid pain. Jan 06 10:26:58 we need it for image builds Jan 06 10:27:05 i don't think there is any headers for aufs Jan 06 10:27:17 how about apparmor Jan 06 10:27:19 ogra: So, what objection do you have to comparing the generated linux-libc-dev for each kernel type? Jan 06 10:27:21 included in the linux-libc-dev package Jan 06 10:27:35 persia, there is no linux-libc-dev for each kernel type Jan 06 10:27:42 But there could be :) Jan 06 10:27:45 not sure we include those either Jan 06 10:27:49 ther is only one and that comes from the upstream source Jan 06 10:28:09 and the archive admin team is strictly against having more than one Jan 06 10:28:21 Fine. Jan 06 10:28:23 read the IRC discussion in the mail Jan 06 10:28:31 we can't have more than one, as the archive can only be built for one armel form Jan 06 10:28:40 I did. You aren't understanding what I'm saying. I'm not talking about the same thing from the mail. Jan 06 10:28:42 and its that process that consumes the package Jan 06 10:28:53 But I don't care to argue that: I'll find a workaround. Jan 06 10:29:16 have we hit an issue with our assumptions here, or are we worryng about the future Jan 06 10:29:31 apw: We've lost track of the discussion. Jan 06 10:29:52 The agenda item was to try to identify what shoud be backported into .31 kernels to make sure lucid works with them. Jan 06 10:30:31 Our inital guess was aufs compcache dm-raid4-5 drbd iscsitarget lirc misc rfkill + alsa + bluetooth Jan 06 10:30:45 whateve misc is Jan 06 10:30:51 * ogra takes a look in the dir Jan 06 10:31:20 /lib/modules/2.6.31-14-generic-pae/kernel/ubuntu/misc/fsam7400.ko Jan 06 10:31:28 description: SW RF kill switch for Fujitsu Siemens Amilo M 7400 Jan 06 10:31:30 my understanding is that aufs is 'compatible' between the two semantically Jan 06 10:31:31 not for us Jan 06 10:31:58 apparmor userspace i believe is aware it may be using two differenet kernels Jan 06 10:32:05 apw: We've had a lot of issues with aufs version skew in the past, and have little trust. Jan 06 10:32:10 apw, right, but we need to make sure that all the inhouse developed features the kernel team develops work Jan 06 10:32:37 thats why my main issues are aufs and apparmor ... but you answered for both, so i personally am happy Jan 06 10:32:59 compcache and dmraid are surely also important to have working Jan 06 10:33:23 not sure about lirc rfkill or iscsitarget Jan 06 10:33:40 rfkill is likely useful, as lots of devices have wireless. Jan 06 10:34:04 but do they have the HW that supports rfkill ? Jan 06 10:34:10 lirc falls into the alsa/bluetooth category for me: if we don't do it, classes of devices won't work. Jan 06 10:34:22 the babbage doesnt have wireless per se Jan 06 10:34:33 and we actually only talk about babbage here Jan 06 10:34:38 dove is on .32 Jan 06 10:35:34 did we lose asac ? Jan 06 10:36:06 * persia installs wireless-tools to see if rfkill works on at least one i.MX51-based device Jan 06 10:37:36 no Jan 06 10:37:40 reading thta long mail atm ;) Jan 06 10:37:55 so from what i understand comparing headers doesnt make sense Jan 06 10:38:05 its supposed to be not broken in that way Jan 06 10:38:14 so lets focus on the core ideas we had: Jan 06 10:38:34 a) figure out which "ubuntu" features were added in .32/lucid Jan 06 10:38:59 -> review and make a list of what parts we want from those Jan 06 10:39:03 Erm, what? Jan 06 10:39:06 right Jan 06 10:40:00 b) try to find some good targets to look closer: Jan 06 10:40:20 e.g. what kernel improvements were done for boot perf. Jan 06 10:40:39 which of them didnt go upstream Jan 06 10:40:41 -> and check if we need those -> Jan 06 10:40:55 we surely do Jan 06 10:41:11 unless we stop caring about bootspeed suddenly Jan 06 10:41:13 ogra: didnt go upstream in .31 ... given that we had .31 in karmic, nothing went upstream for us (fsl) Jan 06 10:41:20 that was done in lucid Jan 06 10:41:21 right Jan 06 10:42:08 i double checked with dtchen back at UDS ... he said, that sound wont be a problem in that we will see regressions over karmic experience Jan 06 10:42:16 ...however, we might not see improvements obviously ... Jan 06 10:42:21 but i think we can live with that Jan 06 10:42:33 yeah Jan 06 10:42:49 as long as noise still comes out of the speakers :) Jan 06 10:42:50 so lets scratch sound from the backporrting candidates unless we find real bugs Jan 06 10:42:55 right Jan 06 10:43:01 QA would hopefully catch that Jan 06 10:43:06 Note that he has already backported the latest ALSA stuff to .31 in a PPA, so it should be fairly painless to integrate. Jan 06 10:43:25 if fixes are available we are probably happy to pull them in Jan 06 10:43:32 -> lets note that as an option/action Jan 06 10:44:09 do we know anything besides boot performance kernel changes and sound? Jan 06 10:44:10 apw, what looks important to me wrt bootspeed are the patches from csurbhi Jan 06 10:44:51 apw, do you see any issues with these to go into a .31 tree ? Jan 06 10:45:07 cooloney: there? Jan 06 10:45:58 cooloney: what ubuntu specific kernel stuff that is in .32 wont be in our .31 kernel? Jan 06 10:46:04 maybe we automatically get everything? Jan 06 10:46:45 ogra, those were pretty simple patches, but do we have a bootspeed issue on arm? Jan 06 10:47:00 apw, bootspeed is always an issue, yes Jan 06 10:47:15 Well, looking at the bootchart we were discussing earlier, we're running at somewhere under 195 seconds right now. Jan 06 10:47:19 apw, if we have any improvement in the main distro they should definately go into arm Jan 06 10:47:28 persia, thats livefs :) Jan 06 10:47:37 ogra: So? :) Jan 06 10:47:42 my babbage boots lucid in about 50sec Jan 06 10:47:48 Still, a fairly long time. Jan 06 10:47:49 or 45 Jan 06 10:47:56 yes, but not 195 :) Jan 06 10:48:07 lets stay with apples vs apples Jan 06 10:48:41 But yeah, we'd like that faster. Jan 06 10:48:46 i agree that the kernel tweakage currently done for i386 is not really our major concenr Jan 06 10:49:04 but i hope we get the big time consumers removed and then it might be more important Jan 06 10:49:06 asac, even if it gains us several seconds in bootspeed ? Jan 06 10:49:09 so being prepared is good Jan 06 10:49:34 My concern is things not working because of kernel/userspace interface changes, more than small improvements. Jan 06 10:49:43 bootspeed is definately a vendor concern we har all the time Jan 06 10:49:52 Small improvements are nice, but the kernel is outdated, and deserves to suffer a bit. Jan 06 10:49:53 *hear Jan 06 10:50:15 persia: i dont think we can understand that up-front fully. Jan 06 10:50:24 we can only figure that out through bugs later on Jan 06 10:50:56 ogra: yes. but we have 195 secdons. most of that is probably not related to anything done in the .32 kernel Jan 06 10:51:07 which is tuning it to get the last few seconds removed from i386 Jan 06 10:51:12 asac, yes, but the 195sec are live images Jan 06 10:51:21 asac, has nothing to do with this discussion Jan 06 10:51:23 asac: Well, hrm. I have suspicions about stuff like bt, alsa, lirc, ieee1394, etc. We had lots of issues with intrepid when the version skewed unexpectedly. Jan 06 10:51:41 But I'm not sure our test coverage is broad enough to catch all that (because it wasn't for i386 for intrepid) Jan 06 10:51:41 persia: dtchen said alsa isnt a problem for older kernels Jan 06 10:51:43 asac, the 45-50 sec for instealled systems *are* an issue for this discussion though Jan 06 10:52:04 ogra: yes. but live image is similarly important. thats the first impression users get Jan 06 10:52:22 asac: Does that presume a separate alsa-modules package? Jan 06 10:52:36 ogra: not really sure where the problem is. i am all for looking at what was done and what can be pulled into .31 for bootspeed Jan 06 10:52:38 asac, but they are no kernel related issues Jan 06 10:53:11 asac, right ... i'm only talking about the installed system here ... the live issues are all casper related Jan 06 10:53:13 ogra: right. but did we analyze our 45 seconds on installed images yet? Jan 06 10:53:19 nope Jan 06 10:53:21 maybe its half of the time in something similar Jan 06 10:53:26 nope Jan 06 10:53:52 Um, those two "nope"s are mutually exclusive: without analysis there's not enough information for the second answer. Jan 06 10:53:56 you say that userspace is well tuned? Jan 06 10:53:57 we dont call things like debconf-communicate anywhere in installed systems Jan 06 10:54:18 ogra: still. for me its currently a blackbox Jan 06 10:54:34 also on liveimages only 50 seconds or so are deconf-communicate Jan 06 10:54:47 http://people.canonical.com/~ogra/babbage2-karmic-20090916-3.png Jan 06 10:54:55 there is a karmic bootchart Jan 06 10:55:02 Well, more than that. there's about 35 seconds in just 10adduser and 19keyboard Jan 06 10:55:09 speed issues there are totally unrelated to the speed issues on the live boot Jan 06 10:55:19 anyway. thats not the point Jan 06 10:55:23 No. Jan 06 10:55:26 right Jan 06 10:55:45 but what i say is that we want kernel improvements backported if they can gain us a few secs Jan 06 10:55:56 ogra: how can you say that its unrelated without having analysed it Jan 06 10:56:11 anyway, as you might know JamieBennett is our boot speed master this cycle ;) Jan 06 10:56:18 I think we should be focusing on SoC-specific performance enhancements with SoC-specific kernels, rather than worrying about backporting. Jan 06 10:56:22 i.e. if we can get from 41 to 31 secs through them ... plus gain another 5 secs through ureadahead that is definately something we want Jan 06 10:56:29 :) Jan 06 10:56:31 so maybe he should take the action to work on it ... including figuring what kernel parts would be beneficial Jan 06 10:56:41 asac, ++ Jan 06 10:56:52 ok. lets do that then. doesnt make sense to speculate Jan 06 10:56:57 Indeed. Jan 06 10:56:59 asac, i have analyzed it in so far that i took bootcharts every release Jan 06 10:57:19 but didnt have any time to look for possible improvements or to dig deeper Jan 06 10:57:28 Do we run any perl during boot? Jan 06 10:57:29 so bootspeed is covered ;) ... JamieBennett will work with whoever want to peer on that on a) identifying kernel patches to backport, b) identifying userspace bottlenecks in both: install and live image Jan 06 10:58:09 OK Jan 06 10:58:10 /me scrambles to read backchat to see what I have volunteered to do Jan 06 10:58:20 JamieBennett, so please talk to csurbhi, if it makes sense to backport their patches to us Jan 06 10:58:27 JamieBennett: basically the last line i said ;) Jan 06 10:58:28 s/their/her/ Jan 06 10:58:31 ogra: OK Jan 06 10:58:31 11:57 < asac> so bootspeed is covered ;) ... JamieBennett will work with whoever want to peer on that on a) identifying kernel patches to backport, b) identifying userspace bottlenecks in both: install and live image Jan 06 10:58:35 JamieBennett: IN summary: analyse bootspeed of installed armel systems, compare against other architectures, and optimise. Jan 06 10:58:47 yep Jan 06 10:58:52 thats a tough comparison :) Jan 06 10:58:58 Yep :) Jan 06 10:59:01 given your HW is likely slowing it down Jan 06 10:59:11 like disk etc Jan 06 10:59:15 but well Jan 06 10:59:27 Well, but simple HW issues scale, but if most stuff is 2x and one thing is 10x, that thing needs attention. Jan 06 10:59:27 lets go back to the actual discussion Jan 06 10:59:28 i dont think we can really compare it Jan 06 10:59:41 maybe to identify stuff that takes relatively long Jan 06 10:59:51 ok ... so lets move on ... bootspeed is covered ;) Jan 06 10:59:56 Right. That's the extent of the potential for comparison. Jan 06 11:00:03 now ... areas of potential userspace breakage: Jan 06 11:00:18 mentioned were: Jan 06 11:00:20 For *-modules, we just have to make sure that it can be built properly. Jan 06 11:00:28 as apw said, aufs and apparmor should just work Jan 06 11:00:32 alsa, bt, lirc, ieee1394 Jan 06 11:00:55 dmraid Jan 06 11:01:08 i can take the action to sync with jdstrand on what innovation we might want for apparmor Jan 06 11:01:27 (and whoever does that on kernel side ) Jan 06 11:01:28 compcache (very important) Jan 06 11:01:36 whats your concerna bout compcache? Jan 06 11:01:44 rfkill drdb ? Jan 06 11:01:44 general breakage i presume? Jan 06 11:01:48 yes Jan 06 11:01:59 we are currently at "user space brekage";) Jan 06 11:02:09 we should have the same upstream version in .31 lucid as in .32 lucid x86 Jan 06 11:02:19 isnt compcache covered by kernel/ubuntu investigation? Jan 06 11:02:23 since the live images 100% rely on it working Jan 06 11:02:44 yes, its in kernel/ubuntu Jan 06 11:02:45 which i had hpoed we could put on cooloney's plate ... mission: get as many goodies for ubuntu specific stuff from .32 to .31 as possibe Jan 06 11:02:54 right Jan 06 11:03:38 ok .... so lets assign this action to him. Jan 06 11:04:04 a) make a list of stuff that changed for kernel/ubuntu in .32 Jan 06 11:04:05 ok, that only leaves sound and apparmor Jan 06 11:04:26 apparmor i took the action to check what innovation we might want Jan 06 11:04:32 right Jan 06 11:04:38 sound is likely mostly safe to leave alone. People who *really* care can get modules separately. Jan 06 11:04:40 sound was already covered imo, but i can also check with dtchen directly what he thinks should be done Jan 06 11:05:17 if he has patches ready for consumption that are safe, i dont see why we should not pick them Jan 06 11:05:28 Heh. 590 headers files differ between linux and linux-fsl-imx51 Jan 06 11:05:32 ;) Jan 06 11:06:02 right, so: bootspeed->Jamie, kernel/ubuntu -> cooloney, sound-> dtchen, apparmor -> asac ... Jan 06 11:06:13 anything we forgot ? Jan 06 11:06:17 Lots of drm changes: we don't care about any of that, right? Jan 06 11:06:27 unlikely Jan 06 11:06:28 bt, lirc Jan 06 11:06:40 lirc is in kernel/ubuntu Jan 06 11:06:43 ogra: sound -> asac (with dtchen) Jan 06 11:06:48 right Jan 06 11:06:55 persia, so do yu take bt ? Jan 06 11:07:25 Sure, although I'm going to be limited to source-inspection. I may have to lean on others to help with any testing. Jan 06 11:07:45 well, grab a kernel guy for help :) Jan 06 11:07:47 for now we want to investigate Jan 06 11:07:58 and then we meet after alpha-2 to discuss the final actions i guess Jan 06 11:08:03 and present results Jan 06 11:08:04 yep Jan 06 11:08:14 well, some bits need to happen pre A2 Jan 06 11:08:20 is there any area that we know is currently breaking us? Jan 06 11:08:21 at least aufs needs to work Jan 06 11:08:29 no, we dont Jan 06 11:08:30 e.g. is anthing of the above urgent for a2 Jan 06 11:08:37 since we havent seen te3h .31 kernel yet Jan 06 11:08:55 ok... aufs is kernel/ubuntu Jan 06 11:08:56 anything else? Jan 06 11:09:01 we can do definitive stuff only if we actually have the new kernel Jan 06 11:09:16 ogra: why arent we seeing issues with aufs now if its needed for a2? Jan 06 11:09:39 well, as apw said, it shouldnt have issues Jan 06 11:09:43 for now, lets hope that stuff that works atm, will work with the new kernel Jan 06 11:09:48 right Jan 06 11:10:06 but you cant say until you see the real thing :) Jan 06 11:10:06 we are talking about actions and urgencies, so fixing aufs is not urgent until we know its broken :) Jan 06 11:10:13 sure Jan 06 11:10:31 we are talking about hypothetical stuff atm Jan 06 11:10:34 Seems that linux-fsl-imx51 headers are rather different for bluetooth :( Jan 06 11:10:36 but i would hope that all stuff urgent enough for a2 target would be breakage of images Jan 06 11:10:44 and would be covered by all other mechanims Jan 06 11:11:02 ogra: yes. thats why i dont think that anything of the stuff we talked about has to happen for a2 atm Jan 06 11:11:09 I'd agree that urgent stuff would be covered in other ways. Jan 06 11:11:12 until we get to know of breakage ;) Jan 06 11:11:20 right Jan 06 11:11:25 This is more that we need to be solid pre-beta, and need a head start. Jan 06 11:11:37 what we are doing here is an proactive effort to improve the overall quality of our final release Jan 06 11:11:47 yep Jan 06 11:12:52 persia: want to send out actions we deferred from this with me/ogra/jamie CCed? Jan 06 11:12:58 and colooney Jan 06 11:13:06 Why CC, rather than addressee? Jan 06 11:13:14 hehe Jan 06 11:13:18 yes. TOed Jan 06 11:13:41 Sure, although I want to dig out of my current stack of stuff first. Jan 06 11:14:10 * asac wonders what that is ;) Jan 06 11:14:34 * ogra hands persia a ladder Jan 06 11:14:39 my current stack of stuff == all the clothes that wait for a laundry here ;) Jan 06 11:15:13 or rather: my board buried under heaps of dirty socks ;) Jan 06 11:15:29 * persia has ~20 windows opened during this discussion that need to be closed after extracting the key bits while knowledge is fresh: actions are logged in lots of places to grab in some minutes. Jan 06 11:15:39 * ogra fights with uboot Jan 06 11:15:50 most likely those 20 windows opened on the sharp thing ;) Jan 06 11:15:58 lol Jan 06 11:16:10 No, only 4 windows on the Netwalker during the past hour discussion :p Jan 06 11:16:16 (mostly terminals to check stuff) Jan 06 11:19:21 anyone running lucid already? Jan 06 11:19:26 on main desktop? Jan 06 11:19:29 is sound working? Jan 06 11:19:46 * asac scared that voip/softphone will be completely brokenish when i upgrade now ;) Jan 06 11:19:51 Should be: lots of people report that it is. Jan 06 11:20:02 Try a liveCD first :) Jan 06 11:20:44 asac, cjwatson upgraded on monday i think Jan 06 11:21:04 no idea if he uses any VoIP though Jan 06 11:25:13 most likely not. i have the feeling i am the only one, given how broken all softphones are ;) Jan 06 11:25:23 at least for real callout voip Jan 06 11:25:59 most apps seems to close the sound stream and open quickly when the call gets dispatched ... this yields random on/off for output/input for the final connection Jan 06 11:26:03 if you use pulse Jan 06 11:26:09 ogra: Am I reading backscroll correctly that you're not researching anything? Jan 06 11:26:32 ogra will be peer for boot performance and the kernel/ubuntu stuff Jan 06 11:26:34 i said i didnt Jan 06 11:26:48 asac: pulse and ekiga always work nicely together for me. Dunno which softphone you use. Jan 06 11:26:52 simply because it was to late in the former releases to do anything about it anyway Jan 06 11:26:56 asac: lucid killed my laptop yesterday Jan 06 11:26:59 persia: ekiga is really really busted ;) Jan 06 11:27:00 won't boot now Jan 06 11:27:03 we had no kernels until mid release Jan 06 11:27:03 persia: are you doing callout? Jan 06 11:27:26 asac: Define "callout". Jan 06 11:27:31 persia, i'm happy to help researching this round Jan 06 11:27:39 odd. then its probably sound chip related Jan 06 11:27:44 ekiga also crashes regularly Jan 06 11:27:52 also i cannot tell ekiga to use a stun server Jan 06 11:27:59 just doesnt have that config field Jan 06 11:28:05 Odd. It worked for me last I tried it, which was a bit ago. Jan 06 11:28:17 You can get to that through the config wizard. Jan 06 11:28:31 stun? Jan 06 11:28:34 thats not there Jan 06 11:28:35 for sure Jan 06 11:28:44 * ogra considers breakfast a good thing and tries to find some food Jan 06 11:28:44 But each and every sound chip (and subcomponent of sound chips) acts differently weirdly, so yes, likely :) Jan 06 11:28:58 i wasted so much time in ekiga/linphone/twinkle that i am quite sure you cannot confiugre a stun server in ekiga Jan 06 11:30:02 http://wiki.ekiga.org/index.php/Ekiga_behind_a_NAT_router Jan 06 11:30:47 gconftool-2 -s /apps/ekiga/general/nat/stun_server stun.ekiga.net --type=string Jan 06 11:31:00 (replace with your faviorite stun server :) ) Jan 06 11:31:11 hmm. so they have the stun server hard coded Jan 06 11:31:11 ok Jan 06 11:31:20 Not hard coded, just not exposed in the UI. Jan 06 11:31:29 thats hard coded in my book ;) Jan 06 11:31:34 gconf default without UI Jan 06 11:31:45 similar to using hexedit to edit the binary ;) Jan 06 11:31:57 Well, it's *lots* easier to change than when something is behind an #ifdef :) Jan 06 11:32:17 * persia has played with far too many foo-default-settings packages to completely agree with that. Jan 06 11:32:54 at least gconf doesnt forget your changes on upgrades ;) ... which hexedit often fails to do Jan 06 11:35:55 asac: See, you're supposed to hexedit the .deb, and remember to set epoch 47 :p Jan 06 11:38:52 ogra: what wifi does the babbage has? Jan 06 11:41:18 asac: ^ Jan 06 11:45:26 armin76: baa Jan 06 11:45:31 armin76: ogra said before " the babbage doesnt have wireless per se", so I presume nothing by default (but add what you like via USB) Jan 06 11:45:43 board-as-antenna ;) Jan 06 11:45:56 asac: Do we have a driver for that? Jan 06 11:46:06 oh Jan 06 11:46:07 thats hardware hacking ;) Jan 06 11:46:11 no driver needed Jan 06 11:46:27 just jump on a usb wifi dongle and try to wire the antenna up with the board for best results ;) Jan 06 11:46:37 Ah, so you modulate the local EM potentials to inject data streams directly? Jan 06 11:47:05 yes, in practice results are much better than the old way of having two antennas in the chassis ;) Jan 06 11:47:21 its not injecting data streams directly Jan 06 11:47:26 * persia goes back to kernel archeology Jan 06 11:47:36 just physical vibration that helps deal with interference ;) Jan 06 11:48:13 only works if you put the board on your external usb drive ;) Jan 06 11:48:24 which will soon be the standard Jan 06 11:49:43 ojn: did your board got wifi? Jan 06 11:49:52 lool: and the lange has wifi? Jan 06 11:50:19 armin76: What's wrong with USB WiFi off-board, as opposed to on-board? Jan 06 11:50:45 * persia suspects any consumer device with a battery will likely also have WiFi Jan 06 11:51:04 Probably USB WiFi, but on-board :) Jan 06 11:51:17 (given previous reports of USB SATA, onboard, etc.) Jan 06 11:51:22 persia: nothing, i'm just asking Jan 06 11:51:46 the efika mx has wifi...i'm not sure if it was usb or not...let's see... Jan 06 11:52:01 it doesn't work though(thats why i'm asking) Jan 06 11:52:08 Those are temping little boxes. Jan 06 11:52:47 armin76: Which device is it? Jan 06 11:52:52 what else would it be if not usb? Jan 06 11:53:02 asac: GPIO? Jan 06 11:53:39 Or even native (although I'd prefer a subprocessor for that sort of thing) Jan 06 11:53:43 SDIO Jan 06 11:54:00 persia: wifi device you mean? Jan 06 11:54:07 armin76: Yeah. Jan 06 11:54:12 oh, i'm stupid Jan 06 11:54:18 well, i just woke up, its expected :P Jan 06 11:54:18 that's the direction olpc has taken with the 1.5, the first revision used USB but USB takes too long to come out of suspend Jan 06 11:54:26 its a ralink 3070usb Jan 06 11:54:30 so yes, its usb :P Jan 06 11:54:51 persia: thanks for asking *g* Jan 06 11:55:46 armin76: Not the one I have a driver for then. Sorry. I have ks79xx_sdio Jan 06 11:55:55 Which reminds me, SDIO is *much* more likely than GPIO. Jan 06 11:57:25 armin76: http://wiki.debian.org/rt2870sta claims to support 148F:3070, so there might be something extractable. Jan 06 11:57:36 Dunno if it works properly on armel :) Jan 06 11:58:12 persia: the kernel is 2.6.31, and has support for the 2870, and thats what i built Jan 06 11:58:19 it detects it and stuff, but doesn't find any ap Jan 06 12:01:39 That's extra annoying. Jan 06 12:02:32 well, i consider more annoying that if you do a reboot, it halts, and if you do a halt, it reboots :P Jan 06 12:04:02 armin76: running ubuntu? Jan 06 12:04:03 ;) Jan 06 12:04:23 it came with ubuntu yes, but mkfs.ext3 is my friend :P Jan 06 12:04:34 the wifi worked in ubuntu? Jan 06 12:04:42 didn't try Jan 06 12:04:43 debian is known to not care much about wifi ;) Jan 06 12:04:51 * asac *cough* Jan 06 12:05:08 Hostname: efikamx - OS: Linux 2.6.31-ER1/armv7l - Distro: Gentoo 1.12.13 - CPU: ARMv7 rev 1 (v7l) - Processes: 78 - Uptime: 12d 15h 45m - Users: 3 - Load Average: 2.46 - Memory Usage: 109.81MB/470.49MB (23.34%) - Disk Usage: 22.61GB/461.20GB (4.90%) Jan 06 12:05:20 try our kernel Jan 06 12:05:24 oh wait ;) Jan 06 12:05:25 hehe Jan 06 12:05:55 armin76: are you using NM+wpasupp? Jan 06 12:05:59 wifi is not a priority for me, i love eth0 Jan 06 12:06:12 asac: no desktop at all Jan 06 12:06:20 NM works well without desktop Jan 06 12:06:24 i simply tried iwlist wlan0 scan Jan 06 12:06:25 i use it for that Jan 06 12:06:40 as root ;)? Jan 06 12:06:49 j.k. Jan 06 12:07:14 i would suggest to try wpasupplicant with nl80211 driver Jan 06 12:07:20 if thats supported by rt.... Jan 06 12:09:46 JamieBennett: MIRs... how are things blocked atm? Jan 06 12:10:12 ok Jan 06 12:10:14 ... Jan 06 12:10:20 all fine? Jan 06 12:10:20 2 MIR's unassigned Jan 06 12:10:41 you said some MIR was rejected? Jan 06 12:10:46 Embryo has concerns from pitti, basically we need to commit to supporting it Jan 06 12:10:57 whats embryo? Jan 06 12:11:08 a package used by edhe Jan 06 12:11:09 edje Jan 06 12:11:17 will it need as much attention as a real baby later ;)? Jan 06 12:11:28 JamieBennett: i mean: whats its purpose/use-case Jan 06 12:11:40 Its a VM that only edje uses Jan 06 12:12:21 how is that used from a high level perspective? e.g. for what is that used in our launcher stack? Jan 06 12:12:21 Upstream says its essential Jan 06 12:12:46 Isn't that the interpreter for the widget defintions? Jan 06 12:12:46 its used by edje which is an essential part of our launcher Jan 06 12:13:01 (its part of the design and layout bit) Jan 06 12:13:14 themes e.t.c Jan 06 12:13:17 well. thats not the perspective i mean :) Jan 06 12:13:23 i want to undersatnd why we need a VM ;) Jan 06 12:13:26 ah Jan 06 12:13:29 FOR EDJE Jan 06 12:13:30 so what persia said Jan 06 12:13:31 ;) Jan 06 12:13:54 edje doesnt really explain whats it used for ;) Jan 06 12:13:58 asac: E17 is all about being able to create really cool interfaces. It takes modularity to a mind-numbing level. Jan 06 12:14:15 so they invented a scripting language? Jan 06 12:14:25 For widgets. Jan 06 12:14:34 persia: indeed and edje is responsible for all theme, layout, image and font definitions Jan 06 12:14:50 to allow layout and animations Jan 06 12:14:52 Imagine a .desktop file on steroids, and then distill for a few years. Jan 06 12:15:06 lol Jan 06 12:15:07 ok Jan 06 12:15:09 i think i figure Jan 06 12:15:19 We also have code concerns about some pacakges Jan 06 12:15:25 JamieBennett: does that thing have a make check testsuite? Jan 06 12:15:28 is that run during build time? Jan 06 12:15:38 asac: no and upstream aren't planning on one Jan 06 12:15:53 what are the code concerns? Jan 06 12:16:04 An embedded turing-complete VM? Jan 06 12:16:39 recasting pointers, tty manipulation, the comments are on the MIR bugs Jan 06 12:16:48 let me bring them up Jan 06 12:17:06 thx Jan 06 12:17:30 https://bugs.edge.launchpad.net/ubuntu/+source/edje/+bug/489359 - edje Jan 06 12:17:33 Launchpad bug 489359 in edje "[MIR] Main inclusion request for edje" [Undecided,Incomplete] Jan 06 12:17:40 https://bugs.edge.launchpad.net/ubuntu/+source/evas/+bug/488923 - evas Jan 06 12:17:43 Launchpad bug 488923 in evas "[MIR] Main inclusion request for evas" [Undecided,Fix committed] Jan 06 12:19:14 The second one looks done, just waiting for the dep to show up. Jan 06 12:19:31 Albin (lutin) is an ubuntu developer as well as upstream Jan 06 12:20:22 persia: Albin has expressed concern that he will fix some issues but the code base is moving and may introduce more errors Jan 06 12:21:21 JamieBennett: so integrating embryo as a pkglib into edje sounds like a feasible approach Jan 06 12:21:26 like pitti suggested Jan 06 12:21:48 could be Jan 06 12:22:19 not sure what the best option Jan 06 12:22:27 I'd be more comfortable following Debian on this, as Debian has close upstream involvement. Jan 06 12:22:42 If we start significant change in packaging, we may end up out-of-sync in some awkward way. Jan 06 12:22:48 well. pitti is right Jan 06 12:22:49 and debian has asac :D Jan 06 12:23:00 armin76: Well, yes, but not for E17 Jan 06 12:23:01 persia: we wouldnt drpo the package from universe Jan 06 12:23:05 just duping code in edje Jan 06 12:23:09 so edje can go to main Jan 06 12:23:30 asac: Right, but the duplicated code ends up 1) causing security headaches, and 2) causing a merge lag. Jan 06 12:23:31 is albin the debian guy? Jan 06 12:23:32 JamieBennett: ? Jan 06 12:23:40 asac: yes Jan 06 12:23:46 lutin on freenode Jan 06 12:23:48 persia: security headaches are worse with it being a public api Jan 06 12:24:04 i will talk to him ;) Jan 06 12:24:08 debian shouldnt have this either ;) Jan 06 12:24:13 as they support everything Jan 06 12:24:53 k Jan 06 12:26:43 in worst case i dont see a big problem with internalizing it Jan 06 12:26:51 we have a commitment to support it Jan 06 12:26:58 obviously Jan 06 12:48:17 asac, huh ? the babbage only has a mini pci slot you can attach a wlan card to, nothing wlan related on board Jan 06 12:49:24 ogra: did you read a bit more context ;)? Jan 06 12:49:28 ogra: There's miniPCI? Jan 06 12:49:41 * persia is impressed at the growing number of available bus options Jan 06 12:49:46 pci feels like news to me. previously i was told arm doesnt have busses ;) Jan 06 12:49:58 ARM has busses, just not usually PCI. Jan 06 12:50:09 That said, my Orion server has PCI-e, so it's not impossible. Jan 06 12:50:12 yeah. thats what it boiled down to Jan 06 12:50:25 we have USB ;) Jan 06 12:50:36 and SDIO Jan 06 12:50:49 persia, well, a mini pci socket ... Jan 06 12:50:49 its in fact USB in the backend Jan 06 12:50:49 .oO(or are these thigs called micro PCI ? ) Jan 06 12:50:53 right, i was talking about the socket form factor Jan 06 12:51:17 ogra: But what *kind* of socket. You can do either SDIO or USB in a socket. Jan 06 12:51:21 (and lots of other stuff too) Jan 06 12:51:22 ogra: miniPCIe is better Jan 06 12:51:26 i have the same thing in one of my x86 laptops Jan 06 12:51:26 but there its attached to PCI Jan 06 12:51:37 all wifi cards for notebooks are PCIe nowadays Jan 06 12:52:47 Um, no. Jan 06 12:53:03 I purchased a notebook in 2008 with SDIO wifi Jan 06 12:53:11 And another one in 2009 Jan 06 12:53:25 yes. but no miniPCI (which was the point) Jan 06 12:54:04 persia, if i plug in the wifi card i get an usb device in dmesg Jan 06 12:54:05 right, miniPCIe is it then Jan 06 12:54:07 right Jan 06 12:54:11 just a special socket for USB Jan 06 12:54:11 Well, again no. The Panasonic toughbook line is *still* miniPCI Jan 06 12:54:27 miniPCIe != USB Jan 06 12:57:34 persia, SATA != USB ... Jan 06 12:57:50 persia, still the babbage has both sockets attached to the USB controller Jan 06 12:58:23 ogra: Sure. I'm just saying "right, miniPCIe is it then"..."just a special socket for USB" doesn't make sense. Jan 06 12:58:30 If there's hardware to convert, that's fine. Jan 06 12:59:06 well, i have these sockets, but effectively they only offer USB devices Jan 06 13:00:42 But what kind of socket are they? What's the line protocol? Jan 06 13:01:12 no idea ... i can only judge by the plug :) Jan 06 13:01:50 how many pins? Jan 06 13:02:40 18+8 Jan 06 13:03:07 or 36+16 if you count that the board you plug in is double sided Jan 06 13:03:17 That does sound like miniPCIe. Odd to stick a PCIe controller on a USB bus. Jan 06 13:03:52 well, as odd as sticking a SATA socket on a USB bus Jan 06 13:04:08 the board simply has only that one controller Jan 06 13:04:10 Actually, that makes a lot more sense. I use SATA over USB regularly on lots of machines. Jan 06 14:36:47 persia: which server is that? :) Jan 06 14:40:14 what kind of devices are ARMv4 without T? Jan 06 14:40:18 armin76: ? Jan 06 14:40:21 does debian support that? Jan 06 14:41:07 asac: ARMv4 without T = arm Jan 06 14:41:24 armel = eabi, which requires thumb interworking Jan 06 14:41:32 which is what T means Jan 06 14:41:38 k Jan 06 14:41:59 but what i am interested in is if someone would want to support that for lets say firefox? Jan 06 14:42:00 what devices...well, old stuff: netwinder, cats Jan 06 14:42:08 so probably not Jan 06 14:42:19 what specs are we talking about there? Jan 06 14:42:26 nailboard Jan 06 14:42:40 the netwinder is 133mhz/128mb Jan 06 14:43:20 Hostname: coral - OS: Linux 2.6.25/armv4l - Distro: Gentoo 2.0.0 - CPU: StrongARM-110 rev 4 (v4l) - Processes: 41 - Uptime: 283d 20h 46m - Users: 1 - Load Average: 0.08 - Memory Usage: 18.36MB/124.01MB (14.80%) - Disk Usage: 15.37GB/35.82GB (42.92%) Jan 06 14:43:32 oh Jan 06 14:43:36 HP Jornada stuff as well Jan 06 14:44:01 the netwinder was a nice device back in 2003 Jan 06 14:44:21 err, wait Jan 06 14:44:28 its 275mhz, not 133 :) Jan 06 14:47:38 asac: http://dev.gentoo.org/~armin76/arm/armhw.xml Jan 06 14:49:15 thx Jan 06 14:50:44 thats just a list of hardware ppl at #gentoo-embedded have, its definitely not a list of all ARM hardware Jan 06 14:51:58 asac: but anyway the most important armv4 devices are the netwinder, cats, and HP Jornada, but they're pretty old as of now, and debian has deprecated support for it anyway Jan 06 14:52:24 ok. thats more than enough for now ;) Jan 06 14:52:40 lets look at the future! Jan 06 15:23:14 asac: teh omgz, hows that ubuntu doesn't have latest pixman?! :D Jan 06 15:23:51 thats X topic Jan 06 15:24:06 asac: quick! Jan 06 15:26:41 asac: btw i'm not sure if you guys are going to have trouble with pixman on dove, as it gets built with -mcpu=cortex-a8 and -mfpu=neon Jan 06 15:26:54 i'm no expert though Jan 06 15:27:33 afaik it would fail it if gets built on a dove Jan 06 15:28:01 it also fails on bbg Jan 06 15:28:08 we dont use NEON enabled kernels atm Jan 06 15:28:16 fails to build or? Jan 06 15:28:37 no point in using neon enabled kernels if dove isn't neon :) Jan 06 19:36:43 Too bad they didn't announce any kind of dates. But sure, they were first to print a press release: http://www.marvell.com/armada/quadruple_core_arm_instruction_set/release/1363/ Jan 06 19:39:08 ojn: does your board have wifi? :) Jan 06 19:39:22 armin76: which board? Jan 06 19:39:57 ojn: nettop Jan 06 19:40:11 well, yeah. and it worked in jaunty but not with karmic Jan 06 19:40:30 haven't had time to debug it, still have visiting family and a bunch of stuff going on at work Jan 06 19:41:58 ojn: ah, i see, i remember about your dmesg :) Jan 06 20:49:50 Hi. I am using Ubuntu ARM as testing platform on a QEMU emulator. The emulator has 256MB of RAM, but I'm wondering: what are the minimum requirements for running Ubuntu ARM? (CLI only) Jan 06 21:10:28 Afternoon all Jan 06 21:10:43 Who here is most familiar with the PL340 (arm DRAM controller?) Jan 06 21:49:52 asac: chromium+v8 built on armv7a, but it still fails on armv5te, i built the latter with debug, this is what it says: http://dpaste.com/141828/ Jan 06 22:11:16 armin76: Are you familiar with how to bring up the DRAM controller? Jan 06 22:11:18 the PL340? Jan 06 22:15:35 Martyn: Doesn't ARM have the configuration sequence in their documentation? Jan 06 22:16:28 Martyn: i wish :/ sorry i can't help Jan 06 22:16:50 ojn : It does, but I'm looking for the code that does so in the linux kernel and not finding it Jan 06 22:17:17 ojn : I'm starting to think the only time the DRAM controller gets touched is during early system boot, in the bootloader... Jan 06 22:36:10 well, yeah Jan 06 22:36:16 it's hard to configure the memory underneath yourself Jan 06 22:36:28 especially since you need DRAM up to load and run linux Jan 06 22:36:45 Some ports do re-tuning of parameters, but that's a pretty scary thing to do (OMAP sometimes changes timings) Jan 07 00:29:18 armin76: is v8 being built for arm or in that error message? Jan 07 00:29:30 s/arm or/arm or thumb/ **** ENDING LOGGING AT Thu Jan 07 02:59:56 2010