[00:18] <greghaynes> When I dd the natty headless omap4 image to an sd card and boot on panda board I get this: http://pastebin.pandaboard.org/index.php/view/7402008 Im running out of ideas on what could be causing this...anyone know?
[03:11] <chihchun> cooloney: hi
[03:25] <twb> Graah
[03:25] <twb> Looks like my TF101 was somehow on last week, and ran itself out of battery completely -- to the point where I couldn't even turn it on with the power plugged in via the dock, I had to plug the power directly into the tablet part
[03:34] <cooloney> chihchun: hi
[03:36] <chihchun> is omap3 porting also included in ti-oamp4 branch of natty kernel tree (2.6.38) ?
[03:42] <twb> lilstevie: I'm looking at u-boot/include/configs/tegra2_common.h:CONFIG_NETBOOT_SETTINGS, and I can't see where it loads the ramdisk.
[03:43] <twb> From the CrOS kernel config you're using, it looks like you make everything =y, so I guess you don't HAVE a ramdisk, but I'd kinda like one, if only so I can use it for rescue when root won't mount
[03:43] <twb> (yay busybox)
[03:58] <twb> Oh, I just realized the FAT version is loading a *u-boot script*, not a kernel directly from FAT
[04:01] <twb> Ah, OK, so fatload/ext2load copy a file into RAM at a specified address, and then source/bootm actually DO something with it.
[04:07] <twb> lilstevie: stupid question, but when you said that u-boot interactivity wasn't working -- did you try just removing the u-boot line that tells it to set console=ttyS0 ?
[04:08] <twb> nm, that would be the kernel, not u-boot.  I can see further down that stdin=serial,tegra-kbc and so on
[05:05] <twb> 15:05 <twb> I manually run "kbdrate -d 250 -r 30" and it is still set to 0
[06:58] <twb> lilstevie: can you show me an MBR-based nvflash flash.cfg?
[06:59] <lilstevie> when I wake up
[06:59] <twb> Sure thing
[06:59] <lilstevie> I am out of it :/
[07:00] <twb> Are you about to get up, or go to bed? ;-P
[07:00] <lilstevie> I have been napping
[07:00] <twb> afk for half an hour, beer
[07:01] <lilstevie> kk
[07:23] <Neko> is Unity3D all OpenGLES ready right now for Oneiric?
[08:58] <twb> back
[08:59] <twb> lilstevie: ^
[08:59] <twb> lilstevie: I was hoping you'd have made me a pastebin :P
[09:42] <rOxx> hello, i´m using beagleboard xm with an rtc battery and now i want to change the time epoch from 1970 to 2010, but with "sudo hwclock --setepoch --epoch=2010" i get the message "The kernel keeps an epoch value for the hardweare clock only on alpha machine. This copy of hwclock was build for a maschine other than alpha. No action taken."  someone can help me to change the epoch ?
[09:44] <twb> Why do you want to set the epoch?
[09:45] <twb> Everything else on unix uses an epoch of 1970
[09:45] <twb> If you just want to set the hw clock, you want hwclock -w
[09:46] <greghaynes> s/unix/known universe
[09:46] <rOxx> im using socketcan and the timestamps are calculated from the time epoch in seconds
[09:47] <rOxx> and now i want to change the time epoch, because the timestamps are to huge
[09:47] <greghaynes> too huge for what?
[09:48] <greghaynes> They should be <32bit
[09:48] <twb> signed, 32-bit time_t goes until 2038, right?
[09:48] <greghaynes> Somewhere around then
[09:49] <twb> I guess socketcan isn't using time_t then
[09:49] <twb> (https://secure.wikimedia.org/wikipedia/en/wiki/SocketCAN)
[09:52] <Neko> it uses timestamp
[09:52] <Neko> dsjfbdfkb
[09:52] <Neko> timeval :D
[09:52] <rOxx> yes but the timestamp i get from the sockets have the format struct timeval with time_t      tv_sec and suseconds_t tv_usec
[09:52] <rOxx> and time_t is count from epoch ?
[09:52] <Neko> sure
[09:52] <Neko> are you sure the time on your board is set right?
[09:53] <Neko> because when the rtc dies on some of my arm boxes, the time is 1969 and time_t values have wrapped around...
[09:53] <Neko> -1 time_t is just the same as 2 billion and it causes trouble..
[09:53] <rOxx> yes the time i set correct, i^m using init.d script to load the time from rtc with "hwclock -s"
[09:53] <twb> lilstevie: ping, did you fall asleep again :-(
[10:14] <twb> Should I be worried that file says uImage is a "u-boot legacy image", when I'm AFAIK using this new FIT/dtc stuff?
[10:34] <Neko> twb, yes..
[10:34] <Neko> it should print a bitchload of info too
[10:34] <twb> what, file?
[10:34] <twb> rootfs/boot/vmlinux.uimg: u-boot legacy uImage, Linux-<IP_ADDRESS>+, Linux/ARM, OS Kernel Image (Not compressed), 3135112 bytes, Fri Sep 23 19:17:03 2011, Load Address: 0x00008000, Entry Point: 0x00008000, Header CRC: 0x246D6351, Data CRC: 0x94ACEAFB
[10:34] <Neko> no, u-boot.. it should say something like "detected fit image" and then stuff going from there (lots and lots of lines)
[10:35] <twb> I haven't put u-boot in place yet
[10:35] <twb> And when I do, it won't have a working keyboard or screen, so I won't see that
[10:35] <lilstevie> they are legacy images
[10:35] <Neko> oh okay.. I wouldn't expect "file" to know the difference right now
[10:35] <lilstevie> it has screen
[10:35] <lilstevie> it prints out the same info that mkimage does if you tell it to read the information
[10:35] <twb> lilstevie: so I'm doing the right thing?
[10:35] <lilstevie> yes
[10:36] <Neko> therefore you're not using the fit/dtc stuff :)
[10:36] <lilstevie> yep :)
[10:36] <lilstevie> u-boot needs fit/dtc stuff to compile
[10:36] <twb> Neko: I sure needed to install dtc to get u-boot to build...
[10:36] <lilstevie> kernel isn't using it though
[10:36] <twb> Oh, OK
[10:36] <Neko> twb, yeah, u-boot always wants it to build, but it doesn't necessarily NEED it.
[10:37] <twb> lilstevie: is it u-boot.img or u-boot, that I write to the EBT partition?
[10:37] <lilstevie> u-boot.bin
[10:37] <lilstevie> I will pastie my config soon
[10:37] <lilstevie> it took me a bit to get the right location for MBR
[10:37] <lilstevie> so probably easier for me just to give that to you p
[10:37] <lilstevie> :p
[10:38] <twb> I hope so
[10:38] <twb> btw is the "no support for micro SD" because it's actually not supported, or just because the script doesn't try to use mmc device 2, but only usb, mmc1, mmc0
[10:39] <lilstevie> because there is no support for it
[10:40] <twb> OK, just checking :-)
[10:41] <twb> If I make an ext4 filesystem, can u-boot's ext2load read files from it, or will it freak out because of extents or something?
[10:44] <twb> BTW, should I be worried that u-boot.bin is like one-sixth the size of the original asus/android bootloader?
[10:44] <lilstevie> no
[10:44] <ndec> ogra_: hi. does banshee work for you?
[10:44] <lilstevie> because it is a different bootloader
[10:45] <ndec> the window opens, but it's all white for me
[10:45] <twb> And a substantially less bloated one :-P
[10:45] <lilstevie> also I have an ext2 fs for my u-boot partition
[10:45] <lilstevie> with a boot.scr kernel and initrd
[10:47] <twb> lilstevie: hm, can you also give me your CONFIG_EXTRA_ENV_SETTINGS for u-boot?  I wasn't sure what to put for e.g. the ramdisk's load address
[10:47] <twb> That is pastebin tegra2-common.h or so
[10:48] <ogra_> ndec, havent tried yet, file a bug :)
[10:49] <lilstevie> I read it to a location in my boot.scr
[10:49] <lilstevie> :p
[10:57]  * twb waits impatiently for MBR flash.cfg and uboot scripts
[11:15]  * twb pokes lilstevie
[11:20] <ndec> ogra_: LP#857299
[11:20] <ogra_> bug 857299
[11:20] <ubot2> Launchpad bug 857299 in banshee "banshee window remain white on startup on pandaboard" [Undecided,New] https://launchpad.net/bugs/857299
[11:20] <ogra_> NCommander will love this :)
[11:21] <ndec> ogra_: i always forget how to trigger ubot2 ;-)
[11:22] <ogra_> :)
[11:23] <ndec> ogra_: on my panda, the link vmlinuz and initrd.gz in /boot are wrong. is that normal?
[11:24] <ndec> they exist but point to non existing kernel
[11:25] <ogra_> upgrade ?
[11:25] <ogra_> or fresh install ?
[11:25] <ndec> upgrade
[11:27] <lilstevie> twb: http://pastebin.com/3SVrZ1PZ
[11:27] <twb> Yay
[11:28] <ndec> ogra_: vmlinuz is in / now?
[11:28] <lilstevie> env is because I have env_is_mmc
[11:28] <lilstevie> and offset to that specific location
[11:28] <ogra_> ndec, not really, no
[11:28] <lilstevie> UIM is my u-boot ext2 part
[11:29] <lilstevie> as for where I load my initrd that is ${loadaddr}+kernel_size+500kb to be safe
[11:29] <twb> Hm, OK.
[11:30] <twb> After the pivot_root, does the ramdisk space get GC'd?
[11:30] <twb> Because if so you could just always load it at 8MB or 16MB or something, to allow for huge kernels
[11:31] <lilstevie> no idea
[11:32] <lilstevie> thats why I do it close :p
[11:32] <twb> You set MBR type=data -- does that mean I have to write the MBR myself?
[11:32] <lilstevie> no
[11:32] <twb> Or does nvflash still do it based on the name or something
[11:33] <lilstevie> that is just nvflash being odd
[11:33] <twb> k
[11:40] <twb> You set allocation_attribute=8 instead of 0x808 -- does that mean "fill to end of disk, with no exceptions" ?
[11:40] <twb> lilstevie: also, why doesn't MPT have file_system_attribute=0 ?
[11:42] <lilstevie> don't ask me, ask nvidia :p
[11:42] <lilstevie> this is based off the ventana flash.cfg in the LDK
[11:42] <twb> I bet its because the nvidia engineer forgot
[11:43] <lilstevie> none of it is documented
[11:43] <twb> And they stripped the executable, so no debugging
[11:44] <lilstevie> if you are a hw partner you can get the BSP stuff, which includes the source code for nvflash
[11:44] <lilstevie> but even then, there is a lot that are PCHs
[11:44] <twb> only under NDA though, I expect, which defeats the purpose of getting it
[11:44] <lilstevie> so I hear anyway
[11:45] <lilstevie> yeah
[11:45] <twb> Well, here we go.
[11:48] <twb> Am I right in thinking that nvflash -bl needs to be given the original bootloader, not u-boot?
[11:49] <lilstevie> for flashing, yes
[11:49] <lilstevie> u-boot does not implement the flashing program
[11:51] <twb> Hmm, it didn't like me
[11:51] <twb> Maybe it doesn't like four-letter partition names
[11:51] <lilstevie> no
[11:51] <lilstevie> 3 only
[11:52] <lilstevie> less ok more not
[11:55] <twb> If you pass TERM=dumb, it disables that progress shit
[11:56] <twb> I think
[11:56] <twb> Never mind, it's still doing its mkfs-type step before copying to actual fs across
[11:57] <twb> But passing TERM=dumb did make it generate a lot less output during the upload step I think.
[11:58] <twb> Hm, no, it must be *just* screen that doesn't like its output.   I built it this way:
[12:12] <twb> make ventana_config DEV_SRC_TREE=tegra-tf101; PATH=/usr/src/dtc:$PATH make -j
[12:13] <twb> (I figured before fucking with its config I should make sure it was gonna work at all)
[12:15] <twb> I can't get it to turn on at all
[12:16] <lilstevie> I build with make ARCH=arm ventana CROSS_COMPILE=arm-linux-gnueabi- DEV_TREE_SRC="tegra2-tf101"
[12:16] <twb> Now, I did get an error *after* repartitioning and uploading all the images, from "./nvflash -r --sync --go"
[12:16] <lilstevie> what error
[12:16] <twb> I was compiling from a native chroot
[12:16] <lilstevie> ok so drop CROSS_COMPILE
[12:17] <twb> I just realized I did tegra-tf101 and you did tegra2-tf101
[12:17] <twb> Error was: [resume mode] \n failed executing command 25 NvError 0x8 \n command failure: sync failed
[12:18] <lilstevie> hm
[12:18] <twb> And then I saw the nvidia splash screen, which I think means the --go worked
[12:18] <twb> Then I just powered it off by holding to power button, since it was (understandably) not finding anything via the asus bootloader
[12:20] <twb> I'm not panicing yet, but this is sure acting like a brick
[12:21] <twb> The other thing I probably did different from you, was I was running dtc from git
[12:21] <twb> v1.3.0-6-g83df28b
[12:21] <lilstevie> yeah well you know you can go back into apx :p
[12:21] <twb> Well, that's a nice theory except it's not showing up in lsusb
[12:21] <lilstevie> press volup then hold power
[12:22] <lilstevie> monitor your lsusb it will show up very soon
[12:22] <lilstevie> unless your batt is flat
[12:22] <twb> I suppose that's possible
[12:22] <twb> The dock's battery is green
[12:23] <twb> OK, APX is back
[12:23] <twb> So now to work out what went wrong
[12:24] <twb> I think the problem is that I forgot the 2 in tegra2-tf101, so I built the wrong dtc
[12:24] <twb> Er, dts
[12:24] <twb> I'm surprised it didn't give an error at compile-time, though...
[12:26] <lilstevie> well personally I am going after serial
[12:27] <twb> haha, there is a dropbear.id.au
[12:27] <twb> (*.id.au names are supposed to be .au fauna)
[12:27] <lilstevie> lol
[12:29] <twb> The downside is that recompiling u-boot is gonna take a while, because until the tf boots again I'm doing it via qemu
[12:30] <twb> (Cross-compiling is too hard.)
[12:30] <lilstevie> just use the linaro compiler
[12:30] <lilstevie> cross compiling is easy
[12:31] <twb> Then I have to compile that, since its binaries aren't signed by Debian
[12:32] <twb> That or trust linaro, I mean.  Plus I have no idea what additional stuff is in linaro that isn't in Debian, and part of the goal here is to be as close to stock Debian as possible -- including bootstrapping everything
[12:39] <twb> lilstevie: how do I tell nvflash not to rewrite all the other partitions, since I'm only going to be uploading a new u-boot?
[12:39] <twb> lilstevie: do I just omit the --create option?
[12:41] <twb> ./nvflash --bct BCT.img --setbct --configfile flash.cfg --bl bl.img --odmdata 0x300d8011 --sbk 0x1682CCD8 0x8A1A43EA 0xA532EEB6 0xECFE1D98 --download 4 u-boot.bin
[12:42] <lilstevie> you cant
[12:42] <lilstevie> not for bootloader
[12:42] <twb> Well that's lame
[12:43] <lilstevie> it is nvflash being a pain
[12:43] <twb> In that case I guess you run a normal --create command, but on a flash.cfg that has all the file= lines removed?
[12:43] <twb> And all the type=ext[23] changed to type=data, to prevent it overwriting the existing filesystem with an empty one
[12:44] <lilstevie> nope
[12:44] <twb> I'm not gonna like the right answer, am i?
[12:44] <lilstevie> because it does format_all
[12:44] <lilstevie> well more to the point
[12:44] <lilstevie> it deletes all partitions
[12:44] <lilstevie> then creates and formats
[12:45] <twb> always?
[12:46] <lilstevie> yes
[12:47] <twb> You'd think with NAND flash they'd want to avoid a big bag of pointless writes
[12:50] <twb> So just to be absolutely clear: there's *no* way to upload a new u-boot, without also having to upload the entire root filesystem again?
[13:04] <brandini> hello all
[13:11] <siji> hello
[13:21]  * twb uploads a new, hopefully correct, u-boot
[13:26] <twb> OK, I uploaded a new u-boot, but skipped uploading the OS.img root filesystem, on the basis that I should at least be able to see u-boot on the screen even if u-boot can't find a kernel
[13:27] <twb> But it's still not turning the screen on...
[13:29] <brandini> :)
[13:31] <twb> I can't see what I did wrong
[13:31] <lilstevie> you know you can upload it as -bl to test
[13:31] <lilstevie> rather than writing every time
[13:32] <twb> No I didn't :-/
[13:32] <lilstevie> did you add ARCH=arm in the make command
[13:32] <twb> No, because I wasn't cross-compiling
[13:32] <twb> http://paste.debian.net/131770/
[13:32] <twb> That's the end of the compile run
[13:33] <lilstevie> file u-boot.bin
[13:33] <twb> http://paste.debian.net/131771/ managed to get the whole thing
[13:33] <twb> lilstevie: /usr/src/u-boot/u-boot.bin: ERROR: vasprintf failed (Invalid or incomplete multibyte or wide character)
[13:34] <lilstevie> file u-boot
[13:34] <twb> ELF 32-bit LSB shared object, ARM, version 1 (SYSV), statically linked, not stripped
[13:34] <lilstevie> hm
[13:35] <lilstevie> gcc vers?
[13:35] <twb> gcc (Debian 4.6.1-11) 4.6.1
[13:36] <lilstevie> hm
[13:36] <twb> If I ask Debian about it they will probably tell me to do the whole thing again from the ground up, on armel
[13:37] <lilstevie> some of the newer toolchains are broken for tegra
[13:37] <lilstevie> some hardware errata bs AFAIK
[13:37]  * twb carefully refrains from chucking tf101 through a window
[13:38] <twb> lilstevie: do you know which chains, or how I can test if a chain is broken?
[13:38] <twb> After all if debian's gcc is broken, then the userland is gonna be screwed even if I build the bootloader and kernel with something else
[13:39] <lilstevie> nah kernel works around this stuff
[13:40] <twb> So I should try building u-boot using an older gcc?
[13:40] <twb> 4.4 and 4.5 should be apt-gettable
[13:42] <lilstevie> well I use 4.4
[13:42] <twb> okey dokey
[13:44] <dmart> twb: this is a long shot, but have you tried exporting LC_ALL=C in the environment and rebuilding?
[13:44] <twb> Hm, LANG probably doesn't make it through chroot(8), lemme look
[13:45] <dmart> "multibyte character" sounds like locale-related encoding problems
[13:45] <twb> dmart: oh, you mean for file(1)
[13:45] <twb> dmart: nice one: /mnt/bar/rootfs/usr/src/u-boot/u-boot.bin:  Spectrum .TAP data "\024\237\024\237\024"
[13:46] <lilstevie> fuck this board
[13:46] <lilstevie> er
[13:46] <lilstevie> wrong chan
[13:46] <twb> haha
[13:46] <lilstevie> and excuse my language
[13:46] <twb> We were all thinking it
[13:46] <dmart> Of course, if the build itself is bad it doesn't solve that problem
[13:46] <lilstevie> the uart is burried in the JTAG port :/
[13:47] <lilstevie> well the only one I can trace
[13:47] <lilstevie> but don't know much more
[13:49] <twb> OK, off we go using gcc-4.4
[14:03] <twb> Donkey balls
[14:03] <twb> /usr/src/u-boot/lib/sha1.c: In function ‘sha1_process’:
[14:03] <twb> /usr/src/u-boot/lib/sha1.c:228:1: internal compiler error: in maybe_add_or_update_dep_1, at sched-deps.c:845
[14:04] <twb> So qemu won't let me compile u-boot using gcc-4.4
[14:06] <twb> At this point I am thinking instead of using userspace emulation on my netbook, I should just use qemu host emulation on one of the chunky buildds in the office
[14:21] <twb> Same problem in gcc-4.5
[14:21] <twb> So until I either get qemu up or reflash this with ubuntu, I'm at an imp-arse.
[14:21] <twb> a.k.a. bed time for twb
[14:39] <brandini>  try and fix this golang test failing
[14:39] <brandini> ok, I've forgotten to install the OMAP4 stuff from TI and I wonder if I should do that to
[14:39] <brandini>  try and fix this golang test failing
[14:39] <brandini> phew
[16:14] <sniperjo> I'm running angstrom, a beagle board version. Should i in theory be able to use an ubuntu beagle board version ?
[16:16] <GrueMaster> sniperjo: angstrom is more generic, but you may have some luck with the oneiric omap images as thy are more mainstream.  Just remember that not all of angstrom's kernel bits are upstream, whereas ubuntu pulls the kernel directly from upstream.
[16:17] <sniperjo> GrueMaster: ok thanks, I'm desperate here
[16:24] <jkridner> GrueMaster: ubuntu also patches the upstream kernel.  we are always trying to reduce the patches in both Angstrom and Ubuntu by moving more stuff upstream.
[16:42] <rsalveti> jkridner: do you know about the pm/smartreflex support at upstream? want to have my xm working at 1ghz :-)
[16:42] <rsalveti> have a bug for ubuntu, bug 771537
[16:42] <ubot2> Launchpad bug 771537 in linux "Beagle XM lacks proper 1Ghz support" [Medium,In progress] https://launchpad.net/bugs/771537
[16:43] <rsalveti> don't know yet if we're already able to have it working with upstream properly, didn't have time to look around for the patches still
[16:46] <GrueMaster> jkridner: What I meant was that unless a system is in our hands, we only support what the upstream kernel supports.  If support for the system that sniperjo is using isn't in the main kernel tree, we really have no way to support it directly.
[16:47] <sniperjo> GrueMaster: Texnexion is also on the beagle board website
[16:47] <sniperjo> not sure what that has to do with anything… but i just though i would put it out there
[16:48] <GrueMaster> That doesn't mean I have one here to test with.  My hardware budget is semi-limited and I already blew it on multiple pandas (and support hardware) for server testing.  Now, if you want to supply me with one...
[16:48] <sniperjo> GrueMaster: If you have it up and running for me, consider it done
[16:49] <sniperjo> it has been done http://www.youtube.com/watch?v=vWYHk15QOTo
[16:49] <GrueMaster> Not that I would be able to get to it this cycle.  I really am overloaded at the moment.
[16:49] <GrueMaster> I have a Nook Color that was my pet project to get running.  So far, I have barely had time to root it (since May).
[16:51] <sniperjo> GrueMaster: I am getting to the stage, where paying for someone to get it working, could be a viable option
[16:52] <GrueMaster> That video has a link to our RootFromScratch page, which indicates to me they built their own chroot environment (similar to ubuntu-core), which is what I suggested to you twice now.
[16:54] <GrueMaster> And I know getting Ubuntu running on non-supported hardware can be done.  I did it using Natty Alpha on a Tegra 2 development platform using their boot loader & kernel.
[16:54] <sniperjo> GrueMaster: i have managed to chroot into a card, but i diddnt have internet connectivity
[16:54] <jkridner> rsalveti mike turquette is supposed to be sending an updated ABB patch.  PM patches are rebased on Kevin's branch on Tony's tree, but more work is required before going upstream.  We pull in the last patch set into OE.
[16:54] <GrueMaster> That may be a kernel issue.  Make sure the ethernet module for your system is loaded.
[16:55] <jkridner> rsalveti: I believe rcn-ee has an ubuntu-style kernel.  I'm sure you must watch it.
[16:55] <jkridner> rsalveti: rcn-ee is pretty good at tracking whatever koen hacks on (and koen follows khilman and tmlind).
[16:55] <rsalveti> jcrigby: cool, would like to check that patch set
[16:55] <rsalveti> yeah
[16:56] <rsalveti> even to enable it properly at linaro
[16:56]  * rsalveti updating his oe tree
[16:57] <jkridner> rsalveti I saw khilman sending arnd patches yesterday for PM.  I don't think it included the ABB support for 1GHz xM, but you can probably set the 1GHz OPP without it and not have too many headaches.
[16:57] <rsalveti> jcrigby: which kernel version are you using as base?
[16:57] <rsalveti> jcrigby: yeah, cool
[16:57] <sniperjo> GrueMaster: how would i find out what my ethernet module was ?
[16:58] <GrueMaster> sniperjo: There are a lot of things to check as to why you don't have networking.  First, look at dmesg to see if the kernel detects the network device.  Second, read the documentation to determine what type of device it is.  If it is usb, lsusb should see it.
[16:58] <GrueMaster> If it is seen, the driver loaded, and dmesg indicates link detected, then maybe you just need to run dhclient eth0.
[17:00] <jkridner> rsalveti: I'd be happy to point you to my 3.0.4 kernel (from koen) that supports 1GHz.
[17:00] <sniperjo> i do have libertas: wlan0: Marvell WLAN 802.11 adapter
[17:01] <rsalveti> jkridner: cool, want to have a look at that
[17:01] <rsalveti> having 1ghz support for our 11.09 would be awesome
[17:15] <jkridner> rsalveti http://gitorious.org/beagleboard-validation/linux/commit/c8f49b6a6cbcb3b2627388cee438096381b41913
[17:30] <rsalveti> jkridner: great
[17:30] <rsalveti> jcrigby: which branch is that, still cloning the tree
[17:33] <jcrigby> rsalveti, is you tab completion expanding to jcrigby when you mean jkridner ?
[17:33] <rsalveti> hahah :-)
[17:33] <rsalveti> that was for jkridner :-)
[17:34] <rsalveti> jcrigby: sorry ;-)
[17:34] <jcrigby> np, my brain is in a fog so I just wanted to make sure
[17:34]  * rsalveti needs food, out for lunch
[17:38] <jkridner> rsalveti I think it is ulcd-android-20110917b
[17:38] <jkridner> there actually aren't any android patches on it...
[17:39] <jkridner> but, I was looking at pulling in the Linaro android patches and this tree was at the base point where I was going to apply the patches
[17:39] <jkridner> I got held up on TLS incompatibilities.
[17:40] <jkridner> I was able to cherry-pick a bunch of the Linaro Android patches, but the Android file system I have has an emulated TLS.
[17:40] <jkridner> :(
[18:02] <gildean> ogra_: tested yesterdays image, installation goes through without a hitch, even with selecting keyboard-layout etc.
[18:03] <gildean> on the ac100 that is
[18:04] <prpplague> GrueMaster: ping
[18:04] <GrueMaster> prpplague: pong
[18:05] <gildean> ogra_: also did it by the wiki with another computer with clean ubuntu install, with installing nvflash from .deb etc.
[18:05] <gildean> so the installation-guide is also tested to be accurate
[18:10] <prpplague> GrueMaster: hey, we need to look into the ppa stuff for the 10.10 release
[18:11] <prpplague> GrueMaster: i along with about 5 others have been trying with no success on installing them
[18:11] <GrueMaster> Yep, I'm working on that now.  Have to flash a new SD with the image.  Should be ready in 20-30 minutes.
[18:14] <GrueMaster> It may be that universe and multiverse need to be enabled iirc.  But I want to verify that first.
[18:30] <prpplague> GrueMaster: yea tried enabling those
[18:37] <GrueMaster> prpplague: I am booting up now.  Will let you know what I find soon.
[18:37] <prpplague> GrueMaster: ok thanks
[18:45] <brandini> w00t, I had to comment out that one test for go in order to get go installed
[19:23] <GrueMaster> prpplague: I just finished booting into maverick (I got distracted a little).  When I initially tried to install the extras, it failed due to gstreamer & faac packages.  Adding universe and multiverse to /etc/apt/sources.list fixes that.
[19:23] <GrueMaster> Will document on wiki.
[19:23] <prpplague> GrueMaster: which instructions were you using ?
[19:24] <prpplague> GrueMaster: are you adding the univer and multiverse from the gui?
[19:25] <GrueMaster> I didn't.  I just logged into the maverick image and tried the link for the ti extras.  When it failed, I opened a terminal and tried "sudp apt-get install ubuntu-omap4-extras-multimedia".  Then figured it out from there.
[19:26] <GrueMaster> No, but I will document it in the release notes.
[19:26] <GrueMaster> This was a known issue for maverick (missing universe & multiverse).
[19:26] <prpplague> GrueMaster: ok, document what you got and i will try to replicate
[19:26] <prpplague> GrueMaster: the instructions we have on omapedia are for using the GUI
[19:27] <brandini> HAH! Anyone want to see how fast the pandaboard serves up requests?
[19:27] <brandini> mind you my BW is limited to 768 outbound
[19:27] <brandini> http://eutonian.ath.cx
[23:30] <cospan> hello, I have a beagleboard XM with ubuntu desktop on it. I want to understand how to trigger events from the user button. I thought all I had to do was build a new kernel after modifying the <kernel base>/arch/arm/omap/mach-omap2/board-omap3beagle.c, compile the kernel and copy the vmlinuz into ubuntu's /boot directory and adjusting the symbolic link to run it, but I looked for the events, and inputs within the sysfs director