hjc

Members
  • Content count

    33
  • Joined

  • Last visited

About hjc

  • Rank
    Advanced Member

Recent Profile Visitors

257 profile views
  1. Definitely needs a SSD, not over USB 2.0, but something more reliable like the SATA on ESPRESSObin or NanoPC T4's M.2
  2. Firefly RK3399 (with official active cooling fan) sbc-bench test results: http://ix.io/1kk9 It shows impressive CPU performance numbers when overclocked to 2.2/1.8 GHz, but that definitely requires a fan.
  3. hjc

    Sinovoip made the BPI Wiki editable!

    IMO it's their employee's job to ensure the provided information are correct. Community members may help them correct typo, grammar, etc., but not basic specs. (e.g. Does a mPCIe slot support PCIe+USB or USB only) They would only feel themselves being cheated when incorrect specs were provided, unless the board is provided for free.
  4. Thanks for merging these boards into Armbian. I'm excited to see the first RK3399 board on Armbian download page. I've migrated my NanoPC T4 to the pre-built image downloaded from Armbian website just now. Also built an image for Firefly RK3399 from armbian/build repository. They all worked smoothly. I'll keep testing these boards and provide feedback or pull requests. BTW the dragonboard 820c & qcomlt kernel/u-boot should be removed, since those are just my personal interests, and they're not completed yet. I'm almost sure that few people would be interested in those Qualcomm boards & SoCs here.
  5. hjc

    NanoPI M4

    It seems that the DT files of NanoPi M4 and NanoPi NEO4 are already published on FriendlyARM GitHub. They share most parts (rk3399-nanopi4-common.dtsi) with NanoPC T4, with minor differences.
  6. I've fixed the build on GitHub, and it now uses latest 4.4.143 kernel from rockchip. Armbian seems to have changed a lot in recent days, haven't got time to rebase my work.,and haven't verified what works and what does not, but at least it builds and runs on my Firefly RK3399 (NanoPC T4 not tested).
  7. Only a few changes. It's basically about creating a new board family with appropriate kernel/u-boot config and patches (called "firefly" here, but actually should be called rockchip64) and adding two boards' definition (Firefly-RK3399 & NanoPC T4). see https://github.com/hjc4869/armbian-build/compare/56d614d1e5cb4d7ec3c803cfcf83bbe5bad04622...6d59a4fc93b46fd4de86bc8b1fa6a0adee4e7bc4
  8. Based on my previous experience, rk3399 can handle 1080p 30fps YouTube h264/vp9 video in chromium browser even without any hardware decoding or GPU present. A properly configured X11+DRI2 desktop would be sufficient. But the CPU's SIMD units are at full load and you'll definitely need a fan, or it will overheat and throttle the frequency.
  9. I'd be glad to do so, but recently I've just graduated and begun working full time, and not having much time to re-organize those development efforts into a solid PR. I'm also lack of usable RK3399 boards for developing & testing, since some of my home services have already been deployed to NanoPC T4. I'll buy some NanoPi M4/NEO4 boards once available. Besides, I still have some other boards to play with (Dragonboard 820c based on Qualcomm APQ8096), so maybe I could not contribute to Armbian for RK3399 directly these days. Sorry for that.
  10. hjc

    Firefly-RK3399

    Hey hjc, the kernel I used is the 4.4.132, which seems strange to me too. What is the status of your internal eMMC? I have the official firefly ubuntu flashed on my eMMC, could it be the problem? Would "dd if=/dev/zero" the eMMC force the board to boot from sd card? I just noticed that my board have a stiker saying the version of the board is "Firefly RK-3399R" what is your board version? I always do a "blkdiscard /dev/mmcblk1" before I try to boot from SD card. Haven't tried to boot with stock OS installed. If no u-boot spl is found on eMMC, Rockchip bootrom will try to load that from SD card. My board is Firefly-RK3399 Plus, purchased in October 2017.
  11. hjc

    Firefly-RK3399

    Which kernel did you use? The mainline (dev) kernel is currently broken for Firefly-RK3399 (if you disable the USB-C related stuff in the config, it should boot), but 4.4.132 works fine on my board.
  12. hjc

    NanoPC T4

    tell me about it. See this and this, they just silently broke all RK3399 boards, and then silently fixed it. This change even stops the UART from working so one cannot diagnose what's wrong. This is all done in the release-4.4 branch, and they seldom use tags, so I doubt they're not testing their code on various boards. Besides, they put both Mali Android and (old, not updated) Linux drivers in the kernel, and their modifications to rk3399.dtsi broke the Linux one, since they switched to the new power model. If you use an old kernel config, it will cause a kernel panic after you update the kernel. They finally completely removed the old Mali Linux drivers recently, and their CONFIG_MALI_MIDGARD_FOR_LINUX/CONFIG_MALI_MIDGARD_FOR_ANDROID disappeared.
  13. hjc

    RockPro64

    Those old u-boot versions are always annoying (I had some 'fun' with the MT7623 with a 2014 based u-boot). Do you know how mature 'mainline u-boot' for the RK3399 is? You still use the old one for the firefly, hopefully we can bring all those boards up with a recent u-boot together with some bits here and there to initialize DRAM properly for each board... RK3399 is supported by mainline u-boot. I changed BOOTSOURCE to https://github.com/u-boot/u-boot.git and checked it on Firefly-RK3399. It runs pretty well, even better than Rockchip u-boot (2017.x). It's running with good USB & ethernet support, booting OS flawlessly. I'm already running some heavy services on NanoPC-T4 so not rebooting them, but I assume it works basically the same. Playing around with u-boot: DDR Version 1.12 20180518 In Channel 0: DDR3, 800MHz Bus Width=32 Col=10 Bank=8 Row=15/15 CS=2 Die Bus-Width=16 Size=2048MB Channel 1: DDR3, 800MHz Bus Width=32 Col=10 Bank=8 Row=15/15 CS=2 Die Bus-Width=16 Size=2048MB 256B stride ch 0 ddrconfig = 0x101, ddrsize = 0x2020 ch 1 ddrconfig = 0x101, ddrsize = 0x2020 pmugrf_os_reg[2] = 0x3AA17AA1, stride = 0xD OUT Boot1: 2018-04-08, version: 1.12 CPUId = 0x0 ChipType = 0x10, 217 SdmmcInit=2 0 BootCapSize=100000 UserCapSize=29820MB FwPartOffset=2000 , 100000 mmc0:cmd5,32 SdmmcInit=0 0 BootCapSize=0 UserCapSize=15193MB FwPartOffset=2000 , 0 StorageInit ok = 80087 LoadTrustBL No find bl30.bin No find bl32.bin Load uboot, ReadLba = 2000 Load OK, addr=0x200000, size=0x90f40 RunBL31 0x10000 NOTICE: BL31: v1.3(debug):f947c7e NOTICE: BL31: Built : 19:40:58, Jun 11 2018 NOTICE: BL31: Rockchip release version: v1.1 INFO: GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3 INFO: plat_rockchip_pmu_init(1089): pd status 3e INFO: BL31: Initializing runtime services INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x200000 INFO: SPSR = 0x3c9 U-Boot 2018.07-rc1-armbian (Jun 19 2018 - 00:14:04 +0800) Model: Firefly-RK3399 Board DRAM: 3.9 GiB MMC: dwmmc@fe320000: 1, sdhci@fe330000: 0 Loading Environment from MMC... OK In: serial@ff1a0000 Out: serial@ff1a0000 Err: serial@ff1a0000 Model: Firefly-RK3399 Board Net: eth0: ethernet@fe300000 Hit any key to stop autoboot: 0 => => => usb start starting USB... USB0: USB EHCI 1.00 USB1: USB EHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 1 for devices... 3 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found => usb info 1: Hub, USB Revision 2.0 - u-boot EHCI Host Controller - Class: Hub - PacketSize: 64 Configurations: 1 - Vendor: 0x0000 Product 0x0000 Version 1.0 Configuration: 1 - Interfaces: 1 Self Powered 0mA Interface: 0 - Alternate Setting 0, Endpoints: 1 - Class Hub - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms 1: Hub, USB Revision 2.0 - u-boot EHCI Host Controller - Class: Hub - PacketSize: 64 Configurations: 1 - Vendor: 0x0000 Product 0x0000 Version 1.0 Configuration: 1 - Interfaces: 1 Self Powered 0mA Interface: 0 - Alternate Setting 0, Endpoints: 1 - Class Hub - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms 2: Hub, USB Revision 2.0 - USB 2.0 Hub [MTT] - Class: Hub - PacketSize: 64 Configurations: 1 - Vendor: 0x1a40 Product 0x0201 Version 1.0 Configuration: 1 - Interfaces: 1 Self Powered Remote Wakeup 100mA Interface: 0 - Alternate Setting 0, Endpoints: 1 - Class Hub - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms 3: Mass Storage, USB Revision 2.10 - SanDisk Ultra USB 3.0 4C530001240422114145 - Class: (from Interface) Mass Storage - PacketSize: 64 Configurations: 1 - Vendor: 0x0781 Product 0x5595 Version 1.0 Configuration: 1 - Interfaces: 1 Bus Powered 224mA Interface: 0 - Alternate Setting 0, Endpoints: 2 - Class Mass Storage, Transp. SCSI, Bulk only - Endpoint 1 In Bulk MaxPacket 512 - Endpoint 2 Out Bulk MaxPacket 512 => dhcp ethernet@fe300000 Waiting for PHY auto negotiation to complete........ done Speed: 1000, full duplex BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 BOOTP broadcast 4 BOOTP broadcast 5 Abort =>
  14. hjc

    NanoPC T4

    Haven't got that working even on legacy kernel. Maybe it's a kernel configuration issue.
  15. hjc

    NanoPC T4

    Headless images already works, except big.LITTLE scheduling. AFAIK, there isn't a good solution for this in vanilla kernel. For lightweight desktop, HDMI is a major problem (incomplete in status matrix, at least my monitor is not working well with RK3399 mainline).