=== bjf is now known as bjf[afk] === bjf[afk] is now known as bjf === bjf is now known as bjf[afk] === bjf[afk] is now known as bjf === freeflyi1g is now known as freeflying === hrw|gone is now known as hrw === XorA|gone is now known as XorA [10:01] sebjan: ping [10:01] lag: pong [10:02] Is all the Syslink code going upstream eventually? Or is it going to reside solely in the Ubuntu kernel? [10:03] this version of the syslink code will not go upstream. Next version is more suitable to go upstream. [10:04] Okay [10:04] I sending my patch to the kernel mailing list now [10:05] lag: great, thanks! [10:08] Gone [10:08] And now ... we wait [10:08] :) [10:15] any news on solution to the git clone issue on omap4? [10:21] XorA: it is fixed with this patch: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=commit;h=d96ac19bf235fb639bc29ad3f7db210174e429c2 [10:25] sebjan: thanks [10:27] ogra: I am downgrading my bb to 6b18 openjdk === amitk is now known as amitk-afk [11:12] hrw, dyfet now has the task to help you working on that [11:16] * ogra_panda waves [11:18] * cooloney waves back to ogra_panda smiling like a panda [11:18] ogra_panda: we can get a working panda image for downloading now? [11:19] cooloney, not yet, seb128 uploaded a new glib, once thats in the archive i can respin, while we have images, they still have the segfaulting kernel [11:22] grmbl [11:22] crashed again [11:22] cooloney: What's the current state of bug 588243 [11:23] Launchpad bug 588243 in linux-ti-omap (Ubuntu) (and 1 other project) "kernel BUG at /build/buildd/linux-ti-omap-2.6.33/drivers/video/omap2/dss/core.c:323! (affects: 1) (heat: 96)" [Undecided,New] https://launchpad.net/bugs/588243 [11:23] lag: oh, sorry, no update. [11:23] as long as i got the hw, i will start to debug that [11:25] What hw do you have currently? [11:26] lag: nothing at all -:< [11:27] cooloney: That's rubbish [11:30] i will got it tommorrow [11:30] What will it be? [11:30] C4? [11:30] god, IO really sucks [11:30] panda, i think [11:31] cooloney: That bug I sent you affects Lucid - Beagleboard [11:31] the MMC driver surely needs love [11:32] ogra_panda: Which board? Going by your name, Panda? [11:32] right [11:32] What's wrong with it? [11:32] tab completion can make the board stuck for 30sec [11:33] * lag checks [11:33] like hard hanging until the rest of the directory name is printed on the term [11:33] but at least i have a working image now [11:34] You do? What was wrong? [11:34] segfaults over and over [11:34] Are you running a full Desktop system? [11:34] lag, i'm running what you should run as well, the ubuntu images := [11:34] :) [11:34] ogra_panda: what's the kernel version [11:35] cooloney, now its the one uploaded yesterday [11:35] i think we got some fixing patches in ti-omap4 [11:35] 901.4 i think [11:35] * lag is a Kernel Engineer - GUIs are for weaners [11:35] that one is a lot better but still sucks at SD I/O [11:35] :) [11:35] ogra: boot from sd but keep rootfs on usb (if it works) [11:35] I'll download the latest [11:35] lag, thats the reason why we always get broken kernels from the kernel team :P [11:35] Do you have a quick link? [11:35] you guys only test if serial works :P [11:36] * lag sees ogra's lips moving, but doesn't hear the noise [11:36] ogra: you need more? really? [11:36] haha [11:36] lag, http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/ wait for 20100707, i'll do a rebuild shortly [11:37] with the latest kernel [11:37] 06 isnt really usable [11:37] due to permament segfaults in 900.1 [11:37] * ogra_panda ponders if he should be brave and try firefox [11:38] lets see :) [11:38] run firefox, come back tomorrow - maybe it will be loaded [11:38] runs fine :) [11:39] couls scroll a bit smoother [11:39] *could [11:40] but is definately the fastest i have seen on arm framebuffer yet [11:40] still fbdev in use? [11:40] sure, we dont have an X server for panda in the archive [11:41] * lag 's monitor still doesn't want to work with the Panda board [11:41] :( [11:42] font rendering sucks [11:42] i wonder why [11:43] it runs at 1920x1080 [11:43] the fonts should be smooth [11:44] beyond the IO issues and the ugly fonts its as fast as an ATOM i'd say [11:44] it even boots in 15sec after u-boot [11:44] i.e. switching on screen to gdm [11:45] htop shows 281MB used with gnome-terminal, FF and xchat open [11:46] shot? [11:46] lag, i think GrueMaster experimented with display settings yesterday and found several options to use DVI adapters [11:47] lag: using hdmi or dvi porT? [11:48] hrw, DVI port doesnt work [11:49] hrw, http://people.canonical.com/~ogra/panda_shot.png [11:49] 23:13 < GrueMaster> IF I plug the switch into the DVI port and the monitor HDMI>DVI cable into the HDMI port, I get video. [11:49] heh, the fonts look fine in the screenshot [11:50] ogra: check cables? [11:50] hrw, weird, afaik there is no signal on the DVI port in the current revision [11:50] the cable is fine [11:50] i think the frequency isnt [11:50] it runs at 60Hz while it should be running at 50 [11:51] sadly you cant influence the resolution at all [11:51] kernel reads EDID and automatically picks the highest res [11:51] it does what monitor says [11:51] ogra: you can [11:51] you cant [11:51] hrw: I can use either [11:51] 18:32 <@prpplague> Magdalena: for the panda you can just pass the bootargs omapdss.hdmimode=0 omapdss.hdmicode=35 [11:51] omap4 doesnt accept resolution options [11:52] 18:32 <@prpplague> Magdalena: that will get you the basic 1024x768 mode that is common to most displays that support vesa/dvi [11:52] 18:33 <@prpplague> GrueMaster: if you check the hdmi code you can see a number of display modes, using the HDMI to run a DVI display you need to use the VESA modes [11:52] well, if i enforce a mode i'm not sure my monitor will be able to use it on HDMI [11:52] try? [11:52] i think it only can 720p and 1080p on the HDMI port [11:53] its more flexible on DVI [11:53] use hdmi->dvi? [11:53] well, first i have a lot of other stuff :) [11:53] display is my least sorrow [11:53] Display is my largest-bugbear [11:53] Trying ... [11:53] * ogra_panda tries some high load websites [11:55] hrw: Nope [11:56] * ogra_panda wonders why avahi cant resolve [11:56] i can only ping myself on a .loacl address [11:57] *local [11:57] tell me when you will resolve that [11:57] ssh hrw@192.168.1.137 is less fun then ssh hrw@beagle.local [11:58] yeah [11:59] ogra@osiris:~$ ping panda.local [11:59] PING panda.local (192.168.2.114) 56(84) bytes of data. [11:59] 64 bytes from panda.local (192.168.2.114): icmp_seq=1 ttl=64 time=35.6 ms [11:59] hmm, the other direction works [11:59] but i cant ssh into my laptop via the local address [12:00] hrw: When we use HDMI->DVI, which port do I use on the PB? [12:01] lag, try both ? [12:02] Am doing [12:03] lag: from how I understood GrueMaster config he has DVI occupied but not used and hdmi output used for display [12:04] HDMI->HDMI[X] HDMI->HDMI&DVI-D->DVI[X] HDMI->DVI[X] [12:04] :( [12:04] And DVI-D->HDMI[X] [12:04] :'( [12:05] lag: connect dvi and hdmi at same time [12:05] no sound :( [12:07] I tried that [12:07] HDMI->HDMI&DVI-D->DVI[X] [12:09] setenv bootargs omapdss.hdmimode=0 omapdss.hdmicode=35 vram=32M, omapfb.vram=0:8M console=tty2 console=ttyO2,115200n8 noinitrd mem=512M root=/dev/mmcblk0p2 rootdelay=1 ip=none; mmcinit 0; fatload mmc 0 0x80200000 uImage; bootm 0x80200000 [12:10] What's our cmdline ogra? [12:11] only vram=32M, no further video related options [12:11] mem=512M is definately wrong [12:11] I've tried that oo [12:11] too* [12:12] What should it be? [12:12] that will try to write in coprocessor occupied ram regions [12:12] 463 [12:12] (as i understood mem=463M is mandatory, thats why we use it on the images) [12:13] why the heck are you using rootdelay ? [12:13] i thought kernel devs know thats deprecated :P [12:13] lag: use rootwait [12:14] ogra@panda:~$ cat /proc/cmdline [12:14] quiet splash vram=32M mem=463M root=UUID=bdee5e48-a61b-492f-a060-6b8d1afe4364 fixrtc [12:14] ... [12:14] hmm, there should be a ro too [12:14] weird [12:14] Still no console on the monitor [12:14] oh, the image used an older jasper [12:16] SIGH !!! [12:16] now glib is in the archive and the image builds fail on empathy [12:16] * ogra wishes the desktop team would stop uploading .... our desktop is fine as it is, damned ! [12:17] j/k [12:23] ogra: I would say "rebuild it on your fast arm" but it suck on i/o... [12:23] i guess USB would be fast [12:23] but that wont get me the package into the archive faster [12:23] its the publisher i'm waiting for === amitk-afk is now known as amitk [13:12] morning [13:20] ogra: nice you were able to boot panda :-) [13:21] ogra: how is it now? still giving lots of seg faults? [13:21] yup, its running fine, i only wish i could build images with the fixes now [13:23] ogra: :-) [13:23] new issues everyday haha [13:23] heh, yeah [13:23] people sadly upload packages ... [13:28] hey robclark|panda :) [13:29] gm ogra_panda [13:29] * ogra_panda hands robclark|panda some bamboo [13:29] yum yum [13:29] :) [13:30] * robclark|panda just got around to re-configuring pidgin on panda after nuking his home directory.. [13:30] * ogra_panda is using xchat [13:31] pidgin is at least relatively easy to get working behind proxy [13:32] might be, i never tried xchat behind proxy :) [13:32] i just find it painful to use IM clients for IRc [13:32] yeah.. pidgin isnt really my favorite [13:34] robclark|panda: irssi works well behind the proxy :) [13:35] hmm.. ok.. something to try [13:43] xchat works fine behind a proxy, that's how I always use it [13:43] hence my lack of a hostmask :p [13:59] ha ! [13:59] finally an image build that doesnt die [14:01] so in 2-3h we should have a panda image thats actually usable [14:21] IT WORKS! [14:22] lag: syslink? [14:22] lool: That's old news - that worked yesterday [14:22] :) [14:22] My monitor - w/Panda [14:22] erf [14:23] Equine Rescue France? [14:29] lag: what helped? [14:30] I'm now running the release (CD) image [14:30] I still don't know what the matter was with the other one? [14:30] Perhaps the rootfs was incorrect? [14:38] ogra_panda, ogra_cmpc, ogra: How long did your Panda image take to come up? [14:39] Mine has been sat at the "will take approx 10mins" screen for about 15mins [14:39] Then it just went off [14:42] sebjan: Ping === rgreening_ is now known as rgreening === rgreening is now known as rgreening_ === rgreening_ is now known as rgreening [15:16] ogra? [15:17] npitre, do you have any idea why Kirkwood keeps PCIBIOS_MIN_IO as 0x1000 and PCIBIOS_MIN_MEM as 0x01000000? [15:19] ericm|ubuntu: no idea -- probably Lennert would know [15:20] * GrueMaster yawns, stretches, and looks for coffee. [15:20] npitre, ok - I'll drop him an email [15:20] GrueMaster, wakeup from hibernation? [15:20] Something likethat. [15:20] * GrueMaster needs a new keyboard. [15:21] ukleinek: would you mind removing that only patch of yours I object to from your Git tree, add the latest ACKs and send RMK a pull request? [15:22] ukleinek: I think that stuff might be ready for mainline [15:22] npitre: no, I can. My only concern is that the uImage target is broken then [15:22] Ok, I have video on my panda working now using a HDMI>DVI cable to a pc monitor. It is in the HDMI port. I am also using the following kernel parameters: [15:22] omapdss.hdmimode=0 omapdss.hdmicode=35 [15:24] GrueMaster: My board worked HDMI->HDMI once [15:24] Then on reboot - nothing [15:24] Then I re-flashed the SD card with the same image and rebooted [15:24] Still nothing [15:25] Try also adding console=ttyO2,115200 console=tty0. That way you can see what is happening in the kernel. [15:26] It's not my cmdline - this is fresh from the CD archive [15:26] lag, his a key, thats DPMS :) [15:26] *hit even [15:26] ? [15:27] GrueMaster, wait for the new image that has a less buggy kernel that doesnt hang all the time [15:27] Mine has been sat at the "will take approx 10mins" screen for about 15mins [15:27] Then it just went off [15:27] I tried that [15:27] Some issues I ran into yesterday included not being able to use my HDMI switchbox with panda (sad face), sometimes losing keyboard input, but not mouse (I have a keyboard with built in touchpad), and occasional system hangs. [15:27] But nothing [15:27] oh, you mean after reboot ? [15:27] I don't even know if my keyboard is compatible [15:27] Yeah [15:27] yeah, thats a known bug with the old images [15:27] wait for 20100707 [15:28] * GrueMaster goes to see if coffee is ready. brb [15:28] I even flashed the card again, but nothing! [15:28] that has a fix for it [15:28] hmm, if you freshly flashed the card it should work indeed [15:28] Correct [15:28] though i wouldnt trus that kernel at all [15:29] the new image should be up in about 1.5h [15:29] Okay, I guess it's worth waiting for [15:30] Is it a kernel bug? [15:30] well, display should still work [15:30] but the kernel throws random segfaults [15:31] so it can die at any point [15:31] i had to do five attempts until resizing worked yesterday [15:31] because it locked up hard in the middle every time [15:31] ukleinek: we'll need to not use the dynamic phys offset (which is off by default) until mkimage/u-boot is fixed, so that shouldn't prevent this stuff from being merged [15:31] lag: pong [15:32] ukleinek: could mkimage simply be used without any load addr? [15:32] Hey sebjan [15:32] Where you in a meeting with Nicolas? [15:33] lag: yes, why? :) [15:33] npitre, 0x0 should work [15:33] Because you both came back at the same time :) [15:33] I was wondering what the verdict was with regards to my patch? [15:42] npitre: no, passing a loadaddr is obligatory [15:44] lag: I would expect some experts reviewers to provide comments. Fyi, I will take your current patch for internal usage, and then update to whatever it ends-up after review. [15:45] No problem [15:45] npitre: pull request sent [15:53] ukleinek: can this limitation be fixed? [15:53] npitre: I didn't touch U-Boot for some time. I think they have a new image format, but I don't know the details [15:54] ukleinek: something like a loadaddr of -1 meaning that it has to be provided at load time or the like [15:54] IIRC U-Boot can boot zImages, too [15:54] Barebox can, too [15:55] ukleinek: last time I booted zImage with uboot, the ATAG block wasn't set up [15:55] ukleinek: nor the r1 machine ID [15:57] npitre: barebox does it right, don't know about U-Boot for sure [16:10] ogra: I see uboot-envtools and uboot-mkimage packages in the archive. Where is the u-boot source? [16:10] u-boot-omap3/4 [16:11] i dont know why debian chose to use no dash [16:11] upstream clearly does [16:12] ogra: in lucid? [16:12] only omap3 there [16:12] ogra: don't see any u-boot-omap3 [16:13] * amitk checks deb-src lines [16:13] amitk, https://edge.launchpad.net/ubuntu/lucid/+source/u-boot-omap3 [16:40] GrueMaster, lag, http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100707/ [16:40] happy playing [16:40] yea, I'm seeing them come in. [16:41] i think we should disable zsync generation [16:41] swap it for MD5sums. :P [16:41] it gives a flase impression that users would gain anything by using it [16:41] GrueMaster, assigned to NCommander === amitk is now known as amitk-afk [16:41] dont blame me :) [16:41] I know. I was kidding. [16:42] ogra: GrueMaster: its sad that we can't use it, bu tI'll look at it once my headache subsides [16:42] Will the omap one work for XM? [16:42] lag, you could try it with a different u-boot binary [16:42] lag, if you find one that works [16:42] Well I have booted the XM [16:42] beyond that it should work [16:42] So I do have one [16:43] When will it work out-of-the-box? [16:43] oh, then *your* XM might even work with that image :) [16:43] mine doesnt [16:43] kernel surely is supposed to work and beyond that there should be no difference in userspace [16:44] feel free to try it :) [16:44] Are we doing a single image now or is the omap4 image still churning? [16:45] i see both [16:45] * ogra reloads [16:45] still [16:46] Can someone point me to a list of hdmi modes? [16:46] 35 is out of range on my monitor [16:46] 35 is 1280x1024 [16:46] i think there are some in the omap4 dss driver code [16:46] beyond that, I don't know. [16:47] This is odd [16:47] Booted with 35 "out of range" [16:47] the panda ? [16:47] Yeah [16:48] oh, i forgot, it doesnt like your EDID [16:48] But it's working [16:48] With my own kernel [16:48] But only with 35 [16:48] 11 doesn't even come up === hrw is now known as hrw|gone [19:17] * zumbi sends armin76's dog to eat all the germans arround :) === fta_ is now known as fta === fta_ is now known as fta [21:09] ogra: Hey there [21:09] ogra: Do you know if the A2 kernels work on Beagleboard XMs? === fta__ is now known as fta === bjf is now known as bjf[afk] === rsalveti` is now known as rsalveti