Espressobin support development efforts

[y52]

I was running the

Marvell>> version

U-Boot 2017.03-armada-17.10.1-g440395a (Sep 25 2017 - 15:43:51 +0200)
aarch64-linux-gnu-gcc (Linaro GCC 6.3-2017.05) 6.3.1 20170404
GNU ld (Linaro_Binutils-2017.05) 2.27.0.20161019

 

I tried switching to 1200/750 firmware:

Marvell>> bubt uboot/flash-image-2g-1200_750_boot_sd_and_usb.bin spi usb
Burning U-BOOT image "uboot/flash-image-2g-1200_750_boot_sd_and_usb.bin" from "usb" to "spi"
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 w25q32dw with page size 256 Bytes, erase size 4 KiB, total 4 MiB
24576 bytes written, 795896 bytes skipped in 0.583s, speed 1438635 B/s
Done!

 

 

As the result, my boad is bricked completely and the U-boot stops at :

----------------------------------------------------
SVC_REV:3

 

Any suggestions on how recover the board now?

[Patrick]

I was running the
Marvell>> version
U-Boot 2017.03-armada-17.10.1-g440395a (Sep 25 2017 - 15:43:51 +0200)
aarch64-linux-gnu-gcc (Linaro GCC 6.3-2017.05) 6.3.1 20170404
GNU ld (Linaro_Binutils-2017.05) 2.27.0.20161019
 
I tried switching to 1200/750 firmware:
Marvell>> bubt uboot/flash-image-2g-1200_750_boot_sd_and_usb.bin spi usb
Burning U-BOOT image "uboot/flash-image-2g-1200_750_boot_sd_and_usb.bin" from "usb" to "spi"
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 w25q32dw with page size 256 Bytes, erase size 4 KiB, total 4 MiB
24576 bytes written, 795896 bytes skipped in 0.583s, speed 1438635 B/s
Done!
 
 
As the result, my boad is bricked completely and the U-boot stops at :
----------------------------------------------------
SVC_REV:3
 
Any suggestions on how recover the board now?

Read the NOTES here: https://www.armbian.com/espressobin/



Verzonden vanaf mijn iPhone met Tapatalk

[ebin-dev]

42 minutes ago, Patrick said:

Sorry, the 5 day's up-time isn't the record.

I changed this governor setting 5 days ago and had no kernel panic anymore.

 

Your problems with the ondemand governor are specific to boards with hardware issues. You may have caused these issues yourself.

 

 

These problems seem to arise (after some time) if your board is powered simultaneously by two sources with different GND potentials (check DC and AC).

In this case your board will be exposed to severe electrical and thermal strain causing hardware issues after some time.

It can be avoided if you access the serial console using a laptop that is not connected to a power supply itself (see https://forum.armbian.com/topic/4089-espressobin-support-development-efforts/?page=7&tab=comments#comment-39671 ).

 

[Patrick]

6 minutes ago, ebin-dev said:

 

Your problems with the ondemand governor are specific to boards with hardware issues. You may have caused these issues yourself.

 

 

These problems seem to arise (after some time) if your board is powered simultaneously by two sources with different GND potentials (check DC and AC).

In this case your board will be exposed to severe electrical and thermal strain causing hardware issues after some time.

It can be avoided if you access the serial console using a laptop that is not connected to a power supply itself (see https://forum.armbian.com/topic/4089-espressobin-support-development-efforts/?page=7&tab=comments#comment-39671 ).

 

I know,

 

But I never used the serial connection with my macbook connected to a power supply

[ebin-dev]

In case you bricked your device, @Igor proposes SATA boot recovery.

 

By the way -  change the following environment settings to permanently boot from SATA:

setenv boot_interface scsi
setenv rootdev "/dev/sda1"
setenv root root=/dev/sda1 rw
setenv bootcmd 'scsi scan; scsi dev 0; ext4load scsi 0:1 $kernel_addr $image_name;ext4load scsi 0:1 $initrd_addr $initrd_image; ext4load scsi 0:1 $fdt_addr $fdt_name;setenv bootargs $console root=$rootdev rw rootwait; booti $kernel_addr $initrd_addr $fdt_addr'

 

[y52]

I've been able to restore the board through the SATA recovery procedure. My next experience was re-trying the 2G-1200/750, which bricked the board again. I downgraded to the 2G-1000/800 and booted Armbian (several times), but it didn't resulted in a stable system. I was not even able loggin in any single time.

I flashed the U-boot with the Espressobin's bootloader again :

U-Boot 2017.03-armada-17.06.3-ga33ecb8 (Jul 05 2017 - 14:30:47 +0800)

Model: Marvell Armada 3720 Community Board ESPRESSOBin
       CPU    @ 1000 [MHz]
       L2     @ 800 [MHz]
       TClock @ 200 [MHz]
       DDR    @ 800 [MHz]
DRAM:  2 GiB
U-Boot DComphy-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
SF: Detected w25q32dw with page size 256 Bytes, erase size 4 KiB, total 4 MiB
*** Warning - bad CRC, using default environment

 

It shows this bad CRC warning again.

 

The Armbian boots, but halts again even before allowing to log in.

 

The overall experience is just discouraging : there is no any single workable configuration with Armbian for my board.

 

Is there any solution?

 

[ebin-dev]

1 hour ago, y52 said:

Is there any solution?

 

There are two more flash images 800_800 and 600_600. 

I would test the board with those images - and RMA the device.

[y52]

Do you think, that the hardware is defective? What should I claim to RMA ?

 

I flashed the firmware with the 800_800 image. 

U-Boot 2017.03-armada-17.10.1-g440395a (Sep 25 2017 - 15:43:51 +0200)

Model: Marvell Armada 3720 Community Board ESPRESSOBin
       CPU    @ 800 [MHz]
       L2     @ 800 [MHz]
       TClock @ 200 [MHz]
       DDR    @ 800 [MHz]
DRAM:  2 GiB

 

The Armbian turns stable. and very quiet. 

root@espressobin:~# cat /proc/version
Linux version 4.4.112-mvebu64 (root@xeon) (gcc version 6.4.1 20171012 (Linaro GCC 6.4-2017.11) ) #8 SMP PREEMPT Wed Jan 24
22:53:43 CET 2018

root@espressobin:~# armbianmonitor -m
Stop monitoring using [ctrl]-[c]
Time        CPU    load %cpu %sys %usr %nice %io %irq

17:27:45:  800MHz  0.12   8%   2%   4%   0%   1%   0%
17:27:50:    0MHz  0.11   1%   1%   0%   0%   0%   0%

 

The scaling works as well:

root@espressobin:~#  cpufreq-info

available frequency steps: 200 MHz, 267 MHz, 400 MHz, 800 MHz

 

I also changed

root@espressobin:~# vi /etc/init.d/cpufrequtils

ENABLE="true"
#GOVERNOR="ondemand"
GOVERNOR="conservative"

 

Then I moved back to 1000/800 flash

Marvell>> bubt uboot/flash-image-2g-1000_800_boot_sd_and_usb.bin spi usb

After booting the Armbian the troubles reappeared back :

Welcome to ARMBIAN 5.38 stable Debian GNU/Linux 9 (stretch) 4.4.112-mvebu64  

 

I am accessing the terminal through ssh with the serial cable detached at this stage.

sk@espressobin:~$ su - root
Password: 

The login took a minute delay and error mistakes appeared :

root@espressobin:~# 
Message from syslogd@localhost at Feb 24 17:52:59 ...
 kernel:[  115.263491] Call trace:

Message from syslogd@localhost at Feb 24 17:52:59 ...
 kernel:[  115.283741] Call trace:

Message from syslogd@localhost at Feb 24 17:53:02 ...
 kernel:[  117.609757] Call trace:

Message from syslogd@localhost at Feb 24 17:53:02 ...
 kernel:[  117.681345] Call trace:

 

The load increased significantly on a quiet system :

root@espressobin:~# armbianmonitor -m
Stop monitoring using [ctrl]-[c]
Time        CPU    load %cpu %sys %usr %nice %io %irq

17:55:52: 1000MHz 10.89  52%  47%   4%   0%   0%   0%
17:55:57: 1000MHz 10.90  50%  50%   0%   0%   0%   0%
17:56:02: 1000MHz 10.91  50%  50%   0%   0%   0%   0%
17:56:07: 1000MHz 10.91  50%  50%   0%   0%   0%   0%

 

And finally everything stopped working :

Message from syslogd@localhost at Feb 24 18:22:26 ...
 kernel:[ 1882.169758] Call trace:

Message from syslogd@localhost at Feb 24 18:22:26 ...
 kernel:[ 1882.241982] Call trace:

root@espressobin:~# armbianmonitor -m
-su: fork: retry: Resource temporarily unavailable
-su: fork: retry: Resource temporarily unavailable
-su: fork: retry: Resource temporarily unavailable

 

sk@espressobin:~$ su - root
-bash: fork: retry: Resource temporarily unavailable
 

Error messages are repetitive every couple of minutes.
Message from syslogd@localhost at Feb 24 18:57:06 ...
 kernel:[ 3961.829759] Call trace:

Message from syslogd@localhost at Feb 24 18:57:06 ...
 kernel:[ 3961.901992] Call trace:

 

Anyway, you can do nothing with the system now.

root@espressobin:~# shutdown -r now
-su: fork: retry: Resource temporarily unavailable
-su: fork: retry: Resource temporarily unavailable

 

What is your expert's advice :  is that a faulty hardware, firmware problem or the one of Armbian?

 

Could somebody  point me on  how to boot from USB automatically ,  in an unattended way? 

[ebin-dev]

20 minutes ago, y52 said:

is that a faulty hardware, firmware problem or the one of Armbian?

 

Your hardware ist stable with 800_800 but not with 1000_800 - this clearly shows that you have a hardware problem not related to Armbian in any way.

Your EspressoBin does not fulfil the specs - you purchased a device with a 1000MHz CPU clock.

Everybody having the same issues should contact GlobalScale and RMA the device.

 

Edit: If you flash something else than 1000_800 you need to adapt min and max values in /etc/default/cpufrequtils to values shown by 'cpufreq-info'.

[y52]

Is the U-Boot log warning meaningful in any way?

SF: Detected w25q32dw with page size 256 Bytes, erase size 4 KiB, total 4 MiB
*** Warning - bad CRC, using default environment

 

Still looking on how to boot in an unattended way from USB.

[y52]

Surprisingly, rebooting the system now with the same settings gives a more stable behavior.

root@espressobin:~# armbianmonitor -u
System diagnosis information will now be uploaded to http://ix.io/OR6

It is quite quiet now:

root@espressobin:~# armbianmonitor -m
Stop monitoring using [ctrl]-[c]
Time        CPU    load %cpu %sys %usr %nice %io %irq

20:20:55:  200MHz  0.02   5%   2%   2%   0%   0%   0%
20:21:00:  200MHz  0.02   3%   1%   0%   0%   0%   0%
20:21:06:    0MHz  0.01   1%   1%   0%   0%   0%   0%
20:21:11:    0MHz  0.01   3%   2%   0%   0%   0%   0%

 

 

[umiddelb]

1 hour ago, y52 said:

Is the U-Boot log warning meaningful in any way?

SF: Detected w25q32dw with page size 256 Bytes, erase size 4 KiB, total 4 MiB
*** Warning - bad CRC, using default environment

 

Still looking on how to boot in an unattended way from USB.

This warning says that the persistent u-boot environment hasn't been initialized yet. 

env default -a
saveenv

will initialize the persistent u-boot environment by copying the built-in defaults. 

[y52]

Yes! It looks true. I've used the saveenv to save my custom variable into the u-boot.

The warning has disappeared :

flags: ncq led only pmp fbss pio slum part sxs 
PCIE-0: Link down
MMC:   sdhci@d0000: 0
SF: Detected w25q32dw with page size 256 Bytes, erase size 4 KiB, total 4 MiB
Net:   eth0: neta@30000 [PRIME]

 

I am looking now setting the network up correctly with 1x wan dhcp  and 2x switch i-faces with fixed ips for lan. 

Has anybody useful configuration or link to setup ?

 

Automated boot from USB is still necessary as well.

[y52]

New Kernel panic log  on a quiet system (1000/800):

root@espressobin:~# ifconfig

root@espressobin:~# [  145.919967] Bad mode in Synchronous Abort handler detected, code 0x86000018 -- IABT (current EL)
[  145.928804] Internal error: Oops - bad mode: 0 [#1] PREEMPT SMP
[  145.935185] Modules linked in: xfrm_user xfrm4_tunnel tunnel4 ipcomp xfrm_ipcomp esp4 ah4 af_key xfrm_algo bridge stp llc ip_tables x_tables
[  145.948080] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.4.112-mvebu64 #8
[  145.954821] Hardware name: Marvell Armada 3720 Community Board (DT)
[  145.961208] task: ffffffc0784d0000 ti: ffffffc0784cc000 task.ti: ffffffc0784cc000
[  145.969220] PC is at rcu_idle_enter+0x0/0x58
[  145.973801] LR is at cpu_startup_entry+0x10c/0x218
[  145.978486] pc : [<ffffffc0001058e8>] lr : [<ffffffc0000efb6c>] pstate: 200001c5
[  145.986398] sp : ffffffc0784cff70
[  145.989731] x29: ffffffc0784cff70 x28: 0000000000000000 
[  145.995134] x27: 0000000000000000 x26: ffffffc0784cc000 
[  146.000625] x25: ffffffc000db2000 x24: ffffffc000d8c000 
[  146.006114] x23: ffffffc0009fb000 x22: ffffffc0784cff70 
[  146.011603] x21: ffffffc000d88ac0 x20: ffffffc000db2ae8 
[  146.017096] x19: ffffffc000db2000 x18: 0000000000000000 
[  146.022587] x17: 0000007f95539e18 x16: 0000000000000000 
[  146.028079] x15: 0000000000000000 x14: 0000000000000000 
[  146.033571] x13: 0000000000000000 x12: 0000000000000000 
[  146.039060] x11: 00000000afb50401 x10: 00000000000007a0 
[  146.044551] x9 : ffffffc0784cfed0 x8 : 00000000ffff6974 
[  146.050042] x7 : 00000021f981b620 x6 : 0000000000000001 
[  146.055532] x5 : 000000007e246000 x4 : 0000000000000000 
[  146.061024] x3 : 00000000000001c0 x2 : ffffffc000e4e008 
[  146.066513] x1 : 000000007e246000 x0 : 0000000000000000 
[  146.072002] 
[  146.073534] Process swapper/1 (pid: 0, stack limit = 0xffffffc0784cc020)
[  146.080461] Stack: (0xffffffc0784cff70 to 0xffffffc0784d0000)
[  146.086398] ff60:                                   ffffffc0784cffd0 ffffffc00008e368
[  146.094404] ff80: 0000000000000001 0000000000000e12 ffffffc000e406b0 0000000000000000
[  146.102408] ffa0: 0000000000000000 0000000000000000 0000000000e85000 0000000000e88000
[  146.110412] ffc0: ffffffc000082810 0000000000000000 0000000000000000 00000000000827fc
[  146.118955] ffe0: 0000000000000000 0000000000000000 5555555555555555 5555555555555555
[  146.127054] Call trace:
[  146.129493] [<ffffffc0001058e8>] rcu_idle_enter+0x0/0x58
[  146.134981] [<ffffffc00008e368>] secondary_start_kernel+0x130/0x158
[  146.141363] [<00000000000827fc>] 0x827fc
[  146.145324] Code: 88017c40 35ffffa1 d5033bbf d65f03c0 (a9bf7bfd) 
[  146.151854] ---[ end trace 23c4e4d5739f5e1a ]---
[  146.156590] Kernel panic - not syncing: Attempted to kill the idle task!
[  146.163448] CPU0: stopping
[  146.163459] CPU: 0 PID: 1 Comm: systemd Tainted: G      D         4.4.112-mvebu64 #8
[  146.163462] Hardware name: Marvell Armada 3720 Community Board (DT)
[  146.163463] Call trace:
[  146.163478] [<ffffffc000089910>] dump_backtrace+0x0/0x108
[  146.163484] [<ffffffc000089a2c>] show_stack+0x14/0x20
[  146.163490] [<ffffffc0004eab68>] dump_stack+0x98/0xb8
[  146.163496] [<ffffffc00008e8a8>] handle_IPI+0x1a8/0x1b8
[  146.163500] [<ffffffc000082598>] gic_handle_irq+0x78/0x168
[  146.163504] Exception stack(0xffffffc0784838d0 to 0xffffffc078483a00)
[  146.163508] 38c0:                                   ffffffc078478000 0000008000000000
[  146.163512] 38e0: ffffffc078483a30 ffffffc0009e8280 0000000060000145 0000000000000000
[  146.163517] 3900: ffffffc07efc2f00 0000000000004ac7 000000007e236000 0000000000000002
[  146.163521] 3920: 00000000000100eb 0000000000000000 0000000000000000 ffffffc07efc2fc0
[  146.163525] 3940: ffffffc078478800 ffffffc078483a70 00000000000007a0 ffffffc0779bdd00
[  146.163529] 3960: 0000000000000003 00000000000e9a18 0000000000000008 003b9aca00000000
[  146.163533] 3980: 0000007fa8bd6b28 0000007fa8a8b300 0000000000000061 ffffffc078478000
[  146.163537] 39a0: ffffffc07efc2f00 0000000000000000 ffffffc0770b0b80 ffffffc0009e496c
[  146.163542] 39c0: 0000000000000000 ffffffc0009e44e4 0000000000000000 0000005588f8c1d0
[  146.163546] 39e0: ffffffc078483dd0 ffffffc078483a30 ffffffc0000d8188 ffffffc078483a30
[  146.163551] [<ffffffc000085700>] el1_irq+0x80/0xf8
[  146.163556] [<ffffffc0000d8188>] finish_task_switch+0x70/0x220
[  146.163565] [<ffffffc0009e44e4>] __schedule+0x194/0x5d8
[  146.163569] [<ffffffc0009e496c>] schedule+0x44/0xb8
[  146.163575] [<ffffffc0009e7600>] schedule_timeout+0x158/0x1a8
[  146.163578] [<ffffffc0009e6580>] __down+0x60/0x98
[  146.163585] [<ffffffc0000f1704>] down+0x4c/0x68
[  146.163590] [<ffffffc0000f62a8>] console_lock+0x18/0x38
[  146.163598] [<ffffffc000678ab8>] show_cons_active+0x20/0x150
[  146.163605] [<ffffffc0006bbe80>] dev_attr_show+0x20/0x58
[  146.163611] [<ffffffc00023d1f4>] sysfs_kf_seq_show+0xb4/0x148
[  146.163615] [<ffffffc00023bb48>] kernfs_seq_show+0x28/0x30
[  146.163622] [<ffffffc0001eb22c>] seq_read+0x174/0x420
[  146.163625] [<ffffffc00023c5bc>] kernfs_fop_read+0x10c/0x198
[  146.163632] [<ffffffc0001c7208>] __vfs_read+0x18/0x40
[  146.163637] [<ffffffc0001c7a1c>] vfs_read+0x7c/0x148
[  146.163641] [<ffffffc0001c8624>] SyS_read+0x44/0xa0
[  146.163646] [<ffffffc000085e30>] el0_svc_naked+0x24/0x28
[  146.394930] ---[ end Kernel panic - not syncing: Attempted to kill the idle task!

[y52]

I have trouble understanding i-net interfaces on Armbian and the way setting them up.

The bridge always includes the wan, while I thought that the latter should not be part of it. Wan should service an external network segment,  while the lan i-faces are intended for the lan segment, as their name stand for.

root@espressobin:~# brctl show    
bridge name     bridge id               STP enabled     interfaces
br0             8000.bab24a6a1ecd       no              lan0
                                                                                lan1
                                                                                wan

Even if I want to remove the wan from the bridge, I am unable doing so.

root@espressobin:~# brctl delif br0 wan

Gives no changes to the bridge.

 

The following sources show, that the bridge is assembled from lan0, lan1 and wan :

https://github.com/armbian/build/tree/master/packages/bsp/mvebu64

 

while eth0 is a stand alone one.

 

Could the development team clarify each network interface designation ? How could a network be set up?

What is the use of MAC addresses, which are built into the u-boot loader?

My board lists the following in the boot loader,

eth1addr=00:51:82:11:22:01
eth2addr=00:51:82:11:22:02
eth3addr=00:51:82:11:22:03
ethact=neta@30000
ethaddr=00:51:82:11:22:00

while a single ethaddr is assigned to all 4 ports lan0, lan1, eth0 and wan by Armbian (which is strange for me). 

 

Some changes were made to the system, which altered the way the interfaces are configured.

Thus, I am unable propagating my network settings through the /etc/network/interfaces configuration. 

 

 

ebin-dev commented on 23 Sep 2017 •

fix of 'job for raising network interfaces' interrupting the boot sequence:
systemd-networkd is configured as a switch (with bridged interfaces)
NetworkManager is configured not to manage any interface

[ebin-dev]

The network configuration files of systemd-networkd reside in /etc/systemd/network/ 

[y52]

I ve understood it already earlier today and changed several settings under the Systemd style.

Check the root@espressobin:/etc/systemd/network# cat 10-wan.network                
[Match]
Name=wan 

[Network]
#Bridge=br0
DHCP=ipv4

I believe, that  #Bridge=br0 should be disabled, as mentioned earlier.

Now the bridge shows

root@espressobin:/etc/systemd/network# brctl show                         
bridge name     bridge id               STP enabled     interfaces
br0             8000.bab24a6a1ecd       no              lan0
                                                                     lan1

 

I still don't understand the eth0 designation, and I am troubled with the mac address usage.

root@espressobin:/etc/systemd/network# ip addr show 

2: eth0:

    link/ether 00:51:82:11:22:00

3: wan@eth0:

    link/ether 00:51:82:11:22:00

4: lan0@eth0:

    link/ether 00:51:82:11:22:00

5: lan1@eth0:

    link/ether 00:51:82:11:22:00

 

Why are wan,  lan0 and lan1 bound to  @eth0 and mac addresses are the same for 4 interfaces?

What is the eth0 used for ?

Edited February 25, 2018 by y52
spelling mistake

[chrisf]

2 minutes ago, y52 said:

What is the eth0 used for ?

 

Is it the physical interface that connects the SoC to the switch.

 

The 3 ports on the board connect to the switch, not a typical network interface.

[y52]

The SOC eth0 designation is hinted by

root@espressobin:/etc/systemd/network# ls -al /sys/class/net/  

eth0 -> ../../devices/platform/soc/soc:internal-regs/d0030000.ethernet/net/eth0 

 

It is very contradictory,  that "3 ports on the board connect to the switch".  A typical router should have at least 1 wan. and 1 lan.

It will bring additional difficulty to the Armbian users.

 

Is the single MAC usage for 4 ports justified by any reason?

 

[chrisf]

3 minutes ago, y52 said:

The SOC eth0 designation is hinted by

root@espressobin:/etc/systemd/network# ls -al /sys/class/net/  

eth0 -> ../../devices/platform/soc/soc:internal-regs/d0030000.ethernet/net/eth0 

 

It is very contradictory,  that "3 ports on the board connect to the switch".  A typical router should have at least 1 wan. and 1 lan.

It will bring additional difficulty to the Armbian users.

 

Is the single MAC usage for 4 ports justified by any reason?

 

 

When you do your bridging, the switch driver configures how the ports forward to each other through the MDIO link. The switch tags packets from the different ports so the kernel knows which interface they're coming from.

 

It might make more sense if you read the DTS file

https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts

 

Have a look in the mdio section, you can see there are 4 ports defined.  Port 0 is eth0 which is an rgmii link between the SoC and the switch  Ports 1, 2, and 3 are the physical ports.

I don't see why they couldn't each have their own MAC address though.

 

[y52]

Does this bridging technique through the MDIO link allow setting up WAN differently from LAN ?

The WAN port should assign address through DHCP, while the LAN switch should keep a fixed one.  I was only able doing it through separating WAN from LAN. 

root@espressobin:/etc/systemd/network# cat 10-br0.network                 
[Match]
Name=br0

[Network]
#DHCP=ipv4
Address=192.168.x.97/24
Gateway=192.168.x1
DNS=192.168.x.1

 

How do you handle this network setup ?

[chrisf]

10 minutes ago, y52 said:

Does this bridging technique through the MDIO link allow setting up WAN differently from LAN ?

The WAN port should assign address through DHCP, while the LAN switch should keep a fixed one.  I was only able doing it through separating WAN from LAN. 

root@espressobin:/etc/systemd/network# cat 10-br0.network                 
[Match]
Name=br0

[Network]
#DHCP=ipv4
Address=192.168.x.97/24
Gateway=192.168.x1
DNS=192.168.x.1

 

How do you handle this network setup ?

Yes it does. The packets from Wan can be forwarded only to eth0, which the kernel is then responsible for forwarding to the lan interfaces. 

As to how best to configure that, I'm not an expert in Linux networking.

 

It does mean that all traffic betwen Wan and Lan must go through eth0 twice, which is only 1gbps

[y52]

It is interesting for internal infrastructure. Anyway the essential question today is how to handle the network configuration and little information is available so far for Armbian.

[y52]

My network setup raised more kernel panic :

Debian GNU/Linux 9 espressobin ttyMV0

espressobin login: root
Password: 
[   34.490520] Bad mode in Error handler detected, code 0xbf000001 -- SError
[   34.497481] Internal error: Oops - bad mode: 0 [#1] PREEMPT SMP
[   34.503686] Modules linked in: bridge stp llc ip_tables x_tables
[   34.509739] CPU: 0 PID: 1 Comm: systemd Not tainted 4.4.112-mvebu64 #8
[   34.516573] Hardware name: Marvell Armada 3720 Community Board (DT)
[   34.523057] task: ffffffc078478000 ti: ffffffc078480000 task.ti: ffffffc078480000

..

[   34.791546] [<ffffffc000085700>] el1_irq+0x80/0xf8
[   34.796229] [<ffffffc00008958c>] do_notify_resume+0x74/0x80
[   34.802170] [<ffffffc000085d28>] work_pending+0x1c/0x20
[   34.807487] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

[ebin-dev]

So - what do you conclude from all that ?

 

What happens to all those kernel panics if you flash your device to 600_600 (with adapted /etc/default/cpufrequtils) ?

[y52]

I am quite frustrated with the discrepancy from the announced hardware CPU clock (1200 Mhz) and its evident inability running at even 20% slower 1000 Mhz speed. I found the board more stable at 800 Mhz CPU clock, allowing making some test bed works. I've requested RMA for the board.

Anyway, Armbian is in a very early development for that board.

It still lacks the USB automatic booting feature. Could a development team build one separate image or integrate USB booting with the updated one to continue testing the board?

The Armbian legacy build has other hitches to overcome. My other immediate bottleneck issue is that network interfaces do not start up and are not accessible after the OS boot before I restart manually  on each boot:

root@espressobin:~# service systemd-networkd restart

There are other minor annoyances, which could be overcome and many other services have not yet been tested.

 

In conclusion : if nothing is corrected, Espressobin bound with Armbian can not be recommended for production installations in the current state.

 

 

[Igor]

1 hour ago, y52 said:

Espressobin bound with Armbian can not be recommended for production installations in the current state

You don't have any better alternative. Other builds are not even on this level. I would not say we are in the early development. Just development. To my observation, it looks like those stability issues are tied to some particular board revision(s). Some work good. 
 

1 hour ago, y52 said:

Could a development team ...

The development team is exhausted and we don't receive help not even for simple tasks which we ask 

• https://forum.armbian.com/topic/4089-espressobin-support-development-efforts/?do=findComment&comment=49271 (taking some responsibility)
• https://forum.armbian.com/topic/6420-preparing-for-ubuntu-1804/ (copy pasting and test)

 

[umiddelb]

3 hours ago, y52 said:

I am quite frustrated with the discrepancy from the announced hardware CPU clock (1200 Mhz) and its evident inability running at even 20% slower 1000 Mhz spped. I found the board more stable at 800 Mhz CPU clock, allowing making some test bed works. I've requested RMA for the board.

Anyway, Armbian is in a very early development for that board.

It still lacks the USB automatic booting feature. Could a development team build one separate image or integrate USB booting with the updated one to continue testing the board?

The Armbian legacy build has other hitches to overcome. My other immediate bottleneck issue is that network interfaces do not start up and accessible after the OS boot before I restart manually  on each boot:

root@espressobin:~# service systemd-networkd restart

There are other minor annoyances, which could be overcome and many other services have not yet been tested.

 

In conclusion : if nothing is corrected, Espressobin bound with Armbian can not be recommended for production installations in the current state.

 

 

Hm, you might consider to align your expectations with the capabilities of the Armbian project. There is only a handful of people running this project during their spare time. If you are unsatisfied with the EspressoBins's current software support please drop a message at the vendor's community portal.

Regarding your complaints.

• USB booting: recent u-boot firmware supports booting from USB devices. With some u-boot scripting knowledge you should be able to implement USB automatic booting. 
• Network interfaces startup on boot:  please take your time to read through this thread, I'm totally happy with this configuration. 

I don't know your exact requirements. If mainline Linux kernel support is one of them the EspressoBin is a good choice IHMO. 

[y52]

5 minutes ago, umiddelb said:

USB booting: recent u-boot firmware supports booting from USB devices. With some u-boot scripting knowledge you should be able to implement USB automatic booting. 

This dual MMC/USB boot capability in "flash-image-2g-CPUclock_RAM_boot_sd_and_usb.bin" has never been explained.

The execution result is :  Bad Linux ARM64 Image magic!

If it really exists, could somebody drop a note on how to launch a MMC or USB boot of a choice and remember that choice to boot the OS from the board the next time automatically?

I do boot from USB, but I need interrupting the u-boot stages and replace the mmc boot sequences, built into the firmware with those of USB boot environment and launch USB manually.  I believe a different firmware should be built for booting from USB.

If you require more testers to join, this issue should be resolved in the 1st run.

[chrisf]

15 minutes ago, umiddelb said:

Hm, you might consider to align your expectations with the capabilities of the Armbian project. There is only a handful of people running this project during their spare time. If you are unsatisfied with the EspressoBins's current software support please drop a message at the vendor's community portal.

I have no issues whatsoever with the Armbian project.  I think the team do an excellent job overall

 

Personally I wouldn't recommend Espressobin for production usage either, due to the excessive number of issues reported with kernel panics than only appear to be mitigated by firmware forcing low clock speeds. My board is unstable on 800/800 and 1000/800. It only works on 600/600 or 1200/750. There have been other posts saying they can't run 1200MHz. Some people have no issues with 1000/800MHz.

 

It all smells of poor board layout, where the tolerances in the SoC or DRAM chips make it a hit-or-miss as to what speed you can run.

I had high hopes for Espressobin due to GlobalScale being a long standing company with successful products behind them (they started the whole plug computer thing with the SheevaPlug didn't they?)