• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 102 subscribers
  • Views 1066 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Bare metal and the k2e pdk

Hannan Khan
Expert 1080 points
Other Parts Discussed in Thread: SYSBIOS

Hi guys !!

okay so i have been trying to work to get something on bare metal A15 of k2e. i was previously able to get the uart0 working by looking at the uart boot sequence from the "bootexamples"

i was thinking of taking the work one step further and work with other peripherals including gpio i2c etc so in order to do that i started working with the 4.02 PDK for K2E specifically.


i found that only SPI, I2C, UART & GPIO had some kind of provision for baremetal and the rest were with sys/bios.

out of all 4 only UART compiles completely once i add the "BARE_METAL" symbol but that also get stuck once i load the program.

my question is that is there any provision for bare metal in the pdk?

and if i want to create my own project via using the files in the pdk, how can(if possible) i achieve that?

thanks guys !!

  • 0
    TI__Mastermind 43955 points
    Hi Hannan Khan,
    Which example you are not able to build with BARE_METAL defined ?

    Yes, you can create your own CCS project with PDK, just add the PDK packages folder in RTSC section while you create the SYSBIOS project.
  • 0 in reply to Shankari G
    Expert 1080 points
    hello Shankari,

    i am not able to build the following :
    SPI_BasicExample_K2E_armTestProject
    SPI_BasicExample_K2E_armExampleProject

    I2C_BasicExample_K2E_armTestProject
    I2C_BasicExample_K2E_armExampleProject

    GPIO_LedBlink_K2E_EVM_armTestProject
    GPIO_LedBlink_K2E_EVM_armExampleProject

    i was able to build :
    UART_BasicExample_k2e_armTestproject
    UART_BasicExample_K2E_armExampleProject


    all of these have #ifdef for BARE_METAL, the rest use sys/bios only

    when i try to create a custom bare metal project i end with huge amounts of undefined references.
  • 0 in reply to Hannan Khan
    TI__Mastermind 43955 points

    Hi Hannan,

    Hannan said:
    i am not able to build the following :
    SPI_BasicExample_K2E_armTestProject
    SPI_BasicExample_K2E_armExampleProject


    Personally I have built these examples ( with sysbios) multiple times i.e., "as-is" but not defining the "bare_metal". I will be of some help to you.

    Also I'm able to build the "I2C_BasicExample_K2E_armTestProject" example with "BARE_METAL" defined, with adding some extra dummy function "i2c_test" to avoid the undefined build errors" but I'm not able to run and got some exception as we are running SYSBIOS example as BARE_METAL.

    I need to check with internal team whether that option of using it as a bare metal is available or not.

    Are you able to build and run successfully without defining the "BARE_METAL" ??
    or in other words, are you able to build and run the example as-is on K2E EVM??

    I think, this example is supposed to be work along with the SYSBIOS and not as a bare metal.
    May be it is still not ready to run as a bare metal. Otherwise, they would have mentioned about the option of baremetal in any of the userguide/ release notes.

    After you answer my above question, I will post you the steps of importing, building and running these examples on the k2E EVMs if you are not bothered of enabling the "bare_metal".

  • 0 in reply to Shankari G
    Expert 1080 points
    hi again !!

    yes i was able to run 1 of the examples as is (did not try the others) so i assume that the others would be working as well.

    i also came upon the same conclusion that the projects are not ready for bare metal, rather it is more of an abstract on how bare metals would be created. i.e. without xdc & sysbios etc
  • 0 in reply to Hannan Khan
    TI__Guru** 115300 points
    Hannan,

    the BARE_METAL flag is a work in progress and hasn`t been enabled completely yet. For SPI, I2C, EMIF16 NAND/NOR interface, I recommend that you take a look at the flash writer utilities which are CSL based. Also there is example code for I2c, UART in the Platform library for the device. (pdk_xx_xx_xx\packages\ti\platforms)

    This has been mostly been instrumented for the DSP but since it is register and functional CSL code, you should be able to integrate this in your ARM code as well.

    Hope this helps.

    Regards,
    Rahul
  • 0 in reply to Rahul Prabhu
    Expert 1080 points
    yea i understand it for the most part and was able to get at least the UART working.... but the problem here is that most of the CSL & docs have been designed to cater DSP processor, is there any documentation that would be useful while working on ARM system?
  • 0 in reply to Hannan Khan
    TI__Guru** 115300 points

    Yes, you are right. A majority of the users for this devices have a Highlevel OS running on the ARM hence the SDK is structured for CSL bare-metal development on the DSP. However with a dedicated Processor SDK RTOS, we plan to extend the LLD offering to ARM on the K2 devices as well. 

    Since CSL is register level, all of the code for the DSP should apply to the ARM. Only things specific for the ARM is setting up of the MMU, interrupt vectors and boot monitor if there is some functions that need to be executed in supervisor or monitor mode. Some of these functions are provided as part of the A15 CSL code which you can locate at  

    pdk_k2hk_4_0_2\packages\ti\csl\arch\a15

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Expert 1080 points
    thanks Rahul !!

    i can confirm that the GPIO, UART, TIMER etc of the 4.02 CSL is in working condition without changing anything. my only problem is getting interrupts working. i looked into the directory as you mentioned but i was hoping an example project of some sorts could be available which could hint towards taking the steps to generate interrupts properly.