[01:21] <godstar> Ive been at this for several hours. Anyone care to help me install Ubuntu on a ARM device?
[09:33] <cooloney> rsalveti: need i connect the beagle to HDMI display to login the board?
[09:34] <rsalveti> cooloney: not actually, only serial is enough
[09:34] <cooloney> rsalveti: http://pastebin.ubuntu.com/466351/
[09:35] <rsalveti> cooloney: just a moment, going there
[09:35] <cooloney> rsalveti: i looks to me it hangs there
[09:35] <cooloney> *it looks
[09:37] <lag_> sebjan: ping
[09:37] <sebjan> lag_: pong
[09:45] <lag_> Hey sebjan
[09:45] <lag_> Do you deal with XM?
[09:46] <sebjan> lag_: hi Lee, no I haven't yet. Someday maybe?
[09:46] <lag_> So who's problem is it?
[09:46] <ogra> lag_, go to #beagle and talk to koen, he should have working kernels
[09:47] <lag_> ogra: Who's koen? Is he with us?
[09:47] <ogra> he wors for TI and is the big beagle master
[09:47] <ogra> he is also angstrom upstream
[09:47] <ogra> *works
[09:47] <lag_> Nice one, thanks
[09:52] <hrw> ;)
[09:53] <hrw> http://www.angstrom-distribution.org/demo/beagleboard/ will give you 2.6.32 for BB
[09:54] <ogra> hrw, who is intrested in .32 nowadays :)
[09:54] <ogra> we dotn wnat spiderwebs and dust on our kernels :)
[09:55] <amitk> ogra: that is state of the art in angstrom land ;)
[09:55] <ogra> yeah
[09:55] <ogra> thats why the ship a duster with the images, right ?
[09:55] <hrw> that's what TI used internally
[09:56] <amitk> but yeah koen is a nice dude to know related to beagle issue, lag.
[09:56] <ogra> well, we need patches for the maverick tree
[09:56] <ogra> not for hardy ;)
[09:57] <hrw> there are few more people on #beagle with XMs
[09:58] <hrw> so maybe instead of waiting for _koen_ to appear better ask for XM kernel patches
[09:59] <ogra> or look at rcn-ee's trees ;)
[09:59] <ogra> since his binaries seem to work fine
[09:59] <ogra> *and* are up to date
[10:00] <hrw> https://code.launchpad.net/~beagleboard-kernel/+junk/2.6.35-dev
[10:00] <hrw> you mean that?
[10:19] <cwillu_at_work> hrw, yep
[10:19] <cwillu_at_work> binaries are available as well
[10:19] <cwillu_at_work> http://rcn-ee.net/deb/
[10:21] <rsalveti> cooloney: your sd card reader is here, if you want to take it back :-)
[10:21] <cwillu_at_work> incidently:  rcn-ee, I've got patches to allow the re-use of the kernel tree, so you don't end up rechecking out (even from a local copy) multiple times, and which ends up making for far quicker compiles if possible
[10:22] <cwillu_at_work> to build_deb and company
[10:23] <cooloney> rsalveti: yeah, thx for reminding.
[10:24] <cooloney> rsalveti: but i failed to see any oops
[10:25] <rsalveti> cooloney: with your kernel?
[10:26] <rsalveti> cooloney: I remember that your kernel is installed on the sd card
[10:26] <rsalveti> you can try the 501, like I did yesterday
[10:26] <rsalveti> then you can try to reproduce the issue
[10:26] <rsalveti> because it'll use the musb as module and load it as needed
[10:31] <cooloney> rsalveti: ok, i understand.
[10:34] <cooloney> rsalveti: $ ls
[10:34] <cooloney> boot-35.scr  boot.scr  uImage  uImage.35  uImage-lucid  uInitrd  uInitrd.35  uInitrd-lucid
[10:34] <cooloney> i got these files
[10:35] <rsalveti> cooloney: probably if you just copy uI*-lucid for uI* it should run the 501 by default
[10:35] <cooloney> rsalveti: ok, thx
[10:35] <rsalveti> I remember I created these files to test 501
[10:45] <cooloney> rsalveti: pls take a look at http://pastebin.ubuntu.com/466386/
[10:45] <cooloney> rsalveti: i tried copy over uI*-lucid and uI*.35
[10:45] <cooloney> rsalveti: and got that issue
[10:46] <rsalveti> cooloney: just a sec
[10:46] <cooloney> rsalveti: np
[10:50] <lag> cooloney: mkimage -A arm -O linux -T ramdisk -C none -a 0 -e 0 -n initramfs -d ./initrd.img-* ./uInitrd
[10:53] <ogra> lag, careful with wildcards ;)
[10:54] <ogra> you might have more than 1 ./initrd.img-* in that dir
[11:08] <cooloney> robclark: hdmi error: Failed to set PHY power mode to 0
[11:10] <ogra> cooloney, buy a better monitor
[11:13] <NCommander> ogra: http://paste.ubuntu.com/466397/
[11:13] <cooloney> ogra: i love my viewsonic at home
[11:14]  * ogra is hapy with the samesung he has
[11:16] <hrw> ogra: cheap chinese samsung fake clone?
[11:18] <robclark> cooloney: hmm, ok, I get that 'PHY power mode' on my board too (but still monitor works)..
[11:19] <cooloney> robclark: oh, weird. need i bring my board for you ?
[11:19] <robclark> cooloney: we can if you want...  I'm just installing meld to more easily diff the two dmesg txt files to see if I can spot some relevant difference
[11:20] <cooloney> robclark: yeah, i use meld heavily
[11:39] <cooloney> rsalveti: if you can help to test Maverick on beagle for that OTG bug, it will be very helpful
[11:40] <rsalveti> cooloney: yep, I'm just installing maverick, going to take a while but I believe it'll be ready for today ;-)
[11:40] <cooloney> since i just checked th patches for musb driver, .34 lucid kernel missed lots of patches from current upstream
[11:40] <cooloney> but those patches are in Maverick .35 kernel now. i think
[11:41] <rsalveti> cooloney: yep, also noticed that
[11:41] <cooloney> rsalveti: awesome, man, thx
[11:41] <rsalveti> np
[11:41] <robclark> cooloney: fwiw, your monitor is working now..  after letting it sit for a while
[11:41] <cooloney> robclark: really.
[11:41] <robclark> I do see some different bits set in one of the hdmi irq status registers with your board...
[11:41] <robclark> I'm trying to find what they mean.. maybe give some hint about the issue
[11:58] <ogra> rsalveti, lp:~jasper-initramfs
[12:33] <ogra> lag_, http://gitorious.org/beagleboard-validation/linux/commits/beagleboardXM
[12:34] <ogra> or rather http://gitorious.org/beagleboard-validation/linux
[12:34] <rcn-ee> hey ogra, was reading #beagle, your guy's xm doesn't boot?
[12:34] <ogra> rcn-ee, it boots but shows some opses
[12:34] <ogra> rcn-ee, the worse part is that USB and the NIC dont work
[12:34] <rcn-ee> there's one oops for me.. the usart3 (i think there's a patch for that on l-o) but nic and usb work for me..
[12:35] <ogra> the oopses seem harmless (trying to probe uart3 and failing because it doesnt exist)
[12:35] <rcn-ee> but i also have the half memory version.. (you guys might have the 512Mb)
[12:35] <lag_> Hi rcn-ee
[12:35] <rcn-ee> hi lag_
[12:35] <lag_> We've been waiting for you :)
[12:35] <ogra> rcn-ee, well, we're using a pretty plain 2.6.35 mainline
[12:35] <ogra> rcn-ee, so i suspect we miss some extra patches
[12:36] <rcn-ee> yeap me too.. here's what you need: http://bazaar.launchpad.net/~beagleboard-kernel/+junk/2.6.35-devel/files/head:/patches/xm/
[12:36] <rcn-ee> (most borrowed from sakoman)
[12:36] <ogra> lag_, ^^^
[12:36] <ogra> :)
[12:36] <rcn-ee> the xm-dvi-ehci will fix the ehci..
[12:37] <lag_> I see :)
[12:37] <lag_> Do I need all 4 patches?
[12:38] <ogra> they seem to make sense
[12:38] <rcn-ee> yeah, all four.. most are just macro's which will be upstream eventually anayways..
[12:38] <ogra> and dont look like they could cause regressions
[12:39] <rcn-ee> nope, not for me atleast, same kernel is booting fine with no regressions on my bx's, cx's, xm, overo, igepv_2..
[12:40] <ogra> cool
[12:40]  * ogra needs to try the new gumstix board h just got
[12:41] <ogra> though i guess the plain beagle MLO/u-boot wont work on it
[12:41] <rcn-ee> actually.. if you've bumped to 1.44ss and 2010-03 xm rev A support is included.. ;)
[12:41] <ogra> lag_, btw, your panda install is done, want me to bring you the SD ?
[12:42] <ogra> rcn-ee, yeah, XM is, we tested that already, (i'm still using 2010-03-rc though)
[12:42] <lag_> If you'd be so kind
[12:42] <ogra> i just got one of the 512M gustix though
[12:43] <lag_> Well I'll apply and try to get them pushed into our kernel
[12:43] <rcn-ee> yeap, that one is fine.. 2010-03-rc was the first.. btw keep an eye on sakomon's tree, there might be some memory tweaks for the xm (512Mb revision)..
[12:43] <ogra> great, i will
[12:46] <rcn-ee> btw, one thing odd about the xm's onboard lan, it comes up as a usbX device, which if you also have the gadget driver loaded it might confuse users (since that's usbx too) i've though about tweaking it to a normal 'ethX'...
[12:50] <ogra> ah, seems its the same HW as the panda has
[12:51] <ogra> panda alo has a usb0
[12:51] <ogra> *also
[12:51] <rcn-ee> yeap the lan95xx, usb/eth hub..
[12:51] <rcn-ee> or wait, doesn't the panda have the smsc...
[12:51] <ogra> yeah
[12:52] <ogra> with a good bunch of issues still
[12:52] <rcn-ee> i just got my booting.. ;) no usb yet for me...
[12:52] <ogra> your panda ?
[12:53] <rcn-ee> yeap... ;)
[12:54] <ogra> http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100720.2/
[12:54] <ogra> grab the omap4.img.gz :)
[12:54] <rcn-ee> will do and give you some results
[12:55] <ogra> just dd it to an SD and boot (you need monitor, kbd, mouse attached)
[12:55] <ogra> (after gunzipping indeed)
[12:56] <rcn-ee> i haven't posted much on #pandaboard, but have you guys forwared ported the u-boot patches to some less ancient?
[12:56] <ogra> no, linaro is working on such stuff
[12:56] <ogra> but thats will likely still take a while
[12:57] <ogra> i just took the panda branch from gitorious and made some changes to the defaults
[12:57] <ogra> (hush shell, script support and loading boot.scr by default form first mmc partition if it exists there)
[13:00] <rcn-ee> i was kinda hoping for one kernel, but it doesn't look yet like you can share a non smp target with an smp one in arm yet.. (or my compiler is too old 4.3.1)
[13:02] <tmzt> because of how cores are initialized?
[13:03] <ogra> rcn-ee, there is work going on towards a unified oma kernel
[13:03] <ogra> *omap
[13:03] <ogra> but that will also still take a while
[13:03] <ogra> will probably hit the streets together with a unified u-boot version ;)
[13:03] <NCommander> rcn-ee: also, very few devices are SMP ARM (panda is the only board I've seen with a multicore chip)
[13:04] <ogra> there will be more soon
[13:04] <ogra> isnt the tegra also SMP ?
[13:04] <NCommander> ogra: um, possibly?
[13:04] <NCommander> no idea
[13:04] <ogra> i think its A9 dual core
[13:13] <lag_> rcn-ee: Hi
[13:14] <rcn-ee> hi lag_
[13:16] <rcn-ee> yeap the tegra is dual core...  otherwise it's still early for dual arm devices, the omap35/36 really didn't take off til a year after the beagle..
[13:16] <lag_> rcn-ee: Would you mind sending me a working kernel binary please? With USB and Eth working?
[13:16] <lag_> I would like to test it before my kernel compiles
[13:16] <rcn-ee> so maybe a year after the panda is released we will see some omap4 devices..
[13:16] <lag_> If it's not to much trouble
[13:16] <rcn-ee> sure lag_ lucid or maverick?
[13:16] <ogra> mavrick
[13:16] <ogra> +e
[13:16] <lag_> You have Lucid working on XM too?
[13:17] <rcn-ee> 2.6.34 or 2.6.35.. (of course.. ;) )
[13:17] <ogra> .35
[13:17] <lag_> ogra: You have a big nose ;)
[13:17] <ogra> haha
[13:17] <rcn-ee> lag_, http://rcn-ee.net/deb/maverick/v2.6.35-rc5-dl6/linux-image-2.6.35-rc5-dl6_1.0maverick_armel.deb
[13:18] <rcn-ee> just don't use a zippy2 on that, it's missing a patch that's in dl7
[13:18] <lag_> So you downloaded our kernel, applied those 4 patches and everything sprung to life?
[13:18] <lag_> I don't even know what zippy is
[13:18] <rcn-ee> actually it's my own mainline +patches blend... config's are very similar..
[13:18] <hrw> rcn-ee: so far Ubuntu/Linaro people use plain BB - no extensions
[13:18] <lag_> He was a children's TV character when I was a kid :)
[13:18] <cwillu_at_work> I wuv my rcn-ee
[13:19] <hrw> I suppose that I am the only one in Linaro/Ubuntu team who has BB expansion board
[13:19] <rsalveti> I got one zippy 2 here, but doesn't work by default, still have to apply some patches
[13:19] <rsalveti> mainly on rcn-ee tree, that got from angstrom
[13:19] <cwillu_at_work> rsalveti, zippy2's ethernet will leak memory without a patch
[13:19] <rsalveti> cwillu_at_work: what patch?
[13:19] <cwillu_at_work> a 2 needed to be a 4
[13:19] <cwillu_at_work> rcn-ee has it
[13:20] <rsalveti> oh, ok, I see it
[13:20] <cwillu_at_work> otherwise it'll leak about 2k every second or two while an ethernet cable is connected
[13:20] <lag_> That's the patch that ogra gave me and said it will make USB work, lol!
[13:20] <rcn-ee> yeap, and the beagle is building maverick's dl7 right now.. it's just no uploaded.. yet..
[13:20] <cwillu_at_work> slabtop -s s -> size-2048 will get into the 20,000 alloated range, and then everything will stop working :)
[13:20] <ogra> lag_, i guessed :)
[13:20] <lag_> :D
[13:20] <cwillu_at_work> if you really need a binary with the patch in a hurry, I can send it to you
[13:21] <ogra> we rather need a working ubuntu kernel :)
[13:21] <rsalveti> yep :-)
[13:21] <cwillu_at_work> ... with btrfs compiled in :p
[13:21] <hrw> ogra: binary which works can be used to test does lag's XM is working at all
[13:21] <cwillu_at_work> none of this initramfs nonesense
[13:21] <cwillu_at_work> -e
[13:22] <rcn-ee> cwillu_at_work, noticed there was more btrfs patches last night.. hopefully it gets in 2.6.35-rc6..
[13:22] <ogra> hrw, well, we will just grab yours if lag_'s doesnt work :P
[13:22] <cwillu_at_work> oh, there's going to be lots of btrfs patches for the foreseeable future
[13:23] <cwillu_at_work> rcn-ee, if you really wanted to be my friend, you'd pull btrfs directly from git in patch.sh :)
[13:23] <rcn-ee> is it just usb/dss2 that's not working on the xm, those 4 from me will take care of it..
[13:23] <hrw> ogra: mine? hah
[13:23] <ogra> indeed yours :)
[13:24] <rcn-ee> i thought about it... ;) since my builders will be free again in a couple hours..
[13:25] <cwillu_at_work> also, did you want to look at the changes I made to build_deb.sh to make it re-use the build environment?
[13:26] <rcn-ee> sure, cwillu_at_work i'd take a look at those tweaks..
[13:28] <cwillu_at_work> http://pastebin.com/rkgRsXnH
[13:28] <cooloney> rsalveti: if the OTG port works, it is supposed to support a USB mouse connected with the USB mini connector you gave to me, right?
[13:28] <cwillu_at_work> rcn-ee, patch isn't terribly clean, as your indentation is atrocious :p
[13:28] <rsalveti> cooloney: without a powered hub, don't know
[13:29] <cwillu_at_work> rcn-ee, so what we do is...
[13:29] <cooloney> rsalveti: i tried powered hub, the usb mouse doesn't work
[13:29] <rsalveti> cooloney: I'll just test with maverick, rebooting...
[13:29] <cooloney> rsalveti: cool
[13:29] <rsalveti> cooloney: with 501?
[13:30] <cooloney> rsalveti: with 501, if the oops shows up, the musb driver does not work at all
[13:30] <cooloney> so the usb mouse won't work
[13:30] <rsalveti> cooloney: yeah, only works when you don't get the oops
[13:30] <cooloney> i never see the oops is gone with 501 kernel
[13:30] <cwillu_at_work> never delete KERNEL, and only clone it if it doesn't exist already.  Then, before checking out a given version, we reset the working copy (which doesn't delete the partial files, so compilation will be quicker if appropriate), and then delete whichever branch we're about to create if necessary
[13:30] <rsalveti> sometimes it does work
[13:30] <rcn-ee> cool cwillu_at_work yeah the patch looks pretty clean and get what your doing.....  yeah it's indentation sucks big time, (damn editor)..
[13:31] <cooloney> rsalveti: i still think we need to build in the modules and config the port as OTG
[13:31] <cwillu_at_work> what editor are you using?
[13:31] <cooloney> rsalveti: currently, we just config it as host
[13:31] <cooloney> not OTG
[13:31] <rcn-ee> gedit and my left pinky... so it's mostly me to blaim.. ;)
[13:31] <cwillu_at_work> gedit isn't that bad Lo
[13:31] <cwillu_at_work> :p
[13:31] <cwillu_at_work> I do have some sanity plugins for it though
[13:32] <cwillu_at_work> (hippy text completion, incremental search improvements, an interesting take on code folding (which is a bit crashy), automatic session save and restore, etc
[13:34] <cwillu_at_work> (the code folding hide everything except for lines containing the word under the cursor, or the selected text, or the currently searched-for text
[13:34] <tmzt> folding?
[13:34] <cwillu_at_work> hides, rather
[13:35] <tmzt> oh, not like msvs
[13:35] <cwillu_at_work> tmzt, that's traditional code folding
[13:35] <cwillu_at_work> which I never had much use for
[13:41] <rsalveti> cooloney: oh, ok
[13:42] <rcn-ee> it's scary some questions people ask for their thesis work.. ;)
[13:51] <cwillu_at_work> I think I hate quilt
[13:52] <hrw> quilt is nice
[13:52] <cwillu_at_work> yes, but how the hell do you set it up the first time?
[13:52] <cwillu_at_work> it's not putting patches into debian/patches, and quilt setup doesn't have any place to say where I want them
[13:57] <hrw> QUILT_PATCHES=$PWD/debian/patches ?
[13:57] <hrw> and xport it
[14:00] <persia> There's a lovely little .quitrc in /usr/share/doc/quilt that automates that bit.
[14:00] <cwillu_at_work> so a quilt'ed source package still requires a random environmen...
[14:00] <cwillu_at_work> it'd be nice if that was documented in dpkg-source :p
[14:00] <hrw> cwillu_at_work: do I force you to use quilt? patch is easy to use...
[14:01] <cwillu_at_work> hrw, I need an old inkscape version compiled for arm, and although there's no patch or series set up, it's complaining
[14:01]  * cwillu_at_work continues grumbling
[14:02] <cwillu_at_work> but if I understand correctly, a quilt'd source package doesn't actually work with quilt until you've set that environment variable?
[14:03] <hrw> I assume "dpkg-source -x package.dsc; cd package-*;debuild -b"
[14:04] <cwillu_at_work> dpkg-buildpackage you mean? :p
[14:04] <hrw> prefer debuild as it keeps build log for me
[14:05] <hrw> unless I need to pass env vars which debuild clears
[14:05] <cwillu_at_work> and you should be able to quilt new <patch>; quilt edit <file>; dpkg-buildpackage, and not have to quilt pop -f?
[14:06] <cwillu_at_work> was complaining about the patch (that it just made) not unapplying cleanly
[14:06] <cwillu_at_work> which is inane, but probably my fault
[14:07] <cwillu_at_work> grumble?
[14:13] <ogra> cwillu_at_work, https://wiki.ubuntu.com/PackagingGuide/PatchSystems
[14:13] <cooloney> rsalveti: i boot once without the oops and usb mouse + usb hub + external power works.
[14:13] <rsalveti> cooloney: yeah, that happens sometimes
[14:17] <rsalveti> rcn-ee: do you know why you're applying the fifo-mode patch for musb?
[14:18] <rsalveti> changing the fifo mode
[14:25] <cwillu_at_work> ogra, thanks;  it looks like the source of my grief is that the source package was slightly malformed
[14:41] <cooloney> rsalveti: i am building a kernel which enable the debug in musb otg driver
[14:41] <rsalveti> cooloney: ok
[14:41] <rsalveti> that can help
[14:55] <lag> hrw: Are you still about?
[14:56] <hrw> lag: Chopin/Linaro room
[14:58] <lag> hrw: My hardware is plugged in :)
[14:58] <hrw> few minutes ok?
[14:59] <hrw> lag: sakoman_ is present in #pandaboard
[15:00] <lag> I saw
[17:56] <hrw> re
[18:57] <rcn-ee> rsalveti, errata.. the omap34/omap35 musb memory is actually 4kb not 8kb which is what fifo=4 is setup for.. bug check: transfer 2GB from two high speed devices on the musb bus (harddrive, eth) and run md5sum, they'll mismatch..  last i heard the musb guys were going to apply the fifo based on board-device.c
[18:58] <rcn-ee> but right now it isn't a per device setting and just a global one..
[18:58] <rsalveti> rcn-ee: oh, ok, makes sense now
[18:58] <rsalveti> cool, thanks
[18:58] <rcn-ee> we ran into more often in the bx days.. but with good ehci ports no one notices it any more.. ;)
[18:59] <rsalveti> rcn-ee: I'm also looking at the micrel and zippy patches, do you know if any of those are proposed upstream already?
[18:59] <rsalveti> or you're just basically maintaining at your patch tree
[18:59] <rsalveti> rcn-ee: nice to know, going to test it here
[18:59] <rcn-ee> they are atleast from micrel, but the netdev maintainers keep shooting them down.. ;)
[18:59] <rsalveti> trying to make the otg port to work with default ubuntu kernel
[19:00] <rsalveti> don't know why it's not working correctly
[19:00] <rcn-ee> i just keep forward porting and testing them on my self (since we sell zippy boards at digikey)
[19:00] <rsalveti> rcn-ee: haha, ok :-)
[19:00] <rcn-ee> i still think it's a config issue. take a look at my defconfig, i'm running bx's with usb hardrives on the musb port...
[19:01] <rsalveti> rcn-ee: yep, that's what I'm checking now
[19:01] <rsalveti> just installed your latest kernel and it worked fine
[19:03] <rcn-ee> good to hear, i try to keep it pretty in sync with ubuntu's config options just to keep me 'sane'... but main things i'm currently working on dspbridge and panda integration in the same kernel..
[19:04] <hrw> igep suxx
[19:04] <rsalveti> hrw: why? :-)
[19:04] <rcn-ee> yeah why, it's slightly faster then my C4 board at gcc bootstrap? ;)
[19:05] <hrw> the one which steve brought has something with mmc - but some of you already know that
[19:09] <armin76> hrw: i can talk bad about a beagle which hanged from time to time :)
[19:09] <hrw> armin76: beagle or beagleboard?
[19:09] <armin76> beagleboard
[19:10] <armin76> is there a beagle?
[19:11] <hrw> there was
[19:11] <hrw> few years ago netherlands company had a linuxpda with that name
[19:11] <hrw> never got to the market but was shown in few places and was supported in openembedded
[19:12] <rcn-ee> rsalveti, one note on the micrel patches too..  Wireing up with the buddy= variable most of that came from Koen, it works quite well for detecting the zippy1/2 boards on boot and loading the correct drivers.  I'm working with someone too add an 'lcd' module and will use a simlar setup..
[19:12] <rcn-ee> none of that is upstream, so who knows if it'll be excepted..
[19:13] <rsalveti> rcn-ee: yep, also just noticed that
[19:13] <rsalveti> first time I get a zippy on my hands
[19:13] <rcn-ee> it makes a prety big mess of beagle.c file. ;)
[19:13] <rsalveti> zippy2
[19:13] <rsalveti> :-)
[19:13] <rcn-ee> they are actually 100% identical except the eth spi device..
[19:14] <rsalveti> yep, but you need the correct id in order to load the correct driver
[19:14] <hrw> [   42.668029] mmci-omap-hs mmci-omap-hs.0: Failed to get debounce clock
[19:14] <hrw> [   42.781280] mmci-omap-hs mmci-omap-hs.1: Failed to get debounce clock
[19:14] <rcn-ee> yeap, and the first big shipment of zippy2's we got in march? had the zippy1 setting on the i2c bus. ;)
[19:15] <rcn-ee> it's simple to reprogram, but it's faq #1 on them..
[19:15] <rsalveti> rcn-ee: hehe, mine also seems to be with the wrong id
[19:15] <rsalveti> yep
[19:15] <ssvb> hrw: but at least it is probably not igepv2 design defect, but just one broken board? unlike USB on beagleboards older than rev C4...
[19:16] <rcn-ee> till you reprogram it, just force buddy=zippy2 in your boot.scr
[19:16] <rsalveti> rcn-ee: do I need any jumper to disable the write protection?
[19:17] <hrw> ssvb: yep
[19:17] <rcn-ee> yeap.. (crap i need one at home)
[19:17] <hrw> ssvb: my c3 bb works quite good with extra capacitor added
[19:19]  * cwillu perks up
[19:20] <rcn-ee> cwillu, your patch works good, defintelly speeds it up. now i can't get my coffee. ;)
[19:21] <cwillu> :)
[19:21] <rsalveti> rcn-ee: hm, jp 1
[19:22] <cwillu> ya, I was actually shocked how much faster the system was even shortly after a reboot
[19:22] <rsalveti> needs to find a jumper around
[19:22] <cwillu> rsalveti, yes
[19:22] <cwillu> I just use an alligator clip
[19:22] <rcn-ee> steal it from one of the freescale boards, they always have extras.. ;)
[19:22] <rsalveti> yeah, will try to find something to connect the pins :-)
[19:22] <rsalveti> oh, good idea :-)
[19:22] <cwillu> rcn-ee, my rootstock image programs x-load/u-boot to nand, updates the eeprom if it hasn't been already, and a few other odds and ends automatically :)
[19:23] <cwillu> I can go from source to a burned sd card, and then booting a beagle and programming the zippy and such under 30 minutes :)
[19:23] <cwillu> it's been a good week :)
[19:23] <rcn-ee> yeah, i think it would be a good idea to put up a eeprom script for new zippy2 owners..
[19:24] <cwillu> sec, let me grab it
[19:24] <cwillu> it's a single upstart job
[19:24] <rsalveti> it'd help a lot, for sure
[19:24] <cwillu> it'll try each boot until it succeeds
[19:24] <rcn-ee> that might be overkill..  if your zippy2 is detected as a zippy1 run this script
[19:25] <cwillu> rsalveti, rcn-ee, fixups.conf
[19:25] <cwillu> fixups.conf
[19:25] <cwillu> ...
[19:25] <cwillu> http://pastebin.com/FjyjvdSN
[19:25] <cwillu> middle click wasn't working :p
[19:26] <cwillu> that's basically all the upstart script is anyway
[19:26] <hrw> ok, one hour passed - igep goes back to the box
[19:26]  * hrw -> movie
[19:27] <rcn-ee> yeap that script looks good and will do it..
[19:27] <cwillu> rcn-ee, there was a cool looking auto-edid patch that I want to experiment when I get back too
[19:27] <cwillu> i.e., detecting monitor resolution at boot
[19:27] <cwillu> here's a question:  how long does it usually take rootstock to run?
[19:28] <rcn-ee> that would be very useful, i've thought of it a couple times, the drm layers has all the good edid stuff nowdays..
[19:28] <rcn-ee> it locks up for me in 25 minutes (maverick alpha-2+) at ldconfig or somethign
[19:28] <cwillu> heh
[19:28] <cwillu> you guys are still on a full qemu vm?
[19:29] <rcn-ee> that one yes.. otherwise 3-4hours on my beagle..
[19:29] <cwillu> I really should figure out who needs which patches :)
[19:29] <cwillu> rcn-ee, I have a finished image in 21 minutes
[19:29] <rsalveti> cwillu: I'll try to change it to use full vm just for user
[19:29] <rsalveti> as root you can easily do most of the steps on user mode emulation
[19:29] <rcn-ee> i still tar it up, which kills the poor beagle..
[19:29] <rsalveti> as you're doing it already
[19:29] <cwillu> yep
[19:29] <rsalveti> just have to find some time during this week
[19:30] <rsalveti> will also try to push the native rootstock stuff
[19:30] <rsalveti> to run it at an arm board
[19:30] <cwillu> I'm just outputting a tarball;  I have separate mkcard script which actually writes the image / creates an image file if desired
[19:30] <rcn-ee> btw, just resynced my rootstock on arm patch on top of rootstrock trunk: http://bazaar.launchpad.net/~beagleboard-kernel/+junk/image-builder/annotate/head:/patches/native-arm.diff
[19:30] <cwillu> I'm going to be out of town till friday, but then I'm hoping to take some time off
[19:31] <rsalveti> rcn-ee: nice, will take a look at it later
[19:31] <lapada> hi, my keyboard  and mouse drivers are not loading so i can not operate, can any one please tell me what could be the issue..?
[19:31] <rsalveti> I'm at prague, so most of the time we're just discussing and debugging stuff, hard to find time for real coding
[19:31] <rcn-ee> i haven't tested it yet, that node has been building kernels, but it's a forward port of my previous stuff.
[19:31] <cwillu> lapada, 2.6.35 kernel?
[19:32] <cwillu> lapada, you're missing a patch, and you actually don't have _anything_ that uses modules
[19:32] <lapada> dont know
[19:32] <cwillu> lapada, easiest answer would be to drop back to 2.6.34, or to use the very latest rcn kernel
[19:32] <cwillu> or it might be something else entirely :p
[19:32] <lapada> it is from the image of ubuntu site
[19:32] <rsalveti> rcn-ee: yep, just changed the config file and the musb is now working beautifully
[19:32] <lapada> lucid 10.0.4
[19:32] <cwillu> ah, no idea then :p
[19:33] <rcn-ee> rsalveti, good to here.
[19:33] <rsalveti> rcn-ee: but will probably have the fifo bug, will also test that later
[19:34] <lapada> I am following this procedure https://wiki.ubuntu.com/ARM/BeagleNetbookInstall
[19:34] <rcn-ee> rsalveti, for the fifo bug you can use this for justification.. http://www.spinics.net/lists/linux-omap/msg29025.html
[19:34] <lapada> but when in installer screen no keyboard nor mouse responds
[19:35] <rcn-ee> actually this one is the original. (it was tweaked in that last post) http://www.spinics.net/lists/linux-usb/msg25777.html
[19:35] <cwillu> lapada, what version of the beagle?
[19:35] <cwillu> and which usb port are you using?
[19:35] <lapada> rev c4
[19:35] <cwillu> and the ehci port (the big one) or musb (the small one next to the power cable)
[19:35] <cwillu> ?
[19:35] <rsalveti> rcn-ee: nice, thanks a lot
[19:36] <lapada> the big one
[19:36] <rcn-ee> yeap no problem, personally fought that bug for a good 3-4 months.. (i think i was the first to run big harddrives and ethernet adapters on the original bx's)
[19:36] <lapada> with a hub connected
[19:38] <cwillu> not sure, sorry
[19:39] <rcn-ee> lapada, is it a powered usb2.0 hub? does it help if you unplug and replug?
[19:39] <rsalveti> hm, hungry, will try to get something to eat around and will be back soon
[19:39] <cwillu> sleepy, back in a few days :p
[19:39] <lapada> it is not a powered hub, but the power source of beagleboard can handle
[19:40] <lapada> and besides already used the same hub with android distribution
[19:40] <rcn-ee> ehh.. lapada back in the 2.6.29 days which is what most android for beagle uses, it kinda worked...  but wasn't suppost to..  i'd really get a powerd hub...
[19:42] <lapada> ok, I think I can get one
[19:42] <lapada> but, any other idea if the problem isnt the hub?
[22:14] <lapada> one little doubt
[22:34] <lapada> after installing ubuntu lucid on beagleboard, after complete 100%, I get just a purple screen, after waiting a while I removed the sd card and booted the bb, but no ubuntu at all!!!!!!!!
[22:35] <lapada> I receive the message:       ERROR: can't get kernel image!
[22:35] <lapada> what should I do?
[22:36] <rsalveti> lapada: how did you actually install it?
[22:38] <lapada> form the ubuntu site I used the ubuntu-10.04-netbook-armel+omap.img
[22:39] <hrw> netbook image on normal beagleboard? insane
[22:39] <lapada> used the image writer to write to the sd card
[22:40] <lapada> boot the beagleboard with the sd card and complete the installation of ubuntu 10.0.4
[22:40] <lapada> https://wiki.ubuntu.com/ARM/Beagle
[22:41] <lapada> the problem is I completed the installation, till finish 100%
[22:42] <rsalveti> hm, didn't try lucid myself but GrueMaster tested a lot, for sure
[22:42] <lapada> but when restarting beagleboard it says https://wiki.ubuntu.com/ARM/Beagle
[22:42] <lapada> ops
[22:42] <lapada> but when restarting beagleboard it says ERROR: can't get kernel image!
[22:43] <rsalveti> it should just put the uImage and uInitrd on nand, set the boot.scr and reboot it
[22:43] <rsalveti> lapada: when do you get this error, at the bootloader?
[22:43] <lapada> yes
[22:43] <rsalveti> it could be that your uboot is not reading the boot.scr, for some reason
[22:44] <rsalveti> lapada: can you paste the full uboot log for me?
[22:44] <lapada> I will try
[22:44] <rsalveti> hrw: I'm testing maverick on a c4 and it's working quite well actually
[22:44] <rsalveti> lots of bugs still, but getting better
[22:44] <rsalveti> bootchart is installed by default, so the boot is slower than it should
[22:46] <lapada>     NAND read: device 0 offset 0x280000, size 0x400000                                4194304 bytes read: OK                                                          Wrong Image Format for bootm command                                             ERROR: can't get kernel image!
[22:47] <lapada> the ubuntu is installed in the usb pen drive
[22:47] <rsalveti> try to get at the bootloader (just press any button while booting) and run the following commands:
[22:47] <rsalveti> mmc init
[22:48] <rsalveti> fatload mmc 0 0x82000000 boot.scr
[22:48] <rsalveti> source 0x82000000
[22:51] <lapada> ubuntu is booting
[22:51] <lapada> but I guess it is the installer..
[22:52] <lapada> yep, the installer again
[22:52] <lapada> isn't booting by
[22:53] <lapada> isn't booting by usb
[22:53] <rsalveti> lapada: just remove your sd card, see if it works
[22:53] <rsalveti> if you installed it at the usb, than it should boot fine
[22:54] <lapada> but it is NOT!!!!
[22:56] <lapada> No MMC card found
[22:56] <lapada> Booting from nand ...
[22:56] <lapada> NAND read: device 0 offset 0x280000, size 0x400000
[22:56] <lapada>  4194304 bytes read: OK
[22:57] <lapada> Wrong Image Format for bootm command
[22:57] <lapada> thats it
[22:57] <lapada> ERROR: can't get kernel image!
[22:58] <rsalveti> it seems that your uboot env is loading the script as it should, and if when loading it, for some reason it's probably setting the root partition to /dev/mmcblk0p2 instead of the usb one
[22:58] <rsalveti> *is not
[22:58] <rsalveti> I should get some sleep :-)
[22:59] <lapada> it makes sense
[22:59] <lapada> how can I change this?
[23:00] <lapada> pls dont sleep
[23:00] <rsalveti> lapada: to change the uboot env you just need to set up the correct arguments, or flashing/updating it to have the default behavior
[23:00] <rsalveti> now to change the boot.scr you'd need access to the nand partition
[23:01] <rsalveti> you can try to set up the bootargs by hand and try to booting the rootfs from your usb
[23:01] <rsalveti> and after booting it, you can mount the nand partition and fix the boot.scr by hand
[23:02] <rsalveti> fatload mmc 0:1 0x80000000 uImage
[23:02] <rsalveti> fatload mmc 0:1 0x81600000 uInitrd
[23:02] <rsalveti> setenv bootargs  ro elevator=noop vram=12M omapfb.mode=dvi:1280x720MR-16@60 root=/dev/sda1 fixrtc console=ttyS2,115200n8
[23:02] <rsalveti> bootm 0x80000000 0x81600000
[23:03] <rsalveti> lapada: try this after pressing some button and getting into the uboot command line
[23:06] <lapada> i'm back
 I should get some sleep :-)
[23:06] <pcacjr_> i'm sure you should
[23:06] <lapada> waaaaaaaait
[23:06] <lapada> I was disconnected
[23:07] <lapada> can you send those commands again
[23:07] <lapada> fatload...
[23:07] <pcacjr_> fatload mmc 0:1 0x80000000 uImage
[23:07] <pcacjr_> atload mmc 0:1 0x81600000 uInitrd
[23:07] <pcacjr_>  setenv bootargs  ro elevator=noop vram=12M omapfb.mode=dvi:1280x720MR-16@60 root=/dev/sda1 fixrtc console=ttyS2,115200n8
[23:07] <pcacjr_> bootm 0x80000000 0x81600000
[23:07] <pcacjr_> enjoy
[23:08] <rsalveti> yep, but actually this should try to load from the first sd partition, and not nand
[23:08] <rsalveti> for lucid the kernel should be in nand, just maverick that gets it installed at the sd card
[23:09] <pcacjr_> rsalveti, then he should change to the proper partition
[23:09] <rsalveti> argh, need to get this boot.scr from lucid
[23:10] <pcacjr_> would it be /dev/mmcblk0px ?
[23:10] <rsalveti> pcacjr_: this is for the sd, on linux
[23:10] <rsalveti> but he first needs to load the uImage and uInitrd from nand, put it on memory, setup the correct arguments and load the images
[23:10]  * pcacjr_ nods
[23:10] <rsalveti> so he can actually boot the board
[23:10] <pcacjr_> i see
[23:11] <lapada> probably
[23:11] <pcacjr_> so would he have the rootfs on eMMC ?
[23:12] <rsalveti> let me check the flash-kernel package from lucid
[23:12] <rsalveti> pcacjr: on usb
[23:12] <lapada> and now I go sleep
[23:12] <lapada> thanks all
[23:13] <pcacjr_> lapada, cya
[23:13] <pcacjr_> rsalveti, ok