• State TI Thinks Resolved
  • Locked Locked
  • Replies 16 replies
  • Answers 3 answers
  • Subscribers 99 subscribers
  • Views 400 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.

AM67A: Power-off sequence from linux to PMIC

Michael Walle
Prodigy 130 points
Part Number: AM67A

Tool/software:

How is the sequence of a power-off starting from a "poweroff" command to power-down of the voltages of the PMIC?

Here is what I presume is happening:

  1. linux kernel will issue a PSCI system off command to the implementation in TF-A.
  2. TF-A will send a message to a sci server. 
  3. ??

Open questions:

  • Where can I find the source code for this sci server (for the J722S/AM67A)
  • As the binary is taken from the ti-linux-firmware repository (I presume), that implemenation can just be something generic. But OTOH the power off is really board specific (i.e. depends on the PMIC, its configuation, etc.) So I further presume, that cannot be part of the generic firmware. Thus, where is that stored?
  • Is there a message sequence flow of all the involved components?

Thanks,
-michael

  • 0
    TI__Guru 64520 points

    Hi,

    Our expert is on vacation this week. Kindly expect delay in response.

    Best Regards,
    Sudheer

  • 0
    TI__Guru**** 163100 points
    Michael Walle said:
    linux kernel will issue a PSCI system off command to the implementation in TF-A.

    That's correct. 

    Michael Walle said:
    TF-A will send a message to a sci server. 

    This is correct as well.

    Linux --> ATF--> TIFS --> DM.

    Michael Walle said:
    Where can I find the source code for this sci server (for the J722S/AM67A)

    This is part of j722s RTOS SDK.

    Michael Walle said:
    • where is that stored?
    • Is there a message sequence flow of all the involved components?

    Source code is part of RTOS SDK. If the board schematics are same then that could be reused.

    Best Regards,

    Keerthy 

  • 0 in reply to Keerthy J
    Prodigy 130 points

    Hi,

    thanks for the answers.

    Keerthy J said:
    Source code is part of RTOS SDK. If the board schematics are same then that could be reused.

    Could you point me to the code where the power-off sequence is eventually landing inside of the RTOS SDK?

    Thanks,
    -michael

  • 0 in reply to Michael Walle
    TI__Guru**** 163100 points

    Hello Michael,

    https://git.ti.com/cgit/processor-sdk/pdk/tree/packages/ti/drv/sciclient/soc/V2/sciclient_pmic.c

    Sample implementation for J7200. I checked with team internally and this is still not implemented for J722s.

    Allow us some time to check on this and get back on when this will be enabled.

    - Keerthy

  • 0 in reply to Keerthy J
    Prodigy 130 points

    Hi Keerthy,

    this is just the client, I was looking for the code which is actually powering the board off.

    Thanks,
    -michael

  • 0 in reply to Michael Walle
    TI__Guru**** 163100 points

    Hi Michael,

    https://git.ti.com/cgit/processor-sdk/pdk/tree/packages/ti/board/src/j721s2_evm/board_power.c#n60

    Something like above. A sequence of I2C commands need to be implemented to power off the PMIC.

    Currently its not there for J722s.

    - Keerthy

  • 0 in reply to Keerthy J
    Prodigy 130 points

    Hi Keerthy,

    Thanks. And that will be part of the RTOS SDK (and not of the PDK)? Or does the RTOS SDK make use of the PDK?

    Also, won't this be a resouce conflict if both linux (or the rich os) and the firmware make use of the PMIC?

    And furthermore, this also means we have to ship over own PDK (fork), correct? Because I'm certain the power-off sequence won't work with our board.

    -michael

  • 0 in reply to Michael Walle
    TI__Guru**** 163100 points

    Michael,

    Michael Walle said:
    Also, won't this be a resouce conflict if both linux (or the rich os) and the firmware make use of the PMIC?

    Are there any use cases for hlos controlling PMIC? If not then R5F running DM should control the PMIC. 

    Michael Walle said:
    ermore, this also means we have to ship over own PDK (fork), correct? Because I'm certain the power-off sequence won't work with our board.

    Yes the implementation is a reference on EVM and depending on your PMIC solution the last set of i2c writes will differ based on the custom solutions.

    Best Regards,

    Keerthy 

  • 0 in reply to Keerthy J
    Prodigy 130 points

    Hi Keerthy,

    Keerthy J said:
    Are there any use cases for hlos controlling PMIC? If not then R5F running DM should control the PMIC. 

    Yes, because HLOS might want to control the voltages of the PMIC. See your beagly-ai board for example, which is using the PMIC in linux:
    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/ti/k3-am67a-beagley-ai.dts?h=v6.15-rc3#n357

    Keerthy J said:
    Yes the implementation is a reference on EVM and depending on your PMIC solution the last set of i2c writes will differ based on the custom solutions.

    Thats pretty bad IMHO, esp. because yocto and buildroot is using the firmware blobs (which then only supports your EVM) from your ti-linux-firmware repository. So, for example, how would we add support for our board within buildroot?

    Are there any plans to move away from board specific firmwares to SoC specific ones?

    Thanks,
    -michael

  • 0 in reply to Michael Walle
    TI__Guru**** 163100 points

    Michael,

    Here is the rationale. We need every core to acknowledge that SOC is getting powered off.

    Linux --> ATF(A72) --> TIFS(M3/M4) & Finally DM(R5F) gets the message to finally power off the system.

    Michael Walle said:

    Are there any plans to move away from board specific firmwares to SoC specific ones?

    Any solution whether Linux does it or some R5F fimrware does, will be board specific. There can be 'n' combinations of power delivery to SOC that can be derived. We support what we can test on the EVM.

    - Keerthy

  • 0 in reply to Keerthy J
    Prodigy 130 points

    Hi Keerthy,

    Keerthy J said:
    Any solution whether Linux does it or some R5F fimrware does, will be board specific.

    Yes of course, with the difference that linux is not firmware and a precompiled binary is taken from ti-linux-firmware when building u-boot for example. Thus, I can change the behavior of linux (and by just modifying the device tree) whereas I cannot change the behavior of the firmware without recomping and putting huge efforts into the build system, because the firmware from ti-linux-firmware is completely useless.

    BR,
    -michael

  • 0 in reply to Michael Walle
    TI__Guru**** 163100 points
    Michael Walle said:
    Yes of course, with the difference that linux is not firmware and a precompiled binary is taken from ti-linux-firmware when building u-boot for example. Thus, I can change the behavior of linux (and by just modifying the device tree) whereas I cannot change the behavior of the firmware without recomping and putting huge efforts into the build system, because the firmware from ti-linux-firmware is completely useless.

    Precisely the same is possible with DM binary. The one pre-built is for EVM but one can always build custom DM binary from the RTOS SDK & replace that in the tispl.bin.

    - Keerthy

  • 0 in reply to Keerthy J
    Prodigy 130 points

    Hi Keerthy,

    Yes that is of course possible, but all your linux development and building infrastructure evolves around the ti-linux-firmware repository with the pre-compiled binaries (which as already mentioned only supports the EVM). Plus, you put the burdon to follow development (and releases!) of the DM binary on the OEMs.

    Thanks,
    -michael

  • 0 in reply to Michael Walle
    TI__Guru**** 163100 points

    Michael,

    This is the poweroff design on all the J7 SoCs. I can take this feedback to our internal teams but this is how we have supported this feature.
    Multiple customers requested this type of design to poweroff finally using MCU R5F. From TI perspective HLOS can be non-Linux as well but DM is a mandatory software run on MCU R5F. Hence the design.

    - Keerthy

  • 0 in reply to Keerthy J
    Prodigy 130 points

    Hi Keerthy,

    yes please take this as feedback. Again, it's not bad that the DM is doing the power-off, but it's bad that it is hardcoded and thus very board specific. TI is really strong in supporting upstream and we've chosen TI because of that. Imagine that the board support is upstreamed to linux (only considering that as HLOS for now) and u-boot. Then all of a sudden we still have to do releases and follow the development of your firmware, just for that tiny detail. So yes, TI should really consider making DM just specifc to a SoC and make everything else configurable.

    As a workaround we'll just skip the power-off of the DM and let linux do the power-off via PMIC (and not via PSCI).

    Thanks,
    -michael

  • 0 in reply to Michael Walle
    TI__Guru**** 163100 points
    Michael Walle said:

    As a workaround we'll just skip the power-off of the DM and let linux do the power-off via PMIC (and not via PSCI).

    Yes. PMIC mfd driver needs to implement the poweroff sequence & then pmic node should be defined as the power controller.
    Thanks for the feedback. I will share the feedback internally.

    - Keerthy