[01:40] hey guys === panda is now known as Guest59538 === asac_ is now known as asac [02:58] morning [02:59] hey bud [02:59] XorA|gone: you get a chance to fill in the pandaboard survey? [02:59] prpplague: already done [02:59] XorA|gone: dandy [03:00] probably the only hope I have of getting one :-D [03:00] a chronos watch? [03:00] XorA|gone: you still haven't gotten a pandaboard? === Guest59538 is now known as panda|x201 [04:18] prpplague: nope [04:19] * XorA|gone is now starting to hate hardware designers [04:19] prpplague: thats not you BTW :D [04:19] hehe === fta` is now known as fta [09:00] flash-kernel needs changes for panda ;( [09:01] 1. 2.6.38-rc has "OMAP4 Panda board" not "OMAP4430 Panda Board" [09:01] 2. linaro kernel is 'omap' not 'omap4' flaovour === asac_ is now known as asac [09:42] hrw, you mean /proc/cpuinfo changed for panda? [10:00] yes [10:00] who knows, maybe one day there will be 4440 based panda [10:42] on a panda, how can I pass boot arguments to the kernel from u-boot without adding a new boot.scr ? I'd like to pass nosmp [10:43] easiest it to edit boot.scr [10:47] hrw: I'm afraid there are multiple versions of the kernel which can boot panda in natty and the latest flash-kernel changes don't allow this [10:48] I know [10:52] well, -omap is tricky, tres is trivial [10:52] s/tres/the rest/ [10:52] * ogra doesnt get where the letters went, i definitely typed them [10:53] I prefer to not touch flash-kernel. my changes ends in ogra's merge queue which is huge enough [10:54] hrw, i will surely fix the cpuinfo bit but would appreciate a patch to handle the case where the package is named -omap [10:54] i fear that will break NCommander's changes for generic kernel installation [10:54] Why does flash-kernel limit which kernels can boot? Shouldn't it take the latest usefully installed kernel, and perform the appropriate action? [10:55] hmm, wait, you are right, flash-kernel doesnt care for package names at all [10:55] * ogra re-checks [10:55] it cares for flavour names [10:55] it shouldnt [10:55] If it cares for flavour names, it needs to be fixed. [10:55] then kill sub_arch check [10:59] Hrm, but it ought care about subarch. [11:00] persia, it does that since NCommander added his subarch stuff [11:00] uname -r | sed -e 's/.*-//' [11:00] it doesnt care for package names but for flavour in uname [11:01] Right. [11:01] which also breaks blaze [11:02] Debian flash-kernel uses kfile to determine subarchi. [11:02] With subarch=$(echo "$kfile" | sed -e 's/.*-//') [11:04] The confusing bit is that the Debian version seems to be willing to accept kfile=/boot/vmlinuz and I'm unsure how that works with check_subarch [11:07] flash-kernel require rewrite I think [11:08] Ah, I see. if subarch="", check_subarch always returns true. [11:11] that doesnt matter [11:11] what matters is that check_subarch is completely ignored on dove omap and omap4 arches [11:12] Ah, because there are no "machine" entries. I see. [11:13] yep [11:13] the prob is that instead of guessing for a proper kernel the code just makes it ignore the check [11:13] and installs whatever kernel is available [11:14] to be proper implemented it would need more of a database and some clever algorhythms to do guesswork [11:15] Right. I see the issue now. flash-kernel is just entirely different for omap|omap4 than everything else, which is a bit confusing. [11:15] a proper implementation would be possible with devicetree db's [11:16] you could match kernel features against the actual hw [11:16] How would that work? [11:16] the kernel ships the devicetree data anyway [11:17] so you iterate over the devices and match them against the actual HW of the board on your first run or from d-i [11:18] if you find the kernel supports a) the arch and b) enough devices for booting, you write a flag [11:18] that flag is looked up on flash-kernel run [11:18] How does one define b) ? [11:19] rootfs device, serial support and basic init ... you need a db for that indeed [11:19] Why do we care about serial? How can we identify "basic init" for arbitrary boards? [11:19] you could spill a warning if not everything is supported [11:20] you cant you will always need a matching db about whats needed for init [11:20] but that way you can at least support a wider range of HW without breaking it for totally unsupported stuff [11:21] Makes porting new devices kinda annoying. I thought with devicetree, we were expecting the kernel to be able to do discovery-boot on arbitrary devices. [11:21] only for devices it has a machine file for [11:21] I thought you would be able to specify a machine file on the kernel command line. [11:21] you still have the toplevel subarch [11:22] i.e. take the touchbook ... [11:22] essentially its a beagle [11:22] and you can use a beagle kernel on it [11:22] but wont have much devices [11:22] since the devices are special and never have been pushed upstream [11:23] you will still be able to boot into serial with any std beagle kernel though [11:25] So, let's say there is a device with necessary upstream support. Should that just work? [11:26] And with the current model, what ought be done differently for the touchbook? It seems to me that it wouldn't be any different to use the machine specifier or running_subarch. [11:26] (as the subarch isn't changing) [11:28] it would be able to tell you that you only have minimal kernel support and optionally ask you about proceeding or not [11:28] So, increase the verbosity of the "Generic Subarch" warning, and ask the user to confirm the operation? [11:29] leave the user the option to not mess up his system [11:31] I can't reconcile wanting to be able to boot (perhaps with confirmation) on devices the code doesn't know about and wanting to have a comprehensive DB controlling the booting. [11:31] How would that work? [11:31] heh, well, if you run flash-kernel you already have a working system [11:32] if you would run it on a kernel that drops features you surely would want a warning [11:33] Yes, but if you run flash-kernel-installer, you may not have a working system yet. [11:34] if you run flash-kernel-installer on such a system, d-i has a bug [11:34] Huh? Why? [11:34] it shouldnt install on unsupported HW [11:34] actually the check should happen way way earlier [11:36] So, I'm a user. I copy some data I downloaded off the internet onto my card. I stick it in my device. I turn it on. [11:37] and d-i (or whgatever else) politely tells you that you in max will run that device with a serial console [11:37] At this point, there are three options. If I'm booting an alternate image, base-installer checks to make sure I'm installing an acceptable kernel. [11:37] or tell you its not supported at all [11:37] or it just works [11:37] If I'm booting a live image, there is no check. [11:37] if I'm booting a pre-installed image, there is no check. [11:37] right, we should add that to jasper [11:37] jasper should probably leverage base-installer to do that. [11:38] yes [11:38] But there's still the live image case. [11:38] its on my WI list [11:38] Heh, OK. [11:38] thats why i asked you about your tool in main ;) [11:38] How is that related? [11:38] device-detect gets me more detailed info [11:38] Than what? [11:39] archdetect (which is what base-installer uses) [11:41] Please *don't* use devicetype-detect for that. [11:41] You'd just be duplicating the test suite, etc. [11:41] but i need to match against more detailed data than archdetect can deliver [11:42] No you don't. [11:42] jasper *is* duplicating stuff [11:42] If you need more specificity, you need to get that into archdetect [11:42] thats its whole purpose [11:42] no, i dont [11:42] I thought we had a UDS session about that. [11:42] archdetect does exactly what its supposed to do [11:42] And decided that jasper should *not* duplicate stuff. [11:42] but doesnt get me enough data back [11:43] jasper *has* to duplicate casper functions [11:43] thats its whole purpose [11:43] What data do you need? [11:43] if you would check live images you would have to implement it in casper [11:43] arch *and* device [11:43] Why? [11:44] because our kernels can support more than one device [11:44] So, back to my story. [11:44] I boot into the live image. Everything is working. I press install. [11:45] and it would be clever to i.e. be able to shut off gdm if you detect you run on a beagle C4 [11:45] It installs, the install runs flash-kernel installer. It installs the kernel that I booted. [11:45] Why do I care if I'm using a device that you've never heard about? [11:45] yeah, thats no issue [11:45] It is if you care about device. [11:45] Because if you care about device, you're going to tell me it doesn't work, and maybe try not to install. [11:46] exactly [11:46] So it is an issue, which is a bug. Let's look at another way to do it that doesn't have that problem. [11:47] As I see it, we have two ways we can fail. [11:48] We fail if we write a kernel to a device which can't use it, and render it unbootable. [11:48] We fail if we refuse to work on a device on which the kernel works. [11:48] Do you see any others? [11:48] half way working devices [11:49] and devices for which this image isnt suited [11:49] (beagle C4 with a full desktop for example) [11:49] I refuse to have an opinion on whether someone wants to run a given image on a given device. That decision belongs to the user. All we can do is suggest things. [11:49] we can adjust defaults [11:50] I don't think that's being nice. [11:50] if i turn off gdm on a C4 thats helping the user and gdm is still there to be started if he wants to [11:50] Let's imagine someone has a beagle C4 that they hacked to have 1G ram and are running overclocked in liquid nitrogen bath: who are we to say they can't run normal desktop? [11:50] they can [11:51] and given they were clever enough to hack it that way i would trust them to find out how to re-renable gdm [11:51] Anyway, we're getting sidetracked. Let's ignore all the defaults for now. [11:52] So, about devices that only kinda work: is the failure if we boot our kernel, or if we don't boot our kernel? [11:52] I'll claim the failure is to not boot the kernel, as otherwise we can never collect useful bug reports. [11:52] yes, i agree [11:52] but the user needs to know about it [11:53] I've no issue with that. [11:53] if you boot a kernel that has no display support at all the user needs to know that [11:53] How can you tell the user this? There's no display... [11:54] mors code on an LED :P [11:54] *morse [11:54] You're mad! [11:55] no, indeed you are right, if we are in first boot that doesnt help [11:55] Going back something useful. [11:55] if i install a development kernel it does though [11:55] So, we've booted the first time with a downloaded install image. [11:55] right, that either boots or doesnt [11:56] As a result, we have confidence that the kernel we booted is sufficient to allow the user interaction, which implies able to boot off install media, input/output of some sort, etc. [11:56] yes [11:56] And I claim we can trust the user to have selected the appropriate input/output (serial console, KVM, etc.) for their needs. [11:57] if the user sees it booting he should, yeah [11:57] Next, we do the install steps (jasper/ubiquity/d-i). [11:57] At this point, we end up calling flash-kernel-installer [11:58] This should succeed. I've no issues with warning the user in the event that it's a device we don't know, but since we booted on that kernel, we ought to be able to install that kernel on the device. [11:59] then flash-kernel-installer should have no checks at all [11:59] Now, here's where it gets tricky. [12:00] There's N different kernels in the archive, and K different ways to mangle the kernel to make it bootable. [12:00] the point is that you need to identify the way the device boots [12:00] in which case you again need the data about the device, not the arch [12:00] So, we care about K, but not about N? [12:01] you just said yourself, if we are booted from that kernel to a point where it works, we dont need to care about N [12:02] flash-kernel will only dump the kernel in a different place [12:02] the place is the point [12:02] and that depends on the device data [12:02] OK, so for that we want the machine info from CPUinfo [12:02] right [12:02] but probably even more [12:02] i.e. beagle C4 vs XM [12:02] And the abstraction of omap_flash_kernel and dove_flash_kernel only breaks things. [12:03] cpuinfo doesnt identify the difference [12:03] devicetype-detect doesn't. [12:03] hmm, we should enhance it that way [12:03] (actually, devicetype-detect only outputs strings like "netbook", "laptop", "desktop", "phone", etc. (even less detail)) [12:04] No. The point of devicetype-detect is to add some flexibility to laptop-detect. [12:04] device-name detect would be more intresting, yes [12:04] devicename-detect has all sorts of arch-specific hackery, but for armel, just uses machine from cpuinfo. [12:05] devicename-detect is mostly interesting because it has the equivalent collection for every architecture. [12:05] So, again, that's no more information. [12:05] it should have revision data [12:05] cpuinfo has that. Devicename-detect doesn't care. [12:05] or at least a switch to show it [12:05] Parsing cpuinfo is significantly more robust. [12:06] but exhausts what flash-kernel can do atm [12:06] How do you mean? [12:07] machine=$(grep "^Hardware" /proc/cpuinfo | sed 's/Hardware\s*:\s*//') [12:07] Right. [12:07] thats all that is matched against [12:07] and not all boards ahve a revision in cpuinfo [12:07] so you cant just blindly match against it [12:08] You're saying that cpuinfo:Hardware doesn't have an identity relation to method-to-make-kernel-bootable? [12:08] not on all boards [12:09] thats the prob [12:09] "OMAP3 Beagle Board" [12:09] is returned for *all* beagles since revision A [12:10] so you can have a 128M, 256M or 512M version with or without flash etc etc [12:10] Is this a kernel bug, or is there additional information available that lets us identify the specific requirements for boot? [12:10] no, thats a design decision from the manufacturer [12:10] persia: it is not a kernel bug [12:10] A3/B7/C3 are beagleboard. they just have different revision [12:11] XM too [12:11] ogra: never played with xM [12:11] So, is there additional information available that lets us identify the specific requirements for boot? [12:11] and you will see the same prob on panda [12:11] though here its even worse since the kernel string changed between revisions [12:12] would be intresting to know what the linaro kernel says on blaze or tablet [12:12] or on the RIM tablet :) [12:12] or the new LG phone ... [12:12] So, is there additional information available that lets us identify the specific requirements for boot? [12:13] not on beagle, i think there is a sysfs file somewhere and u-boot should know it too by poking some HW info [12:13] but u-boot is gone at that point [12:14] Do we know which sysfs file? [12:14] no, i dont atm [12:14] Because we ought to be checking that to define machine in flash-kernel/flash-kernel-installer, rather than cpuinfo:hardware [12:14] and dont have either board around to check [12:14] hrw, Any ideas? [12:15] cpuinfo:hardware is ok for top level identification [12:15] cpuinfo:hardware + cpuinfo:revision are nearly always present on arm [12:15] No, it's useless, if there isn't an identity relation between that and technique-for-making-device-bootable [12:16] hrw, does that pair have an identity relation to technique-for-making-device-bootable? [12:16] persia: sorry, I didn't followed whole discussion [12:16] persia: even hw+rev will not tell you do you need uImage or zImage. [12:16] Ah, so yeah, that's not complete. [12:16] beagleboard can have u-boot or Qi or barebox or anyother bootloader [12:17] Basically, we need some way to know what method to use to make a device bootable. [12:17] Or rather, to be able to select from a set of recipes to convert a packaged kernel into whatever format/placement/etc. is required so that it is a bootable kernel. [12:18] if you stick to 'this machine is ubuntu stock config' then hw+rev should work for most I think [12:19] What do you mean by "ubuntu stock config"? [12:20] granted that device runs known bootloader [12:21] otherwise you will end in hell of providing uImage + zImage + wtfImage + .... + yabImage [12:21] rim tablet may not be so easy to get your own kernel executing on [12:22] I'm willing to pick a preferred bootloader on a per-device basis. [12:22] lilstevie, Why? [12:23] the playbook devel images are starting to show RSA 4096bit signatures [12:23] Oh, annoying bootloader. I'm happy to ignore those devices. [12:24] heh [12:24] the galaxy tab is starting to do my head in too [12:24] Most of the time someone figures out a way to work around them at some point, and only after that is anyone likely to run Ubuntu on them. [12:25] something really doesnt want to let X work on it [12:25] if it is anything like iDevices someone will need to write a replacement bootloader for it [12:25] ogra, Do you know of a case where Hardware+Revision matches two different devices with different requirements for flash-kernel? [12:26] is there a way of getting greater detail on what is screwing with Xorg than -verbose 20 [12:28] lilstevie, You might ask the folk in #ubuntu-x [12:31] persia: ok thanks I asked over there [12:36] ikepanhc, Hey. Do you happen to know if there is a unique device entry in the sysfs tree, or if our best information is Hardware+Revision from cpuinfo? [12:36] did someone stacked beagles with pandas? [12:37] do we have a tiwlan driver somewhere? [12:38] persia: you need the list of device within SoC? [12:38] ikepanhc, Rather, when booting a retail device, I'm trying to have a unique identifier for what to do with a kernel post-install so it will boot. [12:39] Sorry for the confusion around the word "device" [12:40] apachelogger, There's one in a PPA: https://launchpad.net/~tiomap-dev/+archive/release : probably needs some review if it is to be in-archive. [12:41] persia: so, I guess you need a way to identify the SoC because you want to use the same image on different platform? [12:41] hm [12:41] persia: one gets to wonder if it works with omap3 :D [12:41] ikepanhc, It's more than just SoC: for example, the Touchbook and the Beagle are both the same SoC, but different hardware. [12:41] apachelogger, Heh. No idea. [12:42] persia: ok :) [12:42] persia: ok, then for SoC, cpuinfo maybe not perfect but as I know, its the only one [12:43] persia: but for other device outside the SoC, I believe we need to probe them one by one [12:43] persia, the PPA one will go away, it has been reimplemented in .38 [12:43] ikepanhc, Thanks for the confirmation. Right now, we're using cpuinfo:Hardware, but we'll look at cpuinfo:Hardware+revision. If that's not enough, we might request more from the kernels :) [12:43] persia, touchbook is such a case as you ask for above, it is identical to beagle in all aspects [12:43] persia: some hardware designer will try to use gpio pins or ROM for identifying hardwares [12:44] persia: but there is no standard rule for this [12:44] apachelogger, Try the .38 omap3 kernel from the linux source package, and see if the wlan just works. [12:44] ikepanhc, Ah, OK. That makes it extra tricky. Thanks. [12:44] :) [12:44] well, I don't have much to try yet :D [12:44] though [12:45] I'll get an archos 101 it would seem [12:45] apachelogger: nice device [12:46] persia: i2c:50 on beagleboard will give you ID of extension board for example [12:46] a notion ink adam would still be nicer ^^ [12:47] ogra, So, I'm wondering if it's hubris to assume we can guess how to make a kernel bootable. I wonder if we wouldn't do well to catalog a set of post-install recipes, and then have the user select one (defaulting based on cpuinfo:Hardware)? [12:47] hmm, i would prefer to automate it more [12:48] I'm thinking that we have some conffile that specifies the recipe to use, and just reuse it reliably post-install. [12:49] So users would only encounter this on first install, when they are asked to confirm booting method: and it's just the confirmation for some devices, other devices would have to select an alternate method *OR* choose "none", and do it manually. [12:49] hmm, yeah [12:50] So, for the Touchbook/Beagle example, we default to Beagle, but someone with a Touchbook could select Touchbook. [12:51] Mind you, if they happen to be installing a kernel that doesn't have the support for the Touchbook, they will be unhappy, but that's a separate issue. [12:51] And once there is richer devicetree support, we could consider doing an analysis between current hardware and supported hardware, and informing the user if we believe they are installing a poor kernel for their device. [12:51] But that's not for Natty. [12:51] yep [12:52] NCommander, So, the above massively impacts your generic-subarch stuff. [12:53] Basically, we're not convinced that there is a useful relationship between detected-subarchitecture and recipe-to-make-just-installed-kernel-boot. [12:54] NCommander, Do you think we can leverage the generic-subarch spec to do as described above, or do you think we need to do something differently? [12:57] persia, doesn't ARM linux have a machine ID mechanism which had to be setup in the bootloader? [12:58] see http://www.arm.linux.org.uk/developer/machines/ [12:59] sveinse: but you can make kernel which boots on more then one machineID [13:00] sveinse, I don't believe we can see that from userspace, I'mo not convinced there's an identity relationship between that machine ID and the method by which the kernel is made bootable, and I know of devices (e.g. Sharp Netwalker) that do not have a registered unique machineID (which has caused issues with upstreaming support for that device) [13:00] Mind you, I'd be glad to be wrong :) [13:01] NCommander, Since you'll apparently encounter this in backscroll: the description of what I'd like to do starts at :47 [13:02] persia, It's probably true, though. We had a long discussion internally whether to register a public machine ID or not, since it would reveal info about a upcoming product [13:02] hrw, I think we would have cases where the same kernel would boot on multiple devices, using different recipes to make it bootable. [13:03] sveinse, I can't emphasize enough that you really want to have one registered in order to ensure support for the device can eventually go upstream. Use a funny codename, or something that otherwise is unidentifyable with any specifics. [13:04] I do embrace the Machine ID idea in all cases, because as you've said, without it you can't know reliably which HW you're on [13:05] Things like "rhino" or "snowball" or "guppy" or "spitz" don't tend to be very informative. [13:05] Even with it, it's not easy to know, but yeah :) [13:06] USB has it, PCI has it, even mobles phone all have systems for tracking the HW its running on [13:06] iirc PC has it as well via. the DMI [13:08] So you suggest that we ought to try to expose the machineID to userspace, and then claim there is an identity between machineID and recipe-for-kernel-postinstall-mangling? File bugs for devices without machineIDs? [13:10] I would love that yes, but I fear many boards/bootloaders don't set this ID properly [13:11] The machine type codename ("rhino", "snowball" etc.) is irrelevant. It's the number which should uniquely identify the HW. [13:13] And it would be nice if the machine id also could add a field for revision. Now I need to put in some custom mechanism for identifying the board revision to load the correct driver options, etc. [13:13] devicetree is better for that. [13:14] And in the absence of devicetree, a detection algorithm. [13:14] I still need to determine which HW revision I'm on. [13:15] I can probe, but that is implementation dependant. If I could get the revision along with the machine ID, it would be sufficient to inform the SW which HW its running on [13:15] I assert that you care which revision of each peripheral you have, rather than which revision of the board/retail device you have. [13:16] Which is why I claim machineID isn't the right place for that. [13:18] sorry, what do you mean? Machine ID identifies the HW, right? The HW revision number also follows the HW, so it's linked to the Machine ID [13:19] pluggable peripherals are IMHO another ballgame and needs its separate scheme for identification (like USB VID/PID) [13:19] I believe that non-pluggable peripherals ought be treated the same, for the most part. [13:19] Helps reduce duplication of code or special-casing when the same components are used on multiple boards, etc. [13:20] ah, I see. [13:20] That would require that the SoC implementors agreed upon some scheme for device ID on peripherals... [13:20] Yes. [13:21] good luck with convincing them of that [13:21] Well, rather that the board implementor happened to select components, all of which had some scheme for device ID implemented. [13:21] I second that, but doubt it will be easy to convince the mfgs [13:22] heh :) [13:23] When you port linux to a new SoC, you need to make the platform driver's list [13:23] what if you would have to put some pre-defined ID in here, a scheme like USB VID/PID? [13:23] maybe once windows arm devices start being sold [13:24] sveinse, Perhaps, but I'm thinking more about off-SoC peripherals. I'd much rather only have to identify SoC+revision than board+revision and then go hunt up a lookup table. [13:26] lilstevie, Why would that be different? The more so considering all the existing ARM devices that run various flavours of Windows? [13:27] persia, what kind of off-SoC peripherals are we talking about? this doesn't apply for USB at least [13:27] well once windows8 arm gets released that will push for uniform identification methods [13:28] sveinse, Being a software person, I probably have an incomplete picture: I've been presuming that the reason we care about per-machine stuff rather than just per-SoC stuff (with machineID) is that there exists some set of hardware that is on the board and not part of the SoC that is important for booting and initial bringup. I've no idea about the specifics. [13:29] persia, SoC+revision only identifies, well, the SoC. board+revision gives you the ability to know e.g. which gpio is connected to what. [13:29] possibility, not ability per se [13:30] Right, and it's that bit which I'd hope to have some way to identify without tracking board revisions. [13:31] I understand what you want, and I do agree, but I don't think the picture is that easy unfortunately [13:31] What complicates it? [13:32] Many SoC is capable of booting without support from other devices except memory [13:33] Take ethernet as one example: The phy may be external or internal to the phy, same applies to the MAC. You don't know that from a generic SW point of view while booting [13:33] I ment external or internal to the SoC [13:35] And these different implementation choices require different hinting to the drivers, in a way that the drivers cannot handle through discoverability? [13:36] s/discoverability/discovery/ [13:44] persia, essentially yes [13:46] I see. I don't much like it, but I think the right answer is to handle that with devicetree rather than trying to engineer something else currently, for all that means waiting a bit more. [13:46] iirc, the kernel uses the machine id to select which platform init to run. And the platform init (like arch/arm/mach-omap2/board-omap3beagle.c) sets up all the drivers and devices specific to the HW [13:47] That makes sense. [13:50] BTW: looking in the board-omap3beagle.c I find a function named omap3_beagle_init_rev() which actually probes some gpio pins for HW revision. -- Because the designers of the beagle board decided to place the HW revision scheme that way [13:52] When I come to think about it, it wouldn't help to have the HW revision number along the machineID from the bootloader, beacuse its "just" software. Then the bootloader would have to do some HW probing anyways, and then you're back were we started [13:53] oh how time flies... [13:54] * sveinse *leaving* [14:22] persia: efikamx smarttop support on its way to linaro-image-tools https://code.launchpad.net/~lool/linaro-image-tools/efikamx/+merge/50151 [14:41] lool, Cool. === 16WAAHT8Q is now known as ian_brasil [14:43] lool, I notice overo listed there as well. Is that working cleanly with the linaro builds? [14:44] persia: It is, albeit there is a kernel issue which has a patch [14:44] I think it's hdmi output or so [14:44] Your merge doesn't seem to have EfikamxConfig: that was already merged? [14:45] LP #660811 [14:45] Launchpad bug 660811 in linux "Display is not working on Gumstix Overo" [Undecided,Fix released] https://launchpad.net/bugs/660811 [14:45] persia: +class EfikamxConfig(Mx5Config): [14:45] 28 + uboot_name = 'efikamx' [14:45] +class EfikamxConfig(Mx5Config): [14:45] gah [14:45] persia: I see it [14:46] Am I reading 660811 correctly as fixed-in-maverick-open-in-natty? [14:48] Right. That's just me not understanding linaro-image-tools. Sorry. [14:51] persia: 660811 > yes [14:51] albeit I think the bug tasks are bogus [14:53] What's wrong with the bug tasks? [14:55] it says linux [14:55] I thought that omap3 kernels were produced by the linux source package for both maverick and natty. [14:58] right [14:58] just not for lucid [15:00] Yeah, but I think Andy is commenting for the Linaro kernel [15:01] Ah, so maybe it needs some linux-linaro tasks as well? [15:01] But we ought get that patch into linux anyway: regressions are bad. [15:02] I've checked all trees and added missing tasks [15:02] the linux task is still needed [15:06] hrw, just uploaded a little present for you ;) [15:12] ogra: flash-kernel finally? [15:12] :) [15:22] Bah I've just noticed that Ubuntu's flash-kernel doesn't remove tmpfiles it creates and has some insecure constructs like usage of tempfile + suffix [15:22] And needs a merge with upstream :) [15:24] upstream only adds unused arches [15:24] else i would have done it [15:25] There's some code-safety and syntax improvements as well. [15:25]