Re: armel/marvell kernel size
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
Reply to: