[01:11] <rsalveti> rcn-ee: on-line?
[01:11] <rsalveti> about beagle xm
[01:33] <rsavoye> rcn-ee: back from vacation ?
[02:50] <rcn-ee> hey rsavoye back.. ;) power lines went..
[02:50] <rsavoye> everybody wants XM fixes. :-)
[02:51] <rsavoye> TI is sending me another XM board, hopefully without the RAM problem, so real soon I'll be ready for more testing. :-)
[02:51] <rcn-ee> i bet they do.. ;)  Fingers crossed on getting one on monday. .;)
[02:56] <rsavoye> I'll send you my flakey one:-)
[02:57] <rcn-ee> that's okay i got a good collection of broken beagles. ;)
[02:57] <rsavoye> also got an iMX51 coming tomorrow.
[02:58] <rsavoye> Genesis is giving them to developers, if you don't have one yet
[02:58] <rcn-ee> i was playing around with an imx51 based system last month, someone needs to take that git tree by the hornes and fix it.. i know freescale wont'..
[02:58] <rsavoye> hope you had a few good days off
[02:59] <rsavoye> so I assume Maverick won't run on it, but it ships with a hacked up lucid
[02:59] <rcn-ee> oh, i've just been busy this week... ;) lots of testing the gpio stuff to finally fix the 'ro' issues in 2.6.35.. going to post v6 to linux-omap later..
[03:03] <rsalveti> rcn-ee: I'm building with my custom v6 version now to test on my xM
[03:03] <rsalveti> didn't test my xM yet :-)
[03:04] <rsalveti> http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-maverick.git;a=shortlog;h=refs/heads/rsalveti-master
[03:04] <rsalveti> it's just finishing the build, takes quite a while =\
[03:04] <rcn-ee> yeah, about 6 hours. .;)
[03:05] <rcn-ee> i'm about 95% sure that one will get pulled and put in tmind's tree. ;)
[03:05] <rsavoye> I've got an OpenJDK test that's been running for 4 days... and still not done
[03:05] <rsalveti> ouch
[03:06] <rsavoye> it's my third try to even see if if actually finishes...
[03:08] <Martyn> Hey there Rob :)
[03:08] <rcn-ee> rsavoye, is that on a c4 or igepv2?
[03:08] <rcn-ee> hey Martyn how's it going..  Still fun stuff happening at smoothstone. ;)
[03:08]  * Martyn has a CortexA9 compile farm now :)
[03:08] <Martyn> smooth-stone, yeah :)
[03:08] <rsavoye> a babbage board sitting in a closet in Sweden someplace
[03:08] <Martyn> (the - is important, we're even being SUED over it.. sheesh)
[03:09] <rcn-ee> ah crap...  someone wants to stop innovation and forward progres...
[03:09] <Martyn> rsavoye : if you give me a git tree to pull from, I can do a clone and compile it...
[03:09] <rsavoye> that's what I want. distcc on a rack of arms
[03:09] <Martyn> rsavoye : Not quite a "rack" of em, but we do have a lot of Versatile Express hardware
[03:10] <rsavoye> Martyn: for OpenJDK ?
[03:10] <Martyn> and other CortexA9 boards
[03:10] <rsavoye> any remote access :-)
[03:10] <Martyn> oh, I thought you were doing kernel compiles :)
[03:10] <Martyn> rsavoye : No :)  That firewall is airgap.
[03:10] <rsavoye> no, testing rcn-ee's kernel builds on an XM
[03:11] <rsavoye> right now I'm deep in fixing the ARM assembler for OpenJDK, but running the tests is slow
[03:11] <Martyn> I bet
[03:11] <Martyn> Shark is very bad at the moment
[03:11] <rsavoye> but I'd bet rcn-ee would love a faster build
[03:11] <rsavoye> I'm not using shark yet, just fixing the real arm interpreter after a calling convention change broke it a few months ago
[03:12] <rcn-ee> i could.. ;) i finally up'd my main kernel build machine from the 500Mhzish to 600.. ;)
[03:13] <Martyn> Heh
[03:13] <Martyn> I'm clocking around the same (800Mhz) but on a quad core machine
[03:13] <Martyn> and with more of 'em
[03:13] <rcn-ee> it's a little scary in the basement right now.. i need to find room to install my tegra and panda. ;)
[03:13] <Martyn> tegra = ok
[03:13] <Martyn> panda = *shudder*
[03:13] <Martyn> bamboo is a strange creature of a board
[03:14] <rcn-ee> it's a little strange.. ;)
[03:16] <rcn-ee> rsavoye, is your openjdk testing scripted and automated?
[03:16] <rsavoye> yes, "make check" :-)
[03:17] <Martyn> lol
[03:18] <rsavoye> so I'm running the tests on one board in NZ, and gdb on the other one
[03:19] <Martyn> sheesh
[03:19] <rsavoye> hopefully I'll get some hardware in here soon that actually works so I stop begging for remote access
[03:19] <rcn-ee> i think we need to pull kblin in again, he's had some grand schemes of an arm mulitnode build/etc machine. ;)
[03:19] <Martyn> Indeed
[03:20] <Martyn> rsavoye : I'm surprised you need to remote that far to get access to the hardware
[03:20] <rsavoye> there don
[03:20] <rsavoye> 't seem to be many of us here in the US...
[03:21] <rcn-ee> i think there's almost a dozen.. ;)
[03:21] <rsavoye> oh right, you're on this side of the big puddle too
[03:22] <rcn-ee> yeah i just get up early so it looks like i'm europe.. ;)
[03:23] <rsavoye> me too, I like my few hours of intersection with the OpenJDK team in the UK
[03:24] <rcn-ee> and sometimes it's the only way to get things done, otherwise your chasing emails over the next day..
[03:25] <rsavoye> in my case it's useful, as they understand java, and I don't. course they don't know assembler, so we have interesting discussions :-)
[03:25] <rsalveti> interesting :-)
[03:26] <rsavoye> lately we connect someplace in the middle, which works
[03:26] <rsavoye> talking to java guys about assembler is pretty funny though.
[03:27] <rcn-ee> in the back of my mind i've always kinda wondered, does openjdk use the ARM_THUMBEE stuff?
[03:29] <rsavoye> it will when I'm done :-)
[03:29] <rsavoye> after I fix the calling  convention, then comes all the new thumb2 stuff
[03:29] <rsavoye> I have a huge patch for that luckily, but it'll need debugging
[03:30] <rcn-ee> cool! ;)
[03:30] <rsavoye> the point of this is to make java run as fast as possible
[03:31] <rcn-ee> and those builtin java instructions will defintelly help that.. i always thought it was weird the old java instructions in the arm9/etc where so closed..
[03:39] <rcn-ee> okay send v6... i really hope no more changes are needed.. ;)
[06:06] <rsalveti> hm, lots of crashes with my xm =\
[06:06] <rsalveti> probably the memory issue
[06:06] <rcn-ee> but no read only.. ;)
[06:07] <rsalveti> hahah, true :-)
[06:07] <rsalveti> does it work better if I limit the memory at the cmdline?
[06:08] <rcn-ee> umm, i've never tried doing that...
[06:10] <rcn-ee> in your bootarg try half.. "mem=256M"
[06:10] <rsalveti> yeah, that's what I'm trying now
[06:11] <rsalveti> weird, sometimes the kernel does boot
[06:11] <rsalveti> other doesn't even shows the boot log
[06:11] <rsalveti> other some random seg faults haha :-)
[06:11] <rsalveti> memory issues are awesome
[06:11] <rcn-ee> yeah they are a pain...
[06:15] <rsalveti> ok, now just some cool warnings that were happening all the time
[06:16] <rsalveti> [    0.000000] WARNING: at /home/ubuntu/kernel/ubuntu-maverick/arch/arm/mach-omap2/clkt_clksel.c:375 omap2_init_clksel_parent+0xf4/0xf8()
[06:16] <rsalveti> [    0.000000] WARNING: at /home/ubuntu/kernel/ubuntu-maverick/arch/arm/mach-omap2/clkt_clksel.c:194 omap2_clksel_recalc+0xcc/0xf0()
[06:16] <rsalveti> [    0.000000]  (null): no physical address for uart#3, so skipping early_init...
[06:16] <rsalveti> [    0.000000] WARNING: at /home/ubuntu/kernel/ubuntu-maverick/arch/arm/mach-omap2/serial.c:727 omap_serial_init_port+0x88/0x1f8()
[06:16] <rsalveti> probably some missing patches all around
[06:17] <rcn-ee> yeap, the uart#3 stuff isn't in 2.6.36-rc1 either..
[06:19] <rsalveti> rcn-ee: do you know if they are somewhere at least?
[06:19] <rsalveti> or it's something we should fix
[06:20] <rsalveti> rcn-ee: it seems that it does works fine with mem=256M
[06:20] <rcn-ee> cool... stress it fully at that setting.. some of the ideas going around, was the chip select that split the 512 in two halves wasn't correctly working..
[06:21] <rsalveti> yep, that would make sense
[06:23] <rcn-ee> this was the original uart3 fix, it didn't get merged.. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg24695.html  for 2.6.36-rc1 the usart changed alot so it needs to be tweaked..
[06:24] <rsalveti> cool, some work for the weekend
[06:24] <rsalveti> :-)
[06:27] <rsalveti> rcn-ee: does your xM works with usb and ethernet?
[06:28] <rsalveti> hm, seems to work now :-)
[06:28] <rcn-ee> yeap, both usb's (otg/ehci), usb Ethernet, hdmi, serial work...  it runs till in run aptitude.. ;)
[06:29] <rsalveti> cool :-)
[06:51] <rsalveti> GrueMaster: sent you an email, about x-loader and u-boot for es2
[06:51] <rsalveti> you can find them at http://people.canonical.com/~rsalveti/maverick/boot/es2/
[07:03] <kblin> morning folks
[07:09] <rsalveti> night! :-)
[07:22] <DanaG> Say, I see we're now getting some stuff marked Linaro.
[07:22] <DanaG> I get that Linaro is some consortium that includes Canonical, but what does that DO for us?
[07:32] <DanaG> Say, and what does "flash-kernel" do on XM?  There's no Flash... does it do SD instead?
[07:38] <DanaG> https://bugs.launchpad.net/ubuntu/+source/flash-kernel/+bug/365053
[07:38] <ubot2> Launchpad bug 365053 in initramfs-tools (Ubuntu) (and 1 other project) "On armel (Babbage platform), kernel image upgrading breaks if Ubiquity is instructed not to install a bootloader (affects: 1) (heat: 19)" [Medium,Triaged]
[07:42] <sid> hello
[07:43] <sid> anybody there
[07:43] <DanaG> Flash-kernel is also trying: Erasing Kernel NAND space... + dd if=/dev/zero of=/dev/mtdblock3 bs=4194304 count=1
[07:43] <andrew_708476> Is there someone that know a little about Ubuntu that can help me
 : hi i dont know much of ubuntu but i can help you
[07:44] <andrew_708476> ok cool
[07:45] <andrew_708476> you know how with Ubuntu firefox comes with it well on firefox I have lost my web browser and can you help me get it back
[07:49] <DanaG> hmm, ubuntu kernel fails on beagleboard: http://pastebin.com/WTjJgxgm
[07:52] <andrew_708476> does anyone know anything about Ubuntu that wont mind giving someone a hand
[07:52] <DanaG> GO in #ubuntu -- this channel is for ARM-specific stuff.
[07:53] <sid> <andrew_708476: ok try to install new firefox browser use following command sudo apt-get install firefox
[07:54] <andrew_708476> thanks
[07:54] <sid> i want to create ubuntu image for arm tell me the exact procedure
[07:54] <andrew_708476> can I add you and chat to you again
[07:54] <sid> ya sure
[07:55] <sid> my id siddharth.waikar3@gmail.com
[07:55] <sid> send me request
[07:55] <andrew_708476> thanks I need to unstall firefox first do you know how to do that
[07:56] <andrew_708476> in Ubuntu
[07:56] <sid> ok run command sudo apt-get remove firefox
[07:59] <andrew_708476> its gone
[07:59] <sid> ok now run previous command
[08:00] <andrew_708476> I have to restart be back in a minute
[08:00] <sid> no not required
[08:00] <andrew_708476> ok
[08:01] <andrew_708476> its installing it again
[08:41] <cooloney> ogra: morning, oli, did you guys tested latest daily build omap4 image.
[08:41] <cooloney> it looks like it stops at booting
[09:00] <DanaG> Now if only we could get PowerVR drivers in the repos as nicely as fglrx and nvidia... and if only the danged things had GLX, and not just ES.
[09:01] <ogra> cooloney, yes, we're trying to find out why oem-config doesnt come up since a week
[09:01] <ogra> cooloney, i assume it stops at the X wallpaper ?
[09:03] <cooloney> ogra: oh, no, it stops at just enabled the AppArmor
[09:03] <ogra> after the automatic reboot it does ?
[09:14] <cooloney> let me post you an image
[09:14] <cooloney> ogra: http://people.canonical.com/~roc/IMG_20100820_160409.jpg
[09:14] <ogra> hmm, seems it doesnt reboot
[09:15] <ogra> it should actually reboot at the point where it does the "reboot check" line
[09:15] <ogra> smells like a kernel regression
[09:16] <ogra> GrueMaster, on an up to date panda image, if you call sudo reboot on cmdline, does it do the right thing ?
[09:16] <GrueMaster> I haven't had a chance to get to a cmdline post-update.  System hangs.
[09:17] <cooloney> ogra: did the latest 903.7 kernel work before?
[09:17] <GrueMaster> Same as cooloney.
[09:17] <cooloney> ogra: i didn't try daily build for sometime,
[09:17] <ogra> GrueMaster, hmm, i thought you had a way to at least get a console
[09:17] <GrueMaster> cooloney: The kernel appears fine.  There is something else that appears to be hanging the system.
[09:18] <ogra> GrueMaster, the kernel doesnt seem to work fine if the reboot command cant execute
[09:19] <GrueMaster> ogra: I am running the current kernel now.  And yes, reboot works fine.
[09:19] <GrueMaster> I reboot in between package updates.
[09:19] <ogra> weird
[09:20] <ogra> why doesnt it work from initramfs then
[09:25] <DanaG> argh, es2gears won't run on the powervr.
[09:41] <ogra> hmm, so i downgraded upstart and dbus now, still hangs hard if i start p the system bus
[09:41] <ogra> *up
[09:49] <cooloney> ogra: A3 image works fine.
[09:49] <ogra> cooloney, yes, we know, can you give me the /var/log/jasper.log file from your broken test ?
[09:54] <cooloney> ogra: ok, pls wait for a while
[09:57] <GrueMaster> ogra: I saw the same issue that he is seeing once before, but couldn't reproduce it.
[10:11] <DanaG> argh, stupid SGX.
[10:24] <vstehle> DanaG: which platform are you on?
[10:25] <DanaG> Beagleboard.
[10:25] <DanaG> Exit message has been set to: "PVRShell: Unable to create surface"
[10:25] <DanaG> ... and those stupid powervr demos show that their hardware really is annoying...  with ATI, nvidia, intel, and even all the various open-source 2D things, you use standard OpenGL.   PowerVR?  They use some proprietary .POD, and god-only-knows what.  Their demos don't even compile on x86_32 -- missing make_platform.mak and such.
[10:27] <vstehle> DanaG: Your best option with powervr is OGLES2 it seems.
[10:28] <DanaG> Anyway, my definition of "Useful 3D" is "Runs Compiz".
[10:28] <DanaG> As long as nothing ARM will do that, ARM is not viable for netbooks or such for me.
[10:29] <vstehle> DanaG: does compiz run on something else than OGL? GLES maybe?
[10:29] <DanaG> Nope.
[10:29] <DanaG> Nor can kwin, I believe.
[10:54] <cooloney> ogra: too bad, i failed to find that log file in my SD card, it enters initramfs eventually
[11:07] <DanaG> http://wiki.meego.com/ARM/Meego_on_Beagleboard_from_scratch#Run_the_TI_demos
[11:07] <DanaG> ah, fixed my PVR.
[11:18] <persia> So, I got a beagle+zippy, and I connected power, ethernet, USB, and HDMI, and inserted a class 6 Sd with the maverick Alpha 3 image.  I get lights for power and ethernet, but nothing else appears to happen (no video output, no ARP registration on the network).  Any suggestions on how to debug?  I also see nothing on the zippy serial port.
[11:20] <ogra> HDMI ?=
[11:21] <ogra> the beagle doesnt have HDMI, there are only DVI signals on the port
[11:21] <ogra> you dont even see uboot on serial ?
[11:21] <persia> There's a port that fits an HDMI cable
[11:21] <ogra> right
[11:22] <persia> I don't see anything at all.
[11:22] <ogra> its a HDMI port but DVI signals
[11:22] <persia> That's fine: it's wired to an HDMI->DVI-D converter before going to a DVI screen.
[11:22] <ogra> ah, good
[11:23] <ogra> how do you boot ?
[11:23] <ogra> you need to hold down the user button to make the romcode access the SD
[11:23] <persia> S1 or S2?
[11:24] <vstehle> ogra: You are not relying on the u-boot in NAND?
[11:24] <ogra> persia, the one that has "user" written next to it :)
[11:24] <vstehle> ogra: This way you would only need a boot.scr, no MLO, no u-boot
[11:24] <ogra> vstehle, that wouldnt work with XMs
[11:24] <GrueMaster> vstehle: New versions of both.
[11:24] <ogra> nor with pandas
[11:25] <vstehle> ogra: Oh you want a generic solution for OMAP3 & 4? I see...
[11:25] <ogra> yes, thats how our images are designed
[11:25] <vstehle> ogra: Of course; silly me :)
[11:25] <persia> vstehle, I'm not sure I have anything in NAND, or I'd expect to see some serial output
[11:26] <vstehle> persia: "old" beagle for sure say hello on serial, even with no SD
[11:26] <ogra> you should see 40T on the serial port as soon as you fire up the board
[11:26] <ogra> that tells you "i'm alive but have nothing in NAND"
[11:26] <GrueMaster> persia: You need a null modem.
[11:26] <persia> I still have nothing on the serial port, but I've some DVi output now, so I'm happy.  Thanks.
[11:26] <ogra> ah, great
[11:27] <vstehle> persia: strange you have nothing on serial; check cable & config
[11:27] <ogra> you will likely run into mmc issues though
[11:27] <ogra> either it wont find the mmc at all or only have it available in readonly mode
[11:28] <persia> We'll see.  Plymouth is running now.
[11:29] <ogra> plymouth ?
[11:29] <ogra> so it did the resizing already and rebooted ?
[11:29] <persia> Yep.
[11:29] <ogra> hmm, then you dont seem to have mmc issues
[11:29] <persia> It's a very small card :)
[11:29] <ogra> 4G is minimum
[11:30] <cooloney> ogra: too bad, i failed to find that log file in my SD card, it enters initramfs eventually
[11:30]  * ogra will add enough spare space on the image to make it 2.2G big so people dont get the idea to use it on less than 4G cards
[11:30] <ogra> cooloney, the log should be in /dev/.initramfs/
[11:31] <ogra> during the initramfs
[11:31] <persia> Yeah, 4G.  I wouldn't do less, after all the time I spent arguing that supporting 2G was madness :)
[11:31] <ogra> or if you got to the reboot stage it might already have been copied to the rootfs
[11:34] <ogra> persia, if its a normal C4 i'D suggest to immediately create a swap file manually and swapon once ubiquity created the user
[11:34] <ogra> (on a tty while the removal stuff of oem-config runs)
[11:37] <cooloney> ogra: if i ran 'halt' or 'reboot' during initramfs, the log will be gone?
[11:38] <ogra> cooloney, if it went through the second part (that sets up everything) the log should have been copied to the rootfs already
[11:38] <ogra> (that part ends with the "reboot check" message)
[11:38] <persia> ogra, I'm still waiting for something interesting to load over the eye-searing background.  That said, how would I distinguish an abnormal C4?
[11:38] <ogra> persia, you cant, its OOming silently
[11:39] <ogra> persia, though you could be hit by Bug 616581
[11:39] <ubot2> Launchpad bug 616581 in ubiquity (Ubuntu) "oem-config fails to run (affects: 3) (dups: 1) (heat: 24)" [High,Triaged] https://launchpad.net/bugs/616581
[11:40] <NCommander> ogra: I'll pull down the latest dove live when I get back to the hotel and try  and get you anothe rdata point on the dbus issue to confirm if its specific to  pre-installs
[11:40] <ogra> NCommander, great
[11:41] <persia> ogra, Indeed I am :)
[11:41] <ogra> though i just downgraded a daily to the last known working upstart and dbus packages
[11:41] <ogra> persia, just wait until you can hit enter and end up on a rootshell
[11:41] <NCommander> ogra: isn't it nice how easy it is to tweak a pre-installed image ;-)?
[11:41] <ogra> persia, then you can do the setup manually
[11:41] <persia> Indeed.
[11:41] <ogra> NCommander, well, next i'll try to downgrade to the former kernel ...
[11:42] <ogra> NCommander, and *thats* tricky on preinstalled images
[11:42] <ogra> packages are surely a lot easier to change though, i agree
[11:42] <NCommander> ogra: can't you just kick a new uImage into the VFAT and turn it on?
[11:43] <ogra> uImage isnt the prob :)
[11:43] <NCommander> ogra: and respin the uInitrd?
[11:43] <ogra> right you need to respin it
[11:43] <NCommander> ogra: that's not super difficult
[11:44] <ogra> if you cant chroot into the rootfs it is :P
[11:44] <persia> respinning isn't an issue, but it helps if you mount the SD on another armel device to do so...
[11:44] <NCommander> ogra: strip the top 64 bytes of the uInitrd, zcat uInitrd | cpio -ivd
[11:44] <NCommander> change the files yo uneed, then repack, and mkimage
[11:44] <ogra> urgh
[11:44] <ogra> nah
[11:44] <ogra> i prefer to use a clean respin from scratch
[11:45] <NCommander> ogra: that being said, the kernel should still boot if its mismatched; we're not depending on any special modules on OMAP for normal boot last I checked
[11:45] <persia> Clean respin or same-arch chroot is much better than that hack
[11:45] <ogra> right, without input devices etc :P
[11:45] <DanaG> "an hdmi port but DVI signals" -- say, how is that even different?
[11:46] <DanaG> ooh, fbvncserver!
[11:46] <DanaG> http://code.google.com/p/android-vnc/
[11:46] <DanaG> Static one works fine on my non-Android Beagle.
[11:46] <DanaG> Say, now that I don't need Flash... I should try android beagle again.  It's a bummer I couldn't find the danged asix module, though.
[11:48] <persia> DanaG, HDMI can have lots of different signals, but usually includes DVI-D and audio, and may contain one or more serial channels, and perhaps even an ethernet channel.
[11:50] <DanaG> Serial and ethernet?  That'd be spiffy.
[11:50] <DanaG> That serial channel must be how LG makes their receivers and TVs work together.
[11:51] <NCommander> persia: do you plan to be around tonight? I can use your help w/ the libd-i changes
[11:51] <persia> HDMI 1.4 added ethernet.  I think the serial is limited to Consumer Electronics Control messages though, by the spec (although one could conceivably generate non-compliant equipment...)
[11:51] <DanaG> say, I need to ask rcn-ee for kernel headers... since the ubuntu ARM official kernel fails to init omapfb.
[11:52]  * persia refers to the specs for more detail, having only a limited understanding of HDMI
[11:52] <persia> NCommander, probably not more than another hour or two (it's later here than there)
[11:54] <DanaG> argh, ureadahead bails on my thing -- OOM.
[11:54] <persia> Didn't rsalveti have a patch for that?
[11:54] <ogra> dont use the netbook images on less than 512M :)
[11:55] <DanaG> I used the "minimal".
[11:55] <ogra> persia, yes, but Keybuk wasnt available the last days
[11:55]  * persia mumbles "We don't have maintainers in Ubuntu"
[11:55] <DanaG> ah, that android vnc server needs "kbde" -- keyboard emulator.
[11:55] <DanaG> Oh yeah, and what's the deal with Linaro?
[11:55] <DanaG> I know it's a working-group of sorts, but what does it DO for us?
[11:56] <ogra> persia, but we have braches owned by people you cant commit to :P
[11:56] <ogra> DanaG, you know how you can run any x86 machine with the ubuntu -generic kernel ?
[11:56] <persia> DanaG, From my (limited) understanding, it's ARM's linux initiative group doing upstream stuff we can use.
[11:56] <ogra> DanaG, thats one example of things linaro will implement
[11:56] <DanaG> Cool.
[11:56] <DanaG> Either openfirmware-type or UEFI-type could be useful.
[11:57] <DanaG> Though, right now there's a TianoCore for ARM... but no way to really do anything with it.
[11:57] <DanaG> There's no arm grub-efi.
[11:57] <ogra> currently they are working on unifying uboot
[11:57] <persia> ogra, branches are for people who don't know how to use the archive as a VCS.  keybuk wrote a great document explaining how the archive was essentially a VCS.  Plus, james_w set up a VCS that auto-imports anything uploaded, just in case people wanted to use obsolete external VCSs.
[11:58] <ogra> persia, right, but still he is the only one with access to the ureadahead branch
[11:58] <persia> DanaG, There's a few openfirmware implementations for ARM: someone just needs to add support for specific hardware of interest :)
[11:58] <ogra> persia, indeed i could just blindly upload and ignore bzr
[11:59]  * persia is of the opinion that folks using bzr to handle packaging and not following UbuntuDistributedDevelopment guidelines deserve the side effects
[12:02] <cooloney> ogra: http://pastebin.ubuntu.com/480892/
[12:03] <cooloney> ogra: this time it stops before initramfs
[12:04] <ogra> cooloney, WOAH !
[12:05] <ogra> that looks really bad
[12:06] <cooloney> i looks like my SD card is not good
[12:06] <cooloney> *it
[12:06] <ogra> no, i see the same on a fresh image here
[12:06] <cooloney> need i try another onw?
[12:06] <cooloney> ok,
[12:06]  * ogra is just done with a test
[12:06] <cooloney> got it
[12:12] <DanaG> oh yeah, I tried btrfs... got lack of fsck.btrfs/
[12:14] <ogra> hmm, so doing an fsck on a freshly dd'ed image doesnt show any errors
[12:14] <ogra> thats weird
[12:15] <michaelh1> Hi there. What's a good filesystem to use on a SD card?  On my 4 GB card I get 17.5 MB/s read.  FAT gives 3.7 MB/s write but ext3 is half that at 1.7 MB/s...
[12:19] <DanaG> http://pastebin.com/zR7pepwM
[12:19] <DanaG> that's my problem with -1001-omap.
[12:21] <persia> michaelh1, The best filesystem is one supported by the FTL on the flash card, which is incredibly hard to detect.  All filesystems are bad to some degree, as we don't have raw access to the eraseblocks, and are dealiing with a false abstraction of a block device.
[12:21] <DanaG> Say, I'm wondering if I should make my laptop's ssd be btrfs.
[12:22] <persia> In general, journalling filesystems are less bad.
[12:22] <ogra> DanaG, 1001-omap isnt an ubuntu kernel, talk to the people maintining it :)
[12:22] <persia> DanaG, again, depends on the FTL
[12:22] <DanaG> So -15 is Ubuntu?
[12:24] <DanaG> But the linux-omap package depends on 1002 (which isn't even out yet).
[12:25] <DanaG> Okay, I'll try 15.
[12:25] <ogra> surely not
[12:25] <persia> Hrm?  Any kernel in the archives is inherently an Ubuntu kernel.  Any other kernel isn't.
[12:26] <ogra> persia, we have two omap3 flavours, one is a linaro oen
[12:26] <ogra> linux-omap is ours, linx-linaro-omap is linaros
[12:27] <ogra> or linux-linaro-image-omap
[12:27] <ogra> seems their meta doesnt have a toplevel metapackage
[12:27]  * persia doesn't see how linux-linaro-image-omap isn't an Ubuntu kernel, although it's not the default kernel.
[12:27] <ogra> in any case linux-omap should not depends on the -1001- package (which is linaros)
[12:28] <ogra> if that happens, thats a bug
[12:28] <persia> I agree with that :)
[12:28] <mopdenacker> DanaG: at least ext4 gives much better performance than ext3, according to several tests I made. At least on a SATA disk. And I have no problem using it on eMMC.
[12:29] <mopdenacker> btrfs sounds good too. Now sure how mature it is though. ext4 is definitely mature enough (used in our servers without any issue)
[12:30]  * ogra wonders if lag knows if there were any filesystem driver related changes in the omap4 kernels recently 
[12:31] <mopdenacker> DanaG: otherwise, Squashfs rocks for read-ony parts of your fs. It's lightning fast.
[12:31] <ogra> i can fsck the SD card 100 times on x86 without any errors ...
[12:31] <ogra> but as soon as i run it on the üpanda i have lots and loits of filesystem errors
[12:31] <mopdenacker> ogra: perhaps issues in the mmc block drivers?
[12:31] <ogra> mopdenacker, possible
[12:32] <mopdenacker> ... causing corruption after time.
[12:32] <lag> ogra: Not that I'm aware of, but I can check
[12:33] <lag> ogra: So I don't have to read all the backlog, can you briefly tell me what the problem is?
[12:33] <mopdenacker> ogra, do you confirm that your pre-installed images don't support OMAP ES2.0 yet? alpha3 doesn't boot on my Blaze, that's why I suspect this.
[12:34] <ogra> lag, http://pastebin.ubuntu.com/480892/ all these fs errors (which i dont get when running fsck on other arches with the same filesystem)
[12:34] <ogra> mopdenacker, right, we only have one es2 yet thats at the QA person
[12:34] <ogra> mopdenacker, so we cant do any development for es2 yet
[12:35] <ogra> lag, so looking at the changelog of the linux-ti-omap4 package it seems there were a lot mmc realted changes
[12:38] <mopdenacker> ogra: thanks! That's an issue. We will address it during the call this afternoon.
[12:39] <ogra> i think the es2's are on their way now
[12:39] <lag> ogra: Nothing's been changed in the past 2 weeks
[12:39] <ogra> lag, there was an upload on the 5th
[12:39] <ogra> and the first image after the 5th was the first one that stopped working
[12:40] <lag> Yes, two weeks ago
[12:40] <lag> So something in that lot has killed your build?
[12:40] <ogra> well, something between the 4th (alpha3) and the 9th (teh first image that was buildable again)
[12:42] <lag> ogra: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=commitdiff;h=371114579a7d9c313ff76707fbeff39f0a0a4015
[12:42] <lag> ogra: Take your pick
[12:42] <ogra> lag, well grep for MMC in there
[12:43] <lag> Brain grepping :)
[12:43] <ogra> ha !
[12:43] <ogra> at least i see oem-config again now
[12:43] <ogra> with lots of hacking
[12:43] <lag> 15 MMC changes
[12:43] <ogra> yeah
[12:44] <ogra> it could as well be e2fsprogs
[12:44] <ogra> there was a merge on the 7th
[12:45] <ogra> the new oem-config ui looks nice
[12:46] <ogra> argh
[12:46] <ogra> no more way to set the hostname
[12:46] <ogra> thats bad
[12:46] <lag> ogra: Take a know good kernel (I suggest alpha3) and put it on the daily build image
[12:46] <lag> known*
[12:46] <lag> Then test
[12:47] <lag> If you are greeted with the same results, it's the kernel's fault
[12:47] <lag> If not, blame e2fsprogs
[12:48] <ogra> lag, yeah, its just not that easy :P
[12:48] <lag> ogra: Why isn't it?
[12:48] <persia> initrd
[12:48] <ogra> right
[12:48] <lag> Rebuild that too
[12:49] <lag> Do you want me to rebuild it for you?
[12:49] <ogra> i need to test on a virgin image
[12:49] <ogra> which means it is tricky to get exactly all the changes into the initrd
[12:49]  * lag chuckles "virgin"
[12:49] <lag> Do you have any better ideas?
[12:50] <ogra> not really
[12:50] <lag> :)
[12:50] <ogra> but i'm trying all other opportunities first :)
[12:51] <ogra> and additionally i just got oem-config up so i have to finish that install
[12:52] <lag> k
[12:54] <mopdenacker> ogra: do you have documentation for building your pre-installed images? Our plans are to make such images for our next internal release.
[12:55] <lag> mopdenacker: dd and go
[12:55] <ogra> mopdenacker, not yet and the last two weeks i was held up due to the non-booting images its on my TODO to provide such docs
[12:56] <mopdenacker> ogra: I understand. Thanks. Do the images boot now?
[12:56] <ogra> not really
[12:57] <ogra> i have hacked around some issues though
[12:57] <ogra> but they dont resize the filesystem properly due to all these FS errors
[12:57] <mopdenacker> lag: I wish it was that easy... At least you need to make the installer start...
[12:57] <ogra> and there are odd things going on in oem-config
[12:57]  * ogra takes a break
[12:57] <lag> ogra: I have some scripts that may help you create your initrd file if that's the route you decide to go
[12:58] <persia> ogra, The test-build for the pulse stuff isn7t going to complete before I lose track: I'll send you a patch tomorrow.
[12:58] <lag> mopdenacker: How do you mean?
[12:59] <lag> If you're talking about the Panda/Beagleboard all you have to do is dd the image onto an SD card and put it in
[12:59] <lag> The rest is automated
[12:59] <mopdenacker> lag: Yes, but there are a few special things to do:
[12:59] <lag> mopdenacker: There are?
[12:59] <mopdenacker> lag: - create an image that's just the size that you need.
[13:00] <mopdenacker> (and not the size of the sd card you used)
[13:00] <lag> The installer re-sizes the card for you
[13:00] <lag> Wrong: The image
[13:00] <mopdenacker> - modify the rootfs so that the installer starts and does its job (configure the TZ, create the user, choose the login mode).
[13:00] <mopdenacker> A standard image would just boot.
[13:00] <mopdenacker> without starting the installer.
[13:01] <DanaG> oh yeah, something I found on the rcn-ee maverick minimal: it left dhcp-client-identifier set to "d-i".
[13:01] <lag> The TZ and user creation is done via an intuitive GUI
[13:02] <mopdenacker> lag: I'm taking the developer point of view. If I use a 4 GB SD card for development, my image will be 4 GB big, and will contain plenty of unused blocks at the end.
[13:02] <lag> mopdenacker: Ah, I see
[13:02] <mopdenacker> lag: Yes, no issue from the user perspective ;-)
[13:02] <lag> mopdenacker: You just make the image as small as you can <2GB
[13:03] <mopdenacker> that's why I need Oliver's doc
[13:03] <lag> mopdenacker: Make the installer probe the card and re-size on first boot
[13:03] <lag> I didn't realise Oliver was creating a doc from the developer's angle
[13:03] <lag> ogra: When it's ready can you CC me?
[13:04] <kblin> morning rcn-ee
[13:04] <rcn-ee> morning kblin..
[13:04] <lag> mopdenacker: Nice pic :) http://opdenacker.org/images/michael_opdenacker.jpg
[13:05] <lag> rcn-ee: 6th lucky
[13:05] <lag> rcn-ee: I have everything crossed for you!
[13:05] <DanaG> (05:01:41 AM) DanaG: oh yeah, something I found on the rcn-ee maverick minimal: it left dhcp-client-identifier set to "d-i".
[13:05] <rcn-ee> yeap luckly number 6.. time to ship it.. ;)
[13:05] <DanaG> Oh, and one thing I'm using the user-button function for:
[13:05] <DanaG> alt-boot will load uImage.alt and uInitrd.alt.
[13:06] <rcn-ee> kblin, are you still working on the multi node arm setup?  I think a couple users on this list would be interested in setting up big arm farms build building.. ;)
[13:06] <DanaG> Oh, and that android vnc server works fine with non-android ARM!
[13:09] <rcn-ee> lag now that those patches will be merged, there's a couple old bugs we can tackle, like actually setting up the usb on the C4.. (currently u-boot sets that up..)
[13:10] <lag> rcn-ee: I can't help you with that one
[13:10]  * lag only has Panda & XM
[13:10] <kblin> rcn-ee: I was mostly looking at multi-node storage so far
[13:11] <DanaG> c4 is all I have.
[13:11] <rcn-ee> i think the XM has the same issue, although the older u-boot's that don't set the USB won't boot it.. ;)
[13:11] <kblin> rcn-ee: but a working distcc setup is on my todo list
[13:11] <DanaG> But I'm really interested in that panda.
[13:11] <lag> rcn-ee: Who's Jarkko
[13:11] <rcn-ee> I'm not really sure, he either works for TI or Nokia..
[13:11] <DanaG> say, how stable is btrfs?  Will it at least not silently corrupt things when approaching full?
[13:12] <amitk> lag: rcn-ee: ex-Nokia, audio driver maintainer
[13:12] <kblin> DanaG: dunno, just installed my first maverick VMs with brtfs
[13:12] <lag> amitk: Thanks
[13:12] <kblin> will stress them a little the following days
[13:12] <amitk> lag: got a message for him? :)
[13:13] <DanaG> Specifically, SSD optimizations are what I want.
[13:14] <DanaG> wow, btrfs actually makes my dog-slow cruzer not dog-slow.
[13:14] <lag> amitk: Why? Are you having lunch with him? ;)
[13:15] <amitk> lag: i will, next week :-p
[13:15] <amitk> or I can ask him to get onto irc if you need to chat
[13:17] <lag> amitk: I don't - I just saw that he was helping Robert to upstream his patches
[13:17] <lag> rcn-ee needs lots of help ;)
[13:17]  * lag hopes Robert can take a joke :D
[13:18] <amitk> lol
[13:20] <rcn-ee> just a little.. .;)  i was looking at a coupe other board-omap3* files (such as the touchbook) and it looks like it has the same bug.. (wrong setup wp's..)
[13:21] <lag> rcn-ee: Are we talking about USB again?
[13:21] <lag> The patches you've just submitted?
[13:22] <rcn-ee> this is the 'ro' bug on the mmc that my patches fixed for the beagle..  if i'm write, the touchbook will have the same issue if you boot it with 2.6.35..
[13:23] <GrueMaster> persia: ping - bug 616581 started after alpha 3.
[13:23] <ubot2> Launchpad bug 616581 in ubiquity (Ubuntu) "oem-config fails to run (affects: 4) (dups: 1) (heat: 459)" [High,Triaged] https://launchpad.net/bugs/616581
[13:24] <rcn-ee> ^^^  i've always had to run with atleast 50Mb of swap, no matter the amount of ram.. (128/256/512)
[13:24] <lag> rcn-ee: I'm assuming you don't have the HW to test?
[13:25] <rcn-ee> i do.. ;)  bug i'm missing other touchbook patches so i haven't booted my own kernel yet.. but you guys (ogra) had it working for lucid, so you might run into a 'ro' bug, depending on the logic of pin 23..
[13:26] <ogra> rcn-ee, i had only the upstream dev kernel working
[13:26] <ogra> (ai upstream i mean)
[13:26] <ogra> which iirc was 2.6.32 or so
[13:27] <rcn-ee> okay, cool wasn't sure on which kernel you used...
[13:27] <ogra> it never worked (or even booted) with anything else than the ai kernel trees
[13:32] <mopdenacker> ogra: I tested your -alpha3 pre-installed image on the Beagle RevC2 (256 MB of RAM). UNE us hardly usable. Not enough RAM, I would say....
[13:33] <mopdenacker> Hi robclark! Did you find a Panda (board)?
[13:33] <mopdenacker> Don't hesitate to ask me to test stuff if it can help...
[13:33] <robclark> mopdenacker: no not yet..  still trying to debug other issue on LCD/blaze..
[13:34] <robclark> but I will try to find a panda to use for the weekend
[13:34] <mopdenacker> robclark: great, thanks!
[13:38] <DanaG> ooh, g_nokia is cool, but it leaves the link down!
[13:39] <ogra> mopdenacker, yeah, i would love to no support the C series beagles with these images, but that requires XM to work
[13:45] <DanaG> g_audio gadget: Playback error: -77
[13:45] <DanaG> loops infinitely.
[13:45] <DanaG> Where do you even FIND a panda?  I can't find so much as a single picture, or a press release, about it!
[13:46] <GrueMaster> ogra: So you found the oem-config issue?
[13:47] <vstehle> DanaG: it is not released yet.
[13:47] <DanaG> Ah.  Is the release date under NDA?
[13:47] <ogra> GrueMaster, no, only a symptom
[13:48] <ogra> GrueMaster, the lines in question shouldnt be executed
[13:48] <vstehle> DanaG: yep.
[13:48] <DanaG> Bummer.
[13:49] <DanaG> hmm, can you describe what you ARE allowed to say about it?
[13:49] <vstehle> DanaG: certainly: nothing :)
[13:49] <DanaG> Damn, that sucks.
[13:50] <DanaG> er, s/damn/dang/
[13:50] <mopdenacker> ogra: ouch, do you mean you have issues with the kernel for XM? Or do wish you had an XM?
[13:50] <ogra> mopdenacker, i wish there were stable XMs :)
[13:51] <mopdenacker> ogra: understood :-) BTW, the final version is supposed to start shipping today.
[13:51] <mopdenacker> shipping to distributors at least.
[13:51] <ogra> hmm, i stopped counting how often i heard something similar :)
[13:51] <DanaG> I hope it's at least more comparable to xM than to C4.
[13:51] <ogra> if i see them on sale i'll belive it :)
[13:53] <XorA> TI is using the openmoko schedule for XM and panda :-)
[13:55] <ogra> persia, E: ubiquity-frontend-gtk: arch-independent-package-contains-binary-or-object ./usr/lib/ubiquity/panel
[13:55] <ogra> pfft
[13:56] <ogra> so we try to exec an x86 binary
[13:56] <ogra> GrueMaster, ^^^
[13:56] <ogra> fixing that should at least solve one of the issues
[13:58] <GrueMaster> oops.
[13:59]  * ogra goes for a short break
[14:12] <rsalveti> morning
[14:13] <GrueMaster> rsalveti: morning.
[14:27] <rsalveti> mopdenacker: it seems that prpplague found what is wrong with the kernel and your monitor
[14:28] <rsalveti> seems an issue when calculating the 1280x1024 PLL values
[14:28] <rsalveti> he was going to try a fix today, i guess
[14:28] <rsalveti> GrueMaster: were you able to test your es2?
[14:29] <rsalveti> persia: you can find the ureadahead "fix" at the bug, I sent a branch with it
[14:29] <GrueMaster> Getting to that point.  I've actually had to be interactive with the sprint wrap-up mostly.
[14:29] <rsalveti> persia: also, which zippy did you get?
[14:29] <GrueMaster> I have it all downloaded, just need to swap out es1 for es2 & boot.
[14:30] <rsalveti> cool
[14:30] <mopdenacker> Oi rsalveti ! That's good news!
[16:03] <mopdenacker> Morning prpplague !
[16:07] <ogra> lag, argh
[16:08] <ogra> lag, i think we mixed up a bug, while you were looking at bug 605488 for which i gave you swap file instructions, it should have been bug 605739 instead
[16:09] <ubot2> Launchpad bug 605488 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "BUG: scheduling while atomic: mmcqd/46/0x00000002 (affects: 1) (heat: 108)" [High,In progress] https://launchpad.net/bugs/605488
[16:09] <ubot2> Launchpad bug 605739 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "BUG: Bad page state in process swapper pfn:94d23 (affects: 2) (heat: 119)" [High,In progress] https://launchpad.net/bugs/605739
[16:12] <prpplague> mopdenacker: ho ho ho, merry freakin friday!
[16:13] <prpplague> mopdenacker: i think i have the dvi issue nailed down
[16:13] <prpplague> mopdenacker: got to do some more testing this morning
[16:15] <lag> orga: You and I are going to fall out!
[16:15] <lag> ogra: That's another bulk of time you've wasted! Arrrrrrrrrrrrrrrr
[16:15] <ogra> lag, i'll compensate that with beer at the next sprint
[16:16] <lag> ogra: That would be a good start ;)
[16:16] <lag> ogra: Thanks for letting me know
[16:17] <prpplague> beer good
[16:17] <lag> Beer very good
[16:17] <mopdenacker> prpplague: cool! Many thanks!
[16:20] <prpplague> i picked up a couple different hdmi switchers this morning too
[16:20] <prpplague> have a look at geting those working
[16:20] <prpplague> mopdenacker: you have a kernel build environment setup?
[16:21] <mopdenacker> prpplague: I can set it up quickly
[16:21] <prpplague> mopdenacker: you still got the one line patch i posted yesterday?
[16:23] <mopdenacker> prpplague: yes: http://paste.ubuntu.com/480502/
[16:23] <prpplague> mopdenacker: okie dokie, there is another hack we can do for testing
[16:24] <prpplague> mopdenacker: let me get that posted
[16:26] <mopdenacker> prpplague: ouch, the CodeSourcery cross toolchain is sloooow to download.
[16:26] <prpplague> mopdenacker: indeed
[16:26] <prpplague> mopdenacker: http://paste.ubuntu.com/481007/
[16:26] <prpplague> mopdenacker: that's the other patch
[16:26] <prpplague> mopdenacker: let me give you a binary to test
[16:27] <prpplague> mopdenacker: oh wait, are you using a es2 or es1 board?
[16:27] <mopdenacker> prpplague: I have an es1 panda board.
[16:28] <prpplague> mopdenacker: ahh ok, my binaries are for es2
[16:28] <mopdenacker> prpplague: if you have a binary, that'll be quicker.
[16:29] <prpplague> mopdenacker: let me get a es1 build going
[16:32] <mopdenacker> prpplague: great, thanks a lot!
[16:40] <mopdenacker> hey, I'm using the phoronix-test-suite on arm (based on php scripts).
[16:40] <mopdenacker> I'm fed up with these warnings:
[16:40] <mopdenacker> oops, can't copy paste easily.
[16:41] <mopdenacker> Anyway, is the following a bug or a feature:
[16:41] <mopdenacker> dpkg -S /etc/php5/cli/conf.d/gd.ini
[16:41] <mopdenacker> dpkg: /etc/php5/cli/conf.d/gd.ini not found.
[16:42] <mopdenacker> Shouldn't every file that exist be in a package? Perhaps that's a generated file and that's acceptable...
[16:42] <ogra> do you have php5-gd installed ?
[16:42] <mopdenacker> ogra: yes I do.
[16:42] <ogra> well, it might be that the postinst script generates it
[16:43] <mopdenacker> ogra: yes, probably. I'll check this out. Thanks.
[16:47] <GrueMaster> rsalveti: I am currently getting hangs from your xloader.  http://paste.ubuntu.com/481014/
[16:48] <ogra> wow thats odd
[16:48] <ogra> it usually hangs a lot earlier
[16:48] <ogra> having a hang message after the kernel is up is something i havent seen yet
[16:50] <GrueMaster> It is fairly immediate.
[16:51] <ogra> well. it happens at a point where the kernel should have taken over already
[16:57] <rsalveti> GrueMaster: weird, that generally happens to me when my uInitrd is broken
[16:59] <rsalveti> prpplague: did yo ever see this?^
[16:59] <rsalveti> I built the x-loader and u-boot from es2 banch from gitorious
[16:59] <ogra> and the kernel ?
[17:00] <ogra> wasnt it that the es2 wont run with the es1 kernel ?
[17:02] <prpplague> rsalveti: let me look
[17:02] <rsalveti> ogra: I created my own, with es2 patches on top of ubuntu kernel
[17:02] <ogra> ah
[17:02] <rsalveti> thats why I askes GrueMaster to test
[17:02] <ogra> i was just wondering i fan es1 kernel might be able to cause that
[17:02] <ogra> *if an
[17:03] <prpplague> rsalveti: that happens with the kernel returns, which usually means something on the image startup failed, you can enable earlyprintk's to get more details as to the cause
[17:03] <GrueMaster> I am remaking uImage & uInitrd now, but I had installed rsalveti's kernel package.
[17:04] <rsalveti> GrueMaster: es2 package, right?
[17:04] <GrueMaster> yes.
[17:04] <rsalveti> hm
[17:07] <rsalveti> http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-maverick.git;a=shortlog;h=refs/heads/rsalveti-ti-omap4-es2
[17:07] <rsalveti> the tree I used
[17:08] <rsalveti> argh, my N900 is very slow :)
[17:09] <prpplague> mopdenacker: got some place me to upload the image to?
[17:09] <GrueMaster> Ok, working now.  Must have clobbered uInitrd or something.
[17:10] <rsalveti> cool
[17:10] <GrueMaster> Eww.  No USB.
[17:10] <ogra> heh, did the kernel pass lag at some point ?
[17:11] <rsalveti> mopdenacker: let me know if the patch works for you, cause then I can put it at my tree and build a new package
[17:11] <GrueMaster> heh
[17:11] <rsalveti> GrueMaster: can you paste the boot?
[17:11] <prpplague> rsalveti: that patch is just for testing
[17:12] <GrueMaster> Yes. just a sec.
[17:12] <rsalveti> oh, ok :)
[17:12] <prpplague> mopdenacker: http://www.elinux.org/images/2/2f/UImage-test-panda.bin
[17:12] <mopdenacker> prpplague: cool, thanks a lot!
[17:12] <prpplague> mopdenacker: that is a minimal kernel to test the dvi support
[17:16] <GrueMaster> rsalveti: http://paste.ubuntu.com/481025/
[17:17] <mopdenacker> prpplague: I owe you a beer when we meet in Cambridge at ELC-E. IT WOOOOORKS!
[17:17] <mopdenacker> Yooohoo!
[17:17] <prpplague> mopdenacker: hehe
[17:18] <prpplague> mopdenacker: ok i need to do some digging for a more reasonable fix
[17:18] <prpplague> mopdenacker: atleast we know the root of the problem
[17:18] <GrueMaster> I'm being informed that I need to start packing up.  We're getting booted from the room at 6 and I have a lot to pack (typical for mobile)
[17:19] <mopdenacker> Great! Thanks again!
[17:19] <rsalveti> cool, no oops at least
[17:20] <rsalveti> GrueMaster: good luck and have a nice trip back home :)
[17:21] <mopdenacker> Well, it does oops, but that's probably elsewhere. prpplague told us it's a minimal kernel. At least the fb looks great.
[17:21] <mopdenacker> The oops happens loading the initramfs
[17:28] <GrueMaster> rsalveti: As a final note, OTG fails to be detected as well.  "May" be a hw issue.
[17:29] <rsalveti> hm
[17:30] <GrueMaster> I'll look at it more in depth next week.
[17:41] <lag> ogra: Eh?
[17:50] <lag> robclark: ping
[17:51] <robclark> lag:  pong
[17:52] <lag> robclark: Hey Rob, how are you?
[17:52] <robclark> oh, alright
[17:52] <lag> robclark: That doesn't sound too promising :)
[17:53] <lag> robclark: Have you met my friend mpoirier?
[17:53]  * robclark would be better when he gets his panda back ;-)
[17:53] <mpoirier> robclark: hello
[17:53] <lag> robclark: He was sitting opposite me in Prague
[17:53] <robclark> hi mpoirier
[17:53] <robclark> ahh, ok
[17:53] <lag> He was wondering about your readedid patches
[17:54] <lag> He's doing something similar for us
[17:54] <robclark> ahh, ok
[17:54] <lag> mpoirier: All yours
[17:54] <mpoirier> lag: thanks.
[17:54] <robclark> mpoirier: go ahead and ask away
[17:54] <mpoirier> rob,
[17:55] <mpoirier> I just spent a week trying to read the edid with my beagleboard.
[17:55] <mpoirier> finally had to add an entry for the eeprom driver in board-omap3beagle.c
[17:55] <mpoirier> works great right now.
[17:55] <mpoirier> decode-edid recognise my monitor flawlessly.
[17:56] <mpoirier> I did all this 'cause I couldn't find a get-edid in the arm package.
[17:56] <robclark> ahh, cool... I didn't even realize beagle had hw connected to read edid
[17:56] <mpoirier> lag tells me it has been implemented and you're the magician.
[17:56] <robclark> get-edid doesn't exist on arm
[17:56] <robclark> what I did was add a sysfs file
[17:57] <mpoirier> interesting...
[17:57] <robclark> so you could run: parse-edid /sys/devices/display0/edid  (or something roughly like that)
[17:57] <mpoirier> humm...
[17:57] <mpoirier> here is what I did.
[17:58] <robclark> fwiw, here is the patch to add the sysfs file: http://gitorious.org/~robclark/pandaboard/robclarks-kernel-omap4/commit/12fa02c44710ee3c379d0ce2d18811b2a80bec1f
[17:58] <mpoirier> Ok, i'll look at it.
[17:58] <mpoirier> on the other hand, here is what I did:
[17:59] <mpoirier> 1) added an 'i2c_board_info' entry in board-omap3beagle.c
[17:59] <mpoirier> this adds an entry in sysfs: /sys/bus/i2c/devices/3-0050
[17:59] <mpoirier> under 3-0050 you find 'eeprom'.
[17:59] <mpoirier> from there, I simply call decode-edid.
[18:00] <mpoirier> what do you think ?
[18:00] <robclark> ok..
[18:00] <robclark> well, I guess the dss driver, somewhere, needs to get at the EDID in order to utilize it to set the display..
[18:01] <mpoirier> yes
[18:01] <robclark> so at that point it would make sense to expose as a display sysfs file.. I guess that would make life a bit easier for userspace so it didn't have to know which i2c device..
[18:01] <mpoirier> I proceeded in user space 'cause it was a requirement from the arm team.
[18:02] <mpoirier> I'll look at your approach - you're propably getting the perfect settings right away from the drivrer
[18:02] <robclark> hmm.. ok..  well, it seems like it would be nice to have framebuffer working before you boot up far enough to get into userspace..
[18:02] <rsalveti> yep, a sysfs file would be easier to port, but needs to be somehow a standard
[18:02] <robclark> yeah
[18:02] <mpoirier> I didn't want to dive in the driver.
[18:03] <mpoirier> thanks robclark for the tutoring session.
[18:03] <robclark> probably in some dss related struct in the board file, we'd need to add whatever info is needed to get the edid..
[18:03] <robclark> but probably we should chat w/ mythripk too..
[18:03] <robclark> since there will be some cleanup underway in hdmi driver..
[18:04] <rsalveti> yeah, there are two ways to use the edid, one is in the driver, to automatically set the resolution and the other to show it so we can set up the correct boot args
[18:04] <robclark> anyways.. adding the sysfs file is probably the easy part.. the bigger thing I guess is figuring out how to make the hdmi driver know where to find the EDID
[18:05] <mpoirier> yes indeed.
[18:05] <mpoirier> requires to get intimate with the driver itself.
[18:05] <rsalveti> at our blueprint we wanted to at least get the values to set it up after the first boot
[18:05] <rsalveti> after the installation
[18:07] <robclark> I guess for temporary solution.. if you can figure out what kind of board you are on in the installer, then you could know to go read under i2c driver in sysfs and use parse-edid
[18:07] <robclark> of course better solution would be for driver to figure things out for itself.. because you might unplug one monitor and plug in a different one..
[18:08] <rsalveti> yep, that would work
[18:08] <rsalveti> true
[18:08] <robclark> (and even better solution would be able handle that at runtime.. although that is far from perfect on panda either)
[18:09] <mpoirier> robclark: do you get some sort of interrupt when a monitor is plugged in ?
[18:09] <mpoirier> is there a notification mechanism ?
[18:09] <robclark> mpoirier: yeah, there is a hpd (hot plug detect) interrupt..
[18:09] <mpoirier> ah.
[18:09] <mpoirier> an entry should probably have to get in there too.
[18:09] <robclark> well.. the beagle has different HDMI IP probably.. actually, I don't really know what beagle has..
[18:09] <robclark> yeah
[18:10]  * robclark has to get lunch..
[18:10] <robclark> bbl
[18:10] <mpoirier> robclark: thanks.