Re: [U-Boot] [PATCH v2 22/22] x86: Add support for Intel Minnowboard Max
Hi Simon, On 05/28 10:30, Simon Glass wrote: > Hi Andrew, > > On 27 May 2015 at 08:39, Andrew Bradford wrote: > > On 05/27 13:19, Bin Meng wrote: > >> Hi Simon, ->8-- > >> 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... > > > > Indeed, care to ping them to find out when this might happen? It seems like there are no current plans to implement an FSP v1.1 compliant firmware release for Bay Trail [1], which is unfortunate. [1]:https://embedded.communities.intel.com/thread/8218 I will continue to pester my contacts at Intel. Thanks, Andrew ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 22/22] x86: Add support for Intel Minnowboard Max
Hi Simon, Hi Andrew, On Fri, May 29, 2015 at 9:54 PM, Bin Meng wrote: > Hi Andrew, Simon, > > On Fri, May 29, 2015 at 2:09 AM, Andrew Bradford > wrote: >> On 05/28 10:30, Simon Glass wrote: >>> Hi Andrew, >>> >>> On 27 May 2015 at 08:39, Andrew Bradford >>> wrote: >>> > On 05/27 13:19, Bin Meng wrote: >>> >> Hi Simon, >>> >> >>> >> On Wed, May 27, 2015 at 5:37 AM, Simon Glass wrote: >>> >> > Hi Andrew, >>> >> > >>> >> > On 26 May 2015 at 13:52, Andrew Bradford >>> >> > 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--- > > [snip] > >>> >> >> >>> >> >> 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
Re: [U-Boot] [PATCH v2 22/22] x86: Add support for Intel Minnowboard Max
Hi Andrew, Simon, On Fri, May 29, 2015 at 2:09 AM, Andrew Bradford wrote: > On 05/28 10:30, Simon Glass wrote: >> Hi Andrew, >> >> On 27 May 2015 at 08:39, Andrew Bradford wrote: >> > On 05/27 13:19, Bin Meng wrote: >> >> Hi Simon, >> >> >> >> On Wed, May 27, 2015 at 5:37 AM, Simon Glass wrote: >> >> > Hi Andrew, >> >> > >> >> > On 26 May 2015 at 13:52, Andrew Bradford >> >> > 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--- [snip] >> >> >> >> >> >> 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 proble
Re: [U-Boot] [PATCH v2 22/22] x86: Add support for Intel Minnowboard Max
On 05/28 10:30, Simon Glass wrote:
> Hi Andrew,
>
> On 27 May 2015 at 08:39, Andrew Bradford wrote:
> > On 05/27 13:19, Bin Meng wrote:
> >> Hi Simon,
> >>
> >> On Wed, May 27, 2015 at 5:37 AM, Simon Glass wrote:
> >> > Hi Andrew,
> >> >
> >> > On 26 May 2015 at 13:52, Andrew Bradford
> >> > 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 000..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
> >> >>> + *
> >> >>> + * SPDX-License-Identifier: Intel
> >> >>> + */
> >> >>> +
> >> >>> +#include
> >> >>> +#include
> >> >>> +#include
> >> >>> +
> >> >>> +/* 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(s...@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,
> >> >>> + 0x,
> >> >>> + 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(s...@chromium.org): Move to device tree
> >> >>> + */
> >> >>> + fsp_upd->mrc
Re: [U-Boot] [PATCH v2 22/22] x86: Add support for Intel Minnowboard Max
Hi Andrew,
On 27 May 2015 at 08:39, Andrew Bradford wrote:
> On 05/27 13:19, Bin Meng wrote:
>> Hi Simon,
>>
>> On Wed, May 27, 2015 at 5:37 AM, Simon Glass wrote:
>> > Hi Andrew,
>> >
>> > On 26 May 2015 at 13:52, Andrew Bradford
>> > 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 000..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
>> >>> + *
>> >>> + * SPDX-License-Identifier: Intel
>> >>> + */
>> >>> +
>> >>> +#include
>> >>> +#include
>> >>> +#include
>> >>> +
>> >>> +/* 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(s...@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,
>> >>> + 0x,
>> >>> + 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(s...@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;
>
Re: [U-Boot] [PATCH v2 22/22] x86: Add support for Intel Minnowboard Max
Hi Andrew,
On 27 May 2015 at 08:22, Andrew Bradford wrote:
> Hi Simon & Bin,
>
> On 05/26 15:37, Simon Glass wrote:
>> Hi Andrew,
>>
>> On 26 May 2015 at 13:52, Andrew Bradford 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---
>> >> +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(s...@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.
>
> OK, if it doesn't work then that's frustrating.
>
> I do see that HOB 15 on my Valley Island boa
Re: [U-Boot] [PATCH v2 22/22] x86: Add support for Intel Minnowboard Max
Hi Bin,
On 26 May 2015 at 23:19, Bin Meng wrote:
>
> Hi Simon,
>
> On Wed, May 27, 2015 at 5:37 AM, Simon Glass wrote:
> > Hi Andrew,
> >
> > On 26 May 2015 at 13:52, Andrew Bradford
> > 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---
[snip]
> >>> +
> >>> +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(s...@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_da
Re: [U-Boot] [PATCH v2 22/22] x86: Add support for Intel Minnowboard Max
On 05/27 13:19, Bin Meng wrote:
> Hi Simon,
>
> On Wed, May 27, 2015 at 5:37 AM, Simon Glass wrote:
> > Hi Andrew,
> >
> > On 26 May 2015 at 13:52, Andrew Bradford
> > 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 000..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
> >>> + *
> >>> + * SPDX-License-Identifier: Intel
> >>> + */
> >>> +
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +
> >>> +/* 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(s...@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,
> >>> + 0x,
> >>> + 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(s...@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;
> >>> +
> >>> + me
Re: [U-Boot] [PATCH v2 22/22] x86: Add support for Intel Minnowboard Max
Hi Simon & Bin,
On 05/26 15:37, Simon Glass wrote:
> Hi Andrew,
>
> On 26 May 2015 at 13:52, Andrew Bradford 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---
> >> +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(s...@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.
OK, if it doesn't work then that's frustrating.
I do see that HOB 15 on my Valley Island board has the right GUID to be
the FSP_BOOTLOADER_TEMPORARY_MEMORY_HOB and its size is 16408. So that
has me hopeful, but likely I'll run into similar things that you two
have s
Re: [U-Boot] [PATCH v2 22/22] x86: Add support for Intel Minnowboard Max
Hi Simon,
On Wed, May 27, 2015 at 5:37 AM, Simon Glass wrote:
> Hi Andrew,
>
> On 26 May 2015 at 13:52, Andrew Bradford 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 000..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
>>> + *
>>> + * SPDX-License-Identifier: Intel
>>> + */
>>> +
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +/* 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(s...@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,
>>> + 0x,
>>> + 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(s...@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_t
Re: [U-Boot] [PATCH v2 22/22] x86: Add support for Intel Minnowboard Max
Hi Andrew,
On 26 May 2015 at 13:52, Andrew Bradford 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 000..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
>> + *
>> + * SPDX-License-Identifier: Intel
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +
>> +/* 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(s...@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,
>> + 0x,
>> + 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(s...@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
> globa
Re: [U-Boot] [PATCH v2 22/22] x86: Add support for Intel Minnowboard Max
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 000..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
> + *
> + * SPDX-License-Identifier: Intel
> + */
> +
> +#include
> +#include
> +#include
> +
> +/* 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(s...@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,
> + 0x,
> + 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(s...@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_
Re: [U-Boot] [PATCH v2 22/22] x86: Add support for Intel Minnowboard Max
On 27 January 2015 at 22:13, Bin Meng wrote: > On Wed, Jan 28, 2015 at 1:13 PM, Simon Glass wrote: >> This is a relatively low-cost x86 board in a small form factor. The main >> peripherals are uSD, USB, HDMI, Ethernet and SATA. It uses an Atom 3800 >> series CPU. So far only the dual core 2GB variant is supported. >> >> This uses the existing FSP support. Binary blobs are required to make this >> board work. The microcode update is included as a patch (all 3000 lines of >> it). >> >> Signed-off-by: Simon Glass >> --- >> >> Changes in v2: >> - Move CONFIG_SYS_CACHELINE_SIZE to the board CONFIG file >> - Add comment about FSP setting PCIE_ECAM_BASE >> - Put baytrail Kconfig in alphabetical order >> - Remove superfluous check for CONFIG_DEBUG_UART in setup_early_uart() >> - Fix compatible string for SPI flash >> - Remove commented-out DEBUG_UART_CLOCK baud rate >> - Rename 'Coreboot' to 'coreboot' in README.x86 >> > > Reviewed-by: Bin Meng (Rebased on top of upstream/master, so no longer has debug_uart and this code was dropped for now) Applied to u-boot-x86. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 22/22] x86: Add support for Intel Minnowboard Max
On Wed, Jan 28, 2015 at 1:13 PM, Simon Glass wrote: > This is a relatively low-cost x86 board in a small form factor. The main > peripherals are uSD, USB, HDMI, Ethernet and SATA. It uses an Atom 3800 > series CPU. So far only the dual core 2GB variant is supported. > > This uses the existing FSP support. Binary blobs are required to make this > board work. The microcode update is included as a patch (all 3000 lines of > it). > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Move CONFIG_SYS_CACHELINE_SIZE to the board CONFIG file > - Add comment about FSP setting PCIE_ECAM_BASE > - Put baytrail Kconfig in alphabetical order > - Remove superfluous check for CONFIG_DEBUG_UART in setup_early_uart() > - Fix compatible string for SPI flash > - Remove commented-out DEBUG_UART_CLOCK baud rate > - Rename 'Coreboot' to 'coreboot' in README.x86 > Reviewed-by: Bin Meng [snip] Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
