• 0

Making EspressoBin V7 work in 2022 ...


fallen_aarch64
 Share

5 5

Question

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

Link to post
Share on other sites

Recommended Posts

  • 0

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

Link to post
Share on other sites

Armbian is a community driven open source project. Do you like to contribute your code?

  • 0

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.

Link to post
Share on other sites

  • 0

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

Link to post
Share on other sites

  • 0
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?

 

Link to post
Share on other sites

  • 0

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.

Link to post
Share on other sites

  • 0
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? 

Link to post
Share on other sites

  • 0

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?

Link to post
Share on other sites

  • 0
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.

Link to post
Share on other sites

  • 0

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.

Link to post
Share on other sites

  • 0

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.

Link to post
Share on other sites

  • 0

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.

Link to post
Share on other sites

  • 0

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.

Link to post
Share on other sites

  • 0

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.

Link to post
Share on other sites

  • 0

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.

 

Link to post
Share on other sites

  • 0

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).

Link to post
Share on other sites

  • 0
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.

Link to post
Share on other sites

  • 0

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.

Link to post
Share on other sites

  • 0

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?

 

 

 

 

Link to post
Share on other sites

  • 0
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

Link to post
Share on other sites

  • 0
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

Link to post
Share on other sites

  • 0
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

 

Link to post
Share on other sites

  • 0

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

Link to post
Share on other sites

  • 0

Beware! There are two different sets of DTB files. One set used internally only by U-Boot, bundled by U-Boot source code and statically linked into U-Boot binary. And then another set included in Linux kernel, used as external files and used for booting.

 

What you write about is I guess those DTB files supplied by Linux kernel and those are unrelated to U-Boot and firmware.

Link to post
Share on other sites

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.

Guest
Answer this question...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

5 5