Hi Ivan,
On Thu, Apr 19, 2018 at 8:11 AM, Ivan Gorinov ivan.gorinov@intel.com wrote:
Hi Bin,
On Wed, Apr 18, 2018 at 06:48:59AM -0600, Bin Meng wrote:
I don't understand what the bug is here. The AP microcode update is done in sipi_vector.S.
I have found how it works. When a ROM image is built, the binman tool looks for symbol '_dt_ucode_base_size' and updates position and size of the microcode update data in the ucode_base and ucode_size variables. The ucode_base pointer is used to update the bootstrap CPU very early, and the other CPUs later in the multiprocessing code.
On x86, binman is called from Makefile only if a ROM image is created:
u-boot.rom: u-boot-x86-16bit.bin u-boot.bin \ ... $(call if_changed,binman)If there is no ROM image, ucode_base and ucode_size are not initialized and the microcode update data from DTB applied by microcode_update_intel() to the bootstrap CPU is not used by the multiprocessing code.
Correct. If it's not a ROM image, which means U-Boot is probably not the 1st stage bootloader, which means updating microcode is not necessary. So is there any issue with current implementation?
If the 1st stage bootloader is running from the on-chip SRAM, there may be not enough space to include the microcode update data. In this case, U-Boot is a secondary boot loader but still has to update the microcode.
Thanks for the information. Correct, if that's the case, then we should tune our codes to support that.
But I guess the "1st stage" bootloader is loaded by some on-chip BOOTROM to the internal SRAM?
Is the "1st stage" bootloader running from SRAM the U-Boot SPL? Or some proprietary implementation?
Regards, Bin