Heisath Posted March 13, 2022 Posted March 13, 2022 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. 0 Quote
y52 Posted March 20, 2022 Posted March 20, 2022 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 0 Quote
ManoftheSea Posted March 26, 2022 Posted March 26, 2022 (edited) 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 March 26, 2022 by ManoftheSea addl. detail 0 Quote
y52 Posted March 27, 2022 Posted March 27, 2022 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? 0 Quote
Heisath Posted March 27, 2022 Posted March 27, 2022 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 0 Quote
Pali Posted March 27, 2022 Posted March 27, 2022 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. 0 Quote
ManoftheSea Posted March 27, 2022 Posted March 27, 2022 I have been able to compile wtmi now with all of 7.4.1, 8.3, 9.2, and 11.2. Should we prefer the oldest toolchain that works, or the newest? 0 Quote
Heisath Posted March 27, 2022 Posted March 27, 2022 Newest please - don't want to keep the old stuff around. 0 Quote
ManoftheSea Posted March 28, 2022 Posted March 28, 2022 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:~# 0 Quote
y52 Posted March 28, 2022 Posted March 28, 2022 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/ 0 Quote
Heisath Posted March 29, 2022 Posted March 29, 2022 Above seems like a general armbian problem, not ebin specific. @lanefu you did something https://armbian.atlassian.net/browse/AR-445 Maybe it is not enough? 0 Quote
Pali Posted March 29, 2022 Posted March 29, 2022 19 hours ago, y52 said: On 3/27/2022 at 2:38 PM, Pali said: How could the mainline sources be patched with this hotfix? It is already in the u-boot master branch. 0 Quote
y52 Posted March 29, 2022 Posted March 29, 2022 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 0 Quote
lanefu Posted March 29, 2022 Posted March 29, 2022 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 0 Quote
y52 Posted March 29, 2022 Posted March 29, 2022 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 ? 0 Quote
lanefu Posted March 29, 2022 Posted March 29, 2022 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. 0 Quote
y52 Posted March 31, 2022 Posted March 31, 2022 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. 1 Quote
ManoftheSea Posted April 6, 2022 Posted April 6, 2022 @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 0 Quote
lampra Posted April 11, 2022 Posted April 11, 2022 @Heisath @ManoftheSeaAfter espressobin (v5 & v7) was added to supported targets, and by the time that it will hit the download page, It seems to me that the download page would need updated instructions at least for uboot 0 Quote
ManoftheSea Posted April 11, 2022 Posted April 11, 2022 I believe the instructions for u-boot haven't changed. Do you have a specific suggestion? 0 Quote
Pali Posted April 11, 2022 Posted April 11, 2022 In new U-Boot you should not change addr and boot env variables. 0 Quote
lampra Posted April 12, 2022 Posted April 12, 2022 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." 0 Quote
ManoftheSea Posted April 12, 2022 Posted April 12, 2022 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. 0 Quote
Pali Posted April 12, 2022 Posted April 12, 2022 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. 0 Quote
Pali Posted April 12, 2022 Posted April 12, 2022 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). 0 Quote
ManoftheSea Posted April 12, 2022 Posted April 12, 2022 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. 0 Quote
ManoftheSea Posted April 12, 2022 Posted April 12, 2022 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 0 Quote
lampra Posted April 12, 2022 Posted April 12, 2022 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? 0 Quote
ManoftheSea Posted April 13, 2022 Posted April 13, 2022 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. 0 Quote
ManoftheSea Posted April 13, 2022 Posted April 13, 2022 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. 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.