CCS/AM5718: Building custom board for RTOS

Stefan,

Sorry to know that the custom board porting for your project is not going as expected despite reviewing all the documentation that we have around this topic.  We are in the process of overhauling the Custom board port documentation and I would like to give you a preview and see if this helps. 

Here is the typical development flow that we expect a user to create a custom BSP for their own platform:

This flow has been put together based on the internal development flow that the TI team follows whenever we create a new platform that we need to add to the Processor SDK RTOS. For example AM571x IDK was created after AM572x EVM.

Step 1: Before doing anything with the peripherals, can you let us know if you have a working GEL file with the updating clocking and DDR setup such that you can connect to all the cores and load and run simple hello world code from the cores. Other than GEL this should not require any porting.

Step 2: When porting Processor SDK RTOS to custom platform, the CSL and driver, OSAL doesn`t need to be re-built as these are components that we provide which are not reliant on any external board configuration. All of the changes corresponding to your HW are consolidated in the Board library and that is where you should focus on.

Some key things to take care of in the board library:

1. The simpler approach to start would be to use existing TI platform that your HW resembles and update the source files directly in that folder and rebuild the board library.

If you want to created your own board library you can create a separate folder and update the build as shown below:

http://processors.wiki.ti.com/index.php/Adding_Custom_Board_Library_Target_to_Processor_SDK_RTOS_makefiles 

2. TI HW has a personality EEPROM connect to I2C that provides version number, silicon revision and board ID for software to use. IF your board doesn`t use the personality EEPROM, please remove that code.

3. Pinmux changes: After the pinmux project for your HW is generated, the source files for PDK are provided by the tool so you can simply drop those into board.

In addition to this change, you need to ensure that the clock and the peripheral instances are updated in the _clock.c and the board_cfg.h file.

4. DDR changes: Make sure you have tested the GEL file with updated clocking and EMIF Controller and PHY before updating the board library.  This is critical else the board_init for DDR will fail. while you figure this out, you can choose to run and test the HW using on chip OCRAM memory instead.

Leverage the EMIF Tools that we provide to generate these settings.

http://www.ti.com/tool/SITARA-DDR-CONFIG-TOOL 

5. The first thing to check would be to use board diagnostics and check the interfaces for functionality. There are many useful tests like DDR mem test, GPIO, I2C EEPROM and SPI test that don`t use interrupts or DMA and are simple tests that we provide for HW checkout. This will also help confirm that the pinmux and clock chnages you made are as expected.

 6. You can then move to more advanced interfaces like CPSW, PCI, USB and check to see if your MDIO-PHY interface and USB device and host mode setup are working.

Having said that if you are looking for a third party to help with this port, there are several partners that we work with that can help you with this effort that you can find from the list here:

TI DEsign Network Resources

Based on the region that you are based in and the type of service you can pick from the list.

Regards,

Rahul

PS: I know that you indicated that you don`t want links to training and collateral as you are not looking for basic stuff. To skip basic information and go directly to the relevant section in the training, you can go directly to Section 9 of the training application development with processor SDK RTOS

Stefan Thorlacius said:

The strange thing in both description is the line
CFLAGS_GLOBAL_customAM572x  = -DSOC_AM572x -DevmAM572x

Should not
CFLAGS_GLOBAL_customAM572x
be
CFLAGS_GLOBAL_customBoard
in line with the other text ?

We also assume that the lines

ifeq ($(BOARD),$(filter $(BOARD), myCustomBoard))
  PLATFORM_XDC = "evmAM572XCustom"
endif

Makes it visible in the CCS gui when creating new (RTOS, SYS/BIOS) project, that is, even if our board/package is using 'myCustomBoard' in file names and in makefiles it will be
listed as 'evmAM572XCustom' in the GUI.

I would recommend keeping this consistent with the custom Board name that you have picked. If you have used directory name "CustomBoard" use CFLAGS_GLOBAL_customBoard and name the XDC platform also as CustomBoard. Staying consistent will help locate all the files updated when you search in the PDK folder and ensure that you didn`t miss any updates to the makefiles.

Stefan Thorlacius said:

Here is another strange thing we can not sort out, already in the idk571x folder there is both the file idkAM571x_pinmux and the files
generated from the PinMux tool (boardPadDelayDevice.c, boardPadDelay.h), is not the PinMux files used in the build ?
We have assumed that we just dropp the PinMux files into the directory and they are "used" in the build.

 idkAM571x_pinmux project has been to import the baseline idkAM572x pinmux settings in the TI pinmux tool so you can modify that baseline rather than having to start from scratch. this is especially useful when your board is based of one of TI`s HW like in your case.  You can update the file after importing it and then just download and drop the files generated for PDK.  After you drop the updated files, you will need to rebuild the board for the changes to take effect.

You can check the muxmode field in the PADCONFIG register for some of the key changes you made to verify the changes are applied. Dont forget the clocks and the peripheral instances specified in board_cfg.h  and _clock.c file to ensure the module is power up and enabled.

Stefan Thorlacius said:

already now it build without errors but does not show up in the CSS GUI

Good to know you are able to make progress here. Just to clarify the update to the .xdc or .bld files will not show up in CCS GUI but will be recognized by the XDC tools setting when you build a BIOS project.  For this to take effect you will need to update the BIOS configuration file as shown below:

/* Load the Board package and set the board name */
var Board = xdc.loadPackage('ti.board');
Board.Settings.boardName = "customBoard";  // Was previously "idkAM572x"

Stefan,

I was able to prioritize the collateral to address this porting in the software developer guide which should now be available here:

http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_board.html#custom-board-addition

Stefan Thorlacius said:

Is it correctly assumed that the system design of the TI board "construction" is that, whatever peripherals we have?

we add the init call of the LLD to Board init function in idkAM571x.c and then the initializing code of the LLD to

idkAM571x_lld_init. (I know, it seems to be obvious but just to be sure)

Let's say we want to add the LLD for USB/SPI/GPIO/mmcsd we do it similar as with the I2C?

No, the LLD init in board is limited to peripherals required to setup the SOC and key interfaces like I2C LLD for PMIC (power management) and Board ID detect, MDIO PHY for Networking and UART for debug logging. you can initialize other peripherals if you choose to but I would recommend that you keep other peripheral init in the application to allow for flexibility of modifying the LLD configuration  (DMA, interrupt, mode of operation, etc) without having to rebuild the board library. 

No, if you see the code in the function it is calling I2C open only for the instance that is connected to the EEPROM. The I2C configuration however seems to be changed for all instances. In this case, the code doesn`t need to do it for all instance. It can limit the driver configuration change the BOARD_I2C_EEPROM_INSTANCE

Stefan Thorlacius said:

> be recognized by the XDC tools setting when you build a BIOS project. 

> For this to take effect you will need to update the BIOS configuration file as shown below:

> /* Load the Board package and set the board name */

> var Board = xdc.loadPackage('ti.board');

> Board.Settings.boardName = "customBoard";  // Was previously "idkAM572x"

If you look at any RTOS PDK example project. Each project contains a .cfg that indicates which BIOS and PDK module needs to be included and the configuration setting of each of these modules. For example: Look at the AM572x UART driver example configuration file located at pdk_am57xx_1_0_xx\packages\ti\drv\uart\example\sample\am57x\armv7\bios\uart_arm.cfg

Check the setting that includes the board library using the script 

/* Load the Board package and set the board name */
var Board = xdc.loadPackage('ti.board');
Board.Settings.boardName = "idkAM572x";

If you are not using RTOS then this comment doesn`t` apply to you. In case of bare-metal  code, you can simply link to the correct board library in your linker settings.  You don`t need to modify anything in the BIOS package. All of your board porting changes should be limited to PDK package. 

Stefan Thorlacius said:

Your recomendation is to remove the Board_getIDInfo and Board_writeIDInfo (beacouse we do not have the TI specific EEPROM) sound correct.

The reason to keep Board_uartStdioInit in the board build is to make it possible for the examples and diagnostic application to output a result in case we want to make the SPI diagnostic test?

This also means that we should keep Board_icssEthConfig if we want the examples and diagnostic applications to work ?

That is correct. To reuse the software that we provide for the IDK, you would need to remove the BOARD ID and EEPROM related code. Also since you are reusing the design for SPI and ICSS, you can keep that code in the board llbrary so you can call into the functions and run diagnostic based of the same code to checkout your design. 

Stefan Thorlacius said:

When is the function Board_init supposed to be called ?

In

?

1	ti/pdk_am57xx_1_0_13/packages/ti/drv/uart/test/src/main_uart_test.c

it is expclicitly called but in

?

1	/ti/pdk_am57xx_1_0_13/packages/ti/drv/uart/example/UART_BasicExample_Intr_ExampleProject/src/uart_intr_test.c

t is never called (if it is not called in Error_init or BIOS_start)

or the line

?

1	var System    = xdc.useModule('xdc.runtime.System');

is calling it?

Will the CCS compile the argument to function Board_init depending on what is declared in the .cfg file.

Board_init is an initialization call so is usually called right at the beginning of main in the application or in your bootloader code where SOC/system static initialization is required before exercising the cores and interfaces.

Board_init call is an API call into the board library that you include using the .cfg file using the following syntax

/* Load the Board package and set the board name */
var Board = xdc.loadPackage('ti.board');
Board.Settings.boardName = "idkAM572x";

You need to include the board.h header file for the compilation to pick up the macros that are passed to the Board_init. To link to the board library that you have created, you can change this to 

Board.Settings.boardName = "P2HMI";  //Make sure this matches your board name.

The platform that you are picking in the CCS in the screenshot is the BIOS platform definition which specifies the core that you are compiling for and the memory layout of the platform. This is not related to board and typically you can set this to evmAM572x.

If you are interested in seeing how the memory is defined refer to the file Platform.xdc here:

bios_6_7x_xx_xx\packages\ti\platforms\evmAM572X

This only defines the cores in the SOC and memory map so typically doesn`t need to be modified. 

Stephen,

The way the RTSC BIOS build works. The XDCtools looks for modules in the .cfg file in the package repositories that you have specified in your project. Can you check and confirm the XDC Settings of the project and confirm PDK\ packages is added there as shown below:

Regards,

Rahul

Stefan,

When you start with Processor SDK RTOS development, one of the first getting started steps is to discover processor SDK RTOS components  as described here:

http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_how_to_guides.html#overview

When you complete this process, you will see the PDK being added to CCS Products (Windows->Preferences-> Code Composer Studio-> Products)

This allows user to add this product to their project when creating a  new project and defines the MAcro in the linked resources as you can see in screenshot below:

Regards,

Rahul

Stefan Thorlacius said:

After pressing the "Rediscover…." button in the CCS preferences, recreating a Project based on the ti.evm571xx and then added your suggestion

/* Load the Board package and set the board name */
var Board = xdc.loadPackage('ti.board');
Board.Settings.boardName = "customBoard";  // Was previously "idkAM572x"

The buildenvionment seems to found it, we could compile the Project without errors but we have not tested it yet, let us investigate it a Little more.

Glad to know you are making progress. I suspected some issue with the setup as the variables get auto defined when the eclipse plugin for the PDK package is detected in CCS.

Stefan Thorlacius said:

I suggest that the follwoing is added to the "how to build custom board build description" you provided earlier

• That the custom platform will not show up in the GUI, these are SYS/BIOS internal platforms
  
  If not, it will confude people that their board does not show up in the GUI

Thanks for the suggestion. I will update the documentation to reflect this to avoid any confusion.