[04:10] <lilstevie> dcordes
[08:14] <ndec> ogra_: hi
[09:47] <ogra_> hey ndec
[09:47] <ndec> ogra_: just wanted to confirm that I will be at UDS, from Mon to Wed.
[09:48] <ndec> Wed all day
[09:48] <ogra_> awesome !!!!!
[09:49] <ogra_> dont forget to register on LP
[09:49] <ogra_> ;)
[09:49] <ndec> ogra_: that's done ..
[10:47] <cooloney> ndec: welcome, man
[10:49] <hrw> ndec: cool
[14:37] <ppisati> guys, did you ever use jtag on the mvl-dove board? and if yes, which hw/sw did you use?
[14:37] <ppisati> have you ever tried with openocd?
[14:39] <ogra_> i dont think anyone has touched dove in over a year
[14:39] <ppisati> yep
[14:39] <ogra_> (and i dont think anyone in the team is eager to do so)
[14:39] <ppisati> :)
[14:39] <ppisati> no no
[14:39] <ppisati> it's just that i'm debugging an issue on ti-omap3/4
[14:39] <ppisati> and to me, it looks like a stack corruption
[14:39] <ogra_> we had a special dongle for jtag iirc
[14:40] <ppisati> so i would like to see how it works on another arm platform
[14:40] <ppisati> i have a fly swatter and i'm using openocd
[14:40] <ppisati> i just need to know which profile i should use
[14:40] <ppisati> BTW
[14:41] <ogra_> ppisati, asl pprplague
[14:41] <ogra_> *ask
[14:41] <ppisati> as far as you know, is our dove equal to a sheevapolug?
[14:41] <ogra_> no, not at all
[14:41] <ppisati> uh ok
[14:41] <ogra_> its similar but not equal to the armada chip
[14:41] <ppisati> ok
[14:41] <ogra_> its a completely experimental platform
[14:42] <ppisati> i see
[14:42] <ogra_> talk to NCommander for more details, he maintained the port
[14:42] <ppisati> ooooook
[14:43] <ppisati> btwm who is pprplague?
[14:43] <ogra_> works at tincantools and is a contractor at TI afaik
[14:43] <hrw> prpplague is good person to ask about JTAG stuff
[14:44] <ppisati> oh cool
[14:44] <ppisati> my jtag is from tincantools :)
[14:44] <ogra_> thats why i pointed you to him ;)
[14:45] <ppisati> ok, i'll chase him
[14:45] <hrw> my jtag equipment is from openmoko
[14:47] <ppisati> anyway, i senti an email to saeed
[14:48] <ppisati> let's see if he knows the correct profile/cpu for our dove board
[15:41] <rsalveti> ndec: https://launchpad.net/~rsalveti/+archive/unity-3d-gles/
[15:43] <rsalveti> ndec: activate the ppa, install compiz-core and compiz-gnome then once you have your unity-2d session up and running call "compiz --replace composite opengl move resize decor"
[15:51] <hrw> rsalveti: compiz gles will land in oneiric?
[15:52] <rsalveti> hrw: that's the idea
[15:52] <rsalveti> I believe that will be the natural path once Amaranth merge his branch with upstream
[15:52] <rsalveti> but still need more love to make it work properly
[15:53] <hrw> one step closer to desktops
[15:54] <ndec> hrw: you meant to modern desktop... as it's already a desktop
[15:54] <hrw> ndec: my desktop is not modern then - no compiz
[15:54] <hrw> ;D
[15:55] <ndec> hrw: could it be that you are not modern ;-)
[15:55] <ogra_> pfft, unity-2d is so much better anyway
[15:55] <ndec> ndec: have to admit that I don't use unity3d, but standard desktop, but i still use the effects...
[15:55] <hrw> ndec: if modern==use-unity then I will never be modern
[15:56] <hrw> [ 1422.107879] Buffer I/O error on device mmcblk0p2, logical block 326038
[15:56] <hrw> [ 1426.970520] mmcblk0: error -110 transferring data, sector 6924832, nr 8, card status 0xc00
[15:56] <hrw> I hate SD cards
[15:56] <ndec> hrw: not what i meant... i am not using it either.
[15:56] <hrw> [ 1411.778564] JBD: I/O error detected when updating journal superblock for mmcblk0p2.
[15:56] <hrw> [ 1411.786682] journal commit I/O error
[15:56] <rsalveti> hrw: panda or beagle?
[15:56] <hrw> panda
[15:56] <hrw> EA1/ES2.0
[15:57] <hrw> rsalveti: I hope that at luds-o there will be some good non-TI boards available for linaro people
[15:57] <hrw> I am tired of omap[34] based boards
[15:58] <ogra_> well, make nvidia sign up :)
[15:58] <ogra_> get an ac100
[15:58] <rsalveti> hrw: don't know when we'll be getting snowballs, and also not sure about the current state of the sw for it
[15:59] <rsalveti> but that will be an option soon
[15:59] <hrw> ogra_: as linaro engineer I should use linaro hw so even ac100 will not free me from using other boards ;S
[15:59] <rsalveti> nvidia is harder, they don't want to play the opensource game correctly
[15:59] <GrueMaster> rsalveti: We get those every year in winter.  Oh, you were referring to something else.
[15:59] <rsalveti> GrueMaster: hehe :-)
[16:00] <hrw> GrueMaster: snowball is ST-Ericsson A9 board
[16:00] <GrueMaster> Ah, my bad.  :P
[16:00] <ogra_> GrueMaster, well, keep the software after you melted one ;)
[16:00] <ogra_> in a bucket :)
[16:01] <Neko> oh hey I have a comment on the Oneric goals thing for ARM.. I think supporting a raw partition for kernels etc. is kind of a weird idea. Any attempt to override some kind of filesystem management of kernels is going to just make everyone hyper-reliant on flash-kernel to update their systems where it could just be n ext2 partition. There's absolutely nothing wrong with U-Boot ext2 support (except one weird error code which we have a patch for :)
[16:01] <Neko> I forget who's little braindump that was listed under, maybe rsalveti?
[16:01] <ogra_> no, it was mine
[16:01] <rsalveti> ndec: at this ppa you can also grab the unity-2d package, I enabled the qt gles backend by default on it
[16:02] <Neko> is it specifically to support weirdo systems like AC100 that don't actually run U-Boot?
[16:02] <ogra_> with the redesigned flash-kernel it shouldnt be a prob to rely on it ;)
[16:02] <rsalveti> ndec: but for that you'll need the latest driver at omap-trunk ppa, I exposed EGL_NV_post_convert_rounding so Qt can work fine with the PVR driver
[16:02] <ogra_> no, it is mainly for the crappy vfat stuff we have to use to boot from
[16:02] <rsalveti> ndec: would be good to fully implement this extension later, will follow that on an email
[16:02] <Neko> a real redesign or the "loic jiggling"?
[16:03] <hrw> ogra_: try uboot-as-linux-kernel way?
[16:03] <ogra_> the debian redesign thats going on since a year or so
[16:03] <ogra_> yes, loic works on that too
[16:03] <hrw> ogra_: nokia n900 devs got that way
[16:03] <ogra_> and i will too
[16:03] <ogra_> hrw, for what ?
[16:03] <hrw> "echo b >/proc/sysrq-trigger" - best command on panda
[16:03] <Neko> making bootloaders data driven is an expensive configuration nightmare.. every time it needs new data for each board, there's a new little bit of code that ends up being board specific just to make it boot. I don't think you can encapsulate bootloaders in a generic way and still capture all their useful features.
[16:04] <hrw> ogra_: for ac100?
[16:04] <ogra_> hrw, why ?
[16:04] <ogra_> i have a pertty good bootloader atm
[16:04] <ogra_> no need to change it
[16:04] <hrw> ok then
[16:04] <Neko> my primary concern though was the fact that flash-kernel was not designed to run off kernel hooks, I am glad you brought that up
[16:04] <Neko> it needs kicking 10 other packages in other arches though
[16:05] <ogra_> well, initramfs-tools upstream did
[16:05] <Neko> initramfs-tools calling flash-kernel if it exists causes a bunch of weeeeeeeird hacks to be required
[16:05] <ogra_> i wouldnt have changed the way flash-kernel is used atm if upstream would have agreed on my bug suggestion
[16:05] <ogra_> ??
[16:05]  * ogra_ hasnt seen any weird hacks that would require
[16:07] <Neko> they're in ubiquity.. some sort of "move flash kernel out of the way, then install the right kernel, then put flash kernel back, then install uboot-tools and so on which triggers update-initramfs" hacks to make flash-kernel run only once on install
[16:07] <ogra_> adding a huge amount of complexity that isnt needed imho is not really what i was after when filing my bug
[16:07] <ogra_> that bit will not change at all
[16:07] <ogra_> the flash-kernel-installer wont be touched ... it is for doing the initial setup, nothing else
[16:08] <ogra_> the kernel postinst integration wont change that
[16:09] <ogra_> nor will the redesign of flash-kernel change the need to have an initial setup of the bootloader from the installer
[16:09] <Neko> if flash-kernel just worked exactly like update-initramfs (taking an updated ramfs and flashing it or prepping it, taking an updated kernel and flashing it or prepping it, update boot script, and a final "commit it all if not done already") so it can be run in stages and only flash individual parts.. and more importantly happen before update-notifier is called so the little red "you need to reboot" icon isn't shown
[16:09] <ogra_> what might change is that it will get as horridly complex as grubs setup is already
[16:09] <Neko> which relies on that, and the idea that kernel hooks are numbered like udev rules, sysctl rules, and everything else
[16:09] <Neko> alphabetical, filesystem sorted order is a terrible idea
[16:09] <ogra_> since we will mostlxy focus on moving flash-kernel to be treated similar
[16:10] <Neko> as long as that doesn't mean it's called zz-flash-kernel... :0
[16:10] <ogra_> and grub is a complex and ugly beast
[16:11] <ogra_> it will be called whatever is required
[16:11] <Neko> flogging a dead horse here aren't I
[16:11] <ogra_> we wont change initramfs-tools or the kernel postinst mechanism
[16:11] <ogra_> we will adjust flash-kernel to work with the existing implementations instead
[16:12] <Neko> no need to change the mechanism just the script names so you can standardize on what order things run without it being reliant on locale sort order and filesystem case sensitivity and all kinds of other possible freakish flags that apply to a directory listing of files
[16:12] <Neko> the same decision that was made for udev, sysctl, every other rules/hooks/triggers system on Debian and Ubuntu (and every other distro too..)
[16:12] <ogra_> well, then we will follow exactly that sheme
[16:13] <dcordes> lilstevie: pong
[16:13] <dcordes> Hi !
[16:14] <Neko> all it takes is like 50-update-initramfs, 90-flash-kernel-commit, 99-update-notifier (90-update-grub for x86...) instead of it having no explicit numerical ordering
[16:14] <lilstevie> dcordes: fixed usb :p
[16:16] <dcordes> lilstevie: what was the problem ?
[16:16] <Neko> and if you need to do it in steps and handle anything between certain standardized kernel hook numbering scheme, you can do it without trying to predict what letter other packages start the names of their hooks with
[16:16] <dcordes> lilstevie: I have been thinking about it a lot, your strange binary init etc
[16:16] <ogra_> Neko, initrd hooks have a builtin dependency system, no need for file ordering
[16:16] <Neko> sysctl.d has a quite well defined numbering for system things, user things, board specific weirdnesses...
[16:16] <lilstevie> dcordes: a param
[16:16] <dcordes> lilstevie: and how it would disabale usb
[16:16] <dcordes> lilstevie: CMDLINE ?
[16:16] <Neko> ogra, talking about kernel postinst hooks
[16:16] <lilstevie> dcordes: bootloader pram sets it
[16:16] <dcordes> and how does it pass it to the kernel? is it kernel commandline ?
[16:16] <Neko> I thought one of the things that got thought but dropped for Natty was "we want to get rid of initramfs because it's annoying, slows down boot, and AC100 doesn't have enough space for it anyway"
[16:16] <lilstevie> dcordes: we have this weird partition that has the params, when the kernel module gets loaded, it loads in usb state
[16:16] <ogra_> ac100 isnt officially supported
[16:17] <ogra_> and we wont get rid of initramfs
[16:17] <Neko> x86 and ARM already rely on the concept that the bootloader can understand a Linux filesystem and it would be rather weird to have a Linux kernel that could not read its root filesystem
[16:17] <dcordes> ogra_: what does it take to make it officially supported ?
[16:18] <Neko> wouldn't Toshiba have to ship an official Unlock Android tool so you can root it? :)
[16:18] <ogra_> dcordes, a contract with nvidia with either canonical or linaro i would guess
[16:18] <Neko> and then install any OS you like?
[16:18] <ogra_> dcordes, i plan to produce an unsupported community image in 11.10 though
[16:18] <lilstevie> dcordes: I also found out that the bootloader can boot the baseband, havent figured out how to make it do it though
[16:18] <dcordes> lilstevie: hm I don't know oyur SoC. in qsd8250 we have some cpu parameters we set in the bootloader. that is on a very low level, now kernel involved. I don't understand what role your usb bootloader parameters have
[16:19] <dcordes> lilstevie: what is your SoC anyway ?
[16:19] <lilstevie> hummingbird
[16:19] <ogra_> now that we have a proper kernel and many ac100 bits are mainlined
[16:19] <lilstevie> ogra_: heh that sounds nice
[16:19] <lilstevie> dcordes: the driver takes the param
[16:20] <lilstevie> dcordes: but i had to load the module that reads the params
[16:20] <dcordes> lilstevie: ok that's interesting. do you have a place to document all this ?
[16:21] <dcordes> lilstevie: I bet many could benefit from that
[16:21] <lilstevie> dcordes: kinda, I am trying to get a new place sorted out
[16:21] <lilstevie> I just started a twitter for the project :p
[16:23] <Neko> yerg, 200kb/s for a torrent download of natty? my life is over :(
[16:23] <Neko> excuse me while I go and kick the internet in the pants
[16:23] <dcordes> lilstevie: did you try unity-2d on galaxytab yet ?
[16:23] <lilstevie> dcordes: yes
[16:24] <dcordes> lilstevie: does it work well? any flickering ?
[16:26] <lilstevie> only problem I have with it is when I use gestures too many times my touch driver stops working correctly
[16:36] <dcordes> lilstevie: sounds good
[16:37] <dcordes> unity-2d flickering on htcleo (hd2) seems to be a device specific thing
[16:37] <dcordes> our framebuffer driver has room for improvement
[16:37] <lilstevie> my touch driver has room for improvement :p
[16:38] <dcordes> well congrats you have it working at all !
[16:39] <dcordes> I would be happy to further improvement hd2 multitouch support - with ginn I had some first success in maverick. but now I can't really go on due to the flicker problem
[16:39] <dcordes> I was looking to make use of the working mt in unity..
[16:42] <lilstevie> heh it is why I pushed the update button for natty
[16:45] <dcordes> the problem is there is nothing much I can do about it. personally I lack the capability to improve the driver
[16:46] <lilstevie> ah
[16:46] <dcordes> somebody was working on proper driver (xf86-video-msm) for our device
[16:46] <lilstevie> nice
[16:49] <dcordes> I even have a kernel binary with it
[16:50] <lilstevie> :o