Active threads

Showing topics posted in for the last 365 days.

This stream auto-updates     

  1. Yesterday
  2. shippy

    ARMBIAN for Amlogic S905 and S905X

    I haven't installed Armbian yet. Trying to gather enough information to decide if I want to install Android on my TV boxes (e.g., Nexbox A95) or Armbian, with S905W or RK3229. Armbian gives me the ability to install and use many more features, e.g., OpenWrt for networking and WiFi. I do want HW acceleration with Kodi, because I plan to run several concurrent Kodi/SPMC instances for h264/720p streams. Maybe even try Ubuntu multi-seat (2-3 instances)! I am assuming VPU can handle this. The Penta GPU should handle Xorg for multiple I/O. I don't have interest in 1080p/4K streaming.
  3. tkaiser

    RockPro64

    Nope, every Northbridge cooler with a mounting hole distance of 60 mm will work. Latest ayufan release from few hours ago activated USB so let's do a quick USB3 storage benchmark with an EVO840 in a JMS567 enclosure. Testing with our usual iozone benchmark: random random kB reclen write rewrite read reread read write 102400 4 19833 26941 35089 35464 24545 26763 102400 16 66374 85914 107740 108213 79784 86035 102400 512 308034 318723 298717 301950 293118 316910 102400 1024 335762 349205 335279 338808 330313 346358 102400 16384 379379 382513 378721 383947 383529 384295 1024000 16384 397369 402562 384391 384846 Up to 400 MB/s as expected. Current ayufan images are yet not optimized for performance. They're missing increase in CPU clockspeeds (1.4/1.8 GHz instead of 1.5/2.0 GHz) and also do not use latest DRAM initialization (RockPro64 is the first RK3399 device using LPDDR4 so with appropriate DRAM initialization everything memory dependent -- e.g. I/O DMA -- will be faster afterwards) I also did a quick iperf3 test in the meantime: +940 MBits/sec in both directions after ayufan adjusted TX/RX delay values:
  4. TonyMac32

    Librecomputer Tritium H3

    Well, that's still more or less it, with me working on Meson64 and rk3288. PR's have increased a little in recent weeks I think, and sometimes they aren't being thoroughly reviewed, but that's a situation where the only solution is to hold ourselves to having people review and acknowledge a PR before it can be merged. I think the variety of "special needs" boards is a problem, an example is the amount of time I have to spend simply keeping Tinker adjustments from breaking MiQi before rolling them out (and with that I'm not 100% successful). I can't imagine the array of "same but different" Allwinner boards, and looking at the patch directories kind of shows it easily. It's one of the reasons I was willing to suggest the Tritium boards, so far they have no special needs, other than the likely mistaken identity issues that could surface. (And honestly, with the naming conventions of OPi and BPi, they have the same issue, if for different reasons)
  5. tkaiser

    Odroid C2 - update to v5.44 / v5.45 not working?

    Well, every other week the same question is asked here so the mechanism to display a random version number contained in /etc/armbian-release that is part of one specific package that doesn't get updated each time Armbian version number is increased is obviously misleading.
  6. jock

    Armbian for RK3288 XT-Q8L-V10 (Q8) boards

    I guess there is something wrong with the i2c driver. This is the output I can gather using the armbian image with 4.4.126 kernel: root@xt:/home/paolo# dmesg | grep i2c [ 2.876359] i2c /dev entries driver [ 2.877897] of_get_named_gpiod_flags: can't parse 'vsel-gpios' property of node '/i2c@ff650000/syr827@40[0]' [ 2.877913] of_get_named_gpiod_flags: can't parse 'vsel-gpio' property of node '/i2c@ff650000/syr827@40[0]' [ 2.881312] of_get_named_gpiod_flags: can't parse 'vsel-gpios' property of node '/i2c@ff650000/syr828@41[0]' [ 2.881328] of_get_named_gpiod_flags: can't parse 'vsel-gpio' property of node '/i2c@ff650000/syr828@41[0]' [ 2.908968] rk3x-i2c ff650000.i2c: Initialized RK3xxx I2C bus at f0fba000 [ 2.910075] rk3x-i2c ff140000.i2c: Initialized RK3xxx I2C bus at f0fbc000 [ 2.911169] rk3x-i2c ff160000.i2c: Initialized RK3xxx I2C bus at f0fbe000 [ 2.912242] rk3x-i2c ff170000.i2c: Initialized RK3xxx I2C bus at f0fd2000 [ 2.913370] rk3x-i2c ff660000.i2c: Initialized RK3xxx I2C bus at f0fd4000 [ 8.226809] i2c i2c-6: Added multiplexed i2c bus 7 [ 8.228102] i2c i2c-6: Added multiplexed i2c bus 8 root@xt:/home/paolo# i2cdetect -y 5 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- 37 -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- 4a 4b -- -- -- -- 50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- root@xt:/home/paolo# get-edid -b 5 | parse-edid 5 This is read-edid version 3.0.2. Prepare for some fun. Attempting to use i2c interface Only trying 5 as per your request. 256-byte EDID successfully retrieved from i2c bus 5 Looks like i2c was successful. Have a good day. Checksum Correct Section "Monitor" Identifier "PL2390" ModelName "PL2390" VendorName "IVM" # Monitor Manufactured week 6 of 2016 # EDID version 1.3 # Digital Display DisplaySize 510 290 Gamma 2.20 Option "DPMS" "true" Horizsync 30-83 VertRefresh 55-76 # Maximum pixel clock is 170MHz #Not giving standard mode: 1920x1080, 60Hz #Not giving standard mode: 1280x1024, 60Hz #Not giving standard mode: 1440x900, 60Hz #Not giving standard mode: 1680x1050, 60Hz #Not giving standard mode: 1280x960, 60Hz #Not giving standard mode: 1152x864, 75Hz #Not giving standard mode: 1440x900, 75Hz #Extension block found. Parsing... Modeline "Mode 13" 27.00 720 736 798 858 480 489 495 525 -hsync -vsync Modeline "Mode 0" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync Modeline "Mode 1" 25.200 640 656 752 800 480 490 492 525 -hsync -vsync Modeline "Mode 2" 27.027 720 736 798 858 480 489 495 525 -hsync -vsync Modeline "Mode 3" 27.027 720 736 798 858 480 489 495 525 -hsync -vsync Modeline "Mode 4" 74.250 1280 1390 1420 1650 720 725 730 750 +hsync +vsync Modeline "Mode 5" 74.250 1920 2008 2052 2200 1080 1082 1087 1125 +hsync +vsync interlace Modeline "Mode 6" 148.500 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync Modeline "Mode 7" 27.000 720 732 796 864 576 581 586 625 -hsync -vsync Modeline "Mode 8" 27.000 720 732 796 864 576 581 586 625 -hsync -vsync Modeline "Mode 9" 74.250 1280 1720 1760 1980 720 725 730 750 +hsync +vsync Modeline "Mode 10" 74.250 1920 2448 2492 2640 1080 1082 1089 1125 +hsync +vsync interlace Modeline "Mode 11" 54.000 1440 1464 1592 1728 576 581 586 625 -hsync -vsync Modeline "Mode 12" 148.500 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync Modeline "Mode 14" 74.25 1280 1390 1430 1650 720 725 730 750 +hsync +vsync Modeline "Mode 15" 27.00 720 732 796 864 576 581 586 625 -hsync -vsync Option "PreferredMode" "Mode 13" EndSection So EDID works fine on my box using i2c5. I get devices at addresses 37 and 50 as you described and get-edit tool works fine. Also data is correctly reported (display name, modelines, etc...) The i2c6 bus appearing in your test can be probably explained taking a look to the kernel documentation. I found this in the device tree documentation: so that bus is directly embedded into the HDMI controller and spawns up when there is not a master i2c bus for EDID, which is what you did removing the line from the device tree. From what I understand, that works but is suboptimal. To satisfy my curiosity I will try swapping the buses to see what happens. In the meantime you may do tests with another HDMI cable, it is quite common that faulty or cheap cables causes many kinds of issues (HDMI CEC not working or working intermittently for example...) Check the u-boot device tree for &pinctrl section. You'll find these lines: &pinctrl { u-boot,dm-pre-reloc; pinctrl-names = "default"; pinctrl-0 = <&power_led>, <&pwr_hold>; ... act8846 { /* * Original q8 device tree says: * - gpio0 11 HIGH -> power hold * - gpio7 1 LOW -> possibly pmic-vsel, we omit it here */ /*pmic_vsel: pmic-vsel { rockchip,pins = <7 1 RK_FUNC_GPIO &pcfg_output_low>; };*/ pwr_hold: pwr-hold { rockchip,pins = <0 11 RK_FUNC_GPIO &pcfg_pull_up>; }; }; ... }; This way u-boot is instructed to turn the power led GPIO active and the power hold GPIO (which is pin 11 of bank 0) active at boot. edit: I made some tests with other i2c buses, nothing did work, only i2c5 is able to retrieve a valid EDID to me
  7. chwe

    BananaPi R2 (.csc)

    A shortly update: U-Boot is fixed to a level where I decide, that it isn't worth to put more efforts in at the moment... Bootorder: tries to boot with bootscript sitting in /boot/boot.scr (tested works) in case there is not bootscript or the script fails --> uInitrd, zImage, dtb in armbians default folders and if there is no uInitrd (or it isn't 'sane') it boots with zImage and dtb only. booargs=earlyprintk initcall_debug console=ttyS0,115200n1 root=/dev/mmcblk0p1 rw rootfstype=ext4 rootwait audit=0 Memory adressing: ~62MB for the kernel 512kB for boot.scr 512kB for DTB 32MB for uInitrd Don't know how 'sane' those settings are, but it should be more than enough... In case someone wants for whatever reasons uImages with flattened device tree, you can place a bootscript in mmc 1:1 /boot/boot.scr and do whatever u-boot is able to do. Every boot without a boot.scr will set some default bootargs (earlyprintk initcall_debug console=ttyS0,115200n1 root=/dev/mmcblk0p1 rw rootfstype=ext4 rootwait audit=0), in case you test a build and those bootargs aren't correct for you (especially root=/dev/mmcblk0p1 and rootfstype=ext4) better interrupt the boot (you've a 3 seconds timeframe for doing that, and set proper bootargs for your boot to avoid fooling your kernel.. earlyprintk is enabled by default when you use my config file and it's set to the right serial-console for the R2 CONFIG_DEBUG_UART_PHYS=0x11004000 CONFIG_DEBUG_UART_VIRT=0xf1004000 (earlyprintk will be silent without proper settings here, and the currently available defconfig sets them false, probably cause it's based on the evb board, where UART0 is used as debug, whereas the R2 uses UART2 for it) There is currently no 'preboot logic' for to decide if mmc 1 (SD-card) or mmc 0 (eMMC) should be initialized and u-boot expects ext4 FS , but cause all load commands and all calls to mmc_number/partition are done with variables, such a 'preboot-logic' shouldn't be that hard to implement. It's flexible enough but I didn't implement it yet. We're far away for a 'nand-sata-install' implementation and therefore there it's to early to care about such a implementation. As far as I see it at the moment such a 'preboot logic' wouldn't need any rework of the 'bootlogic' (but who knows, u-boot fooled me more than once... ). There are still a bunch of warnings during build of u-boot but none of them seems to be 'harmful'. As long as u-boot doesn't bother me anymore or not behaves as it should, I wont clean it up more that it is now.. eMMC is not on my 'priority list' so don't expect that care much about it in the near future It's somewhere between HDMI and onboard wifi and I don't care about both 'features'... Just to point it out. I will not look into HDMI as long as those patches aren't available in Linus tree. If someone else writes a proper patch to implement it earlier fine, I'm not willing to do it (and I don't have a spare HDMI display to test it, so someone else has to test it too.. ). 799 bytes read in 34 ms (22.5 KiB/s) Running boot/boot.scr from: mmc 1:1 using boot/boot.scr ## Executing script at 85f80000 33841 bytes read in 47 ms (703.1 KiB/s) 4789617 bytes read in 695 ms (6.6 MiB/s) 6091360 bytes read in 864 ms (6.7 MiB/s) Booting boot/zImage boot/uInitrd boot/dtb/mt7623n-bananapi-bpi-r2.dtb from: mmc 1:1 using bootargs=initcall_debug console=ttyS0,115200n1 root=/dev/mmcblk0p1 rw rootfstype=ext4 rootwait audit=0 loglevel=1 bootm flag=0, states=1 Kernel image @ 0x82000000 [ 0x000000 - 0x5cf260 ] ## Loading init Ramdisk from Legacy Image at 86080000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 4789553 Bytes = 4.6 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 86000000 Booting using the fdt blob at 0x86000000 bootm flag=0, states=700 Loading Ramdisk to 8fb6e000, end 8ffff531 ... OK Loading Device Tree to 8fb62000, end 8fb6d430 ... OK Starting kernel ... Uncompressing Linux... done, booting the kernel. ... ... ... [ OK ] Reached target Login Prompts. [ OK ] Started LSB: Start NTP daemon. [ OK ] Reached target Multi-User System. [ OK ] Reached target Graphical Interface. Starting Update UTMP about System Runlevel Changes... [ OK ] Started Update UTMP about System Runlevel Changes. Debian GNU/Linux 9 bananapir2 ttyS0 bananapir2 login: Next steps: Network (mostly untested, but as far as I know, it doesn't connect automatically to my router) Kernelconfig should be adjusted to have something 'armbianalike' As soon as network works 'reliable', I hope that others step in for discussion & testing. I think we reach than a point where most of the 'interesting features' (USB, SATA, Network) are there, so usage as NAS or 'Routerboard'. At the moment, desktop is disabled, and might be disabled until someone deals with HDMI. [off topic] Still don't think that I'm a experienced u-boot hacker... But arrogant enough to call my self a u-boot plumber now...
  8. So far tried: 1. dd - dump emmc to SD card and boot from SD card wich was 1:1 image of emmc - OK: U-Boot SPL 2017.11-armbian (Jan 25 2018 - 07:58:02) DRAM: 2048 MiB Trying to boot from MMC1 U-Boot 2017.11-armbian (Jan 25 2018 - 07:58:02 +0100) Allwinner Technology CPU: Allwinner H3 (SUN8I 1680) Model: Xunlong Orange Pi Plus / Plus 2 DRAM: 2 GiB MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Net: phy interface7 eth0: ethernet@1c30000 starting USB... USB0: USB EHCI 1.00 USB1: USB EHCI 1.00 scanning bus 0 for devices... 2 USB Device(s) found scanning bus 1 for devices... Device NOT ready Request Sense returned 02 3A 00 2 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Autoboot in 1 seconds, press <Space> to stop switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 3708 bytes read in 149 ms (23.4 KiB/s) ## Executing script at 43100000 U-boot loaded from SD Boot script loaded from mmc 21 bytes read in 171 ms (0 Bytes/s) 4578312 bytes read in 459 ms (9.5 MiB/s) 6972808 bytes read in 537 ms (12.4 MiB/s) Found mainline kernel configuration 33781 bytes read in 491 ms (66.4 KiB/s) 401 bytes read in 146 ms (2 KiB/s) Applying user provided DT overlay ds1307.dtbo ** File not found /boot/dtb/overlay/-fixup.scr ** ## Loading init Ramdisk from Legacy Image at 43300000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 4578248 Bytes = 4.4 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 43000000 Booting using the fdt blob at 0x43000000 Loading Ramdisk to 49ba2000, end 49fffbc8 ... OK reserving fdt memory region: addr=43000000 size=6e000 Loading Device Tree to 49b31000, end 49ba1fff ... OK Starting kernel ... Loading, please wait... Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems done. Begin: Will now check root file system ... fsck from util-linux 2.25.2 [/sbin/fsck.ext4 (1) -- /dev/mmcblk0p1] fsck.ext4 -a -C0 /dev/mmcblk0p1 /dev/mmcblk0p1: clean, 81229/918720 files, 466019/3781376 blocks done. done. Begin: Running /scripts/local-bottom ... done. Begin: Running /scripts/init-bottom ... done. Welcome to Debian GNU/Linux 8 (jessie)! Expecting device dev-ttyS0.device... [ OK ] Reached target Remote File Systems (Pre). [ OK ] Reached target Paths. [ OK ] Set up automount Arbitrary Executable File Formats F...utomount Point. [ OK ] Reached target Encrypted Volumes. [ OK ] Created slice Root Slice. [ OK ] Listening on Delayed Shutdown Socket. [ OK ] Listening on /dev/initctl Compatibility Named Pipe. [ OK ] Listening on Journal Socket (/dev/log). [ OK ] Created slice User and Session Slice. [ OK ] Listening on udev Control Socket. 2. When running from SD - as below. Seems to be exactly the same as on legacy. root@PKBACKUP:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT mmcblk1boot0 179:16 0 4M 1 disk mmcblk1 179:8 0 14.6G 0 disk └─mmcblk1p1 179:9 0 14.4G 0 part mmcblk1boot1 179:24 0 4M 1 disk mmcblk0 179:0 0 14.9G 0 disk └─mmcblk0p1 179:1 0 14.4G 0 part / root@PKBACKUP:~# 3. When running from SD move armbian to EMMC by nand-sata-install. Boot from emmc (after message saying "now poweroff ...") - FAILED as before: U-Boot SPL 2017.11-armbian (Jan 25 2018 - 07:58:02) DRAM: 2048 MiB Trying to boot from MMC2 U-Boot 2017.11-armbian (Jan 25 2018 - 07:58:02 +0100) Allwinner Technology CPU: Allwinner H3 (SUN8I 1680) Model: Xunlong Orange Pi Plus / Plus 2 DRAM: 2 GiB MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Net: phy interface7 eth0: ethernet@1c30000 starting USB... USB0: USB EHCI 1.00 USB1: USB EHCI 1.00 scanning bus 0 for devices... 2 USB Device(s) found scanning bus 1 for devices... Device NOT ready Request Sense returned 02 3A 00 2 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Autoboot in 1 seconds, press <Space> to stop switch to partitions #0, OK mmc1(part 0) is current device Scanning mmc 1:1... Found U-Boot script /boot/boot.scr 3708 bytes read in 134 ms (26.4 KiB/s) ## Executing script at 43100000 U-boot loaded from eMMC or secondary SD Boot script loaded from mmc 21 bytes read in 154 ms (0 Bytes/s) MMC: no card present mmc_init: -123, time 2 ** Bad device mmc 0 ** 4578312 bytes read in 464 ms (9.4 MiB/s) 6972808 bytes read in 559 ms (11.9 MiB/s) Found mainline kernel configuration 33781 bytes read in 645 ms (50.8 KiB/s) 401 bytes read in 188 ms (2 KiB/s) Applying user provided DT overlay ds1307.dtbo ** File not found /boot/dtb/overlay/-fixup.scr ** ## Loading init Ramdisk from Legacy Image at 43300000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 4578248 Bytes = 4.4 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 43000000 Booting using the fdt blob at 0x43000000 Loading Ramdisk to 49ba2000, end 49fffbc8 ... OK reserving fdt memory region: addr=43000000 size=6e000 Loading Device Tree to 49b31000, end 49ba1fff ... OK Starting kernel ... Loading, please wait... Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems done. Begin: Waiting for root file system ... Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. done. Gave up waiting for root device. Common problems: - Boot args (cat /proc/cmdline) - Check rootdelay= (did the system wait long enough?) - Check root= (did the system wait for the right device?) - Missing modules (cat /proc/modules; ls /dev) ALERT! /dev/mmcblk0p1 does not exist. Dropping to a shell! Rebooting automatically due to panic= boot argument [ 44.940297] reboot: Restarting system U-Boot SPL 2017.11-armbian (Jan 25 2018 - 07:58:02) DRAM: 2048 MiB Trying to boot from MMC2 U-Boot 2017.11-armbian (Jan 25 2018 - 07:58:02 +0100) Allwinner Technology CPU: Allwinner H3 (SUN8I 1680) Model: Xunlong Orange Pi Plus / Plus 2 DRAM: 2 GiB
  9. @lex

    NanoPi K1 Plus to be released soon

    last numbers: openssl speed -elapsed -evp aes-256-cbc You have chosen to measure elapsed time instead of user CPU time. Doing aes-256-cbc for 3s on 16 size blocks: 21097762 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 64 size blocks: 13885050 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 256 size blocks: 5712407 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 1024 size blocks: 1744124 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 8192 size blocks: 232965 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 16384 size blocks: 116966 aes-256-cbc's in 3.00s OpenSSL 1.1.0g 2 Nov 2017 built on: reproducible build, date unspecified options:bn(64,64) rc4(char) des(int) aes(partial) blowfish(ptr) compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/lib/ssl\"" -DENGINESDIR="\"/usr/lib/aarch64-linux-gnu/engines-1.1\"" The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-256-cbc 112521.40k 296214.40k 487458.73k 595327.66k 636149.76k cpufreq-info -c 1 cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. 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: 2.54 ms. hardware limits: 480 MHz - 1.37 GHz available frequency steps: 480 MHz, 648 MHz, 720 MHz, 768 MHz, 912 MHz, 1.08 GHz, 1.20 GHz, 1.37 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 480 MHz and 1.37 GHz. The governor "performance" may decide which speed to use within this range. current CPU frequency is 1.37 GHz. cpufreq stats: 480 MHz:4.74%, 648 MHz:1.64%, 720 MHz:0.35%, 768 MHz:0.59%, 912 MHz:0.48%, 1.08 GHz:0.44%, 1.20 GHz:0.38%, 1.37 GHz:91.36% (3239) at least, 4.17 pretty stable... I think there is room for improvement, board does not get Temp over 54 ºC so lets the experts handle this...
  10. TonyMac32

    nano pi k2 installing to usb

    You could say that... As far as what I said. ;-). The bootloader on K2 with Armbian is a binary blob from a 2015 release of the bootloader, with some modifications by the SoC vendor. It does not support a lot of things that are common today. Mainline is the current release and actively maintained version of the bootloader, it doesn't have "plug and play" support for this board but it does for a nearly identical board from another company, and it supports all the interesting boot methods.
  11. zador.blood.stained

    Any desktop image for Orange Pi Zeo Plus 2 [Allwinner H5] ?

    We decided to not provide desktop builds for 64bit devices with 512MB RAM so we will not release any prebuilt desktop images for this board. It is still possible to install necessary packages and configure them manually.
  12. Igor

    ROCK64: RAM overclock possible?

    https://github.com/ayufan-rock64/linux-build/blob/master/recipes/overclocking.md
  13. guidol

    TTL to RS232 possible?

    Do you power via the VCC Pin (only RX,TX,GND isnt powered) - and with how much Volt? Specifications Operating voltage: 3.3V-5V DC Operating current: 6mA Power supply: external Which RS232 cable/adapters do you use? maybe if more than 1 nullmodem will switch back to RX/RX and TX/TX. Or did you use gender changers or 9->24pin adapters?
  14. JMCC

    Mainline kernel on Odroid XU4

    Yeah, definitely, leaving existing 4.9 kernel users without updates doesn't fit "the Armbian way" of doing things, even though Hardkernel themselves don't update their 4.9 kernels anymore. That would be a dirty trick that I would do, taking excuse on the fact that new 5422-based boards have been released and so justifying the change in the package names, but doing it really to get rid of the kernel upgrade problem that is getting so old. I'm glad that you guys are more serious than that
  15. sky_khan

    no display from VGA output

    I've noticed this thread after that I've tried downgrading u-boot as written here but unfortunately my cubietruck still outputs to HDMI no matter whatever I tried :/ What else I need to do ? Could you give me a correct configuration for this please?
  16. Hello! Orange pi+ 2e. Armbian Xenial / 5.38 (Ubuntu 16.04.4) I wrote my problem here deeponion.org/community/threads/deeponion-raspberry-pi-compilation-detailed-tutorial.37264/page-5#post-613271 I have compiled, launched and synchronized wallet. Everything is good but... But here is the problem: when I restarting DeepOnion-qt (after encrypt for example), it gives an error. If I delete the file wallet.dat, then the startup occurs again (the file wallet.dat is created new). or@orangepiplus2e:~$ ./deeponion/src/qt/DeepOnion-qt May 23 18:46:15.873 [notice] Tor 0.3.4.0-alpha-dev (git-192c7c8bf9a3c53d) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2g, Zlib 1.2.8, Liblzma N/A, and Libzstd N/A. May 23 18:46:15.873 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning May 23 18:46:15.873 [notice] This version is not a stable Tor release. Expect more bugs than usual. May 23 18:46:15.873 [notice] Configuration file "/home/or/.DeepOnion/tor/torrc" not present, using reasonable defaults. May 23 18:46:15.888 [notice] Scheduler type KIST has been enabled. May 23 18:46:15.889 [notice] Opening Socks listener on 127.0.0.1:9081 ============================================================ T= 1527101180 Tor 0.3.4.0-alpha-dev (git-192c7c8bf9a3c53d) died: Caught signal 11 ./deeponion/src/qt/DeepOnion-qt(+0x447ac2)[0xb6c9fac2] /usr/lib/arm-linux-gnueabihf/libstdc++.so.6(_ZSt18_Rb_tree_incrementPKSt18_Rb_tree_node_base+0x7)[0xb5a45bec] Aborted or@orangepiplus2e:~$ some more info $ ldd $(which apt-get) r@orangepiplus2e:~$ ldd $(which apt-get) libapt-pkg.so.5.0 => /usr/lib/arm-linux-gnueabihf/libapt-pkg.so.5.0 (0xb6db6000) libapt-private.so.0.0 => /usr/lib/arm-linux-gnueabihf/libapt-private.so.0.0 (0xb6d71000) libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb6c63000) libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb6c3b000) libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6b4f000) /lib/ld-linux-armhf.so.3 (0xb6ee3000) libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb6b3c000) libresolv.so.2 => /lib/arm-linux-gnueabihf/libresolv.so.2 (0xb6b1c000) libz.so.1 => /lib/arm-linux-gnueabihf/libz.so.1 (0xb6afa000) libbz2.so.1.0 => /lib/arm-linux-gnueabihf/libbz2.so.1.0 (0xb6ade000) liblzma.so.5 => /lib/arm-linux-gnueabihf/liblzma.so.5 (0xb6abe000) liblz4.so.1 => /usr/lib/arm-linux-gnueabihf/liblz4.so.1 (0xb6aa0000) libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb6a28000) or@orangepiplus2e:~$ $ sudo ldconfig -v | grep libstdc++.so.6 or@orangepiplus2e:~$ sudo ldconfig -v | grep libstdc++.so.6 [sudo] password for or: /sbin/ldconfig.real: Path `/lib/arm-linux-gnueabihf' given more than once /sbin/ldconfig.real: Path `/usr/lib/arm-linux-gnueabihf' given more than once /sbin/ldconfig.real: /lib/arm-linux-gnueabihf/ld-2.23.so is the dynamic linker, ignoring libstdc++.so.6 -> libstdc++.so.6.0.21 /sbin/ldconfig.real: Cannot stat /usr/lib/libmca_common_sm.so: No such file or directory /sbin/ldconfig.real: Cannot stat /usr/lib/libopen-pal.so: No such file or directory /sbin/ldconfig.real: Cannot stat /usr/lib/libopen-rte.so: No such file or directory /sbin/ldconfig.real: Cannot stat /usr/lib/liboshmem.so: No such file or directory or@orangepiplus2e:~$ $ gcc -v or@orangepiplus2e:~$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/5/lto-wrapper Target: arm-linux-gnueabihf Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.9' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-armhf/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-armhf --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-armhf --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror --enable-multilib --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf Thread model: posix gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.9) or@orangepiplus2e:~$ What can I do for fix this problem? Sorry if I wrote in wrong place. Thanks for answer and for your work!
  17. Hum looks like I went too fast in buying that board as Raspberry replacement Sitting on my desk since january and guess will stay there for a while
  18. Yes - the Orange Pi Zero Plus does need his own image You could use https://dl.armbian.com/orangepizeroplus/archive/Armbian_5.45_Orangepizeroplus_Debian_stretch_next_4.14.43.7z or you may select one by your own choice from https://dl.armbian.com/orangepizeroplus/
  19. balbes150

    Armbian for Amlogic S805

    no https://docs.armbian.com/User-Guide_Armbian-Config/
  20. umiddelb

    Booting a rt preempt patched kernel

    IMHO there is no way to implement any kind of interaction when running a boot script. I've ended up defining a set of u-boot macros which I run on the interactive console, eg `run _t´ to boot a test kernel `run _2' to boot from the second partition of the (default) boot device For the ODROID N1 we're discussing to potential use of petitboot due to the current u-boot limitations.
  21. Johhny Blue

    Audio on NEO Core Mainline

    I have been playing around with this as it is really annoying and have found that (on my board) by unmuting mic1, playback will be instant - but there is a loud pop/click. Does anyone know how to remove the click/pop? J.
  22. Last week
  23. Сергей Кравченко

    Bionic Beaver coming to town...

    I just successfully upgraded Orange Pi+2E to 18.04 using these instructions:
  24. You are right. I copied a wrong file. Thank you very much.
  25. zador.blood.stained

    [OPi Plus 2] SPI1 pins

    In theory - yes, but keep in mind that the bus bandwidth will be split between 3 devices so you'll get lower FPS and worse touch screen responsiveness than if they were connected to dedicated SPI controllers. You will need to add extra GPIO chip selects using this as an example and add 3 slave SPIdev devices like here.
  26. because of the emmc of the Core2 I do use image of the NanoPi Neo Plus2 (also H5 CPU) https://dl.armbian.com/nanopineoplus2/ but @Igor the NanoPi Neo Plus2 isnt at the Download-page https://www.armbian.com/download/?tx_maker=friendlyelec
  27. Larry Bank

    Pushing the I2C SSD1306 OLED to its limits

    Thanks for the response. I took the path of least resistance and tested it on a Raspberry Pi Zero. On that platform I can edit the /boot/config.txt to change the I2C speed. It maxes out at 400Khz no matter what value you give it. That's fast enough to do decent animation: I wrote a blog post and shared the code on github: http://bitbanksoftware.blogspot.com/2018/05/practical-animation-on-i2c-ssd1306.html
  1. Load more activity