Jump to content

Espressobin support development efforts

lanefu

By lanefu
in Marvell mvebu

 Share

Recommended Posts

tom_i

tom_i

Posted
Posted

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
Link to comment
Share on other sites
tom_i

tom_i

Posted
Posted

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
Link to comment
Share on other sites
ebin-dev

ebin-dev

Posted
Posted
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
Link to comment
Share on other sites
tom_i

tom_i

Posted
Posted
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
Link to comment
Share on other sites
Jens Bauer

Jens Bauer

Posted
Posted
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
Link to comment
Share on other sites
y52

y52

Posted
Posted

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
Link to comment
Share on other sites
Smurfix

Smurfix

Posted
Posted
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
Link to comment
Share on other sites
tkaiser

tkaiser

Posted
Posted

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
Link to comment
Share on other sites
danglin

danglin

Posted
Posted

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
Link to comment
Share on other sites
danglin

danglin

Posted
Posted

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
Link to comment
Share on other sites
Smurfix

Smurfix

Posted
Posted
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
Link to comment
Share on other sites
tkaiser

tkaiser

Posted
Posted
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
Link to comment
Share on other sites
Jens Bauer

Jens Bauer

Posted
Posted
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
Link to comment
Share on other sites
danglin

danglin

Posted
Posted
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
Link to comment
Share on other sites
Jens Bauer

Jens Bauer

Posted
Posted
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
Link to comment
Share on other sites
y52

y52

Posted
Posted
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
Link to comment
Share on other sites
danglin

danglin

Posted
Posted
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
Link to comment
Share on other sites
Jens Bauer

Jens Bauer

Posted
Posted
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
Link to comment
Share on other sites
y52

y52

Posted
Posted
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
Link to comment
Share on other sites
tkaiser

tkaiser

Posted
Posted
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&amp;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&amp;comment=37981

 

 

0
Link to comment
Share on other sites
tkaiser

tkaiser

Posted
Posted
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 :lol:

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
Link to comment
Share on other sites
danglin

danglin

Posted
Posted
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 :lol:


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
Link to comment
Share on other sites
tkaiser

tkaiser

Posted
Posted
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
Link to comment
Share on other sites
danglin

danglin

Posted
Posted
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
Link to comment
Share on other sites
danglin

danglin

Posted
Posted
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
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...
×
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept