Jump to content

gnasch

Members
  • Posts

    111
  • Joined

  • Last visited

Posts posted by gnasch

  1. 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

  2. @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

  3. 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.

     

  4. 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

  5. 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

     

     

  6. 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

  7. 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

  8. 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

  9. 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

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines