Search the Community
Showing results for 'rock64'.
-
Mainline support is under development and it doesn't work very well. In case you find something not working ... nobody will listen. If that is ok, here are some test builds: https://dl.armbian.com/rock64/nightly/
-
Here's the situation: I tried using their device tree (which is very similar to the one we were using before I made the last PR), but that makes our kernel unable to initialize SD card, as happened before that last PR I mentioned. So I was assuming that a recent kernel like ours introduced some incompatibility with the old device tree. But, now that you mention, it can also be that they are using some patch we don't have. If I am able to pinpoint that patch, it can be introduced per-board without affecting Rock64, can't it?
-
As discussed on multiple threads, the aim of this thread is to bring all RockChip devices under one BSP (4.4) Kernel. This discussion can be found (partly): and a bit background here: https://github.com/rockchip-linux/kernel/issues/98 Cause I'm not willing to cut out all this stuff from the related threads (this would end in a complete disaster) I try to summarize it here (if something is missing, let me know I'll add it): RockChips BSP kernel is not longer an option. Cause it breaks faster that our current resources allow to fix it. Having all SoCs under one kernelsource would make it more predictable and decrease the efforts needed to keep them 'reliable working'. Ayufans (https://github.com/ayufan-rock64/linux-kernel/tree/release-4.4) tends to be the preferred Kernel at the moment. First attempts to bring up rk3288 boards are made notify some of the involved people just to make sure they don't miss it (I probably miss some, don't be upset ): @TonyMac32, @JMCC, @tkaiser, @Igor, @zador.blood.stained, @hjc & @ayufan Some questions which are open for me: How can we ensure that the 4.4 kernel we currently use for the RK3288 get at least 'security updates' as long as the switch needs? Is someone in touch with ayufan so that he recognizes our idea? (or @ayufan do you read the stuff here ) Can we 'channel our efforts' to ensure that we don't waste our and others time (e.g. open a transitions branch and make it clear that PRs against the old kernels don't make sense) I hope this thread doesn't get floated with garbage but on the other side I hope that people write about their plans and 'results' so that we don't do the work twice. EDIT: BTW, I'm not sure if this thread fits better in development or here, but I think it's more recognized by the rk-users when we have it here..
-
@Igor Thanks for adopting my suggestion. RK3328 is working great now. Yesterday, I finally migrated my house server from OPi PC to ROCK64/4GB. Got a RAID5 array of 4 WD Red HDDs via USB3 UASP adapters, providing around 390 MiB/s. Fantastic! @moso Just removed my above-mentioned fork, as Igor merged all relevant changes to the official tree.
-
Thanks a lot for your detailed answer, lots of food for thought. I already own a board with H6, the OrangePi One Plus. I don't know how I could help with this one... As for the RK3399, there are quite a lot of very interesting (to me) cards... 96boards, OrangePi, FriendlyElec, Firefly... Difficult choice. Regarding the RK3328, lots of cards looks nice: ROCK64, Renegade, ROC-RK3328-CC, SwiftBoard Data... And for the MT7623, it looks interesting, but I see almost only routers with this SOC... which could be a good thing for one of my use if I understood well network bonding with Linux (I could have lots of data to send (video from phone screens), and splitting it on 6 differents Ethernet plugs could help).
-
Tested also with Rock64 (slightly slower memory). We get there 3.63 kH/s with our old setting limiting Rock64 to 1.3 GHz. After lastest commit at 1.4 GHz Rock64 scores 3.88 kH/s as expected (little bit slower compared to Renegade due to different DRAM)
-
Or it's just an RK3328 limit? Tested again with Rock64 (but an early developer sample) and got 835 Mbits/sec in TX direction: https://pastebin.com/raw/cwqag6e8
-
Hi, Not sure if this is worth reporting to you, or if this is the right place to do so, but here it is. The current downloadable version from the Armbian website required me to use the https://github.com/Matei-Ciobotaru/Rock64-R64.GPIO library for GPIO functions due to an offset The version of the OS you sent me required me to use the original https://github.com/Leapo/Rock64-R64.GPIO.git library. So Not sure if this is a bug or not. But it is a something I though was worth mentioning. Also the path to /usr/sbin isnt in the version you sent. Hope this helps. Mark
-
Is that in libmali somewhere? That seems to be just higher level stuff like CL EGL GLES. That's probably the wrong place to look, I've seen a link for downloads at pine64.org, don't have it handy. In /lib/firmware/edid I see what appear to be 29 binary dumps of EDID data with video modes in the filenames. Is something comparing the live EDID with the files and setting the mode from the filename on a match? I know EDID has been through several versions that aren't necessarily compatible with each other. Raspberrypi.org doesn't publish source of their EDID parser due to copyright issues. I tried writing one once. I know somebody on the debian-arm mailing list with a Rock64 who uses the mode I want, I guess I should ask him how he gets it. He does build his own kernels, I forget why.
-
I'm trying to use it with a TV that has HDMI input but it's 1360x766. xrandr says it's running at 1920x1080. It's very small, like keep a magnifying glass handy, and I don't have the bottom of the screen where LXDE puts the pager and buttons. I thought from my Raspberry Pi experience that I'd just change the mode in my config.txt https://www.raspberrypi.org/documentation/configuration/config-txt/video.md but apparently the Rock64 isn't that evolved. Can I set an HDMI mode in my armbianEnv.txt? Can it use CVT modes? The standard 1360x768 mode isn't quite right. I've been around this stuff since you had to work out an xfree86.conf file on paper and take timings into account but that was with CRT monitors where the resolution didn't have to exactly match LCD resolutions. Where do I change it? I have a couple monitors that a Pi's EDID parser doesn't work right on either, which is OK as long as there's a way to set the mode manually. FWIW this is an Axess TVD-1801 a couple years old. The PDF I just grabbed says 1366x768, something else said 766 vertically.
-
@balbes150 Thank you very much for all the time, effort and competence you put on your work. It is very much appreciated. @Reddwarf Not much happening there lately: - https://forum.armbian.com/topic/4583-rock64 - https://forum.armbian.com/topic/4895-a5x-max-rk3328-4gb16gb/ - https://forum.armbian.com/topic/4708-z28-rk3328-18/ - https://forum.armbian.com/topic/6658-rk3328-scishion-v88-piano-and-v88-mini-iii-tv-boxes/ As for the second chip, did you mean 3229? If so, it has been a few months since I looked last, but I hadn't found anything for the 3229 until then. I am interested in both the 3328 and the 3229.
-
Try this image: https://dl.armbian.com/rock64/nightly/Armbian_5.51.180704_Rock64_Debian_stretch_default_4.4.138.7z
-
No difference in numbers when trying out tx_delay = <0x25>; rx_delay = <0x11>; So i hope we get DT overlays working to be able to test through all reasonable combinations soon. Without DT overlays this would require a huge amount of reboots Edit: as a reference Rock64 numbers: https://forum.pine64.org/showthread.php?tid=4668
-
Is there a guide somewhere how to enable 1wire support on a rock64 using stretch or xenial. Im trying to read a dallas DS18b20 sensor. I see some examples for other boards but cant figure out how to apply them to the Rock64. Thanks
-
Hi Sorry this is my first time this deep into the kernel. Still no boot on the 1G Rock64 Tried it on multiple 1G rocks. Works fine on the 2G Rock. When I boot the system i get a black screen and nothing ever appears so theres nothing to send you. Is there any logfile I can dig through? Thanks
-
Hi! Thanks I confirmed that it is a 1GB memory size issue. Everything boots fine on my 2Gb Rock64 Do you have the same fix dor Xenial? Thats the image Id like to use. Thanks again
-
And here are the numbers after doing the below (for details see here): https://pastebin.com/raw/d61z7YY1 echo performance > /sys/bus/platform/drivers/rockchip-dmc/dmc/devfreq/dmc/governor If I understood correctly the result was switching from 1024 timing to 1066: root@renegade:~# cat /sys/bus/platform/drivers/rockchip-dmc/dmc/devfreq/dmc/trans_stat From : To :78600000080000000085000000093300000010240000001066000000 time(ms) 786000000: 0 0 0 0 1 0 1 800000000: 0 0 0 0 0 0 0 850000000: 0 0 0 0 0 0 0 933000000: 0 0 0 0 0 0 0 1024000000: 0 0 0 0 0 1 5985353 *1066000000: 0 0 0 0 0 0 903822 Total transition : 2 Wrt TX/RX delay adjustments here is a script made by ayufan to check through a specific range: https://github.com/ayufan-rock64/linux-build/commit/d32a459705afdcc43e2e3f129e9b37577bf13962 (also useful to learn how to use DT overlays with RK's 4.4 BSP kernel). The settings we currently use as follows: https://github.com/teacupx/build/blob/98100bf764235e153bb6ce6fe558fc3a06f4aa39/patch/kernel/rk3328-default/Add_dts_rk3328-roc-cc.patch#L735-L736 But the script doesn't work for whatever reasons.
-
Hi, I'm unable to get my Rock64 to boot either the Xenial or Stretch Armbian images from SD or Emmc. I can get all of the other OS's to boot fine off of either media. Ive tried with multiple Emmc chips, SD cards and Rock64's with the same results so its not the hardware. Seems like it cant find the boot loader. Ive used win32diskimager, Etcher and the Rock64 instakk software. I've formatted the SD card completely, used new SD cards... I'm stuck! Any suggestions Thanks!
-
Is this still present? This looks like a temporally (upstream) network related bug. Yes. Fixed. Now it is also clear why u-boot was from Rock64 ... I haven't notice error while compiling ... and since u-boot was already present (not cleaned properly) ... it didn't break the compilation. I'll remake it and put to the server.
-
I built the new renegade.wip from "master" branch, and it boots and works. As Tony and me could confirm, yesterday the former roc-rk3328-cc.csc from "master" also worked, so I'm pretty sure the problem was that the download image was built from "development", which was still pointing to an old config using the rock64 u-boot. But now, since the file "renegade.wip" is only in master, I think there cannot be any possibility of the same confusion happening again. On the other hand, I have noticed that with today's image my board shows only 510 MiB of RAM, while yesterday it showed the full 1 GiB. I want to troubleshoot this, but for that I need a fully working image. And, as I said, my images are buggy because of the name resolution bug some of us are experiencing in the build script. So @Igor , in case you are not going to restore the download link for Renegade images yet to the download page, would you mind building and image and sending me the link? That way, I can use it as a base, and only build u-boot and kernel for my tests.
-
Strange, since even the U-boot message said Rock64, I built the roc-whatever recipe and it was labelled correctly. That's interesting. I had a Rock64 built and yes, it was panic-on-boot, wheras the renegade wasn't finding the boot script/environment at all. Sent from my Pixel using Tapatalk
-
Nope. It was Renegade. I rebuild for Rock64 this afternoon after this and it works/boots fine. (it was broken too)
-
@Igor was the image uploaded actually and accidentally a renamed Rock64 image? That could explain (part of) the issue with that image. For the filesystem issue, I haven't gotten any farther debugging unfortunately. Sent from my Pixel using Tapatalk
-
https://github.com/armbian/build/commit/c63b2129f64a741d71b30bc7bf3bb6ede98de6fb I attach to last known for now. It's better than having a broken system. I did test and boot Rock64 ... check Renegade and I'll remake the images if it works as well.
-
I see the patches in there, let me verify by building it myself. Building a Rock64 at the moment to see if there was a different issue entirely, but that seems not to be the case I can boot the one I build myself. [edit] ...buuuut it seems to like to lock down the filesystem midstream. let me get some monitoring hardware set up and see if I've found a bad cable or if the SD slot perhaps does not support the modes it claims to... SD cards in question: 128 GB Samaung EVO select 32 GB SanDisk Extreme U3 A1
