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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
