• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 1307 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

understanding clock management in the AM335x starterware code

Aijaz Baig
Prodigy 130 points

Hello folks.

Ive downloaded the starterware and I am now using that as a base to build up on. However Im trying to understand the starterware code itself as an exercise that my come handy for other boards/devices

Now Ive got the beaglebone (hereafter referred to as the bone).

Moving on with the bootloader code, we start from bl_start() in bl_main.c. From there we move on to configVddOpVoltage(). A part of it involves configuring the clock for the module I2C0.

Inside the function I2C0ModuleClkConfig, the first thing we do is we write to the MODULEMODE field of the CM_PER_L3_CLKCTRL register. Now what I do not understand here is that, this field only comes into picture for the 'idle protocol management'. As per the TRM 'For the idle protocol management on the PRCM moduleside,the behavior of the PRCM module is configuredin the CM_<Powerdomain>_<module>_CLKCTRL[x]MODULEMODE bitfield. Based on the configured behavior,the PRCM module asserts the idle request to the module unconditionally (that is, immediately when the software requests).'.

Now my first question is, how do we know, that the i2C0 module is the slave module? I mean is it because there is already an i2c master on the chip and all other modules are supposed to be slave modules all the time?

And my second question is about the following line in the TRM: 'Slave idle protocol:Clock-management protocol between the PRCM and slavemodules Master
stand by protocol'. What exactly does it mean? The sentence was not really clear here./...perhaps a typo..im not sure..

Keen to hear folks

  • 0
    Intellectual 485 points

    Ajiaz,

    Anybody would get confused with the amount of information in the TRM - which is inevitable.

    To start with you may have to understand the chapter 10 and then move on to read other chapters like the PRCM you are referring to.

    If you see section 10.1.2.3, you will see a table of MASTER/SLAVE connectivity. Any entity which can initiate a request for read/write is called a MASTER(initiator) and that which cannot initiate but only respond-to the read/write requests is called a SLAVE(target). So, in the example you have given, an I2C module instance (I2C0,1 etc) cannot initiate a read and/or write request, since they really do no interact with the memory to fetch or put data. An external master like a CPU or a DMA does this (to transfer data via the data port of the I2C). This I2C instances are called slaves and CPU and/or the DMA as masters.

    Please note that here, the MASTER/SLAVE reference is not with respect to the device protocols but the way the entity behaves with respect to the interconnect inside the SOC.

    And yes the second question yo have raised is a typo. The last three words (Master Standby protocol) should have been in the next line to highlight the start of the next section to describe the Master Standby Protocol.

    Hope this helps.

    Regards,

    Madhvapathi Sriram

  • 0 in reply to Madhvapathi Sriram
    Prodigy 130 points

    Hi Sriram

    Madhvapathi Sriram said:
    Anybody would get confused with the amount of information in the TRM - which is inevitable.

    thanks for acknowledging that.

    Madhvapathi Sriram said:

    If you see section 10.1.2.3, you will see a table of MASTER/SLAVE connectivity. Any entity which can initiate a request for read/write is called a MASTER(initiator) and that which cannot initiate but only respond-to the read/write requests is called a SLAVE(target). So, in the example you have given, an I2C module instance (I2C0,1 etc) cannot initiate a read and/or write request, since they really do no interact with the memory to fetch or put data. An external master like a CPU or a DMA does this (to transfer data via the data port of the I2C). This I2C instances are called slaves and CPU and/or the DMA as masters.

    I now understand that the terms 'master' and 'slave' are with regards to the connective fabric that is binding together the various modules on the SoC and not the I2C protocol per se. The AM335x is relatively more complex that way, than say the atmel 7S series of microcontrollers. It is a true modern day SoC in that it employs multiple levels of heirarchy and uses a dedicated protocol (the OCP if I am not wrong) for managing the various different cores on this SoC (which is more of a NoC, a network on chip that is). I must say that I found the naming of the levels viz. L3 and L4 misleading. I was trying to find L1 and L2 (do they exist and if they do, where do I find them in the TRM?)

    Now that I can see from figure 10-2 that the I2C channels (with each channel being the entire I2C infrastructure on the SoC for that channel right?) are slaves and they talk to the cortex a8 core via L4_PER->L3S. Having understood that, here are further questions which take this discussion to the next level. Here are they:

    1. why do we go about setting up the I2C as the very first thing in the bootloader code?  Is it because without doing that, we cannot access the power management IC (PMIC) on the board? Or is it because we are trying to access the EEPROM on which the board configuration has been hard coded?
    2. If we are doing this to access the EEPROM fine but why would we need to access the PMIC so early during startup?  From the bone SRM I can see that by reading the PMIC one can determine whether we are running on 5V or on USB power. This can later be used for determining the operating frequency etc. Also one can determine which LDO will be shut off and which will remain alive in various power modes
    3. Can I find a recommended 'laundry list' of tasks to do at the startup for the AM335x and/or the Beaglebone as a whole? I would be greatly obliged if you could point me to it. May not be a complete list, but even suggestions or hints would also do.

    Keen to hear from you.

    Regards,

    Aijaz Baig.

  • 0 in reply to Aijaz Baig
    Intellectual 485 points

    Aijaz Baig said:

    why do we go about setting up the I2C as the very first thing in the bootloader code?  Is it because without doing that, we cannot access the power management IC (PMIC) on the board? Or is it because we are trying to access the EEPROM on which the board configuration has been hard coded?

    In general, any peripheral, before it is touched, needs to be setup properly, That means enabling clocks for that peripheral, setting up speeds, setting up modes etc. This is truly followed in the case of bootloader too.

    The reason I2C is being initialized first, is evident from the code. The first SoC specific stuff that is done in the bootloader is to set up the Operating Point (OPP) of the SoC/CPU. An operating point, as you may know is a Voltage/Frequency pair. So, the voltage has to be setup, which is via configuring the regulators in the PMIC and because the PMIC is interfaced via I2C, the I2C peripheral needs to be brought out of reset and configured/setup.

    Aijaz Baig said:

    If we are doing this to access the EEPROM fine but why would we need to access the PMIC so early during startup?  From the bone SRM I can see that by reading the PMIC one can determine whether we are running on 5V or on USB power. This can later be used for determining the operating frequency etc. Also one can determine which LDO will be shut off and which will remain alive in various power modes

    As mentioned above, I2C is not only for USB related voltage sensing. It is for the OPP settings

    Aijaz Baig said:

    Can I find a recommended 'laundry list' of tasks to do at the startup for the AM335x and/or the Beaglebone as a whole? I would be greatly obliged if you could point me to it. May not be a complete list, but even suggestions or hints would also do.

    Unfortunately, nothing is as easy. I have always learned it the hardway - Browse the code, refer to the docs, understand whats-in and then adapt the changes to suit your scenario.

    Hope this helps.

    Regards,

    Madhvapathi Sriram