All Activity

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

    Librecomputer Tritium H3

    It does appear the project is now at a size where discipline around feature branches and merges. Who are the principle contributors at this point... cuz it used to be like Igor, Zador and Tkaiser, so a flat branch was managable
  7. Fozzy

    ARMBIAN for Amlogic S905 and S905X

    @balbes150 Hello ! I've installed the Armbian_5.44_S9xxx_Ubuntu_bionic_3.14.29_icewm_20180515.img version of the Armbian. Everything works good, wifi, usb, etc... THANKS ! But when i'm installing Kodi, I get this messages: Reading package lists... Done Building dependency tree Reading state information... Done Note, selecting 'aml-kodi' instead of '/media/dm/USBBB/aml-kodi-debian_5.41_arm64.deb' Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: aml-kodi : Depends: libcdio13 (>= 0.83) but it is not installable Depends: libjpeg62-turbo (>= 1.3.1) but it is not installable E: Unable to correct problems, you have held broken packages. dm@amlogic:/media/dm/USBBB$ sudo apt install -f /media/dm/USBBB/aml-kodi-ubuntu_5.41_arm64.deb Reading package lists... Done Building dependency tree Reading state information... Done Note, selecting 'aml-kodi' instead of '/media/dm/USBBB/aml-kodi-ubuntu_5.41_arm64.deb' Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: aml-kodi : Depends: libavcodec-ffmpeg56 (>= 7:2.4) but it is not installable or libavcodec-ffmpeg-extra56 (>= 7:2.4) but it is not installable Depends: libavfilter-ffmpeg5 (>= 7:2.4) but it is not installable Depends: libavformat-ffmpeg56 (>= 7:2.6) but it is not installable Depends: libavutil-ffmpeg54 (>= 7:2.4) but it is not installable Depends: libcdio13 (>= 0.83) but it is not installable Depends: libglew1.13 (>= 1.12.0) but it is not installable Depends: libmicrohttpd10 (>= 0.9.20) but it is not installable Depends: libpng12-0 (>= 1.2.13-4) but it is not installable Depends: libpostproc-ffmpeg53 (>= 7:2.4) but it is not installable Depends: libswresample-ffmpeg1 (>= 7:2.4) but it is not installable Depends: libswscale-ffmpeg3 (>= 7:2.4) but it is not installable Depends: libva-x11-1 (>= 1.0.3) but it is not installable Depends: libva1 (>= 1.2.0) but it is not installable Depends: libva-drm1 but it is not installable Depends: libcurl3 but it is not going to be installed E: Unable to correct problems, you have held broken packages. Before installing main package i had installed other necessary packages - codec, mali7. Why is there dependencies issues?
  8. 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
  9. talraash

    ARMBIAN for Amlogic S905 and S905X

    yep, it's just different version of libmali(mali-5...mali-7) @shippy What kind of problems do you have in kodi? I see low cpu usage in h264/1080p so hw decoding and acceleration work correct in armbian/kodi
  10. 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...
  11. 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
  12. @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...
  13. shippy

    ARMBIAN for Amlogic S905 and S905X

    What I mean is: Is video processing going to improve for Armbian builds with Kodi 18 upgrades for VDPAU and AMLCodecs? One problem with Armbian builds seems to be that Android has better video hardware acceleration support for Kodi. I think this is true for S905 but don't know for RK3229/later versions. Maybe video acceleration on Armbian and Android are same at lower resolutions and compression like h264/720p?
  14. @lex

    NanoPi K1 Plus to be released soon

    ./tinymembench tinymembench v0.4.9 (simple benchmark for memory throughput and latency) ========================================================================== == Memory bandwidth tests == == == == Note 1: 1MB = 1000000 bytes == == Note 2: Results for 'copy' tests show how many bytes can be == == copied per second (adding together read and writen == == bytes would have provided twice higher numbers) == == Note 3: 2-pass copy means that we are using a small temporary buffer == == to first fetch data into it, and only then write it to the == == destination (source -> L1 cache, L1 cache -> destination) == == Note 4: If sample standard deviation exceeds 0.1%, it is shown in == == brackets == ========================================================================== C copy backwards : 1099.0 MB/s (0.9%) C copy backwards (32 byte blocks) : 1095.5 MB/s (0.9%) C copy backwards (64 byte blocks) : 1086.3 MB/s (0.4%) C copy : 1097.6 MB/s (1.2%) C copy prefetched (32 bytes step) : 892.8 MB/s (0.3%) C copy prefetched (64 bytes step) : 993.4 MB/s C 2-pass copy : 1096.8 MB/s C 2-pass copy prefetched (32 bytes step) : 758.1 MB/s C 2-pass copy prefetched (64 bytes step) : 714.6 MB/s C fill : 3859.1 MB/s (0.1%) C fill (shuffle within 16 byte blocks) : 3856.1 MB/s C fill (shuffle within 32 byte blocks) : 3856.9 MB/s C fill (shuffle within 64 byte blocks) : 3854.5 MB/s --- standard memcpy : 1116.0 MB/s (0.3%) standard memset : 3858.4 MB/s (0.1%) --- NEON LDP/STP copy : 1124.8 MB/s (0.2%) NEON LDP/STP copy pldl2strm (32 bytes step) : 799.7 MB/s (0.4%) NEON LDP/STP copy pldl2strm (64 bytes step) : 963.3 MB/s NEON LDP/STP copy pldl1keep (32 bytes step) : 1164.5 MB/s NEON LDP/STP copy pldl1keep (64 bytes step) : 1164.5 MB/s NEON LD1/ST1 copy : 1109.6 MB/s (0.5%) NEON STP fill : 3860.1 MB/s (0.1%) NEON STNP fill : 3584.2 MB/s (0.7%) ARM LDP/STP copy : 1126.1 MB/s (0.2%) ARM STP fill : 3858.9 MB/s ARM STNP fill : 3584.7 MB/s (0.8%) ========================================================================== == Memory latency test == == == == Average time is measured for random memory accesses in the buffers == == of different sizes. The larger is the buffer, the more significant == == are relative contributions of TLB, L1/L2 cache misses and SDRAM == == accesses. For extremely large buffer sizes we are expecting to see == == page table walk with several requests to SDRAM for almost every == == memory access (though 64MiB is not nearly large enough to experience == == this effect to its fullest). == == == == Note 1: All the numbers are representing extra time, which needs to == == be added to L1 cache latency. The cycle timings for L1 cache == == latency can be usually found in the processor documentation. == == Note 2: Dual random read means that we are simultaneously performing == == two independent memory accesses at a time. In the case if == == the memory subsystem can't handle multiple outstanding == == requests, dual random read has the same timings as two == == single reads performed one after another. == ========================================================================== block size : single random read / dual random read, [MADV_NOHUGEPAGE] 1024 : 0.0 ns / 0.0 ns 2048 : 0.0 ns / 0.0 ns 4096 : 0.0 ns / 0.0 ns 8192 : 0.0 ns / 0.0 ns 16384 : 0.0 ns / 0.0 ns 32768 : 0.0 ns / 0.0 ns 65536 : 5.0 ns / 8.4 ns 131072 : 7.7 ns / 11.7 ns 262144 : 9.0 ns / 13.1 ns 524288 : 10.6 ns / 15.0 ns 1048576 : 94.4 ns / 145.3 ns 2097152 : 139.6 ns / 187.6 ns 4194304 : 168.3 ns / 208.4 ns 8388608 : 183.7 ns / 217.9 ns 16777216 : 192.6 ns / 224.3 ns 33554432 : 197.2 ns / 228.1 ns 67108864 : 201.0 ns / 232.2 ns block size : single random read / dual random read, [MADV_HUGEPAGE] 1024 : 0.0 ns / 0.0 ns 2048 : 0.0 ns / 0.0 ns 4096 : 0.0 ns / 0.0 ns 8192 : 0.0 ns / 0.0 ns 16384 : 0.0 ns / 0.0 ns 32768 : 0.0 ns / 0.0 ns 65536 : 5.0 ns / 8.4 ns 131072 : 7.7 ns / 11.7 ns 262144 : 9.0 ns / 13.1 ns 524288 : 10.6 ns / 14.8 ns 1048576 : 94.4 ns / 145.3 ns 2097152 : 139.0 ns / 186.9 ns 4194304 : 161.5 ns / 200.8 ns 8388608 : 172.7 ns / 205.8 ns 16777216 : 177.9 ns / 208.0 ns 33554432 : 180.3 ns / 209.1 ns 67108864 : 181.5 ns / 209.6 n 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:7.33%, 648 MHz:2.53%, 720 MHz:0.54%, 768 MHz:0.92%, 912 MHz:0.75%, 1.08 GHz:0.68%, 1.20 GHz:0.59%, 1.37 GHz:86.66% (3239)
  15. @lex

    NanoPi K1 Plus to be released soon

    Tweaked DTS, some other numbers: cryptsetup benchmark # Tests are approximate using memory only (no storage IO). PBKDF2-sha1 294543 iterations per second for 256-bit key PBKDF2-sha256 525865 iterations per second for 256-bit key PBKDF2-sha512 215578 iterations per second for 256-bit key PBKDF2-ripemd160 171335 iterations per second for 256-bit key PBKDF2-whirlpool 75328 iterations per second for 256-bit key argon2i 4 iterations, 229155 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time) argon2id 4 iterations, 231680 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time) # Algorithm | Key | Encryption | Decryption aes-cbc 128b 328.1 MiB/s 378.3 MiB/s serpent-cbc 128b 29.1 MiB/s 31.2 MiB/s twofish-cbc 128b 43.4 MiB/s 47.1 MiB/s aes-cbc 256b 287.6 MiB/s 351.6 MiB/s serpent-cbc 256b 29.1 MiB/s 31.2 MiB/s twofish-cbc 256b 43.4 MiB/s 47.1 MiB/s aes-xts 256b 344.4 MiB/s 345.0 MiB/s serpent-xts 256b 31.0 MiB/s 31.9 MiB/s twofish-xts 256b 47.7 MiB/s 48.4 MiB/s aes-xts 512b 321.7 MiB/s 322.3 MiB/s serpent-xts 512b 31.0 MiB/s 31.9 MiB/s twofish-xts 512b 47.6 MiB/s 48.4 MiB/s
  16. 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.
  17. hough

    nano pi k2 installing to usb

    not sure what you said just now but i did discover a problem totally unrelated i was missing d4 sod303. turns out zener diodes are important.
  18. Reddwarf

    ARMBIAN for Amlogic S905 and S905X

    Maybe stupid question but should I use the Mali-5 image(s) when my box has a Mali-450 GPU?
  19. 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.
  20. matt407

    matt407

  21. matt407

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

    Hi tkaiser, thank you for your reply. I'm a bit confused because I thought there is an 4.x Kernel currently the mainline kernel and version 4.14 is at test status? When I look at the download page, kernel version 3.14.79 is listed as unsupported? The reason for the version output is file /etc/armbian-release. I don't know if there is an impact on the armbian installation, if I change the version in this file? cat /etc/armbian-release # PLEASE DO NOT EDIT THIS FILE BOARD=odroidc2 BOARD_NAME="Odroid C2" BOARDFAMILY=odroidc2 VERSION=5.38 LINUXFAMILY=odroidc2 BRANCH=default ARCH=arm64 IMAGE_TYPE=stable BOARD_TYPE=conf INITRD_ARCH=arm64 KERNEL_IMAGE_TYPE=Image P.S. No problem, if the "issue" isn't fixed, if I understand the mechanism behind . In my personal opinion, it will not miss a motd like this on armbian - I like it!
  22. Igor

    ROCK64: RAM overclock possible?

    https://github.com/ayufan-rock64/linux-build/blob/master/recipes/overclocking.md
  23. It is one of the smallest board featuring H5 soc. Since it has an on-board HDMI connector, i think it would be great to have a Desktop image for this board. Other H5 /similar boards like PC2 and Prime already have various desktops available (xenial / stretch with xfce).... Do u guys have any plan to release one in the future? and thanks a lot for the tremendous amount of effort u have put into this project :)
  24. martinayotte

    Orange Pi Plus 2 (e?) - upgrade to "next" - failed

    If I remember, because my OPi+2E is currently unplugged in a box due to house moving, the eMMC was on /dev/mmcblk2. Try to simply boot from SDCard, then look at the result of "ls -l /dev/mmcblk*", then mount the eMMC with "mount /dev/mmcblk2p1 /mnt" and verify /mnt/etc/fstab, not the one of the SDCard.
  25. On legacy it was always first device - either SD or EMMC (if SD was not present). And yes - my fstab was referring directly to /dev/mmcblk0p1. I have updated it to correct UUID=... but still the same. BTW. My armbianEnv.txt is basically empty. It has only one line for DT user overlay (RTC). Any more suggestions? Meanwhile I will try to dump my EMMC onto SD card and try to boot from it.
  26. 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?
  1. Load more activity