From: Wadim Egorov <w.egorov@phytec.de>
To: Bryan Brattlof <bb@ti.com>, Neha Malcom Francis <n-francis@ti.com>
Cc: Santhosh Kumar K <s-k6@ti.com>,
trini@konsulko.com, m-chawdhry@ti.com, nm@ti.com,
u-kumar1@ti.com, vigneshr@ti.com, u-boot@lists.denx.de
Subject: Re: [PATCH v4 2/8] ram: k3-ddrss: Add k3_ddrss_ddr_bank_base_size_calc() to solve 'calculations restricted to 32 bits' issue
Date: Fri, 6 Dec 2024 13:53:32 +0100 [thread overview]
Message-ID: <b7dc8b69-cb3d-433a-adef-56e54e8db275@phytec.de> (raw)
In-Reply-To: <20241024161958.hxbtvbeaf52zsblc@bryanbrattlof.com>
Am 24.10.24 um 18:19 schrieb Bryan Brattlof:
> On October 24, 2024 thus sayeth Neha Malcom Francis:
>> Hi Bryan
>>
>> On 23/10/24 20:09, Bryan Brattlof wrote:
>>> On October 21, 2024 thus sayeth Santhosh Kumar K:
>>>> As R5 is a 32 bit processor, the RAM banks' base and size calculation
>>>> is restricted to 32 bits, which results in wrong values if bank's base
>>>> is greater than 32 bits or bank's size is greater than or equal to 4GB.
>>>>
>>>> So, add k3_ddrss_ddr_bank_base_size_calc() to get the base address and
>>>> size of RAM's banks from the device tree memory node, and store in a
>>>> 64 bit device private data which can be used for ECC reserved memory
>>>> calculation, Setting ECC range and Fixing up bank size in device tree
>>>> when ECC is enabled.
>>>>
>>>> Signed-off-by: Santhosh Kumar K <s-k6@ti.com>
>>>> ---
>>>> drivers/ram/k3-ddrss/k3-ddrss.c | 72 ++++++++++++++++++++++++++-------
>>>> 1 file changed, 57 insertions(+), 15 deletions(-)
>>>>
>>>> diff --git a/drivers/ram/k3-ddrss/k3-ddrss.c b/drivers/ram/k3-ddrss/k3-ddrss.c
>>>> index f2ab8cf2b49b..bd6783ebc2cd 100644
>>>> --- a/drivers/ram/k3-ddrss/k3-ddrss.c
>>>> +++ b/drivers/ram/k3-ddrss/k3-ddrss.c
>>>> @@ -147,6 +147,9 @@ struct k3_ddrss_desc {
>>>> struct k3_ddrss_ecc_region ecc_regions[K3_DDRSS_MAX_ECC_REGIONS];
>>>> u64 ecc_reserved_space;
>>>> bool ti_ecc_enabled;
>>>> + unsigned long long ddr_bank_base[CONFIG_NR_DRAM_BANKS];
>>>> + unsigned long long ddr_bank_size[CONFIG_NR_DRAM_BANKS];
>>>> + unsigned long long ddr_ram_size;
>>>
>>> Should we use the u64 typedef here?
>>>
>>>> };
>>>> struct reginitdata {
>>>> @@ -668,11 +671,54 @@ static void k3_ddrss_lpddr4_preload_full_mem(struct k3_ddrss_desc *ddrss,
>>>> printf("ECC: priming DDR completed in %lu msec\n", get_timer(done));
>>>> }
>>>> +static void k3_ddrss_ddr_bank_base_size_calc(struct k3_ddrss_desc *ddrss)
>>>> +{
>>>> + int bank, na, ns, len, parent;
>>>> + const fdt32_t *ptr, *end;
>>>> +
>>>> + for (bank = 0; bank < CONFIG_NR_DRAM_BANKS; bank++) {
>>>> + ddrss->ddr_bank_base[bank] = 0;
>>>> + ddrss->ddr_bank_size[bank] = 0;
>>>> + }
>>>> +
>>>> + ofnode mem = ofnode_null();
>>>> +
>>>> + do {
>>>> + mem = ofnode_by_prop_value(mem, "device_type", "memory", 7);
>>>> + } while (!ofnode_is_enabled(mem));
>>>> +
>>>> + const void *fdt = ofnode_to_fdt(mem);
>>>> + int node = ofnode_to_offset(mem);
>>>> + const char *property = "reg";
>>>> +
>>>> + parent = fdt_parent_offset(fdt, node);
>>>> + na = fdt_address_cells(fdt, parent);
>>>> + ns = fdt_size_cells(fdt, parent);
>>>> + ptr = fdt_getprop(fdt, node, property, &len);
>>>> + end = ptr + len / sizeof(*ptr);
>>>> +
>>>> + for (bank = 0; bank < CONFIG_NR_DRAM_BANKS; bank++) {
>>>> + if (ptr + na + ns <= end) {
>>>> + if (CONFIG_IS_ENABLED(OF_TRANSLATE))
>>>> + ddrss->ddr_bank_base[bank] = fdt_translate_address(fdt, node, ptr);
>>>> + else
>>>> + ddrss->ddr_bank_base[bank] = fdtdec_get_number(ptr, na);
>>>> +
>>>> + ddrss->ddr_bank_size[bank] = fdtdec_get_number(&ptr[na], ns);
>>>> + }
>>>> +
>>>> + ptr += na + ns;
>>>> + }
>>>> +
>>>> + for (bank = 0; bank < CONFIG_NR_DRAM_BANKS; bank++)
>>>> + ddrss->ddr_ram_size += ddrss->ddr_bank_size[bank];
>>>> +}
>>>> +
>>>> static void k3_ddrss_lpddr4_ecc_calc_reserved_mem(struct k3_ddrss_desc *ddrss)
>>>> {
>>>> fdtdec_setup_mem_size_base_lowest();
>>>> - ddrss->ecc_reserved_space = gd->ram_size;
>>>> + ddrss->ecc_reserved_space = ddrss->ddr_ram_size;
>>>> do_div(ddrss->ecc_reserved_space, 9);
>>>> /* Round to clean number */
>>>> @@ -696,7 +742,7 @@ static void k3_ddrss_lpddr4_ecc_init(struct k3_ddrss_desc *ddrss)
>>>> /* Preload the full memory with 0's using the BIST engine of
>>>> * the LPDDR4 controller.
>>>> */
>>>> - k3_ddrss_lpddr4_preload_full_mem(ddrss, gd->ram_size, 0);
>>>> + k3_ddrss_lpddr4_preload_full_mem(ddrss, ddrss->ddr_ram_size, 0);
>>>> /* Clear Error Count Register */
>>>> writel(0x1, base + DDRSS_ECC_1B_ERR_CNT_REG);
>>>> @@ -741,6 +787,8 @@ static int k3_ddrss_probe(struct udevice *dev)
>>>> k3_lpddr4_start(ddrss);
>>>> + k3_ddrss_ddr_bank_base_size_calc(ddrss);
>>>> +
>>>> if (ddrss->ti_ecc_enabled) {
>>>> if (!ddrss->ddrss_ss_cfg) {
>>>> printf("%s: ss_cfg is required if ecc is enabled but not provided.",
>>>> @@ -761,30 +809,24 @@ static int k3_ddrss_probe(struct udevice *dev)
>>>> int k3_ddrss_ddr_fdt_fixup(struct udevice *dev, void *blob, struct bd_info *bd)
>>>> {
>>>> - struct k3_ddrss_desc *ddrss = dev_get_priv(dev);
>>>> - u64 start[CONFIG_NR_DRAM_BANKS];
>>>> - u64 size[CONFIG_NR_DRAM_BANKS];
>>>> int bank;
>>>> + struct k3_ddrss_desc *ddrss = dev_get_priv(dev);
>>>> if (ddrss->ecc_reserved_space == 0)
>>>> return 0;
>>>> for (bank = CONFIG_NR_DRAM_BANKS - 1; bank >= 0; bank--) {
>>>> - if (ddrss->ecc_reserved_space > bd->bi_dram[bank].size) {
>>>> - ddrss->ecc_reserved_space -= bd->bi_dram[bank].size;
>>>> - bd->bi_dram[bank].size = 0;
>>>> + if (ddrss->ecc_reserved_space > ddrss->ddr_bank_size[bank]) {
>>>> + ddrss->ecc_reserved_space -= ddrss->ddr_bank_size[bank];
>>>> + ddrss->ddr_bank_size[bank] = 0;
>>>> } else {
>>>> - bd->bi_dram[bank].size -= ddrss->ecc_reserved_space;
>>>> + ddrss->ddr_bank_size[bank] -= ddrss->ecc_reserved_space;
>>>> break;
>>>> }
>>>> }
>>>> - for (bank = 0; bank < CONFIG_NR_DRAM_BANKS; bank++) {
>>>> - start[bank] = bd->bi_dram[bank].start;
>>>> - size[bank] = bd->bi_dram[bank].size;
>>>> - }
>>>> -
>>>> - return fdt_fixup_memory_banks(blob, start, size, CONFIG_NR_DRAM_BANKS);
>>>> + return fdt_fixup_memory_banks(blob, ddrss->ddr_bank_base,
>>>> + ddrss->ddr_bank_size, CONFIG_NR_DRAM_BANKS);
>>>> }
>>>
>>> Have we looked into passing this information via the global data pointer
>>> rather than fixing up the device tree on each boot phase?
>>>
>>> https://patchwork.ozlabs.org/project/uboot/patch/20180926215520.87168-23-sjg@chromium.org/
>>>
>>> I don't see a clear path to pass GD from SPL to SPL but there is a TPL
>>> to SPL which I think we should be able to copy.
>>
>> But we also make use of this to fix up the device tree that passes onto
>> kernel as well, I need to look into this patch though. But from a first
>> glance looks like we will be able to pass on the information from SPL->SPL
>> (with modification as you said) and SPL->U-Boot but U-Boot->Kernel would
>> still require this function to be present.
Just came across this series again and noticed that this will be a bit
tricky with boards detecting RAM at runtime.
Updating the memory node with detected RAM size prio to DDR driver
probing should be no problem. But the next stages will need to update
u-boot's and Linux memory nodes too. Unfortunately, we do not have the
data at this stage which tells us how much space was reserved for ECC.
It would be best to do the memory setup for GD or memory node once and
have other stages reuse it.
Right now I have no idea how my board should be aware of the reserved
ecc memory in u-boot. Any suggestions?
>>
>
> I agree. If this scheme works out we can place this kernel fixup
> function with the other OPN fixups we do though later on in the boot.
>
> https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-k3/common_fdt.c
next prev parent reply other threads:[~2024-12-06 12:53 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-21 4:40 [PATCH v4 0/8] Inline ECC Series Santhosh Kumar K
2024-10-21 4:40 ` [PATCH v4 1/8] ram: k3-ddrss: Use the DDR controller BIST engine for ECC priming Santhosh Kumar K
2024-10-21 4:40 ` [PATCH v4 2/8] ram: k3-ddrss: Add k3_ddrss_ddr_bank_base_size_calc() to solve 'calculations restricted to 32 bits' issue Santhosh Kumar K
2024-10-23 4:44 ` Manorit Chawdhry
2024-12-12 14:38 ` Santhosh Kumar K
2024-10-23 14:39 ` Bryan Brattlof
2024-10-24 4:01 ` Neha Malcom Francis
2024-10-24 16:19 ` Bryan Brattlof
2024-12-06 12:53 ` Wadim Egorov [this message]
2024-12-06 17:40 ` Bryan Brattlof
2024-12-12 14:39 ` Santhosh Kumar K
2024-10-21 4:40 ` [PATCH v4 3/8] ram: k3-ddrss: Setup ECC region start and range Santhosh Kumar K
2024-10-21 4:40 ` [PATCH v4 4/8] ram: k3-ddrss: Enable ECC interrupts Santhosh Kumar K
2024-10-21 4:40 ` [PATCH v4 5/8] drivers: ram: Kconfig: Add CONFIG_K3_INLINE_ECC Santhosh Kumar K
2024-10-23 14:45 ` Bryan Brattlof
2024-10-24 4:03 ` Neha Malcom Francis
2024-12-12 14:39 ` Santhosh Kumar K
2024-10-21 4:40 ` [PATCH v4 6/8] configs: j7*_evm_r5_defconfig: Set NR_DRAM_BANKS to 2 Santhosh Kumar K
2024-10-23 14:48 ` Bryan Brattlof
2024-12-12 14:40 ` Santhosh Kumar K
2024-10-21 4:40 ` [PATCH v4 7/8] board: ti: Pull redundant DDR functions to a common location and Fixup DDR size when ECC is enabled Santhosh Kumar K
2024-10-22 10:04 ` Wadim Egorov
2024-12-12 14:40 ` Santhosh Kumar K
2024-10-21 4:40 ` [PATCH v4 8/8] arm: dts: k3-*-ddr: Add ss_cfg reg entry Santhosh Kumar K
2024-10-22 9:22 ` Neha Malcom Francis
2024-12-12 14:40 ` Santhosh Kumar K
2024-12-12 14:38 ` [PATCH v4 0/8] Inline ECC Series Santhosh Kumar K
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b7dc8b69-cb3d-433a-adef-56e54e8db275@phytec.de \
--to=w.egorov@phytec.de \
--cc=bb@ti.com \
--cc=m-chawdhry@ti.com \
--cc=n-francis@ti.com \
--cc=nm@ti.com \
--cc=s-k6@ti.com \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
--cc=u-kumar1@ti.com \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox