OMAP-L138: How to set ARM CPU Frequency on modern SDK?

Hi Juien,

Do you want to use 456MHz from the very beginning of powering on the system or later when booted into Linux? If former, I believe the OPP should still be set in U-Boot/SPL, I would route your query to our UBoot expert to provide comments; if latter, the OPP could be set by cpufreq in Linux. Due to the pandemic, I don't have access to an OMAPL138 EVM right now to check the cpufreq function. But if this is what you need, I will find a time to go to office to get a EVM.

Hi Bin,

Ideally I would like to set everything (pinmuxing + clocks) up from the bootloader, before the DSP and other things are started.

I have already tried modifying the U-Boot DA850 EVM source code, but somehow could not get my configuration running. It also felt quite "hacky", so it would indeed be nice to get some support there:

So far my understanding is that a clean U-Boot configuration should also make use of the devicetree (Driver Model) as well, but I am not sure if the DA850 EVM board part is ready for that?

For instance changing CONFIG_SYS_DA850_PLL0_PLLM / CONFIG_SYS_DA850_PLL1_PLLM in da850evm.h does work, though I would need to set the PMIC voltage Before that with the dm_i2c* functions (CONFIG_DM_I2C set in da850evm_defconfig). But it seems to me that the PLLs are already setup before the DM core is enabled, so I am not too sure how and where to do it properly?

Writing the correct pinmuxing table in da850evm.c should be no problem I believe.

Thanks !
Julien

Hi Julien,

Yes, I think it makes sense to set the OPP in U-Boot. I will route your query to our UBoot expert, but he is out of office this week, so his response might be delayed.

Thanks! Looking forward to it.

Hi Julien,

For OMAP-L138 and DA850 EVM, PLL are set-up in da850_pll_init() called by arch_cpu_init() under "u-boot/arch/arm/mach-davinci/da850_lowlevel.c", where "CONFIG_SYS_DA850_PLL0_PLLDIV1 to CONFIG_SYS_DA850_PLL0_PLLDIV7" and "CONFIG_SYS_DA850_PLL1_PLLDIV1 to CONFIG_SYS_DA850_PLL1_PLLDIV3" are defined in "u-boot/arch/arm/mach-davinci/Kconfig"

A good reference on EVM is "u-boot/board/davinci/da8xxevm/README.da850"

A power-on and power-off sequence is referenced in 6.3 Power Supplies of omap-l138 data sheet
www.ti.com/.../omap-l138

Best,
-Hong

Hi Hong,

Thank you for the feedback. I guess I figured out most of that already, what i am missing is maybe more concrete implementation pointers.

To give more context, I am migrating our software based on the DaVinci-PSP-SDK-03.21.00.04 to the latest Yocto LTS.
Currently the (old) UBL is setting up everything (I²C PMIC voltage increase, clocks, DDR, pinmuxing) before the U-Boot proper relocation.

I would like to achieve something similar with the current SPL (u-boot-ti-staging 2020.01). It is not really clear to me how to best do this though, especially now with the device tree/driver model also present in the SPL. I understand for example that the "u-boot,dm-spl" sections in da850-evm-u-boot.dtsi could be used for that, but I am not sure if this is the way to go?

Regarding da850_lowlevel.c, the PMIC voltage should be set before the da850_pll_init() calls, but I don't see how to do that cleanly within the mainline code: CONFIG_DM_I2C=y is set in da850evm_defconfig (disabling it is breaking other stuff), but the DM core is not yet available at this stage of the init.

Thank you for your help!
Julien

Hi Julien,
I currently don't have OMAP-L138 board to try out, instead I'm using SDK 6.3 for AM335x EVM for your reference.
1. DPLL/PMIC configuration in SPL
Depending on the max speed detected in SPL code via calling am335x_get_efuse_mpu_max_freq(),
- VDD_MPU, VDD_CORE are setup via calling scale_vcores() to configure PMIC
- DPLL_MPU parameters are setup via calling get_dpll_mpu_params()

/arch/arm/mach-omap2/am33xx/clock.c
void prcm_init(void)
{
scale_vcores();		/* Hong: configure PMIC for VDD_MPU, VDD_CORE... */ 
setup_dplls();    	/* Hong: do_setup_dpll() which is a core function for DPLL with M/N... */
}

/board/ti/am335x/board.c
void scale_vcores(void)
{
	...
	freq = am335x_get_efuse_mpu_max_freq(cdev);
	if (board_is_beaglebonex())
		scale_vcores_bone(freq);
	else
		scale_vcores_generic(freq);
}

2. DM/I2C/PMIC in SPL
For AM335x SPL in SDK 6.3, Driver Model (DM) for I2C is based on the traditional platform data instead of device tree
due to limited on-chip SRAM available for adding FDT parsing in SPL.

For AM335x EVM, DM I2C driver is defined below, and used in both SPL and u-boot for accessing EEPROM/PMIC via I2C.

/drivers/i2c/omap24xx_i2c
static const struct udevice_id omap_i2c_ids[] = {
	{ .compatible = "ti,omap3-i2c", .data = OMAP_I2C_REV_V1 },
	{ .compatible = "ti,omap4-i2c", .data = OMAP_I2C_REV_V2 },
	{ }
};

3. Kernel DVFS
There's a e2e post on AM335x PMIC regulator configuration on kernel DVFS
e2e.ti.com/.../983974

Best,
-Hong

Hi Hong,

1. There is no voltage control implemented in /arch/arm/mach-davinci/. Is your advice that I should implement there something similar to the omap2 architecture then?

2. In davinci_i2c.c, there is only CONFIG_DM_I2C, whereas omap24xx_i2c.c has more options (OF_CONTROL, OF_PLATDATA) for the struct udevice_id omap_i2c_ids.
Is there a way to get something working natively for davinci, without having to rewrite too much of the code? Or could you maybe show how to best implement it?

3. This is maybe a slightly different topic, but as written in my first post it seems that cpufreq-davinci isn't working or registered properly:
/sys/devices/system/cpu/cpu0/cpufreq/ is an empty directory on the running system.

Thanks!
Julien

Hi Julien,
1. You may refer to scale_vcores() as in SPL PMIC configuration for AM335x GP EVM depending on your chosen PMIC for OMAP-L138.
2. You can run "dm tree" @u-boot prompt or run "dtc -I dtb u-boot-board_xyz.dtb" to check if I2C Driver Model (DM) is enabled in u-boot device tree.
I2C DM can be added into SPL if I2C DM is in u-boot FDT as listed below:
<u-boot-spl.dtb> is generated from <u-boot.dtb> with specific spl node property like <u-boot,dm-spl>, <u-boot,dm-pre-reloc>...
For example, &i2c0 node is defined in <am437x-gp-evm-u-boot.dtsi> which is, along with <am437x-gp-evm.dts>, implicitly compiled
into <am437x-gp-evm.dtb> file.
&i2c0 {
u-boot,dm-spl;
};
3. I'll pass it to my colleague for further comments on kernel DVFS support on OMAP-L138.
Best,
-Hong

Hi Hong,
2. My question was more how can I make use of the platform data instead of device tree for the DM on the Davinci I2C?
Do I only need the section under #if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA) as in omap24xx_i2c.c, or is there more to implement on davinci to make it work?

I have already tried adding &i2c0 to the SPL in the u-boot.dtsi file, but the target is crashing right-away, so I guess the SRAM is also not sufficient for that on the OMAP-L138.

3. Thanks!
Julien