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