[02:12] GrueMaster: still building, soon you'll get it [02:13] No rush. I've started packing for my flight tomorrow. I'll test first thing Monday once I'm setup. [02:13] GrueMaster: oh, are you leaving tomorrow? [02:13] I'm feeling rather bushed and my son is down for the weekend to celebrate his 21st birthday with his friends. [02:13] I fly out tomorrow morning. [02:16] GrueMaster: quite soon :-) [02:17] well, it's a long flight for you [02:17] 13 hours or something like that. [02:17] hm, about the same for me if I'd go there [02:18] talking about trips I need to book my uds trip [02:19] where's UDS going to be this time ? [02:19] orlando [02:20] yeuch [02:20] dates ? [02:20] 25th - 29th October [02:20] thanks. I know some nice place in Colorado we could have it... [02:33] I thought I saw a new kernel get uploaded today ? [02:33] still trying to get my XM board to work stably... [09:47] cooloney: Morning [10:26] ogra: Hi! I started testing your [10:26] http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100812/maverick-preinstalled-netbook-armel+omap4.img.gz image [10:28] on my PandaBoard ES 1.0. [10:28] I get the below error message after the reboot: [10:28] http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100812/maverick-preinstalled-netbook-armel+omap4.img.gz [10:28] Oops, here's the error: http://pastebin.com/iKWD7Umg [10:34] lag: morning man [10:35] cooloney: Hey Bryan [10:35] cooloney: How are you getting on with your packaging work? [10:36] lag: yeah, just rebased to our 2.6.35 master tree [10:37] and sent out an email to discuss the maintanenc method [10:37] lag: how about your review? [10:37] i think ndec is still working on the integration tree, since there L24.9 branch is increasing [10:39] ogra: I wonder what's responsible for the "Exec format error" message. === fta_ is now known as fta [10:43] cooloney: Yes, I saw your email [10:44] cooloney: I was chatting with apw and tgardner yesterday about the maintenance issues [10:44] cooloney: It's quite a complex one [10:45] cooloney: It would be easier if TI's tree was based solely on Linus' 2.6.35 tree [10:46] lag: right, i also asked that question in the email to ndec [10:47] lag: but that's TI's internal process. i hope we can get such ti patch stack on Linux 2.6.35 release [10:47] lag: currently, it is not easy for them to change. [11:09] cooloney: How did you do the last one? [11:12] lag: sorry, what's the last one? [11:12] The last release [11:13] oh, the last release is simpler, since we just rebased TI's 230+ patches on top of our tip tree. === amitk is now known as amitk-afk [11:18] So what makes this any different? [11:21] lag: actually no big difference to me, just 1300+ patches vs 230+ patches. [11:21] and it is 2.5.35 based release [11:22] we cannot simple rebase on our -ti-omap4 branch, but need to rebase on our master [11:22] since our master is also 2.6.35 based [11:22] When I do a git merge onto master, I only receive one (easily correctable) issue [11:22] yeah, that's it. [11:22] i got 2, [11:22] today. [11:23] but 2 of them are omap3 related [11:23] so it won't be much difficult. [11:24] apw's method is not necessary this time [11:27] You have to revert ce8bd5fb89ad58d345a5eaef52e7fa6f5683f5a9 [11:27] Then you only get one [11:28] cooloney: -^ [11:29] lag: thx, man, you fixed 50% rebasing issues [11:30] lag: and as ndec said in his latest email, we still need to wait for their integration release [11:30] that's our upstream, L24.9 is just their monthly release tree. [11:35] Well, why don't we wait then? [11:35] I'm guessing sebjan will ensure their tree _fits_ on ours [11:36] cooloney: The other conflict should be easy too [11:36] cooloney: The one in HEAD looks far more correct than the other [11:37] Just delete [11:37] ======= [11:37] dss_clk_enable(); [11:37] r = dsi_pll_init(dssdev, 0, 1); [11:37] >>>>>>> L24.9 [11:37] and obviously <<<<<<< HEAD [11:37] The result of the successful merge can be found here: http://kernel.ubuntu.com/git?p=lag/ubuntu-maverick.git;a=shortlog;h=refs/heads/ti-omap4-35 [11:38] Now I just need your packaging work to test [11:50] lag: how did you do that? git merge? [11:50] cooloney: Yeah [11:50] lag: i found you missed some patches from L24.9 branch [11:50] Oh? [11:51] When were they released? [11:51] Give me the commit ids [11:51] lag http://dev.omapzoom.org/?p=integration/kernel-omap4.git;a=shortlog;h=refs/heads/L24.9 === fta_ is now known as fta [11:52] they updated their tree yesterday, i think [11:52] the release for us is supposed to be next week. [11:52] ndec and sebjan will work on it. [11:52] please find my rebase result here [11:52] http://kernel.ubuntu.com/git?p=roc/ubuntu-maverick.git;a=shortlog;h=refs/heads/ti-release-rebasing-testing [11:53] cooloney: I didn't miss anything - they weren't in the tree then [11:53] I thought it was for Friday? [11:54] cooloney: It's pointless merging now, they are going to be updating it daily [11:54] We should wait until our proper release date [11:54] lag: right, we have to wait [11:54] ndec: Are you there? [11:54] so i just test rebasing is simple for this release [11:54] cooloney: Me too [11:54] lag: hi!@ [11:55] ndec: Hello :) [11:55] We've been discussing how best to handle your tree [11:55] lag: oh i see... i saw the emails but was not watching irc... [11:56] When it our release date? [11:56] is* [11:56] lag: cooloney: the current l24.9 branch is quite broken, especially on panda, we are trying to fix this. [11:56] ndec: Do you have people working on the checkpatch errors too? [11:57] lag: unfortunately, I will be on vacation next ;-)... but sebjan will come back mid of next week. [11:57] lag: for checkpatch, this is a bit more complicated... [11:58] lag: our dev process implies that our dev teams are moving to .36, so very likely they will not addess them in a .35 release. [11:59] ndec: after a quick review of the checkpatch result file, i think just several patches cause most of errors [11:59] lag: i will need to see what we can do with sebjan for the most critical one [11:59] ndec: if we pointed them out, they can help to fix that in .36 [12:00] cooloney: well .36 won't help since we will stay in .35. but since you have the list already, you can send that to me and sebjan and we can address them [12:00] ndec: yeah, i know that. but i don't think we can fix those 2800++ coding style errors in this release. [12:00] ndec: Would it be possible to insure your developers run checkpatch before applying their work in future [12:00] just wanna let them know this. [12:01] mopdenacker, i wish too i would know that, we're hunting this bug since monday [12:01] cooloney: lag: we are working on this... [12:01] cooloney: lag: they know. [12:01] ndec: If you every want to upstream your code, it will have to become a common operating procedure [12:01] mopdenacker, if you want a working install, use the alpha3 milestone image [12:02] ogra_cmpc: thanks. That's good to know that I'm not the only one... [12:02] ndec: actually, i think for TI git server we can add some git post-commit script which will call checkpatch.pl to check every commit [12:02] ogra_cmpc: OK, I will do that. Thanks! [12:02] lag: it's part of the procedure. the main problem is time pressure and h/w problems that we need to work with [12:02] ndec: Don't we all :) [12:03] ndec: technically it will drop those commit having coding issues [12:03] cooloney: we know all of this... [12:03] ndec: :D [12:03] lag: yes we do. then it's a matter of prioritization ;-) [12:03] ndec: right, i understood [12:03] ndec: Indeed [12:04] ndec: When is your release date? [12:04] lag: at the end of the day we make h/w... and this is much less soft than software ;-) [12:04] ndec: i agree the first thing we need is working stable 2.6.35 based release for both panda and blaze [12:04] lag: on 17th we should get an updated BSP [12:05] So we'll pull your tree then? [12:06] cooloney: they have been some updates this night in L24.9 branch. I still haven't had a chance to build, but they are supposed to have fix the panda boot problem. [12:06] rcn-ee: ping (when you're up) [12:06] ndec: cooloney: We should wait until the release date [12:06] ndec: got it, awesome. need any help, please let use know [12:07] ndec: cooloney: It's pointless merging until it's finished [12:07] lag: for this specific release where our dev team release is on .35, yes, you can pull from L24.9 branch. then we will create a stable branch on http://dev.omapzoom.org/?p=integration/kernel-ubuntu.git;a=summary for the updates [12:07] lag: yeah, === amitk-afk is now known as amitk [12:07] ndec: And when's that due? [12:07] ndec: indeed. that's way we worked for several monthes [12:07] cooloney: When will your packaging be finished? [12:08] lag: agreed. it's pointless untill I or sebjan tells you that it's booting on panda and blaze, let us do the dirty stuff first ;-) [12:08] lag: i have to wait for that release [12:08] lag: final L24.9 branch from dev team due on 17th [12:08] ndec: I have every intention :) [12:08] * ogra_cmpc hands ndec some gloves [12:08] ndec: Noted [12:08] lag: need to sync config files with the latest release. [12:09] ogra_cmpc: for this specific item I will be on vacation ;-), so I am passing the gloves to sebjan [12:09] ogra_cmpc: Why? Do you have something stuck up there which you'd like removing? [12:09] ndec, haha [12:09] lag, no, for not getting his hands so dirty [12:09] ogra_cmpc: ;) [12:09] heh [12:10] lag, i'm well able to remove stuck things myself :P [12:13] ogra_cmpc: Comes with practise I suppose :) [12:13] ogra_cmpc: Where should the jasper.log file be? [12:17] lag, after the install run in /var/log, during initramfs in /dev/.initramfs/ [12:18] (jasper copies it over as the last step before the reboot) [12:18] It's not in /var/log [12:19] then check /dev/.initramfs/ [12:19] (if it still exists) [12:20] ogra_cmpc: http://paste.ubuntu.com/477403/ [12:20] Does that look okay to you? [12:21] ogra_cmpc: My Panda comes to a crashing halt when the purple screen appears [12:22] The cursor and the background is visible but nothing else [12:22] hit enter after waiting a few mins [12:22] And my USB mouse and keyboard no longer work [12:22] i suppose you are using a newer image than A3 ? [12:22] I am using the latest daily build [12:22] oem-config dies for no apparent reason since monday [12:23] Okay [12:23] What's the link to the most stable version? [12:23] take A3 [12:24] http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/maverick/ [12:24] I have it [12:33] lag pong. ;) [12:33] Good morning Robert [12:34] Hi Lee, how's it going. [12:34] Are you well? [12:34] Very good thanks [12:34] Have you heard anything regarding your ro patch? [12:35] i'm good, it's friday.. ;) I need to quickly verify on my C2/C4 before i post version 3... (it'll be this afternoon as i get off at noon) [12:36] Are you going to shift all the code to board-omap3beagle.c on v3? [12:36] yeap i did.. [12:36] Good stuff [12:36] Hopefully they're leave you alone on this one [12:36] What happens once it's been approved on linux-omap? [12:36] Do you have to submit it upstream? [12:37] nah i'm not woried. ;) they are here for reference.. http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/2.6.35-devel/files/head:/patches/gpio/ [12:38] after linux-omap, tony will probally push them for 2.6.37... (in for-next) (the 2.6.36 merge can't last for maybe another day or two..) [12:39] ndec, can you include asac in the invite for the friday call ? [12:41] rcn-ee: Is Tony the linux-omap maintainer? [12:42] lag: he is [12:42] lag: want to meet him? [12:42] Sure, why not! [12:43] lag: come to Helsinki on Tuesday, I'm having lunch with him [12:43] amitk: Not that I have anything to say :) [12:43] amitk: I'll just nip over :) [12:43] Yeap Tony is the linux-omap maintainer.. [12:44] rcn-ee: how are your stocks of XMs? :) [12:45] rumor up the grape vine... possibly next week.. but i'll probally say that again next week.. ;) [12:46] rcn-ee: You can have mine when amitk sends me the new version :) [12:47] i'll trade you my 256 xMA P7 for your 512. ;) [12:47] even thou the 512's have memory problems, they stay up longer then my 256. ;) [12:48] rcn-ee: I'll think about it [12:48] rcn-ee: nah === fta_ is now known as fta [13:04] lag, you are not seeing Bug 605488 because we dont use swap currently, create a swapfile and add it to fstab, then see if you get the errors [13:04] Launchpad bug 605488 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "BUG: scheduling while atomic: mmcqd/46/0x00000002 (affects: 1) (heat: 132)" [High,In progress] https://launchpad.net/bugs/605488 === fta_ is now known as fta [13:54] rcn-ee: Not having much luck there are we? :) [14:07] rcn-ee but nice you're working on this issue, things will be much easier to merge when we get your patches at least linux-omap upstream :-) [14:08] rcn-ee: some other questions I have, related with xM [14:08] lag, getting closer. ;) one little tweak at a time.. ;) [14:09] maybe lag and ogra can tell more about it [14:09] I wanted to understand the known issues we got with the hardware [14:09] I have a p8 board [14:10] lag: what rev is your xm? [14:10] that has the bad 512Mb Micron, some work, some don't... Production boards are using Neomonix.. well until Micron figures out why they corrupt randomly. [14:10] i have a P7, it's 256Mb Micron.. [14:10] rcn-ee: oh, got it, thanks for the info [14:10] * ogra has micron too, but rev. A [14:10] it has other issues, like crashing into a ball of fire when your run "sudo aptitude update" [14:10] my former one was P7 as well [14:11] but with 512M [14:11] random issues doesn't seems good hehe [14:11] i think the rev. A ones are supposed to be more stable but i might be wrong [14:11] that's weird.. according to my cheat sheet from gerald, the P8 was the first 512, but considering those are marked with a marker. ;) [14:12] hmm, i might misremember and it might have been an 8 [14:12] * lag has a Micron [14:12] lag: but what rev? [14:12] i think all out are micron right now.. the actuall production ones will be Nuemoinx.. [14:13] let see "A" changed gpio related to mSecure, USB host1 (to a header), USB reset and Sysboot changes.. === fta_ is now known as fta [14:15] rcn-ee: cool, you have the logs :-) [14:16] yeah the early one... hasn't been updated since May thou.. the current log is on the schematic of the "A2" on beagleboard.org (it doesn't have the old Px changes) [14:16] * rcn-ee runs work back in a couple hours. [14:19] I think the USB is broken on my Panda :( [14:21] lag: why? [14:24] It doesn't work [14:24] usb 1-1: new high speed USB device using musb_hdrc and address 3 [14:24] usb 1-1: device descriptor read/64, error -110 [14:24] usb 1-1: device descriptor read/64, error -110 [14:24] usb 1-1: new high speed USB device using musb_hdrc and address 4 [14:24] usb 1-1: device not accepting address 4, error -110 [14:24] usb 1-1: new high speed USB device using musb_hdrc and address 5 [14:25] usb 1-1: device not accepting address 5, error -110 [14:25] hub 1-0:1.0: unable to enumerate USB device on port 1 [14:28] lag: es1.0 board:? [14:28] How do I tell? [14:28] black or not ? [14:29] lag: is the pcb green or black? [14:29] es2.0 are painted black [14:29] the only issue I saw regarding the usb is the dma problem [14:29] musb_hdrc.use_dma=0 could help, but not sure if you're getting the same issue [14:29] lag, given that you didnt tell us about a new board you got this week i'd say es2 [14:29] err [14:29] es1 [14:29] lag: es2 has the pandaboard logo [14:30] because of some hardware issues related to the the TWL6030 configuration on ES1.0 boards, not all the time when the board boots with something plugged into the MUSB does it enumerate properly [14:30] and apart from tobin the es2.0's should all still be in delivery [14:30] try rebooting with the MUSB unplugged and plug it in after booting [14:31] * ogra wonders how much the pandas differ within the es1.0 line [14:32] i havent seen any issues regarding musb on my es1 [14:32] ogra: it varies [14:32] yeah, i was guessing so, like the XM [14:33] Green [14:33] now that was a prompt answer :P [14:33] ogra: shh [14:33] ogra: I'm doing more than one thing at once [14:34] really ? [14:34] you can ? [14:34] lol [14:34] I think you misunderstand me - it used to work [14:34] lag: you mutli-task? [14:34] * ogra always secretly suspected female genes in lag [14:34] lag: new kernel ? [14:34] there was a new meta today so likely a new kernel too [14:34] prpplague: Yeah [14:35] prpplague: I'll test the kernel separately - wait one [14:35] lag: np, [14:35] hmm, the kernel is from the 5th though, i wonder why meta wasnt updated alongside [14:35] I tested the newer kernel already, seems to be working fine [14:36] lag: try a simple test, just boot the boot without anything plugged into the MUSB and then plug it in after booting [14:36] ogra: cooloney forgot about it [14:36] when he updated the main debs [14:36] rsalveti, ah [14:36] would have been nice to have it in the alpha release though :P [14:36] ah well [14:37] cant have everything [14:37] * ogra glares at the maverick-changes ML [14:38] coinor-flopc++ ... [14:38] looks like someone just hit random keys to make up a package name [14:39] * prpplague tries to decide what to do about panda audio [14:39] prpplague, emmet (persia) will take care of it (at least he said so yesterday) [14:39] ogra: ?? [14:40] ogra: you mean about the audio? [14:40] though i dont see him online today, seems he still has issues with his new appartment and internet [14:40] prpplague, yep [14:40] ogra: ahh, right, this is more for internal TI L24.x release [14:40] the ASoC module needs to expose the right stuff to make pulse aware of the different devices i think [14:40] it doesnt do that atm [14:40] ogra: i'm trying to decide if panda should share the sdp4430 audio file, or split it off for it's own [14:41] ah [14:41] ogra: yea that is being done in the L24.9 release [14:41] main target needs to be to not need an asound.conf [14:42] hmm [14:42] ogra: the thing is that the panda doesn't have a number of the channels that the sdp has [14:42] ogra: none of the mic [14:43] well, then the driver needs fixing === JamieBen1ett is now known as JamieBennett [14:43] asound.conf is a hack to override broken driver defaults, if the driver doesnt expose the right HW to userspace that needs fixing in the driver [14:43] ogra: right, so the question is, do we share the sdp4430.c file and add a bunch of "machine_is_omap4_panda()" or do i create a seperate file [14:44] heh, your choice i guess, whats working better for upstreamability later ? [14:44] yea that's what i'm trying to think through now [14:45] prpplague, you could probably ask lrg as ASoC upstream buy ;) [14:45] s/buy/guy/ [14:46] ogra: yea already have a ping out for him this morning [14:46] ah [14:46] ogra: he's burried with the L24.9 release as well [14:46] heh [14:46] all of TI is it seems [14:47] * ogra is only sitting with a bucket on his knees waiting to catch the stuff that comes downstream :) [14:47] hehe [14:48] what a nice metaphor [14:48] It could have been worse [14:49] hehe [14:52] lool, you mean it could be a cup ? [14:54] it could be in another place than on your knees === zyga is now known as zyga-lunch === JaMa is now known as JaMa|Away === zyga-lunch is now known as zyga [15:48] ogra: I've tried the alpha3 installer and it works fine so far... [15:48] great [15:49] ogra: The only bad thing is that the first boot phase is completely silent for a few minutes (while it extends the partition). I had to add "console=ttyO2,115200n8" to the bootargs to actually see something. [15:50] This could confuse users, thinking that their system is frozen. And they could reset their board and corrupt their rootfs which is currently being resized. [15:50] well, the image is designed in a way that you dont need to use serial [15:51] you should attach a HDMI monitor [15:51] ogra, I understand... [15:51] how big is your SD ? [15:52] 8 GB [15:52] the resizing shouldnt take more than a few mins (1-2) nowadays [15:52] ogra, you're right. It took approximately 2 minutes. [15:52] lag> It doesn't work [15:52] usb 1-1: new high speed USB device using musb_hdrc and address 3 [15:52] usb 1-1: device descriptor read/64, error -110 [15:52] usb 1-1: device descriptor read/64, error -110 [15:52] usb 1-1: new high speed USB device using musb_hdrc and address 4 [15:52] usb 1-1: device not accepting address 4, error -110 [15:52] usb 1-1: new high speed USB device using musb_hdrc and address 5 [15:52] usb 1-1: device not accepting address 5, error -110 [15:52] we fixed that right before the alpha release (i didnt remove the thxt that tells you "10min per 4G yet) [15:52] hub 1-0:1.0: unable to enumerate USB device on port 1 [15:53] *text [15:53] I did attach an hdmi display, but nothing got displayed during the first boot phase (before the reboot to the installer) [15:54] intresting, but it did work on second boot ? [15:54] ogra: Yes, it did. [15:54] hmm, weird [15:55] robclark, ^^^ any idea why the first boot wouldnt work on HDMI but the second does ? [15:55] (we dont change any graphics related boot options or anything) [15:55] ogra: hmm.. is the first boot over too quickly before the monitor can sync? [15:56] and is there any way you could get a bootlog w/ omapdss.debug=1? [15:56] no, it takes a few mins [15:56] Someone's USB broken also? [15:56] hmm.. and same kernel? [15:57] and it does an auto-reboot so capturing the dmesg is a bit of an effort [15:57] oh, ok.. [15:57] its the alpha3 release, works on my monitor for first and all subsequent boots [15:58] well, I can't think of any particular reason why it would not work on first boot, but would work on subsequent boots.. but I guess I don't know enough about what changes between first boot and second boot.. [15:58] same MLO/u-boot/uImage? [15:58] yes, all the same [15:58] any difference which could change timing and expose a potential race condition? [15:58] first boot is console only, second is using plymouth [15:59] and i think GrueMaster saw some similar issues in the past [15:59] ndec: ping [15:59] hmm.. but framebuffer should come up before you even get to userspace.. [15:59] yeah [16:01] jayabharath: ping [16:03] lag: hi === orbarron|OoO is now known as orbarron [16:04] lag: did you try to plug in usb kybd after boot up.. [16:04] lag: there was a problem that sometimes usb peripharl was not detected when you have it plugged in on cold boot [16:06] jayabharath: I have [16:07] lag: can you send you me your kernel image, i'll test here [16:07] lag: and info on what kernel source you are using [16:07] prpplague: Email address? [16:07] lag: x0132446@ti.com [16:09] prpplague: I remeber there was a TWL OTG VBUS issue.. was this a HW fix or kernel change [16:09] jayabharath: kernel fix === JaMa|Away is now known as JaMa [16:16] jayabharath: prpplague: I'm going to rebuild our latest kernel [16:16] prpplague: When I've done so, I'll send you the .deb [16:29] ogra: thanks for targeting the bugs for beta [16:29] easier to track now [16:29] rsalveti, well, i have to else i'll get grilled in the release meeting :) [16:30] oh, true :-) [16:39] ogra: I got disconnected from the Internet, sorry. I may have missed replies from you. [16:41] mopdenacker, i didnt reply any further to you, i just know that someone in here (i think GrueMaster) had a similar prob before [16:42] Sorry, what was the issue? [16:42] ogra: All right... we can continue to investigate. Thanks! [16:42] GrueMaster, black screen on first boot on the panda but working monitor after the first reboot [16:42] GrueMaster: having no graphical output with the preinstalled images.... [16:42] (after resizing) [16:43] I was seeing that too yesterday, even with my additional parameters I have had to set. Not even seeing serial console output. [16:43] Though in both cases, I had to add hdmi driver bootargs to get the display to work. [16:44] Right, console serial output wouldn't hurt, even if a serial console is not a requirement. [16:44] My panda first boot cmdline: [16:44]