Jump to content

Making EspressoBin V7 work in 2022 ...


fallen_aarch64

Recommended Posts

3 hours ago, y52 said:

NetworkManager and systemd-networkd are duplicating services and can't be run concurrently. You should choose enabling one of them. I understand that systemd-networkd is a preferred choice under Debian, thus NetworkManager should be disabled in order not to interfere in network functioning. User can switch between them if he prefers  NetworkManager.

Yeah but that is not espressobin specific I guess - so I'll leave my hands off it for the moment :)

 

4 hours ago, y52 said:

E: Failed to fetch http://deb.debian.org/debian/pool/main/u/unzip/unzip_6.0-26_arm64.deb  502  Connection closed [IP: ::1 3142]
E: Failed to fetch http://deb.debian.org/debian/pool/main/u/usbutils/usbutils_013-3_arm64.deb  502  Connection closed [IP: ::1 3142]

E: Failed to fetch http://deb.debian.org/debian/pool/main/v/vim/vim_8.2.2434-3%2bdeb11u1_arm64.deb  502  Connection closed [IP: ::1 3142]
E: Failed to fetch http://deb.debian.org/debian/pool/main/v/vlan/vlan_2.0.5_all.deb  502  Connection closed [IP: ::1 3142]
E: Failed to fetch http://deb.debian.org/debian/pool/main/w/wireless-tools/wireless-tools_30~pre9-13.1_arm64.deb  502  Connection closed [IP: ::1 3142]
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
[ error ] ERROR in function create_rootfs_cache [ main.sh:589 -> main.sh:550 -> debootstrap.sh:58 -> debootstrap.sh:311 -> general.sh:0 ]
[ error ] Installation of Armbian main packages for current espressobin bullseye   no failed
[ o.k. ] Process terminated
[ error ] unmount_on_exit() called! [ main.sh:1 -> image-helpers.sh:0 ]
[ o.k. ] Unmounting [ /src/Armbian/build/.tmp/rootfs-c0d7eabc-a7bf-4b6e-a83a-67dc454eb8f4/ ]
[ error ] ERROR in function unmount_on_exit [ main.sh:1 -> image-helpers.sh:94 -> general.sh:0 ]
[ error ] debootstrap-ng was interrupted
[ o.k. ] Process terminated
Execution time: 56132.596534 seconds        <-  15 hours 36 min.
[1] 267691
Sun 13 Mar 2022 06:05:45 AM CET

No idea why apt fails.

Link to comment
Share on other sites

I wonder if mainline u-boot is capable booting ZFS file system and logical volume manager?

It is worth considering setting up Armbian directly on the ZFS as SSD and SD cards are far from being reliable.

I've experienced a series of hard setbacks due to their failures.

 

On 3/20/2022 at 3:15 PM, y52 said:

I wonder if mainline u-boot is capable booting ZFS file system

Apparently, only those file systems are supported :

=> fstypes 
Supported filesystems: fat, ext4, btrfs, squashfs

Link to comment
Share on other sites

Hello,

 

I have an espressobin (ebin?) v7, 1 GB memory.  I have a Bullseye system to attempt build.  I would like to assist with testing.

 

When using branch AR-775 (d74493ec0c04f663bed8e22bcbfeee595507dfa0), I am seeing:

Quote

[ o.k. ] Cleaning [ arm-trusted-firmware-espressobin/master ]
[ o.k. ] Compiling ATF
[ o.k. ] Compiler version [ aarch64-linux-gnu-gcc 7.4.1 ]
[ o.k. ] Started patching process for [ atf mvebu64-espressobin-current ]

[ o.k. ] Looking for user patches in [ userpatches/atf/atf-mvebu64 ]
Building a3700
  CC      lib/libc/abort.c
  CC      lib/libc/assert.c
  CC      lib/libc/exit.c
  CC      lib/libc/memchr.c
[ error ] ERROR in function compile_atf [ main.sh:589 -> main.sh:480 -> compilation.sh:87 -> general.sh:0 ]
[ error ] ATF compilation failed
[ o.k. ] Process terminated

 

I also noted the TF-A instructions call for libcrypto++-dev, which is not part of the pre-reqs installed on the host system (as far as I know).  Does that go in the big list in lib/general.sh ?

 

*Should* u-boot be built with gnueabi, or with gnueabihf?  I noted that the general.sh has linaro-7.4.1 arm-linux-gnueabi, while all the rest of the packages are armhf.  When I've looked in compilation.log, I see errors looking for gnueabi with SKIP_EXTERNAL_TOOLCHAIN (because I don't have a local toolchain installed)

 

In config/sources/families/mvebu64.conf, there is a line "ATF_COMPILER='aarch64-linux-gnu-'".  But the toolchains are:

7.4.1 - aarch64-linux-gnu

8.3 - aarch64-linux-gnu

9.2 - aarch64-none-linux-gnu

(my attempted contribution) 11.2 - aarch64-none-linux-gnu

 

Similarly, 9.2 has arm-none-linux-gnueabihf, instead of 8.3 arm-linux-gnueabihf or 7.4.1 arm-linux-gnueabi

It looks like 7.4.1 doesn't work because it's looking for

cache/toolchain/gcc-linaro-7.4.1-2019.02-x86_64_arm-linux-gnueabi/bin/arm-linux-gnueabihf-

which doesn't exist.

 

Also, I attempted to add the 11.2 toolchain, but still "find_toolchain" only gives 9.2.  I wonder if it's comparing characters rather than numbers.  Or is it supposed to take the smallest version that matches?

 

For wtmi, "gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/arm-linux-gnueabihf-" works for me.  Also, the 10.2.1 from debian bullseye.  I did not have success with 7.4.1 or 9.2... because their names are different.  I see.

 

Pull request submitted against AR-775

 

 

Edited by ManoftheSea
addl. detail
Link to comment
Share on other sites

u-boot compiled from mainline sources logs the following error when booting Espressobin v.7:

kernel: spi-nor spi0.0: unrecognized JEDEC id bytes: e7 60 16 00 00 00
kernel: spi-nor: probe of spi0.0 failed with error -2 

It seems, that U-Boot found the flash but couldn't find its JEDEC ID in its table. Typically this means support is not compiled in, and you need to add support in the U-Boot configuration.

Will it be taken care of in future mainline sources, so that new spi id's are added to uboot?

Link to comment
Share on other sites

2 hours ago, ManoftheSea said:

*Should* u-boot be built with gnueabi, or with gnueabihf?  I noted that the general.sh has linaro-7.4.1 arm-linux-gnueabi, while all the rest of the packages are armhf.  When I've looked in compilation.log, I see errors looking for gnueabi with SKIP_EXTERNAL_TOOLCHAIN (because I don't have a local toolchain installed)

 

In config/sources/families/mvebu64.conf, there is a line "ATF_COMPILER='aarch64-linux-gnu-'".  But the toolchains are:

7.4.1 - aarch64-linux-gnu

8.3 - aarch64-linux-gnu

9.2 - aarch64-none-linux-gnu

(my attempted contribution) 11.2 - aarch64-none-linux-gnu

 

Similarly, 9.2 has arm-none-linux-gnueabihf, instead of 8.3 arm-linux-gnueabihf or 7.4.1 arm-linux-gnueabi

It looks like 7.4.1 doesn't work because it's looking for

cache/toolchain/gcc-linaro-7.4.1-2019.02-x86_64_arm-linux-gnueabi/bin/arm-linux-gnueabihf-

which doesn't exist.

 

Also, I attempted to add the 11.2 toolchain, but still "find_toolchain" only gives 9.2.  I wonder if it's comparing characters rather than numbers.  Or is it supposed to take the smallest version that matches?

 

For wtmi, "gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/arm-linux-gnueabihf-" works for me.  Also, the 10.2.1 from debian bullseye.  I did not have success with 7.4.1 or 9.2... because their names are different.  I see.

 

Pull request submitted against AR-775

 

 

 

I think the uboot and atf should be built with aarch, the wtmi with gnueabi. See: 

https://gitlab.nic.cz/turris/mox-boot-builder

Link to comment
Share on other sites

On 3/27/2022 at 9:49 AM, y52 said:

u-boot compiled from mainline sources logs the following error when booting Espressobin v.7:

kernel: spi-nor spi0.0: unrecognized JEDEC id bytes: e7 60 16 00 00 00
kernel: spi-nor: probe of spi0.0 failed with error -2 

It seems, that U-Boot found the flash but couldn't find its JEDEC ID in its table. Typically this means support is not compiled in, and you need to add support in the U-Boot configuration.

Will it be taken care of in future mainline sources, so that new spi id's are added to uboot?

 

This is a bug in U-Boot for which I sent a hotfix recently: http://patchwork.ozlabs.org/project/uboot/patch/20220323161942.7308-1-pali@kernel.org/ Hotfix should appear in master branch ASAP and will be part of U-Boot 2022.04 release. Ideally please test this hotfix, to ensure that it will be fixed in 2022.04.

 

On 3/27/2022 at 10:21 AM, Heisath said:

 

I think the uboot and atf should be built with aarch, the wtmi with gnueabi. See: 

https://gitlab.nic.cz/turris/mox-boot-builder

 

TF-A and U-Boot is 64-bit ARM code and therefore must be built with aarch64 cross compiler. WTMI firmware (including the new one in mox-boot-builder repo) is 32-bit ARM code and must be built with armv7 cross compiler for Cortex M3. It does not matter if you use softfp or hardfp or linux or gnueabi cross toolchain as firmware is standalone freestanding code and Makefiles override all CPU / arch gcc flags to use correct one. together with ignoring / skipping system pre-compiled CRT code (which is gnueabi/softfp/hardfp specific). So it always should generate correct code or throw compile errors (when compiler does not support required code generation).

 

On 3/26/2022 at 11:26 PM, ManoftheSea said:

I also noted the TF-A instructions call for libcrypto++-dev, which is not part of the pre-reqs installed on the host system (as far as I know).  Does that go in the big list in lib/general.sh ?

 

See TF-A documentation. You can use either precompiled crypto++ libraries (e.g. provided by OS by libcrypto++-dev) or you can compile crypto++ libraries from sources as part of build process. crypto++ libraries are just dependency for host tool which generate flashable A3720 firmware image and it is your choice which version of crypto++ libraries do you want to use. Somebody prefer to use system host pre-compiled libraries, somebody prefer to compile everything from sources.

Link to comment
Share on other sites

Quote

TIM-1.0                                                                         
WTMI-devel-18.12.1-e6bb176                                                      
WTMI: system early-init                                                         
SVC REV: 5, CPU VDD voltage: 1.050V                                             
NOTICE:  Booting Trusted Firmware                                               
NOTICE:  BL1: v1.5(release):1f8ca7e (Marvell-devel-18.12.2)                     
NOTICE:  BL1: Built : 16:26:08, May 21 2019                                     
NOTICE:  BL1: Booting BL2                                                       
NOTICE:  BL2: v1.5(release):1f8ca7e (Marvell-devel-18.12.2)                     
NOTICE:  BL2: Built : 16:26:10, May 21 2019                                     
NOTICE:  BL1: Booting BL31                                                      
NOTICE:  BL31: v1.5(release):1f8ca7e (Marvell-devel-18.12.2)                    
NOTICE:  BL31: Built : 16:26:13                                                 
                                                                                
U-Boot 2018.03-devel-18.12.3-gc9aa92c-armbian (Feb 20 2019 - 09:45:04 +0100)    
                                                                                
Model: Marvell Armada 3720 Community Board ESPRESSOBin                          
       CPU     800 [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 down                                                               
MMC:   sdhci@d0000: 0, sdhci@d8000: 1                                           
Loading Environment from SPI Flash... SF: Detected mx25u3235f with page size 25B
OK                                                                              
Model: Marvell Armada 3720 Community Board ESPRESSOBin                          
Net:   eth0: neta@30000 [PRIME]                                                 
Hit any key to stop autoboot:  0                                                
starting USB...                                                                 
USB0:   Register 2000104 NbrPorts 2                                             
Starting the controller                                                         
USB XHCI 1.00                                                                   
USB1:   USB EHCI 1.00                                                           
scanning bus 0 for devices... 1 USB Device(s) found                             
scanning bus 1 for devices... 2 USB Device(s) found                             
       scanning usb for storage devices... 1 Storage Device(s) found            
/                                                                               
** File not found /boot.scr **                                                  
## Executing script at 06d00000                                                 
Wrong image format for "source" command                                         
/boot/                                                                          
1000 bytes read in 27 ms (36.1 KiB/s)                                           
## Executing script at 06d00000                                                 
194 bytes read in 10 ms (18.6 KiB/s)                                            
21899776 bytes read in 625 ms (33.4 MiB/s)                                      
7702347 bytes read in 240 ms (30.6 MiB/s)                                       
** File not found /boot/dtb/marvell/armada-3720-community.dtb **                
11618 bytes read in 17 ms (667 KiB/s)                                           
## Loading init Ramdisk from Legacy Image at 01100000 ...                       
   Image Name:   uInitrd                                                        
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)                  
   Data Size:    7702283 Bytes = 7.3 MiB                                        
   Load Address: 00000000                                                       
   Entry Point:  00000000                                                       
   Verifying Checksum ... OK                                                    
## Flattened Device Tree blob at 06000000                                       
   Booting using the fdt blob at 0x6000000                                      
   Loading Ramdisk to 3eed2000, end 3f62a70b ... OK                             
   Using Device Tree in place at 0000000006000000, end 0000000006005d61         
                                                                                
Starting kernel ...                                                             
                                                                                
[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]          
[    0.000000] Linux version 5.15.31-mvebu64 (root@upquark) (aarch64-linux-gnu-2
[    0.000000] Machine model: Globalscale Marvell ESPRESSOBin Board             
[    0.000000] earlycon: ar3700_uart0 at MMIO 0x00000000d0012000 (options '')   
[    0.000000] printk: bootconsole [ar3700_uart0] enabled                       
Loading, please wait...                                                         
Starting version 247.3-7                                 

Old u-boot, but new kernel.

 

Quote

Marvell>> bubt usr/lib/linux-u-boot-current-espressobin_22.05.0h-image-DDR4-1g8b
Burning U-BOOT image "usr/lib/linux-u-boot-current-espressobin_22.05.0-trunk_ar"
USB0:   Register 2000104 NbrPorts 2
Starting the controller
USB XHCI 1.00
USB1:   USB EHCI 1.00
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 1 for devices... 2 USB Device(s) found
Image checksum...OK!
SF: Detected mx25u3235f with page size 256 Bytes, erase size 64 KiB, total 4 MiB
Erasing 1179648 bytes (18 blocks) at offset 0 ...Done!
Writing 1133380 bytes from 0x8000000 to offset 0 ...Done!
Marvell>> reboot
Unknown command 'reboot' - try 'help'
Marvell>> reset
resetting ...


TIM-1.0
mv_ddr-devel-g251bc63 DDR4 16b 1GB 1CS
WTMI-devel-18.12.1-1d97715
WTMI: system early-init
SVC REV: 5, CPU VDD voltage: 1.143V
Setting clocks: CPU 1000 MHz, DDR 800 MHz
CZ.NIC's Armada 3720 Secure Firmware 53d2a1c-dirty (Mar 27 2022 00:46:52)
Running on ESPRESSObin
NOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v2.6(release):c43641eb
NOTICE:  BL1: Built : 19:10:59, Mar 27 2022
NOTICE:  BL1: Booting BL2
NOTICE:  BL2: v2.6(release):c43641eb
NOTICE:  BL2: Built : 19:10:59, Mar 27 2022
NOTICE:  BL1: Booting BL31
NOTICE:  BL31: v2.6(release):c43641eb
NOTICE:  BL31: Built : 19:10:59, Mar 27 2022


U-Boot 2022.01-armbian (Mar 27 2022 - 19:08:15 +0000)

DRAM:  1 GiB
WDT:   Not starting watchdog-timer@8300
Comphy chip #0:
Comphy-0: USB3_HOST0    5 Gbps    
Comphy-1: PEX0          2.5 Gbps  
Comphy-2: SATA0         5 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: Link down
MMC:   sdhci@d0000: 0, sdhci@d8000: 1
Loading Environment from SPIFlash... SF: Detected mx25u3235f with page size 256B
OK
Model: Globalscale Marvell ESPRESSOBin Board
Net:   eth0: neta@30000 [PRIME]
Hit any key to stop autoboot:  0
starting USB...
Bus usb@58000: Register 2000104 NbrPorts 2
Starting the controller
USB XHCI 1.00
Bus usb@5e000: USB EHCI 1.00
scanning bus usb@58000 for devices... 1 USB Device(s) found
scanning bus usb@5e000 for devices... 2 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
/
Failed to load '/boot.scr'
## Executing script at 06d00000
Wrong image format for "source" command
/boot/
1003 bytes read in 2 ms (489.3 KiB/s)
## Executing script at 06d00000
243 bytes read in 1 ms (237.3 KiB/s)
21899776 bytes read in 632 ms (33 MiB/s)
7702347 bytes read in 224 ms (32.8 MiB/s)
Failed to load '/boot/dtb/marvell/armada-3720-community.dtb'
11646 bytes read in 1 ms (11.1 MiB/s)
## Loading init Ramdisk from Legacy Image at 01100000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    7702283 Bytes = 7.3 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 06000000
   Booting using the fdt blob at 0x6000000
   Loading Ramdisk to 3f3a4000, end 3fafc70b ... OK
   Using Device Tree in place at 0000000006000000, end 0000000006005d7d

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[    0.000000] Linux version 5.15.31-mvebu64 (root@upquark) (aarch64-linux-gnu-2
[    0.000000] Machine model: Globalscale Marvell ESPRESSOBin Board V7
[    0.000000] earlycon: ar3700_uart0 at MMIO 0x00000000d0012000 (options '')
[    0.000000] printk: bootconsole [ar3700_uart0] enabled
Loading, please wait...
Starting version 247.3-7

Followed by testing... what's up with these cpu frequencies?

Quote

root@electroweak:~# 7za b

7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs LE)

LE
CPU Freq: 64000000 64000000 - - - 256000000 512000000 1024000000 2048000000

RAM size:     983 MB,  # CPU hardware threads:   2
RAM usage:    441 MB,  # Benchmark threads:      2

                       Compressing  |                  Decompressing
Dict     Speed Usage    R/U Rating  |      Speed Usage    R/U Rating
         KiB/s     %   MIPS   MIPS  |      KiB/s     %   MIPS   MIPS

22:        886   154    559    863  |      21247   197    921   1814
23:        875   155    575    893  |      20877   197    919   1807
24:        867   156    598    933  |      20573   197    918   1806
25:        832   155    613    950  |      20032   196    910   1783
----------------------------------  | ------------------------------
Avr:             155    586    910  |              197    917   1803
Tot:             176    752   1356
root@electroweak:~#

 

Link to comment
Share on other sites

On 3/27/2022 at 2:38 PM, Pali said:

This is a bug in U-Boot for which I sent a hotfix recently: http://patchwork.ozlabs.org/project/uboot/patch/20220323161942.7308-1-pali@kernel.org/ Hotfix should appear in master branch ASAP and will be part of U-Boot 2022.04 release. Ideally please test this hotfix, to ensure that it will be fixed in 2022.04.

How could the mainline sources be patched with this hotfix?

 

armbian-truncate-logs doesn't execute resulting in full /var/log pretty quickly.

:/usr/lib/armbian# ./armbian-truncate-logs
./armbian-truncate-logs: 18: /etc/default/armbian-ramlog: Syntax error: "(" unexpected

Line 18 points to a blank one

:/usr/lib/armbian# vi armbian-truncate-logs
#!/bin/sh
#
# Copyright (c) Authors: https://www.armbian.com/authors
#
# This file is licensed under the terms of the GNU General Public
# License version 2. This program is licensed "as is" without any
# warranty of any kind, whether express or implied.
#
# truncate, save and clean logs if they get over 75% of the /var/log size
# working only when armbian-ramlog is enabled

treshold=75 # %
JOURNAL_SIZE=5M # size to shrink systemd-journal

[ -f /etc/default/armbian-ramlog ] && . /etc/default/armbian-ramlog

[ "$ENABLED" != true ] && exit 0
										<<-- this is line 18
logusage=$(df /var/log/ --output=pcent | tail -1 |cut -d "%" -f 1)
if [ $logusage -ge $treshold ]; then
    # write to SD

Expressions before and after line 18 look good and execute individually well.

Sadly enough the errors are not reported in journal files. It took me some time to discover it.

Could somebody figure out where the error comes from?

 

Besides, I've found, that journald.conf settings are not taking effect on limiting logging capacity.

 armbian# cat /etc/systemd/journald.conf
# See journald.conf(5) for details.
[Journal]
..
SystemMaxUse=20M	<<- this option is set by armbian-zram-config
SystemKeepFree=10M	<<- set manually to keep the min. /var/log space available

None of the above options are respected resulting in growing  /var/log/journal/

Link to comment
Share on other sites

3 hours ago, Heisath said:

 you did something https://armbian.atlassian.net/browse/AR-445

Maybe it is not enough? 

This is a different issue.  Operand below from the script executes without error on its own.

 [ -d /var/log/journal ] && journalctl --vacuum-size=5M

The current error comes from some sort of syntax error in the script  as it explicitly raises :

Syntax error: "(" unexpected

 

Link to comment
Share on other sites

2 hours ago, y52 said:

This is a different issue.  Operand below from the script executes without error on its own.

 [ -d /var/log/journal ] && journalctl --vacuum-size=5M

The current error comes from some sort of syntax error in the script  as it explicitly raises :

Syntax error: "(" unexpected

 

 

yep OMG i keep on fixing it for-myself on my boxes and forgetting to upstream so sorry....   

https://github.com/armbian/build/pull/3603

Link to comment
Share on other sites

7 hours ago, lanefu said:

yep OMG i keep on fixing it for-myself on my boxes and forgetting to upstream so sorry....   

https://github.com/armbian/build/pull/3603

This fix is incomplete. It fixes only XTRA_RSYNC_FROM=() procedure declaration in /etc/default/armbian-ramlog

But this procedure IS NOT called in armbian-truncate-logs :

/usr/lib/armbian# vi armbian-truncate-logs
...
# truncate, save and clean logs if they get over 75% of the /var/log size
# working only when armbian-ramlog is enabled

treshold=75 # %
JOURNAL_SIZE=5M # size to shrink systemd-journal

[ -f /etc/default/armbian-ramlog ] && . /etc/default/armbian-ramlog

[ "$ENABLED" != true ] && exit 0

logusage=$(df /var/log/ --output=pcent | tail -1 |cut -d "%" -f 1)
if [ $logusage -ge $treshold ]; then
    # write to SD
    /usr/lib/armbian/armbian-ramlog write >/dev/null 2>&1
    # rotate logs on "disk"
    /usr/sbin/logrotate --force /etc/logrotate.conf
    # truncate
    /usr/bin/find /var/log -name '*.log' -or -name '*.xz' -or -name 'lastlog' -or -name 'messages' -or -name 'debug' -or -name 'syslog' | xargs -r truncate --size 0
    /usr/bin/find /var/log -name 'btmp' -or -name 'wtmp' -or -name 'faillog' -or -name 'firewalld' | xargs -r truncate --size 0
    /usr/bin/find /var/log -name 'mail.err' -or -name 'mail.info' -or -name 'mail.warning' | xargs -r truncate --size 0
    # remove
    /usr/bin/find /var/log -name '*.[0-9]' -or -name '*.gz' | xargs -r rm -f
    # vacuum systemd-journald
    [ -d /var/log/journal ] && journalctl --vacuum-size=${JOURNAL_SIZE}
fi

Thus armbian-truncate-logs still produces the same error :

 

/usr/lib/armbian# ./armbian-truncate-logs
./armbian-truncate-logs: 24: /etc/default/armbian-ramlog: Syntax error: "(" unexpected

Despite that variables are well parsed from armbian-ramlog :

armbian# [ -f /etc/default/armbian-ramlog ] && . /etc/default/armbian-ramlog
armbian# echo $USE_RSYNC
true
armbian# echo $SIZE
50M

armbian-truncate-logs script doesn't contain XTRA_RSYNC_FROM=() procedure.

 

Could you show both fixed /usr/lib/armbian/armbian-truncate-logs script and /etc/default/armbian-ramlog ? 

Link to comment
Share on other sites

5 hours ago, y52 said:

Could you show both fixed /usr/lib/armbian/armbian-truncate-logs script and /etc/default/armbian-ramlog ? 

 

Oh!  Thanks for clarifying.

 

Will try to get to it but running out of time.  Feel free to make changes and comment on the open PR.

Link to comment
Share on other sites

On 3/30/2022 at 12:16 AM, lanefu said:

Oh!  Thanks for clarifying.

 

Will try to get to it but running out of time.  Feel free to make changes and comment on the open PR.

I've made some advancement in debugging "armbian-ramlog & armbian-truncate-log" complex.

Your /usr/lib/armbian/armbian-ramlog has a syntax error in the array expression 

 ${XTRA_RSYNC_TO[@]+"${XTRA_RSYNC_TO[@]}"} 

The 1st array lacks a closing } curly braces. Secondly, I can't figure out, why the same array is duplicated.

Even if you parse a variable XTRA_RSYNC_TO=(--delete) from /etc/default/armbian-ramlog, it will result in :

--delete+--delete

Another problem comes, when you call 

/usr/lib/armbian/armbian-ramlog write >/dev/null 2>&1

from /usr/lib/armbian/armbian-truncate-logs. It actually produces the error:

# /usr/lib/armbian/armbian-truncate-logs
/usr/lib/armbian/armbian-truncate-logs: 23: /etc/default/armbian-ramlog: Syntax error: "(" unexpected

I believe there is a syntax error in the way the call is made, where the XTRA_RSYNC_TO=(--delete) variable is not accounted for.

Could you give it a glance?

Otherwise, if the XTRA_RSYNC_TO=(--delete) variable is remarked in /etc/default/armbian-ramlog

and "--delete" option is hard coded in /usr/lib/armbian/armbian-ramlog, the complex starts running without raising exceptions.

Link to comment
Share on other sites

@PaliI've been trying a couple different toolchains.  It looks like passing `./compile.sh UBOOT_USE_GCC="> 10.0"` causes:

 

lib/display_options.c: In function 'print_freq':
lib/display_options.c:58:9: internal compiler error: Illegal instruction
   58 |         unsigned long d = 1e9;
      |         ^~~~~~~~
0x1732310 diagnostic_impl(rich_location*, diagnostic_metadata const*, int, char const*, __va_list_tag (*) [1], diagnostic_t)
    ???:0
0x1732f96 internal_error(char const*, ...)
    ???:0
0xc24faf crash_signal(int)
    ???:0
0x1935b09 __gmpn_mul_basecase
    ???:0

 

with arm toolchain 11.2.1 on uboot 2022.01 or 2022.04

Link to comment
Share on other sites

15 hours ago, ManoftheSea said:

I believe the instructions for u-boot haven't changed.  Do you have a specific suggestion?

Here are the instructions from the download page (https://www.armbian.com/espressobin/):

"Version 7 EspressoBIN (identifiable by sata power connection instead of molex) has ethernet ports in the reverse order.  This can be fixed by passing the espressobin-v7.dtb in the boot script at /boot/boot.cmd"


Does this still hold, or there is one uboot now that may identify different versions of the board and memory?

"manual flashing to latest u-boot is mandatory! Download the right boot flash for your board: 512,1G,2G, number of RAM chips (if your board is older than a few months it has two RAM chips – one on each side of the PCB opposite to each other. Recent 1GB models have only one chip at the bottom) and appropriate memory speeds. You can obtain numbers from the current boot prompt. Also choose right memory: ddr3 are for V3-V5 EspressoBin’s (i.e. V5, 1g-2cs) and ddr4 images are for v7 EspressoBin’s. Insert ‘ddr3’ or ‘ddr4’ into the bubt command string. Copy this flash-image-ddr3/ddr4-MEM-RAM_CHIPS-CPU_DDR.bin to your FAT formatted USB key, plug it into USB3.0 port and execute from u-boot prompt:"


Is this mandatory now? If yes, the download page does not redirect correctly

"In case you experience instability reflash boot loader with lower CPU speed values!"


Probably not relevant anymore?

"Updated u-boot needs new default boot environment and new boot script (overwrite the one on your /boot media – needed only if you upgrade from < v5.59). This is what you need to copy/paste into u-boot prompt:"


Probably not relevant anymore?


The rest seem to be still relevant.
 

"Boot priority with this script is: 1. USB, 2. SATA, 3. SD card, 4. eMMC
If you manage to crash your SPI flash, get appropriate files and proceed with one of the rescue options: SATA, UART,
UART console is broken on legacy kernel 4.14.y
if you need USB2 port on your mPCI slot (for Bluetooth or 4G/LTE modems) you need to move both jumpers near to the USB2 port. Position for this function is: away from the port."

 

Link to comment
Share on other sites

As far as I've been able to test, yes, the v7 needs the specific dtb passed to linux.  Or, tell me how I might test it, and I will change the instruction to what I am able to discover.

 

@PaliIf someone is upgrading, they need the eth address loaded since it was previously wiped out, right?  I have not been able to use fw_printenv to read mtd, saying only "cannot read environment".  My mtd1 is "empty", all zeros.  This ought to be able to read the u-boot environment, and write it, so as to allow the running linux kernel to correct the u-boot environment (if that is still needed - such as restoring the previously wiped eth address).  Can you help me figure out why?  I have a /etc/fw_env.config with a single line pointed at /dev/mtd1, a size of 0x10000, flash sector size of 0x1000, sectors 0x10.

 

@lampra I don't know if upgrading from the original u-boot remains mandatory, but I would think it does.  I do not know what is gained from more recent u-boot, though I have tested and find it functional.  I believe something was said about removing the heat sink to find out the truly correct speed to flash.  Should we instead say the 1000-800 is the first thing to try?

 

As for the download link, yes, there's something wrong with the mirrors.

 

If I'm updating my u-boot from having this boot environment, does flashing 2022.01 or .04 rewrite the environment for me, or do I need to make some kind of custom change?  Particularly if I've previously wiped out my eth address?

 

Both of you, give me your suggestion on what ought to be on the page.  I will test, and I will update.

Link to comment
Share on other sites

4 hours ago, ManoftheSea said:

@PaliIf someone is upgrading, they need the eth address loaded since it was previously wiped out, right?  I have not been able to use fw_printenv to read mtd, saying only "cannot read environment".  My mtd1 is "empty", all zeros.  This ought to be able to read the u-boot environment, and write it, so as to allow the running linux kernel to correct the u-boot environment (if that is still needed - such as restoring the previously wiped eth address).  Can you help me figure out why?  I have a /etc/fw_env.config with a single line pointed at /dev/mtd1, a size of 0x10000, flash sector size of 0x1000, sectors 0x10.

 

Before upgrading U-Boot, in case your MAC addresses were not wiped out, you should print them in U-Boot console and remember/backup them. After upgrading U-Boot to the new version, you should reset enviroment to default. Latest U-Boot preserve MAC addresses variables. But if your U-Boot version uses different storage offset for env variables then all env variables (including MAC addresses) would be lost. So that is why backup is required. Some Espressobin boards have MAC addresses printed on the sticker/label, which is suitable backup.

 

To access env variables from Linux system, you need to set /etc/fw_env.config correctly. With new U-Boot version, partition number is available in /proc/mtd at u-boot-env line and offset is always zero. Old U-Boot versions have it different.

Link to comment
Share on other sites

U-Boot is part of the firmware package and cannot be flashed separately on Espressobin. So you always have to flash full firmware, not just U-Boot. There are 3 variants of Armada 3720 CPU used in Espressobin: 800 MHz, 1 GHz and 1.2 GHz. And more variants of soldered DDR chips on Espressobin. You have to choose firmware which matches your CPU and DDR (3 or 4 and correct size). If you do not know what you have, you can look at chips markings to recognize it (so in this case you need to look what is under headsink). You can also look at frequences, DDR sizes and other debug information on the serial console to deduce it (but this works only in case you already have running correct firmware; factory firmware should be correct).

Link to comment
Share on other sites

I have discovered a difference in my /boot/boot.cmd and the latest image: there was an `mtdparts=spi0.0:1536k(uboot),64k(uboot-environment),-(reserved)` in the cmdline.  This probably caused my issue with fw_printenv.

 

The /boot/boot.cmd loads the community and then the espressobin dtb in the same location.  Doesn't this just overwrite the community dtb?  But still, it appears to be up to the user to select whether they have a v5 or v7 espressobin, and thus the user needs to manually adjust this line.

 

I don't believe /etc/fw_env.config is being populated - what package ought to?

 

And it appears the reset to default environment gives me a "criptaddr" rather than a "scriptaddr".  I'm rebuilding/flashing/resetting to really confirm this.

Link to comment
Share on other sites

Recording results of testing: latest build of image (2022.05.0-trunk with kernel 5.15.32) and u-boot 2022.04

I ran `env default -a` at the u-boot prompt.  This results in:

Spoiler

boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
boot_efi_binary=load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootaa64.efi; if fdt addr ${fdt_addr_r}; then bootefi ${kernei
boot_efi_bootmgr=if fdt addr ${fdt_addr_r}; then bootefi bootmgr ${fdt_addr_r};else bootefi bootmgr;fi
boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}${boot_syslinux_conf}
boot_net_usb_start=usb start
boot_pci_enum=pci enum
boot_prefixes=/ /boot/
boot_script_dhcp=boot.scr.uimg
boot_scripts=boot.scr.uimg boot.scr
boot_syslinux_conf=extlinux/extlinux.conf
boot_targets=usb0 mmc1 mmc0
bootcmd=run distro_bootcmd
bootcmd_dhcp=devtype=dhcp; run boot_net_usb_start; run boot_pci_enum; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi;seten;
bootcmd_mmc0=devnum=0; run mmc_boot
bootcmd_mmc1=devnum=1; run mmc_boot
bootcmd_pxe=run boot_net_usb_start; run boot_pci_enum; dhcp; if pxe get; then pxe boot; fi
bootcmd_scsi0=devnum=0; run scsi_boot
bootcmd_usb0=devnum=0; run usb_boot
bootfstype=ext4
criptaddr=0x6d00000
distro_bootcmd=scsi_need_init=; setenv nvme_need_init; for target in ${boot_targets}; do run bootcmd_${target}; done
efi_dtb_prefixes=/ /dtb/ /dtb/current/
eth1addr=00:51:82:11:22:01
eth2addr=00:51:82:11:22:02
eth3addr=00:51:82:11:22:03
ethaddr=00:51:82:11:22:00
fdt_addr=0x6f00000
fdt_addr_r=0x6f00000
fdtfile=marvell/armada-3720-espressobin-v7.dtb
kernel_addr=0x7000000
kernel_addr_r=0x7000000
load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}${efi_fdtfile}
mmc_boot=if mmc dev ${devnum}; then devtype=mmc; run scan_dev_for_boot_part; fi
nvme_boot=run boot_pci_enum; run nvme_init; if nvme dev ${devnum}; then devtype=nvme; run scan_dev_for_boot_part; fi
nvme_init=if ${nvme_need_init}; then setenv nvme_need_init false; nvme scan; fi
pxefile_addr_r=0x6e00000
ramdisk_addr_r=0xa000000
sata_boot=if sata dev ${devnum}; then devtype=sata; run scan_dev_for_boot_part; fi
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_d;
scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist
scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; for prefix in ${efi_dtb_prefixes}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${e
scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${boot_syslinux_conf}; then echo Found ${prefix}${boot_syslinux_coi
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boote
scsi_boot=run boot_pci_enum; run scsi_init; if scsi dev ${devnum}; then devtype=scsi; run scan_dev_for_boot_part; fi
scsi_init=if ${scsi_need_init}; then scsi_need_init=false; scsi scan; fi
usb_boot=usb start; if usb dev ${devnum}; then devtype=usb; run scan_dev_for_boot_part; fi

(Some lines are cut off, sorry)

 

To get a functional boot, to these I needed to run

set boot_interface mmc
set image_name Image
set initrd_image uInitrd
set initrd_addr 0x1100000
set devnum 0
set scriptaddr $criptaddr

 

I believe these could functionally be put into the armbian boot.scr rather than needing to overwrite u-boot. 

 

Here is the functioning env settings as linux sees them from fw_printenv:

Spoiler

boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
boot_efi_binary=load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootaa64.efi; if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r};else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi
boot_efi_bootmgr=if fdt addr ${fdt_addr_r}; then bootefi bootmgr ${fdt_addr_r};else bootefi bootmgr;fi
boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}${boot_syslinux_conf}
boot_interface=mmc
boot_net_usb_start=usb start
boot_pci_enum=pci enum
boot_prefixes=/ /boot/
boot_script_dhcp=boot.scr.uimg
boot_scripts=boot.scr.uimg boot.scr
boot_syslinux_conf=extlinux/extlinux.conf
boot_targets=mmc1 mmc0 usb0 scsi0 pxe dhcp
bootargs= root=UUID=24397a2d-1d66-4bb9-a29f-337ac6b78f41 rootfstype=ext4 rootwait loglevel=1 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u
bootcmd=run distro_bootcmd
bootcmd_dhcp=devtype=dhcp; run boot_net_usb_start; run boot_pci_enum; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi;setenv efi_fdtfile ${fdtfile}; setenv efi_old_vci ${bootp_vci};setenv efi_old_arch ${bootp_arch};setenv bootp_vci PXEClient:Arch:00011:UNDI:003000;setenv bootp_arch 0xb;if dhcp ${kernel_addr_r}; then tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r}; else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi;fi;setenv bootp_vci ${efi_old_vci};setenv bootp_arch ${efi_old_arch};setenv efi_fdtfile;setenv efi_old_arch;setenv efi_old_vci;
bootcmd_mmc0=devnum=0; run mmc_boot
bootcmd_mmc1=devnum=1; run mmc_boot
bootcmd_pxe=run boot_net_usb_start; run boot_pci_enum; dhcp; if pxe get; then pxe boot; fi
bootcmd_scsi0=devnum=0; run scsi_boot
bootcmd_usb0=devnum=0; run usb_boot
bootfstype=ext4
criptaddr=0x6d00000
devnum=0
distro_bootcmd=scsi_need_init=; setenv nvme_need_init; for target in ${boot_targets}; do run bootcmd_${target}; done
efi_dtb_prefixes=/ /dtb/ /dtb/current/
emmc_fix=off
eth1addr=0e:02:7a:2d:f1:98
eth2addr=f0:ad:4e:09:08:f4
eth3addr=f0:ad:4e:09:08:f5
ethact=neta@30000
ethaddr=F0:AD:4E:09:08:F3
fdt_addr=0x6f00000
fdt_addr_r=0x6f00000
fdt_name=dtb/marvell/armada-3720-espressobin-v7.dtb
fdtaddr=6f00000
fdtfile=marvell/armada-3720-espressobin-v7.dtb
fileaddr=6f00000
filesize=2d7e
image_name=Image
initrd_addr=0x1100000
initrd_image=uInitrd
kernel_addr=0x7000000
kernel_addr_r=0x7000000
load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}${efi_fdtfile}
mmc_boot=if mmc dev ${devnum}; then devtype=mmc; run scan_dev_for_boot_part; fi
nvme_boot=run boot_pci_enum; run nvme_init; if nvme dev ${devnum}; then devtype=nvme; run scan_dev_for_boot_part; fi
nvme_init=if ${nvme_need_init}; then setenv nvme_need_init false; nvme scan; fi
pxefile_addr_r=0x6e00000
ramdisk_addr_r=0xa000000
rootdev=UUID=24397a2d-1d66-4bb9-a29f-337ac6b78f41
rootfstype=ext4
sata_boot=if sata dev ${devnum}; then devtype=sata; run scan_dev_for_boot_part; fi
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;run scan_dev_for_efi;
scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done; setenv devplist
scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; for prefix in ${efi_dtb_prefixes}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${efi_fdtfile}; then run load_efi_dtb; fi;done;run boot_efi_bootmgr;if test -e ${devtype} ${devnum}:${distro_bootpart} efi/boot/bootaa64.efi; then echo Found EFI removable media binary efi/boot/bootaa64.efi; run boot_efi_binary; echo EFI LOAD FAILED: continuing...; fi; setenv efi_fdtfile
scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${boot_syslinux_conf}; then echo Found ${prefix}${boot_syslinux_conf}; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
scriptaddr=0x6d00000
scsi_boot=run boot_pci_enum; run scsi_init; if scsi dev ${devnum}; then devtype=scsi; run scan_dev_for_boot_part; fi
scsi_init=if ${scsi_need_init}; then scsi_need_init=false; scsi scan; fi
spi_workaround=off
usb_boot=usb start; if usb dev ${devnum}; then devtype=usb; run scan_dev_for_boot_part; fi
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u
verbosity=1

 

Link to comment
Share on other sites

My understanding from a user point of view is that if one needs to boot from media other than sd card, she/he needs to back up the uboot environment and then flash a firmware according to CPU and DDR (analog to the named trusted firmware supplementary files provided by openwrt here).

SD card images (with different .dtb for v5 and v7)  will probably have boot parameters set in boot.scr which a user may override.

 

So I would propose, with the permission of @Pali, to include his two previous posts in the download page. Then, firmware files would be the only thing missing.

 

As I see (please correct me if I am wrong) the default environment supports distroboot.

Just one question; what is preventing armbian from being able to support distroboot (other than lack of resources) so that a user does not have to tweak the uboot environment in order to boot from sata?

Link to comment
Share on other sites

It looks to me that you're right, the default environment wants to support distroboot.  With a few tweaks in the boot.scr, it seems like we can not break old installs, while allowing new installs to have a boot.scr detected on a disk/ssd.  Of course, I've only known about distroboot for 6 hours now. 

 

As far as matching RAM type and processor max speed, that's already on the download page, and still relevant, so we wouldn't change it.  We'd just need to make sure the files are available again, which I would like to resolve.  I will trim down the commands necessary to add to u-boot environment, possibly getting it only to "how to fix your ethaddr" for people upgrading.

 

Link to comment
Share on other sites

Why yes, we can support distroboot, and in a way that does not break people who haven't upgraded uboot!

boot.scr.uimg, which should be processed into boot.scr.uimg - this differently named file will be picked up by the distroboot commands, but not by older modified u-boot.  (I think.)

Spoiler

# DO NOT EDIT THIS FILE
#
# Please edit /boot/armbianEnv.txt to set supported parameters
#

load ${devtype} ${devnum}:1 ${scriptaddr} ${prefix}armbianEnv.txt
env import -t ${scriptaddr} ${filesize}

setenv bootargs "$console root=${rootdev} rootfstype=${rootfstype} rootwait loglevel=${verbosity} usb-storage.quirks=${usbstoragequirks} ${extraargs}"

load $devtype ${devnum}:${distro_bootpart} $kernel_addr_r ${prefix}Image
load $devtype ${devnum}:${distro_bootpart} $ramdisk_addr_r ${prefix}uInitrd
load $devtype ${devnum}:${distro_bootpart} $fdt_addr_r ${prefix}dtb/$fdtfile

booti $kernel_addr_r $ramdisk_addr_r $fdt_addr_r
# mkimage -C none -A arm -T script -d /boot/boot.cmd.uimg /boot/boot.scr.uimg

 

armbianEnv.txt configures the rootdev already.  Someone, probably me, needs to add the rootfstype to that same file.

 

But it'd probably be better still if we used FIT images, whatever those are.

 

Link to comment
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
Reply to this topic...

×   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...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines