| cwillu_at_work | Selecting previously deselected package linux-image-2.6.33.4-l3. | 00:00 |
|---|---|---|
| cwillu_at_work | (Reading database ... Unsupported ioctl: cmd=0xffffffffc020660b | 00:00 |
| cwillu_at_work | repeat x100 | 00:00 |
| cwillu_at_work | seems to be proceeding though | 00:00 |
| rcn-ee | yeap, that's normal inside the machine.. it's weird.. | 00:00 |
| cwillu_at_work | amusingly, my server has already caught up with the beagle | 00:01 |
| cwillu_at_work | the beagle's been running 6 hours | 00:01 |
| rcn-ee | i'm tempted to ask for your package list for comparisson... I'm slowly untarring 1Gig onto a sd card... | 00:01 |
| cwillu_at_work | I'm not using sata drives :p | 00:02 |
| === jmcgee is now known as jmcgee|gone | ||
| cwillu_at_work | re: btrfs, the annoying thing is that there's a tonne of features which are going to be easy to implement, but very few _have_ been implemented yet | 00:04 |
| cwillu_at_work | basically the answer to every cool question is "not yet" | 00:04 |
| cwillu_at_work | separate raid levels per folder/file? not yet | 00:04 |
| rcn-ee | even so, it looks interesting.. | 00:04 |
| cwillu_at_work | online scrubbing? not yet (although you can fake it from userspace) | 00:04 |
| cwillu_at_work | oh, absolutely | 00:04 |
| cwillu_at_work | it's only very recently that you could actually delete snapshots :) | 00:05 |
| cwillu_at_work | hence why I didn't think about it until I already started: been using it 9 months on this box, and it's only been possible to delete in the last month :) | 00:05 |
| cwillu_at_work | honestly, you should start hanging out in #btrfs; the visibility will help, and you'll pumped hearing about it :) | 00:06 |
| cwillu_at_work | "cwillu: hey, if I saw ubuntu/canonical devs in here I'd be all for it." | 00:07 |
| cwillu_at_work | "but from what I see, it'd be a bunch of uninform | 00:08 |
| cwillu_at_work | ed n00bs in here complaining about how btrfs broke their systems and us telling | 00:08 |
| cwillu_at_work | people to update and no updates put into any ubuntu kernels | 00:08 |
| cwillu_at_work | " | 00:08 |
| cwillu_at_work | this is an image problem that could be solved very easily :) | 00:08 |
| rcn-ee | those groups of people are always fun to deal with.. ;) | 00:09 |
| cwillu_at_work | the people in question are quite nice actually :p | 00:09 |
| cwillu_at_work | oh, _that_ group | 00:10 |
| cwillu_at_work | the guy who said that spent a couple hours with me updating the btrfs wiki with debian/ubuntu instructions to update btrfs via dkms (which is currently the only recommended way of using btrfs) | 00:10 |
| cwillu_at_work | update btrfs from git via dkms, rather | 00:11 |
| rcn-ee | dkms makes sense if your using a normal supported ubuntu kernel.... quick updates... | 00:12 |
| DanaG | Now we just need dkms for powervr. =รพ | 00:12 |
| rcn-ee | we need mimotrace for arm... ;) then reverse engineer the suckker...; ) | 00:13 |
| persia | From what i heard at UDS, we ought be able to do something with DKMS+jockey for powerVR for OMAP. | 00:13 |
| DanaG | Hallelujah. | 00:13 |
| persia | Also, DKMS should work for *any* kernel, as long as one packages the kernel and installs the headers, etc. | 00:13 |
| DanaG | Since the TI build script is just a miserable failure. | 00:13 |
| rcn-ee | well the TI SGX bits are gpl.. (i've just recently add those modules into my dev tree 2.6.34's..) it's the binary blob libGL and loader that's the problem.. | 00:14 |
| rcn-ee | (kernel modules bits) | 00:14 |
| DanaG | I'm also curious how GL ES works... and if I could use it on Radeon KMS. | 00:14 |
| persia | Right. The loader would be the bit that would be DKMS, and the binary blob would be handled by jockey. The analogy that I heard at the OMAP session at UDS was to how nVidia works on x86 (assuming no nouveau) | 00:15 |
| rcn-ee | i think we can... but i don't know if r300g is hocked up to the egles bits.. (both are in mesa0 | 00:15 |
| persia | DanaG: GL ES is just a subset of GL. | 00:15 |
| rcn-ee | actually the loader doesn't need DKMS.. just a binary deb ... | 00:15 |
| persia | So anything that supports GL automatically supports GL ES | 00:15 |
| DanaG | My hardware is RV635, to be specific. | 00:15 |
| DanaG | hmm, I wonder if fglrx would support it on bare console. | 00:15 |
| cwillu_at_work | persia, did they say anything about how to acquire the binaries in the first place though? | 00:15 |
| persia | rcn-ee: Well, except it's hard to distribute raw binaries :) | 00:16 |
| cwillu_at_work | persia, the typical process involves sending a request to ti with a corporate email address purporting to be doing oem design work | 00:16 |
| persia | cwillu_at_work: No. If we can find some that are licensed appropriately, we can toss them in multiverse, which would seem the least painful solution to me. | 00:16 |
| cwillu_at_work | that's a pretty big if | 00:17 |
| rcn-ee | yeah.. specially with TI's export license... the key thing, if the gpl modules are built with the kernel, then all you need is the loader/libGL which don't need gcc to build.. | 00:17 |
| DanaG | persia: something that would work: a script like fwcutter. | 00:17 |
| persia | Well, there were folks from TI at the session, and they seemed interested in making it work. I'm not sure how far anyone will get. | 00:17 |
| DanaG | Feed it the x86 .run. | 00:17 |
| persia | DanaG: How do you mean? | 00:17 |
| cwillu_at_work | DanaG, fwcutter is an option because you have the right to have the binary you're cutting from | 00:17 |
| cwillu_at_work | that isn't the case here | 00:18 |
| DanaG | I mean a bit more manual, though. | 00:18 |
| DanaG | Have people download from TI, then feed it to a script. | 00:18 |
| cwillu_at_work | or rather, finding a binary where it _is_ the case is the tricky part | 00:18 |
| persia | If TI can post it for anyone to download, TI can probably allow it to be in Multiverse. | 00:18 |
| rcn-ee | or we got to talk ti into makeing a arm based *.bin loader.. ;) | 00:18 |
| rcn-ee | instead of the pure x86.. | 00:18 |
| persia | I think the issue is that TI is constrained (it's not actually a TI part, just bolted into a TI part) | 00:19 |
| rcn-ee | (the binary they distrubt that contains all the junk) | 00:19 |
| cwillu_at_work | yes, that's exactly the problem | 00:19 |
| rcn-ee | yeap, and that's the same problem intel (pousble) and freescale have... | 00:19 |
| cwillu_at_work | they licenced the powervr core, just like they licenced the arm core | 00:19 |
| cwillu_at_work | and the powervr core's terms are fairly onerous | 00:19 |
| rcn-ee | i've also heard from rumours, mali isn't much better.. so there really isn't a good one yet.. | 00:20 |
| persia | Well, the solution for other architectures has often been to expose a bus and make it someone else's problem :) | 00:21 |
| DanaG | I wonder how similar gma500 and this SGX are.... | 00:22 |
| DanaG | it'd be amusing if the GL code were exactly the same, except for target architecture. | 00:22 |
| * rcn-ee chears come on oem-config.... you can load! | 00:22 | |
| rcn-ee | the arch between the cores according to wikipedia looks similar... | 00:23 |
| cwillu_at_work | perhaps everyone's favourite space tourist should buy a redistributable licence :p | 00:23 |
| persia | From rumours I've heard, PSB is the reference SGX implementation. Dunno how true this is. | 00:23 |
| DanaG | I'd rather have a radeon. | 00:24 |
| DanaG | ARM + Radeon would be fun. | 00:24 |
| persia | cwillu_at_work: May not be possible, really. Some of this stuff is so many levels deep in restrictions that it would take years for the legal work, even if everyone wanted it to happen yesterday. | 00:24 |
| * cwillu_at_work inquires about the possibility of adding a pci-e port to the beagle-xl :p | 00:24 | |
| rcn-ee | i'm tempted to get one of those mini-pci express to pci express adapter do that that once my tegra 2 comes... | 00:24 |
| persia | DanaG: You can do that with the MVL Orions (but not with Ubuntu, as that's ARMv5). They have PCIe. | 00:25 |
| DanaG | hmm, is there yet an armv7l marvell? | 00:25 |
| cwillu_at_work | more importantly, is there a multithreaded dpkg yet? | 00:25 |
| rcn-ee | the armanda's i haven't seen any reference designs yet wit pci x.. but they will be coming... | 00:25 |
| cwillu_at_work | image building is fast enough that I can get impatient with it :) | 00:25 |
| persia | DanaG: Not that I've heard about in retail. There's a "dove" kernel in the archive. | 00:25 |
| DanaG | PCIe, rather. | 00:26 |
| DanaG | "X" is that old long server PCI thingy. | 00:26 |
| DanaG | "extended". | 00:26 |
| persia | 128 bit, wasn't it? | 00:26 |
| persia | Or, rather, isn't it (still available on some boards) | 00:26 |
| rcn-ee | yeah and 3.3volt signaling... yuck.. pain in the rear on my server... | 00:26 |
| persia | Well, pre multi-lane PCIe, it was better than what else was available :) | 00:28 |
| rcn-ee | i'm just annoyed, as it the only slot aviable on my 1U, and all i can get is network/pata/sata boards.... | 00:29 |
| * rcn-ee calling it good, starts a slow 305Mb xfce demo image upload to rcn-ee.net... ;) | 00:30 | |
| * cwillu_at_work starts downloading kernels from rcn-ee.net in a loop | 00:31 | |
| * rcn-ee hopes cwillu_at_work doesn't find the upload point and kill his cable modem... | 00:31 | |
| * rcn-ee 3hours.... i'll be using wget -c for this.. | 00:32 | |
| rcn-ee | cwillu_at_work, say with 2.6.34 have you run into this? http://pastebin.com/iqAHMVD4 | 00:35 |
| cwillu_at_work | on reboot? | 00:36 |
| rcn-ee | only occurs say after 10minues uptime, and then issuing a reboot... | 00:36 |
| cwillu_at_work | I haven't, but I can't say I've been exercising that codepath | 00:36 |
| rcn-ee | i know it happens on beagles... does the overo suffer the same fate? | 00:36 |
| rcn-ee | it's actually happening on all mine... including ones in a headless setup.. | 00:37 |
| rcn-ee | i've pinged linux-omap, but not that may people have jumped to 2.6.34 yet either.. ;) | 00:37 |
| cwillu_at_work | haven't noticed it, but I haven't been doing a whole lot with the overo's in the last two weeks either | 00:38 |
| cwillu_at_work | the zippy's came in, and I've been doing those sd burn tests | 00:38 |
| rcn-ee | noob question, how to get the network-manager thing to show up in xfce on the bottom. ;) | 00:41 |
| cwillu_at_work | nm-applet | 00:41 |
| cwillu_at_work | geez, I've run this 3 times with the chroot in the time it took the original beagle to get to the point that the first chroot died (at which point it also died) | 00:42 |
| cwillu_at_work | taking into account that the beagle had a 6 hour head start | 00:43 |
| rcn-ee | i think the beagle lost.. kill it.. | 00:43 |
| cwillu_at_work | quite | 00:43 |
| persia | Emulation isn't always this much faster. It really depends on the RAM requirements for the build. | 00:43 |
| rcn-ee | yay, nm-applet runs, it doesn't like to run by default.. | 00:43 |
| cwillu_at_work | I know | 00:43 |
| persia | If you compare 1000 iterations of a simple hello.c compile, it's about the same. | 00:43 |
| cwillu_at_work | I'm very very io bound | 00:43 |
| persia | Heh. | 00:44 |
| cwillu_at_work | and doing it in ram is very very much faster than doing on an sd card | 00:44 |
| cwillu_at_work | it's funny though | 00:44 |
| persia | rcn-ee: if you've not tried it before, #xubuntu is also a good place to ask XFCE questions | 00:44 |
| cwillu_at_work | I've been tripping over that code for a while now, never bothered to actually try it :) | 00:45 |
| cwillu_at_work | granted that in my case, it still would've been doing lots from a normal vm anyway | 00:45 |
| cwillu_at_work | but I might have wised up | 00:45 |
| rcn-ee | yeah, i should, i'm starting to use xfce alot on the beagle..... ;) i've gone from providing just console image to full blown xfce images... give the people what they want.. ;) | 00:46 |
| DanaG | I found xfce not worth the bother... by the time I got it the way I liked it, I might as well have used gnome. | 00:48 |
| persia | If you're going that deep, #xubuntu-devel may be of interest, but from what I've heard, Xubuntu isn't quite as optimised for low-spec machines as it was in the past. | 00:49 |
| cwillu_at_work | nope | 00:50 |
| persia | (where Xubuntu is XFCE+everything to make it the way folks like it) | 00:50 |
| rcn-ee | gnome... i did that once on a beagle Bx... Debian Lenny kinda like watching paint dry... but i got firefox up and took a pic.. | 00:50 |
| cwillu_at_work | rcn-ee, my ui is actually built entirely on firefox :p | 00:51 |
| rcn-ee | nice.. it's actually not that bad on Karmic/Lucid.. but on lenny with armv4 unoptimzation... ;) | 00:52 |
| cwillu_at_work | heh | 00:52 |
| rcn-ee | i do really like the speed of chrome on arm thou... | 00:52 |
| cwillu_at_work | it wouldn't have had the neon accelerated routines in libpixman either | 00:52 |
| cwillu_at_work | that makes a huge difference | 00:52 |
| cwillu_at_work | hmm | 00:53 |
| cwillu_at_work | Setting up openssh-client (1:5.3p1-3ubuntu3) ... | 00:53 |
| cwillu_at_work | qemu: uncaught target signal 11 (Segmentation fault) - core dumped | 00:53 |
| rcn-ee | come on beagle.. ;) | 00:54 |
| cwillu_at_work | [31576.626128] kernel tried to execute NX-protected page - exploit attempt? (uid: 0) | 00:54 |
| cwillu_at_work | [31576.626140] BUG: unable to handle kernel paging request at ffffea0006704898 | 00:54 |
| cwillu_at_work | [31576.626147] IP: [<ffffea0006704898>] 0xffffea0006704898 | 00:54 |
| cwillu_at_work | [31576.626159] PGD 28402067 PUD 28403067 PMD 800000002de001e3 | 00:54 |
| cwillu_at_work | [31576.626168] Oops: 0011 [#1] SMP | 00:54 |
| cwillu_at_work | [31576.626174] last sysfs file: /sys/devices/virtual/block/loop1/queue/hw_sector_size | 00:54 |
| cwillu_at_work | [31576.626178] CPU 2 | 00:54 |
| cwillu_at_work | not sure if that happened at the same time, or in response to the umount | 00:54 |
| * cwillu_at_work tries it again without the tmpfs | 00:55 | |
| cwillu_at_work | or maybe my server is dying of btrfs-related conditions | 01:01 |
| rcn-ee | it looks like qemu... the loop mount... | 01:02 |
| cwillu_at_work | I got a bunch of paging request failures below though | 01:05 |
| rcn-ee | ah | 01:05 |
| cwillu_at_work | and all my terminal windows locked up | 01:05 |
| cwillu_at_work | I'm actually suspecting the hardware | 01:05 |
| cwillu_at_work | but why fix it if I can just reboot every night? :p | 01:05 |
| * cwillu_at_work orders pizza | 01:06 | |
| rcn-ee | exactly.. it's what those kitchen timers are for... (specially on cable modems that lock up every 7 hours) | 01:07 |
| cwillu_at_work | I actually bought one yesterday :) | 01:07 |
| cwillu_at_work | it's rebooting a beagle for me | 01:07 |
| rcn-ee | i picked up one of those ipower devices, can turnon/off 4 nodes over ip.. it's rebooted many beagles while i've been away... | 01:08 |
| cwillu_at_work | how much are those? | 01:09 |
| cwillu_at_work | I want to reboot the thing every ten minutes, and bring it back up right away, but I also don't want to pay more than 7.95 to do it | 01:09 |
| rcn-ee | laughs, more $60-70 than that.. but geeks has them on sale every once in a while.. http://www.geeks.com/search.asp?QUERY=ipower then a nice shell script to access them.. http://azug.minpet.unibas.ch/~lukas/myfree/ | 01:11 |
| cwillu_at_work | hmm :/ | 01:11 |
| cwillu_at_work | I think I'll just wire up a relay to a gpio | 01:11 |
| rcn-ee | that was my first thought... old arm board with ethernet, gpio to relays/etc... | 01:12 |
| rcn-ee | no ones really makes it, might be a nice hobby kit to sell... | 01:12 |
| * cwillu_at_work nums on pizza | 01:22 | |
| Martyn | pizza sounds good right about now | 01:25 |
| Martyn | I've started on the long, tedious process of finding duplicated symbols in the arm tree | 01:26 |
| Martyn | It's going to be like zapping flies .. killing them one at a time until all the ARM architectures can be compiled in at the same time | 01:26 |
| Martyn | (making a stupidly large, but VALID kernel) | 01:27 |
| rcn-ee | sounds like fun! Martyn is your current git tree public? | 01:29 |
| Martyn | rcn-ee : No, I need to github the work as it goes along | 01:31 |
| Martyn | i'll do that this weekend. This is _literally_ the first night I've started to work on what I promised to do @ UDS | 01:31 |
| Martyn | I just cloned the linux-arm kernel tree at 2.6.34 current | 01:31 |
| rcn-ee | well you've been busy, sounded like uds was crazy for arm.. ;) i'm mostly asking, cause my tegra 2 is to arrive tomorrow or saturday.. | 01:32 |
| Martyn | ( I have an even higher priority task to do . I need to get a basic patchset to add the arch/arm/mach-sstone subarch before the 2.6.35 window closes ) | 01:33 |
| Martyn | rcn-ee : AWESOME | 01:33 |
| Martyn | We are all going to have those little things | 01:33 |
| Martyn | nVidia have been DRAGGING their fucking feet on getting the linux SDK out | 01:33 |
| Martyn | frankly, I think we might be able to button up lucid lynx on it faster than they can | 01:33 |
| Martyn | I already have arm-server working correctly on it | 01:33 |
| rcn-ee | yeap, they have... some of thought they'd deliver... | 01:34 |
| cwillu_at_work | root@lucid-zippy:/etc/init# xsplash --display=:0 | 03:20 |
| cwillu_at_work | No protocol specified | 03:20 |
| cwillu_at_work | odd | 03:20 |
| cwillu_at_work | hmm | 03:23 |
| cwillu_at_work | xterm opens | 03:23 |
| cwillu_at_work | firefox doesn't, with the same error | 03:23 |
| cwillu_at_work | did we add more xauth sillyness in lucid?\ | 03:23 |
| === lag_ is now known as lag | ||
| === sumitsemwal is now known as sumitsemwal|lunc | ||
| === hrw|gone is now known as hrw | ||
| hrw | morning | 08:10 |
| alf__ | hrw: Morning! | 08:12 |
| === sumitsemwal|lunc is now known as sumitsemwal | ||
| aaron_liuj | udevd-event[1051]: udev_node_mknod: mknod(/dev/tty58.udev-tmp, 020660, 4, 58) failed: Operation not permitted | 09:00 |
| aaron_liuj | udevd-event[1044]: udev_node_mknod: mknod(/dev/tty51.udev-tmp, 020660, 4, 51) failed: Operation not permitted | 09:15 |
| asac | cooloney: hey ... will we first get .34 omap? | 09:16 |
| asac | hrw wonders as he needs some driver ;) | 09:17 |
| aaron_liuj | udevd-event[1051]: udev_node_mknod: mknod(/dev/tty58.udev-tmp, 020660, 4, 58) failed: Operation not permitted | 09:18 |
| hrw | so far I have few network/usb devices: 7Mbps ethernet (x3), rt73usb (tends to disconnect from usb bus), ath9k_htc (802.11n dongle) | 09:18 |
| === rtp_ is now known as rtp | ||
| aaron_liuj | chmod -R 777 /dev/capi" | 09:19 |
| aaron_liuj | udevd-event[1051]: udev_node_mknod: mknod(/dev/tty58.udev-tmp, 020660, 4, 58) failed: Operation not permitted | 09:26 |
| aaron_liuj | i using root nfs but udev occurs error | 09:26 |
| aaron_liuj | udevd-event[1051]: udev_node_mknod: mknod(/dev/tty58.udev-tmp, 020660, 4, 58) failed: Operation not permitted | 09:27 |
| aaron_liuj | when i flash the fs to the board .it's works well | 09:27 |
| hrw | aaron_liuj: so check nfs settings | 09:30 |
| cooloney | asac: for 10.07, it will be .33 first | 09:31 |
| asac | cooloney: first? so in the end .07 gest .34 too? | 09:32 |
| amitk | asac: 10.07 will always be .33 | 09:36 |
| asac | kk | 09:36 |
| cooloney | the patch from ti are based on .33 | 09:36 |
| asac | right | 09:37 |
| asac | i was talking aobut maverick | 09:37 |
| asac | so does that mean until we have 10.07 maverick stays on whatever we are using for .07? | 09:37 |
| amitk | 10.10 will be .35 finally, and we'll make available .34 kernels in the meanwhile | 09:37 |
| amitk | asac: no, they are separate kernel trees | 09:37 |
| cooloney | mattieu will work on M kernel for omap3/omap4 mainline | 09:38 |
| amitk | cooloney: I'm working on it, will be available early next week | 09:38 |
| cooloney | i will work on M kernel branch for omap4 patch dump | 09:39 |
| cooloney | amitk: great, so please talk with mattieu | 09:39 |
| cooloney | he is going to take a look at that | 09:39 |
| amitk | sure | 09:39 |
| cooloney | thanks | 09:39 |
| * amitk & | 09:39 | |
| hrw | beagleboard netspeed is now only limited to usb-ethernet card speed | 09:39 |
| ndec | amitk: cooloney: we will provide .34 patches for M release | 09:53 |
| zyga | guys - how likely is it to have a single kernel for >1 device by 10.10? | 09:53 |
| asac | hi ndec | 09:53 |
| ndec | asac: hi | 09:54 |
| zyga | s/more than >1 device/devices from >1 vendor/ | 09:54 |
| asac | >1 vendor? quite unlikely | 09:54 |
| cooloney | ndec: thanks, hah | 09:54 |
| asac | but you never know :) | 09:54 |
| cooloney | ndec: oh, one question | 09:55 |
| ndec | cooloney: yup | 09:55 |
| cooloney | ndec: i got this in the dmesg | 09:55 |
| cooloney | 'Uninitialized omap_chip, please fix!' | 09:55 |
| zyga | asac, would it be possible to have a bunch of kernels on one 'image' and have uboot guess/choose the right one? | 09:55 |
| amitk | ndec: but you'll also upgrade it to .35 as we go, right? | 09:55 |
| cooloney | did you guys see that? | 09:55 |
| zyga | so that the 'impression' of getting integrated image is better than what we have today | 09:56 |
| ndec | amitk: yes we will do that as well. basically our BSP team follow mainline dev. | 09:56 |
| ndec | amitk: so we get regularly BSP rebase on latest mainline. we will need to discuss how we manage our out-of-tree patches for M releases. | 09:57 |
| hrw | cooloney: on a9 only or also on a8? | 09:57 |
| amitk | ndec: ok, then we are on the same page :) | 09:58 |
| cooloney | hrw: actually, i don't have hw, ogra_cmpc tested that on his blaze | 09:58 |
| ndec | cooloney: i need to check. right now it's not in my dmesg buffer, so I will try to reboot when I am done with my builds | 09:58 |
| asac | zyga: you can have a bunch of kernels on the image and uboot selecting one .... the problem is that we cant have a single uboot for all boards | 09:58 |
| hrw | cooloney: not have it on BB | 09:58 |
| cooloney | it should be omap4430 | 09:59 |
| cooloney | dual a9 | 09:59 |
| hrw | cooloney: so blaze or panda - both are rather TI only (+few protos sent outside) | 09:59 |
| zyga | asac, if the vendor would ship a boot loader that compatible with our boot requirements we might be able to pre-hint it with the right kernel to choose (that would only make sense if the vendors were interested in following this idea)\ | 09:59 |
| ndec | amitk: the only tricky part is between now and july since we want an updated kernel for L and M releases ;-) | 10:00 |
| cooloney | hrw: exactly, i am just trying do some development based on the dmesg from ogra who has that hw | 10:00 |
| hrw | cooloney: 374 void __init omap2_check_revision(void) in arch/arm/mach-omap2/id.c | 10:01 |
| asac | zyga: its difficult. not all boards can have a uboot preinstalled in flash (e.g. some dont have nand etc.) | 10:01 |
| cooloney | hrw: yeah, that is it. | 10:01 |
| hrw | cooloney: looks like it did not found it as 4430 | 10:01 |
| ndec | zygal: at least for omap, we are definetely interested in a single kernel image that supports all our boards. but this is tricky for now. | 10:01 |
| cooloney | hrw: https://pastebin.canonical.com/32503/ | 10:02 |
| asac | so there is more than just that. maybe if all would use disk/u-boot.bin.ARCH or something if they find that on mmc it would work | 10:02 |
| cooloney | hrw: but except that error message, others are looks good | 10:02 |
| cooloney | so weird | 10:02 |
| hrw | cooloney: I saw that dmesg before | 10:02 |
| zyga | asac, as long as arch is not arm-linux-eabi ;-) | 10:02 |
| asac | but thats not that simple either. i think for the time being we need to accept tht we need different boot parts | 10:02 |
| asac | and work on tools so you can more easily combine our filesystems with whatever boot things you need | 10:03 |
| zyga | asac, your last comment is actually very true - a simple program that would download common filesystem image and combine that with whatever device kernel/boot requirements you may need would be good for early-adopters | 10:04 |
| cooloney | hrw: ah, enjoy that. hah | 10:04 |
| ndec | cooloney: I can't access your pastebin with my launchpad account. is that expected? | 10:04 |
| zyga | (with boot instructions/device pictures so that even most inexperienced early adopters/tinkers will get it right each time...) | 10:05 |
| persia | cooloney: If it's not confidential, please use paste.ubuntu.com :) | 10:05 |
| * zyga stops daydreaming ... | 10:05 | |
| persia | zyga: If you want a longer-term daydream, imagine devices shipping with a uboot that does the right thing already in flash, so that we just ship a kernel and it magically works :) | 10:06 |
| zyga | persia, yes, that would be.... just like current PCs *g* | 10:06 |
| zyga | (with less crap on screen) | 10:06 |
| ndec | persia: a longer longer-term daydream would be a device that boots without the bootloader ;-) | 10:07 |
| persia | ndec: Depends on semantic values. My defintion of "bootloader" is "The thing that loads a kernel". I've no objection to it being in ROM, but I'll probably still call it a bootloader. I do have an objection to putting a kernel in ROM. | 10:08 |
| zyga | persia, very true | 10:08 |
| cooloney | persia: ndec sorry, actually, it was posted by ogra_cmpc | 10:09 |
| asac | zyga: yep. thats the setup-sdcard.sh script atm. ... could be improved though | 10:09 |
| zyga | persia, the really bad thing that I would hate is a bunch of devices shipping with bootloaders that load a signed kernel which cannot be changed ... | 10:09 |
| amitk | cooloney: use pastebin.ubuntu.com | 10:09 |
| ndec | cooloney: persia: no problem. i didn't know you had a private pastebin as well... | 10:09 |
| ndec | asac: persia: can you confirm that if I create a new ubuntu package (for PPA upload), the right version number should be: my-pkg-0.1.2-0ubuntu1~ppa1? do you recommend that I put the -0ubuntu1 suffix? | 10:12 |
| persia | zyga: signed kernels are good. Not being able to configure the keyset is bad. Note that we currently distribute signed kernels in Ubuntu, and refuse to write them to flash if they aren't signed (although there are massive manual workarounds to let users do whatever they like)/ | 10:12 |
| persia | ndec: My recommendation is my-pkg (0.1.2-0ppa1) | 10:13 |
| cooloney | ndec: http://pastebin.ubuntu.com/437200/ | 10:13 |
| asac | ndec: your version number looks sane imo ...what persia said is also ok | 10:13 |
| persia | ndec: If the package *already* had an Ubuntu suffix, I'd suggest 0.1.2-3ubuntu4+ppa5 | 10:13 |
| asac | if the package isnt in debian the ubuntu1 suffix isnt needed | 10:13 |
| ndec | persia: I am talking about new TI packages that aren't in debian or ubuntu already | 10:14 |
| persia | If/when it gets uploaded to Ubuntu, it will end up being 0.1.2-0ubuntu1, but it's safer to avoid messing with that for PPA versions, to give more flexibility. | 10:14 |
| ndec | asac: so the 0ubuntu suffix will be needed if we ever put our packages in main/multiverse? | 10:15 |
| asac | persia: ppa1 is good too ;) ... | 10:15 |
| ogra | well, i'd actually like to pull in everything we can as early as possible into maverick | 10:15 |
| asac | ndec: yeah ... unless you upload to debian | 10:15 |
| persia | ndec: For new packages, I generally use -0persia1 : it's been pointed out that I can do this because of how my nick sorts, so I recommend others use -0ppa1 to achieve the same goals. | 10:15 |
| ogra | so using the -0ubuntu1 suffix should be preferred | 10:15 |
| persia | the suffix is not "needed". It's just the conventional notation to indicate how the package got into Ubuntu. | 10:16 |
| ogra | i didnt say its needed but its more consistent | 10:16 |
| asac | ndec: in short ... your version number was perfectly fine ... will upgrade to ubuntu1 plain ... you can also use 0ubuntu0+ppa1 instead f 0ubuntu1~ppa1 ;) | 10:16 |
| persia | But, if the convention is followed, -0ubuntu1 should only be used for the revision that is actually uploaded to Ubuntu, and all prior versions should sort lower. | 10:16 |
| ogra | asac, ++ | 10:16 |
| asac | persia: the suffix is needed to avoid syncs from debian if someone sabotages you and uploads the same package name there | 10:16 |
| ogra | right | 10:17 |
| persia | I'm kinda curious where the ~ recommendation came from. I thought I changed all the LP docs to suggest + | 10:17 |
| asac | if you upload to debian all is fine | 10:17 |
| ndec | I am looking for the *right* thing to do. looks like my initial proposal was ok, right? | 10:17 |
| persia | asac: no it isn't, but it does make that easier. | 10:17 |
| asac | persia: i am still in favour of that. its a matter what you are doing ... improvements to last version -> +xxx ... working on new version -> +1~xxx | 10:17 |
| * persia fails to see a useful semantic distinction between improving the old revision and working on a new revision, but has little interest in debating the specifics :) | 10:18 | |
| ndec | persia: i use ~ppa1 for my initial attempts.. i want my first official package to be 0ubuntu1+ppa1, but for all my initial attempts I am using ~ppa1 until i have something I am happy with | 10:18 |
| asac | persia: its a matter of guts feeling ;) | 10:18 |
| ogra | ndec, pastebin-> sorry i'm not sure about how much i'm allowed to make public about the blaze yet so i usually use the protected pastebin | 10:18 |
| persia | ndec: In short, you can use any version you like. For an ideal end-user upgrade experience from PPA to Ubuntu, be sure to use something that dpkg --check-versions believes is lower than -0ubuntu1 | 10:19 |
| ogra | (and i usually dont paste the url in public channels :P ) | 10:19 |
| asac | ndec: 0ubuntu1+ppa1 would be wrong ... as that wouldnt upgrade to 0ubuntu1 which would be that goes to the real archive ;) | 10:19 |
| asac | just use 0ubuntu0+ppa1, ppa2, ppa3 (even if 3 is final) ... or 0ubuntu1~ppa1, ppa2, ppa3 ... | 10:20 |
| ogra | right | 10:20 |
| asac | both would move towards a 0ubuntu1 for the real archive | 10:20 |
| cooloney | ogra: morning, | 10:20 |
| ogra | in maverick we'll just use -0ubuntu1 then | 10:20 |
| ogra | hey cooloney | 10:20 |
| * persia thinks -0ppa1 is easier to type than -0ubuntu0+ppa1 :) | 10:20 | |
| ogra | ndec, go with asac's suggestion | 10:21 |
| cooloney | i replied one email for you and prepared a new kernel with omap serial built-in for testing | 10:21 |
| ogra | cooloney, great, will test soon | 10:21 |
| ogra | i wonder how that works since the early messages seem to go to ttyS* by default | 10:22 |
| ndec | asac: persia: ogra: thanks. I will continue with what I have, e.g. tisyslink-lib_0.24.5-0ubuntu1~ppa1, and I won't use the +ppa1 unless I want to override the main archive... | 10:23 |
| ndec | ogra: blaze is public platform. its BSP is also on public trees. so all is fine. | 10:24 |
| ogra | cool | 10:24 |
| ogra | i'll use the public pastebin from now on :) | 10:25 |
| ogra | i'm always a bit over-anxious with that stuff :) | 10:25 |
| ndec | ogra: are you able to boot a ubuntu image on blaze? | 10:26 |
| ogra | sure | 10:26 |
| ogra | its my main build platform now :) | 10:26 |
| lag | which chroot do we use for building arm kernels? *-amd64 or *-i386 | 10:26 |
| cooloney | ogra: oh, build platform, native building | 10:26 |
| ogra | lag, -armel | 10:27 |
| ogra | cooloney, indeed | 10:27 |
| ndec | ogra: same for me. this is actually quite cool... | 10:27 |
| ogra | i'm currently working on x-loader and u-boot for the blaze | 10:27 |
| lag | ogra: Doesn't exist on emerald? | 10:27 |
| ogra | its a bit painful that the x-loader tree links hard into the u-boot tree for all the headers | 10:27 |
| ogra | lag, whats emerald ? | 10:27 |
| ogra | kernel porter box ? | 10:28 |
| lag | ogra: I thought you were going to say that :) | 10:28 |
| lag | apw: --^ | 10:28 |
| ndec | ogra: i know... but we will soon get rid of xloader anyways... | 10:28 |
| persia | lag: Probably not. People who use that server were surprised that they work at UDS. | 10:28 |
| ogra | ndec, indeed, but currently i need it so i need to somehow build it :) | 10:28 |
| hrw | ndec: so bootrom -> uboot-from-sd? | 10:28 |
| hrw | or even s/uboot/whatever | 10:29 |
| lag | persia: What do you mean? | 10:29 |
| ogra | hrw, http://omappedia.org/wiki/E-MMC_boot see the bottom | 10:29 |
| ndec | hrw: yes. we can append a small header to bootloader with EMIF config. ROM code parses header, configures DDR, and then loads uboot from SD (or NAND, or eMMC) in to DDR. so no more xloader | 10:29 |
| persia | lag: At the end of the schroot+LXC session there was a demo of running an -armel chroot on an amd64 machine, which was the first time some of the present kernel folk had seen that. | 10:30 |
| ndec | hrw: there is a limitation today with OMAP4, that will be fixed in next silicon rev. | 10:30 |
| hrw | I love that 'next silicon rev' part ;D | 10:31 |
| asac | lol | 10:31 |
| lag | Ah, I see | 10:31 |
| lag | I have already done it, but I can't remember which chroot I used | 10:31 |
| lag | I thought it was amd64 | 10:31 |
| ndec | persia: armel chroot on x86 machine: can we build any armel packages this way? | 10:31 |
| hrw | I own atmel board with CPU rev.A which mean "boot only from dataflash". rev.B boards (which are most of sold ones iirc) can boot from dataflash or nandflash. the funny part is that dataflash is provided as mmccard | 10:32 |
| ogra | ndec, you can but note that its not faster than using qemu VMs ... compiler is as slow as emulated | 10:32 |
| ogra | the only thing you speed up is all the surrounding stuff | 10:32 |
| ndec | ogra: ok.. so I will continue to use my board. | 10:32 |
| ogra | yeah | 10:32 |
| * ogra loves to be able to use make -j2 :) | 10:33 | |
| persia | ndec: No, but you can build most of them. I've never had a build succeed in that environment that didn't also succeed on the buildds, but I've had some fail. Anything that relies on a real /proc tends to break, so mono definitely won't work. Some parrot stuff doesn't work right, etc. There are also some missing syscalls, so some other stuff doesn't work. | 10:33 |
| * ogra thought we had all syscalls after the last release | 10:33 | |
| ogra | there are some missing ioctl calls though | 10:34 |
| persia | ogra: I thought we had all the syscalls that we knew broke builds we'd tested, rather than having done a formal evaluation of all possible syscalls, but you may be right. | 10:34 |
| ogra | well, i havent seen any "unsupported syscall" message in 6 months | 10:35 |
| ndec | ogra: i can't sign my packages on the board since I am mount my rootfs over NFS. and my $HOME is not on a secure location. so I don't want to put my keys there. can I sign the .dsc and .deb afterwards after copying them on my laptop? | 10:35 |
| ogra | yes, you should be able to use debsign or just unpack the tree on your x86 and use dpkg-buildpackage -S -sa | 10:36 |
| persia | ndec: `debsign -r` lets you sign anythng you can scp from and to. man debsign for details. | 10:36 |
| persia | To save on warning messages, I always use `debuild ... -us -uc` when building something for debsign -r | 10:36 |
| * ogra often uses the latter as an additional control point that the source package builds right on other arches | 10:36 | |
| ndec | persia: ogra: ok, I will try that. btw, I am using dput over scp to copy the *.changes, that works great. | 10:37 |
| ogra | cool | 10:37 |
| ogra | i never tried that | 10:37 |
| ndec | ogra: we setup an internal debian archive, so that we can apt-get install our early packages (without launchpad). so we build .dsc and .deb on boards, and update the debian archive with dput! | 10:39 |
| ogra | sweet | 10:39 |
| ndec | ogra: I realized that when you build with 'debuild' the .changes file tracks the .deb, so dput will also upload the .deb | 10:40 |
| ogra | yeah | 10:40 |
| ogra | wont work with the real archive though :) it only accepts sources | 10:40 |
| ogra | i think debian allows binary uploads though | 10:40 |
| persia | ndec: I'll strongly recommend you don't do that. We chose to use source-only uploads in Ubuntu for several reasons, not least of which is that you can end up with problems rebuilding a package because of stuff that is installed in your local machine when using debuild to construct a .deb | 10:41 |
| persia | ogra: Rather, Debian requires binary uploads, supposedly as proof that the source is known to build somewhere. | 10:41 |
| ndec | persia: i am not talking about a production system here. i need to be able to share .deb within the teams so that anyone can apt-get install TI stuff. so the workflow is: 1) I build source and bin package on my board, 2) dput to the archives, 3) any user can use my .deb.... this is cool for early dev. | 10:42 |
| persia | ndec: I understand. I still recommend you use sbuild or pbuilder to do that. This will produce an armel.changes file which you can also dput. | 10:43 |
| persia | The problem is that if you end up having something odd on your machine that isn't listed in the control fields, you may end up with a different .deb than you expect, or it may work for you when testing, but then not work for anyone else later. | 10:44 |
| persia | This doesn't always happen, but these are examples of the sorts of issues that have been encountered with that type of workflow. | 10:44 |
| persia | (and avoiding these issues is part of why sbuild and pbuilder are available in the archives) | 10:45 |
| ndec | persia: you mean running sbuild on the OMAP4 board, to make sure that my control fine has all the proper deps? | 10:46 |
| persia | Precisely. | 10:46 |
| ndec | persia: what are the diffs between sbuild and pbuilder? | 10:46 |
| persia | Completely independent development histories, and different ways to add hook scripts, modify the internals, etc. | 10:47 |
| persia | Both attempt to replicate what is considered an ideal build environment, and so do almost precisely the same thing. | 10:47 |
| persia | I personally use sbuild. I know lots of folks that use pbuilder. My recommendation is always to use the one that seems least confusing (although I'm only able to help people setup/use sbuild on schroot) | 10:48 |
| cooloney | ogra: does that ttyO2 ~test4 kernel work on your side? | 11:05 |
| ogra | cooloney, still garbage | 11:22 |
| ogra | oh, wait i used O0 not O2 | 11:23 |
| ogra | cooloney, any FYI it boots through, i get a login prompt on the LCD | 11:23 |
| ogra | cooloney, works :D | 11:25 |
| ogra | Ubuntu 10.04 LTS blaze ttyO2 | 11:29 |
| ogra | blaze login: | 11:29 |
| ogra | :) | 11:29 |
| ogra | cooloney, so now we only need to get rid of the "omap_hwmod:" messages and we should be roughly fine | 11:29 |
| ogra | ndec, do you have an idea why we get all the spam ? | 11:30 |
| ogra | massive amounts of omap_hwmod: lines are put out ... according to the prefix <7> its loglevel 7 but if i change it it doesnt change behavior | 11:30 |
| ndec | ogra; do you have these traces in serial console or in dmesg? | 11:31 |
| ogra | everywhere | 11:31 |
| ogra | and it goes on to spill to console after boot | 11:32 |
| ogra | <7>omap_hwmod: i2c1: enabling | 11:32 |
| ogra | <7>omap_hwmod: i2c1: idling | 11:32 |
| ogra | thats what i see after boot in dmesg and console | 11:32 |
| ndec | ogra: i don't have them in serial console. but I am not using same kernel as yours. probably something wrong with the config of cooloney's kernel | 11:32 |
| ogra | during boot it points to different devices | 11:32 |
| ogra | well, its the omap4 config merged with the ubuntu config | 11:33 |
| ogra | something seems to clash there | 11:33 |
| ogra | ndec, also are you able to run git clone with your kernel ? | 11:33 |
| ogra | for me it fails and afterwards nearly everything starts to segfault | 11:34 |
| ndec | ogra: nope... i think i mentioned that to you on irc a few weeks back | 11:34 |
| ogra | ah, k | 11:34 |
| ogra | robclark said he heard someone found a fix for it | 11:34 |
| ndec | ogra: i have the same problem. I installed an older version of git (1.6.5) which works. | 11:34 |
| ogra | right | 11:35 |
| ogra | rob told me the same | 11:35 |
| ndec | ogra: i think this is just a rumor of a fix... i haven't seen anything.. | 11:35 |
| cooloney | ndec and ogra, i am working on killing omap_hwmod | 11:35 |
| cooloney | omap_hwmod message | 11:35 |
| ogra | cooloney, perfect | 11:35 |
| ogra | ndec, and rebooting seems to fail for me | 11:35 |
| ndec | cooloney: ok... please don't kill omap_hwmod ;-) | 11:36 |
| ogra | not sure thats known already | 11:36 |
| cooloney | ogra: but still don't have any idea. | 11:36 |
| ndec | ogra: known issue as well. and you must reboot after git clone fails. | 11:36 |
| cooloney | ndec: eheh, indeed. that's our rumtime PM, right | 11:36 |
| ogra | ndec, heh, yeah :) | 11:36 |
| ndec | cooloney: amitk: by the way, CONFIG_ARM_THUMB should be checked in config/enforce for 10.04 and above... it's a strong requirement. | 11:39 |
| ndec | cooloney: in arch/arm/mach-omap2/omap_hwmod.c you have #define DEBUG at b/o file. that should be the problem, no? | 11:41 |
| hrw | asac: http://hrw.pastebin.com/ucXSuQU0 | 11:41 |
| ndec | hrw: this looks sweet... | 11:43 |
| hrw | pure sh | 11:43 |
| ogra | hrw, urgh | 11:43 |
| ogra | use case ! | 11:43 |
| ndec | hrw: still sweet ;-) | 11:43 |
| cooloney | ndec: ok, we enable it in our ARM. | 11:43 |
| cooloney | but not in enforce. | 11:44 |
| ndec | ogra: no more need for ttySx.conf files | 11:44 |
| cooloney | i will post a patch | 11:44 |
| ndec | ogra: the script detect your console args from bootargs and create the correct getty | 11:44 |
| hrw | ARM_THUMB is a thing which should be always enabled in kernel (on 920t and above) | 11:44 |
| ogra | for x in $(cat /proc/cmdline); do | 11:44 |
| ogra | case $x in | 11:44 |
| ogra | console=*) | 11:44 |
| ogra | tty=${x#console=} | 11:44 |
| ogra | log_begin_msg "$DESCRIPTION" | 11:44 |
| ogra | cat > /root/etc/init/${tty}.conf <<EOF | 11:44 |
| ogra | start on stopped rc RUNLEVEL=[2345] | 11:44 |
| ogra | stop on runlevel [!2345] | 11:44 |
| ogra | respawn | 11:44 |
| ogra | exec /sbin/getty -L 115200 ${tty} vt100 | 11:44 |
| ogra | EOF | 11:44 |
| ogra | ndec, hrw ^^^ | 11:45 |
| amitk | cooloney: you can have arch specific enforce. we should add it to our enfore | 11:45 |
| hrw | ogra: what if my board has 57600 serial only? | 11:45 |
| hrw | ogra: but I like your ver | 11:45 |
| cooloney | ndec: found that DEBUG macro. there | 11:45 |
| ogra | hrw, add a nested case that catches the speed :) | 11:45 |
| cooloney | ndec: let me remove it and build the kernel again. | 11:45 |
| ogra | hrw, its just a quick hack, needs test code etc | 11:45 |
| cooloney | ndec: but i think it is the same in omapzoom git tree | 11:45 |
| cooloney | amitk: right, i found most of the omap enforce are the same as our common enforce | 11:46 |
| cooloney | .master enforce | 11:46 |
| ndec | cooloney: yes. i have all traces in dmesg but not in console. what are your bootargs? | 11:46 |
| ogra | hrw, note that my code lives rather in initramfs for a proper upstart script you need the right upstart script commands | 11:46 |
| asac | hrw: your script looks good | 11:47 |
| ogra | hrw, though when scripting, try to rather use case than if its several times faster | 11:47 |
| asac | have you tried it with a few options? | 11:47 |
| asac | ogra: we dont want to patch existing ttys | 11:47 |
| asac | its really just creating the right tty on the fly | 11:47 |
| asac | for non casper boots | 11:48 |
| ogra | asac, yes thats what my script does, you just need some test for ttyS | 11:48 |
| ogra | thats why i said above its a quick hack :) | 11:48 |
| ogra | by default nothing ships ttyS scripts | 11:48 |
| cooloney | ndec: i don't have hardware, so i don't change any bootargs, | 11:48 |
| cooloney | ogra: ^^^^ | 11:49 |
| asac | hrw: can you use ogras approach and clean that up a bit ... so it parses the number etc | 11:49 |
| asac | hrw: or are you happy with your current approach? | 11:49 |
| hrw | http://hrw.pastebin.com/CuT5AM1z is a bit cleaner | 11:49 |
| asac | hrw: also remember to use autologinroot there as the login | 11:49 |
| ogra | ndec, root=UUID=bc59dc33-8403-4fbd-84a6-ddf0c760b25a ro quiet console=ttyO2,115200n8 vram=12M omapfb.vram=0:5M,1:5M fixrtc | 11:49 |
| ndec | asac: autologinroot? | 11:50 |
| hrw | one thing to handle left | 11:50 |
| * ogra needs to feed the cats else they will eat *me* | 11:50 | |
| hrw | cmdline="console=tty1 console=ttyS2" | 11:50 |
| asac | hrw: we should ignore ttyX if /etc/init/ttyX.conf exists | 11:51 |
| hrw | asac: thats next to add | 11:51 |
| asac | right | 11:51 |
| asac | ndec: thats an auto login as root thing. for a minimal image | 11:53 |
| cooloney | ogra: ok, after you feed your cats, you will get a new kernel to test | 11:53 |
| asac | is console=/dev/ttyXXX also valid? | 11:54 |
| asac | i think so | 11:54 |
| asac | hrw: in that case remember to strip the /dev/ or so in your script | 11:55 |
| hrw | ok | 11:57 |
| ndec | cooloney: you need to revert 2d60cfb9010470ce5b172513c907091ad30be34e, http://dev.omapzoom.org/?p=integration/kernel-omap4.git;a=commit;h=2d60cfb9010470ce5b172513c907091ad30be34e. i will check why this ended up in our tree... | 11:58 |
| ogra | asac, i dont think its valid | 12:02 |
| ogra | cooloney, i'm back (surrounded by burping cats now :) ) | 12:03 |
| asac | ogra: kk | 12:03 |
| ogra | ndec, bah, the hole for HDMI on the blaze case needs to be bigger, i have about 10 HDMI cables of different size here, not a single one fits through the hole in the case ! | 12:27 |
| ogra | oh, silly me its micro HDMI | 12:30 |
| * ogra gets the right cable | 12:31 | |
| cooloney | ogra: pls try my ~test5 kernel in the same URL | 12:33 |
| * ogra wgets | 12:33 | |
| cooloney | Which revert the DEBUG macros | 12:34 |
| ogra | cooloney, ndec, http://paste.ubuntu.com/437259/ \o/ | 12:39 |
| ndec | ogra: cool | 12:40 |
| jussi | ogra: lol | 12:40 |
| ogra | hmm, i wonder whyt happens if i dont set the vram options | 12:44 |
| ogra | i think we should really set proper defaults in the kernel so we only need the cmdline option to override them | 12:45 |
| hrw | asac: what handle autologinroot? | 13:13 |
| hrw | current version of service has 48 lines, handles /dev/ttyS2 and ttyS2, uses cases, checks for services | 13:18 |
| hrw | http://hrw.pastebin.com/4VZGsknt | 13:18 |
| * ogra bets line executing 15 is slower than just keeping line 17 alone | 13:20 | |
| ogra | *executing line 15 | 13:20 |
| hrw | right | 13:21 |
| ogra | also does upstart like exit 0 ? | 13:21 |
| hrw | I took it from other init script | 13:21 |
| ogra | ah, k | 13:21 |
| ogra | i wasnt sure about that | 13:21 |
| === XorA is now known as XorA|gone | ||
| ogra | hrw, how about that one :) http://paste.ubuntu.com/437306/ | 13:55 |
| ogra | (indeed without the echo around the getty call) | 13:56 |
| hrw | ;) | 13:57 |
| hrw | ogra: http://hrw.pastebin.com/XAvmFiA8 landed in package | 13:57 |
| ogra | yup | 13:58 |
| hrw | but yes - I like your version | 13:58 |
| hrw | and it does not work on many ARM boards | 13:58 |
| hrw | ttyAM0 ttyAMA0 | 13:58 |
| ogra | why is that ? | 13:58 |
| hrw | ttySAC0 | 13:58 |
| ogra | oh, right | 13:58 |
| hrw | but case: tty([0-9]+) {} should take care | 13:59 |
| ogra | should rather be tty[A-Z]*) in the case | 13:59 |
| hrw | or that | 14:00 |
| === JaMa is now known as JaMa|GoNe | ||
| asac | ogra: what was the hint that told ubiquity on a live cd what packages not to include in the install? | 15:13 |
| asac | ah ... thats ./binary/casper/filesystem.manifest-desktop | 15:14 |
| hrw | prpplague: hi | 15:48 |
| prpplague | hrw: hey bud | 16:01 |
| hrw | prpplague: any rumours when pandaboard will hit market? | 16:02 |
| prpplague | hrw: yea, but i'm not if the info can be released | 16:02 |
| prpplague | i'll ask about that | 16:02 |
| hrw | http://www.flickr.com/photos/hrwandil/4506971517 | 16:46 |
| robclark | hrw: any plans for what sw / UI to be running on that? Remote control? | 16:49 |
| hrw | robclark: for now it is just machine for live-helper and other such things | 16:49 |
| hrw | robclark: I planned to make beagleboard tv but so far did not get good working wifi | 16:50 |
| robclark | ahh | 16:50 |
| ogra_cmpc | hrw, with the ubuntu kernel ? | 16:50 |
| hrw | ogra_cmpc: previous was with 2.6.32 from ti-psp | 16:51 |
| ogra_cmpc | ah | 16:51 |
| ogra_cmpc | i yet have to find a usb wlan stick that doesnt work on ubuntu | 16:51 |
| hrw | ogra_cmpc: tplink TL-WN721N? | 16:52 |
| hrw | ogra_cmpc: it is 802.11n, needs ath9k_htc driver | 16:52 |
| hrw | FATAL: Module ath9k_htc not found. | 16:53 |
| ogra_cmpc | grmbl | 16:54 |
| hrw | ogra_cmpc: FATAL: Module ath9k_htc not found. | 16:54 |
| hrw | ogra_cmpc: it is in wireless tree | 16:54 |
| ogra_cmpc | weird | 16:54 |
| hrw | http://hrw.pastebin.com/hDCp05fH - known? | 16:55 |
| ogra_cmpc | all USB wifi drivers should be enabled in out omap kernel | 16:55 |
| ogra_cmpc | if not thats a bug | 16:55 |
| hrw | ogra_cmpc: all existing in mainline, yes | 16:55 |
| rcn-ee | hrw, we got a thread on linux-omap about dss/core.c:323! ... no fixes yet.. | 16:56 |
| ogra_cmpc | hrw, trying to shut down the board while DPMS is active ? | 16:56 |
| hrw | ogra_cmpc: no just "reboot" command | 16:56 |
| ogra_cmpc | i only get that if the screen is off | 16:57 |
| ogra_cmpc | as long as its on it reboots fine | 16:57 |
| hrw | ogra_cmpc: I do not checked does lcd is on or off | 16:57 |
| hrw | probably off as I do all over serial+ssh | 16:57 |
| ogra_cmpc | so imho its a DPMS vs DSS2 issue | 16:57 |
| ogra_cmpc | right | 16:57 |
| ogra_cmpc | we have a bug about it open somewhere | 16:58 |
| rcn-ee | bug 563650... still occurs with 2.6.34 + dss2 next... | 16:59 |
| ubot2 | Launchpad bug 563650 in linux-ti-omap (Ubuntu Lucid) (and 1 other project) "DSS2 oops when shutting down while DPMS is active (affects: 1) (heat: 10)" [Medium,Confirmed] https://launchpad.net/bugs/563650 | 16:59 |
| ogra_cmpc | https://bugs.edge.launchpad.net/ubuntu/lucid/+source/linux-ti-omap/+bug/563650 | 16:59 |
| ubot2 | Launchpad bug 563650 in linux-ti-omap (Ubuntu Lucid) (and 1 other project) "DSS2 oops when shutting down while DPMS is active (affects: 1) (heat: 10)" [Medium,Confirmed] | 16:59 |
| ogra_cmpc | bah rcn-ee beats me :P | 16:59 |
| rcn-ee | it's one i'm playing source wise with right now.. ;) | 16:59 |
| ogra_cmpc | nice ! | 16:59 |
| hrw | ok, rt2570 and rt3070 refuse to work | 17:00 |
| hrw | rt3072 | 17:00 |
| hrw | rt2570 gets connected/disconnected and loop | 17:01 |
| ogra_cmpc | do you have linux-firmware installed ? | 17:02 |
| hrw | yes, firmwares exists | 17:03 |
| hrw | anyway end of day for me | 17:03 |
| ogra_cmpc | hmm, make sure to file bugs for all of them | 17:03 |
| hrw | have a nice weekend | 17:03 |
| hrw | will | 17:03 |
| === hrw is now known as hrw|gone | ||
| ogra_cmpc | you too | 17:04 |
| === GrueMaster_ is now known as GrueMaster | ||
| Cosmo` | hi chaps, anyone got any experience running Ubuntu on the Beagleboard? | 18:29 |
| ogra_cmpc | Cosmo`, https://wiki.ubuntu.com/ARM/Beagle | 18:30 |
| Cosmo` | thanks ogra_cmpc, i've actually already got it up and running via the netinstall | 18:30 |
| Cosmo` | which is actually really good | 18:30 |
| Cosmo` | but i'm experiencing some strange behaviour | 18:31 |
| Cosmo` | (i am still working out exactly what's going on bear with me for half hour ;) ) | 18:33 |
| Cosmo` | it seems that whenever i do anything intensive over the USB the whole thing just trashes itself | 18:40 |
| Cosmo` | the USB hub powers down | 18:40 |
| ogra_cmpc | you should always use a powered hub with a beagle | 18:40 |
| Cosmo` | i am | 18:40 |
| Cosmo` | however ... i have an idea | 18:40 |
| Cosmo` | one sec | 18:40 |
| ogra_cmpc | what board revision is that ? | 18:40 |
| Cosmo` | C3 i think | 18:41 |
| ogra_cmpc | hmm | 18:41 |
| ogra_cmpc | i havent seen issues like that with the C4, not sure about the C3, rcn-ee might know about that rev | 18:41 |
| rcn-ee | (jumps back in)... Cosmo` is this over ehci? there is a known issue with load on C2/3's.. | 18:41 |
| ogra_cmpc | heh | 18:41 |
| rcn-ee | (hence the C4 ehci power redesign) | 18:41 |
| Cosmo` | if i'm honest | 18:42 |
| Cosmo` | i have no idea | 18:42 |
| rcn-ee | it's labeled.. next to the usb 2.0 (ehci) connector... ;) | 18:42 |
| Cosmo` | no i mean i know it's C3 | 18:42 |
| Cosmo` | but i don't whether it's over ehci | 18:43 |
| Cosmo` | hmm | 18:43 |
| Cosmo` | i think this MIGHT be the problem | 18:44 |
| Cosmo` | one sec | 18:44 |
| rcn-ee | oh sorry... the OTG port (little one next to the 5.0volt) is usually called "MUSB" and the regular usb 2.0 port is called "EHCI" mostly becuase it doesn't support old Usb1/1.1.. (ehci only) | 18:44 |
| rcn-ee | there is a cap mod listed in the beagleboard forums, but most people just use the MUSB port by default on C2/3's... | 18:45 |
| Cosmo` | hmm, not seeing anything that says EHCI | 18:45 |
| Cosmo` | interesting | 18:46 |
| ogra_cmpc | the std. sized USB socket is ehci | 18:46 |
| Cosmo` | i tried powering from the USB OTG just then from my PC and not from the hub | 18:46 |
| Cosmo` | same issue | 18:46 |
| Cosmo` | however | 18:46 |
| Cosmo` | it gets rid of alot of the weird USB errors i was having | 18:46 |
| rcn-ee | Cosmo`, http://elinux.org/BeagleBoard#EHCI talks about the hardware issue.. | 18:46 |
| Cosmo` | right, thanks let me take a look | 18:46 |
| * rcn-ee goes back to beer and grillin.. ;) | 18:47 | |
| Cosmo` | ok, that certainly looks plausible | 18:47 |
| Cosmo` | doh, now i need to get one of those special OTG connectors | 18:47 |
| Cosmo` | is there any way you can force it in software to be a host without using one of the special connectors? | 18:48 |
| ogra_cmpc | a power supply should hlep too, no? | 18:49 |
| Cosmo` | yep, i will need to use one if i am using the USB OTG as a host | 18:49 |
| Cosmo` | at the moment i am powering it from the USB OTG, but i can run back up to the lab and get a power supply | 18:49 |
| Cosmo` | hmm | 20:14 |
| Cosmo` | there's an aggrevating lack of places to buy USB OTG cables in the UK | 20:14 |
| rcn-ee | yeah they've always been hard to find... you can find them at cell phone stores for nokia phones... look like: http://search.digikey.com/scripts/DkSearch/dksus.dll?lang=en&site=US&KeyWords=10-00003-ND | 20:17 |
| rcn-ee | or if you have an atmel avr8/32 development kit, they usually throw one in their too... | 20:18 |
| Cosmo` | well rcn-ee | 20:19 |
| Cosmo` | do you know if i can just force the port into host mode in software? | 20:19 |
| rcn-ee | yeah it's just a config option, you you'll have to rebuild... | 20:20 |
| Cosmo` | because i don't see why i couldn't just use a Mini-B to USB | 20:21 |
| Cosmo` | and plug it into a powered hub | 20:21 |
| Cosmo` | would that work? | 20:21 |
| rcn-ee | yeah it would work.. as long as you jumper the two pins on the beagle.. | 20:21 |
| Cosmo` | oh, so it cannot be done without hardware modification then? | 20:21 |
| Cosmo` | as i can't modify this board | 20:21 |
| rcn-ee | you can either do a software change (config in kernel) or hardware change.. | 20:21 |
| Cosmo` | ah, ok | 20:22 |
| Cosmo` | well i've got no problem with rebuilding the kernel, i'll do it that way | 20:22 |
| Cosmo` | the board doesn't belong to me, i've borrowed it from our research group | 20:22 |
| Cosmo` | is there anything special to know for the ARM kernel or can i just follow standard Ubuntu kernel compilation tutorials? | 20:23 |
| rcn-ee | actually as long as you don't need it at boot.. you might be able to play with: /sys/devices/platform/musb_hdrc/* | 20:23 |
| rcn-ee | my Bx beagle has "cat /sys/devices/platform/musb_hdrc/mode" ->a_host | 20:24 |
| Cosmo` | hmm ... i could try this | 20:24 |
| Cosmo` | i will have to go to the lab and get an adapter first though | 20:24 |
| rcn-ee | with everything on the otg bus, you'll need a serial cable to gain console access to bring it up.. | 20:25 |
| Cosmo` | well i'll just plug a keyboard in on the EHCI port | 20:25 |
| Cosmo` | that doesn't seem to be enough to crash it all | 20:25 |
| Cosmo` | and i can plug it into a monitor so i can make the changes directly | 20:26 |
| rcn-ee | it's high bandwith devices.. usb harddrives/usb ethernet that usually casue it for mine.. | 20:26 |
| Cosmo` | so do i just echo a_host into mode | 20:26 |
| rcn-ee | yeap.. do it as root.. (sudo su) | 20:27 |
| Cosmo` | well hold on, i'll pop to the lab and get an adapter first anyway, can't do anything without that | 20:27 |
| Cosmo` | be back in 20 minutes or so | 20:27 |
| Cosmo` | well | 21:08 |
| Cosmo` | great success | 21:08 |
| Cosmo` | let's see if i can get this working | 21:08 |
| Cosmo` | hmm rcn-ee ... i don't seem to be able to get permission to echo into mode in musb_hdrc | 21:12 |
| rcn-ee | yaep.. you have to use 'tee' or switch to root.. "sudo su" then do it.. | 21:13 |
| Cosmo` | interesting | 21:13 |
| Cosmo` | not used ubuntu before | 21:13 |
| Cosmo` | so never had to do 'sudo su' :) | 21:13 |
| rcn-ee | basicly sudo echo "x" > 'y' doesn't work. ;) | 21:14 |
| Cosmo` | hmm ... | 21:14 |
| Cosmo` | i get a write error with an invalid argument when using "echo 'a_host' > mode" | 21:14 |
| rcn-ee | weird.. just try 'host' not sure why mine is a_host but it's what google shows | 21:16 |
| Cosmo` | odd | 21:17 |
| Cosmo` | that worked | 21:17 |
| Cosmo` | well | 21:17 |
| rcn-ee | when you read back is it host or a_host? | 21:17 |
| Cosmo` | it goes straight back to b_idle anyway | 21:17 |
| Cosmo` | it doesn't error though | 21:18 |
| persia | So, one should generally not `sudo su`. In almost all cases, `sudo -s` is preferable. For redirects, something like `cat foo | sudo tee output.file` is the common solution (only writes the file as root, and keeps the process running as non-root) | 21:22 |
| Cosmo` | right | 21:23 |
| Cosmo` | i'm used to using other distributions so typically i would usually just sudo | 21:23 |
| Cosmo` | and then simply su when it's needed (rarely) | 21:23 |
| Cosmo` | oops | 21:28 |
| Cosmo` | i guess you just can't do it in software on the beagleboard | 21:43 |
| Cosmo` | so rcn-ee, i guess the only option for software will be to recompile the kernel | 22:08 |
| Cosmo` | any pointers on where to look for how to do this? | 22:14 |
| === james_w` is now known as james_w | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!