**** BEGIN LOGGING AT Fri Jun 24 02:59:57 2011 **** ENDING LOGGING AT Fri Jun 24 03:19:19 2011 **** BEGIN LOGGING AT Fri Jun 24 03:20:10 2011 Jun 24 04:07:30 persia, paulliu knows the detail - btw, can you let Quntasan send email to us, me and pualliu, thanks Jun 24 04:11:05 I'll try to convince him. Thanks for the pointer. Jun 24 09:52:15 soo, seems we have images again Jun 24 09:52:27 og? Jun 24 09:52:36 tabcomp fail :p Jun 24 09:52:37 and the oversizedness is caused by the fact that the images contain *all* langpacks Jun 24 09:52:54 oh dear Jun 24 09:53:12 so how does one go about getting a package in universe Jun 24 09:53:15 say a kernel Jun 24 09:53:45 you file a bug pointing to the package and then find a sponsor Jun 24 09:54:01 ok, sounds easy enough Jun 24 09:54:02 or you get it into debian ... Jun 24 09:54:08 which is the preferred way Jun 24 09:54:15 but might be hard in case of kernels Jun 24 09:54:29 would be hard in the case of my tab kernel Jun 24 09:54:58 in any case it would be better to have upload privileges Jun 24 09:55:16 going through sponsoring with a kernel is painful Jun 24 09:55:26 heh Jun 24 09:55:29 at least for followup changes and fixes Jun 24 09:55:55 yeah that is what I am not looking forward to, with the sponsor method that is Jun 24 09:57:05 neither will your sponsor Jun 24 09:57:37 uploading a 90M package for every change is annoying, finding sponsors for that will not be easy Jun 24 09:57:55 long term i would suggest to earn upload privs Jun 24 09:58:10 hm Jun 24 09:58:44 or have someone with these privs in your team that maintains the arch Jun 24 09:59:54 that sounds the hardest Jun 24 10:00:17 Hi all, I have installed Ubuntu arm 11.04 on my beagleboard C3. The thing is usb devices attached to it works in the early stages of booting of the system. But when the booting finishes the usb devices stop working. Any ideas? Jun 24 10:00:23 I don't know anyone with upload privs Jun 24 10:04:06 ogra: the good news is though I am killing the last bug that affects basic usability since switching up to the new kernel Jun 24 10:04:23 what version are you on now ? Jun 24 10:04:44 2.6.35.7 Jun 24 10:04:55 oh, still ancient Jun 24 10:05:24 yeah Jun 24 10:05:26 but newer Jun 24 10:07:00 Finding sponsors doesn't have to be that hard. I'm almost always willing to sponsor kernel uploads to universe, for example. Jun 24 10:08:54 kunguz, Maybe bug #784474? Jun 24 10:08:55 Launchpad bug 784474 in linux-ti-omap "usb enumeration fail on beagleboard" [Undecided,New] https://launchpad.net/bugs/784474 Jun 24 10:09:52 ubot2: persia seems similar, thank you Jun 24 10:09:53 kunguz: Error: I am only a bot, please don't think I'm intelligent :) Jun 24 10:10:13 ubot2: but you are clever one :D Jun 24 10:10:13 kunguz: Error: I am only a bot, please don't think I'm intelligent :) Jun 24 10:10:42 kunguz, I'm not sure that's precisely the bug: it has a decent test scenario written up. If you can't replicate precisely that way, it's always safest to search a bit more for a bug you can precisely replicate, or file a new one. Jun 24 10:11:05 * ogra ponders what to do with the images Jun 24 10:11:14 What do you mean? Jun 24 10:11:28 We should have enough space to include all langpacks on the 1 GB armel desktop Jun 24 10:11:28 live images: Jun 24 10:11:29 * /^language-pack-[^-]+$/ [armel] Jun 24 10:11:29 * /^language-pack-gnome-[^-]+$/ [armel] Jun 24 10:11:31 that ... Jun 24 10:11:42 (paste from the live seed) Jun 24 10:11:59 seems lool added that back when we still rolled live images Jun 24 10:12:15 Let them be oversized for a bit more. In #ubuntu-devel there was some talk about sorting the internationalisation bit next week. Jun 24 10:12:25 well Jun 24 10:12:28 for live, yes Jun 24 10:12:32 There's some reason to have *lots* of languages right now. Jun 24 10:12:50 for preinstalled we likely need some extra code Jun 24 10:12:57 and i dont really want 1G images Jun 24 10:13:14 I suppose. Jun 24 10:13:38 My suspicion is that the work on making sensible international images will end up reducing that substantially. Jun 24 10:13:41 persia: even my galaxy tab 7" image? :) Jun 24 10:14:05 lilstevie, *especially* your galaxy tab image. I would really like Ubuntu to support as many retail devices as we can. Jun 24 10:14:20 ++ Jun 24 10:14:25 But I'm not a kernel hacker, so all I can do is review other folks kernels, make sure they're packaged sanely, and help them get images from them. Jun 24 10:14:29 :) Jun 24 10:14:56 well I am within 24hours of a sane kernel Jun 24 10:14:57 :) Jun 24 10:15:16 For packaging, I'd recommend starting from either jcrigby's scripts or linux-n900 (derived from those)., depending on which makes you more comfortable. Jun 24 10:15:37 persia, note that the hack above is armel only, no other arch ships all langpacks Jun 24 10:15:45 I'm within 24 hours of my weekly "ignore IRC traffic for 20-30 hours" time, but I'd be happy to upload later in the weekend. Jun 24 10:15:57 tbh I will need a bit of help with the packaging, the only debs I have ever packed have been for apt on arm-darwin Jun 24 10:16:07 ogra, So, we should undo that. I'm still not tempted to undo it until we understand the i10n plan. Jun 24 10:16:27 well, i'm happy to go with the defaults all arches use Jun 24 10:16:37 * ogra drops the lines from the seed Jun 24 10:16:49 If you want to have a seed commit today, I'm 100% in favour of doing anything to make armel less special in the seeds. Jun 24 10:17:02 I just expect that we'll have to fiddle it again later. Jun 24 10:17:26 why ? Jun 24 10:17:35 we will inherit whatever desktop does Jun 24 10:17:39 lilstevie, I *may* have time on Sunday, depending on your timezone, etc. If not, I'll try to catch you as soon as I have time. Jun 24 10:17:46 :) Jun 24 10:17:49 Because preinstall != live. Jun 24 10:18:05 well it is 8:15pm friday here :p Jun 24 10:18:18 Ah, a *good* timezone :) Jun 24 10:18:29 :) Jun 24 10:18:31 persia, well, the only difference is casper vs jasper Jun 24 10:18:41 we use the live seed on preinstalled Jun 24 10:18:46 So, yeah, there's a chance I'll have time Sunday evening then. Jun 24 10:18:59 seed change pushed Jun 24 10:19:07 lets see how much that saves Jun 24 10:19:19 i guess we should come out below 800M now Jun 24 10:19:46 Given that there is a *new* method of doing internationalisation in the works, I'm expecting *both* jasper and casper to need adjustment, along with live-build configu. Jun 24 10:19:58 But yeah, for the weekend, we can have smaller images. Jun 24 10:20:48 well, desktop will not go to bigger images for now Jun 24 10:20:53 lilstevie, Be aware that the release manager has all sorts of requirements for generating images. In practice, this typically means that if we get a kernel into the archive in one cycle, we can have proper images the *next* cycle. That said, if your kernel is good enough, and there are testers, etc.., we may be able to work around that. Jun 24 10:20:57 so they will rather drop langs than add Jun 24 10:21:06 It's changing. Jun 24 10:21:11 not yet Jun 24 10:21:22 Stuffing bundles of langs into a single image may not be how it is done in the future. Jun 24 10:21:31 as i understood we still go for 700M in oneiric Jun 24 10:21:34 And there is no way to have any idea about this until next week. Jun 24 10:22:22 persia: heh I don't think we will be working around that Jun 24 10:22:22 Yes, oneiric images will be 700M. Nonetheless, per-locale customisations are happening in a *completely* different way than in the past, and much more comprehensively, which likely has implications about how locale-specific code ends up in default images. Jun 24 10:22:46 lilstevie, Fine by me, as long as you don't mind it being a remix for 11.10. Jun 24 10:23:00 i dont care about customizations :) Jun 24 10:23:05 only about the default image Jun 24 10:23:06 If there are enough users, etc. then we can apply to have proper images for 12.04. Jun 24 10:23:22 Yes. Please read my last sentence again. Jun 24 10:23:24 persia: that said I always tend to understate my stuff Jun 24 10:23:42 persia: my problem is the lack of hardware support Jun 24 10:23:50 lilstevie, It's a geographical limitation. You're just following your peers. Jun 24 10:24:00 heh Jun 24 10:27:03 persia: well there already have been some testers just FYI Jun 24 10:27:12 on the utouch team Jun 24 10:28:11 More folk always help, but we're going to need someone to commit to the milestone testing, which basically means being nearly continuously available (for respins) for ~3 days for each milestone release to ensure image quality. Jun 24 10:28:42 And that usually requires user numbers in the 100s, unless one happens to get lucky and catch a great tester early. Jun 24 10:29:04 hm, well I don't know about 100s :/ Jun 24 10:29:31 Heh, yeah. That's part of why it's sensible to start slowly. Jun 24 10:30:07 If you make something great, and then you tell your users that someone has to volunteer to help test in order to continue, you'll either get a volunteer, or you'll have confirmation that there isn't enough interest. Jun 24 10:30:19 heh Jun 24 10:39:49 hmm Jun 24 10:40:04 so how do i make preinstalled images use the oem user Jun 24 10:40:26 should that be created at image build time or by jasper Jun 24 10:43:32 By jasper. Jun 24 10:43:40 why ? Jun 24 10:44:00 To parallel casper, and keep live-build config more similar. Jun 24 10:44:18 (yes, there's messiness now, but I'd rather clean that up than add to it). Jun 24 10:44:48 well, do you see a reason why preinstalled images shouldnt have an oem user and oem-config enabled by default Jun 24 10:45:09 Remastering. Jun 24 10:45:19 i actually think that code should move into the build process Jun 24 10:45:27 For live also? Jun 24 10:45:30 no Jun 24 10:45:39 OK. Why should live and preinstall be different? Jun 24 10:45:49 well, for remastering its actually an advantage Jun 24 10:46:03 because they are totally different things by design Jun 24 10:46:38 preinstalled images will always have oem-config installed Jun 24 10:46:56 so why not enable it by default (including the user) Jun 24 10:47:46 wrt remastering ... if you dont use the jasper initrd, you are screwed today Jun 24 10:47:57 Why? Jun 24 10:48:06 because jasper enables oem-config Jun 24 10:48:22 I know of people who have extracted the rootfs from a preinstall, generated a *different* initrd, and used it on devices. Jun 24 10:48:52 i know of people trying to use our preinstalled rootfs as is but without initrd :) Jun 24 10:49:07 Heh. Jun 24 10:49:19 if you only want the rootfs then you have to manually fiddle with it to get oem-config up Jun 24 10:49:23 I had to manually touch /var/lib/oem-config/run Jun 24 10:49:31 So the basis of my argument is mostly "There should be no difference between live and preinstall". Jun 24 10:49:31 i.e. you have to do all the bits jasper does to the rootfs Jun 24 10:50:01 But I can see the argument "There should be no difference between preinstall and the results of booting live and performing an orm install". Jun 24 10:50:01 jasper should *only* care about partitioning and resizing Jun 24 10:50:23 and the peripherial bits that includes like bootloader config and fstab creation etc Jun 24 10:50:47 i want to get all unrealted hacks out of the code Jun 24 10:50:49 OK. I can accept that. Jun 24 10:51:00 enabling oem-config is one Jun 24 10:51:03 And jasper might end up going away completely, replaced by spices, or similar. Jun 24 10:51:08 and we dont even do it right atm Jun 24 10:51:14 (or be the instrument of spice implementation) Jun 24 10:51:29 you will always need the resize on boot bit Jun 24 10:51:35 Right. You've convinced me. oem-config should be enabled by live-build. Jun 24 10:51:58 which in turn means you will need to create fstab and bootloader config at the same time Jun 24 10:52:33 that cant be handled by seeds only the package can be pulled in or be omitted by seeds Jun 24 10:52:49 i dont expect jasper to go away as long as we have the resizing Jun 24 10:52:49 Ah, and if jasper is pluggable, fstab can be generated dynamically, and bootloader config can be done by spice insertion to some conf.d. Jun 24 10:53:26 well, bootloader config is something that should better live in flash-kernel-installer ... but that will require more changes Jun 24 10:53:39 since its only available in udeb form atm Jun 24 10:53:57 We could add it to oem-config. Jun 24 10:54:04 Or, no, you need it earlier, don't you. Jun 24 10:54:11 no Jun 24 10:54:14 well Jun 24 10:54:15 yes Jun 24 10:54:18 heh Jun 24 10:54:20 tricky Jun 24 10:54:40 i need a change of the cmdline earlier Jun 24 10:54:59 not necessarily a full new setup of the bootloader Jun 24 10:55:02 We already did the work to have a ubiquity controller for flash-kernel-installer, so it would be handy if we didn't need it until oem-config runs, but because we need it early, jasper has to do it. Jun 24 10:55:11 the actual setup could be done by oem-config Jun 24 10:55:26 but that wouldnt get rid of bootloader code in jasper Jun 24 10:55:42 If we're going to have bootloader code in jasper, let's use flash-kernel. Jun 24 10:56:01 thats what it does ... just not for the setup Jun 24 10:56:11 i.e. the generation of config Jun 24 10:56:25 flash-kernel-installer won't generate the config? Jun 24 10:56:41 flash-kernel-installer isnt existent in jasper Jun 24 10:56:48 i would have to pull it into the initrd Jun 24 10:57:00 Not all of it. Jun 24 10:57:02 with a big penalty (lots of different bootloader deps) Jun 24 10:57:31 So, the way ubiquity does it is to embed the flash-kernel source in the ubiquity source, and then copy flash-kernel-installer.postinst to somewhere useful when building the binary. Jun 24 10:57:34 by current design, all of it Jun 24 10:57:39 It then calls that script to do the setup. Jun 24 10:57:52 i know how ubiquity works Jun 24 10:58:02 (i worked on that code too) Jun 24 10:58:02 Can't we do the same thing for jasper? Jun 24 10:58:16 And inject only the bootloader support demanded by the spice? Jun 24 10:58:33 yes, but to keep it generic you would have to pull all bootloader tools into the initrd Jun 24 10:58:39 that will get huge Jun 24 10:58:40 Yeah: just refreshing both our memories to make sure we're talking about the same thing :) Jun 24 10:58:58 We don't need generic at that point: this is what spices are supposed to do. Jun 24 10:59:06 That's the entire point of the two-stage image build process. Jun 24 10:59:24 well, thats not how flash-kernel-installer is workigng currently Jun 24 10:59:39 so that would need some massive redesign Jun 24 10:59:55 I thought that flash-kernel-installer simply assumed that everything was present, but then only called the bit it needed for the board it was using. Jun 24 10:59:56 modularization ... and support for initrd Jun 24 11:00:14 flash-kernel-installer *makes* everything present Jun 24 11:00:20 thats part of its job Jun 24 11:01:13 it chroots and installs the bits and pieces for the currently used arch Jun 24 11:01:15 Yes, but that's the dependencies. flash-kernel-installer.postinst doesn't do that on it's own, does it? Jun 24 11:01:30 which means you need support for *all* arches in the ship seed Jun 24 11:01:30 And flash-kernel-installer.postinst is *designed* to run from an initrd (the d-i environment) Jun 24 11:01:39 Why? Jun 24 11:01:50 flash-kernel-installer.postinst chroots and calls apt_install Jun 24 11:02:14 flash-kernel-installer.postinst is not designed to be run from an initrd Jun 24 11:02:24 it is designed to be run in d-i context Jun 24 11:02:55 The d-i context *is* an initrd, but we stray :) Jun 24 11:02:57 it expects certain d-i copmponents to be there Jun 24 11:03:17 It calls apt_install for *everything*, rather than just the currently-detected platform? Jun 24 11:03:27 no Jun 24 11:03:39 Right. Jun 24 11:03:47 its doable but as i said in the beginning it takes a lot of changes Jun 24 11:04:01 Ah. because in the preinstall context, we don't have a chroot. Right. Jun 24 11:04:03 and essentially a complete redesign of flash-kernel-installer Jun 24 11:04:09 Let's not do that. Jun 24 11:04:14 we do have a chroot Jun 24 11:04:18 from initrd Jun 24 11:04:32 So, why do we need to change anything? Jun 24 11:04:41 apt_install is a no-op if the package is already installed. Jun 24 11:04:50 if we want to use it out of context we need to change it Jun 24 11:05:15 apt_install doesnt *exist* in non d-i initrds Jun 24 11:05:28 there are plenty of calls to d-i tools in the scripts Jun 24 11:05:40 you cant just dump it into an initrd Jun 24 11:05:47 it wouldnt run Jun 24 11:06:01 Ah, so we'd end up embedding all sorts of things, essentially duplicating ubiquity, and we'd get all sorts of annoyed trying to maintain it. Jun 24 11:06:02 Right. Jun 24 11:06:06 yeah Jun 24 11:06:57 so it would have to become more modular (so you only pull in the snippets you need at initrd generation time) and would need a layer that can switcfh between d-i tools and normal initrd binaires Jun 24 11:07:02 So, we have flash-kernel available in the chroot, right? And whatever bootloader support bits we need for the target? Jun 24 11:07:31 and you would need arch specific hooks in initramfs tools so you can select which bootloader tools go into the initrd Jun 24 11:07:34 Oh, but that won't generate the initial configuration. Jun 24 11:07:45 right Jun 24 11:07:48 No I don't. Jun 24 11:08:00 I can control that by which packages I happen to have installed at initrd generation time. Jun 24 11:08:01 the first change of the cmdline is the bit Jun 24 11:08:19 for the actual final initrd we can actually use flash-kenrle-installer Jun 24 11:08:22 * persia wishes someone would port grub2 already, *again* Jun 24 11:08:23 *kernel Jun 24 11:08:33 * ogra doesnt :P Jun 24 11:08:36 flash-kernel-installer, or flash-kernel? Jun 24 11:08:44 the former Jun 24 11:08:48 from oem-config Jun 24 11:08:57 Oh, right. Because that gives us a d-i context. Jun 24 11:09:02 right Jun 24 11:09:05 So, really, we just need to be able to boot *this one time*. Jun 24 11:09:07 its only the jasper bits Jun 24 11:09:22 where i parse the cmdline and adjust it after resizing Jun 24 11:09:45 So, I don't believe there's a generic way to change the commandline. Jun 24 11:09:53 We've different requirements for different bootloaders. Jun 24 11:10:04 not generic, but pretty generic Jun 24 11:10:22 we currently support what, two bootloader variants in ubuntu ? Jun 24 11:10:31 u-boot and abootimg Jun 24 11:10:51 redboot is gone from teh achrive and from flash-kernel since a few days Jun 24 11:10:55 (and from d-i) Jun 24 11:11:33 Yeah. I have to add some of it back one of these days, if I ever get around to upgrading my netwalker (I kinda wish someone would come out with a satisfactory replacement I could just buy instead). Jun 24 11:11:51 But what I'd add back for redboot is *completely different* from what was there, so that's not strictly relevant. Jun 24 11:11:52 ogra: Do you know if PXE boot is likely going to be an option for next? Jun 24 11:12:05 And there's the messiness for the Nokia devices, but that's something else. Jun 24 11:12:06 (or anyone else) Jun 24 11:12:10 Daviey, "next"? Jun 24 11:12:30 Daviey, the code is in our oneiric u-boot package Jun 24 11:12:40 Daviey, we'll run some tests next week Jun 24 11:12:41 Daviey, You want to watch https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-o-uboot-pxe-support andhttps://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-o-uboot-initial-usb-tftp-support-panda Jun 24 11:13:21 Supposedly, as part of those implementations, we'll end up with docs that describe how to enable PXE for arbitrary u-boots (needs device driver porting) as part of that delivery. Jun 24 11:13:28 persia, yeah, well, we largely dropped imx51 Jun 24 11:13:38 and all bootloader code it had Jun 24 11:13:48 or better lool dropped i just nodded :) Jun 24 11:14:01 Except for the netwalker, all the i.MX devices I have use u-boot. Jun 24 11:14:15 yup Jun 24 11:14:29 most future devices will use fastboot i suspect Jun 24 11:14:46 Dunno. u-boot has a lot of following, and Freescale supports it. Jun 24 11:14:53 if we cover these two we should be largely generic ;) Jun 24 11:15:08 (plus, we *could* have grub2, and not have to worry about any of this mess) Jun 24 11:15:14 pfft Jun 24 11:15:29 unlikely that you get the vendors to support it Jun 24 11:15:37 Ah lovely! Jun 24 11:15:41 took long enough to get most of them to u-boot Jun 24 11:15:56 ogra / persia: we might be pestering you next week. :) Jun 24 11:16:05 we hope so ! Jun 24 11:16:13 Thanks! :) Jun 24 11:17:02 Anyway, for supporting two bootloaders, should that be pluggable? Jun 24 11:17:24 Have the bootloaders provide some file that, when jasper is installed, jasper uses to define *how* to change the cmdline? Jun 24 11:17:44 That's likely more compatible with spices than jamming everything in jasper and hoping the initrd doesn't overflow. Jun 24 11:18:06 I actually think we should consider grub as a third stage bootloader Jun 24 11:19:42 lool, what would be second stage ? Jun 24 11:19:43 lool, I'd love to have a discussion about why we shouldn't use grub as *second* stage, but I really want to figure out the design for pre-oem-config booting first :) Jun 24 11:20:02 I'd love to see grub2 for arm Jun 24 11:20:15 ogra, So, pluggable, or bundle-everything-in-the-initrd and hope we don't get too many bootloaders? Jun 24 11:20:21 persia, well, on the ac100 i have exactly 4M for the initrd Jun 24 11:20:32 That's a good argument for pluggable :) Jun 24 11:20:37 every byte above makes the system oops Jun 24 11:21:37 So we have /usr/share/jasper/bootloaders.d/*.conf, and we source that, and then call "fix_command_line()" ? Jun 24 11:21:48 something like that Jun 24 11:21:59 Oh, right. initrd. Change the names :) Jun 24 11:22:16 And then we add the magic file to abootimg and u-boot. Jun 24 11:22:36 right Jun 24 11:22:45 So, here's the worry. The magic file will end up in the initrd after jasper is purged. Jun 24 11:22:53 Do we care that much? They should be very small. Jun 24 11:23:00 why would it ? Jun 24 11:23:07 Because it lives in the bootloader package. Jun 24 11:23:14 oem-config runs update-initramfs after jasper is removed Jun 24 11:23:27 Right, but that won't remove the files from the bootloader packages. Jun 24 11:23:41 but the hoooks that would install it to the initrd Jun 24 11:23:53 s/it/them/ Jun 24 11:24:30 the files live in the filesystem, but not in the initrd if no hook installs them Jun 24 11:24:37 Aha, so it *would* be somewhere like /usr/share/jasper/... and then jasper would provide the hooks for initramfs-tools, which would be purged on jasper-purge, which would result in the magic files not being in the initrd when update-initramfs is called? Jun 24 11:25:09 well, in /usr/shar/initramfs-tools/hooks, but yeah Jun 24 11:25:34 Well, the hooks go there, but the bootloader implementation files? Jun 24 11:25:52 the hooks define what ends up in the initrd Jun 24 11:25:56 Yes. Jun 24 11:26:07 actually /usr/shar/initramfs-tools/hooks/jasper does Jun 24 11:26:11 But in order to end up in the initrd, stuff has to be in the filesystem. Jun 24 11:26:19 /usr/shar/initramfs-tools/hooks/jasper is part of the jasper package Jun 24 11:26:37 the bootloader config templates can come with the bootloader Jun 24 11:26:43 And the bootloader packages need to deliver the implementations to the filesystem to ensure we don't have multiple (assuming we didn't spice the image to have multiple). Jun 24 11:27:08 right Jun 24 11:27:11 Right. I'm suggesting that the bootloader config templates should be installed to /usr/share/jasper/bootloaders/ or similar. Jun 24 11:27:21 but they wont end up in the initrd ever if /usr/shar/initramfs-tools/hooks/jasper is gone Jun 24 11:27:36 Where jasper ships either an empty directory or a directory containing only .placeholder to support this. Jun 24 11:27:46 Right, which is the correct behaviour. Jun 24 11:29:09 * ogra wishes he would find out why this 4M limit exists on the ac100 Jun 24 11:29:51 Insufficiently hackable bootloader. Jun 24 11:29:56 ogra: partition size? Jun 24 11:30:18 lool, So, why wouldn't we want grub as second stage? Wouldn't using it as third stage add ~8 seconds to boot time? Jun 24 11:30:32 persia: I'm not sure where the 8 seconds are from Jun 24 11:30:48 ogra: is the ac100 fastboot? Jun 24 11:30:52 Random guess on my part to load grub, detect time, timeout, and load the kernel. Jun 24 11:31:42 lool, To put that another way, if we're loading grub2, why wouldn't we want that to be second-stage? Jun 24 11:31:55 it's a bit of a complex story; we could discuss it next week if you like; first, you often need a SPL which just loads the real bootloader into the initialized RAM Jun 24 11:32:12 then you need a bootloader which does good stuff, this could be grub; but we're already at the TPL Jun 24 11:32:23 TPL? Jun 24 11:32:51 invented that one just now for tertiary or third program loader ;-) Jun 24 11:32:56 SPL being secondary program loader Jun 24 11:33:05 Right. Jun 24 11:33:13 the second stage loader is hard for various reasons Jun 24 11:33:27 first, it's extrenely device specific; it's hard to make it generic Jun 24 11:33:32 second, it needs to be extremely small Jun 24 11:33:43 So, for example, on beagle, we do ROM -> FPL (xloader) -> SPL (uboot) -> TPL (linux), right? Jun 24 11:34:21 no, ROM is first stage Jun 24 11:34:25 xloader is a SPL Jun 24 11:34:33 Ah, OK. Jun 24 11:34:46 So you want ROM -> (something) -> grub2 -> linux ? Jun 24 11:35:34 lilstevie, yeah Jun 24 11:36:07 ogra: wonder if it is bootloader related, or if it is partition size Jun 24 11:36:11 fastboot is a pita Jun 24 11:36:22 i'm pretty sure its bootloader related Jun 24 11:36:33 it seems to be related to the unpacked size Jun 24 11:36:48 persia: that's right; the something could perhaps be UEFI related :-) Jun 24 11:37:00 ogra: oh Jun 24 11:37:02 i.e. i can squeeze more into a bz2 or lzma initrd, but that will cause an oops Jun 24 11:37:23 lool, Right. We completely agree, but were previously using different nomenclature. Jun 24 11:37:27 ogra: so maybe its memory hole isnt big enough Jun 24 11:37:33 I also want grub2 as TPL. Jun 24 11:37:38 lilstevie, right Jun 24 11:38:06 persia: also, "something" might need to be in two pieces itself Jun 24 11:38:18 in *some* pieces :) Jun 24 11:38:20 so grub 2 might be QPL or something :-) Jun 24 11:38:31 * lool lunch Jun 24 11:38:56 ogra: FYI memory layout from bootloader is what was causing my issue too, turns out the drivers for 2.6.32 expected FB mem to be at 1 address and the new bootloader has the memory location offset a bit highre Jun 24 11:39:02 higher* Jun 24 11:39:15 lool, I'd really prefer a less capable *something* than a split one. For example, u-boot is often no longer used as SPL beause it has too many features to fit in the small memory barriers, but realistically most of those features aren't needed if handing off to grub2. The same applies, only moreso, for UEFI. Jun 24 11:40:02 often used as ? Jun 24 11:40:12 u-boot *is* an SPL, no ? Jun 24 11:40:32 ogra, For panda, it's TPL. xloader is SPL. Jun 24 11:40:44 well, yeah Jun 24 11:40:47 for panda Jun 24 11:40:52 (according to the nomenclature lool and I are using for this discussion) Jun 24 11:40:55 usually its SPL though Jun 24 11:41:23 omap is special since it doesnt fit enough into its rom apparently :) Jun 24 11:41:32 else x-loader would just live on the board Jun 24 11:41:38 preinstalled in rom Jun 24 11:41:40 No. Jun 24 11:42:09 x-loader is just a trimmed u-boot because u-boot can't all fit in the environment started by the ROM. Jun 24 11:42:27 thats what i said, just the other way round :) Jun 24 11:42:40 But nearly *every* ROM boot code ends up just jumping to somewhere to do setup, and isn't nealy as complex as e.g. x-loader. Jun 24 11:42:51 in non omap boards that bit lives in rom Jun 24 11:42:57 No. Jun 24 11:43:13 So, ROM always just does a jump to somewhere after absolute minimum startup. Jun 24 11:43:22 But ROM is *never* complicated. Jun 24 11:43:28 (this is FPL). Jun 24 11:43:49 Depending on the capability of the ROM, it *may* have enough of an environment to use u-boot as SPL, but it may not. Jun 24 11:43:52 rom inits ram, loads the BL and jumps to it Jun 24 11:44:02 in case of omap the initialized ram is to small Jun 24 11:44:11 If one enables *all* the features in u-boot it's fairly easy to end up with needing something else as SPL. Jun 24 11:45:12 hence the comment above '"something" might need to be in two pieces itself' Jun 24 11:45:33 i didnt debate that :) Jun 24 11:45:45 i just said that generally u-boot is SPL by design Jun 24 11:46:13 My contention is that u-boot is an operating environment that neither knows nor cares where it's loaded. Jun 24 11:46:24 that we deal with the special case of omap doesnt change that fact Jun 24 11:46:26 It could be PPL and be happy. Jun 24 11:47:00 (rom -> uefi -> grub -> linux -> u-boot, for example) Jun 24 11:47:13 well Jun 24 11:47:23 you could: rom -> linux Jun 24 11:47:30 that doesnt make the kernel an SPL :) Jun 24 11:47:31 Sure. Jun 24 11:47:35 Yes it does. Jun 24 11:47:44 for that particular case, yeah Jun 24 11:47:48 but not generally Jun 24 11:47:56 I don't happen to think it's a particularly *good* SPL today. Needs *lots* of work. Jun 24 11:48:00 But some folk use it that way. Jun 24 11:48:10 if you talk to linus you wont talk about his coll SPL Jun 24 11:48:18 *cool even Jun 24 11:48:31 So, I agree that u-boot is often used as SPL. I'm just arguing that there isn't anything about u-boot design that makes it especially suited for that role. Jun 24 11:48:57 apart from its design as SPL you mean ? Jun 24 11:48:59 *g* Jun 24 11:49:12 I might, actually. I happened to be discussing boot loaders last time I was in the same room as Linus (although not with him) Jun 24 11:49:42 thats something else Jun 24 11:49:57 So, what about the u-boot design allows it to even *tell* in which layer it's running? Jun 24 11:50:02 you could discuss u-boot as rootfs with wolfgang Jun 24 11:50:03 I believe it can't. Jun 24 11:50:13 wouldnt change its default purpose Jun 24 11:52:36 So, I just looked at the u-boot design documentation. It explicitly lists several different use cases, and completely fails to mention anywhere at which point it belongs in the boot process. Jun 24 11:53:13 But I also don't care enough to keep banging on the difference between "some" and "any" in specific application to bootloader purposes any longer. Jun 24 11:54:16 On the other hand, I completely fail to understand the point of x-loader: u-boot is claimed to support devices with 128K RAM. Does OMAP really not have that much on startup? Jun 24 11:56:05 i think its half of it, not 100% sure Jun 24 11:56:23 64K!!!!! Jun 24 11:56:38 but even if you had 128 ... Jun 24 11:56:58 you would have to rip out many important features from u-boot to make it fit Jun 24 11:57:19 especially the hush shell support adds a lot Jun 24 11:57:25 If I'm using u-boot as an SPL and loading a real boot loader (e.g. grub), that's fine :) Jun 24 11:57:30 without it we lose .scr support Jun 24 11:57:36 That's fine. Jun 24 11:57:41 no, its not Jun 24 11:57:52 you would have to recompile to change the cdmline Jun 24 11:58:03 Why not? .scr support is just a dirty hack we tossed together because we didn't have a good bootloader. Jun 24 11:58:11 no Jun 24 11:58:19 No you wouldn't, because your TPL would set it dynamically. Jun 24 11:58:21 its a design feature of u-boot Jun 24 11:58:45 nothing we put together at all Jun 24 11:58:48 we just use it Jun 24 11:59:41 You and I are using different definitions of "we" here. Jun 24 11:59:57 we as people in this chatroom :) Jun 24 12:00:02 (awake or not) Jun 24 12:00:29 scr support comes from upstream Jun 24 12:01:08 anyway, your u-öboot would be pretty limited if you would have to fit it in 128k Jun 24 12:01:14 I'm not willing to assert that nobody who occasionally follows #ubuntu-arm works on u-boot upstream, but we're off-point. Jun 24 12:01:22 Right, which is *fine* if I'm using it as SPL. Jun 24 12:01:30 As long as I have a capable TPL. Jun 24 12:01:40 define capable :) Jun 24 12:01:58 apparently linux isnt capable as TPL in the omap case Jun 24 12:02:26 as long as x-loader is needed to actually initialize subsystems like usb Jun 24 12:02:39 Can detect attached bootable media, and dynamically generate command lines (perhaps based on on-disk configuration) to load QPL from that media. Jun 24 12:03:08 The problem there is that x-loader isn't a good enough SPL to get things working. Jun 24 12:03:13 only if x-loader is your SPL :) Jun 24 12:03:25 wrong way round :) Jun 24 12:03:31 Due to long history of using xloader + u-boot, bring-up patches were randomly distributed between the two. Jun 24 12:03:48 x-loader is abused for initializing bots the kernel should initialize Jun 24 12:03:54 *bits Jun 24 12:04:06 not two ... sadly three Jun 24 12:04:16 So, every image should probably reinitialise everything. Not doing so is likely a bug. Jun 24 12:04:17 x-loader, u-boot and kernel Jun 24 12:04:28 image ? Jun 24 12:04:41 executable image that is loaded. *PL. Jun 24 12:04:54 stage :) Jun 24 12:05:33 but you dont need to initialize everything ... Jun 24 12:05:36 So, I accept that all FPLs must suck, by design. Jun 24 12:05:53 x-loader only needs ram and the device it pulls the bootloader from Jun 24 12:05:58 I want my SPL to turn on all my hardware. Jun 24 12:06:16 which as i said above should actually be the job of the rom Jun 24 12:06:18 I want my TPL to use that hardware to figure out how to boot. Jun 24 12:06:30 And I want my QPL as my default operating environment. Jun 24 12:06:40 I just don't happen to like the current SPL and TPL. Jun 24 12:06:56 persia: Note that u-boot is being used increasingly as a SPL rather than the reverse -- but split in two stages Jun 24 12:06:59 they can be merged though Jun 24 12:07:12 lool, Hrm? So *both* SPL and TPL? Jun 24 12:07:32 yes Jun 24 12:07:47 with different configs Jun 24 12:07:51 Right. Jun 24 12:08:16 I should have said that u-boot is seeing increased use as a TPL, rather than saying it was seeing decreased use as SPL. Jun 24 12:08:50 it takes some efforts to bring u-boot down to a size where it can be used as SPL Jun 24 12:09:10 there are also various platform specific things which prevent it; secure boot is one example :-/ Jun 24 12:09:19 * persia vaguely wonders if the sequence "F, S, T, Q, P" has ever been used for cardinality before, considering that it doesn't match *anything* Jun 24 12:09:56 How does secure boot prevent u-boot as SPL? Can't one just sign some known perfect SPL u-boot? Jun 24 12:10:58 there are many reasons; first, basing on u-boot has less advantages since other people can't necessarily deploy it Jun 24 12:10:59 Or is it that the secure boot implementation must necessarily be the SPL? Jun 24 12:11:04 second, the GPL is a problem for some people Jun 24 12:11:24 third, the secure boot bits are often developed in R&D before considering u-boot Jun 24 12:11:30 Oh, right. Depending on the IP involved in the secure boot mechanism... Jun 24 12:12:41 Now, you suggested UEFI as SPL: does that address any of these aside from the GPL issue? Jun 24 12:13:00 persia: If you're interested, we've started some long term boot architecture discussion on the boot-architecture@llo list and on weekly calls Jun 24 12:13:57 I'm interested, but I'm not sure I can dedicate that much time. My opinions are mostly driven by user experience, but I think those are shared widely enough that repetition in that forum won't help. Jun 24 12:14:43 Although I'm glad to know it's happening, and will likely browse the ML archives once in a whle. Jun 24 12:15:59 So by UEFI I don't mean one specific implementation of it; we'd likely focus on tianocore ourselves for some boards, but each vendor could provide other compatible implementations Jun 24 12:16:16 they could even be basaed on GRUB, albeit that's extremely unlikely Jun 24 12:16:23 Heh, indeed. Jun 24 12:16:47 From prior exposure, I just thought that UEFI tended to be large, which might cause some of the same issues as for u-boot as SPL. Jun 24 12:19:27 Ah, so the goal of the boot architecture discussions is to have some spec that clearly separates IHV and OSV roles. I *really* like that. Jun 24 12:20:21 And I completely agree that it makes sense to *not* specify specific payloads, etc., but rather just specify how the payload is accessed. Jun 24 12:20:36 s/specific/particular/ Jun 24 12:28:18 * ogra sighs about firefox in oeniric Jun 24 12:29:28 oh, sweet Jun 24 12:29:39 * ogra likes software-center Jun 24 12:29:50 ogra: ? Jun 24 12:30:08 i didnt know it asks you if it should add a new app you install to the launcher Jun 24 12:30:17 nice Jun 24 12:30:22 what about firefox? Jun 24 12:30:39 and while the app installs you can read reviews Jun 24 12:30:51 its slow, clunky and leaks memory Jun 24 12:31:30 i'm just installing chromium ;) Jun 24 12:31:54 heh Jun 24 12:32:02 I have been using chromium on my tab Jun 24 12:47:47 After a while, my usb mouse stop working on ubuntu-arm installed on beagleboard c3, any suggestions? Jun 24 12:50:00 kunguz, Is there anything associated with it stopping? Anything in the syslog? Changes in /dev/input/*, etc.? Jun 24 12:50:56 persia: actually on the serial port, there is no output from beagleboard and I can not use any other device. Jun 24 12:51:38 persia: I can check the mmc card on other computer for the syslog Jun 24 12:53:42 kunguz, That sounds like a system freeze to me, rather than just the USB mouse stopping. Why do you suspect the USB mouse? Jun 24 12:54:10 persia: the same thing happend during the installation but the installation proceeded and completed with success Jun 24 12:54:55 persia: for example if I wait long enough the system shows a blank screen saver Jun 24 12:55:10 OK. Do you have any other input devices (keyboard, etc.)? Jun 24 12:55:22 persia: only mouse at this moment Jun 24 12:55:29 Nothing happening on the serial port is normal. Jun 24 12:55:39 and an unrecognised wireless adapter Jun 24 12:55:52 Hrm. Debugging one's only input device is tricky :) Jun 24 12:56:24 persia: now I am trying to reboot it only with an USB mouse attached. Jun 24 12:57:15 persia: by the way I am using an usb hub Jun 24 12:57:38 persia: so to say only devices attached are screen, an usb hub and an usb mouse. Jun 24 12:57:39 That makes it more likely to work :) Jun 24 12:59:11 and in my beagleboard it takes like 5 min. to open the whole system Jun 24 12:59:28 Which image are you booting? Jun 24 13:00:07 persia: http://cdimage.ubuntu.com/releases/11.04/release/ubuntu-11.04-preinstalled-netbook-armel+omap.img.gz Jun 24 13:00:10 this one Jun 24 13:00:40 Ah. The only reason I boot that on my beagle is to remove lots of stuff. I really doesn't perform very well with that little RAM. Jun 24 13:00:45 (I also have a C3) Jun 24 13:01:08 persia: is there a lubuntu-arm available? Jun 24 13:01:15 Try http://cdimage.ubuntu.com/releases/11.04/release/ubuntu-11.04-preinstalled-headless-armel+omap.img.gz Jun 24 13:01:32 persia: gnome is a bit too much for beagleboard Jun 24 13:01:39 persia: what is this headless? Jun 24 13:01:41 I don't know of such an image. If you install headless, you can `apt-get install lubuntu-desktop` Jun 24 13:01:53 persia: oh i see thank you very much Jun 24 13:01:56 It's a minimal image, so you can install just the stuff you want. Jun 24 13:02:12 persia: that looks nice, so I am trying it Jun 24 13:02:55 you better install the task though Jun 24 13:03:03 Good luck. I don't consider this to be a step towards debugging your USB mouse issue (if you have one), but I don't think we *can* usefully debug it with no keyboard and such sluggishness. Jun 24 13:03:12 sudo tasksel install ubuntu-desktop Jun 24 13:03:16 or so Jun 24 13:03:29 ogra: task? Jun 24 13:03:31 Or lubuntu-desktop, rather, in this case :) Jun 24 13:03:37 or that Jun 24 13:03:43 ogra: ok I am trying Jun 24 13:03:44 But I don't think lubuntu-desktop has a task for natty. Jun 24 13:03:56 Better to use apt-get and install the metapackage in this special case. Jun 24 13:03:57 no, lubuntu was just added as a task today Jun 24 13:04:04 so its only in oneiric Jun 24 13:04:14 Right. The meta landed in maverick, I think. Jun 24 13:04:19 yep Jun 24 13:04:30 well, indeed, in this case the package is better Jun 24 13:05:19 In general, it's better to use tasks. Jun 24 13:43:01 persia: http://www.sudrap.org/paste/text/14408/ , that's what keeps happening when usb failes Jun 24 13:43:28 Oh, excellent! Jun 24 13:44:09 File a bug. Be sure to include specifics about your hub and mouse. lsusb -vv output is probably helpful. Jun 24 13:45:09 When I have issues like that, I generally try to change my USB routing (move devices and hubs around, swap hubs, etc.). That said, I've never seen that on my beagle, so it may be something different than the issue I work around. Jun 24 15:07:48 Hi, i've ubuntu 11.04 headless installed in my pandaboard. It can play correctly sound but if i record, the file will contain only mute sound. I know there is an issue about alsa, thre is a way to get arecord run correctly? Thank you Jun 24 15:08:39 I sownloaded and compiled latest stable packages of alsa Jun 24 15:08:43 *downloaded Jun 24 15:10:06 did you read the bug i pointed you to ? Jun 24 15:10:27 yep ogra Jun 24 15:10:41 so you are using an mp3 player as input ? Jun 24 15:10:53 and have enabled the Record verb ? Jun 24 15:11:07 as described in the bug Jun 24 15:11:15 and it still doesnt work ? Jun 24 15:11:19 sorry for paste Jun 24 15:11:22 sudo alsaucm set _verb HiFi sudo alsaucm set _verb Record sudo rm /var/lib/alsa/asound.state sudo reboot Jun 24 15:11:40 nope for mp3 player Jun 24 15:11:41 right, that enables all driver bits Jun 24 15:11:46 i do it now Jun 24 15:11:58 the input is wired as line in ... mics wont work Jun 24 15:12:12 ok thank you ogra Jun 24 15:12:40 i'll try with an mp3 player Jun 24 15:12:49 note that you might have overwritten alsa stuff with your self compiled stuff now Jun 24 15:12:50 and a male/male 3.5 cable Jun 24 15:13:05 ah Jun 24 15:13:44 so no guarantee it still works :) Jun 24 15:13:53 if it will not works with mp3 player i will reinstall from zero Jun 24 15:14:17 aplay sounds good Jun 24 15:14:51 ogra: is there some route must be enabled with alsamixer? Jun 24 15:14:54 to record i mean Jun 24 15:15:04 no Jun 24 15:15:19 ok Jun 24 15:15:21 the defaults should just work after you issued the two alsaucm commands Jun 24 15:15:29 ah ok Jun 24 15:15:34 they do for everyone else at least Jun 24 15:15:46 but maybe not for me Jun 24 15:15:52 though you said you are using headless, not sure how well that works without pulse in the loop Jun 24 15:16:07 ok Jun 24 15:16:11 we only test such stuff on the desktop/netbook images Jun 24 15:16:17 so maybe i can try to install pulse too Jun 24 15:16:43 pulse on your repo Jun 24 15:17:02 http://people.canonical.com/~ogra/natty-omap4-pulse/ Jun 24 15:17:50 no Jun 24 15:18:04 thats outdated testing crap Jun 24 15:18:09 ah ok Jun 24 15:18:14 the pulse in the archive works just fine Jun 24 15:18:20 ok thank you ogra Jun 24 17:48:18 apachelogger: I hear you have an iMX53 Quickstart that does fancy things like boot? Jun 24 17:50:18 yes Jun 24 17:51:08 apachelogger: Did you use the provided Ubuntu-esque micro-SD from Freescale, or did you have to homebrew something to make it work? Jun 24 17:51:30 infinity: https://wiki.ubuntu.com/ARM/iMX53QuickStartBoard Jun 24 17:52:05 apachelogger: Yeah. I've been pointed to that. Was curious if anyone's booted one with the SD Freescale is now shipping. Jun 24 17:52:08 FWIW the default microsd image did not manage to bring up VGA for one reason or another Jun 24 17:52:17 apachelogger: But I guess I'll try the crazy homebrew method. Jun 24 17:52:20 I replicated the image and it worked Jun 24 17:52:27 which is also pretty simple Jun 24 17:52:48 just get the image tar.gz from freescale and follow the guide that is shipped inside the tar Jun 24 17:52:53 apachelogger: Not bringing up VGA, I'd be okay with, but the default image doesn't seem to give me serial either, so I have no way of knowing if it's doing... Anything. Jun 24 17:53:20 well, recreating the image definitely works Jun 24 17:53:28 Kay. Jun 24 17:53:54 infinity: http://i.imgur.com/WTJbh.jpg Jun 24 17:54:02 Where do I get this freescale tgz? I only see linaro links on the wiki. Jun 24 17:54:03 that is running the ubuntu image Jun 24 17:54:15 infinity: freescale's quickstart board site Jun 24 17:54:19 there is a downloads section Jun 24 19:07:51 apachelogger, So, one potential candidate for what is "wrong" with the 2.6.38 image is that the 2.6.35 kernel is a BSP kernel, and has *all* the patches, whereas the 2.6.38 kernel is a targeting-mainline kernel, and so doesn't have as many ugly hacks. Jun 24 19:17:32 persia: that adds kernel patch issues to the list of possible causes for not working EGL init :S Jun 24 19:18:27 Indeed. So, Quintasan was talking with paulliu about stuff, and paulliu is working on linux-linaro-lt-mx5, which is 2.6.35 Jun 24 19:19:04 But the shiny is linux-linaro-mx5, which is 2.6.38 Jun 24 19:19:38 The *lt* kernels aren't in Ubuntu, and aren't likely to be. Jun 24 19:43:35 persia: I see **** ENDING LOGGING AT Sat Jun 25 02:59:57 2011