**** BEGIN LOGGING AT Mon Mar 22 03:00:02 2010 Mar 22 10:02:45 apw: Heya Mar 22 10:03:13 apw: On https://bugs.launchpad.net/ubuntu/+source/linux/+bug/524893 the config change can actually be reverted; it didn't help and wasn't actually needed once the fix was found Mar 22 10:03:19 Launchpad bug 524893 in qemu-kvm (Ubuntu Lucid) (and 3 other projects) "versatile: Can't boot initramfses (affects: 1)" [Low,Fix released] Mar 22 10:04:25 I also had in mind to kill the default cmdline from the config, it overrides the ATAG mem information and qemu-ssytem-arm uselessly defaults to 32MB of RAM Mar 22 10:04:49 (that is, passing -m foo to qemu-system-arm isn't enough, one has to pass mem=foo too) Mar 22 10:04:52 32MB!!!!! Mar 22 10:04:59 Yup Mar 22 10:05:06 triggers d-i "Low mem mode" Mar 22 10:05:16 persia: It's from the defconfig Mar 22 10:05:19 it's an old board Mar 22 10:09:10 right. Mar 22 10:17:51 apw: sent to the list Mar 22 10:18:33 persia: BTW did you get a chance to go over the /Ports page? Mar 22 10:18:43 persia: I'd like to hook it up from the /Development page now Mar 22 10:21:24 Unfortunately not. It was top-of-my-list for Saturday, until something else intervened. I'll look at it as soon as I've eaten. Mar 22 10:21:36 Ok thanks Mar 22 11:57:14 Are there any good reasons for me to up my host to Lucid to develop/build Luicid ARM targets (w/rootstock)? Mar 22 11:58:46 nosse1, depends if you also want to test x86 lucid. ;) otherwise karmic works fine, just use the bzr trunk of rootstock Mar 22 11:59:57 of course I want to test Lucid x86 as well... ;) Mar 22 12:00:20 rcn-ee: rootstock is one, script right? Not spread across several files? Mar 22 12:00:49 yeah, it's just a script that access qemu.. Mar 22 12:01:05 excellent. I think I got it then. Mar 22 12:01:23 Now I'm this close to attempt to run Lucid on TI AM3517 Zoom eval kit Mar 22 12:04:24 it should work as i run it on a varity of omap35x targets... just make sure you config meets these requirements http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/2.6-stable/annotate/head%3A/readme.txt Mar 22 12:06:32 rcn-ee: Have you deployed Ubuntu on any omap35x targets for production environments, or just still development? Mar 22 12:09:13 nah, i haven't pushed my customers off karmic yet, as lucid just hit beta-1 last week.. Mar 22 12:09:44 i have two internal development beagles running it 24/7 thou, testing different things.. Mar 22 13:07:30 Ush... ARM Lucid didn't work out-of the box... Well, I didn't really expect that either... Mar 22 13:08:51 works here :) Mar 22 13:09:31 It boots the kernel, and head into NFS, but then it just sits there after "init: ureadahead main process (552) terminated with status 5" Mar 22 13:09:46 ah, NFS Mar 22 13:10:02 there might be mountall bugs with NFS, check launchpad Mar 22 13:10:13 Are there any good tools for debugging nfs-links? i.e. smart cmd options for tcpdump Mar 22 13:10:28 I'd like to see what specific files are being accessed Mar 22 13:10:37 well, try to reach your server from the busybox shell in your initramfs etc Mar 22 13:11:09 thats why ubuntu uses initramfs all over the place ... makes debugging so easy :) Mar 22 13:11:48 hehe: That might just be it then. I tried without initramfs :o Mar 22 13:12:13 well, depending on your kernel it should work even without initramfs Mar 22 13:12:40 its years ago i used rootfs on NFS so i wont be a big help Mar 22 13:13:22 Because you dont really need the initramfs if everything is build statically in the kernel, right. Theres nothing special the distro requires? Mar 22 13:13:31 there is Mar 22 13:13:49 lost of packages place stuff inside the initramfs in ubuntu Mar 22 13:13:52 *lots Mar 22 13:14:13 How do you build one then? Mar 22 13:14:39 update-initramfs -c -k Mar 22 13:14:47 on a running system Mar 22 13:14:56 Thats assuming a running system, yes Mar 22 13:15:01 (prefix that with sudo) Mar 22 13:15:42 if you dont have a running system, take your sd make sure to have qemu-arm-static installed and run the command in a chroot on the SD Mar 22 13:15:54 (on your x86 system) Mar 22 13:16:50 * nosse1 noob, SD=? Mar 22 13:17:10 Sd card Mar 22 13:17:30 oh, you probably dont use one if you use NFS :) Mar 22 13:17:40 just chroot into your exported rootfs then Mar 22 13:17:42 Ah. So thats how you run instead of NFS? Mar 22 13:20:30 using an SD card, yes Mar 22 13:21:40 I recon, since you compile packages natively, moving files back and forth to x86 isn't made as often as you would on a purely crossed target Mar 22 13:21:55 ..so a SD card is fine Mar 22 13:22:05 right, i usually only use x86 for bringup and building a booting image Mar 22 13:23:23 i have to admit my other colleagues are sceptical to build the apps natively on a 500MHz ARM target Mar 22 13:24:13 well, if you use ubuntu as ubuntu developer you can just develop under x86 :) Mar 22 13:24:34 the packages are built automatically on all arches anyway Mar 22 13:25:03 yes, I see both advantages and disadvantages of doing it like this Mar 22 13:25:42 it really depends *what* kind of app you buiuld natively though Mar 22 13:26:09 I'm a little worried that vanilla ubuntu becomes too heavy for a small ARM target, yet it is nice to not have to worry about the system Mar 22 13:26:23 if its just a desktop app it surely is a lot easier to build it natively and have all dependencies already available Mar 22 13:26:34 well, define *small* Mar 22 13:26:41 The other alternative is some kind of LFS in a cross build environment Mar 22 13:26:52 Our product will have a sys-flash of 1G Mar 22 13:27:11 LFS cross building might gain you incompatible binaries Mar 22 13:27:43 1G flash isnt enough for any of the ubuntu desktops Mar 22 13:28:08 not sure about LXDE but even if that would fit it wouldnt leave you much space for user data Mar 22 13:29:20 Yes. Package and product upgrade feats of distro like Ubuntu is very tempting Mar 22 13:29:38 indeed Mar 22 13:29:58 No desktop (sort of). The product will be a end-user product where the user shall not know that Ubuntu is running behind the curtain Mar 22 13:30:14 But it will be a Qt app running either on X11 or directly to fbdev Mar 22 13:30:56 Size isn't that critical (shoult fit into 1G), but startup-time into final application is far more critical. Mar 22 13:30:59 well, if you only compile your app, i would go with natively ... Mar 22 13:31:33 whats the desired time you have ? Mar 22 13:31:43 and with which bootloader ? :) Mar 22 13:31:45 Q is then how much tweeking to Ubuntu is needed to make the app start fast enough Mar 22 13:31:55 TI uses U-boot Mar 22 13:32:07 which is a fairly slow thing in itself Mar 22 13:32:26 Lets say 10-30 secs is fine Mar 22 13:32:41 thats half of it for uboot Mar 22 13:32:50 Uboot will be optimized in order to speed things up Mar 22 13:33:02 thats the easy part Mar 22 13:33:03 if you only fire up your app 15sec should beeasily doable Mar 22 13:33:40 my laptop takes 8 from grub to gnome desktop atm ... Mar 22 13:34:07 Ah, but it's a laptop.. What are we talking about on your ARM targets? Mar 22 13:34:31 and that starts a lot more stuff, even though its x86 and 4G RAM and a fast SSD, 15sec for u-boot-end to app-on-screen will be achievable Mar 22 13:35:02 ARM targets are depending on the disk you run your system off Mar 22 13:35:06 mainly Mar 22 13:35:27 ubuntu-netbook on a babbage board takes from 35 to 45sec Mar 22 13:35:49 (thats imx51 from USB key or USB attached SATA disk) Mar 22 13:36:33 though imx51 loses nearly no time to the bootloader ... (6-10sec) Mar 22 13:36:57 redboot is a lot faster than u-boot ... but a lot less flexible Mar 22 13:37:11 BTW: Those ARM targets used in the Launchpad build farm, what kind of machine/specs are we talking about? Some of these compiles must take a while? Mar 22 13:37:14 (and very painful) Mar 22 13:37:38 the ARM buildds are all imx51 800MHz 512M machines Mar 22 13:37:46 Yeah, I know. I've been working with imx35 previously and thus redboot Mar 22 13:37:47 with USB disks Mar 22 15:01:09 lool: Regarding Development/Ports : there's a lot of TODOs left: are you sure you want to strong-link it already? Mar 22 15:01:32 Also, there are N ways to set up schroots: I'm unsure I want to document all of the manual methods (and they're all painful). Mar 22 15:01:34 persia`: We could hide them as comments Mar 22 15:01:48 Yeah, hiding them works. Mar 22 15:01:53 persia`: Well, I'd like to document how you use sbuild for arm development Mar 22 15:02:11 I can document use easily. Mar 22 15:02:20 For creation, I can't recommend mk-sbuild enough. Mar 22 15:02:37 persia`: hidden now Mar 22 15:02:51 persia`: Oh ok, I thought you tested mk-sbuild successfully? Mar 22 15:03:55 Sorry: translation error. I mean to say that not using mk-sbuild is so painful that there is no limit to the degree to which I will recommend it to any schroot/sbuild users Mar 22 15:04:16 persia`: Do you consider the sbuild section good enough? Mar 22 15:04:33 Basically, one has to create the (directory, tarball, LV snapshot, etc.) manually, and then stick it somewhere, and then write the configuration manually. Mar 22 15:04:50 I'll add in some notes on usage with schroot and sbuild. Mar 22 15:05:01 persia`: I'm not a regular sbuild user; I have it installed and now how it can overall work, albeit not the latest features thereof Mar 22 15:05:07 persia`: Ok good Mar 22 15:05:15 persia`: When you're done, just remove the commented-out TODO Mar 22 15:24:31 Where does rootstock stage its files? Mar 22 16:02:10 OK, sorry for my elementary questions: If I have a rootstock/qemu image either as .img or as tar.gz, how can I invoke qemu to boot from that image/root? Mar 22 16:02:49 I.e. I need a kernel and I need to make the kernel load the root from the image, I presume Mar 22 16:03:43 nosse1, see the rootfs from scratch wikipage (from the channel topic) Mar 22 16:05:12 ogra: embarrasing. Of course, thanks! Mar 22 16:09:10 lool: Sorry that took so long. Use of schroot/sbuild documented : please take a look to make sure it makes sense to you. Mar 22 16:15:24 persia`: Looks good Mar 22 16:15:58 lool: What I wonder is if we need to go to any more effort to make clear that these procedures (should) work for armel/powerpc/sparc Mar 22 16:16:08 (getting a little off-topic for this channel) Mar 22 16:16:37 I don't want to create the impression that one must use pbuilder for armel and sbuild for powerpc, nor the impression that this is armel only. Mar 22 16:16:38 persia`: Let's hope that the people reading it are technical enough to understand that, and fix it if we discover it's a problem Mar 22 16:16:47 That sounds reasonable :) Mar 22 16:17:06 I don't think it's off topic for this chan since we're trying to improve ports documentation as driven by the lack thereof for arm ;-) Mar 22 16:17:12 heh Mar 22 16:17:42 Do you happen to know if qemu-system-ppc needs as many special arguments as qemu-system-arm ? Mar 22 16:18:20 persia`: I happen not to know Mar 22 16:18:34 * persia` either Mar 22 16:18:48 Oh well, there's enough fast ppc HW out there that most folks use native anyway. Mar 22 16:18:52 ISTR seeing people run qemu-system-ppc without any -M arg, but I don't know what kernel's we're building for Mar 22 16:19:38 Wow powerpc has a vmlinux and armel a vmlinuz, how odd Mar 22 16:22:12 ogra: Now this is interesting. Earlier this day I failed getting lucid to run on target. Kernel booted, but failed in userspace. When I now start qemu, I get the same failure Mar 22 16:32:27 nosse1, whats the failure ? Mar 22 16:35:15 Hold on. I hoped I could get the console output with -nographic, but it only dumps the pre-linux bootloader Mar 22 16:39:48 nosse1: I often find "-monitor stdio" to be useful argument when I'm having issues, as this lets me manipulate the session in the terminal whilst it executes in the SDL environment. Mar 22 16:42:06 ogra: From the start of init, I see the following messages 1) modprobe: Could not load ...modules.dep 2) init: ureadahead main process (381) term. with status 5 3) mountall: Could not connect to Plymouth 4) Same as 1 again Mar 22 16:42:30 thats all fine Mar 22 16:42:40 nothing to worry about Mar 22 16:43:30 Then nothing. After a while I get sda sense key errors in qemu Mar 22 16:43:49 thats something to worry about :) Mar 22 16:44:03 This time I'm running from ext3 file-image Mar 22 16:44:38 how did you build your image ? just using rootstock --notarball ? Mar 22 16:44:44 Yup Mar 22 16:45:14 and then the commandline from the wiki ? Mar 22 16:45:23 with the kernel from there ? Mar 22 16:45:23 Hold on, I'm getting lots of errors on e2fsck of the image Mar 22 16:45:28 yes Mar 22 16:46:04 i dont see that here Mar 22 16:46:23 what was the exact commandline you used with rootstock ? Mar 22 16:46:41 Hoi.. Here I got a tracedump of something in the console Mar 22 16:46:55 I used "sudo ./rootstock --imagesize 1G --seed ubuntu-minimal --dist lucid --notarball" Mar 22 16:47:10 ah Mar 22 16:47:24 well, that will fire up oem-config Mar 22 16:47:26 rootstock is the patched one to be able to use my karmic against lucid Mar 22 16:47:35 which can take a few minutes to start Mar 22 16:47:46 persia`: Apparently, one needs to pass -M prep to qemu-system-ppc, and one needs a BIOS which we lack in Ubuntu; see https://bugs.launchpad.net/ubuntu/+source/openbios-sparc/+bug/183495 Mar 22 16:47:49 Launchpad bug 183495 in openbios-sparc (Ubuntu) "[FTBFS] openbios-sparc (1.0~alpha2+20070816-1) fails to build in hardy (affects: 3) (dups: 1)" [Medium,Confirmed] Mar 22 16:48:16 nosse1, if you want to prevent oem-config just use th e-l and -p options for rootstock Mar 22 16:48:21 *the -l Mar 22 16:48:48 persia`: surprisingly, the two files mentionned by https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/60478 are around on my system Mar 22 16:48:52 Launchpad bug 60478 in qemu (Debian) (and 1 other project) "Missing files for qemu-system-ppc (dup-of: 183495)" [Unknown,Fix released] Mar 22 16:48:54 Launchpad bug 183495 in openbios-sparc (Ubuntu) "[FTBFS] openbios-sparc (1.0~alpha2+20070816-1) fails to build in hardy (affects: 3) (dups: 1)" [Medium,Confirmed] Mar 22 16:49:49 ogra, thanks I'll try. My end objective is to get a working image for me to be able to use on target. Mar 22 16:49:58 lool: I have them both as well. Mar 22 16:50:27 nosse1, well, if you boot it on the target system, just wait a little longer, it will bring up oem-config after a while Mar 22 16:50:31 lool: I know far too much about the openhackware and openbiod-sparc issues. They aren't fixable with current Soyuz. Mar 22 16:50:40 to configure user, language, keymap etc Mar 22 16:51:10 W: u-boot-omap3 source: quilt-build-dep-but-no-series-file Mar 22 16:51:11 lool: OK, so qemu-system-foo really only works for armel right now. That makes it easy. Thanks for checking. Mar 22 16:51:14 hmm, is that new ? Mar 22 16:51:29 ogra: No. Mar 22 16:51:34 i never needed debian/patches/series before Mar 22 16:51:42 ogra, I have to admit I perhaps didn't wait long enough to determine whether the target was busy or dead. Mar 22 16:51:43 persia`, well, the complaint is Mar 22 16:51:44 quilt creates it automatically. Mar 22 16:51:53 No, it's been around since jaunty, at least. Mar 22 16:52:07 ogra, but the output was the same on targes as on qemu Mar 22 16:52:10 weird, i never saw that before when building a package and picking quilt Mar 22 16:52:31 nosse1, on qemu it will take even longer until oem-config comes up Mar 22 16:52:32 You probably never didn't have a series file before. Like I said, quilt does it automatically. Mar 22 16:53:38 ogra: I've found quilt incredibly easier to use since adding http://paste.ubuntu.com/399386/ as my ~/.quiltrc Mar 22 16:54:04 ah, thats nearly the same cjwatson gave me Mar 22 16:55:59 His was from /usr/share/doc/quit/README.source Mar 22 16:56:40 Which works exactly the same, only faster for 90% of cases. Mar 22 16:56:51 The kernels you build for target, do you cross compile them or do you also do that natively? Mar 22 16:57:22 nosse1, see /topic :) Mar 22 16:57:22 nosse1: Everything is natively compiled. Mar 22 16:57:59 bah, sigh ... series needs to contain a comment Mar 22 16:58:30 No it doesn't. Mar 22 16:58:50 What happens if I install gcc from my qemu. Will it be capable of generating code for real target? Mar 22 16:59:14 nosse1: As long as your target is compatible with the instruction set gcc is targeting, yes. Mar 22 16:59:15 persia`, diff.gz wont represent empty files Mar 22 16:59:36 so lintian still complains Mar 22 16:59:44 unless i add a comment or something Mar 22 16:59:45 ogra: series shouldn't be empty unless you have no patches, and if you have no patches, you shouldn't have a build-dep on quilt. Mar 22 17:00:12 persia`, i want the new packages i build to reflect a selection for the patchsystem Mar 22 17:00:29 so people touching the package know what to use Mar 22 17:00:40 ogra@babbage2:~/u-boot-omap3-2010.3git20100315$ lintian -i ../u-boot-omap3_2010.3git20100315-0ubuntu1_source.changes Mar 22 17:00:40 ogra@babbage2:~/u-boot-omap3-2010.3git20100315$ Mar 22 17:00:43 there we go :) Mar 22 17:00:47 Just use Format: 3.0 (quilt) then. No build depenency required. No debian/rules magic. Expresses the preference for quilt. Mar 22 17:00:49 * ogra builds a binary Mar 22 17:01:06 persia`, i wont revert what i did now :) Mar 22 17:01:25 * ogra has to get the thing done today Mar 22 17:01:30 anyway, you're supposed to express that preference in debian/README.source Mar 22 17:01:44 Just ask first next time :p Mar 22 17:02:14 expressing that preference in README.source doesnt quiet down lintian Mar 22 17:02:37 i want the package to be ready so people can just drop in diffs Mar 22 17:03:05 as i do with i.e. dpatch Mar 22 17:03:43 and given that asac perfers quilt and i get heat from people that i use dpatch everywhere i thought i should start switching to quilt Mar 22 17:03:50 even though i dont like it Mar 22 17:04:25 in any case i want my packages to be ready for patching right away, without having to fiddle with build-deps Mar 22 17:04:30 Fair enough. Next time you do a package, make me walk you through using format 3.0(quilt) so you have it easy. Mar 22 17:04:43 ok Mar 22 17:04:54 (which never requires build-dep on quilt and still uses quilt) Mar 22 17:10:35 ogra@babbage2:~/u-boot-omap3-2010.3git20100315$ lintian -i ../u-boot-omap3_2010.3git20100315-0ubuntu1_armel.deb Mar 22 17:10:36 W: u-boot-omap3: wrong-bug-number-in-closes l3:#XXXXXX Mar 22 17:10:38 PFFT ! Mar 22 17:13:57 ogra: You want (LP: #...) anyway. This is the pain of dh_make Mar 22 17:14:07 Don't forget to make it not Priority: extra too. Mar 22 17:14:14 i know, i just havent filed a bug yet Mar 22 17:14:40 err, what prio should it have ? Mar 22 17:14:57 * ogra always leaves it extra Mar 22 17:16:21 Can I shutdown qemu/debian from the monitor gracefully? I notice the ext2 img is easily corrupted Mar 22 17:16:46 persia`, what but debootstrap uses the priority field anyway ? Mar 22 17:16:55 errr ubuntu NOT debian. Sorry. (Don't throw any stones.) Mar 22 17:17:20 nosse1, we wouldnt exist without debian, why would we throw anything ? :) Mar 22 17:17:32 :D Mar 22 17:17:43 ogra: Every package manager displays it Mar 22 17:18:10 nosse1, the karmic version used ext2 and i'm not sure you can do anything beyond "sudo halt" ... afaik the kernel wont power off the VM, you need to close it then Mar 22 17:18:21 persia`, so suggest a prio :) Mar 22 17:18:45 its a bootloader that only exists on arm and shouldnt be used anyway unless you build images Mar 22 17:18:48 ogra: "optional" is correct for nearly all new packages Mar 22 17:18:52 ok Mar 22 17:19:03 Wait. Mar 22 17:19:19 "shouldn't be used anyway unless you build images"? Is it not useful for installed devices? Mar 22 17:19:30 ogra, the login/pwd of my image doesnt work so I cannot login. And the image runs when using -snapshop. The kernel crashes without it Mar 22 17:20:38 persia`, well you can use it if you roll your own beagle images Mar 22 17:20:44 theoretically Mar 22 17:21:05 but for ubuntu installs we'll use flash-kernel anyway to write u-boot to NAND Mar 22 17:21:18 * nosse1 trying rootstock again Mar 22 17:21:31 so there is no real point in actually using it for anyone (while you *can* if you want to) Mar 22 17:22:30 persia`, main point of the package is to make d-i and live images using the u-boot-beagle.bin file from this package (along with the MLO file from the x-loader package thats already in the archive) Mar 22 17:22:30 ogra: OK. YOu have a special package where "extra" happens to be correct. This is very rare :) Mar 22 17:22:37 ah Mar 22 17:23:50 persia`, you have to teach me one day how to make proper dh7 packages that can do multiple runs for different configs on the same source Mar 22 17:24:30 eventually i want the u-boot-omap3 package to support all omap targets but that needs several builds Mar 22 17:25:21 (with one binary for each target) Mar 22 17:25:36 ogra: That's going to take time, and is best done with physical presence I think. That is the sort of thing where looking over a shoulder is useful. Mar 22 17:26:12 i know how to do it the old way but dh7 is rather blurry to me Mar 22 17:27:29 Yeah. dh(1) is just as flexible as dh_*, but most folk get confused because of the CDBS-like features. Mar 22 17:27:36 yeah Mar 22 17:27:58 its not important now though ... rather a L+1 thing Mar 22 17:28:09 beagle only is sufficient atm Mar 22 17:29:02 but given the source can also build for zoom1/2 and EVM boards i'D like to sopport them one day Mar 22 17:44:22 Must qemu be run as root? Mar 22 17:48:38 According to e2fsck, the images produced by rootstock have fs-errors Mar 22 17:48:55 qemu definitely doesn't need to be run as root. Mar 22 17:49:22 nosse1, that's pretty normal, just let it clean it up... Mar 22 17:50:12 e2fsck is usually not happy with the time variances so it checks just in case.. Mar 22 17:50:19 or use lucids rootstock (since you build minimal images anyway) Mar 22 17:50:25 Yes, but it seems to be coinciding with crashes of apps inside qemu. I'm not sure, it just seems that way Mar 22 17:50:30 in lucid rootstock defaults to ext3 Mar 22 17:50:48 I'm getting inode count errors and such Mar 22 17:54:07 nosse1, does it clear up on the next reboot? Mar 22 17:54:34 Sometimes I get kernel crashes, sometimes stack dumps in the console and other times I get "I/O error, dev sda" Mar 22 17:54:48 Using -snapshot seems to remedy all of these errors Mar 22 17:55:48 sounds fun, which kernel you using? Mar 22 17:55:59 vmlinuz-2.6.31-rc3versatile1-cortex-a8 Mar 22 17:56:56 nosse1, thats definately not the one from the wiki Mar 22 17:57:08 (i asked you before if you use the one from the wiki) Mar 22 17:58:42 Yes, you're right. I have no clue where this vmlinuz-2.6.31 came from. It was just lying in my dir. Mar 22 17:58:59 But using the one from the wiki, I still have the sda I/O error issue Mar 22 17:59:01 heh Mar 22 18:00:23 hey ogra, just catching up on the backlog, you guys really planning to put the kernel in nand? Mar 22 18:00:35 (omap's) Mar 22 18:00:43 rcn-ee, likely, yes Mar 22 18:00:56 as long as kernel and initramfs actually fit Mar 22 18:01:30 okay.. yeah they should... but as side note, the xm might come with no nand.. (to get 1Gb ram..) Mar 22 18:01:34 i need to do some measuring ... my last days were busy with packaging x-loader and u-boot and starting to design the live images Mar 22 18:02:39 from tomorrow on i'll start working on the flash-kernel changes we need and on the actual image builds Mar 22 18:03:18 we will definately flash x-loader and u-boot with the versions from the image during install Mar 22 18:03:34 i'm not 100% sure about kernel and initramfs yet Mar 22 18:04:44 (for now my focus is to have *something* ready by end of the week ... we'll be able to make changes to that before beta2) Mar 22 18:04:45 ogra: use deb3 Mar 22 18:04:59 asac, ?? Mar 22 18:05:01 err source format 3.0 ... that comes with great quilt integration Mar 22 18:05:15 asac, for my next packages i will ... to late now :) Mar 22 18:05:17 you dont need to know how to use it in order to work with it Mar 22 18:05:25 thats evil ! Mar 22 18:05:28 ogra: if you used quilt we can just convert it easily Mar 22 18:05:33 true.. ;) btw, i got my iegp2 working over the weekend.. with 500.2 it'll need about 4-5 backports from 2.6.34-rc2 for dss2/ethernet.. ;) Mar 22 18:05:35 right Mar 22 18:05:41 cool Mar 22 18:06:05 asac, i'm trying to use quilt by default now even though i hate it Mar 22 18:06:38 rcn-ee, do you know if iegp2 uses the same x-loader and u-boot ? Mar 22 18:06:39 ogra, I still get I/O error on sda using qemu and this time the kernel from the wiki ( ;) ) Mar 22 18:07:07 it's different... ;) Mar 22 18:07:17 nosse1, sorry i have no idea whats going on there, does your user own the disk image ? Mar 22 18:07:28 (i.e. does he have write access to it) Mar 22 18:07:34 rcn-ee, sad Mar 22 18:07:48 ogra, yes Mar 22 18:07:52 * ogra would love to have one generic omap image that works everywhere Mar 22 18:08:36 It's using 1.4.2 x-loader, but i'm not sure if it's the same as beagle.. (it does use OneNAND Flash, so that's different..) the U-boot is 2009.08 and uses boot.ini scripts at boot. (instead of beagles boot.scr) same format thou.. Mar 22 18:08:40 I'll search around Mar 22 18:09:07 nosse1, worst case you could grab rootstock from lucid Mar 22 18:09:13 but 720mhz & 512Mb ram, so it's going into my gcc farm after i get lucid booting.. ;) Mar 22 18:09:24 or just change ext2 to ext3 inside the rootstock script manually Mar 22 18:09:51 rcn-ee, hey, thats nearly as good as the babbage board :) Mar 22 18:10:03 you just need SATA ;) Mar 22 18:10:49 ok, my revC4 boots with x-loader and u-boot from the archive ... Mar 22 18:10:57 yeap it is.. ;) yeap no sata, but onboard wifi and bluetooth.. ;) Mar 22 18:10:58 time to call it a day ... i was up early Mar 22 18:11:07 wifi ++ Mar 22 18:11:38 sound cool, you have c4 usb patches right? Mar 22 18:11:51 i havent booted to a rootfs Mar 22 18:12:11 amitk would know if we have all patches Mar 22 18:12:56 u-boot set's up the regulator for the ehci port on the c4, that's why i asked.. i don't think they are in u-boot mainline yet... Mar 22 18:12:59 rcn-ee, do you know if the board initalizes the framebuffer if you dont give any omapfb options on cmdline ? Mar 22 18:13:19 oh, i packaged u-boot-omap3 ;) Mar 22 18:13:29 okay, that should work then.. Mar 22 18:13:32 didnt touch mainline Mar 22 18:13:45 sarkomans tree Mar 22 18:14:16 i was thinking that over the weekend.. it didn't in the past... and we've always defined it on the command line... Mar 22 18:14:27 ogra, I'm using a rootstock patch which i got from asac. I needed it to be able to run qemu for a lucid target on a karmic (64-bit) machine Mar 22 18:14:38 so i would say no... Mar 22 18:14:47 crap Mar 22 18:15:03 there is a read edid script in angstrom....... Mar 22 18:15:06 thats really messy behavior ... it should jut read EDID Mar 22 18:15:17 yeah, that was dropped years ago from ubuntu Mar 22 18:15:29 doesnt help me if i need the value on cmdline Mar 22 18:16:05 the driver should just check the monitors capabilities and set the highest resolution by default Mar 22 18:16:15 the other issue, the omapfb comand also allocates kernel memory too for the frame buffer... Mar 22 18:16:16 i wonder why that seems to be so hard Mar 22 18:16:41 Well, there is a big limitation on the screen size... (hardware pixel clock) Mar 22 18:16:46 that should also have a default value Mar 22 18:17:03 i think starting with fbfev isnt good to add EDID - but have not looked closely Mar 22 18:17:10 well, but you know your pixel clock capability Mar 22 18:17:13 that's one reason i always recommend the 720p value, it's the most compaitable and biggest.. Mar 22 18:17:23 so you can fall back to something hardcoded Mar 22 18:17:36 its just evil to have to define *defaults* on the cmdline Mar 22 18:17:45 at least these should be there automatically Mar 22 18:17:56 i find it ok to *override* on cmdline Mar 22 18:18:08 but making it a requirement is just bad habit Mar 22 18:18:11 pixel clock limitation is here; http://elinux.org/BeagleBoardFAQ#Display_resolutions_.232 Mar 22 18:18:43 ogra: do we have graphics drivers for beagle already? Mar 22 18:18:53 asac, from debian, yes Mar 22 18:19:00 ogra: is that in archive and just works? Mar 22 18:19:11 it's a sudo neon optimzed framebuffer driver... Mar 22 18:19:27 asac, havent tried yet Mar 22 18:19:33 the guys at allwaysinnovating also did their own varient of that too.. Mar 22 18:19:43 but yes, there is omapfb and omapfb with NEON Mar 22 18:20:01 we have two to pick from, not sure how good they are Mar 22 18:20:11 i'll test that once we have a working image Mar 22 18:20:13 use the neon one... Mar 22 18:20:16 one step at a time :) Mar 22 18:20:21 ogra: i guess we have neon in cpuinfo? Mar 22 18:20:27 if thats stable i will :) Mar 22 18:20:32 shouldnt we just install both and it will pick the right one? Mar 22 18:20:39 asac, at least with the pre-built kernel amitk gave me Mar 22 18:20:43 it's been the default in angstrom for a good year and half.. ;) Mar 22 18:20:57 sounds promissing. nice Mar 22 18:21:02 rcn-ee, angstrom uses different toolchain Mar 22 18:21:15 so i wont say hooray until i tested it ;) Mar 22 18:21:19 yeap, 4.3.3 vs 4.4.x.. Mar 22 18:21:24 but yes, promising for sure Mar 22 18:22:04 * ogra wonders if 500.2 finally made it to the archive Mar 22 18:22:08 ogra: does JamieBennett has a usable environment alöready? maybe he can check that? Mar 22 18:22:21 asac, he should have everything he needs Mar 22 18:22:29 ogra: whats the status on imx kernel in -proposed ? Mar 22 18:22:33 :-P Mar 22 18:22:42 no idea, was it uploaded already ? Mar 22 18:22:54 * ogra didnt get any pings yet /me thinks Mar 22 18:23:16 which reminds me.. did amit put the vfp patches you used for imx in omap's branch? it needs it to.. Mar 22 18:23:50 asac, ogra, ping me in the morning if you want me to check something, about to leave the house in 10 minutes Mar 22 18:23:51 no idea, that kernel is fully his work, i only saw two binaries yet Mar 22 18:24:16 JamieBennett, just bring up your board tomorrow so you can test stuff Mar 22 18:24:17 JamieBennett: ok. would like to have the omap x drivers checked ... Mar 22 18:24:26 JamieBennett: 1. do both (neon + non neon) work Mar 22 18:24:30 okay, well it's no in mainline yet either, so it would be easy to spot in the log.. Mar 22 18:24:35 ogra: will do, first thing I'll do in the morning Mar 22 18:24:35 2. is the right driver automatically selected if we install both Mar 22 18:24:42 asac, given the kernel is stable enough to even try :) Mar 22 18:24:56 ogra: thought we are already there? Mar 22 18:25:00 no, it won't... i had a user with that problem on karmic.. Mar 22 18:25:02 for me 500.2 has multiple issues Mar 22 18:25:11 hmm Mar 22 18:25:11 asac, its there but buggy Mar 22 18:25:17 usb didnt work Mar 22 18:25:28 which is somewhat essential on a beagle :) Mar 22 18:25:36 did we backport their patches or just took the right upstream branch for .32? Mar 22 18:25:38 ext4 wipes the FS Mar 22 18:25:53 i think its plain mainline .33 Mar 22 18:25:59 asac, just a config issue on the usb.. Mar 22 18:26:09 i see the modules loaded Mar 22 18:26:19 it oopsed when i unloaded Mar 22 18:26:24 rcn-ee: cool. can you give ogra or kernel team pointers? Mar 22 18:26:51 though i didnt put much time into it yet, booting and image rolling is my current main concern Mar 22 18:27:09 once thats ready we can fiddle with the rest Mar 22 18:27:11 ogra: right focus on that. jamie and rcn-ee can probably help if you spit out first iamges ;) Mar 22 18:27:30 especially *everyone* can as soon as we have daily builds :) Mar 22 18:27:31 yeap, that's my goal.. ;) my staging area is here: https://code.launchpad.net/~beagleboard-kernel/+junk/lucid-ti-omap and i got a good number of random omap boards.. ;) Mar 22 18:27:43 i want to extend our user base first :) Mar 22 18:28:14 rcn-ee: can you reproduce the issues ogra mentioned? Mar 22 18:28:15 anyway, i'm really done now ... Mar 22 18:28:22 ogra: see you tomorrow Mar 22 18:28:23 * ogra calls it beer o clock for real now Mar 22 18:28:24 but we don't have enough boards yet for new users.. ;) Mar 22 18:28:33 take it easy ogra.. ;) Mar 22 18:28:35 rcn-ee, revC Mar 22 18:28:43 there are lots and lots of users :) Mar 22 18:28:50 asac, i forgot, what issue? ;) Mar 22 18:29:05 rcn-ee: he said his beagleboard is unstable with current kernel in lucid Mar 22 18:29:33 USB and ext4 are the things i spotted yet Mar 22 18:29:47 That's strange.. although i have ran 500.2 more then 5 minutes.. (boot [x], things work [x]) Mar 22 18:29:48 unloading the twl driver makes it oops Mar 22 18:29:55 but mailine 2.6.33 is stable for me.. Mar 22 18:30:01 rcn-ee: are you using lucid packages etc.? Mar 22 18:30:27 they are here if you look for them http://people.canonical.com/~amitk/ti/ Mar 22 18:30:34 yeap... one beagle it's all chroots, another beagle it's different partitions with each dist Mar 22 18:30:52 thanks ogra, will test those... Mar 22 18:31:01 i think at least ... Mar 22 18:31:11 i hust noticed they still say 500.1 Mar 22 18:31:12 thats 500.1 Mar 22 18:31:18 ack Mar 22 18:31:22 where is 500.2 Mar 22 18:31:22 ? Mar 22 18:31:24 in archive? Mar 22 18:31:46 i think that *is* 500.2 just wrongly versioned Mar 22 18:31:54 500.2 was FTBFS this morning Mar 22 18:31:57 i know amit was testing scripts... Mar 22 18:33:05 asac, i know usb can be solved with: https://lists.ubuntu.com/archives/kernel-team/2010-March/009484.html but the question is why desn't the twl stuff like being moderlized... Mar 22 18:34:34 it could be timing with specially since CONFIG_TWL4030_USB sets the power regulator on the musb... Mar 22 18:34:59 Are there any real speed or size differences between ARMv7 and earlier? Mar 22 18:35:28 nosse1, think 486/686/etc.. ;) Mar 22 18:35:36 heh Mar 22 18:35:44 good answer ;) Mar 22 18:36:19 it just gets more complicated since there are alot of x's.. x86... Mar 22 18:37:27 theres an opinion here claiming that the 'x' of the distro doesnt really matter. The important stuff is the end-user app Mar 22 18:38:15 so out of curiosity I was wondering if there had been any real (linux) benchmarking to it Mar 22 18:38:31 nosse1, take a look at these, sheevaplug is armv5 and debian squeeze is built for armv4 http://global.phoronix-test-suite.com/?k=profile&u=robertcnelson-3173-25135-22766 Mar 22 18:41:16 rcn-ee, thanks Mar 22 18:42:11 no problem, it was a fun comparsion test, i'm planning to redo it again, and add a iegp2 for comparsion, it has the same clock speed as the c4, but double the ram.. Mar 22 18:47:32 I sent a mail to phoronix asking for them to test various arm distros and settings Mar 22 18:48:10 seeing they already have.. Mar 22 18:48:25 oh they haven't yet... ;) Mar 22 18:49:44 I've talked with a couple of them at phoronix, they do have access to some arm boards.. Mar 22 18:50:23 I asked about the latest developer boards, so i guess my question is still valid Mar 22 18:51:53 yeap it is.. if you search for arm under their search_results, there is another anonymous user running tests other then me... Mar 22 18:52:14 With the barrage of ARM cellphones being released and the ever increasing software stack on there is think they should allot more time for it Mar 22 18:52:50 yeap.. but you get these funny comparisions.. http://global.phoronix-test-suite.com/?k=profile&u=linuxeasecom-14106-16996-6522 Mar 22 18:54:10 (the lame and ogg) results are invalid on that one.. i should bug phronix, they are missing a dependicy.. Mar 22 18:58:37 Don't you think that there's a lot LFS out there for embedded targets such as ARM phones? Mar 22 18:59:20 Exactly Mar 22 18:59:36 I mean in our product, it is quite new to endorse a distro. I'm living in the LFS/busybox compile-all-in-a-large-image kind of thing Mar 22 18:59:59 I'm still not 100% convinced to deploy ubuntu into our product Mar 22 19:01:54 Hopefully my playing around with ubuntu can change that. I'm certainly happy with Ub. on hosts Mar 22 19:02:36 Even nokia isnt alone in the mobile linuxworld anymore Mar 22 19:03:07 Only palm is i think Mar 22 19:05:48 Since ubuntu is built natively, this implies that you build your own toolchains as well (don't use the popular CodeSourcery, or do you)? Mar 22 19:58:33 All right, I think I finally got the qemu thing going. Tomorrow I will try it on real target. Mar 22 19:59:53 If it still doesnt work, what is my approach for figuring it out? I know it started init, but I didn't get a login prompt Mar 22 20:04:58 For all you guys helping me out: I hope I haven't annoyed too much. Thanks a lot for you help! Mar 22 20:20:12 How hard would it be to get ubuntu running on this? http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=170414804289 **** ENDING LOGGING AT Mon Mar 22 22:48:09 2010 **** BEGIN LOGGING AT Mon Mar 22 22:54:15 2010 **** ENDING LOGGING AT Mon Mar 22 23:25:21 2010 **** BEGIN LOGGING AT Mon Mar 22 23:44:15 2010 Mar 23 01:43:25 like arm v7 cortex a5 is faster arm 1136 Mar 23 01:44:26 an a5? it would need a lot of clockspeed... Mar 23 01:51:05 I haven't seen any performance comparisons. Has anyone announced A5-based SoCs yet? Mar 23 01:53:26 one of the marvell ARMADA cores is.. and ti has one.. Haven't seen any numbers, but it should be slower then a8/a9.. Mar 23 01:53:55 rcn-ee: really? I thought marvell designed their own cores. And which TI part has an A5? I've completely missed that announcement Mar 23 01:56:33 Seems like A5 has better DMIPS/MHz than 1136, but that doesn't mean that real-world performance is better. Mar 23 01:57:59 well yeah Marvell does that in the end... but they say it's a5 compatable... Mar 23 01:58:18 A5 compatible means A8 compatible. I don't see the point in that statement. Mar 23 01:58:22 bzzt. Mar 23 02:02:28 well, A5 is an 8 stage vs A8's 13 stage pipeline, but since Marvel designs it anyways, who knows what the difference is.. ;) Mar 23 02:05:07 yeah sorry about that ti doesn't have a a5, i was getting their new Sitara 500Mha A8.. Mar 23 02:05:13 confused.. Mar 23 02:09:51 rcn-ee: Yeah, you seem to be very confused. :) Mar 23 02:10:47 and i think i'm going nutz, right now i'm 1/2 defconfig changes between a beagle and igep2 both working with ubuntu 500.2 kernel.. Mar 23 02:11:04 (dss2 omapfb stuff) Mar 23 02:30:22 plars: hi, paul, did you test the daily build of UNE for fsl-imx51 Mar 23 02:30:39 plars: i can not enter X, just got a black screen, even beta1 release Mar 23 02:30:46 plars: mine is bb2.5 Mar 23 02:31:39 cooloney: Any interesting output on console? Mar 23 02:36:08 persia: i can switch to console vt1 Mar 23 02:36:20 persia: and login with reentering a new password Mar 23 02:37:00 persia: although i just need my console works firstly Mar 23 02:37:06 What is the output of `date -u` ? Mar 23 02:47:10 cooloney: yes, I tried it, worked fine for me Mar 23 02:47:36 cooloney: I am on babbage 3 though, haven't tried on 2.5 Mar 23 02:51:26 plars: so weird Mar 23 02:52:11 plars: http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-live/current/ Mar 23 02:52:16 i installed this one Mar 23 02:52:57 persia: Tue Mar 23 02:51:10 UTC 2010 Mar 23 02:54:09 OK, so that's not the date bug. Mar 23 02:54:29 Does /var/log/Xorg.log have anything useful? **** ENDING LOGGING AT Tue Mar 23 02:59:57 2010