RTOS/AM6546: AM65x development questions

VC Kumar

Intellectual 1260 points

Part Number: AM6546
Other Parts Discussed in Thread: AM6548

Tool/software: TI-RTOS

Online SDK RTOS documentation (http://software-dl.ti.com/processor-sdkrtos/esd/docs/latest/rtos/Foundational_Components.html#am65x ) in chapter 4.6.3.7 Boot modes states that AM65x IDK enables no boot with SBL via OSPI without stating any reasons
- OSP hardware seems to be available according to IDK and schematics
- Is that a hardware limitation or not yet put into effect in SBL?
Do you have a functional example for R5F TI-RTOS application that can be loaded via SBL?
- It seems there is an example for A53
- The R5F application has problems as described in chapter 1.2 as per attached document (which unfortunately is in GERMAN but maybe you can identify immediately what it is about per your knowledge)
  - Error code: Sciclient_procBootSetProcessorCfg, ProcId 0x1, EntryPoint 0x70005af0... Sciclient_procBootSetProcessorCfg...FAILED
  - Also using known-issues Link (see document) didn’t make start via SBL not possible
  - They assume that errors in linker-script or configuration of TI RTOS example for R5F processor is not compatible with other software (RBL, DSMSC SYSFW, SBL)
- Details of Memory-Mapping of ATCM and BTCM of R5F cores are not complete resp. not well documented
  - TRM describes that there is a dependence on "CPUn_INITRAMA/B bootstrap pins" und " CPUn_LOCZRAMA bootstrap pin". But it seems that is actually internal und controlled via DMSC. These and other properties of R5F, according to chapter 6.3.3.2, table 6-53 are being controlled with MCU_SEC_MMR register but is not documented
  - SBL uses parts of MSRAM and ATCMs but it is not clear how this is working with the variable memory mapping/

over 7 years ago

0 VC Kumar over 7 years ago

TI__Intellectual 1260 points

On the R5F question - please send me an email and I will forward the document referenced

0 Rahul Prabhu over 7 years ago in reply to VC Kumar

TI__Guru** 116950 points

VC,

The customer has correctly identified that OSPI is support on the EVM but there seems to be some misunderstanding in the interpretation of information provided in the Boot User Manual for the device. We currently support booting from SD/MMC and OSPI/QSPI in Processor SDK RTOS bootloader. The Programming of the OSPI flash on the board is done using "No boot mode" as the flash programming tool currently supports only flashing over JTAG as indicated here:
software-dl.ti.com/.../Board_EVM_Abstration.html

After the flash is programmed, user is required to change the boot mode setting to OSPI boot to run the device in OSPI boot mode. This is different from earlier Sitara devices as we previously had the boot ROM on sitara devices cycling through different boot mode based on a defined boot sequence while on the current device we support a primary and a secondary boot media which is selected using BOOTMODE pins.

There are examples included in the SBL package that show deployment of multi-core image that loads images on each of the A53 and R5 cores and also subsequently validated A53 and R5F TI RTOS examples running with the version of SBL. However, the validation with R5F TI RTOS was done post code freeze time line so there is known issue with a work around to get TI RTOS working listed in our Release Notes . Please ask the customer to refer to PRSDK-4147 listed in known issues here:
software-dl.ti.com/.../Release_Specific.html

I am assuming that this is the issue that the customer is referring to. Can you please check what image is the customer trying to load and if there is any way for us to reproduce this issue. Is the application using TCM memory on R5F or just OCRAM memory. It may help if we can get the map file for the application and some usecase details like if they are using split mode or lockstep, if they have verified that there is no memory overlap with SBL, etc.

The missing details of Memory-Mapping of ATCM of R5F cores are not complete resp. not well documented is a known issue that is being addressed during the 4Q2018 documentation update. This is partly caused by the following Cortex R TRM spec from ARM which changes the default base addresses for this memory(specified in our TRM) during R5F boot/reset sequence.

Exception vectors for R5F are either at 0x0000_0000 or 0xFFFF_0000 depending on the HIVECS bit of CP15 (see section 3.8.8 Exception vectors). This is programmable
- After boot, the enablement and the address of TCM A and TCM B can be programmed via software c9, BTCM Region Register (4.3.23) and c9, ATCM Region Register (4.3.24)

infocenter.arm.com/.../DDI0460C_cortexr5_trm.pdf (Check Table 1-2 for base address of exception table)

In TI SDK implementation, the base address of ATCM for R5F core 0 is mapped to ox00000000 from the default 0x41010000 that is specified in the TRM and the applications are required to use the first 0x100 of the memory to place the vector table based on configuration of the HIVECS registers in R5F spec.

Regards,
Rahul

0 Dominic Rath over 7 years ago in reply to Rahul Prabhu

Mastermind 7800 points

Hi,

thanks a lot for replying to our questions so quickly.

The OSPI question is with regard to the table in chapter 4.6.6.3 in the documentation found here: software-dl.ti.com/.../Foundational_Components.html

To me this suggested that booting via SBL from OSPI would only be supported on the EVM, not on the IDK.

This could be related to the SDK directory structure displayed here: software-dl.ti.com/.../Foundational_Components.html
- apparently there's only a sbl_lib_ospi.aer5f for the EVM, not for the IDK.

We haven't looked at the requirements for programming the OSPI yet, but switching bootmode seems reasonable, if that really is the only limitation.

Regarding our problem with running a TI-RTOS example when booting via SBL from SD card:

I believe you're refering to issue PRSDK-4741 (not 4147). We already tried changing the linker script and the config file accordingly, but that only resulted in a different error. Without the change from PRSDK-4741 we got the following error:

Sciclient_procBootSetProcessorCfg, ProcId 0x1, EntryPoint 0x70005af0...
Sciclient_procBootSetProcessorCfg...FAILED

After implementing the change from PRSDK-4741 we didn't even get to the point where Sciclient_procBootSetProcessorCfg gets called.

We tried building the example according to this guide from the documentation:
software-dl.ti.com/.../Examples_and_Demonstrations.html

We used the example provided in the "TI Resource Explorer Classic" at "SYS/BIOS - AM65x - Cortex A53 - IDK_AM65x - Cortex R - TI Target Examples - Generic Examples - Hello Example". Loading the example via JTAG worked just fine, but failed when using the SBL to load the application.

We also tried a bare-metal example and that worked just fine. When looking at the map files / ELF content we noticed that the examples are using different memory regions.

We'll re-create the steps from the guidelines and provide you the map file.

Regarding split/lock-step mode - I believe the "default" for the IDK is lockstep mode. We might want to use split mode in the future, but we're still in very early steps, so right now any working TI-RTOS example
would be fine for us.

Any kind of TI-RTOS example that works on the R5F on a AM65X_IDK when loaded via the SBL would help us as a starting point.

Regarding our question about the memory mapping for the R5F core:

Right now our main issue is that we're not sure where the memories are located during the whole boot procedure:
- how this relates to the settings in the .cfg file for an application
- how is the memory mapped during SBL exeuection
- does the SBL take care of "fixing" the mapping in case the application wants a different layout than what the SBL is using
- the AM65x TRM seems to just duplicate some stuff from the ARM core manuals (like "CPUn_INITRAMA/B bootstrap pins") but we believe that actually this is something that is controlled by the DMSC in the AM65x

This became relevant to us when the TI-RTOS example application wouldn't work when loaded from the SBL, but of course we would also like to understand the boot procedure in order to decide which memory we should use for what purpose.

You wrote about a 4Q2018 documentation update - is there an ETA for this updated documentation?

Best Regards,

Dominic Rath

0 Rahul Prabhu over 7 years ago in reply to Dominic Rath

TI__Guru** 116950 points

Dominic,

DId you get a chance to try the SBL from Processor SDK RTOS 5.02 that we release at the end of Dec 2018 to see if your issue is resolved.

Let us know if there are still some issues that you have observed so we can follow up.

Regards,
Rahul

0 Dominic Rath over 7 years ago in reply to Rahul Prabhu

Mastermind 7800 points

Hello Rahul,

the issue about not being able to boot a TI-RTOS application because either the Sciclient calls or the SBL crashes is solved with 05.02, but there are other issues like the dmtimer problem: e2e.ti.com/.../762215

I believe the question regarding OSPI support on the IDK is resolved, too. With SDK 05.02 there is a sbl_lib_ospi.aer5f for the IDK.

The questions regarding memory mapping in general are still open, although not as pressing, as the original problem about booting a TI-RTOS app via SBL are solved.

You mentioned in your original e-mail a "4Q2018 documentation update" - is there any news on this documentation update? I believe the TRM on the AM6548 website is still Rev. B from September 2018.

A new issue with 05.02 (that doesn't affect us) is that building the SBL fails for the EVM+OSPI. Apparently the MCU SRAM put aside for the SBL is very tight. It works for the IDK+OSPI, it works for EVM&IDK+MMC/SD, but fails for EVM+OSPI, and surprisingly it seems to work when you (TI) built the binaries that ship with the SDK on Linux, but fails when we're building on Windows.

Regards,

Dominic

0 Rahul Prabhu over 7 years ago in reply to Dominic Rath

TI__Guru** 116950 points

Dominic,

We have updated the Processor SDK RTOS Software developers guide to add more boot related details but it appears the TRM update doesn`t occur at quarterly cadence so the updates regarding boot are still being rolled into the manual. Current ETA is mid March

I am able to reproduce this issue on Windows platform and the only quick fix that I can provide you is to force the compiler to build the SBL in Thumb2 mode using --code_state=16 instead of --code_state=32. I compared the IDK and EVM SBL for OSPI and see additional 0cx500 bytes in the binary that I am trying to trace.

If you want to try the Thumb2 mode fix change line 171 in the file pdk_am65xx_1_0_3\packages\ti\build\makerules\rules_ti_cgt_arm.mk

Regards,
Rahul

Processors

Processors forum

RTOS/AM6546: AM65x development questions