y52

Members
  • Content count

    131
  • Joined

  • Last visited

About y52

  • Rank
    Elite member

Recent Profile Visitors

411 profile views
  1. It should be [Network] DHCP=ipv4
  2. 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
  3. 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?
  4. This is quite encouraging to finally get the so much advertised CPU clocking. Has this patch been implemented to the legacy kernel as well? Should the u-boot flash be updated at the same time?
  5. I've discovered more bugs in the current Armbian build, which, I believe, was inherited from Debian 9 and the network card buggy driver. 1) is related with the segmentation-offload, which is pretty well reproducible : root@espressobin:~# tcpdump -ni any -s100 -vvv port 53 27.49.62.17.52256 > 212.27.40.240.53: [bad udp cksum 0x5932 -> 0x332d!] 33775+% [1au] DS? akamaiedge.net. ar: . OPT UDPsize=4096 DO (43) 2) was very difficult to figure out, and the solution is not yet clear. It appears, that systemd-network is not properly handling the ipv4 and ipv6 renewals, which results in the wan network access failure periodically on the ISP ip lease renewal. It was very annoying and caused serious argues with the ISP support. The last working hypothesis is that the ipv6 Router Advertisement causes the networkd-[iface] service to fail and therefore the dhcpv4 client is killed too. 3) I also experienced the trouble with the wan interface automatic start up at boot time. Many experience it as well, which also looks to be a systemd-network trouble. It should work out of the box, but at the current state, the end-user has to adjust those setbacks with additional custom-made services or rc.local commads.
  6. it was also discussed here. It is an internal bus interface. You should remove it from your bridge. Just disregard it.
  7. I had a similar issue setting up the network (also reported here). By some unknown reason the wan i-face was not responding after the boot. I resolved the issue with : # cat /etc/rc.local /sbin/ip link set dev wan up
  8. The build structure is too different to allow easily adjust it to the Armbian's one. Apart from kernel and initrd images, the 4.17 build modules should also be loaded. The manual change looks to be problematic. This is a RC6. Will it finish with the Armbian version upgrade?
  9. I am still trying, although in vain, to find a stable board setup. The board reboots sporadically at visibly no reason, even during the period of inactivity. Your build could be considered like the last straw finding some solution. However, I have a concern if your precompiled image will require a kernel-headers package, which will not be available from Debian repositories? It will not be possible building other applications in the absence of kernel-headers.
  10. They should, but they don't do it. Litigation will cost times more than money spent for the board. This is the answer I received from GloablScaleTech: QUOTE > Our uboot does support 1.2 GHz, but it still testing. That's why it doesn't release public yet. Attached is the uboot firmware for your reference. Currently, I also tried the Armbian uboot 1.2G with our default firmware(Ubuntu 16.04.2 LTS espressobin.localdomain ttyMV0). Everything runs well... I think it's your OS or uboot parameter causes system stuck. UNQUOTE
  11. This setup is only running stable under 2 conditions : 1) Kernel 4.4.131-mvebu64 2) U-Boot loads armada-3720-community-v5.dtb (which I found in the Vendor's rootfs ). The May 10th mainline kernel 4.14.40-mvebu64 reboots sporadically, as I reported yesterday. There is little interest running this board at the values above.
  12. Yes. This is exactly what I used so far. The doubt has been sorted out. Thank you. My current values are as follows : root@espresso:~# cat /etc/default/cpufrequtils # WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=250000 MAX_SPEED=1000000 GOVERNOR=ondemand The U-boot showed Model: Marvell Armada 3720 Community Board ESPRESSOBin CPU @ 1000 [MHz] L2 @ 800 [MHz] TClock @ 200 [MHz] DDR @ 800 [MHz] DRAM: 2 GiB Should anything else be tweaked?
  13. I have a doubt if my board is a 1 chip RAM version or a 2 chips one? The board is a 2Gb. Here are the board pictures : https://mega.nz/#F!OpRDwRCa!lKtPNqEUyTHB5V_HZJEiew Where are the RAM chips located on the board? There is one unsoldered chips circuit place left on the back side. Which U-Boot firmware version should be used for that board to exclude the confusion ?
  14. My goals are exactly the same. This is up to the point. Unfortunately my similar actions are in vain either. This is just a mirage claim. I did RMA'ed the board and the GlobalScaleTech does just close to nothing to replace it. I have a 2Gig EspressoBins (V5_0_1), which crashes immediately at 1200/750 MHz, reboots sporadically with the May 10th firmware and mainline 4.14.40. I feel myself stuck in the current state of hardware/software malfunctions or incompatibility.
  15. The system rebooted on it's own after an hour of operation with the 4.14.40-mvebu64, which didn't happen before with 4.40. 18:51:00 up 6 min, 2 users, load average: 0.09, 0.14, 0.09 and rebooted again only after a few minutes of normal operation : May 16 19:06:57 espresso sshd[1526]: Disconnected from 120.132.43.119 port 35228 [preauth] May 16 19:07:03 espresso sshd[1524]: Connection closed by 200.133.132.253 port 44575 [preauth] ᅬ￰¥¬￸¥■ ￲¢←↓¢￳￲ ￱¥↓¢￴○￰¢. 19:08:54 up 1 min, 1 user, load average: 1.04, 0.42, 0.15 and so on : 19:30:20 up 4 min, 1 user, 20:19:44 up 9 min, 1 user 20:53:49 up 2 min, 1 user This is very troublesome. What should I do with it? It can not be an operational setup.