**** BEGIN LOGGING AT Tue Aug 10 02:59:58 2010 Aug 10 06:58:59 rcn-ee: Are you here/ Aug 10 06:59:13 cooloney: Morning Aug 10 07:12:23 lag: morning, man Aug 10 07:12:30 you are very early Aug 10 07:13:04 I'm always here 0700-30 Aug 10 07:13:39 cooloney: bug 612895 Aug 10 07:13:41 Launchpad bug 612895 in linux-ti-omap4 (Ubuntu) "Unable to handle kernel NULL pointer dereference at virtual address 00000000 (affects: 1) (heat: 1674)" [Undecided,Confirmed] https://launchpad.net/bugs/612895 Aug 10 07:13:49 And the kernel you asked me to test Aug 10 07:13:55 Where did you get the _fix_? Aug 10 07:14:38 lag: i saw you are trying 902 kernel. and we just upgraded to latest TI release Aug 10 07:14:45 lag: maybe you can try that Aug 10 07:15:05 lag: the latest TI release fixed one swap oops Aug 10 07:15:37 ndec: morning Aug 10 07:16:49 cooloney: morning. Aug 10 07:20:13 ndec: Morning :) Aug 10 07:20:18 cooloney: When did you update? Aug 10 07:20:28 lag: morning! Aug 10 07:21:38 lag: tim pull it last week. it is 2.6.34 based release Aug 10 07:21:42 not 2.6.35 Aug 10 07:23:46 morning Aug 10 07:39:44 hrw: hi Aug 10 07:40:00 hrw: where do you keep your compilers packaging Aug 10 07:45:23 zumbi: 2 places Aug 10 07:45:34 1. http://people.canonical.com/~hrw/ubuntu-maverick-armel-cross-compilers/ Aug 10 07:45:50 2. https://edge.launchpad.net/~hrw/+archive/arm-cross-compiler Aug 10 07:46:01 1st has cross compiler packages Aug 10 07:46:19 2nd has my work on binutils/eglibc/gcc and related packages Aug 10 07:46:47 hrw: should we try to sync on getting this into Debian together? Aug 10 07:47:11 (or you might not care on Debian?) Aug 10 07:48:22 zumbi: all my work is first in Debian ;d Aug 10 07:48:35 while most of the work is fine, I have some suggestions on the packaging Aug 10 07:48:37 zumbi: zless /usr/share/doc/gcc-4.4/changelog.Debian.gz please Aug 10 07:49:01 zumbi: I am listening Aug 10 07:49:05 hrw: yes, i saw that changelog, but i do not see it on linux, nor eglibc Aug 10 07:49:28 linux in Debian is other recipe then in Ubuntu... Aug 10 07:50:31 zumbi: I need: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=commit;h=b4f64f3350b628323e39f69b416523f60c7f11f2 http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=commit;h=b4c776c2bc2c183fe13d3ed5f23e00fd9cb62a1d in kernel source package Aug 10 07:50:38 hrw: while one package for cross compiler (armel-cross-toolchain) could be fine. I would suggest to do some package split for building reuse Aug 10 07:51:29 hrw: I have some dependency graph which might clarify package dependencies a little Aug 10 07:51:35 ok Aug 10 07:53:38 hrw: I need some time to build an image of the dependency graph (source at: http://emdebian.org/git/?p=talks/emdebian.git;a=blob;f=pkgdeps.dot;h=9380b2fb14c6ffb6ecb66c05bc71cb375098531f;hb=HEAD ) Aug 10 07:53:59 hrw: I'll ping you back once i get a better looking file Aug 10 07:54:08 ok Aug 10 07:55:16 what you use to visualize it? Aug 10 07:56:13 dotty Aug 10 07:56:42 dot -Tdot pkgdeps.dot | gvpr -c '' | dot -Tpdf -o pkgdeps.pdf Aug 10 07:57:00 brb Aug 10 07:57:03 thx Aug 10 07:57:48 hrw: So you're essentially building a package which takes as input *-source, and outputs all the cross-toolchain .debs; I think zumbi is looking for some modularity, such as building binutils separately, or not rebuilding all stages; I don't think all the modularity is easy, so let's shoot at completing a cross toolchain first, and then we will make it more modular Aug 10 07:58:19 My understanding of zumbi's main concern is the time it would take to build the whole bootstraped toolchain Aug 10 07:58:38 I personally think this is ok, but I understand why he would like to skip some stages / packages in Debian Aug 10 07:58:39 56 minutes on my core2quad Aug 10 07:59:00 sweet Aug 10 07:59:25 zumbi: your graph has a bug. 1st stage of gcc do not need eglibc Aug 10 07:59:40 zumbi: and do not need linux headers - thats what eglibc wants Aug 10 08:04:50 back Aug 10 08:05:31 hrw: the most important think i wanted to show you from the graph is capability to rebuild non default compilers Aug 10 08:06:00 hrw: so if default is 4.4, you could reuse all libs to rebuild 4.3, 4.5, .. Aug 10 08:06:03 zumbi: take my armel-cross-toolchain source package, change component inside, build Aug 10 08:06:22 version of gcc inside is set by VER_GCC variable Aug 10 08:06:36 4.4 and 4.5 should work Aug 10 08:06:54 hrw: ok - i'll do Aug 10 08:06:58 4.3 is not present in ubuntu so I did not changed it Aug 10 08:07:21 if you want to use <4.4 then you will need to merge changes from 4.4 Aug 10 08:07:33 and there are still lot of changes which I need to merge Aug 10 08:07:40 hrw: but you no need to rebuild everything for both compilers (that was my suggestion) :) Aug 10 08:10:26 phone... Aug 10 08:11:28 zumbi: Yes, in general, the structure of cross-compiler packages is not perfectly defined Aug 10 08:11:42 zumbi: for instance, which package should provide $triplet-gcc? Aug 10 08:12:03 zumbi: My take on this is that there are two types of users: a) people who want to quickly build a standalone cross-toolchain Aug 10 08:12:21 and b) people who want to build cross compiler packages which match as much as possible the native toolchain Aug 10 08:13:19 for the later case, I think we need to output -gcc-4.5, -gcc-4.4 and -gcc files, and that should be the default; for the former I think we should add a flag to the gcc cross-build to allow building a standalone package Aug 10 08:13:35 lool: and c) people wanting to just intall the binaries :) Aug 10 08:13:56 zumbi: I'm not sure what you mean Aug 10 08:14:34 I think the in-archive packages should be of type b), but they will be of type a) in the beginning Aug 10 08:14:51 lool: right Aug 10 08:15:24 lool: sounds fine Aug 10 08:19:00 I think that we try to make a) == b) Aug 10 08:19:23 at least thats my goal with ubuntu packages Aug 10 08:20:06 hrw: Hmm, I'm not sure it's possible Aug 10 08:20:15 hrw: Consider that gcc comes from gcc-defaults right now Aug 10 08:20:44 hrw: And that people might want to build a standalone cross-toolchain which ships $triplet-gcc, even if it's not the gcc-4.x they build from is not the default Aug 10 08:23:15 my wife is refuelling our car for first time so I am remote helpdesk Aug 10 08:24:16 lool: current ubuntu cross gcc packages (4.4 4.5) ships $triplet-gcc-VER + u-a stuff to make it $triplet-gcc (gcc/cpp/gcov/g++ etc) Aug 10 09:00:03 hrw: yeah, alternatives suck though :-/ but it's good to have that in place at least Aug 10 09:01:38 speaking of cross-gcc-defaults package... I looked at gcc-defaults one and I think that will make new one based on it instead of adding cross support to this one. Aug 10 09:12:27 armel-cross-toolchain 1.7 builds now. will fail anyway Aug 10 09:22:01 1.8 on a way Aug 10 11:44:46 lag pong Aug 10 11:45:42 Hi Robert Aug 10 11:46:09 Your patch for ro Aug 10 11:46:13 how's it going lee.. Aug 10 11:46:20 Are you going to push it upstream? Aug 10 11:46:23 Good thanks :) Aug 10 11:47:38 for the xm, when the hardware is released, i'll send it to linux-omap, it'll probally get tweaked.. Aug 10 11:50:15 rcn-ee: Why don't you throw it up there now? Aug 10 11:52:56 i don't really have a good excuse. ;) Aug 10 11:54:04 The boards don't work without it Aug 10 11:54:08 Is that good enough? ;) Aug 10 11:56:52 i'll run it thru the patch checker script, and sent it to linux-omap, one more thing enabled for the xm.. Aug 10 11:58:56 \o/ Aug 10 11:59:16 * ogra sighs about oem-config Aug 10 12:00:05 i also just stopwatched the resizing ... 2:30 for two boots and the whole resizing process on a 4G card Aug 10 12:00:24 (each boot takes 35sec for u-boot until the kernel comes up) Aug 10 12:00:46 amitk, do you still think thats to slow ? :) Aug 10 12:01:22 2h30m? Aug 10 12:01:29 2min 30sec :) Aug 10 12:01:47 of which 1min 1sec are simply u-boot stuff Aug 10 12:01:50 err Aug 10 12:01:52 10sec Aug 10 12:02:01 ogra: and how much from first start to final desktop? Aug 10 12:02:29 hrw, no idea, thats from pushing in the power plug to oem-config Aug 10 12:02:56 35 seconds for u-boot? you could cut the u-boot wait variable.. ;) Aug 10 12:03:19 oem-config etc took ages last time Aug 10 12:03:19 answering the oem-config questions will likely take another 2-3min (depending how fast you type and click) plus package removal time which i couldnt stopwatch yet Aug 10 12:03:23 ogra: no, it is loooking _much_ better. Congratulations :) Aug 10 12:03:37 note that i'm talking about omap4 here Aug 10 12:04:01 i dont test on the C4 anymore and XM is currently broken kernel wise Aug 10 12:04:57 on Cx you have to multiply by 10 Aug 10 12:05:12 still pretty quick, is your u-boot for the omap4 like the omap3, where it has a 10 second wait at boot? Aug 10 12:05:13 ogra: I know you cheated :-p But it is still a lot better than the 1.5hr installs Aug 10 12:05:23 hrw, well, if we get the XM working i wont recommend the images for Cx installations Aug 10 12:05:41 ogra: so far I am stick with C3s anyway Aug 10 12:05:47 its simply not up to par with the minimal requirements Aug 10 12:06:16 btw - how often does ubuntu devs reboot their 'desktops'? Aug 10 12:06:30 sweet, looks like a real patch for 588243 just it linux-omap.. Aug 10 12:06:34 after update-manager forced me to Aug 10 12:07:07 ogra: I am ~5 kernels behind current Aug 10 12:07:18 bad hrw Aug 10 12:07:22 yeah Aug 10 12:07:31 you should listen to your update-manager :) Aug 10 12:07:43 ogra: aptitude do not said anything ;D Aug 10 12:07:49 shudder Aug 10 12:07:54 dont use aptitude Aug 10 12:08:02 hrw: aptitude is not recommended by our update guys Aug 10 12:08:12 so what :D Aug 10 12:08:20 it resolves dependencies in a different (unsupported) way Aug 10 12:08:26 I cant stand other apt utils then aptitude and apt-get Aug 10 12:08:51 hrw, do-release-upgrade is what you want if you are a cmdline guy Aug 10 12:08:57 if it require me to use mouse then it is not good Aug 10 12:09:15 13:56 hrw@home:debian$ sudo do-release-upgrade Aug 10 12:09:17 [sudo] password for hrw: Aug 10 12:09:17 Checking for a new ubuntu release Aug 10 12:09:17 No new release found Aug 10 12:09:18 its the equivalent to update-manager Aug 10 12:09:41 what are you running ? lucid or maverick ? Aug 10 12:09:55 maverick since uds Aug 10 12:10:01 ah, that might be different Aug 10 12:10:13 * ogra doesnt run maverick on his main machine Aug 10 12:10:27 what's wrong with 'sudo apt-get update; sudo apt-get dist-upgrade -V' Aug 10 12:10:34 nothing Aug 10 12:10:43 amitk: aptitude logs what I isntalled etc Aug 10 12:10:52 hrw, apt too Aug 10 12:11:04 ogra: it did not when I started using aptitude Aug 10 12:11:19 hrw: /var/log/apt/ Aug 10 12:11:22 aptitude also shows what new, what local/obsolete etc Aug 10 12:11:42 apt-get autoremove :P Aug 10 12:12:00 I used console-apt and few other ncurses/slang frontends in past Aug 10 12:12:20 ah, you need a gui ? Aug 10 12:12:21 well Aug 10 12:12:47 ogra: that does not tell that libdvdcss2 is from outside of ubuntu Aug 10 12:13:06 or that binutils-arm-linux-gnueabi is also not ubuntu package Aug 10 12:14:05 why didnt you use the one inside of ubuntu ? Aug 10 12:14:44 (for DVD playback, use libdvdread4 and run /usr/share/doc/libdvdread4/install-css.sh ) Aug 10 12:15:10 do not remember now Aug 10 12:15:55 ogra: that script does same as I did - fetch pacakge and install Aug 10 12:16:09 yeah Aug 10 12:16:12 likely Aug 10 12:16:37 but I play one dvd per year so... Aug 10 12:17:02 * amitk doesn't even have a laptop with dvd drive any more Aug 10 12:17:11 did I said laptop? Aug 10 12:17:18 mine annoyingly has one Aug 10 12:17:19 I never owned laptop with drive Aug 10 12:17:50 (with an eject button you always hit if you lift it) Aug 10 12:18:24 ogra: remove it from case? Aug 10 12:18:35 then i have an open hole in my lappie Aug 10 12:18:56 the drive is customized to the case Aug 10 12:19:11 and i have no placeholder or something to put into the empty slot Aug 10 12:19:11 so nothing other can fit? Aug 10 12:19:53 i guess when the laptop was recent you could buy dummies to put into the slotr Aug 10 12:20:15 but thats 2.5 years ago and the model isnt produced anymore Aug 10 12:25:26 rcn-ee: Sounds good (I saw that your tabs are out, besides that it looked okay) Aug 10 12:28:32 yeah, noticed that when i added the patch to the lp bug.. (crap wrong tabs..) btw, i think this fixes lp bug 588243 http://www.spinics.net/lists/linux-omap/msg34582.html going to test it this morning.. Aug 10 12:28:34 Launchpad bug 588243 in linux-ti-omap (Ubuntu) (and 1 other project) "kernel BUG at /build/buildd/linux-ti-omap-2.6.33/drivers/video/omap2/dss/core.c:323! (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/588243 Aug 10 12:37:18 rcn-ee: That's a lot of extra code Aug 10 12:37:20 :) Aug 10 12:37:35 I'm sure cooloney will be glad to hear of it Aug 10 12:39:14 rcn-ee: I'm commented on the bug with your information Aug 10 12:54:08 ogra: Around? Aug 10 12:54:24 ogra: Do you remember that discussion about changing the image generatin to output fat32 specifically? Aug 10 12:58:16 lool, yes, i changed it for you back then, does it work now ? Aug 10 12:58:22 No Aug 10 12:58:26 That's why I'm around Aug 10 12:58:31 iirc we still have a bug open thats pending confirmation Aug 10 12:58:46 One thing I noticed, and I had mentioned on IRC, is that the number of heads is non-default when I regenerate it here Aug 10 12:59:14 "regenerate" ? Aug 10 12:59:24 ogra: If you sudo losetup -fv maverick-preinstalled-netbook-armel+omap.img, then sudo kpartx -av /dev/loop0, then compare: sudo fdisk -l /dev/loop0 Aug 10 12:59:31 and sudo file -s /dev/mapper/loop0p1 Aug 10 12:59:38 you'll see that they don't have the same number of heads Aug 10 13:00:20 yep, confirmed, that fixed it for me Aug 10 13:00:24 the CHS geometry is indeed adjusted to the image size, i havent seen any issues with dd'ed images Aug 10 13:01:16 ogra: So if you check the number of heads in the FS, it says 64; if I regenerate the fs, copying back the same files in, it generates a FS with 255 heads here, and it boots in QEMU Aug 10 13:02:05 (now it doesn't work because I get no keyboard and no /dev/mmcblk0p2, but still it will boot into the initramfs!) Aug 10 13:02:20 { Aug 10 13:02:20 echo ,9,0x0C,* Aug 10 13:02:20 echo ,,,- Aug 10 13:02:20 } | sfdisk -D -H 255 -S 63 -C $CYLINDERS $IMAGE >/dev/null 2>&1 Aug 10 13:02:39 thats the code from the debian-cd script (which originally comes from angstrom) Aug 10 13:02:56 this isn't the problem Aug 10 13:03:14 but that defines the sectors Aug 10 13:03:28 I'm speaking of the heads in the *filesystem* Aug 10 13:03:35 err, heads indeed Aug 10 13:04:20 mkdosfs -F 32 -C $IMAGE.vfat ${VATSIZE} >/dev/null 2>&1 Aug 10 13:04:37 thats the filesystem creation, with -F32 added as you requested Aug 10 13:04:53 could it be that our mkdosfs on antimony is to outdated ? Aug 10 13:05:25 Maybe, but looking at the code, I rather think that it's because I'm running it on a different device that I get different results Aug 10 13:05:51 Current images: /dev/mapper/loop0p1: x86 boot sector, mkdosfs boot message display, code offset 0x58, OEM-ID " mkdosfs", Media descriptor 0xf8, heads 64, sectors 144522 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 1112, serial number 0x4c5f659b, label: " " Aug 10 13:05:55 that might be, i get proper partition tables and filesystems if i use it from SD card Aug 10 13:06:22 after mkdosfs on a loop device: Aug 10 13:06:22 /dev/mapper/loop0p1: x86 boot sector, mkdosfs boot message display, code offset 0x58, OEM-ID " mkdosfs", Media descriptor 0xf8, heads 255, sectors 144522 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 1112, serial number 0xcafca2f1, label: " " Aug 10 13:06:58 weird Aug 10 13:08:43 >-------printf ("unable to get drive geometry, using default 255/63\n"); bs.secs_track = CT_LE_W(63); bs.heads = CT_LE_W(255); Aug 10 13:10:01 interestingly, it tries to default to 64 heads on loop devices, but fails to detect my device as a loop device Aug 10 13:10:54 kernel issue ? Aug 10 13:11:56 ogra: Well it's just that it checks for loop major device (7), but I'm using a mapper device (major 252) Aug 10 13:12:21 ah Aug 10 13:12:40 but could that in any way affect your qemu boots ? Aug 10 13:12:44 252 actually means "local/experimental use" Aug 10 13:12:45 i doubt it Aug 10 13:12:58 qemu apparently reads the number of heads from the FS Aug 10 13:13:05 and refuses to boot with heads == 64 Aug 10 13:13:13 hmm Aug 10 13:13:34 I need to say that the partition table actually says 255, so QEMU has a point in not booting :-) Aug 10 13:13:53 but the 255 is needed for real HW :) Aug 10 13:14:12 the 255 is fine Aug 10 13:14:16 the bogus part is the 64 heads in the FS Aug 10 13:14:17 255/63 is a requirement, else x-loader wont work Aug 10 13:14:46 Err which 63 is that? Aug 10 13:15:06 sectors Aug 10 13:15:13 I'm only speaking of heads here Aug 10 13:15:14 the DOS standards Aug 10 13:15:24 sectors don't matter really Aug 10 13:15:30 (here) Aug 10 13:18:26 not here but for the actual images, the partitioning needs to be that way, i dont know how i would change the amount of heads the filesystem uses though, seems mkdosfs has no option for that Aug 10 13:18:57 so it's a set of mkdosfs bugs, but not fun to fix Aug 10 13:19:45 ogra: it's because mkdosfs has a different code path for files and for devices Aug 10 13:20:19 for files, it checks the size and defaults to 32 sectors and 64 heads Aug 10 13:21:15 for unknown devices, it assumes hard disk and checks the geometry, but fails and so uses 63 sectors per track and 255 heads Aug 10 13:22:15 meh Aug 10 13:23:54 lool, i'm planning to provide a script that loop mounts and reformats the vfat for bootloader changes on existing images, we could have some workaround in there that makes it work for you too Aug 10 13:24:18 (we want to provide the same image for blaze and panda but that requires different x-loader and u-boot) Aug 10 13:25:01 ogra: i'd rather fix mkdosfs Aug 10 13:25:35 lool, in hardy ? Aug 10 13:25:48 dont forget antimony is hardy Aug 10 13:29:03 ogra: Well we can certainly prepare a special fixed package to install there Aug 10 13:29:15 indeed Aug 10 15:03:48 ogra: If I want to test my bespoke kernels with the daily image - what's the easiest way? Aug 10 15:16:16 ogra: Hmm it's more complex than I thought Aug 10 15:16:26 LP #615873 Aug 10 15:16:27 Launchpad bug 615873 in dosfstools (Ubuntu) "Doesn't allow forcing file systems to 255 heads (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/615873 Aug 10 15:31:04 someone remember how to tell "dch" to not use "ubuntu1" but bump version? Aug 10 15:32:30 hrw: Bump to what? Aug 10 15:32:51 hrw: You can -i to force a version increment, or -a to force not touching the version; you can -v to set the version Aug 10 15:33:17 lag: what platform do you want to test on? Aug 10 15:33:25 Arm Aug 10 15:33:40 Duh. Aug 10 15:33:50 Little more specific. Aug 10 15:33:51 OMAP3+4 Aug 10 15:34:38 If you want to test on Beagle & Panda, probably easiest to use the Alpha 3 image and install kernel after the image expands and oem-config runs. Aug 10 15:35:01 If you want to test on XM, boot an image on beagle first, then install new kernel. Aug 10 15:35:34 Not sure if you can just put the uImage on the image w/o updating uInitrd. Aug 10 15:35:40 Hmm Aug 10 15:35:44 You can't Aug 10 15:35:53 depmod not found Aug 10 15:36:33 So, let them come up and install kernel.deb after? Aug 10 15:36:50 That would be easiest. Aug 10 15:36:52 alpha3 has problems still on my XM Aug 10 15:37:04 yes, I know. Aug 10 15:37:40 The other possible way is to generate an image with rootstock, but I don't know how well that works. Aug 10 15:37:55 lool: yes, but -i bumps from 1.10 to 1.10ubuntu1 when I want 1.11 Aug 10 15:38:27 yep, with rootstock you can give the kernel image to be used while creating the rootfs Aug 10 15:39:52 rsalveti: But I want to test it with the daily build Aug 10 15:40:02 rsalveti: i.e. the daily build's rootfs Aug 10 15:40:04 GrueMaster: lag: another way is to copy qemu-arm-static to /usr/bin and run chroot Aug 10 15:40:11 after that you're able to install normally Aug 10 15:40:17 hrw: --distributor Debian? Aug 10 15:41:06 lag: well, the advantage of using rootstock is that you can test another kernel easily, without having to wait the daily rootfs to be created Aug 10 15:41:34 lool: ok, thx Aug 10 15:41:47 rsalveti: I have kernels that I know work with rootfs, but they don't when they're used with the daily build Aug 10 15:42:01 rsalveti: I need to test them with the daily build's rootfs Aug 10 15:47:11 lag: so, installing the new kernel deb with chroot is how I'd recommend you to do it Aug 10 15:47:18 if you don't have access to the machine running your rootfs Aug 10 15:47:37 but then you need to create and copy uI* files Aug 10 15:49:03 Does the daily build's rootfs have update-initramfs? Aug 10 15:49:17 And mkimage? Aug 10 15:49:31 GrueMaster can easily check Aug 10 15:55:40 yes, they do. Sorry, had to step out for a bit. Aug 10 15:56:29 lag, create a package, dpkg -i it Aug 10 15:57:15 lool, well, my offer still stands, i can add a special mode to the script Aug 10 15:57:21 But that's saying I have a running system Aug 10 15:57:58 ogra: XM is borked Aug 10 15:58:03 lag, yeah Aug 10 15:58:24 How how can I dpkg -i on the XM? Aug 10 15:58:26 lag, another way is to dpkg -i your package in a chroot and just use mkimage on the files Aug 10 15:58:38 and then replace them on the SD Aug 10 15:58:44 Yeah, that's whay rsalveti said Aug 10 15:59:03 ogra: It looks like we're creating a broken vfat Aug 10 15:59:10 thats what i do for jasper development Aug 10 15:59:10 I'm worried about mtools_skip_check=1 Aug 10 16:00:21 lool, iirc we a) use that elsewhere too in debian-cd, b) as long as the bootloader likes it i'm fine, we repartition and recreate the vfat on first boot anyway Aug 10 16:01:13 lool, seems the only thing that doesnt cope with our images is qemu here Aug 10 16:05:06 ogra: Can I just update-initramfs in a chroot and use the uInitrd and uImage files? Aug 10 16:05:25 lag, you need the mkimage calls too Aug 10 16:05:28 but yes Aug 10 16:05:42 What do I need to do with the rootfs? Aug 10 16:05:50 nothing Aug 10 16:05:51 Just copy the modules into /lib/modules? Aug 10 16:06:05 lag: yep Aug 10 16:06:09 just dpkg -i your package or create the modules dior manually Aug 10 16:06:15 lag: the packages just installs the modules Aug 10 16:06:36 then depending on your changes you need to generate the initrd.img again Aug 10 16:06:54 then create the uI* files and rock on Aug 10 16:07:24 Why do I need to make them twice? Aug 10 16:07:33 Compile kernel Aug 10 16:07:37 Make uImage Aug 10 16:07:47 Make uInitrd.img Aug 10 16:07:54 Make uInitrd Aug 10 16:07:57 Copy to rootfs Aug 10 16:08:04 Copy modules to /lib/modules Aug 10 16:08:06 Done Aug 10 16:08:07 lag, just roll your kernel inside that chroot :) Aug 10 16:08:07 ? Aug 10 16:08:13 I do Aug 10 16:08:18 mak install will put the modules in place Aug 10 16:08:21 *make Aug 10 16:08:31 I don't do make install Aug 10 16:08:44 I have to do it manually Aug 10 16:08:46 well, make modules_install Aug 10 16:08:50 Nope Aug 10 16:09:04 I build on a different machine Aug 10 16:09:24 well, have an armel chroot there you can build in Aug 10 16:09:35 I do Aug 10 16:09:39 wrap a script around it that spits our uImage/uInitrd Aug 10 16:09:43 *out Aug 10 16:09:46 * cpearson wonders if there are any Canonical guys at LinuxCon? Need someone to drink beer with tonight :) Aug 10 16:10:13 cpearson, mdz i think and kees Aug 10 16:10:38 ogra: ping me with real names if you could Aug 10 16:10:39 cpearson, what happened to the photo from prague btw ? Aug 10 16:10:54 cpearson, matt zimmerman and kees cook Aug 10 16:10:59 http://ufgeek.wordpress.com/ Aug 10 16:11:00 (no secret :) ) Aug 10 16:11:10 awesome ! Aug 10 16:11:39 * cpearson does not have magic decoder ring for IRC nick to names :) Aug 10 16:11:41 ogra: thanks Aug 10 16:11:42 lag: don't you need to generate the initrd.img first before creating the uIinitrd? Aug 10 16:11:55 you said make uInitrd.img Aug 10 16:12:10 cpearson: you clearly need to eat more geek flakes Aug 10 16:12:42 the marketing gig is making me soft Aug 10 16:14:16 rsalveti: Don't you use update-initramfs to make uInitrd.img? Aug 10 16:15:43 lag: yep, but I create the *initrd.img* file, not uInitrd.img Aug 10 16:16:01 http://ufgeek.wordpress.com/ - WTF! Aug 10 16:16:04 I have a stalker Aug 10 16:17:21 lag: damnit now you found me, I have to move to the other set of bushes outside your house Aug 10 16:18:22 ogra: cpearson: http://people.canonical.com/~ljones/lastsupper/ Aug 10 16:18:52 rsalveti: Picky! Aug 10 16:19:02 rsalveti: But you get the idea Aug 10 16:19:28 lag: yep, but the *u* on it means that you don't need to run mkimage :P Aug 10 16:19:52 ogra was confused... we had been drinking Aug 10 16:20:00 heh Aug 10 16:20:01 and there was schnitzel Aug 10 16:20:11 * ogra had duck though Aug 10 16:20:17 and an accordion Aug 10 16:20:20 possibly a mad duck :) Aug 10 16:20:39 I'm sure we was briefly pissed... then they took his head off Aug 10 16:20:50 What was the lexicographic revelation? My spelling mistak? Aug 10 16:20:52 ;) Aug 10 16:22:26 cpearson: ? Aug 10 16:28:22 lag: the meaning of the middle F Aug 10 16:28:50 * cpearson looks at the #linux-omap channel... man there are some strange people in there :) Aug 10 16:30:27 And we're not strange? I'm offended. :P Aug 10 18:01:35 XorA|gone: regarding the texture from pixmap stuff, check https://wiki.linaro.org/Platform/UserPlatforms/2010-08-10 and http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg11616.html to see how linaro and mesa guys are working with it Aug 10 18:01:57 if you didn't read this already :-) Aug 10 18:02:49 XorA|gone: alf__ and asac are working to understand if it's really needed to get this proprietary extension implemented on the driver side Aug 10 18:03:28 or if it should just follow the common extensions like mesa guys are doing Aug 10 18:22:19 rsalveti: email me rather than talk here, Ill lose these logs before I get to read them Aug 10 18:23:04 XorA|gone: your email? Aug 10 18:23:14 gg@slimlogic.co.uk Aug 10 18:23:20 k Aug 10 23:35:52 hello room Aug 10 23:36:19 has anyone had any success getting ubuntu 10.04 or 10.10 working on a Keil Versatile Express development board? Aug 10 23:36:44 What processor does that use? Aug 10 23:36:47 I think the problem I'm having is the kernel has an incompatible config Aug 10 23:36:53 A9x4 Aug 10 23:37:00 ? Aug 10 23:37:08 4 core A9 Aug 10 23:37:13 ework: i have been able to boot a kernel on that system Aug 10 23:37:13 oh. Aug 10 23:37:52 I have been able to boot generic debian lenny using debootstrap and the stock kernel from ARM (kernel-2.6.33-arm1) Aug 10 23:38:12 ework: do you want me to send you the .config i've been using? Aug 10 23:40:34 when booting a rootfs built using rootstock it just hangs after a number of errors about plymouth Aug 10 23:40:35 but its still detecting my usb keyboard being plugged in and unplugged Aug 10 23:40:35 I had to add support for DEVTMPFS in my kernel to get past some of the initial errors Aug 10 23:40:35 mattman, what kernel were you using? was is something derived from the ubuntu kernel? Aug 10 23:41:47 ework: 2.6.35-rc5. Aug 10 23:41:53 mattman, that would be really great Aug 10 23:42:02 thats a maverik kernel correct? Aug 10 23:42:15 ework: just a sec working on getting it into pastebin Aug 10 23:43:09 mattman, where is the best place to get the patched ubuntu kernel source so that I can apply this patch against Aug 10 23:43:32 mattman, did you just do a standard "make uImage" after patching it? Aug 10 23:44:59 ework: i haven't patched the kernel. i'm pretty sure this is just a snapshot of the arm-next kernel tree. Aug 10 23:46:30 mattman, whats the best way to cross compile the kernel. Sorry I'm just getting started with this stuff. I've built the kernel a number of times using the standard ubuntu way to a .deb file, but not cross-compiled a kernel from a ubuntu source package. Aug 10 23:47:02 ework: can you see the arm-next kernel at http://git.linaro.org/gitweb? Aug 10 23:47:03 mattman, I also have no problem compiling a kernel from vanilla source, which is how I get the 2.6.33-arm1 kernel I have now Aug 10 23:47:33 ok I think I can figure it out from that git source Aug 10 23:47:56 mattman, did you make this config yourself or is it based on some source Aug 10 23:48:02 ework: ok let me pastebin a link to the .config I'm using Aug 10 23:48:08 mattman, sorry for all the questions I'll slow down Aug 10 23:48:09 ework: yes Aug 10 23:50:20 ework: here's the .config i'm using: http://pastebin.com/D8fUQ1bK Aug 10 23:51:14 ework: i created this by using an older .config and just manually enabling the same devices. Aug 10 23:52:12 mattman, so you were able to boot some form of ubuntu on the versatile express correct? Aug 10 23:52:21 using this kernel and rootstock? Aug 10 23:53:05 ework: yes right now I booted a minimal rootfs then apt-get the rest. Aug 10 23:53:20 mattman, sounds good that was my plan as well Aug 10 23:53:34 let me send you a link to some wiki instructions i put togther. Aug 10 23:57:08 ework: https://wiki.linaro.org/Boards/Vexpress - actually after looking at the instructions again, they are good for when you already have built images. i need to spend more time explaining how i built the images Aug 10 23:57:55 mattman, thank you for all the help you have no idea how much time I've spent spinning my wheels trying to debug why it doesn't boot Aug 10 23:58:34 mattman, I can add some information tho this wiki as I go through the process if that helps Aug 10 23:59:08 looks like I just need a launch pad account which is not a problem Aug 10 23:59:58 ework: good to know. i wondered if the instructions were visible. Aug 11 00:00:00 mattman, btw one other boot option is usb which is what I've been using without problems Aug 11 00:00:39 ework: that's good to know also. i would like to add any information you'd like to share to the document. Aug 11 00:01:15 mattman, I should be able to add information myself if I have a launchpad.net account? Aug 11 00:01:22 ework: true Aug 11 00:01:42 ework: that's even a better ides ;-) Aug 11 00:02:11 mattman, oh you have usb hard drive already at the bottom Aug 11 00:03:41 mattman, this looks similar to whats on the quickstart card. I think you might even want a separate page for building the kernel and rootfs Aug 11 00:04:43 ework: right, seems obvious now that i look at it again. Aug 11 00:05:28 mattman, well its kind of obvious now but it took me a while to understand it to the level documented there Aug 11 00:09:18 mattman, I didn't even know you could boot the kernel off SD or CF I was always updating the flash each time Aug 11 00:09:54 ework: that's pretty nice if you have an SD card reader on your laptop. Aug 11 00:10:26 yah I have the board next to my laptop and can just unplug it and take the card out and put it into a MicroSD to SD adapter Aug 11 00:10:47 copy it over and reboot and it updates the flash Aug 11 00:11:52 ework: just one more item that might help. i don't remember exactly where my minimal rootfs came from, but i think http://releases.linaro.org/platform/linaro-m/headless/alpha-3/linaro-m-headless-tar-20100803-0.tar.gz may work. Aug 11 00:12:15 mattman, this wiki page is very useful but I agree it needs to complimented with instructions for building rootfs and kernel Aug 11 00:12:40 mattman, the minimal rootfs is pretty easy to get using rootstock Aug 11 00:14:02 ework: thanks for the feedback on the wiki page. Aug 11 00:14:08 mattman, maybe it had some incompatibilities which is why I ran into problems Aug 11 00:38:50 ericm|ubuntu: ping? **** ENDING LOGGING AT Wed Aug 11 02:59:57 2010