=== asac_ is now known as asac === Lopi is now known as Lopi|idle === lilstevie is now known as lilstevie|ZNC === fairuz_ is now known as fairuz === lilstevie|ZNC is now known as lilstevie [10:28] hello, having read about the problem to build 20,000 packages for arm and the panda-cluster, I wonder if the ubuntu-devs ever tried or even heard about icecream? http://en.opensuse.org/Icecream [10:30] yes [10:31] aholler: Distribuited buildshave not been the issue. The issue has been lack of hardware for native builds. [10:31] using icecream you could use every x86 box [10:32] to help you build your packages [10:32] How can anx86 build arm "native" packages? [10:32] read about how icecream works [10:32] Not cross-compiled. Native. [10:32] sure [10:33] x86 does not run arm instructions w/o emulation. [10:33] read about how icecream works [10:34] ogra_: do you have tried it? [10:34] After a quick glance, again I ask how this would have helped the lack of arm hardware issue we faced prior to our panda cluster? [10:35] btw: I have worked on distribuited build environments before. [10:35] package builds are usually single threaded, that doesnt gain you much with most packages [10:35] GrueMaster: you could use e.g. make -j20 and the compilation would be done by the x86-boxes [10:36] but the tests would be done localy = native [10:36] Listen to what I am saying. how does an x86 box compile native arm code w/o cross-compiling? [10:36] * ppisati didn't read anything about "the problem to build 20,000 packages" [10:37] I spent 8 years in processor validation at Intel, and now work on arm code. The instruction sets areentirely different. [10:37] GrueMaster: again, read about how icecream works. [10:37] nothing on your arm-box will see the difference [10:37] there is cross-compiling and cross-compiling [10:37] the binaries will be built with a cross toolchain ... [10:37] thats the difference [10:38] just the objects [10:38] you cant guarantee that you get identical binaries with a cross toolchain [10:38] We build all binary packages on their native hardware. We do not rely on cross-compilation. [10:38] GrueMaster: I assume you haven't understand how icecream works. anyway, I'm off, I don't see why I should try to continue this discussion [10:39] I know how icecream works. I have talked with some of the devs when they started building it. [10:40] iirc NCommand1r used it across 4 babbages for OOo builds [10:40] No, he used distcc. [10:40] hmm, i thought it was icecream [10:40] I love this kind of talks [10:40] hrw, you could have chimed in :) [10:41] 'hey guys, why you are building natively? are you insane? cross compilation on farm of cheap x86 is better' etc... [10:41] as compiler expert [10:41] I guess the guy you chased away was trying suggest running the build on one arm machine which the calls icecream/distcc to x86 machines running crosscompilers [10:41] suihkulokki, yes [10:41] SuSE OBS ... [10:42] OBS dodn't due that [10:42] i thought they inject an x86 compiler into a native build env [10:43] you should invite the guy back if you are really intersted in how they do instead of rejecting them on sight ;) [10:43] I honestly don't see how ANY distributed environment would benefit anyone that needs native hardware and doesn't have it. [10:43] the distributed part only helps with packages using -jN [10:44] We could easily deploy icecream (or any other distributed build environment) on our cluster, but the issue was the lack of hardware. [10:44] suihkulokki: like GrueMaster said - we lack native builds and this is a problem to solve [10:45] xU with 120 a9 quadcores for example - I read on linuxdevices that someone is working on such beast [10:46] yep. That would be a nice addition to my rack cabinet at home. :P [10:46] * ogra_ waits until he can buy that in a mac mini like case [11:15] GrueMaster: Hi. You and rsalveti have provided patched kernel for Beagle xM rev C. Is it possible to have it patched to support i2c bus 2, which is available on expansion port/ [11:15] ? [11:33] garagoth: Have to ask rsalveti. As soon as he provides me with a binary, I'll update the tarball. [11:39] ogra_: btw - how much ac100 costs in .de? [11:46] GrueMaster: Ok, thanks. [11:47] rsalveti: Is it possible for you to patch that patched kernel you prepared for beagle xm rev C to support i2c bus 2 (which is on expansion port) ? [11:47] hrw, my last one costed me 170€ off the shelf [11:48] 202EUR here [11:48] ppisati, http://hackaday.com/2011/06/12/how-canonical-automates-linux-package-compilation/ ... [11:48] ogra_: It was cheaper because of that funky keyboard. :P [11:49] "Canonical needed a way to compile about 20,000+ packages for the ARM platform, however they did not want to cross-compile, which is quite time consuming." [11:49] * ogra_ shakes his head [11:49] why would cross compiling be quite time consuming [11:49] on the contrary I would say... [11:50] heh, yeah [11:50] probably i'm reading it wrong though [11:55] there is no ubuntu-arm mailing list? [11:56] bug 791302 needs someone familiar with library symbols? [11:56] Launchpad bug 791302 in libechonest "libechonest version 1.1.3-1 failed to build on armel" [Undecided,New] https://launchpad.net/bugs/791302 [11:56] suihkulokki: no, ubuntu-mobile was dropped [11:56] suihkulokki: ubuntu-devel is used [11:57] I shall spam ubuntu-devel then =) [12:01] ok, I'll try it again. [12:01] To enlight the people here about waht I'm speaking, using icecream only a part of the compilation process is distributed. And there is absolutely no problem when this part is a cross-compiler/-assembler. Thats a whole difference to what people usually are thinking about cross-compiling. [12:02] And using icecream is much better than using distcc, because the building machine distributes the (cross-)compiler (as a chroot, once). [12:02] what gets distributed is a tar-archive containing that stuff: http://www.fpaste.org/PyrG/ [12:02] aholler: does it takes care of mix of amd64/i386/armel/armhf build machines too? [12:03] yes, the build-machine gets informed about the architecture of the slaves and can send them the needed chroot [12:03] I think I will have to setup icecream farm of pandas here [12:03] or just don't use them [12:03] that even speeds up compiling using only -j1 [12:04] aholler, as i said above, we wouldnt get much benefit from a distributed env, the majority of the packages will default to not use -jN [12:04] aholler: I spent 6 years on cross compilation [12:04] there are some where it really helps, i agree [12:04] i.e. libO [12:04] hrw: fine for you [12:05] or firefox ... but the majority wont really benefit from it... for us its more important to build as many *differnt packages* at the same time as possible [12:06] most packages could be build using -jN, at least when ext4 is used. [12:06] the target of the build cluster is to empty the queue as fast as possible to keep up with the other arches, so "more paralell builds" > "faster builds" [12:06] with ext3 there are more problems, because of the limited timestamp [12:07] a single source is still compiled a lot faster on x86 (+network transfer) than on an arm [12:07] it would be good to have a fully native icecream setup on another panda cluster though and route the packages that can benefit from it to that build system [12:08] we definitely wouldnt use it with a cross compiler [12:09] Actually, if icecream can manage client build systems appearing on the fly, it could easily be deployed now on our panda cluster. [12:09] but the concept could indeed help with native compilers too ... [12:09] do you expect a different output from a cross-assembler than native? [12:09] the possibility exists [12:09] aholler: Yes, and we have actual documented bugs with that. [12:10] don't mix that concept icecream/distcc uses which the stuff people usually are understanding with cross-compiling [12:10] s/which/with/ [12:11] anyway, it is just a suggestion, I don't need to convince the people here. [12:12] well, i like the concept of distributed building ... [12:12] ditributed cross- is even better [12:12] thats something i would not agree on :) [12:13] * ppisati -> out to get some food [12:13] I've used that a lot to build x32packages on x64-machines (and vice-versa) several years before [12:14] no, wrong, the other machines helped building the packes, they haven't build them [12:14] anyway, maybe one of you might try it. I'm off again. ;) [12:14] we use x86_64 machines to build i386 packages all the time. That isnt an issue. [12:15] he's gone [12:17] hm. how to call shell in perl and get return as value of variable? [12:19] hrw: give me a minute and I'll pastebin a sample ofcode I wrote while at Intel. [12:22] $var = `command`; ;) [12:23] thats as clever as using system() :P [12:24] with system I have to play with $? etc to get result [12:26] looks like gnu-smalltalk will be fixed [12:26] not that I know perl but fix was needed in perl script [12:28] hrw: Looks like you have it. [12:28] my $multiarch_dir = `dpkg-architecture -qDEB_HOST_MULTIARCH`; [12:28] chomp($multiarch_dir); [12:29] and then one more check in script [12:30] ok. passed step where it was failing [12:31] now time for debdiff [12:31] hrw, Why not "use Dpkg:Arch ..."? That should save considerable cycles. [12:32] (if you just care about multiarch, then "use Dpkg:Arch qw(debarch_to_multiarch);" is probably sufficient) [12:32] persia: because I do not know perl? [12:33] persia: so I am trying to get some hack which works and then it can get improved [12:33] hrw, Heh. So, take a look at the dpkg-architecture source. [12:33] It's fairly trivial to just pull the value from the libary (and we have a nice code example) [12:33] thx [12:34] Around line 196 is the bits you'll need, although you'll also need the use statement near the top. [12:36] my $multiarch_dir = debarch_to_multiarch(get_raw_host_arch()); [12:36] That looks cleaner to me. Does it work? [12:36] Also, how is get_raw_host_arch() implemented? Is this something you could also pull from the library? [12:36] both are from Dpkg::Arch [12:37] I picked code from dpkg-architecture [12:37] Ah, heh. That sounds ideal then, if it works :) [12:37] persia: build in process [12:37] Just be sure to specify both in the use statement, so they are available. [12:37] did [12:37] Perfect :) [12:37] persia: thanks for tips [12:37] No problem. Thanks for asking for help on the channel *before* you found the final solution. [12:39] persia: as I'm not perl programmer I prefer to make sure that my thinking is right. [12:39] persia: and my workflow for bugs is: make a fix and then make a fix to be a proper fix [12:40] Makes sense. I tend to try for a precise problem statement, then a proper fix (which is nearly the same thing, except that I tend to express the problem in English rather than code). [12:41] persia: first ver of fix was good but implementation was bad ;D [12:41] Not bad, just didn't take advantage of the fact that dpkg-architecture was itself implemented in perl, with a handy library. [12:42] Was dpkg-architecture in C, then I think your implementation would have been the least bad. [12:42] (assuming nobody had created perl bindings for the library) [13:08] ppisati: ogra_: GrueMaster: http://comments.gmane.org/gmane.linux.redhat.fedora.arm/1266 [13:08] pointed by agreen, if we want to have a better buildd this would be something to look for [13:10] rsalveti: Is it possible for you to patch that patched kernel you prepared for beagle xm rev C to support i2c bus 2 (which is on expansion port) ? [13:11] garagoth: sure, sorry, just got on-line [13:11] garagoth: what exactly do you need? [13:11] I have trainer board from tin can tools attached to beagle xm C and I need to use i2c which is there. [13:12] It is nice as it is level translated to 5V [13:12] it is i2c bus 2 [13:12] but on your kenel only buses 1 and 3 are visible [13:13] garagoth: oh, ok, guess it's the patch pointed by rcn-ee [13:16] I hope so :-) I had no sources of your kernel, so could not test it myself. [13:16] rsalveti: I had seen a blurb on the pandaboard mailing list regarding usb drive speed & networkiing. When I get home I mean to do some additional testing, including using a usb-nic (not the on-board nic) to see if that makes a difference. [13:17] garagoth: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=summary if you get the HEAD you'll get the same working kernel [13:17] 10.44 [13:18] garagoth: if you build this kernel and add the patch https://github.com/RobertCNelson/stable-kernel/blob/master/patches/sakoman/2.6.39/0032-OMAP3-beagle-add-support-for-expansionboards.patch it may work [13:18] didn't check if you need any other dependencies [13:19] rsalveti: So, build it myself or will you be doing it anyway? [13:20] garagoth: I can guide you if you want, then you can hack it later if needed ;-) [13:20] rsalveti, what exactly do you suggest ? rinning a ping daemon ? [13:20] *running [13:20] ogra_: well, agreen is investigating the kernel to see if we can get a fix [13:20] Would be nice. I need to setup cross-compile env for ubuntu then... somehow :-) Or compile on Beagle [13:21] but would be good to keep an eye on it [13:22] garagoth: http://www.omappedia.org/wiki/Ubuntu_kernel_build_alternatives [13:24] rsalveti: Ok, processing... [13:26] I guess you are cross-compiling? [13:27] rsalveti: weird [13:28] garagoth: yes [13:28] ppisati: why? same chip for both usb and eth :-) [13:30] I like the FIFO queue not overflowing answer. It's more plausible than most of the other proposed "why"s. [13:33] well, the ignore_oc stuff seems like a red herring to me [13:35] I'd say so. [13:35] But that's different than the queue management. [13:41] persia: can i have unity on pandaboard? [13:41] (on natty I mean) [13:42] zumbi_, You can have unity-2d. I don't believe everything was ported to work properly with the GLES drivers TI provided. [13:42] (someone please correct me if I'm wrong). [13:42] so unity-3d not yet ready on arm hw :/ [13:43] persia: thanks [13:43] zumbi_, in th enext weeks [13:43] ogra_: sure, I guess as part of oneiric [13:44] there are two bugs left afaik ... once these are solved it should be available for natty [13:44] later then oneiric [13:44] (all work is done on the natty branches atm and will need forward porting then) [13:45] ogra_, This is GLES porting? [13:45] yes [13:45] uhm.. ok, sounds fine, I'll try it on few weeks then [13:45] for compiz, nux and unity [13:45] zumbi_, rsalveti should be able to point you to a PPA for that [13:45] zumbi_, What's your specific interest? The interface, or reviewing the code paths? [13:46] (beyond that they should show up in the natty release PPA for panda) [13:46] If the former, then unity-2d is supposed to be mostly the same (although some things are different) [13:46] If the latter, I'm sure folk would appreciate additional testing/help with the remaining few bugs. [13:46] zumbi_: https://launchpad.net/~rsalveti/+archive/unity-3d-gles [13:46] ogra_, Do you happen to know the bug numbers? [13:46] zumbi_: not fully working yet [13:46] persia: right now, my interest is have a technology preview, we are currently using Qt for UI design [13:47] rsalveti: thanks [13:47] but you should be able to try it in the following days [13:47] persia, for what ? [13:47] zumbi_, unity-2d is implemented in Qt, so yeah, that doesn't necessarily show anything particularly different. [13:47] ogra_, The compiz/nux/unity bugs. [13:47] i dont think there are bugs [13:47] * persia grumbles [13:48] When "there are two bugs left", those should be filed in launchpad, and discussion happen there. [13:48] there is a team working fulltime on fixing them though :) [13:48] And the team doesn't want another member, for some reason? [13:48] and they report to places i am [13:48] ask linaro :) [13:48] i guess they wont deny if someone wants to help indeed [13:49] rsalveti, Are there bugs? What sort of help could speed the process? [13:49] persia: https://bugs.launchpad.net/unity-gles [13:49] Only one left! [13:49] zumbi_, ^^ [13:50] i thought there was one nux bug too [13:50] but seems that got fixed already [13:50] * jussi prods at persia [13:50] we just discussed at the call and we may have an additional bug for nux [13:50] but still not confirmed [13:51] but it should all be sorted out during this and next week [13:52] the screenshots look cool though [13:53] you should leave it that way and call it unidelic instead of unity :) [13:54] ogra_: hehe :-) === zyga is now known as zyga-food [15:05] and another porting jam just starting at #linaro! come and help us making ubuntu better on arm :-) [15:05] https://bugs.launchpad.net/ubuntu/+bugs?field.tag=arm-porting-queue&orderby=-id [15:10] GrueMaster, soo, your ac100 ... did you actually test if the issues also show up if you manually untar the rootfs ? [15:11] I have put it back on the back burner. Need to be productive on current tasks. [15:11] k [15:11] well, i cant do much until we have identified the actual problem [15:12] make sure to definitely bring it to dublin [15:13] I plan on it. [15:13] will surely be faster to find the issue if i have direct access [15:14] Not sure what the final goal is. If it is just to get me enabled with an ac100, I'll do it as time allows. If we plan on deploying a working installation for other users, it makes sense to debug it and I can add it to the test pool as time allows. [15:15] well, i want the installer to work properly on all models indeed [15:23] seems we are not the only one experiencing issue with usb and gcc 4.6: [15:23] https://lists.yoctoproject.org/pipermail/poky/2011-April/005703.html [15:24] the thread continues in may 2011 too [15:24] https://lists.yoctoproject.org/pipermail/poky/2011-May/005763.html [15:24] rsalveti: Ok, more or less the patch succeeded. Is git clone of the kernel source already with proper config, same as it is on beagle? [15:27] fully updated 11.04 running on a pandaboard, when i try to boot it i get things like [15:27] (stk) : line disc installation timed out [15:27] (stc) : KIM failure complete callback [15:27] that is the bluetooth driver. known issue. [15:28] ah - i just needed to wait long enough [15:28] never saw that before, is it an update-regression? [15:29] and it seems there's a fix... testing... [15:29] Yes and no. It didn't happen in maverick as the driver was rewritten and hasn't been finalized at time of release. === zyga-food is now known as zyga-afk [15:34] what is a proper way to request arm rebuild of package? [15:34] octave-communications 1.0.10-3 was ftbfs on armel 7 weeks ago due to lack of build deps. now they are fulfilled [15:35] one sec [15:35] I am building this package on panda now [15:35] it was bug 791314 btw [15:35] Launchpad bug 791314 in octave-communications "octave-communications version 1.0.10-3 failed to build on armel" [Undecided,New] https://launchpad.net/bugs/791314 [15:36] rebuild triggered [15:36] thx [15:36] https://launchpad.net/ubuntu/+source/octave-communications/1.0.10-3/+build/2469824 [15:36] I just loaded that [15:38] ppisati: The thread continues in June as well. [15:38] yeah [15:38] differently named though [15:39] https://lists.yoctoproject.org/pipermail/poky/2011-June/006634.html is very intresting [15:41] and there's a fix [15:41] wait... [15:42] ppisati, https://lists.yoctoproject.org/pipermail/poky/2011-June/006646.html this one ? [15:44] yep [15:44] but it seems it's not working :( [15:44] well, they later say you should just remove the line completely [15:45] let's try... [15:48] nope [15:50] anyway, let me forward this info the toolchain people [15:51] yeah [15:51] a disassembly like that from our own binaries might help too i guess [15:54] yep [15:54] in the April they were saying they had this issue with the vanilla FSF 4.6 toolchain so it seems it's an upstream bug [15:59] could be [16:04] ok, mail sent [16:04] let me update the lp bug too [16:04] ++ [16:26] I'm trying to compile ubuntu kernel for Beagle, but process fails with error: "as: unrecognized option '-Qy'" [16:26] Any hints? [16:30] which ubuntu? [16:30] and do you have binutils-arm-linux-gnueabi installed? [16:33] natty [16:33] and yes, I have [16:39] so...? [16:46] rsalveti: ping [16:47] hi, anyone knows the uname+pwd for ubuntu-11.04-preinstalled-netbook-armel+omap.img.gz, thx [16:47] there is none [16:47] you set it up during the first boot [16:47] during install you setup your user [16:47] this is a pre-installed image [16:48] pre-installed image which install itself [16:48] at least should... [16:48] yes [16:49] you boot it, it should show you installer [16:49] you select lang, keyboard, packages, user [16:49] the first thing I see is a log-in screen [16:50] the only option is to click 'other' user [16:50] on dvi port? [16:50] yes [16:50] is it ubuntu branded? [16:50] yes, and this is where I downloaded from: http://cdimage.ubuntu.com/releases/11.04/release/ubuntu-11.04-preinstalled-netbook-armel+omap.img.gz [16:51] melis51: What platform are you using? [16:51] Beagleboard [16:51] What rev? [16:51] c3 [16:53] Odd, although you may be running out of memory. I don't remember an issue testing on my C4 though. [16:54] on bb-xM rev C I saw setup screen on X [16:54] try the headless image instaed and then install ubuntu-netbook using tasksel [16:54] When you boot, is it pulling anything from nand, or is it booting completely off the SD? You can tell by watching the serial console. [16:54] oh, right, NAND ! [16:54] * ogra_ totally forgot [16:55] ogra_: That's why you keep me around. :P [16:55] indeed, it might not pull the right initrd in [16:55] GrueMaster, yeah, we all love you :) [16:55] I can't tell right now, but will check [16:56] Do the ARM PPAs build naively? [16:56] melis51, there are instructions on the wiki how to make sure to boot right [16:56] lag, yes, thats why they arent public [16:56] ogra_: All of them? Even my own PPA? [16:57] only trusted people have upload permission [16:57] melis51: Check the Maverick instructions. They have more detail on the beagleboard w/ nand. [16:57] indeed you can make the binaries public [16:57] ora_ I fallowed GrueMaster's instructions on the wiki that worked up until the log-in screen [16:57] ogra_: Let me try to explain [16:57] * GrueMaster updates the instructions for natty. [16:58] ok I will try Maverick, but would be nice to get the latest ver to work too [16:59] you dont need to try maverick [16:59] only the maverick instructions for booting begales with NAND on them [16:59] ok [16:59] Maybe someone can help me with cross-compiling to beagle on natty? I have "as: unrecognized option '-Qy'" [17:00] garagoth, well, hrw is your best option ... beyond that, file a bug against the cross toolchain [17:01] melis51: You can use natty, just follow the maverick instructions specific to the beagleboard rev C. [17:01] Natty Instructions updated to include these now. [17:01] garagoth: fill a bug with exact info what you are doing ok? [17:01] ok thanks I'll try [17:01] hrw: ubuntu-bug or ..? [17:02] garagoth: ubuntu-bug armel-cross-toolchain-base [17:02] garagoth: add "arm-linux-gnueabi-gcc --version" into bug raport [17:03] Ok. [17:03] ogra_: http://ppa.launchpad.net/linaro-landing-team-ste/st-ericsson-u8500-public/ubuntu/pool/main/l/linux-u8500/ [17:04] Would that have been build natively [17:04] lag, yes [17:04] ogra_: Great, thanks! [17:04] we dont so any non native builds in the datacenter [17:04] thanks everyone for your help! [17:04] s/so/do/ [17:05] hrw: it says: no such package: armel-cross-toolchain-base [17:05] melis51: got it working? [17:06] garagoth: so use binutils-arm-linux-gnueabi one [17:06] garagoth: armel-cross-toolchain-base is source package [17:07] I'm not at home, so I will try it a bit later today and will let you know, thanks [17:25] hrw: Hm, can it be because I have no arm-linux-gnueabi-gcc? It is in package gcc-4.4-arm-linux-gnueabi, but I have gcc-4.5-arm-linux-gnueabi which install /usr/bin//usr/bin/arm-linux-gnueabi-gcc-4.5 [17:26] and there is no symlink or anything to arm-linux-gnueabi-gcc [17:26] garagoth: apt-get install gcc-arm-linux-gnueabi then [17:29] ok, time to finish session for me [17:29] have a nice rest of day [17:30] Oooh. I removed from PATH /usr/arm-linux-gnueabi/bin and it started working [17:30] ARGH YOU! :D [17:31] Yes, I create errors. But without your hint I would never find it. [17:32] I was missing one package [17:32] So, thanks a lot and have a nice day as well :-) [17:32] * garagoth crossess fingers to make it compile. [17:34] If I do not click 'Submit bug report' on web page, it is not visible to anyone, right? [18:30] persia: heya im working on a fix for libvirt on arm fyi [18:50] excuse the FAQs, but is there an LTS release for ARM yet and will there be an armv7 Ubuntu release? [18:50] my googling is returning misleading info. [18:53] jkridner: 12.04 will be thefirst LTS release for arm. Armv7 has been supported since 10.04 [18:53] (but 10.04 was not LTS for arm). [18:53] thanks! [18:54] I think 10.04 was armel, compatible with armv7, but not optimized for armv7. [18:54] It was the first armv7 release. [18:55] Our armel port has been armv7 for a while. [18:55] Don't confuse the dpkg arch name with the compiler target. [18:55] (Much like our i386 port won't actually run on 80386 machines) [18:55] True, not all packages were built with full armv7 optimizations, but main was. [20:00] ogra_: there? [20:01] someone know if ubuntu still needs mx51 or omap4 subarches on debian core, more specifically debian-installer [20:01] lool: ^ [20:18] GrueMaster: hi, I changed the setenv as you suggested, but ubuntu won't boot on my beagle === zyga-afk is now known as zyga [20:52] rsalveti: ping [20:53] Hm. I am trying to compile ubuntu kernel with expansion boards support and I have encountered a problem. Some boards have irq_set_irq_type(...) invoked but it is nowwhere defined [20:54] google claims it to be a standard interrupt api function... [20:58] hm, it is there named set_irq_type, not irq_set_irg_type... confusing... [20:59] garagoth, that got changed in 2.6.39... [21:01] garagoth, 2.6.38 and earlier used "set_irq_type", 2.6.39+ uses "irq_set_irq_type" [21:01] damn. One small revision number... [21:02] I'm sooo close to make it work, damn... [21:02] So much trouble to have i2c bus 2 working ;-) [21:03] well the simplistic patch would just to add: "omap_register_i2c_bus(2, 400, NULL, 0);" in the i2c section... but i thought you had a trainer board.. [21:03] yes [21:04] I have [21:04] well, the big patch set's everything up for the trainer.. (and more..) [21:04] and I found usage for gpio, so I need more then i2c, so patching... [21:05] back to soldering while kernel continues to compile... [23:59] zumbi, Support for mx5 and omap4 continues to be useful :) [23:59] persia: thanks, you mean mx51?, I realized that reading omappedia.org