How to verify that the hardware is working at all ...



  • @JeffMeden The board doesn't have any built-in Wi-Fi. You'll need a USB Wi-Fi adapter if you need Wi-Fi.

  • @james_pic yes thanks it's clear now, altho the stream of "rockchip wifi" errors during bootup definitely are misleading. I did try a linux-friendly tplink usb adapter with no more success (it seems there might be just one wifi driver built for this kernel and I have no idea what kind of adapter uses that chip)

  • I downloaded the image rar file, decompressed it and wrote it to the SD Card using etcher on Windows. On boot I get red and green LEDs and then eventually only red. I don't see anything on a screen (1366x768 LCD) connected via HDMI that works fine with a Raspberry.

  • could be that resolution is not supported yet, in display settings it is not one of
    the 6 to choose from

  • If its a display issue you should still get the network to connect (look for ip in dhcp list on your router) and you can log in remotely via ssh with firefly/firefly

  • I just tried that and I have my first signs of life. I was able to ssh into board. Where are the supported HDMI display modes documented? Is 1920x1080 supported?

  • Ubuntu display settings show 720x480, 1280x720, 1920x1080, 3840x2160, 4096x2160 as choices

  • @james_pic, do you have the full dmesg log from UART?

    @JeffMeden run lsusb and provide the hex code for the USB device. The chip can be looked up from that code.

    @WZ9V Please see the announcement in the ROC-RK3328-CC category about display resolutions. We need to add it to the next image. CEA modes like 1080P/720P/480P/4K are supported right now and we have to add many of the DMT modes.

  • @loverpi, I am having difficulty getting the Ubuntu image to boot. I have downloaded the images provided by @Kragius and got the system.img file to boot up correctly so I know the device is working. I am using the SDCard Installer provided by Firefly to flash the Ubuntu image. The boot process hangs at different points each time, similar to the issue @james_pic is experiencing. Below is an image of the most recent boot attempt.

  • @loverpi I'm not sure how to get the full dmesg from UART. How do I do this?

  • @jeepthing Flashing that image with Etcher gives me the same results I got from flashing it with dd.

  • I think I've figured out how to attach to UART (I've used the included USB - TTL adapter, connected to the pins marked "debug"), and I get some output (and the serial output seems to accompany with the on-screen output), but it looks like unintelligible binary (and any terminal I attach is just garbage). I've attached the output, in case anyone can make sense out of it.

  • @james_pic On ROC-RK3328-CC, the UART speed should be set to 1500000 or 150000. I forget which.

  • @jeepthing, That is where I originally started before having to research the issue and finding this discussion.

    So far, the only image that has worked was the system.img provided by @Kragius, but it had display issues. I think I will stick to that for now until a proper fix can be found. Since I am not the only one experiencing this issue I hope that a solution will be provided in the near future.

  • @Slashin8r If @Kragius images work except for graphics, that's great for me - I was planning on running it headless anyway.

  • @loverpi 1500000 got it. I've attached the dmesg output.

  • Just in case the issue was related to filesystem corruption from repeated restarts, I re-ran it with a freshly flashed image. It looks like it's failing in the same way (I want to say it's double-faulting in udev, but my kernel-foo isn't strong).

  • @james_pic, The system.img is Debian 9.3, just wanted to give you a heads up in case that matters. Other than some graphical issues, slight pixelation across desktop and on icons (which most self-corrected on the 2nd boot), it runs fast and smooth.

    @loverpi, I just found out that my bottom USB2 does not work. Is there a way to test this to see if it is a hardware issue or software issue?

  • edited April 2018

    @james_pic Your serial2.txt is un-readable. Can you repost?

    @Slashin8r Until we release the mainline images, it is hard to say. I am not that familiar with Rockchip's BSP.

  • @Slashin8r try using the bottom USB2 after its booted up, I had to unplug plug back in
    mouse , after using it for awhile doing, sudo apt-get update, sudo apt-get upgrade
    and updating packages it now works, with android I still have to plug in after boot

  • @loverpi It seems readable to me - less can open it just fine. It starts with a null byte, which may trick editors into parsing it as UTF-16 BE.

  • I was able to get firefly's new online tool to work for android, they changed to different
    build , the tool downloaded it flashed to SD and it boots up, it downloads very slow tho

  • I'm still having trouble with the April Ubuntu 16.04 image. Here's serial terminal output from a failed boot with a clean SD card. I get the same whether I flash it with dd or Etcher.

    Has anyone else had any luck with the Ubuntu images on the 4GB units? If so, I'm beginning to wonder if I've just got faulty hardware.

  • pacav69 and I created a wiki that includes troubleshooting. You can post issues to it (and we'll try to massage your contribution in) or even become a contributor yourself if you'd like. It's just nice having everything in one spot..

    ..sourced here:

  • We ordered a ROC-RK3328-CC, 4G, heatsink, case, an eMMC module w/ USB cable.
    Locally, we purchased a 128GB SanDisk A1 microSDXC UHS-1 from BestBuy.
    We use Slackware (current) v~14.2 Linux.
    (We only use Windows in a Virtual Box if absolutely necessary.)
    We also mandatorily use anti-static protection for device and handler with a mutual ground for field pad and wrist strap..
    We installed the heat sink.
    We ran an initial "smoke test" (we plugged it in) to see if it would damage any of our equipment.
    No smoke. No overheating. A red and green LED came on but that's it.
    We ran the "smoke test" with the eMMC card installed.
    No smoke. No eMMC overheating either. Same red and green LEDs came on.
    We identified the SD card with lsblk. It (sdb) was not mounted.
    We ran f3probe on the SD card.

    f3probe /dev/sdb
    F3 probe 7.0
    Copyright (C) 2010 Digirati Internet LTDA.
    This is free software; see the source for copying conditions.

    WARNING: Probing normally takes from a few seconds to 15 minutes, but
    it can take longer. Please be patient.

    Probe finished, recovering blocks... Done

    Good news: The device `/dev/sdb' is the real thing

    Device geometry:
    Usable size: 119.08 GB (249737216 blocks)
    Announced size: 119.08 GB (249737216 blocks)
    Module: 128.00 GB (2^37 Bytes)
    Approximate cache size: 0.00 Byte (0 blocks), need-reset=no
    Physical block size: 512.00 Byte (2^9 Bytes)

    Probe time: 3'47"

    The SD card seemed to pass.
    We downloaded and extracted Firefly-RK3399_Android8.1.0_HDMI_180901.img
    It's a 1.4 GB file on disk.
    We burned the (alleged) firmware and disk image to the SD card.

    dd if=/data/ROC-RK3328-CC/firmware/Android/Firefly-RK3399_Android8.1.0_HDMI_180901/Firefly-RK3399_Android8.1.0_HDMI_180901.img of=/dev/sdb conv=notrunc

    2666232+1 records in
    2666232+1 records out
    1365111256 bytes (1.4 GB, 1.3 GiB) copied, 302.057 s, 4.5 MB/s

    We checked to see if the data was actually written
    There were two new sgi partitions:

    Device                   Start              End          Sectors          Size       Id Type                   Attrs

    /dev/sdb9 0 4095 4096 2M 0 SGI volhdr

    /dev/sdb11 0 249730424 249730425 119.1G 6 SGI volume

    We inserted the SD card into the slot (without the eMMC card or cable installed,
    connected USB mouse and keyboard and HDMI cable.
    We plugged in the microUSB cable and connected it to power.
    The red and green LED's came on but nothing else happened for several minutes,
    The HDMI and screen are in normal use when not testing this board so we know they work.
    We tested again without the mouse and keyboard attached.
    The red and green LED's came on but nothing else happened for several minutes,

    (We also tried the above procedure with theROC-RK3328-CC_Android7.1.2_180518.img.xz)

    We presumed that by powering the board on with a black eMMC card we inadvertently altered the boot loader.

    We downloaded and extracted the upgrade_tool and copied it to /usr/local/bin

    cp /data/ROC-RK3328-CC/upgrade_tool/Linux_Upgrade_Tool_v1.24/upgrade_tool \

    chown root:root /usr/local/bin/upgrade_tool
    chmod 0755 /usr/local/bin/upgrade_tool

    We copied the Android image to the same directory for convenience renaming it to system.img

    cp /data/ROC-RK3328-CC/firmware/Android/Firefly-RK3399_Android8.1.0_HDMI_180901/Firefly-RK3399_Android8.1.0_HDMI_180901.img \

    We put the connected the two pins specified and powered on the board to force it into Maskrom mode.

    The red and green LED's came on but nothing else happened.

    We connected the M/M USB cable supplied.

    From /usr/local/bin/ We ran (as root):

    upgrade_tool db out/rk3328_ddr_333MHz_v1.13.bin
    Open loader failed,exit download boot!

    So it's not finding the boot loader.
    We presume "out/ is a directory resulting from compiling a boot loader.

    Since we downloaded the file instead of compiling a boot loader we don't have such a directory
    We don't know where it's supposed to be and there's no documentation indicating the desired location.

    At this point we presume there is no firmware, no boot loader and no OS and that we have to compile a kernel a boot loader and Android just to get this thing to enter some monitor mode.

    We want to know if it's worth our time or if we have a DOA board.

    As a last resort we tried:
    upgrade_tool uf system.img
    Loading firmware...
    Loading firmware failed!

    This is the system.img that was originally:

    So we wanted to know how successfully we were talking to the board.
    We executed:

    upgrade_tool TD
    Test Device Fail!

    upgrade_tool RD
    Reset Device Fail!

    to find out if we were talking to the board at all, we unplugged the board and tried again.

    upgrade_tool RD
    No found any rockusb device,please plug device in!

    So it is talking to the board, but not uploading the firmware. We're not sure to what extent the device is even working.

    At this point we can order a serial board but we're not expecting the output will tell us anything more than we already know.

    The failure to provide the most basic firmware image(s) / boot loaders seems to render this investment unusable assuming that it wasn't received DOA.

    Kind regards,


  • just to answer the original question ... in my hands, when the system boots up successfully, the green led goes off after a few seconds. without a boot, it stays on.

  • edited November 2018

    Try this for an image writing utility. I find it's better than WinDiskImage32 or others.,1.html

    If you want to make the Green LED flash when there is disk activity, I can help.
    I edited /etc/rc.local and added in :
    cd /sys/class/leds/firefly:yellow:user
    echo "mmc0" > trigger
    cd /
    You will need to be root for this. mmc0 is the MicroSD slot. You can find out other devices by executing the following $ ls -l /dev/disk/by-id
    or use lsblk

Sign In or Register to comment.