September 2022 - U-Boot

[PATCH] pci: Handle failed calloc in decode_regions()
by Pierre-Clément Tosi 22 Mar '23

22 Mar '23

Add a check for calloc() failing to allocate the requested memory. Make decode_regions() return an error code. Cc: Bin Meng <bmeng.cn(a)gmail.com> Cc: Simon Glass <sjg(a)chromium.org> Cc: Stefan Roese <sr(a)denx.de> Signed-off-by: Pierre-Clément Tosi <ptosi(a)google.com> --- drivers/pci/pci-uclass.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c index 970ee1adf1..2c85e78a13 100644 --- a/drivers/pci/pci-uclass.c +++ b/drivers/pci/pci-uclass.c @@ -954,7 +954,7 @@ int pci_bind_bus_devices(struct udevice *bus) return 0; } -static void decode_regions(struct pci_controller *hose, ofnode parent_node, +static int decode_regions(struct pci_controller *hose, ofnode parent_node, ofnode node) { int pci_addr_cells, addr_cells, size_cells; @@ -968,7 +968,7 @@ static void decode_regions(struct pci_controller *hose, ofnode parent_node, prop = ofnode_get_property(node, "ranges", &len); if (!prop) { debug("%s: Cannot decode regions\n", __func__); - return; + return -EINVAL; } pci_addr_cells = ofnode_read_simple_addr_cells(node); @@ -986,6 +986,8 @@ static void decode_regions(struct pci_controller *hose, ofnode parent_node, max_regions = len / cells_per_record + CONFIG_NR_DRAM_BANKS; hose->regions = (struct pci_region *) calloc(1, max_regions * sizeof(struct pci_region)); + if (!hose->regions) + return -ENOMEM; for (i = 0; i < max_regions; i++, len -= cells_per_record) { u64 pci_addr, addr, size; @@ -1053,7 +1055,7 @@ static void decode_regions(struct pci_controller *hose, ofnode parent_node, /* Add a region for our local memory */ bd = gd->bd; if (!bd) - return; + return 0; for (i = 0; i < CONFIG_NR_DRAM_BANKS; ++i) { if (bd->bi_dram[i].size) { @@ -1068,7 +1070,7 @@ static void decode_regions(struct pci_controller *hose, ofnode parent_node, } } - return; + return 0; } static int pci_uclass_pre_probe(struct udevice *bus) @@ -1097,7 +1099,10 @@ static int pci_uclass_pre_probe(struct udevice *bus) /* For bridges, use the top-level PCI controller */ if (!device_is_on_pci_bus(bus)) { hose->ctlr = bus; - decode_regions(hose, dev_ofnode(bus->parent), dev_ofnode(bus)); + ret = decode_regions(hose, dev_ofnode(bus->parent), + dev_ofnode(bus)); + if (ret) + return ret; } else { struct pci_controller *parent_hose; -- 2.36.1.124.g0e6072fb45-goog

5 7

kwboot: Marvell Dove UART booting
by Tony Dinh 20 Mar '23

20 Mar '23

Hi all, With great help from Pali, I've made some good progress on kwboot the HP Thin Client T5335z (Marvell Dove SoC) board. I had been unsuccessful running kwboot with this box until Pali pointed out a few important aspects of the Dove SoC, and how the BootROM commands work (my apology for forgetting to include the u-boot-mailing list and Marek on previous email exchanges). Here is the summary of the attempt to kwboot. HP Thin Client T5335z Marvell Dove SoC 88AP510 (A1) 1Ghz CPU 1 GB RAM - Reset Strapping: As with all Dove SoCs, there is no preamble when we send the u-boot image over the serial line. IOW, no magic handshake string to tell the BootROM that we are booting over UART. Instead, the hardware must explicitly set to UART mode booting. For boards like the Solidrun Cubox, there is a button, and some other board, a DIP switch, to enable this mode. For the T55335z, there is no button or DIP switch on the board for that purpose. Instead, there is a jumper (the exact purpose is unknown), but I found that this jumper will put the BootROM into debug mode. And from the BootROM debug prompt, we can execute a command to set the boot mode to UART with "x command. Here is the log and my commentary starting with *** <Begin log> *** With jumper inserted, serial console connected, start serial console # picocom --b 115200 --f n --p n --d 8 /dev/ttyUSB0 Terminal ready *** Hit <Enter> here to get to the prompt and execute "x 0x0E" Bootstrap 2.33> Bootstrap 2.33>x 0x0E *** No more input possible here, so Control-A-X to exit serial console Terminating... Thanks for using picocom *** Run kwboot # kwboot -t -p -B 115200 /dev/ttyUSB0 -D /localdisk/mtd0.t5335z Patching image boot signature to UART Aligning image header to Xmodem block size Waiting 2s and flushing tty Sending boot image header (512 bytes)... 25 % [.... ] Done Sending boot image data (607664 bytes)... 0 % [......................................................................] 1 % [......................................................................] 2 % [......................................................................] <snip> 95 % [......................................................................] 97 % [......................................................................] 98 % [.......................................................... ] Done Finishing transfer [Type Ctrl-\ + c to quit] *** Hung here! BootROM did not execute the image payload. *** *** The file mtd0.t5335z is a dd dump from the SPI flash mtd0 with *** this command: *** # dd if=/dev/mtd0 of=mtd0.t5335z bs=768k conv=sync <End log> - Pali's observation: It looks like Dove uses kwbimage v0 format with extensions, at least according to Function Spec. See 'Binary Code Extension' and 'Header Extension'. Currently kwboot and kwbimage supports v0 image only with one extension. - My comments in response: Indeed. I've seen that in the Functional Spec, too. The mdt0 binwalk also shows what looks like the extension header. DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 118161 0x1CD91 Certificate in DER format (x509 v3), header length: 4, sequence length: 3 199169 0x30A01 Certificate in DER format (x509 v3), header length: 4, sequence length: 5464 380652 0x5CEEC CRC32 polynomial table, little endian 387072 0x5E800 CRC32 polynomial table, little endian 608166 0x947A6 LZMA compressed data, properties: 0x66, dictionary size: 0 bytes, uncompressed size: 147351982848 bytes Thanks, Tony

3 29

[PATCH] board_r: Relocate OF_EMBED if NEEDS_MANUAL_RELOC only
by Pierre-Clément Tosi 16 Mar '23

16 Mar '23

When the embedded device tree is pointed to by the __dtb_dt_*begin symbols, it seems to be covered by the early relocation code and doesn't need to be manually patched. Cc: Simon Glass <sjg(a)chromium.org> Signed-off-by: Pierre-Clément Tosi <ptosi(a)google.com> --- common/board_r.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/common/board_r.c b/common/board_r.c index 56eb60fa27..00926dcb1e 100644 --- a/common/board_r.c +++ b/common/board_r.c @@ -150,13 +150,13 @@ static int initr_reloc_global_data(void) */ gd->env_addr += gd->reloc_off; #endif -#ifdef CONFIG_OF_EMBED /* * The fdt_blob needs to be moved to new relocation address * incase of FDT blob is embedded with in image */ - gd->fdt_blob += gd->reloc_off; -#endif + if (CONFIG_IS_ENABLED(OF_EMBED) && CONFIG_IS_ENABLED(NEEDS_MANUAL_RELOC)) + gd->fdt_blob += gd->reloc_off; + #ifdef CONFIG_EFI_LOADER /* * On the ARM architecture gd is mapped to a fixed register (r9 or x18). -- 2.37.2.789.g6183377224-goog

4 5

[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 00/17] patman: Convert camel case
by Simon Glass 01 Mar '23

01 Mar '23

Much of the Python code in U-Boot was written using the Chromium OS Python style. This series converts the patman class methods and functions from camel case to snake case. This fits with PEP8 and is one step along the way to making the code more compliant with that. Simon Glass (17): patman: Convert camel case in tools.py patman: Convert camel case in command.py patman: Convert camel case in checkpatch.py patman: Convert camel case in commit.py patman: Convert camel case in cros_subprocess.py patman: Convert camel case in func_test.py patman: Convert camel case in get_maintainer.py patman: Convert camel case in gitutil.py patman: Convert camel case in project.py patman: Convert camel case in test_checkpatch.py patman: Convert camel case in test_util.py patman: Convert camel case in tout.py patman: Rename Print() to Tprint() patman: Rename Color() method to build() patman: Convert camel case in terminal.py patman: Update with new pylint scores RFC: tools: Add a camel-case conversion script scripts/pylint.base | 26 +- scripts/style.py | 180 +++++++++++ tools/binman/bintool.py | 30 +- tools/binman/bintool_test.py | 34 +- tools/binman/btool/lz4.py | 8 +- tools/binman/btool/lzma_alone.py | 16 +- tools/binman/cbfs_util.py | 12 +- tools/binman/cbfs_util_test.py | 20 +- tools/binman/control.py | 74 ++--- tools/binman/elf.py | 20 +- tools/binman/elf_test.py | 20 +- tools/binman/entry.py | 42 +-- tools/binman/entry_test.py | 4 +- tools/binman/etype/atf_fip.py | 2 +- tools/binman/etype/blob.py | 4 +- tools/binman/etype/blob_ext_list.py | 2 +- tools/binman/etype/fdtmap.py | 2 +- tools/binman/etype/files.py | 2 +- tools/binman/etype/fill.py | 2 +- tools/binman/etype/fit.py | 20 +- tools/binman/etype/fmap.py | 6 +- tools/binman/etype/gbb.py | 10 +- tools/binman/etype/intel_ifwi.py | 12 +- tools/binman/etype/mkimage.py | 8 +- tools/binman/etype/section.py | 26 +- tools/binman/etype/text.py | 4 +- tools/binman/etype/u_boot_elf.py | 6 +- tools/binman/etype/u_boot_env.py | 4 +- tools/binman/etype/u_boot_spl_bss_pad.py | 4 +- tools/binman/etype/u_boot_spl_expanded.py | 2 +- tools/binman/etype/u_boot_tpl_bss_pad.py | 4 +- tools/binman/etype/u_boot_tpl_expanded.py | 2 +- tools/binman/etype/u_boot_ucode.py | 4 +- tools/binman/etype/u_boot_with_ucode_ptr.py | 2 +- tools/binman/etype/vblock.py | 10 +- tools/binman/fdt_test.py | 4 +- tools/binman/fip_util.py | 16 +- tools/binman/fip_util_test.py | 36 +-- tools/binman/fmap_util.py | 2 +- tools/binman/ftest.py | 324 ++++++++++---------- tools/binman/image.py | 16 +- tools/binman/main.py | 6 +- tools/binman/state.py | 34 +- tools/buildman/builder.py | 108 +++---- tools/buildman/builderthread.py | 12 +- tools/buildman/control.py | 46 +-- tools/buildman/func_test.py | 20 +- tools/buildman/test.py | 30 +- tools/buildman/toolchain.py | 26 +- tools/dtoc/fdt.py | 4 +- tools/dtoc/fdt_util.py | 12 +- tools/dtoc/main.py | 6 +- tools/dtoc/test_dtoc.py | 76 ++--- tools/dtoc/test_fdt.py | 34 +- tools/dtoc/test_src_scan.py | 12 +- tools/patman/checkpatch.py | 36 +-- tools/patman/command.py | 30 +- tools/patman/commit.py | 10 +- tools/patman/control.py | 20 +- tools/patman/cros_subprocess.py | 59 ++-- tools/patman/func_test.py | 74 ++--- tools/patman/get_maintainer.py | 8 +- tools/patman/gitutil.py | 176 +++++------ tools/patman/main.py | 8 +- tools/patman/patchstream.py | 12 +- tools/patman/project.py | 4 +- tools/patman/series.py | 32 +- tools/patman/settings.py | 4 +- tools/patman/status.py | 22 +- tools/patman/terminal.py | 56 ++-- tools/patman/test_checkpatch.py | 80 ++--- tools/patman/test_util.py | 8 +- tools/patman/tools.py | 86 +++--- tools/patman/tout.py | 58 ++-- tools/rmboard.py | 16 +- 75 files changed, 1214 insertions(+), 1033 deletions(-) create mode 100755 scripts/style.py -- 2.35.0.rc2.247.g8bbb082509-goog

1 34

[PATCH v1 00/11] rockchip fixes and extend rk3568 support
by Peter Geis 27 Feb '23

27 Feb '23

to: Simon Glass <sjg(a)chromium.org> to: Philipp Tomsich <philipp.tomsich(a)vrull.eu> to: Kever Yang <kever.yang(a)rock-chips.com> to: Lukasz Majewski <lukma(a)denx.de> to: Sean Anderson <seanga2(a)gmail.com> to: Peng Fan <peng.fan(a)nxp.com> to: Jaehoon Chung <jh80.chung(a)samsung.com> to: Heiko Stübner <heiko(a)sntech.de> cc: u-boot(a)lists.denx.de Good Evening, The following is a few patches for rockchip mainline u-boot support. Patches 1-3 are fixes for the rk3568 reset handler, rockchip emmc dma to sram, and building the rockchip-sfc driver. Patch 4 adds a sanity check for the minimum sfc frequency. Patch 5 and 6 add adc support to spl and enable the rockchip recovery handler in spl, before attempting to load u-boot. Patch 7 enables rk3568 spl bootrom device detection. Patch 8 enables automatic clock gating and other power saving features on rk3568, which solves the chip running hotter compared to downstream. Patch 9 and 10 move the dwc3 platform data to the chip specific code and enable dwc3 otg support on rk3568. Patch 11 is an RFC patch for fixing ram detection on rk3568. Downstream goes about this a different way, where they implemented a special library to handle this. Please review and *especially test* patch 11. Very Respectfully, Peter Geis Peter Geis (11): clk: rockchip: rk3568: fix reset handler mmc: sdhci: allow disabling sdma in spl spi: rockchip-sfc: fix building rockchip-sfc spi: rockchip-sfc: sanity check minimum freq spl: support adc drivers in spl rockchip: handle bootrom recovery mode in spl rockchip: rk3568: add boot device detection rockchip: rk3568: enable automatic clock gating rockchip: move dwc3 config to chip specific handler rockchip: rk3568: add dwc3 otg support [RFC] rockchip: rk356x: attempt to fix ram detection arch/arm/mach-rockchip/Kconfig | 1 + arch/arm/mach-rockchip/Makefile | 6 +- arch/arm/mach-rockchip/board.c | 24 ------ arch/arm/mach-rockchip/boot_mode.c | 4 +- arch/arm/mach-rockchip/rk3399/rk3399.c | 29 +++++++ arch/arm/mach-rockchip/rk3568/rk3568.c | 112 +++++++++++++++++++++++++ arch/arm/mach-rockchip/sdram.c | 19 +++-- common/board_f.c | 7 ++ common/spl/Kconfig | 5 ++ drivers/Makefile | 1 + drivers/clk/rockchip/clk_rk3568.c | 2 + drivers/mmc/Kconfig | 7 ++ drivers/mmc/sdhci.c | 6 +- drivers/spi/rockchip_sfc.c | 6 ++ include/configs/rk3568_common.h | 5 ++ 15 files changed, 197 insertions(+), 37 deletions(-) -- 2.25.1

7 43

[RFC PATCH v1 0/9] Renesas RZ/N1 SoC initial support
by Ralph Siemsen 22 Feb '23

22 Feb '23

The RZ/N1 is a family of SoC devices from Renesas [1], featuring ARM Cortex-A7 and/or Cortex-M3 CPU, industrial ethernet protocols, integrated Ethernet switch, and numerous peripherals. This is a first step in upstreaming support for the RZ/N1 family. Currently it contains just enough to boot to the u-boot prompt. Additional patches will follow to support flash, SD, USB, Ethernet, etc. At this point, I am looking for general feedback about the overall direction and structure. I'm aware of several checkpatch warnings, and some TODO/FIXME items, which will be addressed. This work is based on a vendor-supplied u-boot 2017.01 tree [2], which supports several eval boards, none of which I have access to. Instead development has been done on a Schneider LCES2 board, which is fairly similar to the Renesas RZ/N1D-DB Demo board. The patches are currently against v2022.10-rc2. [1] https://www.renesas.com/us/en/products/microcontrollers-microprocessors/rz-… [2] https://github.com/renesas-rz/rzn1_u-boot/tree/rzn1-stable Michel Pollet (1): tools: Add tool to create Renesas SPKG images Ralph Siemsen (8): ARM: armv7: add non-SPL enable for Cortex SMPEN clk: renesas: prepare for non-RCAR clock drivers clk: renesas: add R906G032 driver pinctrl: renesas: add R906G032 driver ram: cadence: add driver for Cadence EDAC dts: basic devicetree for Renesas RZ/N1 SoC ARM: rzn1: basic support for Renesas RZ/N1 SoC board: schneider: add LCES board support arch/arm/Kconfig | 17 + arch/arm/Makefile | 1 + arch/arm/cpu/armv7/Kconfig | 5 + arch/arm/dts/r9a06g032-rzn1d400-lces.dts | 50 ++ arch/arm/dts/r9a06g032.dtsi | 225 ++++++ arch/arm/mach-rzn1/Kconfig | 32 + arch/arm/mach-rzn1/Makefile | 3 + arch/arm/mach-rzn1/cpu_info.c | 20 + board/schneider/lces/Kconfig | 12 + board/schneider/lces/Makefile | 3 + board/schneider/lces/ddr_timing.c | 140 ++++ .../lces/jedec_ddr3_2g_x16_1333h_500_cl8.h | 399 ++++++++++ board/schneider/lces/lces.c | 41 + configs/lces_defconfig | 26 + drivers/clk/renesas/Kconfig | 8 +- drivers/clk/renesas/Makefile | 6 +- drivers/clk/renesas/r9a06g032-clocks.c | 734 ++++++++++++++++++ drivers/pinctrl/Makefile | 1 + drivers/pinctrl/renesas/Kconfig | 7 + drivers/pinctrl/renesas/Makefile | 1 + drivers/pinctrl/renesas/pinctrl-rzn1.c | 398 ++++++++++ drivers/ram/Kconfig | 1 + drivers/ram/Makefile | 2 + drivers/ram/cadence/Kconfig | 24 + drivers/ram/cadence/Makefile | 1 + drivers/ram/cadence/ddr_async.c | 295 +++++++ drivers/ram/cadence/ddr_ctrl.c | 414 ++++++++++ drivers/ram/cadence/ddr_ctrl.h | 172 ++++ include/configs/lces.h | 22 + include/dt-bindings/clock/r9a06g032-sysctrl.h | 148 ++++ include/dt-bindings/pinctrl/rzn1-pinctrl.h | 141 ++++ tools/Makefile | 2 + tools/spkg_header.h | 49 ++ tools/spkg_utility.c | 306 ++++++++ 34 files changed, 3702 insertions(+), 4 deletions(-) create mode 100644 arch/arm/dts/r9a06g032-rzn1d400-lces.dts create mode 100644 arch/arm/dts/r9a06g032.dtsi create mode 100644 arch/arm/mach-rzn1/Kconfig create mode 100644 arch/arm/mach-rzn1/Makefile create mode 100644 arch/arm/mach-rzn1/cpu_info.c create mode 100644 board/schneider/lces/Kconfig create mode 100644 board/schneider/lces/Makefile create mode 100644 board/schneider/lces/ddr_timing.c create mode 100644 board/schneider/lces/jedec_ddr3_2g_x16_1333h_500_cl8.h create mode 100644 board/schneider/lces/lces.c create mode 100644 configs/lces_defconfig create mode 100644 drivers/clk/renesas/r9a06g032-clocks.c create mode 100644 drivers/pinctrl/renesas/pinctrl-rzn1.c create mode 100644 drivers/ram/cadence/Kconfig create mode 100644 drivers/ram/cadence/Makefile create mode 100644 drivers/ram/cadence/ddr_async.c create mode 100644 drivers/ram/cadence/ddr_ctrl.c create mode 100644 drivers/ram/cadence/ddr_ctrl.h create mode 100644 include/configs/lces.h create mode 100644 include/dt-bindings/clock/r9a06g032-sysctrl.h create mode 100644 include/dt-bindings/pinctrl/rzn1-pinctrl.h create mode 100644 tools/spkg_header.h create mode 100644 tools/spkg_utility.c -- 2.25.1

4 28

[PATCH] arm: dts: rockchip: rk3399: nanopi-r4s: Provide smbios sysinfo
by Christian Kohlschütter 22 Feb '23

22 Feb '23

Provide human-readable manufacturer and product names for the FriendlyELEC NanoPi R4S. Enable CONFIG_SYSINFO and CONFIG_SYSINFO_SMBIOS by default. Signed-off-by: Christian Kohlschütter <christian(a)kohlschutter.com> --- arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi | 22 ++++++++++++++++++++++ configs/nanopi-r4s-rk3399_defconfig | 2 ++ 2 files changed, 24 insertions(+) diff --git a/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi b/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi index cd1642527b..69800cc368 100644 --- a/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi +++ b/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi @@ -14,3 +14,25 @@ #include "rk3399-nanopi4-u-boot.dtsi" #include "rk3399-sdram-lpddr4-100.dtsi" + +/ { + smbios { + compatible = "u-boot,sysinfo-smbios"; + + smbios { + system { + manufacturer = "FriendlyELEC"; + product = "NanoPi R4S"; + }; + + baseboard { + manufacturer = "FriendlyELEC"; + product = "NanoPi R4S"; + }; + + chassis { + manufacturer = "FriendlyELEC"; + }; + }; + }; +}; diff --git a/configs/nanopi-r4s-rk3399_defconfig b/configs/nanopi-r4s-rk3399_defconfig index dd2579d2e0..502f007e6e 100644 --- a/configs/nanopi-r4s-rk3399_defconfig +++ b/configs/nanopi-r4s-rk3399_defconfig @@ -75,3 +75,5 @@ CONFIG_MISC=y CONFIG_MISC_INIT_R=y CONFIG_ROCKCHIP_EFUSE=y CONFIG_ROCKCHIP_OTP=y +CONFIG_SYSINFO=y +CONFIG_SYSINFO_SMBIOS=y -- 2.36.2

3 8

[PATCH 0/3] Introduce new sign binman's option
by Ivan Mikhaylov 18 Feb '23

18 Feb '23

From: Ivan Mikhaylov <ivan.mikhaylov(a)siemens.com> This patch introduces prototype of new sign binman's option. Enhancing the sign procedure, as example: mkimage -G privateky -r -o sha256,rsa4096 -F fit.fit binman replace -i flash.bin -f fit.fit fit into: binman sign -i flash.bin -k privatekey -a sha256,rsa4096 -f fit.fit fit It works with extracted FIT container and image, which provides key signing and replacing FIT container in directed image. Also, I'll add additional enhancement in future to this procedure with skipping on FIT container and providing extract->sign->replace in whole instead of sign->replace with documentation update and test as well. As example: binman sign -i flash.bin -k privatekey -a sha256,rsa4096 -f fit Ivan Mikhaylov (3): binman: add sign option for binman binman: add documentation for binman sign option binman: add test for sign option tools/binman/binman.rst | 10 +++++ tools/binman/cmdline.py | 13 ++++++ tools/binman/control.py | 26 +++++++++++- tools/binman/ftest.py | 42 +++++++++++++++++++ tools/binman/test/225_fit_sign.dts | 67 ++++++++++++++++++++++++++++++ 5 files changed, 157 insertions(+), 1 deletion(-) create mode 100644 tools/binman/test/225_fit_sign.dts -- 2.35.1

4 24

bind/unbind command not working for usb_ether
by Tim Harvey 15 Feb '23

15 Feb '23

Greetings, I'm trying to understand how to use the U-Boot bind command to bind the usb_ether driver to the usb class to register a USB ethernet gadget network device as referenced in: commit 02291d83fdaaf ("doc: add bind/unbind command documentation") commit 49c752c93a78 ("cmd: Add bind/unbind commands to bind a device to a driver from the command line") I have enabled: CONFIG_DM_USB=y CONFIG_USB_GADGET=y CONFIG_USB_ETHER=y However the 'usb_ether' driver is never registered and thus doesn't appear in a 'dm tree' list and can't be bound to the usb controller. With the help of Heiko I've found two ways to get the usb_ether driver to register: dt-way: - add of match in ether.c: diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c index 63d552bc8b..8e2a05a5af 100644 --- a/drivers/usb/gadget/ether.c +++ b/drivers/usb/gadget/ether.c @@ -2690,10 +2690,16 @@ int usb_ether_init(void) return 0; } +static const struct udevice_id usb_ether_ids[] = { + { .compatible = "gadget,usb_ether" }, + { } +}; + U_BOOT_DRIVER(eth_usb) = { .name = "usb_ether", .id = UCLASS_ETH, .probe = usb_eth_probe, + .of_match = usb_ether_ids, .ops = &usb_eth_ops, .priv_auto_alloc_size = sizeof(struct ether_priv), .platdata_auto_alloc_size = sizeof(struct eth_pdata), - then add it directly in your board u-boot.dts: +&usbotg1 { + usb_ether0 { + compatible = "gadget,usb_ether"; + status = "okay"; + }; +}; The non-dt way: - bind it manually in board code with: { struct udevice *dev; struct udevice *usb_dev; int ret; ret = uclass_first_device(UCLASS_USB, &usb_dev); if (!usb_dev || ret) printf("%s: No USB device found\n", __func__); ret = device_bind_driver(usb_dev, "usb_ether", "usb_ether", &dev); if (!dev || ret) printf("%s: usb - not able to bind usb_ether device\n", __func__); } - Note that this is the same code from usb_ether_init() but with UCLASS_USB instead of UCLASS_USB_GADGET_GENERIC What is the intended way to bind the usb_ether gadget device at runtime? Additionally Heiko found that once bound and usb_ether is registered as a network device using a network command like ping/tftpboot calls usb_setup_ehci_gadget() which removes the USB driver ... and so also the child usb ethernet gadget device then re-probes only the usb driver and not the gadget thus fails. I compared this to how the 'ums' command works and that also removes the usb driver and child nodes but because ums isn't a gadget driver it doesn't get removed and works. Best Regards, Tim

5 12