• Content Count

  • Joined

  • Last visited

About y52

  • Rank
    Elite member

Recent Profile Visitors

619 profile views
  1. I added this setting to give (boot log): [ 0.000000] Kernel command line: console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 root=UUID=cdf86afe-e235-4b45-a02b-7954f2bbdaaa rootfstype=ext4 rootwait loglevel=1 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u mtdparts=spi0.0:1536k(uboot),64k(uboot-environment),-(reserved) rootdelay=3 [ 0.000000] Memory: 2026008K/2097152K available (10684K kernel code, 730K rwdata, 3244K rodata, 640K init, 502K bss, 54760K reserved, 16384K cma-reserved) However, the board didn't show up after "shutdown -r now". It was still necessary unplugging it and power up back for it to reboot. "rootwait" and "rootdelay=3", are those rootargs not conflicting and self excluding?
  2. Good suggestion. Which file the boot arguments are set? I looked into armbianEnv.txt, but "rootwait" is not there. Otherwise, are you suggesting changing the variable in the bootloader ? I looked into the current U-Boot 2017.03-armada-18.09.1-ga92bd86-armbian last Marvell>> printenv the rootarg is not set either. Could you be more specific?
  3. Have you seen this https://github.com/armbian/build/commit/9c7ce48f2b6cef71080ee6f04cca6f521f98df96 ? Yes. I understood it. It goes in line with the changes made to boot.cmd You should still replace the wrong boot.scr on your download page. Have you tried # cat /sys/devices/system/cpu/cpu1/cpufreq/stats/trans_table ? I have this table in place : root@karmae:~# cat /sys/devices/system/cpu/cpu1/cpufreq/stats/trans_table From : To : 200000 250000 500000 1000000 200000: 0 1 2 0 250000: 1 0 1846 3910 500000: 2 1822 0 85 1000000: 0 3934 61 0 What should be necessary to check more ? globalscale technologies turns a deaf year to such claims. They consider their boards to fully meet the specifications. I could have sent the board at my own risk for the cost of 50 USD, which is not worth it. globalscale technologies doesn't even guaranty the replacement. Once, the RMA guy told, that they may check it, but since then he doesn't even dare responding. It is really not up to the mark handling so badly technical claims for their boards.
  4. I've recompiled boot.scr from boot.cmd and, this time, the boot with the U-Boot 2017.03-armada-18.09.1-ga92bd86-armbian (Sep 05 2018 - 21:49:34 +0200) went without a hitch. Still the absence of CPU scaling persists. I shall observe how stable the board is with this U-Boot. The previous configuration resulted in hazardous reboots each couple of days.
  5. Interestingly enough, that CPU scaling seems not being reported by armbianmonitor : 14:54:44: 1000MHz 0.00 0% 0% 0% 0% 0% 0% 14:54:49: 1000MHz 0.00 3% 0% 2% 0% 0% 0% 14:54:54: 1000MHz 0.00 1% 0% 0% 0% 0% 0% 14:54:59: 1000MHz 0.00 0% 0% 0% 0% 0% 0% 14:55:05: 1000MHz 0.00 1% 0% 0% 0% 0% 0% 14:55:10: 1000MHz 0.00 0% 0% 0% 0% 0% 0% 14:55:15: 1000MHz 0.00 1% 0% 0% 0% 0% 0% or is broken with this U-Boot 2017.03-armada-18.09.1-ga92bd86-armbian (Sep 05 2018 - 21:49:34 +0200). The previous u-boot versions gave the impression of a functional scaling : 12:32:23: 1000MHz 1.01 21% 7% 10% 0% 4% 0% 12:32:28: 1000MHz 0.93 2% 1% 0% 0% 0% 0% 12:32:33: 0MHz 0.86 1% 0% 0% 0% 0% 0% 12:32:38: 0MHz 0.79 2% 1% 0% 0% 0% 0%^C
  6. I've found the new boot script in https://dl.armbian.com/espressobin/u-boot/bootscript/ However, looking at their content, it seems, that boot.cmd and boot.scr are unrelated to each other and different. As I understand it, boot.scr should be compiled from boot.cmd : "mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr". Why are they completely different? Is there any confusion? boot.scr refers to display environments like setenv disp_mode "1920x1080m60" etc. It should be coming from another build and another board. Which one is correct and should be used for expressobin? boot.cmd looks to be more appropriate, but should be recompiled before used with the boot.
  7. The load address is not an issue. It has been set correctly : Marvell>> setenv fdt_addr 0x6000000 Marvell>> setenv kernel_addr 0x7000000 Marvell>> setenv loadaddr 0x8000000 Marvell>> setenv initrd_size 0x2000000 Marvell>> setenv initrd_addr 0x1100000 Marvell>> setenv scriptaddr 0x6d00000 What is broken in the new u-boot environment is the path to the 'image_name' image_name=Image while the image file is located in 'boot/Image' and the u-boot command "scan_dev_for_boot 'for prefix in ${boot_prefixes}; do echo ${prefix};run boot_a_script; done'" doesn't return the correct path to the Image file. There are probably other issues, as the board doesn't boot consistently between cold boot and hot reset.
  8. I am still on ARMBIAN 5.44 user-built Debian GNU/Linux 9 (stretch) 4.17.9-mvebu64. I've used the new u-boot environments provided in the the EspressoBin download page), but there are no instructions for the changes in the /boot media. Could you be more specific about the new /boot scripts?
  9. I've upgraded the u-boot loader to the last one : U-Boot 2017.03-armada-18.09.1-ga92bd86-armbian (Sep 05 2018 - 21:49:34 +0200) Model: Marvell Armada 3720 Community Board ESPRESSOBin CPU 1000 [MHz] L2 1000 [MHz] NB AXI 250 [MHz] SB AXI 250 [MHz] DDR 800 [MHz] Then I have changed the u-boot environments as it was required. Much to my surprise, I was unable to boot initially. I boot from the the 'mmc' device and the logs showed the errors : Marvell>> 1176 bytes read in 13 ms (87.9 KiB/s) ## Executing script at 06d00000 221 bytes read in 3 ms (71.3 KiB/s) ** File not found Image ** 5837603 bytes read in 256 ms (21.7 MiB/s) ** File not found boot/dtb/marvell/armada-3720-community.dtb ** 8330 bytes read in 10 ms (813.5 KiB/s) Bad Linux ARM64 Image magic! After some debugging, I found, that the 'image_name' environment is badly formed. Indeed : Marvell>> printenv image_name image_name=Image while the image file is located in 'boot/Image' I tried changing the 'boot_prefixes' environment as follows: Marvell>> setenv boot_prefixes '/boot/' Marvell>> printenv boot_prefixes boot_prefixes=/boot/ But it didn't help. So I set : setenv image_name boot/Image saveenv The boot went fine until the next 'shutdown -r now'. When hot rebooting again, the boot process seems to process the sequence for a different boot target : 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 237 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: Waiting for root file system ... Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. ....many times.... Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... mdadm: error opening /dev/md?*: No such file or directory /scripts/local-block/mdadm: 58: /scripts/local-block/mdadm: rm: not found done. ....many times.... Begin: Running /scripts/local-block ... done. done. Gave up waiting for root file system device. Common problems: - Boot args (cat /proc/cmdline) - Check rootdelay= (did the system wait long enough?) - Missing modules (cat /proc/modules; ls /dev) ALERT! /dev/mmcblk0p1 does not exist. Dropping to a shell! (initramfs) If I unplug the board and power it back again, the board boots normally. What's wrong with the u-boot scripts and environments? Besides, is the new kernel build 4.18.xx available for upgrade?
  10. 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.
  11. 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.
  12. 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.
  13. It should be [Network] DHCP=ipv4
  14. systemd remains quite buggy. I try finding workarounds for it's different issues. 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 There is also a bad behavior in inability acquiring the DHCPv6 lease when hot restarting the systemd-networkd without rebooting. Where could kernel configs (for mainline and legacy trees) be found to double check if the following settings are similar as below ? -# CONFIG_IPV6_MULTIPLE_TABLES is not set +CONFIG_IPV6_MULTIPLE_TABLES=y -# CONFIG_IPV6_MROUTE_MULTIPLE_TABLES is not set +CONFIG_IPV6_MROUTE_MULTIPLE_TABLES=y
  15. This is sad. My board just doesn't stay stable with the "-next" kernel, although I wanted to migrate to it. In my case, the board stability also depends significantly on the .dtb file as well. It appears, that the only stable configuration is the legacy kernel and the # DTB submitted by GlobalScaleTech. Stable. setenv fdt_name_a boot/dtb/marvell/armada-3720-community-v5.dtb # DTB submitted by Armbian. Unstable. #setenv fdt_name_a boot/dtb/marvell/armada-3720-community.dtb Anyway, I can still try the "-next" kernel again with the new patch. Should I understand it correctly, that the "1.2ghz" is already implemented in the "next tree" ? Pls confirm the algorithm to migrate from the legacy tree to the "next tree" under "1.2ghz". If I understand it, the following procedure should be applied: 1. apt update & upgrade with the current legacy 4.4.138-mvebu64 kernel 2. armbian-config -> system -> switch to alternative kernel -> next 3. 1200 Mhz u-boot flashing 4. reboot with 1200 Mhz CPU clock under the "next tree" kernel. Should anything else be done?