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 and...@bradfordembedded.com 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 bmeng...@gmail.com wrote: Hi Andrew, Simon, On Fri, May 29, 2015 at 2:09 AM, Andrew Bradford and...@bradfordembedded.com wrote: On 05/28 10:30, Simon Glass wrote: Hi Andrew, On 27 May 2015 at 08:39, Andrew Bradford and...@bradfordembedded.com wrote: On 05/27 13:19, Bin Meng wrote: Hi Simon, On Wed, May 27, 2015 at 5:37 AM, Simon Glass s...@chromium.org wrote: Hi Andrew, On 26 May 2015 at 13:52, Andrew Bradford and...@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--- [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 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
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 and...@bradfordembedded.com wrote: On 05/28 10:30, Simon Glass wrote: Hi Andrew, On 27 May 2015 at 08:39, Andrew Bradford and...@bradfordembedded.com wrote: On 05/27 13:19, Bin Meng wrote: Hi Simon, On Wed, May 27, 2015 at 5:37 AM, Simon Glass s...@chromium.org wrote: Hi Andrew, On 26 May 2015 at 13:52, Andrew Bradford and...@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--- [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 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
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 and...@bradfordembedded.com wrote:
On 05/27 13:19, Bin Meng wrote:
Hi Simon,
On Wed, May 27, 2015 at 5:37 AM, Simon Glass s...@chromium.org wrote:
Hi Andrew,
On 26 May 2015 at 13:52, Andrew Bradford and...@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 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 bmeng...@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(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;
+
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 bmeng...@gmail.com wrote:
Hi Simon,
On Wed, May 27, 2015 at 5:37 AM, Simon Glass s...@chromium.org wrote:
Hi Andrew,
On 26 May 2015 at 13:52, Andrew Bradford and...@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---
[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_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
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 and...@bradfordembedded.com wrote:
Hi Simon Bin,
On 05/26 15:37, Simon Glass wrote:
Hi Andrew,
On 26 May 2015 at 13:52, Andrew Bradford and...@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---
+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 seen before.
Well if you can get access to the old global_data here then you can
memcpy it to a new place in DRAM. That helps. But I
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 and...@bradfordembedded.com wrote:
On 05/27 13:19, Bin Meng wrote:
Hi Simon,
On Wed, May 27, 2015 at 5:37 AM, Simon Glass s...@chromium.org wrote:
Hi Andrew,
On 26 May 2015 at 13:52, Andrew Bradford and...@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 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 bmeng...@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(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
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 s...@chromium.org wrote:
Hi Andrew,
On 26 May 2015 at 13:52, Andrew Bradford and...@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 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 bmeng...@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(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).
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 and...@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---
+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 seen before.
Any pointers on why it was determined that the CAR RAM pointer doesn't
work correctly so I can avoid spending too much time investigating
things which have already been done?
But if it could be made to work,
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 s...@chromium.org wrote:
Hi Andrew,
On 26 May 2015 at 13:52, Andrew Bradford and...@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 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 bmeng...@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(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
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 bmeng...@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(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_next_compatible(gd-fdt_blob, 0, COMPAT_INTEL_BAYTRAIL_FSP) in a
similar way that Quark does in my patchset (I've properly
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 and...@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 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 bmeng...@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(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
Re: [U-Boot] [PATCH v2 22/22] x86: Add support for Intel Minnowboard Max
On 27 January 2015 at 22:13, Bin Meng bmeng...@gmail.com wrote: On Wed, Jan 28, 2015 at 1:13 PM, Simon Glass s...@chromium.org 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 s...@chromium.org --- 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 bmeng...@gmail.com (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 s...@chromium.org 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 s...@chromium.org --- 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 bmeng...@gmail.com [snip] Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
