April 2020 - U-Boot

[PATCH v2 00/19] i.MXRT1050 add LCDIF support
by Giulio Benetti 17 Apr '20

17 Apr '20

This patchset add support for LCDIF on i.MXRT1050 evk. This requires PLL5 to be setup, mxsfb needs to use display_timing to retrieve if Lcd has inverted PIXCLOCK from dts. With this patchset applied we temporary loose DCache support until it will get implemented, since a function in mxsfb.c is needed for setting cache behaviour. Anyway this way Lcd will show the console same way as serial does. Also I've moved private sunxi_ctfb_mode_to_display_timing() to videomodes since I need it for mxfsb.c too, then having a unified function to convert from ctfb_mode to display_timing. Changes: V1->V2: * moved hard-coded LCDIF's parent clock from clk-imxrt1050.c to imxrt1050-evk.dts * reworded some commit log Giulio Benetti (19): clk: imx: pllv3: add enable_bit clk: imx: clk-imxrt1050: fix typo in clock name "video:" clk: imx: clk-imxrt1050: setup PLL5 for video in non-SPL clk: imx: clk-imxrt1050: add set_parent() callback videomodes: add helper function to convert from ctfb to display_timing sunxi: display: use common video_ctfb_mode_to_display_timing() video: mxsfb: add support for DM CLK video: mxsfb: add support for i.MXRT video: mxsfb: refactor for using display_timings video: mxsfb: enable setting HSYNC negative polarity video: mxsfb: enable setting VSYNC negative polarity video: mxsfb: enable setting PIXDATA on negative edge video: mxsfb: enable setting ENABLE negative polarity imxrt1050_evk: add 16bpp video support if video layer enabled ARM: dts: i.mxrt1050: add lcdif node ARM: dts: imxrt1050: allow this dtsi file to be compiled in Linux arch: arm: dts: imxrt1050-evk: add lcdif node configs: imxrt1050-evk: enable video support/console configs: imxrt1050-evk: temporary disable DCACHE arch/arm/dts/imxrt1050-evk.dts | 60 ++++++++++++++ arch/arm/dts/imxrt1050.dtsi | 14 +++- arch/arm/include/asm/arch-imxrt/imx-regs.h | 6 ++ arch/arm/include/asm/mach-imx/regs-lcdif.h | 6 +- configs/imxrt1050-evk_defconfig | 6 ++ drivers/clk/imx/clk-imxrt1050.c | 30 ++++++- drivers/clk/imx/clk-pllv3.c | 9 +++ drivers/video/mxsfb.c | 94 ++++++++++++++-------- drivers/video/sunxi/sunxi_display.c | 33 +------- drivers/video/videomodes.c | 29 +++++++ drivers/video/videomodes.h | 3 + include/configs/imxrt1050-evk.h | 15 ++++ 12 files changed, 234 insertions(+), 71 deletions(-) -- 2.20.1

3 27

[PATCH 1/1] doc/efi: rework secure boot description
by Heinrich Schuchardt 17 Apr '20

17 Apr '20

Ensure a uniform formatting. Some rephrasing. Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- doc/uefi/uefi.rst | 110 ++++++++++++++++++++++++++-------------------- 1 file changed, 62 insertions(+), 48 deletions(-) diff --git a/doc/uefi/uefi.rst b/doc/uefi/uefi.rst index a35fbd331c..4fda00d687 100644 --- a/doc/uefi/uefi.rst +++ b/doc/uefi/uefi.rst @@ -100,79 +100,93 @@ See doc/uImage.FIT/howto.txt for an introduction to FIT images. Configuring UEFI secure boot ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -UEFI specification[1] defines a secure way of executing UEFI images +The UEFI specification[1] defines a secure way of executing UEFI images by verifying a signature (or message digest) of image with certificates. This feature on U-Boot is enabled with:: CONFIG_UEFI_SECURE_BOOT=y To make the boot sequence safe, you need to establish a chain of trust; -In UEFI secure boot, you can make it with the UEFI variables, "PK" -(Platform Key), "KEK" (Key Exchange Keys), "db" (white list database) -and "dbx" (black list database). +In UEFI secure boot the chain trust is defined by the following UEFI variables -There are many online documents that describe what UEFI secure boot is -and how it works. Please consult some of them for details. +* PK - Platform Key +* KEK - Key Exchange Keys +* db - white list database +* dbx - black list database -Here is a simple example that you can follow for your initial attempt -(Please note that the actual steps would absolutely depend on your system -and environment.): +An in depth description of UEFI secure boot is beyond the scope of this +document. Please, refer to the UEFI specification and available online +documentation. Here is a simple example that you can follow for your initial +attempt (Please note that the actual steps will depend on your system and +environment.): -1. Install utility commands on your host - * openssl - * efitools - * sbsigntool +Install the required tools on your host -2. Create signing keys and key database files on your host - for PK:: +* openssl +* efitools +* sbsigntool - $ openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_PK/ \ - -keyout PK.key -out PK.crt -nodes -days 365 - $ cert-to-efi-sig-list -g 11111111-2222-3333-4444-123456789abc \ - PK.crt PK.esl; - $ sign-efi-sig-list -c PK.crt -k PK.key PK PK.esl PK.auth +Create signing keys and the key database on your host: - for KEK:: +The platform key - $ openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_KEK/ \ - -keyout KEK.key -out KEK.crt -nodes -days 365 - $ cert-to-efi-sig-list -g 11111111-2222-3333-4444-123456789abc \ - KEK.crt KEK.esl - $ sign-efi-sig-list -c PK.crt -k PK.key KEK KEK.esl KEK.auth +.. code-block:: bash - for db:: + openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_PK/ \ + -keyout PK.key -out PK.crt -nodes -days 365 + cert-to-efi-sig-list -g 11111111-2222-3333-4444-123456789abc \ + PK.crt PK.esl; + sign-efi-sig-list -c PK.crt -k PK.key PK PK.esl PK.auth - $ openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_db/ \ - -keyout db.key -out db.crt -nodes -days 365 - $ cert-to-efi-sig-list -g 11111111-2222-3333-4444-123456789abc \ - db.crt db.esl - $ sign-efi-sig-list -c KEK.crt -k KEK.key db db.esl db.auth +The key exchange keys - Copy \*.auth to media, say mmc, that is accessible from U-Boot. +.. code-block:: bash -3. Sign an image with one key in "db" on your host:: + openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_KEK/ \ + -keyout KEK.key -out KEK.crt -nodes -days 365 + cert-to-efi-sig-list -g 11111111-2222-3333-4444-123456789abc \ + KEK.crt KEK.esl + sign-efi-sig-list -c PK.crt -k PK.key KEK KEK.esl KEK.auth - $ sbsign --key db.key --cert db.crt helloworld.efi +The whitelist database -4. Install keys on your board:: +.. code-block:: bash - ==> fatload mmc 0:1 <tmpaddr> PK.auth - ==> setenv -e -nv -bs -rt -at -i <tmpaddr>,$filesize PK - ==> fatload mmc 0:1 <tmpaddr> KEK.auth - ==> setenv -e -nv -bs -rt -at -i <tmpaddr>,$filesize KEK - ==> fatload mmc 0:1 <tmpaddr> db.auth - ==> setenv -e -nv -bs -rt -at -i <tmpaddr>,$filesize db + $ openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_db/ \ + -keyout db.key -out db.crt -nodes -days 365 + $ cert-to-efi-sig-list -g 11111111-2222-3333-4444-123456789abc \ + db.crt db.esl + $ sign-efi-sig-list -c KEK.crt -k KEK.key db db.esl db.auth -5. Set up boot parameters on your board:: +Copy the \*.auth files to media, say mmc, that is accessible from U-Boot. - ==> efidebug boot add 1 HELLO mmc 0:1 /helloworld.efi.signed "" +Sign an image with one of the keys in "db" on your host -Then your board runs that image from Boot manager (See below). +.. code-block:: bash + + sbsign --key db.key --cert db.crt helloworld.efi + +Now in U-Boot install the keys on your board:: + + fatload mmc 0:1 <tmpaddr> PK.auth + setenv -e -nv -bs -rt -at -i <tmpaddr>,$filesize PK + fatload mmc 0:1 <tmpaddr> KEK.auth + setenv -e -nv -bs -rt -at -i <tmpaddr>,$filesize KEK + fatload mmc 0:1 <tmpaddr> db.auth + setenv -e -nv -bs -rt -at -i <tmpaddr>,$filesize db + +Set up boot parameters on your board:: + + efidebug boot add 1 HELLO mmc 0:1 /helloworld.efi.signed "" + +Now your board can run the signed image via the boot manager (see below). You can also try this sequence by running Pytest, test_efi_secboot, -on sandbox:: +on the sandbox + +.. code-block:: bash - $ cd <U-Boot source directory> - $ pytest.py test/py/tests/test_efi_secboot/test_signed.py --bd sandbox + cd <U-Boot source directory> + pytest.py test/py/tests/test_efi_secboot/test_signed.py --bd sandbox Executing the boot manager ~~~~~~~~~~~~~~~~~~~~~~~~~~ -- 2.25.1

1 0

[PATCH v2 0/8] A small set of arm cleanups
by Trevor Woerner 17 Apr '20

17 Apr '20

This patch series presents a set of cleanups I stumbled across while looking at some arm-related code. A long time ago there was an effort to follow the Linux kernel's convention of putting SoC-specific code in arch/$(ARCH)/mach-$(SOC) instead of the previous location of arch/$(ARCH)/cpu/$(CPU)/$(SOC). For some reason this didn't occur with code for NXP's LPC32xx SoC. Therefore the first patch performs this move. While moving the code, I noticed that years of editing had caused a list in arch/arm/Makefile to not be sorted alphanumerically anymore, despite the comment's request to do so. Therefore the second patch re-orders the list to put it back in alphanumerical order. While sorting the above-mentioned list, I noticed that there were 4 symbol names that were not following the convention of other symbols: CONFIG_KIRKWOOD, CONFIG_ORION5X, CONFIG_TEGRA, and CONFIG_STM32. These symbols should have the pattern: CONFIG_ARCH_<machine>. Therefore more patches were created to fix these symbol names. While renaming the CONFIG_ARCH_ORION5X symbol I noticed that this SoC had code both in arch/$(ARCH)/cpu/$(CPU)/$(SOC) and arch/$(ARCH)/mach-$(SOC), so there's a patch to complete this move. Also, I found a typo, so another patch. Changes in v2: - Update the commit message to fix the error identified by checkpatch.pl, namely to fix the formatting used to reference a prior commit. - Improve the wording of the commit message, mostly to specify that the sorting was done assuming all symbols had "ARCH_" in the middle. - Update patch to work on latest master; the location where the SPL linker script is specified has changed. - Add Chris Packham's r-b - Added a cover letter. - In the original series I only renamed 2 of the 4 symbols that were missing the "ARCH_" string (CONFIG_ORION5X and CONFIG_KIRKWOOD), since those were the only 2 with TODOs attached to them. As part of v2 I also converted CONFIG_TEGRA and CONFIG_STM32 Trevor Woerner (8): arm: lpc32xx: move SoC to mach-lpc32xx arch/arm/Makefile: sort machine names rename symbol: CONFIG_ORION5X -> CONFIG_ARCH_ORION5X arm: orion5x: finish moving SoC to mach-orion5x rename symbol: CONFIG_KIRKWOOD -> CONFIG_ARCH_KIRKWOOD rename symbol: CONFIG_TEGRA -> CONFIG_ARCH_TEGRA rename symbol: CONFIG_STM32 -> CONFIG_ARCH_STM32 drivers/reset/Kconfig: fix typo Kconfig | 2 +- Makefile | 4 ++-- arch/arm/Kconfig | 10 ++++---- arch/arm/Makefile | 24 +++++++++---------- arch/arm/cpu/arm720t/interrupts.c | 2 +- arch/arm/cpu/arm926ejs/Makefile | 1 - arch/arm/cpu/armv7/Kconfig | 2 +- arch/arm/dts/Makefile | 4 ++-- arch/arm/mach-kirkwood/Kconfig | 2 +- .../lpc32xx => mach-lpc32xx}/Kconfig | 0 .../lpc32xx => mach-lpc32xx}/Makefile | 0 .../arm926ejs/lpc32xx => mach-lpc32xx}/clk.c | 0 .../arm926ejs/lpc32xx => mach-lpc32xx}/cpu.c | 0 .../lpc32xx => mach-lpc32xx}/devices.c | 0 .../arm926ejs/lpc32xx => mach-lpc32xx}/dram.c | 0 .../lpc32xx => mach-lpc32xx}/lowlevel_init.S | 0 .../lpc32xx => mach-lpc32xx}/timer.c | 0 arch/arm/mach-mvebu/Makefile | 6 ++--- arch/arm/mach-mvebu/mbus.c | 6 ++--- arch/arm/mach-orion5x/Kconfig | 2 +- .../orion5x => mach-orion5x}/u-boot-spl.lds | 0 arch/arm/mach-stm32/Kconfig | 2 +- arch/arm/mach-tegra/Kconfig | 2 +- board/keymile/Kconfig | 12 +++++----- common/spl/Kconfig | 4 ++-- config.mk | 2 +- configs/SBx81LIFKW_defconfig | 2 +- configs/SBx81LIFXCAT_defconfig | 2 +- configs/apalis-tk1_defconfig | 2 +- configs/apalis_t30_defconfig | 2 +- configs/beaver_defconfig | 2 +- configs/cardhu_defconfig | 2 +- configs/cei-tk1-som_defconfig | 2 +- configs/colibri_t20_defconfig | 2 +- configs/colibri_t30_defconfig | 2 +- configs/d2net_v2_defconfig | 2 +- configs/dalmore_defconfig | 2 +- configs/db-88f6281-bp-nand_defconfig | 2 +- configs/db-88f6281-bp-spi_defconfig | 2 +- configs/dns325_defconfig | 2 +- configs/dockstar_defconfig | 2 +- configs/dreamplug_defconfig | 2 +- configs/ds109_defconfig | 2 +- configs/e2220-1170_defconfig | 2 +- configs/edminiv2_defconfig | 4 ++-- configs/goflexhome_defconfig | 2 +- configs/guruplug_defconfig | 2 +- configs/harmony_defconfig | 2 +- configs/ib62x0_defconfig | 2 +- configs/iconnect_defconfig | 2 +- configs/inetspace_v2_defconfig | 2 +- configs/jetson-tk1_defconfig | 2 +- configs/km_kirkwood_128m16_defconfig | 2 +- configs/km_kirkwood_defconfig | 2 +- configs/km_kirkwood_pci_defconfig | 2 +- configs/kmcoge5un_defconfig | 2 +- configs/kmnusa_defconfig | 2 +- configs/kmsuse2_defconfig | 2 +- configs/lschlv2_defconfig | 2 +- configs/lsxhl_defconfig | 2 +- configs/medcom-wide_defconfig | 2 +- configs/nas220_defconfig | 2 +- configs/net2big_v2_defconfig | 2 +- configs/netspace_lite_v2_defconfig | 2 +- configs/netspace_max_v2_defconfig | 2 +- configs/netspace_mini_v2_defconfig | 2 +- configs/netspace_v2_defconfig | 2 +- configs/nsa310s_defconfig | 2 +- configs/nyan-big_defconfig | 2 +- configs/openrd_base_defconfig | 2 +- configs/openrd_client_defconfig | 2 +- configs/openrd_ultimate_defconfig | 2 +- configs/p2371-0000_defconfig | 2 +- configs/p2371-2180_defconfig | 2 +- configs/p2571_defconfig | 2 +- configs/p2771-0000-000_defconfig | 2 +- configs/p2771-0000-500_defconfig | 2 +- configs/p3450-0000_defconfig | 2 +- configs/paz00_defconfig | 2 +- configs/plutux_defconfig | 2 +- configs/pogo_e02_defconfig | 2 +- configs/seaboard_defconfig | 2 +- configs/sheevaplug_defconfig | 2 +- configs/stm32f429-discovery_defconfig | 2 +- configs/stm32f429-evaluation_defconfig | 2 +- configs/stm32f469-discovery_defconfig | 2 +- configs/stm32f746-disco_defconfig | 2 +- configs/stm32f769-disco_defconfig | 2 +- configs/stm32h743-disco_defconfig | 2 +- configs/stm32h743-eval_defconfig | 2 +- configs/tec-ng_defconfig | 2 +- configs/tec_defconfig | 2 +- configs/trimslice_defconfig | 2 +- configs/venice2_defconfig | 2 +- configs/ventana_defconfig | 2 +- disk/Kconfig | 4 ++-- drivers/ata/mvsata_ide.c | 4 ++-- drivers/ata/sata_mv.c | 2 +- drivers/gpio/Kconfig | 2 +- drivers/i2c/Kconfig | 2 +- drivers/i2c/mvtwsi.c | 6 ++--- drivers/mailbox/Kconfig | 2 +- drivers/misc/Kconfig | 2 +- drivers/mmc/Kconfig | 2 +- drivers/net/Kconfig | 2 +- drivers/net/mvgbe.c | 4 ++-- drivers/pci/Kconfig | 2 +- drivers/reset/Kconfig | 4 ++-- drivers/spi/kirkwood_spi.c | 10 ++++---- drivers/usb/host/Kconfig | 4 ++-- drivers/usb/host/ehci-marvell.c | 4 ++-- drivers/video/Kconfig | 2 +- include/serial.h | 2 +- tools/Makefile | 4 ++-- 114 files changed, 144 insertions(+), 147 deletions(-) rename arch/arm/{cpu/arm926ejs/lpc32xx => mach-lpc32xx}/Kconfig (100%) rename arch/arm/{cpu/arm926ejs/lpc32xx => mach-lpc32xx}/Makefile (100%) rename arch/arm/{cpu/arm926ejs/lpc32xx => mach-lpc32xx}/clk.c (100%) rename arch/arm/{cpu/arm926ejs/lpc32xx => mach-lpc32xx}/cpu.c (100%) rename arch/arm/{cpu/arm926ejs/lpc32xx => mach-lpc32xx}/devices.c (100%) rename arch/arm/{cpu/arm926ejs/lpc32xx => mach-lpc32xx}/dram.c (100%) rename arch/arm/{cpu/arm926ejs/lpc32xx => mach-lpc32xx}/lowlevel_init.S (100%) rename arch/arm/{cpu/arm926ejs/lpc32xx => mach-lpc32xx}/timer.c (100%) rename arch/arm/{cpu/arm926ejs/orion5x => mach-orion5x}/u-boot-spl.lds (100%) -- 2.26.0.106.g9fadedd637

1 8

[PATCH v10 00/12] Actions S700 SoC support
by Amit Singh Tomar 17 Apr '20

17 Apr '20

This adds Cubieboard7[1] support based on Action Semi's S700 SoC[2], It's Quad-core ARMv8 SoC with Cortex-A53 cores. Peripheral like UART seems to be compatible with S900 SoC(basic support for it is alreay present in u-boot). This series(v10) takes care the commments provided by Mani and patches 04/12, 07/12 and 12/12 has been changed to address those comments. Previous series(v9) fixes a Bug that breaks bubblegum96 board boot(reported by Mani). It was due to fact that driver data read is not proper in the clock driver. There are changes in patch 06/12 to fix it. Series(v8) removes the SoC specific include instead just uses owl-common. For this patch 01/12 and 09/12 changes a bit. Series(v7) fixes a serious Bug that breaks S900, it was there since v5.Thanks to Andre for pointing it out. Series(v6)[3] does following changes: * [PATCH v5 06/11] becomes [PATCH v6 03/11] * [PATCH v5 03/11] becomes [PATCH v6 04/11] * Introduce a new patch to move defconfig options to Kconfig which is [PATCH v6 10/12] Series(v5)[4] just re-orders the patches so that U-BOOT(with bubblegum96_defconfig) builds after every patch of the series(suggested by Andre). S700 support is tested[5] on Cubieboard7-lite board and S900 support is just compiled tested. This patch series can be tested using below tree: https://github.com/Atomar25/u-boot/commits/s700_v10 [1]: http://www.cubietech.com/product-detail/cubieboard7/ [2]: http://www.actions-semi.com/en/productview.aspx?id=225 [3]: http://u-boot.10912.n7.nabble.com/PATCH-v6-00-12-Actions-S700-SoC-support-t… [4]: http://u-boot.10912.n7.nabble.com/PATCH-v5-00-11-Actions-S700-SoC-support-t… [5]: https://paste.ubuntu.com/p/TbBtk5dPGS/ Amit Singh Tomar (12): arm: actions: Add common framework for Actions Owl Semi SoCs arm: actions: rename sysmap-s900 to sysmap-owl serial: actions: add compatible string arm: dts: sync dts for Action Semi S900 arm: dts: actions: s900: add u-boot specific dtsi file clk: actions: Add common clock driver arm: actions: add S700 SoC device tree arm: dts: actions: s700: add u-boot specific dtsi file arm: add support Actions Semi S700 actions: Move defconfig options to Kconfig arm: add Cubieboard7 board support doc: boards: add Cubieboard7 documentation MAINTAINERS | 3 +- arch/arm/Kconfig | 5 +- arch/arm/dts/Makefile | 4 +- arch/arm/dts/s700-cubieboard7.dts | 92 +++++++ arch/arm/dts/s700-u-boot.dtsi | 18 ++ arch/arm/dts/s700.dtsi | 248 +++++++++++++++++++ arch/arm/dts/s900-u-boot.dtsi | 17 ++ arch/arm/dts/s900.dtsi | 322 +++++++++++++++++++++++-- arch/arm/include/asm/arch-owl/clk_s900.h | 57 ----- arch/arm/include/asm/arch-owl/regs_s700.h | 56 +++++ arch/arm/mach-owl/Kconfig | 49 ++-- arch/arm/mach-owl/Makefile | 3 +- arch/arm/mach-owl/soc.c | 57 +++++ arch/arm/mach-owl/sysmap-owl.c | 32 +++ arch/arm/mach-owl/sysmap-s900.c | 32 --- board/ucRobotics/bubblegum_96/Kconfig | 15 -- board/ucRobotics/bubblegum_96/MAINTAINERS | 6 - board/ucRobotics/bubblegum_96/Makefile | 3 - board/ucRobotics/bubblegum_96/bubblegum_96.c | 57 ----- configs/bubblegum_96_defconfig | 12 +- configs/cubieboard7_defconfig | 9 + doc/board/actions/cubieboard7.rst | 114 +++++++++ doc/board/actions/index.rst | 10 + doc/board/index.rst | 1 + drivers/clk/owl/Kconfig | 8 +- drivers/clk/owl/Makefile | 2 +- drivers/clk/owl/clk_owl.c | 155 ++++++++++++ drivers/clk/owl/clk_owl.h | 64 +++++ drivers/clk/owl/clk_s900.c | 137 ----------- drivers/serial/serial_owl.c | 2 +- include/configs/bubblegum_96.h | 40 --- include/configs/owl-common.h | 40 +++ include/dt-bindings/clock/actions,s700-cmu.h | 118 +++++++++ include/dt-bindings/clock/actions,s900-cmu.h | 129 ++++++++++ include/dt-bindings/clock/s900_cmu.h | 77 ------ include/dt-bindings/reset/actions,s700-reset.h | 34 +++ include/dt-bindings/reset/actions,s900-reset.h | 65 +++++ 37 files changed, 1607 insertions(+), 486 deletions(-) create mode 100644 arch/arm/dts/s700-cubieboard7.dts create mode 100644 arch/arm/dts/s700-u-boot.dtsi create mode 100644 arch/arm/dts/s700.dtsi create mode 100644 arch/arm/dts/s900-u-boot.dtsi delete mode 100644 arch/arm/include/asm/arch-owl/clk_s900.h create mode 100644 arch/arm/include/asm/arch-owl/regs_s700.h create mode 100644 arch/arm/mach-owl/soc.c create mode 100644 arch/arm/mach-owl/sysmap-owl.c delete mode 100644 arch/arm/mach-owl/sysmap-s900.c delete mode 100644 board/ucRobotics/bubblegum_96/Kconfig delete mode 100644 board/ucRobotics/bubblegum_96/MAINTAINERS delete mode 100644 board/ucRobotics/bubblegum_96/Makefile delete mode 100644 board/ucRobotics/bubblegum_96/bubblegum_96.c create mode 100644 configs/cubieboard7_defconfig create mode 100644 doc/board/actions/cubieboard7.rst create mode 100644 doc/board/actions/index.rst create mode 100644 drivers/clk/owl/clk_owl.c create mode 100644 drivers/clk/owl/clk_owl.h delete mode 100644 drivers/clk/owl/clk_s900.c delete mode 100644 include/configs/bubblegum_96.h create mode 100644 include/configs/owl-common.h create mode 100644 include/dt-bindings/clock/actions,s700-cmu.h create mode 100644 include/dt-bindings/clock/actions,s900-cmu.h delete mode 100644 include/dt-bindings/clock/s900_cmu.h create mode 100644 include/dt-bindings/reset/actions,s700-reset.h create mode 100644 include/dt-bindings/reset/actions,s900-reset.h -- 2.7.4

5 23

[PULL u-boot] Please pull u-boot-amlogic-20200417
by Neil Armstrong 17 Apr '20

17 Apr '20

Hi Tom, This PR enables RNG on meson boards for UEFI, fixes the SMBIOS information for ODROID-C2, fixes HDMI Video Output broken on GXBB/GXL/GXM based boards and adds support for USB gadget on GXL/GXM boards. The CI job is at https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic/pipelines/2800 Thanks, Neil The following changes since commit 142a07f2a44262d76fec609e1fcde51794a456eb: Merge branch 'master' of git://git.denx.de/u-boot-marvell (2020-04-14 08:47:07 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic.git tags/u-boot-amlogic-20200417 for you to fetch changes up to e8b6dd8263e84f52d91bc0ac3e2582cb6e832307: configs: libretech-s912-pc: Enable USB gadget with Mass Storage function (2020-04-17 09:52:13 +0200) ---------------------------------------------------------------- - enable DM_RNG on meson boards - fix SMBIOS info on Odroid-C2 - Fix video output on GXBB/GXL/GXM boards - add USB gadget support for GXL/GXM boards ---------------------------------------------------------------- Heinrich Schuchardt (2): arm: meson: imply DM_RNG configs: correct SMBIOS information for ODROID-C2 Neil Armstrong (12): ARM: dts: add missing meson-gxl-s805x-libretech-ac-u-boot.dtsi file arm64: dts: meson-gx: add back dmc register range until canvas driver is available generic-phy: add generic_phy_get_by_node() phy: meson-gxl-usb: add set_mode call to force switch to peripheral mode arm: meson-gx: add board_usb_init()/cleanup() for USB gadget arm: dts: meson-gxl: Add USB Gadget nodes for U-Boot configs: libretech-cc: Enable USB gadget with Mass Storage function configs: libretech-ac: Enable USB gadget with Mass Storage function configs: khadas-vim2: Enable USB gadget with Mass Storage function configs: khadas-vim: Enable USB gadget with Mass Storage function configs: libretech-s905d-pc: Enable USB gadget with Mass Storage function configs: libretech-s912-pc: Enable USB gadget with Mass Storage function arch/arm/Kconfig | 1 + arch/arm/dts/meson-gx-u-boot.dtsi | 4 + .../dts/meson-gxl-s805x-libretech-ac-u-boot.dtsi | 7 ++ .../arm/dts/meson-gxl-s905x-khadas-vim-u-boot.dtsi | 2 +- .../dts/meson-gxl-s905x-libretech-cc-u-boot.dtsi | 6 +- arch/arm/dts/meson-gxl-s905x-p212-u-boot.dtsi | 2 +- arch/arm/dts/meson-gxl-u-boot.dtsi | 23 ++++ arch/arm/include/asm/arch-meson/usb-gx.h | 16 +++ arch/arm/mach-meson/board-gx.c | 118 +++++++++++++++++++++ configs/khadas-vim2_defconfig | 7 ++ configs/khadas-vim_defconfig | 7 ++ configs/libretech-ac_defconfig | 7 ++ configs/libretech-cc_defconfig | 7 ++ configs/libretech-s905d-pc_defconfig | 7 ++ configs/libretech-s912-pc_defconfig | 7 ++ configs/odroid-c2_defconfig | 2 + drivers/phy/meson-gxl-usb2.c | 30 ++++-- drivers/phy/meson-gxl-usb3.c | 44 +++++--- drivers/phy/phy-uclass.c | 16 ++- include/generic-phy.h | 27 +++++ 20 files changed, 314 insertions(+), 26 deletions(-) create mode 100644 arch/arm/dts/meson-gxl-s805x-libretech-ac-u-boot.dtsi create mode 100644 arch/arm/dts/meson-gxl-u-boot.dtsi create mode 100644 arch/arm/include/asm/arch-meson/usb-gx.h

2 2

[PATCH 1/5] wandboard: Fix detection for mx6q/mx6dl revD1 revariants
by Fabio Estevam 17 Apr '20

17 Apr '20

The detection of the revD1 version is based on the presence of the PMIC. Currently revb1 device trees are used for mx6q/mx6dl variants, which do not have the PMIC nodes. This causes revD1 boards to be incorrectly be detected as revB1. Use the revd1 device trees, so that the PMIC node can be found and then the PMIC can be detected by reading its register ID. Reported-by: Heiko Schocher <hs(a)denx.de> Reported-by: Derek Atkins <derek(a)ihtfp.com> Signed-off-by: Fabio Estevam <festevam(a)gmail.com> --- Hi Heiko, Could you please try this on your mx6dl wandboard revD1 board? I recall you reported this issue sometime ago. Derek tested this on his mx6q wandboard revD1 board and it worked fine. I have also tested it on a revB1 and the version is properly detected. Thanks arch/arm/dts/Makefile | 4 ++-- ...{imx6dl-wandboard-revb1.dts => imx6dl-wandboard-revd1.dts} | 4 ++-- .../{imx6q-wandboard-revb1.dts => imx6q-wandboard-revd1.dts} | 4 ++-- configs/wandboard_defconfig | 4 ++-- 4 files changed, 8 insertions(+), 8 deletions(-) rename arch/arm/dts/{imx6dl-wandboard-revb1.dts => imx6dl-wandboard-revd1.dts} (78%) rename arch/arm/dts/{imx6q-wandboard-revb1.dts => imx6q-wandboard-revd1.dts} (80%) diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 820ee9733a..2a71917c92 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -622,7 +622,7 @@ dtb-y += \ imx6dl-pico.dtb \ imx6dl-sabreauto.dtb \ imx6dl-sabresd.dtb \ - imx6dl-wandboard-revb1.dtb \ + imx6dl-wandboard-revd1.dtb \ endif @@ -654,7 +654,7 @@ dtb-y += \ imx6q-sabrelite.dtb \ imx6q-sabresd.dtb \ imx6q-tbs2910.dtb \ - imx6q-wandboard-revb1.dtb \ + imx6q-wandboard-revd1.dtb \ imx6qp-sabreauto.dtb \ imx6qp-sabresd.dtb \ imx6qp-wandboard-revd1.dtb \ diff --git a/arch/arm/dts/imx6dl-wandboard-revb1.dts b/arch/arm/dts/imx6dl-wandboard-revd1.dts similarity index 78% rename from arch/arm/dts/imx6dl-wandboard-revb1.dts rename to arch/arm/dts/imx6dl-wandboard-revd1.dts index c2946fbaa0..6d1d863c2e 100644 --- a/arch/arm/dts/imx6dl-wandboard-revb1.dts +++ b/arch/arm/dts/imx6dl-wandboard-revd1.dts @@ -6,10 +6,10 @@ */ /dts-v1/; #include "imx6dl.dtsi" -#include "imx6qdl-wandboard-revb1.dtsi" +#include "imx6qdl-wandboard-revd1.dtsi" / { - model = "Wandboard i.MX6 Dual Lite Board rev B1"; + model = "Wandboard i.MX6 Dual Lite Board revD1"; compatible = "wand,imx6dl-wandboard", "fsl,imx6dl"; memory@10000000 { diff --git a/arch/arm/dts/imx6q-wandboard-revb1.dts b/arch/arm/dts/imx6q-wandboard-revd1.dts similarity index 80% rename from arch/arm/dts/imx6q-wandboard-revb1.dts rename to arch/arm/dts/imx6q-wandboard-revd1.dts index f6ccbecff9..55331021d8 100644 --- a/arch/arm/dts/imx6q-wandboard-revb1.dts +++ b/arch/arm/dts/imx6q-wandboard-revd1.dts @@ -6,10 +6,10 @@ */ /dts-v1/; #include "imx6q.dtsi" -#include "imx6qdl-wandboard-revb1.dtsi" +#include "imx6qdl-wandboard-revd1.dtsi" / { - model = "Wandboard i.MX6 Quad Board rev B1"; + model = "Wandboard i.MX6 Quad Board revD1"; compatible = "wand,imx6q-wandboard", "fsl,imx6q"; memory@10000000 { diff --git a/configs/wandboard_defconfig b/configs/wandboard_defconfig index 82e517b90f..ee70758f3a 100644 --- a/configs/wandboard_defconfig +++ b/configs/wandboard_defconfig @@ -46,8 +46,8 @@ CONFIG_CMD_BMP=y CONFIG_CMD_CACHE=y CONFIG_CMD_EXT4_WRITE=y CONFIG_OF_CONTROL=y -CONFIG_DEFAULT_DEVICE_TREE="imx6dl-wandboard-revb1" -CONFIG_OF_LIST="imx6q-wandboard-revb1 imx6qp-wandboard-revd1 imx6dl-wandboard-revb1" +CONFIG_DEFAULT_DEVICE_TREE="imx6dl-wandboard-revd1" +CONFIG_OF_LIST="imx6q-wandboard-revd1 imx6qp-wandboard-revd1 imx6dl-wandboard-revd1" CONFIG_MULTI_DTB_FIT=y CONFIG_ENV_IS_IN_MMC=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y -- 2.17.1

3 12

A64-Olinuxino-eMMC no USB
by Philip Rinn 17 Apr '20

17 Apr '20

Hi, USB is not working on my Olimex A64-Olinuxino-1Ge4GW Rev. D, no matter if I use the u-boot variant with or without eMMC (but that's no surprise). I use the version provided by Debian, 2020.04+dfsg-1 withe image provided by Armbian it didn't work either. I attached boot logs with and without attached USB key. In both cases one gets an "EHCI failed to shut down host controller." while loading the kernels fdt. The error message with attached USB key is: scanning bus usb@1c1b400 for devices... ERROR: USB-error: DEVICENOTRESPONDING: Device did not respond to token (IN) or did not provide a handshake (OUT) (5) ERROR: USB-error: DEVICENOTRESPONDING: Device did not respond to token (IN) or did not provide a handshake (OUT) (5) USB device not accepting new address (error=20) After booting Linux there is still no USB available, but that's a different bug I guess ;-). I attached the dmesg log anyway. I also filed a Debian bug report about the issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956923. Best, Philip

1 0

[PATCH] pwm: Add PWM driver for SiFive SoC
by Yash Shah 17 Apr '20

17 Apr '20

Adds a PWM driver for PWM chip present in SiFive's HiFive Unleashed SoC This driver is simple port of Linux pwm sifive driver. Signed-off-by: Yash Shah <yash.shah(a)sifive.com> --- drivers/pwm/Kconfig | 6 ++ drivers/pwm/Makefile | 1 + drivers/pwm/pwm-sifive.c | 181 +++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 188 insertions(+) create mode 100644 drivers/pwm/pwm-sifive.c diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig index 1f36fc7..d6ea9ee 100644 --- a/drivers/pwm/Kconfig +++ b/drivers/pwm/Kconfig @@ -40,6 +40,12 @@ config PWM_SANDBOX useful. The PWM can be enabled but is not connected to any outputs so this is not very useful. +config PWM_SIFIVE + bool "Enable support for SiFive PWM" + depends on DM_PWM + help + This PWM is found SiFive's FU540 and other SoCs. + config PWM_TEGRA bool "Enable support for the Tegra PWM" depends on DM_PWM diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile index a837c35..e2d4185 100644 --- a/drivers/pwm/Makefile +++ b/drivers/pwm/Makefile @@ -12,6 +12,7 @@ obj-$(CONFIG_DM_PWM) += pwm-uclass.o obj-$(CONFIG_PWM_EXYNOS) += exynos_pwm.o obj-$(CONFIG_PWM_IMX) += pwm-imx.o pwm-imx-util.o +obj-$(CONFIG_PWM_SIFIVE) += pwm-sifive.o obj-$(CONFIG_PWM_ROCKCHIP) += rk_pwm.o obj-$(CONFIG_PWM_SANDBOX) += sandbox_pwm.o obj-$(CONFIG_PWM_TEGRA) += tegra_pwm.o diff --git a/drivers/pwm/pwm-sifive.c b/drivers/pwm/pwm-sifive.c new file mode 100644 index 0000000..c54297e --- /dev/null +++ b/drivers/pwm/pwm-sifive.c @@ -0,0 +1,181 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2020 SiFive, Inc + * For SiFive's PWM IP block documentation please refer Chapter 14 of + * Reference Manual : https://static.dev.sifive.com/FU540-C000-v1.0.pdf + * + * Limitations: + * - When changing both duty cycle and period, we cannot prevent in + * software that the output might produce a period with mixed + * settings (new period length and old duty cycle). + * - The hardware cannot generate a 100% duty cycle. + * - The hardware generates only inverted output. + */ + +#include <common.h> +#include <clk.h> +#include <div64.h> +#include <dm.h> +#include <pwm.h> +#include <regmap.h> +#include <linux/io.h> +#include <linux/log2.h> +#include <linux/bitfield.h> + +/* PWMCFG fields */ +#define PWM_SIFIVE_PWMCFG_SCALE GENMASK(3, 0) +#define PWM_SIFIVE_PWMCFG_STICKY BIT(8) +#define PWM_SIFIVE_PWMCFG_ZERO_CMP BIT(9) +#define PWM_SIFIVE_PWMCFG_DEGLITCH BIT(10) +#define PWM_SIFIVE_PWMCFG_EN_ALWAYS BIT(12) +#define PWM_SIFIVE_PWMCFG_EN_ONCE BIT(13) +#define PWM_SIFIVE_PWMCFG_CENTER BIT(16) +#define PWM_SIFIVE_PWMCFG_GANG BIT(24) +#define PWM_SIFIVE_PWMCFG_IP BIT(28) + +/* PWM_SIFIVE_SIZE_PWMCMP is used to calculate offset for pwmcmpX registers */ +#define PWM_SIFIVE_SIZE_PWMCMP 4 +#define PWM_SIFIVE_CMPWIDTH 16 + +DECLARE_GLOBAL_DATA_PTR; + +struct pwm_sifive_regs { + unsigned long cfg; + unsigned long cnt; + unsigned long pwms; + unsigned long cmp0; +}; + +struct pwm_sifive_data { + struct pwm_sifive_regs regs; +}; + +struct pwm_sifive_priv { + fdt_addr_t base; + ulong freq; + const struct pwm_sifive_data *data; +}; + +static int pwm_sifive_set_invert(struct udevice *dev, uint channel, + bool polarity) +{ + debug("%s: Do not support polarity\n", __func__); + + return 0; +} + +static int pwm_sifive_set_config(struct udevice *dev, uint channel, + uint period_ns, uint duty_ns) +{ + struct pwm_sifive_priv *priv = dev_get_priv(dev); + const struct pwm_sifive_regs *regs = &priv->data->regs; + unsigned long scale_pow; + unsigned long long num; + u32 scale, val = 0, frac; + + debug("%s: period_ns=%u, duty_ns=%u\n", __func__, period_ns, duty_ns); + + /* + * The PWM unit is used with pwmzerocmp=0, so the only way to modify the + * period length is using pwmscale which provides the number of bits the + * counter is shifted before being feed to the comparators. A period + * lasts (1 << (PWM_SIFIVE_CMPWIDTH + pwmscale)) clock ticks. + * (1 << (PWM_SIFIVE_CMPWIDTH + scale)) * 10^9/rate = period + */ + scale_pow = lldiv((uint64_t)priv->freq * period_ns, 1000000000); + scale = clamp(ilog2(scale_pow) - PWM_SIFIVE_CMPWIDTH, 0, 0xf); + val |= FIELD_PREP(PWM_SIFIVE_PWMCFG_SCALE, scale); + + /* + * The problem of output producing mixed setting as mentioned at top, + * occurs here. To minimize the window for this problem, we are + * calculating the register values first and then writing them + * consecutively + */ + num = (u64)duty_ns * (1U << PWM_SIFIVE_CMPWIDTH); + frac = DIV_ROUND_CLOSEST_ULL(num, period_ns); + frac = min(frac, (1U << PWM_SIFIVE_CMPWIDTH) - 1); + + writel(val, (void __iomem *)priv->base + regs->cfg); + writel(frac, (void __iomem *)priv->base + regs->cmp0 + channel * + PWM_SIFIVE_SIZE_PWMCMP); + + return 0; +} + +static int pwm_sifive_set_enable(struct udevice *dev, uint channel, bool enable) +{ + struct pwm_sifive_priv *priv = dev_get_priv(dev); + const struct pwm_sifive_regs *regs = &priv->data->regs; + u32 val; + + debug("%s: Enable '%s'\n", __func__, dev->name); + + if (enable) { + val = readl((void __iomem *)priv->base + regs->cfg); + val |= PWM_SIFIVE_PWMCFG_EN_ALWAYS; + writel(val, (void __iomem *)priv->base + regs->cfg); + } else { + writel(0, (void __iomem *)priv->base + regs->cmp0 + channel * + PWM_SIFIVE_SIZE_PWMCMP); + } + + return 0; +} + +static int pwm_sifive_ofdata_to_platdata(struct udevice *dev) +{ + struct pwm_sifive_priv *priv = dev_get_priv(dev); + + priv->base = dev_read_addr(dev); + + return 0; +} + +static int pwm_sifive_probe(struct udevice *dev) +{ + struct pwm_sifive_priv *priv = dev_get_priv(dev); + struct clk clk; + int ret = 0; + + ret = clk_get_by_index(dev, 0, &clk); + if (ret < 0) { + debug("%s get clock fail!\n", __func__); + return -EINVAL; + } + + priv->freq = clk_get_rate(&clk); + priv->data = (struct pwm_sifive_data *)dev_get_driver_data(dev); + + return 0; +} + +static const struct pwm_ops pwm_sifive_ops = { + .set_invert = pwm_sifive_set_invert, + .set_config = pwm_sifive_set_config, + .set_enable = pwm_sifive_set_enable, +}; + +static const struct pwm_sifive_data pwm_data = { + .regs = { + .cfg = 0x00, + .cnt = 0x08, + .pwms = 0x10, + .cmp0 = 0x20, + }, +}; + +static const struct udevice_id pwm_sifive_ids[] = { + { .compatible = "sifive,pwm0", .data = (ulong)&pwm_data}, + { } +}; + +U_BOOT_DRIVER(pwm_sifive) = { + .name = "pwm_sifive", + .id = UCLASS_PWM, + .of_match = pwm_sifive_ids, + .ops = &pwm_sifive_ops, + .ofdata_to_platdata = pwm_sifive_ofdata_to_platdata, + .probe = pwm_sifive_probe, + .priv_auto_alloc_size = sizeof(struct pwm_sifive_priv), +}; -- 2.7.4

2 2

[PATCH 00/10] meson: enable USB Gadget support fot GXL/GXM SoCs
by Neil Armstrong 17 Apr '20

17 Apr '20

Thit patchset adds support for OTG Gadget mode on the GXL/GXM SoCs. It adds a new API generic_phy_get_by_node() to get the PHY by it's node. It enabled Gadget and USB Mass Storage for libretech-cc, libretech-ac, khadas-vim, khadas-vim2, libretech-s905d-pc and libretech-s912-pc boards. Neil Armstrong (10): generic-phy: add generic_phy_get_by_node() phy: meson-gxl-usb: add set_mode call to force switch to peripheral mode arm: meson-gx: add board_usb_init()/cleanup() for USB gadget arm: dts: meson-gxl: Add USB Gadget nodes for U-Boot configs: libretech-cc: Enable USB gadget with Mass Storage function configs: libretech-ac: Enable USB gadget with Mass Storage function configs: khadas-vim2: Enable USB gadget with Mass Storage function configs: khadas-vim: Enable USB gadget with Mass Storage function configs: libretech-s905d-pc: Enable USB gadget with Mass Storage function configs: libretech-s912-pc: Enable USB gadget with Mass Storage function .../meson-gxl-s905x-khadas-vim-u-boot.dtsi | 2 +- .../meson-gxl-s905x-libretech-cc-u-boot.dtsi | 6 +- arch/arm/dts/meson-gxl-s905x-p212-u-boot.dtsi | 2 +- arch/arm/dts/meson-gxl-u-boot.dtsi | 23 ++++ arch/arm/include/asm/arch-meson/usb-gx.h | 16 +++ arch/arm/mach-meson/board-gx.c | 118 ++++++++++++++++++ configs/khadas-vim2_defconfig | 7 ++ configs/khadas-vim_defconfig | 7 ++ configs/libretech-ac_defconfig | 7 ++ configs/libretech-cc_defconfig | 7 ++ configs/libretech-s905d-pc_defconfig | 7 ++ configs/libretech-s912-pc_defconfig | 7 ++ drivers/phy/meson-gxl-usb2.c | 30 ++++- drivers/phy/meson-gxl-usb3.c | 44 +++++-- drivers/phy/phy-uclass.c | 17 ++- include/generic-phy.h | 27 ++++ 16 files changed, 301 insertions(+), 26 deletions(-) create mode 100644 arch/arm/dts/meson-gxl-u-boot.dtsi create mode 100644 arch/arm/include/asm/arch-meson/usb-gx.h -- 2.22.0

2 13

[PATCH] rockchip: sdram: fix DRAM bank declaration around OP-TEE
by Justin Swartz 17 Apr '20

17 Apr '20

If OP-TEE is configured, it makes sense to use CONFIG_OPTEE_TZDRAM_BASE and CONFIG_OPTEE_TZDRAM_SIZE to declare the boundaries of the TrustZone memory reserved for OP-TEE instead of assuming that a 32MB reservation is always in place. In this case, the following calculations may be used to determine the boundaries of DRAM bank 0 and 1 which surround the TrustZone reservation: [DRAM bank 0] base = CONFIG_SYS_DRAM_BASE size = CONFIG_OPTEE_TZDRAM_BASE - CONFIG_SYS_SDRAM_BASE [DRAM bank 1] base = CONFIG_OPTEE_TZDRAM_BASE + CONFIG_OPTEE_TZDRAM_SIZE size = top of memory - base of DRAM bank 1 Signed-off-by: Justin Swartz <justin.swartz(a)risingedge.co.za> --- arch/arm/mach-rockchip/sdram.c | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/arch/arm/mach-rockchip/sdram.c b/arch/arm/mach-rockchip/sdram.c index 530644c043..def2c23294 100644 --- a/arch/arm/mach-rockchip/sdram.c +++ b/arch/arm/mach-rockchip/sdram.c @@ -55,16 +55,14 @@ int dram_init_banksize(void) - CONFIG_SYS_SDRAM_BASE; gd->bd->bi_dram[1].start = tos_parameter->tee_mem.phy_addr + tos_parameter->tee_mem.size; - gd->bd->bi_dram[1].size = gd->bd->bi_dram[0].start - + top - gd->bd->bi_dram[1].start; + gd->bd->bi_dram[1].size = top - gd->bd->bi_dram[1].start; } else { gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE; - gd->bd->bi_dram[0].size = 0x8400000; - /* Reserve 32M for OPTEE with TA */ - gd->bd->bi_dram[1].start = CONFIG_SYS_SDRAM_BASE - + gd->bd->bi_dram[0].size + 0x2000000; - gd->bd->bi_dram[1].size = gd->bd->bi_dram[0].start - + top - gd->bd->bi_dram[1].start; + gd->bd->bi_dram[0].size = CONFIG_OPTEE_TZDRAM_BASE + - CONFIG_SYS_SDRAM_BASE; + gd->bd->bi_dram[1].start = CONFIG_OPTEE_TZDRAM_BASE + + CONFIG_OPTEE_TZDRAM_SIZE; + gd->bd->bi_dram[1].size = top - gd->bd->bi_dram[1].start; } #else gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE; -- 2.11.0

2 2