zador.blood.stained

Moderators
  • Content count

    2777
  • Joined

  • Last visited

About zador.blood.stained

  • Rank
    Embedded member

Profile Information

  • Gender
    Male
  • Location
    $(pwd)

Recent Profile Visitors

1687 profile views
  1. Compile 32bit Armbian for aarch64 capable SoC

    And lower memory footprint (which may make sense for devices with only 512MiB RAM). Currently it's not possible to compile 32-bit images using the unmodified build script. Using 32-bit userland is easy - build an image for any 32-bit board and overwrite the kernel, u-boot and board support package. Compiling a 32-bit kernel is harder and I'm not sure how it should be done exactly (what ARCH, CROSS_COMPILE and defconfig combination should be used). AFAIK you also need to patch the ATF to start a 32-bit kernel instead of 64-bit, and u-boot will still be 64-bit in any case.
  2. Trying to boot NanoPi-K2

    You mean something like this? https://lists.denx.de/pipermail/u-boot/2017-May/291439.html Since it's a new device we can experiment all we want (compared to XU4 where unfortunately we already have mainline based images marked as "stable" with the legacy u-boot). Also since I don't see mainline images for C2 marked as "stable" we can probably use the mainline u-boot for C2 next/dev branches too.
  3. ROCK64

    I would recommend to kill the test and turn it off immediately. There is no DVFS or THS in 4.11 branch that we are using for H5, so the board may literally bake itself to death without even trying to throttle.
  4. Trying to boot NanoPi-K2

    And since it is S905 based it may be possible to rely on pure mainline u-boot using Odroid C2 config with some patches. http://git.denx.de/?p=u-boot.git;a=blob;f=board/amlogic/odroid-c2/README;h=b407c049526c334b983b5397c752c6486832746c;hb=HEAD
  5. Trying to boot NanoPi-K2

    Yes, and most likely find/grab a proper Device Tree file or point the u-boot to the proper one.
  6. Trying to boot NanoPi-K2

    AFAIK most Amlogic devices supported by @balbes150 are TV boxes with eMMC storage and on Amlogic devices eMMC has higher boot priority compared to SD. So most likely those images don't have u-boot at all and rely on stock u-boot in eMMC. You can try comparing official FriendlyELEC images and these images in a hex editor.
  7. Battery management via AXP209 (Banana Pi/Pro)

    No, and it wasn't intended to be included in the mainline. From its README At the time it was created it was the simplest way to get data from the PMIC or change some settings without using userspace tools like i2cget/i2cset or a custom code based on i2c libraries. Newer kernels have received proper drivers - starting with 4.12 there is even a battery driver and an ADC IIO driver, but this patch still can be useful i.e. to enable/disable RTC battery changing on some boards. I don't mind, but it has to be noted that it's more a hack than a proper solution (since it doesn't integrate in any existing system like hwmon, iio, power supply, etc.) and it has very limited usefulness without extra documentation.
  8. ROCK64

    I'm not sure if the DRAM throughput affects the results in addition to the CPU clock speed (especially in multithreaded/multiprocess scenarios) so I'm not sure if we should push our benchmarking attempts in this direction. In addition I believe I already erased the card I used for tests, so I'll postpone them for now. IMO storage benchmarks on different boards when using LUKS/cryptsetup with AES encryption would be a more real world scenario and we could see how disk encryption affects the usual NAS performance on, for example, XU4, Rock64, Clearfog (with the mainline kernel) and something like OPi Plus2E.
  9. UAS + mainline kernel + coherent-pool memory size

    It should be SZ_2M instead of SZ_2048K - the latter is not a predefined constant.
  10. ROCK64

    AFAIK it doesn't have ARM crypto extensions so that should be the main reason for lower performance.
  11. armbian-config

    Also a feature request, IMO it is worth adding a feature to tweak the "AllowRootLogin" option in /etc/ssh/sshd_config with 3 possible options - Allow password and public key, allow public key only and disallow everything. This may need release-specific logic, sshd_config man page has to be checked on each release.
  12. armbian-config

    First things that come to mind: - "networking" submenu with options like WiFI, Hotspot, NetworkManager (just to call nmtui), etc. - "software" submenu for Softy, USB redirector, installing a desktop environment, installing headers, etc. - "tweaks" submenu for things like editing armbianEnv.txt, changing timezone, changing locale, etc. Alternatively 2 submenus instead - "system settings" for locale, timezone and other generic Debian/Ubuntu stuff and "tweaks" for Armbian-specific stuff (overlays, MOTD, loglevel) Also current "debian-config" is 70 lines short from being a 1000 lines long. At this point it could use a refactoring, at least splitting stuff into functions and splitting functions into different files.
  13. ROCK64

    It's most likely "benchmarking gone wrong". -evp here applies only to the next algo on the command line (aes-128-cbc), 2 next ones are not affected by this option. So I would advise to rerun the test 3 times, 1 algo at a time, and edit/post a combined table. openssl speed -elapsed -evp aes-128-cbc openssl speed -elapsed -evp aes-192-cbc openssl speed -elapsed -evp aes-256-cbc
  14. BPI-M3 build

    The most developed mainline kernel. There is also a BSP/vendors kernel that may have better support for some hardware features, but nobody except for the vendor is interested in it, especially for less popular devices such as M3.
  15. Kernel -rcX : Last version issues

    (A little bit off-topic) Because it's a release candidate kernel, and moreover it's not an LTS kernel. For example even in stable 4.12 LIRC was completely broken, and then in 4.12.5 to 4.12.6 changelog I've found this (fix). Stuff like this makes you rethink tying the Armbian releases to mainline releases.