Re: armel/marvell kernel size
Dear Ian, Ben, On Sun, Apr 15, 2018 at 9:50 PM, Ben Hutchings wrote: > On Sun, 2018-04-15 at 08:16 +0100, Ian Campbell wrote: >> On Sun, 2018-04-15 at 00:08 +0100, Ben Hutchings wrote: >> > > For the lzo_decompress ones I think you need to add it to >> > > installer/modules/lzo-modules and perhaps add one or two more >> > > dependencies based on what the errors are at that point. >> > >> > Let's not introduce more packages. I would be tempted to put it in >> > kernel-image, which all other udeb packages should depend on. >> >> I thought lzo-modules already existed, but perhaps my tree was out of >> date. If it doesn't then you are right that kernel-image would be a >> find choice. > > You're right, I just didn't remember it existing. Thanks for your hints! I also find the thread [0] that had the similar problem before. So I learned how to fix the problem, and now the fix is in master [1] and sid branch on salsa. [0] https://lists.debian.org/debian-kernel/2014/02/msg00341.html [1] https://salsa.debian.org/kernel-team/linux/commit/175171d4 I also find the target binary-arch_armel_real of makefile fails in my cross compiling environment, which is the reason why I couldn't build udeb. There's a workaround for this: $ sed -i 's/binary-arch_armel:: binary-arch_armel_extra binary-arch_armel_none binary-arch_armel_real/binary-arch_armel:: binary-arch_armel_extra binary-arch_armel_none/' debian/rules.gen After that, the udeb command can be built by ($ARCH is armel for my case): $ fakeroot make -f debian/rules.gen binary-arch_${ARCH} Maybe it's kinda dirty hack, but works for me. I also realized that I never used the binary-arch_armel_real target before. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Re: armel/marvell kernel size
On Sun, Apr 8, 2018 at 5:47 PM, Ben Hutchings wrote: > On Sat, 2018-04-07 at 23:38 +0900, Roger Shimizu wrote: >> On Sat, Apr 7, 2018 at 11:16 PM, Roger Shimizu >> wrote: >> > Dear kernel folks, >> > >> > After all kinda tests recently, together with the patch from Leigh >> > Brown (CC-ed) that disabled VT, finally the armel/marvell can be >> > reduced under 2MB again, without introducing a new flavour. >> >> Sorry, I forgot to mention the post that Leigh Brown provided the patch: >> - https://lists.debian.org/debian-kernel/2018/03/msg00223.html >> >> And the patch, reducing armel image size under 2MB, and pushed to >> master branch is: >> - https://salsa.debian.org/kernel-team/linux/commit/a4fdfa09 > > Well done! Dear Ben, Unfortunately, armel FTBFS on buildd due to udeb [0][1]. [0] https://buildd.debian.org/status/package.php?p=linux&suite=experimental [1] https://buildd.debian.org/status/fetch.php?pkg=linux&arch=armel&ver=4.16-1~exp1&stamp=1523350611 Neither the cross build wiki entry [2], nor the kernel handbook [3] mentions how to build udeb. So could you kindly tell me how to confirm the udeb build? [2] https://wiki.debian.org/HowToCrossBuildAnOfficialDebianKernelPackage [3] https://kernel-handbook.debian.net BTW. I think the udeb breaks because I removed RD_BZIP2 and RD_LZMA. So if you know how to fix the config under debian/installer, please kindly help to do. I don't have enough knowledge to touch stuff under that directory. Thank you! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Re: armel/marvell kernel size
On Sat, Apr 7, 2018 at 11:16 PM, Roger Shimizu wrote: > Dear kernel folks, > > After all kinda tests recently, together with the patch from Leigh > Brown (CC-ed) that disabled VT, finally the armel/marvell can be > reduced under 2MB again, without introducing a new flavour. Sorry, I forgot to mention the post that Leigh Brown provided the patch: - https://lists.debian.org/debian-kernel/2018/03/msg00223.html And the patch, reducing armel image size under 2MB, and pushed to master branch is: - https://salsa.debian.org/kernel-team/linux/commit/a4fdfa09 Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Re: armel/marvell kernel size
Dear Rogério, I'll reply to you later, in a separate email. Dear kernel folks, After all kinda tests recently, together with the patch from Leigh Brown (CC-ed) that disabled VT, finally the armel/marvell can be reduced under 2MB again, without introducing a new flavour. So I already pushed the changes to master and sid branch in salsa. qnap support will be back in next debian kernel release. Cheers, Roger On Tue, Apr 3, 2018 at 2:37 PM, Rogério Brito wrote: > Dear Roger, Ben and others. > > On Sun, Apr 1, 2018 at 10:25 AM, Roger Shimizu wrote: >> On Wed, Jan 24, 2018 at 3:30 AM, Ben Hutchings wrote: >>> On Mon, 2018-01-22 at 22:38 +0900, Roger Shimizu wrote: >>> There's an upstream change in cfg80211 that enables direct-loading of >>> wireless rules, which requires public key crypto in the kernel. There >>> doesn't appear to be any option to disable that mode, even though we >>> don't need it because crda still works. Maybe you could disable >>> wireless networking completely? >> >> I finally settled a solution, by introducing a new armel flavour: >> mini, which doesn't support wireless. >> There're still some users that need wireless, so I didn't remove >> wireless from armel/marvell directly. > > I think that we should still strive to pretend that there's a hard 2MB > limit and to shave some parts that can before we start creating a new > flavor of the kernel... This would force us to think harder about > disabling things in general... In general, I think that we can discuss > a little bit more about what to include/exclude from such smaller > kernels and which flavors to have. > > In other words, I agree with your end goal, but, perhaps, we can plan > this a bit more... > >> So here I propose to have: >> - marvell to support all generic feature and being able to tuned for >> performance. >> - mini without wireless and being minimum. >> >> Patches are all enclosed, and pushed to salsa rosh/armel_mini branch. >> - 0001: Bring back qnap support by a new armel flavour: mini (Disable >> WIRELESS, WLAN, etc) >> - 0002: [armel/mini] Add flavour mini to installer >> - 0003: [armel/mini] Further change a few features as module (I2C, >> I2C_CHARDEV, I2C_MV64XXX, >> MTD, MTD_CMDLINE_PARTS, RTC_DRV_MV, and SPI_ORION) > > I would make your commits more granular, with one semantic change per > commit, to revert and or/bisect in an easier fashion... > >> I tested on stretch by cross compiling, here's generated kernel size. >> - original 4.16~rc6-1~exp2: 2142704 >> - After patch 0001: 2017088 >> - After patch 0002: 2017088 >> - After patch 0003: 1985896 >> >> Here's my testing result regarding those features that changed to module: >> (tested under stretch) > > I'm doing my tests under testing (buster). See more below. > >>> Some options that could possibly be changed from y to m: >>> >>> - I2C, I2C_CHARDEV, I2C_MV64XXX. initramfs-tools should include I2C >>> drivers to the initramfs if needed, but I'm not certain. >> >> No, i2c nor i2c_mv64xxx will be loaded. But my armel box seems fine >> without them. >> Of course, manually "modprobe i2c_mv64xxx" will load the module well. > > While I have compiled a kernel with those options all enabled as > modules, I have not yet had time to boot it (in fact, I created a lot > of kernels that I want to test all in one sitting), but I agree with > the principle of your testing, Roger and, in the worst case, we can > instruct the users to add those to /etc/modules if they absolutely > need them. > > I would not qualify this as a change for only a new kernel flavor, > that is, I would make this change in general... > >>> - MTD, MTD_CMDLINE_PARTS, etc. But I'm pretty sure this will break >>> some systems unless initramfs-tools is updated to include and load the >>> cmdlinepart module. >>> >>> - RTC_DRV_MV (and disable RTC_HCTOSYS). There's a udev rule that >>> should load the system clock from the first RTC if its driver is a >>> module. >>> >>> - SPI_ORION. initramfs-tools should include this in the initramfs if >>> needed, but I'm not certain. >> >> Yes, above 3 modules are loaded without glitch. > > All those are generic material that I would also make generic instead > of only particular to a given flavor. > >>> Some options that could possibly be disabled: >>> >>> - AUDIT. This is quite a niche feature. >> >> I tried, but couldn't. Maybe next time. > > You probably missed this, but I said in a previous message that AUDIT > is automatically selected by AppArmor. In other words, you can have > only the following options: > > * with AppArmor (and AUDIT) > * without AppArmor (but with AUDIT) > * without AppArmor and without AUDIT > > From my perception, Ben was mildly opposed to having AppArmor disabled > by default and wanted to have the kernel as close as possible to other > arches... > > For that reason, I would still keep AppArmor in the big, reference > armel kernel, but opt to create a flavor without AppArmor (and without > AUDIT) for the people that may want
Re: armel/marvell kernel size
Dear Roger, Ben and others. On Sun, Apr 1, 2018 at 10:25 AM, Roger Shimizu wrote: > On Wed, Jan 24, 2018 at 3:30 AM, Ben Hutchings wrote: >> On Mon, 2018-01-22 at 22:38 +0900, Roger Shimizu wrote: >> There's an upstream change in cfg80211 that enables direct-loading of >> wireless rules, which requires public key crypto in the kernel. There >> doesn't appear to be any option to disable that mode, even though we >> don't need it because crda still works. Maybe you could disable >> wireless networking completely? > > I finally settled a solution, by introducing a new armel flavour: > mini, which doesn't support wireless. > There're still some users that need wireless, so I didn't remove > wireless from armel/marvell directly. I think that we should still strive to pretend that there's a hard 2MB limit and to shave some parts that can before we start creating a new flavor of the kernel... This would force us to think harder about disabling things in general... In general, I think that we can discuss a little bit more about what to include/exclude from such smaller kernels and which flavors to have. In other words, I agree with your end goal, but, perhaps, we can plan this a bit more... > So here I propose to have: > - marvell to support all generic feature and being able to tuned for > performance. > - mini without wireless and being minimum. > > Patches are all enclosed, and pushed to salsa rosh/armel_mini branch. > - 0001: Bring back qnap support by a new armel flavour: mini (Disable > WIRELESS, WLAN, etc) > - 0002: [armel/mini] Add flavour mini to installer > - 0003: [armel/mini] Further change a few features as module (I2C, > I2C_CHARDEV, I2C_MV64XXX, > MTD, MTD_CMDLINE_PARTS, RTC_DRV_MV, and SPI_ORION) I would make your commits more granular, with one semantic change per commit, to revert and or/bisect in an easier fashion... > I tested on stretch by cross compiling, here's generated kernel size. > - original 4.16~rc6-1~exp2: 2142704 > - After patch 0001: 2017088 > - After patch 0002: 2017088 > - After patch 0003: 1985896 > > Here's my testing result regarding those features that changed to module: > (tested under stretch) I'm doing my tests under testing (buster). See more below. >> Some options that could possibly be changed from y to m: >> >> - I2C, I2C_CHARDEV, I2C_MV64XXX. initramfs-tools should include I2C >> drivers to the initramfs if needed, but I'm not certain. > > No, i2c nor i2c_mv64xxx will be loaded. But my armel box seems fine > without them. > Of course, manually "modprobe i2c_mv64xxx" will load the module well. While I have compiled a kernel with those options all enabled as modules, I have not yet had time to boot it (in fact, I created a lot of kernels that I want to test all in one sitting), but I agree with the principle of your testing, Roger and, in the worst case, we can instruct the users to add those to /etc/modules if they absolutely need them. I would not qualify this as a change for only a new kernel flavor, that is, I would make this change in general... >> - MTD, MTD_CMDLINE_PARTS, etc. But I'm pretty sure this will break >> some systems unless initramfs-tools is updated to include and load the >> cmdlinepart module. >> >> - RTC_DRV_MV (and disable RTC_HCTOSYS). There's a udev rule that >> should load the system clock from the first RTC if its driver is a >> module. >> >> - SPI_ORION. initramfs-tools should include this in the initramfs if >> needed, but I'm not certain. > > Yes, above 3 modules are loaded without glitch. All those are generic material that I would also make generic instead of only particular to a given flavor. >> Some options that could possibly be disabled: >> >> - AUDIT. This is quite a niche feature. > > I tried, but couldn't. Maybe next time. You probably missed this, but I said in a previous message that AUDIT is automatically selected by AppArmor. In other words, you can have only the following options: * with AppArmor (and AUDIT) * without AppArmor (but with AUDIT) * without AppArmor and without AUDIT >From my perception, Ben was mildly opposed to having AppArmor disabled by default and wanted to have the kernel as close as possible to other arches... For that reason, I would still keep AppArmor in the big, reference armel kernel, but opt to create a flavor without AppArmor (and without AUDIT) for the people that may want to use a small kernel or for those (like me) that never use AppArmor (or that have not yet seen the light with the benefits of a MAC module). Besides your proposed changes, I have some other things in mind that I have in patches here and that I will send after I get access to the notebook where I compiled things: 1 - I would change from the CFQ to the DEADLINE governors *in the general kernel*, as it makes the kernel slightly smaller, but, in my experience, working as well as a CFQ in practice. 2 - Another excellent option is CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y suggested by Leigh Brown (taken from ht
Re: armel/marvell kernel size
On Mar 28, 2018, at 2:22 AM, Rick Thomas wrote: >> What filesystems do you use? Do you use any (para)virtualization? What >> about addon hardware that you have? Any USB dongles? Anything that you >> can think of? Sound? >> >> Do you use NFS? (I do) What kind of compressed ramdisk do you use? The >> loaded modules that you have with lsmod would be nice to know. > Filesystems: ext2 and ext4 Vitrualization: Nope. These are way too small for anything fancy like that. Addon hardware: USB2 ports useful for disk and/or flash drives and other stuff (I don’t do the “other stuff” myself but I suppose there are folks who might). They have 1000BaseT ports. Two ports on the OpenRD Client, one on the SheevaPlug. They each have a mini-USB serial port that they use for serial console. The Client has a headphone jack. I’ve used it in the past for listening to streaming radio. The SheevaPlug has no audio i/o. Both machines have SD-card slots that can be used in booting or as aux data storage. Both get their uboot from mtd, not mmc, so updating uboot requires re-flashing. The Client has 512MB RAM. The SheevaPlug has the same. CPU info for SheevaPlug — > root@sheeva:~# cat /proc/cpuinfo > processor : 0 > model name: Feroceon 88FR131 rev 1 (v5l) > BogoMIPS : 1185.79 > Features : swp half thumb fastmult edsp > CPU implementer : 0x56 > CPU architecture: 5TE > CPU variant : 0x2 > CPU part : 0x131 > CPU revision : 1 > > Hardware : Marvell Kirkwood (Flattened Device Tree) > Revision : > Serial: CPU info for OpenRD Client — > rbthomas@client:~$ cat /proc/cpuinfo > processor : 0 > model name: Feroceon 88FR131 rev 1 (v5l) > BogoMIPS : 1191.93 > Features : swp half thumb fastmult edsp > CPU implementer : 0x56 > CPU architecture: 5TE > CPU variant : 0x2 > CPU part : 0x131 > CPU revision : 1 > > Hardware : Marvell Kirkwood (Flattened Device Tree) > Revision : > Serial: Uboot details on SheevaPlug — > U-Boot 2016.01-rc3+dfsg1-3 (Jan 02 2016 - 23:19:11 +) > Marvell-Sheevaplug > > SoC: Kirkwood 88F6281_A0 > DRAM: 512 MiB (ECC not enabled) > WARNING: Caches not enabled > NAND: 512 MiB > MMC: MVEBU_MMC: 0 > In:serial > Out: serial > Err: serial > Net: egiga0 and on OpenRD Client — > U-Boot 2016.11+dfsg1-4~20170308~1 (Mar 09 2017 - 01:27:49 +) > OpenRD-Client > > SoC: Kirkwood 88F6281_A0 > DRAM: 512 MiB > WARNING: Caches not enabled > NAND: 512 MiB > MMC: MVEBU_MMC: 0 > In:serial > Out: serial > Err: serial > Net: egiga0, egiga1 > I use the SheevaPlug as a backup DHCP/DNS server for my home network. The Client is reserved for experimenting. I don’t currently use NFS on either, but I have in the past. I’m not sure what you mean by “What kind of compressed ramdisk do you use?”. As a stab in the dark — > rbthomas@client:~$ file /boot/initrd.img-4.9.0-6-marvell > /boot/initrd.img-4.9.0-6-marvell: gzip compressed data, last modified: Sun > Mar 4 14:29:43 2018, from Unix and > root@sheeva:~# file /boot/initrd.img-4.9.0-6-marvell > /boot/initrd.img-4.9.0-6-marvell: gzip compressed data, last modified: Sat > Mar 10 10:12:39 2018, from Unix In other words, nothing fancy! Does that help? Rick
Re: armel/marvell kernel size
Dear Ben, and other arm/kernel folks, On Wed, Jan 24, 2018 at 3:30 AM, Ben Hutchings wrote: > On Mon, 2018-01-22 at 22:38 +0900, Roger Shimizu wrote: > > There's an upstream change in cfg80211 that enables direct-loading of > wireless rules, which requires public key crypto in the kernel. There > doesn't appear to be any option to disable that mode, even though we > don't need it because crda still works. Maybe you could disable > wireless networking completely? I finally settled a solution, by introducing a new armel flavour: mini, which doesn't support wireless. There're still some users that need wireless, so I didn't remove wireless from armel/marvell directly. So here I propose to have: - marvell to support all generic feature and being able to tuned for performance. - mini without wireless and being minimum. Patches are all enclosed, and pushed to salsa rosh/armel_mini branch. - 0001: Bring back qnap support by a new armel flavour: mini (Disable WIRELESS, WLAN, etc) - 0002: [armel/mini] Add flavour mini to installer - 0003: [armel/mini] Further change a few features as module (I2C, I2C_CHARDEV, I2C_MV64XXX, MTD, MTD_CMDLINE_PARTS, RTC_DRV_MV, and SPI_ORION) I tested on stretch by cross compiling, here's generated kernel size. - original 4.16~rc6-1~exp2: 2142704 - After patch 0001: 2017088 - After patch 0002: 2017088 - After patch 0003: 1985896 Here's my testing result regarding those features that changed to module: (tested under stretch) > Some options that could possibly be changed from y to m: > > - I2C, I2C_CHARDEV, I2C_MV64XXX. initramfs-tools should include I2C > drivers to the initramfs if needed, but I'm not certain. No, i2c nor i2c_mv64xxx will be loaded. But my armel box seems fine without them. Of course, manually "modprobe i2c_mv64xxx" will load the module well. > - MTD, MTD_CMDLINE_PARTS, etc. But I'm pretty sure this will break > some systems unless initramfs-tools is updated to include and load the > cmdlinepart module. > > - RTC_DRV_MV (and disable RTC_HCTOSYS). There's a udev rule that > should load the system clock from the first RTC if its driver is a > module. > > - SPI_ORION. initramfs-tools should include this in the initramfs if > needed, but I'm not certain. Yes, above 3 modules are loaded without glitch. > Some options that could possibly be disabled: > > - AUDIT. This is quite a niche feature. I tried, but couldn't. Maybe next time. So armel/mini image now reduced 150KB compared to marvell, which now has enough room for Buster. Any concern for merging these patches? Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 From 713af1924e35a0587da2aa22d2d538b424955524 Mon Sep 17 00:00:00 2001 From: Roger Shimizu Date: Sun, 1 Apr 2018 00:27:00 +0900 Subject: [PATCH 1/3] Bring back qnap support by a new armel flavour: mini [armel/marvell] For flavour marvell, set CC_OPTIMIZE_FOR_PERFORMANCE, which is default for other Arch. [armel/mini] Add a new flavour mini to bring back qnap support, which uses config.marvell as base, with some additional settings in config-reduced: - Set CC_OPTIMIZE_FOR_SIZE, which as set in config.marvell before - Change CRYPTO_MANAGER as module - Set CRYPTO_MANAGER_DISABLE_TESTS=y - Disable ZSWAP - Disable WIRELESS - Disable RD_BZIP2 and RD_LZMA --- debian/changelog | 11 +++ debian/config/armel/config-reduced | 33 + debian/config/armel/config.marvell | 3 --- debian/config/armel/defines| 29 +++-- 4 files changed, 67 insertions(+), 9 deletions(-) create mode 100644 debian/config/armel/config-reduced diff --git a/debian/changelog b/debian/changelog index a30befbd9..7a0f7f7df 100644 --- a/debian/changelog +++ b/debian/changelog @@ -7,6 +7,17 @@ linux (4.16~rc6-1~exp2) UNRELEASED; urgency=medium Also revert two commits that disabled armel previously: - [2ed70eb] "Add empty featuresets for armel to help abiupdate script" - [5f62872] "(Temporarily) disable armel kernel image build" + * [armel/marvell] For flavour marvell, set CC_OPTIMIZE_FOR_PERFORMANCE, +which is default for other Arch. + * [armel/mini] Add a new flavour mini to bring back qnap support, which +uses config.marvell as base, with some additional settings in +config-reduced: +- Set CC_OPTIMIZE_FOR_SIZE, which as set in config.marvell before +- Change CRYPTO_MANAGER as module +- Set CRYPTO_MANAGER_DISABLE_TESTS=y +- Disable ZSWAP +- Disable WIRELESS +- Disable RD_BZIP2 and RD_LZMA -- Roger Shimizu Fri, 23 Mar 2018 21:10:34 +0900 diff --git a/debian/config/armel/config-reduced b/debian/config/armel/config-reduced new file mode 100644 index 0..3d6e3bfbc --- /dev/null +++ b/debian/config/armel/config-reduced @@ -0,0 +1,33 @@ +## +## file: crypto/Kconfig +## +CONFIG_CRYPTO_MANAGER=m +CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y + +## +## file: drivers/net/wireless/Kconfig +## +# CONFIG_WLAN is not
Re: armel/marvell kernel size
Hello guys, I believe the problem we are facing on Kirkwood with stretch is the same I had with iop32 and other folks with ixp4xx. As the support for iop32 on Wheezy is under EOL, do we have any hopes to solve the kernel size issue common for all this architectures or it's time to replace our nas? best regards federico 2018-03-28 11:22 GMT+02:00 Rick Thomas : > > On Mar 27, 2018, at 2:08 PM, Rogério Brito wrote: > > > On 2018-03-27 17:29, Rick Thomas wrote: > >> On Mar 27, 2018, at 1:04 PM, Rogério Brito wrote: > >>> As a related subject, I could compile a more stripped down version of > >>> the armel kernel, put it for people to download and ask people to > >>> comment if it works for them, so that we can gauge what people actually > >>> need from such a kernel... > >> > >> Please do! I have an OpenRD box and a SheevaPlug that I’ll be happy to > test on. > > > > You're welcome. I don't know much about the OpenRD nor about the > > SheevaPlug, but are they able to run the -marvell kernels? What was the > > last version of the kernel that worked for you? > > > > What filesystems do you use? Do you use any (para)virtualization? What > > about addon hardware that you have? Any USB dongles? Anything that you > > can think of? Sound? > > > > Do you use NFS? (I do) What kind of compressed ramdisk do you use? The > > loaded modules that you have with lsmod would be nice to know. > > A lot of questions… I’ll do my best to answer them as best I can sometime > this weekend (There are an equally large lot of things on my to-do list > this week! /-: ) > > In the mean time here’s a start: > > OpenRD Client > > rbthomas@client:~$ uname -a > > Linux client 4.9.0-6-marvell #1 Debian 4.9.82-1+deb9u3 (2018-03-02) > armv5tel GNU/Linux > > SheevaPlug > > rbthomas@sheeva:~$ uname -a > > Linux sheeva 4.9.0-6-marvell #1 Debian 4.9.82-1+deb9u3 (2018-03-02) > armv5tel GNU/Linux > > Both are running the latest Stretch. > > Rick >
Re: armel/marvell kernel size
On Mar 27, 2018, at 2:08 PM, Rogério Brito wrote: > On 2018-03-27 17:29, Rick Thomas wrote: >> On Mar 27, 2018, at 1:04 PM, Rogério Brito wrote: >>> As a related subject, I could compile a more stripped down version of >>> the armel kernel, put it for people to download and ask people to >>> comment if it works for them, so that we can gauge what people actually >>> need from such a kernel... >> >> Please do! I have an OpenRD box and a SheevaPlug that I’ll be happy to test >> on. > > You're welcome. I don't know much about the OpenRD nor about the > SheevaPlug, but are they able to run the -marvell kernels? What was the > last version of the kernel that worked for you? > > What filesystems do you use? Do you use any (para)virtualization? What > about addon hardware that you have? Any USB dongles? Anything that you > can think of? Sound? > > Do you use NFS? (I do) What kind of compressed ramdisk do you use? The > loaded modules that you have with lsmod would be nice to know. A lot of questions… I’ll do my best to answer them as best I can sometime this weekend (There are an equally large lot of things on my to-do list this week! /-: ) In the mean time here’s a start: OpenRD Client > rbthomas@client:~$ uname -a > Linux client 4.9.0-6-marvell #1 Debian 4.9.82-1+deb9u3 (2018-03-02) armv5tel > GNU/Linux SheevaPlug > rbthomas@sheeva:~$ uname -a > Linux sheeva 4.9.0-6-marvell #1 Debian 4.9.82-1+deb9u3 (2018-03-02) armv5tel > GNU/Linux Both are running the latest Stretch. Rick
Re: armel/marvell kernel size
>> I can answer this part: yes, you can definitely put an Intel wifi card >> in the mini-pcie slot of an ARM box. > This means that, in principle, we should enable many modules more to get > as full support as desired in Debian on each and every arch... My point wasn't just that it's technically possible, but since those Intel wifi mini-pcie cards are ubiquitous (found in most old discarded laptops you may have lying around), it's fairly likely that someone will want to use one of those. Stefan
Re: armel/marvell kernel size
On 2018-03-27 17:29, Rick Thomas wrote: > On Mar 27, 2018, at 1:04 PM, Rogério Brito wrote: >> As a related subject, I could compile a more stripped down version of >> the armel kernel, put it for people to download and ask people to >> comment if it works for them, so that we can gauge what people actually >> need from such a kernel... > > Please do! I have an OpenRD box and a SheevaPlug that I’ll be happy to test > on. You're welcome. I don't know much about the OpenRD nor about the SheevaPlug, but are they able to run the -marvell kernels? What was the last version of the kernel that worked for you? What filesystems do you use? Do you use any (para)virtualization? What about addon hardware that you have? Any USB dongles? Anything that you can think of? Sound? Do you use NFS? (I do) What kind of compressed ramdisk do you use? The loaded modules that you have with lsmod would be nice to know. > Thanks for keeping these old boxes alive! There's no guarantee, but I may try. Very low probability, but not zero probability... Regards, -- Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Re: armel/marvell kernel size
Hi, Ben and others following the discussion. On 2018-03-27 16:01, Ben Hutchings wrote: > On Tue, 2018-03-27 at 02:30 -0300, Rogério Brito wrote: > [...] I will see if all the modules make sense for an embedded system like this and I will send a list of options for opinions by others... >>> >>> [...] >>> >>> As I see it, the point of installing Debian on little NAS boxes is to >>> break out of the restrictions of an embedded system. We try to >>> provide, so far as possible, the same features across all >>> architectures. >> >> It sure makes sense to provide a lot more than some kernels, but I am >> curious about some features that end up as modules like some >> framebuffer like the following: >> >> (...) >> >> Is there any reason why, say, a driver for an S3 card is enabled while >> not for a Matrox? > > I don't know; that doesn't make a lot of sense. Running make menuconfig, I can disable it without any visible loss (not yet run it, but I don't have such hardware on my Kurobox Pro). If the kernel were only for me, then I would simply kill it, and be done with it, but, as I wrote to Stefan, the logical consequence would be to enable everything that could plausibly be used... OTOH, if people haven't noticed by this time that we need some drivers, perhaps we shouldn't be enabling such a thing... (Yes, I know that enabling a given driver can, say, enable some data structure implementation from the core of the kernel and/or some crypto algorithm, which would make the kernel potentially bigger). > The Kirkwood SoCs have external PCIe links and some of the supported > devices (like OpenRD) provide PCIe expansion slots, so most PCIe device > drivers should be enabled. > >> Are there real users for those? I know that, as >> modules, they don't make the kernel bigger, but they sit there on >> disk, doing nothing (right?). > > They probably don't make a difference. Right. I suspected this much. > However there are some cases > where a modular driver may require (and select) a feature that is > always built-in. Oh, yes this I knew. >> Similarly for wifi cards like those Intel ones like iwlwifi (which is >> the one that I have in this Core 2 Duo here)... > > Prepare to be amazed: https://www.amazon.com/dp/B00OM0L9ZO This I didn't know. :-) >> OK, now to the real meat of my message. Regarding shrinking the >> kernel image, I was able to tweak things slightly (drop from 101% down >> to 98%) by disabling APPARMOR, YAMA, AUDIT, making the kernel use the >> deadline IO scheduler instead of the CFQ and making as modules the >> ones that you suggested in the original message... Is that acceptable? > > I would really rather we avoided disabling AppArmor, since it is not > only built-in but also enabled by default on all other architectures. OK, I will reenable apparmor and see what size I get before sending patches. > Still, as armel will not be a release architecture any more, I suppose > it can diverge further from the normal configuration. I saw your other email. I would like to revert this and I don't know if (finally, after more than a decade contributing to Debian as a Debian Maintainer) it is time to step up and become a Debian Developer and commit to maintain some parts of the kernel... Yes, that means that if this excursion of mine is fruitful, I will volunteer... :-) If not, then I just get the learning experience. :-) Actually, if I succeed, I would be interested in also working to get powerpc revived, since I have an iBook G3, an iBook G4 and two ppc-based kuroboxes (but one of them has only 64MB of RAM and I still have to learn this device tree syntax)... >> If so, then I will test them on my Kurobox Pro and report what works >> and what breaks. I just wanted to get things smaller by tackling some >> lower hanging fruit... >> >> Another point: from what I saw in the Debian scripts, not all >> armel/marvell systems are limited to 2MB (in particular, the Kurobox >> Pro with which I am most concerned still has 630KB of room)... > > Roger has increased the size limit to 2729712 on the sid branch, which > is the limit on the Buffalo Linkstation devices. Check whether that > matches the Kurobox Pro too. I didn't know that. I guess that I cloned the repository after he made that change... Anyway, I will check it, but the kurobox Pro is (in my understanding) very close to a linkstation... >> In the >> very worst case (of course, this is not what we want), if the kernel >> actually gets much bigger in time for the buster release, we could >> selectively drop some systems (like what was done with the DNS323) >> instead of dropping an entire arch... I even think that a new, >> smaller, alternative flavor of the kernel is possible to provide to >> support those systems that are limited to 2MB of kernel image... (I >> can commit to support that, if my initial ideas work and people accept >> them). > > Either of those seem like reasonable options. For the moment, I will try to work with
Re: armel/marvell kernel size
On Mar 27, 2018, at 1:04 PM, Rogério Brito wrote: > As a related subject, I could compile a more stripped down version of > the armel kernel, put it for people to download and ask people to > comment if it works for them, so that we can gauge what people actually > need from such a kernel... Please do! I have an OpenRD box and a SheevaPlug that I’ll be happy to test on. Thanks for keeping these old boxes alive! Rick
Re: armel/marvell kernel size
Hi,Stefan. On 2018-03-27 09:34, Stefan Monnier wrote: >> Similarly for wifi cards like those Intel ones like iwlwifi (which is >> the one that I have in this Core 2 Duo here)... > > I can answer this part: yes, you can definitely put an Intel wifi card > in the mini-pcie slot of an ARM box. Yes, thanks for that hint (which Ben also replied to)... This means that, in principle, we should enable many modules more to get as full support as desired in Debian on each and every arch... OTOH, if nobody has asked for that before, maybe there's nobody missing such support (or they are compiling their own kernels). As a related subject, I could compile a more stripped down version of the armel kernel, put it for people to download and ask people to comment if it works for them, so that we can gauge what people actually need from such a kernel... Thanks for your input, Rogério. -- Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Re: armel/marvell kernel size
On Tue, 2018-03-27 at 02:30 -0300, Rogério Brito wrote: [...] > > > I will see if all the modules make sense for an embedded system like this > > > and I will send a list of options for opinions by others... > > > > [...] > > > > As I see it, the point of installing Debian on little NAS boxes is to > > break out of the restrictions of an embedded system. We try to > > provide, so far as possible, the same features across all > > architectures. > > It sure makes sense to provide a lot more than some kernels, but I am > curious about some features that end up as modules like some > framebuffer like the following: > > (...) > # CONFIG_FB_MATROX is not set > # CONFIG_FB_RADEON is not set > # CONFIG_FB_ATY128 is not set > # CONFIG_FB_ATY is not set > CONFIG_FB_S3=m > CONFIG_FB_S3_DDC=y > # CONFIG_FB_SAVAGE is not set > # CONFIG_FB_SIS is not set > # CONFIG_FB_NEOMAGIC is not set > # CONFIG_FB_KYRO is not set > CONFIG_FB_3DFX=m > # CONFIG_FB_3DFX_ACCEL is not set > CONFIG_FB_3DFX_I2C=y > # CONFIG_FB_VOODOO1 is not set > (...) > > Is there any reason why, say, a driver for an S3 card is enabled while > not for a Matrox? I don't know; that doesn't make a lot of sense. The Kirkwood SoCs have external PCIe links and some of the supported devices (like OpenRD) provide PCIe expansion slots, so most PCIe device drivers should be enabled. > Are there real users for those? I know that, as > modules, they don't make the kernel bigger, but they sit there on > disk, doing nothing (right?). They probably don't make a difference. However there are some cases where a modular driver may require (and select) a feature that is always built-in. > Similarly for wifi cards like those Intel ones like iwlwifi (which is > the one that I have in this Core 2 Duo here)... Prepare to be amazed: https://www.amazon.com/dp/B00OM0L9ZO > OK, now to the real meat of my message. Regarding shrinking the > kernel image, I was able to tweak things slightly (drop from 101% down > to 98%) by disabling APPARMOR, YAMA, AUDIT, making the kernel use the > deadline IO scheduler instead of the CFQ and making as modules the > ones that you suggested in the original message... Is that acceptable? I would really rather we avoided disabling AppArmor, since it is not only built-in but also enabled by default on all other architectures. Still, as armel will not be a release architecture any more, I suppose it can diverge further from the normal configuration. > If so, then I will test them on my Kurobox Pro and report what works > and what breaks. I just wanted to get things smaller by tackling some > lower hanging fruit... > > Another point: from what I saw in the Debian scripts, not all > armel/marvell systems are limited to 2MB (in particular, the Kurobox > Pro with which I am most concerned still has 630KB of room)... Roger has increased the size limit to 2729712 on the sid branch, which is the limit on the Buffalo Linkstation devices. Check whether that matches the Kurobox Pro too. > In the > very worst case (of course, this is not what we want), if the kernel > actually gets much bigger in time for the buster release, we could > selectively drop some systems (like what was done with the DNS323) > instead of dropping an entire arch... I even think that a new, > smaller, alternative flavor of the kernel is possible to provide to > support those systems that are limited to 2MB of kernel image... (I > can commit to support that, if my initial ideas work and people accept > them). Either of those seem like reasonable options. Ben. > Of course, if we could make some real magic and make our kernels much, > much smaller to support back the DNS323, that would be amazing... :-) > > I guess that I will look into those LTO patches in the future... > > OK, I am sending this to see if those ideas make sense, to offer my > help and, of course, to get some feedback. -- Ben Hutchings For every complex problem there is a solution that is simple, neat, and wrong. signature.asc Description: This is a digitally signed message part
Re: armel/marvell kernel size
Hi Ben and others. On Fri, Mar 23, 2018 at 10:50 PM, Ben Hutchings wrote: > On Fri, 2018-03-23 at 18:15 -0300, Rogério Brito wrote: > [...] > > HOLY MOLY! THIS THING IS SLOW on my Core 2 Duo notebook... Granted, I only > > have 4 GB of RAM, but the amount of modules that it compiles is > > HUGE... Quite different from a "regular" kernel that I used to compile... > > Don't you have access to something faster you can work on? Unfortunately, not at this moment. My desktop (a Phenon II X4) was fried during a power outage. :-( > You should be able to save time and disk space by disabling debug info, > as that won't make any difference to the eventual kernel size. You can > do that by adding "debug-info: false" to the [build] section in > debian/config/armel/defines. I did that and it seems to help a bit. > ccache can also be useful, though it doesn't help if you change a config > symbol that affects some widely > used header file. Yes, I was already using ccache and I find it invaluable. > > I will see if all the modules make sense for an embedded system like this > > and I will send a list of options for opinions by others... > [...] > > As I see it, the point of installing Debian on little NAS boxes is to > break out of the restrictions of an embedded system. We try to > provide, so far as possible, the same features across all > architectures. It sure makes sense to provide a lot more than some kernels, but I am curious about some features that end up as modules like some framebuffer like the following: (...) # CONFIG_FB_MATROX is not set # CONFIG_FB_RADEON is not set # CONFIG_FB_ATY128 is not set # CONFIG_FB_ATY is not set CONFIG_FB_S3=m CONFIG_FB_S3_DDC=y # CONFIG_FB_SAVAGE is not set # CONFIG_FB_SIS is not set # CONFIG_FB_NEOMAGIC is not set # CONFIG_FB_KYRO is not set CONFIG_FB_3DFX=m # CONFIG_FB_3DFX_ACCEL is not set CONFIG_FB_3DFX_I2C=y # CONFIG_FB_VOODOO1 is not set (...) Is there any reason why, say, a driver for an S3 card is enabled while not for a Matrox? Are there real users for those? I know that, as modules, they don't make the kernel bigger, but they sit there on disk, doing nothing (right?). Similarly for wifi cards like those Intel ones like iwlwifi (which is the one that I have in this Core 2 Duo here)... OK, now to the real meat of my message. Regarding shrinking the kernel image, I was able to tweak things slightly (drop from 101% down to 98%) by disabling APPARMOR, YAMA, AUDIT, making the kernel use the deadline IO scheduler instead of the CFQ and making as modules the ones that you suggested in the original message... Is that acceptable? If so, then I will test them on my Kurobox Pro and report what works and what breaks. I just wanted to get things smaller by tackling some lower hanging fruit... Another point: from what I saw in the Debian scripts, not all armel/marvell systems are limited to 2MB (in particular, the Kurobox Pro with which I am most concerned still has 630KB of room)... In the very worst case (of course, this is not what we want), if the kernel actually gets much bigger in time for the buster release, we could selectively drop some systems (like what was done with the DNS323) instead of dropping an entire arch... I even think that a new, smaller, alternative flavor of the kernel is possible to provide to support those systems that are limited to 2MB of kernel image... (I can commit to support that, if my initial ideas work and people accept them). Of course, if we could make some real magic and make our kernels much, much smaller to support back the DNS323, that would be amazing... :-) I guess that I will look into those LTO patches in the future... OK, I am sending this to see if those ideas make sense, to offer my help and, of course, to get some feedback. Thanks, -- Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Re: armel/marvell kernel size
On Fri, 2018-03-23 at 18:15 -0300, Rogério Brito wrote: [...] > HOLY MOLY! THIS THING IS SLOW on my Core 2 Duo notebook... Granted, I only > have 4 GB of RAM, but the amount of modules that it compiles is > HUGE... Quite different from a "regular" kernel that I used to compile... Don't you have access to something faster you can work on? You should be able to save time and disk space by disabling debug info, as that won't make any difference to the eventual kernel size. You can do that by adding "debug-info: false" to the [build] section in debian/config/armel/defines. ccache can also be useful, though it doesn't help if you change a config symbol that affects some widely used header file. > I will see if all the modules make sense for an embedded system like this > and I will send a list of options for opinions by others... [...] As I see it, the point of installing Debian on little NAS boxes is to break out of the restrictions of an embedded system. We try to provide, so far as possible, the same features across all architectures. Ben. -- Ben Hutchings Man invented language to satisfy his deep need to complain. - Lily Tomlin signature.asc Description: This is a digitally signed message part
Re: armel/marvell kernel size
On Thu, 2018-03-22 at 00:12 -0300, Rogério Brito wrote: [...] > If nobody is working on getting a new kernel working on armel, I would > like to (at least, unsuccessfully) try to get it to compile. > > At worst, I believe, I can gain some knowledge and compare what I get from > this armel kernel with a Kurobox HD (powerpc-based; see some notes at [0])... > > [0]: > http://cynic.cc/blog/posts/simple-annotations-on-compiling-a-linux-kernel-for-an-embedded-platform/ > > For this task, I have some questions: > > 1 - To get up to speed, is there any recommended way of cross-compiling > the kernels, before I try it on bare-metal? When I compiled my own > kernels, I used to use a cross-compiler that I compiled myself and it > was using a very non-methodological way... Cross-compiling works well. For the Debian package, use: dpkg-buildpackage -aarmel -Pcross,pkg.linux.notools If you want to work with the upstream source, use: make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- [...] > 3 - Besides the points listed above, what else can usually be disabled, > if they don't pertain/make sense in a system like a small armel box? If I knew that I'd have already done it (or suggested it). > 4 - What is the preferred tree to be used for Debian's kernel > development? I am used to compile kernels from Linus's git tree with no > patches, but I know that Debian carries a sizable amount of patches... Clone the kernel team's git repository and use whatever upstream version we are using. > I may have some free time after Easter to have some trial and errors, but it > may even be the case that some free time becomes available before that... > > > We would like to ideally upload a 4.15.x based version to unstable > > (currently imported 4.15.4). > > I now see that there were some 4.16rc's uploaded to the archive... I guess > that this is tied with my 4th point above, right? You can work on either the sid branch (currently 4.15.y) or master (4.16-rcN, for experimental). But in a few weeks 4.16 will be ready for unstable and it will probably result in further code growth, so you might as well work on master. Ben. > Hope to have some luck with my 1st armel adventures, > > > Rogério Brito. > -- Ben Hutchings This sentence contradicts itself - no actually it doesn't. signature.asc Description: This is a digitally signed message part
Re: armel/marvell kernel size
Dear Roger and other people! On Thu, Mar 22, 2018 at 8:40 AM, Roger Shimizu wrote: > Good to hear from you again! Thank you very much. Glad to hear from you again, keeping the armel flame lit! First of all, it seems weird that my previous message didn't get to the lists. I find this very strange, but who knows? I'm now sending it through gmail instead of via my usual relay. I hope that this gets through. > On Thu, Mar 22, 2018 at 12:12 PM, Rogério Brito wrote: >> On 2018-02-17 10:48, Salvatore Bonaccorso wrote: >>> On Tue, Jan 23, 2018 at 06:30:23PM +, Ben Hutchings wrote: There's an upstream change in cfg80211 that enables direct-loading of wireless rules, which requires public key crypto in the kernel. There doesn't appear to be any option to disable that mode, even though we don't need it because crda still works. Maybe you could disable wireless networking completely? Some options that could possibly be changed from y to m: - I2C, I2C_CHARDEV, I2C_MV64XXX. initramfs-tools should include I2C drivers to the initramfs if needed, but I'm not certain. - MTD, MTD_CMDLINE_PARTS, etc. But I'm pretty sure this will break some systems unless initramfs-tools is updated to include and load the cmdlinepart module. - RTC_DRV_MV (and disable RTC_HCTOSYS). There's a udev rule that should load the system clock from the first RTC if its driver is a module. - SPI_ORION. initramfs-tools should include this in the initramfs if needed, but I'm not certain. Some options that could possibly be disabled: - AUDIT. This is quite a niche feature. Also try comparing the complete configs over time and looking for symbols newly set to y. >>> >>> Did you had a chance to look at Ben's suggestions or ideas? >> >> If nobody is working on getting a new kernel working on armel, I would >> like to (at least, unsuccessfully) try to get it to compile. >> >> At worst, I believe, I can gain some knowledge and compare what I get from >> this armel kernel with a Kurobox HD (powerpc-based; see some notes at [0])... >> >> [0]: >> http://cynic.cc/blog/posts/simple-annotations-on-compiling-a-linux-kernel-for-an-embedded-platform/ >> >> For this task, I have some questions: > > I have a wiki entry to help you: > - https://wiki.debian.org/HowToCrossBuildAnOfficialDebianKernelPackage Thank you very much for the link. It will be highly useful for experimenting. > However, Kurobox HD is not armel, so you need to use Kurobox Pro, if > you still have it. Oh, sure. I do have the Kurobox Pro and that's the one which I am planning to keep alive as much as I can (well, not that I don't plan on keeping the other ones not alive... It's just that I am quite short on time and that I plan on keeping the Kurobox Pro churning as it is the one that is already well set up and so on). The notes that I presented on the link above are explicitly for powerpc (BTW, it seems like my ikiwiki setup is foo-barred and ate a large part of what I wrote in that article). As I said before, I hope to have some time before Easter to work on getting the kernel smaller and back being produced. Oh, just to reiterate a part from my previous email (the one that didn't reach the mailing lists): > 3 - Besides the points listed above, what else can usually be disabled, if > they don't pertain/make sense in a system like a small armel box? If anybody could comment on that, it would be very good to know, so as to have some slack to prevent these problems from happening in the near future. Thanks, Rogério Brito. -- Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Re: armel/marvell kernel size
Dear Rogério, Good to hear from you again! On Thu, Mar 22, 2018 at 12:12 PM, Rogério Brito wrote: > Hi, all (and sorry for jumping in a bit late). > > On 2018-02-17 10:48, Salvatore Bonaccorso wrote: >> On Tue, Jan 23, 2018 at 06:30:23PM +, Ben Hutchings wrote: >>> There's an upstream change in cfg80211 that enables direct-loading of >>> wireless rules, which requires public key crypto in the kernel. There >>> doesn't appear to be any option to disable that mode, even though we >>> don't need it because crda still works. Maybe you could disable >>> wireless networking completely? >>> >>> Some options that could possibly be changed from y to m: >>> >>> - I2C, I2C_CHARDEV, I2C_MV64XXX. initramfs-tools should include I2C >>> drivers to the initramfs if needed, but I'm not certain. >>> >>> - MTD, MTD_CMDLINE_PARTS, etc. But I'm pretty sure this will break >>> some systems unless initramfs-tools is updated to include and load the >>> cmdlinepart module. >>> >>> - RTC_DRV_MV (and disable RTC_HCTOSYS). There's a udev rule that >>> should load the system clock from the first RTC if its driver is a >>> module. >>> >>> - SPI_ORION. initramfs-tools should include this in the initramfs if >>> needed, but I'm not certain. >>> >>> Some options that could possibly be disabled: >>> >>> - AUDIT. This is quite a niche feature. >>> >>> Also try comparing the complete configs over time and looking for >>> symbols newly set to y. >> >> Did you had a chance to look at Ben's suggestions or ideas? > > If nobody is working on getting a new kernel working on armel, I would > like to (at least, unsuccessfully) try to get it to compile. > > At worst, I believe, I can gain some knowledge and compare what I get from > this armel kernel with a Kurobox HD (powerpc-based; see some notes at [0])... > > [0]: > http://cynic.cc/blog/posts/simple-annotations-on-compiling-a-linux-kernel-for-an-embedded-platform/ > > For this task, I have some questions: I have a wiki entry to help you: - https://wiki.debian.org/HowToCrossBuildAnOfficialDebianKernelPackage However, Kurobox HD is not armel, so you need to use Kurobox Pro, if you still have it. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Re: armel/marvell kernel size
[ CC tbm ] On Sat, Feb 17, 2018 at 9:57 PM, Bastian Blank wrote: > On Sat, Feb 17, 2018 at 01:48:51PM +0100, Salvatore Bonaccorso wrote: >> Did you had a chance to look at Ben's suggestions or ideas? >> We would like to ideally upload a 4.15.x based version to unstable >> (currently imported 4.15.4). > > I would start with disabling it. The armel architecture (not armhf) will > most likely not be part of Buster anyway. I'm sorry that I still didn't find a way to make armel kernel within 2MB. So I will trigger the easy fix that increase the limit to 3MB, which probably break quite a few qnap boxes. Before Buster release, we still have chance to bring qnap support back, if I or other maintainer find a way.. > For the current state see > https://release.debian.org/buster/arch_qualify.html Sorry to hear that. But I think armel should share the same status with armhf. Anyway, this is another topic to discuss, which is better shouting to d-d in a new thread. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Re: armel/marvell kernel size
On Sat, Feb 17, 2018 at 01:48:51PM +0100, Salvatore Bonaccorso wrote: > Did you had a chance to look at Ben's suggestions or ideas? > We would like to ideally upload a 4.15.x based version to unstable > (currently imported 4.15.4). I would start with disabling it. The armel architecture (not armhf) will most likely not be part of Buster anyway. For the current state see https://release.debian.org/buster/arch_qualify.html Bastian -- War isn't a good life, but it's life. -- Kirk, "A Private Little War", stardate 4211.8
Re: armel/marvell kernel size
Hi Roger, On Tue, Jan 23, 2018 at 06:30:23PM +, Ben Hutchings wrote: > On Mon, 2018-01-22 at 22:38 +0900, Roger Shimizu wrote: > > Dear Ben, > > > > Thanks for keeping armel things rolling for a few releases! > > > > On Thu, Jan 18, 2018 at 1:22 PM, Ben Hutchings wrote: > > > On Fri, 2017-10-20 at 15:07 +0100, Ben Hutchings wrote: > > > > Sadly, linux has again failed to build on armel in experimental due to > > > > the image size growing too large. > > > > > > It's happened again. The compressed image is 1% over the limit. > > > > Yes, it's time again. > > > > I tried the "CRYPTO_MANAGER2" stuff you mentioned before. > > Unfortunately, I didn't make it built as module, except after > > disabling CONFIG_NET, which seems quite ridiculous. > > > > Do you know any other option, BTW? > > I'll continue trying for a while. > > There's an upstream change in cfg80211 that enables direct-loading of > wireless rules, which requires public key crypto in the kernel. There > doesn't appear to be any option to disable that mode, even though we > don't need it because crda still works. Maybe you could disable > wireless networking completely? > > Some options that could possibly be changed from y to m: > > - I2C, I2C_CHARDEV, I2C_MV64XXX. initramfs-tools should include I2C > drivers to the initramfs if needed, but I'm not certain. > > - MTD, MTD_CMDLINE_PARTS, etc. But I'm pretty sure this will break > some systems unless initramfs-tools is updated to include and load the > cmdlinepart module. > > - RTC_DRV_MV (and disable RTC_HCTOSYS). There's a udev rule that > should load the system clock from the first RTC if its driver is a > module. > > - SPI_ORION. initramfs-tools should include this in the initramfs if > needed, but I'm not certain. > > Some options that could possibly be disabled: > > - AUDIT. This is quite a niche feature. > > Also try comparing the complete configs over time and looking for > symbols newly set to y. Did you had a chance to look at Ben's suggestions or ideas? We would like to ideally upload a 4.15.x based version to unstable (currently imported 4.15.4). Regards, Salvatore
Re: armel/marvell kernel size
Another possibility is to use LTO (Link-Time Optimisation): https://lwn.net/SubscriberLink/744507/6489bc782122ca29/ However this is not yet supported in mainline, and it might require more VM than is available on an armel buildd. Ben. -- Ben Hutchings Unix is many things to many people, but it's never been everything to anybody. signature.asc Description: This is a digitally signed message part
Re: armel/marvell kernel size
On Mon, 2018-01-22 at 22:38 +0900, Roger Shimizu wrote: > Dear Ben, > > Thanks for keeping armel things rolling for a few releases! > > On Thu, Jan 18, 2018 at 1:22 PM, Ben Hutchings wrote: > > On Fri, 2017-10-20 at 15:07 +0100, Ben Hutchings wrote: > > > Sadly, linux has again failed to build on armel in experimental due to > > > the image size growing too large. > > > > It's happened again. The compressed image is 1% over the limit. > > Yes, it's time again. > > I tried the "CRYPTO_MANAGER2" stuff you mentioned before. > Unfortunately, I didn't make it built as module, except after > disabling CONFIG_NET, which seems quite ridiculous. > > Do you know any other option, BTW? > I'll continue trying for a while. There's an upstream change in cfg80211 that enables direct-loading of wireless rules, which requires public key crypto in the kernel. There doesn't appear to be any option to disable that mode, even though we don't need it because crda still works. Maybe you could disable wireless networking completely? Some options that could possibly be changed from y to m: - I2C, I2C_CHARDEV, I2C_MV64XXX. initramfs-tools should include I2C drivers to the initramfs if needed, but I'm not certain. - MTD, MTD_CMDLINE_PARTS, etc. But I'm pretty sure this will break some systems unless initramfs-tools is updated to include and load the cmdlinepart module. - RTC_DRV_MV (and disable RTC_HCTOSYS). There's a udev rule that should load the system clock from the first RTC if its driver is a module. - SPI_ORION. initramfs-tools should include this in the initramfs if needed, but I'm not certain. Some options that could possibly be disabled: - AUDIT. This is quite a niche feature. Also try comparing the complete configs over time and looking for symbols newly set to y. Ben. -- Ben Hutchings Reality is just a crutch for people who can't handle science fiction. signature.asc Description: This is a digitally signed message part
Re: armel/marvell kernel size
Dear Ben, Thanks for keeping armel things rolling for a few releases! On Thu, Jan 18, 2018 at 1:22 PM, Ben Hutchings wrote: > On Fri, 2017-10-20 at 15:07 +0100, Ben Hutchings wrote: >> Sadly, linux has again failed to build on armel in experimental due to >> the image size growing too large. > > It's happened again. The compressed image is 1% over the limit. Yes, it's time again. I tried the "CRYPTO_MANAGER2" stuff you mentioned before. Unfortunately, I didn't make it built as module, except after disabling CONFIG_NET, which seems quite ridiculous. Do you know any other option, BTW? I'll continue trying for a while. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Re: armel/marvell kernel size
On Fri, 2017-10-20 at 15:07 +0100, Ben Hutchings wrote: > Sadly, linux has again failed to build on armel in experimental due to > the image size growing too large. It's happened again. The compressed image is 1% over the limit. Ben. -- Ben Hutchings If at first you don't succeed, you're doing about average. signature.asc Description: This is a digitally signed message part
Re: armel/marvell kernel size
On Fri, Oct 27, 2017 at 6:03 AM, Ben Hutchings wrote: > On Tue, 2017-10-24 at 00:10 +0900, Roger Shimizu wrote: >> Dear Ben, >> >> Thanks for the ping! >> >> On Fri, Oct 20, 2017 at 11:07 PM, Ben Hutchings wrote: >> > Sadly, linux has again failed to build on armel in experimental due to >> > the image size growing too large. >> >> Yes, I noticed this armel FTBFS issue. >> However, the solution simple solution, you mentioned in previous email >> [0], has been used. >> Now I think we have to touch the crypto module part, which affects >> cryptsetup/initramfs-tools. >> I'll try this approach this week. >> >> [0] https://lists.debian.org/debian-kernel/2017/05/msg00040.html > > Since we are preparing to enable AppArmor by default, I looked at the > armel config and found that it still had SECURITY_SELINUX enabled (but > no other LSMs). I've just committed a change to the sid branch that > disables that and enables SECURITY_APPARMOR instead. AppArmor appears > to be smaller than SELinux, possibly by enough to fix this. Thanks for the info! Yes, I confirm that after enabling AppArmor, armel kernel reduced to 98.6%, which is quite significant. However I'll keep trying to reduce by other way during buster period. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Re: armel/marvell kernel size
On Tue, 2017-10-24 at 00:10 +0900, Roger Shimizu wrote: > Dear Ben, > > Thanks for the ping! > > On Fri, Oct 20, 2017 at 11:07 PM, Ben Hutchings wrote: > > Sadly, linux has again failed to build on armel in experimental due to > > the image size growing too large. > > Yes, I noticed this armel FTBFS issue. > However, the solution simple solution, you mentioned in previous email > [0], has been used. > Now I think we have to touch the crypto module part, which affects > cryptsetup/initramfs-tools. > I'll try this approach this week. > > [0] https://lists.debian.org/debian-kernel/2017/05/msg00040.html Since we are preparing to enable AppArmor by default, I looked at the armel config and found that it still had SECURITY_SELINUX enabled (but no other LSMs). I've just committed a change to the sid branch that disables that and enables SECURITY_APPARMOR instead. AppArmor appears to be smaller than SELinux, possibly by enough to fix this. Ben. -- Ben Hutchings The most exhausting thing in life is being insincere. - Anne Morrow Lindberg signature.asc Description: This is a digitally signed message part
Re: armel/marvell kernel size
Dear Ben, Thanks for the ping! On Fri, Oct 20, 2017 at 11:07 PM, Ben Hutchings wrote: > Sadly, linux has again failed to build on armel in experimental due to > the image size growing too large. Yes, I noticed this armel FTBFS issue. However, the solution simple solution, you mentioned in previous email [0], has been used. Now I think we have to touch the crypto module part, which affects cryptsetup/initramfs-tools. I'll try this approach this week. [0] https://lists.debian.org/debian-kernel/2017/05/msg00040.html Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Re: armel/marvell kernel size
On Mon, Jul 31, 2017 at 11:43 PM, Roger Shimizu wrote: > And I tried Ben's recommendation to make armel kernel smaller, > which I pushed to branch rosh/strip_armel on alioth, confirmed it worked > well for 4.10.7-1~exp1 (by cherry-pick) on my kirkwood based Linkstation. I already noticed that the above attempt fails for armel, again, for latest 3.13 kernel in experimental. I'll try to fix it this weekend. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Re: armel/marvell kernel size
On Mon, Jul 31, 2017 at 3:05 AM, Roger Shimizu wrote: > > While I'm still working on this, but I find the latest kernel in > archive, 4.11.11-1+b1, fails to boot on my kirkwood based Linkstation. > I tried netconsole, but don't get any log. (netconsole outputs fine on > working kernels, such as 4.9 and 4.10 series.) > And I trace to latest working kernel is 4.10.7-1~exp1. > > 4.11-1_exp[12] FTBFS on armel, and 4.11.3-1_exp1 doesn't boot. > > I checked d-kernel and d-arm list, but didn't find similar issue. > Do you have any clue on this? Thanks! I think my problem is very likely the same as: - https://bugs.debian.org/870185 And I tried Ben's recommendation to make armel kernel smaller, which I pushed to branch rosh/strip_armel on alioth, confirmed it worked well for 4.10.7-1~exp1 (by cherry-pick) on my kirkwood based Linkstation. I know it's better to confirm the d-i part, but I don't have much time before debconf.. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Re: armel/marvell kernel size
On Mon, Jul 31, 2017 at 7:16 AM, Ian Campbell wrote: > > I found that with 4.11 the initrd was too big for my ts41x. Could it be that? Thanks for providing the info! Stock initrd of Linkstation is 9MB, and now Debian's initrd is just 4+MB (MODULE=dep, compressed by gzip). So I don't think it's a problem for Linkstation case. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Re: armel/marvell kernel size
On 30 July 2017 19:05:18 BST, Roger Shimizu wrote: >On Sat, Jul 22, 2017 at 8:40 AM, Ben Hutchings >wrote: >> On Wed, 2017-05-03 at 23:12 +0100, Ben Hutchings wrote: >>> linux 4.11-1~exp1 FTBFS on armel. I spent a little while >modularising >>> some things that were unnecessarily built-in, but the image size >will >>> still be very close to the current limit of 2 MiB. If it grows >beyond >>> this we'll lose support for many QNAP models. >> >> It's now (with 4.12.2-1~exp1) over 2 MiB; please look at this. > >While I'm still working on this, but I find the latest kernel in >archive, 4.11.11-1+b1, fails to boot on my kirkwood based Linkstation. >I tried netconsole, but don't get any log. (netconsole outputs fine on >working kernels, such as 4.9 and 4.10 series.) >And I trace to latest working kernel is 4.10.7-1~exp1. > >4.11-1_exp[12] FTBFS on armel, and 4.11.3-1_exp1 doesn't boot. > >I checked d-kernel and d-arm list, but didn't find similar issue. >Do you have any clue on this? Thanks! I found that with 4.11 the initrd was too big for my ts41x. Could it be that? -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: armel/marvell kernel size
On Mon, 2017-07-31 at 03:05 +0900, Roger Shimizu wrote: > > On Sat, Jul 22, 2017 at 8:40 AM, Ben Hutchings wrote: > > On Wed, 2017-05-03 at 23:12 +0100, Ben Hutchings wrote: > > > linux 4.11-1~exp1 FTBFS on armel. I spent a little while modularising > > > some things that were unnecessarily built-in, but the image size will > > > still be very close to the current limit of 2 MiB. If it grows beyond > > > this we'll lose support for many QNAP models. > > > > It's now (with 4.12.2-1~exp1) over 2 MiB; please look at this. > > While I'm still working on this, but I find the latest kernel in > archive, 4.11.11-1+b1, fails to boot on my kirkwood based Linkstation. > I tried netconsole, but don't get any log. (netconsole outputs fine on > working kernels, such as 4.9 and 4.10 series.) > And I trace to latest working kernel is 4.10.7-1~exp1. > > 4.11-1_exp[12] FTBFS on armel, and 4.11.3-1_exp1 doesn't boot. > > I checked d-kernel and d-arm list, but didn't find similar issue. > Do you have any clue on this? Thanks! No idea, sorry. Ben. -- Ben Hutchings Knowledge is power. France is bacon. signature.asc Description: This is a digitally signed message part
Re: armel/marvell kernel size
On Sat, Jul 22, 2017 at 8:40 AM, Ben Hutchings wrote: > On Wed, 2017-05-03 at 23:12 +0100, Ben Hutchings wrote: >> linux 4.11-1~exp1 FTBFS on armel. I spent a little while modularising >> some things that were unnecessarily built-in, but the image size will >> still be very close to the current limit of 2 MiB. If it grows beyond >> this we'll lose support for many QNAP models. > > It's now (with 4.12.2-1~exp1) over 2 MiB; please look at this. While I'm still working on this, but I find the latest kernel in archive, 4.11.11-1+b1, fails to boot on my kirkwood based Linkstation. I tried netconsole, but don't get any log. (netconsole outputs fine on working kernels, such as 4.9 and 4.10 series.) And I trace to latest working kernel is 4.10.7-1~exp1. 4.11-1_exp[12] FTBFS on armel, and 4.11.3-1_exp1 doesn't boot. I checked d-kernel and d-arm list, but didn't find similar issue. Do you have any clue on this? Thanks! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Re: armel/marvell kernel size
On Sun, 2017-07-23 at 00:14 +0900, Roger Shimizu wrote: > On Sat, Jul 22, 2017 at 8:40 AM, Ben Hutchings > wrote: > > > > On Wed, 2017-05-03 at 23:12 +0100, Ben Hutchings wrote: > > > linux 4.11-1~exp1 FTBFS on armel. I spent a little while > > > modularising > > > some things that were unnecessarily built-in, but the image size > > > will > > > still be very close to the current limit of 2 MiB. If it grows > > > beyond > > > this we'll lose support for many QNAP models. > > > > It's now (with 4.12.2-1~exp1) over 2 MiB; please look at this. > > OK. > BTW. When do you plan to upload 4.12 series kernel to unstable? Some time in the next week. Ben. -- Ben Hutchings All extremists should be taken out and shot. signature.asc Description: This is a digitally signed message part
Re: armel/marvell kernel size
On Sat, Jul 22, 2017 at 8:40 AM, Ben Hutchings wrote: > > On Wed, 2017-05-03 at 23:12 +0100, Ben Hutchings wrote: > > linux 4.11-1~exp1 FTBFS on armel. I spent a little while modularising > > some things that were unnecessarily built-in, but the image size will > > still be very close to the current limit of 2 MiB. If it grows beyond > > this we'll lose support for many QNAP models. > > It's now (with 4.12.2-1~exp1) over 2 MiB; please look at this. OK. BTW. When do you plan to upload 4.12 series kernel to unstable? Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Re: armel/marvell kernel size
On Wed, 2017-05-03 at 23:12 +0100, Ben Hutchings wrote: > linux 4.11-1~exp1 FTBFS on armel. I spent a little while modularising > some things that were unnecessarily built-in, but the image size will > still be very close to the current limit of 2 MiB. If it grows beyond > this we'll lose support for many QNAP models. It's now (with 4.12.2-1~exp1) over 2 MiB; please look at this. Ben. > It should be possible to reduce the image size quite a bit by changing > NAND drivers to modules. I don't know if initramfs-tools is smart > enough to include these drivers in the initramfs where needed. It > would certainly be necessary to add those drivers to the mtd-modules > udeb. > > It may also be possible to reduce the image size by modularising more > cryptographic stuff. The big piece there is cryptomgr > (CONFIG_CRYPTO_MANAGER2), which is directly or indirectly selected by > most other cryptographic options. So this might be impossible. It > also might require changes to cryptsetup to get the right modules > included in the initramfs. > > I'm going to leave further decisions on the size limit and > configuration to you. If armel/marvell breaks again and stays broken > then I'm going to have to disable it. > > Ben. > -- Ben Hutchings All extremists should be taken out and shot. signature.asc Description: This is a digitally signed message part
Re: armel/marvell kernel size
On Mon, 8 May 2017 16:03:50 +0200 Martin Michlmayr wrote: > * Roger Shimizu [2017-05-06 14:45]: > > I'll try to take care of armel/marvell. > > I thought the plan was to drop the whole armel architecture after > stretch anyway. > > Maybe we should start that conversation on debian-arm again at some > point to see what the current consensus is. I started a thread on whether to remove armel after stretch last December [0]. And Steve agreed that he'll not push to remove armel after stretch [1]. With the toolchain issues resolved in stretch (toolchain issues mentioned here [2]), I think the main work is to keep the kernel size and initrd size (including initrd for d-i) within QNAP's limitation. Maybe we have to remove QNAP support some time before buster, it's still able to support other armel with /boot mounting in HDD) [0] https://lists.debian.org/debian-devel/2016/12/msg00135.html [1] https://lists.debian.org/debian-devel/2016/12/msg00329.html [2] https://lists.debian.org/debian-devel/2016/12/msg00143.html Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 pgpn2BKhtjG2l.pgp Description: PGP signature
Re: armel/marvell kernel size
* Roger Shimizu [2017-05-06 14:45]: > I'll try to take care of armel/marvell. I thought the plan was to drop the whole armel architecture after stretch anyway. Maybe we should start that conversation on debian-arm again at some point to see what the current consensus is. -- Martin Michlmayr http://www.cyrius.com/
Re: armel/marvell kernel size
[ CC: Martin ] Dear Ben, Thanks for your effort to support armel/marvell! On Wed, 03 May 2017 23:12:40 +0100 Ben Hutchings wrote: > linux 4.11-1~exp1 FTBFS on armel. I spent a little while modularising > some things that were unnecessarily built-in, but the image size will > still be very close to the current limit of 2 MiB. If it grows beyond > this we'll lose support for many QNAP models. I'll try to take care of armel/marvell. But I don't have QNAP device personally. I have a few Buffalo Linkstation devices that use /dev/sda1 as /boot, so they don't have the 2MB limitation which QNAP devices have. I'll make changes when necessary, and ask Martin and/or other QNAP users to test. > It should be possible to reduce the image size quite a bit by changing > NAND drivers to modules. I don't know if initramfs-tools is smart > enough to include these drivers in the initramfs where needed. It > would certainly be necessary to add those drivers to the mtd-modules > udeb. > > It may also be possible to reduce the image size by modularising more > cryptographic stuff. The big piece there is cryptomgr > (CONFIG_CRYPTO_MANAGER2), which is directly or indirectly selected by > most other cryptographic options. So this might be impossible. It > also might require changes to cryptsetup to get the right modules > included in the initramfs. > > I'm going to leave further decisions on the size limit and > configuration to you. If armel/marvell breaks again and stays broken > then I'm going to have to disable it. Thanks for the advices! I'll chase those possibilities (maybe after stretch released). If I break something, kindly let me know. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 pgpvdAD6LEqWz.pgp Description: PGP signature