[PATCH] configs: clearfog: enable SPL_DM_GPIO to fix boot from SD

[Baruch Siach]

SPL needs DM GPIO to read the SD card-detect signal. This complements
the fix in commit 70bae02f71d4 ("arm: mvebu: clearfog: fix boot from SD
card").

Signed-off-by: Baruch Siach 
---
 configs/clearfog_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig
index 787c6360a7da..10c39e34fb6e 100644
--- a/configs/clearfog_defconfig
+++ b/configs/clearfog_defconfig
@@ -27,6 +27,7 @@ CONFIG_SYS_CONSOLE_INFO_QUIET=y
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x141
+CONFIG_SPL_DM_GPIO=y
 CONFIG_SPL_I2C_SUPPORT=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_GPIO=y
-- 
2.24.0

Re: [PATCH v6 079/102] x86: Add low-power subsystem (lpss) support

[Bin Meng]

On Sun, Dec 8, 2019 at 11:59 AM Bin Meng  wrote:
>
> On Sat, Dec 7, 2019 at 12:52 PM Simon Glass  wrote:
> >
> > This subsystem is present on various Intel SoCs.
> >
> > Add very basic support for taking an lpss device out of reset.
> >
> > Signed-off-by: Simon Glass 
> >
> > ---
> >
> > Changes in v6: None
> > Changes in v5: None
> > Changes in v4:
> > - Add support for updating power state
> > - Move this to intel_common
> >
> > Changes in v3: None
> > Changes in v2: None
> >
> >  arch/x86/cpu/intel_common/Makefile |  1 +
> >  arch/x86/cpu/intel_common/lpss.c   | 44 ++
> >  arch/x86/include/asm/lpss.h| 36 
> >  3 files changed, 81 insertions(+)
> >  create mode 100644 arch/x86/cpu/intel_common/lpss.c
> >  create mode 100644 arch/x86/include/asm/lpss.h
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 078/102] x86: Enable pinctrl in SPL and TPL

[Bin Meng]

On Sun, Dec 8, 2019 at 11:58 AM Bin Meng  wrote:
>
> On Sat, Dec 7, 2019 at 12:52 PM Simon Glass  wrote:
> >
> > If these phases are used we typically want to enable pinctrl in then, so
> > that pad setup and GPIO access are possible.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > Changes in v6: None
> > Changes in v5:
> > - Correct build error in chromebook_samus_tpl
> >
> > Changes in v4: None
> > Changes in v3: None
> > Changes in v2: None
> >
> >  arch/Kconfig   | 2 ++
> >  configs/chromebook_samus_tpl_defconfig | 2 ++
> >  2 files changed, 4 insertions(+)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 077/102] mtd: spi: Export spi_flash_std_probe()

[Bin Meng]

On Sat, Dec 7, 2019 at 12:52 PM Simon Glass  wrote:
>
> With of-platdata we need to create drivers for particular chips, or at
> least drivers that are separate from the standard code, since C structures
> are created by dtoc which are private to that driver.
>
> To avoid duplicating the probing code, export this probe function for use
> by these drivers.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
>  drivers/mtd/spi/sf_probe.c |  2 +-
>  include/spi_flash.h| 12 
>  2 files changed, 13 insertions(+), 1 deletion(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 075/102] spi: ich: Add TPL support

[Bin Meng]

On Sun, Dec 8, 2019 at 11:58 AM Bin Meng  wrote:
>
> On Sat, Dec 7, 2019 at 12:52 PM Simon Glass  wrote:
> >
> > In TPL we want to reduce code size and support running with CONFIG_PCI
> > disabled. Add special code to handle this using a fixed BAR programmed
> > into the SPI on boot. Also cache the SPI flash to speed up boot.
> >
> > Signed-off-by: Simon Glass 
> >
> > ---
> >
> > Changes in v6:
> > - Add a comment about why we should not use MTRR_TYPE_WRBACK
> > - Use SZ_4G instead of open-coding the size value
> >
> > Changes in v5: None
> > Changes in v4: None
> > Changes in v3: None
> > Changes in v2: None
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 076/102] spi: ich: Add Apollo Lake support

[Bin Meng]

On Sat, Dec 7, 2019 at 12:52 PM Simon Glass  wrote:
>
> Add support for Apollo Lake to the ICH driver. This involves adjusting the
> mmio address and skipping setting of the bbar.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4:
> - apollolake -> Apollo Lake
>
> Changes in v3: None
> Changes in v2: None
>
>  drivers/spi/ich.c | 19 ++-
>  drivers/spi/ich.h |  1 +
>  2 files changed, 15 insertions(+), 5 deletions(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 074/102] spi: ich: Add support for get_mmap() method

[Bin Meng]

On Sat, Dec 7, 2019 at 12:51 PM Simon Glass  wrote:
>
> Add this method so that the memory-mapped location of the SPI flash can
> be queried.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4:
> - Use the new pci_ofplat_get_devfn() function
>
> Changes in v3: None
> Changes in v2: None
>
>  drivers/spi/ich.c | 32 
>  1 file changed, 32 insertions(+)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 073/102] spi: ich: Support hardware sequencing

[Bin Meng]

On Sat, Dec 7, 2019 at 12:51 PM Simon Glass  wrote:
>
> Apollo Lake (APL) only supports hardware sequencing. Add support for this
> into the SPI driver, as an option.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
>
> ---
>
> Changes in v6:
> - Add a comment as to why dev_read_bool() is not used
>
> Changes in v5: None
> Changes in v4:
> - Fix comment for exec_sync_hwseq_xfer()
> - apollolake -> Apollo Lake
>
> Changes in v3: None
> Changes in v2: None
>
>  drivers/spi/ich.c | 209 +-
>  drivers/spi/ich.h |  39 +
>  2 files changed, 245 insertions(+), 3 deletions(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 072/102] spi: ich: Support of-platdata for fast-spi

[Bin Meng]

On Sat, Dec 7, 2019 at 12:51 PM Simon Glass  wrote:
>
> The Intel Fast SPI interface is similar to ICH. Add of-platdata support
> for this using the "intel,fast-spi" compatible string.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4:
> - Use the new pci_ofplat_get_devfn() function
>
> Changes in v3: None
> Changes in v2: None
>
>  drivers/spi/ich.c | 18 +++---
>  1 file changed, 15 insertions(+), 3 deletions(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 071/102] spi: ich: Correct max-size bug in ich_spi_adjust_size()

[Bin Meng]

On Sun, Dec 8, 2019 at 11:56 AM Bin Meng  wrote:
>
> On Sat, Dec 7, 2019 at 12:51 PM Simon Glass  wrote:
> >
> > This incorrectly shortens read operations if there is a maximum write size
> > but no maximum read size. Fix it.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > Changes in v6: None
> > Changes in v5: None
> > Changes in v4: None
> > Changes in v3: None
> > Changes in v2: None
> >
> >  drivers/spi/ich.c | 8 +---
> >  1 file changed, 5 insertions(+), 3 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 079/102] x86: Add low-power subsystem (lpss) support

[Bin Meng]

On Sat, Dec 7, 2019 at 12:52 PM Simon Glass  wrote:
>
> This subsystem is present on various Intel SoCs.
>
> Add very basic support for taking an lpss device out of reset.
>
> Signed-off-by: Simon Glass 
>
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4:
> - Add support for updating power state
> - Move this to intel_common
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/cpu/intel_common/Makefile |  1 +
>  arch/x86/cpu/intel_common/lpss.c   | 44 ++
>  arch/x86/include/asm/lpss.h| 36 
>  3 files changed, 81 insertions(+)
>  create mode 100644 arch/x86/cpu/intel_common/lpss.c
>  create mode 100644 arch/x86/include/asm/lpss.h
>

Reviewed-by: Bin Meng 

Re: [PATCH v6 078/102] x86: Enable pinctrl in SPL and TPL

[Bin Meng]

On Sat, Dec 7, 2019 at 12:52 PM Simon Glass  wrote:
>
> If these phases are used we typically want to enable pinctrl in then, so
> that pad setup and GPIO access are possible.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v6: None
> Changes in v5:
> - Correct build error in chromebook_samus_tpl
>
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
>  arch/Kconfig   | 2 ++
>  configs/chromebook_samus_tpl_defconfig | 2 ++
>  2 files changed, 4 insertions(+)
>

Reviewed-by: Bin Meng 

Re: [PATCH v6 075/102] spi: ich: Add TPL support

[Bin Meng]

On Sat, Dec 7, 2019 at 12:52 PM Simon Glass  wrote:
>
> In TPL we want to reduce code size and support running with CONFIG_PCI
> disabled. Add special code to handle this using a fixed BAR programmed
> into the SPI on boot. Also cache the SPI flash to speed up boot.
>
> Signed-off-by: Simon Glass 
>
> ---
>
> Changes in v6:
> - Add a comment about why we should not use MTRR_TYPE_WRBACK
> - Use SZ_4G instead of open-coding the size value
>
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>

Reviewed-by: Bin Meng 

Re: [PATCH v6 071/102] spi: ich: Correct max-size bug in ich_spi_adjust_size()

[Bin Meng]

On Sat, Dec 7, 2019 at 12:51 PM Simon Glass  wrote:
>
> This incorrectly shortens read operations if there is a maximum write size
> but no maximum read size. Fix it.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
>  drivers/spi/ich.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>

Reviewed-by: Bin Meng 

Re: [PATCH v6 070/102] dm: doc: Add a note about of-platdata and header files

[Bin Meng]

On Sat, Dec 7, 2019 at 12:51 PM Simon Glass  wrote:
>
> We don't want to include dt-structs.h in header files, so add a note about
> that.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4:
> - Add a patch to explain of-platdata and header files
>
> Changes in v3: None
> Changes in v2: None
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 069/102] spi: ich: Add mmio_base to struct ich_spi_platdata

[Bin Meng]

On Sat, Dec 7, 2019 at 12:51 PM Simon Glass  wrote:
>
> It is useful to store the mmio base in platdata. It reduces the amount of
> casting needed. Update the code and move the struct to the C file at the
> same time, as we will need to use with of-platdata.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4:
> - Use priv->pch instead of dev->parent
>
> Changes in v3: None
> Changes in v2: None
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 068/102] spi: ich: Various small tidy-ups

[Bin Meng]

On Sat, Dec 7, 2019 at 12:51 PM Simon Glass  wrote:
>
> Use debug() instead of printf() to reduce code size and change a bool
> return value to the use the 'bool' type. Also drop the global data
> declaration since it not actually used. Finally, set the log category.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
>  drivers/spi/ich.c | 17 -
>  1 file changed, 8 insertions(+), 9 deletions(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 067/102] spi: ich: Fix header order

[Bin Meng]

On Sat, Dec 7, 2019 at 12:51 PM Simon Glass  wrote:
>
> Move the header files into the right order.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
>  drivers/spi/ich.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 066/102] spi: ich: Convert to livetree

[Bin Meng]

On Sat, Dec 7, 2019 at 12:51 PM Simon Glass  wrote:
>
> Use dev_get_driver_data() to obtain the device type. It has the same
> effect and is shorter.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
>  drivers/spi/ich.c | 22 +-
>  1 file changed, 5 insertions(+), 17 deletions(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 065/102] spi: ich: Move the protection/lockdown code into a function

[Bin Meng]

On Sat, Dec 7, 2019 at 12:50 PM Simon Glass  wrote:
>
> Reduce the size of the probe function but putting this code into its own
> function.
>
> Also remove the assumption that the PCH is always a parent of the SPI
> controller, as this is not the case APL platforms. Use driver model to
> find the PCH instead.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
>  drivers/spi/ich.c | 63 ---
>  drivers/spi/ich.h |  1 +
>  2 files changed, 44 insertions(+), 20 deletions(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 064/102] spi: ich: Move init function just above probe()

[Bin Meng]

On Sat, Dec 7, 2019 at 12:50 PM Simon Glass  wrote:
>
> It is annoying to have some of the init code in a different part of the
> file. Move ich_init_controller() to just above probe() to keep things
> together.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
>  drivers/spi/ich.c | 122 +++---
>  1 file changed, 61 insertions(+), 61 deletions(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 063/102] x86: spi: Don't enable SPI_FLASH_BAR by default

[Bin Meng]

On Sat, Dec 7, 2019 at 12:50 PM Simon Glass  wrote:
>
> We don't normally need this on x86 unless the size of SPI flash devices is
> larger than 16MB. This can be enabled by particular SoCs as needed, since
> it adds to code size.
>
> Drop the default enabling of this option on x86.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
>  drivers/spi/Kconfig | 1 -
>  1 file changed, 1 deletion(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 062/102] spi: Correct operations check in dm_spi_xfer()

[Bin Meng]

On Sat, Dec 7, 2019 at 12:50 PM Simon Glass  wrote:
>
> At present we have to have an xfer() method even if it does nothing. This
> is not correct, so fix it.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
>  drivers/spi/ich.c| 9 +
>  drivers/spi/spi-uclass.c | 5 -
>  include/spi.h| 2 +-
>  3 files changed, 6 insertions(+), 10 deletions(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 061/102] x86: Make MSR_PKG_POWER_SKU common

[Bin Meng]

On Sat, Dec 7, 2019 at 12:49 PM Simon Glass  wrote:
>
> This is used on several boards so add it to the common file. Also add a
> useful power-limit value while we are here.
>
> Reviewed-by: Bin Meng 
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/include/asm/arch-broadwell/cpu.h | 1 -
>  arch/x86/include/asm/arch-ivybridge/model_206ax.h | 1 -
>  arch/x86/include/asm/msr-index.h  | 9 -
>  3 files changed, 8 insertions(+), 3 deletions(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 060/102] x86: Separate out U-Boot and device tree in ROM image

[Bin Meng]

On Sat, Dec 7, 2019 at 12:49 PM Simon Glass  wrote:
>
> At present binman does not support updating a device tree that is part of
> U-Boot (i.e u-boot.bin). Separate the entries into two so that we can get
> updated entry information. This makes binman_entry_find() work correctly.
>
> Do the same for SPL tool.
>
> In both cases, group the two parts into a section so that SPL symbols get
> the correct total size.
>
> It may be possible for binman to handle this automatically at some point,
> by ignoring u-boot.bin and always creating it from u-boot-nodtb.bin and
> u-boot.dtb
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5:
> - Change SPL as well
> - Group U-Boot and device tree into a section
> - Rename spl section to 'spl' so that binman symbols can find it
>
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/dts/u-boot.dtsi | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 059/102] x86: Don't repeat microcode in U-Boot if not needed

[Bin Meng]

On Sat, Dec 7, 2019 at 12:49 PM Simon Glass  wrote:
>
> At present if SPL sets up the microcode then it is still included in
> U-Boot as well. This is wasteful as microcode is large. Adjust the logic
> in the image to prevent this.
>
> Reviewed-by: Bin Meng 
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/dts/u-boot.dtsi | 7 +++
>  1 file changed, 7 insertions(+)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 057/102] x86: Add an option to control the position of SPL

[Bin Meng]

On Sat, Dec 7, 2019 at 12:49 PM Simon Glass  wrote:
>
> For Apollo Lake SPL is run from CAR (cache-as-RAM) which is in a different
> location from where SPL must be placed in ROM. In other words, although
> SPL runs before SDRAM is set up, it is not execute-in-place (XIP).
>
> Add a Kconfig option for the ROM position.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4:
> - apollolake -> Apollo Lake
>
> Changes in v3:
> - Add SPL condition to the option
>
> Changes in v2: None
>
>  arch/x86/Kconfig | 5 +
>  arch/x86/dts/u-boot.dtsi | 4 ++--
>  2 files changed, 7 insertions(+), 2 deletions(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 058/102] x86: Add an fdtmap and image-header

[Bin Meng]

On Sat, Dec 7, 2019 at 12:49 PM Simon Glass  wrote:
>
> Add these entries to the ROM so that we can list the contents of an image
> with 'binman ls'. The image-header is not essential but does speed up
> access.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/dts/u-boot.dtsi | 5 +
>  1 file changed, 5 insertions(+)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 056/102] x86: Add an option to control the position of U-Boot

[Bin Meng]

On Sat, Dec 7, 2019 at 12:49 PM Simon Glass  wrote:
>
> The existing work-around for positioning U-Boot in the ROM when it
> actually runs from RAM still exists and there is not obvious way to change
> this.
>
> Add a proper Kconfig option to handle this case. This also adds a new bool
> property to indicate whether CONFIG_SYS_TEXT_BASE exists.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4:
> - Rename option to HAVE_SYS_TEXT_BASE
>
> Changes in v3: None
> Changes in v2: None
>
>  Kconfig|  9 ++---
>  arch/x86/Kconfig   |  5 +
>  arch/x86/dts/u-boot.dtsi   | 18 +++---
>  configs/chromebook_samus_tpl_defconfig |  1 +
>  configs/qemu-x86_64_defconfig  |  1 +
>  5 files changed, 16 insertions(+), 18 deletions(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 055/102] x86: Update .dtsi file for FSP2

[Bin Meng]

On Sat, Dec 7, 2019 at 12:49 PM Simon Glass  wrote:
>
> Include the IFWI section and the FSP-M binary. The FSP-T binary is not
> currently used, as CAR is set up manually.
>
> Also drop the FSP binary as this relates only to FSP1.
>
> Reviewed-by: Bin Meng 
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3:
> - Add FSP-S and VBT also
> - Drop VBT as we already have it elsewhere
>
> Changes in v2: None
>
>  arch/x86/dts/u-boot.dtsi | 32 +++-
>  1 file changed, 31 insertions(+), 1 deletion(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 052/102] x86: Add support for newer CAR schemes

[Bin Meng]

On Sat, Dec 7, 2019 at 12:49 PM Simon Glass  wrote:
>
> Newer Intel SoCs have different ways of setting up cache-as-ram (CAR).
> Add support for these along with suitable configuration options.
>
> To make the code cleaner, adjust a few definitions in processor.h so that
> they can be used from assembler.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4:
> - Adjust
> - Fix up license header
> - Fix various code-style problems
> - Use CONFIG_INTEL_CAR_CQOS to control car2.S inclusion
> - Use car_init_ret to return
> - Use post_code() calls consistent with car.S
>
> Changes in v3:
> - Drop dead code
> - Drop unneeded Kconfig file
> - Use a macro for is-power-of-two
>
> Changes in v2: None
>
>  arch/x86/Kconfig|  16 +
>  arch/x86/cpu/intel_common/Makefile  |   8 +
>  arch/x86/cpu/intel_common/car2.S| 448 
>  arch/x86/cpu/intel_common/car2_uninit.S |  87 +
>  arch/x86/include/asm/processor.h|  12 +-
>  5 files changed, 564 insertions(+), 7 deletions(-)
>  create mode 100644 arch/x86/cpu/intel_common/car2.S
>  create mode 100644 arch/x86/cpu/intel_common/car2_uninit.S
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 053/102] x86: Disable microcode section for FSP2

[Bin Meng]

On Sat, Dec 7, 2019 at 12:49 PM Simon Glass  wrote:
>
> At present we don't support loading microcode with FSP2. The correct way
> to do this is by adding it to the FIT. For now, disable including
> microcode in the image.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3:
> - Drop unnecessary #else part of CONFIG_HAVE_MICROCODE
>
> Changes in v2: None
>
>  arch/x86/Kconfig | 4 
>  arch/x86/dts/u-boot.dtsi | 7 +++
>  2 files changed, 11 insertions(+)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 050/102] x86: Don't include the BIOS emulator in TPL

[Bin Meng]

On Sat, Dec 7, 2019 at 12:49 PM Simon Glass  wrote:
>
> We don't generally have enough space to run this, so don't build it into
> TPL. This helps reduce the size of TPL.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/lib/Makefile | 2 ++
>  1 file changed, 2 insertions(+)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 051/102] x86: Add an option to include a FIT

[Bin Meng]

On Sat, Dec 7, 2019 at 12:49 PM Simon Glass  wrote:
>
> Many Intel SoCs require a FIT in order to boot properly. Add an option to
> include this and enable it by default.
>
> This term can be confused with FIT (Flat Image Tree) in U-Boot so the
> CONFIG option has to include 'X86'.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3:
> - Add help to CONFIG_FIT and don't make it 'default y'
> - Rename X86_HAS_FIT to HAVE_X86_FIT
> - Update commit message to explain why HAVE_FIT woudl be confusing
>
> Changes in v2: None
>
>  arch/x86/Kconfig | 8 
>  arch/x86/dts/u-boot.dtsi | 6 ++
>  2 files changed, 14 insertions(+)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 054/102] x86: Update the fsp command for FSP2

[Bin Meng]

On Sat, Dec 7, 2019 at 12:49 PM Simon Glass  wrote:
>
> The current 'fsp' command only works with FSP1. Update it to handle FSP2
> as well. Convert everything to hex which is what U-Boot uses.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4:
> - Explain why FSP-M cannot be shown
> - Use hex for size values also
>
> Changes in v3:
> - Convert code to use hex increased of decimal
> - Update the 'fsp' command for FSP2, instead of disabling it
>
> Changes in v2: None
>
>  cmd/x86/fsp.c | 65 ++-
>  1 file changed, 44 insertions(+), 21 deletions(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 048/102] x86: fsp: Allow remembering the location of FSP-S

[Bin Meng]

On Sat, Dec 7, 2019 at 12:49 PM Simon Glass  wrote:
>
> FSP-S is used by the notify call after it has been used for silicon init.
> To avoid having to load it again, add a field to store the location.
>
> Reviewed-by: Bin Meng 
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/include/asm/global_data.h | 3 +++
>  1 file changed, 3 insertions(+)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 045/102] x86: fsp: Add FSP2 base support

[Bin Meng]

On Sun, Dec 8, 2019 at 11:11 AM Bin Meng  wrote:
>
> On Sat, Dec 7, 2019 at 12:49 PM Simon Glass  wrote:
> >
> > Add support for some important configuration options and FSP memory init.
> > The memory init uses swizzle tables from the device tree.
> >
> > Support for the FSP_S binary is also included.
> >
> > Bootstage timing is used for both FSP_M and FSP_S and memory-mapped SPI
> > reads.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > Changes in v6:
> > - Add a lot of comments to get_cbfs_fsp()
> > - Drop extra conditions on CONFIG_VIDEO_FSP
> > - Make BOOT_FROM_FAST_SPI_FLASH a Kconfig option
> > - Remove hyphens from Firmware-Support-Package
> >
> > Changes in v5:
> > - Drop SAFETY_MARGIN
> >
> > Changes in v4:
> > - Add a LOG_CATEGORY for silicon init
> > - Drop duplicate VBT file CONFIG
> > - Enable HAVE_VBT for FSP2 also
> > - Explain the 'twisty headers' comment
> > - Fix FSP_M reference to refer to FSP_S in commit message
> > - Fix comment on fsp_silicon_init()
> > - Rename arch_fsp_s_preinit() to arch_fsps_preinit()
> > - Rename get_coreboot_fsp() and add comments
> > - Switch over to use pinctrl for pad init/config
> > - Use lower-case pinctrl in arch_cpu_init_dm()
> >
> > Changes in v3:
> > - Add a proper implementation of fsp_notify
> > - Add an fsp: tag
> > - Add bootstage timing for memory-mapped reads
> > - Add fsp_locate_fsp to locate an fsp component
> > - Add fspm_done() hook
> > - Add support for FSP-S component and VBT
> > - Simplify types for fsp_locate_fsp()
> > - Switch mmap to use SPI instead of SPI flash
> >
> > Changes in v2: None
> >
> >  arch/x86/Kconfig |  52 +-
> >  arch/x86/include/asm/fsp2/fsp_api.h  |  63 
> >  arch/x86/include/asm/fsp2/fsp_internal.h |  97 
> >  arch/x86/lib/fsp2/Makefile   |  10 ++
> >  arch/x86/lib/fsp2/fsp_common.c   |  13 ++
> >  arch/x86/lib/fsp2/fsp_dram.c |  78 +
> >  arch/x86/lib/fsp2/fsp_init.c | 191 +++
> >  arch/x86/lib/fsp2/fsp_meminit.c  |  97 
> >  arch/x86/lib/fsp2/fsp_silicon_init.c |  54 +++
> >  arch/x86/lib/fsp2/fsp_support.c  | 131 
> >  include/bootstage.h  |   3 +
> >  11 files changed, 787 insertions(+), 2 deletions(-)
> >  create mode 100644 arch/x86/include/asm/fsp2/fsp_api.h
> >  create mode 100644 arch/x86/include/asm/fsp2/fsp_internal.h
> >  create mode 100644 arch/x86/lib/fsp2/Makefile
> >  create mode 100644 arch/x86/lib/fsp2/fsp_common.c
> >  create mode 100644 arch/x86/lib/fsp2/fsp_dram.c
> >  create mode 100644 arch/x86/lib/fsp2/fsp_init.c
> >  create mode 100644 arch/x86/lib/fsp2/fsp_meminit.c
> >  create mode 100644 arch/x86/lib/fsp2/fsp_silicon_init.c
> >  create mode 100644 arch/x86/lib/fsp2/fsp_support.c
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 047/102] x86: fsp: Add a new arch_fsp_init_r() hook

[Bin Meng]

On Sat, Dec 7, 2019 at 12:49 PM Simon Glass  wrote:
>
> With FSP2 we need to run silicon init early after relocation. Add a new
> hook for this.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
>  common/board_r.c |  3 +++
>  include/init.h   | 11 +++
>  2 files changed, 14 insertions(+)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 046/102] x86: fsp: Set up an MTRR for the graphics frame buffer

[Bin Meng]

On Sat, Dec 7, 2019 at 12:49 PM Simon Glass  wrote:
>
> The FSP-S may do this but at least for coral it does not. Set this up so
> that graphics is not deathly slow.
>
> It isn't clear whether the FSP is expected to set up MTRR. It is not
> mentioned in the APL FSP document.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/lib/fsp/fsp_graphics.c | 4 
>  1 file changed, 4 insertions(+)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 049/102] x86: fsp: Make the notify API call common

[Bin Meng]

On Sat, Dec 7, 2019 at 12:49 PM Simon Glass  wrote:
>
> The fsp_notify() API is the same for FSP1 and FSP2. Move it into a new
> common API file.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4:
> - Drop incorrect coreboot reference from header file
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/include/asm/fsp/fsp_api.h  | 24 
>  arch/x86/include/asm/fsp1/fsp_api.h | 21 +++--
>  2 files changed, 27 insertions(+), 18 deletions(-)
>  create mode 100644 arch/x86/include/asm/fsp/fsp_api.h
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 042/102] x86: Allow interrupt to happen once

[Bin Meng]

On Sat, Dec 7, 2019 at 12:48 PM Simon Glass  wrote:
>
> At present the interrupt table is included in all phases of U-Boot. Allow
> it to be omitted, e.g. in TPL, to reduce size.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3:
> - Move write_pirq_routing_table() to avoid 64-bit build error
>
> Changes in v2: None
>
>  arch/x86/cpu/Makefile   |  2 +-
>  arch/x86/cpu/irq.c  |  8 
>  arch/x86/lib/pirq_routing.c | 10 ++
>  3 files changed, 11 insertions(+), 9 deletions(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 043/102] x86: fsp: Make graphics support common to FSP1/2

[Bin Meng]

On Sat, Dec 7, 2019 at 12:49 PM Simon Glass  wrote:
>
> Both versions of FSP can use the same graphics support, so move it into
> the common directory.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/lib/fsp/Makefile | 3 +++
>  arch/x86/lib/{fsp1 => fsp}/fsp_graphics.c | 2 +-
>  arch/x86/lib/fsp1/Makefile| 1 -
>  3 files changed, 4 insertions(+), 2 deletions(-)
>  rename arch/x86/lib/{fsp1 => fsp}/fsp_graphics.c (98%)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 044/102] x86: fsp: Correct wrong header inlude in fsp_support.c

[Bin Meng]

On Sat, Dec 7, 2019 at 12:49 PM Simon Glass  wrote:
>
> This generic FSP file should include the generic FSP support header, not
> the FSP1 version. Fix it.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/lib/fsp/fsp_support.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 041/102] x86: Allow removal of standard PCH drivers

[Bin Meng]

On Sat, Dec 7, 2019 at 12:48 PM Simon Glass  wrote:
>
> These drivers are not needed on all platforms. While they are small, it
> is useful in TPL to drop then. Add Kconfig control to allow this.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
> - Change 'queensbay' to 'baytrail' in help
> - Fix 'proides' typo
>
>  drivers/pch/Kconfig  | 18 ++
>  drivers/pch/Makefile |  4 ++--
>  2 files changed, 20 insertions(+), 2 deletions(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 045/102] x86: fsp: Add FSP2 base support

[Bin Meng]

On Sat, Dec 7, 2019 at 12:49 PM Simon Glass  wrote:
>
> Add support for some important configuration options and FSP memory init.
> The memory init uses swizzle tables from the device tree.
>
> Support for the FSP_S binary is also included.
>
> Bootstage timing is used for both FSP_M and FSP_S and memory-mapped SPI
> reads.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v6:
> - Add a lot of comments to get_cbfs_fsp()
> - Drop extra conditions on CONFIG_VIDEO_FSP
> - Make BOOT_FROM_FAST_SPI_FLASH a Kconfig option
> - Remove hyphens from Firmware-Support-Package
>
> Changes in v5:
> - Drop SAFETY_MARGIN
>
> Changes in v4:
> - Add a LOG_CATEGORY for silicon init
> - Drop duplicate VBT file CONFIG
> - Enable HAVE_VBT for FSP2 also
> - Explain the 'twisty headers' comment
> - Fix FSP_M reference to refer to FSP_S in commit message
> - Fix comment on fsp_silicon_init()
> - Rename arch_fsp_s_preinit() to arch_fsps_preinit()
> - Rename get_coreboot_fsp() and add comments
> - Switch over to use pinctrl for pad init/config
> - Use lower-case pinctrl in arch_cpu_init_dm()
>
> Changes in v3:
> - Add a proper implementation of fsp_notify
> - Add an fsp: tag
> - Add bootstage timing for memory-mapped reads
> - Add fsp_locate_fsp to locate an fsp component
> - Add fspm_done() hook
> - Add support for FSP-S component and VBT
> - Simplify types for fsp_locate_fsp()
> - Switch mmap to use SPI instead of SPI flash
>
> Changes in v2: None
>
>  arch/x86/Kconfig |  52 +-
>  arch/x86/include/asm/fsp2/fsp_api.h  |  63 
>  arch/x86/include/asm/fsp2/fsp_internal.h |  97 
>  arch/x86/lib/fsp2/Makefile   |  10 ++
>  arch/x86/lib/fsp2/fsp_common.c   |  13 ++
>  arch/x86/lib/fsp2/fsp_dram.c |  78 +
>  arch/x86/lib/fsp2/fsp_init.c | 191 +++
>  arch/x86/lib/fsp2/fsp_meminit.c  |  97 
>  arch/x86/lib/fsp2/fsp_silicon_init.c |  54 +++
>  arch/x86/lib/fsp2/fsp_support.c  | 131 
>  include/bootstage.h  |   3 +
>  11 files changed, 787 insertions(+), 2 deletions(-)
>  create mode 100644 arch/x86/include/asm/fsp2/fsp_api.h
>  create mode 100644 arch/x86/include/asm/fsp2/fsp_internal.h
>  create mode 100644 arch/x86/lib/fsp2/Makefile
>  create mode 100644 arch/x86/lib/fsp2/fsp_common.c
>  create mode 100644 arch/x86/lib/fsp2/fsp_dram.c
>  create mode 100644 arch/x86/lib/fsp2/fsp_init.c
>  create mode 100644 arch/x86/lib/fsp2/fsp_meminit.c
>  create mode 100644 arch/x86/lib/fsp2/fsp_silicon_init.c
>  create mode 100644 arch/x86/lib/fsp2/fsp_support.c
>

Reviewed-by: Bin Meng 

Re: [PATCH v6 040/102] x86: Don't imply libfdt or SPI flash in TPL

[Bin Meng]

On Sat, Dec 7, 2019 at 12:48 PM Simon Glass  wrote:
>
> We don't want to pull in libfdt if of-platdata is being used, since it
> reduces the available code-size saves. Also, SPI flash is seldom needed
> in TPL.
>
> Drop these options.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3:
> - Don't imply SPI flash either
> - Rewrite commit message
>
> Changes in v2: None
>
>  arch/Kconfig | 3 ---
>  1 file changed, 3 deletions(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 038/102] x86: Set the DRAM banks to reflect real location

[Bin Meng]

On Sat, Dec 7, 2019 at 12:48 PM Simon Glass  wrote:
>
> At present with fsp a single DRAM bank is added which extends to the
> whole size of memory. However there is typically only 2GB of memory
> available below the 4GB boundary, and this is what is used by U-Boot while
> running in 32-bit mode.
>
> Scan the tables to set the banks correct. The first bank is set to memory
> below 4GB, and the rest of memory is put into subsequent banks.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3:
> - Move mtrr_add_request() call to next patch
>
> Changes in v2: None
>
>  arch/x86/lib/fsp/fsp_dram.c | 30 +-
>  1 file changed, 29 insertions(+), 1 deletion(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 039/102] x86: Set up the MTRR for SDRAM

[Bin Meng]

On Sat, Dec 7, 2019 at 12:48 PM Simon Glass  wrote:
>
> Set up MTRRs for the FSP SDRAM regions to improve performance.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5:
> - Fix FST typo
>
> Changes in v4: None
> Changes in v3:
> - Move mtrr_add_request() call into this patch
>
> Changes in v2: None
>
>  arch/x86/lib/fsp/fsp_dram.c | 5 +
>  1 file changed, 5 insertions(+)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 033/102] x86: Tidy up error handling in mrccache_save()

[Bin Meng]

On Sat, Dec 7, 2019 at 12:48 PM Simon Glass  wrote:
>
> This function is a bit confusing at present due to the error handling.
> Update it to remove the goto, returning errors as they happen.
>
> While we are here, use hex for the data size since this is the norm in
> U-Boot.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3:
> - Move an additional error handling fix from a future patch
>
> Changes in v2: None
>
>  arch/x86/lib/mrccache.c | 19 +++
>  1 file changed, 7 insertions(+), 12 deletions(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 034/102] x86: Update mrccache to support multiple caches

[Bin Meng]

On Sat, Dec 7, 2019 at 12:48 PM Simon Glass  wrote:
>
> With Apollo Lake we need to support a normal cache, which almost never
> changes and a much smaller 'variable' cache which changes every time.
>
> Update the code to add a cache type, use an array for the caches and use a
> for loop to iterate over the caches.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4:
> - apollolake -> Apollo Lake
>
> Changes in v3:
> - Move line related to variable-cache into the next patch
>
> Changes in v2: None
>
>  arch/x86/cpu/broadwell/sdram.c |  8 ++-
>  arch/x86/cpu/ivybridge/sdram.c |  8 ++-
>  arch/x86/cpu/quark/dram.c  |  8 ++-
>  arch/x86/include/asm/global_data.h | 21 +--
>  arch/x86/include/asm/mrccache.h| 11 +++-
>  arch/x86/lib/fsp/fsp_common.c  |  2 +-
>  arch/x86/lib/fsp1/fsp_dram.c   |  8 ++-
>  arch/x86/lib/mrccache.c| 88 --
>  8 files changed, 106 insertions(+), 48 deletions(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 036/102] x86: Don't export mrccache_update()

[Bin Meng]

On Sat, Dec 7, 2019 at 12:48 PM Simon Glass  wrote:
>
> This function is only used within the implementation so make it static.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4:
> - Add new patch to make mrccache_update() static
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/include/asm/mrccache.h | 15 ---
>  arch/x86/lib/mrccache.c | 16 ++--
>  2 files changed, 14 insertions(+), 17 deletions(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 037/102] x86: Move fsp_prepare_mrc_cache() to fsp1 directory

[Bin Meng]

On Sat, Dec 7, 2019 at 12:48 PM Simon Glass  wrote:
>
> This function needs to be different for FSP2, so move the existing
> function into the fsp1 directory. Since it is only called from one file,
> drop it from the header file.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/include/asm/fsp/fsp_support.h |  7 ---
>  arch/x86/lib/fsp/fsp_common.c  | 20 
>  arch/x86/lib/fsp1/fsp_common.c | 20 
>  3 files changed, 20 insertions(+), 27 deletions(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 035/102] x86: Add mrccache support for a 'variable' cache

[Bin Meng]

On Sat, Dec 7, 2019 at 12:48 PM Simon Glass  wrote:
>
> Add support for a second cache type, for Apollo Lake.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4:
> - apollolake -> Apollo Lake
>
> Changes in v3:
> - Move the mrccache_get_region() change into this patch
>
> Changes in v2: None
>
>  arch/x86/include/asm/mrccache.h | 1 +
>  arch/x86/lib/mrccache.c | 3 ++-
>  2 files changed, 3 insertions(+), 1 deletion(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 032/102] x86: Add a new global_data member for the cache record

[Bin Meng]

On Sat, Dec 7, 2019 at 12:47 PM Simon Glass  wrote:
>
> At present we reuse the mrc_output char * to also point to the cache
> record after it has been set up. This is confusing and doesn't save much
> data space.
>
> Add a new mrc_cache member instead.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/include/asm/global_data.h |  2 ++
>  arch/x86/lib/mrccache.c| 11 +--
>  2 files changed, 7 insertions(+), 6 deletions(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 031/102] x86: Adjust mrccache_get_region() to support get_mmap()

[Bin Meng]

On Sat, Dec 7, 2019 at 12:47 PM Simon Glass  wrote:
>
> It is now possible to obtain the memory map for a SPI controllers instead
> of having it hard-coded in the device tree. Update the code to support
> this.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
> - Use SPI mmap() instead of SPI flash
>
>  arch/x86/lib/mrccache.c | 18 ++
>  1 file changed, 14 insertions(+), 4 deletions(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 030/102] x86: Adjust mrccache_get_region() to use livetree

[Bin Meng]

On Sat, Dec 7, 2019 at 12:47 PM Simon Glass  wrote:
>
> Change the algorithm to first find the flash device then read the
> properties using the livetree API. With this change the device is not
> probed so this needs to be done in mrccache_save().
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3:
> - Update mrccache livetree patch to just convert to livetree
>
> Changes in v2: None
>
>  arch/x86/lib/mrccache.c | 55 +++--
>  1 file changed, 26 insertions(+), 29 deletions(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 029/102] x86: Correct mrccache find_next_mrc_cache() calculation

[Bin Meng]

On Sat, Dec 7, 2019 at 12:47 PM Simon Glass  wrote:
>
> This should take account of the end of the new cache record since a record
> cannot extend beyond the end of the flash region. This problem was not
> seen before due to the alignment of the relatively small amount of MRC
> data.
>
> But with Apollo Lake the MRC data is about 45KB, even if most of it is
> zeroes.
>
> Fix this bug and update the parameter name to be less confusing.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4:
> - Add comments about MRC-cache records being the same size
> - apollolake -> Apollo Lake
>
> Changes in v3:
> - Add an extra size parameter to the find_next_mrc_cache() function
>
> Changes in v2: None
>
>  arch/x86/lib/mrccache.c | 18 ++
>  1 file changed, 14 insertions(+), 4 deletions(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 028/102] x86: Reduce mrccache record alignment size

[Bin Meng]

On Sat, Dec 7, 2019 at 12:47 PM Simon Glass  wrote:
>
> At present the records are 4KB in size. This is unnecessarily large when
> the SPI-flash erase size is 256 bytes. Reduce it so it will be more
> efficient with Apollo Lake's 24-byte variable-data record.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
>
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4:
> - apollolake -> Apollo Lake
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/include/asm/mrccache.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 025/102] x86: Move UCLASS_IRQ into a separate file

[Bin Meng]

On Sat, Dec 7, 2019 at 12:47 PM Simon Glass  wrote:
>
> Update this uclass to support the needs of the Apollo Lake ITSS. It
> supports four operations.
>
> Move the uclass into a separate directory so that sandbox can use it too.
> Add a new Kconfig to control it and enable this on x86.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4:
> - Drop itss uclass in Makefile
> - Fix 'enabled' typo
> - apollolake -> Apollo Lake
>
> Changes in v3:
> - Add two more operations to IRQ
> - Use the IRQ uclass instead of creating a new ITSS uclass
>
> Changes in v2: None
>
>  arch/Kconfig  |  1 +
>  arch/x86/cpu/irq.c|  5 ---
>  drivers/misc/Kconfig  |  9 
>  drivers/misc/Makefile |  1 +
>  drivers/misc/irq-uclass.c | 53 +++
>  include/irq.h | 88 +++
>  6 files changed, 152 insertions(+), 5 deletions(-)
>  create mode 100644 drivers/misc/irq-uclass.c
>  create mode 100644 include/irq.h
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 024/102] sandbox: Add PCI driver and test for p2sb

[Bin Meng]

On Sat, Dec 7, 2019 at 12:47 PM Simon Glass  wrote:
>
> Add a sandbox driver and PCI-device emulator for p2sb. Also add a test
> which uses a simple 'adder' driver to test the p2sb functionality.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6:
> - Correct a few unrelated defconfig changes
> - Drop unwanted debug printf()
>
> Changes in v5: None
> Changes in v4:
> - Drop change to message about a missing uclass
> - Drop empty operations struct since p2sb does not need it
> - Drop pmic_pm8916 driver name and use a sandbox name instead
> - Split out mmio changes into a separate patch
>
> Changes in v3:
> - Fix build errors in sandbox_spl, etc
>
> Changes in v2: None
>
>  arch/sandbox/dts/test.dts  |  13 ++
>  arch/sandbox/include/asm/test.h|   1 +
>  configs/sandbox64_defconfig|   3 +
>  configs/sandbox_defconfig  |   1 +
>  configs/sandbox_flattree_defconfig |   3 +
>  configs/sandbox_spl_defconfig  |   3 +
>  configs/tools-only_defconfig   |   2 +
>  drivers/misc/Makefile  |   2 +
>  drivers/misc/p2sb_emul.c   | 272 +
>  drivers/misc/p2sb_sandbox.c|  39 +
>  drivers/misc/sandbox_adder.c   |  60 +++
>  test/dm/Makefile   |   1 +
>  test/dm/p2sb.c |  28 +++
>  13 files changed, 428 insertions(+)
>  create mode 100644 drivers/misc/p2sb_emul.c
>  create mode 100644 drivers/misc/p2sb_sandbox.c
>  create mode 100644 drivers/misc/sandbox_adder.c
>  create mode 100644 test/dm/p2sb.c
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 027/102] x86: Define the SPL image start

[Bin Meng]

On Sat, Dec 7, 2019 at 12:47 PM Simon Glass  wrote:
>
> Define this symbol so that we can use binman symbols correctly.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/cpu/u-boot-spl.lds | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 023/102] sandbox: Disable mmio by default in tests

[Bin Meng]

On Sat, Dec 7, 2019 at 12:47 PM Simon Glass  wrote:
>
> When reseting sandbox for tests, disable mmio support since that is the
> default state.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4:
> - Split out into a separate patch
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/sandbox/cpu/state.c | 1 +
>  1 file changed, 1 insertion(+)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 026/102] sandbox: Add a test for IRQ

[Bin Meng]

On Sat, Dec 7, 2019 at 12:47 PM Simon Glass  wrote:
>
> Add a simple sandbox test for this uclass.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6:
> - Move setting of CONFIG_IRQ in sandbox to this patch
>
> Changes in v5: None
> Changes in v4:
> - Drop itss uclass change in Makefile (now in previous patch)
> - Drop sandbox defconfig change now that p2sb change is correct
> - Enable IRQ for sandbox64 too to avoid build error
>
> Changes in v3:
> - Change the sandbox test from ITSS to IRQ
>
> Changes in v2: None
>
>  arch/sandbox/dts/test.dts  |  4 +++
>  configs/sandbox64_defconfig|  1 +
>  configs/sandbox_defconfig  |  1 +
>  configs/sandbox_flattree_defconfig |  1 +
>  configs/sandbox_spl_defconfig  |  1 +
>  drivers/misc/Makefile  |  1 +
>  drivers/misc/irq_sandbox.c | 55 ++
>  test/dm/Makefile   |  1 +
>  test/dm/irq.c  | 32 +
>  9 files changed, 97 insertions(+)
>  create mode 100644 drivers/misc/irq_sandbox.c
>  create mode 100644 test/dm/irq.c
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 022/102] pci: Add support for p2sb uclass

[Bin Meng]

On Sat, Dec 7, 2019 at 12:47 PM Simon Glass  wrote:
>
> The Primary-to-Sideband bus (P2SB) is used to access various peripherals
> through memory-mapped I/O in a large chunk of PCI space. The space is
> segmented into different channels and peripherals are accessed by
> device-specific means within those channels. Devices should be added in
> the device tree as subnodes of the p2sb.
>
> This adds a uclass and enables it for sandbox.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
>
> ---
>
> Changes in v6: None
> Changes in v5:
> - Add a way to obtain the port ID for a device
> - Don't enable p2sb on sandbox in this patch
>
> Changes in v4:
> - Adjust condition for binding children
>
> Changes in v3: None
> Changes in v2: None
>
>  drivers/misc/Kconfig   |  33 ++
>  drivers/misc/Makefile  |   1 +
>  drivers/misc/p2sb-uclass.c | 216 +
>  include/dm/uclass-id.h |   1 +
>  include/p2sb.h | 135 +++
>  5 files changed, 386 insertions(+)
>  create mode 100644 drivers/misc/p2sb-uclass.c
>  create mode 100644 include/p2sb.h
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 021/102] x86: sandbox: Add a PMC emulator and test

[Bin Meng]

On Sat, Dec 7, 2019 at 12:47 PM Simon Glass  wrote:
>
> Add a simple PMC for sandbox to permit tests to run.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3:
> - Rename power-mgr uclass to acpi-pmc
> - Tidy up Makefile rules to reduce duplication
>
> Changes in v2: None
>
>  arch/Kconfig  |   3 +
>  arch/sandbox/dts/sandbox.dtsi |  14 ++
>  arch/sandbox/dts/test.dts |  14 ++
>  arch/sandbox/include/asm/test.h   |   1 +
>  cmd/Kconfig   |   8 +
>  cmd/Makefile  |   1 +
>  cmd/pmc.c |  81 ++
>  drivers/Makefile  |   1 +
>  drivers/power/acpi_pmc/Kconfig|   9 ++
>  drivers/power/acpi_pmc/Makefile   |   1 +
>  drivers/power/acpi_pmc/pmc_emul.c | 246 ++
>  drivers/power/acpi_pmc/sandbox.c  |  97 
>  test/dm/Makefile  |   1 +
>  test/dm/pmc.c |  33 
>  14 files changed, 510 insertions(+)
>  create mode 100644 cmd/pmc.c
>  create mode 100644 drivers/power/acpi_pmc/pmc_emul.c
>  create mode 100644 drivers/power/acpi_pmc/sandbox.c
>  create mode 100644 test/dm/pmc.c
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 019/102] x86: Drop unnecessary interrupt code for TPL

[Bin Meng]

On Sat, Dec 7, 2019 at 12:46 PM Simon Glass  wrote:
>
> We don't expect an exception in TPL and don't need to set up interrupts in
> TPL. Drop this whole file.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4:
> - Drop the whole interrupt file for TPL
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/cpu/i386/Makefile | 2 ++
>  1 file changed, 2 insertions(+)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 020/102] x86: power: Add an ACPI PMC uclass

[Bin Meng]

On Sat, Dec 7, 2019 at 12:46 PM Simon Glass  wrote:
>
> Intel x86 SoCs have a power manager/controller which handles several
> power-related aspects of the platform. Add a uclass for this, with a few
> useful operations.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4:
> - Fix alpha order in Kconfig
> - Switch over to use pinctrl for pad init/config
>
> Changes in v3:
> - Rename power-mgr uclass to acpi-pmc
>
> Changes in v2: None
>
>  drivers/power/Kconfig|   2 +
>  drivers/power/acpi_pmc/Kconfig   |  25 +++
>  drivers/power/acpi_pmc/Makefile  |   5 +
>  drivers/power/acpi_pmc/acpi-pmc-uclass.c | 188 +++
>  include/dm/uclass-id.h   |   1 +
>  include/power/acpi_pmc.h | 185 ++
>  6 files changed, 406 insertions(+)
>  create mode 100644 drivers/power/acpi_pmc/Kconfig
>  create mode 100644 drivers/power/acpi_pmc/Makefile
>  create mode 100644 drivers/power/acpi_pmc/acpi-pmc-uclass.c
>  create mode 100644 include/power/acpi_pmc.h
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 016/102] x86: timer: use a timer base of 0

[Bin Meng]

On Sat, Dec 7, 2019 at 12:46 PM Simon Glass  wrote:
>
> On x86 platforms the timer is reset to 0 when the SoC is reset. Having
> this as the timer base is useful since it provides an indication of how
> long it takes before U-Boot is running.
>
> When U-Boot sets the timer base to something else, time is lost and we
> no-longer have an accurate account of the time since reset. This
> particularly affects bootstage.
>
> Change the default to not read the timer base, leaving it at 0. Add an
> option for when U-Boot is the secondary bootloader.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4:
> - Enable option for slimbootloader, coreboot, efi
> - Reverse the sense of the CONFIG option
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/cpu/coreboot/Kconfig   |  1 +
>  arch/x86/cpu/slimbootloader/Kconfig |  1 +
>  drivers/timer/Kconfig   | 14 ++
>  drivers/timer/tsc_timer.c   |  3 ++-
>  lib/efi/Kconfig |  1 +
>  5 files changed, 19 insertions(+), 1 deletion(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 018/102] x86: Drop unnecessary cpu code for TPL

[Bin Meng]

On Sat, Dec 7, 2019 at 12:46 PM Simon Glass  wrote:
>
> We don't need to know every detail about the CPU in TPL. Drop some
> superfluous functions to reduce code size. Add a simple CPU detection
> algorithm which just supports Intel and AMD, since we only support TPL
> on Intel, so far.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4:
> - Drop 'if (0)' call to deep_magic_nexgen_probe() and use #ifndef instead
> - Fix 'what' typo
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/cpu/cpu.c  |  4 
>  arch/x86/cpu/i386/cpu.c | 41 +
>  2 files changed, 41 insertions(+), 4 deletions(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 017/102] x86: timer: Reduce timer code size in TPL on Intel CPUs

[Bin Meng]

On Sat, Dec 7, 2019 at 12:46 PM Simon Glass  wrote:
>
> Most of the timer-calibration methods are not needed on recent Intel CPUs
> and just increase code size. Add an option to use the known-good way to
> get the clock frequency in TPL. Size reduction is about 700 bytes.
>
> Note that version 1 of this commit caused bootstage to crash since the CPU
> was not identified. This is corrected by changes previously applied to
> make sure that the CPU is identified before spl_init() is called, such as
>
>39146a2e0b x86: Move CPU init to before spl_init()
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4:
> - Update commit message to indicate that CPU-identity bug is fixed
>
> Changes in v3: None
> Changes in v2: None
>
>  drivers/timer/Kconfig | 9 +
>  drivers/timer/tsc_timer.c | 7 +--
>  2 files changed, 14 insertions(+), 2 deletions(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 012/102] dm: pinctrl: Allow enabling full pinctrl in SPL/TPL

[Bin Meng]

On Sun, Dec 8, 2019 at 10:04 AM Bin Meng  wrote:
>
> On Sat, Dec 7, 2019 at 12:46 PM Simon Glass  wrote:
> >
> > At present these options cannot be enabled for SPL/TPL, but this can be
> > useful in some cases. Add Kconfig options to allow it.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > Changes in v6:
> > - Split out Kconfig change to new patch to enable full pinctrl in SPL/TPL
> >
> > Changes in v5: None
> > Changes in v4: None
> > Changes in v3: None
> > Changes in v2: None
> >
> >  drivers/pinctrl/Kconfig | 14 ++
> >  1 file changed, 14 insertions(+)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 013/102] board_r: Move early-timer init later

[Bin Meng]

On Sun, Dec 8, 2019 at 10:06 AM Bin Meng  wrote:
>
> On Sat, Dec 7, 2019 at 12:46 PM Simon Glass  wrote:
> >
> > At present the early timer init happens as soon as driver model is set up.
> > This makes it impossible to do anything that needs driver model but must
> > run before devices are probed (as needed with Intel's FSP-S, for example).
> >
> > In any case it is not a good idea to tie probing of particular drivers too
> > closely to the DM init.
> >
> > Create a new function to init the timer and put it a bit later in the
> > sequence.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > Changes in v6: None
> > Changes in v5: None
> > Changes in v4:
> > - Add new patch to move early-timer init later
> >
> > Changes in v3: None
> > Changes in v2: None
> >
> >  common/board_r.c | 19 ++-
> >  1 file changed, 14 insertions(+), 5 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 013/102] board_r: Move early-timer init later

[Bin Meng]

On Sat, Dec 7, 2019 at 12:46 PM Simon Glass  wrote:
>
> At present the early timer init happens as soon as driver model is set up.
> This makes it impossible to do anything that needs driver model but must
> run before devices are probed (as needed with Intel's FSP-S, for example).
>
> In any case it is not a good idea to tie probing of particular drivers too
> closely to the DM init.
>
> Create a new function to init the timer and put it a bit later in the
> sequence.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4:
> - Add new patch to move early-timer init later
>
> Changes in v3: None
> Changes in v2: None
>
>  common/board_r.c | 19 ++-
>  1 file changed, 14 insertions(+), 5 deletions(-)
>

Reviewed-by: Bin Meng 

Re: [PATCH v6 012/102] dm: pinctrl: Allow enabling full pinctrl in SPL/TPL

[Bin Meng]

On Sat, Dec 7, 2019 at 12:46 PM Simon Glass  wrote:
>
> At present these options cannot be enabled for SPL/TPL, but this can be
> useful in some cases. Add Kconfig options to allow it.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v6:
> - Split out Kconfig change to new patch to enable full pinctrl in SPL/TPL
>
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
>  drivers/pinctrl/Kconfig | 14 ++
>  1 file changed, 14 insertions(+)
>

Reviewed-by: Bin Meng 

Re: [PATCH v6 011/102] fdt: Show the preprocessed .dts file on error

[Bin Meng]

On Sat, Dec 7, 2019 at 12:46 PM Simon Glass  wrote:
>
> When device-tree compilation fails it is sometimes tricky to see which
> line is broken, since the input file to dtc is a pre-processed version
> of the device tree.
>
> Add a line that points to the file that needs to be checked:
>
> When the error is in the main .dts file, output is something like this:
>
>output: 'Error: arch/x86/dts/.chromebook_coral.dtb.pre.tmp:478.46-47
> syntax error
>FATAL ERROR: Unable to parse input tree
>
> but in fact looking at that file shows nothing useful:
>
>PAD_CFG_NF_IOSSTATE_IOSTERM(GPIO_157, UP_20K, DEEP, NF1, HIZCRX1, DISPUPD)
>
> Instead we need to look at the preprocessed file, which shows:
>
>163 ((1U << 30) | (1 << 10)) ((0xb << 10) | PAD_CFG1_IOSSTATE_HIZCRX1)
>
> Here it is clear that PAD_CFG1_IOSSTATE_HIZCRX1 is not defined and so is
> not being resolved by the preprocessor.
>
> This commit adds an additional useful message:
>
>Check arch/x86/dts/.chromebook_coral.dtb.dts.tmp for errors
>
> Note that if the error is reported in an included file, such as
> u-boot.dtsi then the output is the following:
>
>Error: arch/x86/dts/u-boot.dtsi:137.14-15 syntax error
>FATAL ERROR: Unable to parse input tree
>
> But again, if the error is due to a preprocessor failure, like this:
>
>filename = CONFIG_IFW_INPUT_FILE;
>
> then you can't tell what the problem is by looking at the source. All you
> see is the original code:
>
> intel-ifwi {
> filename = CONFIG_IFW_INPUT_FILE;
> ...
> };
> };
> intel-fsp-m {
> filename = CONFIG_FSP_FILE_M;
> };
>
> Everything looks fine. But looking at the output of the preprocessor:
>
>  intel-ifwi {
>   filename = CONFIG_IFW_INPUT_FILE;
>   ...
>  };
>  intel-fsp-m {
>   filename = "fsp_m.bin";
>  };
>
> This shows that the filename (normally "fitimage.bin") has not been
> inserted the preprocess, leading to the realisation that the value should
> be CONFIG_IFWI_INPUT_FILE.
>
> If the above does not make sense, I encourage people to try introducing
> errors in the device tree preprocessed values.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4:
> - One last desperate attempt to try to explain the purpose of this commit
> - Update the message to mention the preprocessed file, not un-preprocessed
>
> Changes in v3:
> - Update example error message to better show the intended purpose
>
> Changes in v2: None
>
>  scripts/Makefile.lib | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 010/102] x86: spi: Add helper functions for Intel Fast SPI

[Bin Meng]

On Sat, Dec 7, 2019 at 12:46 PM Simon Glass  wrote:
>
> Most x86 CPUs use a mechanism where the SPI flash is mapped into the very
> top of 32-bit address space, so that it can be executed in place and read
> simply by copying from memory. For an 8MB ROM the mapping starts at
> 0xff80.
>
> However some recent Intel CPUs do not use a simple 1:1 memory map. Instead
> the map starts at a different address and not all of the SPI flash is
> accessible through the map. This 'Fast SPI' feature requires that U-Boot
> check the location of the map. It is also possible (optionally) to read
> from the SPI flash using a driver.
>
> Add support for booting from Fast SPI. The memory-mapped version is used
> by both TPL and SPL on Apollo Lake.
>
> In respect of a SPI flash driver, the actual SPI driver is ich.c - this
> just adds a few helper functions and definitions.
>
> This is used by Apollo Lake.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3:
> - Add support for of-platdata for TPL
> - Add the missing header file
> - Change Fast-SPI driver into a helper file used by ICH SPI
> - Don't include write() and erase() in TPL
> - Drop 'a4' comment for register offset
> - Merge in patch "x86: Add support for booting from Fast SPI"
> - Reorder file so that write() and erase() are together
> - Use pci_get_devfn()
>
> Changes in v2: None
>
>  arch/x86/cpu/intel_common/Makefile   |  1 +
>  arch/x86/cpu/intel_common/fast_spi.c | 73 
>  arch/x86/include/asm/fast_spi.h  | 68 ++
>  arch/x86/include/asm/spl.h   |  1 +
>  4 files changed, 143 insertions(+)
>  create mode 100644 arch/x86/cpu/intel_common/fast_spi.c
>  create mode 100644 arch/x86/include/asm/fast_spi.h
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 009/102] i2c: designware: Support use in SPL

[Bin Meng]

On Sat, Dec 7, 2019 at 12:46 PM Simon Glass  wrote:
>
> Allow this driver to set up an IO address in SPL using an 'early-regs'
> property. This allows SPL to use the I2C driver without having to enable
> the full PCI stack.
>
> Also split out ofdata_to_platdata in designware driver since this is more
> correct, and more convenient for the new logic.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6:
> - Move lpss_reset_release() to another commit
>
> Changes in v5: None
> Changes in v4:
> - Add new patch to allow designware I2C driver to work in SPL
>
> Changes in v3: None
> Changes in v2: None
>
>  drivers/i2c/designware_i2c_pci.c | 43 +---
>  1 file changed, 40 insertions(+), 3 deletions(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 008/102] i2c: designware: Avoid using static data

[Bin Meng]

On Sun, Dec 8, 2019 at 9:54 AM Bin Meng  wrote:
>
> On Sat, Dec 7, 2019 at 12:46 PM Simon Glass  wrote:
> >
> > Drivers are not allowed to use static data since they may be used in SPL
> > where BSS is not available.
> >
> > It is possible that driver model may provide support for numbering devices
> > in the future. But for now, move this to global_data.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > Changes in v6: None
> > Changes in v5: None
> > Changes in v4:
> > - Add new patch to drop static data in designware i2c driver
> >
> > Changes in v3: None
> > Changes in v2: None
> >
> >  arch/x86/include/asm/global_data.h | 1 +
> >  drivers/i2c/designware_i2c_pci.c   | 9 ++---
> >  2 files changed, 7 insertions(+), 3 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 007/102] i2c: designware: Tidy up PCI support

[Bin Meng]

On Sun, Dec 8, 2019 at 9:52 AM Bin Meng  wrote:
>
> On Sat, Dec 7, 2019 at 12:46 PM Simon Glass  wrote:
> >
> > This is hacked into the driver at present. It seems better to have it as
> > a separate driver that uses the base driver. Create a new file and put
> > the X86 code into it.
> >
> > Actually the Baytrail settings should really come from the device tree.
> >
> > Note that 'has_max_speed' is added as well. This is currently always false
> > but since only Baytrail provides the config, it does not affect operation
> > for other devices.
> >
> > Signed-off-by: Simon Glass 
> > Reviewed-by: Heiko Schocher 
> > ---
> >
> > Changes in v6:
> > - Drop unwanted space before comma
> >
> > Changes in v5: None
> > Changes in v4:
> > - Add a comment about the speed logic in __dw_i2c_set_bus_speed()
> > - Add a comment in the commit message about why has_max_speed is added
> > - Drop unwanted debug printf("bad\n")
> > - Fix indentation nit
> > - Rename new file to designware_i2c_pci.c
> >
> > Changes in v3: None
> > Changes in v2: None
> >
> >  drivers/i2c/Makefile |   3 +
> >  drivers/i2c/designware_i2c.c | 106 +--
> >  drivers/i2c/designware_i2c.h |  35 ++
> >  drivers/i2c/designware_i2c_pci.c |  79 +++
> >  4 files changed, 134 insertions(+), 89 deletions(-)
> >  create mode 100644 drivers/i2c/designware_i2c_pci.c
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 008/102] i2c: designware: Avoid using static data

[Bin Meng]

On Sat, Dec 7, 2019 at 12:46 PM Simon Glass  wrote:
>
> Drivers are not allowed to use static data since they may be used in SPL
> where BSS is not available.
>
> It is possible that driver model may provide support for numbering devices
> in the future. But for now, move this to global_data.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4:
> - Add new patch to drop static data in designware i2c driver
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/x86/include/asm/global_data.h | 1 +
>  drivers/i2c/designware_i2c_pci.c   | 9 ++---
>  2 files changed, 7 insertions(+), 3 deletions(-)
>

Reviewed-by: Bin Meng 

Re: [PATCH v6 007/102] i2c: designware: Tidy up PCI support

[Bin Meng]

On Sat, Dec 7, 2019 at 12:46 PM Simon Glass  wrote:
>
> This is hacked into the driver at present. It seems better to have it as
> a separate driver that uses the base driver. Create a new file and put
> the X86 code into it.
>
> Actually the Baytrail settings should really come from the device tree.
>
> Note that 'has_max_speed' is added as well. This is currently always false
> but since only Baytrail provides the config, it does not affect operation
> for other devices.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Heiko Schocher 
> ---
>
> Changes in v6:
> - Drop unwanted space before comma
>
> Changes in v5: None
> Changes in v4:
> - Add a comment about the speed logic in __dw_i2c_set_bus_speed()
> - Add a comment in the commit message about why has_max_speed is added
> - Drop unwanted debug printf("bad\n")
> - Fix indentation nit
> - Rename new file to designware_i2c_pci.c
>
> Changes in v3: None
> Changes in v2: None
>
>  drivers/i2c/Makefile |   3 +
>  drivers/i2c/designware_i2c.c | 106 +--
>  drivers/i2c/designware_i2c.h |  35 ++
>  drivers/i2c/designware_i2c_pci.c |  79 +++
>  4 files changed, 134 insertions(+), 89 deletions(-)
>  create mode 100644 drivers/i2c/designware_i2c_pci.c
>

Reviewed-by: Bin Meng 

Re: [PATCH v6 006/102] net: Move the checksum functions to lib/

[Bin Meng]

On Sun, Dec 8, 2019 at 9:10 AM Bin Meng  wrote:
>
> On Sat, Dec 7, 2019 at 12:46 PM Simon Glass  wrote:
> >
> > These functions are used by code outside the network support, so move them
> > to lib/ to be more accessible.
> >
> > Without this, the functions are only accessible in SPL/TPL only if
> > CONFIG_SPL/TPL_NET are defined. Many boards do not enable those option but
> > still want to do checksums in this format.
> >
> > Fix up a few code-style nits while we are here.
> >
> > Signed-off-by: Simon Glass 
> > Acked-by: Joe Hershberger 
> > ---
> >
> > Changes in v6:
> > - Expand commit message to mention SPL/TPL specifically
> >
> > Changes in v5: None
> > Changes in v4:
> > - Expand commit message to better explain the need to checksum functions
> >
> > Changes in v3: None
> > Changes in v2: None
> >
> >  lib/Makefile|  2 +-
> >  lib/net_utils.c | 48 
> >  net/Makefile|  1 -
> >  net/checksum.c  | 59 -
> >  4 files changed, 49 insertions(+), 61 deletions(-)
> >  delete mode 100644 net/checksum.c
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 006/102] net: Move the checksum functions to lib/

[Bin Meng]

On Sat, Dec 7, 2019 at 12:46 PM Simon Glass  wrote:
>
> These functions are used by code outside the network support, so move them
> to lib/ to be more accessible.
>
> Without this, the functions are only accessible in SPL/TPL only if
> CONFIG_SPL/TPL_NET are defined. Many boards do not enable those option but
> still want to do checksums in this format.
>
> Fix up a few code-style nits while we are here.
>
> Signed-off-by: Simon Glass 
> Acked-by: Joe Hershberger 
> ---
>
> Changes in v6:
> - Expand commit message to mention SPL/TPL specifically
>
> Changes in v5: None
> Changes in v4:
> - Expand commit message to better explain the need to checksum functions
>
> Changes in v3: None
> Changes in v2: None
>
>  lib/Makefile|  2 +-
>  lib/net_utils.c | 48 
>  net/Makefile|  1 -
>  net/checksum.c  | 59 -
>  4 files changed, 49 insertions(+), 61 deletions(-)
>  delete mode 100644 net/checksum.c
>

Reviewed-by: Bin Meng 

Re: [PATCH v6 005/102] dm: pci: Move pci_get_devfn() into a common file

[Bin Meng]

On Sat, Dec 7, 2019 at 12:46 PM Simon Glass  wrote:
>
> Early in boot it is necessary to decode the PCI device/function values for
> particular peripherals in the device tree or of-platdata. This is needed
> in TPL where CONFIG_PCI is not defined.
>
> To handle this, move pci_get_devfn() into a file that is built even when
> CONFIG_PCI is not defined.
>
> Also add a function for use by of-platdata, to convert a reg property to
> a pci_dev_t.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6:
> - Rename pci_x86_ofplat_get_devfn() to pci_ofplat_get_devfn() in comment
>
> Changes in v5: None
> Changes in v4:
> - Add more documentation for pci_ofplat_get_devfn()
> - Mention that the return value is pci_dev_t
> - Rename pci_x86_ofplat_get_devfn() to pci_ofplat_get_devfn()
>
> Changes in v3:
> - Move the function to a common file instead of duplicating it
> - Update device type to pci_dev_t
>
> Changes in v2: None
>
>  drivers/core/util.c  | 20 +++
>  drivers/pci/pci-uclass.c | 16 ---
>  include/dm/pci.h | 43 
>  include/pci.h| 12 ++-
>  4 files changed, 65 insertions(+), 26 deletions(-)
>  create mode 100644 include/dm/pci.h
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 003/102] dm: core: Fix offset_to_ofnode() with invalid offset

[Bin Meng]

On Sat, Dec 7, 2019 at 12:45 PM Simon Glass  wrote:
>
> If the offset is -1 this function correctly sets up a null ofnode. But if
> the offset is any other negative number (e.g. -FDT_ERR_BADPATH) then it
> does the wrong thing.
>
> An offset of -1 in ofnode indicates that the ofnode is not valid. Any
> other negative value is not handled by ofnode_valid(). We could of course
> change that function, but it seems much better to always use the same
> value for an invalid node.
>
> Fix it by setting the offset to -1 if it is invalid for any reason.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4:
> - Update the commit message to be clearer, fix 'correct' typo
>
> Changes in v3: None
> Changes in v2: None
>
>  include/dm/ofnode.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 002/102] dm: gpio: Allow control of GPIO uclass in SPL

[Bin Meng]

On Sat, Dec 7, 2019 at 12:45 PM Simon Glass  wrote:
>
> At present if CONFIG_SPL_GPIO_SUPPORT is enabled then the GPIO uclass
> is included in SPL/TPL without any control for boards. Some boards may
> want to disable this to reduce code size where GPIOs are not needed in
> SPL or TPL.
>
> Add a new Kconfig option to permit this. Default it to 'y' so that
> existing boards work correctly.
>
> Change existing uses of CONFIG_DM_GPIO to CONFIG_IS_ENABLED(DM_GPIO) to
> preserve the current behaviour. Also update the 74x164 GPIO driver since
> it cannot build with SPL.
>
> This allows us to remove the hacks in config_uncmd_spl.h and
> Makefile.uncmd_spl (eventually those files should be removed).
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
>
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4:
> - Disable SPL_DM_GPIO on omap35_logic to avoid a build error
>
> Changes in v3: None
> Changes in v2:
> - Fix the Kconfig condition to avoid build errors on snow
>
>  arch/arm/include/asm/omap_gpio.h  |  2 +-
>  arch/arm/mach-at91/include/mach/at91sam9260.h |  2 +-
>  arch/arm/mach-davinci/include/mach/gpio.h |  2 +-
>  arch/arm/mach-omap2/am33xx/board.c|  4 ++--
>  arch/arm/mach-omap2/omap3/board.c |  2 +-
>  arch/arm/mach-omap2/omap5/hwinit.c|  2 +-
>  board/freescale/imx8qm_mek/imx8qm_mek.c   |  2 +-
>  board/freescale/imx8qxp_mek/imx8qxp_mek.c |  2 +-
>  board/gateworks/gw_ventana/Kconfig|  3 +++
>  board/toradex/apalis-imx8/apalis-imx8.c   |  2 +-
>  configs/omap35_logic_defconfig|  1 +
>  drivers/gpio/Kconfig  | 22 +++
>  drivers/gpio/Makefile |  4 +++-
>  drivers/gpio/at91_gpio.c  |  6 ++---
>  drivers/gpio/atmel_pio4.c |  2 +-
>  drivers/gpio/da8xx_gpio.c |  7 +++---
>  drivers/gpio/da8xx_gpio.h |  2 +-
>  drivers/gpio/mxc_gpio.c   |  4 ++--
>  drivers/gpio/mxs_gpio.c   |  4 ++--
>  drivers/gpio/omap_gpio.c  |  6 ++---
>  drivers/gpio/sunxi_gpio.c |  8 +++
>  drivers/i2c/i2c-uclass.c  |  6 ++---
>  drivers/i2c/muxes/pca954x.c   |  4 ++--
>  drivers/mmc/fsl_esdhc_imx.c   | 13 ++-
>  drivers/mmc/omap_hsmmc.c  |  2 +-
>  drivers/net/designware.c  | 10 -
>  drivers/net/designware.h  |  4 ++--
>  drivers/net/fec_mxc.c |  6 ++---
>  drivers/net/fec_mxc.h |  2 +-
>  drivers/net/mvneta.c  |  4 ++--
>  drivers/net/mvpp2.c   |  8 +++
>  drivers/net/sun8i_emac.c  | 12 +-
>  drivers/pci/pci-aardvark.c|  4 ++--
>  drivers/pci/pcie_dw_mvebu.c   |  4 ++--
>  drivers/spi/atmel_spi.c   | 10 -
>  drivers/spi/designware_spi.c  |  4 ++--
>  drivers/tpm/tpm2_tis_spi.c|  2 +-
>  include/config_uncmd_spl.h|  1 -
>  include/configs/at91-sama5_common.h   |  5 +++--
>  include/configs/gw_ventana.h  |  1 -
>  include/configs/mx6ul_14x14_evk.h |  1 +
>  scripts/Makefile.uncmd_spl|  1 -
>  42 files changed, 111 insertions(+), 82 deletions(-)
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 004/102] dm: pci: Allow delaying auto-config until after relocation

[Bin Meng]

On Sat, Dec 7, 2019 at 12:46 PM Simon Glass  wrote:
>
> At present PCI auto-configuration happens in U-Boot both before and after
> relocation. This is a waste of time and may mess up static addresses used
> in board_init_f(). Adjust the code to supporting doing auto-configuration
> once, after relocation, under control of a device-tree property.
>
> This is needed for Apollo Lake for debugging the silicon-init code. Once
> the UART is moved to a different MMIO address the debug UART does not work
> and any debug output in Apollo Lake's arch_fsp_init_r() causes a hang.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5: None
> Changes in v4:
> - Change the behaviour to be a device-tree option
> - apollolake -> Apollo Lake
>
> Changes in v3: None
> Changes in v2: None
>
>  doc/device-tree-bindings/pci/x86-pci.txt | 24 
>  drivers/pci/pci-uclass.c | 15 ++-
>  include/pci.h|  9 -
>  3 files changed, 42 insertions(+), 6 deletions(-)
>  create mode 100644 doc/device-tree-bindings/pci/x86-pci.txt
>

applied to u-boot-x86/next, thanks!

Re: [PATCH v6 001/102] binman: Add a library to access binman entries

[Bin Meng]

On Sat, Dec 7, 2019 at 12:45 PM Simon Glass  wrote:
>
> SPL and TPL can access information about binman entries using link-time
> symbols but this is not available in U-Boot proper. Of course it could be
> made available, but the intention is to just read the device tree.
>
> Add support for this, so that U-Boot can locate entries.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v6: None
> Changes in v5:
> - Fix build errors on some PowerPC boards
>
> Changes in v4:
> - Add comments to functions
>
> Changes in v3: None
> Changes in v2: None
>
>  common/board_r.c | 10 ++
>  include/binman.h | 45 +
>  lib/Kconfig  | 10 ++
>  lib/Makefile |  1 +
>  lib/binman.c | 48 
>  5 files changed, 114 insertions(+)
>  create mode 100644 include/binman.h
>  create mode 100644 lib/binman.c
>

applied to u-boot-x86/next, thanks!

Re: [PATCH 0/2] sandbox: enable UEFI unit tests

[Heinrich Schuchardt]

On 11/9/19 9:39 AM, Heinrich Schuchardt wrote:

This patch series enables the UEFI unit tests on the sandbox.

The first patch add the missing compatible property in the device trees
which is required by on of the unit tests.

The real time clock unit test will fail if the sandbox is openend without
passing a device tree (parameter -D).

A separate series will enable building UEFI binaries for the sandbox and
enable the corresponding UEFI unit tests.

Heinrich Schuchardt (2):
   sandbox: add missing compatible property in device tree
   configs: sandbox: enable CONFIG_CMD_BOOTEFI_SELFTEST

  arch/sandbox/dts/sandbox.dts   | 1 +
  arch/sandbox/dts/sandbox64.dts | 1 +
  configs/sandbox64_defconfig| 1 +
  configs/sandbox_defconfig  | 1 +
  configs/sandbox_flattree_defconfig | 1 +
  configs/sandbox_spl_defconfig  | 1 +
  6 files changed, 6 insertions(+)

--
2.24.0.rc1



Hello Simon,

this patch series is currently assigned to you as maintainer of the
sandbox. I hope you can add it to your next tree.

Best regards

Heinrich

Re: [U-Boot] [PATCH 0/2] Add support for booting EFI FIT images

[Heinrich Schuchardt]

On 11/28/19 8:20 AM, Heinrich Schuchardt wrote:

On 11/27/19 8:45 PM, Cristian Ciocaltea wrote:

On Tue, Nov 26, 2019 at 07:31:39PM +0100, Heinrich Schuchardt wrote:

On 11/24/19 9:11 PM, Cristian Ciocaltea wrote:

Currently the only way to run an EFI binary like GRUB2 is via the
'bootefi' command, which cannot be used in a verified boot scenario.

The obvious solution to this limitation is to add support for
booting FIT images containing those EFI binaries.

The implementation relies on a new image type - IH_OS_EFI - which
can be created by using 'os = "efi"' inside an ITS file:

/ {
  #address-cells = <1>;

  images {
  efi-grub {
  description = "GRUB EFI";
  data = /incbin/("EFI/BOOT/bootarm.efi");
  type = "kernel_noload";
  arch = "arm";
  os = "efi";
  compression = "none";
  load = <0x0>;
  entry = <0x0>;
  hash-1 {
  algo = "sha256";
  };
  };
  };

  configurations {
  default = "config-grub";
  config-grub {
  kernel = "efi-grub";
  signature-1 {
  algo = "sha256,rsa2048";
  sign-images = "kernel";
  };
  };
  };
};

The bootm command has been extended to handle the IH_OS_EFI images.
To enable this feature, a new configuration option has been added:
BOOTM_EFI

I tested the solution using the 'qemu_arm' board:

=> load scsi 0:1 ${kernel_addr_r} efi-image.fit
=> bootm ${kernel_addr_r}#config-grub


Thanks a lot for the patch series which makes good sense to me.

I think we should pass addresses and not strings to cmd/bootefi.c. This
will need a bit of refactoring as already addressed in a comment to
patch 2/2.

Additionally the documentation in doc/uefi/u-boot_on_efi.rst and
doc/uImage.FIT/howto.txt should be updated.

I cc the contributors given by
scripts/get_maintainer.pl -f common/bootm_os.c

Best regards

Heinrich



Thanks for the feedback, Heinrich!

Instead of creating new function(s), I think we could simply extend
   int do_bootefi_image(const char *image_opt)
with a new parameter to hold the fdt address and move here the call
to 'efi_install_fdt()', which is now performed by 'do_bootefi()'.


efi_install_fdt() has to be called for the 'bootefi bootmgr' command too
so the refactoring is a bit more complicated. I have started on that.

The first step is to change efi_install_fdt() to expect the argument as
address instead of a string.

https://github.com/xypron/u-boot-patches/blob/efi-next/0001-efi_loader-pass-address-to-efi_install_fdt.patch


fdt_addr==NULL indicates no device tree supplied by user.

Best regards

Heinrich



However, I'm not sure about changing the data types, i.e. from
'char *' to ulong, for the following reasons:
1. image_opt may have a different meaning in addition to efi address
2. fdt address may not be provided, so we need somehow to detect an >> invalid 
value

Kind regards,
Cristian



Hello Christian,

patch series
efi_loader: prepare for FIT images
https://lists.denx.de/pipermail/u-boot/2019-December/393192.html
is now available. It offers these functions:

/* Install device tree */
efi_status_t efi_install_fdt(uintptr_t fdt_addr);
/* Run loaded UEFI image */
efi_status_t efi_run_image(void *source_buffer, efi_uintn_t source_size);

Could you, please, rebase your patches on this patch series.

Please, call efi_install_fdt with EFI_FDT_USE_INTERNAL if no device tree
is supplied by the FIT image.

The patch series is also available in branch efi-2020-04 at
https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git

Best regards

Heinrich

[PATCH v2 3/4] efi_loader: carve out efi_run_image()

[Heinrich Schuchardt]

Provide public function efi_run_imager() which can be used to run an UEFI
image from memory.

Signed-off-by: Heinrich Schuchardt 
---
 cmd/bootefi.c| 51 +++-
 include/efi_loader.h |  2 ++
 2 files changed, 34 insertions(+), 19 deletions(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index a3e2a05126..15b4ff9515 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -360,11 +360,8 @@ static int do_efibootmgr(void)
 static int do_bootefi_image(const char *image_opt)
 {
void *image_buf;
-   struct efi_device_path *device_path, *image_path;
-   struct efi_device_path *file_path = NULL;
unsigned long addr, size;
const char *size_str;
-   efi_handle_t mem_handle = NULL, handle;
efi_status_t ret;

 #ifdef CONFIG_CMD_BOOTEFI_HELLO
@@ -382,8 +379,10 @@ static int do_bootefi_image(const char *image_opt)
image_buf = map_sysmem(addr, size);
memcpy(image_buf, __efi_helloworld_begin, size);

-   device_path = NULL;
-   image_path = NULL;
+   efi_free_pool(bootefi_device_path);
+   efi_free_pool(bootefi_image_path);
+   bootefi_device_path = NULL;
+   bootefi_image_path = NULL;
} else
 #endif
{
@@ -399,19 +398,37 @@ static int do_bootefi_image(const char *image_opt)
return CMD_RET_USAGE;

image_buf = map_sysmem(addr, size);
-
-   device_path = bootefi_device_path;
-   image_path = bootefi_image_path;
}
+   ret = efi_run_image(image_buf, size);
+
+   if (ret != EFI_SUCCESS)
+   return CMD_RET_FAILURE;
+
+   return CMD_RET_SUCCESS;
+}
+
+/**
+ * efi_run_image() - run loaded UEFI image
+ *
+ * @source_buffer: memory address of the UEFI image
+ * @source_size:   size of the UEFI image
+ * Return: status code
+ */
+efi_status_t efi_run_image(void *source_buffer, efi_uintn_t source_size)
+{
+   efi_handle_t mem_handle = NULL, handle;
+   struct efi_device_path *file_path = NULL;
+   efi_status_t ret;

-   if (!device_path && !image_path) {
+   if (!bootefi_device_path || !bootefi_image_path) {
/*
 * Special case for efi payload not loaded from disk,
 * such as 'bootefi hello' or for example payload
 * loaded directly into memory via JTAG, etc:
 */
file_path = efi_dp_from_mem(EFI_RESERVED_MEMORY_TYPE,
-   (uintptr_t)image_buf, size);
+   (uintptr_t)source_buffer,
+   source_size);
/*
 * Make sure that device for device_path exist
 * in load_image(). Otherwise, shell and grub will fail.
@@ -425,12 +442,12 @@ static int do_bootefi_image(const char *image_opt)
if (ret != EFI_SUCCESS)
goto out;
} else {
-   assert(device_path && image_path);
-   file_path = efi_dp_append(device_path, image_path);
+   file_path = efi_dp_append(bootefi_device_path,
+ bootefi_image_path);
}

-   ret = EFI_CALL(efi_load_image(false, efi_root,
- file_path, image_buf, size, ));
+   ret = EFI_CALL(efi_load_image(false, efi_root, file_path, source_buffer,
+ source_size, ));
if (ret != EFI_SUCCESS)
goto out;

@@ -441,11 +458,7 @@ out:
efi_delete_handle(mem_handle);
if (file_path)
efi_free_pool(file_path);
-
-   if (ret != EFI_SUCCESS)
-   return CMD_RET_FAILURE;
-
-   return CMD_RET_SUCCESS;
+   return ret;
 }

 #ifdef CONFIG_CMD_BOOTEFI_SELFTEST
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 3a22089329..1e1fe52bc0 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -341,6 +341,8 @@ extern struct list_head efi_register_notify_events;

 /* Initialize efi execution environment */
 efi_status_t efi_init_obj_list(void);
+/* Run loaded UEFI image */
+efi_status_t efi_run_image(void *source_buffer, efi_uintn_t source_size);
 /* Initialize variable services */
 efi_status_t efi_init_variables(void);
 /* Notify ExitBootServices() is called */
--
2.24.0

[PATCH v2 1/4] efi_loader: pass address to efi_install_fdt()

[Heinrich Schuchardt]

As part of moving the parsing of command line arguments to do_bootefi()
call efi_install_fdt() with the address of the device tree instead of a
string.

If the address is EFI_FDT_USE_INTERNAL (= 0), the internal device tree
is used.

Signed-off-by: Heinrich Schuchardt 
---
 cmd/bootefi.c| 32 ++--
 include/efi_loader.h |  3 +++
 2 files changed, 21 insertions(+), 14 deletions(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index f613cce7e2..2b190a3edd 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -196,40 +196,39 @@ static void *get_config_table(const efi_guid_t *guid)
 #endif /* !CONFIG_IS_ENABLED(GENERATE_ACPI_TABLE) */

 /**
- * efi_install_fdt() - install fdt passed by a command argument
+ * efi_install_fdt() - install device tree
  *
- * If fdt_opt is available, the device tree located at that memory address will
+ * If fdt_addr is available, the device tree located at that memory address 
will
  * will be installed as configuration table, otherwise the device tree located
  * at the address indicated by environment variable fdtcontroladdr will be 
used.
  *
- * On architectures (x86) using ACPI tables device trees shall not be installed
- * as configuration table.
+ * On architectures using ACPI tables device trees shall not be installed as
+ * configuration table.
  *
- * @fdt_opt:   pointer to argument
+ * @fdt_addr:  address of device tree or EFI_FDT_USE_INTERNAL to use the
+ * internal device tree as indicated by environment variable
+ * fdtcontroladdr
  * Return: status code
  */
-static efi_status_t efi_install_fdt(const char *fdt_opt)
+static efi_status_t efi_install_fdt(uintptr_t fdt_addr)
 {
/*
 * The EBBR spec requires that we have either an FDT or an ACPI table
 * but not both.
 */
 #if CONFIG_IS_ENABLED(GENERATE_ACPI_TABLE)
-   if (fdt_opt) {
+   if (fdt_addr) {
printf("ERROR: can't have ACPI table and device tree.\n");
return EFI_LOAD_ERROR;
}
 #else
-   unsigned long fdt_addr;
void *fdt;
bootm_headers_t img = { 0 };
efi_status_t ret;

-   if (fdt_opt) {
-   fdt_addr = simple_strtoul(fdt_opt, NULL, 16);
-   if (!fdt_addr)
-   return EFI_INVALID_PARAMETER;
-   } else {
+   if (fdt_addr == EFI_FDT_USE_INTERNAL) {
+   const char *fdt_opt;
+
/* Look for device tree that is already installed */
if (get_config_table(_guid_fdt))
return EFI_SUCCESS;
@@ -556,6 +555,7 @@ static int do_efi_selftest(void)
 static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
argv[])
 {
efi_status_t ret;
+   uintptr_t fdt_addr;

if (argc < 2)
return CMD_RET_USAGE;
@@ -568,7 +568,11 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int 
argc, char * const argv[])
return CMD_RET_FAILURE;
}

-   ret = efi_install_fdt(argc > 2 ? argv[2] : NULL);
+   if (argc > 2)
+   fdt_addr = simple_strtoul(argv[2], NULL, 16);
+   else
+   fdt_addr = EFI_FDT_USE_INTERNAL;
+   ret = efi_install_fdt(fdt_addr);
if (ret == EFI_INVALID_PARAMETER)
return CMD_RET_USAGE;
else if (ret != EFI_SUCCESS)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 16a1b258b1..3a22089329 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -34,6 +34,9 @@ static inline int guidcmp(const void *g1, const void *g2)
EFI_GUID(0xbbe4e671, 0x5773, 0x4ea1, \
 0x9a, 0xab, 0x3a, 0x7d, 0xbf, 0x40, 0xc4, 0x82)

+/* Use internal device tree when starting UEFI application */
+#define EFI_FDT_USE_INTERNAL 0UL
+
 /* Root node */
 extern efi_handle_t efi_root;

--
2.24.0

[PATCH v2 4/4] efi_loader: export efi_install_fdt()

[Heinrich Schuchardt]

Export the efi_install_fdt() function.

Signed-off-by: Heinrich Schuchardt 
---
 cmd/bootefi.c| 2 +-
 include/efi_loader.h | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 15b4ff9515..9d9019c269 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -212,7 +212,7 @@ static void *get_config_table(const efi_guid_t *guid)
  * the environment variable fdtcontroladdr
  * Return: status code
  */
-static efi_status_t efi_install_fdt(uintptr_t fdt_addr)
+efi_status_t efi_install_fdt(uintptr_t fdt_addr)
 {
/*
 * The EBBR spec requires that we have either an FDT or an ACPI table
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 1e1fe52bc0..ca50953272 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -341,6 +341,8 @@ extern struct list_head efi_register_notify_events;

 /* Initialize efi execution environment */
 efi_status_t efi_init_obj_list(void);
+/* Install device tree */
+efi_status_t efi_install_fdt(uintptr_t fdt_addr);
 /* Run loaded UEFI image */
 efi_status_t efi_run_image(void *source_buffer, efi_uintn_t source_size);
 /* Initialize variable services */
--
2.24.0

[PATCH v2 2/4] efi_loader: use hardware device tree by default

[Heinrich Schuchardt]

If the bootefi command is called without passing the address of a device
tree, the internal device tree is used. For devices with a hardware device
tree it is preferable to used the hardware device tree in this case.

Signed-off-by: Heinrich Schuchardt 
---
 cmd/bootefi.c | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 2b190a3edd..a3e2a05126 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -200,14 +200,16 @@ static void *get_config_table(const efi_guid_t *guid)
  *
  * If fdt_addr is available, the device tree located at that memory address 
will
  * will be installed as configuration table, otherwise the device tree located
- * at the address indicated by environment variable fdtcontroladdr will be 
used.
+ * at the address indicated by environment variable fdt_addr or as fallback
+ * fdtcontroladdr will be used.
  *
  * On architectures using ACPI tables device trees shall not be installed as
  * configuration table.
  *
  * @fdt_addr:  address of device tree or EFI_FDT_USE_INTERNAL to use the
- * internal device tree as indicated by environment variable
- * fdtcontroladdr
+ * the hardware device tree as indicated by environment variable
+ * fdt_addr or as fallback the internal device tree as indicated by
+ * the environment variable fdtcontroladdr
  * Return: status code
  */
 static efi_status_t efi_install_fdt(uintptr_t fdt_addr)
@@ -232,15 +234,19 @@ static efi_status_t efi_install_fdt(uintptr_t fdt_addr)
/* Look for device tree that is already installed */
if (get_config_table(_guid_fdt))
return EFI_SUCCESS;
-   /* Use our own device tree as default */
-   fdt_opt = env_get("fdtcontroladdr");
+   /* Check if there is a hardware device tree */
+   fdt_opt = env_get("fdt_addr");
+   /* Use our own device tree as fallback */
if (!fdt_opt) {
-   printf("ERROR: need device tree\n");
-   return EFI_NOT_FOUND;
+   fdt_opt = env_get("fdtcontroladdr");
+   if (!fdt_opt) {
+   printf("ERROR: need device tree\n");
+   return EFI_NOT_FOUND;
+   }
}
fdt_addr = simple_strtoul(fdt_opt, NULL, 16);
if (!fdt_addr) {
-   printf("ERROR: invalid $fdtcontroladdr\n");
+   printf("ERROR: invalid $fdt_addr or $fdtcontroladdr\n");
return EFI_LOAD_ERROR;
}
}
--
2.24.0

[PATCH v2 0/4] efi_loader: prepare for FIT images

[Heinrich Schuchardt]

A patch series has been suggested to provide secure UEFI boot via FIT
images.

This patch series exports the functions needed for the implementation.

v2:
Resend the efi_install_fdt() rework patches.
Export the efi_run_image() and efi_install_fdt().

Heinrich Schuchardt (4):
  efi_loader: pass address to efi_install_fdt()
  efi_loader: use hardware device tree by default
  efi_loader: carve out efi_run_image()
  efi_loader: export efi_install_fdt()

 cmd/bootefi.c| 101 ++-
 include/efi_loader.h |   7 +++
 2 files changed, 69 insertions(+), 39 deletions(-)

--
2.24.0

[PATCH 1/1] linux/types.h: fix typo unchar

[Heinrich Schuchardt]

unsigned char should be called uchar and not unchar.

This fixes a build error in lib/crypto/x509_cert_parser.c.

Signed-off-by: Heinrich Schuchardt 
---
 include/linux/types.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/types.h b/include/linux/types.h
index 51cb284bb8..bd912bcb42 100644
--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -85,7 +85,7 @@ typedef unsigned int  u_int;
 typedef unsigned long  u_long;

 /* sysv */
-typedef unsigned char  unchar;
+typedef unsigned char  uchar;
 typedef unsigned short ushort;
 typedef unsigned int   uint;
 typedef unsigned long  ulong;
--
2.20.1

Re: [U-Boot-Board-Maintainers] Raspberry pi 4 - u-boot - genet / scb

[Sascha Dewald]

Hmm, looks like the google webmail doesn't send multi-mime messages.
I didn't know that yet.

And if there is no progress, then i would look for another solution.
No problem :-)

Am Sa., 7. Dez. 2019 um 10:27 Uhr schrieb Andreas Färber :
>
> Sascha,
>
> Am 07.12.19 um 07:23 schrieb Sascha Dewald:
> > Hello,
> >
> > is there any progress yet ?
>
> There is absolutely no reason to annoy all the board maintainers on this
> mailing list with nagging about an unimplemented driver for one board!
> Especially not with HTML mail and top-posting!!! Please take this
> discussion to the u-boot mailing list (Reply-to set).
>
> Regards,
> Andreas
>
> > Am Fr., 22. Nov. 2019 um 00:27 Uhr schrieb André Przywara
> > mailto:andre.przyw...@arm.com>>:
> >
> > On 21/11/2019 21:46, Sascha Dewald wrote:
> >
> > Hi,
> >
> > > could someone give me a summary which is missing in u-boot and what
> > > needs to be ported ?
> >
> > The PHY is pretty much standard and already supported, as far as I can
> > see, the MAC is not.
> >
> > > I found other broadcom drivers, which are already in u-boot.
> >
> > The RPi4 uses a Broadcom GENETv5 IP (with a slight tweak). The Linux
> > driver is quite sophisticated: it supports older revisions (v1..v4),
> > makes clever use of multiple priority queues and is of course fully
> > interrupt driven, including napi shortcuts, also enjoys all the glory of
> > the full Linux driver framework galore.
> > For U-Boot we can get away with a MUCH simpler driver. Amit and I spent
> > a while understanding the hardware based on the Linux driver, and Amit
> > saw the first ARP packet from U-Boot on his laptop yesterday. He is
> > currently working on the recv() function.
> >
> > > How difficult is it, to strip the drivers down, from the linux
> > kernel to
> > > work with u-boot?
> >
> > As mentioned, stripping the driver down (as in copying and editing) is
> > not a good idea, but the basic driver is already somewhat working
> > (probing, instantiation, sending packets), so we are not far away.
> >
> > If I could ask for just for a few more days of patience, then I am
> > looking forward for your help with review and testing!
> >
> > Cheers,
> > Andre
> >
> > > Am Mi., 20. Nov. 2019 um 12:21 Uhr schrieb Andre Przywara
> > > mailto:andre.przyw...@arm.com>
> > >>:
> > >
> > > On Wed, 20 Nov 2019 12:13:55 +0100
> > > Matthias Brugger mailto:mbrug...@suse.com>
> > >> wrote:
> > >
> > > Hi,
> > >
> > > > Adding Andre as he helps in the effort to port the driver. More
> > > comments inline.
> > > >
> > > > On 19/11/2019 22:46, Heinrich Schuchardt wrote:
> > > > > On 11/19/19 9:48 PM, Simon Glass wrote:
> > > > >> Hi Sascha,
> > > > >>
> > > > >> On Tue, 19 Nov 2019 at 10:10, Sascha Dewald
> > > mailto:sascha.dew...@gmail.com>
> > >>
> > wrote:
> > > > >>>
> > > > >>> Hi Simon,
> > > > >>>
> > > > >>> it uses bcmgenet.
> > > > >>>
> > > > >>> Below some information from "hwinfo" and "dmesg"
> > > > >>>
> > > > >>
> > > > >> OK, well I think this is in linux as
> > > drivers/net/ethernet/broadcom/genet
> > > > >>
> > > > >> I'm not sure about the PHY but it looks like there is no
> > driver for
> > > > >> genet in U-Boot. I suggest poriting it over.
> > >
> > > Amit (CC:ed) is working on that. That is still quite rough and not
> > > really working yet, but as of yesterday he saw the first (empty)
> > > packets on the line at least.
> > > I would assume we get something working still this year.
> > >
> > > > > In linux-next/next-20191119
> > > > > arch/arm64/boot/dts/broadcom/bcm2711-rpi-4-b.dtb
> > > > > there is no network device.
> > > > >
> > > > Florian send a new pull request, I think yesterday which
> > adds the
> > > genet driver
> > > > to RPi4.
> > >
> > > I found the burst length quirk together with the new compatible
> > > string in David's net-next/master two days ago.
> > >
> > > > > On Raspbian you can find for RPi4:
> > > > >
> > > > > compatible = "brcm,genet-v5"
> > > > > relating to Linux
> > drivers/net/ethernet/broadcom/genet/bcmgenet.c
> > > > > CONFIG_BCMGENET "Broadcom GENET internal MAC support"
> > > > >
> > > >
> > > > RPi4 is a special case as DMA burst size is different from plain
> > > genet-v5
> > > > driver. But that might be of no relevance for U-Boot.
> > >
> >   

Re: [U-Boot] [PATCH v3 14/16] lib: crypto: add x509 parser

[Tom Rini]

On Sat, Dec 07, 2019 at 09:51:22PM +0100, Heinrich Schuchardt wrote:
> On 12/6/19 10:50 PM, Tom Rini wrote:
> > On Wed, Nov 13, 2019 at 09:45:00AM +0900, AKASHI Takahiro wrote:
> > 
> > > Imported from linux kernel v5.3:
> > >   x509.asn1 without changes
> > >   x509_akid.asn1 without changes
> > >   x509_parser.h without changes
> > >   x509_cert_parser.c with changes marked as __UBOOT__
> > >   x509_public_key.c with changes marked as __UBOOT__
> > > 
> > > Signed-off-by: AKASHI Takahiro 
> > 
> > Applied to u-boot/master, thanks!
> > 
> Hello Tom,
> 
> this patch causes a build error for rpi_0_w_defconfig with
> CONFIG_X509_CERTIFICATE_PARSER=y:
> 
> In file included from include/linux/time.h:4,
>  from lib/crypto/x509_parser.h:8,
>  from lib/crypto/x509_cert_parser.c:20:
> include/rtc.h:197:26: error: unknown type name ‘uchar’; did you mean
> ‘unchar’?
>  void rtc_write8(int reg, uchar val);
>   ^
>   unchar
> make[4]: *** [scripts/Makefile.build:279: lib/crypto/x509_cert_parser.o]
> Error 1
> 
> The error is caused by:
> 
> include/linux/types.h:88:typedef unsigned char  unchar;
> 
> I have prepared a patch but will first run it through Gitlab:
> 
> https://gitlab.denx.de/u-boot/custodians/u-boot-efi/commit/f574992867cf40f48a381f88c1ac15a47dbe1baf
> 
> @Takahiro:
> I am wondering why this did not show up in your tests. Did Tom miss a patch?

Only sandbox enables any of this out of the box, which is why I've taken
it at this point in the window.  It's otherwise neutral and as good as
it was going to get prior to inclusion somewhere for wider testing.
Which, thanks for doing.

-- 
Tom


signature.asc
Description: PGP signature

Re: [U-Boot] [PATCH] spl: fix entry_point equal to load_addr

[Simon Goldschmidt]

Hi Tom,

On Fri, Dec 6, 2019 at 3:55 PM Tom Rini  wrote:
>
> On Fri, Dec 06, 2019 at 03:05:55PM +0100, Simon Goldschmidt wrote:
> > On Fri, Dec 6, 2019 at 2:49 PM Giulio Benetti
> >  wrote:
> > >
> > > Hello Tom, all,
> > >
> > > On 12/6/19 2:34 PM, Tom Rini wrote:
> > > > On Fri, Dec 06, 2019 at 01:58:46PM +0100, Simon Goldschmidt wrote:
> > > >> On Fri, Dec 6, 2019 at 1:46 PM Patrice CHOTARD 
> > > >>  wrote:
> > > >>>
> > > >>> Hi
> > > >>>
> > > >>> This patch is breaking the STM32MP15 basic boot (spl => u-boot).
> > > >>
> > > >> Looking at socfpga gen5 u-boot.img, this is probably broken as well.
> > > >>
> > > >> And I don't even see any RB or TB tags here :-(
> > > >
> > > > Ugh, what the heck?  I applied this because I looked over the changes
> > > > and they seemed correct.  I'm quite willing to just revert this but I
> > > > would like to know how it's breaking.  Sorry all!
> > > >
> > >
> > > IMHO this is due to wrong images creation with mkinage, especially when
> > > passing parameters with -a and -e flags.
> > >
> > > In my case I need them to be:
> > > -a 0x80002000 (load address) => CONFIG_SYS_TEXT_BASE
> > > -e 0x800023FD (entry point where SPL jumps to) => CONFIG_SYS_UBOOT_START
> >
> > Well, CONFIG_SYS_UBOOT_START is only set in 15 files in include/configs, so 
> > I
> > guess a lot more boards might be broken...
> >
> > >
> > > So *maybe* on STM32MP1 and other broken boards -e
> > > (CONFIG_SYS_UBOOT_START) is not equal to -a (CONFIG_SYS_TEXT_BASE) as
> > > was assumed before(but wrong).
> > >
> > > Indeed CONFIG_SYS_UBOOT_START is set to 0 if not specified in
> > > u-boot/Makefile:
> > > `
> > > # U-Boot entry point, needed for booting of full-blown U-Boot
> > > # from the SPL U-Boot version.
> > > #
> > > ifndef CONFIG_SYS_UBOOT_START
> > > CONFIG_SYS_UBOOT_START := 0
> > > endif
> > > `
> > >
> > > So probably broken boards try to jump to absolute 0.
> > > A solving patch would be:
> > > ifndef CONFIG_SYS_UBOOT_START
> > > CONFIG_SYS_UBOOT_START := CONFIG_SYS_TEXT_BASE
> > > endif
> >
> > That might work, but I wonder if this is the correct time in the release to 
> > do
> > so.
>
> Yes, at this point in the cycle the best option is to revert the
> original commit and for the next release bring it back after applying
> Patrice's series to fix the bogus default to CONFIG_SYS_UBOOT_START and
> cleaning up defconfigs.  Sorry again for all the troubles!

I just wanted to confirm socfpga_gen5 doesn't boot with this patch
but it's ok again now you reverted it.

Regards,
Simon

Re: [U-Boot] [PATCH v3 14/16] lib: crypto: add x509 parser

[Heinrich Schuchardt]

On 12/6/19 10:50 PM, Tom Rini wrote:

On Wed, Nov 13, 2019 at 09:45:00AM +0900, AKASHI Takahiro wrote:


Imported from linux kernel v5.3:
  x509.asn1 without changes
  x509_akid.asn1 without changes
  x509_parser.h without changes
  x509_cert_parser.c with changes marked as __UBOOT__
  x509_public_key.c with changes marked as __UBOOT__

Signed-off-by: AKASHI Takahiro 


Applied to u-boot/master, thanks!


Hello Tom,

this patch causes a build error for rpi_0_w_defconfig with
CONFIG_X509_CERTIFICATE_PARSER=y:

In file included from include/linux/time.h:4,
 from lib/crypto/x509_parser.h:8,
 from lib/crypto/x509_cert_parser.c:20:
include/rtc.h:197:26: error: unknown type name ‘uchar’; did you mean
‘unchar’?
 void rtc_write8(int reg, uchar val);
  ^
  unchar
make[4]: *** [scripts/Makefile.build:279: lib/crypto/x509_cert_parser.o]
Error 1

The error is caused by:

include/linux/types.h:88:typedef unsigned char  unchar;

I have prepared a patch but will first run it through Gitlab:

https://gitlab.denx.de/u-boot/custodians/u-boot-efi/commit/f574992867cf40f48a381f88c1ac15a47dbe1baf

@Takahiro:
I am wondering why this did not show up in your tests. Did Tom miss a patch?

Best regards

Heinrich