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