Jump to content

codnoscope

Members
  • Posts

    13
  • Joined

  • Last visited

Reputation Activity

  1. Like
    codnoscope reacted to hjc in ROC-RK3399-PC (Renegade Elite)   
    That might be true, since there's already an RK3399Pkg (haven't tried myself), but I'd still recommend u-boot, unless you are interested in one of the following use cases:
    1. CentOS/Fedora/openSUSE, based on UEFI and grub on ARM64. These distros are mostly made for servers, instead of IoT stuff, so if you want something like KVM on ARM64, you could try to use them. But I doubt RK3399's 4G RAM could ever handle virtual machines. If you really want an ARM64 server, I recommend more serious solutions like Qualcomm centriq or Cavium ThunderX. If you just want to isolate your own code into different environments, use lxc/lxd or docker on (u-boot based) Armbian.
    2. Windows on ARM64, requires UEFI and ACPI. I'd admit it's quite attractive lightweight desktop solution, and it can even handle simple x86 programs as well. There's already someone made this for Raspberry Pi 3, but just forget it, that's definitely unusable, considering the horribly slow IO of RPi and the crazy (heavily IO bounded) background tasks of the most bloated desktop OS on the earth. On RK3399, yes, I think it is possible to handle Windows' crazy background IO with a USB or SATA or even NVMe SSD (actually a good eMMC could handle that as well), but you'll need to write a lot of Windows drivers to bring up a new platform, including SDIO, eMMC, USB, GMAC, PCIe, and the most difficult part, display drivers (like Rockchip DRM on Linux) on your own or you have to use the (probably slow as hell) UEFI GOP for display. GPU is actually not needed to run Windows desktop, and probably not possible unless you are an employee of ARM Holdings and has the source code of the Mali GPU Windows drivers which has never been released before but actually does exist. The assumptions above are all based on the fact that ACPI was implemented properly, and I don't think this would be true. You can implement ACPI on your own, though.
     
    I don't have any other idea to convince myself that UEFI would be useful on this platform. What's the exact use case you're expecting to do with UEFI?
     
    IMO The biggest and only problem so far for all RK3399 boards is pricing. And this was the reason that I was excited about NanoPi M4, since it had a much lower price while keeping the essential components on board (like WiFi/BT). Unfortunately, people around me still think $65 is a little too high for an SBC when I recommend the board to them. For most people, purchasing a $99 (or higher) SBC is really a crazy idea, even if Armbian has great support for it.
     
  2. Like
    codnoscope reacted to Igor in Firefly RK3399 support efforts (potential csc board?)   
    Don't have this board. Untested.
    https://dl.armbian.com/firefly-rk3399/
  3. Like
    codnoscope got a reaction from gounthar in Rockchip RK3399   
    I would say you should wait a few months for support for these chips to mature.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines