Jump to content

jscax

Members
  • Posts

    43
  • Joined

  • Last visited

Posts posted by jscax

  1. I don't know how I ended up with Lunar installed on my OPI0.

     

    I did a 

    do-release-upgrade

    because it was suggesting to run this command to upgrade to the next version.

     

    I launched it and now I have Lunar installed:

     cat /etc/issue
    Armbian 23.8.1 lunar \l
    
    uname -r
    6.1.63-current-sunxi

     

    Now logging in is saying this:

    Your Ubuntu release is not supported anymore.
    For upgrade information, please visit:
    http://www.ubuntu.com/releaseendoflife
    
    New release '23.10' available.
    Run 'do-release-upgrade' to upgrade to it.

     

    I'm sorry I'm a little bit out of the know of the Armbian flow and sometimes I'm surprised while maintaining my armbian machine updated.

    Am I on a wrong path?

    thank you

  2. Hello,

    I have OPI0 with Ubuntu 20.04.1 LTS with Linux 5.8.6-sunxi and I would like to set 240 MHz as minimum frequency.

    cpufreq-info shows that available steps starts at 480 MHz but on older kernel 240 MHz and 120 MHz were available too.

     

    I also tried to "force" 240 and 120 by editing /etc/default/cpufrequtils but no go.

    Lower reachable frequency is 480 MHz and what I see are a bit CPU higher temperatures.

     

    cpufreq-info
    cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
    Report errors and bugs to cpufreq@vger.kernel.org, please.
    analyzing CPU 0:
      driver: cpufreq-dt
      CPUs which run at the same hardware frequency: 0 1 2 3
      CPUs which need to have their frequency coordinated by software: 0 1 2 3
      maximum transition latency: 5.44 ms.
      hardware limits: 480 MHz - 1.01 GHz
      available frequency steps: 480 MHz, 648 MHz, 816 MHz, 960 MHz, 1.01 GHz
      available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil
      current policy: frequency should be within 480 MHz and 960 MHz.
                      The governor "conservative" may decide which speed to use
                      within this range.
      current CPU frequency is 480 MHz (asserted by call to hardware).
      cpufreq stats: 480 MHz:98.26%, 648 MHz:1.28%, 816 MHz:0.12%, 960 MHz:0.35%, 1.01 GHz:0.01%  (12233)
    analyzing CPU 1:
      driver: cpufreq-dt
      CPUs which run at the same hardware frequency: 0 1 2 3
      CPUs which need to have their frequency coordinated by software: 0 1 2 3
      maximum transition latency: 5.44 ms.
      hardware limits: 480 MHz - 1.01 GHz
      available frequency steps: 480 MHz, 648 MHz, 816 MHz, 960 MHz, 1.01 GHz
      available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil
      current policy: frequency should be within 480 MHz and 960 MHz.
                      The governor "conservative" may decide which speed to use
                      within this range.
      current CPU frequency is 480 MHz (asserted by call to hardware).
      cpufreq stats: 480 MHz:98.26%, 648 MHz:1.28%, 816 MHz:0.12%, 960 MHz:0.35%, 1.01 GHz:0.01%  (12233)
    analyzing CPU 2:
      driver: cpufreq-dt
      CPUs which run at the same hardware frequency: 0 1 2 3
      CPUs which need to have their frequency coordinated by software: 0 1 2 3
      maximum transition latency: 5.44 ms.
      hardware limits: 480 MHz - 1.01 GHz
      available frequency steps: 480 MHz, 648 MHz, 816 MHz, 960 MHz, 1.01 GHz
      available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil
      current policy: frequency should be within 480 MHz and 960 MHz.
                      The governor "conservative" may decide which speed to use
                      within this range.
      current CPU frequency is 480 MHz (asserted by call to hardware).
      cpufreq stats: 480 MHz:98.26%, 648 MHz:1.28%, 816 MHz:0.12%, 960 MHz:0.35%, 1.01 GHz:0.01%  (12233)
    analyzing CPU 3:
      driver: cpufreq-dt
      CPUs which run at the same hardware frequency: 0 1 2 3
      CPUs which need to have their frequency coordinated by software: 0 1 2 3
      maximum transition latency: 5.44 ms.
      hardware limits: 480 MHz - 1.01 GHz
      available frequency steps: 480 MHz, 648 MHz, 816 MHz, 960 MHz, 1.01 GHz
      available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil
      current policy: frequency should be within 480 MHz and 960 MHz.
                      The governor "conservative" may decide which speed to use
                      within this range.
      current CPU frequency is 480 MHz (asserted by call to hardware).
      cpufreq stats: 480 MHz:98.26%, 648 MHz:1.28%, 816 MHz:0.12%, 960 MHz:0.35%, 1.01 GHz:0.01%  (12233)

    thank you

     

  3. On 9/14/2017 at 12:19 AM, petaspam said:

    ENG (GTranslator)

    Hello friends.

    I have an Orange Pi Zero v1.1 running perfectly with ARMbian 3.4.113 server and I connect via PUTTY SSH Client.

    I use the OPI to control a PRUSA Steel 3D printer with the Octoprint program and I am very happy with the results.

    For reasons of mobility and distance, I came up with the idea of being able to compile Marlin Firmware updates through the OPI Zero.

    I've searched and everything found is meant to use the Arduino IDE in graphical mode with X-Window. But as you know the ARMbian for the IPO Zero lacks a graphical system and everything moves by terminal.

    Can you help me with this question? Do you know how to do terminal mode, compile and upload Sketch's to Arduino?

    Thank you very much.

    Did you find the way to do that?

  4. On 11/17/2018 at 5:11 PM, dony said:

     

     

    Hello jscax,

     

    Are you saying that the YS-IRTM uses the "UPD6121".    I thought it used a STC11F02 microcontroller.   I am frustrated about finding information on the module I bought - looks like the one in your link to Aliexpress.    STC11F02  is an 8051 micro - I will see if I can use STC software to get the embedded firmware, and try to disassemble it.

    yes, it's a UPD6121 and I gave up about making it work with different protocol than NEC.

     

    I bought a double led with transistor ( https://www.aliexpress.com/item/Free-Shipping-electronic-building-blocks-Two-way-infrared-transmitter-module-IR-Transmitter-for-arduino/1972945414.html ) which allows me to just turn on/off the LED by changing high/low PIN and I succeded transmitting what I need.

    Note again: you need a double led with transistor to success

     

    I went for a very low level solution, similar to the one posted by nopnop2002 here above.

    I just save ON/OFF pulse with timing and I then just replicate the commands without encoding or making any logic.

  5. On 10/5/2018 at 3:39 PM, martinayotte said:

    Since most people doesn't care about Bluetooth, no developer took time to add it in device-tree ...

     

    Pardon my huge ignorance.

    I think I'm not understanding the whole context Armbian vs OrangePI.

     

    OrangePI is selling PiZero Plus with bluetooth hardware built-in but is not delivering the driver to make it works, correct?

     

    This:

    https://github.com/orangepi-xunlong/OrangePiH5_kernel/tree/master/drivers/bluetooth 

    is not something useful, correct?

     

    I'd like to have BT working.

    I bought OPI0+ for BT feature which I was missing on OPI0 and I did not consider that it shouldn't work.

    Can you please point me the direction to have BT working on OPI0+?

  6. So an update came into apt upgrade and it updated max freq config file too (/etc/default/cpufrequtils).

     

    Welcome to ARMBIAN 5.53.180722 nightly Ubuntu 16.04.5 LTS 4.17.9-sunxi

    After the update max frequency was restored at the original default value MAX_SPEED 1200MHz and I was barely able to boot again my OPI0.

     

    I went through several boot attempts, then after leaving it turned off for 30 minutes I was able to boot again and change back the MAX_SPEED to 960MHz.

     

    From my experience 1200MHz frequency is the offending cause of the random OPI0 freezes. And I had no freezes since I changed the MAX_SPEED @960MHz.

    Do you know if there's some undervolting going on? Maybe there's a wrong value @1200MHz?

     

    Moreover: after the update now the OPI0 is scaling frequency (before it was locked at max freq).

    Is it possible to link temperature with freq scaling?

    If temp > 50 °C ==> max freq = xx

  7.  

    26 minutes ago, Igor said:

     

    Nothing suspicious to me. Try with limit CPU down to 960000, double check voltage at the board, Another option is to lower DRAM speed, but you will need to rebuild u-boot with lower settings. It's worth trying.

    ok now limiting CPU @ 960MHz

     

    Do you have a link for the DRAM thing? I think I'm a little bit out of the know... where can I keep me updated with armbian news? I think there's a lot I'm missing  thank you

  8. 3 minutes ago, tkaiser said:

     

    Again: you won't find anything in any log if you suffer from usual hardware problems (they cause freezes/crashes, especially on 'el cheap' SBC and especially when powered by crappy Micro USB).

     

    Apart from that logging with latest Armbian is broken anyway (at least shutdown logging -- the relevant service is not executed at shutdown/halt/reboot target)

    it's not completely impossible to spot something on logs written before a kernel panic, that's my experience, but this time there's no trace.

    log2ram should not be my friend in this case. how does it work? it logs in ram, then a kernel panic occurs and puff... logs are gone because no one wrote them on sd?

     

    On the power supply side: I'm not using micro usb. I have a 15W PSU (and I'm using like 3 watts) connected with GPIO pins directely.

    I'll have a chance to use another power supply in a few days and will see if that's the issue.

  9. 4 hours ago, Igor said:

     

    One problem at the time. Does it crash?

    Sadly it crashed again after like 16 hours of uptime with the new kernel. In my case it must be on 24h/7d

     

    Attaching the armbianmonitor -u file

     

    I think it has something to do with logrotation/cron/log2ram something

    But I can't spot anything from logs.

     

    Now it crashed at 12PM and had to force reboot, which succeded at 12:31

     

    thank you

    armbianlog.txt

  10. 14 hours ago, Igor said:


    Now repeat the whole thing with most recent kernel 4.17.y/u-boot 2018.05 combo from beta.armbian.com ... armbian-config -> system -> switch to nightly automated build -> reboot

     

     

    uname -r
    4.17.6-sunxi

    Mmh now the CPU seems stuck at 1200MHz. Frequency scaling is not working anymore.

    armbianmonitor -m
    Stop monitoring using [ctrl]-[c]
    Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.
    
    22:18:48: 1200MHz  0.65  22%   7%  13%   0%   1%   0% 47.1°C  0/8
    22:18:53: 1200MHz  0.60   0%   0%   0%   0%   0%   0% 46.2°C  0/8
    22:18:58: 1200MHz  0.55   0%   0%   0%   0%   0%   0% 46.1°C  0/8
    cat /etc/default/cpufrequtils
    # WARNING: this file will be replaced on board support package (linux-root-...) upgrade
    ENABLE=true
    MIN_SPEED=240000
    MAX_SPEED=1200000
    GOVERNOR=ondemand

     

    Any suggestion?

    Thank you

  11. It happened again and I can't find a pattern nor a cause.

     

    armbianmonitor -u share too much informations, attached a manually cleaned (I hope) version.

    2018_07_04_armbianmonitor.txt

     

    There's something strange at the beginning of the attached report about wrong SD partitioning. I don't know if this has something to do with the crash.

    In this crash event I had to try to boot again 2 times, then at the 3d attempt it succeded. During the failing attempts I had to pull out 5V to force shutdown of the OPI0.

     

    The OPI0 is powered by an oversized 15W PSU and I'm not using microusb but I'm powering it using GPIO pins. Pin2 for instance.

     

    uname -r
    4.14.18-sunxi
     

    It's quite important for me to avoid those crashes because they are completely blocking the functionality of OPI0 until I manually shutdown it several times.

     

    thank you very much

     

  12. it's happening again.

     

    there's something in rsyslog configuration which crash the Orange Pi Zero!

     

    I can see there's a new rule which writes on /var/log/syslog all ufw (firewall) catch:

    :msg,contains,"[UFW " /var/log/ufw.log

     

    I don't know if this make things worse but the issue here is that I'd like to get rid of this bad crash.

    After this crash I have to reboot several times, and I can do it only manually, removing +5V from the board.

     

    log2ram seems to be disasbled

     

    Can anyone help? This is having a bad impact

     

    thank you
     

  13. https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=134971#p898539 maybe I found the solution

     

    commenting out last 4 lines from /etc/rsyslog.d/50-default.conf, those last 4:

    
    # NOTE: adjust the list below, or you'll go crazy if you have a reasonably
    #      busy site..
    #
    daemon.*;mail.*;\
           news.err;\
           *.=debug;*.=info;\
           *.=notice;*.=warn       |/dev/xconsole
    

    then service rsyslog restart

     

    Let's see if the issue will shows again

  14. So I have an OPI0 perfectly running then suddenly it freezes.

    All I can find on /var/log/syslog

    Jul  1 10:35:10 localhost CRON[1553]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
    Jul  1 10:36:08 localhost rsyslogd-2007: action 'action 10' suspended, next retry is Sun Jul  1 10:36:38 2018 [v8.16.0 try http://www.rsyslog.com/e/2007 ]
    Jul  1 10:37:07 localhost rsyslogd-2007: action 'action 10' suspended, next retry is Sun Jul  1 10:37:37 2018 [v8.16.0 try http://www.rsyslog.com/e/2007 ]
    Jul  1 10:38:07 localhost rsyslogd-2007: action 'action 10' suspended, next retry is Sun Jul  1 10:38:37 2018 [v8.16.0 try http://www.rsyslog.com/e/2007 ]
    Jul  1 10:39:06 localhost rsyslogd-2007: action 'action 10' suspended, next retry is Sun Jul  1 10:39:36 2018 [v8.16.0 try http://www.rsyslog.com/e/2007 ]
    Jul  1 10:40:06 localhost rsyslogd-2007: action 'action 10' suspended, next retry is Sun Jul  1 10:40:36 2018 [v8.16.0 try http://www.rsyslog.com/e/2007 ]
    Jul  1 10:41:05 localhost rsyslogd-2007: action 'action 10' suspended, next retry is Sun Jul  1 10:41:35 2018 [v8.16.0 try http://www.rsyslog.com/e/2007 ]
    Jul  1 10:42:04 localhost rsyslogd-2007: action 'action 10' suspended, next retry is Sun Jul  1 10:42:34 2018 [v8.16.0 try http://www.rsyslog.com/e/2007 ]
    Jul  1 10:43:04 localhost rsyslogd-2007: action 'action 10' suspended, next retry is Sun Jul  1 10:44:04 2018 [v8.16.0 try http://www.rsyslog.com/e/2007 ]
    Jul  1 10:45:01 localhost rsyslogd-2007: action 'action 10' suspended, next retry is Sun Jul  1 10:46:01 2018 [v8.16.0 try http://www.rsyslog.com/e/2007 ]
    Jul  1 10:45:01 localhost CRON[2103]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)

     

    Googling I found this but it seems like it's not solving

     

    anyone with the same issue?

    hints??

     

    thank you

  15. The MCU programming way seems very hard for me :o

     

    https://wiki.libreelec.tv/infrared_remotes

    Here they talk about overlay enabling. That should be a great implementation, I don't know if this is possible in armbian. But it's all about receiving, I want to send.

     

    This:

    http://www.piddlerintheroot.com/ir-blaster-lirc/

    seems very promising, do you see any cons vs my OPI Zero?

    Is OPI Zero capable of switching GPIO so fast? I hope so

  16. 11 hours ago, nopnop2002 said:

     

     

    There is Chinese Manual.

     

    http://www.uctronics.com/download/U3107_Infrared_decoding_module.zip#sthash.Br6igdz4.dpuf

     

    There is following explanation.

     

    Signal launch of 940nm38kNEC code.

    Yeah, YS-IRTM is working ok using the OPI Zero UART (thanks armbian :beer:), now I can control my TV.

     

    The problem is that YS-IRTM works with NEC protocol only.

    I actually need to control a Samsung AC unit which uses Samsung protocol.

     

    YS-IRTM ==> https://www.aliexpress.com/item/5V-IR-Infrared-Remote-Decoder-Encoding-Transmitter-Receiver-Wireless-Module-IR-Decoder-Module/32528109291.html

     

    http://www.datasheetcatalog.com/info_redirect/datasheet/nec/UPD6122G-002.pdf.shtml => UPD6121 ====> NEC only

     

    Differences between IR remote protocols:

    http://www.techdesign.be/projects/011/011_waves.htm

     

    NEC:

    tt_011_2-nec.gif

     

    SAMSUNG:

    tt_011_8-samsung.gif

     

    So, I was guessing that maybe GPIO can handle this kind of specific 1/0 switching and timing.

    And should be great if does exist a library for this, because seems like something very standardized.

     

    I'd expect something like:

    Ir ir = new Ir()
    ir.setGpioPin(x)
    ir.sendSamsung(hexcode)

     

    But maybe it's all wrong

  17. Is there a way to use PWM or a GPIO pin roughly connected with an infrared LED to transmit IR bits with different protocols NEC, but also Samsung and so on?

     

    I tried YS-IRTM module via UART but it works with NEC protocol only, afaik. I need the Samsung protocol.

     

    I thought there should have been a library for that, but I can't find it or it doesn't exist.

     

    thank you

     

    (OPI Zero)

  18. Now the audio loops no matter alsa mixer settings and no matter I'm using it in single channel only.

     

    This is from my dmesg

    [   12.083950] sun4i-codec 1c22c00.codec: ASoC: /soc/codec-analog@01f015c0 not registered
    [   12.083967] sun4i-codec 1c22c00.codec: Failed to register our card
    [   12.101011] sun4i-codec 1c22c00.codec: Codec <-> 1c22c00.codec mapping ok

    4.14.18-sunxi

    Orange Pi Zero v1.4

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines