Continue the poky-tiny work, paring down the kernel and rootfs even further.
At the direction of the triage team, closing this large placeholder bug.
From a previous discussion on the subject, it was decided to merge the current microYocto work into poky-tiny, as poky-tiny is meant to represent the smallest-possible-footprint distro, and having multiple permutations such as poky-micro and poky-tiny, even if layered, would be too confusing for users. So basically the task is to merge the microYocto work: https://github.com/tzanussi/meta-galileo https://github.com/tzanussi/linux-yocto-micro-3.14 into poky-tiny. Note that the above is still a work in progress.
I'm not sure how I can help with this. Both projects mentioned above look outdated and they look like a work for kernel maintainers.
Per Jessica; Tom should roll this into poky-tiny when applicable.
This was REOPENED
*** Bug 9428 has been marked as a duplicate of this bug. ***
I think that we need make it at least support qemux86-64 and other x86_64 bsps in yocto.
Updating to reflect the most recent 'microLinux' kernel update, for 4.1. This README is the starting point for anyone wanting to build and boot it on actual hardware: https://github.com/tzanussi/meta-microlinux/blob/jethro/README It's part of the 'meta-microlinux' layer which ties together the microlinux 4.1 kernel with jethro along with a rudimentary userspace tailored to the kernel. The most important parts of this layer are the toolchain changes making use of a special binutils for LTO, a poky-micro distro config, and the kernel recipes that tie into the linux-yocto-4.1 metadata to create the smallest possible kernel using the kernel features added for microLinux. https://github.com/tzanussi/meta-microlinux/tree/jethro It supports galileo2 and minnowmax-64, but the latter is untested for jethro/4.1. Most of the patches aren't machine-specific, but the focus was on getting the smallest possible kernel running on galileo2, so that's what was tested, and we never got to other machines before the end of the project. The kernel repos are here: This is the kernel cache containing all the microlinux config fragments: https://github.com/tzanussi/yocto-kernel-cache-micro/tree/yocto-4.1 And this is the kernel repo itself, containing numerous topic branches that get pulled together by the metadata: https://github.com/tzanussi/linux-yocto-micro-4.1 This is the commit in the meta-microlinux layer that shows what the kernel size was at the point Pali ended: https://github.com/tzanussi/meta-microlinux/commit/e8de6b1677dc43d69451f5177ca631682ba6b9cf Basically, this is where we were at at that point: At this point, SMALLEST is: Memory: 235636K/245176K available (455K kernel code, 61K rwdata, 64K rodata, 132K init, 56K bss, 3056K reserved, 0K cma-reserved) virtual kernel memory layout: fixmap : 0xfffe5000 - 0xfffff000 ( 104 kB) vmalloc : 0xd05f0000 - 0xfffe3000 ( 761 MB) lowmem : 0xc0000000 - 0xcfdf0000 ( 253 MB) .init : 0xc1094000 - 0xc10b5000 ( 132 kB) .data : 0xc1071fac - 0xc1092760 ( 129 kB) .text : 0xc1000000 - 0xc1071fac ( 455 kB) Basically, this is a collection of patches contained in a set of topic branches as described below, with comments: * lto: - Patchset from Andi Kleen enabling LTO in the kernel build and fixing a whole set of related things when LTO is enabled. Not upstream but seems fairly clean and is one of the most important single features for getting the overall size down, systemically. - requires special binutils branch and toolchain changes * net-diet: - Another one of Andi Kleen's patches, every one of which was nak'ed by net maintainer (who nak's any tinifiication patch on principle). Another big win in terms of size, with well-defined options for turning various things off, but some of which require userspace changes. * tinification: - Josh Triplett's collection of tinification patches. - various syscall removal patches, factoring out things not really required for certain options - perf disabling/hw breakpoints patches - was in linux-next, but removed recently * staging: - various patches of mine - dev/mem patches, upstream-ready and posted, but abandoned after Ted Tso naked them on security grounds - proc-min patches, which work for my microLinux 'distro', but hard sell because it would require picking and choosing proc files to remove unconditionally vs conditionally, and would introduce gobs of config items - splice system call disabling, both mine and another separate independent version - other smaller patches in various stages of readiness * tracing: - my hist triggers patchset, ported to 4.1, for now - function_hist patches, for autogeneration * xip: - xip patches and fixes, ran on galileo through start_kernel(), but no further due to interrupt starvation. Not useful unless the hardware is fast enough to do xip. * standard/micro/galileo: - galileo-specific patches not upstream yet * standard/micro/minnowmax-64: - minnowmax-64-specific patches not upstream yet * standard/micro/minnowmax: - minnowmax-32-specific patches not upstream yet
*** Bug 9429 has been marked as a duplicate of this bug. ***
Created attachment 3408 [details] Current tiny snapshot
About the 'Current tiny snapshot': Included in the tarball is a README.tiny.build that explains in detail how to apply all the patches and get a successful build that will successfully boot on a Galileo2 board. You need to follow the instructions at the end exactly in order to get a good build. The need for those instruction is one of the things that needs to be fixed. Below is a more complete list - most of these things are just build-system issues that I didn't have time to dive into, instead focusing on the core problem of getting LTO to work and putting things into a position where a lot more progress can now be made on further paring down. Doing just the initial amount of paring down I was able to do saved about 4 Mb in image size. From the kernel build directory, you can get a total size output for the entire kernel build including vmlinux and modules by running a new script from there: scripts/tiny/ksum.py This is helpful to do after you've made changes and want to compare total before and after sizes. Technically, you don't need the above script if you completely disable modules, which is actually one thing you should really be doing for a tiny configuration, but if you don't, that will account the module sizes as well. With the current state of things, you should now be able to make real progress in paring the kernel down, which I'll continue doing. I actually did a lot of this for 4.1, and you can find all the details of those changes here: https://github.com/tzanussi/meta-microlinux/blob/jethro/README I expect that once the build-system problems are fixed and the baseline is merged, you can make a lot of progress by looking at the above repos. As to the current issues with the tarball here, here they are: - In the instructions, I give a specific commit in poky-contrib/zedd/kernel for poky - when I tried using master I got a parse error when building the kernel. I pinged Bruce about it but he couldn't reproduce it, so it remains where it is for now. - There's a problem building the core-image-tiny-initramfs image - I get a build error unless I first build core-image-minimal-initramfs for some reason. But it builds fine if you do things in the order I specified in the README. - In order for LTO to work for the kernel, it requires a modified binutils called 'Linux binutils' which you can read about in the kernel LTO patches. Things work fine if I use the 2.24 tarball and that's what's used in the meta-intel binutils recipe (because it's old I had to fix up, remove, and add some patches to work with gcc 6.2) but we should really be able to use e.g. the 2.27 Linux binutils branch from the binutils repo instead. I tried doing that many times but was never successful, and I'm still not sure whether that was the fault of the binutils branch, or whether that was because of a wrong setup in the build system (I see the same internal errors if I accidentally enable LTO with the normal binutils) so it's not clear to me how to update things to a newer binutils. In any case, we have something that works so can make progress. - In any case, regardless of version, the build requires a different binutils for the kernel and and the overall build. The 'Linux binutils' version should be used only for the kernel during the build and the regular binutils for everything else. It was on my todo list and I briefly looked around for how to do it, but basically it boils down to having a recipe-specific toolchain specification for a single recipe, and while there are examples out there, I was leaving it to the end to actually play around with what would have been a huge time sink for me, and focused on things I could make more progress on instead. I'm sure a build system expert could figure it out quickly. I can't think of anything else other than cleanup items - there is also the start of an idea of centralizing artifacts so that wic doesn't have to look around in various places, which I implemented here, but that's a bigger topic and I think aligned with work Jianxun was thinking of doing this.
Since this work has mostly been merged, and LTO seems not to work on kernels > 4.4 I will close this bug, if we decide to contine work on LTO and somehow make it work with newer kernels a new bug should be opened.