tkaiser Posted July 21, 2018 Posted July 21, 2018 1 hour ago, tom_i said: still no support for booting from SATA? Boots even from SATA disks behind a crappy SATA PM. 0 Quote
tom_i Posted July 22, 2018 Posted July 22, 2018 Fresh install via "nand-sata-install" from uSDHC card and network still doesn't work. I'm on: lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 9.4 (stretch) Release: 9.4 Codename: stretch cat /proc/version Linux version 4.17.3-mvebu64 (root@armbian) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #7 SMP PREEMPT Thu Jun 28 18:21:11 UTC 2018 systemd --v systemd 232 +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN Armbian boots very well, no issues have been detected via starting up. Unfortunatelly, there are missing "lan0" and "lan1" devices in "ip a" ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 1e:XX:XX:XX:XX:43 brd ff:ff:ff:ff:ff:ff 3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether fe:XX:XX:XX:XX:de brd ff:ff:ff:ff:ff:ff 4: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 532 link/ether f0:XX:XX:XX:XX:f2 brd ff:ff:ff:ff:ff:ff 5: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 532 link/ether 9a:XX:XX:XX:XX:c9 brd ff:ff:ff:ff:ff:ff 6: br0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether 4e:XX:XX:XX:XX:43 brd ff:ff:ff:ff:ff:ff /etc/systemd/network$ ls -l total 24 -rw-r--r-- 1 root root 30 Jun 28 20:31 10-br0.netdev -rw-r--r-- 1 root root 38 Jun 28 20:31 10-br0.network -rw-r--r-- 1 root root 40 Jun 28 20:31 10-eth0.network -rw-r--r-- 1 root root 40 Jun 28 20:31 10-lan0.network -rw-r--r-- 1 root root 40 Jun 28 20:31 10-lan1.network -rw-r--r-- 1 root root 40 Jun 28 20:31 10-wan.network cat * [NetDev] Name=br0 Kind=bridge [Match] Name=br0 [Network] DHCP=ipv4 [Match] Name=eth0 [Network] DHCP=ipv4 [Match] Name=lan0 [Network] Bridge=br0 [Match] Name=lan1 [Network] Bridge=br0 [Match] Name=wan [Network] Bridge=br0 Weird is that if I boot via uSDHC card, network works without problem, but after "nand-sata-install" to SSD network doesn't work. I've tried to use "armbian-config" to setup DHCP again = no help. Any ideas? EDIT Problem solved. I had to use all that setenv params from official wiki: setenv load_script 'if test -e mmc 0:1 boot/boot.scr; then echo \"... booting from SD\";setenv boot_interface mmc;else echo \"... booting from USB/SATA\";usb start;setenv boot_interface usb;fi;if test -e \$boot_interface 0:1 boot/boot.scr;then ext4load \$boot_interface 0:1 0x00800000 boot/boot.scr; source; fi' setenv bootcmd 'run get_images; run set_bootargs; run load_script;booti \$kernel_addr \$ramfs_addr \$fdt_addr' After that network is working. 0 Quote
tom_i Posted July 22, 2018 Posted July 22, 2018 Ok another problem :-/ I've run "update" & "upgrade" of espressoBin, it downloads 4.17.5 kernel as I remember correctly. Then I've reboot it, but strange was, that it's booted to 4.17.3 not .5, IP adress was different from previous too. I was surprised little bit, but everything works after many restarts. So I halted EB and then run it again. But now, it shows me that I have "Bad Linux ARM64 Image magic!" Maybe tomorrow, I'll try to replace that installation on SSD via uSDHC again. Because I have correct ENV in u-boot now, so maybe that was the reason of bad patching kernel or... I don't know.. just quessing. PS: just for sure my newer and saved ENV: printenv baudrate=115200 boot=interface scsi boot_interface=usb bootargs=console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 root=/dev/sdc1 rw ip=0.0.0.0:0.0.0.0:10.4.50.254:255.255.255.0:marvell:eth0:none nfsroot=0.0.0.0:/srv/nfs/ bootcmd=run get_images; run set_bootargs; run load_script;booti $kernel_addr $ramfs_addr $fdt_addr bootdelay=2 console=console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 eth1addr=00:XX:XX:XX:XX:01 eth2addr=00:XX:XX:XX:XX:02 eth3addr=00:XX:XX:XX:XX:03 ethact=neta@30000 ethaddr=F0:XX:XX:XX:XX:F2 ethprime=eth0 fdt_addr=0x4f00000 fdt_high=0xffffffffffffffff fdt_name=boot/dtb/marvell/armada-3720-db.dtb fdt_name_a=boot/dtb/marvell/armada-3720-db.dtb fdt_name_b=boot/dtb/marvell/armada-3720-espressobin.dtb fdtcontroladdr=7f7182d8 gatewayip=10.4.50.254 get_images=tftpboot $kernel_addr $image_name; tftpboot $fdt_addr $fdt_name; run get_ramfs get_ramfs=if test "${ramfs_name}" != "-"; then setenv ramfs_addr 0x8000000; tftpboot $ramfs_addr $ramfs_name; else setenv ramfs_addr -;fi hostname=marvell image_name=boot/Image initrd_addr=0x1100000 initrd_image=boot/uInitrd initrd_size=0x2000000 ipaddr=0.0.0.0 kernel_addr=0x5000000 load_script=if test -e mmc 0:1 boot/boot.scr; then echo "... booting from SD";setenv boot_interface mmc;else echo "... booting from USB/SATA";usb start;setenv boot_interface usb;fi;if test -e $boot_interface 0:1 boot/boot.scr;then ext4load $boot_interface 0:1 0x00800000 boot/boot.scr; source; fi loadaddr=0x5000000 netdev=eth0 netmask=255.255.255.0 ramfs_addr=- ramfs_name=- root=root=/dev/sdc1 rw rootdev=/dev/sdc1 rootfstype=ext4 rootpath=/srv/nfs/ serverip=0.0.0.0 set_bootargs=setenv bootargs $console $root ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:none nfsroot=$serverip:$rootpath $extra_params stderr=serial@12000 stdin=serial@12000 stdout=serial@12000 verbosity=1 Environment size: 1933/65532 bytes 0 Quote
ebin-dev Posted July 23, 2018 Posted July 23, 2018 14 hours ago, tom_i said: Ok another problem :-/ I've run "update" & "upgrade" of espressoBin, it downloads 4.17.5 kernel as I remember correctly. Then I've reboot it, but strange was, that it's booted to 4.17.3 not .5, IP adress was different from previous too. I was surprised little bit, but everything works after many restarts. So I halted EB and then run it again. But now, it shows me that I have "Bad Linux ARM64 Image magic!" @Igor can you move this to peer-to-peer technical support please ? It seems that your installation is a mess. To boot from scsi is not officially supported yet. You can make it work but you need to understand what you do. After copying your working installation from SD to SSD using nand-sata-install you still need to manually copy /boot to /dev/sda1/ and to adapt the content of /dev/sda1/etc/fstab (rootdev UUID ; delete /boot entry ). You should also adapt the content of /dev/sda1/boot/armbianEnv.txt (rootdev UUID) and the content of /dev/sda1/boot/boot.cmd (setenv rootdev "/dev/sda1") followed by ‘mkimage -C none -A arm -T script -d boot.cmd boot.scr‘ to avoid any future mess. Then change your environment settings to boot from sata via SPI: setenv boot_interface scsi setenv image_name boot/Image setenv fdt_name boot/dtb/marvell/armada-3720-espressobin.dtb setenv fdt_high "0xffffffffffffffff" setenv rootdev "/dev/sda1" setenv root root=/dev/sda1 rw setenv rootfstype "ext4" setenv verbosity "1" setenv initrd_addr "0x1100000" setenv initrd_image "boot/uInitrd" setenv ethaddr "XX:XX:XX:XX:XX:XX" 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' 0 Quote
tom_i Posted July 23, 2018 Posted July 23, 2018 @ebin-dev - ha .. good point, that is what I forgot. Thx man.. 0 Quote
tom_i Posted July 31, 2018 Posted July 31, 2018 On 7/23/2018 at 8:09 AM, ebin-dev said: @Igor can you move this to peer-to-peer technical support please ? It seems that your installation is a mess. To boot from scsi is not officially supported yet. You can make it work but you need to understand what you do. After copying your working installation from SD to SSD using nand-sata-install you still need to manually copy /boot to /dev/sda1/ and to adapt the content of /dev/sda1/etc/fstab (rootdev UUID ; delete /boot entry ). You should also adapt the content of /dev/sda1/boot/armbianEnv.txt (rootdev UUID) and the content of /dev/sda1/boot/boot.cmd (setenv rootdev "/dev/sda1") followed by ‘mkimage -C none -A arm -T script -d boot.cmd boot.scr‘ to avoid any future mess. Then change your environment settings to boot from sata via SPI: setenv boot_interface scsi setenv image_name boot/Image setenv fdt_name boot/dtb/marvell/armada-3720-espressobin.dtb setenv fdt_high "0xffffffffffffffff" setenv rootdev "/dev/sda1" setenv root root=/dev/sda1 rw setenv rootfstype "ext4" setenv verbosity "1" setenv initrd_addr "0x1100000" setenv initrd_image "boot/uInitrd" setenv ethaddr "XX:XX:XX:XX:XX:XX" 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' Thank you @ebin-dev for your support. Everything works pretty well now 0 Quote
Jens Bauer Posted August 16, 2018 Posted August 16, 2018 On 7/14/2018 at 8:50 PM, y52 said: I suggest modifying as follows the /lib/systemd/system/systemd-networkd.service [Service] Type=notify Restart=on-failure RestartSec=0 # https://www.toradex.com/community/questions/1144/weird-behavior-when-restarting-networkd.html ExecStartPre=/sbin/ip addr flush dev wan ExecStartPre=/sbin/ip link set wan down ExecStartPre=/sbin/ip link set wan up ExecStart=!!/lib/systemd/systemd-networkd Thank you for the suggestion; I'm sorry it took me so long to post a reply; my Mac lost both network ports, but now I got myself a working PCIe card for it from IOCrest. I tried the above (on a clean bionic install without any updating), then rebooting and it seems I lost the network. I also tried clean install, apt update; apt upgrade then applying the above modification, but network never came up after that. 0 Quote
y52 Posted August 16, 2018 Posted August 16, 2018 Don't be discouraged. Just comment out the 2 following lines in your ""systemd-networkd.service : ExecStartPre=/sbin/ip addr flush dev wan #ExecStartPre=/sbin/ip link set wan down #ExecStartPre=/sbin/ip link set wan up Instead, add one line by the end of your "/etc/rc.local " : /sbin/ip link set dev wan up Execute after changes: systemctl daemon-reload Reboot. 0 Quote
Smurfix Posted August 17, 2018 Posted August 17, 2018 10 hours ago, y52 said: Execute after changes: systemctl daemon-reload Reboot. This may be a stupid question, but why would you do a daemon-reload if you're going to immediately reboot anyway? I 0 Quote
Smurfix Posted August 17, 2018 Posted August 17, 2018 On 7/14/2018 at 8:50 PM, y52 said: I suggest modifying as follows the /lib/systemd/system/systemd-networkd.service I suggest doing no such thing. Files in /lib don't belong to you and will be overwritten by the next random update of the package they belong to. Instead, copy this file to /etc/systemd/system/ and edit it there. Alternately, systemd has a well-documented mechanism to override things like ExecStartPre= entries. 0 Quote
tkaiser Posted August 17, 2018 Posted August 17, 2018 I updated my EsbressoBin with flash-image-1g-2cs-1000_800_boot_sd_and_usb.bin from https://dl.armbian.com/espressobin/u-boot/ (with flash-image-1g-2cs-1200_750_boot_sd_and_usb.bin I got ext4 errors). Marvell>> bubt flash-image-1g-2cs-1000_800_boot_sd_and_usb.bin spi usb Burning U-BOOT image "flash-image-1g-2cs-1000_800_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... 2 USB Device(s) found scanning bus 1 for devices... 1 USB Device(s) found reading flash-image-1g-2cs-1000_800_boot_sd_and_usb.bin Image checksum...OK! SF: Detected w25q32dw with page size 256 Bytes, erase size 4 KiB, total 4 MiB Updating, 3% 194180 B/s Updating, 28% 941578 B/s Updating, 65% 1551650 B/s 20480 bytes written, 798656 bytes skipped in 0.395s, speed 2118169 B/s Done! Marvell>> TIM-1.0 WTMI-armada-17.10.5-34ce216 WTMI: system early-init CPU VDD voltage default value: 1.155V Fill memory before self refresh...done Fill memory before self refresh...done Now in Self-refresh Mode Restore termination values to original values Exited self-refresh ... Self refresh Pass. DDR self test mode test done!! Self refresh Pass. DDR self test mode test done!! QS GATING ============= Calibration done: cycle = 0x00 tap =0x5F CH0_PHY_RL_Control_CS0_B0[0xC0001180]: 0x0000005F CH0_PHY_RL_Control_CS0_B1[0xC0001184]: 0x0000005F QS GATING ============= Calibration done: cycle = 0x00 tap =0x5F CH0_PHY_RL_Control_CS1_B0[0xC00011A4]: 0x0000005F CH0_PHY_RL_Control_CS1_B1[0xC00011A8]: 0x0000005F DLL TUNING ============== DLL 0xc0001050[21:16]: [0,29,14] DLL 0xc0001050[29:24]: [5,3a,1f] DLL 0xc0001054[21:16]: [1,29,15] DLL 0xc0001054[29:24]: [8,3b,21] DLL 0xc0001074[21:16]: [0,3f,1f] DLL 0xc0001074NOTICE: Booting Trusted Firmware NOTICE: BL1: v1.3(release):armada-17.10.8:34247e0 NOTICE: BL1: Built : 16:46:16, May 10 2NOTICE: BL2: v1.3(release):armada-17.10.8:34247e0 NOTICE: BL2: Built : 16:46:16, May 10 2018 NNOTICE: BL31: v1.3(release):armada-17.10.8:34247e0 NOTICE: BL31: U-Boot 2017.03-armada-17.10.3-g06ad760-armbian (May 10 2018 - 16:45:48 +0200) Model: Marvell Armada 3720 Community Board ESPRESSOBin CPU @ 1000 [MHz] L2 @ 800 [MHz] TClock @ 200 [MHz] DDR @ 800 [MHz] DRAM: 1 GiB U-Boot DT blob at : 000000003f7182d8 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 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: 2 1 0 *** ERROR: `serverip' not set *** ERROR: `serverip' not set ... booting from SD 1176 bytes read in 5 ms (229.5 KiB/s) ## Executing script at 00800000 221 bytes read in 2 ms (107.4 KiB/s) 14955008 bytes read in 647 ms (22 MiB/s) 4512106 bytes read in 204 ms (21.1 MiB/s) ** File not found boot/dtb/marvell/armada-3720-community.dtb ** 8330 bytes read in 9 ms (903.3 KiB/s) ## Loading init Ramdisk from Legacy Image at 01100000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 4512042 Bytes = 4.3 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 04f00000 Booting using the fdt blob at 0x4f00000 Loading Ramdisk to 3f2c8000, end 3f71592a ... OK Using Device Tree in place at 0000000004f00000, end 0000000004f05089 Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] [ 0.000000] Linux version 4.17.9-mvebu64 (root@nightly) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #164 SMP PREEMPT Tue Jul 24 18:15:33 UTC 2018 [ 0.000000] Machine model: Globalscale Marvell ESPRESSOBin Board [ 0.000000] earlycon: ar3700_uart0 at MMIO 0x00000000d0012000 (options '') [ 0.000000] bootconsole [ar3700_uart0] enabled Loading, please wait... starting version 232 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.29.2 [/sbin/fsck.ext4 (1) -- /dev/mmcblk1p1] fsck.ext4 -a -C0 /dev/mmcblk1p1 /dev/mmcblk1p1: recovering journal /dev/mmcblk1p1: clean, 36495/923232 files, 334257/3849616 blocks done. done. Begin: Running /scripts/local-bottom ... done. Begin: Running /scripts/init-bottom ... done. Welcome to Debian GNU/Linux 9 (stretch) Quick sbc-bench test revealed that the CPU cores aren't running at 1 GHz but just 800 MHz and that thermal readouts are broken: http://ix.io/1kt2 Storage performance test with a SATA connected EVO 840 and performance governor while running at 800 MHz: random random kB reclen write rewrite read reread read write 102400 4 29006 67436 34313 35602 33972 64807 102400 16 94899 157206 111199 112478 112152 112260 102400 512 355983 392732 344499 347130 346680 343875 102400 1024 370437 386847 358432 353261 360746 365497 102400 16384 282429 379475 434285 439253 439033 384619 1024000 1024 401822 402875 360320 360639 1024000 16384 388697 402818 439262 439727 Edit: This morning ext4 errors are back: [32076.089783] EXT4-fs error (device mmcblk1p1): ext4_find_entry:1437: inode #3042: comm gmain: reading directory lblock 0 [32080.090124] EXT4-fs error (device mmcblk1p1): ext4_find_entry:1437: inode #3042: comm gmain: reading directory lblock 0 [32084.089476] EXT4-fs error (device mmcblk1p1): ext4_find_entry:1437: inode #3042: comm gmain: reading directory lblock 0 [32088.089836] EXT4-fs error (device mmcblk1p1): ext4_find_entry:1437: inode #3042: comm gmain: reading directory lblock 0 [32092.089191] EXT4-fs error (device mmcblk1p1): ext4_find_entry:1437: inode #3042: comm gmain: reading directory lblock 0 [32096.089549] EXT4-fs error (device mmcblk1p1): ext4_find_entry:1437: inode #3042: comm gmain: reading directory lblock 0 [32100.088931] EXT4-fs error (device mmcblk1p1): ext4_find_entry:1437: inode #3042: comm gmain: reading directory lblock 0 @Igor: Downloading Debian_stretch_next.7z from https://dl.armbian.com/espressobin/ the contents are as follows (obviously something missing?): macbookpro-tk:~ tk$ ls -la /Users/tk/Downloads/Debian_stretch_next/ total 2261040 drwxr-xr-x 5 tk staff 170 17 Aug 22:14 . drwxr-xr-x 5 tk staff 170 17 Aug 22:14 .. -rw-r--r--@ 1 tk staff 1157627904 24 Jul 20:24 Armbian_5.54_Espressobin_Debian_stretch_next_4.17.9.img -rw-r--r--@ 1 tk staff 18577 24 Jul 20:24 armbian.txt -rw-r--r--@ 1 tk staff 122 24 Jul 20:24 sha256sum.sha 0 Quote
Igor Posted August 18, 2018 Posted August 18, 2018 9 hours ago, tkaiser said: obviously something missing? True. They are not signed ... probably I was changing my build host at that time. Will fix ASAP. 0 Quote
danglin Posted August 21, 2018 Posted August 21, 2018 I have to wonder if cpu frequency scaling is working correctly. There doesn't seem much difference in temperature with u-boot built with CLOCKSPRESET=CPU_600_DDR_600 and CLOCKSPRESET=CPU_1000_DDR_800. With 600MHz u-boot, cpufreq-info shows: cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 0.97 ms. hardware limits: 100.0 MHz - 300 MHz available frequency steps: 100.0 MHz, 120 MHz, 150 MHz, 300 MHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 250 MHz and 300 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 300 MHz. cpufreq stats: 100.0 MHz:0.00%, 120 MHz:0.00%, 150 MHz:0.00%, 300 MHz:100.00% (374) analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 0.97 ms. hardware limits: 100.0 MHz - 300 MHz available frequency steps: 100.0 MHz, 120 MHz, 150 MHz, 300 MHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 250 MHz and 300 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 300 MHz. cpufreq stats: 100.0 MHz:0.00%, 120 MHz:0.00%, 150 MHz:0.00%, 300 MHz:100.00% (374) The listed frquencies here seem off by a factor of two. With 1GHz u-boot, we have: cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 0.97 ms. hardware limits: 200 MHz - 1000 MHz available frequency steps: 200 MHz, 250 MHz, 500 MHz, 1000 MHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 250 MHz and 1000 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1000 MHz. cpufreq stats: 200 MHz:0.33%, 250 MHz:80.06%, 500 MHz:1.55%, 1000 MHz:18.06% (194) analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 0.97 ms. hardware limits: 200 MHz - 1000 MHz available frequency steps: 200 MHz, 250 MHz, 500 MHz, 1000 MHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 250 MHz and 1000 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1000 MHz. cpufreq stats: 200 MHz:0.33%, 250 MHz:80.06%, 500 MHz:1.55%, 1000 MHz:18.06% (194) The frequencies here agree with u-boot. It seems the 1GHz u-boot runs at 250MHz at idle while the 600 MHz u-boot runs at 300MHz. If the numbers are correct, this would explain why both feel hot. 0 Quote
danglin Posted August 21, 2018 Posted August 21, 2018 Probably, this fixes cpu frequency issue: diff --git a/drivers/cpufreq/armada-37xx-cpufreq.c b/drivers/cpufreq/armada-37xx-cpufreq.c index 739da90ff3f6..29966b407613 100644 --- a/drivers/cpufreq/armada-37xx-cpufreq.c +++ b/drivers/cpufreq/armada-37xx-cpufreq.c @@ -77,7 +77,7 @@ static struct armada_37xx_dvfs armada_37xx_dvfs[] = { {.cpu_freq_max = 1200*1000*1000, .divider = {1, 2, 4, 6} }, {.cpu_freq_max = 1000*1000*1000, .divider = {1, 2, 4, 5} }, {.cpu_freq_max = 800*1000*1000, .divider = {1, 2, 3, 4} }, - {.cpu_freq_max = 600*1000*1000, .divider = {2, 4, 5, 6} }, + {.cpu_freq_max = 600*1000*1000, .divider = {1, 2, 3, 4} }, }; static struct armada_37xx_dvfs *armada_37xx_cpu_freq_info_get(u32 freq) The thermal values are wrong because the Armada 3700 family doesn't have a thermal sensor 0 Quote
Smurfix Posted August 22, 2018 Posted August 22, 2018 14 hours ago, danglin said: {.cpu_freq_max = 800*1000*1000, .divider = {1, 2, 3, 4} }, {.cpu_freq_max = 600*1000*1000, .divider = {1, 2, 3, 4} }, That doesn't look right. You can't use the same divider values for two different max frequencies. 0 Quote
tkaiser Posted August 22, 2018 Posted August 22, 2018 18 hours ago, danglin said: I have to wonder if cpu frequency scaling is working correctly Reported cpufreq clockspeeds by driver and reality is also something different. And I've to admit that I've not the slightest idea whether DVFS is implemented on this board or not (if not then it simply makes no difference whether the SoC idles at 100 MHz or 800 MHz -- incorrectly reported as 1000 MHz). It would be really great if you could run sbc-bench with both settings on your board and report back. 0 Quote
Jens Bauer Posted August 22, 2018 Posted August 22, 2018 5 hours ago, Smurfix said: That doesn't look right. You can't use the same divider values for two different max frequencies. I think you're right. If we take 1200*1000*1000/1/2/4/6, we get 25000000 (25 MHz), which I assume is the base frequency. 25 MHz*1*2*3*4 = 600 MHz, so the 600MHz entry is actually alright. It's the 800MHz entry, which looks wrong to me. I don't know what the restrictions are, but 25MHz*1*2*4*4=800MHz. 750MHz could probably be {1,2,3,5} 900MHz could probably be {1,2,3,6} I don't know if any of those would work, though. 0 Quote
danglin Posted August 22, 2018 Posted August 22, 2018 5 hours ago, Smurfix said: That doesn't look right. You can't use the same divider values for two different max frequencies. Why? The idle is set to 150MHz for 600MHz max and 200MHz for 800MHz max. The big problem was the code the 600MHz max by two. Running sbc-bench. 0 Quote
Jens Bauer Posted August 22, 2018 Posted August 22, 2018 On 8/16/2018 at 10:18 PM, y52 said: Don't be discouraged. ExecStartPre=/sbin/ip addr flush dev wan Instead, add one line by the end of your "/etc/rc.local " : /sbin/ip link set dev wan up I now made the above modifications; eg. adding only one line to /lib/systemd/system/systemd-networkd.service and also adding the suggested line for rc.local right before 'exit 0'. This definitely makes a differnce. When I reach the login-prompt in the (serial) terminal, the network-light comes on on the WAN 8P8C connector. -But neither Lampra's nor my own /etc/systemd/network/10-* settings assigns an IP address to the WAN interface. If I do an ifconfig -a | grep inet, I do not see any ip-addresses belonging to my LAN (which is where the 'WAN' port is connected). @Smurfix: I (strongly) acknowledge that I should not edit stuff in /lib and once a solution is found, I'll use /etc for the final setup - but while I'm testing anyway, I might as well just mess up the system, since I'll do a complete re-install anyway when things do not work - I cannot use any editor from the serial terminal, thus I'd prefer having nano via SSH; this kinda requires me to re-install. 0 Quote
y52 Posted August 22, 2018 Posted August 22, 2018 51 minutes ago, Jens Bauer said: When I reach the login-prompt in the (serial) terminal, the network-light comes on on the WAN 8P8C connector. Your wan interface has been activated now. You will need checking your full network setup. Initially I ran into difficulty with several network management systems beeing active simultaneously. You will need deactivating unnecessary services. Set your ip address manually with "ip addr add xxxx dev xx" to confirm your network connectivity and then look for the root reasons, why you can not bring up your network automatically. 0 Quote
danglin Posted August 22, 2018 Posted August 22, 2018 8 hours ago, tkaiser said: Reported cpufreq clockspeeds by driver and reality is also something different. And I've to admit that I've not the slightest idea whether DVFS is implemented on this board or not (if not then it simply makes no difference whether the SoC idles at 100 MHz or 800 MHz -- incorrectly reported as 1000 MHz). It would be really great if you could run sbc-bench with both settings on your board and report back. Here are the sbc-bench results for 600 and 1000 MHz, respectively: http://ix.io/1kXZ http://ix.io/1kXE There was indeed a problem with the patch for 600 MHz. There were errors in downshifting: Aug 22 13:45:44 localhost kernel: [ 1660.817973] cpu cpu0: _generic_set_opp_clk_only: failed to set clock rate: -22 Aug 22 13:45:44 localhost kernel: [ 1660.817991] cpufreq: __target_index: Failed to change cpu frequency: -22 In the end I set all the 600 MHz values to 1. debian@espressobin:~$ cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 0.97 ms. hardware limits: 600 MHz - 600 MHz available frequency steps: 600 MHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 600 MHz and 600 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 600 MHz. cpufreq stats: 600 MHz:100.00% analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 0.97 ms. hardware limits: 600 MHz - 600 MHz available frequency steps: 600 MHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 600 MHz and 600 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 600 MHz. cpufreq stats: 600 MHz:100.00% As in tkaiser's sbc-bench run, the actual clock rate at 1000 MHz seems to be 800 MHz. The clock rates match at 600 MHz. It is my understanding that the values in the dvfs table are simple dividers. These get plugged into the A53_CPU_CLK_PRSCL field in the "North Bridge Clock Divider Select 0" register. Acceptable values are 1 to 6. The internal Boot ROM sets up the PLLs and initial clock frequencies. Then, u-boot adjusts the cpu clock and ddr frequencies based on the CLOCKSPRESET value selected in the atf build. 0 Quote
Jens Bauer Posted August 22, 2018 Posted August 22, 2018 1 hour ago, y52 said: Your wan interface has been activated now. Set your ip address manually with "ip addr add xxxx dev xx" to confirm your network connectivity when I do ... sudo ip addr 10.0.2.80/8 dev wan ... I still have the LED light on the WAN connector, and I can confirm the address is set with 'ip a', but I cannot SSH into that address (like I usually can if the address is assigned without upgrading or by a DHCP server). I tried making a diff -ur between the un-upgraded system and the upgraded system. The only difference is in /lib/systemd/system/unattended-upgrades.service: -ConditionACPower=true In other words: the configuration files seem to be unchanged, so that configuration files that previously worked don't work any longer (unless there are more configurationfiles elsewhere) I also noticed that some binaries (including /lib/systemd/system/systemd-{networkd,resolved}) had changed, so I decided to try and smash things alittle by replacing them one-by-one (resulting in a franken-linux) - but that didn't make any difference - worth the try, though. Note: This does not prove that those binaries aren't at fault. More info: Normally, before upgrading, I can SSH into the Espressobin before the login-prompt comes up in the terminal. But when I have the modification in rc.local, I will need to wait trying until the login-prompt appears (and the LED light comes on on the WAN port). That means the difference (eg. the change) is somewhere much earlier; the problem could be in one of the binaries of course. 0 Quote
y52 Posted August 23, 2018 Posted August 23, 2018 10 hours ago, Jens Bauer said: I can confirm the address is set with 'ip a', but I cannot SSH into that address 1st of all you will need to make sure, that the basic network functionality is valid. Make sure the pings out of the interface are not lost. If you can not ping out, than fix it before proceeding further. SSH service may not be launched or ssh keys are not generated. Other issues, like closed port may not allow to connect over ssh. 0 Quote
tkaiser Posted August 23, 2018 Posted August 23, 2018 11 hours ago, danglin said: Here are the sbc-bench results for 600 and 1000 MHz, respectively: http://ix.io/1kXZ This gives an aes-256-cbc score of 274785 at 8k. 11 hours ago, danglin said: http://ix.io/1kXE And this is 368675. Those OpenSSL numbers are great since they do not depend on anything else other than existence of ARMv8 Crypto Extensions so we can draw conclusions from benchmark result to Cortex-A53 clockspeed. Comparison chart: https://forum.armbian.com/topic/4583-rock64/?do=findComment&comment=37829 An Allwinner H5 clocked at 816 MHz scored 380482 back then so the 368675 we get is a clear indication of slightly below 800MHz. Same with the 274785 number --> slightly below 600 MHz. So with 600 settings it's really 600 MHz (~596) and the 1000 settings use a divider that seems to be somewhat off (1000 MHz being 795 in reality). Interestingly in the above result collection there are EspressoBin numbers that indicate that some time ago we were running at close to 1000 MHz (462012). Numbers were generated exactly one year ago with no kernel cpufreq support back then: https://forum.armbian.com/topic/4089-espressobin-support-development-efforts/?do=findComment&comment=37981 0 Quote
tkaiser Posted August 23, 2018 Posted August 23, 2018 3 hours ago, tkaiser said: So with 600 settings it's really 600 MHz (~596) and the 1000 settings use a divider that seems to be somewhat off (1000 MHz being 795 in reality). And with '1200 MHz' ('flash-image-1g-2cs-1200_750_boot_sd_and_usb.bin') it gets even worse and performance drops even more Checking cpufreq OPP: Cpufreq OPP: 1200 Measured: 742.904/742.370/742.454 Cpufreq OPP: 600 Measured: 367.340/367.847/367.739 Cpufreq OPP: 300 Measured: 178.783/180.299/180.009 Cpufreq OPP: 200 Measured: 117.394/117.781/117.879 Full results confirming lower CPU and memory performance: http://ix.io/1l0T There's seriously something really wrong in u-boot. 0 Quote
danglin Posted August 23, 2018 Posted August 23, 2018 4 hours ago, tkaiser said: And with '1200 MHz' ('flash-image-1g-2cs-1200_750_boot_sd_and_usb.bin') it gets even worse and performance drops even more Checking cpufreq OPP: Cpufreq OPP: 1200 Measured: 742.904/742.370/742.454 Cpufreq OPP: 600 Measured: 367.340/367.847/367.739 Cpufreq OPP: 300 Measured: 178.783/180.299/180.009 Cpufreq OPP: 200 Measured: 117.394/117.781/117.879 Full results confirming lower CPU and memory performance: http://ix.io/1l0T There's seriously something really wrong in u-boot. Here are results for 800 MHz: http://ix.io/1l1M 800 MHz seems to be 800 MHz. I have built my own u-boot from the Marvell GitHub: TIM-1.0 WTMI-devel-18.05.0-06b6160 WTMI: system early-init DDR topology parameters: ======================== ddr type DDR3 ddr speedbin 12 bus width 16-bits cs num 2 cs[0] - group num 0 cs[0] - bank num 8 cs[0] - capacity 512MiB cs[1] - group num 0 cs[1] - bank num 8 cs[1] - capacity 512MiB CPU VDD voltage default value: 1.108V DRAM windows: ============= WIN[0] - base addr 0x60000000 WIN[0] - size 0x40000000 WIN[1] - base addr 0xa0000000 WIN[1] - size 0x20000000 memory test region: =================== CS[0] 0x60000000 - 0x7fffffff CS[1] 0x80000000 - 0x9fffffff Fill memory before self refresh...done Fill memory before self refresh...done Now in Self-refresh Mode Restore termination values to original values Exited self-refresh ... Self refresh Pass. DDR self test mode test done!! Self refresh Pass. DDR self test mode test done!! QS GATING ============= Calibration done: cycle = 0x00 tap =0x5F CH0_PHY_RL_Control_CS0_B0[0xC0001180]: 0x0000005F CH0_PHY_RL_Control_CS0_B1[0xC0001184]: 0x0000005F QS GATING ============= Calibration done: cycle = 0x00 tap =0x5E CH0_PHY_RL_Control_CS1_B0[0xC00011A4]: 0x0000005E CH0_PHY_RL_Control_CS1_B1[0xC00011A8]: 0x0000005E DLL TUNING ============== DLL 0xc0001050[21:16]: [0,32,19] DLL 0xc0001050[29:24]: [4,32,1b] DLL 0xc0001054[21:16]: [2,2b,16] DLL 0xc0001054[29:24]: [8,32,1d] DLL 0xc0001074[21:16]: [0,3f,1f] DLL 0xc0001074[29:24]: [0,3f,1f] DLL: pass NOTICE: Booting Trusted Firmware NOTICE: BL1: v1.4(debug):armada-18.05.2:80bbf68 NOTICE: BL1: Built : 15:49:58, Aug 20 2018 NOTICE: BL1: Booting BL2 NOTICE: BL2: v1.4(debug):armada-18.05.2:80bbf68 NOTICE: BL2: Built : 15:50:01, Aug 20 2018 NOTICE: BL1: Booting BL31 NOTICE: BL31: v1.4(debug):armada-18.05.2:80bbf68 NOTICE: BL31: Built : 15:50:08 U-Boot 2017.03-armada-18.05.3-gf8e4b96 (Aug 20 2018 - 14:47:00 -0400) Model: Marvell Armada 3720 Community Board ESPRESSOBin CPU 800 [MHz] L2 800 [MHz] NB AXI 200 [MHz] SB AXI 250 [MHz] DDR 800 [MHz] For all the configurations that I have built, u-boot displays the correct CPU and DDR frequencies. Whether it is just showing config values or actual frequencies is an open question. The frquencies appear to be set in the atf code. I don't see any setting for CPU frequency in the u-boot config or device tree. I tend to think the core frequency must be correct as the USB, UART and Ethernet SERDES ports work. However, there is some issue with the sdhci@d0000 interface. The card that I have been testing usually fails to reset on shutdown, and when it does one often gets a SD data CRC error. It rarely fails on a cold start. Possibly, this could be a problem with the Boot ROM code in the 3720 or the Espressobin reset circuit. 0 Quote
tkaiser Posted August 23, 2018 Posted August 23, 2018 45 minutes ago, danglin said: However, there is some issue with the sdhci@d0000 interface Can confirm. I tried the '1000' and '1200' settings and when I ran off the SD card I always encountered ext4 errors after some time. Now the rootfs is on an USB3 pendrive. 800 and 1000 settings perform absolutely identical. The only difference is bogus cpufreqs reported with the 1000 settings. Compared to last year we have a 20% performance drop due to not being able to exceed 800 MHz clockspeed any more 0 Quote
danglin Posted August 23, 2018 Posted August 23, 2018 5 minutes ago, tkaiser said: Can confirm. I tried the '1000' and '1200' settings and when I ran off the SD card I always encountered ext4 errors after some time. Now the rootfs is on an USB3 pendrive. 800 and 1000 settings perform absolutely identical. The only difference is bogus cpufreqs reported with the 1000 settings. Compared to last year we have a 20% performance drop due to not being able to exceed 800 MHz clockspeed any more The memcpy tests are better at 800. Just built a kernel without frequency scaling (CONFIG_ARM_ARMADA_37XX_CPUFREQ). Testing... 0 Quote
danglin Posted August 23, 2018 Posted August 23, 2018 54 minutes ago, danglin said: Just built a kernel without frequency scaling (CONFIG_ARM_ARMADA_37XX_CPUFREQ). Testing... Here are results for 800 and 1000: http://ix.io/1l2a http://ix.io/1l2n The inferred CPU frequencies are now reasonably consistent with configured u-boot values. We also have the old OpenSSL performance back. So, the bug is in the Linux frequency scaling code. Maybe this helps with reboot issue. 1 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.