Hi Simon, On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass <s...@chromium.org> wrote: > Intel has invented yet another binary blob which firmware is required to > run. This is run after SDRAM is ready. It is linked to load at a particular > address, typically 0, but is a relocatable ELF so can be moved if required. >
This is really bad! > Add support for this in the build system. The file should be placed in the > board directory, and called refcode.elf. Is there any public documentation that explains this binary blob? Is this blob supposed to hide any top-secret of their chipset?! Why not just a single FSP binary? I fail to understand Intel's firmware strategy given they seem to actively promote FSP. > > Signed-off-by: Simon Glass <s...@chromium.org> > --- > > Makefile | 14 +++++++++++++- > arch/x86/Kconfig | 11 +++++++++++ > arch/x86/include/asm/cpu.h | 12 ++++++++++++ > 3 files changed, 36 insertions(+), 1 deletion(-) > > diff --git a/Makefile b/Makefile > index 6bb5565..76dab6f 100644 > --- a/Makefile > +++ b/Makefile > @@ -1044,6 +1044,10 @@ ifneq ($(CONFIG_HAVE_VGA_BIOS),) > IFDTOOL_FLAGS += -w > $(CONFIG_VGA_BIOS_ADDR):$(srctree)/board/$(BOARDDIR)/$(CONFIG_VGA_BIOS_FILE) > endif > > +ifneq ($(CONFIG_HAVE_REFCODE),) > +IFDTOOL_FLAGS += -w $(CONFIG_X86_REFCODE_ADDR):refcode.bin > +endif > + > quiet_cmd_ifdtool = IFDTOOL $@ > cmd_ifdtool = $(IFDTOOL) -c -r $(CONFIG_ROM_SIZE) u-boot.tmp; > ifneq ($(CONFIG_HAVE_INTEL_ME),) > @@ -1052,7 +1056,15 @@ endif > cmd_ifdtool += $(IFDTOOL) $(IFDTOOL_FLAGS) u-boot.tmp; > cmd_ifdtool += mv u-boot.tmp $@ > > -u-boot.rom: u-boot-x86-16bit.bin u-boot.bin FORCE > +refcode.bin: $(srctree)/board/$(BOARDDIR)/refcode.bin FORCE > + $(call if_changed,copy) > + > +quiet_cmd_ldr = LD $@ > +cmd_ldr = $(LD) $(LDFLAGS_$(@F)) \ > + $(filter-out FORCE,$^) -o $@ > + > +u-boot.rom: u-boot-x86-16bit.bin u-boot.bin FORCE \ > + $(if $(CONFIG_HAVE_REFCODE),refcode.bin) > $(call if_changed,ifdtool) > > OBJCOPYFLAGS_u-boot-x86-16bit.bin := -O binary -j .start16 -j .resetvec > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index 29df78c..2544c65 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -305,6 +305,17 @@ config DCACHE_RAM_MRC_VAR_SIZE > memory reference code and must be set correctly or the board will > not boot. > > +config HAVE_REFCODE > + bool "Add a Reference Code binary" > + help > + Select this option to add a Reference Code binary to the resulting > + U-Boot image. This is an Intel binary blob that handles system > + initialisation, in this case the PCH and System Agent. > + > + Note: Without this binary (on platforms that need it such as > + broadwell) U-Boot will be missing some critical setup steps. > + Various peripherals may fail to work. > + > config SMP > bool "Enable Symmetric Multiprocessing" > default n > diff --git a/arch/x86/include/asm/cpu.h b/arch/x86/include/asm/cpu.h > index 85386da..23ec764 100644 > --- a/arch/x86/include/asm/cpu.h > +++ b/arch/x86/include/asm/cpu.h > @@ -275,4 +275,16 @@ u32 cpu_get_family_model(void); > */ > u32 cpu_get_stepping(void); > > +/** > + * cpu_run_reference_code() - Run the platform reference code > + * > + * Some platforms require a binary blob to be executed once SDRAM is > + * available. This is used to set up various platform features, such as the > + * platform controller hub (PCB). This function should be implemented by the typo: PCH > + * CPU-specific code. > + * > + * @return 0 on success, -ve on failure > + */ > +int cpu_run_reference_code(void); > + > #endif > -- Regards, Bin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot