March 2023 - U-Boot

[PATCH] arm: mvebu: Use 4K sector for Thecus N2350 SPI flash
by Tony Dinh 06 Mar '23

06 Mar '23

Since the SPI flash chip mx25l3205d on this board has 4K-sector capability, enable it for the envs. Signed-off-by: Tony Dinh <mibodhi(a)gmail.com> --- configs/n2350_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/n2350_defconfig b/configs/n2350_defconfig index dcb2c96791..b85ef0dfeb 100644 --- a/configs/n2350_defconfig +++ b/configs/n2350_defconfig @@ -14,7 +14,7 @@ CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff0000 CONFIG_TARGET_N2350=y CONFIG_ENV_SIZE=0x10000 CONFIG_ENV_OFFSET=0x100000 -CONFIG_ENV_SECT_SIZE=0x10000 +CONFIG_ENV_SECT_SIZE=0x1000 CONFIG_DEFAULT_DEVICE_TREE="armada-385-thecus-n2350" CONFIG_SPL_TEXT_BASE=0x40000030 CONFIG_SYS_PROMPT="N2350 > " -- 2.30.2

2 2

[PATCH v2 0/4] FMP versioning support
by Masahisa Kojima 06 Mar '23

06 Mar '23

Firmware version management is not implemented in the current FMP implementation. This series aims to add the versioning support in FMP. EDK2 reference implementation utilizes the FMP Payload Header inserted right before the capsule payload. With this series, U-Boot also follows the EDK2 implementation. Currently, there is no way to know the current running firmware version through the EFI interface. FMP->GetImageInfo() returns always 0 for the version number. So a user can not know that expected firmware is running after the capsule update. With this series applied, version number can be specified in the capsule file generation with mkeficapsule tool, then user can know the running firmware version through FMP->GetImageInfo() and ESRT. Note that this series does not mandate the FMP Payload Header, compatible with boards that are already using the existing U-Boot FMP implementation. If no FMP Payload Header is found in the capsule file, fw_version, lowest supported version, last attempt version and last attempt status is set to 0 and this is the same behavior as existing FMP implementation. Changes in v2: - add FMP Payload Header generation in mkeficapsule tool Masahisa Kojima (4): efi_loader: store firmware version into FmpState variable efi_loader: versioning support in GetImageInfo efi_loader: check lowest supported version in capsule update mkeficapsule: add FMP Payload Header lib/efi_loader/efi_firmware.c | 271 ++++++++++++++++++++++++++++++---- tools/mkeficapsule.c | 81 +++++++++- 2 files changed, 319 insertions(+), 33 deletions(-) -- 2.17.1

2 18

[PATCH 0/4] arm: mvebu: clearfog: defconfig and eMMC updates
by Martin Rowe 06 Mar '23

06 Mar '23

Minor defconfig and eMMC updates for SolidRun's A388 Clearfog devices. Changes since initial discussion: https://lists.denx.de/pipermail/u-boot/2023-February/510492.html - CONFIG_SPL_SPI selected for SPI defconfig - Runtime patching of kernel FDT added for eMMC detection Note that this patch depends on this patch series (has been merged to u-boot-marvell/next): https://lists.denx.de/pipermail/u-boot/2023-March/511038.html Signed-off-by: Martin Rowe <martin.p.rowe(a)gmail.com> Martin Rowe (4): arm: mvebu: clearfog: Fix MMC detection arm: mvebu: clearfog: Align defconfigs arm: mvebu: clearfog: Add defconfig for SPI booting arm: mvebu: clearfog: Detect MMC vs SDHC and fixup fdt board/solidrun/clearfog/clearfog.c | 42 +++++++++++++++++++ configs/clearfog_defconfig | 5 ++- configs/clearfog_sata_defconfig | 12 ++++-- ...arfog_defconfig => clearfog_spi_defconfig} | 10 ++++- 4 files changed, 61 insertions(+), 8 deletions(-) copy configs/{clearfog_defconfig => clearfog_spi_defconfig} (91%) -- 2.39.2

2 12

[PATCH v3 0/4] J721E HS Fixes
by Manorit Chawdhry 06 Mar '23

06 Mar '23

This series fixes the support for J721E board along with some maintainance for it. v3: - drop fixes related to other boards ( make series j721e specific ) - memory map added in docs - applied reviewed-by v2: - Merge two series - Include some more commits that fix the gp builds when merging defconfigs - Update MAINTAINERS to remove hs related defconfigs - applied Acks Andrew Davis (1): arm: k3: config.mk: Add missing dependencies on tispl.bin HS Dave Gerlach (1): arm: mach-k3: Increase SYSFW max image size Manorit Chawdhry (2): configs: j721e: Merge the HS and non-HS defconfigs Kconfig: j721e: Change K3_MCU_SCRATCHPAD_BASE to non firewalled region MAINTAINERS | 2 - arch/arm/mach-k3/Kconfig | 6 +- arch/arm/mach-k3/config.mk | 2 + configs/j721e_evm_a72_defconfig | 3 +- configs/j721e_evm_r5_defconfig | 11 +- configs/j721e_hs_evm_a72_defconfig | 208 ----------------------------- configs/j721e_hs_evm_r5_defconfig | 176 ------------------------ doc/board/ti/j721e_evm.rst | 24 ++++ 8 files changed, 40 insertions(+), 392 deletions(-) delete mode 100644 configs/j721e_hs_evm_a72_defconfig delete mode 100644 configs/j721e_hs_evm_r5_defconfig -- 2.34.1

3 7

[PATCH 0/2] net: DHCPv6 protocol and commands
by seanedmond＠linux.microsoft.com 05 Mar '23

05 Mar '23

From: Sean Edmond <seanedmond(a)microsoft.com> The recently integrated IPv6 patch series relies on the link-local address, or a statically assigned IPv6 address for network operations. This patch series adds IPv6 address assignment through DHCPv6. The implementation meets the requirements in RFC 8415 for "Client/Server Exchanges Involving Four Messages": https://www.rfc-editor.org/rfc/rfc8415 The implementation sends/receives the minimum required DHCPv6 options to network boot. A new command (dhcp6) will execute the protocol. In addition, IPv6 functionality has been extended to the existing pxe commands ("pxe get" and "pxe boot"). Sean Edmond (2): net: dhcp6: Add DHCPv6 (DHCP for IPv6) net: dhcp6: pxe: Add DHCP/PXE commands for IPv6 boot/bootmeth_distro.c | 2 +- boot/bootmeth_pxe.c | 4 +- boot/pxe_utils.c | 3 +- cmd/Kconfig | 26 ++ cmd/net.c | 22 ++ cmd/pxe.c | 86 ++++- cmd/sysboot.c | 2 +- include/net.h | 10 +- include/net6.h | 2 - include/pxe_utils.h | 10 +- net/Makefile | 1 + net/dhcpv6.c | 741 +++++++++++++++++++++++++++++++++++++++++ net/dhcpv6.h | 212 ++++++++++++ net/net.c | 12 + 14 files changed, 1113 insertions(+), 20 deletions(-) create mode 100644 net/dhcpv6.c create mode 100644 net/dhcpv6.h -- 2.39.0

4 7

[PATCH 0/6] clk: uclass fixes and improvements
by Samuel Holland 04 Mar '23

04 Mar '23

This series fixes a few issues found while writing a clk driver for a new SoC (Bouffalo Lab BL808), and adds the new functionality needed to implement a hierarchy of clocks in a single device (without the CCF). The .get_parent hook will be useful on other platforms as well; I plan to use it to implement PLL rate setting on sunxi. Samuel Holland (6): clk: Handle error pointers in clk_valid() clk: Fix error handling in clk_get_rate() clk: Fix error handling in clk_get_parent() clk: Fix rate caching in clk_get_parent_rate() clk: Remove an unneeded check from clk_get_parent_rate() clk: Add a .get_parent operation drivers/clk/clk-uclass.c | 35 ++++++++++++++++------------------- include/clk-uclass.h | 2 ++ include/clk.h | 2 +- 3 files changed, 19 insertions(+), 20 deletions(-) -- 2.39.2

4 26

[PATCH] doc: Add documentation for CZ.NIC Turris routers
by Pali Rohár 04 Mar '23

04 Mar '23

This patch adds a new documentation for all released CZ.NIC Turris routers. Signed-off-by: Pali Rohár <pali(a)kernel.org> --- doc/board/CZ.NIC/index.rst | 9 + doc/board/CZ.NIC/turris.rst | 323 ++++++++++++++++++++++++++++++++++++ doc/board/index.rst | 1 + 3 files changed, 333 insertions(+) create mode 100644 doc/board/CZ.NIC/index.rst create mode 100644 doc/board/CZ.NIC/turris.rst diff --git a/doc/board/CZ.NIC/index.rst b/doc/board/CZ.NIC/index.rst new file mode 100644 index 000000000000..19ec6af2f389 --- /dev/null +++ b/doc/board/CZ.NIC/index.rst @@ -0,0 +1,9 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +CZ.NIC +====== + +.. toctree:: + :maxdepth: 2 + + turris diff --git a/doc/board/CZ.NIC/turris.rst b/doc/board/CZ.NIC/turris.rst new file mode 100644 index 000000000000..b82dea4e0786 --- /dev/null +++ b/doc/board/CZ.NIC/turris.rst @@ -0,0 +1,323 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +CZ.NIC Turris routers +===================== + +CZ.NIC develops open source Turris routers: Turris 1.0, Turris 1.1, Turris Omnia, and Turris Mox. This document describes a U-Boot deployment (compilation, flashing, resetting) on these routers. + +Turris 1.x +---------- + +Turris 1.0 and Turris 1.1 boards contain Freescale P2020 CPUs with two PowerPC e500v2 cores which BootROM (or CPU directly) can load and boot U-Boot bootloader from various locations. For Turris 1.x boards, only Flash NOR and SD cards are supported. P2020 CPU cannot download bootloader via UART like other platforms. For loading the U-Boot bootloader from Flash NOR (which is the default) it is needed to put SW1 dip switches on the board to position 11001010, and for the SD card to position 01101010 respectively. Note that this controls the source from which P2020 loads U-Boot, not from which U-Boot loads boot script or kernel. Boot procedures from SD card and Flash NOR are different, hence U-Boot binaries need to be compiled differently. + +More information about Turris 1.x, including the complete HW documentation (together with the SW1 dip switch options) and Altium design files, can be found on: https://docs.turris.cz/hw/turris-1x/turris-1x/ + +Compilation +^^^^^^^^^^^ + +To compile the Flash NOR version, run:: + + $ make CROSS_COMPILE=powerpc-linux-gnuspe- turris_1x_nor_defconfig + $ make CROSS_COMPILE=powerpc-linux-gnuspe- u-boot-with-dtb.bin + +It will produce a flashable binary file ``u-boot-with-dtb.bin``. + +To compile the SD card version, run:: + + $ make CROSS_COMPILE=powerpc-linux-gnuspe- turris_1x_sdcard_defconfig + $ make CROSS_COMPILE=powerpc-linux-gnuspe- u-boot-with-spl.bin + +It will produce a bootable binary file ``u-boot-with-spl.bin``. + +Flashing +^^^^^^^^ + +To flash the new U-Boot version into Flash NOR, load binary ``u-boot-with-dtb.bin`` (which must have exact size 0xc0000 bytes) to the ``$loadaddr`` address and run U-Boot commands:: + + => protect off 0xeff40000 +0xc0000 + => erase 0xeff40000 +0xc0000 + => cp.b $loadaddr 0xeff40000 0xc0000 + => protect on 0xeff40000 +0xc0000 + +To load the new U-Boot version to the SD card, just copy the ``u-boot-with-spl.bin`` binary image to sector 0 on the SD card. To preserve existing MBR partitions on the SD card, do not overwrite bytes 440-511 on sector 0. Do it for example via the ``dd`` command on Linux:: + + $ dd if=u-boot-with-spl.bin of=/dev/mmcblk0 bs=440 count=1 + $ dd if=u-boot-with-spl.bin of=/dev/mmcblk0 bs=512 skip=1 + +Boot source +^^^^^^^^^^^ + +By default P2020 CPU boots the U-Boot bootloader from the location configured by SW1 dip switches on Turris 1.x boards. But this configuration can be temporarily overridden by GPIOs (software configured) until the power supply is disconnected or the HW reset button is pressed. U-Boot environment provides commands ``run reboot_to_nor``, ``run reboot_to_sd`` and ``run reboot_to_def`` to force boot source location to Flash NOR, SD card, or default value (configured by SW1 dip switches) and initiate reboot (CPU reset). Overridden configuration is not lost after CPU reset. + +This can be useful to temporarily boot U-Boot from a different location (e.g. after flashing the new version) without the need to open the device and change the configuration of SW1 dip switches. + +Reset button +^^^^^^^^^^^^ + +When the HW reset button is pushed, then CPLD puts the main P2020 CPU into a reset state and the power led starts to blink in a one-second period. After 6 seconds, the power led stays powered on. After the HW reset button is released, CPLD releases the main P2020 CPU from the reset state and U-Boot starts booting on the main P2020 CPU. During startup, U-Boot sets the environment ``$turris_reset`` variable to the duration of the reset button being held in seconds, meaning the count of how many times the power led has blinked. The maximal value is therefore 6 seconds. + +If the HW reset button was held for 6 or more seconds then U-Boot sets ``$boot_targets`` to ``rescue`` which automatically starts booting the rescue system from Flash NOR, as defined in the ``$bootcmd_rescue`` variable. Note that U-Boot resets default values of these variables to ensure that booting into rescue mode would work correctly also when the custom U-Boot environment stored in permanent Flash NOR storage is damaged or overwritten. + +Environment variable ``$turris_reset`` can be used by boot scripts during the boot process for various purposes, like different boot modes. + +Turris Omnia +------------ + +Turris Omnia boards contain Marvell Armada 385 CPU with two ARM Cortex-A9 cores on which BootROM can load U-Boot bootloader from various locations. For Turris Omnia, only SPI NOR and UART are supported. The binary image is the same for both, SPI NOR and UART. For UART downloading and booting, a ``kwboot`` application is used (part of U-Boot). + +More information about Turris Omnia can be found on: https://docs.turris.cz/hw/omnia/omnia/ + +Compilation +^^^^^^^^^^^ + +To compile U-Boot for Turris Omnia, run:: + + $ make CROSS_COMPILE=arm-linux-gnueabi- turris_omnia_defconfig + $ make CROSS_COMPILE=arm-linux-gnueabi- u-boot-spl.kwb + +Flashing +^^^^^^^^ + +To flash the new U-Boot version into SPI NOR, load binary ``u-boot-spl.kwb`` to the ``$loadaddr`` address of size ``$filesize`` and run U-Boot commands:: + + => sf probe + => sf update $loadaddr 0x0 $filesize + +UART booting +^^^^^^^^^^^^ + +Run the ``kwboot`` command with the correct tty device:: + + $ ./tools/kwboot -b ./u-boot-spl.kwb -t /dev/ttyUSB0 + +After that, press the HW reset button on Omnia. ``kwboot`` should instruct Armada 385 CPU BootROM to enter into UART download mode, and transfer ``u-boot-spl.kwb`` binary over UART and boot it. + +Armada 385 UART supports speeds up to 5200000 bauds. With appropriate USB-UART converters which support higher speeds, it is possible to speed up transfer via the ``-B`` option. For example ``-B 5200000``. + +Reset button +^^^^^^^^^^^^ + +Like Turris 1.x boards, Turris Omnia has also a dedicated HW reset button. U-Boot during startup sets environment variable ``$omnia_reset`` to the reset mode selected by holding the reset button. + +If the HW reset button was held for about a second or more then U-Boot starts booting the rescue system from SPI NOR. Value from the ``$omnia_reset`` variable is put into the kernel command line, so the rescue system can choose different actions based on reset mode. + +mSATA slot configuration +^^^^^^^^^^^^^^^^^^^^^^^^ + +mSATA slot on Turris Omnia supports both SATA and PCIe modes. By default, it is in auto mode, which means that mode is detected based on the connected mSATA/mPCIe card's pin 43. mPCIe cards must have pin 43 connected to the ground and mSATA cards have this pin disconnected. There are some broken mPCIe cards that do not have grounded this pin and therefore autodetection does not work: the slot is switched to SATA mode and the mPCIe card does not work. + +To workaround this issue with buggy mPCIe cards in the mSATA slot, U-Boot provides a way to turn off autodetection and forces mode to PCIe (or also to SATA). U-Boot SPL during its init phase reads environment variable ``$omnia_msata_slot`` and when it is set to ``sata`` or ``pcie`` then it forces the specified slot mode. In all other cases, it configures mode based on the card's pin 43. + +To force mSATA slot mode to PCIe run commands:: + + => setenv omnia_msata_slot pcie + => saveenv + => reset + +To revert mSATA slot mode back to autodetect mode:: + + => setenv omnia_msata_slot + => saveenv + => reset + +WWAN slot configuration +^^^^^^^^^^^^^^^^^^^^^^^ + +WWAN mPCIe slot (that one with SIM slot) on Turris Omnia is compliant with PCIe Mini CEM 2.1 specification and supports both PCIe and USB 3.0 modes together with USB 2.0 mode. + +As defined in PCIe CEM 2.1 specification, PCIe and USB 3.0 functions share the same mPCIe slot pins (23, 25, 31, 33), and therefore only one of these two functions can be activated and configured at the same time. USB 2.0 function is on dedicated mPCIe slot pins. By default, the WWAN slot is in PCIe + USB 2.0 mode. U-Boot SPL during its init phase reads environment variable ``$omnia_wwan_slot`` and when it is set to ``usb3`` it changes the slot mode (slot pins 23, 25, 31, 33) to USB 3.0. + +To set WWAN slot mode to USB 3.0 run commands:: + + => setenv omnia_wwan_slot usb3 + => saveenv + => reset + +To revert WWAN slot back to PCIe + USB 2.0 mode:: + + => setenv omnia_wwan_slot + => saveenv + => reset + +Turris Mox +---------- + +Turris Mox is a modular router system. Its main Mox-A module contains Marvell Armada 3720 CPU with two 64-bit ARM Cortex-A53 cores and one 32-bit ARM Cortex-M3 on which BootROM can load U-Boot bootloader from various locations. Turris Mox supports only SPI NOR and UART. For UART downloading and booting a ``mox-imager`` application is used. The firmware itself consists of two parts: Secure firmware which runs on 32-bit ARM Cortex-M3 core and A53 firmware which is runs on 64-bit ARM Cortex-A53 cores. + +Application ``mox-imager`` is available at: https://gitlab.nic.cz/turris/mox-imager + +More information about Turris Mox can be found on: https://docs.turris.cz/hw/mox/intro/ + +Compilation +^^^^^^^^^^^ + +To compile U-Boot for Turris Mox, run on a Linux computer:: + + $ make CROSS_COMPILE=aarch64-linux-gnu- turris_mox_defconfig + $ make CROSS_COMPILE=aarch64-linux-gnu- u-boot.bin + +Note that standalone U-Boot cannot be flashed directly into SPI NOR. It can be replaced only as part of the whole A53 firmware which contains a concatenation of a Trusted-Firmware-A BL1 binary and a Trusted-Firmware-A FIT binary. Trusted-Firmware-A FIT binary contains Trusted-Firmware-A BL2 and BL3.1 binaries and also the U-Boot binary. + +To compile the final A53 firmware binary, compile the Trusted-Firmware-A project, specifying the path to the u-boot.bin binary in the ``BL33=`` option by commands:: + + $ make CROSS_COMPILE=aarch64-linux-gnu- PLAT=a3700 CM3_SYSTEM_RESET=1 USE_COHERENT_MEM=0 FIP_ALIGN=0x100 BL33=u-boot.bin mrvl_bootimage + $ cp -a build/a3700/release/boot-image.bin a53-firmware.bin + $ od -v -tu8 -An -j 131184 -N 8 a53-firmware.bin | LC_ALL=C awk '{ for (i = 0; i < 64; i += 8) printf "%c", and(rshift(1441792-131072-$$1, i), 255) }' | dd of=a53-firmware.bin bs=1 seek=131192 count=8 conv=notrunc 2>/dev/null + +It will produce a ``a53-firmware.bin`` binary. + +Trusted-Firmware-A project is available at: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/ + +Flashing +^^^^^^^^ + +To flash new A53 firmware binary (which contains also U-Boot) into SPI NOR, load binary ``a53-firmware.bin`` to the ``$loadaddr`` address of size ``$filesize`` and run U-Boot commands:: + + => sf probe + => sf update $loadaddr 0x20000 $filesize + +Secure firmware +^^^^^^^^^^^^^^^ + +Secure firmware is running on Armada 3720 ARM CM3 core, separated from main ARM A53 cores (on which U-Boot and Linux kernel are running). + +Due to security reasons, it is not possible to flash one's own version of Secure firmware because it is signed and Armada 3720 CPU checks that signature is done by CZ.NIC signing key. Armada 3720 CPU refuses to boot binary which is not signed by CZ.NIC private key. +Released signed binaries of Secure firmware can be downloaded from CZ.NIC releases webpage: https://gitlab.nic.cz/turris/mox-boot-builder/-/releases +Secure firmware is open source and all sources can be downloaded from CZ.NIC repository webpage: https://gitlab.nic.cz/turris/mox-boot-builder/-/tree/master/wtmi + +To flash a new Secure firmware binary (which is signed by the CZ.NIC key) into SPI NOR, load the ``secure-firmware.bin`` binary to the ``$loadaddr`` address of the ``$filesize`` size and run U-Boot commands:: + + => sf probe + => sf update $loadaddr 0x0 $filesize + +UART booting +^^^^^^^^^^^^ + +Run command ``mox-imager`` with correct tty device:: + + $ mox-imager -D /dev/ttyUSB0 -E -t secure-firmware-uart.bin a53-firmware.bin + +And plug the power supply. If it fails, unplug the power supply and plug it in again. + +Armada 3720 UART supports speeds up to 6000000 bauds. With appropriate USB-UART converters which support higher speeds, it is possible to speed up transfer via the ``-b`` option. For example ``-b 6000000``. + +Rescue mode +----------- + +On All Turris boards, it is possible to boot the rescue system from U-Boot just by calling ``run bootcmd_rescue``. It is the same as pressing the HW reset button for a longer time. + +OTP (One Time Programming) +-------------------------- + +Every Turris board contains some OTP storage that is burned during factory programming and which cannot be later modified or erased. It contains information for device identification: the serial number, mac addresses, etc. + +Every Turris 1.0, 1.1, and Omnia board has allocated 3 MAC addresses from CZ.NIC OUI (D8:58:D7) and every Turris Mox board have allocated 2 MAC addresses from CZ.NIC OUI (D8:58:D7). But only the first address is stored in OTP, other MAC addresses can be calculated by numeric `plus one` and `plus two` operations. + +Atsha 204/204a OTP content +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +All Turris 1.0, Turris 1.1 and Turris Omnia boards store into Atsha 204/204a cryptochip OTP area at 32-bit words 0x00-0x03 following data:: + + word 0x00 - first half of 64-bit device serial number + [07:00] - first byte of hw-rev/version (MSB) + [15:08] - second byte of hw-rev/version + [23:16] - third byte of hw-rev/version + [31:24] - fourth byte of hw-rev/version (LSB) + + word 0x01 - second half of 64-bit device serial number + [07:00] - first byte of serial (MSB) + [15:08] - second byte of serial + [23:16] - third byte of serial + [31:24] - fourth byte of serial (LSB) + + word 0x02 - first half of 48-bit first MAC address with CZ.NIC OUI (D8:58:D7) + [07:00] - reserved (zero) + [15:08] - first byte - 0xD8 + [23:16] - second byte - 0x58 + [31:24] - third byte - 0xD7 + + word 0x03 - second half of 48-bit first MAC address + [07:00] - reserved (zero) + [15:08] - fourth byte + [23:16] - fifth byte + [31:24] - sixth byte + +Words 0x00 and 0x01 contain 64-bit device serial numbers in a big-endian format, and words 0x02 and 0x03 contain 48-bit first MAC addresses with CZ.NIC OUI (D8:58:D7) in a big-endian format. + +Armada 385 LD1 eFuse content +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Turris Omnia boards of revision 32 or higher store into 256-bit long Armada 385 LD1 eFuse OTP following data:: + + [047:000] - 48-bit first MAC address with CZ.NIC OUI (D8:58:D7) in big endian + [007:000] - first byte - 0xD8 + [015:008] - second byte - 0x58 + [023:016] - third byte - 0xD7 + [031:024] - fourth byte + [039:032] - fifth byte + [047:040] - sixth byte + [055:048] - board version + [063:056] - reserved (zeros) + [127:064] - 64-bit device serial number in big endian + [071:064] - first byte of hw-rev/version (MSB) + [079:072] - second byte of hw-rev/version + [087:080] - third byte of hw-rev/version + [095:088] - fourth byte of hw-rev/version (LSB) + [103:096] - first byte of serial (MSB) + [111:104] - second byte of serial + [119:112] - third byte of serial + [127:120] - fourth byte of serial (LSB) + [255:128] - reserved (zeros) + [256] - lock bit (1 - if above data are valid) + +Armada 385 LD1 eFuse is mapped to U-Boot fuse bank number 65. + +Read serial number:: + + => fuse read 65 2 1 + +Armada 3720 Secure OTP content +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +All Turris Mox boards store into Armada 3720 Secure OTP 64-bit rows 42 and 43 following data:: + + row 42 + [47:00] - 48-bit first MAC address with CZ.NIC OUI (D8:58:D7) in little endian + [07:00] - sixth byte + [15:08] - fifth byte + [23:16] - fourth byte + [31:24] - third byte - 0xD7 + [39:32] - second byte - 0x58 + [47:40] - first byte - 0xD8 + [53:48] - board version + [55:54] - board type + 0b00 - CZ.NIC Turris Mox + 0b01 - reserved (unassigned) + 0b10 - RIPE Atlas Probe + 0b11 - reserved (unassigned) + [57:56] - RAM size + 0b00 - 512M + 0b01 - 1024M + 0b10 - 2048M + 0b11 - 4096M + [63:58] - reserved (zeros) + [64] - lock bit (1 - if above data are valid) + + row 43 + [63:00] - 64-bit device serial number in big endian with swapped 32-bit words + [07:00] - first byte of serial (MSB) + [15:08] - second byte of serial + [23:16] - third byte of serial + [31:24] - fourth byte of serial (LSB) + [39:32] - first byte of hw-rev/version (MSB) + [47:40] - second byte of hw-rev/version + [55:48] - third byte of hw-rev/version + [63:56] - fourth byte of hw-rev/version (LSB) + [64] - lock bit (1 - if above data are valid) + +Armada 3720 Secure OTP rows are mapped 1:1 to U-Boot fuse bank numbers. + +Read serial number:: + + => fuse read 43 1 + => fuse read 43 0 diff --git a/doc/board/index.rst b/doc/board/index.rst index 53edd5301f25..90467a6bd944 100644 --- a/doc/board/index.rst +++ b/doc/board/index.rst @@ -18,6 +18,7 @@ Board-specific doc bsh/index congatec/index coreboot/index + CZ.NIC/index emulation/index google/index highbank/index -- 2.20.1

4 8

[PATCH 01/13] common/Kconfig: Reword text for BOARD_TYPES
by Tom Rini 04 Mar '23

04 Mar '23

While it is true that for some Samsung platforms, we call get_board_type() the main usage of this CONFIG switch is to enable board_types in global data, which is then used by various platforms. Signed-off-by: Tom Rini <trini(a)konsulko.com> --- common/Kconfig | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/common/Kconfig b/common/Kconfig index e3a5e1be1e95..86d6679d05b5 100644 --- a/common/Kconfig +++ b/common/Kconfig @@ -551,12 +551,11 @@ endmenu menu "Init options" config BOARD_TYPES - bool "Call get_board_type() to get and display the board type" + bool "Enable board_type entry in global data struct" help - If this option is enabled, checkboard() will call get_board_type() - to get a string containing the board type and this will be - displayed immediately after the model is shown on the console - early in boot. + If this option is enabled, a field will be added to the global + data struct to store an unsigned long value for the type of + platform that we have determined we are on, at run-time. config DISPLAY_CPUINFO bool "Display information about the CPU during start up" -- 2.34.1

11 51

[PULL] u-boot-usb/next
by Marek Vasut 04 Mar '23

04 Mar '23

The following changes since commit 49cba67852f1fb5ef481bef3532b2cda96816e45: Merge branch 'next' of https://source.denx.de/u-boot/custodians/u-boot-marvell into next (2023-03-01 11:00:22 -0500) are available in the Git repository at: git://source.denx.de/u-boot-usb.git next for you to fetch changes up to ea436dbc40e01a6c483c41d7ec1e4a419fc6b7c0: dt-bindings: usb: mtk-xhci: add support mt8195 (2023-03-02 22:43:44 +0100) ---------------------------------------------------------------- Chunfeng Yun (5): phy: phy-mtk-tphy: remove macros to prepare bitfield value phy: phy-mtk-tphy: add support mt8195 usb: xhci-mtk: modify the SOF/ITP interval for mt8195 dt-bindings: phy-mtk-tphy: add support mt8195 dt-bindings: usb: mtk-xhci: add support mt8195 Marek Vasut (1): usb: dwc3-meson-g12a: Select PHY instead of imply PHY doc/device-tree-bindings/phy/phy-mtk-tphy.txt | 1 + doc/device-tree-bindings/usb/mediatek,mtk-xhci.txt | 4 +- drivers/phy/phy-mtk-tphy.c | 213 +++++++++++++++++++++++++++++++++++++++++++++++++--------------------------------- drivers/usb/dwc3/Kconfig | 4 +- drivers/usb/host/xhci-mtk.c | 49 ++++++++++++++++++- 5 files changed, 182 insertions(+), 89 deletions(-)

2 1

[PATCH v3 03/17] dt-bindings: reset: Add StarFive JH7110 reset definitions
by Yanhong Wang 03 Mar '23

03 Mar '23

Add resets for the StarFive JH7110 system(SYS),system-top-group(STG) and always-on(AON) reset controller. Signed-off-by: Yanhong Wang <yanhong.wang(a)starfivetech.com> --- .../dt-bindings/reset/starfive,jh7110-crg.h | 183 ++++++++++++++++++ 1 file changed, 183 insertions(+) create mode 100644 include/dt-bindings/reset/starfive,jh7110-crg.h diff --git a/include/dt-bindings/reset/starfive,jh7110-crg.h b/include/dt-bindings/reset/starfive,jh7110-crg.h new file mode 100644 index 0000000000..1d596581da --- /dev/null +++ b/include/dt-bindings/reset/starfive,jh7110-crg.h @@ -0,0 +1,183 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * Copyright (C) 2022 StarFive Technology Co., Ltd. + * + * Author: Yanhong Wang <yanhong.wang(a)starfivetech.com> + */ + +#ifndef __DT_BINDINGS_RESET_STARFIVE_JH7110_H__ +#define __DT_BINDINGS_RESET_STARFIVE_JH7110_H__ + +/* SYSCRG resets */ +#define JH7110_SYSRST_JTAG2APB 0 +#define JH7110_SYSRST_SYSCON 1 +#define JH7110_SYSRST_IOMUX_APB 2 +#define JH7110_SYSRST_BUS 3 +#define JH7110_SYSRST_DEBUG 4 +#define JH7110_SYSRST_CORE0 5 +#define JH7110_SYSRST_CORE1 6 +#define JH7110_SYSRST_CORE2 7 +#define JH7110_SYSRST_CORE3 8 +#define JH7110_SYSRST_CORE4 9 +#define JH7110_SYSRST_CORE0_ST 10 +#define JH7110_SYSRST_CORE1_ST 11 +#define JH7110_SYSRST_CORE2_ST 12 +#define JH7110_SYSRST_CORE3_ST 13 +#define JH7110_SYSRST_CORE4_ST 14 +#define JH7110_SYSRST_TRACE0 15 +#define JH7110_SYSRST_TRACE1 16 +#define JH7110_SYSRST_TRACE2 17 +#define JH7110_SYSRST_TRACE3 18 +#define JH7110_SYSRST_TRACE4 19 +#define JH7110_SYSRST_TRACE_COM 20 +#define JH7110_SYSRST_GPU_APB 21 +#define JH7110_SYSRST_GPU_DOMA 22 +#define JH7110_SYSRST_NOC_BUS_APB_BUS 23 +#define JH7110_SYSRST_NOC_BUS_AXICFG0_AXI 24 +#define JH7110_SYSRST_NOC_BUS_CPU_AXI 25 +#define JH7110_SYSRST_NOC_BUS_DISP_AXI 26 +#define JH7110_SYSRST_NOC_BUS_GPU_AXI 27 +#define JH7110_SYSRST_NOC_BUS_ISP_AXI 28 +#define JH7110_SYSRST_NOC_BUS_DDRC 29 +#define JH7110_SYSRST_NOC_BUS_STG_AXI 30 +#define JH7110_SYSRST_NOC_BUS_VDEC_AXI 31 + +#define JH7110_SYSRST_NOC_BUS_VENC_AXI 32 +#define JH7110_SYSRST_AXI_CFG1_DEC_AHB 33 +#define JH7110_SYSRST_AXI_CFG1_DEC_MAIN 34 +#define JH7110_SYSRST_AXI_CFG0_DEC_MAIN 35 +#define JH7110_SYSRST_AXI_CFG0_DEC_MAIN_DIV 36 +#define JH7110_SYSRST_AXI_CFG0_DEC_HIFI4 37 +#define JH7110_SYSRST_DDR_AXI 38 +#define JH7110_SYSRST_DDR_OSC 39 +#define JH7110_SYSRST_DDR_APB 40 +#define JH7110_SYSRST_DOM_ISP_TOP_N 41 +#define JH7110_SYSRST_DOM_ISP_TOP_AXI 42 +#define JH7110_SYSRST_DOM_VOUT_TOP_SRC 43 +#define JH7110_SYSRST_CODAJ12_AXI 44 +#define JH7110_SYSRST_CODAJ12_CORE 45 +#define JH7110_SYSRST_CODAJ12_APB 46 +#define JH7110_SYSRST_WAVE511_AXI 47 +#define JH7110_SYSRST_WAVE511_BPU 48 +#define JH7110_SYSRST_WAVE511_VCE 49 +#define JH7110_SYSRST_WAVE511_APB 50 +#define JH7110_SYSRST_VDEC_JPG_ARB_JPG 51 +#define JH7110_SYSRST_VDEC_JPG_ARB_MAIN 52 +#define JH7110_SYSRST_AXIMEM0_AXI 53 +#define JH7110_SYSRST_WAVE420L_AXI 54 +#define JH7110_SYSRST_WAVE420L_BPU 55 +#define JH7110_SYSRST_WAVE420L_VCE 56 +#define JH7110_SYSRST_WAVE420L_APB 57 +#define JH7110_SYSRST_AXIMEM1_AXI 58 +#define JH7110_SYSRST_AXIMEM2_AXI 59 +#define JH7110_SYSRST_INTMEM 60 +#define JH7110_SYSRST_QSPI_AHB 61 +#define JH7110_SYSRST_QSPI_APB 62 +#define JH7110_SYSRST_QSPI_REF 63 + +#define JH7110_SYSRST_SDIO0_AHB 64 +#define JH7110_SYSRST_SDIO1_AHB 65 +#define JH7110_SYSRST_GMAC1_AXI 66 +#define JH7110_SYSRST_GMAC1_AHB 67 +#define JH7110_SYSRST_MAILBOX 68 +#define JH7110_SYSRST_SPI0_APB 69 +#define JH7110_SYSRST_SPI1_APB 70 +#define JH7110_SYSRST_SPI2_APB 71 +#define JH7110_SYSRST_SPI3_APB 72 +#define JH7110_SYSRST_SPI4_APB 73 +#define JH7110_SYSRST_SPI5_APB 74 +#define JH7110_SYSRST_SPI6_APB 75 +#define JH7110_SYSRST_I2C0_APB 76 +#define JH7110_SYSRST_I2C1_APB 77 +#define JH7110_SYSRST_I2C2_APB 78 +#define JH7110_SYSRST_I2C3_APB 79 +#define JH7110_SYSRST_I2C4_APB 80 +#define JH7110_SYSRST_I2C5_APB 81 +#define JH7110_SYSRST_I2C6_APB 82 +#define JH7110_SYSRST_UART0_APB 83 +#define JH7110_SYSRST_UART0_CORE 84 +#define JH7110_SYSRST_UART1_APB 85 +#define JH7110_SYSRST_UART1_CORE 86 +#define JH7110_SYSRST_UART2_APB 87 +#define JH7110_SYSRST_UART2_CORE 88 +#define JH7110_SYSRST_UART3_APB 89 +#define JH7110_SYSRST_UART3_CORE 90 +#define JH7110_SYSRST_UART4_APB 91 +#define JH7110_SYSRST_UART4_CORE 92 +#define JH7110_SYSRST_UART5_APB 93 +#define JH7110_SYSRST_UART5_CORE 94 +#define JH7110_SYSRST_SPDIF_APB 95 + +#define JH7110_SYSRST_PWMDAC_APB 96 +#define JH7110_SYSRST_PDM_DMIC 97 +#define JH7110_SYSRST_PDM_APB 98 +#define JH7110_SYSRST_I2SRX_APB 99 +#define JH7110_SYSRST_I2SRX_BCLK 100 +#define JH7110_SYSRST_I2STX0_APB 101 +#define JH7110_SYSRST_I2STX0_BCLK 102 +#define JH7110_SYSRST_I2STX1_APB 103 +#define JH7110_SYSRST_I2STX1_BCLK 104 +#define JH7110_SYSRST_TDM_AHB 105 +#define JH7110_SYSRST_TDM_CORE 106 +#define JH7110_SYSRST_TDM_APB 107 +#define JH7110_SYSRST_PWM_APB 108 +#define JH7110_SYSRST_WDT_APB 109 +#define JH7110_SYSRST_WDT_CORE 110 +#define JH7110_SYSRST_CAN0_APB 111 +#define JH7110_SYSRST_CAN0_CORE 112 +#define JH7110_SYSRST_CAN0_TIMER 113 +#define JH7110_SYSRST_CAN1_APB 114 +#define JH7110_SYSRST_CAN1_CORE 115 +#define JH7110_SYSRST_CAN1_TIMER 116 +#define JH7110_SYSRST_TIMER_APB 117 +#define JH7110_SYSRST_TIMER0 118 +#define JH7110_SYSRST_TIMER1 119 +#define JH7110_SYSRST_TIMER2 120 +#define JH7110_SYSRST_TIMER3 121 +#define JH7110_SYSRST_INT_CTRL_APB 122 +#define JH7110_SYSRST_TEMP_APB 123 +#define JH7110_SYSRST_TEMP_CORE 124 +#define JH7110_SYSRST_JTAG_CERTIFICATION 125 + +#define JH7110_SYSRST_END 126 + +/* AONCRG resets */ +#define JH7110_AONRST_GMAC0_AXI 0 +#define JH7110_AONRST_GMAC0_AHB 1 +#define JH7110_AONRST_IOMUX 2 +#define JH7110_AONRST_PMU_APB 3 +#define JH7110_AONRST_PMU_WKUP 4 +#define JH7110_AONRST_RTC_APB 5 +#define JH7110_AONRST_RTC_CAL 6 +#define JH7110_AONRST_RTC_32K 7 + +#define JH7110_AONRST_END 8 + +/* STGCRG resets */ +#define JH7110_STGRST_SYSCON_PRESETN 0 +#define JH7110_STGRST_HIFI4_CORE 1 +#define JH7110_STGRST_HIFI4_AXI 2 +#define JH7110_STGRST_SEC_TOP_HRESETN 3 +#define JH7110_STGRST_E24_CORE 4 +#define JH7110_STGRST_DMA1P_AXI 5 +#define JH7110_STGRST_DMA1P_AHB 6 +#define JH7110_STGRST_USB_AXI 7 +#define JH7110_STGRST_USB_APB 8 +#define JH7110_STGRST_USB_UTMI_APB 9 +#define JH7110_STGRST_USB_PWRUP 10 +#define JH7110_STGRST_PCIE0_MST0 11 +#define JH7110_STGRST_PCIE0_SLV0 12 +#define JH7110_STGRST_PCIE0_SLV 13 +#define JH7110_STGRST_PCIE0_BRG 14 +#define JH7110_STGRST_PCIE0_CORE 15 +#define JH7110_STGRST_PCIE0_APB 16 +#define JH7110_STGRST_PCIE1_MST0 17 +#define JH7110_STGRST_PCIE1_SLV0 18 +#define JH7110_STGRST_PCIE1_SLV 19 +#define JH7110_STGRST_PCIE1_BRG 20 +#define JH7110_STGRST_PCIE1_CORE 21 +#define JH7110_STGRST_PCIE1_APB 22 + +#define JH7110_STGRST_END 23 + +#endif /* __DT_BINDINGS_RESET_STARFIVE_JH7110_H__ */ -- 2.17.1

2 1