Hi Simon,
On Tue, Dec 16, 2014 at 1:02 PM, Simon Glass <s...@chromium.org> wrote:
> There are several problems in the code. The device tree decode is incorrect
> in ways that are masked due to a matching bug. Both are fixed. Also
> microcode_read_rev() should be inline and called before the microcode is
> written.
>
> Note: microcode writing does not work correctly on ivybridge for me. Further
> work is needed to resolve this. But this patch tidies up the existing code
> so that will be easier.
Yep, I noticed that with the new microcode.dtsi generated from the
microcode tool, the endianness is different from previous ivybridge
one. I think the new one is correct due to dts is using big-endian
while IA processor is little-endian. I just wonder why previous dtsi
could work on ivybridge? And now since we are using little-endian so
we should decode dts using little-endian too. Is this endianness issue
that causes the microcode writing does not work on ivybridge?
> Signed-off-by: Simon Glass <s...@chromium.org>
> ---
>
> Changes in v2:
> - Add new patch to correct problems in the microcode loading
>
> arch/x86/cpu/ivybridge/microcode_intel.c | 25 +++++++++++++++----------
> 1 file changed, 15 insertions(+), 10 deletions(-)
>
> diff --git a/arch/x86/cpu/ivybridge/microcode_intel.c
> b/arch/x86/cpu/ivybridge/microcode_intel.c
> index 79c075f..0817751 100644
> --- a/arch/x86/cpu/ivybridge/microcode_intel.c
> +++ b/arch/x86/cpu/ivybridge/microcode_intel.c
> @@ -50,17 +50,17 @@ static int microcode_decode_node(const void *blob, int
> node,
> update->date_code = fdtdec_get_int(blob, node,
> "intel,date-code", 0);
> update->processor_signature = fdtdec_get_int(blob, node,
> - "intel.processor-signature", 0);
> + "intel,processor-signature", 0);
> update->checksum = fdtdec_get_int(blob, node, "intel,checksum", 0);
> update->loader_revision = fdtdec_get_int(blob, node,
> - "loader-revision", 0);
> + "intel,loader-revision", 0);
> update->processor_flags = fdtdec_get_int(blob, node,
> - "processor-flags", 0);
> + "intel,processor-flags", 0);
>
> return 0;
> }
>
> -static uint32_t microcode_read_rev(void)
> +static inline uint32_t microcode_read_rev(void)
> {
> /*
> * Some Intel CPUs can be very finicky about the CPUID sequence used.
> @@ -116,6 +116,7 @@ int microcode_update_intel(void)
> {
> struct microcode_update cpu, update;
> const void *blob = gd->fdt_blob;
> + int skipped;
> int count;
> int node;
> int ret;
> @@ -123,12 +124,13 @@ int microcode_update_intel(void)
> microcode_read_cpu(&cpu);
> node = 0;
> count = 0;
> + skipped = 0;
> do {
> node = fdtdec_next_compatible(blob, node,
> COMPAT_INTEL_MICROCODE);
> if (node < 0) {
> debug("%s: Found %d updates\n", __func__, count);
> - return count ? 0 : -ENOENT;
> + return count ? 0 : skipped ? -EEXIST : -ENOENT;
> }
>
> ret = microcode_decode_node(blob, node, &update);
> @@ -137,12 +139,15 @@ int microcode_update_intel(void)
> ret);
> return ret;
> }
> - if (update.processor_signature == cpu.processor_signature &&
> - (update.processor_flags & cpu.processor_flags)) {
> - debug("%s: Update already exists\n", __func__);
> - return -EEXIST;
> + if (!(update.processor_signature == cpu.processor_signature &&
> + (update.processor_flags & cpu.processor_flags))) {
> + debug("%s: Skipping non-matching update, sig=%x,
> pf=%x\n",
> + __func__, update.processor_signature,
> + update.processor_flags);
> + skipped++;
> + continue;
> }
> -
> + ret = microcode_read_rev();
> wrmsr(0x79, (ulong)update.data, 0);
> debug("microcode: updated to revision 0x%x
> date=%04x-%02x-%02x\n",
> microcode_read_rev(), update.date_code & 0xffff,
> --
Regards,
Bin
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
