[00:00] GrueMaster: not sure which kernel you are on.. but one obvious thing to sanity check... some recent defconfig from kernel-omap4.git had VRAM defaulting to zero.. so if you didn't give some bootargs you wouldn't get any framebuffers [00:00] you could try something along lines of: vram=8M omapfb.vram=0:8M [00:00] (for example) [00:01] robclark: I'm using the same bootargs as I was for 2.6.34. vram=12M omapfb.mode=dvi:1280x720MR-16@60. And this is on the beagleboard (omap3). [00:01] ahh.. ok.. that should be not the issue then [00:02] This is kernel 2.6.35-6. It is scheduled to hit the pools on Friday. [00:03] do you even get the penguin at bootup? Or nothing at all on dvi? [00:03] Nothing on dvi. See my error post a few lines back. [00:04] rebooting to 2.6.34 kernel is fine. [00:06] hmm, is kernel config not enabling any DSS devices? [00:07] I think it does not go thru this loop at all: for_each_dss_dev(dssdev) { ... } [00:08] make menuconfig, and then Drivers -> Graphics -> OMAP2/3/4... -> and then hopefully there is some DVI option [00:10] Not sure. Let me check the output against 2.6.34 [00:30] Maybe it has something to do with "# CONFIG_OMAP2_DSS_RFBI is not set"? I haven't tweaked the kernel in several years (since 2.4.xx times). [00:30] But I did see that in the config. [00:31] nevermind. same in 2.6.34 [00:33] Interesting. I'm reviewing my bootlogs from earlier 2.6.35 test kernels, and I am seeing the same error in 2.6.35-RC1 raw kernel (no ubuntuisms). [01:13] ogra_cmpc: What's the score? [01:14] My bamboo board was DOA [01:14] -sigh- [01:14] which one is that? [01:21] AMCC 440EP eval board? [05:07] damn it, just missed Martyn [05:35] any softkey pad application available for arm... [07:58] NCommander, so your gobject-introspection "fix" ... [07:59] ogra: yes? [07:59] NCommander, did you check the dependencies and what changed in them between 0.6.12-1 and 0.6.12-1ubuntu1 ? [07:59] ogra: dyfet did. [07:59] since this is not a gobject-introspecion issue but an issue with any build dep [08:00] i'd rather see us fixing the real issue than changing the code that didnt change before the breakage [08:00] looking at the deps i'd suspect glib [08:00] bison, flex and friends didnt change between the two uploads [08:00] ogra: we need gobject-introspection fixed, you've already said that, I'm glad to hunt for the actual cause of the breakage, but I'm happy to work around it [08:01] ogra: dyfet said he checked it [08:01] i'm not sure it wont break it on all other arches [08:01] ogra: I threw it in a PPA, built on everything [08:01] you are changing XML that hadnt changed [08:01] (devirtualized PPA) [08:01] I only changed the XML to reflect the changed vairable names in the C code [08:01] yes, but does that change work on all other arches ? [08:02] * ogra wouldnt even know how to verify that [08:02] ogra: I ran the test suite on all arches [08:02] in any case something in a dep changed, just hacking variable definitions in the gobject code doesnt seem like an appropriate fix [08:02] i'm not talking about the test suite [08:02] but about the binaries using the code [08:03] telepathy for example [08:03] ogra: I didn't change any code expect code used in the test suite [08:03] was seb128 pulled into the discussion by dyfet as i asked ? [08:03] ogra: I didn't see any communication from dyfet to seb128. I was waiting for him to show up to pin ghim on desktop [08:04] hmm, i asked dyfet a week ago at the meeting to discuss it with seb :/ [08:04] (and agin this week) === hrw|gone is now known as hrw [08:26] morning [08:41] dialpad application in ubuntu avaliable.. === ogra_ is now known as ogra === freeflyi1g is now known as freeflying === dyfet` is now known as dyfet [12:07] NCommander, do you remember the former name of the "source" commnad in old u-boot ? [12:07] seems enabling hush shell didnt get me source [12:08] ogra: TI's u-boot might predate that command being added [12:08] its 1.1.4 [12:08] Marvell was 1.3.4 [12:08] gah [12:08] thats really bad [12:08] your trying to execute the boot.scr, right? [12:08] yep [12:08] do imi *offset* where you loaded it [12:09] see if panda's u-boot recongizes it as a boot script [12:09] PANDA # imi 0x80300000 [12:09] ## Checking Image at 80300000 ... [12:09] Image Name: Ubuntu boot script [12:09] Image Type: ARM Linux Script (uncompressed) [12:09] Data Size: 163 Bytes = 0.2 kB [12:09] Load Address: 00000000 [12:09] Entry Point: 00000000 [12:09] Verifying Checksum ... OK [12:09] hrm [12:09] PANDA # [12:09] yep [12:09] possible autoscr [12:10] that might have been the old command for source [12:10] (it shouldbe in help)_ [12:10] nope [12:10] its not [12:10] (in help) [12:11] i see test and other hush commands [12:12] crap [12:12] its possible that its just not implemented [12:12] Which means we're screwed [12:13] (partially) [12:13] i see "go" but that hangs x-loader if i run it [12:13] it wouldn't be super-difficult to backport a the necessary commands [12:13] go is used for jumping to an offset [12:14] yeah [12:14] autoscr is there on blaze? [12:14] * NCommander hasn't checked [12:14] (or source) [12:15] hmm, gumstix uses 1.1.4 and has autoscr [12:16] sounds like something went horribly wrong [12:16] * NCommander grabs the source [12:29] aha ... i see (~CFG_CMD_AUTOSCRIPT... [13:00] PANDA # help [13:00] ? - alias for 'help' [13:00] autoscr - run script from memory [13:00] I WIN !!! === JaMa is now known as JaMa|Off [14:43] GrueMaster ? === sbambrough-afk is now known as sbambrough [15:22] mpoirier: pong. Still waking up, though. [15:22] GrueMaster: good morning. [15:22] your beagle board, it is a C4 ? [15:23] I assume so. [15:25] Yes. Store bought, as it were. [15:26] did you upgrade your MLO and u-boot ? [15:27] or are they stock ? [15:27] I believe I am running what is on ogra's image. [15:28] do me a favor please. [15:28] boot the board (power cycle) and give me the date you get on the very first line that come up on the screen. [15:28] mine is: [15:28] Texas Instruments X-Loader 1.4.2 (Feb 19 2009 - 12:01:24) [15:31] same [15:31] That's the xloader [15:31] yes, indeed. [15:32] [15:32] please confirm that you have used the USB EHCI on this board. [15:32] Huh? [15:32] the normal looking USB port, next to the SD card slot. [15:33] of course. That's how I have keyboard, mouse, ethernet, etc. [15:34] davidm set me a C4 two weeks ago and USB did not work off the box. [15:34] Ok I'm thinking, hw failure happens... [15:34] I'm fully hooked up here. Only thing not in use is the otg port. [15:34] and svideo. [15:34] Yes, don't use OTG. [15:34] so I purchase one from Sparkfun and got it yesterday... [15:34] it too has a problem with USB. [15:35] I'm aware of that. [15:35] that is interesting - aware of what ? [15:35] USB problems with bb ? [15:35] Bug #566645 [15:35] Launchpad bug 566645 in linux-ti-omap (Ubuntu Maverick) (and 2 other projects) "OTG configuration is broken on omap kernel (affects: 2) (heat: 64)" [High,Confirmed] https://launchpad.net/bugs/566645 [15:35] indeed, OTG is not in yet. [15:36] But both my C4 boards, USB EHCI is not responsive. [15:36] I was wondering if you were seeing the same thing... [15:36] Are you running with a powered hub? [15:36] mpoirier, two boards with fail sound funny, perhaps your USB hub is not working with the hardware? [15:37] It does work when hooked up to the C2 board... [15:37] Where are you powering your board from? [15:37] power supply, not OTG. [15:38] ok. [15:38] I'm wondering if u-boot isn't doing something special to enable the port. [15:38] Something I wouldn't have. [15:38] two failure on two boards, this isn't right. [15:39] I have my system booting the uboot from nand when I am running lucid. It is the stock uboot. When I am running maverick, it runs a newer version. Both work fine with USB. [15:40] The maverick uboot, it is on SD card ? [15:41] yes. [15:42] Please email it to me... [15:42] is there another channel for non ARM ubuntu netbook issues ? [15:43] Actually, just pull down ogra's test image. http://projects.gnome.org/NetworkManager/developers/ [15:43] rsavoye: #ubuntu-mobile [15:43] thanks [15:43] or #ubuntu-desktop may help [15:44] I was trying to get a USB install to a Sylvania G netbook to work, it can't find vesa === bjf[afk] is now known as bjf [15:49] GrueMaster, #ubuntu-mobile is dead [15:50] netbook issues go to #ubuntu-desktop or for the efl version to us [15:50] it may be dead, but there is a pile of people [15:51] yes, we're in the process of either closing it or finding a new adopter [15:51] the ubuntu mobile team doesnt exist anymore [15:52] ah... that;s right [16:14] mpoirier: if you have any kernel testing that needs to be done, just ping me and I can test in my environment. I would like to test fixes to some of these critical bugs as soon as they are available, instead of waiting for the next kernel bump. [16:14] very well. [16:16] BTW, the daisy chain fix works well, thanks & kudos. [16:16] was it just removing CPU_IDLE from the Kconfig? [16:17] this is just a big hack and shouldn't be considered to be the real thing. [16:17] removing CPU_IDLE just avoids touching the flaky code. [16:18] Sometimes it is things like this that need to be done to keep the rest of the teams moving forward while a real fix is pursued. [16:19] I have no problem with doing that either..,,. [16:19] It enables people like me to find and report new and annoying bugs. :P [16:19] but the real fix is still eluding me. [16:20] and all this time that I'm not fixing other problems... [16:20] mpoirier, ask koen in #beagle, probably he knows about it and has a patch [16:20] he is a great source of information if it comes to kernel issues with omap :) [16:20] ogra: you seems to know something I don't... [16:21] lag, what was your trick to make HDMI or DVI work on omap4 ? [16:21] push it in harder? [16:21] * ogra remembers you talked about that a while ago [16:21] It doesn't [16:21] It doesn't ? [16:21] It doesn't work [16:22] FBAR [16:22] neither of the ports ? [16:22] Neither [16:23] DVI isn't meant to work [16:23] robclark, didnt you say there was a trick to make HDMI/DVI work on the panda ? [16:23] HDMI just doesn't [16:23] There was a hack to make it work with HDMI/DVI converter [16:23] But I haven't tried that, as I don't have the cable [16:24] lag: you hdmi isn't working? [16:24] Correct [16:24] lag: which kernel release are you using? [16:24] lag: L24.7 ? [16:24] real men use serial [16:24] armin76: hehe indeed [16:25] prpplague: gimme omap4! [16:25] prpplague, we're all using the ubuntu kernel [16:25] Serial works like a peach [16:25] prpplague, which should be based on something newer than L24.7 afaik [16:25] lag, serial doesnt help with images :) [16:25] ogra: I'm not sure if DVI is up yet.. HDMI works well (at least on the monitor that I have) [16:26] for L24.7 kernel, you need some bootargs so you have more than 0MB for framebuffer.. [16:26] the HDMI inteface can be used with a DVI monitor with no problems [16:26] yup [16:26] * armin76 tests :D [16:26] fyi: vram=8M omapfb.vram=0:8M [16:26] thats all ? no resolution ? [16:26] lag: most likely you need to allocate some mem for the framebuffer per robclark 's suggestion [16:26] * ogra tries [16:26] ogra: for hdmi it will autodetect the best resolution [16:27] sweet ! [16:27] ogra: for dvi you will need to specify the mode and resolution [16:27] yeah [16:27] Sounds good [16:27] my monitor has both [16:27] lag: if you are using the hdmi but with a dvi monitor your will need to specific some additional bootargs [16:28] I'm not [16:28] I'm using real HDMI [16:28] Once my kernel is up again, I'll try those extra args [16:28] :) [16:29] lag: ahh ok [16:29] Could that be the source of the "SYNC_LOST_DIGIT" messages I receive? [16:29] They swap my system rendering it unusable [16:29] but 592295 [16:29] Doh! [16:29] bug 592295 [16:29] Launchpad bug 592295 in linux-ti-omap (Ubuntu) "omapdss DISPC error: SYNC_LOST_DIGIT (affects: 1) (heat: 8)" [Medium,Confirmed] https://launchpad.net/bugs/592295 [16:30] omapfb omapfb: failed to allocate framebuffer [16:30] omapfb omapfb: failed to allocate fbmem [16:30] omapfb omapfb: failed to setup omapfb [16:30] omapfb: probe of omapfb failed with error -12 [16:30] hmm [16:31] ogra: someone was seeing that yesterday [16:31] Can you post your .config? [16:31] and i see the SYNC_LOST_DIGIT message too at the end of the boot [16:31] robclark: i was about to ask the same [16:31] ogra: One is fine [16:31] It's expected [16:31] 10,000 is not [16:31] From looking at code, I think that error comes if the kernel is somehow built w/o any DSS drivers enabled.. [16:33] robclark, http://pastebin.com/HeBHjaAS [16:35] ogra: hmm.. that looks somewhat ok.. CONFIG_OMAP2_DSS_HDMI=y [16:35] hmm [16:36] the monitor is definately initialized but i dont see any output [16:36] ogra: do cat /dev/urandom > /dev/fb0 [16:37] i have no shell atm [16:37] ogra: oh [16:37] actually, ogra, I think your error is different from one yesterday. [16:37] ogra: why not? [16:37] ogra: How many messages do you get? [16:37] try change CONFIG_OMAP2_VRAM_SIZE=4 to CONFIG_OMAP2_VRAM_SIZE=8 [16:37] lag, only one [16:37] That's fine then [16:37] No problem [16:38] 4mb is not sufficient for 1920x1080x4byte/pixel [16:38] prpplague, because i dont have a rootfs atm :) [16:38] oh [16:38] /* When we enable digit output, we'll get an extra digit [16:38] * sync lost interrupt, that we need to ignore */ [16:38] robclark, so it reads the EDID of my monitor and automatically takes the highest res. it finds ? [16:38] ogra: so how are suppose to know if the hdmi is working? [16:38] ogra: correct [16:38] prpplague, kernel messages on tty0 [16:39] first frame as it takes long time to decode but it later recovers*/ [16:39] * lag tries again [16:39] first frame as it takes long time to decode but it later recovers*/ [16:39] Grr [16:39] ogra: you are trying to run the hdmi as the console? [16:39] ogra.. yeah.. but it should reduce the framebuffer size if it doesn't have enough mem.. [16:39] first frame as it takes long time to decode but it later recovers*/ [16:39] prpplague, indeed [16:39] ahh [16:39] so you should see some resolution like 1920x540 [16:40] first frame as it takes long time to decode but it later recovers*/ [16:40] but maybe after some limit it gives up at trying to resize the framebuffer [16:40] /*commenting below code as with 1080P Decode we see a sync lost digit for [16:40] first frame as it takes long time to decode but it later recovers*/ [16:40] Got it [16:40] Stupid leading / [16:40] robclark, hmm, my monitor might not do such odd resolutions in HDMI mode [16:40] hmm, ok.. that could be the issue I suppose [16:41] ogra: can you pastebin your bootlog? [16:41] if i boot with serial console i can grab it, yes [16:41] one sedc [16:41] *sec [16:42] http://paste.ubuntu.com/454514/ [16:42] * prpplague looks [16:45] ogra: edit your .config file, turn off DSI and set the number of framebuffers to 1 [16:46] ogra: also turn on the omap2 fb debug support [16:46] well, i wont compile any kernels now :) [16:46] * ogra is busy working on images, but i'll file a bug for the kernel team to fix it [16:47] ogra: oh [16:47] ogra: is the kernel source for what you are using available somewhere? [16:47] i usually dont touch kernels if i can avoid :) [16:48] ogra: ahh [16:48] https://edge.launchpad.net/ubuntu/maverick/+source/linux-ti-omap4/2.6.34-900.1 [16:48] * prpplague looks [16:48] cooloney maintains it, lag gives him a hand [16:48] * prpplague downloads and builds [16:49] * prpplague needs a brake from the mailing list flame wars [16:49] heh [16:50] jkridner1: morning [16:50] ogra: i'll have a look at the build and test [16:51] thanks [16:52] hi prpplague [16:53] hrw: greetings [16:55] ogra: why mem=463M? [16:55] hrw, thats in the u-boot defaults, i just kept them [16:55] hrw: the blaze/sdp team were using that value, i never did get an answer for why [16:56] prpplague: i thought it was for legacy reasons, to set memory aside for dspbridge crap? [16:56] I ran our machines just fine without mem= on the bootargs [16:56] ojn: ahh, that might be true [16:56] prpplague: maybe they had problem with second 512M? [16:57] hrw: the blaze/sdp doesn't have a second 512M [16:57] thats why [16:57] no [16:57] u-boot passes the amount of memory in the proper atags, no need for bootargs. [16:58] well, its in the panda u-boot defaults [16:58] we had 1GB working too (well, 768MB, highmem support was busted back when I tried it last). [16:58] ogra: Should be bug reported, probably. [16:58] but i'll remove it in the ubuntu package if its not needed [16:58] well, in ubuntu we use boot.scr everywhere to set bootargs so i dont really care [16:58] ojn: on which platform? [16:59] prpplague: custom boards [16:59] (4430-based) [16:59] prpplague and all: 463M is the value for 512M boards.. some memory needs to be reserved for coprocessors [17:00] in future, syslink will reserve this at boot time using normal kernel memory allocation APIs.. [17:00] but that isn't implemented yet [17:01] robclark: ahh dandy [17:03] btw, is there already u-boot/x-load patches for 1gb panda? [17:05] GrueMaster: where do I get ogra's test image ? The one you are testing with. [17:05] mpoirier, people.canonical.com/~ogra/jasper/ [17:06] mpoirier, note that updating the kernel doesnt work automatically yet [17:06] and that it uses .34 still [17:06] ah.. toys [17:06] i'm only interested in the u-boot. [17:06] robclark: no not yet [17:06] will I find it in there ? [17:06] Oops. Sorry about that. wrong link in the copy buffer for some reason. [17:06] ogra: kernel building now [17:07] Use ogra's link. There are only two files there. [17:07] mpoirier, uboot is in the image [17:08] ogra: ok thanks. [17:09] mpoirier: You can mount the boot partition with sudo mount cmdline-maverick-armel+omap3.img mnt/ -o loop,offset=$((32256)) [17:09] Saves time from having to write the image to SD. [17:09] I would have just mounted the image. === hrw is now known as hrw|gone [17:13] have a nice rest of day [17:14] mpoirier, oh, i mis-read above, you want u-boot ? [17:14] I just need uboot. [17:15] https://edge.launchpad.net/ubuntu/+source/u-boot-omap3/2010.3git20100531-0ubuntu1/+build/1767190 [17:15] just dpkg -x the .deb [17:16] ogra; thanks. [17:16] ogra: the cmdline-maverick-armel+omap3.img image, what format is it ? [17:17] It is a SD image. 2 partitions. [17:17] its a two partition img to dd to the SD card [17:17] yes, but if I want to mount it live on my file system... [17:17] a simple mount -o loop fails. [17:17] using "file" on the image yields: x86 boot sector; partition 1: ID=0xc, active, starthead 1, startsector 63, 144522 sectors; partition 2: ID=0x83, starthead 0, startsector 144585, 867510 sectors, code offset 0x0 [17:18] haven't seen that before. [17:18] Then you need to find the starting byte of each partition (parted will give you this) and mount with -o loop,offset=. [17:18] ogra: definetly some weirdness going on with that kernel soruce === bjf is now known as bjf[afk] [17:18] ogra: ok. [17:18] prpplague, well, its an ubuntu kernel with the TI patches on top [17:18] * prpplague digging into it [17:18] prpplague, afaik sebjan maintains it on the TI side [17:18] mpoirier: I'll send you a link on how to do this. [17:19] http://wiki.edseek.com/guide:mount_loopback [17:20] GrueMaster: I just got it with the offset command you sent me above. [17:20] I get it now. [17:22] ogra: interesting, straight out of the box with the defconfig, the kernel fails to compile [17:23] indeed [17:23] you need to build it like a debian package [17:23] it runs various scripts to assemble the different config snippets [17:24] hi prpplague. I should free up here shortly and can swing by if you let me know where you are at. still don't have the LCD. :( [17:24] huh? you don't use the defconfigs? [17:24] prpplague, no [17:24] jkridner1: E-2126 , just down from geralds office [17:24] hmm [17:25] prpplague, there is an ubuntu (non arch specific) config and there is an arch specific one [17:25] must be somewere in the debian dir, i guess soemone from the kernel team can explain it better than me [17:26] to build it you definately need to run "fakeroot debian/rules " [17:26] ogra: i'll dig around and see what i can find [17:26] debian/rules is the makefile [17:26] ogra: guess we need to know how to test the ubuntu kernels [17:26] prpplague, we'll soon have daily images [17:26] so you can just install the image and regulary upgrade the kernel [17:27] ogra: well i don't like not knowing, i just assumed ubuntu built the kernel just like the rest of the world, hehe [17:27] ogra: i mainly do kernel dev [17:27] it builds it slightly similar to debian [17:27] ogra: so i need to be able to hack [17:28] well, the kernel team maintains it in a git tree like any other kernel dev does :) [17:28] just the build process is different since its wrapped in packaging stuff [17:29] i'm sure there is a doc somewhere that describes the process [17:30] right [17:32] prpplague, https://help.ubuntu.com/community/Kernel/Compile i think [17:32] * prpplague looks [17:33] "Build the kernel (when source is from git repository, or from apt-get source)" [17:33] thats the section you want [17:34] yea, reading over that now [17:34] you need beefy hardware though (we do not cross compile) [17:35] yea looks there are some "multi-boot" issues [17:35] testing [17:38] ok, here is the bit [17:38] ogra: they have the DPI picodlp enabled in the config [17:38] ouch [17:39] probably a blaze leftover [17:39] lag, ^^^ [17:39] ogra: so if you have that enabled along with the HDMI, you need to change the number of framebuffers to 2 instead of 1, and in addition you need to allocate enough memory for both, 16 is probably enough, but a safe value is 32 [17:40] lag, can you take care that cooloney gets that info ? [17:42] GrueMaster: moving to ogra's u-boot fixed my USB EHCI issue - thanks. [17:42] great :) [17:46] * prpplague retests with the common config [17:47] mpoirier, both boards are working now? [17:47] interesting. [17:48] Must be a u-boot<>kernel combination issue. I haven't tried the new kernels on the old system. [17:54] davidm [17:55] good lord that common image is giant === bjf[afk] is now known as bjf [17:57] davidm: both boards are working now. [18:01] ogra: yea looks like the same issue with the common config, they have 3 different dss drivers enabled, DSI, DPI and HDMI, but only have 2 framebuffers allocated [18:02] ogra: easiest is to just use 32MB for the framebuffers, that should work fine === JaMa|Off is now known as JaMa [18:05] prpplague: we want to have a single kernel image/defconfig for both blaze and panda, so we need to have picodlp activated, right? Are there changes to apply to the config according to you? [18:06] sebjan: assuming i am using the right config per the instructions, the vram needs to be increased to a min of 16, preferable to 32 [18:07] well, we have enough ram, 32 should be doable [18:08] ... and in case we want to use the serial only ;), we can force a lower value in command line then, right? [18:09] no idea if there is a cmdline override :) [18:10] sebjan: correct [18:10] does the vram value override the kernel default ? [18:11] ogra_cmpc: on the command line it does [18:11] sebjan: i emailed you the config i am using [18:12] ah, great, so you only need to change boot.scr [18:14] prpplague: great thanks, I'll take this change [18:24] sebjan: np === bjf is now known as bjf[afk]