[U-Boot] Making U-Boot smaller
Hi,
(moved from thread "U-Boot PXA support")
We have of-platdata, which produces C data from the DT, for linking into U-Boot. It saves libfdt and DT space. But we still have the DM overhead.
We have binman which can insert values into the binary after link-time. This is barely used at present, only for accessing the location of things in flash.
Another thing is that every little tweak and feature adds a few bytes and there are dozens of them in each release. It would be interesting to build a board from 10 years ago (like PXA) and see where the growth is. My bet is that we could add Kconfig options to disable extra features (and enhancements of features) and make quite a difference.
For DM, I think it would be interesting to revisit and compare against the initial release, and see if some features could be made optional in SPL.
Finally I feel we could implement a single-device API for where CONFIG_SPL_DM is not set. We could use the debug UART for serial, a single instance of tiny MMC for MMC, etc.
Regards, Simon
On Tue, May 21, 2019 at 10:14 PM Simon Glass sjg@chromium.org wrote:
Hi,
(moved from thread "U-Boot PXA support")
We have of-platdata, which produces C data from the DT, for linking into U-Boot. It saves libfdt and DT space. But we still have the DM overhead.
We have binman which can insert values into the binary after link-time. This is barely used at present, only for accessing the location of things in flash.
Another thing is that every little tweak and feature adds a few bytes and there are dozens of them in each release. It would be interesting to build a board from 10 years ago (like PXA) and see where the growth is. My bet is that we could add Kconfig options to disable extra features (and enhancements of features) and make quite a difference.
For DM, I think it would be interesting to revisit and compare against the initial release, and see if some features could be made optional in SPL.
Finally I feel we could implement a single-device API for where CONFIG_SPL_DM is not set. We could use the debug UART for serial, a single instance of tiny MMC for MMC, etc.
This is what I'm looking for quite sometime, a tiny MMC which would bypass the mmc stack and do the possible stuff in SPL, since we don't have any option to use full DM in SPL (specifically for Allwinner 64 SoC's). API that would atleast compatible with DM with small foot-print would help.
On 5/21/19 6:56 PM, Jagan Teki wrote:
On Tue, May 21, 2019 at 10:14 PM Simon Glass sjg@chromium.org wrote:
Hi,
(moved from thread "U-Boot PXA support")
We have of-platdata, which produces C data from the DT, for linking into U-Boot. It saves libfdt and DT space. But we still have the DM overhead.
We have binman which can insert values into the binary after link-time. This is barely used at present, only for accessing the location of things in flash.
Another thing is that every little tweak and feature adds a few bytes and there are dozens of them in each release. It would be interesting to build a board from 10 years ago (like PXA) and see where the growth is. My bet is that we could add Kconfig options to disable extra features (and enhancements of features) and make quite a difference.
For DM, I think it would be interesting to revisit and compare against the initial release, and see if some features could be made optional in SPL.
Finally I feel we could implement a single-device API for where CONFIG_SPL_DM is not set. We could use the debug UART for serial, a single instance of tiny MMC for MMC, etc.
This is what I'm looking for quite sometime, a tiny MMC which would bypass the mmc stack and do the possible stuff in SPL, since we don't have any option to use full DM in SPL (specifically for Allwinner 64 SoC's). API that would atleast compatible with DM with small foot-print would help.
It's been in mainline for a long time, MMC_TINY. Creator CI20 uses it.
On Tue, May 21, 2019 at 09:32:29PM +0200, Marek Vasut wrote:
On 5/21/19 6:56 PM, Jagan Teki wrote:
On Tue, May 21, 2019 at 10:14 PM Simon Glass sjg@chromium.org wrote:
Hi,
(moved from thread "U-Boot PXA support")
We have of-platdata, which produces C data from the DT, for linking into U-Boot. It saves libfdt and DT space. But we still have the DM overhead.
We have binman which can insert values into the binary after link-time. This is barely used at present, only for accessing the location of things in flash.
Another thing is that every little tweak and feature adds a few bytes and there are dozens of them in each release. It would be interesting to build a board from 10 years ago (like PXA) and see where the growth is. My bet is that we could add Kconfig options to disable extra features (and enhancements of features) and make quite a difference.
For DM, I think it would be interesting to revisit and compare against the initial release, and see if some features could be made optional in SPL.
Finally I feel we could implement a single-device API for where CONFIG_SPL_DM is not set. We could use the debug UART for serial, a single instance of tiny MMC for MMC, etc.
This is what I'm looking for quite sometime, a tiny MMC which would bypass the mmc stack and do the possible stuff in SPL, since we don't have any option to use full DM in SPL (specifically for Allwinner 64 SoC's). API that would atleast compatible with DM with small foot-print would help.
It's been in mainline for a long time, MMC_TINY. Creator CI20 uses it.
I want to start by saying I'm not criticizing MMC_TINY. But I think this highlights part of the problem of "lets do something that's not the normal framework". Developers come up with a one-off, do their best to make others know about it, and then a year later when someone else has a similar problem, they may or may not stumble into the alternate path fix.
So, getting back to specifics, what would it take to do both: - Make MMC_TINY abstract enough sunxi or TI or ... could plug-in and use this for the "we just need MMC read, ROM probably already did enough init for us for this" - NOT blow up CI20 which I know is super tight on space.
On 5/21/19 9:53 PM, Tom Rini wrote:
On Tue, May 21, 2019 at 09:32:29PM +0200, Marek Vasut wrote:
On 5/21/19 6:56 PM, Jagan Teki wrote:
On Tue, May 21, 2019 at 10:14 PM Simon Glass sjg@chromium.org wrote:
Hi,
(moved from thread "U-Boot PXA support")
We have of-platdata, which produces C data from the DT, for linking into U-Boot. It saves libfdt and DT space. But we still have the DM overhead.
We have binman which can insert values into the binary after link-time. This is barely used at present, only for accessing the location of things in flash.
Another thing is that every little tweak and feature adds a few bytes and there are dozens of them in each release. It would be interesting to build a board from 10 years ago (like PXA) and see where the growth is. My bet is that we could add Kconfig options to disable extra features (and enhancements of features) and make quite a difference.
For DM, I think it would be interesting to revisit and compare against the initial release, and see if some features could be made optional in SPL.
Finally I feel we could implement a single-device API for where CONFIG_SPL_DM is not set. We could use the debug UART for serial, a single instance of tiny MMC for MMC, etc.
This is what I'm looking for quite sometime, a tiny MMC which would bypass the mmc stack and do the possible stuff in SPL, since we don't have any option to use full DM in SPL (specifically for Allwinner 64 SoC's). API that would atleast compatible with DM with small foot-print would help.
It's been in mainline for a long time, MMC_TINY. Creator CI20 uses it.
I want to start by saying I'm not criticizing MMC_TINY. But I think this highlights part of the problem of "lets do something that's not the normal framework". Developers come up with a one-off, do their best to make others know about it, and then a year later when someone else has a similar problem, they may or may not stumble into the alternate path fix.
So, getting back to specifics, what would it take to do both:
- Make MMC_TINY abstract enough sunxi or TI or ... could plug-in and use this for the "we just need MMC read, ROM probably already did enough init for us for this"
- NOT blow up CI20 which I know is super tight on space.
You can already do just that.
Isn't the current problem a good/searchable documentation then ? Like the readthedocs stuff ?
On Tue, May 21, 2019 at 09:54:33PM +0200, Marek Vasut wrote:
On 5/21/19 9:53 PM, Tom Rini wrote:
On Tue, May 21, 2019 at 09:32:29PM +0200, Marek Vasut wrote:
On 5/21/19 6:56 PM, Jagan Teki wrote:
On Tue, May 21, 2019 at 10:14 PM Simon Glass sjg@chromium.org wrote:
Hi,
(moved from thread "U-Boot PXA support")
We have of-platdata, which produces C data from the DT, for linking into U-Boot. It saves libfdt and DT space. But we still have the DM overhead.
We have binman which can insert values into the binary after link-time. This is barely used at present, only for accessing the location of things in flash.
Another thing is that every little tweak and feature adds a few bytes and there are dozens of them in each release. It would be interesting to build a board from 10 years ago (like PXA) and see where the growth is. My bet is that we could add Kconfig options to disable extra features (and enhancements of features) and make quite a difference.
For DM, I think it would be interesting to revisit and compare against the initial release, and see if some features could be made optional in SPL.
Finally I feel we could implement a single-device API for where CONFIG_SPL_DM is not set. We could use the debug UART for serial, a single instance of tiny MMC for MMC, etc.
This is what I'm looking for quite sometime, a tiny MMC which would bypass the mmc stack and do the possible stuff in SPL, since we don't have any option to use full DM in SPL (specifically for Allwinner 64 SoC's). API that would atleast compatible with DM with small foot-print would help.
It's been in mainline for a long time, MMC_TINY. Creator CI20 uses it.
I want to start by saying I'm not criticizing MMC_TINY. But I think this highlights part of the problem of "lets do something that's not the normal framework". Developers come up with a one-off, do their best to make others know about it, and then a year later when someone else has a similar problem, they may or may not stumble into the alternate path fix.
So, getting back to specifics, what would it take to do both:
- Make MMC_TINY abstract enough sunxi or TI or ... could plug-in and use this for the "we just need MMC read, ROM probably already did enough init for us for this"
- NOT blow up CI20 which I know is super tight on space.
You can already do just that.
Isn't the current problem a good/searchable documentation then ? Like the readthedocs stuff ?
Oh? Good! So, yes, it's documented as: Enable MMC framework tinification support. This option is useful if if your SPL is extremely size constrained. Heed the warning, enable this option if and only if you know exactly what you are doing, if you are reading this help text, you most likely have no idea :-)
The MMC framework is reduced to bare minimum to be useful. No malloc support is needed for the MMC framework operation with this option enabled. The framework supports exactly one MMC device and exactly one MMC driver. The MMC driver can be adjusted to avoid any malloc operations too, which can remove the need for malloc support in SPL and thus further reduce footprint.
So, is write supported? When you say "one MMC device", is that static at run-time or you can run-time init and use only one? What would a patch look like that enabled this on SoCFPGA? Thanks!
On 5/21/19 9:59 PM, Tom Rini wrote:
On Tue, May 21, 2019 at 09:54:33PM +0200, Marek Vasut wrote:
On 5/21/19 9:53 PM, Tom Rini wrote:
On Tue, May 21, 2019 at 09:32:29PM +0200, Marek Vasut wrote:
On 5/21/19 6:56 PM, Jagan Teki wrote:
On Tue, May 21, 2019 at 10:14 PM Simon Glass sjg@chromium.org wrote:
Hi,
(moved from thread "U-Boot PXA support")
We have of-platdata, which produces C data from the DT, for linking into U-Boot. It saves libfdt and DT space. But we still have the DM overhead.
We have binman which can insert values into the binary after link-time. This is barely used at present, only for accessing the location of things in flash.
Another thing is that every little tweak and feature adds a few bytes and there are dozens of them in each release. It would be interesting to build a board from 10 years ago (like PXA) and see where the growth is. My bet is that we could add Kconfig options to disable extra features (and enhancements of features) and make quite a difference.
For DM, I think it would be interesting to revisit and compare against the initial release, and see if some features could be made optional in SPL.
Finally I feel we could implement a single-device API for where CONFIG_SPL_DM is not set. We could use the debug UART for serial, a single instance of tiny MMC for MMC, etc.
This is what I'm looking for quite sometime, a tiny MMC which would bypass the mmc stack and do the possible stuff in SPL, since we don't have any option to use full DM in SPL (specifically for Allwinner 64 SoC's). API that would atleast compatible with DM with small foot-print would help.
It's been in mainline for a long time, MMC_TINY. Creator CI20 uses it.
I want to start by saying I'm not criticizing MMC_TINY. But I think this highlights part of the problem of "lets do something that's not the normal framework". Developers come up with a one-off, do their best to make others know about it, and then a year later when someone else has a similar problem, they may or may not stumble into the alternate path fix.
So, getting back to specifics, what would it take to do both:
- Make MMC_TINY abstract enough sunxi or TI or ... could plug-in and use this for the "we just need MMC read, ROM probably already did enough init for us for this"
- NOT blow up CI20 which I know is super tight on space.
You can already do just that.
Isn't the current problem a good/searchable documentation then ? Like the readthedocs stuff ?
Oh? Good! So, yes, it's documented as: Enable MMC framework tinification support. This option is useful if if your SPL is extremely size constrained. Heed the warning, enable this option if and only if you know exactly what you are doing, if you are reading this help text, you most likely have no idea :-)
The MMC framework is reduced to bare minimum to be useful. No malloc support is needed for the MMC framework operation with this option enabled. The framework supports exactly one MMC device and exactly one MMC driver. The MMC driver can be adjusted to avoid any malloc operations too, which can remove the need for malloc support in SPL and thus further reduce footprint.So, is write supported?
No, what for ?
When you say "one MMC device", is that static at run-time or you can run-time init and use only one?
IIRC it's compile time.
What would a patch look like that enabled this on SoCFPGA? Thanks!
Like nothing , since SoCFPGA probes itself from DT in SPL and there's enough space for that. However, if you want an example, CI20 is one.
On Tue, May 21, 2019 at 10:01:42PM +0200, Marek Vasut wrote:
On 5/21/19 9:59 PM, Tom Rini wrote:
On Tue, May 21, 2019 at 09:54:33PM +0200, Marek Vasut wrote:
On 5/21/19 9:53 PM, Tom Rini wrote:
On Tue, May 21, 2019 at 09:32:29PM +0200, Marek Vasut wrote:
On 5/21/19 6:56 PM, Jagan Teki wrote:
On Tue, May 21, 2019 at 10:14 PM Simon Glass sjg@chromium.org wrote: > > Hi, > > (moved from thread "U-Boot PXA support") > > We have of-platdata, which produces C data from the DT, for linking > into U-Boot. It saves libfdt and DT space. But we still have the DM > overhead. > > We have binman which can insert values into the binary after > link-time. This is barely used at present, only for accessing the > location of things in flash. > > Another thing is that every little tweak and feature adds a few bytes > and there are dozens of them in each release. It would be interesting > to build a board from 10 years ago (like PXA) and see where the growth > is. My bet is that we could add Kconfig options to disable extra > features (and enhancements of features) and make quite a difference. > > For DM, I think it would be interesting to revisit and compare against > the initial release, and see if some features could be made optional > in SPL. > > Finally I feel we could implement a single-device API for where > CONFIG_SPL_DM is not set. We could use the debug UART for serial, a > single instance of tiny MMC for MMC, etc.
This is what I'm looking for quite sometime, a tiny MMC which would bypass the mmc stack and do the possible stuff in SPL, since we don't have any option to use full DM in SPL (specifically for Allwinner 64 SoC's). API that would atleast compatible with DM with small foot-print would help.
It's been in mainline for a long time, MMC_TINY. Creator CI20 uses it.
I want to start by saying I'm not criticizing MMC_TINY. But I think this highlights part of the problem of "lets do something that's not the normal framework". Developers come up with a one-off, do their best to make others know about it, and then a year later when someone else has a similar problem, they may or may not stumble into the alternate path fix.
So, getting back to specifics, what would it take to do both:
- Make MMC_TINY abstract enough sunxi or TI or ... could plug-in and use this for the "we just need MMC read, ROM probably already did enough init for us for this"
- NOT blow up CI20 which I know is super tight on space.
You can already do just that.
Isn't the current problem a good/searchable documentation then ? Like the readthedocs stuff ?
Oh? Good! So, yes, it's documented as: Enable MMC framework tinification support. This option is useful if if your SPL is extremely size constrained. Heed the warning, enable this option if and only if you know exactly what you are doing, if you are reading this help text, you most likely have no idea :-)
The MMC framework is reduced to bare minimum to be useful. No malloc support is needed for the MMC framework operation with this option enabled. The framework supports exactly one MMC device and exactly one MMC driver. The MMC driver can be adjusted to avoid any malloc operations too, which can remove the need for malloc support in SPL and thus further reduce footprint.So, is write supported?
No, what for ?
For the cases where writing is required, OK, so not possible here, that's a fine trade-off.
When you say "one MMC device", is that static at run-time or you can run-time init and use only one?
IIRC it's compile time.
Where/how? I don't see it from the code right away..
What would a patch look like that enabled this on SoCFPGA? Thanks!
Like nothing , since SoCFPGA probes itself from DT in SPL and there's enough space for that. However, if you want an example, CI20 is one.
Yes, and now I'm trying to get it understood, so we can update the Kconfig help if nothing else, how limited the driver is and how to switch to it. So what would it look like to use this on SoCFPA, or some other platform you're familiar with and that uses SPL? iMX6 is another "we have no SPL space!" platform that isn't using MMC_TINY, for example.
On 5/21/19 10:10 PM, Tom Rini wrote:
On Tue, May 21, 2019 at 10:01:42PM +0200, Marek Vasut wrote:
On 5/21/19 9:59 PM, Tom Rini wrote:
On Tue, May 21, 2019 at 09:54:33PM +0200, Marek Vasut wrote:
On 5/21/19 9:53 PM, Tom Rini wrote:
On Tue, May 21, 2019 at 09:32:29PM +0200, Marek Vasut wrote:
On 5/21/19 6:56 PM, Jagan Teki wrote: > On Tue, May 21, 2019 at 10:14 PM Simon Glass sjg@chromium.org wrote: >> >> Hi, >> >> (moved from thread "U-Boot PXA support") >> >> We have of-platdata, which produces C data from the DT, for linking >> into U-Boot. It saves libfdt and DT space. But we still have the DM >> overhead. >> >> We have binman which can insert values into the binary after >> link-time. This is barely used at present, only for accessing the >> location of things in flash. >> >> Another thing is that every little tweak and feature adds a few bytes >> and there are dozens of them in each release. It would be interesting >> to build a board from 10 years ago (like PXA) and see where the growth >> is. My bet is that we could add Kconfig options to disable extra >> features (and enhancements of features) and make quite a difference. >> >> For DM, I think it would be interesting to revisit and compare against >> the initial release, and see if some features could be made optional >> in SPL. >> >> Finally I feel we could implement a single-device API for where >> CONFIG_SPL_DM is not set. We could use the debug UART for serial, a >> single instance of tiny MMC for MMC, etc. > > This is what I'm looking for quite sometime, a tiny MMC which would > bypass the mmc stack and do the possible stuff in SPL, since we don't > have any option to use full DM in SPL (specifically for Allwinner 64 > SoC's). API that would atleast compatible with DM with small > foot-print would help.
It's been in mainline for a long time, MMC_TINY. Creator CI20 uses it.
I want to start by saying I'm not criticizing MMC_TINY. But I think this highlights part of the problem of "lets do something that's not the normal framework". Developers come up with a one-off, do their best to make others know about it, and then a year later when someone else has a similar problem, they may or may not stumble into the alternate path fix.
So, getting back to specifics, what would it take to do both:
- Make MMC_TINY abstract enough sunxi or TI or ... could plug-in and use this for the "we just need MMC read, ROM probably already did enough init for us for this"
- NOT blow up CI20 which I know is super tight on space.
You can already do just that.
Isn't the current problem a good/searchable documentation then ? Like the readthedocs stuff ?
Oh? Good! So, yes, it's documented as: Enable MMC framework tinification support. This option is useful if if your SPL is extremely size constrained. Heed the warning, enable this option if and only if you know exactly what you are doing, if you are reading this help text, you most likely have no idea :-)
The MMC framework is reduced to bare minimum to be useful. No malloc support is needed for the MMC framework operation with this option enabled. The framework supports exactly one MMC device and exactly one MMC driver. The MMC driver can be adjusted to avoid any malloc operations too, which can remove the need for malloc support in SPL and thus further reduce footprint.So, is write supported?
No, what for ?
For the cases where writing is required, OK, so not possible here, that's a fine trade-off.
Isn't there CONFIG_MMC_WRITE for that ?
When you say "one MMC device", is that static at run-time or you can run-time init and use only one?
IIRC it's compile time.
Where/how? I don't see it from the code right away..
CCing Ezequiel, he was digging in that recently and he likes CI20 .
What would a patch look like that enabled this on SoCFPGA? Thanks!
Like nothing , since SoCFPGA probes itself from DT in SPL and there's enough space for that. However, if you want an example, CI20 is one.
Yes, and now I'm trying to get it understood, so we can update the Kconfig help if nothing else, how limited the driver is and how to switch to it. So what would it look like to use this on SoCFPA, or some other platform you're familiar with and that uses SPL? iMX6 is another "we have no SPL space!" platform that isn't using MMC_TINY, for example.
See above, I'll deflect this question to the expert(s).
cc: Yamada-san
I dream of a (Kconfig/Kbuild-assisted) bloaty-like output [1] which would point out the culprit configs. This is hardly achievable, but looks good on the paper!
CONFIG FILE SIZE ------------ -------------- CONFIG_FEATURE_A 10.7Mi 37.1% CONFIG_FEATURE_B 5.39Mi 18.6% CONFIG_FEATURE_C 4.48Mi 15.5% CONFIG_FEATURE_D 1.86Mi 6.4% CONFIG_FEATURE_E 1.67Mi 5.8% CONFIG_FEATURE_F 1.61Mi 5.6% CONFIG_FEATURE_G 856Ki 2.9% CONFIG_FEATURE_H 470Ki 1.6% .... TOTAL 28.9Mi 100.0%
[1] https://github.com/google/bloaty
On Wed, May 22, 2019 at 04:15:47PM +0200, Eugeniu Rosca wrote:
cc: Yamada-san
I dream of a (Kconfig/Kbuild-assisted) bloaty-like output [1] which would point out the culprit configs. This is hardly achievable, but looks good on the paper!
CONFIG FILE SIZE
CONFIG_FEATURE_A 10.7Mi 37.1% CONFIG_FEATURE_B 5.39Mi 18.6% CONFIG_FEATURE_C 4.48Mi 15.5% CONFIG_FEATURE_D 1.86Mi 6.4% CONFIG_FEATURE_E 1.67Mi 5.8% CONFIG_FEATURE_F 1.61Mi 5.6% CONFIG_FEATURE_G 856Ki 2.9% CONFIG_FEATURE_H 470Ki 1.6% .... TOTAL 28.9Mi 100.0%
This is relatively easy to do today, with buildman and a local commit to enable/disable CONFIG_FEATURE_A.
Hi Tom,
On Wed, May 22, 2019 at 11:09:54AM -0400, Tom Rini wrote:
On Wed, May 22, 2019 at 04:15:47PM +0200, Eugeniu Rosca wrote:
cc: Yamada-san
I dream of a (Kconfig/Kbuild-assisted) bloaty-like output [1] which would point out the culprit configs. This is hardly achievable, but looks good on the paper!
CONFIG FILE SIZE
CONFIG_FEATURE_A 10.7Mi 37.1% CONFIG_FEATURE_B 5.39Mi 18.6% CONFIG_FEATURE_C 4.48Mi 15.5% CONFIG_FEATURE_D 1.86Mi 6.4% CONFIG_FEATURE_E 1.67Mi 5.8% CONFIG_FEATURE_F 1.61Mi 5.6% CONFIG_FEATURE_G 856Ki 2.9% CONFIG_FEATURE_H 470Ki 1.6% .... TOTAL 28.9Mi 100.0%
This is relatively easy to do today, with buildman and a local commit to enable/disable CONFIG_FEATURE_A.
Being a valid choice doesn't make it necessarily appealing, especially with 512 [1] configurations enabled in sandbox and knowing that U-Boot is not really randconfig-grade [2] (the latter is being improved).
What I was alluding to is embedding the Kconfig symbol names into the ELF objects, such that utilities like 'nm' (currently producing a nice output of symbol sizes [3]) can also be made capable to report the exact Kconfig symbols contributing to the size of the objects passed as input. That would be, in my opinion, mind-blowingly useful.
[1] grep "CONFIG.*=" .config | wc -l 512
[2] https://patchwork.ozlabs.org/patch/1074420/
[3] nm --print-size --size-sort --radix=d ./drivers/clk/clk-uclass.o 0000000000000421 0000000000000024 T clk_free 0000000000000961 0000000000000027 T clk_disable 0000000000000888 0000000000000027 T clk_enable 0000000000000000 0000000000000027 T clk_request 0000000000000503 0000000000000027 T clk_set_parent 0000000000000445 0000000000000029 T clk_get_rate 0000000000000474 0000000000000029 T clk_set_rate ...
On Wed, May 22, 2019 at 06:50:36PM +0200, Eugeniu Rosca wrote:
Hi Tom,
On Wed, May 22, 2019 at 11:09:54AM -0400, Tom Rini wrote:
On Wed, May 22, 2019 at 04:15:47PM +0200, Eugeniu Rosca wrote:
cc: Yamada-san
I dream of a (Kconfig/Kbuild-assisted) bloaty-like output [1] which would point out the culprit configs. This is hardly achievable, but looks good on the paper!
CONFIG FILE SIZE
CONFIG_FEATURE_A 10.7Mi 37.1% CONFIG_FEATURE_B 5.39Mi 18.6% CONFIG_FEATURE_C 4.48Mi 15.5% CONFIG_FEATURE_D 1.86Mi 6.4% CONFIG_FEATURE_E 1.67Mi 5.8% CONFIG_FEATURE_F 1.61Mi 5.6% CONFIG_FEATURE_G 856Ki 2.9% CONFIG_FEATURE_H 470Ki 1.6% .... TOTAL 28.9Mi 100.0%
This is relatively easy to do today, with buildman and a local commit to enable/disable CONFIG_FEATURE_A.
Being a valid choice doesn't make it necessarily appealing, especially with 512 [1] configurations enabled in sandbox and knowing that U-Boot is not really randconfig-grade [2] (the latter is being improved).
What I was alluding to is embedding the Kconfig symbol names into the ELF objects, such that utilities like 'nm' (currently producing a nice output of symbol sizes [3]) can also be made capable to report the exact Kconfig symbols contributing to the size of the objects passed as input. That would be, in my opinion, mind-blowingly useful.
[1] grep "CONFIG.*=" .config | wc -l 512
[2] https://patchwork.ozlabs.org/patch/1074420/
[3] nm --print-size --size-sort --radix=d ./drivers/clk/clk-uclass.o 0000000000000421 0000000000000024 T clk_free 0000000000000961 0000000000000027 T clk_disable 0000000000000888 0000000000000027 T clk_enable 0000000000000000 0000000000000027 T clk_request 0000000000000503 0000000000000027 T clk_set_parent 0000000000000445 0000000000000029 T clk_get_rate 0000000000000474 0000000000000029 T clk_set_rate
Right. More numbers, and more easily readable is good. But to be clear, since we use -ffunction-sections / -fdata-sections (and the kernel doesn't normally), we get can get a lot more detail than I might have implied. It's not just that you'll see that U-Boot shrank X bytes with CONFIG_FEATURE_A disabled, it's that you'll see which functions shrank by how much. What we don't have is the link between "CONFIG_OPTION_X" and "is part of functions A/B/C". But we have a lot of information like you would get out of nm already in u-boot*.map which also includes "and we discarded these functions".
On Wed, May 22, 2019 at 02:50:58PM -0400, Tom Rini wrote:
On Wed, May 22, 2019 at 06:50:36PM +0200, Eugeniu Rosca wrote:
[..]
0000000000000421 0000000000000024 T clk_free 0000000000000961 0000000000000027 T clk_disable 0000000000000888 0000000000000027 T clk_enable 0000000000000000 0000000000000027 T clk_request 0000000000000503 0000000000000027 T clk_set_parent 0000000000000445 0000000000000029 T clk_get_rate 0000000000000474 0000000000000029 T clk_set_rate
Right. More numbers, and more easily readable is good. But to be clear, since we use -ffunction-sections / -fdata-sections (and the kernel doesn't normally), we get can get a lot more detail than I might have implied. It's not just that you'll see that U-Boot shrank X bytes with CONFIG_FEATURE_A disabled, it's that you'll see which functions shrank by how much.
Thanks for the useful highlights.
What we don't have is the link between "CONFIG_OPTION_X" and "is part of functions A/B/C".
Yes, that's the key part. I think the magnitude to have such a feature is reflected by the number of touched components: - Kconfig/Kbuild, and possibly additional components on top of these, to decide which line in the C file is guarded by which configuration - Compiler/linker to inject that information into the ELF files - readelf/nm, to avoid manual parsing of U-Boot map files
A superhero or a motivated small team can possibly do it one day :-)
But we have a lot of information like you would get out of nm already in u-boot*.map which also includes "and we discarded these functions".
On 5/21/19 6:43 PM, Simon Glass wrote:
Hi,
(moved from thread "U-Boot PXA support")
We have of-platdata, which produces C data from the DT, for linking into U-Boot. It saves libfdt and DT space. But we still have the DM overhead.
We have binman which can insert values into the binary after link-time. This is barely used at present, only for accessing the location of things in flash.
Another thing is that every little tweak and feature adds a few bytes and there are dozens of them in each release. It would be interesting to build a board from 10 years ago (like PXA) and see where the growth is. My bet is that we could add Kconfig options to disable extra features (and enhancements of features) and make quite a difference.
For DM, I think it would be interesting to revisit and compare against the initial release, and see if some features could be made optional in SPL.
Finally I feel we could implement a single-device API for where CONFIG_SPL_DM is not set. We could use the debug UART for serial, a single instance of tiny MMC for MMC, etc.
If it's a single-instance, then maybe we can somehow compile-out or short-circuit the DM altogether ?
participants (6)
-
Eugeniu Rosca -
Eugeniu Rosca -
Jagan Teki -
Marek Vasut -
Simon Glass -
Tom Rini