From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ivan Gorinov Date: Wed, 18 Apr 2018 17:11:46 -0700 Subject: [U-Boot] [PATCH] x86: Use microcode update from device tree for all processors In-Reply-To: References: <20180404230700.GA57192@intel.com> <20180417182956.GA57575@intel.com> Message-ID: <20180419001146.GA18420@intel.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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.