tkaiser

Members
  • Content Count

    5402
  • Joined

  • Last visited

About tkaiser

  • Rank
    Embedded member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

16085 profile views
  1. What should change as long as you keep 'Armbian' your personal project?
  2. Great way to communicate project details. I guess this (keeping this whole thing your private pet) is key to success.
  3. @Igor certificate for www.armbian.com expired. @Tido good luck with this sort of poll (no idea why contents of the 'board details' page is now part of download page -- but you might start similar polls for two other totally uninteresting boards: ODROID-C2 and C1)
  4. If you don't provide information what's utilizing the CPU how should anyone here help you or at least get an idea what's going on? Check and provide 'htop' and 'armbianmonitor -u' output.
  5. tkaiser

    NanoPi M4 performance and consumption review

    Depends. Though in all my tests blowing air laterally performed best (see here or here). With NanoPi M4 just some airflow through the heatsink fins is already sufficient (tested it behind a server PSU's 'hot air' outlet). But of course you can easily conduct your own tests. Simply use sbc-bench's thermal testing mode and if you want to adjust your fan setup interactively then use the installed cpuminer application in /usr/local/src/ (but please keep in mind that with the huge thermal mass of NanoPi M4's heatsink it's very easy too fool yourself and that's why I would always recommend a combined sbc-bench -t/-T test run) I recommended the 88SE9235 for a reason and @mindee said they would use this chip. I hope you're aware that there exist RK3399 boards with full PCIe slots already? PCIe functionality is only a kernel thing (drivers and device-tree settings) and a board design issue (PCB trace lengths/routing and signal quality)
  6. tkaiser

    Benchmarking CPUs

    100% meaningless numbers now since they do not provide any insights any more (you can not differentiate what's throttling and what's -- potentially inappropriate -- cpufreq scaling behavior). For two simple reasons: allowing very low cpufreq OPP trashes performance (on your Tinkerboard it's storage performance due to the clockspeeds not increasing fast enough) the way DVFS works at the lower end of the scale the differences in consumption and generated heat are negligible between silly ultra low MHz values and a reasonable lower limit (we in Armbian TEST for stuff like this with every new SoC family!) Closed your issue right now spending additional time to explain: https://github.com/ThomasKaiser/sbc-bench/issues/4
  7. tkaiser

    NanoPi NEO4

    When I did some tests with the RTL8153 on ODROID HC1 the consumption increase caused by the chip alone was always below 1W.
  8. tkaiser

    zram vs swap

    Read the script and don't just skim through. This script (initially written by Igor and not me -- there's also a commit history which helps you understand what stuff is dealt with here) sets up things that need to work on any of the kernels Armbian supports (we're not just dealing with the few devices you seem to use) and does a couple of different stuff. Of course we're not using filesystems for swap and you might even look into the Changelog to understand why mkfs.ext4 is used there.. @Igor certificate for docs.armbian.com has expired
  9. tkaiser

    Pi-factor cases

    Sure, feel free to create an 'USB-C powered boards -- important information' thread or something like that. If those cables were not 30$ and the cheap fakes destroyed the phone.  How is that different with USB-C? See https://www.makeuseof.com/tag/best-usb-c-chargers-whats-safe-whats-dangerous/ or https://www.theverge.com/2016/2/4/10916264/usb-c-russian-roulette-power-cords for example.
  10. Count the patches and search for NEO2 there: https://github.com/armbian/build/tree/master/patch/kernel/sunxi-next
  11. tkaiser

    Pi-factor cases

    They're there already: Firefly RK3399, Vim, Vim2, RockPro64, NanoPC-T4, NanoPi M4, Ficus, Renegade Elite and soon also NanoPi NEO4, Khadas Edge and Edge-V are equipped with USB-C. Some of these boards use USB-C as power input. Here we need to differentiate between 'dumb mode' and 'USB PD compliant' (USB PD --> USB Power delivery specs): With the boards that use just an USB-C receptacle to be fed with 5V (Vim, Vim2, NanoPi M4, NanoPi NEO4) problems are to be expected since real USB-C chargers won't provide enough current (here me citing the specs) and dumb 5V PSUs combined with high currents result in the usual voltage drop With boards that implement USB-C powering also being USB PD compliant you need an extremely expensive USB-C charger So as long as there are not real USB-C chargers lying around in every household and all SBC are USB PD compliant USB-C for powering SBC is simply either a mess or an expensive adventure. You're talking about some Apple smartphones and tablets still using their Lightning connector and not USB-C? Most probably related to the count of peripherals that already use Lightning (Docking Stations and stuff like that). Apple was the company pushing hard for USB market adoption 20 years ago (giving up on their own proprietary ADB bus standard which resulted in a lot of users like me having to buy adapters for expensive ADB peripherals like graphics tablets and such stuff) and they also sent truckloads of engineers to USB Implementers Forum years ago when USB-C and USB PD were defined. Most probably to prevent USB-IF ever doing something silly as Micro USB again (so that they had to invent something own as Lightning since Micro USB already sucked back then).
  12. tkaiser

    Quick Review of Rock960 Enterprise Edition AKA Ficus

    Isn't it the same with the normal Rock960? To me personally not a single 96boards specs compliant device looked appealing (unfortunately Ficus included). But it's the 'standard' itself that's the problem. Form factor, placement of connectors, interfaces exposed. The PCIe connector placement on EE boards is simply moronic. But maybe I understood the whole 96boards approach wrong and this was never meant for end users but just for Android developers?
  13. tkaiser

    NanoPI M4

    'Like all the other boards' is not true since Allwinner boards for example can be flashed using FEL mode (directly accessing the board's eMMC as USB storage). If you have an eMMC to SD card adapter you can burn an Armbian image directly to eMMC, if not it's just calling nand-sata-install and you're done.
  14. tkaiser

    NanoPI M4

    Sure. Just read the review.
  15. tkaiser

    Quick Review of Rock960 Enterprise Edition AKA Ficus

    Almost forgot: in case someone wants to add this device to Armbian as CSC (community supported config -- for official support a 'Board Bring-Up' thread/discussion is needed). I would believe starting with a ficus.csc like this would be a good idea: # RK3399 hexa core 1-4GB GBE eMMC USB3 USB-C WiFi PCIe BOARD_NAME="Ficus" BOARDFAMILY="rk3399" BOOTCONFIG="nanopi4_defconfig" # MODULES="" MODULES_NEXT="" # KERNEL_TARGET="default,dev" CLI_TARGET="stretch:default" DESKTOP_TARGET="bionic:default" CLI_BETA_TARGET="" DESKTOP_BETA_TARGET="" Then adding the 4.4 DT as u-boot and default kernel patch, the mainline DT as dev kernel patch and loading the specific DT similar to how we do it already. Open question: how to deal with rk3399_loader_v1.12.112.bin?