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