Jump to content

Espressobin support development efforts


lanefu

Recommended Posts

22 minutes ago, umiddelb said:

Network interfaces startup on boot:  please take your time to read through this thread, I'm totally happy with this configuration

The quoted configuration looks to be outdated, as, as long as I understood it, Armbian supports the move to Systemd-style and the use of "/etc/network/interfaces" file is deprecated.

Link to comment
Share on other sites

12 hours ago, chrisf said:

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?)

 

I have several 1G EspressoBin boards around and they are stable with Armbian (Debian stretch with legacy kernel). The important aspect is not to expose them to excessive electrical/thermal strain.

 

Thermal strain can easily be avoided by using a heat sink/fan or a huge passive heat sink (i.e. aluminium housing). CPU temperature will then stay below 35 degrees. 

 

Electrical strain arises if you power the board with two different GND potentials (AC or DC differences) while using the console - it will heat up substantially. 

You can harm your board within a few minutes. It can be avoided if you use a battery driven laptop to connect to the console.

 

Did you ever measure the temperature of CPU / PMU / Topaz of your device during operation - in particular while being connected to the console ?

 

If there is anything to improve then I would say that the vendor should sell EspressoBins with an enclosure together with an active or passive cooling mechanism and to reduce the effects of electrical strain on the board.

 

You can not draw any conclusions about Armbian from using a defective board ...

Link to comment
Share on other sites

On 27/02/2018 at 11:21 PM, y52 said:

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.

I'm using this vendor Armbian provided firmware for my EspressoBin (2GB):

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

Model: Marvell Armada 3720 Community Board ESPRESSOBin
       CPU    @ 1000 [MHz]
       L2     @ 800 [MHz]
       TClock @ 200 [MHz]
       DDR    @ 800 [MHz]
DRAM:  2 GiB
U-Boot DT blob at : 000000007f7182d8
Comphy-0: USB3          5 Gbps
Comphy-1: PEX0          2.5 Gbps
Comphy-2: SATA0         6 Gbps

If you are familiar with the u-boot console, you may try to import this u-boot environment. It contains a collection of scripts which help you to boot different boot configurations. If there is no interaction on the console the boot procedure will try to boot from different devices.

Some more information about the script collection and the filesystem layout wrt the kernel/initrd/dtb images can be found here. You don't need to build individual firmware images for USB, SATA, MMC boot. It's all handled inside of the `bootcmd´ macro. 

Edited by umiddelb
error correction
Link to comment
Share on other sites

8 hours ago, umiddelb said:

If you are familiar with the u-boot console, you may try to import this u-boot environment.

Is this import done directly into the boot console ?

8 hours ago, umiddelb said:

the boot procedure will try to boot from different devices.

This is an elegant solution. I shall try understanding the code and implementing it on my board, although I am not familiar a lot with the u-boot.

Link to comment
Share on other sites

3 hours ago, y52 said:

Is this import done directly into the boot console ?

Yes, the file needs to be accessible within the u-boot console.

Load the file at the address reserved for the kernel image and the run `env import $loadaddr $filesize;´. Try if the board boots as expected, then import the environment once again but run a `saveenv´ before booting.

3 hours ago, y52 said:

although I am not familiar a lot with the u-boot.

This article contains some beginner information.

Link to comment
Share on other sites

23 hours ago, y52 said:

The quoted configuration looks to be outdated, as, as long as I understood it, Armbian supports the move to Systemd-style and the use of "/etc/network/interfaces" file is deprecated.

I wouldn't care as long as the upstream distributions (stretch, xenial, bionic) will support it.

 

Link to comment
Share on other sites

23 hours ago, chrisf said:

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.

I've experienced some strange crashes with the 4.4 BSP kernel, but the mainine kernel runs quite stable.    

Link to comment
Share on other sites

1 hour ago, umiddelb said:

the file needs to be accessible within the u-boot console.

Load the file at the address reserved for the kernel image and the run `env import $loadaddr $filesize;´.

The documents and explanations are extremely helpful, allowing to understand the U-Boot environment.

When reading, I was unable finding the method on how the address reserved for the kernel image is referred to :  through the system handle  $loadaddr or as a hex value? In the latter case, where this hex value could be found for any specific board?

 

Is there any reason not to implement your multimedia boot script into Armbian? It looks promising for a general  and flexible solution.

 

Based on this information I was able changing manually the bootcmd variable and boot into the board automatically.

 

 

 

Link to comment
Share on other sites

If anyone is interested in lowering the heat from the board, I've used a 5.9V/3.8A switchmode power supply with great success.

A 5.2V/2A PSU should be enough, though - my PSU just happened to be 3.8A.

The Voltage range for the PSU should be above 5.2V and below 12.5V. There is an on-board 13V zener, this is in order to try and protect any attached harddisk from a spike.

As for current, anything above 2A should be fine. If you're planning on powering a 3.5 inch harddisk from the board, stick with a 12.2V PSU.

-If you're planning on using a 2.5 inch harddisk, you can run on low input voltage between 5.2V and 12.5V.

 

Personally, I'll be using 2.5 inch WD Red drives because they consume very little power.

I might also add a liquid cooler (cheap aluminum blocks from eBay and a silent <5dB, <6W, 0 .. 8L/min pump) - I hate noise.

Note: I have not had any crashes or other issues with my 2GB boards - not even while running the boards on a 12.25V PSU with a 3.5 inch harddisk; the cooling is likely not even necessary, as the boards will be installed in an always-cold room. If, however, I add the cooling, I'll run the pump slowly, so it'll likely use less than 1W anyway.

Link to comment
Share on other sites

22 hours ago, y52 said:

When reading, I was unable finding the method on how the address reserved for the kernel image is referred to :  through the system handle  $loadaddr or as a hex value? In the latter case, where this hex value could be found for any specific board?

You may take 0x02000000 as a load address.  

Link to comment
Share on other sites

On 28/02/2018 at 9:49 PM, umiddelb said:

 

 

It would be nice implementing this multimedia boot script into the next Armbian update.

 

I was setting up a network and noticed a significant conflict between the NetworkManger and the systemd network.

Is there any reason leaving them both running ?

 

I was unable to disable NetworkManager.service booting each time with

root@espressobin:~# systemctl stop NetworkManager.service

root@espressobin:~# systemctl disable NetworkManager.service.

 

It pops up on every reboot.  Its init.d startup script is left active :

root@espressobin:~# ls -al /etc/rc3.d/
lrwxrwxrwx  1 root root   25 Jan 25 16:01 S04network-manager -> ../init.d/network-manager

 

What will definitively stop booting the NetworkManager without uninstalling it?

 

Another network discrepancy :

root@espressobin:~# dhclient -v wlx0001e010301d

/etc/resolvconf/update.d/libc: Warning: /etc/resolv.conf is not a symbolic link to
/etc/resolvconf/run/resolv.conf

 

root@espressobin:~# ls -al /etc/resolv.conf
lrwxrwxrwx 1 root root 32 Jan 27 13:34 /etc/resolv.conf -> /run/systemd/resolve/resolv.conf

 

Which one is the right location for the resolv.conf ? How could it be corrected ?

 

 

I also found another inconvenience with the network interface naming. Thus my WiFi i-face was given a "wlx0001e010301d" name.  Is there a general solution changing the name assignment and reduce the string to 4-5 length, like wlan0 or wlx01 ?   

Link to comment
Share on other sites

 

Logging has been suspended all of a sudden : 

Mar  4 10:48:52 localhost liblogging-stdlog: action 'action 1' resumed (module 'builtin:omfile') [v8.24.0 try http://www.rsyslog.com/e/2359 ]
Mar  4 10:48:52 localhost liblogging-stdlog: action 'action 1' resumed (module 'builtin:omfile') [v8.24.0 try http://www.rsyslog.com/e/2359 ]
Mar  4 10:48:52 localhost liblogging-stdlog: action 'action 1' suspended, next retry is Sun Mar  4 10:49:22 2018 [v8.24.0 try http://www.rsyslog.com/e/2007 ]

 

I was not able restoring it with the

root@espressobin:~# systemctl restart rsyslog.service

 

It stays clogged for some reason.

Link to comment
Share on other sites

Is there some log file size restrictions ?

 

The following resumed logging ;

root@espressobin:/var/log# : > messages
root@espressobin:/var/log# : > wtmp
root@espressobin:/var/log# echo "Log files cleaned up."
Log files cleaned up.
root@espressobin:/var/log# systemctl restart rsyslog.service

Link to comment
Share on other sites

On 03/03/2018 at 3:37 PM, y52 said:

What will definitively stop booting the NetworkManager without uninstalling it?

Has anybody managed preventing the NetworkManager from launching at startup ?

Simply disabling this service did not help because it seems that it is called from somewhere else.

 


root@espressobin:~# systemctl list-unit-files

network-manager.service                disabled 
networking.service                     enabled  
NetworkManager-dispatcher.service      disabled 
NetworkManager-wait-online.service     disabled 
NetworkManager.service                 disabled 

 

And despite this, it is still started :
[  OK  ] Started D-Bus System Message Bus.
         Starting System Logging Service...
         Starting Network Manager...
[  OK  ] Started Network Manager.
         Starting WPA supplicant...
[  OK  ] Started Authorization Manager.
[  OK  ] Started WPA supplicant.
[  OK  ] Started LSB: Armbian gathering hardware information.
[ TIME ] Timed out waiting for device sys-subsystem-net-devices-wlan.device.
[DEPEND] Dependency failed for WPA supplican…emon (interface-specific version).
[ TIME ] Timed out waiting for device sys-su…et-devices-wlx0001e010301d.device.
[DEPEND] Dependency failed for WPA supplican…emon (interface-specific version).
[  OK  ] Reached target Network.


root@espressobin:~# journalctl -u NetworkManager
-- Logs begin at Sun 2018-03-04 23:20:52 CET, end at Sun 2018-03-04 23:23:55 CET. --
Mar 04 23:20:54 espressobin systemd[1]: Starting Network Manager...
Mar 04 23:20:55 espressobin NetworkManager[569]: <info>  [1520202055.9381] NetworkManager (version 1.6.2) is starting...
Mar 04 23:20:55 espressobin NetworkManager[569]: <info>  [1520202055.9407] Read config: /etc/NetworkManager/NetworkManager.conf (lib
Mar 04 23:20:56 espressobin NetworkManager[569]: <info>  [1520202056.0053] manager[0x55a4b48040]: monitoring kernel firmware directo
Mar 04 23:20:56 espressobin NetworkManager[569]: <info>  [1520202056.0056] monitoring ifupdown state file '/run/network/ifstate'.
Mar 04 23:20:56 espressobin NetworkManager[569]: <info>  [1520202056.0673] dns-mgr[0x55a4b3c1a0]: init: dns=systemd-resolved, rc-man
Mar 04 23:20:56 espressobin NetworkManager[569]: <info>  [1520202056.0884] rfkill0: found WiFi radio killswitch (at /sys/devices/pla
Mar 04 23:20:56 espressobin NetworkManager[569]: <info>  [1520202056.0976] manager[0x55a4b48040]: WiFi hardware radio set enabled
Mar 04 23:20:56 espressobin NetworkManager[569]: <info>  [1520202056.0994] manager[0x55a4b48040]: WWAN hardware radio set enabled
Mar 04 23:20:56 espressobin systemd[1]: Started Network Manager.
 

Link to comment
Share on other sites

This doesn't result in disabling NetworkManager either :

root@espressobin:~# systemctl mask NetworkManager.servce
Unit NetworkManager.servce.service does not exist, proceeding anyway.
Created symlink /etc/systemd/system/NetworkManager.servce.service → /dev/null.

 

[  OK  ] Started Network Manager.

 

root@espressobin:~# journalctl -u NetworkManager
-- Logs begin at Mon 2018-03-05 00:06:18 CET, end at Mon 2018-03-05 00:08:42 CET. --
Mar 05 00:06:19 espressobin systemd[1]: Starting Network Manager...
Mar 05 00:06:21 espressobin NetworkManager[547]: <info>  [1520204781.8002] NetworkManager (version 1.6.2) is starting...

 

root@espressobin:~# systemctl status NetworkManager
● NetworkManager.service - Network Manager
   Loaded: loaded (/lib/systemd/system/NetworkManager.service; disabled; vendor preset: enabled)
   Active: active (running) since Mon 2018-03-05 00:06:22 CET; 3min 44s ago
     Docs: man:NetworkManager(8)
 Main PID: 547 (NetworkManager)
    Tasks: 3 (limit: 4915)
   CGroup: /system.slice/NetworkManager.service
           └─547 /usr/sbin/NetworkManager --no-daemon

 

I am running out of ideas.

Link to comment
Share on other sites

6 hours ago, y52 said:

systemctl mask NetworkManager.servce


You made a typo. That's why id doesn't work.
 

systemctl start NetworkManager.servce
 

systemctl start NetworkManager.service

Link to comment
Share on other sites

4 hours ago, Igor said:

You made a typo. That's why id doesn't work.

Igor,

Yes, you are right.  Thanks!

root@espressobin:~# systemctl mask NetworkManager.service
Created symlink /etc/systemd/system/NetworkManager.service → /dev/null.

 

root@espressobin:~# journalctl -u NetworkManager
-- No entries --

 

root@espressobin:~# systemctl status NetworkManager
● NetworkManager.service
   Loaded: masked (/dev/null; bad)
   Active: inactive (dead)

 

root@espressobin:~# systemctl list-unit-files
network-manager.service                masked   
networking.service                     enabled  
NetworkManager-dispatcher.service      disabled 
NetworkManager-wait-online.service     disabled 
NetworkManager.servce.service          masked   
NetworkManager.service                 masked   
ntp.service                            generated

 

The system becomes more clean and manageable without the NetworkManager intervention. 

Link to comment
Share on other sites

On 03/03/2018 at 3:37 PM, y52 said:

/etc/resolvconf/update.d/libc: Warning: /etc/resolv.conf is not a symbolic link to
/etc/resolvconf/run/resolv.conf

 

root@espressobin:~# ls -al /etc/resolv.conf
lrwxrwxrwx 1 root root 32 Jan 27 13:34 /etc/resolv.conf -> /run/systemd/resolve/resolv.conf

 

Which one is the right location for the resolv.conf ? How could it be corrected ?

Any ideas on that as well ?

Link to comment
Share on other sites

On 03.03.2018 at 5:37 PM, y52 said:

Another network discrepancy :

root@espressobin:~# dhclient -v wlx0001e010301d

/etc/resolvconf/update.d/libc: Warning: /etc/resolv.conf is not a symbolic link to
/etc/resolvconf/run/resolv.conf

 

root@espressobin:~# ls -al /etc/resolv.conf
lrwxrwxrwx 1 root root 32 Jan 27 13:34 /etc/resolv.conf -> /run/systemd/resolve/resolv.conf

 

Which one is the right location for the resolv.conf ? How could it be corrected ?

Currently /etc/resolv.conf is managed by systemd-resolved, if systemd-networkd is used in conjunction with systemd-resolved than this symlink is correct and it is safe to ignore the warning. If network is configured differently (NM, /etc/network/interfaces) then it should be relinked to a different path.

Link to comment
Share on other sites

I prefer setting up a pure systemd system, thus not increasing the compatibility difficulties. But the learning curve for the new (at least for me)  systemd setup could overshadow this consideration. 

4 minutes ago, Smurfix said:

you need to disable resolvconf.

I believe the symlink to /etc/resolv.conf should be preserved. Have you meant anything else?

Link to comment
Share on other sites

Globalscale Technologies provided with their default firmware on the following link, it runs 1000MHz with 17.10 kernel:

https://www.dropbox.com/sh/e2dnsk4e5upf0bp/AACuFB9Iu46xLZx1IXGo7ohQa?dl=0

 

The espressobin-rootfs-v0.8-20180129-REL.tar.gz contains more firmware flash files :

root@espressobin:/espressobin/boot/bootloader# ls -al
 4194304 Jan 29 11:22 espressobin-bootloader-cpu-1000-ddr3-1cs-1g-atf-ga3306ab-uboot-gaee49fc-20180129-REL.bin
 4194304 Jan 29 11:22 espressobin-bootloader-cpu-1000-ddr3-2cs-1g-atf-ga3306ab-uboot-gaee49fc-20180129-REL.bin
 4194304 Jan 29 11:22 espressobin-bootloader-cpu-1000-ddr3-2cs-2g-atf-ga3306ab-uboot-gaee49fc-20180129-REL.bin
 4194304 Jan 29 11:23 espressobin-bootloader-cpu-1000-ddr4-1cs-1g-atf-ga3306ab-uboot-gaee49fc-20180129-REL.bin
 4194304 Jan 29 11:23 espressobin-bootloader-cpu-1000-ddr4-2cs-2g-atf-ga3306ab-uboot-gaee49fc-20180129-REL.bin
 4194304 Jan 29 11:23 espressobin-bootloader-cpu-1200-ddr3-1cs-1g-atf-ga3306ab-uboot-gaee49fc-20180129-REL.bin
 4194304 Jan 29 11:23 espressobin-bootloader-cpu-1200-ddr3-2cs-1g-atf-ga3306ab-uboot-gaee49fc-20180129-REL.bin
 4194304 Jan 29 11:23 espressobin-bootloader-cpu-1200-ddr3-2cs-2g-atf-ga3306ab-uboot-gaee49fc-20180129-REL.bin

root@espressobin:/espressobin/boot/bootloader# ls -al ../
total 13396
drwxr-xr-x  3 root root     4096 Jan 29 11:24 .
drwxr-xr-x 21 root root     4096 Mar  5 23:10 ..
-rwxr-xr-x  1 root root    11727 Jan 29 11:24 armada-3720-community.dtb
-rwxr-xr-x  1 root root    11739 Jan 29 11:24 armada-3720-community-v5.dtb

 

They claim, that currently they don’t have customers complaining the speed and unstable issue.

 

It would be worth learning a broad community experience if the board stability is improved with the new U-Boot build.

Link to comment
Share on other sites

My experience is so far good at least for the above new u-boot build with CPU    @ 1000 [MHz] and DDR    @ 800 [MHz].

My board is a v.5 one, hence, I used the

Marvell>> printenv fdt_name  
fdt_name=boot/dtb/marvell/armada-3720-community-v5.dtb

 

WTMI-armada-17.10.1-b90dbf0
ENTER init_ddrgen
DDR_TOPOLOGY is 7 :     DDR3, 2CS 1G + 1G
WTMI_CLOCK=2

Fill memory before self refresh...done

Fill memory before self refresh...done

Now in Self-refresh Mode
Restore CAS Read and Write Latency
Restore termination values to original values
Exited self-refresh ...

DLL TUNING
==============
   DLL 0xc0001050[21:16]: [0,30,18]
   DLL 0xc0001050[29:24]: [5,36,1d]
   DLL 0xc0001054[21:16]: [0,25,12]
   DLL 0xc0001054[29:24]: [3,33,1b]
   DLL 0xc0001074[21:16]: [0,3f,1f]
   DLL 0xc0001074NOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v1.3(release):armada-17.10.3:a3306ab
NOTICE:  BL1: Built : 18:22:52, Jan 29 2NOTICE:  BL2: v1.3(release):armada-17.10.3:a3306ab
NOTICE:  BL2: Built : 18:22:53, Jan 29 2018NOTICE:  BL31: v1.3(release):armada-17.10.3:a3306ab
NOTICE:  BL31:

U-Boot 2017.03-armada-17.10.1-gaee49fc (Jan 29 2018 - 18:21:49 +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 DT blob at : 000000007f7161b8
Comphy-0: USB3          5 Gbps    
Comphy-1: PEX0          2.5 Gbps  
Comphy-2: SATA0         6 Gbps    
SATA link 0 timeout.
AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode
flags: ncq led only pmp fbss pio slum part sxs 
PCIE-0: Link down
MMC:   sdhci@d0000: 0, sdhci@d8000: 1
SF: Detected w25q32dw with page size 256 Bytes, erase size 4 KiB, total 4 MiB
Net:   eth0: neta@30000 [PRIME]
Hit any key to stop autoboot:  0 
resetting USB...
USB0:   Register 2000104 NbrPorts 2
Starting the controller
USB XHCI 1.00
USB1:   USB EHCI 1.00
scanning bus 0 for devices... cannot reset port 2!?
2 USB Device(s) found
scanning bus 1 for devices... 2 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
14405120 bytes read in 184 ms (74.7 MiB/s)
** No boot file defined **
11739 bytes read in 45 ms (253.9 KiB/s)
## Flattened Device Tree blob at 04f00000
   Booting using the fdt blob at 0x4f00000
   Using Device Tree in place at 0000000004f00000, end 0000000004f05dda

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] 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
[    0.000000] Boot CPU: AArch64 Processor [410fd034]
[    0.000000] earlycon: Early serial console at MMIO 0xd0012000 (options '')
[    0.000000] bootconsole [uart0] enabled
[    0.000000] efi: Getting EFI parameters from FDT:
[    0.000000] efi: UEFI not found.
[    0.000000] cma: Reserved 16 MiB at 0x000000007f000000
[    0.000000] psci: probing for conduit method from DT.
[    0.000000] psci: PSCIv1.0 detected in firmware.
[    0.000000] psci: Using standard PSCI v0.2 function IDs
[    0.000000] psci: MIGRATE_INFO_TYPE not supported.
[    0.000000] PERCPU: Embedded 16 pages/cpu @ffffffc07efbf000 s25240 r8192 d32104 u65536
[    0.000000] Detected VIPT I-cache on CPU0
[    0.000000] CPU features: enabling workaround for ARM erratum 845719
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 515584
[    0.000000] Kernel command line: console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 root=/dev/sda1 rw rootwait
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
[    0.000000] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
[    0.000000] software IO TLB [mem 0x78a00000-0x7ca00000] (64MB) mapped at [ffffffc078a00000-ffffffc07c9fffff]
[    0.000000] Memory: 1962244K/2095104K available (9681K kernel code, 587K rwdata, 3328K rodata, 352K init, 288K bss, 116476K reserved, 16384K cma-reserved)

 

It is early to make a judgement, but it looks stable and quiet :

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

12:37:31: 1000MHz  0.56  23%   5%  11%   0%   5%   0%
12:37:36:    0MHz  0.51   1%   0%   0%   0%   0%   0%
12:37:41:    0MHz  0.47   2%   1%   0%   0%   0%   0%
12:37:46:    0MHz  0.43   0%   0%   0%   0%   0%   0%
 

 

What happens to the board on the Shutdown ?

[  OK  ] Reached target Shutdown.
[ 2545.498405] reboot: Power down
ERROR:   a3700_systPANIC at PC : 0x0000000004023248
 

Is it capable to power off completely ? The board doesn't switch off after a powerdown.

 

Link to comment
Share on other sites

What happened to armbianmonitor ?

root@espressobin:~# armbianmonitor -u
System diagnosis information will now be uploaded to /usr/bin/armbianmonitor: line 813: [: -gt: unary operator expected
Please post the URL in the forum where you've been asked for.

 

Is the code broken ? :
CollectSupportInfo() {
        [[ -s /var/log/armhwinfo.log ]] && cat /var/log/armhwinfo.log || zcat /var/log/armhwinfo.log.1.gz
        [[ -f /boot/armbianEnv.txt ]] && LOGLEVEL=$(awk -F'=' '/^verbosity/ {print $2}' /boot/armbianEnv.txt) || LOGLEVEL=1
line 813 ->        if [ ${LOGLEVEL} -gt 4 ]; then
                VERBOSE='-v'
                which lshw >/dev/null 2>&1 && (echo -e "\n### lshw:" ; lshw -quiet -sanitize -numeric)
        fi

 

 

Link to comment
Share on other sites

The 1200 CPU firmware  espressobin-bootloader-cpu-1200-ddr3-2cs-2g-atf-ga3306ab-uboot-gaee49fc-20180129-REL.bin

doesn't run with my board.

----------------------------------------------------
TIM-1.0
WTMI-armada-17.10.1-b90dbf0
ENTER init_ddrgen
DDR_TOPOLOGY is 7 :     DDR3, 2CS 1G + 1G
WTMI_CLOCK=3

Fill memory before self refresh...done

Fill memory before self refresh...done

Now in Self-refresh Mode
Restore CAS Read and Write Latency
Restore termination values to original values
Exited self-refresh ...

DLL TUNING
==============
   DLL 0xc0001050[21:16]: [0,24,12]
   DLL 0xc0001050[29:24]: [a,2f,1c]
   DLL 0xc0001054[21:16]: [0,21,10]
   DLL 0xc0001054[29:24]: [a,31,1d]
   DLL 0xc0001074[21:16]: [0,3f,1f]
   DLL 0xc0001074[29:24]: [0,3f,1f]
 DLL: pass  

 

The booting interrupts here.

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