Pali Posted February 10, 2022 Share Posted February 10, 2022 8 minutes ago, y52 said: It appears, that it overrides u-boot MAC assignments. Yea... it is known that Armbian wants users to not use correct MAC addresses. I have reported it many times and the last thing which was done, was removal of permanent MAC addresses from the board, which is totally insane... 0 Quote Link to comment Share on other sites More sharing options...
y52 Posted February 10, 2022 Share Posted February 10, 2022 6 hours ago, Pali said: Maybe it would be a good idea to write some document / wiki page how to exactly install Debian on SD card for Espressobin... Probably all those reasons above will initiate migration to pure Debian distro. So, practical experience is welcome now. Anyway, it is necessary granting Armbian credit popularizing arm platform and introducing Espressobin and Marvell boards to broad public! It could be understood, that they lack necessary resources. 0 Quote Link to comment Share on other sites More sharing options...
Heisath Posted February 10, 2022 Share Posted February 10, 2022 As said many times before, we will gladly check and accept any PR to https://github.com/armbian/build which improves Espressobin. This can be MAC improvements, Uboot updates whatever. But we do lack the resources to do and test these changes ourselves. That is the reason we moved espressobin in the Armbian buildsystem to CSC, Community support. Some work seems to have been done here, https://github.com/armbian/build/pull/3453 feedback is welcome. BTW. @Pali thanks for your work on mvebu (clearfog) on the PCI mailing list, nice to see some of the Russel King patches finally making it's way to mainline. 0 Quote Link to comment Share on other sites More sharing options...
y52 Posted February 11, 2022 Share Posted February 11, 2022 20 hours ago, Pali said: Yea... it is known that Armbian wants users to not use correct MAC addresses. The permanent MAC address is not inherited to the bridged interface. It is assigned another value. If anyone wants to assign a permanent MAC to bridged i-face, it is necessary adding it to a section in /etc/systemd/network/10-br0.netdev [NetDev] Name=br0 Kind=bridge MACAddress=f0:ad:4e:xx:xx:xx <<-- The problem, which arrises afterwards, is that a permanent MAC somewhat leaks from lan0@eth0 or lan1@eth0 creating duplicate calls to dhcpd on an external server , offering another ip : Feb 11 14:38:11 essprv5 dhcpd[7419]: DHCPDISCOVER from f0:ad:4e:xx:xx:xx via lan Feb 11 14:38:11 essprv5 dhcpd[7419]: DHCPOFFER on 192.168.55.15 to f0:ad:4e:xx:xx:xx via lan Feb 11 14:39:16 essprv5 dhcpd[7419]: uid lease 192.168.55.205 for client f0:ad:4e:xx:xx:xx is duplicate on 192.168.55.0/24 If fact this MAC leak is independent whether bridged interface inherits or not permanent MAC. It leaks in both cases. Would it be possible to avoid this duplicate hit to dhcpd from both bridged and lan0/lan1 interfaces? 0 Quote Link to comment Share on other sites More sharing options...
Pali Posted February 11, 2022 Share Posted February 11, 2022 If you have configured bridge interface br0 based on lan0 and lan1 then you should not touch lan0 and lan1 and should not run on these interfaces any SW. On 2/10/2022 at 9:06 PM, Heisath said: As said many times before, we will gladly check and accept any PR to https://github.com/armbian/build Last time I did it, it was closed. Why should I do it again? Sorry, thanks, I will not spend my time with it again with something which would be closed/dropped. 0 Quote Link to comment Share on other sites More sharing options...
y52 Posted February 11, 2022 Share Posted February 11, 2022 5 minutes ago, Pali said: If you have configured bridge interface br0 based on lan0 and lan1 then you should not touch lan0 and lan1 and should not run on these interfaces any SW. I do not touch lan0 and lan1 in no way. They just leak on their own through a bridged sending duplicate lease messages : Feb 11 14:58:26 esprv5 dhcpd[7419]: uid lease 192.168.55.205 for client f0:ad:4e:xx:xx:xx is duplicate on 192.168.55.0/24 What could be a possible reason for the lan0 and lan1 being involved in dhcpd query? 0 Quote Link to comment Share on other sites More sharing options...
Pali Posted February 11, 2022 Share Posted February 11, 2022 Interesting... I do not know. Just in case did not lan0 and lan1 got configured some ip address? Or Is not dhcpd also listening (for some reason) also on lan0 and lan1? Or is not there some dangling lease (stored in disk lease file) which could conflict? I do not know how exaclty is dhcpd detecting these duplicates, but it smells like a loop in switching/networking. 0 Quote Link to comment Share on other sites More sharing options...
y52 Posted February 11, 2022 Share Posted February 11, 2022 13 minutes ago, Pali said: Just in case did not lan0 and lan1 got configured some ip address? Your guess have been just right! It was only in eth0 configuration, not in lan0 and lan1 : root@tiger:/etc/systemd/network# vi 10-eth0.network [Match] Name=eth0 [Network] #DHCP=ipv4 Once the last line remarked and # systemctl restart systemd-networkd.service I do not see new dhcp requests for the moment. 26 minutes ago, Pali said: As said many times before, we will gladly check and accept any PR to https://github.com/armbian/build The above could also be a good suggestion to improve Espressobin. The other issue is that /var/log is filling up very quickly even on an idle system. It was necessary to tweak : root@tiger:/var/log# vi /etc/systemd/journald.conf #SystemMaxUse=20M SystemMaxUse=15M #SystemMaxFiles=100 SystemMaxFiles=10 root@tiger# systemctl restart systemd-journald root@tiger# journalctl --disk-usage Archived and active journals take up 14.4M in the file system. 0 Quote Link to comment Share on other sites More sharing options...
Heisath Posted February 11, 2022 Share Posted February 11, 2022 1 hour ago, Pali said: Last time I did it, it was closed. Why should I do it again? Sorry, thanks, I will not spend my time with it again with something which would be closed/dropped. Understandable. Can you link me to the PR? I can't find it, and would check if I'm able to pick it up. 0 Quote Link to comment Share on other sites More sharing options...
Pali Posted February 11, 2022 Share Posted February 11, 2022 Just quick search in my emails found this link: https://github.com/armbian/build/issues/2861 And as @y52 pointed, file /boot/armbianEnv.txt has problems too. 0 Quote Link to comment Share on other sites More sharing options...
y52 Posted February 11, 2022 Share Posted February 11, 2022 On 2/10/2022 at 1:08 PM, Pali said: Maybe it would be a good idea to write some document / wiki page how to exactly install Debian on SD card for Espressobin... Does that practical experience exhaust the steps to install mainline Debian ? Install vanilla UEFI Debian for ESPRESSOBin https://gist.github.com/MakiseKurisu/7b2f4122f11ce551eecb9b52c568a5dd 0 Quote Link to comment Share on other sites More sharing options...
Igor Posted February 15, 2022 Share Posted February 15, 2022 On 2/11/2022 at 11:46 PM, y52 said: Install vanilla UEFI Debian for ESPRESSOBin UEFI arm64 Armbian images - if that helps in any way: https://www.armbian.com/uefi-arm64/ 0 Quote Link to comment Share on other sites More sharing options...
TRS-80 Posted February 15, 2022 Share Posted February 15, 2022 On 2/11/2022 at 3:09 PM, Pali said: Just quick search in my emails found this link: https://github.com/armbian/build/issues/2861 Yes, a PR was not sent, only an Issue was filed. Because ebin is CSC, the Issue was closed, although a PR would have been (and I imagine, still is) welcomed. Patches welcome... 0 Quote Link to comment Share on other sites More sharing options...
Heisath Posted February 16, 2022 Share Posted February 16, 2022 I created branch with Ebin improvements and PR https://github.com/armbian/build/pull/3498 This is still WIP. Feedback + help welcome. Currently building TF-A fails because: plat/marvell/armada/a3k/common/a3700_common.mk:148: *** "Platform 'a3700' for WTP image tool requires CRYPTOPP_PATH or CRYPTOPP_LIBDIR. Please set CRYPTOPP_PATH or CRYPTOPP_LIBDIR to point to the right directory". Stop. Got it working, see https://github.com/armbian/build/pull/3498 Compilation seems to work now. Waiting on feedback from ebin owners. armbianEnv.txt still needs adjustment! 1 Quote Link to comment Share on other sites More sharing options...
y52 Posted February 18, 2022 Share Posted February 18, 2022 I've connected ethernet cable from my provider's router to what I considered a WAN adapter on Espressobin v7 (a separate one, located close to the blue USB), while LAN cable was connected to the port in the middle. WAN interface was unable to obtain public address and Internet connection naturally didn't work. I am stunned at discovering, that WAN port is inverted with another port located near the white USB connecter (lan1). Once I inverted the cables WAN interface obtained DHCP lease from provider and established internet connection. I believe, that this particular physical ports position is relevant to Espressobin v5, but WAN and LAN1 are inverted in v7. If I'm understanding things correctly, the names of the ethernet ports on the espressobin come from the device tree - Specifically: port@1 { reg = <1>; label = "wan"; phy-handle = <&switch0phy0>; }; port@2 { reg = <2>; label = "lan0"; phy-handle = <&switch0phy1>; }; port@3 { reg = <3>; label = "lan1"; phy-handle = <&switch0phy2>; }; How could WAN and LAN1 be inverted in order to correspond to their physical placement? 0 Quote Link to comment Share on other sites More sharing options...
Pali Posted February 18, 2022 Share Posted February 18, 2022 Espressobin v5 has WAN port on different position as Espressobin v7. This is the fact (you can look into the official Espressobin manuals) and espressobin v7 DTS file has it reflected compared with espressobin v5 DTS file. 0 Quote Link to comment Share on other sites More sharing options...
y52 Posted February 19, 2022 Share Posted February 19, 2022 11 hours ago, Pali said: espressobin v7 DTS file has it reflected compared with espressobin v5 DTS file. Yes, you are right and thanks for looking into it. There exist several varieties of dtb : -rwxr-xr-x 1 root root 11K Aug 25 21:19 armada-3720-espressobin.dtb -rwxr-xr-x 1 root root 12K Aug 25 21:19 armada-3720-espressobin-emmc.dtb -rwxr-xr-x 1 root root 11K Aug 25 21:19 armada-3720-espressobin-v7.dtb and each board needs adjustments in boot.cmd. So I changed to: setenv fdt_name_a dtb/marvell/armada-3720-community.dtb #setenv fdt_name_b dtb/marvell/armada-3720-espressobin.dtb setenv fdt_name_b dtb/marvell/armada-3720-espressobin-v7.dtb followed by # mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr and reboot. Now physical port positions correspond to dtb settings and there is no confusion with cables. 0 Quote Link to comment Share on other sites More sharing options...
Heisath Posted February 19, 2022 Share Posted February 19, 2022 I want to add, that on ebin all ports are on the same switch IMHO. So WAN/LAN is no physical seperation but just logical. By the way, where you able to check out https://github.com/armbian/build/pull/3498 ? 0 Quote Link to comment Share on other sites More sharing options...
y52 Posted February 19, 2022 Share Posted February 19, 2022 1 hour ago, Heisath said: where you able to check out https://github.com/armbian/build/pull/3498 Could you be more specific if anything needs to be done. 0 Quote Link to comment Share on other sites More sharing options...
Heisath Posted February 19, 2022 Share Posted February 19, 2022 As stated in the PR. I do not own / have access to an Espressobin, so all changes in that branch are untested. It would be great if someone with an ebin could, git clone, checkout that PR branch (AR-775), use it to build an ebin image, burn that to sd card and test if the changes work. So modern uboot boots etc. 0 Quote Link to comment Share on other sites More sharing options...
y52 Posted February 19, 2022 Share Posted February 19, 2022 6 hours ago, Heisath said: git clone, checkout that PR branch (AR-775), use it to build an ebin image, burn that to sd card and test if the changes work Could you provide with more detailed directions for the above tasks, so that they could be executed? Our recent experience with @Pali building mainline u-boot could serve as a good example and practice. 0 Quote Link to comment Share on other sites More sharing options...
Pali Posted February 19, 2022 Share Posted February 19, 2022 10 hours ago, y52 said: So I changed to: setenv fdt_name_a dtb/marvell/armada-3720-community.dtb #setenv fdt_name_b dtb/marvell/armada-3720-espressobin.dtb setenv fdt_name_b dtb/marvell/armada-3720-espressobin-v7.dtb U-Boot automatically fills variable ${fdtfile} to marvell/armada-3720-espressobin-v7.dtb or marvell/armada-3720-espressobin.dtb (or with -emmc.dtb suffix) at the runtime based on detected espressobin variant. Variable ${fdtfile} is standard distroboot variable so you can use it in your boot script to make booting universal. 0 Quote Link to comment Share on other sites More sharing options...
Heisath Posted March 1, 2022 Share Posted March 1, 2022 On 2/19/2022 at 8:19 PM, y52 said: Could you provide with more detailed directions for the above tasks, so that they could be executed? Our recent experience with @Pali building mainline u-boot could serve as a good example and practice. Hi @y52 , sorry for the late reply I had a busy work week. To try the changes you: run "git clone https://github.com/armbian/build" run "cd build" run "git checkout AR-775" run "./compile.sh BOARD=espressobin" use the onscreen menu to select "full-image", "current" kernel, "do not change kernel config", then build script should start building. if errors occur pls post them you use the generated image in output/images to boot your espressobin (use a spare sd card, so you can go back to your working system) report findings Also see documentation on how to build armbian: https://docs.armbian.com/Developer-Guide_Build-Preparation/ 0 Quote Link to comment Share on other sites More sharing options...
y52 Posted March 6, 2022 Share Posted March 6, 2022 On 3/1/2022 at 7:39 AM, Heisath said: if errors occur pls post them I followed your build instructions. I understand that all components sources were build successfully, but the final image creation failed as follows : ... I: Extracting mount... I: Extracting util-linux... I: Extracting libxxhash0... I: Extracting liblzma5... I: Extracting zlib1g... [ o.k. ] Installing base system [ Stage 2/2 ] W: Failure trying to run: /sbin/ldconfig W: See //debootstrap/debootstrap.log for details [ error ] ERROR in function create_rootfs_cache [ main.sh:578 -> main.sh:539 -> debootstrap.sh:58 -> debootstrap.sh:238 -> general.sh:0 ] [ error ] Debootstrap base system for current espressobin bullseye no second stage failed [ o.k. ] Process terminated [ error ] unmount_on_exit() called! [ main.sh:1 -> image-helpers.sh:0 ] [ o.k. ] Unmounting [ /mnt/sda1/Armbian.src/build/.tmp/rootfs-9e4f7fab-ad4f-4c4e-b9da-7fb6b4637f04/ ] [ 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: 19385.060161 seconds I do not see any problem with root@deb10:~# /sbin/ldconfig --version ldconfig (Debian GLIBC 2.28-10) 2.28 Copyright (C) 2018 Free Software Foundation, Inc. I was unable to find debootstrap.log on the system. Could it be fixed ? Mainline u-boot images were created successfully. But I haven't tried them with espressobin, waiting for the base system image generation completed without error. The following packages were built: root@deb10:/mnt/sda1/Armbian.src/build# ls -al output/debs/ total 458112 drwxrwxr-x 3 root root 4096 Mar 6 15:19 . drwxrwxr-x 8 root root 4096 Mar 6 15:19 .. -rw-r--r-- 1 root root 418388 Mar 6 15:19 armbian-bsp-cli-espressobin_22.02.0-trunk_arm64.deb -rw-r--r-- 1 root root 126972 Mar 6 15:11 armbian-config_22.02.0-trunk_all.deb -rw-r--r-- 1 root root 7987392 Mar 6 15:11 armbian-firmware_22.02.0-trunk_all.deb -rw-r--r-- 1 root root 240743148 Mar 6 15:19 armbian-firmware-full_22.02.0-trunk_all.deb -rw-r--r-- 1 root root 2251236 Mar 6 15:11 armbian-zsh_22.02.0-trunk_all.deb drwxrwxr-x 2 root root 4096 Mar 6 09:59 extra -rw-r--r-- 1 root root 27448 Mar 6 15:11 linux-dtb-current-mvebu64_22.02.0-trunk_arm64.deb -rw-r--r-- 1 root root 11848012 Mar 6 15:11 linux-headers-current-mvebu64_22.02.0-trunk_arm64.deb -rw-r--r-- 1 root root 34116236 Mar 6 15:11 linux-image-current-mvebu64_22.02.0-trunk_arm64.deb -rw-r--r-- 1 root root 1179588 Mar 6 15:11 linux-libc-dev_22.02.0-trunk_arm64.deb -rw-r--r-- 1 root root 169641548 Mar 6 11:03 linux-source-current-mvebu64_22.02.0-trunk_all.deb -rw-r--r-- 1 root root 729576 Mar 6 10:54 linux-u-boot-current-espressobin_22.02.0-trunk_arm64.deb 0 Quote Link to comment Share on other sites More sharing options...
Heisath Posted March 6, 2022 Share Posted March 6, 2022 Ok so building the packages works, but image build does not. I will see if I can fix this. @y52 what host system are you building on? Recommended is a virtual machine running Ubuntu Hirsute. You need atleast the OS version, which you're bootstrapping. So if you wanna produce bullseye need atleast bullseye or ubuntu equivalent (hirsute). https://docs.armbian.com/Developer-Guide_Build-Preparation/ EDIT: Image build on hirsute seems to work: [ o.k. ] Mount point [ o.k. ] Ending debootstrap process and preparing cache [ bullseye ] [ o.k. ] Unmounting [ /home/user/build/.tmp/rootfs-89867f8c-41b7-4ec1-aecf-5e1b88411dd8 ] bullseye-cli-arm64.ead...ad3.tar.lz4: 1008MiB [56.1MiB/s] [=========================================================================================================================================================================================================================] 106% [ o.k. ] Applying distribution specific tweaks for [ bullseye ] [ o.k. ] Applying common tweaks [ .... ] Cleaning [ package lists ] [ .... ] Updating [ package lists ] [ .... ] Temporarily disabling [ initramfs-tools hook for kernel ] [ .... ] Installing [ linux-u-boot-current-espressobin_22.02.0-trunk_arm64.deb ] [ .... ] Installing [ linux-image-current-mvebu64_22.02.0-trunk_arm64.deb ] [ .... ] Installing [ linux-dtb-current-mvebu64_22.02.0-trunk_arm64.deb ] [ .... ] Installing [ armbian-bsp-cli-espressobin_22.02.0-trunk_arm64.deb ] [ .... ] Installing [ armbian-firmware_22.02.0-trunk_all.deb ] [ .... ] Installing [ armbian-config_22.02.0-trunk_all.deb ] [ .... ] Installing [ armbian-zsh_22.02.0-trunk_all.deb ] [ .... ] Installing from repository [ wireguard-tools --no-install-recommends ] [ o.k. ] Enabling serial console [ ttyMV0 ] [ o.k. ] Building kernel splash logo [ bullseye ] [ .... ] Installing extras-buildpkgs [ hostapd htop ] [ o.k. ] Calling image customization script [ customize-image.sh ] [ o.k. ] No longer needed packages [ purge ] [ o.k. ] Unmounting [ /home/user/build/.tmp/rootfs-89867f8c-41b7-4ec1-aecf-5e1b88411dd8 ] [ o.k. ] Preparing image file for rootfs [ espressobin bullseye ] [ o.k. ] Current rootfs size [ 1360 MiB ] [ o.k. ] Creating blank image for rootfs [ 1708 MiB ] [ .... ] dd: 1.67GiB [ 124MiB/s] [=================================================================================================================================================================================================================================================>] 100% [ o.k. ] Creating partitions [ root: ext4 ] [ .... ] Creating rootfs [ ext4 on /dev/loop11p1 ] [ .... ] Copying files to [ / ] [ .... ] Copying files to [ /boot ] sent 26.63M bytes received 643 bytes 53.26M bytes/sec total size is 26.62M speedup is 1.00 [ .... ] Updating initramfs... [ update-initramfs -uv -k 5.15.26-mvebu64 ] [ o.k. ] Updated initramfs. [ for details see: /home/user/build/output/debug/install.log ] [ .... ] Re-enabling [ initramfs-tools hook for kernel ] [ o.k. ] Unmounting [ /home/user/build/.tmp/mount-89867f8c-41b7-4ec1-aecf-5e1b88411dd8/ ] [ o.k. ] Free SD cache [ 10% ] [ o.k. ] Mount point [ 88% ] [ o.k. ] Writing U-boot bootloader [ /dev/loop11 ] [ o.k. ] SHA256 calculating [ Armbian_22.02.0-trunk_Espressobin_bullseye_current_5.15.26.img ] [ warn ] GPG signing skipped - no GPG_PASS [ Armbian_22.02.0-trunk_Espressobin_bullseye_current_5.15.26.img ] [ o.k. ] Done building [ /home/user/build/.tmp/image-89867f8c-41b7-4ec1-aecf-5e1b88411dd8/Armbian_22.02.0-trunk_Espressobin_bullseye_current_5.15.26.img ] [ o.k. ] Runtime [ 29 min ] [ o.k. ] Repeat Build Options [ ./compile.sh BOARD=espressobin BRANCH=current RELEASE=bullseye BUILD_MINIMAL=no BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no COMPRESS_OUTPUTIMAGE=sha,gpg,img ] user@builder:~/build$ 0 Quote Link to comment Share on other sites More sharing options...
y52 Posted March 7, 2022 Share Posted March 7, 2022 6 hours ago, Heisath said: what host system are you building on? I was building on Debian 10 host. It would be quite cumbersome to reinstall everything. 6 hours ago, Heisath said: You need atleast the OS version, which you're bootstrapping. So if you wanna produce bullseye need atleast bullseye or ubuntu equivalent I don't have currently another spare host. I am waiting for the cable for my new espressobin setup running Bullseye. Once it gets delivered, I'll be able using it for the new build. Will it be possible to build image on an Arm system? Alternatively, could I reproduce the last failed step from Bullseye@espressobin, thus creating the image on a different host ? 0 Quote Link to comment Share on other sites More sharing options...
Heisath Posted March 7, 2022 Share Posted March 7, 2022 I built an image today: https://drive.google.com/file/d/1uZ4Pn_APPs9cJEpjV6-Nn7b1Ib6Ykh8W/view?usp=sharing maybe you can use this. Otherwise best to use Virtual Box or Docker. Building on Arm is also possible, but I don't know details. 0 Quote Link to comment Share on other sites More sharing options...
y52 Posted March 12, 2022 Share Posted March 12, 2022 On 3/7/2022 at 5:13 PM, Heisath said: maybe you can use this I've tried the above generated image for the AR-775 trunk to boot my espressobin v5. The major concern at this point which requires the fix is that the reboot is being suspended [ OK ] Deactivated swap /dev/zram0. [ OK ] Reached target Unmount All Filesystems. [ OK ] Reached target Final Step. [ OK ] Finished Reboot. [ OK ] Reached target Reboot. [ 582.436469] watchdog: watchdog0: watchdog did not stop! Espressobin gets stuck at this point and requires hardware reset or full power off. It may concomitated with the error message of u-boot log: U-Boot 2022.01-armbian (Mar 05 2022 - 21:54:52 +0100) DRAM: 2 GiB WDT: Not starting watchdog-timer@8300 Other observations, which I made are as follows : 1) u-boot ======= CZ.NIC's Armada 3720 Secure Firmware was not implemented. I haven't noticed a delay for the firmware to initialize DDR and run DDR training algorithm. It produces different CPU voltage : Armbian u-boot @ espressobin v5 SVC REV: 3, CPU VDD voltage: 1.155V compared to mainline u-boot @ espressobin v7 (which I reported earlier here) SVC REV: 5, CPU VDD voltage: 1.225V The difference could arrise from different board versions, but I have no knowledge about it. Here are the 2 u-boot log for comparison : Armbian u-boot @ espressobin v5 ========================== Marvell>> reset resetting ... TIM-1.0 mv_ddr-devel-g7753d4b DDR3 16b 2GB 2CS WTMI-devel-18.12.1-e733e9f-dirty WTMI: system early-init SVC REV: 3, CPU VDD voltage: 1.155V Setting clocks: CPU 1000 MHz, DDR 800 MHz NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.6(release):510155aa NOTICE: BL1: Built : 22:37:08, Mar 5 2022 NOTICE: BL1: Booting BL2 NOTICE: BL2: v2.6(release):510155aa NOTICE: BL2: Built : 22:37:08, Mar 5 2022 NOTICE: BL1: Booting BL31 NOTICE: BL31: v2.6(release):510155aa NOTICE: BL31: Built : 22:37:08, Mar 5 2022 U-Boot 2022.01-armbian (Mar 05 2022 - 21:54:52 +0100) DRAM: 2 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 w25q32dw with page size 256 Bytes, erase size 4 KiB, total 4 MiB OK Model: Globalscale Marvell ESPRESSOBin Board Net: eth0: neta@30000 [PRIME] mainline u-boot @ espressobin v7 ========================== Marvell>> reset resetting ... TIM-1.0 mv_ddr-devel-g7753d4b DDR4 16b 1GB 1CS WTMI-devel-18.12.1-4392eaf WTMI: system early-init SVC REV: 5, CPU VDD voltage: 1.225V Setting clocks: CPU 1200 MHz, DDR 750 MHz CZ.NIC's Armada 3720 Secure Firmware v2021.09.07-27-g489262b (Feb 9 2022 18:50:42) Running on ESPRESSObin NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.6(release):v2.6-365-ge0a6a512b NOTICE: BL1: Built : 18:52:58, Feb 9 2022 NOTICE: BL1: Booting BL2 NOTICE: BL2: v2.6(release):v2.6-365-ge0a6a512b NOTICE: BL2: Built : 18:53:02, Feb 9 2022 NOTICE: BL1: Booting BL31 NOTICE: BL31: v2.6(release):v2.6-365-ge0a6a512b NOTICE: BL31: Built : 18:53:12, Feb 9 2022 U-Boot 2022.04-rc1-00087-gb5c5b9a0be (Feb 09 2022 - 18:44:33 +0100) DRAM: 1 GiB Core: 37 devices, 21 uclasses, devicetree: separate WDT: Not starting watchdog-timer@8300 Comphy chip #0: Comphy-0: USB3_HOST0 5 Gbps Comphy-1: PEX0 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: Link down MMC: sdhci@d0000: 0, sdhci@d8000: 1 Loading Environment from SPIFlash... SF: Detected w25q32dw with page size 256 Bytes, erase size 4 KiB, total 4 MiB OK Model: Globalscale Marvell ESPRESSOBin Board Net: eth0: neta@30000 [PRIME] Hit any key to stop autoboot: 0 As for the "Armbian 22.02.0-trunk Bullseye!" itself : I haven't noticed corrections to terminal and network settings, which we reported with @Pali here: The serial console output settings need to be fixed. It doesn't produce the timestamp. bootargs in boot.cmd setenv bootargs "$console root=${rootdev} rootfstype=${rootfstype} rootwait loglevel=${verbosity} usb-storage.quirks=${usbstoragequirks} mtdparts=spi0.0:1536k(uboot),64k(uboot-environment),-(reserved) ${extraargs}" As it was stated by @Pali : #Remove hardcoded mtdparts= option. U-Boot already supplied correct one via DT. #Missing logs are probably caused by loglevel=1 option. Remove it too. setenv bootargs "$console root=${rootdev} rootfstype=${rootfstype} rootwait usb-storage.quirks=${usbstoragequirks}, ${extraargs}" I've also found it necessary disabling networkd-dispatcher.service enabled enabled networking.service enabled enabled NetworkManager-dispatcher.service enabled enabled <-- disable NetworkManager-wait-online.service disabled enabled NetworkManager.service enabled enabled <-- disable root@espressobin:/etc/systemd/network# systemctl disable NetworkManager-dispatcher.service Removed /etc/systemd/system/dbus-org.freedesktop.nm-dispatcher.service. root@espressobin:/etc/systemd/network# systemctl disable NetworkManager.service Removed /etc/systemd/system/multi-user.target.wants/NetworkManager.service. systemd-network-generator.service disabled disabled systemd-networkd-wait-online.service enabled disabled <-- disable systemd-networkd.service enabled enabled root@espressobin:/etc/systemd/network# systemctl disable systemd-networkd-wait-online.service Removed /etc/systemd/system/network-online.target.wants/systemd-networkd-wait-online.service. The eth0 DHCP setting needs to be disabled. root@espressobin:/etc/systemd/network# vi 10-eth0.network [Match] Name=eth0 [Network] #DHCP=ipv4 <<- Otherwise, it produces unnecessary DHCP queries which leads to confusions. #ethXaddr settings need to be disabled as well : root@espressobin:/boot# cat /boot/armbianEnv.txt verbosity=1 emmc_fix=off spi_workaround=off #eth1addr=0E:98:6A:3C:2F:FF #eth2addr=fa:ad:4e:84:25:2f #eth3addr=00:50:43:0d:19:18 ethXaddr should be removed from the u-boot environment settings if any. ethaddr should be set to the MAC printed on espressobin sticker or generated a valid one. More other fixes will be required, but it would be worth fixing at least above ones. I shall try using this setup to build the trunk directly on Espressobin. It will also show the board stability. The main board used to reset itself sporadically with now old u-boot 2019 and older Armbian. Here is the Arbian log : ================ Failed to load '/boot.scr' ## Executing script at 06d00000 Wrong image format for "source" command /boot/ 1063 bytes read in 15 ms (68.4 KiB/s) ## Executing script at 06d00000 240 bytes read in 12 ms (19.5 KiB/s) 21572096 bytes read in 925 ms (22.2 MiB/s) 8908506 bytes read in 392 ms (21.7 MiB/s) Failed to load '/boot/dtb/marvell/armada-3720-community.dtb' 11618 bytes read in 28 ms (404.3 KiB/s) ## Loading init Ramdisk from Legacy Image at 01100000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 8908442 Bytes = 8.5 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 7f27d000, end 7fafbe9a ... 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.26-mvebu64 (root@builder) (aarch64-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36)) 8.3.0, GNU ld (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36)) 2.32.0.20190321) #trunk SMP PREEMPT Mon Mar 7 08:48:21 CET 2022 [ 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-6 Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems done. Begin: Will now check root file system ... fsck from util-linux 2.36.1 [/sbin/fsck.ext4 (1) -- /dev/mmcblk0p1] fsck.ext4 -a -C0 /dev/mmcblk0p1 /dev/mmcblk0p1: clean, 42974/4462976 files, 648013/15567872 blocks done. done. Begin: Running /scripts/local-bottom ... done. Begin: Running /scripts/init-bottom ... done. Welcome to Armbian 22.02.0-trunk Bullseye! [ OK ] Created slice system-getty.slice. [ OK ] Created slice system-modprobe.slice. [ OK ] Created slice system-serial\x2dgetty.slice. [ OK ] Created slice User and Session Slice. [ OK ] Started Forward Password R…uests to Wall Directory Watch. [ OK ] Set up automount Arbitrary…s File System Automount Point. [ OK ] Reached target Local Encrypted Volumes. [ OK ] Reached target Slices. [ OK ] Reached target Swap. [ OK ] Reached target System Time Set. [ OK ] Listening on RPCbind Server Activation Socket. [ OK ] Listening on Syslog Socket. [ OK ] Listening on fsck to fsckd communication Socket. [ OK ] Listening on initctl Compatibility Named Pipe. [ OK ] Listening on Journal Audit Socket. [ OK ] Listening on Journal Socket (/dev/log). [ OK ] Listening on Journal Socket. [ OK ] Listening on Network Service Netlink Socket. [ OK ] Listening on udev Control Socket. [ OK ] Listening on udev Kernel Socket. ... [ OK ] Finished system activity accounting tool. [ OK ] Finished Generate a daily summary of process accounting. [ OK ] Finished Daily man-db regeneration. [ OK ] Finished Rotate log files. [FAILED] Failed to start Wait for Network to be Configured. See 'systemctl status systemd-networkd-wait-online.service' for details. [ OK ] Reached target Network is Online. Starting LSB: Advanced IEEE 802.11 management daemon... Starting /etc/rc.local Compatibility... [ OK ] Started LSB: Advanced IEEE 802.11 management daemon. [ OK ] Started /etc/rc.local Compatibility. [ OK ] Started Getty on tty1. [ OK ] Started Serial Getty on ttyMV0. [ OK ] Reached target Login Prompts. [ OK ] Reached target Multi-User System. [ OK ] Reached target Graphical Interface. Starting Update UTMP about System Runlevel Changes... [ OK ] Finished Update UTMP about System Runlevel Changes. 0 Quote Link to comment Share on other sites More sharing options...
Heisath Posted March 12, 2022 Share Posted March 12, 2022 @y52 first of all thanks for testing and replying with complete + helpful logs and analyzation! 1 hour ago, y52 said: The major concern at this point which requires the fix is that the reboot is being suspended This is indeed a problem. But I don't think the uboot error is responsible: 1 hour ago, y52 said: WDT: Not starting watchdog-timer@8300 as it is visible in armbian and mainline uboot! 1 hour ago, y52 said: CZ.NIC's Armada 3720 Secure Firmware was not implemented. If this this CZ.NIC firmware is needed, I will check how to add it. 1 hour ago, y52 said: It produces different CPU voltage : Armbian u-boot @ espressobin v5 SVC REV: 3, CPU VDD voltage: 1.155V compared to mainline u-boot @ espressobin v7 (which I reported earlier here) SVC REV: 5, CPU VDD voltage: 1.225V The difference could arrise from different board versions, but I have no knowledge about it. I think this is ebin v5 vs v7. 1 hour ago, y52 said: As for the "Armbian 22.02.0-trunk Bullseye!" itself : I haven't noticed corrections to terminal and network settings, which we reported with @Pali here: The serial console output settings need to be fixed. It doesn't produce the timestamp. bootargs in boot.cmd setenv bootargs "$console root=${rootdev} rootfstype=${rootfstype} rootwait loglevel=${verbosity} usb-storage.quirks=${usbstoragequirks} mtdparts=spi0.0:1536k(uboot),64k(uboot-environment),-(reserved) ${extraargs}" As it was stated by @Pali : #Remove hardcoded mtdparts= option. U-Boot already supplied correct one via DT. #Missing logs are probably caused by loglevel=1 option. Remove it too. setenv bootargs "$console root=${rootdev} rootfstype=${rootfstype} rootwait usb-storage.quirks=${usbstoragequirks}, ${extraargs}" I will look into how-to remove the mtdparts, the loglevel will stay (it is user adjustable via armbianEnv.txt), not sure what the part about timestamps is about, could you clarify? 1 hour ago, y52 said: I've also found it necessary disabling networkd-dispatcher.service enabled enabled networking.service enabled enabled NetworkManager-dispatcher.service enabled enabled <-- disable NetworkManager-wait-online.service disabled enabled NetworkManager.service enabled enabled <-- disable root@espressobin:/etc/systemd/network# systemctl disable NetworkManager-dispatcher.service Removed /etc/systemd/system/dbus-org.freedesktop.nm-dispatcher.service. root@espressobin:/etc/systemd/network# systemctl disable NetworkManager.service Removed /etc/systemd/system/multi-user.target.wants/NetworkManager.service. systemd-network-generator.service disabled disabled systemd-networkd-wait-online.service enabled disabled <-- disable systemd-networkd.service enabled enabled root@espressobin:/etc/systemd/network# systemctl disable systemd-networkd-wait-online.service Removed /etc/systemd/system/network-online.target.wants/systemd-networkd-wait-online.service. The eth0 DHCP setting needs to be disabled. root@espressobin:/etc/systemd/network# vi 10-eth0.network [Match] Name=eth0 [Network] #DHCP=ipv4 <<- Otherwise, it produces unnecessary DHCP queries which leads to confusions. Network settings like this are user defined. Maybe someone wants DHCP on eth0. We don't know that. I'm hesitant to change anything here, please give more reason why. 1 hour ago, y52 said: #ethXaddr settings need to be disabled as well : root@espressobin:/boot# cat /boot/armbianEnv.txt verbosity=1 emmc_fix=off spi_workaround=off #eth1addr=0E:98:6A:3C:2F:FF #eth2addr=fa:ad:4e:84:25:2f #eth3addr=00:50:43:0d:19:18 ethXaddr should be removed from the u-boot environment settings if any. ethaddr should be set to the MAC printed on espressobin sticker or generated a valid one. I will remove the MAC addresses. Not sure how we can "generate a valid one". 0 Quote Link to comment Share on other sites More sharing options...
y52 Posted March 12, 2022 Share Posted March 12, 2022 On 3/12/2022 at 2:27 PM, Heisath said: I will look into how-to remove the mtdparts, the loglevel will stay (it is user adjustable via armbianEnv.txt), not sure what the part about timestamps is about, could you clarify? We discussed this issue on Feb. 10th here: On 3/12/2022 at 2:27 PM, Heisath said: Network settings like this are user defined. Maybe someone wants DHCP on eth0. We don't know that. I'm hesitant to change anything here, please give more reason why. eth0 is the internal switch interface. It is not used in providing user network functionality. It has neither any PHY interface, no it requires any ip address. If DHCP is left enabled, it inquires a supplementary address from the DHCPD server, like it was my case here : Mar 12 10:16:01 tiger dhcpd[981]: DHCPDISCOVER from 00:51:82:11:22:00 (espressobin) via lan Mar 12 10:16:02 tiger dhcpd[981]: DHCPOFFER on 192.168.1.244 to 00:51:82:11:22:00 (espressobin) via lan Mar 12 10:16:05 tiger dhcpd[981]: DHCPDISCOVER from 6e:05:2a:97:c4:0c via lan Mar 12 10:16:05 tiger dhcpd[981]: DHCPDISCOVER from 00:51:82:11:22:00 (espressobin) via lan Mar 12 10:16:05 tiger dhcpd[981]: DHCPOFFER on 192.168.1.244 to 00:51:82:11:22:00 (espressobin) via lan Mar 12 10:16:06 tiger dhcpd[981]: DHCPOFFER on 192.168.1.243 to 6e:05:2a:97:c4:0c (espressobin) via lan Mar 12 10:16:06 tiger dhcpd[981]: DHCPREQUEST for 192.168.1.243 (192.168.4.15) from 6e:05:2a:97:c4:0c (espressobin) via lan Mar 12 10:16:06 tiger dhcpd[981]: DHCPACK on 192.168.1.243 to 6e:05:2a:97:c4:0c (espressobin) via lan Despite it, espressobin is accessible through x.243 only. On 3/1/2022 at 7:39 AM, Heisath said: run "git checkout AR-775" run "./compile.sh BOARD=espressobin" use the onscreen menu to select "full-image", "current" kernel, "do not change kernel config", then build script should start building. if errors occur pls post them Build script on espressobin with Bullseye hasn't completed again with the following errors : 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 Apt commands run separately are executed without error : root@espressobin:/src/Armbian/build# apt-get update .. Get:11 http://deb.debian.org/debian bullseye-backports/main arm64 Packages T-2022-03-13-0802.23-F-2022-03-13-0802.23.pdiff [196 B] Get:13 http://security.debian.org bullseye-security/main arm64 Packages [152 kB] Get:12 http://deb.debian.org/debian bullseye-backports/main all Contents (deb) T-2022-03-13-0802.23-F-2022-03-13-0802.23.pdiff [87 B] Fetched 625 kB in 13s (49.0 kB/s) Reading package lists... Done root@espressobin:/src/Armbian/build# apt install unzip Reading package lists... Done Building dependency tree... Done Reading state information... Done unzip is already the newest version (6.0-26). On the positive side, espressobin with the new u-boot and armbian 22 is so far stable both idle and under heavy load during building. root@espressobin:/src/Armbian/build# uptime 10:43:03 up 23:17, 2 users, load average: 0.00, 0.01, 0.05 When building : Time CPU load %cpu %sys %usr %nice %io %irq CPU 14:02:21: 1000MHz 3.26 99% 14% 84% 0% 0% 0% 27.0°C 14:02:26: 1000MHz 3.24 100% 11% 88% 0% 0% 0% 27.0°C 14:02:37: 1000MHz 3.28 100% 14% 85% 0% 0% 0% 28.0°C On 3/12/2022 at 2:27 PM, Heisath said: NetworkManager-dispatcher.service enabled enabled <-- disable NetworkManager-wait-online.service disabled enabled NetworkManager.service enabled enabled <-- disable 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. 0 Quote Link to comment Share on other sites More sharing options...
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.