MCU-PLUS-SDK-AM243X: Add way to inject configuration for "sciclient_set_boardcfg"

Hi Fabian,

I believe you're referring to the update method described in these locations:

1. https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/08_02_00_31/exports/docs/api_guide_am243x/RESOURCE_ALLOCATION_GUIDE.html
2. https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/08_02_00_31/exports/docs/api_guide_am243x/TOOLS_SYSFW.html#BOARCFG_GEN

This method requires:

• Step #1: manual modification of the files in <SDK>\source\drivers\sciclient\sciclient_default_boardcfg\am64x_am243x\sciclient_defaultBoardcfg_rm.c.
• Step #2: 3 build steps: board config header files, libs, and sciclient_set_boardcfg application (or SBL). It isn't clear which binaries are updated during the build process and presumably the binaries are "attached" to the selected resource allocation.

Can you please elaborate on your concerns a bit? Your concerns appear to be related to how the code is built.

Are you concerned there's a single copy of the files used for the board configuration in folder sciclient_default_boardcfg? Inspecting <SDK>\tools\sysfw\boardcfg\makefile, I see:

            SOC?=am64x
            ifeq ($(SOC),$(filter $(SOC), am64x am243x))
              SOC_FOLDER=am64x_am243x
            endif

So it looks like the make file could be modified to accommodate other folders.

Do you want to have build outputs placed in different folders for different resource allocations?

Regards,
Frank

Hi Frank,

thanks for the reply. This issue is also already addressed to Karim but I will explain it here a little bit more:

Yes it is about the resouce allocation. To configure the application "sciclient_set_boardcfg" which does this configuration on the target one must change the C-File sciclient_defaultBoardcfg_rm.c. This C-File lives inside of the SDK.

If we change the configuration there we change the installed SDK and the SDK is then directly tied to the specific product we are developing. If we are now developing a second product this configuration might be wrong since it is another hardware. The problem is then we need to install a seperate SDK for each product we are developing since every SDK needs its specific modifications. Also we need to keep track about all the changes inside the SDK per product.

Hope this makes it a bit more clear! 

Best Regards

Fabian

Hi Fabian,

Thanks for the response, I have a better understanding now.

It seems to me this could be handled with changes to the build system, but I don't know how involved this would be. Another possible solution is for you to check the code into source revision control, and have a branch for each product. This might prove cumbersome, since new SDK versions would need to be merged in your source revision control system.

Fabian Sorkalla said:

This issue is also already addressed to Karim

Ok, I don't want to duplicate effort, so I'll assign this to Karim and place myself on copy.

Regards,
Frank

Hi Fabian,

Apologies for the delayed response. The method to update boardcfg has changed a from the release you're referring to now. To update the boardcfg, we now provide a GUI tool as well. You can find the usage of this tool here: https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/latest/exports/docs/api_guide_am243x/RESOURCE_ALLOCATION_GUIDE.html

Considering your original question, about updating the boardcfg without touching the SDK, RM boardcfg is something which needs to provided to the System Firmware at the time of boot, before the application comes up. And it is considered as an SDK wide configuration, that is the reason we keep it in the SDK and bundle it up with the SBL image itself to utilize the ROM's ability to load the boardcfg.

In the specific case where ROM boot is not there -> CCS boot, we still need the boardcfg to be sent to SYSFW, that's what the sciclient_set_boardcfg application does. The way we send the boardcfg is by compiling the sciclient_defaultBoardCfg_rm.c to an object file and then converting that binary into a hex array, and then including it in the application. Because the APIs provided by SYSFW accept the boardcfg in runtime like that. If there is a change in the sciclient_defaultBoardCfg_rm.c file, we would need to regenerate this hex array and hence rebuild the sciclient_set_boardcfg application as well.

Keeping your concern in mind, and the above restrictions, I think a solution would be to modify the sciclient_set_boardcfg application to take in a custom boardcfg file rather than the one in SDK, and similar case in SBL. We don't have that capability in the SDK yet, but if this solves your problem, I can get back on a timeline when we can support this OOB from the SDK.

Regards,
Anand Mahadevan SS