fallen_aarch64 Posted December 26, 2021 Posted December 26, 2021 Hi eveyone, I am coming from a a hint off Github here: https://github.com/armbian/documentation/issues/165. Igor was so kind and redirected me to this community. I am struggling since beginning christmas to get my EspressoBin to latest versions out of dusty 2018 images. Device EspressoBin v7 DDR4 1G 1000_800Mhz Baseline - What did I do? - Update U-Boot according https://www.armbian.com/espressobin to devel-18.12.3 - Flashed SD-Card with armbian Focal via Balena according https://docs.armbian.com/User-Guide_Getting-Started/ - Updated Boot Environment according https://www.armbian.com/espressobin/#kernels-archive-all Problem Description - U-Boot Loads and starts over to boot from SD-Card - Booting from SD fails with Marvell>> boot *** ERROR: serverip' not set *** ERROR: serverip' not set Bad Linux ARM64 Image magic! I would be very grateful for any hints how to get armbian booted on the EspressoBin in 2022! Happy Holidays to all. cheers Full Logs U-Boot 2018.03-devel-18.12.3-gc9aa92ce70-armbian (Sep 18 2020 - 10:07:21 +0200) Model: Marvell Armada 3720 Community Board ESPRESSOBin CPU 1000 [MHz] L2 800 [MHz] TClock 200 [MHz] DDR 800 [MHz] DRAM: 1 GiB Comphy chip #0: Comphy-0: USB3 5 Gbps Comphy-1: PEX0 2.5 Gbps Comphy-2: SATA0 6 Gbps SATA link 0 timeout. AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode flags: ncq led only pmp fbss pio slum part sxs PCIE-0: Link up MMC: sdhci@d0000: 0 Loading Environment from SPI Flash... SF: Detected mx25u3235f with page size 256 Bytes, erase size 64 KiB, total 4 MiB OK Model: Marvell Armada 3720 Community Board ESPRESSOBin Net: eth0: neta@30000 [PRIME] https://github.com/armbian/documentation/issues/165 0 Quote
guidol Posted December 26, 2021 Posted December 26, 2021 Its old , but maybe it could help a little bit? https://web.archive.org/web/20180104180446/http://wiki.macchiatobin.net/tiki-index.php?page=Boot+from+removable+storage+-+Ubuntu and http://macchiatobin.net/forums/topic/booting-failure-of-new-board/#post-1512 0 Quote
Solution fallen_aarch64 Posted December 27, 2021 Author Solution Posted December 27, 2021 Hi Guido, again thank you very much. Your links were for the Machiatobin which is Armada 8040 - the Espressobin is using 3720. However it gave me enough food for thought to sucessfully compile Ubuntu 14.04. LTS with it. Just a short write up how it worked out for others and my later me: 1. Compile Kernel Image and DTB - latest supported Kernel is 4.4.8 https://web.archive.org/web/20210307141251/http://wiki.espressobin.net/tiki-index.php?page=Build+From+Source+-+Kernel 2. Fix Errors during compilation /usr/bin/ld: scripts/dtc/dtc-parser.tab.o:(.bss+0x10): multiple definition of `yylloc'; scripts/dtc/dtc-lexer.lex.o:(.bss+0x0): first defined here sed -i 's/^YYLTYPE yylloc;$/extern YYLTYPE yylloc;/' scripts/dtc/dtc-lexer.l sed -i 's/^YYLTYPE yylloc;$/extern YYLTYPE yylloc;/' scripts/dtc/dtc-lexer.lex.c https://web.archive.org/save/https://forum.0cd.xyz/t/building-u-boot-for-the-espressobin/511 3. Prepare Ubuntu 14.04.5 LTS to boot from SDCard https://web.archive.org/save/http://wiki.espressobin.net/tiki-index.php?page=Boot+from+removable+storage+-+Ubuntu DONE 0 Quote
Rötti Posted January 3, 2022 Posted January 3, 2022 Hi @fallen_aarch64 thank you for sharing the information. It would be very nice if you could provide a pull request for the files you changed. So everybody having that board would benefit from that. Since some people are not too much into "sed"ing. Thanks in advance! 0 Quote
guidol Posted January 3, 2022 Posted January 3, 2022 12 minutes ago, Rötti said: And the page https://web.archive.org/save/https://forum.0cd.xyz/t/building-u-boot-for-the-espressobin/511 is not working for me anymore. Thanks in advance! here is a working link to the archive: https://web.archive.org/web/20211227155426/https://forum.0cd.xyz/t/building-u-boot-for-the-espressobin/511 0 Quote
Pali Posted January 6, 2022 Posted January 6, 2022 Hello! I would suggest you to update U-Boot on Espressobin to modern version from year 2021 (e.g. 2021.10) and not some old version from year 2018. Also update kernel to some recent version from year 2021 (e.g. 5.10) as also kernel contains many and many fixes for Espressobin / A3720 SoC. 0 Quote
Pali Posted January 8, 2022 Posted January 8, 2022 Look into the official ARM Trusted-Firmware documentation for Marvell platforms how to build recent version of Firmware + U-Boot for Espressobin: https://trustedfirmware-a.readthedocs.io/en/latest/plat/marvell/armada/build.html (search for how to build production release of Marvell firmware image where are all commands which generatate firmware) Also look into the U-Boot documentation there is important section Permanent ethernet MAC address for updating U-Boot: https://source.denx.de/u-boot/u-boot/-/raw/master/doc/README.marvell 0 Quote
y52 Posted February 6, 2022 Posted February 6, 2022 On 1/8/2022 at 11:07 PM, Pali said: Look into the official ARM Trusted-Firmware documentation for Marvell platforms Pali, your suggestion implementing mainstream u-boot makes a lot of sense. The subj. hasn't been sufficiently discussed and transition to mainstream build requires more explanations. Build Instructions found on https://trustedfirmware-a.readthedocs.io/en/latest/plat/marvell/armada/build.html lack a more comprehensive guidance with the necessary packages to install on a fresh system, as well as adding several git clone calls and then the make calls. Has somebody tried preparing a full steps document? 0 Quote
Pali Posted February 6, 2022 Posted February 6, 2022 In past I reported to Armbian issue tracker to increase firmware versions and rebuild firmware from new sources, but they rejected to do it (because A3720 is unsupported or what). @y52 What is missing in that build instruction TF-A document? I could extend it or write some other guideline / steps. But I do not know what do you mean by full steps document. 0 Quote
y52 Posted February 6, 2022 Posted February 6, 2022 5 minutes ago, Pali said: What is missing in that build instruction TF-A document? I is worth checking which packages are required for building. I've only setup a basic Armbian system and haven't yet completed it with the build environment. Besides, I haven't seen the u-boot sources and how to git clone them. Is the "full example how to build production release of Marvell firmware" at the end of "12.1.1. Build Instructions" and before "12.1.2. Special Build Flags" exhaustive to allow u-boot build from the scratch? 0 Quote
Pali Posted February 6, 2022 Posted February 6, 2022 Yes, it is! It fetches all sources, including U-Boot, compile them and produce final binary. 0 Quote
y52 Posted February 7, 2022 Posted February 7, 2022 Pali, I've started looking into instructions, but knocked upon the 'trusted-firmware-a' certificates issue : root@deb10:/src# git clone https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git Cloning into 'trusted-firmware-a'... fatal: unable to access 'https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/': server certificate verification failed. CAfile: none CRLfile: none If I open the git link in a browser, it SSL connection doesn't reveal certificates anomalies. Any idea how to fix it? 0 Quote
Pali Posted February 7, 2022 Posted February 7, 2022 3 minutes ago, y52 said: server certificate verification failed. CAfile: none CRLfile: none Seems that you have not installed system certificates correctly... Not sure how it can happen, at least I have not seen this error neither on Ubuntu, nor Suse nor Fedora. Anyway, you can call export GIT_SSL_NO_VERIFY=true to set env variable which instruct git ignore SSL related errors. 0 Quote
y52 Posted February 7, 2022 Posted February 7, 2022 I use a basic Debian 10 system. I downloaded the certificate to the file and tried importing it : root@deb10:~# git config --global http.sslCAInfo /src/git-certs/trustedfirmwareCert.pem root@deb10:/src/git-certs# git config --global --list http.sslcainfo=/src/git-certs/trustedfirmwareCert.pem Nevertheless I was unable to clone. root@deb10:/src# git clone https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git Cloning into 'trusted-firmware-a'... fatal: unable to access 'https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/': server certificate verification failed. CAfile: /src/git-certs/trustedfirmwareCert.pem CRLfile: none No idea, why it doesn't recognize it. It worked as you suggested : root@deb10:/src# export GIT_SSL_NO_VERIFY=true root@deb10:/src# git clone https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git Cloning into 'trusted-firmware-a'... remote: Enumerating objects: 36415, done. remote: Counting objects: 100% (36415/36415), done. remote: Compressing objects: 100% (10238/10238), done. remote: Total 96952 (delta 34065), reused 26177 (delta 26177), pack-reused 60537 Receiving objects: 100% (96952/96952), 20.20 MiB | 8.57 MiB/s, done. Resolving deltas: 100% (65796/65796), done. 0 Quote
Pali Posted February 7, 2022 Posted February 7, 2022 On Debian it should be enough to install package ca-certificates (e.g. apt install ca-certificates) if it is not installed yet. Anyway, if you download that file check that file path /src/git-certs/trustedfirmwareCert.pem really exists. 0 Quote
y52 Posted February 8, 2022 Posted February 8, 2022 It is still strange, that certificate is not accepted by Git : # openssl x509 -noout -in trustedfirmwareCert.pem -text Certificate: Data: Version: 3 (0x2) Serial Number: 03:be:6d:7d:08:6a:83:d1:83:bf:24:3b:68:5c:25:31:ee:31 Signature Algorithm: sha256WithRSAEncryption Issuer: C = US, O = Let's Encrypt, CN = R3 Validity Not Before: Jan 28 22:00:18 2022 GMT Not After : Apr 28 22:00:17 2022 GMT Subject: CN = git.trustedfirmware.org Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (4096 bit) ...... It is still worth cloning trusted sources. 0 Quote
Pali Posted February 8, 2022 Posted February 8, 2022 IIRC http.sslCAInfo needs CA (=certificate authority) and not individual server sertificate (which has Subject: CN = git.trustedfirmware.org). So you should import to that file certificate which has Subject: C = US, O = Let's Encrypt, CN = R3. Now looking that you are missing CA for Let's Encrypt... so are not you just a victim of one of those cross-signing issue with Let's Encrypt where Let's Encryt Root CA expired (in Sep 30 2021)? This is already fixed also in Debian (it is required to remove expired Let's Encrypt CA cert), so ensure that you have your system up-to-date and package ca-certificates is also up-to-date. In the worst case for this expired Let's Encrypt Root CA issue, you can manually remove it by calling dpkg-reconfigure ca-certificates and deselect DST Root CA X3. 0 Quote
y52 Posted February 8, 2022 Posted February 8, 2022 Pali, You are absolutely right! I've come to the same conclusion, that Git expected CA (=certificate authority), while I was offering an individual server certificate. In that perspective, I've removed the trustedfirmware's certificate from the Git config and updated root@deb10:/src# apt install ca-certificates following by # apt update & apt upgrade. This time Git has worked as expected: root@deb10:/src# git clone https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git Cloning into 'trusted-firmware-a'... remote: Enumerating objects: 36415, done. remote: Counting objects: 100% (36415/36415), done. remote: Compressing objects: 100% (10238/10238), done. remote: Total 96952 (delta 34069), reused 26177 (delta 26177), pack-reused 60537 Receiving objects: 100% (96952/96952), 20.19 MiB | 8.74 MiB/s, done. Resolving deltas: 100% (65800/65800), done. Other Git clones worked like a charm as well. Thus I've obtained all the sources at this stage: root@deb10:/src# ls -al drwxr-xr-x 7 root root 4096 Feb 8 11:29 A3700-utils-marvell drwxr-xr-x 8 root root 16384 Feb 8 11:28 cryptopp drwxr-xr-x 7 root root 4096 Feb 8 11:29 mox-boot-builder drwxr-xr-x 12 root root 4096 Feb 8 11:28 mv-ddr-marvell drwxr-xr-x 20 root root 4096 Feb 8 11:19 trusted-firmware-a drwxr-xr-x 26 root root 4096 Feb 8 11:27 u-boot Thank you for your follow up. I shall be able continuing u-boot build process on good grounds. 0 Quote
y52 Posted February 8, 2022 Posted February 8, 2022 CROSS_COMPILE requires "aarch64-linux-gnu" Where could it be got from ? The "TF-A Build Instructions for Marvell Platforms" document seems not to specify the cross compiler location or how to install it. 0 Quote
Pali Posted February 8, 2022 Posted February 8, 2022 It requires aarch64-linux-gnu-gcc cross compiler. On Debian it is in package gcc-aarch64-linux-gnu and you can install it via apt install gcc-aarch64-linux-gnu 0 Quote
y52 Posted February 8, 2022 Posted February 8, 2022 Everything seems to be in place now. Should the make instructions make -C u-boot .. make -C mox-boot-builder .. make -C trusted-firmware-a .. be initiated from the "u-boot" sources directory or from the project's base directory? https://marcin.juszkiewicz.com.pl/2021/02/15/ebbr-on-espressobin/ The author doesn't use make -C mox-boot-builder .. 0 Quote
Pali Posted February 8, 2022 Posted February 8, 2022 All commands in that TF-A document in section full example how to build production release of Marvell firmware image must be called from the same directory. So e.g. if you created directory /my/work/dir/ and you called all those git clone commands in /my/work/dir/ then you also have to call other commands in /my/work/dir/ directory (and not in some subdirectory). 0 Quote
Pali Posted February 8, 2022 Posted February 8, 2022 6 minutes ago, y52 said: The author doesn't use make -C mox-boot-builder .. See TF-A documentation, just few lines above that command. It is CZ.NIC’s Armada 3720 Secure Firmware. And in WTMI_IMG section is information about this firmware: This firmware includes additional features like access to Hardware Random Number Generator of Armada 3720 SoC which original Marvell’s fuse.bin image does not have. With this (new) firmware, Linux kernel will gain access to Espressobin's HW random number generator. 0 Quote
y52 Posted February 8, 2022 Posted February 8, 2022 I haven't yet started the image build, as documentation requires some time to grasp. As initial target, I wanted to boot Armbian flashed on /dev/sda with my Espressobin board. Taken, that Armbian uses /boot/boot.cmd in boot sequence, which BOOTDEV target should be used? Is BOOTDEV=SPINOR PARTNUM=0 (the image boot from SPI NOR flash partition 0) correct target for this scenario ? Is it default option, or should it be explicitly instructed for build? I understand that new u-boot will greatly increase boot choices and many regular Linux distributions could be launched from boot loaders like Grub. This will need to be explored later. 0 Quote
Pali Posted February 8, 2022 Posted February 8, 2022 https://trustedfirmware-a.readthedocs.io/en/latest/plat/marvell/armada/build.html Quote BOOTDEV The flash boot device, default is SPINOR. PARTNUM The boot partition number, default is 0. It specifies where you put firmware and from where should bootrom load it. Typically on Espressobin is used SPI-NOR and it has no partitions (hence zero is used). 0 Quote
y52 Posted February 9, 2022 Posted February 9, 2022 I've successfully built the TF-A u-boot image ; root@deb10:/src# make distclean make: *** No rule to make target 'distclean'. Stop. root@deb10:/src# make -C u-boot CROSS_COMPILE=aarch64-linux-gnu- mvebu_espressobin-88f3720_defconfig u-boot.bin make: Entering directory '/src/u-boot' HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o YACC scripts/kconfig/zconf.tab.c LEX scripts/kconfig/zconf.lex.c HOSTCC scripts/kconfig/zconf.tab.o .... DTC arch/arm/dts/armada-3720-espressobin.dtb DTC arch/arm/dts/armada-3720-turris-mox.dtb DTC arch/arm/dts/armada-388-helios4.dtb .. SHIPPED dts/dt.dtb CAT u-boot-dtb.bin COPY u-boot.bin make: Leaving directory '/src/u-boot' root@deb10:/src# make -C mox-boot-builder CROSS_CM3=arm-linux-gnueabi- wtmi_app.bin make: Entering directory '/src/mox-boot-builder' make -C wtmi CROSS_CM3=arm-linux-gnueabi- LTO=1 wtmi_app.bin make[1]: Entering directory '/src/mox-boot-builder/wtmi' CC tim.c CC ebg.c CC uart.c CC efuse.c CC crypto.c .. CC main.c LD wtmi_app.elf OBJCOPY wtmi_app.bin make[1]: Leaving directory '/src/mox-boot-builder/wtmi' cp -a wtmi/wtmi_app.bin wtmi_app.bin make: Leaving directory '/src/mox-boot-builder' root@deb10:/src# make -C trusted-firmware-a CROSS_COMPILE=aarch64-linux-gnu- CROSS_CM3=arm-linux-gnueabi- \ > USE_COHERENT_MEM=0 PLAT=a3700 CLOCKSPRESET=CPU_1200_DDR_750 DDR_TOPOLOGY=5 \ > MV_DDR_PATH=$PWD/mv-ddr-marvell/ WTP=$PWD/A3700-utils-marvell/ \ > CRYPTOPP_PATH=$PWD/cryptopp/ BL33=$PWD/u-boot/u-boot.bin \ > WTMI_IMG=$PWD/mox-boot-builder/wtmi_app.bin FIP_ALIGN=0x100 mrvl_flash make: Entering directory '/src/trusted-firmware-a' CC bl1/aarch64/bl1_arch_setup.c CC bl1/aarch64/bl1_context_mgmt.c CC bl1/bl1_main.c ... Built /src/trusted-firmware-a/build/a3700/release/bl2.bin successfully .. Built /src/trusted-firmware-a/build/a3700/release/boot-image.bin successfully .. Trusted Boot Firmware BL2: offset=0x100, size=0x41F1, cmdline="--tb-fw" EL3 Runtime Firmware BL31: offset=0x4300, size=0xBA30, cmdline="--soc-fw" Non-Trusted Firmware BL33: offset=0xFE00, size=0xD3038, cmdline="--nt-fw" Built /src/trusted-firmware-a/build/a3700/release/fip.bin successfully Built /src/trusted-firmware-a/build/a3700/release/boot-image.bin successfully .... Building a3700 tool CC a3700/mv_ddr_brd.c CC a3700/a3700_tool.c CC a3700/mv_ddr_plat.c CC drivers/mv_ddr_mc6.c CC mv_ddr4_training_db.c CC ddr3_training_db.c CC mv_ddr_common.c CC mv_ddr_build_message.c Building flash image TBB Version : 3.3.12.1 TBB Date : 2017-03-17 Start time: 02/09/22 19:12:54 CommandLineOptions: -r /src/trusted-firmware-a/build/a3700/release/atf-ntim.txt -v -D .. Success: Non-trusted Tim Descriptor file parsing has completed successfully! .. Prepending ImageTag <0x57544d49> to image file: <wtmi_h.bin>. Prepending ImageTag <0x4F424d49> to image file: <boot-image_h.bin>. Success: NTIM Processing has completed successfully! Finish time: 02/09/22 19:12:54 TBB Exiting...! No input file for TIMN is supplied Total number of images to process in file[0] - 3 0 Image at offset 00000000 is TIM_ATF.bin 1 Image at offset 00004000 is wtmi.bin 2 Image at offset 00015000 is boot-image.bin Total number of images 3 Built /src/trusted-firmware-a/build/a3700/release/flash-image.bin successfully root@deb10:/src# ls -alh /src/trusted-firmware-a/build/a3700/release/flash-image.bin -rw-r--r-- 1 root root 1.1M Feb 9 19:12 /src/trusted-firmware-a/build/a3700/release/flash-image.bin Is that flash-image.bin which should be flashed to SPI of Espressobin? Marvell>> bubt flash-image.bin spi usb Will it be necessary adjusting u-boot environment once the migration from Armbian u-boot 2020 to mainline u-boot 2022 is done? 0 Quote
Pali Posted February 9, 2022 Posted February 9, 2022 4 minutes ago, y52 said: Is that flash-image.bin which should be flashed to SPI of Espressobin? Yes! 4 minutes ago, y52 said: Will it be necessary adjusting u-boot environment once the migration from Armbian u-boot 2020 to mainline u-boot 2022 is done? It is suggested to reset environment to default values. But beware about loosing MAC addresses! See: https://source.denx.de/u-boot/u-boot/-/raw/master/doc/README.marvell 0 Quote
y52 Posted February 9, 2022 Posted February 9, 2022 34 minutes ago, Pali said: beware about loosing MAC addresses! I've recorded original MAC address values found with the board. Besides, eth0 MAC ($ethaddr ) is printed on the back of the box. I just doubt about per-port MAC addresses $eth1addr - $eth2addr as they look *not* unique. For building other u-boot variants, I was unable to clean previous build residuals (if any) root@deb10:/src# make distclean make: *** No rule to make target 'distclean'. Stop. How could it be fixed ? 3. Clean-up old residuals: Is it not rather # make mrproper ? Comparing u-boot file sizes : 869K Feb 5 23:30 flash-image-ddr4-1g-1cs-1200_750.bin <-- Armbian u-boot 2020 1.1M Feb 9 19:12 /src/trusted-firmware-a/build/a3700/release/flash-image.bin <-- Marvell AT-F u-boot 2022 0 Quote
Pali Posted February 9, 2022 Posted February 9, 2022 1 minute ago, y52 said: For building other u-boot variants, I was unable to clean previous build residuals (if any) root@deb10:/src# make distclean make: *** No rule to make target 'distclean'. Stop. How could it be fixed ? To cleanup TF-A binaries, just call: make -C trusted-firmware-a distclean MV_DDR_PATH=$PWD/mv-ddr-marvell/ WTP=$PWD/A3700-utils-marvell/ U-Boot and wtmi_app.bin binaries are same for all variants. But if you want to clean them call: make -C u-boot distclean make -C mox-boot-builder clean 0 Quote
y52 Posted February 9, 2022 Posted February 9, 2022 Thank you @Pali. Cleanup instructions were not explicit in the document. I am also concerned about the the required device-tree file. Armbian supply dtb files defined in armbian# cat /boot/boot.cmd .. setenv fdt_name_a dtb/marvell/armada-3720-community.dtb <<-- not used setenv fdt_name_b dtb/marvell/armada-3720-espressobin.dtb <<-- this one is called I believe they were built together with their u-boot version: 8.8K Jun 25 2019 /boot/dtb-4.19.56-mvebu64/marvell/armada-3720-espressobin.dtb Now that we are going to replace Armbian u-boot with the mainline AT-F version, would it be necessary replacing DTB file with the one built now? They could be found here : root@deb10:/src# ls -alh $PWD/u-boot/arch/arm/dts/armada-3720-* -rw-r--r-- 1 root root 6.3K Feb 9 18:47 /src/u-boot/arch/arm/dts/armada-3720-db.dtb -rw-r--r-- 1 root root 4.0K Feb 8 11:27 /src/u-boot/arch/arm/dts/armada-3720-db.dts -rw-r--r-- 1 root root 7.0K Feb 9 18:47 /src/u-boot/arch/arm/dts/armada-3720-espressobin.dtb -rw-r--r-- 1 root root 4.7K Feb 8 11:27 /src/u-boot/arch/arm/dts/armada-3720-espressobin.dts 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.