@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.
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?
@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.
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.
@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.
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?
@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
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..
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
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.
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 Linux_Upgrade_Tool_v1.24.zip upgrade_tool and copied it to /usr/local/bin
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:
Firefly-RK3399_Android8.1.0_HDMI_180901.img
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.
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.
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
Comments
@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
lsusband 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?
@Slashin8r try using libre's verified 16.04 http://share.loverpi.com/board/libre-computer-project/libre-computer-board-roc-rk3328-cc/image/
and flash with Etcher
@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?
@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 -
lesscan 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
ddor 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..
http://lcpugwiki.readthedocs.io
..sourced here: https://github.com/LibreComputerProjectUserGroup/wiki
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:
/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 Linux_Upgrade_Tool_v1.24.zip upgrade_tool and copied it to /usr/local/bin
cp /data/ROC-RK3328-CC/upgrade_tool/Linux_Upgrade_Tool_v1.24/upgrade_tool \
/usr/local/bin
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 \
/usr/local/system.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:
Firefly-RK3399_Android8.1.0_HDMI_180901.img
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,
Cookies_Domain_Shop
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.
Try this for an image writing utility. I find it's better than WinDiskImage32 or others.
https://www.majorgeeks.com/mg/getmirror/usb_image_tool,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