[00:10] <ogra_cmpc> GrueMaster, only if a miracle happens and oem-config gets installable
[00:10] <ogra_cmpc> we now fail on oem-config/ubiquity
[00:10] <GrueMaster> heh.  Figures.
[00:11] <ogra_cmpc> but at least all header issues are fixed
[00:13] <ogra_cmpc> anyway, bedtime
[00:15] <GrueMaster> g'night
[00:29] <lag``> 'ello
[00:29] <lag``> ogra: You should really get out more
[07:53] <rsalveti> cooloney: nice, were you able to build the kernel with highmem and 1gb at your es2 board?
[07:54] <rsalveti> sebjan: http://kernel.ubuntu.com/git?p=roc/ubuntu-maverick.git;a=commit;h=68e4544fcd736e6aa00354da15dd48a92c15750c
[07:54] <rsalveti> didn't test, but it seems cooloney got it working fine
[08:05] <cooloney> rsalveti: i'm going to test it soon, but you know it will take hours
[08:06] <rsalveti> cooloney: but at least it seems we have a fix
[08:06] <rsalveti> ndec: http://lkml.org/lkml/2010/9/8/425
[08:23] <rsalveti> well, time to get some sleep
[08:23]  * rsalveti out
[08:27] <acorvil> Hello.. am new around here.. I am working on cross-compiling an application to ARM enviroment, so I was wondering if someone can help me with some doubts around it?
[08:28] <persia> Better to ask a specific question, generally.  In practice, we don't cross-compile as a matter of course, but some subset of us cross-compile for other projects.
[08:31] <acorvil> Well the thing is this.. am trying to cross-compile and application that uses the library "libusb", but when I try to do it it gives me errors that doesn't find the library.. So I checked the toolchain and it doesnt have the libusb packages, so I was wondering on How to add the library into the toolchain, and if that would fix the error?
[08:35] <hrw> morning
[08:46] <sebjan> cooloney: is this patch supposed to fix the instabilities we observed with highmem? #633227
[08:47] <cooloney> sebjan: yeah, i hope so
[08:48] <cooloney> sebjan: it is quite slow for me to setup the building environment on my es2.0, ports.ubuntu.com connection here is too slow
[08:48] <cooloney> sebjan: so please help to test on your es2.0 firstly, thx
[08:48] <sebjan> ok, I'll make a test with it then
[08:48] <cooloney> sebjan: great, thx
[08:55] <persia> acorvil, Apologies, but it seems that nobody has the answer just now.  Have you tried native or emulated compilation?  In either case, simply installing libusb-dev ought allow the build to proceed.
[08:59] <sebjan> cooloney, ogra: in one of my last patches, I changed the HID support to be in module (instead of statically linked). So without the kernel modules, there is no mouse/keyboard support...
[08:59] <sebjan> would it be easier to re-integrate HID support statically?
[09:02] <acorvil> persia, yeah I already have the libusb-dev installed in my host PC, so if I try native compilation it goes well.. The thing is if I cross-compile it that doesnt find the library
[09:02] <acorvil> I was guessing that the library most be into the toolchain so the cross-compiler can find it.. but I dont know how to get it into the toolchain
[09:03] <ogra> sebjan, our initramfs tools should care automatically to have the modules available. compiling them in statically might be a speed advantage though
[09:03] <persia> You'd need to have the ARM libusb-dev installed.  If you're native ARM, or emulated, it would just be a normal package.  I've absolutely no idea how to integrate it in a cross-compiler.
[09:03] <cooloney> sebjan: CONFIG_USB_HID=m is the same in master branch
[09:04] <persia> If possible, please set modules to match those for the primary kernel: we've had all sorts of annoying ports bugs in the past for different things being modules vs. built-ins
[09:04] <cooloney> sebjan: so i think udev or other foundations stuff in ubuntu will load right modules when we insert the usb device
[09:04] <cooloney> persia: yeah, i agree
[09:05]  * persia has a special desire to see mod_dm has a built-in, for instance, which doesn't seem required for some targets, but breaks boots if not done that way
[09:05]  * ogra wouldnt mind to have some essential things statically compiled in since it lowers the boot tima
[09:05] <ogra> *time
[09:05] <sebjan> cooloney: yes, the modules get loaded and the mouse/keyboard work this way. I was just wondering if it would be easier to have HID statically in case we want to just update the ui
[09:06] <sebjan> cooloney: ... just update the uImage without installing the whole kernel package...
[09:06] <ogra> oh, sweet, we finally got images again
[09:07]  * ogra zsyncs
[09:09] <persia> ogra, The kernel team spends a long time each cycle determining the set of stuff to do statically and modularly, and then lots of userspace stuff expects that.  We've had ports breakages before on both sides (stuff compiled in that oughtn't be, and so didn't initialise properly, and stuff as modules that oughtn't be that broke booting for some folks)
[09:09] <ogra> cooloney, did anyone talk to you about bug 605042 yet ? seems we need an imx51 kernel specialist there
[09:09] <persia> I agree that more in makes faster boots which is nifty, but I strongly argue that this needs to be coordinated with everyone.
[09:10] <ubot2> ogra: Bug 605042 on http://launchpad.net/bugs/605042 is private
[09:10] <cooloney> sebjan: as persia said, normally we will do that config review during UDS
[09:10] <ogra> persia, Keybuk does that too and often there is disagreement, i'm most of the time in the Keybuk camp ;)
[09:10] <cooloney> sebjan: and omap4 branch will be merged into master in the future, we gonna follow the config setting of master
[09:10] <cooloney> ogra: yeah, apw pointed me out that kindly
[09:11] <persia> I'm in the Keybuk camp, based on long arguments about lucid not working on some of my machines.  The kernels *need* to be aligned.
[09:11] <cooloney> ogra: i talked with Yao Qi last night.
[09:11] <persia> So don't tell folks to fuss with them :)
[09:11] <ogra> cooloney, got any idea about it ?
[09:11] <acorvil> persia, Thanks for your answers am going to see if getting the ARM libusb-dev installed and see if it fix the error
[09:11] <cooloney> ogra: just wanna isolate the issues,
[09:11] <ogra> sweet !!
[09:11] <cooloney> ogra: As Yao Qi said, he found the issue on imx51 with 2.6.31 kernel
[09:12] <cooloney> while other 2 omap3 boards with 2.6.33 kernel don't have such issue
[09:12] <ogra> cooloney, right which is what we run on the buildds
[09:12] <cooloney> ogra: i wanna know the root cause is the kernel version 2.6.31 misses some key patches which are in 2.6.33
[09:13] <cooloney> or it's imx51 specific issue.
[09:13] <ogra> ah
[09:13] <ogra> yeah, could be either
[09:13] <cooloney> but unforunately, i don't have fsl-imx51 babbage now
[09:13] <cooloney> mine is bricked,
[09:13] <sebjan> ogra, persia, cooloney: ok, I wanted to get your advice on this HID setting. Will follow your recommendation - let's keep the current configuration.
[09:13] <ogra> yeah, i have a 2.5 here and could test
[09:14] <sebjan> cooloney: my memtester test is running for few minutes now (with your patch), which I have never seen before with 1GB mem!
[09:14] <cooloney> ogra: thanks a lot, so i think is that possible for you to run upstream 2.6.35 or 2.6.33+ kernel to test that.
[09:15] <cooloney> sebjan: good news, man
[09:15] <cooloney> sebjan: actually, it is a very subtle issue, Gary King from NV helped a lot
[09:17] <cooloney> ogra: or do you have fsl contact person who can help to test with their lastest bsp on imx51?
[09:17] <ogra> cooloney, not anymore ...
[09:17] <ogra> cooloney, but i know the upstream maintainer *g*
[09:17]  * ogra looks at amitk 
[09:18] <tmzt_> anybody know if ac100 source was released anywhere?
[09:20] <persia> tmzt_, I've not heard, and I've asked in a few fora.  Might help if someone made a request (if this hasn't already been done).
[09:20] <ogra> tmzt_, i tried to find out on the weekend, but beyond the tegra2 stuff you can pull directly from nvidia there doesnt seem to be anything yet
[09:20] <tmzt_> okay, I don't have hardware or anything
[09:20] <cooloney> ogra: let's welcome amitk, heh
[09:20] <persia> Does anyone own one yet?  I've heard lots of folks say they are hard to find.
[09:20] <tmzt_> I just hope they make enough before market forces kill it
[09:20] <ogra> and its a) not really clear if you can even get serial access to the netbook
[09:20] <persia> serial access may not be required.
[09:21] <cooloney> ogra: so i can try to rebase fsl's latest 2.6.31 based bsp on our lucid kernel
[09:21] <ogra> and b) i doubt all toshiba patches are in the nvidia source
[09:21] <cooloney> and build a kernel for you to test.
[09:21] <tmzt_> I bet they have a EC in it that needs special support
[09:21] <ogra> cooloney, well, i'd like to hear a statement from amitk about the linaro binaries, they build imx51 already, if we could use that without regression for the buildds that would be the best solution
[09:22] <persia> Let's not speculate.  Source will be available if anyone purchases one (nature of the license).  It purportedly ships with an OS that (for some configurations) allows one to rewrite the flash.
[09:22] <ogra> tmzt_, the LCD probably too
[09:22] <tmzt_> that's good
[09:22] <tmzt_> ogra: not ion/nv lcdc?
[09:22] <persia> Better to assume that it will be all good, and we can work around anything confusing later.
[09:22] <cooloney> ogra: yeah, good point
[09:22] <ogra> persia, i saw the unboxing videos, there isnt any CD in the box
[09:22] <persia> ion'd be no issue: we have working free drivers for ion.
[09:22] <tmzt_> how do you define free here?
[09:22] <persia> ogra, So what?  If you own it, you can request the source.
[09:23] <ogra> tmzt_, well, as persia says, i'm only speculating, they sell ac100 around the corner here and i took a look on the weekend, it didnt look easy to unlock it
[09:23] <persia> tmzt_, Mostly DFSG+CC-SA2.0+GFDL+a couple other similar licenses.
[09:23] <ogra> persia, the graphics drivers are definitely closed (even the ones you can download from the tegra site are)
[09:24] <persia> ogra, unlocking Android isn't often complicated.
[09:24] <ogra> if you get serial access, yeah
[09:24] <tmzt_> persia: you saying there's an open 3d driver or just framebuffer?
[09:24] <persia> That's why I'd like it to be Ion.  Run nouveau (which builds for ARM: dunno how tested it is)
[09:24] <tmzt_> ah right
[09:24] <persia> tmzt_, I run nouveau on an Ion on my desktop.
[09:24] <tmzt_> cool, does that work for video playback as well?
[09:24] <amitk> ogra: cooloney: I'm trying to get linaro to build imx51 images
[09:24] <ogra> there is only one otg port and that registers as a cardreader on a host PC immediately after powering up
[09:25] <persia> 3D works (although I won't say it's *great* - some games are good, others not so good.  Videos are fine.
[09:25] <ogra> amitk, i think you already build them (i see them mentioned in the recent upload)
[09:25] <tmzt_> ogra: so firmware flash can be confirmed (essentially)?
[09:25] <amitk> ogra: we build the kernels, the images were only discussed yesterday (dunno if asac already did them)
[09:26] <ogra> tmzt_, it registers as a cardreader for the SD slot, i didnt see a way to access serial or any flash mode
[09:26] <tmzt_> oh okay
[09:26] <ogra> amitk, i dont care about images, just about binary kernel packages
[09:26] <cooloney> amitk: is the linaro kernel 2.6.31 based? or mainline version?
[09:26] <tmzt_> that sounds like what android provides
[09:26] <ogra> cooloney, linaro only uses upstream
[09:26] <ogra> thats why i said "lets see if there are regressions)
[09:26] <amitk> ogra: but as I commented on the bug, if all you need is serial + ethernet, then we might be able to support that
[09:27] <amitk> cooloney: 2.6.31?!! yeeeccccck!
[09:27] <ogra> amitk, we need USB at least
[09:27] <persia> Android allows one to write to flash from the booted system (as does linux).  Not really hard to change what happens on boot.
[09:27] <amitk> ogra: there is USB support too, but I haven't tested it all
[09:27] <ogra> persia, that requires that you can install apps to access it
[09:27] <ogra> persia, toshiba controls the appstore for the device
[09:27] <tmzt_> persia: if the android image allows root, this has been contenious in #android since the g1 was relased
[09:27] <ogra> there is no access to the android stor
[09:27] <persia> ogra, There exist Android devices to which you cannot install applications?  I thought that installing apps was the entire point of Android.
[09:28] <tmzt_> but mostly I'm wanting to replace kernel and remove android entirely
[09:28] <ogra> you can install apps, but only toshiba selected ones
[09:28]  * persia gets confused, and tries to go back to ignoring Android
[09:28] <ogra> persia, in android you cen define which appstore the device uses ...
[09:28] <tmzt_> persia: only some AT&T models, the issue isn't applications (java code in euid/egid sandbox) but the kernel and firmware themselves
[09:28] <ogra> as a manufacturer
[09:28] <tmzt_> persia: local apk install is almost always supported
[09:29] <ogra> apk requires a console, no ?
[09:29] <tmzt_> no, adb works as well
[09:29] <ogra> there is none preinstalled and i dont know if the toshiba store has one
[09:29] <tmzt_> usually has to be enabled in settings
[09:29] <ogra> ah
[09:29] <tmzt_> the review I read mentioned 'sideloading' a wordpress client
[09:30] <ogra> if i wouldnt be so busy with omap4 i'd really buy an ac100 just to find out
[09:30] <tmzt_> point though, very thin full size keyboard debian/ubuntu/linaro device
[09:30] <ogra> but i'm short on play-around-time currently
[09:30] <tmzt_> and 3g options available
[09:30] <ogra> the one here only comes with 3G
[09:31] <ogra> 1€ with contract, 380€ without
[09:31] <cooloney> amitk: cool, is that possible to verify such issue with Linaro upstream based kernel
[09:32] <amitk> cooloney: do you have an easy way to reproduce the problem?
[09:32] <ogra> cooloney, i just need to dpkg -i it i guess
[09:32] <ogra> amitk, bug 605042
[09:33] <ubot2> ogra: Bug 605042 on http://launchpad.net/bugs/605042 is private
[09:33] <ogra> seems a simple "java -version" shows it
[09:37] <tmzt_> okay, I need to go, I'd love to be updated on ac100 if you guys find anything (or get one)
[09:42] <cooloney> amitk: yeah, Yao Qi told me that we have to apt-get install eglibc and open-jdk package
[09:42] <cooloney> and run java --version
[09:44] <sebjan> cooloney: your patch solves the memtester issue, but not the problems during the build: I just reproduced it. So we still have another issue...
[09:45] <cooloney> sebjan: oh, is the memtester issue in launchpad?
[09:46]  * cooloney just found launchpad is down
[09:47] <sebjan> cooloney: I flagged 1 bug and described both tests: bug 633227
[09:47] <ubot2> sebjan: Bug 633227 on http://launchpad.net/bugs/633227 is private
[09:48] <ogra> ndec, http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100909/ works fine on my ES2 6 layer, please spread the word at your team ;) (didnt test on 8 layer yet)
[09:57] <ogra> persia, wuld you like to work on Bug 613612 ?
[09:57] <ubot2> ogra: Bug 613612 on http://launchpad.net/bugs/613612 is private
[09:57] <ogra> (i know you tackled that issue before)
[09:58] <ogra> bah, silly launchpad ...
[09:58] <ogra> being down doesnt help
[09:58] <ogra> title is "Favorites missing from netbook-launcher-efl"
[10:04] <ogra> wohoo !
[10:04] <ogra> 8 layer ES2 works too !
[10:05] <persia> Yeah, that's in my list of things to look at, although something like 4th or 5th place in the list of bugs I'd like to fix for ARM.
[10:14]  * ogra_omap4 hugs his ES2.0
[10:14] <ndec> ogra: i like this ;-)
[10:15] <ogra_omap4> strangely the screen turns black from time to time
[10:16] <ogra_omap4> i have to switch consoles to get my X back
[10:16] <ogra_omap4> [  650.169860] omapdss DISPC error: GFX_FIFO_UNDERFLOW, disabling GFX
[10:16] <ogra_omap4> [  650.219543] omapdss DISPC error: SYNC_LOST_DIGIT
[10:16] <ogra_omap4> aha
[10:16] <oskude> hello, anyone know (yet) if this can run/boot ubuntu ? http://www.archos.com/products/ta/archos_101it/specs.html?country=gb&lang=en (and if there are drivers for the wlan, opengl, etc)
[10:17] <ogra_omap4> and the asoc driver complains a lot in dmesg
[10:18] <ogra_omap4> oskude, if you find a kernel, the ubuntu userspace will likely work
[10:18] <ogra_omap4> check the channel topic for rolling a rootfs
[10:18] <oskude> ogra_omap4: roger. i might just mail them and ask (the device is not yet available, at least not in my country)
[12:32] <ogra_cmpc> NCommander, http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-live/20100909/ FYI
[12:42] <NCommander> WIN!
[12:43] <ogra_cmpc> we should probably enable it in the crontab again :)
[12:43] <ogra_cmpc> semms colin disabled it during beta
[12:44] <NCommander> ogra_cmpc: yeah, that probably would be good
[12:45] <ogra_cmpc> NCommander, is the menifest wikipage alredy updated ?
[12:46] <ogra_cmpc> for dove
[12:48] <persia> manifest
[12:49] <ogra_cmpc> festiman ?
[12:49] <persia> festiVAL
[12:49] <ogra_cmpc> PARTY !!!
[12:49] <persia> Yep :)
[12:49] <ogra_cmpc> heh
[13:39] <ogra> sigh, the XM takes a century to boot
[13:52] <mopdenacker> ogra: do you mean that Ubuntu takes a century to boot the XM? ;-)
[13:52] <persia> he's exaggerating a bit...
[13:52] <mopdenacker> ogra: slow SD card?
[13:52] <persia> It's just slower than for some other platforms.
[13:53] <rsalveti> morning
[13:55] <mopdenacker> Morning rsalveti . Already got coffee?
[13:55] <NCommander> mopdenacker: well, when it boots, its 1907 :-)
[13:56] <ogra> mopdenacker, well, the whole install in the panda takes between 10 and 12min ... the same thing on the XM takes about 45min
[13:56] <persia> EPREEPOCH
[13:56] <Neko> SD cards slow?
[13:56] <mopdenacker> :-)
[13:56] <ogra> i use a class 2 on the panda, and a class 6 on the XM currently
[13:57] <ogra> if definition of classes recently swapped i missed that ;)
[13:57] <Neko> that's still kinda slow. it's a damn shame that new SDHC-I thing probably needs a new controller
[13:57] <mopdenacker> ouch. You've got faster DDR access on OMAP4. Could it be the reason why?
[13:57] <rsalveti> mopdenacker: not yet
[13:57] <Neko> (and I guess on most platforms twice the clock, mx51 esdhc unit runs at 66MHz..)
[13:58] <sakoman> rsalveti: Panda patch is now staged for mainline merge: http://git.denx.de/?p=u-boot/u-boot-ti.git;a=shortlog
[13:58] <ogra> mopdenacker, well, i have dual core 1GHz and 1G on the panda ... single core 600MHz and 512M on the XM ...
[13:59] <rsalveti> sakoman: cool :-)
[13:59] <ogra> surely the SD plays a role but i guess ram and CPU are the more important parts here
[13:59] <ogra> the panda is real fun to use now
[14:00] <rsalveti> ogra: yep, real fast
[14:00] <ogra> i just wish it was a but thinner ... i have a bunch of old netbook shells around :)
[14:00] <ogra> s/but/bit/
[14:01] <persia> Are the clock speeds directly comparable, or have there been scheduler improvements?
[14:01]  * ogra wouldnt mind using it for day to day work with a fast usb disk
[14:01] <mopdenacker> ogra: the XM's OMAP 3730 is supposed to run at 1GHz, according to vstehle ...
[14:01] <persia> You might use it as a desktop :)
[14:01] <ogra> persia, since we run from SD both images use elevator=noop
[14:02] <persia> I meant on-chip dispatch scheduling, pipelining, etc.
[14:02] <ogra> mopdenacker, well, it currently doesnt with our omap3 kernel
[14:02] <ogra> dmesg shows 600MHz
[14:02] <rsalveti> xM should be faster, I guess
[14:02] <ogra> and /proc/cpuinfo 511 bogomips
[14:03] <ogra> the panda goes up to 2000 here ...
[14:03] <ogra> per cpu core ;)
[14:03] <devilhorns> http://slashdot.org/submission/1329038/ARM-Eagle-preys-on-smartphones-and-servers
[14:03] <persia> Ah, so the clockspeeds *aren't* directly comparable.
[14:03] <devilhorns> ^ that will be nice when it hits :)
[14:04] <persia> The hardware virtualisation is the bit that is most exciting to me.  I don't need 2.5GHz even on my desktop (be nice on a buildd though)
[14:05] <Neko> 28nm? crazy
[14:05] <devilhorns> indeed :)
[14:05] <persia> Why?  Isn't RAM there already?
[14:07] <devilhorns> only depressing thing I read there was " it will be at least late 2012 before products featuring the processor arrive on the shelves"
[14:07] <ogra> until then the pandaboard will serve :)
[14:07] <Neko> yeah but there'll be a bunch of nice A9s around before then
[14:12] <Neko> is there a quad A9 on the market yet? :/
[14:13] <ogra> probably prototypes at smoothstone
[14:13] <ogra> surely nothing public yet
[14:13] <sakoman> ogra: you can tweak the xM clock rate with the mpurate u-boot environment variable
[14:14] <persia> devilhorns, That's normal, given the design and certification issues.  Often at least 12 months between having demo HW and retail HW.
[14:14] <ogra> sakoman, ah. cool i'll check if we can do that from jasper on firstboot
[14:14] <sakoman> you could try 'setenv mpurate 720' or even 1000 if your kernel will accept it
[14:14] <devilhorns> persia, indeed ... but dang it, I want one NOW ! :)
[14:14] <rsalveti> sakoman: ogra: I'm just not sure if the kernel supports it
[14:14] <ogra> well, our kernel still has a bunch of oppses it seems
[14:14] <rsalveti> but never tried
[14:14] <persia> devilhorns, Be an ODM or IHV :p
[14:14] <ogra> i see clock related ones :P
[14:15] <sakoman> rsalveti: well, my linux-omap should accept up to 720
[14:15] <devilhorns> persia, hehehe yea...not gonna happen tho :(
[14:15] <rsalveti> sakoman: but we're currently using just upstream, could be missing some patches
[14:15] <sakoman> then 720 should work, but not 1000
[14:15] <rsalveti> but didn't check, can do that later
[14:15] <ogra> i think we use a few cherrypicks from -omap
[14:15] <ogra> so if its there we might be able to pull it in
[14:16] <sakoman> but be warned running above 500 lessens the life of the processor
[14:16] <ogra> like ... from 10 years to 8 ?
[14:16] <ogra> whats the estimated processor life of an omap3 ?
[14:17] <rsalveti> cool, seems we got some patches for mpurate support, so it seems it should work fine
[14:18] <ogra> great
[14:18]  * ogra would like to see the oopses go away though
[14:18] <ogra> seems we still probe for uart3
[14:18] <rsalveti> ogra: yep
[14:18] <rsalveti> where is lag?
[14:18] <rsalveti> :-)
[14:19] <sakoman> ogra: I think it goes from 100K hours to 44K hours.  Let me check
[14:19] <ogra> lag'ing through his vacation until monday i think
[14:19] <rsalveti> hm, ok
[14:19] <sakoman> ogra: https://e2e.ti.com/support/dsp/omap_applications_processors/f/447/p/62063/223487.aspx#223487
[14:20] <ogra> well, thats still 5 years ... :)
[14:20] <sakoman> sure, just wanted to make sure you were making an informed decision
[14:20] <ogra> thanks ! :)
[14:21] <ogra> after 5 years its a good idea to upgrade to omap5 anyway imho ... and TI will earn some money too :)
[14:22] <persia> Depends on the use case.  Given how often you like to accumulate new toys, you might want to try 1200 :)
[14:22] <persia> (or maybe that requires active cooling)
[14:23] <ogra> well, given that our images are using a netbook UI you surely want to upgrade relatively soonish :)
[14:24] <NCommander> ogra: where's the manifest webpage? (I can't find it :-/)
[14:24] <ogra> NCommander, https://wiki.ubuntu.com/MaverickMeerkat/ReleaseManifest davidm should update it though (you had an action item from last meeting)
[14:26] <NCommander> ogra: I know, I spoke with davidm and got a followup action item :-)
[14:26] <ogra> good :)
[14:27] <ogra> it needs to be up to date for next milestone so the release team knows what to do
[14:31]  * ogra takes a break
[15:18] <vstehle> ogra, mopdenacker: http://media.digikey.com/pdf/Data%20Sheets/Circuitco%20Elect/Beagle_Board_Flyer_5-21-10_2.pdf?cshift_ck=null&client_id=5042&cshift_ck=null&client_id=5042
[15:18] <rsalveti> sebjan:
[15:18] <sebjan> rsalveti: yes?
[15:19] <rsalveti> sebjan: the behavior is still weird with the supposed mem fix
[15:19] <sebjan> rsalveti: this patch fixes the memtester issue for me, but not the build issues
[15:20] <rsalveti> tried to run memtest but got disconnected from ssh and then the system started to behave in a weird way
[15:20] <rsalveti> trying to test again, but now I got usb ehci resets again
[15:20] <rsalveti> this is another weird bug that doesn't happen all the time
[15:21]  * vstehle can run 2x memtesters just fine since ~1h30...
[15:22] <ogra_cmpc> vstehle, ah, thanks
[15:23] <vstehle> ogra_cmpc: You can use 'devmem' to lock the PLL @ 1GHz if you booted @ 600 MHz :)
[15:23] <vstehle> ogra_cmpc: But that is not for the faint of heart... :)
[15:25] <ogra_cmpc> yeah, i rather use the u-boot parameter
[15:25] <ogra_cmpc> so we can boot at full speed ;)
[15:30] <rsalveti> sebjan: http://paste.ubuntu.com/490990/ the boot with usb ehci resets
[15:32] <ogra_cmpc> hey, why do you have working asoc ?
[15:33] <rsalveti> sebjan: vstehle: got again
[15:33] <rsalveti> tried just running memtester, went fine for some seconds
[15:33] <rsalveti> then I stopped, started building the kernel, and run memtester on another shell
[15:34] <sebjan> rsalveti: you have this reset issue all the time?
[15:34] <rsalveti> and then http://paste.ubuntu.com/490999/
[15:35] <rsalveti> sebjan: nops, most of the time it works fine
[15:38] <rsalveti> then test fail when running memtest again: http://paste.ubuntu.com/491000/
[15:39] <rsalveti> so it seems it's better somehow with the patch cooloney found, but still not fixed
[15:41] <sebjan> rsalveti: yes, there i still another issue
[16:31] <orbarron> ndec: ping
[16:33] <orbarron> all... I downloaded the OMAP4 maverick beta release and switch out the MLO , uboot and uImage for panda ES2.0 and I am able to get to the log in screen but I cannot seem to log in :( does anyone know the l/p for this?
[16:34] <rsalveti> orbarron: http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100909/maverick-preinstalled-netbook-armel+omap4.img.gz should work fine for es2.0
[16:34] <rsalveti> the latest daily image
[16:35] <rsalveti> guess ogra tested already, I'm still downloading it
[16:35]  * orbarron have that... but can't log in
[16:36] <orbarron> ogra: ping
[16:36] <rsalveti> orbarron: did you run oem-config?
[16:36] <rsalveti> at your first boot?
[16:37] <rsalveti> or was the login screen the first screen you saw?
[16:37] <orbarron> login was the firs thing I saw
[16:37] <rsalveti> hm, ok, so you got the racing condition between oem-config and X
[16:37] <orbarron> followed --> https://wiki.ubuntu.com/ARM/OMAPMaverickInstall
[16:38] <rsalveti> try to reboot it
[16:38] <rsalveti> sometimes I'm also facing this issue
[16:38] <rsalveti> happens when it tries to load but X11 is not ready yet
[16:39] <orbarron> same issue
[16:40] <rsalveti> let me try to boot it
[16:41]  * orbarron took the img from --> http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/maverick/beta/
[16:43] <GrueMaster> orbarron: That is the beta image.  Use today's daily build from http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100909/maverick-preinstalled-netbook-armel+omap4.img.gz
[16:43]  * orbarron downloading it atm
[16:43] <GrueMaster> Beta does not support ES2.x
[16:43] <orbarron> thanks
[16:43] <rsalveti> the image I pointed is the latest daily image
[16:43] <rsalveti> seems you're having problem with it
[16:44] <rsalveti> if you want to test beta image then you need to change mlo and kernel
[16:44] <rsalveti> GrueMaster: were you able to test current daily already?
[16:44] <rsalveti> for omap4
[16:44]  * orbarron switched out uImage, MLO, and uboot with ES2.0
[16:44] <GrueMaster> Booting it now.  It is working through OEM-Config on my 8L board.
[16:45] <rsalveti> GrueMaster: hm, this racing condition doesn't happen all the time
[16:45] <rsalveti> orbarron: try latest image and reboot it a couple of times
[16:45]  * GrueMaster likes that he no longer needs to add parameters for hdmi<>DVI.
[16:45] <orbarron> gm prpplague
[16:45] <GrueMaster> I have seen it 1:10 boots.
[16:45] <prpplague> orbarron: boarding in a few minutes
[16:46] <GrueMaster> It appears more often on XM.
[16:46] <prpplague> orbarron: you get my picture?
[16:46] <orbarron> yeah
[16:46] <prpplague> hehe
[16:46] <orbarron> nice...
[16:46] <prpplague> nothing like a good breakfast
[16:46] <rsalveti> still need to debug that, probably an easy fix
[16:47] <orbarron> prpplague: yeah if that is what you call it :p
[16:47] <prpplague> orbarron: hehe
[16:47] <orbarron> crap... no I am seeing omapdss DISPC error: SYNC_LOST_DIGIT
[16:47]  * prpplague has been asleep 
[16:47] <prpplague> hasn't
[16:48] <prpplague> orbarron: is that before or after the GFX error
[16:48] <orbarron> after
[16:48] <orbarron> saw this on lucid as well
[16:48] <prpplague> trying to start the webcam stuff?
[16:48] <orbarron> not yet... just trying to boot
[16:49] <prpplague> odd
[16:49] <prpplague> ok boarding, i'll be back online after i get to miami
[16:49] <prpplague> orbarron: later
[16:49] <orbarron> prpplague: laters
[16:51] <vstehle> ogra_cmpc: I have one good news and one bad news about the daily images for OMAP4. Which one do you want first? ;)
[17:02] <rsalveti> orbarron: went to the oem-config screen fine here
[17:02] <rsalveti> with latest daily image
[17:03]  * orbarron testing daily image
[17:11] <orbarron> rsalveti: have you seen this error before? --> http://pastebin.com/Dn0thv1D
[17:12]  * orbarron still using beta 
[17:12] <rsalveti> yep, couple of time with different monitors
[17:12] <rsalveti> test with latest daily, should have latest kernel
[17:12] <rsalveti> then if you still faces this issue, we need to debug the display driver
[17:13] <orbarron> will do
[17:25] <rsalveti> GrueMaster: ogra: and about the fixed host name (based on your name) for oem-config?
[17:25] <rsalveti> are we going to stay with this "feature" or should we add a bug for it?
[17:26] <GrueMaster> I think there is a bug already filed.
[17:27] <GrueMaster> I know we discussed it yesterday.
[17:27] <rsalveti> cool
[17:29]  * rsalveti out for lunch
[17:30] <GrueMaster> It is very aggravating for me.  I currently have 8 potential "ubuntu-laptop" hosts.  Trying to ssh into them based on avahi is no good.
[17:32] <Neko> yeah it would be really nice if it pulled the mac address of the first ethernet port or whatever it finds
[17:33] <Neko> at least the default can be ubuntu-laptop-last-6-digits or so
[17:33] <Neko> interested parties will just press delete 7 times and go on their merry way :D
[17:36] <ogra_cmpc> vstehle, the bad ones
[17:36] <GrueMaster> Actually, having it default to <username>-<desktop|laptop> is nice for noobs, but it would also be nice to have the ability to change it.
[17:36] <vstehle> ogra_cmpc: On my Dell monitor, I have the "resize" step outputs, then reboot, then monitor goes black.
[17:37] <ogra_cmpc> vstehle, DSS2 bug i guess
[17:37] <vstehle> ogra_cmpc: Maybe...
[17:37] <ogra_cmpc> we dont touch any graphics config at that point
[17:37] <ogra_cmpc> GrueMaster, it's being worked on
[17:38] <ogra_cmpc> vstehle, dont forget the good news !
[17:38] <GrueMaster> ogra_cmpc: ok.  rsalveti was asking, that's why the thread.
[17:38] <vstehle> ogra_cmpc: The good news are that your image boots "untouched" :)
[17:38] <vstehle> ogra_cmpc: No bootloaders changes, no kernel replacement
[17:38] <vstehle> ogra_cmpc: No bootargs
[17:38] <ogra_cmpc> heh, yeah, here too
[17:39] <ogra_cmpc> and i dont have display issues with my samsung
[17:39] <vstehle> ogra_cmpc: I see what you mean :) Reminds me on Prague...
[17:39] <ogra_cmpc> heh
[17:39] <ogra_cmpc> well, i think there is still one DSS2 patch pending
[17:40] <vstehle> ogra_cmpc: Did you notice the boot partition "disappears" ? I mean that gnome lucid is not able to see it...
[17:40] <vstehle> ogra_cmpc: But a manual mount will do
[17:41] <ogra_cmpc> thats on purpose
[17:41] <ogra_cmpc> users should never touch it at all, all files you need are maintained in /boot
[17:42] <vstehle> ogra_cmpc: Oh? That's a nice "trick" then, if done on purpose.
[17:42] <ogra_cmpc> if you make changes to any file in /boot (i.e. boot.script to change the cmdline) you should use sudo flash-kernel
[17:42] <ogra_cmpc> it will update the hidden partition
[17:43] <ogra_cmpc> if we wouldnt do that, all users would always have an SD card on their desktop/disk list
[17:43] <vstehle> ogra_cmpc: I replaced the kernel and still black screen; I start to suspect the boot.scr...
[17:43] <ogra_cmpc> well, take a look at it, all we set there is vram=32M
[17:44] <ogra_cmpc> no other params
[17:44] <ogra_cmpc> (well, no other video related ones, indeed there are others)
[17:46] <ogra_cmpc> jayabharath, not sure anyone told you yet, the daily omap4 image is for ES2, just download and boot away
[17:47] <jayabharath> ogra_cmpc: very cool.. please point me to it.. orbarron has been trying to use the beta
[17:47] <jayabharath> will give it a try
[17:47] <vstehle> ogra_cmpc: I forgot to tell you: black screen happens after the logo + dots.
[17:48] <ogra_cmpc> jayabharath, http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/current/
[17:48]  * orbarron testing it...
[17:48] <ogra_cmpc> vstehle, wow, thats weird
[17:48] <jayabharath> got cha
[17:48] <ogra_cmpc> orbarron, awesome
[17:49] <ogra_cmpc> for me it works flawless (despite some known bugs) on ES2 6 and 8 layer
[17:50] <vstehle> ogra_cmpc: That's monitor dependent, then
[17:50] <GrueMaster> vstehle: Try removing "quiet splash" and adding "console=ttyO2,115200 console=tty0" and see what the output is.
[17:50] <ogra_cmpc> yeah
[17:50] <ogra_cmpc> vstehle, if you hit ctrl-alt-f1, do you get a console ?
[17:50] <ogra_cmpc> (after it turns black)
[17:51] <vstehle> ogra_cmpc, GrueMaster: I'll reflash my
[17:52] <vstehle> ogra_cmpc: GrueMaster : ...SD card (I wiped the bootloaders and kernels)
[17:52] <GrueMaster> ogra_cmpc: ESID seems to work fine btw.  It is working on my DVI monitor with DVI<>HDMI cable just fine.  Will test with hdmi switch box as soon as I can figure out how to get more power to that side of the desk.
[17:53] <ogra_cmpc> GrueMaster, cool, send beer to robclark and rsalveti for tireless debugging :)
[17:53] <GrueMaster> heh.
[17:54] <GrueMaster> Will buy a round in Dallas.
[17:54] <GrueMaster> (if they have decent beer in Texas).
[17:55] <ogra_cmpc> in the news it looks more like they only have lots of water in TX
[17:55] <GrueMaster> heh.
[17:55] <GrueMaster> They have our weekly rainfall in an hour there.  Texas does everything big.
[17:56] <ogra_cmpc> heh, yeah
[17:56] <orbarron> stop by the State Fair and get some fried beer
[17:56] <GrueMaster> I've read about that.  Very intriguing.
[18:02] <orbarron> ogra_cmpc: panda ES2.0 booted with this image -- thanks
[18:07] <ogra_cmpc> orbarron, awesome
[18:17] <GrueMaster> rsalveti: Bug 566645 appears to be fixed both in Lucid (latest kernel update) and Maverick.
[18:17] <ubot2> Launchpad bug 566645 in linux-ti-omap (Ubuntu Maverick) (and 2 other projects) "OTG configuration is broken on omap kernel (affects: 4) (dups: 1) (heat: 30)" [High,Fix released] https://launchpad.net/bugs/566645
[18:21] <vstehle> ogra_cmpc, GrueMaster: http://paste.ubuntu.com/491116/
[18:21] <vstehle> Screen is black after "enabling binfmt". I tried reducing the RAM a bit (himem/smp issue) but no change.
[18:22] <vstehle> ogra_cmpc, GrueMaster: leds are lit, steady.
[18:23] <GrueMaster> Sounds hung.  Reviewing.
[18:23] <GrueMaster> Actually. my LED
[18:23] <GrueMaster> Actually. my LED's are solid as well.
[18:23] <GrueMaster> Not an indicator.
[18:24] <GrueMaster> Which HDMI port are you plugged into?
[18:24] <vstehle> GrueMaster: Oh. That's in our kernel that some guy connected them to hartbeat + SD activity.
[18:24] <vstehle> GrueMaster: HDMI 1080p
[18:24] <GrueMaster> yea, we should be adding that soon.
[18:25] <vstehle> GrueMaster: I did not believe it at first sight, but I now like the hartbeat.
[18:26] <vstehle> GrueMaster: It helps a lot (when you still have crashes from times to times)
[18:26] <ogra_cmpc> we dont have any LED support in the kernel
[18:26] <ogra_cmpc> and there is nothing coming after binfmt, its the last thing that gets usually started
[18:27] <ogra_cmpc> what do you expect ?
[18:27] <ogra_cmpc> vstehle, a patch for LED support is pending, rsalveti developd that
[18:28] <orbarron> ogra_cmpc: just wondering will this also work for blaze?
[18:28] <vstehle> ogra_cmpc: I don't know. Oh, wait, it just appeared: BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]
[18:28] <ogra_cmpc> vstehle, note that we dont use serial by default, so there wont be anything else happening (no login)
[18:28] <ogra_cmpc> that sounds like a kernel bug
[18:28] <vstehle> ogra_cmpc: The usb keyboard has its numlock unresponsive, too
[18:28] <vstehle> ogra_cmpc: That's a sign
[18:28] <ogra_cmpc> yeah
[18:29] <ogra_cmpc> this is on ES2.0 ?
[18:29] <GrueMaster> I've seen that intermittently on ES1.
[18:29] <vstehle> ogra_cmpc: Yes, ES2.0
[18:29] <GrueMaster> Not on ES2 yet.
[18:29] <vstehle> ogra_cmpc, GrueMaster: let me try nosmp
[18:29] <ogra_cmpc> vstehle, 6 or 8 layer ?
[18:29] <vstehle> ogra_cmpc: 8 layers
[18:29] <ogra_cmpc> hmm
[18:29] <ogra_cmpc> works fine for me
[18:30] <GrueMaster> Same here.  Been running for 2.5 hours now.
[18:30]  * ogra_cmpc was runing his since beginning of the week ... reinstalled this morning with the daily image
[18:31] <vstehle> nosmp does not help
[18:32] <vstehle> Will tomorrow kernel be different? (patches from Seb)
[18:32] <vstehle> In the daily image, I mean
[18:33] <ogra_cmpc> i dont think there was an upload yet
[18:34] <ogra_cmpc> vstehle, rsalveti might have a package with these patches though
[18:34] <ogra_cmpc> since he is testing sebjan's stuff all the time
[18:56] <ogra_cmpc> NCommander, grrr you infected me ! ♬ ♬ ♬ ♬
[18:58] <NCommander> ogra_cmpc: well, it was time for something completely different :-)
[19:11] <lool> I can get a song out of your head if you like
[19:22]  * rsalveti back
[19:24] <rsalveti> GrueMaster: cool, thanks for testing it
[19:26] <rsalveti> ogra_cmpc: vstehle: the led patch is applied at our kernel already, but it's now missing a u-boot fix
[19:26] <rsalveti> that I created and sent sakoman already, he also sent upstream
[19:26] <rsalveti> I created bug 633271 to request this fix for our u-boot
[19:26] <ubot2> Launchpad bug 633271 in u-boot-linaro (Ubuntu) "LEDs not working for Panda with u-boot-linaro-omap4-panda (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/633271
[19:26] <rsalveti> but it's now depending on jcrigby
[19:27] <rsalveti> once we get u-boot fixed, the LED will work by default :-)
[19:27] <rsalveti> vstehle: sorry, what issues are you currently facing?
[19:27] <rsalveti> CPU#0 stuck for 61s! [swapper:0] is interesting
[19:28] <rsalveti> are you able to reproduce it with our latest daily image?
[19:28] <vstehle> rsalveti: daily image not quiet booting on my panda es2
[19:28] <vstehle> rsalveti: reproducible it seems
[19:28] <rsalveti> vstehle: what kernel are you using?
[19:29] <vstehle> rsalveti: I tried the image kernel first, and "ours" then: same behavior
[19:29] <vstehle> rsalveti: I did not try to replace bootloaders
[19:30] <rsalveti> vstehle: are you using swap?
[19:30] <rsalveti> cause swap is still not used by our image, I believe
[19:30] <vstehle> rsalveti: nope. I did not boot yet, so no change
[19:30] <vstehle> rsalveti: Oh you mean, with our kernel?
[19:31] <vstehle> rsalveti: Or you mean, in general?
[19:31] <vstehle> rsalveti: I do use swap on OMAP4 for dev, and it works
[19:31] <rsalveti> vstehle: swap is disabled at userspace at our images
[19:31] <rsalveti> so this could be the reason why only you is able to reproduce it
[19:32] <vstehle> rsalveti: ? I just gunziped the daily image, booted, saw the resize, rebooted and finally got a black screen
[19:32] <vstehle> rsalveti: (I made the story very short :)
[19:32] <greger6> greger live
[19:32] <greger6> http://twitcam.livestream.com/1yway
[19:34] <rsalveti> vstehle: ok, but without doing anything at the default image, are you getting BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]?
[19:34] <vstehle> rsalveti: Exactly.
[19:34] <rsalveti> hm, weird
[19:34] <vstehle> rsalveti: Exactly. ;)
[19:36] <rsalveti> nobody saw this error before at panda
[19:38] <vstehle> rsalveti: ...and I did not see this yesterday either
[19:38] <vstehle> rsalveti: But yesterday, I had to change kernel and bootloaders
[19:38] <vstehle> rsalveti: so, a bit different conditions
[19:38] <rsalveti> vstehle: hm, ok
[19:38] <rsalveti> vstehle: currently we're using an update x-loader, upstream u-boot and sebjan_'s kernel tree
[19:39] <rsalveti> *updated
[19:39] <rsalveti> vstehle: our x-loader: http://gitorious.org/pandaboard/x-loader/commits/omap4_panda_L24.9
[19:46] <vstehle> rsalveti: Out for dinner; back in an hour. *miam*
[19:46] <rsalveti> :-)
[19:47]  * rsalveti looks for coffee
[19:49] <greger6> greger live
[19:50] <greger6> http://twitcam.livestream.com/1yway
[20:39] <jcrigby> rsalveti, yes there will be a new u-boot next week
[20:39] <rsalveti> jcrigby: cool, thanks for the note
[23:22] <sakoman> rsalveti: we're one step closer to mainline now, we've moved from u-boot-ti to u-boot-arm on denx:
[23:22] <sakoman> http://git.denx.de/?p=u-boot/u-boot-arm.git;a=shortlog
[23:23] <rsalveti> sakoman: great! :-)
[23:23] <sakoman> need to finish the expansion board series and get that submitted too.
[23:24] <rsalveti> sakoman: cool, do you have some patches for that already?
[23:24] <sakoman> then will look at igep and see how much work it will take to get their stuff in shape for upstream
[23:24] <rsalveti> nice
[23:24] <sakoman> rsalveti: not that I am happy with.  they introduce too much delay in the boot.
[23:24] <rsalveti> hm, true
[23:24] <sakoman> I am debugging trying to figure out what the real issue is
[23:25] <sakoman> reading the eeprom is taking several seconds!
[23:25] <rsalveti> ouch!
[23:25] <sakoman> either the udelay function is broken, or the hard coded delays in the i2c driver are too long, or both
[23:26] <sakoman> in my exp tree I just arbitrarily slashed the delays
[23:26] <sakoman> but for upstream I need to figure out the real source of the problem
[23:26] <sakoman> that's on the agenda for tomorrow
[23:27] <rsalveti> got it
[23:45] <rsalveti> GrueMaster: ogra: http://people.canonical.com/~rsalveti/iozone-test-omap-mmc-improvement/summary.txt
[23:46] <rsalveti> with a new patch that improves mmc performance for omap3
[23:46] <rsalveti> that's included at our omap4 already
[23:46] <rsalveti> sending to the kernel team atm
[23:51] <sakoman> rsalveti: what is the mmc patch?
[23:51] <rsalveti> sakoman: http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-maverick.git;a=commitdiff;h=844a485189d98b980c822ac718bd89d2a48ed66e;hp=4e90adae43f52db35c99bcaccb2e2a912b8299d5
[23:52] <rsalveti> upstream already, but for 2.6.36-rc1
[23:52] <sakoman> ah, ok.  yeah I've used that for quite some time
[23:52] <sakoman> it does indeed make a *huge* difference
[23:52] <sakoman> especially during installs
[23:52] <rsalveti> cool
[23:53] <sakoman> I was hoping you found something beyond that :-)
[23:53] <rsalveti> sakoman: haha, np, just digging interesting patches to include at our release :-)
[23:53] <rsalveti> *no
[23:56] <sakoman> rsalveti: I was using a slightly different version of it: http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux-omap-2.6.git;a=blobdiff;f=drivers/mmc/host/omap_hsmmc.c;h=8c97c22fe66fd0804ba23bb11d7aa0b2c33c3bd6;hp=83f0affadcae638fcbc0abc8cc0e892c23e16142;hb=84c241a90bbdc001ab69d2cdc58fc32afca5a0c9;hpb=e378ed678988af9af1d658e1e8dc0cf4080821b4
[23:57] <sakoman> But the same idea