
Hi Wolfgang,
(added Ramon to Cc)
On 18.08.20 12:31, Wolfgang Denk wrote:
In message 20200813054800.469284-2-sr@denx.de you wrote:
Since commit 86cf1c82850f ("configs: Migrate CONFIG_NR_DRAM_BANKS") & commit 999a772d9f24 ("Kconfig: Migrate CONFIG_NR_DRAM_BANKS"), CONFIG_NR_DRAM_BANKS is always defined with a value (4 is default).
Has there been any evaluation about the impact this change had on both text and data sizes of the resulting U-Boot image?
Not sure. Ramon and / or Tom might comment on this. Even though the git history shows that these Kconfig migration patches have been committed ~2 years ago, so their memory might be foggy ;)
commit 86cf1c82850f7c226f23684e19616e526ffaf10f Author: Tom Rini trini@konsulko.com Date: Thu Aug 16 08:16:24 2018 -0400
configs: Migrate CONFIG_NR_DRAM_BANKS
We have the following cases: - CONFIG_NR_DRAM_BANKS was defined, migrate normally - CONFIG_NR_DRAM_BANKS_MAX was defined and then used for CONFIG_NR_DRAM_BANKS after a check, just migrate it over now. - CONFIG_NR_DRAM_BANKS was very oddly defined on p2771-0000-* (to 1024 + 2), set this to 8.
Signed-off-by: Tom Rini trini@konsulko.com
commit 999a772d9f24bf9b8d0726e1359c9d8c3bdad72e Author: Ramon Fried ramon.fried@gmail.com Date: Tue Aug 14 01:00:04 2018 +0300
Kconfig: Migrate CONFIG_NR_DRAM_BANKS
Move CONFIG_NR_DRAM_BANKS from headers to Kconfig.
Signed-off-by: Ramon Fried ramon.fried@gmail.com
Especially the default value of 4 makes no sense to me - whiy is this not 1?
I can't really tell. I can only assume, that it originates from this patch:
commit 6b6f216f9234c33881af05116057c902cb411a62 Author: Ramon Fried ramon.fried@gmail.com Date: Tue Aug 14 00:35:42 2018 +0300
fdt_support: Use CONFIG_NR_DRAM_BANKS if necessary
If CONFIG_NR_DRAM_BANKS is bigger than the default value (4) define MEMORY_BANKS_MAX as CONFIG_NR_DRAM_BANKS.
Fixes: 2a1f4f1758b5 ("Revert "fdt_support: Use CONFIG_NR_DRAM_BANKS if defined"") Signed-off-by: Ramon Fried ramon.fried@gmail.com
It makes no sense to still carry code that is guarded with "#ifndef CONFIG_NR_DRAM_BANKS" (and similar). This patch removes all these unreferenced code paths.
...thus futher hiding where we just lost another lof of memory, for no advantage.
Sic...
I'm not sure, what you mean with "lost lot of memory"? We carried referenced code for ~2 years, which this patch series now tries to solve.
Thanks, Stefan