July 2022 - U-Boot

[Bug] Buidling sandbox_vpl_defconfig is unstable
by Heinrich Schuchardt 31 Jul '22

31 Jul '22

Hello Simon, Something is wrong with building sandbox_vpl_defconfig on Gitlab: The following build job failed: https://source.denx.de/u-boot/custodians/u-boot-efi/-/jobs/475640 The following build job succeeded: https://source.denx.de/u-boot/custodians/u-boot-efi/-/jobs/475673 Best regards Heinrich 0 0 0 /1 -1 (starting) sandbox: + sandbox_vpl +/usr/bin/ld: /tmp/u-boot-tpl.zgGiog.ltrans0.ltrans.o: in function `spl_common_init.constprop.0': +drivers/core/root.c:178: undefined reference to `uclass_head' +/usr/bin/ld: /tmp/u-boot-tpl.zgGiog.ltrans0.ltrans.o:(__u_boot_list_2_udevice_2_emul0+0x40): undefined reference to `_u_boot_list_2_uclass_2_i2c_emul' +/usr/bin/ld: /tmp/u-boot-tpl.zgGiog.ltrans0.ltrans.o:(__u_boot_list_2_udevice_2_emul0+0x58): undefined reference to `_u_boot_list_2_uclass_2_i2c_emul' +/usr/bin/ld: /tmp/u-boot-tpl.zgGiog.ltrans0.ltrans.o:(__u_boot_list_2_udevice_2_emul0+0x60): undefined reference to `_u_boot_list_2_uclass_2_i2c_emul' +/usr/bin/ld: /tmp/u-boot-tpl.zgGiog.ltrans0.ltrans.o:(__u_boot_list_2_udevice_2_rtc_at_43+0x40): undefined reference to `_u_boot_list_2_uclass_2_rtc' +/usr/bin/ld: /tmp/u-boot-tpl.zgGiog.ltrans0.ltrans.o:(__u_boot_list_2_udevice_2_rtc_at_43+0x58): undefined reference to `_u_boot_list_2_uclass_2_rtc' +/usr/bin/ld: /tmp/u-boot-tpl.zgGiog.ltrans0.ltrans.o:(__u_boot_list_2_udevice_2_rtc_at_43+0x60): undefined reference to `_u_boot_list_2_uclass_2_rtc' +/usr/bin/ld: /tmp/u-boot-tpl.zgGiog.ltrans0.ltrans.o:(__u_boot_list_2_udevice_2_emul+0x40): undefined reference to `_u_boot_list_2_uclass_2_i2c_emul_parent' +/usr/bin/ld: /tmp/u-boot-tpl.zgGiog.ltrans0.ltrans.o:(__u_boot_list_2_udevice_2_emul+0x58): undefined reference to `_u_boot_list_2_uclass_2_i2c_emul_parent' +/usr/bin/ld: /tmp/u-boot-tpl.zgGiog.ltrans0.ltrans.o:(__u_boot_list_2_udevice_2_emul+0x60): undefined reference to `_u_boot_list_2_uclass_2_i2c_emul_parent' +/usr/bin/ld: /tmp/u-boot-tpl.zgGiog.ltrans0.ltrans.o:(__u_boot_list_2_udevice_2_clk_test+0x40): undefined reference to `_u_boot_list_2_uclass_2_misc' +/usr/bin/ld: /tmp/u-boot-tpl.zgGiog.ltrans0.ltrans.o:(__u_boot_list_2_udevice_2_clk_test+0x58): undefined reference to `_u_boot_list_2_uclass_2_misc' +/usr/bin/ld: /tmp/u-boot-tpl.zgGiog.ltrans0.ltrans.o:(__u_boot_list_2_udevice_2_clk_test+0x60): undefined reference to `_u_boot_list_2_uclass_2_misc' +/usr/bin/ld: /tmp/u-boot-tpl.zgGiog.ltrans0.ltrans.o:(__u_boot_list_2_udevice_2_i2c_at_0+0x40): undefined reference to `_u_boot_list_2_uclass_2_i2c' +/usr/bin/ld: /tmp/u-boot-tpl.zgGiog.ltrans0.ltrans.o:(__u_boot_list_2_udevice_2_i2c_at_0+0x58): undefined reference to `_u_boot_list_2_uclass_2_i2c' +/usr/bin/ld: /tmp/u-boot-tpl.zgGiog.ltrans0.ltrans.o:(__u_boot_list_2_udevice_2_i2c_at_0+0x60): undefined reference to `_u_boot_list_2_uclass_2_i2c' +/usr/bin/ld: /tmp/u-boot-tpl.zgGiog.ltrans0.ltrans.o:(__u_boot_list_2_udevice_2_clk_sbox+0x40): undefined reference to `_u_boot_list_2_uclass_2_clk' +/usr/bin/ld: /tmp/u-boot-tpl.zgGiog.ltrans0.ltrans.o:(__u_boot_list_2_udevice_2_clk_sbox+0x58): undefined reference to `_u_boot_list_2_uclass_2_clk' +/usr/bin/ld: /tmp/u-boot-tpl.zgGiog.ltrans0.ltrans.o:(__u_boot_list_2_udevice_2_serial+0x40): undefined reference to `_u_boot_list_2_uclass_2_serial' +/usr/bin/ld: /tmp/u-boot-tpl.zgGiog.ltrans0.ltrans.o:(__u_boot_list_2_udevice_2_serial+0x58): undefined reference to `_u_boot_list_2_uclass_2_serial' +/usr/bin/ld: /tmp/u-boot-tpl.zgGiog.ltrans0.ltrans.o:(__u_boot_list_2_udevice_2_serial+0x60): undefined reference to `_u_boot_list_2_uclass_2_serial' +/usr/bin/ld: /tmp/u-boot-tpl.zgGiog.ltrans0.ltrans.o:(__u_boot_list_2_udevice_2_clk_fixed+0x40): undefined reference to `_u_boot_list_2_uclass_2_clk' +/usr/bin/ld: /tmp/u-boot-tpl.zgGiog.ltrans0.ltrans.o:(__u_boot_list_2_udevice_2_clk_fixed+0x60): undefined reference to `_u_boot_list_2_uclass_2_clk' +/usr/bin/ld: /tmp/u-boot-tpl.zgGiog.ltrans0.ltrans.o:(__u_boot_list_2_udevice_2_root+0x40): undefined reference to `_u_boot_list_2_uclass_2_root' +/usr/bin/ld: /tmp/u-boot-tpl.zgGiog.ltrans0.ltrans.o:(__u_boot_list_2_udevice_2_root+0x58): undefined reference to `_u_boot_list_2_uclass_2_root' +/usr/bin/ld: /tmp/u-boot-tpl.zgGiog.ltrans0.ltrans.o:(__u_boot_list_2_udevice_2_root+0x60): undefined reference to `_u_boot_list_2_uclass_2_root' +collect2: error: ld returned 1 exit status +make[2]: *** [scripts/Makefile.spl:525: tpl/u-boot-tpl] Error 1 +make[1]: *** [Makefile:2130: tpl/u-boot-tpl] Error 2 +make: *** [Makefile:177: sub-make] Error 2

3 4

[RFCv1] doc: develop: Describe using CONFIG vs CFG for values
by Tom Rini 31 Jul '22

31 Jul '22

Document how and when to use CONFIG or CFG namespace for options. There are times where Kconfig is not a great fit for our needs, so we want to use the CFG namespace instead. Signed-off-by: Tom Rini <trini(a)konsulko.com> --- RFCv1: - This is essentially my idea on how to better handle the problem of CONFIG values that just don't fit in Kconfig because it makes much more sense to define them statically for a given SoC or calculate them from other values, and so on. One example here would be to revert c7fad78ec0ee ("Convert CONFIG_SYS_BR0_PRELIM et al to Kconfig") and re-name these to CFG_SYS_.. instead. Another big example here would be a global search-and-replace of 's/CONFIG_HPS_/CFG_HPS_/g' as that's all tool-generated. Not all CONFIG_SYS_ options would get this as boolean choices are well handled in Kconfig, and that may not be clear enough in what I wrote here? --- doc/develop/build_configuration.rst | 36 +++++++++++++++++++++++++++++ doc/develop/index.rst | 1 + 2 files changed, 37 insertions(+) create mode 100644 doc/develop/build_configuration.rst diff --git a/doc/develop/build_configuration.rst b/doc/develop/build_configuration.rst new file mode 100644 index 000000000000..541ce528b36a --- /dev/null +++ b/doc/develop/build_configuration.rst @@ -0,0 +1,36 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Using CONFIG or CFG to configure the build +========================================== + +There are two namespaces used to control the build-time configuration of +U-Boot, ``CONFIG`` and ``CFG``. These are used when it is either not possible +or not practical to make a run-time determination about some functionality of +the hardware or a required software feature or similar. Each of these has their +own places where they are better suited than the other for use. + +The first of these, ``CONFIG``` is managed in the `Kconfig language +<https://www.kernel.org/doc/html/latest/kbuild/kconfig-language.html>`_ that is +most commonly associated with the Linux kernel and the Kconfig files found +throughout our sources. Adding options to this namespace is the preferred way of +exposing new configuration options as there are a number of ways for both users +and system integrators to manage and change these options. Some common examples +here are to enable a specific command within U-Boot or even a whole subsystem +such as NAND flash or network connectivity. + +The second of these, ``CFG`` is implemented directly as C preprocessor values or +macros, depending on what they are in turn describing. The nature of U-Boot +means that while we have some functionality that is very reasonable to expose to +the end user to enable or disable we have other places where we need to describe +things such as register locations or values, memory map ranges and so on. When +practical, we should be getting these values from the :doc:`device tree +<devicetree/control>`. However, there are cases where this is either not +practical due to when we need the information and may not have a device tree yet +or due to legacy reasons code has not been rewritten. As this information tends +to be specific to a given SoC (or family of SoCs) or if board specific something +that is mandated by the physical design rather than truly user configurable, it +is acceptable to ``#define`` these values in the ``CFG`` namespace. It is +strongly encouraged to place these in the architecture header files, if they are +generic to a given SoC, or under the board directory if board specific. Placing +them under the board.h file in the *include/configs/* directory should be seen +as a last resort. diff --git a/doc/develop/index.rst b/doc/develop/index.rst index 73741ceb6a2f..c8ec7c210d35 100644 --- a/doc/develop/index.rst +++ b/doc/develop/index.rst @@ -9,6 +9,7 @@ General .. toctree:: :maxdepth: 1 + build_configuration codingstyle designprinciples process -- 2.25.1

4 8

[PATCH] bootstd: doc: Fix typos
by Paul Barker 31 Jul '22

31 Jul '22

These typos were found while reading the docs. Signed-off-by: Paul Barker <paul.barker(a)sancloud.com> --- doc/develop/bootstd.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/develop/bootstd.rst b/doc/develop/bootstd.rst index 5e9c0d282bb0..6488c997b65a 100644 --- a/doc/develop/bootstd.rst +++ b/doc/develop/bootstd.rst @@ -21,7 +21,7 @@ feature is typically called `distro boot` (see :doc:`distro`) because it is a way for distributions to boot on any hardware. Traditionally U-Boot has relied on scripts to implement this feature. See -disto_boodcmd_ for details. This is done because U-Boot has no native support +distro_bootcmd_ for details. This is done because U-Boot has no native support for scanning devices. While the scripts work remarkably well, they can be hard to understand and extend, and the feature does not include tests. They are also making it difficult to move away from ad-hoc CONFIGs, since they are implemented @@ -51,7 +51,7 @@ BootLoaderSpec_ format. which looks something like this:: initrd /initramfs-5.3.7-301.fc31.armv7hl.img As you can see it specifies a kernel, a ramdisk (initrd) and a directory from -which to load devicetree files. The details are described in disto_boodcmd_. +which to load devicetree files. The details are described in distro_bootcmd_. The bootflow is provided by the distro. It is not part of U-Boot. U-Boot's job is simply to interpret the file and carry out the instructions. This allows @@ -632,7 +632,7 @@ Other ideas: not need to specify things like `pxefile_addr_r` -.. _disto_boodcmd: https://github.com/u-boot/u-boot/blob/master/include/config_distro_bootcmd.h +.. _distro_bootcmd: https://github.com/u-boot/u-boot/blob/master/include/config_distro_bootcmd.h .. _BootLoaderSpec: http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ .. _distro_boot: https://github.com/u-boot/u-boot/blob/master/boot/distro.c .. _bootflow_h: https://github.com/u-boot/u-boot/blob/master/include/bootflow.h -- 2.25.1

2 1

[PATCH 0/1] sunxi: support half DQ width memory on R40
by Evgeny Boger 30 Jul '22

30 Jul '22

On Allwinner boards memory configuration is detected by bootloader. However, R40 (A40i/T3) is somewhat unique because the detection by the DRAM controller via PIR_QSGATE is broken (either in U-Boot or in the controller). So the memory configuration must be detected by other means. Dual rank detection has been already implemented by Icenowy earlier. This patch extends the automation detection so it can detect half-width DQ configuration (i.e. single x16 DDR3 IC). Tested on Allwinner A40i-based Wiren Board 7 automation controller, for the following memory configurations: * 1x 16-bit 4Gbit DDR3, 512 MiB total RAM * 2x 16-bit 4Gbit DDR3, 1024 MiB total RAM * 2x 16-bit 8Gbit DDR3, 2048 MiB total RAM Unfortunately it has NOT been tested with dual-rank configuration yet, as I don't have any dual-rank boards at hand. I will really appreciate if someone could help me with that. Evgeny Boger (1): sunxi: support half DQ width memory on R40 .../include/asm/arch-sunxi/dram_sunxi_dw.h | 1 + arch/arm/mach-sunxi/dram_sunxi_dw.c | 115 ++++++++++++------ 2 files changed, 79 insertions(+), 37 deletions(-) -- 2.25.1

1 1

[v3] doc: develop: Describe system configuration
by Tom Rini 29 Jul '22

29 Jul '22

Start by describing in general the best practices for how to implement configuration of some aspect of U-Boot. This generally means finding the right choices for when something should be static or dynamically configured and enabled. Then further document when to use CONFIG or CFG namespaces for static configuration. Signed-off-by: Tom Rini <trini(a)konsulko.com> --- Changes in v3: - Drop RFC prefix. - Incorporate most of the specific wording changes Heinrich requested against v2. - Heinrich disliked the "namespace" wording in v2, and that in turn was a hold over from when this talked only about CONFIG vs CFG. Remove that word entirely and instead talk about configuration mechanisms. Reword a number of sections and examples so that they read better or hopefully more clearly now that we talk about different mechanisms. - Expand on when to use each configuration mechanism. Generally don't refer to CONFIG but instead Kconfig. RFCv2: - Based on Pali's feedback, remove the README section and start a new section in this document to cover when to use each namespace. Try and be clear about when to use "hidden" Kconfig options rather than CFG as well. - Based on Heinrich's feedback, rename this to system_configuration.rst and include some introductory remarks on when to use some dynamic or static configuration. Link to the driver model code for dynamic configuration and then explain the CONFIG vs CFG namespaces for static configuration. RFCv1: - This is essentially my idea on how to better handle the problem of CONFIG values that just don't fit in Kconfig because it makes much more sense to define them statically for a given SoC or calculate them from other values, and so on. One example here would be to revert c7fad78ec0ee ("Convert CONFIG_SYS_BR0_PRELIM et al to Kconfig") and re-name these to CFG_SYS_.. instead. Another big example here would be a global search-and-replace of 's/CONFIG_HPS_/CFG_HPS_/g' as that's all tool-generated. Not all CONFIG_SYS_ options would get this as boolean choices are well handled in Kconfig, and that may not be clear enough in what I wrote here? --- README | 21 ----- doc/develop/index.rst | 1 + doc/develop/system_configuration.rst | 132 +++++++++++++++++++++++++++ 3 files changed, 133 insertions(+), 21 deletions(-) create mode 100644 doc/develop/system_configuration.rst diff --git a/README b/README index 2c4bde0b3297..623f35907217 100644 --- a/README +++ b/README @@ -166,27 +166,6 @@ Directory Hierarchy: Software Configuration: ======================= -Configuration is usually done using C preprocessor defines; the -rationale behind that is to avoid dead code whenever possible. - -There are two classes of configuration variables: - -* Configuration _OPTIONS_: - These are selectable by the user and have names beginning with - "CONFIG_". - -* Configuration _SETTINGS_: - These depend on the hardware etc. and should not be meddled with if - you don't know what you're doing; they have names beginning with - "CONFIG_SYS_". - -Previously, all configuration was done by hand, which involved creating -symbolic links and editing configuration files manually. More recently, -U-Boot has added the Kbuild infrastructure used by the Linux kernel, -allowing you to use the "make menuconfig" command to configure your -build. - - Selection of Processor Architecture and Board Type: --------------------------------------------------- diff --git a/doc/develop/index.rst b/doc/develop/index.rst index 73741ceb6a2f..7c41e3f1b6e5 100644 --- a/doc/develop/index.rst +++ b/doc/develop/index.rst @@ -13,6 +13,7 @@ General designprinciples process release_cycle + system_configuration Implementation -------------- diff --git a/doc/develop/system_configuration.rst b/doc/develop/system_configuration.rst new file mode 100644 index 000000000000..1279d12cb7ae --- /dev/null +++ b/doc/develop/system_configuration.rst @@ -0,0 +1,132 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +System configuration +==================== + +There are a number of different aspects to configuring U-Boot to build and then +run on a given platform or set of platforms. Broadly speaking, some aspects of +the world can be configured at run time and others must be done at build time. +In general run time configuration is preferred over build time configuration. +But when making these decisions, we also need to consider if we're talking about +a feature that could be useful to virtually every platform or something specific +to a single hardware platform. The resulting image size is also another +important consideration. Finally, run time configuration has additional overhead +both in terms of resource requirements and wall clock time. All of this means +that care must be taken when writing new code to select the most appropriate +configuration mechanism. + +When adding new features to U-Boot, be they a new subsystem or SoC support or +new platform for an existing supported SoC, the preferred configuration order +is: + +#. Hardware based run time configuration. Examples of this include reading + processor specific registers, or a set of board specific GPIOs or an EEPROM + with a known format to it. These are the cases where we either cannot or + should not be relying on device tree checks. We use this for cases such as + optimized boot time or starting with a generic device tree and then enabling + or disabling features as we boot. + +#. Making use of our Kconfig infrastructure and C preprocessor macros that have + the prefix ``CONFIG``. This is the primary method of build time + configuration. This is generally the best fit for when we want to enable or + disable some sort of feature, such as the SoC or network support. The + ``CONFIG`` prefix for C preprocessor macros is strictly reserved for Kconfig + usage only. + +#. Making use of the :doc:`device tree <devicetree/control>` to determine at + run time how to configure a feature that we have enabled via Kconfig. For + example, we would use Kconfig to enable an i2c chip driver, but use the device + tree to know where the i2c chip resides in memory and other details we need + in order to configure the bus. + +#. Making use of C header files directly and defining C preprocessor macros that + have the ``CFG`` prefix. While the ``CFG`` prefix is reserved for this build + time configuration mechanism, the usage is ad hoc. This is to be used when the + previously mentioned mechanisms are not possible, or for legacy code that has + not been converted. + +Dynamic run time configuration methods. +--------------------------------------- + +Details of hardware specific run time configuration methods are found within the +documentation for a given processor family or board. + +Details of how to use run time configuration based on :doc:`driver model +<driver-model/index>` are covered in that documentation section. + +Static build time configuration methods +--------------------------------------- + +There are two mechanisms used to control the build time configuration of U-Boot. +One is utilizing Kconfig and ``CONFIG`` prefixed macros and the other is ad hoc +usage of ``CFG`` prefixed macros. Both of these are used when it is either not +possible or not practical to make a run time determination about some +functionality of the hardware or a required software feature or similar. Each of +these has their own places where they are better suited than the other for use. + +The `Kconfig language +<https://www.kernel.org/doc/html/latest/kbuild/kconfig-language.html>`_ is well +documented and used in a number of projects, including the Linux kernel. We +implement this with the Kconfig files found throughout our sources. This +mechanism is the preferred way of exposing new configuration options as there +are a number of ways for both users and system integrators to manage and change +these options. Some common examples here are to enable a specific command within +U-Boot or even a whole subsystem such as NAND flash or network connectivity. + +The ``CFG`` mechanism is implemented directly as C preprocessor values or +macros, depending on what they are in turn describing. While we have some +functionality that is very reasonable to expose to the end user to enable or +disable we have other places where we need to describe things such as register +locations or values, memory map ranges and so on. When practical, we should be +getting these values from the device tree. However, there are cases where this +is either not practical due to when we need the information and may not have a +device tree yet or due to legacy reasons code has not been rewritten. + +When to use each mechanism +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +While there are some cases where it should be fairly obvious where to use each +namespace, as for example a command would done via Kconfig, a new i2c driver +should use Kconfig and be configured via driver model and a header of values +generated by an external tool should be ``CFG``, there will be cases where it's +less clear and one needs to take care when implementing it. In general, +configuration *options* should be done in Kconfig and configuration *settings* +should done in driver model or ``CFG``. Let us discuss things to keep in mind +when picking the appropriate mechanism. + +A thing to keep in mind is that we have a strong preference for using Kconfig as +the primary build time configuration mechanism. Options expressed this way let +us easily express dependencies and abstractions. In addition, given that many +projects use this mechanism means it has a broad set of tooling and existing +knowledge base. + +Consider the example of a SHA256 hardware acceleration engine. This would be a +feature of the SoC and so something to not ask the user if it exists, but we +would want to have our generic framework for such engines be optionally +available and depend on knowing we have this engine on a given hardware +platform. Expressing this should be done as a hidden Kconfig symbol that is +``select``'ed by the SoC symbol which would in turn be ``select``'ed by the +board option, which is user visible. Hardware features that are either present +or not present should be expressed in Kconfig and in a similar manner, features +which will always have a constant value such as "this SoC always has 4 cores and +4 threads per core" should be as well. + +This brings us to differentiating between a configuration *setting* versus a +hardware feature. To build on the previous example, while we may know the number +of cores and threads, it's possible that within a given family of SoCs the base +addresses of peripherals has changed, but the register offsets within have not. +The preference in this case is to get our information from the device tree and +perform run time configuration. However, this is not always practical and in +those cases we instead rely on the ``CFG`` mechanism. While it would be possible +to use Kconfig in this case, it would result in using calculated rather than +constructed values, resulting in less clear code. Consider the example of a set +of register values for a memory controller. Defining this as a series of logical +ORs and shifts based on other defines is more clear than the Kconfig entry that +set the calculated value alone. + +When it has been determined that the practical solution is to utilize the +``CFG`` mechanism, the next decision is where to place these settings. It is +strongly encouraged to place these in the architecture header files, if they are +generic to a given SoC, or under the board directory if board specific. Placing +them under the board.h file in the *include/configs/* directory should be seen +as a last resort. -- 2.25.1

3 3

Pull request for doc-2022-10-rc2
by Heinrich Schuchardt 29 Jul '22

29 Jul '22

Dear Tom, The following changes since commit 12fc2c3898cbcf6713055b58bd6103a2b9fda0de: Merge https://gitlab.denx.de/u-boot/custodians/u-boot-marvell (2022-07-29 08:08:33 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-efi.git tags/doc-2022-10-rc2 for you to fetch changes up to 53d2ab9b5a0a48953fc54573d7a22724a30b512d: doc: develop: Describe system configuration (2022-07-29 18:59:47 +0200) ---------------------------------------------------------------- Pull request for doc-2022-10-rc2 Documentation: * Detail how configuration signatures are calculated * Further expand on Image locations and provide example * Describe system configuration ---------------------------------------------------------------- Martin Bonner (1): Provide more details of exactly how configuration signatures are calculated Tom Rini (2): doc: environment: Further expand on Image locations and provide example doc: develop: Describe system configuration README | 21 ------ doc/develop/index.rst | 1 + doc/develop/system_configuration.rst | 132 +++++++++++++++++++++++++++++++++++ doc/uImage.FIT/signature.txt | 26 +++++++ doc/usage/environment.rst | 53 ++++++++++++++ 5 files changed, 212 insertions(+), 21 deletions(-) create mode 100644 doc/develop/system_configuration.rst

2 1

[PATCH] rockchip: rk3399: boot_devices: fix eMMC node name
by Quentin Schulz 29 Jul '22

29 Jul '22

From: Quentin Schulz <quentin.schulz(a)theobroma-systems.com> When idbloader.img is flashed on the eMMC, the SPL still tries to load from SPI-NOR first. This is due to an incorrect look-up in the Device Tree. Since commit 822556a93459 ("arm: dts: sync the Rockhip 3399 SoCs from Linux"), the node name (but not label) changed from sdhci@fe330000 to mmc@fe330000 meaning U-Boot SPL is not looking for the correct node name anymore and fails to find the "same-as-spl" node when eMMC is the medium from which the SPL booted. Fixes: 822556a93459 ("arm: dts: sync the Rockhip 3399 SoCs from Linux") Cc: Quentin Schulz <foss+u-boot(a)0leil.net> Signed-off-by: Quentin Schulz <quentin.schulz(a)theobroma-systems.com> --- arch/arm/mach-rockchip/rk3399/rk3399.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c b/arch/arm/mach-rockchip/rk3399/rk3399.c index 01a05599cd..de11a3fa30 100644 --- a/arch/arm/mach-rockchip/rk3399/rk3399.c +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c @@ -27,7 +27,7 @@ DECLARE_GLOBAL_DATA_PTR; #define GRF_BASE 0xff770000 const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = { - [BROM_BOOTSOURCE_EMMC] = "/sdhci@fe330000", + [BROM_BOOTSOURCE_EMMC] = "/mmc@fe330000", [BROM_BOOTSOURCE_SPINOR] = "/spi@ff1d0000/flash@0", [BROM_BOOTSOURCE_SD] = "/mmc@fe320000", }; @@ -181,7 +181,7 @@ const char *spl_decode_boot_device(u32 boot_device) const char *ofpath; } spl_boot_devices_tbl[] = { { BOOT_DEVICE_MMC1, "/mmc@fe320000" }, - { BOOT_DEVICE_MMC2, "/sdhci@fe330000" }, + { BOOT_DEVICE_MMC2, "/mmc@fe330000" }, { BOOT_DEVICE_SPI, "/spi@ff1d0000" }, }; -- 2.36.1

3 3

[RFCv2] doc: develop: Describe system configuration
by Tom Rini 29 Jul '22

29 Jul '22

Start by describing in general the best practices for how to implement configuration of some aspect of U-Boot. This generally means finding the right choices for when something should be static or dynamically configured and enabled. Then further document when to use CONFIG or CFG namespaces for static configuration. Signed-off-by: Tom Rini <trini(a)konsulko.com> --- RFCv2: - Based on Pali's feedback, remove the README section and start a new section in this document to cover when to use each namespace. Try and be clear about when to use "hidden" Kconfig options rather than CFG as well. - Based on Heinrich's feedback, rename this to system_configuration.rst and include some introductory remarks on when to use some dynamic or static configuration. Link to the driver model code for dynamic configuration and then explain the CONFIG vs CFG namespaces for static configuration. RFCv1: - This is essentially my idea on how to better handle the problem of CONFIG values that just don't fit in Kconfig because it makes much more sense to define them statically for a given SoC or calculate them from other values, and so on. One example here would be to revert c7fad78ec0ee ("Convert CONFIG_SYS_BR0_PRELIM et al to Kconfig") and re-name these to CFG_SYS_.. instead. Another big example here would be a global search-and-replace of 's/CONFIG_HPS_/CFG_HPS_/g' as that's all tool-generated. Not all CONFIG_SYS_ options would get this as boolean choices are well handled in Kconfig, and that may not be clear enough in what I wrote here? --- README | 21 ----- doc/develop/index.rst | 1 + doc/develop/system_configuration.rst | 121 +++++++++++++++++++++++++++ 3 files changed, 122 insertions(+), 21 deletions(-) create mode 100644 doc/develop/system_configuration.rst diff --git a/README b/README index 2c4bde0b3297..623f35907217 100644 --- a/README +++ b/README @@ -166,27 +166,6 @@ Directory Hierarchy: Software Configuration: ======================= -Configuration is usually done using C preprocessor defines; the -rationale behind that is to avoid dead code whenever possible. - -There are two classes of configuration variables: - -* Configuration _OPTIONS_: - These are selectable by the user and have names beginning with - "CONFIG_". - -* Configuration _SETTINGS_: - These depend on the hardware etc. and should not be meddled with if - you don't know what you're doing; they have names beginning with - "CONFIG_SYS_". - -Previously, all configuration was done by hand, which involved creating -symbolic links and editing configuration files manually. More recently, -U-Boot has added the Kbuild infrastructure used by the Linux kernel, -allowing you to use the "make menuconfig" command to configure your -build. - - Selection of Processor Architecture and Board Type: --------------------------------------------------- diff --git a/doc/develop/index.rst b/doc/develop/index.rst index 73741ceb6a2f..7c41e3f1b6e5 100644 --- a/doc/develop/index.rst +++ b/doc/develop/index.rst @@ -13,6 +13,7 @@ General designprinciples process release_cycle + system_configuration Implementation -------------- diff --git a/doc/develop/system_configuration.rst b/doc/develop/system_configuration.rst new file mode 100644 index 000000000000..bb09d1f974d4 --- /dev/null +++ b/doc/develop/system_configuration.rst @@ -0,0 +1,121 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +U-Boot system configuration +=========================== + +There are a number of different aspects to configuring U-Boot to build and then +run on a given platform or set of platforms. Broadly speaking, some aspects of +the world can be configured at run time and others must be done at build time. +In general run time is preferred over build time. But when making these +decision, we also need to consider if we're talking about feature that could be +useful to virtually every platform or something specific to a single hardware +platform. The resulting image size is also another important consideration. +Finally, the overall requirements of being able to do run time detection will +have an impact on if it's possible or not. + +When adding new features to U-Boot, be they a new subsystem or SoC support or +new platform for an existing supported SoC, the preferred configuration order +is: + +#. Simple run time. One example here are chip revision checks. Another is + knowing that we've checked GPIOs and are on revision B of a platform, rather + than doing a more expensive device tree check. This allows us to use a single + device tree for revision A and B in this case and perform fixups as needed + rather than storing two device trees. + +#. Making use of our Kconfig infrastructure and the ``CONFIG`` namespace. The + primary method of build time configuration is done via the ``CONFIG`` + namespace and Kconfig infrastructure. This is generally the best fit for when + we want to enable or disable some sort of feature, such as the SoC or network + support. + +#. Making use of the :doc:`device tree <devicetree/control>` to determine at + run time how to configure a feature that we have enabled via Kconfig. For + example, we would use Kconfig to enable an i2c chip driver, but the device + tree to know where the i2c chip resides in memory and other details we need + in order to configure the bus. + +#. Making use of C header files directly and the ``CFG`` namespace. This is + useful when for various reasons we cannot get configuration values that we + need from the device tree so instead have them defined in a header and use + the prefix ``CFG_`` in their definition. + +Dynamic run time configuration methods. +--------------------------------------- + +For more information in general on how to make use of this please start with the +:doc:`driver model <driver-model/index>` documentation. + +Static build time configuration methods +--------------------------------------- + +There are two namespaces used to control the build time configuration of +U-Boot, ``CONFIG`` and ``CFG``. These are used when it is either not possible +or not practical to make a run time determination about some functionality of +the hardware or a required software feature or similar. Each of these has their +own places where they are better suited than the other for use. + +The first of these, ``CONFIG``` is managed in the `Kconfig language +<https://www.kernel.org/doc/html/latest/kbuild/kconfig-language.html>`_ that is +most commonly associated with the Linux kernel and the Kconfig files found +throughout our sources. Adding options to this namespace is the preferred way of +exposing new configuration options as there are a number of ways for both users +and system integrators to manage and change these options. Some common examples +here are to enable a specific command within U-Boot or even a whole subsystem +such as NAND flash or network connectivity. + +The second of these, ``CFG`` is implemented directly as C preprocessor values or +macros, depending on what they are in turn describing. The nature of U-Boot +means that while we have some functionality that is very reasonable to expose to +the end user to enable or disable we have other places where we need to describe +things such as register locations or values, memory map ranges and so on. When +practical, we should be getting these values from the device tree . However, +there are cases where this is either not practical due to when we need the +information and may not have a device tree yet or due to legacy reasons code has +not been rewritten. + +When to use each namespace +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +While there are some cases where it should be fairly obvious where to use each +namespace, as for example a command would be ``CONFIG`` and a header of values +generated by an external tool should be ``CFG`` there will be cases where it's +less clear and one needs to take care when implementing. In general, +configuration *options* should be ``CONFIG`` and configuration *settings* should +be ``CFG``. Since it is not always clear however, let us discuss things to +keep in mind when adding to either namespace. + +A thing to keep in mind is that we have a strong preference for using the +``CONFIG`` namespace first. Options expressed this way let us make use of the +Kconfig language to express dependencies and abstractions. Consider the example +of a SHA256 hardware acceleration engine. This would be a feature of the SoC and +so something to not ask the user if it exists, but we would want to have our +generic framework for such engines be optionally available and depend on knowing +we have this engine on a given hardware platform. Expressing this should be done +as a hidden symbol that is ``select``'ed by the SoC symbol which would in turn +be ``select``'ed by the board option, which is user visible. This means that +hardware features that are either present or not present should be in the +``CONFIG`` namespace and in a similar manner, features which will always have a +constant value such as "this SoC always has 4 cores and 4 threads per core" +should be as well. + +This brings us to differentiating between a configuration *setting* versus a +hardware feature. To build on the previous example, while we may know the number +of cores and threads, it's possible that within a given family of SoCs the base +addresses of peripherals has changed, but the register offsets within have not. +And for practical reasons, we cannot get this information at run time from the +device tree. This is a case where it is reasonable to instead make use of the +``CFG`` namespace and that it is pure C preprocessor macros to define that +``CFG_SYS_FOO_REG`` is ``(CFG_SYS_FOO_BASE + 0x200)`` and have blocks of those +under ``#if defined(CONFIG_SOC_FOO1) ... #elif defined(CONFIG_SOC_FOO2) ... +#endif`` in a system header file. Another example here is register values. Often +it will make the most sense to construct these from other values and then using +masks and shifts to turn a list of "magic values" in to something that is easier +for humans to parse as well. + +When it has been determined that the practical solution for where to have +something is in the ``CFG`` namespace, the next decision is where to place these +settings. It is strongly encouraged to place these in the architecture header +files, if they are generic to a given SoC, or under the board directory if board +specific. Placing them under the board.h file in the *include/configs/* +directory should be seen as a last resort. -- 2.25.1

3 9

Please pull u-boot-marvell/master
by Stefan Roese 29 Jul '22

29 Jul '22

Hi Tom, please pull this next batch of mostly Marvell related patches: ---------------------------------------------------------------- - mvebu: Add Armada 38x pin muxing support (Pali) - a37xx: pinctrl: Fix requesting GPIOs and pinmux command (Pali) - mvebu: pinctrl: apply SDHCI PHY config for A7K (Kosta) - gpio: Add Turris Omnia MCU driver (Pali) - cmd: mvebu/bubt: Improvements for image verification (Pali) - mvebu: turris_omnia: Fix mpp26 pin name and comment (Marek) ---------------------------------------------------------------- Here the Azure build, without any issues: https://dev.azure.com/sr0718/u-boot/_build/results?buildId=223&view=results Thanks, Stefan The following changes since commit 87069c79e830b2ab909537946a1e1db0e5fe7d8c: Merge https://gitlab.denx.de/u-boot/custodians/u-boot-mmc (2022-07-27 07:00:54 -0400) are available in the Git repository at: git@source.denx.de:u-boot/custodians/u-boot-marvell.git for you to fetch changes up to b2d7619e46aa414cba14a1705892b7e249468d6f: arm: mvebu: turris_omnia: Fix mpp26 pin name and comment (2022-07-29 13:55:52 +0200) ---------------------------------------------------------------- Konstantin Porotchkin (1): mvebu: pinctrl: apply SDHCI PHY config for A7K Marek Behún (1): arm: mvebu: turris_omnia: Fix mpp26 pin name and comment Pali Rohár (24): pinctrl: Add new function pinctrl_generic_set_state_prefix() mvebu: pinctrl: Add Armada 38x driver arm: mvebu: Add gpio-ranges into Armada 38x device tree file pinctrl: Add third argument label for pinctrl_gpio_request() function gpio: mvebu_gpio: Add .request and .rfree methods for Armada 38x gpio: mvebu_gpio: Read number of gpios from DT gpio: mvebu_gpio: Set bank name to mvebu%d arm: mvebu: turris_omnia: Enable a38x pinctrl and gpio support arm64: a37xx: pinctrl: Remove unused grp->pins fields arm64: a37xx: pinctrl: Remove duplicate info->groups and info->ngroups fields arm64: a37xx: pinctrl: Mark all functions and structures as static arm64: a37xx: pinctrl: Add missing pinmuxes into the list arm64: a37xx: pinctrl: Implement gpio_request_enable for gpio functionality arm64: a37xx: pinctrl: Implement get_pins_count, get_pin_name and get_pin_muxing functions gpio: Add Turris Omnia MCU driver arm: mvebu: turris_omnia: Add mcu node with gpio-controller cmd: mvebu/bubt: Verify image type for all 32-bit Aramda SoCs and Armada 3700 cmd: mvebu/bubt: Correctly propagate failure during tftp transport cmd: mvebu/bubt: Add support for sha512 checksum validation for Armada 3700 cmd: mvebu/bubt: Fix cmd main return value on error arm: mvebu: Fix compatible string for nand controller arm: mvebu: Synchronize armada-38x.dtsi with Linux v5.20 arm: mvebu: Synchronize armada-385.dtsi with Linux v5.20 arm: mvebu: Synchronize armada-385-turris-omnia with Linux v5.20 arch/arm/dts/armada-370-xp.dtsi | 2 +- arch/arm/dts/armada-375.dtsi | 2 +- arch/arm/dts/armada-385-turris-omnia-u-boot.dtsi | 5 +- arch/arm/dts/armada-385-turris-omnia.dts | 241 ++++++++-- arch/arm/dts/armada-385.dtsi | 52 +- arch/arm/dts/armada-38x.dtsi | 59 ++- arch/arm/dts/armada-xp-db-xc3-24g4xg-u-boot.dtsi | 2 +- board/CZ.NIC/turris_omnia/MAINTAINERS | 1 + cmd/mvebu/Kconfig | 1 + cmd/mvebu/bubt.c | 98 ++-- configs/turris_omnia_defconfig | 3 +- drivers/gpio/Kconfig | 7 + drivers/gpio/Makefile | 1 + drivers/gpio/gpio-rcar.c | 2 +- drivers/gpio/mvebu_gpio.c | 11 +- drivers/gpio/turris_omnia_mcu.c | 309 ++++++++++++ drivers/mtd/nand/raw/pxa3xx_nand.c | 2 +- drivers/pinctrl/mvebu/Kconfig | 7 + drivers/pinctrl/mvebu/Makefile | 1 + drivers/pinctrl/mvebu/pinctrl-armada-37xx.c | 189 ++++++-- drivers/pinctrl/mvebu/pinctrl-armada-38x.c | 589 +++++++++++++++++++++++ drivers/pinctrl/mvebu/pinctrl-mvebu.c | 4 +- drivers/pinctrl/pinctrl-generic.c | 100 +++- drivers/pinctrl/pinctrl-uclass.c | 3 +- include/dm/pinctrl.h | 5 +- 25 files changed, 1532 insertions(+), 164 deletions(-) create mode 100644 drivers/gpio/turris_omnia_mcu.c create mode 100644 drivers/pinctrl/mvebu/pinctrl-armada-38x.c

2 1

[PATCH u-boot-marvell] arm: mvebu: turris_omnia: Fix mpp26 pin name and comment
by Marek Behún 29 Jul '22

29 Jul '22

There is a bug in Turris Omnia's schematics, whereupon the MPP[26] pin, which is routed to CN11 pin header, is documented as SPI CS1, but MPP[26] pin does not support this function. Instead it controls chip select 2 if in "spi0" mode. Fix the name of the pin node in pinctrl node and fix the comment in SPI node. Signed-off-by: Marek Behún <kabel(a)kernel.org> --- The same patch is being sent to linux, https://lore.kernel.org/linux-arm-kernel/20220727125610.20782-1-kabel@kerne… --- arch/arm/dts/armada-385-turris-omnia.dts | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/dts/armada-385-turris-omnia.dts b/arch/arm/dts/armada-385-turris-omnia.dts index 7f1478edfd..617522be17 100644 --- a/arch/arm/dts/armada-385-turris-omnia.dts +++ b/arch/arm/dts/armada-385-turris-omnia.dts @@ -345,7 +345,7 @@ marvell,function = "spi0"; }; - spi0cs1_pins: spi0cs1-pins { + spi0cs2_pins: spi0cs2-pins { marvell,pins = "mpp26"; marvell,function = "spi0"; }; @@ -380,7 +380,7 @@ }; }; - /* MISO, MOSI, SCLK and CS1 are routed to pin header CN11 */ + /* MISO, MOSI, SCLK and CS2 are routed to pin header CN11 */ }; &uart0 { -- 2.35.1

2 2