**** BEGIN LOGGING AT Thu Feb 17 02:59:58 2011 Feb 17 02:59:59 XorA|gone: you get a chance to fill in the pandaboard survey? Feb 17 03:00:16 prpplague: already done Feb 17 03:00:22 XorA|gone: dandy Feb 17 03:00:27 probably the only hope I have of getting one :-D Feb 17 03:00:45 a chronos watch? Feb 17 03:01:11 XorA|gone: you still haven't gotten a pandaboard? Feb 17 04:19:20 prpplague: nope Feb 17 04:19:30 * XorA|gone is now starting to hate hardware designers Feb 17 04:20:01 prpplague: thats not you BTW :D Feb 17 04:20:09 hehe **** BEGIN LOGGING AT Thu Feb 17 07:32:21 2011 Feb 17 09:00:58 flash-kernel needs changes for panda ;( Feb 17 09:01:17 1. 2.6.38-rc has "OMAP4 Panda board" not "OMAP4430 Panda Board" Feb 17 09:01:31 2. linaro kernel is 'omap' not 'omap4' flaovour Feb 17 09:42:06 hrw, you mean /proc/cpuinfo changed for panda? Feb 17 10:00:24 yes Feb 17 10:00:53 who knows, maybe one day there will be 4440 based panda Feb 17 10:42:51 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 Feb 17 10:43:14 easiest it to edit boot.scr Feb 17 10:47:36 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 Feb 17 10:48:43 I know Feb 17 10:52:10 well, -omap is tricky, tres is trivial Feb 17 10:52:18 s/tres/the rest/ Feb 17 10:52:35 * ogra doesnt get where the letters went, i definitely typed them Feb 17 10:53:18 I prefer to not touch flash-kernel. my changes ends in ogra's merge queue which is huge enough Feb 17 10:54:18 hrw, i will surely fix the cpuinfo bit but would appreciate a patch to handle the case where the package is named -omap Feb 17 10:54:52 i fear that will break NCommander's changes for generic kernel installation Feb 17 10:54:53 Why does flash-kernel limit which kernels can boot? Shouldn't it take the latest usefully installed kernel, and perform the appropriate action? Feb 17 10:55:24 hmm, wait, you are right, flash-kernel doesnt care for package names at all Feb 17 10:55:29 * ogra re-checks Feb 17 10:55:33 it cares for flavour names Feb 17 10:55:45 it shouldnt Feb 17 10:55:50 If it cares for flavour names, it needs to be fixed. Feb 17 10:55:54 then kill sub_arch check Feb 17 10:59:15 Hrm, but it ought care about subarch. Feb 17 11:00:31 persia, it does that since NCommander added his subarch stuff Feb 17 11:00:36 uname -r | sed -e 's/.*-//' Feb 17 11:00:59 it doesnt care for package names but for flavour in uname Feb 17 11:01:11 Right. Feb 17 11:01:12 which also breaks blaze Feb 17 11:02:28 Debian flash-kernel uses kfile to determine subarchi. Feb 17 11:02:50 With subarch=$(echo "$kfile" | sed -e 's/.*-//') Feb 17 11:04:58 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 Feb 17 11:07:21 flash-kernel require rewrite I think Feb 17 11:08:53 Ah, I see. if subarch="", check_subarch always returns true. Feb 17 11:11:35 that doesnt matter Feb 17 11:11:59 what matters is that check_subarch is completely ignored on dove omap and omap4 arches Feb 17 11:12:55 Ah, because there are no "machine" entries. I see. Feb 17 11:13:13 yep Feb 17 11:13:45 the prob is that instead of guessing for a proper kernel the code just makes it ignore the check Feb 17 11:14:00 and installs whatever kernel is available Feb 17 11:14:38 to be proper implemented it would need more of a database and some clever algorhythms to do guesswork Feb 17 11:15:27 Right. I see the issue now. flash-kernel is just entirely different for omap|omap4 than everything else, which is a bit confusing. Feb 17 11:15:50 a proper implementation would be possible with devicetree db's Feb 17 11:16:06 you could match kernel features against the actual hw Feb 17 11:16:38 How would that work? Feb 17 11:16:54 the kernel ships the devicetree data anyway Feb 17 11:17:34 so you iterate over the devices and match them against the actual HW of the board on your first run or from d-i Feb 17 11:18:14 if you find the kernel supports a) the arch and b) enough devices for booting, you write a flag Feb 17 11:18:30 that flag is looked up on flash-kernel run Feb 17 11:18:32 How does one define b) ? Feb 17 11:19:06 rootfs device, serial support and basic init ... you need a db for that indeed Feb 17 11:19:37 Why do we care about serial? How can we identify "basic init" for arbitrary boards? Feb 17 11:19:41 you could spill a warning if not everything is supported Feb 17 11:20:14 you cant you will always need a matching db about whats needed for init Feb 17 11:20:57 but that way you can at least support a wider range of HW without breaking it for totally unsupported stuff Feb 17 11:21:01 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. Feb 17 11:21:20 only for devices it has a machine file for Feb 17 11:21:39 I thought you would be able to specify a machine file on the kernel command line. Feb 17 11:21:59 you still have the toplevel subarch Feb 17 11:22:06 i.e. take the touchbook ... Feb 17 11:22:13 essentially its a beagle Feb 17 11:22:20 and you can use a beagle kernel on it Feb 17 11:22:26 but wont have much devices Feb 17 11:22:55 since the devices are special and never have been pushed upstream Feb 17 11:23:22 you will still be able to boot into serial with any std beagle kernel though Feb 17 11:25:18 So, let's say there is a device with necessary upstream support. Should that just work? Feb 17 11:26:07 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. Feb 17 11:26:13 (as the subarch isn't changing) Feb 17 11:28:10 it would be able to tell you that you only have minimal kernel support and optionally ask you about proceeding or not Feb 17 11:28:54 So, increase the verbosity of the "Generic Subarch" warning, and ask the user to confirm the operation? Feb 17 11:29:24 leave the user the option to not mess up his system Feb 17 11:31:09 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. Feb 17 11:31:13 How would that work? Feb 17 11:32:00 heh, well, if you run flash-kernel you already have a working system Feb 17 11:32:27 if you would run it on a kernel that drops features you surely would want a warning Feb 17 11:33:28 Yes, but if you run flash-kernel-installer, you may not have a working system yet. Feb 17 11:34:13 if you run flash-kernel-installer on such a system, d-i has a bug Feb 17 11:34:21 Huh? Why? Feb 17 11:34:31 it shouldnt install on unsupported HW Feb 17 11:34:49 actually the check should happen way way earlier Feb 17 11:36:14 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. Feb 17 11:37:06 and d-i (or whgatever else) politely tells you that you in max will run that device with a serial console Feb 17 11:37:08 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. Feb 17 11:37:13 or tell you its not supported at all Feb 17 11:37:20 or it just works Feb 17 11:37:24 If I'm booting a live image, there is no check. Feb 17 11:37:30 if I'm booting a pre-installed image, there is no check. Feb 17 11:37:42 right, we should add that to jasper Feb 17 11:37:53 jasper should probably leverage base-installer to do that. Feb 17 11:38:04 yes Feb 17 11:38:09 But there's still the live image case. Feb 17 11:38:12 its on my WI list Feb 17 11:38:17 Heh, OK. Feb 17 11:38:22 thats why i asked you about your tool in main ;) Feb 17 11:38:31 How is that related? Feb 17 11:38:43 device-detect gets me more detailed info Feb 17 11:38:51 Than what? Feb 17 11:39:04 archdetect (which is what base-installer uses) Feb 17 11:41:32 Please *don't* use devicetype-detect for that. Feb 17 11:41:49 You'd just be duplicating the test suite, etc. Feb 17 11:41:59 but i need to match against more detailed data than archdetect can deliver Feb 17 11:42:08 No you don't. Feb 17 11:42:16 jasper *is* duplicating stuff Feb 17 11:42:17 If you need more specificity, you need to get that into archdetect Feb 17 11:42:22 thats its whole purpose Feb 17 11:42:31 no, i dont Feb 17 11:42:33 I thought we had a UDS session about that. Feb 17 11:42:43 archdetect does exactly what its supposed to do Feb 17 11:42:44 And decided that jasper should *not* duplicate stuff. Feb 17 11:42:52 but doesnt get me enough data back Feb 17 11:43:11 jasper *has* to duplicate casper functions Feb 17 11:43:25 thats its whole purpose Feb 17 11:43:34 What data do you need? Feb 17 11:43:39 if you would check live images you would have to implement it in casper Feb 17 11:43:53 arch *and* device Feb 17 11:44:01 Why? Feb 17 11:44:15 because our kernels can support more than one device Feb 17 11:44:45 So, back to my story. Feb 17 11:44:56 I boot into the live image. Everything is working. I press install. Feb 17 11:45:05 and it would be clever to i.e. be able to shut off gdm if you detect you run on a beagle C4 Feb 17 11:45:12 It installs, the install runs flash-kernel installer. It installs the kernel that I booted. Feb 17 11:45:24 Why do I care if I'm using a device that you've never heard about? Feb 17 11:45:26 yeah, thats no issue Feb 17 11:45:37 It is if you care about device. Feb 17 11:45:51 Because if you care about device, you're going to tell me it doesn't work, and maybe try not to install. Feb 17 11:46:08 exactly Feb 17 11:46:29 So it is an issue, which is a bug. Let's look at another way to do it that doesn't have that problem. Feb 17 11:47:56 As I see it, we have two ways we can fail. Feb 17 11:48:15 We fail if we write a kernel to a device which can't use it, and render it unbootable. Feb 17 11:48:35 We fail if we refuse to work on a device on which the kernel works. Feb 17 11:48:40 Do you see any others? Feb 17 11:48:58 half way working devices Feb 17 11:49:10 and devices for which this image isnt suited Feb 17 11:49:29 (beagle C4 with a full desktop for example) Feb 17 11:49:39 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. Feb 17 11:49:56 we can adjust defaults Feb 17 11:50:11 I don't think that's being nice. Feb 17 11:50:33 if i turn off gdm on a C4 thats helping the user and gdm is still there to be started if he wants to Feb 17 11:50:38 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? Feb 17 11:50:49 they can Feb 17 11:51:11 and given they were clever enough to hack it that way i would trust them to find out how to re-renable gdm Feb 17 11:51:32 Anyway, we're getting sidetracked. Let's ignore all the defaults for now. Feb 17 11:52:05 So, about devices that only kinda work: is the failure if we boot our kernel, or if we don't boot our kernel? Feb 17 11:52:22 I'll claim the failure is to not boot the kernel, as otherwise we can never collect useful bug reports. Feb 17 11:52:46 yes, i agree Feb 17 11:52:55 but the user needs to know about it Feb 17 11:53:02 I've no issue with that. Feb 17 11:53:15 if you boot a kernel that has no display support at all the user needs to know that Feb 17 11:53:43 How can you tell the user this? There's no display... Feb 17 11:54:40 mors code on an LED :P Feb 17 11:54:44 *morse Feb 17 11:54:56 You're mad! Feb 17 11:55:04 no, indeed you are right, if we are in first boot that doesnt help Feb 17 11:55:05 Going back something useful. Feb 17 11:55:21 if i install a development kernel it does though Feb 17 11:55:32 So, we've booted the first time with a downloaded install image. Feb 17 11:55:51 right, that either boots or doesnt Feb 17 11:56:16 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. Feb 17 11:56:34 yes Feb 17 11:56:47 And I claim we can trust the user to have selected the appropriate input/output (serial console, KVM, etc.) for their needs. Feb 17 11:57:19 if the user sees it booting he should, yeah Feb 17 11:57:39 Next, we do the install steps (jasper/ubiquity/d-i). Feb 17 11:57:51 At this point, we end up calling flash-kernel-installer Feb 17 11:58:56 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. Feb 17 11:59:35 then flash-kernel-installer should have no checks at all Feb 17 11:59:36 Now, here's where it gets tricky. Feb 17 12:00:06 There's N different kernels in the archive, and K different ways to mangle the kernel to make it bootable. Feb 17 12:00:06 the point is that you need to identify the way the device boots Feb 17 12:00:38 in which case you again need the data about the device, not the arch Feb 17 12:00:39 So, we care about K, but not about N? Feb 17 12:01:41 you just said yourself, if we are booted from that kernel to a point where it works, we dont need to care about N Feb 17 12:02:03 flash-kernel will only dump the kernel in a different place Feb 17 12:02:09 the place is the point Feb 17 12:02:15 and that depends on the device data Feb 17 12:02:22 OK, so for that we want the machine info from CPUinfo Feb 17 12:02:34 right Feb 17 12:02:43 but probably even more Feb 17 12:02:52 i.e. beagle C4 vs XM Feb 17 12:02:59 And the abstraction of omap_flash_kernel and dove_flash_kernel only breaks things. Feb 17 12:03:05 cpuinfo doesnt identify the difference Feb 17 12:03:14 devicetype-detect doesn't. Feb 17 12:03:26 hmm, we should enhance it that way Feb 17 12:03:43 (actually, devicetype-detect only outputs strings like "netbook", "laptop", "desktop", "phone", etc. (even less detail)) Feb 17 12:04:13 No. The point of devicetype-detect is to add some flexibility to laptop-detect. Feb 17 12:04:18 device-name detect would be more intresting, yes Feb 17 12:04:43 devicename-detect has all sorts of arch-specific hackery, but for armel, just uses machine from cpuinfo. Feb 17 12:05:02 devicename-detect is mostly interesting because it has the equivalent collection for every architecture. Feb 17 12:05:15 So, again, that's no more information. Feb 17 12:05:17 it should have revision data Feb 17 12:05:27 cpuinfo has that. Devicename-detect doesn't care. Feb 17 12:05:27 or at least a switch to show it Feb 17 12:05:49 Parsing cpuinfo is significantly more robust. Feb 17 12:06:12 but exhausts what flash-kernel can do atm Feb 17 12:06:53 How do you mean? Feb 17 12:07:10 machine=$(grep "^Hardware" /proc/cpuinfo | sed 's/Hardware\s*:\s*//') Feb 17 12:07:22 Right. Feb 17 12:07:22 thats all that is matched against Feb 17 12:07:46 and not all boards ahve a revision in cpuinfo Feb 17 12:08:00 so you cant just blindly match against it Feb 17 12:08:39 You're saying that cpuinfo:Hardware doesn't have an identity relation to method-to-make-kernel-bootable? Feb 17 12:09:00 not on all boards Feb 17 12:09:07 thats the prob Feb 17 12:09:22 "OMAP3 Beagle Board" Feb 17 12:09:35 is returned for *all* beagles since revision A Feb 17 12:10:04 so you can have a 128M, 256M or 512M version with or without flash etc etc Feb 17 12:10:08 Is this a kernel bug, or is there additional information available that lets us identify the specific requirements for boot? Feb 17 12:10:29 no, thats a design decision from the manufacturer Feb 17 12:10:31 persia: it is not a kernel bug Feb 17 12:10:59 A3/B7/C3 are beagleboard. they just have different revision Feb 17 12:11:10 XM too Feb 17 12:11:29 ogra: never played with xM Feb 17 12:11:31 So, is there additional information available that lets us identify the specific requirements for boot? Feb 17 12:11:34 and you will see the same prob on panda Feb 17 12:11:54 though here its even worse since the kernel string changed between revisions Feb 17 12:12:14 would be intresting to know what the linaro kernel says on blaze or tablet Feb 17 12:12:29 or on the RIM tablet :) Feb 17 12:12:42 or the new LG phone ... Feb 17 12:12:53 So, is there additional information available that lets us identify the specific requirements for boot? Feb 17 12:13:30 not on beagle, i think there is a sysfs file somewhere and u-boot should know it too by poking some HW info Feb 17 12:13:45 but u-boot is gone at that point Feb 17 12:14:08 Do we know which sysfs file? Feb 17 12:14:16 no, i dont atm Feb 17 12:14:26 Because we ought to be checking that to define machine in flash-kernel/flash-kernel-installer, rather than cpuinfo:hardware Feb 17 12:14:28 and dont have either board around to check Feb 17 12:14:35 hrw, Any ideas? Feb 17 12:15:03 cpuinfo:hardware is ok for top level identification Feb 17 12:15:36 cpuinfo:hardware + cpuinfo:revision are nearly always present on arm Feb 17 12:15:50 No, it's useless, if there isn't an identity relation between that and technique-for-making-device-bootable Feb 17 12:16:17 hrw, does that pair have an identity relation to technique-for-making-device-bootable? Feb 17 12:16:24 persia: sorry, I didn't followed whole discussion Feb 17 12:16:41 persia: even hw+rev will not tell you do you need uImage or zImage. Feb 17 12:16:55 Ah, so yeah, that's not complete. Feb 17 12:17:00 beagleboard can have u-boot or Qi or barebox or anyother bootloader Feb 17 12:17:18 Basically, we need some way to know what method to use to make a device bootable. Feb 17 12:17:55 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. Feb 17 12:18:51 if you stick to 'this machine is ubuntu stock config' then hw+rev should work for most I think Feb 17 12:19:54 What do you mean by "ubuntu stock config"? Feb 17 12:20:12 granted that device runs known bootloader Feb 17 12:21:24 otherwise you will end in hell of providing uImage + zImage + wtfImage + .... + yabImage Feb 17 12:22:01 rim tablet may not be so easy to get your own kernel executing on Feb 17 12:22:05 I'm willing to pick a preferred bootloader on a per-device basis. Feb 17 12:22:12 lilstevie, Why? Feb 17 12:23:12 the playbook devel images are starting to show RSA 4096bit signatures Feb 17 12:23:58 Oh, annoying bootloader. I'm happy to ignore those devices. Feb 17 12:24:38 heh Feb 17 12:24:50 the galaxy tab is starting to do my head in too Feb 17 12:24:53 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. Feb 17 12:25:08 something really doesnt want to let X work on it Feb 17 12:25:47 if it is anything like iDevices someone will need to write a replacement bootloader for it Feb 17 12:25:48 ogra, Do you know of a case where Hardware+Revision matches two different devices with different requirements for flash-kernel? Feb 17 12:26:50 is there a way of getting greater detail on what is screwing with Xorg than -verbose 20 Feb 17 12:28:53 lilstevie, You might ask the folk in #ubuntu-x Feb 17 12:31:05 persia: ok thanks I asked over there Feb 17 12:36:51 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? Feb 17 12:36:56 did someone stacked beagles with pandas? Feb 17 12:37:12 do we have a tiwlan driver somewhere? Feb 17 12:38:13 persia: you need the list of device within SoC? Feb 17 12:38:48 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. Feb 17 12:39:19 Sorry for the confusion around the word "device" Feb 17 12:41:01 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. Feb 17 12:41:08 persia: so, I guess you need a way to identify the SoC because you want to use the same image on different platform? Feb 17 12:41:15 hm Feb 17 12:41:30 persia: one gets to wonder if it works with omap3 :D Feb 17 12:41:43 ikepanhc, It's more than just SoC: for example, the Touchbook and the Beagle are both the same SoC, but different hardware. Feb 17 12:41:53 apachelogger, Heh. No idea. Feb 17 12:42:31 persia: ok :) Feb 17 12:42:53 persia: ok, then for SoC, cpuinfo maybe not perfect but as I know, its the only one Feb 17 12:43:15 persia: but for other device outside the SoC, I believe we need to probe them one by one Feb 17 12:43:17 persia, the PPA one will go away, it has been reimplemented in .38 Feb 17 12:43:42 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 :) Feb 17 12:43:49 persia, touchbook is such a case as you ask for above, it is identical to beagle in all aspects Feb 17 12:43:52 persia: some hardware designer will try to use gpio pins or ROM for identifying hardwares Feb 17 12:44:16 persia: but there is no standard rule for this Feb 17 12:44:21 apachelogger, Try the .38 omap3 kernel from the linux source package, and see if the wlan just works. Feb 17 12:44:33 ikepanhc, Ah, OK. That makes it extra tricky. Thanks. Feb 17 12:44:41 :) Feb 17 12:44:43 well, I don't have much to try yet :D Feb 17 12:44:47 though Feb 17 12:45:04 I'll get an archos 101 it would seem Feb 17 12:45:24 apachelogger: nice device Feb 17 12:46:07 persia: i2c:50 on beagleboard will give you ID of extension board for example Feb 17 12:46:15 a notion ink adam would still be nicer ^^ Feb 17 12:47:08 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)? Feb 17 12:47:51 hmm, i would prefer to automate it more Feb 17 12:48:26 I'm thinking that we have some conffile that specifies the recipe to use, and just reuse it reliably post-install. Feb 17 12:49:17 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. Feb 17 12:49:51 hmm, yeah Feb 17 12:50:40 So, for the Touchbook/Beagle example, we default to Beagle, but someone with a Touchbook could select Touchbook. Feb 17 12:51:02 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. Feb 17 12:51:33 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. Feb 17 12:51:36 But that's not for Natty. Feb 17 12:51:54 yep Feb 17 12:52:36 NCommander, So, the above massively impacts your generic-subarch stuff. Feb 17 12:53:18 Basically, we're not convinced that there is a useful relationship between detected-subarchitecture and recipe-to-make-just-installed-kernel-boot. Feb 17 12:54:44 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? Feb 17 12:57:59 persia, doesn't ARM linux have a machine ID mechanism which had to be setup in the bootloader? Feb 17 12:58:59 see http://www.arm.linux.org.uk/developer/machines/ Feb 17 12:59:02 sveinse: but you can make kernel which boots on more then one machineID Feb 17 13:00:15 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) Feb 17 13:00:55 Mind you, I'd be glad to be wrong :) Feb 17 13:01:46 NCommander, Since you'll apparently encounter this in backscroll: the description of what I'd like to do starts at :47 Feb 17 13:02:24 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 Feb 17 13:02:47 hrw, I think we would have cases where the same kernel would boot on multiple devices, using different recipes to make it bootable. Feb 17 13:03:48 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. Feb 17 13:04:48 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 Feb 17 13:05:08 Things like "rhino" or "snowball" or "guppy" or "spitz" don't tend to be very informative. Feb 17 13:05:23 Even with it, it's not easy to know, but yeah :) Feb 17 13:06:24 USB has it, PCI has it, even mobles phone all have systems for tracking the HW its running on Feb 17 13:06:57 iirc PC has it as well via. the DMI Feb 17 13:08:50 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? Feb 17 13:10:07 I would love that yes, but I fear many boards/bootloaders don't set this ID properly Feb 17 13:11:52 The machine type codename ("rhino", "snowball" etc.) is irrelevant. It's the number which should uniquely identify the HW. Feb 17 13:13:21 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. Feb 17 13:14:00 devicetree is better for that. Feb 17 13:14:15 And in the absence of devicetree, a detection algorithm. Feb 17 13:14:35 I still need to determine which HW revision I'm on. Feb 17 13:15:21 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 Feb 17 13:15:56 I assert that you care which revision of each peripheral you have, rather than which revision of the board/retail device you have. Feb 17 13:16:09 Which is why I claim machineID isn't the right place for that. Feb 17 13:18:04 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 Feb 17 13:19:03 pluggable peripherals are IMHO another ballgame and needs its separate scheme for identification (like USB VID/PID) Feb 17 13:19:31 I believe that non-pluggable peripherals ought be treated the same, for the most part. Feb 17 13:19:49 Helps reduce duplication of code or special-casing when the same components are used on multiple boards, etc. Feb 17 13:20:03 ah, I see. Feb 17 13:20:42 That would require that the SoC implementors agreed upon some scheme for device ID on peripherals... Feb 17 13:21:00 Yes. Feb 17 13:21:36 good luck with convincing them of that Feb 17 13:21:50 Well, rather that the board implementor happened to select components, all of which had some scheme for device ID implemented. Feb 17 13:21:51 I second that, but doubt it will be easy to convince the mfgs Feb 17 13:22:12 heh :) Feb 17 13:23:04 When you port linux to a new SoC, you need to make the platform driver's list Feb 17 13:23:30 what if you would have to put some pre-defined ID in here, a scheme like USB VID/PID? Feb 17 13:23:39 maybe once windows arm devices start being sold Feb 17 13:24:53 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. Feb 17 13:26:39 lilstevie, Why would that be different? The more so considering all the existing ARM devices that run various flavours of Windows? Feb 17 13:27:16 persia, what kind of off-SoC peripherals are we talking about? this doesn't apply for USB at least Feb 17 13:27:23 well once windows8 arm gets released that will push for uniform identification methods Feb 17 13:28:57 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. Feb 17 13:29:25 persia, SoC+revision only identifies, well, the SoC. board+revision gives you the ability to know e.g. which gpio is connected to what. Feb 17 13:29:57 possibility, not ability per se Feb 17 13:30:18 Right, and it's that bit which I'd hope to have some way to identify without tracking board revisions. Feb 17 13:31:24 I understand what you want, and I do agree, but I don't think the picture is that easy unfortunately Feb 17 13:31:55 What complicates it? Feb 17 13:32:24 Many SoC is capable of booting without support from other devices except memory Feb 17 13:33:22 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 Feb 17 13:33:37 I ment external or internal to the SoC Feb 17 13:35:02 And these different implementation choices require different hinting to the drivers, in a way that the drivers cannot handle through discoverability? Feb 17 13:36:28 s/discoverability/discovery/ Feb 17 13:44:29 persia, essentially yes Feb 17 13:46:04 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. Feb 17 13:46:36 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 Feb 17 13:47:37 That makes sense. Feb 17 13:50:53 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 Feb 17 13:52:41 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 Feb 17 13:53:56 oh how time flies... Feb 17 13:54:02 * sveinse *leaving* Feb 17 14:22:02 persia: efikamx smarttop support on its way to linaro-image-tools https://code.launchpad.net/~lool/linaro-image-tools/efikamx/+merge/50151 Feb 17 14:41:49 lool, Cool. Feb 17 14:43:43 lool, I notice overo listed there as well. Is that working cleanly with the linaro builds? Feb 17 14:44:17 persia: It is, albeit there is a kernel issue which has a patch Feb 17 14:44:25 I think it's hdmi output or so Feb 17 14:44:48 Your merge doesn't seem to have EfikamxConfig: that was already merged? Feb 17 14:45:06 LP #660811 Feb 17 14:45:08 Launchpad bug 660811 in linux "Display is not working on Gumstix Overo" [Undecided,Fix released] https://launchpad.net/bugs/660811 Feb 17 14:45:28 persia: +class EfikamxConfig(Mx5Config): Feb 17 14:45:34 28 + uboot_name = 'efikamx' Feb 17 14:45:34 +class EfikamxConfig(Mx5Config): Feb 17 14:45:41 gah Feb 17 14:45:45 persia: I see it Feb 17 14:46:48 Am I reading 660811 correctly as fixed-in-maverick-open-in-natty? Feb 17 14:48:14 Right. That's just me not understanding linaro-image-tools. Sorry. Feb 17 14:51:13 persia: 660811 > yes Feb 17 14:51:21 albeit I think the bug tasks are bogus Feb 17 14:53:22 What's wrong with the bug tasks? Feb 17 14:55:12 it says linux Feb 17 14:55:54 I thought that omap3 kernels were produced by the linux source package for both maverick and natty. Feb 17 14:58:14 right Feb 17 14:58:17 just not for lucid Feb 17 15:00:23 Yeah, but I think Andy is commenting for the Linaro kernel Feb 17 15:01:28 Ah, so maybe it needs some linux-linaro tasks as well? Feb 17 15:01:43 But we ought get that patch into linux anyway: regressions are bad. Feb 17 15:02:08 I've checked all trees and added missing tasks Feb 17 15:02:11 the linux task is still needed Feb 17 15:06:38 hrw, just uploaded a little present for you ;) Feb 17 15:12:34 ogra: flash-kernel finally? Feb 17 15:12:46 :) Feb 17 15:22:07 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 Feb 17 15:22:55 And needs a merge with upstream :) Feb 17 15:24:22 upstream only adds unused arches Feb 17 15:24:29 else i would have done it Feb 17 15:25:15 There's some code-safety and syntax improvements as well. Feb 17 15:25:34 ogra: what did you do of the check_subarch part in the end? Feb 17 15:25:40 lool, have you seen initramfs-tools upstreams comment on the bug i files about create vs update ? he claims that the kernel should ship the scripts that call update-initramfs and flash-kernel Feb 17 15:25:49 lool, nothing yet Feb 17 15:25:58 i need the right data first Feb 17 15:26:14 * ogra hasnt run .38 yet Feb 17 15:26:43 lool, and i have no real idea what to do about -omap vs -omap4 atm Feb 17 15:27:35 Could we just allow *both* "omap" and "omap4" for omap4 hardware? Feb 17 15:27:48 its about the uname check Feb 17 15:27:52 Or does this go back to the earlier discussion, and I should ignore it this time? Feb 17 15:28:04 not sure Feb 17 15:28:17 its quick fix vs proper implementation i think Feb 17 15:28:27 the latter is as you stated not natty Feb 17 15:28:33 What? Feb 17 15:28:47 I said that doing devicetree mapping of capabilities was not-natty. Feb 17 15:29:00 there are three subarch concepts in Ubuntu's flash-kernel (and two in Debian's) Feb 17 15:29:20 lool, yes, the third one is NCommander's subarch detection Feb 17 15:29:27 I don't see any reason not to do selectable-recipe for natty, as the generic-subarch spec is still pending, and I no longer believe that solves the actual problem it was intended to solve. Feb 17 15:29:54 which as i stated above in the discussion just a way of ignoring subarch detection and spilling a message on certain arches Feb 17 15:29:56 one is uname -r (running_subarch), Ubuntu-only, one is the sufix of the vmlinuz which we're about to install, and the third one is the subarch name which we use for the platform Feb 17 15:30:17 then there are four, not three Feb 17 15:30:33 What? Where is the fourth? Feb 17 15:30:52 my personal preference would be to never use uname, and to change flash-kernel to create a flash-kernel.conf on install or upgrades which documents the kernel which one prefers to run Feb 17 15:31:16 Where are the logs for this channel located? Feb 17 15:31:38 persia, two debian ones, plus ubuntus vmlinuz plus ignoring arch check completely on dove, omap and omap4 Feb 17 15:31:41 I'd also like to add selectable-flash-recipe to that conffile, and get away from the tight integration of machine and flash-recipe. Feb 17 15:32:17 sveinse: usually irclogs.ubuntu.com is the place for ubuntu chans Feb 17 15:32:26 ogra, No. $running_subarch is the one that is used to ignore things. It's not a fourth one. Feb 17 15:32:58 lool, agreed Feb 17 15:33:26 persia: Yeah; I'm not sure how much should be configurable, but I think there should be a recipe or "method" concept for installign the kernel, e.g. NAND vs MMC Feb 17 15:33:49 persia: I've actually started work on cleaning up flash-kernel upstream; I'm not at the method part yet, but I made good progress on the rest Feb 17 15:34:09 In the earlier discussion, we use the Touchbook vs. the Beagle as an example, where someone might want to have different install recipes for the same reported hardware. Feb 17 15:35:12 Obviously, we should default to the sensible recipe for the detected hardware, but in cases where it's uncertain, or cases where there are choices, or cases where the hardware is unknown at release time (but the user knows a supplied recipe works), the user can still do something useful. Feb 17 15:36:59 Yeah Feb 17 15:37:37 flash-kernel basically needs extension and configuration points; it's just hard to get these right and not end up with a very painful to maintain system Feb 17 15:37:53 or risking to break systems Feb 17 15:37:55 * ogra is eager to see functions and hw database separated as a first step Feb 17 15:38:08 that's what I'm working on ATM Feb 17 15:38:11 it's really a lot of work though Feb 17 15:38:14 cool ! Feb 17 15:38:20 yeah Feb 17 15:38:23 lool, still in bash ? Feb 17 15:38:32 well, in POSIX shell Feb 17 15:38:33 hopefully Feb 17 15:38:42 janimo: I don't really mind :-) Feb 17 15:38:48 there are some painful points I admit Feb 17 15:39:03 * ogra prefers shell Feb 17 15:39:04 but I always liked shell, I'm a bit of a masochist Feb 17 15:39:11 well it i s great for the seemless integration with the OS and running commands, but it is not a sane programming language Feb 17 15:39:29 part of the reason why flash-kernel is spaghetti Feb 17 15:39:45 I tend to disagree Feb 17 15:39:55 Debian's flash-kernel is actually readable, just has a lot of code duplication Feb 17 15:40:09 and I would hope my reworked code is even more readable Feb 17 15:40:20 ubuntu isnt so much Feb 17 15:40:46 thats the issue ... we added on top of debians and not always in the most appropriate way Feb 17 15:43:16 janimo: Another quite sad choice is to intend everything with a tab; it makes it really hard to read when code gets nested a bit :-/ Feb 17 15:55:30 lool: just adjust your tabstop to 2 or something; its why I prefer tabs to spaces Feb 17 15:56:49 NCommander, So, about generic subarch and the lack of apparent relationship between SoC and flashing-recipe. What's your opinion? Feb 17 15:57:45 persia: I'm not quite sure I follow Feb 17 15:58:40 So, based on the set of devices seen, there seems to be no useful relationship between the SoC and the recipe required to ensure that the available kernel is used for the next boot. Feb 17 15:59:27 NCommander, did you read backlog of the last hours ? Feb 17 15:59:31 And you're working on this generic-subarch spec, which seems to focus on providing a good installation experience regardless of whether the device is one that happens to be certified in some way. Feb 17 15:59:45 (if not, i would suggest to do so) Feb 17 15:59:52 ogra: I didn, but still confused Feb 17 16:00:15 persia: I disagree, the install scripts should be smart enough to detect what's present and properly install based on that Feb 17 16:01:07 What sort of detection do you imagine? Feb 17 16:03:15 Specifically, I don't see how we can determine the bootloader configuration in a safe or repeatable manner, especially for devices where we aren't installing the bootloader. Feb 17 16:03:42 persia: on devices we support, we assume the bootloader is uboot, and its installed to the SD card or NAND Feb 17 16:04:09 its straightforward to check if the bootloader is there, and if so, write boot files Feb 17 16:04:15 So, why does ogra claim this breaks some devices? Feb 17 16:04:44 it breaks the blaze Feb 17 16:05:03 ogra: ?, for blaze we simply write to SD card, same as panda Feb 17 16:05:21 doesnt work with emmc Feb 17 16:05:27 the device names are different Feb 17 16:05:35 you have assigned the bug, read it Feb 17 16:06:44 ogra: we don't support using the eMMC, nor have we ever. The block device is written out by flash-kernel-installer into a confiugration file Feb 17 16:07:00 * ogra sighs Feb 17 16:08:23 ogra: am I wrong about supportng the eMMC for booting? Feb 17 16:08:42 it should not break at least,. please read the bug Feb 17 16:08:53 ogra: care to provide a link? Feb 17 16:08:53 it think it was discussed teher since maverick Feb 17 16:11:30 * GrueMaster looks Feb 17 16:11:35 ogra: and my work mostly beeon of dove until this cycle, and then on panda; I don't even have a blaze; I have to borrow GrueMaster's Feb 17 16:12:37 I think it is Bug #626749 Feb 17 16:12:38 Launchpad bug 626749 in flash-kernel "flash-kernel tries to use MTD devices on OMAP4 when no flash-kernel.conf exists" [Medium,Confirmed] https://launchpad.net/bugs/626749 Feb 17 16:12:46 So, specifics aside, can we not imagine a device that should just work that doesn't have an identical recipe to make a kernel boot? Feb 17 16:13:24 * NCommander can't Feb 17 16:14:00 What about Touchbook & Beagle, discussed earlier. Feb 17 16:14:14 Apparently they have the same cpuinfo Feb 17 16:14:22 persia: The hard part about this is platform availability. Feb 17 16:14:34 GrueMaster, Why? Feb 17 16:14:34 If you don't have one, makes it hard to support. Feb 17 16:14:39 persia: already handled by existing code. If the bootloader is on an SD card already, flash-kernel writes to the SD card, else it tries to write to NAND Feb 17 16:15:07 the bug GrueMaster references is simply the code tries to write to NAND unconditionally if theres no configuration info Feb 17 16:15:10 which is a bug Feb 17 16:15:18 NCommander: That assumes /etc/flash-kernel.conf. Feb 17 16:15:33 GrueMaster: which exists if somene installed with one of our images Feb 17 16:15:40 GrueMaster, Why? The point of a flexible architecture is that it allows one to support anything that doesn't work (and accept fixes to tune that). An inflexible model only supports that which was tested and verified. Feb 17 16:16:38 persia: I was referring to the current code, which is not flexible. Feb 17 16:18:00 Well, it's worse than that: parts of it are inflexible, and other parts simply assume a recipe works because it's "dove" or "omap" or "omap4" Feb 17 16:18:04 persia, beagle C vs XM Feb 17 16:18:15 ogra, What's the difference in recipe for those? Feb 17 16:18:16 stop using the touchbook example ;) Feb 17 16:18:30 NAND vs SD boot Feb 17 16:18:35 persia: Beagle C has nand, XM doesn't. Feb 17 16:18:37 identical cpuinfo Feb 17 16:18:43 Physically. Feb 17 16:18:47 ogra: same rev too? Feb 17 16:18:52 Better example. Feb 17 16:19:05 ogra: GrueMaster: so you detect for NAND and use it if its available if something isn't set in flash-kernel.conf Feb 17 16:19:45 NCommander: how you check for nand? Feb 17 16:19:54 NCommander: /proc/mtd? Feb 17 16:20:20 Even our current images are broken wrt beagle C. If the Beagle has had Lucid installed (or anything else that used nand), our current images will fail as they are set to boot from sd only. Feb 17 16:20:28 hrw: yeah and the device in /dev/* Feb 17 16:20:45 NCommander: "modprobe mtdram" and your test will fail Feb 17 16:20:50 Indeed. Feb 17 16:21:22 Alternately, modprobe nandsim Feb 17 16:22:04 Will that work in the case of Tegra? Feb 17 16:22:33 Tegra will hit the hardcoded path Feb 17 16:22:38 Or other systems where the user may not want to kill nand? Feb 17 16:23:54 persia: so you think then generic subarch should die and shelf it as a spec? Feb 17 16:24:16 Well, I'm not sure about that. Feb 17 16:24:40 The more I think about available devices, the more I think that the set of recipes doesn't map well to the set of subarchitectures. Feb 17 16:24:43 persia: you've just made a very convincing case that its not going to have a wide swatch of support Feb 17 16:24:54 persia: right Feb 17 16:25:05 And so while I'm hugely in favour of the goal of making it just work on arbitrary devices, I wonder if splitting by subarch is the right way to do that. Feb 17 16:25:44 NCommander, it shouldnt die but needs more detailed testing for devices Feb 17 16:26:00 So I guess I wonder if you'd be interested in doing some sort of recipe-mapping model rather than a subarch-mapping model in your work for natty. Feb 17 16:26:15 pI dropped out of Mileage Plus years ago after flying 300,00 revenue miles as a 1k or at the mid tier level over 5 years ago.Moved all my business to AA/ One World where I am far happier with fairness on redemption. Feb 17 16:26:20 I would like to go back to UA so I am monitoring the situation but stll feel UA is too stingy with seats to justify switching back.But if the Starnet blocking scenario is over they may have lifted the largest issue off the platform Feb 17 16:26:24 I will be monitoring the situation .Thanks for the heads up all Feb 17 16:26:27 argh Feb 17 16:26:28 I really need to hack Xorg.conf and remove this stupid pasting behavior Feb 17 16:26:48 ?? Feb 17 16:27:07 persia: a lot of boards can't be easily told apart, Beagle and BeagleXM both identify themselves as Beageboard in /proc/cpuinfo Feb 17 16:27:12 heh, yeah, you should Feb 17 16:27:45 NCommander, Right, and I've come to believe that this is even more widely true in retail devices based on various platforms. Feb 17 16:27:50 NCommander, right, so we need to find a better solution on top of the cpuinfo Feb 17 16:28:02 cpuinfo is good but not enough Feb 17 16:28:04 So, because we can't tell them apart, we should provide a menu of recipes, and default best we can. Feb 17 16:28:09 And leave the rest for documentation. Feb 17 16:28:25 persia: ugh, that's fugly, and adds a lot of complexity to user installs Feb 17 16:28:43 For most users, it should be pressing enter once for confirmation. Feb 17 16:29:05 persia: for most users, they won't know the difference Feb 17 16:29:12 For a few users, it may be more complicated, but the alternative is to force them to hack things together manually. Feb 17 16:29:16 Maybe using a separate conf file would be better. That way, it can be more easily updated without package rebuilding. Feb 17 16:29:18 If we can't do it automatically, then I rather not do it Feb 17 16:29:19 i would prefer better automation before we resort to interaction Feb 17 16:29:30 but its a good last resort Feb 17 16:29:35 And we already have too many complaints about stuff that we know is broken because someone didn't perform a regular install. Feb 17 16:29:50 By conf file, I mean a file with a list of supported platforms that can be easily updated. Feb 17 16:30:05 I'm happy with something like debconf-priority-low: adjustable, but not shown by default. Feb 17 16:32:03 looks like you will end with database keeping lot of scripts which will check which exactly hardware it is run on Feb 17 16:33:13 like "if cpuinfo=beagleboard and amount-of-ram=256M then Cx elseif amount-of-ram=512M and lsusb |grep ID-OF-SMSC then beaglexm else ax/bx" Feb 17 16:33:24 Why? Feb 17 16:34:08 I imagine having install-to-NAND, install-to-SD, etc. Just a few recipes. Then, some routine that picks a reasonable recipe. Feb 17 16:34:45 The biggest problem is system identification. cpuinfo just isn't always enough. Feb 17 16:35:36 it is enough as a base but not for details Feb 17 16:36:10 let me get this right: The problem is how to write the kernel image into NAND or MMC (FAT partition) or similar, right? Feb 17 16:36:31 Kinda. Feb 17 16:36:54 More of how to detect which to use. Feb 17 16:37:08 There's a script (flash-kernel) that gets called when a new kernel is installed. This script needs to do something to convert the unpacked kernel .deb into something that is being booted on the device. Feb 17 16:39:44 interesting and challenging. I've made a manual post-kernel-install script to move it to the FAT partition (use mmc boot) which surely isn't an elegant solution Feb 17 16:41:04 * sveinse wish the HW bootloader in the SoC could read sector 0 from NAND or MMC and behave like a PC bootloader. Maybe. Feb 17 16:42:17 sveinse, Take a look at the flash-kernel package. Both flash-kernel and debian/flash-kernel-installer-postinst are interesting. Feb 17 16:44:07 * sveinse is reinventing the wheel... Feb 17 16:45:41 Can't have that :) Feb 17 16:47:25 more wheels !!! Feb 17 16:47:25 hrw, amount-of-ram might not be the best, there's "white label" c4 boards with 512Mb. ;) Feb 17 16:47:51 ~/cr Feb 17 16:48:01 rcn-ee_at_work: nice Feb 17 16:49:40 I'm a little curious about bug 705689. Does anyone knows if this will result in a patch & update for armel-cross 4.5 ? Feb 17 16:49:41 Launchpad bug 705689 in gcc-4.5 "QT applications crash with segfault error on armel when QT is built with gcc 4.5 on natty" [High,Confirmed] https://launchpad.net/bugs/705689 Feb 17 16:49:48 sveinse: It's relatively close to what happens, problem is that every SoC needs a different first piece of code to run, to setup the DDR for instance Feb 17 16:49:48 hrw, you can get it from dmesg, since the gpio detect is printed out.. Feb 17 16:50:14 hrw, dmesg | grep "Beagle Rev:" Feb 17 16:50:27 rcn-ee_at_work: how you check dmesg on machine which works for 2 months and have /var/log/dmesg removed? Feb 17 16:51:35 lool, the FAT load from MMC is a HW bootloader implementation in OMAP, iirc Feb 17 16:51:36 hrw, not easy.. userspace progam to read all 3 gpio pins? Feb 17 16:53:03 hrw, if you know your on a beagle... looks at "cat /proc/cpuinfo" the xM is "CPU variant : 0x3" the Bx/Cx should be "CPU variant : 0x1" Feb 17 16:53:22 sveinse: That's correct, but DDR isn't setup at this point; it's setup by this piece loaded from MMC ("MLO"); the ROM could technically set it up if it was padded in some special ways, but that's a different config block from SoC to SoC Feb 17 16:53:37 sveinse: So concretely, you have different constraints on the data / location from different SoCs Feb 17 16:53:54 You could arrange for writing the first sectors on a lot of SoCs though Feb 17 16:54:53 lool: WOuld it make sense for MLO to setup an area in memory that could be read by userspace similar to dmidecode? Feb 17 16:55:49 hrw, yeap it is.. http://pastebin.com/5WP3TSiK (comparsion of c4/xM) Feb 17 16:57:21 Something like dmidecode would be nice. I wish all architectures had it. Feb 17 16:57:47 thats easy Feb 17 16:58:03 just add a BIOS to all arches :) Feb 17 16:58:07 well, the dmi info is actually in concept the same as the machine id we talked about earlier Feb 17 16:58:35 GrueMaster: what kind of data do you intend to provide? Feb 17 16:58:49 I think UEFI has provisions to pass various data Feb 17 16:58:49 lool, device lists ? Feb 17 16:58:56 rcn-ee_at_work: thx Feb 17 16:59:03 Well, concerning tables of devices, we're leaning towards device tree Feb 17 16:59:10 rsalveti: around? Feb 17 16:59:10 lool, i think devicetree will solve that anyway Feb 17 16:59:11 Basic hardware info, similar to what dmidecode provides. Like what busses are available, what the system is, etc. Feb 17 16:59:25 If/when it appears. Feb 17 16:59:27 ogra: I have x86 which does not use efi and can be booted even without bios Feb 17 16:59:33 lool, Will I be able to get stuff like Manufacturer, Product Name, etc. from devicetree? Feb 17 16:59:39 I have been hearing about devicetree since 2009. Feb 17 16:59:41 hrw, pfft, prototypes Feb 17 17:00:14 hrw, btw, my booking is finally confirmed i'll arrive on sunday evening Feb 17 17:00:20 ogra: no, on-the-shelf hardware Feb 17 17:00:38 ogra: with coreboot Feb 17 17:00:45 persia: I'm not sure about these specific things; it's mainly to describe the hardware layout, but I'm pretty sure it would be easy to have the information Feb 17 17:01:06 hrw, how do you remove the BIOS from that ? Feb 17 17:01:15 In all cases, having dmiinfo or devicetree, will imply that the MLO or bootloader must setup the information uniquely for each HW and revision. Feb 17 17:01:21 hrw: The difference there is all x86 cpu's fetch from the same location for booting. Not so with arm. Feb 17 17:01:42 sveinse: Correct, or the firmware Feb 17 17:01:59 ogra: coreboot ;D Feb 17 17:02:07 GrueMaster: ah but you define booting as after the BIOS Feb 17 17:02:17 lool, OK. That's the information I wanted from dmidecode, but I don't really care where I get it. Feb 17 17:02:22 ogra: coreboot can load filo or grub as payload without any bios legacy stuff Feb 17 17:02:35 hrw, i know coreboot, i worked with it in the past Feb 17 17:02:39 lool: No I don't. I define booting as after the cpu is initialized ant goes external to fetch code. Feb 17 17:02:51 hrw, still there is a BIOS coming up on the boards i used it Feb 17 17:03:04 unless you remove the eprom probably Feb 17 17:03:21 yes, so in that respect, this bootloader or firmware which prepares the machine for kernel boot, is a BIOS per definition. It could provide the information needed for flash-kernel Feb 17 17:03:23 Or flash coreboot into the eeprom Feb 17 17:04:07 sveinse, The complicated thing is that the ARM community doesn't tend to favour two-stage bootloaders, but wants an all-in-one solution, including both full init *AND* kernel load. Feb 17 17:04:49 Some devices support OpenFirmware, and some second-stage bootloaders were ported in the past, but nothing recent has separated stages. Feb 17 17:05:37 persia, I have yet too see a SoC device booting directly into linux kernel. All I've encountered so far have two stage boots Feb 17 17:06:18 As lool said, the DDR needs to be setup and the kernel command line, and so on by the bootloader Feb 17 17:07:14 sveinse: iirc on omap3 you can add header to kernel image which will setup ddr etc (which xloader does normally) and boot Feb 17 17:07:26 sveinse: kernel cmdline needs to be hardcoded in kernel Feb 17 17:07:54 only on 3530, not ? Feb 17 17:08:00 it is? hmm. I need to check my sources... Feb 17 17:08:28 sveinse, I heard of some demos about it, but you mean "two-stage" to be bootloader/kernel. When I talk about "two-stage" bootloaders, I'm talking about the sort of thing we see for x86, powerpc, sparc, etc. where one uses one codebase to init, launches to another codebase for kernel selection, and then loads the kernel. Feb 17 17:08:48 ah, then I agree Feb 17 17:09:11 bios -> grub -> kernel or chiprom -> xloader -> uboot -> kernel... Feb 17 17:09:18 So, EFI/grub or OF/yaboot, etc. (although I think we'll switch to OF/grub for natty powerpc, but I may be mistaken) Feb 17 17:09:21 persia: On x86 images, we currently have 3 stages: bios, bootloader (lilo, grub, etc), kernel. Feb 17 17:09:41 It is possible for x86 to have one: Linux-bios. Feb 17 17:09:47 anyway it is time for me Feb 17 17:09:47 In fact when doing OMAP MMC boot its 3 stages as well: MLO -> Uboot -> Kernel Feb 17 17:10:04 sveinse: mlo is read by inchip code Feb 17 17:10:17 On SOC's, most fetch from an internal rom on the SOC, then fetch from there. Feb 17 17:10:28 hrw, do you know anything about the 4.5 gcc bug in respect of Qt? Feb 17 17:10:33 sveinse, Indeed. OMAP is the closest we have to sanity, but it's still not quite there: lots of messiness in MLO, and Uboot could be doing a lot more than it does in that context. Feb 17 17:10:33 sveinse: no Feb 17 17:10:44 * hrw -> out Feb 17 17:10:50 have a nice rest of day people Feb 17 17:11:08 Actually omap/omap4 is 4 stage by that logic: SoC ROM, MLO, u-boot, kernel. Feb 17 17:12:08 The SoC ROM is stage-0, by my nomenclature. Feb 17 17:12:18 x86 BIOS would be stage-1 Feb 17 17:12:24 Ok, in binary you are correct. Feb 17 17:12:25 silo would be stage-2 Feb 17 17:12:33 :p Feb 17 17:12:39 We are (for boottime reasons) considering to skip the MLO -> uboot part of the boot. I.e. let the MLO image load the kernel itself with a small init function for setting up the magic things like DDR & co Feb 17 17:12:54 X86 always fetches from CS:IP F000:FFF0 Feb 17 17:13:09 Or the end of 1M. Feb 17 17:13:10 uboot is not efficient if you are waiting for it :D Feb 17 17:16:26 GrueMaster: If ARM always fetched from the same addr, would that help us in any way? Feb 17 17:16:37 Might. Feb 17 17:17:32 I don't know much about arm architecture, but I believe it may already. Just most SoC vendors put rom code there on die. Feb 17 17:17:43 Which can't be changed. Feb 17 17:18:10 Because the BIOS or whatever you name it, will always contain the board specific initialization which is the same that we do in our bootloaders Feb 17 17:18:15 With x86, it is the flash-rom chip on most systems. Feb 17 17:18:55 So the question is more to agree upon some dmi-like struct that needs to be setup prior to kerel boot Feb 17 17:18:59 http://en.wikipedia.org/wiki/Booting has some interesting details on this. Feb 17 17:19:26 sveinse: right. That would need to be done by MLO/u-boot. Feb 17 17:19:34 yes, Feb 17 17:19:59 Or the kernel if it is used directly (which may happen in the future). Feb 17 17:20:00 In concept, arm has one (1) dmi-like information: MachineID. Period Feb 17 17:21:15 As I said, I am new to the architecture, but on x86, the bios loads and probes the platform for "extra" devices that aren't hardcoded into the bios already. Feb 17 17:21:40 Things like pci devices, drives, memory boards, etc. Feb 17 17:22:38 Out of interest: How is that done? (I dont mean PCI and USB devices, because they have well defined ID's attached to them) Feb 17 17:23:47 Each vendor uses core bios code from one of the bios vendors (ami, phoenix, etc) and adds board specific information to it. Feb 17 17:24:45 So in the case of arm, MLO would be board specific. u-boot & kernel not so much as they should get the info they need from MLO. Feb 17 17:24:54 and how is this any different from arm's machineid ? Feb 17 17:25:30 I'd have to look, but the machine ID is very limited in what it contains. Feb 17 17:25:49 Does it change between Beagle C4 and other devices using the same CPU? Feb 17 17:26:05 Yes, that I agree. You'd need some database to provide the extra information, like how to update the kernel Feb 17 17:26:28 sveinse, In the x86 world, one encodes the map of devices and layout in code, following one of three known formats (mostly concurrrently two with modern devices). Feb 17 17:26:51 And it does not support extra information, like revision number. I would love to see that feature added. And call it dmi info Feb 17 17:27:28 Personally, I prefer the OF model, where one has board-specific code that loads, which loads a datafile from a known location, and uses that to determine what to do (and can pass the data to the kernel). The ARM devicetree stuff mirrors that, except it doesn't mandate OF (unfortunately) Feb 17 17:28:04 OF? Do you have any references to that? Feb 17 17:28:36 OpenFirmware Feb 17 17:28:55 You can look at the openhackware package for an example implementation: that one targets qemu's powerpc. Feb 17 17:29:57 I just checked /proc/cpuinfo on my Motorola Droid and it is almost identical to Beagle C4. The only difference is the Hardware and Revision lines. Feb 17 17:30:27 That's expected: Hardware and Revision are the lines that are checked for all device-specific stuff. Feb 17 17:31:01 Oh, and bogomips. (for some reason my droid is running at 249 - odd). Feb 17 17:31:14 I think we're talking about the same. A datafile at some specific location could provide a dmi-info like structure with a devicetree or similar. I would shurely like to have such a featureset added Feb 17 17:31:17 I don't know the complete set, but there was once a port of OF for Marvell's MMP (PXA688-based) as prior work on ARM. Feb 17 17:32:00 Note that as much as I like the model, I can't recommend OF for use on ARM: I simply have never used OF on ARM, nor have I heard stories about anyone working on a port to new hardware. Feb 17 17:32:21 GrueMaster, bogomips are intentionally bogus: ignore those. Feb 17 17:32:24 persia: Checking Hardware and Revision isn't enough. In the example of Beagle C4 & BeagleXM, they are the same. Feb 17 17:32:30 ok Feb 17 17:32:53 GrueMaster, the droid has pm scaling working, hence the low bogomips.. Feb 17 17:32:57 the revision in /proc/cpuinfo only gives the SoC revision not the board's, iirc Feb 17 17:34:02 sveinse, it's a single case, on the "beagle" you can use /proc/cpuinfo to determine weither it's a Bx/Cx series or xM... Feb 17 17:34:05 GrueMaster, Right, which is why I 1) want to separate flash-kernel recipe from machine type (cpuinfo:Hardware), and 2) was asking about Manufacturer and Product strings from devicetree Feb 17 17:37:56 GrueMaster, you need to check the "varient' and "revision" to differentiate the beagle's... http://pastebin.com/5WP3TSiK Feb 17 17:38:17 Yes, I know. Feb 17 17:39:03 rcn-ee_at_work: That is for the cpu only, right? The Hardare lines are board specific? Feb 17 17:39:32 yeap, cpu only... the hardware line comes from the board-omap3beagle.c file.. Feb 17 17:40:14 gpio pin probed, right? Feb 17 17:41:13 no, the cat /proc/cpuinfo is pure processor.. the gpio pin probed is just dumped to dmesg on bootup.. Feb 17 17:41:43 anyone know if andy green is on irc? Feb 17 17:44:44 rcn-ee_at_work: So there is no way for software to detect hardware differences then? Feb 17 17:46:33 GrueMaster, well we can detect an xM board vs a bx/cx board.. but to seperate a C1/2/3 vs a C4 we need to read the gpio pins.. Feb 17 17:47:30 (like what is already done in the board-omap3beagle.c ..) Feb 17 17:49:39 i don't know if it would be excepted, but could we modify the "hardware" line in /proc/cpuinfo based on gpio pin setup we have? Feb 17 17:51:42 prpplague: He is agreen on IRC an hangs on #linaro from time to time, but not all the time Feb 17 17:51:53 prpplague: He is on ATM Feb 17 17:52:01 lool: thanks found him Feb 17 17:53:34 rcn-ee_at_work: My ideal goal would be to have an arch specific kernel (armv7) that could detect what it was on and move forward without having to be specificly compiled for beagle?Panda/Blaze/Dove/imx51/etc. Feb 17 17:53:59 Having MLO with the proper info could allow that. Feb 17 17:54:02 GrueMaster, linaro is working on such a beast. Feb 17 17:54:08 Cool. Feb 17 17:55:20 GrueMaster, actually right now you can boot the same kernel on all the mailine omap3/4 boards... so either mlo/u-boot would have to hint on omap vs imx51.. Feb 17 17:58:14 The next step would be to have some way for userspace to get more info on the platform, similar to dmidecode. Feb 17 17:58:35 devicetree Feb 17 17:59:45 And I think linux-linaro-omap already has the necessary bits to boot on all omap3/4 devices. Feb 17 17:59:52 ok, then all that needs to happen is for it to fall in my lap for rigorous testing. :P Feb 17 18:00:10 Well, you can grab linux-linaro-omap today, and see if that works. Feb 17 18:00:20 The devicetree stuff seems to still be future. Feb 17 18:00:26 (but getting *very* close) Feb 17 18:02:00 since both the imx51 and omap are pretty well supported in mainline, if you can get both to atleast build in one uImage.. it might work.. Feb 17 18:02:56 If I get bored, I might see if I can fire up my babbage with a more recent kernel/image. if... Feb 17 18:02:59 :P Feb 17 18:04:57 for kicks.. what's the best supported imx51 target in mainline right now? Feb 17 18:05:44 I think it is the Efika Netbook. Apparently linaro got a bunch. I missed out. :( Feb 17 18:06:34 * GrueMaster never gets cool hardware, only semi-functional development systems Feb 17 18:09:18 They are available retail. Feb 17 18:09:27 * persia has purchased any number of retail ARM devices now Feb 17 18:09:59 Not even that expensive, as laptops go, although you should probably only get one if you plan to actually use it for something other than idle speculation. Feb 17 18:10:30 rcn-ee, mainline, best supported is still the Babbage for imx51. Feb 17 18:53:06 What is the relationship between the ubuntu native (and armel-cross) compiler and the one provided by linaro? Feb 17 18:53:29 they are the same Feb 17 18:53:45 linaro maintains the arm toolchain in ubuntu Feb 17 18:54:04 ah, ok. thanks Feb 17 18:56:18 I see both 4.4 and 4.5 is available from armel-cross. Which to use. I.e. why would I consider using 4.4 over the 4.5? Feb 17 18:57:27 sveinse: Ubuntu gcc-4.x includes the Linaro patchset + Ubuntu patches; cross compilers are built from the exact same sources, but less frequently Feb 17 18:59:12 We're having some issues with compiling Qt (QWS not X11), and it seems surprisingly similar to bug 705689. So my question is what do I lose by downgrading the (cross)compiler to 4.4 Feb 17 18:59:13 Launchpad bug 705689 in gcc-4.5 "QT applications crash with segfault error on armel when QT is built with gcc 4.5 on natty" [High,Confirmed] https://launchpad.net/bugs/705689 Feb 17 18:59:21 sveinse: sometimes we have multiple versions because the new one is not stable enough, or because we still need the old one for some time Feb 17 18:59:40 sveinse: well we're not developping 4.4 any further in Linaro Feb 17 18:59:47 sveinse: and it will eventually go away Feb 17 18:59:48 Is there a wiki page describing how the OMAP4 server image is meant to be installed? Feb 17 18:59:59 ah, that's an answer, thanks Feb 17 19:00:13 Hey there lool Feb 17 19:01:42 GrueMaster, I discovered why the kernel recommends "grub" when the kernel fails to install: it's a string in debian.master/rules.d/armel.mk : turns out it doesn't mean anything. Dunno if it's worth fixing. Feb 17 19:02:01 hey martyn Feb 17 19:03:09 martyn, So, there's two answers to that. 1) there's work on a minimal jasper-based image, which you don't really "install", as such. 2) someone could work on debian-installer and add more omap4 support for some into-real-target install. Feb 17 19:03:30 Err, rather, *if* there existed a wiki page about it, it would have two answers ... Feb 17 19:03:41 * persia believes such a page doesn't currently exist Feb 17 19:03:45 i.e. "don't bother, not even ready for alpha" Feb 17 19:03:53 "use rootstock" Feb 17 19:04:00 Um, no. Feb 17 19:04:21 The main issue is that nobody is working on it. If you want to do it, it's not that hard to get working. Feb 17 19:04:40 I know, but right this second, I'm teaching someone how to get a system image up .. more about expediency Feb 17 19:05:11 The big obstacle is that most folk with OMAP4 have pandas, and pandas don't have flash: they just boot off the SD card. As a result, there's no useful answer to how one should "flash" a kernel and boot configuration. Feb 17 19:05:48 If you just want a system image, just write an SD card, boot it, and maybe trim the installed packages. That's the expedient way. Feb 17 19:06:10 Post-boot, migrate /var and /srv to some real storage device, and reboot. Feb 17 19:06:12 Heh.. I'm trying for Versatile Express Feb 17 19:06:18 so the image has nothing bootable for me Feb 17 19:06:25 interesting. Feb 17 19:06:54 martyn, If you want to use non-archive kernels, rootstock is your best option. When are you uploading a kernel to the archive? Feb 17 19:06:57 not just a versatile express either .. but one that's been chopped up and reformed into a Calxeda system Feb 17 19:07:14 persia: Not for a while yet .. probably not till .39 Feb 17 19:07:23 So, natty+1? Feb 17 19:07:25 better answer would be 'once we have silicon in house' Feb 17 19:07:29 heh. Feb 17 19:07:55 because before then, it's all based on simulation, fpga, hard engineering, and good intentions Feb 17 19:08:19 I've heard some murmurs about folk doing armel servers, so there's a chance that it's just a matter of uploading the kernel and making a few patches. If nobody does one, you may have to tweak a few more things. Feb 17 21:53:09 apachelogger, thumb2 support is presumed for every Ubuntu armel device Feb 17 21:58:10 persia: ok Feb 17 21:58:37 NCommander: I get segfaults for every kde app all within Qt, ScottK suggests that you said it is a gcc bug? Feb 17 21:58:44 on the n900 that is Feb 17 21:59:11 apachelogger: no, thats NEON built into Qt by accident. Will be fixed when 4.7.2 is uploaded Feb 17 22:00:18 NCommander: the n900 cpu supports neon though? Feb 17 22:00:44 apachelogger: oh ... hrm ... it does, doesn't it Feb 17 22:01:00 it did with maverick ^^ Feb 17 22:01:16 * apachelogger installs libqt4-dbg Feb 17 22:01:32 apachelogger: it may be related to the recent precompiled header bug we found. Feb 17 22:01:52 That's the one I was referring to I think. Feb 17 22:02:31 hey ogra (or anyone).. what secret magic is done to make the boot partition on an sd card not automatically mount under /media? And is it possible to reverse this? Feb 17 22:04:10 robclark, I believe it's just a hidden partition. Feb 17 22:04:22 Why do you want it mounted? Feb 17 22:04:24 how does one make a partition hidden/unhidden? Feb 17 22:04:28 robclark, /sbin/mkdosfs -n "SERVICEV001" -F 32 ${ROOTDEV}1 Feb 17 22:04:29 fdisk :) Feb 17 22:04:34 just rename ti Feb 17 22:04:38 *it Feb 17 22:04:42 ok, so just based on the partition name Feb 17 22:04:47 yep Feb 17 22:05:04 it is more convenient to copy over new kernels when I'm mucking with stuff it it mounts itself ;-) Feb 17 22:05:06 note that you will have it permanently on your desktop once renamed Feb 17 22:05:14 no prob Feb 17 22:05:17 that is what I want Feb 17 22:05:20 k Feb 17 22:05:29 thx :-) Feb 17 22:05:32 ogra, It's not a hidden partition? Why not? Feb 17 22:05:46 persia, the naming hides it Feb 17 22:05:56 udev ignores it completely that way Feb 17 22:06:45 we dont want to hide it from mount but prevent automounting Feb 17 22:06:56 It seems to me that you're using a hack that accidentally works rather than using the partition table as it was designed. Feb 17 22:08:41 GrueMaster: what bug is that? Feb 17 22:08:47 persia: Actually, this is a predefined use case in udev. It is mainly to hide pre-installed partitions. Feb 17 22:09:44 GrueMaster, Doesn't make me like it any more, but yeah, it's because of a common naming scheme for certain OEM restore partitions. Feb 17 22:10:22 apachelogger: Bug 705689 Feb 17 22:10:25 Launchpad bug 705689 in gcc-4.5 "QT applications crash with segfault error on armel when QT is built with gcc 4.5 on natty" [High,Confirmed] https://launchpad.net/bugs/705689 Feb 17 22:10:52 GrueMaster: 4:4.7.1-0ubuntu9 ought to be built agianst 4.4 though Feb 17 22:11:04 oh Feb 17 22:11:14 nevermind me, apparently I have ubuntu7 :O Feb 17 22:11:52 heh Feb 17 22:12:11 You had me doing a double-take. Had to check my panda. Feb 17 22:46:46 lool, does: check_subarch "imx51" look ok for the efika stuff ? Feb 17 23:46:04 ogra: Dunno Feb 17 23:46:17 ogra: I don't know Ubuntu's flash-kernel Feb 17 23:47:35 GrueMaster: ubuntu9 does not seem to fix the issue though :S Feb 17 23:52:11 apachelogger, Everything linked against qt4-x11 is still segfaulting apparently randomly? Feb 17 23:52:35 I wouldn't say random... it *always* segfaults Feb 17 23:52:48 gdb says it is in kdeui though ... getting rid of that and trying again now Feb 17 23:54:08 lool, well, you complained at the bug Feb 17 23:56:15 righto Feb 17 23:56:30 persia: something is fishy with current qt combined with kdelibs Feb 17 23:56:35 From what I could tell from the bug before, it seemed that the segfault happened just about anywhere it could, because of being caused by an inline macro definition. What I'm wondering is if everything linked against qt4-x11 that built during the time it was built with gcc-4.5 needs to be rebuilt. Feb 17 23:57:44 persia: a rebuild could indeed fix this, as some kdelibs stuff is sort of used as plugin for Qt (e.g. fileopen dialogs) Feb 17 23:57:59 without kdelibs unity-2d starts without segfault Feb 17 23:58:21 ogra: well I complained because I saw a commented out line, and suggested either fixing it to be consistent (no idea which value it should have though), or removing it entirely Feb 17 23:58:28 + #check_subarch $running_subarch Feb 17 23:58:28 Was unity-2d rebuilt against ubuntu9? Feb 17 23:59:07 yep Feb 17 23:59:08 ogra: does that make sense now? Feb 17 23:59:20 persia: ubuntu9 was uploaded feb 7, unity-2d feb 15 Feb 17 23:59:34 ogra: I just looked at the diff, I don't know how running_subarch should be handled Feb 17 23:59:48 Well, that's annoying. On the bright side, most of the base of KDE FTBFS anyway currently, so it needs to be rebuilt. Feb 18 00:00:00 hmm Feb 18 00:00:15 last kdelibs upload also was feb 15 Feb 18 00:00:39 So, we'd expect kdelibs to work Feb 18 00:01:01 yes, reinstalling kdelibs5 - unity still works Feb 18 00:01:02 But kdebase is broken (uses old binaries) Feb 18 00:01:10 looks like it Feb 18 00:01:33 http://launchpadlibrarian.net/62899430/buildlog_ubuntu-natty-armel.kdeartwork_4:4.6.0-0ubuntu1_FAILEDTOBUILD.txt.gz Feb 18 00:02:22 that is an intersting fail Feb 18 00:02:44 NCommander, Did you say that the bottom of the KDE stack is kdebindings? Feb 18 00:03:11 * apachelogger loves how bindings always breaks arm building Feb 18 00:05:18 lool, well, i think running_subarch is the wrong approach for consistency, all other arches use a fixed value apart from the ubuntu subarch detection stuff, i was more after finding out if imx51 is the right arch to use here (i'm not sure which flavour name is used on the efikas) Feb 18 00:05:35 uhhhh Feb 18 00:05:37 Program received signal SIGSEGV, Segmentation fault. Feb 18 00:05:37 0x414fbee0 in ?? () from /usr/lib/libphonon.so.4 Feb 18 00:06:23 ogra, imx51 is the kernel flavour (linux-linaro-imx51) Feb 18 00:06:28 ok Feb 18 00:06:59 phonon needs a rebuild against ubuntu9 Feb 18 00:09:01 persia, ogra: I checked the build log, and the vmlinuz file is called Feb 18 00:09:06 boot/vmlinuz-2.6.37-1003-linaro-mx51 Feb 18 00:09:14 so maybe it should be linaro-mx51? Feb 18 00:09:15 aha ! Feb 18 00:09:23 persia: yeah Feb 18 00:09:25 thanks !! Feb 18 00:09:28 just a guess Feb 18 00:09:36 it might be sed-ed down to mx51 Feb 18 00:09:46 lool, Oh, maybe. Is "linaro" part of $FLAVOUR? Feb 18 00:09:50 i'll test that tomorrow before i upload Feb 18 00:10:02 persia, doesnt matter :) Feb 18 00:10:15 it depends what the sed command drops out Feb 18 00:10:21 and i'll use that Feb 18 00:10:35 uname -r says 2.6.37-1003-linaro-mx51 Feb 18 00:10:38 ogra, Yes it does: we ought be semantically correct. if we're not, then we have a kernel bug. If we are, then we may have a sed bug. Feb 18 00:10:55 persia: What's $FLAVOUR? Feb 18 00:10:56 Otherwise it all becomes guesswork. Feb 18 00:11:02 in the context atm it doesnt matter, i wont change the function Feb 18 00:11:07 CONFIG_VERSION_SIGNATURE="Ubuntu 2.6.37-1003.6-linaro-mx51 2.6.37" Feb 18 00:11:31 i will just add the right value to the one line change i do so it matches the kernel naming Feb 18 00:11:44 lool, It's the type of kernel built. I believe it's defined by the existence of./debian.${ENV}/config/vars.${FLAVOUR} Feb 18 00:12:21 ogra, OK. Don't blame me if I change the kernel and you have to do it again. Feb 18 00:12:48 So I checked flash-kernel and check_subarch compares with subarch which is set as subarch=$(echo "$kfile" | sed -e 's/.*-//') Feb 18 00:13:05 persia, why would you change linaro kernels ? Feb 18 00:13:06 so the correct subarch would be mx51 Feb 18 00:13:16 k Feb 18 00:13:22 i would have checked that anyway Feb 18 00:13:23 ogra, Because when *any* package in Ubuntu is semantically wrong, I get annoyed at it. Feb 18 00:13:31 ^^ Feb 18 00:13:33 i'm to tired to upload tonight Feb 18 00:13:41 persia: Oh ok; I thought you meant some runtime thing Feb 18 00:14:30 lool, No. If you don't know offhand, I'll check the linux-linaro source. I suspect that "linaro" is not part of the flavour, but just want to make sure. Feb 18 00:15:16 apachelogger, Indeed: phonon built nicely against ubuntu8, sadly. Feb 18 00:15:29 NCommander, Do you know which was the first revision of qt4-x11 to have issues? Feb 18 00:15:41 looking at 2.6.37-1003.6, I see the config is named config.flavour.linaro-mx51 Feb 18 00:15:46 persia: ^ Feb 18 00:15:49 * persia thinks it might be best to ask for a mass-rebuild from an LP-generated lsit Feb 18 00:16:32 persia: if that is the issue at all ;) Feb 18 00:16:42 phonon ubuntu4 uploaded, should be finished in some 20 minutes Feb 18 00:17:30 lool, Indeed. I'm not sure that's how it ought be done: I think it would make more sense to have linux-linaro as SRCPACKAGE, with flavours "mx51", etc. So we'd end up with linux-linaro-image-foo-mx51 rather than linux-image-foo-linaro-mx51 Feb 18 00:17:54 apachelogger, Let's see. NCommander said it was at :09 Feb 18 00:19:49 persia: Ah I can speak in favor of linux-image-*: apparently this pattern is used in places like d-i, and it's a bad idea to diverge from it Feb 18 00:20:07 persia: it was an issue with GCC, not qt Feb 18 00:20:28 persia: it was a design choice to have the packages be named linux-image-linaro-foo rather than linux-linaro-image-foo Feb 18 00:20:38 NCommander, I understand the root, but would the miscompiled qt4-x11 cause the segfaulting apachelogger is seeing in phonon? Feb 18 00:20:51 it's quite a dance to get this right across all binary packages and meta packages Feb 18 00:21:12 lool, I understand. I don't like it. I hope you understand why I don't like it. I'll leave it alone for now. Feb 18 00:21:33 (and thanks for reminding me: I have to do a -meta) Feb 18 00:23:49 Oh, and to be clear, I don't care about linux-image-linaro-foo-mx51, it's the linux-image-foo-linaro-mx51 I don't like (but the former is hard to arrange with the kernel packaging scripts as they exist) Feb 18 00:25:00 ah with foo you meant ABI and version Feb 18 00:25:10 yeah linux-image-linaro-foo-mx51 is hard Feb 18 00:25:12 Yeah. Feb 18 00:25:14 more of a limitation Feb 18 00:25:46 I'm not sure it's a limitation, just would need definition and insertion of $VENDOR Feb 18 00:26:16 I mean, it's just not provisioned in the current implementation Feb 18 00:26:24 I'd like to fix it at some point, so that $FLAVOUR as defined in the kernel packaging and $FLAVOUR as detected by the many sed scripts again have the same value. Doesn't have to be soon. Feb 18 00:30:38 persia: I think the fix in qt4-x11 is only temporary to disable precompiled headers. The real fix is in gcc, and I am not sure if that has been released to update the toolchain. If that is the case, we may need to rebuild kde with precompiled headers off as well. Not sure. Feb 18 00:30:39 Probably just an entry in debian.linaro/control.d/vars.* and corresponding bit in flavour-control.stub, really. Feb 18 00:31:02 apachelogger: ^^^ Feb 18 00:31:12 GrueMaster, apachelogger just tried a test recompile with phonon to see if that's sufficient. We'll know more RSN Feb 18 00:31:16 Sorry, I was at the UPS store earlier. Feb 18 00:31:43 I don't think a simple recompile will fix it, but I could be wrong. Feb 18 00:32:14 NCommander: want to weigh in? Feb 18 00:32:14 More testing is welcome :) Feb 18 00:34:02 GrueMaster, What's the name of the maverick dove kernel meta package? Feb 18 00:34:57 linux-mvl-dove Feb 18 00:35:12 Yep. Was just verifying. Feb 18 00:35:37 * ogra had to fight with the headers on the weekend ... Feb 18 00:35:48 ogra, That's real kernel, not the meta. Feb 18 00:35:53 else i would have had to look it up too :) Feb 18 00:36:07 still segfaulting \o/ Feb 18 00:36:10 persia, nope. thats the meta Feb 18 00:36:18 Not according to the source I'm looking at. Feb 18 00:36:30 linux-image-mvl-dove is the kernel Feb 18 00:36:32 Ah, maybe I should ask: what's the name of the source package that provides that? Feb 18 00:36:36 well, the kernels meta Feb 18 00:37:16 GrueMaster, persia: rebuild apparently does not help :S Feb 18 00:37:20 NCommander, Any suggestions for workarounds that could help apachelogger? Feb 18 00:38:04 persia, linux-meta-mvl-dove Feb 18 00:38:33 Thanks! That's the one permutation I didn't try before giving up. Feb 18 00:38:54 and the binaries of meta and kernel are actually just linux-dove and linux-image-dove Feb 18 00:39:21 dunno where the mvl vanished to Feb 18 00:39:29 * apachelogger installs dbg symbols Feb 18 00:40:05 ogra, The kernel packaging hackery fails to define VENDOR consistently (see above), with results like that. Feb 18 00:40:16 yep Feb 18 00:40:29 well, its gone from the archive since last week Feb 18 00:40:44 so nothing to worry about anymore Feb 18 00:40:51 (for now) Feb 18 00:40:51 Fixing it probably means me generating some PoC kernel hackery, and taking it to UDS, and getting it applied to all vendor kernels. Feb 18 00:41:08 Still have TI and Linaro kernels in the archive though. Feb 18 00:41:33 well, linaro wants to have the branding in the package name as i understand Feb 18 00:41:46 yay Feb 18 00:41:47 http://paste.ubuntu.com/568547/ Feb 18 00:41:50 looks familiar Feb 18 00:41:53 and TI can hopefully be built from upstream next round Feb 18 00:42:28 Yes, but there's always going to be reasons why vendor kernels are interesting, and it makes sense to do them right, rather than half-way and hackishly Feb 18 00:42:40 agreed Feb 18 00:42:48 persia: supposedly gcc 4.5 should be fixed, otherwise we'd need a pile of force-gcc-4.4 changes Feb 18 00:42:48 i just meant its not for natty Feb 18 00:43:14 anyway, nearly 2am ... Feb 18 00:43:15 Oh, indeed. See earlier comment about UDS. Feb 18 00:43:19 Good night :) Feb 18 00:43:22 * ogra vanishes Feb 18 00:43:39 apachelogger, The Linaro GCC team was looking at it. I don't know current status. Feb 18 00:53:45 morning Feb 18 00:54:24 Good morning. Feb 18 00:54:39 apachelogger: persia I'm honestly not sure why sip is choking Feb 18 00:55:51 NCommander, I'm not fussed about sip: I'm concerned about phonon segfaulting, when it wasn't before. Does *everything* have to be rebuilt, or is there a workaround of some sort? Feb 18 00:56:38 And if everything is rebuilt, will it need to be rebuilt again once gcc is fixed? Feb 18 00:58:00 persia: I wasn't aware of phonon segfaulting Feb 18 00:58:14 persia: that beign said, since we were dealing with a miscomplication, everything might need a bump-build :-/ Feb 18 00:58:29 That's not enough. Feb 18 00:59:04 So, phonon was built against qt4-x11 ...ubuntu8, which was broken. It segfaulted. apachelogger rebuilt it against ...ubuntu9, which is the latest. Same segfault. Feb 18 00:59:16 konsole is even segfaulting. Feb 18 00:59:44 NCommander: http://paste.ubuntu.com/568547/ Feb 18 01:00:45 apachelogger: what hardware are you one? Feb 18 01:02:56 NCommander: n900 Feb 18 01:03:05 apachelogger: Try building with gcc-4.4 & adding -no-pch to the extra_configure_opts. This is what was needed to get a working qt. Feb 18 01:03:36 Just building with gcc 4.4 isn't enough as 4.4 has a bug with precompiled headers. Feb 18 01:03:37 * apachelogger i going to bed in a bit Feb 18 01:03:52 GrueMaster: I do not think that was built against 4.4 at all Feb 18 01:03:58 just a rebuild against new Qt Feb 18 01:04:02 NCommander, Are we going to need to rebuild a significant chunk of the archive like that? Feb 18 01:04:14 which does not help as the function in question seems to be inline Feb 18 01:04:19 I'm referring to gcc 4.4 not qt 4.4 Feb 18 01:04:47 GrueMaster: that is what I meant too ;) Feb 18 01:18:26 persia: I honestly don't know at this point Feb 18 01:20:58 See, if qt4-x11 is broken, I'm sorely tempted to upload a replacement that causes everything to fail to built against it, to reduce the number of times we have to reupload stuff later. Feb 18 01:25:38 persia: but its not broken, unity-2d now works fine against it Feb 18 01:25:46 as do other Qt apps, the problem seems tobe kdelibs Feb 18 01:27:16 Ah, so Qt works, but KDE is broken? Feb 18 02:36:15 It can't be too broken as I can build against it. Feb 18 02:36:34 persia: ^^^ Feb 18 02:38:11 ScottK, Sure, but if you're building with an inline macro that generates a segfault at runtime, you may not find the results very useful. Feb 18 02:38:53 True, but I'm bulding kdebindings. I think kdelibs has to actually do stuff for that to work. Not sure though. Feb 18 02:40:38 I don't know. From what I can tell from IRC traffic and bugs, it seems that there are two issues: firstly that gcc-4.5 has a reference count issue meaning that inlines in nested functions can break stack accounting, and gcc-4.4 has an issue with precompiled headers not being compiled in a way that safely allows reuse. Feb 18 02:41:05 This only affects some code, with certain sorts of inline macros. Where that would be hit isn't clear. Feb 18 02:42:20 We'll re-upload all of KDE before release, so it should be ~fine as long as it's sorted soon. Feb 18 02:42:22 I don't think it would be advantageous to apply workarounds to everything that seems dodgy, but a simple rebuild (as tested with phonon) doesn't seem to help. Feb 18 02:42:48 There's a candidate patch under review by the Linaro gcc team for gcc-4.5, which looks like it might do the right thing. Feb 18 02:42:55 (at least in terms of generated RTL) Feb 18 02:43:15 I'm mostly concerned about the timing: with feature freeze and Alpha 3 coming up relatively soon. **** ENDING LOGGING AT Fri Feb 18 02:59:57 2011