[10:02] apw: Heya [10:03] apw: On https://bugs.launchpad.net/ubuntu/+source/linux/+bug/524893 the config change can actually be reverted; it didn't help and wasn't actually needed once the fix was found [10:03] Launchpad bug 524893 in qemu-kvm (Ubuntu Lucid) (and 3 other projects) "versatile: Can't boot initramfses (affects: 1)" [Low,Fix released] [10:04] I also had in mind to kill the default cmdline from the config, it overrides the ATAG mem information and qemu-ssytem-arm uselessly defaults to 32MB of RAM [10:04] (that is, passing -m foo to qemu-system-arm isn't enough, one has to pass mem=foo too) [10:04] 32MB!!!!! [10:04] Yup [10:05] triggers d-i "Low mem mode" [10:05] persia: It's from the defconfig [10:05] it's an old board [10:09] right. [10:17] apw: sent to the list [10:18] persia: BTW did you get a chance to go over the /Ports page? [10:18] persia: I'd like to hook it up from the /Development page now [10:21] Unfortunately not. It was top-of-my-list for Saturday, until something else intervened. I'll look at it as soon as I've eaten. [10:21] Ok thanks === ogra_ is now known as ogra [11:57] Are there any good reasons for me to up my host to Lucid to develop/build Luicid ARM targets (w/rootstock)? [11:58] nosse1, depends if you also want to test x86 lucid. ;) otherwise karmic works fine, just use the bzr trunk of rootstock [11:59] of course I want to test Lucid x86 as well... ;) [12:00] rcn-ee: rootstock is one, script right? Not spread across several files? [12:00] yeah, it's just a script that access qemu.. [12:01] excellent. I think I got it then. [12:01] Now I'm this close to attempt to run Lucid on TI AM3517 Zoom eval kit [12:04] it should work as i run it on a varity of omap35x targets... just make sure you config meets these requirements http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/2.6-stable/annotate/head%3A/readme.txt [12:06] rcn-ee: Have you deployed Ubuntu on any omap35x targets for production environments, or just still development? [12:09] nah, i haven't pushed my customers off karmic yet, as lucid just hit beta-1 last week.. [12:09] i have two internal development beagles running it 24/7 thou, testing different things.. [13:07] Ush... ARM Lucid didn't work out-of the box... Well, I didn't really expect that either... [13:08] works here :) [13:09] It boots the kernel, and head into NFS, but then it just sits there after "init: ureadahead main process (552) terminated with status 5" [13:09] ah, NFS [13:10] there might be mountall bugs with NFS, check launchpad [13:10] Are there any good tools for debugging nfs-links? i.e. smart cmd options for tcpdump [13:10] I'd like to see what specific files are being accessed [13:10] well, try to reach your server from the busybox shell in your initramfs etc [13:11] thats why ubuntu uses initramfs all over the place ... makes debugging so easy :) [13:11] hehe: That might just be it then. I tried without initramfs :o [13:12] well, depending on your kernel it should work even without initramfs [13:12] its years ago i used rootfs on NFS so i wont be a big help [13:13] Because you dont really need the initramfs if everything is build statically in the kernel, right. Theres nothing special the distro requires? [13:13] there is [13:13] lost of packages place stuff inside the initramfs in ubuntu [13:13] *lots [13:14] How do you build one then? [13:14] update-initramfs -c -k [13:14] on a running system [13:14] Thats assuming a running system, yes [13:15] (prefix that with sudo) [13:15] if you dont have a running system, take your sd make sure to have qemu-arm-static installed and run the command in a chroot on the SD [13:15] (on your x86 system) [13:16] * nosse1 noob, SD=? [13:17] Sd card [13:17] oh, you probably dont use one if you use NFS :) [13:17] just chroot into your exported rootfs then [13:17] Ah. So thats how you run instead of NFS? [13:20] using an SD card, yes [13:21] I recon, since you compile packages natively, moving files back and forth to x86 isn't made as often as you would on a purely crossed target [13:21] ..so a SD card is fine [13:22] right, i usually only use x86 for bringup and building a booting image [13:23] i have to admit my other colleagues are sceptical to build the apps natively on a 500MHz ARM target [13:24] well, if you use ubuntu as ubuntu developer you can just develop under x86 :) [13:24] the packages are built automatically on all arches anyway [13:25] yes, I see both advantages and disadvantages of doing it like this [13:25] it really depends *what* kind of app you buiuld natively though [13:26] I'm a little worried that vanilla ubuntu becomes too heavy for a small ARM target, yet it is nice to not have to worry about the system [13:26] if its just a desktop app it surely is a lot easier to build it natively and have all dependencies already available [13:26] well, define *small* [13:26] The other alternative is some kind of LFS in a cross build environment [13:26] Our product will have a sys-flash of 1G [13:27] LFS cross building might gain you incompatible binaries [13:27] 1G flash isnt enough for any of the ubuntu desktops [13:28] not sure about LXDE but even if that would fit it wouldnt leave you much space for user data [13:29] Yes. Package and product upgrade feats of distro like Ubuntu is very tempting [13:29] indeed [13:29] No desktop (sort of). The product will be a end-user product where the user shall not know that Ubuntu is running behind the curtain [13:30] But it will be a Qt app running either on X11 or directly to fbdev [13:30] Size isn't that critical (shoult fit into 1G), but startup-time into final application is far more critical. [13:30] well, if you only compile your app, i would go with natively ... [13:31] whats the desired time you have ? [13:31] and with which bootloader ? :) [13:31] Q is then how much tweeking to Ubuntu is needed to make the app start fast enough [13:31] TI uses U-boot [13:32] which is a fairly slow thing in itself [13:32] Lets say 10-30 secs is fine [13:32] thats half of it for uboot [13:32] Uboot will be optimized in order to speed things up [13:33] thats the easy part [13:33] if you only fire up your app 15sec should beeasily doable [13:33] my laptop takes 8 from grub to gnome desktop atm ... [13:34] Ah, but it's a laptop.. What are we talking about on your ARM targets? [13:34] and that starts a lot more stuff, even though its x86 and 4G RAM and a fast SSD, 15sec for u-boot-end to app-on-screen will be achievable [13:35] ARM targets are depending on the disk you run your system off [13:35] mainly [13:35] ubuntu-netbook on a babbage board takes from 35 to 45sec [13:35] (thats imx51 from USB key or USB attached SATA disk) [13:36] though imx51 loses nearly no time to the bootloader ... (6-10sec) [13:36] redboot is a lot faster than u-boot ... but a lot less flexible [13:37] BTW: Those ARM targets used in the Launchpad build farm, what kind of machine/specs are we talking about? Some of these compiles must take a while? [13:37] (and very painful) [13:37] the ARM buildds are all imx51 800MHz 512M machines [13:37] Yeah, I know. I've been working with imx35 previously and thus redboot [13:37] with USB disks [15:01] lool: Regarding Development/Ports : there's a lot of TODOs left: are you sure you want to strong-link it already? [15:01] Also, there are N ways to set up schroots: I'm unsure I want to document all of the manual methods (and they're all painful). [15:01] persia`: We could hide them as comments [15:01] Yeah, hiding them works. [15:01] persia`: Well, I'd like to document how you use sbuild for arm development [15:02] I can document use easily. [15:02] For creation, I can't recommend mk-sbuild enough. [15:02] persia`: hidden now [15:02] persia`: Oh ok, I thought you tested mk-sbuild successfully? [15:03] Sorry: translation error. I mean to say that not using mk-sbuild is so painful that there is no limit to the degree to which I will recommend it to any schroot/sbuild users [15:04] persia`: Do you consider the sbuild section good enough? [15:04] Basically, one has to create the (directory, tarball, LV snapshot, etc.) manually, and then stick it somewhere, and then write the configuration manually. [15:04] I'll add in some notes on usage with schroot and sbuild. [15:05] persia`: I'm not a regular sbuild user; I have it installed and now how it can overall work, albeit not the latest features thereof [15:05] persia`: Ok good [15:05] persia`: When you're done, just remove the commented-out TODO [15:24] Where does rootstock stage its files? [16:02] OK, sorry for my elementary questions: If I have a rootstock/qemu image either as .img or as tar.gz, how can I invoke qemu to boot from that image/root? [16:02] I.e. I need a kernel and I need to make the kernel load the root from the image, I presume [16:03] nosse1, see the rootfs from scratch wikipage (from the channel topic) [16:05] ogra: embarrasing. Of course, thanks! [16:09] lool: Sorry that took so long. Use of schroot/sbuild documented : please take a look to make sure it makes sense to you. [16:15] persia`: Looks good [16:15] lool: What I wonder is if we need to go to any more effort to make clear that these procedures (should) work for armel/powerpc/sparc [16:16] (getting a little off-topic for this channel) [16:16] I don't want to create the impression that one must use pbuilder for armel and sbuild for powerpc, nor the impression that this is armel only. [16:16] persia`: Let's hope that the people reading it are technical enough to understand that, and fix it if we discover it's a problem [16:16] That sounds reasonable :) [16:17] I don't think it's off topic for this chan since we're trying to improve ports documentation as driven by the lack thereof for arm ;-) [16:17] heh [16:17] Do you happen to know if qemu-system-ppc needs as many special arguments as qemu-system-arm ? [16:18] persia`: I happen not to know [16:18] * persia` either [16:18] Oh well, there's enough fast ppc HW out there that most folks use native anyway. [16:18] ISTR seeing people run qemu-system-ppc without any -M arg, but I don't know what kernel's we're building for [16:19] Wow powerpc has a vmlinux and armel a vmlinuz, how odd [16:22] ogra: Now this is interesting. Earlier this day I failed getting lucid to run on target. Kernel booted, but failed in userspace. When I now start qemu, I get the same failure [16:32] nosse1, whats the failure ? [16:35] Hold on. I hoped I could get the console output with -nographic, but it only dumps the pre-linux bootloader [16:39] nosse1: I often find "-monitor stdio" to be useful argument when I'm having issues, as this lets me manipulate the session in the terminal whilst it executes in the SDL environment. [16:42] ogra: From the start of init, I see the following messages 1) modprobe: Could not load ...modules.dep 2) init: ureadahead main process (381) term. with status 5 3) mountall: Could not connect to Plymouth 4) Same as 1 again [16:42] thats all fine [16:42] nothing to worry about [16:43] Then nothing. After a while I get sda sense key errors in qemu [16:43] thats something to worry about :) [16:44] This time I'm running from ext3 file-image [16:44] how did you build your image ? just using rootstock --notarball ? [16:44] Yup [16:45] and then the commandline from the wiki ? [16:45] with the kernel from there ? [16:45] Hold on, I'm getting lots of errors on e2fsck of the image [16:45] yes [16:46] i dont see that here [16:46] what was the exact commandline you used with rootstock ? [16:46] Hoi.. Here I got a tracedump of something in the console [16:46] I used "sudo ./rootstock --imagesize 1G --seed ubuntu-minimal --dist lucid --notarball" [16:47] ah [16:47] well, that will fire up oem-config [16:47] rootstock is the patched one to be able to use my karmic against lucid [16:47] which can take a few minutes to start [16:47] persia`: Apparently, one needs to pass -M prep to qemu-system-ppc, and one needs a BIOS which we lack in Ubuntu; see https://bugs.launchpad.net/ubuntu/+source/openbios-sparc/+bug/183495 [16:47] Launchpad bug 183495 in openbios-sparc (Ubuntu) "[FTBFS] openbios-sparc (1.0~alpha2+20070816-1) fails to build in hardy (affects: 3) (dups: 1)" [Medium,Confirmed] [16:48] nosse1, if you want to prevent oem-config just use th e-l and -p options for rootstock [16:48] *the -l [16:48] persia`: surprisingly, the two files mentionned by https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/60478 are around on my system [16:48] Launchpad bug 60478 in qemu (Debian) (and 1 other project) "Missing files for qemu-system-ppc (dup-of: 183495)" [Unknown,Fix released] [16:48] Launchpad bug 183495 in openbios-sparc (Ubuntu) "[FTBFS] openbios-sparc (1.0~alpha2+20070816-1) fails to build in hardy (affects: 3) (dups: 1)" [Medium,Confirmed] [16:49] ogra, thanks I'll try. My end objective is to get a working image for me to be able to use on target. [16:49] lool: I have them both as well. [16:50] nosse1, well, if you boot it on the target system, just wait a little longer, it will bring up oem-config after a while [16:50] lool: I know far too much about the openhackware and openbiod-sparc issues. They aren't fixable with current Soyuz. [16:50] to configure user, language, keymap etc [16:51] W: u-boot-omap3 source: quilt-build-dep-but-no-series-file [16:51] lool: OK, so qemu-system-foo really only works for armel right now. That makes it easy. Thanks for checking. [16:51] hmm, is that new ? [16:51] ogra: No. [16:51] i never needed debian/patches/series before [16:51] ogra, I have to admit I perhaps didn't wait long enough to determine whether the target was busy or dead. [16:51] persia`, well, the complaint is [16:51] quilt creates it automatically. [16:51] No, it's been around since jaunty, at least. [16:52] ogra, but the output was the same on targes as on qemu [16:52] weird, i never saw that before when building a package and picking quilt [16:52] nosse1, on qemu it will take even longer until oem-config comes up [16:52] You probably never didn't have a series file before. Like I said, quilt does it automatically. [16:53] ogra: I've found quilt incredibly easier to use since adding http://paste.ubuntu.com/399386/ as my ~/.quiltrc [16:54] ah, thats nearly the same cjwatson gave me [16:55] His was from /usr/share/doc/quit/README.source [16:56] Which works exactly the same, only faster for 90% of cases. [16:56] The kernels you build for target, do you cross compile them or do you also do that natively? [16:57] nosse1, see /topic :) [16:57] nosse1: Everything is natively compiled. [16:57] bah, sigh ... series needs to contain a comment [16:58] No it doesn't. [16:58] What happens if I install gcc from my qemu. Will it be capable of generating code for real target? [16:59] nosse1: As long as your target is compatible with the instruction set gcc is targeting, yes. [16:59] persia`, diff.gz wont represent empty files [16:59] so lintian still complains [16:59] unless i add a comment or something [16:59] ogra: series shouldn't be empty unless you have no patches, and if you have no patches, you shouldn't have a build-dep on quilt. [17:00] persia`, i want the new packages i build to reflect a selection for the patchsystem [17:00] so people touching the package know what to use [17:00] ogra@babbage2:~/u-boot-omap3-2010.3git20100315$ lintian -i ../u-boot-omap3_2010.3git20100315-0ubuntu1_source.changes [17:00] ogra@babbage2:~/u-boot-omap3-2010.3git20100315$ [17:00] there we go :) [17:00] Just use Format: 3.0 (quilt) then. No build depenency required. No debian/rules magic. Expresses the preference for quilt. [17:00] * ogra builds a binary [17:01] persia`, i wont revert what i did now :) [17:01] * ogra has to get the thing done today [17:01] anyway, you're supposed to express that preference in debian/README.source [17:01] Just ask first next time :p [17:02] expressing that preference in README.source doesnt quiet down lintian [17:02] i want the package to be ready so people can just drop in diffs [17:03] as i do with i.e. dpatch [17:03] and given that asac perfers quilt and i get heat from people that i use dpatch everywhere i thought i should start switching to quilt [17:03] even though i dont like it [17:04] in any case i want my packages to be ready for patching right away, without having to fiddle with build-deps [17:04] Fair enough. Next time you do a package, make me walk you through using format 3.0(quilt) so you have it easy. [17:04] ok [17:04] (which never requires build-dep on quilt and still uses quilt) [17:10] ogra@babbage2:~/u-boot-omap3-2010.3git20100315$ lintian -i ../u-boot-omap3_2010.3git20100315-0ubuntu1_armel.deb [17:10] W: u-boot-omap3: wrong-bug-number-in-closes l3:#XXXXXX [17:10] PFFT ! [17:13] ogra: You want (LP: #...) anyway. This is the pain of dh_make [17:14] Don't forget to make it not Priority: extra too. [17:14] i know, i just havent filed a bug yet [17:14] err, what prio should it have ? [17:14] * ogra always leaves it extra [17:16] Can I shutdown qemu/debian from the monitor gracefully? I notice the ext2 img is easily corrupted [17:16] persia`, what but debootstrap uses the priority field anyway ? [17:16] errr ubuntu NOT debian. Sorry. (Don't throw any stones.) [17:17] nosse1, we wouldnt exist without debian, why would we throw anything ? :) [17:17] :D [17:17] ogra: Every package manager displays it [17:18] nosse1, the karmic version used ext2 and i'm not sure you can do anything beyond "sudo halt" ... afaik the kernel wont power off the VM, you need to close it then [17:18] persia`, so suggest a prio :) [17:18] its a bootloader that only exists on arm and shouldnt be used anyway unless you build images [17:18] ogra: "optional" is correct for nearly all new packages [17:18] ok [17:19] Wait. [17:19] "shouldn't be used anyway unless you build images"? Is it not useful for installed devices? [17:19] ogra, the login/pwd of my image doesnt work so I cannot login. And the image runs when using -snapshop. The kernel crashes without it [17:20] persia`, well you can use it if you roll your own beagle images [17:20] theoretically [17:21] but for ubuntu installs we'll use flash-kernel anyway to write u-boot to NAND [17:21] * nosse1 trying rootstock again [17:21] so there is no real point in actually using it for anyone (while you *can* if you want to) [17:22] persia`, main point of the package is to make d-i and live images using the u-boot-beagle.bin file from this package (along with the MLO file from the x-loader package thats already in the archive) [17:22] ogra: OK. YOu have a special package where "extra" happens to be correct. This is very rare :) [17:22] ah [17:23] persia`, you have to teach me one day how to make proper dh7 packages that can do multiple runs for different configs on the same source [17:24] eventually i want the u-boot-omap3 package to support all omap targets but that needs several builds [17:25] (with one binary for each target) [17:25] ogra: That's going to take time, and is best done with physical presence I think. That is the sort of thing where looking over a shoulder is useful. [17:26] i know how to do it the old way but dh7 is rather blurry to me [17:27] Yeah. dh(1) is just as flexible as dh_*, but most folk get confused because of the CDBS-like features. [17:27] yeah [17:27] its not important now though ... rather a L+1 thing [17:28] beagle only is sufficient atm [17:29] but given the source can also build for zoom1/2 and EVM boards i'D like to sopport them one day [17:44] Must qemu be run as root? [17:48] According to e2fsck, the images produced by rootstock have fs-errors [17:48] qemu definitely doesn't need to be run as root. [17:49] nosse1, that's pretty normal, just let it clean it up... [17:50] e2fsck is usually not happy with the time variances so it checks just in case.. [17:50] or use lucids rootstock (since you build minimal images anyway) [17:50] Yes, but it seems to be coinciding with crashes of apps inside qemu. I'm not sure, it just seems that way [17:50] in lucid rootstock defaults to ext3 [17:50] I'm getting inode count errors and such [17:54] nosse1, does it clear up on the next reboot? [17:54] Sometimes I get kernel crashes, sometimes stack dumps in the console and other times I get "I/O error, dev sda" [17:54] Using -snapshot seems to remedy all of these errors [17:55] sounds fun, which kernel you using? [17:55] vmlinuz-2.6.31-rc3versatile1-cortex-a8 [17:56] nosse1, thats definately not the one from the wiki [17:57] (i asked you before if you use the one from the wiki) [17:58] Yes, you're right. I have no clue where this vmlinuz-2.6.31 came from. It was just lying in my dir. [17:58] But using the one from the wiki, I still have the sda I/O error issue [17:59] heh [18:00] hey ogra, just catching up on the backlog, you guys really planning to put the kernel in nand? [18:00] (omap's) [18:00] rcn-ee, likely, yes [18:00] as long as kernel and initramfs actually fit [18:01] okay.. yeah they should... but as side note, the xm might come with no nand.. (to get 1Gb ram..) [18:01] i need to do some measuring ... my last days were busy with packaging x-loader and u-boot and starting to design the live images [18:02] from tomorrow on i'll start working on the flash-kernel changes we need and on the actual image builds [18:03] we will definately flash x-loader and u-boot with the versions from the image during install [18:03] i'm not 100% sure about kernel and initramfs yet [18:04] (for now my focus is to have *something* ready by end of the week ... we'll be able to make changes to that before beta2) [18:04] ogra: use deb3 [18:04] asac, ?? [18:05] err source format 3.0 ... that comes with great quilt integration [18:05] asac, for my next packages i will ... to late now :) [18:05] you dont need to know how to use it in order to work with it [18:05] thats evil ! [18:05] ogra: if you used quilt we can just convert it easily [18:05] true.. ;) btw, i got my iegp2 working over the weekend.. with 500.2 it'll need about 4-5 backports from 2.6.34-rc2 for dss2/ethernet.. ;) [18:05] right [18:05] cool [18:06] asac, i'm trying to use quilt by default now even though i hate it [18:06] rcn-ee, do you know if iegp2 uses the same x-loader and u-boot ? [18:06] ogra, I still get I/O error on sda using qemu and this time the kernel from the wiki ( ;) ) [18:07] it's different... ;) [18:07] nosse1, sorry i have no idea whats going on there, does your user own the disk image ? [18:07] (i.e. does he have write access to it) [18:07] rcn-ee, sad [18:07] ogra, yes [18:07] * ogra would love to have one generic omap image that works everywhere [18:08] It's using 1.4.2 x-loader, but i'm not sure if it's the same as beagle.. (it does use OneNAND Flash, so that's different..) the U-boot is 2009.08 and uses boot.ini scripts at boot. (instead of beagles boot.scr) same format thou.. [18:08] I'll search around [18:09] nosse1, worst case you could grab rootstock from lucid [18:09] but 720mhz & 512Mb ram, so it's going into my gcc farm after i get lucid booting.. ;) [18:09] or just change ext2 to ext3 inside the rootstock script manually [18:09] rcn-ee, hey, thats nearly as good as the babbage board :) [18:10] you just need SATA ;) [18:10] ok, my revC4 boots with x-loader and u-boot from the archive ... [18:10] yeap it is.. ;) yeap no sata, but onboard wifi and bluetooth.. ;) [18:10] time to call it a day ... i was up early [18:11] wifi ++ [18:11] sound cool, you have c4 usb patches right? [18:11] i havent booted to a rootfs [18:12] amitk would know if we have all patches [18:12] u-boot set's up the regulator for the ehci port on the c4, that's why i asked.. i don't think they are in u-boot mainline yet... [18:12] rcn-ee, do you know if the board initalizes the framebuffer if you dont give any omapfb options on cmdline ? [18:13] oh, i packaged u-boot-omap3 ;) [18:13] okay, that should work then.. [18:13] didnt touch mainline [18:13] sarkomans tree [18:14] i was thinking that over the weekend.. it didn't in the past... and we've always defined it on the command line... [18:14] ogra, I'm using a rootstock patch which i got from asac. I needed it to be able to run qemu for a lucid target on a karmic (64-bit) machine [18:14] so i would say no... [18:14] crap [18:15] there is a read edid script in angstrom....... [18:15] thats really messy behavior ... it should jut read EDID [18:15] yeah, that was dropped years ago from ubuntu [18:15] doesnt help me if i need the value on cmdline [18:16] the driver should just check the monitors capabilities and set the highest resolution by default [18:16] the other issue, the omapfb comand also allocates kernel memory too for the frame buffer... [18:16] i wonder why that seems to be so hard [18:16] Well, there is a big limitation on the screen size... (hardware pixel clock) [18:16] that should also have a default value [18:17] i think starting with fbfev isnt good to add EDID - but have not looked closely [18:17] well, but you know your pixel clock capability [18:17] that's one reason i always recommend the 720p value, it's the most compaitable and biggest.. [18:17] so you can fall back to something hardcoded [18:17] its just evil to have to define *defaults* on the cmdline [18:17] at least these should be there automatically [18:17] i find it ok to *override* on cmdline [18:18] but making it a requirement is just bad habit [18:18] pixel clock limitation is here; http://elinux.org/BeagleBoardFAQ#Display_resolutions_.232 [18:18] ogra: do we have graphics drivers for beagle already? [18:18] asac, from debian, yes [18:19] ogra: is that in archive and just works? [18:19] it's a sudo neon optimzed framebuffer driver... [18:19] asac, havent tried yet [18:19] the guys at allwaysinnovating also did their own varient of that too.. [18:19] but yes, there is omapfb and omapfb with NEON [18:20] we have two to pick from, not sure how good they are [18:20] i'll test that once we have a working image [18:20] use the neon one... [18:20] one step at a time :) [18:20] ogra: i guess we have neon in cpuinfo? [18:20] if thats stable i will :) [18:20] shouldnt we just install both and it will pick the right one? [18:20] asac, at least with the pre-built kernel amitk gave me [18:20] it's been the default in angstrom for a good year and half.. ;) [18:20] sounds promissing. nice [18:21] rcn-ee, angstrom uses different toolchain [18:21] so i wont say hooray until i tested it ;) [18:21] yeap, 4.3.3 vs 4.4.x.. [18:21] but yes, promising for sure [18:22] * ogra wonders if 500.2 finally made it to the archive [18:22] ogra: does JamieBennett has a usable environment alöready? maybe he can check that? [18:22] asac, he should have everything he needs [18:22] ogra: whats the status on imx kernel in -proposed ? [18:22] :-P [18:22] no idea, was it uploaded already ? [18:22] * ogra didnt get any pings yet /me thinks [18:23] which reminds me.. did amit put the vfp patches you used for imx in omap's branch? it needs it to.. [18:23] asac, ogra, ping me in the morning if you want me to check something, about to leave the house in 10 minutes [18:23] no idea, that kernel is fully his work, i only saw two binaries yet [18:24] JamieBennett, just bring up your board tomorrow so you can test stuff [18:24] JamieBennett: ok. would like to have the omap x drivers checked ... [18:24] JamieBennett: 1. do both (neon + non neon) work [18:24] okay, well it's no in mainline yet either, so it would be easy to spot in the log.. [18:24] ogra: will do, first thing I'll do in the morning [18:24] 2. is the right driver automatically selected if we install both [18:24] asac, given the kernel is stable enough to even try :) [18:24] ogra: thought we are already there? [18:25] no, it won't... i had a user with that problem on karmic.. [18:25] for me 500.2 has multiple issues [18:25] hmm [18:25] asac, its there but buggy [18:25] usb didnt work [18:25] which is somewhat essential on a beagle :) [18:25] did we backport their patches or just took the right upstream branch for .32? [18:25] ext4 wipes the FS [18:25] i think its plain mainline .33 [18:25] asac, just a config issue on the usb.. [18:26] i see the modules loaded [18:26] it oopsed when i unloaded [18:26] rcn-ee: cool. can you give ogra or kernel team pointers? [18:26] though i didnt put much time into it yet, booting and image rolling is my current main concern [18:27] once thats ready we can fiddle with the rest [18:27] ogra: right focus on that. jamie and rcn-ee can probably help if you spit out first iamges ;) [18:27] especially *everyone* can as soon as we have daily builds :) [18:27]