From: Igor Grinberg <grinberg@compulab.co.il>
To: balbi@ti.com, Tony Lindgren <tony@atomide.com>
Cc: Linux OMAP Mailing List <linux-omap@vger.kernel.org>,
Linux ARM Kernel Mailing List
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] arm: omap: reduce zImage size on omap2plus_defconfig
Date: Fri, 26 Dec 2014 14:08:10 +0200 [thread overview]
Message-ID: <549D4FAA.1040207@compulab.co.il> (raw)
In-Reply-To: <20141226043719.GA7661@saruman>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 12/26/14 06:37, Felipe Balbi wrote:
> Hi,
>
> On Wed, Dec 24, 2014 at 11:04:01AM -0800, Tony Lindgren wrote:
>> * Felipe Balbi <balbi@ti.com> [141224 07:52]:
>>> Hi,
>>>
>>> On Wed, Dec 24, 2014 at 01:53:46PM +0200, Igor Grinberg wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> On 12/23/14 18:19, Felipe Balbi wrote:
>>>>> On Tue, Dec 23, 2014 at 09:30:45AM +0200, Igor Grinberg wrote:
>>>>>> Hi Felipe,
>>>>>>
>>>>>> On 12/22/14 20:05, Felipe Balbi wrote:
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>> CONFIG_SCSI_SCAN_ASYNC=y
>>>>>>> -CONFIG_ATA=y
>>>>>>> -CONFIG_SATA_AHCI_PLATFORM=y
>>>>>>> -CONFIG_MD=y
>>>>>>> +CONFIG_ATA=m
>>>>>>> +CONFIG_SATA_AHCI_PLATFORM=m
>>>>>>
>>>>>> Isn't this needed for the rootfs on SATA devices?
>>>>>
>>>>> there's no known boards with rootfs on SATA. Until then, we can reduce
>>>>> the size.
>>>>
>>>> What makes you say so?
>>>> The decision for rootfs on SATA is taken dynamically.
>>>> OMAP5 boards (specifically cm-t54) can have rootfs on SATA...
>>>
>>> I'll leave the decision to Tony. Even though they _can_, they really
>>> don't and IIRC, OMAP5's SATA has so many silicon errata that it'd be
>>> annoying to find that special device which works (e.g it can't negotiate
>>> lower speeds with SATA III devices and it won't support SATA I).
>>>
>>> As of today, we don't know of anybody really shipping anything with
>>> rootfs on SATA and distros would rather ship initiramfs than a giant
>>> zImage anyway.
>>>
>>> Tony, your call.
>>
>> I think we should move omap2plus_defconfig to be mostly modular and
>> usable for distros as a base. Most distros prefer to build almost
>> everything as loadable modules. And my preference is that we should
>> only keep the minimum rootfs for devices and serial support as
>> built-in and rely on initramfs for most drivers. And slowly move
>> also the remaining built-in drivers to be loadable modules.
>>
>> The reasons for having drivers as loadable modules are many. It
>> allows distros to use the same kernel for all the devices without
>> bloating the kernel. It makes developing drivers easier as just the
>> module needs to be reloaded. And loadable modules protect us from
>> cross-framework spaghetti calls in the kernel as the interfaces are
>> clearly defined.
>>
>> Are there people really using SATA as rootfs right now on omaps?
>
> not that we know :-) The only platforms available today with SATA are
> OMAP5432 uEVM and DRA7x EVM,
I'm sorry... that is not true.
> the latter being mostly used by TIers as of
> now (at least from mainline point of view).
the keyword is mostly... And I'm also not sure this is true these days...
But, really, don't mind me. We will find our solutions (we always did).
I mean, Felipe wants it out so badly...
Who am I to say anything...
>
>> If it's only something that will be more widely used in the future,
>> then I suggest we make it into a loadable module, and presume
>> initramfs and loadable module also for any new devices. The same
>> way x86 has been doing with distros for years.
>
> alright, as a module it shall remain.
>
- --
Regards,
Igor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBAgAGBQJUnU+qAAoJEBDE8YO64Efa8IgP/jQlP5nHLK8aWXpNIrRH3dri
IzIDvWqUC+zYqIgg1JcPmxgfZ+5vhYgjCVx+q0m/81qk164QK4zGs6gDr8sDjK8O
Q8rqujAbVFO2nmJHmq8VhTpapqTDtG5sH/HvtaWPtBxmBoA5yLdA8KObV9Gf2871
GvlP1WS/CUu6ClzEERsdWJkfpkqrJ1My1Ox7zCkL80uqM5z6jmje2sam4AiuGWSK
Kb/Kdkmqae1lizjSnyW0ZckTyCuLUPdzvV+OCq3JrDDJV9W3hrA0KmYKUe4gO0JI
Z2PNMKvbBuA9miY0IPsbILYkQ01OoKOwZXfDrhhK0k5FLPxSujc9NbfwqByTK2gi
Ca5zZKoTaUN8A2YoxdNv+m9gILnlgDCtRjvc6elEYZBLZd+03TsxgWAB+aYfx03d
1W5+qp8jSGBRzsDg5o8ir6mS8xYM3Hpy7xDPT46BqjKzczMCdeXH5MqibL34kqtC
mMhMw1UzZ5qGOyHXqYE9bosgfpbf+WxmVta7/RRgaJJwo7N41pf1sDyoJjczAfPo
cAQNeIwPd1DxiS2nO46i4w8FUq10Lf3I7mXxabXIsU3YD81QpjxL5arlFXlPfDVg
Ki8GW1yE81RepD5xuhhz3/U9pKvozSewH5BlHBo6h9rSBkyyBPs2NbxSxjSNct1H
MKEG/rYHptCRIntrZ8pm
=w62Y
-----END PGP SIGNATURE-----
WARNING: multiple messages have this Message-ID (diff)
From: grinberg@compulab.co.il (Igor Grinberg)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm: omap: reduce zImage size on omap2plus_defconfig
Date: Fri, 26 Dec 2014 14:08:10 +0200 [thread overview]
Message-ID: <549D4FAA.1040207@compulab.co.il> (raw)
In-Reply-To: <20141226043719.GA7661@saruman>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 12/26/14 06:37, Felipe Balbi wrote:
> Hi,
>
> On Wed, Dec 24, 2014 at 11:04:01AM -0800, Tony Lindgren wrote:
>> * Felipe Balbi <balbi@ti.com> [141224 07:52]:
>>> Hi,
>>>
>>> On Wed, Dec 24, 2014 at 01:53:46PM +0200, Igor Grinberg wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> On 12/23/14 18:19, Felipe Balbi wrote:
>>>>> On Tue, Dec 23, 2014 at 09:30:45AM +0200, Igor Grinberg wrote:
>>>>>> Hi Felipe,
>>>>>>
>>>>>> On 12/22/14 20:05, Felipe Balbi wrote:
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>> CONFIG_SCSI_SCAN_ASYNC=y
>>>>>>> -CONFIG_ATA=y
>>>>>>> -CONFIG_SATA_AHCI_PLATFORM=y
>>>>>>> -CONFIG_MD=y
>>>>>>> +CONFIG_ATA=m
>>>>>>> +CONFIG_SATA_AHCI_PLATFORM=m
>>>>>>
>>>>>> Isn't this needed for the rootfs on SATA devices?
>>>>>
>>>>> there's no known boards with rootfs on SATA. Until then, we can reduce
>>>>> the size.
>>>>
>>>> What makes you say so?
>>>> The decision for rootfs on SATA is taken dynamically.
>>>> OMAP5 boards (specifically cm-t54) can have rootfs on SATA...
>>>
>>> I'll leave the decision to Tony. Even though they _can_, they really
>>> don't and IIRC, OMAP5's SATA has so many silicon errata that it'd be
>>> annoying to find that special device which works (e.g it can't negotiate
>>> lower speeds with SATA III devices and it won't support SATA I).
>>>
>>> As of today, we don't know of anybody really shipping anything with
>>> rootfs on SATA and distros would rather ship initiramfs than a giant
>>> zImage anyway.
>>>
>>> Tony, your call.
>>
>> I think we should move omap2plus_defconfig to be mostly modular and
>> usable for distros as a base. Most distros prefer to build almost
>> everything as loadable modules. And my preference is that we should
>> only keep the minimum rootfs for devices and serial support as
>> built-in and rely on initramfs for most drivers. And slowly move
>> also the remaining built-in drivers to be loadable modules.
>>
>> The reasons for having drivers as loadable modules are many. It
>> allows distros to use the same kernel for all the devices without
>> bloating the kernel. It makes developing drivers easier as just the
>> module needs to be reloaded. And loadable modules protect us from
>> cross-framework spaghetti calls in the kernel as the interfaces are
>> clearly defined.
>>
>> Are there people really using SATA as rootfs right now on omaps?
>
> not that we know :-) The only platforms available today with SATA are
> OMAP5432 uEVM and DRA7x EVM,
I'm sorry... that is not true.
> the latter being mostly used by TIers as of
> now (at least from mainline point of view).
the keyword is mostly... And I'm also not sure this is true these days...
But, really, don't mind me. We will find our solutions (we always did).
I mean, Felipe wants it out so badly...
Who am I to say anything...
>
>> If it's only something that will be more widely used in the future,
>> then I suggest we make it into a loadable module, and presume
>> initramfs and loadable module also for any new devices. The same
>> way x86 has been doing with distros for years.
>
> alright, as a module it shall remain.
>
- --
Regards,
Igor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBAgAGBQJUnU+qAAoJEBDE8YO64Efa8IgP/jQlP5nHLK8aWXpNIrRH3dri
IzIDvWqUC+zYqIgg1JcPmxgfZ+5vhYgjCVx+q0m/81qk164QK4zGs6gDr8sDjK8O
Q8rqujAbVFO2nmJHmq8VhTpapqTDtG5sH/HvtaWPtBxmBoA5yLdA8KObV9Gf2871
GvlP1WS/CUu6ClzEERsdWJkfpkqrJ1My1Ox7zCkL80uqM5z6jmje2sam4AiuGWSK
Kb/Kdkmqae1lizjSnyW0ZckTyCuLUPdzvV+OCq3JrDDJV9W3hrA0KmYKUe4gO0JI
Z2PNMKvbBuA9miY0IPsbILYkQ01OoKOwZXfDrhhK0k5FLPxSujc9NbfwqByTK2gi
Ca5zZKoTaUN8A2YoxdNv+m9gILnlgDCtRjvc6elEYZBLZd+03TsxgWAB+aYfx03d
1W5+qp8jSGBRzsDg5o8ir6mS8xYM3Hpy7xDPT46BqjKzczMCdeXH5MqibL34kqtC
mMhMw1UzZ5qGOyHXqYE9bosgfpbf+WxmVta7/RRgaJJwo7N41pf1sDyoJjczAfPo
cAQNeIwPd1DxiS2nO46i4w8FUq10Lf3I7mXxabXIsU3YD81QpjxL5arlFXlPfDVg
Ki8GW1yE81RepD5xuhhz3/U9pKvozSewH5BlHBo6h9rSBkyyBPs2NbxSxjSNct1H
MKEG/rYHptCRIntrZ8pm
=w62Y
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2014-12-26 12:08 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-22 18:05 [PATCH] arm: omap: reduce zImage size on omap2plus_defconfig Felipe Balbi
2014-12-22 18:05 ` Felipe Balbi
2014-12-22 18:11 ` Felipe Balbi
2014-12-22 18:11 ` Felipe Balbi
2014-12-23 7:30 ` Igor Grinberg
2014-12-23 7:30 ` Igor Grinberg
2014-12-23 16:19 ` Felipe Balbi
2014-12-23 16:19 ` Felipe Balbi
2014-12-23 16:56 ` Tony Lindgren
2014-12-23 16:56 ` Tony Lindgren
2014-12-23 17:07 ` Felipe Balbi
2014-12-23 17:07 ` Felipe Balbi
2014-12-24 11:53 ` Igor Grinberg
2014-12-24 11:53 ` Igor Grinberg
2014-12-24 15:49 ` Felipe Balbi
2014-12-24 15:49 ` Felipe Balbi
2014-12-24 19:04 ` Tony Lindgren
2014-12-24 19:04 ` Tony Lindgren
2014-12-25 10:13 ` Igor Grinberg
2014-12-25 10:13 ` Igor Grinberg
2014-12-26 4:42 ` Felipe Balbi
2014-12-26 4:42 ` Felipe Balbi
2014-12-26 11:56 ` Igor Grinberg
2014-12-26 11:56 ` Igor Grinberg
2014-12-26 13:42 ` Javier Martinez Canillas
2014-12-26 13:42 ` Javier Martinez Canillas
2014-12-26 15:19 ` Felipe Balbi
2014-12-26 15:19 ` Felipe Balbi
2014-12-26 19:38 ` Javier Martinez Canillas
2014-12-26 19:38 ` Javier Martinez Canillas
2014-12-26 19:47 ` Felipe Balbi
2014-12-26 19:47 ` Felipe Balbi
2014-12-26 15:09 ` Felipe Balbi
2014-12-26 15:09 ` Felipe Balbi
2014-12-26 16:43 ` Igor Grinberg
2014-12-26 16:43 ` Igor Grinberg
2014-12-26 13:04 ` Grygorii.Strashko@linaro.org
2014-12-26 13:04 ` Grygorii.Strashko@linaro.org
2014-12-26 15:26 ` Felipe Balbi
2014-12-26 15:26 ` Felipe Balbi
2014-12-26 16:13 ` Tony Lindgren
2014-12-26 16:13 ` Tony Lindgren
2014-12-26 16:26 ` Felipe Balbi
2014-12-26 16:26 ` Felipe Balbi
2015-01-08 0:43 ` Tony Lindgren
2015-01-08 0:43 ` Tony Lindgren
2014-12-26 4:37 ` Felipe Balbi
2014-12-26 4:37 ` Felipe Balbi
2014-12-26 12:08 ` Igor Grinberg [this message]
2014-12-26 12:08 ` Igor Grinberg
2014-12-26 15:24 ` Felipe Balbi
2014-12-26 15:24 ` Felipe Balbi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=549D4FAA.1040207@compulab.co.il \
--to=grinberg@compulab.co.il \
--cc=balbi@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.