| sveinse | What can be done to speed up booting in Precise? Point is, we have an embedded product running on OMAP3, w/display, and running non-X Qt graphics (QWS). Booting takes around 30-40 seconds, which is far too long. So we need to reduce it. So in general we can either optimize precise boot or we have to change distro to something more lean. | 06:55 |
|---|---|---|
| sveinse | Much of the boot is scripts and initramfs and all those generic checks made during boot. And the boot is mostly io bound, because the machine is running off an SD-card which isn't too fast | 06:56 |
| ogra_ | sveinse, make sure your kernel supports ureadahead ... use bootchart to identify slow processes on boot | 07:37 |
| sveinse | ogra_: I have used bootchart to ploy, and there is something like 100 processes/scripts before our apps start loading. | 07:57 |
| sveinse | ogra_: for the ureadahead, I've been told (here) that ARMv7 does not support ureadahead. At least I get a failure for it while booting | 07:58 |
| ogra_ | you need a kernel patch | 07:58 |
| ogra_ | it works fine on all arm arches and helüps quite a lot | 07:59 |
| sveinse | ogra_: Where can I find this patch? | 07:59 |
| * ogra_ isnt sure if bug 1194127 has a direct link | 08:00 | |
| ubot2 | Launchpad bug 1194127 in linux-manta (Ubuntu Saucy) "ureadahead does not work in current linux-maguro/linux-mako/linux-manta" [High,Fix released] https://launchpad.net/bugs/1194127 | 08:00 |
| ogra_ | try to find this one on kernel.ubuntu.com iirc the changelog entry comes from git | 08:01 |
| ogra_ | https://lists.ubuntu.com/archives/kernel-team/2009-October/007712.html | 08:02 |
| sveinse | ogra_: We running on precise because this is LTS. Would there be any advantages speedwise to change to a newer distro version? | 08:03 |
| sveinse | I mean, I supporse the ARM support has matured since precise | 08:03 |
| ogra_ | we had a big performance review of arm stuff in quantal ... so yes, you might see some speedups ... but OTOH the support for non LTS is only 9 months nowadays | 08:05 |
| sveinse | Will 14.04 will be LTS? | 08:06 |
| ogra_ | yep | 08:09 |
| sveinse | _ogra: Thanks | 08:26 |
| abhishek_ | ppisati: Hi | 08:50 |
| abhishek_ | ppisati: I was looking for you and want to ask something related to page https://wiki.ubuntu.com/KernelTeam/ARMKernelCrossCompile | 08:50 |
| abhishek_ | ppisati: I have downloaded the Ubuntu-quantal source code and later I did git checkout -b temp Ubuntu-3.4.0-1.1 to move to branch 3.4 | 08:52 |
| abhishek_ | I want to build the Ubuntu for the APQ8064 | 08:52 |
| abhishek_ | there is a support for the ti-omap4, but I wan to build for the qualcomm APQ8064 ..... | 08:54 |
| abhishek_ | ppisati: Can you please help me how should I proceed | 08:54 |
| abhishek_ | ppisati: to get omap4 ...I did git checkout -b ti-omap4 origin/ti-omap4 | 08:55 |
| abhishek_ | ppisati: But, how should I get a support for the qc-apq8064 ......or how can I create the same\ | 08:55 |
| abhishek_ | ppisati: Please help me sir .....I will not take much of your time | 08:58 |
| ppisati | too quick | 09:14 |
| ppisati | or maybe i was too late... :) | 09:14 |
| ppisati | abhishek_: two things: | 09:15 |
| abhishek_ | ppisati: I lost the connection to this | 09:15 |
| ppisati | 1) first check that the kernel version you checked out support your chip | 09:15 |
| abhishek_ | ppisati: I might have missed your earlier messges | 09:15 |
| abhishek_ | ppisati: ok | 09:16 |
| ppisati | 2) then copy the debian.omap4 branch and make all the modifications related to your chip | 09:16 |
| abhishek_ | ppisati: How to find that that the kernel downloaded by me is supporting the chip ?? | 09:17 |
| abhishek_ | ppisati: In arch/arm/configs | 09:17 |
| ppisati | abhishek_: since it's a normale kernel after all, check in arch/arm/* | 09:17 |
| ppisati | and so on | 09:17 |
| abhishek_ | ppisati: ok | 09:18 |
| abhishek_ | ppisati: in arch/arm/mach-apq8064 is not present .....but mach-msm is present | 09:19 |
| ppisati | abhishek_: if you try a make ARCH=arm menuconfig | 09:19 |
| ppisati | check than your soc is there | 09:19 |
| ppisati | *that | 09:19 |
| abhishek_ | Qualcomm MSM is present ...but not Qualcomm APQ8064 | 09:21 |
| ppisati | than you first should try to compile a kernel the normal way | 09:21 |
| ppisati | adding stuff for your chip | 09:21 |
| ppisati | and when you have a stable config, come back | 09:21 |
| abhishek_ | So, I will compile the kernel for the qualcomm MSM ...... | 09:22 |
| ppisati | abhishek_: and you need to boot it too | 09:22 |
| abhishek_ | If I want to add stuff for my chip ....what needs to be changed | 09:22 |
| ppisati | the config | 09:23 |
| abhishek_ | ppisati: How the kernel compiled for the different SOC will boot up ? | 09:23 |
| ppisati | dude, first get familiar with compiling and booting a new kernel on your board | 09:23 |
| abhishek_ | the config in arch/arm/config/apq8064_defconfig | 09:23 |
| abhishek_ | I have already done this activity | 09:23 |
| abhishek_ | I have compiled the kernel for x86 also .....and changed by desktop kernel also | 09:24 |
| abhishek_ | *my | 09:24 |
| abhishek_ | ppisati: What else needs to be changed | 09:26 |
| abhishek_ | Hi Lee | 09:28 |
| abhishek_ | lag: I want some help for the kernel configuration for SoC Qualcomm apq8064 | 09:29 |
| === doko__ is now known as doko | ||
| abhishek_ | I have downloaded ubuntu-quantal ....but this kernel has no support for my SoC ....what I need to change to support my SoC | 09:30 |
| abhishek_ | Please help me | 09:43 |
| wookey | If I try to build debian packages in an ubuntu chroot, what sort of things tend to go wrong? | 12:57 |
| wookey | I need to nobble dpkg-vendor | 12:57 |
| wookey | what eles? | 12:57 |
| wookey | dch does the wrong thing | 12:58 |
| doko | wookey, edit base-files | 13:01 |
| doko | lsb_release -a should work | 13:03 |
| infinity | wookey: base-files and dpkg should be the only two things required to turn Debian into Ubuntu and vice versa. | 15:17 |
| wookey | dpkg? because it encodes teh dpkg-vendor answer in the build? | 15:58 |
| wookey | I'd naively assumed I could change that in a config file somewere | 15:58 |
| infinity | wookey: Mangling /etc/dpkg/origins should be enough to switch dpkg. | 16:07 |
| infinity | wookey: And then /etc/lsb-release and /etc/os-release for base-files. | 16:07 |
| infinity | wookey: I can't think of anywhere else that people query to determine what sort of system they're on. | 16:07 |
| infinity | wookey: Of course, toolchain defaults will differ unless you rebuild those. So, if the goal is to bootstrap Debian from Ubuntu, or Ubuntu from Debian, as soon as you mangle dpkg and base-files, the first order of business is to build your toolchain. | 16:08 |
| infinity | (Can you tell I've done this before...) | 16:09 |
| wookey | that's good. I was oping to find someone who'd done this before to stop me wasting a lot of very slow model time | 16:33 |
| infinity | wookey: Well, I did it in the other direction with armhf, since Debian started that before us. So, I'd do arm64 in exactly the other direction and it should work well. | 16:34 |
| infinity | (Well, as well as anything can work on a model...) | 16:34 |
| infinity | wookey: I assume you'll be in Santa Cruz? | 16:34 |
| infinity | Err. | 16:34 |
| infinity | Clara. | 16:34 |
| wookey | yes | 16:34 |
| infinity | Santa something. | 16:34 |
| wookey | next question. presumably it's unwise to adulterate my working ubuntu build chroot by jamming just-build debian packages in | 16:35 |
| wookey | and I should make another one for that purpose | 16:35 |
| wookey | so I can go back when it breaks | 16:35 |
| infinity | Going back is for wimps. | 16:35 |
| infinity | And you can always debootstrap a new one. :) | 16:35 |
| infinity | But the goal is to evolve into Debian, so you *want* to be installing your just-built packages. | 16:35 |
| infinity | Once everything in your chroot as become Debian versions, then you get to rebuild them all AGAIN, and be fairly confident that you're no longer building against Ubuntu. | 16:36 |
| wookey | yes, i realise that :-) but I was expecting something bad to break | 16:36 |
| infinity | s/as/has/ | 16:36 |
| infinity | I wouldn't expect much world breakage in taking that approach. | 16:36 |
| wookey | I guess I should just save the base chroot for emergencies | 16:36 |
| wookey | debootstrap is easy but the settign up of keys and dupload configs and nobbled dpkg etc is a faff I don;t want to repeat to many times | 16:37 |
| infinity | Luckily, since the autosync, trusty and sid are pretty dangerously similar, so it shouldn't be too, too bad. | 16:37 |
| wookey | easpicially as it's all so gloriously slow | 16:37 |
| wookey | ah, and actualy the keys and stuff is in my $home so that's OK | 16:37 |
| wookey | did you use a snapshot to avoid undue churn, or just stick with 'latest' in both? | 16:38 |
| infinity | No snapshotting, though we did start when saucy was mostly frozen, which helped a bit. | 16:38 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!