| Message ID | 27901501.7xKhhTyrKu@wuerfel (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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' Detlef
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
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: >>> 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. So with your patches it's no longer possible to build a small kernel, correct? Detlef
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
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: >>> 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). So the message is that Linux just get's bigger... Fortunately this patch is planned for 4.5, and 4.4 is going to be an LTS kernel. > 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. Detlef
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
+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/
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
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.
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.
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.
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.
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.
On 12/11/15 15:55, Jason Cooper wrote: > On Fri, Dec 11, 2015 at 03:46:53PM +0100, Arnd Bergmann wrote: >> 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. I've heard of the tinyfication project, but not paid too much attentions. I believe it's the wrong side around. For busybox, patches that produce larger binaries without providing new functionality are just rejected. Those that provide new functionality and such create bigger binaries must have a configuration option for still being able to get the old small binary. If you accept patches that make the kernel bigger without a configuration option to avoid this, any tinyfication effort that tries to make the kernel small again afterwards is IMHO a noble but lost cause. Detlef
--- 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