• Posts

  • Joined

  • Last visited

Reputation Activity

  1. Like
    Werner reacted to martinayotte in Mainline jump in version ...   
    I can share the fact that I've not resolved the H6 issue freezing at "starting kernel", I've even tried them with 5.0.0-rc1, still the same.
    If someone can help narrow the issue, I will be glad ...
  2. Like
    Werner reacted to Igor in Mainline jump in version ...   
    H6 can be created with NEXT now in as is state, but has to be enabled/added. If DEV is broken for some boards now ... that is not an issue.
  3. Like
    Werner reacted to guidol in Orange PI Zero optimization   
    after searching the internet we have to do it the blacklist way

    for every module you doenst want to load create a file in /etc/modprobe.d with the name <modulname>.conf that will include the line
    blacklist <modulname>
    like that :
    /etc/modprobe.d/xradio_wlan.conf : blacklist xradio_wlan  
    If we do this for all 3 modules we get:
    root@opi-zero( cat xradio_wlan.conf mac80211.conf cfg80211.conf blacklist xradio_wlan blacklist mac80211 blacklist cfg80211 After a reboot the modules arent loaded anymore
    root@opi-zero( lsmod Module Size Used by lz4hc 16384 4 lz4hc_compress 24576 1 lz4hc ftdi_sio 40960 0 sun8i_codec_analog 24576 1 sun4i_codec 32768 3 usbserial 24576 1 ftdi_sio snd_soc_core 118784 2 sun4i_codec,sun8i_codec_analog snd_pcm_dmaengine 16384 1 snd_soc_core snd_pcm 69632 2 snd_pcm_dmaengine,snd_soc_core zram 24576 5 snd_timer 24576 1 snd_pcm snd 45056 3 snd_timer,snd_soc_core,snd_pcm soundcore 16384 1 snd sun4i_gpadc_iio 16384 0 uio_pdrv_genirq 16384 0 uio 16384 1 uio_pdrv_genirq usb_f_acm 16384 1 u_serial 20480 3 usb_f_acm g_serial 16384 0 libcomposite 40960 2 g_serial,usb_f_acm ip_tables 20480 0 x_tables 20480 1 ip_tables pwrseq_simple 16384 1  
    for reference:  KernelModuleBlacklisting
    Howto: Create a file '/etc/modprobe.d/<modulename>.conf' containing 'blacklist <modulename>'. Run 'depmod -ae' as root Recreate your initrd with 'update-initramfs -u'  
  4. Like
    Werner reacted to AlterX in Orange PI Zero optimization   
    Very good!! it is working for me as well
  5. Like
    Werner reacted to martinayotte in Ramblings and progress with the RK3399   
    I've received my OrangePi-RK3399 recently ...
    Just for trials, before doing any real development, I gave a try with a NanoPC-T4 4.19.y image compiled a month ago, and it worked "as is", even eMMC and WiFi is running fine.
    That it is a good starting point !
    Of course, to be able to boot from SDCard, we need to short the eMMC clock using the test point TP50265 :

  6. Like
    Werner got a reaction from WarHawk_AVG in Orange Pi One Plus usability ?'   
    The reason for this seems to be a regression or a missing commit from @Icenowy sources (https://github.com/Icenowy/linux/commits/h6-integrate-2-ugly) which has not made the jump into mainline (yet).
    Therefore you either have to use the 4.18.0-rc7 kernel image (which I run two OPi 1+ perfectly fine on right now) or temporarily disable dwmac like @martinayotte did as workaround to successfully boot up the board with a kernel built from newer sources (and use a USB-Ethernet adapter).
    For confirmation you can utilize a UART serial adapter to check the kernel boot for errors like "sun8i_dwmac_probe+0x164/0x518".
    As stated mainline support has still a long way to go to better support the H6 SoC. Do not just discard the board. Just put it on the shelf and it may run fine in a couple of month.
  7. Like
    Werner reacted to martinayotte in Error building for orangepi lite2   
    On my side, I kept my previous OPiOne+ build done with h6-integrate-2-ugly branch.
    I didn't investigate further about Mainline 4.18.10 since Icenowy suggested to check with 4.19.y, but I didn't take the time to check ...
  8. Like
    Werner reacted to martinayotte in Error building for orangepi lite2   
    I've just started new build with 4.18.12, and when finished, I will disable the dwmac and check if it boot properly, I think it will.
    This would mean that patches for dwmac added in 4.19.y would need to be backported, or we wait for 4.19, which can still take awhile ...
  9. Like
    Werner reacted to Igor in when linux 4.19 is released LTS, which ARM-related features are you most excited about?   
    Armbian is mostly ahead of the upstream kernel releases in board specific functions. Up to about one year. Regarding the biggest group (Allwinner), the only change will be that we will remove a few patches  and when 4.19.y is sorted out it will become our NEXT for A10/A20/H3/H5/H6/A64 and Armada 3700, Rockchip, Meson, ... almost all supported board as a first or second kernel.
  10. Like
    Werner reacted to going in (not so) Stupid question - save bandwidth in cleanlevel   
    Thanks. It turned out two topics on one big question:
    How to do better?
    I will prepare an explanatory note and patch, or as you said:
    I think then the two topics can be combined.
  11. Like
    Werner reacted to chwe in (not so) Stupid question - save bandwidth in cleanlevel   
    Do it as you think it's best and if it turns out that it isn't perfect, the PR can still be edited before it gets merged. I would link to those two threads when sending the PR, so that a reviewer know where it comes from.  
  12. Like
    Werner reacted to Igor in board support - general discussion / project aims   
    There are still (many)some (short and) long-term questions which are scattered on the forum and in our heads which we would need to discuss.
    - release naming, 2018.10 or 18.04 + some RFC as shown on the pic,
    - collecting wishes on a special web page or forum topic. When someone approaches with "I want to help" that it is appointed to 1. Check issues on GH, 2. Fixing sound ... 3. Creating this ...
    - improving testing protocols, automating what is possible. I'm low on ideas what more is possible to do.
    - what to add to »end of support«?
    - secure project longterm survival, leverage maintenance costs to users or drastically limit down free support,
    - enforce browser of choice for desktop images, Firefox and/or some lighter alternatives?
    - fix Bluetooth on all Broadcom AP62xx devices. Its the same on most boards, but we have it working only on a Cubietruck IIRC
    - sum most frequent problems under »The Ten Commandments« / FAQ and promote it as much as possible
    - does forum need structure update?
    - add/remove moderators? Disable rights if not moderating content in past 6months?
    - enforce forum rules? Some very simple ones.
    - users are still seeking for help without providing logs. What to do about?

    Download UX:
    - make a bigger diff between nightly and stable, desktop and CLI (Gorazd)
    - add a warning when nightly is downloaded, (Gorazd)
    - tested devices lead to their test page where exists instead of Amazon affiliate, (Gorazd)
    - tested hardware have information to which kernel is attached to but not displayed, (Gorazd)
    - check other download option still no visible enough, (Gorazd)
    - add a support box with 1. Check common issues 2. Search for solution 3. Ask (with a link to the correct forum) (Gorazd)
    - add a button »alternative builds« with a link to dl.armbian.com/DEVICE (Gorazd)
    To keep things in place, I would like to ask @Tido and @chwe  to help keep this 2do list up2date according to with our decisions.
  13. Like
    Werner reacted to data in Orange Pi Lite2 wireless support   
    Ok, new image is up and running:
    AP6255 Wifi works, however somewhat flaky. Ping times are normal for Wifi, but when I type it takes some time to show the characters.
    USB3 Ethernet is not being recognized in dmesg nor does it show up in lsusb
    USB Wifi can scan, however it does not let me connect, complaining about a wrong WPA2 Password.
    just switched to the nightly built via armbian-config. Update to 4.18.11 went successful
    USB Wifi works now, USB3 Ethernet still not recognized
  14. Like
    Werner reacted to Igor in board support - general discussion / project aims   
    Yes, that is planned, but we still have weeks - we also don't need to jump on v4.19.0 ... It's DEV kernel and the idea is that DEV becomes NEXT when the time is right. Which is even more distant. Since 4.19.y is the next LTS it will be worth to prepare it and port support from more recent versions. 4.19.y is for 2019
  15. Like
    Werner reacted to martinayotte in Error building for orangepi lite2   
    You're right ! My resulting build faced the same "oops" issue :

    I don't know why since it was running fine using @Icenowy h6-integrate-2-ugly branch, but it crash here with 4.18.10, but not on the Lite2 (since it doesn't have ETH port).
  16. Like
    Werner reacted to data in Orange Pi Lite2 wireless support   
    It finished:
    [ o.k. ] Writing U-boot bootloader [ /dev/loop0 ]
    [ o.k. ] Done building [ /home/data/build/output/images/Armbian_5.61_Orangepilite2_Ubuntu_bionic_dev_4.18.10.img ]
    [ o.k. ] Runtime [ 16 min ]
    Too bad I have to go now Will report later
  17. Like
    Werner reacted to Icenowy in Error building for orangepi lite2   
    I'm not sure, my distro uses 4.19 and omitted 4.18.
  18. Like
    Werner reacted to martinayotte in Error building for orangepi lite2   
    I didn't rebuild my OPiOne+, it still on Icenowy's branch build done 4 week ago.
    Let me start a build for that one too and I will report back ...
  19. Like
    Werner reacted to Igor in Orange Pi Lite2 wireless support   
    Because that branch is temporarily development branch with a purpose to develop a few things. We only have two choices here - switch to current 4.18.y, say goodbye to HDMI for a while and fix other things, wifi perhaps ... or wait until HDMI is not mainlined. Other options are too expensive.

    I have to remind you that this board is under development and regressions are possible. Some are intended, some not.
  20. Like
    Werner reacted to tkaiser in sbc-bench   
    Relevant swapping occurred. Still no idea why so I added monitoring of virtual memory settings few hours ago. I'll look into this within the next months but no high priority since there is detailed monitoring in sbc-bench we know exactly why numbers differ currently between Orange Pi One Plus (1 GB) and PineH64 (more than 1 GB).
  21. Like
    Werner reacted to tkaiser in Security Alert for Allwinner sun8i (H3/A83T/H8)   
    EDIT: This is NOT about a (hidden) backdoor but just a local privileges escalation that affects one single 3.4 kernel variant for 2 Allwinner SoCs. In case you came here through lurid headlines please read this comment here first and help stop spreading further BS like "all Allwinner devices contain a hidden backdoor" -- the code has been found since Allwinner could be convinced to open their Github repos in the past so everyone is able to audit their Android kernel source!
    It has been brought to our attention two days ago on 2016-04-30 in linux-sunxi IRC that Allwinner's 3.4 legacy kernel for H3/A83T/H8 contains a nasty local privileges escalation. Any process running with any UID can become root easily by simply doing this:
    echo "rootmydevice" > /proc/sunxi_debug/sunxi_debug Combined with networked services that might allow access to /proc this means that this is also a network enabled root exploit. As usual we fixed such an issue within a few hours, on May 1st new Armbian 5.10 images were rolled out and in the meantime the fix is also in Armbian's apt repo so please upgrade now (apt-get update/upgrade or start with a fresh OS image) if you're affected! If you're already running Armbian 5.10 then this vulnerability is already fixed.
    This security flaw is currently present in every OS image for H3, A83T or H8 devices that rely on Kernel 3.4: this applies to all OS images available for Orange Pis (except Armbian 5.10 available since May 1st), any for FriendlyARM's NanoPi M1, SinoVoip's M2+ and M3, Cuebietech's Cubietruck + and Linksprite's pcDuino8 Uno
    We informed all vendors where possible also two days ago (FriendlyARM and SinoVoip took notice, the others still ignore the issue) FriendlyARM: https://github.com/friendlyarm/h3_lichee/issues/1 SinoVoip M3: https://github.com/BPI-SINOVOIP/BPI-M3-bsp/issues/10 SinoVoip M2+: https://github.com/BPI-SINOVOIP/BPI-M2P-bsp/issues/1 Cubietruck +: https://github.com/cubieboard/Cubietruck_Plus-kernel-source/issues/2 LinkSprite pcDuino8 Uno: https://github.com/pcduino/pcduino8-uno-kernel/issues/3 Users of any of the available OS images for H3 based Orange Pis are somewhat lost since none of the OS images or kernels used for these are maintained any longer. Loboris disappeared (so the opened issue is more like a reference) and Xunlong themselves do not maintain their software at all (not even possible to open an issue there).   In case some readers here do also have accounts at Orange Pi forums, please spread the word and inform the users that their OS images are exploitable unless they already use Armbian 5.10. Same applies to Banana Pi forums, please spread the word there also that all M3 and their M2+ OS images are affected (I deleted my account there since talking to @sinovoip is like talking to a wall and just makes me sick, but it might be worth the efforts to try to warn their users)
  22. Like
    Werner reacted to tkaiser in sbc-bench   
    Quick summary:
    unfortunately all the time throttling happened so results are not comparable other than expected with vm.swappiness=1 less swap activity happened compared to vm.swappiness=0 (while 'everyone on the Internet' will tell you the opposite): vm.swappiness=0 Compression: 2302,2234,2283 Decompression: 5486,5483,5490 Total: 3894,3858,3887 Write: 1168700 Read: 1337688 vm.swappiness=1 Compression: 2338,2260,2261 Decompression: 5506,5480,5512 Total: 3922,3870,3887 Write: 1138240 Read: 941548 vm.swappiness=60 Compression: 2266,2199,2204 Decompression: 5512,5495,5461 Total: 3889,3847,3832 Write: 1385560 Read: 1584220 vm.swappiness=100 Compression: 2261,2190,2200 Decompression: 5421,5485,5436 Total: 3841,3837,3818 Write: 1400808 Read: 1601404  
    Still no idea why with with Orange Pi Plus and 1 GB RAM massive swapping occurs while the same benchmark on NanoPi Fire3 also with 1 GB results in low swapping attempts (different kernels, maybe different contents of /proc/sys/vm/*)
  23. Like
    Werner got a reaction from tkaiser in sbc-bench   
    Sure thing.  I'll catch up later.
  24. Like
    Werner reacted to tkaiser in sbc-bench   
    Haha, but now I know. I was an idiot before since it's simply zram/swap as can be easily seen by comparing iostat output from before and after:
    before: zram1 0.93 3.69 0.01 1176 4 zram2 0.93 3.69 0.01 1176 4 zram3 0.93 3.69 0.01 1176 4 zram4 0.93 3.69 0.01 1176 4 after: zram1 588.13 1101.08 1251.45 1408792 1601184 zram2 586.62 1094.84 1251.62 1400808 1601404 zram3 582.01 1087.59 1240.44 1391524 1587092 zram4 587.14 1098.00 1250.54 1404848 1600016 That's 5.3GB read and 6.1GB written on the zram devices. I still have no idea why this benchmark on some boards (most probably kernels) runs with 1 GB without swapping but not on others like here:
    RAM size: 994 MB, # CPU hardware threads: 4 RAM usage: 882 MB, # Benchmark threads: 4 NanoPi Fire3 also with just 1 GB RAM finishes with only minimal swapping:
    RAM size: 990 MB, # CPU hardware threads: 8 RAM usage: 901 MB, # Benchmark threads: 8 Maybe vm.swappiness is the culprit. Can you repeat the bench another three times doing the following prior to each run:
    sysctl -w vm.swappiness=0 sysctl -w vm.swappiness=1 sysctl -w vm.swappiness=60  
  25. Like
    Werner reacted to Igor in Orange Pi Lite2 wireless support   
    I'll try to bring it up in 4.19.y ... some basic support is getting mainlined and it will be less troublesome. I hope.