Heap refinement Part 2 -- make full use of HPSRAM in buffer zone

[keyonjie]

cavs: memory: make full use of HPSRAM

Make size of the buffer zone calculated at the linking stage, to make
full use of all HPSRAM memories.

[keyonjie]

SOFCI TEST

[lgirdwood]

@kkarask @wszypelt can someone restart the CI platforms. Thanks !

17:34:16.079     Timed out after 5.0 seconds.

17:34:16.156     => Exception in test.
17:34:16.172       Exception TimeoutError occurred at 'C:\\work\\tools\\pyexecnetcache\\cavs_scripts-py\\utilities\\fw_loader_pci.py':499
                   Cleaning ROM control IPC failed. Platform restart may be required.

17:34:16.234  === END OF ITERATION === 
17:34:16.259 Test End: 2021-09-09 17:34:16.259

17:34:16.259 Test Duration: 0:00:44.746818

[kkarask]

PR passed after platform restart and rerun.

[lgirdwood]

Thanks @keyonjie this increases the available blocks in the allocator, we can further refine for rc2/final if needed.

[lyakh]

maybe some of these comments are worth addressing in a follow-up PR

[lyakh]

SOF_FW_END is defined as (HP_SRAM_BASE + HP_SRAM_SIZE - 0x1000) and HP_SRAM_BASE is defined to 0xbe000000, so, they both are absolute addresses. _buffer_heap_start is also an absolute address, corresponding to the (relative) current address .. So, SOF_FW_END - _buffer_heap_start is the memory size from "here" to the end of HP SRAM, right? So the above line calculates the relative address of SOF_FW_END. And below _buffer_heap_end is the respective absolute address again, i.e. it's just equal to SOF_FW_END isn't it? Wouldn't it be easier to just use _buffer_heap_end = SOF_FW_END?

[keyonjie]

correct, but we are using some common formats for each zone here:
xx_heap_start = ABSOLUTE(.);
. = . + XXX_SIZE;
xx_heap_end = ABSOLUTE(.);

With this format, we can change the "XXX_SIZE" easily and corresponding change to xx_heap_start/end is not needed.

OTOH, this is aligned with other non-Intel or non-cAVS platforms also, where there could be no definition of SOF_FW_END at all.

[lyakh]

do you have an idea how much RAM this is wasting?

[keyonjie]

yes, I talked this with @lgirdwood , it is 8B/256B about 3%here.

There are some waste, the percentage is up to how much of it is inevitable: e.g.
On TGL like (~3MB HPSRAM), we have about 2/3 memory used for this BUFFER zone so only 1/3 * 3% = 1% is wasted.
On APL like (~0.5MB HPSRAM), the wasting is worst as there is about 1/3 memory used for this BUFFER zone so about 2/3 * 3% = 2% is wasted.

I previously has some calculation to improve it for small SRAM platforms, like

/* the buffer zone will not occupy more than half of the HP SRAM */
#define HEAP_BUFFER_COUNT_MAX  (HP_SRAM_SIZE / (HEAP_BUFFER_BLOCK_SIZE * 2))

This could help to bring back about 5KB memory for us, we can do this kind of fine tune incrementally.

[lyakh]

47 has no special meaning, right? It's just to match one of existing platforms? You could use 4 or 32 or 1024 here or whatever? Maybe at least add a comment there

[keyonjie]

yes, let me add a comment for it.

[lgirdwood]

@lyakh this is a bit of a chicken and egg situation wrt to the linker script and the amount of SRAM free after TEXT, DATA and BSS sizes are known when creating the static heap block arrays. Not a problem in Zephyr as it uses lists in its allocator.