Jump to content

znoxx

Members
  • Posts

    102
  • Joined

  • Last visited

Posts posted by znoxx

  1. May be it will be helpful for someone

     

    I have spare board, which previously was running under 5.10.?? (may be 65 ?).  I have especially saved this Armbian build, since it worked with "strange boards".

    Today I flashed latest Jammy diet with 5.15.80 and... no reaction. USB doctor shows 0.05 to 0.08 spikes and nothing.

    Tried to use again image with 5.10.65. Same reaction.

    Tried image from "orangepi.org" with 5.4.x or whatever. Same, but red light immediately on.

    Found one of boards running 5.10.34, copied microSD and it booted!

    After this I've downloaded 5.10.34 Armbian Focal -- https://mirror.yandex.ru/mirrors/armbian/archive/orangepioneplus/archive/Armbian_21.05.1_Orangepioneplus_focal_current_5.10.34.img.xz and it booted OK.

    Upgraded to 5.10.74 -- still ok.

    Then again flashed Jammy diet -- and it works now.

     

    No idea, how to explain what happened, but thanks for bringing board "up" again...

  2. I have several OpiOne Plus boards.

    They differ by the date of manufacture (let's say 1st batch and 2nd batch)

     

    1st batch:

    Works with kernel 5.10.x but does not boot kernel 5.15.x. Red light is on, power meter shows very little consumption, ethernet does not go up. 

    Switching to last available 5.10.x kernel resolves the situation.

    2nd batch:

    Successfully work with both 5.10.x and work with 5.15.x. Green light is on, power meter shows adequate consumption, board works.

     

    I'm pretty sure, that no more "new" opi one plus will appear at Xunlong shop and this issue won't be fixed in visible future. But well.. How I can "freeze" kernel update and I guess, uboot update also ? Just to prevent accidental updating of boards from "1st batch" ?

     

    Thanks in advance for the answer.

  3. 13 minutes ago, Werner said:

    Xulong literally tried to steal the build script by removing almost any copyright mark as well as search'n'replace Armbian with Orangepi.

     

    It's not a surprise... Unfortunately. However I wonder, how Xunlong can "bite the hand, that feeds". Armbian is the only one "driver", that boosted sales of Orange* devices, making them usable and reliable. However, without Armbian Xunlong could just disappear in AliExpress debris like many other small companies.

  4. Just received my H616 OpiZero2... Since there is no Armiban -- I tried "Xunglong" version of Ubuntu Focal.

     

    title.jpg.9d43d27ae08f779601a826f1017254d5.jpg

    monitor.jpg.b3ae933cc7ce961cd872f8b0b0ef0dfe.jpg

    boot.jpg.9699afd99b5614c1329f9e9b6ed32844.jpg

     

    Motd from Armbian

    armbian-config magically transferred into orangepi-config. Same to armbianmonitor, which is now .. guess - orangepimonitor.

     

    Also armbianEnv.txt now orangepiEnv.txt in /boot.

     

    Looks like "good global search and replace job" was done. I'm not a lawyer, neither too much aware of opensource licenses... But I guess there SHOULD be a reference to original Armbian sources ? 

    May be Armbian "stakeholders" are aware of this, may be not. 

     

    Just for your information.

  5. Hi there.

    Is there any way to set hostname of freshly installed board with armbian-config not in menu, but from command line ? 

    armbian-config --help gives some examples, but not for this case.

     

    And more generic question -- when I "burn" microSD image, first boot comes with questions about root password, new user, etc. Is there a way to do it in unattended mode ? E.g. with ansible.

     

    Thanks a lot in advance!

  6. @piter75, many thanks for your explanation.

    Indeed my "permanent duplicated" mac successfully found in "system connections" folder of original system in "Wired connection 1" file.

    But my 2 GB "retired" board stayed in drawer for a while and I made a new image with freshly downloaded Armbian - let's say "new sd card". Why in this case MAC was the same ?

     

    Unfortunately, I cannot tell you the signs on board -- they covered with heatsink, which I'd prefer not to re-glue back.

     

    2GB board was bought in June-july 2019

    4GB board was bought in Feb 2020, but arrived in May only due to covid situation in logistics =(.

     

  7. Hi!

    Thanks for your reply.

    This is one from 4GB model, which acts now as server:

     

    $xxd /sys/bus/nvmem/devices/rockchip-efuse0/nvmem
    00000000: 524b 3382 00fe 2155 524b 5030 3930 3036  RK3...!URKP09006
    00000010: 0000 0000 1710 150a 0208 0800 0000 0000  ................

    And this one comes from my "old" 2G board, which i want to re-purpose:
     

    $ xxd /sys/bus/nvmem/devices/rockchip-efuse0/nvmem
    00000000: 524b 3382 00fe 2155 524b 5030 3930 3231  RK3...!URKP09021
    00000010: 0000 0000 0f11 2908 0207 0800 0000 0000  ......).........

    By the way, "cloned mac address" worked.  I changed config manually (not in NMTUI) and mac is correct one.

     

    The story behind all this:

     

    I've got 4Gb model and replaced my 2gb model, literally unplugged microSD and boot usb hdd drive and plugged to new board. Mac not changed (I did not payed attention to this at all, and was happy with new server on same IP). However now I want to repurpose 2gb board, flashed new image to microsd and still getting old mac like in server. 

    I wonder is there way to reset something/regenerate it ? 

     

    And yet another issue I'm having. Usually I use some "online generator" to generate mac address.. However, in this case not all "macs" work. E.g. "your one" is working. I changed last digit -- also working. Some generated -- NOPE. 

     

    What is the correct way to generate one ?

     

    Thanks in advance for your reply.

  8. Armbianmonitor:

    Hi!

    I've 2 rock64 boards -- 4gb and 2gb bought with 1 year difference

     

    The problem -- both boards have same MAC address.

    Changing it with macchanger has no effect, same for cloned mac in nmtui.

     

    Also I tried this in armbianEnv.txt:

     

    root@rock64:~# cat /boot/armbianEnv.txt
    verbosity=1
    overlay_prefix=rockchip
    rootdev=UUID=48ad169b-7620-4c84-89fa-6c9a0fcde766
    rootfstype=ext4
    ethaddr=a7:71:b0:90:17:1f
    usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u

     

     

    But mac stays the same. I've plugged usb ethernet just to avoid conflict on same network, but how can I change the MAC of eth0 ?

  9. Not sure the same issue here -- but:

     

    1) Burn latest focal image from website with 5.xx -- system boots. Do apt-get update && apt-get upgrade -- never appears on network (kernel is not upgraded, as I see, but network manager does)

    2) Burn buster image with legacy kernel, apt-get update && apt-get upgrade -- working.

     

    Anybody bumped same ?

     

  10. Hi all!

    First of all thanks to bringing my Opi One Plus back to life.

    I was stuck to 4.20.x kernel, since all other crashed this board (strange, I have several opi1+, but only one of them did not survived upgrade and I had to rollback).

     

    Now it looks pretty stable:

     

    zno@nodex:~$ uname -a
    Linux nodex 5.4.1-sunxi64 #19.11.3.336 SMP Mon Dec 2 02:54:15 CET 2019 aarch64 GNU/Linux

     

    But well... This looks strange:

     

    zno@nodex:~$ sudo cpufreq-info 
    cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
    Report errors and bugs to cpufreq@vger.kernel.org, please.
    analyzing CPU 0:
      no or unknown cpufreq driver is active on this CPU
      maximum transition latency: 4294.55 ms.
    analyzing CPU 1:
      no or unknown cpufreq driver is active on this CPU
      maximum transition latency: 4294.55 ms.
    analyzing CPU 2:
      no or unknown cpufreq driver is active on this CPU
      maximum transition latency: 4294.55 ms.
    analyzing CPU 3:
      no or unknown cpufreq driver is active on this CPU
      maximum transition latency: 4294.55 ms.

    I am somehow old Debian Stretch, may be cpufrequtils is quite old ? But some performance test (minig, heh...) showed 50% lower hashrate, than expected from 1.8 (?) Ghz H6.

     

    Also, cpu is only 60C on full load and power consumption is much less than 1A. Looks like frequency is really low.

     

    Diagnostics uploaded here: http://ix.io/23oE

  11. 3 hours ago, Igor said:

     

    I try to keep wireless support as good as possible, but time to play with is always a problem. I am happy that most of my test devices work quite well and I will check if something can be done regarding 8188EU when time permits.

    Perhaps its time to make an upgrade to AC capable 8812 or at least 8811 ? :) 

    Well, my "demand" is quite exotic. Not so many people use wifi dongle inside LXC container. Not sure one should invest his own time into _such_ investigation.

    Regarding the speed - container runs "TorBox" (http://tbng.ml), and TOR does not give you super-fast connection.  But well, indeed it's time for upgrade to something more 2019 related. 

     

  12. 3 hours ago, Igor said:


    Driver for 8188 was changed with this commit. It should be better but I guess it could also be as step back :(

    Igor, thanks for confirmation.

    Looks like pure driver issue.

    I put good old ralink 5370. Works like charm and my macos started to connect to AP, instead of password loop on Realtek 8188EU.

    One small thing, not indeed rockchip related - diode on ralink usb wifi does not blink =).

     

    Bad thing - my heap of unused Realtek 8188eu adapters just got bigger. :)

     

     

     

  13. Hi all.

    Need help.

    Updated today from 4.4.180 -> 4.4.182

     

    Now getting permanent problem with bypassing network interface to LXC container (worked flawlessly on 4.4.180).

     

    sudo lxc-device -n tbng add wlx0092d00ddb46
    command failed: Operation not supported (-95)
    lxc-device: tbng: tools/lxc_device.c: main: 172 Failed to add wlx0092d00ddb46 to tbng

    Same for trying to pass phy0 to network namespace

     

    zno@armbox:~/_working_kernel$ sudo iw phy phy0 set netns 7094
    command failed: Operation not supported (-95)

     

    I will definately try with another non-realtek dongle, since I see only one difference - driver in dmesg has prefix RTW for debug messages. Previously it was 8188 or RT8188 (not sure).

     

    Thanks in advance for your help. 

  14. Yet another answer to myself.

     

    According to this (valued opinion of @tkaiser) - USB3@ARM SBC + USB3 Hub is totally bad idea: https://forum.openmediavault.org/index.php/Thread/24145-OMV-rock64-problem-with-USB-Hub/

     

    Still yet another problem with USB2. 

    Both ports works ok with directly connected devices. Attaching usb2 hub to lower USB - still ok. To upper USB - gives a lot of errors in dmesg with periodic device reset.

     

    Actually attaching usb voltmeter to hub showed BIG undervoltage (4.4v). Powering USB hub partially resolves situation, but still errors if using upper port.

    Older usb hubs (let's say before-AliExpress-era) work slightly better. 

     

    In my opinion, it's not a problem of kernel, but hardware itself.  

     

    Situation is much more clear now. I need to connect 2 HDD drives (one for system + one for data). Time to give up SSD idea, since my box  ( 8882:009d http://en.sharkoon.com/product/1686/10066) does not pass "TRIM" command, which is probably vital for SSD.

     

  15. Update...  It was guilty USB3 hub.

     

    I'm willing to have more than one USB3 port on rock64, but look... 

    Hub works fine on standart PC, but adding it to Rock64 gives this weird effect.

     

    Can anyone confirm, that USB3 HUB is not recommended to use for connecting boot USB3 SSD ?

     

    It's not a question of power - I'm using good PSU. And drive is SSD (consumes not too much).

     

    Thanks in advance.

  16. Armbianmonitor:

    Hi all!

    I'm having strange issue with Rock64.

    I downloaded latest Armbian 5.88 with 4.4.180 kernel.

     

    Installation and boot are ok, but when I try to do

    apt-get install lvm2

    Package installs, configures and...

     

    update-initramfs: Generating /boot/initrd.img-4.4.180-rockchip64

    update-initramfs: Converting to u-boot format

     

    Then I do

    root@rock64:~# sudo reboot

     

    And I'm getting a boot loop... Same effect, if I move system to SSD. At first I thought it was issue with ssd transferred system... But it clearly reproduced on freshly written with uSD only boot.

     

    I've dumped armbianmonitor output (just in case) on freshly flashed OS.

    MicroSD is old 2GB one (I'm planning to use SSD drive and use uSD only for boot). But same effect on other cards.

     

    Another one issue (which I probably can live with, but you may find this interesting).

    I install hostapd-rt along with using rtl8188eu dongle. Hostapd starts, but here are two points:

     

    Everything works with android

    It fails to authenticate with MacOS...

     

    But weirdest thing here - when I stop hostapd with systemctl, then start - it shows "Oops, SMP error" and reboots. 

     

    Still not sure about revision (not v3 definately :)

     

    Thanks in advance for looking into it.

     

     

  17. Igor, thanks for reply.

    I see in download section "legacy kernel 4.4.y" -- marked as stable and supported.

    And I guess you are talking about 4.17+ regarding "mainline".

     

    I will start with 4.4 anyway, hope it has docker support...

     

    One thing which confuses me a LOT: "Rock64 V3 is not supported". If I booted, installed system to USB hdd (ssd)... Does it mean I'm not on V3 version ? Cannot find any description of V3 vs not-a-v3.

  18. Hi all.

    In download section i do see "large heatsink required" for Rock64.

    Can anyone post any links to eamples of good heatsink with proper size ?

    I will be migrating "home server" from Cubieboard2 to Rock64 and chasing long-term stable operation.

    When board just booted and "does nothing", cpu remains pretty cool. However i'd better be prepared. :)

    thanks in advance for tips.

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines