| zumbi | persia: someone wanted to do some omap4 cleanup on d-i | 00:00 |
|---|---|---|
| persia | I think I mean "mx5". I've heard folk say that the same code supports the i.MX51 and the i.MX53, and that someone was calling that mx5 while adding support in Debian. | 00:00 |
| zumbi | debian is likely enabling omap subarch | 00:00 |
| zumbi | persia: yes, that someone was me | 00:01 |
| persia | Will Debian "omap" support omap3 and omap4? | 00:01 |
| zumbi | mx51 and mx53 are not yet compatible | 00:01 |
| persia | Heh. Then you know what string I need more than I :) | 00:01 |
| zumbi | yes, omap in debian will be for omap3 and omap4 | 00:02 |
| persia | They aren't? I thought linaro had a kernel that worked on both. | 00:02 |
| zumbi | persia: is not about what I need, I am trying not to break your stuff | 00:02 |
| persia | If "omap" in Debian is for both omap3 and omap4, then it makes sense for Ubuntu to carry "omap4" is a patch, for as long as it continues to be required. | 00:02 |
| zumbi | as someone submitted a patch which removed omap4 from libdebian-installer | 00:02 |
| persia | As long as we know about it, it oughtn't be a disaster. | 00:03 |
| zumbi | persia: ok - but there are old trees with omap4 and documentation all over teh place | 00:03 |
| persia | NCommander, Are you about? Would you have time to review this with zumbi to figure out what makes sense as an Ubuntu patch? | 00:04 |
| zumbi | persia: this was the thread triggering this question.. http://lists.debian.org/debian-boot/2011/06/msg00184.html | 00:04 |
| persia | Ah, and now it all makes sense. | 00:06 |
| persia | Yeah, it's probably better to leave "omap4" and "imx51" in the reserved list for now, as this makes the Ubuntu patching easier (reassinging some boards,etc.). | 00:06 |
| zumbi | yes, that was what I thought | 00:07 |
| zumbi | we'll see how we end up with mx51 and mx53 | 00:07 |
| persia | What's outstanding there? A merged kernel, or something larger? | 00:09 |
| zumbi | persia: is it just an offset issue | 00:11 |
| zumbi | at boot time | 00:11 |
| persia | Hrm. That confuses me. I've been told that folks with both Efika smartbooks (mx51) and Quickstarts (mx53) are booting with the linaro kernel. | 00:13 |
| persia | I thought that was the same kernel. | 00:13 |
| zumbi | http://lists.debian.org/debian-arm/2011/04/msg00067.html | 00:14 |
| persia | apachelogger, What's your `uname -a` output? | 00:14 |
| zumbi | persia: well, maybe it has been fixed | 00:15 |
| zumbi | that issue was raised back in april | 00:15 |
| zumbi | I have not tested mx53 stuff yet | 00:15 |
| persia | Uwe also seems to be talking about mainline, and I suspect Linaro's Freescale Landing Team has a number of patches in the pipeline. | 00:16 |
| zumbi | persia: yes, Uwe is mainline.. but certainly if that is in Linaro eventually it'll get into mainline | 00:18 |
| persia | Sometimes the patches need a fair bit of rewriting :) | 00:19 |
| zumbi | if it is not there yet... I need to update myself | 00:19 |
| persia | (but yeah, it's heaps better than the old abandoned vendor trees) | 00:19 |
| zumbi | well, there is not much involved into have mx53 and mx51 in one kernel | 00:19 |
| zumbi | we really hoping for unified kernel | 00:20 |
| persia | I think there is one. Unfortunately, jcrigby, who'd know for sure, seems to be away from IRC this week. | 00:21 |
| persia | Unfortunately, my git-fu isn't up to finding shortlog difference between trees sufficiently to distinguish which patches may have been applied to achieve this. | 00:22 |
| zumbi | well, that's upstream call I suspect | 00:26 |
| persia | Heh, well. Depends on your feeling towards distro-patches :) I suspect that for Ubuntu we'll be telling base-installer to use the linaro kernels (since they regularly get uploaded into the archive). I'm not convinced Debian wants N kernel source packages, which makes it much harder to do without upstream support. | 00:28 |
| zumbi | persia: debian kernel team sticks to upstream/mainline | 00:35 |
| persia | Sensibly :) | 00:35 |
| zumbi | and they have a policy of only backporting patches which have been accepted into mainline HEAD | 00:35 |
| persia | Ubuntu kernel team does the same (mostly), but there are something like 6 kernel source packages in Ubuntu, of which only one is managed by that team. | 00:35 |
| zumbi | unless it is a bugfix | 00:35 |
| persia | For Ubuntu, even bugfixes get asked if they are upstream (although I suspect some that aren't yet get applied) | 00:36 |
| zumbi | well, it becomes insane if you do it other way, you need an upstream to distribute | 00:36 |
| zumbi | Debian distributes GNU | 00:36 |
| zumbi | free and open stuff | 00:36 |
| zumbi | Ubuntu is more into commercial world, I want it to work even if it is not open/free | 00:37 |
| zumbi | I mean Ubuntu besides being driven by business, it also does not comply to Debian free and open source guidelines... | 00:39 |
| persia | It's not about free/non-free and it's not about money. | 00:39 |
| zumbi | in a sense Debian is freedom taliban | 00:39 |
| zumbi | persia: I was not trying to be annoying that was just my point of view | 00:39 |
| persia | All the extra kernels in the archive are GPLv2-only, and some of them are uploaded by people I know not to be receiving any compensation for doing so. | 00:39 |
| persia | I agree that having a single upstream is *lots* easier to manage, and generally cleaner. | 00:40 |
| zumbi | well, you really do not want to carry 6 different kernels for x86 | 00:41 |
| zumbi | then dealing with bug reports is insane | 00:41 |
| persia | They have 6 different source packages. | 00:41 |
| persia | (but I think we only have 2 source packages for x86) | 00:41 |
| persia | And different binary package names | 00:41 |
| zumbi | when talking about free/non-free, I was thinking on ti-sgx 3D drivers, nvidia stuff, etc... | 00:42 |
| persia | I don't believe any of that is in Ubuntu. | 00:42 |
| zumbi | and surely there is community around Ubuntu | 00:42 |
| persia | TI has a PPA in which they distribute some stuff. | 00:42 |
| persia | I don't think nVidia has one. | 00:42 |
| zumbi | uhm.. I might be wrong | 00:43 |
| zumbi | persia: but then why fork Debian and not work with it? | 00:44 |
| persia | I wasn't involved in that decision. | 00:45 |
| persia | At the time, I was following Debian mailing lists, and had the impression that there was a desire to do ~1000 NMUs, which were considered to be unfreindly at the time. | 00:45 |
| persia | I believe the fork comes from the desire to be able to upload things *without* considering whether it's NMU, and the desire to release every six months (Ubuntu was announced around the time that sarge was looking like it would never release) | 00:47 |
| persia | I think many Ubuntu Developers, especially most of those who have been around a while, do also work in Debian in one way or another. | 00:47 |
| persia | I'm not sure it's fair to say "and not work with it" | 00:48 |
| zumbi | persia: yes, that's for sure | 00:48 |
| zumbi | persia: well in a way we use debian tweaked for our needs at work | 00:48 |
| persia | Now, since 2005 NMUs in Debian have transitioned from being an injury to being a help to other maintainres, there's lots more team maintainership, the DAM lock that nobody understood is gone, etc. | 00:49 |
| zumbi | we got some extra packages in internal repo | 00:49 |
| persia | So lots of the initial rationales for Ubuntu would probably be considered differently if considered today. | 00:49 |
| persia | But at this point, deciding to not have Ubuntu gets messy and complicated: too many people have too much invested in continued existence. | 00:50 |
| persia | As some of the first changes in Ubuntu were toolchain patches, which required rebuilding all the rdepends, I don't think "extra packages in a third-party repo" would ever have worked. | 00:51 |
| persia | Ubuntu continues to be a testing ground for new toolchains in Debian, which I think benefits Debian in terms of patches available for FTBFS at least as much as it benefits Ubuntu in terms of tighter optimisations. | 00:52 |
| zumbi | persia: I agree | 00:53 |
| zumbi | surely one is testbed of the other | 00:53 |
| persia | Mind you, there's been *lots* of argument about this, from lots of directions in the past. There have been some periods where cooperation was weak. | 00:53 |
| zumbi | yes, lots of flames | 00:54 |
| micahg | some of the toolchain diffs (hardening defaults) were brought up at UDS in the Debian health check session | 00:54 |
| persia | But I very much hope that more teams follow the example of the Mono/CLI team, where a common set of folk have upload rights to both distributions, tend to do most of their stuff in Debian (except where variation is required to comply with other variation), and everyone stays (mostly) happy. | 00:54 |
| zumbi | persia: some DD are annoyed to not be able to upload to ubuntu | 00:55 |
| zumbi | and find some packages are not in sync | 00:55 |
| persia | zumbi, Sure, but some DD *can* upload to Ubuntu. There's more than a few that have requested (and been granted) upload rights for the stuff they maintain. | 00:55 |
| zumbi | DEX is great opportunity to improve cooperation | 00:56 |
| zumbi | persia: I did not know about that.. in any case I am not against any | 00:56 |
| persia | Those DDs who are annoyed to not be able to upload should demonstrate they are watching LP bugs, and apply to get upload. | 00:56 |
| persia | On the other hand, some DD complain and say that Ubuntu should sync their latest upload all the time: in several cases this has broken chunks of the archive that go beyond that specific package late in the release cycle. | 00:57 |
| persia | This is especially common when Debian is just coming out of freeze while Ubuntu is entering freeze. | 00:57 |
| persia | And some DDs don't bother to test whether their new uploads even build under Ubuntu (but still insist on sync) | 00:58 |
| zumbi | yes, slightly similar, but not same | 00:58 |
| persia | Luckily, those are the extreme minority, but it's fear of that sort that leads to the process of requiring folk to apply and demonstrate they do care about Ubuntu (which has been described as overly bureaucratic by some) | 00:59 |
| zumbi | I think there is material to write a book | 00:59 |
| persia | Several :) | 00:59 |
| zumbi | well, I think the base system is well built but either debian and ubuntu developers | 01:00 |
| zumbi | I have lots of friends that are working or have worked for canonical | 01:00 |
| persia | There's lots of Ubuntu Developers that don't work for Canonical as well (although, to be honest, we've not been as good at recuiting new developers lately, and Canonical has hired a lot of folk, so I'm not sure whether Canonical employs a majority currently) | 01:06 |
| zumbi | It is quite amazing how all that is structured | 01:09 |
| zumbi | it is hard to understand properly :) | 01:09 |
| zumbi | I am not sure I got contributions to ubuntu, but at least if I fix something in debian I ping the packages in ubuntu, so they can check | 01:09 |
| zumbi | and I have even signed the ubuntu code of conduct | 01:10 |
| persia | What's your LP account? | 01:10 |
| zumbi | but not sure how can i help ubuntu, I try to keep debian alive at least on embedded arches which have been in my interest since the beginning | 01:10 |
| zumbi | persia: my nickname | 01:11 |
| persia | You've not been granted specific credit for any patches in Ubuntu (although I know you've been helping folk for a long time). | 01:12 |
| zumbi | I do not maintain much packages in debian, but fixed tslib driver for X.org in debian and pinged the bugreport in ubuntu | 01:12 |
| zumbi | well, not helping, really is cooperation | 01:13 |
| persia | Sure: I tend to think of cooperation as "folk helping each other" :) | 01:13 |
| persia | If your patches are getting applied in Debian smoothly, and flowing to Ubuntu well enough that you're comfortable, I'd say you have nothing to worry about. | 01:14 |
| persia | If you want to deploy patches that aren't being accepted, or there are issues with getting stuff into Ubuntu that you want to fix, then it may make sense to prepare debdiffs for bugfixes and send them to Ubuntu bugs for application. | 01:15 |
| persia | But it all depends on your personal motivations, and whether you have any desire to identify as an "Ubuntu Developer". | 01:16 |
| zumbi | I see | 01:16 |
| zumbi | well, I don't care.. I would like to close LP#1 :) | 01:16 |
| zumbi | I think that was that one bug Mark wrote time ago | 01:17 |
| persia | That's getting very close to closed, unfortunately not from our work (iOS, Android) | 01:17 |
| zumbi | sadly, yes | 01:18 |
| zumbi | but still .. they are around | 01:19 |
| persia | Oh, indeed. And lots of the Android work ends up being directly useful to us. | 01:19 |
| zumbi | later moves with Nokia were not good | 01:19 |
| zumbi | I am still waiting for the ubuntu-phone | 01:20 |
| persia | I keep hearing good things from Nokia, although for stuff that isn't phones. I'm not yet ready to have an opinion. | 01:20 |
| persia | I believe Kubuntu Mobile has a working dialer and some baseband support. | 01:20 |
| zumbi | persia: no, you need to ship actual devices, not expect people to fit that into a mobile | 01:21 |
| zumbi | pre-installed ubuntu phones | 01:21 |
| persia | Yeah, well. All we can do is build it, and hope they come. | 01:22 |
| zumbi | well, you need to contact manufacturers | 01:22 |
| persia | Sure, some of us, as individuals, can go talk to ODMs, etc., but at that point I'm not sure that it's still part of the wider "we". | 01:22 |
| persia | I'm not convinced that it's yet possible to deliver a product with turnkey free software. | 01:23 |
| zumbi | HTC has recently open the bootloader | 01:23 |
| zumbi | to make their devices more hackable | 01:23 |
| persia | If we can reach that point, where it just works, and can usefully be installed on nearly any phone, then it becomes a relatively safe option for someone to release a phone based on that stack (rather than requiring in-house development effort) | 01:23 |
| zumbi | not open as in source, but open as in access | 01:23 |
| persia | Given the number of tablets and handhelds released with Ubuntu Jaunty when the ARM port first became available, I would expect several devices to appear shortly after it was known to work. | 01:24 |
| zumbi | we build a lightwriter for disabled people, not only helps them to speak up but it also works as a phone | 01:24 |
| persia | (mind you, most of this was not available outside the Chinese market, but that's the hot location for early adoption in consumer electronics: everywhere else folk are very conservative) | 01:25 |
| zumbi | yes, the Chinese just go for it.. | 01:26 |
| zumbi | I know Anthony Fok and Paul Liu | 01:26 |
| zumbi | great developers | 01:27 |
| persia | Right. There's lots of cool stuff to do. I believe that we (being developers) need to focus on making sure that our software stack works, is easily adapted to a wide variety of hardware, and is widely available at no cost (free code is something we care about. free beer is something the manufacturers care about) | 01:27 |
| persia | Whereas we (being the free software community) need to encourage or develop entrepreneurs who will take these things to retail devices. | 01:28 |
| zumbi | Yes, I have thought many times to develop some hardware and use free software to develop retail devices | 01:29 |
| zumbi | but all of it is complex | 01:29 |
| persia | It's no more complex than software :) It's just different. There are very few folk who can do both. | 01:29 |
| zumbi | getting parts sorted | 01:30 |
| zumbi | MOQs | 01:30 |
| persia | Oh yeah. | 01:31 |
| persia | Anyway, getting late in the morning for me, and I must run. Have a good evening. | 01:31 |
| zumbi | hardware is .. don't know how to describe.. hardware to be ready for production is just tough | 01:31 |
| === Lopi|idle is now known as Lopi | ||
| zumbi | persia: sure.. bye | 01:31 |
| zumbi | persia: just one more thing, linux is the testbed of new processors which tomorrow (years away) will be part of products, besides mobile world which it changes so fast | 01:32 |
| persia | I wish it was that simple. | 01:33 |
| persia | Lots of the things that get tested (much of which goes mainline) ends up being PoC to drive design wins, which end up with derivations for production deployment. | 01:33 |
| persia | Even with many of the SoC vendors collaborating within Linaro to help make BSPs be mostly upstream(able) code, I suspect there remain cultural barriers to having vendor devices mainline enabled. | 01:34 |
| persia | (with the exception of a few bright spots, where vendors are very cooperative) | 01:35 |
| persia | In many ways, I welcome Windows 8 to the game: it helps the conversations about having hardware be a base platform on which arbitrary software is delivered. | 01:36 |
| zumbi | yes, it'll bring all the fun on how broken it is | 01:36 |
| persia | At least with more things reaching mainline these days, the SoC vendors haven't dropped support for recent kernels before the devices ever reach retail. | 01:36 |
| zumbi | omap is keeping up with community very well | 01:37 |
| persia | I don't care about the actual operation of Windows 8: the reasons I am unlikely to use it have nothing to do with what it does or who makes it. | 01:37 |
| persia | I care more about how the presence of multiple operating system choices for a given platform provide incentives for board manufacturers to have known working generic solutions. | 01:38 |
| persia | TI does good. I like TI. I'm not happy with how bootstrapping works: it still requires omap-specific code. | 01:38 |
| zumbi | it is already happening due to android, linux duality | 01:38 |
| persia | From what I understand, this is a ROM issue with ROM inside the SoC, which can't be fixed until OMAP6 or OMAP7. | 01:38 |
| persia | Android and Linux are almost identical code (ignoring userspace). | 01:39 |
| persia | As a result, the *same* set of enablement patches is likely to work for both. | 01:39 |
| zumbi | yes, omap has a ROM which calls x-loader, u-boot, etc... | 01:39 |
| persia | The nice thing about Windows 8 is that the Android/Linux patches *will not apply*, which means thinking about generics at a design level. | 01:40 |
| persia | Anyway, I'm getting very late :) It's always fun chatting with you, but ... | 01:40 |
| zumbi | omap ROM code loads x-winloader which loads winkernel | 01:40 |
| zumbi | persia: sure, later .. :) | 01:40 |
| === asac_ is now known as asac | ||
| ogra_ | zumbi, to answer yesterdays question, imx51 was just removed in ubuntu in favor of mx5, omap4 is one of our supported arches so needs to stay | 09:47 |
| ogra_ | IMAGES !!!! | 09:48 |
| ogra_ | http://cdimage.ubuntu.com/daily-preinstalled/20110616/ | 09:49 |
| ogra_ | yipiee | 09:49 |
| ogra_ | hmm, nearly 1G | 09:49 |
| zumbi | ogra_: what's the difference between omap and omap4? | 10:04 |
| zumbi | in the cdimage build | 10:05 |
| ogra_ | omap4 has a special kernel package | 10:05 |
| ogra_ | and special boot options | 10:05 |
| ogra_ | for omap4 we also provide additional packages that make it easy to enable the TI | 10:05 |
| ogra_ | PPA | 10:05 |
| ogra_ | which holds the sgx drivers and HD video codecs etc | 10:06 |
| zumbi | I see.. thanks | 10:06 |
| ogra_ | the prob is, while you can have a jiont kernel packqage for all omap arches, you still need a separate binary bootloaders and cmdline options atm | 10:07 |
| ogra_ | -s | 10:07 |
| zumbi | ogra_: part of that can probably be solved with boot scripts | 10:08 |
| ogra_ | not really | 10:08 |
| ogra_ | TI initializes half the HW in their bootloaders instead of the kernel ... | 10:09 |
| ogra_ | if you would have x-loader and u-boot binaries that support all omap arches and only switch through boot scripts, you would end up with huge binaries | 10:10 |
| ogra_ | and i even doubt a multiarch x-loader would be possible at all | 10:10 |
| ogra_ | i fear until UEFI gets default for ARM we will have to live with SoC specific bootloader binaries here | 10:13 |
| zumbi | yes, x-loader upstream maintainer was a bit sick of all that | 10:13 |
| zumbi | Why doesn't TI just boot directly into kernel and this one is responsible to do everything | 10:14 |
| ogra_ | no idea | 10:14 |
| zumbi | don't really need u-boot, unless you rely on it to initialize everything | 10:15 |
| ogra_ | for the build cluster we tried to use a raw kernel boot ... and initially ended up with no MMC and no USB | 10:15 |
| ogra_ | getting that initialized needed a good bunch of first stage bootloader hacking | 10:15 |
| ogra_ | sadly you need x-loader, there is not enough memory to carry u-boot | 10:16 |
| ogra_ | so x-loader needs to init the ram first | 10:16 |
| zumbi | now, everything starts to make sense | 10:17 |
| ogra_ | sadly it grew more heads over the years it seems | 10:17 |
| ogra_ | as well as u-boot did | 10:17 |
| GrueMaster | The processor only has 64K memory on boot, that's why x-loader is the way it is. It initializes ram (and a bunch of other crap), then u-boot can load and do more. | 10:18 |
| ogra_ | so even if you wanted to do something like booting a raw minimal kernel and then kexec into something full, you would still need x-loader and u-boot | 10:18 |
| GrueMaster | Well, x-loader at least. | 10:18 |
| ogra_ | which makes kexec moot since it just adds boot time for no benefit | 10:18 |
| GrueMaster | You can boot a kernel from xloader. | 10:18 |
| ogra_ | well, you should be able to dd a binary header in front of uImage that replaces x-loader | 10:19 |
| janimo | ogra, would an xloader/uboot that supports OMAP3 and 4 be that huge? Even if it were double the current size - which it probably would not be - it's not an issue | 10:19 |
| ogra_ | at least with newer omaps | 10:19 |
| GrueMaster | Can't. not enough memory to load both. | 10:20 |
| ogra_ | janimo, for x-loader it is ... as GrueMaster said above, 64k is your limit | 10:20 |
| janimo | not having both binaries but one that handles both. Is the extra code/data so much different it would increase the size beyond what it fits? | 10:21 |
| ogra_ | for u-boot it might be possible to be a big multisoc binary | 10:21 |
| ogra_ | but surely for the cost of bootspeed | 10:21 |
| zumbi | is it true that TI had problems with memory controllers as those did not match, so omap was unable to use memory (as LPDDR) | 10:23 |
| ogra_ | on XM, yes | 10:23 |
| ogra_ | (beagle XM omap3) | 10:23 |
| zumbi | yes, I heard on 3530 early revs | 10:23 |
| zumbi | all this is just insane.. :) | 10:23 |
| hrw | XM used 36/37 iirc from start - or not? | 10:24 |
| hrw | 34/35 was on normal beagleboard | 10:24 |
| ogra_ | the wonderful world of ARM :) | 10:24 |
| hrw | I hope for cheap ARM board with 2MB of flash on board | 10:24 |
| hrw | so there will be space for bootloader so boot from usb/sd/sata/network will be easy | 10:25 |
| ogra_ | i think you will see flash on board less and less | 10:25 |
| ogra_ | eMMC costs only half of i t | 10:25 |
| hrw | ogra_: flash/emmc/esomething/whatever | 10:25 |
| hrw | a way to just connect power and get board booted | 10:26 |
| zumbi | hrw: sounds about right, xM using DM3730 | 10:26 |
| hrw | ogra_: if you want to use sdio on panda you have to solder second sdmmc or use other computer to send bootloader over usbdevice | 10:27 |
| zumbi | there is "Automotive eMMC" much more reliable/tested than current eMMC | 10:27 |
| hrw | I miss real developer boards | 10:27 |
| zumbi | I need to play with TI Wilink module, I hope it performs as expected | 10:29 |
| ogra_ | oh, there goes tomboy | 11:17 |
| garagoth | Good morning | 11:17 |
| garagoth | A little question, if I may. I cross compiled kernel for Beagle (that is, for arm). In parent directory (relative to kernel sources) I have now 5 .dev biles and a lot of .udeb files. What are .udeb files? Is it sufficient if I install linux-image-2.6.38-10-omap_2.6.38-10.44_armel.deb and linux-libc-dev_2.6.38-10.44_armel.deb? What are -versatile packages? (ok. Maybe not a little question, but I am tired as hell...) | 11:22 |
| ogra_ | udeb files are packages used by debian-installer | 11:23 |
| persia | udebs (micro-debs, but created with an assuption of weak unicode support) are only for the installer. | 11:23 |
| ogra_ | you dont need them if you dont build an installer image based on d-i | 11:23 |
| garagoth | Ok, good. | 11:23 |
| garagoth | So only *.deb are of my interest then.. | 11:23 |
| ogra_ | you should really make your build command more explicit | 11:24 |
| ogra_ | -versatile is another arm subarch | 11:24 |
| garagoth | I just followed manual pointed by rsalveti ;-) | 11:24 |
| garagoth | It was not very... um, explanatory. | 11:24 |
| persia | That doesn't have instructions for only building some flavours of the kernel? | 11:24 |
| ogra_ | fakeroot debian/rules binary-debs should just build the linux-image and headers packages | 11:25 |
| garagoth | http://www.omappedia.org/wiki/Ubuntu_kernel_build_alternatives | 11:25 |
| ogra_ | sigh | 11:25 |
| persia | ogra, That still builds all the flavours though | 11:25 |
| ogra_ | why didnt you use any ubuntu documentation instead ? | 11:25 |
| garagoth | in manual there is binary-arch | 11:25 |
| garagoth | not binary-debs | 11:25 |
| ogra_ | persia, oh, right, its the main ubuntu soucretree | 11:25 |
| * ogra_ forgot | 11:26 | |
| garagoth | ogra_: I used what rsalveti told me... | 11:26 |
| persia | garagoth, You did the right thing. We're unhappy with the docs, not with your execution. | 11:26 |
| ogra_ | well, there are about three very detailed wikipages on the ubuntu wiki | 11:26 |
| persia | garagoth, You did more than you needed, because the docs suck. | 11:26 |
| persia | Just use the "omap" kernel .deb on your beagle. | 11:26 |
| garagoth | Ok. Many thanks. | 11:26 |
| persia | ogra, I thought the omappedia page was based on one of them | 11:27 |
| * persia is looking | 11:27 | |
| garagoth | ogra_: If you would be so king and provide a link to better tutorial... | 11:27 |
| ogra_ | persia, well, as the omappedia pages are all based on something ... the prob is there was a snapshot taken but the updates dont move over | 11:27 |
| persia | ogra, https://wiki.ubuntu.com/Kernel/Action/BuildKernelPackage doesn't help much :( The wiki hates me. | 11:28 |
| persia | I agree that it's better to use the w.u.c source, but we have to know a good one, and I fear the messiness of w.u.c is biting us here. | 11:28 |
| garagoth | persia: heh, this is even shorter then omappedia... | 11:28 |
| persia | garagoth, Sure, but it skips a lot, doesn't explain how to cross compile, and still results in what you got. | 11:29 |
| garagoth | :-) | 11:29 |
| ogra_ | https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel is one | 11:30 |
| persia | https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel is a bit nicer, but I thought there was a cross-compile one. | 11:30 |
| ogra_ | there is amitk's blog | 11:30 |
| ogra_ | but thats not up to date, i think hrw had a more up to date one | 11:30 |
| amitk | ogra_: yes, go to hrw's blog post | 11:31 |
| persia | No, there's a wiki page about it. | 11:31 |
| persia | If that's not up-to-date, then we fail at docs. | 11:31 |
| hrw | http://marcin.juszkiewicz.com.pl/2010/10/19/how-to-cross-compile-arm-kernel-under-ubuntu-10-10/ one? | 11:32 |
| * ogra_ likes https://wiki.ubuntu.com/SergeHallyn_ppakernels | 11:32 | |
| ogra_ | short and simple | 11:32 |
| persia | Doesn't cover the use case though. | 11:32 |
| ogra_ | no | 11:32 |
| ogra_ | covers mine though :) | 11:33 |
| hrw | https://wiki.linaro.org/Resources/HowTo/PackageYourOwnKernel is more complicated | 11:33 |
| persia | Only because you're refusing to participate in Ubuntu these days. | 11:33 |
| ogra_ | who uses cross compilers anyway :P | 11:33 |
| garagoth | ... me? | 11:33 |
| ogra_ | persia, huh ? | 11:33 |
| ppisati | me | 11:33 |
| ppisati | :) | 11:33 |
| persia | ogra, Pushing kernels to PPAs when they ought be in the archive. | 11:33 |
| ogra_ | pfft, *REAL MEN* compile natively :) | 11:33 |
| ppisati | no way | 11:34 |
| ppisati | two hours to get a kernel | 11:34 |
| ogra_ | persia, it cant be in the archive yet ... | 11:34 |
| ppisati | i would prefer to pull myself a tooth | 11:34 |
| garagoth | I cross-compiled this kernel for few hours. I took looots of disk space. | 11:34 |
| garagoth | No way I would do this natively... | 11:34 |
| persia | ogra, Why not? | 11:34 |
| hrw | garagoth: define looots | 11:34 |
| ogra_ | ppisati, i just always have a tree around where i only remobuild changes | 11:34 |
| ogra_ | *rebuild | 11:34 |
| ogra_ | only if i know they work i roll a package | 11:35 |
| ogra_ | persia, because i cant upload to natty :P | 11:35 |
| ogra_ | (and even if i could i wouldnt gain any benefit from that) | 11:35 |
| persia | The rest of us are working on oneiric these days :p | 11:35 |
| garagoth | hrw: looots == 7.9 GB | 11:35 |
| hrw | ogra_: add kernel to oneiric and provide it also in ppa? | 11:35 |
| * persia stops teasing ogra | 11:35 | |
| hrw | garagoth: 8GB for kernel tree? | 11:35 |
| * ppisati tries to figure out what's the plan for oneiric/ti-omap4 | 11:36 | |
| ogra_ | hrw, if you donate me 24h every day :P | 11:36 |
| garagoth | this is what I have in kernel dir when cross-compile finished | 11:36 |
| hrw | garagoth: huge | 11:36 |
| garagoth | inclugind generated packages | 11:36 |
| ogra_ | garagoth, you did it wrongly | 11:36 |
| hrw | garagoth: good that my panda has still 153GB free on /home | 11:36 |
| hrw | ops. 135GB | 11:36 |
| ogra_ | you only wanted an omap3 beagle deb, but built *everything* | 11:36 |
| garagoth | hrw: USB HDD ? | 11:36 |
| persia | ogra, Yeah, but that's our fault: the documentation sucks. | 11:37 |
| hrw | garagoth: yes - 320GB sata | 11:37 |
| garagoth | ogra_: Now I know. I blame documentation :D | 11:37 |
| ppisati | actually to cross compile i do: | 11:37 |
| ppisati | export $(dpkg-architecture -aarmel); export CROSS_COMPILE=arm-linux-gnueabi- | 11:37 |
| garagoth | hrw: How you connected SATA to Panda? | 11:37 |
| ppisati | fakeroot debian/rules clean; fakeroot debian/rules binary-$flavour | 11:37 |
| ogra_ | garagoth, ogra@isis:~/kernel/linux-ac100-2.6.37$ du -hcs | 11:37 |
| ogra_ | 501M. | 11:37 |
| ogra_ | oh, wait, thats unbuilt | 11:38 |
| garagoth | :D | 11:38 |
| ppisati | [flag@newluxor ubuntu-natty]$ du -sk . | 11:38 |
| ppisati | 3937700 . | 11:38 |
| ogra_ | :P | 11:38 |
| ppisati | 3.8G | 11:38 |
| ogra_ | still to much if you only build the linux-image and -headers debs | 11:39 |
| ppisati | binary-omap -> omap3 | 11:39 |
| ppisati | fakeroot debian/rules binary-omap | 11:39 |
| ppisati | natty/master | 11:39 |
| ppisati | if you have any recepie to cut it, i'm all ears :) | 11:39 |
| ogra_ | doesnt that roll udebs and -docs and the like (and ddebs) | 11:39 |
| ppisati | when i'm doing bisect/bug finding i use linus vanilla | 11:39 |
| ppisati | copy .config from some ubuntu kernel | 11:40 |
| ppisati | and then make uimage | 11:40 |
| ppisati | it works and it takes much less time and space | 11:40 |
| ppisati | nope | 11:40 |
| ogra_ | yeah | 11:40 |
| ppisati | onlye kernel and header | 11:40 |
| ogra_ | thats how i do it for the ac100 too | 11:40 |
| persia | Oh my. The page on the wiki got removed as part of Kernel Wiki Gardening, and replaced with a link to amitk's old blog post. | 11:40 |
| ogra_ | only for a release i actually roll a test package | 11:40 |
| ppisati | btw, one day i want to find out what are the minimun required configs to make a vanilla kernel boot an ubuntu userland | 11:41 |
| hrw | garagoth: usb->sata enclosure? | 11:41 |
| persia | garagoth, Sorry. For now, the omappedia page is the best one, but if you look at the Ubuntu pages, you can find ways to build fewer kernels to achieve your goals. | 11:41 |
| garagoth | persia: Linking to someones blog from wiki for official instructions... well, looks unprofessional :-) | 11:41 |
| persia | Especially when the author of the blog post recommends a different resource (see backscroll). | 11:41 |
| garagoth | hrw: Mm. And what transfer rates you have? I wanted to replace my home server with a panda/beagle cluster | 11:42 |
| persia | In general, we don't do much with cross-compiling (except hrw). | 11:42 |
| hrw | garagoth: poor - 20MB/s max | 11:42 |
| persia | hrw, You should take over some area of the wiki, and build the comprehensive cross-compilation resource, and make all the other wikis (e.g. omappedia) point there. | 11:42 |
| hrw | persia: sounds like a plan | 11:43 |
| persia | \o/ Real Documentation! | 11:43 |
| ogra_ | ppisati, didnt you have a spec for that ? | 11:47 |
| * ogra_ thought he saw one | 11:47 | |
| ppisati | ogra_: about what? | 11:48 |
| ogra_ | <ppisati> btw, one day i want to find out what are the minimun required configs to make a vanilla kernel boot an ubuntu userland | 11:48 |
| ppisati | ogra_: nope, unfortuntaly no | 11:49 |
| ogra_ | oh ? | 11:49 |
| ogra_ | did it get dropped ? | 11:49 |
| ppisati | never heard of a spec about it | 11:49 |
| garagoth | YESSS!!!!! i2c bus 2 working !!! | 11:53 |
| garagoth | But for some reason there is no entry about expansion board in dmesg... hum... | 11:53 |
| ogra_ | ppisati, yeah, i only saw the workitem on https://launchpad.net/ubuntu/+spec/other-kernel-o-config-review ... seems i mixed that up | 11:54 |
| persia | ogra, The minimums are tricky (but there is work to document them). There's a number of cases where things work for *some* systems and break horribly for others, because of assumptions in userspace about kernel config that only are exposed in non-default environments. | 11:57 |
| ogra_ | sure | 11:57 |
| * ogra_ didnt say it was an easy task | 11:58 | |
| ogra_ | :) | 11:58 |
| persia | Heh, yeah. But seriously, I believe the kernel team has been collecting this data since ~karmic because of some regressions discovered at karmic release because the release config didn't match userspace expectations. | 12:01 |
| persia | I doubt they have *all* the quirks documented yet, but there ought be a fair collection of information. I forget where, but remember apw telling me that it was in git somewhere. | 12:02 |
| persia | Hrm. The magic summon-the-man-who-remembers-stuff-about-the-kernel incantation didn't work :( | 12:03 |
| apw | persia, collecting which data ? | 12:04 |
| ogra_ | LOL | 12:04 |
| ogra_ | it worked :) | 12:04 |
| persia | apw, Which kernel options are required to match userspace expectations for Ubuntu. | 12:04 |
| apw | ahh i see, we have been codifying the values of ones we have found to be required, in the enforcer file, but that doesn't cover everything which is required sadly | 12:05 |
| persia | Where is the enforcer file, so ogra can have a peak at the current knowledge? | 12:05 |
| ogra_ | persia, i know where it is i think | 12:06 |
| ogra_ | ogra@isis:~/kernel/linux-ac100-2.6.37$ ls debian.ac100/config/enforce | 12:07 |
| ogra_ | debian.ac100/config/enforce | 12:07 |
| ogra_ | here we go | 12:07 |
| persia | apw, Thanks! | 12:07 |
| persia | ogra, Good luck. If you find more required configs, please make sure they reach that file for all the kernels. | 12:08 |
| ogra_ | i dont get why its in the flavour subdir though | 12:08 |
| ogra_ | since it checks lots of general values ... that should just be in debian/ | 12:08 |
| persia | Because debian.foo/ generates debian/ so anything in debian/ is subject to wiping. | 12:08 |
| ogra_ | only parts of debian/ | 12:09 |
| persia | Yeah, well. debian.foo/ is where all the kernel team work happens. | 12:09 |
| persia | They like to leave debian/ alone if possible, considering it strange black magic (which it is) | 12:09 |
| ogra_ | s/black magic/insane perl/ | 12:10 |
| ogra_ | :) | 12:10 |
| * persia agrees with Arthur C. Clarke, and continues to call it "magic" in compliance with common duck-typing algorithms. | 12:11 | |
| ogra_ | heh | 12:11 |
| ogra_ | magic always has something positive in it for me ... | 12:11 |
| ogra_ | sick parl code somewhat misses that positivity :) | 12:12 |
| ogra_ | *perl | 12:12 |
| * persia uses "black" and "white" to indicate relative positions on that continuum | 12:12 | |
| persia | And "strange" relates to it's unrelation to anything else anywhere else | 12:12 |
| ogra_ | well, even 'black' magic might make me sit in awe ... while some perl code just lets me sit in tears ;) | 12:13 |
| garagoth | ;-) | 12:13 |
| persia | Right. That's the "strange" part. | 12:13 |
| rsalveti | morning | 13:12 |
| * rsalveti reading backlog | 13:12 | |
| persia | Good morning. | 13:13 |
| rsalveti | garagoth: awesome, good you got it working | 13:31 |
| rsalveti | yeah, next step is to build just the omap flavor :-) | 13:31 |
| rsalveti | then it'll be even faster | 13:31 |
| rsalveti | persia: problem is that there is no official cross-build documentation anywhere at wiki.ubuntu | 13:32 |
| rsalveti | that's why I pointed the omap one | 13:32 |
| rsalveti | as it describes well how to do it | 13:32 |
| persia | rsalveti: hrw volunteered to create some, so that's a solved problem. | 13:32 |
| rsalveti | well, it's solved once it's done ;-) | 13:32 |
| persia | No criticism was implied to giving garagoth helpful advice: the critism was at *all of us* for not having the pages on the wiki. | 13:33 |
| ogra_ | lool, i'm looking at debian bug 550584, i dont really understand the purpose of your highest-abi file ... cant we determine the highest abi from just listing /boot ? | 13:33 |
| ubot2 | Debian bug 550584 in flash-kernel "flash-kernel not run when going to new upstream kernel version" [Important,Open] http://bugs.debian.org/550584 | 13:33 |
| persia | rsalveti: The problem of "What are we goind to do about the lack of docs" is solved. The problem "There are no good cross-compilation docs on the wiki" is pending :) | 13:34 |
| rsalveti | garagoth: I believe if you run with binary-omap it should just build for omap flavor, but need to check | 13:34 |
| ogra_ | yes | 13:35 |
| persia | Indeed. | 13:35 |
| garagoth | rsalveti: :-) | 13:36 |
| garagoth | Took me to compile this 3-4 hours | 13:36 |
| rsalveti | garagoth: that's because you compiled for both versatile and omap | 13:37 |
| rsalveti | so just omap should be half | 13:37 |
| rsalveti | and takes a while because there are tons of modules | 13:37 |
| ogra_ | well, thats still quite long for cross building | 13:37 |
| garagoth | rsalveti: I need to verify one more thing, as in dmesg there was no info that expansion board was detected. But i2c works fine! | 13:37 |
| ogra_ | the ac100 package natively takes 2h here | 13:38 |
| rsalveti | well, that depends on the host ;-) | 13:38 |
| garagoth | I have dual core 2Ghz | 13:38 |
| persia | ogra_: Right. Two flavours ~ 3-4 hours. One flavour ~ 2 hours. | 13:38 |
| garagoth | 4255 bogomips per core | 13:38 |
| ogra_ | persia, natively ... | 13:38 |
| ogra_ | persia, vs 4 for two flavours cross | 13:38 |
| persia | Heh, I know. See prior point about ARM hardware being good these days :) | 13:38 |
| ogra_ | heh | 13:38 |
| rsalveti | garagoth: can you paste me the patch you used? | 13:39 |
| persia | (and cross-compilation not actually being an interesting problem anymore) | 13:39 |
| ogra_ | yeah | 13:39 |
| ogra_ | as i said, real men build native | 13:39 |
| garagoth | uh. I used one that you pointed me to and tweaked it a little. | 13:39 |
| * ogra_ wants a T-Shirt with that *g* | 13:39 | |
| * persia suspects this also applies to real women and real small green furry things from Alpha Centuri | 13:39 | |
| garagoth | one chunk was failing, so I added it manually... and irq_set_irq_type I corrected to set_irq_type | 13:40 |
| ogra_ | not sure about the furry things ... but you could read men as "humans" | 13:40 |
| rsalveti | garagoth: ok, that should be fine | 13:40 |
| ogra_ | i doubt green furry things from alpha centauri use C ... they will likely use green furry C ... | 13:41 |
| garagoth | I gen generate a patch for you | 13:41 |
| garagoth | I still have original file | 13:41 |
| garagoth | http://nevander.eu.org/patch_expansionboards_2.6.38.10.patch | 13:44 |
| rsalveti | garagoth: your u-boot needs to set the buddy kernel argument | 13:47 |
| rsalveti | I believe the extension support is enable at u-boot already | 13:47 |
| rsalveti | but then you probably need something like buddy=${buddy} at your kernel cmd line | 13:47 |
| rsalveti | let me check u-boot sources | 13:50 |
| garagoth | aaah. | 13:50 |
| garagoth | true!!! | 13:50 |
| garagoth | Let me check :-) | 13:50 |
| rsalveti | garagoth: see if you're u-boot is already saying that you have an expansion board | 13:51 |
| lool | ogra_: one way is to scan /boot, the other is to note down the versions when installing kernels; but note that the bug concludes we should copy the grub logic | 13:51 |
| garagoth | Yes, it is detecting it correctly | 13:51 |
| lool | ogra_: debbugs are a bit hard to read because they are threaded; I usually download the mbox and either read by thread or by date | 13:52 |
| rsalveti | garagoth: so try adding buddy=${buddy} at your kernel cmd line arguments | 13:52 |
| rsalveti | garagoth: edit /boot/boot.script and then run flash-kernel | 13:52 |
| ogra_ | lool, yeah, i read that ... do you think the patch will make it into debian soon ? i would like to have it before A2 8we have massive upgrade probs due to that bug) | 13:53 |
| ogra_ | if it doesnt make debian in time, i'll just addi it to ubuntu until i can sync it, but if avoidable i wouldnt like to waste time on having to carry it in ubuntu | 13:54 |
| lool | ogra_: the patch needs to be reworked to use the grub bits and heavily tested; I'm getting asked about f-k stuff in Debian frequently, but I have a hard time making progress on it | 13:55 |
| lool | should improve in the next weeks hopefully | 13:55 |
| ogra_ | well, oneiric can be your guinea pig | 13:56 |
| garagoth | rsalveti: It works !!! | 14:22 |
| rsalveti | garagoth: awesome | 14:27 |
| garagoth | Definitely. Fully working beagle now... | 14:27 |
| uragano2 | hello, is ubuntu-omap4-extras still instable on natty? | 14:59 |
| ogra_ | instable ? | 15:00 |
| rsalveti | uragano2: should be, why? | 15:00 |
| rsalveti | tested yesterday with a fresh image and it worked fine | 15:00 |
| * ogra_ still wonders if instable is a typoed installable or unstable :) | 15:01 | |
| uragano2 | because i installed it already one time and my system become unstable, so searching on google i found this https://bugs.launchpad.net/ubuntu/+source/jasper-initramfs/+bug/759817 | 15:02 |
| ubot2 | Ubuntu bug 759817 in jasper-initramfs "ubuntu-omap4-extras from the TI PPA is not installable in natty" [Medium,Fix released] | 15:02 |
| ogra_ | thats long fixed | 15:03 |
| ogra_ | your unstability surely doesnt have to do anything with ubuntu-omap4-extras itself | 15:03 |
| ogra_ | probably with something this pulls in, but these are plenty of packages | 15:03 |
| uragano2 | ok...i try to install it again hoping that this time it'll work fine :D | 15:04 |
| ogra_ | we didnt chnage anything since release | 15:04 |
| ogra_ | *change | 15:04 |
| hrw | chromium-browser build passed 310 minutes. just 2.5h to possible breakage | 15:16 |
| === zyga is now known as zyga-food | ||
| ogra_ | hrw, how long does it usually take ? | 15:20 |
| hrw | last time it took 440 minutes to fail | 15:21 |
| ogra_ | (and why is everyone building chromium today ?) | 15:21 |
| hrw | on panda | 15:21 |
| hrw | ogra_: it ftbfs on armel | 15:21 |
| ogra_ | ah | 15:21 |
| ogra_ | well, someone in #ac100 compiles it too today | 15:21 |
| hrw | I have a patch for 440 minutes breakage applied | 15:21 |
| * ogra_ crosses fingers | 15:22 | |
| hrw | bug 791283 btw | 15:22 |
| ubot2 | Launchpad bug 791283 in chromium-browser "chromium-browser version 11.0.696.71~r86024-0ubuntu1 failed to build on armel" [Undecided,Confirmed] https://launchpad.net/bugs/791283 | 15:22 |
| hrw | 12.something.x.y also fails | 15:22 |
| ogra_ | yeah, i saw it on the fstbfs list since a while | 15:22 |
| uragano2 | this time the installation finished successfully :D | 15:28 |
| uragano2 | audio throws hdmi doesn't work...can u help me? | 15:44 |
| uragano2 | *through | 15:44 |
| jeremiah | Hi. The oneiric daily headless OMAP 4 doesn't want to boot the kernel | 16:45 |
| ogra_ | heh, that can well be | 16:46 |
| jeremiah | Is there a place to file bugs or does one just report here? | 16:46 |
| ogra_ | see the topic | 16:46 |
| jeremiah | Ah, cool | 16:46 |
| ogra_ | we just changed the build system completely, so its no surprise there are issues :) | 16:46 |
| jeremiah | Okay. | 16:46 |
| jeremiah | No problem. Is there a more stable version that one might try? | 16:47 |
| jeremiah | Like a natty build? | 16:47 |
| jeremiah | Or what do people recommend for getting a debian based OS onto the Panda? | 16:47 |
| ogra_ | ah | 16:47 |
| ogra_ | https://wiki.ubuntu.com/ARM/OMAP | 16:48 |
| persia | jeremiah, There are working natty images. | 16:48 |
| ogra_ | see that page | 16:48 |
| jeremiah | persia: Oh really? Okay, I'm happy to try on of those. :) | 16:48 |
| jeremiah | I guess I'll use my google-fu :) | 16:49 |
| persia | No, check the page ogra gave you | 16:49 |
| jeremiah | Ah, okay, will do. | 16:49 |
| persia | Has direct links and everything. Without sponsored links or ads or anything :( | 16:49 |
| persia | s/(/)/ | 16:49 |
| jeremiah | heh | 16:49 |
| === Amaranth_ is now known as Amaranth | ||
| jeremiah | Well, I'll try the 11.04-preinstalled-headless-armel+omap4 and see what happens. | 16:52 |
| persia | Beware that you have selected a *very* minimal install: you likely have to install bundles of things to make it do what you want. | 16:52 |
| GrueMaster | jeremiah: what rev board do you have? | 16:52 |
| jeremiah | persia: I plan to do that, I'm going to try to spin up the Automotive respin | 16:53 |
| jeremiah | GrueMaster: Let me check . . . | 16:53 |
| ogra_ | ah, for the automotive respin that image might actually still be a bit big :) | 16:53 |
| GrueMaster | Should be a label on the bottom of the board. | 16:53 |
| jeremiah | GrueMaster: Looks like the lable says REV A# | 16:54 |
| jeremiah | Sorry, Rev A3 | 16:54 |
| persia | ogra, Isn't it just ubuntu-minimal? | 16:54 |
| ogra_ | jeremiah, you might want to talk to Dr_Who i know he knows some tricks to make them even smaller | 16:54 |
| ogra_ | persia, -standard iirc | 16:54 |
| jeremiah | ogra_: Really? Okay. :) | 16:54 |
| GrueMaster | A3??? Didn't know they were available. | 16:54 |
| persia | jeremiah, Do you particularly want to do it as a remix (as it is called in our nomenclature)? | 16:54 |
| jeremiah | GrueMaster: I just got onw | 16:54 |
| GrueMaster | cool. let me know how it goes. | 16:55 |
| ogra_ | persia, yes, it was defined at UDS | 16:55 |
| jeremiah | persia: Well, I've been working with some Canonical folks to get this up and running. | 16:55 |
| ogra_ | an IVI remix | 16:55 |
| jeremiah | I work the GENIVI consortium | 16:55 |
| persia | ogra, It's not tricks: it's a smaller seed collection (linaro nano) | 16:55 |
| Dr_Who | Hi jeremiah | 16:55 |
| jeremiah | And Canonical is planning on releasing the official GENIVI "respin" | 16:55 |
| ogra_ | persia, its also omitting the installation of any docs etc | 16:55 |
| jeremiah | Dr_Who: Hi! | 16:55 |
| ogra_ | nano is surely so shrunk down for a proper ubuntu | 16:56 |
| jeremiah | Dr_Who: I was hoping to do some testing of the Ubuntu / GENIVI respin for automotive | 16:56 |
| Dr_Who | yeah and in the next incantation, replacing some of the core elements with their busybox counterparts | 16:56 |
| ogra_ | but something between minimal and nano should be cleanly possible | 16:56 |
| persia | Ah. I'd be in favour of having an automotive flavour from which Canonical derived, but that may require more coordination. | 16:56 |
| jeremiah | I have a list of packages and I'll add some of the GENIVI components | 16:56 |
| * GrueMaster wanders off ins search of something called the "loo". | 16:56 | |
| Dr_Who | jeremiah: sounds like fun! | 16:56 |
| jeremiah | Dr_Who: It is! :) | 16:56 |
| ogra_ | GrueMaster, two times right | 16:56 |
| jeremiah | Any time I get to fool around with Ubuntu its fun | 16:56 |
| ogra_ | down the corridor | 16:57 |
| Dr_Who | jeremiah: you might be interested in https://wiki.linaro.org/LiveHelper/Hacking | 16:57 |
| Dr_Who | basically how to roll your own images | 16:57 |
| jeremiah | persia: Well, there has been a bit of co-ordination with Chris Kenyon, Ken Edwards, et. al. from Canonical. | 16:57 |
| jeremiah | Dr_Who: Okay, I'll read that. | 16:57 |
| jeremiah | Thanks | 16:57 |
| Dr_Who | I can point you at the things we did for nano which may or may not be of interest to you | 16:58 |
| === easwar is now known as meindian523 | ||
| jeremiah | I think if I can get a kernel to boot on the OMAP I'd be happy. I'm willing to leave the userland pretty plain for a bit. | 16:58 |
| Dr_Who | jeremiah: o actually its in that wiki page | 16:58 |
| jeremiah | We don't have an official OMAP release until October. | 16:58 |
| Dr_Who | ah .. plenty of time | 16:59 |
| ogra_ | ah, well in that case the headless image is surely the least painful startin point | 16:59 |
| jeremiah | (Even though the official Canonical press release claiming compliance is out!) =) | 16:59 |
| jeremiah | ogra_: Cool, I'll start there. | 16:59 |
| jeremiah | I already have the headless running on the OMAP 3 | 16:59 |
| jeremiah | Really nice. | 16:59 |
| ogra_ | and then apply nano imporvements where possible | 16:59 |
| jeremiah | So the steps would be to boot Natty on the panda then use Live Helper? | 17:01 |
| GrueMaster | image is the same on omap4. | 17:01 |
| persia | Booting Natty on the panda gives you a development environment. | 17:02 |
| === NCommand1r is now known as NCommander | ||
| persia | Live Helper lets you build images based on some archive (you might use natty). | 17:02 |
| ogra_ | jeremiah, live helper is to actually produce rootfses | 17:02 |
| jeremiah | persia: Ah, okay. Thanks. | 17:02 |
| persia | Running live-helper (or rather live-build) on the panda lets you build images for use on the panda. | 17:02 |
| ogra_ | right, it was renamed | 17:02 |
| jeremiah | ogra_: okay, now I get it. So it would allow me to create a custom root file system | 17:03 |
| jeremiah | That is frickin' great. | 17:03 |
| jeremiah | Just what I'm looking for. | 17:03 |
| persia | If you're testing experience, you can run live-build on an arbitrary platform where you know you have support, and build images for that platform. | 17:03 |
| persia | If you're testing platform support, you want to run it natively (at least on the same architecture) | 17:03 |
| jeremiah | persia: Hmm, interesting. I need to do some testing but don't really have a testing environment yet. | 17:03 |
| persia | Do you need to test images, or just test software? | 17:04 |
| jeremiah | The goal is to port some automotive software to the OMAP | 17:04 |
| persia | In that case, I'd recommend completely ignoring live-build for now. | 17:04 |
| jeremiah | So mostly just testing apps | 17:04 |
| jeremiah | Ah, okay. Fair enough. | 17:04 |
| ogra_ | yeah, what persia said | 17:04 |
| persia | Just install Natty on the panda. | 17:04 |
| jeremiah | I plan to do some building and then package the apps so others can test | 17:04 |
| persia | Then install the application you want to test (package it for easy uninstall/upgrade/etc.) | 17:04 |
| jeremiah | Later we'll do the integration. | 17:04 |
| jeremiah | Cool, sounds like a plan. | 17:05 |
| persia | If you're doing packaging, I'd strongly recommend either doing packaging on *some other* machine, and just build on the panda *OR* install the Netbook image on the panda and use that as a development environment. | 17:05 |
| persia | (depends how many Ubuntu boxes you have around) | 17:05 |
| jeremiah | I have a Tegra2 box | 17:05 |
| persia | Starting from the headless image as a development environment will get annoying very quickly. | 17:05 |
| jeremiah | And a Intel Core 2 duo | 17:06 |
| persia | Ah, that works :) | 17:06 |
| persia | Either is good for packaging. For building, you want to build the package on the tegra or the panda. If both are running Ubuntu, the results ought be identical. | 17:06 |
| jeremiah | I won't need an magic VFP flags for the tegra? | 17:06 |
| persia | Once you know the set of packages you want to deploy, then it's worth looking at seeds, live-build, etc. and attempting to make an image to distribute as the remix. | 17:07 |
| persia | No. | 17:07 |
| jeremiah | I thought that I might face some NEON issues. But the box I have, called the TrimSlice seems to be working pretty okay | 17:07 |
| ogra_ | by default ubuntu doesnt use NEON at build time anywhere | 17:07 |
| ogra_ | thats a requirement | 17:07 |
| jeremiah | Ah okay, good to know | 17:07 |
| persia | No. | 17:07 |
| persia | Rather, Ubuntu doesn't default to NEON instructions anywhere, and only uses NEON where runtime detection is available. | 17:08 |
| ogra_ | your Sw either needs runtime detection two binary packages | 17:08 |
| persia | Ubuntu *definitely* uses NEON at build time, or we wouldn't be able to support NEON runtime detection :p | 17:08 |
| ogra_ | ubuntu doesnt support packages using neon at build time | 17:08 |
| persia | The buildds can't execute NEON? | 17:09 |
| ogra_ | sure they can | 17:09 |
| persia | So, how isn't it supported? | 17:10 |
| persia | By policy, packages aren't allowed to depend on NEON being available at runtime. | 17:10 |
| persia | But I don't see how this affects build-time. | 17:10 |
| ogra_ | it isnt supported to default to NEON and to hardcode that at build time | 17:10 |
| persia | And, further, I suspect that test code run at build time *would* run NEON, as the runtime detection should notice it is available. | 17:10 |
| persia | Ah, yes, that's not supported :) | 17:11 |
| ogra_ | phew | 17:11 |
| ogra_ | finally i got the formulation of the sentence in a way that persia agrees | 17:11 |
| GrueMaster | Amazing. | 17:11 |
| persia | P.S. It's easier to talk about not supporting NEON-by-default *at runtime* than fussing about build-time :p | 17:11 |
| persia | jeremiah, Anyway, my understanding is that the base VFP stuff is implemented the same for a range of SoCs, and we're mostly using that. This does mean that we don't take advantage of some of the capabilities of TEGRA (but that would need runtime detection, etc. for all the same reasons it's required for NEON) | 17:13 |
| jeremiah | Okay, cool! | 17:34 |
| uragano2 | somebody know why during the boot i see IP-Config: eth0 hardware address MAC-A mtu 1500 DHCP [ 2.775718] eth0: link up IP-Config: no response after 60 secs - giving up | 17:38 |
| persia | uragano2, Maybe there is software attempting to bring up a network link that you aren't using? | 17:40 |
| uragano2 | i see this since the first time that i installed natty | 17:42 |
| uragano2 | persia: no, sorry. the error was an other i confused! anyway i have installed only ubuntu-omap-extras and dropbear, | 17:44 |
| shirgall | Anyone know where I can get the stuff to enable the sound on my pandaboard on Oneiric? | 18:07 |
| ogra_ | stuff ? | 18:07 |
| shirgall | ogra_: not sure what I need to make it work | 18:07 |
| shirgall | ogra_: So I punted and was non-specific. :) | 18:07 |
| shirgall | ogra_: If I plug in a USB sound "card" that works fine. | 18:08 |
| ogra_ | bug 746023 | 18:08 |
| ubot2 | Launchpad bug 746023 in alsa-utils "No sound on omap4" [High,In progress] https://launchpad.net/bugs/746023 | 18:08 |
| ogra_ | see the pre-last comment from tobin | 18:08 |
| ogra_ | it is also in the release notes and on various wikipages | 18:08 |
| shirgall | Ah, thanks, will look. | 18:08 |
| uragano2 | i am experiencing many issues with natty!!! did u do too??? | 18:39 |
| hrw | uragano2: natty is past... | 18:41 |
| uragano2 | what do u mean? | 18:42 |
| hrw | I am experiencing issues with oneiric | 18:42 |
| MrCurious | by any chance does a pandaboard compiling ubuntu kernel page exist? Its been years since i built a kernel, and that was on familiar hardware. I have no idea what to enable/disable for a pandaboard. | 18:47 |
| persia | MrCurious, Grab the kernel from the archive, and look at the config as a base. | 18:50 |
| MrCurious | you mean apt-get install kernel? | 18:51 |
| NCommander | MrCurious: the config files for an ubuntu kernel are installed to /boot/config-*-omap4 | 18:53 |
| MrCurious | oh sweet | 18:53 |
| MrCurious | now the end of persia's sentence parses (in my head) | 18:53 |
| persia | apt-get source, but that was the idea. | 18:53 |
| MrCurious | just to locate the kernel. reading through a apt-cache search now | 18:53 |
| persia | It's "linux-to-omap4" for the panda, isn't it? | 18:55 |
| persia | Err, "linux-ti-omap4" | 18:55 |
| MrCurious | from looking at the uname compared to the avail kernel sources it seems there were some patches put against it? | 18:57 |
| MrCurious | the -1208-omap4 | 18:57 |
| persia | That's the name of the binary package. GO ahead and grab that, and apt will do the right thing. I'm not sure it does the right thing with the source name for kernel packages (I know it does the wrong thing for the main Ubuntu kernel, and filed a bug about it a few years ago) | 19:03 |
| MrCurious | so grab the source on teh -1208-omap4 binary kernel? | 19:04 |
| persia | Right. That gets you the source, all the patches, and the configuration used. | 19:05 |
| persia | You can fiddle with that with relative confidence that you can undo what you did and get back to what was installed by default. | 19:05 |
| MrCurious | oh sweet, the source tag is going to become my new best friend of the minute | 19:05 |
| persia | apt-get source is a handy tool: it's part of what makes using an open source operating system fun :) | 19:05 |
| uragano2_ | what means if i run arp -a form my pc and it returns "pandy.homenet.telecomitalia.it (192.168.1.217) at <incomplete> on wlan0"..why is it incomplete? | 20:07 |
| MrCurious | to build the image for pandaboard, on pandaboard, its make uImage then make uinstall (will that work right when the msdos partition is on SD, and the root partition is on a USB drive? | 20:40 |
| MrCurious | here is to hoping that all the configuration options are auto set | 20:48 |
| MrCurious | well, make uImage fails 3 files in with no rule to make target | 20:53 |
| MrCurious | it has been a long time. make dep is now un-needed | 20:53 |
| MrCurious | guessing i have to copy the config from /boot to defconfig in the kernel dir? | 20:57 |
| persia | MrCurious, Build a kernel package, and then install it. Let flash-kernel take care of the details. | 20:57 |
| MrCurious | having trouble getting the kernel build to take off | 20:58 |
| MrCurious | trying to put in teh patch to usb that prpplague mentioned in teh pandaboard post from a few hours ago | 20:58 |
| MrCurious | trying to work out how to get /boot/config-2.6.38-1208-omap4 to apply to the kernal-image-2.6.38-1208-omap4 sources i downloaded | 21:02 |
| MrCurious | and get that image built | 21:02 |
| MrCurious | ubuntu/aufs/magic.mk no such file or directory | 21:03 |
| MrCurious | thinking i am on teh wrong path | 21:04 |
| MrCurious | make clean doesnt work | 21:04 |
| persia | https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel might help. It'S written from the i386/amd64 perspective, but most things are basically the same. | 21:04 |
| MrCurious | ty | 21:05 |
| === meindian523 is now known as easwar | ||
| === zyga-food is now known as zyga | ||
| MrCurious | persia: when i get to the fakeroot debian/rules step i discover i lack a debian/rules | 22:30 |
| MrCurious | any hings? | 22:30 |
| MrCurious | hints rather | 22:30 |
| persia | How did you get the source? | 22:30 |
| MrCurious | apt-get source linux-image-$(uname -r) | 22:30 |
| MrCurious | which gives me /usr/src/linux-headers-2.6.38-1208-omap4 | 22:31 |
| MrCurious | i wonder if make clean nuked that | 22:31 |
| persia | It shouldn't. | 22:31 |
| persia | It should give you a .dsc file, a .gz file, and an unpacked directory "linux-omap" in the directory in which you ran apt-get source. | 22:32 |
| MrCurious | it did make a src dir in the dir i ran that | 22:32 |
| MrCurious | is that the kernel dir i should be messing with instead of the one in /usr/src? | 22:33 |
| persia | Yes. | 22:33 |
| persia | I'm not sure how you got the one in /usr/src | 22:33 |
| MrCurious | i grabbed the kernel in a variety of ways, i guess | 22:34 |
| MrCurious | building the kernel outside of /usr/src feels ODD | 22:35 |
| persia | Heh. We do offer several choices, so that people who want to do different things can. Sometimes that seems like a good idea, and sometimes it makes it awkward (as many fok randomly search the internet for solutions, and find all sorts of recommendations out there) | 22:36 |
| MrCurious | yup | 22:36 |
| MrCurious | i am documenting my travels, so i can only ask once | 22:36 |
| persia | Ask as much as you like. | 22:36 |
| MrCurious | ty | 22:37 |
| persia | We don't always agree on things, but if you ask, we're more likely to point you to reasonably heavily trod paths :) | 22:37 |
| persia | If you don't ask, you never know what you might find. | 22:37 |
| MrCurious | thanks! oh, a bud pointed me to a rather simple way of getting ubuntu to bring up wireless on boot | 22:37 |
| persia | Which? I have a suspicion I won't like it, but still ... :) | 22:38 |
| MrCurious | i pm you it | 22:38 |
| MrCurious | it may not be perfect, as i noticed the box lost networking after being on for a day or two | 22:39 |
| MrCurious | make: *** No rule to make target `binary-generic'. Stop. | 22:39 |
| MrCurious | that sounds ominous | 22:39 |
| MrCurious | wonder if i need binary-generic | 22:40 |
| persia | It's a rule in debian/rules. Not something external you need. | 22:40 |
| persia | You shouldn't have to uninstall Network Manager to do that: Network Manager is supposed to check /etc/network/interfaces and ignore anything defined there. | 22:41 |
| MrCurious | hmmm | 22:41 |
| MrCurious | hmm debian/rules lacks a binary-generic | 22:41 |
| MrCurious | root@unwin-desktop:~/linux-ti-omap4-2.6.38# grep binary debian/rules | 22:42 |
| MrCurious | binary: binary-indep binary-arch | 22:42 |
| MrCurious | include $(DROOT)/rules.d/2-binary-arch.mk | 22:42 |
| MrCurious | include $(DROOT)/rules.d/3-binary-indep.mk | 22:42 |
| MrCurious | perhaps the build mechanism has mutated since the howto page was last touched | 22:43 |
| persia | Oughtn't have been. | 22:44 |
| persia | Maybe the ti-omap kernel is different somehow. | 22:44 |
| persia | Anything in rules.d/* ? | 22:44 |
| MrCurious | well, i think i will just push on, and hope that dependency management catches any missed steps | 22:44 |
| MrCurious | 3 different rules.d dirs (debian.ti-omap4, debian, and debian.master | 22:45 |
| MrCurious | ti-omap4 dir only has armel | 22:46 |
| MrCurious | .mk | 22:46 |
| persia | debian/rules.d/* | 22:48 |
| MrCurious | 0-common-vars.mk 1-maintainer.mk 2-binary-arch.mk 3-binary-indep.mk 4-checks.mk 5-udebs.mk | 22:48 |
| persia | debian.ti-omap4 *should* have been used to populate debian/ when the source package was uploaded, so you oughtn't need to worry for making local packages. | 22:48 |
| MrCurious | binary-arch is the one we want | 22:48 |
| MrCurious | ? | 22:48 |
| persia | I don't remember what debian.master does. | 22:48 |
| persia | binary-arch.mk probably includes the definition for binary-arch: | 22:49 |
| persia | make sure debian/rules includes debian/rules.d/binary-arch.mk | 22:49 |
| MrCurious | nope | 22:49 |
| MrCurious | well it does i think | 22:50 |
| MrCurious | include $(DROOT)/rules.d/2-binary-arch.mk | 22:50 |
| MrCurious | binary-arch appears to be building stuff | 22:53 |
| MrCurious | back in a bit. going to let it cook and see what it makes | 22:53 |
| persia | Oh, right. | 22:54 |
| persia | "binary-generic" is the expansion of "binary-${FLAVOUR}". | 22:54 |
| persia | You probably wanted "binary-ti-omap4" | 22:54 |
| persia | Oughtn't matter in practice: I believe this kernel source only has the one flavour. | 22:55 |
| MrCurious | make: *** No rule to make target `binary-ti-omap4'. Stop. | 22:58 |
| MrCurious | hmmm | 22:58 |
| MrCurious | well binary-arch was making something think i will let that cook | 22:59 |
| persia | We'll see what it makes :) | 23:01 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!