Ping again? Or silence means no care from CZ.NIC side?
On Tuesday 31 January 2023 19:53:23 Pali Rohár wrote: > Gentle ping? Does CZ.NIC care about Turris routers and u-boot support? > > On Monday 07 November 2022 21:28:31 Pali Rohár wrote: > > Hello! Just beware of these two commits which renamed files mentioned in > > patch > > https://source.denx.de/u-boot/u-boot/-/commit/87ac4b4b4ca5f00e2ddcdac41c9dc691ab2aecf1 > > https://source.denx.de/u-boot/u-boot/-/commit/d8fa0a76681af3ecea3941f5c743332dd76c7543 > > So documentation in v2 now needs to be updated to address those renamed > > files. > > > > On Tuesday 01 November 2022 23:10:00 Josef Schlehofer wrote: > > > Hey Pali, > > > > > > Thanks for letting me know about it! > > > > > > I will prepare new version tomorrow and send it as v2. > > > > > > Regards, > > > Josef > > > > > > On 01. 11. 22 23:07, Pali Rohár wrote: > > > > + Lukáš and Josef from CZ.NIC > > > > > > > > On Monday 03 October 2022 22:25:05 Pali Rohár wrote: > > > > > + Štěpán from CZ.NIC. Please look at the Heinrich comments below and > > > > > prepare a new version with fixes... I will let it to you right now. > > > > > > > > > > On Monday 26 September 2022 13:30:02 Heinrich Schuchardt wrote: > > > > > > On 9/23/22 13:36, Pali Rohár wrote: > > > > > > > This patch adds a new documentation for all released CZ.NIC > > > > > > > Turris routers. > > > > > > > > > > > > > > Signed-off-by: Pali Rohár <p...@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``. > > > > > > Please, use a maximum of 80 characters per line. > > > > > > > > > > > > > + > > > > > > > +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 > > > > > > Please, precede the code-block by > > > > > > > > > > > > .. code-block:: c > > > > > > > > > > > > to get syntax highlighting > > > > > > > > > > > > Use continuation lines to use a maximum of 80 characters. > > > > > > > > > > > > Don't use '$ ' as a line start as it make copying the commands to > > > > > > the > > > > > > console unnecessarily complicated. > > > > > > > > > > > > Best regards > > > > > > > > > > > > Heinrich > > > > > Just small explanation. There are '$ ' at the start of lines which > > > > > describe commands which should be called on the host and '=> ' at the > > > > > start of lines which should be called on U-Boot console. It is there > > > > > to > > > > > visually distinguish differences. And btw, it is shell code, so > > > > > probably > > > > > should not use C lang highlighting. > > > > > > > > > > > > + > > > > > > > +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 > > > > > > > > >
