Search the Community
Showing results for 'rock64'.
-
Great thanks, this worked for me! I had the same problem as Antoine: I already owned one ROCK64 board and I just added other 2 (v3.0 2018-1105) and I was having issues with the network. All of them had the same MAC and efuse is empty also. $ xxd /sys/bus/nvmem/devices/rockchip-efuse0/nvmem 00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................ I flashed the image (Armbian_20.11.3_Rock64_focal_current_5.9.14_desktop in my case) on the eMMC and then I modified /etc/network/interfaces before starting for the first time, and all worked like a charm. I usually modify also the hostnames, so the avahi announce on the network is different for each board.
-
Good day, I'm looking for help adding touchscreen support to the ROCKPI 4 Legacy Kernel and correct screen configuration settings. Im new to SBC development so I'm still learning the build system. I have taken the time to track down, what I believe, are the commits to add basic support for the "Raspberry Pi 7" Touchscreen" to the kernel. I believe their will be changes needed to rootfs so that the display manager recognizes it and sets it up properly. ARMBIAN_BUILD_BRANCH: Legacy Kernel --> https://github.com/ayufan-rock64/linux-kernel/tree/release-4.4.202 RADXA_BUILD_BRANCH: Kernel --> https://github.com/radxa/kernel/releases/tag/4.4.154-110-rockchip MY_BUILD_BRANCH: Armbian Legacy Kernel --> https://github.com/SydeLink/linux-kernel/commits/sL-armbian-radxa These are the commits I've cherry picked from Radxa's Kernel 97f1fae7dcaea5712ae69d239016251090242bcd //Overlay a9e01ea73ca3a5e3e25d78cb3725ced3f3c3c8ca //Driver 29beb4f7264afcc6bb60672e06e1f8b727903eb4 //Driver de225d96bb00b0b187f930df3c077fd172b9255f //Driver It builds successfully. I've installed to device. It now boots to black screen. I believe its now picking up the screen but no longer knows what to output to. I remember seeing some commits to add fallback to x11 for this issue but cant remember where. I'm pausing at this point for the evening. Hope this helps others :D
-
@Werner What if you'd ask to ship it together with your M1? I'm willing to pay for yours and mine, if you ship mine when received. I'm not too willing on the M1. I've got a Rock64 that brought me a lot of headaches. Now the problem is found, but it was so unstable and I couldn't figure out why.(difference in ram modules)
-
Hello togehter, I did a fresh os install on the Rock64, but even though it installs correctly and initially works, it stops after a reboot. Already tried different kernels and even the nightly version. docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 6dc24654d9f9 homeassistant/raspberrypi4-64-homeassistant:0.118.5 "/init" About an hour ago Exited (255) About an hour ago homeassistant f8aac0ec7775 homeassistant/aarch64-hassio-multicast:3 "/init" About an hour ago Exited (255) About an hour ago hassio_multicast b7751d91ddfd homeassistant/aarch64-hassio-observer:2020.10.1 "/init" About an hour ago Up 2 minutes 0.0.0.0:4357->80/tcp hassio_observer b4425d86051c homeassistant/aarch64-hassio-cli:2020.11.1 "/init /bin/bash -c …" About an hour ago Exited (255) About an hour ago hassio_cli 764edea09d68 homeassistant/aarch64-hassio-audio:17 "/init" About an hour ago Exited (255) About an hour ago hassio_audio 7b8d7aa79b28 homeassistant/aarch64-hassio-dns:2020.11.0 "/init" About an hour ago Exited (255) About an hour ago hassio_dns d99989112f79 homeassistant/aarch64-hassio-supervisor "/init" About an hour ago Exited (255) About an hour ago hassio_supervisor also if a open up ip:4357 it only says Home Assistant observer Supervisor: Disconnected Does anybody know how to fix this? Thank you in advance. Best Regards, Vin
-
Hi, I have 3 Rock64 4GB boards (v2.0, rockchip production week says 1812 for all boards), running Armbian Buster 5.8.y (11/25/2020), and they all have the same MAC address. I tried reflashing the OS a couple of times on eMMC modules, didn't help. I did have the cloned-mac-address stance in my connection file, and removing it like suggested in the previous answers didn't fix the issue. I'm getting this for all 3 boards : $ xxd /sys/bus/nvmem/devices/rockchip-efuse0/nvmem 00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................ Any idea of what is going on ? Thanks!
-
That screen probably connects the touch panel through GPIO which is not near as big of a deal as getting the whole screen working through the gpio header. If you don't want the touch function, you can ignore it. It looks like the only way to push video to that screen is hdmi. Which should be fine. As for whether the connectors will line up? The Rock64 has the same footprint as the raspberry pi 3 and the connectors appear to be in the same places? I'd rate it a solid "maybe". https://files.pine64.org/doc/rock64/rock64 board dimension.pdf https://www.mouser.com/new/dfrobot/dfrobot-raspberry-pi-3-bplus/
-
Ya, I though it would not be as simple. Shame there isn't as big as a community for the rock64 compared to Raspberry or even the Orange pi, especially on emulation. It's a pretty solid board for that. The issue is to connect the Rock64 to the display using the provided HDMI angle adapter, I'll have to connect it to the GPIO too. Which is still uncertain as the GPIO's on the Rock64 are slightly different than on the raspberry pi, as what Tony stated. Not sure if it would cause any damage to either the board, screen or both. I could also just use an HDMI cable, but I want to be able to mount the Rock64 on the back of the display with the provided display housing, while also using the provided HDMI angle adapter as it is much neater/cleaner looking. Unless of course if I use the provided HDMI adapter while it is connected to the GPIO, the pins will be bypassed except the 5v and ground. Otherwise, I'll keep looking around for a display without a GPIO connector.
-
Hello, Is it just me or something has changed lately regarding the installation of u-boot on SPI? I have a Rock64 v2 and I am quite sure one year ago or more I used to update the SPI using the nand-sata-install script. Today I wanted to flash it again, but whenever I run the script (either via armbian-config) the error message in the title is shown and nothing occurs. Running Armbian 20.21 with legacy (4.4) kernel. Oh, the relevant u-boot package according to apt is installed. Thanks! Edit: The reason behind is to check if a newer code would finally support booting from the SSD plugged on the USB3 port, which never worked, while it has always worked if plugged on a USB2 port.
-
Hi @soerenderfor, can you explain a bit further the process? I downloaded the u-boot-flash-spi-rockpro64 from there : https://github.com/ayufan-rock64/linux-mainline-u-boot/releases/tag/2020.01-ayufan-2014-gff2cdd38 I downloaded the last release of armbian for RockPro64. Then : -Flash u-boot - Install armbian then use armbian-config to move the system to my Sata SSD (Boot from SPI - System on SATA) - Still in armbian-config, I accepted/declined the option to update the bootloader in the SPI flash I did those three in every order, flashing first then installing, installing then flashing, accepting the update to the bootloader in armbian-config, then declining it... Leaving the bootloader on the SD card does works ("Boot from SD - System on SATA" in Armbian-config), but I can get my RockPro64 to boot directly from the SATA SSD. What am I doing wrong / What did you do exactly to make it work?
-
Armbian v20.11 (Tamandua) Planning Thread
balbes150 replied to Werner's topic in Armbian build framework
You can check the General launch of one of the desktop images from this link to Rock64 and (if possible) show the output of the UART log ? I am interested in two options for starting-do not change anything after recording and the second, change the dtb to rock64. https://users.armbian.com/balbes150/firefly_station_m1/ArmbianTV/ -
Armbian v20.11 (Tamandua) Planning Thread
lanefu replied to Werner's topic in Armbian build framework
Yes I have a rock64 v2 -
Armbian v20.11 (Tamandua) Planning Thread
balbes150 replied to Werner's topic in Armbian build framework
Does anyone have Rock64 available to perform a small check on the ability to start the system ? -
As Tony said. That display is HDMI. It only takes 5V from the GPIOs. The Rock64 has the same form factor. So even the HDMI adapter should work. I use a simular 3.5" display on boards like the Odroid C2. You can also power the display with micro-USB from the USB ports of your device if you don't want to put it on the GPIO's or if it doesn't fit.
-
Hello @TonyMac32, many thanks for the information! I did some further research, and it looks like the TXD and RXD on the Rock64 is on pins 19 and 20. Where as on the Pi, it's on pins 8 and 10. So you are right, the display might not work on the rock64 if I were to use the SPI interface, rather than the HDMI. I don't want to risk damaging my Rock64, so I'll hold off on that display until I get a PI. I did found a very detailed document HERE that goes over all of the pins on the Rock64. If an SD card is in place, pins 19, 21, 23 and 24 will become unavailable, as those occupied by the memory chip. So long story short, I think I'll continue to use my monitor as a display for my Rock64. Which is strange, as other documentations did say that the Rock64 is quasi-Raspberry pi compatible, but oh well. The Rock64 is a great emulation machine for it's price, since I got the bundle on Amazon. It's just a shame that not a lot of GPIO devices support the Rock64. EDIT: also found this very detailed post that goes over the rock64's GPIO pins. Forum link
-
Hello @joey99, This is a bit of a complicated question, I'll give it my best shot. The Raspberry Pi GPIO's are tied to the Broadcom SoC and as such are named accordingly. This will not be the numbering found on any other board with an open market SoC. So the numbers will never line up on anything else, since no one is allowed to buy the processors used by the RPi foundation. To the GPIO on the RK3328 (The SoC found in the Rock64), Rockchip arranges it's GPIO thusly: Bank ---> Group ---> Pin The RK3328 has GPIO0,1,2,3 Each has a theoretical 32 pins, grouped A0-7, B0-7, C0-7, and D0-7 Linux will assign these a scalar value, IO 0- whatever the top number is. That's where my knowledge ends. In short, your hat should work, assuming you have the drivers for it and can extract the proper pin numbers out of the documentation. [Edit] and on second look ,that display is HDMI, but I assume you were thinking of SPI LCD's. A GPIO TFT LCD will not be compatible as the Rockchip pins for parallel LCD are not sent to the same places.
-
The GPIO pins on the Rock64 are very similar to the Raspberry Pi's GPIO, except the Raspberry pi calls pin #19 GPIO 10, pin #21 GPIO 9 and pin #23 GPIO 11. Where as the Rock64's pin #19 is GPIO3_A1, pin #21 GPIO_A2 and pin #23 GPIO3_A0. The Rock64 documentation does say that it is quasi-Raspberry Pi compatible, but it's hard to find anyone who has actually tested this. Here is the GPIO layout of the Rock64, compared to the Pi 3 I'm currently trying to figure out if a display such as THIS can be connected to the Rock64's GPIO pins without any major issues. User documentation for the display can be found HERE on page 2, in the PDF named 5inch_HDMI_Display_User_Manual. Any information will be greatly appreciated.
-
I'm happy to have helped. The Rock64 boards are not the best. I had a lot of troubles with mine. But to they are good enough to have fun with, certainly for that price. Enjoy them, and have a nice day. -
Thanks so much for posting your videos. I recently picked up a number of Rock64 1-GB SBCs off Amazon for $8-$15 (they were used as part of a security monitoring platform that seems to be dumping inventory). I'm just getting started building simple home sensor and monitoring projects. Your Armbian tutorials and insights have been extremely helpful. -
Rock64 enable 1-wire to read DS18B20 or Dallas temperature sensor
martinayotte replied to Perry's topic in Beginners
Ok ! I've never try this over on Rock64, but I did for some other Rockchip boards. So, I've just tried and figured out that U-Boot version was not supporting "setexpr" function, so fixup script failed : ## Executing script at 0900Unknown command 'setexpr' - try 'help' Unknown command 'setexpr' - try 'help' Unknown command 'setexpr' - try 'help' Unknown ' Unknown command 'setexpr' - tlibfdt fdt_getprop(): FDT_ERR_NOTFOUND libfdt fdt_path_offset() returned FDT_ERR_BADPATH I will check to see if doing new builds will provided newer U-Boot for this board ... Alternatively, it is possible maybe to workaround by editing main DT instead of using overlay. -
Good evening. I added the following to /boot/armbianEnv.txt param_w1_pin=GPIO1_D4 This is the armbianEnv.txt contents verbosity=1 bootlogo=false overlay_prefix=rockchip rootdev=UUID=cbeeff94-c38d-4a79-b10a-3854a2470be4 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u param_w1_pin=GPIO1_D4 overlays=i2c7 spi-spidev w1-gpio I restarted the Rock64. The w1 directory is not created in the /sys/bus/ directory. I have to run modprobe w1-gpio and/or modprobe w1-therm to see the w1 directory. The /sys/bus/w1/devices/ directory is empty. There is not an address or the w1_bus_master listed. Thank you for your help Perry
-
How is the 1-wire bus enabled on a Rock64 with Armbian 20.08.17 Bionic? I have enabled the w1-gpio through armbian-config. The /sys/bus/w1/devices/ folder is empty after sudo modprobe w1-gpio and sudo modprobe w1-therm. Below is what is in the armbianEnv.txt file in the /boot directory. verbosity=1 bootlogo=false overlay_prefix=rockchip rootdev=UUID=cbeeff94-c38d-4a79-b10a-3854a2470be4 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u overlays=i2c7 spi-spidev w1-gpio In the /boot/dtb/rockchip/overlay/ directory there is a file rockchip-w1-gpio.dtbo. I have connected the VCC pin of the DS18B20 to 3v3 physical pin 1, ground of the DS18B20 to physical pin 9, data of the DS18B20 to physical 7. The DS18B20 address and w1_bus_master1 do not appear in the /sys/bus/w1/devices/ folder. What more is required to see the DS18B20 and take readings? I have already connected an 18x2 LCD to i2c and am writing information to the LCD using python. Thank you for the help. Perry
-
I'm trying to get a Rock64 board working with a wifi USB dongle, sold as RTL8188 and which is in fact a 8188eu. I use the latest armbian-buster as downloaded a few days ago. The dongle appears in dmesg when plugged in, but no module is loaded. I can manually load the 8188eu module and get no errors, but no wifi interface appears. Ifconfig, iwconfig and nmtui don't see anything they could use for wlan. I have installed the firmware-realtek package as well, it made no difference. I can get the module 8188eu autoloaded at boot, but that doesn't change the non-availability of a wlan interface. Any help appreciated. I have posted the armbianmonitor -u output in the required field. ( here it is again: http://ix.io/2Dee )
-
We dropped Rock64 for quality / stability issues. You can do some forum search to find original topics that lead to that decision. Its pointless to waste so much time for the board that is made poor, three different variants are floating out in the wild which are impossible to support all at the same time. You have to tell users - "your version is X, throw it away" ... why should we take the burden of telling you bad news. Why? They also use different power connector which is yet another annoying problem. Vendor provides no backing for the time we waste in bulk - for its constantly complaining clients. We can't sort out this situation and why should we? There are other boards and vendors that makes better hardware, have better attitude and helps us killing the costs. We have too many problems without trying to do the impossible - fix design failures / cheap design with software fixes and 100% on our costs. Rock64 looks nice on paper and if you are lucky - we don't need to play in such game - you have variant that works reasonable well. But it is certainly not better then any H5 board in term of stability. According to my experiences, contrary. It is strange that you have troubles with PC2. H5 boards are in general pretty robust and reliable and Orangepi vendor has production on respectable level - its a serious company and ODM for other hw vendor / resellers. Also we - as community - have very good coverage Allwinner hardware. Too recent and known to be critically unstable at this point. Thank you! I wish everyone would give something, proper attitude at extreme minimum, when asking for help! We - in everyday life - also have to pay or give something back if we asks for help, don't we?
-
Today I run a k3s cluster with different boards: 5 Orange Pi PC2, 2 Rock64 (2G and 4G), a NAS with a Rock64 2G, 1 Jetson TX1, 1 Jetson Nano. I have also other board in use: 1 Pine64, 1 Rasp Pi4, 1Rasp Pi 3, 4 Orange Pi Zero (H2 and H5) and an old Odroid XU3 Lite and 1 Odroid HC2. I use Armbian on all of these where it is available. The Rasp Pi boards and the . All those boards were bought over the time from 2011 when I started with a Bifferboard and later the BeagleBoard. On the cluster I run several services (from flight feeders to meteo station services, home automation and video surveillance and a STORJ node on the HC2. The experience so far was quite good (thanks also to Armbian) especially with the Odroid HC2, the Rock64 and the Pine64. The Orange Pi (both PC2 and Zero) are more susceptible to HW problems; I had more PC2, 3 of them stopped working and now are broken but I can expect that being very cheap, so the manufacturing quality is quite low. I would like to replace gradually the Orange Pi PC2 with a board that is more reliable and it seemed so far that the quality/price of the Rock64 has been quite good but it in the end it is more important to have a good OS on top of them. Ideally that "mighty" board should have good performance, low cost and Armbian well integrated with it. Minimum requirement is at least 4 core, 1 USB3 or SATA port and 2G of RAM. I do not like the Rasp Pi (due mainly to the software). I do not know the reason of change of support for the Rock64 and so I asked about that.; considering the situation myself and another colleague were looking also to alternatives like the Odroid C4.
-
The rock64 is a flaky board. I have similar issues seems to last 2 or 3 days. If you're able to connect something to record logs from the serial console that could help
