On the motherboard developed by our company (intel atom denverton 3538), there is a low performance of the processor and memory. When trying to monitor the exchange of the SVID bus lines with the oscilloscope (SVID_CLK, SVID_DATA and SVID_ALERT), no activity was noticed. Circuit design is correct (passed Intel review). Could this be the reason for the slow speed of the processor and memory? Do I need to activate this technology in coreboot or FSP? Is there any way to check the operation of the sVID controller from Linux?
Hi,
Slow performance might be due to thermal throttling, Can you please check prochot# signal? It should be high(voltage equal to power rail to which it's pulled up to)
In Linux, you can use powertop program to monitor CPU frequency, CPU C-states. Under some load, CPU will utilise max frequency. Try running some benchmark tool and check max frequency CPU is able to reach.
I'm not sure why you want to access SVID bus now. This is handled by CPU based on its instantaneous operating frequency. That's for Vcc_core voltage control. Higher frequency will need higher voltage on Vcc_Core and vice versa. Also can you measure voltage on this rail in loaded condition.
Also provide coreboot log.
Dhanyawad, Naresh G Solanki
On Fri, 22 Feb, 2019, 8:35 PM , dponamorev@gmail.com wrote:
On the motherboard developed by our company (intel atom denverton 3538), there is a low performance of the processor and memory. When trying to monitor the exchange of the SVID bus lines with the oscilloscope (SVID_CLK, SVID_DATA and SVID_ALERT), no activity was noticed. Circuit design is correct (passed Intel review). Could this be the reason for the slow speed of the processor and memory? Do I need to activate this technology in coreboot or FSP? Is there any way to check the operation of the sVID controller from Linux? _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Intel CPUs typically drive SVID-enabled PMICs using an internal small core (at least Core m and Core i parts). In any case, the peripherals on SVID bus have addresses that sometimes are assigned via bootstrap pins. Your Denverton design probably has a TI and ST Micro PMICs connected to SVID. If the device does not respond on the expected address, the CPU probably won't retry communication. I'm not closely familiar with Atom family, so I don't know what it would do. The Core CPU will raise CATERR signal and die. In any case, I recommend trying to capture what happens on the SVID bus from the very moment of powerup. Expect a low-voltage (~ 1V) 25 MHz I2C-like signal.
If you do capture it and you have a support agreement with Intel, you can ask them for an SVID decoder. You might also try decoding it manually (search web for "vr pwm specification intel"), using the Intel spec.
Finally, if you determine that the peripherals in your system indeed nak the SVID traffic, the actual addresses of these peripherals can be programmed in the BIOS code, however I am not certain if this is something happening inside the FSP and if it can be modified externally.
From: dponamorev@gmail.com dponamorev@gmail.com Sent: Friday, February 22, 2019 7:05 AM To: coreboot@coreboot.org Subject: [coreboot] Intel sVID controller and SVID bus. On the motherboard developed by our company (intel atom denverton 3538), there is a low performance of the processor and memory. When trying to monitor the exchange of the SVID bus lines with the oscilloscope (SVID_CLK, SVID_DATA and SVID_ALERT), no activity was noticed. Circuit design is correct (passed Intel review). Could this be the reason for the slow speed of the processor and memory? Do I need to activate this technology in coreboot or FSP? Is there any way to check the operation of the sVID controller from Linux? _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
The reason for the poor performance was not working SVID bus. Understand exactly what settings affect the enabling/disabling SVID bus failed to find out. The problem was solved by choosing another platform in spsFITs (Aspen Cove instead of Harcuvar). After that, the SVID bus started to work, we saw the clock signals (25 MHz), saw the exchange of data between the processor and the PMICs. Performance came in the expected frame :)
-
Alex Feinman -
dponamorev＠gmail.com -
Naresh G. Solanki