Group Actions
Engagement
  • Author Author: bhfletcher
  • Date Created: Date Created
  • Views 3335 views
  • Likes 9 likes
  • Comments 6 comments
Related
Recommended

Zynq UltraScale+ PMU and the Ultra96-V2 On/Off Controller

bhfletcher

The Xilinx Zynq UltraScale+ MPSoC device has an integrated Platform Management Unit or PMU. This PMU's functionality is described in Chapter 6 of Xilinx UG1085, Zynq UltraScale+ Device Technical Reference Manual. The PMU controls many things on the ZU+ device, including powering up and down the ZU+. The Ultra96-V2 incorporates an On/Off controller to interface between the on-board power regulators and the ZU+. This allows the ZU+, Power Button, and regulators to seamlessly work together to power the system on and off without corrupting your Linux (or other OS) file system.

 

The key inputs/outputs of the system are detailed below:

Signal NameSourceDestinationPolarityDescription
PWR_PB_NPush Button (SW4)On/Off Controller (U6)Low-enabledPush button input for powering on and off. Responds to both short and long pushes. When the system is powered off, a short or long push initiates a power-on sequence. When the system is powered on, a short push will trigger an interrupt, telling the Xilinx PMU to perform a shutdown. A long push (~10 seconds held down) will also issue an interrupt but will power off the system regardless of whether the PMU issues KILL_N or not.
MIO34_POWER_KILL_NZU+ (U1)On/Off Controller (U6)Low-enabledDisable the power regulators immediately. The ZU+ PMU enables this when it has properly processed an internal shutdown command successfully and is ready for the on/off controller to turn off the regulators.
EN_SEQ_PLOn/Off Controller (U6)Pmics (U11, U12, U21)High-enabledEnables the three primary Infineon power regulation devices. Asserted by the On/Off Controller during a power-up sequence, and de-asserted by the On/Off Controller during a power-down sequence (either a response to KILL_N or a long push).
MIO26_PWR_INTOn/Off Controller (U6)ZU+ (U1)High-enabledInterrupt input to the ZU+ when a power-down push button event has been received.
INITStrapping resistor (JT6)On/Off Controller (U6)Default = LowWhen low, the On/Off Controller powers up with the push button control. When high, the On/Off Controller powers up the system as soon as the input voltage is valid.

 

The Ultra96-V1 used an off-the-shelf On/Off Controller, but it had a couple deficiencies:

  • No capability to turn on immediately when Power is applied. An option to be able to do this is a requirement of the 96Boards Spec. To do this on Ultra96-V1 required soldering multiple components and bypassing the On/Off Controller.
  • Interrupt polarity was low while the Xilinx PMU requires high

 

Since we couldn't find exactly what we needed, we decided to work with Dialog Semiconductor to design our own. We used the Dialog GreenPAK line of mixed-signal programmable devices to accomplish this. This device accomplishes everything that we needed in a very small 2mm x 2.2mm STQFN package at a cost that is less than $1 USD. We were previously paying ~$3 for the On/Off Controller chip on the Ultra96-V1. Specifically, our design is based on the Dialog GreenPAK SLG46170 device, with the programmed part number being SLG4G42480V. If you want to duplicate the exact functionality of the On/Off Controller on the Ultra96-V2, the SLG4G42480V may be ordered from Avnet. If you are working on a project with Avnet as your distributor, work with your Avnet FAE to request samples of the device to avoid the 3K MOQ, or you can get Avnet's code for the On/Off Controller to customize it for yourself by submitting a request at http://Avnet.me/AvnetProgrammingFiles.

 

For those that want to modify the power-up initialization from push-button control to power-up with power connected, you will need to move a single resistor on the Ultra96-V2. This is the 3-pad, 10-Kohm resistor JT6, which selects either pull-down (default, use Push Button) or pull-up (power up with power). To implement the Power Up with Power Connected function, move the JT6 from position 1-2 to position 2-3. JT6 is located on the backside of the Ultra96-V2, so you will first need to remove the heatsink. JT6 is then located in the upper right of the southwest quadrant, near U6 as highlighted in the photo below.

image

 

To help explain the functionality of this device, a datasheet is available at Dialog SLG4G42480 On-Off Controller Datasheet . Also, here are several functional diagrams showing the logic within this device.

 

image

image

image

image

 

image

image

image

image

In summary, the Xilinx Zynq UltraScale+ MPSoC's PMU offers many great system advantages. Having an inexpensive, small, customized On/Off Controller on the Ultra96-V2 is a great way to take advantage of some of these features.

  • in reply to narrucmot

    POS - Power Off Suspend.  In the code there is '#ifdef ENABLE_POS'  in a few places but this is not enabled for the ultra96.   However, it pm_hooks it specifically connects MIO26 to the PMU. 

     

    I think you are correct that maybe it was just assumed it would be connected a certain way.  There are a few places where the codes looks at specific pins/wake events.   I tried prototyping using different pins.  I can get the kill normally on 34 on a different pin but I can't seem to catch a "button press" if I try pin 31(by pulling R7 low).  I'm was wondering if there was anything special about the pins in the code but as you said they appear interchangeable.

     

    Maybe there is something wrong with they way the interrupts work and that's why you guys had to do the polling code.  I sure looks like it should be working but then I would think there would be some kind of conflict between the button handler code and the wake event handler. 

     

    Thanks for the help,

    jeff

  • in reply to jrhtech

    It *may* be possible for the PMU <-> PS to use an interrupt handler.  Chapters 6 and 13 of the Zynq MPSoC TRM (https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf) seem to indicate this is possible.  I can't really comment on why polling code was used instead.  Xilinx creates the PMU firmware for the Zynq MPSoC, and further adapts it for the Ultra96 (variants for the -V1 and -V2 boards for the different on/off controller schemes used on each board) (https://github.com/Xilinx/embeddedsw/tree/master/lib/sw_apps/zynqmp_pmufw/src). 

     

    What is POS code?

     

    The PMU GPI1[0:5] inputs are mapped to MIO[26:31] (see chapter 6 of the Zynq MPSoC TRM).  I don't know what source files you are referring to, so I don't know why MIO26 would be hard coded in the software.  I would assume (cautiously, of course) that MIO26 is hard coded because it is the first PMU GPI1 input and it is assumed that a designer would naturally connect a needed PMU GPI1 input there.  If one were to design their own board there is probably no logical reason why the other PMU GPI1 inputs couldn't be used instead (and the PMU firmware patched accordingly).

     

    --Tom

  • in reply to narrucmot

    Hi Tom,

     

      Thanks. I took a closer look at the code and the linux driver and can see how IPI is used to send the message up and then then back down to the PMU which then handles the files assert on MIO 34. I see that the ultra96 is polling on the wake state of GPI0.   Shouldn't it be possible to use an interrupt handler instead?  Actually, it looks like there is a handler register for wake events that eventually calls  PmShutdownInterruptHandler(), that looks very similar to the button polling code.  Why was the polling code needed? 

      Also, I notice most of the POS code is hardcoded for MIO26; however, if POS is not enabled is there any reason a different GPI could not be used instead of GPI0/MIO26 ?

     

    thanks,

    jeff

  • in reply to jrhtech

    Hi Jeff,

     

    In the ZU+ PS configuration for the Ultra96-V2 MIO26_PWR_INT is mapped to the PMU input GPI[0].  A short press of the PB switch SW4 will be followed by the on/off controller asserting MIO26.  The PMU firmware monitors the status of MIO26 and handles communication with Linux.  Linux will process the power down request from the PMU firmware and when complete the PMU will assert MIO34_KILL_N.  The PMU firmware is bare-metal and thus should be deterministic, but the communication between the PMU firmware and Linux, and how long it takes Linux to process the request and shutdown, is not.

     

    The MIO34_KILL_N signal is asserted following:

    • A short press of the SW4 PB switch if Linux is running.
    • The user issuing the Linux 'shutdown' command. 

     

    Once MIO34 is asserted, or after a long press (~12 seconds) of SW4 if Linux is not running, the on/off controller will assert EN_SEQ_PL and the PMICs will be disabled.

     

    This screenshot describes the inputs and outputs to the ZynqMP PMU:

    image

    --Tom

  • Two questions.  1) What determines the time difference between when the Ultra96PowerButtonHandler runs and the kill on MIO34 is asserted?  Or is MIO34 asserted because of the actions in ButtonHandler?  2) How does this initiate a clean shutdown on Linux?  Are the IPI somehow telling linux to shutdown?

     

    thanks,

    jeff