This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM62P: Which memory is U-Boot SPL R5 running from?

Part Number: AM62P

Tool/software:

Hello TI experts:

I’m seeing that the start-address of the U-Boot SPL R5 code is 0x43c00000. That’s confirmed by the corresponding device tree node, the u-boot-spl.lds file, and some debug code I have added.

In theory, some type of RAM memory needs to be present in that address range of the SoC since the U-Boot code needs to be loaded by the ROM and DM-R5. However, I can find no corresponding entry in the memory map of the AM62P. The closest entry I find is called MSRAM_64K0_RAM, but it’s located at 0x43C40000 in the MAIN memory map:

The WKUP_R5FSS0 and MCU_R5FSS0 memory maps don’t show anything useful either and the “Region Address Translation” (RAT) function (seemingly) also cannot (or should not?) be used to remap memory in that area (from page 631 of the AM26P TRM):

Obvious question:
What's the "magic" here?

  • Hi Christian,

    there's a section in the TRM that discusses the memory region 0x43c0_0000 used by the bootloaders, see here:

    Besides that, other TRMs of related devices (AM62 TRM) have a section called "SoC Address Aliasing", that provides some further details. Please see below capture from the AM62 TRM. This section seems to be missing in the AM62P TRM, and I just filed a TRM enhancement request (ref: SITARAAPPS-4827) to have this investigated/fixed.

    Regards, Andreas

  • Thx Andreas!

    A couple of comments:

    • It may be useful to add SMS0_HSM_SRAM0 to the MAIN memory map.
    • It may be useful to use the same format for addresses throughout your documentation, primarily wrt the use of underscores. Capitalization and length are also inconsistent. The latter makes sense when referring to 36bit addresses, though.

  • Christian:

     with design documentation being sourced multi-nationally, in Dallas, Bengaluru India, and now even in Germany, I would agree some sort of consistency guidelines should be revisited in general (I had sourced an ASIC design manual back in the 90's)

    regards

    Jim Mrowca (ex-TIer, 1982-1997)

  •  with design documentation being sourced multi-nationally, in Dallas, Bengaluru India, and now even in Germany, I would agree some sort of consistency guidelines should be revisited in general

    Most of the "hard and critical, low-level" TRM content like register names, addresses, bit descriptions, etc. actually get sourced from the same databases that are used for SoC design, and the same applies for header files and definitions etc. used in our SDKs (MCU+ SDK, specifically) or firmware projects (TIFS, DM, etc.). So there's some good automation there, and consistency.

    Now, as for the TRMs, the "wordy" parts stilly rely on people setting the right associations to setup the structure, and then also double-check things are right. The issues is those TRMs are very very large, so it's hard to go through it always to make sure all content is there, current, and correct. While we certainly try there's a bandwidth/priority aspect to this for sure. However we always appreciate feedback, and will act on it. So TRMs usually mature/improve over time. The AM62P is still a rather "new" device, for example as compared to AM62 non-P.

    Regards, Andreas

  • It may be useful to add SMS0_HSM_SRAM0 to the MAIN memory map.

    I made this very suggestion before, but it was rejected, with the argument of it already being discussed on the "SoC Level Address Aliasing" section (which unfortunately is missing right now).

    It may be useful to use the same format for addresses throughout your documentation, primarily wrt the use of underscores. Capitalization and length are also inconsistent. The latter makes sense when referring to 36bit addresses, though.

    Let me see that I can find a way to provide this feedback. It'll certainly help with searchability.

    Regards, Andreas

  • It'll certainly help with searchability.

    Exactly. It's a struggle to find stuff in documents with such enormous size.

    I do see how difficult it must be to get that organized ;-)