| persia | lool: Needs work on options to handle both --arch powerpc and --arch=powerpc, but looks lovely otherwise. | 00:21 |
|---|---|---|
| persia | Ugh. No it doesn't. Looks bug-for-bug compatible with debootstrap :( | 00:29 |
| persia | Anyway, you shipped it, and it looks good, and I'll make the tools use it. | 00:30 |
| persia | ( well, unless system_arch == amd64 && deb_arch == i386 | lpia ) | 00:31 |
| aaron | morning all | 01:43 |
| aaron | i'm coming again | 01:46 |
| aaron_liuj | how to use the qemu in the rootstock | 03:32 |
| persia | You'll have to wait at least 5 hours for good rootstock support. | 03:34 |
| === DanaG1 is now known as DanaG | ||
| tkmedia | hi guys i dont see the mini2440 as being a supported board is possible and just untested ? | 05:47 |
| * persia tries to figure out what a "mini2440" is | 05:49 | |
| persia | tkmedia: It might be able to run Jaunty, but nothing newer. | 05:49 |
| persia | I'd recommend using Debian on that platform. | 05:49 |
| persia | (assuming we're talking about a board with a Samsung S3C2440A ARM920T ) | 05:50 |
| tkmedia | yes thankyou | 05:50 |
| persia | Glad to help. If you decide to run Jaunty, the install may be a bit tricky, but ought work. | 05:50 |
| tkmedia | intrepid actually would be nice | 05:51 |
| persia | If you decide to run Debian, the install may be a bit tricky, but you should have continued support for longer (Jaunty runs out of support in October). | 05:51 |
| persia | Intrepid wasn't compiled for armel. | 05:51 |
| tkmedia | k | 05:51 |
| tkmedia | whats the best way to try jaubty | 05:52 |
| tkmedia | juanty | 05:52 |
| persia | Do you have a working 2.6.28 or newer kernel for the board? | 05:53 |
| tkmedia | 2.6.29 | 05:54 |
| persia | That ought work. | 05:54 |
| persia | Do you have a local Ubuntu install from which to prep stuff? | 05:54 |
| persia | (if so, which release?) | 05:54 |
| tkmedia | i have severla vm's | 05:54 |
| tkmedia | ones a 0910 | 05:55 |
| persia | OK. So the easiest way to get a rootfs is probably to run rootstock in the 9.10 environment. | 05:55 |
| tkmedia | yep did that | 05:55 |
| persia | And you created a jaunty rootfs? | 05:55 |
| tkmedia | hmm let me chk | 05:56 |
| tkmedia | i used the example | 05:56 |
| tkmedia | with minal lxde | 05:56 |
| persia | Which example? | 05:57 |
| tkmedia | top | 05:57 |
| persia | From which page? | 05:57 |
| tkmedia | sec | 05:57 |
| tkmedia | sudo rootstock \ | 05:58 |
| tkmedia | --fqdn myhostname \ | 05:58 |
| tkmedia | --login ubuntu \ | 05:58 |
| tkmedia | --password temppwd \ | 05:58 |
| tkmedia | --imagesize 2G \ | 05:58 |
| tkmedia | --seed xubuntu-desktop | 05:58 |
| tkmedia | but changed seed | 05:58 |
| tkmedia | to lxde | 05:58 |
| persia | Right. | 05:58 |
| tkmedia | ,gdm | 05:58 |
| tkmedia | so that should work with the .29 kernel right? | 05:59 |
| persia | Yes, but. | 05:59 |
| persia | You want to add --dist jaunty | 06:00 |
| tkmedia | kernel panic | 06:00 |
| persia | The default is --dist karmic | 06:00 |
| tkmedia | ahhh | 06:00 |
| persia | And that will generate binaries that include instructions not supported on your chip. | 06:00 |
| tkmedia | ok cool | 06:00 |
| persia | So try again, and if that doesn't work, please ask again. | 06:01 |
| tkmedia | so thats why i got kernel panic ? | 06:01 |
| persia | I'm not sure, but possibly. How did you construct your kernel? | 06:01 |
| persia | Are you sure your kernel works? | 06:01 |
| tkmedia | yes | 06:01 |
| tkmedia | let mtry with dist-juanty | 06:02 |
| persia | If you're sure the kernel works, then yeah, I'd blame the rootfs, especially if I expected the rootfs to generate instructions the processor can't handle. | 06:02 |
| persia | "jaunty" | 06:02 |
| tkmedia | and will be back if any more questions | 06:02 |
| tkmedia | thanks | 06:02 |
| persia | Good luck! | 06:02 |
| tkmedia | so just -dist jaunty on the bottom | 06:03 |
| tkmedia | added | 06:03 |
| DanaG | hmm, weird thing about the rcn-ee images: the ubuntu username isn't uid 1000. | 06:12 |
| DanaG | same for GID: not 1000. | 06:12 |
| StevenK | DanaG: It isn't on the Live CD either, since that would conflict with installed systems | 06:49 |
| StevenK | (And then you could potientally read other users files) | 06:49 |
| DanaG | Though, with livecd, you can read them anyway, as root. | 06:52 |
| DanaG | And the UID was like 1002 (which still could collide), and the image was an installed system. | 06:52 |
| StevenK | Right, but that falls under "You have physical access, so ..." | 06:53 |
| DanaG | Oh, and the UID of things like "fuse" were different too. | 06:55 |
| DanaG | I fiddled with the things a bit, and made them match better (along with finding files that were owned by corresponding old UID, and chowning them. | 06:55 |
| gevz | hello | 06:58 |
| gevz | can somebody help me? | 07:00 |
| DanaG | go ahead and ask the issue itself, instead of just asking if anyone's around. =รพ | 07:02 |
| gevz | ok, I have PDA Asus A363 can I install ubuntu on this device? | 07:05 |
| DanaG | hmm, you'd have to find out more about what the chip is, for one. | 07:06 |
| gevz | one moment | 07:07 |
| gevz | processor type - Intel XScale PXA272 416 MHz | 07:07 |
| DanaG | weird, I see nothing about "asus a363" on the internet. | 07:08 |
| DanaG | er, not "nothing", but not too much. | 07:08 |
| gevz | ROM 128 Mb, RAM 64 Mb | 07:08 |
| DanaG | 64 megs RAM is tiny. | 07:08 |
| DanaG | http://vip.asus.com/forum/view.aspx?id=20070507004052843&board_id=6&model=MyPal+A636&SLanguage=en-us&page=2 | 07:09 |
| gevz | :) I don`t like a Windows | 07:11 |
| gevz | I want ubuntu ;) | 07:11 |
| persia | gevz: OK. What device do you have? | 07:13 |
| gevz | A363 | 07:14 |
| persia | ASUS MyPal A363? | 07:15 |
| gevz | yes | 07:15 |
| persia | OK. According to http://www.handhelds.org/moin/moin.cgi/MyPal you should be able to run linux | 07:15 |
| persia | Or maybe not | 07:16 |
| * persia looks harder | 07:16 | |
| persia | Really a A363 and not a A636> | 07:17 |
| persia | s/>/?/ | 07:17 |
| persia | I can't find any information about the A363, unfortunately. | 07:18 |
| persia | The A626 can run Linux, but only Ubuntu 9.04 and nothing newer. | 07:18 |
| persia | The resolution is also low enough the experience may leave something to be desired. | 07:18 |
| persia | I'd recommend Debian for such a device. | 07:18 |
| gevz | oh... excuse me, I mistake | 07:18 |
| gevz | A636 | 07:19 |
| persia | Which is the mistake? | 07:19 |
| persia | Ah, that's better :) | 07:19 |
| gevz | not A363 | 07:19 |
| persia | But yeah, for the A636 you can run Jaunty if you hack it. | 07:20 |
| gevz | how i can do it? | 07:20 |
| persia | I'd recommend starting from http://www.handhelds.org/moin/moin.cgi/A636 | 07:20 |
| persia | Once you have figured out how to install linux, installing Debian or Ubuntu becomes easier. | 07:21 |
| gevz | ok, I do not quite understand where I start | 07:25 |
| gevz | this link to list of hardware, but I can`t understand how to install linux? | 07:26 |
| persia | For devices of that class, one usually has to construct a replacement firmware and proceed with the "firmware upgrade" procedure. | 07:27 |
| persia | I recommend searching for available documentation carefully, as there is a risk you can make the device unbootable. | 07:27 |
| persia | I don't see any good guides from a quick search myself. | 07:28 |
| gevz | ok, please help me | 07:28 |
| gevz | I have compiled a list of equipment, what next? | 07:29 |
| persia | I'm really not sure how to help, and don't want to give advice that will make your device useless. | 07:31 |
| persia | The next step is to understand how the device boots. | 07:32 |
| persia | Once you have that, compile a customised kernel, and get the device to boot that kernel. | 07:32 |
| persia | Once you have that, you can start considering what you want for a filesystem. | 07:32 |
| persia | But the first two steps are big ones. | 07:32 |
| gevz | What image do I download ubuntu? | 07:34 |
| persia | There exists no image of Ubuntu that will work on your hardware. | 07:34 |
| persia | You can potentially construct something that works, but it's non-trivial. | 07:34 |
| gevz | ok, thanx | 07:34 |
| Laibsch | I ran "sudo ~/bin/qemu-debootstrap --arch=armel lucid lucid-armel-chroot http://rie:3142/ports.ubuntu.com/ubuntu-ports", but the chroot sources.list file does not contain any entries for package sources. | 07:35 |
| Laibsch | Is that to be expected? | 07:35 |
| persia | Yes. | 07:35 |
| Laibsch | hm | 07:36 |
| Laibsch | please explain | 07:36 |
| Laibsch | I kind of expected the file to be populated, obviously. | 07:36 |
| persia | I don't believe debootstrap automatically populates that. | 07:36 |
| persia | So this is expected behaviour. | 07:36 |
| Laibsch | let's rephrase the question | 07:37 |
| persia | From your ability to run that command, I presume you're using lucid. | 07:37 |
| Laibsch | Shouldn't debootstrap populate the file? | 07:37 |
| persia | No. | 07:37 |
| Laibsch | why not? | 07:37 |
| Laibsch | I run lucid, yes | 07:37 |
| persia | So, if you want to create a chroot for use, I'll recommend you use `mk-sbuild --arch=armel lucid` | 07:38 |
| persia | This will work, populate everything, and give you a summary of ways to use the chroot. | 07:38 |
| Laibsch | lool: asked me to test his scripts | 07:38 |
| persia | Oh, if that's what your're doing, then you're doing it right. | 07:38 |
| Laibsch | and I don't mind a few rough edges here or there | 07:38 |
| Laibsch | why do you think debootstrap ought not to populate sources.list? | 07:40 |
| persia | because there's extensive logic in mk-sbuild to populate it after the debootstrap run. | 07:40 |
| Laibsch | gevz: you may also have a look at openembedded | 07:40 |
| gevz | what this? | 07:40 |
| Laibsch | gevz: google should tell you | 07:41 |
| gevz | I have ban on google ;) | 07:41 |
| persia | or any other search tool, really. | 07:41 |
| persia | Then use something else :) | 07:41 |
| lool | Laibsch: morning | 07:41 |
| Laibsch | gevz: OE is very well suited for your problem of getting a kernel compiled | 07:42 |
| Laibsch | lool: good morning | 07:42 |
| persia | OE is also well suited to that class of device. | 07:42 |
| Laibsch | probably | 07:42 |
| * Laibsch hopes to lower the bar for ubuntu-arm eventually | 07:43 | |
| Laibsch | But I fully support the decision to focus on more powerful devices first | 07:43 |
| persia | Laibsch: Not first: only. We expect the market to catch up with us by the time we're sorted. | 07:43 |
| Laibsch | yes, I was afraid that may be the case | 07:44 |
| Laibsch | There ain't nobody there to tell me I can't try, though ;-) | 07:44 |
| Laibsch | Speaking of which | 07:45 |
| lool | persia: (from this night) ARM920T + jaunty isn't going to work I'm afraid | 07:45 |
| Laibsch | Now that I have my armv7l chroot, how would I go about trying to compile armv5te software? | 07:45 |
| Laibsch | what knobs do I need to fiddle with? | 07:46 |
| persia | lool: No? Why not. | 07:46 |
| persia | Laibsch: You need to change the compiler defaults. | 07:46 |
| lool | Laibsch: debootstrap is now expected to create a binary sources.list, but most people don't need source entries, so it defaults to disabled for these | 07:46 |
| lool | Laibsch: sbuild usually pulls the source by its own means IIRC | 07:47 |
| lool | persia: ARM920T is v4 | 07:47 |
| persia | lool: Ah. So it needs to be ARM11+ ? | 07:47 |
| persia | I thought it was ARM9+ | 07:47 |
| lool | I think some ARM9xxs are v5, but rare | 07:47 |
| lool | Best to check the wikipedia page | 07:47 |
| persia | That makes sense. Still, I think anyone with older hardware should be running Debian anyway. | 07:47 |
| lool | yes | 07:47 |
| persia | It's frustrating to get stuck not being able to upgrade. | 07:48 |
| persia | Anyway, sbuild doesn't do anything special with sources.list. It just presumes that one exists in the chroot. | 07:48 |
| persia | mk-sbuild populates one based on the arguments it gets passed. | 07:48 |
| Laibsch | persia: where are those changed? | 07:48 |
| persia | Laibsch: Which? | 07:49 |
| Laibsch | the compiler defaults | 07:50 |
| Laibsch | so that I can compile for armv5te | 07:50 |
| persia | No idea. I'd guess in the gcc package. | 07:50 |
| Laibsch | lool: ? | 07:51 |
| Laibsch | I guess the question can be put another way | 07:52 |
| Laibsch | who changed what where to specify that lucid is armv7l? | 07:52 |
| Laibsch | I'll just turn that back locally ;-) | 07:52 |
| lool | Laibsch: gcc-4.4 package | 07:52 |
| lool | we configure it with the defaults | 07:52 |
| lool | Laibsch: I'm not sure you realize how long and complex and heavy that's going to be | 07:53 |
| lool | It's not impossible, but building gcc-4.4 takes days espcially under qemu or older v5 hardware | 07:53 |
| Laibsch | probably | 07:53 |
| lool | Then you need to bootstrap everything such as eglibc, binutils etc. | 07:53 |
| Laibsch | I don't mind days of compilation | 07:54 |
| lool | Laibsch: You intend to build on v5 hardware? | 07:54 |
| Laibsch | When I started with OE my machine was seriously underpowered (it kind of always was) | 07:54 |
| Laibsch | It took about a week to build the toolchain for me | 07:54 |
| Laibsch | and things broke often, so it may have been a month before I had anything working | 07:54 |
| persia | You should expect a similar amount of pain. | 07:54 |
| Laibsch | not a big problem | 07:54 |
| Laibsch | especially since I can always use OE-compiled software | 07:55 |
| Laibsch | But I want to move slowly away | 07:55 |
| ynezz | uh? | 07:55 |
| Laibsch | I think native compilation makes more sense | 07:55 |
| lool | Laibsch: If you intend to build on v5 hardware, the easiest path for you (in terms of man hours) is probably to build the Ubuntu toolchain source packages after changing their defaults inside a Debian armel chroot | 07:55 |
| ynezz | Laibsch: tired of OE? :p | 07:55 |
| Laibsch | ynezz: yes | 07:55 |
| Laibsch | but basically I understood that OE is not the right tool going into the future | 07:56 |
| Laibsch | for me | 07:56 |
| Laibsch | I'm looking more for a desktop experience on the devices I have | 07:56 |
| ynezz | isn't it more about koen? | 07:56 |
| Laibsch | Openembedded is of course, more embedded | 07:56 |
| Laibsch | yes and no | 07:57 |
| ynezz | ok | 07:57 |
| Laibsch | I sat down and thought about if OE gives me what I need | 07:57 |
| Laibsch | and if it's going in the direction I want it to go | 07:57 |
| Laibsch | I've been with OE for 5 years and I'd say OE has never managed to put out anything usable for end-users | 07:58 |
| Laibsch | I don't see that changing and I'm more of an end-user | 07:58 |
| Laibsch | My hope is ubuntu-arm/debian-arm will eventually be able to output something usable for the ordinary user | 07:58 |
| tkmedia | [02:45] <lool> persia: (from this night) ARM920T + jaunty isn't going to work I'm afraid | 07:59 |
| persia | tkmedia: Sorry about that. My mistake. | 07:59 |
| tkmedia | hmm looks like troouble | 07:59 |
| tkmedia | np | 07:59 |
| tkmedia | Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,3) | 07:59 |
| persia | tkmedia: Should be able to run Debian, I'd think. | 07:59 |
| tkmedia | k | 08:00 |
| ynezz | Laibsch: I've started using ubuntu for the same reason, for headless boards with 32MB RAM is OE the best... | 08:00 |
| gevz | Congratulation of all women in this chatroom with 8 March!!! | 08:00 |
| gevz | bye | 08:00 |
| tkmedia | how can you tell which ver arm the device will run | 08:01 |
| persia | http://en.wikipedia.org/wiki/ARM_architecture gives some useful guidance | 08:02 |
| Laibsch | ynezz: yes, I agree that for the seriously low-powered devices and embedded devices, OE still makes a lot of sense. But that's not necessarily my area of interest. I hope I can lower the bar enough so that the spitz becomes usable. Otherwise, I'll have to wait for some sexy hardware (the Palm Pre might be something I like) | 08:02 |
| persia | cooloney: Do you happen to know if our kernels do anything with XN ? | 08:02 |
| lool | tkmedia: This is not related to jaunty thouhg | 08:03 |
| lool | tkmedia: a binary incomptibility would show up as a sigill, like init being killed | 08:03 |
| tkmedia | ok what is a good dev board .... i like the beagle boards but want a 7" lcd like the samsung | 08:06 |
| persia | tkmedia: DO you need 7"? The NetWalker has 5" and is a complete netbook to boot. | 08:10 |
| tkmedia | prefer a little larger but will look into it thanks | 08:12 |
| persia | You could also get one of the 7" USB displays. As long as you get one that uses DisplayLink it ought to work with lucid+ | 08:13 |
| persia | (or if it doesn't, complain to me about it, and I'll try to fix that) | 08:13 |
| ynezz | tkmedia: in month or so, there should be LCD+Touchscreen avialable for BB from Tincantools | 08:13 |
| cooloney | persia: sorry, have no idea about that? what's XN? for fsl-imx51? | 08:14 |
| tkmedia | yes I want something that could be wall mounted | 08:14 |
| Laibsch | tkmedia: Always Innovating Touchbook may be something to check out | 08:14 |
| persia | cooloney: According to the ARM wikipedia page, XN is a technology available in newer ARM cores that it similar to NX for x86. I'd like to see us enable that if we can. | 08:15 |
| persia | Laibsch: Have they solved the shipment delay issue? | 08:15 |
| Laibsch | no idea | 08:15 |
| Laibsch | I was just visiting their homepage this minute | 08:15 |
| Laibsch | which is why I mentioned it | 08:16 |
| Laibsch | what backlog do they have? | 08:16 |
| tkmedia | interesting | 08:18 |
| tkmedia | nice form factor | 08:18 |
| persia | Laibsch: I heard it took a couple months to get delivered. I'd be glad to be wrong. | 08:18 |
| DanaG | ynezz: I believe specialcomp.com also has some sort of touchscreen, though probably low-res. | 08:19 |
| Laibsch | When I was shopping around for a new netbook last month I had a brief look at it, but was disappointed by 512MB RAM only. So, I went for a pinetrail atom instead :-P I'm very happy so far. | 08:20 |
| ynezz | DanaG: that show dog board from tincantools should have 800x480 for price about $149 | 08:20 |
| ynezz | DanaG: 7" | 08:20 |
| ynezz | forget to mention that | 08:20 |
| DanaG | what's the difference between zippy and zippy2? | 08:21 |
| persia | ynezz: Which driverdoes it use? | 08:21 |
| DanaG | I see no LCD at tincantools. | 08:21 |
| ynezz | persia: dunno :) ask prpplague on #beagle | 08:21 |
| DanaG | oh yeah, I used these kernels: http://rcn-ee.net/deb/kernel/beagle/ | 08:21 |
| DanaG | ah, 10/100 in zippy2. | 08:22 |
| ynezz | DanaG: it should be available in month or so | 08:22 |
| persia | ynezz: Oh, it's a special Beagle expansion? | 08:22 |
| * persia was hoping for something generic | 08:22 | |
| cooloney | persia: ok, i see, just a quick digging | 08:22 |
| persia | cooloney: If you can get that to work, the security team will love you :) | 08:22 |
| cooloney | it is available since ARMv6 | 08:22 |
| persia | Right, but I don't think we ever turned it on. | 08:23 |
| ynezz | persia: yes, beagle related | 08:23 |
| cooloney | #define PMD_SECT_XN (1 << 4) /* v6 */ | 08:23 |
| cooloney | persia: but i am not sure how to use it. | 08:24 |
| cooloney | persia: need some time to take a look | 08:24 |
| lool | persia: I think Kees had a look and flipped a logic bug in arm code | 08:24 |
| lool | So I actually think it's working and enabled | 08:25 |
| persia | lool: Really? That's different than what I last heard, but I would be glad to have missed something. | 08:25 |
| persia | cooloney: Cool. Maybe check with kees: if lool is right, nothing to do. | 08:25 |
| lool | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/364358 http://www.outflux.net/blog/archives/2009/11/24/missing-kernel-features-in-arm/ | 08:25 |
| ubot4 | Launchpad bug 364358 in linux (Ubuntu Jaunty) (and 1 other project) "ARM: image is running with READ_IMPLIES_EXEC (affects: 1) (dups: 1)" [Undecided,Fix released] | 08:26 |
| lool | cooloney: ^ | 08:26 |
| lool | So I'm pretty XN works now | 08:26 |
| persia | Cool! | 08:26 |
| lool | +sure | 08:26 |
| persia | I caught the original blog post, but not the followup. | 08:26 |
| DanaG | what does "ASLR" stand for? | 08:28 |
| persia | http://en.wikipedia.org/wiki/Address_space_layout_randomization | 08:28 |
| persia | Makes it harder to take advantage of buffer overflow exploits, poke exploits, etc. | 08:29 |
| DanaG | ah. | 08:35 |
| DanaG | anyway, bedtime now. =รพ | 08:35 |
| cooloney | lool: thanks, | 08:35 |
| lool | cooloney: Did you manage to look into the kexec problem? | 08:36 |
| cooloney | and from the code arch/arm/mm/mmu.c | 08:36 |
| cooloney | lool: yeah, we found a way in imx51 and mvl-dove | 08:36 |
| cooloney | i prepared a kernel package for versatile alreayd | 08:36 |
| cooloney | and going to test it now | 08:36 |
| cooloney | if you wanna test, please take a look at this bug | 08:36 |
| cooloney | https://bugs.launchpad.net/adana/+bug/517841 | 08:37 |
| ubot4 | cooloney: Error: Bug #517841 is private. | 08:37 |
| cooloney | persia: XN bit is enabled when arch >= ARMv7 | 08:38 |
| lool | http://kernel.ubuntu.com/git?p=roc/ubuntu-lucid.git;a=shortlog;h=refs/heads/kexec-versatile is the branch | 08:38 |
| lool | http://people.canonical.com/~roc/kernel/kexec/ has the binary kernels | 08:38 |
| cooloney | yeah, | 08:41 |
| cooloney | but we still have to patch the kexec-tools | 08:41 |
| persia | cooloney: That's fine. | 08:42 |
| lool | Only for initramfs support though | 08:44 |
| cooloney | lool: do you mean another issue about initramfs on versatile? | 08:46 |
| cooloney | lool: i saw your config patch was merged | 08:47 |
| lool | cooloney: Didn't yet try with | 08:47 |
| lool | my patch in | 08:47 |
| lool | cooloney: But we should really fix the initramfs issue | 08:47 |
| lool | perhaps it's a similar problem actually! | 08:48 |
| lool | perhaps our kernel is too big! | 08:48 |
| lool | I didn't think of that | 08:48 |
| cooloney | yeah, the issue is very similar, without patching the kexec-tools to increase the size | 08:48 |
| cooloney | we can not kexec reboot the kernel | 08:48 |
| lool | cooloney: Question | 08:48 |
| cooloney | it looks like the similar in qemu | 08:49 |
| lool | cooloney: the kernel knows where it's loaded, how big it is, and where the initramfs is supposed to me | 08:49 |
| lool | cooloney: Don't you think the kernel should test whether kernel start + kernel size < initramfs start? | 08:49 |
| cooloney | lool: normally, the bootloader should take care of that, such as uboot or qemu | 08:50 |
| lool | cooloney: Don't you think it's a good idea to have such a sanity check to avoid debugging kexec like we did? | 08:53 |
| lool | cooloney: With your kernel, I still can't load initrds *gah* | 08:55 |
| lool | cooloney: I think it's due to the same bug as for kexec, or similar | 08:55 |
| lool | cooloney: Do you have a recipe for converting a vmlinuz to a vmlinux? | 08:56 |
| cooloney | lool: you wanna try vmlinux, right? i can uploaded for you | 08:56 |
| lool | cooloney: Would be nice, thanks | 08:57 |
| lool | I do see "cramfs" in the list of attempted file systems now; but it doesn't work | 08:57 |
| lool | cooloney: So with your kernel to run qemu and loaded with kexec, it still hangs as before | 09:00 |
| lool | "Starting new kernel" and nothing more | 09:00 |
| cooloney | ok | 09:00 |
| cooloney | there is no "Uncompressing...," right? | 09:00 |
| lool | cooloney: Let me try with the serial console trick | 09:01 |
| lool | I get more output in this way | 09:01 |
| * ogra glares at klibc buildlog ... -march=armv4 -mtune=strongarm | 09:01 | |
| lool | cooloney: Well using an uncompressed kernel might improve the test; let's try with one | 09:01 |
| ogra | hrm | 09:01 |
| cooloney | lool: no problem, i am uploading, but it will take some time | 09:02 |
| cooloney | due to the slow connection at my home | 09:02 |
| lool | cooloney: Press the "FAST" button below your modem | 09:03 |
| lool | sometimes it's labeled TURBO instead | 09:03 |
| persia | ogra: Please fix :) | 09:03 |
| ogra | persia, well, thats not the cause of the ftbfs | 09:03 |
| persia | Yeah, but :) | 09:04 |
| ogra | lool, isnt that a software switch that needs this proprietary program from www.modemspeedier.com ? | 09:05 |
| persia | ogra: Depends on the modem. The better class have external controls that do the same thing as the extended AT sequences. | 09:06 |
| ogra | heh | 09:07 |
| lool | cooloney: Updated the kexec/versatile bug | 09:10 |
| lool | lp #518567 | 09:10 |
| ubot4 | Launchpad bug 518567 in linux (Ubuntu) (and 1 other project) "armel/versatile: Can't kexec (affects: 1)" [Undecided,New] https://launchpad.net/bugs/518567 | 09:10 |
| lool | cooloney: Found how to convert the image (I think) | 09:14 |
| lool | Hmm not sure | 09:15 |
| lool | I get no vidoe output, so seems my vmlinux is busted | 09:16 |
| cooloney | lool: i found 2 vmlinux in my build dir | 09:18 |
| cooloney | one is 61M, | 09:18 |
| cooloney | one is 3M, which is not for this | 09:18 |
| cooloney | lool: or just Image? | 09:19 |
| lool | cooloney: I think we want vmlinux | 09:19 |
| lool | cooloney: but you can strip it | 09:19 |
| lool | vmlinuz is stripped and gzipped which is why it's much smaller | 09:19 |
| lool | My vmlinux is 6.3 MB so that seems about right | 09:20 |
| cooloney | ok, will do that | 09:20 |
| lool | cooloney: YES! | 09:21 |
| lool | cooloney: So booting your vmlinuz and kexecing the vmlinux I created works | 09:22 |
| lool | cooloney: So don't bother uploading | 09:24 |
| lool | So many problems here, vmlinuz loading broken, vmlinux boot broken, need to test initrd support... | 09:24 |
| cooloney | ok, understand now | 09:26 |
| cooloney | you convert the vmlinx from my vmlinuz | 09:26 |
| cooloney | and kexec that, right? | 09:26 |
| lool | Yes | 09:27 |
| cooloney | ok, cool | 09:28 |
| asac | ericm_: why do we use CONFIG_OABI_COMPAT=y ? | 09:29 |
| lool | cooloney: That's a good workaround, but would you be interested in chasing the other issues? | 09:29 |
| ericm_ | asac, that's for old ABI binary to be still able to run | 09:29 |
| ericm_ | asac, it's harmless - any issue you found related to this? | 09:29 |
| cooloney | lool: i'd love to, | 09:31 |
| persia | lool: Are you certain that we don't need to use qemu to support ppc64 on ppc, sparc64 on sparc, and amd64 on i386? | 09:31 |
| lool | persia: I'm not, I applied the same heuristics as the qemu Debian package | 09:31 |
| persia | OK. I'll just follow along then. | 09:31 |
| lool | persia: I think it's only possible to run ppc64 on powerpc if you have ppc64 hardware and you run a 64-bits kernel (with a powerpc 32-bits userspace) | 09:32 |
| asac | ericm_: mvl asked why we still have that. i think they thought it would help if we'd drop it | 09:32 |
| asac | iirc there were also some performance claims | 09:32 |
| persia | lool: I think the same is true in every case in my example. | 09:32 |
| asac | if you say it shouldnt hurt at all, fine. | 09:32 |
| lool | persia: but I don't have hardware and I didn't want to write overly complex code I couldn't test | 09:32 |
| lool | persia: Yes, I'm only giving an example | 09:32 |
| ericm_ | asac, so far no related issues with that | 09:34 |
| amitk | ericm_: we could get rid of OABI. We don't care about letting older ABI binaries run on Ubuntu... | 09:34 |
| asac | ericm_: but is there any reason to keep it? e.g. EABI is already really really old | 09:34 |
| asac | right | 09:34 |
| lool | persia: Similarly, it might be possible to use qemu-x86_64-static under i386, but I don't think we actually have a binfmt for that as it might mess up config_32 for users of amd64 hardware with a 64-bits kernel | 09:35 |
| lool | Anyway, if someone wants to support using qemu there and has a patch which I can understand, I'm happy to review + merge it :-) | 09:35 |
| persia | lool: I think you're right, and I don't want to fuss with it enough to try to fix it now. | 09:36 |
| amitk | ericm_: I remember that I turned it off on FSL | 09:36 |
| ericm_ | asac, amitk, no specific reason, just want to keep a certain degree of backward compatibility, but it's OK to remove I agree | 09:37 |
| ericm_ | asac, amitk, it's actually not very old, EABI became popular in less than 2 years | 09:37 |
| amitk | ericm_: with the distro compiled for armv7+, backward compatibility is not one of our stated goals :) | 09:38 |
| ericm_ | amitk, agree | 09:38 |
| amitk | and we want to make sure that we run all EABI code. Debian does a great job of supporting OABI and EABI as it is. | 09:38 |
| lool | Does OABI support hurt? | 09:39 |
| cooloney | lool: is there any option in qemu to enable a host directory to share with the running qemu virtual system | 09:39 |
| lool | ISTR it caused some weird bugs on dove | 09:39 |
| ericm_ | well, in some cases, that depends on the source code availability to be recompiled with new EABI and new toolchain | 09:40 |
| lool | cooloney: There is, but I don't use it | 09:40 |
| cooloney | lool: ok, | 09:40 |
| lool | cooloney: Consider either a nfs export if you have that, or just loop mount your image | 09:40 |
| lool | (I do the latter) | 09:40 |
| ericm_ | but it's not always true - esp. in some areas source code is not available, but anyway those are corner cases | 09:40 |
| lool | cooloney: | 09:40 |
| lool | http://people.canonical.com/~lool/loop-mnt-do | 09:40 |
| ericm_ | lool, I don't think OABI support is harmful - so far no evidence | 09:41 |
| lool | cooloney: loop-mnt-do some.img | 09:41 |
| lool | ericm_: I think there was a suspend resume bug under dove triggered by this config | 09:41 |
| ericm_ | lool, that's caused by other issue but could be worked around by turning this option off | 09:41 |
| ericm_ | lool, Marvell has provided a right fix to that bug | 09:42 |
| lool | lp #453682 | 09:42 |
| ubot4 | Launchpad bug 453682 in linux-mvl-dove (Ubuntu Karmic) (and 2 other projects) "late resume failure on dove (affects: 2)" [High,Fix released] https://launchpad.net/bugs/453682 | 09:42 |
| lool | ericm_: I agree, this bug is fixed, I just don't know whether OABI_COMPAT is exposing us to more of such bugs, or whether it's truly harmless | 09:42 |
| ericm_ | lool, so far none - I tend to keep a certain backward compatibility, but as amitk said, this might not be necessary, and I'm totally fine to turn this off if everyone agrees | 09:44 |
| lool | The only other reasons I can think of to drop it: * size of the kernel (but then it's a pig anyway), * security issue in one of the OABI code pathes (no track thereof until now though) | 09:44 |
| ericm_ | lool, fair enough | 09:45 |
| lool | ericm_: Frankly, I have no opinion either way; I'm just curious of what would justify the config either way -- as to be able to answer questions on this choice | 09:45 |
| lool | I didn't face someone running an OABI binary on Ubuntu so far, and didn't have to run one myself; perhaps it's useful for e.g. flash tools or proprietary software like skype or flash? no idea really | 09:46 |
| ericm_ | lool, could you include me in the CC loop when discussing these config options with Marvell, I know they intend to keep their kernel config as close as ours so to minimize the future developing effort | 09:46 |
| asac | i doubt it | 09:46 |
| lool | ericm_: I actually don't discuss this with marvell myself | 09:46 |
| asac | (flash/skype) | 09:46 |
| lool | ericm_: If I ever do, I'll Cc: you :-) | 09:47 |
| ericm_ | lool, thanks | 09:47 |
| * lool is just polluting the amitk/ericm discussion out of curiosity | 09:47 | |
| asac | ericm_: amitk: so i take it that we can drop this? /me goes files a bug | 09:47 |
| ericm_ | asac, thanks | 09:48 |
| asac | bug 534277 | 09:49 |
| ubot4 | Launchpad bug 534277 in linux-mvl-dove (Ubuntu) "disable OABI_COMPAT (affects: 1)" [Medium,Triaged] https://launchpad.net/bugs/534277 | 09:49 |
| asac | cooloney: is that on for -fsl too? | 09:51 |
| asac | (see above) | 09:51 |
| suihkulokki | disabling oabi compat gives a tiny performance improvement on making syscalls | 09:52 |
| asac | good... we want performance ;) | 09:52 |
| suihkulokki | then you should start with disabling the PIE binary stuff which has major impact in performance | 09:54 |
| suihkulokki | the PIE/address randomizing stuff is snakeoil for security on 32bit archs anyway | 09:55 |
| cooloney | asac: i just checked that | 09:58 |
| cooloney | it is disabled in fsl-imx51 | 09:58 |
| amitk | ericm_: cooloney: ^^^ what suihkulokki said about PIE is very pertinent. | 09:59 |
| cooloney | grep -r CONFIG_OABI_COMPAT ../Ubuntu/fsl-imx51-lucid/debian.fsl-imx51/config/ | 09:59 |
| cooloney | ../Ubuntu/fsl-imx51-lucid/debian.fsl-imx51/config/config.common.ubuntu:# CONFIG_OABI_COMPAT is not set | 09:59 |
| cooloney | roc@roc-macubuntu:~/Work/qemu-arm$ | 09:59 |
| amitk | cooloney: I disabled it very early in Karmic I think | 09:59 |
| cooloney | amitk: yeah, thx, man, heh | 09:59 |
| ericm_ | suihkulokki, what is PIE binary, sorry? | 10:07 |
| persia | http://en.wikipedia.org/wiki/Position-independent_code#Position-independent_executables | 10:09 |
| cooloney | so we need to disalbe that PIE stuff in kernel? | 10:13 |
| cooloney | will some apps fail to run due to that? | 10:13 |
| ogra | we should try :) | 10:14 |
| ogra | if the performance penalty is really that high it might be worth to look at | 10:14 |
| persia | Um, why? | 10:16 |
| ericm_ | PIC sounds more familiar to me, but anyway - how's this related to oabi? | 10:16 |
| persia | PIE isn't that useful for security on 32-bit architectures, but PIC is critical for sane shared libraries. | 10:17 |
| persia | And we probably have to unwind some other things: kees implemented the ASLR stuff a while back. | 10:18 |
| amitk | ericm_: its not related to OABI, it is related to performance | 10:18 |
| ogra | persia, oh, i meant pie | 10:18 |
| ogra | err | 10:19 |
| ogra | pic | 10:19 |
| amitk | ogra: no, you meant PIE ;) | 10:19 |
| * ogra curses the similarity of all these abbrev.'s | 10:19 | |
| ericm_ | that's true, PIC hurts performance a bit | 10:19 |
| amitk | ericm_: no, we are talking about PIE | 10:19 |
| cooloney | PIC hurts perf, but it necessary for .so | 10:19 |
| ericm_ | why do we need PIE anyway? | 10:20 |
| cooloney | i have no idea about PIE stuff as well as ericm_ | 10:20 |
| persia | Right. We aren't giving up PIC. Once we have PIC, PIE doesn't generally matter that much, performance-wise. | 10:20 |
| cooloney | and what kind of app is using PIE binary | 10:20 |
| cooloney | persia: so PIE is an older trick than PIC? | 10:20 |
| amitk | ericm_: for security, It randomizes the address space layout | 10:21 |
| ericm_ | lool, apparently I missed the discussion of kexec vmlinux, it looks the arm kexec-tools doesn't support vmlinux/vmlinuz, but the one generated with objcopy can be used directly by kexec to avoid the zImage uncompressing code overwritting initramfs data issue | 10:21 |
| === Guest78773 is now known as NCommander | ||
| persia | cooloney: PIE just means the *entire executable* is PIC. | 10:21 |
| ericm_ | and give a better performance since uncompressing can be skipped | 10:21 |
| amitk | so there is no well-known location for the executable code | 10:21 |
| amitk | but we'll need to talk to the security team about disabling it for ARM. They might have other views. | 10:22 |
| === NCommander is now known as Guest33867 | ||
| === mcasadevall_ is now known as NCommander | ||
| Laibsch | lool: I assume you are using glibc for ubuntu-arm? Have you guys considered eglibc? The OE toolchain guru swears by it. | 10:29 |
| persia | Laibsch: Have you checked? I think we are using a variant of eglibc | 10:30 |
| Laibsch | persia: no, I have not | 10:31 |
| Laibsch | "assume" | 10:31 |
| Laibsch | I thought it was quicker to just give that information and let lool decide what he wants to do with it | 10:31 |
| Laibsch | I wouldn't even know where to check ;-) | 10:31 |
| persia | Laibsch: It's almost always more efficient to investigate a bit :) | 10:31 |
| persia | Or ask questions generally. | 10:31 |
| ogra | we use eglibc by default | 10:32 |
| ogra | on all arches iirc | 10:32 |
| Laibsch | persia: I did ask, see above | 10:32 |
| persia | By "generally" I meant "without highlighting any individual" :) | 10:32 |
| NCommander | morning persia | 10:32 |
| persia | NCommander: So it is :) | 10:32 |
| Laibsch | persia: I'm trying to help by pointing out possible lessons learned for ubuntu-arm from what I know about OE. If I need to finish an IT education first before being allowed to do that, I'll just simply stop. Becuase my time is limited. | 10:33 |
| NCommander | OE is nifty because they cross-compile everything, which makes it a lot easier to build than say Ubuntu which requires native building | 10:34 |
| Laibsch | it's both a blessing and a curse, I guess | 10:34 |
| NCommander | Laibsch: indeed, some packages are mindbogglingly difficult to cross-build | 10:35 |
| * NCommander glares at mySQL | 10:35 | |
| persia | Laibsch: It's not about an education. It's just about trying things, and asking questions not of specific folk so that they aren't distracted if someone else has the answer. | 10:35 |
| * NCommander sighs | 10:36 | |
| Laibsch | we've spent more time discussing this now than it will take an expert to decide what to do with the info | 10:36 |
| Laibsch | I'm not an expert | 10:36 |
| Laibsch | if you want me to become one before I can point out possible differences then I'm sorry, I can't do that | 10:37 |
| persia | Laibsch: You've taken that wrong. My apologies. | 10:37 |
| Laibsch | I will try my best not to waste people's time | 10:38 |
| Laibsch | But there's two sides to the equation | 10:38 |
| persia | Absolutely :) | 10:38 |
| Laibsch | lool's time and mine. I'm looking at overall efficiency. I think that may be where our diffrences are | 10:38 |
| Laibsch | It will cost me an immense amount of time to understand the toolchain issues | 10:39 |
| Laibsch | it will be only seconds to either discard or decide to look further into it for an expert | 10:39 |
| Laibsch | hence the decision I made | 10:39 |
| Laibsch | btw, no offense taken, don't worry | 10:39 |
| persia | Cool! | 10:40 |
| ogra | funnily i cant find the public discussion for it, but we switched to eglibc in karmic | 10:43 |
| Laibsch | great | 10:43 |
| * amitk remembers it being posted to ubuntu-devel | 10:43 | |
| Laibsch | I understand that ubuntu on arm still has some speed issue, though, correct? | 10:44 |
| lool | Sorry, I was interrupted by someone at my door | 10:44 |
| cooloney | lool: for the kexec on versatile | 10:45 |
| asac | hmm axis build failure looks odd https://edge.launchpad.net/~asac/+archive/armel1/+build/1543870 | 10:45 |
| asac | is java working at all on armel atm? | 10:45 |
| cooloney | lool: you mentioned kexec -l vmlinux works on your side | 10:45 |
| cooloney | lool: is on versatile hardware? | 10:46 |
| lool | cooloney, ericm_: http://people.canonical.com/~lool/vmlinuz-to-vmlinux | 10:46 |
| cooloney | lool: but failed on qemu, right? | 10:46 |
| lool | That converts a vmlinuz to vmlinux | 10:46 |
| cooloney | lool: got you, thanks, | 10:46 |
| lool | cooloney: It's in qemu | 10:46 |
| lool | cooloney: a) I can't qemu-boot the vmlinux kernel (unrelated to kexec), only the vmlinuz one b) I can't kexec the vmlinuz kernel (original bug); that seems to be a bug in the way kexec choses addresses (perhaps) | 10:47 |
| lool | cooloney: I don't have versatile hardware (probably nobody does around here); I just use qemu | 10:47 |
| cooloney | lool: understand. i cannot kexec vlinux, it does not work on my qemu | 10:48 |
| cooloney | lool: right, just was confused by your post in the bug | 10:48 |
| cooloney | heh | 10:48 |
| cooloney | 'I can't boot the vmlinux in qemu though.' hehe | 10:48 |
| lool | cooloney: I need to update the bug again | 10:49 |
| cooloney | i played versatile hw before, so i assume you got it | 10:49 |
| cooloney | lool: ok | 10:49 |
| lool | That was after testing your kernel, but before testing vmlinux | 10:49 |
| cooloney | lool: let me try your vmlinuz-to-vmlinux | 10:49 |
| lool | cooloney: I don't have it; we just use versatile because it's well supported in qemu | 10:49 |
| lool | cooloney: you need to pipe the output | 10:52 |
| lool | cooloney: e.g. vmlinuz-to-vmlinux ~/yourvmlinuz > output-vmlinux | 10:52 |
| cooloney | lool: yeah, just got an vmlinux file with the pipe after the funny symbols popped up on my screen w/o pipe | 10:53 |
| asac | thumb2 rebuild ftbfs: http://paste.ubuntu.com/390975/ | 10:54 |
| cooloney | lool: OMG, the vmlinux generated by your script works with kexec | 10:55 |
| cooloney | lool: cool | 10:55 |
| persia | asac: Not bad at all! | 10:55 |
| persia | ~4% of the rebuilds | 10:55 |
| lool | Laibsch: So as pointed out above, we use eglibc by default everywhere, just like Debian | 10:55 |
| Laibsch | great | 10:55 |
| === ogra_ is now known as ogra | ||
| lool | suihkulokki: Do you know of public benchmarks of PIE versus non-PIE on armel? | 10:56 |
| Laibsch | anybody here using a native arm compile host coupled with a bunch of icecc clients? | 10:56 |
| lool | I can expect that basically any security feature has a cost, but I wish we had some data to quantify | 10:56 |
| cooloney | then we can comfirm what patches need to be applied into our master.versatile, fsl-imx51, mvl-dove | 10:57 |
| lool | Laibsch: To clarify, there is exactly one source packages pool which is the Ubuntu archive; the Ubuntu armel port uses the very same source as the Ubuntu Desktop Edition for instance | 10:57 |
| lool | cooloney: Let me test a pristine vmlinuz to see whether your patches are required | 10:58 |
| Laibsch | yes, that is my understanding | 10:58 |
| Laibsch | and that is the benefit of ubuntu-arm over OE imho | 10:58 |
| Laibsch | it will likely scale better going into the future | 10:58 |
| amitk | IMHO, s/likely// in the above sentence :) | 10:59 |
| Laibsch | future is always uncertain ;-) | 11:00 |
| amitk | its worked for Ubuntu for over 4 years now... | 11:02 |
| amitk | and in the Linux kernel for much longer (embedded -> PC -> mainframe) | 11:03 |
| cooloney | lool: thanks please update the status of launchpad | 11:03 |
| lool | cooloney: done | 11:04 |
| Laibsch | amitk: right now, I think OE-derived stuff is more usable. the debian-arm project apparently predates OE, yet I would venture to guess that Angstrom is more usable currently than debian-arm. | 11:04 |
| lool | Depends of the purpose | 11:05 |
| lool | OE doesn't provide an end-user installer, or security support | 11:05 |
| ogra | or easy upgradeability | 11:06 |
| lool | People running Debian on ARM NAS devices care about these | 11:06 |
| persia | And it works great for that use case. | 11:06 |
| persia | I know a bunch of folks happy with Debian on handhelds as well. | 11:06 |
| amitk | Laibsch: for a different definition of "usable" from our typical users. | 11:07 |
| Laibsch | OE is not meant to provide that. That would be distro stuff | 11:07 |
| amitk | ... developers as well, in fact | 11:08 |
| Laibsch | an end-user installer in that sense may not be necessary | 11:08 |
| Laibsch | devices have traditionally been flashed with a complete rootfs | 11:08 |
| Laibsch | upgradeability is something that Angstrom does care very much about | 11:09 |
| Laibsch | security is indeed a very weak point | 11:09 |
| persia | Laibsch: That only works for pre-sold stuff, and even pre-sold stuff may want a refresh for a variety of reasons (e.g. install Kubuntu Netbook on a Netwalker) | 11:09 |
| Laibsch | but there's been some work there lately | 11:09 |
| Laibsch | persia: what do you mean pre-sold stuff? | 11:10 |
| Laibsch | I don't understand what you are trying to say | 11:10 |
| persia | err, stuff sold pre-installed. | 11:10 |
| ogra | i think he means pre-installed | 11:10 |
| Laibsch | no, that is not true | 11:10 |
| * persia goes to find calories in hopes of thinking better | 11:10 | |
| Laibsch | I'm not aware of any device with angstrom installed as shipped (althought that may have changed lately) | 11:11 |
| ogra | Laibsch, what we want is that your sister can buy that arm netbook ... and if she doesnt like the perinstalled OS is able to install ubuntu on it and use it like on x86 with no drawbacks | 11:11 |
| Laibsch | sure | 11:11 |
| ogra | (and without prior computer knowledge) | 11:11 |
| Laibsch | that's how OE got staretd | 11:11 |
| Laibsch | people replaced Sharp ROM with OZ ROM for example | 11:12 |
| ogra | your sister would be able to replace os-blah on her arm netbook with OE ? | 11:12 |
| Laibsch | so, I don't understand the point being made there | 11:12 |
| ogra | would that even be possible without knowing how to use a serial console ? | 11:12 |
| Laibsch | of course | 11:12 |
| Laibsch | you guys seem to have some serious misconceptions | 11:13 |
| ogra | no, i've just seen a lot of hard to work with arm hardware :) | 11:13 |
| Laibsch | I think it's much easier to change the OS on a Z with OE-derived stuff than put Ubuntu on it | 11:13 |
| kblin | Laibsch: are you surprised? this is an ubuntu chennel :) | 11:13 |
| ogra | and i want to meet your sister ! | 11:13 |
| ogra | *g* | 11:13 |
| Laibsch | My sisters are older than me and married | 11:13 |
| Laibsch | sorry ;-) | 11:14 |
| ogra | heh | 11:14 |
| kblin | Laibsch: it's a bit like talking about the benefits of perl on #python | 11:14 |
| amitk | heh | 11:14 |
| Laibsch | well, it's good to know what else is out there | 11:14 |
| Laibsch | and I think there is a lot that can be learned from OE | 11:14 |
| ogra | kblin, nah ... OE surely has its advantages | 11:14 |
| Laibsch | so that the wheel doesn't need reinvention | 11:14 |
| kblin | ogra: good point | 11:14 |
| ogra | but there is a reason why endusers pick ubuntu over gentoo on theirt x86 machines :) | 11:15 |
| lool | kblin: Oh don't worry we often debate python versus shell here | 11:15 |
| Laibsch | There was no alternative to OE at the time it was invented | 11:15 |
| Laibsch | native compilation was not possible | 11:15 |
| ogra | and i think the same reasons apply if you look at OE vs ubuntu-arm | 11:15 |
| Laibsch | that's changing and that's why I'm considering to switch | 11:15 |
| ogra | lool, well, if asac joins the discussion there will also be C involved :) | 11:16 |
| Laibsch | You need to look back 5+ years when OE came to life | 11:16 |
| ogra | sure | 11:16 |
| ogra | there was no ubuntu-arm back then | 11:16 |
| kblin | Laibsch: the reason why I run ubuntu on my ARM boxes is one of convenience rather than a technical one | 11:16 |
| amitk | Laibsch: It is safe to say that most people here have played with Zaurii, OE, familiar, etc. in a previous life. | 11:17 |
| Laibsch | then it's pretty amazing to read "OE is hard to install" | 11:17 |
| Laibsch | for two reasons | 11:17 |
| Laibsch | 1) you never install OE on your device | 11:17 |
| kblin | so? | 11:17 |
| Laibsch | 2) OE-derived distros do provide an easy to use installer mechnism (at least for the devices I'm familiar with) | 11:18 |
| lool | Folks, I'm not sure the Ubuntu versus OE discussion is leading anywhere | 11:18 |
| ogra | yeah, lets turn it into a gnome vs kde one rather ! | 11:18 |
| Laibsch | lool: I'm not sure anybody is trying to convince anybody else | 11:18 |
| lool | Different projects stand in different states and fit different people; I'm happy to discuss specific things we can rip from OE if there's something we can easily rip right now and it fits with the priorities of Ubuntu ARM | 11:18 |
| Laibsch | for me it's an exchange of facts, more than anything else | 11:19 |
| * amitk gets back to real work | 11:19 | |
| kblin | lool: armv5 support? ;) | 11:19 |
| Laibsch | kblin: good idea! | 11:19 |
| kblin | lool: cheap shot, I know :) | 11:20 |
| kblin | Laibsch: not really important, ogra's sister won't buy a netbook with an armv5, so that's not a problem :) | 11:21 |
| ogra | she only buys what i tell her is easiest to use for her :) | 11:21 |
| lool | cooloney: https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/534324 | 11:22 |
| ubot4 | Launchpad bug 534324 in qemu-kvm (Ubuntu) "Can't run uncompressed (vmlinux) kernels (affects: 1)" [Undecided,New] | 11:22 |
| * kblin gets back to work | 11:22 | |
| lool | cooloney: So a vmlinux from the archive vmlinuz just works | 11:22 |
| ogra | oh my ... so klibc defines armv4 and tunes for strongarm upstream | 11:22 |
| ogra | hrm | 11:22 |
| lool | cooloney: So your patches/build aren't needed to load vmlinux; perhaps these are needed for initramfs? | 11:23 |
| lool | kblin: Oh it's absolutely desirable | 11:23 |
| * ogra was hoping that was a debian setting from rules | 11:23 | |
| lool | kblin: I have some thoughts on that, but it wasn't really a high priority until now | 11:23 |
| kblin | lool: like doing two builds? | 11:25 |
| lool | Wow, I end up with apex on my versatile install; I bet the kernel did it | 11:25 |
| lool | kblin: I don't think we would build this all the time | 11:25 |
| lool | kblin: What would be ok is taking Ubuntu's armel archive, using some clever machinery to rebuild everything a couple of times, and storing this new archive somewhere else | 11:26 |
| lool | Where that machinery could either be an expensive set of ARM hosts or qemu on a lot cheap x86 hosts (such as EC2) | 11:26 |
| lool | apw: I'm considering a d-i upload; do you plan uploading linux-fsl and linux-mvl this week? if you do, I'll hold it a bit | 11:28 |
| apw | lool, yes i think i have patches pending on both branches | 11:28 |
| apw | i'll have a look shortly and let you know ... | 11:28 |
| lool | Thanks | 11:29 |
| ogra | lool, apex is in universe | 11:30 |
| ogra | lool, but only moved out of the d-i deps recently | 11:30 |
| ogra | so it depends when you installed | 11:30 |
| lool | I'm not sure why it got pulled really | 11:32 |
| lool | I created the chroot with debootstrap | 11:32 |
| lool | Hmm it might be the d-i build-deps | 11:32 |
| lool | Right | 11:32 |
| Laibsch | seeing that CPU cycles on arm are still scarce, I'd like to reiterate my earlier question. Anybody here using a native arm compile host coupled with a bunch of icecc clients? | 11:32 |
| lool | So nm, just my setup | 11:33 |
| persia | Laibsch: Just use the emulation if you can't do native. It's not that slow. | 11:34 |
| Laibsch | I'm really interested in that question, though. | 11:34 |
| lool | I don't think anybody here does that | 11:34 |
| Laibsch | I see | 11:34 |
| lool | I think it's used in the OBS, in the Xandros ARM builds, and perhaps in the mojo tools | 11:34 |
| Laibsch | Any technical reason to make that infeasible? | 11:35 |
| Laibsch | OK | 11:35 |
| Laibsch | Maybe I'll have a bit of fun with something like that, too | 11:35 |
| lool | We just use different solutions | 11:35 |
| Laibsch | I've previously used OE and distributed that with icecc | 11:35 |
| Laibsch | It worked pretty nicely | 11:35 |
| asac | JamieBennett: https://launchpad.net/ubuntu/+source/fio/1.33.1-1ubuntu1/+build/1550048/+files/buildlog_ubuntu-lucid-ia64.fio_1.33.1-1ubuntu1_FAILEDTOBUILD.txt.gz ;) | 12:21 |
| * JamieBennett looks | 12:21 | |
| asac | its ia64 | 12:21 |
| asac | /build/buildd/fio-1.33.1/verify.c:907: undefined reference to `write_barrier' | 12:21 |
| asac | guess we can ignore it ;) | 12:22 |
| asac | unless you see the problem right away | 12:22 |
| JamieBennett | Why is that code being included on IA64 ? | 12:22 |
| asac | not sure | 12:22 |
| asac | most likely the problem is that its not included :;) | 12:22 |
| asac | the symbol isnt defined | 12:22 |
| asac | e.g. it lacks a ia64 implementation | 12:22 |
| JamieBennett | Its ARM specific though (in arch/arch-arm.h) | 12:23 |
| asac | or the ia64 implementation currently in the code is not picked up | 12:23 |
| asac | JamieBennett: verify.c | 12:23 |
| * JamieBennett didn't touch verify.c | 12:23 | |
| asac | ./arch/arch-ia64.h | 12:23 |
| asac | JamieBennett: #define nop asm volatile ("hint @pause" ::: "memory"); | 12:23 |
| asac | #define read_barrier() asm volatile ("mf" ::: "memory") | 12:23 |
| asac | feels like its a missing _ | 12:23 |
| asac | #define writebarrier() asm volatile ("mf" ::: "memory") | 12:24 |
| asac | simple fix we could try in the next upload | 12:24 |
| JamieBennett | asac: still don't understand what the current fix could of done to effect that unless IA64 was broken before | 12:24 |
| asac | JamieBennett: its not a regression | 12:26 |
| asac | the problem existed before | 12:26 |
| asac | (i am quite sure) | 12:26 |
| JamieBennett | asac: so yes, missing '_' it seems | 12:26 |
| asac | sorry if i made you feel that way ;) | 12:26 |
| asac | JamieBennett: ok. have you updated the patch? i can just add the _ for next upload | 12:26 |
| JamieBennett | asac: np | 12:26 |
| JamieBennett | asac: I was looking for what I had 'broken' ;) | 12:27 |
| asac | heh :) | 12:27 |
| asac | this time it wasnt you | 12:27 |
| JamieBennett | :) | 12:27 |
| JamieBennett | I'll update the patch and attach it to the bug | 12:27 |
| JamieBennett | unless its easier for you to just do it ? | 12:28 |
| asac | i will wait for you | 12:30 |
| === mcasadevall is now known as Guest20793 | ||
| === Guest20793 is now known as NCommander | ||
| === dl9pf_ is now known as dl9pf | ||
| === dl9pf is now known as dl9pf_ | ||
| === dl9pf_ is now known as dl9pf | ||
| ogra | asac, so you were complaining about http://people.canonical.com/~ogra/babbage2-lucid-20100211-3.png boottimes ... i did a test on a similar scaled x86 system with the same software ... http://people.canonical.com/~ogra/celeron-M-lucid-20100308-3.png | 13:16 |
| ogra | i dont think we look so bad on babbage compared to that | 13:16 |
| ogra | (note the celeron has even 10MB/s higher disk throughput) | 13:17 |
| asac | ogra: when is the UI up? | 13:19 |
| asac | e.g. what do i need to look for? | 13:19 |
| ogra | netbook-launcher | 13:19 |
| ogra | and then gnome-panel | 13:19 |
| asac | so its 50s v. 60s? | 13:19 |
| ogra | or 35 vs 45 | 13:20 |
| ogra | depends what you look at | 13:20 |
| ogra | launcher is up very fast | 13:20 |
| ogra | panel has 10-15s delay | 13:20 |
| ogra | but its definately not arch specific if you compare two similar systems | 13:20 |
| ogra | (similar slow) | 13:21 |
| ogra | lool, bah, you broke rootstock packaging ... "qemu-kvm-extras-static | qemu-kvm-extras" .... qemu-system-arm is still needed for the image building and system setup, oem-config installation etc | 13:30 |
| lool | ogra: Back then, I think it used to use either system emulation or syscall emulation but not both, didn't it? | 13:36 |
| ogra | nope | 13:37 |
| ogra | it always did use qemu-system-arm for the system configuration, user steup and preparation for running on real HW | 13:37 |
| ogra | mono was always my showstopper | 13:38 |
| ogra | syscall emu is only used for the debootstrap part (which is the smallest bit of rootstock) | 13:39 |
| === mcasadevall is now known as NCommander | ||
| ogra | lool, soo, our versatile kernel ... would you expect it to do thumb2 instructions properly ? i now ran a rootstock build of karmic ubuntu-desktop under lucid that seems to properly finish (not done yet but all the steps where lucid hangs are definately done) ... that somnewhat points to userspace imho | 16:24 |
| ogra | i wonder if the versatile hack that enables a v7 cpu actually enables the needed bits and pieces to execute lucid binaries | 16:25 |
| ogra | (though its still weird that it just silently hangs withouot errors, segfaults or anything) | 16:26 |
| lool | ogra: I don't understand what you're saying | 16:26 |
| ogra | lool, well, you know about my hang of qemu | 16:26 |
| lool | ogra: I can run a lucid thumb2 userspace under qemu-system-arm with our versatile kernel | 16:26 |
| ogra | but can you run it under heavy IO disk load ? | 16:27 |
| lool | I don't see how that relates to thumb2 | 16:27 |
| * ogra refers to bug 532733 | 16:27 | |
| ubot4 | Launchpad bug 532733 in qemu-kvm (Ubuntu) "apt/dpkg in qemu-system-arm hangs if a big task is installed (affects: 1)" [Medium,Incomplete] https://launchpad.net/bugs/532733 | 16:27 |
| ogra | well, i dont know why it hangs but installing karmic ubuntu-desktop doesnt expose the hang | 16:28 |
| lool | ogra: did you strace the processes as I suggested? | 16:28 |
| ogra | while using a lucid userspace inside qemu does | 16:28 |
| ogra | yes, nothing | 16:28 |
| lool | nothing? | 16:28 |
| ogra | well, i straced apt ... | 16:28 |
| lool | It's certainly in one syscall, or its hung using all CPU; no? | 16:28 |
| ogra | no, nothing, it just stops | 16:29 |
| lool | On which syscall? | 16:29 |
| * ogra will need to re-run ... i threw away the image to make room | 16:29 | |
| === bjf is now known as bjf-afk | ||
| ogra | these qemu-system-arm images start to eat my disk space :/ | 16:30 |
| lool | ogra: You mean the expensive megabytes of your SSD :) | 16:31 |
| ogra | heh, yeah | 16:32 |
| Meizirkki | What's the state of Lucid regarding arm support ? | 17:09 |
| Meizirkki | dpkg goes segfault on my Touch Book.. | 17:10 |
| ogra | lucid is v7 and thumb2 | 17:10 |
| Meizirkki | hmm | 17:10 |
| ogra | does your CPU support both ? | 17:10 |
| Meizirkki | lemme see | 17:11 |
| * ogra thinks touchbook was omap ... some cortex-a8 so it should actually work | 17:11 | |
| Meizirkki | it's based on beagle board | 17:13 |
| Meizirkki | thumb is supported, i'm not sure about thumb2 :( | 17:13 |
| ogra | right | 17:13 |
| ogra | it should be supported ... | 17:13 |
| ogra | how exactly does it fail ? | 17:14 |
| Meizirkki | for example: "apt-get install something" it starts downloading but very soon says http method died unexpectedly (Segmentation Fault)) | 17:15 |
| ogra | thats not dpkg | 17:15 |
| Meizirkki | and if i repeat it enough it will eventually get it all downloaded, but then dpkg fails to unpack packages because of Segmentation Fault | 17:16 |
| ogra | hmm, intresting | 17:16 |
| Meizirkki | Yes they both segfault | 17:16 |
| ogra | we dont see that on imx51 or dove boards | 17:16 |
| Meizirkki | According to elinux.org lucid does run on BB as well.. | 17:17 |
| ogra | where did you get the kernel ... and what kernel version are you running ? | 17:17 |
| Meizirkki | The kernel is a mess.. provided by Always Innovating (the company selling TB) | 17:18 |
| ogra | what version | 17:18 |
| ogra | lucid needs .32 | 17:18 |
| Meizirkki | 2.6.29 | 17:18 |
| Meizirkki | alright | 17:18 |
| Meizirkki | that's it :) | 17:18 |
| ogra | hmm, might be :) | 17:18 |
| Meizirkki | thanks for all the help | 17:18 |
| ogra | welcome ... | 17:18 |
| ogra | there is a beagle kernel for lucid on the beagle wiki though | 17:18 |
| lool | Meizirkki: this sounds like a hardware stability proble | 17:18 |
| lool | m | 17:18 |
| ogra | not sure that has all the touchbook drivers though | 17:19 |
| lool | Meizirkki: Is the segfault happening always at the same place? | 17:19 |
| Meizirkki | lool, | 17:19 |
| Meizirkki | yes | 17:19 |
| lool | Meizirkki: Is it actually a "segfault", or is it e.g. a sigbus? | 17:19 |
| Meizirkki | segfault | 17:19 |
| Meizirkki | lool, knowing there are some hardware bugs.. it might be a hw stability problem as well | 17:20 |
| lool | Meizirkki: Unless your libc/dpkg are heavily modified causing the segv, it rather points at hardware stability issues to me | 17:20 |
| lool | Meizirkki: If random programs segfault, not just dpkg, then it's certainly the case | 17:21 |
| lool | Meizirkki: Out of curiosity, where did you get it? | 17:21 |
| Meizirkki | Touch Book ir Ubuntu ? | 17:21 |
| Meizirkki | o | 17:21 |
| ogra | cant you buy it at AI ? | 17:21 |
| lool | Meizirkki: the TB | 17:21 |
| Meizirkki | I bought my Touch Book from AI | 17:21 |
| Meizirkki | It's from the second batch i guess.. | 17:21 |
| lool | Meizirkki: If you want to rule out userspace changes, you can debootstrap Ubuntu lucid into a local clean chroot, dpkg is stable for us | 17:22 |
| Meizirkki | AI kernel is a bit strange too, size 5MB and it doesn't have any omap3 powersave stuff or even IP multicasting.. but some android patches.. | 17:22 |
| lool | Meizirkki: So that it can run android! | 17:24 |
| ogra | instead of lucid :P | 17:24 |
| Meizirkki | haha | 17:25 |
| Meizirkki | I'm looking forward seeing a recent omap-pm kernel running on it though, they will never get 10-15 hours of USE with this kernel | 17:26 |
| Meizirkki | (on one charge) | 17:26 |
| ogra | sure ... with the extra car battery attached :) | 17:27 |
| Meizirkki | lol | 17:27 |
| Meizirkki | it does 16 hours without wlan which is nowhere near enough | 17:28 |
| Meizirkki | They'll send me a new keyboard-part for free => 12A extra battery :P | 17:28 |
| * Meizirkki boots up lucid | 17:34 | |
| lool | persia: poke | 17:40 |
| lool | if [ ! -f "/usr/bin/build-arm-chroot" ]; then | 17:40 |
| lool | sudo apt-get install qemu-kvm-extras-static | 17:40 |
| lool | fi | 17:40 |
| lool | DEBOOTSTRAP_COMMAND=qemu-debootstrap | 17:40 |
| lool | persia: Sounds like DEBOOTSTRAP_COMMAND=qemu-debootstrap should be first and you should test with if ! which $DEBOOTSTRAP_COMMAND >/dev/null 2>&1 ... | 17:41 |
| ssvb | Meizirkki: Cortex-A8 r1pX (typically r1p3) from OMAP34xx/OMAP35xx chips has quite a number of thumb/thumb2 hardware bugs | 17:57 |
| ssvb | if you really want to use thumb, you need to apply some workarounds | 17:57 |
| ssvb | Meizirkki: at the very least you need to have CONFIG_ARM_ERRATA_430973=y option in the kernel configuration | 17:59 |
| Meizirkki | okay, thanks | 17:59 |
| ssvb | and some of the fixes have to go to the bootloader | 17:59 |
| ssvb | so without this option enabled, you are going to have segfaults in thumb code for sure. If it does not help, then your bootloader did not set IBE bit in AUXCR and you will have to fix it there too | 18:03 |
| ssvb | Meizirkki: additionally your binutils package should be recent enough to have this workaround: http://sourceware.org/ml/binutils/2009-05/msg00297.html | 18:05 |
| Meizirkki | thanks | 18:05 |
| ssvb | good luck and if you get stuck, you can poke me regarding all this thumb stuff :-) | 18:06 |
| Meizirkki | I'm stuck already :P as I'm not that familiar with the hardware.. but i'll at least file bug to AI so they can fix their kernel and u-boot :) | 18:07 |
| ssvb | ok, that may be the best solution, don't forget to provide them with these errata numbers and links, if they have Cortex-A8 errata list pdf, they will be able to dig up all the necessary details from it | 18:10 |
| === bjf-afk is now known as bjf | ||
| persia | lool: Indeed. That's a much better way to do it. | 23:27 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
