The design does not support that function as designed. We have done designs that auto power on, but the X15 is not designed that way and there are no plans to change the design
The design does not support that function as designed. We have done designs
that auto power on, but the X15 is not designed that way and there are no
plans to change the design
What I did was solder a jumper to the holes for J5. That's near
the PMIC. When J5 is shorted, PMIC_POWERHOLD on and automatically
powers up the board.
Not sure if there are some other side effects with this. But at
least it makes the board usable for basic boot testing in a rack.
That is doable.And yes there are side affects. If you don’t run SW, that fixes a contention issue in the processor and let it sit, you will void the warranty and damage the processor after about 120 hours of operation…
I believe mainline u-boot has the disable now, so as long as you guys
don't debug u-boot (and halt mid u-boot) on that board and always just
try to boot the kernel, it'll be fine.
just splitting hair here: SPL should put in required workaround. but
holding powerhold impacts other functions in the system as well. long
press power off wont work anymore, and few other internal pmic timer
issues might pop up -> we've not looked more since it was'nt how "it
is supposed to be used" ;)...
> >> That is doable.And yes there are side affects. If you don't run SW, that
> >> fixes a contention issue in the processor and let it sit, you will void
> the
> >> warranty and damage the processor after about 120 hours of operation..
> >
> > I believe mainline u-boot has the disable now, so as long as you guys
> > don't debug u-boot (and halt mid u-boot) on that board and always just
> > try to boot the kernel, it'll be fine.
> >
>
> just splitting hair here: SPL should put in required workaround. but
> holding powerhold impacts other functions in the system as well. long
> press power off wont work anymore, and few other internal pmic timer
> issues might pop up -> we've not looked more since it was'nt how "it
> is supposed to be used" ;)...
Yeah OK. Well at least it can be used for basic boot testing that
way.
Hi, I have the same request. Is it now OK to short across J5 to solve this?
Otherwise, I was thinking of using the LONG PRESS KEY behavior of the device.
Basically, solder across the PWRON button, and modify uboot to write to the PMIC to prevent the shutdown.
LONG_PRESS_KEY.LPK_INT_CLR = 0
and then read to clear the interrupt.
Thank you
Thank you so much for your response. Will you be able to tell me what the issue is that uboot solves? What contention is caused inside the part when we short across this jumper?
‘state’ = ‘feature’… You can bug TI about it, it’ll require an NDA… Just make sure the SOC initializes with something u-boot/barebox/etc and it’ll be fine…