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