We are facing a reset problem on our custom AM1808 board designed using an AM1808 EVM as reference.
We are using UBL code shipped with ti-sdk-am180x-evm-05.02.00.00 SDK which sets ARM and DDR clocks to 456MHz and 150MHz respectively.
Cpuidle and Cpufreq are enabled and we are using the userspace governor.
Here comes the problem: if we set the operating frequency to 96MHz we are unable to reset the board, neither via console reboot command
nor via hardware reset (!).
It seems that the device resets but then remains stuck somewhere in the boot process in ROM or UBL because nothing is displayed
on the console.
If we substitute the UBL with an old version (dumped from the EVM spi flash) which sets the initial ARM clock to 300MHz there is no problem resetting
the board even at 96MHz.
We think this is what happens:
- On first boot the PMIC starts with a default core voltage of 1.2V with is enough for the core to bootstrap at 456MHz
- UBL boots U-UBOOT which boots the kernel, everything ok.
- Then we set the operating frequency to 96MHz (echo 96000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed) and the governor
then instructs the PMIC to lower the core voltage to 1.0V
- We issue a reset (via reboot command or hardware button reset)
- The ARM resets BUT the PMIC is still suppling 1.0V to the core
- Part of the UBL code wich sets the ARM clock to 456MHz is executed ...but the ARM core is unable to start operation at 456MHz with that voltage and the boot got stuck somewhere (Maybe PLL is not able to get a lock?)
The following points seems to back the above explanation of the problem:
- When we use an UBL code which sets the initial clock at 300Mhz the board is able to reset without problems even at 96MHz
We guess that at 300MHz 1.0 volts are sufficient for the ARM to bootstrap.
- We patched the 96MHz opp in da850.c to fix the PMIC voltage to 1.2 volt:
static const struct da850_opp da850_opp_96 = {
.freq = 96000,
.prediv = 1,
.mult = 20,
.postdiv = 5,
//.cvdd_min = 1000000,
//.cvdd_max = 1050000,
.cvdd_min = 1200000, // <------
.cvdd_max = 1200000, // <------
};
and as expected with this 'fix' we were are able to reset.
Questions:
1. Can you confirm that this is an expected behavior and that the correct solution is to
rebuild UBL with a different operating point with a lower ARM clock ?
2. Regarding question 1, we tried to change the UBL operating point as described here:
http://processors.wiki.ti.com/index.php/OMAPL1:_Changing_the_Operating_Point
but in our 'include/device.h' file there are no #define DEVICE_OPP_* macros as stated in the wiki page.
So instead we patched the function 'DEVICE_init()' in the file 'ti-sdk-am180x-evm-05.02.00.00/host-tools/flash_utils/OMAP-L138_FlashAndBootUtils_2_31/OMAP-L138/Common/src/device.c' this way:
Uint32 DEVICE_init()
{
....
....
....
// System PLL Setup
if (status == E_PASS)
{
#if defined(AM1808)
// CPU(s) at 456 MHz
// status |= DEVICE_PLL0Init(0, 18, 0, 0, 0, 18, 8);
status |= DEVICE_PLL0Init(0, 24, 0, 1, 0, 11, 5); // <-------- patch to force 300 MHz
#elif defined(AM1810)
// CPU(s) at 300 MHz
status |= DEVICE_PLL0Init(0, 24, 0, 1, 0, 11, 5);
#else
// CPU(s) at 300 MHz
status |= DEVICE_PLL0Init(0, 24, 0, 1, 0, 11, 5);
#endif
}
....
....
And again this solves the issue, but is this a correct approach?
Waiting for your response, thanks in advance. Gabriele.
