Hi Ivan, On Thu, Apr 19, 2018 at 8:11 AM, Ivan Gorinov <ivan.gori...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot