Re: [PATCH] arm: omap: reduce zImage size on omap2plus_defconfig

[Felipe Balbi <balbi@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 4999 bytes --]

Hi,

On Thu, Dec 25, 2014 at 12:13:07PM +0200, Igor Grinberg wrote:
> Hi Tony,
> 
> On 12/24/14 21:04, 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).
> 
> Yet, it is not that buggy and at least until now, I di not get any
> reports about badly working SATA from customers...
> 
> >>
> >> 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.
> 
> So, you just continue to ignore what I'm saying... even after I point
> to a device...

you pointed a device which *can* have rootfs on SATA, not one which
*has* rootfs on SATA, there's a very big difference there.

> Is it SATA that makes it so giant?
> Because I find it worth having in SATA than spare some more k's...

that's your point of view. As Tony mentioned, we have a very standard
way of dealing with this which is initramfs and x86 has been using that
for the past 15+ years.

> >> 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?
> 
> Yes. That is exactly my point.

read your email, you said it *CAN* have rootfs on SATA.

> > 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.
> 
> The difference from x86 is that we're in embedded here and

bullshit, you would never ship a product with omap2plus_defconfig. You'd
build your own at which point you would switch SATA to built-in.

> although initramfs is a kind of option, but it means, you need to
> load even more data during the boot process... it is annoying and
> I would not want to use it on embedded.

make your own defconfig.

> (BTW, x86_64_defconfig has it compiled in...)
> 
> We can also, split the defconfig as it was some time ago... but I
> would not want to go that direction...
> 
> If we go the initramfs way, then why not also load MMC from it?
> That will also reduce kernel size... (but add initramfs size)

I'm fine with that. The difference is that people have been relying on
MMC built-in for the past 10+ years, since the old OMAP1 MMC driver,
changing that now is likely to cause some "my board won't boot anymore"
bug reports.

> I'm sure you will find making the MMC a loadable module inconvenient.
> That how I find making the SATA a loadable module...
> 
> Right now, we tell our customers that they can use mainline with
> omap2plus_defconfig.

that's the worst thing you can do. You should at a minimum provide your
customers with a more minimal rootfs. Why would you have your customers
build MUSB on an OMAP5 board ? Why would they build 5 different
network device drivers ? Why would they build almost every single PMIC
we ever used ? The list goes on and on.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]