gnasch

Hi tomter does your timing correspond to this? http://tinyvga.com/vga-timing/1280x800@60Hz you have to check the lines in the kernel, and in h3disp (which sets fex) you will setup the pll_video. it works for me if the value of the pll_video / divisor from kernel = pixel frequency. I had a problem with wrong value in h3disp. see also my question at: https://forum.armbian.com/index.php?/topic/4094-vesa-1280x1024-with-h3disp/ Disclaimer: I do not know what I am doing but I hope this helps, gnasch

@tkaiser: thank you very much for your help. I was able to track down the bug. Contrary to first belief, the kernel is not concerned, but in h3disp on line 196 the pll_video is initialized to 646 MHz. With kernels divisor of 4 this results in pixel frequency of 161.5 MHz, which is too high for Vesa 1280*1024. So I replaced this initialization with 432 MHz, which results in correct fD of 108 MHz. Now the monitor synchronizes. Unfortunately I found a bugfix by @igor on 24.Oct.2016 which inserted the 646 MHz value. I could not read the reasoning behind this (facebook srsly?), so I would kindly ask to revert this change if no important reasons for it exist. best wishes and thanks to armbian team for your great work! gnasch

bump - where could I find the relevant kernel sources? Did the armbian project patch this legacy kernel? Thanks gnasch

Hi twilipi then it is clear. when you connect your two clients with a cable there is no DHCP server in this "network". So the desperate clients will construct an APIPA Address to try and communicate. But when you connect the clients to your internet router, the DHCP server in it will give an other address to each client. you have to find out these new addresses! First on your macbook, say it will be something like 192.168.x.y. Then you can find out the address of your router, often 192.168.x.1. and once you have this you enter your routers web interface with http://address.of.your.router . There you can find out, what address it assigned to our opi, often in a list called "home network" or "DHCP table". Finally connect to your opi at this address.

Hello, today I want to connect the OpiPcPlus to a Flexscan S1921 Monitor. I select h3disp -m 33 -d to use my *tested* hdmi-to-dvi cable and reboot. Now the monitor complains: fV: 59.9 Hz fH: 63.9 kHz fD: 161.7 MHz ****red*** this seems too high because VESA mode should use a pixel frequency of 108MHz which is also the spec of the monitor. 1280x1024 @ 60Hz (VESA) hsync: 64.0kHz 1280x1024 108.0 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync The pixel frequency seems too high for the 60 Hz image refresh, it corresponds to 85 Hz. I am using legacy kernel: Linux JagOpi 3.4.113-sun8i #10 SMP PREEMPT Thu Feb 23 19:55:00 CET 2017 armv7l GNU/Linux Any ideas? Thanks, gnasch

Hi did you check this thread? https://forum.armbian.com/index.php?/topic/1080-tiny-3-lcd-on-orange-pi/#comment-29367 best, gnasch

@christos - did you inform xunlong (forum or email) about the flaw? thx, gnasch

I had good experience with OpiPcPlus, its wifi is reasonably working and it can be used as an "always on" PC as long as you do not want to decode video within the browser. OpiPc(without plus) is working here for almost a year as a small public DNS server, no problems at all. Updates are bad though because the wifi driver for the external UsbWifi dongle has to be recompiled with every kernel change. Please look for a stable 5V2A supply and one of the recommended SD cards, then you should be fine. best, gnasch

Programs compiled for AMD64 will not execute on ARM CPU's under armbian. This is not the problem of armbian, you would have to emulate the AMD64 CPU for doing this. Easier to select another program or look for an Intel NUC. hth, gnasch

Hello change language best, gnasch

how about systemctl stop log2ram.service install apache, run first time creating directory, systemctl start log2ram.service

apt-cache show usbmount apt-cache show pmount best, gnasch

Hi Please verify quality of your power supply and your cabling. HDD motor takes a lot of current when starting.

man screen I seem to remember that screen can reattach itself to an existing session, duplicating it. best, gnasch

According to https://linux-sunxi.org/Xunlong_Orange_Pi_Plus#SATA this should work, if you provide sufficient power of good quality. There seems to be no 2TB limit mentioned in the gl830 sata bridge datasheet here: http://pdf1.alldatasheet.com/datasheet-pdf/view/207044/GENESYS/GL830.html best, gnasch

here is mine on opi pc: systemd-analyze blame 6.009s shorewall.service 4.820s armhwinfo.service 2.048s rpimonitor.service 2.016s alsa-restore.service 1.988s sec.service 1.729s networking.service 1.727s ifplugd.service 1.521s rc-local.service 1.279s hostapd.service 1.269s hddtemp.service 1.260s lirc.service 1.208s gpm.service 1.149s systemd-udev-trigger.service 1.147s rpimonitor-helper.service 1.129s loadcpufreq.service 1.048s ntp.service 1.019s systemd-setup-dgram-qlen.service 1.004s systemd-journal-flush.service 939ms fake-hwclock.service 879ms keyboard-setup.service 720ms dev-mqueue.mount 647ms rsyslog.service 639ms kmod-static-nodes.service 623ms sys-kernel-debug.mount 619ms blacklists.service 619ms systemd-modules-load.service 609ms keymap.service 549ms systemd-user-sessions.service 509ms console-setup.service 499ms systemd-sysctl.service 410ms kbd.service 359ms cpufrequtils.service 359ms systemd-tmpfiles-setup-dev.service 319ms systemd-tmpfiles-setup.service 214ms sys-fs-fuse-connections.mount 209ms hdparm.service 199ms systemd-random-seed.service 191ms var-swap.swap 189ms udev-finish.service 169ms shorewall6.service 159ms systemd-update-utmp.service 115ms user@0.service 114ms systemd-logind.service 113ms systemd-udevd.service 89ms sysfsutils.service 79ms systemd-remount-fs.service 43ms systemd-update-utmp-runlevel.service 42ms systemd-tmpfiles-clean.service 11ms tmp.mount is there a problem with network or name resolution? dns timeouts? gnasch

Hi, you have included no information. Do you look at boot output? try systemd-analyze blame best, gnasch

OpiPcPlus is not equipped with a hardware clock. so your hwclock --test -D will always come up with a date 1.Jan.1970 + uptime. when ntp starts and the difference between the system clock and network servers is too high, it will not step the system clock. Usually on boot there is a call to ntpdate which will step the clock from the net. then ntpd is started and will keep time monotonous and synced to network time. Never had any problem with armbian and this mechanism. Is your network only ready very late in the boot process? hth, gnasch

Hi Jon has your root filesystem filled up? may cause different problems. best, gnasch

And waiting / hanging for 30s awfully smells like waiting for DNS to resolve something and running into a timeout. This does not happen here, please check. gnasch

if your monitor is not of hdmi but of dvi type then you need to use the -d switch in h3disp utility.

did you try to use h3disp as root user?

Gentlemen didn't you hear the developer? Bring serial logs or be forgotten. Speculations don't help. best, gnasch

I feel this forum to be most "international", in the sense that there is a lot of misunderstandings, eternal repetitions of always the same questions and unclear communications. Maybe we customers and/or testers are not that fluent in english to write correct error reports. Also searching in the forum is still a pain, and there are no pinned threads. Maybe you could attach a simple questionnaire to the nightly builds to be sent to a response address. Something with tick boxes for "boots, gives image on monitor, stays running more than one night, etc", and a little text field for comments. Might go a long way for reporting. Disclaimer: I am a fool and understand of nothing. Just my 2 cents. thanks for the great work! gnasch

good that you have a working module! I think nmtui is the recommended tool for setting up network-manager. Best to clear out the old config and make new. best, gnasch