y52 Posted February 27, 2018 Posted February 27, 2018 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. 0 Quote
ebin-dev Posted February 28, 2018 Posted February 28, 2018 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 ... 0 Quote
chrisf Posted February 28, 2018 Posted February 28, 2018 I went as far as to 3d print a case with a little fan in it and put on a couple of heatsinks. I have never powered with board with anything but an isolated DC supply. There are no ground loop issues 0 Quote
umiddelb Posted February 28, 2018 Posted February 28, 2018 (edited) 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 March 1, 2018 by umiddelb error correction 0 Quote
y52 Posted February 28, 2018 Posted February 28, 2018 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. 0 Quote
umiddelb Posted February 28, 2018 Posted February 28, 2018 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. 0 Quote
umiddelb Posted February 28, 2018 Posted February 28, 2018 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. 0 Quote
umiddelb Posted February 28, 2018 Posted February 28, 2018 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. 0 Quote
y52 Posted February 28, 2018 Posted February 28, 2018 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. 0 Quote
Jens Bauer Posted March 1, 2018 Posted March 1, 2018 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. 1 Quote
umiddelb Posted March 1, 2018 Posted March 1, 2018 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. 0 Quote
y52 Posted March 3, 2018 Posted March 3, 2018 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 ? 0 Quote
y52 Posted March 4, 2018 Posted March 4, 2018 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. 0 Quote
y52 Posted March 4, 2018 Posted March 4, 2018 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 0 Quote
arm-push Posted March 4, 2018 Posted March 4, 2018 21 hours ago, Igor said: Are you running this without a heat sink? 0 Quote
Igor Posted March 4, 2018 Posted March 4, 2018 1 minute ago, arm-push said: Are you running this without a heat sink? Yes. I don't use a heat sink. 1 Quote
y52 Posted March 4, 2018 Posted March 4, 2018 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. 0 Quote
Smurfix Posted March 4, 2018 Posted March 4, 2018 9 minutes ago, y52 said: Has anybody managed preventing the NetworkManager from launching at startup ? What's wrong with systemctl mask NetworkManager.servce ? 0 Quote
y52 Posted March 4, 2018 Posted March 4, 2018 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. 0 Quote
Igor Posted March 5, 2018 Posted March 5, 2018 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 0 Quote
y52 Posted March 5, 2018 Posted March 5, 2018 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. 0 Quote
y52 Posted March 5, 2018 Posted March 5, 2018 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 ? 0 Quote
zador.blood.stained Posted March 5, 2018 Posted March 5, 2018 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. 0 Quote
Smurfix Posted March 5, 2018 Posted March 5, 2018 If you use systemd-resolved, you need to disable resolvconf. 0 Quote
y52 Posted March 5, 2018 Posted March 5, 2018 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? 0 Quote
y52 Posted March 6, 2018 Posted March 6, 2018 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. 0 Quote
y52 Posted March 6, 2018 Posted March 6, 2018 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. 0 Quote
y52 Posted March 6, 2018 Posted March 6, 2018 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 0 Quote
y52 Posted March 6, 2018 Posted March 6, 2018 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. 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.