Search the Community
Showing results for 'rock64'.
-
[RockPro64] Armbian upstream kernel/uboot test?
Igor replied to anonymoustemp's topic in Pine RockPro64
Thanks! If you plan to keep them concise, then this https://www.armbian.com/rock64/ is best place. Here you can check what is generally expected. If you agree, you get a password on email, the rest - technical details if needed - are written in the dashboard when you login. -
First of all, thanks for sharing your opinions. My shortlist is: 1) Odroid HC-1 - due to known stability 2) Rock64 - it has USB3 on board and recently I purchased USB3 dock for 2 drives. Works nice, uas supported, but no trim. So idea was to connect 2 drives -ssd for system and rotational for data, but looks like trim support is not for me. That's not good, but, well. Nothing stops me for rotational drive for system. Or leave system on _good_ _expensive_ microSD, or make the "read only root", which is promising, but I guess kernel updates will suffer while changing "/boot" data. 3) Orange Pi Prime. Good for it's price, has wifi onboard (hope it supports host mode for hostapd in latest kernel), but no USB 3.0. (2) and (3) are 64bit I guess. Not sure I do have 64 bit tasks (e.g. Apache/nginx large file upload), but still good to have. Also I'm quite sure they both consume less power then HC1. The case is not electricity bill, but requirements for PSU. I run my "rig" from 10A 5V psu, which powers cubie, usb hub, couple of orange pi's (pc2 and pc) without any issues. Probably HC-1 will be ok with this setup also. Personally I really like coming Allwinner H6 boards. They are colder on same Mhz's, but Armbian is in testing stage for them and quite far from stable version.
-
well is it really cheaper? Assuming the 2gb ram is really a requirement: Board: 35$ Reliable USB-Sata bridge: 10$ you save roughly 5$.. Depending on other requirements, the HC1/HC2 has a lot more horse power and a proper casing solution which is still missing if you opt for the rock64.. If encryption is important maybe a ARMv8 might be a better choice. But then I would probably opt for a RK3399 (support not 100% mature yet) but decent mainline support and more options to bring up SATA than with a RK3328 (and the price for the cheaper RK3399 are quite okay)..
-
If you want a cheaper solution, maybe a supported board based on rk3328 like rock64 could be a good option since it has usb3 and gigabit ethernet.
-
Thank you WindySea. Yes just put the hardware sync once on boot. Will disable it. Noticed no time jumps but after ~48 hours the hardware clock is drifting off time sync. I started this little mini automation computer stuff here on RPi's with RTCs (used PiFace RTC shim) and then also on micro OpenWRT routers (made for tinkering with easy to get to GPIO pins) the got a Pine64 (pro bono to ticker with). I waited for over a year for the Rock64 to implement an RTC (it was promised) and I was told it would be in the next production batch....never came to being switched to maybe getting a RockPi4 (still thinking of this one) and meanwhile found out about Armbian and drifted over to getting a TVBox and running Armbian on it. I got in to the NTP stuff in the 1990's tinkering in my home sandbox. So then the nightly upgrade has created a timing issue that you are looking to resolve. Understood. Not sure if you are tinkering with any of the Armbian based TV boxes. Here looking to add a battery backed up RTC in a new automation server based on the S912 Octocore arm tvbox. I have yet to take one apart. Are there schematics out there in internetlandia for any of these devices?
-
Thanks, I've just made the update to my rock64 and will see how it goes over the next couple of weeks. The NIC is only stable for a maximum of a week.
-
A64 date/time clock issue
martinayotte replied to martinayotte's topic in Advanced users - Development
Don't confuse me : Pine64 != Rock64 ... I don't understand why using Armbian_5.79.190418_Pine64_Ubuntu_bionic_dev_5.0.7.img. On my side, here is "dmesg | grep eth" give : root@pine64:~# dmesg | grep eth [ 4.651697] dwmac-sun8i 1c30000.ethernet: PTP uses main clock [ 4.662672] dwmac-sun8i 1c30000.ethernet: Linked as a consumer to regulator.6 [ 4.677055] dwmac-sun8i 1c30000.ethernet: Current syscon value is not the default 6 (expect 0) [ 4.685758] dwmac-sun8i 1c30000.ethernet: No HW DMA feature register supported [ 4.693011] dwmac-sun8i 1c30000.ethernet: RX Checksum Offload Engine supported [ 4.700246] dwmac-sun8i 1c30000.ethernet: COE Type 2 [ 4.705231] dwmac-sun8i 1c30000.ethernet: TX Checksum insertion supported [ 4.712026] dwmac-sun8i 1c30000.ethernet: Normal descriptors [ 4.717702] dwmac-sun8i 1c30000.ethernet: Chain mode enabled [ 18.403292] dwmac-sun8i 1c30000.ethernet eth0: No Safety Features support found [ 18.403309] dwmac-sun8i 1c30000.ethernet eth0: No MAC Management Counters available [ 18.403316] dwmac-sun8i 1c30000.ethernet eth0: PTP not supported by HW [ 31.712399] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx [ 31.712430] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready -
Yes, looks like the script used one of the branches, I do not have one branch with all patches, I tend to group patches into multiple branches to make it easier rebasing and review changes. If you keep the hdmi-sound base as you have and add https://github.com/Kwiboo/linux-rockchip/compare/rockchip-5.x-hdmi-sound...rockchip-5.x-vpu-v2.patch as a patch you should have both branches. The 1080p H264, VP8 samples I have tested on my tinker board and even my rock64 running libreelec / kodi-gbm seems to play back fine using sw decoding. There are some libreelec test images at http://kwiboo.libreelec.tv/test/ for testing, built out of https://github.com/Kwiboo/LibreELEC.tv/commits/rockchip-5.x
-
Thank you very much for your answer! I have no problem to install vnc and browsers on linux environment I have problem only with this armbian release and wanted to take a shortcut and not download several dozen versions trying all of them one by one. So I've chosen a latest Ubuntu desktop and everything is fine now, everything working out of the box . And it doesn't call itself Rock64 anymore...
-
Yes, discussed at length on these forums, ignored by all... There is the tiny barrel jacks like that seen on the Rock64.
-
Hi all. Here my review video of the new Pine H64 model B. I also compare it with the Orange Pi 3, and it's older brother the Rock64. I hope you'll like it. Thank you. Greetings, NicoD
-
Thanks jpegxguy , I will try that. What is mkscr? and where does the boot.cmd live? Don't know why my rock64 gets this but i don't see other people discussing this. It's about once a week and the only recovery is to restart it.
-
HI, thank you very much for the script, working very well, just can't start kodi. It just exits to console, and getting following error: (i'm not running armbian, but the defualt ubuntu, and the script is working great also on ayufan, can watch YT, and videos, all cool) Apr 08 16:42:05 rock64 kernel: rockchip-vop ff370000.vop: [drm:vop_crtc_enable] Update mode to 1280x720p60, type: 11 Apr 08 16:42:13 rock64 kernel: dwhdmi-rockchip ff3c0000.hdmi: failed to get edid Apr 08 16:42:14 rock64 kernel: dwhdmi-rockchip ff3c0000.hdmi: failed to get edid DISTRIB_ID=Ubuntu DISTRIB_RELEASE=18.04 DISTRIB_CODENAME=bionic DISTRIB_DESCRIPTION="Ubuntu 18.04.2 LTS" Linux rock64 4.4.132-1075-rockchip-ayufan-ga83beded8524 #1 SMP Thu Jul 26 08:22:22 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux THANKS FOR THE GREAT JOB
-
I can never seem to get the Rock64 to boot consistently from the SSD. Sometimes it comes up, sometimes it just "hangs". About once out of every 6 or seven times can I SSH into it - this is regardless of distro whether it's Bionic or Stretch. This is totall after flashing it to allow for USB boot. On the Pi, I was able to solve this 100% of the time by using a small microSD card with nothing but "bootcode.bin" and an empty file called "timeout" which tells the boot to hang for a bit while things "spin up" and the SSD (or HD) mass storage come available. Once I did this, all my Pi's work great. In addition with the Pi I am able to do all of this completely "headless" where I can restore an .img onto the SSD, copy over a wpa_supplicant.conf file and touch an ssh file and "boom", I can always get to it consistently without having to prep it by plugging in a monitor and keyboard to make manual changes before booting it headless. Are there any steps to make this a similar possibility with the Rock64? Is there some image I can put on an SD card that will accomplish the same thing and then let bootup happen and continue on the image restored to the SSD that is hanging off the USB 3.0 port? Personally I don't care if it has a microSD in it or not - as long as it boots consistently 100% of the time and all of the real I/O occurs on the SSD drive. Thanks! Ryan
-
Yes, I tried all the dtb files of rk3328, now again.I don't know what the problem is. rk3328-a5x.dtb no eth0 rk3328-a5x-1500.dtb no eth0 rk3328-a5x-mx10.dtb no eth0 rk3328-box.dtb no eth0 rk3328-box-liantong.dtb system not start rk3328-box-trn9.dtb no inet rk3328-box-trn9-1500.dtb no inet rk3328-box-z28.dtb no eth0 rk3328-evb.dtb no eth0 rk3328-evb-100m.dtb no eth0 rk3328-evb-android.dtb system not start rk3328-mx10.dtb no eth0 rk3328-mx10-fast.dtb no eth0 rk3328-mx10-low.dtb no eth0 rk3328-roc-cc.dtb no inet rk3328-rock64.dtb no eth0 rk3328-rock64-android.dtb no inet rk3328-rockbox.dtb no eth0 rk3328-t9-android.dtb system not start no eth0 like this no inet like this
-
sick and tired of my Armbian desktop locking and crashing
NicoD replied to AxelFoley's topic in Pine RockPro64
So it started to do this after an upgrade? I only asked if you were using the media script to know if that's not the problem. You didn't need to install it. But it could help, you never know. I'm not sure it works on the RockPro64. Did you try another browser? Firefox? Vivaldi? I know what browser crashes look like, I've had enough of them myself. I've worked with the Rock64 this week and always had them. I then tried an older kernel and it was better. Maybe it's the same problem, or related. @JMCC Could it be? Did you find anything? What are the crashes like? Different kinds of crashes? Messages you get? You could run Chromium with the terminal (just type chromium)and see if it gives any clues to what's going on. -
WD Blue 3D NAND SSD 1TB is not working on USB 3.0
suberimakuri replied to Telekomiker's topic in Rockchip
I haven't had any luck with reliable USB3 and SSD's on my Rock64's (7x), so I'm using USB2. Tried powered usb hubs, etc. There are a bunch of threads about it on here and arch forums, plus ayufan's github. Sorry If you spot something I'll be keen to hear. -
My sentence was a bit unclear. I menth something like, "I've got the simular C2 that I like a lot, but other people don't like it." So that's why I thought I'm not sure it's the best choice to make for him. I would always say to buy the NanoPi M4 before anything else for desktop use. I've been struggling with the Rock64 a whole week, + with the RPi3B+. Yesterday I again turned the M4 on after a week not using it, boy how happy I was to be back on it. So fast, stable, pleasant, ... There's nothing like it(that I have yet) I just ordered the Odroid N2. So maybe the M4 isn't going to stay my favorite. But I've got to wait +2 weeks for it to arrive, why haven't we got a time machine yet. It's 2019 g*d damned.
-
There is no such problem with RK. This is the problem of the manufacturer of the specific equipment (or rather the problem of support of this equipment). I have TV boxes on the basis of RK3328. On them everything works without problems (Armbian and LibreELEC). Including video and audio output in 4K mode (using a media script). The only problem is, you need to modify the cooling. The same applies to rk3399, if you select the correct model , the user receives a fully complete and ready to use equipment. On rk3328 can normally be used as a mini PC with the desktop resolution up to 1080p. For those who need a desktop resolution of 4K or max performance model rk3399. PS I would be interested to check a few assumptions, if there are owners of Renegad or Rock64, write, discuss the steps.
-
The Renegade is RK3328 like the Rock64, I have one on my desk. It has DDR4, however there have been the same frustrations concerning the RK3328 support in general from Rockchip. I know Armbian has put a few bugfixes out there, Ayufan has been doing double time on it, but without some vendor assistance there is only so much you can do. It is a very nice board, but I don't know that a move from the Potato to it would show you any benefit (same cores, same clock speed, better/more ram.)
-
? Which problems? I actually have more issues with my C2 and K2... There is also the likelihood of that SoC (The S905) being EOL'd (if it hasn't already been) Don't get me wrong, the C2 is a great board, but it is at best on equal support footing with the Le Potato. The issues with the Rock64 are honestly more Rockchip issues, their support of that SoC hasn't really seemed to hit the level of the RK3288 or RK3399. The RK3288 is still my favorite Rockchip for "normies" because it just works. No games, no BS, it's about as close to plug and play as you're going to get. Unfortunately it didn't fit enough buzzwords, so the only boards using it are the MiQi and Tinker Board, with a proper power supply the Tinker is a solid choice, and will run circles around a quad-core A53 in desktop use. The only competitors so far desktop wise are the RK3399 (support isn't quite there yet) and the Odroid XU4. (H6 is still pretty buggy I think)
-
Thank you, that's some extensive testing. You clearly are having the same experience as I have. This doesn't seem to be the same with everybody. I'm using a Rock64 with 4GB, you the Renegade 4GB. So the problem isn't with my board(too bad). @JMCC Someone made a useful comment on the video "Hi, I can see you are playing youtube video in vp09 format. Try to use h264ify addon to force h264 format, it should help a lot. I dont know if hardware acceleration is supported for vp09 codec." I did try h264ify, but it wasn't much better. I'll give more info tonight on this, it still didn't say h264, but it wasn't vp09 either. It also crashed with this installed, maybe 1080p played a bit smoother, but image quality was a lot worse than 720p vp09. The fact that Firefox does exact the same things makes me think the problem isn't with the browsers, but some compatibillity problem with the script or so. Or did we both forget something? I don't think so? With the NanoPi M4 I've never had any issue like this. That seems to work perfectly for me. I've also tried Ayufan his images but those were not bootable. He seems to have made images with VPU/GPU too. I told them to try Armbian with your script. They answered : "Using the latest Armbian build but get a NIC failure about once a week. Bunch of TX error.... Hoping these new builds and patched kernel will fix this as it's a known issue with the rockchip... Funnily enough the older 0.56 stable build never had this issue that i recall." I do not use the Rock64 a lot and don't follow threads about it. I think it's a known issue, but I'm not sure. Cheers
-
in the setiathome-forum you did wrote you only tested os-versions with kernel 4.4.176 - maybe that was the problem? Like for my NanoPi K1 Plus I compiled armbian 5.77 with kernel 5.0.4 for my NanoPi A64 (its not offiicial in the build-system)... And via the BOINC-Manager on the PC I started on the NanoPi A64 setiathome So why not try the armbian-build-system for your rock64? There seems to be also 5.0.0 (or more) kernel dev-image possible for rock64: [ o.k. ] Checking git sources [ u-boot-rockchip64 rockchip-master ] [ .... ] Creating local copy [ .... ] Fetching updates [ o.k. ] Checking git sources [ linux-rockchip64 5.0.0-1092-ayufan ] [ .... ] Creating local copy [ .... ] Fetching updates remote: Enumerating objects: 67035, done.
-
I was getting computational errors, the task would fail. If I ran 2 task, the system could handle it. My rock64 is active cooled and that was not the problem. When I tried 5 different flavors of linux, all failed, but this last worked. This has been the only platform I have struggled with. here is my thread on setiathome. https://setiathome.berkeley.edu/forum_thread.php?id=84052&postid=1987458#1987458 maybe if I can build a buster version of armbian, it will a fun experiment.
-
wouldn't agree on this one.. IMO overall pine build decent SBCs with a design which makes sense for a really competitive price. This thread together with this one: just show that you rush through multiple ideas trying to fix something which might need some time to fix. E.g. updating to 4.14 (or 5.0) or whatever kernel you want from 4.4 doesn't mean that things get automatically better. The 4.4 kernel for Rockchips is based on Rockchips opensource 4.4 kernel whereas all others (4.14 ++) are based on upstream.. So as long as the needed drivers aren't in mainline, the BSP kernel will support more features than upstream kernels. I would suggest you go for a more problem solving approach than trying various random things/boards which might frustrate you even more. E.g. install the official image for the Rock64, test if the things you need work and if they do, compare it with the configuration we use for armbian (e.g. devicetree, kernelconfig). Fill in the missing bits and things will work. In case not, pine has also a community forum where you can open issues that *random feature* doesn't work.. probably they read their own forum and try to help things fixed. It's very likely that my next SBC will be a Rock64 cause the board has some nice features and the price is really competitive for my use-cases. IMO rockchips is one of the few companies for which armbian builds images where the SoC maker cares to mainline their features.. Are they perfect? for sure not. but at least they try it.. Whereas allwinner was a pure community push to get those SoCs in mainline, and for the Amlogic, a lot of funding happened due to SBC makers cared about it (tbh I really don't follow Amlogic support cause their boards are mostly boring for my needs - seems that they're great multimedia devices but just not my use-case).
