[02:23] wg 2 [10:17] has anyone ever dealt with mmap and virt_to_phys address translation on arm? ogra? [10:18] whats your prob ? [10:19] briefly this: http://linux.omap.com/pipermail/davinci-linux-open-source/2009-September/016102.html [10:19] well, not so brief... :P [10:20] ogra: I think virt_to_phys behave differently in i386 and arm, but I'm not finding what. [10:22] i know the minimal addresses are different on arm vs intel ... but that shouldnt stop you from using it [10:22] I think so, but I got only zeroes. [10:23] did you read the link above? [11:26] gaspa: Hmm isn't the kmalloc area already remapped? [11:26] gaspa: Anyway you want to bring this up on some kernel chan; we're not so much into kernel dev here [11:28] gaspa: that sounds exactly like what the android pmem driver does [11:30] lool: I tried also calling pfn_range with kmalloc_area directly...(if that's what you meant... otherwise I didn't catch what you said ;) ) [11:30] ali1234: I don't know at all android, have you any pointer to this pmem driver? [11:32] "Android/PMEM: The PMEM (physical memory) driver is used to provide contiguous physical memory regions to userspace libraries that interact with the digital signal processor (DSP) and other hardware that cannot cope with scatter-gather." [11:33] source: http://android.git.kernel.org/?p=kernel/common.git;a=blob;f=drivers/misc/pmem.c;h=44c0ae8515bac186a7a0a3060204b29ef7b21130;hb=f92ea0328d3a0bb5386d52fd68ae4e10ca1ebce6 [11:34] ali1234: seen, but I'm not facing with device memories, it's just a test to learn using mmap so i'm currently using normal RAM [11:34] anyway, i'll take a look. ;) [11:35] ok, well, the memory address by pmem is like any other, it just happens to be shared with devices so outside what linux considers general purpose ram [11:36] ultimately it just remaps it and makes it into a device file in userspace [11:36] it's a bit of a hack to make obfuscated userspace drivers work [11:37] there's the /dev/mem driver too which does the same thing but on the whole of the address space [11:38] that one is probably simpler/nicer [11:38] yes, in fact my code went from that (indirectly) [11:42] ali1234: BTW: thanks! [11:42] pmem seems interesting, but for other purposes of mine ;) [12:06] eggonlea, i'm just working on rootstock [12:06] eggonlea: Hey [12:06] eggonlea, it needs some massive changes to work with the new upstart ... init=/bin/bash doesnt work anymore [12:06] hi [12:07] well, it does work, but you cant start any services anymore, i'm working since this morning to find a proper way around that [12:07] do you mean the rootfs is created but the /etc/init.d/udev start should be removed [12:07] the bugfix for teh networking stuff is already in my local branch but doesnt make sense to push unless the rest is fixed [12:08] new upstart prevents /etc/init.d/xxxx scripts from beiong executed directly [12:08] you need to use the service utility for that, which only works if upstart is running [12:09] so... will upstart work with "chroot"? [12:09] but since rootstock uses something similar to init=/bin/bash upstart isnt running and the service utility doesnt find the upstart soocket to send its messages to [12:09] no, and it doesnt have to [12:09] it needs to work with a VM [12:10] and the rootstock installer needs to be spawned by upstart [12:10] so i'm trying to convert everything to it atm [12:10] I see. so rootstock/qemu should be ok after fixing the init scripts between first_run and second_run [12:11] well, the second run actually has to become an upstart job [12:11] and thats what i work on [12:11] please let me know if I could contribute on this. [12:11] well, do you know much about upstart jobs ? [12:12] * ogra is in the middle of rewriting the installer [12:12] know some high level configuration but no deep understanding into the code [12:14] * ogra fires up another test, cross your fingers ;) [12:15] please [12:15] my pleasure [12:15] i switched the first stage completely to qemu-arm-static btw ... it takes less than 10min now to get to the VM [12:15] instead of 30+ [12:15] it never costs so much time before. [12:16] I think ~10 minutes for ubuntu-minimum before [12:16] you mean it doesnt sit eternally in "I: Configuring core packages..." after it switched to VM on your side ? [12:17] it surely does for everyone else [12:17] but if the whole thing took 10min for you before it will only take 2 now ;) [12:17] let me see if I could find the log back. [12:19] cool [12:19] I cannot get the log back. [12:19] I'll record them next time [12:20] after it switched to VM it did a lot of debootstrap processing where it got very slow ... and just sat there [12:20] i had a lot of user complaints about that [12:20] i moved all of debootstrap out of the VM and it operates a lot faster now [12:20] I have a question: could we leave the second part to run on the real board intead of qemu? [12:21] i a later version, not for karmic [12:21] why? any tech obstacle? [12:22] could you file a whishlist bug about that ? [12:22] we're past feature freeze [12:22] got it. [12:22] i wont add new features to it now [12:22] only fix up existing stuff and add speedups [12:23] Sure, I'll do that. [12:23] so, when do you expect to have a workable one? [12:23] i hope later today [12:24] what a good news! [12:24] upstart doesnt seem to be happy to run in a VM though ... i need to find out why first [12:25] thanks and wait... no more question to interrupt your work, then. [12:25] again, if you have anything need a man to test or debug, please let me know. [12:25] will do, thanks a lot for the offer :) [12:26] or, you could drop your engineering version to me. [12:27] create a branch on LP, send it on ubuntu-arm maillist or to aawlbt@gmail.com directly. [12:29] http://paste.ubuntu.com/275799/ [12:29] i'm in the middle of reworking it, it wont work, but you can take a look [12:30] got it. [12:33] note that the new version needs qemu-arm-static installed [12:34] * ogra goes to find some lunch while another test runs [12:47] * eggonlea go home for supper [14:21] ali1234, lool: solved... aerhm. I was mmap'ing with PROT_NONE ;) [15:24] I: ARM rootfs created as /var/build/rootstock-fixing/armel-rootfs-200909221611.tgz [15:24] I: Cleaning up... [15:24] ..... [15:24] I: A logfile was saved as /var/build/rootstock-fixing/rootstock-200909221611.log [15:24] I: done ... [15:24] WOHOO ! [15:31] ogra: WTF is this -Nqemu-arm-static stuff?? [15:32] -N ? [15:32] no idea, i surely didnt add any -N [15:36] i guess kirkland added that the statci branch doesnt exist in the other builds, its a second pass with a copy of the sourcetree [15:37] It's ridiculous [15:37] remove it if it doesnt break the build [15:37] you cant build -static in the same pass as nonstatic [16:10] ogra: The rules are absolutely horrid [16:10] I've never seen so many policy violations and programming errors in the same rules [16:10] Starting with binary: binary-static binary-indep binary-arch [16:17] Geez clean depends on config.status [16:22] Where can I find the launchpad files that generate the karmic-desktop-armel+dove files? [16:26] found 'em [16:35] Martyn: :D [16:36] armin76 : generating an image for pbx-a9 is going to be fun [16:36] "fun" in the "I think I need a rusty 10 foot stake shoved up ..." [16:36] way [16:51] lool, i refuse any responsibility for clean ! :) but you can blame me for everything with -static [16:52] sigh, i really wonder how livecd-rootfs still works with the upstart changes [16:53] cups is definately unhappy about Failed to connect to socket /com/ubuntu/upstart: Connection refused [16:57] What does it changes for livecd-rootfs? [16:57] Hmm probably we should disable start/stop/service there [16:58] i'm comparing the code atm [16:58] there is not a single change from Keybuk [16:58] i wonder why it works [17:01] oh, it diverts usr/sbin/invoke-rc.d [17:03] Yes [17:03] You dont? [17:03] nope [17:03] i run a VM [17:04] up to now i didnt divert anything ... there was never a need to [17:05] i dont see it touching start-stop-daemon though [17:05] (i know it did once in the past) [17:05] I thought you were using a chroot not a vm [17:06] original rootstock: chroot for first debootstrap stage, VM for rest [17:06] new rootstock: chroot for complete debootstrap stage, VM for rest [17:07] future rootstock (if the binfmt issues are fixed): chroot for complete build [17:13] Martyn: gimme ssh access to the babbage board plz :P [17:23] armin76: Sure, give me a couple hours though [17:24] armin76: I'm in the middle of doing a new Karmic buildroot on the babbage and on the PBX-a9 [17:24] armin76: Do you have my IM? [17:25] armin76: Babbage v1 is okay? [17:26] Martyn: armv7 is okay :) [17:26] how much space? [17:27] 5x5" :P [17:27] in fact i wasn't expceting you would say yes [17:27] * armin76 is just happy with ssh+being able to chroot [17:38] * armin76 blames ogra for martyn running away [17:39] sure sure, blame me ! [17:39] .oO(was martyn -static ?) [18:04] ogra: Why did you name the package qemu-arm-static instead of qemu-static? [18:05] because its arm onyl [18:05] *only [18:05] and needs its own postinst [18:05] But we could easily have multiple binaries in there [18:05] we shouldnt [18:05] Why not? [18:05] qemu-system-arm is in qemu-kvm-extras [18:06] Among others [18:06] i personally dont want ppc or mips if i need just an armel chroot [18:06] yeah, i dont like that either [18:06] You have qemu-system-mips64el and qemu-system-ppc64 and a bunch others with qemu-kvm-extras [18:06] i'd prefer a binary for every arch [18:06] but qemu system doesnt need the binfmt stuff [18:06] That would be huge [18:06] nor does it need the sysctl settings [18:06] 15 binary packages [18:07] fine [18:07] That's huge [18:07] i wouldnt mind 15 binary packages if i can then install only for one arch i care for [18:07] The qemu-arm-static approach isn't consistent with qemu-kvm-extras [18:07] i created it before qemu-kvm was in the archive [18:08] bah it was the same before the qemu-kvm package [18:08] i just tried to merge the -static stuff into the existing package on kirklands request [18:08] in any case there exists no -static flavour thats integrated for karmic [18:08] I'm saying it's inconsistent to have one package per target for the static flavour and one package for all targets in the shared flavour [18:09] apart from arm [18:09] So? [18:09] It's still inconsistent [18:09] so the naming is fine for the moment [18:09] ogra: What would it change for you if it was named qemu-static? [18:09] Or qemu-kvm-static [18:09] beyond i highly object having to have ppc sysctl and binfmt mangling installed just because i want arm [18:10] You wont since it only has arm [18:10] they might even conflict [18:10] ppc might be added in L [18:10] i know at least one person trying to work out support for mips and ppc in debian over the next months [18:11] Yeah so your argument that there exists no -static flavour thats integrated for karmic apart from arm is moot :-) [18:11] no [18:11] the package adds binfmt handlers and sysctl settings [18:11] its different from the non static version [18:11] Yes [18:12] thats why static binaries should have one package per arch [18:12] and the proper conflict/breaks settings if needed [18:12] Does debian/binfmt-arm correspond to ARM binaries? [18:12] yes [18:13] Does it match e.g. ppc binaries [18:13] no [18:13] So I dont see the issue you mention [18:13] the magic is different [18:13] sysctl is the issue [18:13] binfmt is just ugly [18:14] Isn't there a common sysctl we can find for other arches? [18:14] i dont want to have a ton binfmt handlers installed if i only need one arch ... as i said before [18:14] I dont want to have 15 packages cluttering Packages.gz [18:14] if it comes to sysctl there might even be conflicting settings [18:14] you wont convince me :) if you feel its needed to change the package, do it ... [18:15] i'll live with it ... [18:15] Ok [18:15] but you wont convince me :) [18:15] just tell me how it's called in the end so i can change the arm docs accordingly [18:15] I personally prefer keeping things consistent between static and shared [18:15] If it creates issue we can look into them and see if we need to split [18:15] its a different purpose [18:16] I think it's premature optimisation to name the package -arm and doesn't match the shared package; I personally find it misleading that qemu-static-arm changes system wide settings in a way not specific to ARM stuff [18:16] Such as the sysctl knob you mention [18:16] * ogra wonders about "udevd[392]: specified group 'fuse' unknown" in the recent rootstock test [18:17] right, kees and i tried a better approach [18:17] but the support doesnt work yet [18:17] so i had to resort to sysctl [18:17] there are plans for a per binary solution in the security team [18:17] just not there ydet [18:18] (see changelog, i went back and forth through several solutions) [18:18] (guided by kees) [18:20] hmm, why dont i see the fuse errors in livefs buildlogs ? [18:21] there is nothing in livecd-rootfs that would touch /etc/group [18:24] Unpacking linux-headers-2.6.31-101-imx51 (from .../linux-headers-2.6.31-101-imx51_2.6.31-101.8_armel.deb) ... [18:24] hrm [18:24] why is that pulled in by ubuntu-desktop [18:26] * ogra sees "apt-get -y --purge remove $HEADERPACKAGES oh my [18:26] so many hacks [18:58] sigh, rootstock is so time consuming