• Content count

  • Joined

  • Last visited

About y52

  • Rank
    Elite member

Recent Profile Visitors

334 profile views
  1. it was also discussed here. It is an internal bus interface. You should remove it from your bridge. Just disregard it.
  2. 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
  3. 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?
  4. 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.
  5. 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
  6. 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.
  7. 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?
  8. 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 ?
  9. 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.
  10. 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 port 35228 [preauth] May 16 19:07:03 espresso sshd[1524]: Connection closed by 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.
  11. I was able to switch from my kernel 4.4.y to a mainline one using the ARMBIAN 5.44 config : Linux espresso 4.14.40-mvebu64 #47 SMP PREEMPT Thu May 10 16:17:01 CEST 2018 aarch64 GNU/Linux What is more important for me, is that the regular DTB files are loaded, rather than the vendor's one, from boot.scr: root@espresso:/boot# ls -al /boot/dtb/marvell/armada-3720* -rw-r--r-- 1 root root 8369 May 10 16:17 /boot/dtb/marvell/armada-3720-db.dtb -rw-r--r-- 1 root root 7952 May 10 16:17 /boot/dtb/marvell/armada-3720-espressobin.dtb For a moment, the system is running at 1000MHZ as previously. I keep an eye on it. Will the board run stable at 1200MHZ and will it not stuck again? I've noticed, another improvement "thermal: armada: Add support for overheat interrupt indication". Does the mainline kernel allow for the CPU temperature surveillance? armbianmonitor -m doesn't show any temperature at all.
  12. Yes. You may optionally try another type of terminal access. I was under the impression, that your were using one under Windows.
  13. Try the space button. Switch options may not be visible in a text terminal. No, It works without reboot.
  14. I did. GlobalScale turned a deaf ear. They do not respond now. No. This page doesn't contain the .dtb choice. It just points to the boot/boot.scr, where the choice is made. It is somewhat arbitrary, depending on the board version and the kernel branch. This is what I am trying to find out.
  15. I've updated the armbian-config package. It seems to be working now, allowing to switch to the linux-image-next-mvebu64 Will the other applications (bind9, dhcp, iptables etc) dependencies be effected with this switch? Could you also suggest if I'll need to preserve the "usbstoragequirks" setting value after the switch to linux-image-next-mvebu64 ? My current one is: root@espresso:/boot# cat /boot/armbianEnv.txt usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u .... However, your test installation runs at 800MHz, while my board runs at 1000MHz. I fear that the DTB file, supplied with this build, will turn the board unstable and unsuitable at 1000MHz. This is very unfortunate, that I was unable achieving 1200MHz, despite the GlobalScaleTech board vendor specifications claims. Is that the "boot/dtb/marvell/armada-3720-espressobin.dtb" , which should be used with the linux-image-next-mvebu64 ? I shall backup the board before committing the switch.