=== asac_ is now known as asac [03:39] persia: it finished cooking [03:40] and it made a bunch of _armel.udeb files and some armel.deb [04:01] persia: this look right to you? linux-headers-2.6.38-1208_2.6.38-1208.11_armel.deb linux-headers-2.6.38-1208-omap4_2.6.38-1208.11_armel.deb linux-image-2.6.38-1208-omap4_2.6.38-1208.11_armel.deb linux-ti-omap4-tools-2.6.38-1208_2.6.38-1208.11_armel.deb [04:11] history [06:35] anyone here who has built a ubuntu 11.04 kernel on arm in teh past month? [06:36] i would love to compare your procedure against the one i got pointed to [06:38] :( all i want is a kernel with todays usb patch [06:56] sudo apt-get build-dep linux-image-2.6.38-1208-omap4 [06:57] Picking 'linux-ti-omap4' as source package instead of 'linux-image-2.6.38-1208-omap4' [06:57] no apt-get, YOU DO NOT KNOW BETTER! [06:57] and sadly, i dont know how to get around this [07:00] MrCurious: Yes it does. linux-ti-omap4 is a source package, which contains the Build-Depends, linux-image-2.6.38-1208-omap4 is a binary package, which has no concept of Build-Depends. [07:01] but when i try to play along with the instructions here https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel [07:01] it derails with fakeroot debian/rules binary-headers binary-generic [07:01] as there is no binary-generic [07:01] dont suppose i could petition you tohold my hand with this process some? [07:01] or point to a set of instructions for doing it [07:02] I have no idea, sorry. I was just pointing out that apt-get is reporting a correct message. [07:02] ok [07:03] then i will continue on and try binary-arch instead of binary-generic [08:47] MrCurious, The kernel you compiled is inside linux-image-2.6.38-1208-omap4_2.6.38-1208.11_armel.deb : install this package (`dpkg -i`` may be helpful). [08:48] i think i tried that and something went amiss [08:48] on a new compile recipe now http://www.omappedia.org/wiki/Ubuntu_kernel_for_OMAP4 [08:48] giving that a crack [09:03] well that build instruction is a bust [09:03] the working origin/ti-omap4 branch is a bust [09:08] Well, expanding on "something went amiss" and "is a bust" is likely to get more information. [09:08] I make it a point to actively avoid building my own kernels, and even when I do need to generate a kernel, tend to do it by uploading it to an archive, and then installing it. [09:09] So I'm probably not the best person to provide insight here. [09:09] perhaps i am attacking this upside down [09:09] ppisati, Any suggestions on how to tweak linux-ti-omap4 locally to play with different config settings? [09:09] i should really say where i want to be, rather then some point on the road i think leads there [09:09] Always :) [09:10] there is a patch to the usb code [09:10] https://lists.yoctoproject.org/pipermail/poky/2011-June/006649.html [09:10] i want a kernel for ubuntu panda with THAT fix [09:10] do you know a easier way to get that one line fix in [09:10] to a kernel that i can get installed :D [09:11] see any alt paths than the one i am on? [09:12] getting further with this source tree :D [09:13] lets hope that WARNINGS are normal for kernel builds on this platform [09:14] There's a bug outstanding. I don't have the bug number in my immediately-accessible logs. [09:14] no worries [09:14] The easiest solution is to just wait until someone uploads a kernel with the patch, but that doesn't help with either doing it soon, or with learning how to help test patches in the future to help them get uploadede faster. [09:15] can i get you to ping me in days to come if you know how i can get my fingers on a fixed kernel with that fix [09:15] persia: what you mean? any config in particular? [09:15] No. I'll forget :) [09:16] MrCurious: unfortuntaly that fix doesn't work [09:16] ppisati, MrCurious wants to help test https://lists.yoctoproject.org/pipermail/poky/2011-June/006649.html but I don't seem to be able to find good instructions that let that happen. [09:16] it seems prplplague has tested and verified the performance of the fix [09:16] Could you help? [09:16] MrCurious: nor the other one suggested in that thread [09:16] you mean no performance perk? [09:16] actually i tried it yesterday, and it didn't work [09:16] i mean that fix [09:16] uhm [09:17] didnt work as in compile bug, or clean build, no affect on behavior [09:17] no affect, the change is trivial [09:17] you can change the attribute the way they say, or entirely delete that attribute line [09:17] just to lay a few lashes on the dead horse... [09:17] we are talking file: include/linux/usb/ehci_def.h [09:18] no changes in beahevious, usb devices are still MIA [09:18] new line [09:18] __attribute__ ((packed,aligned(__alignof__(int)))); [09:18] yes [09:18] MrCurious: did you try it? [09:18] my usb devices are all present [09:18] really? [09:18] which kernel? [09:18] just way slower than on every other machine [09:18] this fix only came out in past 24 hours [09:18] i know [09:18] wait [09:19] [pandaboard] Speed Problems with USB HDD or Networking [09:19] that thread [09:19] https://bugs.launchpad.net/linux-linaro/+bug/747639 [09:19] Ubuntu bug 747639 in linux-linaro "No USB devices on omap3 (beagle/overo) with recent linaro-2.6.38 based kernels or 2.6.29-rc1" [High,Fix released] [09:19] amd here is the bug in ubuntu [09:20] no wait, but that;s a different bug [09:20] we are talking different bugs :D [09:20] yep [09:20] phew. thought the fix to my bug wasnt good [09:20] back to trying to build a kernel [09:21] this one: https://lists.yoctoproject.org/pipermail/poky/2011-June/006649.html [09:21] is about the missing usb devices on omap3/4 with gcc 4.6 [09:21] i think i read somewhere that .0 GCC vers bring pain [09:21] and for some reason its being used [09:21] fall back to older gcc and be happy? [09:22] 4.6 is the official toolchain for oneiric [09:23] is there any way to get higher than 640x480 on pandaboard? [09:23] MrCurious: but you pointed me to the missing usb devices patch [09:23] MrCurious: and you said prplplague tested the fix, and it was working [09:24] he tested it for performance on panda [09:25] i could see that fix causing usb issues [09:28] MrCurious: i should ask him [09:28] prpplague^2: ^ [09:31] yes. i mean to ask him how i can get the image he built :D [09:32] brendand: you connected lcd to hdmi or dvi output? [09:33] hrw - it's the one labelled HDMI-1080p right next to usb/ether connectors [09:36] hrw - other one doesn't work [09:36] hrw - the cable i am using is hdmi to dvi though, my samsung monitor only has vga and dvi ports [09:42] thats fine [09:42] brendand: which kernel you run? [09:42] hrw - stock natty [09:43] 2.6.38-1208-omap4.11 [09:44] linux-image-2.6.38-1208-omap4 2.6.38-1208.11 [09:44] here [09:44] and my hdmi->dvi monitor gives 1680x1050 [09:45] Those are the same kernel: the differences in versions are because of how the versions were collected. [09:45] yep [09:45] persia - yep [09:45] i used uname -a [09:45] anyway [09:46] in 'monitors' i can't select anything but 640x480 [09:46] and xrandr only reports that as well [09:47] so your monitor was not recognized [09:47] brendand: you have any graphics on screen? [09:47] hrw - absolutely [09:48] yeah, monitors says 'unknown' [09:48] whereas my laptop says 'Samsung 23"' [09:49] If you attach the same screen to something else, can it parse EDID? [09:52] * brendand installs read-edid [09:54] hanging? [09:54] should it complete quickly? parse-edid that is [09:54] It ought. [09:55] `parse-edid < /sys/class/drm/${PORT}/edid` ? [09:55] okay [09:56] yeah, it can [09:56] hanging was obviously waiting for input [09:57] OK, so you're getting good EDID, with the right resolution and name, etc? [09:58] GOSH but the CPU gets hot durring a kernel build [09:58] i now have NINE fingerprints! [09:58] Um, putting one's finger on a CPU that has no heatsink is rarely a good idea. [09:59] yeah [09:59] they get hot. but they seldom glow [09:59] OMAP4s don't get very hot, but many chips have thermal densities exceeding that of most nuclear reactor cores. [09:59] the gumstix cpu gets much hotter ALL the time [09:59] i have been debating tossing some passive heat sink on it [10:01] Won't hurt (unless you cause physical damage in the process). Not required for long-term system health. [10:01] http://paste.ubuntu.com/628319/ [10:01] ARM chips are very much designed to run without one [10:01] 2048x1152? I thought you said 1680x1050 [10:02] brendand, That's not universally true: some designs run at sufficiently high clock speeds that they would melt. [10:02] persia: I said 1680x1050 [10:02] Your paste says 2048x1152 [10:03] his paste - sorry for mess [10:03] * persia suffers from id3entity failure,. and decides to go wake up a bit more [10:04] problem is that's for the vga port [10:04] my laptop has no hdmi port, so can't attach a cable to that [10:07] I *think* EDID info ought be the same regardless of the port used. [10:10] You could try forcing resolution on the kernel command line. [10:10] how? [10:11] I think it involves editing boot.scr and fiddling with u-boot. [10:11] hrw, Do you know the specifics there? [10:14] nope, my monitors work with panda [10:15] www.omappedia.org/wiki/Bootargs_for_enabling_display ... look for hdmimode and hdmicode [10:15] hrw, I meant about adjusting the command line: I thought you might know uboot. [10:16] ogra, Thanks! [10:16] there is a wikipage about editing the cmdline in our wiki somewhere [10:17] though just edit /boot/boot.script and run flash-kernel and reboot should be enough [10:18] persia: ah. adjusting is easy - cp /dev/mmcblk0p1/boot/boot.scr /boot/boot.script, vi /boot/boot.script, drop crap in front, edit, run flash-kernel [10:19] hdmimode/code are unknown for me [10:19] hrw, Thanks. Sorry for the confusion. [10:19] hrw, why do you copy /boot/boot.scr to /boot/boot.script ? [10:19] ogra_: cause my system lacked it? [10:19] on an ubuntu install they should always be identical [10:20] despite the header indeed [10:20] uh, why were you lacking it ? [10:20] Some folk who run Ubuntu don't perform an Ubuntu install. [10:20] ogra_: iirc plain test one was added during natty cycle - my rootfs is quite old [10:20] nah, that cant be :P [10:21] the plain text boot.script exists since we support omap4 [10:21] so your install must be really old :) [10:22] ogra_: boot.script was part of kernel image? [10:23] 10:44 hrw@malenstwo:chromium-browser-12.0.742.91~r87961$ dpkg -S /boot/boot.script [10:23] in the middle of an update will try after that [10:23] dpkg-query: no path found matching pattern /boot/boot.script. [10:23] no, but part of the preinstalled image [10:23] ogra_: I think boot.script was missing here too. My card reader is broken, cannot check properly. [10:23] ogra_: this rootfs was probably generated with linaro-media-create [10:23] ah [10:23] hrw: strings boot.scr > boot.script [10:24] zumbi: header has 'ubuntu boot script' in it iirc [10:24] yep, capital U [10:24] I thik i tried the headless image [10:45] prpplague^2: did you really get an ubuntu kernel to work with gcc 4.6? [10:49] hi guys.. is this the right place for asking some struct alignment (packed) questions how to solve in order to port a package x86->arm? [10:52] r3, You can ask. No promises that folks who know enough to answer are around at the moment. [10:58] ok, thank you, i will try [11:01] i found issues in coova-chilli which is working well in x86 but sometimes not in arm. issue is during a cast of a packed struct which contains generic fields to a in_addr struct, which is unaligned of course. now i have a working workaround, but i try to understand if there's an easier solution, because with this workaround i need to check and fix every cast of every file. i'm no expert, so probably there's a simple compiler flag which fixes this (?) would be g [11:01] reat that, would'nt it? :D [11:02] here is a bit of code containing the wrong cast commented out and my workaround: http://pastebin.com/VgxRxzJn [11:05] for more context: coova-chilli is a captive portal which during login asks a radius server for AA.. it is possible to assign (within radius) for each mac-address a static ip address which should be assigned then to that particular mac-address. we get this ip address by the radius response (that packed struct) [11:08] if such a static ip address is set within radius database, i get it, but instead of getting 192.168.11.66 after the cast i have 192.168.11.6. digging in depth, i understood that packed struct does not add the alignment padding but the cast then jumps over 2 bytes of padding, because somehow it does not know that the source struct is packed [11:09] now with that double cast (cast from packed to unaligned const struct to my in_addr struct) this problem is solved. but do i really need to change this everywhere? is this normal procedure you need to do when you port software from x86 to arm? [11:12] r3: maybe http://wiki.debian.org/ArmEabiFixes helps? === r3 is now known as _r3_ [11:17] <_r3_> zumbi: thank you! i'll take a look [11:23] <_r3_> hmm, no this case is missing. but very interesting.. i need to check some of them too, since python for example on our platform is really slow. maybe because of wrong alignment [12:00] _r3_: This is really nothing to do with ARM -- the affected cast is invalid C for at least two reasons [12:01] _r3_: first, the code is type-punning, which is not allowed [12:01] _r3_: second, the code is casting without meeting the alignment requirements of the target type, which is not allowed either [12:02] Some arches (i.e. x86) are rather forgiving about this, but many are not [12:07] _r3_: the correct fix would be something like http://pastebin.ubuntu.com/628360/ [12:18] <_r3_> dmart: hmm.. i get it in correct byte order, since that is already converted in receive function.. but with wrong byte order instead of 192.168.11.66 i would get: 66.11.168.192 but not 192.168.11.6.. that '6' comes from 2 bytes after the i field [12:19] <_r3_> and well type-punning is needed since radius protocol is at it is .. i can't change that.. it is casting without meeting the alignment req. yes. is there an easy way to make the compiler understand that? [12:20] <_r3_> without doing the double cast i mean :) [12:25] ogra: If I was a member of the public wanted to host my own ARM PPA, what would I have to do? [12:26] ogra_: -^ [12:26] lag, talk to IS and convince them that only employees can upload [12:26] ogra_: So they can't host an ARM PPA? [12:26] or upload to a private arm ppa you only have access to and do a binary copy of the debs to a public one [12:27] I don't mean for me [12:27] I mean if I weren't an employee [12:27] well, we dont have public PPAs until the cluster is in place [12:27] I don't know what that means, what cluster? [12:27] which will happen soon, but due to the fact that we could only fit 10 boards in it instead of 20, ppas might still take a while [12:28] the panda build cluster [12:28] currently arm PPAs are non virtualized [12:28] So all ARM builds are completed on a Panda Board cluster currently? [12:28] which means you can do very bad stuff if you have upload permission [12:28] no, currently we have a bunch of babbage boards as build machines [12:29] they are supposed to be replaced by a pandaboard cluster [12:29] that cluster will have special tecnology to fake virtualization [12:29] Right, but members of the public can't build on them? [12:29] so we can make public PPAs available [12:30] until thats in place there wont be any public PPAs for arm [12:30] Okay, so what are the plans ETA? [12:31] the first cluster should be in place within the next 7-10 days, its physically in the datacenter but hasnt been set up [12:31] that one will likely only replace the existing build machines [12:31] So the bottom line is, non-employees will be able to host their own ARM PPAs in the upcoming weeks? [12:31] when the second cluster is ready (which will get us PPAs most likely) isnt predictable atm [12:32] Okay, I guess that answers my question [12:32] Thanks dude [12:32] i would say ETA for public PPAs is likely not happening before P [12:32] #probably earlier, but thats a matter of luck [12:32] Right, thanks [12:33] * ogra_ would love to have it this cycle but life goes slower than planned wrt build machines [12:36] _r3_: did you try my code from pastebin? By reading the adress from hisipattr without a type cast, the compiler shouldn't get confused [12:49] _r3_: ...though actually, your code is roughly equivalent. However, casting from one packed structure type to another shouldn't be necessary. If reading that field from struct radius_attr_t is giving wrong results, that suggests a compiler bug, but the compiler is not required to give sensible results if you cast a struct radius_attr_t * to in_addr_t * and deference the result [12:50] Well, the Natty image didn't want to boot either on the Panda A3 [12:50] And this page: http://www.omappedia.org/wiki/Get_started_with_ubuntu_on_omap4 [12:50] Appears to be out of date [12:50] lool: is there a common mailing list for Ubutntu arm developers? [12:50] dmart, ubuntu-devel@ [12:50] persia: thanks! [12:51] persia: was there previously a separate ubuntu-arm@, or am I mis-remembering? [12:51] There never was. [12:51] fair enough [12:51] Theoretically, everyone is supposed to care about all the architectures. [12:51] In practice, this isn't actually true, but nobody is going to complain about some architecture-specific threads. [12:52] For reasons totally unrelated to this IRC thread, I was thinking of suggesting that everyone gets mroe proactive about getting rid of alignment faults in userspace apps [12:52] On the other hand, it needs to stay relevant to Ubuntu: so "how to deal with porting issues" is interesting, as it helps us all solve FTBFS issues. "Here's a new device" is less interesting, unless someone is doing the work to have that device supported in Ubuntu. [12:52] jeremiah, yes, rather use ubuntu docs to install ubuntu ;) [12:52] heh [12:52] Well, that would make sense. :) [12:52] That's definitely applicable to ubuntu-devel@ : powerpc folk are just as prone to that sort of thing, so it's not even that arm-specific. [12:53] http://wiki.ubuntu.com/ARM/OMAP [12:53] try that :) [12:53] persia: ok, thanks [12:53] hrw: Is our toolchain available for on Debian? [12:53] though it might be that we're missing bits for A3 borads [12:53] lag, Debian uses a slightly different toolchain (although some of the same folk are contributing). [12:54] thanks ogra [12:54] hrw: persia: I mean the Linaro toolchain [12:54] I hope we're not missing any A3 bits - but we'll soon find out. =) [12:54] yeah [12:54] lag, So do I. [12:55] At UDS I saw a lot of Debian folks doing Linaro stuff. :) [12:55] persia: Okay, thanks [12:55] As "Ubuntu toolchain" and "Linaro toolchain" are essentially equivalent (if not, someone is slacking, or we're not all working on the same thing anymore) [12:55] Not as many as the Ubuntu folks, but still. [12:57] jeremiah, I think the lines begin to blur in that area: given that both Debian and Ubuntu are community projects, and share lots of code, I think many people involved in the area end up working with both projects. [13:06] persia: I certainly have a hard time telling where one project begins and the other ends. [13:06] I mean, those who are paid by Canonical one can assume they spend a good deal of their time on Ubuntu [13:07] But, as Mark Shuttleworth says, every Ubuntu developer is a Debian Developer. :) [13:07] Although that might not be literally true. [13:11] dmart: there was an ubuntu-mobile@ list but it's dead nowadays [13:11] and I don't think it ever cared of ARM [13:11] during the team transition phase probably [13:11] but the people on the list were fairly overlapping with people caring about ARM ;-) [13:11] It didn't. In it's latter days, it mostly consisted of apologies about lpia, and backporting efforts. [13:12] No. Lots of regulars on ubuntu-mobile@ left and did something different when it stopped being a focus, and more ARM stuff was happening. [13:13] jeremiah, I believe the quote was the other way: that every Debian Developer is an Ubuntu Developer. [13:13] I know of folk paid by Canonical who do all their work in Debian and none in Ubuntu. [13:15] The boundary isn't really about individuals, as many folk participate in both, or about code, as much code is shared, but rather about the goals and output. [13:15] persia: Ah, you may be right. :) [13:15] about the shuttleworth quote, for sure [13:16] Debian strives to generate a universal operating system. Ubuntu strives to present a (limited) selection of the results of applying opinionated defaults to generate specific user experiences. [13:18] But Ubuntu also wants one to assign copyright to ubuntu, which is sometimes controversial. [13:18] There's obviously overlap in those goals (and plenty of other goals which I've simplified away), but the answer in Debian is often "Let's enable users to do things how they wish, but sanely" and the answer in Ubuntu is often "Users should be doing things like this, so let's make sure that works very well." [13:18] No. Ubuntu has no interest in having copyright assigned. === stenzel_ is now known as stenzel [13:19] Canonical happens to provide some Ubuntu infrastructure, and also happens to sponsor some upstream projects that require copyright assignment, but that's not that relevant to Ubuntu. [13:19] There's a number of cases where Ubuntu has patched Canonical software, but refused the copyright assignment, so the software in Ubuntu differs from that Canonical provides. [13:19] Really? I didn't know that. Interesting. [13:20] So there certainly is a degree of independence [13:26] lag: there are no cross compilers in Debian archive. If you want them then Emdebian guys have repositories with cross compilers. [13:26] hrw: Can a Debian user use our binaries? [13:27] lag: Linaro gcc changes are part of Ubuntu gcc now. Debian uses same packaging as Ubuntu but iirc does not apply Linaro changes [13:27] they might pull in unwanted deps [13:27] lag: no warranty that they will install but may work [13:27] unimportant stuff like a different libc and such [13:27] hrw: Great [13:27] ogra: I'm sure they will live :) [13:28] i wouldnt be that sure when mixing debian and ubuntu [13:28] on a binary level at least [13:29] ogra_: both debian and ubuntu uses eglibc 2.13 now [13:29] hrw, which release ? :P [13:30] if someone run lenny they will surely not have a happy system after installing a natty toolchain (which pulls in the ubuntu libc) [13:31] Debian and Ubuntu are not guaranteed to be binary compatible. There isn't even any serious attempt made to be so, and most folk who push in that direction get strong push-back. [13:31] ogra_: testing [13:31] and most often just fall over at some point [13:31] ogra_: I do not have to support Debian so I limit my Debian work to sid [13:31] It's supposed to be *source* compatible (although that's slowly eroding for some categories, and several folk are working to get it back) [13:31] mixing debian and ubuntu on a binary level is asking for trouble [13:32] <_r3_> dmart: aaah now i got it. assign directly to s_addr! .. i will try it, thank you! [13:32] For ARM, it's raw madness: The ABIs are known to differ. [13:32] right [13:32] and there are the compiler defaults etc [13:33] That's part of why the ABI differs :) [13:33] well, beyond the obvious ABI difference between v5 and v7 :) [13:33] Does that force an ABI difference? [13:34] I thought that was just an ISA difference, but didn't actually affect exported symbols. [13:34] no idea if -as-needed is ABI specific for example [13:34] It's not. [13:34] or -no-shrink-warp [13:34] That's just a linker thing. [13:34] etc [13:35] i think we have a good bunch of non ABI related config diffs [13:35] Oh, heaps. [13:35] But the ABI differences are the reason it's not safe to mix binaries. [14:36] Hmm. I can't get the ubuntu-11.04-preinstalled-headless-armel+omap4.img.gz to boot past the kernl [14:36] kernel even [14:36] I'll try another version, like the netbook. [14:36] md5sum was correct anyway. [14:36] What sort of error are you getting? [14:37] I very much doubt that you'll get different behaviour from a different image in terms of intiial startup. [14:37] persia: It just says; "uncompressing kernel . . ." [14:37] No, I imagine its the same kernel for all of them most likely [14:37] how long did you wait ... [14:37] ogra_: Not particularly long this time. [14:37] It is, and the same bootloader, and the same set of code to launch the startup process. [14:38] it takes a while until oem-config has parsed the debconf db before it shows the UI [14:38] But I'll check again, because I onlyl closed minicom [14:38] ogra, Where "a while" is measured in minutes or tens of minutes? [14:38] minutes [14:39] Thought so: just wanted to set some bounds :) [14:39] I've just rebooted [14:39] It stops here: Uncompressing Linux... done, booting the kernel. [14:39] right, give it a moment [14:39] okay :) [14:39] debconf produces a lot of I/O [14:40] Sd cards arent really great for that [14:40] What makes me nervous is that one of the leds has stopped and the other has goine into a steady blinking state [14:40] Yeah :/ [14:40] which one blinks ? [14:40] jeremiah: I think that's expected (or at least my panda usually only has one blinking light) [14:41] the left one is heartbeat, it means the board is alive [14:41] ah, okay [14:41] the right one (closer to the SD) is disk access [14:41] if thats solid there is a lot IO [14:41] D1 was blinking (that is on my left) but has now stopped. [14:42] Now both have gone out. [14:42] hrm [14:42] <_r3_> dmart: yeah, that's working, thank you! .. however.. i have to change every cast, that's always necessary i guess, is it? i was searching for some neat compiler-flag or something easy which solves this, hehe .. but ok, probably the game really isn't played that way :) [14:47] Yeah. Definitely stuck, kernel won't boot. [14:47] I wonder if there are complications from the new u-boot? [14:48] I notice that on OMAPedia it talks about compiling u-boot with omap4430sdp_config [14:49] But it looks like the config has changed to omap_panda_config [14:49] But that is for u-boot, and it looks like we've gotten past the bootload by the time the "booting the kernel" message comes up [14:50] omappedia has a lot outdated info [14:50] Yeah, you're right. [14:50] It does seem quite out of date [14:51] Sheesh. That page was last edited about six months ago. [14:52] Well, I'm compiling linaro-gcc here to see if I can't compile a kernel here. [14:54] why are you compiling gcc ? [14:54] dont you like the binary packages ? :) [15:23] jeremiah, i just talked to TI, seems for the A3 panda we will need some patches to x-loader to make it work [15:38] ppisati: i haven't booted ubuntu on pandaboard in atleast 3 months, much less compile with gcc-4.6, why do you ask? [15:39] prpplague^2: becasue someone said you had usb devices in a ubuntu kernel compiled witg gcc 4.6 [15:39] prpplague^2: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/791552 [15:39] Ubuntu bug 791552 in linux "No USB support on beagle/beagleXM" [High,New] [15:42] ppisati: i am guessing that is reference to this - https://lists.yoctoproject.org/pipermail/poky/2011-June/006649.html [15:43] ppisati: i normally don;t any testing of ubuntu kernel/rootfs [15:43] prpplague^2: yes, tried that and it didn't work and since someone said you had it working [15:44] prpplague^2: i was asking [15:44] ppisati: ahh, well i didn't try anything with an ubuntu kernel, or with gcc 4.6 [15:44] ppisati: np [15:44] prpplague^2: ok [15:44] ppisati: the problem also affects some performance issues on the EHCI [15:45] ogra: uh what changes are they refering to ? [15:45] ogra_: Ah okay. [15:46] prpplague^2, no idea, i need to ask sebjan [15:47] ogra: there shouldn't be any changes to x-loader to support A3 boards [15:48] ogra: i'll check on that when i get to the office [15:48] prpplague^2, well, i was just told there are patches [15:48] ogra_: hmm, sounds odd to me. i validated A3 boards with mainline x-loader and u-boot [15:48] ogra_: i'll give you a ping when i get to the office [15:49] * prpplague^2 heads to the door [15:49] k [15:56] lilstevie, hehe [15:56] * ogra_ just saw the mail [15:56] ogra_: :) [18:54] Hm, a question about kernel packaging, again. [18:54] I have that 2.6.38-10 kernel I have compiled [18:54] but kernel-headers-..-omap.deb required kernel-headers.deb [18:54] how to generate it? [18:58] hrw: Good to see you. A question, if I may... [18:59] I have that 2.6.38-10 kernel I have compiled. There is linux-headers-2.6.38-10-omap_2.6.38-10.44_armel.deb package, but it depends on linux-headers-2.6.38-10 package. How to generate it? [19:01] ... [19:22] Ok, nwm, I managed to make it... === phh_ is now known as phh [20:15] garagoth: I think you need to build binary-indep [20:16] or binary-headers [20:23]