Date: Wed, 21 Feb 2018 17:25:01 -0800 From: bob prohaska <fbsd@www.zefox.net> To: Ian Lepore <ian@freebsd.org> Cc: George Rosamond <george@ceetonetechnology.com>, freebsd-arm@freebsd.org, bob prohaska <fbsd@www.zefox.net> Subject: Re: Custom kernel for RPi2 and 3 Message-ID: <20180222012501.GA1313@www.zefox.net> In-Reply-To: <1519242042.91697.116.camel@freebsd.org> References: <20180220161900.GA2345@www.zefox.net> <c1a82728-a6cd-c972-9b54-73baca644528@zyxst.net> <20180221051801.GA73510@www.zefox.net> <d1e2036f-fb9e-71fa-0918-8b904f16a807@ceetonetechnology.com> <1519229812.91697.61.camel@freebsd.org> <20180221181518.GA696@www.zefox.net> <1519242042.91697.116.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Feb 21, 2018 at 12:40:42PM -0700, Ian Lepore wrote: > On Wed, 2018-02-21 at 10:15 -0800, bob prohaska wrote: > > On Wed, Feb 21, 2018 at 09:16:52AM -0700, Ian Lepore wrote: > > > > > > That script looks like a really complicated way to do: > > > > > > ? make showconfig __MAKE_CONF=/dev/null SRCCONF=/dev/null > > > > > > -- Ian > > Is there a straightforward way to sort what's being used from what > > can't (or isn't) being used? For example, on a Pi2 the command emits > > MK_WIRELESS??????= yes > > MK_WIRELESS_SUPPORT = yes > > Given that there's no onboard wireless and no USB WiFi adapter, it's > > fairly obvious those two can be set to "no". It's less clear what? > > MK_TEXTPROC??????= yes > > portends, and whether it's essential. > > > > Perhaps I mis-posed the original question. What I'm looking for might > > better be called a minimal kernel configuration supporting only the > > hardware native to a particular board. The old RPI2 kernel config file > > seemed to do that, but I gather it's deprecated.? > > > > Thanks for reading! > > > > bob prohaska > > Well, for starters all the WITH/WITHOUT stuff affects only userland, > not kernel builds. ?So setting WITHOUT_WIRELESS will leave the 'wpa' > program out of the build/installworld, but has no effect on whether any > wireless stuff is compiled in the kernel or modules. > Ok, wrong tree. I'll stop barking 8-) > When it comes to GENERIC kernels and how to slim them down... I should > start by mentioning that I've hated GENERIC kernels going back to 1996 > or so, but at least they made some kind of sense for x86 machines that > all had so much in common with each other. ?For ARM I think the concept > is somewhere between useless and actively harmful. ?I seem to be pretty > much alone in thinking so. ?If we ever get to the point where a generic > kernel can contain almost nothing in the way of options and drivers, > and the right modules can be dynamically loaded during boot as needed, > that would be useful. That sounds rather ambitious, but certainly desirable. In the meantime there's a lot to be said for a "boot it and it will run" setup, especially for first timers. > > So about the only way to make a custom slim kernel these days if your > platform is based on GENERIC is create a custom config file, include > GENERIC, then write a series of nooption and nodevice statements that > turn off all the stuff you don't want. ?That ensures that if new > required stuff gets added in the future, you'll pick it up. ?It also > ensures that when new stuff you don't need gets added, you'll also get > burdened with all of that. ?Given that an arm generic kernel contains > all the stuff needed by every arm SoC, it's a pretty good bet that > almost everything added to generic in the future will be things you > don't need, and on every update you'll have to examine it looking for > what got added that you now need new nooption/nodevice statements for. > > There's no good way to figure out what you need and what you don't > other than to read GENERIC line by line, hoping that the comments (when > they exist at all) give you enough of a clue about whether you need > that line. ?Sometimes you need to look in sys/arm/conf/NOTES and in > sys/conf/NOTES to find the info on what a given device or option is. > That's essentially what I tried, sans the consultation of the various NOTES. I just grepped the dmesg output for the first-column terms in GENERIC that seemed unrelated to Rpi. If they weren't in dmesg output I commented them out. Then I tried make buildkernel. The compiler errors were usually pretty good at indicating what I had to uncomment, though in a few cases it was guesswork. Once the compile completed the resulting kernel booted and ran, but it was still rather large : bob@www:~ % ls -l /boot/kernel/kernel -r-xr-xr-x 1 root wheel 9410680 Feb 20 23:23 /boot/kernel/kernel That compares to bob@www:~ % ls -l /boot/kernel.old/kernel -r-xr-xr-x 1 root wheel 10912668 Feb 17 13:23 /boot/kernel.old/kernel On a Pi2 running stable/11 using the RPI2 config one sees bob@www:~ % ls -l /boot/kernel/kernel -r-xr-xr-x 1 root wheel 8037808 Feb 20 21:37 /boot/kernel/kernel I'm quite astonished at how little reduction in kernel size was achieved. I'll post the config file if anybody wants to look at it. If I'm being unrealistic please say so, but memory constraints, at least on the Pi3, look imminent. Thanks for reading! bob prohaska
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180222012501.GA1313>