[00:21] lool: Needs work on options to handle both --arch powerpc and --arch=powerpc, but looks lovely otherwise. [00:29] Ugh. No it doesn't. Looks bug-for-bug compatible with debootstrap :( [00:30] Anyway, you shipped it, and it looks good, and I'll make the tools use it. [00:31] ( well, unless system_arch == amd64 && deb_arch == i386 | lpia ) [01:43] morning all [01:46] i'm coming again [03:32] how to use the qemu in the rootstock [03:34] You'll have to wait at least 5 hours for good rootstock support. === DanaG1 is now known as DanaG [05:47] hi guys i dont see the mini2440 as being a supported board is possible and just untested ? [05:49] * persia tries to figure out what a "mini2440" is [05:49] tkmedia: It might be able to run Jaunty, but nothing newer. [05:49] I'd recommend using Debian on that platform. [05:50] (assuming we're talking about a board with a Samsung S3C2440A ARM920T ) [05:50] yes thankyou [05:50] Glad to help. If you decide to run Jaunty, the install may be a bit tricky, but ought work. [05:51] intrepid actually would be nice [05:51] 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] Intrepid wasn't compiled for armel. [05:51] k [05:52] whats the best way to try jaubty [05:52] juanty [05:53] Do you have a working 2.6.28 or newer kernel for the board? [05:54] 2.6.29 [05:54] That ought work. [05:54] Do you have a local Ubuntu install from which to prep stuff? [05:54] (if so, which release?) [05:54] i have severla vm's [05:55] ones a 0910 [05:55] OK. So the easiest way to get a rootfs is probably to run rootstock in the 9.10 environment. [05:55] yep did that [05:55] And you created a jaunty rootfs? [05:56] hmm let me chk [05:56] i used the example [05:56] with minal lxde [05:57] Which example? [05:57] top [05:57] From which page? [05:57] sec [05:58] sudo rootstock \ [05:58] --fqdn myhostname \ [05:58] --login ubuntu \ [05:58] --password temppwd \ [05:58] --imagesize 2G \ [05:58] --seed xubuntu-desktop [05:58] but changed seed [05:58] to lxde [05:58] Right. [05:58] ,gdm [05:59] so that should work with the .29 kernel right? [05:59] Yes, but. [06:00] You want to add --dist jaunty [06:00] kernel panic [06:00] The default is --dist karmic [06:00] ahhh [06:00] And that will generate binaries that include instructions not supported on your chip. [06:00] ok cool [06:01] So try again, and if that doesn't work, please ask again. [06:01] so thats why i got kernel panic ? [06:01] I'm not sure, but possibly. How did you construct your kernel? [06:01] Are you sure your kernel works? [06:01] yes [06:02] let mtry with dist-juanty [06:02] 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] "jaunty" [06:02] and will be back if any more questions [06:02] thanks [06:02] Good luck! [06:03] so just -dist jaunty on the bottom [06:03] added [06:12] hmm, weird thing about the rcn-ee images: the ubuntu username isn't uid 1000. [06:12] same for GID: not 1000. [06:49] DanaG: It isn't on the Live CD either, since that would conflict with installed systems [06:49] (And then you could potientally read other users files) [06:52] Though, with livecd, you can read them anyway, as root. [06:52] And the UID was like 1002 (which still could collide), and the image was an installed system. [06:53] Right, but that falls under "You have physical access, so ..." [06:55] Oh, and the UID of things like "fuse" were different too. [06:55] 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:58] hello [07:00] can somebody help me? [07:02] go ahead and ask the issue itself, instead of just asking if anyone's around. =þ [07:05] ok, I have PDA Asus A363 can I install ubuntu on this device? [07:06] hmm, you'd have to find out more about what the chip is, for one. [07:07] one moment [07:07] processor type - Intel XScale PXA272 416 MHz [07:08] weird, I see nothing about "asus a363" on the internet. [07:08] er, not "nothing", but not too much. [07:08] ROM 128 Mb, RAM 64 Mb [07:08] 64 megs RAM is tiny. [07:09] http://vip.asus.com/forum/view.aspx?id=20070507004052843&board_id=6&model=MyPal+A636&SLanguage=en-us&page=2 [07:11] :) I don`t like a Windows [07:11] I want ubuntu ;) [07:13] gevz: OK. What device do you have? [07:14] A363 [07:15] ASUS MyPal A363? [07:15] yes [07:15] OK. According to http://www.handhelds.org/moin/moin.cgi/MyPal you should be able to run linux [07:16] Or maybe not [07:16] * persia looks harder [07:17] Really a A363 and not a A636> [07:17] s/>/?/ [07:18] I can't find any information about the A363, unfortunately. [07:18] The A626 can run Linux, but only Ubuntu 9.04 and nothing newer. [07:18] The resolution is also low enough the experience may leave something to be desired. [07:18] I'd recommend Debian for such a device. [07:18] oh... excuse me, I mistake [07:19] A636 [07:19] Which is the mistake? [07:19] Ah, that's better :) [07:19] not A363 [07:20] But yeah, for the A636 you can run Jaunty if you hack it. [07:20] how i can do it? [07:20] I'd recommend starting from http://www.handhelds.org/moin/moin.cgi/A636 [07:21] Once you have figured out how to install linux, installing Debian or Ubuntu becomes easier. [07:25] ok, I do not quite understand where I start [07:26] this link to list of hardware, but I can`t understand how to install linux? [07:27] For devices of that class, one usually has to construct a replacement firmware and proceed with the "firmware upgrade" procedure. [07:27] I recommend searching for available documentation carefully, as there is a risk you can make the device unbootable. [07:28] I don't see any good guides from a quick search myself. [07:28] ok, please help me [07:29] I have compiled a list of equipment, what next? [07:31] I'm really not sure how to help, and don't want to give advice that will make your device useless. [07:32] The next step is to understand how the device boots. [07:32] Once you have that, compile a customised kernel, and get the device to boot that kernel. [07:32] Once you have that, you can start considering what you want for a filesystem. [07:32] But the first two steps are big ones. [07:34] What image do I download ubuntu? [07:34] There exists no image of Ubuntu that will work on your hardware. [07:34] You can potentially construct something that works, but it's non-trivial. [07:34] ok, thanx [07:35] 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] Is that to be expected? [07:35] Yes. [07:36] hm [07:36] please explain [07:36] I kind of expected the file to be populated, obviously. [07:36] I don't believe debootstrap automatically populates that. [07:36] So this is expected behaviour. [07:37] let's rephrase the question [07:37] From your ability to run that command, I presume you're using lucid. [07:37] Shouldn't debootstrap populate the file? [07:37] No. [07:37] why not? [07:37] I run lucid, yes [07:38] So, if you want to create a chroot for use, I'll recommend you use `mk-sbuild --arch=armel lucid` [07:38] This will work, populate everything, and give you a summary of ways to use the chroot. [07:38] lool: asked me to test his scripts [07:38] Oh, if that's what your're doing, then you're doing it right. [07:38] and I don't mind a few rough edges here or there [07:40] why do you think debootstrap ought not to populate sources.list? [07:40] because there's extensive logic in mk-sbuild to populate it after the debootstrap run. [07:40] gevz: you may also have a look at openembedded [07:40] what this? [07:41] gevz: google should tell you [07:41] I have ban on google ;) [07:41] or any other search tool, really. [07:41] Then use something else :) [07:41] Laibsch: morning [07:42] gevz: OE is very well suited for your problem of getting a kernel compiled [07:42] lool: good morning [07:42] OE is also well suited to that class of device. [07:42] probably [07:43] * Laibsch hopes to lower the bar for ubuntu-arm eventually [07:43] But I fully support the decision to focus on more powerful devices first [07:43] Laibsch: Not first: only. We expect the market to catch up with us by the time we're sorted. [07:44] yes, I was afraid that may be the case [07:44] There ain't nobody there to tell me I can't try, though ;-) [07:45] Speaking of which [07:45] persia: (from this night) ARM920T + jaunty isn't going to work I'm afraid [07:45] Now that I have my armv7l chroot, how would I go about trying to compile armv5te software? [07:46] what knobs do I need to fiddle with? [07:46] lool: No? Why not. [07:46] Laibsch: You need to change the compiler defaults. [07:46] 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:47] Laibsch: sbuild usually pulls the source by its own means IIRC [07:47] persia: ARM920T is v4 [07:47] lool: Ah. So it needs to be ARM11+ ? [07:47] I thought it was ARM9+ [07:47] I think some ARM9xxs are v5, but rare [07:47] Best to check the wikipedia page [07:47] That makes sense. Still, I think anyone with older hardware should be running Debian anyway. [07:47] yes [07:48] It's frustrating to get stuck not being able to upgrade. [07:48] Anyway, sbuild doesn't do anything special with sources.list. It just presumes that one exists in the chroot. [07:48] mk-sbuild populates one based on the arguments it gets passed. [07:48] persia: where are those changed? [07:49] Laibsch: Which? [07:50] the compiler defaults [07:50] so that I can compile for armv5te [07:50] No idea. I'd guess in the gcc package. [07:51] lool: ? [07:52] I guess the question can be put another way [07:52] who changed what where to specify that lucid is armv7l? [07:52] I'll just turn that back locally ;-) [07:52] Laibsch: gcc-4.4 package [07:52] we configure it with the defaults [07:53] Laibsch: I'm not sure you realize how long and complex and heavy that's going to be [07:53] It's not impossible, but building gcc-4.4 takes days espcially under qemu or older v5 hardware [07:53] probably [07:53] Then you need to bootstrap everything such as eglibc, binutils etc. [07:54] I don't mind days of compilation [07:54] Laibsch: You intend to build on v5 hardware? [07:54] When I started with OE my machine was seriously underpowered (it kind of always was) [07:54] It took about a week to build the toolchain for me [07:54] and things broke often, so it may have been a month before I had anything working [07:54] You should expect a similar amount of pain. [07:54] not a big problem [07:55] especially since I can always use OE-compiled software [07:55] But I want to move slowly away [07:55] uh? [07:55] I think native compilation makes more sense [07:55] 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] Laibsch: tired of OE? :p [07:55] ynezz: yes [07:56] but basically I understood that OE is not the right tool going into the future [07:56] for me [07:56] I'm looking more for a desktop experience on the devices I have [07:56] isn't it more about koen? [07:56] Openembedded is of course, more embedded [07:57] yes and no [07:57] ok [07:57] I sat down and thought about if OE gives me what I need [07:57] and if it's going in the direction I want it to go [07:58] 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] I don't see that changing and I'm more of an end-user [07:58] My hope is ubuntu-arm/debian-arm will eventually be able to output something usable for the ordinary user [07:59] [02:45] persia: (from this night) ARM920T + jaunty isn't going to work I'm afraid [07:59] tkmedia: Sorry about that. My mistake. [07:59] hmm looks like troouble [07:59] np [07:59] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,3) [07:59] tkmedia: Should be able to run Debian, I'd think. [08:00] k [08:00] Laibsch: I've started using ubuntu for the same reason, for headless boards with 32MB RAM is OE the best... [08:00] Congratulation of all women in this chatroom with 8 March!!! [08:00] bye [08:01] how can you tell which ver arm the device will run [08:02] http://en.wikipedia.org/wiki/ARM_architecture gives some useful guidance [08:02] 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] cooloney: Do you happen to know if our kernels do anything with XN ? [08:03] tkmedia: This is not related to jaunty thouhg [08:03] tkmedia: a binary incomptibility would show up as a sigill, like init being killed [08:06] ok what is a good dev board .... i like the beagle boards but want a 7" lcd like the samsung [08:10] tkmedia: DO you need 7"? The NetWalker has 5" and is a complete netbook to boot. [08:12] prefer a little larger but will look into it thanks [08:13] 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] (or if it doesn't, complain to me about it, and I'll try to fix that) [08:13] tkmedia: in month or so, there should be LCD+Touchscreen avialable for BB from Tincantools [08:14] persia: sorry, have no idea about that? what's XN? for fsl-imx51? [08:14] yes I want something that could be wall mounted [08:14] tkmedia: Always Innovating Touchbook may be something to check out [08:15] 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] Laibsch: Have they solved the shipment delay issue? [08:15] no idea [08:15] I was just visiting their homepage this minute [08:16] which is why I mentioned it [08:16] what backlog do they have? [08:18] interesting [08:18] nice form factor [08:18] Laibsch: I heard it took a couple months to get delivered. I'd be glad to be wrong. [08:19] ynezz: I believe specialcomp.com also has some sort of touchscreen, though probably low-res. [08:20] 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] DanaG: that show dog board from tincantools should have 800x480 for price about $149 [08:20] DanaG: 7" [08:20] forget to mention that [08:21] what's the difference between zippy and zippy2? [08:21] ynezz: Which driverdoes it use? [08:21] I see no LCD at tincantools. [08:21] persia: dunno :) ask prpplague on #beagle [08:21] oh yeah, I used these kernels: http://rcn-ee.net/deb/kernel/beagle/ [08:22] ah, 10/100 in zippy2. [08:22] DanaG: it should be available in month or so [08:22] ynezz: Oh, it's a special Beagle expansion? [08:22] * persia was hoping for something generic [08:22] persia: ok, i see, just a quick digging [08:22] cooloney: If you can get that to work, the security team will love you :) [08:22] it is available since ARMv6 [08:23] Right, but I don't think we ever turned it on. [08:23] persia: yes, beagle related [08:23] #define PMD_SECT_XN (1 << 4) /* v6 */ [08:24] persia: but i am not sure how to use it. [08:24] persia: need some time to take a look [08:24] persia: I think Kees had a look and flipped a logic bug in arm code [08:25] So I actually think it's working and enabled [08:25] lool: Really? That's different than what I last heard, but I would be glad to have missed something. [08:25] cooloney: Cool. Maybe check with kees: if lool is right, nothing to do. [08:25] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/364358 http://www.outflux.net/blog/archives/2009/11/24/missing-kernel-features-in-arm/ [08:26] 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] cooloney: ^ [08:26] So I'm pretty XN works now [08:26] Cool! [08:26] +sure [08:26] I caught the original blog post, but not the followup. [08:28] what does "ASLR" stand for? [08:28] http://en.wikipedia.org/wiki/Address_space_layout_randomization [08:29] Makes it harder to take advantage of buffer overflow exploits, poke exploits, etc. [08:35] ah. [08:35] anyway, bedtime now. =þ [08:35] lool: thanks, [08:36] cooloney: Did you manage to look into the kexec problem? [08:36] and from the code arch/arm/mm/mmu.c [08:36] lool: yeah, we found a way in imx51 and mvl-dove [08:36] i prepared a kernel package for versatile alreayd [08:36] and going to test it now [08:36] if you wanna test, please take a look at this bug [08:37] https://bugs.launchpad.net/adana/+bug/517841 [08:37] cooloney: Error: Bug #517841 is private. [08:38] persia: XN bit is enabled when arch >= ARMv7 [08:38] http://kernel.ubuntu.com/git?p=roc/ubuntu-lucid.git;a=shortlog;h=refs/heads/kexec-versatile is the branch [08:38] http://people.canonical.com/~roc/kernel/kexec/ has the binary kernels [08:41] yeah, [08:41] but we still have to patch the kexec-tools [08:42] cooloney: That's fine. [08:44] Only for initramfs support though [08:46] lool: do you mean another issue about initramfs on versatile? [08:47] lool: i saw your config patch was merged [08:47] cooloney: Didn't yet try with [08:47] my patch in [08:47] cooloney: But we should really fix the initramfs issue [08:48] perhaps it's a similar problem actually! [08:48] perhaps our kernel is too big! [08:48] I didn't think of that [08:48] yeah, the issue is very similar, without patching the kexec-tools to increase the size [08:48] we can not kexec reboot the kernel [08:48] cooloney: Question [08:49] it looks like the similar in qemu [08:49] cooloney: the kernel knows where it's loaded, how big it is, and where the initramfs is supposed to me [08:49] cooloney: Don't you think the kernel should test whether kernel start + kernel size < initramfs start? [08:50] lool: normally, the bootloader should take care of that, such as uboot or qemu [08:53] cooloney: Don't you think it's a good idea to have such a sanity check to avoid debugging kexec like we did? [08:55] cooloney: With your kernel, I still can't load initrds *gah* [08:55] cooloney: I think it's due to the same bug as for kexec, or similar [08:56] cooloney: Do you have a recipe for converting a vmlinuz to a vmlinux? [08:56] lool: you wanna try vmlinux, right? i can uploaded for you [08:57] cooloney: Would be nice, thanks [08:57] I do see "cramfs" in the list of attempted file systems now; but it doesn't work [09:00] cooloney: So with your kernel to run qemu and loaded with kexec, it still hangs as before [09:00] "Starting new kernel" and nothing more [09:00] ok [09:00] there is no "Uncompressing...," right? [09:01] cooloney: Let me try with the serial console trick [09:01] I get more output in this way [09:01] * ogra glares at klibc buildlog ... -march=armv4 -mtune=strongarm [09:01] cooloney: Well using an uncompressed kernel might improve the test; let's try with one [09:01] hrm [09:02] lool: no problem, i am uploading, but it will take some time [09:02] due to the slow connection at my home [09:03] cooloney: Press the "FAST" button below your modem [09:03] sometimes it's labeled TURBO instead [09:03] ogra: Please fix :) [09:03] persia, well, thats not the cause of the ftbfs [09:04] Yeah, but :) [09:05] lool, isnt that a software switch that needs this proprietary program from www.modemspeedier.com ? [09:06] ogra: Depends on the modem. The better class have external controls that do the same thing as the extended AT sequences. [09:07] heh [09:10] cooloney: Updated the kexec/versatile bug [09:10] lp #518567 [09:10] 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:14] cooloney: Found how to convert the image (I think) [09:15] Hmm not sure [09:16] I get no vidoe output, so seems my vmlinux is busted [09:18] lool: i found 2 vmlinux in my build dir [09:18] one is 61M, [09:18] one is 3M, which is not for this [09:19] lool: or just Image? [09:19] cooloney: I think we want vmlinux [09:19] cooloney: but you can strip it [09:19] vmlinuz is stripped and gzipped which is why it's much smaller [09:20] My vmlinux is 6.3 MB so that seems about right [09:20] ok, will do that [09:21] cooloney: YES! [09:22] cooloney: So booting your vmlinuz and kexecing the vmlinux I created works [09:24] cooloney: So don't bother uploading [09:24] So many problems here, vmlinuz loading broken, vmlinux boot broken, need to test initrd support... [09:26] ok, understand now [09:26] you convert the vmlinx from my vmlinuz [09:26] and kexec that, right? [09:27] Yes [09:28] ok, cool [09:29] ericm_: why do we use CONFIG_OABI_COMPAT=y ? [09:29] cooloney: That's a good workaround, but would you be interested in chasing the other issues? [09:29] asac, that's for old ABI binary to be still able to run [09:29] asac, it's harmless - any issue you found related to this? [09:31] lool: i'd love to, [09:31] 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] persia: I'm not, I applied the same heuristics as the qemu Debian package [09:31] OK. I'll just follow along then. [09:32] 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] ericm_: mvl asked why we still have that. i think they thought it would help if we'd drop it [09:32] iirc there were also some performance claims [09:32] lool: I think the same is true in every case in my example. [09:32] if you say it shouldnt hurt at all, fine. [09:32] persia: but I don't have hardware and I didn't want to write overly complex code I couldn't test [09:32] persia: Yes, I'm only giving an example [09:34] asac, so far no related issues with that [09:34] ericm_: we could get rid of OABI. We don't care about letting older ABI binaries run on Ubuntu... [09:34] ericm_: but is there any reason to keep it? e.g. EABI is already really really old [09:34] right [09:35] 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] 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:36] lool: I think you're right, and I don't want to fuss with it enough to try to fix it now. [09:36] ericm_: I remember that I turned it off on FSL [09:37] 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] asac, amitk, it's actually not very old, EABI became popular in less than 2 years [09:38]