[U-Boot] [PATCH] x86: Use microcode update from device tree for all processors

[Bin Meng]

Hi Ivan,

On Thu, Apr 19, 2018 at 8:11 AM, Ivan Gorinov <ivan.gorinov at 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