tkaiser

  • Posts

    5445
  • Joined

Reputation Activity

  1. Like
    tkaiser reacted to jeanrhum in sbc-bench   
    Hi,
     
    I saw you tested your Up board based on atom z8300, so I tested my x5 based on z8350: http://ix.io/1lwg
    However, I have only manjaro installed on it and cpufreq is not reported, nor the soc temperature, so maybe this numbers are not relevant for you.
     
  2. Like
    tkaiser reacted to hjc in NanoPI M4   
    M4 (4.4 armbian nightly kernel) w/ the official huge heatsink attached: http://ix.io/1lvP
    Ambient temperature is ~29℃
    I'll write a full review this weekend.
  3. 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).
  4. Like
    tkaiser reacted to hjc in Firefly RK3399 support efforts (potential csc board?)   
    @tkaiser I've managed to boot 4.18 kernel on Firefly RK3399 (those problems on 4.17 seems gone), and ran sbc-bench after editing the dts in the same way (set trip point to 85℃, OC to 2.2/1.8GHz), results are here: http://ix.io/1lmN.
  5. Like
    tkaiser got a reaction from Igor_K in UP Board performance compared to ARM   
    Just to have some sort of comparison to x86 based SBC I benchmarked my UP Board (lying in the drawer for years) right now:
     
    As can be seen the Intel Atom x5-Z8300 CPU will be outperformed by an RK3399 or even an el cheapo NanoPi Fire3 pretty easily: https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md
     
    Onboard eMMC performance (16GB on my model) also not that impressive (random IO ok, but sequential write performance below SD card level at just ~20 MB/s):
    Internal 32 GB eMMC random random kB reclen write rewrite read reread read write 102400 4 2959 3431 16319 16706 11944 3400 102400 16 6710 6162 23026 23813 21143 6775 102400 512 15525 20512 100141 97841 98877 20622 102400 1024 20925 21024 102145 105088 100305 17150 102400 16384 20425 20749 106923 107996 108337 20844 1024000 16384 18512 19994 106359 106060 103988 20007 I backed this board in the beginning to check it with NAS usage in mind but never managed to attach fast storage since UP Board (just like LeMaker's Guitar back then) uses the crappy Micro-B USB3 receptacle (designed for OTG/device and not host mode -- you need an UEFI update and a special cable to be able to attach USB3 SuperSpeed peripherals to this board).
     
    BTW: kernel situation as crappy as with a lot of ARM boards (or maybe the board now fully works also with mainline kernel -- I don't know). At least the official kernel enabling majority of board features is a 4.9.45 that received zero fixes for over a year now: https://github.com/emutex/ubilinux-kernel
  6. Like
    tkaiser got a reaction from TonyMac32 in Top-Left USB port on Le Potato board crashes USB driver on 4.14   
    LOL! Yeah, asking the SoC vendor constantly cheating on users... haha, no, my simple approach is to stay away from everything where's Amlogic printed on!  
  7. Like
    tkaiser reacted to mindee in NanoPi NEO4   
    Just a little bit list, more detail would be done on wiki soon.
    1. NEO4 board size is 45 x 56mm, but M4 is 85 x 56mm
    2. NEO4 has 1GB DDR3 RAM with single chanel, But M4 has two version 2GB DDR3 RAM/4G LPDDR3 RAM with Dual Chanel.
    3. NEO4  will use AP6212 wireless module with single antenna , but M4 use AP6356S dual-band module, and use 2x2 MIMO and 2 real antennas. 
    4. NEO4 has one MIPI-CSI, M4 has two MIPI-CSI
    5. NEO4 has USB3.0  x1 & USB 2.0  x1, but M4 has USB 3.0 x4 behind a VL817 internal hub.
    6. NEO4 use 1.27mm pitch SMD connector for GPIO-40 pinout,  M4 is same with RPi3 40pin GPIO.
     
    Both have:
    1. PCIe x2 pin-out
    2. eMMC module connector
    3. GigE port.
    4. TypeC is for power supply and OTG.
    5. HDMI-A & MicroSD slot.
    6. Big CNC heat sink, with two side 1/4 screw hole
  8. Like
    tkaiser got a reaction from lanefu in DNS issues for local network with Armbian only   
    Please see
     
    It seems writing something to /etc/resolvconf/resolv.conf.d/head at image creation time creates this issue and removing the file should solve it. @Igor wanted to look into but no idea what happened.
     
    IMO neither using Google's DNS nor Cloudflare's is a brilliant idea and we should really change this so user's local config always wins. Details: https://blog.powerdns.com/2018/03/22/the-dns-camel-or-the-rise-in-dns-complexit/
     
  9. Like
    tkaiser reacted to Igor in Firefly RK3399 support efforts (potential csc board?)   
    That is not a problem. How about this way:
     
    RK3288 -> rockchip with whatever source, ayugan if there will be not much hassle
    RK3399 (RockPRO) and RK3328 (Rock64) ->  rockchip64 (ayufan source)
    RK3399 (FriednlyARM) remains RK3399 (fa source) ... we postponed this merge for the future
  10. Like
    tkaiser got a reaction from NicoD in Tinkerboard S: What is ASUS view on voltage drops in cables?   
    Are you kidding?
     
    https://www.google.com/search?rls=en&q=Micro-USB_1_01.pdf
     
    This is the relevant specification for WHAT YOUR USERS HAVE AT HOME. The connector is rated for 1.8A max, 99.99% of cables are made for 500mA max.
     
    That is the REALITY OUT THERE if you throw an electronics device on the market equipped with this crappy Micro USB connector. It encourages users to use common Micro USB gear which simply WILL FAIL with the Tinkerboard since not made for higher currents than a few hundred mA.
     
    USB PD (power delivery) specs in the meantime defined NEW specifications so with both NEW receptacles and NEW cables 3A are possible with Micro USB. The USB PD specs (see here for an overview) while now defining NEW Micro USB connections (needing NEW receptacles, jacks and cables!) do of course not define any PD profile that uses 3A at 5V. Why? Since VOLTAGE DROP. Ohm's law still exists. The lower the voltage, the higher the drop.
     
    The USB PD specs define Micro USB carrying 3A with NEW Micro USB connectors and NEW cables only at 12V (Profile 3) or 20V (Profile 4). And the reason is once again called VOLTAGE DROP.
     
    If you put a Micro USB receptacle on your product to power your board you do two things at the same time:
    Encourage users to use the Micro USB gear that's already lying around (crappy phone chargers, average cables not suitable for more than 500mA). You introduce underpowering hassles Encourage users to make the wrong calculation since they think they won't need a new and special PSU if they already have a charger or an USB PSU lying around. You try to create the impression your product would be cheaper than it is (since always needing a SPECIAL Micro USB PSU which is additional costs) By using Micro USB board makers trick their customers into believing they could re-use existing PSUs so the board appears to be a less expensive buy compared to honestly stating that while the board uses a pretty common connector it's incompatible to 99.99% of all Micro USB gear that consumers already have.
     
    And the whole sh*t show started over at the RPi. If they would've started with a sane barrel plug this whole mess wouldn't exist. Since then those other board makers who copied the crappy Micro USB connector would now copy this barrel plug instead to advertise their '1:1 replacement for the RPi'.
     
    Since having the same moronic discussion with the RPi fanclub some while ago: https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=208192&start=50#p1292499 (just a quick check how many different Micro USB connectors at which amperage rating a company like RS sells. If you read through the whole thread please keep in mind that RPi forum moderators act as censors. They partially edited my posts and banned my account as a result of frequent mentions of competitor's products. But that's normal over there)
  11. Like
    tkaiser got a reaction from NicoD in Another RK3399: Khadas Edge   
    This just works (on RockPro64 -- I did the testing already of course):
     

  12. Like
    tkaiser got a reaction from markbirss in FEL mass storage or writing images directly to eMMC   
    One of the Banana Pi employees took @zador.blood.stained's work, added a Windows GUI and extended SoC support from H3 only to A64, A83T and even H5: http://forum.banana-pi.org/t/the-3rd-party-emmc-flash-tool-for-bpi/4080
  13. Like
    tkaiser got a reaction from chwe in DNS issues for local network with Armbian only   
    Tried a fix with https://github.com/armbian/build/commit/f10acc0080825faf711eb6e6b7425910d75d840c
     
    Would be great if you could try next nightly version and report back.
  14. Like
    tkaiser reacted to JMCC in NanoPI M4   
    Well, FFmpeg's RKMPP support includes only decoding so far, so not many chances that Plex/Emby will support accelerated encoding for RK3399 anytime soon. Gstreamer should be pretty well supported, in theory just as RK3288, but I haven't tested it. Now I'm returning to SBC's after some weeks, so I'll make sure to test video encoding when I do the RK3399 media script, God willing.
  15. Like
    tkaiser got a reaction from gounthar in NanoPI M4   
    I hope you added the heatsink?
     
    My take on 'enclosure' is all those boards landing in a drawer. Since most recent boards generate more and more heat I'm thinking about adding 2 large and silent fans + dust filters in a similar way as shown here: https://forum.openmediavault.org/index.php/Thread/18962
  16. Like
    tkaiser got a reaction from gounthar in NanoPI M4   
    Ok, so it's confirmed:
     
    Powering also possible through pins 2 and 4 so since the SoC is at the right side and heat dissipation is no problem @mindee could evaluate a 'SATA HAT' using the 2 PCIe lanes, a Marvell 88SE9235 SATA controller (x2 PCIe to host, 4 x SATA 3.0 to disks) and power circuitry with 12V input able to feed board and 4 x 3.5" disks.
     
    If I understood correctly RK3399's VPU capabilities make it interesting as transcoding NAS (once video support is ready in Linux, though no idea how far things are. @JMCC do you know about the state of video transcoding with RK3399?)
  17. Like
    tkaiser reacted to wtarreau in NanoPi NEO4   
    I thought they were two different names for the same upcoming board, with various intermediary designs. But you're right, the NEO4 is even smaller than the M4! So yes that makes sense, it's a single channel RAM. Then I think I'm more interested in the M4. However if they made a complete aluminum enclosure like they recently did with the NEO/NEO2 with the buttons and OLED, it could be very tempting to get one as well for about everything you can do with a machine lying in your computer bag!
  18. Like
    tkaiser reacted to Icenowy in Banana Pi M2U - A40 - ethernet interface problem   
    Mikey from Sinovoip showed me some photos on kernel logs that is said to be booting A40i with mainline U-Boot.
     
    (Of course this makes no difference as mainline U-Boot doesn't try to recognize the print on the chip ;-) )
  19. Like
    tkaiser reacted to guidol in Banana Pi M2U - A40 - ethernet interface problem   
    OK - I have requested the boot log:

    Guido Imran Lehwalder:
    Lion Wang If you got an example of the board with A40i would it be possible to get a bootlog of armbian with kernel 4.18.y from this A40i device?
    This would much help for working on armbian for the A40i version of the board ;)
    And maybe if you logged in in armbian also a the info from:
    armbianmonior -u

    Lion Wang:
    Guido Imran Lehwalder Ok ,i will let my R&D ( Research and development ) do this work ,thank you.
    i see armbian have a beta image for Ultra and berry .
     
    I also doubled the request in their forum.
     
  20. Like
    tkaiser got a reaction from iamwithstupid in NanoPi Duo2 and NanoPi Hero are coming   
    By comparing https://github.com/friendlyarm/linux/blob/sunxi-4.14.y/arch/arm/boot/dts/sun8i-h3-nanopi-duo2.dts and https://github.com/friendlyarm/linux/blob/sunxi-4.14.y/arch/arm/boot/dts/sun8i-h2-plus-nanopi-duo.dts the only real difference is replacing the crappy XR819 Wi-Fi with RTL8189 (the other change being H2+ being replaced by H3)
     
    NanoPi Hero also features RTL8189 Wi-Fi, is limited to Fast Ethernet and has an I2C accessible voltage regulator allowing the board to clock at up to 1368 MHz (at 1.4V VDD_CPUX): https://github.com/friendlyarm/linux/blob/sunxi-4.14.y/arch/arm/boot/dts/sun8i-h3-nanopi-hero.dts
     
    Maybe @mindee is so kind to provide an early picture of the latter?
  21. Like
    tkaiser reacted to Gouwa in Another RK3399: Khadas Edge   
    There are four M.2 holes designed to mount the heatsink, two close to USB port, and the other two close to the gold fingers :)
     
    Actually, we designed the heatsink as the enclosure and same with VIMs heatsink it support to mount a cooling fan on it.
     
    the M.2/PCIE is on the bottom of the Captain carrier board.
     
    More details will be update on Khadas Webiste soon.
     
    Have fun!
     
  22. Like
    tkaiser got a reaction from Sergius Triticum Aestivum 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).
  23. Like
    tkaiser reacted to DrSchottky in H3 BROM reversing   
    Ok, thanks for the hint.
     
    Oh, since I haven't found one I made a little tool to dump the bootrom from userspace (tested on Armbian for H2+/H3, but should work on other SoCs too). I leave it here, just in case someone wants to play with this stuff 
     
  24. Like
    tkaiser got a reaction from Igor_K in NanoPI M4   
    Ok, so it's confirmed:
     
    Powering also possible through pins 2 and 4 so since the SoC is at the right side and heat dissipation is no problem @mindee could evaluate a 'SATA HAT' using the 2 PCIe lanes, a Marvell 88SE9235 SATA controller (x2 PCIe to host, 4 x SATA 3.0 to disks) and power circuitry with 12V input able to feed board and 4 x 3.5" disks.
     
    If I understood correctly RK3399's VPU capabilities make it interesting as transcoding NAS (once video support is ready in Linux, though no idea how far things are. @JMCC do you know about the state of video transcoding with RK3399?)
  25. Like
    tkaiser reacted to hipboi in SBC for 2 x 2.5 HDD   
    @tkaiser I did not forget it. We update ficus to v1.1 adding some requests from customers and now it's out. We will send you the new boards soon after some testing.