=== bjf is now known as bjf[afk] [01:58] rcn-ee, kinda sorta :p [01:58] * ogra_cmpc is surprised to see that cwillu actually uses that non-work nick [01:59] i always thought thats only channel decoration :) [01:59] heh [01:59] I don't usually have any arm equipment to hack on here :p [02:00] * prpplague pokes ogra and ogra_cmpc to see if they are alive [02:00] barely [02:00] working since 7am (its 3am now) ... and nearly falling over [02:00] ogra_cmpc: ubuntu arm with multiple frame buffers [02:00] ogra_cmpc: i'll make it quick [02:01] sounds intresting, do you think X is capable of managing them properly ? [02:01] well i know X is, just not sure how [02:01] * prpplague isn't a userland person [02:02] will likely need changes to the xserver [02:02] hmm [02:02] the current omapfb one we have even hardcodes fb0 [02:02] OH [02:02] there is big room for improvement :) [02:03] we need to start discussing it now [02:03] (or when more correctly when you've had some rest) [02:03] are you going to be working with the blaze and/or panda? [02:03] prpplague, at a time when XorA is around, he is upstream for the omapfb xserver [02:04] OH [02:04] i work with both, yes [02:04] * prpplague can deal with XorA hehe [02:04] heh [02:05] ogra_cmpc: we need to setup a time with XorA within the next 7 days to discuss the matter [02:05] i havent tried omapfb on the panda yet though [02:05] ogra_cmpc: i have ubuntu running on one fb at a time right now [02:05] i seem to be one of the lucky guys that have a HDMI monitor the panda can actually handle [02:05] ogra_cmpc: but not both [02:06] they seem to be rare atm, some issues wiht reading EDID data [02:06] ogra_cmpc: thats odd, we've not found one that doesn't work [02:06] intresting [02:06] ogra_cmpc: we need to get sync'd up on this so i can resolve those issues [02:06] prpplague, does maverick's omapfb support xorg's -nr yet? [02:06] well, mine works too, even though i was told samsung would be the most problematic and i have a samsung [02:06] i.e., plymouth slickness [02:06] it's a trivial patch if not [02:07] cwillu, you didnt file a bug and patch yet ;) [02:07] cwillu sorry don't know, i'm normally a kernel/boardbringup guy [02:07] cwillu, file me a bug and i'll upload the fix [02:07] feel free to even assign it to me [02:07] ogra_cmpc: now, is your display actually hdmi or is it dvi-d? [02:08] HDMI [02:08] I think I have a debdiff [02:08] the DVI port isnt working yet i was told [02:08] whether it's actually sane is another matter [02:08] ogra_cmpc: dvi is working but has some timing issues [02:08] so i didnt bother to try [02:08] ah, i was told differently [02:08] ogra_cmpc: you can actually use the HDMI port to connect to a dvi-d display as well [02:08] indeed [02:09] 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] but i'm using the DVI port for the beagle, so having the panda on HDMI is very convenient [02:09] (and my main machine onj VGA) [02:09] saves a lot of space ;) [02:09] ogra_cmpc: right np [02:10] ogra_cmpc: i actually prefer using dvi-d devices myself [02:10] inded i can switch plugs around for testing [02:10] ogra_cmpc: anyway, when is the best time to contact you via irc to debug some of this? [02:10] european business hours usually [02:10] ogra_cmpc, okay, I'll ping you tomorrow from _at_work :p [02:11] ogra_cmpc: ahh, ok [02:11] i'm normally up after 9/10 UTC [02:11] 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] great [02:11] * prpplague hands ogra_cmpc some nice belgian ale and sends ogra_cmpc to bed [02:12] *slurp* [02:12] :) [02:12] wait the belgian was for me, i was suppose to give you some coors [02:12] lol [02:12] * prpplague jokes with ogra_cmpc [02:13] * ogra_cmpc gets a pilsner urquell from the fridge then :P [02:13] hehe decent choice [02:13] * prpplague drinks his duvel [02:14] 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] ogra_cmpc: dont suppose you are headed to CELF-EU ? [02:15] is it in prague this time ? [02:15] cambridge [02:15] * ogra_cmpc is going to the ubuntu distro sprint ... doing face to face work [02:15] when is it ? [02:15] october [02:16] if it doesnt clash with any ubuntu dates i might go [02:16] http://www.embeddedlinuxconference.com/elc_europe10/index.html [02:16] we're releasing on the tenth this time [02:16] 27 and 28 [02:16] sounds good [02:17] i'm hoping i'll get a trip to Nice from TI sometime soon, but i have to do some major work [02:17] Nice is nice :) [02:17] though its probably way to warm now [02:17] ogra_cmpc: hehe, just an excuse to visit some of belgian abbeys [02:18] heh [02:18] * prpplague goes to read schematics [02:18] later [02:18] night then [02:19] * ogra_cmpc will go to bed after the beer [08:44] ogra, Amitk: ping [08:44] lag: wassup? [08:44] Hey amitk [08:45] I'm chatting with someone on another channel [08:46] He says "I am presenting about the BB at OSCON and want to get Ubuntu working to demo" [08:46] Would like eye-candy [08:46] Do we have eye candy for Beagle yet? [08:49] 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. === hrw|gone is now known as morning === morning is now known as hrw [08:49] morning [08:49] Eye candy == Desktop (in my Luddite kernel speak) :)# [08:50] Is Desktop running on Beagle? [08:50] lag: it does [08:50] Great [08:50] Where do I (he) get it from? [08:51] lag: download the images from http://cdimage.ubuntu.com/ports/releases/10.04/release/ [08:51] the maverick images are a WIP [09:20] ARGH [09:21] Bug #579227 ¬_¬ [09:21] 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 === Jefro is now known as Jefro_afk [09:38] directhex, why dont you use an ubuntu kernel and the recommended way to run the vm ? [09:39] directhex: Looks like you're passing too much RAM [09:39] directhex: How do you run QEMU? [09:39] lool, as suggested on http://www.aurel32.net/info/debian_arm_qemu.php [09:40] directhex, https://wiki.ubuntu.com/ARM/RootfsFromScratch [09:40] directhex, look at "Using a qemu image with full emulation" [09:40] directhex: With the images from there as well? [09:41] 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] really what i need is both, of course [09:41] directhex, then you need two kernels and two images [09:42] ogra, right. [09:42] directhex, well the above ubuntu instructions are used by many users [09:42] if you follow the howto corretly it should just work [09:43] *correctly [09:43] 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] it did crash without -m 128 though [09:43] looking at www.aurel32.net that page seems to be last edited in 2008, no idea how accurate that still is [09:44] directhex: It looks like someone borke the default -m value [09:44] directhex: Just pass -m 128 or -m 256 systematically [09:44] lool, that seems to help [09:44] directhex: if this is for package builds, you might be interested in qemubuilder [09:44] lool, for mono chroots wont work [09:44] lool, right now this is for debugging [09:45] directhex: I started this page https://wiki.ubuntu.com/UbuntuDevelopment/Ports listing possible ways to develop for Ubuntu ports, it links back to RootfsFromScratch pages to create rootfses, but there are other ways [09:46] ogra: qemubuilder uses a real vm AFAIK [09:46] ah, i thought it was like pbuilder [09:46] it is like pbuilder [09:46] lool, oh, some of that looks useful [09:47] lool, hmm, doesnt our pbuilder use chroots ? [09:47] lool, which -cpu value is closest to the debian baseline? [09:47] 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] at least the implementationm emmet worked on [09:47] directhex: You dont need to worry about the CPU value of your emulated machine [09:48] directhex: Unless you're trying to debug something where you're generating code that requires a too recent CPU [09:48] e.g. you're generating v7 code for Debian binaries [09:48] lool, i'm trying to debug something where i'm generating code that requires a too recent CPU [09:48] assuming that's causing the SIGILL anyway [09:48] Ok [09:48] let me look [09:49] directhex: I'm grabbing gcc-4.4 sources to see how it's configured [09:52] WOHOOOO !!!!! \o/ [09:52] http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/current/ [09:52] not sure how well it works though [09:53] I'm stupid, I should just look at the build log [09:53] "--with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16" is used for Ubuntu [09:53] --target=arm-linux-gnueabi [09:53] hrw: Debian one [09:54] Debian do not force any tune flags [09:54] yup, exactly [09:54] so gcc defaults are used [09:54] armv4t probably but maybe even armv4 [09:55] because gcc 4.4.x is able to do EABI for armv4 (strongarm etc) [09:56] directhex: Oldest I can find is arm946, which is already armv5t [09:56] directhex: It might not work with your versatile kernel though [09:57] arm946? rather arm926 [09:57] lool, so i can't emulate armv4t? and even armv5t is troublesome? man, ARM is messy :/ [09:58] directhex, qemu is [09:58] directhex: qemu-arm is able to do arm926 and higher [09:58] hmm.. omap310 may be arm920 but I am not sure [09:59] dont blame arm for drawbacks of an emulator, thats like saying intel is crap because vmware is buggy :) [10:00] nope. omap310 is arm925 which is armv4t [10:00] ogra, in the absence of an ubuntu arm porterbox for mere mortals, i need to make do [10:00] there are porterboxes, they are just not accessible for everyone [10:01] 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] ogra, hence "for mere mortals" [10:02] directhex, we'll get there [10:02] likely this year [10:03] ogra: Hmm really? [10:03] lool, matter of affordable powerful HW [10:03] pandas for everyone! [10:04] lool, the panda should be available by end of the year for a reasonable price [10:04] ogra: i dont think that's the issue, we have a porter box already [10:04] 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] lool, if we can have PPAs because its cheap to put up a bunch of pandas thats nearly as good as a porter box imho [10:05] ogra: having cheap powerful hardware doesn't give us PPAs though [10:05] but indeed i also mean you can just buy one for under $150 [10:05] lool: but if we get 10 pandas for LP/PPA? [10:05] or 50 [10:06] (which is more what i'm after :P) [10:06] this will make big build farm [10:06] right, thats what i would like to have [10:06] you can stack pandas, give each SD card for rootfs + nfs storage for builds and it will fly [10:06] it's not a problem of buildd power I'm afraid [10:06] That's certainly one of the issues [10:06] indeed a PPA doesnt give you shell access but it will improve the situation a lot [10:07] but another one is security [10:07] yes, thats something we need to sort [10:07] and i'm positive we can do that with joined effort of ubuntu-arm and linaro [10:07] hrw: nfs for builds is a terrible idea, it breaks plenty due to timestamp skews and other issues, but it's possible to use networked storage -- or simply USB [10:08] ogra: What's your security story then? [10:08] lool, dedicated pandas with the same setup the other PPAs use but with real HW instead of kvm ? [10:08] lool: having 4U 20TB storage is easier to maintain then 50 USD harddrives [10:10] rather than nfs use iscsi or ata-over-ethernet [10:10] suihkulokki: Yes, exactly, or even nbd [10:11] <3 nbd [10:11] ogra: So real hardware in the DC is not going to fly I'm afraid [10:11] lool, why not ? [10:12] 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] otherwise, it might be possible to do nasty things in one PPA build, which would affect the next one [10:12] lool, aufs ftw ;) [10:12] ogra: IS has the details, but essentially we cant allow direct hardware access, especially on ARM where it might mean changing the bootloader and such [10:13] which is why we use xen / kvm on x86 [10:13] anyway - nfs was just a nane [10:13] name [10:13] lool, i'll write a spec for m+1, lets see what IS says about the ideas i have [10:13] apt-cacher-ng ftw [10:14] 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] lool, essentially my plan would be to run the boards like ltsp clients (nbd squashfs image remotely merged with a tmpfs in ram) [10:15] 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] 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] ogra: Problem is that you cant prevent the build from touching it [10:15] sure you can, especially on a panda [10:15] since it has root permissions in the form of installing any other PPA package [10:16] you make the vfat inaccessible so nobody can fiddle with kernels and the like [10:16] ogra: Ok; I might like background on this hardware then [10:16] ogra: How do you make it inaccessible? [10:17] on a partition level, setting a type the kernel wont touch for example, i guess there are other ways [10:17] "wont touch" [10:17] what if I build a kernel module which allows me to overcome that, and then modprobe it [10:17] or wait, you remote boot anyway [10:17] there doesnt need to be a vfat [10:17] yes, but that doesn't prevent me from changing the config that says to remoteboot [10:18] e.g. fconfig or uboot-env-tool to update the bootcmd [10:18] how would you do that if everything lives on a remote boot server ? [10:18] ogra: I'm sure there are ways to protect from that, such as signatures or some form of container for ARM (e.g. lxc, even if not very secure, would allow hiding a bunch of devices) [10:19] ogra: Certainly the boards have their boot setup stored in flash somewhere? [10:19] no flash on panda [10:19] how do you tell it to network boot? [10:20] there are only two ways you can boot a panda, serial or SD [10:20] you pull the bootloader via serial, then let it tftpboot [10:20] ogra: ok, that might a good way then, always providing the boot bits on SD and rebooting after each build; it needs some kind of hardware remote reboot though [10:21] so everything lives on a remote x86 machine the user doesnt have access to [10:21] 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] right, thats my plan [10:21] and then get elmo drunk and sign it off ;) [10:25] is there an easy way to see which instruction caused a SIGILL? [10:32] directhex: if you do that under gdb, you should get a backtrace and you can also disassemble at the point of the sigill [10:33] alternatively, compiling your kernel with CONFIG_DEBUG_USER and booting with debug_user=1 should do the trick [10:34] user_debug=, sorry. [10:41] oh for the love of... qemu segfaulted whilst installing lucid === asac__ is now known as asac [11:01] amitk: Are you around? [11:02] And ogra [11:02] * ogra_cmpc is here with half an eye [11:02] asac, http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/current/ [11:03] (no idea if it work though) [11:03] *works [11:03] ogra_cmpc: I am having troubles with my Beagle XM and Lucid [11:03] lucid ? [11:03] Can you get a console? [11:03] that wont work [11:03] Yes, Lucid [11:03] Doh! [11:04] lag: yeah? [11:04] kernel is missing bits [11:04] amitk: I think my question has been answered [11:04] Balls [11:04] lag: you're expected to fix the missing bits in maverick :-p [11:04] So I won't be able to bug-fix on Lucid OMAP3 [11:04] you also need the maverick x-loader/u-boot [11:04] I have it working for Maverick [11:05] you do ?!? [11:05] with the default bits? [11:05] amitk: No one specified that [11:05] lucid is beagle C4 only [11:05] lag: that is why you got the board. Implied specification? ;) [11:05] * lag thinks people need to tell me these things [11:06] I thought I received it so I could fix bugs on OMAP3 and the Panda to fix bugs on OMAP4? [11:06] woo [11:06] * amitk agrees and beats himself up [11:06] That to me was implied [11:06] maverick is supposed to work on as many omap3 platforms as we can make possibkle plus panda and blaze [11:06] Okay [11:07] So I am a Maverick guy? [11:07] lag: the XM appeared towards the end of the lucid cycle, so there wasn't enough time to enable it in Lucid [11:07] lag, well, dont you have a C4 too ? [11:07] I only learned that it was a new board a little while ago [11:07] lag: but if a few patches make it work in lucid, then I guess an SRU is possible [11:07] I thought Beagle was Beagle [11:07] http://paste.ubuntu.com/456338/ [11:08] That is my Lucid run [11:08] amitk, it needs a new bootloader, i doubt we can SRU that [11:08] ogra_cmpc: What's the difference in bootloaders? More sysIDs? [11:09] ogra_cmpc: I'm not sure if lag flashed a non-Lucid bootloader onto the XM [11:09] lag: is this console capture from a stock lucid image? [11:09] amitk, it comes withou preinstalled bootloader afaik [11:10] ogra_cmpc: Not true [11:10] Well, not for me anyways [11:10] mine did and i havent seen one that had anything in nand [11:11] amitk: Yes, I built it from git [11:11] though ours were early ones [11:11] ogra_cmpc: It doesn't have NAND [11:11] afaik the XM isnt shipped yet anyway, there are stll ram issues according to #beagle [11:12] lag, q ah, right, that was the issue :) [11:12] Yes, that would do it :) [11:13] So amitk, I am to work on Maverick [11:13] Check [11:13] * ogra_cmpc has a hard time typing sitting in position that only allows i finger typing atm [11:13] I'll stop assigning myself to Lucid bugs then :) [11:13] s/i/1/ [11:13] ogra_cmpc: Are you in jail? [11:14] ;) [11:14] kind of, i got a sick cat on my lap sitting in my living room [11:14] Oh dear [11:14] holding the cmpc with 1 hand above my haed trying to type [11:14] Did NCommander manage to kill his cat in the end? [11:15] What is cmpc? [11:15] ask him :) [11:15] classmate pc [11:15] 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] lag: I managed to put Ubuntu on my Nexus One, then NFS mount my laptop's HDD [11:15] Lol, looks like a toy [11:15] conveniently small for use in the living room where i dont want other computetrs [11:16] NCommander: Nicely done [11:16] * ogra_cmpc is having a coffee break watching the presidential election in germany on TV [11:16] amitk: Who's my lead? [11:16] amitk: I think here lies the issue [11:16] lag: rtg [11:16] NCommander, how is your cat related to that ? [11:16] amitk: I'm a floater [11:16] amitk: He hasn't asked me to do anything - ever :S [11:17] I'll speak with him today [11:17] 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] lag: I'll sound him out for you ;) [11:17] shudder [11:17] amitk: It's okay. I can speak with him direct via other means [11:17] lag: and if TZ is an issue, then perhaps apw [11:17] He should be on soon [11:18] It's not an issue [11:19] amitk: Which OMAP3 board does mpoirier have? [11:19] C4 afaik [11:19] balls [11:20] he might have an XM too, not sure [11:20] We were working together yesterday to try and get my Beagle up and running [11:20] I assumed he had an XM [11:20] Okay [11:20] I'll have to re-touch base with him today [11:21] Thanks for clearing things up ogra & amitk [11:21] in any case talk to the guys in #beagle too, about the issues why XM isnt shipped yet [11:21] I've been talking to them this morning [11:21] It's due in July [11:21] perhaps your oopses are related [11:21] As I say, I have a console running [11:22] No, my oopses are Lucid only [11:22] with the archive kernel and archive bootloaders ? [11:22] Maverick works [11:22] cool [11:22] * lag uses the word 'works' loosely [11:22] I have a running console [11:23] well, as long as the default binaries we provide get you that, thats a good step already [11:23] Kind of - there is one issue with SDHC cards [11:23] You have to turn off preempt to get them to work [11:24] i think we have that on the C4 too [11:24] there is a bug mpoirier is working on [11:24] Correct [11:24] Same thing [11:25] so not XM specific [11:25] Nope [12:10] lag: there's issues with memory on the xm, though [12:11] kai: What issues are those? [12:11] hm, I just realized that my work account isn't in #beagle, so I guess they already told you that [12:11] kai, are you incognito today ? [12:11] ogra: no, I'm kblin from my "home" box and kai at work [12:11] ah [12:11] I have a different channel selection [12:11] i never saw you as kai :) [12:12] yeah, #ubuntu-arm technically isn't related to work :) [12:14] work is more related to high performace computing, not really a playground for ARMs [12:14] kai: http://paste.ubuntu.com/457317 [12:17] kai, pfft ... if you stick enough beagles together you can have a HPC cluster too [12:26] ogra: right, and I get data off them with ultra-high-speed USB connections :) [12:27] at least ... if not these super fast serial connections :) [12:27] lag: not entirely convinced [12:27] er [12:27] ogra: ^^^ [12:28] lag: if you're saying this only happens with specific kernels, that's probably not the memory issue [12:28] but ask jkridner about the memory thing [12:29] It's the first time I've seen it [12:29] And I've only seen it once [12:33] ok [12:33] as I said, ask one of the TI folks about the memory issues with the xm === JaMa is now known as JaMa|Off [14:15] ogra: ping [14:16] ogra_cmpc: This perhaps? [14:18] heh [14:18] lag, whats up ? [14:19] Have you been asked to have a think about syslink? [14:20] we discussed it here yesterday, yes [14:20] I've been asked to lend my services [14:20] How may I assist you [14:21] err, i didnt do anything with it, only gave a recommendation how to handle the loading of the module best with regard to our images [14:22] since the kernel apparently cant do it alone [14:22] fixing that part would help, beyond that, fixing the module itself is in sebjan's TODO i think [14:23] lag, i also think there are some patches in sebjan's branch we dont have yet to fix the loop issues [14:24] That's correct [14:24] I'm keeping an eye on those [14:24] I've also been asked to touch base with you [14:24] Have we come a conclusion as to which method would be best? [14:24] a way to probe the platform bus for devices to make the module autoload would be the best [14:25] but i'm not sure about the technical possibilities here [14:25] wrt kernel [14:25] How about something in /etc/modules, or upstart? [14:25] i know we had platform devices for NIC drivers before under imx51 and these were autoloaded without /etc/modules [14:26]