Jump to content

Making EspressoBin V7 work in 2022 ...


fallen_aarch64

Recommended Posts

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

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

 

 

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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.   

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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:

  1. run "git clone https://github.com/armbian/build"
  2. run "cd build"
  3. run "git checkout AR-775"
  4. run "./compile.sh BOARD=espressobin"
  5. use the onscreen menu to select "full-image", "current" kernel, "do not change kernel config", then build script should start building.
  6. if errors occur pls post them
  7. 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) 
  8. report findings

Also see documentation on how to build armbian: https://docs.armbian.com/Developer-Guide_Build-Preparation/

 

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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$ 

 

Link to comment
Share on other sites

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 ?

Link to comment
Share on other sites

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.

 

 

 

 

 

Link to comment
Share on other sites

@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".

 

 

 

 

 

Link to comment
Share on other sites

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.

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