[01:58] <cwillu> rcn-ee, kinda sorta :p
[01:58]  * ogra_cmpc is surprised to see that cwillu actually uses that non-work nick 
[01:59] <ogra_cmpc> i always thought thats only channel decoration :)
[01:59] <cwillu> heh
[01:59] <cwillu> I don't usually have any arm equipment to hack on here :p
[02:00]  * prpplague pokes ogra and ogra_cmpc to see if they are alive
[02:00] <ogra_cmpc> barely
[02:00] <ogra_cmpc> working since 7am (its 3am now) ... and nearly falling over
[02:00] <prpplague> ogra_cmpc: ubuntu arm with multiple frame buffers
[02:00] <prpplague> ogra_cmpc: i'll make it quick
[02:01] <ogra_cmpc> sounds intresting, do you think X is capable of managing them properly ?
[02:01] <prpplague> well i know X is, just not sure how
[02:01]  * prpplague isn't a userland person
[02:02] <ogra_cmpc> will likely need changes to the xserver
[02:02] <prpplague> hmm
[02:02] <ogra_cmpc> the current omapfb one we have even hardcodes fb0
[02:02] <prpplague> OH
[02:02] <ogra_cmpc> there is big room for improvement :)
[02:03] <prpplague> we need to start discussing it now
[02:03] <prpplague> (or when more correctly when you've had some rest)
[02:03] <prpplague> are you going to be working with the blaze and/or panda?
[02:03] <ogra_cmpc> prpplague, at a time when XorA is around, he is upstream for the omapfb xserver
[02:04] <prpplague> OH
[02:04] <ogra_cmpc> i work with both, yes
[02:04]  * prpplague can deal with XorA hehe
[02:04] <ogra_cmpc> heh
[02:05] <prpplague> ogra_cmpc: we need to setup a time with XorA within the next 7 days to discuss the matter
[02:05] <ogra_cmpc> i havent tried omapfb on the panda yet though
[02:05] <prpplague> ogra_cmpc: i have ubuntu running on one fb at a time right now
[02:05] <ogra_cmpc> i seem to be one of the lucky guys that have a HDMI monitor the panda can actually handle
[02:05] <prpplague> ogra_cmpc: but not both
[02:06] <ogra_cmpc> they seem to be rare atm, some issues wiht reading EDID data
[02:06] <prpplague> ogra_cmpc: thats odd, we've not found one that doesn't work
[02:06] <ogra_cmpc> intresting
[02:06] <prpplague> ogra_cmpc: we need to get sync'd up on this so i can resolve those issues
[02:06] <cwillu> prpplague, does maverick's omapfb support xorg's -nr yet?
[02:06] <ogra_cmpc> well, mine works too, even though i was told samsung would be the most problematic and i have a samsung
[02:06] <cwillu> i.e., plymouth slickness
[02:06] <cwillu> it's a trivial patch if not
[02:07] <ogra_cmpc> cwillu, you didnt file a bug and patch yet ;)
[02:07] <prpplague> cwillu sorry don't know, i'm normally a kernel/boardbringup guy
[02:07] <ogra_cmpc> cwillu, file me a bug and i'll upload the fix
[02:07] <ogra_cmpc> feel free to even assign it to me
[02:07] <prpplague> ogra_cmpc: now, is your display actually hdmi or is it dvi-d?
[02:08] <ogra_cmpc> HDMI
[02:08] <cwillu> I think I have a debdiff
[02:08] <ogra_cmpc> the DVI port isnt working yet i was told
[02:08] <cwillu> whether it's actually sane is another matter
[02:08] <prpplague> ogra_cmpc: dvi is working but has some timing issues
[02:08] <ogra_cmpc> so i didnt bother to try
[02:08] <ogra_cmpc> ah, i was told differently
[02:08] <prpplague> ogra_cmpc: you can actually use the HDMI port to connect to a dvi-d display as well
[02:08] <ogra_cmpc> indeed
[02:09] <prpplague> ogra_cmpc: for instances you can mix and match dvi-d and hdmi, you can have 2 hdmi, 2 dvi or 1 dvi and 1 hdmi
[02:09] <ogra_cmpc> but i'm using the DVI port for the beagle, so having the panda on HDMI is very convenient
[02:09] <ogra_cmpc> (and my main machine onj VGA)
[02:09] <ogra_cmpc> saves a lot of space ;)
[02:09] <prpplague> ogra_cmpc: right np
[02:10] <prpplague> ogra_cmpc: i actually prefer using dvi-d devices myself
[02:10] <ogra_cmpc> inded i can switch plugs around for testing
[02:10] <prpplague> ogra_cmpc: anyway, when is the best time to contact you via irc to debug some of this?
[02:10] <ogra_cmpc> european business hours usually
[02:10] <cwillu> ogra_cmpc, okay, I'll ping you tomorrow from _at_work :p
[02:11] <prpplague> ogra_cmpc: ahh, ok
[02:11] <ogra_cmpc> i'm normally up after 9/10 UTC
[02:11] <prpplague> ogra_cmpc: i'll try to get with you tomorrow and set down some times we can iron out a plan of support
[02:11] <ogra_cmpc> great
[02:11]  * prpplague hands ogra_cmpc some nice belgian ale and sends ogra_cmpc to bed
[02:12] <ogra_cmpc> *slurp*
[02:12] <ogra_cmpc> :)
[02:12] <prpplague> wait the belgian was for me, i was suppose to give you some coors
[02:12] <ogra_cmpc> lol
[02:12]  * prpplague jokes with ogra_cmpc 
[02:13]  * ogra_cmpc gets a pilsner urquell from the fridge then :P
[02:13] <prpplague> hehe decent choice
[02:13]  * prpplague drinks his duvel
[02:14] <ogra_cmpc> while i'm german i'm a big fan of check beers
[02:14]  * ogra_cmpc looks forward to be in prague in a few weeks :)
[02:14] <prpplague> ogra_cmpc: dont suppose you are headed to CELF-EU ?
[02:15] <ogra_cmpc> is it in prague this time ?
[02:15] <prpplague> cambridge
[02:15]  * ogra_cmpc is going to the ubuntu distro sprint ... doing face to face work 
[02:15] <ogra_cmpc> when is it ?
[02:15] <prpplague> october
[02:16] <ogra_cmpc> if it doesnt clash with any ubuntu dates i might go
[02:16] <prpplague> http://www.embeddedlinuxconference.com/elc_europe10/index.html
[02:16] <ogra_cmpc> we're releasing on the tenth this time
[02:16] <ogra_cmpc> 27 and 28
[02:16] <ogra_cmpc> sounds good
[02:17] <prpplague> i'm hoping i'll get a trip to Nice from TI sometime soon, but i have to do some major work
[02:17] <ogra_cmpc> Nice is nice :)
[02:17] <ogra_cmpc> though its probably way to warm now
[02:17] <prpplague> ogra_cmpc: hehe, just an excuse to  visit some of belgian abbeys
[02:18] <ogra_cmpc> heh
[02:18]  * prpplague goes to read schematics
[02:18] <prpplague> later
[02:18] <ogra_cmpc> night then
[02:19]  * ogra_cmpc will go to bed after the beer
[08:44] <lag> ogra, Amitk: ping
[08:44] <amitk> lag: wassup?
[08:44] <lag> Hey amitk
[08:45] <lag> I'm chatting with someone on another channel
[08:46] <lag> He says "I am presenting about the BB at OSCON and want to get Ubuntu working to demo"
[08:46] <lag> Would like eye-candy
[08:46] <lag> Do we have eye candy for Beagle yet?
[08:49] <amitk> lag: not really. They could showoff the normal desktop. But more eyecandy than that would mean integrated 3d graphics drivers which we don't do yet.
[08:49] <hrw> morning
[08:49] <lag> Eye candy == Desktop (in my Luddite kernel speak) :)#
[08:50] <lag> Is Desktop running on Beagle?
[08:50] <hrw> lag: it does
[08:50] <lag> Great
[08:50] <lag> Where do I (he) get it from?
[08:51] <amitk> lag: download the images from http://cdimage.ubuntu.com/ports/releases/10.04/release/
[08:51] <amitk> the maverick images are a WIP
[09:20] <directhex> ARGH
[09:21] <directhex> Bug #579227 ¬_¬
[09:21] <ubot2> Launchpad bug 579227 in qemu-kvm (Ubuntu) "[qemu-system-arm] hardware error: pl011_read: Bad offset 16000018 (affects: 4) (heat: 83)" [Low,Confirmed] https://launchpad.net/bugs/579227
[09:38] <ogra> directhex, why dont you use an ubuntu kernel and the recommended way to run the vm ?
[09:39] <lool> directhex: Looks like you're passing too much RAM
[09:39] <lool> directhex: How do you run QEMU?
[09:39] <directhex> lool, as suggested on http://www.aurel32.net/info/debian_arm_qemu.php
[09:40] <ogra> directhex, https://wiki.ubuntu.com/ARM/RootfsFromScratch
[09:40] <ogra> directhex, look at "Using a qemu image with full emulation"
[09:40] <lool> directhex: With the images from there as well?
[09:41] <directhex> ogra, didn't do anything useful either (gets stuck with a blinky cursor partway through booting). plus i need a debian environment, not just ubuntu
[09:41]  * ogra thinks that aurel wikipage is several years old
[09:41] <directhex> really what i need is both, of course
[09:41] <ogra> directhex, then you need two kernels and two images
[09:42] <directhex> ogra, right.
[09:42] <ogra> directhex, well the above ubuntu instructions are used by many users
[09:42] <ogra> if you follow the howto corretly it should just work
[09:43] <ogra> *correctly
[09:43] <lool> directhex: So I downloaded the armel images from aurel32's site, and I could start and execute the initrd with: qemu-system-arm -M versatilepb -kernel vmlinuz-2.6.26-1-versatile -initrd initrd.img-2.6.26-1-versatile -m 128
[09:43] <lool> it did crash without -m 128 though
[09:43] <ogra> looking at www.aurel32.net that page seems to be last edited in 2008, no idea how accurate that still is
[09:44] <lool> directhex: It looks like someone borke the default -m value
[09:44] <lool> directhex: Just pass -m 128 or -m 256 systematically
[09:44] <directhex> lool, that seems to help
[09:44] <lool> directhex: if this is for package builds, you might be interested in qemubuilder
[09:44] <ogra> lool, for mono chroots wont work
[09:44] <directhex> lool, right now this is for debugging
[09:45] <lool> directhex: I started this page https://wiki.ubuntu.com/UbuntuDevelopment/Ports listing possible ways to develop for Ubuntu ports, it links back to RootfsFromScratch pages to create rootfses, but there are other ways
[09:46] <lool> ogra: qemubuilder uses a real vm AFAIK
[09:46] <ogra> ah, i thought it was like pbuilder
[09:46] <lool> it is like pbuilder
[09:46] <directhex> lool, oh, some of that looks useful
[09:47] <ogra> lool, hmm, doesnt our pbuilder use chroots ?
[09:47] <directhex> lool, which -cpu value is closest to the debian baseline?
[09:47] <lool> directhex: It's not very well advertized (ie not at all), I was suggested to mature it a bit before it's linked more proeminently
[09:47] <ogra> at least the implementationm emmet worked on
[09:47] <lool> directhex: You dont need to worry about the CPU value of your emulated machine
[09:48] <lool> directhex: Unless you're trying to debug something where you're generating code that requires a too recent CPU
[09:48] <lool> e.g. you're generating v7 code for Debian binaries
[09:48] <directhex> lool, i'm trying to debug something where i'm generating code that requires a too recent CPU
[09:48] <directhex> assuming that's causing the SIGILL anyway
[09:48] <lool> Ok
[09:48] <lool> let me look
[09:49] <lool> directhex: I'm grabbing gcc-4.4 sources to see how it's configured
[09:52] <ogra> WOHOOOO  !!!!! \o/
[09:52] <ogra> http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/current/
[09:52] <ogra> not sure how well it works though
[09:53] <lool> I'm stupid, I should just look at the build log
[09:53] <hrw> "--with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16" is used for Ubuntu
[09:53] <lool> --target=arm-linux-gnueabi
[09:53] <lool> hrw: Debian one
[09:54] <hrw> Debian do not force any tune flags
[09:54] <lool> yup, exactly
[09:54] <hrw> so gcc defaults are used
[09:54] <hrw> armv4t probably but maybe even armv4
[09:55] <hrw> because gcc 4.4.x is able to do EABI for armv4 (strongarm etc)
[09:56] <lool> directhex: Oldest I can find is arm946, which is already armv5t
[09:56] <lool> directhex: It might not work with your versatile kernel though
[09:57] <hrw> arm946? rather arm926
[09:57] <directhex> lool, so i can't emulate armv4t? and even armv5t is troublesome? man, ARM is messy :/
[09:58] <ogra> directhex, qemu is
[09:58] <hrw> directhex: qemu-arm is able to do arm926 and higher
[09:58] <hrw> hmm.. omap310 may be arm920 but I am not sure
[09:59] <ogra> dont blame arm for drawbacks of an emulator, thats like saying intel is crap because vmware is buggy :)
[10:00] <hrw> nope. omap310 is arm925 which is armv4t
[10:00] <directhex> ogra, in the absence of an ubuntu arm porterbox for mere mortals, i need to make do
[10:00] <ogra> there are porterboxes, they are just not accessible for everyone
[10:01] <lool> directhex: not being able to emulate armv4t is a qemu limitation, but I dont consider that a big deal given the age of it... you might be able to use qemu's versatile emulation with a special kernel built for versatile and for v5t, but by default it my expect more than that
[10:01] <directhex> ogra, hence "for mere mortals"
[10:02] <ogra> directhex, we'll get there
[10:02] <ogra> likely this year
[10:03] <lool> ogra: Hmm really?
[10:03] <ogra> lool, matter of affordable powerful HW
[10:03] <hrw> pandas for everyone!
[10:04] <ogra> lool, the panda should be available by end of the year for a reasonable price
[10:04] <lool> ogra: i dont think that's the issue, we have a porter box already
[10:04] <lool> ogra: Oh you dont mean that porter boxes will be available to more people by the end of the year, you mean people will be able to get fast hardware?
[10:04] <ogra> lool, if we can have PPAs because its cheap to put up a bunch of pandas thats nearly as good as a porter box imho
[10:05] <lool> ogra: having cheap powerful hardware doesn't give us PPAs though
[10:05] <ogra> but indeed i also mean you can just buy one for under $150
[10:05] <hrw> lool: but if we get 10 pandas for LP/PPA?
[10:05] <ogra> or 50
[10:06] <ogra> (which is more what i'm after :P)
[10:06] <hrw> this will make big build farm
[10:06] <ogra> right, thats what i would like to have
[10:06] <hrw> you can stack pandas, give each SD card for rootfs + nfs storage for builds and it will fly
[10:06] <lool> it's not a problem of buildd power I'm afraid
[10:06] <lool> That's certainly one of the issues
[10:06] <ogra> indeed a PPA doesnt give you shell access but it will improve the situation a lot
[10:07] <lool> but another one is security
[10:07] <ogra> yes, thats something we need to sort
[10:07] <ogra> and i'm positive we can do that with joined effort of ubuntu-arm and linaro
[10:07] <lool> hrw: nfs for builds is a terrible idea, it breaks plenty due to timestamp skews and other issues, but it's possible to use networked storage -- or simply USB
[10:08] <lool> ogra: What's your security story then?
[10:08] <ogra> lool, dedicated pandas with the same setup the other PPAs use but with real HW instead of kvm ?
[10:08] <hrw> lool: having 4U 20TB storage is easier to maintain then 50 USD harddrives
[10:10] <suihkulokki> rather than nfs use iscsi or ata-over-ethernet
[10:10] <lool> suihkulokki: Yes, exactly, or even nbd
[10:11] <ogra> <3 nbd
[10:11] <lool> ogra: So real hardware in the DC is not going to fly I'm afraid
[10:11] <ogra> lool, why not ?
[10:12] <lool> ogra: We would have to ensure a way to really wipe anything from the board, such as changes to the u-boot config or things like that
[10:12] <lool> otherwise, it might be possible to do nasty things in one PPA build, which would affect the next one
[10:12] <ogra> lool, aufs ftw ;)
[10:12] <lool> ogra: IS has the details, but essentially we cant allow direct hardware access, especially on ARM where it might mean changing the bootloader and such
[10:13] <lool> which is why we use xen / kvm on x86
[10:13] <hrw> anyway - nfs was just a nane
[10:13] <hrw> name
[10:13] <ogra> lool, i'll write a spec for m+1, lets see what IS says about the ideas i have
[10:13] <hrw> apt-cacher-ng ftw
[10:14] <lool> ogra: I'm not sure it's a specable thing, but having a wiki page explaining the proposed plan and running it through IS is a good idea
[10:14] <ogra> lool, essentially my plan would be to run the boards like ltsp clients (nbd squashfs image remotely merged with a tmpfs in ram)
[10:15] <lool> ogra: Now I'm a bad PPA builds, I flash a new kernel which will insert a rootkit into any gcc builds, but otherwise chainloads the normal setup, how do you avoid that?
[10:15] <ogra> lool, everything works out of the initramfs, no need to touch the bootloader in that setup and you can maintain everything on an x86 machine ... after a build the panda gets rebooted and becomes virgin again
[10:15] <lool> ogra: Problem is that you cant prevent the build from touching it
[10:15] <ogra> sure you can, especially on a panda
[10:15] <lool> since it has root permissions in the form of installing any other PPA package
[10:16] <ogra> you make the vfat inaccessible so nobody can fiddle with kernels and the like
[10:16] <lool> ogra: Ok; I might like background on this hardware then
[10:16] <lool> ogra: How do you make it inaccessible?
[10:17] <ogra> on a partition level, setting a type the kernel wont touch for example, i guess there are other ways
[10:17] <lool> "wont touch"
[10:17] <lool> what if I build a kernel module which allows me to overcome that, and then modprobe it
[10:17] <ogra> or wait, you remote boot anyway
[10:17] <ogra> there doesnt need to be a vfat
[10:17] <lool> yes, but that doesn't prevent me from changing the config that says to remoteboot
[10:18] <lool> e.g. fconfig or uboot-env-tool to update the bootcmd
[10:18] <ogra> how would you do that if everything lives on a remote boot server ?
[10:18] <lool> ogra: I'm sure there are ways to protect from that, such as signatures or some form of container for ARM (e.g. lxc, even if not very secure, would allow hiding a bunch of devices)
[10:19] <lool> ogra: Certainly the boards have their boot setup stored in flash somewhere?
[10:19] <ogra> no flash on panda
[10:19] <lool> how do you tell it to network boot?
[10:20] <ogra> there are only two ways you can boot a panda, serial or SD
[10:20] <ogra> you pull the bootloader via serial, then let it tftpboot
[10:20] <lool> ogra: ok, that might a good way then, always providing the boot bits on SD and rebooting after each build; it needs some kind of hardware remote reboot though
[10:21] <ogra> so everything lives on a remote x86 machine the user doesnt have access to
[10:21] <lool> I feel you get a better sense of the issues at hand now, and with you knowledge of the hardware you should be in a position to write something up  :-)
[10:21] <ogra> right, thats my plan
[10:21] <ogra> and then get elmo drunk and sign it off ;)
[10:25] <directhex> is there an easy way to see which instruction caused a SIGILL?
[10:32] <lool> directhex: if you do that under gdb, you should get a backtrace and you can also disassemble at the point of the sigill
[10:33] <Lutin> alternatively, compiling your kernel with CONFIG_DEBUG_USER and booting with debug_user=1 should do the trick
[10:34] <Lutin> user_debug=, sorry.
[10:41] <directhex> oh for the love of... qemu segfaulted whilst installing lucid
[11:01] <lag> amitk: Are you around?
[11:02] <lag> And ogra
[11:02]  * ogra_cmpc is here with half an eye
[11:02] <ogra_cmpc> asac, http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/current/
[11:03] <ogra_cmpc> (no idea if it work though)
[11:03] <ogra_cmpc> *works
[11:03] <lag> ogra_cmpc: I am having troubles with my Beagle XM and Lucid
[11:03] <ogra_cmpc> lucid ?
[11:03] <lag> Can you get a console?
[11:03] <ogra_cmpc> that wont work
[11:03] <lag> Yes, Lucid
[11:03] <lag> Doh!
[11:04] <amitk> lag: yeah?
[11:04] <ogra_cmpc> kernel is missing bits
[11:04] <lag> amitk: I think my question has been answered
[11:04] <lag> Balls
[11:04] <amitk> lag: you're expected to fix the missing bits in maverick  :-p
[11:04] <lag> So I won't be able to bug-fix on Lucid OMAP3
[11:04] <ogra_cmpc> you also need the maverick x-loader/u-boot
[11:04] <lag> I have it working for Maverick
[11:05] <ogra_cmpc> you do ?!?
[11:05] <ogra_cmpc> with the default bits?
[11:05] <lag> amitk: No one specified that
[11:05] <ogra_cmpc> lucid is beagle C4 only
[11:05] <amitk> lag: that is why you got the board. Implied specification? ;)
[11:05]  * lag thinks people need to tell me these things
[11:06] <lag> I thought I received it so I could fix bugs on OMAP3 and the Panda to fix bugs on OMAP4?
[11:06] <NCommander> woo
[11:06]  * amitk agrees and beats himself up
[11:06] <lag> That to me was implied
[11:06] <ogra_cmpc> maverick is supposed to work on as many omap3 platforms as we can make possibkle plus panda and blaze
[11:06] <lag> Okay
[11:07] <lag> So I am a Maverick guy?
[11:07] <amitk> lag: the XM appeared towards the end of the lucid cycle, so there wasn't enough time to enable it in Lucid
[11:07] <ogra_cmpc> lag, well, dont you have a C4 too ?
[11:07] <lag> I only learned that it was a new board a little while ago
[11:07] <amitk> lag: but if a few patches make it work in lucid, then I guess an SRU is possible
[11:07] <lag> I thought Beagle was Beagle
[11:07] <lag> http://paste.ubuntu.com/456338/
[11:08] <lag> That is my Lucid run
[11:08] <ogra_cmpc> amitk, it needs a new bootloader, i doubt we can SRU that
[11:08] <lag> ogra_cmpc: What's the difference in bootloaders? More sysIDs?
[11:09] <amitk> ogra_cmpc: I'm not sure if lag flashed a non-Lucid bootloader onto the XM
[11:09] <amitk> lag: is this console capture from a stock lucid image?
[11:09] <ogra_cmpc> amitk, it comes withou preinstalled bootloader afaik
[11:10] <lag> ogra_cmpc: Not true
[11:10] <lag> Well, not for me anyways
[11:10] <ogra_cmpc> mine did and i havent seen one that had anything in nand
[11:11] <lag> amitk: Yes, I built it from git
[11:11] <ogra_cmpc> though ours were early ones
[11:11] <lag> ogra_cmpc: It doesn't have NAND
[11:11] <ogra_cmpc> afaik the XM isnt shipped yet anyway, there are stll ram issues according to #beagle
[11:12] <ogra_cmpc> lag, q ah, right, that was the issue :)
[11:12] <lag> Yes, that would do it :)
[11:13] <lag> So amitk, I am to work on Maverick
[11:13] <lag> Check
[11:13]  * ogra_cmpc has a hard time typing sitting in position that only allows i finger typing atm
[11:13] <lag> I'll stop assigning myself to Lucid bugs then :)
[11:13] <ogra_cmpc> s/i/1/
[11:13] <lag> ogra_cmpc: Are you in jail?
[11:14] <lag> ;)
[11:14] <ogra_cmpc> kind of, i got a sick cat on my lap sitting in my living room
[11:14] <lag> Oh dear
[11:14] <ogra_cmpc> holding the cmpc with 1 hand above my haed trying to type
[11:14] <lag> Did NCommander manage to kill his cat in the end?
[11:15] <lag> What is cmpc?
[11:15] <ogra_cmpc> ask him :)
[11:15] <ogra_cmpc> classmate pc
[11:15] <amitk> lag: you should confirm with your lead, but basically whoever has the HW should support it in whatever releases we want to support it in. This includes new features + bugs.
[11:15] <NCommander> lag: I managed to put Ubuntu on my Nexus One, then NFS mount my laptop's HDD
[11:15] <lag> Lol, looks like a toy
[11:15] <ogra_cmpc> conveniently small for use in the living room where i dont want other computetrs
[11:16] <lag> NCommander: Nicely done
[11:16]  * ogra_cmpc is having a coffee break watching the presidential election in germany on TV
[11:16] <lag> amitk: Who's my lead?
[11:16] <lag> amitk: I think here lies the issue
[11:16] <amitk> lag: rtg
[11:16] <ogra_cmpc> NCommander, how is your cat related to that ?
[11:16] <lag> amitk: I'm a floater
[11:16] <lag> amitk: He hasn't asked me to do anything - ever :S
[11:17] <lag> I'll speak with him today
[11:17] <NCommander> ogra_cmpc: well, I could put my phone in my cat, then connect it over wifi, and have Ubuntu running in my cat!
[11:17] <amitk> lag: I'll sound him out for you ;)
[11:17] <ogra_cmpc> shudder
[11:17] <lag> amitk: It's okay. I can speak with him direct via other means
[11:17] <amitk> lag: and if TZ is an issue, then perhaps apw
[11:17] <lag> He should be on soon
[11:18] <lag> It's not an issue
[11:19] <lag> amitk: Which OMAP3 board does mpoirier have?
[11:19] <ogra_cmpc> C4 afaik
[11:19] <lag> balls
[11:20] <ogra_cmpc> he might have an XM too, not sure
[11:20] <lag> We were working together yesterday to try and get my Beagle up and running
[11:20] <lag> I assumed he had an XM
[11:20] <lag> Okay
[11:20] <lag> I'll have to re-touch base with him today
[11:21] <lag> Thanks for clearing things up ogra & amitk
[11:21] <ogra_cmpc> in any case talk to the guys in #beagle too, about the issues why XM isnt shipped yet
[11:21] <lag> I've been talking to them this morning
[11:21] <lag> It's due in July
[11:21] <ogra_cmpc> perhaps your oopses are related
[11:21] <lag> As I say, I have a console running
[11:22] <lag> No, my oopses are Lucid only
[11:22] <ogra_cmpc> with the archive kernel and archive bootloaders ?
[11:22] <lag> Maverick works
[11:22] <ogra_cmpc> cool
[11:22]  * lag uses the word 'works' loosely 
[11:22] <lag> I have a running console
[11:23] <ogra_cmpc> well, as long as the default binaries we provide get you that, thats a good step already
[11:23] <lag> Kind of - there is one issue with SDHC cards
[11:23] <lag> You have to turn off preempt to get them to work
[11:24] <ogra_cmpc> i think we have that on the C4 too
[11:24] <ogra_cmpc> there is a bug mpoirier is working on
[11:24] <lag> Correct
[11:24] <lag> Same thing
[11:25] <ogra_cmpc> so not XM specific
[11:25] <lag> Nope
[12:10] <kai> lag: there's issues with memory on the xm, though
[12:11] <lag> kai: What issues are those?
[12:11] <kai> hm, I just realized that my work account isn't in #beagle, so I guess they already told you that
[12:11] <ogra> kai, are you incognito today ?
[12:11] <kai> ogra: no, I'm kblin from my "home" box and kai at work
[12:11] <ogra> ah
[12:11] <kai> I have a different channel selection
[12:11] <ogra> i never saw you as kai :)
[12:12] <kai> yeah, #ubuntu-arm technically isn't related to work :)
[12:14] <kai> work is more related to high performace computing, not really a playground for ARMs
[12:14] <lag> kai: http://paste.ubuntu.com/457317
[12:17] <ogra> kai, pfft ... if you stick enough beagles together you can have a HPC cluster too
[12:26] <kai> ogra: right, and I get data off them with ultra-high-speed USB connections :)
[12:27] <ogra> at least ... if not these super fast serial connections :)
[12:27] <kai> lag: not entirely convinced
[12:27] <kai> er
[12:27] <kai> ogra: ^^^
[12:28] <kai> lag: if you're saying this only happens with specific kernels, that's probably not the memory issue
[12:28] <kai> but ask jkridner about the memory thing
[12:29] <lag> It's the first time I've seen it
[12:29] <lag> And I've only seen it once
[12:33] <kai> ok
[12:33] <kai> as I said, ask one of the TI folks about the memory issues with the xm
[14:15] <lag> ogra: ping
[14:16] <lag> ogra_cmpc: This perhaps?
[14:18] <ogra_cmpc> heh
[14:18] <ogra_cmpc> lag, whats up ?
[14:19] <lag> Have you been asked to have a think about syslink?
[14:20] <ogra_cmpc> we discussed it here yesterday, yes
[14:20] <lag> I've been asked to lend my services
[14:20] <lag> How may I assist you
[14:21] <ogra_cmpc> err, i didnt do anything with it, only gave a recommendation how to handle the loading of the module best with regard to our images
[14:22] <ogra_cmpc> since the kernel apparently cant do it alone
[14:22] <ogra_cmpc> fixing that part would help, beyond that, fixing the module itself is in sebjan's TODO i think
[14:23] <ogra_cmpc> lag, i also think there are some patches in sebjan's branch we dont have yet to fix the loop issues
[14:24] <lag> That's correct
[14:24] <lag> I'm keeping an eye on those
[14:24] <lag> I've also been asked to touch base with you
[14:24] <lag> Have we come a conclusion as to which method would be best?
[14:24] <ogra_cmpc> a way to probe the platform bus for devices to make the module autoload would be the best
[14:25] <ogra_cmpc> but i'm not sure about the technical possibilities here
[14:25] <ogra_cmpc> wrt kernel
[14:25] <lag> How about something in /etc/modules, or upstart?
[14:25] <ogra_cmpc> i know we had platform devices for NIC drivers before under imx51 and these were autoloaded without /etc/modules
[14:26] <lag> That's interesting
[14:26] <ogra_cmpc> well, both are workarounds
[14:26] <lag> Okay, but non-standard?
[14:26] <ogra_cmpc> if we could fix it in kernel that would be preferred
[14:26] <ogra_cmpc> well, it was the fec NIC driver on imx51, amitk made it autoload back then
[14:27] <ogra_cmpc> not sure how
[14:27] <ogra_cmpc> if we cant fix it in kernel i'll simply add a line to jasper_setup do the module gets added to /etc/modules, thats trivial
[14:28] <ogra_cmpc> i perfer to not use an upstart job, since that will require an extra package only to ship the job
[14:30] <lag> Auto loading within the kernel seems a little weird
[14:30] <lag> Usually, if you want it to auto-load you just build it in
[14:30] <ogra_cmpc> well, usually if there is a device on a bus (acpi or pci come to mind) the module is loaded automatically
[14:31] <ogra_cmpc> indeed these buses work differently and can be walked by a probing process
[14:31] <lag> Okay, so perhaps something similar might be in order
[14:31] <ogra_cmpc> the kernel is supposed to work on multiple SoCs, i'm not sure you will have the HW on all of them
[14:32] <ogra_cmpc> which is likely the basic reason that ndec decided to modularize it first place
[14:32] <lag> Makes sense
[14:33] <lag> I'll do a little more research
[14:33] <lag> So the final word from you is; you'd put it in userspace, but you'd prefer not to?
[14:33] <ogra_cmpc> yeah, probably amitk can give some info how/why the fec driver worked that way
[14:33] <ogra_cmpc> right
[14:33] <ogra_cmpc> userspace is trivial but if we could solve it in kernel that would absolutely rock
[14:35] <lag> Naturally - the kernel does rock! :)
[14:35] <lag> I'll get back to you
[14:35] <ogra_cmpc> if its not broken, yeah :)
[14:35] <sebjan> cooloney: I have pushed the updates in my for-ubuntu-2.6.34 branch
[14:36] <sebjan> cooloney: the changes are pointed to by tag: ti-ubuntu-2.6.34-901.2+ti+panda+release0
[14:36] <cooloney> sebjan: thanks, man
[14:37] <sebjan> cooloney: as usual, you do not want to take the last commit which is just a changelog update for package version
[14:37] <lag> sebjan, cooloney: Let me know when you have that sorted and I'll be happy to test again
[14:48] <amitk> ogra_cmpc: lag: jeremy kerr had a patch in jaunty and/or karmic to convert the fec driver to use platform_driver. If that hasn't made it to mainline yet, it should
[14:49] <ogra_cmpc> amitk, right, would just be intresting to see how the autoloading of the module was handled in that
[14:49] <lag> amitk: Sounds like a good start
[14:50] <lag> Would you mind reducing my search area a bit?
[14:50] <ogra_cmpc> i guess looking at fec.c in our imx51 tree might be a start
[14:52]  * lag takes his sniffer-dog 'grep' from the kennel
[14:54] <lag> is "imx51" == "mx51 upstream maintainer tree"
[14:55] <ogra_cmpc> i would guess so
[14:55] <ogra_cmpc> but better ask a kernel person :)
[14:55] <lag> It's Amit's tree, so I guess I'm asking him
[14:55] <lag> amitk -^
[14:57] <amitk> lag: check the fsl-imx51 branch of the jaunty/karmic kernels
[14:58] <amitk> it isn't really a imx51 problem since the part is used on other platforms. So the driver is maintained by someone else
[14:58]  * lag wishes people would stop assuming he knows where stuff is and it a little more forthcoming with information 
[14:58] <lag> =;-)
[14:58] <lag> is*
[15:00] <amitk> it is called "institutional memory". :) All of it should be downloaded to wiki ideally, but not possible in practice.
[15:01] <lag> That would be a pointless exercise anyway, as the search doesn't work
[15:01] <lag> You'd have to know which page it's in and where do find that page
[18:25] <directhex> sigh. add some debugging printf to mono, mono stops throwing sigill...
[18:27] <ogra> sweet
[18:27] <ogra> just keep the printf ;)
[18:29] <directhex> just what every arm user needs - a list of detected arm abilities on every app execution
[23:38] <ogra_cmpc> GrueMaster, http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100630.6/
[23:38] <GrueMaster> must have just shown up.
[23:39] <GrueMaster> Checked 10 minutes ago.
[23:41] <GrueMaster> I'll have it in ~20 minutes.
[23:41] <davidm> I dont' see anything in that dir
[23:43]  * ogra_cmpc rsyncs already
[23:43] <ogra_cmpc> rsync isnt much better with bz2 files though
[23:47] <GrueMaster> ogra_cmpc: where are the image build logs stored?
[23:48] <ogra_cmpc> http://people.canonical.com/~ubuntu-archive/
[23:48] <ogra_cmpc> they are mirrored by a cronjob so you have to wait until they show up
[23:50] <GrueMaster> Too bad they can't be monitored in real time.
[23:51] <GrueMaster> Like the buildds.
[23:51] <ogra_cmpc> you can monitor the livefs build in real time from chinstrap
[23:57] <directhex> aha!
[23:57] <directhex> looks like it's not the thumb2 patch at all
[23:57]  * ogra_cmpc said so yesterday already 
[23:57] <ogra_cmpc> what is it then ?
[23:58] <directhex> the cpuinfo parsing patch. written by...
[23:58] <directhex> author	Loïc Minier <loic.minier@ubuntu.com>
[23:58] <directhex> sorry lool
[23:58] <ogra_cmpc> heh
[23:58] <ogra_cmpc> well, he improved the situation a lot with it iirc
[23:59] <ogra_cmpc> knowing that it wasnt perfect yet
[23:59]  * ogra_cmpc remembers a discussion about it