Hi Wolfgang,

(added Ramon to Cc)

On 18.08.20 12:31, Wolfgang Denk wrote:
In message <20200813054800.469284-2...@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 <tr...@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 <tr...@konsulko.com>

commit 999a772d9f24bf9b8d0726e1359c9d8c3bdad72e
Author: Ramon Fried <ramon.fr...@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.fr...@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.fr...@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.fr...@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

Reply via email to