v0.9 is missing GPIO63 to trigger CTRL1 on the PMIC about beaglev-starlight HOT 9 CLOSED

and resetting the pmic (by I2C) should work exactly the same way

I agree that for as long as pmic is guaranteed to have that API (the I2C one) -- we're all good.

Yes, it has a (badly named) register just for this,

from beaglev-starlight.

@esmil is CTRL1 related to IRQB in #14?

from beaglev-starlight.

Not directly. In the v0.9 schematic the pmic has an output pin, GPO3, connected to the reset lines of the SoC, USB usb hub and the ethernet phy. The pmic also has a number of input pins CTL1 - CTL6. As far as I can tell the GPO3 output is set up to go high when the different voltage levels are good and CTL1 is high and CTL5 is high.

Both CTL1 and CTL5 are pulled high by the "LDO_3V3" power line, but the physical reset button is set up to pull CTL5 low when the button is pressed. This then results in the GPO3 output going low and thus resetting the SoC, USB hub and ethernet phy.

Having GPIO63 set up to pull CTL1 low would then reset everything the same way as the physical button just signalling CTL1 instead of CTL5.

However the way I reset the board in my starlight branch is that I just tell the pmic to reset itself over the I2C connection. This way the pmic also pulls GPO3 low while it goes through the startup sequence of turning on the different power rails and signalling "power good" by releasing GPO3 again.

So with this code in place we don't actually need GPIO63 to trigger CTL1 since telling the pmic to reset itself over I2C should pull GPO3 low and reset the SoC, USB hub and ethernet phy in exactly the same way. I'd rather have the IRQB line fixed so we can get interrupts from the pmic as described in #14. Having both won't hurt though.

from beaglev-starlight.

Wait, @esmil -- but it sounds like it almost works "by accident" (not that I'm complaining that it does!) so my question is -- shouldn't the board have an explicit "officially supported" reset functionality?

from beaglev-starlight.

I'm not sure why you think it sounds like it works by accident. I'm sure the board is designed such that the pmic "power good" output is connected to the various reset lines exactly such that they're kept in reset mode until the pmic upstart sequence is done and power levels are stable. I'm sure we can agree that the board resetting properly after being turned on is not "by accident", and resetting the pmic (by I2C) should work exactly the same way.

from beaglev-starlight.

I'm sure we can agree that the board resetting properly after being turned on is not "by accident"

absolutely!

and resetting the pmic (by I2C) should work exactly the same way

I agree that for as long as pmic is guaranteed to have that API (the I2C one) -- we're all good. I'm not just not enough into pmic's to know whether this is something that is expected to be a basic functionality of a pmic. Hence my question.

from beaglev-starlight.

@tekkamanninja @MichaelZhuxx please help update my explanation so that it is clear to @FionaYu20180326 what change we would like to see in the next PCB revision to allow GPIO reset to work

from beaglev-starlight.

@FionaYu20180326 this is the problem the @MichaelZhuxx found which should be fixed:

we found the reason why our board could reset and beta board couldnt is that the schmatic is updated. the beta board is remove the GPIO63 to trigger "CTRL1" on the pmic. Attached two version of schematic for your reference.

@esmil thanks. we will fix it.

BeagleV_v0.81.pdf
BeagleV_v0.9.pdf

from beaglev-starlight.

@esmil
Hi emil,
Here is the sequencing setup of the PMIC. CTL1 is the enable signal of all the power rails. CTL5 just affects the GPO3 of PMIC.

from beaglev-starlight.