Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #59248 > unrolled thread

armel/marvell kernel size

Back to article view | Back to linux.debian.kernel

Contents

  armel/marvell kernel size Ben Hutchings <ben@decadent.org.uk> - 2017-10-20 16:10 +0200
    Re: armel/marvell kernel size Roger Shimizu <rogershimizu@gmail.com> - 2017-10-23 17:40 +0200
      Re: armel/marvell kernel size Ben Hutchings <ben@decadent.org.uk> - 2017-10-26 23:10 +0200
        Re: armel/marvell kernel size Roger Shimizu <rogershimizu@gmail.com> - 2017-10-29 18:20 +0100
    Re: armel/marvell kernel size Ben Hutchings <ben@decadent.org.uk> - 2018-01-18 05:30 +0100
      Re: armel/marvell kernel size Roger Shimizu <rogershimizu@gmail.com> - 2018-01-22 15:00 +0100
        Re: armel/marvell kernel size Ben Hutchings <ben@decadent.org.uk> - 2018-01-23 19:40 +0100
          Re: armel/marvell kernel size Ben Hutchings <ben@decadent.org.uk> - 2018-01-26 19:00 +0100
          Re: armel/marvell kernel size Salvatore Bonaccorso <carnil@debian.org> - 2018-02-17 13:50 +0100
            Re: armel/marvell kernel size Bastian Blank <waldi@debian.org> - 2018-02-17 14:20 +0100
              Re: armel/marvell kernel size Roger Shimizu <rogershimizu@gmail.com> - 2018-03-22 13:00 +0100
            Re: armel/marvell kernel size Roger Shimizu <rogershimizu@gmail.com> - 2018-03-22 13:00 +0100
              Re: armel/marvell kernel size Rogério Brito <rbrito@gmail.com> - 2018-03-22 19:20 +0100
            Re: armel/marvell kernel size Ben Hutchings <ben@decadent.org.uk> - 2018-03-23 00:10 +0100
            Re: armel/marvell kernel size Ben Hutchings <ben@decadent.org.uk> - 2018-03-24 03:00 +0100
              Re: armel/marvell kernel size Rogério Brito <rbrito@gmail.com> - 2018-03-27 07:50 +0200
                Re: armel/marvell kernel size Stefan Monnier <monnier@iro.umontreal.ca> - 2018-03-27 14:40 +0200
                  Re: armel/marvell kernel size Rogério Brito <rbrito@ime.usp.br> - 2018-03-27 22:30 +0200
                    Re: armel/marvell kernel size Rick Thomas <rbthomas@pobox.com> - 2018-03-27 22:50 +0200
                      Re: armel/marvell kernel size Rogério Brito <rbrito@ime.usp.br> - 2018-03-27 23:30 +0200
                        Re: armel/marvell kernel size Rick Thomas <rbthomas@pobox.com> - 2018-03-28 11:30 +0200
                          Re: armel/marvell kernel size Federico Pietro Briata <federico@briata.org> - 2018-03-28 14:30 +0200
                            Re: armel/marvell kernel size Roger Shimizu <rogershimizu@gmail.com> - 2018-04-01 15:30 +0200
                              Re: armel/marvell kernel size Rogério Brito <rbrito@ime.usp.br> - 2018-04-03 08:00 +0200
                                Re: armel/marvell kernel size Roger Shimizu <rogershimizu@gmail.com> - 2018-04-07 16:20 +0200
                                  Re: armel/marvell kernel size Roger Shimizu <rogershimizu@gmail.com> - 2018-04-07 17:00 +0200
                                    Re: armel/marvell kernel size Roger Shimizu <rogershimizu@gmail.com> - 2018-04-13 02:10 +0200
                                      Re: armel/marvell kernel size Roger Shimizu <rogershimizu@gmail.com> - 2018-04-15 18:30 +0200
                          Re: armel/marvell kernel size Rick Thomas <rbthomas@pobox.com> - 2018-04-02 01:50 +0200
                    Re: armel/marvell kernel size Stefan Monnier <monnier@iro.umontreal.ca> - 2018-03-27 23:30 +0200
                Re: armel/marvell kernel size Ben Hutchings <ben@decadent.org.uk> - 2018-03-27 21:10 +0200
                  Re: armel not to be released anymore? (was: armel/marvell kernel  size) Ben Hutchings <ben@decadent.org.uk> - 2018-03-27 21:30 +0200
                  armel not to be released anymore? (was: armel/marvell kernel size) "W. Martin Borgert" <debacle@debian.org> - 2018-03-27 21:40 +0200
                    Re: armel not to be released anymore? (was: armel/marvell kernel size) Paul Wise <pabs@debian.org> - 2018-03-28 06:40 +0200
                  Re: armel/marvell kernel size Rogério Brito <rbrito@ime.usp.br> - 2018-03-27 22:50 +0200

Page 1 of 2  [1] 2  Next page →

#59248 — armel/marvell kernel size

[Multipart message — attachments visible in raw view] — view raw

Sadly, linux has again failed to build on armel in experimental due to
the image size growing too large.

Ben.

-- 
Ben Hutchings
Make three consecutive correct guesses and you will be considered an
expert.

[toc] | [next] | [standalone]

#59255

Dear Ben,

Thanks for the ping!

On Fri, Oct 20, 2017 at 11:07 PM, Ben Hutchings <ben@decadent.org.uk> 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

[toc] | [prev] | [next] | [standalone]

#59272

[Multipart message — attachments visible in raw view] — view raw

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 <ben@decadent.org.uk> 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

[toc] | [prev] | [next] | [standalone]

#59284

On Fri, Oct 27, 2017 at 6:03 AM, Ben Hutchings <ben@decadent.org.uk> 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 <ben@decadent.org.uk> 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

[toc] | [prev] | [next] | [standalone]

#60019

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]

#60045

Dear Ben,

Thanks for keeping armel things rolling for a few releases!

On Thu, Jan 18, 2018 at 1:22 PM, Ben Hutchings <ben@decadent.org.uk> 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

[toc] | [prev] | [next] | [standalone]

#60059

[Multipart message — attachments visible in raw view] — view raw

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 <ben@decadent.org.uk> 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.

[toc] | [prev] | [next] | [standalone]

#60079

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]

#60229

Hi Roger,

On Tue, Jan 23, 2018 at 06:30:23PM +0000, 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 <ben@decadent.org.uk> 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

[toc] | [prev] | [next] | [standalone]

#60230

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

[toc] | [prev] | [next] | [standalone]

#60520

[ CC tbm ]

On Sat, Feb 17, 2018 at 9:57 PM, Bastian Blank <waldi@debian.org> 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

[toc] | [prev] | [next] | [standalone]

#60521

Dear Rogério,

Good to hear from you again!

On Thu, Mar 22, 2018 at 12:12 PM, Rogério Brito <rbrito@ime.usp.br> 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 +0000, 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

[toc] | [prev] | [next] | [standalone]

#60527

Dear Roger and other people!

On Thu, Mar 22, 2018 at 8:40 AM, Roger Shimizu <rogershimizu@gmail.com> 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 <rbrito@ime.usp.br> wrote:
>> On 2018-02-17 10:48, Salvatore Bonaccorso wrote:
>>> On Tue, Jan 23, 2018 at 06:30:23PM +0000, 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/BCFCAAAA
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

[toc] | [prev] | [next] | [standalone]

#60528

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]

#60543

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#60575

Hi Ben and others.

On Fri, Mar 23, 2018 at 10:50 PM, Ben Hutchings <ben@decadent.org.uk> 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/BCFCAAAA
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

[toc] | [prev] | [next] | [standalone]

#60577

> 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.


        Stefan

[toc] | [prev] | [next] | [standalone]

#60584

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/BCFCAAAA
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

[toc] | [prev] | [next] | [standalone]

#60585

On Mar 27, 2018, at 1:04 PM, Rogério Brito <rbrito@ime.usp.br> 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

[toc] | [prev] | [next] | [standalone]

#60588

On 2018-03-27 17:29, Rick Thomas wrote:
> On Mar 27, 2018, at 1:04 PM, Rogério Brito <rbrito@ime.usp.br> 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/BCFCAAAA
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.kernel

csiph-web