Jump to content

tkaiser

Members
  • Posts

    5462
  • Joined

Reputation Activity

  1. Like
    tkaiser got a reaction from arox in What about Google Home   
    We're not talking about a development board that makes accessing the hardware and especially the boot process easy but a rather expensive surveillance device people buy for whatever bizarre reasons. The technical details are so f*cking boring that everyone who disassembles the spy tool to get access to this boring PCB IMO must be mad.  
     
    If someone wants to waste a lot of time please contribute to Armbian in a more sensible way instead of wasting your time on hardware not worth a look with a target audience (for Linux on this thing) that does not exist.
     
  2. Like
    tkaiser got a reaction from Tido in Burn ISO Image to Micro SD Card   
    Does this tool always verify burning results?
     
     
    Does this tool always verify burning results?
     
     
    Does this tool always verify burning results?
     
    We had an awful lot of absolutely unnecessary support requests 2 years ago with users failing to burn images correctly (since SD cards were broken or card readers or whatever). When starting to only recommend Etcher this amount of absolutely unnecessary support requests declined drastically.
     
    A burning tool that does no verify is a nightmare from a support point of view since unfortunately the average user doesn't get it that a lot of stuff can go wrong when burning SD cards. This problem is the whole reason why resin.io folks developed Etcher in the first place.
     
    Recommending any burning tool that does NOT a verify the result by default is a really bad idea.
  3. Like
    tkaiser reacted to Sergey Zinchenko in Tinkerboard rk3288 iptables CT target problem, NETFILTER_XT_TARGET_ST not set   
    I have made pull request with the module required. I also added number of modules for iotop utility too you know.
    Thank you!
  4. Like
    tkaiser got a reaction from gounthar in What about Google Home   
    The Armada 1500 family consists of totally different SoCs, the '1500 Mini Plus' is pretty uninteresting, the whole business unit is now part of Synaptics who locked everything away and this is the status of upstream support: https://github.com/torvalds/linux/tree/master/arch/arm/mach-berlin
     
    Good luck.
  5. Like
    tkaiser got a reaction from Tido in Banana Pi M3   
    Sure, 'the Allwinner syndrome'. Once the SoC is EOL and can not be purchased any more the brave souls over at linux-sunxi finished mainline kernel support. Situation 3-4 years ago was different but today I really have no clue why to waste a single second on anything Allwinner that is not also cheap as hell (talking about the small OPi and NanoPi boards) or makes good use of Allwinner's battery support (PineBook, Olimex' Teres, Olimex Lime/Lime2 boards that use the battery to provide full 'UPS functionality' since also powering USB and SATA devices via step up converters)
     
    Banana Pi M3 with its outdated 32-bit Cortex-A7 little cores and the totally unsupported PowerVR GPU is even more expensive than faster little.LITTLE designs like NanoPi Fire3 or even true big.LITTLE designs like ODROID XU4/HC1/HC2 (the latter also with an USB-to-SATA bridge but USB3 based and more than 25 times faster than the crappy GL830 on the M3).
  6. Like
    tkaiser got a reaction from chwe in Librecomputer Renegade RK3328   
    The latter. That's the main difference between @ayufan's attempt and mine. And no, haven't had a look at the patch failures and am currently away from any build host... or to be more precise from the SSD carrying the VM and all the cached stuff:


  7. Like
    tkaiser reacted to TonyMac32 in NanoPI M4   
    Well, if the manufacturing is done intelligently, the tailings get recycled nicely.  You could argue the energy involved in it, but I'd probably counter the cast ones use far more energy than simply machining out of large blocks.  In general aluminum and steel are quite "eco" compared to any plastic, and certainly better than say copper as far as mining/refining are concerned.  (off topic, but interesting)
  8. Like
    tkaiser got a reaction from JMCC in Librecomputer Renegade RK3328   
    I would prefer 'speaking' names so renegade is IMO better than roc-???-cc. Soon there will be a "Renegade Elite" available based on RK3399... and renegade-rk3328 and renegade-rk3399 look almost the same. So maybe calling this now just renegade and the RK3399 board then renegade-elite?
  9. Like
    tkaiser got a reaction from TonyMac32 in Librecomputer Renegade RK3328   
    I would prefer 'speaking' names so renegade is IMO better than roc-???-cc. Soon there will be a "Renegade Elite" available based on RK3399... and renegade-rk3328 and renegade-rk3399 look almost the same. So maybe calling this now just renegade and the RK3399 board then renegade-elite?
  10. Like
    tkaiser reacted to Da Xue in ROC-RK3399-PC (Renegade Elite)   
    There's no plans for full size PCI-E cards because that is like Pandora's box in terms of customer issues. If 20V works, we could potentially design a mezzanine to drive PoE devices and act as a terminator for PoE camera system for computer vision applications.
  11. Like
    tkaiser got a reaction from WarHawk_AVG in Clone/backup bootable microsd card - make as small as possible image   
    By default Pishrink will even resize the image to the maximum (which is IMO not the best strategy) at next boot: https://github.com/Drewsif/PiShrink/blob/8aae06a4b20b1638237e4a5442a26ebb3fe6a3b1/pishrink.sh#L11 (you need to call the script with -s to skip auto resize at next boot). Disclaimer: I've neither used the script before nor know how good it copes with all partitioning schemes Armbian supports (when it's targeting the Raspberry Pi then the script's assumption will be '1 FAT partition followed by 1 ext4 partition' while with Armbian it's completely different)
     
    In Armbian we do the resize never to full capacity but 'waste' 5% on SD cards of 4GB in size (or smaller), 2% with up to 8 GB and 1% above. The reason is to allow people to clone cards to another one 'of same size' (but two cards 'of same size' from different manufacturers never have the same capacity but differ slightly) and to help old/crappy cards with wear leveling (that's the 'leave a 5% spare area on old/small SD cards' rule explained above).
     
    BTW: The above commands also work after shutting down the board. Simply execute them followed by a reboot and you're done.
     
    BTW 2: All occurrences of resize2fs here in the forum are soon worthless since the service will be called armbian-resize-filesystem in the future. Same with firstrun which will be called armbian-firstrun. Of course all of this is stuff for our documentation but for whatever reasons contributions to Armbian are only declining...
  12. Like
    tkaiser got a reaction from WarHawk_AVG in h3consumption to be included into future Armbian releases   
    Different location now: https://github.com/armbian/build/blob/master/packages/bsp/h3consumption
     
     
    It's possible to decompile/manipulate/recompile DT files but at least I do not plan on porting the tool to mainline. With mainline you better go with DT overlays and the stuff many people are interested in (limit count of CPU cores and networking options) is done in /etc/rc.local anyway. And some stuff like changing DRAM clock speed simply doesn't work with mainline at all.
  13. Like
    tkaiser got a reaction from WarHawk_AVG in Burn ISO Image to Micro SD Card   
    Does this tool always verify burning results?
     
     
    Does this tool always verify burning results?
     
     
    Does this tool always verify burning results?
     
    We had an awful lot of absolutely unnecessary support requests 2 years ago with users failing to burn images correctly (since SD cards were broken or card readers or whatever). When starting to only recommend Etcher this amount of absolutely unnecessary support requests declined drastically.
     
    A burning tool that does no verify is a nightmare from a support point of view since unfortunately the average user doesn't get it that a lot of stuff can go wrong when burning SD cards. This problem is the whole reason why resin.io folks developed Etcher in the first place.
     
    Recommending any burning tool that does NOT a verify the result by default is a really bad idea.
  14. Like
    tkaiser reacted to Da Xue in ROC-RK3399-PC (Renegade Elite)   
    Native *speed*. Thanks for the catch. 5V and 12V works. Still trying to get 20V working.
  15. Like
    tkaiser got a reaction from chwe in ODROID N1 -- not a review (yet)   
    Today nobody (outside Hardkernel) knows for sure whether they use S922 (other SoC vendors like HiSilicon exist also) and nobody (outside Amlogic) knows for sure which CPU cores are inside S922
  16. Like
    tkaiser got a reaction from Da Xue in ROCK64: RAM overclock possible?   
    Care to report the instabilities you will now run into (before others find this thread and think this would be a great idea)?
     
    You could start with https://github.com/ehoutsma/StabilityTester but would need to adjust both MAXFREQUENCY and the REGULATOR_* variables first.
  17. Like
    tkaiser reacted to JMCC in NanoPC T4   
    Well, let's take a break from important decision-making, and post some benchmarks about VPU/GPU. I have used the official FriendlyELEC's Ubuntu Xenial image, kernel 4.4.126, 32-bit architecture. That allowed me to easily create a media configuration script, based on the existing RK3288 one. All tests were done with "performance" governor, both in CPU and GPU.
     
    The 32-bit script can be downloaded here. It is not yet a release version, so there may be some rough edges. If the community demands it, I might create a 64-bit version in the future.
     
    1. VPU 4K Video Decoding capabilities
    I'll make a chart comparing NanoPC-T4 (RK3399) with ASUS TinkerBoard (RK3328) and Khadas VIM2 (Amlogic S912). Rockchips acceleration was tested with our well-known MPV, while for Amlogic we used @balbes150's LibreElec:
    BOARD H.264 HEVC VP9 HEVC-10 VP9-10 ------------------------------------------------------ TB (RK3288) ✓ ✓ x x x T4 (RK3399) ✓ ✓ ✓ ✓ x VIM2 (S912) ✓ ✓ ✓ ✓ ✓ The first thing to comment here is that VP9 10-bit HDR video playback is not supported by the board, which on the other hand is in accordance with Rockchip's official specs. HDR is only supported for H.264 and H.265 (we didn't test the former, though, but we can assume it works if the latter does). It should not be a software issue, since we tested also in Android with the Rockchip Media Player App, and we only got a messagebox saying "10-bit video is not supported". So, in this aspect, RK3399 is inferior to the competitor's S912, which can play VP9-HDR10 videos.
     
    Besides that, all supported videos played with perfect smoothness and vivid colors.
     
    2. GPU OpenGL-ES & WebGL
    Time for 3D capabilities of the Mali-T860 with 4 cores @800 Mhz. As references for the comparison, we chose this time the TinkerBoard (Mali-T760, 4 cores@600), and the Odroid XU4 (Mali-T628, 6 cores@600). All three malis share the Midgard architecture, though they represent the first, second and third generation. We didn't use this time the S912, because it has no Linux Mali support, plus performance would be much lower with only 3 cores. Kernel for TB is Armbian's 4.4.131-rockchip, while for XU4 is 4.14.30. For the Rockchips we used their custom X server with Glamor enabled, while for XU4 we used Crashoverride's armsoc X driver:
    Results are in frames per second:
    BOARD Glmark2-X Glmark2-offscreen WebGL Aquarium (Chromium) ----------------------------------------------------------------------------------------- TB (RK3288) 57 547 30-34 T4 (RK3399) 52 340 33-36 XU4 (S5422) 428 747 39-44 In the first place, Rockchip's X server seems to be better tuned for the RK3288, where we see that FPS almost match the Vsync (60 FPS). In the case of RK3399, we see it is significantly lower, while we also see tearing that does not happen with the other Rockchip SoC. XU4's driver works in a different way, and so it is not limited by Vsync, but nevertheless it doesn't show any tearing.
    Offscreen performance is strangely low in RK3399 (probably a matter of a not-so-well tuned Mali binary?). WebGL performs better in 3399 than 3288, but the difference is not as big as one should expect considering the superiority of both CPU and GPU. XU4 clearly sticks from the others.
     
    3. GPU OpenCL performance
    Now OpenCL performance with GPU miners. That can give us a better idea of the raw processing power of the GPU since there are no X drivers getting in the way. We used cgminer for the skein algo, and sgminer for lyra2rev2. Results are averages from running the miner for two hours, with an intensity as high as possible monitoring that no hardware errors happened.
    BOARD Skein (Mh/s) Lyra2rev2 (Kh/s) ------------------------------------------------ TB (RK3288) 1.150 42 T4 (RK3399) 1.150 60 XU4 (S5422) 1.440 72 It is shocking that performance in Skein algo is about the same for RK3288 and RK3399, but using CPU miners for the same algorithm the TinkerBoard  also gives surprisingly high numbers (higher than XU4). For that reason, I think there must be something in the TB that makes it specially suited for Skein (maybe the dual-channel RAM?), so results must be taken carefully. On the other hand, Lyra2 numbers are more or less as expected.
     
     
    Remember that all these tests are made in a armhf system. Maybe arm64 can give us some surprise in the future. Or maybe Rockchip can make improvements to their binaries/libraries giving better performance.
  18. Like
    tkaiser reacted to TonyMac32 in NanoPC T4   
    @JMCC Nice review, I still need to get my system running... :'(  
     
    @tkaiser, there is very little "special" with the rk3288 boards we support, the Tinker patches have been carefully (well, as carefully as I can manage) tailored to not harm the operation of other boards (the Tinker Reboot is a nasty one, it's hackish code that I wrapped with a device tree check conditional execution).  The MiQi is basically just a Rockchip development board, nothing strange to get in the way. 
     
    I would support a common BSP kernel for all the devices, for Mainline though I would recommend using straight official mainline and grab patches for the important things from the "almost mainline" or "will wind up in mainline" repos (easy for me to say when the RK3288 is almost perfectly supported at this point).
     
     
  19. Like
    tkaiser reacted to JMCC in NanoPC T4   
    Definitely. After your remarks, I think Ayufan's is the best option, for the following reasons:
    After @kevery's clarifications, it seems like RK upstream aims at a purpose that does not fit Armbian's needs. Hardkernel's is dead ATM, and we have no clue what N2 will be like (maybe not even Rockchip). Firefly's and FriendlyELEC's can end up being similar to ASUS, where they choose to stay with an older version of the kernel/drivers and patch them. Not what Armbian does normally. Ayufan's main difficulty is that, being driven by a single person, the project could die if for any reason he cannot take care of it any more. But being open to external contributions somehow prevents that situation, since there would be more people closely familiar with the source tree who could be able to continue the work. And also, since his work and Armbian's is so close (we are already using his kernel for RK3328), transition would be relatively easy. The only drawback could be that @TonyMac32 would need to check all his patches against that kernel (it currently does not support RK3288), but I think that would be a piece of cake compared to what he is doing now trying to put order in RK's upstream kernel.
  20. Like
    tkaiser reacted to wtarreau in Amlogic still cheating with clockspeeds   
    This is exactly why there are people like us who dissect products and push them to their limits so that end users don't have to rely on marketing nor salesmen but on real numbers reliably measured by third party who don't have any interest in cheating.
     
    Regarding your point about Tj and lifetime, you're totally right, and in general it's not a problem for people who overclock because if they want to get a bit more speed they won't keep the device for too long once it's obsolete.
    Look at my build farm made out of MiQi boards (RK3288). The Rockchip kernel by default limits the frequency to 1.6 GHz (thus the Tinker board is likely limited to this as well). But the CPU is designed for 1.8. In the end, with a large enough heat sink and with throttling limits pushed further, it runs perfectly well at 2.0 GHz. For a build farm, this 25% frequency increase directly results in 25% lower build time. Do I care about the shortened lifetime ? Not at all. Even if a board dies, the remaining ones are faster together than all of them at stock frequency. And these boards will be rendered obsolete long before they die.
     
    I remember a friend, when I was a kid, telling me about an Intel article explaining that their CPU's lifetime are halved for every 10 degrees Celsius above 80 or so, and based on this I shouldn't overclock my Cyrix 133 MHz CPU to 150. I replied "because you imagine that I expect to keep using that power-hungry Cyrix for 50 years? For me it's more important that my audio processing experimentation can run in real time than protecting my CPU and having to perform them offline".
     
    However it's important that we are very clear about the fact that this has to be a choice. You definitely don't want companies to build products that will end up in sensitive domains and expected to run for over a decade using these unsafe limits. On the other hand, the experiments run by a few of us help figuring available margins and optimal heat dissipation, both of which play an important role in long term stability designs.
  21. Like
    tkaiser reacted to kevery in NanoPC T4   
    I'm Kever Yang from Rockchip BSP team, and I'm in charge of open source for Rockchip SoCs, you should able to see my patches to upstream U-Boot and kernel. Thanks very much to @tkaiser for share this thread to me, and I hope I can do some explanation here so that help developers understand what we are doing.
     
    The github(https://github.com/rockchip-linux/) is owned by Rockchip,  and repos on github consider to be a 'Linux SDK' of some of Rockchip SoCs(mainly for RK3328, RK3288, RK3399 now), we have a wiki to provide basic document for it(http://opensource.rock-chips.com/), the github is now maintained by one of our product team. We hope this github can be a good reference to developers who interested in Rockchip platform.
     
    I have to declare that Rockchip never try to stop community developers to report issue to Rockchip by github or by mail, but it's not correct to close issues without any comments, I'm sorry about what we have done and I promise it would never happen again. For some issues, we may not able to fix it, but people should get a saying if we have to close it. Rockchip always open to community, and, yes, we hope to get advice about github maintain.
     
    Here is the information about Rockchip source code:
    - Rockchip have only one common BSP maintained by BSP team, including U-Boot, kernel, rkbin(ddr, miniloader, trust), this is used in all Rockchip products and for many SoCs, so it including 4.4 base/LTS patches, upstream backport for some modules, vendor/rockchip solution for some modules because the requirement for production;
    - Rockchip product team will test for product SDK release, but usually only for one SoC per SDK, and it will fix at that point before next version SDK. 
    - Rockchip kernel is now 4.4, and will update to next LTS;    
      We try to use upstream source code as much as possible for all the modules, you can find this out by compare to our last version kernel 3.10, but still way to go.
    - Rockchip kernel is used for Android and Linux OS;
    - Github source code is a special 'Linux SDK', not like other 'fixed after release for one SoC' SDK, it keeps update and used for more than one SoCs, you can consider it to be a mirror of Rockchip internal BSP
         * that's why we not able to merge the pull request, we have to review all the source code internally;
         * the github release branch is  not maintained directly by BSP team, so it may not have maintained good enough now, I will sync with the maintainer, we will have better test, and better release flow;
    - Rockchip don't have official community version BSP which only have everything from upstream, and won't going to have one in near future;
    - Issue report(feature defeat, performance and etc) are always welcome, we want provide a better common kernel.
        We will fix issues really need to fix, people don't want to get a kernel always have the same issue.
    - We focus on evb first for new SoCs, and some popular board will add later; this may be one of the conflict with the what community wants.
     
        About the common kernel for community, here is my suggestion:
    - Community can chose one kernel version fork from Rockchip as common kernel, now the kernel4.4 already has good support for RK3288/RK3399/RK3328;
    - Developing, apply patches for new board support, switch some of module to upstream driver, and so on;
    - Upstream the new board support or feature support as much as you can, then rockchip kernel can support it when update to new kernel;
    - If some feature/performance issue need to fix recently, community people can contact Rockchip/me, we will try to fix it if we can;
    - maybe a mailing list is needed for better communication?
  22. Like
    tkaiser got a reaction from ykchavan in OPI PC+ not booting   
    You need another Linux system and a card reader. Attach the card reader with SD card inserted, check output of
    lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT,UUID Then you need to mount the 1st partition of the SD card and edit /mnt/boot/ArmbianEnv.txt and adjust there the line reading
    rootdev=UUID=e59363f1-765c-4660-9275-4563bb872371 and replace the part after 'UUID=' with what lsblk showed for partition of your SD card.
     
    The above example assumed that you mounted the partition to /mnt, if that differs you need to edit still the respective file (/boot/ArmbianEnv.txt on the SD card's 1st partition)
  23. Like
    tkaiser got a reaction from Moklev in WE NEED !YOUR! HELP   
    Just for the record: this package (a simple script in reality) installs and works pretty well in Debian too so it should be purged anywhere as part of an upgrade mechanism.
  24. Like
    tkaiser got a reaction from Moklev in [DEPRECATED] zRAM in Armbian Stretch (mainline 4.14.yy)   
    Not only you tested it but thousands of OpenMediaVault users (the majority on the Raspberry Pi) since I did exactly the same in our OMV images for ARM boards.
     
    But this is not the recommended way any more, lz4 for whatever reasons performs not greater than lzo but it would be great if you can join testing efforts.
     
  25. Like
    tkaiser got a reaction from firepower in NanoPC T4   
    This is something hopefully suitable to become a 'Board Bring up' thread.
     
    The NanoPC T4 was the smallest RK3399 board around featuring full set of interfaces (Rock960 was smaller but there you can't use GbE without a proprietary expander) but in the meantime he got two smaller siblings: NanoPi M4 and the cute NEO4.
     
    Pros:
    Another RK3399 board so software support is already pretty mature Rich set of interfaces (2 x USB2 without shared bandwidth, 2 x USB3, triple display output and so on) No powering hassles due to 12V (2A) PSU requirement 16GB superfast eMMC 5.1  Usable and performant Wi-Fi (dual band and dual antenna so MIMO can be used, for numbers see here) All 4 PCIe lanes exposed (M.2 M key connector on the bottom, suitable for NVMe SSDs, or to attach a 4 port SATA controller or a PCIe riser card)  
    Cons:
    A bit pricey (but if you compare with RockPro64 for example and order all Add-Ons you end up with a similar price) High idle consumption (4W PSU included in idle), maybe this is just bad settings we can improve over time heatsink too small for continous loads  
    I started relying on @hjc's work since he's currently using different kernels than we use on RockPro64 or ODROID-N1 (though all the 4.4 kernels are more or less just RK's 4.4 LTS branch with some modifications, with mainline I didn't had a look what's different in Heiko's tree and 'true' mainline).
     
    Tinymembench numbers with RK 4.4 vs. mainline kernel (the latter both showing lower latency and higher bandwidth).
     
    Internal 16 GB eMMC performance:
    eMMC / ext4 / iozone random random kB reclen write rewrite read reread read write 102400 4 23400 28554 26356 26143 27061 29546 102400 16 48364 48810 85421 85847 84017 47607 102400 512 48789 49075 273380 275699 258495 47858 102400 1024 48939 49053 290198 291462 270699 48099 102400 16384 48673 49050 295690 295705 294706 48966 1024000 16384 49243 49238 298010 298443 299018 49255 That's what's to be expected with 16 GB and exactly same numbers as I generated on ODROID-N1 with 16 GB size. When checking SD card performance it maxed out at 23.5 MB/s which is an indication that no higher speed modes are enabled (and according to schematics not possible since not able to switch to 1.8V here -- I didn't try to adjust DT like with ODROID-N1 where SDR104 mode is possible which led to some nice speed improvements when using a fast card -- see here and there)
     
    Quick USB3 performance test via the USB-3A port:
    Rockchip 4.4.132 random random kB reclen write rewrite read reread read write 102400 4 24818 29815 33896 34016 24308 28656 102400 16 79104 90640 107607 108892 80643 89896 102400 512 286583 288045 285021 293431 285016 298604 102400 1024 315033 322207 320545 330923 320888 327650 102400 16384 358314 353818 371869 384292 383404 354743 1024000 16384 378748 381709 383865 384704 384113 381574 mmind 4.17.0-rc6-firefly random random kB reclen write rewrite read reread read write 102400 4 37532 42871 22224 21533 21483 39841 102400 16 86016 104508 87895 87253 84424 102194 102400 512 274257 294262 287394 296589 287757 304003 102400 1024 294051 312527 317703 323938 323353 325371 102400 16384 296354 340272 336480 352221 339591 340985 1024000 16384 367949 189404 328094 330342 328136 139675 This was with an ASM1153 enclosure which shows slightly lower numbers than my usual JMS567 (all currently busy with other stuff). Performance with RK 4.4 kernel as expected, with mainline lower for whatever reasons. I also tried to test with my VIA VL716 enclosure directly attached to the USB-C port but ran into similar issues as with RockPro64 but since my enclosure and the cable also show problems when using at a MacBook Pro I suspect I should blame the hardware here and not USB-C PHY problems with RK3399.
     
    This is NanoPC T4 with vendor's heatsink, lying flat on a surface that allows for some airflow below, running cpuburn-a53 on all 6 cores after half an hour:
    13:57:31: 1008/1416MHz 8.44 100% 0% 99% 0% 0% 0% 91.1°C 0/5 13:57:40: 1008/1416MHz 8.52 100% 0% 99% 0% 0% 0% 91.1°C 0/5 13:57:48: 1008/1416MHz 8.51 100% 0% 99% 0% 0% 0% 91.1°C 0/5 13:57:57: 1200/1416MHz 8.47 100% 0% 99% 0% 0% 0% 90.6°C 0/5 13:58:05: 1200/1416MHz 8.47 100% 0% 99% 0% 0% 0% 91.1°C 0/5 So with heavy workloads you most probably need a fan to prevent throttling. 
     
    Development related questions: IMO we should try to rely on single sources for all the various RK3399 boards that are now available or will be soon. And I would prefer ayufan's since he's somewhat in contact with RK guys and there's a lot of great information/feeback provided by TL Lim. What do others think?
     
    Also an issue is IRQ affinity since on boards where PCIe is in use those interrupts should clearly end up on one of the big cores while on other boards USB3 and network IRQs are better candidates. I already talked about this with @Xalius ages ago and most probably the best idea is to switch from static IRQ affinity set at boot by armbian-hardware-optimization to a daemon that analyzes IRQ situation every minute and adopts then dynamically the best strategy.
     
    Wrt information for endusers. All RK3399 boards basically behave the same since the relevant stuff is inside the SoC. There's only different DRAM (matters with regard to consumption and performance), different interfaces exposed and different power circuitry (and obviously different settings like e.g. cpufreq behaviour but I think we should consolidate those for all RK3399 boards). So you already find a lot of information in my ODROID-N1 'review', my SBC storage performance overview and most probably also a lot around RockPro64. No idea where to inform about RK3399 GPU/VPU stuff since not interested in these areas at all (hope others add references or direct information).
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines