Hello everyone!
After some lurking, I resolved to step into the fray  

So, I have a shiny new Rock64 board, running latest linux ayufan minimal build (0.7.9).

My OS is on microSD, a Sandisk Ultra A1 16GB (92 MB/s tested with another Linux box).

I've noticed SD speed is quite low on Rock64 (about 21 MB/s in my case), because of DDR50 mode only (no SDR104).

But... in his 0.7.7 release notice, auyfan himself says he enabled SDR104 in Rock64 kernel: 
https://github.com/ayufan-rock64/linux-b.../tag/0.7.9 (search for "SDR104")
(I know Rock64 hardware does not support SD 1.8v signaling. I suppose he did a similar trick used on Raspberry PI: force the clock to 100MHz even if signaling is 3.3v instead of 1.8v. It works flawlessy on RPIs, I have 4).

I upgraded the kernel and the u-boot to the latest, as per instructions.

Now, what should I do to enable SDR104? Some obscure file/config/whatever to edit?

Thanks! Let's Rock this SD

I am looking for a stable EMMC LibreELEC version. I tested a few of the most recent ones but they all crashed after a few minutes, even if LibreELEC was in idle. The Rock64 has got a heatsink, the power supply is 5 V, 3 A.

With my Rockpro64 LibreELEC works fine, but I would prefer the smaller board.

Hi everyone!
Just installed  PINE64 WIFI 802.11BGN/BLUETOOTH 4.0 MODULE on Pine64/Android 7.1 TV ver 0.3.10 build 66 and it works...
The problem is that after 10-15 minutes of working it gets crazy hot (heat sink is installed) and freezes the system.
If WIFI/BLUETOOTH is disabled and network cable is used instead device works just great no overheating or any other issues..
I hope that someone has a solution to this problem.
Thanks in advance!

Using either python or java, there is no way to set an interrupt on a GPIO pin. Instead, you must poll, wasting valuable CPU. In other words, the modules available to read pins as input or output do not support setting callback functions as RPi.GPIO does.

This has been available since 2013 on the Raspberry Pi, but is not supported by any of the modules on the Rock64. See:

https://raspi.tv/2013/how-to-use-interru...pio-part-3

The only modules I can find are Leapo and all callbacks are marked as "Not yet implemented." Further doc says that interrupts are not supported in the kernel. This makes the GPIO header useless for real applications.

https://github.com/Leapo/Rock64-R64.GPIO...efinitions

For quite some time, rumors have swirled of Pine64 making a foray into the handheld device market. I've been altogether dismissive of the discussion, because frankly it's a waste of time.and mental real estate mulling over unsubstantiated chatter in tech. But today I read a tweet from Pine64's official handle, and I can't afford to dismiss it. 

To paraphrase the tweet, Pine64 retweeted this article from It's FOSS, with the following addendum: "What do you think ? Should we make a smartphone? "

This is a simple question with an even simpler answer: NO. 

Pine64 stands alone as the sole company possessing adequate brand recognition, resources, and community involvement to ever pose a serious challenge to Raspberry Pi. We could discuss all day why that competition is so incredibly pivotal, but I think it mostly goes without saying so I won't digress further. 

A mobile device would undeniably divert resources, attention, and time away from development of Pine64's next generation of SoC boards. That's not a likelihood, or a plausibility or a potentiality, that's a downright certitude. By what way of reasoning should Pine64 divert anything from their centerpiece claim to fame? ARM's platform is growing every single day with constant new extensions made to armv8. Just last month, armv8.5 was announced, and the latest extensions are sure to be phenomenal. 

What is Pine64 planning to integrate these extensions into the next lines of Rock64? As far as I know – and please correct me if I'm wrong – there was no attention whatsoever given to integrating the significant extensions released with armv8.4 back in 2017. My point is that Pine64 seems to be of the belief that they've conquered the mountain, and they await the next challenge. Newsflash: they haven't, and the challenge is still upon us. 

I was relatively nonplussed by the Pinebook, as I figured it was a way to broaden Pine64's reach to a new consumer group, and show newcomers to the SoC community what these boards are capable of doing, becoming, and creating. Jumping into the fray that is the mobile market is an entirely different breed of idea. Not only is it fundamentally misguided, it's altogether devoid of reason, purpose, or ambition.

My Pixel 2 XL feels like silk to the touch, because the hardware is such a work of beauty. I love holding this phone in my hand. It's also rooted, so I'm able to flash whatever software my heart desires. It offers literally everything I want in a mobile device. If you suggest that Pine64 can produce a more refined product than this at a comparable price point, you are lying to yourself and you know it. 

This is not an insult or even a critique of Pine64 as a company. Michael Jordan is widely-regarded as the greatest basketball player of all time. One year he tried to switch to baseball. He failed. That doesn't mean he's a lesser athletic talent, it just means he was playing the wrong game. This is more or less Pine64's proposition – they're, in my opinion, the single best and most promising consumer-grade single board computer company in the world, with potential to surpass the most successful SBC company in history by every metric, but they're going to divert funds from that endeavor to go play baseball for a while. Sure. Try that.

Just know this: every single penny that's spent on a doomed-to-disappoint-if-not-fail-miserably phone is a penny that could have been invested in making Pine64's existing product line that much greater and more competitive. And for what? There is already Ubuntu Touch. There is already Android. There is already Purism, a company developing a 100% free and open source phone on which you'll literally be able to install the mainline kernel, and anything else your heart desires.

So what does Pine64 bring to the table with their phone, other than less refined models of what we already have? They're sacrificing advancements to their boards by investing even one penny, one minute, or one more employee hired to accomplish this. That's just a fact - resources are finite, and what a company spends on one thing is money sacrificed elsewhere. So in neglecting further development of what made Pine64 a rockstar company in the first place, what precisely is being delivered in return? What reason in the world is there to deprive your SoC platforms of valuable resources, when the outcome will represent a wholly redundant, utterly pointless novelty device?

I want to see Pine64 succeed. This is not the path to succees. This is not the way to grow our community. This is not the way to take advantage of each new eye-popping extension ARM adds to their ever-growing platform. Someday very soon ARM-based hardware will be commonplace in enterprise server solutions. This nonsense about a phone is just that - nonsense. It will not be successful, and it will squander much of what Pine64 has accomplished, giving valuable ground away to competing companies.

That's all I have to say. I just needed to get this off my chest. I believe in Pine64 as a company and I love working with their boards, but if/when Pine64 begins to lag behind the rest of the market because they're distracted with a futile phone project, I'm going to buy the best boards available. And sadly, if "Pine Phone" goes forward, Pine64 will cease to produce even one of the best boards around in any class by any metric whatsoever.

Thanks for reading.

Hello I am trying to make a case for this board and would like to start now before the board gets here so it can be printed. Does anyone have a 3D file or a CAD drawing of this board?

Hi,
I am using Ubuntu LXDE on Rockpro64.
Any library that can be used with this image to access GPIO?
Also how can i control fan.
Thanks.

Hi ,

Does this board support 4k LCD (Sony Xperia Z5 Premium) thro MIPI-DSI? 

If yes, what are components I need other than the LCD& the board?

Thank  you.

For the life of me, I cannot find the location described in the wiki for the antenna locations. It says:

Quote: In the back section of the case at the very top you will find three cut-outs where the SMA antennas can be fitted.

I have a raspberry pi respeaker hat I want to use on the rock64, but their install scripts only work on the raspberry pi. It looks like most of the script is easily modified to work on the rock64, but I'm not sure about the DTB file.  I decompiled it and it's over my head.  What is needed to make this compatible with the rock64?

This is the decompiled overlay file:
https://pastebin.com/qbtADNUp