Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
On Saturday 25 February 2023 11:42:20 Martin Rowe wrote:
> This new clearfog_spi_defconfig file is copy of existing
> clearfog_defconfig file and changed to instruct build system to
> generate final kwbimage for SPI booting and to store the
> environment in SPI as well.
>
> Signed-off-by: Martin Rowe
> ---
> .../{clearfog_sata_defconfig => clearfog_spi_defconfig}| 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
> copy configs/{clearfog_sata_defconfig => clearfog_spi_defconfig} (93%)
>
> diff --git a/configs/clearfog_sata_defconfig b/configs/clearfog_spi_defconfig
> similarity index 93%
> copy from configs/clearfog_sata_defconfig
> copy to configs/clearfog_spi_defconfig
> index 84f900bf50..31b1e9fce8 100644
> --- a/configs/clearfog_sata_defconfig
> +++ b/configs/clearfog_spi_defconfig
> @@ -3,20 +3,24 @@ CONFIG_ARCH_CPU_INIT=y
> CONFIG_SYS_THUMB_BUILD=y
> CONFIG_ARCH_MVEBU=y
> CONFIG_TEXT_BASE=0x0080
> +CONFIG_SPL_GPIO=y
> CONFIG_SPL_LIBCOMMON_SUPPORT=y
> CONFIG_SPL_LIBGENERIC_SUPPORT=y
> CONFIG_NR_DRAM_BANKS=2
> CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff
> CONFIG_TARGET_CLEARFOG=y
> -CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y
> +CONFIG_ENV_SECT_SIZE=0x1
> CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog"
> CONFIG_SPL_TEXT_BASE=0x4030
> +CONFIG_SPL_MMC=y
> CONFIG_SPL_SERIAL=y
> CONFIG_SPL_STACK=0x4002c000
> CONFIG_SPL=y
> CONFIG_DEBUG_UART_BASE=0xf1012000
> CONFIG_DEBUG_UART_CLOCK=25000
> +CONFIG_SPL_LIBDISK_SUPPORT=y
> +# CONFIG_SPL_SPI is not set
Any reason to disable it?
> CONFIG_SYS_LOAD_ADDR=0x80
> CONFIG_DEBUG_UART=y
> CONFIG_AHCI=y
> @@ -59,6 +63,7 @@ CONFIG_SYS_I2C_MVTWSI=y
> CONFIG_I2C_EEPROM=y
> CONFIG_SPL_I2C_EEPROM=y
> CONFIG_MMC_BROKEN_CD=y
> +CONFIG_SPL_DM_MMC=y
> CONFIG_SUPPORT_EMMC_BOOT=y
> CONFIG_MMC_SDHCI=y
> CONFIG_MMC_SDHCI_SDMA=y
> --
> 2.39.2
>
Re: [RFC PATCH v3 3/9] clk: renesas: add R906G032 driver
On 2/24/23 19:00, Ralph Siemsen wrote: Hi Marek, On Fri, Feb 24, 2023 at 12:05 PM Marek Vasut wrote: Could you at least submit the clean up to Linux and then sync the result to U-Boot, and indicate the Linux clock table came from commit with extra patch on top ? Yes will do. I am refreshing my linux-side patch as we speak. Thanks !
Re: [PATCH RFC u-boot-mvebu 57/59] arm: mvebu: Define env_sf_get_env_addr() also for Proper U-Boot
Hi Pali,
On Tue, Feb 21, 2023 at 12:22 PM Pali Rohár wrote:
>
> Proper U-Boot moves SPI0 CS0 Flash mapping from 0xD400 to 0xF400
> and change its size from 64 MB to 8 MB. Definitions are already in
> MBUS_SPI_BASE/MBUS_SPI_SIZE macros. So define these macros also for SPL
> build, use them in env_sf_get_env_addr() function and move this function
> from spl.c to cpu.c to be available in Proper U-Boot too.
Interesting! So would it affect the board that has a 4MB SPI flash ?
I know there is a bug somewhere, because I need to set both
CONFIG_ENV_OFFSET and CONFIG_ENV_ADDR. One or the other is not enough.
I'm debugging an error that seemingly has something to do with the SPI
envs area: how u-boot set envs and recalculate checksum, and Linux
fw_setenv() seems to not be doing the same thing. This is on a 4MB SPI
mx25l3205d flash (Thecus N2350 board).
It might also have something to do with a SPI flash being set to some
protected blocks (in the Status Register upon boot).
Thanks,
Tony
>
> Signed-off-by: Pali Rohár
> ---
> arch/arm/mach-mvebu/cpu.c | 9 +
> arch/arm/mach-mvebu/include/mach/cpu.h | 5 +
> arch/arm/mach-mvebu/spl.c | 13 -
> 3 files changed, 14 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c
> index c5089a91c747..97154aaa2a7e 100644
> --- a/arch/arm/mach-mvebu/cpu.c
> +++ b/arch/arm/mach-mvebu/cpu.c
> @@ -35,6 +35,15 @@ static const struct mbus_win windows[] = {
> #endif
> };
>
> +/* SPI0 CS0 Flash of size MBUS_SPI_SIZE is mapped to address MBUS_SPI_BASE */
> +#if CONFIG_ENV_SPI_BUS == 0 && CONFIG_ENV_SPI_CS == 0 && \
> +CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE <= MBUS_SPI_SIZE
> +void *env_sf_get_env_addr(void)
> +{
> + return (void *)MBUS_SPI_BASE + CONFIG_ENV_OFFSET;
> +}
> +#endif
> +
> void lowlevel_init(void)
> {
> /*
> diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h
> b/arch/arm/mach-mvebu/include/mach/cpu.h
> index c17c2440f1b1..906a8737a401 100644
> --- a/arch/arm/mach-mvebu/include/mach/cpu.h
> +++ b/arch/arm/mach-mvebu/include/mach/cpu.h
> @@ -71,8 +71,13 @@ enum cpu_attrib {
> #define MBUS_PCI_MEM_SIZE ((MBUS_PCI_MAX_PORTS * 128) << 20)
> #define MBUS_PCI_IO_BASE 0xF110
> #define MBUS_PCI_IO_SIZE ((MBUS_PCI_MAX_PORTS * 64) << 10)
> +#ifdef CONFIG_SPL_BUILD
> +#define MBUS_SPI_BASE 0xD400
> +#define MBUS_SPI_SIZE (64 << 20)
> +#else
> #define MBUS_SPI_BASE 0xF400
> #define MBUS_SPI_SIZE (8 << 20)
> +#endif
> #define MBUS_DFX_BASE 0xF600
> #define MBUS_DFX_SIZE (1 << 20)
> #define MBUS_BOOTROM_BASE 0xF800
> diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
> index 02528e025d8c..6b8c72a71dab 100644
> --- a/arch/arm/mach-mvebu/spl.c
> +++ b/arch/arm/mach-mvebu/spl.c
> @@ -308,19 +308,6 @@ int board_return_to_bootrom(struct spl_image_info
> *spl_image,
> hang();
> }
>
> -/*
> - * SPI0 CS0 Flash is mapped to address range 0xD400 - 0xD7FF by
> BootROM.
> - * Proper U-Boot removes this direct mapping. So it is available only in SPL.
> - */
> -#if defined(CONFIG_SPL_ENV_IS_IN_SPI_FLASH) && \
> -CONFIG_ENV_SPI_BUS == 0 && CONFIG_ENV_SPI_CS == 0 && \
> -CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE <= 64*1024*1024
> -void *env_sf_get_env_addr(void)
> -{
> - return (void *)0xD400 + CONFIG_ENV_OFFSET;
> -}
> -#endif
> -
> void board_init_f(ulong dummy)
> {
> int ret;
> --
> 2.20.1
>
[PATCH] arm: mvebu: Enable NAND flash for Thecus N2350 board
Enable 512MB PXA3XX NAND flash when u-boot is running. Signed-off-by: Tony Dinh --- configs/n2350_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configs/n2350_defconfig b/configs/n2350_defconfig index b85ef0dfeb..247533ebb8 100644 --- a/configs/n2350_defconfig +++ b/configs/n2350_defconfig @@ -69,6 +69,9 @@ CONFIG_SYS_64BIT_LBA=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_MVTWSI=y CONFIG_MTD=y +CONFIG_MTD_RAW_NAND=y +CONFIG_NAND_PXA3XX=y +CONFIG_SYS_NAND_ONFI_DETECTION=y CONFIG_SF_DEFAULT_SPEED=5000 CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_STMICRO=y -- 2.30.2
Re: [PATCH] kconfig: Proposed language extension for multiple builds
+Masahiro Yamada On Fri, 24 Feb 2023 at 19:04, Simon Glass wrote: > +lk > > On Sun, 19 Feb 2023 at 14:55, Simon Glass wrote: > > > > In the case of Linux, only one build is produced so there is only a > > single configuration. For other projects, such as U-Boot and Zephyr, the > > same code is used to produce multiple builds, each with related (but > > different) options enabled. > > > > This can be handled with the existing kconfig language, but it is quite > > verbose, somewhat tedious and very error-prone, since there is a lot of > > duplication. The result is hard to maintain. > > > > Describe an extension to the Kconfig language to support easier handling > > of this use case. > > > > Signed-off-by: Simon Glass > > --- > > > > Documentation/kbuild/kconfig-language.rst | 134 ++ > > 1 file changed, 134 insertions(+) > > > > diff --git a/Documentation/kbuild/kconfig-language.rst > b/Documentation/kbuild/kconfig-language.rst > > index 858ed5d80defe..73fb016a5533f 100644 > > --- a/Documentation/kbuild/kconfig-language.rst > > +++ b/Documentation/kbuild/kconfig-language.rst > > @@ -228,6 +228,24 @@ applicable everywhere (see syntax). > >enables the third modular state for all config symbols. > >At most one symbol may have the "modules" option set. > > > > +- phase declaration: "defphase" > > + This defines a new build phase. See `Build Phases`_. > > + > > +- default phase: "phasedefault" > > + This indicates the default build phase. See `Build Phases`_. > > + > > +- add entries for phases: "addphases" > > + This creates new phase-specific entries based on a template entry and > adds > > + the same attributes to it. See `Build Phases`_. > > + > > +- set entries for phases: "setphases" > > + This sets the phases which need an entry. This allows creating an > entry that > > + only has a primary phase. See `Build Phases`_. > > + > > +- indicate a phase-specific attribute: "forphases" > > + This marks an attribute as being applicable only to a particular > phase or > > + group of phases. See `Build Phases`_. > > + > > Menu dependencies > > - > > > > @@ -319,6 +337,119 @@ MODVERSIONS directly depends on MODULES, this > means it's only visible if > > MODULES is different from 'n'. The comment on the other hand is only > > visible when MODULES is set to 'n'. > > > > +Build Phases > > + > > + > > +Some projects use Kconfig to control multiple build phases, each phase > > +resulting in a separate set of object files and executable. This is the > > +case in U-Boot [12]_. Zephyr OS seems to be heading this way too [13]_. > > + > > +Generally the phases are related, so that enabling an entry in the > primary > > +phase also enables it by default in the others. But in some cases it may > > +be desirable to use separate conditions for each phase. > > + > > +All phases have a phase name, for example `SPL`. This name is used as a > > +prefix to each entry used in that phase, with an underscore in between. > > +So if FOO is the primary entry, the equivalent entry for the SPL phase > > +is SPL_FOO. The primary phase is marked with a "phasedefault" entry. > > + > > +Phases are declared like any other menu entry except that also have a > > +"defphase" keyword. Phase entries are normally hidden so do not have a > > +prompt:: > > + > > +config PPL > > +bool > > +defphase "Primary Program Loader" > > +phasedefault > > +help > > + This is the primary bootloader. > > + > > +config SPL > > +bool > > +defphase "Secondary Program Loader" > > +help > > + This is used to set up memory and load the primary bootloader. > > + > > +The default phase (here PPL) is assumed for all entries, in the sense > that > > +all entries are present in PPL by default and no prefix is needed on > these > > +entries. So FOO means that it applies to PPL. There must be exactly one > > +default phase. > > + > > +The resulting menu entries can be used normally throughout the Kconfig. > With > > +this technique, the different build phases can be fully and individually > > +controlled from Kconfig. > > + > > +However it is not ideal. Often the secondary phases have far fewer > entries than > > +the primary phase, since they offer fewer features. Even so, each FOO > that is > > +needed in a phase must have an SPL_FOO, etc. To avoid an explosion of > entries, > > +it is possible to indicate which are enabled, as a shortcut for > creating new > > +entries:: > > + > > +config FOO > > +bool "Enable foo feature" > > +addphases SPL > > +depends on %BAR > > +depends on QUX > > +forphases SPL depends on FIZZ > > + > > +Note that "%" expands to the phase, so this is equivalent to (ignoring > BAR):: > > + > > +config FOO > > +bool "Enable foo feature" > > +depends on BAR > > +depends on QUX > > + > > +config SPL_FOO#
Re: [PATCH] kconfig: Proposed language extension for multiple builds
+lk On Sun, 19 Feb 2023 at 14:55, Simon Glass wrote: > > In the case of Linux, only one build is produced so there is only a > single configuration. For other projects, such as U-Boot and Zephyr, the > same code is used to produce multiple builds, each with related (but > different) options enabled. > > This can be handled with the existing kconfig language, but it is quite > verbose, somewhat tedious and very error-prone, since there is a lot of > duplication. The result is hard to maintain. > > Describe an extension to the Kconfig language to support easier handling > of this use case. > > Signed-off-by: Simon Glass > --- > > Documentation/kbuild/kconfig-language.rst | 134 ++ > 1 file changed, 134 insertions(+) > > diff --git a/Documentation/kbuild/kconfig-language.rst > b/Documentation/kbuild/kconfig-language.rst > index 858ed5d80defe..73fb016a5533f 100644 > --- a/Documentation/kbuild/kconfig-language.rst > +++ b/Documentation/kbuild/kconfig-language.rst > @@ -228,6 +228,24 @@ applicable everywhere (see syntax). >enables the third modular state for all config symbols. >At most one symbol may have the "modules" option set. > > +- phase declaration: "defphase" > + This defines a new build phase. See `Build Phases`_. > + > +- default phase: "phasedefault" > + This indicates the default build phase. See `Build Phases`_. > + > +- add entries for phases: "addphases" > + This creates new phase-specific entries based on a template entry and adds > + the same attributes to it. See `Build Phases`_. > + > +- set entries for phases: "setphases" > + This sets the phases which need an entry. This allows creating an entry > that > + only has a primary phase. See `Build Phases`_. > + > +- indicate a phase-specific attribute: "forphases" > + This marks an attribute as being applicable only to a particular phase or > + group of phases. See `Build Phases`_. > + > Menu dependencies > - > > @@ -319,6 +337,119 @@ MODVERSIONS directly depends on MODULES, this means > it's only visible if > MODULES is different from 'n'. The comment on the other hand is only > visible when MODULES is set to 'n'. > > +Build Phases > + > + > +Some projects use Kconfig to control multiple build phases, each phase > +resulting in a separate set of object files and executable. This is the > +case in U-Boot [12]_. Zephyr OS seems to be heading this way too [13]_. > + > +Generally the phases are related, so that enabling an entry in the primary > +phase also enables it by default in the others. But in some cases it may > +be desirable to use separate conditions for each phase. > + > +All phases have a phase name, for example `SPL`. This name is used as a > +prefix to each entry used in that phase, with an underscore in between. > +So if FOO is the primary entry, the equivalent entry for the SPL phase > +is SPL_FOO. The primary phase is marked with a "phasedefault" entry. > + > +Phases are declared like any other menu entry except that also have a > +"defphase" keyword. Phase entries are normally hidden so do not have a > +prompt:: > + > +config PPL > +bool > +defphase "Primary Program Loader" > +phasedefault > +help > + This is the primary bootloader. > + > +config SPL > +bool > +defphase "Secondary Program Loader" > +help > + This is used to set up memory and load the primary bootloader. > + > +The default phase (here PPL) is assumed for all entries, in the sense that > +all entries are present in PPL by default and no prefix is needed on these > +entries. So FOO means that it applies to PPL. There must be exactly one > +default phase. > + > +The resulting menu entries can be used normally throughout the Kconfig. With > +this technique, the different build phases can be fully and individually > +controlled from Kconfig. > + > +However it is not ideal. Often the secondary phases have far fewer entries > than > +the primary phase, since they offer fewer features. Even so, each FOO that is > +needed in a phase must have an SPL_FOO, etc. To avoid an explosion of > entries, > +it is possible to indicate which are enabled, as a shortcut for creating new > +entries:: > + > +config FOO > +bool "Enable foo feature" > +addphases SPL > +depends on %BAR > +depends on QUX > +forphases SPL depends on FIZZ > + > +Note that "%" expands to the phase, so this is equivalent to (ignoring BAR):: > + > +config FOO > +bool "Enable foo feature" > +depends on BAR > +depends on QUX > + > +config SPL_FOO# Phase is prepended > +bool "Enable foo feature (SPL)"# Suffix is added > +depends on SPL_BAR # "%" dependency is expanded > +depends on QUX > +depends on FIZZ# Added only for SPL > +depends on SPL # Added automatically
Re: [PATCH] kconfig: Proposed language extension for multiple builds
Hi Masahiro, On Sun, 19 Feb 2023 at 14:55, Simon Glass wrote: > > In the case of Linux, only one build is produced so there is only a > single configuration. For other projects, such as U-Boot and Zephyr, the > same code is used to produce multiple builds, each with related (but > different) options enabled. > > This can be handled with the existing kconfig language, but it is quite > verbose, somewhat tedious and very error-prone, since there is a lot of > duplication. The result is hard to maintain. > > Describe an extension to the Kconfig language to support easier handling > of this use case. > > Signed-off-by: Simon Glass > --- > > Documentation/kbuild/kconfig-language.rst | 134 ++ > 1 file changed, 134 insertions(+) > Do you have any comments on this, please? Regards, Simon > diff --git a/Documentation/kbuild/kconfig-language.rst > b/Documentation/kbuild/kconfig-language.rst > index 858ed5d80defe..73fb016a5533f 100644 > --- a/Documentation/kbuild/kconfig-language.rst > +++ b/Documentation/kbuild/kconfig-language.rst > @@ -228,6 +228,24 @@ applicable everywhere (see syntax). >enables the third modular state for all config symbols. >At most one symbol may have the "modules" option set. > > +- phase declaration: "defphase" > + This defines a new build phase. See `Build Phases`_. > + > +- default phase: "phasedefault" > + This indicates the default build phase. See `Build Phases`_. > + > +- add entries for phases: "addphases" > + This creates new phase-specific entries based on a template entry and adds > + the same attributes to it. See `Build Phases`_. > + > +- set entries for phases: "setphases" > + This sets the phases which need an entry. This allows creating an entry > that > + only has a primary phase. See `Build Phases`_. > + > +- indicate a phase-specific attribute: "forphases" > + This marks an attribute as being applicable only to a particular phase or > + group of phases. See `Build Phases`_. > + > Menu dependencies > - > > @@ -319,6 +337,119 @@ MODVERSIONS directly depends on MODULES, this means > it's only visible if > MODULES is different from 'n'. The comment on the other hand is only > visible when MODULES is set to 'n'. > > +Build Phases > + > + > +Some projects use Kconfig to control multiple build phases, each phase > +resulting in a separate set of object files and executable. This is the > +case in U-Boot [12]_. Zephyr OS seems to be heading this way too [13]_. > + > +Generally the phases are related, so that enabling an entry in the primary > +phase also enables it by default in the others. But in some cases it may > +be desirable to use separate conditions for each phase. > + > +All phases have a phase name, for example `SPL`. This name is used as a > +prefix to each entry used in that phase, with an underscore in between. > +So if FOO is the primary entry, the equivalent entry for the SPL phase > +is SPL_FOO. The primary phase is marked with a "phasedefault" entry. > + > +Phases are declared like any other menu entry except that also have a > +"defphase" keyword. Phase entries are normally hidden so do not have a > +prompt:: > + > +config PPL > +bool > +defphase "Primary Program Loader" > +phasedefault > +help > + This is the primary bootloader. > + > +config SPL > +bool > +defphase "Secondary Program Loader" > +help > + This is used to set up memory and load the primary bootloader. > + > +The default phase (here PPL) is assumed for all entries, in the sense that > +all entries are present in PPL by default and no prefix is needed on these > +entries. So FOO means that it applies to PPL. There must be exactly one > +default phase. > + > +The resulting menu entries can be used normally throughout the Kconfig. With > +this technique, the different build phases can be fully and individually > +controlled from Kconfig. > + > +However it is not ideal. Often the secondary phases have far fewer entries > than > +the primary phase, since they offer fewer features. Even so, each FOO that is > +needed in a phase must have an SPL_FOO, etc. To avoid an explosion of > entries, > +it is possible to indicate which are enabled, as a shortcut for creating new > +entries:: > + > +config FOO > +bool "Enable foo feature" > +addphases SPL > +depends on %BAR > +depends on QUX > +forphases SPL depends on FIZZ > + > +Note that "%" expands to the phase, so this is equivalent to (ignoring BAR):: > + > +config FOO > +bool "Enable foo feature" > +depends on BAR > +depends on QUX > + > +config SPL_FOO# Phase is prepended > +bool "Enable foo feature (SPL)"# Suffix is added > +depends on SPL_BAR # "%" dependency is expanded > +depends on QUX > +depends on FIZZ# Added only for SPL
[PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
This new clearfog_spi_defconfig file is copy of existing
clearfog_defconfig file and changed to instruct build system to
generate final kwbimage for SPI booting and to store the
environment in SPI as well.
Signed-off-by: Martin Rowe
---
.../{clearfog_sata_defconfig => clearfog_spi_defconfig}| 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
copy configs/{clearfog_sata_defconfig => clearfog_spi_defconfig} (93%)
diff --git a/configs/clearfog_sata_defconfig b/configs/clearfog_spi_defconfig
similarity index 93%
copy from configs/clearfog_sata_defconfig
copy to configs/clearfog_spi_defconfig
index 84f900bf50..31b1e9fce8 100644
--- a/configs/clearfog_sata_defconfig
+++ b/configs/clearfog_spi_defconfig
@@ -3,20 +3,24 @@ CONFIG_ARCH_CPU_INIT=y
CONFIG_SYS_THUMB_BUILD=y
CONFIG_ARCH_MVEBU=y
CONFIG_TEXT_BASE=0x0080
+CONFIG_SPL_GPIO=y
CONFIG_SPL_LIBCOMMON_SUPPORT=y
CONFIG_SPL_LIBGENERIC_SUPPORT=y
CONFIG_NR_DRAM_BANKS=2
CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff
CONFIG_TARGET_CLEARFOG=y
-CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y
+CONFIG_ENV_SECT_SIZE=0x1
CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog"
CONFIG_SPL_TEXT_BASE=0x4030
+CONFIG_SPL_MMC=y
CONFIG_SPL_SERIAL=y
CONFIG_SPL_STACK=0x4002c000
CONFIG_SPL=y
CONFIG_DEBUG_UART_BASE=0xf1012000
CONFIG_DEBUG_UART_CLOCK=25000
+CONFIG_SPL_LIBDISK_SUPPORT=y
+# CONFIG_SPL_SPI is not set
CONFIG_SYS_LOAD_ADDR=0x80
CONFIG_DEBUG_UART=y
CONFIG_AHCI=y
@@ -59,6 +63,7 @@ CONFIG_SYS_I2C_MVTWSI=y
CONFIG_I2C_EEPROM=y
CONFIG_SPL_I2C_EEPROM=y
CONFIG_MMC_BROKEN_CD=y
+CONFIG_SPL_DM_MMC=y
CONFIG_SUPPORT_EMMC_BOOT=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_SDMA=y
--
2.39.2
[PATCH 1/2] arm: mvebu: clearfog: Fix MMC detection
A388 Clearfog MMC is either SD Card or eMMC with different behaviour for both. Setting MMC_BROKEN_CD allows both to correctly detect MMC. Signed-off-by: Martin Rowe --- configs/clearfog_defconfig | 3 +-- configs/clearfog_sata_defconfig | 8 2 files changed, 5 insertions(+), 6 deletions(-) diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig index 8cd35f9f1a..24e7c16ac7 100644 --- a/configs/clearfog_defconfig +++ b/configs/clearfog_defconfig @@ -46,7 +46,6 @@ CONFIG_CMD_USB=y CONFIG_CMD_TFTPPUT=y CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y -CONFIG_CMD_MVEBU_BUBT=y CONFIG_ENV_OVERWRITE=y CONFIG_ENV_MIN_ENTRIES=128 CONFIG_ARP_TIMEOUT=200 @@ -59,7 +58,7 @@ CONFIG_DM_I2C=y CONFIG_SYS_I2C_MVTWSI=y CONFIG_I2C_EEPROM=y CONFIG_SPL_I2C_EEPROM=y -CONFIG_SUPPORT_EMMC_BOOT=y +CONFIG_MMC_BROKEN_CD=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_SDMA=y CONFIG_MMC_SDHCI_MV=y diff --git a/configs/clearfog_sata_defconfig b/configs/clearfog_sata_defconfig index e9b36150ea..84f900bf50 100644 --- a/configs/clearfog_sata_defconfig +++ b/configs/clearfog_sata_defconfig @@ -6,11 +6,14 @@ CONFIG_TEXT_BASE=0x0080 CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_NR_DRAM_BANKS=2 +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff CONFIG_TARGET_CLEARFOG=y CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog" CONFIG_SPL_TEXT_BASE=0x4030 CONFIG_SPL_SERIAL=y +CONFIG_SPL_STACK=0x4002c000 CONFIG_SPL=y CONFIG_DEBUG_UART_BASE=0xf1012000 CONFIG_DEBUG_UART_CLOCK=25000 @@ -18,8 +21,6 @@ CONFIG_SYS_LOAD_ADDR=0x80 CONFIG_DEBUG_UART=y CONFIG_AHCI=y CONFIG_DISTRO_DEFAULTS=y -CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y -CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff CONFIG_BOOTDELAY=3 CONFIG_USE_PREBOOT=y CONFIG_SYS_CONSOLE_INFO_QUIET=y @@ -31,7 +32,6 @@ CONFIG_SPL_BSS_START_ADDR=0x40023000 CONFIG_SPL_BSS_MAX_SIZE=0x4000 CONFIG_SPL_SYS_MALLOC_SIMPLE=y # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set -CONFIG_SPL_STACK=0x4002c000 CONFIG_SPL_I2C=y CONFIG_SYS_MAXARGS=32 CONFIG_CMD_TLV_EEPROM=y @@ -46,7 +46,6 @@ CONFIG_CMD_USB=y CONFIG_CMD_TFTPPUT=y CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y -CONFIG_CMD_MVEBU_BUBT=y CONFIG_ENV_OVERWRITE=y CONFIG_ENV_MIN_ENTRIES=128 CONFIG_ARP_TIMEOUT=200 @@ -59,6 +58,7 @@ CONFIG_DM_I2C=y CONFIG_SYS_I2C_MVTWSI=y CONFIG_I2C_EEPROM=y CONFIG_SPL_I2C_EEPROM=y +CONFIG_MMC_BROKEN_CD=y CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_SDMA=y -- 2.39.2
[PATCH 0/2] arm: mvebu: clearfog: defconfig updates
Minor defconfig updates to Pali's RFC "arm: mvebu: Various fixes" for
SolidRun's A388 Clearfog devices.
Martin Rowe (2):
arm: mvebu: clearfog: Fix MMC detection
arm: mvebu: clearfog: Add defconfig for SPI booting
configs/clearfog_defconfig| 3 +--
configs/clearfog_sata_defconfig | 8
...rfog_sata_defconfig => clearfog_spi_defconfig} | 15 ++-
3 files changed, 15 insertions(+), 11 deletions(-)
copy configs/{clearfog_sata_defconfig => clearfog_spi_defconfig} (92%)
--
2.39.2
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
> When generating this patch, use git options -M, -C and > --find-copies-harder. It will detect that you created this file as copy > from other file and generate better diff. Will do. This thread has gotten quite long! I've: - tested all the boot modes and bubt update types - created the SPI defconfig, - fixed the eMMC detection by enabling MMC_BROKEN_CD - taken a look at the kwbimage documentation, but I don't think I can be of much help there I'm also able to help test any new changes for the MMC boot flow. Is there anything else that I've missed that I can help with while I've got it all setup? Martin
Re: [PATCH 1/2] clk: sunxi: add THS clk/reset
On Mon, 13 Feb 2023 10:42:55 +0800
qianfangui...@163.com wrote:
Hi,
> From: qianfan Zhao
>
> Add clock/reset definitions for THS peripherals.
the bits look alright, compared against the manual. But it misses the
A64 clocks, the THS driver would cover that SoC, too.
Cheers,
Andre
> Signed-off-by: qianfan Zhao
> ---
> drivers/clk/sunxi/clk_h3.c | 5 +
> drivers/clk/sunxi/clk_h6.c | 4
> drivers/clk/sunxi/clk_r40.c | 5 +
> 3 files changed, 14 insertions(+)
>
> diff --git a/drivers/clk/sunxi/clk_h3.c b/drivers/clk/sunxi/clk_h3.c
> index 213ab510ed..774d67cbfa 100644
> --- a/drivers/clk/sunxi/clk_h3.c
> +++ b/drivers/clk/sunxi/clk_h3.c
> @@ -38,6 +38,7 @@ static struct ccu_clk_gate h3_gates[] = {
> [CLK_BUS_DE]= GATE(0x064, BIT(12)),
>
> [CLK_BUS_PIO] = GATE(0x068, BIT(5)),
> + [CLK_BUS_THS] = GATE(0x068, BIT(8)),
>
> [CLK_BUS_I2C0] = GATE(0x06c, BIT(0)),
> [CLK_BUS_I2C1] = GATE(0x06c, BIT(1)),
> @@ -49,6 +50,8 @@ static struct ccu_clk_gate h3_gates[] = {
>
> [CLK_BUS_EPHY] = GATE(0x070, BIT(0)),
>
> + [CLK_THS] = GATE(0x074, BIT(31)),
> +
> [CLK_SPI0] = GATE(0x0a0, BIT(31)),
> [CLK_SPI1] = GATE(0x0a4, BIT(31)),
>
> @@ -98,6 +101,8 @@ static struct ccu_reset h3_resets[] = {
>
> [RST_BUS_EPHY] = RESET(0x2c8, BIT(2)),
>
> + [RST_BUS_THS] = RESET(0x2d0, BIT(8)),
> +
> [RST_BUS_I2C0] = RESET(0x2d8, BIT(0)),
> [RST_BUS_I2C1] = RESET(0x2d8, BIT(1)),
> [RST_BUS_I2C2] = RESET(0x2d8, BIT(2)),
> diff --git a/drivers/clk/sunxi/clk_h6.c b/drivers/clk/sunxi/clk_h6.c
> index 24eb9725db..5464530056 100644
> --- a/drivers/clk/sunxi/clk_h6.c
> +++ b/drivers/clk/sunxi/clk_h6.c
> @@ -42,6 +42,8 @@ static struct ccu_clk_gate h6_gates[] = {
>
> [CLK_BUS_EMAC] = GATE(0x97c, BIT(0)),
>
> + [CLK_BUS_THS] = GATE(0x9fc, BIT(0)),
> +
> [CLK_USB_PHY0] = GATE(0xa70, BIT(29)),
> [CLK_USB_OHCI0] = GATE(0xa70, BIT(31)),
>
> @@ -91,6 +93,8 @@ static struct ccu_reset h6_resets[] = {
>
> [RST_BUS_EMAC] = RESET(0x97c, BIT(16)),
>
> + [RST_BUS_THS] = RESET(0x9fc, BIT(16)),
> +
> [RST_USB_PHY0] = RESET(0xa70, BIT(30)),
>
> [RST_USB_PHY1] = RESET(0xa74, BIT(30)),
> diff --git a/drivers/clk/sunxi/clk_r40.c b/drivers/clk/sunxi/clk_r40.c
> index 630e80d2b4..4fbfd28207 100644
> --- a/drivers/clk/sunxi/clk_r40.c
> +++ b/drivers/clk/sunxi/clk_r40.c
> @@ -42,6 +42,7 @@ static struct ccu_clk_gate r40_gates[] = {
> [CLK_BUS_TCON_TOP] = GATE(0x064, BIT(30)),
>
> [CLK_BUS_PIO] = GATE(0x068, BIT(5)),
> + [CLK_BUS_THS] = GATE(0x068, BIT(8)),
>
> [CLK_BUS_I2C0] = GATE(0x06c, BIT(0)),
> [CLK_BUS_I2C1] = GATE(0x06c, BIT(1)),
> @@ -57,6 +58,8 @@ static struct ccu_clk_gate r40_gates[] = {
> [CLK_BUS_UART6] = GATE(0x06c, BIT(22)),
> [CLK_BUS_UART7] = GATE(0x06c, BIT(23)),
>
> + [CLK_THS] = GATE(0x074, BIT(31)),
> +
> [CLK_SPI0] = GATE(0x0a0, BIT(31)),
> [CLK_SPI1] = GATE(0x0a4, BIT(31)),
> [CLK_SPI2] = GATE(0x0a8, BIT(31)),
> @@ -113,6 +116,8 @@ static struct ccu_reset r40_resets[] = {
> [RST_BUS_TCON_TV1] = RESET(0x2c4, BIT(29)),
> [RST_BUS_TCON_TOP] = RESET(0x2c4, BIT(30)),
>
> + [RST_BUS_THS] = RESET(0x2d0, BIT(8)),
> +
> [RST_BUS_I2C0] = RESET(0x2d8, BIT(0)),
> [RST_BUS_I2C1] = RESET(0x2d8, BIT(1)),
> [RST_BUS_I2C2] = RESET(0x2d8, BIT(2)),
RE: Boot from 64-bit memory address?
Hi Rick, Thanks for the feedback! I did make those changes to binman.dtsi. Ultimately, I think the issue is with the "ERROR: Out of memory" error which comes from the EFI loader (lib/efi_loader) because there's no conventional memory (i.e. something with a memory address below 4GB). The allocation error afterward (from boot/image_board.c::boot_ramdisk_high) is a knock-on effect since there's no location available to move initramfs to. As I've dug into this more today though, it seems like so many backend things for RISC-V in U-Boot are set up to only support 32-bit DRAM. I think there will be quite a lot of adjustments to be made to support the memory map I have. Thanks, Phil -Original Message- From: Rick Chen Sent: Thursday, February 23, 2023 10:33 PM To: Bernard, Philip Cc: U-Boot Mailing List ; Leo Liang ; peter...@andestech.com; rick Subject: Re: Boot from 64-bit memory address? Hi Philip, > From: U-Boot On Behalf Of Bernard, > Philip > Sent: Thursday, February 23, 2023 9:21 AM > To: u-boot@lists.denx.de > Subject: Boot from 64-bit memory address? > > Hi, > > Is it possible to boot from a DRAM memory address beyond the 32-bit > boundary? I'm trying to configure a new RISC-V board which has 2GB of > DRAM starting at offset 0x40__. I started from the settings > for an existing RISC-V board and made I think it is possible to boot from a DRAM memory beyond the 32-bit boundary. But maybe you need to modify some code to achieve that. I have tried to boot an internal AE350-like platform whose DRAM base is at 0x4. adjustments for my HW, but when I try to boot, I run into an "out of memory" error. > > From > https://u-boot.readthedocs.io/en/latest/develop/uefi/u-boot_on_efi.html#tables > I noticed that U-Boot will only use "conventional" memory which is 4GB and > below, so it seems like this may not be possible? Looking through the repo, I > also noticed that nearly every device is configuring settings like > CONFIG_SYS_LOAD_ADDR with a 32-bit value, so I haven't found any examples to > emulate for my use case. CONFIG_SYS_LOAD_ADDR is not important. Maybe you shall notice CONFIG_SYS_TEXT_BASE and CONFIG_SPL_OPENSBI_LOAD_ADDR which will be parsed from binman.dtsi You can change them like this: load = /bits/64 ; load = /bits/64 ; > > I'm hoping someone knows the mistake I'm making or can confirm that this > isn't possible. Appreciate the help. > > Best, > Phil > > > Below is the output from U-Boot: > > U-Boot SPL 2022.07 (Feb 23 2023 - 00:50:44 +) Trying to boot from > RAM > > OpenSBI v1.1 >_ _ > / __ \ / | _ \_ _| > | | | |_ __ ___ _ __ | (___ | |_) || | > | | | | '_ \ / _ \ '_ \ \___ \| _ < | | __| | |_) | __/ | | |) > | | | > | ||_) || |_ > \/| .__/ \___|_| |_|_/|/_| > | | > |_| > > Platform Name : test,test > Platform Features : medeleg > Platform HART Count : 1 > Platform IPI Device : aclint-mswi > Platform Timer Device : aclint-mtimer @ 100Hz > Platform Console Device : uart8250 > Platform HSM Device : --- > Platform Reboot Device: --- > Platform Shutdown Device : --- > Firmware Base : 0x8000 > Firmware Size : 276 KB > Runtime SBI Version : 1.0 > > Domain0 Name : root > Domain0 Boot HART : 0 > Domain0 HARTs : 0* > Domain0 Region00 : 0x0200-0x0200 (I) > Domain0 Region01 : 0x8000-0x8007 () > Domain0 Region02 : 0x-0x (R,W,X) > Domain0 Next Address : 0x00400120 > Domain0 Next Arg1 : 0x004001267830 > Domain0 Next Mode : S-mode > Domain0 SysReset : yes > > Boot HART ID : 0 > Boot HART Domain : root > Boot HART Priv Version: v1.10 > Boot HART Base ISA: rv64imafdcb > Boot HART ISA Extensions : time > Boot HART PMP Count : 8 > Boot HART PMP Granularity : 4 > Boot HART PMP Address Bits: 54 > Boot HART MHPM Count : 0 > Boot HART MIDELEG : 0x0222 > Boot HART MEDELEG : 0xb109 > > > U-Boot 2022.07 (Feb 23 2023 - 00:50:44 +) > > CPU: rv64imafdc > Model: test,test > DRAM: 2 GiB > Core: 11 devices, 8 uclasses, devicetree: separate > ERROR: Out of memory > Loading Environment from nowhere... OK > In:serial@13140 > Out: serial@13140 > Err: serial@13140 > Model: test,test > Net: No ethernet found. > Hit any key to stop autoboot: 0 > Moving Image from 0x400600 to 0x400020, end=4000b01c8c ## Flattened > Device Tree blob at ff76a1d0 >Booting using the fdt blob at 0xff76a1d0 > ERROR: Failed to allocate 0x100 bytes below 0x1. Can you dig in where to print this ERROR ? Thanks, Rick > ramdisk - allocation error
[PATCH v2 00/26] CONFIG_IS_ENABLED vs IS_ENABLED
This patch set gets ready to check the usage of CONFIG_IS_ENABLED/IS_ENABLED. After the set has been applied, you can delete test/usage_of_is_enabled_todo.txt and run test/usage_of_is_enabled_commit.sh The script test/usage_of_is_enabled_check.sh checks for new questionable uses of CONFIG_IS_ENABLED/IS_ENABLED and is added to .azure-pipelines.yml, and .gitlab-ci.yml Changes in v2: - new patch - delay include of linux/kconfig.h to do from Makefile - include linux/kconfig.h from tools/Makefile - as suggested by Simon - keep #error, but change condition to use IS_ENABLED_NOCHECK - keep #error, but change condition to use IS_ENABLED_NOCHECK - changed condition of when to include field bdf - added protection to another instance of bdf in uart.c - Thanks to Simon for getting this corrected - use normal if, not preprocessor - new in series - use an accessor function gd_set_pci_ram_top - Always define function instead of using same protection Troy Kisky (26): kconfig: add IS_ENABLED_NOCHECK to bypass usage_of_is_enabled_check cmd: nvedit: check for ENV_SUPPORT lib: crc32: prepare for CONFIG_IS_ENABLED changes lib: md5: prepare for CONFIG_IS_ENABLED changes lib: sha1: prepare for CONFIG_IS_ENABLED changes lib: sha256: prepare for CONFIG_IS_ENABLED changes lib: sha512: prepare for CONFIG_IS_ENABLED changes tools: prevent CONFIG_IS_ENABLED errors by including linux/kconfig.h tools: Makefile: prepare for CONFIG_IS_ENABLED changes by adding CONFIG_TOOLS_xxx x86: cpu: qemu: qemu: remove SPL use with CONFIG_IS_ENABLED config_distro_bootcmd: remove booting environment variables from SPL environment ofnode: fdt_support definitions needed if OF_CONTROL is enabled ringneck-px30: use IS_ENABLED_NOCHECK to avoid CI test failure for ENV_IS_NOWHERE puma-rk3399: use IS_ENABLED_NOCHECK to avoid CI test failure for ENV_IS_NOWHERE fdt_support: always define fdt_fixup_mtdparts m53menlo: define ft_board_setup only if CONFIG_IS_ENABLED(OF_LIBFDT) freescale: common: pfuze: define pfuze_mode_init only if defined(CONFIG_DM_PMIC) ns16550: match when to define bdf with uart code solidrun: mx6cuboxi: use CONFIG_IS_ENABLED(SATA) instead of CONFIG_CMD_SATA wandboard: use CONFIG_IS_ENABLED(SATA) instead of ifdef CONFIG_SATA arm: mach-imx: use CONFIG_$(SPL_)SATA instead of CONFIG_SATA x86: cpu: i386: cpu: only set pci_ram_top if CONFIG_IS_ENABLED(PCI) gateworks: venice: Always define setup_fec and setup_eqos power: pmic: add dm style definitions if not CONFIG_IS_ENABLED(POWER_LEGACY) arm: cpu: armv7: ls102xa: fdt: remove eth_device support CI: add test/usage_of_is_enabled_check.sh .azure-pipelines.yml | 11 + .gitlab-ci.yml| 5 + arch/arm/cpu/armv7/ls102xa/fdt.c | 12 - arch/arm/mach-imx/Makefile| 2 +- arch/x86/cpu/apollolake/uart.c| 4 + arch/x86/cpu/i386/cpu.c | 2 +- arch/x86/cpu/qemu/qemu.c | 2 +- board/freescale/common/pfuze.c| 2 +- board/gateworks/venice/venice.c | 2 +- board/menlo/m53menlo/m53menlo.c | 2 + board/solidrun/mx6cuboxi/mx6cuboxi.c | 5 +- .../puma_rk3399/puma-rk3399.c | 2 +- .../ringneck_px30/ringneck-px30.c | 2 +- board/wandboard/wandboard.c | 5 +- cmd/nvedit.c | 5 +- include/asm-generic/global_data.h | 6 + include/config_distro_bootcmd.h | 23 ++ include/fdt_support.h | 26 ++- include/linux/kconfig.h | 5 + include/ns16550.h | 2 +- include/power/pmic.h | 2 +- lib/crc32.c | 11 +- lib/md5.c | 7 +- lib/sha1.c| 7 +- lib/sha256.c | 7 +- lib/sha512.c | 11 +- test/usage_of_is_enabled_check.sh | 19 ++ test/usage_of_is_enabled_commit.sh| 12 + test/usage_of_is_enabled_correct.sh | 50 + test/usage_of_is_enabled_exempt.txt | 9 + test/usage_of_is_enabled_list.sh | 86 +++ test/usage_of_is_enabled_splcfg.txt | 21 ++ test/usage_of_is_enabled_todo.txt | 210 ++ tools/Makefile| 3 + 34 files changed, 527 insertions(+), 53 deletions(-) create mode 100755 test/usage_of_is_enabled_check.sh create mode 100755 test/usage_of_is_enabled_commit.sh create mode 100755 test/usage_of_is_enabled_correct.sh create mode 100644 test/usage_of_is_enabled_exempt.txt create mode 100755 test/usage_of_is_enabled_list.sh create mode 100644 test/usage_of_is_enabled_splcfg.txt create mode 100644
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
On Friday 24 February 2023 15:07:43 Martin Rowe wrote: > [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting > > This new clearfog_spi_defconfig file is copy of existing > clearfog_defconfig file and changed to instruct build system to > generate final kwbimage for SPI booting and to store the > environment in SPI as well. > > Signed-off-by: Martin Rowe > --- > configs/clearfog_spi_defconfig | 88 ++ > 1 file changed, 88 insertions(+) > create mode 100644 configs/clearfog_spi_defconfig > > diff --git a/configs/clearfog_spi_defconfig b/configs/clearfog_spi_defconfig > new file mode 100644 > index 00..31b1e9fce8 > --- /dev/null > +++ b/configs/clearfog_spi_defconfig When generating this patch, use git options -M, -C and --find-copies-harder. It will detect that you created this file as copy from other file and generate better diff.
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
On Friday 24 February 2023 06:27:49 Martin Rowe wrote: > > > boot0 - zeroed > > > boot1 - u-boot (with local version 'boot1') > > > user - u-boot (with local version 'user') > > Can you check if boot_ack argument has some effect on the initial > > choice? Or if completely disabling boot partitions (boot_enable to 0) > > have some effect? > > boot_ack doesn't appear to do anything. I can only set 0 or 1 and > there's no noticeable change to the boot process. Ok. > Setting `mmc partconf 0 0 0 0` with the same setup as described above > results in the same BootROM fallback from BOOT0 to BOOT1, then SPL in > BOOT1 loads u-boot from the user area, which is identical to the `mmc > partconf 0 0 7 0` flow. Ok. > > If really EXT_CSD[179] register is completely ignored we may change SPL > > to always boot from BOOT0 (when eMMC with boot partitions is used) and > > if it fails then fallback to BootROM booting. > > Is there a way of knowing where the SPL was loaded from? I was trying to figure it out but it looks like that bootrom stores this information into variable on the bootrom stack. So I think that this is impossible. > Because it > would make sense to me that if SPL was loaded from BOOT1 to try and > load u-boot from BOOT1 as well, or from BOOT0 if SPL was loaded from > BOOT0, etc. Having u-boot loaded from a different location is not what > I expected and seems like it would cause a lot of confusion, > especially in a failed A/B rollout. Exactly, I want to avoid it. > BootROM seems to completely ignore > the setting, so I agree that SPL should ignore it as well, but > hardcoding BOOT0 (or even setting the partition as a compile-time > option) is probably not a great outcome. It is a solution and nice trick to how to fix it. Reason is that if SPL fails to load U-Boot from selected partition then it fallbacks to the BootROM, which loads U-Boot from the correct location. So if we hardcode partition to BOOT0 then it obviously works correctly when SPL+U-Boot is on BOOT0. And if it is stored on BOOT1 or USER then BootROM already has to fail load it from BOOT0, which means that on BOOT0 is not valid U-Boot and when SPL tries to load main U-Boot from BOOT0 it fails too, and it returns control to the BootROM which knows that it should load it from BOOT0. And this would work also for DATA. > Two observations that might help here: > 1. After reset, running `mmc partconf 0` always shows PARTITION_ACCESS > is set to 0x0, even it it was set to something else prior to reset Ok, so access permissions are reset. I do not know if this is in MMC standard or not. > 2. With the same setup as described above and `mmc partconf 0 0 1 1` > the SPL eventually times out trying to load from the zeroed BOOT0 and > returns to BootROM, which results in u-boot being loaded from BOOT1: Access permissions can disable access to particular partition. So it makes sense that it timeouts. And BootROM can always load and run main u-boot from the correct location. We are using SPL for loading main u-boot because this is way how it was first implemented and return to bootrom was broken in the past. Anyway, if you completely disable MMC support in SPL then SPL just returns control to BootROM which loads main U-Boot. Reading main u-boot via BootROM is slower as from SPL for SPI-NOR booting because SPL can use faster SPI transfers than BootROM. So this is the reason why we want in SPL to use native load method and not just BootROM. But maybe for MMC it would make sense? > = > BootROM - 1.73 > > Booting from MMC > BootROM: Bad header at offset > BootROM: Bad header at offset 0020 > Switching BootPartitions. > > U-Boot SPL 2023.04-rc2boot1-00098-g93408c61cd-dirty (Feb 23 2023 - > 19:43:59 +1000) > High speed PHY - Version: 2.0 > EEPROM TLV detection failed: Using static config for Clearfog Pro. > Detected Device ID 6828 > board SerDes lanes topology details: > | Lane # | Speed | Type | > > | 0| 3 | SATA0 | > | 1| 0 | SGMII1 | > | 2| 5 | PCIe1 | > | 3| 5 | USB3 HOST1 | > | 4| 5 | PCIe2 | > | 5| 0 | SGMII2 | > > High speed PHY - Ended Successfully > mv_ddr: 14.0.0 > DDR3 Training Sequence - Switching XBAR Window to FastPath Window > mv_ddr: completed successfully > Trying to boot from MMC1 > ERROR: Invalid kwbimage v1 > mmc_load_image_raw_sector: mmc block read error > spl: mmc: wrong boot mode > Trying to boot from BOOTROM > Returning to BootROM (return address 0x05c4)... > Timeout waiting card ready > BootROM: Image checksum verification PASSED > > > U-Boot 2023.04-rc2boot1-00098-g93408c61cd-dirty (Feb 23 2023 - 19:43:59 +1000) > > SoC: MV88F6828-A0 at 1600 MHz > DRAM: 1 GiB (800 MHz, 32-bit, ECC not enabled) > Core: 38 devices, 22 uclasses, devicetree: separate > MMC: mv_sdh: 0 > Loading
[PATCH v2 23/26] gateworks: venice: Always define setup_fec and setup_eqos
The compiler will optimize away base on IS_ENABLED(CONFIG_FEC_MXC).
It avoids an error in converting to CONFIG_IS_ENABLED(NET).
Signed-off-by: Troy Kisky
---
Changes in v2:
- Always define function instead of using same protection
board/gateworks/venice/venice.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/gateworks/venice/venice.c b/board/gateworks/venice/venice.c
index c4d86c26a9b..7a819e76a1c 100644
--- a/board/gateworks/venice/venice.c
+++ b/board/gateworks/venice/venice.c
@@ -41,7 +41,6 @@ int board_fit_config_name_match(const char *name)
return -1;
}
-#if (IS_ENABLED(CONFIG_NET))
static int setup_fec(void)
{
struct iomuxc_gpr_base_regs *gpr =
@@ -71,6 +70,7 @@ static int setup_eqos(void)
return set_clk_eqos(ENET_125MHZ);
}
+#if IS_ENABLED(CONFIG_NET)
int board_phy_config(struct phy_device *phydev)
{
unsigned short val;
--
2.34.1
[PATCH v2 19/26] solidrun: mx6cuboxi: use CONFIG_IS_ENABLED(SATA) instead of CONFIG_CMD_SATA
setup_sata is linked with
obj-$(CONFIG_SATA) += sata.o
So use SATA instead of CMD_SATA.
Signed-off-by: Troy Kisky
---
Changes in v2:
- use normal if, not preprocessor
board/solidrun/mx6cuboxi/mx6cuboxi.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c
b/board/solidrun/mx6cuboxi/mx6cuboxi.c
index 7c44379ec4a..6fa5cf4d27d 100644
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
+++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
@@ -275,9 +275,8 @@ int board_early_init_f(void)
{
setup_iomux_uart();
-#ifdef CONFIG_CMD_SATA
- setup_sata();
-#endif
+ if (CONFIG_IS_ENABLED(SATA))
+ setup_sata();
setup_fec();
return 0;
--
2.34.1
[PATCH v2 24/26] power: pmic: add dm style definitions if not CONFIG_IS_ENABLED(POWER_LEGACY)
This avoids an error in converting to CONFIG_IS_ENABLED(DM_PMIC).
Many boards SPL code needs these definitions to compile, even if
the functions are not linked.
Signed-off-by: Troy Kisky
Reviewed-by: Simon Glass
---
(no changes since v1)
include/power/pmic.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/power/pmic.h b/include/power/pmic.h
index 70f2709bd0b..636221692d0 100644
--- a/include/power/pmic.h
+++ b/include/power/pmic.h
@@ -86,7 +86,7 @@ struct pmic {
#endif /* CONFIG_IS_ENABLED(POWER_LEGACY) */
/* TODO: Change to CONFIG_IS_ENABLED(DM_PMIC) when SPL_DM_PMIC exists */
-#ifdef CONFIG_DM_PMIC
+#if defined(CONFIG_DM_PMIC) || !CONFIG_IS_ENABLED(POWER_LEGACY)
/**
* U-Boot PMIC Framework
* =
--
2.34.1
[PATCH v2 14/26] puma-rk3399: use IS_ENABLED_NOCHECK to avoid CI test failure for ENV_IS_NOWHERE
When usage_of_is_enabled_check.sh is added, this will show a false positive for IS_ENABLED(CONFIG_ENV_IS_NOWHERE). Use IS_ENABLED_NOCHECK to avoid check and error on SPL builds. Signed-off-by: Troy Kisky --- Changes in v2: - keep #error, but change condition to use IS_ENABLED_NOCHECK board/theobroma-systems/puma_rk3399/puma-rk3399.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/theobroma-systems/puma_rk3399/puma-rk3399.c b/board/theobroma-systems/puma_rk3399/puma-rk3399.c index 97f398bd754..d1e3a544974 100644 --- a/board/theobroma-systems/puma_rk3399/puma-rk3399.c +++ b/board/theobroma-systems/puma_rk3399/puma-rk3399.c @@ -136,7 +136,7 @@ int mmc_get_env_dev(void) return CONFIG_SYS_MMC_ENV_DEV; } -#if !IS_ENABLED(CONFIG_ENV_IS_NOWHERE) +#if !IS_ENABLED_NOCHECK(CONFIG_ENV_IS_NOWHERE) #error Please enable CONFIG_ENV_IS_NOWHERE #endif -- 2.34.1
[PATCH v2 12/26] ofnode: fdt_support definitions needed if OF_CONTROL is enabled
With the use of CONFIG_IS_ENABLED in code, instead of at the preprocessor level, these defines are still needed if OF_CONTROL is enabled. Signed-off-by: Troy Kisky Reviewed-by: Simon Glass --- (no changes since v1) include/fdt_support.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/fdt_support.h b/include/fdt_support.h index 5638bd4f165..eeb83e6251d 100644 --- a/include/fdt_support.h +++ b/include/fdt_support.h @@ -7,7 +7,8 @@ #ifndef __FDT_SUPPORT_H #define __FDT_SUPPORT_H -#if defined(CONFIG_OF_LIBFDT) && !defined(USE_HOSTCC) +#if (defined(CONFIG_OF_LIBFDT) || defined(CONFIG_OF_CONTROL)) && \ + !defined(USE_HOSTCC) #include #include -- 2.34.1
[PATCH v2 21/26] arm: mach-imx: use CONFIG_$(SPL_)SATA instead of CONFIG_SATA
This avoid an error with enable_sata_clock when defined(CONFIG_SATA) is changed to CONFIG_IS_ENABLED(SATA). Signed-off-by: Troy Kisky Reviewed-by: Simon Glass --- (no changes since v1) arch/arm/mach-imx/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile index 4dfc60eedc4..50f26975eac 100644 --- a/arch/arm/mach-imx/Makefile +++ b/arch/arm/mach-imx/Makefile @@ -54,7 +54,7 @@ obj-$(CONFIG_IMX_RDC) += rdc-sema.o ifneq ($(CONFIG_SPL_BUILD),y) obj-$(CONFIG_IMX_BOOTAUX) += imx_bootaux.o endif -obj-$(CONFIG_SATA) += sata.o +obj-$(CONFIG_$(SPL_)SATA) += sata.o obj-$(CONFIG_IMX_HAB)+= hab.o obj-$(CONFIG_SYSCOUNTER_TIMER) += syscounter.o endif -- 2.34.1
[PATCH v2 15/26] fdt_support: always define fdt_fixup_mtdparts
SPL code wants fdt_fixup_mtdparts defined as a NOP
when the function isn't linked in.
Prepare for ifdef CONFIG_OF_LIBFDT being converted to
if CONFIG_IS_ENABLED(OF_LIBFDT)
Signed-off-by: Troy Kisky
Reviewed-by: Simon Glass
---
(no changes since v1)
include/fdt_support.h | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/include/fdt_support.h b/include/fdt_support.h
index eeb83e6251d..94497d755a3 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -245,16 +245,6 @@ int fdt_increase_size(void *fdt, int add_len);
int fdt_delete_disabled_nodes(void *blob);
struct node_info;
-#if defined(CONFIG_FDT_FIXUP_PARTITIONS)
-void fdt_fixup_mtdparts(void *fdt, const struct node_info *node_info,
- int node_info_size);
-#else
-static inline void fdt_fixup_mtdparts(void *fdt,
- const struct node_info *node_info,
- int node_info_size)
-{
-}
-#endif
void fdt_del_node_and_alias(void *blob, const char *alias);
@@ -412,6 +402,19 @@ int fdt_get_cells_len(const void *blob, char
*nr_cells_name);
#endif /* ifdef CONFIG_OF_LIBFDT */
+#if CONFIG_IS_ENABLED(OF_LIBFDT) && defined(CONFIG_FDT_FIXUP_PARTITIONS)
+struct node_info;
+void fdt_fixup_mtdparts(void *fdt, const struct node_info *node_info,
+ int node_info_size);
+#else
+struct node_info;
+static inline void fdt_fixup_mtdparts(void *fdt,
+ const struct node_info *node_info,
+ int node_info_size)
+{
+}
+#endif
+
#ifdef USE_HOSTCC
int fdtdec_get_int(const void *blob, int node, const char *prop_name,
int default_val);
--
2.34.1
[PATCH v2 10/26] x86: cpu: qemu: qemu: remove SPL use with CONFIG_IS_ENABLED
CONFIG_IS_ENABLED(SPL_X86_32BIT_INIT)
would check for CONFIG_SPL_SPL_X86_32BIT_INIT for SPL builds
Signed-off-by: Troy Kisky
Reviewed-by: Simon Glass
---
(no changes since v1)
arch/x86/cpu/qemu/qemu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/cpu/qemu/qemu.c b/arch/x86/cpu/qemu/qemu.c
index e54082df7f9..274978c023b 100644
--- a/arch/x86/cpu/qemu/qemu.c
+++ b/arch/x86/cpu/qemu/qemu.c
@@ -97,7 +97,7 @@ static void qemu_chipset_init(void)
}
}
-#if !CONFIG_IS_ENABLED(SPL_X86_32BIT_INIT)
+#if CONFIG_IS_ENABLED(X86_32BIT_INIT)
int arch_cpu_init(void)
{
post_code(POST_CPU_INIT);
--
2.34.1
[PATCH v2 18/26] ns16550: match when to define bdf with uart code
When switching defined(CONFIG_PCI) to CONFIG_IS_ENABLED(PCI)
bdf is no longer accessible. So add preprocessor protection
to avoid access.
Signed-off-by: Troy Kisky
Reviewed-by: Simon Glass
---
Changes in v2:
- changed condition of when to include field bdf
- added protection to another instance of bdf in uart.c
- Thanks to Simon for getting this corrected
arch/x86/cpu/apollolake/uart.c | 4
include/ns16550.h | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/x86/cpu/apollolake/uart.c b/arch/x86/cpu/apollolake/uart.c
index a9362436000..878aa48ed76 100644
--- a/arch/x86/cpu/apollolake/uart.c
+++ b/arch/x86/cpu/apollolake/uart.c
@@ -79,10 +79,12 @@ void apl_uart_init(pci_dev_t bdf, ulong base)
static int apl_ns16550_probe(struct udevice *dev)
{
+#if IS_ENABLED_NOCHECK(CONFIG_PCI) && defined(CONFIG_SPL_BUILD)
struct apl_ns16550_plat *plat = dev_get_plat(dev);
if (!CONFIG_IS_ENABLED(PCI))
apl_uart_init(plat->ns16550.bdf, plat->ns16550.base);
+#endif
return ns16550_serial_probe(dev);
}
@@ -110,7 +112,9 @@ static int apl_ns16550_of_to_plat(struct udevice *dev)
ns.reg_offset = 0;
ns.clock = dtplat->clock_frequency;
ns.fcr = UART_FCR_DEFVAL;
+#if IS_ENABLED_NOCHECK(CONFIG_PCI) && defined(CONFIG_SPL_BUILD)
ns.bdf = pci_ofplat_get_devfn(dtplat->reg[0]);
+#endif
memcpy(plat, , sizeof(ns));
#else
int ret;
diff --git a/include/ns16550.h b/include/ns16550.h
index e7e68663d03..41b977b5b26 100644
--- a/include/ns16550.h
+++ b/include/ns16550.h
@@ -74,7 +74,7 @@ struct ns16550_plat {
int clock;
u32 fcr;
int flags;
-#if defined(CONFIG_PCI) && defined(CONFIG_SPL)
+#if IS_ENABLED_NOCHECK(CONFIG_PCI) && defined(CONFIG_SPL_BUILD)
int bdf;
#endif
};
--
2.34.1
[PATCH v2 26/26] CI: add test/usage_of_is_enabled_check.sh
Add script usage_of_is_enabled_check to print any configs that
use CONFIG_IS_ENABLED instead of IS_ENABLED and vice versa.
Add usage_of_is_enabled_commit.sh to generate commits to fix the above
issues.
You can remove entries from test/usage_of_is_enabled_todo.txt
or the entire file and then run
test/usage_of_is_enabled_commit.sh
to convert to suggested usage of CONFIG_IS_ENABLED/IS_ENABLED
or run test/usage_of_is_enabled_check.sh to
see which configs are still todo.
Signed-off-by: Troy Kisky
Reviewed-by: Simon Glass
---
(no changes since v1)
.azure-pipelines.yml| 11 ++
.gitlab-ci.yml | 5 +
test/usage_of_is_enabled_check.sh | 19 +++
test/usage_of_is_enabled_commit.sh | 12 ++
test/usage_of_is_enabled_correct.sh | 50 +++
test/usage_of_is_enabled_exempt.txt | 9 ++
test/usage_of_is_enabled_list.sh| 86
test/usage_of_is_enabled_splcfg.txt | 21 +++
test/usage_of_is_enabled_todo.txt | 210
9 files changed, 423 insertions(+)
create mode 100755 test/usage_of_is_enabled_check.sh
create mode 100755 test/usage_of_is_enabled_commit.sh
create mode 100755 test/usage_of_is_enabled_correct.sh
create mode 100644 test/usage_of_is_enabled_exempt.txt
create mode 100755 test/usage_of_is_enabled_list.sh
create mode 100644 test/usage_of_is_enabled_splcfg.txt
create mode 100644 test/usage_of_is_enabled_todo.txt
diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index 8327edf87aa..3f216d82a7e 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -67,6 +67,17 @@ stages:
:^doc/ :^arch/arm/dts/ :^scripts/kconfig/lkc.h
:^include/linux/kconfig.h :^tools/ && exit 1 || exit 0
+ - job: check_usage_of_is_enabled
+displayName: 'Check usage of CONFIG_IS_ENABLED vs IS_ENABLED'
+pool:
+ vmImage: $(ubuntu_vm)
+container:
+ image: $(ci_runner_image)
+ options: $(container_option)
+steps:
+ # generate list of SPL configs
+ - script: test/usage_of_is_enabled_check.sh
+
- job: cppcheck
displayName: 'Static code analysis with cppcheck'
pool:
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index c3ceca2974d..57330060b82 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -137,6 +137,11 @@ check for new CONFIG symbols outside Kconfig:
:^doc/ :^arch/arm/dts/ :^scripts/kconfig/lkc.h
:^include/linux/kconfig.h :^tools/ && exit 1 || exit 0
+check usage of CONFIG_IS_ENABLED vs IS_ENABLED:
+ stage: testsuites
+ script:
+- ./test/usage_of_is_enabled_check.sh
+
# QA jobs for code analytics
# static code analysis with cppcheck (we can add --enable=all later)
cppcheck:
diff --git a/test/usage_of_is_enabled_check.sh
b/test/usage_of_is_enabled_check.sh
new file mode 100755
index 000..6bd5d9c1ac7
--- /dev/null
+++ b/test/usage_of_is_enabled_check.sh
@@ -0,0 +1,19 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Written by Troy Kisky
+
+scriptdir=`dirname "$0"`;
+${scriptdir}/usage_of_is_enabled_list.sh | grep -vw FOO;
+if [ $? -eq 0 ] ; then
+ echo "The above may have incorrect usage of IS_ENABLED/"\
+"CONFIG_IS_ENABLED"
+ echo "Run test/usage_of_is_enabled_commit.sh and "\
+"squash with appropriate commit"
+ ret=1;
+else
+ ret=0;
+fi
+
+rm ${scriptdir}/splcfg.tmp ${scriptdir}/exclude.tmp
+exit ${ret}
diff --git a/test/usage_of_is_enabled_commit.sh
b/test/usage_of_is_enabled_commit.sh
new file mode 100755
index 000..593dbd1428c
--- /dev/null
+++ b/test/usage_of_is_enabled_commit.sh
@@ -0,0 +1,12 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Written by Troy Kisky
+
+scriptdir=`dirname "$0"`;
+${scriptdir}/usage_of_is_enabled_list.sh | \
+xargs -I {} sh -c "${scriptdir}/usage_of_is_enabled_correct.sh {}; \
+git commit -a -m\"CONFIG_{}: correct usage of CONFIG_IS_ENABLED/IS_ENABLED\";"
+
+
+rm ${scriptdir}/splcfg.tmp ${scriptdir}/exclude.tmp
diff --git a/test/usage_of_is_enabled_correct.sh
b/test/usage_of_is_enabled_correct.sh
new file mode 100755
index 000..8724747beed
--- /dev/null
+++ b/test/usage_of_is_enabled_correct.sh
@@ -0,0 +1,50 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Written by Troy Kisky
+
+scriptdir=`dirname "$0"`;
+
+if [ -z "$1" ] ; then
+ echo missing config
+ exit 1;
+fi
+if [ ! -f "${scriptdir}/splcfg.tmp" ] ; then
+ echo missing splcfg.tmp
+ exit 1;
+fi
+
+
+grep -qw $1 ${scriptdir}/splcfg.tmp
+if [ $? -ne 0 ] ; then
+# not splcfg
+# change CONFIG_IS_ENABLED to IS_ENABLED
+git grep -l \
+-e "CONFIG_IS_ENABLED($1)" \
+ | \
+xargs -IFile sh -c \
+" \
+sed -i -E \"\
+s/CONFIG_IS_ENABLED\($1\)/IS_ENABLED\(CONFIG_$1\)/g; \
+\" File";
+else
+# splcfg
+# change IS_ENABLED to CONFIG_IS_ENABLED
+# change ifdef to CONFIG_IS_ENABLED
+# change ifndef to !CONFIG_IS_ENABLED
+# change defined to CONFIG_IS_ENABLED
+git grep -l \
+
[PATCH v2 25/26] arm: cpu: armv7: ls102xa: fdt: remove eth_device support
commit e524f3a449f5 ("net: Remove eth_legacy.c")
removed struct eth_device
This prevents errors in the conversion to CONFIG_IS_ENABLED(DM_ETH).
Signed-off-by: Troy Kisky
Reviewed-by: Simon Glass
---
(no changes since v1)
arch/arm/cpu/armv7/ls102xa/fdt.c | 12
1 file changed, 12 deletions(-)
diff --git a/arch/arm/cpu/armv7/ls102xa/fdt.c b/arch/arm/cpu/armv7/ls102xa/fdt.c
index 599b7e18ef3..a5c5c780ae8 100644
--- a/arch/arm/cpu/armv7/ls102xa/fdt.c
+++ b/arch/arm/cpu/armv7/ls102xa/fdt.c
@@ -25,11 +25,7 @@ DECLARE_GLOBAL_DATA_PTR;
void ft_fixup_enet_phy_connect_type(void *fdt)
{
-#ifdef CONFIG_DM_ETH
struct udevice *dev;
-#else
- struct eth_device *dev;
-#endif
struct tsec_private *priv;
const char *enet_path, *phy_path;
char enet[16];
@@ -37,12 +33,8 @@ void ft_fixup_enet_phy_connect_type(void *fdt)
int phy_node;
int i = 0;
uint32_t ph;
-#ifdef CONFIG_DM_ETH
char *name[3] = { "ethernet@2d1", "ethernet@2d5",
"ethernet@2d9" };
-#else
- char *name[3] = { "eTSEC1", "eTSEC2", "eTSEC3" };
-#endif
for (; i < ARRAY_SIZE(name); i++) {
dev = eth_get_dev_by_name(name[i]);
@@ -53,11 +45,7 @@ void ft_fixup_enet_phy_connect_type(void *fdt)
continue;
}
-#ifdef CONFIG_DM_ETH
priv = dev_get_priv(dev);
-#else
- priv = dev->priv;
-#endif
if (priv->flags & TSEC_SGMII)
continue;
--
2.34.1
[PATCH v2 22/26] x86: cpu: i386: cpu: only set pci_ram_top if CONFIG_IS_ENABLED(PCI)
This avoids an error when ifdef CONFIG_PCI is changed to
if CONFIG_IS_ENABLED(PCI)
Signed-off-by: Troy Kisky
---
Changes in v2:
- use an accessor function gd_set_pci_ram_top
arch/x86/cpu/i386/cpu.c | 2 +-
include/asm-generic/global_data.h | 6 ++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/x86/cpu/i386/cpu.c b/arch/x86/cpu/i386/cpu.c
index c7f6c5a013e..068670dfc41 100644
--- a/arch/x86/cpu/i386/cpu.c
+++ b/arch/x86/cpu/i386/cpu.c
@@ -415,7 +415,7 @@ int cpu_phys_address_size(void)
/* Don't allow PCI region 3 to use memory in the 2-4GB memory hole */
static void setup_pci_ram_top(void)
{
- gd->pci_ram_top = 0x8000U;
+ gd_set_pci_ram_top(0x8000U);
}
static void setup_mtrr(void)
diff --git a/include/asm-generic/global_data.h
b/include/asm-generic/global_data.h
index 987fb66c17a..952e17b2c13 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -560,6 +560,12 @@ static_assert(sizeof(struct global_data) == GD_SIZE);
#define gd_event_state() NULL
#endif
+#if CONFIG_IS_ENABLED(PCI)
+#define gd_set_pci_ram_top(val)gd->pci_ram_top = val
+#else
+#define gd_set_pci_ram_top(val)
+#endif
+
/**
* enum gd_flags - global data flags
*
--
2.34.1
[PATCH v2 17/26] freescale: common: pfuze: define pfuze_mode_init only if defined(CONFIG_DM_PMIC)
pfuze_mode_init calls pmic_reg_read which is only available from
obj-$(CONFIG_$(SPL_TPL_)DM_PMIC) += pmic-uclass.o
Prepare for conversion of defined(CONFIG_DM_PMIC) to
CONFIG_IS_ENABLED(DM_PMIC).
Signed-off-by: Troy Kisky
Reviewed-by: Simon Glass
---
(no changes since v1)
board/freescale/common/pfuze.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/freescale/common/pfuze.c b/board/freescale/common/pfuze.c
index 6dca22960bf..a9288820b2e 100644
--- a/board/freescale/common/pfuze.c
+++ b/board/freescale/common/pfuze.c
@@ -91,7 +91,7 @@ struct pmic *pfuze_common_init(unsigned char i2cbus)
return p;
}
-#else
+#elif defined(CONFIG_DM_PMIC)
int pfuze_mode_init(struct udevice *dev, u32 mode)
{
unsigned char offset, i, switch_num;
--
2.34.1
[PATCH v2 16/26] m53menlo: define ft_board_setup only if CONFIG_IS_ENABLED(OF_LIBFDT)
The function ft_board_setup calls do_fixup_by_path_string
which is only available on CONFIG_IS_ENABLED(OF_LIBFDT).
This prepares for the conversion.
ft_board_setup is only called from image-fdt which is linked by
obj-$(CONFIG_$(SPL_TPL_)OF_LIBFDT) += image-fdt.o
Signed-off-by: Troy Kisky
Reviewed-by: Simon Glass
---
(no changes since v1)
board/menlo/m53menlo/m53menlo.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/board/menlo/m53menlo/m53menlo.c b/board/menlo/m53menlo/m53menlo.c
index 14324c7087d..ca3b81c57ff 100644
--- a/board/menlo/m53menlo/m53menlo.c
+++ b/board/menlo/m53menlo/m53menlo.c
@@ -264,6 +264,7 @@ void board_preboot_os(void)
gpio_direction_output(IMX_GPIO_NR(6, 0), 0);
}
+#if CONFIG_IS_ENABLED(OF_LIBFDT)
int ft_board_setup(void *blob, struct bd_info *bd)
{
if (lvds_compat_string)
@@ -272,6 +273,7 @@ int ft_board_setup(void *blob, struct bd_info *bd)
return 0;
}
+#endif
struct display_info_t const displays[] = {
{
--
2.34.1
[PATCH v2 13/26] ringneck-px30: use IS_ENABLED_NOCHECK to avoid CI test failure for ENV_IS_NOWHERE
When usage_of_is_enabled_check.sh is added, this will show a false positive for IS_ENABLED(CONFIG_ENV_IS_NOWHERE). Use IS_ENABLED_NOCHECK to avoid check and error on SPL builds. Signed-off-by: Troy Kisky --- Changes in v2: - keep #error, but change condition to use IS_ENABLED_NOCHECK board/theobroma-systems/ringneck_px30/ringneck-px30.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/theobroma-systems/ringneck_px30/ringneck-px30.c b/board/theobroma-systems/ringneck_px30/ringneck-px30.c index 47d1a40ef7c..5b2e0c7d40f 100644 --- a/board/theobroma-systems/ringneck_px30/ringneck-px30.c +++ b/board/theobroma-systems/ringneck_px30/ringneck-px30.c @@ -118,7 +118,7 @@ int mmc_get_env_dev(void) return CONFIG_SYS_MMC_ENV_DEV; } -#if !IS_ENABLED(CONFIG_ENV_IS_NOWHERE) +#if !IS_ENABLED_NOCHECK(CONFIG_ENV_IS_NOWHERE) #error Please enable CONFIG_ENV_IS_NOWHERE #endif -- 2.34.1
[PATCH v2 20/26] wandboard: use CONFIG_IS_ENABLED(SATA) instead of ifdef CONFIG_SATA
Prepare for linking setup_sata only when CONFIG_SATA/CONFIG_SPL_SATA
is defined.
Signed-off-by: Troy Kisky
---
Changes in v2:
- new in series
board/wandboard/wandboard.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/board/wandboard/wandboard.c b/board/wandboard/wandboard.c
index da995dd0f58..48914450a29 100644
--- a/board/wandboard/wandboard.c
+++ b/board/wandboard/wandboard.c
@@ -352,9 +352,8 @@ static void setup_display(void)
int board_early_init_f(void)
{
setup_iomux_uart();
-#ifdef CONFIG_SATA
- setup_sata();
-#endif
+ if (CONFIG_IS_ENABLED(SATA))
+ setup_sata();
return 0;
}
--
2.34.1
[PATCH v2 11/26] config_distro_bootcmd: remove booting environment variables from SPL environment
SPL environments don't need commands that they can never use. Avoid errors with CONFIG_IS_ENABLED conversions by skipping them now. Signed-off-by: Troy Kisky Reviewed-by: Simon Glass --- (no changes since v1) include/config_distro_bootcmd.h | 23 +++ 1 file changed, 23 insertions(+) diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h index 9d2a225e7eb..2a136b96a6d 100644 --- a/include/config_distro_bootcmd.h +++ b/include/config_distro_bootcmd.h @@ -35,11 +35,15 @@ #devtypel "_boot=" \ BOOTENV_SHARED_BLKDEV_BODY(devtypel) +#define BOOTENV_DEV_BLKDEV_NONE(devtypeu, devtypel, instance) + #define BOOTENV_DEV_BLKDEV(devtypeu, devtypel, instance) \ "bootcmd_" #devtypel #instance "=" \ "devnum=" #instance "; " \ "run " #devtypel "_boot\0" +#define BOOTENV_DEV_NAME_BLKDEV_NONE(devtypeu, devtypel, instance) + #define BOOTENV_DEV_NAME_BLKDEV(devtypeu, devtypel, instance) \ #devtypel #instance " " @@ -59,6 +63,10 @@ #define BOOTENV_SHARED_MMC BOOTENV_SHARED_BLKDEV(mmc) #define BOOTENV_DEV_MMCBOOTENV_DEV_BLKDEV #define BOOTENV_DEV_NAME_MMC BOOTENV_DEV_NAME_BLKDEV +#elif defined(CONFIG_SPL_BUILD) +#define BOOTENV_SHARED_MMC +#define BOOTENV_DEV_MMCBOOTENV_DEV_BLKDEV_NONE +#define BOOTENV_DEV_NAME_MMC BOOTENV_DEV_NAME_BLKDEV_NONE #else #define BOOTENV_SHARED_MMC #define BOOTENV_DEV_MMC \ @@ -190,6 +198,10 @@ #define BOOTENV_SHARED_SATABOOTENV_SHARED_BLKDEV(sata) #define BOOTENV_DEV_SATA BOOTENV_DEV_BLKDEV #define BOOTENV_DEV_NAME_SATA BOOTENV_DEV_NAME_BLKDEV +#elif defined(CONFIG_SPL_BUILD) +#define BOOTENV_SHARED_SATA +#define BOOTENV_DEV_SATA BOOTENV_DEV_BLKDEV_NONE +#define BOOTENV_DEV_NAME_SATA BOOTENV_DEV_NAME_BLKDEV_NONE #else #define BOOTENV_SHARED_SATA #define BOOTENV_DEV_SATA \ @@ -293,6 +305,11 @@ BOOTENV_SHARED_BLKDEV_BODY(usb) #define BOOTENV_DEV_USBBOOTENV_DEV_BLKDEV #define BOOTENV_DEV_NAME_USB BOOTENV_DEV_NAME_BLKDEV +#elif defined(CONFIG_SPL_BUILD) +#define BOOTENV_RUN_NET_USB_START +#define BOOTENV_SHARED_USB +#define BOOTENV_DEV_USBBOOTENV_DEV_BLKDEV_NONE +#define BOOTENV_DEV_NAME_USB BOOTENV_DEV_NAME_BLKDEV_NONE #else #define BOOTENV_RUN_NET_USB_START #define BOOTENV_SHARED_USB @@ -395,6 +412,9 @@ "\0" #define BOOTENV_DEV_NAME_DHCP(devtypeu, devtypel, instance) \ "dhcp " +#elif defined(CONFIG_SPL_BUILD) +#define BOOTENV_DEV_DHCP BOOTENV_DEV_BLKDEV_NONE +#define BOOTENV_DEV_NAME_DHCP BOOTENV_DEV_NAME_BLKDEV_NONE #else #define BOOTENV_DEV_DHCP \ BOOT_TARGET_DEVICES_references_DHCP_without_CONFIG_CMD_DHCP @@ -413,6 +433,9 @@ "fi\0" #define BOOTENV_DEV_NAME_PXE(devtypeu, devtypel, instance) \ "pxe " +#elif defined(CONFIG_SPL_BUILD) +#define BOOTENV_DEV_PXEBOOTENV_DEV_BLKDEV_NONE +#define BOOTENV_DEV_NAME_PXE BOOTENV_DEV_NAME_BLKDEV_NONE #else #define BOOTENV_DEV_PXE \ BOOT_TARGET_DEVICES_references_PXE_without_CONFIG_CMD_DHCP_or_PXE -- 2.34.1
[PATCH v2 09/26] tools: Makefile: prepare for CONFIG_IS_ENABLED changes by adding CONFIG_TOOLS_xxx
CONFIG_IS_ENABLED(FIT_SIGNATURE) will check for CONFIG_TOOLS_FIT_SIGNATURE. So define it now in preparation. Signed-off-by: Troy Kisky Reviewed-by: Simon Glass --- (no changes since v1) tools/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/Makefile b/tools/Makefile index 5d6284e6451..86f1b6b5049 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -162,8 +162,10 @@ ifdef CONFIG_TOOLS_LIBCRYPTO # This affects include/image.h, but including the board config file # is tricky, so manually define this options here. HOST_EXTRACFLAGS += -DCONFIG_FIT_SIGNATURE +HOST_EXTRACFLAGS += -DCONFIG_TOOLS_FIT_SIGNATURE=1 HOST_EXTRACFLAGS += -DCONFIG_FIT_SIGNATURE_MAX_SIZE=0x HOST_EXTRACFLAGS += -DCONFIG_FIT_CIPHER +HOST_EXTRACFLAGS += -DCONFIG_TOOLS_FIT_CIPHER=1 endif # MXSImage needs LibSSL -- 2.34.1
[PATCH v2 08/26] tools: prevent CONFIG_IS_ENABLED errors by including linux/kconfig.h
We need to include in order to include files that use CONFIG_IS_ENABLED. Signed-off-by: Troy Kisky Reviewed-by: Simon Glass --- Changes in v2: - include linux/kconfig.h from tools/Makefile - as suggested by Simon tools/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/Makefile b/tools/Makefile index e13effbb66a..5d6284e6451 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -298,6 +298,7 @@ endif # !LOGO_BMP # Define _GNU_SOURCE to obtain the getline prototype from stdio.h # HOST_EXTRACFLAGS += -include $(srctree)/include/compiler.h \ + -include $(srctree)/include/linux/kconfig.h \ $(patsubst -I%,-idirafter%, $(filter -I%, $(UBOOTINCLUDE))) \ -I$(srctree)/scripts/dtc/libfdt \ -I$(srctree)/tools \ -- 2.34.1
[PATCH v2 07/26] lib: sha512: prepare for CONFIG_IS_ENABLED changes
We need to include in order to include
files that use CONFIG_IS_ENABLED. TO prepare for that
don't pet the watchdog when USE_HOSTCC is defined.
Signed-off-by: Troy Kisky
Reviewed-by: Simon Glass
---
Changes in v2:
- delay include of linux/kconfig.h to do from Makefile
- as suggested by Simon
lib/sha512.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/lib/sha512.c b/lib/sha512.c
index fbe8d5f5bfe..a504281bf93 100644
--- a/lib/sha512.c
+++ b/lib/sha512.c
@@ -13,6 +13,9 @@
#ifndef USE_HOSTCC
#include
#include
+#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
+#define PET_WDG
+#endif
#else
#include
#endif /* USE_HOSTCC */
@@ -292,7 +295,7 @@ void sha384_csum_wd(const unsigned char *input, unsigned
int ilen,
unsigned char *output, unsigned int chunk_sz)
{
sha512_context ctx;
-#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
+#ifdef PET_WDG
const unsigned char *end;
unsigned char *curr;
int chunk;
@@ -300,7 +303,7 @@ void sha384_csum_wd(const unsigned char *input, unsigned
int ilen,
sha384_starts();
-#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
+#ifdef PET_WDG
curr = (unsigned char *)input;
end = input + ilen;
while (curr < end) {
@@ -355,7 +358,7 @@ void sha512_csum_wd(const unsigned char *input, unsigned
int ilen,
unsigned char *output, unsigned int chunk_sz)
{
sha512_context ctx;
-#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
+#ifdef PET_WDG
const unsigned char *end;
unsigned char *curr;
int chunk;
@@ -363,7 +366,7 @@ void sha512_csum_wd(const unsigned char *input, unsigned
int ilen,
sha512_starts();
-#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
+#ifdef PET_WDG
curr = (unsigned char *)input;
end = input + ilen;
while (curr < end) {
--
2.34.1
[PATCH v2 04/26] lib: md5: prepare for CONFIG_IS_ENABLED changes
We need to include in order to include
files that use CONFIG_IS_ENABLED. TO prepare for that
don't pet the watchdog when USE_HOSTCC is defined.
Signed-off-by: Troy Kisky
Reviewed-by: Simon Glass
---
Changes in v2:
- delay include of linux/kconfig.h to do from Makefile
- as suggested by Simon
lib/md5.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/lib/md5.c b/lib/md5.c
index 1636ab93661..20d5e87814b 100644
--- a/lib/md5.c
+++ b/lib/md5.c
@@ -29,7 +29,10 @@
#ifndef USE_HOSTCC
#include
+#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
#include
+#define PET_WDG
+#endif
#endif /* USE_HOSTCC */
#include
@@ -288,14 +291,14 @@ md5_wd(const unsigned char *input, unsigned int len,
unsigned char output[16],
unsigned int chunk_sz)
{
struct MD5Context context;
-#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
+#ifdef PET_WDG
const unsigned char *end, *curr;
int chunk;
#endif
MD5Init();
-#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
+#ifdef PET_WDG
curr = input;
end = input + len;
while (curr < end) {
--
2.34.1
[PATCH v2 05/26] lib: sha1: prepare for CONFIG_IS_ENABLED changes
We need to include in order to include
files that use CONFIG_IS_ENABLED. TO prepare for that
don't pet the watchdog when USE_HOSTCC is defined.
Signed-off-by: Troy Kisky
Reviewed-by: Simon Glass
---
Changes in v2:
- delay include of linux/kconfig.h to do from Makefile
- as suggested by Simon
lib/sha1.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/lib/sha1.c b/lib/sha1.c
index 8d074078934..cd5d7aead8d 100644
--- a/lib/sha1.c
+++ b/lib/sha1.c
@@ -19,6 +19,9 @@
#ifndef USE_HOSTCC
#include
#include
+#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
+#define PET_WDG
+#endif
#else
#include
#endif /* USE_HOSTCC */
@@ -328,14 +331,14 @@ void sha1_csum_wd(const unsigned char *input, unsigned
int ilen,
unsigned char *output, unsigned int chunk_sz)
{
sha1_context ctx;
-#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
+#ifdef PET_WDG
const unsigned char *end, *curr;
int chunk;
#endif
sha1_starts ();
-#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
+#ifdef PET_WDG
curr = input;
end = input + ilen;
while (curr < end) {
--
2.34.1
[PATCH v2 06/26] lib: sha256: prepare for CONFIG_IS_ENABLED changes
We need to include in order to include
files that use CONFIG_IS_ENABLED. TO prepare for that
don't pet the watchdog when USE_HOSTCC is defined.
Signed-off-by: Troy Kisky
Reviewed-by: Simon Glass
---
Changes in v2:
- delay include of linux/kconfig.h to do from Makefile
- as suggested by Simon
lib/sha256.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/lib/sha256.c b/lib/sha256.c
index 4d26aea1c8c..8e1c3992674 100644
--- a/lib/sha256.c
+++ b/lib/sha256.c
@@ -8,6 +8,9 @@
#ifndef USE_HOSTCC
#include
#include
+#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
+#define PET_WDG
+#endif
#else
#include
#endif /* USE_HOSTCC */
@@ -276,7 +279,7 @@ void sha256_csum_wd(const unsigned char *input, unsigned
int ilen,
unsigned char *output, unsigned int chunk_sz)
{
sha256_context ctx;
-#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
+#ifdef PET_WDG
const unsigned char *end;
unsigned char *curr;
int chunk;
@@ -284,7 +287,7 @@ void sha256_csum_wd(const unsigned char *input, unsigned
int ilen,
sha256_starts();
-#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
+#ifdef PET_WDG
curr = (unsigned char *)input;
end = input + ilen;
while (curr < end) {
--
2.34.1
[PATCH v2 03/26] lib: crc32: prepare for CONFIG_IS_ENABLED changes
We need to include in order to include
files that use CONFIG_IS_ENABLED. TO prepare for that
be more direct with using defined(USE_HOSTCC).
Signed-off-by: Troy Kisky
Reviewed-by: Simon Glass
---
Changes in v2:
- delay include of linux/kconfig.h to do from Makefile
- as suggested by Simon
lib/crc32.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/lib/crc32.c b/lib/crc32.c
index aa94d70ef3e..12c104c62a4 100644
--- a/lib/crc32.c
+++ b/lib/crc32.c
@@ -14,11 +14,14 @@
#else
#include
#include
+#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
+#define PET_WDG
+#endif
#endif
#include
#include
-#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
+#ifdef PET_WDG
#include
#endif
#include "u-boot/zlib.h"
@@ -84,7 +87,7 @@ static void __efi_runtime make_crc_table(void)
}
crc_table_empty = 0;
}
-#elif !defined(CONFIG_ARM64_CRC32)
+#elif !defined(CONFIG_ARM64_CRC32) || defined(USE_HOSTCC)
/*
* Table of CRC-32's of all single-byte values (made by make_crc_table)
*/
@@ -184,7 +187,7 @@ const uint32_t * ZEXPORT get_crc_table()
*/
uint32_t __efi_runtime crc32_no_comp(uint32_t crc, const Bytef *buf, uInt len)
{
-#ifdef CONFIG_ARM64_CRC32
+#if defined(CONFIG_ARM64_CRC32) && !defined(USE_HOSTCC)
crc = cpu_to_le32(crc);
while (len--)
crc = __builtin_aarch64_crc32b(crc, *buf++);
@@ -243,7 +246,7 @@ uint32_t __efi_runtime crc32(uint32_t crc, const Bytef *p,
uInt len)
uint32_t crc32_wd(uint32_t crc, const unsigned char *buf, uInt len,
uInt chunk_sz)
{
-#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
+#ifdef PET_WDG
const unsigned char *end, *curr;
int chunk;
--
2.34.1
[PATCH v2 02/26] cmd: nvedit: check for ENV_SUPPORT
Avoid error messages when SPL,TPL,VPL build don't
have the environment options of the main build.
This is needed when defined(CONFIG_ENV_IS_IN_xxx) is changed
to CONFIG_IS_ENABLED(ENV_IS_IN_xxx).
Signed-off-by: Troy Kisky
Reviewed-by: Simon Glass
---
(no changes since v1)
cmd/nvedit.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/cmd/nvedit.c b/cmd/nvedit.c
index 7cbc3fd573a..ef0fe55431c 100644
--- a/cmd/nvedit.c
+++ b/cmd/nvedit.c
@@ -43,6 +43,7 @@
DECLARE_GLOBAL_DATA_PTR;
+#if CONFIG_IS_ENABLED(ENV_SUPPORT)
#ifdefined(CONFIG_ENV_IS_IN_EEPROM)|| \
defined(CONFIG_ENV_IS_IN_FLASH) || \
defined(CONFIG_ENV_IS_IN_MMC) || \
@@ -60,10 +61,12 @@ DECLARE_GLOBAL_DATA_PTR;
#endif
#if!defined(ENV_IS_IN_DEVICE) && \
- !defined(CONFIG_ENV_IS_NOWHERE)
+ !defined(CONFIG_ENV_IS_NOWHERE) && \
+ !defined(CONFIG_VPL_BUILD)
# error Define one of CONFIG_ENV_IS_IN_{EEPROM|FLASH|MMC|FAT|EXT4|\
NAND|NVRAM|ONENAND|SATA|SPI_FLASH|REMOTE|UBI} or CONFIG_ENV_IS_NOWHERE
#endif
+#endif
/*
* Maximum expected input data size for import command
--
2.34.1
[PATCH v2 01/26] kconfig: add IS_ENABLED_NOCHECK to bypass usage_of_is_enabled_check
This is for use when a config with an SPL version needs to always check the non-spl verion of the config. It avoids error messages from CI test script usage_of_is_enabled_check.sh Signed-off-by: Troy Kisky --- Changes in v2: - new patch include/linux/kconfig.h | 5 + 1 file changed, 5 insertions(+) diff --git a/include/linux/kconfig.h b/include/linux/kconfig.h index 2bc704e1104..19b71723ab3 100644 --- a/include/linux/kconfig.h +++ b/include/linux/kconfig.h @@ -27,6 +27,11 @@ * 0 otherwise. */ #define IS_ENABLED(option) config_enabled(option, 0) +/* + * Using IS_ENABLED_NOCHECK instead of IS_ENABLED prevents + * complaints from test/usage_of_is_enabled_check.sh + */ +#define IS_ENABLED_NOCHECK(option) config_enabled(option, 0) /* * U-Boot add-on: Helper macros to reference to different macros (prefixed by -- 2.34.1
Re: [RFC PATCH v3 3/9] clk: renesas: add R906G032 driver
Hi Marek, On Fri, Feb 24, 2023 at 12:05 PM Marek Vasut wrote: > > Could you at least submit the clean up to Linux and then sync the result > to U-Boot, and indicate the Linux clock table came from commit > with extra patch on top ? Yes will do. I am refreshing my linux-side patch as we speak. Ralph
Re: [RFC PATCH v3 3/9] clk: renesas: add R906G032 driver
On 2/24/23 16:14, Ralph Siemsen wrote: On Thu, Feb 23, 2023 at 9:09 AM Miquel Raynal wrote: Hi Marek, marek.va...@mailbox.org wrote on Thu, 23 Feb 2023 14:56:41 +0100: Either way is fine by me, I just want to be sure the u-boot clock tables are in sync with Linux as much as possible, and can be easily resynced in the future, that's all. Of course. The fix is mainline already, so on that regard we should be fine. Right, so mainline has all the fixes, the only thing missing there is the "cleanup" of the clock tables, which I have done in the u-boot version under review. Assuming this is satisfactory, I will aim to get the same cleanup done on the clock tables in the kernel side, so they are in sync with u-boot. Could you at least submit the clean up to Linux and then sync the result to U-Boot, and indicate the Linux clock table came from commit with extra patch on top ? I think that would be best.
Re: [PATCH] ARM: dts: at91: sama7g5: fix clock id for ebi node
On 23.02.2023 13:28, Mihai Sain wrote:
> The PMC_MCK1 clock id for the ebi node is 23.
>
> Fixes: 4ce85577ac ("ARM: dts: at91: sama7g5/sama7g5ek: align with Linux DT")
> Signed-off-by: Mihai Sain
Reviewed-by: Claudiu Beznea
> ---
> arch/arm/dts/sama7g5.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/dts/sama7g5.dtsi b/arch/arm/dts/sama7g5.dtsi
> index d38090d7dd..a802153af8 100644
> --- a/arch/arm/dts/sama7g5.dtsi
> +++ b/arch/arm/dts/sama7g5.dtsi
> @@ -150,7 +150,7 @@
> 0x1 0x0 0x4800 0x800
> 0x2 0x0 0x5000 0x800
> 0x3 0x0 0x5800 0x800>;
> - clocks = < PMC_TYPE_CORE 13>; /* PMC_MCK1 */
> + clocks = < PMC_TYPE_CORE 23>; /* PMC_MCK1 */
> status = "disabled";
>
> nand_controller: nand-controller {
Re: [PATCH 2/2] imx93_evk: enable ADC
On 24/02/2023 15:31, Fabio Estevam wrote: Hi Luca, On Fri, Feb 24, 2023 at 4:59 AM Luca Ellero wrote: Hi Fabio, thank you for your reply. Ok, I will add a comment to the patch and fix DT node. Should I resend only this patch or both? Please resend the whole series. My suggestion: 1/3 - ADC driver 2/3 - Sync U-Boot imx93 evk dts with the one from linux-next 20230224 3/3 - Enable the ADC driver in the imx93 evk defconfig Hi Fabio, ok, thanks for your suggestions. Regards -- Luca Ellero E-mail: luca.ell...@brickedbrain.com Internet: www.brickedbrain.com
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
> Please note that this patch is sent to the list a s reply to the > RFC patchset from Pali. Something went wrong here, so that the > commit subject was not used. Also for the 2nd patch. Ah, sorry, I'm not really set up for this. The first patch branches from Pali's RFC, though, so maybe it would be best to include my two when the final mvebu changes are sent in? > You are removing the bubt cmd here. This is most likely a mistake. I had to double check this as well, but CONFIG_MMC_BROKEN_CD also enables bubt for some reason, so it's definitely still included in the config but gets removed by savedefconfig. Martin
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
Hi Martin, On 2/24/23 16:07, Martin Rowe wrote: [PATCH 1/2] arm: mvebu: clearfog: Fix MMC detection A388 Clearfog MMC is either SD Card or eMMC with different behaviour for both. Setting MMC_BROKEN_CD allows both to correctly detect MMC. Signed-off-by: Martin Rowe Please note that this patch is sent to the list a s reply to the RFC patchset from Pali. Something went wrong here, so that the commit subject was not used. Also for the 2nd patch. Another comment below. --- configs/clearfog_defconfig | 3 +-- configs/clearfog_sata_defconfig | 8 2 files changed, 5 insertions(+), 6 deletions(-) diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig index 8cd35f9f1a..24e7c16ac7 100644 --- a/configs/clearfog_defconfig +++ b/configs/clearfog_defconfig @@ -46,7 +46,6 @@ CONFIG_CMD_USB=y CONFIG_CMD_TFTPPUT=y CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y -CONFIG_CMD_MVEBU_BUBT=y You are removing the bubt cmd here. This is most likely a mistake. So please re-send the patches with a correct subject and also without removing the bubt cmd support. Thanks, Stefan CONFIG_ENV_OVERWRITE=y CONFIG_ENV_MIN_ENTRIES=128 CONFIG_ARP_TIMEOUT=200 @@ -59,7 +58,7 @@ CONFIG_DM_I2C=y CONFIG_SYS_I2C_MVTWSI=y CONFIG_I2C_EEPROM=y CONFIG_SPL_I2C_EEPROM=y -CONFIG_SUPPORT_EMMC_BOOT=y +CONFIG_MMC_BROKEN_CD=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_SDMA=y CONFIG_MMC_SDHCI_MV=y diff --git a/configs/clearfog_sata_defconfig b/configs/clearfog_sata_defconfig index e9b36150ea..84f900bf50 100644 --- a/configs/clearfog_sata_defconfig +++ b/configs/clearfog_sata_defconfig @@ -6,11 +6,14 @@ CONFIG_TEXT_BASE=0x0080 CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_NR_DRAM_BANKS=2 +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff CONFIG_TARGET_CLEARFOG=y CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog" CONFIG_SPL_TEXT_BASE=0x4030 CONFIG_SPL_SERIAL=y +CONFIG_SPL_STACK=0x4002c000 CONFIG_SPL=y CONFIG_DEBUG_UART_BASE=0xf1012000 CONFIG_DEBUG_UART_CLOCK=25000 @@ -18,8 +21,6 @@ CONFIG_SYS_LOAD_ADDR=0x80 CONFIG_DEBUG_UART=y CONFIG_AHCI=y CONFIG_DISTRO_DEFAULTS=y -CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y -CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff CONFIG_BOOTDELAY=3 CONFIG_USE_PREBOOT=y CONFIG_SYS_CONSOLE_INFO_QUIET=y @@ -31,7 +32,6 @@ CONFIG_SPL_BSS_START_ADDR=0x40023000 CONFIG_SPL_BSS_MAX_SIZE=0x4000 CONFIG_SPL_SYS_MALLOC_SIMPLE=y # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set -CONFIG_SPL_STACK=0x4002c000 CONFIG_SPL_I2C=y CONFIG_SYS_MAXARGS=32 CONFIG_CMD_TLV_EEPROM=y @@ -46,7 +46,6 @@ CONFIG_CMD_USB=y CONFIG_CMD_TFTPPUT=y CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y -CONFIG_CMD_MVEBU_BUBT=y CONFIG_ENV_OVERWRITE=y CONFIG_ENV_MIN_ENTRIES=128 CONFIG_ARP_TIMEOUT=200 @@ -59,6 +58,7 @@ CONFIG_DM_I2C=y CONFIG_SYS_I2C_MVTWSI=y CONFIG_I2C_EEPROM=y CONFIG_SPL_I2C_EEPROM=y +CONFIG_MMC_BROKEN_CD=y CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_SDMA=y Viele Grüße, Stefan Roese -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [RFC PATCH v3 5/9] ram: cadence: add driver for Cadence EDAC
Hi Bryan, On Thu, Feb 23, 2023 at 2:54 PM Bryan Brattlof wrote: > > Hi Ralph! > Love seeing more boards here, though I know of a few chips that use some > type of cadence controller. I'm just curious if it would it make sense > to name this with some type of Renesas specific branding? Indeed the this IP from Cadence likely is used in quite a few places. However it is usually quite difficult to figure out exactly which version of the IP is present, what bugs/workarounds are needed, etc. I am fine with renaming this in a more renesas-specific manner (suggestions welcomed!). On the other hand, it would good to try and encourage having one driver for this, rather than a bunch of similar-but-not-quite-equivalent ones scattered about. Perhaps a non-specific name might help? Ralph
Re: Pull request for efi-2023-04-rc3-2
On Fri, Feb 24, 2023 at 03:44:19PM +0100, Heinrich Schuchardt wrote: > On 2/24/23 15:42, Tom Rini wrote: > > On Fri, Feb 24, 2023 at 11:02:57AM +0100, Heinrich Schuchardt wrote: > > > The following changes since commit > > > 8c3acb726ef083d3d5de12f20318ee0e5070: > > > > > >Merge branch 'master' of > > > https://source.denx.de/u-boot/custodians/u-boot-usb (2023-02-22 13:36:29 > > > -0500) > > > > > > are available in the Git repository at: > > > > > >https://source.denx.de/u-boot/custodians/u-boot-efi.git > > > tags/efi-2023-04-rc3-2 > > > > > > for you to fetch changes up to 0bb5d6b1e4105ec4215239958830a396658bfed8: > > > > > >cmd: bootefi: allocate device-tree copy from high memory (2023-02-24 > > > 07:44:35 +0100) > > > > > > Gitlab CI showed no issues: > > > https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/15340 > > > > > > > > > Pull request for efi-2023-04-rc3-2 > > > > > > Documentation: > > > Fix links to fwu_updates.rst > > > > This is a fix. > > > > > > > > UEFI: > > > Allocate device-tree copy from high memory in bootefi command > > > > This I think counts as a fix, but I'm a little confused about allocate > > in this context. Can you point me at the patch please? > > > > > Correct attributes checks in SetVariable() > > > > This is a fix.. > > > > > Other: > > > Allow SPL to load main U-Boot via partition type GUID > > > > This is new functionality, and I didn't quite see that everyone agreed > > this was a good idea? Not for master at this point in the cycle. > > Would you take it for next? The last feedback I saw was that the idea isn't exactly workable and presents its own challenges for distributions / OSes, or did I miss some further messages? -- Tom signature.asc Description: PGP signature
Re: Pull request for efi-2023-04-rc3-2
On Fri, Feb 24, 2023 at 04:52:06PM +0200, Ilias Apalodimas wrote: > Hi all, > > Just to put some context > > On Fri, 24 Feb 2023 at 16:44, Heinrich Schuchardt > wrote: > > > > On 2/24/23 15:42, Tom Rini wrote: > > > On Fri, Feb 24, 2023 at 11:02:57AM +0100, Heinrich Schuchardt wrote: > > >> The following changes since commit > > >> 8c3acb726ef083d3d5de12f20318ee0e5070: > > >> > > >>Merge branch 'master' of > > >> https://source.denx.de/u-boot/custodians/u-boot-usb (2023-02-22 13:36:29 > > >> -0500) > > >> > > >> are available in the Git repository at: > > >> > > >>https://source.denx.de/u-boot/custodians/u-boot-efi.git > > >> tags/efi-2023-04-rc3-2 > > >> > > >> for you to fetch changes up to 0bb5d6b1e4105ec4215239958830a396658bfed8: > > >> > > >>cmd: bootefi: allocate device-tree copy from high memory (2023-02-24 > > >> 07:44:35 +0100) > > >> > > >> Gitlab CI showed no issues: > > >> https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/15340 > > >> > > >> > > >> Pull request for efi-2023-04-rc3-2 > > >> > > >> Documentation: > > >> Fix links to fwu_updates.rst > > > > > > This is a fix. > > > > > >> > > >> UEFI: > > >> Allocate device-tree copy from high memory in bootefi command > > > > > > This I think counts as a fix, but I'm a little confused about allocate > > > in this context. Can you point me at the patch please? > > https://source.denx.de/u-boot/custodians/u-boot-efi/-/commit/0bb5d6b1e4105ec4215239958830a396658bfed8 > > The TL;DR is that we were placing the DT on 127mb. This might > overwrite previously loaded binaries. The efi-stub of the linux kernel > doesn't use the DTB in place. Instead, it copies it and adds some > nodes for the efi-stub -> kernel proper handover (e.g a kaslr-seed). > So we as far as linux is concerned we are free to place the DT > wherever we want. > > Unless people from risc-v want this in *now*, we are better of landing > this in -next. Ah, thanks. So the sinking feeling that I had that we had duplicated the complex logic of "where _IS_ a safe place in memory to put things" was done again, but without being configurable, was right. Sigh. I don't have an idea on here's how we solve it, but I do worry we're going to have, once again, some of the overlap and silent corruption problems of old. But maybe not this time, since we're finally getting payloads that we can determine the BSS of, etc. > > >> Correct attributes checks in SetVariable() > > This can wait. This fixes one minor issue on the SystemReady Security > extensions test suite. This is a test suite (mostly running as EFI > apps) from Arm to check conformance for UEFI Secure Boot and Measured > boot. Ah, OK. -- Tom signature.asc Description: PGP signature
Re: [RFC PATCH v3 3/9] clk: renesas: add R906G032 driver
On Thu, Feb 23, 2023 at 9:09 AM Miquel Raynal wrote: > > Hi Marek, > > marek.va...@mailbox.org wrote on Thu, 23 Feb 2023 14:56:41 +0100: > > > > Either way is fine by me, I just want to be sure the u-boot clock tables > > are in sync with Linux as much as possible, and can be easily resynced in > > the future, that's all. > > Of course. The fix is mainline already, so on that regard we should be > fine. Right, so mainline has all the fixes, the only thing missing there is the "cleanup" of the clock tables, which I have done in the u-boot version under review. Assuming this is satisfactory, I will aim to get the same cleanup done on the clock tables in the kernel side, so they are in sync with u-boot. Ralp
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
[PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting This new clearfog_spi_defconfig file is copy of existing clearfog_defconfig file and changed to instruct build system to generate final kwbimage for SPI booting and to store the environment in SPI as well. Signed-off-by: Martin Rowe --- configs/clearfog_spi_defconfig | 88 ++ 1 file changed, 88 insertions(+) create mode 100644 configs/clearfog_spi_defconfig diff --git a/configs/clearfog_spi_defconfig b/configs/clearfog_spi_defconfig new file mode 100644 index 00..31b1e9fce8 --- /dev/null +++ b/configs/clearfog_spi_defconfig @@ -0,0 +1,88 @@ +CONFIG_ARM=y +CONFIG_ARCH_CPU_INIT=y +CONFIG_SYS_THUMB_BUILD=y +CONFIG_ARCH_MVEBU=y +CONFIG_TEXT_BASE=0x0080 +CONFIG_SPL_GPIO=y +CONFIG_SPL_LIBCOMMON_SUPPORT=y +CONFIG_SPL_LIBGENERIC_SUPPORT=y +CONFIG_NR_DRAM_BANKS=2 +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff +CONFIG_TARGET_CLEARFOG=y +CONFIG_ENV_SECT_SIZE=0x1 +CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog" +CONFIG_SPL_TEXT_BASE=0x4030 +CONFIG_SPL_MMC=y +CONFIG_SPL_SERIAL=y +CONFIG_SPL_STACK=0x4002c000 +CONFIG_SPL=y +CONFIG_DEBUG_UART_BASE=0xf1012000 +CONFIG_DEBUG_UART_CLOCK=25000 +CONFIG_SPL_LIBDISK_SUPPORT=y +# CONFIG_SPL_SPI is not set +CONFIG_SYS_LOAD_ADDR=0x80 +CONFIG_DEBUG_UART=y +CONFIG_AHCI=y +CONFIG_DISTRO_DEFAULTS=y +CONFIG_BOOTDELAY=3 +CONFIG_USE_PREBOOT=y +CONFIG_SYS_CONSOLE_INFO_QUIET=y +# CONFIG_DISPLAY_BOARDINFO is not set +CONFIG_DISPLAY_BOARDINFO_LATE=y +CONFIG_SPL_MAX_SIZE=0x22fd0 +CONFIG_SPL_HAS_BSS_LINKER_SECTION=y +CONFIG_SPL_BSS_START_ADDR=0x40023000 +CONFIG_SPL_BSS_MAX_SIZE=0x4000 +CONFIG_SPL_SYS_MALLOC_SIMPLE=y +# CONFIG_SPL_SHARES_INIT_SP_ADDR is not set +CONFIG_SPL_I2C=y +CONFIG_SYS_MAXARGS=32 +CONFIG_CMD_TLV_EEPROM=y +CONFIG_SPL_CMD_TLV_EEPROM=y +# CONFIG_CMD_FLASH is not set +CONFIG_CMD_GPIO=y +CONFIG_CMD_I2C=y +CONFIG_CMD_MMC=y +CONFIG_CMD_PCI=y +CONFIG_CMD_SPI=y +CONFIG_CMD_USB=y +CONFIG_CMD_TFTPPUT=y +CONFIG_CMD_CACHE=y +CONFIG_CMD_TIME=y +CONFIG_ENV_OVERWRITE=y +CONFIG_ENV_MIN_ENTRIES=128 +CONFIG_ARP_TIMEOUT=200 +CONFIG_NET_RETRY_COUNT=50 +CONFIG_NET_RANDOM_ETHADDR=y +CONFIG_SPL_OF_TRANSLATE=y +CONFIG_AHCI_MVEBU=y +CONFIG_DM_PCA953X=y +CONFIG_DM_I2C=y +CONFIG_SYS_I2C_MVTWSI=y +CONFIG_I2C_EEPROM=y +CONFIG_SPL_I2C_EEPROM=y +CONFIG_MMC_BROKEN_CD=y +CONFIG_SPL_DM_MMC=y +CONFIG_SUPPORT_EMMC_BOOT=y +CONFIG_MMC_SDHCI=y +CONFIG_MMC_SDHCI_SDMA=y +CONFIG_MMC_SDHCI_MV=y +CONFIG_MTD=y +CONFIG_SF_DEFAULT_BUS=1 +CONFIG_SPI_FLASH_WINBOND=y +CONFIG_SPI_FLASH_MTD=y +CONFIG_PHY_MARVELL=y +CONFIG_PHY_GIGE=y +CONFIG_MVNETA=y +CONFIG_MII=y +CONFIG_MVMDIO=y +CONFIG_PCI=y +CONFIG_PCI_MVEBU=y +CONFIG_SCSI=y +CONFIG_SPL_DEBUG_UART_BASE=0xd0012000 +CONFIG_DEBUG_UART_SHIFT=2 +CONFIG_SYS_NS16550=y +CONFIG_KIRKWOOD_SPI=y +CONFIG_USB=y +CONFIG_USB_XHCI_HCD=y -- 2.39.2 On Fri, 24 Feb 2023 at 06:27, Martin Rowe wrote: > > > > boot0 - zeroed > > > boot1 - u-boot (with local version 'boot1') > > > user - u-boot (with local version 'user') > > Can you check if boot_ack argument has some effect on the initial > > choice? Or if completely disabling boot partitions (boot_enable to 0) > > have some effect? > > boot_ack doesn't appear to do anything. I can only set 0 or 1 and > there's no noticeable change to the boot process. > > Setting `mmc partconf 0 0 0 0` with the same setup as described above > results in the same BootROM fallback from BOOT0 to BOOT1, then SPL in > BOOT1 loads u-boot from the user area, which is identical to the `mmc > partconf 0 0 7 0` flow. > > > If really EXT_CSD[179] register is completely ignored we may change SPL > > to always boot from BOOT0 (when eMMC with boot partitions is used) and > > if it fails then fallback to BootROM booting. > > Is there a way of knowing where the SPL was loaded from? Because it > would make sense to me that if SPL was loaded from BOOT1 to try and > load u-boot from BOOT1 as well, or from BOOT0 if SPL was loaded from > BOOT0, etc. Having u-boot loaded from a different location is not what > I expected and seems like it would cause a lot of confusion, > especially in a failed A/B rollout. BootROM seems to completely ignore > the setting, so I agree that SPL should ignore it as well, but > hardcoding BOOT0 (or even setting the partition as a compile-time > option) is probably not a great outcome. > > Two observations that might help here: > 1. After reset, running `mmc partconf 0` always shows PARTITION_ACCESS > is set to 0x0, even it it was set to something else prior to reset > 2. With the same setup as described above and `mmc partconf 0 0 1 1` > the SPL eventually times out trying to load from the zeroed BOOT0 and > returns to BootROM, which results in u-boot being loaded from BOOT1: > = > BootROM - 1.73 > > Booting from MMC > BootROM: Bad header at offset > BootROM: Bad header at offset 0020 > Switching BootPartitions. > > U-Boot SPL
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
[PATCH 1/2] arm: mvebu: clearfog: Fix MMC detection A388 Clearfog MMC is either SD Card or eMMC with different behaviour for both. Setting MMC_BROKEN_CD allows both to correctly detect MMC. Signed-off-by: Martin Rowe --- configs/clearfog_defconfig | 3 +-- configs/clearfog_sata_defconfig | 8 2 files changed, 5 insertions(+), 6 deletions(-) diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig index 8cd35f9f1a..24e7c16ac7 100644 --- a/configs/clearfog_defconfig +++ b/configs/clearfog_defconfig @@ -46,7 +46,6 @@ CONFIG_CMD_USB=y CONFIG_CMD_TFTPPUT=y CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y -CONFIG_CMD_MVEBU_BUBT=y CONFIG_ENV_OVERWRITE=y CONFIG_ENV_MIN_ENTRIES=128 CONFIG_ARP_TIMEOUT=200 @@ -59,7 +58,7 @@ CONFIG_DM_I2C=y CONFIG_SYS_I2C_MVTWSI=y CONFIG_I2C_EEPROM=y CONFIG_SPL_I2C_EEPROM=y -CONFIG_SUPPORT_EMMC_BOOT=y +CONFIG_MMC_BROKEN_CD=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_SDMA=y CONFIG_MMC_SDHCI_MV=y diff --git a/configs/clearfog_sata_defconfig b/configs/clearfog_sata_defconfig index e9b36150ea..84f900bf50 100644 --- a/configs/clearfog_sata_defconfig +++ b/configs/clearfog_sata_defconfig @@ -6,11 +6,14 @@ CONFIG_TEXT_BASE=0x0080 CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_NR_DRAM_BANKS=2 +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff CONFIG_TARGET_CLEARFOG=y CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog" CONFIG_SPL_TEXT_BASE=0x4030 CONFIG_SPL_SERIAL=y +CONFIG_SPL_STACK=0x4002c000 CONFIG_SPL=y CONFIG_DEBUG_UART_BASE=0xf1012000 CONFIG_DEBUG_UART_CLOCK=25000 @@ -18,8 +21,6 @@ CONFIG_SYS_LOAD_ADDR=0x80 CONFIG_DEBUG_UART=y CONFIG_AHCI=y CONFIG_DISTRO_DEFAULTS=y -CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y -CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff CONFIG_BOOTDELAY=3 CONFIG_USE_PREBOOT=y CONFIG_SYS_CONSOLE_INFO_QUIET=y @@ -31,7 +32,6 @@ CONFIG_SPL_BSS_START_ADDR=0x40023000 CONFIG_SPL_BSS_MAX_SIZE=0x4000 CONFIG_SPL_SYS_MALLOC_SIMPLE=y # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set -CONFIG_SPL_STACK=0x4002c000 CONFIG_SPL_I2C=y CONFIG_SYS_MAXARGS=32 CONFIG_CMD_TLV_EEPROM=y @@ -46,7 +46,6 @@ CONFIG_CMD_USB=y CONFIG_CMD_TFTPPUT=y CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y -CONFIG_CMD_MVEBU_BUBT=y CONFIG_ENV_OVERWRITE=y CONFIG_ENV_MIN_ENTRIES=128 CONFIG_ARP_TIMEOUT=200 @@ -59,6 +58,7 @@ CONFIG_DM_I2C=y CONFIG_SYS_I2C_MVTWSI=y CONFIG_I2C_EEPROM=y CONFIG_SPL_I2C_EEPROM=y +CONFIG_MMC_BROKEN_CD=y CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_SDMA=y -- 2.39.2 On Wed, 22 Feb 2023 at 21:23, Pali Rohár wrote: > > On Wednesday 22 February 2023 21:20:58 Martin Rowe wrote: > > Hi > > > > > Could you send a patch which adds appropriate defconfig file for SPI > > > boot? So this configuration would be tested in U-Boot CI automatically. > > > > Will do. Does it need to be the same as the other defconfigs > > otherwise? I suggest putting the environment in SPI as well if u-boot > > is already there (default is MMC). > > Yes, it makes sense. > > > > Have you tried booting from eMMC boot partition or eMMC user data > > > partition? Because all 3 options should work, but I'm not fully sure if > > > BootROM choose partition from eMMC register or if tries all 3 in some > > > order. This is something which needs to be checked and verified. > > > > I only tested from boot0, but will test the others as well. I've only > > ever seen it fallback, but I'll check the new changes and see if they > > can select the boot device. > > Ok. When testing, ensure that you erase uboots from other partitions or > check that it boots the correct version from the correction partition. > > > > Could you try to use SolidRun eMMC patch which SolidRun has for years in > > > its repository? > > > > > > https://github.com/SolidRun/u-boot/commit/19a96f7c40a8fc1d0a6546ac2418d966e5840a99 > > > > > > Probably same functionality is needed to implement also into > > > board_fix_fdt() function enabled by CONFIG_OF_BOARD_FIXUP. Look for > > > other boards how they use CONFIG_OF_BOARD_FIXUP. > > > > > > And if ... you can try to put this logic in board_late_init() function. > > > For inspiration look into Espressobin board which deactivates eMMC at > > > runtime by checking existence of eMMC: > > > https://source.denx.de/u-boot/u-boot/-/blob/master/board/Marvell/mvebu_armada-37xx/board.c > > > > This is still on my TODO from earlier discussions. > > > > > There is still missing documentation for kwbimage config file format. > > > It should be in "kwbimage" section of ./doc/mkimage.1 file but there is > > > only placeholder... It would be nice if somebody can take it and write > > > it. > > > > I'm not sure if I have the expertise for this, but can take a look as well. > > > > Martin > > Ok.
Re: Pull request for efi-2023-04-rc3-2
Hi all, Just to put some context On Fri, 24 Feb 2023 at 16:44, Heinrich Schuchardt wrote: > > On 2/24/23 15:42, Tom Rini wrote: > > On Fri, Feb 24, 2023 at 11:02:57AM +0100, Heinrich Schuchardt wrote: > >> The following changes since commit > >> 8c3acb726ef083d3d5de12f20318ee0e5070: > >> > >>Merge branch 'master' of > >> https://source.denx.de/u-boot/custodians/u-boot-usb (2023-02-22 13:36:29 > >> -0500) > >> > >> are available in the Git repository at: > >> > >>https://source.denx.de/u-boot/custodians/u-boot-efi.git > >> tags/efi-2023-04-rc3-2 > >> > >> for you to fetch changes up to 0bb5d6b1e4105ec4215239958830a396658bfed8: > >> > >>cmd: bootefi: allocate device-tree copy from high memory (2023-02-24 > >> 07:44:35 +0100) > >> > >> Gitlab CI showed no issues: > >> https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/15340 > >> > >> > >> Pull request for efi-2023-04-rc3-2 > >> > >> Documentation: > >> Fix links to fwu_updates.rst > > > > This is a fix. > > > >> > >> UEFI: > >> Allocate device-tree copy from high memory in bootefi command > > > > This I think counts as a fix, but I'm a little confused about allocate > > in this context. Can you point me at the patch please? https://source.denx.de/u-boot/custodians/u-boot-efi/-/commit/0bb5d6b1e4105ec4215239958830a396658bfed8 The TL;DR is that we were placing the DT on 127mb. This might overwrite previously loaded binaries. The efi-stub of the linux kernel doesn't use the DTB in place. Instead, it copies it and adds some nodes for the efi-stub -> kernel proper handover (e.g a kaslr-seed). So we as far as linux is concerned we are free to place the DT wherever we want. Unless people from risc-v want this in *now*, we are better of landing this in -next. > > > >> Correct attributes checks in SetVariable() This can wait. This fixes one minor issue on the SystemReady Security extensions test suite. This is a test suite (mostly running as EFI apps) from Arm to check conformance for UEFI Secure Boot and Measured boot. > > > > This is a fix.. > > > >> Other: > >> Allow SPL to load main U-Boot via partition type GUID > > > > This is new functionality, and I didn't quite see that everyone agreed > > this was a good idea? Not for master at this point in the cycle. > > Would you take it for next? Regards /Ilias > > Best regards > > Heinrich > > > > >> Test case for crc8 function > > > > This I suppose can count as a fix. > > >
Re: Pull request for efi-2023-04-rc3-2
On 2/24/23 15:42, Tom Rini wrote: On Fri, Feb 24, 2023 at 11:02:57AM +0100, Heinrich Schuchardt wrote: The following changes since commit 8c3acb726ef083d3d5de12f20318ee0e5070: Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-usb (2023-02-22 13:36:29 -0500) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-efi.git tags/efi-2023-04-rc3-2 for you to fetch changes up to 0bb5d6b1e4105ec4215239958830a396658bfed8: cmd: bootefi: allocate device-tree copy from high memory (2023-02-24 07:44:35 +0100) Gitlab CI showed no issues: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/15340 Pull request for efi-2023-04-rc3-2 Documentation: Fix links to fwu_updates.rst This is a fix. UEFI: Allocate device-tree copy from high memory in bootefi command This I think counts as a fix, but I'm a little confused about allocate in this context. Can you point me at the patch please? Correct attributes checks in SetVariable() This is a fix.. Other: Allow SPL to load main U-Boot via partition type GUID This is new functionality, and I didn't quite see that everyone agreed this was a good idea? Not for master at this point in the cycle. Would you take it for next? Best regards Heinrich Test case for crc8 function This I suppose can count as a fix.
Re: Pull request, u-boot-tegra/master
On Thu, Feb 23, 2023 at 02:25:04PM -0700, Tom Warren wrote: > Tom, > > Please pull u-boot-tegra/master into U-Boot/master. Thanks. > It has passed 'buildman tegra' w/o error, and Thierry has tested it on his > Tegra boards. > > The following changes since commit 8c3acb726ef083d3d5de12f20318ee0e5070: > > Merge branch 'master' of > https://source.denx.de/u-boot/custodians/u-boot-usb (2023-02-22 13:36:29 > -0500) > > are available in the git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-tegra.git master > > for you to fetch changes up to 5a8fe1ee818e0f8a74fa088f6a3d705a01b6afbe: > > ARM: tegra20: implement BCT patching (2023-02-23 12:55:37 -0700) > This is a bit later than I'd like in general, but I know you've been working at this for a bit, and since it's tested on a wide array of the targets in question, I'll take it this time, to master. Also please push it through CI on source.denx.de in the future, I had to fixup a few doc problems (and CI should be enabled). Thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] trace: Relax test requirements
On Fri, Feb 17, 2023 at 03:45:16PM -0700, Simon Glass wrote:
> We expect the profile and bootstage to agree on timing, but when
> running on slow machines there can be a larger descrepency. Increase the
> tolerance to fix this.
>
> Fixes: 9cea4797aeb ("trace: Add a test")
> Signed-off-by: Simon Glass
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2 2/2] env: mmc: Apply GPT only on eMMC user HW partition
On Thu, Feb 09, 2023 at 01:30:10PM +0100, Marek Vasut wrote:
> Apply the GPT U-Boot environment GUID type look up only on eMMC user
> HW partition, do not apply the look up on eMMC boot HW partitions as
> mmc_offset_try_partition() assumes either SD partitions or eMMC user
> HW partition.
>
> This fixes environment operation on systems where CONFIG_SYS_MMC_ENV_PART
> is non-zero and CONFIG_SYS_REDUNDAND_ENVIRONMENT is set.
>
> Fixes: 80105d8fd52 ("env: mmc: select GPT env partition by type guid")
> Signed-off-by: Marek Vasut
> Reviewed-by: Tom Rini
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 2/2] x86: Pass -z execstack for EFI payload flags
On Tue, Feb 14, 2023 at 03:09:32PM -0500, Tom Rini wrote: > To match how we link EFI executables elsewhere, and to silence a linker > warning, pass -z execstack here as well. > > Cc: Bin Meng > Cc: Heinrich Schuchardt > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] Makefile: Link with -z noexectack
On Tue, Feb 14, 2023 at 03:09:31PM -0500, Tom Rini wrote:
> When moving to gcc-12.2 we started trying to quiet some of the new
> linker warnings, that are not relevant to us. However, a
> misunderstanding of the mechanics at play meant that I intentionally
> omitted passing -z noexecstack to the linker, when we do need to. Add
> this flag and in turn remove warnings from the linker.
>
> Fixes: 1e1c51f8ace8 ("Makefile: link with --no-warn-rwx-segments")
> Signed-off-by: Tom Rini
> Reviewed-by: Simon Glass
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] fs: btrfs: limit the mapped length to the original length
On Mon, Feb 13, 2023 at 08:37:59AM +0800, Qu Wenruo wrote:
> [BUG]
> There is a bug report that btrfs driver caused hang during file read:
>
> This breaks btrfs on the HiFive Unmatched.
>
> => pci enum
> PCIE-0: Link up (Gen1-x8, Bus0)
> => nvme scan
> => load nvme 0:2 0x8c00 /boot/dtb/sifive/hifive-unmatched-a00.dtb
> [hangs]
>
> [CAUSE]
> The reporter provided some debug output:
>
> read_extent_data: cur=615817216, orig_len=16384, cur_len=16384
> read_extent_data: btrfs_map_block: cur_len=479944704; ret=0
> read_extent_data: ret=0
> read_extent_data: cur=615833600, orig_len=4096, cur_len=4096
> read_extent_data: btrfs_map_block: cur_len=479928320; ret=0
>
> Note the second and the last line, the @cur_len is 450+MiB, which is
> almost a chunk size.
>
> And inside __btrfs_map_block(), we limits the returned value to stripe
> length, but that's depending on the chunk type:
>
> if (map->type & (BTRFS_BLOCK_GROUP_RAID0 | BTRFS_BLOCK_GROUP_RAID1 |
>BTRFS_BLOCK_GROUP_RAID1C3 | BTRFS_BLOCK_GROUP_RAID1C4 |
>BTRFS_BLOCK_GROUP_RAID5 | BTRFS_BLOCK_GROUP_RAID6 |
>BTRFS_BLOCK_GROUP_RAID10 |
>BTRFS_BLOCK_GROUP_DUP)) {
> /* we limit the length of each bio to what fits in a stripe */
> *length = min_t(u64, ce->size - offset,
> map->stripe_len - stripe_offset);
> } else {
> *length = ce->size - offset;
> }
>
> This means, if the chunk is SINGLE profile, then we don't limit the
> returned length at all, and even for other profiles, we can still return
> a length much larger than the requested one.
>
> [FIX]
> Properly clamp the returned length, preventing it from returning a much
> larger range than expected.
>
> Reported-by: Andreas Schwab
> Signed-off-by: Qu Wenruo
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: Pull request for efi-2023-04-rc3-2
On Fri, Feb 24, 2023 at 11:02:57AM +0100, Heinrich Schuchardt wrote: > The following changes since commit 8c3acb726ef083d3d5de12f20318ee0e5070: > > Merge branch 'master' of > https://source.denx.de/u-boot/custodians/u-boot-usb (2023-02-22 13:36:29 > -0500) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-efi.git > tags/efi-2023-04-rc3-2 > > for you to fetch changes up to 0bb5d6b1e4105ec4215239958830a396658bfed8: > > cmd: bootefi: allocate device-tree copy from high memory (2023-02-24 > 07:44:35 +0100) > > Gitlab CI showed no issues: > https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/15340 > > > Pull request for efi-2023-04-rc3-2 > > Documentation: > Fix links to fwu_updates.rst This is a fix. > > UEFI: > Allocate device-tree copy from high memory in bootefi command This I think counts as a fix, but I'm a little confused about allocate in this context. Can you point me at the patch please? > Correct attributes checks in SetVariable() This is a fix.. > Other: > Allow SPL to load main U-Boot via partition type GUID This is new functionality, and I didn't quite see that everyone agreed this was a good idea? Not for master at this point in the cycle. > Test case for crc8 function This I suppose can count as a fix. -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/2] imx93_evk: enable ADC
Hi Luca, On Fri, Feb 24, 2023 at 4:59 AM Luca Ellero wrote: > Hi Fabio, > thank you for your reply. > Ok, I will add a comment to the patch and fix DT node. > Should I resend only this patch or both? Please resend the whole series. My suggestion: 1/3 - ADC driver 2/3 - Sync U-Boot imx93 evk dts with the one from linux-next 20230224 3/3 - Enable the ADC driver in the imx93 evk defconfig
Re: [PATCH 1/1] sandbox: allow building sandbox_spl with CONFIG_DEBUG
On 2/21/23 21:35, Simon Glass wrote: On Sat, 18 Feb 2023 at 01:34, Heinrich Schuchardt wrote: Building sandbox_spl with CONFIG_DEBUG leads to errors due to missing symbols: /usr/bin/ld: common/spl/spl_fit.o: in function `spl_fit_upload_fpga': common/spl/spl_fit.c:595: undefined reference to `fpga_load' /usr/bin/ld: test/test-main.o: in function `dm_test_post_run': test/test-main.c:124: undefined reference to `crc8' /usr/bin/ld: test/test-main.o: in function `dm_test_pre_run': test/test-main.c:95: undefined reference to `crc8' collect2: error: ld returned 1 exit status This is due to -Og not eliminating unused functions. Add FPGA and CRC8 support to the defconfig. Sandbox tests for SPL_FPGA and CRC8 should be created. So enabling these setting is advised anyway. Signed-off-by: Heinrich Schuchardt --- configs/sandbox_spl_defconfig | 4 1 file changed, 4 insertions(+) Reviewed-by: Simon Glass Hello Heinrich, Simon, I am facing similar issues on different defconfig when enabling OPTIMIZE_DEBUG. I don't think enabling SPL_FPGA and DM_FPGA is the solution there. Do you know why is the drivers/fpga/fpga.c built all the time, with no Kconfig selected ? I think that maybe spl_fit_upload_fpga and fpga_load should be built conditionally , I would like to have SPL load a FIT, but not anything related to FPGA in my config. Thanks, Eugen
Re: [PATCH] ARM: dts: at91: sama7g5: fix clock id for ebi node
On 2/23/23 13:28, Mihai Sain wrote:
The PMC_MCK1 clock id for the ebi node is 23.
Fixes: 4ce85577ac ("ARM: dts: at91: sama7g5/sama7g5ek: align with Linux DT")
Signed-off-by: Mihai Sain
---
arch/arm/dts/sama7g5.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/dts/sama7g5.dtsi b/arch/arm/dts/sama7g5.dtsi
index d38090d7dd..a802153af8 100644
--- a/arch/arm/dts/sama7g5.dtsi
+++ b/arch/arm/dts/sama7g5.dtsi
@@ -150,7 +150,7 @@
0x1 0x0 0x4800 0x800
0x2 0x0 0x5000 0x800
0x3 0x0 0x5800 0x800>;
- clocks = < PMC_TYPE_CORE 13>; /* PMC_MCK1 */
+ clocks = < PMC_TYPE_CORE 23>; /* PMC_MCK1 */
status = "disabled";
nand_controller: nand-controller {
Hi Mihai,
It appears PMC_MCK1 = PMC_MAIN(3) + 10 , in Linux.
In U-boot indeed it's 23.
Thanks for fixing it,
Reviewed-by: Eugen Hristev
PS. I will amend the commit as it appears 4ce85577ac does not exist
[RFC PATCH] binman: bintool: etype: Add support for ti-secure entry
core-secdev-k3 is the TI security development package provided for K3 platform devices. This tool helps sign bootloader images with the x509 ceritificate header. Signed-off-by: Neha Malcom Francis --- This patch depends on https://patchwork.ozlabs.org/project/uboot/patch/20230224115101.563729-1-n-fran...@ti.com/ and on ongoing development in https://git.ti.com/cgit/security-development-tools/core-secdev-k3 tools/binman/btool/tisecuretool.py| 72 +++ tools/binman/etype/ti_secure.py | 114 ++ tools/binman/ftest.py | 36 ++ tools/binman/test/278_ti_secure_rom.dts | 11 ++ tools/binman/test/279_ti_secure.dts | 11 ++ .../binman/test/280_ti_secure_nofilename.dts | 10 ++ tools/binman/test/281_ti_secure_combined.dts | 12 ++ 7 files changed, 266 insertions(+) create mode 100644 tools/binman/btool/tisecuretool.py create mode 100644 tools/binman/etype/ti_secure.py create mode 100644 tools/binman/test/278_ti_secure_rom.dts create mode 100644 tools/binman/test/279_ti_secure.dts create mode 100644 tools/binman/test/280_ti_secure_nofilename.dts create mode 100644 tools/binman/test/281_ti_secure_combined.dts diff --git a/tools/binman/btool/tisecuretool.py b/tools/binman/btool/tisecuretool.py new file mode 100644 index 00..5102bb1f7d --- /dev/null +++ b/tools/binman/btool/tisecuretool.py @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (c) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# Written by Neha Malcom Francis +# +"""Bintool implementation for TI security development tools + +tisecuretool helps add x509 certification for bootloader images for K3 platform devices + +Source code: +https://git.ti.com/cgit/security-development-tools/core-secdev-k3/""; + +import os + +from binman import bintool +from patman import tout +from patman import tools + +class Bintooltisecuretool(bintool.Bintool): +"""Signing tool for TI bootloaders""" +name = 'tisecuretool' +def __init__(self, name): +super().__init__(name, 'TI secure tool') + +def sign_binary_secure(self, fname, out_fname): +"""Create a signed binary + +Args: +fname (str): Filename to sign +out_fname (str): Output filename + +Returns: +str: Tool output +or None +""" +tool_path = self.get_path() +script_path = os.path.join(tool_path, 'scripts/secure-binary-image.sh') +args = [ +'sh', +script_path, +fname, +out_fname +] +output = self.run_cmd(*args, add_name=False) +return output + +def sign_binary_rom(self, args): +"""Create a signed binary that is booted by ROM + +Args: +fname (str): Filename to sign +out_fname (str): Output filename""" +tool_path = self.get_path() +script_path = os.path.join(tool_path, 'scripts/secure-rom-boot-image.sh') +#args.insert(0, script_path) +args.insert(0, script_path) +output = self.run_cmd(*args, add_name=False) +return output + +def fetch(self, method): +"""Fetch handler for TI secure tool + +This builds the tool from source + +Returns: +True if the file was fetched, None if a method other than FETCH_SOURCE +was requested +""" +if method != bintool.FETCH_SOURCE: +return None +result = self.fetch_from_git( +'git://git.ti.com/security-development-tools/core-secdev-k3.git', 'tisecuretool') +return result diff --git a/tools/binman/etype/ti_secure.py b/tools/binman/etype/ti_secure.py new file mode 100644 index 00..26f81ff8e8 --- /dev/null +++ b/tools/binman/etype/ti_secure.py @@ -0,0 +1,114 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (c) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# Written by Neha Malcom Francis +# +# Entry-type module for signed binaries for TI K3 platform +# + +from binman.etype.blob import Entry_blob +from binman import bintool + +from dtoc import fdt_util +from patman import terminal +from patman import tools +from patman import tout + +class Entry_ti_secure(Entry_blob): +"""An entry which contains a signed x509 binary for signing TI +General Purpose as well as High-Security devices. + +Properties / Entry arguments: + - filename: filename of binary file to be secured + +Output files: +- filename_x509 - output file generated by secure x509 signing script (which +used as entry contents) +""" +def __init__(self, section, etype, node): +super().__init__(section, etype, node) +self.filename = fdt_util.GetString(self._node, 'filename') +self.core = fdt_util.GetString(self._node, 'core', 'secure') +self.load_addr = fdt_util.GetInt(self._node, 'load', 0x41c0) +
[PATCH v3] binman: bintool: Add support for tool directories
Currently, bintool supports external compilable tools as single
executable files. Adding support for git repos that can be used to run
non-compilable scripting tools that cannot otherwise be present in
binman.
Signed-off-by: Neha Malcom Francis
---
Changes in v3:
- moved back to using DOWNLOAD_DIR as community is making
relevant changes
- extended coverage for bintool_test.py
- added function comment for new parameter
Changes in v2:
- added parameter to obtain path to download the directory
optionally, enables flexibility to avoid using
DOWNLOAD_DESTDIR
- added test to bintool_test.py
- s/FETCH_NO_BUILD/FETCH_SOURCE
- code reformatting
tools/binman/bintool.py| 47 +-
tools/binman/bintool_test.py | 43 +++
tools/binman/btool/_testing.py | 4 +++
tools/patman/tools.py | 2 +-
4 files changed, 88 insertions(+), 8 deletions(-)
diff --git a/tools/binman/bintool.py b/tools/binman/bintool.py
index 8fda13ff01..33f563c46f 100644
--- a/tools/binman/bintool.py
+++ b/tools/binman/bintool.py
@@ -32,12 +32,13 @@ FORMAT = '%-16.16s %-12.12s %-26.26s %s'
modules = {}
# Possible ways of fetching a tool (FETCH_COUNT is number of ways)
-FETCH_ANY, FETCH_BIN, FETCH_BUILD, FETCH_COUNT = range(4)
+FETCH_ANY, FETCH_BIN, FETCH_BUILD, FETCH_SOURCE, FETCH_COUNT = range(5)
FETCH_NAMES = {
FETCH_ANY: 'any method',
FETCH_BIN: 'binary download',
-FETCH_BUILD: 'build from source'
+FETCH_BUILD: 'build from source',
+FETCH_SOURCE: 'download source without building'
}
# Status of tool fetching
@@ -201,12 +202,13 @@ class Bintool:
print(f'- trying method: {FETCH_NAMES[try_method]}')
result = try_fetch(try_method)
if result:
+method = try_method
break
else:
result = try_fetch(method)
if not result:
return FAIL
-if result is not True:
+if result is not True and method != FETCH_SOURCE:
fname, tmpdir = result
dest = os.path.join(DOWNLOAD_DESTDIR, self.name)
print(f"- writing to '{dest}'")
@@ -261,7 +263,7 @@ class Bintool:
show_status(col.RED, 'Failures', status[FAIL])
return not status[FAIL]
-def run_cmd_result(self, *args, binary=False, raise_on_error=True):
+def run_cmd_result(self, *args, binary=False, raise_on_error=True,
add_name=True):
"""Run the bintool using command-line arguments
Args:
@@ -270,6 +272,7 @@ class Bintool:
binary (bool): True to return output as bytes instead of str
raise_on_error (bool): True to raise a ValueError exception if the
tool returns a non-zero return code
+add_name (bool): True to add bintool name to the beginning of
command
Returns:
CommandResult: Resulting output from the bintool, or None if the
@@ -278,7 +281,10 @@ class Bintool:
if self.name in self.missing_list:
return None
name = os.path.expanduser(self.name) # Expand paths containing ~
-all_args = (name,) + args
+if add_name:
+all_args = (name,) + args
+else:
+all_args = args
env = tools.get_env_with_path()
tout.detail(f"bintool: {' '.join(all_args)}")
result = command.run_pipe(
@@ -304,18 +310,19 @@ class Bintool:
tout.debug(result.stderr)
return result
-def run_cmd(self, *args, binary=False):
+def run_cmd(self, *args, binary=False, add_name=True):
"""Run the bintool using command-line arguments
Args:
args (list of str): Arguments to provide, in addition to the
bintool
name
binary (bool): True to return output as bytes instead of str
+add_name (bool): True to add bintool name to the beginning of
command
Returns:
str or bytes: Resulting stdout from the bintool
"""
-result = self.run_cmd_result(*args, binary=binary)
+result = self.run_cmd_result(*args, binary=binary, add_name=add_name)
if result:
return result.stdout
@@ -354,6 +361,32 @@ class Bintool:
return None
return fname, tmpdir
+@classmethod
+def fetch_from_git(cls, git_repo, name):
+"""Fetch a bintool git repo
+
+This clones the repo and returns
+
+Args:
+git_repo (str): URL of git repo
+name (str): Bintool name assigned as tool directory name
+
+Returns:
+str: Directory of fetched repo
+or None on error
+"""
+dir = os.path.join(DOWNLOAD_DESTDIR, name)
+if os.path.exists(dir):
+print(f"- {dir} repo already exists")
+return
Re: [PATCH v2] binman: bintool: Add support for tool directories
Hi Simon
On 23/02/23 02:50, Simon Glass wrote:
Hi Neha,
On Tue, 21 Feb 2023 at 21:30, Neha Malcom Francis wrote:
Hi Simon
On 22/02/23 01:05, Simon Glass wrote:
Hi Neha,
On Fri, 17 Feb 2023 at 04:46, Neha Malcom Francis wrote:
Currently, bintool supports external compilable tools as single
executable files. Adding support for git repos that can be used to run
non-compilable scripting tools that cannot otherwise be present in
binman.
Signed-off-by: Neha Malcom Francis
---
Changes in v2:
- added parameter to obtain path to download the directory
optionally, enables flexibility to avoid using
DOWNLOAD_DESTDIR
- added test to bintool_test.py
- s/FETCH_NO_BUILD/FETCH_SOURCE
- code reformatting
This looks better but I see have some questions and nits.
tools/binman/bintool.py| 45 --
tools/binman/bintool_test.py | 22 +
tools/binman/btool/_testing.py | 5
tools/patman/tools.py | 2 +-
4 files changed, 66 insertions(+), 8 deletions(-)
diff --git a/tools/binman/bintool.py b/tools/binman/bintool.py
index 8fda13ff01..04c951fa0b 100644
--- a/tools/binman/bintool.py
+++ b/tools/binman/bintool.py
@@ -32,12 +32,13 @@ FORMAT = '%-16.16s %-12.12s %-26.26s %s'
modules = {}
# Possible ways of fetching a tool (FETCH_COUNT is number of ways)
-FETCH_ANY, FETCH_BIN, FETCH_BUILD, FETCH_COUNT = range(4)
+FETCH_ANY, FETCH_BIN, FETCH_BUILD, FETCH_SOURCE, FETCH_COUNT = range(5)
FETCH_NAMES = {
FETCH_ANY: 'any method',
FETCH_BIN: 'binary download',
-FETCH_BUILD: 'build from source'
+FETCH_BUILD: 'build from source',
+FETCH_SOURCE: 'download source without building'
Would this be a script? Should we say 'download script without building' ?
Addressed this in a further below comment.
}
# Status of tool fetching
@@ -201,12 +202,13 @@ class Bintool:
print(f'- trying method: {FETCH_NAMES[try_method]}')
result = try_fetch(try_method)
if result:
+method = try_method
break
else:
result = try_fetch(method)
if not result:
return FAIL
-if result is not True:
+if result is not True and method != FETCH_SOURCE:
fname, tmpdir = result
dest = os.path.join(DOWNLOAD_DESTDIR, self.name)
print(f"- writing to '{dest}'")
@@ -261,7 +263,7 @@ class Bintool:
show_status(col.RED, 'Failures', status[FAIL])
return not status[FAIL]
-def run_cmd_result(self, *args, binary=False, raise_on_error=True):
+def run_cmd_result(self, *args, binary=False, raise_on_error=True,
add_name=True):
Please update function comment for new param
"""Run the bintool using command-line arguments
Args:
@@ -278,7 +280,10 @@ class Bintool:
if self.name in self.missing_list:
return None
name = os.path.expanduser(self.name) # Expand paths containing ~
-all_args = (name,) + args
+if add_name:
+all_args = (name,) + args
+else:
+all_args = args
env = tools.get_env_with_path()
tout.detail(f"bintool: {' '.join(all_args)}")
result = command.run_pipe(
@@ -304,7 +309,7 @@ class Bintool:
tout.debug(result.stderr)
return result
-def run_cmd(self, *args, binary=False):
+def run_cmd(self, *args, binary=False, add_name=True):
Please update function comment for new param
"""Run the bintool using command-line arguments
Args:
@@ -315,7 +320,7 @@ class Bintool:
Returns:
str or bytes: Resulting stdout from the bintool
"""
-result = self.run_cmd_result(*args, binary=binary)
+result = self.run_cmd_result(*args, binary=binary, add_name=add_name)
if result:
return result.stdout
@@ -354,6 +359,32 @@ class Bintool:
return None
return fname, tmpdir
+@classmethod
+def fetch_from_git(cls, git_repo, name, toolpath=DOWNLOAD_DESTDIR):
+"""Fetch a bintool git repo
+
+This clones the repo and returns
+
+Args:
+git_repo (str): URL of git repo
+name (str): Bintool name assigned as tool directory name
missing toolpath arg
Will make the above changes
+
+Returns:
+str: Directory of fetched repo
+or None on error
+"""
+dir = os.path.join(toolpath, name)
+if os.path.exists(dir):
+print(f"- Repo {dir} already exists")
+return None
+os.mkdir(dir)
+print(f"- clone git repo '{git_repo}' to '{dir}'")
+tools.run('git', 'clone', '--depth', '1', git_repo, dir)
doesn't this download directly into
Re: [PATCH 2/2] drivers: thermal: Introduce sun8i_thermal
On Mon, 13 Feb 2023 10:42:56 +0800
qianfangui...@163.com wrote:
Hi,
sorry for the delay, somehow this mail never made it into my inbox.
> From: qianfan Zhao
>
> Portting sun8i_thermal.c from linux-5.15 drivers and drop interrupt
> features. Next is an example from allwinner T3:
So what is the use case for this driver? I see how temperature reporting is
useful in the kernel, and even essential for things like DVFS, but what's
the reason for having that in U-Boot?
> => temperature get thermal-sensor@1c24c00
> thermal-sensor@1c24c00: 39437 C
The documentation says that the unit is "degree Celsius". The kernel seems
to use "millidegree of Celsius", at least internally and in sysfs, so this
would need to be adjusted.
Cheers,
Andre
> =>
> thermal-sensor@1c24c00: 39776 C
> =>
> thermal-sensor@1c24c00: 39437 C
>
> Signed-off-by: qianfan Zhao
> ---
> drivers/thermal/Kconfig | 8 +
> drivers/thermal/Makefile| 1 +
> drivers/thermal/sun8i_thermal.c | 368
> 3 files changed, 377 insertions(+)
> create mode 100644 drivers/thermal/sun8i_thermal.c
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 97d4163e8e..be3118175f 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -41,4 +41,12 @@ config TI_DRA7_THERMAL
>Enable thermal support for for the Texas Instruments DRA752 SoC family.
>The driver supports reading CPU temperature.
>
> +config SUN8I_THERMAL
> + bool "Temperature sensor driver for allwinner sunxi SOCs"
> + depends on ARCH_SUNXI
> + select REGMAP
> + help
> + Enable thermal support for for the sunxi SoC family.
> + The driver supports reading CPU temperature.
> +
> endif # if DM_THERMAL
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 8acc7d20cb..9f419962cc 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -9,3 +9,4 @@ obj-$(CONFIG_IMX_THERMAL) += imx_thermal.o
> obj-$(CONFIG_IMX_SCU_THERMAL) += imx_scu_thermal.o
> obj-$(CONFIG_TI_DRA7_THERMAL) += ti-bandgap.o
> obj-$(CONFIG_IMX_TMU) += imx_tmu.o
> +obj-$(CONFIG_SUN8I_THERMAL) += sun8i_thermal.o
> diff --git a/drivers/thermal/sun8i_thermal.c b/drivers/thermal/sun8i_thermal.c
> new file mode 100644
> index 00..51ea81ccf7
> --- /dev/null
> +++ b/drivers/thermal/sun8i_thermal.c
> @@ -0,0 +1,368 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Thermal sensor driver for Allwinner SOC
> + * Based on the linux driver
> + *
> + * Copyright (C) 2023 qianfan Zhao
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define FT_TEMP_MASK GENMASK(11, 0)
> +#define TEMP_CALIB_MASK GENMASK(11, 0)
> +#define CALIBRATE_DEFAULT0x800
> +
> +#define SUN8I_THS_CTRL0 0x00
> +#define SUN8I_THS_CTRL2 0x40
> +#define SUN8I_THS_IC 0x44
> +#define SUN8I_THS_IS 0x48
> +#define SUN8I_THS_MFC0x70
> +#define SUN8I_THS_TEMP_CALIB 0x74
> +#define SUN8I_THS_TEMP_DATA 0x80
> +
> +#define SUN50I_THS_CTRL0 0x00
> +#define SUN50I_H6_THS_ENABLE 0x04
> +#define SUN50I_H6_THS_PC 0x08
> +#define SUN50I_H6_THS_DIC0x10
> +#define SUN50I_H6_THS_DIS0x20
> +#define SUN50I_H6_THS_MFC0x30
> +#define SUN50I_H6_THS_TEMP_CALIB 0xa0
> +#define SUN50I_H6_THS_TEMP_DATA 0xc0
> +
> +#define SUN8I_THS_CTRL0_T_ACQ0(x)(GENMASK(15, 0) & (x))
> +#define SUN8I_THS_CTRL2_T_ACQ1(x)((GENMASK(15, 0) & (x)) << 16)
> +#define SUN8I_THS_DATA_IRQ_STS(x)BIT(x + 8)
> +
> +#define SUN50I_THS_CTRL0_T_ACQ(x)((GENMASK(15, 0) & (x)) << 16)
> +#define SUN50I_THS_FILTER_EN BIT(2)
> +#define SUN50I_THS_FILTER_TYPE(x)(GENMASK(1, 0) & (x))
> +#define SUN50I_H6_THS_PC_TEMP_PERIOD(x) ((GENMASK(19, 0) & (x))
> << 12)
> +#define SUN50I_H6_THS_DATA_IRQ_STS(x)BIT(x)
> +
> +struct ths_device;
> +
> +struct ths_thermal_chip {
> + boolhas_mod_clk;
> + boolhas_bus_clk_reset;
> + int sensor_num;
> + int offset;
> + int scale;
> + int ft_deviation;
> + int temp_data_base;
> + int (*init)(struct ths_device *tmdev);
> + int (*calc_temp)(struct ths_device *tmdev,
> + int id, int reg);
> +};
> +
> +struct ths_device {
> + const struct ths_thermal_chip *chip;
> +
Pull request for efi-2023-04-rc3-2
The following changes since commit 8c3acb726ef083d3d5de12f20318ee0e5070: Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-usb (2023-02-22 13:36:29 -0500) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-efi.git tags/efi-2023-04-rc3-2 for you to fetch changes up to 0bb5d6b1e4105ec4215239958830a396658bfed8: cmd: bootefi: allocate device-tree copy from high memory (2023-02-24 07:44:35 +0100) Gitlab CI showed no issues: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/15340 Pull request for efi-2023-04-rc3-2 Documentation: Fix links to fwu_updates.rst UEFI: Allocate device-tree copy from high memory in bootefi command Correct attributes checks in SetVariable() Other: Allow SPL to load main U-Boot via partition type GUID Test case for crc8 function Heinrich Schuchardt (5): disk: accessors for conditional partition fields kconfig: new macro IF_ENABLED() spl: allow loading via partition type GUID test: unit test for crc8 cmd: bootefi: allocate device-tree copy from high memory Masahisa Kojima (1): efi_loader: update SetVariable attribute check Vincent Stehlé (1): doc: uefi: fix links cmd/bootefi.c| 19 +++ common/spl/Kconfig | 27 ++- common/spl/spl_mmc.c | 18 ++ doc/develop/uefi/fwu_updates.rst | 3 ++- doc/develop/uefi/uefi.rst| 4 ++-- include/linux/kconfig.h | 7 +++ include/part.h | 36 lib/efi_loader/efi_variable.c| 31 +-- test/lib/Makefile| 1 + test/lib/test_crc8.c | 29 + 10 files changed, 145 insertions(+), 30 deletions(-) create mode 100644 test/lib/test_crc8.c
Re: [PATCH] usb: dwc3-meson-g12a: Select PHY instead of imply PHY
On jeu., févr. 23, 2023 at 17:32, Marek Vasut wrote: > Imply means you can turn off the option and expect things to work > - "it's a good idea to have X enabled" is when to use imply > - "you must have X for Y to work" is when to use select > > Use "select" here. > > Signed-off-by: Marek Vasut Reviewed-by: Mattijs Korpershoek > --- > Cc: Mattijs Korpershoek > Cc: Neil Armstrong > Cc: Tom Rini > --- > drivers/usb/dwc3/Kconfig | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig > index f010291d022..e8373b30bb7 100644 > --- a/drivers/usb/dwc3/Kconfig > +++ b/drivers/usb/dwc3/Kconfig > @@ -40,7 +40,7 @@ config SPL_USB_DWC3_GENERIC > config USB_DWC3_MESON_G12A > bool "Amlogic Meson G12A USB wrapper" > depends on DM_USB && USB_DWC3 && ARCH_MESON > - imply PHY > + select PHY > help > Select this for Amlogic Meson G12A Platforms. > This wrapper supports Host and Peripheral operation modes. > @@ -48,7 +48,7 @@ config USB_DWC3_MESON_G12A > config USB_DWC3_MESON_GXL > bool "Amlogic Meson GXL USB wrapper" > depends on DM_USB && USB_DWC3 && ARCH_MESON > - imply PHY > + select PHY > help > Select this for Amlogic Meson GXL and GXM Platforms. > This wrapper supports Host and Peripheral operation modes. > -- > 2.39.1
Re: [PATCH 09/13] s5p: Remove empty arch_misc_init
On Fri, 17 Feb 2023 at 05:19, Simon Glass wrote: > On Wed, 15 Feb 2023 at 20:39, Tom Rini wrote: > > > > We don't need to provide an empty arch_misc_init function here, we can > > just not enable the hook. > > > > Cc: Stefan Bosch > > Signed-off-by: Tom Rini > > --- > > arch/arm/cpu/armv7/s5p4418/cpu.c | 7 --- > > configs/s5p4418_nanopi2_defconfig | 1 - > > 2 files changed, 8 deletions(-) > > > > Reviewed-by: Simon Glass > Reviewed-by: Minkyu Kang -- Thanks, Minkyu Kang.
Re: [PATCH v2 2/2] samsung: common: do not reset if cros-ec uclass is missing
On Mon, 13 Feb 2023 at 23:45, Simon Glass wrote:
> On Mon, 13 Feb 2023 at 01:08, Henrik Grimler wrote:
> >
> > Otherwise non-ChromeOS samsung devices, like the odroid boards, are
> > stuck in a bootloop if CONFIG_CROS_EC is not enabled:
> >
> > <...>
> > MMC: SAMSUNG SDHCI: 2, EXYNOS DWMMC: 0
> > Loading Environment from MMC... *** Warning - bad CRC, using default
> environment
> >
> > cros-ec communications failure -96
> >
> > Please reset with Power+Refresh
> >
> > Cannot init cros-ec device
> > resetting ...
> >
> > Issue started after commit e44d7e73fe0d ("dm: core: Switch
> > uclass_*_device_err to use uclass_*_device_check").
> >
> > Signed-off-by: Henrik Grimler
> > ---
> > board/samsung/common/board.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Reviewed-by: Simon Glass
>
Reviewed-by: Minkyu Kang
--
Thanks,
Minkyu Kang.
Re: [PATCH v1 00/11] Tegra DC improvements
Greetings Tom!
I was thinking about what you asked about ACKs/Tested-By/Reviewed-By's.
Before these patches, DC and video support was available only for T20,
so the main concern is regressions towards T20. Thierry has no T20
boards at all which is rather unfortunate.
I have made a list of T20 boards which use driver I have patched:
- seaboard
- harmony
- ventana (we tested this patches on TF101 which is almost full ventana copy)
- paz00
- colibri_t20
- tec
- medcom-wide
Maybe someone from the paz00 community will agree to help. Patches are
made in a way that no changes into existing setups are needed.
Patchset additionally includes 2 changes to the simple-panel driver.
It was written by Simon Glass, so maybe Simon would like to take a
look at changes.
P. S. Unfortunately I can not show the full potential of these patches
right now, they will shine only once I will submit T30 devices
support, which rely on video out as the main output source.
пн, 20 лют. 2023 р. о 11:54 Svyatoslav Ryhel пише:
>
> This patch set is dedicated to improvement of video support
> on T20 and T30 devices. It contains:
>
> - DC driver improvements (T30 support was added into existing T20
> DC driver, it was moved into own folder, added support of reading
> clocks from dts, improved work with panel ops and implemented
> native 180 degree panel rotation support)
>
> - DSI driver bring up (driver is based on mainline Linux one with
> minor adjustments, only T30 tested)
>
> - Simple panel driver tweaks (added get_display_timing ops and
> implemented simple MIPI DSI panels support)
>
> Marcel Ziswiler (1):
> tegra: lcd: video: integrate display driver for t30
>
> Svyatoslav Ryhel (10):
> video: move tegra dc driver into own folder
> video: tegra-dc: get clocks from device tree
> video: tegra-dc: request timings from panel driver first
> video: tegra-dc: assign regmap directly
> video: tegra-dc: add 180 degree panel rotation
> video: tegra-dc: add panel_set_backlight call
> video: tegra-dc: pass DC regmap to internal devices
> video: tegra20: add DSI controller driver
> simple_panel: add support for get_display_timing
> simple_panel: support simple MIPI DSI panels
>
> arch/arm/dts/tegra30-u-boot.dtsi | 9 +
> arch/arm/include/asm/arch-tegra/dc.h | 8 +
> arch/arm/include/asm/arch-tegra30/display.h | 28 +
> arch/arm/include/asm/arch-tegra30/dsi.h | 197 +
> arch/arm/include/asm/arch-tegra30/pwm.h | 13 +
> drivers/video/Kconfig | 11 +-
> drivers/video/Makefile| 2 +-
> drivers/video/simple_panel.c | 47 +-
> drivers/video/tegra20/Kconfig | 17 +
> drivers/video/tegra20/Makefile| 4 +
> drivers/video/tegra20/dsi.h | 126 +++
> drivers/video/tegra20/mipi-phy.c | 134 +++
> drivers/video/tegra20/mipi-phy.h | 48 ++
> drivers/video/{tegra.c => tegra20/tegra-dc.c} | 123 ++-
> drivers/video/tegra20/tegra-dsi.c | 769 ++
> 15 files changed, 1487 insertions(+), 49 deletions(-)
> create mode 100644 arch/arm/include/asm/arch-tegra30/display.h
> create mode 100644 arch/arm/include/asm/arch-tegra30/dsi.h
> create mode 100644 arch/arm/include/asm/arch-tegra30/pwm.h
> create mode 100644 drivers/video/tegra20/Kconfig
> create mode 100644 drivers/video/tegra20/Makefile
> create mode 100644 drivers/video/tegra20/dsi.h
> create mode 100644 drivers/video/tegra20/mipi-phy.c
> create mode 100644 drivers/video/tegra20/mipi-phy.h
> rename drivers/video/{tegra.c => tegra20/tegra-dc.c} (82%)
> create mode 100644 drivers/video/tegra20/tegra-dsi.c
>
> --
> 2.37.2
>
