Hi Lucas,
this is an interesting idea and I did poke around a bit.
On Wed, Jan 08, 2025 at 04:46:22PM +0100, Lucas Stach wrote:
> It would be interesting to know if any of the configured PLLs go out of
> lock again during the time your delay loop runs. I.e. check if any of
> CM_IDLEST_DPLL_CORE, CM_IDLEST_DPLL_DDR, CM_IDLEST_DPLL_PER or
> CM_IDLEST_DPLL_MPU contain a value other than 0x1.
I inserted this into the delay loop:
static void __udelay(int us)
{
volatile int i;
for (i = 0; i < us; i++) {
(__raw_readl(CM_IDLEST_DPLL_MPU) != 0x1) ? putc_ll('m') : (void)0;
(__raw_readl(CM_IDLEST_DPLL_CORE) != 0x1) ? putc_ll('c') : (void)0;
(__raw_readl(CM_IDLEST_DPLL_PER) != 0x1) ? putc_ll('p') : (void)0;
(__raw_readl(CM_IDLEST_DPLL_DDR) != 0x1) ? putc_ll('d') : (void)0;
}
}
but none was triggered. Additionaly I tried this instead of the above
before entering the delay loop in beaglebone_sram_init(void):
while(__raw_readl(CM_IDLEST_DPLL_DDR) != 0x0);
//while(__raw_readl(CM_IDLEST_DPLL_CORE) != 0x0);
//while(__raw_readl(CM_IDLEST_DPLL_PER) != 0x0);
//while(__raw_readl(CM_IDLEST_DPLL_MPU) != 0x0);
__udelay(3000);
When I suspect the bit being stable I expect to be being trapped so I
booted with a version without this, replaced it with the trap and
rebooted, I did this 4 times for each DDR, CORE, PER and MPU.
If the bit toggles back to zero I would exit the while, delay and boot
normal. So if trapped == no bit toggle.
Either the putc_ll inserted into the loop did not appear nor the while
trap was left in any case so I suspect this bit is stable at 0x1 for
each type of PLL.
Kind Regards
Konsti
--
INSIDE M2M GmbH
Konstantin Kletschke
Berenbosteler Straße 76 B
30823 Garbsen
Telefon: +49 (0) 5137 90950136
Mobil: +49 (0) 151 15256238
Fax: +49 (0) 5137 9095010
konstantin.kletschke@xxxxxxxxxxxxx
http://www.inside-m2m.de
Geschäftsführung: Michael Emmert, Derek Uhlig
HRB: 111204, AG Hannover
