| dasilva333 | hey guys | 01:40 |
|---|---|---|
| === panda is now known as Guest59538 | ||
| === asac_ is now known as asac | ||
| XorA|gone | morning | 02:58 |
| prpplague | hey bud | 02:59 |
| prpplague | XorA|gone: you get a chance to fill in the pandaboard survey? | 02:59 |
| XorA|gone | prpplague: already done | 02:59 |
| prpplague | XorA|gone: dandy | 02:59 |
| XorA|gone | probably the only hope I have of getting one :-D | 03:00 |
| prpplague | a chronos watch? | 03:00 |
| prpplague | XorA|gone: you still haven't gotten a pandaboard? | 03:00 |
| === Guest59538 is now known as panda|x201 | ||
| XorA|gone | prpplague: nope | 04:18 |
| * XorA|gone is now starting to hate hardware designers | 04:19 | |
| XorA|gone | prpplague: thats not you BTW :D | 04:19 |
| prpplague | hehe | 04:19 |
| === fta` is now known as fta | ||
| hrw | flash-kernel needs changes for panda ;( | 09:00 |
| hrw | 1. 2.6.38-rc has "OMAP4 Panda board" not "OMAP4430 Panda Board" | 09:01 |
| hrw | 2. linaro kernel is 'omap' not 'omap4' flaovour | 09:01 |
| === asac_ is now known as asac | ||
| janimo | hrw, you mean /proc/cpuinfo changed for panda? | 09:42 |
| hrw | yes | 10:00 |
| hrw | who knows, maybe one day there will be 4440 based panda | 10:00 |
| janimo | 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:42 |
| hrw | easiest it to edit boot.scr | 10:43 |
| lool | 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:47 |
| hrw | I know | 10:48 |
| ogra | well, -omap is tricky, tres is trivial | 10:52 |
| ogra | s/tres/the rest/ | 10:52 |
| * ogra doesnt get where the letters went, i definitely typed them | 10:52 | |
| hrw | I prefer to not touch flash-kernel. my changes ends in ogra's merge queue which is huge enough | 10:53 |
| ogra | 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 |
| ogra | i fear that will break NCommander's changes for generic kernel installation | 10:54 |
| persia | Why does flash-kernel limit which kernels can boot? Shouldn't it take the latest usefully installed kernel, and perform the appropriate action? | 10:54 |
| ogra | hmm, wait, you are right, flash-kernel doesnt care for package names at all | 10:55 |
| * ogra re-checks | 10:55 | |
| hrw | it cares for flavour names | 10:55 |
| ogra | it shouldnt | 10:55 |
| persia | If it cares for flavour names, it needs to be fixed. | 10:55 |
| hrw | then kill sub_arch check | 10:55 |
| persia | Hrm, but it ought care about subarch. | 10:59 |
| ogra | persia, it does that since NCommander added his subarch stuff | 11:00 |
| ogra | uname -r | sed -e 's/.*-//' | 11:00 |
| ogra | it doesnt care for package names but for flavour in uname | 11:00 |
| persia | Right. | 11:01 |
| ogra | which also breaks blaze | 11:01 |
| persia | Debian flash-kernel uses kfile to determine subarchi. | 11:02 |
| persia | With subarch=$(echo "$kfile" | sed -e 's/.*-//') | 11:02 |
| persia | 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:04 |
| hrw | flash-kernel require rewrite I think | 11:07 |
| persia | Ah, I see. if subarch="", check_subarch always returns true. | 11:08 |
| ogra | that doesnt matter | 11:11 |
| ogra | what matters is that check_subarch is completely ignored on dove omap and omap4 arches | 11:11 |
| persia | Ah, because there are no "machine" entries. I see. | 11:12 |
| ogra | yep | 11:13 |
| ogra | the prob is that instead of guessing for a proper kernel the code just makes it ignore the check | 11:13 |
| ogra | and installs whatever kernel is available | 11:13 |
| ogra | to be proper implemented it would need more of a database and some clever algorhythms to do guesswork | 11:14 |
| persia | 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 |
| ogra | a proper implementation would be possible with devicetree db's | 11:15 |
| ogra | you could match kernel features against the actual hw | 11:16 |
| persia | How would that work? | 11:16 |
| ogra | the kernel ships the devicetree data anyway | 11:16 |
| ogra | 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:17 |
| ogra | if you find the kernel supports a) the arch and b) enough devices for booting, you write a flag | 11:18 |
| ogra | that flag is looked up on flash-kernel run | 11:18 |
| persia | How does one define b) ? | 11:18 |
| ogra | rootfs device, serial support and basic init ... you need a db for that indeed | 11:19 |
| persia | Why do we care about serial? How can we identify "basic init" for arbitrary boards? | 11:19 |
| ogra | you could spill a warning if not everything is supported | 11:19 |
| ogra | you cant you will always need a matching db about whats needed for init | 11:20 |
| ogra | but that way you can at least support a wider range of HW without breaking it for totally unsupported stuff | 11:20 |
| persia | 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 |
| ogra | only for devices it has a machine file for | 11:21 |
| persia | I thought you would be able to specify a machine file on the kernel command line. | 11:21 |
| ogra | you still have the toplevel subarch | 11:21 |
| ogra | i.e. take the touchbook ... | 11:22 |
| ogra | essentially its a beagle | 11:22 |
| ogra | and you can use a beagle kernel on it | 11:22 |
| ogra | but wont have much devices | 11:22 |
| ogra | since the devices are special and never have been pushed upstream | 11:22 |
| ogra | you will still be able to boot into serial with any std beagle kernel though | 11:23 |
| persia | So, let's say there is a device with necessary upstream support. Should that just work? | 11:25 |
| persia | 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 |
| persia | (as the subarch isn't changing) | 11:26 |
| ogra | it would be able to tell you that you only have minimal kernel support and optionally ask you about proceeding or not | 11:28 |
| persia | So, increase the verbosity of the "Generic Subarch" warning, and ask the user to confirm the operation? | 11:28 |
| ogra | leave the user the option to not mess up his system | 11:29 |
| persia | 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 |
| persia | How would that work? | 11:31 |
| ogra | heh, well, if you run flash-kernel you already have a working system | 11:31 |
| ogra | if you would run it on a kernel that drops features you surely would want a warning | 11:32 |
| persia | Yes, but if you run flash-kernel-installer, you may not have a working system yet. | 11:33 |
| ogra | if you run flash-kernel-installer on such a system, d-i has a bug | 11:34 |
| persia | Huh? Why? | 11:34 |
| ogra | it shouldnt install on unsupported HW | 11:34 |
| ogra | actually the check should happen way way earlier | 11:34 |
| persia | 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:36 |
| ogra | and d-i (or whgatever else) politely tells you that you in max will run that device with a serial console | 11:37 |
| persia | 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 |
| ogra | or tell you its not supported at all | 11:37 |
| ogra | or it just works | 11:37 |
| persia | If I'm booting a live image, there is no check. | 11:37 |
| persia | if I'm booting a pre-installed image, there is no check. | 11:37 |
| ogra | right, we should add that to jasper | 11:37 |
| persia | jasper should probably leverage base-installer to do that. | 11:37 |
| ogra | yes | 11:38 |
| persia | But there's still the live image case. | 11:38 |
| ogra | its on my WI list | 11:38 |
| persia | Heh, OK. | 11:38 |
| ogra | thats why i asked you about your tool in main ;) | 11:38 |
| persia | How is that related? | 11:38 |
| ogra | device-detect gets me more detailed info | 11:38 |
| persia | Than what? | 11:38 |
| ogra | archdetect (which is what base-installer uses) | 11:39 |
| persia | Please *don't* use devicetype-detect for that. | 11:41 |
| persia | You'd just be duplicating the test suite, etc. | 11:41 |
| ogra | but i need to match against more detailed data than archdetect can deliver | 11:41 |
| persia | No you don't. | 11:42 |
| ogra | jasper *is* duplicating stuff | 11:42 |
| persia | If you need more specificity, you need to get that into archdetect | 11:42 |
| ogra | thats its whole purpose | 11:42 |
| ogra | no, i dont | 11:42 |
| persia | I thought we had a UDS session about that. | 11:42 |
| ogra | archdetect does exactly what its supposed to do | 11:42 |
| persia | And decided that jasper should *not* duplicate stuff. | 11:42 |
| ogra | but doesnt get me enough data back | 11:42 |
| ogra | jasper *has* to duplicate casper functions | 11:43 |
| ogra | thats its whole purpose | 11:43 |
| persia | What data do you need? | 11:43 |
| ogra | if you would check live images you would have to implement it in casper | 11:43 |
| ogra | arch *and* device | 11:43 |
| persia | Why? | 11:43 |
| ogra | because our kernels can support more than one device | 11:44 |
| persia | So, back to my story. | 11:44 |
| persia | I boot into the live image. Everything is working. I press install. | 11:44 |
| ogra | 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 |
| persia | It installs, the install runs flash-kernel installer. It installs the kernel that I booted. | 11:45 |
| persia | Why do I care if I'm using a device that you've never heard about? | 11:45 |
| ogra | yeah, thats no issue | 11:45 |
| persia | It is if you care about device. | 11:45 |
| persia | Because if you care about device, you're going to tell me it doesn't work, and maybe try not to install. | 11:45 |
| ogra | exactly | 11:46 |
| persia | 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:46 |
| persia | As I see it, we have two ways we can fail. | 11:47 |
| persia | We fail if we write a kernel to a device which can't use it, and render it unbootable. | 11:48 |
| persia | We fail if we refuse to work on a device on which the kernel works. | 11:48 |
| persia | Do you see any others? | 11:48 |
| ogra | half way working devices | 11:48 |
| ogra | and devices for which this image isnt suited | 11:49 |
| ogra | (beagle C4 with a full desktop for example) | 11:49 |
| persia | 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 |
| ogra | we can adjust defaults | 11:49 |
| persia | I don't think that's being nice. | 11:50 |
| ogra | 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 |
| persia | 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 |
| ogra | they can | 11:50 |
| ogra | 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 |
| persia | Anyway, we're getting sidetracked. Let's ignore all the defaults for now. | 11:51 |
| persia | 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 |
| persia | I'll claim the failure is to not boot the kernel, as otherwise we can never collect useful bug reports. | 11:52 |
| ogra | yes, i agree | 11:52 |
| ogra | but the user needs to know about it | 11:52 |
| persia | I've no issue with that. | 11:53 |
| ogra | if you boot a kernel that has no display support at all the user needs to know that | 11:53 |
| persia | How can you tell the user this? There's no display... | 11:53 |
| ogra | mors code on an LED :P | 11:54 |
| ogra | *morse | 11:54 |
| persia | You're mad! | 11:54 |
| ogra | no, indeed you are right, if we are in first boot that doesnt help | 11:55 |
| persia | Going back something useful. | 11:55 |
| ogra | if i install a development kernel it does though | 11:55 |
| persia | So, we've booted the first time with a downloaded install image. | 11:55 |
| ogra | right, that either boots or doesnt | 11:55 |
| persia | 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 |
| ogra | yes | 11:56 |
| persia | And I claim we can trust the user to have selected the appropriate input/output (serial console, KVM, etc.) for their needs. | 11:56 |
| ogra | if the user sees it booting he should, yeah | 11:57 |
| persia | Next, we do the install steps (jasper/ubiquity/d-i). | 11:57 |
| persia | At this point, we end up calling flash-kernel-installer | 11:57 |
| persia | 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:58 |
| ogra | then flash-kernel-installer should have no checks at all | 11:59 |
| persia | Now, here's where it gets tricky. | 11:59 |
| persia | There's N different kernels in the archive, and K different ways to mangle the kernel to make it bootable. | 12:00 |
| ogra | the point is that you need to identify the way the device boots | 12:00 |
| ogra | in which case you again need the data about the device, not the arch | 12:00 |
| persia | So, we care about K, but not about N? | 12:00 |
| ogra | 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:01 |
| ogra | flash-kernel will only dump the kernel in a different place | 12:02 |
| ogra | the place is the point | 12:02 |
| ogra | and that depends on the device data | 12:02 |
| persia | OK, so for that we want the machine info from CPUinfo | 12:02 |
| ogra | right | 12:02 |
| ogra | but probably even more | 12:02 |
| ogra | i.e. beagle C4 vs XM | 12:02 |
| persia | And the abstraction of omap_flash_kernel and dove_flash_kernel only breaks things. | 12:02 |
| ogra | cpuinfo doesnt identify the difference | 12:03 |
| persia | devicetype-detect doesn't. | 12:03 |
| ogra | hmm, we should enhance it that way | 12:03 |
| persia | (actually, devicetype-detect only outputs strings like "netbook", "laptop", "desktop", "phone", etc. (even less detail)) | 12:03 |
| persia | No. The point of devicetype-detect is to add some flexibility to laptop-detect. | 12:04 |
| ogra | device-name detect would be more intresting, yes | 12:04 |
| persia | devicename-detect has all sorts of arch-specific hackery, but for armel, just uses machine from cpuinfo. | 12:04 |
| persia | devicename-detect is mostly interesting because it has the equivalent collection for every architecture. | 12:05 |
| persia | So, again, that's no more information. | 12:05 |
| ogra | it should have revision data | 12:05 |
| persia | cpuinfo has that. Devicename-detect doesn't care. | 12:05 |
| ogra | or at least a switch to show it | 12:05 |
| persia | Parsing cpuinfo is significantly more robust. | 12:05 |
| ogra | but exhausts what flash-kernel can do atm | 12:06 |
| persia | How do you mean? | 12:06 |
| ogra | machine=$(grep "^Hardware" /proc/cpuinfo | sed 's/Hardware\s*:\s*//') | 12:07 |
| persia | Right. | 12:07 |
| ogra | thats all that is matched against | 12:07 |
| ogra | and not all boards ahve a revision in cpuinfo | 12:07 |
| ogra | so you cant just blindly match against it | 12:07 |
| persia | You're saying that cpuinfo:Hardware doesn't have an identity relation to method-to-make-kernel-bootable? | 12:08 |
| ogra | not on all boards | 12:08 |
| ogra | thats the prob | 12:09 |
| ogra | "OMAP3 Beagle Board" | 12:09 |
| ogra | is returned for *all* beagles since revision A | 12:09 |
| ogra | so you can have a 128M, 256M or 512M version with or without flash etc etc | 12:10 |
| persia | Is this a kernel bug, or is there additional information available that lets us identify the specific requirements for boot? | 12:10 |
| ogra | no, thats a design decision from the manufacturer | 12:10 |
| hrw | persia: it is not a kernel bug | 12:10 |
| hrw | A3/B7/C3 are beagleboard. they just have different revision | 12:10 |
| ogra | XM too | 12:11 |
| hrw | ogra: never played with xM | 12:11 |
| persia | So, is there additional information available that lets us identify the specific requirements for boot? | 12:11 |
| ogra | and you will see the same prob on panda | 12:11 |
| ogra | though here its even worse since the kernel string changed between revisions | 12:11 |
| ogra | would be intresting to know what the linaro kernel says on blaze or tablet | 12:12 |
| ogra | or on the RIM tablet :) | 12:12 |
| ogra | or the new LG phone ... | 12:12 |
| persia | So, is there additional information available that lets us identify the specific requirements for boot? | 12:12 |
| ogra | 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 |
| ogra | but u-boot is gone at that point | 12:13 |
| persia | Do we know which sysfs file? | 12:14 |
| ogra | no, i dont atm | 12:14 |
| persia | Because we ought to be checking that to define machine in flash-kernel/flash-kernel-installer, rather than cpuinfo:hardware | 12:14 |
| ogra | and dont have either board around to check | 12:14 |
| persia | hrw, Any ideas? | 12:14 |
| ogra | cpuinfo:hardware is ok for top level identification | 12:15 |
| hrw | cpuinfo:hardware + cpuinfo:revision are nearly always present on arm | 12:15 |
| persia | No, it's useless, if there isn't an identity relation between that and technique-for-making-device-bootable | 12:15 |
| persia | hrw, does that pair have an identity relation to technique-for-making-device-bootable? | 12:16 |
| hrw | persia: sorry, I didn't followed whole discussion | 12:16 |
| hrw | persia: even hw+rev will not tell you do you need uImage or zImage. | 12:16 |
| persia | Ah, so yeah, that's not complete. | 12:16 |
| hrw | beagleboard can have u-boot or Qi or barebox or anyother bootloader | 12:16 |
| persia | Basically, we need some way to know what method to use to make a device bootable. | 12:17 |
| persia | 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:17 |
| hrw | if you stick to 'this machine is ubuntu stock config' then hw+rev should work for most I think | 12:18 |
| persia | What do you mean by "ubuntu stock config"? | 12:19 |
| hrw | granted that device runs known bootloader | 12:20 |
| hrw | otherwise you will end in hell of providing uImage + zImage + wtfImage + .... + yabImage | 12:21 |
| lilstevie | rim tablet may not be so easy to get your own kernel executing on | 12:21 |
| persia | I'm willing to pick a preferred bootloader on a per-device basis. | 12:22 |
| persia | lilstevie, Why? | 12:22 |
| lilstevie | the playbook devel images are starting to show RSA 4096bit signatures | 12:23 |
| persia | Oh, annoying bootloader. I'm happy to ignore those devices. | 12:23 |
| lilstevie | heh | 12:24 |
| lilstevie | the galaxy tab is starting to do my head in too | 12:24 |
| persia | 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:24 |
| lilstevie | something really doesnt want to let X work on it | 12:25 |
| lilstevie | if it is anything like iDevices someone will need to write a replacement bootloader for it | 12:25 |
| persia | ogra, Do you know of a case where Hardware+Revision matches two different devices with different requirements for flash-kernel? | 12:25 |
| lilstevie | is there a way of getting greater detail on what is screwing with Xorg than -verbose 20 | 12:26 |
| persia | lilstevie, You might ask the folk in #ubuntu-x | 12:28 |
| lilstevie | persia: ok thanks I asked over there | 12:31 |
| persia | 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 |
| hrw | did someone stacked beagles with pandas? | 12:36 |
| apachelogger | do we have a tiwlan driver somewhere? | 12:37 |
| ikepanhc | persia: you need the list of device within SoC? | 12:38 |
| persia | 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:38 |
| persia | Sorry for the confusion around the word "device" | 12:39 |
| persia | 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:40 |
| ikepanhc | 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 |
| apachelogger | hm | 12:41 |
| apachelogger | persia: one gets to wonder if it works with omap3 :D | 12:41 |
| persia | ikepanhc, It's more than just SoC: for example, the Touchbook and the Beagle are both the same SoC, but different hardware. | 12:41 |
| persia | apachelogger, Heh. No idea. | 12:41 |
| apachelogger | persia: ok :) | 12:42 |
| ikepanhc | persia: ok, then for SoC, cpuinfo maybe not perfect but as I know, its the only one | 12:42 |
| ikepanhc | persia: but for other device outside the SoC, I believe we need to probe them one by one | 12:43 |
| ogra | persia, the PPA one will go away, it has been reimplemented in .38 | 12:43 |
| persia | 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 |
| ogra | persia, touchbook is such a case as you ask for above, it is identical to beagle in all aspects | 12:43 |
| ikepanhc | persia: some hardware designer will try to use gpio pins or ROM for identifying hardwares | 12:43 |
| ikepanhc | persia: but there is no standard rule for this | 12:44 |
| persia | apachelogger, Try the .38 omap3 kernel from the linux source package, and see if the wlan just works. | 12:44 |
| persia | ikepanhc, Ah, OK. That makes it extra tricky. Thanks. | 12:44 |
| ikepanhc | :) | 12:44 |
| apachelogger | well, I don't have much to try yet :D | 12:44 |
| apachelogger | though | 12:44 |
| apachelogger | I'll get an archos 101 it would seem | 12:45 |
| hrw | apachelogger: nice device | 12:45 |
| hrw | persia: i2c:50 on beagleboard will give you ID of extension board for example | 12:46 |
| apachelogger | a notion ink adam would still be nicer ^^ | 12:46 |
| persia | 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 |
| ogra | hmm, i would prefer to automate it more | 12:47 |
| persia | I'm thinking that we have some conffile that specifies the recipe to use, and just reuse it reliably post-install. | 12:48 |
| persia | 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 |
| ogra | hmm, yeah | 12:49 |
| persia | So, for the Touchbook/Beagle example, we default to Beagle, but someone with a Touchbook could select Touchbook. | 12:50 |
| persia | 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 |
| persia | 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 |
| persia | But that's not for Natty. | 12:51 |
| ogra | yep | 12:51 |
| persia | NCommander, So, the above massively impacts your generic-subarch stuff. | 12:52 |
| persia | Basically, we're not convinced that there is a useful relationship between detected-subarchitecture and recipe-to-make-just-installed-kernel-boot. | 12:53 |
| persia | 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:54 |
| sveinse | persia, doesn't ARM linux have a machine ID mechanism which had to be setup in the bootloader? | 12:57 |
| sveinse | see http://www.arm.linux.org.uk/developer/machines/ | 12:58 |
| hrw | sveinse: but you can make kernel which boots on more then one machineID | 12:59 |
| persia | 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 |
| persia | Mind you, I'd be glad to be wrong :) | 13:00 |
| persia | NCommander, Since you'll apparently encounter this in backscroll: the description of what I'd like to do starts at :47 | 13:01 |
| sveinse | 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 |
| persia | hrw, I think we would have cases where the same kernel would boot on multiple devices, using different recipes to make it bootable. | 13:02 |
| persia | 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:03 |
| sveinse | 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:04 |
| persia | Things like "rhino" or "snowball" or "guppy" or "spitz" don't tend to be very informative. | 13:05 |
| persia | Even with it, it's not easy to know, but yeah :) | 13:05 |
| sveinse | USB has it, PCI has it, even mobles phone all have systems for tracking the HW its running on | 13:06 |
| sveinse | iirc PC has it as well via. the DMI | 13:06 |
| persia | 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:08 |
| sveinse | I would love that yes, but I fear many boards/bootloaders don't set this ID properly | 13:10 |
| sveinse | The machine type codename ("rhino", "snowball" etc.) is irrelevant. It's the number which should uniquely identify the HW. | 13:11 |
| sveinse | 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 |
| persia | devicetree is better for that. | 13:13 |
| persia | And in the absence of devicetree, a detection algorithm. | 13:14 |
| sveinse | I still need to determine which HW revision I'm on. | 13:14 |
| sveinse | 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 |
| persia | I assert that you care which revision of each peripheral you have, rather than which revision of the board/retail device you have. | 13:15 |
| persia | Which is why I claim machineID isn't the right place for that. | 13:16 |
| sveinse | 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:18 |
| sveinse | pluggable peripherals are IMHO another ballgame and needs its separate scheme for identification (like USB VID/PID) | 13:19 |
| persia | I believe that non-pluggable peripherals ought be treated the same, for the most part. | 13:19 |
| persia | Helps reduce duplication of code or special-casing when the same components are used on multiple boards, etc. | 13:19 |
| sveinse | ah, I see. | 13:20 |
| sveinse | That would require that the SoC implementors agreed upon some scheme for device ID on peripherals... | 13:20 |
| persia | Yes. | 13:20 |
| lilstevie | good luck with convincing them of that | 13:21 |
| persia | Well, rather that the board implementor happened to select components, all of which had some scheme for device ID implemented. | 13:21 |
| sveinse | I second that, but doubt it will be easy to convince the mfgs | 13:21 |
| persia | heh :) | 13:22 |
| sveinse | When you port linux to a new SoC, you need to make the platform driver's list | 13:23 |
| sveinse | what if you would have to put some pre-defined ID in here, a scheme like USB VID/PID? | 13:23 |
| lilstevie | maybe once windows arm devices start being sold | 13:23 |
| persia | 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:24 |
| persia | lilstevie, Why would that be different? The more so considering all the existing ARM devices that run various flavours of Windows? | 13:26 |
| sveinse | persia, what kind of off-SoC peripherals are we talking about? this doesn't apply for USB at least | 13:27 |
| lilstevie | well once windows8 arm gets released that will push for uniform identification methods | 13:27 |
| persia | 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:28 |
| sveinse | 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 |
| sveinse | possibility, not ability per se | 13:29 |
| persia | Right, and it's that bit which I'd hope to have some way to identify without tracking board revisions. | 13:30 |
| sveinse | I understand what you want, and I do agree, but I don't think the picture is that easy unfortunately | 13:31 |
| persia | What complicates it? | 13:31 |
| sveinse | Many SoC is capable of booting without support from other devices except memory | 13:32 |
| sveinse | 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 |
| sveinse | I ment external or internal to the SoC | 13:33 |
| persia | And these different implementation choices require different hinting to the drivers, in a way that the drivers cannot handle through discoverability? | 13:35 |
| persia | s/discoverability/discovery/ | 13:36 |
| sveinse | persia, essentially yes | 13:44 |
| persia | 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 |
| sveinse | 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:46 |
| persia | That makes sense. | 13:47 |
| sveinse | 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:50 |
| sveinse | 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:52 |
| sveinse | oh how time flies... | 13:53 |
| * sveinse *leaving* | 13:54 | |
| lool | persia: efikamx smarttop support on its way to linaro-image-tools https://code.launchpad.net/~lool/linaro-image-tools/efikamx/+merge/50151 | 14:22 |
| persia | lool, Cool. | 14:41 |
| === 16WAAHT8Q is now known as ian_brasil | ||
| persia | lool, I notice overo listed there as well. Is that working cleanly with the linaro builds? | 14:43 |
| lool | persia: It is, albeit there is a kernel issue which has a patch | 14:44 |
| lool | I think it's hdmi output or so | 14:44 |
| persia | Your merge doesn't seem to have EfikamxConfig: that was already merged? | 14:44 |
| lool | LP #660811 | 14:45 |
| ubot2 | Launchpad bug 660811 in linux "Display is not working on Gumstix Overo" [Undecided,Fix released] https://launchpad.net/bugs/660811 | 14:45 |
| lool | persia: +class EfikamxConfig(Mx5Config): | 14:45 |
| lool | 28+ uboot_name = 'efikamx' | 14:45 |
| lool | +class EfikamxConfig(Mx5Config): | 14:45 |
| lool | gah | 14:45 |
| lool | persia: I see it | 14:45 |
| persia | Am I reading 660811 correctly as fixed-in-maverick-open-in-natty? | 14:46 |
| persia | Right. That's just me not understanding linaro-image-tools. Sorry. | 14:48 |
| lool | persia: 660811 > yes | 14:51 |
| lool | albeit I think the bug tasks are bogus | 14:51 |
| persia | What's wrong with the bug tasks? | 14:53 |
| lool | it says linux | 14:55 |
| persia | I thought that omap3 kernels were produced by the linux source package for both maverick and natty. | 14:55 |
| ogra | right | 14:58 |
| ogra | just not for lucid | 14:58 |
| lool | Yeah, but I think Andy is commenting for the Linaro kernel | 15:00 |
| persia | Ah, so maybe it needs some linux-linaro tasks as well? | 15:01 |
| persia | But we ought get that patch into linux anyway: regressions are bad. | 15:01 |
| lool | I've checked all trees and added missing tasks | 15:02 |
| lool | the linux task is still needed | 15:02 |
| ogra | hrw, just uploaded a little present for you ;) | 15:06 |
| hrw | ogra: flash-kernel finally? | 15:12 |
| ogra | :) | 15:12 |
| lool | 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 |
| persia | And needs a merge with upstream :) | 15:22 |
| ogra | upstream only adds unused arches | 15:24 |
| ogra | else i would have done it | 15:24 |
| persia | There's some code-safety and syntax improvements as well. | 15:25 |
| lool | ogra: what did you do of the check_subarch part in the end? | 15:25 |
| ogra | 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 | 15:25 |
| ogra | lool, nothing yet | 15:25 |
| ogra | i need the right data first | 15:25 |
| * ogra hasnt run .38 yet | 15:26 | |
| ogra | lool, and i have no real idea what to do about -omap vs -omap4 atm | 15:26 |
| persia | Could we just allow *both* "omap" and "omap4" for omap4 hardware? | 15:27 |
| ogra | its about the uname check | 15:27 |
| persia | Or does this go back to the earlier discussion, and I should ignore it this time? | 15:27 |
| ogra | not sure | 15:28 |
| ogra | its quick fix vs proper implementation i think | 15:28 |
| ogra | the latter is as you stated not natty | 15:28 |
| persia | What? | 15:28 |
| persia | I said that doing devicetree mapping of capabilities was not-natty. | 15:28 |
| lool | there are three subarch concepts in Ubuntu's flash-kernel (and two in Debian's) | 15:28 |
| ogra | lool, yes, the third one is NCommander's subarch detection | 15:29 |
| persia | 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. | 15:29 |
| ogra | which as i stated above in the discussion just a way of ignoring subarch detection and spilling a message on certain arches | 15:29 |
| lool | 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 | 15:29 |
| ogra | then there are four, not three | 15:30 |
| persia | What? Where is the fourth? | 15:30 |
| lool | 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 | 15:30 |
| sveinse | Where are the logs for this channel located? | 15:31 |
| ogra | persia, two debian ones, plus ubuntus vmlinuz plus ignoring arch check completely on dove, omap and omap4 | 15:31 |
| persia | I'd also like to add selectable-flash-recipe to that conffile, and get away from the tight integration of machine and flash-recipe. | 15:31 |
| lool | sveinse: usually irclogs.ubuntu.com is the place for ubuntu chans | 15:32 |
| persia | ogra, No. $running_subarch is the one that is used to ignore things. It's not a fourth one. | 15:32 |
| ogra | lool, agreed | 15:32 |
| lool | 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 | 15:33 |
| lool | 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 | 15:33 |
| persia | 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. | 15:34 |
| persia | 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. | 15:35 |
| lool | Yeah | 15:36 |
| lool | 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 | 15:37 |
| lool | or risking to break systems | 15:37 |
| * ogra is eager to see functions and hw database separated as a first step | 15:37 | |
| lool | that's what I'm working on ATM | 15:38 |
| lool | it's really a lot of work though | 15:38 |
| ogra | cool ! | 15:38 |
| ogra | yeah | 15:38 |
| janimo | lool, still in bash ? | 15:38 |
| lool | well, in POSIX shell | 15:38 |
| ogra | hopefully | 15:38 |
| lool | janimo: I don't really mind :-) | 15:38 |
| lool | there are some painful points I admit | 15:38 |
| * ogra prefers shell | 15:39 | |
| lool | but I always liked shell, I'm a bit of a masochist | 15:39 |
| janimo | well it i s great for the seemless integration with the OS and running commands, but it is not a sane programming language | 15:39 |
| janimo | part of the reason why flash-kernel is spaghetti | 15:39 |
| lool | I tend to disagree | 15:39 |
| lool | Debian's flash-kernel is actually readable, just has a lot of code duplication | 15:39 |
| lool | and I would hope my reworked code is even more readable | 15:40 |
| ogra | ubuntu isnt so much | 15:40 |
| ogra | thats the issue ... we added on top of debians and not always in the most appropriate way | 15:40 |
| lool | 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 :-/ | 15:43 |
| NCommander | lool: just adjust your tabstop to 2 or something; its why I prefer tabs to spaces | 15:55 |
| persia | NCommander, So, about generic subarch and the lack of apparent relationship between SoC and flashing-recipe. What's your opinion? | 15:56 |
| NCommander | persia: I'm not quite sure I follow | 15:57 |
| persia | 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. | 15:58 |
| ogra | NCommander, did you read backlog of the last hours ? | 15:59 |
| persia | 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. | 15:59 |
| ogra | (if not, i would suggest to do so) | 15:59 |
| NCommander | ogra: I didn, but still confused | 15:59 |
| NCommander | persia: I disagree, the install scripts should be smart enough to detect what's present and properly install based on that | 16:00 |
| persia | What sort of detection do you imagine? | 16:01 |
| persia | 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. | 16:03 |
| NCommander | persia: on devices we support, we assume the bootloader is uboot, and its installed to the SD card or NAND | 16:03 |
| NCommander | its straightforward to check if the bootloader is there, and if so, write boot files | 16:04 |
| persia | So, why does ogra claim this breaks some devices? | 16:04 |
| ogra | it breaks the blaze | 16:04 |
| NCommander | ogra: ?, for blaze we simply write to SD card, same as panda | 16:05 |
| ogra | doesnt work with emmc | 16:05 |
| ogra | the device names are different | 16:05 |
| ogra | you have assigned the bug, read it | 16:05 |
| NCommander | 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 | 16:06 |
| * ogra sighs | 16:06 | |
| NCommander | ogra: am I wrong about supportng the eMMC for booting? | 16:08 |
| ogra | it should not break at least,. please read the bug | 16:08 |
| NCommander | ogra: care to provide a link? | 16:08 |
| ogra | it think it was discussed teher since maverick | 16:08 |
| * GrueMaster looks | 16:11 | |
| NCommander | 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 | 16:11 |
| GrueMaster | I think it is Bug #626749 | 16:12 |
| ubot2 | 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 | 16:12 |
| persia | 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? | 16:12 |
| * NCommander can't | 16:13 | |
| persia | What about Touchbook & Beagle, discussed earlier. | 16:13 |
| persia | Apparently they have the same cpuinfo | 16:14 |
| GrueMaster | persia: The hard part about this is platform availability. | 16:14 |
| persia | GrueMaster, Why? | 16:14 |
| GrueMaster | If you don't have one, makes it hard to support. | 16:14 |
| NCommander | 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 | 16:14 |
| NCommander | the bug GrueMaster references is simply the code tries to write to NAND unconditionally if theres no configuration info | 16:15 |
| NCommander | which is a bug | 16:15 |
| GrueMaster | NCommander: That assumes /etc/flash-kernel.conf. | 16:15 |
| NCommander | GrueMaster: which exists if somene installed with one of our images | 16:15 |
| persia | 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. | 16:15 |
| GrueMaster | persia: I was referring to the current code, which is not flexible. | 16:16 |
| persia | 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" | 16:17 |
| ogra | persia, beagle C vs XM | 16:18 |
| persia | ogra, What's the difference in recipe for those? | 16:18 |
| ogra | stop using the touchbook example ;) | 16:18 |
| ogra | NAND vs SD boot | 16:18 |
| GrueMaster | persia: Beagle C has nand, XM doesn't. | 16:18 |
| ogra | identical cpuinfo | 16:18 |
| GrueMaster | Physically. | 16:18 |
| hrw | ogra: same rev too? | 16:18 |
| persia | Better example. | 16:18 |
| NCommander | ogra: GrueMaster: so you detect for NAND and use it if its available if something isn't set in flash-kernel.conf | 16:19 |
| hrw | NCommander: how you check for nand? | 16:19 |
| hrw | NCommander: /proc/mtd? | 16:19 |
| GrueMaster | 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. | 16:20 |
| NCommander | hrw: yeah and the device in /dev/* | 16:20 |
| hrw | NCommander: "modprobe mtdram" and your test will fail | 16:20 |
| persia | Indeed. | 16:20 |
| persia | Alternately, modprobe nandsim | 16:21 |
| GrueMaster | Will that work in the case of Tegra? | 16:22 |
| persia | Tegra will hit the hardcoded path | 16:22 |
| GrueMaster | Or other systems where the user may not want to kill nand? | 16:22 |
| NCommander | persia: so you think then generic subarch should die and shelf it as a spec? | 16:23 |
| persia | Well, I'm not sure about that. | 16:24 |
| persia | 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. | 16:24 |
| NCommander | persia: you've just made a very convincing case that its not going to have a wide swatch of support | 16:24 |
| NCommander | persia: right | 16:24 |
| persia | 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. | 16:25 |
| ogra | NCommander, it shouldnt die but needs more detailed testing for devices | 16:25 |
| persia | 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. | 16:25 |
| NCommander | 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. | 16:26 |
| NCommander | 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 | 16:26 |
| NCommander | I will be monitoring the situation .Thanks for the heads up all | 16:26 |
| NCommander | argh | 16:26 |
| NCommander | I really need to hack Xorg.conf and remove this stupid pasting behavior | 16:26 |
| ogra | ?? | 16:26 |
| NCommander | persia: a lot of boards can't be easily told apart, Beagle and BeagleXM both identify themselves as Beageboard in /proc/cpuinfo | 16:27 |
| ogra | heh, yeah, you should | 16:27 |
| persia | NCommander, Right, and I've come to believe that this is even more widely true in retail devices based on various platforms. | 16:27 |
| ogra | NCommander, right, so we need to find a better solution on top of the cpuinfo | 16:27 |
| ogra | cpuinfo is good but not enough | 16:27 |
| persia | So, because we can't tell them apart, we should provide a menu of recipes, and default best we can. | 16:28 |
| persia | And leave the rest for documentation. | 16:28 |
| NCommander | persia: ugh, that's fugly, and adds a lot of complexity to user installs | 16:28 |
| persia | For most users, it should be pressing enter once for confirmation. | 16:28 |
| NCommander | persia: for most users, they won't know the difference | 16:29 |
| persia | For a few users, it may be more complicated, but the alternative is to force them to hack things together manually. | 16:29 |
| GrueMaster | Maybe using a separate conf file would be better. That way, it can be more easily updated without package rebuilding. | 16:29 |
| NCommander | If we can't do it automatically, then I rather not do it | 16:29 |
| ogra | i would prefer better automation before we resort to interaction | 16:29 |
| ogra | but its a good last resort | 16:29 |
| persia | And we already have too many complaints about stuff that we know is broken because someone didn't perform a regular install. | 16:29 |
| GrueMaster | By conf file, I mean a file with a list of supported platforms that can be easily updated. | 16:29 |
| persia | I'm happy with something like debconf-priority-low: adjustable, but not shown by default. | 16:30 |
| hrw | looks like you will end with database keeping lot of scripts which will check which exactly hardware it is run on | 16:32 |
| hrw | 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" | 16:33 |
| persia | Why? | 16:33 |
| persia | I imagine having install-to-NAND, install-to-SD, etc. Just a few recipes. Then, some routine that picks a reasonable recipe. | 16:34 |
| GrueMaster | The biggest problem is system identification. cpuinfo just isn't always enough. | 16:34 |
| ogra | it is enough as a base but not for details | 16:35 |
| sveinse | let me get this right: The problem is how to write the kernel image into NAND or MMC (FAT partition) or similar, right? | 16:36 |
| persia | Kinda. | 16:36 |
| GrueMaster | More of how to detect which to use. | 16:36 |
| persia | 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. | 16:37 |
| sveinse | 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 | 16:39 |
| * sveinse wish the HW bootloader in the SoC could read sector 0 from NAND or MMC and behave like a PC bootloader. Maybe. | 16:41 | |
| persia | sveinse, Take a look at the flash-kernel package. Both flash-kernel and debian/flash-kernel-installer-postinst are interesting. | 16:42 |
| * sveinse is reinventing the wheel... | 16:44 | |
| persia | Can't have that :) | 16:45 |
| ogra | more wheels !!! | 16:47 |
| rcn-ee_at_work | hrw, amount-of-ram might not be the best, there's "white label" c4 boards with 512Mb. ;) | 16:47 |
| hrw | ~/cr | 16:47 |
| hrw | rcn-ee_at_work: nice | 16:47 |
| sveinse | I'm a little curious about bug 705689. Does anyone knows if this will result in a patch & update for armel-cross 4.5 ? | 16:49 |
| ubot2 | 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 | 16:49 |
| lool | 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 | 16:49 |
| rcn-ee_at_work | hrw, you can get it from dmesg, since the gpio detect is printed out.. | 16:49 |
| rcn-ee_at_work | hrw, dmesg | grep "Beagle Rev:" | 16:50 |
| hrw | rcn-ee_at_work: how you check dmesg on machine which works for 2 months and have /var/log/dmesg removed? | 16:50 |
| sveinse | lool, the FAT load from MMC is a HW bootloader implementation in OMAP, iirc | 16:51 |
| rcn-ee_at_work | hrw, not easy.. userspace progam to read all 3 gpio pins? | 16:51 |
| rcn-ee_at_work | 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" | 16:53 |
| lool | 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 | 16:53 |
| lool | sveinse: So concretely, you have different constraints on the data / location from different SoCs | 16:53 |
| lool | You could arrange for writing the first sectors on a lot of SoCs though | 16:53 |
| GrueMaster | lool: WOuld it make sense for MLO to setup an area in memory that could be read by userspace similar to dmidecode? | 16:54 |
| rcn-ee_at_work | hrw, yeap it is.. http://pastebin.com/5WP3TSiK (comparsion of c4/xM) | 16:55 |
| persia | Something like dmidecode would be nice. I wish all architectures had it. | 16:57 |
| ogra | thats easy | 16:57 |
| ogra | just add a BIOS to all arches :) | 16:58 |
| sveinse | well, the dmi info is actually in concept the same as the machine id we talked about earlier | 16:58 |
| lool | GrueMaster: what kind of data do you intend to provide? | 16:58 |
| lool | I think UEFI has provisions to pass various data | 16:58 |
| ogra | lool, device lists ? | 16:58 |
| hrw | rcn-ee_at_work: thx | 16:58 |
| lool | Well, concerning tables of devices, we're leaning towards device tree | 16:59 |
| TheUni_ | rsalveti: around? | 16:59 |
| ogra | lool, i think devicetree will solve that anyway | 16:59 |
| GrueMaster | Basic hardware info, similar to what dmidecode provides. Like what busses are available, what the system is, etc. | 16:59 |
| GrueMaster | If/when it appears. | 16:59 |
| hrw | ogra: I have x86 which does not use efi and can be booted even without bios | 16:59 |
| persia | lool, Will I be able to get stuff like Manufacturer, Product Name, etc. from devicetree? | 16:59 |
| GrueMaster | I have been hearing about devicetree since 2009. | 16:59 |
| ogra | hrw, pfft, prototypes | 16:59 |
| ogra | hrw, btw, my booking is finally confirmed i'll arrive on sunday evening | 17:00 |
| hrw | ogra: no, on-the-shelf hardware | 17:00 |
| hrw | ogra: with coreboot | 17:00 |
| lool | 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 | 17:00 |
| ogra | hrw, how do you remove the BIOS from that ? | 17:01 |
| sveinse | In all cases, having dmiinfo or devicetree, will imply that the MLO or bootloader must setup the information uniquely for each HW and revision. | 17:01 |
| GrueMaster | hrw: The difference there is all x86 cpu's fetch from the same location for booting. Not so with arm. | 17:01 |
| lool | sveinse: Correct, or the firmware | 17:01 |
| hrw | ogra: coreboot ;D | 17:01 |
| lool | GrueMaster: ah but you define booting as after the BIOS | 17:02 |
| persia | lool, OK. That's the information I wanted from dmidecode, but I don't really care where I get it. | 17:02 |
| hrw | ogra: coreboot can load filo or grub as payload without any bios legacy stuff | 17:02 |
| ogra | hrw, i know coreboot, i worked with it in the past | 17:02 |
| GrueMaster | lool: No I don't. I define booting as after the cpu is initialized ant goes external to fetch code. | 17:02 |
| ogra | hrw, still there is a BIOS coming up on the boards i used it | 17:02 |
| ogra | unless you remove the eprom probably | 17:03 |
| sveinse | 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 | 17:03 |
| persia | Or flash coreboot into the eeprom | 17:03 |
| persia | 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. | 17:04 |
| persia | Some devices support OpenFirmware, and some second-stage bootloaders were ported in the past, but nothing recent has separated stages. | 17:04 |
| sveinse | persia, I have yet too see a SoC device booting directly into linux kernel. All I've encountered so far have two stage boots | 17:05 |
| sveinse | As lool said, the DDR needs to be setup and the kernel command line, and so on by the bootloader | 17:06 |
| hrw | sveinse: iirc on omap3 you can add header to kernel image which will setup ddr etc (which xloader does normally) and boot | 17:07 |
| hrw | sveinse: kernel cmdline needs to be hardcoded in kernel | 17:07 |
| ogra | only on 3530, not ? | 17:07 |
| sveinse | it is? hmm. I need to check my sources... | 17:07 |
| persia | 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. | 17:08 |
| sveinse | ah, then I agree | 17:08 |
| hrw | bios -> grub -> kernel or chiprom -> xloader -> uboot -> kernel... | 17:09 |
| persia | So, EFI/grub or OF/yaboot, etc. (although I think we'll switch to OF/grub for natty powerpc, but I may be mistaken) | 17:09 |
| GrueMaster | persia: On x86 images, we currently have 3 stages: bios, bootloader (lilo, grub, etc), kernel. | 17:09 |
| GrueMaster | It is possible for x86 to have one: Linux-bios. | 17:09 |
| hrw | anyway it is time for me | 17:09 |
| sveinse | In fact when doing OMAP MMC boot its 3 stages as well: MLO -> Uboot -> Kernel | 17:09 |
| hrw | sveinse: mlo is read by inchip code | 17:10 |
| GrueMaster | On SOC's, most fetch from an internal rom on the SOC, then fetch from there. | 17:10 |
| sveinse | hrw, do you know anything about the 4.5 gcc bug in respect of Qt? | 17:10 |
| persia | 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. | 17:10 |
| hrw | sveinse: no | 17:10 |
| * hrw -> out | 17:10 | |
| hrw | have a nice rest of day people | 17:10 |
| GrueMaster | Actually omap/omap4 is 4 stage by that logic: SoC ROM, MLO, u-boot, kernel. | 17:11 |
| persia | The SoC ROM is stage-0, by my nomenclature. | 17:12 |
| persia | x86 BIOS would be stage-1 | 17:12 |
| GrueMaster | Ok, in binary you are correct. | 17:12 |
| persia | silo would be stage-2 | 17:12 |
| GrueMaster | :p | 17:12 |
| sveinse | 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 | 17:12 |
| GrueMaster | X86 always fetches from CS:IP F000:FFF0 | 17:12 |
| GrueMaster | Or the end of 1M. | 17:13 |
| sveinse | uboot is not efficient if you are waiting for it :D | 17:13 |
| sveinse | GrueMaster: If ARM always fetched from the same addr, would that help us in any way? | 17:16 |
| GrueMaster | Might. | 17:16 |
| GrueMaster | I don't know much about arm architecture, but I believe it may already. Just most SoC vendors put rom code there on die. | 17:17 |
| GrueMaster | Which can't be changed. | 17:17 |
| sveinse | 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 | 17:18 |
| GrueMaster | With x86, it is the flash-rom chip on most systems. | 17:18 |
| sveinse | So the question is more to agree upon some dmi-like struct that needs to be setup prior to kerel boot | 17:18 |
| GrueMaster | http://en.wikipedia.org/wiki/Booting has some interesting details on this. | 17:18 |
| GrueMaster | sveinse: right. That would need to be done by MLO/u-boot. | 17:19 |
| sveinse | yes, | 17:19 |
| GrueMaster | Or the kernel if it is used directly (which may happen in the future). | 17:19 |
| sveinse | In concept, arm has one (1) dmi-like information: MachineID. Period | 17:19 |
| GrueMaster | 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. | 17:21 |
| GrueMaster | Things like pci devices, drives, memory boards, etc. | 17:21 |
| sveinse | Out of interest: How is that done? (I dont mean PCI and USB devices, because they have well defined ID's attached to them) | 17:22 |
| GrueMaster | Each vendor uses core bios code from one of the bios vendors (ami, phoenix, etc) and adds board specific information to it. | 17:23 |
| GrueMaster | 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. | 17:24 |
| sveinse | and how is this any different from arm's machineid ? | 17:24 |
| GrueMaster | I'd have to look, but the machine ID is very limited in what it contains. | 17:25 |
| GrueMaster | Does it change between Beagle C4 and other devices using the same CPU? | 17:25 |
| sveinse | Yes, that I agree. You'd need some database to provide the extra information, like how to update the kernel | 17:26 |
| persia | 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). | 17:26 |
| sveinse | And it does not support extra information, like revision number. I would love to see that feature added. And call it dmi info | 17:26 |
| persia | 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) | 17:27 |
| sveinse | OF? Do you have any references to that? | 17:28 |
| persia | OpenFirmware | 17:28 |
| persia | You can look at the openhackware package for an example implementation: that one targets qemu's powerpc. | 17:28 |
| GrueMaster | 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. | 17:29 |
| persia | That's expected: Hardware and Revision are the lines that are checked for all device-specific stuff. | 17:30 |
| GrueMaster | Oh, and bogomips. (for some reason my droid is running at 249 - odd). | 17:30 |
| sveinse | 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 | 17:31 |
| persia | 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. | 17:31 |
| persia | 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. | 17:31 |
| persia | GrueMaster, bogomips are intentionally bogus: ignore those. | 17:32 |
| GrueMaster | persia: Checking Hardware and Revision isn't enough. In the example of Beagle C4 & BeagleXM, they are the same. | 17:32 |
| GrueMaster | ok | 17:32 |
| rcn-ee_at_work | GrueMaster, the droid has pm scaling working, hence the low bogomips.. | 17:32 |
| sveinse | the revision in /proc/cpuinfo only gives the SoC revision not the board's, iirc | 17:32 |
| rcn-ee_at_work | 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... | 17:33 |
| persia | 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 | 17:34 |
| rcn-ee_at_work | GrueMaster, you need to check the "varient' and "revision" to differentiate the beagle's... http://pastebin.com/5WP3TSiK | 17:37 |
| GrueMaster | Yes, I know. | 17:38 |
| GrueMaster | rcn-ee_at_work: That is for the cpu only, right? The Hardare lines are board specific? | 17:39 |
| rcn-ee_at_work | yeap, cpu only... the hardware line comes from the board-omap3beagle.c file.. | 17:39 |
| sveinse | gpio pin probed, right? | 17:40 |
| rcn-ee_at_work | no, the cat /proc/cpuinfo is pure processor.. the gpio pin probed is just dumped to dmesg on bootup.. | 17:41 |
| prpplague | anyone know if andy green is on irc? | 17:41 |
| GrueMaster | rcn-ee_at_work: So there is no way for software to detect hardware differences then? | 17:44 |
| rcn-ee_at_work | 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.. | 17:46 |
| rcn-ee_at_work | (like what is already done in the board-omap3beagle.c ..) | 17:47 |
| rcn-ee_at_work | 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? | 17:49 |
| lool | prpplague: He is agreen on IRC an hangs on #linaro from time to time, but not all the time | 17:51 |
| lool | prpplague: He is on ATM | 17:51 |
| prpplague | lool: thanks found him | 17:51 |
| GrueMaster | 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. | 17:53 |
| GrueMaster | Having MLO with the proper info could allow that. | 17:53 |
| persia | GrueMaster, linaro is working on such a beast. | 17:53 |
| GrueMaster | Cool. | 17:54 |
| rcn-ee_at_work | 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.. | 17:55 |
| GrueMaster | The next step would be to have some way for userspace to get more info on the platform, similar to dmidecode. | 17:58 |
| persia | devicetree | 17:58 |
| persia | And I think linux-linaro-omap already has the necessary bits to boot on all omap3/4 devices. | 17:59 |
| GrueMaster | ok, then all that needs to happen is for it to fall in my lap for rigorous testing. :P | 17:59 |
| persia | Well, you can grab linux-linaro-omap today, and see if that works. | 18:00 |
| persia | The devicetree stuff seems to still be future. | 18:00 |
| persia | (but getting *very* close) | 18:00 |
| rcn-ee_at_work | 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.. | 18:01 |
| GrueMaster | If I get bored, I might see if I can fire up my babbage with a more recent kernel/image. if... | 18:02 |
| GrueMaster | :P | 18:02 |
| rcn-ee_at_work | for kicks.. what's the best supported imx51 target in mainline right now? | 18:04 |
| GrueMaster | I think it is the Efika Netbook. Apparently linaro got a bunch. I missed out. :( | 18:05 |
| * GrueMaster never gets cool hardware, only semi-functional development systems | 18:06 | |
| persia | They are available retail. | 18:09 |
| * persia has purchased any number of retail ARM devices now | 18:09 | |
| persia | 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. | 18:09 |
| persia | rcn-ee, mainline, best supported is still the Babbage for imx51. | 18:10 |
| sveinse | What is the relationship between the ubuntu native (and armel-cross) compiler and the one provided by linaro? | 18:53 |
| ogra | they are the same | 18:53 |
| ogra | linaro maintains the arm toolchain in ubuntu | 18:53 |
| sveinse | ah, ok. thanks | 18:54 |
| sveinse | 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? | 18:56 |
| lool | sveinse: Ubuntu gcc-4.x includes the Linaro patchset + Ubuntu patches; cross compilers are built from the exact same sources, but less frequently | 18:57 |
| sveinse | 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 | 18:59 |
| ubot2 | 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 | 18:59 |
| lool | 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 | 18:59 |
| lool | sveinse: well we're not developping 4.4 any further in Linaro | 18:59 |
| lool | sveinse: and it will eventually go away | 18:59 |
| martyn | Is there a wiki page describing how the OMAP4 server image is meant to be installed? | 18:59 |
| sveinse | ah, that's an answer, thanks | 18:59 |
| martyn | Hey there lool | 19:00 |
| persia | 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. | 19:01 |
| lool | hey martyn | 19:01 |
| persia | 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. | 19:03 |
| persia | Err, rather, *if* there existed a wiki page about it, it would have two answers ... | 19:03 |
| * persia believes such a page doesn't currently exist | 19:03 | |
| martyn | i.e. "don't bother, not even ready for alpha" | 19:03 |
| martyn | "use rootstock" | 19:03 |
| persia | Um, no. | 19:03 |
| persia | The main issue is that nobody is working on it. If you want to do it, it's not that hard to get working. | 19:04 |
| martyn | I know, but right this second, I'm teaching someone how to get a system image up .. more about expediency | 19:04 |
| persia | 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. | 19:05 |
| persia | 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. | 19:05 |
| persia | Post-boot, migrate /var and /srv to some real storage device, and reboot. | 19:06 |
| martyn | Heh.. I'm trying for Versatile Express | 19:06 |
| martyn | so the image has nothing bootable for me | 19:06 |
| GrueMaster | interesting. | 19:06 |
| persia | martyn, If you want to use non-archive kernels, rootstock is your best option. When are you uploading a kernel to the archive? | 19:06 |
| martyn | not just a versatile express either .. but one that's been chopped up and reformed into a Calxeda system | 19:06 |
| martyn | persia: Not for a while yet .. probably not till .39 | 19:07 |
| persia | So, natty+1? | 19:07 |
| martyn | better answer would be 'once we have silicon in house' | 19:07 |
| persia | heh. | 19:07 |
| martyn | because before then, it's all based on simulation, fpga, hard engineering, and good intentions | 19:07 |
| persia | 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. | 19:08 |
| === ian_brasil__ is now known as ian_brasil | ||
| === TheUni_ is now known as TheUni | ||
| persia | apachelogger, thumb2 support is presumed for every Ubuntu armel device | 21:53 |
| apachelogger | persia: ok | 21:58 |
| apachelogger | NCommander: I get segfaults for every kde app all within Qt, ScottK suggests that you said it is a gcc bug? | 21:58 |
| apachelogger | on the n900 that is | 21:58 |
| NCommander | apachelogger: no, thats NEON built into Qt by accident. Will be fixed when 4.7.2 is uploaded | 21:59 |
| apachelogger | NCommander: the n900 cpu supports neon though? | 22:00 |
| NCommander | apachelogger: oh ... hrm ... it does, doesn't it | 22:00 |
| apachelogger | it did with maverick ^^ | 22:00 |
| * apachelogger installs libqt4-dbg | 22:01 | |
| GrueMaster | apachelogger: it may be related to the recent precompiled header bug we found. | 22:01 |
| ScottK | That's the one I was referring to I think. | 22:01 |
| robclark | 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? | 22:02 |
| persia | robclark, I believe it's just a hidden partition. | 22:04 |
| persia | Why do you want it mounted? | 22:04 |
| robclark | how does one make a partition hidden/unhidden? | 22:04 |
| ogra | robclark, /sbin/mkdosfs -n "SERVICEV001" -F 32 ${ROOTDEV}1 | 22:04 |
| persia | fdisk :) | 22:04 |
| ogra | just rename ti | 22:04 |
| ogra | *it | 22:04 |
| robclark | ok, so just based on the partition name | 22:04 |
| ogra | yep | 22:04 |
| robclark | it is more convenient to copy over new kernels when I'm mucking with stuff it it mounts itself ;-) | 22:05 |
| ogra | note that you will have it permanently on your desktop once renamed | 22:05 |
| robclark | no prob | 22:05 |
| robclark | that is what I want | 22:05 |
| ogra | k | 22:05 |
| robclark | thx :-) | 22:05 |
| persia | ogra, It's not a hidden partition? Why not? | 22:05 |
| ogra | persia, the naming hides it | 22:05 |
| ogra | udev ignores it completely that way | 22:05 |
| ogra | we dont want to hide it from mount but prevent automounting | 22:06 |
| persia | It seems to me that you're using a hack that accidentally works rather than using the partition table as it was designed. | 22:06 |
| apachelogger | GrueMaster: what bug is that? | 22:08 |
| GrueMaster | persia: Actually, this is a predefined use case in udev. It is mainly to hide pre-installed partitions. | 22:08 |
| persia | GrueMaster, Doesn't make me like it any more, but yeah, it's because of a common naming scheme for certain OEM restore partitions. | 22:09 |
| GrueMaster | apachelogger: Bug 705689 | 22:10 |
| ubot2 | 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 | 22:10 |
| apachelogger | GrueMaster: 4:4.7.1-0ubuntu9 ought to be built agianst 4.4 though | 22:10 |
| apachelogger | oh | 22:10 |
| apachelogger | nevermind me, apparently I have ubuntu7 :O | 22:11 |
| GrueMaster | heh | 22:11 |
| GrueMaster | You had me doing a double-take. Had to check my panda. | 22:12 |
| ogra | lool, does: check_subarch "imx51" look ok for the efika stuff ? | 22:46 |
| lool | ogra: Dunno | 23:45 |
| lool | ogra: I don't know Ubuntu's flash-kernel | 23:46 |
| apachelogger | GrueMaster: ubuntu9 does not seem to fix the issue though :S | 23:47 |
| persia | apachelogger, Everything linked against qt4-x11 is still segfaulting apparently randomly? | 23:52 |
| apachelogger | I wouldn't say random... it *always* segfaults | 23:52 |
| apachelogger | gdb says it is in kdeui though ... getting rid of that and trying again now | 23:52 |
| ogra | lool, well, you complained at the bug | 23:54 |
| apachelogger | righto | 23:56 |
| apachelogger | persia: something is fishy with current qt combined with kdelibs | 23:56 |
| persia | 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. | 23:56 |
| apachelogger | persia: a rebuild could indeed fix this, as some kdelibs stuff is sort of used as plugin for Qt (e.g. fileopen dialogs) | 23:57 |
| apachelogger | without kdelibs unity-2d starts without segfault | 23:57 |
| lool | 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 | 23:58 |
| lool | + #check_subarch $running_subarch | 23:58 |
| persia | Was unity-2d rebuilt against ubuntu9? | 23:58 |
| apachelogger | yep | 23:59 |
| lool | ogra: does that make sense now? | 23:59 |
| apachelogger | persia: ubuntu9 was uploaded feb 7, unity-2d feb 15 | 23:59 |
| lool | ogra: I just looked at the diff, I don't know how running_subarch should be handled | 23:59 |
| persia | Well, that's annoying. On the bright side, most of the base of KDE FTBFS anyway currently, so it needs to be rebuilt. | 23:59 |
| apachelogger | hmm | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!