Groups > linux.kernel > #1288507 > unrolled thread

Re: [PATCH 0/5] ARM: orion5x/dove/mv78xx0 multiplatform

Started by	Arnd Bergmann <arnd@arndb.de>
First post	2015-12-10 14:20 +0100
Last post	2015-12-11 22:40 +0100
Articles	13 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

  Re: [PATCH 0/5] ARM: orion5x/dove/mv78xx0 multiplatform Arnd Bergmann <arnd@arndb.de> - 2015-12-10 14:20 +0100
    Re: [PATCH 0/5] ARM: orion5x/dove/mv78xx0 multiplatform Arnd Bergmann <arnd@arndb.de> - 2015-12-10 14:50 +0100
      Re: [PATCH 0/5] ARM: orion5x/dove/mv78xx0 multiplatform Arnd Bergmann <arnd@arndb.de> - 2015-12-10 22:10 +0100
        Re: [PATCH 0/5] ARM: orion5x/dove/mv78xx0 multiplatform Arnd Bergmann <arnd@arndb.de> - 2015-12-10 22:40 +0100
          Re: [PATCH 0/5] ARM: orion5x/dove/mv78xx0 multiplatform Arnd Bergmann <arnd@arndb.de> - 2015-12-11 00:20 +0100
            Re: [PATCH 0/5] ARM: orion5x/dove/mv78xx0 multiplatform Jason Cooper <jason@lakedaemon.net> - 2015-12-11 14:40 +0100
              Re: [PATCH 0/5] ARM: orion5x/dove/mv78xx0 multiplatform Arnd Bergmann <arnd@arndb.de> - 2015-12-11 15:50 +0100
                Re: [PATCH 0/5] ARM: orion5x/dove/mv78xx0 multiplatform Jason Cooper <jason@lakedaemon.net> - 2015-12-11 16:00 +0100
              Re: [PATCH 0/5] ARM: orion5x/dove/mv78xx0 multiplatform Josh Triplett <josh@joshtriplett.org> - 2015-12-11 19:30 +0100
                Re: [PATCH 0/5] ARM: orion5x/dove/mv78xx0 multiplatform Jason Cooper <jason@lakedaemon.net> - 2015-12-11 19:50 +0100
                  Re: [PATCH 0/5] ARM: orion5x/dove/mv78xx0 multiplatform Josh Triplett <josh@joshtriplett.org> - 2015-12-11 20:10 +0100
                    Re: [PATCH 0/5] ARM: orion5x/dove/mv78xx0 multiplatform Jason Cooper <jason@lakedaemon.net> - 2015-12-11 20:20 +0100
    Re: [PATCH 0/5] ARM: orion5x/dove/mv78xx0 multiplatform Arnd Bergmann <arnd@arndb.de> - 2015-12-11 22:40 +0100

#1288507 — Re: [PATCH 0/5] ARM: orion5x/dove/mv78xx0 multiplatform

From	Arnd Bergmann <arnd@arndb.de>
Date	2015-12-10 14:20 +0100
Subject	Re: [PATCH 0/5] ARM: orion5x/dove/mv78xx0 multiplatform
Message-ID	<qE9iy-6It-9@gated-at.bofh.it>

On Thursday 10 December 2015 13:56:05 Detlef Vollmann wrote:
> On 11/30/15 14:43, Gregory CLEMENT wrote:
> >> Detlef, Benjamin,
> >>
> >> could you test it on an Orion5x based board?
> Ok, I tested the v2 series on v4.4-rc3 on my
> DNS-323: Identified HW revision B1
> Orion ID: MV88F5182-A2. TCLK=166666667.
> 
> Only basic tests, serial port and network.
> 
> The good news:
> orion5x_defconfig works and is even slightly smaller than the
> original v4.4-rc3 kernel image.
> 
> The bad news:
> My own config (which is massivly stripped down) produces a kernel
> image that's more than 26K bigger than on v4.4-rc3 without any
> added functionality.
> The DNS-323 is extremly constrained in space (the whole system
> including boot loader, kernel and filesystem has to fit into 8M flash).
> Any ideas how I can get rid of this additional overhead?

Can you send me your config file? I can have a look.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1288515

From	Arnd Bergmann <arnd@arndb.de>
Date	2015-12-10 14:50 +0100
Message-ID	<qE9LA-6Ua-9@gated-at.bofh.it>
In reply to	#1288507

On Thursday 10 December 2015 14:18:11 Arnd Bergmann wrote:
> On Thursday 10 December 2015 13:56:05 Detlef Vollmann wrote:
> > On 11/30/15 14:43, Gregory CLEMENT wrote:
> > >> Detlef, Benjamin,
> > >>
> > >> could you test it on an Orion5x based board?
> > Ok, I tested the v2 series on v4.4-rc3 on my
> > DNS-323: Identified HW revision B1
> > Orion ID: MV88F5182-A2. TCLK=166666667.
> > 
> > Only basic tests, serial port and network.
> > 
> > The good news:
> > orion5x_defconfig works and is even slightly smaller than the
> > original v4.4-rc3 kernel image.
> > 
> > The bad news:
> > My own config (which is massivly stripped down) produces a kernel
> > image that's more than 26K bigger than on v4.4-rc3 without any
> > added functionality.
> > The DNS-323 is extremly constrained in space (the whole system
> > including boot loader, kernel and filesystem has to fit into 8M flash).
> > Any ideas how I can get rid of this additional overhead?
> 
> Can you send me your config file? I can have a look.
> 

I've done a quick check with an allnoconfig-like test and it seems that
CONFIG_OF is weighing in at around 86K here, with all the other options
it pulls in, comparing an allnoconfig kernel for DS-323 with one that
has CONFIG_OF enabled as well.

The multiplatform kernel also enables CONFIG_OF unconditionally, but is
otherwise a little smaller than the mach-orion5x based one:

   text    data     bss     dec     hex filename
 942144   64112   17648 1023904   f9fa0 build/tmp/vmlinux-orion-allno
1027516   54052   20824 1102392  10d238 build/tmp/vmlinux-multi-plus-orion
1025320   66020   18744 1110084  10f044 build/tmp/vmlinux-orion-plus-of

The diff below shows all the differences between orion-allno and
multi-plus-orion.

	Arnd

--- config-orion	2015-12-10 14:25:05.609113585 +0100
+++ .config	2015-12-10 14:24:29.646879038 +0100
@@ -3,6 +3,8 @@
 # Linux/arm 4.4.0-rc4 Kernel Configuration
 #
 CONFIG_ARM=y
+CONFIG_ARM_HAS_SG_CHAIN=y
+CONFIG_MIGHT_HAVE_PCI=y
 CONFIG_SYS_SUPPORTS_APM_EMULATION=y
 CONFIG_STACKTRACE_SUPPORT=y
 CONFIG_LOCKDEP_SUPPORT=y
@@ -14,8 +16,7 @@
 CONFIG_NEED_DMA_MAP_STATE=y
 CONFIG_ARCH_SUPPORTS_UPROBES=y
 CONFIG_VECTORS_BASE=0xffff0000
-# CONFIG_ARM_PATCH_PHYS_VIRT is not set
-CONFIG_PHYS_OFFSET=0x0
+CONFIG_ARM_PATCH_PHYS_VIRT=y
 CONFIG_PGTABLE_LEVELS=2
 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
 CONFIG_BUILDTIME_EXTABLE_SORT=y
@@ -56,6 +57,7 @@
 CONFIG_IRQ_DOMAIN=y
 CONFIG_HANDLE_DOMAIN_IRQ=y
 CONFIG_IRQ_FORCED_THREADING=y
+CONFIG_SPARSE_IRQ=y
 CONFIG_GENERIC_CLOCKEVENTS=y
 
 #
@@ -186,7 +188,7 @@
 # System Type
 #
 CONFIG_MMU=y
-# CONFIG_ARCH_MULTIPLATFORM is not set
+CONFIG_ARCH_MULTIPLATFORM=y
 # CONFIG_ARCH_VERSATILE is not set
 # CONFIG_ARCH_CLPS711X is not set
 # CONFIG_ARCH_GEMINI is not set
@@ -198,9 +200,6 @@
 # CONFIG_ARCH_IOP32X is not set
 # CONFIG_ARCH_IOP33X is not set
 # CONFIG_ARCH_IXP4XX is not set
-# CONFIG_ARCH_DOVE is not set
-# CONFIG_ARCH_MV78XX0 is not set
-CONFIG_ARCH_ORION5X=y
 # CONFIG_ARCH_KS8695 is not set
 # CONFIG_ARCH_W90X900 is not set
 # CONFIG_ARCH_LPC32XX is not set
@@ -212,8 +211,29 @@
 # CONFIG_ARCH_OMAP1 is not set
 
 #
-# Orion Implementations
+# Multiple platform selection
+#
+
 #
+# CPU Core family selection
+#
+# CONFIG_ARCH_MULTI_V4 is not set
+# CONFIG_ARCH_MULTI_V4T is not set
+CONFIG_ARCH_MULTI_V5=y
+CONFIG_ARCH_MULTI_V4_V5=y
+# CONFIG_ARCH_MULTI_V6 is not set
+# CONFIG_ARCH_MULTI_V7 is not set
+CONFIG_ARCH_MULTI_CPU_AUTO=y
+# CONFIG_ARCH_MVEBU is not set
+# CONFIG_MACH_ASM9260 is not set
+# CONFIG_ARCH_AT91 is not set
+# CONFIG_ARCH_INTEGRATOR is not set
+# CONFIG_ARCH_MV78XX0 is not set
+# CONFIG_ARCH_MXC is not set
+# CONFIG_ARCH_MXS is not set
+# CONFIG_ARCH_NOMADIK is not set
+# CONFIG_ARCH_NSPIRE is not set
+CONFIG_ARCH_ORION5X=y
 # CONFIG_ARCH_ORION5X_DT is not set
 # CONFIG_MACH_DB88F5281 is not set
 # CONFIG_MACH_RD88F5182 is not set
@@ -237,6 +257,11 @@
 # CONFIG_MACH_RD88F5181L_GE is not set
 # CONFIG_MACH_RD88F5181L_FXO is not set
 # CONFIG_MACH_RD88F6183AP_GE is not set
+# CONFIG_ARCH_MMP is not set
+# CONFIG_ARCH_REALVIEW is not set
+# CONFIG_PLAT_SPEAR is not set
+# CONFIG_ARCH_U300 is not set
+# CONFIG_ARCH_WM8505 is not set
 CONFIG_PLAT_ORION=y
 CONFIG_PLAT_ORION_LEGACY=y
 
@@ -286,6 +311,10 @@
 #
 # PCI host controller drivers
 #
+# CONFIG_PCI_HOST_GENERIC is not set
+# CONFIG_PCI_LAYERSCAPE is not set
+# CONFIG_PCIE_IPROC is not set
+# CONFIG_PCIE_ALTERA is not set
 # CONFIG_PCIEPORTBUS is not set
 # CONFIG_PCCARD is not set
 
@@ -346,16 +375,16 @@
 #
 # Boot options
 #
-# CONFIG_USE_OF is not set
+CONFIG_USE_OF=y
 CONFIG_ATAGS=y
 # CONFIG_DEPRECATED_PARAM_STRUCT is not set
 CONFIG_ZBOOT_ROM_TEXT=0
 CONFIG_ZBOOT_ROM_BSS=0
+# CONFIG_ARM_APPENDED_DTB is not set
 CONFIG_CMDLINE=""
-# CONFIG_XIP_KERNEL is not set
 # CONFIG_KEXEC is not set
 # CONFIG_CRASH_DUMP is not set
-# CONFIG_AUTO_ZRELADDR is not set
+CONFIG_AUTO_ZRELADDR=y
 
 #
 # CPU Power Management
@@ -427,8 +456,20 @@
 #
 # CONFIG_BRCMSTB_GISB_ARB is not set
 CONFIG_MVEBU_MBUS=y
+# CONFIG_VEXPRESS_CONFIG is not set
 # CONFIG_MTD is not set
-# CONFIG_OF is not set
+CONFIG_DTC=y
+CONFIG_OF=y
+# CONFIG_OF_UNITTEST is not set
+CONFIG_OF_FLATTREE=y
+CONFIG_OF_EARLY_FLATTREE=y
+CONFIG_OF_ADDRESS=y
+CONFIG_OF_ADDRESS_PCI=y
+CONFIG_OF_IRQ=y
+CONFIG_OF_PCI=y
+CONFIG_OF_PCI_IRQ=y
+CONFIG_OF_RESERVED_MEM=y
+# CONFIG_OF_OVERLAY is not set
 CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y
 # CONFIG_PARPORT is not set
 
@@ -550,17 +591,26 @@
 # Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
 #
 CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y
+CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
 CONFIG_ARCH_REQUIRE_GPIOLIB=y
 CONFIG_GPIOLIB=y
 CONFIG_GPIO_DEVRES=y
+CONFIG_OF_GPIO=y
 # CONFIG_DEBUG_GPIO is not set
 
 #
 # Memory mapped GPIO drivers
 #
+# CONFIG_GPIO_74XX_MMIO is not set
+# CONFIG_GPIO_ALTERA is not set
 # CONFIG_GPIO_DWAPB is not set
+# CONFIG_GPIO_EM is not set
 # CONFIG_GPIO_GENERIC_PLATFORM is not set
+# CONFIG_GPIO_GRGPIO is not set
+CONFIG_GPIO_MVEBU=y
 # CONFIG_GPIO_VX855 is not set
+# CONFIG_GPIO_XILINX is not set
+# CONFIG_GPIO_ZEVIO is not set
 # CONFIG_GPIO_ZX is not set
 
 #
@@ -597,8 +647,11 @@
 # Multifunction device drivers
 #
 # CONFIG_MFD_CORE is not set
+# CONFIG_MFD_ATMEL_FLEXCOM is not set
+# CONFIG_MFD_ATMEL_HLCDC is not set
 # CONFIG_MFD_CROS_EC is not set
 # CONFIG_MFD_ASIC3 is not set
+# CONFIG_MFD_HI6421_PMIC is not set
 # CONFIG_HTC_EGPIO is not set
 # CONFIG_HTC_PASIC3 is not set
 # CONFIG_LPC_ICH is not set
@@ -670,6 +723,7 @@
 #
 # Common Clock Framework
 #
+# CONFIG_CLK_QORIQ is not set
 # CONFIG_COMMON_CLK_PXA is not set
 
 #
@@ -679,6 +733,8 @@
 #
 # Clock Source drivers
 #
+CONFIG_CLKSRC_OF=y
+CONFIG_CLKSRC_PROBE=y
 CONFIG_CLKSRC_MMIO=y
 # CONFIG_ARM_TIMER_SP804 is not set
 # CONFIG_ATMEL_PIT is not set
@@ -711,6 +767,7 @@
 # CONFIG_NTB is not set
 # CONFIG_VME_BUS is not set
 # CONFIG_PWM is not set
+CONFIG_IRQCHIP=y
 # CONFIG_IPACK_BUS is not set
 # CONFIG_RESET_CONTROLLER is not set
 # CONFIG_FMC is not set
@@ -907,7 +964,7 @@
 CONFIG_DEBUG_UART_8250_SHIFT=2
 # CONFIG_DEBUG_UART_8250_WORD is not set
 # CONFIG_DEBUG_UART_8250_FLOW_CONTROL is not set
-CONFIG_UNCOMPRESS_INCLUDE="mach/uncompress.h"
+CONFIG_UNCOMPRESS_INCLUDE="debug/uncompress.h"
 # CONFIG_CORESIGHT is not set
 
 #
@@ -924,6 +981,8 @@
 #
 # Library routines
 #
+CONFIG_BITREVERSE=y
+# CONFIG_HAVE_ARCH_BITREVERSE is not set
 CONFIG_RATIONAL=y
 CONFIG_GENERIC_STRNCPY_FROM_USER=y
 CONFIG_GENERIC_STRNLEN_USER=y
@@ -935,7 +994,12 @@
 # CONFIG_CRC16 is not set
 # CONFIG_CRC_T10DIF is not set
 # CONFIG_CRC_ITU_T is not set
-# CONFIG_CRC32 is not set
+CONFIG_CRC32=y
+# CONFIG_CRC32_SELFTEST is not set
+CONFIG_CRC32_SLICEBY8=y
+# CONFIG_CRC32_SLICEBY4 is not set
+# CONFIG_CRC32_SARWATE is not set
+# CONFIG_CRC32_BIT is not set
 # CONFIG_CRC7 is not set
 # CONFIG_LIBCRC32C is not set
 # CONFIG_CRC8 is not set
@@ -952,6 +1016,7 @@
 CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
 # CONFIG_CORDIC is not set
 # CONFIG_DDR is not set
+CONFIG_LIBFDT=y
 # CONFIG_SG_SPLIT is not set
-# CONFIG_ARCH_HAS_SG_CHAIN is not set
+CONFIG_ARCH_HAS_SG_CHAIN=y
 # CONFIG_VIRTUALIZATION is not set

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1288932

From	Arnd Bergmann <arnd@arndb.de>
Date	2015-12-10 22:10 +0100
Message-ID	<qEgDo-33z-25@gated-at.bofh.it>
In reply to	#1288515

On Thursday 10 December 2015 20:03:18 Detlef Vollmann wrote:
> On 12/10/15 14:43, Arnd Bergmann wrote:
> > On Thursday 10 December 2015 14:18:11 Arnd Bergmann wrote:
> >> On Thursday 10 December 2015 13:56:05 Detlef Vollmann wrote:
> 
> >>> The bad news:
> >>> My own config (which is massivly stripped down) produces a kernel
> >>> image that's more than 26K bigger than on v4.4-rc3 without any
> >>> added functionality.
> >>> The DNS-323 is extremly constrained in space (the whole system
> >>> including boot loader, kernel and filesystem has to fit into 8M flash).
> >>> Any ideas how I can get rid of this additional overhead?
> >>
> >> Can you send me your config file? I can have a look.
> >>
> > 
> > I've done a quick check with an allnoconfig-like test and it seems that
> > CONFIG_OF is weighing in at around 86K here, with all the other options
> > it pulls in, comparing an allnoconfig kernel for DS-323 with one that
> > has CONFIG_OF enabled as well.
> > 
> > The multiplatform kernel also enables CONFIG_OF unconditionally, but is
> > otherwise a little smaller than the mach-orion5x based one:
> > 
> >    text    data     bss     dec     hex filename
> >  942144   64112   17648 1023904   f9fa0 build/tmp/vmlinux-orion-allno
> > 1027516   54052   20824 1102392  10d238 build/tmp/vmlinux-multi-plus-orion
> > 1025320   66020   18744 1110084  10f044 build/tmp/vmlinux-orion-plus-of
> > 
> > The diff below shows all the differences between orion-allno and
> > multi-plus-orion.
> How did you get the orion-allno config and how did you get it compiled?
> I tried to apply your changes to my config and compile it, but
> it started silentoldconfig which introduced back 'ARCH_MULTIPLATFORM'

The first and third row are without my patches, once they are applied,
ARCH_ORION becomes a sub-option of ARCH_MULTIPLATFORM.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1288944

From	Arnd Bergmann <arnd@arndb.de>
Date	2015-12-10 22:40 +0100
Message-ID	<qEh6q-3f7-33@gated-at.bofh.it>
In reply to	#1288932

On Thursday 10 December 2015 22:14:25 Detlef Vollmann wrote:
> On 12/10/15 21:59, Arnd Bergmann wrote:
> > On Thursday 10 December 2015 20:03:18 Detlef Vollmann wrote:
> >> On 12/10/15 14:43, Arnd Bergmann wrote:
> >>>    text    data     bss     dec     hex filename
> >>>  942144   64112   17648 1023904   f9fa0 build/tmp/vmlinux-orion-allno
> >>> 1027516   54052   20824 1102392  10d238 build/tmp/vmlinux-multi-plus-orion
> >>> 1025320   66020   18744 1110084  10f044 build/tmp/vmlinux-orion-plus-of
> >>>
> >>> The diff below shows all the differences between orion-allno and
> >>> multi-plus-orion.
> >> How did you get the orion-allno config and how did you get it compiled?
> >> I tried to apply your changes to my config and compile it, but
> >> it started silentoldconfig which introduced back 'ARCH_MULTIPLATFORM'
> > 
> > The first and third row are without my patches, once they are applied,
> > ARCH_ORION becomes a sub-option of ARCH_MULTIPLATFORM.
>
> So with your patches it's no longer possible to build a small kernel, correct?

Correct. I was a bit surprised at how much object code enabling CONFIG_OF
adds these days, it used to be a lot less, but you are right that
disabling CONFIG_OF is not possible with the way that ARCH_MULTIPLATFORM
is structured.

It was always the plan to move all orion5x machines over to use CONFIG_OF
eventually, so you get that overhead one way or another, and at least
it looks like doing multiplatform on top of OF doesn't add any noticeable
extra overhead (the total numbers are actually smaller).

It may also be worth investigating what has made CONFIG_OF so costly,
maybe we can reduce this a bit again.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1289003

From	Arnd Bergmann <arnd@arndb.de>
Date	2015-12-11 00:20 +0100
Message-ID	<qEiFb-4qp-3@gated-at.bofh.it>
In reply to	#1288944

On Thursday 10 December 2015 23:00:24 Detlef Vollmann wrote:
> On 12/10/15 22:29, Arnd Bergmann wrote:
> > On Thursday 10 December 2015 22:14:25 Detlef Vollmann wrote:
> >> On 12/10/15 21:59, Arnd Bergmann wrote:
> > It may also be worth investigating what has made CONFIG_OF so costly,
> Probably because too much is done at runtime and too few things can
> be fixed at build time.
> 
> > maybe we can reduce this a bit again.
> Probably not without turning the wheel backward :-(
> 
> So for the test: yes it works, but I'm unhappy with it.

I'm not too happy about adding 80kb to the uncompressed kernel 
image either. I've spent some more time now trying to find where
we added the bloat. It's mainly in drivers, not in arch specific
code, a kilobyte here and there eventually adds up, but the largest
portion with a little over 50% of the total diff is drivers/of.

I don't expect to find a lot of low-hanging fruit there. For
reference, see the diff of 'size -A' below.

	Arnd

 
-orion5x_defconfig-dt/arch/arm/kernel/built-in.o  :
+orion5x_defconfig-nodt/arch/arm/kernel/built-in.o  :
--
-Total                                    48034
+Total                                    46863
 
 
-orion5x_defconfig-dt/arch/arm/mm/built-in.o  :
+orion5x_defconfig-nodt/arch/arm/mm/built-in.o  :
--
-Total                                       43680
+Total                                       43672
 
 
-orion5x_defconfig-dt/arch/arm/plat-orion/built-in.o  :
+orion5x_defconfig-nodt/arch/arm/plat-orion/built-in.o  :
--
-Total                                     22131
+Total                                     22103
 

-orion5x_defconfig-dt/drivers/ata/built-in.o  :
+orion5x_defconfig-nodt/drivers/ata/built-in.o  :


-Total                                                  160244
+Total                                                  159524
 
 
-orion5x_defconfig-dt/drivers/base/built-in.o  :
+orion5x_defconfig-nodt/drivers/base/built-in.o  :
--
-Total                                                      111366
+Total                                                      109090
 
 
-orion5x_defconfig-dt/drivers/bus/built-in.o  :
+orion5x_defconfig-nodt/drivers/bus/built-in.o  :
-Total                                        10151
+Total                                        8120
 
 
-orion5x_defconfig-dt/drivers/clk/built-in.o  :
+orion5x_defconfig-nodt/drivers/clk/built-in.o  :
--
-Total                                                  35514
+Total                                                  29469
 
 
-orion5x_defconfig-dt/drivers/crypto/built-in.o  :
+orion5x_defconfig-nodt/drivers/crypto/built-in.o  :
--
-Total             8712
+Total             8552
 
 
-orion5x_defconfig-dt/drivers/dma/built-in.o  :
+orion5x_defconfig-nodt/drivers/dma/built-in.o  :
--
-Total                                             18939
+Total                                             16186
 
 
-orion5x_defconfig-dt/drivers/gpio/built-in.o  :
+orion5x_defconfig-nodt/drivers/gpio/built-in.o  :
--
-Total                                               26663
+Total                                               19142
 
 
-orion5x_defconfig-dt/drivers/i2c/built-in.o  :
+orion5x_defconfig-nodt/drivers/i2c/built-in.o  :
--
-Total                                                  25772
+Total                                                  23778
 
 
-orion5x_defconfig-dt/drivers/input/built-in.o  :
+orion5x_defconfig-nodt/drivers/input/built-in.o  :
--
-Total                                          39847
+Total                                          38531
 
 
-orion5x_defconfig-dt/drivers/leds/built-in.o  :
+orion5x_defconfig-nodt/drivers/leds/built-in.o  :
--
-Total                                          10436
+Total                                          10372
 
 
-orion5x_defconfig-dt/drivers/misc/built-in.o  :
+orion5x_defconfig-nodt/drivers/misc/built-in.o  :
--
-Total             3163
+Total             1939
 
 
-orion5x_defconfig-dt/drivers/mtd/built-in.o  :
+orion5x_defconfig-nodt/drivers/mtd/built-in.o  :
--
-Total                                              162074
+Total                                              157383
 
 
-orion5x_defconfig-dt/drivers/net/built-in.o  :
+orion5x_defconfig-nodt/drivers/net/built-in.o  :
--
-Total                                    50038
+Total                                    46757
 
 
-orion5x_defconfig-dt/drivers/of/built-in.o  :
+orion5x_defconfig-nodt/drivers/of/built-in.o  :
--
-Total                                             46444
+Total                                             0
 
 
-orion5x_defconfig-dt/drivers/pci/built-in.o  :
+orion5x_defconfig-nodt/drivers/pci/built-in.o  :
--
-Total                                                   115926
+Total                                                   115352
 
 
-orion5x_defconfig-dt/drivers/perf/built-in.o  :
+orion5x_defconfig-nodt/drivers/perf/built-in.o  :
--
-Total                              4796
+Total                              4202
 
 
-orion5x_defconfig-dt/drivers/phy/built-in.o  :
+orion5x_defconfig-nodt/drivers/phy/built-in.o  :
--
-Total                                            5529
+Total                                            4909
 
 
-orion5x_defconfig-dt/drivers/rtc/built-in.o  :
+orion5x_defconfig-nodt/drivers/rtc/built-in.o  :
--
-Total                                       35840
+Total                                       35024
 
 
-orion5x_defconfig-dt/drivers/tty/built-in.o  :
+orion5x_defconfig-nodt/drivers/tty/built-in.o  :
--
-Total                                              125096
+Total                                              119738
 
 
-orion5x_defconfig-dt/drivers/usb/built-in.o  :
+orion5x_defconfig-nodt/drivers/usb/built-in.o  :
--
-Total                                                251268
+Total                                                250498
 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1289571

From	Jason Cooper <jason@lakedaemon.net>
Date	2015-12-11 14:40 +0100
Message-ID	<qEw5t-52w-25@gated-at.bofh.it>
In reply to	#1289003

+Josh

Hey Arnd, Detlef,

On Fri, Dec 11, 2015 at 12:10:55AM +0100, Arnd Bergmann wrote:
> On Thursday 10 December 2015 23:00:24 Detlef Vollmann wrote:
> > On 12/10/15 22:29, Arnd Bergmann wrote:
> > > On Thursday 10 December 2015 22:14:25 Detlef Vollmann wrote:
> > >> On 12/10/15 21:59, Arnd Bergmann wrote:
> > > It may also be worth investigating what has made CONFIG_OF so costly,
> > Probably because too much is done at runtime and too few things can
> > be fixed at build time.
> > 
> > > maybe we can reduce this a bit again.
> > Probably not without turning the wheel backward :-(
> > 
> > So for the test: yes it works, but I'm unhappy with it.
> 
> I'm not too happy about adding 80kb to the uncompressed kernel 
> image either. I've spent some more time now trying to find where
> we added the bloat. It's mainly in drivers, not in arch specific
> code, a kilobyte here and there eventually adds up, but the largest
> portion with a little over 50% of the total diff is drivers/of.

Wasn't there an idea kicked around a while ago to create a
dt2boardfile script/executable*?  Then, during kernel configuration, you
enable it and select which dts file you want.  It would disable
CONFIG_OF, multiplatform, etc.  And generate a board_file.c from the dts
file.

If anything, it might be worth asking the kernel tinification [1], [2]
folks if they'd be interested in taking this on...


thx,

Jason.

* This may have been completely in my head...

[1] http://events.linuxfoundation.org/sites/events/files/slides/tiny.pdf
[2] https://tiny.wiki.kernel.org/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1289641

From	Arnd Bergmann <arnd@arndb.de>
Date	2015-12-11 15:50 +0100
Message-ID	<qExbb-5Nm-7@gated-at.bofh.it>
In reply to	#1289571

On Friday 11 December 2015 13:36:01 Jason Cooper wrote:
> +Josh
> 
> Hey Arnd, Detlef,
> 
> On Fri, Dec 11, 2015 at 12:10:55AM +0100, Arnd Bergmann wrote:
> > On Thursday 10 December 2015 23:00:24 Detlef Vollmann wrote:
> > > On 12/10/15 22:29, Arnd Bergmann wrote:
> > > > On Thursday 10 December 2015 22:14:25 Detlef Vollmann wrote:
> > > >> On 12/10/15 21:59, Arnd Bergmann wrote:
> > > > It may also be worth investigating what has made CONFIG_OF so costly,
> > > Probably because too much is done at runtime and too few things can
> > > be fixed at build time.
> > > 
> > > > maybe we can reduce this a bit again.
> > > Probably not without turning the wheel backward 
> > > 
> > > So for the test: yes it works, but I'm unhappy with it.
> > 
> > I'm not too happy about adding 80kb to the uncompressed kernel 
> > image either. I've spent some more time now trying to find where
> > we added the bloat. It's mainly in drivers, not in arch specific
> > code, a kilobyte here and there eventually adds up, but the largest
> > portion with a little over 50% of the total diff is drivers/of.
> 
> Wasn't there an idea kicked around a while ago to create a
> dt2boardfile script/executable*?  Then, during kernel configuration, you
> enable it and select which dts file you want.  It would disable
> CONFIG_OF, multiplatform, etc.  And generate a board_file.c from the dts
> file.

I think you are right this has come up in the past, but I don't see how
it would work in practice without significant changes to driver subsystems:

The way we describe devices in DT is often very different from what we
have for the traditional board files, and in some cases we don't even
support platform data any more, so this would still depend on having
properties according to the DT bindings, and require a large chunk of
the same code that is doing DT at the moment.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1289653

From	Jason Cooper <jason@lakedaemon.net>
Date	2015-12-11 16:00 +0100
Message-ID	<qExkS-5QI-19@gated-at.bofh.it>
In reply to	#1289641

On Fri, Dec 11, 2015 at 03:46:53PM +0100, Arnd Bergmann wrote:
> On Friday 11 December 2015 13:36:01 Jason Cooper wrote:
> > +Josh
> > 
> > Hey Arnd, Detlef,
> > 
> > On Fri, Dec 11, 2015 at 12:10:55AM +0100, Arnd Bergmann wrote:
> > > On Thursday 10 December 2015 23:00:24 Detlef Vollmann wrote:
> > > > On 12/10/15 22:29, Arnd Bergmann wrote:
> > > > > On Thursday 10 December 2015 22:14:25 Detlef Vollmann wrote:
> > > > >> On 12/10/15 21:59, Arnd Bergmann wrote:
> > > > > It may also be worth investigating what has made CONFIG_OF so costly,
> > > > Probably because too much is done at runtime and too few things can
> > > > be fixed at build time.
> > > > 
> > > > > maybe we can reduce this a bit again.
> > > > Probably not without turning the wheel backward 
> > > > 
> > > > So for the test: yes it works, but I'm unhappy with it.
> > > 
> > > I'm not too happy about adding 80kb to the uncompressed kernel 
> > > image either. I've spent some more time now trying to find where
> > > we added the bloat. It's mainly in drivers, not in arch specific
> > > code, a kilobyte here and there eventually adds up, but the largest
> > > portion with a little over 50% of the total diff is drivers/of.
> > 
> > Wasn't there an idea kicked around a while ago to create a
> > dt2boardfile script/executable*?  Then, during kernel configuration, you
> > enable it and select which dts file you want.  It would disable
> > CONFIG_OF, multiplatform, etc.  And generate a board_file.c from the dts
> > file.
> 
> I think you are right this has come up in the past, but I don't see how
> it would work in practice without significant changes to driver subsystems:
> 
> The way we describe devices in DT is often very different from what we
> have for the traditional board files, and in some cases we don't even
> support platform data any more, so this would still depend on having
> properties according to the DT bindings, and require a large chunk of
> the same code that is doing DT at the moment.

yes, that's unfortunate.  Perhaps the tinification links are still
helpful to Detlef.

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1289813

From	Josh Triplett <josh@joshtriplett.org>
Date	2015-12-11 19:30 +0100
Message-ID	<qEAC6-862-13@gated-at.bofh.it>
In reply to	#1289571

On Fri, Dec 11, 2015 at 01:36:01PM +0000, Jason Cooper wrote:
> +Josh
> 
> Hey Arnd, Detlef,
> 
> On Fri, Dec 11, 2015 at 12:10:55AM +0100, Arnd Bergmann wrote:
> > On Thursday 10 December 2015 23:00:24 Detlef Vollmann wrote:
> > > On 12/10/15 22:29, Arnd Bergmann wrote:
> > > > On Thursday 10 December 2015 22:14:25 Detlef Vollmann wrote:
> > > >> On 12/10/15 21:59, Arnd Bergmann wrote:
> > > > It may also be worth investigating what has made CONFIG_OF so costly,
> > > Probably because too much is done at runtime and too few things can
> > > be fixed at build time.
> > > 
> > > > maybe we can reduce this a bit again.
> > > Probably not without turning the wheel backward :-(
> > > 
> > > So for the test: yes it works, but I'm unhappy with it.
> > 
> > I'm not too happy about adding 80kb to the uncompressed kernel 
> > image either. I've spent some more time now trying to find where
> > we added the bloat. It's mainly in drivers, not in arch specific
> > code, a kilobyte here and there eventually adds up, but the largest
> > portion with a little over 50% of the total diff is drivers/of.
> 
> Wasn't there an idea kicked around a while ago to create a
> dt2boardfile script/executable*?  Then, during kernel configuration, you
> enable it and select which dts file you want.  It would disable
> CONFIG_OF, multiplatform, etc.  And generate a board_file.c from the dts
> file.
> 
> If anything, it might be worth asking the kernel tinification [1], [2]
> folks if they'd be interested in taking this on...

No objection if you want to add it to the task list on
tiny.wiki.kernel.org (on the more difficult end).

I don't know if you could generate a board file, but I do wonder if you
could effectively compile in a parsed description and ditch the parser.
Bonus if you can make the values parsed out of it into compile-time
constants for constant folding.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1289824

From	Jason Cooper <jason@lakedaemon.net>
Date	2015-12-11 19:50 +0100
Message-ID	<qEAVs-8di-3@gated-at.bofh.it>
In reply to	#1289813

On Fri, Dec 11, 2015 at 10:27:30AM -0800, Josh Triplett wrote:
> On Fri, Dec 11, 2015 at 01:36:01PM +0000, Jason Cooper wrote:
> > +Josh
> > 
> > Hey Arnd, Detlef,
> > 
> > On Fri, Dec 11, 2015 at 12:10:55AM +0100, Arnd Bergmann wrote:
> > > On Thursday 10 December 2015 23:00:24 Detlef Vollmann wrote:
> > > > On 12/10/15 22:29, Arnd Bergmann wrote:
> > > > > On Thursday 10 December 2015 22:14:25 Detlef Vollmann wrote:
> > > > >> On 12/10/15 21:59, Arnd Bergmann wrote:
> > > > > It may also be worth investigating what has made CONFIG_OF so costly,
> > > > Probably because too much is done at runtime and too few things can
> > > > be fixed at build time.
> > > > 
> > > > > maybe we can reduce this a bit again.
> > > > Probably not without turning the wheel backward :-(
> > > > 
> > > > So for the test: yes it works, but I'm unhappy with it.
> > > 
> > > I'm not too happy about adding 80kb to the uncompressed kernel 
> > > image either. I've spent some more time now trying to find where
> > > we added the bloat. It's mainly in drivers, not in arch specific
> > > code, a kilobyte here and there eventually adds up, but the largest
> > > portion with a little over 50% of the total diff is drivers/of.
> > 
> > Wasn't there an idea kicked around a while ago to create a
> > dt2boardfile script/executable*?  Then, during kernel configuration, you
> > enable it and select which dts file you want.  It would disable
> > CONFIG_OF, multiplatform, etc.  And generate a board_file.c from the dts
> > file.
> > 
> > If anything, it might be worth asking the kernel tinification [1], [2]
> > folks if they'd be interested in taking this on...
> 
> No objection if you want to add it to the task list on
> tiny.wiki.kernel.org (on the more difficult end).

Done.

> I don't know if you could generate a board file, but I do wonder if you
> could effectively compile in a parsed description and ditch the parser.
> Bonus if you can make the values parsed out of it into compile-time
> constants for constant folding.

After a bit of discussion with Arnd on irc, I agree.  Going to  a board
file doesn't really work since the logic is now mostly in the drivers
probe functions.

The dts parsing -> compile-time constants is worth looking into.

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1289833

From	Josh Triplett <josh@joshtriplett.org>
Date	2015-12-11 20:10 +0100
Message-ID	<qEBeN-7o-7@gated-at.bofh.it>
In reply to	#1289824

On Fri, Dec 11, 2015 at 06:46:02PM +0000, Jason Cooper wrote:
> On Fri, Dec 11, 2015 at 10:27:30AM -0800, Josh Triplett wrote:
> > On Fri, Dec 11, 2015 at 01:36:01PM +0000, Jason Cooper wrote:
> > > +Josh
> > > 
> > > Hey Arnd, Detlef,
> > > 
> > > On Fri, Dec 11, 2015 at 12:10:55AM +0100, Arnd Bergmann wrote:
> > > > On Thursday 10 December 2015 23:00:24 Detlef Vollmann wrote:
> > > > > On 12/10/15 22:29, Arnd Bergmann wrote:
> > > > > > On Thursday 10 December 2015 22:14:25 Detlef Vollmann wrote:
> > > > > >> On 12/10/15 21:59, Arnd Bergmann wrote:
> > > > > > It may also be worth investigating what has made CONFIG_OF so costly,
> > > > > Probably because too much is done at runtime and too few things can
> > > > > be fixed at build time.
> > > > > 
> > > > > > maybe we can reduce this a bit again.
> > > > > Probably not without turning the wheel backward :-(
> > > > > 
> > > > > So for the test: yes it works, but I'm unhappy with it.
> > > > 
> > > > I'm not too happy about adding 80kb to the uncompressed kernel 
> > > > image either. I've spent some more time now trying to find where
> > > > we added the bloat. It's mainly in drivers, not in arch specific
> > > > code, a kilobyte here and there eventually adds up, but the largest
> > > > portion with a little over 50% of the total diff is drivers/of.
> > > 
> > > Wasn't there an idea kicked around a while ago to create a
> > > dt2boardfile script/executable*?  Then, during kernel configuration, you
> > > enable it and select which dts file you want.  It would disable
> > > CONFIG_OF, multiplatform, etc.  And generate a board_file.c from the dts
> > > file.
> > > 
> > > If anything, it might be worth asking the kernel tinification [1], [2]
> > > folks if they'd be interested in taking this on...
> > 
> > No objection if you want to add it to the task list on
> > tiny.wiki.kernel.org (on the more difficult end).
> 
> Done.

Can you add yourself as a potential contact for that project?

> > I don't know if you could generate a board file, but I do wonder if you
> > could effectively compile in a parsed description and ditch the parser.
> > Bonus if you can make the values parsed out of it into compile-time
> > constants for constant folding.
> 
> After a bit of discussion with Arnd on irc, I agree.  Going to  a board
> file doesn't really work since the logic is now mostly in the drivers
> probe functions.
> 
> The dts parsing -> compile-time constants is worth looking into.
> 
> thx,
> 
> Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1289837

From	Jason Cooper <jason@lakedaemon.net>
Date	2015-12-11 20:20 +0100
Message-ID	<qEBot-aF-1@gated-at.bofh.it>
In reply to	#1289833

Hey Josh,

On Fri, Dec 11, 2015 at 11:08:15AM -0800, Josh Triplett wrote:
> On Fri, Dec 11, 2015 at 06:46:02PM +0000, Jason Cooper wrote:
> > On Fri, Dec 11, 2015 at 10:27:30AM -0800, Josh Triplett wrote:
...
> > > No objection if you want to add it to the task list on
> > > tiny.wiki.kernel.org (on the more difficult end).
> > 
> > Done.
> 
> Can you add yourself as a potential contact for that project?

Updated.

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1289927

From	Arnd Bergmann <arnd@arndb.de>
Date	2015-12-11 22:40 +0100
Message-ID	<qEDzY-1uM-1@gated-at.bofh.it>
In reply to	#1288507

On Thursday 10 December 2015 14:39:27 Detlef Vollmann wrote:
> #
> # Automatically generated file; DO NOT EDIT.
> # Linux/arm 4.4.0-rc3 Kernel Configuration
> #

Just for fun, a few things you can probably disable without
much downsides:

> CONFIG_DEFAULT_HOSTNAME="dns-323"
> CONFIG_SWAP=y
> CONFIG_SYSVIPC=y
> CONFIG_SYSVIPC_SYSCTL=y

SYSVIPC could be disabled in principle for most embedded systems

> CONFIG_SYSFS_DEPRECATED=y
> CONFIG_SYSFS_DEPRECATED_V2=y
> # CONFIG_RELAY is not set
> CONFIG_BLK_DEV_INITRD=y
> CONFIG_INITRAMFS_SOURCE=""

SYSFS_DEPRECATED can probably go, initramfs would be smaller than initrd

> CONFIG_COMPAT_BRK=y
> CONFIG_SLAB=y
> # CONFIG_SLUB is not set
> # CONFIG_SLOB is not set
> # CONFIG_SYSTEM_DATA_VERIFICATION is not set
> # CONFIG_PROFILING is not set
> CONFIG_KEXEC_CORE=y
> CONFIG_HAVE_OPROFILE=y

SLOB would be smaller than SLAB, kexec is often not needed. 

> CONFIG_SWIOTLB=y
> CONFIG_IOMMU_HELPER=y

I have no idea why SWIOTLB is always enabled on ARM, I suspect that's
a bug, and disabling it would save some space (need to change arm/Kconfig)

> #
> # User Modules And Translation Layers
> #
> CONFIG_MTD_BLKDEVS=y
> CONFIG_MTD_BLOCK=y

I suspect you don't use MTD_BLOCK

> CONFIG_BLK_DEV=y
> # CONFIG_BLK_DEV_NULL_BLK is not set
> # CONFIG_BLK_DEV_PCIESSD_MTIP32XX is not set
> # CONFIG_BLK_CPQ_CISS_DA is not set
> # CONFIG_BLK_DEV_DAC960 is not set
> # CONFIG_BLK_DEV_UMEM is not set
> # CONFIG_BLK_DEV_COW_COMMON is not set
> CONFIG_BLK_DEV_LOOP=y
> CONFIG_BLK_DEV_LOOP_MIN_COUNT=4
> # CONFIG_BLK_DEV_CRYPTOLOOP is not set
> # CONFIG_BLK_DEV_DRBD is not set
> # CONFIG_BLK_DEV_NBD is not set
> # CONFIG_BLK_DEV_SX8 is not set
> CONFIG_BLK_DEV_RAM=y

Loop and RAM could be loadable modules, if that saves space in the
end. If modules are actually larger, you can have everything built-in.
> #
> # Serial drivers
> #
> CONFIG_SERIAL_EARLYCON=y
> CONFIG_SERIAL_8250=y
> # CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set
> CONFIG_SERIAL_8250_CONSOLE=y
> CONFIG_SERIAL_8250_DMA=y
> # CONFIG_SERIAL_8250_PCI is not set
> CONFIG_SERIAL_8250_NR_UARTS=2
> CONFIG_SERIAL_8250_RUNTIME_UARTS=2
> # CONFIG_SERIAL_8250_EXTENDED is not set
> CONFIG_SERIAL_8250_FSL=y

No need for 8250_FSL or 8250_DMA on your hardware

> #
> # Memory mapped GPIO drivers
> #
> # CONFIG_GPIO_74XX_MMIO is not set
> # CONFIG_GPIO_ALTERA is not set
> # CONFIG_GPIO_DWAPB is not set
> # CONFIG_GPIO_EM is not set
> # CONFIG_GPIO_GENERIC_PLATFORM is not set
> # CONFIG_GPIO_GRGPIO is not set
> CONFIG_GPIO_MVEBU=y
> # CONFIG_GPIO_VX855 is not set
> # CONFIG_GPIO_XILINX is not set
> # CONFIG_GPIO_ZEVIO is not set
> # CONFIG_GPIO_ZX is not set

It looks like you get two GPIO drivers for the same hardware.
We should probably change this so you only need one of the two.

> #
> # USB Host Controller Drivers
> #
> # CONFIG_USB_C67X00_HCD is not set
> # CONFIG_USB_XHCI_HCD is not set
> CONFIG_USB_EHCI_HCD=y
> CONFIG_USB_EHCI_ROOT_HUB_TT=y
> # CONFIG_USB_EHCI_TT_NEWSCHED is not set
> CONFIG_USB_EHCI_PCI=y
> CONFIG_USB_EHCI_HCD_ORION=y

You probably don't have a PCI EHCI

> CONFIG_USB_STORAGE=y

module

> #
> # PHY Subsystem
> #
> CONFIG_GENERIC_PHY=y

probably not needed since you have no specific driver for it.

> #
> # File systems
> #
> CONFIG_EXT2_FS=y
> CONFIG_EXT2_FS_XATTR=y
> CONFIG_EXT2_FS_POSIX_ACL=y

EXT2 no longer needs to be built when EXT4 is enabled, you can just
use the EXT4 code to mount EXT2 file systems.

> CONFIG_XFS_FS=y
> # CONFIG_XFS_QUOTA is not set

XFS is huge. If you don't need it, that would likely save more than anything
else.

> CONFIG_MINIX_FS=y

minixfs is almost never needed, but small.

> # CONFIG_OMFS_FS is not set
> # CONFIG_HPFS_FS is not set
> # CONFIG_QNX4FS_FS is not set
> # CONFIG_QNX6FS_FS is not set
> # CONFIG_ROMFS_FS is not set
> # CONFIG_PSTORE is not set
> # CONFIG_SYSV_FS is not set
> # CONFIG_UFS_FS is not set
> CONFIG_NETWORK_FILESYSTEMS=y
> CONFIG_NFS_FS=y
> CONFIG_NFS_V2=y
> CONFIG_NFS_V3=y

NFS and NFSD are also pretty big, but I assume you need them.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

csiph-web

Re: [PATCH 0/5] ARM: orion5x/dove/mv78xx0 multiplatform

Contents

#1288507 — Re: [PATCH 0/5] ARM: orion5x/dove/mv78xx0 multiplatform

#1288515

#1288932

#1288944

#1289003

#1289571

#1289641

#1289653

#1289813

#1289824

#1289833

#1289837

#1289927