arm: omap: reduce zImage size on omap2plus_defconfig

By converting a few drivers to modules because they won't be needed during boot anyways, we can shave off about 700KiB of text.

Note that while at that, and after discussions with Tony Lindgren, a few extra drivers were either removed because they weren't needed, or added because they're useful for debugging/testing.

Below is output of size for pre and post vmlinux binaries:

text data bss dec hex filename

8342992  757876 8411840 17512708        10b3904 vmlinux-post-patch
9069110  800316 8419072 18288498        1170f72 vmlinux-pre-patch

Signed-off-by Felipe Balbi <[email protected]>

---
 arch/arm/configs/omap2plus_defconfig | 121 ++++++++++++++++++++++-------------
 1 file changed, 75 insertions(+), 46 deletions(-)

arch/arm/configs/omap2plus_defconfig +75 -46

index c2c3a85..a1dc3ed 100644
@@ -13,7 +13,6 @@ CONFIG_CGROUP_FREEZER=y
 CONFIG_CGROUP_DEVICE=y
 CONFIG_CPUSETS=y
 CONFIG_CGROUP_CPUACCT=y
-CONFIG_RESOURCE_COUNTERS=y
 CONFIG_MEMCG=y
 CONFIG_MEMCG_SWAP=y
 CONFIG_MEMCG_KMEM=y

@@ -68,7 +67,6 @@ CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
 CONFIG_CPU_FREQ_GOV_POWERSAVE=y
 CONFIG_CPU_FREQ_GOV_USERSPACE=y
 CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
-CONFIG_GENERIC_CPUFREQ_CPU0=y
 # CONFIG_ARM_OMAP2PLUS_CPUFREQ is not set
 CONFIG_CPU_IDLE=y
 CONFIG_BINFMT_MISC=y

@@ -103,7 +101,7 @@ CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
 CONFIG_DMA_CMA=y
 CONFIG_OMAP_OCP2SCP=y
-CONFIG_CONNECTOR=y
+CONFIG_CONNECTOR=m
 CONFIG_MTD=y
 CONFIG_MTD_CMDLINE_PARTS=y
 CONFIG_MTD_BLOCK=y

@@ -122,14 +120,13 @@ CONFIG_BLK_DEV_RAM=y
 CONFIG_BLK_DEV_RAM_SIZE=16384
 CONFIG_SENSORS_TSL2550=m
 CONFIG_BMP085_I2C=m
-CONFIG_SENSORS_LIS3_I2C=m
 CONFIG_SRAM=y
+CONFIG_SENSORS_LIS3_I2C=m
 CONFIG_SCSI=y
 CONFIG_BLK_DEV_SD=y
 CONFIG_SCSI_SCAN_ASYNC=y
-CONFIG_ATA=y
-CONFIG_SATA_AHCI_PLATFORM=y
-CONFIG_MD=y
+CONFIG_ATA=m
+CONFIG_SATA_AHCI_PLATFORM=m
 CONFIG_NETDEVICES=y
 # CONFIG_NET_VENDOR_ARC is not set
 # CONFIG_NET_CADENCE is not set

@@ -154,8 +151,8 @@ CONFIG_TI_CPSW=y
 # CONFIG_NET_VENDOR_WIZNET is not set
 CONFIG_AT803X_PHY=y
 CONFIG_SMSC_PHY=y
-CONFIG_USB_USBNET=y
-CONFIG_USB_NET_SMSC95XX=y
+CONFIG_USB_USBNET=m
+CONFIG_USB_NET_SMSC95XX=m
 CONFIG_USB_ALI_M5632=y
 CONFIG_USB_AN2720=y
 CONFIG_USB_EPSON2888=y

@@ -172,18 +169,22 @@ CONFIG_WLCORE_SDIO=m
 CONFIG_MWIFIEX=m
 CONFIG_MWIFIEX_SDIO=m
 CONFIG_MWIFIEX_USB=m
-CONFIG_INPUT_JOYDEV=y
-CONFIG_INPUT_EVDEV=y
-CONFIG_KEYBOARD_GPIO=y
+CONFIG_INPUT_JOYDEV=m
+CONFIG_INPUT_EVDEV=m
+CONFIG_KEYBOARD_ATKBD=m
+CONFIG_KEYBOARD_GPIO=m
 CONFIG_KEYBOARD_MATRIX=m
-CONFIG_KEYBOARD_TWL4030=y
+CONFIG_KEYBOARD_OMAP4=m
+CONFIG_KEYBOARD_TWL4030=m
+# CONFIG_INPUT_MOUSE is not set
 CONFIG_INPUT_TOUCHSCREEN=y
 CONFIG_TOUCHSCREEN_ADS7846=m
 CONFIG_TOUCHSCREEN_EDT_FT5X06=m
 CONFIG_TOUCHSCREEN_TSC2005=m
 CONFIG_TOUCHSCREEN_TSC2007=m
 CONFIG_INPUT_MISC=y
-CONFIG_INPUT_TWL4030_PWRBUTTON=y
+CONFIG_INPUT_TWL4030_PWRBUTTON=m
+CONFIG_SERIO=m
 # CONFIG_LEGACY_PTYS is not set
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y

@@ -196,15 +197,16 @@ CONFIG_SERIAL_8250_RSA=y
 CONFIG_SERIAL_OF_PLATFORM=y
 CONFIG_SERIAL_OMAP=y
 CONFIG_SERIAL_OMAP_CONSOLE=y
-CONFIG_HW_RANDOM=y
 CONFIG_I2C_CHARDEV=y
 CONFIG_SPI=y
 CONFIG_SPI_OMAP24XX=y
+CONFIG_SPI_TI_QSPI=m
 CONFIG_PINCTRL_SINGLE=y
 CONFIG_DEBUG_GPIO=y
 CONFIG_GPIO_SYSFS=y
-CONFIG_GPIO_TWL4030=y
-CONFIG_W1=y
+CONFIG_GPIO_TWL4030=m
+CONFIG_W1=m
+CONFIG_HDQ_MASTER_OMAP=m
 CONFIG_BATTERY_BQ27x00=m
 CONFIG_CHARGER_ISP1704=m
 CONFIG_CHARGER_TWL4030=m

@@ -213,20 +215,21 @@ CONFIG_CHARGER_BQ24190=m
 CONFIG_CHARGER_BQ24735=m
 CONFIG_POWER_RESET=y
 CONFIG_POWER_AVS=y
+CONFIG_HWMON=m
 CONFIG_SENSORS_LM75=m
-CONFIG_THERMAL=y
+CONFIG_SENSORS_TMP102=m
+CONFIG_THERMAL=m
 CONFIG_THERMAL_GOV_FAIR_SHARE=y
 CONFIG_THERMAL_GOV_USER_SPACE=y
 CONFIG_CPU_THERMAL=y
-CONFIG_TI_SOC_THERMAL=y
+CONFIG_TI_SOC_THERMAL=m
 CONFIG_TI_THERMAL=y
 CONFIG_OMAP4_THERMAL=y
 CONFIG_OMAP5_THERMAL=y
 CONFIG_DRA752_THERMAL=y
 CONFIG_WATCHDOG=y
-CONFIG_OMAP_WATCHDOG=y
-CONFIG_TWL4030_WATCHDOG=y
-CONFIG_MFD_SYSCON=y
+CONFIG_OMAP_WATCHDOG=m
+CONFIG_TWL4030_WATCHDOG=m
 CONFIG_MFD_PALMAS=y
 CONFIG_MFD_TPS65217=y
 CONFIG_MFD_TPS65218=y

@@ -289,51 +292,77 @@ CONFIG_SND_OMAP_SOC=m
 CONFIG_SND_OMAP_SOC_OMAP_TWL4030=m
 CONFIG_SND_OMAP_SOC_OMAP_ABE_TWL6040=m
 CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m
-CONFIG_USB=y
+CONFIG_HID_GENERIC=m
+CONFIG_USB_HIDDEV=y
+CONFIG_USB_KBD=m
+CONFIG_USB_MOUSE=m
+CONFIG_USB=m
 CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
-CONFIG_USB_MON=y
+CONFIG_USB_MON=m
 CONFIG_USB_XHCI_HCD=m
-CONFIG_USB_WDM=y
-CONFIG_USB_STORAGE=y
+CONFIG_USB_WDM=m
+CONFIG_USB_STORAGE=m
+CONFIG_USB_MUSB_HDRC=m
+CONFIG_USB_MUSB_OMAP2PLUS=m
+CONFIG_USB_MUSB_AM35X=m
+CONFIG_USB_MUSB_DSPS=m
 CONFIG_USB_DWC3=m
-CONFIG_USB_TEST=y
+CONFIG_USB_TEST=m
 CONFIG_AM335X_PHY_USB=y
-CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET=m
 CONFIG_USB_GADGET_DEBUG=y
 CONFIG_USB_GADGET_DEBUG_FILES=y
 CONFIG_USB_GADGET_DEBUG_FS=y
+CONFIG_USB_CONFIGFS=m
+CONFIG_USB_CONFIGFS_SERIAL=y
+CONFIG_USB_CONFIGFS_ACM=y
+CONFIG_USB_CONFIGFS_OBEX=y
+CONFIG_USB_CONFIGFS_NCM=y
+CONFIG_USB_CONFIGFS_ECM=y
+CONFIG_USB_CONFIGFS_ECM_SUBSET=y
+CONFIG_USB_CONFIGFS_RNDIS=y
+CONFIG_USB_CONFIGFS_EEM=y
+CONFIG_USB_CONFIGFS_MASS_STORAGE=y
+CONFIG_USB_CONFIGFS_F_LB_SS=y
+CONFIG_USB_CONFIGFS_F_FS=y
+CONFIG_USB_CONFIGFS_F_UAC1=y
+CONFIG_USB_CONFIGFS_F_UAC2=y
+CONFIG_USB_CONFIGFS_F_MIDI=y
+CONFIG_USB_CONFIGFS_F_HID=y
 CONFIG_USB_ZERO=m
 CONFIG_MMC=y
 CONFIG_SDIO_UART=y
 CONFIG_MMC_OMAP=y
 CONFIG_MMC_OMAP_HS=y
 CONFIG_NEW_LEDS=y
-CONFIG_LEDS_CLASS=y
-CONFIG_LEDS_GPIO=y
+CONFIG_LEDS_CLASS=m
+CONFIG_LEDS_GPIO=m
 CONFIG_LEDS_TRIGGERS=y
-CONFIG_LEDS_TRIGGER_TIMER=y
-CONFIG_LEDS_TRIGGER_ONESHOT=y
-CONFIG_LEDS_TRIGGER_HEARTBEAT=y
-CONFIG_LEDS_TRIGGER_BACKLIGHT=y
+CONFIG_LEDS_TRIGGER_TIMER=m
+CONFIG_LEDS_TRIGGER_ONESHOT=m
+CONFIG_LEDS_TRIGGER_HEARTBEAT=m
+CONFIG_LEDS_TRIGGER_BACKLIGHT=m
 CONFIG_LEDS_TRIGGER_CPU=y
-CONFIG_LEDS_TRIGGER_GPIO=y
-CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
+CONFIG_LEDS_TRIGGER_GPIO=m
+CONFIG_LEDS_TRIGGER_DEFAULT_ON=m
 CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_TWL92330=y
-CONFIG_RTC_DRV_TWL4030=y
-CONFIG_RTC_DRV_OMAP=y
+CONFIG_RTC_DRV_TWL4030=m
+CONFIG_RTC_DRV_OMAP=m
 CONFIG_DMADEVICES=y
 CONFIG_TI_EDMA=y
 CONFIG_DMA_OMAP=y
-CONFIG_EXTCON=y
-CONFIG_EXTCON_PALMAS=y
+# CONFIG_IOMMU_SUPPORT is not set
+CONFIG_EXTCON=m
+CONFIG_EXTCON_PALMAS=m
+CONFIG_TI_EMIF=m
 CONFIG_PWM=y
-CONFIG_PWM_TIECAP=y
-CONFIG_PWM_TIEHRPWM=y
-CONFIG_PWM_TWL=y
-CONFIG_PWM_TWL_LED=y
-CONFIG_OMAP_USB2=y
-CONFIG_TI_PIPE3=y
+CONFIG_PWM_TIECAP=m
+CONFIG_PWM_TIEHRPWM=m
+CONFIG_PWM_TWL=m
+CONFIG_PWM_TWL_LED=m
+CONFIG_OMAP_USB2=m
+CONFIG_TI_PIPE3=m
 CONFIG_EXT2_FS=y
 CONFIG_EXT3_FS=y
 # CONFIG_EXT3_FS_XATTR is not set

Signature · 1 line

2.2.0

CONFIG_USB_ANNOUNCE_NEW_DEVICES=y

arch/arm/configs/omap2plus_defconfig +7 -3

-CONFIG_USB_MON=y
+CONFIG_USB_MON=m
 CONFIG_USB_XHCI_HCD=m
-CONFIG_USB_WDM=y
-CONFIG_USB_STORAGE=y
+CONFIG_USB_WDM=m
+CONFIG_USB_STORAGE=m
+CONFIG_USB_MUSB_HDRC=m
+CONFIG_USB_MUSB_OMAP2PLUS=m
+CONFIG_USB_MUSB_AM35X=m
+CONFIG_USB_MUSB_DSPS=m

Hi Felipe,

On 12/22/14 20:05, Felipe Balbi wrote:

[...]

arch/arm/configs/omap2plus_defconfig CONFIG_BLK_DEV_RAM=y · line 129

Quoted 6 lines

CONFIG_SCSI_SCAN_ASYNC=y

arch/arm/configs/omap2plus_defconfig +2 -3

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

Quoted 5 lines

CONFIG_NETDEVICES=y
# CONFIG_NET_VENDOR_ARC is not set
# CONFIG_NET_CADENCE is not set

arch/arm/configs/omap2plus_defconfig +0 -0

@@ -154,8 +151,8 @@ CONFIG_TI_CPSW=y
 # CONFIG_NET_VENDOR_WIZNET is not set

arch/arm/configs/omap2plus_defconfig CONFIG_TI_CPSW=y · line 155

Quoted 6 lines

arch/arm/configs/omap2plus_defconfig +2 -2

 CONFIG_AT803X_PHY=y
 CONFIG_SMSC_PHY=y
-CONFIG_USB_USBNET=y
-CONFIG_USB_NET_SMSC95XX=y
+CONFIG_USB_USBNET=m
+CONFIG_USB_NET_SMSC95XX=m

What about the NFS root for boards with only USB eth?

arch/arm/configs/omap2plus_defconfig CONFIG_SERIAL_8250_RSA=y · line 207

Quoted 5 lines

arch/arm/configs/omap2plus_defconfig +1 -2

 CONFIG_DEBUG_GPIO=y
 CONFIG_GPIO_SYSFS=y
-CONFIG_GPIO_TWL4030=y
-CONFIG_W1=y
+CONFIG_GPIO_TWL4030=m

w/o this devices wired to twl gpios will not come up and likely will miss the enumeration...

arch/arm/configs/omap2plus_defconfig CONFIG_SND_OMAP_SOC=m · line 299

Quoted 6 lines

arch/arm/configs/omap2plus_defconfig +5 -1

-CONFIG_USB=y
+CONFIG_HID_GENERIC=m
+CONFIG_USB_HIDDEV=y
+CONFIG_USB_KBD=m
+CONFIG_USB_MOUSE=m
+CONFIG_USB=m

So, you don't consider USB a valid rootfs storage option?

Quoted 9 lines · Igor Grinberg

arch/arm/configs/omap2plus_defconfig CONFIG_SERIAL_8250_RSA=y · line 207

Quoted 5 lines · Felipe Balbi

CONFIG_DEBUG_GPIO=y
CONFIG_GPIO_SYSFS=y

arch/arm/configs/omap2plus_defconfig +1 -2

-CONFIG_GPIO_TWL4030=y
-CONFIG_W1=y
+CONFIG_GPIO_TWL4030=m

w/o this devices wired to twl gpios will not come up and likely will miss the enumeration...

for example ?

Quoted 11 lines · Felipe Balbi

Quoted 9 lines · Igor Grinberg

Review

Quoted 5 lines · Felipe Balbi

CONFIG_DEBUG_GPIO=y
CONFIG_GPIO_SYSFS=y

(quoted diff) +1 -2

-CONFIG_GPIO_TWL4030=y
-CONFIG_W1=y
+CONFIG_GPIO_TWL4030=m

w/o this devices wired to twl gpios will not come up and likely will miss the enumeration...

Quoted 1 line

for example ?

The TWL4030 part needs to be checked for the legacy booting to make sure the board-*.c file *_twl_gpio_setup() callbacks still work properly. Or you may want to leave it for later.

From fcda0df51e3138f4901516fe850020968ca228a3 Mon Sep 17 00:00:00 2001

Quoted 6 lines · Igor Grinberg

Hi Felipe,

On 12/22/14 20:05, Felipe Balbi wrote:

[...]

Quoted 8 lines

arch/arm/configs/omap2plus_defconfig CONFIG_BLK_DEV_RAM=y · line 129

Quoted 6 lines

CONFIG_SCSI_SCAN_ASYNC=y

arch/arm/configs/omap2plus_defconfig +2 -3

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

Quoted 14 lines

arch/arm/configs/omap2plus_defconfig CONFIG_TI_CPSW=y · line 155

Quoted 12 lines

CONFIG_NETDEVICES=y
# CONFIG_NET_VENDOR_ARC is not set
# CONFIG_NET_CADENCE is not set

arch/arm/configs/omap2plus_defconfig +2 -2

@@ -154,8 +151,8 @@ CONFIG_TI_CPSW=y
 # CONFIG_NET_VENDOR_WIZNET is not set
 CONFIG_AT803X_PHY=y
 CONFIG_SMSC_PHY=y
-CONFIG_USB_USBNET=y
-CONFIG_USB_NET_SMSC95XX=y
+CONFIG_USB_USBNET=m
+CONFIG_USB_NET_SMSC95XX=m

What about the NFS root for boards with only USB eth?

USB is a module already and it breaks PM when enabled.

Quoted 8 lines

arch/arm/configs/omap2plus_defconfig CONFIG_SND_OMAP_SOC=m · line 299

Quoted 6 lines

arch/arm/configs/omap2plus_defconfig +5 -1

-CONFIG_USB=y
+CONFIG_HID_GENERIC=m
+CONFIG_USB_HIDDEV=y
+CONFIG_USB_KBD=m
+CONFIG_USB_MOUSE=m
+CONFIG_USB=m

So, you don't consider USB a valid rootfs storage option?

read the original defconfig. This is *only* for usbcore.ko, EHCI is disabled, XHCI is a module, MUSB is disabled. What will you use for rootfs ?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 16 lines · Felipe Balbi

Quoted 14 lines · Igor Grinberg

Hi Felipe,

On 12/22/14 20:05, Felipe Balbi wrote:

[...]

arch/arm/configs/omap2plus_defconfig CONFIG_BLK_DEV_RAM=y · line 129

Quoted 6 lines

CONFIG_SCSI_SCAN_ASYNC=y

arch/arm/configs/omap2plus_defconfig +2 -3

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

Quoted 2 lines

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

Quoted 9 lines

Quoted 8 lines

arch/arm/configs/omap2plus_defconfig CONFIG_SND_OMAP_SOC=m · line 299

Quoted 6 lines

arch/arm/configs/omap2plus_defconfig +5 -1

-CONFIG_USB=y
+CONFIG_HID_GENERIC=m
+CONFIG_USB_HIDDEV=y
+CONFIG_USB_KBD=m
+CONFIG_USB_MOUSE=m
+CONFIG_USB=m

So, you don't consider USB a valid rootfs storage option?

Quoted 3 lines

read the original defconfig. This is *only* for usbcore.ko, EHCI is disabled, XHCI is a module, MUSB is disabled. What will you use for rootfs ?

Yes, thanks for pointing. Now I see indeed this is a sensible thing to do and probably should have been done a while ago.

Might be worth addressing/explaining this in the commit message.

Hi,

Quoted 20 lines · Igor Grinberg

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 16 lines · Felipe Balbi

Quoted 14 lines · Igor Grinberg

Hi Felipe,

On 12/22/14 20:05, Felipe Balbi wrote:

[...]

arch/arm/configs/omap2plus_defconfig CONFIG_BLK_DEV_RAM=y · line 129

Quoted 6 lines

CONFIG_SCSI_SCAN_ASYNC=y

arch/arm/configs/omap2plus_defconfig +2 -3

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

Quoted 6 lines

Quoted 2 lines

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.

Quoted 26 lines · Felipe Balbi

Hi,

Quoted 23 lines · Igor Grinberg

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 18 lines · Felipe Balbi

Quoted 6 lines · Igor Grinberg

Hi Felipe,

On 12/22/14 20:05, Felipe Balbi wrote:

[...]

Quoted 8 lines

arch/arm/configs/omap2plus_defconfig CONFIG_BLK_DEV_RAM=y · line 129

Quoted 6 lines

CONFIG_SCSI_SCAN_ASYNC=y

arch/arm/configs/omap2plus_defconfig +2 -3

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

Quoted 8 lines

Quoted 3 lines

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

Quoted 4 lines

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.

Quoted 2 lines

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?

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.

Hi Tony,

Quoted 27 lines · Tony Lindgren

Quoted 26 lines · Felipe Balbi

Hi,

Quoted 23 lines · Igor Grinberg

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 18 lines · Felipe Balbi

Quoted 6 lines · Igor Grinberg

Hi Felipe,

On 12/22/14 20:05, Felipe Balbi wrote:

[...]

Quoted 8 lines

Review

Quoted 6 lines

CONFIG_SCSI_SCAN_ASYNC=y

(quoted diff) +2 -3

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

Quoted 8 lines

Quoted 8 lines

Quoted 3 lines

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

Quoted 1 line

Quoted 1 line

Quoted 3 lines

Quoted 3 lines

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

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

Quoted 16 lines

Quoted 1 line

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.

Quoted 1 line

Are there people really using SATA as rootfs right now on omaps?

Yes. That is exactly my point.

Quoted 4 lines

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

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.

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

Hi,

Quoted 47 lines · Igor Grinberg

Hi Tony,

Quoted 27 lines · Tony Lindgren

Quoted 26 lines · Felipe Balbi

Hi,

Quoted 23 lines · Igor Grinberg

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 18 lines · Felipe Balbi

Quoted 6 lines · Igor Grinberg

Hi Felipe,

On 12/22/14 20:05, Felipe Balbi wrote:

[...]

Quoted 8 lines

Review

Quoted 6 lines

CONFIG_SCSI_SCAN_ASYNC=y

(quoted diff) +2 -3

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

Quoted 8 lines

Quoted 8 lines

Quoted 3 lines

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

Quoted 4 lines

Quoted 4 lines

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.

Quoted 2 lines

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.

Quoted 3 lines

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.

Quoted 17 lines

Quoted 17 lines

Quoted 2 lines

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.

Quoted 3 lines

Quoted 1 line

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.

Quoted 7 lines

Quoted 5 lines

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.

Quoted 4 lines

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.

Quoted 6 lines

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

Quoted 2 lines

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.

Quoted 6 lines

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.

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

Quoted 1 line

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.

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

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.

Quoted 3 lines

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.

Quoted 5 lines

Quoted 3 lines

Right now, we tell our customers that they can use mainline with omap2plus_defconfig.

that's the worst thing you can do.

Hello all,

Quoted 9 lines · Igor Grinberg

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

Quoted 1 line

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.

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

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.

I do agree with Tony and Felipe that we should try to build as much stuff as possible as a module instead of built-in to match what distros do and what has been done for x86 for years.

However, if that's the case I wonder what's the point of having both an omap2plus_defconfig and a multi_v7_defconfig? Would it make sense

to get rid of the SoC specific configs then and just use the single ARMv7 defconfig for all SoCs with most of the options enabled as a module?

FYI, some time ago I posted a patch to enable SBS-compliant batteries support as a module for Exynos defconfig and was told to re-spin the patch and enabling it as built-in instead since the most popular use case for exynos_defconfig was development and people usually just copy the kernel binary and not the modules [0].

So it seems that each ARM SoC community has a different opinion about how things should be configured and do it differently.

Quoted 3 lines

Quoted 2 lines

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.

There are different opinions but let please try to keep the discussion constructive and use a polite tone.

Quoted 4 lines

Quoted 4 lines

Quoted 3 lines

Right now, we tell our customers that they can use mainline with omap2plus_defconfig.

Quoted 2 lines

Quoted 1 line

that's the worst thing you can do.

I'm confused, Felipe said that customers should not base their config from omap2plus_defconfig but AFAUI Tony's argument is exactly the opposite, that everything should be configured as a module so distros

can use omap2plus_defconfig as a base. So, is or is not expected that people will use omap2plus_defconfig as a base for their own config?

I think the problem is that there isn't an agreement about what is the purpose of the per SoC (e.g: oma2plus_defconfig) and the multi_v7 defconfigs (or at least is not well documented since I could not find it). So, IMHO this concern should be raised to the ARM SoC maintainers and there should be an agreement in the ARM community as a whole about how things should be configured on each defconfig, and all SoCs should follow the agreed rule.

Otherwise it seems that the motivation for each kconfig symbol enabled is just to make the workflow of the developer posting the patches easier and wins whoever shouts louder.

I wonder the same thing, but look at multi_v7_defconfig today. Almost everything is built-in, which makes the kernel image enormous (5.5MiB).

Quoted 3 lines

to get rid of the SoC specific configs then and just use the single ARMv7 defconfig for all SoCs with most of the options enabled as a module?

if people accept switching some of those as modules, sure. I don't mind that at all. I'll still continue to maintain my out-of-tree defconfigs for my boards anyway. It's also very good to have a generic defconfig which will just work with everything I have.

Quoted 5 lines

FYI, some time ago I posted a patch to enable SBS-compliant batteries support as a module for Exynos defconfig and was told to re-spin the patch and enabling it as built-in instead since the most popular use case for exynos_defconfig was development and people usually just copy the kernel binary and not the modules [0].

lol, that's the reason why I don't use multi_v7_defconfig.

Quoted 2 lines

can use omap2plus_defconfig as a base. So, is or is not expected that people will use omap2plus_defconfig as a base for their own config?

I never claimed that people should not use it as a *base*, rather it should not be used to build a product's kernel/modules. Imagine you shipping an embedded product based off of OMAP5 and you add CPSW, QSPI, MUSB, a ton of touchscreen drivers you don't use, several PMIC drivers built-in, etc. It's a waste of space and just bloats that product's zImage.

Quoted 7 lines

I think the problem is that there isn't an agreement about what is the purpose of the per SoC (e.g: oma2plus_defconfig) and the multi_v7 defconfigs (or at least is not well documented since I could not find it). So, IMHO this concern should be raised to the ARM SoC maintainers and there should be an agreement in the ARM community as a whole about how things should be configured on each defconfig, and all SoCs should follow the agreed rule.

OTOH, the OMAP defconfig is part of the OMAP port and Tony will have the final saying about it, right ?

Quoted 18 lines

I wonder the same thing, but look at multi_v7_defconfig today. Almost everything is built-in, which makes the kernel image enormous (5.5MiB).

Quoted 3 lines

to get rid of the SoC specific configs then and just use the single ARMv7 defconfig for all SoCs with most of the options enabled as a module?

if people accept switching some of those as modules, sure. I don't mind that at all. I'll still continue to maintain my out-of-tree defconfigs for my boards anyway. It's also very good to have a generic defconfig which will just work with everything I have.

Quoted 5 lines

FYI, some time ago I posted a patch to enable SBS-compliant batteries support as a module for Exynos defconfig and was told to re-spin the patch and enabling it as built-in instead since the most popular use case for exynos_defconfig was development and people usually just copy the kernel binary and not the modules [0].

Quoted 2 lines

lol, that's the reason why I don't use multi_v7_defconfig.

Agreed, on its current form I wonder what's the use case for multi_v7_defconfig. I guess most options will slowly be changed to be built as a module though to be similar to what distros do.

Quoted 10 lines

Quoted 2 lines

can use omap2plus_defconfig as a base. So, is or is not expected that people will use omap2plus_defconfig as a base for their own config?

I never claimed that people should not use it as a *base*, rather it should not be used to build a product's kernel/modules. Imagine you shipping an embedded product based off of OMAP5 and you add CPSW, QSPI, MUSB, a ton of touchscreen drivers you don't use, several PMIC drivers built-in, etc. It's a waste of space and just bloats that product's zImage.

Got it, thanks for the clarification. I agree that omap2plus_defconfig is very bloated to be used for products as-is. I also have custom defconfig to test the OMAP boards I maintain which is basically omap2plus_defconfig + a merged config fragment (using merge_config.sh) that disables and enables needed options.

Quoted 8 lines

Quoted 7 lines

I think the problem is that there isn't an agreement about what is the purpose of the per SoC (e.g: oma2plus_defconfig) and the multi_v7 defconfigs (or at least is not well documented since I could not find it). So, IMHO this concern should be raised to the ARM SoC maintainers and there should be an agreement in the ARM community as a whole about how things should be configured on each defconfig, and all SoCs should follow the agreed rule.

Quoted 3 lines

OTOH, the OMAP defconfig is part of the OMAP port and Tony will have the final saying about it, right ?

Sorry, I didn't mean that Tony doesn't have the last word for omap defconfig. My point was that it should be nice to get a consensus about this and specially document it to make life easier for everyone.

People posting defconfig changes will know what the rule is and we can avoid having these kind of discussions which I have had many times in the past when posting defconfig changes and I'm sure I will have more in the future again.

But I don't really mind tbh, I will keep maintaining my custom defconfigs anyways and post wnen I think that enabling a config option in a mainline defconfig makes sense and will do as a module or built-in depending of what the SoC maintainer tells me to use.

Quoted 16 lines

Quoted 16 lines

Quoted 16 lines

Quoted 1 line

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.

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

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.

yep, it also *CAN* have rootfs on MMC and NFS and ...

Quoted 7 lines

Quoted 6 lines

Quoted 4 lines

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

Quoted 2 lines

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.

Yep, that is one of the options indeed, but I'm not asking you to deal with my problems, right?
I'm feeling like you are trying to insult me.
Are you angry with me? Why?
Is it because I have a different opinion?

Quoted 5 lines

Quoted 3 lines

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.

This sounds like: mind your own business...
Is that what you want to say?

Quoted 8 lines

Quoted 7 lines

(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)

Quoted 4 lines

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.

Yep. So there are exceptions, right?

Quoted 7 lines

Quoted 5 lines

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.

Hmmm... Interesting, so people should not use mainline.

Quoted 2 lines

You should at a minimum provide your
customers with a more minimal rootfs. Why would you have your customers

Quoted 3 lines

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.

That is their decision to make. I'm just saying that they can use it.

Hi,

Quoted 18 lines · Igor Grinberg

Quoted 18 lines

Quoted 18 lines

Quoted 17 lines

Quoted 1 line

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?

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

Yes. That is exactly my point.

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

yep, it also *CAN* have rootfs on MMC and NFS and ...

those we *know* people are using as rootfs. We know of several users who are actually using it :-)

Quoted 11 lines

Quoted 10 lines

Quoted 7 lines

Quoted 5 lines

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.

Quoted 5 lines

Yep, that is one of the options indeed, but I'm not asking you to deal with my problems, right?
I'm feeling like you are trying to insult me.
Are you angry with me? Why?
Is it because I have a different opinion?

heh, cute :-)

Quoted 9 lines

Quoted 6 lines

Quoted 4 lines

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.

This sounds like: mind your own business...
Is that what you want to say?

nope, not really.

Just saying that if you're really concerned about
being embedded and that initramfs takes that much more time to load, you'd just make your own defconfig and maintain it out-of-tree.

RMK does that for quite a few boards, I do it for my boards and also for my x86 desktops/laptops.

It's not really rocket science.

Quoted 9 lines

Quoted 9 lines

Quoted 8 lines

(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)

Quoted 6 lines

Quoted 4 lines

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.

Yep. So there are exceptions, right?

never claimed the contrary.

Quoted 7 lines

Quoted 7 lines

Quoted 6 lines

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.

Quoted 3 lines

Quoted 1 line

that's the worst thing you can do.

Hmmm... Interesting, so people should not use mainline.

now you're reading what you want to read ;-) Using my statements out of context.

It's clear (actually s/rootfs/defconfig below) that I meant defconfig.

Quoted 2 lines

Quoted 2 lines

You should at a minimum provide your
customers with a more minimal rootfs. Why would you have your customers

oh wait, not rootfs, defconfig.

Quoted 5 lines

Quoted 3 lines

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.

That is their decision to make. I'm just saying that they can use it.

right, and they can switch SATA to built-in if they want to ship an initramfs-less product, don't you think ?

Hi Tony,

Quoted 27 lines · Tony Lindgren

Quoted 26 lines · Felipe Balbi

Hi,

Quoted 23 lines · Igor Grinberg

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 18 lines · Felipe Balbi

Quoted 6 lines · Igor Grinberg

Hi Felipe,

On 12/22/14 20:05, Felipe Balbi wrote:

[...]

Quoted 8 lines

Review

Quoted 6 lines

CONFIG_SCSI_SCAN_ASYNC=y

(quoted diff) +2 -3

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

Quoted 8 lines

Quoted 8 lines

Quoted 3 lines

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

Quoted 4 lines

Quoted 4 lines

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

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

Quoted 2 lines

Quoted 2 lines

Tony, your call

Quoted 15 lines

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.

Quoted 1 line

Are there people really using SATA as rootfs right now on omaps?

Yes. That is exactly my point.

From my side I'd like to note that I know about few ongoing projects on DRA7x EVM

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Tony, your call

May be it will be good thing to split this patch. That way more information will be stored in commit log about which set of options gives us what benefits. And also, It will allow to continue with agreed changes. ?

Quoted 14 lines

Quoted 14 lines

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.

Quoted 4 lines

Quoted 1 line

Are there people really using SATA as rootfs right now on omaps?

Yes. That is exactly my point.

From my side I'd like to note that I know about few ongoing projects on DRA7x EVM where SATA is used as rootfs - now It is the fast possible way to start Android.

Quoted 7 lines · Grygorii.Strashko at linaro.org

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Tony, your call

May be it will be good thing to split this patch. That way more information will be stored in commit log about which set of options gives us what benefits. And also, It will allow to continue with agreed changes. ?

can be done, but then again, it's just a defconfig change. Tony, your call.

Quoted 19 lines

Quoted 18 lines

Quoted 7 lines

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.

Quoted 8 lines

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.

Quoted 3 lines

From my side I'd like to note that I know about few ongoing projects on DRA7x EVM where SATA is used as rootfs - now It is the fast possible way to start Android.

now this is something different. This is evidence that there are people relying on SATA on rootfs. I'll leave to Tony again.

Quoted 31 lines · Felipe Balbi

Quoted 7 lines · Grygorii.Strashko at linaro.org

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Tony, your call

May be it will be good thing to split this patch. That way more information will be stored in commit log about which set of options gives us what benefits. And also, It will allow to continue with agreed changes. ?

can be done, but then again, it's just a defconfig change. Tony, your call.

Quoted 19 lines

Quoted 18 lines

Quoted 7 lines

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.

Quoted 8 lines

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.

Quoted 6 lines

Quoted 3 lines

From my side I'd like to note that I know about few ongoing projects on DRA7x EVM where SATA is used as rootfs - now It is the fast possible way to start Android.

now this is something different. This is evidence that there are people relying on SATA on rootfs. I'll leave to Tony again.

OK sounds like people are really using SATA as rootfs, so we might as well keep it built in then. And it does not affect the PM on the devices that do have PM working, that has been a problem with having some drivers built-in.

We can still work towards making the current rootfs device drivers into loadable modules in the long term :)

From 7e6d99cedb12004bad1205bbaf556ebf3db0f730 Mon Sep 17 00:00:00 2001

Quoted 44 lines · Tony Lindgren

Quoted 31 lines · Felipe Balbi

Quoted 7 lines · Grygorii.Strashko at linaro.org

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Tony, your call

May be it will be good thing to split this patch. That way more information will be stored in commit log about which set of options gives us what benefits. And also, It will allow to continue with agreed changes. ?

can be done, but then again, it's just a defconfig change. Tony, your call.

Quoted 19 lines

Quoted 18 lines

Quoted 7 lines

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.

Quoted 8 lines

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.

Quoted 6 lines

Quoted 3 lines

From my side I'd like to note that I know about few ongoing projects on DRA7x EVM where SATA is used as rootfs - now It is the fast possible way to start Android.

now this is something different. This is evidence that there are people relying on SATA on rootfs. I'll leave to Tony again.

OK sounds like people are really using SATA as rootfs, so we might as well keep it built in then. And it does not affect the PM on the devices that do have PM working, that has been a problem with having some drivers built-in.

Quoted 2 lines

We can still work towards making the current rootfs device drivers into loadable modules in the long term :)

Here's v3:

Quoted 35 lines · Felipe Balbi

Hi,

Quoted 20 lines · Igor Grinberg

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 16 lines · Felipe Balbi

Quoted 14 lines · Igor Grinberg

Hi Felipe,

On 12/22/14 20:05, Felipe Balbi wrote:

[...]

arch/arm/configs/omap2plus_defconfig CONFIG_BLK_DEV_RAM=y · line 129

Quoted 6 lines

CONFIG_SCSI_SCAN_ASYNC=y

arch/arm/configs/omap2plus_defconfig +2 -3

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

Quoted 6 lines

Quoted 2 lines

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

Quoted 5 lines

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?

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.

Hi,

Quoted 56 lines · Tony Lindgren

Quoted 35 lines · Felipe Balbi

Hi,

Quoted 20 lines · Igor Grinberg

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 16 lines · Felipe Balbi

Quoted 14 lines · Igor Grinberg

Hi Felipe,

On 12/22/14 20:05, Felipe Balbi wrote:

[...]

Review

Quoted 6 lines

CONFIG_SCSI_SCAN_ASYNC=y

(quoted diff) +2 -3

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

Quoted 6 lines

Quoted 2 lines

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

Quoted 5 lines

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.

Quoted 1 line

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,

the latter being mostly used by TIers as of
now (at least from mainline point of view).

Quoted 5 lines

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.

Quoted 14 lines

Quoted 14 lines

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.

Quoted 4 lines

Quoted 1 line

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.

Quoted 2 lines

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