[U-Boot] [PATCH v2 22/22] x86: Add support for Intel Minnowboard Max
Andrew Bradford
andrew at bradfordembedded.com
Wed May 27 16:39:23 CEST 2015
On 05/27 13:19, Bin Meng wrote:
> Hi Simon,
>
> On Wed, May 27, 2015 at 5:37 AM, Simon Glass <sjg at chromium.org> wrote:
> > Hi Andrew,
> >
> > On 26 May 2015 at 13:52, Andrew Bradford <andrew at bradfordembedded.com> wrote:
> >> Hi Simon and Bin (sorry for bringing this back from the dead),
> >>
> >> But I have a question about fsp_configs.c down below:
> >>
> >> On 01/27 22:13, Simon Glass wrote:
> >> ------------->8---------------
> >>> diff --git a/arch/x86/cpu/baytrail/fsp_configs.c b/arch/x86/cpu/baytrail/fsp_configs.c
> >>> new file mode 100644
> >>> index 0000000..86b6926
> >>> --- /dev/null
> >>> +++ b/arch/x86/cpu/baytrail/fsp_configs.c
> >>> @@ -0,0 +1,156 @@
> >>> +/*
> >>> + * Copyright (C) 2013, Intel Corporation
> >>> + * Copyright (C) 2014, Bin Meng <bmeng.cn at gmail.com>
> >>> + *
> >>> + * SPDX-License-Identifier: Intel
> >>> + */
> >>> +
> >>> +#include <common.h>
> >>> +#include <asm/arch/fsp/azalia.h>
> >>> +#include <asm/fsp/fsp_support.h>
> >>> +
> >>> +/* ALC262 Verb Table - 10EC0262 */
> >>> +static const uint32_t verb_table_data13[] = {
> >>> + /* Pin Complex (NID 0x11) */
> >>> + 0x01171cf0,
> >>> + 0x01171d11,
> >>> + 0x01171e11,
> >>> + 0x01171f41,
> >>> + /* Pin Complex (NID 0x12) */
> >>> + 0x01271cf0,
> >>> + 0x01271d11,
> >>> + 0x01271e11,
> >>> + 0x01271f41,
> >>> + /* Pin Complex (NID 0x14) */
> >>> + 0x01471c10,
> >>> + 0x01471d40,
> >>> + 0x01471e01,
> >>> + 0x01471f01,
> >>> + /* Pin Complex (NID 0x15) */
> >>> + 0x01571cf0,
> >>> + 0x01571d11,
> >>> + 0x01571e11,
> >>> + 0x01571f41,
> >>> + /* Pin Complex (NID 0x16) */
> >>> + 0x01671cf0,
> >>> + 0x01671d11,
> >>> + 0x01671e11,
> >>> + 0x01671f41,
> >>> + /* Pin Complex (NID 0x18) */
> >>> + 0x01871c20,
> >>> + 0x01871d98,
> >>> + 0x01871ea1,
> >>> + 0x01871f01,
> >>> + /* Pin Complex (NID 0x19) */
> >>> + 0x01971c21,
> >>> + 0x01971d98,
> >>> + 0x01971ea1,
> >>> + 0x01971f02,
> >>> + /* Pin Complex (NID 0x1A) */
> >>> + 0x01a71c2f,
> >>> + 0x01a71d30,
> >>> + 0x01a71e81,
> >>> + 0x01a71f01,
> >>> + /* Pin Complex */
> >>> + 0x01b71c1f,
> >>> + 0x01b71d40,
> >>> + 0x01b71e21,
> >>> + 0x01b71f02,
> >>> + /* Pin Complex */
> >>> + 0x01c71cf0,
> >>> + 0x01c71d11,
> >>> + 0x01c71e11,
> >>> + 0x01c71f41,
> >>> + /* Pin Complex */
> >>> + 0x01d71c01,
> >>> + 0x01d71dc6,
> >>> + 0x01d71e14,
> >>> + 0x01d71f40,
> >>> + /* Pin Complex */
> >>> + 0x01e71cf0,
> >>> + 0x01e71d11,
> >>> + 0x01e71e11,
> >>> + 0x01e71f41,
> >>> + /* Pin Complex */
> >>> + 0x01f71cf0,
> >>> + 0x01f71d11,
> >>> + 0x01f71e11,
> >>> + 0x01f71f41,
> >>> +};
> >>> +
> >>> +/*
> >>> + * This needs to be in ROM since if we put it in CAR, FSP init loses it when
> >>> + * it drops CAR.
> >>> + *
> >>> + * TODO(sjg at chromium.org): Move to device tree when FSP allows it
> >>> + *
> >>> + * VerbTable: (RealTek ALC262)
> >>> + * Revision ID = 0xFF, support all steps
> >>> + * Codec Verb Table For AZALIA
> >>> + * Codec Address: CAd value (0/1/2)
> >>> + * Codec Vendor: 0x10EC0262
> >>> + */
> >>> +static const struct pch_azalia_verb_table azalia_verb_table[] = {
> >>> + {
> >>> + {
> >>> + 0x10ec0262,
> >>> + 0x0000,
> >>> + 0xff,
> >>> + 0x01,
> >>> + 0x000b,
> >>> + 0x0002,
> >>> + },
> >>> + verb_table_data13
> >>> + }
> >>> +};
> >>> +
> >>> +const struct pch_azalia_config azalia_config = {
> >>> + .pme_enable = 1,
> >>> + .docking_supported = 1,
> >>> + .docking_attached = 0,
> >>> + .hdmi_codec_enable = 1,
> >>> + .azalia_v_ci_enable = 1,
> >>> + .rsvdbits = 0,
> >>> + .azalia_verb_table_num = 1,
> >>> + .azalia_verb_table = azalia_verb_table,
> >>> + .reset_wait_timer_us = 300
> >>> +};
> >>> +
> >>> +void update_fsp_upd(struct upd_region *fsp_upd)
> >>> +{
> >>> + struct memory_down_data *mem;
> >>> +
> >>> + /*
> >>> + * Configure everything here to avoid the poor hard-pressed user
> >>> + * needing to run Intel's binary configuration tool. It may also allow
> >>> + * us to support the 1GB single core variant easily.
> >>> + *
> >>> + * TODO(sjg at chromium.org): Move to device tree
> >>> + */
> >>> + fsp_upd->mrc_init_tseg_size = 8;
> >>> + fsp_upd->mrc_init_mmio_size = 0x800;
> >>> + fsp_upd->emmc_boot_mode = 0xff;
> >>> + fsp_upd->enable_sdio = 1;
> >>> + fsp_upd->enable_sdcard = 1;
> >>> + fsp_upd->enable_hsuart0 = 1;
> >>> + fsp_upd->azalia_config_ptr = (uint32_t)&azalia_config;
> >>> + fsp_upd->enable_i2_c0 = 0;
> >>> + fsp_upd->enable_i2_c2 = 0;
> >>> + fsp_upd->enable_i2_c3 = 0;
> >>> + fsp_upd->enable_i2_c4 = 0;
> >>> + fsp_upd->enable_xhci = 0;
> >>> + fsp_upd->igd_render_standby = 1;
> >>> +
> >>> + mem = &fsp_upd->memory_params;
> >>> + mem->enable_memory_down = 1;
> >>> + mem->dram_speed = 1;
> >>> + mem->dimm_width = 1;
> >>> + mem->dimm_density = 2;
> >>> + mem->dimm_tcl = 0xb;
> >>> + mem->dimm_trpt_rcd = 0xb;
> >>> + mem->dimm_twr = 0xc;
> >>> + mem->dimm_twtr = 6;
> >>> + mem->dimm_trrd = 6;
> >>> + mem->dimm_trtp = 6;
> >>> + mem->dimm_tfaw = 0x14;
> >>> +}
> >>
> >> I am trying to move this fsp upd to use device tree as I am trying to
> >> create a patch set to add the Intel Valley Island E38xx board (which
> >> uses a SODIMM rather than memory down). In doing so, I've found that
> >> global data doesn't seem to be available when update_fsp_upd() is called
> >> and generally it seems that gd->fdt_blob is used to get a reference to
> >> the flattened device tree.
> >>
> >> I'm not super familiar with device tree, but I was attempting to use
> >> fdtdec_next_compatible(gd->fdt_blob, 0, COMPAT_INTEL_BAYTRAIL_FSP) in a
> >> similar way that Quark does in my patchset (I've properly created the
> >> COMPAT_INTEL_BAYTRAIL_FSP define and some device tree nodes in my dts
> >> file). When I call fdtdec_next_compatible() the board does something
> >> which I'm unable to debug (Valley Island does not have the early UART
> >> pins connected so I have no early UART capability) but things just seem
> >> to stop.
> >>
> >> In manually tracing the calls which lead to update_fsp_upd(), it seems
> >> that we haven't yet set up global data, so it makes sense that I can't
> >> reference it. But the device tree should be available in NOR flash or
> >> in some other way which we can access in order to get the FSP UPD
> >> settings.
> >>
> >> Is there a simple way to access the device tree while it's still in NOR
> >> flash so I can avoid using gd? Or can global data be setup prior to
> >> calling update_fsp_upd() (I believe we're still in CAR at this point)?
> >> Or am I misunderstanding something basic here?
> >>
> >> Did you have a rough outline of how this could be moved to device tree?
> >
> > This is a bit tricky. I would like to move fsp_init() later in the
> > init sequence (e.g. to board_init_f()). See this TODO in the code:
> >
> > /*
> > * TODO:
> > *
> > * According to FSP architecture spec, the fsp_init() will not return
> > * to its caller, instead it requires the bootloader to provide a
> > * so-called continuation function to pass into the FSP as a parameter
> > * of fsp_init, and fsp_init() will call that continuation function
> > * directly.
> > *
> > * The call to fsp_init() may need to be moved out of the car_init()
> > * to cpu_init_f() with the help of some inline assembly codes.
> > * Note there is another issue that fsp_init() will setup another stack
> > * using the fsp_init parameter stack_top after DRAM is initialized,
> > * which means any data on the previous stack (on the CAR) gets lost
> > * (ie: U-Boot global_data). FSP is supposed to support such scenario,
> > * however it does not work. This should be revisited in the future.
> > */
> >
> > The primary issues are:
> > 1. The need to recover the global_data
> > 2. The need to change to a new stack
> >
> > Re 1, my reading of the HOB stuff is that it is supposed to provide
> > you with a pointer to the CAR RAM (all ~128KB of it) so that you can
> > go back and find your old stack (and in our case, global_data).
> >
> > Bin mentioned that this doesn't work - his is the comment above after
> > I asked him about it.
> >
> > But if it could be made to work, then we could delay the init.
> >
> > Re 2, U-Boot expects to change to a new stack when it wants to, which
> > is at the boundary of board_init_f() and board_init_r(). The Intel FSP
> > should not mandate a stack change over a C function call. IMO that is
> > just bad design. Dealing with it is not very easy, but one option is
> > to run with the new stack for the rest of the board_init_f() sequence
> > and then change stack again at the end of the sequence. Ick.
> >
> > To specifically address your problem, global_data is not available
> > until board_init_f() is called, and the device tree comes into
> > existence soon after. We could hack around it - e.g. with microcode we
> > find it in the device tree and stick a pointer to it in a special
> > place. But the real solution is to figure out how to move this
> > fsp_init() stuff to later in the sequence. For non-FSP boards we don't
> > have this problem - e.g. ivybridge does RAM init long after we have
> > global_data and device tree. Note it is still running from flash at
> > this point, but CAR is set up and that is where global_data resides.
> >
> > I'm interested to hear what you figure out.
> >
>
> I just noticed that Intel has released FSP specification v1.1 [1] in
> April. After a rough read of the 1.1 spec, it looks to me that Intel
> changed the fsp_init() design by breaking it down into 3 sub-routines:
> FspMemoryInit(), TempRamExit() and FspSiliconInit(). I feel this might
> be more logical to adapt U-Boot, but again I am not sure if the stack
> migration stuff is still there. So far I don't see any new FSP
> releases using the 1.1 spec.
>
> [1] https://www-ssl.intel.com/content/www/us/en/embedded/software/fsp/fsp-architecture-spec-v1-1.html
There's also a very good overview of how to use an FSP v1.1 firmware at
[1]. It states that the problem in v1.0 for bootloaders was that when
you call FspInit() that temporary ram was torn down unconditionally.
Now, in v1.1, it says after calling FspMemoryInit() that control will be
given back to the bootloader running in the temporary ram (CAR?). Then
the bootloader is responsible for migrating to main memory and to call
TempRamExit() so that temporary memory can be cleaned up.
This sounds like what u-boot would want and what Simon described above,
for u-boot to be in charge of relocating from CAR to main memory, right?
If so, likely things will be much easier once there's a v1.1 FSP for
baytrail...
[1]:http://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Creating_the_Intel_Firmware_Support_Package_Version_1_1_with_the_EFI_Developer_Kit_II.pdf
Thanks!
-Andrew
More information about the U-Boot
mailing list